Posts by ky41083

    Dear all, i need your help. Since Kodi Krypton (8 version onwards) i cannot install to internal. I do the process and then my mini m8s ii goes into boot loop. Does anyone knows why this happening? any sollution maybe? is there a place i can find my original stock firmware?

    Install to internal twice in a row? Read OP....


    Sorry I thought it was 1 of your builds I was already using :-/ I installed it around a year ago the links are gone so development must have stopped. I still have the files somewhere which i used to flash the beelink. Not sure if there would be of use to make the remote work??


    Recommended: Go find a remote.conf specific to your box, with good feedback, download it, and place it in the root of the external flash device LibreELEC is installed on.


    Might work alternative: Find the remote.conf file the older unknown build you are using, is using, and place it in same location given above.

    8.0.1i is working the best for me right now, after daily driving with both 8.0.1i and 8.0.1j.


    On 8.0.1i:


    Chapter seeking / skipping backwards is near 95% reliable. Every once in a while it hangs with the "buffer circle 100" in the middle of the screen, but it's very rare and very random. It happens during playback of the exact same file(s) it has previously worked, without issues, many times before. To get the video to resume playback without stopping it, you need to skip forward to (or past) the point in the video you were at, when you first tried to skip backwards. To me this says playback isn't completely hung, and as such should be possible to fix and make reverse skipping 100%.


    There are zero audio sync issues on my box, even YouTube live streams have good audio sync. I do not do anything PVR addon related on this box, so I cannot speak on PVR streams.


    There are zero buffering issues with live streams, YouTube live for example.


    I do not ever put this box in standby mode, nor would I want to, so I did not / do not test this.


    On 8.0.1j:


    Skipping backwards is 0% reliable again, as it was before @afl1's patches to 8.0.1i.


    Everything else, I couldn't see any significant differences with.


    So, on my setup, it is a choice between being able to skip backwards in a stream 95% of the time, or 0% of the time.


    I hope, @afl1's patches in 8.0.1i aren't completely abandoned, and some sort of middle ground is found, where we can both skip backwards 100%, and audio sync on other hardware / setups is also 100%.


    Wanted to share this, as I read through recent posts, it seems like almost everyone is using 8.0.1j, even if they don't do anything PVR related. I can see why both builds are advertised as being the latest in the OP, but I think a lot of users aren't understanding the difference.


    kszaq implemented it into i version because some said that it should be fixed, i can only talk about my 2 devices, on them it doesn't work because i have to remove powercord to get the device up again


    Gesendet von meinem Redmi Note 3 mit Tapatalk


    Suspend was re-enabled on version 8.0.1i, because it includes a fix that "may" fix suspend on "some" boxes, where the ethernet driver was causing suspend to fail.


    The proper fix, if suspend still isn't working on your particular box(es), is not to revert to a previous version, it is to stop using suspend, on boxes that still can't suspend properly... Optionally, make a quick post that says "Box model / LibreELEC version / suspend still not working".


    The only reason you should ever revert to a previous LibreELEC version, is if your box(es) develop show stopping issues after an upgrade, and report them in detail as previously noted in this thread, if you want them looked at.


    Thanks for your input but I realize I was not clear enough. I set kodi system => display settings to 2160p60 when the TV is on but when I turn off the box and back on again it is set to 1080p60i. I was just wondering if the display could be set to 4K when switching the box on.


    HDMI connected devices should be able to detect supported display modes even when the display is powered off. Display devices run some internals on standby power, and the chip that advertises compatible display modes is one of them. Short answer: Even if you boot the box entirely with the TV off, it will be able to read supported display modes.


    If you turn your TV on first, give it ~15 seconds, then turn your box on, what happens?


    Yes, gxbb_p200_2G_1Gbit_OTG_Port.dtb is the correct device tree for the Beelink M18

    I don't know how helpful this is, posting it anyways just in case...


    To deal with the AMlogic hardware decoder video buffer always reading 0 or close to 0 issue, in my advancedsettings.xml, I set the minimum video buffer to 0, and the minimum audio buffer to 60 (set whatever you want here). As the AV stream is pulled in as a single interleaved stream, the audio buffer is never far off (+- ~5%) from the true video buffer, and this fixed almost all of my buffering issues a long time ago.


    Like this:


    <pvr>
    <!-- The following PVR cache tags are removed as of Kodi v17 -->
    <minvideocachelevel>0</minvideocachelevel>
    <!-- Cache up to this level in the video buffer before resuming playback if the buffers run dry. -->
    <minaudiocachelevel>60</minaudiocachelevel>
    <!-- Cache up to this level in the audio buffer before resuming playback if the buffers run dry. -->
    <cacheindvdplayer>true</cacheindvdplayer>
    <!-- Cache PVR stream in DVDPlayer. -->
    </pvr>


    Read factor also set to 5, seemed to round off live streams. If you want my whole advancedsettings.xml let me know and I will post. I know it's in the PVR section of the XML, but any changes here effect how all internet streams are buffered on my hardware.


    Also, note the first comment from the Kodi dev's, this all becomes irrelevant on upgrade to Kodi v17, as the whole streaming engine has changed, and dvdplayer doesn't even exist anymore. So, this all may be obsoleted and fixed just by updating Kodi.


    Ok I see, so my sister box must use an identical partition layout, except for /data. All coming together now :-)


    Thank you again for entertaining my curiosity, and dev'ing an awesome beta!

    I want to stick to generic device trees. So far it seems that every box can use one from the trees I provide. Creating a new device tree is very time consuming because you need to decompile dtb, find dtb from earlier kernel version that you can compare it with, compare manually and manually insert every change. These boxes do not provide any hardware ID that you can rely on to load a proper device tree.


    Got it. Thanks for the update, and the info :-)


    Any idea how different S905 boxes share identical boot.img's, with different sized internal storage and RAM? I have a box that does this, with its lower spec'd sibling. Which is what lead me to believe that uBoot supports at least some auto detection during boot.

    Are you looking to collect any device tree sources (actual decompiled code) from S905 boxes that do not have an official device tree image in your download collection?


    Or are you trying to stick with the generic DTB method, to avoid building / uploading possibly 100's of separate DTB binary images?


    If you want more, I will be happy to upload a few, listed by box Make/Model...


    Would it be at all feasible, to dynamically load the correct DTB at boot, based on detected hardware ID's?


    Thanks for a great beta!