Firmware: A-410 [01 Apr. 2014] | A-400 [12 Mar. 2014] | C-300 [13 Feb. 2014] | A-300 [24 Feb. 2014] | C-200 [11 July 2013] | A-200/A-210 [11 July 2013] | Popbox V8 [3 Dec 2013]

Just got your NMT | WIKI has the answers | Search the forum | Forum Rules/Policy | Firmware & Official NMT News | Popcornhour manuals



User(s) browsing this thread: 1 Guest(s)
Post Reply 
Database Schema
03-21-2013, 11:44 AM
Post: #1
Database Schema
Rom has made the first pass at the database schema, which you can find here: https://github.com/YAMJ/database_schema

Visit this user's website Find all posts by this user
Add Thank You Quote this message in a reply
[+] 3 users say Thank You to Omertron for this post
03-21-2013, 08:17 PM
Post: #2
RE: Database Schema
Is there a specific reason to use blob as datatype for synopsis columns?
Find all posts by this user
Add Thank You Quote this message in a reply
03-21-2013, 08:38 PM
Post: #3
RE: Database Schema
Not really, there are a number of things I would change, this is a first pass and there are still a number of things I need to add.

Panasonic TX-P55VT65, Sony BDP-S550, SkyHD, HDMI 4x2 Matrix, Synology 1511+ with DX510 25TB NAS, Denon AVR-X2000 receiver, Kef Q Series speakers QED cables.
C200, A300, A400 x 2
Visit this user's website Find all posts by this user
Add Thank You Quote this message in a reply
03-22-2013, 05:53 AM (This post was last modified: 03-22-2013 06:44 AM by accident.)
Post: #4
RE: Database Schema
I took a quick look but to be honest, I'm exhausted so I'll just put out a comment that may or may not be handled here..

I would like to make sure the following is handled here:

1: caprica s01e01. tv aired version is family safe. bluray version is softcore porn. I would like to have both in the database and at some point we can sort out how to not present unsafe titles to a child. personally, the design of this for dentedboxes has been "buckets". you put movies into "buckets" and then you add "buckets" to users. no guessing if you got the movie scanned right or not. you can associate a bucket to a scan location for those who have presorted by age.

2: multiple versions of a movie, nicely organized, almost episodes for lack of a better description. to me a trailer is just a version of the same movie. and a commerical is just a version of an episode for tv. keep in mind they might be rated for different ages even though the same title.

3: non-file episodes. lets say RSS feeds of an online tv show which has thetvdb data. would be nice to be able to at some point get some rss feeds that can tie into tv shows and automatically pull or link to the new episodes.

4: non-file movies. there's a lot of free to view movies on youtube for example. would be great to have an integrated list of them in the movies and not some free to view section. again would need a scanner for them but just to make sure the DB is friendly to that..

5: images. I can see the advantage to having some way to quick query "all the movies missing artwork" in the db, but does the artwork really need to be in the database other than I have it or a I don't for this usage? from an API design standpoint, I just want to ask for hte poster of movie #21. I don't really need to waste time with more data initially. when you error that it doesn't exist I'll revert to the alternative view.

6: seasons. I know you always complained about the nmj database with episodes just together. I don't really follow the need to have season records. there really isn't unique per season data except for maybe artwork. see #5 for if you even need to store that in the db traditionally.

7: multipart episodes. it's rare but it's been posted enough and I've run into it enough myself to wish it just worked and I didn't need to deal with it.

rom:

multiple play paths might be needed here.. perhaps not somethign that should be int he db record, maybe just a relative path from the scan path.. I know some might want http paths for tablet watching/upnp, others might want pch paths.. this technically will work on more than the pch so their paths.. we can sort out the api and how to figure out the rest of the playerpath later but to store a full play path is probably limiting.
Find all posts by this user
Add Thank You Quote this message in a reply
03-22-2013, 08:11 AM
Post: #5
RE: Database Schema
1: I think the concept is sound. I think we've talked about this before, where I want to have multiple files associated with a "grouping" - deliberately not using Series/Season/Movie/Collection there. That grouping can then be logically one of those sub-groupings.
I.E. A grouping of tv episodes from the same show and season is a TV Season, A grouping of files by a common theme: a "set", etc.
That gives anyone the flexibility to have what they want, e.g. give me all the latest videos that star Brad Pitt. Or all the latest TV episodes by date.

2: See #1

3: Non-local video files - should be handled the same was as streaming video

4: See #3

