R-Pi Update fails

The Feb. update is not loading correctly.
25 files. 24 are downloaded ok. The 25th (I think it’s mediacenter) hangs after a few bytes, the download rate goes to zero and times out.
I have tried several times, always the same result.

I don’t see any indications of errors (or even update/download activity) in any log files…

Neither can I :slight_smile:

Can you share those logs?


I need to enable debug and re-run. I will send the logs when I have done that.
– I was hoping it was going to be a known problem with a known (and easy) fix :slight_smile:

Having problems uploading … so here is a link to the debug enabled kodi.log file:

I need full logs, please uploading using the My OSMC system.

Which would indicate network issues.
So can you connect by SSH to the Pi?

Yes, I can login and I can stream programs (BBC) as well as content from my file server.

A bit more context, in case it is useful:

All IP traffic from the R-Pi running OSMC is routed through a permanent Wireguard connection on my firewall/router to a small Lightsail instance in the UK with a static IP. This gives us access to programming we want.

My local internet connection is 1.2G. There is no real network bottleneck, as can be seen from this snapshot monitoring the traffic on that Wireguard interface while my wife watches a TV program:

This has been working fine for several years, including updates. It is only the last update that has problems, and only with the last couple of files … usually the last, but I have also seen it quit on file 24.
The transfer rate just gets worse and worse, with long periods of no traffic, until it quits.

As soon as I can get to the device, I will turn on debuging and try again.

I noticed that each time I trued the update, the downloa would progress a bit further.
Watching the display on the router, I saw bursts of activity, downloading between 4 and 5 Mbps, then nothing for a long time. Occasioanl spikes of download, maybe another small burst or two then finally timing out.

This really looks like an overloaded server??? to me.

Anyway, after multiple attempts, it finally loaded 100% and the update applied successfully.
Still trying to update the logs using “grab-logs -A”
It’s running, but throughput is a bit slow…

No other reports of update issues here.

Here are the debug logs anyway — uploading finally failed.

If you can’t even upload logs you have a network connectivity issue, they run on complete different servers

I am beginning to think you are probably right…
It must be the forwarding in the Mikrotik router, because a direct wireguard connection to that VPN server has no problems at all…

Keep things simple first, start with the basics.

Our servers are doing just fine.

This is really an FYI, in case anyone is interested.

Tracked down the problem and fixed it.
I can’t say that I entirely understand why it was performing so poorly … but …

My router (Mikrotik) had an OS update - a major revision update.
As part of the update, some of the routing was changed. The update process automatically modified some routing to use the new features.

The old scheme I was using was pretty simple. Packets coming from the system running Kodi were tagged. Tagged packets were routed to a VPN interface.

The new scheme uses a level of indirection, using specific routing tables. The modified config created a routing table for the VPN, and used the table to route tagged traffic.

It was not working well. Well enough to stream HD TV, but quite poorly on upload traffic (to anywhere).
I gave up trying to see why it was not working well, and changed the way it worked, removing the tagging of the packets, and just adding a specific route for traffic from the Kodi IP to the VPN (Wireguard) interface.

It worked. Full speed (limited by the WiFi speed of the Kodi device ~50Mbps). Ran the update, and it worked with no issues.

I still can’t see why the tagging solution that worked fine before it got “auto updated” didn’t work - it was more complex than the original, but I think it should still have been working.

Whatever. The simplified solution just using a specific route coupled with a specific routing table works fine.