feedback for test build LibreELEC-RK3328

    U-Boot problems:

    1) My (Fast) Ethernet adapter isn't seen.

    2) "usb start" generates an exception and reboots, even with no external USB devices connected.

    However Ethernet and USB work fine once LibreElec is booted :)

    I am running the generic box version on a Scishion V88 Piano.

    Do people running other versions on different hardware have the same problems?

    Quote from TrashCanMan

    Can there be something related to the ethernet driver used by libreelec that limit the upload? its the same driver/options that the omv people use?

    See build/armbian-hardware-optimization at master · armbian/build · GitHub for some hw optimization moving interupt handling to different cpu cores and more.

    Unsure if this scripts will run on LE as is but could be interesting to test with some of these optimization.

    Quote from shadowmask

    My (Fast) Ethernet adapter isn't seen.

    "usb start" generates an exception and reboots, even with no external USB devices connected.

    I reverted gmac2io support for rk3328 in u-boot to fix an wifi issue on the rockbox, all rk3328 targets share u-boot config at the moment, I will probably create device specific configs to try and work around device specific issues, I have also seen usb crashes and I suspect this is because of different gpio pins used

    Quote from Kwiboo

    See build/armbian-hardware-optimization at master · armbian/build · GitHub for some hw optimization moving interupt handling to different cpu cores and more.

    Since im trying anything i have at hand ill try it anyway but i did an iperf and it nearly toped the gigabit AND never toped any cpu at 100% so the chances are very slim that the issue is there IMO but also, iperf works virtually, its not using both hdd and eth at the same time...maybe you got something there...

    I did a basic dd test to be sure since the hdparm test was for reads:

    Code
     dd if=/dev/zero of=output bs=1M count=4096; rm -f output
4096+0 records in
4096+0 records out
4294967296 bytes (4.0GB) copied, 68.344728 seconds, 59.9MB/s

    i got about that speed on OMV so i guess my hdd limit is there, i also tested some tuning from the script you suggested:

    - IO scheduler is already at cfg for my device, no change done there.

    - all this make no change on the "issue" (taken from the script):

    Code
    echo 7 >/sys/class/net/eth0/queues/rx-0/rps_cpus
