feedback for test build LibreELEC-RK3328

    Hey, do someone have same problem with subtitles not showing in HEVC files?

    It works with ODROID C2, but i will love to get it working om my ROCK64 i just love the picture quality on the ROCK64.


    Best Regards

    I tried the new 8.90.007 on my rock64, and so far I have not seen the freeze or audio only after leaving a video paused for a long period of time issue.

    Unfortunately I am still unable to shut off the tv when left paused via the screen saver (seems to work when I press preview, but not in daily use).

    This is a move in the right direction. :)

    Keep up the good work!

    Hi, I’ve wrote it recently but I’ll ask again. Doesn’t anyone have the same problem: When watching movie (whatever type, from usb3 hdd/sd card) the screen stops subtitles stop but sound goes, this lasts few seconds and then everything goes normally, it happens several time during the movie. When I rewind the “lagging” passage it will play then normally(so it is not corrupted) This lagging is randomly. Sometimes after 10minutes sometimes 3 lagging passages in short interval.

    Rock64 clean install 8.9.007 without any addons. 🤔🤷🏻‍♂️

    Update: this is in the log from that time

    Code
    Nov 17 12:21:52 LibreELEC kernel: rk_iommu ff360480.iommu: FORCE_RESET command timed out
Nov 17 12:21:52 LibreELEC kernel: rk-vcodec ff360000.rkvdec: Failed to attach iommu device
Nov 17 12:21:52 LibreELEC kernel: rk-vcodec ff360000.rkvdec: vcodec service attach failed
Nov 17 12:21:52 LibreELEC kernel: rk-vcodec ff360000.rkvdec: resetting...
Nov 17 12:21:52 LibreELEC kernel: rk-vcodec ff360000.rkvdec: reset done
Nov 17 12:21:52 LibreELEC kernel: rk-vcodec ff360000.rkvdec: reset done

    Edited once, last by johnyor (November 18, 2018 at 7:59 PM).

    Quote from johnyor

    Hi, I’ve wrote it recently but I’ll ask again. Doesn’t anyone have the same problem: When watching movie (whatever type, from usb3 hdd/sd card) the screen stops subtitles stop but sound goes, this lasts few seconds and then everything goes normally, it happens several time during the movie. When I rewind the “lagging” passage it will play then normally(so it is not corrupted) This lagging is randomly. Sometimes after 10minutes sometimes 3 lagging passages in short interval.

    Rock64 clean install 8.9.007 without any addons. 🤔🤷🏻‍♂️

    Update: this is in the log from that time

    Code
    Nov 17 12:21:52 LibreELEC kernel: rk_iommu ff360480.iommu: FORCE_RESET command timed out
