Advanced Duplicate Find & Fix 3.8.2 (2014-01-27)

[Koinu]

After several reinstalls and checks with admin-rights and so on, unfortunately, the problem is still there:
- in the "Delete Suggestions"
- right click on a track
- "Delete Selected and/or Transfer their Playstat"
- in the new pop up "OK"
The above mentioned error window appears.

As skywinder and I have the same OS, could it be a problem with the x64-OS?

[Bex]

I managed to replicate the "No such table"-error. It will be fixed later today. In the mean time you can use the node in the "Entire Library"-Collection which works just fine. If not enabled go to Tools->Options->Library->Media Tree, and enabled it.

[Bex]

I managed to replicate all errors reported and fix them. I also found another error which is fixed.

Ver 3.8.1 (2012-11-10)
-Fixed SQL errors with "Create Keep/Delete Suggestion Nodes" in CDS when a tolerance was applied
-Fixed SQL errors in right click menu "Delete Selected and/or Transfer their Playstat"
-Fixed "Create Keep/Delete Suggestion Nodes" in "Tracks with same Content"-Node didn't respect "Filter by Playlist"

Download here or from the first post:
Advanced Duplicate Find & Fix 3.8.1
If you're a new user, please read the first post, including the installation instructions.

[Koinu]

Bex, thanks a lot.
Nothing to report except your tool works very well!

[Bex]

Thank you, Koinu!

[MM3 monkey]

Thank you VERY much indeed for this monumental update, Bex. And thanks Nyn too.

[Bex]

Thanks!

[snox]

Thank you Bex for this very helpful script. Using it for a while now.

[Bex]

Thank you!

[Blutarsky]

Before reading the whole pot, I was wondering if this script can help the following problem:
When updating some tracks in the library, from older to newer versions, often the newer tracks may have changed the file name; problem because if the track is part of a playlist a tedious ticking task will occur to spot where the newer track must be inserted in the playlist. Can your script help on this? How?

[Bex]

Sure, use the Copy/Paste Metadata feature and copy from the old track and paste to the new track (use manual selection). You can then choose what you want to paste, If all tags are correct on the new tracks you only want to paste the Special Database Values. Try it one track first so you get a hang of how it works. You can then copy from a list of tracks to a list of tracks, the lists need to be in same order though.

[Blutarsky]

Well the new tracks are always properly tagged.

I'd have to plan a proper strategy to minimize efforts swapping newer versions: delete older tracks before loading the newer copies? Or keep them, so they can be used as an outline to follow?

For example, lately I have refreshed some 800+ tracks in the library (2700 tracks). Updated complete albums or just singles. Some of the update tracks are part of 20 playlists (each one counting from 20 to 150 tracks)....

Conceptually the workflow should work in this way:
- add newer versions
- swap newer versions in playlists (automatically or almost automatically)
- highlight duplicated tracks and delete older ones

Any idea?

[Bex]

When I replace old files with new rips I do like this:
1. Rip the new track, I don't care about their tags. (I do this per album)
2. Add them to MM's library if they are not there.
3. Locate the old files.
4. Make sure that the old track and the new tracks are in exact same order.
5. Copy metadata from the old tracks and paste to the new tracks, I select to:
- a) Paste all "Special Database values"
- b) Paste all "Tags and Database Values"
- c) Delete Copied tracks
- - - Delete from Library and computer (Without Confirmation)
- - - Move the "Pasted to Tracks" to the deleted "Copied from Tracks" old Path

Doing it this way I transfer absolutely everything from my old tracks to my new rips and the old, now useless tracks, are deleted. I have also set up a short cut in "Copy/Paste Metadata" which does the above so it's faster to execute.

I know that others that do the some thing but some don't want to delete the old tracks until they manually checked that all is OK.

If you already have many new rips in your library which you want to replace old tracks with and they are tagged the same as the old tracks. Go for "Custom Duplicate Search" with e.g. same Artist, Title, Album, Length and then "Create Keep/Delete suggestion nodes". But read the first post first.

[Blutarsky]

When I replace old files with new rips I do like this:
1. Rip the new track, I don't care about their tags. (I do this per album)
2. Add them to MM's library if they are not there.
3. Locate the old files.
4. Make sure that the old track and the new tracks are in exact same order.
5. Copy metadata from the old tracks and paste to the new tracks, I select to:
- a) Paste all "Special Database values"
- b) Paste all "Tags and Database Values"
- c) Delete Copied tracks
- - - Delete from Library and computer (Without Confirmation)
- - - Move the "Pasted to Tracks" to the deleted "Copied from Tracks" old Path

Doing it this way I transfer absolutely everything from my old tracks to my new rips and the old, now useless tracks, are deleted. I have also set up a short cut in "Copy/Paste Metadata" which does the above so it's faster to execute.

I know that others that do the some thing but some don't want to delete the old tracks until they manually checked that all is OK.

If you already have many new rips in your library which you want to replace old tracks with and they are tagged the same as the old tracks. Go for "Custom Duplicate Search" with e.g. same Artist, Title, Album, Length and then "Create Keep/Delete suggestion nodes". But read the first post first.

Questions:
- Would this workflow be successful on changed filenames? (example: oldfilename.mp3, newfilename.m4a)

- a) Paste all "Special Database values"

- Will this step enable inheriting of playlists data?

[Bex]

- Would this workflow be successful on changed filenames? (example: oldfilename.mp3, newfilename.m4a)

Yes.

- Will this step enable inheriting of playlists data?

Yes. The checkbox "Transfer Playlist Entries" takes care of that.