OpenDCT: An open source digital cable tuner.

[EnterNoEscape]

Originally Posted by Telecore

Log file is attached. The other two times, the video eventually appeared after the initial "copy once" - CBS is no surprise but also happened in recording of SNL on Sat. Night.

Update/Correction: Both CBS incidents resulted in a black screen with audio for the whole show, BUT comskip somehow found the commercial boundaries in the shows. The NBC incident recovered after about a minute such that video and audio were present.

That's exactly what happened: analog copy protection. I knew I should have put an option in there to turn the messages off. You'll get that option in the next beta. I suspect Comskip found the commercials because it sees each file as an individual container. SageTV sees them all as one container and it bases it's information off of the very first one, so if they have different audio/video properties, you end up with exactly what you described. I know this because sometimes I forget to delete old segments before I change the video format and SageTV will not be able to play the new segments back.

[EnterNoEscape]

Originally Posted by jusjoken

Just guessing but may this be related to.....

How to add BDA support to Windows Server 2012

From <https://knowledge.zomers.eu/dvblogic...rver-2012.aspx>

SageTV uses the BDA drivers for the HDHomeRun devices in Windows, but OpenDCT does not, so this will likely be unnecessary unless you would like to set the capture device up as a "native" SageTV capture device instead of through OpenDCT.

[troll5501]

Originally Posted by EnterNoEscape

The code behind this is actually very simple and does almost everything possible to prevent this from happening. Every single step is checked to make sure it points to an actual object. It's almost safe to say this is a bug in FFmpeg, but there is one more thing that can be checked and I'll make sure it makes it into 0.5 (probably not 0.4), because I think this particular bug is very rare.

I had two more of these JVM crashes this morning, one at 08:12 (OpenDCT had been running for 7 days) and then another one at 8:15 after it was only running for 3 minutes. I know you said this should be a rare event, but let me know if I can provide any logs or JVM hs_err files that may help in finding/validating the root cause of this issue.

This is with OpenDCT 0.4.48 and Java 1.8.0_72.

Here are the final opendct.log log entries just prior to each crash:

08:12:30.258 [FFmpegTransSageTVConsumerImpl-36388:DCT-HDHomeRun Prime Tuner 13191941-1] INFO  FFmpegStreamDetection - After avformat_find_stream_info() pos=0 bytes_read=1459444 seek_count=1. probesize: 165440 analyzeduration: 0.

08:15:39.233 [FFmpegTransSageTVConsumerImpl-120:DCT-HDHomeRun Prime Tuner 13191941-2] INFO  FFmpegStreamDetection - After avformat_find_stream_info() pos=0 bytes_read=1504188 seek_count=1. probesize: 165440 analyzeduration: 0.

Both SIGSEGV crashes occured in:

# Problematic frame:
# C  [libjniavformat.so+0x31527]  Java_org_bytedeco_javacpp_avformat_00024AVStream_codec__+0x47

[EnterNoEscape]

Originally Posted by troll5501

I had two more of these JVM crashes this morning, one at 08:12 (OpenDCT had been running for 7 days) and then another one at 8:15 after it was only running for 3 minutes. I know you said this should be a rare event, but let me know if I can provide any logs or JVM hs_err files that may help in finding/validating the root cause of this issue.

This is with OpenDCT 0.4.48 and Java 1.8.0_72.

Here are the final opendct.log log entries just prior to each crash:

08:12:30.258 [FFmpegTransSageTVConsumerImpl-36388:DCT-HDHomeRun Prime Tuner 13191941-1] INFO  FFmpegStreamDetection - After avformat_find_stream_info() pos=0 bytes_read=1459444 seek_count=1. probesize: 165440 analyzeduration: 0.

08:15:39.233 [FFmpegTransSageTVConsumerImpl-120:DCT-HDHomeRun Prime Tuner 13191941-2] INFO  FFmpegStreamDetection - After avformat_find_stream_info() pos=0 bytes_read=1504188 seek_count=1. probesize: 165440 analyzeduration: 0.

Both SIGSEGV crashes occured in:

# Problematic frame:
# C  [libjniavformat.so+0x31527]  Java_org_bytedeco_javacpp_avformat_00024AVStream_codec__+0x47

Well...it should have been a rare event. I saw this one back in February and I put some code in place to try and prevent it from happening and didn't have another incident since. I'll see what I can do with the link you sent me.

Update: I guess this isn't the same issue, that file didn't trigger it.

Update2: The one thing those both have in common is they are using nearly the minimum amount of probe data. 0.5.3 is a little smarter about how it uses that value. I'll see if I can pull some of those improvements into 0.4.

[EnterNoEscape]

• Backported the FFmpeg stream detection from 0.5.3.
• Added some more null pointer checking.
• Fixed some wording in the consumer factory logging.

[troll5501]

Originally Posted by EnterNoEscape

• Backported the FFmpeg stream detection from 0.5.3.
• Added some more null pointer checking.
• Fixed some wording in the consumer factory logging.

