OpenDCT: An open source digital cable tuner.

[EnterNoEscape]

Originally Posted by jarredduq

Uploaded file to Google Drive: https://drive.google.com/file/d/0ByM...ew?usp=sharing

The raw video playback is terrible. I'll see if there's something that can be done, but usually that's not a good sign.

[jarredduq]

Originally Posted by EnterNoEscape

The raw video playback is terrible. I'll see if there's something that can be done, but usually that's not a good sign.

Yeah, I don't know what Comcast does to the stream... I'm hoping that when they move to h.264 that things improve. They are taking their sweet time in the Bay Area to do the conversion.

[EnterNoEscape]

Originally Posted by jarredduq

Yeah, I don't know what Comcast does to the stream... I'm hoping that when they move to h.264 that things improve. They are taking their sweet time in the Bay Area to do the conversion.

I ran it through VideoRedo, it reported all kind of problems and could not fix it satisfactorily. I ran it through FFmpeg and it reported a constant stream of corrupt packets with similar playback results. I ran it though a few variations of the filtering in OpenDCT and nothing was able to make it better.

Unfortunately this looks like the quality of the transport stream itself is very poor, which makes me think you may have a signal issue at least around the frequency band that Bravo happens to be on. I used to have something similar happen from time to time with Lifetime and Oxygen which wouldn't be a problem for me, but someone else in my house actually watches those channels. I didn't really do much about the problem because other frequencies came in so strong an amplifier might create a different problem and one day the problems just stopped happening inexplicably.

I know this probably isn't what you want to hear, but I would double-check all of your coax connections (make sure you don't have any new kinks) and if possible try connecting before any splitters to see if it makes any difference.

[MattHelm]

OK, I've been a long time browser of this thread, and have a question.

Can I use OpenDCT to handle both a Ceton InfiniTV (cable) and a ATSC HDHomeRun (OTA, Non-Prime) at the same time???

If so, is anyone doing this, and is there any special tricks. The HDHomeRun is on a separate Ethernet controller than the Ceton.

Just making sure before I mess with a (mostly) working system.

[KeithAbbott]

Originally Posted by MattHelm

Can I use OpenDCT to handle both a Ceton InfiniTV (cable) and a ATSC HDHomeRun (OTA, Non-Prime) at the same time???

This can be done within the SageTV server (server can talk with the HDHomeRun directly, and talks to the Ceton via OpenDCT). Not sure why you would want to attempt it all within OpenDCT...

[EnterNoEscape]

Originally Posted by MattHelm

OK, I've been a long time browser of this thread, and have a question.

Can I use OpenDCT to handle both a Ceton InfiniTV (cable) and a ATSC HDHomeRun (OTA, Non-Prime) at the same time???

If so, is anyone doing this, and is there any special tricks. The HDHomeRun is on a separate Ethernet controller than the Ceton.

Just making sure before I mess with a (mostly) working system.

If you use the latest beta, yes, all of those will be detected by default and are supported. I'll only note that channel scanning on InfiniTV devices will not return anything unless offline scanning is enabled which is a feature I may be removing and replacing with the "on demand" scanning that everyone is more accustomed to.

[EnterNoEscape]

Originally Posted by KeithAbbott

This can be done within the SageTV server (server can talk with the HDHomeRun directly, and talks to the Ceton via OpenDCT). Not sure why you would want to attempt it all within OpenDCT...

It has been echoed a few times, but one reason to use OpenDCT is because it will not lock the HDHomeRun tuners when they are not in use and can be configured to take the tuners away from another program in the event that it's needed for a recording. Many people are sharing their tuners between the HDHomeRun DVR software and SageTV since SageTV can't playback DRM'd content.

OpenDCT also will use http protocol when available which is much more reliable than RTP (the only option currently built into SageTV).

Another reason, unrelated to ATSC is that as long as you have at least one tuner with a CableCARD, OpenDCT will automatically map all of your available ClearQAM channels.

[EnterNoEscape]

Originally Posted by troll5501

Installed 0.4.42 this morning and no issues and no dts corrections so far today. I reverted back to the default GC and heap sizes for the first round of testing. GC is currently occurring every 5 to 10 seconds with two active recordings but it isn't causing any problems.

I thought I'd give you a little teaser. I ported the current circular buffer over to a directly allocated byte buffer for the future 0.5 and the results are very promising. CPU usage dropped to less than 1% on average with GC happening at a rate of just under a minute after growing from about 10MB to about 34MB for one recording. On 8 recordings CPU usage was around 8% and a GC happened about every 13 seconds.

