INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1]   Go Down

Author Topic: Further Client/Server development?  (Read 13606 times)

Mars

  • World Citizen
  • ***
  • Posts: 199
Further Client/Server development?
« on: October 24, 2011, 11:08:23 am »

Just moving some comments to a new thread  ;)

What about the ability of accessing and managing the library (Importing, Tagging, Renaming, Dragging'n Dropping, ...) simultaneously from any PC at home (or outside home)?

Maybe with an actual Client - Server system, with full control of the Data Base from the client side based on User/Permissions policies . Just like in many companies' systems, where DDBB are stored in the Server, usually located in a separate room and only manipulated by the IT's for maintenance, and data are introduced and accessed from the client work stations. I would reproduce the same scheme at Home, with my HTPC being the Server, hidden in a cabinet by the TV, even without physical keyboard or mouse, where Data Base would be stored and managed from the rest of the Client devices (Laptops, PC's, Tablets, Phones...).

Or maybe with a Web interface (call it WebTag as an addition to WebPlay and WebRemote) also based on User/Permissions policies, with the ability of editing the Data Base (Importing, Tagging, Renaming, ...) from any other device.

"Feeding" the library from the client side has been widely demanded.

I guess database real time multi users updates must be difficult to implement. It may require an external database engine, such as PostgreSQL ?
Logged

flac.rules

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 1268
Re: Further Client/Server development?
« Reply #1 on: October 24, 2011, 02:08:24 pm »

Yes, if possible, a better client/server-model would be very nice, I am still not using the server-mode, as I cannot use more than one server-hosted library on MC :(
Logged

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: Further Client/Server development?
« Reply #2 on: October 24, 2011, 03:49:38 pm »

Mars, just a little friendly advice... You should probably:

1) Try the current system thoroughly.
2) Post specific comments on exactly what doesn't work for you, what you'd like to see added, and why.

General "it should have moar serverosity" comments aren't going to amount to much.

The current Library Server system CAN "feed the library" from the client side, even on MC16.  There are some limits, but there have even been improvements on this already in MC17 (for example Send To -> External and Drag-Drop both now, apparently, work from the Client side on MC17 with current beta builds).

I'm someone who is VERY concerned over the utility of the server system.  For example, this IS something I'd love to see eventually:

I cannot use more than one server-hosted library on MC :(

That's a specific request for something the current system can't do (serve more than one library at a time).

I realize your old threads may have contained more context, but expecting the busy developers to (A) remember, or (B) dig through a deep thread when they have other stuff to do, is asking for failure.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

flac.rules

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 1268
Re: Further Client/Server development?
« Reply #3 on: October 24, 2011, 05:04:24 pm »

Well, I guess i could give it more context, however the usefulness should be pretty apparent. I guess we all agree that its useful to have the server-way to do things as an option (library can be centrally stored, easier to handle central libraries accessed by many computers and so on). Being that the server-model is useful, I would like to use it, however another useful feature is several libraries (like one for me, one for my wife), the benefits of combing the two should be clear, because today, if you use both those to features, you're forced too choose between them.
Logged

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: Further Client/Server development?
« Reply #4 on: October 24, 2011, 05:43:01 pm »

To be clear, Elvis... I quoted you because you DID make a specific, clear, concise feature request.  Multiple Library support on the Server.

I have no way of knowing, though I suspect they'd argue that feature is a bit of a niche request (which makes it fall into "perhaps someday").  I agree though, there are many use-cases where having the ability to simultaneously serve more than one library could come in very handy (separate library for the spouse or kids being the first thing that pops to mind, or maybe a "secret" library for that content you don't want the kids to access).

I actually DO this at work, but I use a couple VMs running on the same machine to pull it off, which isn't practical for a home user.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

Mars

  • World Citizen
  • ***
  • Posts: 199
Re: Further Client/Server development?
« Reply #5 on: October 25, 2011, 03:06:13 am »

Thanks for your advice, Glynor  ;)

