Posts by chewitt

Something probably got bumped out of sequence and there's an API/ABI change to handle. Give it a couple of days and through general package bumping it will probably resolve itself. Thanks for the tip.

heitbaum ping ^

crazyturk issue is that AMLGX LE12 nightlies are still building with "arm" userspace while the general assumption in our buildsystem is that all ARMv8 SoC devices are now using "aarch64" userspace. In short, the common ARMv8 "arm" repo probably isn't being built and thus does not exist or best case it exists but is incomplete (missing all the binary add-ons) and thus you can't install them. If you look in a Kodi debug log it should be fairly obvious from the URL failures.

I will need to look at bumping kernels to Linux 6.5 and moving AMLGX to aarch64 .. I had been hoping to ignore that for longer.

RPi boards have no real-time-clock (RTC) hardware so 'dateTime' in the OS initially starts from the libc release date (in the LE image you're using this is a date in Febuary 2023) and then once the network is up an NTP request to pool.ntp.org time servers corrects dateTime. At least, that's what's supposed to happen. In your case boot looks normal and I can see the board gets an IP, but NTP isn't resetting dateTime so the clock remains in Febuary, and this means any website/service that presents a TLS certificate with a start date newer than the OS clock is seen to be in the future and invalid, which renders that website/service inaccessible; and this can be seen in the logs.

It's unclear why the NTP request is failing, but that's the cause of the issue. The workaround is to set the correct date/Time using the "date" command via SSH, but this will not be persistent over a reboot due to the lack of RTC chip on the RPi board.

Some ISPs seem to block NTP requests to pool.ntp.org servers, in which case another can be configured and used via the LE settings add-on or through 'connmanctl' (the connection manager utility). Many routers will also respond to an NTP request.

It doesn't sound like a software problem.

Kodi is not good with large file listings, but this is how Kodi is coded (and something likely changed between Leia and Matrix) so your options are to seek changes from the people who code Kodi (via the Kodi forum) .. or since everything is open-source, you can modify Kodi code and recompile things yourself (although few users will have the skills for that).

RPi2 (1GB) should be as smooth at H264 decoding/playback to RPi3/4; except for being slower at everything requiring CPU, e.g. navigating around the Kodi GUI (where RPi3 is quicker and RPi4 considerably quicker). The VC1 license won't help H264 (as different codec). If you only need offline media you might want to compare the older LE 9.2.x release with LE11.x as it's a little lighter and more optimised on older Pi hardware.

Note that "The Audio DB" and similar metadata repositories allow users to contribute content. If your favourite (but obscure, or at least not listed) band/album is not in the DB, you can add it, and then it will scrape (for you and for anyone else).

No debug log = Nothing to investigate. https://wiki.libreelec.tv/support/log-files

2023-08-30 18:37:01.357 T:910      info <general>: ffmpeg[0x3cb1230]:   Stream #0:1(por): Audio: ac3, 48000 Hz, stereo, fltp, 384 kb/s (forced)
2023-08-30 18:37:01.357 T:910      info <general>: ffmpeg[0x3cb1230]:   Stream #0:2(eng): Audio: dts (DTS), 48000 Hz, 5.1(side), fltp, 1536 kb/s (default)

^ Have you selected the right audio stream? .. it looks like the Portugese audio is stereo, and English is 5.1.

That's the boot log from linux mint .. which looks to be using the out-of-tree vendor drivers (kernel is tainted). You need to share the boot log from LE .. run "dmesg | paste" and share the URL.

If the OS date/time has not been updated via NTP (which would be unusual) it can mean the OS time is before the validity start-date of TLS certificates used by websites; ergo the cert is invalid (from the OS perspective) and comms can fail. That's simple to check via SSH and usually somewhat human-readable in a Kodi debug log.

Reboot with Kodi in debug mode and run "pastekodi" and share the URL so people here can read the logs.

LE 11.x supports NTFS, but we switched from the NTFS-3G (FUSE) drivers to the upstream/in-kernel drivers, so there are technical differences and likely new and exciting error messages to discover and understand.

Best to read/check the add-on support thread in the Kodi forums.

Best to check/read the add-on support thread in the Kodi forum, and if needed ask the Q there, since it's not really an LE issue.

The correct resolution would be getting a NAS device to avoid all the wiring and silliness associated with USB devices .. but I doubt that's the answer you're looking for

You'll need to share a boot log for any serious comments. That will also shed some light on what device you connected all the drives to..

It sounds like more of a hardware problem than software. Perhaps a bad power-supply? .. or dry solder joints on the PCB inside the box? .. or failing RAM .. it's hard to comment when it's hardware (and hardware issues can't be fixed with software).

Bookmarks and Series/Episode watched status are different. Bookmarks are temporary; they exist only for a single episode to permit restart at the same point in a single episode. After the episode is watched, the bookmarks are cleared. Similarly (but separately) TV show episodes are watched/unwatched, and this allows Kodi to position which episode is next in a series when you navigate into a series. Watched/unwatched status is persistent in the library views, so once an episode or series has been watched it remains 'watched' .. but this can be changed via the context menu; and you can set the series as watched or unwatched.

All this is documented in the Kodi wiki: https://kodi.wiki

Perhaps try adding "video=HDMI-A-1:1920x1080M@60" to the kernel boot params in /flash/syslinux.cfg .. "mount -o remount,rw /flash" to make the partition read-write first.