NextPVR Forums

No new recording since 4/16. I did a system update that day, Arch linux, which I suspect has something to do with the problem. This has happened previously but infrequently. What seems to get things going again is a reboot and then in NextPVR go to "Scheduler" and "Recurring" and selecting each title one by one and clicking ok. This reinitiates the recording process and everything is fine for quite a while.

I'm not sure if there is a way to see what programs were upgraded during a specific upgrade process or if that is even helpful.

I've attached logs but I had to remove some items to meet the 2mb quota. Maybe I need to change a setting but my nrecord.logs are 3.8mb each.

Thanks,

Craig

4MB nrecord.logs are normal. Don't remove too much and if necessary use OneDrive, GoogleDrive or one I've been using filetransfer.io when attaching fails.

Martin

I still have the data, I limited what was included in the current upload. If more is needed I can upload to GoogleDrive.

But nothing was attached

Martin

Link to log files

https://drive.google.com/drive/folders/1...sp=sharing

Thanks for the complete logs, I wanted to check the spammy DeviceHostLinux logs that I expected were causing the large file size. The problem is likely caused by the 6.1.5 style IsComplete bug disabling the tuners. Sub has fixed this for 6.1.6 but for now just restart the server. If you don't use thumbnails or timing files you can turn them off.

I see you still don't have a good PreStartup.sh script I mentioned this to you a few years ago https://forums.nextpvr.com/showthread.ph...#pid551616 This might still have a negative impact on scheduling recordings.


Martin

Martin,

I have it in my npvr.service file

I did up the value from 14 to 20 just now

Ok I guess you need to check dmesg to see if 20 seconds is enough and your script works, I only support the deb installer, not custom setups.

Martin

Thanks Martin,


I appreciate your assistance.  Since reboot time really isn't that critical to me I am going to change to 30 which should be overkill. The failure happened at 14s, according to my scan of prior boots in journalctl, which was my setting.

Based on dmesg the tv card was allocated in under 9s on the last boot