My comments were initially in the "Where We're Going Next" thread ( http://yabb.jriver.com/interact/index.php?topic=66587.msg450456#msg450456 ) which was a more generalist one, not so specific, but when a bit of discussion started I was requested to move to a new thread. So I was just trying to open a discussion on how did people manage their data and put the example of what many of us have at work with ERP systems based on client/server schemes, in which full control is granted from any workstation, depending on the user credentials.

My main aim is not having to do any library managing physically at the server.

As you said, there have been many improvements, but I still have to be quite stealthy with the sync mechanism since there are things that apparently can be modified from the client but then changes are not reflected on the server.

As requested and to be more specific, these are some of the things I missed whenever I tried to manage the library from the client side that still can't be done, as far as I'm concerned:

  • Configuring Theater View (So I wouldn't have to interrupt the playback and "steal" the display of the HTPC)
  • Configuring View Schemes
  • Renaming Files (under library tools) after a tagging work is made
  • Assigning Cover Art and saving to the file folder
  • Deleting Playlists
  • Using more than one hosted library
  • User Accounts System with permission for viewing and/or editing data, modifying configurations and settings,...
Logged

MrHaugen

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 3774
Re: Further Client/Server development?
« Reply #6 on: October 25, 2011, 04:31:10 am »

You're touching some important things. Especially this with view management and a User Account System or Access Control Lists system to prevent access for certain users, or prevent alteration of data like Number Plays etc, or other tag manipulations. It's not before this is implemented that we will see the true potential of a server/client relationship. It could be used in a lot of cases like homes, to separate libraries for different family members, to prevent modify rights to customers in your store, share the library with friends, limiting access on devices that have specific purposes etc etc.

The thing with views is that the views should also be individual. Now, you get the views that is configured on the server. This is not great in case you want several clients with different purposes. The attached illustration that was created some weeks ago when we touched the subject of View management. It's a possible solution at least. The illustration consists of two selectable views, where you can drag and drop items, copy, move etc. Thing's can be stored for user created groups, and synced to given clients.
Logged
- I may not always believe what I'm saying

Mars

  • World Citizen
  • ***
  • Posts: 199
Re: Further Client/Server development?
« Reply #7 on: October 25, 2011, 05:35:18 am »

Thanks for your reply, MrHaugen  :)

The thing with views is that the views should also be individual

Yes, I would definitely add this to the list. I like the profiles system suggested, in which one could sit in front of any PC at home, log in MC with its credentials and have its own profile with its preferred view schemes and permissions. It could also be used to assign dedicated functions to different computers at home.
Logged

MrHaugen

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 3774
Re: Further Client/Server development?
« Reply #8 on: October 25, 2011, 05:46:52 am »

Remember that this suggestion/illustration does not take into account access to Media on the server. Another management interface would be needed for that. But the groups in this example could very well be tied to a access control system. One example would be lockdown of theater view, a user/group selection via the primary roller in the main menu and a touch screen interface for a short code for each user or group. Or a credential popup when connecting to a new library server. Which could also be saved on the client. I could finally start to add music only client on my bathroom, video and music only client on my kitchen, as well as sharing my library with friends and family without the risk of them messing up the tags. It would be a server/client nirvana imo.
Logged
- I may not always believe what I'm saying

Mars

  • World Citizen
  • ***
  • Posts: 199
Re: Further Client/Server development?
« Reply #9 on: October 25, 2011, 06:39:00 am »

Remember that this suggestion/illustration does not take into account access to Media on the server

However, view limitation would also somehow prevent access, so it would work in that way, wouldn't it?

I could finally start to add music only client on my bathroom, video and music only client on my kitchen, as well as sharing my library with friends and family without the risk of them messing up the tags. It would be a server/client nirvana imo.

This is nice for the user "consumer", but I'm also really interested in the "editor", that is, the user who modifies the library. As I said, I'm trying to avoid any data edition or configuration phisically on the server.
Logged

MrHaugen

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 3774
Re: Further Client/Server development?
« Reply #10 on: October 25, 2011, 06:50:10 am »

Sure. It would work in a similar manner, if you're not to concerned of privacy, or editing of your data. If the standard views have access to most data, it's still only a matter of exiting the theater view and editing or viewing data that is not meant for this client. You could also easily edit your views on the local client, and use that until the views from the server is forced on the client at next MC startup. If that behavior is not changed to continually syncing views with server.

And, yes. The editing role on the clients could be better. It's not very good to rely on RDP or VNC to access the server to do certain changes.

*Edited VLC to VNC :)
Logged
- I may not always believe what I'm saying

Mars

  • World Citizen
  • ***
  • Posts: 199
Re: Further Client/Server development?
« Reply #11 on: October 25, 2011, 07:05:57 am »

The editing role on the clients could be better. It's not very good to rely on RDP or VLC to access the server to do certain changes.

