OpenDCT: An open source digital cable tuner.

[realcap]

Originally Posted by realcap

Starting to receive a number of system error messages due with halts while recording and at the beginning of recordings. Several occurred this evening. Please direct me to the correct settings needed to solve. My log file is attached.
Thanks,
Mike

This log file should now contain data. Thanks again, Mike

[EnterNoEscape]

Originally Posted by boukmandutty

I think it might have been network related. I use a MoCA network hacked up via some fios modems to get my cox connection between rooms (I hate cox!). I noticed that when I plug the hdhomerun prime directly into the cable modem there is no stutter or any sort. I notice it still takes me a long time to tune channels though.

What I did notice this evening though is a recording failure that seems to have been caused by my windows media center computer using the tuner at the same time.

Does opendct move automatically to the next tuner if the one assigned for a recording is being used? I actually have to use Windows Media center because everything except local channels has drm (I hate cox so much!). Doesn't OpenDCT play nice with other programs?

My log is attached.

What you are describing is pooling. Pooling is not enabled by default because it will use any capture device it can load by default too which might cause undesirable behavior and it's confusing from the SageTV side of things because it doesn't change the name of the capture device to the one that actually did the capturing. To enable it, do the following:

Stop the OpenDCT service.
Open opendct.properties.
Change pool.enabled=false to true.
Save the file.
Start the OpenDCT service.

[EnterNoEscape]

Originally Posted by realcap

This log file should now contain data. Thanks again, Mike

Everything actually looks ok from the log perspective. The only suggestion I could give you is to upgrade to the latest beta since you're a little behind and I have fixed a lot of little things since that release.

[realcap]

Updated to 5.8 beta. Recording 2 news programs at 18:30 and received halt errors for both recordings. Have attached the log file for your review. Thanks for taking a look and helping me out with any suggested modifications.
Mike

[Fuzzy]

Originally Posted by realcap

Updated to 5.8 beta. Recording 2 news programs at 18:30 and received halt errors for both recordings. Have attached the log file for your review. Thanks for taking a look and helping me out with any suggested modifications.
Mike

Something got tweaked in you configuration somewhere. OpenDCT is calling your configured tuners:
DCT-HDHomeRun Prime Tuner 1319F1B6-1
DCT-HDHomeRun Prime Tuner 1319F1B6-2
DCT-HDHomeRun Prime Tuner 1319F1B6-3

but sage is referring to them as:
DCT-HDHRun 1319F1B6-1
DCT-HDHRun 1319F1B6-2
DCT-HDHRun 1319F1B6-3

So OpenDCT doens't know which tuner to use, giving the error message of:
DEBUG SageTVManager - The capture device 'DCT-HDHRun 1319F1B6-2' is not yet available.
because it does not have a tuner named as such. Did you by chance change the name of the encoders in the mmc/encoders section of your sage.properties file? These names have to match.

[EnterNoEscape]

Originally Posted by Fuzzy

So OpenDCT doens't know which tuner to use, giving the error message of:
DEBUG SageTVManager - The capture device 'DCT-HDHRun 1319F1B6-2' is not yet available.
because it does not have a tuner named as such. Did you by chance change the name of the encoders in the mmc/encoders section of your sage.properties file? These names have to match.

That log looks a lot different from the first one. If you want to change the names of the capture devices, you have to do it in opendct.properties or it won't know you changed the names.

Update: Comparing this to the previous log, it would suggest you probably deleted opendct.properties. You don't need to do this (I don't), but some members have been so that they will see the latest defaults if they changed. If you're deleting that file, you need to note what you changed and re-do your changes especially if you changed the device names.

[realcap]

Thanks, Fuzzy! I corrected all of the tuner names in both OpenDCT and Sagetv properties files to match. I have no idea how these got mixed up because I did not manually change any of the names. Only updated OpenDCT to the 5.8 version. I also had to update the Video Sources in SageTV but no problem.

My Sagetv properties files has many old video source records such as:
mmc/encoders/123456970/video_capture_device_name=SageDCT-HDHomeRun Prime Tuner 1319F1B6-2

Is there any problem in deleting all of the old ones that are no longer used?

