Posts by chewitt

<?xml version="1.0" encoding="utf-8" ?>
<sources>
    <video>
        <default pathversion="1"></default>
        <source>
            <name>TV</name>
            <path pathversion="1">smb://username:password@DISKSTATION/Video/</path>
            <allowsharing>true</allowsharing>
        </source>
        <source>
            <name>Concerts</name>
            <path pathversion="1">smb://username:password@DISKSTATION/Video/Concerts/</path>
            <allowsharing>true</allowsharing>
        </source>
        <source>
            <name>Movies</name>
            <path pathversion="1">smb://username:password@DISKSTATION/Video/My%20Films/</path>
            <allowsharing>true</allowsharing>
        </source>
    </video>
    <music>
        <default pathversion="1"></default>
        <source>
            <name>Music</name>
            <path pathversion="1">smb://username:password@DISKSTATION/music/</path>
            <allowsharing>true</allowsharing>
        </source>
    </music>
</sources>

^ some nesting issues fixed. Yes you need %20 for space, but better would be to change the share name to remove the space (spaces in paths are always a bad idea). I would also organise things so that TV, Movies, Music, Concerts are in different folders. Different media types normally require different scraper settings so if you mix them up .. expect weird scraper issues and false matches. Put movies in Title Folders (one folder per Movie) is usually the best approach, and similar with TV shows, one folder per show, doesn't matter if seasons are in subfolders or all in the same folder.

CEC should be fixed in the latest images on my share (not nightlies) - would be nice to have confirmation.

The X96-Air and A95XF3-Air device trees are also renamed to use 100/1000 suffixes to indicate 10/100 or Gigabit connectivity on the boxes. I've used 2g/4g before but some Google searching shows RAM size is not a reliable correlation to the PHY specs.

Odroid HC4 now has a separate image, device-tree is submitted upstream and should be included with Linux 5.12, and I'll work on mainline u-boot support once it's accepted - until then it's using the C4 u-boot sources (which work fine).

I'll push an update to main repo with the same changes in the next week.

Quote from TasTraceur

Because now everything works perfectly and in the new release I will lose at least the ShitCrapStream

^ ...stream is piracy and forum rules state that support stops pending proof of a system free of piracy add-ons/services etc.

Have you read/followed: Infra-Red Remotes - LibreELEC.wiki ?

The current ConnMan implementation was made for the simple use-case of connecting a tunnel and routing everything down the tunnel to the remote location; partly because that's my personal use-case and I did the work with ConnMan devs to get WireGuard support added into ConnMan. Any other use-case probably needs work and validation with them.

You're best asking in the Kodi Forum support thread for the XEM scraper.

<?xml version="1.0" encoding="utf-8" ?>
<sources>
    <video>
        <default pathversion="1"></default>
        <source>
            <name>TEST</name>
            <path pathversion="1">smb://username:password@DISKSTATION/MEDIA/</path>
            <allowsharing>true</allowsharing>
        </source>
    </video>
</sources>

^ edit /storage/.kodi/userdata/sources.xml to use that format for the sources, it's fairly simple to crib the format. Change username/passsword and the name of the Synology and share names as you need them in each section (video/music/pictures/games/files). Save and reboot or restart Kodi to effect the changes. You cannot "browse" to add shares without downgrading the NAS to SMBv1 (not recommended) but this takes 5 mins effort to setup once and then you're done.

Use a current LE10 nightly dev image and then install "Tubed" from the Kodi repo. This works well and since it has completed all the YouTube vetting processes for apps, it requires no "developer API key" setup to work. The icon is a bit odd due to vetting preventing anything that looks like YouTube's logo, but you'll love the speed of search in K19.

I have fuzzy recall about reading something else about WMC recently.. along the lines of the developer abandoning the add-oon due to the fact that WMC is long-dead from MS and he wasn't using it anymore .. and a reasonably simple bug being reported and then fixed with assistance from one of the Team Kodi developers. Anyway, that's just a hint on overall status. The best place to report bugs is the Kodi forum support thread, because then the actual maintainer will see them. LE's role is building and publishing whatever the upstream maintainer releases so we're less involved with the bug triage and fix process.

Kodi are in the process of switching some mirror infrastructure around so some things are probably broken right now. Wait 24h and see if it the issue resolves itself.

belaid38 The "wetek-play2" image is structured for mainline u-boot so will only boot (mainline u-boot) from SD once you erase vendor u-boot from the internal emmc storage - if it's there the box *always* boots from it and vendor u-boot doesn't understand extlinux.conf. The "box" image should be compatible with devices with vendor u-boot installed on emmc.

I can see the ir-receiver nodes are defined in device-tree so I guess it should be able to work. Have you tried following the infos in Infra-Red Remotes - LibreELEC.wiki ?

RPi4 hardware decoding is still work in progress but improving daily. Keep updating. Keep testing.

Should be resolved with qtbase: disable zstd support by HiassofT · Pull Request #5058 · LibreELEC/LibreELEC.tv · GitHub

dazed Thanks for the report. HEVC/HDR etc. and other video/audio gremlins are all known, and CEC is something I'll look into. Did the Minix IR remote work? .. I added an embedded keymap for that. If you could also check BT and run "dmesg | paste" and share the URL it would be appreciated.

Hedda It should have been reasonably obvious from our initial responses that a) we don't want posts full of product links, b) we aren't too interested in OGA/OGS as LE supported devices. Lakka forums would be a better place for your enthusiasm.

hard to tell without logs from the system.

erbas the main influence is the ffmpeg changes the Raspberry Pi foundation devs have been doing on stateful V4L2 support. I'm tracking the work but beyond a point in mid-December the changes to ffmpeg need corresponding changes in the vdec drvier and this is beyond my non-coding abilities to do .. and since nobody else works on this we're stalled and unable to keep up. H264 is now working well on Pi hardware.

I'm also using updated firmware, but updated is not always better since Amlogic does not backwards test on older hardware they no longer support so change that fix e.g. GXL may also regress GXBB, and testing that is a hugely time intesive task (and work is busy).

In other news, I now have mainline u-boot booting a WP2 (GXBB) box from SD card (after erasing vendor u-boot from emmc) and have been using it as the family daily-driver for the last week. I'm currently trying to understand why audio must be forced to 44.1KHz to get audio output while the same kernel image on a GXL/GXM device is fine. However I'm at the limits of my non-coding-developer knowledge so progress comes only from guesswork and trial/error testing which is time consuming.

For the wider audience: I added a Minix Neo U9-H (S912) device tree to the "box" image based on educated guesswork and the vendor kernel device tree. It would be nice if someone with that box could test it and give feedback.