OpenDCT: An open source digital cable tuner.

[muzicman0]

Originally Posted by EnterNoEscape

OpenDCT should be started before SageTV if possible. Run levels correlate with what's expected to be available in the OS and if we're powering up, rebooting or shutting down. However all of the distros have their own ideas about what they should be. I would have been of the impression you're using systemd, but if we're talking about runlevels, you must be using init.d.

The more important line is # Required-Start: $local_fs $remote_fs $network which indicates what the service needs before it can start. It could start in runlevel 2, 3, 4 or 5 if as soon as one of them has everything it needs. Anyway, try this:

sudo ln -fs /opt/opendct/service /etc/init.d/opendct
sudo chmod 755 /etc/init.d/opendct

I added a @reboot crontab under root, and it works now.

[EnterNoEscape]

Originally Posted by muzicman0

I added a @reboot crontab under root, and it works now.

I'm glad to see you worked something out.

[reggie14]

My family did Xmas yesterday, so I'm spending the day trying to get my new HDMI encoder working (to replace my HD-PVR which has been getting increasingly unreliable).

I thought it would be straightforward, but I'm running into a lot of stability and miscellaneous problems.

First, I'll describe my setup. I'm running OpenDCT 0.5.28. I followed the regular directions from this post, except that I'm using my USB-UIRT with no tuning executable and no stopping executable. Other than that, I left everything else the default (except for the later changes noted below). I'm using the 0.ts URL for the encoder.

After running into some initial problems, I realized I should have changed the consumer. So, now its set to opendct.consumer.RawSageTVConsumerImpl.

Then, I noticed SageTV was crashing every time I changed the channel with that tuner. I think I tracked this down to the stopping_executable_delay_ms setting. Basically, I noticed Sage locked up if I went straight from one channel to another. Setting the stopping executable delay to 0 (from the default of 15000) seemed to fix that. Are there any downsides to that?

Now I can't figure out why the tuning delay isn't working. I want Sage to send the USB-UIRT tuning commands right away, and then wait a few seconds for the channel to change before starting to record. I did this with my HD-PVR by configuring my Sage.properties with delay_to_wait_after_tuning=4000.

I've increased that to 6000, but Sage doesn't seem to be obeying it. What I see is Sage very quickly starts showing me the feed off the HDMI encoder. Then, a couple seconds later, I see the IR commands being sent for the channel change. Increasing the delay_to_wait_after_tuning in Sage.properties doesn't see to do anything.

One thing that confuses me is what do the settings in opendct.properties do? What does delay_to_wait_after_tuning do if I set it there? Also, I still have tuning_delay_ms set to 0, since I'm not using a tuning executable. Does that have an impact here?

Also, I've set fast_network_encoder_switch to false in both Sage.properties and OpenDCT.properties. I couldn't tell in the guide if that's required, or only required if you're not using a transport stream.

[waylo]

Are you making sure to close the SageTV application and/or service before making these changes? Otherwise the settings will not take.

[reggie14]

Originally Posted by waylo

Are you making sure to close the SageTV application and/or service before making these changes? Otherwise the settings will not take.

Yep. And I double checked that the settings stuck.

[SHS]

Originally Posted by reggie14

Yep. And I double checked that the settings stuck.

I guest you need wait for EnterNoEscape
But if I guest the delay_to_wait_after_tuning should also be set to same =4000

[EnterNoEscape]

Originally Posted by SHS

I guest you need wait for EnterNoEscape
But if I guest the delay_to_wait_after_tuning should also be set to same =4000

Correct. That's where the delay should be set for OpenDCT.

I'm curious why you saw any delays with the stop delay since that actually spins up a new thread and returns to SageTV immediately. If SageTV starts another recording before the time in milliseconds is up, it does that instead of stopping.

[reggie14]

I've been slowly increasing the delay values. Right now the value in the OpenDCT properties is 6000. And the value in Sage.properties is 8000. That should correspond to 6 seconds and 8 seconds, right? I tried restarting the server completely, too, just to make extra sure Sage was picking up the new values.

Yet, I don't see any difference in behavior. Sage very quickly jumps into the video. About 1 second in, I see the IR commands being sent to the STB.

