Posts by chewitt

Quote from Watersnapper

Would there be away to write Libreelec it to the onboard flash so it doesn't have to keep booting from the SD card?

In short, no, we would need the original u-boot sources from the vendor to extract needed boot files to build a dedicated image.

Have a read of this for the remote: https://wiki.libreelec.tv/configuration/…ration-advanced .. the article needs updating to reflect a move to "toml" format files. If you look at the existing .toml files in the filesystem (find / -name *.toml) you'll see the format is very slightly changed, but still easy to crib.

Have a read of this: https://wiki.libreelec.tv/configuration/4k-hdr .. the HDR bits aren't relevant (S905 doesn't support it) but everything else regarding adjust-refresh and modes will probably help with playback. Otherwise the big fat disclaimer on what works/doesn't-work and the general state of decoding in the AMLGX image that's in the public release notes applies.

Hard to say .. I've done little testing recently due to being on a different continent to all my test kit

No idea on the SMB issue; look at system logs on the Windows side and LE system (not Kodi) log.

RockPro64 is nice hardware RK3399 but despite having a sample somewhere I've done little with it and can't speak from experience about how it runs LE these days; my general impression is that RK3399 doesn't have all its capabilities supported (but I could be speaking out of my rear .. since I don't use them much/ever).

RPi5 is faster and despite being technically less capable on-paper in terms of codecs is probably more useable today, and I speak from the personal experience of using one over the last few months during pre-launch dev/test. RPi5 would be my go-to (as it already is).

Pi codecs are pretty robust, but ultimately they are large and complex software so there's always opportunities to throw weird media at them and cause new crashes. Hence the request for a snippet that causes the problem; pi devs like those and will typically investigate to see if any changes can be made to avoid the problem and play the media, or at least fail more gracefully.

Leaving DRMPRIME off is proably not what you want as it means all media is software decoded and at some point that'll cause different issues.

Recycled RPi3 or a current RPi4 (or RPi5 once it ships in a few weeks) with an analogic DAC card (HAT) to create the RCA outputs. It's a little bit more fiddly to assemble than something that ships in an all-in-one box, but it should be cheaper than £200, and it's based on the most reliable hardware that we support. Lots of Pi DAC cases available here: https://thepihut.com/collections/raspberry-pi-audio-cases and most DAC cards give really good quality audio output, unlike the all-in-one boxes intended for HDMI use where analogue is an afterthought.

LE aims to be a minimalist OS so we don't pre-embed the full 350MB of linux-firmware needed to support all cards; so an educated guess is the driver modules are present in the kernel but the firmware blob(s) needed for the card to boot are missing. Run "pastekodi" and share the URL generated so we can see the boot log. It will normally flag the missing file, which can be manually downloaded/installed to prove that the card works once files are added, and then we can pick those files into the AMLGX image so manual fiddling isn't needed in the future.

Now what needs to happen is to email the alsa-devel mailing list with a plain-text email (not html) that has a good description of the problem, some log examples (via pastebin links) of before/after, and the contents of the files that you generated. Then hopefully one of the names on the list can spot what kind of exception/quirk needs to be added to eliminate the workaround. If you do that and you're given a patch to test, ping us back because it's fairly simple to spin an LE image with the patch and have you test it.

Installation to spare disk space (needing two partitions not one) is possible, but not using our installer, and we do not provide instructions or support on dual-boot setups. If you know what you're doing (and depending on which other OS's are involved) it's not particularly hard to configure. If you don't know what you're doing (and most users don't) then it's a fiddly multi-step process with lots of confusing terminology and a high risk of trashing the other OS installs. We're not interested in the support work of guiding someone through recovery, which is why we don't have the feature or support dual-boot setups.

2023-10-09 19:45:27.267 T:1229    ERROR <general>: CFileCache::Open - <http://USERNAME:[email protected]:9981/imagecache/151> failed to open
2023-10-09 19:45:27.268 T:1229    ERROR <general>: CCurlFile::Open failed with code 404 for http://127.0.0.1:9981/imagecache/85:

It's not a debug log (so of limited use for diagnosing media issues) .. the only thing that stands out is ^ this sort of thing which is probably missing channel picons or thumbs of some kind in TVHeadend which is causing delays when doing DVB things. I don't see any attempts to play offline media though .. which is presumably what a delay when "navigating to a folder" is about. Debug log needed for that.

As noted by johnny depp the installer app should be able to see the USB drive under Windows to write the LE image directly to the SSD. RPi images do not boot into an installer where you pick the install target (as in the Generic image).

Does the SSD have it's own PSU or are you trying to power the SSD from the board? .. and what PSU is being used?. Note that USB booting has a much higher current draw on the board than SD card and will need something like the official Raspberry Pi PSU that's rated for (and will actually give) 5V/3A to avoid power brown-out issues; which from the description of boot failures and reboots is my guess/hunch on the problem. You might also need config.txt changes to boost power on the USB ports and some USB drives still suck enough current to need their own independent PSU. For kicks, you can also boot an LE12 nightly from SD card and ensure any available firmware updates have been applied (via updates in LE settings).

If this all sounds fiddly, please remember the board was designed to boot easily from SD card (and that bit works easily and as advertised). If you want to go off-piste with more exotic boot scenarios it's not quite as straightforward.

cp /storage/.config/samba.conf.sample /storage/.config/samba.conf
nano /storage/.config/samba.conf
<make changes, save, exit, etc.>
reboot

In LE the /etc/ path is inside a read-only file so cannot be edited, but renaming the samba.conf.sample file and editing does the same thing.

Did you interrupt syslinux and type the command? (correct) .. or boot into the installer and type the command? (wrong)

No idea on the boot/reset issue. You need to force recovery boot if the device has been running CE else the u-boot bootscripts are looking for the wrong files; but your description says you've seen the Kodi home screen which would mean you've gotten beyond that issue and first-booted the box into LE.

You can use the same video= line but chage the resolution to 720p. Kodi can only handle progressive output so will ignore 1080i resolutions.

Otherwise it's pretty much impossible to "guess the issue" without UART logs from the box.

Upstream u-boot has no support for Amlogic proprietary restore image formats and sequences.

No idea what the issue is, but if the nightly works, use it, you'll find it's quite stable (Kodi is overdue a move to Beta).

Removing "quiet" and adding "ssh" to the APPEND line in uEnv.ini will result in console output on-screen (although it tends to dump text to screen faster than most eyeballs can track anything) and forces SSH to start so if boot has reached userspace (maybe) you might be able to connect to the box and poke around to look for issues. Something else to try is adding "video=HDMI-A-1:1920x1080M@60" (all on the same line) to force DRM output to 1080p; in case it's trying to use a 4K mode and disagreeing with the TV panel in some way.