Posts by frakkin64

RPi4 doesn't have a clock, so LE needs network connectivity and a working network stack to reach an NTP server to set it during the boot. If you do have an RTC, then you would likely have to enable it with an overlay, check with who sold the device. It will likely need NTP to initially set the clock.

I don't know anything about HifiBerry, but pointing out the obvious that it also depends on your media source. If your media source is not 5.1, is poor quality, then garbage in/garbage out. I'll leave it to DAC users to comment, I just use audio over HDMI.

Did you try a recent LE12 nightly? I don't know which platform (x86-64, I guess?) but RTL8822BE is enabled on LE12 nightly. RTL8822BU (usb variant) is working without issue on LE12 nightly for RPi4 platform.

Quote from bizpix

So, new SD card - New LibreELEC-RPi4.arm-11.0.3.img

but im still getting "ERROR IN MOUNT STORAGE" (image attached)

Any ideas please? Is my Pi4 corrupted?

It's probably the SD card, there are some SD cards that the RPi just seems to hate. I don't know if updating the EEPROM brings better compatibility, because for me the problem eventually went away.

What brand/model of card is it? Another thing to try is pop the SD card into another computer, edit the cmdline.txt on the FAT partition and add this at the end of the line (not a new line, without quotes, make sure to add a space and then the text):

" sdhci.debug_quirks2=4"

This will disable UHS modes, IIRC. The card will operate slower, but perhaps more reliably. That's what used to work for me on LE10.

LE12 nightly box image works, with the known issues in the release notes. I have run LE, CE, Armbian, and OSMC on the Vero 4K+, the former three are via SD card (nothing installed to eMMC other than OSMC).

The only problem I have with OSMC (in terms of a media center OS) is they are a bit slow on the take up of Kodi releases. I think the other issue that is possibly looming in people's minds is now that they have their next device out how long will the 4K+ continue to be maintained.

Right now, I am just using it to run Armbian as a serial console terminal. Personally, I am sticking with RPi4 or moving on to x86 devices.

One other comment with the Vero 4K+ is you have to use the toothpick method to boot the SD card, and be warned if the SD card is not prepared properly then there is a bug in the bootloader that will wipe the instaboot partition and cause OSMC on the eMMC not to boot. This, in my opinion, is because they (OSMC) didn't modify the default bootloader script to remove the "wipeisb" & decided to use multiple Android partitions in an LVM group.

Quote from chewitt

The percentage of x86_64 users peaked around 30% in the early years of OpenELEC then gradually declined to a stable 10% figure in recent years.

Just guessing, but I would suspect many x86_64 users are using Windows. HW compatibility, acceleration, DRM, etc is what I would expect to be better & more attractive on Windows since that is the main OS platform x86_64 manufacturers are targeting.

Widevine isn't delivered by a repository, however Inputstream Helper addon (which is a dependency of the netflix addon) can download & install it.

The place to start is the add-on github.

CastagnaIT/plugin.video.netflix: InputStream based Netflix plugin for Kodi (github.com)

Seems there is an issue open with 103 replies for the same error, which probably means it isn't fully known/resolved. My advice is to buy a SmartTV, will save you a lot of headaches for Netflix, Prime, Disney, Hulu, and so on. I dropped Netflix over a year ago, so that's about all I can suggest, and I use my Smart TV to watch Prime.

By the way, it wouldn't hurt to turn on debug and upload a log file.

Log Files - LibreELEC.wiki

It might help with more informed answers. The HDR/4K guide is also something to follow closely, IIRC LE11 or LE10 defaulted the GUI to the highest resolution and 4K is absolute murder for RPi4, especially if it is upscaling 1080p content to 4K. You definitely want to make sure you set your display resolution to 1080p and use whitelists/adjust refresh rate if you need to play 4K content.

Quote from barry

Can the analog output issue be filed as a bug/regression? I was using it for several years until it broke in v11.

I am not sure if it's LE or the kernel, but you can certainly log an issue. Might be good to try an LE11 nightly, as it should have a later kernel. Or if you are brave, the LE12 nightly is pretty stable.

LibreELEC official nightly builds

Quote from barry

Others are not having stuttering on RPi4 & EL 11?

Nope, works great. It's probably your analog audio, can't imagine a lot of people use it. Try using HDMI audio and rule that out.

Quote from oJPTo

thanks, posting random links does not help.

I am rather sure it's not about power.

I tried two different self powered hubs.

I use the original raspberry power supply and the USB device uses less than 200 mA / less than 1 Watt when in use. (the rest went to USB hub and power supply, because I measured the brut amount)

problem does not happen on PC.

But it's ok. I give up.

Display More

