Posts by chewitt

PAPlayer is the native/internal (and on LibreELEC the only) audio player that's used in Kodi, as we do not support the player being changed. Changing the audio or video player used to be a thing in ye olden XBMC days. I haven't seen it being discussed in many years and I'm not even sure swapping to another is still supported.

If the board powers up (LED's come on) the device is not bricked (esp. for something booting from SD media). It can have software issues that disrupt boot, but it is not bricked.

Add ssh to boot params in exlinux.conf to force the SSH daemon to start. Add video=HDMI-A-1:1920x1080M@60D to stop the kernel defaulting to 4K60 modes the TV might not like. If you want us to do more than blind guess at the issue; attach a serial UART cable and pastebin/share the output from boot.

NB: You can also try: https://chewitt.libreelec.tv/testing/LibreE…ockpro64.img.gz

Perhaps look at https://github.com/add-ons/plugin.video.vrt.nu/issues for info on current issues with that addon. If the VRT content is both geolocked and encrypted it's possible that a specific or minimum libwidevine version is required, and as the add-on authors are always one step behind upstream changes there are occasional delays and breakage while things are adjusted. In some cases it's possible to manually download and mod things but we don't track that here, and there's not much point in me trying to test VRT Max as I'm ~6,500km from Belgium.

Random MACs cause issues with ConnMan as the 'service' identifier is derived from the MAC, e.g. ethernet_b827ebb5e9a8_cable so randomly generated MACs mean a new (unconfigured) NIC on each boot.

That said, I would still expect the second NIC to be detected and brought into an UP state, and for it to receive an IP via DHCP, which will mean you have two NICs in the same subnet etc. - but that's generally not an issue, and you can add a static DHCP reservation in the router to avoid manual configuration on the LE side.

See if this works to assign a static MAC:

nano /storage/.config/udev.rules.d/99-network-custom-mac.rules

Create that ^ file with the content below:

SUBSYSTEM=="net", ACTION=="add", KERNELS=="0001:04:00.0", PROGRAM="/sbin/ip link set %k address ae:7f:66:a5:82:77"

Reboot to see if it works. Check the MAC assigned, then reboot again and check again to see if it changed? .. and if no, has the NIC been detected properly this time?

There are several K22 database API version bumps in recent time, so depending on what version you are updating from and to; the system may run a database upgrade in the background on boot. In theory Kodi should be showing the splash screen with a status message when that happens, but I can't put hand on heart and say that I've always seen it. So if you see a black screen, SSH in and check the kodi.log to see whether that's happening (or not) before forcing an update.

It's the first time I hear of problems

a) Kodi does not publish a "Linux" version; each distro compiles and provides IA for their own users

b) If an updated IA version is released we have normally bumped our IA add-on within 24 hours

c) The "old problem" you are reading about is an old problem

d) If you want to faff about on the CLI using wget, unzip, and database hacking to enable the add-on, it can be done. As you need the 'compiled for LE' version from our repo though; why bother when it takes 5 seconds via the GUI.

e) There is no current/known problem with the IA add-on (at least, it works here for me)

Quote from elliottmc

My RPi5 [snip] works fine with the SQL database, but it's on a wired connection

QED

The iwd developers are aware of our reports, I have personally flagged it and provided information multiple times, and maintain a discussion about it with them. The root cause is not obvious to anyone, but this is not uncommon with wireless issues due to the sheer number of variables involved and difficulty in investigating the issue; it's one of the annoying ones where nobody has been able to isolate the factors required to replicate it.

NB: 30 = ~0.0001% of the userbase. Sorry that you are 1/30, but you are wildly over-imagining the problem.

K22 has some basic DB connection handling, so if an SQL database is configured Kodi will make a number of connection attempts until the connection is available; and after X attempts it fails and restarts. On restart .. rinse/repeat.

K21 and earlier tries once and if the DB is not accessible it fails and falls back to the local DB (usually blank).

The "wait for network" setting can be increased in the LE settings add-on, but that won't ever fix the underlying issue of there being no network connection; that's what needs to be fixed.

