Question about AFT and duplicate entries

[Colin Guthrie]

Jeff Mitchell wrote:
> You can't.  Buyer beware.  The point of AFT isn't to make sure that 
> every file that is the exact same song always updates stats -- it's to 
> make sure that stats aren't lost totally.  It's up to you to make sure 
> you don't have duplicate files all over your collection (which are 
> generally annoying anyways and people generally want to get rid of 
> them).  Or that you always play the same one.
> 
> If anything, people generally want to use AFT to find duplicates to 
> avoid this situation, because it's so annoying  :-)

Ahh indeed. OK I think I was seeing AFT as being a little more far
reaching than I initially envisaged. I see what you mean here.

In my use case it's not amazing as I tend to copy subsets of my full
collection onto my laptop for when I'm not connected to my home network.
 I guess what I should do in this scenario is setup my local folders as
a Media device in some way and have some sort of manual mount point or
something and just "disconnect" it when I'm attached to my home
network.....

>> mysql> select count(*) from statistics where uniqueid is null;
>> +----------+
>> | count(*) |
>> +----------+
>> |        9 |
>> +----------+
>>
>>   
> Right.  BUT.  There is still a URL associated with that second copy.  
> And the uniqueid will get updated to the proper ID if/when that first 
> file is ever deleted/removed/not found.  Then the second one will be 
> found, the entry in statistics will get a proper uniqueid attached to 
> it, and it becomes the new one.  Does this mean you can bounce back and 
> forth with your statistics?  Absolutely.  See my preceding answer for 
> why this is generally not a problem.

Cool. Yup I think I'm getting it now :)


>> 1. Remove the unique key on the uniqueid table to allow it to list
>> *every* file in your collection, copies and all (as the copies *do* show
>> up in the browser and *can* be played, they *must* be cataloged).
>>   
> Maybe.  A long time ago the design was to allow this, and not have the 
> unique field be unique (an ID rather than a unique ID).  But it didn't 
> work for other reasons, some of which have been mitigated by now, and 
> I'm not sure about the rest.

I guess if you do a lot of renames, the uniqueid table may never get any
smaller....

> You'd have to cause everywhere the statistics table is accessed to have 
> to put in code to ensure that the "full" URL is figured out ahead of 
> time to avoid screwing with dynamic collection.

Yeah, I'd imagine there are a lot of knock on effects. The scanner would
also have to update the statistics to correct the uniqueid on the event
that the file changes etc. so this is not just free....

> Thanks for the input...

That's OK, thanks for your patience!! :)

Col