Posts by ozarks

    Hi,

    For all the those with an Orange Pi 5, I have posted a guide over on the Armbian forums to enable Kodi on Orange Pi 5 with GPU Hardware Acceleration and HDMI Audio.

    [GUIDE] Kodi on Orange Pi 5 with GPU Hardware Acceleration and HDMI Audio

    Hope this helps scratch that Kodi itch, until the superstars that maintain LibreELEC have a build available for the Orange Pi 5.

    :)

    Awesome. The community development for this board in such a short space of time is amazing.

    Originally had this problem with a Millhouse Kodi build but nobody on the Kodi forum was able to help, so tried with a fresh default generic Libreelec installation and then with the latest nightly with all 3 showing the same results. The following is the key elements of my post. I had thought that Braswell would no longer be supported but it seemed that the most likely scenario was a switch to i965 rather than iHD but I was unable to find a method that would work.

    I carried out a new installation to a USB flash drive and booted using an Asock Beebox N3150.

    After seeing the initial text splash screen that gave the options for running (live, run etc) the screen went blank and the only activity was for a few seconds on the flash drive.

    I shut it down and booted from the same flash drive to an ancient second gen i7 laptop and it booted fine.

    I set a manual IP address, booted again from the Beebox and then SSH into the box to look at the log.

    There was a specific line that stood out that read ERROR <general>: libva error: /usr/lib/dri/iHD_drv_video.so init failed

    I guessed that this might point to the problem but whilst I could find plenty of info about it, it was all geared towards Linux installations and I could not see anything that might help solve things.

    Copied the contents of the Kodi log to hastebin and hope that this gives the required information for diagnosis.

    hastebin

    Thanks

    Code
    LibreELEC (official): 9.2.3 (Generic.x86_64)
    
    LibreELEC:~ # lspci
    (...)
    00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) (rev 0c)
    00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (secondary) (rev 0c)
    (...)

    On this hardware I have this problem:

    Code
    LibreELEC:~ # vainfo
    libva info: VA-API version 1.5.0
    libva info: va_getDriverName() returns 0
    libva info: Trying to open /usr/lib/dri/i965_drv_video.so
    libva info: Found init function __vaDriverInit_1_5
    libva error: /usr/lib/dri/i965_drv_video.so init failed
    libva info: va_openDriver() returns -1
    vaInitialize failed with error code -1 (unknown libva error),exit

    Any idea?

    Code
    LibreELEC (official): 9.2.3 (Generic.x86_64)
    
    LibreELEC:~ # lspci
    (...)
    00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) (rev 0c)
    00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (secondary) (rev 0c)
    (...)

    On this hardware I have this problem:

    Code
    LibreELEC:~ # vainfo
    libva info: VA-API version 1.5.0
    libva info: va_getDriverName() returns 0
    libva info: Trying to open /usr/lib/dri/i965_drv_video.so
    libva info: Found init function __vaDriverInit_1_5
    libva error: /usr/lib/dri/i965_drv_video.so init failed
    libva info: va_openDriver() returns -1
    vaInitialize failed with error code -1 (unknown libva error),exit

    Any idea?

    Are you getting a blank screen after seeing the initial splash to confirm booting?

    I have a couple of older Intel Boxes. One running a x5-Z8350 (HD Graphics (Cherrytrail)) and the other a Celeron N3150 (Intel(R) HD Graphics 400 (Braswell).

    Both were previously running fine using some old builds based upon Linux kernel 4.19.

    I created a new fresh USB boot using 9.2.2 and fired it up on each box.

    On the x5-Z8350 I end up with a blank screen other than a few lines showing errors, all very similar such as:

    [ 0.37032] ACPI Bios error (bug) failure creating named object [\SB.STR3], AE_ALREADY_EXISTS (20190215/dswload2-324)

    On the N3150, there is just a black screen.

    On both boxes however, I was able to SSH with WinSCP, which seemed to indicate a successful boot process.

    I also ran the command kodi-send --host=127.0.0.1 -a "TakeScreenshot" and to my surprise, it captured the full Estuary opening screen.

    The same USB build works fine on machines with an old Core i7-2630Q or newer N3350 or N4200.


    Trying various older builds I find that anything based upon Linux kernel 5 or above will not work but anything prior to that works.

    Searching for info regarding the ACPI bios error doesn't yield anything that specifically answers the question as to what it is any why it occurs.

    I was asked to update a friends older Libreelec running on an SD card on their Beelink GT 1 clone 2Gb/16Gb/1GB Lan(which runs GT1 Android perfectly).

    But I ran into some issues.

    Firstly in the initial post of this thread there is mention of a new activation of the universal multi-boot but no mention of what, where and how this part is achieved.

    So I soldiered on with the knowledge that I had from previous installation.

    Flashed the latest S912 image (LibreELEC-AMLGX.arm-9.80-devel-20190821140333-07b919f-s912.img)

    It was to clear which DTB should be used but as this was a q201 board (which the previous Libreelec version had a DTB for this setup) it seemed logical to start with the meson-gxm-q201.dtb, so I modified uEnv.ini and extlinux.conf as appropriate.

    Popped in the SD card and started up the box, which initially booted to Android, so I installed the Reboot to Libreelec app, ran it and it proceeded to boot from the SD card and I saw the Libreelec logo.

    But after waiting a little while, I noticed that a reboot had been automatically initiated, where it would go through the same process again and again, in some form of boot loop. It did this a number of times before just stopping with no activity and a blank screen.

    So I switched the box off and put the SD card into my PC to see what it;s state was. It seemed to be at the same state that it was in before placing it onto the Android box.

    I wondered whether the dtb was incompatible, so after a little searching it seemed that the extlinux.conf or meson-gxm-rbox-pro might potentially be compatible but after trying each, the same boot loop activity occurred.

    So I am stuck as to what direction to go in next and wonder whether this mysterious universal multi-boot thing holds the answer?

    I've been using both LE (LibreELEC-S912.arm-8.2.5.1-444-1000nits) and CE (nightly and stable builds) regularly on a daily basis for a while now on 2 S912 boxes.

    To say that CE is is almost not stable and faulty is perhaps a little strong.

    In terms of general picture quality, LE scores higher, especially when it comes to OTA SD content, where the picture is sharper and colours more vibrant. However CE continues to show great improvements and recent nightly builds bring the quality much closer.

    LE has issues with HEVC content where playback starts but within a few seconds can cause a blank screen, requiring either a scrub to the end of the video or a reboot to resolve. CE does not have this issue.

    General playback of the vast variety of video formats is consistently good with both but when it comes to things like Sony_4K_HDR_Camp and many other test files of the same type, LE plays perfectly but CE, in any form shows distinct stuttering, so there is absolutely no doubt that under the same conditions, using the same box, LE beats CE for such very high end video, although it should be said that the general availability of commercial release movies/TV shows using the high end settings of the test files is probably minutely small, so not necessarily a great issue for now but something for the future.

    This difference could of course may be related to either CE or LE directly but perhaps to Kodi, where for my use, I am essentially using 17.6 on LE and 18.x on CE, which will still be prone to bugs until 18 becomes an official stable release.

    The only area where neither currently works for me is with regards to commercial 4K releases, where I find things too dark in comparison with 720p/1080p versions, so stick with these for the time being.

    I do think that to some degree, a form of competition gets created when both comparing the two and giving feedback that can sometimes render some form of hostility, which is a shame because I believe that most people just want to give constructive feedback to aid, rather than hinder development.

    The vast majority of users appreciate the work that goes into development and perhaps that also gets a little lost in the conversations, where devs perhaps feel as though they are being jumped on rather than being supported.

    We are all most certainly in a far better position than if such endeavours were left to hardware manufacturers, that consistently provide sub par software out of the box.

    I am a very happy camper with what is available, as I believe that most of us are and should be.

    What I found was that when the addon was installed, the folder that was created was automatically populated with the ini file.

    If I am reading things correct, your modification to comskip.ini references a specific file name, which I am guessing won't work unless you can predict the name of the file that will be recorded.

    There are also a couple of back slashes in there, which I'm not certain are allowed.

    One thing that I did change, which might not have any impact, but worth trying, is to use the default stream profile for Matroska, which is then also selected in the recording section to produce a .MKV file rather than a .TS.

    I take it that you are not using a 9.0 based LE release as the addon doesn't work with the latest releases and comskip is now baked into the latest TVheadend builds.

    Installed the 1468 generic release on Millhouse #1015 build.

    When first attempting to record there was no output.

    I turned on Activate TRACE Debug to see if I could find out why and whilst active, recording worked.

    After turning the debug off again recording is fine and also works after a reboot.

    Also tested Comskip and it works perfectly.

    For reference, the Post-processor command: entry for Comskip should read:

    /storage/.kodi/addons/service.tvheadend42/bin/comskip --ini=/storage/.kodi/userdata/addon_data/service.tvheadend42/comskip/comskip.ini %f