Krypton colors are just beautiful on Nougat kernel. Or just normal. On MM kernel they look washed out.
Can you take a comparison picture with a camera?
Yes, the GUI it is faster on 8.0.1l-mm but colors are too dark. So I'll go forward with builds with Nougat kernel.
Hmm?
Are the colors washed out or too dark?
That is kind of a contradiction...
What is completely unusable?
The 8.0.1l-mm build?
...Or the regular Krypton Nougat-based builds?
Btw: Is there another alternative similar to Estuary skin? Estuary mod is really great but too slow on my box
I already ramped up the gpu which makes it a tiny bit more responsive but still too slow. It seems Estuary mod is made for more powerfull desktop systems, a more stripped down version of this skin would be amazing..
If you preferred the original Estuary design (before the big overhaul in which custom backgrounds are impossible), I can help you out...
I extracted the last good version of Estuary v1 and zipped it.
Just PM me if you want that zip... 
I used 8.0.1l-mm all day yesterday and I'm very close to finally replacing Jarvis on the NAND.
Thank you so much for building this MM Krypton koenkooi and kszaq!
There are still a few frame skips here and there triggered by opening the overlay or pausing, but that's ok - those do not disturb the viewing experience.
...I always use Unpause Jumpback anyhow...
I still had no time for UHD HDR testing, but I promise to do that within the next few day.
After testing a bit more, I need to adjust my initial report regarding two points:
1. The 7.1 pink noise on the rear channels can also happen with H.264 videos, it just seems to occur less frequently.
2. It looks like the additional delay is not present in Krypton (at least not in 8.0.1l-mm). I had forgotten that there is no advancedsettings.xml with a global 175ms delay for 23-24fps videos. After comparing to some DTS-HD videos, it looks like Krypton just has that global 175ms, regardless of the codec used. Confirmation pending, but both DTS-HD and FLAC seemed a/v-synced after inserting the advancedsettings.xml into the Krypton userdata folder.
8.0.1l with MM kernel (freshly rebased on latest LE kernel): Index of /s905/8.0.1l-mm/
1h 46min of high bitrate 1080p video via NFS, not a single drop or skip.
The Krypton bliss feels very near!
I'll do some UHD HDR testing later.
Turn on the samba sharing in Libreelec menu. Default in this builds is OFF.
Wow, this is embarrassing - I could have thought of that myself. 
I just did not think of it because the defaults always stayed the same during the previous builds... 
Anyhow - thank you.
My build finished: s905x build with MM kernel
8.0.1l with MM kernel (freshly rebased on latest LE kernel): Index of /s905/8.0.1l-mm/
Both your builds somehow mess up accessing the box via LAN in Windows.
I could always access all previous builds when I just entered the IP in the Win Explorer (\\xxx.xxx.x.xx) - to copy tar files in the update folder.
That's not possible with either Krypton MM build.
I got around it by accessing the mSD via my NAS, but I assume others might not have that option...
Is there maybe some way I can define a delay for FLAC only myself?
No, not yet.
I tried to search for "subtitle" and "skip" in the forums, because I wanted to make sure there is no report yet (judging from the issue apparently being fixed in Leia).
However, I did not find anything, so I will report it.
Can you give me a hint of where to report the bug?
Would "Video Support" be the correct subforum?
Kodi Community Forum - Video Support
I was wondering if it is maybe possible to import the fix from a Leia Alpha?
As I said, I do not have these subtitle skips in my Leia Nightly build in Windows, I could also test a Leia Nightly for the Pi if that helps.
Unfortunately I don't know when and how it was fixed - maybe you (or someone) can make sense of the Leia Nightly history log?
My build finished: s905x build with MM kernel
I only tried one thing last night with that build - I tested for frame skips.
It looks good, the high bitrate movie played for 1h 8min via NFS and there was no frame skip.
So far, so good...
[hr]
8.0.1l with MM kernel (freshly rebased on latest LE kernel): Index of /s905/8.0.1l-mm/
Thanks kszaq, I will do some testing with that build too.
[hr]
nougat kernel based librreelec is best in picture quality...but latest mm kernel based libreelec is best picture quality?
Why don't you compare and decide for yourself? 
what is difference between nougat based and mm based kernal libreelec?
Well, this bug report is about banding in 10 Bit sources.
10 Bit sources look infinitely better with the MM kernel.
[hr]
Even though you don't see conversion banding, it's still not "functional HDR" as said earlier. For true HDR output, you need to use Android. This could be done with a separate device or by dual booting.
I was mainly referring to those black screen signal losses you currently have in Krypton when playing UHD/HDR content when I said "functional HDR".
I know that HDR is not being output 1:1 as it should in 7.0.3.012j, but it looks fine to me. Not too different from the TV's internal media player to be honest.
Do you know a good Android build I could test on Mini M8S II?
The one that was initially installed on the box is horseshit.
1. FLAC introduces an additional delay (compared to DD/DTS).
I think it is around 175ms. Others should test that number to make sure.
2. Most of the time, starting an x265 movie with a 7.1 FLAC audio track triggers awful scratching/hissing noises on the rear channels (like pink noise) and a beep in the beginning (and after skipping).
My speaker setup is 5.1. The AVR downmixes 7.1 to 5.1.
TrueHD and DTS-HD 7.1 tracks are properly played as 5.1 without any noise on the rears.
I assume there might be an error within the (rear back channel) FLAC decoder?
Device type:
S905X
Build:
7.0.3.012j and 8.0.1l
Device:
Mini M8S II 2GB/16GB
How to reproduce:
1. Look for a/v-sync in the attached samples.
2. Unfortunately, short samples don't trigger the noise.
I can only reproduce it with a full length movie.
However, I included a log of the event.
Samples:
I added different FLAC samples for the delay.
FLAC testfiles – Google Drive
(Folder includes four 30s samples: FLAC 16Bit 5.1, FLAC 16Bit 7.1, FLAC 24Bit 5.1 and FLAC 24Bit 7.1)
Specs from log audio:
Audio
ID : 4
Format : FLAC
Format/Info : Free Lossless Audio Codec
Codec ID : A_FLAC
Duration : 2 h 27 min
Bit rate mode : Variable
Bit rate : 1 475 kb/s
Channel(s) : 8 channels
Channel positions : Front: L C R, Side: L R, Back: L R, LFE
Sampling rate : 48.0 kHz
Frame rate : 10.417 FPS (4608 spf)
Bit depth : 16 bits
Stream size : 1.52 GiB (6%)
Title : English FLAC16 7.1
Writing library : Lavf57.72.101
Language : English
Default : Yes
Forced : No
Support logs:
Attached.
That sounds amazing! (Assuming the patches from afl1 are included in 8.0.1l...)
Thanks for trying that, I'm looking forward to testing it.
Actually people report something opposite: better colour reproduction...
I have yet to see any quantifyable evidence of those claims...
There is no difference to me in content and I can't make out a difference on the Spears&Munsil pattern.
...and no issues with Live TV thanks to updated decoders.
I understand that of course. I don't use Live TV so I have not encountered any Live TV issues either.
Yes, I know.
This is why I also said this:
I am aware that this has been known for a while, but I still thought it makes sense to have a proper bug report thread for this.
Maybe this can be forwarded to AMLogic somehow?
It is just one of the things which makes we wonder:
Do you have to use the Nougat Kernel in Krypton?
As far as I am concerned everything simply works better with the Marshmallow Kernel.
No frame skips, smooth 10 Bit output, functional HDR - you name it...
Is there anything essential that the Marshmallow Kernel can't do?
Would it be possible to build Krypton around the Marshmallow Kernel?
Edit:
Sorry I read your post too fast...
Is 8.0.1a using the Marshmallow Kernel?
I deliberately chose a simple Blu-ray encode I made myself to avoid noise, i.e. limit this bug report to the 10 Bit issue only.
Your file introduces 2160p, BT.2020 and HDR10 (ST 2084) as potential additional noise factors.
However, the banding is very obvious in your sample too - in Krypton only. Jarvis again shows no banding.
Also, your file shows all kinds of issues in Krypton, none of which are there in Jarvis.
Signal interruption (black screens), weird bright dots...
Again, this is why I chose a simple 1080p BT.709 encode.
On a side note:
There is no way to circumvent AACS 2.0 from a UHD Blu-ray.
This PE2 sample must be a capture and in no way represents actual UHD HDR content.
I would recommend to stick to official sample files (LG, Samsung, Sony) to show UHD/HDR related issues.
