OpenDCT: An open source digital cable tuner.

[troll5501]

Originally Posted by HelenWeathers

I've run into an issue with OpenDCT. Not sure if you're equipped to test or not. Hope someone else may be able to try this also.

This only happens when recordings on my OTA tuners start while recordings on DCT tuners are in progress. This is with Sage 7 and win 7/32 with 4 OTA tuners and OpenDCT w HDHR Prine CC tuner. OpenDCT is running on the same machine (my Sage server). OpenDCT ver = OpenDCT_0.3.9_x86.

To test I set up 2 recordings on DCT tuners to start at ie 2PM and 4 recordings on OTA tuners starting at 2:05, 2:06, 2:07 and 2:08PM. All 6 recordings stopped at 2:15PM.

All 4 OTA recordings were glitch free but both DCT tuner recordings exibited 6-8 second glitches at 2:05, 2:06, 2:07 and 2:08 when the 4 OTA tuners kicked in.

I've been experiencing similar issues with 0.3.9 and 0.3.11 (the latest I've installed). What I've noticed is that any spike in CPU utilization, even very slight, will often cause a hiccup/glitch/pixelation in the recordings and at the same time OpenDCT will log ffpmeg warnings. I'm only testing with a single Prime, but I can often trigger this by starting a second or third recording, or stopping an existing recording. See my post #114 in this thread and let me know if you are seeing similar warnings in your opendct.log.

Usually the CPU spike comes from sagetv.exe but recently I discovered that just opening an RDP session to my SageTV server is enough to generate a short CPU spike which causes a burst of ffmpeg warnings from OpenDCT and pixelation in the recordings.

I've tried disabling hyperthreading, allocating more CPU cores, setting CPU affinity, switching from XP to Win7, etc. with no luck. Today I increased one of the OpenDCT buffer sizes based on a comment earlier in this thread, but I haven't had much time yet to do additional testing.

[EnterNoEscape]

Both of you should try turning off upload id. Stop the OpenDCT service, then change consumer.ffmpeg.upload_id_enabled to false, then start it back up again. I can't recommend anything other than the current "stable" build. The latest alpha appears to be ok in most regards, but we're still testing.


Update: Also if you can re-create the corruption problem and post your log, that would be the biggest help. I suspect the other possibility is that packets are getting dropped/out of order and we should be able to see that when the continuity counter logs that the packets are out of sequence.

[troll5501]

Originally Posted by EnterNoEscape

Both of you should try turning off upload id.

I already have it disabled but I'm still seeing these issues.

[HelenWeathers]

Here is a shortened log. Will do as you say. Hope the log helps.

[HelenWeathers]

Originally Posted by troll5501

I've been experiencing similar issues with 0.3.9 and 0.3.11 (the latest I've installed)......

I did look at your post. Issue results in similar symptoms but can't say for sure if cause is same or not. Above my pay grade.

[EnterNoEscape]

I think I know what the problem is and I already just saw it myself last night when a backup happened to kick off at the same time as a recording, it was constant, so my wife was really not happy with me. I had to recover some recordings using PlayOn. What appears to be happening is the incoming UDP packets are being temporarily paused long enough that OpenDCT is thinking that the tuner device has rebooted and re-tunes the channel trying to recover. This feature is triggered around 5 seconds of no data coming in. In the 0.4 versions it was reduced to 4 seconds which apparently was a bad idea (only 3 people plus me are using that version). Just tonight I made the value adjustable for myself and even at 15 seconds under the right conditions it was still re-tuning. I now have it at 60 seconds and it's harder, but I can still create issues. I've never had a rebooting problem, so high values don't really have me concerned. There's also a timeout on the port itself too and that's not triggering, so something must be inconsistent with the values coming back to the tuner monitoring thread. I'm going to take a look at why that only fails to work correctly sometimes tonight and hopefully have a fix by tomorrow. It's odd that more people haven't seen this, but I guess it needs the right conditions.

Update: I believe I have a fix. I'll let it run over night and check on things in the morning. So far things are looking very good.

Update #2: This issue is significant enough that I back-ported it since many people may have it and don't even know yet. The new latest stable version of OpenDCT is now v0.3.16-Stable. For the two people who have been experiencing this issue, you will want to upgrade immediately and make sure this is working correctly now.

