[8.0.2e] LibreELEC 8.0 for S905/S905X

  • have a few issues with version 7 and 8. with kszaq builds for T95X 2x8gb box

    #1. When clicking on a stream or local file, the display will flutter from blue screen to "snowy" back to blue and then the actual stream/file will play. Very noticeable when switching to something SD more than something that is HD 720p
    video is currently set to ,1920x1080 60hz in system
    is this normal behavior for this version / on this box ?

    #2. When file or stream first starts, then menu bar at bottom (showing play/pause etc..) gets stuck for 10 to 30 seconds and remote does not respond (also, Working scroll may also appear and freeze for that time ) in the bottom right corner.
    is this normal ?

    #3. Back Button on remote stops functioning if i disable remote and touch screen option in Kodi
    leave it enabled and it works....

    anyone else have same issues and have it fixed and how ?


    thanks

  • I would say that i tested s905 (beelink mx64) and s905x (kekilo tx5 pro) and both of them play any video well. There is only one exception - h264 10bit (Hi10P). Hi10P played without hardware acceleration so 300-400% cpu load and frame drops. h265 10bit (HEVC) plays well too.

    There is huge problem with audio/video sync when audio is external file, but it is not related to kzsaq build - general krypton issue i think.


  • Hello,

    # cd .update/
    # wget lastversion.img.tgz
    # reboot

    Regards.

    Thanks zorrua,

    I'm running beta3 and I know there is no update for now.
    but anyway, I get this error message:

    wget: bad address 'lastversion.img.tgz'

    you need to put tgz file on update folder or its should download automatically from the server?


  • There is only one exception - h264 10bit (Hi10P). Hi10P played without hardware acceleration so 300-400% cpu load and frame drops. h265 10bit (HEVC) plays well too.

    This is expected behaviour, as there is no hardware acceleration for h264 hi10p files. In my experience, 720p files work quite well; but complex ASS subtitles can sometimes crash kodi Krypton.

  • Thanks Kszaq for the great effort you have done on that.

    i have Nexbox A95X - S905X 2G RAM /16G

    * for the good luck it seams that i have "Original" device , i have found the boot button in AV slot and the device booted from SD card from the first time.
    * My remote work without any remote adjustment or configuration.
    * My Bluetooth is working , Wifi
    * remote switch the device On/Off with no problem.
    * i Didn't have any boot issue.

    - didn't test the Ethernet but showing in the settings
    - Didn't test CEC as my TV didn't support it.
    - All my videos working , didn't test 4K

    only two times the device reset " crashed" and rebooted automatically i don't know the reason and two times is not an issue.

  • I will add a review for the same box (Nexbox A95X - S905X 2G RAM /16G):
    - CEC works flawlessly with the AV receiver Onkyo TX-NR727 (code: 32910)
    - 4K videos that I've played, including 10 bits - no problem.

    Edited once, last by Zatserkovnyy (January 25, 2017 at 1:21 PM).

  • I have one question, i install the last version on my mini8S, and for the moment it's work with the original remote.
    I would like to use my harmony, but i think that i have to change something at remote.conf level ?

    I try to test with USB IR module and it's work with my configuration of my HTPC, but not with the IR module integrated.
    Do you have some idea ?


  • Negative (high priority):
    - My biggest concern right now: I have regular frame skips. These occur in various (all?) normal h264 and x264 encodes I tested, both 720p and 1080p. All are clean encodes which work flawlessly on the Pi. I think all were 23.976Hz. Frame rate switching is active and does seem to work. Am I doing something wrong? I did not touch the defaults for hardware acceleration. Resolution is on 1080p/50Hz in the menus. Since the old AVR is now between the box and TV, there is no 4K support anymore.
    - Upscaling quality of SD videos looks awful. Very blocky and annoying. I disabled hardware acceleration and tried software decoding and even Bilinear upscaling looks better than the hardware accelerated upscaler. Is there a way to change that? 720p does not look good either and is much cleaner on the Pi.

    Quote


    I just put the 7.0.3.012c on an SD to see if my issues may be Krypton-specific.

    - I did not see any immediate frame skips (nor were any in CodecInfo), but I need a bit more time for testing to confirm.
    - Upscaling of SD and 720p looks much better in Jarvis. No concerns here.

    Hi kszaq,

    can you comment this?
    Are you aware of these issues and will they be fixed in a future release?


  • Hi kszaq,

    can you comment this?
    Are you aware of these issues and will they be fixed in a future release?

    Unfortunately I don't know much about the decoder, I can't promise they will be fixed. At the same time I don't see any frame skips except when browsing GUI during playback.

    Edited once, last by kszaq (January 25, 2017 at 8:23 PM).

  • Some questions about compiling from source. What confuses me (among others) is the 32bit userspace vs 64bit cpu.

    Would this be ok to compile with 32bit userspace? "PROJECT=S905 ARCH=arm make amlpkg" (and again with ARCH=aarch64 for 64bit userspace?)

    Would changing "CONFIG_AML_TEMP_SENSOR" in linux.arm.conf be enough to compile with temp-sensor enabled vs disabled?

    Are there any changes necessary to prepare for dual boot support or is the source code ready for SD boot as well as internal nand install?

    Just want to familiarize my self with this.
    Thanks...

    Edited once, last by Asxetos (January 25, 2017 at 8:35 PM).


  • Would this be ok to compile with 32bit userspace? "PROJECT=S905 ARCH=arm make amlpkg" (and again with ARCH=aarch64 for 64bit userspace?)

    Source code is ready to compile 32-bit userspace only. To compile for aarch64 you need to delete this patch: Python-32bit-usespace-workaround.patch and rename (or copy) linux.arm.conf to linux.aarch64.conf. Remember that the main reason for 32-bit userspace is memory leak that has not been fixed.


    Would changing "CONFIG_AML_TEMP_SENSOR" in linux.arm.conf be enough to compile with temp-sensor enabled vs disabled?

    You also need to disable SARADC.


    Are there any changes necessary to prepare for dual boot support or is the source code ready for SD boot as well as internal nand install?

    It's ready.

  • Source code is ready to compile 32-bit userspace only. To compile for aarch64 you need to delete this patch: Python-32bit-usespace-workaround.patch and rename (or copy) linux.arm.conf to linux.aarch64.conf. Remember that the main reason for 32-bit userspace is memory leak that has not been fixed.

    You also need to disable SARADC.

    It's ready.

    Thanks for the help kszaq,
    So this is OK? "PROJECT=S905 ARCH=arm make amlpkg"
    And do you mean disable this "CONFIG_AM_SARADC" ?

    Edited once, last by Asxetos (January 25, 2017 at 9:28 PM).


  • There is only one exception - h264 10bit (Hi10P). Hi10P played without hardware acceleration so 300-400% cpu load and frame drops. h265 10bit (HEVC) plays well too.

    Luckily H.264 10bit is rare. It's also clear that this is a hardware limitation.

  • The problem is, although Hi10p has always been in the H264 specs, since no one uses it in the commercial space, hardware manufacturers never implemented it.
    Why would they build hardware specs no one uses?

    H264 Hi10p is to my understanding mostly used for anime. Or at least some subbing groupe used it.
    Why? because it reduces encoding banding , and anime encoding is very prone to banding.

    But since these applications are not commercial ones or are even labeled as illegal ones, why would they now create hardware decoding for that purpose?