Share the URL generrated by journaltctl | paste on the 12.2 box after a clean boot please.
Posts by chewitt
-
-
As the forum those patches are hosted on requires me to register just to view them, I have no idea whether they are simple nip-tuck patches or something more invasive. Both Tvheadend and Videolan have online repos that accept pull requests, so if the patches are needed, get them submitted -> reviewed -> merged.
-
Technical Debt 101: If fegol cannot be bothered to upstream patches (authored three years ago) I'm not picking them into the LE codebase, because we will never be able to drop them in future Tvheadend and libdvbcsa package updates.
-
Either link to the actual patch so we know what you're talking about, or don't be suprised when nothing changes.
-
Can you add the ICAM patch to future versions of Tvheadend43?
What patch?
-
Would it be possible to build ffmpeg with libx264 and libx265 support or are they still too slow?
The ffmpegx add-on provides an ffmpeg binary wth h264 support (not sure about h265). Hardware encoding is still some way off as the kernel is still missing a defined uAPI for V4L2 encoding so there's a choreographed dance between kernel, specs, and userspace apps like gstreamer and ffmpeg to pull off.
-
dmesg showed that the firmware overlay was processed, but the iwlwifi driver was not added.
The RPi5 image doesn't contain iwlwifi drivers or firmware.
This image (LE13) has the driver enabled: https://chewitt.libreelec.tv/testing/LibreE…-12.90.1.img.gz
I'd like to know the specific firmware files required for that card, as the iwlwifi folder in upstream linux-firmware contains a ton of files and I only want to pick the subset needed. Please experiment and report back.
-
Google how to use fdtput and disable the SDIO node for the WiFi device in device-tree. Or blacklist the kernel driver. Or use rfkill.
-
Have a look here: https://github.com/jefflessard/tm…eedback/devices
If you know the VFD config that worked on CE there should be a matching dtso file. Amlogic u-boot doesn't support overlays so you cannot load/use the dtso overlays directly, but you should be able to look at the content there and see how I've implemented the same changes in board dts files in my kernel branch.
The device-tree content for tm16xx has changed format a bit due to kernel maintainer feedback so the dts files in my 6.17 repo will work with the driver in LE13/master but not the driver in the LE12.2 image.
-
Some platforms, e.g. SNES, have about 10x possible emulators so the workflow is oriented towards opening the game ROM/file and then selecting the emulator you want to run it with, not running an emulator and then selecting a game.
-
Please stop creating new threads with the same question!
LE does not have package management. It does have Docker. Docker runs containers, which provide apps to the OS. You can install containers that provide the apps you are looking for. NB: VLC server is not compatible with V4L2/GBM graphics.
-
-
There are changes to iptables/nftables in recent kernels and I probably need to spend more time on the issue; which won't happen that quickly as I'm travelling for most of the next week.
-
The trac ticket is referring to https://code.ffmpeg.org/FFmpeg/FFmpeg/…ac5c69aa1cffffb and a few follow-up commits. This was merged for ffmpeg 8.0 so it will not be in current LE images which use 7.1; we are waiting on an update of v4l2_request support patches for ffmpeg 8.0 to be completed, and then we will bump to 8.0. I am hoping to see patches submitted this week, but the contributor responsible has a history of optimism on dates, so no promises

-
You can install the Docker add-on and then pull an Icecast2 container, e.g. https://hub.docker.com/r/pltnk/icecast2 - we have no idea how it is configured or whether the end-result is useable. The main idea behind Docker support is that users can install and support whatever they like (emphasis on the user supporting themselves).
NB: The Virtual OVA exists for internal test and devevlopment and we expect audio and video rendered in the ESXi browser client or vmware fusion/workstation/player. Users are welcome to experiment with other use-cases, but those are also self-supported.
-
is there any way to tell what was applied?
If the system boots /etc/os-release will tell you what is running. If the system does not boot you can compare the md5 hashes of the KERNEL and SYSTEM files in the boot partition with hashes of files in the released Generic and Generic-Legacy images to see which ones match.
-
The common mistake with recursive copying is some form of cp -R /oldstorage/.kodi /newstorage/.kodi which results in the old Kodi userdata files being copied to /storage/.kodi/.kodi and since that's the wrong location you still see a clean install on restart.
It also sounds like the clone worked (it booted) so the missing step was editing syslinux.cfg in the boot partition to change default boot mode from 'run' to 'boot'
-