Posts by JoeAverage

    noggin, thanks for suggestions


    I've been running (correct engl. ?) satip-axe before the last Org.-FW were out.

    at that time satip-axe saved more power then the original FW.

    AFAIK, this isn't the case anymore.


    I do not have special need for LNB customisation.

    thanks anyway !

    CvH

    chewitt


    I'm trying to adjust my script for the coming new server structure:

    https://test3.libreelec.tv/11.0/Generic/


    I now want to avoide some shortages/mistakes [*] of my old script, where I were unable to exactly get what's an update/downgrade.


    so the new script version should work with the field "mtime" (see attached file, it's pre-filtered output from command: curl -s https://test3.libreelec.tv/json/11.0/Generic/)


    to be able to compare the mtime fields I need to convert the date/time string to a form allowing to do integer comparison


    this should be the target format : 202207020834. (CCYYMMDDHHMM)


    my first draft is

    - to create a temporary list of only the mtime strings

    - read the list and convert the mtime string to the above target format

    - do the comparsions

    - notice the next nightly what is elder/newer then the running one

    - (unsure) convert back to the mtime string and grep that mtime string in the list ...

    - download the found nightly and it's sha256 (unsure if needed, cause -AFAIK- the update installer does already a check summing)

    ...


    the problem now are:

    a) read the above temporary file containing the mtime strings for conversion *without* stumbling over blanks the strings contain

    my attempt to fix: set IFS="

    or as I now see via CvH suggestion


    b) doing so I 'll up to now get a additional date, cause -my guess - bash read commands from the right to left, so I get one more date (the current date) then mtime strings are in file

    How to avoid that ???


    [*]

    the "build date-git hash", form 20220623-a81b6d9 doesn't in all cases allow to figure the correct nightly for update/downgrade.

    thinks of builds with same date and different git hash, e.g. builds from 5:00 and 19:00


    converted mtime string seems the way to go and saves me a lot of logical brainer's to get it better as in my current script V0.08


    ===

    other question:

    is there a way to do an inline conversations during an output of awk ?


    let say, I've a file named out-von-JSON containing this:

    { "name":"LibreELEC-Generic.x86_64-11.0-nightly-20220628-f7f28a7.img.gz", "type":"file", "mtime":"Tue, 28 Jun 2022 18:07:28 GMT", "size":221226619 },


    to get the mtime string field I would do the following:

    cat out-von-JSON|grep -v sha256 | grep -v Generic.x|awk -F '"mtime":' '{print $2}'|cut -d '"' -f2


    => Tue, 28 Jun 2022 18:07:28 GMT


    Am I able to do inline conversation for the awk part '{print $2}' ?

    - it's 30 years ago I learned Unix -

    hallo


    I've the following problem while bash scripting (my nightly download script)


    I need for an date comparison to convert a file of dates.

    initial date format is "Sun, 03 Jul 2022 02:35:26 GMT" and should be converted to format: 202207030435.


    let say the file is named "dates"

    the following for loop doesn't work cause of the blanks in each line:


    for i in $(cat dates); do date -d $i '+%Y%m%d%H%M'; done.


    How to read the file line by line without stumbling over the blanks in the lines.

    trying to put ' or " in front and at the end of each line doesn't work out ...

    jim_p please keep an eye on the first page in this thread, cause I've found a bug during testing yesterday: esp. when nightlies with same build date, but different build hours, hit the download server a mismatch of what is a update/downgrade could occur.


    currently rewriting the script and testing V0.10 ...

    thanks ghtester for promotion :thumbup:


    I would wait for script version V0.09, cause in V0.08 is still a bug regarding the mismatch what is an update/downgrade.

    esp. when 2 nightlies hit the download server on the same day e.g. at 5:00 and 23:00

    currently the script doesn't handle release hours !

    apart of that the script does what it should


    V0.09 is still under investigation/testing/development, maybe tonight...

    jim_p thanks for testing and report


    +++ Edit +++

    I'm quite sure you were not running V0.08 when you maid the screenshots/pictures !

    Why ?

    looking at your pictures, where it reads

    " u) update your nightly to the lastest. )"


    ". )" doesn't exists in V0.08 anymore, that was the typo fix I mentioned in the changelog

    or

    look at the script code, line 394


    and cause you're not running V0.08 you got the junk in the 2. photo: 20220629 is an downgrade for the running 20220627


    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

    I use firefox and right-click on the MediaFire link, then "copy-link" and paste that after "wget " and I get the script.


    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.

    thanks for the offer

    Since there are no new nightlies today, because the last commit is still f7f28a7, I will keep 0.07 and test it and I will upgrade to 0.08 afterwards.

    and what do want archive with doing so ?

    0.07 has a bug with legacy and with 0.08 it's fixed ?


    that what I already know !


    yesterday I tested legacy update/downgrade and the same for generic several times.

    0.08 seems the way to go !


    P.S.

    your wish was heard:

    a download link is available in comment #1 !

    Arrrggghhh, I completely read over (correct engl. ?) "legacy".

    sorry !!!

    - legacy is untested by me, so far -


    EDIT

    see comment #52


    P.S.

    V00.7 doesn't change anything regrading your issue you see !

    it has an adjustment [1] regarding disk space check


    [1] where I'm not complete satisfied with ...


    P.P.S.

    in case you want to avoid a disk space checks at all:

    you could change line 401 and 408 to:


    download_and_install ${UPDATE_NIGHTLY};

    and

    download_and_install ${DOWNGRADE_NIGHTLY};


    each without: "check_disk_space ... &&"

    Yes I am on v0.06 from 23.06.2022

    now, and also before your comment #46, too ?


    see my attached screenshot:

    I'm like you on "ccaf8be"

    and I test the script daily with the download server side in an browser open


    And today, besides the above message that the new image is under downgrade, ...

    and

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

    seems to be a contradiction

    me is confused

    ... I am getting a low space message

    and

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


    yup, for "download" only

    please read line 7 in comment #1


    what is it ?

    what's my doing in the script ?

    at least a sort of "blame JoeAverage"-prevention


    backgound:

    I've downloaded the Generic and a RPi image and decompressed them.

    it turned out: what you can read in line 7 from comment #1.

    the numbers 4 and 5 are rounded values, cause I only could calculate with integers.


    decompression is a point what the update installer does and I'm unsure how he/it handles this "low disk space case" exactly:

    IIRC, the update installer denies to install the update !


    so, the nightly was on one hand successfully downloaded, but on the other NOT installed cause of insufficient disk space.


    in the worst case I would have downloaded a nightly maybe (see some comments above) on a low speed internet connection *just* for peanuts !


    question: who would be the idiot afterwards ? 8)


    so my script checks the disk space needed to successfully decompress the nightly during update installer run *before* I start a download at all and exists when diskspace seems low !


    EDIT

    I've checked the decompression factors again:

    as mglae somewhere said max. decompression size is always ~576 MB (tested Generic and RPi2), what would be a decompression factor for Generic of 3 and for RPi 5


    is fixed in script Version V0.07

    I'm running a refurbished DigiBit R1 (shot for 60 €) with lastest FW since ~4 years now with nearly no complaint's.


    1. but sometimes the box hangs somehow just after the first boot:

    - e.g. TVH is unable to connect

    - the light for the SAT connections stays off

    a reboot of the DigiBit fixes it (light is on, etc.)


    2. another point is:

    the DigiBit sometimes gets really hot (I guess ~60°) and this problem seems to be independent from it's hot outside (summertime) or if a TV channel is currently active.



    maybe I need to mention:

    * the DigiBit is powerplugged in an smart socket, auto. shutting it off when sucking less then 9 W over a timeframe of 120 min. (no TV channel is running)

    but I've seen the "unable to connect to TVH"-problem *before* I bought the smart socket.


    * gets a fixed DHCP IP address


    * only 2 Sat ports in use


    anyone seen the above ?

    any fixes/pointers ?

    jim_p


    I guess the script version you were running was NOT V0.06 from 23.06.22, right ?


    I would be very very astonished, if so, cause exactly the mismatch what is the update/downgrade was/should be fixed in V0.06 and I run the script daily here without your above obvious mismatch/mistake.


    there is a internal talk going on to place the script on (in ?) a central place in the future, but before it will change again, cause the download server structure will change.


    up to that:

    no need highlight 400 lines !

    just click the copy icon most right of the word "Bash" (top of the Code box)


    the whole keystrokes with editor "vi" needed are:


    0. open a webrowser and move to comment #1 in this thread

    1. ssh to the LE box

    2. move to the directory where the elder script lies

    3. run "cat < get_nightly.sh > get_nightly.sh" what empties this file/script

    4. vi get_nightly.sh

    5. press the copy icon in comment #1; a popup message will appear

    3. press in vi the "i" key (for insert)

    4. press in vi "CRTL+SHIFT+v" what paste the content into the currently empty get_nightly.sh [press "CTRL+SHIFT+v" ONLY ONCE !!!]

    5. press in vi "ESC"-key (leaves vi's insert mode)

    6. and afterward ":wq" (double point, write, quite)



    I risked though and pressed d to "downgrade" to that nightly, checked that the file was copied in the .update folder, rebooted and the update was done correctly.

    no need to check that manually, the script already does it.

    and another point:

    if something goes wrong with the downgrade: it has nothing to do with my script, cause it's the update installer task.

    my script just fetches a nighlty image and places it under ~/.update

    that's all it does.


    or in short:

    "teamwork is essential. it allows to blame someone else." 8o

    well, I'm the opinion when the box boots it configures the resolution of the monitor or what the monitor per default could do via a sort of handshake.


    I could be wrong !


    but when I'm not:

    why doesn't that work for you (without manual intervention) ?


    that's one part of the background of my suggestion.

    the other was: running a monitor out of it's specs (if possible at all) wouldn't be good in long terms, I guess ...