OpenDCT: An open source digital cable tuner.

[CarlR]

Hi - I'm looking to add 2 WinTV-DCR-2650 boxes for use with SageTV.
These connect to the PC via USB, not over the network, so do I need to use OpenDCT?
I'm a little confused as I've seen a few (very old) threads talking about using OpenDCT with the WinTV-DCR-2650, but it seems like OpenDCT is just for tuners that are connected over ethernet (like the HDHomeRun OTA tuners I have)

[EnterNoEscape]

Originally Posted by CarlR

Hi - I'm looking to add 2 WinTV-DCR-2650 boxes for use with SageTV.
These connect to the PC via USB, not over the network, so do I need to use OpenDCT?
I'm a little confused as I've seen a few (very old) threads talking about using OpenDCT with the WinTV-DCR-2650, but it seems like OpenDCT is just for tuners that are connected over ethernet (like the HDHomeRun OTA tuners I have)

I have never tested with that tuner, but as I understand from others descriptions, it presents itself as a network device via the USB port and it uses the HDHomeRun protocol. If that's the case, you should be able to use OpenDCT to interface with it.

[CptKirk]

The best way I dealt with these channels was to actually use FFmpeg to transcode just music stations. I created a profile specifically for this purpose (ultrafast_mc) that only picks up stations that look like music stations. All other stations are just remuxed like normal. By transcoding, it's basically just adding all of the interframes that don't exist normally on music channels and makes them much more compatible.

Thanks for the note. How do you use the ultrafast_mc profile?

Change

consumer.dynamic.channels.ffmpeg=
consumer.dynamic.channels.raw=801-850

To:

consumer.dynamic.channels.ffmpeg=801-850
consumer.dynamic.channels.raw=

Will that tell it to use the ffmpeg on my music channels 801 to 850?

How will it engage/use the ultrafast_mc profile?

What would I look for in the opendct logs to see that the ultrafast_mc profile was being used?

Sorry for all the questions, haven't really tried doing anything with opendct except for using the defaults.

[EnterNoEscape]

Set the software transcoding profile by changing sagetv.device.<unique_id>.transcode_profile to one of the available profiles are stored under C:\ProgramData\OpenDCT\config\transcode on Windows and /etc/opendct/conf/transcode on Linux. See profile_example.properties for help on how you can create your own. Do not include the .properties extension when setting the profile.

So you would change set the transcode_profile profile per device. Unfortunately, I never set it up to have profiles per channel. It's an interesting idea, but I think I never did it because I thought it would be better to have the profiles identify content instead of putting that burden on the user.

e.g.
sagetv.device.<unique_id>.transcode_profile=ultrafast_mc

[technazz]

Iv'e Been using the generic pipe with IPTV streams for a while. If you can play certain recording until they are finished use the following setting in the sage.properties file

skip_internal_format_parser=true

I found it here

https://forums.sagetv.com/forums/sho...hed#post620783

Chris

[CarlR]

Originally Posted by CarlR
Hi - I'm looking to add 2 WinTV-DCR-2650 boxes for use with SageTV.
These connect to the PC via USB, not over the network, so do I need to use OpenDCT?
I'm a little confused as I've seen a few (very old) threads talking about using OpenDCT with the WinTV-DCR-2650, but it seems like OpenDCT is just for tuners that are connected over ethernet (like the HDHomeRun OTA tuners I have)

Originally Posted by EnterNoEscape

I have never tested with that tuner, but as I understand from others descriptions, it presents itself as a network device via the USB port and it uses the HDHomeRun protocol. If that's the case, you should be able to use OpenDCT to interface with it.

Hi - Thanks for the reply. I've managed to configure SageTV and OpenDCT and have 2 WinTV-DCR-2650 connected via USB.

Recordings seem to work ok for a while, but eventually I will get a System Message in SageTV saying that "device input <one of the DCRs> stopped producing data while recording ...". It is not always the same recording unit or the same channel.

Rebooting the DCR does not fix the problem. The last time I tried restarting the OpenDCR service and then rebooting the DCRs, and that worked. Not sure what this means, but just offering it as a data point.

Do you have any suggestions for further debug? I've looked through the windows error logs (running W7) and nothing jumps out at me, but I don't really know what I am looking for. I'm not sure it makes a difference, but I have 3 HDHR dual OTA tuners that are connected to the same PC using ethernet - and they are not being managed by OpenDCT. I'm using the HDHR software for them. Could that be causing a conflict?

Any help would be appreciated.

Thanks,
Carl

[nyplayer]

Just an FYI in my area they did the repack I was getting no signal on most of my OTA channels on my connects .. A rescan in the web page fixed this.

[CarlR]

Things have been working well for a while (about two weeks), but a after a reboot of the PC running SageTV, everything went sideways.

