• 1
  • 2
  • 3
  • 4(current)
  • 5
  • 6
  • 20
New DB Structure for all libraries + DBs [update 2015 06 13 / Released SQL 1.3]
#46
(2014-08-14, 16:03)jjd-uk Wrote:
(2014-08-12, 12:02)da-anda Wrote: One of the next things he likes to refactor/cleanup are the profiles and especially the permission handling and content filtering. So if we can come up with a good idea/solution on how to handle access to media and everything related (genres, actors, ..) for profiles, Jonathan could refactor in that direction.
One annoying thing about Profiles & the way the database is currently implemented, is that it doesn't cater well for a multi-user environment.

Currently you can either have:

a. Profiles which have separate databases so each profile can have it's own watched status etc, however the downside of this is that metadata needs to be scraped for each profile.

or

b. Profiles which share the master database so metadata is only scraped the once, however it's then not possible to have separate watched status for each Profile.

The ideal solution in my opinion would be:

1. Profiles are assigned the sources that they will be allowed to access along with a permission level.
2. Metadata is scraped the once so a single metadata store is always maintained and can be initiated by any Profile that has permission, thus metadata is shared between all profiles that have access to a particular source.
3. Each profile to be configurable as to whether user actions should be tracked on a per profile basis, so for example the database could assign watched status per profile.

All of this will be very easy to implement in the structure I proposed.
Will now work on a new file format easy to read!
If you think I'm useful please use the +/- button to raise my reputation
Reply
#47
I've looked both schemas... and I think the model I'm proposing it includes the core concepts of both of them but is a little better (Tongue hehehe)...

Introducing the concept of Asset will create a lot of freedom as well as introducing the Person
Also I introduced some optimizations, for example is useless to repeat for every HD movie the size, we have a size table and refer to one instance of the size!
If you think I'm useful please use the +/- button to raise my reputation
Reply
#48
I've installed Oracle Data modeler (is really free!!!) and started the Logical model based on my initial design, MedioOS and MediaPortal as well as Amber Media Manager.

I'm now focusing on adding ALL the logical entities we need, I've NOT (yet) added all the attributes as this is very time consuming; I will do that after I lock the logical design.

Can you please review it and let me know what I forgot?

Note on users filtering:
Right now I'm assuming we will use a bitmap field filtering to be quicker and manage it easily. In the essence this is the idea:
UserID: 2^x (this means user ID will be 2,4,8, etc... so that each user has just one bit at 1 and all others at 0)
Permission/Visibility: is a bitmap field if the bit of a user is at 1 the field is enabled

User check: is simply UserID AND Permission <> 0 -> user is enabled
All users: is easy $FFFF
No User: is easy: 0

This is done with integer fields to save space and be very quick. Then depending is the Permission is a visibility or deny the query will be = 0 or != 0.


if this WILL NOT WORK we will have to add a Asset/Permission table.


Shared Folder with file: http://1drv.ms/1lB02N4 (you need to download everything from there Smile )


Note: Oracle desing developer allow creation of the physical model... that's why I'm focusing on the logical model.
If you think I'm useful please use the +/- button to raise my reputation
Reply
#49
Please allow me to provide more details an ALL the request you made so far:
Original design concepts:
1) To be very quick
2) To remove all replicated information
3) To create a relational structure
4) there is a file table that includes all files independently from what they are
5) files are grouped in libraries
6) users can filter libraries
7) an asset is composed by different files (i.e. multipart movie)
8) assets can be: movie, episode, pictures, music, thumbnail, module, etc...
9) each specific asset does have it's own set of specific properties
10) rating/stars are linked to assets
11) series/seasons are a grouping of assets
12) watched is linked to assets
13) there is a path table where we can store any path format and the format is speficied in path/type. In this way we can have Linux based path/samba/URI etc... also path substitution becomes very easy
14) CRC32 is used to identify univokely a file
15) There is one table Persons for every person. Their role is specified in a separate table (same person is a composer, actor, writer director). Asset Thumbnail linked to Person is the art.
16) We need to have 1 DB for everything, thumbnails, music, pictures, games, etc… in this way the code will be more efficient, data will be smaller, etc…

