Posts by chewitt

It's best to allow a week between iterations of kernel patches unless it's a final 'one last thing..' respin. Maintainers have crazy busy inboxes and work up them in date/time order so it's annoying to spend time reviewing something only to discover there are another three iterations of the same thing on the same day that need to be reviewed, with only minor adjustments in each. Allow time for people to send feedback, then send one next version that incorporates all that feedback. Also, when replying to messages always reply to the comments inline and never top-post as this loses context/conversation threading. The maintainers on the Amlogic list are pretty relaxed folks about such offences, but others can get rather irate about it. The same comments apply to u-boot and most upstream projects where the reviewer/maintainers are also kernel people.

That said, most people (self included) learn what's acceptable on kernel lists though trial and error, so annoying a few devs and being told off is just a normal rite of passage

Your options are ViwX, ViwX, or ViwX .. so best to warm up to the idea of using it.

If you implemented cache fiddling on the current RPi4 setup; remove it and you'll likely discover things improve, esp. with LE13 images. Why? because there is a sizeable chasm between how most users think media streams and caching work, and how it actually works, which results in people with utterly moronic cache configurations. Unless your network is broken (in which case the solution is always to fix the network) there is no need for anything beyond Kodi defaults, no matter what some outdated reddit or Kodi forum thread armchair pundit claims or recommends. K22 has changed things quite a bit.

RPi5 is a noticeable update on RPi4. Generic PC stuff is a little faster again. There is no performance difference between 4/8/16 GB RAM in terms of GUI and playback because 2GB is enough for 4K and the GPU and Kodi desktop resolution (and key-repeat/scroll speed of the remote device) dictate how fluid things feel, not RAM size. These days 16GB seems to be the minimum DIMM size that you can so not sure anything smaller is even possible. The difference between DDR4 and DDR5 is likely irrelevant for LE use.

I have an RPi5 booting from an NVME drive (family daily-driver) and an Intel N150 box with eMMC storage (x86_64 dev work) and while the Intel box is technically a lot faster, the real-world difference is more marginal.

The SoC searches for a boot firmware signature on SPI > eMMC > SD > USB but most devices don't have SPI flash so eMMC will be checked first. If you are seeing that repeating bootrom sequence either eMMC is wiped or non-functional (and the device is in its lowest level of boot mode). On a normal box that would mean easy booting from SD or USB, but Dreambox One/Two use encrypted boot firmware so you can only restore original Dreambox images that are signed with the correct keys, and most Amlogic 'factory restore' images are eMMC specific so even if you write them to USB media the device won't boot them. If there's an official SD card restore image you can see if that will also work from USB, but I suspect it won't. Normal S922X hardware is a little easier to mess with but secure boot devices are inherently more limited in options.

Please share the full system log, e.g. journalctl | paste after a clean boot with the images in https://chewitt.libreelec.tv/testing/

Also, what spec is the PSU? .. under-spec PSU's and ARM SoC boards often result in instability on the SDIO bus and WiFi chips draw more power than you'd think sometimes. NB: The clm_blob 'error' is completely harmless and can be ignored.

If you follow the 4K/HDR instructions in the wiki and run the GUI at 1080p so Kodi only switches to 4K for playback, and use a remote device that scrolls well, the overall user experience is very fluid. Use of pass-through audio for Atmos has no relevance to anything being “fast” in my (daily driving an RPi5 since before launch) experience.

From a brief search the Broadcom chip on the Rock4C should have driver/firmware and most Intel hardware is well supported too. The best advice I can give is “go find an Ethernet cable” .. in the absence of any logs or proper technical info to hint at the problem we have nothing to go on.

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