While I'm obviously still open to the idea that this is user error, I really don't see what I could be doing wrong here.

I'll do some more testing with stopping_executable_delay_ms once I get other things working. Maybe something weird was just going on because I still had the HD-PVR set up. I noticed I couldn't get Sage to use the HDMI encoder over the HD-PVR, even though the encoder merit for the HDMI encoder was higher. I had to disable channels in the line-ups to do the testing.

Edit: It looks like it might not be just me running into this problem. Another user reported that delay_to_wait_after_tuning isn't working properly.

[EnterNoEscape]

I don't have a good answer for why this is happening. I'll have to see if I can reproduce the issue when time permits. In the mean time, if you can produce a SageTV server log and OpenDCT log after having the unexpected behavior, I might be able to see the problem.

[reggie14]

Originally Posted by EnterNoEscape

I don't have a good answer for why this is happening. I'll have to see if I can reproduce the issue when time permits. In the mean time, if you can produce a SageTV server log and OpenDCT log after having the unexpected behavior, I might be able to see the problem.

Thanks! I PMed you a link to the logs. It included my Sage.properties file, the OpenDCT.log, wrapper.log and the Sage log.

Wildly speculating, I wonder if the delay_to_wait_after_tuning setting works with network encoders.

[EnterNoEscape]

Originally Posted by reggie14

Thanks! I PMed you a link to the logs. It included my Sage.properties file, the OpenDCT.log, wrapper.log and the Sage log.

Wildly speculating, I wonder if the delay_to_wait_after_tuning setting works with network encoders.

The SageTV side of things probably doesn't obey the delay for network encoders. You did try tuning_delay_ms on the OpenDCT side of things correct? The logs implies that the delay is 0.

[reggie14]

Originally Posted by EnterNoEscape

The SageTV side of things probably doesn't obey the delay for network encoders. You did try tuning_delay_ms on the OpenDCT side of things correct? The logs implies that the delay is 0.

Update: Indeed, that's exactly what I needed to change. I needed to increase it to 7000ms (compared to 4000 ms with my HD-PVR). Though, channel changes don't feel that much longer. One more question: do I need to set the fast network encoder switch to false? The guide was a little unclear whether that applied to all HDMI network encoders, or just when you're using non-TS containers.

Original:
My OpenDCT log is attached. These are probably the relevant lines:

sagetv.device.-1512991805.channel_padding=0
sagetv.device.-1512991805.consumer=opendct.consumer.RawSageTVConsumerImpl
sagetv.device.-1512991805.custom_channels=
sagetv.device.-1512991805.delay_to_wait_after_tuning=7000
sagetv.device.-1512991805.device_name=HDMI Enc 1
sagetv.device.-1512991805.encoder_listen_port=9000
sagetv.device.-1512991805.encoder_merit=1
sagetv.device.-1512991805.encoder_pool=generic_http
sagetv.device.-1512991805.exclusive_server_address=
sagetv.device.-1512991805.fast_network_encoder_switch=false
sagetv.device.-1512991805.http_password=admin
sagetv.device.-1512991805.http_username=admin
sagetv.device.-1512991805.last_channel=552
sagetv.device.-1512991805.pretuning_executable=
sagetv.device.-1512991805.stopping_executable=
sagetv.device.-1512991805.stopping_executable_delay_ms=0
sagetv.device.-1512991805.streaming_url=http\://192.168.1.81/0.ts
sagetv.device.-1512991805.streaming_url2=
sagetv.device.-1512991805.streaming_url2_channels=
sagetv.device.-1512991805.transcode_profile=
sagetv.device.-1512991805.tuning_delay_ms=0
sagetv.device.-1512991805.tuning_executable=

Notably, tuning_delay_ms=0. Should that be increased? Or delay_to_wait_after_tuning?

The documentation suggests that tuning_delay_ms is only used if you're using a tuning executable.

[reggie14]

Are there any known bugs with tuner preference when you shut down OpenDCT with Sage still running?

I current use an HDHR Connect, HDHR Prime, and HDMI encoder, with tuner merit in that order. I've been playing with the OpenDCT settings a lot lately, and I've noticed some odd behavior. Basically, Sage starts wanting to use the HDMI encoder over the HDHR tuners.

