Print

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

[lalittle]

I searched the help and the forums, but I'm still not clear about the specific changes that are made when doing a "library sync."  Is it just the actual "files" that are kept in sync, or do changes made to things like view schemes also get "synced" back to the server?  Just how many "areas" does the library sync effect?

Also, how does the library sync handle changes made to the same "item" on both systems?  Does it track each individual change on both systems, or does it just look at media file and/or library file modified times?  If I change the genre of a song on the client, and later change the name for the same song on the server and do a library sync, do I end up with the new genre AND the new name, or do I just end up with the new name given that this file has the most recent date?

Finally, does the client need write permission on the server's drive in order for it to work?

I'm going to do some testing, but I wanted to ask here also just so I don't really mess things up.

Thanks,

Larry

[lalittle]

Does anybody have any feedback on these questions?  The official help and wiki really doesn't address these questions.

Thanks,

Larry

[JimH]

It's the server's job to write changes, so the client doesn't need permission.

Right now, whatever you have done on the client will determine what changes are made when you sync.

Eventually, we plan to make the sync more automatic.

[lalittle]

I noticed some fixes to the Library Sync feature in recent builds, but I'm still fuzzy on some of the specifics of this feature.  Can anybody help me to understand more about this?  I posted some questions in the MC14 forum a couple weeks ago, but didn't get any responses, so I'm hoping I have more luck here.  Note that I did search both the help system (wiki) and forums, but could not find the answers to these questions.

1)  What specific changes are made when doing a "library sync"?  Is it just the actual "files" that are kept in sync, or do changes made to things like view schemes also get "synced"?  Just how many "areas" does the library sync effect?

2)  How does the library sync handle changes made to the same "item" on both the client and server systems?  Does it track each individual change on both systems, or does it just look at media file and/or library file modified times, or does it only work in the client to server direction, or...?  If I change the genre of a song on the client, and later change the name for the same song on the server and THEN do a library sync, what happens?  Do I end up with the new genre AND the new name, or do I just end up with the new name given that this file has the most recent date, or...?

3)  Does the client need write permission on the server's drive/s in order for it to work?  If so, which drives and/or folders would need to be included?

4)  Does it make a difference if I select "Sync Library" on the client as opposed to the server -- i.e. does the system used to start the operation make any difference?

5)  If I do NOT want a client system to be able to make changes on the server (even if somebody selects "Library Sync"), is there any way to actually PREVENT a Library Sync from making changes to the server?

Thanks for any feedback on this,

Larry

[park]

1. Playlists and all tags get synched. Viewscheme changes do not.

2. Matt said that the most recent computer to make a change to a file wins, so if two computers made a change to the same file, the last one to sync would overwrite that file's library data. I assume that means not just for the specific tag that was changed, but would write all the tags in that file.

3. No.

4. I think so. I think you are supposed to sync from a client and the server gets updated. I dont think it's possible to sync all clients to a server from the server itself.

5. No.

Make sure you download the latest build (.61) since there was a bug in recent builds that meant tags werent being synched. I found out after doing 5 hours of tagging (carefully syncing every 20 minutes), and then booting up the next day and seeing it all gone. Please dont share my pain.

[MrHaugen]

5)  If I do NOT want a client system to be able to make changes on the server (even if somebody selects "Library Sync"), is there any way to actually PREVENT a Library Sync from making changes to the server?

I really hope this will come one day. To have a client with MC, in any place there are several people not to familiar with MC, could potentially be a disaster.
I've said it before and say it again. If MC really want to shine in a multi client setup, some form of lock down have to be in place. Preferably a way to log in to Theater View with user or groups with simple Access control. Read or write access to each big media groups would be good (Audio, Video, Images).

[lalittle]

Thanks for writing me back on this -- it prevents a lot of headaches and saves considerable time to learn the critical details of a feature before just trying it.

It's the server's job to write changes, so the client doesn't need permission.

Are you saying that anybody using a LS client can make changes to the server's library?  This seems like it opens up a rather large potential security issue.  I like to have client access to my main library system, but I do NOT want every client system to be capable of making changes, especially when I'm testing for various bugs.  I have both "test" libraries and my "real" library, and I'd hate to mistakenly make changes to my "real" library.  Is there any way of telling the server to ignore client based changes?

Right now, whatever you have done on the client will determine what changes are made when you sync.

It seems like there could be a fundamental problem with this approach.  When I make changes on the server, it is NOT reflected on any client that is running when these changes are made until I reload the library on the client.  Couldn't this lead to a situation where I make changes on the server, then later made some changes on a client and do a sync.  If the client system determines the changes, won't this erase any changes that I had previously made on the server?

Eventually, we plan to make the sync more automatic.

