Master Media Database implementation/design. Comments please

[MariachiElf]

I'm going to be implementing a Master Media Database whose primary purpose in life is to store unique identifiers and references to all pieces of Media spread throughout all of MP in one central location and associate "id tags" to said elements.

Imagine if you will a big physical CD album case on your coffee table with cards in each of the sleeves. Each card represents a particular piece of Media (a movie, a photo album, a Music Playlist, the latest episode of a TV recorded series). Now if you want to initiate playback of any of those items, you punch in the number on the card via your remote control or keyboard, or you run your barcode scanner over it, or if you're like me, you swipe the card over your RFID Reader, and magically MP starts to play it back.

There are two problems with this vision and the current state of MP.

First is that there currently is no central place to lookup a tag associated with any possible Media Type. Under the current architecture, I would need to know about each database type in advance and then add a table to each of those databases and then whenever a "tag" arrived, search each database trying to find which one had the "tag". While it would work, it's horribly inefficient, intrusive on the owners of the existing databases, and not very scalable because everytime a new database came online, my plugin would need to be updated.

Second there's no centralized way via an API call that I can find to tell MP to initiate playback of this Media Element. So let's say the end user requested a movie, and they were currently listening to background music from a CD. This request would involve asking the CD player UI to stop playback (allowing it to remember the point it was interrupted), have MP navigate over to the Videos UI and then initiate playback of the requested movie. The plugin would need to know how to properly stop each UI, tell MP to navigate to another UI, and then know how to initiate playback of the requested media in the new UI.


So I see the need for a Master Media Database coupled with some new methods that UIs wishing to allow playback of tagged elements would implement. At the least, this database would contain two tables. One that held all Media Elements that had some kind of a tag associated to them and their actual location in their "home" database, and another that held the tag to Media Element mapping. Each Media "silo", as I call it, that wanted the ability to tag the elements it stores for playback would via an API insert the element to be tagged into the Master DB and implement a UI to associate a tag with that element. Further, they would need to implement a way for an outside plugin to ask it to initiate playback of said media element (I have no idea what the best approach for this is), as well as for an outside plugin to request it stop playback and prepare to close.

In this "minimal" form the only items in the Master DB are the tagged elements. It does not contain a reference for every media element in all of MP. This is the level I intend to implement in the first round.

On the other end of the spectrum, this database is a fully indexed and searchable database of every media element MP currently has stored on any machine in the MP installation site and can adhoc aggregate new media "silos" on demand. I'm not going to implement this version any time soon.



For each Media Element how should I store the "local" reference? I was thinking the Element table would look like this:
| Master ID | UI Plugin Name | Media Type | Media ID |

Master ID - A globally unique internal number to reference this element

UI Plugin Name - The name of the plugin responsible for playback
Media Type - An indicator to the UI Plugin on how to interpret the Media ID

Media ID - The identifier the UI Plugin will use to uniquely identify this Element.

Both Media Type and Media ID would be passed to the UI Plugin when requesting playback.

I was thinking the "Tag" Table would look like this:
| Master ID | Tag Class | Tag ID |

Master ID - Same as above, the globally unique identifier for the Element

Tag Class - A "namespace" for the Tag ID, think of "RFID", "ISBN", "KeyedInput" as posible values for this field. A way for different input device types to prevent collisions in Tag IDs. Each "Class" would probably also have its own Process Plugin

Tag ID - The actual ID that the outside world would provide


In addition to this central database, I believe there should also be a central process that received these requests. External input plugins would submit their "Class" and "Tag ID" to this central process and it would handle the details of implementing the results.
I was thinking this is very much like a control MP from the Web Plugin and was thinking of trying to somehow use that model (if not that same plugin) here.


All input is much appreciated. I would especially like to here from folks on the UI side who can envision how I might go about actually implementing all of this. Specifically, how does an end user actually use the UI to associate multiple different tag classes and IDs to the same element knowing that some will be "read the next tag from the RFID Reader" or "Read the results of the next barcode scan" -- I guess a call back to the Input plugin of some kind... And how do we cleanly switch from playback of one media to playback of another...