After a day of many trial and error loops, I'm now

• running SageTV as a service
• using OpenDCT to control all 3 of my HDHR dual OTA tuners, and my two HDHR DCR-2650 dual CableCard tuners (which connect via USB but present to DCT as being on eth6 and eth9).
• run the OpenDCT console and configured all the tuners in SageTV.
• using the opendct.properties as it was created by running the console, with the exception of setting the following parameters
  • sagetv.device.<deviceID>.consumer=opendct.consumer.RawSageTVConsumerImpl
  • sagetv.device.global.required_devices_loaded_count=10
  • sagetv.device.global.required_devices_loaded_timeout_ms=600000

Operation of any of the tuners is the same. When I try to record on SageTV the "tuner" light turns on on the appropriate box, but I get a "No Data" screen in SageTV.

It appears from the log file that the "producer" and "consumer" both start up, but no data is ever transferred between the two. This log is from an attempted recording on the HDHR OTA tuner, but the CableCard tuners give the same messages :
"The consumer appears to be stuck at 0"
"The producer appears to be stuck at 0"

23:49:53.816 [SageTVRequestHandler-1403:HDHomeRun HDHR-US Tuner 1011EDAA-1] DEBUG HDHRNativeCaptureDevice - Searching for channel '11.1' program in '[3: 11.1 WBAL-DT, 4: 11.2 MeTV]'...
23:49:53.816 [SageTVRequestHandler-1403:HDHomeRun HDHR-US Tuner 1011EDAA-1] INFO  HDHRNativeCaptureDevice - Found '11.1' in 'HDHomeRunProgram{PROGRAM='3', CHANNEL='11.1', CALLSIGN='WBAL-DT', ENCRYPTED=false, CONTROL=false, NO_DATA=false}' out of '[3: 11.1 WBAL-DT, 4: 11.2 MeTV]'.
23:49:53.816 [SageTVRequestHandler-1403:HDHomeRun HDHR-US Tuner 1011EDAA-1] DEBUG HDHomeRunControl - key: '/tuner1/program' value: '3' lockKey: '1442927200' sendLength: 36 address: 169.254.30.218
23:49:53.816 [SageTVRequestHandler-1403:HDHomeRun HDHR-US Tuner 1011EDAA-1] INFO  HDHRNativeCaptureDevice - Configuring and starting the new RTP producer...
23:49:53.816 [SageTVRequestHandler-1403:HDHomeRun HDHR-US Tuner 1011EDAA-1] DEBUG RTPCaptureDeviceServices - Producer was not running.
23:49:53.816 [SageTVRequestHandler-1403:HDHomeRun HDHR-US Tuner 1011EDAA-1] DEBUG HDHomeRunControl - key: '/tuner1/target' value: 'rtp://169.254.173.160:8374' lockKey: '1442927200' sendLength: 60 address: 169.254.30.218
23:49:53.816 [NIORTPProducerImpl-1328:HDHomeRun HDHR-US Tuner 1011EDAA-1] INFO  NIORTPProducerImpl - Producer thread is running.
23:49:53.816 [NIORTPProducerImpl-1328:HDHomeRun HDHR-US Tuner 1011EDAA-1] DEBUG NIORTPProducerImpl - Thread priority is 9.
23:49:53.816 [SageTVRequestHandler-1403:HDHomeRun HDHR-US Tuner 1011EDAA-1] DEBUG HDHomeRunControl - key: '/tuner1/program' value: 'null' lockKey: '0' sendLength: 26 address: 169.254.30.218
23:49:53.816 [SageTVRequestHandler-1403:HDHomeRun HDHR-US Tuner 1011EDAA-1] INFO  HDHRNativeCaptureDevice - Configuring and starting the new SageTV consumer...
23:49:53.816 [SageTVRequestHandler-1403:HDHomeRun HDHR-US Tuner 1011EDAA-1] DEBUG BasicCaptureDevice - Consumer is not in progress.
23:49:53.816 [RawSageTVConsumerImpl-1336:HDHomeRun HDHR-US Tuner 1011EDAA-1] DEBUG RawSageTVConsumerImpl - Thread priority is 8.
23:49:53.816 [RawSageTVConsumerImpl-1336:HDHomeRun HDHR-US Tuner 1011EDAA-1] INFO  RawSageTVConsumerImpl - Raw consumer thread is now running.
23:49:53.816 [RawSageTVConsumerImpl-1336:HDHomeRun HDHR-US Tuner 1011EDAA-1] INFO  NIOSageTVMediaServer - Connecting to SageTV server on socket /127.0.0.1:7818...
23:49:53.816 [RawSageTVConsumerImpl-1336:HDHomeRun HDHR-US Tuner 1011EDAA-1] INFO  NIOSageTVMediaServer - Sending 'WRITEOPEN \\pc-sagetv\SageTV_B04\SageTV\TheTonightShowStarringJimmyFallon-S07E22-EmmaThompsonJoelKinnamanLiamGallagher-28491455-12.ts 747468357' to SageTV server...
23:49:53.831 [RawSageTVConsumerImpl-1336:HDHomeRun HDHR-US Tuner 1011EDAA-1] INFO  RawSageTVConsumerImpl - Waiting for PES start byte...
23:49:55.329 [SageTVRequestHandler-1403:HDHomeRun HDHR-US Tuner 1011EDAA-1] DEBUG SageTVRequestHandler - Replied: 'OK'
23:50:48.197 [SageTVTuningMonitor-279] DEBUG SageTVTuningMonitor - The consumer appears to be stuck at 0, file system length 0, file name '\\pc-sagetv\SageTV_B04\SageTV\TheTonightShowStarringJimmyFallon-S07E22-EmmaThompsonJoelKinnamanLiamGallagher-28491455-12.ts', copy protection NONE.
23:50:48.197 [SageTVTuningMonitor-279] DEBUG SageTVTuningMonitor - The producer appears to be stuck at 0.
23:51:08.290 [SageTVRequestHandler-1403:Unknown] DEBUG SageTVRequestHandler - SageTV sent: 'STOP HDHomeRun HDHR-US Tuner 1011EDAA-1 Digital TV Tuner'
23:51:08.290 [SageTVRequestHandler-1403:HDHomeRun HDHR-US Tuner 1011EDAA-1] DEBUG HDHRNativeCaptureDevice - Stopping encoding...
23:51:08.290 [SageTVRequestHandler-1403:HDHomeRun HDHR-US Tuner 1011EDAA-1] DEBUG RTPCaptureDeviceServices - Stopping producer thread...
23:51:08.290 [NIORTPProducerImpl-1328:HDHomeRun HDHR-US Tuner 1011EDAA-1] DEBUG NIORTPProducerImpl - Producer was closed by an asynchronous close exception => null
23:51:08.290 [NIORTPProducerImpl-1328:HDHomeRun HDHR-US Tuner 1011EDAA-1] INFO  NIORTPProducerImpl - Producer thread has disconnected.
23:51:08.290 [NIORTPProducerImpl-1328:HDHomeRun HDHR-US Tuner 1011EDAA-1] INFO  NIORTPProducerImpl - Producer thread has stopped.
23:51:08.290 [SageTVRequestHandler-1403:HDHomeRun HDHR-US Tuner 1011EDAA-1] DEBUG BasicCaptureDevice - Stopping consumer thread...
23:51:08.306 [SageTVRequestHandler-1403:HDHomeRun HDHR-US Tuner 1011EDAA-1] INFO  NIOSageTVMediaServer - Sending 'CLOSE' to SageTV server...
23:51:08.306 [SageTVRequestHandler-1403:HDHomeRun HDHR-US Tuner 1011EDAA-1] INFO  NIOSageTVMediaServer - Sending 'QUIT' to SageTV server...
23:51:08.306 [SageTVRequestHandler-1403:HDHomeRun HDHR-US Tuner 1011EDAA-1] DEBUG HDHomeRunControl - key: '/tuner1/channel' value: 'none' lockKey: '1442927200' sendLength: 39 address: 169.254.30.218
23:51:08.306 [RawSageTVConsumerImpl-1336:HDHomeRun HDHR-US Tuner 1011EDAA-1] DEBUG RawSageTVConsumerImpl - Raw consumer was closed by an interrupt exception => java.lang.InterruptedException
	at java.lang.Object.wait(Native Method)
	at opendct.consumer.buffers.SeekableCircularBufferNIO.waitForBytes(SeekableCircularBufferNIO.java:152)
	at opendct.consumer.buffers.SeekableCircularBufferNIO.read(SeekableCircularBufferNIO.java:583)
	at opendct.consumer.RawSageTVConsumerImpl.run(RawSageTVConsumerImpl.java:162)
	at opendct.util.ThreadPool$1.run(ThreadPool.java:39)
	at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
	at java.util.concurrent.FutureTask.run(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)