Requests:
1) RetroPlayer being mainlined sooner or later might as well consider adding stand-alone games and game ROMs launched via emulators into the scope of the database model right away as well.
a. Added: Games are just an asset. Please let me know which properties we need specific for a game

2) title, description, thumbnail, tag, "category"
a. Correct is done like that.
b. Note that there is a AssetType table to allow to filter assets. (That is a table so here we can have everything, Movie, Picture, Fanart, Poster, CDArt, Thumbnail, Song, SeriesArt, etc…
c. Thumbnail is, at all effects, an Art element. So they will not have a separate file
d. The Asset2Assets table will create the link between assets, for example the link between the movie and it’s fanart/clearart/cdart, it’s songs, it’s

3) categories above. IMO we also need a flexible categorization for assets, while there should be a way to have global categories (probably using tags for this scenario) and media specific ones.
a. There is a Tags folder that is bound to assets and to types. This will allow to have all tags in a single table and to apply the correct ones to the different assets (i.e. it can be used for genere in movies and for EXIF tags for pictures)

4) Asset group, like a TV-Show, Season or Album? And the interdependencies, like the soundtrack of a movie? Simply add a "movie" db field to an album and link it to a move asset in the later case? Or rather a more generic approach like a "relatedAssets" table?
a. RelatedAssets, is the table Asset2Asset. This will lead to maximum flexibility so you can have a single view where a movie is related to the TV series, to the fanart, to the soundtrack, etc…

5) Your model should also contain persons, be it artists, directors, actors or whatever, while the person itself is neutral, so does not have a specific context. Reason is, the same person could be componist, director, actor, singer, drummer, whatever (Jaret Leto f.e.). So the linking MM table needs to hold the context specific info.
a. Done, great idea

6) If an user wants to split for example tv shows in tv series, anime, documentary and movies in movies, cartoons, anime you can only filter (usually by bath) and you have to manually configure everything because there's no actual separation.. Is there a solution for this problem?
a. Native in the model. You can apply all the tags you want.

7) 1.There have been some threads discussing getting proper support for non-music audio content, like audio books and podcasts, that don't belong in the music library. This might be a good time to lay the foundation by introducing tables for such content. This type of content requires some fields that doesn't exist for music:◦Resume position. An audiobook might span multiple files so they would need a flattening feature, like multi-part movies, and the resume function need to keep track of the position on a per-book rather than on a per-file basis.
a. We can easily add a new table for specific audio contents.

8) 2.There are two interpretations what the "lastplayed" field for video content actually means; The start of playback, or completion of playback. Maybe this field should be split into two to allow for both valid use-cases. More info here: http://trac.xbmc.org/ticket/14441
a. There is a bookmarks table with a time field that is bound to the Asset. What that times means depends from the player. We can add an “integer” position if we need. If we want we can bound that to users to have the per user bookmark.
b. Also we can add a Bookmark type so that we can separate between user bookmars, automatic bookmarks (lat played position) etc…

9) 3.Fields for the number of audio channels, bitrate, bitdepth and language for music to enable smart playlists to filter on those properties.
a. These are properties of the Song asset.

10) 4.Replay gain field for music videos. This is however not yet supported by the player.
a. What is this_

11) movies, cartoons, anime you can only filter (usually by bath) and you have to manually configure everything because there's no actual separation.. Is there a solution for this problem?
a. Tags management is a good solution present in the structure

12) Movies/mature/teen/child: where different profiles would have access to either mature and everything below, teen and everything below, or just child.
a. Can be easily added with a link amongs Tags and users or with Ratings and Users. From a data structure everything is there. Is more related to the application logic.

13) If you guys are revamping the database, can i humbly request that you use meaningful field names. EG the movie table in the current videos78 database has fields
a. All fields must have a “speaking name”. No C01 or similar.

