Posts by chewitt
-
-
Restricting to localhost wouldn't make sense for the intended use-case with LE.
-
Have you defined a whitelist of resolutions that Kodi should use for "adjust refresh" playback? .. this is new in K18.
-
TX3 is fine for most media. I have the 'mini' version for mainline kernel testing with the VFD driver. For $16 it's a nice box .. the dreadful WIFI chip is the only 'bad' thing that I could find with it and that's easily fixed with an external USB chip. The mini version doesn't support 5GHz wifi and BT though so those could be more general issues. NB: I can't comment much on current 3.14 kernel LE or Android performance as I've only ever used mainline kernel Amlogic LE images on the box.
-
The add-on server has rules that allow access from LibreELEC clients. Web browsers are not LibreELEC clients.
I'm not aware that add-on downloads are a general problem - and if the server was problematic we'd see more reports of problems. At the moment there is still a single server located in Germany that hosts all the files and we haven't mirrored them like we do with distro images. Our user numbers have grown quite a bit in the last year though, so it might be time to think about mirroring or adding a second server somewhere else.
-
The legacy security option is visible when SMB1 is set for min/max. You need to configure this in Kodi SMB settings not the LE Samba settings (which are for Samba server, not client).
-
To distract attention away from the pointless he-said/she-said "who bakes the better biscuit?" discussion. Here's something for S912 users:
The current lack of text in the GUI means it's hard to prove K18 is using panfrost with mesa-18.3 on 4.19.12 kernel .. and that this is the 20 second gap between OOM errors (it's buggier than a BBC documentary on Insects) .. but progress is progress
Corroborating logfile for the unbelievers http://ix.io/1xur
Happy New Year folks .. keep it up(stream) and open-source!
-
USB audio cards should just be auto-detected by the kernel. Worst case if there's a kernel option missing it can be added.
-
Klojum look at add-on config/option .. the root password is auto-generated and visible there (along with the Kodi user).
-
The SSV6051 wireless has an awful driver (the code is hideous) and since the company that produced it has gone bust it's unlikely to ever improve. It will definitely NOT be supported once we bump to mainline kernels, so perhaps invest in a USB external device if you really need wifi.
-
Lets Encrypt has no requirement for working reverse DNS records. It only requires the A/CNAME record that's used in the cert to be correct, and the webserver to allow access to a temporary folder that's accessed to validate the host during the cert registration/renewal process.
-
Kodi uses the smbclient from Samba which defaults to SMB2, so if you enable min SMB1 and max SMB2 it will use SMB2 and you will not be able to access your SMB1 share. To force SMB1 you need to set min/max to SMB1. You may also need to enable the legacy security option; depending on how ancient the SMB code is in the router.
-
Yes, Intel are arseholes for requiring Windows to update firmware. Yes I said firmware. AFAIK the BIOS/firmware are the same thing on a NUC.
-
Yes it is possible to multi-boot an x86_64 device with LE as one of the OS. It's not something we support in our installer though, so you'll need to do a manual install and figure out the sequencing and bootloader bits yourself.
-
Update the NUC firmware. Update the Marantz firmware. Update to the current LE beta. Make sure "sync playback to display" is off.
-
Clean install the current beta. If necessary do a selective (manual) restore of DB files from a previous install .. but you need to lose all the addon cruft that OE added else all we can see in logs is the entire Kodi language addons set updating. I'm sure there's some vide playback in the log somewhere, but I gave up looking for it.
Once you have a clean install .. retest and if necessary run "cat /storage/kodi/temp/kodi.log | paste" and share the URLs
-
udev rules are cummulative so you can add a rule to /storage/.config/udev.rules.d/ that matches on label/uuid and runs fsck on the drive. This will then be a persistent behaviour that is done on each boot.
I'm not sure what the match criterial look like in a rule so you'll need to Google a bit, but the following commit shows a similar rule that matches on HFS+ filesystems and fsck's them so the rest of the rule will look similar:
-
I didn't look (and have no plan to either) but I doubt it's wildly different. Despite all manufacturers claiming their product is unique it's in their own interests (for software support) to not diverge far from the reference designs.