• 1
  • 2(current)
  • 3
  • 4
  • 5
  • 20
New DB Structure for all libraries + DBs [update 2015 06 13 / Released SQL 1.3]
#16
(2014-07-30, 15:11)RockerC Wrote: Again for reference, much looks to have been discussed in detail before and some work even started here:

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

http://forum.xbmc.org/showthread.php?tid=141169
https://github.com/garbear/xbmc/commits/photolibrary

http://forum.xbmc.org/showthread.php?tid=155304
https://github.com/declankenny/Video_Database_Proposal

http://forum.xbmc.org/showthread.php?tid=73831
http://wiki.xbmc.org/index.php?title=Dat...Schema_4.0
http://wiki.xbmc.org/index.php?title=Dat...hema_4.0/a

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

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

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

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

As far as I can tell none of these previous ideas and concepts have yet made it into mainline.

I read a lot of that.

I hope my approach will make it in the mainline as library management is an area that needs really a lot of improvement.
I'm trying to have a simplier approach that will resolve a lot of the issues at the root adding a lot of flexibility to XBMC for future functionalities.

I'm confident it will be so good to make it.

Also I do not think is a good idea to "alter" existing DB but is probably better to do a "conversion" routine that reads the data from one DB and inserts it in the new one.
It will be easier to write, test and debug and more fault proof. Also it will allow to migrate DB from sqlite to a shared DB lice MySQL or SQLServer etc...
(obviously should be done in an efficient way with correct number of connections and, also, with correct transactions)
If you think I'm useful please use the +/- button to raise my reputation
Reply
#17
(2014-07-31, 23:48)m.savazzi Wrote: Sorry what do you mean with remote?

On the DB the segmentation is done at data level, much easier, quicker and does not require any configuration on the client apart creating users.
If we want to introduce segmentation based on tags, metadata, etc... is trivial as on a DB is very easy to achieve it.

He is the developer of a remote xbmc controller for android (Yatse) and it was talking about the same feature i was too.
Users right now can already split with smart playlists and custom nodes for example tv shows in documentary and tv series and add them to skin home but he has no way to bring those categories to the remotes because it's not built in xbmc and in the database so people don't understand why they don't have the same categories in the remote that xbmc has. In short terms you can already do that but it needs to be integrated into the db anyway to make it work well
Reply
#18
(2014-08-01, 01:49)phate89 Wrote:
(2014-07-31, 23:48)m.savazzi Wrote: Sorry what do you mean with remote?

On the DB the segmentation is done at data level, much easier, quicker and does not require any configuration on the client apart creating users.
If we want to introduce segmentation based on tags, metadata, etc... is trivial as on a DB is very easy to achieve it.

He is the developer of a remote xbmc controller for android (Yatse) and it was talking about the same feature i was too.
Users right now can already split with smart playlists and custom nodes for example tv shows in documentary and tv series and add them to skin home but he has no way to bring those categories to the remotes because it's not built in xbmc and in the database so people don't understand why they don't have the same categories in the remote that xbmc has. In short terms you can already do that but it needs to be integrated into the db anyway to make it work well

Sorry, now Ihave understood. I've been using Smart Playlist and they are great but complex and somehow limited.
The DB structure I'm builidng and proposing will make that segmentation part useless.... so that SmartPlaylist can exploit their potential after the data is segmented.

I have to solve the issue of the data modeler but will work on that part deeply as I do agree is very important (and I use it too Smile )

This is another place where a good DB structure will simplify several areas of the code in XBMC and in the skins

I will test this one:
http://www.oracle.com/technetwork/develo...01047.html

If is really free I will love Oracle even more!
If you think I'm useful please use the +/- button to raise my reputation
Reply
#19
you can use mysql administrator to create db layouts visually
Reply
#20
Also checkout the ideas from this thread

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

(2014-07-31, 23:48)m.savazzi Wrote: The major point is which abstraction layer we use. I will check if ODBC allow a "cross DB" Alter Table syntax to avoid having the code to manage it.
See that ODBC and other methods of database abstraction layer for XBMC's library have been discussed before too here

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

iODBC and unixODBC implementations of ODBC are both cross-platform portable which might make them interesting

http://www.iodbc.org
http://www.unixodbc.org
Reply
#21
One of the other things to bear in mind is that any new schema must not result in a slow down of queries on devices like the Pi, if I remember correctly this is partly where the last attempt fell down.
Reply
#22
an abstraction will always slow things down a little. And the bottleneck on the PI are not necessarily the queries. We load a shitload of data that's not even needed in many views - this needs to be optimized (-> lazy loading of relational information) and for this a ORM layer on top of the new db schema/abstraction could help
Reply
#23
I'm excited about the possibility for this. I use mySQL with synology and love it. Just wish I could use profiles for custom libraries with specific resumes without hacks. I'm hoping new and updated database will allow for easy customizations like parental control and the like!
Reply
#24
Hi all,

Not sure if everyone is aware of MediaBrowser - it is a cross-platform Media server and shared database that we have been developing a Python addon for. We are reaching the limits of what can be done with Python however and are very interested in a more direct mechanism to achieve XBMC integration. We will be reading up on the links posted here - but if you are interested please check out MediaBrowser:

http://mediabrowser.tv/

and the MediaBrowser XBMC AddoOn:

http://mediabrowser.tv/community/index.p...99-xbmb3c/

I realize it may not be everyone's cup of tea - so definitely prefer a model like XBMC has with LiveTV - a model that allows integration of multiple backend DBs.

xnappo
Reply
#25
guys, our mastermind jmarshall is currently doing some refactoring of the DB structure (mostly unifying things to share the same structure, logic and code base, see PR5198 ). This is some sort of preparation to make bigger refactorings like applying a new schema like suggested in here more easy. The big refactoring has to be split up in smaller steps though and can't/won't be a hard cut.
I made him aware of the work going on in here and it's appreciated. 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.

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?

So start your engines and keep concepts coming.
Reply
#26
I think with shares filtering, restricting by pg ratings and hiding genres it's almost all covered.
Probably it's better to actually bind the profiles to the sources because it's easier to match the "source_id" than everytime check if the string starts with the path.
Another question is: we want a fully configurable filtering by genre and pg or we're going to propose some group and xbmc will fit the media into one of those like "all-content", "adult-only", "kids-only" or "safe-only"?
Because with defined groups is a lot easier to manage by the user and also cleaner the code. The scraper provides the info, xbmc based on that defines on what group it fits and set it directly in the database and filtering will be a lot easier..
Reply
#27
Genre / PG are not well defined as can be just anything depending on scaper / user values in NFO, so groups must be editable by users so he can put it's choice in each category if this road is taken.

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.
Reply
#28
(2014-08-12, 12:02)da-anda Wrote: guys, our mastermind jmarshall is currently doing some refactoring of the DB structure (mostly unifying things to share the same structure, logic and code base, see PR5198 )...

...big refactoring has to be split up in smaller steps though and can't/won't be a hard cut..
There are some very good points they bring up there there about being realistic on how to approach changes in FOSS projects

https://github.com/xbmc/xbmc/pull/5198

"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."
Reply
#29
Maybe it would be worth looking into DB schemas of other media centres like MediaPortal or MediaBrowser to see how they are doing it.
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
#30
(2014-08-12, 13:34)Tolriq Wrote: Genre / PG are not well defined as can be just anything depending on scaper / user values in NFO, so groups must be editable by users so he can put it's choice in each category if this road is taken.

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.

I'm not an expert but if they're so different it's going to be hard to also make it editable. Is it not easier to handle different versions in code?
Reply
  • 1
  • 2(current)
  • 3
  • 4
  • 5
  • 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