so I switch to legacy and it turns out there is still a bug (an update is identified as downgrade, f*ck !)
- needs time -
so I switch to legacy and it turns out there is still a bug (an update is identified as downgrade, f*ck !)
- needs time -
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 ?
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 ?
the script is named *.bak and should end on *.sh, - I guess-
and
the autostart.sh has a "(" at the beginning and an ")&" at the end
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."
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 ...
I would check the vendor specs of your monitor regarding resolution/frequency ...
I guess it could be done via an script running at startup.
but I would also check the setting.
maybe you need to switch to expert or similar mode before: the most left bottom icon in the setting screen: multiple clicks on it
LE config addon:
=> system
* Resolution
* whitelist
don't know if LE has a default Resolution causing the switch back, but then the startup script should do the job
how and where to put a script running during boot:
This does not work or works very poorly.
What does not work or works very poorly ?
*reading* and *understanding* a simple sentence:
cit.: "We can update from both .tar and .img.gz files, but .tar files are faster to process."
or
that *you* didn't get rix81 is searching for *obvious* LE11 nightlies ?
Garzie, when I press the Enter key on my keyboard or the OK key on my remote I get a menu similar to your first *.png.
yeah, AVG spreads malware too, at least in the past:
=> Controversy
anyway:
I guess the above message from your virus scanner it harmless.
jim_p, I found a bug (what is for update/downgrade) wasn't work as expected
(hopefully) fixed it now and the script is online again.
you need to copy the script again !
a report is welcome
P.S.
what image are for RPi3b+ ?
I guess RPi2
I had a similar problem running addon "Kodi-Addon-ARDundZDF" what initial isn't ready for LE11
editing the addon.xml from it and changed the number to
<import addon="xbmc.python" version="3.0.0"/>
reboot and I was done.
don't know if this trick works out everywhere ...
what convinces you to know how big the "flies" are in, let's say: in 5 years, when the box needs to do some other work apart from AV ?