Posts by mo123

Quote from Trillian59

Hi Folks!

I just bought me some Rock Pi 4s to replace the old Raspberries here running Librelec.

So far, it looks good, even 4k films can be played (sometimes )

But I have noticed that Audio Passthrough to an external Amp really does not work with the Rock

Only static noise comes out of the Speakers (I've learned it the hard way last night, very late already.... bad karma...)

The Amp does not recognise any Dolby Digital or DTS Frames, instead it keeps on playing PCM, which explains the evil noise fairly well.

I found this thread, read it and hoped, there will be a solution, at least somebody is working on it right now.

But, I cannot make head or tails out of it, one says "yes", others say "no", one points to the "nightly" or "development" image (I've tried it right now, still no go )

So, at the end I feel quite lost.

a) is this problem known ?

b) does somebody work on it already?

c) if the answers are "no" what is the best place to report it???

Display More

You have to wait until mainline Linux support is added for Rockchip devices.

4.4 kernel images don't support audio passthrough.

Rockchip: add mainline linux support by Kwiboo · Pull Request #3560 · LibreELEC/LibreELEC.tv · GitHub

Kwiboo

Please check gigabit lan support on RK3328 mainline.

It is missing some code in the dts files that was present in the 4.4 kernel dts files.

Trn9 board uses gigabit lan and maybe some others too like ROC CC.

Thanks

Quote from npcomplete

Kwiboo I have a RK3399 box (X99) for which I had a working 4.4 dts. I tried booting the rockpro64 img, but it gave an error wrt i2c on the serial console.

I ended up modifying the original 4.4 dts which got rid of the i2c error bringing it closer to rockpro64, but the screen is blank. There is an error regarding EDID is blank.

Let me know so I can provide any debug logs or dump of any parameters from serial console.

Code

1. # cat /sys/kernel/debug/dri/0/state
2. plane[31]: plane-0
3. crtc=(null)
4. fb=0
5. crtc-pos=1024x768+0+0
6. src-pos=1024.000000x768.000000+0.000000+0.000000
7. rotation=1
8. normalized-zpos=0
9. color-encoding=ITU-R BT.601 YCbCr
10. color-range=YCbCr limited range
11. plane[33]: plane-1
12. crtc=(null)
13. fb=0
14. crtc-pos=0x0+0+0
15. src-pos=0.000000x0.000000+0.000000+0.000000
16. rotation=1
17. normalized-zpos=0
18. color-encoding=ITU-R BT.601 YCbCr
19. color-range=YCbCr limited range
20. plane[36]: plane-2
21. crtc=crtc-0
22. fb=44
23. allocated by = kodi.bin
24. refcount=2
25. format=XR24 little-endian (0x34325258)
26. modifier=0x0
27. size=1024x768
28. layers:
29. size[0]=1024x768
30. pitch[0]=4096
31. offset[0]=0
32. obj[0]:
33. name=0
34. refcount=3
35. start=00000000
36. size=3145728
37. imported=no
38. crtc-pos=1024x768+0+0
39. src-pos=1024.000000x768.000000+0.000000+0.000000
40. rotation=1
41. normalized-zpos=0
42. color-encoding=ITU-R BT.601 YCbCr
43. color-range=YCbCr limited range
44. plane[38]: plane-3
45. crtc=(null)
46. fb=0
47. crtc-pos=0x0+0+0
48. src-pos=0.000000x0.000000+0.000000+0.000000
49. rotation=1
50. normalized-zpos=0
51. color-encoding=ITU-R BT.601 YCbCr
52. color-range=YCbCr limited range
53. crtc[35]: crtc-0
54. enable=1
55. active=1
56. planes_changed=1
57. mode_changed=0
58. active_changed=0
59. connectors_changed=0
60. color_mgmt_changed=0
61. plane_mask=4
62. connector_mask=1
63. encoder_mask=1
64. mode: "1024x768": 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa
65. connector[41]: HDMI-A-1
66. crtc=crtc-0
67. hdr_metadata_changed=0

Display More

Code

1. [ 8.659739] rockchip-drm display-subsystem: HDMI-A-1: EDID is invalid:
2. [ 8.659794] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
3. [ 8.659801] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
4. [ 8.659805] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
5. [ 8.659810] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
6. [ 8.659814] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
7. [ 8.659818] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
8. [ 8.659822] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
9. [ 8.659826] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
10. [ 8.677009] SWITCH_REG1: supplied by vcc3v3_sys
11. [ 8.689483] SWITCH_REG2: supplied by vcc3v3_sys
12. [ 8.738088] Console: switching to colour frame buffer device 128x48
13. [ 8.743182] rk808-rtc rk808-rtc: registered as rtc0
14. [ 8.775272] rockchip-drm display-subsystem: fb0: frame buffer device

Display More

Display More

You will need a 5.1 not 4.4 dts kernel file to test with mainline images used here.

But I can't help further.

Quote from muveedkhan

