Posts by chewitt

Flirc should be usable with anything that outputs an IR signal. so Yes. Latest version of LE is recommended although this has nothing to do with flirc support which works the same on every release we've ever shipped (that's the wonder of flirc).

That is incorrect advice. The hardcoded smbclient default dialect is SMBv2, so if you set a range from SMBv1 to SMBv3 Kodi will continue to use SMBv2; it can auto-negotiate upwards to SMBv3 but not down to SMBv1. The ONLY way to use SMBv1 is to set both min/max to SMBv1.

Startup scripts execute /etc/samba/smb.conf unless /storage/.config/samba.conf exists, then it is used. Note that the LE samba shares have a default credential (libreelec:libreelec) so smb://user:pass@ipaddress/ authentication will be required.

Quote from FPSC

What I'm doing wrong?

Pulse is configured for Kodi to connect and output audio via a BT speaker. You need to reconfigure pulse audio to use it the other way around and accept audio to play-back on locally connected speakers (or via the DAC card).

See https://wiki.libreelec.tv/configuration/…tooth-receiving - and note that Kodi does not dynamically switch audio routing when you connect the BT device.

Quote from stredwizard

I only use portainer to create an ubuntu container to run a bash script because it doesn't work in the Libreelec console.

Sounds like "a sledgehammer to crack a walnut" .. bash vs. ash differences can normally be worked around. What's the script?

Kodi can run off-screen, but not headless, unless hacks are applied to disable the requirement for video output.

See https://github.com/matthuisman/docker-kodi-headless

The main use-case for Kodi in headless mode is to manage the DB, not for no-GUI playback, and you might not agree that running an Ubuntu based container on LE via Docker is a desirable way to achieve your goal - You'd also still need to builid an LE image that includes Docker and excludes Kodi (as Kodi will not run if there is no GPU). Choose which hoops you want to jump through.

NB: The project has no intention of providing 'headless' images, but you could probably self-build an image with the same headless patches. There are instructions in the wiki for self-building standard images. There are no guides for building a headless image. So it's one of those tasks that will require some initiative. I generally hold the view that people with the skills to do that kind of thing generally don't ask questios on how to do it, they just get on with it. And those that need to ask for help and intructions, normally don't succeed.

See RE: Cannot Install/Update Addons

Quote from Dozeros

Translating: I can add custom modelines to that conf file to match as best as possible the refresh rate of my devices to the movies frame rate, because what comes by default taken from the edid data is not accurate?

Correct. Using more decimal places in the frequency value of the modeline can improve accuracy:

ModeLine       "1920x1080_23.976" 74.1756 1920 2558 2602 2750 1080 1084 1089 1125 +hsync +vsync

^ The 74,1756 value uses four decimal places.

The default conf for nVidia should be /etc/X11/xorg-nvidia.conf .. the override location is /storage/.config/xorg.conf

2021-11-15 08:44:19     INFO <general>: ID:0x1ec Name:4096x2160 Refresh:23.975760 Width:4096 Height:2160
2021-11-15 08:44:19     INFO <general>: ID:0x1f9 Name:1920x1080 Refresh:23.977369 Width:1920 Height:1080

The Kodi log shows that your 23.976 modes are not accurate (23.976025 is the target) so frame drops will be needed to keep in-sync.

Way back in time (before LibreELEC, in OpenELEC days) when I maintained the AppleTV image (which had an nVidia GPU) I used to see similar things. I discovered the nVidia driver *never* gives correct modes from the EDID data, and I have fuzzy memory on reading somewhere that this is caused by nVidia having their own way of calculating things that's different from everyone else (I forget details, but this sounds exactly like something nVidia would do). Anyway, I discovered that Xorg uses modelines that with the base frequency defined at one or two decimal places, but the maximum supported is four. So with a custom /storage/.config/xorg.conf deployed it was possible to set manual modelines (based on the actual ones captured with Xorg iin debug mode) but tweak the frequencies a little to make the modelines more accurate. It was never possible to get them 100% but the difference became small enough that I never noticed the frame drops when they did occur.

This is the custom xorg.conf file for the Samsung TV that I was using back then: https://chewitt.libreelec.tv/xorg.chewitt - the Device section probably has options set that are specific to AppleTVs, but the Monitor and Screen sections show how I added custom modelines.

NB: No guarantees this resolves the issue .. and LE11 will not use Xorg so even if it does, it's not a long-term thing.

LE does not support a headless Kodi configuration (and I'm not sure one exists, it's been on the roadmap for years). The best compromise is probably running LE as VM under vmware, then the Hypervisor provides a virtual GPU to the VM and you don't need a physical GPU card.

It's unlikely that installing a Python add-on affected a Linux kernel subsystem. More likely there is a change in the kernel used with an older and current LE version that affects power modes for the IR receiver .. or something in that direction. First step is sharing the dmesg log from the box after the receiver stops working. It would also be useful to know what IR hardware is being used.

I've interpretted the original request as thin-client to server with GPU work being done on the big server; similar to how game streaming works between a small thin-client device and a 'big' computer with the fancy GPU. There is no equivalent to this for video playback.

If you just want client/server behaviour with some NUC-like thin clients this is simple. Setup a MariaDB database on the server, and share files over SMB or NFS to clients that share a common library maintained in the central SQL database. Doing this in the same house does not need wireguard, file sharing over SFTP/FTP/WebDAV, or any of the pirate shitware that @elonesa described (which has been edited from his post).

It's not a supported (or supportable) configuration with LE, and no plans to change that.

Quote from tiku

i have created .no compat folder in .update folder, but still no luck.

Run "touch /storage/.update/.nocompat" .. it's checking for a .nocompat file, not a folder. NB: You might want to uninstall aarch64 binary add-ons before crossgrading like this as they may not handle the change of arch to "arm" gracefully.

You should be able to build Armbian with LE's kernel version and current patch-set. HDMI works although with random box devices there are more unknowns. There's no harm in trying.

It's completely logical. The .m3u file is managed by the add-on, so if you edit it externally the add-on is not aware of changes. Deactivate, edit, and then reactivate, avoids that. If it worked differently in older versions that was likely luck more than design.

Quote from hbbs

Could you look into that as well?

Not my area of expertise. Someone else will need to do that.