echo 32768 >/proc/sys/net/core/rps_sock_flow_entries
echo 32768 >/sys/class/net/eth0/queues/rx-0/rps_flow_cnt
/sbin/ethtool -K eth0 rx off tx off
ifconfig eth0 down && ifconfig eth0 up

    - the part about storage quirk is also active since my drive isnt using UAS, its using the standard usb-storage driver (also i dont think its part of my issue since dd and hdparm give good values)

    But there are parts of the script that i dont know how to split since my coding skill is allmost null, specially the parts about the /proc/interrupts spliting and the governor cpufreq increase (this last is even needed? afaik we work permanently on performance)...(remember i have a rock64, section rockchip64 on the script), anyway thanks in advance for any/all the help :D

    Kwiboo I kept searching and trying things on my own, my notes:

    So, i tested the suggested script and made allmost no difference, if at all all this made the speed more spiky, less stable but spikes never go over about 35MB/s and go down to 25MB/s, are you sure there are nothing limiting the speed on libreelec? the weird thing is that read does 30MB/s and write does over 90MB/s (most of the time its near 100MB/s), i mean, usually in any media writing is slower than reading (also remember that i had OMV installed before this on the same board, same cables, same HDD, same all, and i was getting around 70MB/s on both read and write)...do you need me to open a bug report somewhere? no idea if you or other developers use any github/bug tracker...

    Also i cant find it but i had a copy of the samba.conf from when i was usign OMV and the optimizations where identical to the ones Libreelec uses, i can search it if you need to compare, i have a copy of the whole OMV card somewhere...

    Edited once, last by TrashCanMan (October 18, 2018 at 6:27 PM).

    Ignore all my ranting, apparently its some problem with w10 i think, i dont have another hdd to test atm but created a 3gb ramdisk on my second rock64, transfered a file there, result: 55MB/s without any tuning at all on the other rock64, also im pretty sure its a pretty inneficient test for a start and i got more juice out of it...so...sorry about all the hot air, im going to google about w10 samba issues, thanks anyone for reading...

    Hey guys, I just want to report my troubles with 8.90.006 on Rock64.

    When I play a movie (whatever type/resolution) I have screen freezes and after few seconds it play again normally. Sounds goes on still. Workaround is rewind few seconds back or wait. First I thought there’s a problem with my usb3(in powered usb3 switch) but it’s the same behavior when I move a movie to SD card. The screen doesn’t freeze in the same time twice, it is “random”.

    Don’t know if it is related but Kodi in idle can take up to 45% cpu time. Not sure how much it took when playback/screen freezes. Worth find out I gues :)

    Hi,

    Just to share my recent experience with LE 8.90.006 on Rock64,

    I have been using XBMC/Kodi since the days of the original xbox, across multiple platforms over the years.

    I have a central Linux file server, serving files via NFS, it also hosts a Mariadb MYSQL server to allow multiple kodi clients around the house to share the same database.

    I installed LE 8.90.006 on my 1GB RAM Rock64 last night and tested playback of multiple file formats for around 3 hours. I found no significant issues with playback of SD, HD or UHD content from NFS file shares over Fast ethernet (100Mbps). HDMI CEC works well with my Samsung TV and I uploaded my remote.xml file from one of my other kodi clients so I could use some of the other buttons on my Samsung TV remote. Again all working well.

    Considering this is an Alpha distribution of a Kodi Beta, I think it's great!

    Thanks ever so much for developing a distribution of LE for the Rock64.

    Feedback for LE 8.90.006 on Z28 Pro (RK3328):

    Issues:

    - VC1 videos are not HW accelerated

    - 1080i 59.94 fps h.264 videos are not deinterlaced and played at 29.97 Hz

    - 576i 50 fps mpeg2 files with pulldown flag (iso, mpg, vob) are not deinterlaced and played at 25 Hz

    - 480i 59.94 fps mpeg2 files with pulldown flag are not deinterlacing

    For picture quality:

    Direct To Plane Method:

    - Visible banding and clipping (tested with Spears & Munsil test video)

    EGL:

    - No banding, but the clipping same as Direct To Plane

    - 10 bit videos have no picture

    Overall the SD upscaling is bad quality (same as Amlogic).

    Thanks for your work!

    Quote from soerenderfor

    Thanks for libreelec to Rock64, i am a big fan of RockChip. The picture quality is so much better than amlogic.

    I have an Amlogic S905X and an S912 with CoreELEC.. Please use limited color space.

    The Rockchip are clipping white and chroma, so the picture quality is worse than Amlogic.

    Quote from djnice

    I have an Amlogic S905X and an S912 with CoreELEC.. Please use limited color space.

    The Rockchip are clipping white and chroma, so the picture quality is worse than Amlogic.

    I dont understand, with my eyes the picture quality on my rock64 is much better than Odroid C2. Do you use some special settings?

    But i will also say i am not an expert, do you have any tips? I have tried these different commands in the config. On both Rockchip(Rock64) and amlogic(Odroid C2) on Libreelec and Coreelec. And the 422,8 bit was the best if i remember correct on my LG55

    echo '444,10bit' > /sys/class/amhdmitx/amhdmitx0/attr

    echo '444,8bit' > /sys/class/amhdmitx/amhdmitx0/attr

    echo '422,10bit' > /sys/class/amhdmitx/amhdmitx0/attr

    echo '422,8bit' > /sys/class/amhdmitx/amhdmitx0/attr

    Edited once, last by soerenderfor (October 21, 2018 at 2:32 PM).

    Quote from djnice

    Please use limited color space.

    Do not enable Use limited colour range (16-235) in Kodi when using Rockchip, instead enable full range on TV when using RGB output or colors will be wrong.

    I am currently working on an update that will hide this option and also makes it possible to select between 4:2:2 and 4:4:4 YCbCr output instead of just 4:4:4 YCbCr.

    Quote from Kwiboo

    Do not enable Use limited colour range (16-235) in Kodi when using Rockchip, instead enable full range on TV when using RGB output or colors will be wrong.

    I am currently working on an update that will hide this option and also makes it possible to select between 4:2:2 and 4:4:4 YCbCr output instead of just 4:4:4 YCbCr.

    Thanks, but my Toshiba TV does not have full range setting. The Rockchip can't output limited range?

    YCbCr 4:2:2, 4:4:4 is the color space, not the range. All movies are in YUV 4:2:0 limited (16-235), not RGB full.

    Video levels and color space - Official Kodi Wiki

    Quote from djnice

    Thanks, but my Toshiba TV does not have full range setting. The Rockchip can't output limited range?

    Rockchip currently can output:

    1. RGB Full Range (YUV video is clipped and scaled from 16-235 to 0-254). Set TV to Full Range - WtW & BtW clipped, Single video scaling.

    2. YCbCr 4:2:2/4:4:4 Limited Range (RGB gui is scaled from 0-254 to 16-235). Set TV to Limited Range - WtW & BtB preserved*, Zero video scaling.

    Recommended and default settings:

    - Use limited colour range (16-235) should be set to False

    - System -> HDMI Output Format should be set to RGB

    - Player -> HDMI Output Format should be set to YCbCr

    - TV should be set to Full Range when RGB is used and Limited Range when YCbCr is used

    *In current build the Video Output Processor is configured to clip YUV WtW & BtW values before it is sent out over HDMI.

    Thank you, I will try!

    For interlaced videos:

    I discovered, only MBAFF videos are wrong (59.94i and 50i too). I uploaded an 50i sample, the Amlogic plays at 50Hz with proper deinterlacing, the Rockchip plays at 25Hz without deinterlacing: https://drive.google.com/open?id=1s-9nsjh-ljrheb_xgh_l0ufhegyufxrr