Posts by chewitt

I would investigate using systemd to locally mount the remote SMB shares so they become part of the local filesystem; instead of using the SMB clients in Kodi/Emby. The advantage of this approach is you can configure startup/shutdown dependencies; i.e. the systemd service for the Emby container (or Docker as a whole) can be tweaked to depend on the SMB mount being active first.

Probably. Grab a spare SD card and see for yourself.

I never heard of mediasources.xml before, but sources.xml (where you define sources) and passwords.xml (password mappings to sources) are definitely valid. In the past I had creds in sources.xml but at some point that stopped working and the mapping (as posted above) was needed.

The release notes refer to kernel overlays that provide(d) support for additional kernel modules to support DVB cards that are not upstream (lots of them). I'm not aware of any changes to the Kodi PVR clients.

NFSMOUNT

-- MOVIES

-- Movie1 (2012)

-- Movie2 (2018)

-- TVSHOWS

-- Show

-- Show.s01.e01.mkv

-- Show.s01.e02.mkv

-- AnotherShow

-- AndAnotherShow

^ I'd use a single NFS mount with separate folders underneath it for content. Edit /storage/.kodi/userdata/sources.xml to change the paths to align with that. Delete existing DB files, restart Kodi to start over clean, then set the content types and scrapers to use for each source and then rescrape. Don't obsess over trying to reuse existing library data. As long as you named everything correctly in the first place it will all (re)scrape easily.

http://ftp.sunet.se/mirror/archive…media/openelec/ <= OE v4-v6

https://mirror.math.princeton.edu/pub/openelec/ <= OE v7-8

^ 10 seconds of Google searching found some old OE mirrors that still have files for download. You can probably get something to install and show the Kodi home-screen, but when it refuses to access anything on the internet due to expired TLS certs and other issues that impact on old software, there will be zero support in this forum. We forked from OE in 2016 and anything before LE is not our problem.

NB: The OE v8 release is after we forked LE and it has a ton of problems due to a large number of changes being added without any prior testing (one of the several reasons we forked) .. so best to skip that one.

This is the CPU opp-table: https://github.com/torvalds/linux…3399-t-opp.dtsi

It looks like support for the 4SE board has been submitted and merged upstream: https://patchwork.kernel.org/project/linux-…@collabora.com/ .. although I don't see that in torvalds/master (will become Linux 6.6) yet, bu you should be able to pick/backport those patches onto the Linux 6.5 kernel we use in LE master easily.

https://wiki.libreelec.tv/development/build-basics

https://wiki.libreelec.tv/development/git-tutorial

I moved all my devices to LE12 for testing so can't test LE11, but in LE12: Settings > Display > Calibration > Video Calibration exists. You may need to have the GUI in advanced or expert mode to see the option.

Kodi is not a heavy-CPU application unless you're software decoding lots of media, but using the non-T device-tree means you are over-clocking the board, so you need to ensure it's properly cooled via fan or case.

Kodi feature requests should be made to Kodi developers via the Kodi forums: https://forum.kodi.tv/forumdisplay.php?fid=9

Kodi feature requests should be made here: https://forum.kodi.tv/forumdisplay.php?fid=9

I suggest reading the link I already posted.

It's a while since I played with an RPi3 but something around 10s is normal for most of ARM boards we support.

You figured out that you need to replace <service> with the actual service name, right?

Put the passphrase in a temporary text file, copy it, then paste it when prompted by connmanctl for the passphrase.

I'd advise against trying to run the Kodi GUI at 4K, Please have a read: https://wiki.libreelec.tv/configuration/4k-hdr

resize2fs /dev/sda3

Partitions and Filesystems are separate things and I'd guess you've resized the partition to 100% but not the filesystem within it. The ^ above command should fix that.

The screenshot shows the T version to be slower than earlier versions; which means it will need a dedicated device-tree file that as a minimum defines the correct CPU opp-points and voltages to be used. If the T version is just a way to recycle low-yield chip that don't clock high enough to be sold as regular non-T chips that'll be the sole difference, although the voltages needed for stable ops might be difference from the regular chips. If it's a deliberate "low power" variant there are likely other minor silicon differences that need to be accounted for. Radxa probably have RK vendor kernels with device-trees that contain that information. I'd argue it's also their responsibility to submit support for the board to the upstream kernel. You might want to have a dig around in the Armbian forum to see if there's any prior-art there as Radxa often target Armbian support for their boards.