Emulation mode testing Round III

[mvallevand]

Martin,

I can now confirm this is not a one off problem but has now happened several times.

Sorry I didn't reply to your original post. I have been looking into it from the symptoms it didn't sound like it would be "one-of" but I haven't found what would cause the deadlock.

It is intermittent and unpredictable but basically appears as either the first track stops playing when the screen saver kicks in but if just press a button

This is what I've been testing, but I haven't had it happen in about 20 attempts. I will have more time tonight. The Americans like hockey in the afternoon.

I have spent the day running gbpvr in debug mode, ML2 with insane amounts of logging, and running your test dongle capturing the putty log and of course the problem has not occured.

Rather then server side, to really diagnose this the mvpmc client side debug logs are probably necessary. There some instructions around that I would have to find.

But I have noticed that the display in the putty output always show the same size and bit rate for the mp3 file " bps 192 length 5695866 dropoff 0"

That's just a perk of gbpvr. It caused me a problems in emulation a year ago because I kept waiting for those remaining bytes, but I understand the protocol better now and don't need it. It's also too bad that this is shortnames, I could add fancy stuff to the vfd http://www.mvpmc.org/mvpmc_hardware_howto.html#s9

Thanks for the feedback, and again sorry for not replying earlier. The game is about to restart ...

Martin

[tkgafs]

Hi Martin,

after several hours the freeze happened.

I pressed go go to activate screen to see the title of the track

when the screen saver re-activated the music paused

the following was in the putty.log

Done with audio file
23:22:21 bps 192 length 5695866 dropoff 0
Starting to play audio file 'Q:\Music\Include\FRANZF~1\07-ELE~1.MP3'
mvpmc: read: Bad address
Error updating screen
Skipped 2 bytes
mvpmc: unknown message type 120 from VNC server
Error updating screen
Skipped 1071 bytes
4095719 Remaining 1600147
Done with audio file
23:25:49 bps 192 length 5695866 dropoff 0
Starting to play audio file 'Q:\Music\Include\VARIOU~1\GREATE~1\CD1\21-CHR~1.MP3'



one attachment is from gbpvr debug level log, the time on the mvp seems to be about 41mins slower than the server time [can it use ntp by the way]

so the gbpvr time is approx 12:03

the other is from musiclibrary2 covering the same period

hope this helps

tkgafs

[mvallevand]

Hi Martin,

after several hours the freeze happened.

I pressed go go to activate screen to see the title of the track

23:22:21 bps 192 length 5695866 dropoff 0
Starting to play audio file 'Q:\Music\Include\FRANZF~1\07-ELE~1.MP3'
mvpmc: read: Bad address
Error updating screen
Skipped 2 bytes
mvpmc: unknown message type 120 from VNC server
Error updating screen

Thanks. Those skipped 2 bytes are the same things that caused all the ping problem up to now, also shown in the gpbvr logs, (the ping corrupts the video buffer)

2007-05-20 12:03:19.187 VERBOSE [25] MVP data read: 1 (9)
2007-05-20 12:03:19.187 VERBOSE [25] MVP request processed
2007-05-20 12:03:19.234 VERBOSE [27] Y/Y2 buffer: 2674 bytes
2007-05-20 12:03:19.250 VERBOSE [25] MVP data read: 1 (8)
2007-05-20 12:03:19.250 VERBOSE [25] Responding to ping
2007-05-20 12:03:19.250 VERBOSE [25] MVP request processed
2007-05-20 12:03:19.296 VERBOSE [27] U/V buffer: 1072 bytes
2007-05-20 12:03:19.296 VERBOSE [27] incremental frame sent

It isn't completely an mvpmc problem, but I thought I had handled them all. This will help me quite a bit thanks. It make sense to free anything waiting for the ping when these errors come up. There is a new alpha to address this.

one attachment is from gbpvr debug level log, the time on the mvp seems to be about 41mins slower than the server time [can it use ntp by the way]
so the gbpvr time is approx 12:03

FYI, without actually setting the mvp's time to an ntp time source in the dongle.bin.config script the times will not typically match

Martin

[mvallevand]

Sorry, it is just wrong what I said. I had the machine switched of because we had guests over who were using my 'GBPVR server room' (That's the luxury you get when the kids have left home ). So the machine was off, and I did not properly check the events. It is indeed the menu as Hans says, and indeed the video inset is at the right hand side.

I think I have addressed this in the 0520 alpha. Let me know how it works for you. If this works and tkgafs's problems improve a bit, I want to open a round 4 thread.

Martin

[pz1]

I think I have addressed this in the 0520 alpha. Let me know how it works for you. If this works and tkgafs's problems improve a bit, I want to open a round 4 thread.

Martin

will give it a try tonight or tomorrow.
Pieter

[HtV]

I gave the latest alpha(20-05) a try:

-when you go from livetv to menu now works ok, video in inset onnthe right.
-But when from there you go to recordings, you get the little inset on the lower right, ok. When you start a recording it starts in the little window and you can't stop or pause it, if you push the menu button you go back to the menu (with inset), menu button again, you get fullscreen video , but no buttons work anymore. Then the mvp locks up with a still from the video. Only way out is restart mvp. I tested this several times.
Now I got kicked off the tv. So no more testing for the moment.

cya Hans

[mvallevand]

I gave the latest alpha(20-05) a try:

-when you go from livetv to menu now works ok, video in inset onnthe right.
-But when from there you go to recordings, you get the little inset on the lower right, ok. When you start a recording it starts in the little window and you can't stop or pause it, if you push the menu button you go back to the menu (with inset), menu button again, you get fullscreen video , but no buttons work anymore. Then the mvp locks up with a still from the video. Only way out is restart mvp. I tested this several times.
Now I got kicked off the tv. So no more testing for the moment.

cya Hans

Thanks Hans, none of this behaviour is new and I thought it was the same with the Hauppauge dongle. This is on a list of things I test all the time. With the Hauppauge dongle I didn't think any keys other than menu navigation worked while in inset mode and they also seem to queue up and when you return to full screen a lot of unpredictable things happen.

I also found mvpmc wasn't hung it just has to wait a while for gbpvr to start re-streaming and it can take 10 seconds or more.

I haven't done a lot of comparison with the Hauppauge dongle on this recently because inset video doesn't work as well for me on Vista.

Martin

[HtV]

Thanks Hans, none of this behaviour is new and I thought it was the same with the Hauppauge dongle.

I didn't know that, I never use the menukey :o , I only use the menukey now while testing the mvpmc-dongle. To be honest, until a few days ago I was under the impression that I had turned off the inset-video. Must have been turned on again when I did a complete re-install a while ago. I do know that I turned it off then because it gave me trouble, well that makes sense now.
If the tv-set is available I'll try out the hauppauge dongle on this.

I also found mvpmc wasn't hung it just has to wait a while for gbpvr to start re-streaming and it can take 10 seconds or more

This could very well be true, I don't think I waited that long, probably pushed some more buttons.

But as I said the black screen with the video-inset is cured.

cya Hans

[pz1]

As expected for me the black screen with the video-inset has been cured too.

[mvallevand]

As expected for me the black screen with the video-inset has been cured too.

Pieter/Hans thanks a lot. The problem wasn't quite how I described it, it relates more my misunderstanding of the logic of how and when to request screen updates while video is playing.

Martin