Noodlesoft Forums

My main iTunes library folder is on an external drive. Hazel does not monitor any of the folders on this drive.

As I obtain new media files, I drop them into my Music and Movies folders on my local drive. Hazel monitors these folders, and runs an Automator workflow on files that are added to them. This workflow adds the files to my iTunes library (without copying them to the external drive—they are added at their current location) and sets a few of their library properties.

Periodically, as my local drive fills up, I perform a "Consolidate Library" operation in iTunes, which copies all of the media files in my local Music and Movies folders into the iTunes library folder on the external drive, updating the library to reference the files at their new location. I then delete the files from the local folders to free up space on my local drive.

The problem I am having is that, for some reason, while iTunes is performing the "Consolidate Library" operation, Hazel seems to think that the files on the local drive are new again, and it begins executing the Automator action on them. The result is, at the end of the "Consolidate Library" operation, I have two copies of each of the files in my iTunes library. This is easy enough to clean up, but I’d prefer not to have to.

Why is Hazel detecting and re-processing the files as new? As far as I can tell, the "Consolidate Library" operation isn’t doing anything to the files in question besides copying them to a location that Hazel does not monitor. Their Created, Modified, and Last Opened dates are not affected.

I am running Mac OS X 10.5.6 and iTunes 8.2.

What are the conditions on the rule? Hazel keeps track of the last rule matched so that it doesn't keep re-running the same rule on a file but if conditions change such that the file in question starts matching a different rule (or no rule at all), then it can end up running the rule again if conditions change back.

Taking my Music folder as an example, I have two rules defined for this folder:

Rule #1: if ALL true: 1) Kind is Music, 2) Name contains "Grant Lawrence"
Rule #2: if Kind is Music

The files that I see being reprocessed match both rules, which may be significant. The files that only match Rule #2 are not being reprocessed.

One thing to keep in mind is that a file only matches one rule, which is the first one in the list for which the conditions hold. If the files being reprocessed match rule 1, then, unless there are other circumstances, the question is whether at some point, the file's name does not contain "Grant Lawrence". Is it possible that the file gets renamed at some point? Are there other rules or conditions not shown here? Also, what do each of the rules actually do?

Thank you for the insight, but I’m afraid I still can’t reconcile the behavior I’m seeing with what you describe.

To the best of my knowledge, the files are never renamed. The first action (the one that is mysteriously being re-triggered) runs a very simple Automator workflow that adds the file to iTunes with particular iTunes properties set (e.g. skip when shuffling), and then displays a Growl notification.

The second action simply imports files into iTunes (using Hazel's own support for this) and then displays a Growl notification.

Any tips on how I might probe more deeply into the cause of this problem?

It might be better if we take it to email. Click on the "Contact Support" link in Hazel's "Info" tab. If you are a registered user, you can export the rules in question and attach them to the email, otherwise, screenshots of the rules would be helpful.

Also, if you could turn on debug mode as described here: viewtopic.php?f=4&t=296

If you can re-trigger the event and then grab the logs during that period and send them to me, I can get a definite sense of what is going on.

The problem seems to have been confined to a specific set of files. Now that those files are no longer present in the folder, I seem to be unable to reproduce the issue.

If it happens again, I will certainly follow up by email with a full debug log.

Thanks!