Comskip after pressing Blue button

[Jaggy]

I know you are no longer enhancing mvpmc as such, but I have a small problem that doesn't happen with the Hauppauge dongle. But having said that all the problems I was having with the MVP going into widescreen mode on my 4:3 tv (a real pain) & connecting at times with it I don't have with the mvpmc dongle

I have automatic comskip turned off as I haven't been able to find a decent comskip.ini for NZ. Normally I just hit the blue button to see how comskip has marked things & if it looks right hit the play button or if it looks wrong hit the skip button, this works fine with the Hauppauge dongle but mostly there is a huge delay if it works at all I haven't been able to confirm what it does as I normally end up hitting the skip button & end up well passed the adds into the recording. If I just hit play when it gets to an add break & if comskip has marked things right it works fine. Any ideas??

[mvallevand]

emulation mode isn't as fast with the OSD but "huge" delays surprise me, I only notice sub-second delays. As for skip taking you past the commercial point I have never tested comskip files with the MVP so I don't know what this means or where is supposed to take you. mvpmc just sends the keys when they are hit and plays the video that GBPVR streams.

Martin

[Jaggy]

It isn't comskip that is taking me past the commercial point it is because nothing seems to happen when I hit play I always end up hitting skip as well & then it decides to do both comskip & skip.

The delay is fairly large defiantly much more than sub-seconds. I have been using an MVP for long enough to know there is no advantage in trying to hurry it up, I learned that was a waste of time really early on.

[mvallevand]

Upload your logs and I will have a look to see if I can find anything.

Martin

[Jaggy]

I assume it will be best if I set it back to only starting 1 mvp server first before I try to reproduce the fault & upload the logs?

[mvallevand]

It is easiest that way.

Martin

[Jaggy]

It will be a day or two before I can get to kill the other mvp servers & try to reproduce the problem to get logs, I seem to have become rather busy again at the moment.

Typically, I took extra note tonight while we were watching & every time it worked 100% fine, so I will just monitor it for a while & see if I can come up with a patten for when it goes into slow mode.

[mvallevand]

If it is an intermittent problem that is slightly different. If you can't come up with a repeatable pattern I don't need logs. There is a known issue with emulation mode where the remote seems to just take a siesta and commands don't seem to get passed. Earlier this year sub and I spend hours trying to determine the cause and the end result was that both the client and the server were operating well at the application level, and it is the TCPIP layer where things were hung up.

Other users have helped by sending ethereal capture and debug logs from mvpmc but nothing stands out. Because there is no QoS in the Hauppauge protocol, it is almost like trying to figure out the reason why a web page can be slow to open at times.

It is known that the network "card" in the MVP is terrible so it is the likely cause but I have resigned myself that this problem is never going to be diagnosed. The PCH has a better but not perfect network card. Neither of them can do 100Mbs, but on my network it can hit 45Mbs compared to 12 Mbs on the MVP, and I have never experienced this "lost" remote issue. For me this is the solution.

Note that the Hauppauge dongle resolves several issues by "crashing" on timeouts however because it goes back to the MVP blue screen and quickly restarts a session it is sometimes less apparent. This is not a strategy I want to take.

Martin