Help with emulation mode.

[jksmurf]

Martin,

I was going to do another test for you, but wanted to check something

Does the mvpmc file from http://www.mvpmc.org/~mvallevand/mvpmc.zip need to be d/l again following each new dongle release? I remember I had an old version last time, this (mvpmc) one is dated 16 Dec, but the Alpha Dongle is dated 20 Dec (File Datestamp, not the filename which is 21st)

k.

[mvallevand]

K you are right, I have now updated mvpmc too.

Martin

[jksmurf]

K you are right, I have now updated mvpmc too. Martin

Here you go, using sub's PVRX2.exe test file above, mvpmc just uploaded today, 21/12 dongle, datestamps done, putty log attached.

I had a couple of instances of non-reactive remote last night, and a couple at the START of this test, but generally the test was pretty good. Probably nothing in the logs for you to troubleshoot! Always like that during a test. Seriously though, sometimes it (the remote) just seem doesn't respond.

I did a few Go OK's, some scrolling around, some looking at some movies, in out of Plugins, FF, Skip, etc.

k.

[Turas]

today i started with tests again, using pvrx2-logging version and newest alpha-dongle.

soon after startup, when scrolling in tvguied - i ran into a completely stuck remote.

looking at the logs i found that i had some problems with mlupdate (ml2 is the only plugin i've currently enabled). mlupdate produced a huge amount of logging at the time the remote got stuck. at that time mlupdate had been configured to use the internal-updater which probably uses resources of pvrx2?. so the remote probably has been "stuck" because of pvrx2 being busy with plugin-logging... (btw: i already switched to external-update and solved other problems with the plugin for next tests i will do!)

i think i can remember a previous post where sub said, that a reason for pvrx2 not sending the requested data / response in time could be, that the responsible pvrx2-thread is not getting the needed cpu time... in the case today this seems to be exactly the reason. therefore on the mvp/mvpmc-side nothing could have been done to avoid the "stuck" remote.

@sub: is there a way to prevent plugins from "stealing" too much cpu-time from the mvp-gui-handling? e.g. running the mvp-gui-handling in a separate thread - maybe even with a higher (configurable) priority? (don't know if this is already done, or if it's possible at all...)

br turas
---

[Turas]

some further results.
(still have to fix problems with ml-updater...)

-) mvpmc really stable, no single remote problem occured.

-) no problems with livetv and switching channels

-) ff/rewind sometimes get stuck on play-video (go/ff-go/rewind) seem to be a bit more stable concerning that.

-) rewind, when playing back a show currently being recorded, always got stuck. when you invoke osd in such situation, it indicates you are at the end of the recording which is not true. can be solved by pressing play sometimes.

-) when having problems with ff/rewind, it happens that the upper part of osd (showing the progress) is not displayed at all. solved only after stopping / playback again.

some thoughts about handling ff/rewind and channel-changing (should go into another thread probably)
=> would it be possible to make ff/ rewind "less fluently" by displaying not so many pics and doing kind of "mini-skips" instead. maybe even make it configurable or increasing the "pic-skip-rate" with each press of ff/rewind (= making it a bit faster with every key-press)?

as far as i remember the hauppauge-dongle is doing the ff/rewind a bit faster
(not saying that the hauppauge is at any rate better!!! already realized the value of mvpmc... )

=> could some key of the remote be used for switching back and forward between the current and previous tv-channel?
(e.g.
- watching channel 1,
- selecting channel 10 manually with "10/ok"
- pressing the remote-button switches to channel 1 again
- pressing the remote-button again switches to channel 10 again
-...)

logs attached.
br turas
---

[mvallevand]

Here you go, using sub's PVRX2.exe test file above, mvpmc just uploaded today, 21/12 dongle, datestamps done, putty log attached.

I had a couple of instances of non-reactive remote last night, and a couple at the START of this test, but generally the test was pretty good. Probably nothing in the logs for you to troubleshoot! Always like that during a test. Seriously though, sometimes it (the remote) just seem doesn't respond.

I did a few Go OK's, some scrolling around, some looking at some movies, in out of Plugins, FF, Skip, etc.

k.

