Print

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

[benn600]

With the recent stirring up of a server/client system and users/permissions, I'd like to bring up separating MC into two pieces:

1) Media Database
2) User Details (Playlists, Play Count, *and program settings*)

You may have read my DVD tagging thread.  If MC could utilize two portions, as explained above, then I would not have any trouble keeping the Media Database portion up to date and wouldn't need tagging info stored in the files (as much).  I still like tags in files because it means the MC database is not mandatory for "continuing existing."  I never like relying completely on a program's database.  The files are mandatory for enjoying them...MC "technically" is not.

Specifics obviously need to be worked out but this is a start.

[johnnyboy]

I've thought this for years, just never said it

[benn600]

Take your household of music listeners--creating a relational database for the entire household requires the above.

For just one person, go ahead and combine the two majorly different pieces of the puzzle.

[Alex B]

Instead of trying to create the requested true client/server system, which would need a completely
different database engine and structure, something like this could be a good start towards a better
multi-users system.

I can imagine that the following could be relatively easy to accomplish:

- Add some automation to the current "shared library" feature. (Does it have an official name yet?)
  The initial start up process is currently a bit too complex task for many users. MC could automatically
  create the needed network shares and translate the filename paths according to the created
  share names so that the users would not need to move the media files.

- Add an easier way to promote one of the MC instances to have the write access.

- Make possible what is suggested in this thread. Each MC instance could have a "personal"
  subfolder for client specific database fields (user ratings, playlists etc) in the shared libary folder.
  Each MC instance would always be able to write these fields. Maybe MC could display a list of
  unconnected "accounts" when the shared library is loaded. Then it would not matter which PC is 
  used for opening a personal "account".

- A global play count could be maintained by summing the main library and user play counts.

[benn600]

Those are some good ideas.

Remember that on your server, you can still use the network addressable shares, //Chenbro/titanium/Music/[Artist]/[Album]/[Name].flac

That way it will work all over the network.

[hit_ny]

If MC could utilize two portions, as explained above, then I would not have any trouble keeping the Media Database portion up to date and wouldn't need tagging info stored in the files (as much).  I still like tags in files because it means the MC database is not mandatory for "continuing existing."  I never like relying completely on a program's database.  The files are mandatory for enjoying them...MC "technically" is not.

what does this mean ?

that you would like to save user specific info like rating etc for a file in the database ?

..and not anymore in the files ?

cos if you are already saving that stuff in the files then why do you need user specific sections in the DB

 ?

[benn600]

It needs to be in the files for backup preservation.  If I move files on the server and a user's MC notices that, it may lose the tags.  Luckily they are stored in the files.

The tags cannot be just stored in the files because that would be painfully slow checking all the files to get all 14K song tags.

[llafriel]

I also miss the ability to create playlists and set ratings from clients. What if the client communicated what was changed to the server, and the server updated its library accordingly? I know ratings could work this way as I do this already via my ppc and Netremote, well I think it works that way..