I have Coreelec 21.2 emmc install on an Odroid N2 w/ 2GB ram (always on).
I notice over time (from boot to next forced reboot) the system runs more and more laggy, the breath (blue) led is blinking faster and faster, until a forced reboot (and in rare cases a forced power cycle) is necessary.
The system temperature is always reasonable, and i think 2GB of ram is plenty for Coreelec.
Can you help me troubleshoot this?
Thanks…
I think this is a kernel level problem which goes right back to the AMLogic propitiatory kernel that is used. I find its particularly poor at changing the decoder and the way it handles the frame buffer for the video. Quite often when I play a HD file and then go back to watching a SD source it simply grinds to a halt and crashes.
I do not think that there is anything that can be done about this since the kernel is propitiatory and has bugs. Thats my opinion anyway.
Does anybody know how the blue led blink rate is coming from?
Its set in your config.ini, it can be completely disabled there.
New method is to use CE settings, hardware, system led.
Thanks Shoog, but that will simply change the led behavior, it will not fix the reason the system gradually slows down to a halt.
Just a thought,
I have 2 identical setup Coreelec boxes in the house. Their only difference is the SOC. The Odroid N2 is with a s922x, and the TX3 with a s905X3. Both 2 GB ram, both wired network. Guess what, the s905X3 shows NO such symptoms.
This started on the Odroid after the Omega update. Before Omega, both functioned trouble free for weeks non stop. Perhaps this deserves a second look at the Odroid low level code (example) from the experts?
As far as I am aware the S922 and the S905x3 run on different AML kernels - so there is likely to be significant differences in the way they behave under CE due to these different kernels. The S922 effectively EOL so will never see any kernel revisions so issues that exist now will never be solved.
As has been said - the AML kernels are proprietary so there is very little that can be done to correct fundamental performance issues which are caused by the kernel as they are supplied as binaries.
Not correct: coreelec:ce_dev_cycle [CoreELEC Wiki]
Both SoC are supported by CE-NO, 5.15 vendor kernel.
I will never say i know better than you, i don’t.
But to me, this sure looks like a memory leak on the s922x in general, or the Odroid N2 specifically.
Running 2 Odroid-N2 devices with CoreELEC 21.2 installed on SD card.
No issues like yours. Don’t see any memory leak. Both devices up and running constantly for weeks, maybe months without reboot.
Maybe you have some add-on which cause memory leak?
You could try to monitor hardware and confirm if memory leak is indeed a case: CoreElec HW monitor
Running several N2(+) 24/7 without noticing any substantial memory leak issues. Maybe try without any (3rd party) add-ons if present….
Mine has had the described behaviour since I got it a few years ago. Any change of encoding format playback is liable to cause a slow down and eventual reboot. Happens every few days usually after a HD movies and then back to Tvheadend TV stream. Used to cause blackscreen and hard lockups on format switch so things have got better.
As far as I am concerned its just part of the territory.
Thanks Shoog, this is the first helpful tip i get (that makes sense) and it matches my situation.
I run Tvheadend on an older Mecool Ki-Pro with 2 clients, the GT-king (s922x) and a TX3 (s905x3). The difference is that we mostly watch TV on the s922x.
I’ll look around more into this, but as you say maybe i should accept it as “just part of the territory”.
One more thing i found out experimenting, I run kodi for many years so the whole family was used to the older default skin “Confluence”. I continued using it after kodi changed their default skin to “Estuary”, and i decided to switch to the new skin only last month (see if it made any difference).
BIG difference. Because of the skin change alone, i can now get 3-4 days of use without having to reboot. (wtf ???)
I personally believe its a problem with the way the frame buffer is used by the decoders. Each media stream has to engage a decoder from the list of hardware decoders which in turn takes possession of the frame buffer which is written out to your TV. I think what happens is that at stream change the decoder fails to release the frame buffer correctly so there is a conflict which eventually leads to a lock up.
I don’t know if this is correct - but for me the issue has been so present and persistent I can only believe that its something to do with the way that the AMLogic propitiatory kernel handles the frame buffer and decoders. The fact that the slow downs happen when a different decoder is engaged is the clue for me. Since this is binary kernel code and not source code its not within the power of the CE team to address it.
If you completely stop a stream before engaging the next one things seem to behave more predictably, but this is not a guaranteed fix by any stretch.
I am willing to accept that I am completely wrong - but this is the best explanation I have which fits the behaviour I have seen since using AMLogic devices and especially the N2.
About | FAQ | Terms of Service | Privacy Policy | Legal Notice