https://bugs.kde.org/show_bug.cgi?id=420939
--- Comment #50 from Scott <shagooser...@gmail.com> --- The first issue, the pool drive, I use mergerfs: here <https://github.com/trapexit/mergerfs> ver. 2.31. Following your suspicions I deleted the index file, /home/scott/.local/share/baloo/index and changed the config to follow absolute addresses (attached) removing any reference to the drive, pool. This cured the red-flag issue from may last post, baloo now does it's indexing and is only a couple of files shy of the number of files I expect to be indexed. More importantly it no longer duplicates entries, if I disable and then enable balooctl no further indexing occurs, the same is true after re-booting the machine. I performed this 3 times. The new 2nd issue, running balooctl enable for the first time produces a piped balooctl monitor file with 5488 files indexed. Running balooctl status returns 5976 files indexed. So after doing all this testing I find that not one file displays a duration anymore. If I copy any file to my /home/Videos directory the duration is displayed. I have only entered commands which start with baloo...? I have also attached the piped stderr file which may be of some value you. On Sun, Aug 8, 2021 at 4:16 PM <bugzilla_nore...@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=420939 > > --- Comment #49 from tagwer...@innerjoin.org --- > (In reply to Scott from comment #48) > > ... I have now discovered that some > > files are indexed but do not display a duration. The following file > appears > > in the indexed list but there is no duration displayed... > It's "video/mp2t", that's good news. > > Does it give a "Duration" if you look with "MediaInfo"? > > If it does... > > Try copying to your home directory, see if you can index it there and > check the results of "balooshow -x" > > If it doesn't... > > It'd be a question of thinking back to ask "what is different" or "what > did I do differently" with this one. Not going to be easy... > > > 5/ This seems to be your "red flag" > > baloosearch -i "Battle of Jutland the Navys Bloodiest Day 2016".ts > > f3f600000031 /mnt/pool/Entertainment/Documentaries/Movies/Battle of > > Jutland the Navys Bloodiest Day 2016.ts > > f8c500000031 /mnt/pool/Entertainment/Documentaries/Movies/Battle of > > Jutland the Navys Bloodiest Day 2016.ts > > Elapsed: 0.997359 msecs > This looks "complicated"... Maybe bad news for your indexing. > > In each of your examples the "device Id" was 31(hex)/49(decimal). My worry > was > that was changing when you rebooted. > > What is strange is that the (supposed) "Inode" for the file _is_ changing. > It > may be that I've got this wrong, but it looks like it appears as: > > 63685(decimal) > 70217(decimal) > > plus baloo has seen: > > f3f6(hex) - which is 62454(decimal) > f8c5(hex) - which is the 63685(decimal) > > If these ID's are jumping round then baloo doesn't have a chance. > > You are looking at > > /mnt/pool/... > > and have a set of discs mounted behind it? Your original > .config/baloofilerc > mentioned /media/data/disk01, disk02, disk03 and so on... Maybe the "pool" > doesn't keep inodes stable :-/ > > Try finding your "Battle of Jutland the Navys Bloodiest Day 2016".ts on the > mounted discs (rather than on the "pool") and do a stat of it there... > It'd be > something like: > > cd /media/data/disk1/entertainment/Movies > stat "Battle of Jutland the Navys Bloodiest Day 2016".ts > > The hope is that the device number/inode remains stable (and indeed stays > the > same when you reboot) > > -- > You are receiving this mail because: > You reported the bug. -- You are receiving this mail because: You are watching all bug changes.
