OpenDCT: An open source digital cable tuner.

[peternm22]

Originally Posted by makutaku

I am still figuring out how to make some of the suggested changes "stick" and be applied without reverting back

You need to stop the OpenDCT service to make changes to the properties file. If you're using Windows, there should be a shortcut in your start menu that says "OpenDCT Stop Service". Run that, and then make your changes.

Once you have saved your charges, run "OpenDCT Start Service".

[EnterNoEscape]

Originally Posted by makutaku

I am having trouble understanding how OpenDCT property file(s) work.

Could you please let us know the purpose of these files:

opendct.properties.default
opendct.properties.upgrade-0


And more importantly, why does opendct.properties keep getting regenerated ?

For those familiar with SageTV property file, this is somewhat not intuitive: I am still figuring out how to make some of the suggested changes "stick" and be applied without reverting back

opendct.properties is the only file you need to worry about. Similar to SageTV, you always need to stop the service before you can make any changes or they will be overwritten.

Those other files are created when you install new versions of OpenDCT as a backup of your configuration prior to the upgrade. opendct.properties.default is just a template of the defaults for anyone that wants to configure settings prior to just running OpenDCT for the first time. Running OpenDCT will generate a similar file with lots more entries that are specific to your computer.

[waylo]

Can you confirm my recollection here... To get a properties.default file, we simply delete our existing opendct.properties file and run OpenDCT?

[EnterNoEscape]

Originally Posted by waylo

Can you confirm my recollection here... To get a properties.default file, we simply delete our existing opendct.properties file and run OpenDCT?

opendct.properties.default is a new thing. It's a part of the installation on Linux and actually isn't really needed at all since OpenDCT since the very first version always persisted properties on their first use similar to SageTV. It's really just there for the few people that want to configure something ahead of time. If you were to do that, you need to copy opendct.properties.default to opendct.properties. In Linux that's a very common thing to do, so I didn't really put a lot of explanation in there other than just making a note of it in the release notes. If you want to reset everything to defaults the easiest way is to delete opendct.properties. You can ignore opendct.properties.default completely, but do not delete it. It could make the installer angry.

[panteragstk]

Originally Posted by EnterNoEscape

It's definitely not keeping up. Sometimes when transcoding at first there is a brief backlog of data that gets sorted out in less than a minute. In your case it falls behind and keeps falling further and behind. Below are a few telling log entries.

12:05:10.700 [NIOHTTPProducerImpl-124:HDHomeRun HDHR4-2US Tuner 1043DBF9-0] WARN  SeekableCircularBufferNIO - The buffer has 7863256 bytes left to be read, has only 1065 bytes left for writing and 1316 bytes cannot be added. Deferring bytes to queue buffer.
12:05:58.297 [FFmpegTransSageTVConsumerImpl-126:HDHomeRun HDHR4-2US Tuner 1043DBF9-0] DEBUG FFmpegTranscoder - FPS: 27.77777777777778
12:06:40.378 [FFmpegTransSageTVConsumerImpl-126:HDHomeRun HDHR4-2US Tuner 1043DBF9-0] DEBUG FFmpegTranscoder - FPS: 23.80952380952381

I have an i5-3570K that can keep up with things for up to 3 streams, so I know it's not impossible to use this feature on modern hardware. Somewhere down the road I think I'm going to take Fuzzy's suggestion to just use the normal FFmpeg binary for transcoding because it will multi-thread this a lot better (which might help your situation) and make supporting platform specific hardware acceleration a lot easier too.

Ok. I've got dual Xeon E5-2670's so I'd think they'd be able to keep up. Oddly, in recordings the files seem to be perfect.

Are here any settings I can change to help things out?

[EnterNoEscape]

Originally Posted by panteragstk

Ok. I've got dual Xeon E5-2670's so I'd think they'd be able to keep up. Oddly, in recordings the files seem to be perfect.

Are here any settings I can change to help things out?

Not really, because what I'm saying is that the single core speed isn't high enough. You can see how the framerate goes from almost keeping up to falling behind. I suspect at first it's using turbo boost, then that wears off leaving you at 2.6GHz. With all of the errors I was seeing about the packets being broken, I'm surprised that the files are fine after being recorded. If you're saying your only issue is live playback, then the only suggestion I can give you is to stay a little further back from live.

[panteragstk]

Originally Posted by EnterNoEscape

Not really, because what I'm saying is that the single core speed isn't high enough. You can see how the framerate goes from almost keeping up to falling behind. I suspect at first it's using turbo boost, then that wears off leaving you at 2.6GHz. With all of the errors I was seeing about the packets being broken, I'm surprised that the files are fine after being recorded. If you're saying your only issue is live playback, then the only suggestion I can give you is to stay a little further back from live.

Ok. So clock speed is important with this, not amount of cores. I may not be able to use it after all.

I may try to see if I can offload it to my desktop that is at 4.5ghz, but I'm going to have to think about that.

EDIT: Tried that, didn't work at all. Not sure why. Would adding more threads to the docker help things?

[EnterNoEscape]

Originally Posted by panteragstk

Ok. So clock speed is important with this, not amount of cores. I may not be able to use it after all.

I may try to see if I can offload it to my desktop that is at 4.5ghz, but I'm going to have to think about that.

