OpenDCT: An open source digital cable tuner.

[EnterNoEscape]

Originally Posted by mistergq

Updated to 0.4.35 beta.

Homerun Prime with Cable card works fine.

Tried to setup a regular HDHR that is getting digital cable. Sage is not able to get a signal from it. Do I need to redo any discover?

You didn't do anything wrong. The QAM mapping is automatic and if you have an HDHomeRun Prime as your DCT, things are little more complicated because it needs to tune the channel on an available HDHomeRun Prime, get the frequency and program, then it use that on the HDHomeRun. The tuning is off by default because it might surprise someone. Anyway, to turn it on do the following:

1) Stop the OpenDCT service.
2) Change in opendct.properties channels.qam.automap_tuning_lookup to true.
3) Start the OpenDCT service.

After making that change, you should be able to tune into any ClearQAM channel. OpenDCT will remember what frequency and program was discovered so it will only be a little slow the first time you tune into a channel on the old HDHomeRun.

Originally Posted by Telecore

I have noticed two isolated problems on certain channels, but I am not sure if they can be attributed to OpenDCT. First of all, for some reason, the local CBS affiliate channel cannot be viewed on the V7 server (with OpenDCT), but it can on the V9 server. I have ignored this problem by mapping this channel exclusively to the ATSC tuner card. Second, there are very infrequent brief (ms) audio drop-outs that occur sometimes, but only on certain channels. Other channels have no noticeable audio glitches and all the video in both cases appears to be glitch-free.

Try changing sagetv.device.<unique_id>.consumer to opendct.consumer.FFmpegTransSageTVConsumerImpl for all of your tuners. You'll be using the new consumer that also supports transcoding, but without setting a profile (which is the default) which means you'll still just be remuxing. nyplayer at least saw some improvement with the new remuxer, so maybe it will help you too.

[EnterNoEscape]

Originally Posted by HelenWeathers

Is the CC data not embedded in the recording???

Part of adding support for converting closed captions to subtitles is because if you live transcode the video it will no longer contain the closed captions because FFmpeg doesn't currently support it.

Originally Posted by nyplayer

You have them on the extenders but not on the the PC SageTVClient open source or the Android MiniClient. They are in the recordings but SageTV has no way of exposing them like you stated. I have tried extracting them but SageTV does not process them correctly.

The .srt files I was able to generate from various content all appeared to be working really well and were in sync with the video. The only problem I ran into was SageTV really gets confused about what to use when a recording gets broken up. It kept trying to use the .srt file for the first file of the recording when it was on the second file of the recording.

When I ran it on the H.264 content that you gave me, it also worked well, but the 1080i clip only had Spanish for some reason. I extracted 5 fields and only one of them actually contained data.

I believe there is some light at the end of the tunnel since it sounds like eventually the placeshifter player will be changed from mplayer to a VLC based player which should have very good closed caption support based on that alone.

[waylo]

Originally Posted by nyplayer

There are no more extenders available to purchase so for any new users coming in and want to use SAGETV the open source SageTV does not Include the Sage Decoder and that is the only one that works with MPEG2 for CC as far as H.264 no CC in SageTV at all... SageTV never natively supported H.264 at all. Also there is no CC support in the MiniClient. Comcast in my area has almost completed the conversion to H.264 so I have mostly lost CC.

There are some 3rd party mpeg decoders that can display CC aside from Sage Decoder, but those do have to be installed separately. I personally use PowerDVD8.

[nyplayer]

Originally Posted by waylo

There are some 3rd party mpeg decoders that can display CC aside from Sage Decoder, but those do have to be installed separately. I personally use PowerDVD8.

They do not work in SageTV with H.264 content if you have one that works within SageTV please let me know ,,, and how to configure them. I have PowerDVD13 and it does not do CC in SageTV. It needs to work on PC Client.

The attachment is how Comcast broadcasts in my area. As you can see it has closed captions but sage cannot display them.

[Telecore]

Originally Posted by EnterNoEscape

Try changing sagetv.device.<unique_id>.consumer to opendct.consumer.FFmpegTransSageTVConsumerImpl for all of your tuners. You'll be using the new consumer that also supports transcoding, but without setting a profile (which is the default) which means you'll still just be remuxing. nyplayer at least saw some improvement with the new remuxer, so maybe it will help you too.

Thanks - the above change fixed the problem with the CBS station not being viewable via OpenDCT. Maybe there is an issue due to different firmware revisions on the 2 servers between the Ceton card where it worked and the one where it did not.

[EnterNoEscape]

I think one of the key differences is that in the old remuxer, time base for the stream is set to the time base for each codec. The outcome is we have a non-standard time base which should not throw off most players, but I could also see it possibly introducing rounding errors which might explain the audio glitches you were describing. The new remuxer uses source stream time base which generally results in the presentation time stamps being barely changed at all.