5: Not sure what you mean. I don't *think* the image is stored in the database, as with the current YAMJ I expect it to be a link to a file. Whether or not there's still an accessible cache (a la jukebox folder) or not has to be determined.

6: See #1: I think the metadata for a video file should be separated from the file itself. That way you can associate multiple files to the same metadata (e.g. different versions of the same movie can have the same plot). Because of this, you can have metadata that doesn't have a file associated with it (e.g.upcoming episodes) or a grouping that is show and/or season specific.

7: See #1

Visit this user's website Find all posts by this user
Add Thank You Quote this message in a reply
03-22-2013, 08:34 AM
Post: #6
RE: Database Schema
1: my view on whole house is you can't trust a scanner ever so it's one place you need to manually get involved and for this situation I think it's the right way to go. Especialyl if I can make it a couple clicks without getting off the couch to sort them. when you can sort out multiple ages for children, young teen, older teen and parent then you can do things like remove all children from an adult user or show only some of them for a teenager, etc etc. Then it can dynamically fall down to the rest. for example, don't show horror genre when there is no titles that a child can get to it in. don't show the caprica soft core porn version to a child but make it easy for an adult to get to it. more things can be grouped into this and it's really the basis for how I view what should be whole house with multiple age groups.

5: I'm not saying don't put the image in the database, i'm saying the record with a local drive url is overkill. each title will have a record id with it so make a hashed layout based on that id. then a skin can just ask for id/type and get the image if it exists. 404 if you can't find it on the drive, or send over the image if you do. the database record for image really should be just enough to say when type of images you do or don't have. then you can do somethign like "find all tv shows with missing artwork" as part of your what to recheck scan routing. basically leave the image on the drive and go and speed up what to recheck to a nanosecond database call instead of looking at the images in the drive.

3: I want to expand this a little more. think of tekzilla from revision 3 or the guild. both offer rss feeds for these web based tv shows. both have data on thetvdb before they come out on dvd/bluray. Basically make it so a file isn't required to scan so an http or similar url to an episode would be considered a valid file. just something more to make sure you have the ability in the database for the record.
Find all posts by this user
Add Thank You Quote this message in a reply
03-23-2013, 11:18 AM (This post was last modified: 03-23-2013 11:27 AM by accident.)
Post: #7
RE: Database Schema
Quality of data..

something that seemed to work really well with dentdbxoes, although it was very limited testing was to keep a record of data quality for each item. The idea is similar to yamj's what data is used above what feature, but pulled out to store it so you can recheck and go back later to adjust.

In my case I was using a little 1 byte number scale with room for new things later...

0- unknown source (missing don't have)
1- filename source
5- internet source, would like to replace when possible
6- internet source, don't replace
10-nfo source
20-user edited/added to the database, don't touch unless they alter it.


The idea of the scale:

- the title came from the filename, it goes into the record with a quality of 1. you later find it on the internet, but it was the wrong language so you put it in as 5. you then find it later in the correct language so it gets a 6.. later the user adds an nfo file to the title and then you replace it again with a 10.. you only replace the field IF the new value is greater than the old value. The nice thing about this system say someone edited their database so almost everything is 20. then decided sickbeard was amazing and suddenly have all new nfo files for everything, you don't alter a single thing they edited ebcause you know the data came from manual intervention and not a < nfo source.

- for images, this works also.. you can track the image quality form internet sources. for example if you find an image but it fails the aspect or whatever checks you plan to keep, you can still get that image with a quality value of 5 but later during a recheck you can find that preferred quality image so you know to delete the old one in favor of the new one.. also handy for multiple image sites when the first site might have the worst image. you do end up getting more images but you end up with a better automatic scan.

some things didn't follow normal logic. for example top250 or rating from an internet source always went into 5, but a user could adjust it manually and it would stop updating from the net.

Also handy for recheck as you can database poll for all teh data setting 3 to know you need to go look for better on those titles.
Find all posts by this user
Add Thank You Quote this message in a reply
03-23-2013, 03:25 PM (This post was last modified: 03-23-2013 03:39 PM by modmax.)
Post: #8
RE: Database Schema
Here my suggestions and/or questioins to the database schema,
cause I had nearly the same approach.
I call it "V1 database schema", cause I've not seen any remarks to th version.

So I start to describe it from the entry point, which is in my opionion the SCAN_PATHS table.

1.) SCAN_PATHS
- For what is the SP_FILETYPES?
- Perhaps a PLAYER_PATH value is missing

