Emulation mode testing Round III

[mvallevand]

I just had a chance to try out the 0423 dongle this evening and it worked very well. Channel changes are snappy, there was no video freezing and no loss of A/V sync. I changed channels in Live TV usning UP/DOWN, numbers and mini-guide and all methods worked equally well.
There were a few glitches. When a recording ended, I had to press a key to return to the plug-in screen. Likewise, when a scheduled recording began I had to press a key to get out of the stopped video. And once changing channels with the number keys I had to press a remote key to finish the channel change. There is still a shadowed screen that precedes the info screen, a little hiccup. But essentially this MVPMC dongle worked just as well for Live TV and playback as the Hauppage dongle, but with quicker channel changes.
Great work, Martin!

I'm sure you'd find a few it get out of sync several changes but I'm glad that in general channel changing is improving. The key at the end of video is definitely something I will tackle for the next alpha.

One question what is the info screen?

Thanks for the feedback.

Martin

[Luckerman]

One question what is the info screen?

I'm referring (inexactly) to the overlay with channel/program info that appears on pause or at channel change.

[mvallevand]

Just for the record: The last few days I did test the 0421 version. On my installation the LiveTV and Video stuff seemed better. I did however encounter a problem with Music Library 2(ML2). After two reboots and a reload of the dongle, the playlists always stopped after playing one (or may be in one occasion) two tracks. I did not observe that in the 0409 version. The standard GBPVR dongle still works fine with ML2.
pz

Based on your feedback I realised I made a change according to the file size that is invalid that is probably causing this problem. I'll have a look tonight.

As for the two reboots, I find in general emulation works much better when gbpvr jumps into the screen saver when I go into emulation. It might be that gbpvr hasn't initialised everything, or my startup code needs more tweaking (there is definitely one step out of sequence if you check the gbpvr logs) that I will also be looking at when I start with some Hauppauge server testing on the weekend.

Martin

[pz1]

As for the two reboots, I find in general emulation works much better when gbpvr jumps into the screen saver when I go into emulation. It might be that gbpvr hasn't initialised everything, or my startup code needs more tweaking (there is definitely one step out of sequence if you check the gbpvr logs) that I will also be looking at when I start with some Hauppauge server testing on the weekend.

Martin

Ah, probably I had to express myself better. What I intended to say is:
1) ML2 stops after 1 track
2) Even after a couple, of reboots _to make sure_ that I started with a clean machine (=no history of other actions), I still observed that ML2 stops after 1 track.

Thanks for the reply. I will wait and see for the next release.

pz

[mvallevand]

I'm referring (inexactly) to the overlay with channel/program info that appears on pause or at channel change.

I think I do this based on the command from gbpvr. There is a menu change with a colour from the config.xml (default 170) which I apply to all the screen. I assume this is some kind of dim command to get your attention. I seem to remember seeing the Hauppauge dongle doing the same thing. The reall annoyance is that it doesn't stay on very long. Maybe sub can tell me what I should be doing with this?

To reduce the annoyance factor if you made it almost transparent set the 170 to 2 or 3 (0 and 1 are reserved!) it would be barely noticable.

Martin

[jksmurf]

Previously I wrote

The channel changes and stuttery playback (low spec PC mine, so emulation working too hard?) makes it not as good as DONGLE_33_25032.BIN atm (for me) k.

Martin,

I guess there was a question in there :-) ... to me "emulation" implies it is not native f/w running the mvp, but f/w emulating the original mvp functions?

Does this mean that the faster your PC is, the better (read "smoother" the emulation works? I know from long ago that sub noted the mvp response with GBPVR is better with a faster PC, but does emulation mode make this work even harder?

I guess I'm wondering whether my attempts at testing of the dongle (and it does have some great features I would like) is somewhat thwarted at the outset due to my lowly system?

k.

[mvallevand]

Previously I wrote

Martin,

I guess there was a question in there :-) ... to me "emulation" implies it is not native f/w running the mvp, but f/w emulating the original mvp functions?

With sub's help on graphics side the hardware is now doing most of the real work, but I am emulating what I should do in between gbpvr and mvpmc. It's no doubt not as optimized as hauppauge, I guess a lot but the burden isn't transfered to your server.

