[mythtv-users] Announcement: Looking for Alpha testers for a generic Lossless cut solution

[Doug Vaughan]

Kevon,
     Right now I can find no reliable replacement for either 
mythccextractor or CCExtractor. I am in the process of informing the 
CCExtractor developer (Carlos Fernandez) and supplying sample videos. I 
worked with him to get UK DVB subtitles working. Carlos was remarkably 
responsive so I would be surprised if he did not react to these requests.

     In fact Lossless Cut includes CCExtractor (32 and 64 bit) 
executables which are a release ahead of what you can find on the 
sourceforge.net. In any event mythccextractor would be my go to subtitle 
utility when the ticket has been addressed. It already does extract EIA 
subtitles but I think with the same issue as stated in the ticket. 
Hopefully in the end CCExtractor would only be used to support MythTV 
v0.24 users.

     The code to use mythccextractor is already in Lossless Cut but 
currently commented out. If you want to experiment by un-commenting fine 
but I have not tested it in a while. Search for the ticket number in 
lossless_cut.py

     As for your comments about the wrong tpage info I am aware of that. 
The issue is around the inconsistent subtitle track information various 
recording devices include within the recording container and 
specifically for the subtitle track. Even with the working UK DVB-T 
subtitle extraction, cut and remux, two subtitle tracks are processed 
but only one produces an SRT file.

     As to aborting the script when there are issues with the subtitle 
tracks, I actively decided to log a message that a subtitle track was 
being skipped and keep processing. Over the last few days it seems 
obvious that subtitle processing will be problematic until utilities 
mature and subtitle track info patterns emerge.

     I added such a statement at the top of the the wiki last night. 
Right now subtitles are a best effort situation. I believe over time 
this will get better.

     There is a bug where the configuration setting "delete_old" is 
being ignored when the replace "-r" option is used. This means even if 
you changed "delete_old" setting to "false" the original recording will 
still be deleted. This will be fixed in v0.1.4 (the next release). I 
discovered it while replying to this email;) I personally never use the 
"-r" option. I tried to give the user options with the "-r". Of course 
that newly discovered bug has to be fixed first.

I hope this address your concerns.

Doug