I guess you mean VNC access. I agree, it is not the most convenient way to manage it, even worse when the Server is actually the HTPC and you have to interrupt playback or catch the focus.
Logged

Mars

  • World Citizen
  • ***
  • Posts: 199
Re: Further Client/Server development?
« Reply #12 on: October 25, 2011, 10:59:42 am »

17.0.21 (10/21/2011)
...
6. NEW: On a Library Server client, dragging will allow dragging files to other programs if the file can be found through a UNC path or mapped drive.

Great News!

Thanks
Logged

maxxsid

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 866
Re: Further Client/Server development?
« Reply #13 on: October 25, 2011, 01:10:24 pm »

Doesn't work on my system.. : (
(I reported in the other thread that it worked but was actually wrong - sorry for the mixup)

Great News!

Thanks
Logged

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: Further Client/Server development?
« Reply #14 on: October 25, 2011, 11:27:39 pm »

As requested and to be more specific, these are some of the things I missed whenever I tried to manage the library from the client side that still can't be done, as far as I'm concerned:

  • Configuring Theater View (So I wouldn't have to interrupt the playback and "steal" the display of the HTPC)
  • Configuring View Schemes
  • Renaming Files (under library tools) after a tagging work is made
  • Assigning Cover Art and saving to the file folder
  • Deleting Playlists
  • Using more than one hosted library
  • User Accounts System with permission for viewing and/or editing data, modifying configurations and settings,...

Every single one of those things would be fantastic, obviously.  The only ones I have any concerns about are last two.  I'd really like to see them, but I can say as someone who does use (and helps manage) a multiuser Digital Asset Management system at the office...

The UI to configure those things is not trivial.  That mocked-up dialog box MrHaugen posted is a perfect exemplar.  That's a dialog box only a computer science major or open-source geek could appreciate, and it is (IMHO) not appropriate in an application targeted at consumers (certainly high-end, technically adept, "pro-sumers", but consumers all the same, not system administrators only).

That's why I think the best long-term solution would be to eventually roll a separate MC Server Edition product.  Without it, MC would still have all the library sharing functions it does now (hopefully with items one through five in your list above checked off).  But, if you buy a separate license for (and run) MC Server Edition, it would add a whole new set of functionality:

1. Sharing multiple MC libraries simultaneously.
2. User-based access controls and user account rights management.
3. Server runs as a truly separate process, and uses MC "client" (ANY client) for configuration.
4. Server can run as a process on a headless server much more easily (running at the login window).
5. Metadata conflict resolution workflows.

And, you can think of other possible ways this might "untie their hands" a bit.  For example...

What about the configuration of Gizmo, Theater View, WebRemote, and WebPlay functionality?  Right now, MC offers the option to modify and configure these systems all independently.  That's great, but man... It takes FOREVER to tweak and get set up correctly if you don't like the defaults much.  I just think about someone a little less advanced and dedicated to it than I am (someone who really likes the good quality features of MC, or a "sound guy", or whatever), but just doesn't care to take the time to manage all of that...

I think it would help the "average" user if this were simplified down quite a bit.  Say there were only three independent view systems that they have to manage and create: Standard View, Theater View, and Remote.  Remote would cover WebRemote, WebPlay, Gizmo, and any other future system that uses the Web Service interface (cough...iOS...cough).  On the server version, you'd have the freedom to offer advanced users the opportunity to configure those views separately or with more granularity (or still together if the user prefers).  You could even have more than one "Remote" configuration, where different users (or different devices) get served different views depending on their need.  Having different views for the DLNA audio-only streamer, verses the one on Gizmo, versus the one on the DLNA TV in the bedroom would be amazing, but it is hard to implement if everyone to has to deal with that stuff!

Whacking the server edition user with User Account Management tasks and the complexities of multiple libraries would be acceptable, but I'm not sure it makes sense in the current "client" version of MC.  Just think, with multiple simultaneous library support, an uninformed user could really proceed to screw up his tags royally (if you started serving multiple libraries simultaneously which contained the same file references, and switched between them accidentally occasionally, it could spell tagging consistency trouble very quickly).  A server version could offer these features without suffering the backlash from the more casual users.

And, of course, we'd make it worth their while by paying for an extra license for the trouble.
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

glynor

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 19608
Re: Further Client/Server development?
« Reply #15 on: October 25, 2011, 11:40:27 pm »

I agree, it is not the most convenient way to manage it, even worse when the Server is actually the HTPC and you have to interrupt playback or catch the focus.

I realize this doesn't solve the problem with MC itself, but for the current situation... You may want to consider moving the server elsewhere if possible.  Of course, you probably can't do this if your only "client" machine is a laptop that needs to be able to go offline and to sleep and whatnot.

But... If you do have another PC in the house, or can rearrange things, you might really get a better experience with MC as it is now running the HTPC as the client and having the server somewhere else.

I originally ran my HTPC as my server because that's where the cable box was, so that's where my capture devices were, and so that's where big hard drives were, and so on and so forth.  But not long after switching over to using MC's Library Server functionality, it became clear that this was impractical for many of the same reasons you listed.  Doing all of my view configuration on the "big screen" was an ergonomic nightmare, and annoyed my wife who just wanted to listen to music while she worked or watch a little TV.

Plus, all of that crap in my living room was an eyesore.  Thick coax cables (and splitters, of course) power cables and USB cords making a nest behind the systems, an ugly blinking cable box from Time Warner, a desktop-style PC case lying on its side, and plus the HTPC was much louder than it needed to be with all those hard drives (and that requirement was only getting worse over time).

So I moved it.  I ripped out all of the coax cable from the living room.  I moved the cable box down to the basement man-cave.  My server PC can be as loud as it wants, have as many hard drives as it wants, and cables hidden away under a desk and behind my monitors.  I built a little shelf for my cable box and the HD-PVR, and I have docking stations and external RAID array boxes for gobs and gobs of storage capacity.

And my wife is VERY happy with the new setup in the living room.  I have three boxes under the TV, total.  My HTPC (in a nice Lian Li HTPC case), my receiver, and a small battery backup (which is hidden away behind the TV).  There are WAY fewer cables behind the setup (and I just got some nice flexible corrugated conduit that I'm going to wrap up all of those with here shortly).  Only two cables (one power and one HDMI) go up to the TV itself.

It is very quiet.  I didn't go crazy... It still has fans (so John Siracusa could certainly hear it with his bat-hearing), but they're big ones and they rotate slow.  And there are two hard drives in it (boot and backup) but they don't get hammered on like the big storage drives except at boot and when Acronis runs the backup in the middle of the night.  Plus, when SSD's price-per-GB gets down a bit more in a year or so, I'll drop a 256GB SSD in it and that noise will be gone too.  I can't hear it at all in my normal listening environment.

And, a whole bunch of those management problems you're having go away.  I can sit at my desk in my man-cave and do the library management and most of the tagging "heavy lifting".  The big storage drives are local down there, so Rename, Move, and Copy operations go way quicker than they would over a network drive.  I don't bother anyone upstairs unless I want to reboot the server (which is rare).  Managing the views is easier with a regular mouse and a regular keyboard an a regular monitor.

And, perhaps most importantly... For power.  I have one machine, in one room (with all of it's assorted peripheral boxes) that I need to leave on no matter what.  I can shut down or reboot the HTPC whenever I want.  Like when I leave home on a trip!  The server stays up and keeps recording and serving my stuff, but everything else is off upstairs.

It is so choice. If you have the means, I highly recommend picking one up.  ;)
Logged
"Some cultures are defined by their relationship to cheese."

Visit me on the Interweb Thingie: http://glynor.com/

flac.rules

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 1268
Re: Further Client/Server development?
« Reply #16 on: October 26, 2011, 02:17:57 am »

Every single one of those things would be fantastic, obviously.  The only ones I have any concerns about are last two.  I'd really like to see them, but I can say as someone who does use (and helps manage) a multiuser Digital Asset Management system at the office...

The UI to configure those things is not trivial.  That mocked-up dialog box MrHaugen posted is a perfect exemplar.  That's a dialog box only a computer science major or open-source geek could appreciate, and it is (IMHO) not appropriate in an application targeted at consumers (certainly high-end, technically adept, "pro-sumers", but consumers all the same, not system administrators only).


To be honest, I don't see the connection? The view-settings Mrhaugen posted are just as complex or non-complex no matter how many libraries you have? It's not needed to have several hosted libraries, you can just make everything as today, but being able to access more than one library on the server? I guess one can argue for both an easier approach to configuration from the client side, or a more flexible, but having the ability to share multiple libraries is compatible with both?
Logged

MrHaugen

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 3774
Re: Further Client/Server development?
« Reply #17 on: October 26, 2011, 02:34:31 am »

The illustration is just an example of how it could be done with views. I think that most users familiar with MC would know how to deal with it. It's just an extension on todays user interface. Only point with the UI illustration was to illustrate what probably needs to be done in some way, to edit views easily and copy/move things between view as well as syncing views with clients. It could probably be split up and simplified, but that is not the point here really.

A separate MC server product might be a good idea. I would purchase it for sure.
Logged
- I may not always believe what I'm saying

Mars

  • World Citizen
  • ***
  • Posts: 199
Re: Further Client/Server development?
« Reply #18 on: October 26, 2011, 09:56:45 am »

The UI to configure those things is not trivial.  That mocked-up dialog box MrHaugen posted is a perfect exemplar.  That's a dialog box only a computer science major or open-source geek could appreciate, and it is (IMHO) not appropriate in an application targeted at consumers (certainly high-end, technically adept, "pro-sumers", but consumers all the same, not system administrators only).

Well, at first sight, I wouldn't consider it more complicated than other tweakings like those in Theater View, View Schemes, Zones, or even in Smartlists. Of course, all of them should be considered as "Advanced" or "Pro" tools, as they have its particular learning curve.

That's why I think the best long-term solution would be to eventually roll a separate MC Server Edition product.  Without it, MC would still have all the library sharing functions it does now (hopefully with items one through five in your list above checked off).  But, if you buy a separate license for (and run) MC Server Edition, it would add a whole new set of functionality:

1. Sharing multiple MC libraries simultaneously.
2. User-based access controls and user account rights management.
3. Server runs as a truly separate process, and uses MC "client" (ANY client) for configuration.
4. Server can run as a process on a headless server much more easily (running at the login window).
5. Metadata conflict resolution workflows.

I Actually had this on mind when opening the thread, but I preferred to poll a little before raising the issue. I guess there is some Market Research and Cost-Benefits Analysis tasks to do, but I agree it could probably be a step beyond for Average and specially for Professional users (you know better than me).
Logged

Mars

  • World Citizen
  • ***
  • Posts: 199
Re: Further Client/Server development?
« Reply #19 on: October 26, 2011, 11:09:21 am »

You may want to consider moving the server elsewhere if possible. Of course, you probably can't do this if your only "client" machine is a laptop that needs to be able to go offline and to sleep and whatnot

So I moved it.  I ripped out all of the coax cable from the living room.  I moved the cable box down to the basement man-cave.  My server PC can be as loud as it wants, have as many hard drives as it wants, and cables hidden away under a desk and behind my monitors.  I built a little shelf for my cable box and the HD-PVR, and I have docking stations and external RAID array boxes for gobs and gobs of storage capacity.

And my wife is VERY happy with the new setup in the living room.  I have three boxes under the TV, total.  My HTPC (in a nice Lian Li HTPC case), my receiver, and a small battery backup (which is hidden away behind the TV).  There are WAY fewer cables behind the setup (and I just got some nice flexible corrugated conduit that I'm going to wrap up all of those with here shortly).  Only two cables (one power and one HDMI) go up to the TV itself.

I like your solution, but, unfortunately, doesn't fit in our "minimalist" stage of life (not enough room in our tiny flat). Instead of a "Man-Cave", what we have is a romantic "Men&Wife-Cave" which reduces to the whole appartment ;D. So we have all the heavy stuff in the living room, by the TV: DSL Router, PVR, IPTV Receiver, and BD HTS at a sight and the NAS and the HTPC enclosed in a cabinet, with all the wires hidden in order to accomplish with my wife's standards.;)

The rest of equipment at home is basically composed by a pair of Laptops, two Smartphones and a Tablet. So for me the HTPC is the only option for hosting the Server by the moment, and that's why I'd like to be able to manage everything from the Client (Laptop or, hopefully, Tablet).
Logged

ThoBar

  • Citizen of the Universe
  • *****
  • Posts: 992
  • Was confishy
Re: Further Client/Server development?
« Reply #20 on: October 27, 2011, 01:16:53 am »


  • Configuring Theater View (So I wouldn't have to interrupt the playback and "steal" the display of the HTPC)
  • Configuring View Schemes
  • Renaming Files (under library tools) after a tagging work is made
  • Assigning Cover Art and saving to the file folder

I'd really like to throw my support behind these suggestions - especially that 1st one! The HTPC should really not have to be taken offline to do that!
Logged

JimH

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 72438
  • Where did I put my teeth?
Re: Further Client/Server development?
« Reply #21 on: October 27, 2011, 06:40:25 am »

I'd really like to throw my support behind these suggestions - especially that 1st one! The HTPC should really not have to be taken offline to do that!
How could you both watch a movie and browse somewhere else at the same time?  Two screens?
Logged

MrHaugen

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 3774
Re: Further Client/Server development?
« Reply #22 on: October 27, 2011, 07:18:51 am »

I believe they are thinking of a more bidirectional synchronization of views between server and clients. In real time, more or less. That new view settings is read and applied when a new view is accessed. It would be very effective to change views or other setting this way rather than exiting TV, synchronizing or restarting MC, going back in TV and then checking the difference.

In my ideal setup, I would have one server with all the data. Options, Views and perhaps even several libraries for different client or user groups. You could switch the targeted group on the server. Change options, change views, test them locally on the server. Or you could change settings on your workstation, and have the settings duplicated to other clients within the same group. Syncing between one client to the server, and then to another client. Some options needs a restart for the clients to update of course. As usual.

This way you would never be forced to refuse your wife to use the HTPC. You would never have to get the mouse and keyboard for the HTPC. You'd not even have to connect remotely to your server to change some settings there. And you'll never have to change the settings on new clients, as they are saved together with the libraries.
Logged
- I may not always believe what I'm saying

Mars

  • World Citizen
  • ***
  • Posts: 199
Re: Further Client/Server development?
« Reply #23 on: October 27, 2011, 08:45:25 am »

Exactly, in fact the main idea behind it is about the possibility of giving more power to the Client towards the Server, specifically in those mentioned areas:

  • Configuring Theater View (So I wouldn't have to interrupt the playback and "steal" the display of the HTPC)
  • Configuring View Schemes
  • Renaming Files (under library tools) after a tagging work is made
  • Assigning Cover Art and saving to the file folder
  • Deleting Playlists
  • Using more than one hosted library
  • User Accounts System with permission for viewing and/or editing data, modifying configurations and settings,...

It was also commented that maybe some of them could involve deeper changes, such as the segmentation of the product:

The only ones I have any concerns about are last two.  I'd really like to see them, but I can say as someone who does use (and helps manage) a multiuser Digital Asset Management system at the office...

The UI to configure those things is not trivial.  That mocked-up dialog box MrHaugen posted is a perfect exemplar.  That's a dialog box only a computer science major or open-source geek could appreciate, and it is (IMHO) not appropriate in an application targeted at consumers (certainly high-end, technically adept, "pro-sumers", but consumers all the same, not system administrators only).

That's why I think the best long-term solution would be to eventually roll a separate MC Server Edition product.  Without it, MC would still have all the library sharing functions it does now (hopefully with items one through five in your list above checked off).  But, if you buy a separate license for (and run) MC Server Edition, it would add a whole new set of functionality:

1. Sharing multiple MC libraries simultaneously.
2. User-based access controls and user account rights management.
3. Server runs as a truly separate process, and uses MC "client" (ANY client) for configuration.
4. Server can run as a process on a headless server much more easily (running at the login window).
5. Metadata conflict resolution workflows.
 
Logged

ThoBar

  • Citizen of the Universe
  • *****
  • Posts: 992
  • Was confishy
Re: Further Client/Server development?
« Reply #24 on: October 27, 2011, 10:52:54 am »

How could you both watch a movie and browse somewhere else at the same time?  Two screens?
As MrHaugen has alluded to, this would be on a separate PC. Having said this, I believe there is no need for a Theater View view to be read every time a view is changed (in fact that could be detrimental) - every time Theater View is loaded is more than ample.

The main thrust of the request (point 1 only) - as I understand it - is to enable the definition of views in Theater View, from another PC.

For me, where my HTPC and server are one and the same it can be a right pain to try and modify the views in Theater View on the server. The HTPC is simply not setup for mouse & kb access. Ideally, I'd like an option - when editing views and connected to a MC Library server - to choose whether to edit views on the server or client.
Logged

Mars

  • World Citizen
  • ***
  • Posts: 199
Re: Further Client/Server development?
« Reply #25 on: October 28, 2011, 09:35:10 am »

For me, where my HTPC and server are one and the same it can be a right pain to try and modify the views in Theater View on the server. The HTPC is simply not setup for mouse & kb access. Ideally, I'd like an option - when editing views and connected to a MC Library server - to choose whether to edit views on the server or client.

I absolutely agree. For for me it would even apply to points 2 through 5:

Quote
As requested and to be more specific, these are some of the things I missed whenever I tried to manage the library from the client side that still can't be done, as far as I'm concerned:

  • Configuring Theater View (So I wouldn't have to interrupt the playback and "steal" the display of the HTPC)
  • Configuring View Schemes
  • Renaming Files (under library tools) after a tagging work is made
  • Assigning Cover Art and saving to the file folder
  • Deleting Playlists
  • Using more than one hosted library
  • User Accounts System with permission for viewing and/or editing data, modifying configurations and settings,...
Logged

Mars

  • World Citizen
  • ***
  • Posts: 199
Re: Further Client/Server development?
« Reply #26 on: October 28, 2011, 10:16:40 am »

I think that more power to the Client would lead to a more "portable" managing system for the library.

In my case, with all the current abilities of the client, plus point 1 through 5 of the requested ones, I would be able to do 99% of managing tasks (not 100%, just in case I forgot some...).

Logged

JustinChase

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 3276
  • Getting older every day
Re: Further Client/Server development?
« Reply #27 on: October 28, 2011, 11:18:00 am »

I think it would help to consider that a "Library" should ONLY include factual information/media, not any opinions, judgements or opinions about that media.

A user profile (call it whatever you want) should include only the opinions, judgements and opinions about the underlying media.

Consider a real library, with books, in a building near you.  They don't impose someones opinions of the quality of a book to you.  They just allow you to use what is there, and the card catalog helps you find it.  Imagine if you walked into the library and they told you that all the 5 star books are in that back corner, and all the 2 star books are on the other side??  What if you thought some of the 2 star books shoudl be 5 star books, so you moved them to that section.  No one would be happy.  That's what I think we have now.

If the library only included information about where the media is, what it's called, and what resources are required to play it, that should be all the library needs to do.

The profile should have all my opinions and preferences, and should ONLY display the media based on my preferences.  I don't think a profile shoud be able to actually manipulate the data at all.  Just display information about the media the way I want to see it, but the underlying media should me managed exclusively by the Library server portion.  That way, it is the only part that knows where everything is, so when a new profile logs in, the server can present that profile/user with an accurate list of data, that the profile will display according to the user preferences.

I don't need or want to 'customize' the underlying data as a regular user, I just want to see a 'customized' representation of the data.  My wife will never share my opinions about music, so if our 'library' insists that Metallica is a 5 star band, my wife will never use this 'library'.

But, since she can't have/maintain her own library, she gets nothing out of MC.  She opens it, all the smartlists give results that I want, it's useless to her.

She can't create a library and customize it for her wants, because I can only have one library running at a time, and i use it more than her, so I win; she loses.

If her profile could connect to the media at the same time my profile could connect to the same media (without pre-set judgements), we could both use the software in the way we want.

An administrator account/permissions would be required to set up the "rules" for the library to follow (auto-import, naming convention, storage location, etc), but a "normal" user account could be limited to changing judgements/preferences, but not the underlying media, for example.  A "party" user could be restricted from changing anything.  You could create several "party" profiles, depending on the type of party you were having, for example.

I'm goint to try to spend some time this weekend going thru the options and separate what I think is a factual setting and a judgement setting, which I think may help illustrate my ideas better.
Logged
pretend this is something funny

Mars

  • World Citizen
  • ***
  • Posts: 199
Re: Further Client/Server development?
« Reply #28 on: October 29, 2011, 06:35:21 pm »

So, to sort a little some of the main ideas exposed here (please, correct me if I'm wrong):

1) A system based on Users/Profiles would add a deep transformation in the usability of MC as a complete Media Home System.
 
2) The Data in the library could be divided in two types: "Objective" and "Subjective". The Objective fields would include all the referencial and specification facts of the stored media files (i.e. Artist, Album, Name, Year, Bitrate, Filename, ...), whereas the Subjective would refer to user's Personal appreciations or statistical references to each Media File.
 
3) Only an "Administrator" should be able to modify and access to all the objective data. Levels of modification and access could be delegated to other Users or User Groups.

4) Each User could have its own profile to edit Personal fields (except the autocalculated ones), manage their own Playlists and set Preferences (Views, Playback). A "Default" setting could be choosed and would retrieve the Subjective data, Playlists and Configurations set by the "Administrator".

5) Phisically, the Server would host and distribute the database to the Client computers from which data would be fully managed according the Users/Profile System.

6) This system would probably requiere a seperate Media Center Server.
Logged

