OpenDCT: An open source digital cable tuner.

[BobbyDing]

Can two instances of Sage/Opendct share the same 6 hdhr tuners (3 devices)? I was wondering if I set the tuner pools with opposite merits, would they coexist happily (excepting of course if they run out of available tuners)? If it's possible, pooling would need to be enabled. But what would the lock settings need to be set to? Are there any other settings that would need to be tweaked? Or is this just not practical?

Thanks!

[panteragstk]

Question: How do I tweak deinterlacing when encoding to 1080p? It doesn't seem to be working all that well with my interlaced channels.

[EnterNoEscape]

Originally Posted by BobbyDing

Can two instances of Sage/Opendct share the same 6 hdhr tuners (3 devices)? I was wondering if I set the tuner pools with opposite merits, would they coexist happily (excepting of course if they run out of available tuners)? If it's possible, pooling would need to be enabled. But what would the lock settings need to be set to? Are there any other settings that would need to be tweaked? Or is this just not practical?

Thanks!

It can be done, but they will fight each other a lot because SageTV doesn't know what it can't use. nyplayer did something clever like what you're describing, but he set it up so that one of the instances was not allowed to force use of the tuners and the other instance was allowed for force use of the tuners. The first instance I described was a test machine and the second instance was his production machine. That means that any time the production machine needs a tuner regardless of what the test machine wants at the moment will always win. The test machine will just get what it can get or nothing if nothing is available without forcing the use of a tuner.

Originally Posted by panteragstk

Question: How do I tweak deinterlacing when encoding to 1080p? It doesn't seem to be working all that well with my interlaced channels.

Are you seeing combing? The logs should show if it actually detected the content as interlaced or not. If it's failing to detect interlaced content correctly, I'll need to fix that, but if it is finding it and the quality isn't great under some circumstances, you'll need to play with the settings below.

#===================================================================================================
# These are the default filter graph options for encoding to h264.
#===================================================================================================
# This filter is used if the content is determined to be interlaced. Since frame doubling is
# enabled, every frame must be deinterlaced or the video might have a variable frame rate. Special
# characters such as backslash (\) must be escaped (\\) in this file. opendct_dfps gets converted to
# double the input source framerate. This "hack" is needed or the output file will report that the
# stream is quadruple the original frame rate due to the input time base code. It is more efficient
# to let the filter graph handle this than to code the scaling on the Java side.
v.e.default.h264.deinterlace_filter=yadif=mode=2, mcdeint=mode=fast, scale=w='trunc(oh*a/16)*16':h='min(720\\,ih)':interl=0:flags=bilinear, format=pix_fmts=yuv420p, fps=fps=opendct_fps:round=near

# This filer is used if the content is determined to be progressive. opendct_fps gets converted to
# the input source framerate. This "hack" is needed or the output file may report that the stream is
# quadruple the original frame rate due to the input time base code. It is more efficient to let the
# filter graph handle this than to code the scaling on the Java side.
v.e.default.h264.progressive_filter=scale=w='trunc(oh*a/16)*16':h='min(720\\,ih)':interl=0:flags=bilinear, format=pix_fmts=yuv420p, fps=fps=opendct_fps:round=near

# This filter is used for any 720p content. 'default' is an alias for 'w*.h*' The left to right most
# specific setting always wins if there is a conflict.
# Ex. w1280.h720 > w1280.h* > w*.h720
v.e.w1280.h720.h264.progressive_filter=format=pix_fmts=yuv420p, fps=fps=opendct_fps:round=near

# This filter disables frame doubling for 1080i content so only 29.97 FPS needs to be processed.
v.e.w1920.h1080.h264.deinterlace_filter=yadif=mode=0, scale=w='trunc(oh*a/16)*16':h='min(720\\,ih)':interl=0:flags=bilinear, format=pix_fmts=yuv420p, fps=fps=opendct_fps:round=near

