The switch to .ts files has caused all my recordings to transcode to my Shield and hosed FF/RW skipping. Now it pauses a couple seconds on every jump. Annoying. Had to revert to 1.7.5 and now thinking I can never upgrade any further??
@hstamas give it a couple more releases. There used to be a remux setting I think it was that would convert to mkv from what I recall. Hopefully they will bring back that setting. Never used it myself just recalling from some other posts on forum.
I guess I will be hanging out on 1.7.5 until the remux setting from 1.7.4 is added back.
If I do upgrade or if PMS doesn’t add the re-mux option back, would something like this be sufficient for re-muxing to .mkv during post-processing?
ffmpeg -i input -c:v copy -c:a aac output.mkv
@andyblac1974 said:
correct DVR is back to TS container, although it is remuxed and not a raw dump like originally, so still may be some issues. so if anyone has any please report them.
Can we get any details about what occurs during this TS remux? If we want to remux (again) to .mkv, can we just do a straight copy, or do we still need to re-encode audio to aac, as we must with a raw .ts dump?
@johnm_ColaSC said:
@hstamas give it a couple more releases. There used to be a remux setting I think it was that would convert to mkv from what I recall. Hopefully they will bring back that setting. Never used it myself just recalling from some other posts on forum.
Yeah I tried the remux feature when I first started using the Dvr hoping it would solve some lip sync issues I was having (it didn’t) and the constant strain on my server was just too much as it was reencoding the mpeg2 files. Hoping they can just have an option to put it back the way it was or I’m at a dead end with Plex.
Maybe this reverting back to ts is just a bump until they get the issue with closed captioning/sub titles in the mkv resolved. I personally use mcebuddy to remove commercials and convert to mp4. But mcebuddy is only available on Windows.
I wonder how switching to MKV would enable the live TV and timeshifting, where the TS file wouldn’t?
According to the guys that write the TS-Doctor repair app,
only the TS container keeps the important packet timers and counters to have audio and video perfectly synced in case of errors. When these timers are removed during the conversion to MKV, it’s nearly impossible to recreate them from that file if it is damaged.
So, it’s unwise to use other container formats than TS or M2TS to record TV streams. TS is the native format for video broadcasts and developed to deliver synced audio and video even in case of reception problems.
I occasionally get corruption in some of my channels, but could mostly repair the TS file. That stopped working with the MKV file and the audio would always get out of sync after repaired.
@kamererhouse said:
I wonder how switching to MKV would enable the live TV and timeshifting, where the TS file wouldn’t?According to the guys that write the TS-Doctor repair app,
only the TS container keeps the important packet timers and counters to have audio and video perfectly synced in case of errors. When these timers are removed during the conversion to MKV, it’s nearly impossible to recreate them from that file if it is damaged.
So, it’s unwise to use other container formats than TS or M2TS to record TV streams. TS is the native format for video broadcasts and developed to deliver synced audio and video even in case of reception problems.
I occasionally get corruption in some of my channels, but could mostly repair the TS file. That stopped working with the MKV file and the audio would always get out of sync after repaired.
This is helpful. Thanks for the additional info about the advantages of the TS container. The primary concern for most people screaming about this change is that a lot of clients can’t direct play anything in a TS container, and in fact, even when plex direct streams TS by breaking the audio and video out of the container, my Android TV client loses A/V sync after a few minutes.
The value of remuxing to MKV is really in client support, and the original capture is in the native TS container, so even though the “packet timers” are lost when remuxing to MKV, that only means they can’t be recovered later; it doesn’t imply that they aren’t leveraged to ensure accurate sync when the remux occurs.
I fully agree with the posters above that this should be configurable. If your clients can all handle transport stream, or if you need the insurance of being able to repair the stream, by all means use it, but I actually think the flip-flopping on this has little to do with timeshift support, which was introduced for iOS during the 1.7.4 release when it was configurable.
Not sure if this was mentioned (on the go, didnt read), but I added a section of my post processing. If it detects it is TS, it converts to MKV. If it is MKV, it moves on to the next section.
Please bring back the (formerly default) MKV remux option so that my Shield TV doesn’t have to transcode/remux all the recordings on the fly.
Please bring back the (formerly default) TS format so that Closed Captions, DVB Subs and TTX subs are preserved and not thrown away,
@HeartWare42 The TS format was brought back with version 1.7.6.
I know - but I have yet to get confirmation that DVB subs and TTX subs were brought back along with it, as it is now a re-muxed .TS format and not the original, raw transport stream dump that it was previously.
Also - my comment was just as much a slight provocation to the post by @cncb in that shifting to MKV yet again would perhaps solve some problems, but would (re-)introduce some others. The best option would be for the user to decide which format should be used, and - if the remuxed .TS format doesn’t preserve all PIDs, ie. DVB and TTX subs - whether or not to use the raw .TS format or a re-muxed version (knowing that using the raw .TS format would eliminate live TV).
I took that comment to request they bring back the option of “remux” which would take the TS file and output a MKV when the recording was done.
Okay - that’s not how I read it, but it might be. Anyway, I still think there should be 3 options:
- Save as raw transport stream in .TS format (maybe preventing live TV and/or time shift)
- Save as re-muxed stream in .TS format (allowing live TV and time shift, but - perhaps - losing CC and DVB/TTX subs)
- Save as re-muxed stream in .MKV format (for compatibility with playback devices that doesn’t support .TS format, but losing CC and DVB/TTX subs)
Me, personally… I would go for option 1, as it was in the good, old 1.6 days (unless the remuxed TS stream incorporates all the PIDs, ie. includes CC and DVB/TTX subs).
I’m pretty sure the MKV container supports subtitles and closed captions. It was probably just a remuxing bug that caused them to get lost.
@HeartWare42 Yes, I just want the MKV option back and support all the other options you list so we can use whatever is appropriate for our needs. In a past build, they suddenly forced an MKV remux and now they don’t even allow it? It makes no sense to make changes in this manner.
@cncb They more than likely added the TS file back to allow those users with Hearing Disabilities to view closed captions/subtitles in new recordings again. The switch to MKV totally screwed up the closed captions/subtitles so anyone that required them could not understand what was happening in a show. My guess would be the MKV option will come back again either as an option or all recordings will again be MKV once they figure out the issue with including closed captions/subtitles in the MKV file.
I would agree with @HeartWare42 those 3 choices would be good.
I am still a raw .ts proponent. The muxed .mkv format was throwing off A/V sync while cutting out commercials and trimming the ends. But using the raw .ts in TSDoctor, sync was maintained.
