Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[glynor]

This has been annoying me for a long while, but I battled it for a few hours last night (and I have many more hours ahead later) so I'm finally going to complain.  You sure you missed me?   

If you have a Handheld added to MC that points to a file path (a "generic" handheld), and you have the Delete from Handheld any files not in sync list option enabled, there is one aspect that doesn't work as expected, and it is creating a ton of problems for me.

If the "sync path" (that specified for a media type under Files, Paths, and More in the Handheld settings) changes for an existing handheld, any files that are already synced over don't get "fixed".  They stay where they are.  MC doesn't delete the old ones and sync the new ones.  This makes it difficult to move or rename files on the handheld once you've synced items over to them, without deleting the entire contents of the handheld and starting over.

So, for a simple example:

1. You set up a handheld and use the default path options for music, [Artist]\[Album], and then sync some files over.
2. Later you decide you'd rather have them organized by [Genre]\[Artist]\[Album], so you change the path option in the handheld.
3. Sync again with some new files.
4. You will now have a mix on disk.  The stuff that was already there (and still in the sync list) stays in the [Artist]\[Album] hierarchy, and the new stuff uses the new [Genre] based system.

The only way to "fix" the files that are already there is to manually delete them in Windows Explorer, and then resync.

My particular issue with this is the old Clean(,3) problem.  Back in the day when I was setting up my sync, MC didn't have a simple way to replace special characters in an expression the same way it does when you do a file renaming operation (like you do in a Handheld sync).  The Clean(,3) option used to insert a "-" character, while the actual rename operation inserted a "_" character.

You fixed that.  Yay.  So now, my expression properly names the files on disk and can create a "key" in MC to locate those handheld copies.

Here's the problem:  I had it the "old way" (with the dashes) for months and months.  I have just under 40,000 tracks synced to my handheld, plus a metric ton of photos and some videos as well.  There are currently about 3000 tracks that "error" when I use MCiS to sync my handheld to iTunes, because the files on disk "exist" (as far as MC's Handheld Sync is concerned) but they are named wrong on disk according to the now-current Expression in the Handheld File Paths setting.

Three thousand tracks is a bunch of tracks, but 40k is way more.  I'm looking for 3000 needles in a 40k track haypile.  My only choice is to wipe the entire "handheld" and start over.  But syncing 40k tracks (converting a ton from higher bitrates, flac, and other esoteric file types) is no quick business.  If I remember right, it took days and days of fiddling and waiting to get it done the first time.  It's using a sledgehammer to drive in a thumb tack.

Can this be changed?

[glynor]

Also, it would be nice if the Handheld Sync list dialog looked and worked like a regular View Scheme.  I have 40k tracks in there, of a wide variety of types, but I can't filter them by anything other than Artist and Album.  I'd like to have Panes at the Top like any regular View Scheme, and add [Media Sub Type], [Genre], and other more esoteric categories so that I can filter the sync list properly.

And... Lastly... This.  Please, dog, this: http://yabb.jriver.com/interact/index.php?topic=71377.0

I still need to sync more than one Handheld on an automated basis.  It works now, as long as you only have one Handheld added to MC, but that's an annoying limitation.  Can we get an MCC that accepts a named handheld and syncs it on command?  Pretty, pretty please with a cherry on top?

[MrC]

Glynor, this may be the same issue I reported in MC17.  Matt worked through many of the HH issues.  There seems to be one remaining - namely, stale entries are not removed from the HH.  See the beta thread "Sync and Duplicates, one cause", particularly start w/reply #12.

[BryanC]

Glynor, this may be the same issue I reported in MC17.  Matt worked through many of the HH issues.  There seems to be one remaining - namely, stale entries are not removed from the HH.  See the beta thread "Sync and Duplicates, one cause", particularly start w/reply #12.

I can't see the beta threads, but this "sync and duplicates" sounds very similar to a problem I've been dealing with for at least 5 years now. I hope we get this fixed.

[glynor]

It is also annoying that the Recheck Sync button/feature of the Handheld Sync system is badly behaved.

On my system (with a substantial sync list of a bit under 40k files) it pegs a single CPU core until it is done, but only one (so it appears to be single-threaded).  Multithreading it might be more trouble than it's worth if it is difficult and/or wouldn't gain much performance.  But it also blocks the UI while it does its thing, and doesn't put up a "please wait" dialog reliably.  Sometimes I see a "Calculating Transfer" dialog, but it only appears briefly (and sometimes not at all), and when it does, it is only visible for a small fraction of the time it takes to calculate the sync.