No, we will see if they are need at all any after fixing “basic” items before fine tuning.
I wasn’t sure how to do a clean install for coreelec on the official dual boot or does it not matter if an upgrade is done?
Yes, FEL handling is different than everything what was present at Kodi at all. Kodi is a frame based player what was good but it’s not anymore time accurate. Mostly like you get one frame package from the demuxer but mostly it’s like two or more real frames on screen. This is the reason of decoupling demuxer from decoder as it isn’t a 1:1 count anymore.
FEL is even more worse as the decoder needs data feed in, independent from demuxer or frame output.
FEL is BL and EL layer but this doesn’t mean the demuxer deliver one frame and the next. Maybe he delivers two BL and one EL what will cause the chain broken. As CoreELEC looks like the only distribution to support plain FEL such case never happened. This all is a work on progress and we will see what are the correct steps in what direction in future…
3 Likes
EDIT: Don’t use this image. Otherwise you will only get 3GB of total space in your /storage directory. Instead use the ceemmc tool (you’ll get about 25GB this way).
First make a backup. Then either download it, or store it on a USB drive. You will need this later.
Then go here, hit the 0.5.4 firmware.
Specifically you want what’s in 0.5.4->DualBoot CoreELEC
Grab the zip file without ota in the name.
There should be an Amlogic Firmware tool you will need to install to proceed. The img file after extraction is about 1.9GB (if it’s 1.4GB it’s the wrong one). Process takes around 5 minutes. Oh and you need a USB-A to USB-A 3.0 OTG cable. First boot up will take you to the regular Ugoos image. Restart into CoreELEC. It’ll be an older version so it’ll ask to update a couple of times. Then restore the backup.
5 Likes
So exactly what I did before lol, but then read a clean install was preferred and couldn’t work out how to do it
This makes me think the Kodi documentation is actually incomplete for auto cd/cs. It’s not just resolution changes. Auto cd/cs kicks in on refresh rate changes as well, it’s just not documented.
I will test the newer nightly with Portisch’s updated logic, but it definitely seems like the issue is in the auto cd/cs logic.
When GUI is set to 2160p/23.976, which matches the the vast majority of 4K DV/HDR content. The code doesn’t invoke the auto cd/cs logic and it works. There is no screen blanking as GUI=content resolution/refresh settings, and proceeds to playback quickly.
But if either of those change, then the auto cd/cs logic is called. The screen blanks while the resolution/refresh rate matching is set, auto cd/cs is called, and sets the color bit incorrectly.
In the case of the 1080p/60hz GUI that works (PurplePlayer’s example), whitelisting was turned on, which may have impacted the auto cd/cs logic even for 4K content.
This is not true if resolution change to or from DV.
Then a forced mode switch will be done to apply DV settings. The kernel is not designed to switch funny revolution all the time. Android do boot and stay at one resolution. So all of it adjustments needs to be tested and checked carefully as it’s not “standard”.
I’ll probably use dual boot when development on Dolby Vision cools down a bit. Right now using an SD card is convenient for switching between test builds, and as I use fairly fast cards, there is no lag that currently bothers me.
I’m just happy this stuff all already works so well.
Okay dual boot working again and on same omega nightly from the 22nd and it looks like hdr10+ play as HDR and that’s when I get video freezing but perfect audio still
Very interesting. In previous posts, many of the content that had color bit issues were actually HDR.
I’m guessing there is no forced mode switch in these cases, and the weak auto cd/cs logic I described above is kicking into these cases, and selecting wrong color bit depending on user GUI resolution/refresh rate settings.
This user-dependency is impacting testing results, especially on non-DV or HDR content, showing inconsistencies even on the same build.
For HDR testing, I feel there needs to be multiple conditions to capture all the conditions of auto cd/cs. This is assuming 2160p and 23.976 content:
Resolution and refresh rate change (GUI set to 1080 and 60hz)
Resolution but no refresh rate change (GUI set to 1080 and 23.976)
No resolution, but refresh rate change (GUI set to 2160p and 60Hz)
No resolution and no refresh rate change (GUI set to 2160p and 23.976)
Resolution matching via the “Whitelist” does seem to impact test results. But maybe testing the 4x conditions above and verifying HDR/FEL/MEL color bit is set correctly on all 4 conditions is the first pass.
FYI. I found a corner case with DV playback and wanted to mention it.
It is very important that your TV and receiver, sound bar etc are fully powered on at the very least and probably set to proper inputs/outputs before either rebooting the box or powering on from a full shutdown condition. Otherwise it appears this can trigger a TV changed condition during DV playback, since the current codebase appears to be comparing current EDID to what was established during boot up in order to determine a TV changed condition.
I doubt this will occur after resume from suspend however so at least there’s that.
1 Like
@Portisch The new changes have made things worse. The video freezes on the BL_EL.mkv around 15 seconds in and the Power Rangers video shows a double image with a green bar at the bottom.
https://pastebin.com/raw/KBCBJvMf
This doesn’t solve this device’s CEC issue for me. Here’s what I’d expect it to do:
- Press TV remote power button to power ON
- TV Turns ON
- Receiver turns ON
- Press TV remote INPUT button and select “CoreELEC” (the AM6B+)
- AM6B+ turns ON
- Press TV remote power button to power OFF
- TV turns OFF
- Receiver turns OFF
- AM6B+ SUSPENDS
- Everything is now OFF
- Repeat
Here’s what actually happens:
- Press TV remote power button to power ON
- TV Turns ON
- Receiver turns ON
- Press TV remote INPUT button, and “CoreELEC” (the AM6B+) is MISSING
- Workarounds are either (A) manually turn on the AM6B+, or (B) manually set receiver to the AM6B+'s input.
- AM6B+ turns ON
- Press TV remote power button to power OFF
- TV turns OFF
- Receiver turns OFF
- AM6B+ SUSPENDS
- Everything is now OFF
- Repeat
Alternatively, I tried setting the AM6B+ to always stay on and never suspend, and it automatically turned my receiver back on over CEC even after disabling everything under Input > Peripherals > CEC, which should ensure that doesn’t happen.
CEC Power On and Input switching is critical IMO to this device eventually being usable in more people’s home theater setups.
CE-20 or CE-21?
Any “cut” log will be ignored.
CE-20 is going EOL so be sure to test CE-21.
For real debugging you need to enable video and audio/video timing logging as well.
Is FEL playback close to stable in CE21?
Are you saying we all should be focusing on CE21 or just for a specific issue?
I thought most of us were currently testing CE20.5
ok, guys. I did some extended testing:
hardware: Ugoos AM6b+, Sony A95L (2023 QDOLED)
software: latest CE 20.5 nightly 20240326
options: cd/cs auto; no whitelist
I tried two testfiles (fileinfo read via mediainfo):
Testfile 1: 3840x2160, 23,976, HDR, 4:2:0, 10 Bit File (UHD Movie Remux)
Testfile 2: 1920x1080, 23,976, SDR, 4:2:0, 8 Bit File (F-HD Movie Remux)
here are my findings:
first of all, I can repoduce the wrong color bug only on the first try after a restart. If I do a second try, the file plays fine.
Testfile 1 (UHD movie):
GUI set to 1920x1080, 60: wrong colors on the first play, second try works, TV receives the following informations on both tries: 3840x2160, 24, BT2020, YUV 4:4:4, 12 bit
GUI set to 3840x2160, 60: wrong colors on the first try, second try plays fine, TV receives the following informations on both tries: 3840x2160, 24, BT2020, YUV 4:4:4, 12 bit
GUI set to 3840x2160, 23,98: playback is fine on both tries, TV receives the following informations on both tries: 3840x2160, 24, BT2020, YUV 4:4:4, 12 bit
Testfile 2 (FHD Movie):
This file plays fine on all three GUI settings. TV receives 3840x2160, 23,98, BT709, YUV 4:4:4 12 Bit if the GUI is set to UHD resoltion and 1920x1080, 23,98, BT709, YUV 4:4:4, 12 Bit if the GUI is set to FHD resolution.
to sum up:
only the UHD file makes problems and only on the first playback after a fresh start of the box. with GUI set to 3840x2160, 23,98 it always plays fine.
my question is: why does the TV receive a 4:4:4 12 bit signal during playback of the FHD movie? shouldn’t it get the native 4:2:0 of the file with 10 bit color?
Edit: I will do the same testings with 21 nightly later
CE-21. How do I enable enable video and audio/video timing logging?
what does this mean?
When I play a HDR10+ test file I get:
4K23.976 444 BT2020 12b HDR+ 445MHz
This is not correct?
Under component logging settings.
Open player debug window while playing and what the vq: ??% (??%, ??MB) if it goes down to 0 while playing.