14) is to make smart playlists more and more powerful, so user can create their own library nodes, skins can show content in some sort of widget on the homescreen etc.
a. This data structure will allow a lot of filtering to happen at DB level, having much less data going around and freeing up power for Smart Playlists to work better. The example of parental rating will be handled directly at DB level filtering assets.

15) a. Profiles which have separate databases so each profile can have it's own watched status etc, however the downside of this is that metadata needs to be scraped for each profile.
or
b. Profiles which share the master database so metadata is only scraped the once, however it's then not possible to have separate watched status for each Profile.
The ideal solution in my opinion would be:
1. Profiles are assigned the sources that they will be allowed to access along with a permission level.
2. Metadata is scraped the once so a single metadata store is always maintained and can be initiated by any Profile that has permission, thus metadata is shared between all profiles that have access to a particular source.
3. Each profile to be configurable as to whether user actions should be tracked on a per profile basis, so for example the database could assign watched status per profile.
a. DB should support the ideal model. NO duplicated info. Only one DB and only ONE scraping. Users are stored in the DB and are bound to content with their permission.
b. Right now I’ve bound users to libraries but we can bound users to EACH asset if we want allowing to have a granularity down to level one (you can choose with fanart is shown to who). NOTE: this is at Database level, application should manage all of that 

16) but very functional. fields can be repurposed without renaming them. if a dynamic db is wanted, this part will only get worse.
a. We will NOT have repurposing of fields. With SQL is easy enough to rename a column if needed.
b. Repurposing or hybrid data columns are not meaningfull in a DB like this one. Is not simple but is not that big to have to add such huge complexity to code and developers. Approach is keep it simple -> column name should be reasonable. Queries and code will be much better and readable

17) Watched status was only meant to be one example, for sure resume points, bookmarks and other stuff like that should have the ability to be set on a per profile basis in the database, whilst keeping a single metadata (by that I mean posters, movie info etc) store.
a. Done, and native from the DB

18) Well yes but I prefer to add a reminder, as for watched status in previous post there's was a good proposal about a "log" table to handle this particular thing. So listing what should be tied to profile or not or both may be a good start Smile Anyway since I repeat myself I'll stop but defining the target shows the path, building a path without target have few chance to arrive to correct target Wink
a. We can add that. Explain better what you’d like to see as Log. For example I like the idea that the “last played” smart playlist changes depending on the User that has logged on

19) What we have to take into account:
- restrict media to certain shares/folders
- restrict by meta-data like PG ratings or don't let kids listen to songs with explicit lyrics
- what other restrictions for profiles are required?
- not only filter the media itself according to the rules, but also things like genres (don't show "adult" genre to kids)
- how to do this in a well performing way without having to do (much) postprocessing of the items - so can it be done on DB level?
a. All of this is in the DB strcutre. And Yes the idea is to move all possible filtering and sorting at DB level that is, for sure, more performing than locally.
b. Local layer should only do presentation and postprocessing, not Data functions (filtering, ordering, grouping, etc…) that’s DB stuff

20) The main question about profiles is about external access (as I tried to talk a lot in previous thread), right now you need to log in in Xbmc to activate a profile then all DB access are tied to the profile.
Since it seems one of the future direction is all about central database or replication it's important to decide how those profiles will be used from a remote point of view and internally.
Because profiles are not only tied to database but also addons, cache and tons of things, it's important to know the target first.

21) We can add ALL profiles and info in the DB if we want to avoid having external XML files. At this point XBMC will start and open the main connection to DB, load users and we can move on from there. There is no need to have a per user DB… even on SQL Lite the DB is just ONE with everything we need in there
a. For sure the current DB handing with thousands of connections IS NOT good.

22) "if a new schema happens then it will only happen via incremental changes."
"I'm not saying we don't need a new DB schema. All I'm saying is that it is too big of a task to come with a completely new DB schema that doesn't match anything that is in the current DB schema and replace the whole thing including updating old databases etc. We have to do it in (little) steps and IMO one of them is to get the current schema into something more generic that will be easier to migrate and that will also be easier to maintain in the meantime."
a. NO. Working only on small changes will never lead to the correct design as you will always remain bound to the outdated (or sub optimal) initial design. What we are doing is a new DB focused on performance and efficiency for all platforms.
b. The correct approach is NOT to modify existing DB but to build a simple Migration procedure that will be executed ONCE and will extract the (good) data from the existing DB and will insert it in the NEW DB. After that missing information will be integrated in the new DB. This will need to be really transactional!
If you think I'm useful please use the +/- button to raise my reputation
Reply
#50
Noted this also indirectly ties into the (UPnP) client-server model extensions they talk about here

