OpenDCT: An open source digital cable tuner.

[EnterNoEscape]

I forgot to mention another feature I added in 0.4 that might interest several people who are running more than one copy of OpenDCT.

• Exclusive Server Address.

  If you set the property sagetv.device.<unique_id>.exclusive_server_address to the IP address of the server intended to use it, when PROPERTIES are requested if the request did not come from this IP address, the capture device is not returned. This should help some people clean up tuner discovery, since you can now effectively make specific tuners only visible to a specific server.

[troll5501]

Originally Posted by EnterNoEscape

The messages that you're seeing implies that FFmpeg has stopped consuming data from the buffer or that it is unable to write data because they are suggesting that the circular buffer is overflowing. I'm not sure this is exactly the same issue, but the trigger is the same as you noted. Please post a log from when it happens so I can possibly give you better direction.

Two log files are attached. Please let me know if you need any other information. Thanks!

[EnterNoEscape]

Originally Posted by troll5501

Two log files are attached. Please let me know if you need any other information. Thanks!

Base on the evidence in the logs, it appears that FFmpeg is in fact still running; so that's good. It didn't crash or do anything odd, so that leaves us with only two other reasonable alternative ideas on what's happening. The first one is the hard drive isn't keeping up, but due to past performance, I'm going to assume that's not the problem. The second one has to do with the Windows XP scheduler prioritizing threads differently than newer versions of Windows.

From what I'm seeing in the logs, the producer thread is out-pacing the consumer thread. It just so happens that the producer thread has a higher priority than the consumer thread. There's a good reason for the producer to have a higher priority; we don't get a second chance to grab a UDP packet. I'll post a new beta that addresses this potential imbalance after I do some testing to make reasonably sure it doesn't have any unintended side effects.

[EnterNoEscape]

The beta has been updated to allow the producer and consumer thread priorities to be changed. Under normal circumstances you would not want to do this, but if you're having problems like troll5501, being able to adjust these properties could help you. I have already adjusted the defaults to make the two dependent threads less likely to get out of sync per my previous post.

The range is 1-10 (10 being highest priority, 5 being normal). The properties are consumer.ffmpeg.thread_priority=8 and producer.rtp.nio.thread_priority=9. Also to reiterate, you should not under normal circumstances need to change the default values.

If you are not having this kind of issue, there is no rush to upgrade.

[jgsouthard]

EnterNoEscape, spencerw, and those helping -- this is amazing work!

I've been having all kinds of problems with SageDCT 2.7.4 and PrimeNetEncoder 2.0.0 with Comcast in Windows 10. SageDCT causes bad pixelation/skips with FFMPEG and unwatchable recordings using DUMP (regardless of the encode_digital_tv_as_program_stream setting). PNE 2.0.0 will only work with one HDHomeRun Prime (3 tuners) -- if I add my second one I start getting mostly No Signal and Halts in Recording.

So tonight I decided to give OpenDCT 0.4.14 a try. Using Daweeze's excellent step-by-step installation procedure in Post #175, I had OpenDCT installed in 20 minutes. WAY easier than either SageDCT or PrimeNetEncoder. Something similar to Daweeze's instructions needs to be documented on GitHub, I think.

Setup went smoothly. OpenDCT recognized my two HDHomeRun Primes with no problem, and I got them added to SageTV (and deleted the old ones from PNE) with no problems.

But alas, all was not roses. I found that I was getting No Signal / Halts in Recording frequently. After browsing the opendct.properties file for a bit, I increased both consumer.ffmpeg.min_analyze_duration and consumer.ffmpeg.min_probe_size to 5000000, and it seems to be working fine now based on an hour of testing. You may have the defaults a bit too aggressive on those. So far everything else in opendct.properties is at the defaults, although I want to investigate pooling so my occasional use of HDHomeRun View from another device on the network doesn't cause me to loose a SageTV recording.

I'll give it another 2-3 days before declaring victory, but even if I run into some other problems I'm still WAY impressed with what you've accomplished on this in such a short period of time.

[jgsouthard]

I spoke too soon. I'm still getting No Signal / Halt errors, although so far they seem to be recovering within a minute or two into the recording. I've attached the logs, and the last example of the error occurred when a recording kicked off on channel 657 at 2016/01/18 20:59:00.092. What do all of those errors indicate? Is there a simple fix?

[troll5501]

Originally Posted by EnterNoEscape

The beta has been updated to allow the producer and consumer thread priorities to be changed. Under normal circumstances you would not want to do this, but if you're having problems like troll5501, being able to adjust these properties could help you. I have already adjusted the defaults to make the two dependent threads less likely to get out of sync per my previous post.
If you are not having this kind of issue, there is no rush to upgrade.

Thanks! I've done some initial testing and the new thread priority defaults seem to be helping. I still need to keep rw_buffer_size at 256K for stability during times of high CPU. I'll do more testing over the next few days.

However, in 0.4.x I am seeing a new issue that I did not see in 0.3.16 and it may be similar to what the previous poster described. Often when tuning a channel it "fails" and I get "No Signal" in SageTV. The HDHR tuner LED is lit but no data is streaming (file size is not growing). After a minute or so, SageTV restarts the recording and then usually it works. I don't remember ever seeing this in 0.3.16.

I've uploaded today's logfile for your review. The java.lang.ArrayIndexOutOfBoundsException seems to occur frequently when starting recordings. Some highlights:

