I don't want to write stats to my files because there is more than one user of those files, so that's a non-solution.

Can you explain what the performance problem is, in more detail? Thanks in advance.

Yes, other users use Guayadeque too, they have their own independent stats. As I said, writing per-user information in files is a non-solution. Perhaps you would consider writing this information in user.XXXX.YYYY extended attributes instead?

---------------------------------------

Creating a unique ID for each file should take less than a second with the algorithm I proposed. It would be content-based such that you don't have to worry about tags changing. It would *also* be optional.

Finally, generating unique file IDs should be done *in the background*, *after* scanning the library, rather than at the same time of the scan. Precisely so if the process is somehow "slow", it does not affect the use of Guayadeque -- it can always be completed incrementally and eventually.

anonbeat is right if the implementation is poor. if the implementation is solid, it would make the program no slower than it is today.

It's now accepted.

Yes. You are correct. In order to reassign statistics rows to the newly discovered files, guayadeque would have to compute the fingerprints for each of the files (as per the spec I wrote). To get this right, guayadeque would do what it already does today (namely, scan the new directory) and *then* generate the UID in a background thread. As new UIDs are generated for files that were already scanned but not fingerprinted yet, guayadeque can then start reassigning statistics based on this.

Example

/d/music/AlbumX/{Track1,Track2,Track3} gets renamed to /d/music/AlbumZ/{Track1,Track2,Track3}

Then guayadeque is told to update its collection

guayadeque updates its track table. this marks the tracks within AlbumX as deleted, and adds rows for /d/music/AlbumZ/{T1..T3}.

So far, guayadeque has done nothing new here.

Then when the scan is done (or perhaps in parallel as new elements are found), guayadeque generates UIDs for those files that are missing in the UID table.

INTERESTINGLY, once you are done generating the UID for AlbumZ/Track1, you can immediately query your UID table, asking "do you have this UID here?". If there are rows with that UID, you immediately know all the old paths (if you did this right, you will only have one "obsolete" path), so you can safely update all tables that have said paths everywhere, with the new path of AlbumZ/Track1.

And so on, and so forth.

If you have two copies of the same file, guayadeque will add them both to the collection as it does today, then, upon scanning for missing UIDs, the generation of the second file's UID will be accompanied with the discovery process above ("hey, this file happens to be at that path already"), which will cause the stats of the second file to be redirected to the first file. Care must be taken to *merge* stats in the case that there are already stats for both files.

For caution's sake, I would make this feature opt-in, and mutually exclusive with "write statistics to tracks".