New recordings not updating

[sub]

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.

I'm no expert at reading kodi logs, but what log messages makes you think that?

[mvallevand]

14:41:32.385 T:1449128704 DEBUG: CurlFile::Open(0x64a5e388) http://192.168.2.4:8866/service?method=c...87e5e5fa2c
14:41:32.597 T:1440740096 DEBUG: Thread FileCache start, auto delete: false
14:41:32.597 T:1440740096 INFO: CFileCache:rocess - Source read didn't return any data! Hit eof(?)
14:41:32.647 T:1440740096 DEBUG: Thread FileCache 1440740096 terminating

The fact that the disabling only occurs on the 30 second timeout shows the network is the source of the problem not the web server so it doesn't really fix the problem Getting rid of it just means that it might update some time. The live tv playback shows the EAGAIN issue that the http call doesn't handle at all.

Martin

[sub]

I'm pretty sure the "CFileCache:rocess - Source read didn't return any data! Hit eof(?)" isn't saying it returned no data. It's just saying it's read until the end of the response. Likely means the last loop to read more data from the socket got no more data. ie, you'll see the same thing on the successful calls, like session.login

14:37:01.080 T:1905259264 DEBUG: CurlFile::Open(0x71048bb0) http://192.168.2.4:8866/service?method=s...C6E2FB065B
14:37:01.096 T:1549792000 DEBUG: Thread FileCache start, auto delete: false
14:37:01.096 T:1549792000 INFO: CFileCache:rocess - Source read didn't return any data! Hit eof(?)
14:37:01.146 T:1549792000 DEBUG: Thread FileCache 1549792000 terminating

[Bobins]

Just to add a bit of input. The network is hardwired Gigabit and this test was done on the latest RPi 3B+ hardware which is supposed to have better ethernet than the older models.
I assume the blocking being referred to is in the software handling the ethernet connectivity for Kodi on the RPi and not specifically the hardware.
From a bit of further testing, it looks like this update stop can consistently be triggered after watching live tv on the RPi.

[Bobins]

Sub. If you get to know when the change has been included in the v18 beta I'll happily test on one of my RPs's

[mvallevand]

The problem is not Kodi it is the network stack it does not handle things as gracefully as any other device I have seen and quickly returns no data warnings which originally the pvr adon wasn't handling for steaming. And your logs are full of these retries. This was fixed but the same problem was not fixed for API calls. Subs fix will mask the problem because it will continue to retry in the minutes and hours ahead.

There is no reason that things should get disabled now though. Thirty seconds is much too long for that call and if it isn't your RPI you need to get check your network.

Martin

[Bobins]

Thanks for the explanation Martin.
I'm pretty confident in my network not being the problem as I'm not seeing any network issues across any other devices attached. (and most of my rather long working life has been spent in IT hardware / system design . I do have some software writing experience but mostly on somewhat larger systems)
I do see the same problem consistently on all the RPi's so I think you're spot on with pointing to their poor network handling.
Shame considering they're pretty good for their overall cost/size.

[PapaJay]

Hi

I think I am hitting the same problem as Bruce. Here is my configuration:

NPVR Version= 4.1.1 (4.2.3 downloaded, but not installed)
Intel i3-6100 Quad Core + 8GB DDR2 Gigabyte Motherboard
Windows 10 Pro 64bit
HDHomeRun Connect tuner
250Gb SSD System Disk
2Tb WD Media Store

Raspberry Pi3 B+ running LibreELEC (Kodi v17.6)

Everything is connected via a hardwired gigabit LAN.

This is very similar to what Bruce is running.

What is happening in our case is that we record the CTV National News and then when we want to watch the latest recording, it is not in the list of recordings. The problem started after I upgraded the Raspberry Pi 3b from OpenELEC 7.0.1 (Kodi 16.1) to LibreELEC 8.2.5 (Kodi 17.6). Based on your analysis, I am guessing that there is some extra network load being put on the RaspBerry Pi network adapter by the new level.

After lots of reading of forum threads from several years ago I learned back in September that before the fix that checks every 60 seconds for updates, the NextPVR addon only checked the NextPVR server for updates when it was loaded (started) by Kodi, or when the user deleted a recorded show from the list.

Based on this, to workaround the problem in the current 17.6 code (easiest to most disruptive):

1) Delete a show that has been watched (and you don't want to keep) using the Kodi interface on the Raspberry Pi. We delete last nights National News, to watch tonight's and don't delete tonight's until tomorrow night. This has worked every time so far. If you keep everything, and want to refresh the list often, then you may need to record something that you will never watch so you can delete a show it to drive list refresh.
2) Disable and enable the NextPVR addon in Kodi. The act of disabling it unloads the addon and enabling it reloads it, which will drive a refresh of the recorded shows from the server. Note that this will also drive a reload of the TV Guide info (if it is not cached on Kodi) and an update of the media information for shows that are new, but you probably want to do this anyway. If the Raspberry Pi has not been used for sometime updating the media info could take time as there will be lots of new shows.
3) Reboot the Raspberry Pi. From the viewpoint of the NextPVR addon it does the same thing as an disable / enable but you add in the reboot time.

Because I had read the forum postings from several years ago back in late September, I assumed that somehow I had gotten a back level release of the NextPVR addon when I upgraded to 17.6. In this thread I asked how I could check to see if the addon was the current stable level: https://forums.nextpvr.com/showthread.ph...odi-Add-on. Sub assured me that I had the 17.6 addon, so the only reasonable explanation now appears to be that I am hitting the same problem Bruce reported.

Papajay