2.) VIDEO_MEDIA
- There should be a last_modification_date in order to determine
if the file has changed or not.
- There should be a TYPE value, to determine if it's a MOVIE, DVD, BLURAY or HDDVD.

3.) VIDEO_AUDIO
Should be splitted in a VIDEO and AUDIO section. It makes no difference if
video/audio codecs are stored in one or two tables; but you have not
to add a flag to the table in order to set "this is a video codec" or "this is an audio codec".
Also the codec tables may have different fields.

4.) CERTIFICATES
The relation from "VIDEO_MEDIA" to "CERTIFICATES" is wrong.
I hope i'm correct the CERTIFICATES should hold the certificates from MPPA or
other countries (i.e. FSK12 for Germany).
Also the certificates may have no image; i would let this as SKIN dependant part.

5.) IMAGES
The INT values should determine a foreign key relationshop, but then the foreign keys
must be placed i.e. in the VIDEO_TITLE (for artworks like poster, fanart etc.)
or from Studio to the studio image.
So it's just a table with an id, a path and an image type. Also a field
for URL (internate access) or an attachment marker (for describing to which media
file the image is attached in a MKV filed) should be used.
So the IMAGE_PATH may stay nullable if you haven't a local file.

The entity is OK, if you want i.e. more than one fanart for a video_title,
but in that case you must have a combined foreign key (image_type along with
appropiate id) for fetching the fanarts for a video title.

6.) VIDEO_SET
VS_TITLE_ID is wrong, should be VS_IMAGE_ID.
You already have the relation from VIDEO_SET to VIDEO_TITLE via the TITLE_SET
entity.

7.) STUDIO
STUDIO_LOGO is not a char, it's an int cause it is a foreign key to IMAGES.id.

8.) VIDEO_TITLE
- What is TITLE_TYPE? Do determine between movie and TV show?
Then that just should be a boolean (OK, is a short with value 0 or 1 in some databases)
- IMDB_ID: Not to be stored here, there another entity with MOVIEDB/ID should exist,
with a foreign key from MOVIEDB/ID table to VIDEO_TITLE.
Same issue for RATING.
- ORIGINAL_TITLE should be included
- VT_CERTIFICATE is obsolete cause you have a relation to CERTIFICATES.
- VT_RUNTIME is obsolete also; covered by VIDEO_IMAGE

9.) CAST_CREW should have a DEPARTMENT (like Director, Writer etc.).
Role ist then only used for actors, and department should be set always.
This means: CAST_CREW shoud be renamed to PEOPLE_CREW following
the other namings.

10.) SEASON
Should have a an end date, whoch can be nullable.

11.) SERIES
I think this are the episodes.
- Then they should contain an EPISODE-ID; whoch episode in that season.
- Can an episode have a different studio than the season? Then SER_STUDIO_ID
would be OK, but I would let this away; to much studio relations for me ... :-)
- The IMDB_ID and THETVDB_ID could be let out. Is determin by the VIDEO_TITLE/SEASON/EPISODE
chain ...

12.) CATEGORIES
For what are the categories? Some kind of sorting or Indexing?
Just wondering for hwat this entity should be.

13.) There is missing an entity like VIDEO_PART which may have a relation to VIDEO_MEDIA.
I think that just may consist of:
- VIDEO_MEDIA_ID
- part (integer)
- path (local path in SCAN_PATHS)
Also the VIDEO_PATH from VIDEO_MEDIA is obsolete, cause each VIDEO_MEDIA should then have
a least ONE video part.
Find all posts by this user
Add Thank You Quote this message in a reply
[+] 2 users say Thank You to modmax for this post
03-23-2013, 06:23 PM
Post: #9
RE: Database Schema
Yet Another Question:
How should TV shows mapped into this schema?

- Video-Title = One Season?
Then some values in the SEASON table like PLOT and OUTLINE is obsolete
Maybe the season is then not needed?
- How should an episode video file mapped to an episode?
Then there should be a relation between VIDEO_MEDIA and SERIES also
Find all posts by this user
Add Thank You Quote this message in a reply
03-24-2013, 11:27 AM (This post was last modified: 03-24-2013 11:31 AM by jluc2808.)
Post: #10
RE: Database Schema
some remarks about YAMJv3_DatabaseShema published
general
each field should be tagged with the original site where the data has been fetched
some field should be 'duplicated' with alternate foreign/alternate contents like certificate, plot, outline, biography, poster, fanart, ....
i don't know at this point if some field /object shouldn't have historical entries with date that could duplicate as historic several parts like test new value....

