@andy5macht so you had the OC set too high then? I think my device also craps out at 1992 on the a53 cores.
yes, i think so too now. but it did work with stable 9.2.1 and i had no errors while using the devie until reboot?! so i haven´t thought of this
Test 9.2.1 again to confirm the frequency works okay, if it does then I will look into it further.
I had this problem also, 1992 was causing problems.
https://relkai.coreelec.org/CoreELEC-Amlogic.arm-9.2-nightly_20200116-Generic.img.gz
Kodi constantly reboots every hour.
P.S. X96 s905x.
I have 52-54 in idle (static picture), when I start to move mouse and go through menu etc., temperature goes up to 56-58. Which is quite high (with air through the box). I am get used to 36-40 idle on C2.
I installed Temperature Monitor on stock Android 9 and see, what temp Ive got after couple of minutes.
Not sure, if older kernels had HDMI connection detection or something, to save cycles during display turned off. Or if android kernel have such function though.
After 5-10mins, idle stock Android temp is stable on 46 (even with signal on TV, so thats not the state HDMI device is off)… When I moving a mouse a lot to make screen changes, it goesto 48-51 very quickly, like after 3-4secs. Then, temperature is around 51, comparable as CE idle temp (although still 3°C less). When I left mouse on spot, temp goes down eventually again on 46C.
I am not talking about Kodi dirty region or smartredraw, I dont have enabled any of these. Idle CE was tested in static picture, no scrolling texts etc., because Android have also static picture.
Would be great if this could be nitpicked somewhere (kernel?), 46 is far better than 54 in long term and also this would match stock SW+HW behauviour.
Not sure what was changed, if temp dropped 10C before according hav, but I think there is still some room to improvement and catch the flies(?).
Summary TL/DR:
I think CE-ng nightly temperatures are quite high…
P.S.: Android was 1080/50Hz, wifi off, CE was 1080/23.976, wifi on
Using Nightly builds means that the user has very little controls in regards to Update settings?
Using CoreELEC-Amlogic-ng.arm-9.2-nightly_20200116-Generic, and first thing I have done was set to manual for ’ Automatic Updates ', and disabled ’ Show Update Notifications ’ then shortly afterwards It alerted me of an CoreELEC update. Decided to try restarting Kodi, and got back in and soon was prompted again.
Also CoreELEC-Amlogic-ng.arm-9.2-nightly_20200121-Generic Update messed up my eMMC install, which is a lesson learned. Moving on from that…; however on freshly cleaned Micro-SD Card that update puts my GT1 Mini 4/64GB unit into a rebooting loop. Not even able get to the preparation phase… anyways one of the incentives to control Auto updates and have control over being notified besides.
Imagine when being asked to try the Nightly build to see if it fixes the issue, and when it does. They have to wait for official version to become available to change back over…, assuming that’s possible? In the mean-time person not interested in participating with the experiment trials so where’s that leaves those?
Also, what about people who interested in helping with Nightly builds but sometimes very busy, or when they aren’t feeling in the mood for few days, week or so. So this should seen as priority situation and addressed.
… just my thoughts on it.
Well, regarding my boot loop. I downloaded the CoreELEC-Amlogic-ng.arm-9.2-nightly_20200116-Odroid_N2.img flashed it to a microsd, and it boots.
How do I get that image to the emmc?
Thanks!
(brainfart thoughts; Would it be possible to add a counter of sorts.
That counts fast unsuccessful boots, and when it hits a limit, it decides to flash the latest successful image?)
ps. sorry for crosspost ds.
There are 2 paths.
Stable build, where you will expect any bugs/issues to remain until the next stable release but also not to be introduced to new ones.
Nightlies, that although up to date with updates, fixes etc, you have to accept that being at the bleeding edge, sometimes things will go wrong. So always take a backup of a new, working installation before proceeding with any update.
When things break or go wrong, it is useful to developers to get as much information as possible about what happened, what release, what box and sometimes logs too.
I can confirm that updating to NG 202020221 failed on my S905X2 (A95X Max) where during the update the process reached a point where the last thing on screen stated that it was updating samba and then stalls for a few minutes before rebooting, where the box VFD shows the word boot but where there is no further action and no activity on screen. Powering off an on shows the same process.
I will extract the contents of an earlier release, boot from an SD card an replace system and kernel to see if that resolves things.
Updating 202020121 on an S912 box works fine.
I know this all already… and still the matter should be taking seriously. I explained some cases why so…
Got the notification that there was a new version available and did i want to reboot and now I am stuck in a bootloop. Installed to emmc on a S905X3.
They are taken seriously and you also have the option of saying no to updates.
Busy and not in the mood are things that I would consider not taking things seriously but that is not the position of the devs.
As for priorities, that should never ever be something dictated by users unless they are paying for a product or service, which is not the case here. I cannot imagine any dev not wanting to put any and all bugs at the top of a priority list but this is not practical from standpoints of time and resource availability (which includes factors that are outside of their control).
The paths are clear and simple, one of which comes with danger, which is also clearly stated in advance.
Compent… who are you to CoreELEC?
You a regular so please don’t speak on their behalf.
I expressed valid concerns and opinions and if you don’t agree, then that’s you but you don’t speak for CoreELEC so please stop trying.
Similarly!
New version, result bootloop error. Installed on SD / X96 Max Plus 2 S905X3.
Similarly!
20200121 nightly build was removed from update server.
Thank you for info.
To restore just replace kernel.img and SYSTEM file on cards(use previous build tar file to unpack this files)…
For ceemmc installed system follow ceemmc instruction to restore only /flash partition
2 Likes
Thank you for help,info.