OpenDCT: An open source digital cable tuner.

[waylo]

Can you speak a little more on when running the console is needed? Is it only with the initial install? What about when we start with a brand new .properties file?

[EnterNoEscape]

Originally Posted by waylo

Can you speak a little more on when running the console is needed? Is it only with the initial install? What about when we start with a brand new .properties file?

Running the console is really only recommended the very first time you ever use OpenDCT on a computer. It will give you some immediate feedback if it doesn't like for example the version of Java you're running. Other than that, there's no difference between starting the service, then stopping it.

Once we move over to the (becoming mythical) web interface, the console shortcut will go away.

[stanger89]

Originally Posted by EnterNoEscape

That's very interesting. Everything did exactly what it was supposed to and the HDHomeRun refused to tune in the channels it claims to have. What happens when you put http://192.168.0.8:5004/auto/v885 into a browser? Does it start downloading? Maybe you're running an older firmware? Also the fall back to RTP using the virtual channel 885 failed which is extra odd. I can understand that maybe the URL doesn't work, but the virtual channel not working is very perplexing.

That URL opens fine (and plays) in VLC.

[EnterNoEscape]

Originally Posted by stanger89

That URL opens fine (and plays) in VLC.

That's a good start. Make sure your firmware is completely up to date. The version I'm on is from August of last year. The firmware that I'm on will allow me to tell it what tuner I want to use. I can replace auto with tuner0 for example.

[stanger89]

Originally Posted by EnterNoEscape

That's a good start. Make sure your firmware is completely up to date. The version I'm on is from August of last year. The firmware that I'm on will allow me to tell it what tuner I want to use. I can replace auto with tuner0 for example.

Can't say it's the latest, but it looks like a similar firmware to what you're running 20150826.

And I tried and I can play a "tuner0" URL with VLC as well.

[nyplayer]

Originally Posted by stanger89

Can't say it's the latest, but it looks like a similar firmware to what you're running 20150826.

And I tried and I can play a "tuner0" URL with VLC as well.

Talking about firmware for the HdHomeruns I am up to 20160328atest2 and I have not had any halts since keeping current. I cannot even remember the last time I had a halt detected. I keep updating because I am using the HDHomerun DVR.... and there have been a lot of improvements to the HDHomerun streams.

[stanger89]

Well I've been in an "if it ain't broke, don't fix it" mentality, I don't "need" OpenDCT as all my stations are ClearQAM, but I am interested if it's ffmpeg remuxing can fix some issues I have with recordings Sage doesn't like. I'm not having halts or anything.

[waylo]

I've inquired on the Silicon Dust forums if there's any harm for us regular HDHR users (without their DVR) to upgrade. The response was that aside from the fact you cannot downgrade, there were no known issues.

https://www.silicondust.com/forum/vi...207547#p207547

I personally am still on the 8/2015 one and will sit on it until there are more benefits.

[Toddly]

[QUOTE=EnterNoEscape;587772]You have an interesting, but likely permissions or disk space related issue. Every time OpenDCT tries to create a new file for a recording, I see something like this:

ERROR FFmpegSageTVConsumerImpl - Unable to create the recording file '\\Nacho\H\G3Sportsman-GatorGarFishing-21210612-1.ts'.

My speculation is that the .mpgbuf file used for channel previews is working because the file already exists and is fully allocated (it's a circular buffer basically). Are you running the OpenDCT service under an account that actually has network access?

I have been using the same drives using SageDCT before I moved to OpenDCT. I did recheck and adjust permissions for the drives for all users with full control. My machine logs in automatically as an Administrator and that is how I install the programs.

Do you think it may be a Sage issue or maybe reinstall OpenDCT using a newer version to rewrite the program. I could blow it out and start over as this is getting frustrating.

[EnterNoEscape]

Originally Posted by stanger89

Can't say it's the latest, but it looks like a similar firmware to what you're running 20150826.

And I tried and I can play a "tuner0" URL with VLC as well.

This doesn't make any sense. You're running the exact same firmware as me and yet I haven't seen this happen once on my setup without the URL being completely wrong or the virtual channel actually not existing.

There's only one more thing that I can think of for you to try. Change sagetv.device.parent.<parent_id>.http.producer to opendct.producer.HTTPProducerImpl in opendct.properties.

[EnterNoEscape]

Originally Posted by Toddly

I have been using the same drives using SageDCT before I moved to OpenDCT. I did recheck and adjust permissions for the drives for all users with full control. My machine logs in automatically as an Administrator and that is how I install the programs.

Do you think it may be a Sage issue or maybe reinstall OpenDCT using a newer version to rewrite the program. I could blow it out and start over as this is getting frustrating.

What really matters is what account the OpenDCT service is running under. If the account the service is running under doesn't have proper permissions to access the network share that you're using, you'll have all kinds of problems. By default the OpenDCT service is installed using the built in local system account which won't use the same credentials as your administrator account. This should have been true for your SageDCT install too.

Just to verify that it's related to permissions on the network share, try changing your recording directory to a local path on the server and see if it will successfully start a recording to that location.

To change the account being used by OpenDCT, you need to do the following:
1) Click on the start menu.
2) Type services.msc
3) Press Enter.
4) Find SageTV OpenDCT in the list of services.
5) Double-click on it.
6) Change the radio button from Local system account to This account:
7) Enter your user credentials that you use to access the network share.
8) Click OK
9) Right-click on the OpenDCT service and restart it.