Thanks! I already installed 0.4.49 and I'll let you know if I see any more issues.

[EnterNoEscape]

Originally Posted by troll5501

Thanks! I already installed 0.4.49 and I'll let you know if I see any more issues.

I really hope this gets you working. What's the point in having something labeled stable if it crashes once a week?

[wayner]

I haven't been paying attention to OpenDCT since I am in Canada and we can't get CableCARDs from our cable companies.

But it looks like this project is getting broader in scope in seeing the Github correspondence.

Can OpenDCT now be used to tune streams, such as from an IP web camera? That would be hugely useful to me if that were the case.

[brandypuff]

It's not designed for that but it is a neat idea.

[wayner]

Originally Posted by brandypuff

It's not designed for that but it is a neat idea.

Isn't there discussion about streaming IPTV. What is the difference between that and an IP cam that can produce a ffmpeg or mjpeg type stream from a URL like http://192.168.1.50/videostream.cgi?user=[USERNAME]&pwd=[PASSWORD]

I have tried other solutions like WebFeedEncoder but that required VLC as an intermediate step and VLC tends to be unreliable, at least for me.

[EnterNoEscape]

Originally Posted by wayner

Isn't there discussion about streaming IPTV. What is the difference between that and an IP cam that can produce a ffmpeg or mjpeg type stream from a URL like http://192.168.1.50/videostream.cgi?user=[USERNAME]&pwd=[PASSWORD]

I have tried other solutions like WebFeedEncoder but that required VLC as an intermediate step and VLC tends to be unreliable, at least for me.

OpenDCT is optimized for incoming MPEG-TS. I have tested it with other formats out of curiosity, but for for varying reasons MPEG-TS is the only thing it really does well. There's nothing stopping you from trying it anyway, but if it doesn't work, don't be surprised.

[tmiranda]

Originally Posted by wayner

Isn't there discussion about streaming IPTV. What is the difference between that and an IP cam that can produce a ffmpeg or mjpeg type stream from a URL like http://192.168.1.50/videostream.cgi?user=[USERNAME]&pwd=[PASSWORD]

I have an idea on how to do this but have no device for testing. Any suggestions on a VERY cheap test device or would you be willing to make the feed publicly available for a short time?

[EnterNoEscape]

I should probably mention too that you do have the option to have OpenDCT just download the raw stream. I don't know how well that works with IP cameras; all of the IP cameras that I have are attached to Raspberry Pi's.

[jmv]

I've done a little digging and it looks like my firmware is all up to date. It looks like for my ATSC HDHomeRuns 20150406 is the current Firmware (if you check in the HDHomerun directory you'll see each of the firmwares for each of the various Silicondust devices and for mine they are hdhomerun3_atsc_firmeware_20150406.bin and hdhomerun_atsc_firmware_20150406.bin)...

So is there anything you can do on your end to figure out why OpenDCT is not seeing my last HDHomerun? I would like to migrate this system to replace my current system this weekend, so any help would be appreciated.

I also downgraded to the stable release to see if that would help...but no deal...I did notice in the log that it says under the unsupported tuner HDHomeRunDiscovery - HDHomerun device returned an unknown tag with the length 35. Also, this is a 2 tuner device, but OpenDCT seems to be asking the device about tuners 0,1,2 (3 tuners). This unit is also different in HDHomeRun Setup in that for the 2 other ATSC tuners it lists the tuners like 10103591-0 with 1 Tuner and 10103591-1 with 1 Tuner, but for the HDHomerun Prime and the HDHR3 it lists only the Device without the -0 or -1 and lists Tuners as 3 and 2 respectively. I've attached the full log...please let me know if I can do anything to help trouble shoot.

08:54:04.457 [HDHomeRunDiscoveryReceive-36] INFO HDHomeRunDiscoverer - Discovered a new HDHomeRun device 'HDHomeRun HDHR3-US 103B91FB'.
08:54:04.547 [HDHomeRunDiscoveryReceive-36] DEBUG HDHomeRunControl - key: '/tuner0/lockkey' value: 'null' lockKey: '0' sendLength: 26
08:54:04.548 [HDHomeRunDiscoveryReceive-36] DEBUG HDHomeRunControl - key: '/tuner1/lockkey' value: 'null' lockKey: '0' sendLength: 26
08:54:04.549 [HDHomeRunDiscoveryReceive-36] DEBUG HDHomeRunControl - key: '/tuner0/lockkey' value: 'null' lockKey: '0' sendLength: 26
08:54:04.550 [HDHomeRunDiscoveryReceive-36] DEBUG HDHomeRunControl - key: '/tuner1/lockkey' value: 'null' lockKey: '0' sendLength: 26
08:54:04.552 [HDHomeRunDiscoveryReceive-36] DEBUG HDHomeRunControl - key: '/tuner0/lockkey' value: 'null' lockKey: '0' sendLength: 26
08:54:04.553 [HDHomeRunDiscoveryReceive-36] DEBUG HDHomeRunControl - key: '/tuner1/lockkey' value: 'null' lockKey: '0' sendLength: 26
08:54:04.554 [HDHomeRunDiscoveryReceive-36] DEBUG HDHomeRunControl - key: '/tuner2/lockkey' value: 'null' lockKey: '0' sendLength: 26
08:54:04.555 [HDHomeRunDiscoveryReceive-36] DEBUG HDHomeRunDiscovery - HDHomerun device returned an unknown tag with the length 35