23:51:08.306 [RawSageTVConsumerImpl-1336:HDHomeRun HDHR-US Tuner 1011EDAA-1] INFO  RawSageTVConsumerImpl - Raw consumer thread is now stopping.
23:51:08.306 [RawSageTVConsumerImpl-1336:HDHomeRun HDHR-US Tuner 1011EDAA-1] DEBUG RawSageTVConsumerImpl - Bytes available to be read = 0
23:51:08.306 [RawSageTVConsumerImpl-1336:HDHomeRun HDHR-US Tuner 1011EDAA-1] DEBUG RawSageTVConsumerImpl - Space available for writing in bytes = 2097151
23:51:08.306 [RawSageTVConsumerImpl-1336:HDHomeRun HDHR-US Tuner 1011EDAA-1] INFO  RawSageTVConsumerImpl - Raw consumer thread has stopped.
23:51:08.306 [SageTVRequestHandler-1403:HDHomeRun HDHR-US Tuner 1011EDAA-1] DEBUG HDHomeRunControl - key: '/tuner1/target' value: 'none' lockKey: '1442927200' sendLength: 38 address: 169.254.30.218
23:51:08.306 [SageTVRequestHandler-1403:HDHomeRun HDHR-US Tuner 1011EDAA-1] DEBUG HDHomeRunControl - key: '/tuner1/lockkey' value: 'null' lockKey: '0' sendLength: 26 address: 169.254.30.218
23:51:08.306 [SageTVRequestHandler-1403:HDHomeRun HDHR-US Tuner 1011EDAA-1] DEBUG HDHomeRunControl - key: '/tuner1/lockkey' value: 'none' lockKey: '1442927200' sendLength: 39 address: 169.254.30.218
23:51:08.306 [SageTVRequestHandler-1403:HDHomeRun HDHR-US Tuner 1011EDAA-1] DEBUG HDHomeRunControl - key: '/tuner1/lockkey' value: 'null' lockKey: '0' sendLength: 26 address: 169.254.30.218
23:51:08.306 [SageTVRequestHandler-1403:HDHomeRun HDHR-US Tuner 1011EDAA-1] INFO  HDHRNativeCaptureDevice - HDHomeRun is now unlocked.
23:51:08.306 [SageTVRequestHandler-1403:HDHomeRun HDHR-US Tuner 1011EDAA-1] DEBUG HDHRNativeCaptureDevice - Capture device is now re-unlocked.
23:51:08.306 [SageTVRequestHandler-1403:HDHomeRun HDHR-US Tuner 1011EDAA-1] DEBUG SageTVRequestHandler - Replied: 'OK'

