OpenDCT: An open source digital cable tuner.

[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.

Thanks! Is it some kind of pointer issue? I'm planning to move to 0.5 very soon but I may wait until 0.5.3 since it looks like you've made quite a few changes since 0.5.2.

[EnterNoEscape]

Originally Posted by troll5501

Thanks! Is it some kind of pointer issue? I'm planning to move to 0.5 very soon but I may wait until 0.5.3 since it looks like you've made quite a few changes since 0.5.2.

As you might already know, the error basically means it doesn't have access to the memory address that it's trying to access. In this specific location, the only thing I can do is make sure the pointer actually points to a valid address aka, not zero. If it has an address, there's a 99% certainly that it was allocated at some point and something unexpectedly deallocated it. I blame FFmpeg because the pointer OpenDCT is trying to access could have only been allocated by it's own methods during stream detection.

[EnterNoEscape]

Generic HTTP Capture Device (this is also on the very first post and GitHub for reference):

• Creating Capture Devices for Editing

  Create names for them under the property generic.http.device_names_csv in opendct.properties separated by commas. Start the OpenDCT service, let it run for a few seconds, then stop it. You should now see entries in opendct.properties that have the property sagetv.device.<unique_id>.device_name matching the name of the devices you requested. The names can really be anything, just don't use commas in the names for what should be obvious reasons.

  Ex. generic.http.device_names_csv=Encoder 1,Encoder 2

• sagetv.device.<unique_id>.channel_padding=

  This is the minimum length to be passed for the %c% variable. Values shorter than this length will have zeros (0) appended to the left of the channel to make up the difference. (Ex. 8 becomes 008 if this is set to 3.)

• sagetv.device.<unique_id>.custom_channels=

  This is an optional semicolon delimited list of channels you want to appear in SageTV for this device. This is a shortcut around creating an actual OpenDCT lineup. If there are any values in the field, they will override the lineup assigned to this capture device on a channel scan. This provides an easy way to add channels if you are not actually going to use guide data.

• sagetv.device.<unique_id>.pretuning_executable=

  This is an optional executable that if defined, will always be run before actually tuning the channel. You can add the channel as an argument by using the variable %c%. Don't forget to escape backslashes (\ needs to be \\).

• sagetv.device.<unique_id>.stopping_executable=

  This is an optional executable that if defined, will always be run when the capture device is told to stop. You can add the last tuned channel as an argument by using the variable %c%. Don't forget to escape backslashes (\ needs to be \\).

• sagetv.device.<unique_id>.streaming_url=

  This is a URL that points directly to an audio/video stream. HLS and m3u8 playlists are not supported at this time.

• sagetv.device.<unique_id>.streaming_url2=

  This is an alternative URL that points directly to an audio/video stream. This stream will only be used if a channel matches one of the ranges in streaming_url2_channels. HLS and m3u8 playlists are not supported at this time.

• sagetv.device.<unique_id>.streaming_url2_channels=

  This is the channel ranges that will use the alternative URL. This uses the same formatting as the dynamic consumer channel ranges.

• sagetv.device.<unique_id>.tuning_delay_ms=0

  This is the amount of time in milliseconds to wait after the program associated with tuning_executable has returned.

• sagetv.device.<unique_id>.tuning_executable=

  This is an optional executable that if defined will be used to change the channel being streamed. Insert %c% where the channel needs to be provided to the executable. If %c% isn't provided, but this property is defined, the channel number will be appended as a final parameter. Don't forget to escape backslashes (\ needs to be \\).

  Ex. /full/path/tune 0 %c% or C:\\Full\\Path\\tune.exe 0 %c%

• Added 59 second videos that will be streamed in place of an actual recording if the channel is detected to be Copy Once or Copy Never.
• Added a check after tuning that will return to SageTV early if the copy protection status is Copy Once or Copy Never.
• Added a property to enable the use of the timebase 1/0 instead of the standard stream timebase of 90khz. This can make recording more compatible with programs that do not work well with VBR MPEG-TS streams that FFmpeg generates. Set the property consumer.ffmpeg.use_compat_timebase to true if you want to enable this. This is preferred over CBR since the file sizes will not increase.
• Added a property to enable the use of a constant bitrate for MPEG-TS. This can make recording more compatible with programs that do not work well with VBR MPEG-TS streams generated by FFmpeg. Set the property consumer.ffmpeg.use_mpegts_cbr to true if you want to enable this.
• Added a few efficiency improvements to the tuning monitor.
• Added more FFmpeg null condition handling.
• Changed initial bytes streamed for FFmpeg to be closer to what's actually needed to start playback.
• Changed FFmpeg offset calculations so that all new and switched recordings are offset as close to 0 as possible.
• Changed FFmpeg behind tolerance to no more than four frames, since being behind is a much bigger issue than being too far ahead. In CBR, this could have the effect of dropping an entire commercial. That may not sound like a bad thing, but that ~30 seconds missing could be enough to make SageTV think there's a problem.
• Improved responsiveness of raw consumer.
• Fixed FFmpeg audio channel selection so a greater weight is put on the bitrate over the number of frames that have arrived.
• Fixed FFmpeg stream detection so that when a program is not provided, it will try to get all of the streams associated with the first usable video stream when one is found.
• Fixed a potential offset calculating error in FFmpeg related to the new aggregate write feature.
• Removed PTS hack property and code. It's not as useful as expected.
• Removed file missing and file size checking while directly writing files from FFmpeg consumer.
• Removed waiting for key audio packet(s). Now once the first video key frame is written, all audio packets from that point on are written.
• Removed ability to use the old UPnP detection method and device.
• Removed the old FFmpeg implementation.

[nyplayer]

The addition of detecting copy once is great.

[EnterNoEscape]

I'm thankful I got the suggestion. I really didn't know how nice that was going to be until it was there. It writes out about 4 minutes worth of video (the source video is 59 seconds), then stops, so if this happens on a channel you didn't expect it to happen on, you'll see the errors in SageTV. That was my biggest concern; I didn't want people to think all was well when it's not.

[HelenWeathers]

What a pleasant suprise!!!

I installed the 5.3 this AM (clean install, removed previous DCT folders). Did a few test recordings with default settings to check it out and everything went perfectly. To my delight, the files also played in Windows Media Player without making any changes to the OpenDCT properties.

Thank you once again!! This just keeps getting better and better.

[EnterNoEscape]

Originally Posted by HelenWeathers

What a pleasant suprise!!!

I installed the 5.3 this AM (clean install, removed previous DCT folders). Did a few test recordings with default settings to check it out and everything went perfectly. To my delight, the files also played in Windows Media Player without making any changes to the OpenDCT properties.

Thank you once again!! This just keeps getting better and better.

Oops. I double-checked the default properties file and it has the 1/0 timebase turned on. It's not a huge detail, I'll make sure it's off in the next release. You'll just need to remember to turn it back on.

[avs5221]

I'm trying to get Opendct working on a fresh install, but when I run as console it seems to hang at connecting to my HDHRP's lineup.xml. It just sits there indefinitely. On top of that, it won't populate an opendct.properties file, so I can't look in there. Any ideas to move it along?

[jmv]

...moved this from the other OpenDCT sorry for the double post but I guess this is the thread to post issues...I am building a new Windows 2012 R2 based Sage TV server (V7). I decided to give OpenDCT a try (0.5.3). I have a couple of issues. First OpenDCT does not activate all of my HDHR's. My 2 Model HDHR-US (OTA) are both seen and activated, my Model HDHR3-CC (Prime Cable card) is seen and activated. However a later model HDHR3-US 103B91FB is seen in the log, but tuners are not added to OpenDCT (below is the single log entry that shows OpenDCT saw the unit...). I don't know if it matters, but the HDHR with the non-activated tuners is the first one of the 4 listed in the OpenDCT log.

18:13:45.880 [HDHomeRunDiscoveryReceive-34] INFO HDHomeRunDiscoverer - Discovered a new HDHomeRun device 'HDHomeRun HDHR3-US 103B91FB'.
18:13:45.990 [HDHomeRunDiscoveryReceive-34] DEBUG HDHomeRunControl - key: '/tuner0/lockkey' value: 'null' lockKey: '0' sendLength: 26
18:13:46.005 [HDHomeRunDiscoveryReceive-34] DEBUG HDHomeRunControl - key: '/tuner1/lockkey' value: 'null' lockKey: '0' sendLength: 26
18:13:46.005 [HDHomeRunDiscoveryReceive-34] DEBUG HDHomeRunControl - key: '/sys/hwmodel' value: 'null' lockKey: '0' sendLength: 23
18:13:46.005 [HDHomeRunDiscoveryReceive-34] INFO HDHomeRunDiscoverer - Discovered a new HDHomeRun device 'HDHomeRun HDHR-US 10103591'.
18:13:46.130 [HDHomeRunDiscoveryReceive-34] DEBUG DynamicConsumerImpl - Using default consumer 'opendct.consumer.FFmpegTransSageTVConsumerImpl' for channel ''
18:13:46.146 [HDHomeRunDiscoveryReceive-34] DEBUG HDHomeRunControl - key: '/tuner0/lockkey' value: 'null' lockKey: '0' sendLength: 26
18:13:46.146 [HDHomeRunDiscoveryReceive-34] DEBUG HDHomeRunControl - key: '/sys/model' value: 'null' lockKey: '0' sendLength: 21
18:13:46.146 [HDHomeRunDiscoveryReceive-34] DEBUG HDHomeRunControl - key: '/sys/version' value: 'null' lockKey: '0' sendLength: 23
18:13:46.162 [HDHomeRunDiscoveryReceive-34] DEBUG HDHomeRunControl - key: '/sys/features' value: 'null' lockKey: '0' sendLength: 24

My second issue, is that if I try to watch liveTV on the server using the prime tuners, the playback is very choppy, dropped frames, black screen sometimes locks. If I use an HD300 playback is smooth, also, if i record and then start watching it is smooth. I am using all default settings. Should I change something in the OpenDCT properties file to improve server liveTV playback?

Thanks for a great contribution to the SageTV community...hope I never get to see the CC Flag feature in action!

[EnterNoEscape]

Originally Posted by avs5221

I'm trying to get Opendct working on a fresh install, but when I run as console it seems to hang at connecting to my HDHRP's lineup.xml. It just sits there indefinitely. On top of that, it won't populate an opendct.properties file, so I can't look in there. Any ideas to move it along?

It probably didn't actually hang. That was likely just the last thing it did. If you hit Ctrl-C after you see that message, does the console close? If you don't close it by hitting Ctrl-C, the discovered devices will not be saved. You might have an easier time not using the console at all and just starting the service, then stopping it.

[EnterNoEscape]

Originally Posted by jmv

I am building a new Windows 2012 R2 based Sage TV server (V7). I decided to give OpenDCT a try (0.5.3). I have a couple of issues. First OpenDCT does not activate all of my HDHR's. My 2 Model HDHR-US (OTA) are both seen and activated, my Model HDHR3-CC (Prime Cable card) is seen and activated. However a later model HDHR3-US 103B91FB is seen in the log, but tuners are not added to OpenDCT (below is the single log entry that shows OpenDCT saw the unit...). I don't know if it matters, but the HDHR with the non-activated tuners is the first one of the 4 listed in the OpenDCT log.


My second issue, is that if I try to watch liveTV on the server using the prime tuners, the playback is very choppy, dropped frames, black screen sometimes locks. If I use an HD300 playback is smooth, also, if i record and then start watching it is smooth. I am using all default settings. Should I change something in the OpenDCT properties file to improve server liveTV playback?

Thanks for a great contribution to the SageTV community...hope I never get to see the CC Flag feature in action!

You'll need to actually post your log to help me figure out why you're not seeing the HDHR3-US as I'm sure there's a little more in there that may not look relevant, but could be. Did you try just restarting the SageTV service without restarting OpenDCT? It's possible this is a situation whereby it wasn't detected by OpenDCT yet when SageTV asked what it has available?

It's interesting that playback on the server is choppy; I've only seen this on Music Choice channels. Generally I've seen this is a result of the SageTV client not being able to figure out the source clock-rate of the recording, so it keeps getting too far ahead. The only thing I can think of for you to try on this one is setting consumer.ffmpeg.use_compat_timebase to false. It may have accidentally been set true by default. I just checked a few channels on my own primary server and did not see any stuttering, so I'm a a little more confused about why you're seeing it.

[jmv]

Thanks for the fast reply....my property file says this...

consumer.ffmpeg.use_compat_timebase=false

I think that is what you said it should be.

I've attached the full log file.

[EnterNoEscape]

Originally Posted by jmv

Thanks for the fast reply....my property file says this...

consumer.ffmpeg.use_compat_timebase=false

I think that is what you said it should be.

I've attached the full log file.

That's correct. I can see that somehow SageTV running it's own discovery somehow prevented that last device from making it in. What happened that shouldn't have happened is that after discovery, the device wasn't added. I can also see the discovery thread ended gracefully, so what I can say is that something happened that made it think it was ok to not load this device. I'll need to see what I can fix in that regard.

As you can see, there's less than 100ms between when the HDHR3-US was discovered and when SageTV started querying the network encoder which is what each one of those lockkey entries are. I'm going to put a little more logging in the next beta in this area to hopefully clear up why this happened. In the mean time, I want you to restart the OpenDCT service, wait about 30 seconds, then restart the SageTV service. I have a feeling the HDHR3-US will probably show up. If it doesn't, unfortunately you'll need to wait for the next beta.

08:56:36.139 [HDHomeRunDiscoveryReceive-35] INFO  HDHomeRunDiscoverer - Discovered a new HDHomeRun device 'HDHomeRun HDHR3-US 103B91FB'.
08:56:36.186 [HDHomeRunDiscoveryReceive-35] DEBUG HDHomeRunControl - key: '/tuner0/lockkey' value: 'null' lockKey: '0' sendLength: 26
08:56:36.186 [HDHomeRunDiscoveryReceive-35] DEBUG HDHomeRunControl - key: '/tuner1/lockkey' value: 'null' lockKey: '0' sendLength: 26
08:56:36.186 [HDHomeRunDiscoveryReceive-35] DEBUG HDHomeRunControl - key: '/tuner2/lockkey' value: 'null' lockKey: '0' sendLength: 26
08:56:36.186 [HDHomeRunDiscoveryReceive-35] DEBUG HDHomeRunDiscovery - HDHomerun device returned an unknown tag with the length 35
08:56:36.186 [HDHomeRunDiscoveryReceive-35] DEBUG HDHomeRunControl - key: '/tuner0/lockkey' value: 'null' lockKey: '0' sendLength: 26
08:56:36.186 [HDHomeRunDiscoveryReceive-35] DEBUG HDHomeRunControl - key: '/tuner1/lockkey' value: 'null' lockKey: '0' sendLength: 26
08:56:36.186 [HDHomeRunDiscoveryReceive-35] DEBUG HDHomeRunControl - key: '/tuner0/lockkey' value: 'null' lockKey: '0' sendLength: 26
08:56:36.186 [HDHomeRunDiscoveryReceive-35] DEBUG HDHomeRunControl - key: '/tuner1/lockkey' value: 'null' lockKey: '0' sendLength: 26
08:56:36.201 [SageTVDiscovery-52] DEBUG SageTVDiscovery - Received discovery datagram from SageTV server '/192.168.1.231:8270' and validating...
08:56:36.201 [SageTVDiscovery-52] DEBUG SageTVDiscovery - Validated discovery datagram from SageTV server '/192.168.1.231:8270' and preparing response...
08:56:36.201 [SageTVDiscovery-52] INFO  SageTVDiscovery - Sent discovery response datagram to SageTV server '/192.168.1.231:8270'.

[jmv]

I guess I'll be waiting for the next beta . Attached is the latest log. Still doesn't handoff the 103B91FB device over so SageTV sees it. I waited 5 min before starting the sageTV service after starting the OpenDCT service.

thanks,

mv

[EnterNoEscape]

That one looks similar the last one. My only guess for now is that the tuner count is 0 for some reason. I say this because I reviewed the code right after the last message and honestly the only path I can see whereby you see nothing else happen is if it reported 0 tuners. Are you running the latest firmware?

[jmv]

The 2 HDHR-US and the HDHR3-US (unrecognized tuners on this one) all are running Firmware 20150406. The Prime is on 20150826. I can upgrade the HDHR3-US if you think it would make a difference. As an aside the HDHR3-US was working on the prior server using SageDCT setup.

[Telecore]

Had a weird problem with 5.3 - the CBS evening news recorded in its entirety with audio only and a black screen after initially showing the copy once screen. Also had two other copy once incidents that fixed themselves over the weekend on CBS and NBC. Let me know if you want any logs or info thanks.

[EnterNoEscape]

Originally Posted by jmv

The 2 HDHR-US and the HDHR3-US (unrecognized tuners on this one) all are running Firmware 20150406. The Prime is on 20150826. I can upgrade the HDHR3-US if you think it would make a difference. As an aside the HDHR3-US was working on the prior server using SageDCT setup.

I know that Silicondust has some provisioning in their discovery code that will fill in the blanks automatically because some devices report the wrong number of tuners on certain firmwares. I would recommend upgrading your firmware and trying again due to that possibility alone.

Originally Posted by Telecore

Had a weird problem with 5.3 - the CBS evening news recorded in its entirety with audio only and a black screen after initially showing the copy once screen. Also had two other copy once incidents that fixed themselves over the weekend on CBS and NBC. Let me know if you want any logs or info thanks.

This sort of confirms what I thought was happening to you on CBS at least; NBC is a new one. I'll add an option to turn off the messages for people like you were the flag happens, but it doesn't actually stop the recording. If this becomes a problem while I still haven't released the next beta, I would recommended downgrading to 5.2. Because of the copy protection video, SageTV based it's assumptions about the entire video on that first video which is why you were missing the video in playback. I'm 90% certain the video was actually there, just not detected by SageTV, so it didn't play it. I would like to see the log for the CBS news recording. I just want to confirm that it's analog copy protection that's causing the problem.

[Telecore]

Originally Posted by EnterNoEscape

This sort of confirms what I thought was happening to you on CBS at least; NBC is a new one. I'll add an option to turn off the messages for people like you were the flag happens, but it doesn't actually stop the recording. If this becomes a problem while I still haven't released the next beta, I would recommended downgrading to 5.2. Because of the copy protection video, SageTV based it's assumptions about the entire video on that first video which is why you were missing the video in playback. I'm 90% certain the video was actually there, just not detected by SageTV, so it didn't play it. I would like to see the log for the CBS news recording. I just want to confirm that it's analog copy protection that's causing the problem.

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.

[jusjoken]

Originally Posted by jmv

The 2 HDHR-US and the HDHR3-US (unrecognized tuners on this one) all are running Firmware 20150406. The Prime is on 20150826. I can upgrade the HDHR3-US if you think it would make a difference. As an aside the HDHR3-US was working on the prior server using SageDCT setup.

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>