http://forum.xbmc.org/showthread.php?tid=202930

That is at a early stage so might be good to get input from them as well before get too far ahead
Reply
#51
(2014-08-30, 11:19)m.savazzi Wrote: I've installed Oracle Data modeler (is really free!!!) and started the Logical model based on my initial design, MedioOS and MediaPortal as well as Amber Media Manager.
Have you by the way also looked at MusicBrainz Database Schema which is another good example?

https://musicbrainz.org/doc/MusicBrainz_Database/Schema
http://wiki.musicbrainz.org/-/images/5/52/ngs.png
http://wiki.musicbrainz.org/MusicBrainz_Database/Schema

Their relationship table structure and link table seem to work well.


They have nicely documented style guidelines too for clearification
https://wiki.musicbrainz.org/Style

Could maybe at least copy a lot of their wiki documentation regardless.


Interestingly MusicBrainz took a similar journey back in 2011

https://wiki.musicbrainz.org/Next_Generation_Schema
https://wiki.musicbrainz.org/History:Nex...ma/History
https://wiki.musicbrainz.org/History:Preparing_For_NGS
https://wiki.musicbrainz.org/History:Nex...ma/Roadmap
https://wiki.musicbrainz.org/Server_Rele...s/20110516

So can probably get some ideas how to both politically and practically implement a new DB schema.

That NGS history makes for a good read about lessons learned.
Reply
#52
(2014-08-30, 12:21)RockerC Wrote: Noted this also indirectly ties into the (UPnP) client-server model extensions they talk about here

http://forum.xbmc.org/showthread.php?tid=202930

That is at a early stage so might be good to get input from them as well before get too far ahead

Good suggestion but this is different.
UPnP sharing is 2 independent Kodi that "talk" each other to exchange the content of their libraries.

Here is how to make a Library, how to have a shared DB among different Kodi endpoints, how to have a real DB behind Kodi.

The new DB and UPnP library sharing are NOT competing each other but are complementing each other!


M

(2014-08-30, 12:39)RockerC Wrote:
(2014-08-30, 11:19)m.savazzi Wrote: I've installed Oracle Data modeler (is really free!!!) and started the Logical model based on my initial design, MedioOS and MediaPortal as well as Amber Media Manager.
Have you by the way also looked at MusicBrainz Database Schema which is another good example?

https://musicbrainz.org/doc/MusicBrainz_Database/Schema
http://wiki.musicbrainz.org/-/images/5/52/ngs.png
http://wiki.musicbrainz.org/MusicBrainz_Database/Schema

Their relationship table structure and link table seem to work well.


They have nicely documented style guidelines too for clearification
https://wiki.musicbrainz.org/Style

Could maybe at least copy a lot of their wiki documentation regardless.


Interestingly MusicBrainz took a similar journey back in 2011

https://wiki.musicbrainz.org/Next_Generation_Schema
https://wiki.musicbrainz.org/History:Nex...ma/History
https://wiki.musicbrainz.org/History:Preparing_For_NGS
https://wiki.musicbrainz.org/History:Nex...ma/Roadmap
https://wiki.musicbrainz.org/Server_Rele...s/20110516

So can probably get some ideas how to both politically and practically implement a new DB schema.

That NGS history makes for a good read about lessons learned.

GREAT! will read all of that!

You're right at a certain point all major projects need to re design the database IF they have not started with the DB design at the beginning or if the original design is not able to scale anymore.

Their DB looks great but quite complex. If we want to have all the same data for music we can import their structure in Kodi new DB. Otherwise we need to extract only some infos.

