OpenDCT: An open source digital cable tuner.

[EnterNoEscape]

Originally Posted by wayner

Ok, step 1 accomplished - I can now add the two new sources. I must have missed that instruction about network encoders in the guide.

However I don't seem to get a valid stream, when I try to preview the channel I get "Watch request failed. null".

The streaming URL is listed as http\://192.168.1.32/mjpeg.cgi. Is that correct with the extra backslash? Or should the URL not include http://? Or do I need an executable of some sort as an intermediary?

It also appears that both IP cameras are trying to use port 9001. Should I be changing one of them?

Here is the opendct.log

18:38:29.701 [WrapperSimpleAppMain] INFO  Main - Starting OpenDCT 0.5.21...
18:38:29.708 [WrapperSimpleAppMain] DEBUG Config - OSVersion determined that 'Windows 8.1' is WINDOWS.
18:38:29.726 [WrapperSimpleAppMain] INFO  Main - OpenDCT logging to the directory 'c:/ProgramData/OpenDCT/logs'.
18:38:29.729 [WrapperSimpleAppMain] INFO  UpnpManager - Logging Cling UPnP to 'c:/ProgramData/OpenDCT/logs\opendct_cling.log'.
18:38:29.729 [WrapperSimpleAppMain] DEBUG UpnpManager - Logging level for Cling UPnP is set to 'severe'.
18:38:29.729 [FFmpegAsyncInit-20] INFO  Main - FFmpeg loading...
18:38:29.731 [FFmpegAsyncInit-20] DEBUG FFmpegUtil - Initializing FFmpegLogger...
18:38:29.810 [WindowsPowerMessagePump] INFO  WindowsPowerMessagePump - Message pump started.
18:38:29.832 [FFmpegAsyncInit-20] DEBUG FFmpegUtil - Calling av_log_set_callback...
18:38:29.832 [FFmpegAsyncInit-20] DEBUG FFmpegUtil - Calling avcodec_register_all...
18:38:30.740 [FFmpegAsyncInit-20] DEBUG FFmpegUtil - Calling avfilter_register_all...
18:38:31.401 [FFmpegAsyncInit-20] DEBUG FFmpegUtil - Calling av_register_all...
18:38:31.401 [FFmpegAsyncInit-20] INFO  Main - FFmpeg loaded in 1672ms.
18:38:34.759 [WrapperSimpleAppMain] INFO  NetworkPowerEventManger - Network interfaces which are up and have an IP4 address are: 
name:eth5 (Intel(R) Ethernet Connection (2) I219-V) 192.168.1.98
18:38:34.759 [WrapperSimpleAppMain] DEBUG WindowsPowerMessagePump - 'class opendct.power.NetworkPowerEventManger' is now listening.
18:38:34.760 [WrapperSimpleAppMain] DEBUG WindowsPowerMessagePump - 'class opendct.sagetv.SageTVManager' is now listening.
18:38:34.763 [DynamicAsyncInit-20] INFO  DynamicConsumerImpl - Dynamic consumer default set to use opendct.consumer.FFmpegTransSageTVConsumerImpl
18:38:34.763 [DynamicAsyncInit-20] INFO  DynamicConsumerImpl - Dynamic consumer set to use opendct.consumer.FFmpegTransSageTVConsumerImpl for []
18:38:34.763 [DynamicAsyncInit-20] INFO  DynamicConsumerImpl - Dynamic consumer set to use opendct.consumer.MediaServerConsumerImpl for []
18:38:34.763 [DynamicAsyncInit-20] INFO  DynamicConsumerImpl - Dynamic consumer set to use opendct.consumer.RawSageTVConsumerImpl for []
18:38:37.082 [WrapperSimpleAppMain] INFO  UpnpManager - Starting UPnP services...
18:38:37.113 [WrapperSimpleAppMain] INFO  DCTDefaultUpnpServiceConfiguration - Using the interface 'eth5' with IP address 192.168.1.98 for UPnP discovery.
18:38:37.125 [WrapperSimpleAppMain] DEBUG UpnpManager - Sending a SecureContainer search message for 'schemas-cetoncorp-com' devices...
18:38:37.130 [UPnPDiscovery-36] INFO  UpnpManager - UPnP discovery thread has started.
18:38:37.151 [HDHomeRunDiscoverySend-37] INFO  HDHomeRunDiscovery - HDHomeRun discovery sender thread started.
18:38:37.151 [HDHomeRunDiscoveryReceive-37] INFO  HDHomeRunDiscovery - HDHomeRun discovery receive thread for /192.168.1.255:65001 broadcast started.
18:38:37.151 [WrapperSimpleAppMain] DEBUG WindowsPowerMessagePump - 'class opendct.tuning.discovery.DiscoveryManager' is now listening.
18:38:37.152 [HDHomeRunDiscoverySend-37] INFO  HDHomeRunDiscovery - Broadcasting HDHomeRun discovery packet to /192.168.1.255:65001... (startup)
18:38:37.152 [WrapperSimpleAppMain] INFO  NanoHTTPDManager - Starting webserver on port 9091...
18:38:37.154 [GenericHttpLoader-40] DEBUG DeviceLoaderImpl - Advertising new capture device 'Kitchen'.
18:38:37.156 [HDHomeRunDiscoveryReceive-37] DEBUG HDHomeRunControl - key: '/tuner0/lockkey' value: 'null' lockKey: '0' sendLength: 26 address: 192.168.1.150
18:38:37.156 [GenericHttpLoader-40] DEBUG SageTVManager - The requested capture device 'Kitchen' did not exist. Triggering re-discovery.
18:38:37.156 [GenericHttpLoader-40] DEBUG DynamicConsumerImpl - Using default consumer 'opendct.consumer.FFmpegTransSageTVConsumerImpl' for channel ''
18:38:37.161 [GenericHttpLoader-40] DEBUG SageTVManager - Port 9001 is available.
18:38:37.162 [HDHomeRunDiscoveryReceive-37] DEBUG HDHomeRunControl - key: '/tuner1/lockkey' value: 'null' lockKey: '0' sendLength: 26 address: 192.168.1.150
18:38:37.163 [GenericHttpLoader-40] INFO  SageTVManager - The capture device 'Kitchen' is ready.
18:38:37.164 [GenericHttpLoader-40] DEBUG SageTVSocketServer - Setting listening flag...
18:38:37.164 [GenericHttpLoader-40] INFO  SageTVSocketServer - Opening ServerSocket on port 9001...
18:38:37.164 [SageTVTuningMonitor-47] INFO  SageTVTuningMonitor - Tuning monitor thread started.
18:38:37.164 [SageTVSocketServer-48:9001] INFO  SageTVSocketServer - Started listening on port 9001...
18:38:37.169 [WrapperSimpleAppMain] DEBUG WindowsPowerMessagePump - 'class opendct.nanohttpd.NanoHTTPDManager' is now listening.
18:38:37.169 [WrapperSimpleAppMain] DEBUG WindowsPowerMessagePump - 'class opendct.channel.ChannelManager' is now listening.
18:38:37.169 [HDHomeRunDiscoveryReceive-37] DEBUG HDHomeRunDiscovery - HDHomerun device returned an unknown tag with the length 35. This can be ignored.
18:38:37.171 [HDHomeRunDiscoveryReceive-37] DEBUG HDHomeRunControl - key: '/sys/hwmodel' value: 'null' lockKey: '0' sendLength: 23 address: 192.168.1.150
18:38:37.175 [WrapperSimpleAppMain] INFO  Main - Running in daemon mode...
18:38:37.180 [HDHomeRunDiscoveryReceive-37] INFO  HDHomeRunDiscoverer - Discovered a new HDHomeRun device 'HDHomeRun HDHR4-2US 1040E3E1' with 2 tuners.
18:38:37.184 [GenericHttpLoader-40] DEBUG DeviceLoaderImpl - Advertising new capture device 'Bedroom'.
18:38:37.184 [GenericHttpLoader-40] DEBUG SageTVManager - The requested capture device 'Bedroom' did not exist. Triggering re-discovery.
18:38:37.184 [GenericHttpLoader-40] DEBUG DynamicConsumerImpl - Using default consumer 'opendct.consumer.FFmpegTransSageTVConsumerImpl' for channel ''
18:38:37.186 [GenericHttpLoader-40] INFO  SageTVManager - The capture device 'Bedroom' is ready.
18:38:37.205 [HDHomeRunDiscoveryReceive-37] DEBUG DeviceLoaderImpl - Advertising new capture device 'HDHomeRun HDHR4-2US Tuner 1040E3E1-0'.
18:38:37.207 [HDHomeRunDiscoveryReceive-37] DEBUG SageTVManager - The requested capture device 'HDHomeRun HDHR4-2US Tuner 1040E3E1-0' did not exist. Triggering re-discovery.
18:38:37.207 [HDHomeRunDiscoveryReceive-37] INFO  BasicCaptureDevice - Skipping capture device 'HDHomeRun HDHR4-2US Tuner 1040E3E1-0' because it is on the ignore list.
18:38:37.208 [HDHomeRunDiscoveryReceive-37] WARN  HDHomeRunDiscoverer - Capture device will not be loaded => Capture device cannot be loaded because it is on the ignore list.
18:38:37.208 [HDHomeRunDiscoveryReceive-37] ERROR DeviceLoaderImpl - The capture device 'HDHomeRun HDHR4-2US Tuner 1040E3E1-0' did not load.
18:38:37.208 [HDHomeRunDiscoveryReceive-37] DEBUG DeviceLoaderImpl - Advertising new capture device 'HDHomeRun HDHR4-2US Tuner 1040E3E1-1'.
18:38:37.208 [HDHomeRunDiscoveryReceive-37] DEBUG SageTVManager - The requested capture device 'HDHomeRun HDHR4-2US Tuner 1040E3E1-1' did not exist. Triggering re-discovery.
18:38:37.208 [HDHomeRunDiscoveryReceive-37] INFO  BasicCaptureDevice - Skipping capture device 'HDHomeRun HDHR4-2US Tuner 1040E3E1-1' because it is on the ignore list.
18:38:37.208 [HDHomeRunDiscoveryReceive-37] WARN  HDHomeRunDiscoverer - Capture device will not be loaded => Capture device cannot be loaded because it is on the ignore list.
18:38:37.208 [HDHomeRunDiscoveryReceive-37] ERROR DeviceLoaderImpl - The capture device 'HDHomeRun HDHR4-2US Tuner 1040E3E1-1' did not load.
18:38:37.353 [HDHomeRunDiscoverySend-37] INFO  HDHomeRunDiscovery - Broadcasting HDHomeRun discovery packet to /192.168.1.255:65001... (requested)
18:38:37.354 [HDHomeRunDiscoveryReceive-37] DEBUG HDHomeRunControl - key: '/tuner0/lockkey' value: 'null' lockKey: '0' sendLength: 26 address: 192.168.1.150
18:38:37.363 [HDHomeRunDiscoveryReceive-37] DEBUG HDHomeRunControl - key: '/tuner1/lockkey' value: 'null' lockKey: '0' sendLength: 26 address: 192.168.1.150
18:38:37.373 [HDHomeRunDiscoveryReceive-37] DEBUG HDHomeRunDiscovery - HDHomerun device returned an unknown tag with the length 35. This can be ignored.
18:38:37.553 [HDHomeRunDiscoverySend-37] INFO  HDHomeRunDiscovery - Broadcasting HDHomeRun discovery packet to /192.168.1.255:65001... (startup)
18:38:37.554 [HDHomeRunDiscoveryReceive-37] DEBUG HDHomeRunControl - key: '/tuner0/lockkey' value: 'null' lockKey: '0' sendLength: 26 address: 192.168.1.150
18:38:37.566 [HDHomeRunDiscoveryReceive-37] DEBUG HDHomeRunControl - key: '/tuner1/lockkey' value: 'null' lockKey: '0' sendLength: 26 address: 192.168.1.150
18:38:37.575 [HDHomeRunDiscoveryReceive-37] DEBUG HDHomeRunDiscovery - HDHomerun device returned an unknown tag with the length 35. This can be ignored.
18:38:37.754 [HDHomeRunDiscoverySend-37] INFO  HDHomeRunDiscovery - Broadcasting HDHomeRun discovery packet to /192.168.1.255:65001... (startup)
18:38:37.755 [HDHomeRunDiscoveryReceive-37] DEBUG HDHomeRunControl - key: '/tuner0/lockkey' value: 'null' lockKey: '0' sendLength: 26 address: 192.168.1.150
18:38:37.759 [HDHomeRunDiscoveryReceive-37] DEBUG HDHomeRunControl - key: '/tuner1/lockkey' value: 'null' lockKey: '0' sendLength: 26 address: 192.168.1.150
18:38:37.769 [HDHomeRunDiscoveryReceive-37] DEBUG HDHomeRunDiscovery - HDHomerun device returned an unknown tag with the length 35. This can be ignored.
18:38:41.131 [UPnPDiscovery-36] DEBUG UpnpManager - Sending a SecureContainer search message for 'schemas-cetoncorp-com' devices...
18:38:45.132 [UPnPDiscovery-36] DEBUG UpnpManager - Sending a SecureContainer search message for 'schemas-cetoncorp-com' devices...
18:38:49.132 [UPnPDiscovery-36] DEBUG UpnpManager - Sending a SecureContainer search message for 'schemas-cetoncorp-com' devices...
18:38:53.133 [UPnPDiscovery-36] DEBUG UpnpManager - Sending a SecureContainer search message for 'schemas-cetoncorp-com' devices...
18:38:57.133 [UPnPDiscovery-36] DEBUG UpnpManager - Sending a SecureContainer search message for 'schemas-cetoncorp-com' devices...
18:39:01.134 [UPnPDiscovery-36] DEBUG UpnpManager - Sending a SecureContainer search message for 'schemas-cetoncorp-com' devices...
18:39:05.135 [UPnPDiscovery-36] DEBUG UpnpManager - Sending a SecureContainer search message for 'schemas-cetoncorp-com' devices...
18:39:09.135 [UPnPDiscovery-36] DEBUG UpnpManager - Sending a SecureContainer search message for 'schemas-cetoncorp-com' devices...
18:39:09.135 [UPnPDiscovery-36] DEBUG UpnpManager - Stopping broadcast.
18:39:09.135 [UPnPDiscovery-36] DEBUG DiscoveryRegistryListener - Before shutdown, the registry has 3 device(s).
18:39:09.135 [UPnPDiscovery-36] DEBUG DiscoveryRegistryListener - Shutdown of UPnP registry complete.
18:39:15.148 [UPnPDiscovery-36] DEBUG UpnpManager - Broadcast requested.
18:39:15.166 [UPnPDiscovery-36] INFO  DCTDefaultUpnpServiceConfiguration - Using the interface 'eth5' with IP address 192.168.1.98 for UPnP discovery.
18:39:19.168 [UPnPDiscovery-36] DEBUG UpnpManager - Sending a SecureContainer search message for 'schemas-cetoncorp-com' devices...
18:39:23.169 [UPnPDiscovery-36] DEBUG UpnpManager - Sending a SecureContainer search message for 'schemas-cetoncorp-com' devices...
18:39:26.310 [SageTVSocketServer-48:9001] WARN  SageTVSocketServer - IPv6 connection detected. This is an untested configuration.
18:39:27.169 [UPnPDiscovery-36] DEBUG UpnpManager - Sending a SecureContainer search message for 'schemas-cetoncorp-com' devices...
18:39:31.170 [UPnPDiscovery-36] DEBUG UpnpManager - Sending a SecureContainer search message for 'schemas-cetoncorp-com' devices...
18:39:35.171 [UPnPDiscovery-36] DEBUG UpnpManager - Sending a SecureContainer search message for 'schemas-cetoncorp-com' devices...
18:39:39.171 [UPnPDiscovery-36] DEBUG UpnpManager - Sending a SecureContainer search message for 'schemas-cetoncorp-com' devices...
18:39:43.172 [UPnPDiscovery-36] DEBUG UpnpManager - Sending a SecureContainer search message for 'schemas-cetoncorp-com' devices...
18:39:47.173 [UPnPDiscovery-36] DEBUG UpnpManager - Sending a SecureContainer search message for 'schemas-cetoncorp-com' devices...
18:39:47.173 [UPnPDiscovery-36] DEBUG UpnpManager - Stopping broadcast.
18:39:47.173 [UPnPDiscovery-36] WARN  DiscoveryRegistryListener - Before UPnP shutdown, the registry did not contain any devices.
18:39:47.173 [UPnPDiscovery-36] DEBUG DiscoveryRegistryListener - Shutdown of UPnP registry complete.
18:40:02.051 [SageTVRequestHandler-73:Unknown] DEBUG SageTVRequestHandler - SageTV sent: 'START Bedroom HDMI|266592774|1|2968356004100|\\brora\tv\639600969_1_0111_1840-0.ts|Great-H.264'
18:40:02.051 [SageTVRequestHandler-73:Bedroom] DEBUG GenericHttpCaptureDevice - Capture device is now re-locked.
18:40:02.051 [SageTVRequestHandler-73:Bedroom] DEBUG SageTVRequestHandler - Starting network encoder via upload ID '266592774' to file name '\\brora\tv\639600969_1_0111_1840-0.ts'.
18:40:02.051 [SageTVRequestHandler-73:Bedroom] DEBUG BasicCaptureDevice - Consumer is was not in progress.
18:40:02.052 [SageTVRequestHandler-73:Bedroom] DEBUG DynamicConsumerImpl - Using default consumer 'opendct.consumer.FFmpegTransSageTVConsumerImpl' for channel '1'
18:40:02.055 [SageTVRequestHandler-73:Bedroom] INFO  GenericHttpCaptureDevice - Starting the encoding for the channel '1' from the device 'Bedroom' to the file '\\brora\tv\639600969_1_0111_1840-0.ts'...
18:40:02.055 [SageTVRequestHandler-73:Bedroom] INFO  GenericHttpCaptureDevice - Configuring and starting the new SageTV producer...
18:40:02.055 [SageTVRequestHandler-73:Bedroom] INFO  NIOHTTPProducerImpl - Connecting to source using the URL 'http://192.168.1.31/mjpeg.cgi'
18:40:02.055 [SageTVRequestHandler-73:Bedroom] INFO  NIOHTTPProducerImpl - Connecting with credentials.
18:40:02.078 [SageTVRequestHandler-73:Bedroom] DEBUG NIOHttpDownloader - HTTP response: 'HTTP/1.0 401 Authorization Required', 'Server: alphapd', 'Date: Wed Jan 11 18:40:00 2017', 'Pragma: no-cache', 'Cache-Control: no-cache', 'Content-type: text/html', 'WWW-Authenticate: Basic realm="TV-IP651WI"', 
18:40:02.078 [SageTVRequestHandler-73:Bedroom] INFO  GenericHttpCaptureDevice - Configuring and starting the new SageTV consumer...
18:40:02.078 [NIOHTTPProducerImpl-74:Bedroom] INFO  NIOHTTPProducerImpl - Producer thread is running.
18:40:02.078 [NIOHTTPProducerImpl-74:Bedroom] DEBUG NIOHTTPProducerImpl - Thread priority is 9.
18:40:02.078 [NIOHTTPProducerImpl-74:Bedroom] INFO  NIOHTTPProducerImpl - We have reached the end of the stream. Stopping thread.
18:40:02.078 [NIOHTTPProducerImpl-74:Bedroom] INFO  NIOHTTPProducerImpl - Producer thread has stopped.
18:40:02.080 [SageTVRequestHandler-73:Bedroom] DEBUG BasicCaptureDevice - Consumer is was not in progress.
18:40:02.081 [FFmpegTransSageTVConsumerImpl-76:Bedroom] INFO  FFmpegTransSageTVConsumerImpl - FFmpeg Transcoder consumer thread is now running.
18:40:02.081 [FFmpegTransSageTVConsumerImpl-76:Bedroom] DEBUG FFmpegTransSageTVConsumerImpl - Thread priority is 8.
18:40:02.088 [FFmpegTransSageTVConsumerImpl-76:Bedroom] DEBUG FFmpegStreamDetection - Calling avformat_open_input
18:40:02.590 [FFmpegTransSageTVConsumerImpl-76:Bedroom] INFO  FFmpegContext - Returning AVERROR_EOF in readCallback.call()
18:40:03.111 [FFmpegTransSageTVConsumerImpl-76:Bedroom] INFO  FFmpegContext - Returning AVERROR_EOF in readCallback.call()
18:40:03.612 [FFmpegTransSageTVConsumerImpl-76:Bedroom] INFO  FFmpegContext - Returning AVERROR_EOF in readCallback.call()
18:40:03.612 [FFmpegTransSageTVConsumerImpl-76:Bedroom] ERROR FFmpegContext - initTsStream: avformat_open_input returned error code -1094995529
18:40:03.612 [FFmpegTransSageTVConsumerImpl-76:Bedroom] DEBUG FFmpegStreamDetection - Calling avformat_open_input
18:40:04.114 [FFmpegTransSageTVConsumerImpl-76:Bedroom] INFO  FFmpegContext - Returning AVERROR_EOF in readCallback.call()
18:40:04.615 [FFmpegTransSageTVConsumerImpl-76:Bedroom] INFO  FFmpegContext - Returning AVERROR_EOF in readCallback.call()
18:40:05.116 [FFmpegTransSageTVConsumerImpl-76:Bedroom] INFO  FFmpegContext - Returning AVERROR_EOF in readCallback.call()
18:40:05.116 [FFmpegTransSageTVConsumerImpl-76:Bedroom] ERROR FFmpegContext - initTsStream: avformat_open_input returned error code -1094995529
18:40:07.171 [ChannelManager-50] INFO  ChannelManager - The static channel lineup Kitchen (generic_http) will remain unchanged.
18:40:07.171 [ChannelManager-50] INFO  ChannelManager - Updating the HDHomeRun channel lineup HDHomeRun HDHR4-2US 1040E3E1 (atsc_hdhomerun_1040e3e1).
18:40:07.172 [ChannelManager-50] INFO  HDHomeRunChannels - Connecting to HDHomeRun using the URL 'http://192.168.1.150:80/lineup.xml'
18:40:15.123 [FFmpegTransSageTVConsumerImpl-76:Bedroom] DEBUG FFmpegStreamDetection - Calling avformat_open_input
18:40:15.624 [FFmpegTransSageTVConsumerImpl-76:Bedroom] INFO  FFmpegContext - Returning AVERROR_EOF in readCallback.call()
18:40:16.126 [FFmpegTransSageTVConsumerImpl-76:Bedroom] INFO  FFmpegContext - Returning AVERROR_EOF in readCallback.call()
18:40:16.627 [FFmpegTransSageTVConsumerImpl-76:Bedroom] INFO  FFmpegContext - Returning AVERROR_EOF in readCallback.call()
18:40:16.627 [FFmpegTransSageTVConsumerImpl-76:Bedroom] ERROR FFmpegContext - initTsStream: avformat_open_input returned error code -1094995529
18:40:16.627 [FFmpegTransSageTVConsumerImpl-76:Bedroom] INFO  FFmpegTransSageTVConsumerImpl - Unable to detect any video.
18:40:16.627 [AsyncWriter-75:639600969_1_0111_1840-0.ts] INFO  FFmpegTransSageTVConsumerImpl - Closing the file '\\brora\tv\639600969_1_0111_1840-0.ts'
18:40:17.082 [SageTVRequestHandler-73:Bedroom] DEBUG SageTVRequestHandler - Replied: 'OK'
18:40:17.082 [SageTVRequestHandler-73:Bedroom] DEBUG SageTVRequestHandler - An unhandled exception was created => java.net.SocketException: Software caused connection abort: recv failed
	at java.net.SocketInputStream.socketRead0(Native Method)
	at java.net.SocketInputStream.read(Unknown Source)
	at java.net.SocketInputStream.read(Unknown Source)
	at sun.nio.cs.StreamDecoder.readBytes(Unknown Source)
	at sun.nio.cs.StreamDecoder.implRead(Unknown Source)
	at sun.nio.cs.StreamDecoder.read(Unknown Source)
	at java.io.InputStreamReader.read(Unknown Source)
	at java.io.BufferedReader.fill(Unknown Source)
	at java.io.BufferedReader.readLine(Unknown Source)
	at java.io.BufferedReader.readLine(Unknown Source)
	at opendct.sagetv.SageTVRequestHandler.run(SageTVRequestHandler.java:127)
	at java.lang.Thread.run(Unknown Source)