EDIT: Tried that, didn't work at all. Not sure why. Would adding more threads to the docker help things?

I don't know how well this scales, but you can try telling x264 to use more threads. In the encode profile you can change these values:

# Two threads is more than enough for one transcoding. Reasons to not use more threads:
# 1) If more than one transcoding is being performed at the same time, the CPU cache hits will
# decrease as all of the cores are intensely working simultaneously on very different content.
# 2) The more cores involved, the longer it actually takes before the first frame is written and
# for the last frame to be written.
# 3) The decoding and filtering are all currently done on one thread and will potentially limit the
# scalability.
v.e.default.h264.dict.threads=2
v.e.default.h264.dict.lookahead_threads=1
v.e.default.h264.dict.sliced_threads=0

Perhaps my comment was a little too optimistic. I should also mention that the processor definitely matters as much as the clock speed. I have a 3.4GHz Phenom II and it doesn't do a very good job.

[panteragstk]

Originally Posted by EnterNoEscape

I don't know how well this scales, but you can try telling x264 to use more threads. In the encode profile you can change these values:

# Two threads is more than enough for one transcoding. Reasons to not use more threads:
# 1) If more than one transcoding is being performed at the same time, the CPU cache hits will
# decrease as all of the cores are intensely working simultaneously on very different content.
# 2) The more cores involved, the longer it actually takes before the first frame is written and
# for the last frame to be written.
# 3) The decoding and filtering are all currently done on one thread and will potentially limit the
# scalability.
v.e.default.h264.dict.threads=2
v.e.default.h264.dict.lookahead_threads=1
v.e.default.h264.dict.sliced_threads=0

Perhaps my comment was a little too optimistic. I should also mention that the processor definitely matters as much as the clock speed. I have a 3.4GHz Phenom II and it doesn't do a very good job.

I'll play around with it. I did speak too soon about the recordings being good...they are not.

I'm still excited that this even exists. Very impressed with the work you've done on this. And other things of course.

[panteragstk]

Well, it looks like increasing the thread count solved everything. CPU usage didn't go up, but performance looks to be silky smooth.

Pretty excited.

[EnterNoEscape]

Originally Posted by panteragstk

Well, it looks like increasing the thread count solved everything. CPU usage didn't go up, but performance looks to be silky smooth.

Pretty excited.

Cool. I had all but forgotten about those settings. I wrote those profiles about a year ago. There's a lot of settings you can play with in them. The dict settings are actually codec specific parameters, so there are definitely even more options than what's already in the profile. I just put references into the profiles for anything I thought might interest someone. I tuned them for performance and quality at the expense of file size since the original goal was to just get the stream re-encoded and keep it looking as good as the original.

[crarbo1]

Originally Posted by panteragstk

Well, it looks like increasing the thread count solved everything. CPU usage didn't go up, but performance looks to be silky smooth.

Pretty excited.

Do you mind posting what settings worked for you? I'm hope to experiment this weekend with transcoding with OpenDCT and would like all the help I can get it to working.

Thanks,
Chuck

[smak]

Originally Posted by panteragstk

Well, it looks like increasing the thread count solved everything. CPU usage didn't go up, but performance looks to be silky smooth.

Pretty excited.

I am interested in your settings as well

I have been doing some transcoding but am interested in going to a different container. I have not cracked the code on that setting yet.

Thanks!

[panteragstk]

Originally Posted by crarbo1

Do you mind posting what settings worked for you? I'm hope to experiment this weekend with transcoding with OpenDCT and would like all the help I can get it to working.

Thanks,
Chuck

Originally Posted by smak

I am interested in your settings as well

I have been doing some transcoding but am interested in going to a different container. I have not cracked the code on that setting yet.

Thanks!

Sure. See attached. Keep in mind I have a 16 core (32 with hyperthreading) server so I have no clue how the settings will work on your servers.

[crarbo1]

Originally Posted by panteragstk

Sure. See attached. Keep in mind I have a 16 core (32 with hyperthreading) server so I have no clue how the settings will work on your servers.

Thanks. I will take a look at this now.

[panteragstk]

Originally Posted by crarbo1

Thanks. I will take a look at this now.

NP. Let us know if they work.

[scoful]

I can't believe I haven't seen this before. I've been running SageDCT for a few years. How's the stability of OpenDCT versus SageDCT?

[panteragstk]

Originally Posted by scoful

I can't believe I haven't seen this before. I've been running SageDCT for a few years. How's the stability of OpenDCT versus SageDCT?

No clue about comparing it to SageDCT, but I'm using HDHR's for OTA and converting to h.264 and it is rock solid.

[waylo]

Originally Posted by scoful

I can't believe I haven't seen this before. I've been running SageDCT for a few years. How's the stability of OpenDCT versus SageDCT?

I've found it rock solid. Many of us started having issues with RAW files produced by SageDCT not being able to be read in SageTV7. Not sure if that is still an issue with SageTV9, but many of us made the switch long ago.

Plus Enternoescape is great about troubleshooting and support on this forum.

[KarylFStein]

Originally Posted by scoful

I can't believe I haven't seen this before. I've been running SageDCT for a few years. How's the stability of OpenDCT versus SageDCT?

It's been very stable for me with an InfiniTV6 PCIe card. The developer is also very active and responsive which is a big reason why I moved from SageDCT.