Posts by Kwiboo

Thanks all for testing the devel build and reporting mostly good results, it may take some time for current work-in-progress to fall into the regular LE nightly builds (sending pull requests to Kodi and wait for the bimonthly Kodi package update in LE).

I will continue to upload new builds to Index of /test/ once there is something significant that has changed or improved.

Quote from mo123

Do you know an easy way to get the SHA hash values of a specific commit of a package?

Easiest is to set PKG_SHA256="" and then run scripts/get rkmpp and it will show the sha256, no need to set PKG_SHA256 unless you want to commit and push code. I use projects/Rockchip/tools/update-package-version.sh to update packages but seem to have missed the tools folder in latest part6 push, will include next update.

Also regarding the absolute latest mpp that enables post-process support seem to have a 100% cpu when opening a video and hevc not working issue, I went with the commit before post-process was enabled, [h264d]: remove build warnning · rockchip-linux/mpp@3f57e7b · GitHub for devel image.

Quote from kostaman

I've noticed Live TV Mpeg2 SD channels are now Hardware Decoding.

Noticed after playing Mpeg2 for a while the picture freezes and a repetitive sound continues with both red and white lights gone out.

Hardware mpeg2 decoding is using my experimental ffmpeg rkvpu hwaccel that does not check on errors from VPU, I will activate mpeg2/4 hw decoding from rkmpp decoder once deinterlace support is working properly. Should hopefully fix these kind of issues.

VC-1 is supported by hw but not by mpp library, unclear if it will be added as it is a proprietary video format from Microsoft.

Quote from zarusz

Are all the changes/fixes mentioned above and done by Kwiboo part of today's nightly build?

LibreELEC-RK3328.arm-9.0-nightly-20180606-598f67c-rock64.img.gz

Yes, all fixes mentioned in this thread should be included in that build, it has been pretty stable on my main testing device (Rock64 / Transformer).

EDIT: Sorry, I misread, the nightly images do not contain any fixes yet, please test libreelec-rk3328.arm-9.0-devel-20180606204626-0267cea-rock64.img.gz, that image should include all fixes mentioned in this thread.

This test build have latest rockchip 4.4 kernel, latest rkmpp library, latest rkbin ddr/miniloader firmware, and my work-in-progress Kodi branch (including the same fix for black-after-stop that is included in Raybuntu's Rock64 images)

kostaman thanks for the log files, I will look into the emmc issue in a few days/next week

I have uploaded test .http://img.gz/.tar files for rock64 and box-trn9 at Index of /test/ built from my latest rockchip-part6 branch.

It includes RendererDRMPRIME: release video buffers after flush by Kwiboo · Pull Request #13978 · xbmc/xbmc · GitHub that should make playback a little bit more reliable.

Please report new issues seen on these images compared to latest nightly.

Quote from Kernle32DLL

I also tried to compile the "part-6" branch, but that failed to compile (something about missing GDM - I presume it has something to do with this).

You are correct, there was a missing depend from kodi to gbm-rockchip, please try the latest from rockchip-part6 again, it should have the correct depends now. Part6 now also contains work-in-progress kodi patches that will limit and scale gui to 1080p/720p when playing 4k video and unlocks 4k@50/60hz resolutions.

The part7 branch is a bit outdated and is mainly a stash with mainline kernel code, I will pick up once part6 is merged.

The VPU in RK3328 do not seem to handle bbb h264 2160p 60fps but should handle the h264 2160p 30fps version, guess it is a hw limit (I have not tested any other 4k h264 60fps video).

Quote from muya

the audio dropouts are every 5 minutes and only for 23,976fps (AC3 and DTS).

would be interesting if you could reproduce it

you can test with my sample i created, if needed

I have finally done some tests of your sample on my Rock64 + LG OLED55B7V + Sony HT-Z9F using a combo of LPCM, AC3 PT, 23.976hz and 60hz. I could not notice any dropouts or sync issues using the latest 4.4 kernel (contains fixes for fractal clocks).

I will try to get the kernel update pull request merged in next few days after I have completed testing on Tinker Board S and RockPro64.

What distribution + version are you using to build? I do my building inside a ubuntu bionic docker container (a xenial container before that) and have no issues building u-boot for TinkerBoard.

Quote from Marciano

is there any news on deinterlacing on rock64?

The latest mpp updates from Rockchip seems to have post processing support, unclear to me at this point what needs to be updated in ffmpeg to support/activate deinterlacing.

NL-PCM (AC3/DTS) and HBR (HD-audio) support is next on my list after current 10-bit color and HDR work.

NL-PCM audio works unintentionally today and will most likely result in some pops or white noise in some cases.

I suggest you use regular L-PCM audio until NL-PCM/HBR audio is fully supported.

The plan is to create an alsa plugin that will modify the 16-bit sample bitstream into the 21-bit format the HDMI TX IP expects, if all goes well this plugin should also help enable NL-PCM/HBR audio on mainline Amlogic/Rockchip/Allwinner.

Quote from muya

i see you are doing a lot commits, any ETA for a new build to test?

Yeah :), I am currently focusing on Kodi parts that should eventually lead to 10-bit color and HDR support, no real ETA but my aim is to have it finished in a week or two.

