OpenDCT: An open source digital cable tuner.

[EnterNoEscape]

Originally Posted by nyplayer

I tested this and it introduces other problems like I get now Video on channels that are MPEG2-TS to begin with on my clients.

If you're talking about the issue that I'm thinking of, you should be able to fix it by changing the value of hdhr.wait_for_streaming to 8500 or greater. The latest default is 8500ms because KryptoNyte reported that often the audio or video was missing. He's currently using 15000ms for that value which might be overkill. This value basically is how long OpenDCT is willing to wait to be told about 1MB has been written to the file before it returns OK to SageTV.

The value for InfiniTV devices is upnp.device.wait_for_streaming and also has the default of 8500.

[jgsouthard]

Originally Posted by EnterNoEscape

Thanks for the endorsement!

You were commenting about how you need to start the service, then stop it to have the option for tuner pooling options to be present. You can alternatively remove the old opendct.properties, before you upgrade and the latest properties file should be put in its place by the installer. I've become a little better at making sure the most recent "static" options are already in that starting properties.

I actually do remove the old opendct.properties file before the upgrade and let the new one get recreated, but none of the tuner entries are added to the file until you start and then stop SageTV. So since I'm starting with a clean opendct.properties file, I have to start Sagetv and then stop it so that the tuner entries get populated and then I can make my minor changes to the properties.

I could avoid all that by just keeping the old opendct.properties file intact, but I want to pick up new properties and defaults that you've added. I also could skip that step if I wasn't making any changes to the tuner properties in opendct.properties, but one of the changes that I make is to set sagetv.device.<device_id>.always_force_external_unlock=true for each of the tuners in opendct.properties. I can't make that changes until those entries get added.

[EnterNoEscape]

Originally Posted by jgsouthard

I could avoid all that by just keeping the old opendct.properties file intact, but I want to pick up new properties and defaults that you've added. I also could skip that step if I wasn't making any changes to the tuner properties in opendct.properties, but one of the changes that I make is to set sagetv.device.<device_id>.always_force_external_unlock=true for each of the tuners in opendct.properties. I can't make that changes until those entries get added.

It occurred to me right after I posted that that you might be changing the always_force_external_unlock property.

[nyplayer]

Originally Posted by EnterNoEscape

If you're talking about the issue that I'm thinking of, you should be able to fix it by changing the value of hdhr.wait_for_streaming to 8500 or greater. The latest default is 8500ms because KryptoNyte reported that often the audio or video was missing. He's currently using 15000ms for that value which might be overkill. This value basically is how long OpenDCT is willing to wait to be told about 1MB has been written to the file before it returns OK to SageTV.

The value for InfiniTV devices is upnp.device.wait_for_streaming and also has the default of 8500.

It was set to 8500 changed it to 10000 and they played ok.

Edit
That was just an experiment which I will not be using to encode as mpg ... it totally kills my SageMiniclient slow motion playing video. Most of my broadcast are H.264.

[EnterNoEscape]

Originally Posted by nyplayer

It was set to 8500 changed it to 10000 and they played ok.

Thanks for the feedback. I guess I should just bump that right up to 15000. The value is really just a balance between responsiveness when the channel isn't coming in and overall reliability mostly in regards to MPEG-PS. SageTV doesn't spend any time detecting what's in the MPEG-PS file. The instant it sees the file has data, if for any reason a stream is not present within the amount of data available in that instant, it will never see that stream. I really don't want to end up with that situation you got in SageDCT whereby it would hang onto the request so long you felt like it was malfunctioning.

[cat6man]

Originally Posted by EnterNoEscape

Thanks for the feedback. I guess I should just bump that right up to 15000. The value is really just a balance between responsiveness when the channel isn't coming in and overall reliability mostly in regards to MPEG-PS. SageTV doesn't spend any time detecting what's in the MPEG-PS file. The instant it sees the file has data, if for any reason a stream is not present within the amount of data available in that instant, it will never see that stream. I really don't want to end up with that situation you got in SageDCT whereby it would hang onto the request so long you felt like it was malfunctioning.

do you think this could be related to my livetv streaming problem?
if i record a channel and wait 30s, i can watch it without problem.
if i record a channel and and hit watch without waiting, the hd300 freeezes.
if i watch livetv, it plays for less than a minute before crashing the hd300

so, it seems that delay before streaming could be an issue here as well.
what do you think?

[EnterNoEscape]

Originally Posted by cat6man

do you think this could be related to my livetv streaming problem?
if i record a channel and wait 30s, i can watch it without problem.
if i record a channel and and hit watch without waiting, the hd300 freeezes.
if i watch livetv, it plays for less than a minute before crashing the hd300

