Posts by chewitt

First, also test a current LE13 image in case it's something already resolved?

If not resolved, have a look in https://test.libreelec.tv/12.0/Generic/Generic/ and starting with the oldest development image (at the top of the file listing) to see if that has the same issue. If no problem we need to "bisect" (a halving process) the list of images to find out when the breaking change has occured; we can then cross-reference that to changes in GitHub. If the same issue is present and there are success reports from other users, I'm not sure we will figure it out easily as LE11 images were deleted when development switched to LE13.

HDMI uses active negotiation/handshaking on both ends when things are connected/unplugged or turned on/off. Kodi will respond to video capability changes, but audio capabilities are only detected once at startup. You cannot tell LE/Kodi to leave video on (as that's not how things work) but you can capture the EDID data that describes the connected HDMI properties and configure/force the Linux DRM layer to always see the AVR as being present, which achieves the same thing. Run "getedid create" from the console and then reboot, then run some tests. See https://wiki.libreelec.tv/configuration/edid

Google (AI) tells me that Freely's IPTV services are not DRM encryptied, but I'm not able to find any information online (from a brief search) about how you would configure something. Everything talks about "using your Freely equipped TV" and that appears to be based on an app (OpApp) embedded in the TV's OS rather than accessing from something else.

noggin Can you share any light on what might be possible?

Quote from schneiderlein

Maybe its something because of newer libdvdcss versions coming with LE12 that breaks compatibility

I think that's unlikely, but it's easy to test with older LE official releases and/or nightly LE12 images with older versions installed.

IMHO it's more likely that the old drive needs lens cleaning or replacement. I have a couple of really old (and really slow) SCSI cdrom drives that were clearly built to last that still work great despite being around on the planet longer than my teenage daughter, while anything newer (and faster) with an IDE/SATA connector seems to last a couple of years before dying for no explicable reason.

Quote from srazor

The only reason is that there is no acestream version for arm64 LE12/13 out of the box

Awesome! We are always delighted to hear piracy apps don't work. Long may that continue

I'm still using the original 'Amazon essentials' micro-HDMI to full size HDMI cable the RPi devs shipped out with the original RPi4 pre-production samples and it's never given problems. I prefer that to using adapters, and we do see occsasional issues from users with adapters being reported.

No harm in testing a different HDMI source too, but there's nothing exotic about the RPi board's HDMI output, so I wouldn't expect that to show any change.

It's possible and has been done. It's not something we formally support though, so there's (intentionally) no written guides on the process. Note that LE supports Docker (via an add-on) so if the goal is to run a bunch of other apps on the same hardware, perhaps investigate using containerised apps rather than using Proxmox.

Quote from salvador

There is no details how to connect video on a specific HDMI

On LE, Kodi does not run under a desktop/windowing environment so display selection is not possible. Instead Kodi will output on the display connector that probed first, and because hardware probe order cannot normally be guaranteed it is not possible to pre-determine which connector will be used.

On a general purpose Linux distro with a desktop/windowing environment you can move the Kodi app window to a specific display and the OS will (or should) remember this, and Kodi will allow you to select a specific display for full-screen output.

In both cases you should be able to select a persistent audio output device in Kodi settings.

It will not be possible to run released versions of LE11 because the latest hardware (and CPU stepping) requires mesa changes that do not exist in the embedded version of mesa. There are also boot firmware changes required, although that's less complicated as files from newer releases can be literally drag/dropped on the older SD card. I can't comment on whether newer mesa is a simple or complicated. Changing the package in the buildsystem is simple, but whether it then compiles or fails on other dependencies is the $64,000 question. There is no HOWTO guide or writeup on doing that kind of thing, and I doubt project staff will leap to volunteer at spoon-feeding instructions.

Why LE11? .. I can't think of any good reason not to use something newer

Given the immense size of the RPi userbase and attentive support it receives from their developers; if there was a real-world issue with current practice it would have been attended to.

There was some activity last month https://github.com/raspberrypi/linux/issues/6867 but as nobody has submitted a demand for us to bump the add-ons to something that includes usable code yet, I would assume development is still work in progress.

RPiOS and LE use identical firmware, config, and kernels. If it works in one it should work in the other.

Have you tried hdmi_force_hotplug=1 ? - I'm not 100% sure this is still supported in Pi firmware but worth a shot.

Quote from Elicity

I could reproduce some I think: I use the HDMI-port closest to power-port, when I use the other one CEC does not work.

That's intentional and expected. CEC is only supported on the HDMI-A-1 connector (nearest the USB-C power port).

Have you tried a different HDMI cable?

If the device is not showing up with "lsusb" then the device is either not connected, not connected via USB, or perhaps has not been powered up (might need something toggled during boot or a dedicated regulator to be described) as the output of the command is a raw read of the devices attached to the USB bus and there is no need for anything to be "supported" with drivers etc.

NB: device-tree will only describe the connectivity for the USB hub/ports, there's no need to describe attached USB devices because once ports are probed/discovered anything attached to them will be probed and have supported drivers loaded automatically (as it's USB). Asmedia chips are normally supported by the generic "CONFIG_USB_UAS" driver which is enabled by default in LE images; and I would assume in ilmich images too.

Pastebin the dumped device-tree file, someone else might see something in it.

If the WiFi/BT module in your box is QCA9377 (as with that user) the device-tree file you are using either describes a Broadcom SDIO module and neither WiFi or BT will work, or this patch is applied: with https://patchwork.kernel.org/project/linux-…[email protected]/ and WiFi will work, but the BT module is connected via serial UART connection; and since Broadcom and QCA9377 modules run at different speeds etc. this will not work unless the device-tree file correctly describes how it is connected.

I have zero knowledge on Batocera and will not be building custom Batocera images to guess at fixes, so you need to go report the issue to Batocera developers via their forum and follow their guidance.

Quote from Emaitaly

I'm trying Batocera on an old Android Tv Box... GooBangDoo XB-III - AMLOGIC Quad-core A53

I suggest you post in the Batocera forum then, because we do not support Batocera here.

You will need to configure Tvheadend, then install the pvr.hts add-on and configure that to connect to the Tvheadend instance.