Posts by yubby

    The 'ol issue of the 'text' keys on the MCE IR Keyboard have cropped up again, forcing me to 'back rev' any of the x86 systems that are using them to version 9.0.2

    I had found from other users' postings, that the issue cropped up in the development releases, which apparently hadn't been resolved, and moved downstream into the general release...

    I had researched the issue last week, but traveled and lost the URL's (developer forum ?) that I was referencing. Several users had encountered the issue, and back-rev'd as I have...

    Now that I'm 'at home', I'll re-test the issue, and submit the differences I had found in the "dmesg" and 'log' outputs (between versions 9.0.2, and 9.1.002)

    It wasn't until I started upgrading all of the LibreElec units I have (and have distributed to friends/family) that I noticed that 'video acceleration' was enabled for the on-board graphic processors that never had it (and were reaching 99% CPU usage for 4K 'high quality' video streams).

    VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RS880 [Radeon HD 4200]

    I'm seeing approximately 25-33% less CPU usage (see images) with the VAAPI acceleration enabled.

    BUT, I have also found that the acceleration is DIS-abled after the unit(s) have 'gone to sleep' (suspend mode) and been re-awakened. Only a reboot of the system re-enables the acceleration abilities...

    The problem is sometimes more obvious, with a 'lockup' of the GUI when Kodi comes out of 'suspend mode', with a strange artifact in the middle of the display (see images), and then either a 'reset' of the desktop, or a restart of Kodi (without rebooting), with either action resulting in the disabling of video acceleration.

    Yes, 'those 2' steps are performed, but as mentioned in my original utterance (above), the 'peripheral' items appeared (to me at least, but someone 'liked' my post, which may indicate that they have experienced the same issue) to have been 'skipped', such as migrating the current 'skin' and it's settings, and other configuration items...

    AH ! But now that I think about the issue realized (made apparent) during the '.img' file installation method, if the Confluence add-on is being 'auto-disabled', then the skin and it's "settings" would NOT be migrated (would they ?)....

    And the 'encoding' settings for RIPing CD's are lost, since there's no 'encoder' (LAME being auto-disabled)..

    SO, if there 'is' an issue with add-ons being auto-disabled (rather than being 'updated' from the Kodi repository), then 'that' may be the 'only' issue, which if resolved, would solve the issues that 'I' have encountered with the updates.... (results may vary)

    Yes, as long as the 2 'packages' contain the same contents, and are both installed during the 'reboot' process (where I get to watch the ASCII terminal text of it unpacking, check-summing, and installing), it 'should' behave in the same manner.

    BUT, it hasn't, which is the odd thing...

    Also, with the add-ons which get auto-disabled during the process, it may point to specific Kodi configurations, where the 'order' of the steps is blocking or being negated due to prerequisites of specific steps not being met (i.e. check for add-on updates, 'before' deciding whether the add-on is to be disabled). The 2 add-ons that I've experienced the issue with (Confluence and Lame) are in the official Kodi repository, which you'd think 'would' be auto-updated...

    Just an FYI (I've got a lot of these lately), the 'in-app' updater (Main Menu -> LibreElec -> Updates) acts differently, than dropping the ".img" file in ".update" (and rebooting) when upgrading from 8.2.x to 9.0.x

    The 'in-app' updater does not appear to 'migrate' configuration settings, skin, and add-ons (as per my recent experiences updating all the units I've deployed), so I've avoided 'that' method, and have had 100% success (so far) with the 'full image file' method...

    EXCEPT !! 2 installed add-ons appear to have frequent issues with the upgrade (Confluence and Lame) which are 'auto-disabled' during the process, and have to be 're-enabled' and 'updated' manually, before they can be used again...

    Just an FYI...

    I found 'this' thread in response to migrating to the "Chrome" add-on (since "Chromium" has been dropped) and ran into the 'no audio' issue.

    Yes, must set the 'audio device' used by Chrome manually.

    'mine' was "plughw:1,7" (knew 'which' Nvidia output device by the order listed in the "settings -> audio" display in LibreElec)

    :~/.kodi/temp # aplay -l

    **** List of PLAYBACK Hardware Devices ****

    card 0: SB [HDA ATI SB], device 0: ALC662 rev1 Analog [ALC662 rev1 Analog]

    Subdevices: 1/1

    Subdevice #0: subdevice #0

    card 1: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0]

    Subdevices: 1/1

    Subdevice #0: subdevice #0

    card 1: NVidia [HDA NVidia], device 7: HDMI 1 [HDMI 1]

    Subdevices: 0/1

    Subdevice #0: subdevice #0

    I have just encountered this issue, with a LE system using an ASUS GT520 video card, and a new Samsung 75" 4K LED television.

    Depending on the resolution 'chosen' (or selected during startup ?) the calibration settings are lost.

    I think I reduced the cause to the 2 different "1920 x 1080" resolution choices (presented in system->display->resolution) to the one using '60 hz' and the other using '59.5923759834734 hz' (not exact).

    One 'saved' the settings, and the other doesn't, but the system chooses the 'bad' one during startup (sometimes).

    Indeed...

    I have begun upgrading my 'friends/family' systems with LE 9.0.1 and found that the MCE button assignments have been 'fixed' so they match the 'real' MS MCE control layout.

    ALL context menus are now assigned to "DVD Menu", and the "Guide" and "Info" button assignments are 'swapped' (Guide being 'TV Guide', which most users won't need).

    Such that, I created 'my' custom MCE keymap (named "MCE-custom.xml") which contains the following to assign the numpad '8' to video 'info' and the '9' to 'codec info':

    This may require a 'new/different' thread, but the 8.2.x and 9.x.x LE versions may have introduced an additional issue, or a new one, where the system cannot 'shutdown' or 'suspend', due to Xorg getting 'stuck' (and it's process running-away at 100% CPU) during the 'shutdown' process (as per tailing the 'kodi.log' file). LibreElec-shutdown-issue-logs.txt

    I cannot 'kill' the Xorg process (even with a -9), and requires the 10-second power-button death stroke, to shut off the system.

    Oddly enough, it appears to be isolated to 4K televisions. ((systems using an ASUS GT520 video card))

    I believe I have reduced the possible issues to the driver or card (tested using the 'current' Nvidia version, and the 'legacy' one via the UDEV 'fix'), attempting to converse with the TV (and not getting a response ?) by testing the process of selecting 'power off', but pulling out the HDMI cable before pressing the 'OK' ('select') button, at which point the system shuts down properly...

    Just an FYI, I've begun updating the 'friends and family' systems with 9.0.1 (Leia), and have found almost ALL of the screensavers of the 'long long ago' (Euphoria, Fieldlines, etc) are now unusable. (resorting to 'dim').

    I suspect that the 'maintainers' of those screensavers have NOT updated to Python version '3'...

    Well, I did just that, though it's a different 'internal' PCI-e x1 card, which I bought on Ebay for $13 total...

    Same chipset vendor, but different 'chip'... (why the '5592' isn't supported, but the '5392' is, is interesting)

    1f:00.0 Network controller: Ralink corp. RT5392 PCIe Wireless Network Adapter

    [ 7.538219] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 5392, rev 0223 detected
    [ 7.543014] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 5392 detected
    [ 7.544754] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'

    [ 9.586219] ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2860.bin'
    [ 9.588453] ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.40

    I can 'see' my neighbor's AT&T routers now...

    The lspci output only proves the hardware powered on, it has no bearing on driver support for the hardware. The (broadcom) wl module contains a mixed GPL/proprietary license which taints the license status of the kernel (no longer pure GPL). It's irrelevant.

    What driver is that card supposed to use?

    Ah, the 'wl' module 'is' for the Broadcom gig wired interface that's also present...

    I tried to use an ASUS PCE-N53 PCI-e (x1) card, but it does not appear to be 'enabled' (can't connect/doesn't show any wifi networkds), though it's detected by the O/S.

    lspci:

    1f:00.0 Network controller: Ralink corp. RT5592 PCIe Wireless Network Adapter

    Is 'this' related ?

    dmesg:

    [ 7.510104] wl: loading out-of-tree module taints kernel.
    [ 7.510107] wl: module license 'MIXED/Proprietary' taints kernel.