Fails to disconnect from tuner!

[Bobbybear]

Recorded one program PC did not go to sleep after.
Restarted PC and recorded two programs consecutively with a 5 minute overlap, PC did not go to sleep after recording finished.
The PC then soon after recorded a scheduled program, still did not go to sleep after recording finished....
Re-started PC before bed time so it would sleep all night.
I have three log files if anyone wants to view them, decided not to clog the system with more junk...
Just wish v5 was as reliable as v4.
Bob

[Bobbybear]

Thought I had fixed this problem!!
Found a system image from before v5 install, rolled back PC.
Upgraded to Windows 11 Pro.
Reinstall v5 from scratch, seemed to run OK.
Uninstalled v4 by a different method to before.
NPVR v5 has run very successfully for 4 or 5 days without any problem until today. (Looks like I had a corrupt v5 install or corrupted v5 when I uninstalled v4!!)
But this morning:
Recorded a program from a two channel Sat tuner which is number 5 and 6 in my tuner list. (the channel only available on FreeSat)
Program was 30 mins long plus 30 minutes of buffers (15mins each end) the PC was still running after two hours, Tuner still connected.
Could not delete the recorded program from the web browser!
Map file and timer file in the program recording folder.
Saved the log file (attached)
Had to restart the PC to kill it. (maybe I could have stopped and restarted the server)
After restart, deleted program from the web browser page without any problems, but it left the program recording folder with a .map file in it.
So there is still a bug there somewhere.
Bob

[mvallevand]

I didn't look at the logs because there was an issue that sub needed to look at with second try recordings which he didn't comment on yet.

Martin

[Bobbybear]

Thanks Martin

Hopefully Sub can fix this for the next update/release

Bob

[sub]

Ultimately it is probably something to do with that first request to start the recording, which timed out. After that, the application assumes it failed to start, and it's never requested to stop.

It's not clear why it might have happened though, and why we're not seeing any other reports.

[mvallevand]

Even with the unexplanable failure my thought is when you do the second chance recording you should still close the first recording and map file and remove it from the table of in progress recordings.

Martin

[sub]

Even with the unexplanable failure my thought is when you do the second chance recording you should still close the first recording and map file and remove it from the table of in progress recordings.

It can't close that first recording, because it never got back the handle that identified the recording...so it can't say (for example) to DeviceHostWindows 'stop recording handle #6', because it doesn't know the handle number.

[sub]

The attached updated DeviceHostWindows.exe does some more detailed logging, which will hopefully tell us why it's not starting successfully.

[mvallevand]

It looked like the handle was returned though in that first set of logs 150001 is the failed one that never disappeared.

Code:

<rsp stat="ok">
<Status>
  <Device oid="21" identifier="TBS 6281 DVBT/T2 Tuner A (#0)">
    <Recording handle="150001">R:\Recorded TV\The Long Call\Season 01\The Long Call.S01E03.ts</Recording>
  </Device>
  <Device oid="22" identifier="TBS 6281 DVBT/T2 Tuner A (#1)">
    <Recording handle="160001">R:\Recorded TV\Shetland\Season 06\Shetland.S06E02.ts</Recording>
  </Device>
  <Device oid="23" identifier="TBS 6281 DVBT/T2 Tuner B (#0)">
    <Recording handle="170001">R:\Recorded TV\The Long Call\Season 01\The Long Call.S01E03.ts</Recording>
  </Device>
<Device oid="24" identifier="TBS 6281 DVBT/T2 Tuner B (#1)"> </Device>
<Device oid="25" identifier="TBS 6981 BDA DVBS/S2 A Tuner/Demod (#0)"> </Device>
<Device oid="26" identifier="TBS 6981 BDA DVBS/S2 B Tuner/Demod (#0)"> </Device>
</Status>
</rsp>

Martin

[sub]

It looked like the handle was returned though in that first set of logs 150001 is the failed one that never disappeared.

It didn't make it back when it started the recording, which was the key time it needed it (even though it did show in later status call). The logging looked like DeviceHostWindows quickly started the recording and returned the handle, but from the recording service side it time out waiting for the response, so it never got the handle.

This updated DeviceHostWindows with extra logging should help us get to the bottom of it.