OpenDCT: An open source digital cable tuner.

[Daweeze]

Originally Posted by HelenWeathers

PROBLEM RESOLVED:
Discovered that Windows Media Center was activated so deactivated it under programs & features.

.......


Not sure what the issue was, but am leaning to WMC as the culprit. I usually remove WMC from my Sage servers but somehow this time it got by me.

Helen,

Thanks for reminding me of this. I am not sure that the little blips I have have anything to do with having Media Center Installed or not. I have Windows 8.1 and I remember I just downloaded WME while it was available for free when Windows 8.0 was released and I have never used it. I removed it from Windows Features anyway.

-Travis

[Telecore]

Originally Posted by EnterNoEscape

I think I see the problem now and I'm very certain I can fix it.

It looks like you have fixed the standby problem in 0.4.12. I installed it last night and it has been working when coming out of sleep mode multiple times. I will keep testing on both Sage servers and eventually go "all in" on my main Sage V7 server with all 6 tuners. Thanks again and I'll keep you posted about any issues I observe.

UPDATE: take a look at the attached logs - I think there may have been some issues.

[EnterNoEscape]

Originally Posted by Daweeze

Helen,

Thanks for reminding me of this. I am not sure that the little blips I have have anything to do with having Media Center Installed or not. I have Windows 8.1 and I remember I just downloaded WME while it was available for free when Windows 8.0 was released and I have never used it. I removed it from Windows Features anyway.

-Travis

There was also an issue all the way through v0.3.15 that was addressed in v0.3.16 that would cause a stall to be detected when there wasn't a stall often when the computer was under higher than normal load. Are you running the latest stable and still seeing issues?

[Daweeze]

Originally Posted by EnterNoEscape

There was also an issue all the way through v0.3.15 that was addressed in v0.3.16 that would cause a stall to be detected when there wasn't a stall often when the computer was under higher than normal load. Are you running the latest stable and still seeing issues?

I was using v0.3.14. I upgraded to v0.3.16 just now. I was seeing the same problem when using SageDCT. The usual problem is that while watching Live TV, the screen will just freeze and only a Channel Down/Up or Up/Down would restore the viewing of the channel. I recently discovered a problem with one of my Network Switches which may be related so I will try to replace that sometime this week before reporting any issues worth troubleshooting. I don't want to waste your time when I know that variable for trouble still exists.

-Travis

[HelenWeathers]

Originally Posted by Daweeze

Helen,

Thanks for reminding me of this. I am not sure that the little blips I have have anything to do with having Media Center Installed or not. I have Windows 8.1 and I remember I just downloaded WME while it was available for free when Windows 8.0 was released and I have never used it. I removed it from Windows Features anyway.

-Travis

The reason I suspect WMC for causing issues is that on the other Win7 machines on my network the HDHR Prime does not show up anywhere in Device Manager and in figuring out why I discovered the existance of WMC on my SageTV server. Then I found this on the SD website: "HDHomeRun BDA/WMP: Fix problem where BDA/WMP could interrupt http stream".

That was enough for me to remove WMC - I never use it anyway.

I looked thru my Sage logs for the last 24hrs and there is no longer an association of the DCT tuner with BDA tuning. All DCT recordings are good.

So, all is well in SageTVland.

[Telecore]

Originally Posted by Telecore

It looks like you have fixed the standby problem in 0.4.12. I installed it last night and it has been working when coming out of sleep mode multiple times. I will keep testing on both Sage servers and eventually go "all in" on my main Sage V7 server with all 6 tuners. Thanks again and I'll keep you posted about any issues I observe.

UPDATE: take a look at the attached logs - I think there may have been some issues.

Here's some more logs. It's working better but I noticed some weird stuff. When SageTV came out of sleep around 5:20, the 1st channel I tuned used SageDCT, so I guess the OpenDCT tuner wasn't available yet. Then OpenDCT became available - I re-tuned the channel and got the spinning circle of death. System Info indicates OpenDCT tuners are functional. Logs attached.

[EnterNoEscape]

It looks like the devices are not checking in fast enough. Increase the value of sagetv.device.global.required_devices_loaded_timeout_ms to 60000. As a safety measure OpenDCT will completely restart if all required devices don't load within that many milliseconds with the assumption that something must not be working correctly. 30000 seemed like enough time in testing, but maybe it's not. I checked and every one of those opendct-crash-x.log files represents a time when the devices were not detected and loaded within that time. I have to assume my experiences have been more optimal than most people's, so maybe I will change the default to one minute instead of 30 seconds. That change will only effect installations where the property is not populated already.

Update: If the increase doesn't work out for you, we have a new beta in the works that will be more aggressive with detection until we have all of the capture devices loaded.

[Telecore]

