New Rock64 User Problems

  • Changing the amount of audio channels at the LE audio settings doesn't help?

    Da Flex:

    I am currently letting Kodi autoselect the audio settings (System - Settings- Audio shows ALSA:HDMI, HDMI) with 2.0 channels.

    This seems to match the TVs I am using.


    I'll try using different audio settings and see if that improves things. I'm not sure why this would only be a problem on 3 of my 10 players. You would think that if there was a problem, it would manifest on all the players.


    Thanks for the suggestion.

  • I installed Librelec on my Rock 64 today,


    I don't have any particular freeze, i've got the 4 Go DDR3 version, the only difference is the PSU, i had to buy a PSU from amazon because the rock "stock" one just got killed without doing anything.. (One day i plug my rock64 and my rock led were blinking like crazy, after a bit of research with my multimeter, the PSU wasn't capable anymore to power my rock, so i changed it).


    Unfortunatly i got a issue with video playback. 720p, i don't have a FPS counter on the screen but the framerate i think is about 20 FPS, also in 1080p (even worse).


    I tried with youtube, and unofficial Amazon and Netflix app (those two apps are my goal, i've leave android tv because i can"t use them anymore due to windevine L3 only. Then i tried on librelec and both apps are working fine, execpt the video is laggy (not buffery)


    What's the issue ?

  • Oh, hi totalgaara, what MicroSD are you using?!

    I've used 2 Class 10 SanDisk, 8GB and 16GB

    YouTube worked at 1080p 60FPS very smoothly.

    Netflix at 1080p was impossible, cause is software decoded. Only at 720p

    I don't own an Amazon Account so i can't tell you 'bout that.

    Hope we can solve it.

  • Hi, i'm using the emmc module (16 gb, yeah that explain the high cpu usage when decoding video, maybe i've a good news, but i think it strange that i can't find any information about that.


    Apparently, someone make a build for libreelec and some people say that hardware decoding is working on his build, i will try it, but i don't understand if that person find the solution, why he is not sharing it ?. Edit i was wrong, actually this guy is helping ^^ thank to him


    Unfortunatly, no hardware acceleration, same situation with his build, now i will test with android + kodi


    Another solution i was asking myself this morning was to use Kodi on android build (ayufan), but.. i think we are going to have the same DRM issues with the netflix app..i guess, i'm not sure

    Edited once, last by totalgaara ().

  • i think part of the problem is small variations in the values that effect memory timing as there are now so many people playing with kernel/dtb settings that in some cases what works good for one is a problematic for others... theres still a lot of testing being done as some trying and migrate the kernels to mainstream and settle things out...


    Personally i have 3 of the Pine boards and RockPros and each one of them act a bit different and it took along time to get the kernels and learning routines for the memory time down to the point that all the boards work pretty much the same... what i found weird was that all of my N2's are not prone to this same type of tempermental pickyness... not sure if its just in how RockChip implemented their vcc/timing for all the memory busses or if its something else... Don't get me wrong tho as i am picking on Rockchip tho as to be honest i actually prefer it to any of the Amlogic driven stuff, just a observation on my part as i spent a considerable amount of time building IDE's for both platforms as I use both platforms for control boards for other projects not simply just as media players...


    Kodi on Android will always be inferior to Kodi on *unix but until full open source gpu stack for *unix is finished and out in the open, Android is still the only real avenue for acceleration using its blobs... Outside of the public realm there are private fixes but they still require custom blobs that are created by the ones creating the fixes... at least those blobs are working on current 5.3 kernels, meaning your not being held back by depending on blobs tied to the version of Android...

  • I come back with some bad news unfortunatly.


    Video playback in youtube as ElBoluTony say work fine, like youtube.


    The reason why we can"t play 1080p (and 720p, it's not pleasant...) is because the Netflix addons and the Amazon prime video extension use the CPU to "decrypt" windevine DRM protected content.


    Our rock64 has only L3 Windevine, while we need L1. So that L1 is "emulated" and use a lot of CPU ressources, because the GPU is in this case : totally useless , that's why the playback is not good, Rock64 is not powerfull enough...


    Don't know what we can do more, i love that device, but seriously i start to hate it, we can do nothing on it... Android TV, you can dream to use netflix or amazon prime video app, even if it was, it will be SD video playing because of L1 DRM


    Unfortunatly on lLibrelec, we have a chance but the L1 emulation use too much power, don't know if it fixable

  • I already posted several LibreELEC builds for MVR9, Rock64, ROC CC with 720p Netflix software decoding support.

    But seems no one even uses it. Search for it in the forums.

    Devices like the RockPi 4 RK3399 can even decode 1080p Netflix in LibreELEC with my image.

  • I already posted several LibreELEC builds for MVR9, Rock64, ROC CC with 720p Netflix software decoding support.

    But seems no one even uses it. Search for it in the forums.

    Devices like the RockPi 4 RK3399 can even decode 1080p Netflix in LibreELEC with my image.

    Yeah i didn't know about your build ?


    is it that file ? LibreELEC-RK3328.arm-9.1-devel-20190314143101-e738c7b-roc-cc.img.gz


    The RockPi4 is more powerfull than the rock64, that's why i think 1080p is playing fine, but i'm still looking to get it on the rock 64

  • Well thats not exactly true.... Discussing hacking of DRM's i don't think is something allowed here but anyone that truly understands Arm's Tee and enough about emulating decrypt/decode routines would disagree with you... its more about no one wanting to take on the issues of messing with DRM protection out in the public domain...