Print

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

[Samson]

Hi All,
MC 18.0.212
I am syncing playlists to a 'virtual handheld' folder and have checked "Delete from Handheld any files not in Sync List". MC is incorrectly listing many tracks or whole albums for "delete on Sync" when you click the "Recheck Sync".This has caused some grief as I initially didn't monitor this and lost stuff eventually needing to start from scratch.

I have isolated the problem to MC mainting two different versions of the same playlist. So you have 'Playlist A' listed under "Playlists" in the Tree....and you have "Playlist A" also listed under "Drives and Devices"/Handheld device. The playlists listed under the Handheld device are a subset of ("Playlists" > playlists) which have been chosen to be included in the "Options" section for the handheld. Logic would suggest these are simply a copy of, or link to, the original playlist....but they aren't.

Items listed for "Delete on Sync" are physically present in the "virtual HH" folder. The same item IS listed in the HH Playlist A... but NOT listed in the "Playlists" - Playlist A. So it seems deletion is set by reference to whats in the "Playlists" - Playlist.

Adding the items back to the "Playlist" -Playlist A and Recheck Sync now removes the "delete on sync" warning. However in the HH- Playlist A , it shows as a "Duplicate"

Any suggestion to fix would be appreciated
Thanks
David

[MrC]

I don't think the playlists are the source of the trouble.  I believe that MC creates the playlists on the device to reflect what was synced, and so that you can use those playlists on your device as well.  Their incorrect contents are symptoms, but not the cause.

MC creates a database file on the device (Database.mpl) and this list is used to hint at what files MC has synced to the device.  I believe MC compares the sync playlists or files against this list, but it also does some more internal magic.

Over the past year, many bugs in this area have been squashed.  At least one still remains - that is, when metadata changes for a file, sometimes the sync process fails to match up the new file and its metadata with the old one, and you'll get duplicates.  This typically happens when you change something like the album name, or artist.

Another bug I suppose is that the status indicated in the sync status queue is not very reliable for what MC will actually do.  Sometimes it tells you that some files will be deleted, sometimes it doesn't and just does the work anyway.  (In my opinion, this area needs a major overhaul, as over the years, I and others have found HH sync to be troublesome and fairly unreliable).

Ultimately, I've created a process that works well most of the time, and occasionally I have to delete a duplicate file or two.  The process I use makes this pretty easy now (for me anyway).

A key step is to first ensure that you are starting with a clean slate, removing everything from the virtual HH directory, including the Database.mpl, and have MC perform a full sync.

Each time I sync, I open both the virtual HH view, and my Sync List smartlist, and take note of how many files are indicated on each.  They should always been the same at the end of the sync, and when they are not, this indicates MC has failed to correctly match a file with changed metadata with an existing file on the HH.  And then I have to find which file(s) are duplicated.  Often the log messages indicate which files were problematic (I keep logging always enabled), and other times I have to export both views so that I can sort and compare them.  This always yields the differences, and then I manually delete the HH files that MC didn't delete.

My views (Sync List and Fake HH) contain a single column - the MC "MatchKeyExpression" value.  This is a calculated value that MC uses to determine whether or not two files are the same.  For Audio files, it is tantamount to:

    [Name]  Clean([Artist], 1)  [Album] [Genre]  FormatNumber([Track #,0])  [Media Type]

By exporting these views as CSV files, I can sort and diff the files easily, to find the problems.

So, start with a clean slate, enable logging, and then do your sync and check the results by checking the file counts.

[Samson]

Thanks MrC for your time taken to reply. Before reading your post I got as far as comparing the two (2) playlists, the Virtual HH list in MC ,the actual content of the HH directory and the content of the .mpl file. Your workaround no doubt simplifies this process but would still be too complicated for me to pursue.

I previously gave up on keeping a cache file as it was too problematic and now with the sync function also unreliable I think it is fair to say the whole process is broken.

I,ve spent a lot of hours on this and will very likely change to doing manual conversions and using a 3rd party sync tool. To be honest it would have been appreciated if these bugs were included in the Wiki in the form of "use at own risk",lol.

That said, thank you again for your efforts. You have saved me many more hours puzzling what I might have been doing wrong.

Cheers Mr C
David