Posts by chewitt

No idea what the problem is but the long-standing advise for most DVB hardware is to separate the card/server end from the client so that the client device (RPi #1) can use the latest and greatest LE version, and the TVH/card are connected to another device (RPi #2) that runs whatever distro (with kernel and drivers) that runs reliably. TBS sadly have rather poor upstream kernel support for their devices (and I believe have moved their driver sources to a closed-source model again) so hitting the magic combo that runs right on recent or bleeding-edge LE kernels can be challenging.

Quote from punter

can I use the one from coreelec that works?

No, as the file is kernel-version specific. You'll have to experiement with other g12a device-tree files.

My understanding has always been that ConnMan has conflict avoidance logic and should enable the tether using an alternative subnet class, e.g. if Ethernet uses 192.168.x.x then it would pick 10.x.x.x or 172.16.x.x instead. Not something I ever needed to test though. Regardless, the logic is automagic and the wireless configuration is not something you can directly control. The functionality in ConnMan is for providing a hotspot on mobile phone or tablet device and so has on/off level controls; it is intentionally simple and not a router. And, if WireGuard works with the move-before logic, you need the move-before logic.

I'm noticing that your compose file has "- PUID= 0" not "- PUID=0" .. notice the space after the = .. Yaml files are sensitive to formatting.

I'd also recommend switching the drive to ext4 as exFAT does not support unix permissions (hence everything is 777)

Quote from rdorsch

[ 10.369177] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available

The broadcom driver supports loading a board/implementation-specific (not chipset-specific) tuning firmware (clm_blob) but very few boards have them and thus there is no blob to load in our image and the driver reports this. It should really be a warning not an error, but ISTR the driver uses the generic kernel firmware loading helpers so it's not possible to alter how that's reported without impacting the reporting of all kernel firmware loading which would not be desirable. In short, it's harmless. You might need to configure the wireless regdomain in the LE settings add-on for all channels to be available.

As a general rule you don't need to directly install Widevine. If you install add-ons that require it they will use inputstream.adaptive to handle the playback of media streams and this add-on will initiate the installation of Widevine libs. All you see is an on-screen prompt to agree to the download of them.

#!/bin/bash
for file in `ls /path/to/input/files/*`; do
  ffmpeg -i $file -o /path/to/output/files/$file 
done

^ pseudo code, you need to add paths and the actual ffmpeg command to convert the input file ($file) to the output file

How are you starting the nextcloud container? .. and which container?

^ debug logs

Put the file in /storage/.update or do a manual update in the settings add-on.

I'm wondering if this is the "disturbed dry solder joints cause UART noise that u-boot interprets as keyboard input" problem I've seen on my own Hub; and has been reported here in the forum with at least one other user. The (fake) keyboard input interrupts boot and drops you into the u-boot local console. If a UART cable is connected and working (which can be a challenge due to the same dry joints) it's fairly obvious when this happens. If no working UART connected the box didn't reach the point where kernel/initramfs (which loads the LE boot splash) was booted so nothing appears on screen .. hence users claim the device is bricked etc.

For the record: I've seen some Amlogic devices with boot states that were challenging to recover from but I've never encountered a device that was truly bricked. And since we (me) have working u-boot for the box, recovery is possible.

The first step is really to get normal UART output to see what happened. Again, if the UART socket joints are dry that might require cable wiggling, patience, and many attempts.

Lakka is based upon the LE codebase: https://github.com/libretro/Lakka…mment-604326782

Moved section. Share the URL generated by "pastekodi" .. we want to see how things are connected.

(systemctl stop connman && mkdir -p /storage/.cache/connman/myservice && cp /storage/settings /storage/.cache/connman/myservice/settings && systemctl start connman)&

^ You can always run stop/copy/restart commands in the background so they complete (else termination of session stops commands) to do things .. beware the line-wrap. Or put them in a script and execute the script in the background.

There are some other threads in this forum from people seeking EAP connections - search should find them - and the wiki is open for anyone to contribute some markdown content to. If you find something that works then it can be written up.

The OS is running fine (but no GPU drivers means Kodi doesn't start). SSH in and wget/download an earlier 11.x release to /storage/.update/ and reboot.

It will work forever .. but only covers LE 11.0.3. If there is an LE 11.0.4 release it will not magically include new links to that release.

Connman actively manages content in its cache folder (means you shouldn't add stuff there when connman is running) so you need to stop the service before adding a correctly formatted profile directory and settings file and then restart the service. You shouldn't need to configure anything in iwd; the config should be passed from connman.

Note that ConnMan names the profile directory in a structured way (not plain SSID) and the SSID in the directory name and in the settings file must be a base64 encoded string; connman will not auto-convert plaintext SSID details, and since passphrase (with a non EAP) connection is the same I'd make an educated-guess that username/password in an EAP connection file also will be the same. If all else fails, the long-winded route I've seen others take for EAP connections in the past is to boot a normal desktop distro that also uses ConnMan and get the connection and config working there; then transfer the profile/settings over.

2023-07-29 02:55:49.891 T:757     debug <general>: CDRMUtils::SetMode - found crtc mode: 3840x2160 @ 30 Hz

EDID data in Kodi.log shows 1080/3840 modes fine but this ^ looks like it's trying to set 4K GUI which won't work as the silicon only supports 1080p on the GUI plane. Have you fiddled with the GUI settings on the other monitor? .. because by default we set the GUI to 1080p. If no, I can't explain, but perhaps try clearing display settings (stop kodi, delete guisettings.xml, restart kodi) or force the initial DRM output to 1080p by appending "video=HDMI-A-1:1920x1080M@60" to kernel boot params in extlinux.conf.