Posts by diederik

  • LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

    My message may not have come across correctly then? I think both Detlev's v8 as your patch set are ready to be merged.
    There do need to come additional fixes ... somewhere (ffmpeg, mpv, RK356x SoC support, board support, etc) and possibly in multiple places. To make it even better!

    To me the issues I found (only) with LibreELEC indicate some issue on the LE side? And thus not with Detlev's and your patch set. Otherwise I should've gotten the errors also outside LE ... which was not the case. OTOH, I also got the feeling that it worked better on LE because it did its (decoding) work better ... which in turn showed there were actual issues. Again, dunno where. But those can be worked on in subsequent patch series?

    I actually tried both 8-bit and 10-bit ... and I thought HDR needed 10-bit? Both worked though.

  • LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

    Quote from diederik

    chewitt Could you update the image for the following devices? Rock64, RockPro64, Quartz64-A, Quartz64-B, NanoPi R5S. Then I'll do my best to do a test run with them shortly.

    Chewitt should have already seen it, but for completeness, I wrote a test report here:
    Re: [PATCH v3 0/3] media: rockchip: rkvdec: add support for the VDPU346 variant - Diederik de Haas

    I was a bit surprised that it was so easy to break it. My testing was only while connected to my 4K TV ... and maybe 4K input files also made it break faster?
    That's next to a 4K HDR video file (sort of) working, which was surprising and really cool :D

  • LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

    Quote from chewitt

    I'd expect Wayland to be using zero-copy rendering as this is supported by the DRM layer and Mesa on RK hardware. For zero-copy to work mpv needs to use DRMPRIME pixfmt so buffers contain a pointer to a frame (in DMA) not a decoded frame.

    ...

    LE is not using mpv or Wayland, but Kodi and ffmpeg support both zero-copy (DRMPRIME) and normal (EGL) output. DRMPRIME is the default in all our ARM SoC images as it's more efficient, which is important for ARM SoC boards.

    NB: I have no playback issues with any of your private test samples on newer RK boards (356X, 3576, 3588).

    IIRC LE has some ffmpeg patches related to DRMPRIME which I may not have, so that could be a factor.

    I knew LE wasn't using mpv or Wayland, but I thought you encountered some issues too with Jellyfin test files ... and those were gone for me too with that dmabuf-wayland parameter. In case there were still issues, it could've pointed to a possible solution and that's why I mentioned it.

    But if there are no (more) issue with playback in LE, all the better :)

  • LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

    chewitt On #linux-rockchip 'linkmauve' suggested to add '--vo=dmabuf-wayland' to my mpv parameters and that had a spectacular result:
    No more frame drops in the BBB video 8) and the problems I had with x265 files (all blue output) ... were solved too \o/

    See https://libera.catirclogs.org/linux-rockchip/2025-10-06 (I saw you weren't online, hence this message)

    Dunno if that is in some way relevant for LibreELEC, but it may provide a clue. Hopefully ;)

  • LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

    Quote from diederik

    Several days ago I checked chewitt's repo and didn't see any additions to the rk356x-base.dtsi (or sth like that), which I think means that rkvdec2 support doesn't work for devices like my Q64-B? That would explain the less then stellar results I got.

    Updated to chewitt's latest build on Q64-B and tried some of my test file while being ssh-ed into the device and running htop. Now I'm sure it doesn't do HW decoding on rk356x. So whether it seems to work or not, depends on the complexity (bitrate I guess) of the video file.

    On the bright side, my tests on Q64-B (rk3566) and NanoPi R5S (rk3568) on my Debian system (with a whole bunch of patches) were quite successful \o/

    Chewitt: I'll CC you on my test result post and on an RFC PATCH submission I'll do (soon (tm)).

  • LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

    chewitt I did make/try something for rk356x and I'm about to test whether (and to what extend) that works. Will let you know what comes of it.

    In the mean time, I did a new test with the image build dd 20250911 on my Rock64 and while it was generally good, it did have some problems starting my BBB x265 videos (both 8-bit and 10-bit), so I booted again with debug logs enabled and played those 2 files and uploaded the compressed log to 'my share'.

    When you go to 'my share' you'll notice that I renamed some files so x264/x265 and 8/10-bit is directly visible in the file name. And it also contains some new files, including 'bbb_sunflower_1080p_60fps_normal.x265.cf24.slow.8bit.mp4' which was one of those test files.

  • LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

    I did some testing on the PINE64 Quartz64 Model B (rk3566) with my standard set of test files:

    1. Device Tree 101 - 1080p x264
    2. Big Buck Bunny (BBB) - 1080p x264
    3. BBB - 1080p x265 10-bit (re-encoding of 2)
    4. BBB - 2160p x264
    5. Bo Burnham - Can't Handle This - 1080p x264
    6. Bo Burnham - Kill yourself - 1280x640 x264 10-bit
    7. Bo Burnham - White W0man's Instagram - 1080p x264 *
    8. Elementary S01E01 - 1280x720 x265 10-bit

    *) Mangled the title a bit as it contained a disallowed word ...

    Test results:

    1. Played, but starting took a while (possibly due to debug logging and its size (>1GB)?; without debugging it seemed to just play fine)

    2. Played fine

    3. Failed to start

    4. Audio played, but picture 'refreshed' once per 30 secs or once per minute?

    5. Played fine

    6. Audio played, but no picture. The wait screen (kind of) flickered

    7. Played fine

    8. Failed to start, just wait screen. No screen flickering though


    I uploaded a compressed debug log (both FFmpeg and 'Video' components enabled) to the location chewitt knows. It's 8.2MB compressed, but uncompressed it's 256MB

  • LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

    Quote from chewitt

    I've been running tests on an RK3576 Rock-4D board. The kernel codebase is still maturing in places but I think this will be a nice sweet-spot for LE use. The boards are less-featured than RK3588, which makes the boards cheaper, but the peripherals that have been omitted are all things that LE has no use for, while the media capabilites are essentially the same.

    RK3576 actually has a better (or at least newer) multimedia capabilities (VOP3 for RK3576 vs VOP2 for RK3588). Not sure if the all the code to make use of it are upstreamed already though.

  • Seeking login/access details

    Quote from ADKM

    From memory there was some issue at setup and things were done 'differently". Possibly a script of some kind was needed, but impossible to say for sure.

    After reading the links I've been able to change directories and see various files including mountshares.sh and startup.log. I've not found any autostart.sh.

    Permanent mount of Samba share fails may be of use and especially the link referenced there:

    https://wiki.libreelec.tv/how-to/mount_network_share

    Quote

    Are these text files. Is there a way to view them ?

    In Unix/Linux, everything is a file (unless it is a process).

    You can view files in a number of ways: cat, less (quit with 'q') or nano (=text editor)

  • Netflix

    Look through the log files in .kodi/temp/ to see if you can find any hint as to why it is failing.

    Generally, if you want help, you should provide WAY more info (in English) so people have something to go on. Right now it only says "it doesn't work", which is not useful for others to start with.

    Info like 'used hardware'/'LE version' should be considered the bare minimum.

    When errors occur, run pastekodi and share the URL that is printed which generally provides a LOT of information for people to go on.

    HTH

  • shell script to get the latest nightly (old)

    Quote from JoeAverage

    but sorry I guess I never will support those platforms.

    That's quite alright :)

    Quote

    why ?

    look into nightly download directory and compare with your os-release.

    on the first you'll see a lot of "sub-variants" (?, the part between git tag and .img.gz) for .eg. 3328, but no such sub-variants in your os-release.

    Knowing that it's not automatically applicable to all devices, is useful to know.

    I don't know a way to differentiate those sub-variants programmatically either.

    Quote

    and I feel I'm getting old, earlier ~18 h nonstop wasn't a theme. When I have bitten in a task it goes nonstop until tiredness isn't "fixable" with further caffeine and lastely realizing that I repeat the same programming mistake over and over again ... :D

    One of the best and often underappreciated 'debugging' techniques, is taking a break/nap or plainly a good nights sleep ;)

  • shell script to get the latest nightly (old)

    Not requested, but I run LE on a Pine64 Rock64 device:

    which may still help in learning about variations in /etc/os-release outputs

  • Just dug out old PC based Media Centre - will it run?

    Quote from Garzie

    does anyone know if i can plug that in after installing libreelec - or will it not search for and install drivers for that if plugged in after initial install

    On every boot LE (well probably the kernel) searches for and tries to initialize the devices it finds. Including new ones.

    If your (new) soundcard/device is supported by the upstream* Linux kernel, then it should just work.

    *) Upstream means in Linus Torvalds (git) repository. Several devices claim Linux support, but that's only with a highly modified custom kernel. Then it becomes much more questionable whether it will 'just' work on LE.