10:50:52.157 [FFmpegSageTVConsumerImpl-2328:DCT-HDHomeRun Prime Tuner 13191941-2] ERROR FFmpegSageTVConsumerImpl - FFmpeg remux failed: Could not find a video stream.
10:50:52.157 [FFmpegSageTVConsumerImpl-2328:DCT-HDHomeRun Prime Tuner 13191941-2] INFO  FFmpegSageTVConsumerImpl - FFmpeg consumer thread is stopping.
10:50:52.157 [FFmpegSageTVConsumerImpl-2328:DCT-HDHomeRun Prime Tuner 13191941-2] INFO  FFmpegSageTVConsumerImpl - FFmpeg consumer thread has stopped.
10:52:04.253 [SageTVRequestHandler-2263:DCT-HDHomeRun Prime Tuner 13191941-2] DEBUG DCTCaptureDeviceImpl - Stopping encoding...
10:52:04.253 [SageTVRequestHandler-2263:DCT-HDHomeRun Prime Tuner 13191941-2] DEBUG RTPCaptureDevice - Stopping producer thread...
10:52:04.253 [SageTVRequestHandler-2263:DCT-HDHomeRun Prime Tuner 13191941-2] DEBUG RTPCaptureDevice - Waiting for producer thread to stop...
10:52:04.253 [NIORTPProducerImpl-2272:DCT-HDHomeRun Prime Tuner 13191941-2] DEBUG NIORTPProducerImpl - Producer was closed by an asynchronous close exception => java.nio.channels.AsynchronousCloseException

10:52:09.925 [FFmpegSageTVConsumerImpl-2398:DCT-HDHomeRun Prime Tuner 13191941-2] ERROR SeekableCircularBuffer - throwing java.lang.ArrayIndexOutOfBoundsException: You cannot move the read index beyond the currently available data.
10:52:09.925 [FFmpegSageTVConsumerImpl-2398:DCT-HDHomeRun Prime Tuner 13191941-2] ERROR SeekableCircularBuffer - throwing java.lang.ArrayIndexOutOfBoundsException: You cannot move the read index beyond the currently available data.
10:52:09.925 [FFmpegSageTVConsumerImpl-2398:DCT-HDHomeRun Prime Tuner 13191941-2] WARN  FFmpegCircularBuffer - Seek: Requested a read index that is not yet available => java.lang.ArrayIndexOutOfBoundsException: You cannot move the read index beyond the currently available data.
10:52:09.925 [FFmpegSageTVConsumerImpl-2398:DCT-HDHomeRun Prime Tuner 13191941-2] WARN  FFmpegCircularBuffer - Seek: Requested a read index that is not yet available => java.lang.ArrayIndexOutOfBoundsException: You cannot move the read index beyond the currently available data.

[EnterNoEscape]

I will clean that up on GitHub. First time use details are a little better spelled out in the paragraph starting with "For the first run..." in the first post on this thread. I agree that GitHub should have something similar, and probably better. I will however continue to make the assumption that people know how to add a new capture device within the GUI.

Increasing consumer.ffmpeg.min_analyze_duration should only help you out if for some reason you're getting the wrong audio streams. The streaming doesn't start until at least one video stream and one audio stream is detected. It will continue to collect packets and try to detect everything it needs until it gets to consumer.ffmpeg.max_analyze_duration. If it's helping for any other type of issue, we usually have a bigger problem.

I noticed that OpenDCT in your logs is being a little too tenacious about getting the program from the Prime and it was getting you to the point where the buffer was overflowing. I toned down the aggressiveness and added some extra handling for if any of the response from the HDHomeRun comes in fragmented. I suspect this is a big contributor to the no signal screen you're seeing. This change will be in the next beta release. (troll5501, this looks like the problem you're seeing too)

I see UPnP re-detecting the Prime. That usually means your Prime rebooted. The result appears to be OpenDCT having a lot of trouble re-establishing a connection to the Prime. Prior to this, we have clean communication for the most part. There is code to handle this kind of situation and it will try to re-connect. I'm going to focus on making the re-connecting code try a little harder and we'll see if that helps you out. These changes will also be in the next beta release.

[EnterNoEscape]

This one is far less aggressive about getting the currently tuned program from the capture device. FFmpeg can figure the value out on it's own, but this was put in as a helper before processing so that when it's available we can focus on it. The feature that takes advantage of this doesn't exist in the current beta code, but it will in the future.

This also addresses issues involving network communications with HDHomeRun devices. The focus is specifically in handling fragmented responses and attempts to reach the device when it is unreachable. There is a new property called hdhr.retry_count that defaults to 5. This is the number of times OpenDCT will try to execute a command when the HDHomeRun is not responding. The attempts have a 1 second interval. This will not slow things down in any way if everything on your network is functioning.

If you are not currently having any issues with HdHomeRun devices, I recommend that you wait for feedback on this release before upgrading.

[jgsouthard]

Thanks for the feedback and the quick response. I'll give 0.4.16 a try.

[jgsouthard]

I installed 0.4.16 this morning and renamed my opendct.properties so that OpenDCT would recreate it using all defaults. I then started a manual recording and immediately got No Signal, so I canceled that recording and set two more recordings to start a few minutes later, plus some other schedule recordings for the next couple of hours after that.

Attached are the logs from that test, with the results below:

06:12 Started OpenDCT 0.4.16

06:14 Started manual recording, No Signal

06:30 Started two scheduled recordings. Both cause "Halt detected in Recording" errors in the first minute or so, then began recording. Both had audio only, but no video.

06:59 Started one scheduled recording, which worked OK.

07:59 Started one scheduled recording, which caused a "Halt detected in Recording" error in the first minute or so, then began recording normally.