k, it looks like your gbpvr verbose server side logging got turned off again at 14:55:13 with one of your converter3 errors which is before any problems occurred. I think xrecord is either turning logging off itself or corrupting memory which leads to other delays.

I have no doubt that gbpvr's responses to mvpmc get blocked somehow. The only good thing is that I hsve yet to see a log that indicates mvpmc is dieing during the unresponsive period. My only fear is this is more a network or o.s. issue with tcp and QoS that sub or I can't control.

Martin

[mvallevand]

some further results.
(still have to fix problems with ml-updater...)

For the this first test you also hit the remote key too early after startup.

-) mvpmc really stable, no single remote problem occured.

-) no problems with livetv and switching channels

Since you AutoStart two servers, you were running the server that did not have server side logging on. Unlike Arne I find that with reduced logging I get improved performance and unfortunately it is a much harder to debuf

-) ff/rewind sometimes get stuck on play-video (go/ff-go/rewind) seem to be a bit more stable concerning that.

Go FF is just 2x play so it should only stick because of bandwidth. Go Rewind is just rewind.

-) rewind, when playing back a show currently being recorded, always got stuck. when you invoke osd in such situation, it indicates you are at the end of the recording which is not true. can be solved by pressing play sometimes.

-) when having problems with ff/rewind, it happens that the upper part of osd (showing the progress) is not displayed at all. solved only after stopping / playback again.

These look like server side issues.

some thoughts about handling ff/rewind and channel-changing (should go into another thread probably)
=> would it be possible to make ff/ rewind "less fluently" by displaying not so many pics and doing kind of "mini-skips" instead. maybe even make it configurable or increasing the "pic-skip-rate" with each press of ff/rewind (= making it a bit faster with every key-press)?

Do you mean the short skip option on the Misc screen?

as far as i remember the hauppauge-dongle is doing the ff/rewind a bit faster
(not saying that the hauppauge is at any rate better!!! already realized the value of mvpmc... )

There's no question that Hauppauge does this much better. When I first started this the mvpmc demux didn't even handle the special GOP mpegs that were being sent and I still can't figure out how to avoid the black screen that happens on and off. I find that the Hauppauge server does a better job too, but I think most GBPVR users use short skip anyway

=> could some key of the remote be used for switching back and forward between the current and previous tv-channel?
(e.g.
- watching channel 1,
- selecting channel 10 manually with "10/ok"
- pressing the remote-button switches to channel 1 again
- pressing the remote-button again switches to channel 10 again
-...)

The new remotes have a previous channel key.

Thanks, and note in one of your logs MVP-PVRX2.exe-3.log at 12:06 there is what I consider a classic timeout with a screen update and heartbeat both dead on the gui stream but there is no client log to help. What's becoming apparent is the timeout is not random, it is thirty seconds.

Martin

[Turas]

For the this first test you also hit the remote key too early after startup.

i'll remember that one. is there a message appearing on telnet-log to indicate that remote can be used?

Since you AutoStart two servers, you were running the server that did not have server side logging on. Unlike Arne I find that with reduced logging I get improved performance and unfortunately it is a much harder to debuf

corrected that one already

Do you mean the short skip option on the Misc screen?

no. short skip uses at least 30seconds between steps and most important it isn't automatically done repeatedly without pressing the button again.
what i mean is just skipping some pics (if possible at all e.g. 1s or 2s, ...) and when you press the button again e.g. doubling the skipping (e.g. 2s or 4s, ...)
that's how my "old vcr" did it and i really liked it

The new remotes have a previous channel key.

ok. but i still have an old one. would be reeeaaly nice if the "empty-key" between "mute" and "full" could be used for that?

br turas
---

[mvallevand]

Since I don't know why GBPVR doesn't respond if the the keystroke is early, I just count 8 seconds. It definitely shouldn't be before the first Handle ping.

I don't think the short skip has to be that long people have posted their setting. For PVRX2 on PC I think only short skip is supported, that's why I allowed the GO FF.

The next alpha will have Go ChannelUp set to prev channel.

Martin

[Turas]

played music for a while using musiclibrary2.
when i tried to stop and return to main menu a hang occured. music stopped but i couldnt go back to mainmenu.

happened about 17:50 - 17:53

br turas
---