Posts by ilmich

    if you build legacy images with the legacy kernel (4.4) the driver for SSV6051 is built by default for the supported box mentioned in the first post (including a8).

    Assuming you have already checked the kernel logs, try to decompile the device tree blob of your image.

    The one for a8 has this

             wireless-wlan {
                    compatible = "wlan-platdata";
                    rockchip,grf = <0x36>;
                    wifi_chip_type = "ssv6051";
                    sdio_vref = <0xce4>;
                    WIFI,host_wake_irq = <0x75 0x1c 0x00>;
                    status = "okay";

    which enables the wifi chip.

    Hi admtpu

    I tried the files, only the mxq4k and A8 files work, but no wifi?

    it's strange because I have a box with the same wifi chip and the image for the a8 works without problems.

    However, I advise you to use an external wifi card.

    In my case the integrated wifi works badly, because the box heats up a lot and the internal components after a while lower the performance.

    I'm new to libreelec, but I'm pretty versed in linux, can you guide me how to make it?

    make sure your system is ready for build and then launch this command (for example)

    `PROJECT=Rockchip DEVICE=RK322x ARCH=arm UBOOT_SYSTEM=rk3228b-a8 make image

    and if the build is ok, under /target you will find the image produced.


    looking into the log I've founded

    Error Contents: 400 Client Error: Bad Request for url:

    that is an http client error indicating that the addon maybe use an old api (maybe fixed with this Fix authentication due to cookie changes by michaelarnauts · Pull Request #212 · add-ons/ · GitHub )

    Sorry, but I can't help you because is not a libreelec issue :(

    I'm using netflix / amazon prime / dazn without any issue

    Have you tried images for rk3228 instead of rk3229!?!? Keep in mind that often rk3228 boxes are sold as rk3229.

    Try to flash an image for rk3228 (for example the alfawise a8).

    Unfortunately with these boxes, you have to try until you find the right image

    the source code of the stable branch (libreelec 9.2)

    GitHub - knaerzche/ at libreelec-9.2

    is updated, but @knaerzche's images not yet.
    So I've cloned his repo and build the image for my box by myself.

    Am I the only one having trouble with the libreelec repo?

    I noticed that some packages have urls which are wrong or out of date

    For example rockchip has removed the source code of the mpp package. But on github I found a fork

    GitHub - HermanChen/mpp: Rockchip MPP(Media Process Platfrom)

    that still works.

    Glad to know it was useful :D.

    However I'll forgot to mention that I've only builted(and shared) knaerzche repo with latest commits. Nothing more, nothing less :)

    Thank you. I followed these steps and everything looked to be ok, but when I tried to start the system I got an error message "failed to start login service". The system starts but a lot of services are no running (ssh, etc). I think I will have to back to the original image.

    It's strange because

    - I'm using an image with this patch

    - the two files are used only with software decoded streams(during my experiments, eventually broken shaders cause only black screen during playback)

    I forgot to say that the whole procedure must be performed as super user, because otherwise there is the risk that the resulting filesystem may have wrong permissions.
    In any case, the correct procedure would be to recompile the image with the patch. I'll try to send it to the project maintainer.

    Can you please elaborate how to apply this patch? I would like to be able to play hevc files without system reboot,

    Thank you:)

    Assuming that you have a linux distribution:

    - flash image as usual on a SD card

    - mount first partition of sd card on your linux machine

    # mount /dev/mmcblk0p1 /some_mountpoints

    - explode libreelec filesystem with squashfs tools

    # mkdir tmp_dir 
    # cd tmp_dir
    # unsquashfs /some_mountpoints/SYSTEM 

    at this point under squashfs-root you can find the exploded filesystem of libreelec.

    - replace file squashfs-root/usr/share/kodi/system/shaders/GLES/2.0/gles_yuv2rgb_basic.frag

    - replace file squashfs-root/usr/share/kodi/system/shaders/GLES/2.0/gles_yuv2rgb_bob.frag

    - repackage squash filesystem, copy to sd card and umount

     # mksquashfs squashfs-root/ SYSTEM -comp gzip
     # cp SYSTEM /some_mountpoints/SYSTEM
     # umount /dev/mmcblk0p1

    that's all.

    NB: this patch disable BT.709 color conversion that is slow on my mali 400 because it's use the pow math function.

    Searching on kodi official github I've found

    - Kodi PR#15286 improved rendering performance: · wrxtasy/CoreELEC@8f98ed7 · GitHub CoreELEC patch that is basically what I've done with my box

    - [GLES] memcpy instead multi glTexSubImage2D for planes with pitch by peak3d · Pull Request #15286 · xbmc/xbmc · GitHub discussion of what is the problem

    - Kodi 18.0 stutters when playing DVD files (VIDEO_TS) on Fire TV · Issue #15405 · xbmc/xbmc · GitHub discussion (now closed) that let me thinking kodi devs will never accept this kind of patch (that is, obviusly, more like a workaround than a solution)

    At this point let me know knaerzche if you think reasonable to patch only this libreelec port.

    Just for share my experience:

    - I've switched back to stable (only because I don't need an external wifi usb adapter)

    - patched kodi (no overclock.. no governor... only shaders)

    and now, I'm able to play well also netflix/prime tv shows with the appropriate kodi addon (assuming sd quality that is the max available resolution with the DRM addon usable with libreelec).

    Overclocking does not worth it, the GPU and memory subsystems (2 core GPU + 64 bit memory bus) are simply not tough enough on the rk322x.

    You are right... this kind of box is not suitable for cpu/gpu intensive tasks, but, in my opinion, it's powerful enough for libreelec usage.

    Looking into kodi source I've discovered that for software decoded streams, gpu is used for upscaling and color conversions (opengles vertex/fragment shaders).

    With a mpeg4 stream (that in mainline libreelec is not hardware decoded) playing with scaler(nearest vs bilinear) and resolutions (fullhd vs hd), make video looks worse/better.

    So after some experiments with shaders I've finally found this trick.

    To reduce gpu load I've substantially reverted this commit (by removing sections into shaders)

    [GLES] VideoPlayer: rewrite yuv - rgb conversion · xbmc/xbmc@0aadf5d · GitHub

    that introduces other colorspace conversions.

    I know it's not a clean solution, considering I'm not a color space expert, but now the box is almost perfect :)