BDA tuner locked.

[emveepee]

I am trying to figure out why NextPVR OTA updates fail for me on Windows every night after a connection. In debugging this does using a BDA tuner prevent use from hdhomerun_config on the "hung" tuner? I couldn't do anything with the HDHR until an HDHR reboot. I am running on 172.16.3.3

Code: Select all

[D:\temp]"c:\program files\Silicondust\HDHomeRun\hdhomerun_config" 10528531 get /tuner0/streaminfo
3: 9.1 CBOFT-D
tsid=0x432D
[D:\temp]"c:\program files\Silicondust\HDHomeRun\hdhomerun_config" 10528531 save /tuner0 33.ts
unable to start stream
[D:\temp]"c:\program files\Silicondust\HDHomeRun\hdhomerun_config" 10528531 save /tuner0 33.ts
unable to start stream
[D:\temp]"c:\program files\Silicondust\HDHomeRun\hdhomerun_config" 10528531 get /tuner0/streaminfo
3: 9.1 CBOFT-D
tsid=0x432D
[D:\temp]"c:\program files\Silicondust\HDHomeRun\hdhomerun_config" 10528531 get /tuner0/lockkey
172.16.3.3
[D:\temp]"c:\program files\Silicondust\HDHomeRun\hdhomerun_config" 10528531 get /tuner0/lockkey
172.16.3.3
[D:\temp]"c:\program files\Silicondust\HDHomeRun\hdhomerun_config" 10528531 get /tuner0/debug
tun: ch=auto6t:587000000 lock=8vsb:587000000 ss=91 snq=90 seq=100 dbg=-5175/11887
dev: bps=19494848 resync=0 overflow=0
ts:  bps=18437536 te=52788 crc=24
net: bps=18434528 pps=1751 err=0 stop=0
[D:\temp]"c:\program files\Silicondust\HDHomeRun\hdhomerun_config" 10528531 set /tuner0/channel none
ERROR: resource locked by 172.16.3.3
[D:\temp]"c:\program files\Silicondust\HDHomeRun\hdhomerun_config" 10528531 get /tuner0/lockkey
172.16.3.3
[D:\temp]"c:\program files\Silicondust\HDHomeRun\hdhomerun_config" 10528531 set /tuner0/channel none
ERROR: resource locked by 172.16.3.3

[D:\temp]"c:\program files\Silicondust\HDHomeRun\hdhomerun_config" 10528531 set /sys/restart self
[D:\temp]"c:\program files\Silicondust\HDHomeRun\hdhomerun_config" 10528531 set /tuner0/channel none
[D:\temp]"c:\program files\Silicondust\HDHomeRun\hdhomerun_config" 10528531 set /tuner0/channel 8vsb:33
[D:\temp]"c:\program files\Silicondust\HDHomeRun\hdhomerun_config" 10528531 get /tuner0/lockkey
none
[D:\temp]"c:\program files\Silicondust\HDHomeRun\hdhomerun_config" 10528531 get /tuner0/lockkey
none
[D:\temp]"c:\program files\Silicondust\HDHomeRun\hdhomerun_config" 10528531 get /tuner0/streaminfo
3: 9.1 CBOFT-D
tsid=0x432D
[D:\temp]"c:\program files\Silicondust\HDHomeRun\hdhomerun_config" 10528531 set /tuner0/channel none
[D:\temp]

[jasonl]

Yes, the BDA driver automatically locks the tuner while streaming (and unlocks it when done).

[emveepee]

Yes, the BDA driver automatically locks the tuner while streaming (and unlocks it when done).

So if BDA locks the tuner and the original calling program fails and is no longer running is there a solution other than reboot?

Martin

[nickk]

So if BDA locks the tuner and the original calling program fails and is no longer running is there a solution other than reboot?

There is a keepalive system. If the original app terminates the HDHomeRun will drop the lock in about a minute or so.

[emveepee]

There is a keepalive system. If the original app terminates the HDHomeRun will drop the lock in about a minute or so.

After terminating the app with taskkill I didn't see it timeout after much more than a minute, that is why I thought BDA internals were potentially keeping it alive. I expect tonight the NextPVR app will fail so is there anyway to confirm this timeout?

Martin

[nickk]

Please turn on "send diagnostic information" in HDHomeRun Setup... then we can see what the BDA driver is doing.

[emveepee]

Please turn on "send diagnostic information" in HDHomeRun Setup... then we can see what the BDA driver is doing.

OK thanks I just enabled it. You should focus on 10528531-0

I am running a control now, basically you should see an 8197 PID scan with the found PID's being added and running for 70 seconds. This duplicates on 8 local frequencies . When I run this manually like I am doing right now, it completes and when I schedule it later in the day it completes.

The issue is when scheduled overnight (2:46 Eastern) the first scan is short of EPG event IDs and the tuner stays locked on the second frequency.

As it turns out the control failed so you might have the problem logged.

I killed the task and I still see

"c:\program files\Silicondust\HDHomeRun\hdhomerun_config" 10528531 get /tuner0/streaminfo
3: 9.1 CBOFT-D
tsid=0x432D

and it is not timing out. The web server still shows it locked too.

Martin

[emveepee]

Hours later I still get

"c:\program files\Silicondust\HDHomeRun\hdhomerun_config" 10528531 set /tuner0/channel none
ERROR: resource locked by 172.16.3.3

[emveepee]

Update after a failed 2:45 (Eastern) run I restarted a manual run just before 3:09 and it completed and successfully reset the tuner. The question is can you detect what is failing in BDA around 02:47:48

Martin

[emveepee]