I'm completely run out of ideas. Any suggestions would be greatly appreciated.

Thanks,
Carl

[emveepee]

Does OpenDCT require SageTV? I have a plugin that can access SageDCT and the r5000 device from NextPVR using the Sage network protocol but I would like to test it with the new version of NextPVR. In Canada I can't use cablecard but it sounds like I might be able to use OpenDCT with my http h265/264 encoder as a test.

Martin

[EnterNoEscape]

Originally Posted by emveepee

Does OpenDCT require SageTV? I have a plugin that can access SageDCT and the r5000 device from NextPVR using the Sage network protocol but I would like to test it with the new version of NextPVR. In Canada I can't use cablecard but it sounds like I might be able to use OpenDCT with my http h265/264 encoder as a test.

Martin

There's a good chance it will not work as expected out of the box in that scenario unless they also implemented the SageTV media server features. You would need to tell OpenDCT to not use that feature (which is configurable); it might work then.

[emveepee]

Originally Posted by EnterNoEscape

There's a good chance it will not work as expected out of the box in that scenario unless they also implemented the SageTV media server features. You would need to tell OpenDCT to not use that feature (which is configurable); it might work then.

I don't even know what the media server features are. My simple app was focused on these commands

(ping)
command: NOOP
returns: OK

(version check)
command: VERSION
returns: 2.1

(start recording)
command: START|TunerName|ChannelNo|TunerID|FilePath|RecQuality
returns: OK

(switch channel and file)
command: SWITCH|ChannelNo|FilePath
returns: OK

(Filesize check)
command: GET_SIZE
returns: File size in bytes (STRING)

(stop recording)
command: STOP
returns: OK

I really only understood that servers I worked with cared about the unique ChannelNo which was specified to match the NextPVR channel number (typically the SD channel number) and FilePath which NextPVR requests.

Looks like I have research ahead of me.

Thanks,

Martin

[EnterNoEscape]

Originally Posted by emveepee

I don't even know what the media server features are. My simple app was focused on these commands

(ping)
command: NOOP
returns: OK

(version check)
command: VERSION
returns: 2.1

(start recording)
command: START|TunerName|ChannelNo|TunerID|FilePath|RecQuality
returns: OK

(switch channel and file)
command: SWITCH|ChannelNo|FilePath
returns: OK

(Filesize check)
command: GET_SIZE
returns: File size in bytes (STRING)

(stop recording)
command: STOP
returns: OK

I really only understood that servers I worked with cared about the unique ChannelNo which was specified to match the NextPVR channel number (typically the SD channel number) and FilePath which NextPVR requests.

Looks like I have research ahead of me.

