Print

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

[JimH]

[I'm copying Matt's post from the release thread because I think it deserves a thread of its own]

Matt said:

Some more details about the database changes:

A Media Center 11 library can not be used by Media Center 10.

We will assume you have a valid Media Center 10 library backup when putting out future alphas.  That means there'll be no upgrading early alpha libraries -- you'll need to upgrade from your MC 10 backup.

Some of the new database improvements:

• Faster and less resource intensive.
• Only changed fields get saved -- no more "Saving database..." lag with large libraries.
• The data in the database can be completely unloaded when it's not in use.
• Some fields like lyrics, notes, text, get compressed in memory and on disk for about 10:1 space savings.
• Duplicate values only use disk space and memory once.

On the horizon:

• A new caching layer that works a little like a browser cache -- making it so your computer won't have to do work to sort or build lists of things it has already done in the past.

[Jaguu]

Relational database?

Does it mean that I could define some tags just related to an artist such as Artist Name, Birthdate, Nationality, Biography etc?

[Matt]

Relational database?

Does it mean that I could define some tags just related to an artist such as Artist Name, Birthdate, Nationality, Biography etc?

Create a field like "Artist Biography."  Then just put the same bio in for all the tracks with that artist.

The actual data won't ever be on disk or in memory more than once.  And it'll get compressed if it's really long.

When the field hasn't been used for a while, it'll get unloaded so it's using no memory at all.

[Tolga]

Cool !

[AoXoMoXoA]

You KNOW I have been waiting for this . . . .  
Any idea when it will go BETA?

[Robert Taylor]

Is this the new database which will allow updates from multiple clients?

If it is, I promise I will put my underpants on my head, and run down my neighbourhood street in the nude...

After I get out of jail, I will have a party, and drink an enormous amount of bourbon...

[Sir Alan]

Any idea when it will go BETA?

Just as soon as they think that anyone who paid to upgrade to 10 six months ago is ready to fork out again...

[Marty3d]

Are there any plans / thoughts about a better date handling in this new database? I've been talking about this a couple of times. You know, assigning a separate date each time a song is played etc. so you can use it to create Views like "Top 10 list" for each day/week/year and so on.. It would be SO great!

[Matt]

Are there any plans / thoughts about a better date handling in this new database? I've been talking about this a couple of times. You know, assigning a separate date each time a song is played etc. so you can use it to create Views like "Top 10 list" for each day/week/year and so on.. It would be SO great!

Keeping a list of dates is simple, but it'd be hairy to view or use that field after that.  If you've got a slick solution, start another thread and we'll hash it out.

[Matt]

Is this the new database which will allow updates from multiple clients?

If it is, I promise I will put my underpants on my head, and run down my neighbourhood street in the nude...

After I get out of jail, I will have a party, and drink an enormous amount of bourbon...

If that isn't motivation, I don't know what is.  What you're describing is a really complicated problem though.

The first step may be to allow just one client to open with read-write access at a time.  Other clients would get read-only access until that client closed.  Kind of like a Word document on a network share.

[RandyP]

The first step may be to allow just one client to open with read-write access at a time.  Other clients would get read-only access until that client closed.  Kind of like a Word document on a network share.

This is the most important step to me - it lets me manage our family's music while the others are listening to it. They're set up for read-only access to the main music collection for "damage control" already. The same thinking applies to the digital photo album on the server, too.

From my family's viewpoint, the best implementation is having individual ratings and playlists, along with mutual access to the read-only music and image collection. Global playlists and/or easy playlist sharing would be cool.

[JustinChase]

While we're asking, how about smartlist and view scheme sharing too.  It would be pretty cool to be able to easily share those customizations as well.

Maybe an optional "Suit" to go on top of the "skins".  That way someone can publish their totally custom MC layout.  Playlists, smartlists, view schemes, Hairstyles, visualizations, plug-ins (maybe), tree layout, custom toolbars, everything we can customize, published in one easy to install package, just like a skin.

Then I could see how Matt, or gpvillamil uses MC to manage their libraries, I could use some (or many) of their ideas, schemes, etc, along with some from gamer, or James, and mine to create a truly custom Media Center.  I am guessing many people have some totally 'tricked out' implementations, and are probably doing things better than i am.