JustinChase

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 3276
  • Getting older every day
Re: Further Client/Server development?
« Reply #29 on: October 29, 2011, 07:27:55 pm »

So, to sort a little some of the main ideas exposed here (please, correct me if I'm wrong):

1) A system based on Users/Profiles would add a deep transformation in the usability of MC as a complete Media Home System.
I think it would, yes
 
2) The Data in the library could be divided in two types: "Objective" and "Subjective". The Objective fields would include all the referencial and specification facts of the stored media files (i.e. Artist, Album, Name, Year, Bitrate, Filename, ...), whereas the Subjective would refer to user's Personal appreciations or statistical references to each Media File.
yes, the data on the server would only be information about the media, where it is stored, what streams are in the container, resolution, etc; the unchangeable information.  The values we place upon that media would be separated into the profile, including ratings, views, cover art, playlists, playback settings, conversion settings etc.
 
3) Only an "Administrator" should be able to modify and access to all the objective data. Levels of modification and access could be delegated to other Users or User Groups.
yes
 
4) Each User could have its own profile to edit Personal fields (except the auto-calculated ones), manage their own Playlists and set Preferences (Views, Playback). A "Default" setting could be chosen and would retrieve the Subjective data, Playlists and Configurations set by the "Administrator".
yes, and I would allow users/profiles to share their data (playlists, views, etc) with others also

 
5) Physically, the Server would host and distribute the database to the Client computers from which data would be fully managed according the Users/Profile System.
basically yes.  the server does not need to physically host all the media, it just needs to be the part that is aware of all of the media, including the available renderers/zones, and assets, including TV tuners.  If the server is aware of everything, and is the only part of MC to have direct access to the media/assets, then it can easily decide who gets to manipulate what, and in what order to serve what to whom.
 
