Please see if an LE13 nightly or image from my test share works better? https://chewitt.libreelec.tv/testing
Posts by chewitt
-
-
I don't see anything that looks obviously wrong. The channel is opened and you can see ffmpeg parsing content. Two audio streams are found; one is mpeg2audio which I'd guess is stereo, and one is ac3 which I'd guess has 5.1 audio, which is selected alongside the H264 video content.
Disabling VAAPI changes the process flow inside Kodi, although I'd have to go look at code to understand more. I'm wondering what differences might exist/show in the logs as a first step. Please share some additional debug logs (separate logs/pastes if possible, as these are easier to search).
- Show an SD channel with VAAPI disabled
- Show an HD channel being opened
NB: LE did bump the Tvheadend version last week https://github.com/LibreELEC/LibreELEC.tv/pull/10719 but the list of changes in the update are not particularly interesting (compile fixes, translation updates, etc.). There are also ffmpeg changes to improve the transcoding capabilities (mentions of VAAPI here, but this is encoding not decoding) so I'm not immediately seeing a connection to the problem reported.
-
The feature was added to the addon in the last two days. You just happen to have needed it as it was merged/built/published.
-
Remove all HDMI settings from config.txt. HDMI settings belong to cmdline.txt now.
Note that 'kernel param' settings in cmdline.txt are completely different from old-style config.txt settings. If you put the old-style settings in the wrong file the board probably doesn't boot.
-
I don't see the errors reading firmware/version that you do when running flirc_util, e.g.
Code
Display MoreROCK5B:~ # flirc_util [W] lib/cmds.c handle_longopt(180): `version' doesn not take '--pretty' option flirc_util version b71c83813a98efb92d565792bdcab96efa3533e0 [b71c838+] Firmware Detected FW Version: v4.10.1 SKU: Flirc 2.0 [dori] Branch: release Config: release Hash: 0x26D56A46 Commands: delete Delete next remote button flirc sees from saved database delete_index Delete button at index displayed in `flirc_util settings` device_log Displays the log on the device dfu Kick in or out of Device Firmware Upgrade mode format Remove all saved buttons from flirc help Show this help. Also try `help <command>` interkey_delay set the interkey delay loadconfig Load configuration file from disk to flirc loglevel set the log level mode Enable or disable a usb mode noise_canceler Noise canceler to prevent phantom presses normal Put flirc in normal user mode profiles enable or disable built in profiles reboot Displays all the devices current settings record Record infrared buttons and link them to HID keys record_api Advanced button recording record_lp Record a long pres key record_macro Record a macro key rom_table enable or disable a give rom table saveconfig Save configuration file to disk script run a command script sendir Send a packet over the IR transmitter settings Displays all the devices current settings sleep_detect Turns on sleep/suspend detection unit_test Performs a self test upgrade Uploads new firmware image to flirc hardware version Print the application version and device version if connected wait Waits for the device to be plugged in (used for scripting)I'd suggest contacting flirc support as they know their hardware better than we do.
-
The upstream kernel p200 dtb is for devices using external-phy (rgmii) with Gbit Ethernet and the chip on reg=3 of the MDIO bus.
The upstream kernel p201 dtb is for devices using internal-phy (rmii) with 10/100 Ethernet.
The downstream kernel gxbb_p200_1G_100M_RealtekWiFi file uses rmii so p201 upstream is the correct one to use.
In the upstream kernel both p200 and p201 have identical SDIO (WiFi) configuration inherited from the p20x.dtsi. This is set to probe SDIO reg=1 and although it is technically possible to have other SDIO reg assigments on the bus, I have never seen any Amlogic device with any SDIO module use anything other that reg=1, so the p201 dtb should result in SDIO probing and loading of the WiFi driver in the image. I'm not seeing any SDIO probing so you either share a log from the CE image to prove something exists, or we believe the upstream kernel logs that show a MediaTek MT7601U chip connected to the USB bus. Assuming this is not an external USB dongle; the chip is internally wired. If true it will be the first time I see that specific chip used in an Amlogic box, but it's a cost-engineered (cheap) internal-phy box with 10/100 Ethernet so using a cheap USB chipset internally is completely plausible.
-
The latest RK356X, RK3576, and RK3588 images in my test share have a fix for broken multi-channel audio (missing channels and speaker placement issues). Enjoy
-
No idea .. perhaps see if the LE13 images in https://chewitt.libreelec.tv/testing are any different?
-
It won't be unless you install the "flirc_util" add-on from the LE repo and then logout/login over SSH.
-
There's been recent activity here: https://github.com/LibreELEC/LibreELEC.tv/pull/10592 .. but it reads like some further work and testing is required before things are mergeable.
-
I'm using a BT remote with an RPi5 on LE13 nightlies for years so I don't think there's a general issue with Bluez. The only issue I have is a few unmapped keys, but that's laziness on my part. I keep telling myself it's a "rainy day" task to update the hwdb file, but as it only rains twice a year (briefly) here it never happens
-
Connect the RPi directly to the projector and I'll take an educated guess that the 1/4 screen issues go away. Then if you add spliters and adapters etc. inline the issues reappear and you'll know the self-inflicted cause.
I'm not expert on config.txt options but I doubt the HDMI tweaks you added there do anything. Almost all the old firmware tweaks were obsoleted when RPi switched over to the upstream kernel display pipeline (some time ago). Many of the old tweaks have kernel DRM equivalents though.
-
these should be different boards/dtbs for different boards?
LE is not CE so in some scenarios CE 'fixes' result in something that works better on some piece of hardware. In other scenarios the absence of those 'fixes' results in LE working better. Roll dice
-
If you run "flirc_util" does it see hardware attached? - are you able to record key-presses, e.g. flirc_util record enter
flirc ^
-
Code
kernel: mt7601u 1-1.3:1.0: ASIC revision: 76010001 MAC revision: 76010500 kernel: mt7601u 1-1.3:1.0: Direct firmware load for mt7601u.bin failed with error -2 kernel: mt7601u 1-1.3:1.0: probe with driver mt7601u failed with error -2There is no Realtek WiFi hardware visible in any of the logs shared. There IS a Mediatek USB WiFi device visible in all logs shared and this is missing firmware (as above). The Linux 6.18-rc7 kernel images posted to my test share a few days ago (mentioned in post #4) have the missing firmware added. The latest logs you shared show a Linux 6.17.4 kernel image that does not contain the firmware (although you can always add it manually using the commands in post #2). If you believe there to be Realtek WiFi hardware inside the box you need to pastebin the old vendor kernel dmesg log somewhere so I can maybe see what chip is present.
NB: LE has its own paste server so in the AMLGX images all you need to do is run "pastekodi" and share the URL generated.
-
-
Deoptim No further support for you in this forum: https://kodi.wiki/view/Official:Forum_rules/Banned_add-ons
NB: I've removed the download links to the private image as these aren't guaranteed to be free of similar crapware.
-
Random thoughts:
a) Always use the HDMI port nearest the PSU connector
b) Are you using any kind of micro-HDMI to HDMI adapter? .. or a proper micro-HDMI to HDMI cable? - If you are using an adapter, this is probably the source of the problem.
c) If using a proper micro-HDMI to HDMI cable (no adapter) put Kodi in debug mode, reboot, then SSH in and run "pastekodi" and share the URL .. perhaps we can see something.