I've started to read this: https://wiki.musicbrainz.org/History:Nex...ma/History with great interest and it's great we are very aligned on the design principles.
If you think I'm useful please use the +/- button to raise my reputation
Reply
#53
(2014-08-30, 13:45)m.savazzi Wrote: Good suggestion but this is different.
UPnP sharing is 2 independent Kodi that "talk" each other to exchange the content of their libraries.

Here is how to make a Library, how to have a shared DB among different Kodi endpoints, how to have a real DB behind Kodi.

The new DB and UPnP library sharing are NOT competing each other but are complementing each other!

I haven't looked at your schema but one concept that might be missing is source and import. A source is basically a path/identifier of a location (filesystem, upnp server, plugin, ...) from where an item can and has been imported. An import belongs to a source and additionally has a media type i.e. from an import you get media items of a specific media type. At least that's what I'm currently using in my media import work (which RockerC linked to). I just added three additional tables called "source", "import" and "importlinks".
Always read the online manual (wiki), FAQ (wiki) and search the forum before posting.
Do not e-mail Team Kodi members directly asking for support. Read/follow the forum rules (wiki).
Please read the pages on troubleshooting (wiki) and bug reporting (wiki) before reporting issues.
Reply
#54
(2014-08-30, 13:45)m.savazzi Wrote:
(2014-08-30, 12:21)RockerC Wrote: Noted this also indirectly ties into the (UPnP) client-server model extensions they talk about here

http://forum.xbmc.org/showthread.php?tid=202930

That is at a early stage so might be good to get input from them as well before get too far ahead

Good suggestion but this is different.
UPnP sharing is 2 independent Kodi that "talk" each other to exchange the content of their libraries.

Here is how to make a Library, how to have a shared DB among different Kodi endpoints, how to have a real DB behind Kodi.

The new DB and UPnP library sharing are NOT competing each other but are complementing each other!


M

Nope he is working on a new way to share Kodi's data. UPnp is only how they are transferred but (I think) it requires some db change for example to define the source and the imported data
Reply
#55
(2014-08-30, 14:04)Montellese Wrote:
(2014-08-30, 13:45)m.savazzi Wrote: Good suggestion but this is different.
UPnP sharing is 2 independent Kodi that "talk" each other to exchange the content of their libraries.

Here is how to make a Library, how to have a shared DB among different Kodi endpoints, how to have a real DB behind Kodi.

The new DB and UPnP library sharing are NOT competing each other but are complementing each other!

I haven't looked at your schema but one concept that might be missing is source and import. A source is basically a path/identifier of a location (filesystem, upnp server, plugin, ...) from where an item can and has been imported. An import belongs to a source and additionally has a media type i.e. from an import you get media items of a specific media type. At least that's what I'm currently using in my media import work (which RockerC linked to). I just added three additional tables called "source", "import" and "importlinks".

I will look into that but I do not think there is a need.

In the DB the core concept is the Asset that is composed by several physical items.
Each physical item is bound to a Filename and a Path. At current stage both filename and path are generic enough to be able to hande ALL possible "sources".
You can store in path a url, UNC, etc...

I'm still looking into that to see what is the more efficient solution for this issue. The library should be generic, accessible at the same time from different OS so there is not an universal "PATH" that can work everywhere.
The Solutions I've seen so far is to store all paths in smb format (Windows) \\server\path and have a conversion into the correct OS format
the other one is to have a prefix
SMB:\\
UX://
WEB:\\
UPNP:...

etc so we know the format is saved in the table path

If you help me undestand better the "source, importlinks" it would be great... if you can make some real case examples
If you think I'm useful please use the +/- button to raise my reputation
Reply
#56
From what I unterstand the filepath might not be enough. One goal is to allow addons to fill the db. There could be two addons who add items from the same website. From an youtube url alone, we do not know which addon imported this video.

Or a TV backend could add a recorded movie to our db. The path would probably be just a local file/or smb or whatever. From the path alone, we wouldn't know that the file actually came from the backend.