The very last line is likely of most interest to you since at least in the example file that's what's applied to 1080i when it's deinterlaced to 1080p. We are using yadif=mode=0 to deinterlace. It's literally the same way filtering is described when using FFmpeg with the addition of the opendct_fps helpers. You can change anything you see, but I would recommend keeping fps=fps=opendct_fps:round=near or the framerate might become a little variable.

[panteragstk]

Thanks. I'll check the logs and let you know if they show that interlaced content is not being detected. Otherwise I'll play around with the settings.

[tmalley]

Old machine crapped out. Now have a Win 10 64bit CyberPowerPC with AMD FX 8350 and AMD Radeon Rx 480 graphics. Using Ceton infiniTV6 PCie. Sagetv7 is reinstalled. SageDCT web site not available and can't find another site to download it so found OpenDCT. Can't tell which of the 6 versions of 5.28.1 to download.... Downloaded JAVA 1.8.0-121 but don't know how to tell if 32 or 64 bit. What the F... is file type .rpm .deb and .msi and why do I care? Please help ASAP since I have NO SageTV!!!

[KryptoNyte]

From the "stable" link in the first post of this thread, you would download;

OpenDCT_0.5.28_x86.msi

[Tiki]

.msi is an installer package for Windows.
.rpm and .dev are packages for Linux.

[tmalley]

Much appreciated. I'll give it a try.

Downloaded, installed..followed instructions by Daweeze..Working with no issues at this time.
Wife is happy again. Thanks to all.

[technazz]

Still getting pausing after changing the consumers to RAW and changing the below settings


consumer.ffmpeg.thread_priority=9
consumer.media_server.thread_priority=9
consumer.raw.thread_priority=9


Can you take a look to see if there is anything in the logs?

Thanks

Chris

[EnterNoEscape]

Originally Posted by technazz

Still getting pausing after changing the consumers to RAW and changing the below settings


consumer.ffmpeg.thread_priority=9
consumer.media_server.thread_priority=9
consumer.raw.thread_priority=9


Can you take a look to see if there is anything in the logs?

Thanks

Chris

All I can tell is that the streams keep stalling out. Their end is disconnecting from OpenDCT and as a result OpenDCT is closing the connection. Does this service permit multiple streams?

[BobbyDing]

Originally Posted by EnterNoEscape

It can be done, but they will fight each other a lot because SageTV doesn't know what it can't use. nyplayer did something clever like what you're describing, but he set it up so that one of the instances was not allowed to force use of the tuners and the other instance was allowed for force use of the tuners. The first instance I described was a test machine and the second instance was his production machine. That means that any time the production machine needs a tuner regardless of what the test machine wants at the moment will always win. The test machine will just get what it can get or nothing if nothing is available without forcing the use of a tuner.

Thank you. Is that done with the LOCK properties?
.

[technazz]

Originally Posted by EnterNoEscape

All I can tell is that the streams keep stalling out. Their end is disconnecting from OpenDCT and as a result OpenDCT is closing the connection. Does this service permit multiple streams?

Ok,

I have a limit of 4 connections from the same IP. When I watched recording, i only lost video, audio continued to play.

The 'source' sometimes has buffering issues and stalls from time to time but it is usually random. The space between the stalls seemed consistent thats why i thought something was going on with either the settings or the computer not keeping up.

T Hanks

Chris

[EnterNoEscape]

Originally Posted by BobbyDing

Thank you. Is that done with the LOCK properties?
.

This is in the first post. I believe this should answer your questions about pooling.

This new feature enables OpenDCT to intelligently select a tuner based on merit and lock status in that order. It does two passes over the tuners. The first one tries to find the highest merit tuner that is not currently in use by SageTV; it checks each one in order to see if it's locked. If they are all either in use or locked, it then it goes through a shorter list of tuners not in use by SageTV, but locked and checks if it's allowed to unlock any of them forcefully. If it's not allowed on any of them, then it gives up. These locked checks are surprisingly fast. Since the InfiniTV devices do not have a locked indication like the HDHomeRun Prime devices, enabling pooling with only InfiniTV devices will just remap them based on merit.