09:57 Stopped OpenDCT service and modified properties as follows, then restarted OpenDCT:
consumer.ffmpeg.max_analyze_duration=10000000
consumer.ffmpeg.max_probe_size=10000000
consumer.ffmpeg.min_analyze_duration=5000000
consumer.ffmpeg.min_probe_size=5000000
consumer.ffmpeg.rw_buffer_size=32768
consumer.ffmpeg.upload_id_enabled=false

I realize that most of these changes are not necessary; but SOMETHING I changed is helping, since recordings after 09:57 seem to be OK (logs not included beyond 09:57).

Although recordings after 09:57 seem OK so far, I'm still seeing hundreds of errors in opendct.log like the following during recording, even with these changes in opendct.properties:

11:52:19.283 [SageTVRequestHandler-466CT-HDHomeRun Prime Tuner 1319784E-0 > DCT-HDHomeRun Prime Tuner 132277E9-1] ERROR HDHomeRunControl - HDHomeRun device did not reply with a valid message for key = '/tuner1/program', value ='null' and lockkey='0'.
11:52:19.383 [SageTVRequestHandler-466CT-HDHomeRun Prime Tuner 1319784E-0 > DCT-HDHomeRun Prime Tuner 132277E9-1] DEBUG HDHomeRunControl - key: '/tuner1/program' value: 'null' lockKey: '0' sendLength: 26

[troll5501]

I've been running 0.4.16 since last night, and it looks much better so far. No tuning failures and no stuttering/hiccups as long as I keep the rw_buffer_size at 256K. I will continue to test and let you know if I experience any issues.

I do have a question about some things I see in the logs...not sure if they are normal or not. Neither one seems to be causing any problems:

1) I see many of the same messages as jgsouthard:

