Posts by jim_p

    Yes, I was not running 0.08 on the screenshots above, but 0.07. I said I was waiting for a new set of nightly builds so as to test 0.07 because I thought its bug on generic-legacy was fixed. It was not, so I upgraded to 0.08 once the forementioned upgrade was done.

    First upgrade with 0.08 on generic-legacy was successful. Sadly, it is the end of the x64 nightlies for me today because I am tired of testing something that has iffy behavior on my hardware's wifi. I may check again when 11 reaches alpha or beta, but right now all I want to do is to open a bug report on kodi (bug that appears in 18, 19 and 20) and delete the whole thing.

    This is libreelec settings, it has nothing to do with kodi settings. Choose another submenu from the settings, e.g. interface, or wait for someone that uses the estuary skin to guide you further.

    I do not use it because I absolutely hate tile-styled interfaces, so I can't help you more.

    You were right about 0.07 and generic-legacy. Screenshots are from the x64 and the rpi3 installations. I updated them to 0.08 and I am waiting for tomorrow.

    As for the mediafire link. Wget-ing it results in an html file. I named it "whatever" because the redirections that wget has to go through add my public ip to it

    Having said that, I offer to add it as a gist and I (promise that I) will keep updating with every new release that you make.
    It leads to the raw text version of the gist, so one can use it with wget directly.

    Code
    https://gist.githubusercontent.com/pitsi/121409e48df9529feb6e8b18bd8aa303/raw/11f1bb1502e2e5506e124ef8338432ec1b82b4e8/get_nightly.sh

    ---edit

    I can now confirm that v0.08 works properly on generic-legacy. I just noticed a new image was uploaded earlier today, so I made the upgrade via the script.

    Le is running from the nand.

    I also learned that they occasionally use an old usb stick and that the tvbox always is connected to the power plug, so is turned on via its remote. So I asked the family to completely disconnect it from the power supply, wait a bit and then reconnect it. And it stayed on the mxq logo for less than 20 seconds.

    I also noticed that, yesterday, systemd-analyze blame has kodi.service top the board with like 45-50 sec to start, way more than the wait-time-sync.service which comes second at ~10. Kodi itself though is available and operational in less time than that.

    Yes, when I wrote msg 46 both installations had v0.06 of it. And yes, I am also confused about why it happens only on the generic-legacy.

    I am now upgrading them to v0.07 of the script, but due to the lack of new images (both of them are on 20220627-f7f28a7), I will post any new findings tomorrow.

    A difficult day started for the rpi. After 2 days of wirelessly connecting with no issues, I had to go wired today for the upgrade.

    I started downloading the 20220627 nightly and minimised putty's window. On my tiny 12Mbps connection, it takes ~100 seconds to download the ~1`20MB image for the rpi, so I let it run. I checked it again a few minutes later and it had frozen at ~50% of the way!

    I closed that connection, I sshed to it again from a new instance of putty, killed wget, for which I have no idea why was it still running, deleted the existing file just in case, downloaded the file again and rebooted when it was done.

    When the rpi boots, I usually wait for the green light to stop blinking before connecting via ssh, but this time it was lit up for 5+ (if not 10+) minutes straight, with no or minimal blinking! I sshed to it to run htop or something, but it came up again with the access denied error (like I said in message 53). Instead of unplugging the ethernet cable like last time, I decided to schedule a shutdown in the next 15-20 minutes with "shutdown -P 8:30".

    The green light turned off ~1 minute after I gave the command and at that time the system already at least 10+ minutes of uptime according to uptime (and uptime -s).

    I checked dmesg for anything weird, like ext4 corruption, but the only notable thing was that message about cec timeout. I then powered it off. I then started it again (cold boot) and tried to finally connect to the wireless via connman, but I got this... new behavior on the first try

    Code
    Agent ReportError wifi_bxxx_4xxx_managed_psk
    invalid-key
    Error /net/connman/service/wifi_bxxx_4xxx_managed_psk: Input/output error
    Agent request cancelled by ConnMan

    but it connected as usual on the second try, asking for the key again (as usual).

    Yes I am on v0.06 from 23.06.2022

    As for the script part, compare all those steps above with something like that

    Code
    rm get_nightly.sh
    wget https://gist.githubusercontent.com/pitsi/e1a47f4b9c8d0176e2c2b8fa2f8fa1da/raw/67d0a404b7b4beeafde457b10b3354b2686eca30/apt.conf -O get_nightly.sh
    chmod +x get_nighly.sh

    My gist above is for debian's apt (file /etc/apt/apt.conf), but you get the idea. Also, I use nano because I am not comfortable with vi.

    And today, besides the above message that the new image is under downgrade, I am getting a low space message

    Code
    NOT enough disk space to proceed.
    I need roughly echo 1092 MB of free disk space !

    I have backed up the image of 20220625 for another reason, but the free space I have is enough for it to download

    Code
    # df -h
    Filesystem                Size      Used Available Use% Mounted on
    ...
    /dev/sda2                 1.3G    382.7M    954.1M  29% /storage
    ...

    Its an old 2gb usb stick. I am now moving the foremention image to my pc so that the script runs properly even with the downgrade option.

    ---edit

    I forgot to mention that the upgrade and downgrade options appear properly on the rpi.