People:
change PPL_PICTURE_PATH to PPL_MAIN_PICTURE_PATH (main People_Photo field)
add 2 fields for alternate photo PPL_ALT1_PICTURE_PATH, PPL_ALT2_PICTURE_PATH
add translated_biography for further translation field
add general movie list

crew:
add foreign voice
add 1 pointer to the photo selector field (main/alt1/alt2)

movie/series
add watched
add date_watched
add 'alternate'_site_id (not only imdb)
add in index index_set to allow the movie/serie in several set
Find all posts by this user
Add Thank You Quote this message in a reply
03-24-2013, 01:07 PM
Post: #11
RE: Database Schema
Wow, where do I start, I've not visited this thread for a while and so many points to reply to, but here goes....

(03-23-2013 03:25 PM)modmax Wrote:  So I start to describe it from the entry point, which is in my opionion the SCAN_PATHS table.

1.) SCAN_PATHS
- For what is the SP_FILETYPES?

I actually stole this from the NMJ as I believe it is a good idea - but does not have to be used if you don't want to. Essentially if it is an int you can set to what type of media is scanned for in this path. It can be decoded with a bitwise and to see what should be scanned for on that path. eg:

1 = movies
2 = TV
4 = Music
etc....

So a 1 in this filed means only scan for movies. 2 means only scan for TV, 3 means scan for movies and TV, 5 means scan for movies & music but not TV etc...

Quote:- Perhaps a PLAYER_PATH value is missing

SP_PATH is the player path.

Quote:2.) VIDEO_MEDIA
- There should be a last_modification_date in order to determine
if the file has changed or not.

Yes, a lot of the tables need mod date and time, still to be added.

Quote:- There should be a TYPE value, to determine if it's a MOVIE, DVD, BLURAY or HDDVD.

You mean SOURCE? A movie is a movie, no difference whther it is a movie from BD or movie from DVD. I agree a SOURCE type may need adding.

Quote:3.) VIDEO_AUDIO
Should be splitted in a VIDEO and AUDIO section. It makes no difference if
video/audio codecs are stored in one or two tables; but you have not
to add a flag to the table in order to set "this is a video codec" or "this is an audio codec".
Also the codec tables may have different fields.

These are split, VIDEO_MEDIA essentially stores the video data, VIDEO_AUDIO stores the audio data. One VIDEO_MEDIA (file) can have multiple audio tracks (all with different properties) which is why it has to be separate. It is the same for subtitles.

If you want to support multiple video tracks in a file then this would have to be split out into another table.

Quote:4.) CERTIFICATES
The relation from "VIDEO_MEDIA" to "CERTIFICATES" is wrong.
I hope i'm correct the CERTIFICATES should hold the certificates from MPPA or
other countries (i.e. FSK12 for Germany).
Also the certificates may have no image; i would let this as SKIN dependant part.

No Idea what you mean here, CERTIFICATES is not directly linked to VIDEO_MEDIA, it is an attribute from VIDEO_TITLE and the link is there.

If ANYTHING in the DB has no value it does not have to be set (unless it is set to not null). If there is no image, don't set one. I split the certificates out so that you could store more images (if you want them) per certificate, eg large image, small image etc.

Quote:5.) IMAGES
The INT values should determine a foreign key relationshop, but then the foreign keys
must be placed i.e. in the VIDEO_TITLE (for artworks like poster, fanart etc.)
or from Studio to the studio image.
So it's just a table with an id, a path and an image type. Also a field
for URL (internate access) or an attachment marker (for describing to which media
file the image is attached in a MKV filed) should be used.
So the IMAGE_PATH may stay nullable if you haven't a local file.

Again, no idea what you mean with this.

Quote:The entity is OK, if you want i.e. more than one fanart for a video_title,
but in that case you must have a combined foreign key (image_type along with
appropiate id) for fetching the fanarts for a video title.

I also don't understand this. You can select all images for a title of a type by selecting the images table with IM_TITLE_ID='xx' and IM_IMAGE_TYPE='FANART' or whatever where the 'XX' is the VIDEO_TITLE ID

Quote:6.) VIDEO_SET
VS_TITLE_ID is wrong, should be VS_IMAGE_ID.
You already have the relation from VIDEO_SET to VIDEO_TITLE via the TITLE_SET
entity.

No it is not wrong, The IMAGE_ID is irrelevant, you may want multiple images for a SET (poster, thumbnail, small, large etc) so the idVIDEO_SET relates to IM_VIDEO_SET_ID