At the end of the day your issue probably needs someone familiar with the driver & usb hub, which means it is a mainline Linux problem or Raspberry Pi Linux problem. It's not unheard of to be the latter (there has been breakage before on Raspberry Pi's kernel that manifested with the same error), and they are probably in a better position to provide some sort of support. It could also just be a shitty device. I guess don't be surprised if it's not solved, it often takes someone with the technical knowledge of the driver, device, and stack in between to solve it. The other option is going back to the manufacturer and see what they will do to support it, probably nothing as that is pretty typical.

On the bright side the problem is more in the annoyance category, at least it works.

Do you happen to have "adjust display refresh rate" turned on with nothing whitelisted? I would turn that off and see what happens, then you can go back and set it up properly.

2023-10-29 15:36:41.001 T:1119 DEBUG <general>: OnAVChange: CApplication::OnAVChange

2023-10-29 15:36:41.635 T:1172 WARNING <general>: CRenderManager::Configure - timeout waiting for configure

2023-10-29 15:36:41.636 T:1172 ERROR <general>: OutputPicture - failed to configure renderer

2023-10-29 15:36:41.653 T:1172 DEBUG <general>: CRenderManager::Configure - change configuration. 640x480. display: 640x480. framerate: 29.97.

2023-10-29 15:36:45.639 T:1170 DEBUG <general>: CVideoPlayer::SetCaching - caching state 0

2023-10-29 15:36:45.639 T:1170 DEBUG <general>: CDVDClock::SetSpeedAdjust - adjusted:0.000000

2023-10-29 15:36:46.653 T:1172 WARNING <general>: CRenderManager::Configure - timeout waiting for state

2023-10-29 15:36:46.653 T:1172 ERROR <general>: OutputPicture - failed to configure renderer

Quote from oJPTo

You have to re-insert the usb device after every boot, else it won't work.

I don't know if this still works, and what the PSU requirements are.

RPi 3: USB not enumerating during boot, fine on hotplug - Raspberry Pi Forums

But in essence your issue:

[   14.777058] usb 1-1.1.2: dvb_usb_v2: 2nd usb_bulk_msg() failed=-110
[   14.777103] dvb_usb_af9035: probe of 1-1.1.2:1.0 failed with error -110

Appears to be kernel/bootloader related, nothing to do with LE. Earlier on you can see it enumerating the device, it just later on fails with this. You might want to try logging an issue on https://github.com/raspberrypi/linux and see what they have to say, the forum post suggests it doesn't do anything (would have to check config.txt documentation to see, it might be for RPi2 and earlier)

More info on max_usb_current, seems applicable to 3B+?

B+ and max_usb_current - Raspberry Pi Forums

Quote from LybsterKodi

I'd be happy to have the house rewired and buy new kit & a NAS to run gigabit .

You can pick up a UPS for about $50, there is an Amazon branded 400VA one. It may be worth the hassle. As for rewiring, you can certainly run/stream over wireless from a NAS, you just have to tweak/tune and deal with the potential problems with wireless. I have been doing it for 10 years, and with 802.11ac and later it very viable.

Biggest issue is if you're using a Raspberry Pi 4 or less is being aware of that you're not getting the full 802.11ac bandwidth, it's about 80~100Mbps in terms of actual transfer rates. But that is suitable for most content and paired with a relatively decent size buffer cache you can manage 4K content over 802.11ac wireless with no problems. Obviously sustained high bit rate video in excess of your actual transfer rates means you will get stalling, but I have never seen that with movies. The easiest solution is a USB dongle, with those on a Raspberry Pi 4 you can get 270Mbps transfer rates fairly easily over wireless, which is more than sufficient for any content.

But wireless can be a real pain in the butt, so don't get me wrong on that. I personally learned a lot dealing with it, mostly using commodity hardware like the TP-Link Archer A7 v5 running OpenWrt, and TP-Link AC1300 USB dongles (w/ mainline backported rtw88 drivers tracked to LE12 RPi4 devices).

Anyways, if I have the motivation to pay someone to rip up my house to wire it with Ethernet then I would probably do it (probably wiring for 2.5Gbe/10Gbe), but I am cheap and what I have is working fine. Not to mention there are more important improvements that actually help resale, like bathrooms & kitchens that are actually becoming a necessity to do.

Fairly sure it is a 32-bit kernel, it's been a while. I think the issue is MMAL couldn't work with a 64-bit kernel & 32-bit user space (see here), I remember reading that way back when I was still using Raspberry Pi OS and running Kodi on that.

It could be an add-on as well, or any number of causes. But I think the point is LE 9.2 is no longer being maintained, so your not going to see any fixes unless you can find someone on the community maintaining it. So why not just upgrade?

LE12 nightlies work great as daily drivers, sure there are bumps in the road if you update frequently, but you can settle into a stable nightly and it works fine.