Without knowing what the source was, we cannot sync the metadata.
Reply
#57
(2014-08-30, 12:21)RockerC Wrote: Noted this also indirectly ties into the (UPnP) client-server model extensions they talk about here

http://forum.xbmc.org/showthread.php?tid=202930

That is at a early stage so might be good to get input from them as well before get too far ahead

One good thing that was talked in that and in he GSOC proposal is the dataset change sync.

This would be a must for remote makers for offline files.

Imagine you download a file to your phone then watch it offline and have a new resume point.

Then you connect to network and XBMC also have a resume point set, who wins ? What it the last changeset ?

This is a long term change but supporting this would make XBMC a big step forward in it's central media tool for the house.

But linking that with some of my proposals about authentication for remote on a per remote / user token, each remote / token could trigger a changeset start after a sync to then be able to make the decision on reconnect.
This covers not only new media added but also updated metadata or resume point / watched status ......
Reply
#58
(2014-08-30, 15:33)m.savazzi Wrote:
(2014-08-30, 14:04)Montellese Wrote:
(2014-08-30, 13:45)m.savazzi Wrote: Good suggestion but this is different.
UPnP sharing is 2 independent Kodi that "talk" each other to exchange the content of their libraries.

Here is how to make a Library, how to have a shared DB among different Kodi endpoints, how to have a real DB behind Kodi.

The new DB and UPnP library sharing are NOT competing each other but are complementing each other!

I haven't looked at your schema but one concept that might be missing is source and import. A source is basically a path/identifier of a location (filesystem, upnp server, plugin, ...) from where an item can and has been imported. An import belongs to a source and additionally has a media type i.e. from an import you get media items of a specific media type. At least that's what I'm currently using in my media import work (which RockerC linked to). I just added three additional tables called "source", "import" and "importlinks".

I will look into that but I do not think there is a need.

In the DB the core concept is the Asset that is composed by several physical items.
Each physical item is bound to a Filename and a Path. At current stage both filename and path are generic enough to be able to hande ALL possible "sources".
You can store in path a url, UNC, etc...

I'm still looking into that to see what is the more efficient solution for this issue. The library should be generic, accessible at the same time from different OS so there is not an universal "PATH" that can work everywhere.
The Solutions I've seen so far is to store all paths in smb format (Windows) \\server\path and have a conversion into the correct OS format
the other one is to have a prefix
SMB:\\
UX://
WEB:\\
UPNP:...

etc so we know the format is saved in the table path

If you help me undestand better the "source, importlinks" it would be great

It's not just the path the problem. In its new model kodi needs to know what items in the database are from a specific source because it's up to the user to add or not media for specific kodi instances on the network.
In its new implementation when kodi detects another kodi machine in the same network it ask if the user wants to import and keep in sync its media. If the user agree kodi adds movies, tv shows and music in that library and it connects them to the source and update them at every change (watched count, new episode,renamed movie etc etc). So kodi needs to know the media connected to that source and if the user wants to include the changes or not
Reply
#59
(2014-08-30, 15:41)Fice Wrote: From what I unterstand the filepath might not be enough. One goal is to allow addons to fill the db. There could be two addons who add items from the same website. From an youtube url alone, we do not know which addon imported this video.

Or a TV backend could add a recorded movie to our db. The path would probably be just a local file/or smb or whatever. From the path alone, we wouldn't know that the file actually came from the backend.

Without knowing what the source was, we cannot sync the metadata.

I'm not talking of a "filepath" but of "path" a path can be of ANY asset.
In the end and Asset must be bound to a physical object... the path is how to reach that physical object.

On a TV backend can be we channel, can be the satellite channel NIT:etc..
On a share is the path
On the web is the URL
On a UPnP is the path to server
etc...

The filename is the name to identify the physical object.

The model should be generic enough to allow to handle all physical assets.

We can check if you provide me example of physical objects I can see if it works for every case

(2014-08-30, 15:48)Tolriq Wrote:
(2014-08-30, 12:21)RockerC Wrote: Noted this also indirectly ties into the (UPnP) client-server model extensions they talk about here

