INTERACT FORUM

Please login or register.

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

Author Topic: Many clients sharing the same library?  (Read 3864 times)

Olf

  • Recent member
  • *
  • Posts: 7
Many clients sharing the same library?
« on: November 07, 2005, 03:24:13 pm »

In my home, I'm using several computers to play music, so I've set up one computer as a media server and use it's library on the other computers.

This setup does not do what I want it to do, as I want to be able to administer my library from all my computers. Therefore, I am wondering if it is possible to store the library on a network drive next to the songs and then point several clients to the same library? Would that work or would the library crash if two clients are up at the same time?
Logged

Alex B

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 10121
  • The Cosmic Bird
Re: Many clients sharing the same library?
« Reply #1 on: November 07, 2005, 03:41:17 pm »

Welcome to the forum!

This has been asked and discussed several times. Here is one of the answers and some other links:

http://yabb.jriver.com/interact/index.php?topic=29585.msg204025#msg204025
Logged
The Cosmic Bird - a triple merger of galaxies: http://eso.org/public/news/eso0755

Polfliet

  • Recent member
  • *
  • Posts: 32
Re: Many clients sharing the same library?
« Reply #2 on: November 12, 2005, 03:04:54 pm »

I'm in the same boat and have searched for the best way to auto-sychronize or share my main MC library and music files for a while now.  Has anyone tried configuring PC's as handheld devices and using MC's built-in synchronization?  And what would be the limitations to this if it worked.  Everytime I've tried it freezes during the "Retreiving file info..." window that pops up.

Would a third party synchronization program work better?  I just noticed Microsoft has a new fre Power Toy, "SyncToy 1.0".  Do you think simply using this to sync the MC library file folders (and music folders) on multiple PC's would work?
Logged

JimH

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 72444
  • Where did I put my teeth?
Re: Many clients sharing the same library?
« Reply #3 on: November 12, 2005, 04:17:21 pm »

Has anyone tried configuring PC's as handheld devices and using MC's built-in synchronization? 
MC 11.0 supports this and it does work, though it hasn't been widely used yet.
Logged

johnp

  • World Citizen
  • ***
  • Posts: 145
  • let your 'Yes' be 'Yes,' and your 'No,' 'No'
Re: Many clients sharing the same library?
« Reply #4 on: November 13, 2005, 04:12:26 pm »

I posted a possible solution here but have no response from anyone in the "know" as of yet...
Logged

Polfliet

  • Recent member
  • *
  • Posts: 32
Re: Many clients sharing the same library?
« Reply #5 on: November 13, 2005, 08:53:01 pm »

I like the idea of just using the master library from a remote location, but have worried of corrupting the database.  Do you think it's OK to do this as long as you know no one else is accessing the database at the same time?
Logged

johnp

  • World Citizen
  • ***
  • Posts: 145
  • let your 'Yes' be 'Yes,' and your 'No,' 'No'
Re: Many clients sharing the same library?
« Reply #6 on: November 13, 2005, 10:13:36 pm »

I think the general consensus from JRiver is that you are going to have issues if you do that.  Also I have read reports from people that since migrating to v11.x, there are performance issues when using more than one PC connected to a single database.

I would still like to know if there is a way to automate the synchronization of multiple individual databases by using the current backup - restore scheme.  With Girder, I can send a command to pop up a backup or retore window, but I still need to type in the file name and click OK.  I would like to do this via a script or something that would have zero user intervention.  Just a push or pull database function request.

Anyone out there undertand what I am asking?

Thanks,

John
Logged

hit_ny

  • Citizen of the Universe
  • *****
  • Posts: 3310
  • nothing more to say...
Re: Many clients sharing the same library?
« Reply #7 on: November 14, 2005, 03:15:31 am »

This has been a long running request since as far asi can remember.

Currently it's possible for several clients to request from the server but no updates allowed, read only.

If you need to update anything, would remote desktop to the server do the trick ?

Agreed its not as seamless as just making changes in a remote client and having the updates sent to the server but as a workaround.

