[Starson17]

Originally Posted by kiwidude

Given the complications and permutations I suspect that the only solution that would keep all of us happy is a dialog that displays the data from all the merge sources and the user picks what they want from each?

Yes. Kovid has discussed writing a fine control interface for Metadata Fetching. This should alleviate some problems for bad metadata in the first place, and it will provide a starting point for a fine control interface for Merge.

Where it is not quite perfect for me is that if you automatically add tags when new records are added (like "00New") than you have to clear these out before you merge. In this situation I want to merge nothing but formats into the master.

I can see that some might prefer to not merge the "autoadded" tag. That would be easy to change in the code, but others might want to remember that their recently added book was manually merged into an existing record. On the whole, I don't see much benefit of one over the other. It's another of those "permutations" of what different people want that would be best handled with a fine control Merge interface.

Publish date is not merged. I suspect the reason is that the (poor imho) decision not to use nullable dates means that the application cannot determine that X does not have a publish date set yet and that it should in fact overwrite with the value from Z.

Yes, that's why. If a field is filled, I don't overwrite it in Merge, and date fields are always filled.

I wonder if the value it has would match the "Date" column for newly added records and based on this it could decide that a different value could be merged?

This is a good point. When I get a chance, I'll check. Feel free to post what you find or any sample code for this change. I don't use Publish Date much, but if we can detect a "null" entry in the destination and a non-null in a source, we should overwrite.

So for instance the comments fields may differ only by some line feeds - but Calibre will combine them together when you merge and you end up with double summaries.

True, but it's unusual for anyone to edit the Comments to add only a line feed. My tests show that the text from a Fetch is consistent, so if all you've done is run a Fetch Metadata on the books, then merged, you won't get multiple summaries. They'll match.

I think it would be better if the auto-merge behaviour gave an option to only auto-merge new formats, but create duplicate rows (marked with a tag perhaps) where you have the same format.

This seems reasonable, too. We could also consider merging in metadata (which is completely ignored during AutoMerge.)

Feel free to add a Bug/Enhancement Request on this.

I have the same sorts of issues with the metadata download behaviour - where in a perfect world more granular control is desired so you could choose which data to overwrite. However I don't have the Python coding skills to help improve it unfortunately.

This is in the ToDo list (but, AFAIK, not with high priority), and I think it should be done before fine grain control for Merge. The two will be similar. It's currently just a bit beyond my PyQt skills, but we'll get there eventually.