http://forum.xbmc.org/showthread.php?tid=202930

That is at a early stage so might be good to get input from them as well before get too far ahead

One good thing that was talked in that and in he GSOC proposal is the dataset change sync.

This would be a must for remote makers for offline files.


Imagine you download a file to your phone then watch it offline and have a new resume point.

Then you connect to network and XBMC also have a resume point set, who wins ? What it the last changeset ?

Bookmarks (personal and automatic ones) can be saved per user and can even have a date.
Automatic bookmarks like last played position can have an ID (for example the name of the pc/phone or the date) so when you connect back you can see in the bookmarks:
"last played position on PC1" "last played position on WindowsPhone 2" "last played position on ZZZ3"
and user can choose where to start.

In my experience this is a NON problem as for "last played position" the biggest one always wins. In other words if I watch a movie till minute 7 on my Windows Phone and then I watch it till minute 10 on my laptop...
It's obvious that I've watched it for 10 minutes so that when I go on my HTPC and want to resume the playback I want to start from minute 10.

(2014-08-30, 15:48)Tolriq Wrote: This is a long term change but supporting this would make XBMC a big step forward in it's central media tool for the house.

But linking that with some of my proposals about authentication for remote on a per remote / user token, each remote / token could trigger a changeset start after a sync to then be able to make the decision on reconnect.
This covers not only new media added but also updated metadata or resume point / watched status ......

The DB fully supports this scenario. If the file is remote (aka: web link, youtube) you can have all the bookmarks you like

(2014-08-30, 15:48)phate89 Wrote:
(2014-08-30, 15:33)m.savazzi Wrote:
(2014-08-30, 14:04)Montellese Wrote: I haven't looked at your schema but one concept that might be missing is source and import. A source is basically a path/identifier of a location (filesystem, upnp server, plugin, ...) from where an item can and has been imported. An import belongs to a source and additionally has a media type i.e. from an import you get media items of a specific media type. At least that's what I'm currently using in my media import work (which RockerC linked to). I just added three additional tables called "source", "import" and "importlinks".

I will look into that but I do not think there is a need.

In the DB the core concept is the Asset that is composed by several physical items.
Each physical item is bound to a Filename and a Path. At current stage both filename and path are generic enough to be able to hande ALL possible "sources".
You can store in path a url, UNC, etc...

I'm still looking into that to see what is the more efficient solution for this issue. The library should be generic, accessible at the same time from different OS so there is not an universal "PATH" that can work everywhere.
The Solutions I've seen so far is to store all paths in smb format (Windows) \\server\path and have a conversion into the correct OS format
the other one is to have a prefix
SMB:\\
UX://
WEB:\\
UPNP:...

etc so we know the format is saved in the table path

If you help me undestand better the "source, importlinks" it would be great

It's not just the path the problem. In its new model kodi needs to know what items in the database are from a specific source because it's up to the user to add or not media for specific kodi instances on the network.
In its new implementation when kodi detects another kodi machine in the same network it ask if the user wants to import and keep in sync its media. If the user agree kodi adds movies, tv shows and music in that library and it connects them to the source and update them at every change (watched count, new episode,renamed movie etc etc). So kodi needs to know the media connected to that source and if the user wants to include the changes or not

Source IS the path and is part of the library. Why that is not working. Can you make examples of "sources"?

Note that UPnP is not efficient to share content compared to SMB, NFS... it does have the advantage of being simple Smile
BUT it just another mean of sharing the content, thus PATH/Name still apply.
If you think I'm useful please use the +/- button to raise my reputation
Reply
#60
Source is 99% another kodi device that share and automatically adds and keeps updated (if the user wants) its media and its metadata. Upnp is just the protocol for the exchange but you need to know what media comes from what kodi device and know if the user wants its files directly in the database or not. Read the example in my last post
Reply
  • 1
  • 2
  • 3
  • 4(current)
  • 5
  • 6
  • 20

Logout Mark Read Team Forum Stats Members Help
New DB Structure for all libraries + DBs [update 2015 06 13 / Released SQL 1.3]3