If you're going to share a log please share the whole log, else we miss a bunch of stuff that is important. Rinse/repeat with the v12 nightly.
Posts by chewitt
-
-
The resize issue is something we're aware of .. enjoy the Pi
-
The only error I can see in the snippet is the icon.png loading error, and that's effectively harmless. Share a full debug log.
-
/storage/.kodi exists .. the . is not optional
-
The first thing I'd check/change or experiment with is the HDMI cable(s) used. ATMOS and other high-bitrate formats are often combined with 4K/HDR video and the combination requires more data to be transmitted on the cable and this means higher bandwidth "certified" cables are needed. HDMI cables also impact the EDID data carried on the HDMI connection which advertises the audio capabilities to the Pi device. As a secondary thing I'd check for AVR firmware updates. AVR devices do ship with bugs that do get fixed in later updates sometimes.
-
There's two HDD's, one 6 tb and an 8 tb. They are just average drives, so probably plenty fast enough I'd guess.
There can be a huge performance difference between proper NAS drives in a RAID config where you typically use a larger number of smaller drives to achieve capacity and access performance vs. "JBOD" configs with drives optimised for cost/density: often a single huge platter and not the 3-4 platters of a few years ago. Navigating a filesystem with a large number of inodes (files and sub-directories) results in lots of small file read/write access which is often the opposite of the large file read/write "backups" access profile that cheaper drives are designed for, so it's not uncommon for playback (of a single large file) to be no issue but navigation to be slower.
Are you using library views (Movies/TVShows) or the non-Library (Videos) views to browse media? - If using a library, how many sources are used for each media type? - and are you using default sqlite or MariaDB to host the database?
-
It's not an obvious configuration and sadly does catch a few people out. I'm not sure what we could really do to improve though.
-
I'm sorry to intrude, but is this specific to Raspberry or is it for all architectures?
Specific to RPi0/1/2/3 boards. Recent Intel GPU's shouldn't have any problems with H264/HEVC media; AV1 will depend on the chipset.
-
That linked file was already asked about in another thread and it played fine on RPi5.
-
It requires someone to flag that newer updates are available on the back-end and in recent years that manual process is often overlooked due to life/work/etc. You can download it manually in the GUI and update.
-
Have you read https://wiki.libreelec.tv/configuration/4k-hdr ? - the configs discussed should generally help with most media playback.
-
Probably fixed by https://github.com/LibreELEC/LibreELEC.tv/pull/6159 which has gone off the team radar..
-
Have a read of this, the content is applicable to 1080p media as much as other types: https://wiki.libreelec.tv/configuration/4k-hdr
-
Kodi always outputs progressive so you need to enable adjust-refresh and rate doubling, and set the mode whitelist to NOT include 1080p @ 30/29.97/25 modes. Kodi will then switch to 1080@50 with each interlaced half-frame rendered in a single frame. Normal PAL content will be output at 1080@50 too (each frame is rendered twice).
-
Banned add-ons are installed. No support.
-
One of the goals of our codebase is that everything functions the same regardless of the hardware; the notable exceptions being boot/install which are often dictated by hardware type. Stats also show that 80% of our userbase has an RPi board and 10% Intel x86_64 devices so 90% of users should be covered by those general catch-all subforums. In the past (in OpenELEC days) the forum also had more dedicated subsections with the result of each subforum having lower traffic and lower engagement, whereas with only a couple of main sections those forum areas are naturally higher traffic and overall more users enage and contribute to the forum. It's something we've thought about too, but it always ends up with the team being 50:50 for/against .. so it never happened.
-
HEVC files will play but where 1080p was mostly possible under the legacy codebase 720p is probably the maximum now, and for encrypted streams like Netflix where DRM needs to be handled SD will likely be the limit.
-
Code
Display MoreRPi5:~ # ls -l /usr/sbin/*fsck* lrwxrwxrwx 1 root root 8 Oct 21 13:52 /usr/sbin/dosfsck -> fsck.fat -rwxr-xr-x 1 root root 749016 Oct 21 13:54 /usr/sbin/e2fsck -rwxr-xr-x 1 root root 68736 Oct 21 13:53 /usr/sbin/fsck -rwxr-xr-x 1 root root 68800 Oct 21 13:52 /usr/sbin/fsck.exfat lrwxrwxrwx 1 root root 6 Oct 21 13:54 /usr/sbin/fsck.ext2 -> e2fsck lrwxrwxrwx 1 root root 6 Oct 21 13:54 /usr/sbin/fsck.ext3 -> e2fsck lrwxrwxrwx 1 root root 6 Oct 21 13:54 /usr/sbin/fsck.ext4 -> e2fsck -rwxr-xr-x 1 root root 133688 Oct 21 13:52 /usr/sbin/fsck.fat lrwxrwxrwx 1 root root 8 Oct 21 13:52 /usr/sbin/fsck.msdos -> fsck.fat lrwxrwxrwx 1 root root 8 Oct 21 13:52 /usr/sbin/fsck.vfat -> fsck.fat^ LE uses the full e2fsck binary not busybox.
I built a Generic/GBM image here: https://chewitt.libreelec.tv/testing/LibreE…_64-11.80.0.tar which should reinstate mkfs.ntfs and include the ntfsfix tool from ntfsprogs. The image is not tested since I don't have any Intel CPU hardware around these days, but please have a play with the binaries to ensure they compiled okay and to see if ntfsfix can resolve the dirty-filesystem issues you're seeing?
