New alpha dongle Dec. 04

[mvallevand]

Server side is fine, I don't think I've seen any for 1.1.5 anyway. Also when the remote stops responding make sure you try these two mvpmc key combinations:

Go FF - this turns on the mvpmc mode of fast forward and being client side only it shows the client is working ok. Not so useful with livetv

Go Ok - this turns off a lock I have preventing extra keys from queuing up when gbpvr stops responding to a client heartbeat command. Afterwards try your key again. This sounds hopeful but it does nothing for me.
The purpose of the exercise IMHO is to determine why this happens. I could make mvpmc more like the Hauppauge dongle and reboot in this situation but that doesn't sound appealing.

Martin

[mvallevand]

I tried for an hour to get the no response issue and couldn't but I did find that video was sticking after a resume/restart once in a while. I noticed that I had a command in there from the Hauppauge protocol that I used to see in sniffing the traffic, that I don't understand anyway so I took it out. I still have to do some tweaking of this because I still find that I have to unintuitively hit the pause key after a restart to get the video to play when it does not respond. This probably applies to all dongles.

Martin

[Sheik Yerbouti]

Hi Martin,

It happened again this afternoon, and I see these lines in the mvplog from gbpvr:

Code:

2007-12-09 17:45:33.142    ERROR    [6]    error sending incremental frame: De externe host heeft een verbinding verbroken
2007-12-09 17:45:33.142    VERBOSE    [6]    MVP request processed
2007-12-09 17:45:33.142    VERBOSE    [6]    MVP waiting for data
2007-12-09 17:45:33.142    ERROR    [6]    handleMVPConnection() exception: De software op uw hostcomputer heeft een verbinding verbroken
2007-12-09 17:45:33.345    VERBOSE    [6]       bij System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
   bij System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 size, SocketFlags socketFlags)

   bij GBPVRX2.MVP.x3ca133dee7547455.x3d75adb3418c5c9e()
   bij GBPVRX2.MVP.x3ca133dee7547455.xd3faf5962405de4e()
2007-12-09 17:45:33.345    VERBOSE    [6]    MVPSendStopRequest()
2007-12-09 17:45:33.859    VERBOSE    [6]    EnableScreenSaver()
2007-12-09 17:45:33.859    VERBOSE    [6]    getValue cached value: /settings/ScreenSaverEnabled : true
2007-12-09 17:45:33.859    VERBOSE    [6]    ForceRepaint()
2007-12-09 17:45:33.859    VERBOSE    [6]    UiList.GetRend

The Go button doesn't seem to work on my remote, so I can't help you with that at this moment. I do have another remote laying around somewhere, so I'll try it sometime in the near future.
Unfortunately I don't know if this log message is the reason the MVP doesn't respond, or if it's because I've turned off the MVP after it stopped responding. I believe that with the Hauppauge dongle this message meant a reboot of the MVP. I have tried the latest Hauppauge dongle for Vista, and I haven't seen the 'no response'-behaviour, but it gave a lot of reboots. To end with a positive note: This is the only problem I'm having with the mvpmc dongle

[Turas]

i'm using the alpha-mvpmc dongle now and it's for sure much more stable than the hauppauge-beta-dongle i've been using before. since the hauppauge dongle did reboot from time to time it's a probably a good assumption that hauppauge "resolves" the "stucking remote", or other problems with a reboot.

i've just had the time for one test yesterday doing live-tv / channel changing / forward / rewind,... test ended with complete video / mvp frozen. guess that's more a gbpvr / multi-receiver problem than a dongle issue.

for this test i used the method from:
http://forums.gbpvr.com/showpost.php?p=1...stcount=37
logs attached.

in the morning i just let "net-radio" play for about 15 minutes. when i returned the remote was stuck. but i didn't have time to collect the proper logs.

br turas
---

[mvallevand]

Hi Martin,

It happened again this afternoon, and I see these lines in the mvplog from gbpvr:

Thanks Sheik, those logs don't show want I want, I'd need it back to where I think would see the sockets get blocked which I think relate to "Responding to ping" and "MVP data read: 1 (9)" log messages. For me it's easier just to get the entire log in case there is something else.

However your log snippet is interesting because GBPVR seems to continue to use the same rfb socket after it gives the remote host dropped connection message which doesn't make a lot of sense. Are you running from the command line and not auto-starting a server?

Martin

[mvallevand]

for this test i used the method from:
http://forums.gbpvr.com/showpost.php?p=1...stcount=37
logs attached.

Thanks Turas. This looks like you did do good test. If you are going to use that method which really really really helps me, that's great but you didn't quite get the syntax right. If you want to run without typing out /etc/mvpmc/mvpmc and instead change directories you need to use ./mvpmc to tell it to run the app from the current directory. It would help if after killing mvpmc you set the time with

rdate -s "ntp server" where the ntp server is your choice.

This ensures the seconds in both logs will be the same.

As for your logs, it looks like your logs end in xarchive not in gbpvr. I don't do any testing with xarchive but if this is something you use a lot it might be the partial source of the problem. I also don't like the looks of those errors on some of your plugins either, I'm not sure what does that the the state of the server but that might be nothing.

Regarding the net radio problem, I know if you hit a key too early in emulation mode the remote is guaranteed to hang later on which I'm pretty sure is an initialization timing issue in pvrx2, similar to the crash if you close PVRX2.exe too early. For me I have used the time of the last BuildChannelProgrammeIndexHints as a rule of thumb to tell me what I consider too early, however for you that took almost thirty seconds (and not my eight), so I am going rethink this.

Martin

[mvallevand]

I have fixed one problem with the pause on resume and have uploaded a new alpha. The command to pause a/v was sometimes getting flipped around if multiple plays and stops are received it might fix other problems too. if you use pause a lot I feel this is definitely worth trying.

Martin

[Sheik Yerbouti]

However your log snippet is interesting because GBPVR seems to continue to use the same rfb socket after it gives the remote host dropped connection message which doesn't make a lot of sense. Are you running from the command line and not auto-starting a server?
Martin

Martin, I'm auto-starting two servers and not running from the command line. However, I've read your post to Turas, and now I'm running the debug version of mvpmc. So now we'll just have to wait for the problem to show up. Is autostarting two servers a problem?

[Turas]

As for your logs, it looks like your logs end in xarchive not in gbpvr. I don't do any testing with xarchive but if this is something you use a lot it might be the partial source of the problem.

since my latest tests showed some errors with plugins again i'll disable all of them before doing the next tests.

mvpmc was quite stable during these tests.
- 3 reboots when changing net-radio-channel; but i think that's been a plugin error.
- "seems-to-hang" during onscreen program-guide. stuck for 10-30s; then the commands from the remote were executed one after another.

however for you that took almost thirty seconds (and not my eight), so I am going rethink this.

maybe that's because i have quite a large xmltv-guide to load - using full descriptions instead of short ones for the shows (~25MB).

will load the new alpha now.
br turas
---

[HtV]

Hi Martin,

Loaded the latest alpha, did some heavy testing with netradio, livetv, ML2, lot of skipping channelchanging etc etc. Sorry can't help you, no problem whatsoever.
I was very pleased with the almost instant skipping in ML2, may have been like this before but haven't used it much, let alone the way I did tonight.
So, another great release, thanks alot again.

cya Hans