Mike

[realcap]

Originally Posted by EnterNoEscape

That log looks a lot different from the first one. If you want to change the names of the capture devices, you have to do it in opendct.properties or it won't know you changed the names.

Update: Comparing this to the previous log, it would suggest you probably deleted opendct.properties. You don't need to do this (I don't), but some members have been so that they will see the latest defaults if they changed. If you're deleting that file, you need to note what you changed and re-do your changes especially if you changed the device names.

Thanks EnterNoEscape, you are correct, I followed the instructions provided in the link contained in your first post and deleted the opendct.properties file. I'll now go back and make the other changes from my previous properties file. All seems to be working now. Greatly appreciate all of your efforts and attention to all of us SageTV dummies. Mike

[EnterNoEscape]

Originally Posted by realcap

Thanks EnterNoEscape, you are correct, I followed the instructions provided in the link contained in your first post and deleted the opendct.properties file. I'll now go back and make the other changes from my previous properties file. All seems to be working now. Greatly appreciate all of your efforts and attention to all of us SageTV dummies. Mike

Thanks for pointing that out. I added a note about deleting the file.

[Fuzzy]

So, I created a docker template for OpenDCT. As far as I can tell on my end, it's working okay (only tested media server mode - because I can't see a reason to use anything else). If anyone wants to give it a try, the repository for it should be at:

https://github.com/crazifuzzy/opendct-docker

In unRAID, add that to your docker repositories, and you can probably create a new container using all defaults.

[EnterNoEscape]

Originally Posted by Fuzzy

So, I created a docker template for OpenDCT. As far as I can tell on my end, it's working okay (only tested media server mode - because I can't see a reason to use anything else). If anyone wants to give it a try, the repository for it should be at:

github.com/crazifuzzy/opendct-docker

In unRAID, add that to your docker repositories, and you can probably create a new container using all defaults.

Thank you so much for doing this! Hopefully when I get done with the EPG stuff, I'll get a chance to test this on Unraid.

[Fuzzy]

Originally Posted by EnterNoEscape

Thank you so much for doing this! Hopefully when I get done with the EPG stuff, I'll get a chance to test this on Unraid.

There is much I could add to it, but for now it seems to get up and working quickly. No current version checking or anything, so right now it just pulls down the 0.5.8-1.

[mlcarson]

HDHomerun Prime
Model: HDHR3-CC
Device ID: 131D2C6C
Firmware: 20150826
Cable Provider: Comcast - Santa Maria, CA

I'm having abnormally long channel changes using OpenDCT. This is true on both the stable 0.4.49 and the latest beta 0.5.8 versions. Channel changes vary between 8-15 seconds but at least one channel times out at 15 seconds and literally takes 1 minute to tune (MPLEX).

I've changed the OpenDCT Properties file "Delay_to_wait_after_tuning" from 0 to 500 but it made no difference in the channel delay. The HDHomerun View app changes channel instantly.

I've attached the opendct.log file.

This is a Comcast H.264 area and the log indicates:
04:21:07.357 [FFmpegTransSageTVConsumerImpl-135CT-HDHomeRun Prime Tuner 131D2C6C-2] ERROR h264 - [3c377ca0] non-existing SPS 0 referenced in buffering period
04:21:07.357 [FFmpegTransSageTVConsumerImpl-135CT-HDHomeRun Prime Tuner 131D2C6C-2] ERROR h264 - Repeated 1 time: [3c377ca0] non-existing SPS 0 referenced in buffering period.

See the actual attachment for the entire log.

[jm9843]

Originally Posted by Fuzzy

So, I created a docker template for OpenDCT. As far as I can tell on my end, it's working okay (only tested media server mode - because I can't see a reason to use anything else).

FFMpeg is still working when the MediaServer fails for some of us, likely because of the open issue Built in remuxer does not detect any streams on some channels.

[mlcarson]

In case it matters, I grabbed the latest firmware from SD which was labeled 20160809atest1.exe but the HDHomeRun Prime webpage shows the firmware as 20160630atest2 after the update. It didn't seem to make any difference with respect to the slow tuning problem.

