Posts by ciclista71

I have taken some pcaps from my router, to see what's going on.

What I see is that, all of a sudden, while the WiFi is still active, 802.11 packets between the router and the rpi4 are sent and received and the IP address is maintained (so, apparently, it's all good), nobody can get an ARP answer from the rpi4. The router tries, the other raspberry tries, with no success.

It all starts at 22:38, when the capture begins and I try to connect to my NFS server. At 22:41 the vpn service detects something is wrong and connmand tears down the routes, but the WiFi gets disconnected only at 22:47. As soon as it reconnects, ARP tables are correctly populated and everything is back to normal.

Here you see the router sending an ARP request to the RPI4, getting no answer. Also the other Raspberry tries, with no luck

Wifi gets disconnected at 22:47 and the rpi4 reconnects, ARP is populated

At this point in time, the NAS (.120) is also discovered and I can start watching the TV program (10 minutes after my initial atrempt)

So it looks like the WiFi is up but ARP requests fail, how can it be? And how could I write a script that manually tears WiFi down and up if I see something like that?

I tried by checking the ARP table of the RPI4: if I don't see the NAS IP, I will reconnect, but this is not working because I believe ARP ageing is about 5 minutes, so I arrive quite late

I tried with ping, but it didn't work either - well, I tried only once and in that case I was getting a continuous rebuffering, with PVR disconnecting and reconnecting. From the logs, ping was always successful, so probably this is not working either.

I cannot think of other ideas. So far I am trying storing my TV programs on a USB stick connected to the rpi4, I did some tests and apparently it's working, but still, I would like to find a solution.

Yes, only when running opevvpn, but if I have installed it it's because I want to use it....

Basically what I see is that kodi.sh returns the pid of the openvpn command, but the script as such does not do any ps or grep, so maybe it's the kodi.bin reporting this value which is stored somewhere, maybe in some variables? I will try to check the openvpn python scripts, I have lowered the openvpn verbosity to 1 but nothing changes

It's also strange nobody else is seeing this problem...

Hi,

I have just installed the VPN Manager in LibreELEC 10.0.0.2 and I am using NordVPN. It looks like it is working fine, however the journalctl reports thousands of logs coming from kodi.sh that reports a number:

Code

Apr 27 13:04:55 LibreELEC kodi.sh[18555]: 775
Apr 27 13:05:00 LibreELEC kodi.sh[18560]: 775
Apr 27 13:05:05 LibreELEC kodi.sh[18565]: 775
Apr 27 13:05:09 LibreELEC kodi.sh[18662]: 775
Apr 27 13:05:14 LibreELEC kodi.sh[18667]: 775
Apr 27 13:05:18 LibreELEC kodi.sh[18672]: 775
Apr 27 13:05:23 LibreELEC kodi.sh[18677]: 775
Apr 27 13:05:28 LibreELEC kodi.sh[18682]: 775
Apr 27 13:05:32 LibreELEC kodi.sh[18683]: 775
Apr 27 13:05:37 LibreELEC kodi.sh[18688]: 775
Apr 27 13:05:42 LibreELEC kodi.sh[18785]: 775
Apr 27 13:05:46 LibreELEC kodi.sh[18790]: 775
Apr 27 13:05:51 LibreELEC kodi.sh[18795]: 775
Apr 27 13:05:56 LibreELEC kodi.sh[18800]: 775
Apr 27 13:06:00 LibreELEC kodi.sh[18805]: 775
Apr 27 13:06:05 LibreELEC kodi.sh[18812]: 775
Apr 27 13:06:09 LibreELEC kodi.sh[18856]: 775
Apr 27 13:06:14 LibreELEC kodi.sh[18914]: 775
Apr 27 13:06:19 LibreELEC kodi.sh[18915]: 775
Apr 27 13:06:23 LibreELEC kodi.sh[18920]: 775
Apr 27 13:06:28 LibreELEC kodi.sh[18925]: 775
Apr 27 13:06:33 LibreELEC kodi.sh[18930]: 775
Apr 27 13:06:37 LibreELEC kodi.sh[18935]: 775
Apr 27 13:06:42 LibreELEC kodi.sh[19032]: 775
Apr 27 13:06:44 LibreELEC connmand[465]: ntp: adjust (slew): -0.001108 sec
Apr 27 13:06:47 LibreELEC kodi.sh[19037]: 775
Apr 27 13:06:51 LibreELEC kodi.sh[19042]: 775
Apr 27 13:06:56 LibreELEC kodi.sh[19047]: 775

Basically, I cannot use the logs anymore as the logfile stores only a certain amount of rows.

if I do a ps, I see that 775 is the vpn process

Code

550 root      0:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups  
771 root      0:50 /storage/.kodi/addons/service.tvheadend43/bin/tvheadend -B -C -u root -g video -c /storage/.kodi/userdata/addon_data/service.tvheadend43  
775 root      0:00 /usr/sbin/openvpn --daemon --config /storage/.config/openvpn.config  
782 root      0:00 [kworker/u9:1-hc]

I didn't activate any logs (AFAIK), is there a way to stop this log? It appeared right after I installed the vpn service.

I would just need to suppress this message that kills all the rest of the relevant logs

Any idea on where I should look?

Thanks!

Hi,

I am running the latest LE (10.0.0.2) with the latest FW for my Rpi4 (with the uHAT and TVH installed)

The problem I am facing is that when I start watching a recorded video or when I am watching it (typically, max 10 minutes after I start), everything stops.

In the logs I can see many messages stating that NFS server is down (I record videos to my NAS):

Apr 13 22:29:42 LibreELEC kernel: nfs: server 192.168.1.120 not responding, still trying
Apr 13 22:29:42 LibreELEC kernel: nfs: server 192.168.1.120 not responding, still trying
Apr 13 22:29:42 LibreELEC kernel: nfs: server 192.168.1.120 not responding, still trying

I don't have any WiFi issues, at least, by monitoring the WiFi I see connection is seen as UP, with a good DBm. What I saw some days ago is that the MAC address of the NAS was seen as "incomplete" in the ARP table, so I created a script that would bring wifi down and up when this would occur. It works but I still get disruption of the service.

Yesterday, though, the MAC was there in the table and WiFi was up, as you can see here below (the fields show Time, DBm, connection status, MAC of the NAS, MAC of another Raspberry I have: I send statistics to a Grafana server located there)

Wed Apr 13 22:27:07 CEST 2022,-50,yes,24:5e:be:3a:9e:dd,b8:27:eb:ca:5d:2d
Wed Apr 13 22:27:22 CEST 2022,-49,yes,24:5e:be:3a:9e:dd,b8:27:eb:ca:5d:2d
Wed Apr 13 22:27:37 CEST 2022,-49,yes,24:5e:be:3a:9e:dd,b8:27:eb:ca:5d:2d
Wed Apr 13 22:27:52 CEST 2022,-50,yes,24:5e:be:3a:9e:dd,b8:27:eb:ca:5d:2d
Wed Apr 13 22:28:07 CEST 2022,-50,yes,24:5e:be:3a:9e:dd,b8:27:eb:ca:5d:2d
Wed Apr 13 22:28:22 CEST 2022,-50,yes,24:5e:be:3a:9e:dd,b8:27:eb:ca:5d:2d
Wed Apr 13 22:28:37 CEST 2022,-50,yes,24:5e:be:3a:9e:dd,b8:27:eb:ca:5d:2d
Wed Apr 13 22:28:52 CEST 2022,-49,yes,24:5e:be:3a:9e:dd,b8:27:eb:ca:5d:2d
Wed Apr 13 22:29:07 CEST 2022,-49,yes,24:5e:be:3a:9e:dd,b8:27:eb:ca:5d:2d
Wed Apr 13 22:29:22 CEST 2022,-51,yes,24:5e:be:3a:9e:dd,b8:27:eb:ca:5d:2d
Wed Apr 13 22:29:37 CEST 2022,-49,yes,24:5e:be:3a:9e:dd,b8:27:eb:ca:5d:2d
Wed Apr 13 22:29:52 CEST 2022,-48,yes,24:5e:be:3a:9e:dd,b8:27:eb:ca:5d:2d
Wed Apr 13 22:30:07 CEST 2022,-48,yes,24:5e:be:3a:9e:dd,b8:27:eb:ca:5d:2d
Wed Apr 13 22:30:22 CEST 2022,-49,yes,24:5e:be:3a:9e:dd,b8:27:eb:ca:5d:2d
Wed Apr 13 22:30:38 CEST 2022,-48,yes,24:5e:be:3a:9e:dd,b8:27:eb:ca:5d:2d
Wed Apr 13 22:30:53 CEST 2022,-48,yes,24:5e:be:3a:9e:dd,b8:27:eb:ca:5d:2d
Wed Apr 13 22:31:08 CEST 2022,-48,yes,24:5e:be:3a:9e:dd,b8:27:eb:ca:5d:2d
Wed Apr 13 22:31:23 CEST 2022,-47,yes,24:5e:be:3a:9e:dd,b8:27:eb:ca:5d:2d
Wed Apr 13 22:31:38 CEST 2022,-47,yes,24:5e:be:3a:9e:dd,b8:27:eb:ca:5d:2d
Wed Apr 13 22:31:53 CEST 2022,-50,yes,24:5e:be:3a:9e:dd,b8:27:eb:ca:5d:2d
Wed Apr 13 22:32:08 CEST 2022,-49,yes,24:5e:be:3a:9e:dd,b8:27:eb:ca:5d:2d
Wed Apr 13 22:32:23 CEST 2022,-53,yes,24:5e:be:3a:9e:dd,b8:27:eb:ca:5d:2d
Wed Apr 13 22:32:38 CEST 2022,-51,yes,24:5e:be:3a:9e:dd,b8:27:eb:ca:5d:2d
Wed Apr 13 22:32:53 CEST 2022,-51,yes,24:5e:be:3a:9e:dd,b8:27:eb:ca:5d:2d
Wed Apr 13 22:33:08 CEST 2022,-50,yes,24:5e:be:3a:9e:dd,b8:27:eb:ca:5d:2d

The situation recovered only at 4M, when the MAC went down and I automatically reconnected to the network (see the reason=3)

Thu Apr 14 04:45:32 CEST 2022,-47,yes,24:5e:be:3a:9e:dd,b8:27:eb:ca:5d:2d
Thu Apr 14 04:45:47 CEST 2022,-47,yes,24:5e:be:3a:9e:dd,b8:27:eb:ca:5d:2d
Thu Apr 14 04:46:03 CEST 2022,,,,
Thu Apr 14 04:46:18 CEST 2022,-47,yes,24:5e:be:3a:9e:dd,b8:27:eb:ca:5d:2d
Thu Apr 14 04:46:33 CEST 2022,-47,yes,24:5e:be:3a:9e:dd,b8:27:eb:ca:5d:2d

Apr 14 04:46:02 LibreELEC wpa_supplicant[536]: wlan0: CTRL-EVENT-DISCONNECTED bssid=dc:39:6f:f2:32:9d reason=3 locally_generated=1
Apr 14 04:46:09 LibreELEC kernel: nfs: server 192.168.1.120 OK
Apr 14 04:46:11 LibreELEC tvheadend[31042]: http: Starting HTTP server 0.0.0.0:9981
Apr 14 04:46:11 LibreELEC tvheadend[31042]: htsp: Starting HTSP server 0.0.0.0:9982

Of course, I couldn't watch anything for the entire night, when this happens, the entire Kodi gets stuck basically: if you go to System Info and go to the Network part, the GUI freezes and CEC stops responding as well.

This also interrupted the recording of the program I wanted to watch, so I lost it. It also stopped sending data to the Grafana Server, which has a different IP Address and does not use NFS (of course, it's an HTTP server)

Note that when TVH records the video (towards the very same NAS), I never lose a bit, and it's a 220 minutes recording. But very often (or maybe always), when I try to play it, it all gets wrong and stuck. If my script works, then I have problems for 10 minutes, but yesterday it was a no-go

At a certain point in time, when the GUI was stuck, I also got this message in the logs, but I didn't see any direct consequences - maybe this is not relevant and just a consequence of all the rest

Apr 13 23:54:18 LibreELEC kernel: tvh:upnp invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0

It's not a temperature problem because I have a fan shim controlled by a Kodi add-on (which worked even when the GUI was frozen):

2022-04-13 22:52:40.726 T:959      INFO <general>: 66.2Enabling fan! temp:66.2
2022-04-13 22:54:42.977 T:959      INFO <general>: 51.6 Disabling fan! temp:51.6
2022-04-13 22:59:23.112 T:959      INFO <general>: 66.2Enabling fan! temp:66.2
2022-04-13 23:01:15.162 T:959      INFO <general>: 51.6 Disabling fan! temp:51.6
2022-04-13 23:06:25.855 T:959      INFO <general>: 66.2Enabling fan! temp:66.2
2022-04-13 23:08:12.813 T:959      INFO <general>: 51.1 Disabling fan! temp:51.1
2022-04-13 23:13:03.121 T:959      INFO <general>: 66.2Enabling fan! temp:66.2
2022-04-13 23:15:10.446 T:959      INFO <general>: 51.1 Disabling fan! temp:51.1

Is there a way to solve the NFS issue? Did anyone of you experience this problem?

Note that the server is not down because the other Rpi is connected to it and I don't see any issues there: I send influxdb data every 30 seconds and I didn't lose any single bucket yesterday. I also use that NAS with my other Kodi on a FireTV and I have never ever experienced any issues (it uses WiFi connectivity as well). And on top, recording from LE (TVH) to the NAS always works.

Luca

Let's close this topic, WiFi is not lost anymore. Now I have different issues.

The solution was basically to upgrade the firmware of the raspberry and probably also LE

Time has passed and in the meantime I have upgraded to LE10, latest version (and I have to say I am extremely happy about the de-interlacing feature, wow!).

WiFi drops are very rare and they don't affect performance or network connectivity, as they last between 4 to 6 seconds only and the connection doesn't drop. The latest version and firmware were key, I believe.

But I have another big problem, that was present even before, I think: at least once a day I get the following error:

LibreELEC kernel: nfs: server 192.168.1.120 not responding, still trying

This occurs about 4 minutes after the connection with my NAS is lost and this status continues for about 10 minutes, when the router disconnects LibreELEC from the WiFi, reconnection takes place and the NFS FS comes up again

Apr 03 21:13:55 Last data sent to InfluxDB (every 30s via a POST to a server located in a Raspberry at .132)


Apr 03 21:17:06 LibreELEC kernel: nfs: server 192.168.1.120 not responding, still trying
Apr 03 21:23:48 LibreELEC wpa_supplicant[509]: wlan0: CTRL-EVENT-DISCONNECTED bssid=dc:39:6f:xx:xx:xx reason=2
Apr 03 21:23:53 LibreELEC wpa_supplicant[509]: wlan0: CTRL-EVENT-CONNECTED - Connection to dc:39:6f:xx:xx:xx completed [id=0 id_str=]
Apr 03 21:24:03 LibreELEC kernel: nfs: server 192.168.1.120 OK


Apr 03 21:24:07 Data recovered from InfluxDB

The NAS is working properly and also the network connection, because I have other two RPi sending data to the server and at that very same time their connection was perfectly working. So it's not a server error. And, as you see, we would be talking about two servers going down: the NAS (at .120) and the Grafana server (at .133). The grafana server is not mounted, I just send a POST to it. The NFS instead is mounted, as per the documentation.

I created some monitoring scripts and found out a strange behaviour:

WiFi is seen as UP and connection with the Router is established; however, at a certain point, the ARP table can't find the MAC for the NAS (and also for the other Raspberry). When the WiFi gets disconnected and reconnected, everything comes back:

Sun Apr 3 21:12:24 CEST 2022|signal: -55 dBm|associated: yes|tx failed: 73|connected time: 65301 seconds|(192.168.1.120) at <MAC> [ether] on wlan0|(192.168.1.133) at <MAC_2> [ether] on wlan0
Sun Apr 3 21:12:54 CEST 2022|signal: -58 dBm|associated: yes|tx failed: 73|connected time: 65331 seconds|(192.168.1.120) at <MAC> [ether] on wlan0|(192.168.1.133) at <MAC_2> [ether] on wlan0
Sun Apr 3 21:13:24 CEST 2022|signal: -61 dBm|associated: yes|tx failed: 73|connected time: 65361 seconds|(192.168.1.120) at <MAC> [ether] on wlan0|(192.168.1.133) at <MAC_2> [ether] on wlan0
Sun Apr 3 21:13:55 CEST 2022|signal: -62 dBm|associated: yes|tx failed: 75|connected time: 65392 seconds|(192.168.1.120) at <MAC> [ether] on wlan0|(192.168.1.133) at <MAC_2> [ether] on wlan0

Until here, good; next line is when NFS is lost, TX failures increase. Still WiFi is associated and connected

Sun Apr 3 21:14:43 CEST 2022|signal: -58 dBm|associated: yes|tx failed: 82|connected time: 65422 seconds|(192.168.1.120) at <incomplete> on wlan0|(192.168.1.133) at <incomplete> on wlan0
Sun Apr 3 21:15:17 CEST 2022|signal: -56 dBm|associated: yes|tx failed: 82|connected time: 65470 seconds|(192.168.1.120) at <incomplete> on wlan0|(192.168.1.133) at <incomplete> on wlan0
Sun Apr 3 21:15:50 CEST 2022|signal: -60 dBm|associated: yes|tx failed: 82|connected time: 65504 seconds|(192.168.1.120) at <incomplete> on wlan0|(192.168.1.133) at <incomplete> on wlan0
Sun Apr 3 21:16:23 CEST 2022|signal: -56 dBm|associated: yes|tx failed: 82|connected time: 65537 seconds|(192.168.1.120) at <incomplete> on wlan0|(192.168.1.133) at <incomplete> on wlan0
...
When the WiFi gets disconnected and reconnected, TX Failures of course go to 0, connected time is reset and the MAC addresses of the NAS and Rpi are found again
...
Sun Apr 3 21:24:08 CEST 2022|signal: -56 dBm|associated: yes|tx failed: 0|connected time: 14 seconds|(192.168.1.120) at <MAC> [ether] on wlan0|(192.168.1.133) at <MAC_2> [ether] on wlan0
Sun Apr 3 21:24:38 CEST 2022|signal: -58 dBm|associated: yes|tx failed: 0|connected time: 44 seconds|(192.168.1.120) at <MAC> [ether] on wlan0|(192.168.1.133) at <MAC_2> [ether] on wlan0
Sun Apr 3 21:25:12 CEST 2022|signal: -59 dBm|associated: yes|tx failed: 0|connected time: 77 seconds|(192.168.1.120) at <MAC> [ether] on wlan0|(192.168.1.133) at <MAC_2> [ether] on wlan0
Sun Apr 3 21:25:42 CEST 2022|signal: -54 dBm|associated: yes|tx failed: 0|connected time: 107 seconds|(192.168.1.120) at <MAC> [ether] on wlan0|(192.168.1.133) at <MAC_2> [ether] on wlan0

Now,

I wonder if I can decrease this long timeout between NFS down (4 minutes after the MAC Address is lost) and WiFi Reconnection (which takes places about 10 minutes after the down - wifi reconnection seems to solve the problem).

During this time, if I am watching a recorded program, TVH client and server will fail and I will have to wait until it recovers.

10 minutes is a very long time!

Thanks for helping!

I have just seen an interesting thing: my LibreELEC got disconnected from the network, BUT the events are strange:

I see the first errors in the logs at 17:39:07, with NFS that cannot be reached - there is nothing before this

Apr 01 17:39:07 LibreELEC kernel: nfs: server 192.168.1.120 not responding, still trying

but I stop reporting data about my network at 17:35

During the hole (I send the data to an external server, so you don't see any data when the WiFi is down, but I also stored them in the LibreELEC) I don't see any errors in the interface (which is strange): err_in and err_out always report 0.

WiFi gets disconnected at 17:43:26 on the LibreELEC and at the same time I see a similar log in my router (it was the router to de-register the device)

WiFi is reestablished at 17:43:32, just 6 seconds later.

So it looks like there is a problem with the WiFi which is not detected by anyone until very late in some cases. This causes network drops and as soon as the WiFi is removed and re-added, it all works fine.

Maybe I could force a disconnection if I see problems? But how?

I did many changes, to try to improve the situation:

- I saw that the TVH Server had the pass stream set as default; I understood it should be set as htsp, so I changed that

- I disabled samba and disabled avahi

- I have removed many EPG updates not related to my country or providers (I just left OTA EPG)

I recorded my TV program and this part has always worked well. The duration of the recording is 220 minutes, so if I had had network issues I would have seen them. Instead, it all went well: no network errors, good upload bitrate, no CPU spikes, used MEM is good.

I have some "dropped in" errors, don't know what it is. This happens continuously, not only when I am recording.

Then, however, as soon as I start watching it, or maybe some time after (or when I go back and forth quickly with FFWD or FRWD, kodi hangs: NFS stops working, TVH server crashes, connmand removes IP routes and IP addresses, WiFi goes down, and for about 10 minutes everything gets stuck. If I go to the system menu and try to go down from Network to Storage, Kodi hangs and the remote also stops working. I will try to monitor that part as well, as soon as it happens (in a couple of days, I think, so as soon as I have time to watch the recorded program)

This only happens when I play a video, because every time I SSH, nothing happens: recording lasts for 220 minutes without issues. I changed many time the configuration of the TVH server with my browser and it all worked fine.

I really don't know where to look at, since kodi fails right when I need it.

WiFi is stable, I got just one disconnection (lasting 6 seconds) once in the last 24 hours

Mar 31 04:53:11 LibreELEC wpa_supplicant[497]: wlan0: CTRL-EVENT-DISCONNECTED bssid=dc:39:6f: reason=2
Mar 31 04:53:17 LibreELEC wpa_supplicant[497]: wlan0: CTRL-EVENT-CONNECTED - Connection to dc:39:6f: completed [id=0 id_str=]

Note that during that time, TVH didn't notice any issues, no event is reported at 04:35 (I have activated debug=all in TVH server)

2022-03-31 04:43:39.172 [   INFO]:epgdb: stored (size 490075)
2022-03-31 04:45:00.004 [  DEBUG]:epg: now/next 128803/122350 set on Rai Storia
2022-03-31 04:45:00.004 [  DEBUG]:epg: inform HTSP of now event change on Rai Storia
2022-03-31 04:45:00.004 [  DEBUG]:epg: arm channel timer @ 2022-03-31;05:40:00(+0200) for Rai Storia
2022-03-31 05:00:00.000 [  DEBUG]:epg: expire event 130648 (Tenn's: ATP 1000 Miami (diretta)) from Sky Sport Uno HD
2022-03-31 05:00:00.000 [  DEBUG]:epg: now/next 0/0 set on Sky Sport Uno HD
2022-03-31 05:00:00.000 [  DEBUG]:epg: inform HTSP of now event change on Sky Sport Uno HD

I will keep you posted.

I am using the pass, I tried with mkv as well but I didn't see great improvements

Hi,

I have an Rpi4 with the latest LE 10.0.1 and tvheadend server 4.3.1979

I recorded a video, yesterday evening, and it all went well till I decided to start watching it (while it was still being recorded).

This is how it went:

Recording started at 21:30 and should have finished at 00:30

Mar 09 21:09:30 LibreELEC tvheadend[9167]: dvr: "CLV-2022-03-09-21:10" on "Rai 3 HD" recorder starting

At 22:10 or so I ssh'ed to LE to check some files and folders, and a few minutes later I also connected to the web interface of TVH because I was mistakenly recording twice the same video, so I stopped the automatic EPG recording and let the manual recording proceed. This all happened over WiFi, no issues

At 22:44 I decided to play the video, so I sat in front on my TV, went to the LiveTV section of my LE, went to recordings, and played the file.

2022-03-09 22:44:14.748 T:817 INFO <general>: VideoPlayer::OpenFile: pvr://recordings/tv/active/CLV-2022-03-09-21_10/CLV-2022-03-09-21%3a10 (1969), TV%20(Rai%203%20HD), 20220309_201000, 1367281094.pvr
2022-03-09 22:44:15.037 T:17827 INFO <general>: CDVDVideoCodecDRMPRIME::Open - using decoder V4L2 mem2mem H.264 decoder wrapper
2022-03-09 22:44:15.078 T:17828 INFO <general>: Creating audio stream (codec id: 86019, channels: 2, sample rate: 48000, no pass-through)
2022-03-09 22:44:21.079 T:817 INFO <general>: Display resolution ADJUST : 1920x1080 @ 50.000000 Hz (21) (w3ight: -1458166273442578432.000)

Note that at that time I don't see any clear message from TVH, just the below (I was expecting to see the hello message from the TVH server):

Mar 09 22:43:52 LibreELEC tvheadend[9167]: http: 127.0.0.1: HTTP/1.1 HEAD (2) /imagecache/524 -- 404
Mar 09 22:43:52 LibreELEC tvheadend[9167]: http: 127.0.0.1: HTTP/1.1 HEAD (2) /imagecache/525 -- 404
Mar 09 22:43:52 LibreELEC tvheadend[9167]: http: 127.0.0.1: HTTP/1.1 HEAD (2) /imagecache/529 -- 404
Mar 09 22:43:52 LibreELEC tvheadend[9167]: http: 127.0.0.1: HTTP/1.1 HEAD (2) /imagecache/528 -- 404
Mar 09 22:43:52 LibreELEC tvheadend[9167]: http: 127.0.0.1: HTTP/1.1 HEAD (2) /imagecache/344 -- 404
Mar 09 22:43:52 LibreELEC tvheadend[9167]: http: 127.0.0.1: HTTP/1.1 HEAD (2) /imagecache/527 -- 404
Mar 09 22:43:52 LibreELEC tvheadend[9167]: http: 127.0.0.1: HTTP/1.1 HEAD (2) /imagecache/74 -- 404
Mar 09 22:44:06 LibreELEC tvheadend[9167]: http: 127.0.0.1: HTTP/1.1 HEAD (2) /imagecache/462 -- 404
Mar 09 22:44:08 LibreELEC tvheadend[9167]: http: 127.0.0.1: HTTP/1.1 HEAD (2) /imagecache/462 -- 404

It all went well until 22:59, when all of a sudden the video froze and I lost all kind of connections (connection to TVH and connection to the WiFi)

About one minute before everything crashed, I do see a connection from the client to the server (I don't understand why, since I was watching the video since 22:43)

Mar 09 22:58:26 LibreELEC tvheadend[9167]: htsp: Got connection from 127.0.0.1
Mar 09 22:58:26 LibreELEC tvheadend[9167]: htsp: 127.0.0.1: Welcomed client software: Kodi Media Center (HTSPv34)
Mar 09 22:58:26 LibreELEC tvheadend[9167]: htsp: 127.0.0.1 [ Kodi Media Center ]: Identified as user 'tvheadend'
Mar 09 22:58:26 LibreELEC tvheadend[9167]: htsp: 127.0.0.1 [ tvheadend | Kodi Media Center ]: Privileges updated
Mar 09 22:59:40 LibreELEC tvheadend[9167]: mpegts: too much queued table input data (over 2MB) for Sony CXD2880 #0 : DVB-T #0, discarding new
Mar 09 22:59:50 LibreELEC tvheadend[9167]: mpegts: too much queued table input data (over 2MB) for Sony CXD2880 #0 : DVB-T #0, discarding new
Mar 09 23:00:00 LibreELEC tvheadend[9167]: mpegts: too much queued table input data (over 2MB) for Sony CXD2880 #0 : DVB-T #0, discarding new
Mar 09 23:00:10 LibreELEC tvheadend[9167]: htsp: 127.0.0.1 [ tvheadend | Kodi Media Center ]: Write error -- Broken pipe
Mar 09 23:00:10 LibreELEC tvheadend[9167]: htsp: 127.0.0.1 [ tvheadend | Kodi Media Center ]: Write error -- Broken pipe
Mar 09 23:00:10 LibreELEC tvheadend[9167]: htsp: 127.0.0.1 [ tvheadend | Kodi Media Center ]: Disconnected
Mar 09 23:00:10 LibreELEC tvheadend[9167]: subscription: 01E1: "HTSP" unsubscribing, hostname="127.0.0.1", username="tvheadend", client="Kodi Media Center"

So it looks like there was a connection and then kind of another one that made the entire system hang.

WiFi went down for a couple of seconds

Mar 09 22:59:54 LibreELEC wpa_supplicant[510]: wlan0: CTRL-EVENT-DISCONNECTED bssid=dc:39:6f:f2:32:9d reason=2
Mar 09 22:59:59 LibreELEC wpa_supplicant[510]: wlan0: CTRL-EVENT-CONNECTED - Connection to dc:39:6f:f2:32:9d completed [id=0 id_str=]

but nevertheless, I couldn't SSH LE anymore, and also NFS connection went down (I save the videos to my NAS) - note that I could access my NAS from all other systems, meaning my WiFi was perfectly working and I saved other things from other systems to that very same NAS exactly during that time

Mar 09 23:13:26 LibreELEC kernel: nfs: server 192.168.1.120 not responding, still trying
Mar 09 23:15:36 LibreELEC kernel: nfs: server 192.168.1.120 not responding, still trying

Mar 09 23:17:46 LibreELEC kernel: nfs: server 192.168.1.120 not responding, still trying
Mar 09 23:19:56 LibreELEC kernel: nfs: server 192.168.1.120 not responding, still trying
Mar 09 23:22:05 LibreELEC kernel: nfs: server 192.168.1.120 not responding, still trying
Mar 09 23:24:15 LibreELEC kernel: nfs: server 192.168.1.120 not responding, still trying
Mar 09 23:26:25 LibreELEC kernel: nfs: server 192.168.1.120 not responding, still trying
Mar 09 23:28:34 LibreELEC kernel: nfs: server 192.168.1.120 not responding, still trying
Mar 09 23:30:44 LibreELEC kernel: nfs: server 192.168.1.120 not responding, still trying
Mar 09 23:32:54 LibreELEC kernel: nfs: server 192.168.1.120 not responding, still trying
Mar 09 23:35:04 LibreELEC kernel: nfs: server 192.168.1.120 not responding, still trying
Mar 09 23:37:13 LibreELEC kernel: nfs: server 192.168.1.120 not responding, still trying
Mar 09 23:39:23 LibreELEC kernel: nfs: server 192.168.1.120 not responding, still trying
Mar 10 11:29:20 LibreELEC kernel: nfs: server 192.168.1.120 OK

At 00.43, system crashed. I had gone to sleep so I hadn't played with LE or with TVH since 23:15, more or less.

Mar 10 00:42:38 LibreELEC tvheadend[9167]: mpegts: too much queued table input data (over 2MB) for Sony CXD2880 #0 : DVB-T #0, discarding new
Mar 10 00:42:48 LibreELEC tvheadend[9167]: mpegts: too much queued table input data (over 2MB) for Sony CXD2880 #0 : DVB-T #0, discarding new
Mar 10 00:43:45 LibreELEC kernel: kworker/u8:2 invoked oom-killer: gfp_mask=0x2dc2(GFP_KERNEL|__GFP_HIGHMEM|__GFP_NOWARN|__GFP_ZERO), order=0, oom_score_adj=0
Mar 10 00:43:45 LibreELEC kernel: CPU: 0 PID: 23182 Comm: kworker/u8:2 Tainted: G         C        5.10.76 #1
Mar 10 00:43:45 LibreELEC kernel: Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)
Mar 10 00:43:45 LibreELEC kernel: Workqueue: brcmf_wq/mmc1:0001:1 brcmf_sdio_dataworker [brcmfmac]
Mar 10 00:43:45 LibreELEC kernel: Call trace:
Mar 10 00:43:45 LibreELEC kernel:  dump_backtrace+0x0/0x1e4
Mar 10 00:43:45 LibreELEC kernel:  show_stack+0x24/0x30
Mar 10 00:43:45 LibreELEC kernel:  dump_stack+0xf8/0x168
Mar 10 00:43:45 LibreELEC kernel:  dump_header+0x50/0x1e4
Mar 10 00:43:45 LibreELEC kernel:  oom_kill_process+0x228/0x230
Mar 10 00:43:45 LibreELEC kernel:  out_of_memory+0x1ec/0x34c
Mar 10 00:43:45 LibreELEC kernel:  __alloc_pages_slowpath.constprop.0+0x824/0xb20
Mar 10 00:43:45 LibreELEC kernel:  __alloc_pages_nodemask+0x28c/0x2e0
Mar 10 00:43:45 LibreELEC kernel:  __vmalloc_area_node+0x10c/0x270
Mar 10 00:43:45 LibreELEC kernel:  vzalloc+0xb8/0x130
Mar 10 00:43:45 LibreELEC kernel:  brcmf_sdio_dataworker+0x2158/0x25f0 [brcmfmac]
Mar 10 00:43:45 LibreELEC kernel:  process_one_work+0x1e8/0x45c
Mar 10 00:43:45 LibreELEC kernel:  worker_thread+0x78/0x4e4
Mar 10 00:43:45 LibreELEC kernel:  kthread+0x134/0x140
Mar 10 00:43:45 LibreELEC kernel:  ret_from_fork+0x10/0x38
Mar 10 00:43:45 LibreELEC kernel: Mem-Info:
Mar 10 00:43:45 LibreELEC kernel: active_anon:1648 inactive_anon:889462 isolated_anon:0
active_file:15 inactive_file:4728 isolated_file:96
unevictable:7338 dirty:0 writeback:818
slab_reclaimable:8185 slab_unreclaimable:10741
mapped:6306 shmem:10545 pagetables:2216 bounce:0
free:6886 free_pcp:162 free_cma:160
Mar 10 00:43:45 LibreELEC kernel: Node 0 active_anon:6592kB inactive_anon:3557848kB active_file:60kB inactive_file:18912kB unevictable:29352kB isolated(anon):0kB isolated(file):384kB mapped:25224kB dirty:0kB writeback:3272kB shmem:42180kB writeback_tmp:0kB kernel_stack:3440kB all_unreclaimable? yes
Mar 10 00:43:45 LibreELEC kernel: DMA free:15304kB min:3732kB low:4664kB high:5596kB reserved_highatomic:0KB active_anon:0kB inactive_anon:721640kB active_file:0kB inactive_file:7476kB unevictable:172kB writepending:0kB present:970752kB managed:885712kB mlocked:0kB pagetables:1384kB bounce:0kB free_pcp:120kB local_pcp:56kB free_cma:640kB
Mar 10 00:43:45 LibreELEC kernel: lowmem_reserve[]: 0 2929 2929 2929
Mar 10 00:43:45 LibreELEC kernel: DMA32 free:12240kB min:12648kB low:15808kB high:18968kB reserved_highatomic:0KB active_anon:6592kB inactive_anon:2836208kB active_file:60kB inactive_file:11308kB unevictable:29180kB writepending:2760kB present:3080192kB managed:2999448kB mlocked:0kB pagetables:7480kB bounce:0kB free_pcp:528kB local_pcp:252kB free_cma:0kB

System recovered by himself at 11:29 on the next day. My recording stopped at 23.09 (not at 00:30)

2022-03-10 11:29:31.373 T:22867    INFO <general>: PVR Manager: Starting
2022-03-10 11:29:31.437 T:990      INFO <general>: AddOnLog: pvr.hts: Async updates initialised
2022-03-10 11:29:31.712 T:22872    INFO <general>: PVR Manager: Started

Mar 10 00:43:00 LibreELEC tvheadend[9167]: mpegts: too much queued table input data (over 2MB) for Sony CXD2880 #0 : DVB-T #0, discarding new
Mar 10 11:29:23 LibreELEC systemd[1]: service.tvheadend43.service: Main process exited, code=killed, status=9/KILL
Mar 10 11:29:23 LibreELEC systemd[1]: service.tvheadend43.service: Failed with result 'signal'.
Mar 10 11:29:25 LibreELEC systemd[1]: service.tvheadend43.service: Scheduled restart job, restart counter is at 2.
Mar 10 11:29:25 LibreELEC tvheadend[22817]: main: Log started
Mar 10 11:29:25 LibreELEC tvheadend[22817]: http: Starting HTTP server 0.0.0.0:9981
Mar 10 11:29:25 LibreELEC tvheadend[22817]: htsp: Starting HTSP server 0.0.0.0:9982

It looks clear that as soon as I try to use the TVH Player, something breaks the system and everything collapses, but is there any other alternatives to play a recording?

I tried with another Kodi I have on my FireTV but I got various issues (can't FFW, for instance), so actually I don't know how to proceed.

I could just use the Rpi4 for the tvheadend server, but then I need some good players that can handle interlaced videos and .ts files that grow over time

Thanks for helping!

Luca

The FritzBox tells me about connections and disconnections, but actually I see it also for other devices (for which I do not get any issues whatsoever)

I am using Firmware 07.28, installed on the 30th of August. Sometimes the device gets de-registered, sometimes is de-registers itself.

02.09.21 15:41:35 Wireless device deregistered itself (5 GHz), LibreELEC, IP 192.168.1.143
02.09.21 12:36:33 New wireless device registered itself (5 GHz), 433 Mbit/s, LibreELEC, IP 192.168.1.143
02.09.21 12:36:17 Wireless device was deregistered (5 GHz), LibreELEC, IP 192.168.1.143
02.09.21 12:35:45 New wireless device registered itself (5 GHz), 433 Mbit/s, LibreELEC, IP 192.168.1.143
02.09.21 12:35:31 Wireless device was deregistered (5 GHz), LibreELEC, IP 192.168.1.143
02.09.21 08:51:21 New wireless device registered itself (5 GHz), 433 Mbit/s, LibreELEC, IP 192.168.1.143
02.09.21 08:51:03 Wireless device was deregistered (5 GHz), LibreELEC, IP 192.168.1.143
02.09.21 08:50:49 New wireless device registered itself (5 GHz), 433 Mbit/s, LibreELEC, IP 192.168.1.143
02.09.21 08:50:49 New wireless device registered itself (2,4 GHz), 72 Mbit/s, LibreELEC, IP 192.168.1.143
02.09.21 08:50:49 Wireless device was deregistered (5 GHz), LibreELEC, IP 192.168.1.143
02.09.21 08:50:48 Reregistered wireless device (Band-Steering): Automatic change of Wi-Fi frequency band to improve data transmission, LibreELEC, IP 192.168.1.143
02.09.21 05:01:37 New wireless device registered itself (5 GHz), 433 Mbit/s, LibreELEC, IP 192.168.1.143
02.09.21 05:01:35 Reregistered wireless device (Band-Steering): Automatic change of Wi-Fi frequency band to improve data transmission, LibreELEC, IP 192.168.1.143,
02.09.21 05:00:15 New wireless device registered itself (2,4 GHz), 72 Mbit/s, LibreELEC, IP 192.168.1.143

I see similar messages also for my iPhone and my IP Cameras but I do not suffer network outages, amnd anyway there is nothing I can do about it.

The 5Ghz channel is set manually to 40 (because I need it for the FireTV to work properly with 5Ghz).

Switching to ethernet is too complicated because I am just opposite the router and I would need to lay a cable across the room, not easy and not nice.

However, I have done another attempt, which is bringing the wifi down and up programmatically on my FritzBox router. I have created a python script that does the job. WiFi is taken down for three seconds and then up again.

Now, when this happens, wpa_supplicant sees a connection drop with valid reason codes (2, 3 or 6), still I can see the teardown of the interfaces but the system is not affected. The connection doesn't drop, I keep watching what I was watching, I keep recording what I was recording.

I can bring down the wifi like that many times and still, the behaviour will be perfect.

The issue occur when the wpa_supplicant throws an error with reason=0 locally_generated=1. In that case, the system doesn't recover

reason=0 is not one of the valid wpa_supplicant codes, though....

OK,

During the last week I upgraded from LE10 to LE10RC1, but the behaviour is basically the same:

Whenever there is a short network loss, connmand removes the IP address and the routes (and the same is notified by avahi), and three things happen:

- TVH Server keeps recording the video, which is prolly locally stored and then sent to the NAS as soon as network recovers (I don't lose any frames when I watch it later)

- PVR Simple IPTV Client cannot reconnect because there is no interface to use (they have been removed) and will succeed quite late (I saw improvements in LE10RC1, but still it's 3 to 4 minutes)

- If I go to the Network Section of LE with the remote ands check the IP address, I will not see it (it's blank) and LE hangs (I need to unplug it and re-plug it)

So, for me the issue is the way connman or avahi work whenever a connection is lost. I would expect the IP to stay there, and instead the routes, and DNS, everything is teared down. Strangely enough, the TVH server keeps working (I think it's saving locally and then flushing to the NAS as soon as network is up again)

I tried to configure a static IP, but still, interfaces are removed.

The problem is that only that Rpi has connection problems. I lose SSH connectivity to it but I can perfectly browse the NAS from my Windows PC which is over the same WiFi.

I can't think of any other workaround.....

frakkin64, I don't think the BUS gets saturated because I have issues only when playing the videos, but not when recording them.

What I have noticed is instead something that may have nothing to do with WiFi, and I will explain why:

If I play a video while it's being recorded, after around 30 minutes I get a client disconnection and from that moment on, least for 10 minutes, I cannot resume the connection even if I disable and re-enable the PVR Player.

No matter what, the TV Program gets recorded without any issues and actually, I can watch it with VLC.

If instead I play a video after it's been recorded, everything goes fine.

I see this because every Wednesday I get the issue (and it's when I record the program) but on Thursday or in other days, it's all good.

For this reason I will do the following attempts:

- But back the latest LE + Kodi Release, record and play while recording to see if the new TVH client is better

- While recording, use a different player (I have a FireTV with an older Kodi instance) to see if this leads to the same issues

- While recording, play the video with a different player (Kodi, through the files section or VLC from my PC)

According to what I find, I will decide what to do.

I have read of other people having this issue of getting disconnected while playing a video being recorded and even if they used ethernet cable, still the problem wasn't solved. And actually, how can it be that the client cannot connect to the server if they are both on the same machine? It cannot be network dependent if the loopback is involved!

I'm going on holiday tomorrow, so I will resume my analysis in August when I am back.

That's a really tough issue... TV programs will switch to HD in September and I need to solve my problems by then, as my legacy PVR only supports SD and therefore I will have to rely only on my pi4.

Well,

it all happened again. Disconnections are way less frequent, but intrestingly, it looks like I lose connection when I am playing a video while it's been recorded. The server keeps recording and storing the video to the NAS but the client cannot connect to the server anymore.

During August I will play with different configurations

I'm back, after doing various attempts.

First of all, I backed up my LE9 SD card and I have to say that Win32 Disk Imager always gives me issues, so I used dd to copy the card to an image in my (old) mac. This takes around 3h.... Maybe there is a better way.

Anyhow, I first installed LE10 and used TVH 4.3.3 as a server. Installation was smooth and all the tweaks I did in config.txt to make my TV work under LE9 weren't needed (actually, I initially copied them from LE9 to LE10 and I couldn't see anything in my TV, so I removed them and it all worked). I also checked the brcm firmware and was up-to-date, I could also update the BootLoader (I don't exactly know what it is, but I did it).

WiFi looked very stable, I normally have wifi flapping apart from hard disconnection but I tested it for 4 hours and I never saw any disconnection.

The problem is that TVH couldn't find the TV channels I was looking for. There is a mux at 626Mhz, where TVH could see 3 services but these weren't mapped to any channels. Here below, what I should get from 626Mhz

As you see, TVH sees the mux, scan is OK, 4 services are found (why 4?), 0 are mapped to a channel

If I go to the services tab, though, I do not see anything under the 626Mhz

This means that I cannot record anything from Rai3 because I just cannot find it.

I played quite a lot of time with the configuration but I couldn't do anything to solve the issue.

I then uninstalled TVH 4.3.3 (also because the TV scans always stopped at 97%) and installed TVH 4.2.x. In this case, TV scan reached 100% but I couldn't find Rai3 either, so I gave up.

I saved the image and went back to LE9 (dd took around 5 hours!) and this morning I run it again. I had forgotten the TVH Server GUI password, but after some research I have discovered it is uuencoded in the passwd folder, so I could enter it again.

I did found Rai3 HD this time, I see the services and the channels, I see the EPG, I can watch the channel. Strange thing is that the mux scan shows "FAILURE"

Anyhow, I see the channels (all the three services which are Rai2 HD, Rai3 HD and RaiSport+) and I can watch them.

Of course I still had the network issue so this time I have given it a try and I have updated the brcm firmware

Kodi GUI says that the bootloader is still updated to 2021 (I think the first time I used LE9 it was showing a different date, maybe upgrading it from LE10 made this change persistent? Maybe it's not SD dependent?), so there's nothing else I can upgrade.

I will now leave the system on for a while to see if I lose connection. I have disabled the script that tried to reconnect automatically, so let's see.

I will also report the TVH issue in the TVH forum to see what people say.

I will keep you posted.

[EDIT]

So far, no wifi issues anymore. I will keep this configuration for a while, let's see.

Case closed, for the moment.

Thanks for helping!

I have read many posts talking about issues wirh pi4 and LE10, but if instead for you it's working, then why not giving it a try?

It's an attempt I can do.

I do not have a spare SD so I am backing it up (dd'ing) and once I am done, I will do a scratch install - anyway I don't think I am going to play with LE9 anymore....

Thanks for your hint, I will play with it and report my findings.

BTW, can I ise TVH 4.3.3 instead of 4.3.2 under LE10? I understood the "unstable" version of TVH is much more up-to-date but LE9 doesn't let me chose it.

Yesterday evening, at 21:10 CET, a Scheduled Recording started on my TvHeadEnd server and at 22:39 I decided to watch a Recorded Video (a different one, though this is not important). At 22:43 the Wi-Fi stopped working.

The sequence is the following:

2021-06-30 22:39:06.953 T:3011491152  NOTICE: VideoPlayer::OpenFile: pvr://recordings/tv/active/Rai 3 HD-2021-06-23-21_10/Rai%203%20HD-2021-06-23-21%3a10, TV%20(Rai%203%20HD), 20210623_191000, 1647485047.pvr
2021-06-30 22:39:17.347 T:3011491152  NOTICE: Whitelist search for: width: 1920, height: 1080, fps: 25.000, 3D: false
2021-06-30 22:39:17.349 T:3011491152  NOTICE: Display resolution ADJUST : 1920x1080 @ 50.000000 Hz (19) (w3ight: 0.000)

========== So far, the video is playing with the correct resolution ================

2021-06-30 22:41:38.589 T:2812248944   ERROR: AddOnLog: Tvheadend HTSP Client: pvr.hts - Command fileRead failed: No response received
2021-06-30 22:41:38.590 T:2812248944   ERROR: AddOnLog: Tvheadend HTSP Client: pvr.hts - vfs fileRead failed
2021-06-30 22:41:40.623 T:2545165168  NOTICE: CVideoPlayerAudio::Process - stream stalled

========= Here, the Player cannot find the network, probably, and stalls ======

2021-06-30 22:42:03.598 T:2881561456   ERROR: AddOnLog: Tvheadend HTSP Client: pvr.hts - Command hello failed: No response received
2021-06-30 22:42:03.598 T:2881561456   ERROR: AddOnLog: Tvheadend HTSP Client: pvr.hts - failed to send hello
2021-06-30 22:42:04.354 T:2536772464   ERROR: SetRecordingLastPlayedPosition: Add-on 'Tvheadend:127.0.0.1:9982' returned an error: server error

============ LE detects disconnected WiFi later on, almost one minute after TVH Client stops ======

Jun 30 22:42:25 LibreELEC wpa_supplicant[398]: wlan0: CTRL-EVENT-DISCONNECTED bssid=dc:39:6f:f2:32:9c reason=0 locally_generated=1
Jun 30 22:42:25 LibreELEC wpa_supplicant[398]: dbus: wpa_dbus_property_changed: no property SessionLength in object /fi/w1/wpa_supplicant1/Interfaces/0
Jun 30 22:42:25 LibreELEC wpa_supplicant[398]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
Jun 30 22:42:25 LibreELEC wpa_supplicant[398]: wlan0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=IT
Jun 30 22:42:25 LibreELEC wpa_supplicant[398]: wlan0: Trying to associate with SSID 'TISCALI'
Jun 30 22:42:28 LibreELEC wpa_supplicant[398]: wlan0: CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00 status_code=16
Jun 30 22:43:10 LibreELEC wpa_supplicant[398]: wlan0: Failed to initiate sched scan

====== Jun 30 22:43:33 Scrpit reconnects to the WiFi ======

Jun 30 22:43:35 LibreELEC wpa_supplicant[398]: wlan0: Failed to initiate sched scan
Jun 30 22:43:35 LibreELEC wpa_supplicant[398]: wlan0: Trying to associate with SSID 'TISCALI'
Jun 30 22:43:38 LibreELEC wpa_supplicant[398]: wlan0: Associated with dc:39:6f:f2:32:9c
Jun 30 22:43:38 LibreELEC wpa_supplicant[398]: wlan0: CTRL-EVENT-CONNECTED - Connection to dc:39:6f:f2:32:9c completed [id=0 id_str=]

============ I should get a valid connection, but TVH Client cannot speak with TVH Server =========
============ As you see, 10 minutes after the network has established, I still cannot play my Recorded Video ===

2021-06-30 22:53:15.986 T:2820641648   ERROR: GetTimers: Add-on 'Tvheadend:127.0.0.1:9982' returned an error: the command failed
2021-06-30 22:53:15.986 T:2820641648   ERROR: GetTimers: PVR client 'Tvheadend:127.0.0.1:9982' returned an error: the command failed
2021-06-30 22:53:20.987 T:2820641648   ERROR: GetRecordings: Add-on 'Tvheadend:127.0.0.1:9982' returned an error: the command failed
2021-06-30 22:53:20.987 T:2820641648   ERROR: GetRecordings: PVR client 'Tvheadend:127.0.0.1:9982' returned an error: the command failed

I do not understand how I can lose connectivity on my loopback, though.

I was pretty sure that my recording would fail as well, and instead, surprisingly, I haven't lost any packets at all, even while the wifi was out. If you look at my grafana, you'll notice TVH or Kodi cached the data and then sent them all as soon as the WiFi was re-established (I did tweak the advancedsettings.xml). Actually I do not have any issues in playing HD Video.

My settings are the following, and I am using buffermore=4 to cache NFS as well. Odd enough, I am using exactly the same memory size you are using!

<advancedsettings>
        <cache>
                <buffermode>4</buffermode>
                <memorysize>524288000</memorysize>
                <readfactor>5</readfactor>
                <curlclienttimeout>10</curlclienttimeout>
                <curllowspeedtime>10</curllowspeedtime>
        </cache>

I think the next steps will be the following:

1) improve the script to react more quickly (though I am not sure I will solve the TVH Client issue) and play with TVH settings to see if there is a way to speed up network recovery

2) Update the firmware (now that I know I need to add all the three files) and see what happens

3) If 1) and 2) are not working, I will try installing Buster Lite, add TVH and use Kodi on my FireTV as a player, to see if WiFi drops still occur

4) If I still have issues, I will have to take the drill and start cabling my house