Guest - Testers are needed for the reworked CDateTime core component. See... https://forum.kodi.tv/showthread.php?tid=378981 (September 29) x
  • 1(current)
  • 2
  • 3
  • 4
  • 5
  • 24
WIP Developer Area
#1
Brick 
This area should only be used by developers to exchange ideas and discuss issues.

If you possess skills with Visual Studio 2012 and/or Visual Basic 2012 or above, you're more than welcome to help review, test, or actively develop for Ember MM! Possibilities are endless - add your own scraper, fix a bug and such. Please report here if you're working on something so we know someone is working on a specific part of Ember - helps to keep track of changes Smile
Development help:
http://wiki.embermediamanager.org/index....evelopment


Current database model of Ember: https://dl.dropboxusercontent.com/u/7856...r1.4x.html
Sample Database: http://dl.dropboxusercontent.com/u/78566...tabase.emm
#2
Welcome everyone and thank you to DanCooper for setting this up.

M
If you think I'm useful please use the +/- button to raise my reputation
#3
New master fork of 1.4.x is online and ready to clone: Link

Thanks you m.savazzi for your hard work!

I have change the base folder "Ember Media Manager" to "EmberMediaManger". Transifex has a problem to read lnaguage files inside a folder with spaces in the name.
I will on Friday try to add all subsequent amendments (1.3.0.12/.13).
#4
Hi m.savazzi.

So I had imagined (not complete yet).
All link tables have foreign keys only and no primary keys. Only the main tables have primary keys.

IMDB as the primary key does not work for movies. The same movie several times could also be present (SD, HD, HD3D).

Image
Full size image
#5
Dan,
I've modified the DB and put that online. Structure is easier now with my DB Smile
If you think I'm useful please use the +/- button to raise my reputation
#6
(2013-05-17, 13:34)m.savazzi Wrote: Dan,
I've modified the DB and put that online. Structure is easier now with my DB Smile

Please send my a PM with the link, i don't have Skype @work.

Edit: It's OK, i have found the link (i love MagicPaket and TeamViewer =)
#7
(2013-05-17, 01:01)DanCooper Wrote: New master fork of 1.4.x is online and ready to clone: Link

Thanks you m.savazzi for your hard work!

I have change the base folder "Ember Media Manager" to "EmberMediaManger". Transifex has a problem to read lnaguage files inside a folder with spaces in the name.
I will on Friday try to add all subsequent amendments (1.3.0.12/.13).

It is a pleasure Smile

I've forked your 1.4 and now are cloning it on the PC.

Will work to fix all the language strings in a single file so that we can we can update Transifex

M
If you think I'm useful please use the +/- button to raise my reputation
#8
I have looked at your database.
Follow questions:

  1. I still do not understand why you link tables with primary keys want to use.
    I use primary key only when a record can not be uniquely defined. And that's not necessary here.
    I think this is a better way to prevent duplicate entries occur:
    Code:
    --Tabelle: actorlinkmovie

    --DROP TABLE actorlinkmovie;

    CREATE TABLE actorlinkmovie (
      idActor   integer,
      idMovie   integer
    );

    CREATE UNIQUE INDEX ix_actorlinkmovie_1
      ON actorlinkmovie
      (idActor, idMovie);

    CREATE UNIQUE INDEX ix_actorlinkmovie_2
      ON actorlinkmovie
      (idMovie, idActor);

  2. Why do you want no Writer and Director link tables?
    Just when you usu primary key for idPerson and idMovie it is not possible eg Bruce Willis to save as an actor and director.

  3. What advantage do you see when the set is linked to a file instead of a movie?

  4. Why do you have removed all "Has*****" column? Do you want check every time "If NotNullOrEmpty -> PosterPath" while the movie is loading?
    All main lists use this entries for the green tick mark.
#9
(2013-05-17, 14:58)DanCooper Wrote: I have looked at your database.
Follow questions:

  1. I still do not understand why you link tables with primary keys want to use.
    I use primary key only when a record can not be uniquely defined. And that's not necessary here.
Primary Key: set of unique values needed to identify univocally a single row

Every table must have a PK (if is not a trash kind folder), using the Unique Index is partial. In the case of link tables the PK is the couple if link ids.
Is more efficient and quicker.

(2013-05-17, 14:58)DanCooper Wrote: I think this is a better way to prevent duplicate entries occur:
Code:
--Tabelle: actorlinkmovie

--DROP TABLE actorlinkmovie;

CREATE TABLE actorlinkmovie (
  idActor   integer,
  idMovie   integer
);

CREATE UNIQUE INDEX ix_actorlinkmovie_1
  ON actorlinkmovie
  (idActor, idMovie);

CREATE UNIQUE INDEX ix_actorlinkmovie_2
  ON actorlinkmovie
  (idMovie, idActor);

na, is less efficient and leads to confusion as it makes people think that there could be duplicated rows due to the lack of a PK.

