OpenDCT: An open source digital cable tuner.

[Fuzzy]

Originally Posted by EnterNoEscape

I don't believe we can. It's a nice video; thanks for putting that together. I have a fun fact for you that has saved me a lot of time when setting up tuners. You can just hit cancel and it will move forward anyway when you see The Broadcast Standard is being determined. Please wait... I'm honestly not sure what it's supposed to be doing there.

Old legacy step that should probably be removed...

[sflamm]

Noticed that OpenDCT tuning of HDHR Prime seems to have slowed down significantly in recent versions...

Any tips for speeding it up?

I've read that setting this might help:

consumer.dynamic.default=opendct.consumer.MediaServerConsumerImpl

Does this work with HDHR Prime?

Not sure what the MediaServerConsumerImplConsumer type is as it is not listed in the documentation:

Dynamic Consumer Options:
Channel Range Notation
Channel ranges are defined by a number then a hyphen followed by another number (8-10). Multiple ranges are separated by a comma (13-15,8-10). ATSC channels are defined by a number (frequency channel) then a hyphen followed by a the channel number then a hyphen followed by the sub-channel number (50-8-1). The use of two hyphens automatically makes it literally a channel instead of a range.
Ex. 8-10,50-8-1,13-16 will match the following channels: 8, 9, 10, 50-8-1, 13, 14, 15, 16
consumer.dynamic.channels.ffmpeg=
These are the channels that will always be assigned to the transcoding FFmpeg consumer.
consumer.dynamic.channels.raw=
These are the channels that will always be assigned to the raw consumer.
consumer.dynamic.default=opendct.consumer.FFmpegTransSageTVConsumerImpl
This is the consumer always used if the channel currently tuned doesn't match the channels under consumer.dynamic.channels.ffmpeg or consumer.dynamic.channels.raw.

Can someone please explain what consumer to use and when/why?

thanks in advance.

[sflamm]

In my openDCT configuration file:

consumer.dynamic.default=opendct.consumer.FFmpegTransSageTVConsumerImpl

...

sagetv.device.-472171404.always_force_external_unlock=false
sagetv.device.-472171404.consumer=opendct.consumer.FFmpegTransSageTVConsumerImpl
sagetv.device.-472171404.delay_to_wait_after_tuning=0
sagetv.device.-472171404.device_name=DCT-HDHomeRun Prime Tuner 13185194-2

What is the difference between the consumer.dynamic.default and sagetv.device.parent.consumer ?


Also in the documentation:

sagetv.device.parent.<unique_id>.consumer=opendct.consumer.FFmpegTransSageTVConsumerImpl
This is the implementation to be used for streaming to SageTV. The currently valid values for this property are the default and opendct.consumer.RawSageTVConsumerImpl. Parent entries cover an entire device. Right now this is for convenience, so you don't need to set this value for each tuner. It will probably change once we are using a web interface. opendct.consumer.FFmpegSageTVConsumerImpl has been deprecated as of 0.4.

The configuration default setting is

opendct.consumer.FFmpegTransSageTVConsumerImpl (I did not modify).

If this is deprecated what should be used instead?


And there is no meantion of MediaServerConsumerImplConsumer type in the documentation at all...

[KarylFStein]

Originally Posted by sflamm

In my openDCT configuration file:



What is the difference between the consumer.dynamic.default and sagetv.device.parent.consumer ?


Also in the documentation:



The configuration default setting is

opendct.consumer.FFmpegTransSageTVConsumerImpl (I did not modify).

If this is deprecated what should be used instead?


And there is no meantion of MediaServerConsumerImplConsumer type in the documentation at all...