Yes please keep me posted on any new versions. At this point, I have turned off SageDCT and am using OpenDCT exclusively. I did change the delay to 60000 but crash files are still being produced. From a user standpoint, though, I think there are no visible problems because my wife was watching TV this morning before I got up and reported no issues. Crash files were created at the time she turned SageTV on.

I think that I may have mentioned this before, but the SageTV->System Info is reporting both the 6 local OpenDCT tuners and the 6 OpenDCT tuners in the other PC. Could detecting all 12 be contributing to additional startup delay?

[EnterNoEscape]

You're using the PCI-E cards and you don't have them bridged onto the same network, correct? If I recall correctly, the last time you sent me your configuration it told me basically it only saw one of the DCT's. If this statement is true, 6 out of the 12 tuners you're seeing in SageTV are being discovered from the other computer running OpenDCT and have no influence when you're coming out of standby. Bill reported that the 60 second timeout at times wasn't working out for him either, but it would always recover when OpenDCT restarted automatically. He proposed a solution that he used before to speed up detection. After looking through Cling and verifying the results in Wireshark, I feel like we came up with a good solution that will not kill your network with discovery packets. I was concerned that it could adversely effect streaming during detection.

I have been running the latest version since last night. It also has a fix for a rare FFmpeg issue in it, so I wanted to at least give it about a day before I told anyone else to try it.

[Telecore]

After installing 0.4.13, everything seems to be working very well - no more crash logs, no issues after wake-up, no visible glitches when watching shows and all tuners report as functioning: true. I will look for future updates and the official release and keep you posted if I see anything. Thanks for all your hard work.

[nyplayer]

Working great here also the Pooling of the Primes is working great I can now share all the Prime Tuners with my test machine and also the HDHomerunDVR. Opendct is checking the tuners and if in use moves on to the next tuner.


On my production system I have always force_external_unlock=false set to true so I never miss a recording.

[EnterNoEscape]

Originally Posted by Telecore

After installing 0.4.13, everything seems to be working very well - no more crash logs, no issues after wake-up, no visible glitches when watching shows and all tuners report as functioning: true. I will look for future updates and the official release and keep you posted if I see anything. Thanks for all your hard work.

Excellent. It's good to see you're finally in a good place.

Originally Posted by nyplayer

Working great here also the Pooling of the Primes is working great I can now share all the Prime Tuners with my test machine and also the HDHomerunDVR. Opendct is checking the tuners and if in use moves on to the next tuner.


On my production system I have always force_external_unlock=false set to true so I never miss a recording.

That is an excellent application of the pooling feature. I might be trying that out myself. It's a shame there doesn't appear to be an equivalent for the InfiniTV devices.

[EnterNoEscape]

There were some significant changes on the code side and several features added, so I felt it was best to first only have a small number of the community actually testing to be sure things were reasonably stable before a larger audience tries it out and several people are telling me about the exact same problem. For a complete log of how we got to this beta check the release.md markdown document on GitHub. Unless otherwise noted, "property" changes are referring to changing property values in opendct.properties. For anyone on 0.4.13, there is no rush to get on this version since nothing really changed.

New Features

• Tuner Pooling.

  This new feature enables OpenDCT to intelligently select a tuner based on merit and lock status in that order. It does two passes over the tuners. The first one tries to find the highest merit tuner that is not currently in use by SageTV; it checks each one in order to see if it's locked. If they are all either in use or locked, it then it goes through a shorter list of tuners not in use by SageTV, but locked and checks if it's allowed to unlock any of them forcefully. If it's not allowed on any of them, then it gives up. These locked checks are surprisingly fast. Since the InfiniTV devices do not have a locked indication like the HDHomeRun Prime devices, enabling pooling with only InfiniTV devices will just remap them based on merit.

  To enable the pooling feature change the property pool.enabled from false to true.

  Because of this new feature, the force unlock feature is now set per capture device. To enable forced unlocking, change the value of sagetv.device.<unique_id>.always_force_external_unlock to true for each device that you want this feature enabled on. The global setting no longer has any effect.

  Merit is set by changing the value of sagetv.device.<unique_id>.encoder_merit. Higher numbers mean higher priority. This is also the merit that will be sent on discovery.

  Pools are automatically assigned based on capture device type the first time you run OpenDCT. You can change the pools by changing the value of sagetv.device.<unique_id>.encoder_pool to another name for all of the capture devices that you want to put into a different pool. The name is case sensitive. Also be sure to not have any extra spaces. I highly do not recommend putting capture devices that cannot tune the same channels into the same pool. It will create a problem per paragraph two in the issue created for this feature.