6) This system would probably require a separate Media Center Server.
Actually, I don't think so.  Media Center already has all of these parts/functions.  it would just need to be divided into 2 parts.  both parts would install on a brand new install, and a user would never need to be aware that there are 2 parts, they just seamlessly function together.  BUT, you can install the profile part on other machines.  it would just ask on install if you already have a server installed on the network, or, better still, it would broadcast to a known port, and the install would look there for the broadcast and just ask if you wanted to use that data library/server.

It would allow anyone to schedule recordings, since they would just tell the server what they wanted to record, and it is the only thing allowed to manage the recordings, so it knows what it can and cannot accommodate, so no conflicts.  The profile would not need to have a physical tuner, because the program would not be designed to 'record show' on the local asset, which my laptop does not have.  it would just request to 'record show' and the server would send the proper command to the best available tuner, no matter what machine it resides in.  they would all record to the same place, because the server would be the only place this spec is set.

I've been thinking about this for years, and have yet to see a request for a client/server functionality that this will not provide/resolve.  Not to say there aren't any, but this resolves all I've seen.
Logged
pretend this is something funny

swinster

  • World Citizen
  • ***
  • Posts: 234
Re: Further Client/Server development?
« Reply #30 on: October 31, 2011, 12:54:32 pm »

Hi,

I posted this in a separate thread, but then realised this one had already been started.

In this post (http://yabb.jriver.com/interact/index.php?topic=66587.0) regarding where you are going next, JimH reply to a comment


Quote
Quote
MrHaugen

real user based database system
JimH - Nice to have but not a broad demand yet.

From what I have seen, I have seen a lot of people (myself included) clamouring for this for many years. I would love to see a proper database back end, if not for the actually media, but for the management of the tag, data, preferences, views etc etc.

With the rise of WHS you need a proper client server structure. One where you would not need to keep running to the server to make certain change or updates. I would love to see a service based server that simply serves the info. Everything else is managed form the client. This is one area where is still feel MC is clunky in its operation.

I know that this discussion has been going on since around MC 12, so the idea that there is not  a "broad demand" is a little short sighted.


So simply, things I would like to see:

1) Everything needs to be controlled and setup up from a client, logged on as an admin, not actually at the remote server machine
2) Different users can be given different right and different views
3) Importing and ripping from a client can be done straight into a library server.
4) Ability to create off-line cache of material. I am often on the road with the laptop but still want access to some of my main server material. I then rip a new CD into the off-line store and it synced as soon as I reconnect to the network at home.
5) ...... (come back to these)
Logged
Pages: [1]   Go Up