18:40:17.127 [FFmpegTransSageTVConsumerImpl-76:Bedroom] INFO  FFmpegTransSageTVConsumerImpl - FFmpeg Transcoder consumer thread stopped.
18:40:19.505 [SageTVRequestHandler-77:Unknown] DEBUG SageTVRequestHandler - SageTV sent: 'STOP Bedroom HDMI'
18:40:19.505 [SageTVRequestHandler-77:Bedroom] DEBUG GenericHttpCaptureDevice - Stopping encoding...
18:40:19.505 [SageTVRequestHandler-77:Bedroom] DEBUG BasicCaptureDevice - Consumer is was not in progress.
18:40:19.506 [SageTVRequestHandler-77:Bedroom] DEBUG GenericHttpCaptureDevice - Capture device is now re-unlocked.
18:40:19.506 [SageTVRequestHandler-77:Bedroom] DEBUG SageTVRequestHandler - Replied: 'OK'
18:40:19.506 [StoppingThread-79] DEBUG GenericHttpCaptureDevice - Stopping executable will be run in 15000 milliseconds.

What else can I do to try to fix? Should I try turning off passwords on my IP cam to see if it is an authentication issue?

I don't know if you did, but you can actually provide a username and password in the latest 0.5 betas. There is a bigger issue looming here that you're not going to like to hear. That looks like it's going to output MJPEG. OpenDCT doesn't have any handling for that format and I'm not sure SageTV will like it as a recording format.

