Intel Linux drivers have no HDR support. Kodi (v17) has no HDR support. Short of a miracle, you're not going to make HDR work. Linux drivers are evolving and Kodi (v18) is adding HDR support. In the future, it would work. Right now, no.
Posts by chewitt
-
-
The update back-end is currently hosted on the same server that hosts the main website and a few other things. The plan was to relocate the update function to another box, and most backoffice things are also moving from .tv to our .net domain. The update move worked when first done, but the server has issues and appears to have stopped responding properly - but wasn't noticed. All that's been done is the DNS for .tv was moved back to the old server which was then updated with 8.2.3 update details. All the certs we use are from letsencrpt but a few things like the website/forum are fronted by cloudflare who sub their own certs instead. At some point in the next week or so the issues on the new server may get fixed and the DNS will move again .. aka "nothing to see here, move along please"
-
Please provide a Kodi debug log. System (dmesg) shows nothing about Kodi.
-
Unless you tell us what that change was, we have no idea.
-
Debug log please. The one you posted is a normal log.
-
There is no support for using the mic in BT remotes on LE because there is nothing native in Linux to process the audio stream (or redirect it to somewhere for processing). It works under Android because Android has an OS-level API for voice processing.
-
It's based on information from the videos database. If there's an issue with running the query that builds content for that view, it will be visible in a Kodi debug log.
-
No specific plans for that device, but as long as SR have based OS support on a mainline kernel it shouldn't be that hard to support. As long as the drivers follow the V4L2 direction we're moving towards the iMX8 SoC should be supportable under the newer Kodi graphics architecture that we have been working on.
-
Same model Samsung in both locations? .. it wouldn't be the first time Samsung pushed a firmware update that broke CEC for people.
-
start with sharing the full debug log that goes with the crash
-
look at /storage/.config/samba.conf.sample for the default shares list, rename to samba.conf and edit (and reboot) if you want to edit the list
-
auto-mounting is done using udev and user created udev rules can be placed in /storage/.config/udev.rules.d/ to make them persistent if not truly permanent (which would require creating your own image). udev rules are applied in alphanumeric sequence so a rule numbered +1 higher than our default auto-mount rule can be used to remount the mounted USB with 'ro' set.
this will still not prevent anyone from READING the data from the USB which is what the OP has stated (twice) as the problem.
-
-
Next step is to use a current milhouse (Leia) release. If the issue is still present, then we start looking for where the bug is.
-
-
It might be possible to support that SoC, but it's not mentioned in current Amlogic documentation and we have enough issues supporting the stuff that is, so I don't see if leaping onto our agenda.
-
You can block writing *to* the USB drive (using the command I posted before) but once the USB device has been mounted you cannot block reading or copying *from* the USB drive. LE has a single user, root, who can access anything.
-
This USB dongle has a Mediatek MT7610U chipset. There are only vendor provided drivers available (nothing in the mainline kernel) and their quality is best described as crap (and I'm being extremely polite about the code). Until Mediatek get their sh1t together and upstream a proper driver to the Linux kernel, or someone in the open source community does the work for them, we will not support it.