so, it seems that delay before streaming could be an issue here as well.
what do you think?

It's hard to say. It can't hurt to try it. This delay will apply to MPEG-TS and MPEG-PS.

I'm currently trying to work out the best way to make sure the most needed information about the streams is always available, because I noticed that even with a delay in place there are still a very small number of incidents when the video doesn't come in. I noticed that if I purposefully make sure the very first frame to be written is a video key frame, it seems to fix this issue. The only place I still see problems on the Windows SageTV Client even with MPEG-PS is on Music Choice content. I have a feeling we will always struggle with that one at least on the client.

[cat6man]

i increased hdhr.wait_for_streaming to 13500 (13.5s if entry is in ms) and still crashed on livetv.
however, i did not notice any kind of delay before video showed up on tv, certainly nothing like 13.5 seconds.
this was recording with hdhr-prime...........seems like that delay is not in the logical path for me? maybe a clue........

[EnterNoEscape]

Originally Posted by cat6man

i increased hdhr.wait_for_streaming to 13500 (13.5s if entry is in ms) and still crashed on livetv.
however, i did not notice any kind of delay before video showed up on tv, certainly nothing like 13.5 seconds.
this was recording with hdhr-prime...........seems like that delay is not in the logical path for me? maybe a clue........

The delay is only carried out to 13.5s if no data has been written at present it returns as soon as 768k has been written. If it's somehow helping, you could try increasing the tuning delay on the SageTV side of things. That would be mmc/encoders/<unique_id>/delay_to_wait_after_tuning in Sage.properties. The default is 0. The value is in ms, you could try tacking a few seconds on there and see what happens.

[CptKirk]

Had lots of problems tonight. Lots of drops. Log files attached. It had seemed to be doing a lot better after I updated to the latest Intel Nic driver.

Did a hard power off/on for the HDHR and rebooted the server.

Using 4.45 rc9. Going to update to 4.47 stable after my wife's shows are over tonight.

[EnterNoEscape]

Originally Posted by CptKirk

Had lots of problems tonight. Lots of drops. Log files attached. It had seemed to be doing a lot better after I updated to the latest Intel Nic driver.

Did a hard power off/on for the HDHR and rebooted the server.

Using 4.45 rc9. Going to update to 4.47 stable after my wife's shows are over tonight.

15 seconds is a very long time for a channel to come in with the exception of Music Choice. In this case I'm not sure you actually had a network related issue, but somehow the entire streaming process completely stopped. See if upgrading makes any difference. I may also need to re-evaluate the amount of time that needs to pass before the re-tune thread assumes the streaming must be stalled.

[stanger89]

I hope I'm missing something simple, I've been trying to setup OpenDCT on one of my Prime tuners in an attempt to solve an issue with one of my channels.

I'm running an all ClearQAM setup with a Prime (no CC) and older HDHR. I have one channel that's been giving me garbled recordings so I'm wanting to try Open DCT.

Now, I went through the instructions posted earlier (Deezer I think), and it all seems like it's working, it finds my HDHRs, they show up in Sage, they show 100% signal strength, but when I try to preview or view a station I get no signal.

Am I missing a step on remapping channels? Or something else simple? I found mentions of doing this with a CC, but I don't have one of those.

[CptKirk]

Switched to 4.47. Doing better, still having some macroblocking and image freezing. Logs attached, problems starting at 19:05.

[EnterNoEscape]

Originally Posted by stanger89

I hope I'm missing something simple, I've been trying to setup OpenDCT on one of my Prime tuners in an attempt to solve an issue with one of my channels.

I'm running an all ClearQAM setup with a Prime (no CC) and older HDHR. I have one channel that's been giving me garbled recordings so I'm wanting to try Open DCT.

Now, I went through the instructions posted earlier (Deezer I think), and it all seems like it's working, it finds my HDHRs, they show up in Sage, they show 100% signal strength, but when I try to preview or view a station I get no signal.

Am I missing a step on remapping channels? Or something else simple? I found mentions of doing this with a CC, but I don't have one of those.

Unfortunately, if you don't have a tuner with a CableCARD, you're going to have a very hard time with OpenDCT and ClearQAM. You would need to manually specify all of the frequencies and programs which probably isn't going to be worth your time. If you're interested in editing the lineup in this fashion, I can tell you what you'll need to change, but you may find in the end it's easier to use the support already built into SageTV for remapping channels.

[EnterNoEscape]

Originally Posted by CptKirk

Switched to 4.47. Doing better, still having some macroblocking and image freezing. Logs attached, problems starting at 19:05.

