Posts by chewitt

Quote from dmladenov

So can we confirm that all p271 boxes are Mali 450-MP2 and should use meson-gxl-s905l-p271.dtb from your images ?

The current assumption is that p271 is the "3" variant and p261 is the "2" variant, so I need to switch the numbering else p271 will try to use 3x Mali cores and everything will lock-up when the hardware probes. I'll let you know when that switch is done.

What does the case on your box look like? .. Amazon UAE has some cheap S905L devices so I might get one to run experiments on the audio problem. That needs to be resolved before I think about trying to upstream anything.

I have a hunch it's down to media type, as I don't see 'gaps' in playback with normal mp3 tracks but do occasionally hear them with WAV files (used for DTS albums) sometimes; more noticeably when tracks have large filesizes and/or when I ripped an album to a single large file and not individual tracks. I also have some badly ripped mp3's from the early 2000's that have legitimate silence in them (annoyingly).. it was a thing sometimes back then. Otherwise there's no setting for gapless playback, it's the default.

Have you enabled the service, i.e. "systemctl enable /storage/.config/system.d/add-route.service" ?

RPi5 has a power on/off button and the Flirc case (shipping soon) will be decent (and there are others). For sure it's not the perfect hardware for everyone's taste, but it has the best software support by noticeable margin and that's the most critical factor for daily-driver usage with LE/Kodi. NUC's started out as a solid piece of kit and their reputation is built on that, but in the last few years as Intel bred chipsets faster than people wrote drivers for them it's been less smooth sailing and the current experience does not live up to past reputation. I think some of the cheaper mini-PC devices devices that ship these days have promise, but I think software support needs to improve in multiple places before you'll see project staff singing their praises.

I've noticed some glitches playing things back but I haven't had time to investigate properly. I have a hunch this is related to Kodi rendering and not the codecs; though those definitely have their own issues too and that's what shows in the system log. Over time the surrounding kernel keeps moving forwards so the lack of codec maintenance means differences start to creep in, causing minor regressions until eventually something more fundamental breaks. There's an issue with buffers not being free'd which will cause the device to run out of memory over time, and there are other things too.

The other hardware device that isn't working correctly is the rtc chip, which doesn't report any time data. If the boxes use a coin cell batter that can be removed, remove it and it might show different log messages. If it's a soldered one that's not possible but the thought it that low/under voltage might results in bad or no values being readable.

Thanks for confirming WiFi works again.

There's nothing in the Kodi logs, which is one reason why we asked for "pastekodi" which also outputs the systemd log. You may also need to include the FTP server log (assuming there is one).

It'll be more work to create and maintain an add-on than to simply rebase the one-line/one-commit change to enable/include the package in a self-built image. The add-on would only work for your post-boot use-case whereas iscsi is more commonly used for early-boot things (albeit not within LE as I don't recall anyone complaining when we dropped it from the image).

cd /storage/.update
wget https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.aarch64-11.80.0.tar
reboot

No need to burn/write anything .. Just update the existing installation ^

We stopped including iscsi support in the main image some time ago, but the package remains in the buildsystem so you could self-build with it enabled again, see: https://github.com/LibreELEC/Libr…EC/options#L197

Instructions for self-building: https://wiki.libreelec.tv/development/build-basics

It's not really a tried-and-tested solution for you want to do, so while it should work in theory, practice might be more fun.

LE 11.0.4 and LE12 nightlies already switched to using https://paste.libreelec.tv

ExecStart=/bin/sh -c 'ip route add 192.168.1.0/24 via 192.168.0.10'

^ You probably need to use the full path to the shell binary?

risa2000 Interesting. Nice to see the errors are gone. The log also shows Broadcom WiFi is now missing but I suspect that's due to another change I made. Can you update to https://chewitt.libreelec.tv/testing/LibreE…h64-11.80.0.tar and share the boot log to confirm (it should be fixed if I'm right)?

wapvi can you confirm it resolves things for you too?

Quote from dmladenov

I just updated - the sound is gone again !

Share Kodi and/or system logs that show a problem, else we have no idea what the issue is.

The images in my test share exist solely to support me testing things with random users. I deliberately use a fixed version and rarely clean build and almost never document the changes inside. I have no plans to change that, so use them at your own peril

If you want something that more directly tracks the upstream LE repo and with known content, it's time to learn how to build your own images. It's not rocket science: https://wiki.libreelec.tv/development/build-basics

4K content comes in a wide variety of different refresh rates and codecs; in fact one of the odd things in your log is no info on the codec of the source media. FFmpeg is instructing that codec id=xx is being used but there's nothing to indicate what that is, and I normally see something more explicit; though with local file or normal internet streams. I'm wondering if that's being obscured by inputstream.adaptive?

Can you repeat with FFMpeg component logging enabled in Kodi settings (System > Logging .. IIRC). Also make whitelist changes as those should generally improve playback over a wide range of media. Does it influence the outcome?

Press 'o' on the keyboard attached to the device or SSH into the box and run "kodi-remote" and press 'o' again. It's not possible to access this directly from the OSD pop-ups.