Getting Kodi / LibreELEC to work smoothly on a Raspberry Pi 4

1st Official Post

    My Hardware setup: Raspberry Pi 4 (w/4Gb memory), 32Gb SDcard, USB3 500 Gb SSD -

    The idea of using a USB drive is so that should I desire to change the content, I power down the Raspberry Pi, move the SSD to my desktop, make the desired changes of content, plug in the SSD to the Raspberry Pi and then power up the system. Kodi recognizes the change in content accordingly.

    Problems: First problem - Way too much buffering while accessing the 500 Gb SSD. Press Enter to start the play of media located on the SSD and Kodi would sit spinning its wheels for upwards of a minute. Second problem - I was not able to invoke the various ViewTypes for content existing on the SSD ( Wall vs Slide vs List )

    Solution: First) reformat the USB SSD from  ExFAT FS to  FAT32 (VFAT) FS. Second) assign a new label to the SSD (11 characters or less)

    Discussion: LibreELEC (and other Linux distributions) do not handle ExFAT FS format efficiently. The older FAT32 (VFAT) format works much smoother. And a 500 GB USB drive can be formatted as FAT32.

    For some reason (unknown to me), Kodi fails to allow the various ViewTypes on outboard media if the USB media lacks a volume label. This problem goes away once a volume label has been assigned.

    • Official Post

    Why not use Linux's default EXT4 disk format on the SSD?

    Normally any disk format should be okay, so I'm thinking more on what the video file format is when there is buffering.

    Enable debugging, restart Kodi, and provide the log file after reproducing the error(s).

    • Official Post

    LE currently implements exFAT via FUSE which runs in userspace and so is rather slow. In the near-term future LE10 will probably bump to newer kernels which now have the new/official Microsoft exFAT driver implemented (Linux 5.7 IIRC) so the driver runs in-kernel and should be an order of magnitude faster to use; performance should be on-par with other in-kernel drivers like the VFAT drivers we use for FAT16/FAT32.

    I understand about using EXT4 format. I deliberately chose FAT32 for a Linux reason.

    A SSD should be mounted with the 'noatime' option at the time of mounting. Setting the option to 'noatime' extends the life of the drive. By default, LibreELEC mounts the SSD with the "relatime" option for ExFAT and EXT4 formats. To make matters worse, the /etc/fstab is read only. So there is no way to add an entry to /etc/fstab to specify the mounting options. A FAT32 format sidesteps the issue.

    Furthermore, with the FAT32 format, the buffering has been reduced - 1 to 10 seconds range, which is acceptable to me.

    A thank you to chewitt for the technical explanation

    Edited once, last by tkocou (May 11, 2020 at 4:03 PM).

    • Official Post

    We don't use /etc/fstab which is why it's blank and you cannot edit or override the file. It only exists because some other Linux plumbing looks for it and craps out when it doesn't (even if the file is blank). We use udevil for mounting and it's possible to override our default udev rules if you want to (use a file with the same name in /storage/udev.rules.d). I guess when all the upstream sources adopt noatime we'll acquire the same change. Until then, we'll stick to the accepted defaults.

    Quote from chewitt

    We don't use /etc/fstab which is why it's blank and you cannot edit or override the file. It only exists because some other Linux plumbing looks for it and craps out when it doesn't (even if the file is blank). We use udevil for mounting and it's possible to override our default udev rules if you want to (use a file with the same name in /storage/udev.rules.d). I guess when all the upstream sources adopt noatime we'll acquire the same change. Until then, we'll stick to the accepted defaults.

    I accept the reason for the /etc/fstab situation. My only concern is the lack of a tutorial on how to create a proper udev rule for udevil. While there is online documentation, the documentation is somewhat obscure and I have not found any concrete examples.

    Quote from BeauSlim

    Defaults may have changed and it has been a while, but in the past I have seen some improvement in local content stuttering by forcing buffer mode to 1 as per the kodi wiki.

    Thank you for the tip. As expected for a default value, the buffer mode was set to 2 (Streaming only). So I will try the suggested mode and see if the studdering diminishes.

    • Official Post
    Quote from redboy

    why do they use FA16 instead of ext4 or some other native linux system for the system?

    because some users will need to tweak/edit boot config files (e.g. config.txt on Raspberry Pi boards) and users need to mount the first partition of the USB/SD media on their desktop OS .. and Windows/macOS cannot mount native Linux filesystems like EXT4. Using FAT16 allows editing anywhere and causes no harm or loss of performance.