Posts by milhouse

    Yesterday I tried to play few movies in Kodi in 4k - results are not good, stuttering, freezing etc.


    Dolby Atmos and DTS HD MA not worked only DD 5.1 (yes i had enabled passthrough and Dolby Atmos and DTS HD MA capable receiver, this option worked with my S905X).

    Were these h264 or HEVC 4K videos? 4K video playback is HEVC only.


    From the announcement post:

    * HEVC decode to [email protected] (with HDR)

    * H.264 decode to [email protected]


    If these were HEVC 4K videos, can you post the media info?

    milhouse I will wait for the USB booting then. I was wondering if I can use the following method (I guess it should be faster):

    1. Download RPi4 image and manually upgrade my RPi3 with it (update folder).
    2. After rebooting my RPi3 should show the rainbow screen (firmware not right)
    3. Activate USB boot on my RPi4 (when available)
    4. Plug in my USB HDD in the RPi4 and cross fingers

    What do you think?

    You'd need to create /storage/.update/.nocompat to allow the RPi3 to upgrade using RPi4 image/tar, but then once it has finished upgrading to the RPi4 version of LibreELEC it will fail to boot as the new RPi4-based installation (when running on your RPi4 hardware) would not be able to boot from the USB drive to which it has been installed.


    If you left the RPi4-based installation running on your RPi3 hardware it may actually boot from your USB HDD, but the "RPi4 on RPi3" user experience is not good at the moment.


    My advice would be to install the RPi4 image to a fresh SD card, boot it and restore a backup of your RPi3 installation. Once USB booting is supported by the RPi4 - instructions will be posted detailing the bootloader flashing process - you should be able to attempt upgrading your RPI3 without the SD card using the latest RPi4 image and the nocompat method above. Then replace your RPi3 with your RPi4.

    soyxan USB and network booting are not yet supported, this is on the RPi Foundation to-do list - USB booting should be along soon (few weeks) followed by network boot support. The RPi has 512KB of flash memory so the bootloader can be updated with new features and bug fixes.


    Assuming you're happy to boot from SD card it should be possible to restore a backup of your RPi3 installation to the RPi4 system.

    I installed RPI4 arm 9.1.001 on my Rasberry Pi 4 and everything is very lazy and slow. Moving between menus is not smooth and just ugly.


    After some time in Kodi appeared a thermometer in right corner, so RPI is burning.


    With Noobs is not possible install Raspbian and LibreELEC, Noobs doesn't recognize LibreELEC image.

    Tearing in the GUI is a known issue.


    It's best to run the Kodi GUI at 1080p rather than 4K as this will result in snappier performance (Settings > System > Display > Limit GUI Size > 1080p).


    RPi4 shouldn't be overheating in normal usage, you can try running bcmstat.sh to monitor temperatures.


    It's possible that NOOBS needs to update with RPi4 support (guess, as I've never used NOOBS).


    Any plans to do version for RPI4 faster and smoother? Or I'm just using wrong version?


    This version is unusable with RPI4

    Yes, this is the first release on brand new hardware, of course things will improve. As mentioned in the blog, this RPi4 release is essentially an "alpha" release. The feedback from this and subsequent releases will lead to improved RPi4 kernel and firmware support which will be a huge benefit to LibreELEC with Kodi 18 and, eventually, Kodi 19.


    To be totally honest I have found the RPi4 version of LibreELEC 9.2 to be entirely usable, and stable. I'm confident the more obvious issues will be addressed quickly.

    If Mainline support where the great bugbear that is claimed why release a Rpi4 none mainline Leia build of LE - its simply inconsistent and that tells the lie.

    Why? Because RPi4 is going to be massively popular, and we took the decision to push out a short-lived branch with experimental RPi4 support as - unlike the AML situation - there is no other *ELEC option for RPi4 users. RPi has always used modern kernels so rounding out support to include RPi4 wasn't a big deal, and not only that, this RPI4 release is an important learning curve for both us (LibreELEC) and RPi Foundation for brand new hardware.


    So just to summarise: AML users have options - they're not being hung out to dry - but RPi4 users don't have the luxury of options, hence this exceptional release. Do you not see the difference?


    BTW, the situation in LibreELEC master for RPi (including RPi4) going forward will be entirely different to the way it currently is in libreelec-9.2, particularly once we transition closer to Kodi 19 when MMAL will be dropped.


    Progress is happening, sorry it's not the way you'd like it to happen, but it's being coordinated in the best way possible between those that are involved with the code building Kodi and LibreELEC for the future. Continuing to shout from the peanut gallery isn't really contributing anything.

    Shoog we (the LibreELEC developers - you know, the ones that actually do the heavy lifting to maintain this stuff) just don't want to waste time maintaining a dead-end 3.14 kernel. There are alternative options available for those that _do_ want to continue using the 3.14 kernel with the latest hacked up versions of Kodi. For everyone else, they can continue using their current version of LibreELEC and Kodi until we have something better to offer them. Iterating on 3.14 in the short term is utterly pointless. And with 100% focus now on maineline, progress is going to happen sooner than it would have done if we still had the distraction of 3.14.


    So that's the reality, that's why we have done this - because there are other options now (nobody is forced to use LibreELEC), and 3.14 is a developmental brake that is slowing progress for everyone.

    Digital passthrough can work perfectly on 3.14

    Please stop with your obsession for 3.14. We both know it's a total patch-fest, there's no vendor support, full of never-to-be-fixed security holes, and even upstream packages which are vital to LibreELEC are starting to have problems supporting such old kernels. Ultimately there's no long term or even short term gain by continuing to maintain a kernel this old.


    3.14 has been dropped and the way forward is the mainline kernel - it's a cleaner solution and we don't have to waste time trying to keep old crap building, which is a major distraction.


    If you want to continue using builds based on 3.14 then you know what to do.

    Well good news...but they didn't fix it actually they just used the same workaround we used not to have the glitch: disable fbc...

    Yes, I was being sarcastic - I probably should have put double-quotes around the word fixed... :)


    Given Intel don't seem willing to fix it properly, it does make me wonder if the hardware (silicon) is incapable of being fixed. Fortunately it seems to work adequately without fbc.

    Intel have fixed the Gemini Lake framebuffer compression bug in kernel 5.1.9 - it's now turned off by default.


    changelog-5.1.9:



    Hey There. I just upgared to the lates libreelec on my HTPC, which is fairly old. (Asrocm e350m1) I1m getting constant stuttering now during video pleayback. Is there any way to switch bak to the old VDPAU rendering method?

    No there's no way to use VDPAU with AMD, it's no longer supported.


    If you're experiencing stutter issues with AMD and VAAPI then your best bet is to post your debug-enabled kodi.log in the LibreELEC x86_64 Kodi 19 test thread on the Kodi forum (as that's where those test builds are supported) and maybe a sample video file too.

    I have encountered all of the main personalities in this story and I simply ain't buying the poor Innocent wronged victim narrative.
    What I see is the sad bickering of divorced parents.

    Just as a bit of perspective - hows the relationship with team OE going ?


    Shoog

    I've no idea who you are Shoog, and while you may think you've encountered "all of the main personalities" you are unlikely to have first-hand evidence of what happened 2 years ago, so sorry, buy what you want, but you're doing so while not fully informed.

    Anyway... Team OE? It no longer exists.

    I tried to stay out of this issue, but damn you sure sound like you are lying


    "They do no give anything back" ... "OK they do , but we don't accept them" ... "OK, there was one, but how many more"

    which is it?

    Not "lying", geez! Go find the evidence, the smoking gun. That particular PR wasn't accepted because the contributor refused to engage - what do you want us to do, we're not mind readers! But it is at least an example of how difficult it was working with some contributors that are no longer team members - as I said, peer-review requires two way communication, not a refusal to engage or hissy fits when issues in the code are pointed out. Anyway... I'm done - believe what you want (I promised myself I wouldn't be (ab)using this thread for this [email protected]). :)

    I'm not sure why Kodi continues to crash, to be honest.


    The best option may now be to try booting your NUC from a LibreELEC 9.0.1 USB memory stick using the "live" mode and see if that works - if it does (ie. Kodi doesn't crash) then it's most likely a corrupted setting that is causing the issue with your normal installation, which you may need to wipe out with a fresh install (you could try deleting or renaming /storage/.kodi as well). While an upgrade from older installations normally works it's not guaranteed, particularly when major changes to settings occur as is the case when upgrading to Kodi 18.


    If Kodi continues to crash when booting from the LibreELEC 9.0.1 memory stick then this requires further investigation as that would not be expected behaviour - I'm pretty sure your Haswell Mobile hardware is still supported.

    Well, not true. Let's look this patch drivers/wetek: build open-source dvb driver by afl1 · Pull Request #116 · LibreELEC/linux-amlogic · GitHub

    It is even for Wetek who donated to LE but LE ignore things from others.

    One PR, and look at the usual suspects that piled on with unhelpful comments. When a serious development question is asked by a LibreELEC developer there is no response from the contributor. The peer-review process is all about adult-level, professional, two-way communication, and when a contributor refuses to engage in kind - or at all - are you really going to blame LibreELEC members for not wasting their time reviewing the code, let alone merging it?


    How far did you have to dig to find that "gem"? Are you going to keep digging? :)


    Also sometimes things come to LE by mysterious ways from CE :)

    I expect better of you, to be honest. I'd ask you to post some concrete examples rather than make vague claims, but really I'm not going to waste my time refuting single lines of code with you!


    The afl1 driver is possibly the sole contentious area that I'm aware of, as efforts were made separately by LibreELEC to include that driver with chewitt in discussion with afl1, but due to interference - not least CoreELEC switching to an incompatible project licence illegally changing the licence on code to which they don't own sole copyright - that development hasn't yet concluded.

    Unfortunately this lack of transparency is a bit sad, but its helped me decide who is distorting the story.

    Shoog

    Yes, it's a shame so much of this happened in private team chats, but if you care to familiarise yourself with the rage-closed PRs then you might get a feeling for how bat sh1t crazy things got and why Team LibreELEC members slowly stopped reviewing the PRs because they became sick and tired of all the drama while only trying to help contributors improve their code towards submission.


    But if you're suggesting I'm "distorting the story" then... LOL. Just LOL. Unless you were privy to the conversations prior to the fork you really have _no idea_ how horrible it was dealing with various former contributors, and for that you should consider yourself fortunate.

    Unfortunately I call BS on this since I know of at least one which was not. If you can't even be honest then its best to be quiet.


    Shoog

    Not really sure what you're saying here about "at least one which was not" but please don't tell Kwiboo (or any other forum member for that matter) "to be quiet" as Kwiboo had first hand experience of how it went down in the Team LibreELEC Slack prior to the fork.


    There were several Amlogic PRs from CoreELEC founders merged *before* the fork, many more that were rage closed by the contributor during the peer-review process (as while they might have worked for Amlogic they broke or impaired pretty much every platform other than Amlogic), and I'm certain that there were *no* PRs contributed after the fork as CoreELEC made Team LibreELEC very aware that they would not be upstreaming any of their code. Needless to say, we were left distraught and dismayed at their decision (nah, not really!)