SongKong Jaikoz

SongKong and Jaikoz Music Tagger Community Forum

concerning the beta feature of moving dups to a folder

#1

Only played with the new features in a limited way so far.

One thing that confused me was after selecting “Delete Duplicates” the total number of files open in Jaikoz didn’t change. I then noticed that the base folder of the duplicate files was changed to that of the folder I selected for files to be moved into.

However, in a sea of files where the status indicator is “C”, this was not obvious. Personally, I was expecting them to be saved with whatever changes, moved, then closed, but upon reflection, the safest thing for Jaikoz and do no harm and let people make their own decision is to merely flag the duplicates, which it does by changing the base folder and the status indicator.

I think this would be better accomplished by a new status indicator (since “D” is taken for files to be deleted, can it be “Dup”?) and have them flagged with a new color, selectable in the preferences.

#2

Forget about the Beta for a moment. The current release already has a Delete Duplicates action , when you run this the duplicate files are marked for deletion with a ‘D’ - but not actually deleted until you save changes.

You are suggesting it should be changed to ‘Dup’ instead, but then with the beta version how would you differentiate between duplicates that should be deleted and subsequently duplicates that should just be moved because Delete Duplicates has been run again but with the Move setting rather than the Delete setting - I think the status is probably correct as it is, if you do actaully commit the changes I think the files are closed from Jaikoz.

#3

Totally true and why I recanted my desire to have something automagically done to the dups. It is in keeping with what Jaikoz has always done. I was just envisioning different workflows.

Well maybe the action should be called “Detect Duplicates” more than merely Delete since now you have a nondestructive behavior option for that action.

So how would I differentiate between duplicates that should be deleted and those that should be moved because Delete duplicates has been run again? If I changed the option “to move”, wouldn’t all of the duplicates previously flagged as “D” for delete now just be flagged as “C” for change? Wouldn’t that always be a risk to overriding what you meant to delete if someone does another action later?

My vision of a workflow:

Run autocorrector - it fixes a ton of stuff;
I run “Detect duplicates with move option” - it flags a bunch of stuff to move by changing base folder to my holding folder and changes the status to “Dup”.
Looking at the dupes, I see several I don’t even want to bother with scheduled to be moved to the dupe folder, so I select to delete them to delete and they get a status indicator of “D”.
I hit save, and all my good files go where they need to be, the duplicates I want to save for further examination are saved to the dupe folder and those I want deleted are still deleted.

But to be certain, I can still do this by :

Run autocorrector - it fixes a ton of stuff;
I run “Delect duplicates with move option” - it flags a bunch of stuff to move by changing base folder to my holding folder and changes the status to “C”.
Sorting by Base Folder to find the folder where I defined where dupes go, I can locate what Jaikoz has identified as a dupes.
Looking at the dupes, I see several I don’t even want to bother with scheduled to be moved to the dupe folder, so I select to delete them to delete and they get a status indicator of “D”.
I hit save, and all my good files go where they need to be, the duplicates I want to save for further examination are saved to the dupe folder and those I want deleted are still deleted.

#4

Good point, although the Filter already allows you to just ‘Detect Duplicates’ , whereas when you run ‘Delete Duplicates’ it does the additional step of deciding which of the duplicates to keep and which to change. Also whatever action you choose for Delete Duplicates, they are sort of deleted.

Delete, actually deletes them
Create Alias, also deletes the file and replaces with an alias
Move files, doesn’t actually delete the files , but moves to a staging area that you could consider as a Trash Folder

So I’m undecided about this.

Not if you rerun delete duplicates against only some of the songs.

Actually, once something is marked as deleted most action are now ignored
when applied to the song, you have to ‘Undelete’ it.

[quote=wynlyndd]
My vision of a workflow:

Run autocorrector - it fixes a ton of stuff;
I run “Detect duplicates with move option” - it flags a bunch of stuff to move by changing base folder to my holding folder and changes the status to “Dup”.
Looking at the dupes, I see several I don’t even want to bother with scheduled to be moved to the dupe folder, so I select to delete them to delete and they get a status indicator of “D”.
I hit save, and all my good files go where they need to be, the duplicates I want to save for further examination are saved to the dupe folder and those I want deleted are still deleted.

But to be certain, I can still do this by :

Run autocorrector - it fixes a ton of stuff;
I run “Delect duplicates with move option” - it flags a bunch of stuff to move by changing base folder to my holding folder and changes the status to “C”.
Sorting by Base Folder to find the folder where I defined where dupes go, I can locate what Jaikoz has identified as a dupes.
Looking at the dupes, I see several I don’t even want to bother with scheduled to be moved to the dupe folder, so I select to delete them to delete and they get a status indicator of “D”.
I hit save, and all my good files go where they need to be, the duplicates I want to save for further examination are saved to the dupe folder and those I want deleted are still deleted.[/quote]

Yes, your summary is correct, my thinking was that if you set to move duplicates then you would probably want to consider them further at a later date, not during the current Jaikoz session. I don’t know if your workflow would be common.

#5

Okay…when moving the dups to a new folder, I would like there to be an option in the iTunes integration tab to remove these dups from iTunes upon save.

After moving a couple thousand files to the dup directory, I then had to physically move the folder to an external drive and then turn off the external drive to make them break or be missing. Then I had to run an Applescript from Doug’s itunes scripts to search for dead tracks. This took forever against the whole iTunes library.