• Early Port Assignment.

  When this is enabled, OpenDCT will immediately (< 500ms from startup) open any ports assigned in opendct.properties. For most people this will just be port 9000. Set the property sagetv.early_port_assignment to true to enable this feature.

  If you are using this feature, just like standby, you must set sagetv.device.global.required_devices_loaded_count to match the total number of capture devices OpenDCT should expect to be detected and loaded. If you do not set this property and SageTV makes a tuning request before anything has been detected, OpenDCT will not know that it should hang onto that request and the request will just return ERROR to SageTV.

• HDHomeRun Prime Channel Auto-Enabling.

  This is enabled by default. It can be disabled by setting channels.prime.enable_all_channels to false.

  The process of importing these channels already happens one minute after startup and every 8 hours by default in OpenDCT. The change is that now unless the channel actually indicates that it required DRM to tune, OpenDCT assumes it's tunable. What this translates into directly is you can now do a channel scan within SageTV and import your last channel scan from your HDHomeRun Prime.

  Warning: There is a SageTV imposed limitation of 159 channels for this type of network encoder. If you have more than 159 channels available to you, this feature will disappoint you. Note that 159 channels doesn't mean 1-159. The channel numbers can be anything, but SageTV will only ask about 159 of them.

• UPnP Ignore Interface by IP or Interface Name

  You can now specify an comma separated list of local IP addresses or interfaces to prevent UPnP from using them.

  You can provide a comma seperated list of interfaces on the property upnp.service.configuration.ignore_interfaces_csv. You will need to reference the log to figure out what interfaces you want to list here. The ones being used are listed very early in opendct.log. This difficulty is the reason why the IP address option is available too.

  You can provide a comma seperated list of IP addresses on the property upnp.service.configuration.ignore_local_ip_csv.

[nyplayer]

That explains why when I was scanning I was only getting 159 channels I have over 300. I wonder if this can be changed in Open source.?? Do you recommend I set it to false since I have over 300 channels?

[EnterNoEscape]

Honestly it doesn't matter. It pulls the channels either way; this just changes what it does with that information. It can be fixed, but the reason it happens if I recall correctly is more complicated than just changing a a single number. The conversation I'm thinking of came up a long time ago. I think it has to do with a frequency table or something in that ballpark.

[nyplayer]

Just one more question when you use pooling does the opendct merits take precedence over the SageTV tuner merits? I am just fine tuning my production and test systems.

[EnterNoEscape]

OpenDCT will override the SageTV merit for devices within the same pool. Devices not in a pool or not controlled by OpenDCT will still use the SageTV merit property. You can also remove a single device from pooling by blanking the encoder_pool value for that device.

[nyplayer]

Originally Posted by EnterNoEscape

OpenDCT will override the SageTV merit for devices within the same pool. Devices not in a pool or not controlled by OpenDCT will still use the SageTV merit property. You can also remove a single device from pooling by blanking the encoder_pool value for that device.

Fantastic this only gets better thanks.

[troll5501]

Originally Posted by EnterNoEscape

There were some significant changes on the code side and several features added

Can you explain more about the changes you made to the buffering? I upgraded to 0.4.13 a few days ago and now my workaround for corruption/pixelation during times of high CPU no longer helps. The problem occurs now even with rw_buffer_size=262144 on 0.4.13.

When the problem occurs, I get lots of the new debug messages "The buffer contains xxx bytes, has only yyy bytes left for writing, and zzz bytes cannot be added" and "The buffer has lost xxx bytes". Immediately after these I get the "Continuity check failed" errors that I used to get in 0.3.16 before I increased the buffer size.

[EnterNoEscape]

Originally Posted by troll5501

Can you explain more about the changes you made to the buffering? I upgraded to 0.4.13 a few days ago and now my workaround for corruption/pixelation during times of high CPU no longer helps. The problem occurs now even with rw_buffer_size=262144 on 0.4.13.

When the problem occurs, I get lots of the new debug messages "The buffer contains xxx bytes, has only yyy bytes left for writing, and zzz bytes cannot be added" and "The buffer has lost xxx bytes". Immediately after these I get the "Continuity check failed" errors that I used to get in 0.3.16 before I increased the buffer size.

The changes were to allow FFmpeg to use the circular buffer more like it's a normal growing file. The previous design made an assumption that once detection was completed that we didn't need to remember how far we actually traveled in buffer. The design turned out to be flawed for two people who ironically had a completely unrelated issue. The new design remembers how many bytes have streamed and will allow FFmpeg to seek back to as far is still safe in the buffer. I realize this sounds a little easier that it actually is.

The messages that you're seeing implies that FFmpeg has stopped consuming data from the buffer or that it is unable to write data because they are suggesting that the circular buffer is overflowing. I'm not sure this is exactly the same issue, but the trigger is the same as you noted. Please post a log from when it happens so I can possibly give you better direction.