from where I can download the 5.x kernel image (package) so that we also can test and give you the feedback. Thank you

Here are the test images with mainline Linux 5.1 kernels.

Index of /test/

Mpeg2 should work.

It seems there is progress being made with H264 and hopefully that should work too early next month.

Then H265 and VP9 video playback code still has to be created and tested with mainline Linux.

I can't wait until everything works fully with mainline Linux.

Quote from Patkino

May I ask you to point me the correct build and/or dtb file for RK3399 H96 Max 2g RAM version?

There is no support for that device.

Please ask the manufacturer to send sample devices to the LibreELEC developers plus the kernel source code.

Try all the other RK3399 dts files and check which one works the best then the things not working can perhaps be fixed.

Carey It must be because you have a different revised board.

Most Rock64 users have the non revised or rev1 boards that they bought one or two years ago.

The kernel dts file might not contain the correct settings for the latest rev2 or 3 boards I think.

It can hopefully be fixed with the correct kernel changes later on.

Pine64 should have made one board with everything improved from user feedback before the device was released since all these revised boards become a nightmare later on to all support correctly.

Maybe something also causing problems with rev3 boards and micro-sd cards.

Wonder how it passed quality control?

Rock64 v3 and SD-Cards

Quote from default_user8

I'm on the latest alpha build of libreelec, and have an issue with the video on my rock64 1GB board. I've just now started using this board, and I have found 2 issues. One is that when i start a video I lose hdmi output, the other is when i do have hdmi output the color is not correct. The interface works correctly, this only happens when i start a video. Has anyone else had this same issue and have you been able to get it corrected or should i go back to using my raspberry pi and find another use for the rock64.

Did you try the latest nightly?

libreelec-rk3328.arm-9.1-nightly-20190501-6f2af43-rock64.img.gz

Quote from antaril

Hi,

i use my Rockpi4 dayli with live tv and netflix. I have also a tvheadend server with german sky Card. Everything works well, but sometimes the video has to reload and at this point i have to stop the program and start it again, because the video is showing slideshow. If i turn of the Hardware decoder and use SW everything works fine!! It would be nice if someone can test this issue!

Sorry for my english...

The nightly images are missing the software decode patches from Kwiboo for Inputstream Netflix decoding.

Otherwise everything could be hardware decoded and Netflix software decoded automatically with much better performance.

Things will improve even more with the switchover to the Linux 5 kernel.

Quote from spaceship9876

I was referring to the RK3530, the RK3588 will definitely be open sourced as it is designed for chromebooks.

Since it's more powerful than the RK3328, it will also have Linux support.

Of course it will be open-source.

The main use of RK3588 is Linux support.

It just depends which companies will release development boards based on it and send sample devices to developers.

Don't expect cheap no name brands that only ship with Android to have any LE support.

But it's still almost a year away.

The S905X3 is a low cost device, RK3588 won't compete against it, rather against the S922 but the RK3399 performance is already a bit faster than the S922. I would rather say the RK3530 will compete against S905X2 & S905X3.

Quote from flyingernst

Hello,

sorry, I have to open a new topic, since noone gives answers...is there a offical (alive) develoment topic for the rock64 with changelogs?! I cant do testing when I dont know what to look for...I do all the updates usually.

Thanks,

regards

Display More

Compare the commit number in your image to the one in the Github page to see commits newer than it or the ones included in the image. Eg. b090091bb921 That is your change-log.

Commits · LibreELEC/LibreELEC.tv · GitHub

The daily images are all still using the old 4.4 kernel that is now discontinued since mainline v5.x kernel support is being worked on.

Just some of the hundreds of mainline patches that will be tested and merged soon.

WIP: Rockchip: add initial mainline support · Kwiboo/[email protected] · GitHub

The kernel update from 4.4 to 5.0.7 alone already contains a few thousand changes.

Some mainline kernel work being done on a daily basis.

Rockchip SoC list - Patchwork

With mainline support lots of things like 10-bit, HDR, interlaced playback, HD Audio have to be redone and for HDR, follow standards set by Intel code that have to be tested and still merged into mainline kernel. But if finished, everything will run a lot more stable and be better supported. All of this takes tremendous time and effect from several different developers.

Several Rockchip devices are tested not just Rock64, there is no special support for one device.

Quote from muveedkhan

please can you let us know any timeline when the new version will getting release. (any tentative update)

New preliminary mainline 5.x kernel images should be available next week or before the end of April for RK3328/RK3399 for testing.

You have to remember that HDR(awaiting Intel patches) and 10-bit support is now wip and won't work as on 4.4.x kernel images.

HD Audio is also wip but will be developed further for mainline kernel.

H264, H265, interlaced support is also being redesigned so there will be new issues and improvements.

So 4.4.x kernel images are the most stable until support for all the components get merged into mainline kernel.

I'm thinking more the Rock64 issues are hardware related since the stuttering can't be reproduced on other devices.