(2013-05-17, 14:58)DanCooper Wrote:
  • Why do you want no Writer and Director link tables?
    Just when you usu primary key for idPerson and idMovie it is not possible eg Bruce Willis to save as an actor and director.

  • is not efficient. TMDB, IMDB structures are better, it is even much quicker to deserialize (in case we want to scrape all person info)

    Writer, Music, Actors, etc... are all persons Smile
    So we need a Person table where store person info (an din the future we can add more info if we want) and then a second table where we distinguish what the person have done in each movie, and this is the link table.
    Also from a code perspective is easier as we have to add/update only the person table.

    (2013-05-17, 14:58)DanCooper Wrote:
  • What advantage do you see when the set is linked to a file instead of a movie?

  • Sorry maybe I did a mistake, the relationship are multiple:
    Movie -> files (for all info, NFO, effective media, fanart, etc...)
    Set -> movies (for the relationship in the set, which movies are part of the set)
    Set -> files (for the set specific info like the fanart or an image)

    The files table contains ALL files (subitle, movies, episodes, images, etc...) they are distinguished by the type flag. This is again much quicker and more flexible.
    the link tables create the relationship between the assets and the files...


    (2013-05-17, 14:58)DanCooper Wrote:
  • Why do you have removed all "Has*****" column? Do you want check every time "If NotNullOrEmpty -> PosterPath" while the movie is loading?
    All main lists use this entries for the green tick mark.

  • I do not want to do that, but they are useless as fields as they have to be put in the View on the table, in other words those fields are
    select count(file)>0 from files where type = 1 {fanart} and files.movieid = movieid
    or even select count(file) from files where type = 1 {fanart} and files.movieid = movieid

    in this way we avoid multiple updates, add file, update flag etc... is just a source of errors Smile

    In a nutshell we are using SQLite that is a relational DB... so let's take advantage of that to simplify the code Smile... and this is why I added all the PK, all FK and indexes. Once we insert, delete, update something we can be sure is coherent!
    Also in the dev and debug phase is easier as the wrong insert/update/delete sequence will generate an immediate error.

    M

    Working on language files!

    from 1780 string down to 600 Smile
    If you think I'm useful please use the +/- button to raise my reputation
    #10
    1)
    Note: in the actual code there are NO selected scrapers after wizard. So the scrape process will just skip Smile

    I would put the TMDB scrapers enable by default but they need the APIKey to work.

    Open to suggestions...

    2)
    Also a lot of the extension plugins are enabled by default. I would remove them as they can lead to a mess (i.e. renamed is enabled by default Sad )

    3)
    Do we leave the Wiki page?
    can someone edit/update wiki with the latest info?

    4) I think we have to update the About Smile to change the scrolling text AND the page that is opened on click
    If you think I'm useful please use the +/- button to raise my reputation
    #11
    (2013-05-17, 15:34)m.savazzi Wrote: Every table must have a PK (if is not a trash kind folder), using the Unique Index is partial. In the case of link tables the PK is the couple if link ids.
    Is more efficient and quicker.
    OK Big Grin

    (2013-05-17, 15:34)m.savazzi Wrote: na, is less efficient and leads to confusion as it makes people think that there could be duplicated rows due to the lack of a PK.
    Accepted

    (2013-05-17, 15:34)m.savazzi Wrote: is not efficient. TMDB, IMDB structures are better, it is even much quicker to deserialize (in case we want to scrape all person info)

    Writer, Music, Actors, etc... are all persons Smile
    So we need a Person table where store person info (an din the future we can add more info if we want) and then a second table where we distinguish what the person have done in each movie, and this is the link table.
    Also from a code perspective is easier as we have to add/update only the person table.
    OK. We rename the table to "persons". I don't like it when the table name is different to primary key column (idPerson). It is easier to see that the field is not linked to another table.

    (2013-05-17, 15:34)m.savazzi Wrote: Sorry maybe I did a mistake, the relationship are multiple:
    Movie -> files (for all info, NFO, effective media, fanart, etc...)
    Set -> movies (for the relationship in the set, which movies are part of the set)
    Set -> files (for the set specific info like the fanart or an image)

    The files table contains ALL files (subitle, movies, episodes, images, etc...) they are distinguished by the type flag. This is again much quicker and more flexible.
    the link tables create the relationship between the assets and the files...
    I also do not know what is appropriate. We can also decide later.

    (2013-05-17, 15:34)m.savazzi Wrote: I do not want to do that, but they are useless as fields as they have to be put in the View on the table, in other words those fields are
    select count(file)>0 from files where type = 1 {fanart} and files.movieid = movieid
    or even select count(file) from files where type = 1 {fanart} and files.movieid = movieid

    in this way we avoid multiple updates, add file, update flag etc... is just a source of errors Smile

    In a nutshell we are using SQLite that is a relational DB... so let's take advantage of that to simplify the code Smile... and this is why I added all the PK, all FK and indexes. Once we insert, delete, update something we can be sure is coherent!
    Also in the dev and debug phase is easier as the wrong insert/update/delete sequence will generate an immediate error.
    +1

    (2013-05-17, 15:34)m.savazzi Wrote: Working on language files!
    from 1780 string down to 600 Smile

    This sounds really great Smile


    This evening I try to add all changes that i have done in 12/13. See you later in Skype.
    #12
    (2013-05-17, 16:04)DanCooper Wrote:
    (2013-05-17, 15:34)m.savazzi Wrote: is not efficient. TMDB, IMDB structures are better, it is even much quicker to deserialize (in case we want to scrape all person info)

    Writer, Music, Actors, etc... are all persons Smile
    So we need a Person table where store person info (an din the future we can add more info if we want) and then a second table where we distinguish what the person have done in each movie, and this is the link table.
    Also from a code perspective is easier as we have to add/update only the person table.
    OK. We rename the table to "persons". I don't like it when the table name is different to primary key column (idPerson). It is easier to see that the field is not linked to another table.

    You are fully right. Let me recheck the DB I've done, maybe I messed up.

    the table should be named Persons
    the PK is idPerson
    then there are the personslinkmovie etc...

    (2013-05-17, 16:04)DanCooper Wrote:
    (2013-05-17, 15:34)m.savazzi Wrote: Sorry maybe I did a mistake, the relationship are multiple:
    Movie -> files (for all info, NFO, effective media, fanart, etc...)
    Set -> movies (for the relationship in the set, which movies are part of the set)
    Set -> files (for the set specific info like the fanart or an image)

    The files table contains ALL files (subitle, movies, episodes, images, etc...) they are distinguished by the type flag. This is again much quicker and more flexible.
    the link tables create the relationship between the assets and the files...
    I also do not know what is appropriate. We can also decide later.

    The structure with one files table is the most flexible and future proof. Let's check I've not mixed up the FK and relationships with the other tables Smile

    Also I'm not sure if a Set Fanart is needed or used by any skin Tongue
    If you think I'm useful please use the +/- button to raise my reputation
    #13
    (2013-05-17, 16:06)m.savazzi Wrote:
    (2013-05-17, 16:04)DanCooper Wrote:
    (2013-05-17, 15:34)m.savazzi Wrote: is not efficient. TMDB, IMDB structures are better, it is even much quicker to deserialize (in case we want to scrape all person info)

    Writer, Music, Actors, etc... are all persons Smile
    So we need a Person table where store person info (an din the future we can add more info if we want) and then a second table where we distinguish what the person have done in each movie, and this is the link table.
    Also from a code perspective is easier as we have to add/update only the person table.
    OK. We rename the table to "persons". I don't like it when the table name is different to primary key column (idPerson). It is easier to see that the field is not linked to another table.

    You are fully right. Let me recheck the DB I've done, maybe I messed up.

    the table should be named Persons
    the PK is idPerson
    then there are the personslinkmovie etc...

    Do you have an idea to prevent actors with same name that are not the same person? Have TMDB/IMDB a "personally number", linked to a profile?

    (2013-05-17, 16:06)m.savazzi Wrote: Also I'm not sure if a Set Fanart is needed or used by any skin Tongue

    Set fanart and posters are used by EVERY skin if you have enabled "group movies to sets" in XBMC settings. But you can only set an individually images over the context menu.
    But... There is a plugin for this problem. You need a folder "artwork" in the movie source folder. The poster must be named "<set-name>.jpg" and the fanart "<set-name>-fanart.jpg". Actually quite simple to implement in Ember.

    I've also seen that XBMC wants to make a solution for it in next release (14). Thus, we are already one step ahead Big Grin
    #14
    (2013-05-17, 01:01)DanCooper Wrote: New master fork of 1.4.x is online and ready to clone: Link

    Thanks you m.savazzi for your hard work!

    I have change the base folder "Ember Media Manager" to "EmberMediaManger". Transifex has a problem to read lnaguage files inside a folder with spaces in the name.
    I will on Friday try to add all subsequent amendments (1.3.0.12/.13).

    Woot! Very nice, I will check this out this weekend.
    I looked at the database structure and so far I think it's a good setup - one thing I missed is support for the new VideoTag Field (since v12 Frodo):

    Quote:5 Movie tags
    To add a movie to one or multiple tags an NFO file can be created and for every tag an XML tag can be added like this
    <movie>
    ...
    <tag>Name of the tag</tag>
    ...
    </movie>
    If there's no tag with the specified name it will be automatically created and the tag will be attached to the movie. A movie can be added to multiple tags by adding it multiple times.

    More information here: http://wiki.xbmc.org/index.php?title=Video_library_tags
    For this I think we need another table videotag linked to the movie?
    Just want to mentioned it, since I'm pretty sure that this feature will be requested later on anyway Smile
    #15
    I think we have now reached the level of 1.3.0.12.
    Tomorrow I will add the features from 1.3.0.13.
    Then we can look for the lost features.

    Good fight, good night!
    • 1(current)
    • 2
    • 3
    • 4
    • 5
    • 24

    Logout Mark Read Team Forum Stats Members Help
    Developer Area6
    This forum uses Lukasz Tkacz MyBB addons.