OpenDCT: An open source digital cable tuner.

[waylo]

I recently installed 0.56 and found the tuning times were far far longer than before. I also missed all recordings over the weekend while I was out that were to use the HDHR Prime, due to "capture device failure." Can someone take a peek at the attached logs?

I've switched back to 0.54 and the tuning times seem back to "normal" (had skipped over 0.55).

[HelenWeathers]

I'm running 0.5.4 on Win 10 without issue. Have not tried .5 or .6 yet.

[EnterNoEscape]

Originally Posted by waylo

I recently installed 0.56 and found the tuning times were far far longer than before. I also missed all recordings over the weekend while I was out that were to use the HDHR Prime, due to "capture device failure." Can someone take a peek at the attached logs?

I've switched back to 0.54 and the tuning times seem back to "normal" (had skipped over 0.55).

Does your computer go into standby? The log you posted basically just shows me that none of your HDHomeRun devices were detected.

Edit: Actually one of them was: HDHomeRun HDHR-US, but the Prime was not.

[waylo]

Originally Posted by EnterNoEscape

Does your computer go into standby? The log you posted basically just shows me that none of your HDHomeRun devices were detected.

My HTPC does not go into standby and is kept on 24/7. Would SageTV logs provide more info?

Both the Prime and the HDHR-US are on the LAN and not directly connected to the HTPC. Would LAN connectivity issues cause the same error?

Unrelatedly, I've been having some recent issues with the HDHR-US not releasing a tuner for some reason, but I am not using OpenDCT to tune the HDHR-US.

[EnterNoEscape]

Originally Posted by waylo

My HTPC does not go into standby and is kept on 24/7. Would SageTV logs provide more info?

Both the Prime and the HDHR-US are on the LAN and not directly connected to the HTPC. Would LAN connectivity issues cause the same error?

Unrelatedly, I've been having some recent issues with the HDHR-US not releasing a tuner for some reason, but I am not using OpenDCT to tune the HDHR-US.

Regarding the HDHR-US: I noticed that on shutdown that it was locked by 192.168.1.101. I don't usually look at those very hard because I presume you know how you're using things better than I do. Did you make sure you don't have an instance of SageTV loading it that you might have forgot about?

If you have any logs that show when OpenDCT first started, those would be very helpful in figuring out why the HDHomeRun Prime might have not loaded.

I was just browsing all of the changes between 0.5.4 and 0.5.6. Since I actually didn't make any changes should have any meaningful effect on the actual discovery process, but I did change programs from strings to integers, I'm willing to bet I missed handling a conversion error somewhere and when the lineup tries to load it's taking the whole tuner down with it. It would make sense that a legacy device would be the lone immune device.

[waylo]

Originally Posted by EnterNoEscape

Regarding the HDHR-US: I noticed that on shutdown that it was locked by 192.168.1.101. I don't usually look at those very hard because I presume you know how you're using things better than I do. Did you make sure you don't have an instance of SageTV loading it that you might have forgot about?

If you have any logs that show when OpenDCT first started, those would be very helpful in figuring out why the HDHomeRun Prime might have not loaded.

I was just browsing all of the changes between 0.5.4 and 0.5.6. Since I actually didn't make any changes should have any meaningful effect on the actual discovery process, but I did change programs from strings to integers, I'm willing to bet I missed handling a conversion error somewhere and when the lineup tries to load it's taking the whole tuner down with it. It would make sense that a legacy device would be the lone immune device.

Thanks for brainstorming with me and for pointing out the lock coming from 192.168.1.101. Curious, as that's the main HTPC, so I would expect most tuner commands to come from there, but I can't think of other apps that would lock it. I think somewhere some rogue process is activating the tuner but not releasing it nicely.

I just run the SageTV app, not the service, but I will check that again. I do have WMC, but it does not have any scheduled recordings that use the HDHR-US. I also have Kodi with the ServerWMC backend running, just for kicks, but I rarely use it to tune anything. In fact it's ServerWMC that I use to confirm the tuner is locked for no reason. However it gets locked, every subsequent ATSC recording gets delayed as it spends the first 2.5 minutes trying to access the locked tuner before switching to the other one.

I'l see if I can pull up some of those SageTV logs. The HTPC is tasked to reboot every few days at 3am to keep it running smoothly.

As the HDHR-US is not configured to use OpenDCT, there's no way OpenDCT could be related, correct?

[EnterNoEscape]

Originally Posted by waylo

