No debug log .. no problem
Posts by chewitt
-
-
No idea about the AMD stuff, I have always avoided their hardware. GeForce 7025 requires an image that contains the old 304.xx nVidia driver, see here: LibreELEC builds with nVidia 304.xx driver
-
Is "Neptune" a build? if so, you can't get any support here
is installed which means "off sod" rearranged into a less polite sequence
-
Running "cat /storage/.kodi/temp/kodi.log | paste" will generate a URL to share the log, but you probably need to enable debug logging and demo the problem by navigating the GUI, which will require you to sit in-front of the box.
-
No RK add-ons will be built until RK support is merged into our master branch. Then the repo will get built and populated. The workaround is self-building the add-on(s) you need based on the unmerged code.
-
-
Search for vpeter's version of 8.2.3 for Cubox with a 3.14 kernel and see if that improves things.
-
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.
-
/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.