Posts by chewitt

Quote from TheSwede86

You don't think an online petition would help?

The number of users with an S912 device is statistically insignificant as a percentage of our total userbase and our entire userbase (including all the pi users, NUC users, etc.) is statistically insignificant against the number of "Kodi on Android" devices with an S912 chip that work fine. The sum of money involved to license all S912 chips produced is non-trivial so I don't see a compelling business case that would suddenly make Amlogic have a change of heart. You're welcome to do something if you want, but in the grand scheme of things I don't see this helping.

Current testing has been done on RK3328 and RK3288, not RK3229, and there are no official releases for any RK devices. The proof of concept images for TinkerBoard etc. that are in circulation using Kodi Krypton are now discontinued as the developers working on RK support switched to Kodi Leia in recent weeks, i.e. there will be no further improvements/updates to the Krypton images.

block devices detected by the kernel are automounted via udev, e.g. /usr/lib/udev/rules.d/60-block.rules

Quote from funabashi

But what about other solutions like DLNA or UPNP?

Neither of them are "casting" protocols which is what you are asking for, and there are no broadly supported open source "works on all devices" casting protocols available, which is why Kodi hasn't evolved support for them. If/when that changes, Kodi will change.

Create a DHCP reservation for the NUC in your router so you can predict what IP it receives. Now create a USB and install LE normally (to USB or HDD it doesn't matter). After install it will boot and you end up with a black screen, but this is normally an Xorg issue and not a total failure to boot the core OS. Now SSH into the box's IP and run "cat /var/log/Xorg.0.log | paste" so we can see why there is no display. I have a hunch that this is an Xorg modeline issue.

It's a perfectly stable beta release though, and my comment is more directed at your moaning about being unable to collect logs off the box due to your broken samba configuration which is (from our perspective) a self-inflicted problem.

Current intention is 8.2.0 once Kodi 17.5 is released.

Two suggestions if there is no "network" solution to the stupid ISP:

#1. Get an RTC board for the pi so that date/time is remembered over reboots and doesn't have to depend on NTP updates.

#2. Try setting the router IP as an NTP source; as some/many routers will respond to the request. As long as the router's internal clock is fairly accurate on current time the pi will get a time/date that's close enough for YouTube etc. to work and you have a workaround. You can also get an NTP server app for other machines in the house Win/Linux with a persistent (if not accurate) clock to pull the same trick.

Quote from Daz

Do you guys think we'll ever get proper fbdev Mali libraries?

No. Never. Amlogic has no commercial interest in paying a large amount of $$$ to appease the small number of Linux users hacking their Android product. It sucks for us, but if I were them I'd probably make the same business decision so I don't blame them.

Quote from ChimeyJimmey

Full HD? 4K?

1080p works. 4k is unlikely to ever work for a variety of technical reasons and (even if those get solved) the majority of far-east made Amlogic boxes ship with a widevine L1 license not the L3 one required to make it work.

The normal issue with NTFS drives not mounting is the filesystem being in an unclean state after users literally pull the drive instead of doing a "safe eject" in Windows. This is detected by Linux and the kernel refuses to mount the filesystem to avoid damage. If you reconnect to Windows and run chkdsk.exe over the drive and then safely eject it will probably mount fine.

That generation of NUC supports 10-bit HEVC but fixes for HD audio passthrough are not in current LE releases, because while the available fixes work great on the latest generations of NUC they also break stuff on older generations. Things are resolved once the kernel bumps to 4.13 or so which is available in milhouse dev builds (future LE 9.0, although we are nowhere near alpha releases at the moment) and some other community images found in these forum. The LSPCON internal DP > HDMI design decision attracts pissy comments because it's taken Intel a huge amount of time to recognise and then fix the audio problem (more than a year).

Install the system-tools addon

8.1.2 is a beta release, logs are in /storage/.kodi/temp/ and enabling debug in Kodi gives more info if the issue is with Kodi. And if people don't read release notes and don't update incompatible customised Samba v3 config it will not be used in 8.2 releases that detect and ignore the incompatible config.

The newly appeared GH branch is missing some major functional parts at the moment (audio and hardware acceleration) and we have no visibility on Amlogic funding that development with their contract developers (it's not us). The branch exists because we are working on graphics elements between Amlogic, Rockchip, and others that need us to be experimenting from a newer overall codebase.

LE 9.0 does not exist yet, so I suggest you stop running unreleased pre-alpha code and use the released/stable LE 8.x image that works.

There's a ton of variables involved so you'll need to share a Kodi debug log so we understand hardware used and codecs etc. for the stream.

It's hard to comment. The Windows download is the most popular for the app and these days the majority of users will be using Win10, so quite why you've seen issues is not known. Overall we see very few issues reported.