Posts by kurai

    Aaargh - after doing some work getting some new skin code to work on the LE Nightly, I used the restore function of the Backup plugin to quickly wipe/reset my changes.

    Turns out the plugin doesn't (or can't ?) honour the permissions settings of /storage/.cache/ssh/

    Now I can't get back into console as the SSHD bails after complaining the permissions are too open.

    It's late, and my brain isn't working properly any more - is there *any* way or workaround to change the permissions via the UI/file-manager or local keyboard access ?

    Or otherwise get a local console going, since there's a keyboard and mouse connected to the machine.

    I'm on the Generic Nightly, & CTRL+ALT+F3 doesn't work, neither does the web-console from systemtools addon.

    Any advice welcome as I'm clearly too tired to be thinking coherently :/

    I have an N6005 device - pretty much the same thing but clocked a little higher and it works fine on Generic LE11 Kodi 20 (Nexus) - even HDR.

    There were a lot of updates to the kernel for Jasper Lake series iGPU happening during the Kodi 19 (Matrix) development cycle.

    Try the Generic-legacy version if you want to stay with LE10/Kodi19 (that worked fine from the start, only without HDR functionality)

    Have you also added the mapping of the Harmony Clear button-send to the Kodi Delete function in .Kodi\userdata\keymaps\keymap.xml ?

    In the Harmony software I have the Clear button set to send the Clear keypress and change it's function, once received, in the keymap instead.

    e.g. snippets from my keymap.xml

    I'm using the Harmony Hub + RF remote + IR blaster to USB MCE receiver but the principle should be the same with Harmony 665 + Flirc IR receiver.

    Great news CvH

    The ticker was usually the way I heard about significant updates/developments first, since I would often miss inbuilt updater notifications and I am otherwise not checking the site/forums all that often ... unless I encounter an issue or just randomly remember to check in, once in a while.

    I am very much of the "if it Just Works[tm]" ... leave it alone until it doesn't ... mindset :P

    There are downsides to this - I recently made a query in the Bug Report section about something and it turned out the root cause was me leaving in an old advancedsettings.xml entry that hasn't been relevant/useful for *at least* 3 hardware platform updates that I've gone through :blush:

    Aaaaah - looks like I had a brain-lock. I was making the assumption the windowing init was happening at a point before any addons were loaded, so they wouldn't be relevant at that stage of startup.

    Turns out that's completely wrong as the clean/vanilla instance chewitt suggests does indeed work properly.

    Looks like it's time for me to go on a cruft-hunt to find out what part of the years worth of accumulated tinkering has misbehaved :)

    I've been using using nightlies since I got this new hardware in October as, at the time, the kernel in the mainline releases didn't support Intel Jasper Lake fully.

    I've been updating the nightly version to latest every week or two since then - never been able to get the GBM versions to init.

    As someone else has confirmed it *should* work, I'll go ahead and collect debug logs etc when I get home.

    Hi all.

    Before I waste everyone's time asking you to comb through debug logfiles & shell outputs, am I correct in thinking that the title hardware *should* work just fine with the standard Generic GBM nightly build ?

    For some reason it always stops at the "critical <general>: CApplication::CreateGUI - unable to init windowing system" entry and I have to use the Generic-Legacy nightly builds with X11 instead, which is a pain since I want to try out HDR.

    I've trawled through a great many of the existing posts and nearly all the potential pitfalls & issues have either already been fixed/integrated into later Nightly builds or don't apply to my specific hardware.

    Am I just being dim, and not finding something already known and/or obvious that prevents GBM working with my shiny new Odroid H3+ ?

    Resurrecting this old thread because I noticed it's still an issue while I was testing a Nightly build install.

    To be clear - it's not an issue with the build itself - it's a problem with this website and how it has implemented it's RSS feed and/or a quirk of the way the Kodi RSSReader deals with it.

    For whatever reason the inbuilt Kodi RSSReader ticker cannot parse this particular feed, even though it checks out fine on the W3C validator.

    Feed Validator Results: https://libreelec.tv/feed.xml

    I copied the XML to my local webserver and chopped out all the article entries, in case it was a parsing issue with one post, but even with just the barebones XML feed structure it still failed to parse it.

    Feed display appears to be b0rked again.

    It fetches and seems to look properly formatted in a web browser, but won't display in LE/Kodi RSS ticker.

    (For both https://libreelec.tv/feed and https://libreelec.tv/feed.xml)

    Other feeds work, and I've changed nothing related on my end, so it looks to be a libreelec.tv issue

    Code
    DEBUG <general>: Thread RSSReader start, auto delete: false
    DEBUG <general>: CurlFile::Open(0x7efdeb34e900) https://libreelec.tv/feed.xml
    DEBUG <general>: easy_acquire - Created session to https://libreelec.tv
    DEBUG <general>: Got rss feed: https://libreelec.tv/feed.xml
    DEBUG <general>: RSS feed encoding: UTF-8
    DEBUG <general>: Thread RSSReader 139629037942336 terminating

    A successful feed has the following DEBUG entry after the encoding line:-

    Code
    DEBUG <general>: Parsed rss feed: https://kodi.tv/rss.xml

    heh - I decided to live dangerously and do an in-place 9.2->10 upgrade, just to see what would happen (after a full disk-image backup, natch ;) )

    I won't say it was ... painless ... but I've managed to get pretty much everything working as I like.

    Fixing/replacing the addons/plugins that were broken in the Python 2->3 transition was the longest part, but it was more a case of step repetition than anything mind bendingly difficult, once I got rid of the defunct dependency packages and updated some repos to their Matrix versions.

    The most "technical" parts were probably tracking down why some of my remote button customisations were broken - turns out that Kodi has finally gotten rid of the XBMC. prefix from the various ActivateWindow() functions (A quick search/replace operation in keymap.xml and all was good again.) and tweaking my favourite skin (Ronie's Transparency) to work as it hasn't been updated for Matrix.

    Really the only thing that doesn't work as I'd like is the TV-NextAired plugin - the Python 3 version works very differently than it's Python 2 predecessor and has a very different UI layout.

    To be honest I'm rather surprised that most of my years worth of endless tweaks and modifications and customisations to OS/Kodi/Skin/addons/settings carried over as well as they did. 8)

    I'm an old school user since XBMC on original XBox and have a pretty good idea of how things work under the hood, so your mileage may vary.

    I *certainly* wouldn't recommend doing this unless you are like me and just want to experiment - if in ANY DOUBT whatsoever follow chewitt and the rest of the LE team's advice, and do a clean install :*

    Have you already applied the setting to force the use of the older "legacy" Nvidia drivers, instead of "latest" ?

    (The later ones cause hangs and crashes upon sleep/resume cycle with older Nvidia video hardware)

    Both sets of Nvidia drivers are included in the LibreELEC install - the udev rule simply activates the legacy ones in preference to latest.

    Having a htpc with a GT520 myself, going into suspend freezes my machine.

    Try enforcing the legacy Nvidia video driver

    Code
    wget http://chewitt.libreelec.tv/96-nvidia.rules -O /storage/.config/udev.rules.d/96-nvidia.rules

    It has solved the suspend problem on my machine, and so far I haven't noticed any video performance problems. The actual problem is hard to tackle so far.

    I have a ... kind of ... similar issue that I have had to work around - but with video as well as audio.

    My setup is an Odroid H2 (Gemini Lake J4105 micro x86 system-on-a-board thing) connected to a Yamaha RX-V485 receiver connected to a Samsung RU7400 TV.

    When I use my Logitech Harmony remote to power on all three devices at once the TV doesn't register any input from the Odroid.

    The Odroid *is* up and running - I can SSH into it and see all the relevant Kodi processes and the kodi.log shows errors relating to no display device connected.

    If I manually turn on TV/receiver *first* then the Odroid initialises video and audio fine.

    The problem seems to be that the Intel HDMI signal only tries to negotiate an EDID handshake *once*, early, during it's boot or resume process and if the receiver and/or TV isn't yet ready it doesn't retry and stalls video/audio over HDMI until sleep/resumed or rebooted once more.

    So ... as Da Flex says - it seems to be a timing issue.

    The quick and dirty workaround I have set up is to either

    • add a 1 second delay to the Odroid's startup trigger in the Harmony remote software, to give the receiver time to bring up it's passthrough signalling and the TV to enable it's HDMI inputs fully.
    • or start a different video source device group first (e.g. FireTV Stick or MS Remote Display Adapter which are also plugged into receiver HDMIs) then use the Harmony remote to switch to the Kodi/Odroid "activity" - i.e. Harmony knows that the receiver/TV are already on, so just switches receiver inputs and starts the Odroid.

    I don't know enough about the low level video output process chain to say whether its an integral problem with the Intel chipset hardware, or if its something that could be addressed in software via the Linux Intel video drivers or LibreELEC tools/processes. :(