I gave it a try again... and it slowed down Dolphin intensely. here is some output: kf.baloo: Failed to add exclude folder config entry for "/home/user" kf.coreaddons: "Could not load plugin from /usr/lib64/qt5/plugins/ffmpegthumbs.so: Failed to extract plugin meta data from '/usr/lib64/qt5/plugins/ffmpegthumbs.so'" kf.baloo: Failed to add exclude folder config entry for "/home/user" Specified App: kf5-baloo-libs-5.108.0-1.fc38.x86_64 baloo-widgets-23.04.3-2.fc38.x86_64 kf5-baloo-5.108.0-1.fc38.x86_64 kf5-baloo-file-5.108.0-1.fc38.x86_64 --- Software --- OS: Fedora Linux 38.20230814.0 (Kinoite) KDE Plasma: 5.27.6 KDE Frameworks: 5.108.0 Qt: 5.15.10 Kernel: 6.4.10-200.fc38.x86_64 Compositor: wayland --- Hardware --- CPU: AMD Ryzen 5 PRO 3500U w/ Radeon Vega Mobile Gfx RAM: 13.5 GB GPU: AMD Radeon Vega 8 Graphics Video memory: 2048MB
after disabling it and rebooting the system is snappy again. All apps were laggy and sometimes even crashing, this was completely crazy
https://discussion.fedoraproject.org/t/baloo-exclude-certain-directories-by-default/116813/1
(In reply to Henning from comment #1) > ... All apps were laggy and sometimes even crashing, this was completely crazy ... To me that sounds like Baloo not running within its memory limits. It should be constrained by systemd to the 512MB set in the unit file. See what: systemctl --user status kde-baloo reports, in particular the "Memory:" line. The 512MB is pretty strict and may force Baloo to swap (something else you don't want it to do) but it should stop Baloo taking memory at the expense of the rest of the system. You probably don't want Baloo to index the whole drive, from "/" downwards, normal configuations are to index your home and exclude hidden files/folders. If you want to include hidden files/folders then exclude .cache, .local/share/Trash (and .mozilla if you have it). This is from experience on a vanilla platform, I'm not sure what differences you might see with Kinoite.
(In reply to tagwerk19 from comment #3) > ... I'm not sure what differences you might see with Kinoite ... With a quick look, Kinoite seems to be too alien :-/ There's a symlink from /home to /var/home, you see yourself in /var/home/username but $HOME refers to /home/username. That's going to confuse Baloo...
doesnt baloo work reliably with links? Would this mean Fedora needs to build a variant that replaces that link? Atomic Fedora uses a ton of linking, as the one you mention.
(In reply to Henning from comment #5) > ... doesn't baloo work reliably with links? ... The answer is somewhere between "probably not" and "I'm not sure in this case"... Baloo is built on the assumption that it can set up a one-to-one link between the filename and an internal "DocId", where the DocId is in part derived from the inode. It wants to be able to go from the filename to the DocId, then back again and get the same filename. Symlinks can mess with this assumption Baloo can work if given a symlinked folder to index but it should not meet the files via "another route" - so it should not index the files under their canonical names (or when following another symlink!). "Can work" may be a bit optimistic, it worked for me but I got a firm "don't do that" when I previously suggested this as an option. You can see that it stumbles in the trivial case here, when told to exclude $HOME and include $HOME/Documents (etc), these are Fedora defaults. Maybe this is something that can be patched, however there's an expectation that symlinks can hide "real filenames", they are not really the right tool for that... (Note that Baloo also does not "follow" symlinks when it is indexing, so if you have a separate mount and a symlink to it from your $HOME, Baloo won't index it. This is more a surprise and annoyance question rather than a reliability one though)