OpenDCT: An open source digital cable tuner.

[jhkoenig]

Originally Posted by KryptoNyte

To clarify, you're using the HDHR Premium TV service in Sage via OpenDCT. You had problems with playback on files with odd framerates (on what playback devices?). You changed OpenDCT to run all media through ffmpeg in OpenDCT, and in doing so, comskip doesn't work anymore?

Oops, my bad. Your re-cap is correct, except that I was capturing CABLE streams using my HDHR via OpenDCT, rather than PREMIUM TV streams. Sorry for the confusion. The failure mode wasn't 100% (~40% without detectable pattern), but seemed to focus on HGTV shows that were particularly dear to my wife.

[KryptoNyte]

Originally Posted by EnterNoEscape

Certainly, you just need to change to the raw consumer. Change opendct.consumer.FFmpegTransSageTVConsumerImpl to opendct.consumer.RawSageTVConsumerImpl in the config file.

The buffer was already set to the suggested value, so I left that alone. I went ahead and made the change to use Raw. Channel tuning is still 10 to 12 seconds. Is it possible that the delays implemented for Ceton devices, or tuning twice (as I recall) to ensure channel changes for Ceton is affecting tuning times?

It's also possible I'm using a fairly old version of OpenDCT ...

[KryptoNyte]

Originally Posted by jhkoenig

Oops, my bad. Your re-cap is correct, except that I was capturing CABLE streams using my HDHR via OpenDCT, rather than PREMIUM TV streams. Sorry for the confusion. The failure mode wasn't 100% (~40% without detectable pattern), but seemed to focus on HGTV shows that were particularly dear to my wife.

Okay. I'm not sure how much longer the Premium TV service will be around. Entering television services has been a pretty rocky start for Silicondust.

When I was using a cablecard with HDHR primes and OpenDCT, I never had an issue with comskip (passing files thru ffmpeg). Well, of course there are some programs where it struggles to score commercials vs. show, but that's more in the comskip algorithm tuning I suppose.

[KryptoNyte]

From the logs, it appears I'm on OpenDCT 0.5.8

Would that be a problem?

[EnterNoEscape]

Originally Posted by KryptoNyte

The buffer was already set to the suggested value, so I left that alone. I went ahead and made the change to use Raw. Channel tuning is still 10 to 12 seconds. Is it possible that the delays implemented for Ceton devices, or tuning twice (as I recall) to ensure channel changes for Ceton is affecting tuning times?

It's also possible I'm using a fairly old version of OpenDCT ...

Sorry, I gave you the default value without a lot of details. I meant that you could half that or quarter it.

You can always try upgrading, but I don't think that the version you're on (0.5.8) was a particularly problematic version.

[KryptoNyte]

Originally Posted by EnterNoEscape

Sorry, I gave you the default value without a lot of details. I meant that you could half that or quarter it.

You can always try upgrading, but I don't think that the version you're on (0.5.8) was a particularly problematic version.

Thank you. I'll give it a shot. If I have time over the coming month, I probably need to migrate to the 64bit version of Sage. I have a feeling that would clean up a lot of old problems. Lot's of spinning circles these days, and with the Premium TV service in such bad shape, I've found that a tuner that can't tune a channel or stream properly brings the entire SageTV service to it's knees.

[tmiranda]

Originally Posted by KryptoNyte

I've found that a tuner that can't tune a channel or stream properly brings the entire SageTV service to it's knees.

This always has bothered me. If a tuner is having problems my system, including the UI, comes to a screeching halt.

[EnterNoEscape]

Originally Posted by tmiranda

This always has bothered me. If a tuner is having problems my system, including the UI, comes to a screeching halt.

As I understand it, this is due in part to interdependencies in the SageTV code that rely on responsiveness of tuners currently configured. There are certain UI
API calls that ultimately will trigger a "ping" to network encoders for example.

[clu]

I have 9 tuners (3 HDHomeRun prime and 6 Ceton). I'm not quite sure what pooling does, I do have it enabled. I would think that a new tuner would be used changing channels to make going back to the previous channel faster.

Currently the same tuner is being used unless when recording a show, then a new tuner will be used.

For some reason ESPNHD takes a very long time. I even get the "No Signal" and after another 6-10 sec it finally shows up.

Attached my opendct.properties. Appreciate any help/suggestions if I have some setting that make it slow.

Is the tuning performance HDHomerun/Ceton about the same? Tuning performance is more important to me than number of tuners.

[BobbyDing]

Hi, what are the chances of openDCT working with this software (link below) to record iptv channels? It emulates an HDHR tuner. I don't think it responds to standard HDHR queries to find tuners (so Sage and openDCT don't see it on the network), but if your able to manually enter the IP:PORT, it does work. It already works with Emby and Plex as an HDHR tuner or via m3u.

https://xteve.de/

Thanks!

Bobby

[egeller]

Originally Posted by BobbyDing

Hi, what are the chances of openDCT working with this software (link below) to record iptv channels? It emulates an HDHR tuner. I don't think it responds to standard HDHR queries to find tuners (so Sage and openDCT don't see it on the network), but if your able to manually enter the IP:PORT, it does work. It already works with Emby and Plex as an HDHR tuner or via m3u.

