Messages

Quentin,
first, let me tell you that you are amazing. In ten years of linux and open source, I've never seen a developer so committed to his work and his users. Thanks for your great work.

Now to the technical details. I don't think the drawbacks you point out are really relevant, and in fact working around them in an efficient way doesn't seem to be easy. I'm only curious about #3 (which could be particularly interesting for collections on removable media - nowadays I don't know almost anybody with a static mountpoint for a removable drive): why making it fstab only? Is there any particular reason for not relying on mtab only? Which, by the way, could simplify a lot of the work when inotify support is live.

About #2, I don't think 20s is a lot. You already have to scan the whole tree for songs at least once, which takes a lot more than this, and it could be done at the same time. But then again, I don't know if the network overhead is relevant here.

When a directory contains a mountpoint, as you say, it should be (internally) broken down to two different library entries. Making the search for songs non-fs-crossing (can be done easily with unix find, I don't know if perl supports it) should help keeping the code simple.

The only thing that is really needed to avoid a mess in the code is the database splitting. Damn, if I was comfortable enough with perl I'd give it a try.

It's true that a program cannot know if a file is deleted or its partition is simply unmounted, if it happens when it's not running. However, if we take fstab's contents as 'trusted', the workflow seems to be pretty straightforward:

1. gmb is started
2. check the directories listed in the library and understand if they are on a mounted media*
3. compare the directory list with the mounted filesystems list
4. apply the necessary filters

There are some points to take in consideration if things are done this way. First of all, there's no removable media support unless statically defined. This could be addressed with a "manual" addition of a removable media to the library, based on the ID of the drive.

Then, it has to be kept in mind that the approach as described here should work fine for most layouts, but there are some edge cases that are not covered. For example, library dir: /foo. Mountpoint: /foo/bar. However, this one should be easy too (the check on point 2. becomes: match libdir on mountdir OR match mountdir on libdir). There may be other cases I didn't think about.

Finally, while the program is running, just keep an inotify() on the involved medias to apply filters on-the-fly.


* This implies we suppose the user doesn't use mountpoints to "hide" other content. I think it's a sane assumption.

I have moved most of my music to a networked server and I'm currently looking for a solution to use gmb from my laptop. I already have an NFS share, but it's not always mounted, so its presence is unreliable. I'm not asking for mpd or mt-daapd support, since I know it would mean an incredible amount of work to fit it in the current structure.

However, it would be nice to able to be able to mark the directories as "networked", so that gmb would show the files inside them only if they are present. Ideally, when the user adds a directory s/he checks a "networked" mark, which enables a drop-down menu containing the system's mountpoints. The user then selects the appropriate one, which is then checked for mounting. Autodetection should also be possible, even though it's not completely trivial.

This however arises the problem of separating the local db from the "mobile" ones... filtering could be done on just a single db, but it probably would come at a performance cost, I don't know...