Is there any possibility that something else is trying to use your HDHomeRun tuners or rebooting them? The reason I ask is because I can see in at least one instance, 5 minutes into the recording, the device suddenly goes missing for about 45 seconds, then comes back not tuned into anything. I verified that SageTV had not asked for it to stop.

Possibly unrelated, but worth trying anyway. For at least one user, it was a benefit to disable using http to stream the video data. Here's how you do that:

1) Stop the OpenDCT service.
2) Open opendct.properties.
3) Change hdhr.allow_http_tuning to false
4) Save the file.
5) Start the OpenDCT service.

[EnterNoEscape]

Originally Posted by EnterNoEscape

Unfortunately, if you don't have a tuner with a CableCARD, you're going to have a very hard time with OpenDCT and ClearQAM. You would need to manually specify all of the frequencies and programs which probably isn't going to be worth your time. If you're interested in editing the lineup in this fashion, I can tell you what you'll need to change, but you may find in the end it's easier to use the support already built into SageTV for remapping channels.

I figured I should add to this. If you have a prime and you have done a channel scan on the prime, you should have a bunch of channels starting at 5000 in a file named qam_hdhomerun_xxxxxxxx.properties under the lineup folder in the OpenDCT configuration directory.

One line should look something like this:

channel.5000=5000,,false,Unknown,http\://x.x.x.x\:5004/auto/v5000,,-1,,,0,UNKNOWN,false

5000 as you may have guessed is the channel according to the HDHomeRun Prime. The value missing between the commas (,,) would be the actual channel that you would like SageTV to associate with that channel. So for example, if you discover that channel 5000 is actually channel 2, you would edit that line to look like the following.

channel.5000=5000,2,false,Unknown,http\://x.x.x.x\:5004/auto/v5000,,-1,,,0,UNKNOWN,false

For the legacy HDHomeRun, what you can do is get the prime mapped, then check every channel you mapped on the prime in SageTV. This will cause the programs and frequencies to be populated. Then when you tune in on the legacy HDHomeRun, the values should be transferred automatically.

As you can see it's not terribly trivial. In fact it would be a lot easier if there was a configuration interface of some kind.

[EnterNoEscape]

I've been looking at a few issues as they have come up in the most recent stable version and this update should address many of them without introducing new problems. Many of these changes are being pushed into the current beta too.

• CONFIGURATION UPGRADE: The first time you run this version, it will upgrade your current configuration. Anything still referencing FFmpegSageTVConsumerImpl will be changed over to FFmpegTransSageTVConsumerImpl. hdhr.wait_for_streaming and upnp.dct.wait_for_streaming will be changed to 15000.
• Renamed FFmpegSageTVConsumerImpl to FFmpegOldSageTVConsumerImpl to force old installations to use the newer remuxer unless explicitly set otherwise.
• Increased initial bytes written before returning to SageTV up to 1MB.
• Removed small performance optimization to reduce the number reads performed by the transcoding FFmpeg consumer.
• Increased re-tune timeout to 16000ms.
• Fixed counter not resetting on SWITCH for direct FFmpeg consumer.

[stanger89]

Originally Posted by EnterNoEscape

...but you may find in the end it's easier to use the support already built into SageTV for remapping channels.

What does this mean? Setup the tuner(s) in OpenDCT, and then in Sage do a Channel scan and remap? I believe I tried that but I'll have to try again.

For what it's worth I get a "good" lineup from the HDHR via lineup.xml (if I grab it manually), as in I get real channel numbers. At some point "recently" my provider started providing the logical channel numbers in the PSIP (I believe) data, at least in such a way that the HDHR software would recognize them.

[matt91]

Hi -

I'm still getting some occasional missed recordings, including at 2100 [Chicago Med] last night. The show at 2200 [Chicago Fire] on the same channel (804) recorded OK, so I'm not sure what's up. (there are a few other shows that recorded last night too, but I honestly didn't notice if they did or didn't record - and I'm at work now and can't confirm.)

Is there anything telling in here? I can post the sagetv_0 log once I get home if that is needed.

thanks again for any help.

edit: I'm running 0.5.0 beta

[nyplayer]

Originally Posted by matt91

Hi -

I'm still getting some occasional missed recordings, including at 2100 [Chicago Med] last night. The show at 2200 [Chicago Fire] on the same channel (804) recorded OK, so I'm not sure what's up. (there are a few other shows that recorded last night too, but I honestly didn't notice if they did or didn't record - and I'm at work now and can't confirm.)

Is there anything telling in here? I can post the sagetv_0 log once I get home if that is needed.

thanks again for any help.

edit: I'm running 0.5.0 beta

out of curiosity do you have this property ... also I recommend pooling if you are not using it
always_force_external_unlock=true

I set that to true and it makes sure it takes the tuner forcibly if it needs to .... works great