Does this mean that the faster your PC is, the better (read "smoother" the emulation works? I know from long ago that sub noted the mvp response with GBPVR is better with a faster PC, but does emulation mode make this work even harder?

A few things could effect performance

1. In looking at your gbpvr logs (not just with mvpmc) I've noticed that you get what I think of as the ping/progress errors because your server can't respond to some heartbeat command fast enough to handle these calls synchronously. I've put some code in mvpmc to avoid these and that might get in the way. There is a command line switch --em-safety and if you pass it 0 all this extra checking is off. There is more chance that a collision will occur and you will get some exits to the mvpmc screen, but you probably get those with the hauppauge dongle. You might want to try this.

2. A slow server will make the OSD slower so I expect this might have some impact.

3. Finally there will some minor stutter between channels changes especially if capturing is slow but I would expect the biggest impact is network throughput. I can open a thread of testing this if you'd like.

I guess I'm wondering whether my attempts at testing of the dongle (and it does have some great features I would like) is somewhat thwarted at the outset due to my lowly system?

k.

I've tested emulation running the linux based vdr-mediamvp on an nslu2 so you've got to have a better machine than this. Unless you are running with some extreme cpu usage I think that mvpmc should work and I should remove the bottlenecks.

Martin

[jksmurf]

... It's no doubt not as optimized as hauppauge, I guess a lot but the burden isn't transfered to your server...

Cool.

.... I've put some code in mvpmc to avoid these and that might get in the way. There is a command line switch --em-safety and if you pass it 0 all this extra checking is off. There is more chance that a collision will occur and you will get some exits to the mvpmc screen, but you probably get those with the hauppauge dongle. You might want to try this.

I guess this means issuing some comands via tftp... :o ... I've only ever used it a few times in my life with 1/2 dead routers and bringing my NSLU2 back from the dead, I'll need to read up on it again.

I guess that's why I was chuffed to see the commands in the mvmpc web page, but I understand it doesn't save it?? e.g. start automatically in emulation mode doesn't save? Would this be able (when you get the save working?) to also be able to be issued via that http:// page?

Finally there will some minor stutter between channels changes especially if capturing is slow but I would expect the biggest impact is network throughput. I can open a thread of testing this if you'd like....

Oh yes please. Some network Syadmins etc might find this easy, but if it helps your testing (even though it's a bit of an aside) it'd be neat to see what I can do to make it better, although I guess everyone's topology is different. e.g. I run two WRT54GS's in WDS mode to my wired MVP...

...Unless you are running with some extreme cpu usage I think that mvpmc should work and I should remove the bottlenecks. Martin

The only time I have "extreme" CPU usage is after a show has been recorded and comskip is hammering away. I might try the run comskip DURING recording option to avoid this, but otherwise, no, it doesn't get run when we're watching TV.

k.

[mvallevand]

Cool.

I guess this means issuing some comands via tftp... :o ... I've only ever used it a few times in my life with 1/2 dead routers and bringing my NSLU2 back from the dead, I'll need to read up on it again.

No, to just test it to see if it helps do it via telnet. Login as root then type or cut and paste these
killall mvpmc
mvpmc --emulate ? --startup emulate --em-safety 0 &

I guess that's why I was chuffed to see the commands in the mvmpc web page, but I understand it doesn't save it?? e.g. start automatically in emulation mode doesn't save? Would this be able (when you get the save working?) to also be able to be issued via that http:// page?

Using the mvpmc share option is definitely the easiest solution for know. Don't bother with tftp

Oh yes please. Some network Syadmins etc might find this easy, but if it helps your testing (even though it's a bit of an aside) it'd be neat to see what I can do to make it better, although I guess everyone's topology is different. e.g. I run two WRT54GS's in WDS mode to my wired MVP...

I'll try and make it straight forward and maybe through the web page but you would need the share for the best results.

The only time I have "extreme" CPU usage is after a show has been recorded and comskip is hammering away. I might try the run comskip DURING recording option to avoid this, but otherwise, no, it doesn't get run when we're watching TV.

k.

That's positive.

[mvallevand]

Ah, probably I had to express myself better. What I intended to say is:
1) ML2 stops after 1 track
2) Even after a couple, of reboots _to make sure_ that I started with a clean machine (=no history of other actions), I still observed that ML2 stops after 1 track.

Thanks for the reply. I will wait and see for the next release.

pz

I've uploaded a new dongle to address the 1 track issue. I'm pretty sure it was the file size problem. As for rebooting the power off really does a good job of cleaning memory, you should rarely have to do more than that unless the video thread really became corrupt.

Martin