Thanks for brainstorming with me and for pointing out the lock coming from 192.168.1.101. Curious, as that's the main HTPC, so I would expect most tuner commands to come from there, but I can't think of other apps that would lock it. I think somewhere some rogue process is activating the tuner but not releasing it nicely.

I just run the SageTV app, not the service, but I will check that again. I do have WMC, but it does not have any scheduled recordings that use the HDHR-US. I also have Kodi with the ServerWMC backend running, just for kicks, but I rarely use it to tune anything. In fact it's ServerWMC that I use to confirm the tuner is locked for no reason. However it gets locked, every subsequent ATSC recording gets delayed as it spends the first 2.5 minutes trying to access the locked tuner before switching to the other one.

I'l see if I can pull up some of those SageTV logs. The HTPC is tasked to reboot every few days at 3am to keep it running smoothly.

As the HDHR-US is not configured to use OpenDCT, there's no way OpenDCT could be related, correct?

I would try removing the HDHomeRun software and ensure the BDA drivers get removed from that computer. This sounds little like something another forum member once experienced early on.

It's very unlikely that OpenDCT is locking it. OpenDCT will load it, but unless you tell SageTV to use it, OpenDCT will not try to lock it. The reason I know it's locked is because when OpenDCT stops, it will unlock any tuner it might have used just in case. It would have successfully unlocked those tuners if it had actually been what locked them, but according to the log, it was unable to unlock them which implicitly means it did not lock them.

If you have any OpenDCT logs from starting OpenDCT on 0.5.6, that would provide me with the best insight into what's probably happening.

[nyplayer]

Linux OpenDCT.properties ... I tried enabling pooling but it will not let me because it is read only. I then tried to change the permissions but it said it is not allowed...is there something specific I have to do to edit he properties file? ... do I have to use sudo in front of chmod???

[EnterNoEscape]

Originally Posted by nyplayer

Linux OpenDCT.properties ... I tried enabling pooling but it will not let me because it is read only. I then tried to change the permissions but it said it is not allowed...is there something specific I have to do to edit he properties file? ... do I have to use sudo in front of chmod???

Like many services in Linux, that file is owned by root. To edit it, you'll likely need to either run your favorite editor with sudo. You could chmod or chown it, but when you start the service back up, the permissions will change back.

[nyplayer]

Got it thanks.

[EnterNoEscape]

Originally Posted by nyplayer

Got it thanks.

In Windows I actually had the installer change the inherited permissions for the configuration directory. Otherwise you'd need to run an elevated editor there too.

[waylo]

Originally Posted by EnterNoEscape

If you have any logs that show when OpenDCT first started, those would be very helpful in figuring out why the HDHomeRun Prime might have not loaded.

I was just browsing all of the changes between 0.5.4 and 0.5.6. Since I actually didn't make any changes should have any meaningful effect on the actual discovery process, but I did change programs from strings to integers, I'm willing to bet I missed handling a conversion error somewhere and when the lineup tries to load it's taking the whole tuner down with it. It would make sense that a legacy device would be the lone immune device.

Here's a startup log of 0.5.6 for your perusal.

[EnterNoEscape]

Originally Posted by waylo

Here's a startup log of 0.5.6 for your perusal.

Thanks. That's interesting. It takes two discovery broadcasts for the HDHR-US to respond. The broadcast should have happened 3 times, but it didn't. I'll need to look into that.

If you haven't rolled back already, try stop the service, changing hdhr.smart_broadcast to false in opendct.properties, the starting the service back up.

[tmiranda]

I suddenly started getting loads of missed recordings due to capture device failure on the OpenDCT devices. Logfile atatched. I didn't change anything in my system?

[EnterNoEscape]

Originally Posted by tmiranda

I suddenly started getting loads of missed recordings due to capture device failure on the OpenDCT devices. Logfile atatched. I didn't change anything in my system?

In that log I don't see anything out of the ordinary. The only line of interest is:

The buffer has 7863100 bytes left to be read, has only 1221 bytes left for writing and 1316 bytes cannot be added. Deferring bytes to queue buffer.

Considering that detection took less a second, the buffer really shouldn't already be overflowing. I never see the recovery message that follows that one once everything is back under control and I also don't see the the next warning that basically means you dropping data. It's hard to say what is actually going on here especially since according to OpenDCT, 52366272 bytes were written to disk. That's as verified by the counter that keeps track of how many bytes are written after they are written. I was querying the files directly, but that can cause a very bad performance hit, so that code was removed. Is the file that's being recorded larger than 0? If so, are you able to playback the file directly?

