OpenDCT: An open source digital cable tuner.

[Telecore]

I build a SageTV test system, put the latest open source jar and exes with Windows 10. Have 2 sources, Avermedia Duet ATSC with 2 tuners that works and a Ceton PCIe 6. Can't get the cable video sources to show up with OpenDCT. although everything appears OK to me. Logs are attached (I hope) - any insight is appreciated.

UPDATE: didn't have network_encoder_discovery=true in sage.properties

but still not working - can't see any channels yet...

[EnterNoEscape]

Originally Posted by Telecore

I build a SageTV test system, put the latest open source jar and exes with Windows 10. Have 2 sources, Avermedia Duet ATSC with 2 tuners that works and a Ceton PCIe 6. Can't get the cable video sources to show up with OpenDCT. although everything appears OK to me. Logs are attached (I hope) - any insight is appreciated.

UPDATE: didn't have network_encoder_discovery=true in sage.properties

but still not working - can't see any channels yet...

If SageTV actually pulled in the tuner properties from OpenDCT, you will see in the log an entry that looks like [SageTVDiscovery-xx] INFO SageTVDiscovery - Sent discovery response datagram to SageTV server '/x.x.x.x:8270'.

What I would do is stop the SageTV service, check that network_encoder_discovery is still set to true in Sage.properties, then start the SageTV service again. That should be enough to get the tuners to show up as capture devices available to be added.

[EnterNoEscape]

Originally Posted by bnh

Thought i'd give this a go this afternoon. Using Ceton-Infinitv 4-tuner with cablecard, on windows 10. java 1.7.0_05. SageTV 7-licensed.

13:37:51.192 [cling-29:Ceton InfiniTV PCIe (00-80-38-6a) Tuner 2] ERROR RegisterDevice - There was a problem creating network encoders from the embedded devices on 'Ceton InfiniTV PCIe (00-80-38-6a)' with the schema 'schemas-cetoncorp-com' => org.fourthline.cling.transport.spi.InitializationException: The ConnectionManager service did not return a supported protocol.

I don't think I saw an attachment. The InfiniTV PCIe 4 devices are particularly slow and the step that it's failing on is one of the steps to make sure this is the type of device that OpenDCT thinks it is. In fact it's the first step involving direct communication after the device is discovered. This particular DCT has less than half the performance of the InfiniTV PCIe 6 and is very easy to overwhelm. What the capture device is returning is most likely HTTP error 500 which is what you get when it is being stressed. What I would recommend is making sure you don't have any other services that might be trying to access the tuner running and then try again. I have an InfiniTV PCIe 4 and I stopped seeing these issues a while ago, so I thought we had resolved it, but it looks like it can still happen. If that still fails, please wait for the next release.

Technically we check enough things that this step failing could be overlooked at initialization and in the next version I think we will do just that.

[FriscoJohn]

EnterNoEscape:

I followed your instructions (except that I didn't comment out wrapper.java.command=java--turns out one doesn't need to) and ran "OpenDCT Run As Console". This time it ran like a champ. I started the OpenDCT service and then opened SageTV, went to Setup Video Sources and clicked Add New Source and was happy to see the three OpenDCT-HDHRPrime tuner entries show up. I installed each and went to Channel Setup. I successfully previewed two different cable channels, getting both sound and picture. I thought I had it made but I then tried a third channel and the video played for a second or so in the little preview window then froze, although the sound continued. This also locked up the computer so that it wouldn't respond to any keyboard or mouse commands and I had to hold in the power switch to shut it down.

I was hoping that was a fluke so I restarted everything and tried again, same result. I made another clean start and this time tried to tune a channel from the EPG. Got a second or two of video and the picture and computer froze.

I made sure that SageDCT had cleanly uninstalled and tried again. Same result. I could preview one or two channels before everything froze up.

In sum, I had essentially the same problem with OpenDCT-SageTV7 as I had had with SageDCT-SageTV7 on my WIN10 install, although OpenDCT played a little more video before freezing.

At this point it was looking like there is just something about the combination of SageTV7 and network encoders that WIN10 doesn't like since WIN10 locks up with either SageDCT or OpenDCT. At this point I bailed on Win10 and reverted to WIN7. Fortunately Microsoft makes this easy. Just go to the Restore screen and click Return to Windows 7. (But you only have a month to do this.)

I had to reinstall OpenDCT once I was back on Win7 and I also had to reinstall Java8. Once this was done, I opened SageTV, went to Setup Video Sources>Add Video Source, reinstalled the OpenDCT tuners, and everything worked great! The tuning is faster than it was with SageDCT and OpenDCT is able to tune several channels (SD AMC, SD Fox Channel) that I couldn't turn anymore with SageDCT. (Apparently Comcast has started changing their video in the San Francisco area to H264 channel by channel.)