Also I noticed that you're on the older consumer, try installing the latest version of OpenDCT 0.4 stable. It will upgrade you to the newer one that works a little better in many regards.

[Telecore]

I've had a couple of incidents over the last few days with version 4.48 where openDCT could not tune any channels. During the last 2 upgrades I have deleted the config file in order to ensure that I have the latest defaults/parameters. I've reverted to 4.47 in the meantime - log file is attached.

[EnterNoEscape]

Originally Posted by Telecore

I've had a couple of incidents over the last few days with version 4.48 where openDCT could not tune any channels. During the last 2 upgrades I have deleted the config file in order to ensure that I have the latest defaults/parameters. I've reverted to 4.47 in the meantime - log file is attached.

The part that failed could also fail in any version. The issue is with the Cling UPnP library. I noticed that sometimes it just continues to block the port it's using even after it is shutdown. What's happening is when you're resuming it can't open the port, so it removes network adapter (also not a good thing). If we didn't need that interface, this would be fine, but I have yet to see a situation whereby this actually works without org.fourthline.cling.transport.impl.NetworkAddressFactoryImpl$2.synchronizedRemove(NetworkAddressFactoryImpl.java:160) throwing an exception.


I'll need to go through the Cling library and patch this one up as I'm sure this is the first time you've seen it, but it will probably happen to someone else eventually too. I guess I'm just surprised the project didn't already see this one and fix it.

[CptKirk]

Nyplayer mentioned he was using 20160328atest2. I figured it wouldn't hurt to give it a try so I updated from 20150826 to 20160328atest2 as well.

Downloaded the 20160419atest1 (it flashes 20160328atest2 on the HDHR).

You can browse through the 3 pages of the changelog and see what's been updated. 20160321atest1 and 20160328atest2 is where they call out specific changes to the HDHomeRun Firmware.

HDHomeRun Tuner Firmware: (20160321atest1)
* Report audio and video codec types in lineup json.
* Report ONID and TSID in lineup json when tuning information is requested.
* Report tuner count in discover json.
* Detect and report if h.264 channels are SD or HD.
* Support using a secondary DNS server delivered via DHCP.
* ClearQAM: Favor HD over SD channels when a virtual channel number conflict is detected.
* CableCARD: Fix problem where card firmware error message was not displayed.
* DVB-T/C: Fix possible false-positive detection of MPEG2 video.
* Improvements to compatibility with non-compliant DLNA clients.
* Improvements to diagnostic logging.

HDHomeRun Firmware: (20160328atest2)
* Fix possible crash running channel scan.

I had been getting 2 to 3 halts every day. So far on the 20160328atest2 I've not had a single halt error in 2 days. Looks promising, keeping my fingers crossed.

[troll5501]

I haven't posted for awhile, so I just wanted to give a quick update. I've been running 0.4.47 for the last 10 days and it's been rock solid. I haven't had any recording failures or hiccups that I've noticed, and I've had live TV running 24x7 on one (and often two) extenders along with my normal scheduled recordings every day. I've even had Music Choice streaming successfully non-stop for the last 72 hours!

I'm going to upgrade to 0.4.48 and give it a short test before moving up to 0.5.x. Thanks again for all of the great work on OpenDCT!

[Telecore]

Originally Posted by EnterNoEscape

