finding duplicate tracks in jemplode

Lacking the ability to "replace track" in jemplode, and doubting my ability to make it happen (I think I figured out how AbstractPlaylistNodeModifier and so might be able to figure it out eventually) I figured I'd just upload the duplicates and manually copy the Wendy flags. However, the easy way to deal with this is to be able to search for duplicate tagged songs. I can't think of a good way to do that. Well, I guess this would actually be "search for duplicate info from tags in the database".

I can't think of a good way to do it. Is it because I'm slow this morning, or is it not possible?

44+ checks the hash code of the tunes that are uploaded, but you have to had uploaded the original songs with 44+ to get their hash code calculated properly.

However, if you wanted to do one that instead just matched tags, you would want to look at FIDPlaylistNodeModifier. the importFile(..) method is responsible for either adding a node to the playlist or finding an existing one that's already there. You could change that implementation to implement your own replacement algorithm (_node.getPlayerDatabase().getNodeMap().elements() will give you an Enumeration of all the nodes in the database. You can then call getTags().getValue(DatabaseTags.TITLE_TAG) and look for one whose title matches and just return that node.

ms

Ok.

I guess i just need to make a build environment for myself.

To confirm that I understand what's going on...

The core of this test is the one that ends up being done in AbstractFIDNode's "matches" routine, yes?

It implies a match would be length and title matching, and I think if I tweaked it to be track time and title matching it would be sufficient. I'm going to try it as soon as I find what I did with my eclipse install.

Yeah -- one approach would be to modify the matches(..) method and make the FIDNodeModifier iterate the entire database looking for a .matches(..) node. The only downside is that it could potentially be a really slow process. ms

With 10000 songs there's no doubt it would be slow.

Thanks.