Posts by inspector71

    I used `rpi-eeprom-update -a on my Pi 5 recently, that went fine.

    That's a different script to rpi-update though.

    I am aware rpi-eeprom-update exists in LE builds as far back as 9.2.6, maybe earlier. However, when run, it's output is quite strange to my mind, at least. Alas, I cannot currently paste into this forum! Not as a quote, code block, plain text at least. What I see is "LATEST" is older than the "CURRENT" but both are quite dated. 2020 and 2021 respectively. That lingo makes no sense to me.

    The script I am referring to has been around since before the RPi got EEPROM on the board. I do not particularly mind which methodology is applied. But I need to know what is going to be the outcome beforehand as I'm wanting to tweak a very well running installation that I do not want to break.

    GitHub - raspberrypi/rpi-update: An easier way to update the firmware of your Raspberry Pi
    An easier way to update the firmware of your Raspberry Pi - GitHub - raspberrypi/rpi-update: An easier way to update the firmware of your Raspberry Pi
    github.com

    I'd like to know ...

    1. Exactly which files are replaced by each script?
    2. Does the script default to the most recent versions of files?
    3. Can I apply older versions of files over newer versions if the newer versions misbehave?
    4. Can I brick the hardware by running the script?
    5. Can I brick LE by running the script?

    I have some answers to these questions so far, but I would like all of the answers I need before proceeding. Although I'm also throwing changes at a 'naked', fresh instance I can easily sacrifice :)

    Thank you for your thoughts, much appreciated :)


    Same for me, no issues.

    Folks can still also just flash the firmware direct to an sdcard, and it'll auto-install without manual commands required:

    https://github.com/raspberrypi/rpi-eeprom/releases

    I was thinking of copying newer versions of certain files on to the FAT partition, over-writing the defaults. For example, there is a start4.elf and start4*.elf series of files supplied by RPi Foundation but not seemingly bundled with the LE RPI4.arm releases. May be playing with fire but I am curious if these start4 file or files may fix a hardware compatibility problem I am experiencing.

    I seem to recall LE devs stating it's a bad idea to run rpi-update to get a newer firmware version. However my skills and/or this forum software do not return anything, viewable in the precis of search results, when searching for '"rpi-update"'.

    Is using rpi-update to get a more recent firmware version advisable?

    FWIW, disabled all addons and still no luck. Blocked JS hoping to get a naked textarea instead of a CKEditor5 instance.

    Running Firefox 115.6.0esr on Windows 10.

    Can actually paste via the CKEditor5 link insertion widget. But not directly into the instance.

    In case of any confusion, it's pasting into the CKEditor5 instance that is the issue for me. Copying from the CKEditor5 instance works fine.

    Oh well.

    Cannot answer all those questions but this may be of interest:

    Also, this post:

    chewitt
    December 26, 2023 at 2:55 PM

    Is there a web site where we can browse the LibreELEC add ons repository? I thought there was at some stage but maybe it's gone?

    I ask because when documenting, debugging issues, it would be good to have a site to refer to, rather than a reference to "System Tools" or "Raspberry Pi Tools" which are good but very generic terms.

    Please note: I am not requesting anything here. Not trying to put any stress, pressure, workload on anyone. More just checking if I can't find such a resource or such a resource doesn't exist. I've had a look here:

    Unofficial add-on repositories - Official Kodi Wiki

    and here:

    Category:All add-ons - Official Kodi Wiki

    Though those are official Kodi links, I thought the official builds might at least include the LibreELEC repo as an option, and thus maybe a wiki page for it that might lead to further clues. No such luck.

    LE10 (stable) and LE11 (stable but still pre-beta) images can do everything that LE 9.2.8 can do.

    Respectfully, that's false.

    Quote

    Use them; they are greatly superior than LE 9.2.8 now.

    Developers require such deep technical knowledge, and work so very hard to produce newer builds, that it's so easy to become embedded in the mentality that the sole value of software is determined by version numbers, API support, bit depth, codecs and all sorts of technicalities.

    Software only exists as part of an ecosystem combined with hardware, usability and support. Crucially, software is irrelevant if not experienced by humans.

    As much as I absolutely and completely appreciate the massive, dedicated efforts of the Kodi, LibreELEC developers, the use case I have is not some high-tech scenario wherein everyone's got all the consoles; can afford an nVidia Shield; doesn't mind that Kodi can't be booted directly on Android (without arsing about); only needs one telly, not two so MicroHDMI is just another $30 cost; uses a 10 years old 1080p display with whatever colour depth was available 10 years ago; doesn't care about surround sound so boosting the vocal channel to make 5.1 watchable would ideally be default (though I understand why it is not); can't afford / doesn't want to play the streaming services lottery just to access the odd murder mystery in SD or HD because storing larger files - even 1080p - takes up more and more space ... etc.

    So I'll be the judge of what is "superior" and that will be what provides the basics of user needs. Thus far in the decade+ 'journey' (cough, splutter, spit) of porting the 'smart' phone platform to an SBC, ultra simplistic realities like the need for reliable power supply / storage that doesn't fry itself with the occasional surge or brownout; a power button to empower ordinary users to hard shutdown an invariably-freezing-at-some-stage system ("Have you tried turning it off and on again?" has not been simplistically practical with the RPi ecosystem); basic cooling of the hardware ... have been largely ignored or sometimes dubiously supported. Yes, they are finally there in basic form with the RPi 5, but it's been forever, and a lot of wasted money and frustrating, stressful effort trying often poxy or just unsupported HATs and so forth. Nobody wants to come out and say so because the innernets is a honeypot for trolls so it's not acceptable to be reasonably critical lest readers feel it's another troll post. Also because it's an ecosystem wherein everyone's putting in so much effort for free.

    Working around these limitations has been a continual requirement, amongst attempting 'up' grades because everyone in the tech industry gravitates towards that all-about-the-software in isolation, rather than the full user experience, headspace and thus writes the likes of what you have done above. Which is tantamount to "I am sick and tired of legacy users, FFS, just 'up' grade". As somewhat forceful, rude as that could be interpreted, I can actually fully understand it. But I don't agree with it. I'm looking to reduce my ballache and if that means stopping at a version that supports everything I need, as a whole, so be it. AN 80 Km round trip to rescue yet another fried SD card set up is not practical, especially with rising fuel costs.

    I don't intend to complain continually in this forum or elsewhere after hopefully, finally, settling with what works if that choice creates difficulties I know the LE developers and others cannot do anything about. So I hope I'm not going to, deliberately at least, cause any additional burden that you are seemingly frustrated by and concerned about in the future. No sir. Not me :)

    Quote

    If you have an issue with those images; state the problem.

    Raspberry Pi VNC addon is incompatible with LE11.

    Vaguely, it used `dispmanx IIRC, whereas I'm guessing the video driver changes to Kodi, and / or the change to requiring Python 3 for Add Ons, broke this addon and made fixing it impossible unless there is another VNC solution for the Raspberry Pi that can be ported to LibreELEC.

    Please do not get me wrong. It is fantastic that the Raspberry Pi Fo went down the direction of supporting open source video driver development, Vulkan support, OpenGL, merging into the official Linux kernel and all that other stuff that Phoronix reports on, but I can only glance through and try to ingest. I recall the very early days of that situation (though the project name slips my mind) before Igalia and Mesa and all these other steps have come along.

    However, I've found VNC highly important for remote support of my septogenerian Mum's LE set up. AFAIK some things in Kodi you still can't do via any other means than GUI. Like setting the content type of Library sources. But it's also very logical to have GUI access to aid remote troubleshooting.

    I'm not completely against having an Argon add-on in our repo, but IMHO the better approach would be for Argon to host their own repo so they can maintain the add-on and push updates to their users from a central location.

    Whilst I understand this approach, and admire your 'stewardship' (if you like) of LE as a project that's doubtless delivered pleasure to hundreds of thousands, I wonder if a possibly, arguably, more pragmatic (debatably) approach than what appears to be the Torvalds approach to hardware support, might, just might, be worth considering?

    Now, that paragraph may well be well and truly too 'loaded' with triggers so I do acknowledge that and would like to explain that it's not my intention to create any argy bargy.

    I'm just curious if it might be possible to attempt to integrate a generic fan control mechanism into LE. Why? It's taken decades for the Torvalds approach to hardware support - make the OEMs do it - to get to the current stage of relatively good support. But that's with large OEMs. The sort of OEMs that make smaller, cheaper products for the likes of us poor sods who don't want to / cannot pay for an arguably spyware solution like an nVidia Shield running Android and not even booting straight to Kodi (natively), have proven blithely inept at supporting LE. Yet there's myriad "piece of junk code but works for me [in my non-LE edge case]" attempts to use generic PWM, I2C, non-Python / dependancy-free, ``systemd approaches out there. Seemingly indicating - to my largely ignorant perspective - that a generic approach is within the bounds of possibility. Especially if OEMs can at least dump documentation for controlling their hardware. The alternative, generic approaches just largely seem to flounder, repositories becoming archived, or only come with installation instructions for non-LE scenarios like using APT and so on.

    Might it be possible to at least attempt to galvanise, centralise these efforts into a central LE managed repo to create and modify a generic fan control, perhaps power button control, add on that installs a systemd service and generally makes this whole nightmare a much more high-quality experience that is in concert with the rest of the LE experience?

    Again, I reiterate, I'm feeling mild agitation (actually, tamed rage) towards these OEMs who can so easily, cheaply, seemingly create this hardware (because so much of the world's manufacturing has been killed off and centralised in their home country / language) but I'm trying to turn that feeling into at least expressing an idea that *might* be somewhat relatively productive. I apologise in advance if the agitation I'm feeling is coming through this e motion-less medium as more directed towards anybody or any project other than the OEMs selling their dubious products. Thanks for reading.

    This forum needs a Do Not Buy list.

    Unless you are willing to take risks, tolerate just plain broken hardware and zero or crappy LibreELEC support:

    DO NOT BUY

    1. Argon40 :cursing: :!:
    2. Desktop Pro :cursing: :!:

    :cursing: Hardware daughter boards FAIL

    :!: Support for LibreELEC is a FAIL

    our (forum moderator) experience with it is mostly all-bad. The case [uses a daughter board to expand micro normal HDMI sockets ... and direct those, plus the audio jack to the rear of the case] The standard protocol when we see 'Argon' anywhere in the issue report is "remove the board from the case, [...] all working now?" and in 9/10 situations users refuse to believe it's the case, but when we insist and they finally cave in and remove the board; the problem was the case. Caveat Emptor :)

    DO NOT BUY Argon40

    The case is a piece of shite.

    I bought one having had all these shitty issues with the Desktop Pro but had not seen this analysis. Oh how I wish there was a more obvious advice page where this experience was emblazoned in enormous headline. (bad)news papers have the merit of providing that sort of alarming warning via headline size YELLING at you not to buy shite crap from yet another shite, amateur manufacturer poking together a bunch of bits and then relying on the language barrier to fail to support their silicon.

    Sorry, I now see my question was interpretable as a request. Not my intention. I know the last thing LibreELEC developers need to do is continue to maintain 9.2 ... although you have tweaked it several times :) , hence .8, to the benefit of all end users and for that I thank you most sincerely.

    LibreELEC 10 / Kodi 19.* Matrix seems to be a big step as it is. The RPi4 rev 1.4 is news to me but must be an added head scratching factor, I'm sure!

    Occasionally peek at the commit feeds for the RPi firmware and LibreELEC, noticing the significant work happening consistently and in no way do I want to burden the devs with a 9.2.* branch request, adding to the workload.

    Instead of a request, I was just seeking clarification as my compilation experience, and Linux driver knowledge, is minimal :)


    Thanks for the link! Update: unfortunately it's a broken link. Here's the current link:

    https://wiki.libreelec.tv/development/build-basics

    The dwc2 driver isn't included in LibreELEC [stable, 9.2.8]

    With Kodi Matrix 19.x requiring add-ons are updated to use Python 3, as the LibreELEC blog suggests, many users are expected to stay on the LibreELEC 9 / Kodi 18 Leia releases for some time. Particularly as RPi4 video support is not very mature in Kodi 19 so RPi4 users, at least, might be inclined to stay put.

    Is it possible to add dwc2 driver support to the LibreELEC 9 series? Does it require recompiling the kernel?

    Wow. 5 years later, just found this repo. Looks amazing, but a shipload of effort from one person? Alas ...

    Code
    2021-06-22 23:02:42.444 T:2566869760  NOTICE: Thoradia Add-ons: found release 9.2.0/RPi4/arm
    2021-06-22 23:02:42.444 T:2566869760  NOTICE: Thoradia Add-ons: using release 9.2.0/RPi4/arm
    2021-06-22 23:02:42.449 T:2566869760  NOTICE: Thoradia Add-ons: updated datadir to https://raw.githubusercontent.com/thoradia/thoradia/master/9.2.0/RPi4/arm/
    2021-06-22 23:02:51.640 T:2608833280   ERROR: CRepository: failed read 'TBD'
    2021-06-22 23:02:51.739 T:3010547776 WARNING: CGUIMediaWindow::OnMessage - updating in progress
    2021-06-22 23:02:53.512 T:2566869760   ERROR: GetDirectory - Error getting addons://service.thoradia/
    2021-06-22 23:02:53.545 T:3010547776   ERROR: CGUIMediaWindow::GetDirectory(addons://service.thoradia/) failed

    RPi4 (4GB); LE 9.2.7

    Uncertain whether to add this to the GitHub issues as there's already one for LE10 that I assume is similar if not the same cause. Do not want to hassle anyone unnecessarily.