Thanks,

Martin

It will still be a little confusing, but I learned the more advanced features here: https://github.com/google/sagetv/blo...ver.java#L1011

The OpenDCT side of things is here: https://github.com/enternoescape/ope...stHandler.java

OpenDCT is a 3.0 network capture device (which allows for media server support).

Edit: I want to note that the SWITCH command never changes the channel as it is currently implemented. The goal is to find an I frame in the video and start a new file with the I frame. This is what enables SageTV to transition between different recordings on one channel without blanking the screen at the transition.

[Foggy]

Originally Posted by waylo

Hi ENE,

I was editing my opendct properties file for the first time in a long time and I found this very long string at the very top:

\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000\u0000=
buffers.nio.direct2=true

It's truncated here, but it's about 50+kb of this.

Any idea how this got there? It's not there in the backup of the last version .properties file in the same folder. That was last updated ~2 months ago.

Bringing up a very old post, - my properties file has the same stuff at the top "\u0000". It was not in the Nov 17th archive I made but showed up after that. I'm going to shut the services down, edit that file and start it up again.

John

[EnterNoEscape]

Originally Posted by Foggy

Bringing up a very old post, - my properties file has the same stuff at the top "\u0000". It was not in the Nov 17th archive I made but showed up after that. I'm going to shut the services down, edit that file and start it up again.

John

It's definitely some property that's being interpreted as all null characters that was written out. What I don't know what generated that property. It is strangely enough properly formatted for the properties file, so it shouldn't cause any issues.

[KryptoNyte]

I wanted to make my Ceton Infinitv6 Pcie available to other computers on the network, so I just finished bridging the pcie device with my Intel NIC. I uninstalled OpenDCT and reinstalled the 64 bit version, but the log seems to indicate that the Ceton 'network' device doesn't have an IP address. I did set the IP address of the bridged network to a static IP of 192.166.254.101, so I was expecting discovery of the Ceton 'network' device there.

Is there a setting in OpenDCT that I need to tweak, or have I missed something in the bridged configuration?

14:29:26.715 [WrapperSimpleAppMain] INFO Main - Starting OpenDCT 0.5.29...
14:29:26.731 [WrapperSimpleAppMain] DEBUG Config - OSVersion determined that 'Windows 7' is WINDOWS.
14:29:26.731 [WrapperSimpleAppMain] INFO Config - Current directory is 'C:\Program Files\OpenDCT Authors\OpenDCT'
14:29:26.762 [WrapperSimpleAppMain] INFO Main - OpenDCT logging to the directory 'c:/ProgramData/OpenDCT/logs'.
14:29:26.793 [WrapperSimpleAppMain] INFO UpnpManager - Logging Cling UPnP to 'c:/ProgramData/OpenDCT/logs\opendct_cling.log'.
14:29:26.793 [WrapperSimpleAppMain] DEBUG UpnpManager - Logging level for Cling UPnP is set to 'severe'.
14:29:26.793 [FFmpegAsyncInit-22] INFO Main - FFmpeg loading...
14:29:26.793 [FFmpegAsyncInit-22] DEBUG FFmpegUtil - Initializing FFmpegLogger...
14:29:26.840 [FFmpegAsyncInit-22] DEBUG FFmpegUtil - Calling av_log_set_callback...
14:29:26.840 [FFmpegAsyncInit-22] DEBUG FFmpegUtil - Calling avcodec_register_all...
14:29:26.902 [WindowsPowerMessagePump] INFO WindowsPowerMessagePump - Message pump started.
14:29:27.215 [FFmpegAsyncInit-22] DEBUG FFmpegUtil - Calling avfilter_register_all...
14:29:27.437 [FFmpegAsyncInit-22] DEBUG FFmpegUtil - Calling av_register_all...
14:29:27.437 [FFmpegAsyncInit-22] INFO Main - FFmpeg loaded in 644ms.
14:29:31.885 [WrapperSimpleAppMain] INFO NetworkPowerEventManger - InfiniTV device 'Ceton InfiniTV Network Device #2' does not have an IP address. Extending wait...
14:29:42.970 [WrapperSimpleAppMain] INFO NetworkPowerEventManger - InfiniTV device 'Ceton InfiniTV Network Device #2' does not have an IP address. Extending wait...
14:29:54.055 [WrapperSimpleAppMain] INFO NetworkPowerEventManger - Network interfaces which are up and have an IP4 address are:
name:eth9 (MAC Bridge Miniport) 192.168.254.101
14:29:54.055 [WrapperSimpleAppMain] DEBUG WindowsPowerMessagePump - 'class opendct.power.NetworkPowerEventManger' is now listening.
14:29:54.055 [WrapperSimpleAppMain] DEBUG WindowsPowerMessagePump - 'class opendct.sagetv.SageTVManager' is now listening.
14:29:54.055 [DynamicAsyncInit-22] INFO DynamicConsumerImpl - Dynamic consumer default set to use opendct.consumer.FFmpegTransSageTVConsumerImpl
14:29:54.055 [DynamicAsyncInit-22] INFO DynamicConsumerImpl - Dynamic consumer set to use opendct.consumer.FFmpegTransSageTVConsumerImpl for []
14:29:54.055 [DynamicAsyncInit-22] INFO DynamicConsumerImpl - Dynamic consumer set to use opendct.consumer.MediaServerConsumerImpl for []
14:29:54.055 [DynamicAsyncInit-22] INFO DynamicConsumerImpl - Dynamic consumer set to use opendct.consumer.RawSageTVConsumerImpl for []
14:29:54.180 [WrapperSimpleAppMain] INFO UpnpManager - Starting UPnP services...
14:29:54.242 [WrapperSimpleAppMain] INFO DCTDefaultUpnpServiceConfiguration - Using the interface 'eth9' with IP address 192.168.254.101 for UPnP discovery.
14:29:54.258 [WrapperSimpleAppMain] DEBUG UpnpManager - Sending a SecureContainer search message for 'schemas-cetoncorp-com' devices...
14:29:54.273 [UPnPDiscovery-36] INFO UpnpManager - UPnP discovery thread has started.
14:29:54.320 [HDHomeRunDiscoverySend-37] INFO HDHomeRunDiscovery - HDHomeRun discovery sender thread started.
14:29:54.320 [HDHomeRunDiscoveryReceive-37] INFO HDHomeRunDiscovery - HDHomeRun discovery receive thread for /192.168.254.255:65001 broadcast started.