[EnterNoEscape]

Originally Posted by jm9843

FFMpeg is still working when the MediaServer fails for some of us, likely because of the open issue Built in remuxer does not detect any streams on some channels.

There's the media server remuxer which always requires the media server, then there's just using the media server. They are actually different things. You can use FFmpeg and write the recording file using upload ID (which is the media server), for example.

[EnterNoEscape]

Originally Posted by mlcarson

HDHomerun Prime
Model: HDHR3-CC
Device ID: 131D2C6C
Firmware: 20150826
Cable Provider: Comcast - Santa Maria, CA

I'm having abnormally long channel changes using OpenDCT. This is true on both the stable 0.4.49 and the latest beta 0.5.8 versions. Channel changes vary between 8-15 seconds but at least one channel times out at 15 seconds and literally takes 1 minute to tune (MPLEX).

I've changed the OpenDCT Properties file "Delay_to_wait_after_tuning" from 0 to 500 but it made no difference in the channel delay. The HDHomerun View app changes channel instantly.

I've attached the opendct.log file.

This is a Comcast H.264 area and the log indicates:
04:21:07.357 [FFmpegTransSageTVConsumerImpl-135CT-HDHomeRun Prime Tuner 131D2C6C-2] ERROR h264 - [3c377ca0] non-existing SPS 0 referenced in buffering period
04:21:07.357 [FFmpegTransSageTVConsumerImpl-135CT-HDHomeRun Prime Tuner 131D2C6C-2] ERROR h264 - Repeated 1 time: [3c377ca0] non-existing SPS 0 referenced in buffering period.

See the actual attachment for the entire log.

That error comes from H.264 content. It means the packet is referencing a frame that doesn't exist. Because FFmpeg wants to understand more than it actually needs to know about the streams, for just remuxing, this can take a while with H.264 content. Then the data is written out fairly fast; depending on your disk performance. Then SageTV needs to buffer and decode the content which can be just as taxing on the system.

I see the worst detection in there took less than 4 seconds to complete and start writing. Writing took almost 6 seconds though. I think I can see a problem here that I didn't consider and is actually due to all of those bad packets. OpenDCT waits for all of the data used for detection to be written out before it returns OK to SageTV. The bad packets that never get written go towards the data to be written and since the stream is already a low bitrate, it takes a while to reach the expected amount of data to be written. This is no longer needed since we worked out some of the bad problems with MPEG2-PS format detection in the latest SageTV builds. I'll get rid of that wait in the next beta release.

[RangerZ]

After 6 years I have done a clean install of Win 7 on a 64bit Dell i5 and now looking to reinstall SageTV. I plan to use a single Silicon Dust HDHR3-CC with OpenDCT (v20150604) and have RCN cable service.

I have not read the entire 60 plus pages so some of this may have been addressed. What I have read is to deep at this time. With all the version changes is there some more reasonable place to start in the thread.

I plan to use the 4.49 stable release, unless there are some good reasons to use 5.8 beta.

Does OpenDCT need to be installed on both server and client machines or only the server machine?

The java recommendation seems a bit wishy washy. I have both versions installed to support 64 bit IE and 32 bit Mozilla, though plan to use Mozilla. Is there an advantage to using 64 bit and, regarding my first question, what if I have a 32 bit client?

