Print

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

[csimon]

We've been porting to Linux and having some success...

Great news!

As you've pointed out, Linux devices tend to come in several flavours which are boxes dedicated for particular tasks. And
you can of course get a Linux PC which is analogous to a Windows PC or a MC, and you could just do a "simple" port to provide exactly the same MC on all 3 platforms.

However, a true separation of client and server functionality makes more sense in the Linux world. Some people may indeed have Linux PCs and want the entire product on that machine, but the the best example is the Linux NAS, on which the client components wouldn't make sense. It just needs to have a server product running, which handles the database and requests for reads and writes.

You then have clients on other devices, e.g. a manager interface for ripping and tagging, setting up views etc.  A renderer which plays requested media. A controller, etc.  Of course, the roles of these devices are very well documented, everyone knows what they are!

But the current MC has all of these functions integrated. I don't know how much separation there is behind the scenes in the code, but as far as I can see you can't install a server on one device, a renderer on another, and a controller on another, regardless of what platform.  You can't even do it on Windows.  you can't set up a server, and allow a client to connect to it for database management purposes.  Library server does not go far enough, it's clunky and limited. You can't connect two clients to the same library with full functionality on both.

XBMC and Plex went down the client/server route a long time ago and they are prolific on all platforms, even embedded in TVs and streamers etc, whereas MC is still tied to Windows PCs.

This opens some doors for JRiver...

Exactly!  Just as I'm saying. But I suspect the move to some sort of client/server separation requires a fundamental change in the core product, affecting the Windows and Mac ports, rather than just porting to Linux?  I don't know if what you're saying is simply a port to Linux or some sort of start to a change of structure and separation of "modules" within the product?

[csimon]

PS. NAS's as servers may not be powerful enough to handle transcoding.

In that situation, transcoding could be delegated to a "helper" PC maybe?

[JimH]

... separation of client and server functionality makes more sense in the Linux world. Some people may indeed have Linux PCs and want the entire product on that machine, but the the best example is the Linux NAS, on which the client components wouldn't make sense. It just needs to have a server product running, which handles the database and requests for reads and writes.

You then have clients on other devices, e.g. a manager interface for ripping and tagging, setting up views etc.  A renderer which plays requested media. A controller, etc.  Of course, the roles of these devices are very well documented, everyone knows what they are!

I don't see any practical advantage to splitting functionality.  If a piece of software is both a DLNA Server and DLNA Renderer, but only one is used, there is little disadvantage compared to discrete elements.

But the current MC has all of these functions integrated. I don't know how much separation there is behind the scenes in the code, but as far as I can see you can't install a server on one device, a renderer on another, and a controller on another, regardless of what platform. 

This works now with the OSX and Windows versions of MC.  Either can server and either can render.

You can't even do it on Windows. 

Can too.

you can't set up a server, and allow a client to connect to it for database management purposes.

Remote management is a different issue.  I realize you may think it's essential, but I don't think it is.  It would be nice.

[JustinChase]

I don't see any practical advantage to splitting functionality.  If a piece of software is both a DLNA Server and DLNA Renderer, but only one is used, there is little disadvantage compared to discrete elements.

One of many (HUGE) practical advantages is to allow all users to have/maintain their own separate libraries.  If the "server" is only meant to serve the data to the client, and the clients would have all the customization/rating/opinion of the media, it could easily be different for all clients.

Some examples have been given over the years, but here are a few again.  My wife and I have very different tastes in music, so keeping the ratings as part of "the library" on "the server" means one of us doesn't get music the way we prefer it.  Also, I have one library for the children, and another one for us, which shows ALL content/media we have.  Letting me choose which device gets which access would be most welcome.  Another reason is to keep the Linux 'server' install to a minimum.  taking away most options related to opinion of media, and putting that on (the probably more powerful) client will help in many low powerful server machines (think NAS).

There is no reason that MC can't be split into 2 parts, with both being included in the "normal" install, but giving flexibility to allow only the server part to be installed when one desires, and offers many advantages.  Well, I'm sure there are LOTS of technical reasons, mostly to do with restructuring the code, but the functionality seems to be mostly in place, it would just be a matter of 'breaking it up' in logical ways to allow the 2 parts to act as one, or separately.

[xynoe44]

I can see several advantages in working in server/client mode. The biggest ones:

