PDA

View Full Version : Emulation mode - 1.08 Update



mvallevand
2007-07-06, 08:12 PM
I have updated the alpha mvpmc with small improvements to deal with changes in GBPVR including changes PVRX2's improvement. This code will be incorporated into the mvpmc code base tonight and will be available in the mvpmc nightlies beginning with 07/07/07 and in the full 0.3.4 version when it is available.

For GBPVR note that inset video is no longer supported by sub. With the tremendous improvements in PVRX2 I assume over as short time most of you will be migrating, but if you have any comments please indicate if you are using GBPVR or PVRX2

Martin

mvallevand
2007-07-07, 04:04 PM
The emulation code changes did get built last night, so the 2007-07-07 nightly is probably the better dongle to use. Looking at the about screen I noticed I have a lucky version too. The automated buiild was at 0300 EDT which is 0700 UTC. so 07/07/07:0700 !

This will allow me to continue to improve the alpha version without impacting what there is today. For those using yesterday's alpha there is no reason to upgrade.

I addition to the nightly, sub's survival guide links to

http://www.mvpmc.org/~mvallevand/donglex2a.zip

Now I will attempt point to the version that you feel is best. Now it is the nightly.

Martin

mvallevand
2007-07-10, 01:00 AM
I have uploaded my first alpha for 1.0.8 to potentially address some problems when PVRX2 returns less data then requested as discussed in this link
http://forums.nextpvr.com/showthread.php?t=27711

Ideally PVRX2 should do the buffering, since I have placed an arbitrary timeout of 7/10 of a second on this which may be too much or too little. Hopefully this is a temporary solution.

Martin

sub
2007-07-10, 01:57 AM
Ideally PVRX2 should do the bufferingIt does. If there isnt as enough data available to fulfil the request, it waits a bit and checks again. It does this a few times, then eventually returns whatever it can. It'll usually only return a partial data buffer when its reached the end of file. The next request would typically return zero bytes.

mvallevand
2007-07-10, 02:15 AM
It does. If there isnt as enough data available to fulfil the request, it waits a bit and checks again. It does this a few times, then eventually returns whatever it can. It'll usually only return a partial data buffer when its reached the end of file. The next request would typically return zero bytes.

I don't know if you saw the log I posted here, http://forums.gbpvr.com/showpost.php?p=207714&postcount=7 but it looks like the buffering seems to change after show transition in live tv. This update gets around this by waiting a bit on short reads and requesting another read even when you return zero. I'd like to see just a little longer wait at this point since as the mvp plays out its mux you should actually have more time to pre-buffer and I think you do, but once the pre-buffer is empty the short reads start.

Martin

jksmurf
2007-07-18, 11:19 AM
Just like to report that the 2007-07-11 Alpha mvpmc dongle seemed to take a lot longer after "Starting Application" appears than the previous one (which also worked ok with PVRX2)

Haven't tried 2007-07-17

k.

mvallevand
2007-07-18, 11:48 AM
Just like to report that the 2007-07-11 Alpha mvpmc dongle seemed to take a lot longer after "Starting Application" appears than the previous one (which also worked ok with PVRX2)
k. I haven't changed the startup code and I don't see any difference so I'd like to see the MVP- logs that go with this. I think you should also look to see if any plugin, skin, or patch you've added since the release might be causing this by going back to the dongle in donglex2a.

Here's my current startup time (using the mvpmc debug output) This seven seconds is very typical, with a screen in under a second.


08:25:43 Starting Application
08:25:44 Emulation timer started
08:25:44 Received RDC command RDC_SETTINGS Settings command 0
08:25:44 Received RDC command RDC_SETTINGS Settings command 3
08:25:44 YUV2 update 44 0 640 480
08:25:44 Timer 0 New Session - 0 5000
08:25:44 Received RDC command RDC_SCALE
08:25:45 Timer 0 OSD 0 5000
08:25:50 Timer 0 Ping - 10 5000
08:25:50 Handle Ping
08:25:55 Timer 0 OSD 0 5000


Martin

HtV
2007-07-18, 01:20 PM
I tested here, no difference in the 11-07 and 17-07 dongle overhere. "Starting application" takes about 1-2 secs.

cya Hans

jksmurf
2007-07-18, 01:55 PM
OK, I'll try and remember how to add the debug logs for mvpmc (assume those are what you need). I have also installed every PVRX2 patch sub has thrown up the latest being this one from today 18 July (http://forums.gbpvr.com/showpost.php?p=210116&postcount=10).

k.

mvallevand
2007-07-18, 02:41 PM
OK, I'll try and remember how to add the debug logs for mvpmc (assume those are what you need). I have also installed every PVRX2 patch sub has thrown up the latest being this one from today 18 July (http://forums.gbpvr.com/showpost.php?p=210116&postcount=10).

k.

For now the server side log will be fine. The results I showed were on the comskip patched PVRX2 too.

Martin

mvallevand
2007-07-20, 11:21 AM
I have updated the mvpmc code base with the changes that are in the alpha. The nightly from 20070720, dongle2a.zip and the alpha starting 20070711 have the same emulation mode code.

