I noticed that after upgrading to 1.7.1 my dvr recordings are now in .mkv format and are no longer in .ts. I noticed that there are only 2 options under the DVR for Off and Transcode. Off used to record in a .ts format, Remux would put the file in a .mkv container (which now appears to be the default), and Transcode would make a .mp4.
It doesn’t appear that I’m having any issues yet with the new .mkv setting, but I didn’t see any changelog information about that change. I used to keep the files in the .ts format as I would get audio sync issues using the .mkv wrapper. I use MCEBuddy after every recording to remove the commercials and the audio would get off with the mkv wrapper, but not with the straight .ts.
I will report back later if I’m having issues now that the option is .mkv only.
That is a big change and it should’ve been mentioned. I know when I first started using the DVR beta releases, I was using the remux option. If I had recordings that had too many artifacts, I would have failures in my DVR so I switched this feature off and was getting .ts files.
I expect this may be a necessary change for the Live TV viewing…hopefully they’ve been able to improve the reliability of it.
This has also affected my post processing scripts (and my docker build). I’m rewriting my scripts to workaround this. I don’t have a problem per-se with this, but if the remuxing is being done post-process, its kind of a wasted step (as my scripts do remuxing already and need to regardless due to commercial marking), so it would really be nice if this could go back to being an option - otherwise every recording is incurring an extra remux pass.
Why is such a big change not mentioned in the changelog?
This also affects my post processing script. The new file created by MCEBuddy overwrites the old file (since it has the same name, before x.ts -> x.mkv, now x.mkv -> x.mkv) so the Archive function doesn’t work.
How does this change affect the script? It certainly changes the mcebuddy configuration if you are trancoding to mkv but nothing in the actual script needs changing. I use the same script and it has kept running with no issues since the conversion. As far as the archive, the archive setting in mcebuddy is configurable so you can set it to archive to a specific drive/path if you want/need to keep the original recording.
I do agree that a change in the container should have been documented in the release notes. Probably in bold so it caught everyone’s attention.
@hovee said: @Wiidesire same issue as I use your script as well. Do you plan on updating it?
You can workaround that (if you want a backup of the untouched recording) by editing the Profiles.conf located under MCEBuddy2x/config. You’ll now see the list of all profiles. Depending on what Profile you chose, add the following to the end of the profile: CustomCommandPath="C:\Windows\System32\cmd.exe" CustomCommandParameters="/c move /y "%sourcefile%" "D:\YYY\%originalfilename%-Backup.mkv"" CustomCommandHangPeriod=900 CustomCommandCritical=true CustomCommandUISession=false CustomCommandShowWindow=false
Replace 'D:\YYY' with your desired backup path (which should not be within a DVR library).
The script won’t change.
@johnm_ColaSC said:
As far as the archive, the archive setting in mcebuddy is configurable so you can set it to archive to a specific drive/path if you want/need to keep the original recording.
That’s the point. The Archive function doesn’t work when the filename is the exact same (including the extension). The archive moving is done after the conversion. So MCEBuddy first overwrites the original file with the converted one (because they have the same name) and then tries to move the original, which ofcourse doesn’t work.
@Wiidesire So the container change exposed a design flaw in mcebuddy. Archive should be made of the original file before processing begins. Otherwise selection of a conversion profile in mcebuddy that matches the original container would create this same issue.
@johnm_ColaSC said: @Wiidesire So the container change exposed a design flaw in mcebuddy.
Are you implying that I blamed Plex for it? Because I didn’t. @johnm_ColaSC said:
Archive should be made of the original file before processing begins. Otherwise selection of a conversion profile in >mcebuddy that matches the original container would create this same issue.
I raised the issue with the dev over half a year ago: https://mcebuddy2x.codeplex.com/discussions/657921
No I blame mcebuddy, especially since you made them aware of this issue previously. Surely in 18 months they could have moved the logic to archive the file to the first task to be completed.
Sort of going off the main topic now, but this is a big part of why I won’t pay for MCE buddy, one it says open source, but you can’t compile it (and then fork with a fix for this), and two the dev seems to have sorta stopped, which with a name like MCE I guess I can see it sorta dying, but a good product meets demand. Anyway I posted in that thread for added vis as well.
@Wiidesire said: CustomCommandPath="C:\Windows\System32\cmd.exe" CustomCommandParameters="/c move /y "%sourcefile%" "D:\YYY\%originalfilename%-Backup.mkv"" CustomCommandHangPeriod=900 CustomCommandCritical=true CustomCommandUISession=false CustomCommandShowWindow=false
Replace 'D:\YYY' with your desired backup path (which should not be within a DVR library).
The script won’t change.
It would be helpful if you would provide some type of roadmap. I have no issue with using .mkv instead of .ts as far as containers go… however if one prefers to transcode to a particular format it isn’t really helpful to force an automatic remux when it isn’t needed.
It is and isn’t. If plex converts the video file to a more universal container like MKV then post processing can be done after the video file is completed by plex and still retain the metadata plex gets with the show. That is what I have been told by a few others. If plex doesn’t do it, a post processing script must be used to convert the video to the final container before plex marks the video as completed. This can mean a significant delay in the video being available after recording actually completes.
I actually like the idea of letting plex turn it into MKV with it immediately available and then set MCE Buddy to convert it from mpeg2 to hvec after a period of time.
@jwaltrip4 said:
I dont have issues so much with mkv.
I have major issues with no close caption
Closed captions are supported by MKV, so not sure what the plex team did in their implementation… it should work. My issue isn’t about MKV, I use it all the time… the problem I have is that they apparently now force remux for everyone without an option to opt out. For me it is just a waste of resources because I do it anyway in post processing. I’m running a test tonite for closed captions and will report back… when I did .TS to .MKV I never had any issues getting the closed captions. If they did something to screw that up… shame on them…
I can verify this… you are absolutely correct. MKV supports closed captions. As I mentioned above when I did this myself - remuxing and transcoding from .TS I had no issues with the closed captions. Whomever programmed this change made a careless mistake and needs to acknowledge and fix it. This might be getting lost in the crosstalk. Created a new post so hopefully this issue will get some attention: forums.plex.tv/discussion/273490/warning-plex-1-7-0-1-7-1-breaks-closed-captioning-subtitles#latest
