On a Wetek Play 2 better to continue using this version or switch to Coreelec?
if everything is fine why switch? do you need new features?
On a Wetek Play 2 better to continue using this version or switch to Coreelec?
if everything is fine why switch? do you need new features?
@ wrxtasy: Are there other fixes in 8.2.4.2? Are there a log / release notes somewhere?
Hint - the patch in question, patches CPUInfo in Kodi - it Does Not patch the Kernel, only what Kodi reads from the Linux Kernel which is the Maximum CPU MHz the SoC is capable of.
You can still get the current CPU Freq with:
Believe me when I tell you there is NO bug.
I see. Thank you @wrxtasy. It's just a cosmetical thing in the gui.
I was just scared as load is nearly zero and still the cpu temps are around 3-4 degrees higher in idle than with the build before. but not a big thing. it seems to work, that's what matters. you were - of course - right. thank you.
It's not a problem and is functioning exactly how Kodi was Patched to operate to avoid user confusion:
thank you. but this patch was commited on Sep 6, 2016 already. why does the scale down work in 8.2.4-Subtitles-ff and in releases before then?
it's a bad decision in my opinion. the cpu runs in power mode all the time, which means more heat and more power usage - not really energy efficient now
Display MoreWith this build
echo 100000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
does not work anymore (with 8.2.4_subtitle fix it did). cpu is not scaling down and always is on max 1512MHz which is bad for cpu temps, as my minix is running 7x24.
only
echo 100000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq would work. but then it's limited all the time and browsing is awful slow.
could you please look into that issue?
back to 8.2.4-Subtitles-ff and cpu scale down does work again. so it's confirmed it's a problem with the new build.
does 8.2.4.1 use a new kernel?
With this build
echo 100000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
does not work anymore (with 8.2.4_subtitle fix it did). cpu is not scaling down and always is on max 1512MHz which is bad for cpu temps, as my minix is running 7x24.
only
echo 100000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq would work. but then it's limited all the time and browsing is awful slow.
could you please look into that issue @wrxtasy ?
thank you
Hi all !
Can I now be sure my Minix U9-h will auto switch to correct resolution and color dept between HDR and SDR movies whithout having to add any manual commands during a movie evening with my friends ?
With the 8.2.2.3 build.
Panasonic OLED EZ950 TV.
Thank you in advance for your reply.
Yes, switching between resolutions and color spaces does work without manual actions.
Your problem is similar to mine.
New TV, old AVR and HDMI splitter
You can try to do this with a hdmi cable from AVR to the projector.
Did this work your you? Such a "simple" hardware mod. Would be nice.
Your problem is similar to mine.
New TV, old AVR and HDMI splitter
You can try to do this with a hdmi cable from AVR to the projector.
Thank you. I already ordered an HDFury Vertex (as well it supports RS232 for Home Automation, i.e changing Projector Color Profiles from REC709 to BT.2020) which will get delivered today. This will solve the problem as it can send the devices custom EDIDs.
Is there a way to force HDR output on s912 devices?
I am asking because my projector isn't HDR capable, but has a wider color gamut (REC2020). In my chain (Minix > Oppo UDP-203 > AV Receiver > Epson LS10000 Projector) sits an Oppo UDP-203 player, which has a HDMI Input and would accept HDR signals and tone map it to BT2020/SDR.
But /sys/class/amhdmitx/amhdmitx0/edid does not show and Deep Color / HDR strings from the Oppo UDP-203. That's, why I guess, the s912 always puts out REC709/SDR.
My s912 minix all the way gives out REC709/SDR even when I play BT2020/HDR files.
So the s912 is converting REC2020/HDR to REC709/SDR, but I would like to output unmodifed HDR and the oppo to do his tone mapping magic.
cat /sys/class/amhdmitx/amhdmitx0/hdr_cap =
Supported EOTF:
Traditional SDR: 0
Traditional HDR: 0
SMPTE ST 2084: 0
Future EOTF: 0
Is there a way for a custom hdr_cap file, like custom EDID (which is already possible), which overrides what's in /sys/class/amhdmitx/amhdmitx0/hdr_cap? Would be a very nice feature for displays which offers BT2020 color gamut but no native HDR support.