Basically what's happening is that at least when using RTP, the data never actually enters the JVM (only pointers to the data) and is processed completely off heap. HTTP still initially comes in via a byte array, but I don't currently see any alternatives short of writing my own implementation. I didn't try this before because I thought allocating many contiguous 8MB buffers would create an initial tuning performance problem. On top of that, the stream is being split so a copy of the video stream is going into CCExtractor and it's still more efficient.

[troll5501]

Originally Posted by EnterNoEscape

I thought I'd give you a little teaser. I ported the current circular buffer over to a directly allocated byte buffer for the future 0.5 and the results are very promising. CPU usage dropped to less than 1% on average with GC happening at a rate of just under a minute after growing from about 10MB to about 34MB for one recording. On 8 recordings CPU usage was around 8% and a GC happened about every 13 seconds.

Basically what's happening is that at least when using RTP, the data never actually enters the JVM (only pointers to the data) and is processed completely off heap. HTTP still initially comes in via a byte array, but I don't currently see any alternatives short of writing my own implementation. I didn't try this before because I thought allocating many contiguous 8MB buffers would create an initial tuning performance problem. On top of that, the stream is being split so a copy of the video stream is going into CCExtractor and it's still more efficient.

That sounds great! Looking forward to trying it out when it's ready. I see that you also switched to allocateDirect for RTP in one of the recent 0.4 commits (not yet released).

Regarding RTP vs HTTP, I spent many hours and tried everything I could think of to eliminate the "PES packet size mismatch" errors that were occurring on a regular basis with HTTP...GC tuning, TCP tuning, BIOS C-state and power policy settings, more CPUs in the VM, NFS and storage buffering changes, etc with no luck.

What I began to realize is that most of the times when the PES errors occurred they would affect multiple tuners at the same time and would always result in a glitch of a few seconds in one or more of the recordings.

I finally reverted back to UDP by setting hdhr.allow_http_tuning=false and everything seems to work much better. I still see occasional PES errors but they are always around the start or end of commercials and do not cause any noticeable glitches, and I also have not seen multiple tuners report PES errors at the same time.

All of your comments since adding the HTTP functionality seem to indicate that it should be more reliable, so I'm not sure why I'm having so many issues with it. Based on netstat counters, I have not had a single dropped UDP packet or receive error in the last 30 hours and I've had one or more recordings active the entire time. The keys to my success with UDP are to max out the NIC driver receive buffers and also to increase net.core.rmem_max (I'm using 8388608) so that OpenDCT is able to set the socket receive buffer to the large value specified in opendct.properties (currently defaults to 5312000).

Here were the UDP counters (baseline) at the time I switched from HTTP to UDP yesterday:

Udp:
    944507 packets received
    1 packets to unknown port received.
    30 packet receive errors
    1847 packets sent
    0 receive buffer errors
    0 send buffer errors

And here are the counters now...so you can get an idea of the volume of packets processed:

Udp:
    215139726 packets received
    63 packets to unknown port received.
    30 packet receive errors
    4467 packets sent
    0 receive buffer errors
    0 send buffer errors

Regarding the heap size changes, the GC events are greatly reduced with the 128MB initial heap size although I still see some Full GC events on occasion and one in particular stopped all threads for 1.3 seconds according to the -XX:+PrintGCApplicationStoppedTime stats:

INFO   | jvm 1    | 2016/04/04 12:47:37.407 | [GC (Allocation Failure)  134442K->99674K(146944K), 0.0056798 secs]
INFO   | jvm 1    | 2016/04/04 12:47:37.407 | [Full GC (Ergonomics)
INFO   | jvm 1    | 2016/04/04 12:47:38.709 |  99674K->27856K(130560K), 1.3047619 secs]
INFO   | jvm 1    | 2016/04/04 12:47:38.709 |          vmop                    [threads: total initially_running wait_to_block]    [time: spin block sync cleanup vmop] page_trap_count
INFO   | jvm 1    | 2016/04/04 12:47:38.709 | 31836.887: ParallelGCFailedAllocation       [      39          0              0    ]      [     0     0     0    10  1310    ]  0
INFO   | jvm 1    | 2016/04/04 12:47:38.709 | Total time for which application threads were stopped: 1.3213746 seconds, Stopping threads took: 0.0000381 seconds

Since yesterday afternoon I have been testing the G1GC collector again. It doesn't appear to have performed any Full GC yet and in general is working quite well.

[troll5501]

I have a question about the logging of repeated messages. I'm not sure, but it appears that when the "Repeated" message is written to the logfile, the tuner name displayed is not necessarily the one that originally generated the messages, but is the one that is currently trying to write a new log entry and then detected that some previous repeated messages were already "queued" for display

