Posts by chewitt

"User error: please replace user"

Are you running the latest nightly?

config SND_ALOOP                                                                          
        tristate "Generic loopback driver (PCM)"                                          
        select SND_PCM                                                                    
        select SND_TIMER                                                                  
        help                                                                              
          Say 'Y' or 'M' to include support for the PCM loopback device.                  
          This module returns played samples back to the user space using                 
          the standard ALSA PCM device. The devices are routed 0->1 and                   
          1->0, where first number is the playback PCM device and second                  
          number is the capture device. Module creates two PCM devices and                
          configured number of substreams (see the pcm_substreams module                  
          parameter).                                                                     
                                                                                          
          The loopback device allows time synchronization with an external                
          timing source using the time shift universal control (+-20%                     
          of system time).                                                                
                                                                                          
          To compile this driver as a module, choose M here: the module                   
          will be called snd-aloop.

No mention of SND_DRIVERS there ^ so looks like a kernel bug to report and submit a fix for

Honestly no idea and I'm neck-deep in debugging something so not going to spend time looking.

I bumped Kodi four days ago: https://github.com/LibreELEC/Libr…94747d2db405f63

So update to the latest nightly and it should be there.

If you have a working default image building, edit projects/RPi/devices/RPi4/linux/linux.aarch64.conf to enable the module then rebuild the image and it will rebuild the kernel and update the image.

At least that's the theory. It doesn't work for me on an Amlogic image with linux-7.3-rc2 kernel either, and diff comparing the edited conf and .config file from the kernel build folder shows the kernel has unset CONFIG_SND_ALOOP=m when processing the config; hence nothing gets built.

I will task Claude to investigate the problem once I take a break from some other debugging. I suspect some kind of upstream kernel issue and not something on our side.

Done

Quote from vobs

I would have to rename them like 'Movie.Year.3D.SBS.mkv' – it seems that the letter 'F' is preventing the 3D recognition.

First world problems

echo "127.0.0.1 update.libreelec.tv releases.libreelec.tv" >> /storage/.config/hosts.conf
reboot

Run that ^ over SSH

The fix will be in nightlies within 24h of this being merged: https://github.com/LibreELEC/LibreELEC.tv/pull/11756

You'll need to ask questions on the design intent in the Kodi forum; the author CrystalP is active there.

Quote from atoulmin

I noticed in the nightly builds that output for AMD radeon has shifted from YUV to RGB. Are we able to change that back? or at least offer a setting to switch?

AMD/Intel/nVidia cards *should* output in their native RGB format, and this is not a problem as long as the correct conversions are used; which are all broadcast standards. The change is that Kodi now implements and handles colour things correctly instead of not-handling them at all resulting in wrong output.

Make sure you have the GUI in expert mode.

Quote from plez

Any clue what's causing this ?

Linux 5.15+ removed support for NTLM: https://git.kernel.org/pub/scm/linux/…782eb68f61a179c

There was some discussion about reverting the change but Linus rejected the idea https://lore.kernel.org/all/CAHk-=wjSB…mail.gmail.com/ and a simple git revert no longer works due to surrounding code change in the kernel.

Some workarounds are mentioned in https://bugzilla.kernel.org/show_bug.cgi?id=216682; AFPS support via FUSE is probably the right direction to move in. The original AFPS project looks to be quite dead but https://github.com/Netatalk/netatalk-client seems to be current and might be something we can package into an installable add-on similar to NTFS-3G.

I still have a TimeCapsule in a box somewhere, but I'm travelling and it will be a ~week before I can investigate further.

It's best to allow a week between iterations of kernel patches unless it's a final 'one last thing..' respin. Maintainers have crazy busy inboxes and work up them in date/time order so it's annoying to spend time reviewing something only to discover there are another three iterations of the same thing on the same day that need to be reviewed, with only minor adjustments in each. Allow time for people to send feedback, then send one next version that incorporates all that feedback. Also, when replying to messages always reply to the comments inline and never top-post as this loses context/conversation threading. The maintainers on the Amlogic list are pretty relaxed folks about such offences, but others can get rather irate about it. The same comments apply to u-boot and most upstream projects where the reviewer/maintainers are also kernel people.

That said, most people (self included) learn what's acceptable on kernel lists though trial and error, so annoying a few devs and being told off is just a normal rite of passage

Your options are ViwX, ViwX, or ViwX .. so best to warm up to the idea of using it.

If you implemented cache fiddling on the current RPi4 setup; remove it and you'll likely discover things improve, esp. with LE13 images. Why? because there is a sizeable chasm between how most users think media streams and caching work, and how it actually works, which results in people with utterly moronic cache configurations. Unless your network is broken (in which case the solution is always to fix the network) there is no need for anything beyond Kodi defaults, no matter what some outdated reddit or Kodi forum thread armchair pundit claims or recommends. K22 has changed things quite a bit.

RPi5 is a noticeable update on RPi4. Generic PC stuff is a little faster again. There is no performance difference between 4/8/16 GB RAM in terms of GUI and playback because 2GB is enough for 4K and the GPU and Kodi desktop resolution (and key-repeat/scroll speed of the remote device) dictate how fluid things feel, not RAM size. These days 16GB seems to be the minimum DIMM size that you can so not sure anything smaller is even possible. The difference between DDR4 and DDR5 is likely irrelevant for LE use.

I have an RPi5 booting from an NVME drive (family daily-driver) and an Intel N150 box with eMMC storage (x86_64 dev work) and while the Intel box is technically a lot faster, the real-world difference is more marginal.

The SoC searches for a boot firmware signature on SPI > eMMC > SD > USB but most devices don't have SPI flash so eMMC will be checked first. If you are seeing that repeating bootrom sequence either eMMC is wiped or non-functional (and the device is in its lowest level of boot mode). On a normal box that would mean easy booting from SD or USB, but Dreambox One/Two use encrypted boot firmware so you can only restore original Dreambox images that are signed with the correct keys, and most Amlogic 'factory restore' images are eMMC specific so even if you write them to USB media the device won't boot them. If there's an official SD card restore image you can see if that will also work from USB, but I suspect it won't. Normal S922X hardware is a little easier to mess with but secure boot devices are inherently more limited in options.

Please share the full system log, e.g. journalctl | paste after a clean boot with the images in https://chewitt.libreelec.tv/testing/

Also, what spec is the PSU? .. under-spec PSU's and ARM SoC boards often result in instability on the SDIO bus and WiFi chips draw more power than you'd think sometimes. NB: The clm_blob 'error' is completely harmless and can be ignored.