Posts by quickstang

Quote from kszaq

Can you guys check this older firmware that I mentioned earlier? It's quite easy to do but please make sure that you are able to connect to your RPi over ethernet in case this firmware does not work at all!

First, run the nightly with working WiFi, connect over SSH and execute this:

Code

mkdir -p /storage/.config/firmware/cypress
wget https://github.com/RPi-Distro/firmware-nonfree/raw/ad23f33a29fb7f8bc344d80d0eb40abe1953d145/debian/config/brcm80211/cypress/cyfmac43455-sdio-standard.bin -O /storage/.config/firmware/cypress/cyfmac43455-sdio.bin

Reboot. Check WiFi. If working, update to latest nightly and check WiFi. Please report your result.

In case this firmware breaks WiFi even on older builds, delete it:

Code

rm /storage/.config/firmware/cypress/cyfmac43455-sdio.bin

I haven't ever SSH'd into the Pi unfortunately. I do have Putty on the windows laptop, and tried logging in with the instructions here from the documentation...but no luck yet getting into the Pi to be able to test this. Maybe with some extra guidance I could make it happen.

Open a terminal window on your computer and enter the following command, replacing the <ip address> placeholder with the IP address of the Raspberry Pi you’re trying to connect to and <username> with your username:

$ ssh <username>@<ip address>

When the connection works, you will see a security warning. Type yes to continue. You will only see this warning the first time you connect.

Enter your account password when prompted.

You should now see the Raspberry Pi command prompt:

<username>@<hostname> ~ $

You are now connected to the Raspberry Pi remotely, and can execute commands.

Quote from Wolfpig

As i still have no idea what it is, and as i probably cant change that by myself.....

BTW: As i looked today a bit further

a) the working nightly is connecting correctly with WPA2 (not really a surprise if it does not support wpa3)

b) the non working nightly only sets the Wireless state to ready, it does neither receive the internal ip from the router and does not see the router as the DNS source (the field there is kept blank, which probably also the reason why it sets the connection state or what it was to auto instead dhcp)

c) manually setting the ip, dns etc. makes no difference

As i have no real problems with the running nightly, i will keep that for a bit and see if that problem might get squished out in the near future.

Would i need to report that as a possible bug somewhere?

Display More

I think I will probably do the same. Just keep the current 20th build which I know still works, and wait to see if this gets fixed in the future.

Quote from kszaq

To me it looks like iwd is trying to offload SAE but the firmware only supports doing this with wpa_supplicant, iwd fails to authenticate and does not fallback to WPA2.

Edit: These 2 threads seem to confirm that WPA3 does not work with iwd (yet):
https://github.com/raspberrypi/linux/issues/4718
https://github.com/raspberrypi/linux/issues/6130

So basically, if our whole network has WPA3 settings on (my whole eero network does), until there is a fix we won't have any network settings correct?

So this is the issue and nothing related to IPv6?

Quote from Wolfpig

If it changes from one Libreelc build to the other, making it completely unusable that still would be a not intended behavior.

Log created with the gbm shell on the latest nightly build (2024-11-03) (as no network is available)

External Content pastebin.com

Content embedded from external sources will not be displayed without your consent.

Display all external content

Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

Comparison log from the fully working nightly build 2024-10-20

https://paste.libreelec.tv/allowed-gorilla.log

BTW: What i noticed right now while testing, other that it takes the not working build 2-3 times so long to get a connection (even if it still wont believe that a network connection exists), the connection type stays on auto on the non working builds, while it is set (correctly?) to dhcp on the older working build.

Forgot to check if the fixed IP Adress i set in my router for my pi is used on the failure, or of it is using some other random one

Display More

My network also shows State: ready, and Type: auto under connection settings along with IP address.

I do have IPv6 set to on for my eero router as seen in the picture. It has always been on and again, no issues with any nightly up until that IPv6 change it appears.

kszaq I myself personally do not have firewall set to on for the Pi under the network settings.

Quote from chewitt

If there's an issue it seems to be localised to your environment. I'm running a (self-built) nightly image on an RPi5 without any network issues and lots of other people run nightlies too; enough to flag-up any general networking issues. NB: The kernel changes in question will be irrelevant unless your home network is IPv6 based?

I'd start with a clean LE13 nightly image on a spare SD card. Any different?

Yes, the network does have IPv6 on.

Tested a clean build of the latest nightly and there were no network settings there just like the pictures in my first post.

If this network issue is still happening, even with Nov 1 nightly, is it going to take the below reverted or is there another option to get my network settings visible again, other than staying on the Oct 20th nightly.

linux: enable CONFIG_IPV6_MULTIPLE_TABLES · LibreELEC/LibreELEC.tv@d3fe5bf

Allows setting up multiple IPv6 routing tables when using VPN.

github.com

linux: enable CONFIG_IPV6_MULTIPLE_TABLES

Browse files

Allows setting up multiple IPv6 routing tables when using VPN.

Quote from heitbaum

Here is the log between those 2 versions

https://github.com/LibreELEC/Libr…869d0...56c531c

This is the only patch (that may be of issue) - https://github.com/LibreELEC/Libr…59e13377e8b3dc5

This could be it. I just tested the newest nightly LibreELEC-RPi5.aarch64-13.0-nightly-20241029-81a82b6.img.gz

and I still have the same issue. 0 network settings. Reverted back to the 20th with no network issues, and all values are there.

Quote from MatteN

Same thing happened on one of my Pi4 with latest LE13 nightly, turned off /on both wi-fi and ethernet a couple of times and it suddenly started to work again.

I just reverted back to LibreELEC-RPi5.aarch64-13.0-nightly-20241020-ce869d0 and it works fine again. I had to load this from a USB to the update folder, but it appears there is something happening from this build to the current ones. I don't see anything in the log, so not sure.

I had been running the latest 13.0 nightlies on my Pi5, with 0 issues until LibreELEC-RPi5.aarch64-13.0-nightly-20241021-56c531c

Booted, and all of the sudden my network was gone. I can see my internet on, and no issues with any other devices in the house. I decided to look at the system info section and go to my network and noticed everything was blank. There is a primary and secondary DNS, I just didn't show it.

I tried a fresh install of LibreELEC-RPi5.aarch64-13.0-nightly-20241025-9f8eeb6 this morning, and same issue. Nothing is there under system info and network. However WiFi is connected though.

I also rebooted my whole network just to test that, and that didn't work either.

Thoughts?

Thanks!

So I disabled CEC this morning and had the pi on the addons screen. I let it idle (have a screensaver set) and about 1.5hrs later give or take 15 or 20 min it rebooted. So I will need to get a log. I was running the latest nightly.

Quote from petediscrete

I’d say a good starting point would be to provide full logs for your system.

If the CEC settings don’t work, I will get full logs.

Quote from VLouis

Hi,

A good starting point could be to take a look at the CEC settings:

Settings -> System -> Input -> Peripherals -> CEC Adapter.

It's a posibility your RPi have random reboots, and thru HDMI-CEC to "grab" the TV input when the LE starting.

If you don't use the CEC (control the Kodi with the TV remote), better to disable it completelly.

Another thing is why your RPi have random reboots (if have it...)...

Display More

I will take a look at the settings. I don’t think it has random reboots, but if the settings don’t fix it, I will get a log to see if there are reboots.

No, I don’t control it with a remote. All I use is a keyboard once it’s on. Shutdown with power option, then turn off the pi with button on power cable.

I'm running LE12 nightlies, and noticed a weird behavior I haven't really seen before, and I am not sure when it started happening.

I will have my Pi4 on, just idling on the main page when it boots. I will play around with the Pi4 and then decide I want to come back to it later. I switch inputs on my TV to watch YouTube TV or something on my Roku. I will be watching something, and then all of a sudden (no specified amount of time when this happens) my pi will just automatically switch inputs back to the input it's on. At first I thought maybe I was sitting on my remote, or one of my kids was accidentally hitting a button on the keyboard, but that wasn't it. It just randomly switched. I was watching a football game, and then bam, the TV said input 3 and there was the Kodi screen. Also had this while watching a show on Paramount+. I Was watching a TV show and then about an hour in our two, the the pi went to input 3.

The other behavior I hadn't seen until last night was that after I got done with Monday night football on the Roku, I powered the TV off with the Roku remote, set it down, started putting things away, and before I got to powering off the pi from the power button on the cord, the TV turned on and was on input 3 with the main Kodi screen. It was like the pi automatically turned my TV back on.

I don't know if anyone else has seen these two behaviors, but I have no idea when and why it started. The first is kind of annoying when you're watching TV and then your pi decides to cut your show off and then switch inputs automatically. I don't know if there is a display setting, but I have no idea how to fix it.

Any help would be appreciated.

I just suddenly started having issues using VPN Manager for OpenVPN on mine as well. My issue just started yesterday. Booted libreelec, VPN manager tried to authenticate through Nord, but then it tells me "Could not authenticate with VPN provider. Please check user name and password and try again." I'm not sure where the issue is yet, because this happens on 11.0 and 12.0 nightlies. It was fine on both of those Friday/Saturday.

I know it isn't my username and password, because I as well am logged on through my laptop. I've changed 0 settings in the app in Kodi for both 11.0 and 12.0. I also tried to update the add-on, but there are no updates. I'm using the add-on from Zomboided which is 7.0.1.

It just randomly stopped working. I'll test it later today. Unfortunately I don't have another VPN provider to try with to see if it's a Nord issue or not.

I noticed LE11 nightlies haven't been updated for the Pi since the 15th. Has this been transitioned to LE12 now? Those show the newest build of 3/19. However those are aarch64.

