Posts by chewitt

Quote from Free Man

Would you recommend a 4 or 8GB Rpi5 for running LE?

I wouldn't look at the 8GB model unless planning to run containers and such in the background. For normal LE use a 2GB board would be fine so the lower spec 4GB board is more than enough.

Quote from jack121

Would LE install onto a zidoo z9x pro

100% no, it has a Realtek RTD1619BPD SoC chip with zero upstream kernel support.

This is a box for the pirate BeOutQ satellite service in the Middle-East (targetted at Saudi Arabia). According to a UEFA report on the box that I found in Google it has a Montage M88RS6060 tuner and this chipset has drivers in the upstream kernel (CONFIG_MEDIA_TUNER_M88RS6000T) which are not currently enabled in the AMLGX image; but the user behind the video has presumably self-built an LE image after enabling the needed things.

LE10/LE11/L12 all support DVB hardware (internal or external) *IF* the hardware has upstream drivers. Your WP2 box has old drivers written for 3.10 kernel that were ported to 3.14 .. and nothing newer. I made an attempt to clean-up the tuner/demod/diseq drivers (enough to compile them on a recent/current kernel, see https://github.com/chewitt/linux/commits/dvb-sucks) but these drivers are not modular following modern kernel standards and more code-glue is needed to make anything work; and AFAIK the signal from the tuner and demod needs to be processed by an Amlogic demux driver which doesn't exist. I have no real clue how the DVB stuff works and I don't write code .. someone that does needs to take that work forwards.

TL/DR; nothing new .. nothing that will advance the non-support for the tuners in your WP2 box.

To my ears that sounds like even greater justification

Thanks for confirming. The change will go into LE12 with https://github.com/LibreELEC/LibreELEC.tv/pull/8201

I'm reading your description and my first thought is .. this user needs to get a NAS box and migrate the mess of USB drives and cables and wall-warts into a single device that just sits in the network serving media. Not the cheap option, but it'll be a pile more reliable for any client box/board to work with and you'll quickly forget all about USB woes and focus on movie watching.

NB: No idea about numbers of drive limits or power limits; not my area of expertise.

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.