1/ Dependencies management. I certainly don't want all the client side dependencies (Xorg/Wayland, UI Widgets, alsa, audio/video players, etc...) on a headless server/device if it can be avoided.
2/ Better separation of concerns. For example, right now, the configuration is pretty confusing (for a novice like me). Which options applies when running in server mode? in client mode? BTW, the same applies for zones.
3/ Easier upgrade/update process
4/ Flexibility. The server component can be run on architectures or devices that don't support the client component.

[apgood]

Same issue exists with xbmc. It is difficult to port it to nas device like unraid because it is designed to run with a full GUI frontend while the nas device (e.g. unraid) is command line based plus possibility of adding a webserver to run a webbased front end if necessary.

So option to just install it in server mode would be really useful for adoption / adapation to light weight Linux nas distros

[RoderickGI]

Remote management is a different issue.  I realize you may think it's essential, but I don't think it is.  It would be nice.

Yes, it would be nice. I am hitting that issue now with setting up and testing views, moving and renaming files, and other activities as I clean up the mess that is my media collection. I haven't even started on the music yet. 

With the commercial world embracing SaaS (Software as a Service), using very thin clients which provide full functionality, the whole technology is very well understood and mature. But it is hard to take an application written to run solely on a local machine (whether server, controller, or renderer) and convert it to a full Client Server structure. It takes years, and commitment in the form of dollars.

[ogs]

So option to just install it in server mode would be really useful for adoption / adapation to light weight Linux nas distros

This is how I hope to see MC for Linux. I have several Linux units running in my home network for various purposes. None of them with GUI. I use Windows on my desktops so I'd need to control settings on a Linux MC server from a Windows MC client GUI. At present I run MC on a headless Win7 installation. A client/server split would be very useful here too.

[imugli]

OK so I'm not the Linux-on-NAS guy, I'm the Ubuntu server guy, so a server module for debian/ubuntu is something I have been dreaming of for a LOOONG time. My server runs an overclocked C2D with loads of RAM (which should be OK for transcoding), while my HTPC (and current server) is a little Atom thing that has just enough grunt to do HD. In this instance, give me a command line to get it running and I'm good to go.

I also run ubuntu on laptops around the house, so sign me up for a client / gui version as well :-)

Great to hear you guys are going down this path!

[csimon]

I don't see any practical advantage to splitting functionality.

A HUGE advantage is that you can install a server on a headless NAS and use a client to maintain it.  You can then also mix-and-match components of the system which work best with your particular network and devices that you want to use.  I'm sorry that you do not see any merit in this, whereas lots of other people do, including replies in this thread.

No, it is not possible to install a server on one machine and a client on the other, because you have not got the components cleanly separated. And clients do not have full functionality unless they are also a server. This doesn't make sense.

MC is not a client/server system, regardless of the fact that you decided to call your products clients and servers. The complete absence of the non-essential (as you call it) remote management, and that fact that clients are crippled unless they are also servers, proves this. I'm having huge difficulty in keeping just two installations of MC in sync, this just shouldn't be the case. I should just have one server/database and then multiple clients that connect to it. None of this vague synching stuff on which I can't get definite answers on how it's supposed to work, and restrictions on which installations you can use to rip CDs on. A very common and sensible configuration I would imagine is a PC connected to your TV and audio system, in other words a HTPC, but unless you also use that PC to rip CDs with an have a keyboard and mouse handy in the living room, what it effectively means is that you have to have another PC switched on all the time.  It is not possible to use a HTPC as a server and use another PC occasionally to maintain it.

If I'm missing things in MC that everyone else finds simple, could anyone please explain how to keep two PCs in sync, in other words how to use MC as a client/server system, that does not involve manual synching or copying of files or otherwise irregular synching, and that doesn't require two PCs switched on?

[JimH]

A HUGE advantage is that you can install a server on a headless NAS and use a client to maintain it.  You can then also mix-and-match components of the system which work best with your particular network and devices that you want to use.  

That's a different issue than splitting the architecture.  You want remote configuration and maintenance, but that could be done without dividing the program into a client and a server.  Some of it is already done.

...  it is not possible to install a server on one machine and a client on the other, because you have not got the components cleanly separated.

That's like saying that left handed pitchers should have only one arm.