For example, I think the Repeated entry at 22:00:00.550 by tuner "-0" is actually errors generated earlier by tuner "-1" (thread 0x7f31e803f480):

21:26:26.151 [FFmpegTransSageTVConsumerImpl-648:DCT-HDHomeRun Prime Tuner 13191941-1] WARN  mpegts - [0x7f31e803f480] PES packet size mismatch
22:00:00.550 [FFmpegTransSageTVConsumerImpl-267:DCT-HDHomeRun Prime Tuner 13191941-0] WARN  mpegts - Repeated [0x7f31e803f480] PES packet size mismatch time1: .
22:00:00.550 [FFmpegTransSageTVConsumerImpl-267:DCT-HDHomeRun Prime Tuner 13191941-0] WARN  mpegts - [0x7f31e8135260] PES packet size mismatch
22:00:01.929 [FFmpegTransSageTVConsumerImpl-1354:DCT-HDHomeRun Prime Tuner 13191941-0] ERROR mpeg2video - Repeated [0x7f31e8135260] PES packet size mismatch time1: .
22:19:54.336 [FFmpegTransSageTVConsumerImpl-648:DCT-HDHomeRun Prime Tuner 13191941-1] WARN  mpegts - [0x7f31e803f480] PES packet size mismatch
23:00:00.028 [FFmpegTransSageTVConsumerImpl-658:DCT-HDHomeRun Prime Tuner 13191941-2] WARN  mpegts - Repeated [0x7f31e803f480] PES packet size mismatch time2: s.
23:00:00.029 [FFmpegTransSageTVConsumerImpl-658:DCT-HDHomeRun Prime Tuner 13191941-2] WARN  mpegts - [0x7f31e84fde20] PES packet size mismatch
23:03:00.008 [FFmpegTransSageTVConsumerImpl-648:DCT-HDHomeRun Prime Tuner 13191941-1] WARN  mpegts - Repeated [0x7f31e84fde20] PES packet size mismatch time1: .
23:03:00.008 [FFmpegTransSageTVConsumerImpl-648:DCT-HDHomeRun Prime Tuner 13191941-1] WARN  mpegts - [0x7f31e803f480] PES packet size mismatch

I just want to make sure I'm understanding this correctly, because I've been watching these logs closely so I can correlate these errors to the correct tuners and timestamps.

[EnterNoEscape]

Originally Posted by troll5501

I have a question about the logging of repeated messages. I'm not sure, but it appears that when the "Repeated" message is written to the logfile, the tuner name displayed is not necessarily the one that originally generated the messages, but is the one that is currently trying to write a new log entry and then detected that some previous repeated messages were already "queued" for display

For example, I think the Repeated entry at 22:00:00.550 by tuner "-0" is actually errors generated earlier by tuner "-1" (thread 0x7f31e803f480):

21:26:26.151 [FFmpegTransSageTVConsumerImpl-648:DCT-HDHomeRun Prime Tuner 13191941-1] WARN  mpegts - [0x7f31e803f480] PES packet size mismatch
22:00:00.550 [FFmpegTransSageTVConsumerImpl-267:DCT-HDHomeRun Prime Tuner 13191941-0] WARN  mpegts - Repeated [0x7f31e803f480] PES packet size mismatch time1: .
22:00:00.550 [FFmpegTransSageTVConsumerImpl-267:DCT-HDHomeRun Prime Tuner 13191941-0] WARN  mpegts - [0x7f31e8135260] PES packet size mismatch
22:00:01.929 [FFmpegTransSageTVConsumerImpl-1354:DCT-HDHomeRun Prime Tuner 13191941-0] ERROR mpeg2video - Repeated [0x7f31e8135260] PES packet size mismatch time1: .
22:19:54.336 [FFmpegTransSageTVConsumerImpl-648:DCT-HDHomeRun Prime Tuner 13191941-1] WARN  mpegts - [0x7f31e803f480] PES packet size mismatch
23:00:00.028 [FFmpegTransSageTVConsumerImpl-658:DCT-HDHomeRun Prime Tuner 13191941-2] WARN  mpegts - Repeated [0x7f31e803f480] PES packet size mismatch time2: s.
23:00:00.029 [FFmpegTransSageTVConsumerImpl-658:DCT-HDHomeRun Prime Tuner 13191941-2] WARN  mpegts - [0x7f31e84fde20] PES packet size mismatch
23:03:00.008 [FFmpegTransSageTVConsumerImpl-648:DCT-HDHomeRun Prime Tuner 13191941-1] WARN  mpegts - Repeated [0x7f31e84fde20] PES packet size mismatch time1: .
23:03:00.008 [FFmpegTransSageTVConsumerImpl-648:DCT-HDHomeRun Prime Tuner 13191941-1] WARN  mpegts - [0x7f31e803f480] PES packet size mismatch

