OpenDCT: An open source digital cable tuner.

[Fuzzy]

Is there some java 1.8 feature you are wanting to use? If not, I'd just stick with 1.7 as a min-version.

[Daweeze]

Wow, web interface looks great! OpenDCT has worked great for the last few days for us. I can confirm better than SageDCT was. I have had only 1 halt but it is signal based. For some reason Food Network is pixelated in recordings every 5-10 seconds. I will have to look at the HDHomeRun Prime Web Interface to see the signal/quality for that band/channel. Is there any way the OpenDCT web GUI would be able to provide any channel signal/quality feedback from the HDHR units? I remember there used to be a Signal Quality Plug-In for OTA in SageTV....

Great work, WAF is really high with this release. Channels had been locking up in the middle of watching randomly before OpenDCT and it was getting annoying.

Also, will there be a way to see the Channel Mapping for the Tuner Lineups?

Thanks again,

-Travis

[jm9843]

0.3.14-beta installed and early results are good. Easy installation, the only thing that I ran into is that Logitech Media Server (i.e. Squeezebox) uses port 9000 by default. It was easiest to change what it's using and give OpenDCT 9000.

One question: does the tuner property 'encode_digital_tv_as_program_stream' have any effect with OpenDCT?

[EnterNoEscape]

Originally Posted by Fuzzy

Is there some java 1.8 feature you are wanting to use? If not, I'd just stick with 1.7 as a min-version.

The problem isn't my own preference. The problem is that the latest Jetty requires 1.8.

[EnterNoEscape]

Originally Posted by Daweeze

Is there any way the OpenDCT web GUI would be able to provide any channel signal/quality feedback from the HDHR units? I remember there used to be a Signal Quality Plug-In for OTA in SageTV....

Great work, WAF is really high with this release. Channels had been locking up in the middle of watching randomly before OpenDCT and it was getting annoying.

Also, will there be a way to see the Channel Mapping for the Tuner Lineups?

Thanks again,

-Travis

The web interface on the Dashboard that you didn't see actually does show the filename, channel, signal and copy protection status. I attached an example of what that looks like. I'm not completely happy with the appearance of the dashboard and it will probably change but for now it's acceptable since it provides the majority of "at a glance" information most people would be interested in.

The Lineups tab in the web interface will allow you to completely view, edit and create lineups. The work on that tab has not started yet, so I don't have anything to show you. At present, the best you could do is try to decipher the properties files under lineups in the configuration folder which likely isn't going to be worth it.

The web pages are generated completely in JavaScript with a minimal framework provided by static HTML. Everything you see was populated from JSON provided by the OpenDCT web server. Technically the web page you see doesn't even need to be served from OpenDCT itself. You could actually have the website itself running out of Jetty on SageTV and just point it to the server hosting OpenDCT as it's data source. This allows for trivial design of custom applications for people who would like to display/edit information somewhere else.

[EnterNoEscape]

Originally Posted by jm9843

0.3.14-beta installed and early results are good. Easy installation, the only thing that I ran into is that Logitech Media Server (i.e. Squeezebox) uses port 9000 by default. It was easiest to change what it's using and give OpenDCT 9000.

One question: does the tuner property 'encode_digital_tv_as_program_stream' have any effect with OpenDCT?

Good to know about the port, maybe we will change the default in the future. Since that actually sounds like it might be a commonly used port for some people. If you remove all of your sagetv.device entries and change sagetv.new.device.socket_server_shared_port to another port they will all be automatically re-generated with the new port. Or you can just change sagetv.device.<encoder_id>.encoder_listen_port for each tuner to whatever you would rather they use. They can share the same port which is the default or you can give each one it's own port.

That property will not do anything useful in regards to OpenDCT. OpenDCT should only create .ts files. We do not currently have any plans to support creating program streams in addition to transport streams.

[KryptoNyte]

That web interface ... that's nice stuff.

[EnterNoEscape]

Originally Posted by KryptoNyte

That web interface ... that's nice stuff.

Thanks. A lot of the style is thanks to bootstrap, but I did have a reasonable hand in the color scheming. I modeled it after the SageTV web interface. Another advantage to using bootstrap is the interface is implicitly mobile friendly. I was looking at it on my cell phone and it's surprisingly usable despite the fact that I have been developing using a Chrome browser.

[KryptoNyte]

A few quick ones;

1) Will OpenDCT run under Java Version 6? I'm not sure that I'm reading the comment correctly about using Version 7 at a minimum (or is it version 7 at a maximum?).

2) Are you or any other tester currently using both a Prime and a Pcie based Ceton tuner on the same machine (with cablecard in a all devices)? Are there any additional challenges here regarding the installation?

3) Regarding the testing with the Prime's ... because I still have a couple on a very old firmware (you can't revert these darn things) - has anyone tested OpenDCT on old firmware?

[KryptoNyte]

