Plex DVR file format change

General Discussions Plex Features
1

After upgrading to the latest release, Plex DVR has changed the output file that is saved from my HDHomerun Prime devices. I used to get a .TS file, and now I am getting a .MKV file. I do not have the Convert video while recording setting turned on.

This is significant for me, as I run a script outside of Plex to search for .TS files and convert to .MP4, and that script wasn’t finding any media files to convert. This filled up my drive with .MP4 files, and stopped all new recordings. Season finale shows were missed.

I review the release notes carefully before applying any new updates. I don’t recall seeing any announcement of a file format or extension change.

2

This post needs to be moved to the DVR beta discussion.

3

I noticed the same thing. My last .ts file recorded was on 5/22 at 6:30 p.m.; thereafter everything is in .MKV format.

NOTE: I no longer have any TRANSCODE WHILE RECORDING option in DVR Device Settings, only the HDHomeRun.Extend quality selections.

4

This beta does indeed use MKV files by default now, rather than .ts files. Best thing to do here is just update your script :slight_smile:

5

Actually, none of my new recordings since the change will play on my Apple TV. It just looks like it’s going to play and then jumps back to the menu. Very annoying.

6

Me too…

Need TS files back. I need CC/subtitles. I was handling in post processing.

Is this a bug?

7

It is not a bug, and has been confirmed as the standard container going forward in another thread. The video container doesn’t change the video. Most likely the MKV container was chosen for compatiability and usefullnes.

8

Then it is a problem, becuase there are no subtites.

The benefit of the ts format was we could extact the close caption and remux it into the mkv.

Is plex going to address this?

What about those of us that need subtitles?

Sounds like anothet blasted change by the plex team and screw everyone that is negativly impacted

9

Also… there is nothing in the release notes about this change

10

This should have been in the release notes, but it should also have been brought up as the direction going forward in advance of the change. I personally haven’t updated (saw the threads warning of an issue) first, but I’m sure I can update things to handle this in my scripts (unclear on impacts to CC usage as I don’t use them but it should be considered a MAJOR issue if it does break close captioning). I love Plex but not loving how this rolled out…

11

From what i can see there are no close captions.

This is a show stopper for me.

I find it hard to beleive that this would be left out.

I can forgive all of the other BS, but not that :slight_smile:

12

This should have been included in the change log.

Well my point is that if you do some research on the different containers and what they can store the most flexible is MKV. There is absolutely no reason subtitles can’t be included in the MKV file.

13

Very true.

What i was doing was exrracting the close caption from the ts, and them muxing everything into an mkv myself.

I would have no complaints if that was what plex did.

They did not.

So clearly people with hearing loss dont matter. :slight_smile:

14

I really don’t get what they are doing here and it would be helpful if someone would explain. Why force remuxing on all users? If you want to make it the default, fine - but don’t force it on everybody. I use the postprocessing script functionality - it is just a waste of processing cycles to have plex automatically remux everything when I’m going to do it myself when I process the video file. If you want to do it for live tv fine, but not everybody wants or needs that. I already have an antenna going to my TV.

15

@mavrrick said:
It is not a bug, and has been confirmed as the standard container going forward in another thread. The video container doesn’t change the video. Most likely the MKV container was chosen for compatiability and usefullnes.

I get that the MKV container is more flexible - but as I mentioned in my previous comment why force this change on everyone? It’s just using cpu cycles for nothing if one has their own postprocessing script and breaks scripts. Also as another person pointed out it was just slammed in without warning.

16

I totally agree it should of been documented better. That is a huge miss when folks are creating external stuff to work with plex. I am really not sure it is many cpu cycles though. Because of problems I am having I watched a few records very closely. It appears that the file is recorded to transcoder location in chunks as it is on live TV. After the show ends it mixes all those files together into one stream. Thay means it is muxing the file anyways so changing the container would be trivial.

17

I would like to chime in as well - I get that remuxing is handy for many people, but for us advanced users… why not have an advanced option “Do not automatically remux streams?”
In the meantime, I’m downgrading back to 1.5.5.

18

Based on my previous post though everything is remuxed. So it may be more like specifying what container to use instead of if remuxing is turned on at all.

19

Looks like they updated the release notes so show remux is now done by default.

20

It’s a double hit for those with low powered servers that never intended them to be used for transcoding. Not only is extra resource used for the remux when recording but something about the way they’ve created the mkv container causes the plex clients (at least some of them) to want to transcode before playing, which of course the server can’t do. I’d live with the unnecessary remux (although I’m perfectly happy playing TS files as I’d done for years with MythTV) but breaking my playback ability because shows now have to be transcoded is not acceptable. With DVB files this stuff should be simple: grab the stream, write it to a file. Then read the file and stream it to a player. No need for additional complexity or fancy back end capabilities.