[da-anda]

would be great to have a UML of the database design to get a better overview and can optimize even more in a collaborative way (using some opensource UML tool - probably MySQL-Workbench).

Here is the UML for "File" section.
...

---

And the "Library" section.
...

great, thanks. Mind sharing the files as well so one can play with them a bit? Maybe put them on github like the rest?

[DecK]

great, thanks. Mind sharing the files as well so one can play with them a bit? Maybe put them on github like the rest?

Done.

[jmarshall]

Sorry to be pedantic, but when you say 'path' do you mean folder(directory) or could you also be referring to an individual file?

Referring to scraper settings, it's a folder or directory. e.g. you could have movies/genre/movie1/files type setup, with content set on the movies root, and content overridden for a particular genre (or a particular movie). I'm not sure if this is really needed or not - it's mostly used for language related stuff as far as I'm aware (different scrapers for German + English for example).

Can you explain this a little more? I've never used a rar and don't see how a path cannot be hierarchical. Sorry for being dumb...

Sure, a rar path has the form rar://<path_to_rar>/<path_in_rar>. There's a bunch of others that aren't necessarily heirarchical. Multipaths are another where the parent is a multipath:// path, and the child (if not itself a multipath) is then just the normal child path. Otherwise it's difficult to figure out which of the multiple paths at the beginning the child belongs to. It may be that this could be changed - I have no particular feeling as to whether it would be a good or bad thing to do.

In my thinking, each source has a single root folder. This would be a change from the current way it works but would not be a reduction in functionallity.Current multipath sources would become multiple sources.

That would be problematic for those that like to browse using their folder structure. A source being multiple paths allows would allow those paths to be merged. This functionality might be better placed somewhere else - I'm not sure, as it also messes with the hierarchy stuff?

Cheers,
Jonathan

[Klojum]

It's probably just me overlooking something obvious, but why have most (all?) DATE or DATETIME fields been defined as TEXT fields in XBMC schemas? I noticed it in XBMC Eden (video60.db), and now I still see a TEXT field in the schema used as a date field (DKnode.Releasedate TEXT). Is this coming from an ancient Xbox database setup or some other backward compatibility thing? AFAIK, SQLite and certainly MySQL has DATE and DATETIME field types. So why not use them?

[volkris]

Associating metadata (particularly watched status) with an ID instead of a filename is one of the big shortcomings of XBMC, so I'd long wanted the database to be updated like this.

It looks like DecK has done significant work on this. Is it in the right pipeline for progress? A bug filed or whatever need to happen?

[zag]

Just seen this, nice initiative. I think its important to keep it simple but also fast.

Are the files hosted anywhere?

[Mettbrot]

come on... https://github.com/declankenny/Video_Database_Proposal

[da-anda]

zag - read a few posts back, it's on github

[narvatu]

This prototype has the ability to ;

• support multiple profiles.
  
• add new media types (Home Movies, Documentries, etc.) to the library without the need to add new tables.
  
• add new types of artwork (CDart, ClearArt, etc.)without the need to add new tables or even columns to existing tables.
  
• associate any artwork type with any media type in the library.
  
• allow movies to be in multiple sets.
  
• allow sets to contain any media type, including other sets.
  
• allow sources to be updated (location change) without having to rescan all items.
  
• be fully backwards compatible with the current structure (this one is aspirational at the moment)
  

If this database proposal will allow a movie belongs to several movie sets, perhaps the developer should participate in this thread since it would change the established rules

[pecinko]

If this database proposal will allow a movie belongs to several movie sets, perhaps the developer should participate in this thread since it would change the established rules

That is a read only forum. I suppose devs should first state their intension - is it to improve existing library features or to go with library redesign.

[Martijn]

If this database proposal will allow a movie belongs to several movie sets, perhaps the developer should participate in this thread since it would change the established rules

That is a read only forum. I suppose devs should first state their intension - is it to improve existing library features or to go with library redesign.

existing

[narvatu]

That is a read only forum.

Because of his, I post in this thread. I dont know if deck is authorized, but other participants in this thread (Da-anda, zag, jmarshall...)do.

I suppose devs should first state their intension - is it to improve existing library features or to go with library redesign.

I do not know either. The intention is to note that the work of the two threads influence on each other and avoid working on a model with a single movie set for film whether to change (soon) to another model that allows multiple Movie Set. This would influence the entire management of nfo, fanart, thumbnails ... discussing in the other thread

shame on me for gossip these developer forums

[jmarshall]

We have this feature (database redesign) featured as a suggest GSOC project this year. I don't know if DecK qualifies as a student or not. Either way, we would encourage those that wish to work on this and are students to apply

http://wiki.xbmc.org/index.php?title=Goo..._Code_2013

Cheers,
Jonathan

[xynoe4]

Any chance to get support for multiple audios/subtitles in a single video file? It would be great if one day, for example, we could filter movies/tv shows having english audio or spanish subtitles

Thanks and great work by the way.

[mkortstiege]

Please keep it a development talk. No +1 and/or feature requests in here please. Thanks.