Backend crash while navigating in-progress recording

[Allan]

Thanks for your attention, Martin and Sub.

For your information, the exact steps were as follows:

• I am watching an in-progress recording with the webOS app
  
• dotnet crashes while I am skipping through an ad
  
• the computer running the backend detects the dotnet crash and instantly restarts nextPVR (macOS launchdaemon configured to keep NextPVR running)
  
• resumption of the recording fails (my working theory is that the HDHR was still streaming to the crashed process and needed to time out or something. I have now added a prestartup.sh with a 30 second sleep to see if that helps in the future)
  
• I try to continue watching the in-progress recording, but just get a black screen. I try the MrMC (abandoned KODI branch) plugin, but also blank screen. I determine that I am watching the failed resumed recording and NextPVR has deleted the original file (per rule to keep only one recording of this program - I previously assumed it deletes the old only after it completes recording the new, which is what I was used to with MythTV).
  

[Allan]

I found this log in diagnostic reports.

[mvallevand]

Sub has started work on upgrading the libSkiaSharp libraries and initial testing looks promising.

One thing that for was noted was the LG OS app did not fail when the server failed so the playback state was likely confused. Next time if you are playing in a crash Exit from the main menu to do a clean restart. I am not sure the 30 seconds will be enough to cause the client to fail.

Martin

[Allan]

Crashed again while navigating in-progress recording in LG client. Before and after logs attached.
- running 7.0.2.250621
- the 30 second delay did not achieve a restarted recording when the backend restarted automatically. I eventually manually restarted recording.

In the case where (a) the backend crashes during recording; (b) the recording is restarted; and © scheduler is configured for "keep 1": the result is that the first part of the program is deleted. This is because the restarted recording is treated as a new recording, and because the algorithm deletes an "old" recording as soon as the new recording starts. I wonder what the rationale is for deleting the old recording as soon as the new recording starts, rather than after it is completed. Here, it causes a problem. In my view, it is also unintuitive - if you don't yet have the new recording and the old one is deleted, you have not kept 1.

[mvallevand]

There is a memory leak in UI clients in 7.0.2 that sub needs to look at. Unfortunately in my experience over the last decade UI clients do crash from time to time.

I wonder what the rationale for your keeping keep set at 1 when you know the problem since we discussed it before. While I understand the problem, the scenario which is not typical and sub never said he would look into it. Just use the delete at the end of recording prompt.

Martin