Avoid iTunes library entry duplicate?

[batsonjay]

Hi -

Sorry if this was answered elsewhere; I searched a bit first, but after 2 pages of search results, thought I'd done enough searching & can ask

Assume a simple rule that's watching a 1-deep folder, the match is to type "Music", and the action is to add to iTunes library.

When I move a music file OUT of that folder, then back IN, it appears a second, duplicate iTunes *library* entry is made. (I confirmed that a) when I moved the file OUT of the watched folder, iTunes updated it's location to it's new folder location, and b) after I moved the file back, iTunes updated the existing entry with that new (original) location, then the rule triggered & Hazel created a second entry, which is now identical to the first entry.

It's possible such action may be taken by me occasionally (I'm a DJ, and I do a fair bit of manual library management). I couldn't see an obvious way to set up a rule to check to assure that it wasn't making this 2nd library entry.

Am I missing something, or is Hazel unable to check first if iTunes already has a library entry matching appropriate attributes (e.g. possibly size, filename, or etc.), and if so, NOT create the iTunes library entry?

[Mr_Noodle]

It may be difficult to check for duplicates in the library in that behavior would be different between whether you have the option to copy files into iTunes checked or not. I'll look into it though.

[batsonjay]

It may be difficult to check for duplicates in the library in that behavior would be different between whether you have the option to copy files into iTunes checked or not. I'll look into it though.

Good point about the copy file option. BUT, hopefully that's check-able by your software.

The question will arise "How much metadata about a library entry indicates a match such that you ought not to create a new entry".

My thoughts would be that you would not create a new library entry if:

• The filename (excluding path) is an exact match;
• The file size (physical on disc, vs. logical) is an exact match;
• (Optional?) The file date modified is an exact match. (I'm not sure about the specifics of "Date added" to know if that would trip things up.)

The failure case is that you fail to match an existing library entry, and thus create an extra library entry; you wouldn't be removing anything, so there's very little downside to providing this capability; just warn users it's not guaranteed to be flawless.

This will cover the vast amount of cases properly, and provide enough value that the feature accomplishes the desire without unintended consequences.

Thanks for looking into this. It's likely going to be a notable benefit to me.