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.
Posts by chewitt
-
-
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 RecordingsI'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.orgPiping mkv file helpHello 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:
CodeDuring 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):
CodeDuring 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:
Diff--- 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.
-
-
NB: While LE13 is using the 580.xx driver we'll need to bump to the latest driver to gain coverage of newer nVidia cards at some point, and the next-latest 595.xx series drops support for everything before RTX cards. Intel/AMD avoid the whole 'sliding window of support coverage' we see with nVidia cards.
-
The libnfs maintainer bumped to 7.0.1 to ensure the already-merged fix for the issue we hit is picked up by mainstream distros that generally prefer tagged versions. LE is also bumped to this now; so problem solved (twice). Thanks for testing.
-
okk so it turns out it really was the splitter!
We'll feign surprise at discovering that
-
Only for information about HW from Linux version 6.19.0
To be crystal clear, I have zero interest in bug reports against this kernel as it's about to be superseded with the 7.2 kernel as used in the images from my test shares. Dealing with temp things is a low priority to investigate, so repeatedly posting the same "still not working" post is just becoming annoying. I also haven't read the AI-slop 'guidance' posted, because Gemini is total garbage.