Quote:7.) STUDIO
STUDIO_LOGO is not a char, it's an int cause it is a foreign key to IMAGES.id.

Not as I have defined it. I have only made provision for 1 studio logo and the STUDIO_LOGO (char) is the path to the image. If multiple images are required then this field can be changed and a link added to IMAGES. It was just a design decision.

Quote:8.) VIDEO_TITLE
- What is TITLE_TYPE? Do determine between movie and TV show?
Then that just should be a boolean (OK, is a short with value 0 or 1 in some databases)

I disagree, you are restricting to just movies & TV then. What about 'Home Movies', or other such video types. I am designed this from a high level, considering other jukeboxes but also not restricting it.

Quote:- IMDB_ID: Not to be stored here, there another entity with MOVIEDB/ID should exist,
with a foreign key from MOVIEDB/ID table to VIDEO_TITLE.
Same issue for RATING.

This can be changed, as I said, its an initial draft, if multiple sources/ids are wanted then it should be another table with source name, source URL or ID and ratings, votes etc.

Quote:- ORIGINAL_TITLE should be included

Yes, another thing that needs to be added.

Quote:- VT_CERTIFICATE is obsolete cause you have a relation to CERTIFICATES.

It is if you are strict, but if you only want to store the certificate text (no image) then you can use this. It is faster access than joining tables and there is nothing in DB design that says you cannot duplicate data where necessary to speed access Wink

Quote:- VT_RUNTIME is obsolete also; covered by VIDEO_IMAGE

there is no VIDEO_IMAGE (unless it was that and I have since changed it). BUT the runtime is in VIDEO_TITLE (the MOVIE/Episode runtime) and VIDEO_MEDIA (the physical video file runtime). These are different. The media file you have may not be the same as the movie runtim. Also a movie may be in multiple video files so the movie runtime would be the whole movie time, the VIDEO_MEDIA runtime would only be part of the movie runtime.

Quote:9.) CAST_CREW should have a DEPARTMENT (like Director, Writer etc.).
[quote]

That would be ROLE Wink

[quote]
Role ist then only used for actors, and department should be set always.
This means: CAST_CREW shoud be renamed to PEOPLE_CREW following
the other namings.

Disagree, it is still a ROLE a director is a person with a specific job/role just like an Actor, they are the same entity.

Quote:10.) SEASON
Should have a an end date, which can be nullable.

Can be added.

Quote:11.) SERIES
I think this are the episodes.

no they are not, they are seasons.

Quote:- Then they should contain an EPISODE-ID; whoch episode in that season.

Quote:- Can an episode have a different studio than the season? Then SER_STUDIO_ID

No

Quote:12.) CATEGORIES
For what are the categories? Some kind of sorting or Indexing?
Just wondering for hwat this entity should be.

Categories would be like 'Kids films', 'Animation' whatever, just another type of group s that users can define the titles in the groups and view only those titles. Note this is different from Genre.

Quote:13.) There is missing an entity like VIDEO_PART which may have a relation to VIDEO_MEDIA.
I think that just may consist of:
- VIDEO_MEDIA_ID
- part (integer)
- path (local path in SCAN_PATHS)
Also the VIDEO_PATH from VIDEO_MEDIA is obsolete, cause each VIDEO_MEDIA should then have
a least ONE video part.

I assume you mean in multiplart videos? Then VIDEO_MEDIA is what you are wanting.

To summarise. Example Movie Lord of the rings split in 2 video files.

VIDEO_TITLE is the MOVIE details, there is only 1 record.
VIDEO_MEDIA is the details of EACH VIDEO FILE - so there would be two here.
Each VIDEO_MEDIA record will be linked to one or more VIDEO_AUDIO records as the video file may have more than one track, DTS, DD, Commentary, different languages.

Panasonic TX-P55VT65, Sony BDP-S550, SkyHD, HDMI 4x2 Matrix, Synology 1511+ with DX510 25TB NAS, Denon AVR-X2000 receiver, Kef Q Series speakers QED cables.
C200, A300, A400 x 2
Visit this user's website Find all posts by this user
Add Thank You Quote this message in a reply
03-24-2013, 02:47 PM
Post: #12
RE: Database Schema
Hi Rom,
thanks for your explanations. Now it is clearer to me.
With the explanations I also understand your design decisions for the ER model.

I was confused about some relations, but the go not to an entity,
I should have seen them in 3D and noticed then that they do not end at
the entity: the are just hidden by the entity table ... I shouldn't wear
sunglasses when reading something .. :-)

