I don't understand. In what scenario would you set up Handheld sync in such a way to get lots of dupes? Certainly not from syncing several playlists. What situation would produce a handheld sync that you would want, but would give you lots of dupes?
Mainly I was responding to this comment Brian. You asked how you could get dups in a Handheld sync. I explained how it could happen simply, and probably quite commonly. Not everyone curates their music collection carefully, or their Playlists. Of course then as you say below, you have a handheld definition that produces dups.
No, that doesn't make sense. Why? Because Handheld Sync uses a common area for writing all songs.
Yes I thought that through as well, and you are correct. But if (proper) de-duping reduced the amount of files to be copied over, at the simple level that would reduce the time it takes to synchronise, which I for one would appreciate.
The worst that would happen is that MC's logic would make it try to copy the same file to the same location twice. In which case, MC should deal with file level duplicates. Maybe that's the issue: Maybe Handheld Sync's file level duplicates handling only creates duplicates.
Unfortunately JRiver doesn't have any control over how a handheld device responds when something tries to copy the same file to it twice, into the same location. They have to support as many devices as they can, and can't know how each will respond.
In the best case, which is when the handheld is treated by the PC as a hard drive, Windows will rename the second file by adding " (1)" to it. I saw that yesterday, but I was writing to a hard disk folder. If I was writing to a handheld that presented as a folder I assume it would do the same, but I can't test that.
In the worst case (possibly), the handheld would flag an error, or perhaps ask for confirmation of a file overwrite. If MC doesn't show that message to the user, and to do so it would need to understand that there is a message to display and an action to be taken, then the Handheld Sync may just hang, or stop when the message timed out, or never complete. I don't know how WMDM devices are supposed to respond to that situation, or if they have flexibility in how they respond, and I don't think I shall research that. JRiver added de-dup capability to Handheld synchronisation for some reason, after all. I trust they had good reason.
I've actually got a handheld definition right now which duplicates files every single time I run it. I wonder if this behavior I'm seeing (file level duplicates) is related to this decision to do Handheld Sync de-duping. In my opinion it would be smarter to have file level duplicate code that has the option to overwrite or ignore.
File level de-dup may make more sense, as long as it also took into account the destination directory. That is, it would be full path level de-dup. Otherwise files of the same name, but belonging to completely different albums, would be removed from the synchronisation. I think we could all find songs with the same file name in out collections, even though they belong to completely different Artists and Albums.
But file level de-dup would take away from the power of using tags, and possibly force people to rename files to force a track to synchronise.
Nothing like a bit of robust discussion in the morning hey Brian? Now I need some breakfast!