Posts by frakkin64

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.

Other thing to look at, since it sounds like it is related to a signal problem, is your beacon loss counter on the client:

iw wlan0 station dump

beacon loss: 11

This one ^ was the pain in my ass, beacon loss 11 is actually great for this device (it was hundreds in a few hours with frequent disconnects), and iwd is pretty useless at giving you a clue what is wrong. You usually have to compile a separate kernel with debug turned on and turn on MLME debug to get a clue what's wrong. For me it turned out be beacon loss/timeout (but iwd reports everything as error 4, which is the AP disconnected). I ended up bumping the probe timeout to a pretty gross number of 2 seconds (normally it's 100ms), which seems to have helped. I probably ultimately need another AP to have full coverage, but it is working, and I still have those illusions of running ethernet in the house.

Other devices closer to the AP generally have no beacon losses.

I haven't had any issues with Ethernet, only with that atf change

Sometimes taking a picture with your phone makes it easier to inspect solder joints. I can't see anything anymore with the naked eye, especially tiny fine pitched QFPs. I have watched quite a few repair videos where people find a few legs not even soldered down on QFPs, just floating and making contact. It's probably when the legs are slightly bent by handling or the feeder reel on the placement machine. QFPs are definitely susceptible to that sort of leg bending.

And from experience working for a cellular manufacturer when there are part shortages, you get pretty desperate and start salvaging these parts from returns/defects and you run them through a reforming machine. The fall-out on salvaged QFPs is pretty horrendous, but they do it anyways. It seems pretty crazy to me, considering you just pulled it off a board to put it on another board for it to fail again. But they definitely do it.

The latest nightlies (10/13) should include the fix.

Quote from jernej

Recently we spoke about many issues in clock driver. Guess what, I found one. HDMI clock isn't set correctly. That's why I have troubles with some displays, in this case LG TV. It seems that monitors are more forgiving, but fps would suffer.

Ha, yeah multisync monitors are crazy nowadays in what they support. I am using an older LG TV as well with the Allwinner device, but it's a pretty old TV (1080p, pre-SmartTV), it won't give up the ghost yet -- I'm also just running it at 60Hz because I keep forgetting to turn on adjust refresh rates and whitelist modes.

Quote from jernej

Great, I'll submit it as a fix, not only to LE, but in mainline Linux in general. If you don't mind, I would submit it with your "Reported-by:" and "Tested-by:" tags (you can give them to me via PM, but in the end, they will be publicly visible in commit message).

Sent via PM.

Quote from jernej

P.S. I make a few more improvements in nightly LE12 images. Network related patch is reverted and there is also a bugfix for ocassional DRAM init issue and possible HEVC decoding issue. On top of that, there is full 10-bit display pipeline support and GPU DVFS.

I saw those commits, planning to re-build and run with that next week. I may have seen the DRAM init issue, if that is the one that causes the device not to boot, it always happens a while after I have disconnected the serial console. But this is honestly a nice little device, and it's a real bargain with an eMMC.