kapqa it seems that there is issue with build server. You can check later or build image yourself.
levitsky86 Please enable debug logging and execute pastekodi in ssh after the issue is observed. It will upload all relevant logs and generate URL. Hopefully it will reveal something useful.
the nightly would function, however it would not connect to any repositories "could not connect to repository" > maybe there is an issue with the ethernet?
Depends which board you have. Common mistake is to use non-plus image on plus board. Ethernet is slightly different.
jernej , perhaps it can be added to global /etc/systemd/sleep.conf for Crust supported boards?
It seems that you have figured out everything. You can make PR. I would gladly merge it 
the original libreelec for pine a64 had separate images for 512 and 1gb/2gb a64 versions?
No, 512 MiB boards are not really supported. Memory consumption is not optimized enough. However, some 512 MB boards are still in list, one on explicit request and other for historical reasons.
image for pinea64 (librelec10) is totally unstable; would boot, hang during setup screen, would start again, after some 10-20 seconds screen
Something like that was fixed about a week ago. Which image did you try? Try latest nightly image.
are there any repositories left with the older images? thanks.
Only latest nightly and beta1 images are available, but beta1 won't work for you.
I don't know, I never used netflix addon myself. You should ask about it in subforum which is not platform specific.
There was no LE 9 (Kodi v18) release because at that time it didn't work good enough. It's possible that someone kept images though...
I have no noticed that there is no separate nightly update image for Orange Pi Plus 2E.
I guess some build server issue.
Should I update from any other image now?
No. Currently there is no so much relevant changes that you would need to update.
I'm not 100% sure, but if I recall correctly, testing there was done systematically with some script where it seemed to work, but after additional testing with Kodi, problems were observed. Note that these problems are not necessary obvious immediately. This was tested and discussed internally in LE team chat...
The libreelec works normaly until I turn-off the television. This last operation turns-off the banana-pi, but unfortunately like a cut-off of the power supply, without activating a process for power-off!
Actually I want that the banana-pi remains turned-on while turning-off the Sony-television.
Is this issue known?
Why do you think it's not properly shut down? Shutting down board when TV is powered off and vice versa is by design. If you don't want this behaviour, then either disable HDMI-CEC on your TV or change CEC settings under input settings in Kodi (currently I can't give you detailed instructions).
Another issue I see is that GS1 doesn't seem to be running GPU at full speed.
Yes, devfreq for GPU is missing because all attempts to make it work failed. GPU always locks up after some time due to unknown reason. 432 MHz is default frequency in HW and it's good compromise between speed and consumption/heat. Note that Android uses different GPU driver (closed source from ARM), which is probably better optimized than mesa.
H3 supports booting only from micro SD card or eMMC (where Android is installed). You don't need to do anything special for booting from SD card, just burn image and insert it - SD card has higher priority than eMMC.
You can try with Beelink X2 image, but no promises - I don't know if it is compatible. Only currently available images are for LibreELEC 10 which has Kodi 19 (either beta1 from download page or nightly images). There is no image with older Kodi.
3) 2.4W running, idle on Kodi homescreen. Kodi IS wasting too much CPU in idle mode though, shouldn't be more than a single digit percent of a low frequency state CPU core, not ~35-40% like at the moment.
You should also check CPU frequency. Governor lowers frequency during low load.
BTW, Crust/Linux fixes were just merged for GS1.
offbeat CEC is indeed a bit flaky at the moment. You can test above suggestion if you want. It's unlikely we'll be able to make it behave perfectly before final release. It's big PITA. Crashlogs should help.
I should be able to build/test any patches if that would help.
Please test this patch: http://ix.io/2UF5 (just put it in projects/Allwinner/patches/linux/). CEC still works for me after switching input sources.
I tried a few things yesterday, installs fine, my needed add-ons work, although the streaming buffers a lot. I don't know if it's related to the Tritium H3 or the mpeg-dash stream. We always had problems with these streams, but no freezing or repeatedly buffering. When I switched back to my khadas vim1 running leia everything was OK'isch using the same add-on.
I tested streaming on H5 version and it worked fine at that time, but it used HLS protocol. It could be protocol related. Note that Tritium boards only have 100 Mbps ethernet via internal PHY - I already had compatibility issues with that.
Couldn't log in with samba, but maybe i didn't try enough. Before shutting down the device I checked the LE settings and there seems to be a choice now to login with or without pasword. but I didn't try it anymore. I know it nevers gone happen but a nfs server is way more trouble free.
SMB1 is not supported anymore and afaik you must use username/password with SMB2/3. Anyway, no worries. I'm mostly interested if driver works - everything on top of that is same for all devices.
Great, I'm happy that it works for you. Fixes will be included in next beta and I'll send respective fixes to Linux and Crust.
2) No more CEC errors in dmesg and cec-client. I will test ir further later, no access to capable TV at the moment.
Preferred way to check CEC on mainline Linux is to stop Kodi (systemctl stop kodi) and run cec-ctl --playback -S. It should print some TV properties (if it is connected).
3) Suspend/resume and poweroff/poweron worked perfectly while connected to TV. In headless mode though suspend rarely works, mostly fails due to GPU driver error, resulting either instant wakeup, or suspend/crash/smthelse without ability to wake using remote.
Headless poweroff/poweron using remote worked 100% during my tests
Good, that's in line with other devices. I noticed that instant wakeup on few occasions too but currently I'm very happy that it works so well as it does. Poking GPU drivers is the last thing I want to do.
Here goes, Beelink GS1 last stock Android, firmware 106N0, kernel 3.10.65
Thanks. Note that there is no need to use both methods - both should give exactly the same result, which they did. 4 means external 32k oscillator is unusable, which is what we see on mainline. IMO it's best just to disable it and use internal, less precise oscillator. Here is another test image: LibreELEC-H6.arm-10.0-devel-20210330172558-ba292b4-beelink-gs1-pm-and-int-32k-osc.img.gz (burn it, don't update). At least RTC should be quiet now and maybe CEC and suspend/resume will work too. Let me know.