It would be great if we could easily share ideas just like skins.

What do you guys think?

Insane?

No?

[Robert Taylor]

Hey Matt...

Forgive me, for I am not a programmer, but couldn't you do something like:

On the Media Server end there's a thingy (like a broker), who is the only dude who has complete access to the DB.

On the Client end, all the updates get sent to the broker, so they don't need to talk to the Db directly...

That way it's only ever the Server machine which needs exclusive access to the DB...which is pretty much as it is now isn't it?

It's amazing how you can make things sound so simple when you don't know what you're talking about isn't it? 8-)

[IanG]

On the Media Server end there's a thingy (like a broker), who is the only dude who has complete access to the DB.

On the Client end, all the updates get sent to the broker, so they don't need to talk to the Db directly...

That way it's only ever the Server machine which needs exclusive access to the DB...which is pretty much as it is now isn't it?

That's the way to go, but it's not simple - MC currently expects to get instant access to the db, and that isn't going to happen with client / server.  It's a bit like feature requests to this forum - some people submit a request and then either acknowledge the response or wait for a reasonable time before politely repeating it.  Other people throw their toys out of the pram if they don't get an instant positive response.  Another group will just give up if they don't get an answer.  The trick is to ensure that MC always behaves like a model citizen.

And then you get conflicting requirements....

Ian G.

[JimH]

Other people throw their toys out of the pram if they don't get an instant positive response.

[grahamk]

Let me just pipe in and say that a DB that can be accessed/changed from multiple clients would be a huge step forward for MC.

I have a  network mounted database that is accessed on mulitple systems. I would like to be able to update tags from any one of them, and have the change appear on all instances of MC. I wouldn't put underwear on my head and run down the street. But I'd pretty much pay whatever you asked for the upgrade license. :-)

Graham

[Jonas]

Let me just pipe in and say that a DB that can be accessed/changed from multiple clients would be a huge step forward for MC.

I agree 100%.  I'd love being able to set properties and create / change playlists from the living room computer, or from work.  This would be a major reason for me to upgrade to MC11.

Having read-only access from all but one computer would be fine for my purposes.  I don't think I'll be doing concurrent updates.

[soren]

Jim,

Databases do this all over the world every day
Not sure what databases you use, but locking mechanisms must be included???

I've often wondered why you don't implement what someone above called a broker.
This kind of message broker could be integrated in the media server to make it bidirectional.
Well maybe it will put too much load on it ... a second server app on another port might be better

Updates do not have to be instantaneous .. queing should work just fine.

Not to be ... but if you wrote the database layer nice and clean, this change will be a smooth ride

/Sören

[AZ_JazzyJ]

Another alternative (although a huge architectural change from how MC currently operates) could be to move to a data independent model where the MC client and database are separate.  This would allow a client to use a request/response paradigm to a database interface for updates.  The client and database could reside on the same machine or could reside on different machines and that should not matter.  This basically creates the database piece as a music service it is just that the service is local to your network rather than outside (such as iTunes or Napster).  A standardized request/response mechanism could be developed that could be extensible to make requests to other services such as those on-line or even within neighborhoods (a neighborhood in this example is within a household not a physical neighborhood although that would be possible if you could establish access based on read-only rather than allowing sharing.  This of course would be a huge security implication that I personally would rather stay away from).  By moving to a services based application, it could open up alternative markets such as on-demand music or video delivery if those industries invoke that product type.  It will also lead to data sharing among devices such as a PC, PDA, Hand Held device, or in-house music service.  The messages being delivered to and from the client to the database could easily be XML thereby opening up the architecture for others to extend where JRiver does not want to include a feature within the standard product.  Just a thought.

Jeff

[Robert Taylor]

Just another small point which occurred to me about client server (again spoken as a programming ignoramous).

IanG mentioned how hard it would be to have "instant access" to the DB, Soren said "it may put too much of a load" on the server. I mean...I'm using MySQL DBs to access data from PHP web pages at work. I could have hundreds of clients connected at a time. (I know MySQL is a different kettle of fish from MC, but...)

My understanding is that MC supports around 3 clients. That doesn't seem like a huge load to impose on a DB server to me...

[IanG]

Just another small point which occurred to me about client server (again spoken as a programming ignoramous).