I believe in another thread Fuzzy had suggested that cameras could be used, but you would likely need to use ffmpeg.exe to convert the stream to something more DVR friendly like H.264 and MPEG-TS. He was also suggesting the use of the Generic Pipe.

[wayner]

Originally Posted by EnterNoEscape

I believe in another thread Fuzzy had suggested that cameras could be used, but you would likely need to use ffmpeg.exe to convert the stream to something more DVR friendly like H.264 and MPEG-TS. He was also suggesting the use of the Generic Pipe.

Ok thanks, I started in that thread but then I saw that HTTP addresses could be streamed and I was hoping that this would work.

Theoretically would it work with cameras that output H.264?

[AlphaCrew]

Originally Posted by EnterNoEscape

Your InfiniTV 4 is taking longer than 2 minutes to come back to life after standby. That's a really long time. Try this:

1. Stop the OpenDCT service.
2. Change pm.network.resume_timeout_ms=120000 to a larger value like 240000 in opendct.properties.
3. Start the OpenDCT service.

The default value is 2 minutes (in milliseconds) before the program assumes something has gone wrong and restarts. When that happens, it creates the crash log you posted.

Testing now.. Thank you for the quick response. I just wanted you to know, this piece of software you've written and developed is fantastic, and I would really like to know if there is a mechanism in place where one could throw you a couple of bucks for some 'scooby snacks'?

