I've removed the links. It's the same as the cheapest box I have available here ![]()
EDIT: I've ordered one for $25, arriving this evening. It'll give me something to play with while resting legs next week (am running a marathon tomorrow morning).
I've removed the links. It's the same as the cheapest box I have available here ![]()
EDIT: I've ordered one for $25, arriving this evening. It'll give me something to play with while resting legs next week (am running a marathon tomorrow morning).
There are some rough edges to NTFS support since we switched from NTFS-3G to in-kernel drivers with LE11. However that should only result in the mounted NTFS volume being marked "dirty" needing chkdsk.exe to clear the dirty state. We haven't seen reports where volumes or the underlying partition data have been trashed. Most partition schemes also maintain multiple copies of tables to prevent against total loss (or to at least make restore easier) so if those are also missing I'd be suspecting a more serious problem with the storage (favourites would be power and firmware issues): I note that LE deliberately doesn't support any form of software RAID so it must be done in hardware (which means RAID config is nothing to do with our software).
Partition data can be backed up with a script that uses "dd" to copy the first few MB of disk to a file. You then need to script that being sent off-box or stored on a separate storage device. You can automate script execution with cron or a systemd timer.
Have a read: https://wiki.libreelec.tv/hardware/amlogic
The images in my test share https://chewitt.libreelec.tv/testing/ have some additional Realtek drivers that are deliberately missing from official images.
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.
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).
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
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?
I just updated - the sound is gone again !
![]()