OpenDCT: An open source digital cable tuner.

[RangerZ]

OK, I can accept that, but what I was trying to say is that I have the paramter set and OpenDCT has stopped generating the subtitles.

In summary, some of the subtitles were off time wise, probably due to my FF & RW and channel surfing on Live TV as opposed to a recording. Captions just work for MPEG.

I deleted all the .SRT files in an attempted to clear up the issues, but new ones did not generate.

Rebooted.

Today I disabled the flag, waited some time and restarted the flag, but still not generating subtitles.

IIRC I was getting srt files generated for even live tv as soon as I tuned, but now nothing.

[EnterNoEscape]

Originally Posted by RangerZ

OK, I can accept that, but what I was trying to say is that I have the paramter set and OpenDCT has stopped generating the subtitles.

In summary, some of the subtitles were off time wise, probably due to my FF & RW and channel surfing on Live TV as opposed to a recording. Captions just work for MPEG.

I deleted all the .SRT files in an attempted to clear up the issues, but new ones did not generate.

Rebooted.

Today I disabled the flag, waited some time and restarted the flag, but still not generating subtitles.

IIRC I was getting srt files generated for even live tv as soon as I tuned, but now nothing.

That sounds like the configuration was changed. If you post opendct.properties, I can probably tell you where the issue is.

[RangerZ]

Attached, Thank you!

[EnterNoEscape]

Originally Posted by RangerZ

Attached, Thank you!

You have CCExtractor disabled:

consumer.ffmpeg.ccextractor_enabled=false

should be

consumer.ffmpeg.ccextractor_enabled=true

[RangerZ]

I guess I misunderstood post 2111

I thought

consumer.ffmpeg.ccextractor_enabled=

controlled the Subtitles being moved during transcoding.

I thought

consumer.ffmpeg.upload_id_enabled=

controlled the creation of .srt files

My problem has been I accidentally changed the wrong parameter. I changed

consumer.ffmpeg.ccextractor_all_streams=false

which I think controls the creation of CC2.

So after I fixed the

consumer.ffmpeg.ccextractor_enabled=false

I left the

consumer.ffmpeg.ccextractor_all_streams=false

as I figured I only needed CC1, however it appeared to generate only a 0KB file, but was only briefly tested. Menus were present.

The quality of the subtitles is not that great, but expect that is more of a CCextractor issue, or is it a limit of the HW to process the content?. see attached. The file name is the actual verbage.

Thanks for straightening me out.

[RangerZ]

I set up a program to record and just went back to look at it and check subtitles. The recorded program was from 12-1PM, the current (live) program is playing from 2-3PM.

The current program displays no subtitles, but the display shows 6 entries for subtitles. There are 2 .srt files (79k and 1K). see jpg.

The recorded program has subtitles for about the first 7 minutes (12:03-12:09) and there is an error indicated in the attached log about that time. see log pt 1

After watching some of the recorded program, and going back to the (now) next current program (3-4pm) I am back to working subtitles and normal menu (2 entries).

I split the log files due to size. up to 2PM in the first, after in the second.

[EnterNoEscape]

Originally Posted by RangerZ

I set up a program to record and just went back to look at it and check subtitles. The recorded program was from 12-1PM, the current (live) program is playing from 2-3PM.

The current program displays no subtitles, but the display shows 6 entries for subtitles. There are 2 .srt files (79k and 1K). see jpg.

The recorded program has subtitles for about the first 7 minutes (12:03-12:09) and there is an error indicated in the attached log about that time. see log pt 1

After watching some of the recorded program, and going back to the (now) next current program (3-4pm) I am back to working subtitles and normal menu (2 entries).

I split the log files due to size. up to 2PM in the first, after in the second.

I see a lot of these:

Changed fps using NAL to: 29.970030

which isn't normal.

Apparently there are some problems in CCExtractor when it comes to certain H.264 streams and that causes it to not work correctly. There was an issue identified late last year that has since been fixed that might resolve your problem too. I would say you can just upgrade to the latest CCExtractor, but OpenDCT uses a slightly modified binary because it will automatically create two files that don't have the naming convention one might expect. I'll look into patching a new build that I will release with the next version of OpenDCT.

[RangerZ]

thanks for finding an issue.

FWIW, I have monitored the issue with extra entries in the popup.

It seems that while the 3-4PM show I had Subtitles, that the 4-5 and now 5-6 do not. In addition the 4-5 displayed 4 entries in the pop-up, and the 5-6 now display 6 entries.

This is for live TV on the same channel.

Changing to a different channel resets the pop-up and subtitles again appear for the new channel.

[bisongde]

Hey EnterNoEscape,

Is QuickSync implemented yet? I notice in the transcode config there are lines commented out for QuickSync that mention it's not yet available. Is this because you use LibAV instead of ffmpeg, or the ffmpeg build included with OpenDCT doesn't have the QuickSync codec included yet?