You absolutely deserve it.

EDIT: No crash logs after wake from hibernation.

[EnterNoEscape]

Originally Posted by wayner

Ok thanks, I started in that thread but then I saw that HTTP addresses could be streamed and I was hoping that this would work.

Theoretically would it work with cameras that output H.264?

Most likely, yes. The most ideal configuration would have an audio stream too, but just H.264 video in an MPEG-TS container should be ok.

[EnterNoEscape]

Originally Posted by AlphaCrew

Testing now.. Thank you for the quick response. I just wanted you to know, this piece of software you've written and developed is fantastic, and I would really like to know if there is a mechanism in place where one could throw you a couple of bucks for some 'scooby snacks'?

You absolutely deserve it.

EDIT: No crash logs after wake from hibernation.

You could be right, but at this time I am satisfied with all of the happy users.

Excellent. Maybe 2 minutes is a little aggressive considering that if OpenDCT does restart, SageTV will probably miss at least the start of a recording. Since it seems like it's probably better to relax this time and I'm sure you're not the first person to experience this problem I'm going to just change the default value to 4 minutes on all new installations following the next release.

[wayner]

Is there a reason for using OpenDCT for the OTA version of the HDHR rather than using the HDHR the "old-fashioned" way?

[Fuzzy]

Originally Posted by wayner

