OpenDCT: An open source digital cable tuner.

[EnterNoEscape]

Are you using the SageTV Windows Client?

[EnterNoEscape]

Never mind on my first post. I see the lines like ERROR FFmpegTransSageTVConsumerImpl - Unable to open 'E:\Recorded TV\ABCWorldNewsTonight-3768062-0.ts' for writing => java.nio.file.FileSystemException: E:\Recorded TV\ABCWorldNewsTonight-3768062-0.ts: The process cannot access the file because it is being used by another process. frequently in your logs. The error is especially odd since it's not like this is the second time accessing the file. Do you have anything monitoring the recording directories?

[videolog]

Nothing monitoring that I am aware of.

[mgpaulus]

Originally Posted by jptheripper

I searched thread but couldnt see an answer. Does this support the Hauppauge
WinTV-DCR-2650 Dual Tuner CableCARD Receiver?

Thanks

Actually, I wanted to report that your latest (0.57?) does support the DCR-2650. It seems to look and smell like an HDHR-Prime with only 2 tuners, but I hooked one up and OpenDCT found it and is serving it up. SageTV is able to add the device/tuners with the same channel lineup as my full Prime, and I can do a channel preview just fine. So, don't give up hope on it. If you have one laying around, give it a shot.

[EnterNoEscape]

I did not realize that Silicondust probably made that tuner. Thanks for finding that out.

[EnterNoEscape]

Originally Posted by videolog

Nothing monitoring that I am aware of.

It's just very odd. I'm not sure what else to say. The logs don't show anything like OpenDCT trying to open the file, then re-opening the file which could possibly result in that error message, but the message is very suggestive that something else beat OpenDCT to creating the file. You could try enabling upload id and see if using the media server helps any.

1. Stop OpenDCT.
2. Open opendct.properties.
3. Change consumer.ffmpeg.upload_id_enabled to true.
4. Save the file.
5. Start OpenDCT.

[videolog]

Okay, I will give that a try.

[sic0048]

I find that my system won't recover cleanly when I loose my cable service. I'm using a Ceton Infini TV 6 ETH device and SageTV v7.

Here is a log as an example. I went to bed with our cable service being out, but the SageTV system being up and the tuners available. When I woke up, the tuners were not associated in Sage properly. They showed up as available, but wouldn't actually tune anything. Stopping the SageTV service, recycling the SageDCT service, and then restarting the SageTV service corrected the issue and the tuners were properly associated.

I had similar issues when I first rebuilt my SageTV system and didn't set the computer to "never sleep". When the computer would sleep, whenever it came back online, the Centon tuners would show up in Sage, but wouldn't actually work until the two services (SageTV and OpenDCT) were cycled.

Does this show anything that could help make the system better at recovering from a loss of broadcast service like this?

Thanks!

[phantomii]

As mentioned in an earlier post I also have a Ceton Eth6. It was also mentioned that this device had a bug or memory leak issue. So out of curiosity I have a question for OpenDCT (which maybe should be sent to SageTV dev folks).

Would it be possible to have the OpenDCT app or possibly SageTV itself send a periodic reset (hopefully avoiding recording times) to the Ceton device to clear issues and get things working again?

Just a thought.....

[EnterNoEscape]

Originally Posted by sic0048

I find that my system won't recover cleanly when I loose my cable service. I'm using a Ceton Infini TV 6 ETH device and SageTV v7.

Here is a log as an example. I went to bed with our cable service being out, but the SageTV system being up and the tuners available. When I woke up, the tuners were not associated in Sage properly. They showed up as available, but wouldn't actually tune anything. Stopping the SageTV service, recycling the SageDCT service, and then restarting the SageTV service corrected the issue and the tuners were properly associated.

I had similar issues when I first rebuilt my SageTV system and didn't set the computer to "never sleep". When the computer would sleep, whenever it came back online, the Centon tuners would show up in Sage, but wouldn't actually work until the two services (SageTV and OpenDCT) were cycled.

Does this show anything that could help make the system better at recovering from a loss of broadcast service like this?

Thanks!

What I see in that log is that the circular buffer was unable to allocate itself because the JVM ran out of memory. The place that problem is happening is kind of odd, but I guess it's possible you're seeing is the result of some very strange race condition.

I've partly been holding out on a new beta release until the Windows SageTV installer is updated, but I think I'll put one out there a little sooner to fix this issue you're having. I have a few ideas on how to fix this or at least catch it before it's a problem and correct it.

[EnterNoEscape]

Originally Posted by phantomii

As mentioned in an earlier post I also have a Ceton Eth6. It was also mentioned that this device had a bug or memory leak issue. So out of curiosity I have a question for OpenDCT (which maybe should be sent to SageTV dev folks).

Would it be possible to have the OpenDCT app or possibly SageTV itself send a periodic reset (hopefully avoiding recording times) to the Ceton device to clear issues and get things working again?

Just a thought.....

It's possible, but you'll have a much better experience if you script it run from SageTV since OpenDCT has no knowledge of the recording schedules. It just does what SageTV tells it to do.

[EnterNoEscape]