Bottom line, I couldn't get OpenDCT (or SageDCT) to work with Win10. OpenDCT works great on Win7 and I'm going to keep it because of its advantages over SageDCT.

Thanks so much for writing this great program and for all the hand holding you provided in getting me up and running with it.

I'm going to be very interested in hearing about other people's experiences in using OpenDCT on Win10. I am using SageTV7 (latest release) so conceivably people might have better luck with Sage Open Source.

[nyplayer]

Sagetv9, OpenDCT and the Prime in windows 10 Pro works like a champ. Have not had any problems whatsoever. All recordings play perfectly and CPU usage is real low. I even tested it with SageTV 7 and it works fine. I did not have to do any changes to any of the Config files for Java or anything else.

It is probably a firewall Issue I made sure the wrapper.exe App is added to the firewall for both public and private.

[EnterNoEscape]

FriscoJohn,

Good to hear you got things working, but I'm sure you'll want to revisit why it wasn't working well on Windows 10 some day. I agree with nyplayer about the firewall thing. It's possible that JSW was unable to determine if the JVM was running or not and kept killing it thinking it was unresponsive. I'll add wrapper.exe to the firewall exceptions during the installation in the next release. Hopefully that will help someone. If it becomes enough of an issues, I might also write some helper scripts to assist people with unexpected configurations to get things working correctly. JSW doesn't have terrific logic when it comes to finding the Java you're looking for. It basically uses whatever is in PATH.

I'm really glad to hear about the H.264 channels coming in. All of my channels are still MPEG2, so I was curious about how that experience would be. The FFmpeg implementation should be able to handle any codec that the version of FFmpeg used by JavaCPP was built to support since we just look for any video stream and any audio stream(s), then start remuxing. This is why there is a minimum probe size. If we make it any shorter, sometimes you'll get Spanish audio. The default is what Bill has been using for over 6 months, so it's considered very safe. Bill is working on making it even more resilient to getting it wrong which will potentially allow us to use a smaller probe size which translates directly into even faster channel tuning. The next minor release (0.4) should have those improvements if all goes well along with a few other new features based on some suggestions from this thread.

- Joe

[EnterNoEscape]

Version 0.3.10-beta is now available.

Changes:
*Relaxed the source protocol requirement when creating a new UPnP capture device.
*Added wrapper.exe to firewall exceptions on Windows installer.

There is nothing critical in this release unless you are currently having problems involving tuner initialization.

[bnh]

Originally Posted by EnterNoEscape

Version 0.3.10-beta is now available.

Changes:
*Relaxed the source protocol requirement when creating a new UPnP capture device.

That appears to have allowed the device to be initialized. Sage can see all four tuners.

However nothing can be tuned. i noticed dct_infinitv.properties has all the channels listed for sagetv.unavailable_channels, and nothing listed for sagetv.available_channels.

i reused the existing lineup that sagedct was using.

[nyplayer]

Originally Posted by EnterNoEscape

Version 0.3.10-beta is now available.

Changes:
*Relaxed the source protocol requirement when creating a new UPnP capture device.
*Added wrapper.exe to firewall exceptions on Windows installer.

There is nothing critical in this release unless you are currently having problems involving tuner initialization.

This is back to setting the IP to 127.0.0.1 even if I override it in the Sage properties what ever changes you made on the previous version appear to be undone by this version ... backing off to previous version as the Ip on both nics is 127.0.0.1. It does not create the sagetv.device.parent.1293650468.local_ip_override=10.0.0.13

[mechling-burgh]

Installed Opendct on the server and installed with no prorblems. Stoped SageTV services ran Opendct install then add network_encode_discover=true started sageTV service went into setup video sources added all three primes and rans great. That said I'm having one problem and I noticed it on both the sage version 7 and version 9 computers and that is the computers are not waking up to record shows now. The strange thing is, it does not show up in message log as a missed recording or conflict. I'm going to turn on full logging and see if I can find more out, but in case I was missing something simple I thought I would ask while I get better log files. If I leave the computer on all the time the shows do record without problems.

[EnterNoEscape]

Originally Posted by nyplayer

This is back to setting the IP to 127.0.0.1 even if I override it in the Sage properties what ever changes you made on the previous version appear to be undone by this version ... backing off to previous version as the Ip on both nics is 127.0.0.1. It does not create the sagetv.device.parent.1293650468.local_ip_override=10.0.0.13

I'm not sure how that regression happened I'm going to pull 0.3.10 for now.

Update: Somehow those changes hit the master, but didn't get included in the 0.3 branch. Hopefully I'll have something later today after I comb over things to make sure nothing else was missed.

[nyplayer]

Originally Posted by EnterNoEscape

I'm not sure how that regression happened I'm going to pull 0.3.10 for now.

Update: Somehow those changes hit the master, but didn't get included in the 0.3 branch. Hopefully I'll have something later today after I comb over things to make sure nothing else was missed.

