INTERACT FORUM
More => Old Versions => Media Center 17 => Topic started by: jacky on January 16, 2012, 08:05:43 pm
-
I am considering abandoning a centralized MC Library server.
Instead I am considering having multiple computers each with their own local library DB, but sharing the same music/movie files on a central Mapped Drive on a file server.
But I am concerned about file write conflicts. I don't know if MC will automatically modify tags, change thumbnails, etc upon auto-import or during use....
And thus cause unintended changes made from other MCs.
For example:
Thumbnail storage (folder.jpg)
Tagging
Ratings
For example, I would like to know the behavior of the following scenario:
1. User manually imports "album A" CD through MC1 (Media Center on computer 1) into the server mapped drive
2. User Manually changes some tags, adds a thumbnail
3. MC2's auto import picks up newly discovered file in the server mapped drive directory
4. What will MC2 do? Might it replace some tags / covers with the ones it finds on FreeDB?
what other unforseen consequences could arise from this configuration?
-
This seems like more trouble that its worth if you're expecting to make changes on any system.
MC will update its internal cover art thumbnail when it finds a new art file in your shared location.
MC2's database is not automatically updated with file tag changes are made by MC1, so you'll need to
- force Update Tags (from library) on MC1, and then
- do an Update Library (from tags) on each MC2 system
MC won't replace tags with external database lookups. Lookups such as this are only done when a new (to the library) CD is inserted.
-
I use this approach, but what I do is assume that my library is the master and is the only one allowed to update the files. On the other "client" I go through all the library fields and turn off the save to tags options. This means changes are only made to the local library and never the files, which keeps things clean. The actual files then only reflect MY library, which is how I want it.
-
If all instances of MC are set to write everything to file tags and to auto import the same folder, I think it is going to work for music files (mp3 and flac) at least. I do not know about video etc, or what will happen if two instances of MC try to write to the same file at the same time (if you should set all instances to analyse files at import for instance).
-
If all instances of MC are set to write everything to file tags and to auto import the same folder, I think it is going to work for music files (mp3 and flac) at least.
It does.
But sometimes it doesn't as changes made on library1 are not always refelcted in library2.
In pratice I only use 1 for the tagging.
-
But sometimes it doesn't as changes made on library1 are not always refelcted in library2.
Strange. I have only one instance of MC, but must sometimes use external tagging tools for certain tasks and I copy the music files with backup software to another location for use with Logitech Media Server for my Squeezeboxes. MC auto import picks up the changes made by external tagging tools perfectly, and all tagging done in MC is perfectly reflected in Logitech Media Server. This has never failed as far as I am aware.
-
As of MC17, one such problem has an implemented workaround:
http://yabb.jriver.com/interact/index.php?topic=66413.0 (http://yabb.jriver.com/interact/index.php?topic=66413.0)
but this won't help users of previous versions of MC.
There can be other problems. Consider an MC1 user updating some property and having MC1 update tags, for all 10,000 of your files. This will take a little time for the updates to reach the files, it happens in the background.
Now, a second MC2 makes some tag changes on the same files that MC1 made changes for. Some of those MC1 files may have been updated; some may not yet have been updated. MC2 writes the tags, updating the file.
What does MC1's background tag writing do? Overwrite MC2's changes? Skip MC1's changes?
This is called a Race Condition, and it is always possible to occur when two competing systems are not synchronized using effective locking mechanisms. And MC was not designed in this usage model to guarantee atomicity in this case.