Print

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

[gvanbrunt]

I agree with Samson. Part of the confusion is that MC running as a Client to a Library Server is really more of a server that "sometimes get the Library to stream content to it" than a client. It basically runs on it's own and tries to do things without "talking to the server". For example:

 - You update some library information on a file and it doesn't sync right away. So it may or may not get written back. I've lost lots of tagging changes this way. So much so that I gave up doing it on the client. (Yes I know you can force a sync, but that doesn't work if something locks up your computer)

- You can't really move files on the client unless the file paths are available to it. Move/copy should be in the context of the server and not the client.

- Tagging of files doesn't happen if the files are directly available to the Client.

- lots, and lots more...

Basically it is really confusing for users because this isn't a true client/server model. I think the design intent was that it can work without having to burden the server computer with everything. It also allows the client to get files without the server streaming them. Which is good, but not worth the other issues. Additionally I think the current model makes adding features more difficult. Security for example. We've been asking for user based security for a long time which on the surface seems simple but not so when clients are in play.

[csimon]

This isn't the current model, and it's not one I would want.

For me, a client is a separate computer that needs separate settings, DSP, etc.

The only settings that are hardware related are the audio and video facilities.  Settings, views and such things are not necessarily PC-based, but might be user-based or library-based.

It would be great to see sync add support for more actions on the client like view customization, file importing, etc.  However, if you just want to use the server remotely, you might be best using Remote Desktop or equivalent.

The "sync" stuff is what's limiting and confusing everything and is so complicated and possibly unreliable [see marko's post above].  There shouldn't be a need to sync stuff here and there and push things and pull things - a client/server model would access things remotely and directly. Client/server is tried and tested in the rest of the networking world, it does actually work. One basic network database principle is to only have one master -trying to keep two or mor local databases in sync is a nightmare.

MC should evolve as a true network system, the ability to use and install MC anywhere, send to any devices anywhere on the MC "network", and read and write to the household's central MC database. A peer-to-peer synching system is not up to this task. Suggesting the use of Remote Desktop to do things on a "server" because there isn't a client for it is really from decades ago.

[JimH]

Please don't start up the client/server argument again.  There is no definition of "true" client/server.

[Castius]

Regarding sever/client besides requiring to logging. I would agree with Matt. Adding just a few requests is enough. It was nice having a subsonic server. But the client suffered because it needed to be both.

Basicly, I'd rather see improved features than talk about what it is or isn't.

[Matt]

MC uses a network model where a client works at full speed with local data and merges changes with a master server.

A lot of highly successful network systems work this way.  Subversion (SVN) is one amazing example of this model that I use daily.  Evernote is another example.

I believe strongly that this is the best networking model for something like MC.

[JimH]

I'll merge this with the other similar thread.

[MrHaugen]

I agree that the sync could involve more things like image and path editing. so you could use the clients to do actual tagging. But other than that, I do not know. I don't know if it's really needed to sync all settings. It would be a huge task, and I do not believe so many need this?

[Matt]

There is no definition of "true" client/server.

We occasionally get pushed to do a "true this" or "true that."

In my opinion, these statements come off as a little pretentious.

It's a little like: "Jim, that's neat that you're painting.  Have you ever thought about becoming a true painter?"

It's great to brain-storm about ways to improve (there are a lot of things we could do better!).  But it's important to remember there's seldom a single correct answer.  

In some ways, engineering is about weighing a lot of requirements and picking the best compromise.  No path will ever meet all requirements perfectly (at least if time, money, opportunity cost, etc. are listed with the other requirements).

[preproman]

I guess what seems to be needed is the devs make MC a service on a file server (NAS)  ie unRAID and others.  

This way the file server (NAS) would be one of choice, make MC run on that server as a service like Sick Beard, SABnzbd and I think Plex is having success doing this as well.  
The clients would be each pc on the network.  No PC will act as a server and a client at the same time.  The database (one of them) will reside on the file server.

This will take some development in Linux.  This may be what the issue is..

[JimH]

No PC will act as a server and a client at the same time.  The database (one of them) will reside on the file server.

There is no reason that a PC can't act as both at the same time, and I can think of some cases when it should.

[gvanbrunt]

We occasionally get pushed to do a "true this" or "true that."

In my opinion, these statements come off as a little pretentious.

It's a little like: "Jim, that's neat that you're painting.  Have you ever thought about becoming a true painter?"

It's great to brain-storm about ways to improve (there are a lot of things we could do better!).  But it's important to remember there's seldom a single correct answer.  

In some ways, engineering is about weighing a lot of requirements and picking the best compromise.  No path will ever meet all requirements perfectly (at least if time, money, opportunity cost, etc. are listed with the other requirements).

Ok, so change my post to read "pure client/server" model" or "traditional client/server". That is actually what I meant.

I don't disagree that there are many advantages to the way the hybrid model MC currently has. I'm not suggesting changing that. What I am suggesting is changing its' behavior to be more the model that that everyone is familiar with - at least in how it appears to work. If the rendering can take place on the client and take a load off the server, that's fantastic. However when I tag files I expect the Library to get updated and that would include the tags as well. It shouldn't matter that the client has no direct access to them. As a user I shouldn't have to think about if the client has direct access to the files paths or not.

[Matt]

However when I tag files I expect the Library to get updated and that would include the tags as well.

This happens today.

More here:
http://wiki.jriver.com/index.php/Library_Server_Sync

[Castius]

Nice!

Will we have control over what is synced?
I'm not keen on File deletes. At least until we have user profiles.

File adds (server adds always go to clients, client adds go to server if the server can reach the file)

I'm guessing this means still no cover art or file upload outside the local network?
I know this is not an easy task. But with MC passing data between server and client i would think it would be a little easier to add.
Do you mind explaining why?

[csimon]

We occasionally get pushed to do a "true this" or "true that."

In my opinion, these statements come off as a little pretentious..... But it's important to remember there's seldom a single correct answer. 

If you Google for "client server definition" you'll get the "true" meaning, and there is only one definition.

[csimon]

There is no reason that a PC can't act as both at the same time, and I can think of some cases when it should.

That's absolutely correct.  Servers and clients are actiually programs and they can run on the same machine at the same time.  The crucial bit is that functionally they are separate and they communicate by messaging protocols, i.e. some sort of API.  That way, they can be installed separately anywhere on the network for efficiency or any other reasons as particular circumstances dictate.

[flac.rules]

The most glaring problem with the server/client model of MC for me so far has been that you can't have "map" many libraries from the same server on the client. So if you use more than one library, the whole server-client way to do it is a not very good solution from the get-go, i would love to use the server-client functionality.

[preproman]

There is no reason that a PC can't act as both at the same time, and I can think of some cases when it should.

Please share.. 

In a home with mulitple clients.  there should be one centralized file server (NAS).  The other clients should be reserved for client duties not server duties.  I can keep pointing to my unRAID box. No other PC on the network has the same duties as the unRAID box (NAS) nor should it.

[JimH]

What you describe is one way to share.

Peer to peer is another way.

[gvanbrunt]

This happens today.

More here:
http://wiki.jriver.com/index.php/Library_Server_Sync

So you are saying tags will get written to files from a client even if the client doesn't' have access to the file path? I know the library gets updated but the tags never used to in this case. If this has changed I missed it in the release notes when Client Sync was being added way back when... (Was that in MC 16 or 17?)

I'll have to play around with this more and give it another chance.