Database locked error

[ceejayemm]

Martin

I use a shared folder from my OpenMediaVault NAS (CMHomeNAS2.lan) to provide the folder where the recordings are stored.  This folder is mounted to the RPi via NFS. Until now this share has been available from the NAS from 07:00 until 22:30 - in between these times if the NFS share is not being used it will 'go to sleep'. This is the cause of the 'error' you are seeing . The share has 'gone to sleep' and the PI is waiting on it rewakening at 07:00 and you will also see this happening. I have, as an experiment, suspended the disconnection of the NFS shares from tonight to see if this is part of the problem (but I don't think it is).

All of the other NextPVR stuff, including the database, config files etc are provided by a local, always available, SSD mounted as per the Raspberry official instructions to allow a RPi 4B to boot from an SSD. So the server should be as quick as it is possible for a RPi of this configuration to be. The network is a wired 1GB network with short cables between the RPi and the NAS so I don't think there are problems here.

PostProcessing DOES complete, in the case of 'Romancing the Stone' (last night) in around 38 mi ns. I did note however that Comskip, according to its logfile - see snippet below, thinks it should run slowly because the time it is running but i don't know how this is implemented or whether it can be changed at this point in time.

################################################################
Generated using donator Comskip 0.82.010
Time at start of run:
Sat Jun 12 22:15:01 2021
################################################################
ComSkip playing nice due as per command line.
Mpeg: /home/pi/nas_recordings/Films/Romancing the Stone (1984)/Romancing.the.Stone.(1984).ts
Exe comskip.exe
Logo: /home/pi/nas_recordings/Films/Romancing the Stone (1984)/Romancing.the.Stone.(1984).logo.txt
Ini: /home/pi/Comskip/comskip.ini

Detection Methods to be used:
1) Black Frame
2) Logo - Give up after 2000 seconds
3) Scene Change
4) Resolution Change
5) Aspect Ratio
6) Silence


ComSkip throttles back from -0001 to -0001.
The time is now 2215 so comskip is running slowly.


Chris

[ceejayemm]

Sub / Martin

Setting the <SchedulesDirectDaysOvernight> setting to 7 in config.xml and stopping the NAS from going to sleep has resulted in the EPGUpdate working correctly - up to a point.

The update started at 02:45 as normal and progressed until:

2021-06-14 02:47:01.008 [ERROR][28] (23 - CCXTV): Date requested (2021-06-14) not within  ->  for stationID 116252.

It then continued continued until:

2021-06-14 02:47:50.048 [DEBUG][28] legacy tuning requesting target rtp://192.168.86.225:8020
2021-06-14 02:47:50.070 [DEBUG][28] Requesting: rtp://192.168.86.225:8020
2021-06-14 02:47:50.073 [DEBUG][28] RTP input source starting
2021-06-14 02:47:50.149 [DEBUG][28] StartStream [sink] allocated handle: 1
2021-06-14 02:47:50.149 [DEBUG][28] StartStream() returned handle=1
2021-06-14 02:47:50.149 [DEBUG][28] Allocated Handle: 1
2021-06-14 02:47:50.401 [ERROR][71] TS continuity counter indicates missing packets
2021-06-14 02:47:50.402 [DEBUG][71] Have received 1316 bytes from rtp source
2021-06-14 02:47:50.477 [ERROR][71] TS packet damaged
2021-06-14 02:47:50.477 [ERROR][71] TS packet damaged
2021-06-14 02:47:50.571 [ERROR][71] TS continuity counter indicates missing packets


when the 'TS packet damaged' and 'TS continuity counter indicates missing packets' repeated continuously until:

2021-06-14 02:51:57.513 [ERROR][17] TS packet damaged

It then continued normally until:

2021-06-14 02:53:05.558 [DEBUG][28] Starting: bash -c "'/var/opt/nextpvr/scripts/PostUpdateEPG.sh' "