I have 12 tuners that I would like to be able to transcode down to a fairly compressed size (quality not as big a concern as compression). I had originally set up two boxes for this purpose, one as grabber and one as transcoder. If it's possible though I'd like to set up Sage on both boxes and have each transcode live using QuickSync.

If QSV isn't implemented, is there a timeline for it being implemented or can I add in support by substituting out the ffmpeg/libav build or adding in the codecs myself? How involved would this be (probably pretty involved or you would have done it yourself by this point)?

Thanks!

[EnterNoEscape]

Originally Posted by bisongde

Hey EnterNoEscape,

Is QuickSync implemented yet? I notice in the transcode config there are lines commented out for QuickSync that mention it's not yet available. Is this because you use LibAV instead of ffmpeg, or the ffmpeg build included with OpenDCT doesn't have the QuickSync codec included yet?

I have 12 tuners that I would like to be able to transcode down to a fairly compressed size (quality not as big a concern as compression). I had originally set up two boxes for this purpose, one as grabber and one as transcoder. If it's possible though I'd like to set up Sage on both boxes and have each transcode live using QuickSync.

If QSV isn't implemented, is there a timeline for it being implemented or can I add in support by substituting out the ffmpeg/libav build or adding in the codecs myself? How involved would this be (probably pretty involved or you would have done it yourself by this point)?

Thanks!

It's not implemented and there isn't a timeline to support it. The last time I looked into implementing it, the work involved was more than I was willing to put into it and possibly above my abilities. It's not as simple as compiling the QuickSync code into the libraries. We were talking about taking the easier route and just compiling the FFmpeg executable which is a lot easier, but with the downside that tuning into a station will be slower.

[bisongde]

Originally Posted by EnterNoEscape

It's not implemented and there isn't a timeline to support it. The last time I looked into implementing it, the work involved was more than I was willing to put into it and possibly above my abilities. It's not as simple as compiling the QuickSync code into the libraries. We were talking about taking the easier route and just compiling the FFmpeg executable which is a lot easier, but with the downside that tuning into a station will be slower.

So where's a good place to start if I'm looking to do this myself? Decompiling the .jar and adding the ffmpeg executable? Is there a certain place I should be focusing my efforts for the transcoder code? Is the transcoder portion a self-contained module or will I have to make changes throughout? Maybe I could make a separate class that can be enabled or disabled based on a config line for others in a similar position?

Tuning time is not an issue for us, as long as it's not something ridiculous. These systems are used almost purely for automated recording with 3 min heads and 10 min tails. Little if any live TV viewing.

[EnterNoEscape]

Originally Posted by bisongde

So where's a good place to start if I'm looking to do this myself? Decompiling the .jar and adding the ffmpeg executable? Is there a certain place I should be focusing my efforts for the transcoder code? Is the transcoder portion a self-contained module or will I have to make changes throughout? Maybe I could make a separate class that can be enabled or disabled based on a config line for others in a similar position?

Tuning time is not an issue for us, as long as it's not something ridiculous. These systems are used almost purely for automated recording with 3 min heads and 10 min tails. Little if any live TV viewing.

You would need to implement a new consumer that uses the FFmpeg executable instead of the JavaCPP pre-compiled libraries. It shouldn't be difficult to create the new implementation, but to do this right, you also need to add 32-bit and 64-bit Windows and Linux binary to the bin directory in the project, add compiling scripts for updating the binary, update the readme on how to compile the binary from sources (they don't need to be in the OpenDCT project) and modify the RPM, DEB and MSI installers to include the FFmpeg binary preferably in it's own folder (./bin/ffmpeg). Of course I can help you get everything where it needs to be and update the installers. The hard part will be working with the FFmpeg executable reliably and getting all of the streams because you won't be able to manipulate it the same way you can with the libraries. Take a look at PrimeNetEncoder if you're curious what that might look like.

The reason why I don't prefer to have the sources downloaded and compiled by the packaging script is mostly because I'm trying to keep the required dev setup simple and able to compile installers on both Windows and Linux. If you haven't done it before, you'll quickly learn that compiling FFmpeg for Windows is fairly involved. My other lesser reason has more to do with how newer code can often mean new issues and sometimes breaks how we are compiling which makes the project even more difficult for someone that just wants to change a single line of code for example.

[Fuzzy]

of course, if you are going through that much - it may be simpler to add the sage protocols into ffmpeg instead, and have it do almost all the lifting.

[waylo]

Just as a FYI, my BitDefender antivirus just started picking up the wrapper binary as a virus for some reason. It blocked and quarantined and deleted it, which of course caused many tuning issues. This was eventually fixed by making it an exclusion to the virus scan.

Not sure why this false positive is popping up just now, probably a new virus definition update.

[Fuzzy]

Originally Posted by waylo

Just as a FYI, my BitDefender antivirus just started picking up the wrapper binary as a virus for some reason. It blocked and quarantined and deleted it, which of course caused many tuning issues. This was eventually fixed by making it an exclusion to the virus scan.

Not sure why this false positive is popping up just now, probably a new virus definition update.