mv

[JustFred]

Other than the support for tuner locking, is there any advantage of using OpenDCT to manage/control the HDHomerun tuners? Assuming ATSC and/or ClearQam, why not simply use Sage's built-in control?

[nyplayer]

Originally Posted by JustFred

Other than the support for tuner locking, is there any advantage of using OpenDCT to manage/control the HDHomerun tuners? Assuming ATSC and/or ClearQam, why not simply use Sage's built-in control?

Tuner pooling if you want to be able to share the tuners with other devices or DVR software. Also force unlock if tuners are being used by another device or APP If SageTV needs the tuner it will take over the tuner.


For EX.
I share all my tuners with my test System and the HDHomerun DVR.... but SageTV production system has first priority because of forced tuner unlock. I am able to watch TV on my Android devices and not worry about interrupting a Sage recording.

[jmv]

I was also trying to avoid the BDA items as my platform is Windows Server 2012 R2 it doesn't natively support...

To try to understand if this is my issue or a capability not yet present in OpenDCT, is anyone successfully running an HDHR3-US model tuner with OpenDCT?

[EnterNoEscape]

Originally Posted by jmv

I've done a little digging and it looks like my firmware is all up to date. It looks like for my ATSC HDHomeRuns 20150406 is the current Firmware (if you check in the HDHomerun directory you'll see each of the firmwares for each of the various Silicondust devices and for mine they are hdhomerun3_atsc_firmeware_20150406.bin and hdhomerun_atsc_firmware_20150406.bin)...

So is there anything you can do on your end to figure out why OpenDCT is not seeing my last HDHomerun? I would like to migrate this system to replace my current system this weekend, so any help would be appreciated.

I also downgraded to the stable release to see if that would help...but no deal...I did notice in the log that it says under the unsupported tuner HDHomeRunDiscovery - HDHomerun device returned an unknown tag with the length 35. Also, this is a 2 tuner device, but OpenDCT seems to be asking the device about tuners 0,1,2 (3 tuners). This unit is also different in HDHomeRun Setup in that for the 2 other ATSC tuners it lists the tuners like 10103591-0 with 1 Tuner and 10103591-1 with 1 Tuner, but for the HDHomerun Prime and the HDHR3 it lists only the Device without the -0 or -1 and lists Tuners as 3 and 2 respectively. I've attached the full log...please let me know if I can do anything to help trouble shoot.




mv

The unknown tag entry isn't significant. In fact Silicondust says not to log it. I'm just being defiant. I plan on releasing an new version this week. I just added a few changes that could be significant regarding the new HTTP capture device and I want to make sure they work as expected.

[EnterNoEscape]

• Added code to make sure if DRM is encountered mid-recording, the recording doesn't get completely wiped. Instead the message will be appended to the end.
• Added a little more logging around capture device detection and loading.
• Added handling for when SageTV makes a second request while we are still waiting for the resolution to change on HTTP capture devices.
• Added option to turn off the copy protection videos. Set error_videos_enabled to false to disable the videos.
• Added assumption that 0 tuners on an HDHomeRun device should be 2. If this adjustment is needed and wasn't expected, it will appear in the logs.
• Added HTTP HDMI capture device to the device presented to SageTV. In a future release of SageTV 9, you will be able to use the local SageTV server tuning plugins instead of the tuning executables.
• Moved streaming to start before tuning_executable and after pretuning_executable. This results in the streaming starting sooner.
• Due to the change above now if your script/executable returns the exit code 12000, all currently buffered data will be dumped. This is mostly useful if the channel resolution changed so you don't get a recording containing the event.
• Fixed a number formatting exception.
• Fixed multiple calls to get the OS version when it's already a static final value.
• Internal: Capture devices now understand different device types as requested by SageTV.

[jmv]

Thank you! We have signs of life. The HDHR3 showed up in sagetv, seemed to have both tuners available, I added both. But when I went to record, I tried recording 6 shows to fill all the OTA tuners, and it got to 5 but didn't give me the 6th. All 5 of the working tuners recorded correctly. So we have one of the 2 HDHR3-US tuners now getting all the way to being seen as a tuner in sage. Not sure why it would allow me to see the tuner in SageTV tuner setup, appear to add it, but not have it appear to work when I tried to record the 6th show. I've attached the OpenDCT log in case it helps.

I don't have a lot of time this AM, but I did briefly look at the SageTV summary details and it didn't seem to have all the tuners listed where I would normally see all 9 telling me some were idle and some were active, it only showed 8 of the tuners, only 1 for the HDHR3-US.

thanks for all your support.

mv