The part that failed could also fail in any version. The issue is with the Cling UPnP library. I noticed that sometimes it just continues to block the port it's using even after it is shutdown. What's happening is when you're resuming it can't open the port, so it removes network adapter (also not a good thing). If we didn't need that interface, this would be fine, but I have yet to see a situation whereby this actually works without org.fourthline.cling.transport.impl.NetworkAddressFactoryImpl$2.synchronizedRemove(NetworkAddressFactoryImpl.java:160) throwing an exception.


I'll need to go through the Cling library and patch this one up as I'm sure this is the first time you've seen it, but it will probably happen to someone else eventually too. I guess I'm just surprised the project didn't already see this one and fix it.

Thanks, good to know. I will go back to the latest 4.48 and just keep an eye out for this problem. The bad thing is that when it happens I can't tune anything at all and I end up rebooting to fix. This week it happened twice within the last 4-5 days. I appreciate your persistance - thanks for all the hard work on this.

[Toddly]

Originally Posted by EnterNoEscape

What really matters is what account the OpenDCT service is running under. If the account the service is running under doesn't have proper permissions to access the network share that you're using, you'll have all kinds of problems. By default the OpenDCT service is installed using the built in local system account which won't use the same credentials as your administrator account. This should have been true for your SageDCT install too.

Just to verify that it's related to permissions on the network share, try changing your recording directory to a local path on the server and see if it will successfully start a recording to that location.

To change the account being used by OpenDCT, you need to do the following:
1) Click on the start menu.
2) Type services.msc
3) Press Enter.
4) Find SageTV OpenDCT in the list of services.
5) Double-click on it.
6) Change the radio button from Local system account to This account:
7) Enter your user credentials that you use to access the network share.
8) Click OK
9) Right-click on the OpenDCT service and restart it.

Also I noticed that you're on the older consumer, try installing the latest version of OpenDCT 0.4 stable. It will upgrade you to the newer one that works a little better in many regards.

I got it working changing the account credentials. It has never been a problem before but I am now running Win 10. Gonna upgrade to the next version later today. Thanks for your assistance.

[EnterNoEscape]

Originally Posted by Telecore

Thanks, good to know. I will go back to the latest 4.48 and just keep an eye out for this problem. The bad thing is that when it happens I can't tune anything at all and I end up rebooting to fix. This week it happened twice within the last 4-5 days. I appreciate your persistance - thanks for all the hard work on this.

I can see how the correlation would lead you to think something was changed in the new version. I am 99% certain that the newer version isn't more prone to this issue mostly because none of the changes made were anywhere near the classes that influence this piece.

Edit: I am actually taking a close look at this one right now to see if I can make it any better. This isn't a recommendation, but in 0.5 this situation is a lot less likely since the detection process only runs to find the capture devices, then stops which should greatly reduce the changes of the socket not being closed before the next request.

[EnterNoEscape]

Originally Posted by EnterNoEscape

I can see how the correlation would lead you to think something was changed in the new version. I am 99% certain that the newer version isn't more prone to this issue mostly because none of the changes made were anywhere near the classes that influence this piece.

Edit: I am actually taking a close look at this one right now to see if I can make it any better. This isn't a recommendation, but in 0.5 this situation is a lot less likely since the detection process only runs to find the capture devices, then stops which should greatly reduce the changes of the socket not being closed before the next request.

I thought I saw an opportunity for improvement the last time I looked at this, but actually the logic that's supposed to close up everything in use is fairly solid. I have seen this before whereby the port even though it has been "closed," it ends up not freeing the port that was used until the receiver is garbage collected. You should be able to positively circumvent this problem by changing the value of upnp.service.configuration.http_listen_port to 0 in opendct.properties. Basically 0 tells it to pick any available port. The reason I added the static port was so one would be able to use a static firewall configuration.

[EnterNoEscape]

Originally Posted by troll5501

I haven't posted for awhile, so I just wanted to give a quick update. I've been running 0.4.47 for the last 10 days and it's been rock solid. I haven't had any recording failures or hiccups that I've noticed, and I've had live TV running 24x7 on one (and often two) extenders along with my normal scheduled recordings every day. I've even had Music Choice streaming successfully non-stop for the last 72 hours!

I'm going to upgrade to 0.4.48 and give it a short test before moving up to 0.5.x. Thanks again for all of the great work on OpenDCT!

Glad it's working well for you. That's an impressive amount of time to stay tuned into one channel.