Committed writes of log data to the nrecord.log can be delayed up to 18 hours during inactive periods of the DVR, for example late in the evening until the next evening when recordings begin again. I presume the use of a Buffered Writer object or similar programming object/technique. I haven't noticed buffered data committed to other logs after a delay, but please search the code base for other instances of delayed buffer writes and commit these writes immediately.
Having an incomplete log prevents monitoring and responding quickly to recording errors and similar DVR event monitoring.
I've attached some logs that illustrate the delay, opening the earlier version of the logs you can see a partial truncated line of log info committed at the end of nrecord.log, and the rest of the line and dozens to hundreds more lines of data not showing up for hours until some event triggers more logging activity that presumably exceeds the buffered write threshold and gets the stale data written to the log. I'm using the latest version 6.1.1.221106 Available (6th Nov 2022) on Linux Mint 21(.0 confirmed, the sys info no longer displays minor version number) and the delayed buffer writes have been in place over 1+years of NextPVR releases.
Also, opening the browser TV Guide at http://localhost:8866/guide.html causes the beginning of thousands of log writes lasting well over half an hour to be written to nrecord.log - since these are apparently activities related to just building TV Guide data and Scheduled Recording data and Channel lists for the web browser GUI tabs and/or database table maintenance and not DVR recording activities, I would ask that non-recording logging entries have their own log file like guiinterface.log or dbmaintenance.log rather than clog the nrecord.log. Opening http://localhost:8866/settings.html will generally trigger a few lines of log data that will commit hours-old writes to nrecord.log without triggering the half-hour+ thousands of log lines initiated by opening the guide.html
Having an incomplete log prevents monitoring and responding quickly to recording errors and similar DVR event monitoring.
I've attached some logs that illustrate the delay, opening the earlier version of the logs you can see a partial truncated line of log info committed at the end of nrecord.log, and the rest of the line and dozens to hundreds more lines of data not showing up for hours until some event triggers more logging activity that presumably exceeds the buffered write threshold and gets the stale data written to the log. I'm using the latest version 6.1.1.221106 Available (6th Nov 2022) on Linux Mint 21(.0 confirmed, the sys info no longer displays minor version number) and the delayed buffer writes have been in place over 1+years of NextPVR releases.
Also, opening the browser TV Guide at http://localhost:8866/guide.html causes the beginning of thousands of log writes lasting well over half an hour to be written to nrecord.log - since these are apparently activities related to just building TV Guide data and Scheduled Recording data and Channel lists for the web browser GUI tabs and/or database table maintenance and not DVR recording activities, I would ask that non-recording logging entries have their own log file like guiinterface.log or dbmaintenance.log rather than clog the nrecord.log. Opening http://localhost:8866/settings.html will generally trigger a few lines of log data that will commit hours-old writes to nrecord.log without triggering the half-hour+ thousands of log lines initiated by opening the guide.html
