Posts by chewitt

I've pushed a full set of RK3288/RK3328/RK3399/RK356X/RK3576/RK3588 images to my testing share. Top-level changes are:

- Update kernel to Linux 7.2.1
- Update Kodi to K22-beta2
- Fixed missing audio on RK3576
- Fixed missing system temp in Kodi
- Added NPU support on RK3576 (not that anything uses it)
- Added AIC8800 SDIO WiFi support (patches from the mailing-list, firmware needs manual install from Khadas repos)

Notes:

I've included some patches that align HDMI audio card names in the kernel. For some devices this will (again) result in the card name presented to Kodi changing and you'll need to visit Kodi audio settings to reselect an HDMI output device. On the upside (with the kernel side finally having consistent naming) this should now be a permanent change.

I haven't tested RK3568 for some months, and due to some travel this week it will be another week or so before I get around to it. heitbaum did test RK3399 for me so I've been able to confirm the deinterlace driver and HDR work there.

There are still some audio glitches with pass-through. I plan to investigate this after Kwiboo reworks his being-upstreamed patches against another large in-flight patch series; until then it's not worth debugging something that will change the involved code.

I guarantee CastagnaIT is developing and testing against K22 codebases; Gemini came up with horse-poop there.

The workflow that's documented in the wiki is for users to boot from the "box" image (which contains autoscript files that should hook vendor u-boot) then download a device-specific image to eMMC to /storage and write using emmctool. It's also possible to create a combined .img file that has mainline u-boot + extlinux + autoscript boot files to handle users who see 'mibox4' in the image filename and attempt to use that first. It works because vendor u-boot ignores the extlinux files and mainline u-boot ignores the autoscript files. The combined .img type is what the buildsystem creates by default when the amlogic-boot-fip device name e.g. 'mibox4' falls-through the case statement in projects/Amlogic/bootloader/mkimage. Does the "box" image boot from USB once a device-tree dtb has been added to the /amlogic folder?

For testing you can add WiFi/BT firmware locally https://wiki.libreelec.tv/how-to/add-firmware - You can also hack files into the image using projects/Amlogic/filesystem/usr/lib/firmware/xxx - not something I'll accept in our main repo but fine to save effort during development.

NB: It would be easier to review things if you cloned https://github.com/LibreELEC/LibreELEC.tv and pushed a topic branch with the changes. Same for https://github.com/torvalds/linux and https://github.com/u-boot/u-boot respectively.

Use a file sharing site?

Quote from mcecc_libre

new issue with The Crew and real-debrid .. any recommendations welcome

I recommend you find another forum to get help in, because this one does not care for pirates.

Thread

Forum Rules

General Conduct

• Be polite and respectful to forum staff and other users
• Be polite and respectful towards this project and other projects
• Be patient, user and staff are spread all over the world, an answer may take time

Posting

• One topic per thread
• Posts should be written in English (add text in your native language if needed)
• Be as descriptive and detailed as possible. We are not mind readers!
• Use AI tools sparingly .. do not post whole pages of encyclopedia output
• If you use AI tools to triage an

…

newphreak

March 15, 2016 at 1:02 AM

I've not looked at it, but one of the users posted a script which reconstructs the JSON file that contains info on all the recordings. I'd start with that.

I've not run LE12.x images for a long time, but it works fine for me on current LE13 (Generic) nightlies. You'll need to share a Kodi debug log that shows clean boot then installation failure for anyone to comment.

The add-on is not available in the LE12.x repos simply because it was developed against LE13 and I have no devices running LE12.x images for testing purposes these days.

The patch looks structurally okay to me now, but I can't speak for the code. Denis and Marcel seem to be less active at the moment and I'm not sure if they are still working at Intel or were laid off, which might slow things up (not that ConnMan has been quick in recent years). If there is no comment in a week you might need to reply to your own email submission with a brief apology for the five previous messy iterations, and politely asking for feedback. If we see some positive feedback then I'm happy to pick the patch into LE images until ConnMan sees a version bump that includes it.

If you have questions, ask questions. Otherwise you just made a statement that has no answer.

See these threads from the Tvheadend forum - the correct term to search on there seems to be "importing" recordings:

Re-Import Existing Recordings

I'm running HTS Tvheadend-testing 4.4.20181215 from http://syno.dierkse.nl/ on a Synology NAS. It stopped working a little while ago and I recently had a c...

tvheadend.org

Piping mkv file help

Hello everyone and I hope all is well during this corona pandemic. I have been messing around with tvheadend and was wondering if I can pipe my local movies...

tvheadend.org

