Unable to delete recording. File may be in use.

[mvallevand]

If you pull one of your two Hauppauge tuners and remove the splitter you must be using do things work better?

Martin

[seattlefog]

It's a Hauppauge quad tuner. It seems to show up as 2 pairs of tuners / demodulators. Like they put two of their dual-tuner chips on a single card? Two other questions. What is the "BDA driver" you referred to in a previous response? Is it something i could scrutinize more fully?

Also I noted something odd in the devices.log. It appears to be doing hardware discovery. It has entries for beginning discovery, a bunch of entries, followed by done. That pattern repeats. However it doesn't appear to end in that fashion. "Setting up device for:
2025-04-02 15:38:44.269 [DEBUG][1] About to check for HDPVR/Colossus/Siena tuners.
2025-04-02 15:38:44.269 [DEBUG][1] About to check for analog tuners"

That's it. no "done" like for all the other items, and no further entries following either. That could just be a coding oversight. It also logged that way on the previous installation, which was working fine. Still maybe sub (or whoever codes) would want to know.
Let me know if you have other ideas. Much appreciated.

[mvallevand]

I wouldn't worry about log entries like that since you are looking at the differences between your Win 10 and Win 11 setup and not a problem with NextPVR itself. Your Win 11 issue is not being reported by others.

I can't help thinking it relates to networking somehow which is how my triage started. Now that you have removed anything firewall related, I can't explain why localhost is not allows responding. Maybe it is ipv6 related?

The BDA drivers are the generic interface that NextPVR uses on Windows to talk to digital h/w tuners.

Martin

[seattlefog]

I wondered about the ip 4 vs 6. remember that if I reissue the cancel command reported in the log, using http://localhost/... it in fact cancels the recording just fine. It's only when the web service issues it that it times out. I've now spotted another thread on the forums here related to Hauppauge drivers being corrupted on upgrades to widows 11 24h2 . That wasn't exactly my scenario, but the card was installed on windows 11 and the drivers upgraded later. I've fired off an email to Hauppauge support asking if they have a sequence that would completely delete, then install a fresh copy of the drivers. Bummer about the scammer. BTW I spotted a post on Haupaugge FAQ about timers allowing wake from sleep. Apparently there are timers, then important timers at least in some configurations. Requires using Control Panel. I posted that quote, and hopefully it didn't go to bogus users. As always, thanks for your input.

[mvallevand]

Yes it is not clear why only the stops are being blocked and only for you (apparently)

The issue isn't related to waketimers since your PC is awake. The only thing I am unsure of is that whatever is on physical channel 16 might not be locking which might cause additional issues.

I found a spammer post that both sub and I responded to and the user even told us he wasn't a spammer, AI can be a nuisance. Don't be frustrated by the experience if users don't post logs please continue to help by asking for them. I don't like having to do it.

Martin

[seattlefog]

I believe I've resolved my issue. I noted that localhost pinged at ::1 (ipv6). After issues with the request to cancel/end recordings, I tried to force it back to 127.0.0.1, even re-adding a HOSTS file to that effect. It still resolved to ::1. My final attempt was to edit the Windows 11 registry to prioritize v4 over v6. This caused localhost to resolve to 127.0.0.1 and the recordings now end  without a webservice timeout. My theory is that the request to cancel a recording issues an explicit v4 request (perhaps specifying 127.0.0.1), but the binding on the web service target or socket for localhost was for ipv6 causing the timeout. That's probably something @sub could confirm in about 30 seconds. If my supposition is correct, I would expect more Windows 11 + V7 issues to crop up over time, since it appears that Windows 11 really loooves to force v6. In any event thank you again for the time you spent on this issue.

[mvallevand]

I noted it might be ipv6 related, maybe you don't have working ipv6 or have it firewalled or routed properly? I tested with curl and the tuner server will respond on ipv6.

If ipv6 isn't working you should probably disable it. Check if ping -6 localhost works or is very slow.

Also on the server try http://[::1]:8866 to see if the NextPVR responds.

Martin

[sub]

If it's managing to start the stream using localhost, then I wouldn't expect it to be any different for when accessing localhost to stop the stream. They both done exactly the same way.

[seattlefog]

Previously, I uninstalled Bitdefender, then ran for multiple days with Windows firewalls off to no avail. So I think that can be eliminated as a suspect. It pings fine (both before and after remediation) on ipv6. NextPVR comes up and works great on http://[::1]:8866. Communication to other PCs on my local network appear to work find on ipv6. Just a reminder that the start recording commands to localhost and port worked fine; only the stop command failed. That's why I'm speculating that something about how that singular command is sent triggers the issue, rather than a more general problem. BTW NextPVR works fine with the NIC disabled and no DNS whatsoever.  Start, playback, and stop recordings all work fine; no external network needed for those functions. This is a 6 year old computer that served the first 5 years of its life as my primary desktop PC, so whatever the issue, it's subtle, and as far as I can tell NextPVR specific. I'm just happy that things are again working as they should. No more 30 minute shows that record for 12 hours. 

[seattlefog]

If it's managing to start the stream using localhost, then I wouldn't expect it to be any different for when accessing localhost to stop the stream. They both done exactly the same way.

Me neither. Thanks for weighing in. As you can see from my response prioritizing ipv4 vs ipv6 resolved my issue for whatever reason.