I just want to make sure I'm understanding this correctly, because I've been watching these logs closely so I can correlate these errors to the correct tuners and timestamps.

The logging is all done via one method that must be thread-safe. If you don't see Repeated prior to the message, the message directly correlates to that tuner. If you do see Repeated, then go by the hex address in brackets since any thread that comes back with a different entry than the last entry will print out that line. I should probably try to sort that out better, but I couldn't think of a good way to do it without creating the possibility of creating an object that might only be used for one tuning and never be freed.

As for the HTTP problems, my best guess is it's a real-time related issue or maybe even an issue with the current firmware. It's hard to say, but if RTP is working for you, I'd just stick with it. The video coming out is digital, so it's not like you're getting a completely different picture. HTTP has been much more reliable for myself, but as you have just demonstrated not everyone will have the same experience.

[EnterNoEscape]

Originally Posted by jarredduq

Yeah, I don't know what Comcast does to the stream... I'm hoping that when they move to h.264 that things improve. They are taking their sweet time in the Bay Area to do the conversion.

My conversation with troll5501 made me think of something that might have changed for you since the last version of OpenDCT you might have had installed. Try changing hdhr.allow_http_tuning to false.

[brandypuff]

Originally Posted by EnterNoEscape

can be configured to take the tuners away from another program in the event that it's needed for a recording.

How do I configure it to do such?

[jarredduq]

Originally Posted by EnterNoEscape

I ran it through VideoRedo, it reported all kind of problems and could not fix it satisfactorily. I ran it through FFmpeg and it reported a constant stream of corrupt packets with similar playback results. I ran it though a few variations of the filtering in OpenDCT and nothing was able to make it better.

Unfortunately this looks like the quality of the transport stream itself is very poor, which makes me think you may have a signal issue at least around the frequency band that Bravo happens to be on. I used to have something similar happen from time to time with Lifetime and Oxygen which wouldn't be a problem for me, but someone else in my house actually watches those channels. I didn't really do much about the problem because other frequencies came in so strong an amplifier might create a different problem and one day the problems just stopped happening inexplicably.

I know this probably isn't what you want to hear, but I would double-check all of your coax connections (make sure you don't have any new kinks) and if possible try connecting before any splitters to see if it makes any difference.

Signal strength: https://drive.google.com/file/d/0ByM...ew?usp=sharing in the past I had motorola booster, but it caused overload of signal. I was told by silicondust -10 or better is ideal. I dont watch bravo myself, but my wife does, so I know the moment there is an issue. :-)

[Greg2dot0]

Originally Posted by brandypuff

How do I configure it to do such?

from page 1 of this thread:

To enable forced unlocking, change the value of sagetv.device.<unique_id>.always_force_external_unlock to true for each device that you want this feature enabled on. The global setting no longer has any effect.

[cat6man]

hi there

i'm not sure if this is the right thread but i've recently created a new linux v9 server with opendct and a hdhd-prime. i'm getting warnings that the recording has stopped and will try to be restarted, sometimes 1 or 2 times per show recorded. it seems more common on non-clear channels, i think.
the recording directories show the recordings do pick up again and a new incremental *.ts file is created (so i end up with a glitch which is tolerable).

is this related to the problems you've been discussing here or is this something different? any suggestions?

[EnterNoEscape]

• Fixed incorrect variable order for repeat FFmpeg logging.
• Fixed pts being adjusted incorrectly under some circumstances.
• Socket server now doesn't try to register the loopback address for standby support.
• Changed over to using G1GC for garbage collection. Thanks troll5501 for your indirect suggestion to use this. It certainly makes a difference and this does seem to be the kind of application for which this implementation is intended.

With any luck, this will become the next stable version, so if I don't hear any significant issues with it from anyone by next week, I will move this to stable and start the next beta.

[EnterNoEscape]

Originally Posted by cat6man

hi there

i'm not sure if this is the right thread but i've recently created a new linux v9 server with opendct and a hdhd-prime. i'm getting warnings that the recording has stopped and will try to be restarted, sometimes 1 or 2 times per show recorded. it seems more common on non-clear channels, i think.
the recording directories show the recordings do pick up again and a new incremental *.ts file is created (so i end up with a glitch which is tolerable).

is this related to the problems you've been discussing here or is this something different? any suggestions?

