I am using PlexDVR with HDhomerun tuners and am not having good luck with the Closed Captions. I can’t find any way to extract the CC from the .mkv files created by plexdvr. Before this last update of plex you had the choice of downloading your hdhomerun tv program files in .ts or .mkv, now you can only download the tv files in .mkv. CCextractor works with .ts but not with .mkv so now I can’t extract the CC into an .srt file to be used by the roku streamer. Does anyone know of another program that will extract Closed Captions from OTA TV files in .mkv container? I believe the difference is that the .ts files were plain mpeg2 while the .mkv are h264 and as far as I can tell ccextractor doesn’t work on h264 files. It will create a file but the play timing of the file is less than 1 second which causes the CC to just flash by on the screen in the first second of the program.
I can’t use HandBrakeCLI because this being OTA TV recording, sometimes I will get a damaged frame in the TV file and this causes HandBrake to lock up and puts the processors into overdrive failing to finish processing and raising the processor temps to dangerous levels.
I have tried to use ffmpeg but the latest Debian version doesn’t do Closed Captioning at all.
There is another thread that was made soon after the 1.7.x PMS release that discussed this in some details. The just of what came out of it was that the sub weren’t exactly striped but In the files in a way that some software really struggles with. That doesn’t make the current situation any better, but in that same thread it was acknowledged by someone within plex that they are working to improve that situation.
The assertion this means they need to bring back .ts container though is a poor one. The MKV container can do anything the .ts container can do and much more. They just need to get them in .MKV container in a way more clients will identify them.
The assertion this means they need to bring back .ts container though is a poor one. The MKV container can do anything the .ts container can do and much more. They just need to get them in .MKV container in a way more clients will identify them.
I have to disagree here, There is still no CC extractor for .mkv (h264) files available except for HandbrakeCLI and as I said in my original post above, if there is a damaged frame in the file, which I have experienced from time to time, then handbrake goes into overdrive as I have described above. This doesn’t happen using ccextractor on a .ts (mpeg2) file. So without the choice to download .ts files there is no other way to extract cc from the tv files. That I have found anyway. I use Linux.
@mavrrick said:
There is another thread that was made soon after the 1.7.x PMS release that discussed this in some details. The just of what came out of it was that the sub weren’t exactly striped but In the files in a way that some software really struggles with.
In that case, could you please tell me, how I extract the DVB subs from the recorded files, as well as the TTX subs? No program I have available that processes MKV files can see any other tracks than a video track and one or more audio tracks.
So where are the DVB subs and/or the TTX subs stored?
@mavrrick said:
The assertion this means they need to bring back .ts container though is a poor one. The MKV container can do anything the .ts container can do and much more. They just need to get them in .MKV container in a way more clients will identify them.
Agreed - but UNTIL THEN they shouldn’t make it impossible for users to get them. If necessary, they should provide a post processing program that can extract these informations from the .MKV file, but as it is, there is currently NO WAY (at least no way that I am aware of) to get this information any more, other than reverting back to a version that saves in .ts format.
Do you know of ANY way to get the subtitles (both DVB and TTX) from the recordings that the Plex DVR makes?
Do a search and find the thread. I read through it a few weeks is ago, but it isn’t something I am concerned with.
They are not holding a gun to your head and making you use 1.7.x of plex media server. If you want stuff to run the same as before run an earlier version of plex. Just remember you will not have the new transcode engine that is needed for live TV.
Post processing is for us end-users to figure out, not for plex to provide. It is also not there fault a tool doesn’t exist for what you want.
@mavrrick said:
They are not holding a gun to your head and making you use 1.7.x of plex media server.
No - and I am going to install v1.6 on top of it as soon as I can get clarification as to if this would cause any problems. Had I known of this problem (f.ex. by the update description containing a big warning, that all subtitle support for recordings would cease to function), I wouldn’t have installed the 1.7 update in the first place…
@mavrrick said:
Just remember you will not have the new transcode engine that is needed for live TV.
No problem - I watch live to on my TV.
@mavrrick said:
Post processing is for us end-users to figure out, not for plex to provide.
I beg to differ (in this case). When they implement a change that removes an important (for some) feature, then they should do what they can to mitigate the problems caused by this - by either allowing files to be saved in .ts format, by properly supporting all the features that the previous version had, or by assisting in making a temporary fix until a proper fix can be implemented. That’s just good practice for software development…
@mavrrick said:
It is also not there fault a tool doesn’t exist for what you want.
No - but it’s their fault that they removed a feature without ensuring (and publicizing) a work-around for the people that relied on that feature…
Post processing is an option they added for end users to do there own thing and I would never expect something provided by them using that functionality. Mainly because it opens them up to further support issues. If plex provides it, it should be built in.
In software development all to often a temporary fix becomes permanent. They know there is an issue and are working on a proper solution. With the new transcoder in 1.7.x simply saving as TS may not change anything.
It certainly could have been communicated better but it is still in beta. They can make significant changes if they want to. I also don’t believe they intentionally removed our broke CC. Based on the thread I read they tried something and it didn’t work well. That is largely because of how CC works actually.
There was also a thread about a work around that allows plex to download subtitles on the fly. I am not sure how good that is though if you are not in the US.
@mavrrick said:
Post processing is an option they added for end users to do there own thing and I would never expect something provided by them using that functionality. Mainly because it opens them up to further support issues. If plex provides it, it should be built in.
If you can’t use the CC that exists in the TV stream then the software is broken. This is NOT an option. And since end users of this plexdvr have to PAY for the ability to use it then it is their responsibility to see that it works, beta or no beta. If they want to experiment on the end user then they need to stop charging us. Saying that, I am willing to use my own abilities in a post processing script to get what I need out of their service but when they change the software to the point that it is broken beyond use for a certain section of the user base then it is broken and they are charging us to test their software instead of paying us. I have spent hours searching for a way to get CC working again since the update, I have since paid another payment to keep plexdvr working. And so far I am still unable to use it. What they are doing is screw.ing a certain section of their user base. Using CC should not be a part of the post processing script, I agree with you “it should be built in”.
simply saving as TS may not change anything.
The point we have been making all along is that it worked fine until the removed the ability to save in TS. This would actually change EVERYTHING!
@sudheeshb said:
I fully agree with OP. This is one of the key feature which many of us uses. You may the try the following work around ( not a good one ).
Extract the TS from the MKV. You can use ffmpeg for this.
ffmpeg -i input.mkv -vcodec copy output.ts
Now you can extract closed caption from the TS file. You may use ffmpeg or ccextractor for this.
I tried this and it worked. I had to convert to ts with this then extract the CC with ccextractor then convert the ts to mp4 while burning the srt to the mp4. Trying to play the srt along side the ts caused plex to error out so I had to burn it to mp4.
Unfortunately, this only works for CC subtitles, which (I believe) is not used outside the US/Americas. In Europe we use DVB subs and/or TTX subs, and these are irrevocably lost and cannot be restored from the .MKV file with any kind of post processing script.
Also, the burning of the sub titles into the video removes the advantage of having the subs externally from the video - namely the ability to have the OPTION of having subs or not during playback.
@HeartWare42 said:
Unfortunately, this only works for CC subtitles, which (I believe) is not used outside the US/Americas. In Europe we use DVB subs and/or TTX subs, and these are irrevocably lost and cannot be restored from the .MKV file with any kind of post processing script.
Ah, I didn’t know that. I was hoping they fixed this with the new update but no luck.
I am seriously thinking of just buying a DVR, this is getting really hit and miss.
Also, the burning of the sub titles into the video removes the advantage of having the subs externally from the video - namely the ability to have the OPTION of having subs or not during playback.
Actually it adds the subs as an option in the mp4, it doesn’t burn them in.
@HeartWare42 said:
Also, the burning of the sub titles into the video removes the advantage of having the subs externally from the video -
namely the ability to have the OPTION of having subs or not during playback. @widgeteye said:
Actually it adds the subs as an option in the mp4, it doesn’t burn them in.
Okay - that at least is a plus. Now we only need a way to preserve the DVB and TTX subs as well. Preferably Plex DVR should re-mux these as PGS (Blu-Ray) subs and SRT/SSA subs (the latter to preserve the colours available in the TTX subs).
Or just leave the recording as .ts format so that I can do with these as I usually do…
I just ordered a new DVR from Amazon, I am giving up on plexDVR, it just is not able to do CC. Even after I finally was able to get CC extracted from the TV files there are so many errors in them they aren’t usable. HDHR downloads the files from channels with 100% signal strength and 100 SNQ, yet when the files are finally played they skip and pixellate and the subtitles don’t work properly. It’s just not worth the trouble. I’ve spent hundreds of dollars and months working on this as a dvr, plus I am having to pay plex to be their guinea pig, which is ridiculous. I’m done, good luck to the rest of you.
PS: I will be selling two HDHR Connects for $140.00 total. Only selling as a pair. probably putting them on Ebay within the next week or two.
In the US closed captions are a requirement. I think the only way Plex will be able to get their DVR out of “beta” is by building in the functionality (see the part at the end about Netflix):
Americans with Disabilities Act (ADA)
Passed in 1990, the ADA set landmark accessibility requirements that affect both private and public entities. Just as the ADA requires handicap ramp access to buildings, it demands that “auxiliary aids” be made available to anyone with a disability. In the case of the deaf and hard of hearing, that means providing closed captioning for videos.
Closed captioning or video transcriptions are required for:
“Public entities,” i.e., state and local governments, in both internal and external video communication.
“Places of public accommodations,” which is a business in any of the following industries. (Private clubs and religious organizations are exempt.)
Lodging (e.g., hotels)
Food service (e.g., restaurants)
Entertainment (e.g., movie theaters)
Public displays (e.g., museums)
Public venues (e.g., libraries)
Service industry (e.g., doctor’s offices)
Retail (e.g., shops)
Public Transportation (e.g., train stations)
Education (e.g., universities)
Recreation (e.g., stadiums)
Social Services (e.g., day care)
Fitness (e.g., gyms)
While the ADA doesn’t specifically address online video (it was written in 1990, after all), legal precedent set by a 2012 law suit categorized Netflix, a purely virtual business, as a ‘place of public accommodation’ and therefore required video captioning. The ADA is long overdue for revision to explicitly define a place of public accommodation in the context of the Internet. Until then, the consensus is that any website or online business that fits into one of the 12 categories above is subject to ADA regulations. This would include colleges and universities.
@aLanManT said:
In the US closed captions are a requirement. I think the only way Plex will be able to get their DVR out of “beta” is by building in the functionality (see the part at the end about Netflix):
While the ADA doesn’t specifically address online video (it was written in 1990, after all), legal precedent set by a 2012 law suit categorized Netflix, a purely virtual business, as a ‘place of public accommodation’ and therefore required video captioning.
In this case I believe plexDVR will NEVER come out of beta. They are obviously trying to save themselves the time and trouble by having the users do this themselves.
One thing I’ve noticed I have 2X Xeon processors running 24 logical cores. But it would seem handbrake for a single processing instance can only take advantage of one processors.
I would add that I have OTA, and in bad whether I get dropped frames etc. I use MCEbuddy to extract CC and converts the file to .mp4 using handbrake. I will process 2 recording simultaneously this way and I have no such problem as you mentioned with handbrake locking up. As long as plex doesn’t introduce bugs like recording hanging, or audio with no video all is good. Any encoding will naturally use as much processor as available bc handbrake can use multiple cores as it should to encode quicker, if you don’t want it to do that then use MCEBuddy and MP4 or MKV unprocessed and you can still extract CC to srt just without all the encoding, just puts the appropriate container around it. .
