Posts by chewitt

    The reason the SSV6051P driver works on the RK BSP kernel (and current Amlogic BSP kernels) has nothing to do with RK having better open-source compatibility. It is simply due to RK using an old kernel. I forget the exact kernel version where things break, but once you move beyond Linux 4.11 or 4.12 there are major crypto API changes and the driver no longer compiles. If you're lucky RK might task one of their internal devs to rewrite it at some point, but IMHO that's a long shot.

    Support for "SMB browsing" only exists in the SMB1 (NT1) protocol which is now deprecated almost everywhere due to the huge number of security issues it contains. There is no native support for browsing in SMB2 or higher, it's not part of the protocol, you have to use an entirely new discovery protocol (ONVIF). "under the hood" Kodi uses the Samba smbclient which does not include ONVIF support, so once you start using SMB2 or SMB3 (the default in Kodi v17 and up and all current versions of Windows) there is no support for browsing. If browsing is essential, i.e. you're not capable of learning an alternative way of doing things, you must downgrade all your 'server' devices to SMB1 and then force both min/max SMB protocol support in the Kodi SMB client to SMB1. Then everything speaks SMB1 which supports browsing. If you choose the sensible option and keep your devices on SMB2 you just need to configure things properly (once, in sources.xml) and that should be it. As a rule anything you serve media from should be on a static address (via DHCP reservation in the router is easiest) and then you can configure sources using an IP or a hostname. As long as something on the network is a master browser the names should resolve. At least, that's my personal experience. I set sources.xml once ~8 years ago pointing at a device called MEDIABOX and haven't changed it since (the box has changed, but the share names remained the same, so no reason to change clients).

    If the script dumped things in the configured locations /storage/.config/argononed.conf will contain something like:

    55=10

    60=55

    65=100

    Left value is temp in ºC and right value is percentage of fan speed. So change values as you like and then reboot or restart the argononed systemd service, e.g. "systemctl restart argononed.service" to effect the change.

    Then rejoice that fans in cases are totally unnecessary (and suck for HTPC devices) and put it back to normal so you can't hear it.

    Two comments:

    a) I don't see this behaviour myself with 4K HDR media. For reference my config.txt is here http://ix.io/28WU .. note I don't bother forcing the ability to output in 4k@60 because I don't posess any 4k media that runs at 4k60 apart from test files and the "up to 4k@30" support covers [email protected] which works fine, and like all the ARM devices I posess, the GUI runs best at 1080p anyway.

    b) Development is focussed on the future GBM/V4L2 migration and moving away from the legacy 4.19 kernel and MMAL initial release compromise that's being used in LE 9.2 images, so even if there's a confirmed bug it's unlikely to be investigated and resolved.

    Microsoft stopped Workgroup support in Windows 10. What is the current solution to the Windows name resolve issue? It doesn't seem to be working out of the box.

    /storage/.config/hosts.conf .. which is applied to /etc/hosts on boot?

    Browsing is gone and needs Kodi to think about adding support for ONVIF etc. but that will probably not happen until a more general refactoring of Kodi SMB support takes place. It's stinky fragile code so there's a long-running shortage of volunteers to touch it.

    Code
    [   12.803948@1] libphy: stmmac-0:00 - Link is Up - 1000/Full

    ^ kernel boot to network 'up' is 12 seconds. For reasons unknown connman then reapplies the configurations which takes you to 14 seconds. If you delayed start until the network is up, Kodi takes a few more seconds. So 20 seconds sounds about right.

    NB: Using an experimental mainline kernel image the time before Kodi starts is quicker but it's not a massive improvement. If you correlate events between http://ix.io/28WS and http://ix.io/28WR it shows boot is still about 12-14 seconds. The A53 CPUs in S905 devices are not particularly quick.

    Once the KMS driver supports 10-bit output (almost there) HDR comes within reach; although most HDR media is HEVC and under GBM/V4L2 the HEVC support is still at a fairly experimental stage. RPi4 is an unusual SoC becuase H264 (the same IP from previous Pi generations which we've had working for a while) follows the stateful API while HEVC (new IP from another Broadcom chip, with all new code) follows the stateless API. Making it all work together (including the FFMpeg side) is uncharted territory. The first step is making something work. Then we have to make it work reliably. Then we have to get the code upstream (Royal 'we' .. the Pi Foundation folks). TL/DR; don't hold your breath just yet :)

    If we turn our anti-spam defenses off to appease you (one user) we get overwhelmed fairly quickly by a ton of spam which pisses off all the moderators and staff of the project (many users) who support our userbase (several hundred thousand users). If we have to lose one user to keep everyone else happy .. sorry but we're not changing. This project is non-profit. This forum doesn't track anything. There are no advertising tools. /shrug

    "Support" in that context means you can boot the board. There's a ton more code required to get a functional media device!

    Overall I am very happy to see a mix of the Pi Foundation staff, several core subcontractors they hired, and numerous names from the Pi ecosystem (including some of our own contributors) writing and upstreaming code to the kernel right now. The previous Pi architecture ended up being largely "out of tree" because when the first Pi launched in 2012 the folks who wrote the code were (in their own words) pretty ignorant about kernel things and the business priority was on shipping a working product. Over time their upstream awareness grew but the success of the Pi meant the task had become exponentially larger and still being a charity with a small staff the priority remained on shipping a working product. RPi0/1/2/3 are now super stable because the codebase has been iterated continuously and attentively over a period of seven years. RPi4 is being treated very differently. The benefits of being and business need to be "upstream" are very clearly understood now, and to continue the stratoshpheric success of Pi hardware the new shiny needs to mature a tad quicker than seven years. Lessons have been learned. Fortunately the success of the Pi means they're somewhat better funded this time around, so they aren't being shy about spending on good resources to get things done.

    So .. to end my ramble. In the last few days some of the GBM/V4L2 work reached the point where we can package a "working" system on Linux 5.4 and we'll bump to Linux 5.5 soon. Proper public testing is still some way off as the transition from MMAL to GBM/V4L2 decoding means "one step forwards and two steps backwards" in the user experience due to the amount of new code involved. We'd like things to be closer to parity before we invite the masses to bug hunt. The greatest compliment will be a bunch of users whining about updating and not noticing any difference :)

    WireGuard support is now merged in LE master branch. I will wait on the connman bump before PR'ing to the 9.2 branch as well. It's in a functional state (it works for me) but I'm sure there are some lurking issues to find. Enjoy :)

    There are HAT boards that exploit the ability to power an RPi via the GPIO pins. Basically you power the HAT board not the main board, and this means the IR sensor remains powered and able to recieve a power-on command when the main board is powered off. Have a look in some of the larger Pi reseller catalogues online and you'll find them.