Beelink RK3288 devices also had stuttering that couldn't be reproduced on other RK3288 devices and it turned out it was because of low quality RAM chips that were used.

Also Pine seems to have abandoned the device and making empty promises to users.

But I hope I'm wrong and with the Linux v5 kernel that LibreELEC developers are working on, it would improve things.

Quote from 0per8or

Hi,

I am new to this forum and I just bought a Rock64. I am experiencing CEC issues with my Philips TV. The CEC device gets registered on startup but it does not work. I installed the Rock64 image version 8.90.014.

Code

1. 2019-04-07 08:42:37.963 T:3960447856 NOTICE: Register - new cec device registered on cec->Linux: CEC Adapter (0000:0000)
2. 2019-04-07 08:44:10.010 T:3866129264 DEBUG: CecLogMessage - << requesting vendor ID of 'TV' (0)
3. 2019-04-07 08:44:10.010 T:3866129264 DEBUG: CecLogMessage - << 10:8c
4. 2019-04-07 08:44:10.010 T:3866129264 ERROR: CecLogMessage - CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=64
5. 2019-04-07 08:44:10.010 T:3866129264 DEBUG: CecLogMessage - << 10:8c
6. 2019-04-07 08:44:10.010 T:3866129264 ERROR: CecLogMessage - CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=64
7. 2019-04-07 08:44:10.010 T:3866129264 DEBUG: CecLogMessage - << powering on 'TV' (0)
8. 2019-04-07 08:44:10.010 T:3866129264 DEBUG: CecLogMessage - << 10:04
9. 2019-04-07 08:44:10.010 T:3866129264 ERROR: CecLogMessage - CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=64
10. 2019-04-07 08:44:10.010 T:3866129264 DEBUG: CecLogMessage - << 10:04
11. 2019-04-07 08:44:10.010 T:3866129264 ERROR: CecLogMessage - CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=64
12. 2019-04-07 08:44:10.010 T:3866129264 DEBUG: CecLogMessage - << Recorder 1 (1) -> broadcast (F): active source (1000)
13. 2019-04-07 08:44:10.010 T:3866129264 DEBUG: CecLogMessage - << 1f:82:10:00
14. 2019-04-07 08:44:10.010 T:3866129264 ERROR: CecLogMessage - CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=64
15. 2019-04-07 08:44:10.010 T:3866129264 DEBUG: CecLogMessage - << 1f:82:10:00
16. 2019-04-07 08:44:10.010 T:3866129264 ERROR: CecLogMessage - CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=64
17. 2019-04-07 08:44:10.010 T:3866129264 DEBUG: CecLogMessage - failed to make 'Recorder 1' the active source. will retry later
18. 2019-04-07 08:44:10.136 T:3866129264 DEBUG: CecLogMessage - << requesting power status of 'TV' (0)
19. 2019-04-07 08:44:10.136 T:3866129264 DEBUG: CecLogMessage - << 10:8f
20. 2019-04-07 08:44:10.136 T:3866129264 ERROR: CecLogMessage - CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=64
21. 2019-04-07 08:44:10.136 T:3866129264 DEBUG: CecLogMessage - << 10:8f
22. 2019-04-07 08:44:10.136 T:3866129264 ERROR: CecLogMessage - CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=64

Display More

Any ideas how to fix this issue?

Use a newer image.

Index of /

The one you're using is ancient.

Quote from buximze

edit: the cpu governor is set to performance by default.

new nightly release today installed on my rock64 and the problem persists.

Did you try a faster micro-sd card?

You can manually turn it to OnDemand or Interactive(which is even better), it really helps with stability to decrease temperature and heat compared to Performance that always runs at the highest CPU speed.

feedback for test build LibreELEC-RK3328

MVR9 RK3328 users run their devices for hours without any freezes or crashes, but maybe it is because of a better heatsink and higher quality DDR4 RAM used. You can also use a USB cooling fan to make sure the device runs stable and doesn't downclock because of high temperatures.

Quote from buximze

edid: this happened on all the nightly builds.

Disable all passthrough options as it will only be supported in the next LibreELEC version.

Read the forums and also change to an OnDemand CPU governor.

Make sure you are using a nightly build as they work better.

Index of /

Quote from bmentink

Thanks for your help anyway ... Can you supply the Netfix plugin link that you used just in case my one was incorrect?

I used:

Yes, same one works.

The new 0.14 one doesn't work for me.

Quote from bmentink

mo123

I tried your image with the official .dtb file and it booted up fine, I installed the Netfix plugin nad had similar issues to the official build, just worse.

When it tries to download the Chromium image to extract libwidevine it starts, get's a little way, then crashes ... I tried about 10 times, just won't complete ..

I am about to give up, just takes too long to sort out .. maybe I will wait until Rock64 image is more stable ..

Display More

The Chrome image downloads fine for me but takes a while.

Someone must really make a small addon that just downloads the Widevine DRM files and not a whole Chrome image.