There are a myriad of reasons why "streaming providers" will cause issues. Unless you reveal exactly which streams and providers you're talking about and provide Kodi debug logs that demonstrate what issue Kodi is having there is no point in debating the theory of reasons why things don't work. Of course, if those are pirate streams from IPTV services, you (and we) know why quality is sh1t and you don't need to bother replying.
Posts by chewitt
-
-
/mnt/md1/Users/AlexGilbert/Media/Videos looks like the internal path on the server which is probably not the network visible path. It's technically possible to create a share path like that, but normally an SMB/Samba server would create something like //192.168.1.92/Media/Videos so it looks unusual, and unusual often means wrong.
-
Win10 (which has been updated by MS to disable gues/anon access) is using SMB3 with authenticated access. You need to use LE 8.2.3 and you need to configure Kodi to use a user/pass when connnecting to the WIn10 shares. If you don't authenticate; access is not allowed to the shares. It's a well known problem with people who don't read release notes.
-
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.
-
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.
-