1. does a/the Git Tag of a nightly always increase ?
2. does the update installer before decompressing a nightly checks the needed disk space ?
I guess yes, but any pointer where could read this routine/script ?
- searched github, but ... -
P.S.
seems I found a bug/case (still investigating !) I didn't handle in my nightly update script (see screenshot)
same date and diff git tags
f*ck 
1/ no. The githash is a hash. It matches the hash from https://github.com/LibreELEC/LibreELEC.tv/commits/master . The “GitHub Actions” (gha) scheduled builds - grab the latest hash and build that nightly / or manually if initiated manually. The gha has the capability of building a hash, which may not be the latest hash - which is used for release builds, it could in theory be used for nightly to build a previous hash image …
1. If we build a nightly every night regardless of what changed in the repo, the githash may not change (as no new changes in the preceeding 24h period). However the current automation should not build new images if there are no changes in the previous 24h period, so the hash for nightlies should always change. It's not something you can 100% count upon though.
2. No because we cannot predict the size of decompressed KERNEL/SYSTEM files in advance. After decompressing the MD5 hashes extracted from the image are compared against the files on-disk, so if tar expansion fails (lack of space or any other reason) or the hashes are absent; validation falis and the update attempt fails, deleting the content of /storage/.update and rebooting.
However the current automation should not build new images if there are no changes in the previous 24h period, so the hash for nightlies should always change
given that:
the case two nightlies with same date (in the above screenshot for Generic or the last both) should "usually" not happen on the build system ?
despite all your both answers (thanks) the problem I have in my script isn't cleared enough/yet
it is:
given two nightlies with same build date but different hashes (see screenshot in comment #1: the last both)
Now I need to decide which one is for update and which one is for downgrade ?
- currently I don't (can't ?) work with the date of the last column ! -
so will the hash comparison in the form always be reliable ?
[ "fa73826" > "b78941a" ]
- for the true case: nightly with hash "fa73826" is for update and with hash "b78941" is for downgrade
- and for the false case give: nightly with hash "fa73826" for downgrade and "b78941" is for update
does the comparison always work out, or particularly:
- is the hash from today always higher then the one from yesterday ?
- in other words: can I decide from two given hashes which is the elder and which the newer one ?
===
for the update installer decompression disk space size problem:
would it be an option to decompress in an ramdisk (RAM) if disk space isn't sufficing and RAM would fit ?
I guess it would be an speed improvement too ..
- in other words: can I decide from two given hashes which is the elder and which the newer one ?
Based solely on hashes, no. You would need to check git repo which is newer. Hash is just some hex number, calculated from data. In fact, from security perspective, you should not be able to infer any useful information from hashes alone.
EDIT: To be clear, hashes are taken from git commits, we don't have any control over them.
I'm not 100% certain, but I suspect the file used to create releases.json processes files and appends data sequentially so you can probably infer file age from file order (hashes doesn't work) although that's probably a complete bitch to parse with a shell script. The work slowly taking shape in this PR should make nightly updates easier in the future: https://github.com/LibreELEC/serv…ttings/pull/276
thanks folks for input
I guess I'll fix my script with following when it's see's nightlies with same date and diff. hash.
A info to the user saying: sorry, can't decide what the nightlies are (update/downgrade). Try tomorrow !
or the like.
it seems to me slightly better then running wild and ofter an downgrade as an update and vice versa..
will mark this thread as resolved !
EDIT: To be clear, hashes are taken from git commits, we don't have any control over them.
(Git-) Gott würfelt nicht (Einstein) 
