Posts by chewitt

    Code
    cd /storage
    wget https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-10.85.0-wetek-play2.img.gz
    emmctool w LibreELEC-AMLGX.arm-10.85.0-wetek-play2.img.gz

    If you're feeling brave, some figuring out happened and that image ^ should result in a WP2 box that boots and runs LE with upstream u-boot from internal storage instead of SD card :)

    Code
    cd /storage
    wget https://chewitt.libreelec.tv/testing/LibreELEC-AMLGX.arm-10.85.0-wetek-play2.img.gz
    emmctool w LibreELEC-AMLGX.arm-10.85.0-wetek-play2.img.gz

    If you're feeling brave, that ^ should result in a WP2 box that boots from internal storage instead of SD card :)

    You can store files on the PC (or low-power NAS device in the network, or the USB drive attached to the PC) then share the files to the RPi and create a network "source" for the shared files instead of having them directly connected to the RPi via USB. You can now rearrange them into whatever filing structure you like on the NAS/USB drive, or (recommended) use MusicBrain`z Piccard to scrape/tag and automagically store the files for you. You'll still need to 'scrape' the files into the Library on the Kodi side but once the tags are redone with MB that process is very accurate and the Web GUI should have a "refresh library" button. I'm not aware of Web GUIs that make playlist creation easier - Kodi is rather designed to do that kind of thing from the TV interface, but avoiding the need to fixup meta/scraping (because it's done properly by Picard) is normally a good win for music management.

    The purpose of releasing is so that users who need to run Matrix (and in the near-ish future, Nexus) can update their devices. For users with older RPi hardware it's a mixed bag because the upstream switch to a common GBM/V4L2 video pipeline (standardisation) means there is no longer any support for the older OMX/MMAL decoders. They were removed (along with iMX6 and Amcodec) to reduce the code spaghetti that had made Kodi increasingly impossible to maintain (fix something for one and you break something elsewhere): we did table-napkin maths at Kodi DevCon and estimated 38 decoding path combinations are reduced to 6 paths and with more work can reach 4 in the future. When it is used used with appropriate hardware, DRMPRIME is great. For example: For hardware with appropriate kernel drivers Kodi now supports HDR properly with 8/10/12 bit output - HDR support on RPi4 is now awesome (the comparison with LE 9.2 is night/day).


    The software optimisation done for HEVC under the older proprietary decoders was extremely clever, but also a huge hack, and requires a substantial 50,000 lines-of-code patch to ffmpeg that would never, ever, be upstreamable. In the mid-term future we will be running ffmpeg with upstream only code and no meaningful patches. That makes distro maintenance a lot easier, not just for LE, and means RPi hardware will start working the same on all distro's and not just the limited few dumb enough to allow 50,000 LOC patches in their codebases.


    There is no plan to redo the huge invasive code hack for older RPi hardware because (as before) it would never be upstreamable. After 10-years of hoarding custom patches in their own Linux fork the RPi Foundation has learned the cost of downstream development and the value of upstreaming. LE and Team Kodi have been one of the catalysts for change in their approach. We're proud of that, and we've been thanked for pushing them into making the changes, because standardising and upstreaming is benefitting their business model.


    So .. as has been published multiple times; you are welcome to continue using LE9.2 if you depend on HEVC support.

    Using OpenVPN will place your unprotected LE device on the public internet. It is not designed for that. So the security engineer in me wants to polietely suggest that users who don't know how to use VPN software (or can't Google and figure out an understanding) .. shouldn't use VPN software. I'm not trying to be an arse; I just don't want to see people getting shafted by scanning bots that *will* find and start brute-forcing an LE box rather quickly.

    AV1 is still rather new so there isn't much 'open' hardware supporting it in circulation and the few 'streaming' sources that offer AV1 content also support H264/VP9 so it's "nice to have" not "must have" for now. The RK3588 SoC is promising; but boards for that are only just starting to be released, they aren't particularly cheap (not that anything is these days) and nobody wrote V4L2 drivers for the AV1 codec in the SoC yet (although there are firm plans to write it and we know the Collabora developer who has the task for a commercial project).

    Code
    find /volume1 -type d -name @eaDir -exec rm -rf \"{}\" \;

    I've no idea why Kodi behaves like that, but the workaround would be to disable AFP services on the Synology box, as that's the reason @eadir files are created (to hold AFS metadata). It's unlikely AFP services are needed as all Apple kit from the last decade or more speaks SMB. Then do a recursive find/delete of the @eadir files with ^ the above command, reboot the RPi's and see what happens.

    I haven't noticed this myself, but a) I'm not using the WP2 for much, b) I've erased emmc to boot the box using the upstream u-boot image on SD card (the wetek-play2.img.gz file in my test share) which may do power things differently.


    ^ we added a tools section to the latest versions, which will erase the mulit-partitioning that Windows is dumb about, making the whoie card writeable again. NB: I've only ever observed issues with the app when the card is done/failing.

    Coming out of same mode puts it into a boot loop but keen to see how this can be fixed.

    It's a self-inflicted problem that will be solved by uninstalling/removing the incompatible piracy shitware that caused the issue. If you want to use those add-ons you are not welcome in this forum (aka, you should read our forum rules again).

    In the future the answer will be yes, and we should have about three months of previous images for download, but right now we're still in the process of making the changes to achieve that goal and there are none to speak of .. so no.

    At the end of the day it is simple for people to make a USB and test to see what works for their use-cases, and a major task to aggregate and maintain results as we move frequently and continuously through combinations of newer kernels, drivers and firmware - which is why that idea dies on its arse each time someone raises it or well-meaningly starts a thread on the topic.