Of course, I could turn off itunes integration in the Jaikoz preferences, and only save/move the dups, turn itunes integration back on, and save the rest, but I would still have to run the Super Dead Track remover script.

#6

If we forget about delete duplicates for a moment, if you use the new Preferences/Save/General/Move marked files to deletion folder instead of actually deleting them then they ARE removed from iTunes, even though the files are not actually deleted.

So you could get your required behaviour by having Preferences/Local Correct/Delete Duplicates/When you have Duplicate songs set to Delete Duplicates and Preferences/Save/General/Move marked files to deletion folder instead of actually deleting them checked. Then when you clicked save they would be moved to the deletions folder and removed from iTunes.

The difficulty with doing what you are asking for is that if you have Preferences/Local Correct/Delete Duplicates/When you have Duplicate songs set to Move Duplicates to Duplicate Folder it does this my modifying the foldername, when it comes to save there is nothing to tell Save that these files should be handled differently to other files that are marked for modification because they have been edited.

So the question is do I need to have a think about how can I implement what you want, or are things over complex and should I just remove the Move Duplicates to Duplicate Folder option because you can do what you want by taking advantage of the Deletions folder.

#7

ideas on their way… having a think on it. (or is that jthink…)

#8

Okay here’s how I see it:

We now have these four scenarios to consider:

items that we want deleted
items that we want deleted but moved to reconsider

duplicates we want detected and deleted
duplicates we want detected but moved to reconsider

You’ve implemented some extra options in the preferences to make this happen. Awesome. Now some schmucks like me are asking for more options, which will require more options in the preferences and it may become a complicated mess (give users an inch and they’ll take a mile, and then complain that it is confusing, even though you’ve given them exactly what they want). Let’s see…

Functionally speaking, there are many similarities in the above four scenarios, particularly:

items that we want deleted
duplicates we want detected and deleted

Previously, these were our only two scenarios and we handled them the same way : status change to “D” and the save changes routine whisked them away. They were then deleted from iTunes if integration options were turned on.

Now we are getting nuanced though :

items that we want deleted but moved to reconsider
duplicates we want detected but moved to reconsider

We could treat these about the same and just move to the same folder and have subsequent operations treat them the same i.e. remove from iTunes, however I think the current subtlety is the correct one :

when deleted files are moved to their “reconsider” folder or deleted outright, they are deleted from iTunes
when duplicate files are moved to their “reconsider” folder, they remain in iTunes (by default)

I’d say for 50% to 60% of people this is what they want and expect and the options are not complex.

Paul, you proposed combining the two options

items that we want deleted but moved to reconsider
duplicates we want detected but moved to reconsider

into one function, which would status change/flag them with “D” and move them into a “reconsider” folder and remove from iTunes. I think this is takes granularity away from a user. If I want to be able to “reconsider” my duplicates, now my Deletes are in the same folder, mixed in. I personally am confident enough that when I allow it to be marked with a “D” it should be done away with.

-----------------------------------------------------------------------------------So if we accept the current options are good, how do we add to it to get the option to remove duplicates from iTunes?

Since currently, the duplicates are flagged by merely changing the base folder to the folder specified in the options. In its own way, this is an indicator. It says, “I am a dupe!”

Your save routine can see which folder it is putting the file, then save the changes to the file, and then pass off the filename to the routine that interacts with iTunes with instructions to remove it from iTunes.

All without needing a new status indicator for dupes. Personally I like having a new status indicator (the save routine would need to recognize it) for in the future when there is a plugin API, you allow someone else’s code to do something with them.

I think this would help the other 40-50% of people who do not want the dupes in iTunes even though they are reconsidering them.

#9

Ok, so actually the status quo is correct for the majority (60%) , but you want an option to "Delete from iTunes when Duplicates saved to Duplicates Folder’ .

Without this option, they would be deleted from iTunes if you loaded the Duplicates folder in Jaikoz, and deleted them from within Jaikoz after reviewing them, but I suppose you want to review them outside of Jaikoz in which case this wouldn’t happen.

#10

Well it’s not even that I want to review outside Jaikoz. After spending a few days loading up my collection in batches, and moving out duplicates to another folder, I now have a few thousand files to reconsider. I will probably load them up in Jaikoz again for the reconsidering process but not right now. Might be a week, or a month or more until I get around to it. But in the meantime, I don’t want to see them in iTunes.

#11

Right, Im looking at adding it for beta2, but in the meantime could you use the last playlist created by Jaikoz, and delete from iTunes.

#12

Yep. Hadn’t thought of that being an alternative way since I had that option turned off since it made a zillion little playlists and iTunes annoyingly won’t let me select multiple playlists at a time to do anything with.

#13

Yeah, I remembered you said this after posting, I’m looking now in the iTunes Windows SDK docs to work out how to create a top level folder

#14

Awesome! I hope it’s easy. Personally, not being able to select multiple playlists to move them around or delete is an oversight on Apple’s part.

#15

Its done, ready for Jaikoz 350 beta2

Unfortunately the iTunes integration is never that easy because i have to write Applescript for OSX and use a COM wrapper for Windows, so I have to do the work twice and its not as nice as pure Java.

#16

bows

Glad it was easy.