feedback for test build LibreELEC-RK3328

    Quote from muya

    the audio dropouts are every 5 minutes and only for 23,976fps (AC3 and DTS).

    would be interesting if you could reproduce it

    you can test with my sample i created, if needed

    I have finally done some tests of your sample on my Rock64 + LG OLED55B7V + Sony HT-Z9F using a combo of LPCM, AC3 PT, 23.976hz and 60hz. I could not notice any dropouts or sync issues using the latest 4.4 kernel (contains fixes for fractal clocks).

    I will try to get the kernel update pull request merged in next few days after I have completed testing on Tinker Board S and RockPro64.

    So, as I finally got my hands on a Rock64 4gb Friday, I thought I should weigh in here with tome tests, too (as the Rock64 is a RK3328 device, too).

    I conducted tests with the 20180601 nightly build, as well as the "part-7" branch from Kwiboo. I also tried to compile the "part-6" branch, but that failed

    to compile (something about missing GDM - I presume it has something to do with this).

    EDIT: I noticed while writing this that Kwiboo rebased "part-6", I will try to compile this again now. I will also compile the current master, since this includes some neat changes.

    I did test the following files, all 1080p if not noted otherwise:

    BigBuckBunny 60fps, both 1080p and 4k

    Anime A:

    - FFProbe: h264 (High 10), yuv420p10le(progressive), 1440x1080 [SAR 1:1 DAR 4:3], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)

    - VLC: H264 - MPEG-4 AVC (part 10) (avc1) / Planar 4:2:0 YUV 10-bit LE

    Anime B:

    - FFProbe: hevc (Main), yuv420p(tv, unknown/bt709/unknown), 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)

    - VLC: MPEG-H Part2/HEVC (H.265) (hevc) / Planar 4:2:0 YUV

    Series episode:

    - FFProbe: h264 (High), yuv420p(progressive), 1920x1080, SAR 1:1 DAR 16:9, 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)

    - VLC: H264 - MPEG-4 AVC (part 10) (avc1)

    Movie:

    - FFProbe: h264 (High), yuv420p(tv, bt709/unknown/unknown, progressive), 1920x804, SAR 1:1 DAR 160:67, 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)

    - VLC: H264 - MPEG-4 AVC (part 10) (avc1)

    LibreELEC-RK3328.arm-9.0-nightly-20180601-19b9bed-rock64

    - BigBuckBunny 1080p: Works flawlessly

    - BigBuckBunny 4k: Video plays "to slow", and is out of sync with audio

    - Anime A: Unwatchable because of video stutter

    - Anime B: Works flawlessly

    - Series episode: Works flawlessly

    - Movie: Works flawlessly

    Kwiboo "rockchip part 7" (a9bed38daf236ecd502357890ae2bc47a55cf9c4)

    - BigBuckBunny 1080p: Works flawlessly

    - BigBuckBunny 4k: Video plays "to slow", and is out of sync with audio

    - Anime A: Unwatchable because of video stutter

    - Anime B: Works flawlessly

    - Series episode: Works flawlessly

    - Movie: Works flawlessly

    Other things to note which are of interest:

    - Anime A did run ok on my Rasperry Pi 3 with LE 8 and 9, but had very annoying color artifacts (probably because of 10bit?)

    - I did experience some problems across the builds with resumed playback - stuttering and outright stuck playback. But I was unable to reproduce this yet :|

    - I have no idea why the movie works, and the series episode doesn't (on 20180601) - for all I know they are encoded the same way. (see point above)

    - Neither 1080p nor 4k BigBuckBunny ran on the Rasperry Pi 3 (1080p with stutter, 4k did not even run)

    - The movie file works fine via NFS or USB, but stutters via SFTP. This happens on the Raspberry Pi, too - I have yet to figure out why (network is fast enough, and my laptop doesn't have the problem) (if found the reason - SFTP transfer speed is limited to 30mbit for me. I will investigate). All I know is that the bit rate peeks at 60mbit at the opening logo - which is when the stuttering happens.

    Edited 2 times, last by Kernle32DLL (June 10, 2018 at 9:26 AM).

    Quote from Kernle32DLL

    I also tried to compile the "part-6" branch, but that failed to compile (something about missing GDM - I presume it has something to do with this).

    You are correct, there was a missing depend from kodi to gbm-rockchip, please try the latest from rockchip-part6 again, it should have the correct depends now. Part6 now also contains work-in-progress kodi patches that will limit and scale gui to 1080p/720p when playing 4k video and unlocks 4k@50/60hz resolutions.

    The part7 branch is a bit outdated and is mainly a stash with mainline kernel code, I will pick up once part6 is merged.

    The VPU in RK3328 do not seem to handle bbb h264 2160p 60fps but should handle the h264 2160p 30fps version, guess it is a hw limit (I have not tested any other 4k h264 60fps video).

    Quote from Kwiboo

    The VPU in RK3328 do not seem to handle bbb h264 2160p 60fps but should handle the h264 2160p 30fps version, guess it is a hw limit (I have not tested any other 4k h264 60fps video).

    Hmmm, thats strange. Considering that the Pine64 webpage advertises the Rock64 (with RK3328) as "64-bit 4K60P HDR Media Board Computer". Well it does not mention with what encoding, tho :D

    Quote from Kwiboo

    You are correct, there was a missing depend from kodi to gbm-rockchip, please try the latest from rockchip-part6 again, it should have the correct depends now

    Will do

    Kwiboo

    LibreELEC (community): nightly-20180603-330aad4 (RK3328.arm)

    This update didn't go very well. I presume the migration was for the whitelist option whatever.

    My TV Booted into 640 x 480

    Input Stream Adaptive, RTMP Input

    Became incompatible.

    System Settings Display

    I noticed there were two 1080p in the list to choose from.

    I chose the first one and it changed to 60hz.

    Second one switched to 59.94hz

    There is no 1080p 50hz

    Whitelist for 1080p

    1080p 60hz / 59.94hz / 24hz / 23.987hz

    Again no 50hz

    Bottom line is i can't use this version due to TV Headend Client Live tv or recordings not adjusting refresh rate from GUI and upon stop i get the dreaded black screen.

    BTW : I took screenshots which are just a .png of a black screenshot.

    I tried SSH but obviously things don't work like they used to in the old s905 boxes.

    Code
    LibreELEC (community): nightly-20180603-330aad4 (RK3328.arm)
LibreELECrock64:~ # fw_printenv hdmimode
-sh: fw_printenv: not found
LibreELECrock64:~ # fw_printenv outputmode
-sh: fw_printenv: not found
LibreELECrock64:~ # fw_setenv hdmimode 1080p50hz
-sh: fw_setenv: not found
LibreELECrock64:~ # fw_setenv outputmode 1080p50hz
-sh: fw_setenv: not found
LibreELECrock64:~ #

    I tried Kwiboo s branch "rockchip-part6" at d404a14.

    From what I can tell, this fixes the "black-after-stop" issue (as seen by kostaman in 330aad4).

    More importantly this also makes "Anime A" work for me. That is, the x264 10bit one. And cherry on top - no color artifacts like I got on my Raspberry Pi 3 \o/.

    Also, I did not encounter any video stuttering (or other problems) on resumed playback. I'm not 100% sure yet if its actually fixed tho, as I was unable to reproduce it reliably anyway.

    Thanks a lot for your work Kwiboo ! :)

    EDIT: Also, I noticed that the errors which currently occur on 330aad4 (see attachment) when doing the initial startup (with partition resizing, etc.) are gone with the mentioned branch. Nice!

    Quote from Kernle32DLL

    I tried Kwiboo s branch "rockchip-part6" at d404a14.


    From what I can tell, this fixes the "black-after-stop" issue (as seen by kostaman in 330aad4).

    Well done. Thank you for the information.

    BTW have you or anyone tried using Android TV running on eMMC and LibreElec running via SD Card at the same time ?

    I cannot get LE to run whilst eMMC is inserted.

    It boots to a certain stage but freezes.

    Quote from kostaman

    BTW have you or anyone tried using Android TV running on eMMC and LibreElec running via SD Card at the same time ?

    I cannot get LE to run whilst eMMC is inserted.

    It boots to a certain stage but freezes.

    Make sure that all eMMC/SD partitions are labelled differently, and that they match their entries in the corresponding configuration files, respectively:

    e2label <-> /boot/efi/extlinux/extlinux.conf

    dosfslabel <-> /etc/fstab

    Otherwise the wrong partition(s) may be mounted at boot time.

    Quote from LeoD

    Make sure that all eMMC/SD partitions are labelled differently, and that they match their entries in the corresponding configuration files, respectively:

    e2label <-> /boot/efi/extlinux/extlinux.conf

    dosfslabel <-> /etc/fstab

    Otherwise the wrong partition(s) may be mounted at boot time

    I'm out of my depth here. Only have MacOS to SSH via Terminal App. No linux machine. Happy to try command lines that will output more details.

    See SSH Output.

    I booted up with eMMC Android TV and LE SD Card both inserted.

    First boot : It booted into LE Splash screen but error codes all over screen. SSH was alive so i logged .

    LibreELECrock64:~ # paste /storage/.kodi/temp/kodi.log

    http://ix.io/1cry

    LibreELECrock64:~ # dmesg | paste

    http://ix.io/1cs0

    Second & Third attempt Booted to LE Home Screen. SSH but it froze. Got some logs.

    # dmesg | paste

    http://ix.io/1cs4

    # paste /storage/.kodi/temp/kodi.log

    http://ix.io/1cs5

    # paste /storage/.kodi/temp/kodi.log

    http://ix.io/1csg

    # dmesg | paste

    http://ix.io/1csi


    I Removed eMMC and Rebooted with SD Card Only.

    log-2018-06-06-07.36.35.zip

    kostaman thanks for the log files, I will look into the emmc issue in a few days/next week

    I have uploaded test .http://img.gz/.tar files for rock64 and box-trn9 at Index of /test/ built from my latest rockchip-part6 branch.

    It includes RendererDRMPRIME: release video buffers after flush by Kwiboo · Pull Request #13978 · xbmc/xbmc · GitHub that should make playback a little bit more reliable.

    Please report new issues seen on these images compared to latest nightly.

    Quote from zarusz

    Are all the changes/fixes mentioned above and done by Kwiboo part of today's nightly build?

    LibreELEC-RK3328.arm-9.0-nightly-20180606-598f67c-rock64.img.gz

    Yes, all fixes mentioned in this thread should be included in that build, it has been pretty stable on my main testing device (Rock64 / Transformer).

    EDIT: Sorry, I misread, the nightly images do not contain any fixes yet, please test libreelec-rk3328.arm-9.0-devel-20180606204626-0267cea-rock64.img.gz, that image should include all fixes mentioned in this thread.

    This test build have latest rockchip 4.4 kernel, latest rkmpp library, latest rkbin ddr/miniloader firmware, and my work-in-progress Kodi branch (including the same fix for black-after-stop that is included in Raybuntu's Rock64 images)

    Edited once, last by Kwiboo (June 6, 2018 at 10:43 PM).