Feature request: statistics tracking

RuddO
Posts: 55
Joined: Mon Feb 20, 2012 10:06 am

Feature request: statistics tracking

Post by RuddO » Sat Feb 25, 2012 12:29 pm

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".

RuddO
Posts: 55
Joined: Mon Feb 20, 2012 10:06 am

Feature request: statistics tracking

Post by RuddO » Sat Feb 25, 2012 12:32 pm

Remember that UID generation, at least in the spec I wrote, is really fast. It really only consists of a bunch of audio frames (which you can read with FADVISE to prevent readahead) that won't actually change when the tags themselves change.

Post Reply