https://xteve.de/

Thanks!

Bobby

If it supports a playlist that is a URL, with the channel number as part of the URL, then YES you can get it working with OpenDCT. You pass the channel number as a %c% variable on the URL you configure in OpenDCT.

I did something similar as a proof-of-concept with IPTV. I ran TVHeadend (TVH) to access IPTV and accessed channels in Sage via a playlist that came from TVH.

It was a lot of setup to get the EPG set up in TVH. It was also a lot of work to maintain, as channels were changing in IPTV. At one point I was working on exporting the EPG data from TVH to SageTV, but decided not to pursue that. It required more time than I wanted to spend on it and the IPTV service was not reliable enough to use Sage, so I used TVH as a DVR / recorder.

[tmiranda]

I upgraded my Ubuntu system to 19.04 and it broke opendct Whenever I tune a channel the first second is OK and then it stutters and is unwatchable. I've attached a logfile.

I tried changing the "use_http_tuning" setting to false and that made no difference.

Nothing else was changed other than "upgrading" Ubuntu. (If it isn't broken, fix it until it is.)

Thanks for any help.

[EnterNoEscape]

Originally Posted by tmiranda

I upgraded my Ubuntu system to 19.04 and it broke opendct Whenever I tune a channel the first second is OK and then it stutters and is unwatchable. I've attached a logfile.

I tried changing the "use_http_tuning" setting to false and that made no difference.

Nothing else was changed other than "upgrading" Ubuntu. (If it isn't broken, fix it until it is.)

Thanks for any help.

As you might have guessed I was going to say, I don't see anything in the logs that would make me think there are issues with the stream other than your reported experience. I don't see FFmpeg displaying codec errors in the steam. Is this issue true for both live and pre-recorded? Maybe the filesystem is under-performing post upgrade? Didn't you go through something like this several months ago?

[tmiranda]

Originally Posted by EnterNoEscape

As you might have guessed I was going to say, I don't see anything in the logs that would make me think there are issues with the stream other than your reported experience. I don't see FFmpeg displaying codec errors in the steam. Is this issue true for both live and pre-recorded? Maybe the filesystem is under-performing post upgrade? Didn't you go through something like this several months ago?

It happens live and recorded. No difference.

My issues months ago ended up being network related. I mistakenly thought it was the file system but it ended up being a marginal CAT5e cable. When I replaced the cable everything worked flawlessly.

This new issue manifests itself just like the previous issue which makes me think it's something related to the networking. I haven't had much time to debug but that's the direction I will look.

I've already turned off automatic updates, something I should have done sooner

[trk2]

Originally Posted by tmiranda

It happens live and recorded. No difference.

My issues months ago ended up being network related. I mistakenly thought it was the file system but it ended up being a marginal CAT5e cable. When I replaced the cable everything worked flawlessly.

This new issue manifests itself just like the previous issue which makes me think it's something related to the networking. I haven't had much time to debug but that's the direction I will look.

I've already turned off automatic updates, something I should have done sooner

Do you have anything recorded from before the upgrade that you know recorded and played properly? You can try playing back a known good file and see if the issue is present. That would help determine if it is at all related to OpenDCT.

[tmiranda]

Originally Posted by trk2

Do you have anything recorded from before the upgrade that you know recorded and played properly? You can try playing back a known good file and see if the issue is present. That would help determine if it is at all related to OpenDCT.

Everything that was recorded before the upgrade plays fine.

[tmiranda]

Originally Posted by tmiranda

Everything that was recorded before the upgrade plays fine.

Finally debugged this. The culprit was a bad network cable What are the odds of a cable going bad at the same time an upgrade is done? I think I'm going to buy a lottery ticket.

[EnterNoEscape]

Originally Posted by tmiranda

Finally debugged this. The culprit was a bad network cable What are the odds of a cable going bad at the same time an upgrade is done? I think I'm going to buy a lottery ticket.

Is the cable under some tension? Maybe your NIC or switch are somehow frying the cable. Either way, that's some crazy luck.

[tmiranda]

Originally Posted by EnterNoEscape

Is the cable under some tension? Maybe your NIC or switch are somehow frying the cable. Either way, that's some crazy luck.

I'm wondering if it's the switch going bad. I had another "cable" go bad and fixed it by plugging a new cable into another port on the switch. I did the same thing on this bad "cable", plugged a new cable into a different port. I'll have to look at the switch in more detail.

Another possibility is that the NIC is frying the switch. Two bad cables on one machine may not be a coincidence.

[wnjj]

Originally Posted by tmiranda

I'm wondering if it's the switch going bad. I had another "cable" go bad and fixed it by plugging a new cable into another port on the switch. I did the same thing on this bad "cable", plugged a new cable into a different port. I'll have to look at the switch in more detail.

Another possibility is that the NIC is frying the switch. Two bad cables on one machine may not be a coincidence.

Since cables are just wire and the switch is a bunch of electronics my vote is the switch or NIC.