I do acknowledge that what you want is not what we currently do, but this has little to do with the separation of MC into a discrete client and server.

And what you want is not a small task.

[gvanbrunt]

I've heard this argument many times over it it makes no sense from a design standpoint. To stream video etc, you have pretty many "UI libraries" installed anyway as they are part of the process. To spend a pile of development time on taking out 1% of the code so it is "server only" is better spent elsewhere. Even if this were done, users will continue to complain as MC will "need all these different" libraries to run on Linux even though it is "server only". And then how do you configure it? From the console? A config file? More code needed for a very small gain.

And did someone say size? MC is probably a smaller install than most "server only" installs on any platform. 23MB in windows.  40 on mac. Most libraries are bigger than that on Linux.

Finally, there would be a pile of users complaining that "it don't run right on my NAS. Every time I stream it is jumpy etc".... These types of servers were not meant for transcoding or streaming. Many don't have the power for either as even streaming is very time sensitive compared to serving a file. As someone who has set up many Linux based VoIP systems, I see it all the time on their bulletin boards: users that don't have the hardware to run the system. And that is voice only (not video) and on hardware much more powerful than a typical cheap home NAS. I think many users assume that making it "server only" will somehow make it run better on light hardware. I don't think that is realistic.

[csimon]

And did someone say size? MC is probably a smaller install than most "server only" installs on any platform. 23MB in windows.  40 on mac. Most libraries are bigger than that on Linux.

The issue here is that a full-blown MC installation (even if you only want to run the server component) may not run on a NAS because it requires a GUI front-end etc. The idea is that you install the database server onto a NAS and then connect to it via a front-end from elsewhere.

And then how do you configure it? From the console? A config file? More code needed for a very small gain.

Err, from a client!  The current MC product already has client and server sides to it, but built into the one product, so we are told. So you install the full product somewhere and use its client bits to talk to the server. But what's becoming more obvious is that the client and server bits are in name only. If they were true client'server than you'd be able to connect to a server's library and make changes to it transparently without involving synching or going to the actual server to rip CDs.

Finally, there would be a pile of users complaining that "it don't run right on my NAS. Every time I stream it is jumpy etc".... These types of servers were not meant for transcoding or streaming. Many don't have the power for either as even streaming is very time sensitive compared to serving a file. As someone who has setup many Linux based VoIP systems, I see it all the time on their bulletin boards: users that don't have the hardware to run the system. And that is voice only (not video) and on hardware much more powerful than a typical cheap home NAS. I think many users assume that making it "server only" will somehow make it run better on light hardware. I don't think that is realistic.

Except of course that NAS's already do run serving and streaming products and have been for years.  For example, DLNA servers, iTunes Server, Plex Server, DVBLink TV Server (streams live TV over DLNA), Squeezebox Server, Serviio.  I think you've missed this!

My small NAS serves media without any problems or stuttering. Its only issue is the limited Artist/Album/Genre menus, which is why I like the customisation facilities of MC.

MC doesn't actually require a beefy PC, as has been pointed out many times before, even to render media. File serving and streaming is well within the limits of a small NAS.

File serving and streaming is actually what NAS's excel at and is their job.

Transcoding is a different issue - NAS's should be able to handle audio transcoding but video is more difficult, hence my comment in post #2.


I think what the team is looking at here is a complete port to Linux PC, and we probably ought to stop getting excited about an install on a NAS as it ain't gonna happen and this isn't their intention.

[JustinChase]

I just would like to remind everyone of something simple, that seems to be overlooked rather often in these discussions.

Server = One who serves

