Posts by chewitt

/etc/fstab exists solely to stop some error messages from being shown. It's not actually used so you will never see content about drive mounts there. And I'm guessing the command sequence based on the "emmctool" script that's embedded in the Amlogic image. The general principle is that you shouldn't peform change operations on mounted partitions and filesystems and some commands result in auto-remount being triggered so you need to unmount things again before you run the next command. So unmount, grow the parition to 100%, then resize the filesystem to 100%. There's no need for crash helmets as the worst that happens is you mess up something that isn't being used and doesn't already work. You can always start over and have another go.

NB: I'm wondering if an "nvmetool" script might be useful for RPi5 boards.

It might need an eeprom and USB firmware update at some point, but there should be no reason why it cannot run LE12.

Quote from gregtotheizzo

Is there anyway to edit a conf to disable the SSL requirement in the interim?

No, it needs to be compiled with the right options. The fix is in LE12/13 nightlies for a while so just update to the current one?

Quote from Da Flex

You probably found 3 add-ons, which are still using Python 2.

Probably not if the addon was working under LE11 as per post #1.

Seeing a full debug log would be useful.

Attention from Intel devs is never guaranteed, but if you never open it, you can guarantee it never receives attention. TL/DR; open the ticket, there is nothing to lose.

NB: Assume that Intel devs have little clue what LibreELEC is (let alone our release numbers) so focus on talking about kernel details that they do understand.

Thanks for confirming. I'll push some changes out.

EDIT, fix merged to master now. Separate fix will go to LE12 in a couple of days I'd guess.

The log doesn't show anything.

The normal approach is to designate one of the HTPC devices (or a NAS box) as the 'server' and use a common MariaDB instance to host the Kodi database along with the content being played. That's going to need a reasonable network though: Ethernet is always advised as the amazing WiFi speeds acheived in some test lab for marketing purposes are never the same as your home in real life.

I've also seen people use rsync to literally sync local database files and thumbs between different LE devices, but that relies upon you only ever using one device at a time and performing a sync before you switch devices; else things are quickly out of sync. The rsync binary is in the network-tools add-on IIRC.

What happens if you first install using the LE10 image and then manually update to LE12?

rellla please try this image: https://chewitt.libreelec.tv/testing/LibreE…droid-n2.img.gz

Quote from 824c6286420nyn

so I don't think it's a cable issue.

Well, it reads exactly like a cable issue. Also make sure you have the latest BIOS and graphics firmware that might be available. Intel have a long history of buggy firmware.

This wiki article explains a bunch of things: https://wiki.libreelec.tv/configuration/4k-hdr

Urgh.. I didn't see that the first time (need new eyeballs). So my guess about needing /amlogic/amlogic/*.dtb is correct. That patch fixes another variant of the issue but is only relevant for u-boot 2024.07 (we are on 2024.04).

If the TV doesn't provide a 24Hz mode I would leave the desktop set to 1080@60 and enable 3:2 pulldown in Kodi settings. Adjust refresh is in Settings / Player .. and I would leave it set to start/stop not always.

Quote from mtrcycllvr

so, I guess close this thread as 'solved'...

I'm now seeing normal HTTP requests to the ARMv8 repo which is presumably the RPi, so "turning it off and on again" seems to be the fix for things. I've marked as closed.

Quote from mtrcycllvr

Kodi was making requests from high number ports vs. just straight from secure http on 443

That's normal and correct behaviour. There are muliple processes inside Kodi that might need to communicate to a remote service on 443 at the same time. If only outbound 443 could be used they would all have to queue up and wait for their turn to use the port, and you'd need some clever scheduling code to manage all the requests. If each process communicate outbound on a random port they can all talk at the same time and stuff gets done a lot faster. It's how all modern TCP/IP apps work.

I did a little digging on our side this morning. I can see requests in the addons webserver access log from an RPi3 running an old Milhouse image. This is hammering the server with multiple requests/second, which is not normal behaviour and suggests some kind of issue somewhere, but according to the webserver logs we are responding (HTTP 206 status responses). I see no requests from any other device (from the same static IP) and no other HTTP status response codes, e.g. 404's or such, only 206's.

From what I can see on our end, the issue isn't on our end.

Similar != Same. Kodi 20 (Nexus) and Kodi 21 (Omega) use different SMB (and NFS) client caching defaults.