@lennier76 said:
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. …
This is beta still and stuff happens - but clearly this wasn’t thought out nor implemented well. If you want to make automatic remux the default, have at it… but 1st make sure you implement it correctly (loss of closed captions is a big fail) and 2nd give people (especially those who are using the postprocessing routines) an option to opt out. It’s ridiculous to do double processing for absolutely no benefit. Huge design fail. Just makes absolutely no sense. This release is half-baked. We’re in Beta now, not Alpha.
@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 agree it’s not a bug… but it’s a design fail. Why are they forcing EVERYBODY to remux? If you’re doing post processing, it’s a waste of CPU and some people don’t need it anyway as others have mentioned. They should know this… they provided the shim to do post processing, duh! 2nd, why are they dropping closed captions? Clearly someone didn’t do their homework on remuxing options.
This release was just thrown out there… they didn’t mention this in the release notes, the broke post processing scripts and they botched the remuxing. This is a beta, not an alpha. What were they thinking? The answer is apparently, they weren’t.
You didn’t read my posts. Even if the file is kept in a .ts container it is being remuxed.
If you watch the recording on your system you will find it is writing to your transcode location first. To that location it appears to write out the video file in small chunks. I believe this is likely related to live TV playback being added. Once the show is over it muxes those tiny files together to create the MKV file. That last step would be the same if they generated .ts files.
Was it handled the best? Absolutely not! Is it a problem and should it be changed back? Functionally I doubt it because of how flexible MKV container is. Did they screw up with CC/Subtitles? Sure sounds like it, but it should be fixable since MKV supports pretty much every subtitle standard.
Don’t forget this wasn’t the only change with this version. It looks like plex updated the transcoder and that could have very well been related to this change as well.
Standards change as scope is discovered. Beta doesn’t mean functionality can’t change. All it means is the software isn’t a final stable release.
@mavrrick said:
You didn’t read my posts. Even if the file is kept in a .ts container it is being remuxed.
If you watch the recording on your system you will find it is writing to your transcode location first. To that location it appears to write out the video file in small chunks. I believe this is likely related to live TV playback being added. Once the show is over it muxes those tiny files together to create the MKV file. That last step would be the same if they generated .ts files.
I did read your response and you are missing the point. Prior to this release the .ts file immediately prior to post-processing contained subtitles. The new remuxed MKV file does not. Now during recording I have multiple transcode processes running to remux to MKV… Previously I did not. This isn’t about MKV being a better container… It’s about breaking things without regard to functionality. All they needed to do was to put another checkbox for “remux to MKV” and state you would lose CC… Like they did for transcoding. It’s not that hard. Instead they break post processing scripts and nuke CC. This is not an alpha… It is a beta. You don’t break major functionality. Apparently they don’t have design reviews.
@gbcox Actually i am not missing the point. I said CC/Subtitles was a huge miss and it is something they should fix in the container they feel will best server Plex. If that is MKV then that is the direction they should go. I am not going to presume to know their development direction to tell them if it is or isn’t.
You are also glossing over something I have said twice before. With 1.7+ atleast i am seeing something that would indicated it requires muxing reguardless of what container is used. I am not sure you would get subtitles in the current state even if the file was placed in a TS file as you suggest. This is a problem for subtitles and needs to be brought up. But the complaint about remuxing and TS vs MKV is pointless really. The reality is they shouldn’t distinguish between Remux at all. The should probably simply ask what container you want your content in. The problem with that is that based on the container you could have very drastic differences in functionality.
Post processing is a user issue and not a plex issue. Ofcourse we would prefer our scripts always work, but i never expect everything I custom write to work with a program i didn’t write after a upgrade. That is where they missed huge with the change log. Lets be honest though a good script will probably not care about the extention and if then if it does, it is likely easy to fix.
I’m still somewhat doubtful about the “always remuxing” as it doesn’t match my experience but then again I haven’t looked into it very closely so I will trust your info.
Post-Processing is VERY much a Plex issue as they have a feature that has been documented and if they intend to break that, there should be communication before it ever gets released. Now, if I don’t pay attention then that is on me. Personally, I find it concerning that they aren’t here discussing these issues with the community. It’s just bad customer relations as the only way I have this feature is to be paying them…
It looks like the file format changed back to .TS with the recently announced update today. The DVR instructions online still say it is recording to an MKV container, but the announcement says (DVR) Use MPEGTS for all DVR recordings. I can confirm that new recordings have moved back to .TS files.
I’ll have to modify my conversion scripts back to .TS now.
THANK YOU for putting the announcement of the change in the release notes.
I noticed the change back to TS format this morning as well, and fortunately was able to revert to 1.7.5 before my post-processing script failed.
I use a post-processing script setup under Linux, and I was planning to replace the remux step that Plex removed with this line:
#!/bin/sh
filename=$(basename “$1”) ffmpeg -i “$1” -vcodec copy -acodec copy "$filename.mkv"
Can someone explain to me why the change from one and then back to the other? Know they made the change is great but why they made the change escapes me. Would be great to know how this will impact me before I upgrade to the new version. I don’t need to know all the nitty gritty just a brief few sentences on the pros/cons would be great.
Users with disabliities were unable to utilize closed captions/sub titles in the mkv format.Switching back to ts container was probably the answer to that issue.
@tvguy25 said:
I noticed the change back to TS format this morning as well, and fortunately was able to revert to 1.7.5 before my post-processing script failed.
I use a post-processing script setup under Linux, and I was planning to replace the remux step that Plex removed with this line:
#!/bin/sh
filename=$(basename “$1”) ffmpeg -i “$1” -vcodec copy -acodec copy “$filename.mkv”
I didn’t have any trouble with my post-processing script, with the modification above, under Ubuntu 16.04
After my comskip run was complete, it deleted the existing *.ts file in the grab folder, and copied in a file with *.mkv Plex picked up the changed file as expected:
Jul 13, 2017 14:12:17.952 [0x7f3894bff700] DEBUG - Jobs: '/usr/local/bin/call_comskip_edl_ts.sh' exit code for process 26185 is 0
Jul 13, 2017 14:12:17.952 [0x7f3894bff700] DEBUG - DVR:Recorder: Postprocessing script '/usr/local/bin/call_comskip_edl_ts.sh' seems to have renamed output file '/Media/Temp/Plex_DVR/.grab/ce4c3f173efbdaebf00947de2528633ab02570ed/General Hospital (1963) - S55E70 - Episode 70.ts' to '/Media/Temp/Plex_DVR/.grab/ce4c3f173efbdaebf00947de2528633ab02570ed/General Hospital (1963) - S55E70 - Episode 70.mkv'
If you are having trouble with the script executing, make certain the permissions/user are correct.
@tvguy25 said:
I didn’t have any trouble with my post-processing script, with the modification above, under Ubuntu 16.04
After my comskip run was complete, it deleted the existing *.ts file in the grab folder, and copied in a file with *.mkv Plex picked up the changed file as expected:
Jul 13, 2017 14:12:17.952 [0x7f3894bff700] DEBUG - Jobs: '/usr/local/bin/call_comskip_edl_ts.sh' exit code for process 26185 is 0
Jul 13, 2017 14:12:17.952 [0x7f3894bff700] DEBUG - DVR:Recorder: Postprocessing script '/usr/local/bin/call_comskip_edl_ts.sh' seems to have renamed output file '/Media/Temp/Plex_DVR/.grab/ce4c3f173efbdaebf00947de2528633ab02570ed/General Hospital (1963) - S55E70 - Episode 70.ts' to '/Media/Temp/Plex_DVR/.grab/ce4c3f173efbdaebf00947de2528633ab02570ed/General Hospital (1963) - S55E70 - Episode 70.mkv'
If you are having trouble with the script executing, make certain the permissions/user are correct.
I posted what my log shows, and it doesn’t even reference my script. In the past when I’ve fat fingered something the log says “script not found” or some such error. If the script runs then I get some type of completion code. Now I get nothing. It is as if I didn’t enter a postprocessing script… but it is there…
