Help with emulation mode.

[mvallevand]

I have uploaded another alpha dongle and debug mvpmc that tries and prevents the situation that sub's increased logging indicated. I'm not sure if it fixes any other remote death problems, but I can no longer recreate the situation I discussed earlier in this thread.

Martin

[jksmurf]

Martin

Do you still need logs produced with sub's test PVRX2 and the new 16th Dec dongle?

k.

[mvallevand]

Yes, please, if you have a dead remote I would. The problem I was addressing was not something I ever saw in your logs.

Martin

[Arnes]

Yes, please, if you have a dead remote I would.

I have sometimes a dead remote: Nothing happens when I issue commands and after some seconds suddenly they are executed all at once. I would help out with logs as well. I've read http://forums.gbpvr.com/showpost.php?p=1...stcount=37
and have a few questions.

• Is the mvpmc linked in that post still needed? I have the 2007-12-16 release.
  
• How do I copy that file to the mvp? I only use GBPVR to boot the mvp. Do I have to install a DHCP/TFTP combo for that? I'm running vista.
  
• What "are all my other startup options" for mvpmc? May I use what the ps command lists on the mvp? (-c 192.168.0.1 --vlc 192.168.0.1 --emulate ?)
  

I've especially observed the effect, while playing files recorded with my AverMedia M778 card. Popping up the status (blue button) often, or seeking when it's still open is almost a guarantee for blocking the remote for a while.

Files recorded with my other card (Hauppauge PVR 350) do much better.. and obviously it's on top of the recording source list .

Arne

[mvallevand]

TFTP is only used to load the dongle, once it is loaded the mvp is simply a linux machine on your network. When you run the debug mvpmc to help in testing I ask that you run it directly from a share rather than flash, it definitely doesn't need a tftp or a poweroff.

You command line is fine and you can certainly copy it from ps or alternatively what I do is type cat /etc/dongle.config to display the command line. Either way saves a bit of typing.

It is interesting that you find files captured from one source behave differently I suspect that it is just coincendence or too small a sample size, but it is possible that when you have two tuners on the go extra stress is on the server causing the delays and I will watch for this.

One other thing to point out, don't use the Go OK more than once to queue up commands, if there isn't a change after the first try, it's not going to help it can only make things worse.

Martin

[Arnes]

TFTP is only used to load the dongle, once it is loaded the mvp is simply a linux machine on your network. When you run the debug mvpmc to help in testing I ask that you run it directly from a share rather than flash, it definitely doesn't need a tftp or a poweroff.

Sorry, I haven't seen the wood for the trees. :-) Off course it's easy to load something from a share when the OS on the MVP is running.

So I have here one mpg file from the AverMedia and all I have to do is open up OSD and then seek a few times. I've switched GBPVR to debug level logging, then - funny enough - I have to try more, but finally the the mvpmc log reads something like:

18:31:06 Ping stuck avoid Keystroke 0 2 901

I have attached the logs. The mvp is rdated and is 7 hours and one second before local time and server - about 1:45 AM now.

It is interesting that you find files captured from one source behave differently I suspect that it is just coincendence or too small a sample size, but it is possible that when you have two tuners on the go extra stress is on the server causing the delays and I will watch for this.

Off course this recording was done while recording another show and probably playing one of the two time shifted. But by the time I did this test there was no additional load and the machine is new and quite well equipped (2GB RAM, 2.4GHz Core 2 Duo, very fast Raid-0 disks).

If any additional tests may help, I'm willing to do more, but first have to sleep and work.

Arne

[mvallevand]

Arnes, I'm going to need you to use the PVRX2.exe that sub has posted on this thirty. It looks like it took thirty seconds for the heartbeat response to what mvpmc sent at 31:00 and it that same time. This is a different from the problem I was having, and I now think that either mvpmc or GBPVR is having trouble when the separate mvpmc media stream and hearbeat threads send the (9) and (8) commands too close together.

Martin

[Arnes]

Arnes, I'm going to need you to use the PVRX2.exe that sub has posted on this thirty. It looks like it took thirty seconds for the heartbeat response to what mvpmc sent at 31:00 and it that same time. This is a different from the problem I was having, and I now think that either mvpmc or GBPVR is having trouble when the separate mvpmc media stream and hearbeat threads send the (9) and (8) commands too close together.

Sorry Martin,

I tried for an hour, but I can only reproduce the problem when setting the GBPVR logging to error level. On debug there is no way here to block the remote with the PVRX2 version sub posted here.

Arne

[mvallevand]

Arne, don't say sorry, it is kind of why this problem is so hard to diagnose, I think it's more a timing issue then a specific bug in code and I'm trying to figure a way around it. I know that last alpha didn't get it right, it actually causes too many slow downs and I don't really think it avoids the problem.

My gut feeling is that somewhere along the way there is a collision when mvpmc sends a heartbeat every five seconds, a stream progress indicator which can be four times a second, and the remote key which happens randomly all out on the same socket from 3 separate treads and then read by gbpvr on (I think) one thread.

Martin

[mvallevand]

I really didn't like the performance of the last alpha dongle especially during live tv. This new dongle just locks outboad rfb socket traffic to potentially slow the flow to GBPVR a little bit if GBPVR can't keep up. Let's see if this helps?

Martin