Is there a reason for using OpenDCT for the OTA version of the HDHR rather than using the HDHR the "old-fashioned" way?

Stream fixes are one. Transcoding to h.264 as it records would be another.

[EnterNoEscape]

Originally Posted by Fuzzy

Stream fixes are one. Transcoding to h.264 as it records would be another.

I thought most people were doing it for the pooling. Can you expand on what you mean by stream fixes? Are you talking about the corrections done while remuxing?

[Fuzzy]

Originally Posted by EnterNoEscape

I thought most people were doing it for the pooling. Can you expand on what you mean by stream fixes? Are you talking about the corrections done while remuxing?

Yes, that's what I was alluding to. more an issue with cable than with ota, but a weak ota signal can also result in some screwy packets coming in, that ffmpeg could throw out and clean up the file a bit.

I honestly forgot about the pooling feature - I only use sage so it's not something I think about.

[wayner]

Originally Posted by Fuzzy

Stream fixes are one. Transcoding to h.264 as it records would be another.

Does it do this by default and should I be thinking about the CPU ramifications of this when I build my permanent unRAID server. Transcoding a couple of OTA channels will take a little bit of CPU resources, won't it? I guess it uses FFMPEG to do this - can FFMPEG take advantage of QuickSync to help with the transcoding?

[EnterNoEscape]

