If the -u switch makes a difference, my first thought is that the problem would be related to your time zone / DST settings. As mglae points out, "For historical reasons hwclock default to local time. Use hwclock -u -r to use stored UTC time correctly." I'm in South Africa (GMT + 2 and no DST) and I never needed the -u switch. YMMV.
Posts by frankvw
-
-
OK. So it looks like your hardware clocks might be the problem. As mglae already noted, the battery of your RTC might be flat. Get a new RTC; it's easier and cheaper than trying to replace the battery (which is soldered in).
Not sure why you get an error from timedatectl; on my RPI3 and 4 it both works fine.
-
I live in Italy so GMT +1
CodeLibreELEC:~ # hwclock -r Fri Sep 6 18:44:09 2024 0.000000 seconds LibreELEC:~ # date Fri Sep 6 20:44:14 CEST 2024I'm seeing one problem here right away. You're at GMT+1 but the difference between the hardware clock and the on-board clock is two hours, not one. So there's something wrong with you time settings. Daylight Savings Time seems the most likely candidate, but no DST is showing up in the output of the date command. So first let's found out more about that.
As soon as you note that the on-screen clock is out of sync, note the time it shows and post it here. Then use the timedatectl command and post the output here. In my case the output is:
CodeLocal time: Sat 2024-09-07 09:49:48 SAST Universal time: Sat 2024-09-07 07:49:48 UTC RTC time: Sat 2024-09-07 07:49:49 Time zone: Africa/Johannesburg (SAST, +0200) System clock synchronized: yes systemd-timesyncd.service active: yes RTC in local TZ: noI'm beginning to suspect that the problem might lie with the on-board clock on your RPi which for some reason appears to get out of sync, but at this point I don't have the details so this is more speculation than anything else. So once you note the time on the screen is off please provide the above details so we can home in on the cause of the problem.
// FvW
-
For historical reasons hwclock default to local time. Use hwclock -u -r to use stored UTC time correctly.
Eh? On my RPi3 with LE9 (soon to be replaced by an RPi4 with LE12) the output of hwclock -r comes back with UTC time, not local time (as per the output in my above post.) So why is that?
// FvW
-
I've followed this guide to install a rtc in my raspberry pi with Libreeec, but it seems not to work properly. After the reboot without connection, the on screen clock is wrong, probably is showing the yesterday time but if I use hwclock -r the time is perfect.
Use the date command to verify that the hardware clock updates the system clock. E.g. on my RPi:
CodeLibreELEC:~ # hwclock -r Fri Sep 6 05:03:48 2024 0.000000 seconds LibreELEC:~ # date Fri Sep 6 07:03:50 SAST 2024As you can see the two show the same time. The output of hwclock shows GMT while the output of date shows my local time (.I'm on South African Standard Time a.k.a. SAST which is GMT + 2 hours.)
If this isn't the case on our system that means the hardware clock doesn't update the system clock correctly and we can look into why that is. If it is correct, there's something else wrong and we'll take it from there. So please post the output of the above commands on your system and let us know in what timezone you live, then we'll know more about what might be goin on.// FvW
-
frankvw Make sure your HDMI cables are conform to HDMI 2.0 / 2.1 (4K ready). Those cables have better shielding.
Would insufficient shielding make a cable work perfectly on the RP3 but give me no signal at all (TV and monitor just switch off) on the RPi4? Don't get me wrong, I'm not saying it's not possible but I fail to understand how that would work.
-
Now that you mention it, I've had a weird HDMI cable issue with my new RPi4 as well. I've got a short micro HDMI to HDM cable (75cm or so) which works fine. I've also got a regular one metre HDMI to HDMI cable, and a HDMI coupler (2 HDMI sockets). When I use the HDMI cable and the coupler to extend the short micro HDMI to HDMI cable, I have no picture on my HDMI computer monitor or on my TV. Using the same thing to extend the regular HDMI cable on my old RP3 works fine
So it looks like some cables don't play nice with the RPi4 micro HDMI ports. Not sure what the issue is but it's definitely there. However it's not related to LE; when I power up the RPi4 I don't even see the "rainbow" screen so it's a hardware issue between my RPi4, cables and displays.
-
libx265 is only available for X86_64.
I hadn't understood that from the relevant ffmpeg docs. I do realize that the SoC in the RPi4 will never be able to do it in hardware, but from what I see a software solution for H.256 encoding should be possible, in fact some efforts in that direction seem to have been underway for a a while (e.g. here and here) albeit not with stellar results so far.
Oh well. Thanks for clearing that up!// FvW
-
I am not sure what else I can provide here, but, if anybody who can help needs more information, please ask.
Did you do an in-place upgrade or a clean install? I've always had the best results with the latter. It's more work but for me trying an in-place upgrade ultimately became more of a hassle somehow. Get a separate SD card, do a clean install, add your favorite add-ons and port your media an database.
If you want to migrate your database to another installation of LibreElec with the same major version number, the following procedure will keep your whole library and sources intact:- Log in via ssh
- Copy .kodi/userdata/Thumbnails/*
- Copy .kodi//userdataDatabase/MyVideosxx.db(where xx is the highest number if there's more than one version)
- Copy .kodi/userdata/Dagabase/Texturesxx.db (xx is the highest number, as above)
- .kodi/userdata/sources.xml
- Install the new LibreElec
- Run "systemctl stop kodi"
- Restore the above files to their original locations
- Run "systemctl start kodi".
This has worked for me!
-
In a bout of recklessness I decided to try how well my RPi4 can handle video compression. I've got a lot of stuff that can be significantly reduced in size (let's face it, a cartoon like The Simpsons doesn't really need to be full HD 1080p video) and HEVC is much better than H264 when it comes to video file size reduction. I know the RPi is not exactly a MIPS-monster, but ffmpeg runs most threads with a relatively low priority and the RPi is sitting idle during the night in any case, so who cares if it takes hours per file in the background? So I installed the ffmpeg tools and cranked up ffmpeg. Error:
Unknown encoder 'libx265'
Okay - so this lib is not installed along with the rest of the stuff in the ffmpeg tools add-on. Which is not unreasonable. Yet HEVC compression runs surprisingly well on my old laptop (which has no GPU and is not a top-of-the-line model) so it still might work better on the RPi than one might guess and I'd like to give it a try.
Is there a way for me to add it manually?// FvW
-
Clearing the binaries and reinstalling the add-ons did the trick. I was expecting to have to reconfigure everything from scratch, but fortunatley not. Thanks for that!!
-
I just upgraded from the latest stable LE11 to LE12.0.0 on my RPI4. I now have two problems.
1. Several add-ons no longer work. For example, the Shadertoy screensaver complains that:
2024-05-24 14:38:37.335 T:1435 error <general>: Unable to load /storage/.kodi/addons/screensaver.shadertoy/screensaver.shadertoy.so.20.2.0, reason: /storage/.kodi/addons/screensaver.shadertoy/screensaver.shadertoy.so.20.2.0: wrong ELF class: ELFCLASS32
I suspect this has to do with the fact that "64-bit capable ARM SoC devices including Raspberry Pi 4/5 have been switched from ‘arm’ to ‘aarch64’ userspace" as per the announcement. Is that correct? Does that mean I must now reinstall all my add-ons from scratch? (Say it ain't so...)
2. This seems more of a Kodi issue than an LE one, but let me blunder ahead anyway: updates of add-ons fail because Kodi doesn't seem to be able to find its way through the repo anymore. For example:
2024-05-24 14:43:27.909 T:2362 error <general>: Requested path https://mirrors.kodi.tv/addons/nexus/script.xbmcbackup/script.xbmcbackup-1.7.0.zip not found in known repository directories
However, using wget on the same RPi (this time form the command line, obviously) works fine and the file is found and downloadable:
LibreELEC:~/download # wget https://mirrors.kodi.tv/addons/nexus/script.xbmcbackup/script.xbmcbackup-1.7.0.zip
Connecting to mirrors.kodi.tv (23.19.87.248:443)
Connecting to www.mirrorservice.org (212.219.56.184:443)
saving to 'script.xbmcbackup-1.7.0.zip'
script.xbmcbackup-1. 100% |*****************************************************************************************************************************| 826k 0:00:00 ETA
'script.xbmcbackup-1.7.0.zip' savedWhat's going on here?
// FvW
-
I'm running LE11.06 on an RPI4.
Given all the recent WiFi problems with LE10/11 on the Raspberry Pi (discussion here) I would like to try using an external WiFi dongle. Going through the junkbox I came across an Alpha Networks AWUS036AC (e.g. here). This is a dual-antenna long range model which, given that the "invalid key" problem is definitely related to lower signal strengths, might help. This dongle uses a Realtek RTL8812AU which I believe should be supported right out of the box. (Correct me if I'm wrong.)
But how do I persuade LE to use this USB dongle rather than RPi's build-in WiFi adaptor?
// FvW
-
Hi and thanks for an interesting thread : I had a power outage yesterday, and now 2/3 disks don't want to start. Have run them in Win10 without problems after chkdsk. Today I have LE 11.0.4 generic on a PC which worked flawlessly. Any ideas? Mvh Thore from Sweden
Until ntfsfix is included again with LE using a Windoze box to clear the 'dirty' bit on the NTFS partitions is your only option, I'm afraid.
I'm surprised at the attention this issue attracted. I for one vote to use the ext4 system for all things LE and be done with it.
As I said above, people want to use LE because it's easy, convenient and does not require any computer skills beyond the ability to follow step-by-step instructions on how to copy a distro image to an SD card or USB stick. They are, however, stuck with USB storage devices that come out of the box with NTFS on it, and they just expect that to work.
Which, from a UX point of view, is not all that an unreasonable standpoint.
At this point in time any power failure or accidental unplugging of an NTFS based storage device will stop it from working, and LE has no option to fix that. You need a Linux box with ntfsfix on it just to get the partition to mount again, and a Windoze box to fix any real NTFS problems.
Keep in mind that, to all intents and purposes, all USB storage devices come out of the box with NTFS on it.
So as far as user experience goes, shaky NTFS support is not a good thing. Add to that the fact that this could be easily fixed to some degree (including ntfsfix again and having it triggered by a udev rule when an NTFS device is plugged in and I agree with you: we shouldn't still be just discussing this.
For those with an IT background the choice between NTFS and ext4 is a no-brainer. And I have reformatted my NTFS media tank to ext4 and now all is well. But for every person who knows what ext4 is, why NTFS should be avoided in a *ix environment and how to replace NTFS with ext4, there is a gazillion "normal" people out there who just buy a device, plug it in, an expect it to work. They reason that since it does work "everywhere else" (i.e. on every Windoze box) why won't it on LE? It's not an unreasonable question, in all fairness.
If we want to reserve LE for the IT-savvy elite then yes, let's ignore NTFS and consider its shortcomings the punisment for using it. But unless I'm very much mistaken, that's not what LE is all about, is it? -
It still comes down to education. People shouldn't be uncleanly shutting down any device. Put LE on a ups to survive power outages and properly use the shutdown menu to power LE off. No more problem.
You do have a point. Removing all the safeties from all equipment, removing insulation from live wires, removing the brake lights from cars, etc. will educate everyone very, very quickly and teach them not to do anything stupid with equipment that have could potential unwanted effects. But is that really the way to go?
Let's face reality here: people are going to install LE because of its combination of simplicity and rich features, then plug any off-the-shelf USB storage device in it and expect it to work. And those things will be dismounted uncleanly sooner or later, because accidents happen. If LE then can no longer use the device their UX is impacted and they'll blame LE for not doing what they can do with their average Windoze or Linux box every single day.If that can be remedied fairly simply (and it can as per the above discussion) I believe that's worth doing. But that's just me.
-
Remember the critique, lies, damn lies and statistics. Why do so many people here want to use LE I wonder 😂
That's the point. They do want to use LE because it's easy, convenient and does not require any computer skills beyond the ability to follow step-by-step instructions on how to copy a distro image to an SD card or USB stick. They are, however, stuck with USB storage devices that come out of the box with NTFS on it, and they just expect that to work.
As one of Debian's Elder Geeks put it (about 25 years ago now): "If the user points the gun at his foot and pulls the trigger, it is our job to ensure the bullet gets where it's supposed to." It's much the same here: people install LE for its simplicity of use, then they plug in a USB storage device that comes right out of the box, and they aren't even aware that it comes with NTFS on it and the problems associated therewith, much less are they interested in converting it to ext4. They plug and expect play.
Now I'll grant you that there are limits to catering to all aspects of that expectation, but in this case LE's finicky response to uncleanly dismounted NTFS devices and a lack of a means to fix it within LE is serious enough for the uneducated user to consider LE broken in this regard. You and I understand what's going on, but from a UX standpoint (I'm trying to avoid using "the great unwashed masses" as a descriptive term here) this is a problem.
Which in my opinion can be fixed fairly easily by restoring ntfsfix to the next LE distro image and (as I would prefer) hooking it into a udev rule that automatically runs it on any NTFS partition at mount time.
Perhaps testdisk could also be added to the next image for cases in which ntfsfix is insufficient. I see that tools like udevadm (which are not exactly intended for Joe & Jane Average User) is there, so why not testdisk? It'll get used more often than the udev tools, would be my guess. -
Or else keep NTFS systems away from the Linux party. It really is a matter of re education for Windows users. With shares and other network solutions does anyone really need to be using an NTFS disc on LE anyone. And for those who do, with storage being so cheap these days a simple copy over of the contents of the NTFS disk to EXT4 would suffice before hooking up to the LE machine. Honestly what can’t be done in Linux that can be done in Windows. I prefer spending my time “consuming” my media instead of watching LE consuming my NTFS file system 😂
I'm with you on that. In fact, when I come into power and become Ruler of All the World, the first thing I'll do is to banish Windows and NTFS from the face of the earth and make Linux skills a compulsory part of general education, and the Redmond crowd will be among the first against the wall. However, until that happy day comes around, we need to face the reality that just about every USB device sold comes with NTFS on it, and John & Jane Consumer have no idea what ext4 is, much less how to convert their newly bought USB harddisk to it. They simply plug it in and expect it to work. And most of the time it does. Except with LE, right now. And that's not a Good Thing. But it can be fixed, as per the above discussion, and it's not all that complicated. So my vote is to leave the Windows vs. Linux (and related technologies) holy War for what it is, face facts, and deal with it.
I'm currently looking into a different approach: let users choose to mount NTFS partitions read-only https://github.com/LibreELEC/LibreELEC.tv/pull/8308 - this would hopefully solve the issue of easy corruption in case of unclean shutdowns.
so long,
Hias
If that works, I could live with it. However,it wouldn't let anyone add media through SMB or sftp, and it would break add-ons like Transmission, though. Not a big issue for me but it might be for many others. However, compromises being what they are it's better than the current unreliability of NTFS devices.
-
Don't get too excited about ntfsfix, I did a quick test on a corrupted NTFS filesystem, removing the dirty bit, and as expected it didn't help with the errors and the ntfsdriver set the dirty bit again after mounting it because the filesystem had issues.
You're right: ntfsfix is severly limited. It always has been. In fact, the manpage specifically states that "ntfsfix is NOT a Linux version of chkdsk. It only repairs some fundamental NTFS inconsistencies, resets the NTFS journal file and schedules an NTFS consistency check for the first boot into Windows."
However, the issue under discussion here is that a simple unclean dismount (i.e. pulling the plug on an USB device without first dismounting it cleanly, having a power failure or other crash, or simply moving a cable with a dodgy plug or connector) will leave the "dirty bit" set on the NTFS partition regardless of whether or not anything has been corrupted. LE then refuses to remount it, ever.
As of LE11.0.3 there's no ntfsfix at all included to reset the dirty bit. That means that as soon as you have even the slightest hiccup with and NTFS disk on LE, you need to plug the HD into either a Linux box that has ntfsfix on it, or into a Windows box and run Chkdsk. That's a bit hard to live with, and simply restoring ntfsfix to LE will go a long way to fixing that problem.
If you have real NTFS corruption problems, no amount of ntfsfix will help you and only running Chkdsk on a Windows box will sort it out. But that's a Linux issue, not an LE issue. NTFS support for Linux has never been great (although these days it's sufficient for all regular purposes) but the lack of a proper Chkdsk alternative that can repair a corrupted NTFS has been a problem since NTFS support was first introduced in Linux.
As petediscrete already suggested above, testdisk may be a better alternative for ntfsfix. However, for daily LE use ntfsfix will be sufficient in most cases and infinitely better than nothing at all (which LE11.0.3 currently has).