It could be related. I'd need to see your log files. On the Linux install, you will find them under /var/log/opendct. I'm mostly interested in logs from when the glitches are happening, so if one didn't happen recently, you may need to take a look in the archive directory to find a log file containing the entries from when the issue happened.

[HelenWeathers]

Today my OpenDCT stopped abruptly shortly after startup with a Windows message I've never seen before.

10:56:36.977 [WrapperSimpleAppMain] INFO  Main - Starting OpenDCT 0.4.43...
10:56:37.040 [WrapperSimpleAppMain] DEBUG Config - OSVersion is parsing the name 'Windows 7'.
10:56:37.040 [WrapperSimpleAppMain] DEBUG Config - OSVersion determined that 'Windows 7' is WINDOWS.
10:56:37.118 [WrapperSimpleAppMain] INFO  Main - OpenDCT logging to the directory 'c:/ProgramData/OpenDCT/logs'.
10:56:37.133 [WrapperSimpleAppMain] INFO  UpnpManager - Logging Cling UPnP to 'c:/ProgramData/OpenDCT/logs\opendct_cling.log'.
10:56:37.133 [WrapperSimpleAppMain] DEBUG UpnpManager - Logging level for Cling UPnP is set to 'severe'.
10:56:37.133 [FFmpegAsyncInit-19] INFO  Main - FFmpeg loading...
10:56:37.743 [WindowsPowerMessagePump] INFO  WindowsPowerMessagePump - Message pump started.
10:56:42.083 [Shutdown] INFO  Main - OpenDCT has received a signal to stop.
10:56:42.083 [Shutdown] INFO  Main - Saving current configuration...
10:56:42.083 [PowerMessageManagerShutdown] INFO  Main - Stopping power messages...
10:56:42.083 [PowerMessageManagerShutdown] INFO  WindowsPowerMessagePump - Posting WM_QUIT message and waiting for message pump thread to exit.
10:56:42.113 [WindowsPowerMessagePump] INFO  WindowsPowerMessagePump - Message pump stopped.

Any ideas.

[EnterNoEscape]

Originally Posted by HelenWeathers

Today my OpenDCT stopped abruptly shortly after startup with a Windows message I've never seen before.

10:56:36.977 [WrapperSimpleAppMain] INFO  Main - Starting OpenDCT 0.4.43...
10:56:37.040 [WrapperSimpleAppMain] DEBUG Config - OSVersion is parsing the name 'Windows 7'.
10:56:37.040 [WrapperSimpleAppMain] DEBUG Config - OSVersion determined that 'Windows 7' is WINDOWS.
10:56:37.118 [WrapperSimpleAppMain] INFO  Main - OpenDCT logging to the directory 'c:/ProgramData/OpenDCT/logs'.
10:56:37.133 [WrapperSimpleAppMain] INFO  UpnpManager - Logging Cling UPnP to 'c:/ProgramData/OpenDCT/logs\opendct_cling.log'.
10:56:37.133 [WrapperSimpleAppMain] DEBUG UpnpManager - Logging level for Cling UPnP is set to 'severe'.
10:56:37.133 [FFmpegAsyncInit-19] INFO  Main - FFmpeg loading...
10:56:37.743 [WindowsPowerMessagePump] INFO  WindowsPowerMessagePump - Message pump started.
10:56:42.083 [Shutdown] INFO  Main - OpenDCT has received a signal to stop.
10:56:42.083 [Shutdown] INFO  Main - Saving current configuration...
10:56:42.083 [PowerMessageManagerShutdown] INFO  Main - Stopping power messages...
10:56:42.083 [PowerMessageManagerShutdown] INFO  WindowsPowerMessagePump - Posting WM_QUIT message and waiting for message pump thread to exit.
10:56:42.113 [WindowsPowerMessagePump] INFO  WindowsPowerMessagePump - Message pump stopped.

Any ideas.

Is that from wrapper.log? I'm not sure why it was told to stop, but it likely wasn't coming from within OpenDCT. When OpenDCT tells itself that it needs to stop or restart, it always posts a message to the log and directly to the console (which will be caught in wrapper.log regardless of the logging configuration) on why before it does it. The only exception would be a native error, but even that message ends up in wrapper.log.

It looks like it stopped just before or while it was detecting the available network adapters, but I don't see any logging in that regard or errors. The only thing that looks like it completely loaded was the Windows message pump which is used for detecting and handling standby. I can see that part correctly terminated, so it's unlikely to have been the cause.

If there aren't any stack traces in wrapper.log, it has the appearance that either JSW did something strange or JSW was told to stop by Windows.

Is the service currently refusing to start?