Grouping error

[DavidHB]

Thank you, Simon. I have now identified the problem, but, as your litany of questions forms a useful diagnostic tool, I shall answer them first, in the hope of helping other users afflicted with issues of this kind.

(27-10-2013 08:05)simoncn Wrote:  Have you accidentally omitted one of the tracks from this sonata from the group?

No.

Quote:Do any of the tracks from this sonata produce a warning or error message in the log?

No (other than the group-related message previously described).

Quote:Do any tracks with the same group name appear on disc 1?

No.

Quote:Do the tracks on disc 2 begin with track 1, and are they all numbered consecutively?

Yes and yes.

Quote:Please try isolating the problem by adding the first movement of this sonata (only) to the group. If this works, try adding movements 1 and 2 only, etc.

I had tried this. If the Group tag was added to a single file, there was no error message, and the track would show up normally in the Control Point. The fact that it did not show up as a group should have been a clue, but I only realised the implications later. Adding a second track to the group generated the error previously described.

The problem was that the file set on the NAS was not identical to the file set in my PC music folder. I do all the ripping and metadata work on the PC, and then use a SyncToy 'Echo' folder pair to synchronise the NAS with the PC music folder. For reasons I still don't understand, SyncToy failed to delete a separate, rogue copy of the offending disc from the NAS file set. Understandably, MinimServer did not take kindly to two folders with identical content. With the rogue copy removed, all works normally.

The moral here is that, if the workflow requires separate but synchronised copies of the music library to be kept on the PC and on the NAS (and I believe that this is a generally good way of working), a separate instance of MinimServer, accessing the PC file set, should be run on the PC, so that, if need be, the two file sets can be tested separately. I have known for some time that this is a sensible idea, but neglected to follow it up. In the present instance, testing the file sets separately would have enabled me to identify the problem much more quickly.

Thanks again for your help.

David