Duplicate file scan pulls up files with only one copy

[Bex]

Ok here is the code to use when you have decided what tracks to delete:

Code: Select all

DELETE Songs.*, Songs.ID
FROM Songs
WHERE (((Songs.ID) In (1234,1325,4514,7854,1246)));

Just put the id's you want to delete comma separeted in the parenthesis. The numbers you see there now are just an example so dont forget to remove them from the code.
And since this actually deletes stuff from your db, TAKE A BACKUP FIRST!!!

To run the query do as with the other queries!


Good luck!
/Bex

[Bex]

Here it is!

Code: Select all

DELETE Songs.*, Songs.ID
FROM Songs
WHERE (((Songs.ID) In (9479,9492,9462,9476,9480,9495,9496,9497,9471,9484,9477,9469,9473,9463,
9488,9485,9472,9483,9465,9481,9486,9494,9467,9470,9475,9468,9466,9491,
9482,9478,9489,9487,9474,9464,9490,9493)));

Did it work?

[Exaxxion]

Well, the false duplicates have vanished, but for good measure, I scanned a directory that I know produced some of the false duplicates...

And all of the songs that were in there that came up as (1x) reappeared. Perhaps I should reapply my backup, then erase them from the database using the same method with the other set of IDs?

[Bex]

Intresting I think you just found a bug that has been discussed alot lately. Please remove the dups again and install the dubug version (see the sticky in the debug forum). Scan the directories and send the debug log to the MM team. I'm sure they are interested in that log.

Then you could try to delete the other ones eventhough the tracks with the highest ID should be the one to delete. Dont forget to make a new backup if you use the only one you have!

/Bex

[Exaxxion]

Actually, I tried it with the lower set of ID's, rescanned, and it didn't show any (1x) results anymore ^_^

I don't know if you still want me to send that debug log, but i still have the backup mdb from before the change.

[Bex]

Yes. please send a debog log to the MM team.

[Exaxxion]

I hate to be a bother, but I don't see any forums listed as "Debug", could you possibly provide a link or more detailed directions? Thanks

[Bex]

Sure, I meant the Bug forum (actually this one) : http://www.mediamonkey.com/forum/viewtopic.php?t=69

Please note that it is when you add the tracks which gets duplicated that is intresting to get a log from!

/Bex

[Nebbin]

I'm having similar problems recently - where all tracks from scanned folders are being added to MM, without regard to any tracks already in MM's DB, thus creating these false duplicates (ie, same file path, both bold when playing, both disappear when one is deleted). This has only been the case since switching to MM 2.5.1.

I'll install the debug version of MM and send the results to the developers. Hopefully a fix is easy, and that it's just something I'm doing wrong.

[Matt M]

I seem to be having a similar problem.. I updated the names of some files in a playlist... When I go back to the drive they're on the old names are there...they no longer play...a correct thing I think.

I then rescan that folder..the new names show up..but the old ones don't go away...and they don't become dead links.

What am I doing wrong??

[rusty]

Hi,
It sounds like there's a problem, but we haven't been able to reproduce this.

If you can, PLEASE send a debug log.

Thx.

-Rusty

[Exaxxion]

@Matt M

Have you tried looking at the files in the old directory? Mediamonkey, to the best of my knowledge, uses a "copy then delete" operation when moving files. With older versions I noticed that it would occasionally leave behind same-name files, but their filesizes were 0 (empty), so they would not play. I assumed that this meant the delete operation didn't work right, and I just deleted them manually because the files had nothing in them anyway, the new files worked, and it wasn't a major problem.

Check to see the size of the remaining files in either the MM filesize node or in explorer. If it is zero, you can just delete them, assuming the new files play properly.

By the way, your problem is completely different from the one I had in this thread. The one I had still continues to appear from time to time but I just fix it with the SQL method mentioned earlier in this thread. Note: The SQL method will not work for your problem, so just ignore it.

@Nebbin

Your problem is also different. In mine, one track is believed to be a duplicate, and appears in the duplicate node as (x1). There is only one copy of the file in existence, and a duplicate instance of the file is not listed anywhere in the library, thus no double-bolding, etc.