opendct.consumer.FFmpegTransSageTVConsumerImpl is right (note the "Trans" in there.

You can set a "default" consumer type, but then overwrite that value on the device level if you want. What I have is this:

...
consumer.dynamic.default=opendct.consumer.FFmpegTransSageTVConsumerImpl
...
sagetv.device.741291179.consumer=opendct.consumer.DynamicConsumerImpl

Here device 741291179 will use the default consumer which is defined by the consumer.dynamic.default line.

[KarylFStein]

Originally Posted by sflamm

And there is no meantion of MediaServerConsumerImplConsumer type in the documentation at all...

Hm, when I thought I was testing the media server encoder I set these:

consumer.ffmpeg.upload_id_enabled=true
consumer.raw.upload_id_enabled=true

Maybe I did it wrong...

[EnterNoEscape]

Originally Posted by KarylFStein

Hm, when I thought I was testing the media server encoder I set these:

consumer.ffmpeg.upload_id_enabled=true
consumer.raw.upload_id_enabled=true

Maybe I did it wrong...

You are using the media server in that case too. The slowdowns are related to some compatibility for SageTV v7. That's one of the reasons I said I am going to stop supporting things that only break v7 in the next beta cycle.

[EnterNoEscape]

Originally Posted by sflamm

Noticed that OpenDCT tuning of HDHR Prime seems to have slowed down significantly in recent versions...

Any tips for speeding it up?

I've read that setting this might help:

consumer.dynamic.default=opendct.consumer.MediaServerConsumerImpl

Does this work with HDHR Prime?

Not sure what the MediaServerConsumerImplConsumer type is as it is not listed in the documentation:



Can someone please explain what consumer to use and when/why?

thanks in advance.

The media server consumer is described in the release notes. Admittedly it is a little buried. I've been mostly full steam ahead and haven't taken a lot of time to update the general information about them. It's really a lot to process for anyone.

The media server consumer is the fastest of the bunch. The only problem is that this one still chokes for some people. The code behind it is complicated enough that I haven't been able to fix some of the problems people have seen. This is the remuxer that SageTV uses for it's natively supported tuners and the remuxing actually happens within the SageTV JVM, not OpenDCT. This only uses the media server.

The FFmpeg consumer is the most widely adaptive and the default because it's the safest bet for most people. It uses the FFmpeg libraries to remux the stream. This by default writes directly to disk, but can be told to write to the SageTV media server instead.

The raw consumer is what is sounds like. It writes out the stream unfiltered. This by default writes directly to disk, but can be told to write to the SageTV media server instead.

[jgsouthard]

Originally Posted by EnterNoEscape

You are using the media server in that case too. The slowdowns are related to some compatibility for SageTV v7. That's one of the reasons I said I am going to stop supporting things that only break v7 in the next beta cycle.

Just to make sure I'm clear on what you are saying. So are you saying that those of us still on SageTV v7 should stick with OpenDCT 0.5.24 and not upgrade to any future versions unless/until we upgrade to SageTV v9; or only that if we use a later beta and it doesn't work you won't support a fix unless it also doesn't work in v9?

I've stayed with v7 on Windows 10 because it has been rock solid with OpenDCT for months, so I've been reluctant to go through the v9 upgrade and risk breaking something else. But you keep improving OpenDCT, and I'd like to be able to take advantage of those improvements.

[EnterNoEscape]

Originally Posted by jgsouthard

Just to make sure I'm clear on what you are saying. So are you saying that those of us still on SageTV v7 should stick with OpenDCT 0.5.24 and not upgrade to any future versions unless/until we upgrade to SageTV v9; or only that if we use a later beta and it doesn't work you won't support a fix unless it also doesn't work in v9?

I've stayed with v7 on Windows 10 because it has been rock solid with OpenDCT for months, so I've been reluctant to go through the v9 upgrade and risk breaking something else. But you keep improving OpenDCT, and I'd like to be able to take advantage of those improvements.

You can continue to upgrade, but if a change makes it stop working for you on v7, I will still try to help you out, but the answer may ultimately be upgrade. I don't foresee any major breaking changes for 90% of users. The current stable will remain compatible and may recieve fixes if needed. One of the first things I will be eliminating are those delays which will break PS format detection on v7.

[Tiki]

Originally Posted by jgsouthard

Just to make sure I'm clear on what you are saying. So are you saying that those of us still on SageTV v7 should stick with OpenDCT 0.5.24 and not upgrade to any future versions unless/until we upgrade to SageTV v9; or only that if we use a later beta and it doesn't work you won't support a fix unless it also doesn't work in v9?

I've stayed with v7 on Windows 10 because it has been rock solid with OpenDCT for months, so I've been reluctant to go through the v9 upgrade and risk breaking something else. But you keep improving OpenDCT, and I'd like to be able to take advantage of those improvements.

And don't forget, if you're using the built in Sage EPG data, that's going away in July. You will need to migrate to a new source before then or you won't have any guide data. Sage v9 has added built in support for Schedules Direct, which is a $25/year service for guide data. So most people will be forced to upgrade to v9 and get a SD subscription by July.

[EnterNoEscape]

Originally Posted by Tiki

And don't forget, if you're using the built in Sage EPG data, that's going away in July. You will need to migrate to a new source before then or you won't have any guide data. Sage v9 has added built in support for Schedules Direct, which is a $25/year service for guide data. So most people will be forced to upgrade to v9 and get a SD subscription by July.

That's mostly my argument for why I'm going to effectively drop support for v7. If I was still running v7 I'd at least be testing the waters with v9 now.

[jm9843]

I'm one of those people that is still using the FFmpeg consumer because the media server consumer caused issues with low bitrate standard def channels. Although I just got my letter from Comcast on the h.264 switch so I might give it another go after that happens.

Originally Posted by EnterNoEscape

The FFmpeg consumer is the most widely adaptive and the default because it's the safest bet for most people. It uses the FFmpeg libraries to remux the stream. This by default writes directly to disk, but can be told to write to the SageTV media server instead.

Is there any advantage to the latter? (FFmpeg consumer -> media server) Maybe I missed it but I didn't see anything for this option in the release notes.

[waylo]

I recently did some very quick testing with the media server, coming over from ffmpeg. It does seem to be a tad quicker, but still not very fast on my system. If I had to estimate, I think it was ~7 seconds vs. 9 seconds to get 'live' playback. I need to do more rigorous timing testing.

The mediaserver did seem to have some issues with tuning into some channels. TNT, for instance, on ffmpeg, would sometimes show a 'no signal' error for 1 second before finally playing. On mediaserver, in the same situation, was unable to display video for whatever reason. I've kept it on ffmpeg for now for that reason.

[EnterNoEscape]

Originally Posted by jm9843

Is there any advantage to the latter? (FFmpeg consumer -> media server) Maybe I missed it but I didn't see anything for this option in the release notes.

It's just faster and the files it produces are sometimes more friendly to programs like Windows Media Player. OpenDCT doesn't really take advantage of it's more interesting features like locking onto a specific ATSC stream.

[AlphaCrew]

Well, I missed 4 shows again last night for what the 'system' calls scheduling conflicts. The system has been running great for a couple of weeks..

Logs and Windows Event Information Attached.

EDIT: All shows where attached to the Ceton lineup.

[EnterNoEscape]

Originally Posted by AlphaCrew

Well, I missed 4 shows again last night for what the 'system' calls scheduling conflicts. The system has been running great for a couple of weeks..

Logs and Windows Event Information Attached.

EDIT: All shows where attached to the Ceton lineup.

I can't recall if you're still on v7. If that's the case, then what's happening is because OpenDCT will not open the communication port again until the InfiniTV devices are actually available and my best guess would be that SageTV wanted it to be available sooner and marked it as inactive. I can see in the log where it comes up, doesn't get any directions from SageTV, then is put back into standby.

I might look into identifying the network adapter that's specifically being used to talk with SageTV and as soon as that's up, the port is opened regardless of if anything else is ready yet. Then of course if SageTV issues a command other than NOOP, we won't be able to to anything with it because the associated capture device might not be available.

[AlphaCrew]

Originally Posted by EnterNoEscape

I can't recall if you're still on v7. If that's the case, then what's happening is because OpenDCT will not open the communication port again until the InfiniTV devices are actually available and my best guess would be that SageTV wanted it to be available sooner and marked it as inactive. I can see in the log where it comes up, doesn't get any directions from SageTV, then is put back into standby.

I might look into identifying the network adapter that's specifically being used to talk with SageTV and as soon as that's up, the port is opened regardless of if anything else is ready yet. Then of course if SageTV issues a command other than NOOP, we won't be able to to anything with it because the associated capture device might not be available.

Everything is version 9. OpenDCT would not work reliably at all on my installation of V7. Now that I'm on V9 It's much much better now, and until last yesterday has worked fine.

[EnterNoEscape]

Originally Posted by AlphaCrew

Everything is version 9. OpenDCT would not work reliably at all on my installation of V7. Now that I'm on V9 It's much much better now, and until last yesterday has worked fine.

Technically OpenDCT didn't do anything wrong, but I will work on getting things available more quickly in the future so at least SageTV thinks it can use it even if OpenDCT will be holding onto the request for a while.

[AlphaCrew]

Originally Posted by EnterNoEscape

Technically OpenDCT didn't do anything wrong, but I will work on getting things available more quickly in the future so at least SageTV thinks it can use it even if OpenDCT will be holding onto the request for a while.

Thanks EnterNoEscape.

[EnterNoEscape]

Originally Posted by AlphaCrew

Thanks EnterNoEscape.

No problem. There's always room for improvement. I'm working on an exciting major overhaul within the SageTV core at the moment, but I will resume working on OpenDCT likely in a month or so.