An update:
As I thought it may have something to do with profile corruption (I always used the same one across upgrades), I created a second one, not importing anything from the Master profile, added just one folder of media indexed using Universal movie scrapper as a data scrapper. Media are stored on an NFS-accessible hard drive. Otherwise it's a stock configuration with no background indexing taking place. The exact same issue reappeared.
The random freeze issue didn't go away in this new profile, and even occurred during idle times, not just trying to update the library. Symptoms are the usual ones: keyboard is still detected and responds to pressing [Caps Lock], cycling the indicator LED on and off, but the GUI stays frozen. Trying to SSH into LE at these times also ends up in a timeout. If I randomly press keys during while GUI has frozen, most often than not LE reboots by itself, sitting on the LE splash screen for what seems to be an abnormally long amount of time.
Third unexpected symptom: when LE hasn't crashed and SSH is still accessible with LE otherwise idling, Kodi still shows quite a bit of CPU / RAM being used constantly: /usr/lib/kodi/kodi.bin --standalone -fs always hovers around 45% CPU, and RAM taken by the same process takes 65% of the available total over about 45 instances.
Since I now have two profiles, I SSHed into LE while it was sitting on the profile selection screen, and interestingly, process /usr/lib/kodi/kodi.bin --standalone -fs isn't peaking above 8% CPU / 11% RAM. Right after login, the same process sits at about 35% CPU and 15% RAM over 29 instances of the process. Are these numbers considered normal?
A movie I watched yesterday kept on freezing video every 6-7 minutes (much like commercial breaks on public channels!) but soundtrack remained unaffected. Another one I attempted playing displayed the "Play" symbol in the upper right corner as if it were in the background, but didn't show any video not played any sound.
To the untrained eye, it seems as if LE11.x still has unsorted, unrelated, random issues, but that could be just my impression.
Knowing how tricky it was (and still is) to get media properly indexed, I avoided doing clean installs whenever possible. Doing a
# tune2fs -l /dev/mmcblk0p2 gives:
tune2fs 1.46.6 (1-Feb-2023)
Filesystem volume name: <none>
Last mounted on: /storage
Filesystem UUID: f9464344-3849-4215-bba3-bd21af023a22
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: unsigned_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 1916928
Block count: 7659520
Reserved block count: 0
Overhead clusters: 164363
Free blocks: 2750018
Free inodes: 1829737
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Reserved GDT blocks: 1024
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Fri Jun 22 07:11:49 2018
Last mount time: Wed Dec 31 19:00:04 1969
Last write time: Wed Dec 31 19:00:04 1969
Mount count: 326
Maximum mount count: -1
Last checked: Fri Jun 22 07:11:49 2018
Check interval: 0 (<none>)
Lifetime writes: 70 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 32
Desired extra isize: 32
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 6e617c07-f8f3-46ed-8b8b-55c4a2abce68
Journal backup: inode blocks
Display More
I thought that LE was supposed to perform an fsck on each boot.
Debug log: http://ix.io/4xq3
Crash log: http://ix.io/4xq4
Any idea what's happening chewitt ?