Martin

jksmurf
2007-07-20, 02:34 PM
Is this the wait I'm looking at?



2007-07-20 20:52:26.781 VERBOSE [4] Sent dongle block 7360
2007-07-20 20:52:26.831 VERBOSE [4] Last block 7378
2007-07-20 20:52:26.831 VERBOSE [4] Sent dongle block 7378
2007-07-20 20:52:26.831 VERBOSE [4] Sent: C:\Program Files\devnz\gbpvr\dongle\dongle_Alpha_2007_07_17.b in
2007-07-20 20:52:56.324 VERBOSE [3] Received MVP Service Locator request
2007-07-20 20:52:56.324 VERBOSE [3] Parsing MVP Service Locator request


in MVP-PVRX2.exe-1.log

k.

mvallevand
2007-07-20, 04:50 PM
Is this the wait I'm looking at?

I'm looking for the MVP-PVR* logs. Based on what I see, there is a huge delay (almost 1 minute) with the Stock Ticker. Are you saying you don't see the same delay with the Hauppauge dongle?



2007-07-20 20:52:57.385 VERBOSE [6] Skinhelper loading image from file: C:\Program Files\devnz\gbpvr\skin\blue\panels\RecordingProces sNotRunning.png
2007-07-20 20:52:57.495 VERBOSE [6] About to check file: C:\Program Files\devnz\gbpvr\plugins\Jeff\StockerTickerPanelW idget.dll
2007-07-20 20:53:03.063 VERBOSE [6] About to check file: C:\Program Files\devnz\gbpvr\plugins\Jeff\Video Archiver.dll
2007-07-20 20:53:03.194 VERBOSE [6] Skin file not found: C:\Program Files\devnz\gbpvr\skin\panels\VApanel.xml
...
2007-07-20 20:53:03.754 VERBOSE [6] Skinhelper loading image from file: C:\Program Files\devnz\gbpvr\skin\blue\panels\RecordingProces sNotRunning.png
2007-07-20 20:53:03.754 VERBOSE [6] About to check file: C:\Program Files\devnz\gbpvr\plugins\legacy\recordPlugin.dll
2007-07-20 20:53:03.834 VERBOSE [6] About to check file: C:\Program Files\devnz\gbpvr\plugins\legacy\StockerTickerPane lWidget.dll
2007-07-20 20:53:47.467 VERBOSE [6] About to check file: C:\Program Files\devnz\gbpvr\plugins\legacy\UbuRadio.dll
2007-07-20 20:53:47.507 VERBOSE [6] About to check file: C:\Program Files\devnz\gbpvr\plugins\legacy\Video Archiver.dll
2007-07-20 20:53:47.647 VERBOSE [6] Skin file not found: C:\Program Files\devnz\gbpvr\skin\panels\VApanel.xml
2007-07-20 20:53:47.647 VERBOSE [6] ...about to check default skin


Martin

jksmurf
2007-07-21, 06:15 AM
I'm looking for the MVP-PVR* logs. Based on what I see, there is a huge delay (almost 1 minute) with the Stock Ticker. Are you saying you don't see the same delay with the Hauppauge dongle?


Never tried it, but uninstalling VideoArchive (i.e. removing Stock Ticker in the process) fixed that. Back to normal...

k.

mvallevand
2007-07-29, 06:38 PM
I have uploaded a new alpha dongle to address problems where emulation mode and pvrx2 became out of sync and mvpmc would appear to freeze. Basically emulation mode is being a little too smart because it anticipate responses to the stop/ff/rw/skip and replay keys. This fix returns control to the server after about 1.5 seconds.

I have found it removes the following freezes

- FF/RW key hit not using the short skip option, note FF/RW are still not implemented in PVRX2 but at least the video will continue to play

- skip key hit near end of livetv

- skip key hit really early in a video.

Martin

pz1
2007-07-29, 07:50 PM
Martin,
does it make sense if I test this dongle under 99.12?
Pieter

mvallevand
2007-07-29, 08:23 PM
Martin,
does it make sense if I test this dongle under 99.12?
Pieter

I don't think it would hurt too much and I'm still willing to look at fixing things for 99.12 and this last change is a good one going backwards. My one big area of concern would be channel changing of livetv. Of course for stability you would also need to add the command line option --em-safety 3

I'd also like to see your comments, you do find a lot of little things that I don't notice.

Martin

ggee
2007-07-30, 02:29 AM
Great news. I'll give it a try too to see if it helps a littlewith my FF hangs.

Thanks,
Greg


I have uploaded a new alpha dongle to address problems where emulation mode and pvrx2 became out of sync and mvpmc would appear to freeze. Basically emulation mode is being a little too smart because it anticipate responses to the stop/ff/rw/skip and replay keys. This fix returns control to the server after about 1.5 seconds.

I have found it removes the following freezes

- FF/RW key hit not using the short skip option, note FF/RW are still not implemented in PVRX2 but at least the video will continue to play

- skip key hit near end of livetv

- skip key hit really early in a video.

Martin