BTW, I realize the link I included doesn't exactly say that, I'll see if I can find where I read that.

BTW, "uname -a" will confirm for you on the shell in LE9.

$ git branch --remotes --contains 303d2b39c021ffbd7fece0db7822d8f5e0c1b73f

upstream/libreelec-10.0

upstream/libreelec-11.0

upstream/master

Quote from frankvw

Yes, you're right, htop is also affected (although it's less noticeable there).

Yeah, mc is a trainwreck, there is just so much more to draw. There is a PR now, just waiting on review by the developers. The other big issue is it would require bumping the addons and rebuilding.

I rebuilt system-tools & network-tools with the PR for LE12, and it's smooth now.

It's probably something related to ncurses library or terminfo. It would require someone probably reverting commits to identify when it worked and when it was broken, and doing runtime testing to isolate the cause.

It doesn't really bother me, but I have also noticed it. I don't use midnight commander, so don't care about that. But I have noticed it in htop.

RPi4 2GB has been adequate for my needs, all of my MC devices are 2GB. 4GB for $10 more gives you a lot more headroom, if you're on the fence then I would spend the extra money.

But even at 2GB, Kodi sits under 1GB (usually around 800MB with a very large buffer cache tunable). A fresh start up of Kodi is less than 350MB of RAM used, but things go up as icons are cached, and then the playback buffers add in as you play content.

I do occasionally playback 4K HDR movies, no issues, but most content I have is 1080p. I don't use SSDs, all of my media is on my NAS. I just boot from an SD card.

Now that I am re-reading, I seem to have missed the question, it's not about using it as a MC device, but as a NAS. I have no experience with that, but I can't imagine it being great, really depends on how demanding the clients are.

By the way, what I would suggest is looking at the RPi5, and maybe check out some of the performance reviews / NAS testing from folks like Jeff Geerling. RPi4, in my opinion is very much built to a price point, and some of that sacrifice is I/O bandwidth. RPi5 specifically has a custom chip to address this shortcoming, and adds a lot more bandwidth to USB3.0 and even a PCIe bus for NVMe's.

Quote from frankvw

Aha. I hadn't realized that yet (I've been out of the picture for a while.) I now see reports of iwd issues on the RPi4 as early as 2019, then on Raspbian Buster. Unfortunately I can't see this being a big, high priority issue..

That's probably folks that chose to use iwd on Raspberry Pi OS. That's the nice thing about Debian, you can try all kinds of alternatives from the standard installation. As far as I know Raspberry Pi didn't switch the default supplicant, even a fresh install of bookworm appears to still use wpa_supplicant:

$ ps fuxwa |grep wpa

root 542 0.0 0.1 17148 10628 ? Ss Oct20 0:14 /sbin/wpa_supplicant -u -s -O DIR=/run/wpa_supplicant GROUP=netdev

iwd is the new thing (I think it started somewhere around 2017 or 2018), and probably around 2019 is when it became compelling as a replacement for wpa_supplicant.

One other thought is perhaps trying a USB dongle. I don't know which ones are recommended for LE11, as I compile my own with rtw88 drivers backported from the mainline kernel. It might indicate if the common thread is the broadcom drivers, I don't know if anyone has collected reports and correlated the common thread here. I know Ethernet is what is recommended, and perhaps a lot of folks follow that as Wi Fi is a pain in the butt.

Quote from frankvw

It's a catch-22: reproducing the problem will prevent access to logfiles at that time, and restoring network and logfile access will make the symptom (and the log files?) go away.

The log files are not going to be useful; they will indicate what you already know, and others have posted them already. If you want to know more then you need to re-compile the kernel with mac80211 & MLME debug on, turn on persistent logs, and reproduce the problem.

Quote from frankvw

this needs to be kicked upstairs to the developers of these modules; the LE developers can't be expected to resolve this.

The iwd mailing list is the place for that, LE developers would do that if they could reproduce it, but it seems based on prior threads that they can't reproduce it. It seems to me that you would have to bring that up on the mailing list, since no one can proxy for you without being able to reproduce the problem.

The difference between Raspberry Pi OS & Leia is iwd, both of them historically were using wpa_supplicant. As soon as LE (in 10) switched to iwd that's when these reports started rolling in. iwd does work great here with rtw88 devices & openwrt AP, so what that unique difference is unknown.

Quote from birdr

These are some of the logs that frakkin64 mentioned.

Looks like your probably using the built-in wifi? It doesn't indicate beacon loss, unfortunately. But noticed you did have some tx failed, which to me would suggest signal problems.

It's possible that invalid key is triggered off of response time, perhaps the authentication packet is sent out, it doesn't get a response within X time and that is considered an invalid key. I don't know if that's how it works, but it would possibly explain why it works sometimes or when it is closer.