If you see frames at the start of playback some kind of network connection to the source media is functioning. If playback stutters and freezes I'd point fingers at the often-rubbish WiFi on the RPi5 resulting in inadequate bandwidth; but that would not explain a hard lock-up requiring reboot and being unable to stop playback and return to the GUI. You might need to enable debug logging in Kodi settings and persistent logging (in the LE settings add-on) to capture a debug log on disk that can be shared so we can maybe see more about what's going on. The obvious test would be to cable the RPi5 to the router. If that solves the problem, either keep using the cable or look for a USB WiFi dongle that performs better than the onboard WiFi (decent chip, terrible antenna).

ConnMan is not quite as strict as the kernel, but maintainers prefer patch descriptions with an imperative tone, so if there is another iteration of the patch I'd change this:

During interface teardown, the GSupplicantInterface resources were not being
properly canceled, leading to a socket file descriptor leak. This patch
ensures that g_supplicant_interface_cancel is executed safely when the
interface is removed.

To this (but with correct line wrapping):

During interface teardown GSupplicantInterface resources are not properly canceled leading to a socket file descriptor leak. Fix this by ensuring g_supplicant_interface_cancel is always executed when an interface is removed.

NB: there appears to be a stray line-delete in the patch:

--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -2740,19 +2740,17 @@  static void interface_removed(GSupplicantInterface *interface)
 	DBG("ifname %s", ifname);
 
 	wifi = g_supplicant_interface_get_data(interface);
-
 	if (wifi)
 		wifi->interface = NULL;

If you have an account on patchwork it would be good to mark earlier iterations of patches as superseded so maintainer tools (and thus maintainers) can ignore them.

To the original question: I'd prefer to see the patch merged and package bumped than place 'known bug' info in the wiki.

As a general rule we have no problem picking patches submitted to mailing lists into LE kernels as there's a visible commitment to upstream things and we'll be able to drop patches in future kernel bumps. This is all good and normal.

For boot things, proper u-boot support would be desirable. If the box has a signed bootloader? then that becomes difficult, but I'd look to solve those kind of packaging issues via amlogic-boot-fip and projects/Amlogic/bootloader/{install,release,mkimage} scripts than do on-box assembly with emmctool. I have no knowledge of these boxes though. I did see there's no SD card interface so I guess you are booting from a USB stick?

Tvheadend (server) supports IPTV sources, which are then visible in Kodi as channels via the Tvheadend PVR client addon. Q's on the topic are probably best directed towards the Tvheadend forum; although be mindful that the developers there (as here) have rather low or no interest in helping people with pirate IPTV sources.

The kernel drivers need to evolve to handle yuv420p10le and AFBC compression; which is a rather non-trivial task requiring human developer experience in media drivers and proper Amlogic silicon knowledge to ensure correct architecture. I've tried pointing the latest generations of LLM tools at the problem, but even Claude Fable quickly descends into AI-slop generation when trying to port things from the proprietary Amlogic BSP codebase. Amlogic are working on entirely new drivers and allegedly new DRM code; but this will focus on their newer chips (although they have promised to back-fill support for older ones) and due to their inexperience with upstreaming the progress is glacial.

Kodi V4L2 decoding does not support per-codec enable/disable and the whole point of V4L2 decoding is a clean implementation that avoids the typical Android approach of band-aiding userspace apps to workaround flawed kernels. If the kernel side works the need to disable things goes away.

NB: GXL chips like S905X/D/W/L/etc. support 10-bit decoding and processing inside the chip, but only 8-bit output, so these boards always have some visible banding. The dithering options recently added to K22 seem to help a little with this.

TL/DR; I lack the developer skills and knowledge to fix the problem and there's not really anyone anywhere working on the staging driver to fix its many problems (it has some deeper architectural issues once you get to newer generations). Until that changes, it is what it is, sadly.

raspberry_kan If intending to upstream the device-tree to the kernel:

* Drop most of the comments from the dts; discussion should be done in a cover-letter or commit description, not code

* Commits need a 'Signed-off-by' with a real name/email

* You need to update bindings with information too; learn to run a bindings check against the dts to find errors

Please note that emmctool support is intentionally for devices that have upstream u-boot support. I'm not inclined to accept any changes that manipulate vendor boot code; there are too many opportunities for 'bricking' devices.

There is no support for SSV6051 chips on a modern Linux kernel. Armbian devs hacked something together for Rockchip boards but the hacking simplified the driver by removing all the code associated with Amlogic hardware, so while it might read like an option in Google results it's not usable; and even on Rockchip hardware the driver is dreadful.

TL/DR; these days upstream Realtek USB WiFi chip support is decent so lots of good dongles available.