Thing is if they do implement multi-client updates, what would it look like. If any client makes updates, how would you handle a rollback in case of an error. There has to be a rollback feature included.

It gets complicated quite fast.
Logged

JimH

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 72444
  • Where did I put my teeth?
Re: Many clients sharing the same library?
« Reply #8 on: November 14, 2005, 06:49:46 am »

... Also I have read reports from people that since migrating to v11.x, there are performance issues when using more than one PC connected to a single database.
I don't recall seeing any reports on this.  There was a sluggish startup problem for a few builds, but that's gone now.
Logged

johnp

  • World Citizen
  • ***
  • Posts: 145
  • let your 'Yes' be 'Yes,' and your 'No,' 'No'
Re: Many clients sharing the same library?
« Reply #9 on: November 14, 2005, 09:11:55 am »

I don't recall seeing any reports on this.  There was a sluggish startup problem for a few builds, but that's gone now.

I was referring to this post.  But I have seen other as well that claim the same thing.  noite: I am not talking about using the library server to stream, I am talking about sharing the actual library file sto a network drive and connecting to them with multiple instances of Media Center.

Still, no one has told me if what I am wanting to do is possible.  That is to automate the "backup" and "restore" processes via command line or Girder or some other mechanism.

Best,

John
Logged

johnp

  • World Citizen
  • ***
  • Posts: 145
  • let your 'Yes' be 'Yes,' and your 'No,' 'No'
Re: Many clients sharing the same library?
« Reply #10 on: November 14, 2005, 09:30:18 am »

This has been a long running request since as far asi can remember.

Currently it's possible for several clients to request from the server but no updates allowed, read only.

If you need to update anything, would remote desktop to the server do the trick ?

Agreed its not as seamless as just making changes in a remote client and having the updates sent to the server but as a workaround.

Thing is if they do implement multi-client updates, what would it look like. If any client makes updates, how would you handle a rollback in case of an error. There has to be a rollback feature included.

It gets complicated quite fast.

I agree it can be complicated.  That is likely why it is not a feature as of yet.  I think you have to go with a master slave model as I mentioned in my post mentioned above.  The sychronization can be automatic or manual as desired by the user.  Library archive backups can be performed automatically before changes to allow for regression in case of an error or unwanted / accidental change.

The thing is , none of this is new.  Multi user relational databases have been around since I have been working with computers and that is a long time.  There just needs to be a command decision made to support it and move on.

Other players have interesting ways of dealing with the same problems.

Music Match for example although quite inferior in many other ways has a seemingly clever way of dealing with this problem.  All tag and library information is stored within the file.  Even on wav files (some may remember my pleas of many years ago asking for wav file tagging).  At any rate when a new instance of Music Match is installed  the client just does an import and the library is all there.  The new or updated songs are automatically added to the client through a function called watch folders.  Any time a song is added to a watched folder it is automatically imported into the library.

This does not deal well with all the other cool aspects of Media Center's Library like playlists play counts etc. etc., but I think it can be an example of how to deal with the problem of managing or at least adding to the actual music portion of the library.

As far as using Remote Desktop to manage the Main Music Server, the JRiver Application does not run as a service and therefore must run as an aplication in a logged on session.  As such, to get it to work automatically at boot time, one must auto-login the console session and  launch Media Center at startup time.  Alas, Remote Desktop will not overtake a console logon and so you must use a program like VNC to take the console.  This will work but it is very slooooooow and painful to use and still you cannot access local resources on your PC to Rip, Burn, iPod sync etc.  Everything has to be physically connected to the server.

So remote control is not a viable solution to this problem.

I still think that automated Library: backup (from server), restore (to client), backup (from client) restore (to server) has some short term workaround potential, I just can't figure out how to automate the file naming and execution part.
Logged

hit_ny

  • Citizen of the Universe
  • *****
  • Posts: 3310
  • nothing more to say...
Re: Many clients sharing the same library?
« Reply #11 on: November 16, 2005, 01:56:03 am »

