yes known problem, official drivers do not compile at kernel 4.9 - so nothing i can do till they fix their drivers (the oss drivers that i use have no support for v7)
Which error do you see? I tested the official drivers successfully about two weeks ago using this package.mk.
It may look familiar to you as it is "borrowed" from your GitHub repository.
Maybe checking udev's knowledge about the partitions gives an idea:
udevadm info /dev/sda1
udevadm info /dev/sda2no the 4.8 patch had a lot merge conflicts also without the tbs patch (at least milhouse told so)
Yes, it looks like the DVB API is changing on every mayor kernel release. The patch must match the kernel version. I can nearly promise the 4.9 patch will not work on 4.10 - but the 4.10 patch is already WIP.
But why does it work with less than 8.388.240 MB without any problems. I dont know the exact value when it is overturning but it must be between 8.388.240 MB (working) 8.399.999 MB (not working).
The device size is detected different (and you swapped the two log files 
1022 dmesg log:
[ 9.840137] sd 0:0:0:0: [sda] 17581277184 512-byte logical blocks: (9.00 TB/8.19 TiB)1031 dmesg log:
[ 9.733719] sd 0:0:0:0: [sda] 23441768448 512-byte logical blocks: (12.0 TB/10.9 TiB)But I have currently no idea what is causing this.
Ah yea, 4.8 uses a dd bridge patch from 3rd party, that won't work at 4.9 and was dropped. Looks like 4.9 don't support your card completely
The ddbridge patch for 4.9 is working fine on my DD Cine CT V6 with my private build. Unfortunately it was conflicting with the TBS driver patches that has been added to the LibreELEC 4.9 kernel and could not be updated.
As the TBS driver patches are removed in the meantime I will PR the ddbridge patch again the next few days.
That does work, but it causes other problems. With the ethernet device no longer managed by connmand, the DNS configuration can't be changed because it's hard coded into the systemd unit file for the connman service. DNS1 and DNS2 get set to Google's DNS servers.
cp /usr/lib/systemd/system/connman.service /storage/.config/system.d/And edit the file in /storage/.config/system.d to your needs.
Next I tried the following autostart.sh file:Code# Kill lirc remote services systemctl stop eventlircd.service #start ir-keytable ir-keytable -c -p RC-5,RC-6 -w/storage/.config/rc_keymaps/myremote
eventlircd must not be stopped in autostart.sh when changing key tables.
The remote can be tested with evtest from the system-tools addon:
systemctl stop kodi
systemctl stop eventlircd
evtest
Select the remote's /dev/input/eventX and start pressing keys.
22:38:36.806 T:546425532640 INFO: ffmpeg[7F397FF0E0]: Stream #0:0: Video: h264 (High 10), yuv420p10le, 1920x800 [SAR 1:1 DAR 12:5], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)22:38:36.808 T:546425532640 NOTICE: Opening stream: 0 source: 256
22:38:36.808 T:546425532640 NOTICE: Creating video codec with codec id: 28
22:38:36.808 T:546425532640 DEBUG: FactoryCodec - Video: amcodec - Opening
22:38:36.808 T:546425532640 DEBUG: FactoryCodec - Video: amcodec - Failed
22:38:36.808 T:546425532640 DEBUG: FactoryCodec - Video: - Opening
22:38:36.808 T:546425532640 NOTICE: CDVDVideoCodecFFmpeg::Open() Using codec: H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
22:38:36.808 T:546425532640 DEBUG: CDVDVideoCodecFFmpeg - open frame threaded with 6 threads
22:38:36.809 T:546425532640 DEBUG: CDVDVideoCodecFFmpeg - Updated codec: ff-h264
22:38:36.809 T:546425532640 DEBUG: FactoryCodec - Video: ff-h264 - Opened
No HW support for H.264 High 10 video and CPU too slow.
The WMV3 issue looks like a driver problem. When it is fixed upstream it will be part the next releases.
A search on freedesktop.org shows two bug reports this year: 96600 – [RV630]: a lot of artifacts appears on a screen playing some videos through VDPAU with hardware acceleration and 94381 – VC-1 VDPAU decoding on radeon causes occasional garbage.
However the three samples from the bug reports play well HW accelerated on my AMD C-60 netbook with 7.90.009.
What is your Kodi settings level?
Being "Expert" there is an additional "Video calibration..." below "Calibration". Furthermore you can disable VC-1 VDPAU acceleration only in player settings.
Why do i want to do that?
It works now so why change it?
... after the next release. This disables the new default Radeon xorg.conf too and avoids building LE yourself.
Currently i just removed the patch responsable for this and compiled a new build and this resolved it also.
In this case just put an empty xorg.conf in /storage/.config
Did you use w_scan with parameter "-t 3"? May not help but is always a try worth.
You can try to switch to legacy drivers yourself:
Have already thought of that, things is that Windows apparently is now 100% ready for UTC time, so I'd rather switch my Linux boots to RTC.
Which issues still do exist in Windows 10?
I guess it may be possible to symlink the required directory to be able to modify the clock setting.
Only if you build LibreELEC yourself.
In addition with local time set all three OS will try to correct the RTC on daylight saving time change.
IMO not possible due to read only /etc file system.
Think about changing Windows to UTC.
Currently a LibreElec backup is just a tar of /storage/.cache, /storage/.config, /storage/.kodi and /storage/.ssh
Video on HDMI #1 and sound on HDMI #0?