Quote from bvtv

Can anyone help me installing inputstream adaptive on libreelec before installing the addon and dependencies in kodi on libreelec? Thanks

The inputstream.adaptive add-on is in the LE add-on repo. If widevine is then required for some add-on it should trigger the install of widevine.helper which handles the download/install automatically.. at least that's my experience.

The user with the problem always believes it affects "lots of users" but the large number of reports (from a small number of vocal people who repeat post) vs number of active installs doesn't substantiate the claim, and over time with upstream changes to iwd, the number of new or continuing reports has declined. There are for sure some users still impacted, and we'd love that number to decline further, but that's in the hands of iwd developers not ours, and wpa_supplicant has other issues that were mitigated in the switch to iwd, so regardless of which one is used we have a "You can please some of the people some of the time, not all the people all of the time" situation, so we favour progress and moving forwards, and there is no interest to revert.

Images for older boards in my test share are updated to Linux 6.16.4 and now include fixes for 10-bit format selection that were broken in semi-recent kernel bumps.

Quote from Elicity

I could not find a case for the Rock-4D, does it fit a PI-case by any chance?

No idea, I have no RPi cases kicking around at the moment (other than RPi5 cases which definitely aren't the same).

Quote from Roomen

If your colleagues can help us, we will be very grateful!!!

I have friends in the project, but no colleagues; because we are not a company, there is no product, and we do not undertake commerical development or support work. Good luck with the AI suggestions!!!

The brcmfmac driver needs to load a firmware (.bin) and nvram (.txt) file from /usr/lib/firmware/brcm but we have no firmware files for BCM4354 in the AMLGX image. If you find files, add them manually: https://wiki.libreelec.tv/how-to/add-firmware

Most mentions of IP1001M found via Google seem to point back at either unifrequ/ophub device-trees, which look to be a hack job that only partially works, or CE forum threads which fizzle out with the recommendation to avoid X' boxes.

I did also find https://blog.csdn.net/zuiaikg703/article/details/120350194 which (translated) has some hacky changes for an IP1001C variant, but Google AI claims the difference between IP1001C and IP1001M is that C is multi-mode (copper/optical) while M is single-mode (copper). The current ICPLUS PHY kernel driver only implements a relatively basic level of support for registers, so I would assume it was written around the M variant, but AI also flagged some differences in support for Jumbo frames and other items between C and M that I don't see registers being defined for, which leaves scope for unknown defaults that could leave the PHY misconfigured.

One thing I did notice is the current kernel driver does not support the 0x02430d91 hardware identifier that I see mentioned in the unifreq dts, so the MDIO bus will not auto-discover and configure the chip automatically.

This should add the identifier: https://github.com/chewitt/linux/…9d8517b2529ebd4 but no guarantees that helps? You may also need to undo some of the ethernet_phy/mdio hackery from ophub dts files.

The latest AMLGX images in my test share have a kernel with that patch, but not a dts for the X96-max-plus box.

Nothing is impossible, but we don't normally support hardware with those features; they aren't needed on HTPC devices connected to a TV that don't move. So we have no idea what's required, you don't either, and Google searching on "HiGole 2 Pro" mostly finds complaints about being unable to find drivers, no support from the vendor, and it being rubbish hardware that dissapointed and then died. If the screen is mirrored then you definitely need a windowing environment like Wayland or Xorg. Our legacy image has Xorg but you'd need to configure it to use various drivers and how that's done is not documented.

Sorry, but we are quite focussed on HTPC hardware and are not a general purpose OS.

Do the Samsung and Toshiba TV's have similar resolutions/mode capabilities?

If yes, connect the device to the Samsung TV, run "getedid create" and allow it to capture the EDID data. Then shutdown and move to the Toshiba, and the OS will still see itself as connected to the Samsung. This might (or might not) work.

If they don't, e.g. Samsung supports 4K and Toshiba does not, use the whitelist to only allow the 1080 modes to be used.