Also the descriptions didn't match to what I expected; for i.e. VIDEO_AUDIO
I thought there should be VIDEO and AUDIO codecs in it.

Only thing what is not clear to me:
Why SEASON and SERIES?
If SERIES are for seasons and not episodes, for what is SEASON then?
Find all posts by this user
Add Thank You Quote this message in a reply
03-24-2013, 04:36 PM (This post was last modified: 03-24-2013 04:39 PM by accident.)
Post: #13
RE: Database Schema
(03-24-2013 11:27 AM)jluc2808 Wrote:  each field should be tagged with the original site where the data has been fetched

the whole quality thing is sort of like this tag, except all you know is where it got the data, not if that data is preferred for the user. An example, you got an image from themoviedb. but if you have the quality you know it's an image in the wrong language from somewhere on the internet and it needs to be replaced because that's the preference of the user.

It's sort of a way to improve rescanning and making the database not temporary but still being fully automatic and handling some common problems that we all run into, especially with new tv shows or non-english artwork.
Find all posts by this user
Add Thank You Quote this message in a reply
03-24-2013, 05:36 PM (This post was last modified: 03-24-2013 06:25 PM by accident.)
Post: #14
RE: Database Schema
(03-24-2013 01:07 PM)Rom Wrote:  
Quote:9.) CAST_CREW should have a DEPARTMENT (like Director, Writer etc.).
[quote]

That would be ROLE Wink

[quote]
Role ist then only used for actors, and department should be set always.
This means: CAST_CREW shoud be renamed to PEOPLE_CREW following
the other namings.

Disagree, it is still a ROLE a director is a person with a specific job/role just like an Actor, they are the same entity.

I don't know if I agree with this one. I think your forgetting there is some movies where the role of director is a role in the film and NOT the actual director of the film. I'm not looking at the schema while reading this so many it's nothing. If this is a actor/director/whatever role and you can have mary being the director of the film, and mary also being the character of director acting in the film then it's all good Smile

I didnt' want to try to find the post but omertron braught up that type of video should be just a bit and I disagree with that... I know his view is everything is a tv show or movie but in reality, there is music videos, home videos, exercise videos, anime, things that people have in the past asked to be supported and separate in the indexes. To limit the database because there are 2 types right now is just limiting the future or making switching it later a harder project.

Also there was mention of parts.. When you start support multiple versions then parts as a # isn't enough. you can end up with part 1 and part 2 for 3 completely different versions. maybe versions is where they are different in this case but you may not know that from the filename if you think of the order data is going to be found when scanning.

scan vs presentation:

I mentioned this in the scanner thread I started but a common request has been to have a mini-series show up in movies. to get the good data it has to be scanned as a tv show, but that doesn't mean there can't be a new flag to say visually it's on the tv as a movie. The more I think about it, fitting tv into movies really limits things where a movie, and it's multiple versions is more like a tv show and then this senario of "band of brothers" fits where you can have multi-part movies that have different "plots/episodes" to read about.
Find all posts by this user
Add Thank You Quote this message in a reply
03-24-2013, 07:30 PM
Post: #15
RE: Database Schema
(03-24-2013 04:36 PM)accident Wrote:  
(03-24-2013 11:27 AM)jluc2808 Wrote:  each field should be tagged with the original site where the data has been fetched

the whole quality thing is sort of like this tag, except all you know is where it got the data, not if that data is preferred for the user. An example, you got an image from themoviedb. but if you have the quality you know it's an image in the wrong language from somewhere on the internet and it needs to be replaced because that's the preference of the user.

It's sort of a way to improve rescanning and making the database not temporary but still being fully automatic and handling some common problems that we all run into, especially with new tv shows or non-english artwork.
i agree with that comment, which is not opposed to the fact that the 'fetched from' could be a good knowledge, by example: from NFO or from allociné or from theMoviedb
in a lot of case these info were welcome to help people and debug end-sites evolutions

in another way i asked for multiple field according with the country or language like plot, folder, artwork, ..... thid 2nd demand seems to me important for foreign people and should let skin people display either english or anyother language without the need to rebuilt the contents of the database with only one language.
Find all posts by this user
Add Thank You Quote this message in a reply
Post Reply 


Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Database Schema - Watched jhmiller 23 2,188 07-30-2013 03:20 PM
Last Post: jhmiller
Information YAMJ3 configuration stored in database modmax 7 995 06-22-2013 05:50 AM
Last Post: Omertron

Forum Jump: