Posts by jim_p

    Another day, another new weird thing comes up. As usual, the rpi did not connect wirelessly on first boot, so I went wired to do today's update.

    First, it stopped at like 95% of the download, so I had to cancel it with ctrl+c and continue it with wget's -c parameter and it completed it after a few seconds. This was happening at the start due to poor wireless signal, but why did it happen on wired connection too?

    Second, I did the usual connman procedure of connecting it wirelessly, but connman returned no propmt for the key this time, so I thought it connected successfully. But it did not, according to iwconfig and ifconfig, so I tried again and this time I got this new output of the connection being in progress

    Code
    connmanctl> connect wifi_bxxx_4xxx_managed_psk
    Error /net/connman/service/wifi_bxxx_4xxx_managed_psk: In progress

    I retried again after like 1 minute but it showed the same, so I let it continue for a couple of minutes, did the procedure again and I was prompted for the key like usual.

    Third, once the update was downloaded (and after checking its sum with the same file downloaded on my pc), I issued a reboot. Unlike previous versions where the connection was terminated instantly (especially via ethernet), le 11 takes some to disconnect and putty to report that the connection was terminated. After like 1 minute, putty was still on and returned to the prompt so as to run another command. I then ran dmesg, which showed the usual cec errors that come up when it is not connected to the tv, but nothing more related to the filesystem.

    Then I decided to run htop to check if some other process is delaying it, and it said "sh: htop: access denied" (or something like that). Its green led was permanently on, not blinking, so I hesitated to pull the plug. But I pulled the ethernet cable and after like 30 seconds, I finally saw the green led come of and back on again.

    Long story short, it booted to the new nightly, I sshed to it, checked dmesg again for filesystem issues, but still no luck. I ran connman again, reconnected to the wireless (it did not ask for the key this time), rebooted, and luckily wireless was active again after the reboot.

    That change was done only 1 month ago. 1 month ago I wasn't even using the nightly on the rpi, let alone on x64.

    And the issue with that message has appeared very recenty, like 3-4 nighlies ago. Did something else change recently, e.g. the kernel maybe? I am sad, because 11 fixed the framedrops issue that 10 has but introduced that wifi issue. Anyway, I will keep looking.

    There you go.

    Back to the rpi with a new error in connman. As usual, 1st boot of the day, it does not connect wirelessly so I connect the cable, ssh to it to launch connman to see what is going on. First try returned no prompts to enter the key or anything

    Code
    connmanctl> connect wifi_bxxx_4xxx_managed_psk
    connmanctl> exit

    I waited a bit, checked ifconfig, checked iwconfig and it had not connected yet. Back to connman for another try and I get this progress error for the first time ever

    Code
    connmanctl> connect wifi_bxxx_4xxx_managed_psk
    Error /net/connman/service/wifi_bxxx_4xxx_managed_psk: In progress
    connmanctl> exit

    I waited a bit more, checked ifconfig again, checked iwconfig again and still nothing. So I tried again and this time it popped the usual "the network exists and has this key" prompt

    Code
    connmanctl> connect wifi_bxxx_4xxx_managed_psk
    Agent RequestInput wifi_bxxx_4xxx_managed_psk
    Passphrase = [ Type=psk, Requirement=mandatory ]
    PreviousPassphrase = [ Type=psk, Requirement=informational, Value=mywifikey ]
    Passphrase? mywifikey
    connmanctl> exit

    And it finally connected!

    What type of magic do I have to do so as to add test.libreelec.tv (or any of its subdirectories) as a source in kodi's file manager? I add it like in the picture, but when I access it, it is completely empty.

    (screenshot is from my pc running kodi 19.4 on debian testing/unstable x64, but you get the idea)

    But I told you in another thread: don't use the script anymore

    Well, I had to test its complete functionality, even for once!

    As for /etc/issue, it shows exactly what you see in the motd when you log in via ssh, e.g.

    Code
    ##############################################
    #                 LibreELEC                  #
    #            https://libreelec.tv            #
    ##############################################
    
    
    LibreELEC (community): nightly-20220612-363112b (RPi2.arm)

    The text in the parentheses is the only thing that mentions the architecture. On x64 it says "generic.x86_64".

    I know that about dmesg. Wouldn't the kernel find a wireless interface at boot and name it wlan, like I mentiona above? Why is it not in dmesg then? I will keep searching, athough I do not know how much longer I can keep that installation.

    Also, I noticed that wl is used for it, like in le 10 and 9. How can I blacklist it and test b43 that also supports it?

    In other news, one thing I managed to test on x64 le 11 was video playback on my old laptop. One of the reasons I have not yet moved to le 10 there is because I get frame drops on every video (file or stream), regardless of resolution.

    The stream/file plays fine, the cpu usage is at normal levels, but the motion is not as smooth as in le 9. It seems as if it skips some frames and it happens even on low resolutions like 360p. So, I discovered that it does not happen on le 11 and I am pleased :)

    ---edit

    Well, this happened on the first boot of today's nightly. It is on dmesg and it seems serious.

    Code
    [  206.501651] netdevice: wlan0: Incorrect netdev->dev_addr

    ---reedit

    I just found the way to blacklist a module.
    https://wiki.libreelec.tv/how-to/blacklist-kernel-module

    But there is no b43!

    Code
    # modinfo b43
    modinfo: ERROR: Module b43 not found.

    you can crossgrade between generic and generic-legacy without any problem, if you are unsure what you want to use then go for "generic"

    Are you sure about that? Yesterday I upgraded from generic to generic-legacy with no issues. And I tried to do the same today, but the other way round (generic-legacy to generic) and an error came up at boot saying something about a file named ".nocompat". It did not upgrade and it still is on yesterday's nightly.

    Sorry for complaining about the 0 byte files. I totally missed if's -s parameter when reading the script. I read the new version quickly and I sshed to the rpi to test it. And it somehow fails, probably because of something on wget

    The file is on the server, it is not 0 bytes and I have changed hardware and arch as described in lines 37 to 39. Also, the -vx parameter of sh seems to just output the contents of the script in the terminal, just like cat.

    Sure, I am willing to try any suggestions. I also searched for a way to make it somehow return the board type, i.e. rpi2 in my case, but sadly I found none. The file /etc/issue seems to be the only one containing it in text.

    ---edit

    I did not notice the quoted text (rough day today, sorry). So, if the script does check for 0 byte files, please ignore my last suggestion.

    So, I wanted to try on my rpi3b+ nightly installation (rpi2 variation of the image), but because the rpi folder (= what I am supposed to change on line 5 for arch) has 2 different images for rpi2 and rp4, I checked what the cut command actually does on line 19. And it returns the image for rpi4, which is wrong

    Code
    # wget https://test.libreelec.tv/11.0/RPi/
    Connecting to test.libreelec.tv (164.92.230.217:443)
    saving to 'index.html'
    index.html           100% |********************************|  4475  0:00:00 ETA
    'index.html' saved
    
    # cat index.html | cut -d " " -f2 | sed -e 's/href=//'g | sed -e 's/"//'g | grep nightly | sort -r | head -1
    LibreELEC-RPi4.arm-11.0-nightly-20220609-c66e09a.img.gz

    In other folders, e.g. in the rockchip one where there are like 10 different variations, things are worse. But on folders that there is one, e.g. the generic or the samsung one, it works as it should.

    ---edit

    Also, now that the build system sometimes creates 0 byte images, there should be a "fail safe" that e.g. deletes the downloaded file when it is 0 bytes.