The sample file isn't long enough to show the problem, but a Kodi debug log will be more informative.
Posts by chewitt
-
-
You can drop the .tar files in /storage/.update but Kodi does not support downgrades so after downloading the .tar file to the board you need to manually stop Kodi and rename /storage/.kodi to /storage/.kodi22 before rebooting to start the update. On restart after the update this will give you a clean K21 instance to (re)configure.
Note that I don't keep archives of my older K21 images and I bumped to K22 more than a year ago, so the only K21 images around are the official releases which allegedly have a boot bug on C2 boards. It will start u-boot then fail to boot into the kernel, but this only visisble with a UART cable connected.
Also note that earlier K22 images in my share solved the boot bug with a workaround in u-boot, and the latest images solve it with a kernel fix submitted upstream (that should do the same thing). I'm not sure if the board will boot with u-boot from the latest image and kernel from the older one. You'll have to try it and see.
-
If anyone needs an RPi5 image that includes that patch, I pushed one here:
https://chewitt.libreelec.tv/testing/LibreELEC-RPi5.aarch64-12.80.0.img.gz
(sorry, haven't used Generic x86_64 for years now)
-
-
I don't ever test CEC as I have too many devices connected and it causes issues, so I disable it in my AVR, but grab a spare SD card and see what happens with https://chewitt.libreelec.tv/testing/LibreE…droid-c2.img.gz which should be using Linux 6.14.0 and libCEC 7.0 which may (or may not) improve things?
-
-
PCI-Express devices are in progress, we don't have them on the market yet but they will be available within the next 2 months I would say (according to the current status). Contracts with chip suppliers are signed, samples are in our office. The PCI-Express datatransfer already works, we are working on the frontend (receiver part at the moment).
There is a definite need for 'supported' products in this space so this is nice to hear

-
Log is attached. positive-deer.log.txt.zip
Why!??? .. all you had to do was share the URL the paste function generated (https://paste.libreelec.tv/positive-deer.log) which shows the filesystem on the USB drive was force-checked:
Code
Display MoreApr 06 07:30:54.103762 LibreELEC kernel: scsi 4:0:0:0: Direct-Access USB SanDisk 3.2Gen1 1.00 PQ: 0 ANSI: 6 Apr 06 07:30:54.103925 LibreELEC kernel: sd 4:0:0:0: [sda] 60125184 512-byte logical blocks: (30.8 GB/28.7 GiB) Apr 06 07:30:54.104039 LibreELEC kernel: sd 4:0:0:0: [sda] Write Protect is off Apr 06 07:30:54.104150 LibreELEC kernel: sd 4:0:0:0: [sda] Mode Sense: 43 00 00 00 Apr 06 07:30:54.104263 LibreELEC kernel: sd 4:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA Apr 06 07:30:54.104272 LibreELEC kernel: sda: sda1 sda2 Apr 06 07:30:54.104382 LibreELEC kernel: sd 4:0:0:0: [sda] Attached SCSI removable disk Apr 06 07:30:54.104393 LibreELEC fsck: fsck.fat 4.2 (2021-01-31) Apr 06 07:30:54.104405 LibreELEC fsck: /dev/sda1: 18 files, 44522/65501 clusters Apr 06 07:30:54.104413 LibreELEC fsck: STORAGE contains a file system with errors, check forced. Apr 06 07:30:54.104421 LibreELEC fsck: STORAGE: 36620/1847776 files (0.7% non-contiguous), 2185938/7383547 blocksbut even with fsck there's loads of this:
CodeApr 06 07:30:55.157302 LibreELEC kernel: sd 4:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=DRIVER_OK cmd_age=0s Apr 06 07:30:55.157923 LibreELEC kernel: sd 4:0:0:0: [sda] tag#0 Sense Key : 0x3 [current] Apr 06 07:30:55.158357 LibreELEC kernel: sd 4:0:0:0: [sda] tag#0 ASC=0x11 ASCQ=0x0 Apr 06 07:30:55.158758 LibreELEC kernel: sd 4:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 02 11 42 88 00 00 08 00 Apr 06 07:30:55.159165 LibreELEC kernel: critical medium error, dev sda, sector 34685576 op 0x0:(READ) flags 0x3000 phys_seg 1 prio class 2 Apr 06 07:30:55.159217 LibreELEC kernel: EXT4-fs error (device sda2): __ext4_find_entry:1683: inode #1051944: comm mount-swap: reading directory lblock 0And then:
CodeApr 06 07:31:07.955704 kodiLounge kernel: EXT4-fs error (device sda2): __ext4_find_entry:1683: inode #1052028: comm kodi.bin: reading directory lblock 0 Apr 06 07:31:08.000646 kodiLounge kernel: EXT4-fs error (device sda2): __ext4_find_entry:1694: inode #1052028: comm kodi.bin: checksumming directory block 0 Apr 06 07:31:10.457599 kodiLounge kernel: EXT4-fs error (device sda2): htree_dirblock_to_tree:1083: inode #1052028: comm kodi.bin: Directory block failed checksum Apr 06 07:31:13.098569 kodiLounge kernel: EXT4-fs error (device sda2): __ext4_find_entry:1694: inode #1052028: comm kodi.bin: checksumming directory block 0 Apr 06 07:31:13.191377 kodiLounge kernel: EXT4-fs error (device sda2): __ext4_find_entry:1694: inode #1052028: comm kodi.bin: checksumming directory block 0 Apr 06 07:31:13.260223 kodiLounge kernel: EXT4-fs error (device sda2): __ext4_find_entry:1694: inode #1052028: comm kodi.bin: checksumming directory block 0 Apr 06 07:31:13.308411 kodiLounge kernel: EXT4-fs error (device sda2): htree_dirblock_to_tree:1083: inode #1052028: comm kodi.bin: Directory block failed checksum Apr 06 07:31:13.355379 kodiLounge kernel: EXT4-fs error (device sda2): __ext4_find_entry:1694: inode #1052028: comm kodi.bin: checksumming directory block 0So the USB drive is bad (critical medium error) and this impacts data read from /dev/sda2 which is mounted as /storage. I think it is unlikely that the power outage caused the issue. It's more likely the drive went bad all on its own, but the outage results in unclean shutdown of the filesystem so the filesystem is in a 'dirty' state causing fsck to be run on boot, and this then finds or runs into the underlying media problem. On a memory device medium errors are failed cells in the flash memory chip that's inside.
I wouldn't waste time attempting to repair the USB drive as once cells start to fail the only outcome is more cells failing. If it's still possible (not guaranteed) you can backup the essential Kodi userdata like sources.xml, passwords.xml, DB files, and add-on settings files somewhere. Then make a clean install on a replacement USB drive, stop Kodi, and copy the userdata bits back.
-
Please provide a full debug log.How to post a log (wiki)1. Enable debugging in Settings>System Settings>Logging2. Restart Kodi3. Replicate the problem4. Generate a log URL (do not post/upload logs to the forum)
use "Settings > LibreELEC > System > Paste system logs" or run "pastekodi" over SSH, then post the URL link -
will this be in LE 12 repo chewitt ?
No because https://github.com/LibreELEC/LibreELEC.tv/pull/9663 remains unmerged (overlooked). Once the correction is pushed to master and the LE12 PR is updated to match I'll merge the PR so the add-on populates to the LE12 repo.
-
From what I can see with View Mode and Zoom:
Starting from "Normal" mode if you enable "Zoom" mode it starts with "Zoom amount = 1.0" and when you make any change to the amount value the selected mode automatically changes to "Custom" mode. I've zoomed a 4:3/SD letterbox video so the sides are closer to the edge of my 16:9 screen resulting in "Zoom amount = 1.15" and if you toggle between "Normal" and "Custom" modes the zoom value is persistently applied.
However, if I now switch back to "Zoom" the display switches to a mode similar to "Wide zoom" and not the current "Custom" value that I defined. This probably makes sense in the context of not wanting to automatically revert to "Zoom amount = 1.0" when going back to "Zoom" as this would presumably change the "Custom" value automatically too. However, if I now move to change "Zoom amount" the wide zoom mode is shown until the amount value is adjusted; only then the screen switches to the "Custom" amount value. I also note that if I adjust "Zoom amount" back to 1.0 the mode auto-switches back to "Normal" mode again.
This is probably old code and "not a bug" since "code is working as designed" but the design could use improvement. Unless there is some use-case I'm not understanding I think it would be more logical to simply have "Zoom" respect the current "Zoom amount" value defined and eliminate "Custom" mode.
As this is nothing specific to LibreELEC I'd suggest you report this to Kodi developers via their forum or GitHub issues.
-
Running "getedid create" to capture the EDID data to file will achieve nothing on a system that cannot see the EDID data on the HDMI connection in the first place. You capture <null> to file and force the system to see <null> on every boot.
It's unclear what the issue here is, but given the general lack of user reports about RPi4 boards not seeing EDID, it's unlikely to be a software issue and more likely to be hardware or something specific to this user. Note that RPiOS and LE essentially share the same boot firmware and kernel.
-
Custom nodes create a new entry point into the Library (using a filter on e.g. source name) but this doesn't change how library views are created from scraped metadata. Kodi has default scrapers for online metadata sources like themoviedb.com, and local sources that provide metadata using a mymoviename.nfo file in the same folder as the mymoviename.mp4 media file.
See: https://kodi.wiki/view/NFO_files for more .nfo info.
NB: If creating .nfo files for all your private movies is a chore, it might be easier to use the "Videos" view instead. This is not library based and allows you to simply browse a filesystem folder tree. Not as fancy, but zero effort.
-
As You Can see HDMI0 and HDMI1 is available.
The image shows "EDID=none" and whatever causes no EDID to be read is the source of your problem as Kodi determines HDMI audio capabilities using EDID data from the HDMI connection at startup. No EDID = No audio.
The config.txt and distroconfig.txt files are full of changes from known-working defaults; although most are #commented out and are legacy items which are no longer supported, there are also other items present which will change behaviour.
In short, this is not the clean install that you were asked to make (it looks like an upgrade from an older LE9 install) and there is so much config mess from you guessing at things that it's not clear what change(s) might be involved. Please go make a true clean install. Unless there is a self-inflicted problem with bad cables or HDMI adaptors (or an Argon case) it should then "just work" like a normal RPi4 install.
-
https://github.com/xbmc/xbmc/pull/26606 submitted .. if it passes build (it should) I'll merge it tomorrow.
-
https://github.com/xbmc/xbmc/pull/25700 <= seems to be this issue, which is fixed for K22, but wasn't backported to K21.
The quick fix is to update to a current LE13 nightly image which uses K22. The longer fix is waiting for someone to see if the patch backports onto K21 and then either submit a backport upstream (and then bumping the Kodi version in our LE12 branch) or we can backport the patch direct. I'm not sure there's any plan for another K21 maintenance release. I've been using K22 images for the last year and despite technically being pre-alpha code they've been stable, so I'd probably pick the quick option.
-
Please provide a full debug log.How to post a log (wiki)1. Enable debugging in Settings>System Settings>Logging2. Restart Kodi3. Replicate the problem4. Generate a log URL (do not post/upload logs to the forum)
use "Settings > LibreELEC > System > Paste system logs" or run "pastekodi" over SSH, then post the URL link -
I tried a 640 stream and still got the blur for most of the screen (about two third, interestingly the top third works quite well, and below that it blurs).
Please pastebin a Kodi debug log that shows this stream being played.