What doesn't make sense is once I copy the mp3 off the server MC see's the embedded cover art.
If I understand that statement correctly, you copy the mp3 from the server to somewhere else, and then without doing anything else, MC "sees" the embedded Cover Art, as evidenced by the thumbnails showing up in MC?
Makes perfect sense. When you copy the file off the server it triggers a File Event. MC sees the File Event, looks at the file, and builds a thumbnail for it because it doesn't already have one. What doesn't make sense is why MC doesn't see the Cover Art when you copy a file to the server, particularly if MC imports the file at that time. But if you copy lots to the server, MC will work through the files to add thumbnails. Whereas when you generate a File Event MC will immediately look at that file and build the thumbnail.
Remember, Cover Art and Thumbnails are two different things, thumbnails being smaller versions of the original Cover Art image, in three sizes, and stored in a set of indexed files for fast access by MC for quick display in MC Views. Which is most likely why;
If I open up MC24, I see no cover art. 
MC simply hasn't built the Thumbnail to display in its Views yet. Well, at least that is one possibility.
Except that I think Vocalpoint's observation is an important one here. For some files, Tag & Rename doesn't write Cover Art tags in a consistent way that MC can read.
Im guessing i might just have to start using MC to fix mp3 metadata.
I think that would be a good idea, and if you do that, make the share Read/Write access, so that MC can write tag updates to the files. Otherwise tags will have one value in the MC Library, and another in the file itself, meaning if you ever import them again into MC, tags will be wrong.
Take a look at the "Manage Library Fields" function in MC, and use the drop-down filter (top left) to "Show only fields saved in tags". There are quite a few. Whether a field is written to the file tags is defined at the field level, as shown by the "Save in file tags (when possible)" checkbox. When you use a Read Only share, and then make any change in MC, all those tags will get out of sync.
If MC needs r/w access, why do 99.99% work fine with read only access. Close to all 165,00 mp3 have embedded cover are. MC doesnt need to write anythhing.
Actually, I think MC only needs Read/Write access to the Thumbnails files, which are on the PC running MC. I don't think it needs write access to the original mp3 files to build thumbnails. But I could be wrong there.
I'm still not sure how many PCs you have involved in your whole setup, but I know there is a "W2k8 server with a read only share" and a "MC24 server is running on dedicated box running W10 Pro", then I think you have a Workstation that acts as a MC Client at some times, or your MC Server would have no need to be a server and could just be a standalone copy of MC (i.e. Media Network wouldn't need to be running). So the thumbnail files would exist on the MC24 Server, and separately on the Workstation MC Client, as each installation of MC maintains its own thumbnails files. Of course, each MC installation has Read/Write access to its local disks where the thumbnails files are located.
Author
Topic: Weird Behavior relating to embedded cover art. (Read 2138 times)