Posts by wkchick

    I believe we are almost there. There's been couple of builds released in just two days. I tested LibreELEC-AMLGX.arm-9.1-devel-20190604130101-a41fdf1-box.img.gz on a MiniMX-III II (S905x), using meson-gxl-s905x-p212.dtb (for LibreELEC with kernel 3.14 it was gxl_p212_2g.dtb),

    Boot: OK

    Ethernet: OK

    WiFi: No

    Audio: OK (but unlike Kwiboo's build, only meson-gx-audio analog, no HDMI)

    CEC: OK

    Remote: OK (after modified rc_maps.cfg)

    x264: Plays OK

    x265 10bit: Plays OK (but halt after 15 minutes of playback, still respond to remote).

    TVH client: OK


    I also tested LibreELEC-AMLG12.arm-9.1-devel-20190603165839-a41fdf1-box.img.gz on X96S, an Android TV stick that's based on S905Y2). There is no Ethernet, only WiFi (both 2.4GHz and 5GHz band). I tried all dtb available, only meson-g12a-x96-max.dtb and meson-g12a-x96-max-rmii.dtb can boot properly.

    Boot: OK (with either meson-g12a-x96-max.dtb or meson-g12a-x96-max-rmii.dtb)

    WiFi: No

    Audio: OK

    Remote: OK right out of the box

    x264: Plays OK

    x265: No


    WiFi chip on the X96S is Ampak AP6255 which is the same as that on Khadas-VIM.


    Thank so much for making such progress in relatively short period of time. Before today, I thought my X96S stick could never have LibreELEC. Also with progress made on S905, I wish RK3328, which based on the same GPU could be benefit too.

    Do you have a shorter sample of a video that cause such freeze/catchup? Would be interesting to test on my board.


    Hopefully getting h264/hevc hw decoding on mainline wont take too much time (weeks).

    I just prepared a short sample video. You can download it from here.

    As far as I could remember I also get my Power Supply from the Factory (Pine64). After all, it's almost two years and I got bad memory.


    Our ROCK64 SBCs have the same date code 1748 (I presume it means year 2017 week 48), the only difference is you have 4GB RAM while I have only 2GB (I guess Carey got 2GB RAM as well). Hence it is possible that the manufacturer used RAM chip of different speeds for 4GB and 2GB variants. Or it might be the the newer kernel (4.4.156) requires more RAM to render?


    If it is the power supply, then I do know how to explain why I got no issues with previous kernel 4.4.142. Anyway I will try to find another power supply to test. It won't be easy as it is not a microUSB socket.


    @kostman, may I ask the brand, size and speed of your microSD card?

    This is expected, the linux v5.x images only have MPEG-2 hw decoding (for now), everything else is sw decoded and there is an issue with 10-bit video (will show as green).


    Does the image work / boot / do not crash compared to latest nightly or the recently released 8.90.015 image?

    Kwiboo , Sorry, I overlooked your previous post that already stated only MPEG-2 hw decoding. I just tested with MPEG-2 video and playback is flawless.


    For me, all image files work / boot properly. My only problem is playback of HEVC video freezes and then catchup every 15 to 20 seconds for images after 2018/10/02, up to the latest 8.90.015.

    I do not have a device tree for the trn9 box on mainline kernel currently, only roc-cc, rock64 and rockbox, I will try to add the missing ones before I create a new mainline testing thread and post all linux v5.1 images (later today).

    I tested your linux 5.1 image on my ROCK64 with the fastest speed microSD card I can get. HW acceleration is still not working (green screen but audio is fine). Once I turned off HW acceleration, video playback just like everything in slow motion.


    EDIT: Unlike other images, the Pine A64 remote control doesn't work. It isn't a big issue as CEC is working and I can use the TV remote instead, just want to let you know.

    mo123 I really appreciate your feedback.


    So to be clear, are you saying that you think just the dtb file needs to be revised on the current builds for the ROCK64 V2.0 boards? And not the older kernel and system files as well?


    Thanks for helping me understand.

    I played around with different combinations of dtb and build images before and found not much differences. I believe the main issue is due to the newer linux kernel 4.4.154. One way to prove is to get LibreELEC 9.0.2 with kernel 4.4.142 and test. I understand that they are working on kernel 4.20, that why I had never reported this before.

    I thought you used the usual update method (copy the tar file to the update directory using Samba and then reboot) to roll back from any current version to that one dated 2018/10/02. Anyway, it doesn't matter as long as it works! I sometimes use your approach (copy KERNEL, SYSTEM and dtb files to the FAT partition of microSD card) to update as well.


    I also experienced occasionally hang up of the SBC before with the build on 2018/10/02, I think you can rule out you got a defective ROCK64.

    I believe we have the same ROCK64, as least the circuit board is the same. The heat sink I have can only cover only the RK3288 processor. It's about 13 x 18mm in size. My Odroid-C2 is equipped with a much bigger heat sink. Heat sink on Rock Pi 4 is also bigger.


    You need to prepare the SD card with an image file, either the rb image or any one downloaded from LibreELEC website. I would suggest you prepare the SD card with this LibreELEC-rock64.arm-rb-leia24.img.gz first. If it works (or there's no more kernel panic), then update using the tar file. I personally did this process once today.


    BTW, the linux kernel of recent testing image released after 2018/10/02 is 4.4.154 whereas the kernel before that is 4.4.142. For me, there is no stuttering at all for the two LibreELEC builds I uploaded. If anyone could prepare a build with Kodi 18.2 (LibreELEC 9.0.2) with kernel 4.4.142, that would be fantastic!

    Carey , I share your feeling on ROCK64, only I've never experienced kernel panic. I bought my ROCK64 SBC in 2017. FYI, the board marked ROCK64 2,0 2017-0713 with date code 1704. There is no eMMC and I used only 16GB microSD card. I got the same 5V3A AC adapter as you did, together with the remote control from PINE64.


    I experienced with kernel 4.4.156, heavy stuttering during playback of 720p and 1080p HEVC (8-bit or 10-bit) video files. Every 10 or 15 seconds, the video freezes for a few seconds and then playing catch up. Then the same thing repeats itself again while audio is fine. The last good (or less problematic) kernel was the one released on 2018/10/02.


    Would it be the hardware problem? AC adapter (voltage unstable)? Processor temperature too high due to heat sink too small? I don't think so. In fact before LibreELEC official release, I was testing Raybuntu's ROCK64 build and that was good at least for video playback. After I read your post, I pull the image file out and test it once again on the same hardware and playback was smooth, no stuttering or audio out of sync at all for the whole movie. Color is also very good.


    I still keep the image file of the last build by Raybuntu LibreELEC-rock64.arm-rb-leia24.img.gz but only the tar file (for update) of 2018-10-02 LibreELEC-RK3328.arm-9.0-nightly-20181002-8b3e678-rock64.tar, you can download from here and test them on you SBC if you like.


    I also tested the image that Kwiboo suggested with kernel 4.9 or 5.0, If I turned on HW acceleration, video was not playing at all but audio was fine. If I turned off HW acceleration, video was playing significantly behind the audio but no stuttering. All tests were done with the same video 10bit HEVC 1080p video file on the same SBC hardware.

    Hi,


    Are there any PVR clients included in LibreELEC-RK3328.arm-9.0-devel-20180606204626-0267cea-rock64 ?

    I could not find TVHeadend client there..

    That's a development and can't link to the LibreELEC repository. You need to update or flash the build download from here. However I found playback problem with the 06/08 build for ROCK64, suggest download and update to 06/07 build.

    Where do you get your CoreElec nightly builds ?

    There's no CoreELEC nightly builds, Legitwarrior referred to LibreELEC nightly builds available here.


    When this thread started, adamg's build was still named LibreELEC but now changed to CoreELEC, while LibreELEC started posting test builds for various devices. I also tested certain of them, remote control doesn't work. As told by adamg, this was due to Kodi, not LibreELEC or CoreELEC. In fact, adamg did a lot of work to make it works.

    I didn't own Harmony One remote and not sure which LE 8.2 build you're using. However, I have been using Raybuntu's LE Krypton and Leia builds (now discontinued) on my Odroid-C2 with MCE remote (bought so many years ago). All media control keys are working with LIRC turned on. Perhaps you can try to program your Harmony One as a MCE remote and turn on the LIRC in the LE setting.

    Couldn't download any image from link provided and don't know or have the tools to build the image. I believe all builds are consolidated here.. Going to test ROCK64 builds downloaded from there (need a few extra microSD cards).

    Then why on the page [HOWTO + FAQ] Install community builds on S905/S905D/S905W/S905X/S912 device

    there is information: "Odroid-C2 and LePotato: you do not have to chose a device tree as it is embedded in kernel.img." ? It obviously misguiding Odroid-C2 users that adamg's build can also be used on this device.

    I have prepared SD card with LibreELEC-S905.arm-8.90.6.img.gz without copying dtb file from \device_trees to \root as it is explained that this doesn't need to be done by Odroid-C2 and LePotato users and started my C2. Result is: not booting.

    As far as I knew, Odroid-C2 as well as LePotato employ separate builds due to uboot.ini of those devices. Device trees are not applicable to them. They just share the same code base. You can see separate build by adamg for LePotato here. As for Odroid-C2, you will have to wait for the official build as Raybuntu already discontinued his build and you couldn't download from here.

    I believe both should work but I don't own either of them. I also think you could find corresponding dtb for those boxes for adamg's Leia build. I haven't check their specifications so I couldn't answer which one is better than the others.


    I don't think either one of them comes with built-in DVB tuner. I believe only the MeCOOL KI or KII Pro got DVB tuner built-in.


    Not sure which Xbox HD DVB adapter you have but they did mentioned in External USB DVB-T2 for LE that Xbox DVB-T stick is supported (by CvH at the very bottom post).

    I have the MeCOOL BB2 Pro but rarely used it due to Linux framebuffer support of S912 processor. Look for kszaq's thread for better explanation. All my S905/S905X boxes were bought more than a year ago (for example I only got Mini M8S II and not M8S III), not sure dtb for LibreELEC is available.


    Netflix on MeCOOL BB2 Pro as well as other S905/S905X works but I don't watch Netflix with those boxes all the time. Mrs prefers the Roku stick for Netflix.


    You did mention XBox DVB adapter (I presumed USB stick) which is not applicable in my area, However, I use S905/S905X devices with ATSC TV stick (Hauppauge and KWorld) for TVHeadEnd server/PVR as well as client which run without any problem. You might be able to replace your old PC with another S905 box as well, this is what I did. I read somewhere on this Forum, the XBox DVB adapter is supported by LibreELEC.

    My Rock64 came with a Heat Sink for PINE A64 Using 3M 8810 Thermal Conductive Advise tape for effective heat transfer
    I've seen the Temp at 75c at one point which is something I'm not used to seeing in my TX7.

    I did get a freeze just before checking on reboot.

    I haven't installed the heat sink yet but ask if anyone has used a heat sink with 3M tape before.?

    I have the ROCK64 board for over a month. I installed the heat sink (with conductive tape) that came with the board. Even with the tiny heat sink installed, the temperature is still very high (up to or exceed 70c), which is unusual when compare with other S905x TV box. I cut a square hole on the chassis (it fits perfectly with Raspberry Pi), hope to help lowering the temperature. Right now, it is used as TVH server and so far so good (no hang, no freeze). Guess temperature would go much higher if playback mainly uses software decoding. I planned to change to a bigger heat sink and employ thermal conductive paste but have not set a time yet.