IanG mentioned how hard it would be to have "instant access" to the DB,

Sorry, I didn't make that point very well!  What I meant was that a db has to be designed to work as client  / server.  I'm assuming that MC's wasn't, so there's a lot of development work involved.

Ian G.

[IlPadrino]

It befuddles me a bit to see talk about database engines...  I mean, come on...  Codd died last year, but he once said "At the time, Nixon was normalizing relations with China.  I figured that if he could normalize relations, then so could I."  My point is that this isn't exactly a new field; ACID properties have been standard fare for quite some time.

Me...  I would like to see MC use a common database server that opens up the MC structure to standard tools (e.g. XML queries, etc.).  

[salsbst1]

Another vote for client/server here

[salsbst1]

I'd be 90% satisfied if Media Server could turn into "Database Server", so that my clients could share a Samba file server to read media files while sharing an MC Database via MC Server.

[negopus]

Create a field like "Artist Biography."  Then just put the same bio in for all the tracks with that artist.

The actual data won't ever be on disk or in memory more than once.  And it'll get compressed if it's really long.

When the field hasn't been used for a while, it'll get unloaded so it's using no memory at all.

I have some questions on MC11's relational database, since I'm used to traditional relational databases, with tables, fields, constraints (foreign keys).

How does MC automatically understand the structuring of data. If I define an "Artist Bio" field, do I have to fill the "Artist Bio" field manually with identical data for each occurrence of a given "Artist"?

And if I change a single "Artist Bio" afterwards, while I listen to a single track ot that "Artist", will "Artist Bio" changes be propagated to all the occurrendes of that "Artist" (as in a relational database with ARTIST table and ARTIST_BIO field, when I update the ARTIST table)?

It seems more a smart compression/memory management algorhytm than a relational database.

[hit_ny]

It seems more a smart compression/memory management algorhytm than a relational database.

And allowing for updates from more than one single client.

I think the same. So unless they are incorporating an open source database (unlikely), they wont be able to create a full-fledged one. Licensing one would prolly dbl (if not more) the cost of the final product.

In fact i don't disagree with this approach, it looks like it would suit user's needs pretty well (more efficient + client side updates).

Why is a "relational" database required at all ?

[negopus]

There are many advantages that arise from using a real relational database. They would greatly improve the audio experience.

First of all the user would fill/download the Artist and Album information only once, and it would propagate to all relevant tracks.

Currently, you have to manually fill the Artist and Album fields for every single track. Maybe there is some other way of working, that I am unaware of. ?

Also, suppose that the user is a music rewiever, listening to an album. He suddenly wants to write a comment on the album on the fly. If he updates the "Album Comment" field on a single track, all the remaining tracks of the same album would remain unaligned with the latest comments.

So the relational database is a feature for power users, who work with additional information a lot.

[hit_ny]

Currently, you have to manually fill the Artist and Album fields for every single track. Maybe there is some other way of working, that I am unaware of.

I can't see this changing whether the dB is relational or not, data entry is still required whether this is done by the user or getting it from  the web.

Also, suppose that the user is a music rewiever, listening to an album. He suddenly wants to write a comment on the album on the fly. If he updates the "Album Comment" field on a single track, all the remaining tracks of the same album would remain unaligned with the latest comments.

Again i cant see how this changes, you have to explicitly tell MC which tracks to update. In this case it would be all tracks in the album. Currently, you select the relevant tracks and enter in a comment (if applicable) and it gets done in one go.

Oh i'm not sure about this but i think as far as the data is represented in the library, i think that comment that was just applied for the album on a bunch of tracks prolly gets stored in one place (in the library) and the others reference it. To do otherwise seems to be quite wasteful.

i think this needs some clarification. people's libraries have balooned to incredible sizes once they decided to import bios, lyrics etc. with a resulting slowdown. i have a feeling this is what JRiver means by storing on one place.

So the relational database is a feature for power users, who work with additional information a lot.

I must be missing something here.

[negopus]

Currently, you have to manually fill the Artist and Album fields for every single track. Maybe there is some other way of working, that I am unaware of.

I can't see this changing whether the dB is relational or not, data entry is still required whether this is done by the user or getting it from  the web.

