Hello everybody,
koenkooi : How can we apply this patch ? I have the same issue since the update to 8.1.2, my windows share (without password) doesn't work. I tried the jg555 solution but i didn't find the smb.conf to modified.
Thank you for your help.
PS : un special thank you to kszaq for this builds
The latest build from kszaq already has it, but if you have an existing /storage/.config/smb.conf you'll need to update it manually.
Display MoreAs far as I know, the samba used in libreelec 8 and higher should support SMBv2.
Not sure if 7 aka jarvis has at least samba 3.6.
8 has samba 3.6.25 and since 3.6 it supports SMBv2.
You could put this in a custom smb.conf "
server min protocol= SMB2".That should in in theory make samba use SMBv2 as minimum.
PS SMB3 is added since Samba4, I sure hope that will be added in soon tho.
Or atleast in libreelec 9 (leia).
LE 8.1/8.2 and master have a patch to backport the autonegotiation from samba 4.7: samba: backport default to SMB3_11 from Samba 4.7 · LibreELEC/LibreELEC.tv@d48c3d8 · GitHub
So if you have no 'min' or 'max' protocol in your config it will try to negotiate smb3.11 first and work down the list on failure.
Try an 8.1.x/8.2 build, that has a much improved smb performance.
Yes, I know that of course.
However, have you ever seen a 15m cable that got the Premium label?
The only ones I have seen in Germany max out at 3m and cost a hilarious 60€ at that length...
Allekabels.nl has premium certified at 6m for €40, but not any longer ones. I wonder if that's a cost or electrical issue (or both).
Hmmm this is what I feared...
15m cables are almost never capable of those bandwidths.
Have you tried to use a short (3m max), good HDMI 2 cable directly between box and JVC?
FWIW, there are no such things as "HDMI 2.0" cables. The only thing the HDMI alliance does is specify a 'premium' label (with QR code so you can check it yourself), which in practice means it works for 2.0, because it was actually tested.
So far all three premium cables I bought work great with 4k60/444, the non-premium "2.0 + ethernet cables" are hit and miss. They are sadly 3 times the prices of regular cables, though 
That's probably it. My TV's internal player does not exhibit banding though. Is dithering supposed to be turned on?
I'll just post the clip again.
hdr_banding.mkvTo all the people with an HDR capable set:
Play this file and please report back whether or not you can see banding artifacts within the white gradient.
I don't see banding, but I do see some form of slim vertical stripes which I think are dithering artefacts. I had to walk up to the TV to see those, though 
can a s905x handle x264 4k/60fps video? i've tried all the big buck bunny 2D files. it can play them properly except for the 2 videos below. so i think it must be a hw limitation
bbb_sunflower_2160p_60fps_normal.mp4
bbb_sunflower_native_60fps_normal.mp4
It can, it was fixed in a 7.x kszaq build a while ago, but recent kernel/kodi updates might have changed that. But yes, plain s905 is better at h264 than s905x.
KERNEL_VERSION="4e39713" s
kindly send the link of this kernel KERNEL_VERSION="4e39713"?
[TESTING][S905(X)] 10bit/HDR/Dithering Test Builds & Discussion
I have a new test build I'm not updating OP with because it's very experimental and the last build is in a good state. You can use the linked device trees from OP.
Changes:
- A very experimental buffer change in an attempt to improve the frame skip situation.
- A hdmitx change that may improve compatibility with some AVRs (to be tested by those with 4k output on their TVs but not AVRs).
A build with KERNEL_VERSION="4e39713" still gives me frameskips on h264/4k. But I only have a single movie using that and I can't see any visual difference between the 4k version and the bluray I can't say I care a lot about this bug 1080p h264 works great, as does 4k h265.
There still are frame skips, but it depends on the media type. I have a very experimental buffer change that has reduced frame skips from my testing. I still need to get a h264 4k test file as a benchmark (all my 4k media is h265).
30s h264/4k clip: deadpool-001.mkv
Have a look at Autostart.sh - OpenELEC , that explains about autostart and links to how to access it through windows via samba.
I'm very interested to know if this fixes the issue for you. Unfortunately the hpll reg testing for the output issue hasn't been going quite as smooth as I'd hoped.
I did a build with KERNEL_VERSION="b05cd25" and the following cherry-picks from your tree:
+ 2b5bbfb661fb6ee7603ed584c76ba35a78dc8510 S905: update audio config and patches
+ e0d87740a4c7ef327ca3d9bb915546be0f571a24 S905: use custom test kernel
+ 1ac55183798d10b148c207527b856acd65d519bf projects/S905: set same mode during switch
+ 129ed2cd207b226e22bf398066fc96e72fc4ab0d kodi/patches/amlogic: @afl1 lateframes patch
+ 25cc0edccc5591646158874fa9f9c0bf1ec9e72b Revert "projects/S9*: fix BBC H.264 DVB-T"
+ c852260023320f9d2bb42c3a853b5455d63844c5 S905: bump kernelWith GUI set to 1080p50 and having done echo '444,10bit' > /sys/class/amhdmitx/amhdmitx0/attr all the previously mentioned issues are gone. I get artefact free and skipless playback on 'passengers', 'lucy', 'PE II' and web-dl content.
However, I did notice an issue with 4k h264 SDR playback ('deadpool'), a lot of frameskips there. I went back to your previous hybrid nougat/mm kernel and frameskips are worse there, about double.
All in all this seems to be the best 4k/hdr configuration so far, good work!
Thanks for updating your github! The new HDMI cable arrived so I can properly test 4k without worrying about that now
You're right, it is stuck at 5 (SDR8 output) on anything other than GXM. I got HDR10 with a test file but didn't see it had HDR10 metadata. Thank you, my mistake.
koenkooi It's built with the latter. I forgot to push the LE kernel bump.
Good, then I've built and tested the same kernel 'echo 444,10bit' still gives me various issues, including a new 'resolution error' on the AVR. But like jd17 I'm going to wait for new HMDI cables to arrive before drawing any conclusions. So no real testing till tuesday evening, sorry.
I did notice that 'echo 422,10bit' falls back to 422,8bit on Passengers and the Smurfs according to my AVR.
Uploaded a new build in OP. Changes:
- Removed "output_rgb" interface completely since it's redundant (see OP).
- h264 dolby vision support (nougat backport)
- Fixed too high of contrast (nougat backport)
- New white balance module (nougat backport)
- A few HDR fixes (nougat backports)
- Added section in OP on dolby vision.
Is this built with KERNEL_VERSION="6b34aaf" or KERNEL_VERSION="65c65db"? The changelog implies the latter, but your LE repo says the former.
Some more digging into 'regular'/SDR content, with KERNEL_VERSION="361e832":
Here's the log file for a frameskipping video, after doing 'echo 422,10bit > /sys/class/amhdmitx/amhdmitx0/attr ; systemctl restart kodi'. For future logs, LE has 'pastebinit' builtin:
m8s:~ # cat ~/.kodi/temp/kodi.log | pastebinit
http://sprunge.us/LgfXI still haven't replaced the HDMI cable, so saying that PEII still makes the AVR say 'no signal' is a bit useless.
Display More[..]
Without:
[..]
I also recommend you set a 1080 GUI to use your displays upscaling on 1080 media. It will change to 2160 on 2160 media playback. The 2160 GUI is just poorly upscaled from 1080 anyway.
[..]
After:
Pe II: I'm assuming your GUI was set to 50hz? I have a workaround on it's way to go back to always setting the mode. Long term this could potentially go back in the kernel to do so on colorspace change only.
I have my GUI set to 1080p50 after discovering that 2160p is worse due to scaling. I'll try to do the tests you suggested this weekend.
Without echo '444,10bit' > /sys/class/amhdmitx/amhdmitx0/attr
PE II: Vertical banding in sun during intro, AVR says ‘YCbCr420, 24 bit’
Passengers: OK, AVR says ‘YCbCr4444, 24bit’
1080p24 SDR: Tons of frameskips
After echo '444,10bit' > /sys/class/amhdmitx/amhdmitx0/attr
PE II: TV says “no input”, AVR says it does have input
Passengers: white dots in picture, audio glitches, AVR says ‘YCbCr444, 30bit’. Could be cable related.
1080p24 SDR: Tons of frameskips, AVR says ‘YCbCr4444, 30bit’