Print

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

[JustinChase]

I hope that one day JRiver dedicates the resources to restructure the code to allow for a true server > client experience.  Putting the media and program level settings on a server, running as a service, and the only way to connect is with a client, which is customizable both in terms of appearance as well as content/library.

Once this happens, only the "server" portion need be ported, and I would throw another +1 for unRAID capability once they reach this point.  Trying to put the full MC experience on Linux is a big reach, from what I can see.  Matt and company are great programmers, but I don't see excess capability sitting around waiting to learn a new language.

Hopefully one day, after the server has been separated from the user experience it will run on Linux.

[JimH]

I hope that one day JRiver dedicates the resources to restructure the code to allow for a true server > client experience. 

MC is both a true client and a true server.  It is misinformed to say that it is otherwise.  I grant you that it may not be exactly what you want or expect, but think about how many possible expectations there are for what client/server "should" be.

There are things we'd like to improve about how the clients and servers work together, but that's true in every aspect of the program.

[JustinChase]

MC is both a true client and a true server.  It is misinformed to say that it is otherwise. 

You are correct, I mis-spoke.  I should have said "more robust and separated" instead of "true".  "true" is very subjective, and misleading.  JRiver Media Center is, in fact, a very capable server and client system.

I do wish it were more separated, for various reasons, as I've written a few times, and it sounds like you and Matt share many of the same desires, which is great.

I apologize for my mistake, it was not meant to slander. 

[JimH]

Thanks.  No offense.  It wasn't meant for you but for people who might read it and think the client/server aspect needs work.  It's like saying someone "needs" money.  It's usually true.  It doesn't mean they are poor.

But don't hold your breath waiting for a different architecture.  We're pretty happy with what it is and does.  I don't know of anything else, including Windows' features, that comes close.

[preproman]

I don't know of anything else, including Windows' features, that comes close.

The Plex client / server implementation is bleeding edge.  Let me be clear.  Just the client / server implementation.

[preproman]

MC is both a true client and a true server. 

A true client is very, very true.  A true server.  Well..  It's not a server in a sense that it can server up data to various different applications such as unRAID, Windows home server. MC is from what I can see - is bound to MC.  A true server is the backend to many different apps.  So a true server is debatable.

[JimH]

A true client is very, very true.  A true server.  Well..  It's not a server in a sense that it can server up data to various different applications such as unRAID, Windows home server. MC is from what I can see - is bound to MC.  A true server is the backend to many different apps.  So a true server is debatable.

If you want to define what a server is, then you can be the judge of whether MC is one.  But you are mistaken.

MC has several servers.  Library Server is specific to MC.  The TiVo server works with TiVo.  DLNA is an industry standard server.

That it only works with a subset of what is possible is not a reason to say it isn't a true server.

I'm not aware of any other software that works with our Library Server, for example, but it runs big circles around anyone's DLNA Server.  It can provide a deep and rich experience on the client, essentially duplicating the experience of the native app.

[Matt]

I wish the program used a real database.

[JustinChase]

Without knowing the architecture, or programming, it's hard to know what exactly you mean by that.

I hope you mean that you wish the data (the actual media files themselves) was just considered/treated like raw data, to be reported on and displayed any and all ways a user wishes.  The data in a database is not prejudged or 'graded', it's just something to manipulate/report on.  Our media files could/should be treated more like this.

Ratings, sortings, expressions, preferences should all be separate from the raw data, like a database.

This gives you ultimate control.  Access rating, which is currently being discussed becomes a snap. User A has x,y & z permissions, to g, h & j types of files, but User B only has x permissions, and only to j types; for example.

User A can rate track 9 with 5 stars, but User B can rate the same track 2 stars, and both can access the data simultaneously, with their own preferences.

The Server just responds to requests from any user, whether running a full MC install from a networked machine, or a phone using Gizmo, or a machine in an internet cafe in Barcelona using webGizmo.  As long as they provide the proper credentials, they get their experience.  You mostly offer this already.  If the HTPC connects to the library, then the Desktop connects to the same library, the Desktop cannot have write access.  If a client connects to a server, changes are managed and synced later.  These should be all the tools needed to have everything separate; they would just need to be organized somewhat differently.  I know I've said it before (probably in too much detail/length), but this change would resolve every complaint and every request I've seen about and for client server functionality.

Maybe big effort, I have no idea.  I would certainly not want to lose the speediness of MC, but with all the data manipulation happening on a server, and just feeding media to clients, it seems like it shouldn't slow down too much, if at all.  I think that is Jim's concern, slowing down the database; and it's a very valid concern, but I'm not sure it's accurate (especially considering my first sentence).