2021-06-14 02:53:15.562 [DEBUG][28] /var/opt/nextpvr/scripts/PostUpdateEPG.sh has completed
2021-06-14 02:53:15.585 [INFO][28] Finished updating EPG


Looking at the Guide in the Web App I seem to have TV programme listings through to Monday June 21st which is roughly in line with setting the <SchedulesDirectDaysOvernight> setting to 7.

So other than figuring out what causes the remaining errors above for:

a) (23 - CCXTV): Date requested (2021-06-14) not within  ->  for stationID 116252
b) TS continuity counter indicates missing packets
c) TS packet damaged
d) the spurious (?) 'legacy tuning requesting target rtp://192.168.86.225:8020' (which seems to be the PI itself ?)

I will set the <SchedulesDirectDaysOvernight> setting back to 15 tonight and then, if that is OK, turn the NAS 'sleep mode' back on again the following night.  

I still can't see why allowing the NAS share to sleep has the effect of upsetting the EPG update as this share ONLY contains the recorded program files. Why would the EPG Update process need access to these recordings ?

Thanks for your help so far, I think we are getting there but not quite there yet. I have uploaded this full set of improved logs.

Regards.

Chris

[mvallevand]

I don't think it is the EPG, but it could be recording list requests from Kodi that want access to your drive. I could also be network congestion.

Answering

a. Contact SD if you think they should have more data for CCXTV. NextPVR does turn it into a problem by ignoring the SD message when the say data is not available by continuing for future days, but this is a long time issue.

b-d You are requesting OTA data in addition to SD data for some channels. Change to SD if you can. For the errors you would need to to capture a full mux and send it to sub, there is a possibility it is valid if it is a marginal signal.

Martin

[ceejayemm]

Martin

Thanks for your response. 

The Kodi updates seem a reasonable possibility. 

Sub - is there any way that such Kodi update requests could be suspended for the duration of the EPG Update ?  The EPG is more useful to me than making sure Kodi is updated in the middle of the night :-)

I don't actually need CCXTV (whatever that is) so I will simply delete it from my Channels list ?  Similarly with the other odd channel that get updated via the DVB/ATSC EPG setup. Is it simply a case of 'unticking' these channels in Channels section of NextPVR or do I actually need to delete them somehow ?

Thanks again for your help and advice.

Chris

[mvallevand]

If turning off the NAS overnight is necessary, and it turns out to be the problem, to me the simple solution would be to to set your EPG update to happen shortly after the NAS is online in the morning. Matrix Kodi clients will update the EPG cache after the EPG is signaled by NextPVR, older clients, won't be able to record from the guide until the timed update occurs.

Deleting is actually via ticking and clicking the trash can. Untick all first!

Martin

[sub]

I don't actually need CCXTV (whatever that is) so I will simply delete it from my Channels list ?  Similarly with the other odd channel that get updated via the DVB/ATSC EPG setup. Is it simply a case of 'unticking' these channels in Channels section of NextPVR or do I actually need to delete them somehow ?

You can just delete them if you don't need them. I delete a handful of garbage channels whenever I scan my locals.

(otherwise you have to create a group that doesn't have them selected, and select that group....easier to just delete them)

[ceejayemm]

Sub / Martin

Over the last few days I have:

1. Turned of the NAS auto-sleep function and reset the SD download options (in config.xml) back to 15 days but left the update time at 02:45 - EPG updated correctly but still with oddities (a-d) listed earlier

2. Removed the CCXTV and other channels not updated via SD - errors a-d went away

3. Moved EPG update time to 07:02 - EPG updated correctly and no other errors

4. Re-instated NAS Auto sleep (it wakes up automatically at 07:00) - EPG updates correctly and no other errors.

I think, as you surmised, that we can put this problem down to the KODI update not liking the NAS data store not being available and that it was co-incidence it happened during the EPG update process.

Thanks for your help and patience.

Chris