It looks like Sage will try to use the HDHR tuners if the HDMI encoder is in use, although I can't really verify what works because the Sage UI hangs in that situation.

Restarting both Sage and OpenDCT seems to resolve the issue. And it's only happened to me so far after restarting OpenDCT without restarting Sage.

If this is interesting, I could do some more thorough testing. But, because of all the crashes, I don't want to do this if its already a known issue (or otherwise expected behavior).

A slightly more serious problem that I stumbled upon is that Sage really doesn't like it if different sections of a recorded show are recorded off different tuners. I had a situation where one section of a show was recorded off the HDMI encoder. When I went back to that channel later, Sage picked an HDHR tuner, but started playback from the earlier partial recording off the HDMI encoder. This at least made the HD300 crash. I ultimately had to restart the Sage server, too, but maybe for other reasons.

[mwittl]

My wife will often try to record 5 shows at a single time period, however, after using OpenDCT on a pretty beefy machine along with 2 HDHR Primes dedicated to our SageTV box, one of the 5 recordings will always get screwy (artifacts, blocking, pixilation, dead spots) when trying to record anything more than 4 shows. I'm trying to see what the limitation is on this, or if there is a setting I can tweek in the profile for OpenDCT to improve the number of simultaneous recordings? Using standard settings right now.

[KryptoNyte]

Originally Posted by mwittl

My wife will often try to record 5 shows at a single time period, however, after using OpenDCT on a pretty beefy machine along with 2 HDHR Primes dedicated to our SageTV box, one of the 5 recordings will always get screwy (artifacts, blocking, pixilation, dead spots) when trying to record anything more than 4 shows. I'm trying to see what the limitation is on this, or if there is a setting I can tweek in the profile for OpenDCT to improve the number of simultaneous recordings? Using standard settings right now.

Is the entire network gigabit start to finish, or is there 100mbit in there somewhere?

[waylo]

Originally Posted by mwittl

My wife will often try to record 5 shows at a single time period, however, after using OpenDCT on a pretty beefy machine along with 2 HDHR Primes dedicated to our SageTV box, one of the 5 recordings will always get screwy (artifacts, blocking, pixilation, dead spots) when trying to record anything more than 4 shows. I'm trying to see what the limitation is on this, or if there is a setting I can tweek in the profile for OpenDCT to improve the number of simultaneous recordings? Using standard settings right now.

When it's recording 5 streams, what's the CPU usage %?

More importantly, what is your storage media? Is it connected directly to the SageTV box or networked?

I think it'd be very difficult to get 5 HD recording threads to a single hard drive as there would definitely be some mechanical limitations.

If it's multiple hard drives, there is a setting in SageTV under "General" called "Video Recording Path Optimization Style." Make sure that's set to BANDWIDTH.

[EnterNoEscape]

Originally Posted by reggie14

Update: Indeed, that's exactly what I needed to change. I needed to increase it to 7000ms (compared to 4000 ms with my HD-PVR). Though, channel changes don't feel that much longer. One more question: do I need to set the fast network encoder switch to false? The guide was a little unclear whether that applied to all HDMI network encoders, or just when you're using non-TS containers.

Original:
My OpenDCT log is attached. These are probably the relevant lines:

sagetv.device.-1512991805.channel_padding=0
sagetv.device.-1512991805.consumer=opendct.consumer.RawSageTVConsumerImpl
sagetv.device.-1512991805.custom_channels=
sagetv.device.-1512991805.delay_to_wait_after_tuning=7000
sagetv.device.-1512991805.device_name=HDMI Enc 1
sagetv.device.-1512991805.encoder_listen_port=9000
sagetv.device.-1512991805.encoder_merit=1
sagetv.device.-1512991805.encoder_pool=generic_http
sagetv.device.-1512991805.exclusive_server_address=
sagetv.device.-1512991805.fast_network_encoder_switch=false
sagetv.device.-1512991805.http_password=admin
sagetv.device.-1512991805.http_username=admin
sagetv.device.-1512991805.last_channel=552
sagetv.device.-1512991805.pretuning_executable=
sagetv.device.-1512991805.stopping_executable=
sagetv.device.-1512991805.stopping_executable_delay_ms=0
sagetv.device.-1512991805.streaming_url=http\://192.168.1.81/0.ts
sagetv.device.-1512991805.streaming_url2=
sagetv.device.-1512991805.streaming_url2_channels=
sagetv.device.-1512991805.transcode_profile=
sagetv.device.-1512991805.tuning_delay_ms=0
sagetv.device.-1512991805.tuning_executable=