To enable the pooling feature change the property pool.enabled from false to true.

Because of this new feature, the force unlock feature is now set per capture device. 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.
Merit is set by changing the value of sagetv.device.<unique_id>.encoder_merit. Higher numbers mean higher priority. This is also the merit that will be sent on discovery.

Pools are automatically assigned based on capture device type the first time you run OpenDCT. You can change the pools by changing the value of sagetv.device.<unique_id>.encoder_pool to another name for all of the capture devices that you want to put into a different pool. The name is case sensitive. Also be sure to not have any extra spaces. I highly do not recommend putting capture devices that cannot tune the same channels into the same pool. It will create a problem per paragraph two in the issue created for this feature.

[panteragstk]

Originally Posted by EnterNoEscape

It can be done, but they will fight each other a lot because SageTV doesn't know what it can't use. nyplayer did something clever like what you're describing, but he set it up so that one of the instances was not allowed to force use of the tuners and the other instance was allowed for force use of the tuners. The first instance I described was a test machine and the second instance was his production machine. That means that any time the production machine needs a tuner regardless of what the test machine wants at the moment will always win. The test machine will just get what it can get or nothing if nothing is available without forcing the use of a tuner.



Are you seeing combing? The logs should show if it actually detected the content as interlaced or not. If it's failing to detect interlaced content correctly, I'll need to fix that, but if it is finding it and the quality isn't great under some circumstances, you'll need to play with the settings below.

#===================================================================================================
# These are the default filter graph options for encoding to h264.
#===================================================================================================
# This filter is used if the content is determined to be interlaced. Since frame doubling is
# enabled, every frame must be deinterlaced or the video might have a variable frame rate. Special
# characters such as backslash (\) must be escaped (\\) in this file. opendct_dfps gets converted to
# double the input source framerate. This "hack" is needed or the output file will report that the
# stream is quadruple the original frame rate due to the input time base code. It is more efficient
# to let the filter graph handle this than to code the scaling on the Java side.
v.e.default.h264.deinterlace_filter=yadif=mode=2, mcdeint=mode=fast, scale=w='trunc(oh*a/16)*16':h='min(720\\,ih)':interl=0:flags=bilinear, format=pix_fmts=yuv420p, fps=fps=opendct_fps:round=near

# This filer is used if the content is determined to be progressive. opendct_fps gets converted to
# the input source framerate. This "hack" is needed or the output file may report that the stream is
# quadruple the original frame rate due to the input time base code. It is more efficient to let the
# filter graph handle this than to code the scaling on the Java side.
v.e.default.h264.progressive_filter=scale=w='trunc(oh*a/16)*16':h='min(720\\,ih)':interl=0:flags=bilinear, format=pix_fmts=yuv420p, fps=fps=opendct_fps:round=near

# This filter is used for any 720p content. 'default' is an alias for 'w*.h*' The left to right most
# specific setting always wins if there is a conflict.
# Ex. w1280.h720 > w1280.h* > w*.h720
v.e.w1280.h720.h264.progressive_filter=format=pix_fmts=yuv420p, fps=fps=opendct_fps:round=near

# This filter disables frame doubling for 1080i content so only 29.97 FPS needs to be processed.
v.e.w1920.h1080.h264.deinterlace_filter=yadif=mode=0, scale=w='trunc(oh*a/16)*16':h='min(720\\,ih)':interl=0:flags=bilinear, format=pix_fmts=yuv420p, fps=fps=opendct_fps:round=near

The very last line is likely of most interest to you since at least in the example file that's what's applied to 1080i when it's deinterlaced to 1080p. We are using yadif=mode=0 to deinterlace. It's literally the same way filtering is described when using FFmpeg with the addition of the opendct_fps helpers. You can change anything you see, but I would recommend keeping fps=fps=opendct_fps:round=near or the framerate might become a little variable.