At least one other forum member has seen this before which prompted me to add a bunch of code that was forcing flushes to disk and doing file length verification by checking what the filesystem reports. That extra code never revealed anything interesting, so it was removed. I really feel like this is some kind of reliability issue, but I have personally never experienced it without deliberately doing things like deleting the file while it is being written which interestingly enough, doesn't trigger any kind of exception in Java. It's hard to assign blame, but the file writing code is about as simple as it gets and I have ways to verify that data should have been written that should be very reliable, which makes me think there are some issues in Java/some versions of Java in this regard.

Edit: I actually did spot the recovery message after I looked again at the log. I probably need to take a break. The overflow can be a good indicator that your disk isn't keeping up though.

[Telecore]

Originally Posted by EnterNoEscape

Also something that came to mind is maybe on your content, FFmpeg is reordering things in a strange way. Try setting consumer.ffmpeg.use_compat_timebase to true too. The HD300 shouldn't be having these issues, so I'm a little surprised about that.

I've been running 5.6, mostly with no problems. I did what you suggested above, but not all of the earlier stuff you suggested. My config file modifications from the default are:
changed upnp.service.configuration.http_listen_port=8051 to =0
changed error_videos_enabled=false (was true)
added sagetv.device.global.ignore_devices_csv=HDHomeRun HDHR3-6CC-3X2 Tuner 13206485-0,HDHomeRun HDHR3-6CC-3X2 Tuner 13206485-1,HDHomeRun HDHR3-6CC-3X2 Tuner 13206485-2 (to only use the Ceton tuners)
changed consumer.ffmpeg.use_compat_timebase=true (was false)

Another problem happened today at 16:30 (see attached file) while watching a baseball game, the log file says something like "the consumer appears to be stuck". Had to change channels and change back to recover. Just want to give you more info/feedback in case there's an issue here - thanks

Edit: by the way - have not yet seen the problem that occurs when re-tuning at the top of the hour since I made the suggested change

[tmiranda]

Originally Posted by EnterNoEscape

The overflow can be a good indicator that your disk isn't keeping up though.

That makes sense. I saw the errors when there were many simultaneous recordings.

[nyplayer]

Originally Posted by tmiranda

That makes sense. I saw the errors when there were many simultaneous recordings.

I guess I cannot see the disk not being able to keep up with it... When you are talking at the most 5-6 gig an hour?? Maybe you should look at the cables. Are your drives that slow.


I just wrote and read a 4 gig file in 2 minutes over the network to my SageServer. so writing multiple files over the course of an hr. should not make much difference.


PS I replaced all my network cables with these. They are great.

http://www.monoprice.com/product?c_i...219&p_id=15153

[EnterNoEscape]

Originally Posted by nyplayer

I guess I cannot see the disk not being able to keep up with it... When you are talking at the most 5-6 gig an hour?? Maybe you should look at the cables. Are your drives that slow.


I just wrote and read a 4 gig file in 2 minutes over the network to my SageServer. so writing multiple files over the course of an hr. should not make much difference.


PS I replaced all my network cables with these. They are great.

http://www.monoprice.com/product?c_i...219&p_id=15153

Something to keep in mind is it's not really the overall throughput that's a problem so much as random access caused by all of those streams writing to different places on the disk at the same time. In OpenDCT, when a recording starts, there is a small burst for each recording since some data gets held up while the container streams are being detected.

SageTV regularly checks the file size which from what I've observed usually causes a sync for the file to happen on the file system. When those happen too many times in succession it will slow things down to a crawl. SageTV is very smart about when it does them, so it's normally not an issue and really there isn't a better way to do it as far as I can tell. I found this out when I was doing some aggressive testing to reproduce a problem that turned out to be due to something else unrelated to OpenDCT. Checking the filesize every write caused things to slow down so badly I couldn't watch anything.

I recall that I used to have a problem with Comskip running live on too many recordings at once that would actually cause bad recordings to happen. The CPU usage was always very low, so it's unlikely to have been a factor. I scaled back the number of instances allowed at one time, upgraded to 7200 RPM hard drives and the issues went away. I'm sure this hasn't been much of a problem for everyone, but I just wanted to point out that there are sometime other factors at play.

[tmiranda]

I've got 8 tuners and two recording drives. I haven't done much "real" testing but when the errors occur it's when 6 or more of the tuners are busy.