• Added option to force MPEG2-PS when using the Media Server. The option is consumer.media_server.prefer_ps and is defaulted to true because this is the recommended setting for the remuxer.
• Added option for a discoverer to indicate that its capture devices need to be fully unloaded on standby. Currently no capture devices require this.
• Added timeout to socket server that listens for requests from SageTV. This should keep the socket from becoming stale due to a network interface going down, then back up.
• Added option to NIORTPProducerImpl to disable the use of a direct byte buffer. The property is producer.rtp.nio.allocate_direct and defaults to true.
• Added option to NIORTPProducerImpl to enable monitoring for when packets are taking longer than 1ms to be inserted into the circular buffer. If packets are taking over 5ms to be inserted, double-buffering is enabled to reduce the number of times writes are made to the circular buffer which should reduce the chances of long waits at the cost of make one extra copy. The property is producer.rtp.nio.log_timing_exp and defaults to true.
• Added out of memory handling for FFmpegTransSageTVConsumerImpl.
• Changed NIORTPProducerImpl to use non-blocking I/O for keeping track of packets.
• Changed NIOHTTPProducerImpl to use non-blocking I/O for keeping track of packets.
• Changed HDHomeRun communication packets to direct byte buffers.
• Changed HDHomeRun smart discovery broadcast so that it will not continuously trigger more broadcasts due to communication errors.
• Changed HDHomeRun discovery to stop trying to load a capture device after 3 failed attempts.
• Changed custom Cling UPnP build to the version available on Maven. The modifications are no longer needed since the library isn't used for anything other than detecting the presence of capture devices.
• Changed resume behavior to wait for another IP address when a required network interface has an APIPA address. This addresses a problem with some internal InfiniTV cards.
• Removed dependency on commons-cli-1.3.jar.
• Removed dependency on fastutil-7.0.12.jar.
• Capture devices are no longer unloaded on standby since it's really not actually required.
• The dynamic consumer now loads in separate thread.
• Lineups now load in parallel. This can speed up startup time significantly if you have a variety of capture devices.
• Lineups with no name are no longer loaded.

[CptKirk]

Is there anything special you need to do to switch from the stable to the beta builds?

[KeithAbbott]

Originally Posted by CptKirk

Is there anything special you need to do to switch from the stable to the beta builds?

Here's the procedure that I came up with when I upgraded from stable to beta (for Windows):

1. Stop the SageTV service
2. Stop the OpenDCT service
3. Backup the "C:\ProgramData\OpenDCT" directory
4. Delete the "C:\ProgramData\OpenDCT\config\opendct.properties" file
5. Install the desired version of OpenDCT
6. Apply any necessary "C:\ProgramData\OpenDCT\config\opendct.properties" file changes
7. Start the OpenDCT service
8. Start the SageTV service

If you are downgrading to a prior version, uninstalling the currently installed version is necessary between steps 4 and 5.

Would love any additional suggestions for improvement.

[EnterNoEscape]

That looks good, but there isn't really any reason to back up C:\Program Files\OpenDCT Authors or C:\Program Files (x86)\OpenDCT Authors unless you changed the log4j2.xml file. All configuration and logs end up under C:\ProgramData\OpenDCT.

[KeithAbbott]

Originally Posted by EnterNoEscape

That looks good, but there isn't really any reason to back up C:\Program Files\OpenDCT Authors or C:\Program Files (x86)\OpenDCT Authors unless you changed the log4j2.xml file. All configuration and logs end up under C:\ProgramData\OpenDCT.

My reason to back it up is so that I can roll back easily if I run into problems.

[EnterNoEscape]

I see what you're saying, but you're defeating the installer when you do things like that. It can possibly create strange issues if you upgrade, then copy the old files back because it's not working out for you, then upgrade again at a later date because the installer isn't going to know about the changes you made to the installation and could for example leave you with two copies of opendct-x.x.x.jar.

It's a lot safer if you're rolling back to uninstall the newer version, then re-install the older version, then restore the old configuration files that you backed up. I know for many users, this back up approach is due to how SageTV mixes all of the configuration pieces with the non-configuration data and it's nearly impossible to sort out what you need and what you don't need in under a few minutes.

[KeithAbbott]

Originally Posted by EnterNoEscape

That looks good, but there isn't really any reason to back up C:\Program Files\OpenDCT Authors or C:\Program Files (x86)\OpenDCT Authors unless you changed the log4j2.xml file. All configuration and logs end up under C:\ProgramData\OpenDCT.

I've updated my post to reflect this.

Originally Posted by EnterNoEscape

It's a lot safer if you're rolling back to uninstall the newer version, then re-install the older version, then restore the old configuration files that you backed up. I know for many users, this back up approach is due to how SageTV mixes all of the configuration pieces with the non-configuration data and it's nearly impossible to sort out what you need and what you don't need in under a few minutes.

Is uninstalling the old version also a good idea when you are upgrading to a new version, or is that really only recommended when you are rolling back to a prior version of OpenDCT?

Also, your first post in this thread has a reference to instructions on how to initially install OpenDCT, which I found very valuable. Any chance that first post could include a reference on how to upgrade to newer versions? It's getting difficult to search thru this thread due to it's shear size.

[EnterNoEscape]

Originally Posted by KeithAbbott

Is uninstalling the old version also a good idea when you are upgrading to a new version, or is that really only recommended when you are rolling back to a prior version of OpenDCT?

Also, your first post in this thread has a reference to instructions on how to initially install OpenDCT, which I found very valuable. Any chance that first post could include a reference on how to upgrade to newer versions? It's getting difficult to search thru this thread due to it's shear size.

Uninstall only if you are rolling back. Otherwise, you just install the newer version and it will upgrade everything for you.

I'll put a note about upgrades in the first post.

Update: I was just thinking about this and I realized all of the install information is at the top of the GitHub page. I will duplicated it.

[jarredduq]

I'm running 0.5.8 beta and Comcast has started migrating more channels to h.264. I've noticed that tuning is extremely slow for the channels on h.264. It's around 15 seconds compared to about 3 with MPEG2. Also, it comes up with the no signal message for about 5 seconds before the video starts playing.

It's working, but I'm wondering if there is a setting I need to change to speed up the tuning.

Thanks in advance.