Posts by ozarks

    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
    1. LibreELEC (official): 9.2.3 (Generic.x86_64)
    2. LibreELEC:~ # lspci
    3. (...)
    4. 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (primary) (rev 0c)
    5. 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (secondary) (rev 0c)
    6. (...)

    On this hardware I have this problem:

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

    Any idea?


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

    On this hardware I have this problem:

    Code
    1. LibreELEC:~ # vainfo
    2. libva info: VA-API version 1.5.0
    3. libva info: va_getDriverName() returns 0
    4. libva info: Trying to open /usr/lib/dri/i965_drv_video.so
    5. libva info: Found init function __vaDriverInit_1_5
    6. libva error: /usr/lib/dri/i965_drv_video.so init failed
    7. libva info: va_openDriver() returns -1
    8. 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

    Glad that it fixed the dark video rraod.


    BTW, you should not need the reboot to libreelec Android app as the default for a normal boot will be to boot from the SD card.


    I think that it's use is probably for those users that have dual boot options when both OS's are installed on the internal storage.

    Try the LibreELEC-S912.arm-8.2.5.1-444-1000nits build from here.


    I've been using it on my S912 and it's about as perfect as you can get and all videos and streams are pretty much flawless and not a dark video in sight.


    I have tried Coreelec and it does work well but because I use Comskip, it isn't yet compatible with the latest Leia based releases, I'm sticking with it.


    Could not be happier right now.

    I would prefer to see words such as 'misogynistic' not continually misrepresented and completely misunderstood.


    Firstly, in reference to the term wife acceptance factor, we should first look at what it refers to.


    "an assessment of design elements that either increase or diminish the likelihood a wife will approve the purchase of expensive consumer electronics products such as high-fidelity loudspeakers, home theater systems and personal computers."


    It implies no such derogatory statement about women.


    It is simply a tongue in cheek reference to something that many men may well have experienced when going out to buy their beloved tech.


    The really bad practice seems to come from people who are unable to balance a sense of humour with ethical and moral thinking that matters and seek to ban anything that they decide is offensive, without really looking at the larger picture.


    Look at 95% of humour and you will find it aimed at somebody, often taking a stereotype and exaggerating it.


    Be careful what you wish for because you may find others picking holes in what you find amusing, dissecting it to fit in whatever they decide should be right and wrong for today, or turning your own arguments around to make you face your own morality to make it appear that you want a cake and eat it kind of scenario.


    That's my tuppence worth on the subject.

    There is no such file in the image. Therefore, it is built outside the source kernel that is used in the image and will not be able to work with it.



    Show the entire output of the script. The specified error may not be critical (in some cases). What system is installed in eMMC ?

    Thanks for the confirmation.

    I am using the latest image LibreELEC-S912.arm-9.0-devel-20180920164743-905fd26.img.


    I put a link to the dtb as part of the name in the last post.


    gxm_q201_2g_1gbit


    Thanks

    I decided to give this a test and initially was able to boot up from the SD card successfully but I noticed that whilst I had WiFi, there was no Ethernet connectivity shown.


    So I swapped out the q201 2g dtb with the one that I had previously been using that has ethernet (gxm_q201_2g_1gbit.dtb) but then unfortunately it would not boot at all.