My current config also has an older OTA SD Dual Tuner which I will be eliminating in the new install. I want to keep it (preferably) for the short term in the running system. The docu on this config is vague (https://github.com/enternoescape/opendct item 3)

Edit opendct.properties per the section below if you want to limit what it should discover otherwise continue to the next step.

Windows: From the Start Menu, open OpenDCT Properties.

Will I see a list of discovered devices or do I need to explicitly enter something?

Are there any recommendations for Silicon Dust firmware for use with 4.49. When I moved to 20140604 I feel it caused problems with my OTA tuner, so I am a bit gun shy. I also read somewhere I do not need to install the HDHR software (Player?). Not clear I have this right. Last I recall the Player and Firmware were all in one.

I used SageDCT and PNE in the past. If I recall when SageDCT was installed I moved from MPEG recording files to TS files. I do not know what OpenDCT produces or if it can be controlled. Not smart enough to know the differences or if I should care. I tend to think MPEG is more universal, but not had an issue playing or trans-coding either. Related, I could use direction on best choices for Video\Audio setup. For what it's worth I generally record and watch in SageTV, a small amount of trans-coding for my iPhone and VLC for machines with no SagTV installed.

I don't know what I don't know. I appreciate any clarification I can get.

[mlcarson]

HDHomeRun PRIME
Model: HDHR3-CC
Device ID: 131D2C6C
Firmware: 20160630atest2
Card Authentication: success
Card OOB Lock:success
Card Validation: success

3:04:59 Changing Channel from channel 139 Elrey to 072 TVLDW.
3:06:12 Video starts

The HDHomeRUN prime shows the actual tuning taking 1 sec.
20160828-10:04:26 Tuner: tuner2 tuning 139 ELREY (auto:255MHz-3214)
20160828-10:04:26 Tuner: tuner2 streaming http to 192.168.1.107:17186
20160828-10:04:26 CableCARD: tuner2 139 ELREY (auto:255MHz-3214) access = subscribed
20160828-10:05:02 Tuner: tuner2 tuning 72 TVLDW (auto:249MHz-2413)
20160828-10:05:02 Tuner: tuner2 streaming rtp to 192.168.1.107:8452
20160828-10:05:03 CableCARD: tuner2 72 TVLDW (auto:249MHz-2413) access = subscribed

The other logs that I uploaded also had examples of this but this time I'm attaching logs for just this one channel change. Typical channel changes take 10-13 secs before video appears but certain channel changes like this one take a minute or more. Neither station is using H.264. The FFmpegTransSageTVConsumerImpl just takes 72.464 secs before it can detect the streams.

[EnterNoEscape]

Originally Posted by mlcarson

HDHomeRun PRIME
Model: HDHR3-CC
Device ID: 131D2C6C
Firmware: 20160630atest2
Card Authentication: success
Card OOB Lock:success
Card Validation: success

3:04:59 Changing Channel from channel 139 Elrey to 072 TVLDW.
3:06:12 Video starts

The HDHomeRUN prime shows the actual tuning taking 1 sec.
20160828-10:04:26 Tuner: tuner2 tuning 139 ELREY (auto:255MHz-3214)
20160828-10:04:26 Tuner: tuner2 streaming http to 192.168.1.107:17186
20160828-10:04:26 CableCARD: tuner2 139 ELREY (auto:255MHz-3214) access = subscribed
20160828-10:05:02 Tuner: tuner2 tuning 72 TVLDW (auto:249MHz-2413)
20160828-10:05:02 Tuner: tuner2 streaming rtp to 192.168.1.107:8452
20160828-10:05:03 CableCARD: tuner2 72 TVLDW (auto:249MHz-2413) access = subscribed

The other logs that I uploaded also had examples of this but this time I'm attaching logs for just this one channel change. Typical channel changes take 10-13 secs before video appears but certain channel changes like this one take a minute or more. Neither station is using H.264. The FFmpegTransSageTVConsumerImpl just takes 72.464 secs before it can detect the streams.

Something is very wrong with that stream. FFmpeg never actually figured out what the program number was probably because it was missing very important packets and since the data comes in at such a low bitrate, it took even longer for it to just go with what it could find and start streaming that. Unfortunately I can't really improve on that since the logic behind that decision is within the FFmpeg binary which I am not going to be customizing.

I also double-checked what "program stream index 0 is null" means and it literally happens because FFmpeg can't get program number. Because that value is not set yet, no audio or video are usable as far as OpenDCT is concerned. As soon as that value was set is when the streaming started.

We might be able to get FFmpeg to just stream a video and audio stream without any program being associated which works out fine for a player, but when remuxing, we risk grabbing the wrong streams or leaving streams out completely which people would definitely notice. I'll have to think about this one a little because I feel like fixing your problem could break things badly for others who were not having any problems before. I can say whatever I come up with will likely still involve at least a 15 second wait on the particularly bad channels you have because of the previously mentioned possibilities.