[HelenWeathers]

Originally Posted by EnterNoEscape

......This issue is significant enough that I back-ported it since many people may have it and don't even know yet. The new latest stable version of OpenDCT is now v0.3.16-Stable. For the two people who have been experiencing this issue, you will want to upgrade immediately and make sure this is working correctly now.

I'll download 0.3.16 when I get home today, take it for a spin and let you know how it goes.

[HelenWeathers]

Same thing continues to happen. Log attached.

Not a hugh issue to me - TAKE YOUR TIME ON THIS!!

[troll5501]

Originally Posted by EnterNoEscape

What appears to be happening is the incoming UDP packets are being temporarily paused long enough that OpenDCT is thinking that the tuner device has rebooted and re-tunes the channel trying to recover.

Maybe I'm facing a different issue than what you experienced, because there is not a complete break in the recording but there is corruption. I installed 0.3.16 and did a few tests. Here are two occurances. For each of these, I could see some pixelation at these exact moments in the recordings.

With 3 recordings active, I started an RDP session to the SageTV/OpenDCT server at 14:15:39 and immediately got this:

14:15:39.651 [NIORTPProducerImpl-115:DCT-HDHomeRun Prime Tuner 13191941-2] WARN  RTPPacketProcessor - Expected frame number 45591, received frame number 45603
14:15:39.651 [NIORTPProducerImpl-78:DCT-HDHomeRun Prime Tuner 13191941-1] WARN  RTPPacketProcessor - Expected frame number 19686, received frame number 19689
14:15:39.651 [NIORTPProducerImpl-98:DCT-HDHomeRun Prime Tuner 13191941-0] WARN  RTPPacketProcessor - Expected frame number 43967, received frame number 43978
14:15:39.651 [FFmpegSageTVConsumerImpl-108:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG ffmpeg - [mpegts @ 060fb020] Continuity check failed for pid 4283 expected 4 got 10
14:15:39.651 [FFmpegSageTVConsumerImpl-108:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG ffmpeg - [mpegts @ 060fb020] Continuity check failed for pid 4284 expected 2 got 4
14:15:39.666 [FFmpegSageTVConsumerImpl-88:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG ffmpeg - [mpegts @ 05b79ae0] Continuity check failed for pid 4490 expected 12 got 15
14:15:39.666 [FFmpegSageTVConsumerImpl-108:DCT-HDHomeRun Prime Tuner 13191941-0] WARN  ffmpeg - [mpegts @ 060fb020] PES packet size mismatch
14:15:39.666 [FFmpegSageTVConsumerImpl-125:DCT-HDHomeRun Prime Tuner 13191941-2] DEBUG ffmpeg - [mpegts @ 060e9600] Continuity check failed for pid 6920 expected 9 got 13
14:15:39.666 [FFmpegSageTVConsumerImpl-88:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG ffmpeg - [mpegts @ 05b79ae0] Continuity check failed for pid 4491 expected 5 got 7
14:15:39.698 [FFmpegSageTVConsumerImpl-88:DCT-HDHomeRun Prime Tuner 13191941-1] WARN  ffmpeg - [mpegts @ 05b79ae0] PES packet size mismatch

At 14:28:39, I stopped one of the recordings:

14:28:39.411 [NIORTPProducerImpl-115:DCT-HDHomeRun Prime Tuner 13191941-2] WARN  RTPPacketProcessor - Expected frame number 5992, received frame number 6036
14:28:39.411 [NIORTPProducerImpl-98:DCT-HDHomeRun Prime Tuner 13191941-0] WARN  RTPPacketProcessor - Expected frame number 45890, received frame number 45913
14:28:39.411 [NIORTPProducerImpl-78:DCT-HDHomeRun Prime Tuner 13191941-1] WARN  RTPPacketProcessor - Expected frame number 52519, received frame number 52582
14:28:39.411 [FFmpegSageTVConsumerImpl-108:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG ffmpeg - [mpegts @ 060fb020] Continuity check failed for pid 4283 expected 2 got 1
14:28:39.411 [FFmpegSageTVConsumerImpl-108:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG ffmpeg - [mpegts @ 060fb020] Continuity check failed for pid 4284 expected 3 got 15
14:28:39.426 [FFmpegSageTVConsumerImpl-88:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG ffmpeg - [mpegts @ 05b79ae0] Continuity check failed for pid 4491 expected 2 got 11
14:28:39.442 [FFmpegSageTVConsumerImpl-125:DCT-HDHomeRun Prime Tuner 13191941-2] DEBUG ffmpeg - [mpegts @ 060e9600] Continuity check failed for pid 6920 expected 13 got 15
14:28:39.442 [FFmpegSageTVConsumerImpl-125:DCT-HDHomeRun Prime Tuner 13191941-2] DEBUG ffmpeg - [mpegts @ 060e9600] Continuity check failed for pid 6921 expected 12 got 14
14:28:39.442 [FFmpegSageTVConsumerImpl-108:DCT-HDHomeRun Prime Tuner 13191941-0] WARN  ffmpeg - [mpegts @ 060fb020] PES packet size mismatch
14:28:39.473 [FFmpegSageTVConsumerImpl-125:DCT-HDHomeRun Prime Tuner 13191941-2] WARN  ffmpeg - [mpegts @ 060e9600] PES packet size mismatch
14:28:39.520 [FFmpegSageTVConsumerImpl-108:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG ffmpeg - [mpegts @ 060fb020] Continuity check failed for pid 71 expected 0 got 1
14:28:39.520 [FFmpegSageTVConsumerImpl-88:DCT-HDHomeRun Prime Tuner 13191941-1] WARN  ffmpeg - [mpegts @ 05b79ae0] PES packet size mismatch
14:28:39.536 [SageTVRequestHandler-241:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG SageTVRequestHandler - SageTV sent: 'STOP DCT-HDHomeRun Prime Tuner 13191941-1 Digital TV Tuner'
14:28:39.536 [SageTVRequestHandler-241:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG DCTCaptureDeviceImpl - Stopping encoding...
14:28:39.536 [SageTVRequestHandler-241:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG RTPCaptureDevice - Stopping producer thread...
14:28:39.536 [SageTVRequestHandler-241:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG RTPCaptureDevice - Waiting for producer thread to stop...
14:28:39.536 [NIORTPProducerImpl-78:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG NIORTPProducerImpl - Producer was closed by an asynchronous close exception => 
java.nio.channels.AsynchronousCloseException
	at java.nio.channels.spi.AbstractInterruptibleChannel.end(Unknown Source) ~[?:1.7.0_91]
	at sun.nio.ch.DatagramChannelImpl.receive(Unknown Source) ~[?:1.7.0_91]
	at opendct.producer.NIORTPProducerImpl.run(NIORTPProducerImpl.java:253) [opendct-0.3.16.jar:?]
	at java.lang.Thread.run(Unknown Source) [?:1.7.0_91]
14:28:39.551 [NIORTPProducerImpl-78:DCT-HDHomeRun Prime Tuner 13191941-1] INFO  NIORTPProducerImpl - Producer thread has disconnected.
14:28:39.551 [PacketsMonitor-80:NIORTPProducerImpl-78:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG NIORTPProducerImpl - The packet monitoring thread has been interrupted.
14:28:39.551 [NIORTPProducerImpl-78:DCT-HDHomeRun Prime Tuner 13191941-1] INFO  NIORTPProducerImpl - Producer thread has stopped.
14:28:39.551 [PacketsMonitor-80:NIORTPProducerImpl-78:DCT-HDHomeRun Prime Tuner 13191941-1] INFO  NIORTPProducerImpl - Producer packet monitoring thread has stopped.
14:28:39.551 [SageTVRequestHandler-241:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG BasicCaptureDevice - Stopping consumer thread...
14:28:39.551 [SageTVRequestHandler-241:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG BasicCaptureDevice - Waiting for consumer thread to stop...
14:28:39.551 [FFmpegSageTVConsumerImpl-88:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG FFmpegSageTVConsumerImpl - Consumer created an IO exception => 
java.nio.channels.ClosedByInterruptException
	at java.nio.channels.spi.AbstractInterruptibleChannel.end(Unknown Source) ~[?:1.7.0_91]
	at sun.nio.ch.FileChannelImpl.write(Unknown Source) ~[?:1.7.0_91]
	at opendct.consumer.FFmpegSageTVConsumerImpl.writeBuffer(FFmpegSageTVConsumerImpl.java:701) [opendct-0.3.16.jar:?]
	at opendct.consumer.FFmpegSageTVConsumerImpl.access$900(FFmpegSageTVConsumerImpl.java:50) [opendct-0.3.16.jar:?]
	at opendct.consumer.FFmpegSageTVConsumerImpl$WriteCallback.call(FFmpegSageTVConsumerImpl.java:543) [opendct-0.3.16.jar:?]
	at org.bytedeco.javacpp.avformat.av_interleaved_write_frame(Native Method) ~[ffmpeg-2.8.1-1.1.jar:1.1]
	at opendct.consumer.FFmpegSageTVConsumerImpl.remuxRtpPackets(FFmpegSageTVConsumerImpl.java:1057) [opendct-0.3.16.jar:?]
	at opendct.consumer.FFmpegSageTVConsumerImpl.run(FFmpegSageTVConsumerImpl.java:249) [opendct-0.3.16.jar:?]
	at java.lang.Thread.run(Unknown Source) [?:1.7.0_91]
14:28:39.551 [FFmpegSageTVConsumerImpl-88:DCT-HDHomeRun Prime Tuner 13191941-1] INFO  FFmpegSageTVConsumerImpl - Returning AVERROR_EOF in writeCallback.call()
14:28:39.551 [FFmpegSageTVConsumerImpl-88:DCT-HDHomeRun Prime Tuner 13191941-1] ERROR FFmpegSageTVConsumerImpl - Error -541478725 while writing packet at input stream offset -1.
14:28:39.551 [FFmpegSageTVConsumerImpl-88:DCT-HDHomeRun Prime Tuner 13191941-1] INFO  FFmpegSageTVConsumerImpl - FFmpeg consumer thread is stopping.
14:28:39.551 [FFmpegSageTVConsumerImpl-88:DCT-HDHomeRun Prime Tuner 13191941-1] INFO  FFmpegSageTVConsumerImpl - FFmpeg consumer thread has stopped.
14:28:39.551 [SageTVRequestHandler-241:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG HDHomeRunManager - key: '/tuner1/vchannel' value: 'none' lockKey: '1062674822' remaining: 40
14:28:39.551 [SageTVRequestHandler-241:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG HDHomeRunManager - key: '/tuner1/target' value: 'none' lockKey: '1062674822' remaining: 38
14:28:39.551 [SageTVRequestHandler-241:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG HDHomeRunManager - key: '/tuner1/lockkey' value: 'null' lockKey: '0' remaining: 26
14:28:39.551 [SageTVRequestHandler-241:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG HDHomeRunManager - key: '/tuner1/lockkey' value: 'none' lockKey: '1062674822' remaining: 39
14:28:39.551 [SageTVRequestHandler-241:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG HDHomeRunManager - key: '/tuner1/lockkey' value: 'null' lockKey: '0' remaining: 26
14:28:39.551 [SageTVRequestHandler-241:DCT-HDHomeRun Prime Tuner 13191941-1] INFO  DCTCaptureDeviceImpl - HDHomeRun is now unlocked.
14:28:39.551 [SageTVRequestHandler-241:DCT-HDHomeRun Prime Tuner 13191941-1] INFO  DCTCaptureDeviceImpl - Stopped encoding.
14:28:39.551 [SageTVRequestHandler-241:DCT-HDHomeRun Prime Tuner 13191941-1] INFO  DCTCaptureDeviceImpl - Capture device is now unlocked.
14:28:39.551 [SageTVRequestHandler-241:DCT-HDHomeRun Prime Tuner 13191941-1] DEBUG SageTVRequestHandler - Replied: 'OK
'
14:28:39.583 [FFmpegSageTVConsumerImpl-108:DCT-HDHomeRun Prime Tuner 13191941-0] DEBUG ffmpeg - [mpegts @ 060fb020] Continuity check failed for pid 0 expected 5 got 6

[HelenWeathers]

Yes. It seems in my issue when Sage triggers the tuner on an OTA tuner the HDHRPrime stream is killed. It takes 4 or 5 secs for DCT to realise this has happened and about 3 secs to recover and begin producing stream again.

[EnterNoEscape]

Originally Posted by troll5501

Maybe I'm facing a different issue than what you experienced, because there is not a complete break in the recording but there is corruption. I installed 0.3.16 and did a few tests. Here are two occurances. For each of these, I could see some pixelation at these exact moments in the recordings.

It looks like you're actually missing many UDP packets when you remote in. That's more out of my control. You can try increasing the the value of producer.nio.udp_receive_buffer significantly to try to counteract the effects. Unfortunately UDP does not have any means to recover missed packets, so once you're computer has decided to drop them, they are gone for good.

[Telecore]

Tried to get alpha 0.4.8 running on my main SageTV server (win7 x64, V7) but video sources not showing up, although looks like discovery occurs in the log files (attached) - any ideas? Have Java 6 and 7 installed (32 bit for SageTV) and latest Java 8 64 bit for OpenDCT. Also testing on my Win10/V9 system and will update you on that. Thanks in advance.

[EnterNoEscape]

Originally Posted by HelenWeathers

Yes. It seems in my issue when Sage triggers the tuner on an OTA tuner the HDHRPrime stream is killed. It takes 4 or 5 secs for DCT to realise this has happened and about 3 secs to recover and begin producing stream again.

All of my recordings finished last night without issue which is why I posted the updated version. This problem was rather severe in my opinion and very sneaky.

I'm not sure what killed means in this context. Are you saying the stream recovers without any errors in the stream after 3 seconds have passed? For example, if you skipped back 5 seconds before the pause happened and then watch 10 seconds of the recording from that point is the playback completely smooth? I would expect the pause to happen if there was something significant going on, but the actual recording should be fully intact and catch back up to the live stream quickly after the usage spike passed.

If that's not what's happening, I would like to get another log from you so we can try to figure out what else is going on. Also you could try increasing the time required for a "stall" to be detected by increasing the value of producer.rtp.nio.stalled_timeout_s. If you put it up to something like 30 seconds, and then it stalls for 30 seconds, that would make me think SageTV is unintentionally messing with the tuner.

[EnterNoEscape]

Originally Posted by Telecore

Tried to get alpha 0.4.8 running on my main SageTV server (win7 x64, V7) but video sources not showing up, although looks like discovery occurs in the log files (attached) - any ideas? Have Java 6 and 7 installed (32 bit for SageTV) and latest Java 8 64 bit for OpenDCT. Also testing on my Win10/V9 system and will update you on that. Thanks in advance.

I don't any any hints for you on this one. Can you post Sage.properties and opendct.properties? Also can you confirm that 192.168.2.191 the IP address of the Win7 v7 server?

[Telecore]

192.168.2.191 is the SageTV server. Files are attached. Trying to get OpenDCT working here because of SageDCT re-tuning issue - video disappears at the top of the hour or 1/2 hour when watching live tv when the program changes. Not sure why this started. OpenDCT seems good on Win10 PC and tunes faster. Also, cannot get SageDCT ffmpeg working on this pc, either, so OpenDCT would have advantage of ffmpeg cleanup. Thanks!

[HelenWeathers]

Originally Posted by EnterNoEscape

......I'm not sure what killed means in this context..

There's an 8 sec forward jump in playback of the DCT recordings each time this occurs. The timeline jumps from ie 01:00 to 01:08. If I do a skip back immediately I am taken back to a sec or so before the break and the progress bar & timeline then jump ahead immediately to just after the break. I'll do another test after recording time tonight and open the DTC recording in VideoRedo to take a look at the frames produced if they are there.

SageTV doesn't break the recording into pieces (-0, -1 etc).

In which file and which folder do I find the producer.rtp.nio.stalled_timeout_s setting?

[EnterNoEscape]

Originally Posted by HelenWeathers

There's an 8 sec forward jump in playback of the DCT recordings each time this occurs. The timeline jumps from ie 01:00 to 01:08. If I do a skip back immediately I am taken back to a sec or so before the break and the progress bar & timeline then jump ahead immediately to just after the break. I'll do another test after recording time tonight and open the DTC recording in VideoRedo to take a look at the frames produced if they are there.

SageTV doesn't break the recording into pieces (-0, -1 etc).

In which file and which folder do I find the producer.rtp.nio.stalled_timeout_s setting?

Sorry, I should have mentioned that. There's a shortcut on the Start Menu to OpenDCT Properties. The property is in that file.

[EnterNoEscape]

Originally Posted by Telecore

192.168.2.191 is the SageTV server. Files are attached. Trying to get OpenDCT working here because of SageDCT re-tuning issue - video disappears at the top of the hour or 1/2 hour when watching live tv when the program changes. Not sure why this started. OpenDCT seems good on Win10 PC and tunes faster. Also, cannot get SageDCT ffmpeg working on this pc, either, so OpenDCT would have advantage of ffmpeg cleanup. Thanks!

It's not you, it's me. We made some logging adjustments in the latest version to get rid of some nuisances and it looks like I introduced a little bit of delay when SageTV is getting PROPERTIES. It's very sensitive to this; it basically just stopped accepting data right in the middle. I'll need to mess around with it a little, but I can't imagine this will take long to fix.

Update: Just so everyone knows, this issue only effects people using the 0.4 versions, not the 0.3 versions that most people should be using right now.

[EnterNoEscape]

There were a few questions about standby support and I updated the first post on this thread to include that information which is also updated on GibHub and I have clarified why you would care about these properties. When OpenDCT goes into standby, it will unload all capture devices before Windows enters standby. When Windows comes out of standby, it waits for all network interfaces to start communicating again, then immediately re-opens all of the ports for communication with SageTV. Then it re-discovers the capture devices. The re-discovery process can take long enough that SageTV has requested a device that is not available in OpenDCT at the moment. By telling OpenDCT how many capture devices you expect it to have, it knows that when that request comes in and the device isn't available that it needs to wait longer. The instant we reach the number of required capture devices, all pending requests are processed.

The reason for the count instead of automatically determining the number of devices is it will not work for initial startup and if the computer went into standby before everything was detected, it would have an incorrect assumption on return from standby. Also since you can require or ignore devices based on per capture device or per parent, the count can't be derived from that list either, so a number is the easiest way to address this. The web interface implementation is already much more elegant and does not require you to know much about any properties you've seen here because it takes care of them for you when you explicitly add a detected capture device (not all that different from SageTV). So if you find this annoying, sometime this year it will no longer be a consideration.

• sagetv.device.global.required_devices_loaded_timeout_ms=30000

  This is the amount of time allowed in milliseconds to pass while waiting for the required number of devices before the program will exit with a failure. If you are running as a service, the program will actually restart with the assumption that something must have gone wrong. This timeout will only happen if sagetv.device.global.required_devices_loaded_count is higher than 0.

• sagetv.device.global.required_devices_loaded_count=0

  This is the number of devices that need to be detected and loaded before the required timeout. This must be the total number of devices OpenDCT normally detects and loads for standby support to work correctly. If this value is left at zero, OpenDCT will just return failures to SageTV when it asks for a device that has not been detected yet because it has no way to know if it should have that device or not. If you are not using standby changing this parameter will also help at startup because it will make OpenDCT hang onto any tuning requests from SageTV until all of the devices have been loaded.

[HelenWeathers]

I changed producer.rtp.nio.stalled_timeout_s=5 to producer.rtp.nio.stalled_timeout_s=30. Started OpenDCT, waited 15 sec & started SageTV service.

Sage now gives me a > 30 second jump ahead in time line for both DCT recordings each time an OTA recording is started.

With WMPlayer when I hit the first of these spots it plays thru it but on the second occurance the video just freezes. In VideoRedo using frame advance, when I hit the segment VR freezes.

I've attached OpenDCT & Sage logs below.

In normal use I never saw this issue until one night I was recording two sports events on ESPN & ESPN2 and happened to have 3 OTA recordings triggered at 9:59PM, 10:00PM and 10:01PM. That's when I decided to set up my test.

A rare event, though.