3 posts were merged into an existing topic: 3D MVC support
My X96 Air 4/32GB has still been going strong - just needing an occasional refresh of the corelec to keep things working
recently i ran into a problem - was running CE20.5 but in the last month or so it started acting a bit funny - locking up - rebooting - menu items going to blank pages - and also started losing its wifi connection when waking from standby
i thought this just meant that it was time to refresh CE again - which i have done - its now running CE21.1 through a complete fresh install
everything now works as intended - except for the dropping the wifi connection after standby - its not done this before in the 3 years i have been using it
my device is X96air_A100 - uses sm1_s905x3_4g.dtb - CE21.1
is it a config type thing i can change - or does anyone know a fix
much appreciated!
can anyone offer any support on this ?
Iām struggling with a performance drop while playing videos with the HW codec on my Ugoos AM6 Plus. Iāve configured the system to always use 60 FPS. The video starts smoothly, but then the FPS drops down to 11-20 FPS. If I start a CPU-intensive task (e.g., compressing to tar), the FPS goes back up to 60 FPS. This is likely related to the power management of the main CPU. Is it possible to configure the energy mode of the box?
Yes, Itās the GUI renderer FPS, video decoding can be much faster. If the GUI renderer is slower than 24 FPS, the video wonāt be smooth enough.
The question is: Why is the GUI rendering so slow, and why does the starting of a CPU-intensive task increase the GUI rendererās FPS? With ffmpeg rendering, it works at 60 FPS. It could be that the main CPU switches to a low energy consumption mode due to low CPU usage.
Is there a way to adjust this setting and prevent it from switching to low energy consumption mode?
No, itās not this case. The gui FPS is regulated by the need of render the gui. Itās NOT related to video FPS. When you switch off osd it goes down to 0 FPS as there is nothing to render.
We will remove this annoying useless gui FPS as it only confuses people.
2 Likes
Thank you for the detail answer.
For me, itās still unclear why the external to kodi task (archiving to the tar in the terminal) increases GUI render fps (at least in the view) and solves my problem with not smooth video play.
Is the CPU governor at āperformanceā or āondemandā?
<sftp:root@coreelec>$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
performance
performance
performance
performance
performance
performance
I found the issue. It is not a CPU problem but rather processed by the rendering engine.
The behavior is as follows:
1. The OSR displays memory information on the screen.
2. When I start compression to a tar file, the system intensively uses memory.
3. Kodi checks the free memory and updates dirty regions to reflect new memory data in the OSR, updating the display.
If I set algorithmdirtyregions to 0 (where the entire viewport is always rendered), everything is rendered continuously, and the video plays smoothly with AMLCodec.
Iām not sure, but it looks like AMLRenderer does not update dirty regions similar to FFMpegRenderer. So far, I havenāt experienced this issue with it.
Thank you for support
can anyone point me in the right direction for this
a bit more information -
after waking from sleep - if i open the coreelec configuration addon - i can see it says āfailedā next to the WIFI connection
if i then select āconnectā - it will connect again successfully - signal strength is good - everything then works as it should - so there is no hardware issue
i did this so i could connect and see the kodi log after its woken from sleep and dropped its wifi connection -
so at 18:09hrs it went to sleep - and around 15mins later i woke it from sleep and that section of the log file reads as follows
kodi log 27102024.txt (70.3 KB)
the log is full of junk from lots addons reporting errors because they cannot see urls - and then some python errors i cannot make much sense of
if this enough information to get some pointers ?
I think there is a setting to have Kodi wait for network ready when starting up. Maybe check that you have this setting enabled? Iām thinking connecting to wifi is maybe too slow and extensions trying to use it timeout and then doesnāt retry properly or something like this.
thanks for your reply - i was beginning to think i was invisible - or had committed some forum etiquette blunder that had rendered me persona non grata
i did see that setting - so i have tried it both enabled and disabled - but the behaviour is exactly the same in each case
interestingly - if i wake the unit back up after only a 2-3minutes of sleep the wifi can still be connected - whereas if i leave it 10minutes or more - its is always showing āfailureā in coreelecās connection status
if i am not mistaken - these boxes do some kind of light sleep for the first 10minutes or so of āsleepā - before powering down fully - and the connection dropping seems to be associated with this full sleep only.
what should i try next - or do you need more info / logs etc
if so please let me know which
i think the fact that it only drops when the OS goes fully to sleep and then wakes again means its likely a CoreELEC issue - something changed with the WIFI drivers in the last couple of versions perhaps - as it started doing it after an auto-update - before this latest clean install.
happy to be proved wrong - but let me know what logs / data are needed
A post was merged into an existing topic: Help, support CPM build
trying the udevadm info command via SSH i get
CoreELEC (official): 21.1.1-Omega (Amlogic-ng.arm)
Machine model: Amlogic
CoreELEC dt-id: sm1_s905x3_4g
Linux version: 4.9.269 (portisch@ubuntu) #1 Mon Aug 26 17:08:18 CEST 2024
Kodi compiled: 2024-08-26 16:21:12 +0100CoreELEC:~ # udevadm info /sys/bus/pci/devices/* | paste
Unknown device ā/sys/bus/pci/devices/*ā: No such device
https://paste.coreelec.org/EmptyPaste
CoreELEC:~ #
does this help ?
looks like i used the wrong command for my box
flailing around in the dark here 
does this help at all ?
Use shut down instead suspend.
Itās more a connman issue, the driver did not change I guess.
When the device go to sleep the chip is not controlled anymore and maybe not init or handled correctly again after resume.
Linux system arenāt far away to be suspend compatible finally and will never be I guessā¦