Posts by chewitt

  • NFS and Samba Mounts - Stream Stalls

    If you want stability/reliability on a connection always use Ethernet. If you use WiFi "all bets are off" because there are so many extra variables added to the process. Pi 3B is also known for being "okay" and not "great" with wireless performance (3B+ is evolutionarily better but not revolutionary). If you are stuck with wireless the best approach is a wireless router/bridge device that provides Ethernet to the Pi. I'm regularly working with devices that don't have working wifi drivers so I have an Apple A1rport Express for that purpose .. small, good reception on the last generations of them, and usually quite cheap on eBay - I go for the ones without a box, no cable, and look filthy - as they clean-up fine, I have cables, and they're the cheapest.

  • ODROID-N2

    I'm not sure 3D will be on anyone's agenda for the Kodi GBM video pipeline - it's seen as a very niche/dead feature these days. OSMC are using the legacy kernel codebase so any fixes there aren't immediately transferrable.

  • @balbes150 LE images with Kodi-19 for S9xxx

    Quote from ukmark62

    Just to report that I don't see any improvement in playback of HEVC files compared to the previous builds.

    About half of my vids (so far) don't play - just buffers to 100% and gets stuck, and others that do play have issues with ff,rw, skip seek etc causing lockups (as in previous builds).

    HEVC has some rough spots but should generally play fine on GX (not G12A/B which has zero support for HEVC at the moment) hardware with 8-bit media. Most streamed HEVC media is 8-bit, but most ripped HEVC media is 10-bit and right now there is no 10-bit support in the HDMI driver. Once 10-bit support lands; then some work can be done to continue development on the HEVC decoder. There's no need for bug reports - we're engaged with the developers doing that work and we have a good and library of bad media for testing with.

  • @balbes150 LE images with Kodi-19 for S9xxx

    TX3 mini should have working 2.0 audio out-of-box - no need for a USB soundcard unless you're chasing multi-channel support. We have a sponsor for that work now, but due to existing commitments with the sponsor and the implementor it will be a while before it happens.

    G12A/B hardware now has working 2.0 audio and multi-channel should follow (before we see it on GX). I'm refining the config but it should appear in balbes150 images 'soon' ..

    Remotes should work fine as long as you have a keymap configured. Infrared Remotes [LibreELEC.wiki] has all the info needed.

  • @balbes150 LE images with Kodi-19 for S9xxx

    Yup, those .. and any more that get added. DVB currently requires a large out-of-tree patch series that's best confined to community images until it's reworked and sent upstream (if that ever happens). General advice - on all ARM platforms - is to use USB tuners or stick a Raspberry Pi on the network (in a cupboard) somewhere as the drivers are overall better quality and you're not dependent on the whims of community development.

  • @balbes150 LE images with Kodi-19 for S9xxx

    An update on some status things:

    Baylibre figured out a way to work around the SDIO issues on S905X2 which permits WiFi to work in a "hacky but should be acceptable" way and changes have ben submitted upstream. From initial unscientific testing the maximum throughput numbers are down on the same Broadcom chip on similar hardware, but they are still reasonable and better than having no WiFi at all. S905X3/D3/Y3 chips should be with distributors and manufacturers 'soon' which will kick off lots of "new model!" announcements but there's nothing really new, it's just a bug-fixed version of the S905X2/D2/Y2.

    Changes to better handle Ethernet on cost-engineered S905X2 boxes using the 10/100 internal PHY instead of 10/100/1000 external PHY are going through some iterations and testing. Once merged this should allow a single x96max device tree - the x96max-rmii variant will not be needed. If this works well people will look at porting the approach to gx devices. The mainline kernel already eliminated the 1G/2G/3G device-tree variants that complicate the initial install user experience with the legacy kerrnel. If ethernet-phy device-tree variants can be eliminated too this will be a really nice simplification for users trying to "guess the working device-tree" for their box.

    Hardware decoding on S905X2 and S922X is now working with caveats: HEVC support in g12 decoder firmware appears to be a bit different to gx and some bits need to be rethought - but doesn't make sense to do this until 10-bit HDMI support lands as that will also trigger some HEVC rework. So right now all the expected codecs for g12a/b are working apart from HEVC (and firmware is missing so playback triggers a hard crash). Amlogic's legal team have now provided a redistributable license for their vdec firmware files and they have been submitted to linux-firmware for inclusion in the 5.3 kernel. Until then we'll continue to maintain our own repo.

    Audio is now working on S905X2 with caveats: HDMI has 2.0 output with occasional drop-outs that need to be investigated. S/PDIF is not working and needs to be investigated. S922X still needs the device tree changes for N2 to be figured out, then it can be tested. Multi-channel PCM output will need some additional dw-hdmi changes - work from Kwiboo on that is being cleaned-up and should be submitted upstream soon.

    10-bit video support for dw-hdmi is now being worked on, which will also allow us to piggy-back on upstream HDR development in the kernel and Kodi at the moment. We discovered the main reason HDR changes have not been merged is the kernel maintainers requirement for a working userspace implementation to match them. Intel was using Weston/Wayland for this, but due to slow progress they have now switched their efforts to Kodi. With some LE/Kodi developer help in the last couple of weeks there is now working (still work in progress, but working) HDR support on Intel Gemini Lake hardware. This allows Intel to show a working userspace app and get the changes merged - which will trigger a cascade of HDR support work in many other GPU/SoCs (including Amlogic, Allwinner and Rockchip). One of the many positive outcomes from this collaboration is that there are now several Intel graphics developers with instructions to contribute and allocate some hours to Kodi support each month, which we think is rather fab :)

    We have identified a sponsor for development of audio support on GX hardware, but due to current commitments the sponsor and implementor have the work cannot be scheduled until Q4/19. There is still an opportunity for the Linux community to step up and work on it sooner, but given the length of time this has already gone untouched, that's unlikely to happen. At least we know there's a plan, and it's just a matter of time.

    VIM3 with an S922X chip was announced in the last week and some initial prototypes were posted to selected developers in the last few days. We have already had some "will it be supported?" Q's in the forum and the answer is; all Amlogic hardware that has an upstream device-tree in the kernel or submitted and pending merge will be supported going forwards. I'd make an educated guess VIM3 will have a device-tree fairly soon :)

    NB: Hardware decoding and audio changes will need to land in the amlogic branch in our GH repo before appearing in balbes150 images. All being well that should happen within the next week.

    Enjoy :)