Originally Posted by wayner

Does it do this by default and should I be thinking about the CPU ramifications of this when I build my permanent unRAID server. Transcoding a couple of OTA channels will take a little bit of CPU resources, won't it? I guess it uses FFMPEG to do this - can FFMPEG take advantage of QuickSync to help with the transcoding?

A very good CPU should be able to transcode 1080i30 to 720p30 using a little more than one core. I added transcoding expecting that I would be adding hardware acceleration at some point. I didn't know at the time how much heavy lifting was in ffmpeg.c which is not a part of the libraries. FFmpeg can use QuickSync if it's built to support it, the implementation in OpenDCT does not. I have looked into this and it's a lot of work. Also Linux support for QuickSync is still very spotty, so at this time I do not have any plans to add support.

[wayner]

For my unRAID server I am thinking of recycling parts from a desktop PC from a few years ago. The CPU is an i5-2500K and the mobo is an Asus P8H67M-EVO. That CPU should be up to the task, shouldn't it? It has four cores and runs at 3.3GHz.

How would comskip work on a file being transcoded if you have it marking commercials as soon as the recording starts? Would it put a double load on the CPU?

One thing I am not so sure about is how that CPU works in a VM environment. Here are the specs - it doesn't support some of the VM stuff that Intel offers. Should I care about Vt-d?