[JimH]

I wish the program used a real database.

It was an inside joke.  We've heard something like that comment many times in the past.  We always thought, "Hey!  It is a real database.", pretty much like my reaction to your comment about MC needing to be "true" client/server.

I'd love to see a performance contest between mySQL and MC sometime.

[preproman]

That it only works with a subset of what is possible is not a reason to say it isn't a true server.

Jim,

You are correct and I agree with that.  I was thinking more on a larger scale.  When I think server, I think of endless possiblities.  Just to name a few serviecs that run on the unRAID server, of course what I was comapring the JR server to.  Couch Potato, SickBeard, SABnzbd, VM, Transmission, they now have an iTunes service runing on unRAID.

The point of this is.  If JR could run as a service on the back end of a (server) like unRAID and others and have the same great, powerful, fantastic front end (client)  then IMHO that is the true meaning of Client / Server.

[MrHaugen]

I kind of agree with Justin and preproman here. Sure, MC have it's server capabilities, and there is no written rule of how a server should act. But it might open up a lot of possibilities if it was a bit more separated. The following are a mad mans thoughts produced in roughly 20 minutes. It's very rough, and it might not be doable at all, but I would like to at least try to contribute to this discussion. As I believe that this is of rapidly increasing importance.

I think we talk about 3 things here. At least the way I see it.
- We have the client who can act on it's own, or show the content dictated by the library server.
- We have the server as it is today. Who both work as a server, dealing out information that is needed. In addition it's a client who serves like a sort of renderer or playback unit for steaming services and so on.
- Then we have the server functionality. The part that actually shares the data and sync the changes back to it's central location. The mother of all client.

In many ways I think it would be good to separate these. Perhaps have a server service who acts like the actual server with database. Controlling the media, syncing data, forcing restrictions and so on. This part could have a focus on cross platform interoperability. I think it would be a much less demanding task than preparing the whole client for cross platform operations.

Then you would have the client. The client could be installed with only the client part if it was connected to the library server. And if it was just a local client, it could be installed with this library server service.

Last we have the playback, trans-coding and streaming capabilities that many also refer as the server today. This could still be a part of the client. So, if you would want a server with both library and streaming options you could just install the client and server component on a windows server. Or you could install the server service on a NAS and the client on a server or client.


I would also like to see a comparison of MySQL and JRiver's database. I think that JRiver's DB would beat it. With the mad thoughts written above I want to make it clear that I do not want MC to move away from it's own database. I think we will loose out on speed that way. I don't want one single database at the server either. Because the data traffic back and forth is doomed to be slower than a local database. The way the sync is handled today between two databases is pretty much the best of two worlds imo. IF JRiver had a server component with a DB, and provided more open API's for this (I don't know if there is any today?), there might be some amazing possibilities for third party tools and integrations.

[JimH]

Jim,

You are correct and I agree with that.  I was thinking more on a larger scale.  When I think server, I think of endless possiblities.  Just to name a few serviecs that run on the unRAID server, of course what I was comapring the JR server to.  Couch Potato, SickBeard, SABnzbd, VM, Transmission, they now have an iTunes service runing on unRAID.

The point of this is.  If JR could run as a service on the back end of a (server) like unRAID and others and have the same great, powerful, fantastic front end (client)  then IMHO that is the true meaning of Client / Server.

I see.  I think you meant service, not server.  A service is not necessarily a server.  A service could be anything.

[cncb]

I agree with Justin's points.  In fact, client/server problems has pushed me away from using MC for the last several months.

1) Service: This is absolutely necessary for at least the TV recording engine.  Any crashes in the main program will bring down any recordings in progress which is a big problem with a DVR.  I know the idea is to never have any crashes but this is not realistic.

2) Feedback on client: I had problems with files not getting deleted via a client (particularly TV recordings).  I had no idea until I looked on my server's hard drive to see the files still there.  There needs to be some feedback on operations on the client so we know that something may have failed.  I had the same problem when tagging photos: keywords weren't written to files when tagged from the client.  Again the issue is that I was oblivious to any problems since there is no indication on the client.

I recently received your "newsletter" email touting MC's impressive speed.  I don't really understand why you are so focused on speed when, in my opinion, reliability is more important in the client/server model.  Are people really complaining when a search takes 0.3 seconds instead of 0.25 seconds?

[glynor]

I wish the program used a real database.