[Bram]

What is a RFID Reader?

I can't realy give you any comment that would help you I think. Altough your plan sounds logical and, from what I read in the forum, it would be nice to make the base of MP a bit more universal.

[NLS]

RFID must be RSS feed?

Anyway this will never work without the cooperation of some of the core devs and the major plugin devs (my tv, my videos, my music)...

Good luck.

Do try Meedio and see how it implements databases. You can find versions 1.38-1.41 for free (no activation needed).

[CHli]

RFID is a little chip that you can place anywhere and that can be read contactless. It can contains some KB of datas.

In a few years lot's of ppl will have an RFID inside their body (ID Card, Medical Archive, etc, will be stored in it) f34r !

[NLS]

no thanks

[MariachiElf]

RFID is Radio Frequency IDentification.
Think of it as bar codes read via radio waves.
You can uniquely tag every item you have, throw them all in a bag, walk through a door that has a reader in it and read the tag of every item in the bag. Of course my reader is a simple thing with just a 2" range and can only read one tag at a time. But the RFID Reader isn't really important to the overall design goal. Substitute "RFID Reader" with "Numbers keyed in from the remote" and you get the same result.

I agree it won't work easily without support from the core and main plugin devs. Which is why I'm posting here first. A well thought out, clean, and easy to implement design, as well as evidence of the feature's desirability from the user base help a lot in making architectural changes. Fortunately, the more I think about it, the less intrusive my design is becoming and it's more an add-on then a redesign.

Thanks!
More comments please, this is great!

[mzemina]

MikeFair - Where did you get the reader and the tags?

[MariachiElf]

http://www.phidgetsusa.com/

I got their RFID Kit with the RFID Toys book.

However in the RFID Toys book he identifies other sources for hobbyist and more professional readers depending on the features you're looking for.

[patrick]

Originally Posted by MikeFair

For each Media Element how should I store the "local" reference? I was thinking the Element table would look like this:
| Master ID | UI Plugin Name | Media Type | Media ID |

Since you asked, a few suggestions:

--- Add Optional Media Location
- Ex AFAIK Music Playlists are not stored in the music database but
read from the specified location at run time, this way the media
object would not "have" to be in a database.

--- Add UI Plugin ID
- IIRC Two Plugins can share the same name but not the same "ID"

--- Media Label (and maybe label2 and label3)
- Text string(s) so the user will know what it is
This could help if you, for example, wanted to prompt/ask the
user before actually causing the media to "play"
you would not need to make a call to the music/video/etc plugin
to do a db lookup just to get the labels.

Not really sure what your question is for the associations UI
and Input plugin so not musch help there.

HTH,
patrick

[MariachiElf]

That's exactly the type of feedback I was looking for!

-- Media Location
I think adding an optional Media Location is a good idea, that way the Media Type can be used as a human friendly name to be presented to the end user, and the optional Location could be used to clarify the location. Type, Location, and ID would all be submitted back to the UI.

-- Use UI Plugin ID
Didn't know there was an ID, much better. Replace UI Plugin Name above with UI Plugin ID.

-- Media Label
I keep going back and forth with this one. Is there any UI interaction directly from this database. I certainly agree that if there is, then this text field is most useful. On the one hand the user requested the "tag", the only thing that truly understands how to interact with the Element associated to that tag is the UI Plugin. So how about this. I'll add a "command" to the "Tag" table that way when the UI associates the tag to the element the user can choose then what is meant by the tag. To keep things easy to use I don't think a confirmation window is appropriate here. I'm also concerned about keeping things updated. I don't want to add a second copy of the title of a Media Element if I don't have to because I don't know how they would be kept in sync. The last thing I want is for the UI devs to have to manage not only their own label for this thing in their own DB, but also the copy of it in the Master DB.

On that note, I personally feel that Elements really have many names and there really should be an "Element Name" table just for tracking that.

Thanks for the feedback! Keep it coming this is getting good.[/quote]