NPVR TS mux, is it less stable than proprietary Windows muxes?

[Braklet]

Still experimenting with my NPVR installation migrated from GB-PVR 1.4.7. I just recorded a program from an ATSC OTA (USA) channel, and edited the recording using my standard tool (VideoRedo), deleting commercials and remuxing to MPG containers.

This TS recording seems to experience a lot more periodic dropouts than I was used to with GB-PVR and the DVR-MS mux. This wasn't an exhaustive test and there are very good reasons to use Transport Streams, but now I wonder if Microsoft provided additional data massaging with their proprietary mux.

Is there any way to set additional parameters to improve TS performance, maybe increase buffering or something?

Still in n00b stage when it comes to NPVR... TIA.

[sub]

The TS mux is just an dump of whatever the card delivered. The app isn't doing any fancy manipulation of the data. I'm sure any drop outs you're getting are not caused by the ts mux, but the signal.

[mvallevand]

Yes dvr-ms files do include proprietary timecode information that makes for potentially better edits and skipping, but they can't repair broken video streams.

If you goal is to cut commercials and play mpeg-ps files, NextPVR isn't as good as GB-PVR, as it is not relies on Windows for playback. npeg-ts is a better target in 2013

Martin

[Braklet]

any drop outs you're getting are not caused by the ts mux, but the signal.

I'm sure that is the case, but I also suspect that the DVR-MS system resources provide an additional layer of error recovery not possible with TS.

Way back when, I experimented with the TS mux as I was tracking down some ATSC channel tuning bugs and needed access to all streams. As I recall it acted in much the same way with periodic data interruptions.

As an additional experiment I ran both NPVR and GB-PVR recording services simultaneously, and scheduled a 30 minute NPVR recording on one ATSC channel immediately followed by a 30 minute GB-PVR recording on the same channel. The NPVR TS recording revealed occasional data munging, while the GB-PVR DVR-MS recording remained stable.

Is there any provision within NPVR for alternate MUXes, maybe just for debugging?

[sub]

Is there any provision within NPVR for alternate MUXes

No there isn't.

[Braklet]

If you goal is to cut commercials and play mpeg-ps files, NextPVR isn't as good as GB-PVR, as it is not relies on Windows for playback. npeg-ts is a better target in 2013

I never liked DVR-MS containers but this morning's experiment proves to me that it has advantages over a raw transport stream. Whether transport stream is "better" remains debatable; I notice that MythTV's recordings also use a program stream mux and produce MPG files.

I don't mind the signal glitches for timeshifted-then-deleted material but I still record OTA stuff occasionally for archiving. Unless there is some sort of TS timecode repair tool (VideoRedo didn't seem to fix it) I may have to stick to GB-PVR and think of some other way to tie in my Raspbmc client.

Note that my standard operating procedure for DVR-MS recordings is to edit commercials out with VideoRedo and re-mux to program streams in MPG containers. I then modify gbpvr.db3 to point to the new version. I still don't particularly care for DVR-MS but am forced to stick with it if the recordings are better quality.

[johnsonx42]

Some folks seem to use TSDoctor to fix up messy transport stream recordings. It's not free, but it has a 30 day trial so you can see if it's worth it.

[Braklet]

@Johnsonx42, thanks for the tip, I'll give TSD a trial to see if it helps with the screwy TS I recorded yesterday.

OK folks, I tried another experiment this morning (record 30 minutes of an ATSC broadcast channel using GB-PVR/DVR-MS mux followed by 30 minutes of the same channel using NPVR/TS mux). This time the TS output seemed much more stable. I didn't want to watch an hour of throwaway stuff but I only noticed one minor glitch, and VideoRedo didn't complain about dropping frames when remuxing to PS, as it did with my prior TS recording. It's possible that I rebooted the HTPC in between those experiments, maybe the weather was different enough. I'm willing to live with the risk of glitchy TS recordings, but this leads me to another question:

How is Live TV different from background recording? Even when NPVR recorded dicey TS, live broadcast TV looked great. I ask because I'd like to know if I need to focus on the HDD as an error source. I regularly scan it for problems and occasionally defragment it so didn't expect issues.