Which device typically tunes faster, the Prime, or the pcie Ceton tuner?

[EnterNoEscape]

Originally Posted by KryptoNyte

A few quick ones;

1) Will OpenDCT run under Java Version 6? I'm not sure that I'm reading the comment correctly about using Version 7 at a minimum (or is it version 7 at a maximum?).

2) Are you or any other tester currently using both a Prime and a Pcie based Ceton tuner on the same machine (with cablecard in a all devices)? Are there any additional challenges here regarding the installation?

3) Regarding the testing with the Prime's ... because I still have a couple on a very old firmware (you can't revert these darn things) - has anyone tested OpenDCT on old firmware?

1) It will not. You must have 1.7 or greater installed and it looks like down the road, we will need to use 1.8 or you won't be able to use the web interface. I will continue to compile for 1.7, but once we get to version 1.0, you will start to be unable to use anything related to Jetty.

2) My production configuration is InfiniTV 6 PCIe with CableCARD, plus an HDHomeRun original doing clear QAM. My test server is using an InfiniTV 4 PCIe without a CableCARD (clear QAM), an InfiniTV 6 PCIe with a CableCARD and an HDHomeRun Prime without a CableCARD. I occasionally swap the CableCARD between the Prime and InfiniTV 6 when I need to verify something. There are no complications or additional configuration considerations when using a mix of devices. Every device uses a 7MB circular buffer if using FFmpeg (it can't be any smaller than 6MB due to how much data it can require to be able to start streaming), so RAM might be a consideration if you go completely nuts. I do load testing by scheduling and watching recordings across all of these devices simultaneously. I then start and stop the SageTV server a few times since that's typically when things can get the most crazy if they are going to break. Below are some notes of interest about my observations with each device.

InfiniTV 4: This thing is very slow and not supported by Ceton anymore. 800ms average tuning time. Also even without a CableCARD present, it can falsely detect copy protection on an unencrypted channel and will shut the stream down after about a second of streaming. Based on my experiences, I do not recommend anyone buying one of these with the intention to use it for clear QAM. If you happen to have an extra laying around, it's a good secondary use and I'd just remove any channels that it can tune, but have copy protection problems. It's strange that the card would impose an artificial restriction that it is not required to honor.

InfiniTV 6: This card has been very reliable. 90ms average tuning time. In my limited clear QAM testing, I didn't run into the copy protection issues the InfiniTV 4 has. I personally haven't seen any issues, but I've heard this card requires better than passive cooling or it will not run reliably.

Prime: I can see why so many people like this tuner. It reminds me why Silicondust is the only manufacturer that I recommend for most setups. 15ms average tuning time. If they made a 6 tuner version that only needed one CableCARD I would have been completely sold from the start (CableCARD's are not free and my wife likes to record a lot of TV). I've owned this one for only a month, but I can say it is very fast and reliable as a clear QAM device and a digital cable tuner. Tuning performance is identical in both modes.

One more note: Clear QAM on the Prime can only be accomplished in an automatic way via either having an InfiniTV device to pull a lineup from (which includes frequencies and programs) or by letting OpenDCT find a tuner not in use on a device that has a CableCARD, tune the channel the normal way, then get the program and frequency that way. The latter is disabled by default because most people would not expect OpenDCT to be talking to a tuner that SageTV did not actually request.

3) Someone else will need to weigh in here. I always keep my devices mostly up to date. The only thing I can think of that you might run into is the UPnP filter skipping your older device because it doesn't know what it is. That can be fixed in the properties if you run into it. We'd just need to take a quick look at the logs.

Originally Posted by KryptoNyte

Which device typically tunes faster, the Prime, or the pcie Ceton tuner?

The Prime is by far the fastest in all regards, but that's all relative since you'll never notice unless you watch a lot of live TV. They all under the worst possible scenario (which is InfiniTV ClearQAM if anyone wants to know) never exceed 1 second to actually tune the channel. The rest of the streaming process is typically less than 2 seconds of processing before SageTV starts playback. As some people have noted, tune is often less than 2 seconds in total when using FFmpeg (which is the default).

[EnterNoEscape]

0.3.15-Stable has been released. This was built on 0.3.14-Beta, so there is no urgency/benefit to upgrading to this version as it is just a milestone. 0.3 is now set in stone. There will be no new features and it will be considered to be the version to use if you want the most stable version without the latest features. There will only be updates if any horrible problems are discovered and 0.4 has not yet reach a "stable" state.

0.4 has been undergoing internal testing and if we don't discover any new issues this week, it will become available for download.

[KryptoNyte]

Thank you for your thorough responses. Clearly you've dedicated significant time in this endeavor!

Someday down the road, do you anticipate your [tuner] web interface to entirely replace the web interface we have right now? I see you're going to leave 0.3.15 as the last Java 1.7 release, and then with 0.4 require Java 1.8, I guess that would kill the current web interface, as I understand it?

[nyplayer]

Originally Posted by KryptoNyte

Thank you for your thorough responses. Clearly you've dedicated significant time in this endeavor!

Someday down the road, do you anticipate your [tuner] web interface to entirely replace the web interface we have right now? I see you're going to leave 0.3.15 as the last Java 1.7 release, and then with 0.4 require Java 1.8, I guess that would kill the current web interface, as I understand it?

If the future of OpenDCt is Java 1.8 and it breaks the SageTV Web Server I can see this being a problem. I rely a lot on the SageTV webserver for backups and other important things.

[Telecore]

Sorry to change the subject - I made another attempt to get OpenDCT to work, this time using version 0.3.15 with Win10 and SageTV V9, Ceton PCIe 6 and co-existing with SageDCT. SageDCT channels work. I mapped one channel exclusively to OpenDCT. Still no signal when tuned, but the attached logs may be more useful than what I posted before. Any input is appreciated - thanks.

[EnterNoEscape]

Originally Posted by KryptoNyte

Thank you for your thorough responses. Clearly you've dedicated significant time in this endeavor!

Someday down the road, do you anticipate your [tuner] web interface to entirely replace the web interface we have right now? I see you're going to leave 0.3.15 as the last Java 1.7 release, and then with 0.4 require Java 1.8, I guess that would kill the current web interface, as I understand it?

I was thinking someone might ask that, but I really don't think I want to take the reigns on such an iconic feature and I really don't consider myself to be a great UI designer. It's twice the work to be programming and writing the HTML/JavaScript since you're really designing two web sites. One to create/retrieve/modify/delete data and the other to display/manipulate that data. Even if you're building the entire page in Java and sending it to the browser mostly rendered like the current interface, you still have about the same amount of work plus an API. Because of this, I don't think I will be able to put in the time and effort that it deserves and there isn't enough that I would change about it to motivate me to actually do it.

Don't worry about the Java 1.8 requirement until we hit 1.0 which will be the release that uses web interface and even then the interface will remain optional (allowing for people to still use 1.7). The web interface will not exist until then. I am just trying to keep the word out so people have it in the back of their mind. There are talks in the forums about updating Jetty to the latest for SageTV v9, so a complete Jetty upgrade for SageTV is probably not too far (maybe late this year?) away from actually happening. From what I understand the biggest breakage people should see if upgrading to 1.8 is parts of the web interface. I could use an older unsupported version on Jetty, but I will only resort to that if the backlash is tremendous.

[EnterNoEscape]

Originally Posted by Telecore

Sorry to change the subject - I made another attempt to get OpenDCT to work, this time using version 0.3.15 with Win10 and SageTV V9, Ceton PCIe 6 and co-existing with SageDCT. SageDCT channels work. I mapped one channel exclusively to OpenDCT. Still no signal when tuned, but the attached logs may be more useful than what I posted before. Any input is appreciated - thanks.

It's very unclear to me how SageDCT could possibly be working with that data unless it's running in raw mode. FFmpeg complains about the packets, but does eventually figure out what's going on, then after that it continues to try and seek within the stream for an unknown reason. The continued seeking is very troublesome since we never see that in normal use. Your log is the very first time I have seen that happen. The only thought I have is to try to increase the FFmpeg read/write buffer size. Change consumer.ffmpeg.rw_buffer_size to 32768. You can try larger values too if you want. Make sure you stop the OpenDCT service before you make the change, then start it back up again.

[Telecore]

Thanks for the suggestion - tried 65536 but it still doesn't work. I also uninstalled OpenDCT 32 bit, installed 64 bit Java, and tried OpenDCT 64 bit, but same result. At least now I have a way of trying OpenDCT without removing SageDCT and re-doing channel lineups. I am a bit confused because I definitely have SageDCT operating in FFMPEG mode.

[EnterNoEscape]

I'll have some versions just for you to test out hopefully soon. We just haven't seen that behavior. I need to re-write a part of the circular buffer to accommodate your situation. This is not a small undertaking. I wrote our buffer from scratch because the only ones I could find didn't have a license compatible with the project.

[crawfofd]

I am trying to get the openDCT to work with my Ceton 6 PCIe card.

This is my setup; SageTV9 OS, HDhomerun Prime, Ceton 6 PCIe, Windows 7 64, 16g mem. I'm using the lastest openDCT and Ceton Drivers. Using 32bit for Java and openDCT.

The Hdhomerun Prime is working perfectly,

The Ceton when I tune to it takes for ever to tune and is highly pixelated (Unusable). I ran openDCT in console mode to see what was happening and I get constant warnings:
ffmpeg - [mpegts @ 0a0a2500] PES Packet size mismatch

Any help would be greatly appreciated. If you need a log file, let me know which one and I will send it.

Just wanted to let you know your work is greatly appreciated. Thanks