Posts by chewitt

    https://pine64.com/product/rockpr…oth-5-0-module/ says this is a Cypress (aka Broadcom) CYW43455 SDIO module so the fix is probably to use the correct firwmare/nvram files for the module. If there is no board specific file provided the kernel driver will look for default files and use them, but the current ones we package are sourced from some Amlogic boards and might not give great results.

    Pine64 probably have the correct brcmfmac43455-sdio.bin/brcmfmac43455-sdio.txt files to use in distro images and you can override the ones we provide by creating /storage/.config/firmware/brcm/brcmfmac43455-sdio.(bin/txt) locally and rebooting.

    The GeForce 6100 is a firm no as it requires a "no longer supported" nVidia driver version that isn't compatible with the version of Xorg we use (for at least 4-5 years). Support probably stops around LE 8.0. I've no clue about the AMD card but if the Generic Legacy (Xorg) version doesn't work, it's likely a similar story. You can try older releases from https://archive.libreelec.tv/ but beyond a point you'll hit issues with TLS certificates and add-ons that aren't compatible.

    NB: Someone's unused RPi3B will greatly outperform both cards and is likely better for the planet in electricity use terms.

    risa2000 sent me a box to experiment with and I finally got around to fiddling with it :)

    It's not the most stable thing though .. so more experimenting needed.

    Code
    SOURCE
    |--- TVShowName
         |--- Series 01
              |--- TVShowName s01e01.mkv
              |--- TVShowName s01e02.mkv
         TVShowName s02e01.mkv
         TVShowName s02e02.mkv
         TVShowName s03e01.mkv

    If you want to put files in Series/Season folders that's fine, but the files in the folder should follow the show name and should include sXXeXX or SXXEXX naming. It's not essential to put them in folders (some of mine are, others aren't) but again, the filenames need to be in the right format for things to scrape properly. You can even have both formats (as above) as long as there's no overlap in the filenames that you are using. My $0.02: keep names short/clean/simple and you avoid scraping issues.

    NB: If you want to use random filenames, you need to provide local .nfo files that either map the random filenames to the online URL for the episode in an online scrapable source (IMDB, TVDB, etc.) or you need to provide all info in the local .nfo file and use the "local file" scraper not an online one.

    If the goal is moving the RPi4 install from old to new SD card, take a backup in LE settings, clean install LE on the new card, then restore the backup. The backup only contains contents of /storage/.cache, /storage/.config, /storage/.kodi - If you aren't storing media on the SD card then a 16GB card is more than enough. If you are storing media use a USB>SD adapter to mount the old card once the backup is restored and copy media over to the new card. If no adapter, connect it to something else with a card reader and copy files over the network (it'll be slow, but you only do it once). NB: In nearly all cases copying/moving the content of the card will be faster than cloning tools as you only move e.g. 40GB of files on the card instead of copying 128GB of physical card.

    FAT32 (vfat) partition can be any size but we use 512MB for default. The storage partition can be 100% remaning size. The system boots using the UUIDs of the partitions so labels can be anything you like (see cmdline.txt).

    No idea on the 4K60 output issue, but:

    In next step I was testing RPi4 and RPi5 connected directly to LG monitor. I could play my 2160p/60 fps videos H.265 smoothly, but 2160p/60 fps H.264 videos are choppy on both players.

    RPi4 hardware decodes H264 and does not support media over 1080p resolution. RPi5 software decodes H264 and will play media over 1080p but H264 is less efficient than e.g. HEVC for the same resolution and H264/60fps/2160p media probbably exceeds the CPU limits of software decoding. Best solution: reencode that media to HEVC and it'll play nicely. Alternative solution: use a recent Intel Core i7 or better device which has the CPU grunt to cope with the non-standard format.

    Last test - 1080p movies. Both players play 1080p H264 without a problem.
    RPi4 has a problem with 1080p VC-1, but RPi5 plays them smoothly.

    That's expected. RPi4 and RPi5 software decode VC1, but only RPi5 has the CPU grunt needed for the task.

    SD cards frequently have different disk "geometry" ensuring the partition data copied from one card is incorrect once written to another card. The solution to that is to prepare the destination card to match the source partition/filesystem arrangement, mount the filesystems, then rsync the contents of the partition(s) instead trying to clone the entire physical (card) disk.

    wpa_supplicant is the Xorg of the WiFi world; it's used everywhere, it works, but it's architecturally hideous :)

    iwd is the Wayland that will replace it everywhere, soon, but it's still young(er) and maturing (rapidly).

    The latest iwd version bump that went into nightlies a couple of days ago has a pile of fixes for connection issues; the devil is always in the detail but might be worth seeing if anything improves. If it doesn't the investigation process requires you to run iwd in debug mode to capture verbose output traces for bad behaviours/failures and then report them upstream.

    NB: LE has long been an advocate for newer and better code that seeks to displace older stuff so we'll be sticking with iwd. It's good to compare with wpa though, if only to help point fingers in the right direction.

    Omega RC1 has shipped (on the Kodi side, we'll be a couple of days probably) so the code is believed to be complete .. until more issues are found that need fixing. So best to post/share the issues and get them documented and public; else Kodi devs assume all is good and won't fix the (unknown) issue. Post the Q with a "not sure if this is the right place, mods please move if not" and if it's the wrong place it'll be moved.

    If you scraped media into the library from smb://nas/share/files, this is the path stored in the library. If the NAS is now accessed using smb://192.168.1.10/share/files the path is different and Kodi treats this like new files.

    First, try this to see if it restores name resolution:

    Code
    echo "192.168.1.10        servername servername.local" >> /storage/.config/hosts.conf
    reboot

    Or experiment with path substition https://kodi.wiki/view/Path_substitution

    Is there not source code for the u-boot firmware?

    Amlogic sources exist but 99.999% of manufacturers "tweak" the sources to work with the components of a specific box (including the remote codes needed for that model) and if the RAM chip timing/specs are changed (always) this makes the u-boot binaries unique to a specific box. Unless you know what changes to make, the compiled u-boot binaries won't boot the box. Universal IR remotes are always easier.

    The AMLGX image works with S905W boxes, but you will have to see if the p281 device-tree boots (or Tanix TX3). These super-cheap boxes often have WiFi chips like SSV6501 that have no upstream drivers so the box will probably be Ethernet only.