As an added bonus, the transcoding consumer does SWITCH better than the old one. It also writes asynchronously from the FFmpeg processing which may help on slower machines and it measurably improves transcoding performance. Eventually it will be replacing the old consumer as the default, but since it's young and it could have unknown problems, so I don't want to subject unwilling participants to that possibility.

The next release has improved tuning speed when the transcoding consumer is in use, so if you noticed a small slow down in tuning performance, that should be fixed in the next release.

[waylo]

Originally Posted by nyplayer

They do not work in SageTV with H.264 content if you have one that works within SageTV please let me know ,,, and how to configure them. I have PowerDVD13 and it does not do CC in SageTV. It needs to work on PC Client.

The attachment is how Comcast broadcasts in my area. As you can see it has closed captions but sage cannot display them.

I meant for those broadcasts still in mpeg2 format. A dwindling # of channels, for sure. In my area, it was initially limited to basic cable channels, but I noted today that CBS has made the switch (at least during the day). The other major stations are still mpeg2.

[waylo]

Thank you @enternoescape for all the work you've done and the support you provide.

I was wondering if you had any thoughts on why the music stations have had glitches with DCT tuning? On comcast.

These are the stations which stream music with slideshow-like pics/text/ads on the screen.

Specifically, they are slow to tune initially (no signal for maybe 10 seconds), but then play for the first 15 second or so. Inevitably they start skipping and eventually stop playing after these 15 seconds or so.

I first noticed this issue when I switched from SageDCT to PrimeNetEncode. I just switched to OpenDCT today and noticed it persists with the latest 0.4 beta x86.

Is this a problem that could be helped with the 'consumer' change you mention in the posts above?

[jgsouthard]

I just installed 0.4.35 Beta, and it seems to work fine on initial testing. But I noticed something odd in the logs. The time stamps in wrapper.log are correct, but the time stamps in opendct.log are all one hour earlier than the correct time.

[EnterNoEscape]

Originally Posted by waylo

I was wondering if you had any thoughts on why the music stations have had glitches with DCT tuning? On comcast.

These are the stations which stream music with slideshow-like pics/text/ads on the screen.

Specifically, they are slow to tune initially (no signal for maybe 10 seconds), but then play for the first 15 second or so. Inevitably they start skipping and eventually stop playing after these 15 seconds or so.

I first noticed this issue when I switched from SageDCT to PrimeNetEncode. I just switched to OpenDCT today and noticed it persists with the latest 0.4 beta x86.

Is this a problem that could be helped with the 'consumer' change you mention in the posts above?

This is actually something that I've been checking when I make changes. Music Choice with FiOS is working for me very well with either consumer. I left it playing for hours last week and it never stopped playing. No meaningful changes were made to the old consumer. The tuning time takes around 8-20 seconds and can't be improved because the video data is not frequent enough for FFmpeg to calculate things like framerate.

All of that being said. The newer consumer may help in your situation and likely will not hurt.

Originally Posted by jgsouthard

I just installed 0.4.35 Beta, and it seems to work fine on initial testing. But I noticed something odd in the logs. The time stamps in wrapper.log are correct, but the time stamps in opendct.log are all one hour earlier than the correct time.

That might be a daylight savings oversight in log4j2. Have you tried restarting the service?

[waylo]

Originally Posted by EnterNoEscape

This is actually something that I've been checking when I make changes. Music Choice with FiOS is working for me very well with either consumer. I left it playing for hours last week and it never stopped playing. No meaningful changes were made to the old consumer. The tuning time takes around 8-20 seconds and can't be improved because the video data is not frequent enough for FFmpeg to calculate things like framerate.

All of that being said. The newer consumer may help in your situation and likely will not hurt.

Thanks for the commentary. I'm guessing then it is something ffmpeg can't handle correctly with something Comcast-specific. With SageDCT, I could only use the 'dump' setting, and I recall (it was almost a year ago) those music channels worked okay. With PNE and OpenDCT using ffmpeg, the issue probably lies in there.

I will try changing the consumer setting and report back.

[EnterNoEscape]

Originally Posted by waylo

Thanks for the commentary. I'm guessing then it is something ffmpeg can't handle correctly with something Comcast-specific. With SageDCT, I could only use the 'dump' setting, and I recall (it was almost a year ago) those music channels worked okay. With PNE and OpenDCT using ffmpeg, the issue probably lies in there.

I will try changing the consumer setting and report back.

For a little while I thought we couldn't get the Music Choice type content to work with FFmpeg reliably and I was going to add the ability to use a different consumer based on the channel being tuned, but the reliability started to shape up and I thought that might be a little tedious. OpenDCT does also have a raw consumer, but I haven't really had a good reason to use it in a while. The raw consumer is opendct.consumer.RawSageTVConsumerImpl and would be the equivalent to dump in SageDCT.

