New recordings not updating

[mvallevand]

It is the correct log but you need to enable debug level. I do it in advanced settings.xml so it is always on

In the Kodi settings there is an option to reset the database. It is necessary when you rescan NextPVR or change tuners

Martin

[Bobins]

OK PVR database is reset/reloaded, Kodi debug turned on and RPI rebooted ... I'll monitor now for the update stopping.

[Bobins]

Ok. This seems pretty consistent in that the stopping of the update happens relatively shortly after a reboot of the RPIs.
Haven't been able to pin down a specific trigger although I was watching live TV on the Kodi and stopped watching 1 minute before the updates stopped..
Attached is the web.log and Kodi log (with debug on).
The updating stops about 15:44.

[mvallevand]

Ok it would have been nice to get all the web logs but in any case, I think this is the crappy ethenet in the RPi is really causing you a lot of grief. All those EAGAIN calls are blocking on the network that I pretty much only see on the RPi. Seveal years ago I submitted a fix for streaming to handle them but looking at all those debug errors on http calls I think similar retry logic needs to be added to the the DoRequest() function.

Martin

[sub]

Yeah, it basically looks like one of the network calls fails, and some logic in the addon disables the method=recording.lastupdated call on the assumption it's running an old server which doesn't support it (which is not the case)

[sub]

Mike who did the recent timeshift changes to the addon is taking a look at the addon at the moment, so I've sent him a few lines of code to better handle this. I'm unable to compile the Kodi addon at the moment, so I've asked him to include the change.

[sub]

FYI, the change will only be included in Kodi 18, since that is what the current code base is.

[mvallevand]

Yeah, it basically looks like one of the network calls fails, and some logic in the addon disables the method=recording.lastupdated call on the assumption it's running an old server which doesn't support it (which is not the case)

The disable flag only occurs if the web server returns a web error. In this case the blocking is causing the file, so the line

while (XBMC->ReadFileString(fileHandle, buffer, 1024))

needs to handle the 0 return option with EAGAIN somehow

Martin

[sub]

13:28:59.691 T:1567617792 DEBUG: CurlFile::Open(0x5393050) http://192.168.2.4:8866/service?method=r...6b82cf85d9
13:29:18.197 T:1567617792 ERROR: CCurlFile::FillBuffer - Failed: Couldn't connect to server(7)
13:29:18.197 T:1567617792 ERROR: CCurlFile::Open failed with code 0 for http://192.168.2.4:8866/service?method=r...6b82cf85d9
13:29:18.197 T:1567617792 ERROR: Open - failed to open source <http://192.168.2.4:8866/service?method=recording.lastupdated&sid=f5d1ee45513d483ebda9d76b82cf85d9>
13:29:18.197 T:1567617792 NOTICE: AddOnLog: NextPVR PVR Client: Disabling recording update. Update NextPVR to v3.4

The fix I've requested is to remove this disabling logic, since no one is running old pre v3.4 releases these days.

[mvallevand]

The easy fix I've requested is remove this disabling logic, since no one is running old pre v3.4 releases these days.

That is what I figured but based on the last set of logs that won't fix it, since the logs show that all the calls to lastupdated were failing with length 0 even though the web server was returning the correct time.

Martin