Being able to edit from the client is nice, but it seems like a feature this powerful needs some options to prevent "accidents."  A confirmation before changes are made should definitely be included, but I would also advocate the ability to turn OFF the sync capability on the server end.  This would be for people that don't want to worry about changes being made by people that don't know what they are doing.  This is essentially the way it worked in earlier versions of MC, where the client didn't have the power to do any "damage" to the server.

Thanks,

Larry

[lalittle]

I really hope this will come one day. To have a client with MC, in any place there are several people not to familiar with MC, could potentially be a disaster.
I've said it before and say it again. If MC really want to shine in a multi client setup, some form of lock down have to be in place. Preferably a way to log in to Theater View with user or groups with simple Access control. Read or write access to each big media groups would be good (Audio, Video, Images).

Thanks for the feedback.

However this "security" situation is handled, I don't think the solution would be to simply "lock down" the server entirely.  It would get really tiresome to have to "unlock" the server every time we wanted to make a simple edit like fixing a typo, and then to have to remember to lock it down again (we actually already have the "party mode" for completely locking changes out.)  I think what we need is the ability to lock out changes made from CLIENT systems while still allowing edits to be made locally on the server itself.  This way, the user of the actual server system could continue to make edits as usual without having to worry about a client making unwanted changes.

Perhaps it would work to have a checkbox on the "Library Server" settings page that said "Allow editing from Client system."

I agree with the previous post that the library sync feature opens up the potential for real problems -- it's just TOO powerful to not offer a way of preventing it.  If I can't prevent changes made from a client, I'll seriously have to change how I currently use Library Server.

Larry

[DWAnderson]

Isn't Party Mode supposed to address the issue of clients not making changes? Party Mode, however, does not seem to prevent changes when a Library Sync is done.

[lalittle]

Isn't Party Mode supposed to address the issue of clients not making changes? Party Mode, however, does not seem to prevent changes when a Library Sync is done.

Even if Party Mode DID work to stop library sync changes from the client, it would be an incredible pain to have to turn Party Mode off just to make a minor change to the library on the server (like fixing a typo), and then to have to remember to turn it back on again.  On top of this, you'd have a situation where any time you wanted to make changes to the server's library, you'd be openning the library up to the security issues we're talking about.

What we need is a server side setting that locks out changes from the CLIENT without interfering with changes made on the server itself -- some sort of "Allow Library Sync" checkbox in the Library Server settings.

Larry

[DWAnderson]

Even if Party Mode DID work to stop library sync changes from the client, it would be an incredible pain to have to turn Party Mode off just to make a minor change to the library on the server (like fixing a typo), and then to have to remember to turn it back on again.  On top of this, you'd have a situation where any time you wanted to make changes to the server's library, you'd be openning the library up to the security issues we're talking about.

I think you could get the same result if party mode worked properly: run each MC client with a command line parameter (that could be built into a Windows shortcut) that runs MC in Party Mode.

Even with MC as-is now, I think you can get the same result by running MC on the clients and having them access the library from a network share rather than through library server. If the server PC already is already running MC then the clients open the library as read only automatically. In fact, I believe there is even a command line parameter (suggested by me and added in a prior version of MC ) that lets you force the clients to open the library on a read only basis.

[lalittle]

I think you could get the same result if party mode worked properly: run each MC client with a command line parameter (that could be built into a Windows shortcut) that runs MC in Party Mode.

But this would rely on the client system to "self impose" the restriction.  This is far less secure than allowing the server to prevent external changes to it's own library.

Even with MC as-is now, I think you can get the same result by running MC on the clients and having them access the library from a network share rather than through library server. If the server PC already is already running MC then the clients open the library as read only automatically. In fact, I believe there is even a command line parameter (suggested by me and added in a prior version of MC ) that lets you force the clients to open the library on a read only basis.

Aren't' there significant differences to this compared to using Library Server?  I searched the wiki for info on sharing libraries between systems, and all the information I found talked about using Library Server for this function, so I'm not even clear how the "Network share" thing works.  I think the bottom line is that Library Server is the "normal" way of doing what we're talking about, so this is really where the security needs to be addressed.

Thanks,

Larry

[jacky]

I think you could get the same result if party mode worked properly: run each MC client with a command line parameter (that could be built into a Windows shortcut) that runs MC in Party Mode.

Even with MC as-is now, I think you can get the same result by running MC on the clients and having them access the library from a network share rather than through library server. If the server PC already is already running MC then the clients open the library as read only automatically. In fact, I believe there is even a command line parameter (suggested by me and added in a prior version of MC ) that lets you force the clients to open the library on a read only basis.

By sharing the Library database and other library files from a central network share among multiple PCs, has anyone encountered any file contention access problems? I'm asking because, I am curious as to whether there will be any file locking problems if more than 1 media center is accessing the same library simultaneously.