5 hours ago
Hi all,
I run NextPVR inside a Proxmox Linux (Debian) container, installed through the nextpvr-helper.deb package. I passed-through the USB TV tuner device (Hauppauge TV WinTV-dualHD model 01590) to the container and it works like a charm.
I have however found an anomaly that more than one time compromised the DVB recordings I have scheduled: the recording of DVB streams is interrupted by scheduled EPG updates, if that operation takes place during the time of the recording and is performed via the DVB tuner (Settings > Guide > EPG Sources = 'DVB/ATSC EPG' for at least one channel) and not via XML resources ('XMLTV').
The possible workarounds are:
I actually have put in place the second workaround since a while, except for forgetting about it when I tuned a new DVB channel that become recently available. This event triggered this bug again.
Ideally, it would be nice if EPG update from DVB is not performed if the tuner device is busy while recording.
Hope this was of help for others with unexpected interruptions of their DBV recordings.
Cheerz
A.
My configuration:
To reproduce:
Evidence (relevant excerpts from device-adapter0.log):
# Scheduled recording starts OK at 21:00
2025-10-11 21:00:00:064 [DEBUG] starting stream: /shared/private/NEXTPVR_OUT/Easy A/Easy A_2025-10-11_21102245.ts
2025-10-11 21:00:00:840 [INFO] Creating writer for: /shared/private/NEXTPVR_OUT/Easy A/Easy A_2025-10-11_21102245.ts
# Scheduled recording keeps on going until 21:55
[i][...][/i]
2025-10-11 21:55:30:977 [DEBUG] Received 2107889276 bytes from device so far
2025-10-11 21:55:36:010 [DEBUG] Received 2111393032 bytes from device so far
2025-10-11 21:55:41:038 [DEBUG] Received 2115303996 bytes from device so far
[i]# Scheduled EPG update kicks in at 21:55, caused by the only channel that was set to retrieve that data from DVB/ATSC EPG[/i]
2025-10-11 21:55:42:294 [INFO] received request
2025-10-11 21:55:42:294 [DEBUG] about to process request...
2025-10-11 21:55:42:294 [DEBUG] got 348 bytes
2025-10-11 21:55:42:294 [DEBUG] got request:
POST /stream/start?slipseconds=120&pids=18 HTTP/1.1
POST /stream/start?slipseconds=120&pids=18 HTTP/1.1
Host: localhost:35017
Connection: Keep-Alive
Content-Type: application/xml
Content-Length: 194
<tuning>
<type>DVB-T</type>
<name>LA7CINEMA</name>
<locator>
<conf>506000000OFF</conf>
</locator>
<service_id>752</service_id>
<service_type>27</service_type>
</tuning>
2025-10-11 21:55:42:294 [DEBUG] resource: /stream/start?slipseconds=120&pids=18
2025-10-11 21:55:42:294 [DEBUG] ProcessRequest@1
2025-10-11 21:55:42:294 [DEBUG] resource: /stream/start?slipseconds=120&pids=18
2025-10-11 21:55:42:294 [DEBUG] ProcessRequest@1
2025-10-11 21:55:42:294 [DEBUG] ProcessRequest@1.1
2025-10-11 21:55:42:294 [DEBUG] ProcessRequest@1.2
2025-10-11 21:55:42:294 [DEBUG] ProcessRequest@1.3
2025-10-11 21:55:42:294 [DEBUG] ProcessRequest@1.4
2025-10-11 21:55:42:294 [DEBUG] ProcessRequest@done
2025-10-11 21:55:42:294 [DEBUG] starting stream: /tmp/stream.ts
2025-10-11 21:55:42:294 [DEBUG] slip seconds: 120
2025-10-11 21:55:42:294 [DEBUG] LA7CINEMA (sid=752)
2025-10-11 21:55:42:294 [DEBUG] on request adapter0, frontend0
2025-10-11 21:55:42:296 [INFO] Tuning: 506000000 Hz
2025-10-11 21:55:42:296 [INFO] Changing frequencies
[i]# Above EPG update operation killed the ongoing DVB recording, despite on a different channel and frequency[/i]
2025-10-11 21:55:42:296 [INFO] Stopped recording (/shared/private/NEXTPVR_OUT/Easy A/Easy A_2025-10-11_21102245.ts)
I run NextPVR inside a Proxmox Linux (Debian) container, installed through the nextpvr-helper.deb package. I passed-through the USB TV tuner device (Hauppauge TV WinTV-dualHD model 01590) to the container and it works like a charm.
I have however found an anomaly that more than one time compromised the DVB recordings I have scheduled: the recording of DVB streams is interrupted by scheduled EPG updates, if that operation takes place during the time of the recording and is performed via the DVB tuner (Settings > Guide > EPG Sources = 'DVB/ATSC EPG' for at least one channel) and not via XML resources ('XMLTV').
The possible workarounds are:
- schedule EPG updates only once per day, at a time when you are unlikely to record anything from the DVB tuner, for example 5:00 AM
- unset EPG from 'DVB/ATSC EPG' from ALL the channels and use exclusively 'XMLTV' instead: EPG update from the web does not interfere with DBV tuner recordings
I actually have put in place the second workaround since a while, except for forgetting about it when I tuned a new DVB channel that become recently available. This event triggered this bug again.
Ideally, it would be nice if EPG update from DVB is not performed if the tuner device is busy while recording.
Hope this was of help for others with unexpected interruptions of their DBV recordings.
Cheerz
A.
My configuration:
- Settings > Channels > at least one channel is set with EPG Source = DVB/ATSC EPG
- Settings > Guide > Automatic EPG Update = 06:55:00,21:55:00 (now changed to 05:00)
To reproduce:
- Schedule the recording of any event on any channel via DVB tuner whose duration overlaps with the scheduled Automatic EPG Update via the same tuner, say from 21:00 to 23:00
- Result: the DVB recording is interrupted at the time of the EPG update, in this case 21:55, with no error shown in GUI
Evidence (relevant excerpts from device-adapter0.log):
# Scheduled recording starts OK at 21:00
2025-10-11 21:00:00:064 [DEBUG] starting stream: /shared/private/NEXTPVR_OUT/Easy A/Easy A_2025-10-11_21102245.ts
2025-10-11 21:00:00:840 [INFO] Creating writer for: /shared/private/NEXTPVR_OUT/Easy A/Easy A_2025-10-11_21102245.ts
# Scheduled recording keeps on going until 21:55
[i][...][/i]
2025-10-11 21:55:30:977 [DEBUG] Received 2107889276 bytes from device so far
2025-10-11 21:55:36:010 [DEBUG] Received 2111393032 bytes from device so far
2025-10-11 21:55:41:038 [DEBUG] Received 2115303996 bytes from device so far
[i]# Scheduled EPG update kicks in at 21:55, caused by the only channel that was set to retrieve that data from DVB/ATSC EPG[/i]
2025-10-11 21:55:42:294 [INFO] received request
2025-10-11 21:55:42:294 [DEBUG] about to process request...
2025-10-11 21:55:42:294 [DEBUG] got 348 bytes
2025-10-11 21:55:42:294 [DEBUG] got request:
POST /stream/start?slipseconds=120&pids=18 HTTP/1.1
POST /stream/start?slipseconds=120&pids=18 HTTP/1.1
Host: localhost:35017
Connection: Keep-Alive
Content-Type: application/xml
Content-Length: 194
<tuning>
<type>DVB-T</type>
<name>LA7CINEMA</name>
<locator>
<conf>506000000OFF</conf>
</locator>
<service_id>752</service_id>
<service_type>27</service_type>
</tuning>
2025-10-11 21:55:42:294 [DEBUG] resource: /stream/start?slipseconds=120&pids=18
2025-10-11 21:55:42:294 [DEBUG] ProcessRequest@1
2025-10-11 21:55:42:294 [DEBUG] resource: /stream/start?slipseconds=120&pids=18
2025-10-11 21:55:42:294 [DEBUG] ProcessRequest@1
2025-10-11 21:55:42:294 [DEBUG] ProcessRequest@1.1
2025-10-11 21:55:42:294 [DEBUG] ProcessRequest@1.2
2025-10-11 21:55:42:294 [DEBUG] ProcessRequest@1.3
2025-10-11 21:55:42:294 [DEBUG] ProcessRequest@1.4
2025-10-11 21:55:42:294 [DEBUG] ProcessRequest@done
2025-10-11 21:55:42:294 [DEBUG] starting stream: /tmp/stream.ts
2025-10-11 21:55:42:294 [DEBUG] slip seconds: 120
2025-10-11 21:55:42:294 [DEBUG] LA7CINEMA (sid=752)
2025-10-11 21:55:42:294 [DEBUG] on request adapter0, frontend0
2025-10-11 21:55:42:296 [INFO] Tuning: 506000000 Hz
2025-10-11 21:55:42:296 [INFO] Changing frequencies
[i]# Above EPG update operation killed the ongoing DVB recording, despite on a different channel and frequency[/i]
2025-10-11 21:55:42:296 [INFO] Stopped recording (/shared/private/NEXTPVR_OUT/Easy A/Easy A_2025-10-11_21102245.ts)