[KryptoNyte]

The Ceton page, where it provides bridging instructions would seem to suggest that I can't bridge the 6 tuner model. Oh well.

http://cetoncorp.com/product-support/

[emveepee]

An OpenDCT user in NextPVR (linux) is generally having positive results but he has reported that some channels take quite a long time to open, 18 seconds to tune and another 14 seconds to deliver data. Is this expected behaviour?

Here is his properties file https://gist.github.com/dapharsyde/1...73f7f527f91c90


He also cannot use raw mode because it returns transport streams with more that one program for the tuned channel. Is there a property that can fix that or maybe skip over data while tuning?

2019-12-15 19:59:35.998	[DEBUG][14]	[FFMPEG]:   Duration: N/A, start: 58835.751222, bitrate: N/A
2019-12-15 19:59:35.998	[DEBUG][14]	[FFMPEG]:   Program 2 
2019-12-15 19:59:35.998	[DEBUG][14]	[FFMPEG]:     Stream #0:6[0x1736]: Video: mpeg2video ([2][0][0][0] / 0x0002), none, 90k tbr, 90k tbn
2019-12-15 19:59:35.999	[DEBUG][14]	[FFMPEG]:     Stream #0:7[0x1737](eng): Audio: ac3 ([129][0][0][0] / 0x0081), 0 channels
2019-12-15 19:59:35.999	[DEBUG][14]	[FFMPEG]:     Stream #0:8[0x1769](spa): Audio: ac3 ([129][0][0][0] / 0x0081), 0 channels
2019-12-15 19:59:35.999	[DEBUG][14]	[FFMPEG]:   Program 8516 
2019-12-15 19:59:35.999	[DEBUG][14]	[FFMPEG]:     Stream #0:12[0x1742]: Video: mpeg2video ([2][0][0][0] / 0x0002), none, 90k tbr, 90k tbn
2019-12-15 19:59:35.999	[DEBUG][14]	[FFMPEG]:     Stream #0:13[0x176a](eng): Audio: ac3 ([129][0][0][0] / 0x0081), 0 channels
2019-12-15 19:59:35.999	[DEBUG][14]	[FFMPEG]:   Program 1 
2019-12-15 19:59:35.999	[DEBUG][14]	[FFMPEG]:     Stream #0:3[0x1749]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, top first), 1920x1080 [SAR 1:1 DAR 16:9], Closed Captions, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
2019-12-15 19:59:35.999	[DEBUG][14]	[FFMPEG]:     Stream #0:4[0x174a](eng): Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, 5.1(side), fltp, 384 kb/s
2019-12-15 19:59:35.999	[DEBUG][14]	[FFMPEG]:     Stream #0:5[0x174b](spa): Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, mono, fltp, 192 kb/s
2019-12-15 19:59:35.999	[DEBUG][14]	[FFMPEG]:   Program 6 
2019-12-15 19:59:35.999	[DEBUG][14]	[FFMPEG]:     Stream #0:9[0x1750]: Video: h264 ([27][0][0][0] / 0x001B), none, 90k tbr, 90k tbn
2019-12-15 19:59:35.999	[DEBUG][14]	[FFMPEG]:     Stream #0:10[0x1751](eng): Audio: ac3 ([129][0][0][0] / 0x0081), 0 channels
2019-12-15 19:59:36.000	[DEBUG][14]	[FFMPEG]:     Stream #0:11[0x1752](spa): Audio: ac3 ([129][0][0][0] / 0x0081), 0 channels
2019-12-15 19:59:36.000	[DEBUG][14]	[FFMPEG]:   Program 8517 
2019-12-15 19:59:36.000	[DEBUG][14]	[FFMPEG]:     Stream #0:0[0x1746]: Video: mpeg2video ([2][0][0][0] / 0x0002), none(tv), 90k tbr, 90k tbn, 90k tbc
2019-12-15 19:59:36.000	[DEBUG][14]	[FFMPEG]:     Stream #0:1[0x1747](eng): Audio: ac3 (AC-3 / 0x332D4341), 0 channels, fltp
2019-12-15 19:59:36.000	[DEBUG][14]	[FFMPEG]:     Stream #0:2[0x1748](spa,spa): Audio: ac3 (AC-3 / 0x332D4341), 0 channels, fltp