Intel® Turbo Boost Technology ‡ 2.0
Intel® vPro Technology ‡ No
Intel® Hyper-Threading Technology ‡ No
Intel® Virtualization Technology (VT-x) ‡ Yes
Intel® Virtualization Technology for Directed I/O (VT-d) ‡ No
Intel® VT-x with Extended Page Tables (EPT) ‡ Yes
Intel® 64 ‡ Yes

[KarylFStein]

Originally Posted by wayner

Does it do this by default and should I be thinking about the CPU ramifications of this when I build my permanent unRAID server. Transcoding a couple of OTA channels will take a little bit of CPU resources, won't it? I guess it uses FFMPEG to do this - can FFMPEG take advantage of QuickSync to help with the transcoding?

I don't know what it ships with, but you can toggle raw/ffmpeg in the configuration file. Using FFMPEG didn't fix any issues I had and still have with Placeshifter and the Android client, so just set it to RAW. My HD300s work fine with that.

[EnterNoEscape]

Originally Posted by wayner

For my unRAID server I am thinking of recycling parts from a desktop PC from a few years ago. The CPU is an i5-2500K and the mobo is an Asus P8H67M-EVO. That CPU should be up to the task, shouldn't it? It has four cores and runs at 3.3GHz.

How would comskip work on a file being transcoded if you have it marking commercials as soon as the recording starts? Would it put a double load on the CPU?

