I have a docker container running nextpvr on a Core i3-1315U nuc running Ubuntu 24.04 server. I am running a record of a 720p baseball game and seeing about 40% (of a core) usage with Recording Auto Transcode set to Leave Recording in Native Format. I attached a log for the start of the recording a bit of the recording. It seems like it might be transcoding, but I am not sure why?
I am just wondering if this seems like a reasonable about of CPU usage for a single recording? I was hoping to scale up to many more recordings in parallel and figuring out how to partition the CPU on this machine (or if I would need another machine).
This week-end, where I live, we set clocks forward by one hour (daylight savings). The time change happened Sunday morning at 2:00am: When it used to be 2:00am, it is now 3:00am.
I had a program recording scheduled Sunday night (yesterday, after the time shift), at 9:10pm. Today, I noticed the recording started only an hour later than expected (10:10pm).
I tried to understand what may have caused it. I remembered the daylight saving time, and thought this may be related. I took a look at the TV Guide tab of the web interface of NextPVR: the vertical line of the time indicator properly indicates the current time (but I have no idea if this was the case yesterday).
However, I headed over to the "Scheduler" tab, and noticed that the start times of all my scheduled recurring recordings are all:
set back by an hour in the "Pending" list (e.g. if a recording used to start at 9:05pm, it now reads "10:05pm")
set forward by an hour in the "Recurring" list (e.g. if a recording used to start at 9:05pm, it now reads "8:05pm")
As a side note, I tested further: After scheduling a new recording by pressing the (+) icon, the new recording list item displays:
the correct start time in the "Pending" list
the wrong start time in the "Recurring" list (time is set back by an hour, now)
The clock of my NAS that hosts my NextPVR Docker container is updated properly and follows the daylight saving time properly (just confirmed).
I restarted by docker container, updated the Scheduler web page (Ctrl-F5), and the start times are still offset...
Have you ever faced this type of issue? Do you know what may be causing it?
I have been having problems with my Nextpvr client application. Web app seems to work perfectly. And the "other client" option in the web client menu works perfectly. But the client *.exe crashes and I have delete the process and restart the server to clear the problem.
This all started a week ago when I was trying to fix an on-going audio sync problem when using the "NextPVR.exe". The only way I could get playback of any show with proper audio sync was to use a 3rd party playback app like VLC OR the NextPVR WEB app OR the yauiclient. But recently that app also started crashing.
Logs are attached. I am now just leaving the server running and browsing the recorded shows folders using a 3rd party app for playback. I AM able to use the web app but at this point using a 3rd party media player is what works best. Yesterday after several days of work I also uninstalled Nextpvr completely and installed a new clean install. No change still crashing. (used Revo uninstaller and wiped all traces of NextPVR from system AND ran every windows 11 system check possible which shows no problems.
This all started several weeks ago when I was browsing this forum and found a recent post about continuing audio sync problems which is still un-resolved as of last night. I fear all my attempts at fixing this may have made things worse ?
This problem seems like something others must have come across before but I can't find a single discussion of it here.
I have postprocessing.bat calling a ffmpeg copy but it errors out on a path / filename with spaces. I have the "%1" in quotes but I guess after the %1 is expanded out to the passed path and filename, the quotes are lost, and ffmpeg fails...
Logs attached as well as my postprocessing.bat. I don't even know if the rest of it works, I can't get past passing the input file yet. haha
There's an example of the failure in nrecord.log at 2025-03-29 12:25:00.184
I have some recent instances of getting multiple recordings of the same event. An example is the 2025 NCAA Men's Basketball Tournament.
Attached are the logs. Did I set the scheduler incorrectly? I clicked on the item in the guide and setup a recurring recording to catch all the games airing OTA.
I experimented different scanning duration for the DVB/ATSC EPG (found under "Settings > Guide > (cog icon, for DVB/ATSC EPG, on the right-hand side))"). Default value is 60 sec.
I identified a sweet spot at 6 sec.
When set to 5 seconds, the DVB/ATSC EPG doesn't have enough time to download the data. When set to 6 seconds, it successfully downloads it.
This is only my own experience; YMMV.
I could imagine users with many channels, polling the DVB/ATSC signal, for a minute, for each channel... This could take a long time, even if at night it's less problematic.
What about reducing the default value to, maybe, 10 seconds?
Maybe you have good reason to set it to 60 seconds by default (I don't know).
I've started experience weird behavior when watching recordings. If I frequently pause/resume, that seems to trigger the issue. Playback will become erratic (audio is ok) and I can no longer pause/exit/stop the playback. If I kill the client (yauiclient in this case), the NPVR tray icon is gray and I cannot use the web browser to get the logs until I reboot.
I was watching this:
D:\nextpvr\KPAX 530 News\KPAX 530 News_20250326_17301800.ts
nrecord.log.1 (the issues started before this time if that helps)
2025-03-26 18:32:34.502 [DEBUG][5] ClientGetActivity() returning:
{
"level": 4,
"action": "pause"
}
You can see that the logging just stops at 2025-03-26 18:32:35.705
Hope this helps. Let me know if you need anything else.
Art
I'm using version: 7.0.1.241229 with a Docker arm32v7. I am able to reproduce a problem here. If a recording is in progress and if I click the "Update EPG" button in the settings, as soon as the progress hits a channel that is set to a DVB EPG, this aborts the recording. It doesn't seem the XMLTV EPG format causes any problem, from my tests so far. I have attached the log files.
Hi! I think Zap2it site is gone, so that means I won't be able to use the epg guide on nextpvr. Heres another sife that I found, but I can't seem to use it for nextpvr. https://tvlistings.gracenote.com/grid-af...ml?aid=lat