Thanks,

Martin

[dapharsyde]

Originally Posted by emveepee

An OpenDCT user in NextPVR (linux) is generally having positive results but he has reported that some channels take quite a long time to open, 18 seconds to tune and another 14 seconds to deliver data. Is this expected behaviour?

Here is his properties file https://gist.github.com/dapharsyde/1...73f7f527f91c90


He also cannot use raw mode because it returns transport streams with more that one program for the tuned channel. Is there a property that can fix that or maybe skip over data while tuning?

2019-12-15 19:59:35.998	[DEBUG][14]	[FFMPEG]:   Duration: N/A, start: 58835.751222, bitrate: N/A
2019-12-15 19:59:35.998	[DEBUG][14]	[FFMPEG]:   Program 2 
2019-12-15 19:59:35.998	[DEBUG][14]	[FFMPEG]:     Stream #0:6[0x1736]: Video: mpeg2video ([2][0][0][0] / 0x0002), none, 90k tbr, 90k tbn
2019-12-15 19:59:35.999	[DEBUG][14]	[FFMPEG]:     Stream #0:7[0x1737](eng): Audio: ac3 ([129][0][0][0] / 0x0081), 0 channels
2019-12-15 19:59:35.999	[DEBUG][14]	[FFMPEG]:     Stream #0:8[0x1769](spa): Audio: ac3 ([129][0][0][0] / 0x0081), 0 channels
2019-12-15 19:59:35.999	[DEBUG][14]	[FFMPEG]:   Program 8516 
2019-12-15 19:59:35.999	[DEBUG][14]	[FFMPEG]:     Stream #0:12[0x1742]: Video: mpeg2video ([2][0][0][0] / 0x0002), none, 90k tbr, 90k tbn
2019-12-15 19:59:35.999	[DEBUG][14]	[FFMPEG]:     Stream #0:13[0x176a](eng): Audio: ac3 ([129][0][0][0] / 0x0081), 0 channels
2019-12-15 19:59:35.999	[DEBUG][14]	[FFMPEG]:   Program 1 
2019-12-15 19:59:35.999	[DEBUG][14]	[FFMPEG]:     Stream #0:3[0x1749]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv, top first), 1920x1080 [SAR 1:1 DAR 16:9], Closed Captions, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
2019-12-15 19:59:35.999	[DEBUG][14]	[FFMPEG]:     Stream #0:4[0x174a](eng): Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, 5.1(side), fltp, 384 kb/s
2019-12-15 19:59:35.999	[DEBUG][14]	[FFMPEG]:     Stream #0:5[0x174b](spa): Audio: ac3 ([129][0][0][0] / 0x0081), 48000 Hz, mono, fltp, 192 kb/s
2019-12-15 19:59:35.999	[DEBUG][14]	[FFMPEG]:   Program 6 
2019-12-15 19:59:35.999	[DEBUG][14]	[FFMPEG]:     Stream #0:9[0x1750]: Video: h264 ([27][0][0][0] / 0x001B), none, 90k tbr, 90k tbn
2019-12-15 19:59:35.999	[DEBUG][14]	[FFMPEG]:     Stream #0:10[0x1751](eng): Audio: ac3 ([129][0][0][0] / 0x0081), 0 channels
2019-12-15 19:59:36.000	[DEBUG][14]	[FFMPEG]:     Stream #0:11[0x1752](spa): Audio: ac3 ([129][0][0][0] / 0x0081), 0 channels
2019-12-15 19:59:36.000	[DEBUG][14]	[FFMPEG]:   Program 8517 
2019-12-15 19:59:36.000	[DEBUG][14]	[FFMPEG]:     Stream #0:0[0x1746]: Video: mpeg2video ([2][0][0][0] / 0x0002), none(tv), 90k tbr, 90k tbn, 90k tbc
2019-12-15 19:59:36.000	[DEBUG][14]	[FFMPEG]:     Stream #0:1[0x1747](eng): Audio: ac3 (AC-3 / 0x332D4341), 0 channels, fltp
2019-12-15 19:59:36.000	[DEBUG][14]	[FFMPEG]:     Stream #0:2[0x1748](spa,spa): Audio: ac3 (AC-3 / 0x332D4341), 0 channels, fltp