RK3328 have a dedicated hdmi phy clock and should have very good sync, even at 23,976fps and other fractal refresh rates.

Interesting regarding audio dropouts, I mainly test shorter sample videos, will test proper 23,976fps content and see if I can reproduce and fix the issue.

Quote from kostaman

The one issue which persists in all versions is with TVHeadend Client.

My GUI is set to 1080p 50hz for AU Live TV.

Live TV Opens but when i stop the stream there appears to be an Adjust refresh rate attempt followed by Black screen and no response using remote.

If i change GUI to 1080p 60hz stream opens and when i stop there is a refresh rate change back to 50hz no issue.

Thanks for reporting, this issue should only happen when video fps and gui refresh rate is the same and just like you have discovered using a different refresh rate for gui and your video content is the best workaround until a proper fix has been submitted to Kodi.

I have an old work-in-progress patch that should fix this issue at kodi-wip.patch but it needs to be reworked before it can be sent to Kodi.

Device testing has not yet completed as the Rockchip 4.4 kernel has been update several times in past week or two, I am in no hurry so might take a week or two before the rockchip kernel and package update PR gets merged.

I do not believe there has been any major Rockchip specific changes between those builds it should mainly be Kodi that has changed.

For audio I recommend that you only use L-PCM and completely disable passthrough (AC3/DTS), passthrough only works by coincident, I will run longer 23,976 fps video tests and keep an look out for audio issues during my next testing session.

Resume and chapter issues (if the issues are new in latest build) is most likely due to changes in Kodi and might have already been fixed in upstream Kodi.

When it comes to power on, this is not very hight prio for me personally as I have my devices powered on most of the time, I would recommend not turning of the box for the time being

I do want to look into some addon/service/system that can reduce cpu/gpu speed and power consumption when Kodi is idle/screensaver active, but unclear when this will happen.

I think I had a similar issue after I pulled latest LibreELEC master branch, try with a clean build and see if that solved the issue.

What distribution+version are you running on your build host? I do all my building inside the tools/docker container (ubuntu xenial).

Quote from muya

whats about "power on box after shutting down LE works only with re connecting the power again to the box"

any idea/ solution?

No solution for current builds, I will test latest kernel from Rockchip on different devices this weekend, lets hope it fixes crash on restart issues observed on some of the devices.

Since box-trn9 is for an Android box and not a Single-Board Computer it will not get same attention or testing time as Rock64 and ROC-RK3328-CC gets.

Quote from muya

fix needed:

blinking LED

To change the blinking LED behavior you can use a Autostart.sh [LibreELEC.wiki] script to change led triggers using something like

echo default-on > /sys/class/leds/led1/trigger

The default is set to hearbeat in order to quickly be able to tell if the kernel have crashed or not.

There has been some issues with restarts in the current kernel version used on Rockchip, hopefully a kernel/u-boot bump will fix such issues.

Building RasPlex on Arch has never been tested, suggest you build on ubuntu or inside a docker container, see thread-4786-post-33377.html#pid33377

Hello dummys,

Building RasPlex has only ever been tested on ubuntu 14.04/16.04, if you want to build on Arch I suggest you build RasPlex inside a ubuntu xenial based docker container (OpenPHT-Embedded/Dockerfile at openpht-1.7 · RasPlex/OpenPHT-Embedded · GitHub).
The release builds of RasPlex is built inside that docker container on our Jenkins server and should work without issues.

Alpha 010 should fix the screensaver standby issue for most bluetooth devices, it fixes the main issue that activated the busy dialog when a bluetooth device was disconnected.

I will look for my old DualShock 3 and run some tests