[Finished] Improve Relations in the MediaLibrary (1 Viewer)

[MJGraf]

Hi everybody,

I wanted to share an idea to improve our MP2 MediaLibrary, but before creating a Jira entry, I'd like to get some thoughts on how you think about it.

The idea first came to my mind, when reading this post of Albert: https://forum.team-mediaportal.com/...ust-allow-other-dbs.113769/page-5#post-941001

Maybe some background first for those of you, who are not so familiar with MP2, yet. In the MP2 server we have two kinds of objects, which are important for my idea:

• MediaItems: MediaItems are something you can watch or listen to. Examples are an MP3 file a JPG file or an AVI file. But it could also be an URL to a streaming source in the internet.
• MediaItemAspects: MediaItemAspects are used to store metadata for the MediaItems in our MP2 server's database. A MediaItem can have multiple MediaItemAspects. For example, every MediaItem has the MediaAspect. There we store things like the "Title" or the "Playcount". But the same MediaItem, if it e.g. is an MP3 file, has the AudioAspect, where we store for example the "Artist" of that song. Title, Playcount and Artist in these examples are called "Atributes" of a MediaItemAspect.

Now these Attributes are stored as fields in our database and, as such, also have a cardinality. we support all cardinalities, i.e. inline, 1:n, n:1 and n:m.

But: While the datatypes we support (many simple datatypes, string and byte[] for binary data) are definitely sufficient for inline attributes, I think they are an extremely limiting factor for 1:n, n:1 and n:m relations.

Let me give you an example: "Artist" in the AudioAspect are a n:m Attribute - which is correct, since one artist can have multiple songs and one song can have multiple artists. But now we only have this attribute as a string. This has two disadvantages:

• Firstly, if there are two artists with the same name, they will be stored as one artist. But this is a minor problem currently, because we really just store the name of the artist so it just doesn't matter if MP2 treats them as the same artists, because the name as the only information we store is the same for both.
• The much bigger limitation IMHO is that we cannot store "attributes for attributes". In this example I would e.g. like to store FanArt for this artist. This is currently not possible because "Artist" is only a (string) Attribute in the AudioAspect.

Now the idea is to store the n-side of 1:n, n:1 and n:m as separate MediaItemAspects. This way, we could have a MediaItemAspect called "ArtistAspect", which is then in a n:m relationship with the AudioAspect.
I also thought about treating e.g. Artists as separate "MediaItems" - not MediaItemAspects, because from a non-tech-feeling you could also say "Play AC/DC", so that it starts playing songs from AC/DC. So from the definition above, one could also think of an Artist as a MediaItem.

And I'm not only talking about Artists here. It would of course also affect e.g. albums, genres, etc. And for albums e.g. we could only store the album cover once - not several times for every audio file.

I'm not sure how much work it would be to implement it. But in any case it would break a lot of other parts of MP2, since this is a very "deep" change and so I wanted to start this discussion before we are heading to an MP2 final release and we eventually get more developers, who start using our MediaLibrary.

Any thoughts (also from MP1 people!) are welcome!
Michael

 

[HTPCSourcer]

Completion of MIA rework has successfully addressed all of the above.