Thanks!

Thanks for the code. I happened to come across that code in a qnap forum, but I have never used Putty or SSH, so I am trying to figure out how to do that first and if I am typing the above exactly or what. I tried another option of trying to find it through Total Commander as someone else said they were able to do, but no luck. I have disabled the appropriate stuff in Qfinder, so no new stuff is generated, but getting rid of the current stuff is my issue. I am a newbie with SSH.

One thing I don't understand is I have never had this issue until about a week ago, so I have no idea what caused it to just start happening.

I did try the code above as seen in the following Putty. I've SSH'd into my NAS then copied the code. I have no idea if it took or not because again I'm new to SSH and am not sure what tells me if the command worked or didn't work. It does say no such file or directory, but I did read that may be normal and perfectly fine.

I also tried this command I found as well.

rm -rf /share/Qmultimedia/*/.@__thumb
rm -rf /share/Qmultimedia/*/*/.@__thumb
rm -rf /share/Qmultimedia/*/*/*/.@__thumb
rm -rf /share/Qmultimedia/*/*/*/*/.@__thumb
rm -rf /share/Qmultimedia/*/*/*/*/*/.@__thumb

Again, pasted it into Putty, hit enter and again no idea if it took or not as it doesn't say anything.

I do still see the @__thumb folder under file manager in Kodi, so both commands probably didn't work.

If I can't figure out this SSH stuff I may try to just create a new folder in my NAS like "Multimedia Stuff" then copy everything over to that folder, delete "Multimedia" and then re-scan. Would be much more time consuming, but I am having no luck with this @__thumb nonsense that's already there.

Yep, QNAP TS-212 NAS. I'll try and search again. I tried searching .@__thumbs a few times and came up with nothing, but I'll try some variations. It's driving me nuts. I have like 90 files in one TV section. At one point it was creating a thumbnail for every movie but was just creating this so called "tom thumb" thumbnail in my movies section and I had no idea what the files were until manually deleting them. And they had the same file layout as above.

Looked like this...

I was wondering if anyone has seen this issue before as I am not sure why it started or how. When I scan my NAS on startup and Kodi looks for shows, it ends up adding multiple .@__thumb files in the Movies and or TV section of random shows/movies. So then it looks like I have 6 of the same file because it creates 5 more, when in reality I only have one. When it does this with TV shows, I have no idea which one the real file is until I select each one and wait for it to play. When it doesn't play, I delete that file.

I think it is coming from this .@__thumb folder as seen on the file manager picture of my NAS, but when I actually look on the actual NAS, that folder doesn't exist. I even have show hidden folders selected on my NAS.

I think I can solve this somehow by getting rid of that folder, but I can't seem to find it.

If you look at my NAS screenshot, you can see there is no .@__thumb folder. But if you look at the screenshot of the file manager picture, it's there.

When I actually delete the files from Kodi, they look like this...

nfs://http://192.xxx.x.xx/Multimedia/TV/(name of show)/.@__thumb/s800episodename.mkv

nfs://http://192.xxx.x.xx/Multimedia/TV/(name of show)/.@__thumb/s100episodename.mkv

nfs://http://192.xxx.x.xx/Multimedia/TV/(name of show)/.@__thumb/defaultepisodename.mkv

nfs://http://192.xxx.x.xx/share/MD0_DATA/Multimedia/TV/(name of show)/.@__thumb/s800episodename.mkv

nfs://http://192.xxx.x.xx/share/MD0_DATA/Multimedia/TV/(name of show)/.@__thumb/s100episodename.mkv

So I get 5 of these files along with the 1 real file because it's an .mkv extension. I'll then manually delete each one above when I find the real one. I just don't know why it's creating those and how to solve it. I was thinking scraper issue, but since there's a folder, that might not be the issue. Well, except that the scraper is seeing that folder and creating those files that don't exist.

I was going to do a fresh install since it does this every time I scan, but before I did, I wanted to see if anyone had any thoughts, and hopefully the above makes some sense. I am running LE 11 Nightlies.

Quote from the_third_pi

I just updated to the most recent build (Jan 28) on my RPi400 and can confirm that wifi doesn't work.

At startup I saw failed to start iwd.service. Ethernet works as expected. This was working on the last nightly I was using from Jan 20 and also the one I tested from Jan 26. This is probably unrelated to the problem above, sorry.

log shows

Code

Dec 20 11:15:46.554163 Pi systemd[1]: iwd.service: Main process exited, code=killed, status=6/ABRT
Dec 20 11:15:46.554634 Pi systemd[1]: iwd.service: Failed with result 'signal'.

Probably related to https://github.com/LibreELEC/LibreELEC.tv/pull/7420

Same here. Just updated to nightly Jan 28 and I also get the iwd.service error. My connections screen is also blank. I can also confirm that the 26th build had no issues.