02:00:00.541 [SageTVRequestHandler-4277:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG HDHomeRunControl - bufferLimit: 30, packetLength: 22
02:00:00.541 [SageTVRequestHandler-4277:DCT-HDHomeRun Prime Tuner 13191941-0] ERROR HDHomeRunControl - HDHomeRun device did not reply with a valid message for key = '/tuner0/program', value ='null' and lockkey='0'.
02:00:00.651 [SageTVRequestHandler-4277:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG HDHomeRunControl - key: '/tuner0/program' value: 'null' lockKey: '0' sendLength: 26

2) Often when a recording stops or when I switch channels on live TV, I see several Java exceptions:

03:00:00.350 [SageTVRequestHandler-4838:null] DEBUG SageTVRequestHandler - SageTV sent: 'STOP DCT-HDHomeRun Prime Tuner 13191941-0 Digital TV Tuner'
03:00:00.350 [SageTVRequestHandler-4838:null] DEBUG SageTVRequestHandler - Renaming the thread 'SageTVRequestHandler-4838:null' to 'SageTVRequestHandler-4838:DCT-HDHomeRun Prime Tuner 13191941-0'...
03:00:00.350 [SageTVRequestHandler-4838:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG DCTCaptureDeviceImpl - Stopping encoding...
03:00:00.350 [SageTVRequestHandler-4838:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG RTPCaptureDevice - Stopping producer thread...
03:00:00.350 [NIORTPProducerImpl-4282:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG NIORTPProducerImpl - Producer was closed by an asynchronous close exception => java.nio.channels.AsynchronousCloseException
	at java.nio.channels.spi.AbstractInterruptibleChannel.end(Unknown Source)
	at sun.nio.ch.DatagramChannelImpl.receive(Unknown Source)
	at opendct.producer.NIORTPProducerImpl.run(NIORTPProducerImpl.java:272)
	at java.lang.Thread.run(Unknown Source)

03:00:00.350 [SageTVRequestHandler-4838:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG RTPCaptureDevice - Waiting for producer thread to stop...
03:00:00.350 [NIORTPProducerImpl-4282:DCT-HDHomeRun Prime Tuner 13191941-0] INFO  NIORTPProducerImpl - Producer thread has disconnected.
03:00:00.350 [NIORTPProducerImpl-4282:DCT-HDHomeRun Prime Tuner 13191941-0] INFO  NIORTPProducerImpl - Producer thread has stopped.
03:00:00.350 [RTCPClient-4281] DEBUG RTCPClient - The RTCP thread has been requested to stop => java.nio.channels.ClosedByInterruptException
	at java.nio.channels.spi.AbstractInterruptibleChannel.end(Unknown Source)
	at sun.nio.ch.DatagramChannelImpl.receive(Unknown Source)
	at opendct.video.rtsp.rtcp.RTCPClient.run(RTCPClient.java:137)
	at java.lang.Thread.run(Unknown Source)

03:00:00.350 [NIORTPProducerImpl-4282:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG NIORTPProducerImpl - Producer was interrupted while waiting for packet monitoring thread to stop => java.lang.InterruptedException
	at java.lang.Object.wait(Native Method)
	at java.lang.Thread.join(Unknown Source)
	at opendct.producer.NIORTPProducerImpl.run(NIORTPProducerImpl.java:358)
	at java.lang.Thread.run(Unknown Source)

03:00:00.350 [RTCPClient-4281] INFO  RTCPClient - RTCP client thread is stopped.
03:00:00.350 [PacketsMonitor-4284:NIORTPProducerImpl-4282:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG NIORTPProducerImpl - The packet monitoring thread has been interrupted.
03:00:00.350 [SageTVRequestHandler-4838:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG BasicCaptureDevice - Stopping consumer thread...
03:00:00.350 [PacketsMonitor-4284:NIORTPProducerImpl-4282:DCT-HDHomeRun Prime Tuner 13191941-0] INFO  NIORTPProducerImpl - Producer packet monitoring thread has stopped.
03:00:00.381 [SageTVRequestHandler-4838:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG BasicCaptureDevice - Waiting for consumer thread to stop...
03:00:00.381 [FFmpegSageTVConsumerImpl-4308:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG FFmpegSageTVConsumerImpl - Consumer created an IO exception => java.nio.channels.ClosedByInterruptException
	at java.nio.channels.spi.AbstractInterruptibleChannel.end(Unknown Source)
	at sun.nio.ch.FileChannelImpl.write(Unknown Source)
	at opendct.consumer.FFmpegSageTVConsumerImpl.writeBuffer(FFmpegSageTVConsumerImpl.java:707)
	at opendct.consumer.FFmpegSageTVConsumerImpl.access$900(FFmpegSageTVConsumerImpl.java:50)
	at opendct.consumer.FFmpegSageTVConsumerImpl$WriteCallback.call(FFmpegSageTVConsumerImpl.java:549)
	at org.bytedeco.javacpp.avformat.av_interleaved_write_frame(Native Method)
	at opendct.consumer.FFmpegSageTVConsumerImpl.remuxRtpPackets(FFmpegSageTVConsumerImpl.java:1067)
	at opendct.consumer.FFmpegSageTVConsumerImpl.run(FFmpegSageTVConsumerImpl.java:255)
	at java.lang.Thread.run(Unknown Source)

03:00:00.381 [FFmpegSageTVConsumerImpl-4308:DCT-HDHomeRun Prime Tuner 13191941-0] INFO  FFmpegSageTVConsumerImpl - Returning AVERROR_EOF in writeCallback.call()
03:00:00.381 [FFmpegSageTVConsumerImpl-4308:DCT-HDHomeRun Prime Tuner 13191941-0] ERROR FFmpegSageTVConsumerImpl - Error -541478725 while writing packet at input stream offset -1.
03:00:00.381 [FFmpegSageTVConsumerImpl-4308:DCT-HDHomeRun Prime Tuner 13191941-0] INFO  FFmpegSageTVConsumerImpl - FFmpeg consumer thread is stopping.
03:00:00.381 [FFmpegSageTVConsumerImpl-4308:DCT-HDHomeRun Prime Tuner 13191941-0] INFO  FFmpegSageTVConsumerImpl - FFmpeg consumer thread has stopped.

I've attached today's log for your review, even though I'm not seeing any issues so far.

Thanks for all of your recent work on this!

[EnterNoEscape]

Originally Posted by jgsouthard

I installed 0.4.16 this morning and renamed my opendct.properties so that OpenDCT would recreate it using all defaults. I then started a manual recording and immediately got No Signal, so I canceled that recording and set two more recordings to start a few minutes later, plus some other schedule recordings for the next couple of hours after that.

Attached are the logs from that test, with the results below:

06:12 Started OpenDCT 0.4.16

06:14 Started manual recording, No Signal

06:30 Started two scheduled recordings. Both cause "Halt detected in Recording" errors in the first minute or so, then began recording. Both had audio only, but no video.

06:59 Started one scheduled recording, which worked OK.

07:59 Started one scheduled recording, which caused a "Halt detected in Recording" error in the first minute or so, then began recording normally.

09:57 Stopped OpenDCT service and modified properties as follows, then restarted OpenDCT:
consumer.ffmpeg.max_analyze_duration=10000000
consumer.ffmpeg.max_probe_size=10000000
consumer.ffmpeg.min_analyze_duration=5000000
consumer.ffmpeg.min_probe_size=5000000
consumer.ffmpeg.rw_buffer_size=32768
consumer.ffmpeg.upload_id_enabled=false

I realize that most of these changes are not necessary; but SOMETHING I changed is helping, since recordings after 09:57 seem to be OK (logs not included beyond 09:57).

Although recordings after 09:57 seem OK so far, I'm still seeing hundreds of errors in opendct.log like the following during recording, even with these changes in opendct.properties:

11:52:19.283 [SageTVRequestHandler-466CT-HDHomeRun Prime Tuner 1319784E-0 > DCT-HDHomeRun Prime Tuner 132277E9-1] ERROR HDHomeRunControl - HDHomeRun device did not reply with a valid message for key = '/tuner1/program', value ='null' and lockkey='0'.
11:52:19.383 [SageTVRequestHandler-466CT-HDHomeRun Prime Tuner 1319784E-0 > DCT-HDHomeRun Prime Tuner 132277E9-1] DEBUG HDHomeRunControl - key: '/tuner1/program' value: 'null' lockKey: '0' sendLength: 26

The issues you had with your first run actually had to do with communication issues with the HDHomeRun. OpenDCT was unable to effectively re-establish a connection with it. I think I know what I'm missing and I'll address it in the next beta. I might be trying to be too efficient with the TCP/IP connections.

When you bumped the consumer.ffmpeg.max_probe_size up to 10000000, you also forcibly increased the circular buffer to about 11MB even then you didn't put that setting in the file. My guess would be the added buffer size is helping in some way.

The problems with getting the value of /tuner1/program fortunately isn't a critical problem, but I'm still trying to work out why it's not working when everything else is. I have add more logging on that particular piece that will hopefully reveal what's actually happening in the next beta.

Also... The audio only thing might be something Bill will need to take a look at.

[EnterNoEscape]

Originally Posted by troll5501

I've been running 0.4.16 since last night, and it looks much better so far. No tuning failures and no stuttering/hiccups as long as I keep the rw_buffer_size at 256K. I will continue to test and let you know if I experience any issues.

I do have a question about some things I see in the logs...not sure if they are normal or not. Neither one seems to be causing any problems:

1) I see many of the same messages as jgsouthard:

02:00:00.541 [SageTVRequestHandler-4277:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG HDHomeRunControl - bufferLimit: 30, packetLength: 22
02:00:00.541 [SageTVRequestHandler-4277:DCT-HDHomeRun Prime Tuner 13191941-0] ERROR HDHomeRunControl - HDHomeRun device did not reply with a valid message for key = '/tuner0/program', value ='null' and lockkey='0'.
02:00:00.651 [SageTVRequestHandler-4277:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG HDHomeRunControl - key: '/tuner0/program' value: 'null' lockKey: '0' sendLength: 26

2) Often when a recording stops or when I switch channels on live TV, I see several Java exceptions:

03:00:00.350 [SageTVRequestHandler-4838:null] DEBUG SageTVRequestHandler - SageTV sent: 'STOP DCT-HDHomeRun Prime Tuner 13191941-0 Digital TV Tuner'
03:00:00.350 [SageTVRequestHandler-4838:null] DEBUG SageTVRequestHandler - Renaming the thread 'SageTVRequestHandler-4838:null' to 'SageTVRequestHandler-4838:DCT-HDHomeRun Prime Tuner 13191941-0'...
03:00:00.350 [SageTVRequestHandler-4838:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG DCTCaptureDeviceImpl - Stopping encoding...
03:00:00.350 [SageTVRequestHandler-4838:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG RTPCaptureDevice - Stopping producer thread...
03:00:00.350 [NIORTPProducerImpl-4282:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG NIORTPProducerImpl - Producer was closed by an asynchronous close exception => java.nio.channels.AsynchronousCloseException
	at java.nio.channels.spi.AbstractInterruptibleChannel.end(Unknown Source)
	at sun.nio.ch.DatagramChannelImpl.receive(Unknown Source)
	at opendct.producer.NIORTPProducerImpl.run(NIORTPProducerImpl.java:272)
	at java.lang.Thread.run(Unknown Source)

03:00:00.350 [SageTVRequestHandler-4838:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG RTPCaptureDevice - Waiting for producer thread to stop...
03:00:00.350 [NIORTPProducerImpl-4282:DCT-HDHomeRun Prime Tuner 13191941-0] INFO  NIORTPProducerImpl - Producer thread has disconnected.
03:00:00.350 [NIORTPProducerImpl-4282:DCT-HDHomeRun Prime Tuner 13191941-0] INFO  NIORTPProducerImpl - Producer thread has stopped.
03:00:00.350 [RTCPClient-4281] DEBUG RTCPClient - The RTCP thread has been requested to stop => java.nio.channels.ClosedByInterruptException
	at java.nio.channels.spi.AbstractInterruptibleChannel.end(Unknown Source)
	at sun.nio.ch.DatagramChannelImpl.receive(Unknown Source)
	at opendct.video.rtsp.rtcp.RTCPClient.run(RTCPClient.java:137)
	at java.lang.Thread.run(Unknown Source)

03:00:00.350 [NIORTPProducerImpl-4282:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG NIORTPProducerImpl - Producer was interrupted while waiting for packet monitoring thread to stop => java.lang.InterruptedException
	at java.lang.Object.wait(Native Method)
	at java.lang.Thread.join(Unknown Source)
	at opendct.producer.NIORTPProducerImpl.run(NIORTPProducerImpl.java:358)
	at java.lang.Thread.run(Unknown Source)

03:00:00.350 [RTCPClient-4281] INFO  RTCPClient - RTCP client thread is stopped.
03:00:00.350 [PacketsMonitor-4284:NIORTPProducerImpl-4282:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG NIORTPProducerImpl - The packet monitoring thread has been interrupted.
03:00:00.350 [SageTVRequestHandler-4838:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG BasicCaptureDevice - Stopping consumer thread...
03:00:00.350 [PacketsMonitor-4284:NIORTPProducerImpl-4282:DCT-HDHomeRun Prime Tuner 13191941-0] INFO  NIORTPProducerImpl - Producer packet monitoring thread has stopped.
03:00:00.381 [SageTVRequestHandler-4838:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG BasicCaptureDevice - Waiting for consumer thread to stop...
03:00:00.381 [FFmpegSageTVConsumerImpl-4308:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG FFmpegSageTVConsumerImpl - Consumer created an IO exception => java.nio.channels.ClosedByInterruptException
	at java.nio.channels.spi.AbstractInterruptibleChannel.end(Unknown Source)
	at sun.nio.ch.FileChannelImpl.write(Unknown Source)
	at opendct.consumer.FFmpegSageTVConsumerImpl.writeBuffer(FFmpegSageTVConsumerImpl.java:707)
	at opendct.consumer.FFmpegSageTVConsumerImpl.access$900(FFmpegSageTVConsumerImpl.java:50)
	at opendct.consumer.FFmpegSageTVConsumerImpl$WriteCallback.call(FFmpegSageTVConsumerImpl.java:549)
	at org.bytedeco.javacpp.avformat.av_interleaved_write_frame(Native Method)
	at opendct.consumer.FFmpegSageTVConsumerImpl.remuxRtpPackets(FFmpegSageTVConsumerImpl.java:1067)
	at opendct.consumer.FFmpegSageTVConsumerImpl.run(FFmpegSageTVConsumerImpl.java:255)
	at java.lang.Thread.run(Unknown Source)

03:00:00.381 [FFmpegSageTVConsumerImpl-4308:DCT-HDHomeRun Prime Tuner 13191941-0] INFO  FFmpegSageTVConsumerImpl - Returning AVERROR_EOF in writeCallback.call()
03:00:00.381 [FFmpegSageTVConsumerImpl-4308:DCT-HDHomeRun Prime Tuner 13191941-0] ERROR FFmpegSageTVConsumerImpl - Error -541478725 while writing packet at input stream offset -1.
03:00:00.381 [FFmpegSageTVConsumerImpl-4308:DCT-HDHomeRun Prime Tuner 13191941-0] INFO  FFmpegSageTVConsumerImpl - FFmpeg consumer thread is stopping.
03:00:00.381 [FFmpegSageTVConsumerImpl-4308:DCT-HDHomeRun Prime Tuner 13191941-0] INFO  FFmpegSageTVConsumerImpl - FFmpeg consumer thread has stopped.

I've attached today's log for your review, even though I'm not seeing any issues so far.

Thanks for all of your recent work on this!

1) I'm still trying to track this one down. It's clearly returning data, but for some reason it's either badly formatted or OpenDCT doesn't currently have the logic to read it. It's odd and I don't see it happening on my setup. Currently that value isn't used for anything, it will be used to help focus detection in the future. So for now it's just a nuisance in the logs.

2) Don't worry about the exceptions when you stop a recording. They are mostly just interrupt messages. They are exceptions, but they are expected when the thread is being interrupted. They are just there for debugging purposes and only show up because DEBUG is enabled in logging. Also Returning AVERROR_EOF in writeCallback.call() will be seen pretty much every time you stop a recording because it tells FFmpeg essentially there's no more to read.

[jgsouthard]

I switched my 0.4.16 setup back to default properties and ran about 4-5 recordings this afternoon with no apparent problems, so I'm puzzled as to why I saw the issues this morning. If I run into more problems I'll try to make fewer and smaller changes in opendct.properties to better identify what is helping. But if I have a critical recording coming up that I don't want to lose, I tend to overreact and go back to settings that I know work.

But since 0.4.14 was totally unusable for me with the default properties, I think I can safely say that 0.4.16 is a significant improvement over 0.4.14.

[EnterNoEscape]

I know how you feel. I can be the same way. Anything to get it working, then figure it out later if I have time. My wife does not forgive bad recordings. Especially now that she knows that I am more than usual the person who is responsible to fix the cause. You can kind of see my preference in how many tunable parameters there are in OpenDCT. I think we have picked good defaults for most people, so 99% of tweaking is really just that and not a requirement.

I think I found the cause of your last no signal issue and fixed it. If it happens again, the worst thing you should get is a relatively short lived busy icon in the middle of the screen while OpenDCT re-connects to the device. That was my experience while I was randomly rebooting the Prime while it was in use. Fun fact: If the Prime is rebooted in the middle of a recording, OpenDCT will detect that it stalled after about 4-5 seconds, then re-tune and resume the recording. The total recovery process generally takes less than 10 seconds. If you want to try this out, start a few recordings that you don't care about, then reboot the Prime. (in your situation I would wait for the next beta before trying this though)

I think I figured out what was going on with /tuner0/program. If I'm right about that key, the Prime is returning "0" for 2 seconds straight and a measure in place to make sure we don't go past the end of the actual data prevented OpenDCT from reading a one character value. I figured this out after doing some math based on the size returned in your logs. That's unfortunate since we were really hoping that could be used as additional assurance that we have everything needed. However, what we are doing right now to detect streams looks like it's working really well for most people or they just aren't saying anything. I guess no other single character values have ever been returned and my provider always returns a program. When I look at the SageTV source code I have noticed a few times there is special code just because one particular provider does things just differently enough that it breaks a particular detection routine.

I'm just doing some testing right now to be extra sure that the improvements do what they are expected to do. Hopefully I'll have something for everyone tomorrow.

[jgsouthard]

Thanks!

[EnterNoEscape]

This release addresses some communication recovery issues when the HDHomeRun drops off the network or stops talking for any other reason. It also should completely fix 1 character responses.

This release also adds an extra recovery element to the current buffering. If the circular buffer overflows, the data that would otherwise be discarded, is now placed in a dynamically allocated queue that is allowed to grow up to 4 times the buffer size. This will help out mostly in situations when computer processing resources are consumed to the point that FFmpeg temporarily can't keep up with the live data. It should buy you over 10 seconds if no FFmpeg processing is possible or there is temporary hard drive congestion.

Like the previous beta, I would wait for feedback from the people who currently have issues before upgrading.

[jgsouthard]

Originally Posted by EnterNoEscape

This release addresses some communication recovery issues when the HDHomeRun drops off the network or stops talking for any other reason. It also should completely fix 1 character responses.

This release also adds an extra recovery element to the current buffering. If the circular buffer overflows, the data that would otherwise be discarded, is now placed in a dynamically allocated queue that is allowed to grow up to 4 times the buffer size. This will help out mostly in situations when computer processing resources are consumed to the point that FFmpeg temporarily can't keep up with the live data. It should buy you over 10 seconds if no FFmpeg processing is possible or there is temporary hard drive congestion.

Like the previous beta, I would wait for feedback from the people who currently have issues before upgrading.

In initial testing this morning, 0.4.17-Beta looks really good. I've run 10-12 recordings or partial recordings using default properties, including 6 at once, with no apparent hiccups. The logs look relatively clean as well. The only thing I saw that looked at all suspicious was one group of errors in wrapper.log:

INFO   | jvm 1    | 2016/01/21 08:34:20.939 | 08:34:20.923 [FFmpegSageTVConsumerImpl-592:DCT-HDHomeRun Prime Tuner 1319784E-1] WARN  ffmpeg - [mpegts @ 18211620] PES packet size mismatch
INFO   | jvm 1    | 2016/01/21 08:46:55.618 | 08:46:55.571 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR ffmpeg - [mpegts @ 18212c40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 4032367747 >= 4032364744
INFO   | jvm 1    | 2016/01/21 08:46:55.618 | 08:46:55.571 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR FFmpegSageTVConsumerImpl - Error -22 while writing packet at input stream offset -1.
INFO   | jvm 1    | 2016/01/21 08:46:55.618 | 08:46:55.571 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR ffmpeg - [mpegts @ 18212c40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 4032367747 >= 4032366245
INFO   | jvm 1    | 2016/01/21 08:46:55.618 | 08:46:55.571 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR FFmpegSageTVConsumerImpl - Error -22 while writing packet at input stream offset -1.
INFO   | jvm 1    | 2016/01/21 08:46:55.618 | 08:46:55.586 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR ffmpeg - [mpegts @ 18212c40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 4032367747 >= 4032367746
INFO   | jvm 1    | 2016/01/21 08:46:55.618 | 08:46:55.586 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR FFmpegSageTVConsumerImpl - Error -22 while writing packet at input stream offset -1.
INFO   | jvm 1    | 2016/01/21 08:46:56.727 | 08:46:56.680 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR ffmpeg - [mpegts @ 18212c40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 4032459338 >= 4032458587
INFO   | jvm 1    | 2016/01/21 08:46:56.727 | 08:46:56.680 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR FFmpegSageTVConsumerImpl - Error -22 while writing packet at input stream offset 3804930684.
INFO   | jvm 1    | 2016/01/21 08:46:56.837 | 08:46:56.821 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR ffmpeg - [mpegts @ 18212c40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 4032476605 >= 4032472852
INFO   | jvm 1    | 2016/01/21 08:46:56.837 | 08:46:56.821 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR FFmpegSageTVConsumerImpl - Error -22 while writing packet at input stream offset -1.
INFO   | jvm 1    | 2016/01/21 08:46:56.837 | 08:46:56.821 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR ffmpeg - [mpegts @ 18212c40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 4032476605 >= 4032474353
INFO   | jvm 1    | 2016/01/21 08:46:56.837 | 08:46:56.821 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR FFmpegSageTVConsumerImpl - Error -22 while writing packet at input stream offset -1.
INFO   | jvm 1    | 2016/01/21 08:46:56.837 | 08:46:56.821 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR ffmpeg - [mpegts @ 18212c40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 4032476605 >= 4032475854
INFO   | jvm 1    | 2016/01/21 08:46:56.837 | 08:46:56.821 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR FFmpegSageTVConsumerImpl - Error -22 while writing packet at input stream offset -1.
INFO   | jvm 1    | 2016/01/21 08:46:57.602 | 08:46:57.493 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR ffmpeg - [mpegts @ 18212c40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 4032547927 >= 4032544924
INFO   | jvm 1    | 2016/01/21 08:46:57.602 | 08:46:57.493 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR FFmpegSageTVConsumerImpl - Error -22 while writing packet at input stream offset -1.
INFO   | jvm 1    | 2016/01/21 08:46:57.602 | 08:46:57.493 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR ffmpeg - [mpegts @ 18212c40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 4032547927 >= 4032546425
INFO   | jvm 1    | 2016/01/21 08:46:57.602 | 08:46:57.493 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR FFmpegSageTVConsumerImpl - Error -22 while writing packet at input stream offset -1.
INFO   | jvm 1    | 2016/01/21 08:46:57.602 | 08:46:57.524 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR ffmpeg - [mpegts @ 18212c40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 4032547927 >= 4032547926
INFO   | jvm 1    | 2016/01/21 08:46:57.602 | 08:46:57.524 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR FFmpegSageTVConsumerImpl - Error -22 while writing packet at input stream offset -1.
INFO   | jvm 1    | 2016/01/21 08:49:12.815 | 08:49:12.799 [NIORTPProducerImpl-588:DCT-HDHomeRun Prime Tuner 1319784E-1] WARN  RTPPacketProcessor - Expected frame number 37845, received frame number 37846
INFO   | jvm 1    | 2016/01/21 08:49:13.034 | 08:49:12.940 [FFmpegSageTVConsumerImpl-592:DCT-HDHomeRun Prime Tuner 1319784E-1] WARN  ffmpeg - [mpegts @ 18211620] PES packet size mismatch

[EnterNoEscape]

Originally Posted by jgsouthard

In initial testing this morning, 0.4.17-Beta looks really good. I've run 10-12 recordings or partial recordings using default properties, including 6 at once, with no hiccups. The logs could relatively clean as well. The only thing I see that looks suspicious was one group of errors in wrapper.log like the following:

INFO   | jvm 1    | 2016/01/21 08:34:20.939 | 08:34:20.923 [FFmpegSageTVConsumerImpl-592:DCT-HDHomeRun Prime Tuner 1319784E-1] WARN  ffmpeg - [mpegts @ 18211620] PES packet size mismatch
INFO   | jvm 1    | 2016/01/21 08:46:55.618 | 08:46:55.571 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR ffmpeg - [mpegts @ 18212c40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 4032367747 >= 4032364744
INFO   | jvm 1    | 2016/01/21 08:46:55.618 | 08:46:55.571 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR FFmpegSageTVConsumerImpl - Error -22 while writing packet at input stream offset -1.
INFO   | jvm 1    | 2016/01/21 08:46:55.618 | 08:46:55.571 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR ffmpeg - [mpegts @ 18212c40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 4032367747 >= 4032366245
INFO   | jvm 1    | 2016/01/21 08:46:55.618 | 08:46:55.571 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR FFmpegSageTVConsumerImpl - Error -22 while writing packet at input stream offset -1.
INFO   | jvm 1    | 2016/01/21 08:46:55.618 | 08:46:55.586 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR ffmpeg - [mpegts @ 18212c40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 4032367747 >= 4032367746
INFO   | jvm 1    | 2016/01/21 08:46:55.618 | 08:46:55.586 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR FFmpegSageTVConsumerImpl - Error -22 while writing packet at input stream offset -1.
INFO   | jvm 1    | 2016/01/21 08:46:56.727 | 08:46:56.680 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR ffmpeg - [mpegts @ 18212c40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 4032459338 >= 4032458587
INFO   | jvm 1    | 2016/01/21 08:46:56.727 | 08:46:56.680 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR FFmpegSageTVConsumerImpl - Error -22 while writing packet at input stream offset 3804930684.
INFO   | jvm 1    | 2016/01/21 08:46:56.837 | 08:46:56.821 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR ffmpeg - [mpegts @ 18212c40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 4032476605 >= 4032472852
INFO   | jvm 1    | 2016/01/21 08:46:56.837 | 08:46:56.821 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR FFmpegSageTVConsumerImpl - Error -22 while writing packet at input stream offset -1.
INFO   | jvm 1    | 2016/01/21 08:46:56.837 | 08:46:56.821 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR ffmpeg - [mpegts @ 18212c40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 4032476605 >= 4032474353
INFO   | jvm 1    | 2016/01/21 08:46:56.837 | 08:46:56.821 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR FFmpegSageTVConsumerImpl - Error -22 while writing packet at input stream offset -1.
INFO   | jvm 1    | 2016/01/21 08:46:56.837 | 08:46:56.821 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR ffmpeg - [mpegts @ 18212c40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 4032476605 >= 4032475854
INFO   | jvm 1    | 2016/01/21 08:46:56.837 | 08:46:56.821 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR FFmpegSageTVConsumerImpl - Error -22 while writing packet at input stream offset -1.
INFO   | jvm 1    | 2016/01/21 08:46:57.602 | 08:46:57.493 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR ffmpeg - [mpegts @ 18212c40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 4032547927 >= 4032544924
INFO   | jvm 1    | 2016/01/21 08:46:57.602 | 08:46:57.493 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR FFmpegSageTVConsumerImpl - Error -22 while writing packet at input stream offset -1.
INFO   | jvm 1    | 2016/01/21 08:46:57.602 | 08:46:57.493 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR ffmpeg - [mpegts @ 18212c40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 4032547927 >= 4032546425
INFO   | jvm 1    | 2016/01/21 08:46:57.602 | 08:46:57.493 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR FFmpegSageTVConsumerImpl - Error -22 while writing packet at input stream offset -1.
INFO   | jvm 1    | 2016/01/21 08:46:57.602 | 08:46:57.524 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR ffmpeg - [mpegts @ 18212c40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 4032547927 >= 4032547926
INFO   | jvm 1    | 2016/01/21 08:46:57.602 | 08:46:57.524 [FFmpegSageTVConsumerImpl-1002:DCT-HDHomeRun Prime Tuner 1319784E-2] ERROR FFmpegSageTVConsumerImpl - Error -22 while writing packet at input stream offset -1.
INFO   | jvm 1    | 2016/01/21 08:49:12.815 | 08:49:12.799 [NIORTPProducerImpl-588:DCT-HDHomeRun Prime Tuner 1319784E-1] WARN  RTPPacketProcessor - Expected frame number 37845, received frame number 37846
INFO   | jvm 1    | 2016/01/21 08:49:13.034 | 08:49:12.940 [FFmpegSageTVConsumerImpl-592:DCT-HDHomeRun Prime Tuner 1319784E-1] WARN  ffmpeg - [mpegts @ 18211620] PES packet size mismatch

It's good to see you're finally heading somewhere pleasant. I was very concerned we might have a lot to work on when you were among some of the people saying that all the other software wasn't working for them. The error RTPPacketProcessor - Expected frame number 37845, received frame number 37846 looks like the server missed a single UDP packet. It's also likely there were other missed UDP packets before the dts errors. UDP is rather fickle; we only get one chance to get the packet. If the network interface is very busy with other traffic you'll start dropping packets. Also if the computer is lacking processing resources to at least buffer the packets as they come in, you're in trouble too. The only thing I can advise you on with this one is to try increasing the size of producer.rtp.nio.native_udp_receive_buffer=1328000. It looks like you only have a little bit of a problem, so I'd probably bump it up to 2-3MB, but I've seen people suggest 8MB+ receive buffer sizes as "recommended." Just keep in mind the end result does consume proportionally more RAM multiplied by each tuner. 1328000 was chosen because it's a multiple of the typical RTP packet size. That means that under normal conditions the OS will buffer up to 1000 packets per tuner for OpenDCT.

I should also note as I'm sure you've noticed, the log file is rotated daily, but it also rotates when it reaches 20MB in size or the service is restarted. They are archived using gzip so they take up a fairly small amount of space. Usually when you see things in wrapper.log that you don't see in opendct.log, it's because of one of those 3 reasons. Up to 30 days is retained by default. There is also a safety measure in place that will clean up log files if for some reason your free space on the same drive as the logs goes below 1GB which isn't likely going to be caused by OpenDCT in it's current logging mode, but you can't be too careful.