Well, this is one of the feature of the relational DB. TRACK is the child table, ALBUM is the parent table. You update the ALBUM table once, and the changes immediately reflect on all the tracks of the album.

i think this needs some clarification. people's libraries have balooned to incredible sizes once they decided to import bios, lyrics etc. with a resulting slowdown. i have a feeling this is what JRiver means by storing on one place.

Maybe MC11's relational-like features (compression) were added just to help people filling their DBs with bios, lyrics and so on, keeping the DB size small (and keeping performance reasonable). In this (typical) scenario the DB use is almost static, however.

My need is for a frequently updated DB instead.

So the relational database is a feature for power users, who work with additional information a lot.

I must be missing something here.

You are missing nothing, hit_ny. I am just repeating the same concept in other words.

[IanG]

Suppose I have a track by Gordon Giltrap and I load a bio for him.  The next track I tag with his name will automatically have that bio associated with it.  It works retrospectively, too - if I already had 100 tracks and then entered the bio I'd be able to access it via any of them without doing any more work.  That also applies to any updates to the bio.  

Ian G.  

[negopus]

Correct, IanG. This is exactly the way a relational database works.

[TarbhUisge]

Just a thought...

MC could be pretty easily served by using TinyDB.  This would provide the functionality - I believe - everyone is looking for.  It is small, fast, cheap,  relational and could be easily packaged with MC as opposed to other RDBMS'.

I have been using a program - MyBase - for a few years now that is based on TinyDB and it is quite impressive even for a large - 150MB - dB that contains TEXT, IMAGE (BLOB), etc... and works in a multi-user environment.

See:

http://www.tinydb.com
http://www.wjjsoft.com

Thanks - Tim

[adamsp70]

A relational database would also be able to provide a solution to the "best of" problem which is that identical tracks appear in the original album and the "best of" (and other album collections like the "Now" series)

Seems silly to keep an identical copy of the MP3 with only differing tags, but you want the track to be included when playing both albums.

[AoXoMoXoA]

I am unclear on something;

Should I change anything about my bio or lyrics storage to take advantage of the new database?

They are currently stored in the file tags
(bio repeatedly stored in each song by the same artist)

 ?

[c1c9k72]

Is there any chance that, once this database gets all the kinks worked out of it, that we may be able to get to use it in v 10 ?

[negopus]

MyBase. Great program! I wasn't aware it was based on TinyDB.

[JimH]

Is there any chance that, once this database gets all the kinks worked out of it, that we may be able to get to use it in v 10 ?

Doubtful.

[jplumey]

Me...  I would like to see MC use a common database server that opens up the MC structure to standard tools (e.g. XML queries, etc.).  

I'm with you as well. Bundling a small DB server like TinyDB with MediaCenter would undoubtedly increase the price of the software but as someone mentioned in another post, this could open up opportunities for releasing a "Pro" product that featured that functionality.

The "Pro" version could offer things like more concurrent users, special features for DJ's or clubs who wanted to use the software to manager their music. How about connecting MC to a store audio system for playing over the PA? How about MC serving as a repository for companies doing any kind of team-oriented work with media (studios, video and audio production companies, websites, etc.). How about using MC to power a network of kiosks at a music store or a convention?

Adding a separate DB and a properly architected client / server model would open up a whole new world!

I for one think that MC is an undiscovered jewel. When I show my friends what I can do their jaws drop. I showed them how I can get to any song in about three seconds and next thing I know they're online with their credit card. If JRiver really wants to take the product to the next level, they ought to seriously consider adding this functionality. The overhead of including a small db server is pretty minimal to the overall gains that can be realized.

[rfehr]

Someone suggested a "fake" multi-user capability where the client having the database open for write access would have to release control prior to annother client gaining write access.

Given the difficulty (from what I hear) in implementing a 'true' multi-user database, I think the above is a great short term "finger in the **".

In my case, the media server is headless and would never have write access to the database - it would only need to be notifed that the database has changed so it could be re-loaded.

All of the write access requests would come from networked PC's arround the house.  One caveat v.s. MS Word implementation - Library Server would post a "<clientname> has requested write access to the media database" with an auto release on a 10 second timer.  This way, a potentially unattended but running MC client could not completely prevent write access from other clients.

This would solve 90+% of my issues and I'd bet that it would do the same for most people in this post.