I agree it can be complicated.  That is likely why it is not a feature as of yet.  I think you have to go with a master slave model as I mentioned in my post mentioned above.  The sychronization can be automatic or manual as desired by the user.  Library archive backups can be performed automatically before changes to allow for regression in case of an error or unwanted / accidental change.

The thing is , none of this is new.  Multi user relational databases have been around since I have been working with computers and that is a long time.  There just needs to be a command decision made to support it and move on.
Comerical dBs, create timestamps that allow you to roll back to a certain date/time. To be able to do this requires transaction support as every insert/update that is made against the dB is recorded. It would also have to offer internal locking of records during an update. Commercial dBs are designed from the ground up to be multi-user so you can take these features for granted.

MC can save a copy of the dB everytime a change is made and there is support for this currently but this gets unwiedly quite fast. This is strictly a one user option.

As you can appreciate hacking this into the current MC dB is not a trivial task. It would require a shift from its dependance on the filesytem for these features to actually supporting it internally. MC's dB would require a re-write.

At which point JRiver do a cost-benefit analysis and it gets swept under the rug ;). This also would imply a certain PRo quality which would be dearer than the current single user version. Would the majority of MC users pay more for this ?

Personally i think this would be a killer feature to have (for the reasons you mentioned) and widen the 2 yr gap between MC & it's competitors. Does that mean they got 2 yrs to implement it ;).


Other players have interesting ways of dealing with the same problems.

Music Match for example although quite inferior in many other ways has a seemingly clever way of dealing with this problem.  All tag and library information is stored within the file.  Even on wav files (some may remember my pleas of many years ago asking for wav file tagging).  At any rate when a new instance of Music Match is installed  the client just does an import and the library is all there.
You can do this in MC if you override all fields to save to file. But then your backups will take longer. I chose the middle ground where essential tags etc rating are written to the file and the rest is just saved in the library.


  The new or updated songs are automatically added to the client through a function called watch folders.  Any time a song is added to a watched folder it is automatically imported into the library.

This does not deal well with all the other cool aspects of Media Center's Library like playlists play counts etc. etc., but I think it can be an example of how to deal with the problem of managing or at least adding to the actual music portion of the library.
Thx for clarifying where the watch folder concept orginates from. I have not felt a need for it to date. I have a TO-Listen disk partition where any thing new gets added, then i do an AA and rate it. If i like it it gets shifted  to its final destination & imported else it's trashed.

A watch folder would not work in the case as it supposes one or a set of folders and everthing gets dumped in it. I don't want to depend on MC to organise where files are stored, just to present different views of it.  I still maintain a genre hiearchy in the file system. So i manually shift an album to the right genre parition before it's imported anyway.

This also has the advantage of reducing file fragmentation as file altering operations are all done in one partition. The only downside is that the playcount is 0 when its imported into MC instead of 1 but that's acceptable to me.

I prefer to explicity import into MC rather than have it automatically do it.

As far as using Remote Desktop to manage the Main Music Server, the JRiver Application does not run as a service and therefore must run as an aplication in a logged on session.  As such, to get it to work automatically at boot time, one must auto-login the console session and  launch Media Center at startup time. 
Not sure i understand this but are you saying its not possible to have MC's server automatically startup after a reboot ?

This may require a 3rd party utility, i vaguely recall it being done that way.

I still think that automated Library: backup (from server), restore (to client), backup (from client) restore (to server) has some short term workaround potential, I just can't figure out how to automate the file naming and execution part.
Sounds quite hairy the way you describe it ;)
Logged

johnp

  • World Citizen
  • ***
  • Posts: 145
  • let your 'Yes' be 'Yes,' and your 'No,' 'No'
Re: Many clients sharing the same library?
« Reply #12 on: November 16, 2005, 11:24:52 am »

All points well taken:

AS far as cost goes I would be willing to pay for a dealer / pro version of this product to get these features.  I shutter to think of the cost, but I am willing to cough up extra $$ to get this type of "server" functionality.

Regards,

John
Logged
Pages: [1]   Go Up