Could you also provide linux 5 test build for trn9 box?
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 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.
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.
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?
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.
Display MoreNo issues comparable with any of the above with my Rock64 .
I am using the Factory Power Supply.
LE Via SD Card. 4gb Ram.
Rock64 HDMI straight into TV.
One USB stick and one USB receiver for remote inserted.
See my Board. Just to compare.
![]()
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?
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.
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).
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?
I have a 4GB board.
I think the issue is with the different memory modules used, my Rock64 boards is from one of the batches when the board was rather new and when 1866mhz memory modules was used even if the board spec was 1600mhz.
The old images did not have dfi/dmc ddr devfreq enabled in device tree and possible explains why you have a more stable board with the old image and problems with newer images.
The linux v5.0 image I linked to possible had the 933mhz ddr init code and that would explain why it does not work on your board, I have uploaded a linux v5.1 image with the 786mhz ddr init code: libreelec-rk3328.arm-9.1-devel-20190512071134-2f3393e-rock64.img.gz
One of my Rock64 boards:
I tried this build. HDMI is black, same as the build "LibreELEC-RK3328.arm-9.1-devel-20190416231707-c1c92b1-rock64" that I tried. I tried using SD and eMMC. Same results.
Just to reiterate. The 20181002 build still works on my board consistently. So I don't see why it can be a bad board or power supply. I am testing with 2 different power supplies, same results every test I do. I would now assume there is something different in the manufacturing of my board, as far as model/revision of chips, memory timing, etc. All I can say with certainty is that I get expected playback consistently using build 20181002 on my board. And no other builds I've tried have worked. So there is something "right" in that build that works on the version of board I have.
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).
Tried latest build, trn9 box booted but I got neither ethernot nor wifi, pvr.hts, tvheadend and oscam didn't work also.
So I coudn't test anything and rolled back to latest kernel 4.4 nightly where I'm experiencing crashes all the time.
Very frustrating.
@kostman, may I ask the brand, size and speed of your microSD card?
I am using an old low spec Sandisk Ultra
It's been in the Rock64 since Raybuntu's test images and i haven't bothered upgrading it.
I just prepared a short sample video.
I just played your video sample.
No issues at all.
Carey I would immediately point Ameridroid to this forum on your issues. They're probably going to say it's a Power supply. I don't know. If it's possible to send it back for testing. Could be bad Memory / Flash . Damn electronics. Bad batch in their stock they should know about it. Sorry i can't help further. At least the board looks identical to mine. Except that one number.
hi mates, here the same case with LE but harder because I am not able to run on kodi leia gui more than 3 steps.. or any step... hard to start LE, lots of reboots about kernel panic, locked cpu2, for instance...
I flash and replace files from 2018.10.02 to the kwiboo build 2019.05.12.07 as Carey has done and I achieve to start kodi 18 beta gui, after a reboot with reset button, because first boot has failed...
I bought the rock64 4gb ram with the pine store power supply 3000mah, in november 2018, and it have never worked fine, neither minimal OS debian /ubuntu nor dietpi... I think I still could do a claim to pine64 store, dont it? We buy 2 rock64 on the same order, my rock64 is a disaster, and the other one it just works to give a domestic vpn connection.. but sometimes my friend has some hangs and automatical system reboot with ubuntu bionic.
I just wanted to know how to do a claim. I received an emmc 16gb module to make the last try the make my rock64 full working but no results..
I would like somebody to guide me if possible, to explain my claim to pine64 store. first order with the 2 rock64 and others, I paid by PayPal, the last emmc module with credit card. here a pic of my board,
thanks in advance.
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.
I had the same issue. I purchased a ROCK64 SBC last year and it's marked ROCK64_V2.0 2017-0713, same as yours. I did my setup around September 2018 by using a nightly build which unlikely I did not backup, actually I performed a backup through the LibreELEC UI to find out too late that it backed up the storage partition only. So everything was working fine until last Monday when I had the very bad idea to upgrade LibreELEC. Since then I started to experience the same issue as you: every 10 or 15 seconds, the video was freezing for a few seconds before re-syncing. The strange fact is that this behavior was taking place only after I stopped a video and restarted the playback; if I just let a video play after the boot without stopping it there would have been no issues. However, I tried to downgrade to the older official release which is
LibreELEC-RK3328.arm-8.90.006-rock64.img and I had the same issue. It runs kernel 4.4.154. Then I found your post and I tried the
LibreELEC-RK3328.arm-9.0-nightly-20181002-8b3e678-rock64.tar image you uploaded which solved the issue. Now the playback is smooth as before. As you pointed out it looks like that with the later kernel or DTB they broke support for the older versions of the board.
For completeness, attached the kernel log messages printed during a playback freeze event.
Thanks for having uploaded that build.
I have problem with playing video with resolution 960x540 qHD with hevc, playing only sound. Other videos no problem.
I have installed release LibreELEC-RK3328.arm-9.1.501-rock64.img.gz
What could I set?
I have problem with playing video with resolution 960x540 qHD with hevc, playing only sound. Other videos no problem.
I have installed release LibreELEC-RK3328.arm-9.1.501-rock64.img.gz
What could I set?
Can you post some sample videos?
It would be interesting to test it on different Rockchip devices.
Can you post some sample videos?
It would be interesting to test it on different Rockchip devices.
is it stream from dvb-t2. I'll make a recording.
Hi.
I posted last week about an odd problem with 3 of 10 of my Rock64 LibreElec/Kodi video players freezing up.
It was recommended that I post in this thread, too.
Bottom line: on 3 of 10 video players, I occasionally get a video freeze in a random location. The only error I could trap was:
ERROR: ffmpeg[E2E2C380]: [AVBSFContext] Channel mapping 2 is only specified for channel counts which can be written as (n + 1)^2 or (n + 1)^2 + 2 for nonnegative integer n
Rock64 4GB
LibreELEC/Kodi (LibreELEC 9.1.002), playing a simple addon to loop the video based on a timer.
Confluence skin, SAMBA turned off
4k video, playing on a 1080p monitor for debugging. The freeze happens both in 1080 and 4k.
The video is playing from SanDisk Ultra microSDHC UHS-1 16GB cards
The CPUs have heatsinks with cooling fans, and run at 43 deg C. CPU cores show <20% loading in general.
Memory use is ~0.4GB (10%)
I have 3 Amp power supplies from Pine64 and Ameridroid
I've purchased replacement Rock64s, but I would love any suggestions on something I can do to eliminate around the freezeing.
Should I set the CPU speed to a fixed speed?
Is there a build that might be more stable?
Thanks,
-Jeff
ERROR: ffmpeg[E2E2C380]: [AVBSFContext] Channel mapping 2 is only specified for channel counts which can be written as (n + 1)^2 or (n + 1)^2 + 2 for nonnegative integer n
Changing the amount of audio channels at the LE audio settings doesn't help?