Notably, tuning_delay_ms=0. Should that be increased? Or delay_to_wait_after_tuning?

The documentation suggests that tuning_delay_ms is only used if you're using a tuning executable.

tuning_delay_ms is the number of milliseconds OpenDCT will wait before starting to buffer and stream from the device (this delay will happen if the tuning executable is defined or not). Using the tuning plugin from the SageTV side of things was added after that documentation was written. I'll have to update that. delay_to_wait_after_tuning the maximum number of milliseconds to wait before returning to SageTV regardless of if the requested channel is actually streaming. It doesn't need to be changed usually.

The fast remux setting can be set to true. OpenDCT supports it.

[EnterNoEscape]

Originally Posted by reggie14

Are there any known bugs with tuner preference when you shut down OpenDCT with Sage still running?

I current use an HDHR Connect, HDHR Prime, and HDMI encoder, with tuner merit in that order. I've been playing with the OpenDCT settings a lot lately, and I've noticed some odd behavior. Basically, Sage starts wanting to use the HDMI encoder over the HDHR tuners.

It looks like Sage will try to use the HDHR tuners if the HDMI encoder is in use, although I can't really verify what works because the Sage UI hangs in that situation.

Restarting both Sage and OpenDCT seems to resolve the issue. And it's only happened to me so far after restarting OpenDCT without restarting Sage.

If this is interesting, I could do some more thorough testing. But, because of all the crashes, I don't want to do this if its already a known issue (or otherwise expected behavior).

A slightly more serious problem that I stumbled upon is that Sage really doesn't like it if different sections of a recorded show are recorded off different tuners. I had a situation where one section of a show was recorded off the HDMI encoder. When I went back to that channel later, Sage picked an HDHR tuner, but started playback from the earlier partial recording off the HDMI encoder. This at least made the HD300 crash. I ultimately had to restart the Sage server, too, but maybe for other reasons.

I think this is actually an issue on the SageTV side of things based on how you're describing it. It sounds like SageTV just need to recognize that all of the tuners are now online. Technically SageTV should fix this within an hour, but I haven't payed close attention to merits in the scenario you're describing.

[mwittl]

Originally Posted by KryptoNyte

Is the entire network gigabit start to finish, or is there 100mbit in there somewhere?

My entire network is gigabit, end-to-end.

Originally Posted by waylo

When it's recording 5 streams, what's the CPU usage %?

More importantly, what is your storage media? Is it connected directly to the SageTV box or networked?

I think it'd be very difficult to get 5 HD recording threads to a single hard drive as there would definitely be some mechanical limitations.

If it's multiple hard drives, there is a setting in SageTV under "General" called "Video Recording Path Optimization Style." Make sure that's set to BANDWIDTH.

No idea of the CPU usage when it's recording. Most of our recordings occur after I go to bed!

Storage consists of several multi-terabyte disks, one is internal to the Sage box and one connected via USB 3.0

I double checked my Video Recording Path Optimization Style setting and it's already set to BANDWIDTH.

Any other thoughts or things for me to check?

[waylo]

Originally Posted by mwittl

My entire network is gigabit, end-to-end.




No idea of the CPU usage when it's recording. Most of our recordings occur after I go to bed!

Storage consists of several multi-terabyte disks, one is internal to the Sage box and one connected via USB 3.0

I double checked my Video Recording Path Optimization Style setting and it's already set to BANDWIDTH.

Any other thoughts or things for me to check?

Just to clarify, by 'several' you mean 2 HDs?

I think having 3 HD streams to a single HD (which would be inevitable if you have 5 streams split among 2 destinations) is too much for a HD to reliably write to.