Nov 17 12:21:52 LibreELEC kernel: rk-vcodec ff360000.rkvdec: Failed to attach iommu device
Nov 17 12:21:52 LibreELEC kernel: rk-vcodec ff360000.rkvdec: vcodec service attach failed
Nov 17 12:21:52 LibreELEC kernel: rk-vcodec ff360000.rkvdec: resetting...
Nov 17 12:21:52 LibreELEC kernel: rk-vcodec ff360000.rkvdec: reset done
Nov 17 12:21:52 LibreELEC kernel: rk-vcodec ff360000.rkvdec: reset done

    My movies play fine the whole way on my Rock64. Could your board be overheating? Random lagging could be the OS trying to cool off the cpu by slowing it down.

    I've just tried it (x264 movie playback) again, copied to SD instead of using usb3 ext hdd (in powered hub) still the same. when I open Codecinfo I can see no dropped frames nor skipped. But when the video freezes - Player a/v increases up to ca 10s and then drops to 0.0xx and video plays normally

    Feedback for nightly LibreELEC-RK3328.arm-9.0-nightly-20181122-4ad81f9-rock64.img.gz

    Media encoded with xvid at 640x480 and Divx DX50 at 512x384 is playing back in a lagging fashion. It feels like it is playing 3 frames and then skipping 3 frames. Other resolutions might be impacted, but these were ones I could find in my media collection.

    Same media plays fine on other devices.

    So what's the root issue behind the 4k 60fps lag when playing BBB on a Rockchip board? Definitely skipping some frames, and I know there's been some discussion surrounding the issue. Just wondering what's actually causing it and if there's any plan to resolve?

    It's probably that the rkvdec device tree is disabled (among other things, including VPU and RGA).

    At least on my setup, it is.

    (rockpro64 on ayufan 4.4.138-1100)

    You can have it enabled in the kernel, you can have libmpp installed, and you can have mpv compiled to use hwdec=rkmpp, but....:

    rkvdec@ff660000 status = "disabled" in my /sys/firmware/fdt

    I know that it's needed for x265/HEVC/etc.

    It worked!

    On a whim I ran dtedit and enabled RKVDEC, RGA, and VPU, and rebooted, and now 4K videos and HEVC/x265 videos play without dropping any frames using rkmpv

    (Your mileage may vary, I have been editing my DTB a lot lately and I've removed all PCIE from it.)

    Quote from fosf0r

    It worked!

    On a whim I ran dtedit and enabled RKVDEC, RGA, and VPU, and rebooted, and now 4K videos and HEVC/x265 videos play without dropping any frames using rkmpv

    (Your mileage may vary, I have been editing my DTB a lot lately and I've removed all PCIE from it.)

    Do you have a guide to do it, or can you explain how? Best Regards.

    Edit: I should have mentioned, I accomplished this on ayufan's debian images, not any libreELEC ones, with a ROCKPRO64, not a rock64, sorry about the confusion. I bet the majority of these things are similar though.

    I flashed bionic-minimal-rockpro64-0.7.11-1075-arm64.img.xz

    And then downgraded it to kernel 4.4.138 of my own building.

    4.4.154 is messed up for me, at least on ayufan.


    ( Small note: I use "joe" as my editor. You might be using "nano". I don't know how to use any other editors than joe, so I can't tell you commands for your editor. )

    First, make sure you are able to mount your boot device (emmc or SD card) filesystem on another Linux system, because if your system crashes from making this change, you won't be able to get back in to undo the changes.

    To recover from this, you would have to mount partition 7 on another system and edit /boot/extlinux/extlinux.conf to either point to the original devicetreedir of /boot/dtbs/4.4.x-stuff/ or to point fdt to your backup copy of /boot/dtb-4.4.x-stuff.

    - - - -

    Backing up current settings:

    Run dtedit

    That will launch your current default editor.

    Don't make any changes, just immediately exit the editor.

    That will cause ayufan's scripts to send your current DTB to a file in /boot

    Now please ls -al /boot and see if you see a file called /boot/dtb-4.4.x-stuff (where "stuff" is whatever your filename is, I don't know it since I built my own.)

    Make a backup of that file.

    cp /boot/dtb-4.4.x-stuff /boot/dtb-4.4.x-stuff-WORKING

    Also note the "source" file is there too, only difference is the "s" in the filename:

    /boot/dts-4.4.x-stuff

    Also make a backup copy of that source file if you want.

    - - -

    The main event:

    Now use your editor and edit the source for the dtb:

    /boot/dts-4.4.x-stuff

    While editing that file, search for rkvdec

    Within the rkvdec braces { }, find status = "disabled"

    And change that to status = "okay"

    Save and exit the editor.

    ayufan's scripts will automatically recompile the changes into /boot/dtb-4.4.x-stuff

    (You did back yours up first right?)

    Now you may want to edit /boot/extlinux/extlinux.conf

    And make sure there aren't multiple kernels, and make sure that the fdt line is present and points at that file.


    ----------


    RECOVERY IF IT FAILS:


    Here is my entire extlinux.conf so you can compare to your own.

    My device hostname is called 'kodiplex' since I was building both of those programs, and my customized 4.4.138 kernel is tagged 'kodiplex' too so it is literally version "4.4.138-kodiplex" for me, just ignore that and substitute with the proper ayufan name and version that yours is.

    If your extlinux.conf is using "devicetreedir" instead of "fdt" then your edit will NOT take effect

    The below is what it looks like for me, with the edit in place, working.

    If yours doesn't boot, scroll down to the next code block and fix the fdt line like I show below:

    Code
    timeout 10
menu title select kernel
label kernel-4.4.138-kodiplex
kernel /boot/vmlinuz-4.4.138-kodiplex
initrd /boot/initrd.img-4.4.138-kodiplex
fdt /boot/dtb-4.4.138-kodiplex
append rw panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 root=LABEL=linux-root rootwait rootfstype=ext4


    The line you should fix in extlinux.conf if your system fails to boot is the fdt one, you'd set it to point to the "WORKING" copy that you made before editing all of this:

    Code
    fdt /boot/dtb-4.4.138-ayufan-stuff-WORKING


    Alternatively, if /boot/dtbs/ is present, you could delete the whole "fdt" line and replace it with a "devicetreedir" line to get your system back to normal again:

    Code
    devicetreedir /boot/dtbs/dtb-4.4.138-ayufan-stuff/

    ! All your mileage may vary, since I quit using a lot of ayufan's automation/packages and began building my own kernel and software !

    Edited 2 times, last by fosf0r: Had to clarify I'm using ayufan images (November 29, 2018 at 9:15 PM).