It is detecting interlaced content without issue. I changed some settings around and it seems to have improved things a bit. BTW, I'm also using transcode to 1080p if that makes a difference in filter settings.

[peternm22]

Quick question about one of the settings "retune_enable=", is this the same as the SageTV setting "Always Tune Channel"?

I have "Always Tune channel" in SageTV set to false, but I noticed that my OpenDCT tuners (two BM3000's, using the USB-UIRT), are still changing the channel even if it is on the same channel.

[EnterNoEscape]

Originally Posted by peternm22

Quick question about one of the settings "retune_enable=", is this the same as the SageTV setting "Always Tune Channel"?

I have "Always Tune channel" in SageTV set to false, but I noticed that my OpenDCT tuners (two BM3000's, using the USB-UIRT), are still changing the channel even if it is on the same channel.

That has to do with a monitoring feature. If that's set to true, OpenDCT will restart the capture device streaming if it stops streaming for a specific number of milliseconds. It's really only there because of the InfiniTV 6 Eth which will disappear from the network and some people didn't want to wait the full minute for SageTV to just tell OpenDCT to restart the recording. For your situation, it would be perfectly safe to set it to false since you're really not going to get any benefit.

[ptaylor]

First, sorry this is a novel.... But I'm having some issues...

Used SageTV a long time ago, been running MythTV mostly for the last few years, but MythTV still doesn't seem to be nearly as good as SageTV was years ago, in my opinion (no disrespect intended to the Devs who work on it).

Anyhow, I am running UnRaid with the docker versions of SageTV and OpenDCT. I also have a Shield TV and have had some issues with the Android client. Sometimes it works great, other times it acts up. Tonight, i started playing a show and tried to back up a bit because it skipped a bit of the beginning, and it seemed to skip forward instead of back, multiple times, but I digress.

I pointed the Plex server built into the Shield to my UnRaid box where the SageTV recordings are stored. Since I started naming the shows with the season and episode, Plex seems to pick them up pretty well. Plex was running pretty slow though when I tried to skip, and it seems that Plex is transcoding the files to play back on the Shield. Since they are just MPEG2 in transport streams, and I thought the Shield should handle that with hardware, I'm a bit surprised that it was transcoding. I even tried forcing Plex to play it directly, but then it didn't seem to play at all. So, I tried pointing Kodi to that directory and I couldn't play the .ts files there either. Now, I had one file that I had transcoded to a regular MPEG file, and it would play back fine in Kodi, but not the .ts files.

Is there something special about these .ts files?

Tonight, SageTV was set to record the Amazing Race. With about 10 minutes left, I was looking through SageTV and noticed the dreaded red bar over the blank preview window. My recording was not really working. I tried to play it and was getting "No Signal". I shut down the OpenDCT and SageTV dockers and started my MythTV docker. It booted up and started recording the show (since it was set as a favorite in MythTV also), also in .ts format. I navigated to the Share where it was in Kodi and could play it fine, though it was only a bit over 6 minutes long..

Why would I get the "No signal" in SageTV, but it worked fine in MythTV?

I went into SageTV and looked at Past Airings of the Amazing Race, and the two listed (4/27 and 5/4) are both shown in italics, which means they were watched, right? That would seem to indicate that it worked before, but isn't now... (I've stopped the MythTV docker and started the SageTV dockers back up, and can confirm that the channel isn't coming in on SageTV, but the same channel works under MythTV.)

Any suggestions on getting everything working again in SageTV?

[EnterNoEscape]

Originally Posted by ptaylor

First, sorry this is a novel.... But I'm having some issues...

Used SageTV a long time ago, been running MythTV mostly for the last few years, but MythTV still doesn't seem to be nearly as good as SageTV was years ago, in my opinion (no disrespect intended to the Devs who work on it).

Anyhow, I am running UnRaid with the docker versions of SageTV and OpenDCT. I also have a Shield TV and have had some issues with the Android client. Sometimes it works great, other times it acts up. Tonight, i started playing a show and tried to back up a bit because it skipped a bit of the beginning, and it seemed to skip forward instead of back, multiple times, but I digress.

I pointed the Plex server built into the Shield to my UnRaid box where the SageTV recordings are stored. Since I started naming the shows with the season and episode, Plex seems to pick them up pretty well. Plex was running pretty slow though when I tried to skip, and it seems that Plex is transcoding the files to play back on the Shield. Since they are just MPEG2 in transport streams, and I thought the Shield should handle that with hardware, I'm a bit surprised that it was transcoding. I even tried forcing Plex to play it directly, but then it didn't seem to play at all. So, I tried pointing Kodi to that directory and I couldn't play the .ts files there either. Now, I had one file that I had transcoded to a regular MPEG file, and it would play back fine in Kodi, but not the .ts files.

Is there something special about these .ts files?

Tonight, SageTV was set to record the Amazing Race. With about 10 minutes left, I was looking through SageTV and noticed the dreaded red bar over the blank preview window. My recording was not really working. I tried to play it and was getting "No Signal". I shut down the OpenDCT and SageTV dockers and started my MythTV docker. It booted up and started recording the show (since it was set as a favorite in MythTV also), also in .ts format. I navigated to the Share where it was in Kodi and could play it fine, though it was only a bit over 6 minutes long..

Why would I get the "No signal" in SageTV, but it worked fine in MythTV?

I went into SageTV and looked at Past Airings of the Amazing Race, and the two listed (4/27 and 5/4) are both shown in italics, which means they were watched, right? That would seem to indicate that it worked before, but isn't now... (I've stopped the MythTV docker and started the SageTV dockers back up, and can confirm that the channel isn't coming in on SageTV, but the same channel works under MythTV.)

Any suggestions on getting everything working again in SageTV?

One of the things people don't know when they use the OpenDCT docker is that it's using the SageTV internal remuxer which is fine in many cases, but it doesn't do as well with poorly constructed streams (which is very common from many cable companies) as other remuxing methods like FFmpeg. When you do a normal OpenDCT installation, FFmpeg is what is used by default because it's the best choice. You'll want to stop the OpenDCT docker, then edit opendct.properties changing to the following values:

consumer.dynamic.default=opendct.consumer.FFmpegTransSageTVConsumerImpl
consumer.ffmpeg.upload_id_enabled=true

After doing that, save the changes and start the container again. You should have a much better experience.

[ptaylor]

Originally Posted by EnterNoEscape

You'll want to stop the OpenDCT docker, then edit opendct.properties changing to the following values:

consumer.dynamic.default=opendct.consumer.FFmpegTransSageTVConsumerImpl
consumer.ffmpeg.upload_id_enabled=true

After doing that, save the changes and start the container again. You should have a much better experience.

Ok - I shut down the OpenDCT container, changed the file, then restarted the container. After that, the file is changed back. I've tried it several times, and after the docker starts up, this setting reverts back to:

consumer.dynamic.default=opendct.consumer.MediaServerConsumerImpl

What am I doing wrong?

[EnterNoEscape]

Originally Posted by ptaylor

Ok - I shut down the OpenDCT container, changed the file, then restarted the container. After that, the file is changed back. I've tried it several times, and after the docker starts up, this setting reverts back to:

consumer.dynamic.default=opendct.consumer.MediaServerConsumerImpl

What am I doing wrong?

You're probably doing nothing wrong. I think the container is scripted to force MediaServerConsumerImpl on you. It might be easier to change sagetv.device.<unique_id>.consumer=opendct.consumer.DynamicConsumerImpl to opendct.consumer.FFmpegTransSageTVConsumerImpl for each capture device.

I know that the docker scripts don't manipulate those values.