because virus scanners are an over-intrusive waste in most cases, and can easily be replaced by safe computer use.

[bisongde]

Originally Posted by EnterNoEscape

You would need to implement a new consumer that uses the FFmpeg executable instead of the JavaCPP pre-compiled libraries. It shouldn't be difficult to create the new implementation, but to do this right, you also need to add 32-bit and 64-bit Windows and Linux binary to the bin directory in the project, add compiling scripts for updating the binary, update the readme on how to compile the binary from sources (they don't need to be in the OpenDCT project) and modify the RPM, DEB and MSI installers to include the FFmpeg binary preferably in it's own folder (./bin/ffmpeg). Of course I can help you get everything where it needs to be and update the installers. The hard part will be working with the FFmpeg executable reliably and getting all of the streams because you won't be able to manipulate it the same way you can with the libraries. Take a look at PrimeNetEncoder if you're curious what that might look like.

The reason why I don't prefer to have the sources downloaded and compiled by the packaging script is mostly because I'm trying to keep the required dev setup simple and able to compile installers on both Windows and Linux. If you haven't done it before, you'll quickly learn that compiling FFmpeg for Windows is fairly involved. My other lesser reason has more to do with how newer code can often mean new issues and sometimes breaks how we are compiling which makes the project even more difficult for someone that just wants to change a single line of code for example.

Yeah that's understandable, and maybe a bit for me to bite off to turn this around with the schedule I have for this project. Would be interested in digging into it long-term though.

If I can multicast a stream, would it be possible to somehow get OpenDCT to send the instructions to the tuner to send a secondary stream to a separate ffmpeg encoder process that would transcode and store recordings outside of Sage? That way I could use a version of ffmpeg that would be capable of hardware acceleration without extensive modification of OpenDCT.

What I'm imaging is a script to have ffmpeg take input streams like it would take file inputs at the command line, and being able to use the same kinds of switches to determine the encoders and presets used, etc.

Maybe I'm going about this the wrong way. Fuzzy, sounds like maybe you're being a little facetious with your suggestion, but if that's a viable option I'm open to exploring it.

[EnterNoEscape]

Originally Posted by bisongde

Yeah that's understandable, and maybe a bit for me to bite off to turn this around with the schedule I have for this project. Would be interested in digging into it long-term though.

If I can multicast a stream, would it be possible to somehow get OpenDCT to send the instructions to the tuner to send a secondary stream to a separate ffmpeg encoder process that would transcode and store recordings outside of Sage? That way I could use a version of ffmpeg that would be capable of hardware acceleration without extensive modification of OpenDCT.

What I'm imaging is a script to have ffmpeg take input streams like it would take file inputs at the command line, and being able to use the same kinds of switches to determine the encoders and presets used, etc.

Maybe I'm going about this the wrong way. Fuzzy, sounds like maybe you're being a little facetious with your suggestion, but if that's a viable option I'm open to exploring it.

I gave you pretty much what would need to be done to add what you were asking for. It has been something I was considering adding, but the number of users that would take advantage of it is so small it didn't feel like it was worth it. I feel that the place where this effort would be better spent would be updating and fixing up the FFmpeg used by SageTV for placeshifting so it could also be used to live transcode to disk. This would benefit all current and future network encoders.

I guess a consumer could be added that just blasts the stream somewhere other than SageTV, but there's information the receiver of that stream would need to know so that at least it writes to the correct file and at some point we would just be creating a "network encoder lite."

[nkd]

2 days ago I suddenly lost many channels, a rescan did not help. Something is messed up and I can not figure out what. I have done the following
1. Upgraded sage to the latest version (9.X)
2. Upgraded OpenDCT to the latest available stable version
3. Updated HDHomerun prime software and firmware
4. Checked on HDHomerun to make sure that the channels are available and viewed the video to ensure
5. Scanned for updated channels with Sage; no joy
6. Dialogue with ScheduleDirect support to make sure that the channels are indeed available

I am now out of ideas, any help would be appreciated

Neel

[waylo]

Check your antivirus to make sure it didn't kill any important parts to opendct.

Mine so helpfully killed the main binary needed for opendct to work (wrapper).

Edit: it wasn't clear if you lost all hdhr channels or just some. Do you have any other tuners?

[Tiki]

Originally Posted by nkd

2 days ago I suddenly lost many channels, a rescan did not help. Something is messed up and I can not figure out what. I have done the following
1. Upgraded sage to the latest version (9.X)
2. Upgraded OpenDCT to the latest available stable version
3. Updated HDHomerun prime software and firmware
4. Checked on HDHomerun to make sure that the channels are available and viewed the video to ensure
5. Scanned for updated channels with Sage; no joy
6. Dialogue with ScheduleDirect support to make sure that the channels are indeed available

I am now out of ideas, any help would be appreciated

Neel

What do you mean by "lost"?
Are they gone from your guide?
Do they not record correctly? What happens when you try to record or playback?
Are there error messages in the log?