Livetv restart

[trummel]

i've played with using ts mux for a couple of days now. It works ok with the NMT, and the restating problem has gone away. But - isn't there always a but! The MVP's will play the .ts files, but the lack of any kind of ff or rew means that it is not a suitable substitute for the files created with the cyberlink mux.

So It's back to trying to diagnose why the combination of NMT/cyberlink causes the skip. Recorded programs don't have a problem nor does live tv on a PC client or on an MVP.

Mux checker reports:-

Found: CyberLink MPEG Muxer
FILE: c:\windows\system32\MpgMux1307.ax
VERSION: 5.0.1307

Any suggestions?

[mvallevand]

The problem doesn't sound like it is PCH related. Navigation on files on the MVP is a function of GBPVR and I guess GBPVR works better with Cyberlink muxed files, it doesn't mean the MVP can actually play the file better than the PCH can. I would take the file that doesn't play on the PCH and run a basic

ffmpeg -i input.mpg -oac copy -ovc copy output.mpg and if this output file plays on the PCH the problem is Cyberlink.

Martin

[trummel]

It is only a problem whilst it's live (time shifted). If i grab the file that was created from the livetv folder and play it with NMT from my video's folder, it plays without error. Parsing it with ffmpeg changes the size slightly, but it also plays correctly.

[mvallevand]

Sorry, I've been a bit dense on this whole thread. I have experience the same scenario and I am not sure what the best work around is. When a TS file is being recorded, I have noted that there is no consistency on the timeline when programs change. Therefore it is possible that at the very end of a program, before the GBPVR tells the PCH to change files (the 8 second delay), the PCH sees a bad timeline and resets to the beginning of the file. At the same time the recording service does start recording the new show so two files exist. I'm not sure if your scenario is exactly the same but when the reset happens I hit a stop and then the new show starts. I remember leaving the PCH on one day in testing and it looped on one show for an evening as 7 or 8 eights hours of new shows were recorded and deleted.

Martin

[trummel]

It might be connected except - it's using cyberlink mpg not .ts files and it happens in the middle of a program (or anywhere for that matter), usually within a minute or so of starting to watch it.

[mvallevand]

I think I have the explanation to this. The http server has to trick the server into thinking there is a steady stream of data when it is first loading because the PCH wants 8 MB of data before it even starts playing. If the PCH doesn't receive the data in a certain period of time it will loop on its internal buffer data. Because the Cyberlink mux is caching writes there probably is enough of a delay for this initial load to fail.

You can confirm this by recording a program and time shifting it by about thirty seconds. If my hunch is correct it should play fine.

Martin

[trummel]

So is it worth increasing the pre-play delay? and if so which one?

[mvallevand]

I have no idea, I don't bother with the Cyberlink mux because digital broadcasts here have ac3 audio.

Martin

[trummel]

Just to close this off, I found that fiddling around with the preplay delays didn't make an obvious fix, however swapping the version of the Cyberlink Mux from 5.0.1307 to 5.0.2022 seems to have cured it.