Posts by jim_p

  • Update URL/channel for nightly builds

    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)

  • shell script to get the latest nightly (old)

    Quote from JoeAverage

    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".

  • Adding boot parameters to the rpi (and any arm build probably)

    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.

  • Update URL/channel for nightly builds

    Quote from CvH

    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.

  • shell script to get the latest nightly (old)

    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.

  • shell script to get the latest nightly (old)

    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.

  • shell script to get the latest nightly (old)

    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.

  • Adding boot parameters to the rpi (and any arm build probably)

    Ok then, I am waiting for the other rpi to come.

    In other news, wifi could not connect earlier, so I connected the cable and I retried it with connman. But this time, connman mentioned that it had the key stored and it showed its right value

    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?

  • Adding boot parameters to the rpi (and any arm build probably)

    Fresh pastekodi from the rpi. I waited for like 5 minutes for it to connect to the wifi, it didn't, so I plugged the cable, sshed to it and connected to the wifi via connman again. This time though connman asked for the wifi key, although it was already stored. And I did not remove .cache/connman/wifi_whatever beforehand!

    http://ix.io/3Ziu

    The service wait-time-sync.service topped the systemd-analyze blame board with a massive 5 minutes and 30 seconds, much higher than the 10 seconds delay of kodi-waitonnetwork.service which was second. It is more than obvious that le was waiting for a network connection here.

  • Adding boot parameters to the rpi (and any arm build probably)

    Time for the x64 nightly installation to shine :D

    After 2^n reboots and 2^n-1 flicks of the wifi switch (yes, the laptop is so old that it has such a hardware switch), it finally showed the wireless networks. As for the wifi signal, you are right about its calculation. It show as ~10% weaker than on le 9 and 10.

    At the first try to connect, it failed and complained about the key being wrong, while it wasn't. At the second try it was accepted with no issues and connected to my wifi. Instead of installing confluence and greek, I had the idea of upgrading to the latest nightly and after it rebooted it showed no connections again. Right now, 2-3 reboots later, there are still no connections listed in libreelec settings and there is no wlan0 in ifconfig :(

    Also, kodi-send --action=InstallAddon does not work, neither locally (run via ssh) nor remotely (run from my pc with the --host= parameter). I have already enabled remote control from applications on this system and from other systems.

  • Adding boot parameters to the rpi (and any arm build probably)

    Why does pastekodi return "no results to fetch" and sometimes it just gets me back to the prompt without this message or the paste url? I just run it 5 times before it returned the url eventually.

    There you go though. It failed to connect wirelessly, so I connected the cable and sshed to it. I will do the upgrade to the new nightly now.

    http://ix.io/3ZgE

    ---edit

    And it just connected automatically on the first boot with 20220603-98b9aa2. What if the wifi takes longer to connect and I am just too impatient to wait? However, I think 1 minute is enough time for it to boot and connect, given the fact that it also has to wait for network connection right before kodi starts. Right now, wait-time-sync.service and kodi-waitonnetwork.service top the board of systemd-analyse blame with 32 and 10 seconds of delay respectively, while the remaining services each have a delay of 3 seconds at most.