[Telecore]

Originally Posted by Telecore

Thanks - the above change fixed the problem with the CBS station not being viewable via OpenDCT.

Experienced a halt while watching CBS with re-muxing enabled - apparently there was a stoppage of packets. Watched another show recorded from 8-9 that was 100% fine on AMC. Part of the wrapper.log file is attached from around the time of the halt.

[jarredduq]

Originally Posted by EnterNoEscape

For a little while I thought we couldn't get the Music Choice type content to work with FFmpeg reliably and I was going to add the ability to use a different consumer based on the channel being tuned, but the reliability started to shape up and I thought that might be a little tedious. OpenDCT does also have a raw consumer, but I haven't really had a good reason to use it in a while. The raw consumer is opendct.consumer.RawSageTVConsumerImpl and would be the equivalent to dump in SageDCT.

Music Choice is working for me with OpenDCT. It does take about 10 seconds to tune a music channel for some reason...

[EnterNoEscape]

Originally Posted by jarredduq

Music Choice is working for me with OpenDCT. It does take about 10 seconds to tune a music channel for some reason...

The long delay is because FFmpeg needs to know certain properties about the video and since those channels have very few video frames, it takes longer for it to get the information it's looking for. The unfortunate thing is that much of that data isn't relevant for just remuxing. SageTV also doesn't appear to start playing audio until it reaches a video key frame which can also add a few seconds.

[EnterNoEscape]

Originally Posted by Telecore

Experienced a halt while watching CBS with re-muxing enabled - apparently there was a stoppage of packets. Watched another show recorded from 8-9 that was 100% fine on AMC. Part of the wrapper.log file is attached from around the time of the halt.

I saw that only 3 packets made it in with no continuity errors after what I believe was at least 5 second. Even with Music Choice, that number should be in the hundreds if not the low thousands. The part that I don't understand is that the tuner says the channel doesn't have any copy protection (NONE actually means it's also not encrypted), but it's clearly shutting it off which is what happens when DRM kicks in. I suspect you're having the same problem I had with analog copy protection on that channel. That pretty much means you probably should just stay away from that channel with your InfiniTV tuners. Sorry we couldn't make any progress on this one, but I believe the tuner is at fault on this one.

[Fuzzy]

The flawed .SRT handling (live not refreshing the file, and not properly transitioning on multi-part recordings) are all fixable issues - so I wouldn't use that as a reason to NOT automatically extract SRT's from the recordings. It won't work right away, obviously, but it will give many at least some support (on post-live viewing in full single-file recordings), while the issue gets resolved on the sagetv end.

You definitely SHOULD create an issue or two on github so it can be logged, and hopefully someone gets a chance to look into it.

[EnterNoEscape]

Originally Posted by Fuzzy

The flawed .SRT handling (live not refreshing the file, and not properly transitioning on multi-part recordings) are all fixable issues - so I wouldn't use that as a reason to NOT automatically extract SRT's from the recordings. It won't work right away, obviously, but it will give many at least some support (on post-live viewing in full single-file recordings), while the issue gets resolved on the sagetv end.

You definitely SHOULD create an issue or two on github so it can be logged, and hopefully someone gets a chance to look into it.

I agree with everything you have said.

I am going to add support either way. I just didn't want anyone to get too excited since the initial experience might be less than they hoped for. Additional libraries will need to be added to the project to add support for CCExtractor and I haven't decided how I want to integrate it yet.

[Telecore]

Originally Posted by EnterNoEscape

I saw that only 3 packets made it in with no continuity errors after what I believe was at least 5 second. Even with Music Choice, that number should be in the hundreds if not the low thousands. The part that I don't understand is that the tuner says the channel doesn't have any copy protection (NONE actually means it's also not encrypted), but it's clearly shutting it off which is what happens when DRM kicks in. I suspect you're having the same problem I had with analog copy protection on that channel. That pretty much means you probably should just stay away from that channel with your InfiniTV tuners. Sorry we couldn't make any progress on this one, but I believe the tuner is at fault on this one.

Thanks for looking at this - I am going to update the Ceton firmware from 13.5.6.132 to 14.10.3.163. The newer firmware is on my other SageTV system (both have Infinitv6 PCIe's) and I have never seen this problem there. Also, thanks a lot for your hard work on OpenDCT.

[EnterNoEscape]

While I'm on the topic of compiling. I really don't want to continue support for 32-bit Linux kernels once we hit 0.5 because I'm going to start doing some compiling of native code (FFmpeg, CCExtractor) and I don't want to have 6 different configurations to compile for and test against.

Is anyone using a 32-bit Linux distribution?