Ok no Problem backed off was easy.

[FriscoJohn]

Re: My attempts to use OpenDCT with SageTV7 on WIN10 and failure thereof

I defer to NYPlayer's and the authror's expertise but I'm wondering about the firewall problem explanation because HDHR View worked fine through the firewall and OpenDCT could briefly play video in Sage and even when the video froze the sound continued, apparently ad infinitum, although I didn't listen to it that long. If it weren't getting through the firewall how could this happen?

EnterNoEscape, sorry I didn't wait for your new release before I gave up and reverted to WIN10 but I really had no compelling need to use WIN10 and was driven just by curiosity to upgrade. I understand Microsoft will continue to support WIN7 for another three years so there's not much real incentive to upgrade (except, I suppose the possibility that Microsoft could stop its free upgrade policy some time in the future). It's good though that you are developing with WIN10 in mind since sooner or later we'll all have to deal with it. By the way, OpenDCT is still working great on WIN7. Nice job!

[EnterNoEscape]

Originally Posted by nyplayer

Ok no Problem backed off was easy.

You're a great early warning system. I really appreciate the quick feedback. I verified the changes since release and this looks like it was the only change that somehow didn't get committed to the 0.3 branch.

Version 0.3.11-beta has been released. It just fixes the small, but quite significant commit fixing assigning local interfaces and allowing the selected interface to be overridden. I hope these kind of things don't become a common problem as I'm sure this time it was just human error.

[EnterNoEscape]

Originally Posted by mechling-burgh

The strange thing is, it does not show up in message log as a missed recording or conflict. I'm going to turn on full logging and see if I can find more out, but in case I was missing something simple I thought I would ask while I get better log files. If I leave the computer on all the time the shows do record without problems.

OpenDCT does log when the computer goes into standby and when it comes out. If you can post a log when it goes in and comes out of standby, I can verify that it's actually stopping the devices correctly. If it doesn't, it's possible they would continue to stream and the UDP packet storm will prevent WOL packets from working.

[EnterNoEscape]

Originally Posted by bnh

That appears to have allowed the device to be initialized. Sage can see all four tuners.

However nothing can be tuned. i noticed dct_infinitv.properties has all the channels listed for sagetv.unavailable_channels, and nothing listed for sagetv.available_channels.

i reused the existing lineup that sagedct was using.

Does dct_infinitv.properties at least contain channels? What firmware are you running on your InfiniTV 4? Also the regression I just fixed based on what I'm seeing in your logs might have fixed the issue you were having.

sagetv.available_channels isn't actually used to determine if OpenDCT will tune a channel or not. That list is there for a reference of what would be sent to SageTV if you did a channel scan. Don't update the field since it is generated based on all of the channels within the file and your changes will be immediately overwritten. At present it's only populated correctly if you enable offline channel scanning, which is considered experimental.

[nyplayer]

Originally Posted by EnterNoEscape

You're a great early warning system. I really appreciate the quick feedback. I verified the changes since release and this looks like it was the only change that somehow didn't get committed to the 0.3 branch.

Version 0.3.11-beta has been released. It just fixes the small, but quite significant commit fixing assigning local interfaces and allowing the selected interface to be overridden. I hope these kind of things don't become a common problem as I'm sure this time it was just human error.

Works as designed thank you.

[mechling-burgh]

Okay to be thick where are the OpenDCT logs I can't find them. I also realized I forgot to remove the Prime Encoder java loader which I will do once I get my kids off the sage. I was just going through the sage.properties and noticed that the DCT has the locale look up (127.0.0.1) and it also picked up the test computer (192.168.2.60). Should the network_encoder_discovery be set to false after the first install? I will also remove the extra tuners when I fix the java loader.

[nyplayer]

Originally Posted by mechling-burgh

Okay to be thick where are the OpenDCT logs I can't find them. I also realized I forgot to remove the Prime Encoder java loader which I will do once I get my kids off the sage. I was just going through the sage.properties and noticed that the DCT has the locale look up (127.0.0.1) and it also picked up the test computer (192.168.2.60). Should the network_encoder_discovery be set to false after the first install? I will also remove the extra tuners when I fix the java loader.

if using windows 7 and later the logs are in c:\programdata. Setup the tuners with with 127.0.0.1 make sure you have the 3.11 Beta just released. There is a property to Ignore tuners I have not used it yet.

[bnh]

Originally Posted by EnterNoEscape

Does dct_infinitv.properties at least contain channels? What firmware are you running on your InfiniTV 4? Also the regression I just fixed based on what I'm seeing in your logs might have fixed the issue you were having.

same behaviour with the 3.11beta.

Yes, dct_infinitv.properties does contain channels. it looks complete for what i have access to.

Ceton Infinitv Firmware Version: 1.1.7.2
Diagnostic tool says both driver and firmware are up to date.