I'm on Version: 7.1.1.260616 on a Windows 10 PC with clients that are all RasPi, Onn, Fire.
I had a secondary recording location that was pointed at my NAS on my network. It was called "DS418play". The path was "\\DS418play\TV Shows\NextPVR Recordings\". That setup worked fine for years. I recently got a new NAS. I named it "DS1618". The folder structure is the same, so I updated the recording location to "\\DS1618\TV Shows\NextPVR Recordings\"
For some reason, that causes a problem. I can get TV to play on a client for maybe 30 secs, sometimes longer, and then an error will pop up that says timeshifting is disabled, and the stream stops shortly after. To test, I renamed my NAS "DS418play" (the same name as my old NAS and old file path, even though this is a DS1618 NAS now). That made the errors stop and playback was fine again. I changed the names to DS1618, error started again.
Has anyone else experienced this? Is there a fix? I did export the logs zip file, but I'm unsure what specifically would be needed from it. Thanks in advance!
Martin,
In this case, I accidentally exited playback during a game, then hit play to resume and wound up on a blank (blue) screen. I've had this issue happen before, but wasn't at a good spot to capture a log. Usually I'm recording several games and jumping around between them. So a bit of a stress test.
I think this is around the point of interest in the log
2026-09-27 11:09:09.184 [DEBUG][8] Got request [10.8.19.77]: /control
This is from a client machine.
After restarting or removing the sid from the json file the recording has lost the resume position.
Art
Hi,
I'm running NextPVR in the official Docker container nextpvr/nextpvr_amd64 on Unraid.
I noticed playback issues while testing my recordings.
The host also has an Intel Arc A310, but that GPU is bound to vfio-pci and is not used by NextPVR.
The Arrow Lake iGPU is exposed to the NextPVR container as: /dev/dri/renderD128
The mapping on the host is:
pci-0000:00:02.0-card -> ../card1
pci-0000:00:02.0-render -> ../renderD128
NextPVR runs as root, so this does not appear to be a permissions issue. 1. VAAPI / web playback
With VAAPI enabled in NextPVR, playing a recording in the web interface fails with: Failed to start requested stream
[AVHWDeviceContext @ ...] libva: /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so init failed
[AVHWDeviceContext @ ...] libva: /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so init failed
[AVHWDeviceContext @ ...] Failed to initialise VAAPI connection: -1 (unknown libva error).
Device creation failed: -5.
Failed to set value '/dev/dri/renderD128' for option 'vaapi_device': Input/output error
Error parsing global options: Input/output error
The versions installed in the NextPVR container are:
ffmpeg 5.1.9-0+deb12u1
intel-media-va-driver-non-free 23.1.1+ds1-1
libva2 2.17.0-1
libva-drm2 2.17.0-1
I also tested what upgrading the VAAPI stack from Debian Trixie would require. It would provide:
intel-media-va-driver-non-free 25.2.3
libva 2.22.0
libdrm 2.4.124
but it would also upgrade libc and several other core packages from Debian 12 to Debian 13, so I did not perform that upgrade.
As soon as I disable VAAPI in NextPVR, web playback works correctly.
Therefore this seems to be specifically related to the Intel VAAPI/media-driver version in the current NextPVR container and Arrow Lake-S.
Interestingly, Plex is running on the same Unraid server with the same /dev/dri device exposed and ships its own iHD_drv_video.so and works fine.
My questions is:
Is the Intel media-driver included in the current NextPVR Docker image known to be too old for Arrow Lake-S, and is there a plan to update it?
Posted by: jrockow - 2026-09-25, 11:32 AM - Forum: Windows
- No Replies
When you're all caught up with life and have nothing better to do, think about this.
Would it be possible to somehow distinguish the different device channels in the web TV guide?
For example the 6 channels in device 1 would be displayed in red, the 6 channels in device 2 would be displayed in green, etc.
Sometimes I have duplicate channels in 2 or more devices and this would make it easier to select which one I want to record from.
I realize you've got a lot on your plate, just something to tuck away in your mind as a future enhancement.
Thanx for all your hard work.
I was going to replace this recurring recording, but wanted to look at the details first by clicking on the Update button when the hang occurs.
I see some exceptions shortly after this point in the nrecord.log
2026-09-19 09:03:52.033 [DEBUG][71] LoadListingByAdvancedRules(channel='all channels',advancedRules=title like 'Woodsmith Shop')
I had to remap the PBS channels some time ago, thus the 0 for the channel. I just hadn't bothered to update them since they kept recording.
Art
I installed windows and NPVR on my current computer a year ago. After about 6 months I had trouble with frequent computer freezing (blank screen and not responding to inputs) and considered that I may have had an issue with an well used video card, and the event viewer show a couple of errors.
Last month I removed the card, reinstalled Windows 11 and NPVR. Things ran very well until this week and two days in a row I had to reboot a non-responsive computer. I can not tell from the Windows logs what time this may be happening, and the only errors I see are com related to NPVR? The computer in question is just used as a media player (NPVR and occasional videos). Windows update is on automatic.
I ran disk and memory diags on the computer and it looked ok.
Is it possible for someone to see if there is any info in the logs that may help, even though it does not seem to be an issue during active recording?
log should be attached mkroc logs 9_16_26.zip
I am running yauiclient v3 in linux mint 22.3 and it works well except that every several days it crashes with gigabytes in the log file. I started it a few days ago and noticed that something was looking for or trying to write yauiclient.conf in my .yauiclient directory. This is a greatly trimmed log file with what I think has the details. I cleared out the log files, started yauiclient, and waited for the crash. Can you tell me what is causing this and what I need to do to correct it?
Hi.
Not sure exactly when it started but I have had issues recently where when the start padding overlaps a recording in progress, it will stop the recording and start the later one, chopping the end of the show off, in my case exactly 6 minutes. I've been using NPVR since V4 and only had this problem on later versions of V7. Previous behaviour would swap the recordings over exactly on the start/stop time, say 7pm but now it swaps at 6.54pm.
My setup has 2x astrometa DVB-T2 USB receivers and one TBS 6902 and the problem only affects the 6902 when one recording follows another on the same tuner. The 6902 is priority 1 for recording.
For now I've found an older version 7 on videohelp and installed that so I'll see how that goes. I did have a V5 which was fine but didn't store episode numbers so I'm trying 7.0.0.241105 to see if that rectifies it.
I think the astrometa are not affected as all channels are on the same transponder.
While researching something else, I came across the following statement in a post on The Green Button:
Quote:I'd hate to go back to the multiple HDPVR route alone.
This suggests that the writer had already done it, but I've never heard of such a thing: Is it really possible to attach more than one Hauppauge HDPVR to the same cable DVR, and have each HDPVR capture a different channel?
I asked the Brave Browser, and here's what it reported:
Quote:can i use more than one hd pvr with the same dvr
**Yes**, it is possible to use multiple HD-PVR devices with a single DVR setup, particularly when using software like **SageTV** or **NextPVR**.
* **Software Configuration**: In SageTV, you can configure the system to recognize and utilize multiple HD-PVR units, allowing them to tune to different channels simultaneously.
* **Channel Scanning**: Users have reported success by ensuring that **mc2xml** (used for TV guide data) is correctly configured; specifically, using a single token allows the system to handle multiple tuners without conflicts that might arise from separate guide downloads.
* **Tuning Independence**: Once configured, each HD-PVR can blast to its own channel independently, enabling the recording or viewing of different programs at the same time.
* **Limitations**: While multiple tuners allow for simultaneous recording, some legacy single-tuner DVRs or specific converter boxes may only allow one recording at a time, necessitating multiple hardware units to avoid conflicts.
As we know, this could be an AI hallucination, but then there's that TGB post. Has anybody successfully done this in NextPVR? Would it require three computers in addition to three HDPVRs? Would it work for a set-top box as well as for a DVR?