Thanks,

Martin

Thanks Martin.

I am the openDCT user mentioned in this post. While testing further, I also noticed inconsistent results tuning to some channels. Sometimes the copy protection bit is set to "Copy Free", but just seconds later, the same channel becomes "Copy Never".

Here is a opendct.log that shows success tuning to 745 (copy free), success tuning to 747 (copy free), then failure tuning back to 745 (copy never)

of particular note is these line entries:

Line 143: 12:40:56.806 [SageTVRequestHandler-48:DCT-Ceton InfiniTV Ethernet (00-80-8d-8a) Tuner 6] INFO  InfiniTVCaptureDevice - Starting the encoding for the channel '745' from the device 'DCT-Ceton InfiniTV Ethernet (00-80-8d-8a) Tuner 6' to the file 'stdout' via the upload id '8888'...
Line 200: 12:40:59.067 [SageTVRequestHandler-48:DCT-Ceton InfiniTV Ethernet (00-80-8d-8a) Tuner 6] DEBUG InfiniTVStatus - The returned value was trimmed to 'Copy Control Information: "Copy Free" (00)'

Line 276: 12:41:19.428 [SageTVRequestHandler-48:DCT-Ceton InfiniTV Ethernet (00-80-8d-8a) Tuner 6] INFO  InfiniTVCaptureDevice - Starting the encoding for the channel '747' from the device 'DCT-Ceton InfiniTV Ethernet (00-80-8d-8a) Tuner 6' to the file 'stdout' via the upload id '8888'...
Line 374: 12:41:23.396 [SageTVTuningMonitor-50] DEBUG InfiniTVStatus - The returned value was trimmed to 'Copy Control Information: "Copy Free" (00)'

Line 417: 12:41:59.921 [SageTVRequestHandler-48:DCT-Ceton InfiniTV Ethernet (00-80-8d-8a) Tuner 6] INFO  InfiniTVCaptureDevice - Starting the encoding for the channel '745' from the device 'DCT-Ceton InfiniTV Ethernet (00-80-8d-8a) Tuner 6' to the file 'stdout' via the upload id '8888'...
Line 449: 12:42:02.659 [SageTVRequestHandler-48:DCT-Ceton InfiniTV Ethernet (00-80-8d-8a) Tuner 6] DEBUG InfiniTVStatus - The returned value was trimmed to 'Copy Control Information: "Copy Never" (0x03)'

It is strange that the same channel is going between copy free and copy never. Is there a setting I can enable to avoid this? Perhaps by retrying the tuning until it returns the Copy Free bit?

[emveepee]

@dapharsyde although possibly not related to your problem, I see an issue in your logs perhaps with my understanding of the protocal. OpenDCT is trying to create a file to tell us about the DRM issue instead of streaming it over the Media port.

I was passing a filename 'stdout' as reference for myself thinking it was never used, maybe this has to be a valid filename on the server.

Back to my post, I will try to simplify the question. Are any SageTV users using the Ceton device and can it take 20 or 30 seconds on some channels (other than Music Choice)?

Martin

[sic0048]

Originally Posted by emveepee

@dapharsyde although possibly not related to your problem, I see an issue in your logs perhaps with my understanding of the protocal. OpenDCT is trying to create a file to tell us about the DRM issue instead of streaming it over the Media port.

I was passing a filename 'stdout' as reference for myself thinking it was never used, maybe this has to be a valid filename on the server.

Back to my post, I will try to simplify the question. Are any SageTV users using the Ceton device and can it take 20 or 30 seconds on some channels (other than Music Choice)?

Martin

I'm using the Ceton ETH 6 network tuner and don't have prolonged channel change times. It might take 3-4 seconds (which can FEEL like forever, but really isn't).


My biggest problem is that I can't tune to the ACC Network with the Ceton card. I can't get the tuner to pull the new data even after a HITT is sent etc from the cable company. I suspect it is a firmware issue and I'm simply going to be SOL for that one channel. Luckily I can stream it on other devices.