One thing I am not so sure about is how that CPU works in a VM environment. Here are the specs - it doesn't support some of the VM stuff that Intel offers. Should I care about Vt-d?

Intel® Turbo Boost Technology ‡ 2.0
Intel® vPro Technology ‡ No
Intel® Hyper-Threading Technology ‡ No
Intel® Virtualization Technology (VT-x) ‡ Yes
Intel® Virtualization Technology for Directed I/O (VT-d) ‡ No
Intel® VT-x with Extended Page Tables (EPT) ‡ Yes
Intel® 64 ‡ Yes

I don't think that would put quite a double load on the CPU. The transcoding has to happen in realtime, but you can always run comskip with the nice parameter and it will take longer, but it also won't use very many resources at all.

VT-d is only of interest if you plan on passing PCI-e peripherals into your VMs. Your motherboard also needs to support it or it's as good as not having it. I prefer having it because it keeps my configuration options open.

[EnterNoEscape]

Originally Posted by KarylFStein

I don't know what it ships with, but you can toggle raw/ffmpeg in the configuration file. Using FFMPEG didn't fix any issues I had and still have with Placeshifter and the Android client, so just set it to RAW. My HD300s work fine with that.

Raw used to be a viable option for me, but now I have a few channels that are doing things wrong, so I prefer to just leave it on FFmpeg.

[Fuzzy]

Originally Posted by EnterNoEscape

A very good CPU should be able to transcode 1080i30 to 720p30 using a little more than one core. I added transcoding expecting that I would be adding hardware acceleration at some point. I didn't know at the time how much heavy lifting was in ffmpeg.c which is not a part of the libraries. FFmpeg can use QuickSync if it's built to support it, the implementation in OpenDCT does not. I have looked into this and it's a lot of work. Also Linux support for QuickSync is still very spotty, so at this time I do not have any plans to add support.

any particular reason to be calling ffmpeg as a library instead of using a precompiled binary for the ffmpeg duties? Then it would be relatively trivial to drop in a HW accellerated build.

[wayner]

Originally Posted by EnterNoEscape

I don't think that would put quite a double load on the CPU. The transcoding has to happen in realtime, but you can always run comskip with the nice parameter and it will take longer, but it also won't use very many resources at all.

VT-d is only of interest if you plan on passing PCI-e peripherals into your VMs. Your motherboard also needs to support it or it's as good as not having it. I prefer having it because it keeps my configuration options open.

Would that be an issue for using afireire card or a pcie Sata controller for more drives?

[EnterNoEscape]

Originally Posted by Fuzzy

any particular reason to be calling ffmpeg as a library instead of using a precompiled binary for the ffmpeg duties? Then it would be relatively trivial to drop in a HW accellerated build.

It provides for significantly tighter integration and I can make it do things that ffmpeg.c doesn't allow without modification. There is a particular timing issue that causes files output by the binary to be unplayable in WMP for example that OpenDCT was able to overcome because it's using the libraries instead. I can load up all of the libraries once and that time is never wasted again.

When you use ffmpeg.c there is a performance cost for every time you launch the executable. OpenDCT will repeatedly re-scan the stream until it sees that FFmpeg has found everything OpenDCT wants. Doing this process with ffmpeg.c while not impossible does take a significantly longer amount of time mostly because the libraries keep getting reloaded. I'm not completely closed off to the idea, but it works really well in this configuration and I doubt moving it over to the compile executable will make things better. Maybe it will become an option in a future release for those that really just want to know.

Edit: Switching is many times easier too since I know exactly where the next key frame is because FFmpeg told me that's what it is. I know I can scan the stream on the Java side and chop where needed, but I'm not going to be as good at identifying corner cases as this much more tested code in FFmpeg.

Originally Posted by wayner

Would that be an issue for using afireire card or a pcie Sata controller for more drives?

Only if you want to pass those peripherals into a VM.

[wayner]

Originally Posted by EnterNoEscape

Only if you want to pass those peripherals into a VM.

And SageTV for unRAID/Docker is not technically running in a VM, correct?

[EnterNoEscape]

Originally Posted by wayner

And SageTV for unRAID/Docker is not technically running in a VM, correct?

Correct with one caveat. In Docker, most of the time, the host OS needs to load the drivers for a peripheral. It doesn't matter if the container "OS" comes with drivers when installed as a full OS. So in order to use a peripheral in Docker, the host OS (in this case unRAID) needs to at least be able to load a driver for it.