Update after a failed 2:45 (Eastern) run I restarted a manual run just before 3:09 and it completed and successfully reset the tuner. The question is can you detect what is failing in BDA around 02:47:48

At 4:44 you would also see a Linux test using rtp which was successful.

Martin

[jasonl]

No apparent failures in BDA at 2:47:48 ET this AM. The frequency was changed to 587 MHz at that time and it streamed normally until 3:08:42 when it was apparently killed, and then the app reloaded and tuned 539 MHz. The BDA driver detected a dead connection and forced a release of the lock, then it was relocked for itself. I'm thinking the BDA driver might be set to not utilize the automatic timeout since it has this other logic built in, and it was more intended for programs like MythTV that use libhdhomerun directly. It's been a lot of years since this was top of mind...

[emveepee]

Thanks for looking.

From the description "The BDA driver detected a dead connection" it does sounds like BDA doesn't timeout on its own and it took NextPVR reintialized BDA on the manual run to make the tuner available.

Can you tell me how long it took 587 to respond after 539 in the earlier failed run?

First bad run
2025-04-22 02:46:37.125 [DEBUG][4] locked=0, present=0, strength=0, quality=0 (took 0ms to check)
2025-04-22 02:46:38.134 [DEBUG][4] locked=1, present=1, strength=95, quality=90 (took 688ms to check)
no response logged and the logic freezes

The later good run was
2025-04-22 03:08:55.019 [DEBUG][4] locked=0, present=0, strength=0, quality=0 (took 0ms to check)
2025-04-22 03:08:56.198 [DEBUG][4] locked=1, present=1, strength=95, quality=90 (took 937ms to check)
2025-04-22 03:10:08.315 [DEBUG][6] locked=1, present=1, strength=90, quality=90 (took 1468ms to check)

Martin

[jasonl]

20250422-02:46:37 10528531-0 bda: CHDHomeRunTuner::StartChanges
20250422-02:46:37 10528531-0 bda: CHDHomeRunDemodulatorNode::put_ModulationType: -1
20250422-02:46:37 10528531-0 bda: CHDHomeRunTunerNode::put_Polarity
20250422-02:46:37 10528531-0 bda: CHDHomeRunTunerNode::put_Range(-1)
20250422-02:46:37 10528531-0 bda: CHDHomeRunTunerNode::put_Bandwidth(-1)
20250422-02:46:37 10528531-0 bda: CHDHomeRunTunerNode::put_FrequencyMultiplier(1)
20250422-02:46:37 10528531-0 bda: CHDHomeRunTunerNode::put_Frequency(537250000)
20250422-02:46:37 10528531-0 bda: CHDHomeRunDeviceState::CommitChangesImplChannel: Set channel: auto6t:539000000
20250422-02:46:37 10528531-0 bda: CHDHomeRunDeviceState::CommitChangesImplChannel: Set program: 0
20250422-02:46:37 10528531-0 bda: CHDHomeRunSignalStats::GetTunerStatus: ch=auto6t:539000000 lock=8vsb ss=96 snq=85 seq=0
20250422-02:46:37 10528531-0 bda: CHDHomeRunSignalStats::GetTunerStatus: ch=auto6t:539000000 lock=8vsb ss=95 snq=90 seq=0
20250422-02:46:38 10528531-0 bda: CHDHomeRunSignalStats::GetTunerStatus: ch=auto6t:539000000 lock=8vsb ss=95 snq=90 seq=100


20250422-02:47:48 10528531-0 bda: CHDHomeRunTuner::StartChanges
20250422-02:47:48 10528531-0 bda: CHDHomeRunDemodulatorNode::put_ModulationType: -1
20250422-02:47:48 10528531-0 bda: CHDHomeRunTunerNode::put_Polarity
20250422-02:47:48 10528531-0 bda: CHDHomeRunTunerNode::put_Range(-1)
20250422-02:47:48 10528531-0 bda: CHDHomeRunTunerNode::put_Bandwidth(-1)
20250422-02:47:48 10528531-0 bda: CHDHomeRunTunerNode::put_FrequencyMultiplier(1)
20250422-02:47:48 10528531-0 bda: CHDHomeRunTunerNode::put_Frequency(585250000)
20250422-02:47:48 10528531-0 bda: CHDHomeRunDeviceState::CommitChangesImplChannel: Set channel: auto6t:587000000
20250422-02:47:48 10528531-0 bda: CHDHomeRunDeviceState::CommitChangesImplChannel: Set program: 0
20250422-02:47:49 10528531-0 bda: CHDHomeRunSignalStats::GetTunerStatus: ch=auto6t:587000000 lock=8vsb ss=91 snq=90 seq=0
20250422-02:47:49 10528531-0 bda: CHDHomeRunSignalStats::GetTunerStatus: ch=auto6t:587000000 lock=8vsb ss=91 snq=90 seq=0
20250422-02:47:49 10528531-0 bda: CHDHomeRunSignalStats::GetTunerStatus: ch=auto6t:587000000 lock=8vsb ss=91 snq=90 seq=0
20250422-02:47:49 10528531-0 bda: CHDHomeRunSignalStats::GetTunerStatus: ch=auto6t:587000000 lock=8vsb ss=91 snq=90 seq=100

Both were completely normal. I can't give you down to the ms since we don't log that precisely but it didn't reach into an additional second, so < 2s on both.

[emveepee]

Thanks for checking that, I've passed that on to the author. I rebooted my PC a couple of days ago and the scheduled updates have started working.

It would be nice if the BDA dead connection timeout issue could be looked at deeper, the rtp method on Linux seems more stable.

Thanks again.