A server is not, by definition, a manager of opinion based information, a transcoder, a downloader, a tagger, a place for eye candy, or any of the other multitude of things that MC does.  Sure, it can do all those, things, and the way MC is currently designed, it does do all those things (which is why MC isn't called a server).

This discussion of client/server seems to get off track sometimes when this simple definition is ignored.  A server, if MC should every choose to create a server, separate from a client, should be designed/meant to ONLY serve data to a client.  Any and all clients should manage the configuration and movement of the data and opinion/customization of presentation of the data to the user, but the server should just sit there, and wait for a client to ask for something, then SERVE that something to the client.  If it can transcode, maybe that's good, but I think that's really the job of a client, mostly to allow the server to run on low powered systems.

It sounds like JRiver is not intending to separate MC into a separate client and a separate server, which makes me sad, but that's how it continues to appear to me.  If JRiver makes noises that this might become a possibility, I'm sure there will be many good ideas presented to help the process along.

[csimon]

I note that, in the original thread that this was split from, Jim did actually mention that MC's DLNA server might sit well on a NAS.

If that's the way it's going then that's great - however every NAS tends to have its own DLNA server these days and there are a number of other servers that you can download and install.  What's going to be special about MC's DLNA server and why single out DLNA Server for the NAS treatment? Presumably it will have to hook into MC's library structure and database, otherwise there's going to be no benefit over any other DLNA server.  In other words surely the library server needs to be on the NAS too.  Or will it require a Windows PC to run a library server which the NAS has to connect to in order to serve data to a client, which seems a bit overly complicated and missing the point of putting the server on the NAS???

What MC calls Library Server is basically what *I* mean by having a server component on a NAS.  In other words, a database server - something that holds MC's library and attends to requests from clients for data, whether that comes from a co-hosted DLNA server, a DLNA renderer or controller on the network, an MC renderer or controller on the network, or a database management interface.

Functions that cannot (and really shouldn't) be performed by the database server (e.g. video transcoding) could be performed by an "application server", i.e. the part of MC that can act as middleware between the server and the client.

[JustinChase]

In other words surely the library server needs to be on the NAS too.  Or will it require a Windows PC to run a library server which the NAS has to connect to in order to serve data to a client, which seems a bit overly complicated and missing the point of putting the server on the NAS???

What I'm suggesting is that the "library" become the "client", and everyone gets their own, and the only attachment to the "server" is that all clients know what media sits on the server.  The server is ONLY to serve the media.  There doesn't need to be any "application server" or "middleware" in any of this.  The server just serves whatever media the client requests, and the client does whatever is necessary with the requested media.

The client could be a windows client, a linux client, a mac client, an android client, a windows mobile client, whatever.  They all just connect to the JRiver server, and they all get to browse and arrange and categorize and tag and rate the media in any way that they wish, separate from all the other clients.  ideally they could share views and such, but wouldn't have to.  Howoever, the server should not care at all about ratings, or tags, or views, or anything like that.  It should ONLY manage the physical media, and serve it to any client that requests it, no matter the OS of the client.  That server could be a Linux server, a windows server, a mac server, whatever box anyone wants to install it onto, but it should be smallish and do nothing but serve media to clients.

[Louis]

> The server just serves whatever media the client requests, and the client does whatever is necessary with the requested media.
+1 Sounds like a great idea, this is the way the world is going as clients other than Windows proliferate and one becomes less bound to a single PC of old.

[JimH]

I think many users assume that making it "server only" will somehow make it run better on light hardware. I don't think that is realistic.

I agree.

[imugli]

Personally, I'm not concerned with whether the server module is integrated with client as it currently is or not. What is important is that it runs on a headless server, minus a GUI and can be managed remotely from a client.

[JustinChase]

I think many users assume that making it "server only" will somehow make it run better on light hardware. I don't think that is realistic.

I agree.

Really?!?!

You honestly believe that a program that needs to evaluate what media is available, including determining the way information is presented/viewed, transcode media based on virtually infinitely configurable settings, including zone management, 16 plus channel surround processing, equalization, R128 processing, tag writing, displaying audio and images simultaneously, and much more will run the same on "light hardware" as a program that simply streams ones and zeroes to another program?

I know you can't believe that's true.

A server, doing nothing but delivering data to a client can run on pretty much any hardware.  I've seen many posts of people not able to playback media smoothly on decent machines, due to all the processing they are trying to do.

I think the 'issue' here is the different definitions of "server"; which is exactly why I provided the simple definition earlier.  Server should ONLY stream media to clients.  My router can do that, with the most basic hardware inside.

[JimH]

Really?!?!

You honestly believe that a program that needs to evaluate what media is available, including determining the way information is presented/viewed, transcode media based on virtually infinitely configurable settings, including zone management, 16 plus channel surround processing, equalization, R128 processing, tag writing, displaying audio and images simultaneously, and much more will run the same on "light hardware" as a program that simply streams ones and zeroes to another program?

Yes, because the server could be set to do a analysis or not.   Having the capabilities doesn't mean they have to be used.

You're talking about a file server.  There are many kinds of servers.

[JimH]

Personally, I'm not concerned with whether the server module is integrated with client as it currently is or not. What is important is that it runs on a headless server, minus a GUI and can be managed remotely from a client.

Yes.  That's a reasonable goal.

[JustinChase]

Yes, because the server could be set to do a analysis or not.   Having the capabilities doesn't mean they have to be used.

You're talking about a file server.  There are many kinds of servers.

Yes, I agree, a 'file server' is pretty much what I'm advocating here.  Take all the analysis, management and customization off of the server, and just let it serve files to MC clients.  Put all the work on the clients, and let each client work with the server in it's own, customizable way.  This gives us custom libraries, and full control on each client, and a small footprint for a server that can be installed in very basic, low powered hardware.

I'll be honest, I've been using the client/server model MC has had since it was available, and I'm still confused by where to set different settings, to get the work done in the 'right' place.  There's settings on the 'server' and also on the client, and they are all the same settings.  Which one takes precedence, which way is most efficient, what gets over-ridden by what, what connection type allows clients to make permanent changes, and which way only allows sessional changes?  I know some of these answers, but most people don't and it's not nearly as easy to manage as if it was all fully and completely separated.  I imagine it will be a lot of work to fully separate the code, but is it really that much work?  You've re-written the entire code base to be OS agnostic already, and that had to be a TON of work, and I can't imagine this would be nearly as difficult.  I don't think you'll have to re-write very much code, but would mostly be re-organizing it, and tying it together differently, but you already have all the pieces in place to do everything.

Anyway, I realize you have priorities, and I'm not trying to force you to do anything, I'm just trying to clarify what I think many people want when they refer to a client/server system; which is NOT having both the client and the server installed on every machine.  That's less efficient and less flexible than fully separating them.

With all that said, I do realize that there are probably some folks that do want the server to do all the work, and want to have very low powered client hardware, and this might not be a great solution for them.  Having the server do all the heavy lifting might be required for that situation, which means you probably should allow the server to do this work, but that still doesn't require the server to manage the "Library" portion of MC.  The settings, the views, the ratings, the configurations, and that type of 'opinion based' stuff should not be part of "the server" per se.  It could be stored on the server, but I think each client should have the ability to experience the media in their own way, no matter how anyone else wants to experience it.  I think views and expressions and smartlists and all that personal customization should be sharable, but not forced on everyone based on the settings of one "Library Server".

It's not a simple topic, I realize that, but I think there are better ways of separating these things that provide better flexibility and functionality, without losing capability.

Hopefully this constructive conversation continues to progress.

Thanks for listening.

[terrym@tassie]

Personally, I'm not concerned with whether the server module is integrated with client as it currently is or not. What is important is that it runs on a headless server, minus a GUI and can be managed remotely from a client.

+1 to this

[RoderickGI]

You're talking about a file server.  There are many kinds of servers.

Wow. So much confusion about what servers are and what they do. Well, I guess "servers" can be configured in many, many ways, and the type of applications that use servers of some sort can define what the term means. There are file servers, data servers, database servers, application servers, client servers (Yes, how about that to confuse this discussion. Think about what Citrix does.) and lots more and just about every combination of the above.

What I think we should all remember is that many of the "clients" that we want to use with MC will have very little power, and that will become more the case in the future. These are known as Thin Clients and only present the data sent to them on a screen. ALL other processing happens on some "backend" hardware, usually known as an Application Server. In the case of MC, that needs to be the transcoding of media to a format that the thin client can present.

Think about streaming content to mobile phones of any variety, to a tablet, to a NUC or Raspberry Pi, to a TV, to a roll-up wall mounted OLED screen. None of those is going to, or should;
"evaluate what media is available, including determining the way information is presented/viewed, transcode media based on virtually infinitely configurable settings, including zone management, 16 plus channel surround processing, equalization, R128 processing, tag writing, displaying audio and images simultaneously, and much more"

Of course those thin clients would not be required to do all of the above, mostly because their screens are too small or they don't have the input devices required, or have the hardware to rip discs, and so on. But it would be nice if a PC client could do full management of the media content, perhaps even ripping discs and any other tasks that might normally be managed on a single box installation.

Yes.  That's a reasonable goal.

I'd be happy with just full management from a remote GUI client. If the backend was configurable into a single box, or multiple boxes with different components on each, that would be fine.


There is also a different issue of having settings and preferences for each user, which may be equivalent to each client hardware device, or may not. Using just a backend file server for MC and full clients each with their own database/library would result in lots more maintenance, as each library would need to be maintained, and I would ask; "If Genre is stored as a tag in a music file, which client gets to define the genre?"

[JustinChase]

There is also a different issue of having settings and preferences for each user, which may be equivalent to each client hardware device, or may not. Using just a backend file server for MC and full clients each with their own database/library would result in lots more maintenance, as each library would need to be maintained, and I would ask; "If Genre is stored as a tag in a music file, which client gets to define the genre?"

'lots more maintenence' compared to what?  if structured right, all views and settings and smartlists could be shared amongst some/all clients.  As it is today, i have to maintain the views and theater views and smartlists and options and everything for every library separately.  and even with all of that, i can't consume my media at the same time my wife consumes her media, without one of being forced to use the opinions of the other, meaning one of us is not enjoying out media the way we want to.

As for storing tags in files, obviously only one client could define this, and that would have to be the administrator account.  That would be the same account that determines who can see what views or types of media or whatever.  Someone has to manage everything anyway, so that might as well be who defines tags.  I suppose they could allow that to be done by another client, but MC would need to be smart enough to only allow one client to write to tags, and if any client other than that client connects to the server, that option should just not be presented to them, or it should be greyed out (I prefer not presented, but I'm not stuck on that).

Again, I'm not saying my way is the best/only way, and I'm very happy to see more discussion on this topic, I believe it will help get MC to a better place down the road.

[RoderickGI]

'lots more maintenence' compared to what?

Lots more maintenance than having one library shared by all users and all clients, which is what I have, and it seems was the intent of the MC design, although separate libraries can be opened at separate times. The fact that the library is stored by default under the creator's User directory and so each user who logs onto the server accesses a different library does muddy the issue somewhat of course. I'm really not sure what the thought process was behind that decision. It was probably appropriate at the time.

But as I said, the issue of having different settings and preferences for each user is definitely separate to the Client/Server issue. I understand that it is an important issue to you as you have mentioned it elsewhere, but solving that problem would require some different design changes, such as including the creation of Users in MC (or allowing the operating system Users to be referenced internally), holding multiple values for each field in the library tied to the user, allowing the flagging of Users against library components similar to Permissions in Windows or Unix, and maybe allowing true multiple user sign-ins or connections to the hardware holding the library, such as on a true server, rather than a Windows 7 PC for example. Plus no doubt a bunch of other stuff.

Sorry, but it is a different issue and would require a lot more work, essentially making MC a multi-user system.

[JustinChase]

essentially making MC a multi-user system.

which is exactly what I'm requesting

[RoderickGI]

which is exactly what I'm requesting

Okay then. 

[csimon]

Yes, I agree, a 'file server' is pretty much what I'm advocating here.

I think "file" server is a little too simplistic here though as, if taken literally, MC already delegates all file handling to a file server. It doesn't care where your files are held, whether they are database files or media files. It lets the OS hande all that sort of stuff. You can already store files on a file sever and it is completely transparent to MC.  File Server is one of the fundamental services in every OS, whether it's Windows, Mac, or a Linux NAS.

I think what we are talking about here is a database (library) server. To talk about specifics, I don't know what sort of database MC has, but for the sake of argument let's assume it's an SQL-based database such as mySQL. I would like to see the database/library service of MC installable at a single, central point for use by all installations of MC. At the moment, each installation has its own database and behaves as its own server. You then have to talk about enabling library server on a machine and linking to it and synching the librarires at regular intervals...  Yeuch!  that should all be unnecessary. There should be no separate database on each installation of MC. There should be no database access done by any clients. They should all connect to a library server and do reads and writes via the server.  Or maybe SQL commands are indeed generated by the client but they are passed to a database server that is defined by a connection string rather than hardcoded to a local database.

That server may well indeed run on the same machine as your client but the key is that it is functionally isolated from the client functionaility.  As long as each module of MC (e.g. renderer, ripping and tagging, controller) has a connection string to the database server, it doens't matter where on the network you put the database server. And the big advantage - I can not stress this renough...the BIG, HUGE, MAJOR advantage of this is the you have one central, single database and library (or more correctly, the single MC database contains multiple libraries) that doesn't need to be synched and every client access exactly the same information at the same time, no update anamalies or sync issues, it's all done in real-time.

I would like to point out that database services are indeed something that a NAS can handle well. Look at Synology NAs's for example and look at the range of packages that are isntallable. It's a compolete Linux server insrtallation remember, albeit running on a low-poer device, but it's not unheard of to run typical LAMP configurations for web services, mail servers, and other productivity-oriented services, all on a NAS.  Please look at http://www.synology.com/dsm/dsm_app.php?lang=uk for an idea of what NAS's are capable of!

If the library server was a separate module, people could choose where they want to put it. Some people may have Mac servers, or Windows Home Server, or a Linux NAS, where they already have their central file services.  A dedicated machine for a dedicated task. On the other hand, if they want a single machine for MC then they still can do it but when they want to expand their network with more than one installation of MC then it will be easier than at present, as they can leave the database server in one place and not have to have several instances of it and have to try and keep them in sync.

I'll be honest, I've been using the client/server model MC has had since it was available, and I'm still confused by where to set different settings, to get the work done in the 'right' place.

I agree, I'm the same. As I've mentioned before, I too am still struggling with how to set up two PCs that are looking at the same library. This should be fundamental. There shouldn't be a "right" place to do a particular task, you should be able to do anything from anywhere.


There will be many discussions and debates about where to put individual bits of functionality - you can have thick clients and thin clients, thick server and thin servers I guess!  You can have several different abstraction layers in a client/server model - I've talked about middleware, or application servers. This sort of thing may be over the top but when you think about it, it's actually quite logical and most probably MC is already structured internally in this way - messages being passed between various modules etc, a communication protocol. It may be helpful to focus on what the current problems are with MC, or what issues people are facing, that may inform what bits are best to pull out into a separate "server". These are some of the things that I'm finding difficult or impossible or logically vague:

1. Maintaining the library (rip and tag, create views etc) from a "home office" PC which is not on all the time. (clients should be able to maintain the library with as much functionality as the server)

2. Keeping two or more copies of MC in sync. (each installation shouldn't have its own physical database and changes should be instantly available on all clients)

3. Understanding which "server" to connect to and how to actually set this up, when you've got a handheld remote like JRemote but two or more MC PCs.  (there shouldn't be a need for more than one server of a particular type on the network!)


Whether the library/database server needs to go as far as answering queries from clients such as "what albums do I have?", "what MC zones are available on the network?", or whether that functionality is worked out by the clients, is open to interpretation!

[EDIT: I'm not saying that a separate database server in particular would solve this problem, but this current thread just shows how MC's "media network" is convoluted and not easily configured or understood, I've certainly given up on trying help this guy becaiuse I don't know what to advise and I'm confused by MC's current client/server functionality too: http://yabb.jriver.com/interact/index.php?topic=81262.new;topicseen#new - his issues are basically the same as the three issues I've detailed above, he's having problems with having to logon to a headless server to do updates, and getting confused about enabling servers and synching between them]

[csimon]

There is also a different issue of having settings and preferences for each user, which may be equivalent to each client hardware device, or may not. Using just a backend file server for MC and full clients each with their own database/library would result in lots more maintenance, as each library would need to be maintained, and I would ask; "If Genre is stored as a tag in a music file, which client gets to define the genre?"

The answer is "any or all of them"!

Physical file tags are inherently not multi-user!  This is a problem that MC can't really address, but I guess it would be possible for the user to decide for themselves by not allowing MC to store data in physical file tags, that way they could indeed set up different libraries if they want different people in the same household to have different opinions on genres and other classification information. It's a lot of maintenance, but that's fine, if that household wants to do it that way then it will indeed be a lot of work for them. How can they do it at the moment?  Duplicate the entire physical media file library for each person and have separately maintained installations of MC and databases? Or just define separate libraries?

Multi-user is not the same thing as multi-library, although multi-user can be simulated via multi-libraries.

[EDIT: Multi-seat is something different again!  Each PC can have its own hardware, and theoretically each user should be able to set up their own preferences for each individual player/renderer/admin UI.]

[RoderickGI]

The answer is "any or all of them"!  . . . <snip>

Yep, I pretty much agree with all that. But after all this discussion I get back to your original implication that;

We've been porting to Linux and having some success.

= Client/Server

I don't think Jim's announcement supports that implication. "Porting to Linux" ≠ "Client/Server".

Anyway, I guess we have expressed our opinion. Obviously the people who created Plex agree with us, but it seems that Jim and Matt don't, yet. That's okay for now, although it would be nice to have full remote management sooner rather than later, with or without a Client/Server implementation.

[csimon]

Yep, I pretty much agree with all that. But after all this discussion I get back to your original implication that;
 = Client/Server

I don't think Jim's announcement supports that implication. "Porting to Linux" ≠ "Client/Server".

No....except the tantalising hints about putting DLNA Server on NAS, other media devices (not necessarily computers) that run Linux, Linux opening doors for JRiver, networked home, store in one location-play on another! Small media devices and specialist devices like that are not goiung ot be able to run a full implementation of MC as it stands at the moment. So it all started to sound like soem sort of structure change - someone's latest comment has sort of assumed that too - "Add me to the list who are looking forward to running MC as a server on unraid, for Mac/PC clients." - which, if it's just a port to Linux, is not going to be possible in the way they think it is, it'll just be like the current product but on Linux and it won't be possible to manage the server from a client.  But I did add a question at the end: " I don't know if what you're saying is simply a port to Linux or some sort of start to a change of structure and separation of "modules" within the product?"

[JimH]

No....except the tantalising hints about putting DLNA Server on NAS, other media devices (not necessarily computers) that run Linux, Linux opening doors for JRiver, networked home, store in one location-play on another! Small media devices and specialist devices like that are not goiung ot be able to run a full implementation of MC as it stands at the moment.

Please don't make such absolute statements.

a.  there is yet no implementation of MC on Linux
and
b.  you may not fully understand the internals of MC
and
c.  we don't know what hardware will be used

Give us a little time.

[csimon]

I'm not, your first message hinted at the possibilties therefore I ended my post with:

" I don't know if what you're saying is simply a port to Linux or some sort of start to a change of structure and separation of "modules" within the product?""

in order to try and find out what you meant by all those hints, but there was no answer except negativity towards client/server in general and that you don't think that remote management is an issue.

I have never said that you have said that you are considering client/server, please don't make such statements.

[JimH]

I don't know if what you're saying is simply a port to Linux or some sort of start to a change of structure and separation of "modules" within the product?"

We're porting to Linux.  It might involve some structural changes, but it's too soon to say.

[JustinChase]

It might involve some structural changes, but it's too soon to say.

Thank you for being open to the possibility.  There are many great minds in this community, so I'm sure you'll continue to get lots of feedback, if you ever need/request it from us; hopefully most of it will be useful

[Samson]

Hi Everyone,
I'll weigh in here as merely an end-user without any technical expertise,simply looking at function. What I would like is:

1) Have an option for a Client MC that totally controls all read/write capabilities on the server....same tagging,same options, same everything,what you change on the client happens on the server.The only difference, from an end-user perspective, would be media plays (is rendered) on the client machine.   I achieve this currently by using a remote desktop application over the network but it is clumsy for things like viewing video.

2) Have a Client version that only reads the server library, is rendered on the client, but maintains all its own separate write capabilities for tagging,options...ie makes no changes whatsoever to the main server library.This would be for family members to use and have their own preferences,options, ratings etc.If they added files to the common media storage location it could be in their own directory or in a commonly accessed directory.Import rules would be separately maintained.

The current arrangement seems to be a hybrid of the above two which seemed to me a good idea but the reality is I get confused as to what the client can or can't do eg if setting the cache location for a handheld sync on the client, turns out its the server that determines this......similarly using Library tools don't seem to work when used on the client.....

Cheers
David

[flydeep]

++1 - will likely have on two Linux systems, do I get an extra vote?

I have an UNRAID system and will build another one in near future if MC can be installed in a server headless mode. I like the concept of having a centralized library with user read/write permission (the new multi user feature could be handy for this).

For eg: For my machine I want to have ability to change the library but for the parents/kids machine they just need to access the library and nothing more.

Will we be notified when a Linux version becomes available?

We're porting to Linux.  It might involve some structural changes, but it's too soon to say.

[fitbrit]

Yes, if I could run MC on unRaid and never have to keep another HTPC on 24/7, I will be so happy!