...One of the best and often underappreciated 'debugging' techniques, is taking a break/nap or plainly a good nights sleep
Hhhmm, "collides" with getting work done. 
anyway:
a new version of my script is under comment #1.
and needs testing and I'm quiet sure "optimization"
anyone ?
P.S.
now comes the nap ...
thanks diederik
but sorry I guess I never will support those platforms.
why ?
look into nightly download directory and compare with your os-release.
on the first you'll see a lot of "sub-variants" (?, the part between git tag and .img.gz) for .eg. 3328, but no such sub-variants in your os-release.
therefore, with my script I (currently) can't figure out what sub-varaint your're running. I guess there is a way, but that seems - as a guy with a lack of doing *logical* programming smart - a sort of burden.
numbers to backup this thesis:
yesterday (?) I sat from 4 pm non-stop to 4 am at a new version of the script - with a lot of caffeine/nicotine - and it's not ready yet ...
and I feel I'm getting old, earlier ~18 h nonstop wasn't a theme. When I have bitten in a task it goes nonstop until tiredness isn't "fixable" with further caffeine and lastely realizing that I repeat the same programming mistake over and over again ... 
The compressed size differs from platform to platform, e.g. ~211MiB for Generic or ~123MiB for RPI4.
sure, in my scripts I dynamically fetch the compressed image size for the diff. platforms already from the download server
Disk/image size is constant (read: changes in calculation are very rare): https://github.com/LibreELEC/Libr…pts/mkimage#L25
sorry can't get what you mean.
my assumptions are
1. if a nightly is stored under ~/.update and the box gets rebooted then the update installer decompresses the nightly (*.img.gz => *.img)
what blows the nightly up to the un-compressed size of (compressed-nightly-size * 2.6)
2. further I need to have this so calculated size of disk space to be able to install the update at all without errors (caused by lack of disk space)
is my assumption wrong ?
thanks HiassofT
and sooo easy, Mrrppphh 
Assumption that compressed package needs three times more to install is as inaccurate ...
Indeed it is inaccurate: cause it seems to be more then "3".
*I* assumed the de-compressed file is 1.5 up to max. 2x of the initial compressed image.
so my initial disk space calc was as following:
1x image size for downloading the nightly image in ~/.update plus
1x image size for the second copy of the nightly image in ~/backup plus
0.5 up to 1x image size when decompressing the image
===
2.5 up to 3x (the max) of the initial downloaded nightly image size as diskspace would be needed, so calculating with the 3 (the max.) I felt more on the safer side, until I proofed it:
instead of assuming decompression ratio would be 2 only, it is real ~2.6x !
ls -lh
total 760M
-rw-r--r--. 1 ron ron 549M 12. Jun 11:02 LibreELEC-Generic.x86_64-11.0-nightly-20220612-363112b.img
-rw-r--r--. 1 ron ron 211M 13. Jun 09:42 LibreELEC-Generic.x86_64-11.0-nightly-20220612-363112b.img.gzthanks.
the last version of the new script is in comment #1
you got RPi* and willing to test ?
thanks, but it wouldn't fullfill my needs.
I want to share the script to LE users, so I need a LE-buildin-solution what will work on all LE boxes
- self deleted -
I need to do calculation in an shell script under LE, e.g. this:
#!/bin/sh
SPACE_NEEDED=$(expr 220 \* 3 \* 1024 );
but "expr" is unavailable under LE.
Idea's ?
thanks, will try to handle RPi* with my new scripts, too
needs some time !
Have you thought about putting it in a(n online) git repo? (and putting a link to that in your script thread)
Huh, my small script is usable just for automated home task and shouldn't be blown up to a software project.
Me has a shortage of "brain windings" for programming, cause I first wrote the favorite "Hello world" in C with the age of 30 (1991) and bought my first computer at that time (Intel 386 33Mhz, 2 MB RAM, 40 MB HD, 
)
means: I started very late to train that and now it's long ago
I guess my knowledge fot programming (I've been working as a OS supporter/(Co-) admin) is just sufficing to do some (small) scripting and sorta extended "Hello world" "projects".
that's all
I don't know if it already exist, but a (small) downloadable file with the filename + size + checksum (to verify whether the DL succeeded) seems very useful and shouldn't be too hard.
+1
best: a text file
if I get it right: the update installer does a sorta check summing, if in RAM only - don't know ! -
file size is there too, but I need to fetch that info out of the downloaded file "index.html", not done yet.
and it seems the download directories are changing somehow: yesterday a new variant hit the scene ...
and at least it should be clear:
when the update installer from the LE-Addon is able to handle all files in the download server directories (think: image roll back; change between generic/generic-legacy) then the script is (mostly) dead anyway.
jim_p, thanks for the report.
But I told you in another thread: don't use the script anymore
1. it doesn't decide between Generic and Generic-legacy and as you told in the other thread: switching between both isn't that flawless.
2. there is a left over in ~/.update when hitting CRTL+C. maybe a half downloaded/damaged image.
don't know what it exactly means, but I guess it won't harm (untested !) cause the update installer run a sort of check summing and should deny installing the update
3. I nowhere check the needed disk space to download, copy the ~/backup and to handle the uncompression the update installer does.
(kudos diederik 
)
anyway, I rewrote the script to handle 1. and 2., but currently not 3.
for 3.:
I guess I need ~2.5 - 3x the image size as required disk space (1x update, 1-2x the uncomressed update, 1x copy in backup).
therefore I need to fetch the image size from download server *before* I start downloading at all.
for 1.:
I currently fetch the HW; Arch, etc. sorta dynamically from the running box, but currently not for other images (as of now only: generic and generic-legacy is handled)
The lack I have is the output of "cat /etc/issue" for esp. RPi's and others and of cource the HW to test (owning a Generic only)
care to post that for your RPi ?
maybe I get some more grip...
I'm completely undecided to put the new script online again ..., until at least I get a fix for the disk space part ...
just a shot into the dark:
- two partition on the media disk (kids/parents stuff splitted on separate partitions)
- two profiles (kids/parents)
- the kids profile does a umount of the parents partition via a script when kids profile is entered
- the parents profile does a mount ....
- ... ?
+++ Edit +++
are you aware of extra triggering the kids fun of discovering stuff when it's named "PARENTS FILMS"
- haven't you never searched parents room's for presents you'll get at x-mas, when the parents were outdoor ? 
-
CvH thanks for clarification
May I ask why today's x64 nighly build (83a7f20) is named "generic-legacy" instead of just "generic"?
can't answer the question, but - maybe your read it already - I pulled my script, so please don't use it for Generic anymore, until the question is cleared.
I guess it's not a rename only, - AFAIK (unsure) - it's another GPU mimic variant. size differs too ...
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.
yeah, my mistake, sorry !
line 71:
wget -nc "${SERVER_URL}"/"${NEW_NIGHTLY}"; should read
wget -nc "${DOWNLOAD_URL}"/"${NEW_NIGHTLY}";
please fix that in your script !
and yeah "-vx" is some sort of debugging to show how the Variables the script uses gets filled/what there values are when the script runs
You may want to take into account that people could be using a 512MB or 1GB SD card on which downloads fail because of -ENOSPACE
very good point !
need to think about how to manage that ...
and I need to think somewhat more since "legacy"-variants hit the scene ...
and after some more thinking I pulled the script completely !
who watches the movie then ?
