(2014-09-09, 07:57)Montellese Wrote: (2014-09-08, 20:40)phate89 Wrote: But in this way don't you have 2 times the movie in the database with all scraped info with 2 different ids?
(2014-09-08, 22:17)m.savazzi Wrote: At program level you can simply add the details to the first version and copy them to the other or even not copy just leave the second record empty
IMO if a DB design results in (obvious and predictable) duplicate information there is something wrong. In the case of multiple versions of the same movie / asset IMO it makes more sense to detect this situation during library scanning and then linking the new file to the existing movie / asset instead of always retrieving both assets (with different database IDs) and then having to match multiple versions of the same asset every time they are shown in the user interface.
Correct and this is NOT the case. Director's cut and Theatrical are TWO different movies, they have different poster, etc... They have different Runtime, different Year, etc...
The IMDB ID is different.
On the other side is true that they share a set of common information like Artists, director, etc...
What I mean to write is that the DB Structure is smart enough to handle this situation avoding duplicated info.
(2014-09-09, 07:57)Montellese Wrote: I'm actually working on this with the current DB layout and I added a table that links files to media items and during library scanning it detects "identical media items" (for movies it uses the title and year or imdbid). Then when retrieving all movies you get an item for every version of a media item (with the identical database ID and the identical metadata but with different file details like streams) which you can easily go through and put together all items with the same database ID (no additional complex logic that slows down the listing necessary) into a single item that is then presented like a movie set
Good. In the new DB we can do the same using the Version table so we avoid duplications.
Example:
Version 1 of movie Foo:
foo - part 1.mpg
foo - part 2.mpg
Version 2 of movei foo:
foo.mkv
In this way we will have
File 1: foo - part 1.mpg
File 2: foo - part 2.mpg
File 3: foo.mkv
Asset 1: foo
bound to file 1, file 2
Asset 2: foo
bound to file 3
Version table: asset 2 bound to asset 1
So we will NOT duplicate common information on 2 as we already have one. On 2 we will add the video and audio track info.
(2014-09-08, 20:40)phate89 Wrote: Also about the watched status i think should be related to the episode, movie etc etc. It's the episode/movie itself that i watched not the specific file. If i have 2 versions of the file and i watch the first the 2nd should also result watched. Also if you remove a watched episode or movie and then you add it back the asset will be deleted and created so the episode will result unwatched, however since the episode entry won't be deleted the database will already have the watched status.
(2014-09-08, 22:17)m.savazzi Wrote: At program level you can simply add the details to the first version and copy them to the other or even not copy just leave the second record empty
Watched is associated to the asset so if you watch the Director's cut but not the theatrical movie it will be recorded correctly
If you watch the first the second should not be marked as watched OR if you want to have it watched the program can do it. This is a lot of freedom for Kodi
IMO this is something that should be definable by the user i.e. the user should be able to choose whether watching the standard version of movie X should also mark the director's cut version of the same movie X as watched or not. Therefore it should be linked to the specific file and xbmc/kodi can implement the necessary logic to do it the way the user wants. That "freedom" is not possible if the watched status is linked to the media item / asset.
[/quote]
Not correct. As explained in the example we will have
Asset 1: foo
Asset 2: foo
Version table: asset 2 bound to asset 1
If user wants to have separate view state in the AssetViewed table you will havbe
Asset 1: viewed true
Asset 2: viewed false
If you want to have a single viewed state there are 2 options either when you update the viewed state you use the Version table to update all status at once OR you use only viewed 1 to update AND you use version table to retrieve Always asset 1 status when querying.
I like more the first as if user decides to switch from one mode (all the same) to the other (each asset it's viewe state) the user experience is better.
It's a freedom for Kodi code.
(2014-09-09, 11:08)phate89 Wrote: (2014-09-09, 07:57)Montellese Wrote: IMO this is something that should be definable by the user i.e. the user should be able to choose whether watching the standard version of movie X should also mark the director's cut version of the same movie X as watched or not. Therefore it should be linked to the specific file and xbmc/kodi can implement the necessary logic to do it the way the user wants. That "freedom" is not possible if the watched status is linked to the media item / asset.
But what are the chances it will become an option? Usually small options like this will never go into mainline (and it's probably a good thing).
Btw i agree as i said before about the duplicate movie. Sometimes some sort of duplication is allowed to simplify the db and speed up access but in a media database movie is a major resource and it must be unique. Also it would be great if in the future kodi will not show twice the episode if we have 2 versions of it or we renamed it and not yet clean the database (it happens to me A LOT) and prompt a choice list after but that's probably part of the kodi code more than the db..
(2014-09-09, 11:27)Tolriq Wrote: Do not forget that the final plan is synchronization.
Same database ID for multiple media with different path could generate troubles for syncing watched status for the case of different watched status per media quality. (Specially with path translations or direct / indirect access ).
Not talking about remotes that will now have to deal with multiple path for a same ID, that will be complicated like hell to do offline download and sync.
But I'd also avoid the mess of Tv Shows with multiples ID per path with group by name that are well ...
Not sure there's an easy an optimal way to address this without major impacts, like for remotes Player.Open movieid 1, what file start ? Ask on the client ? Need to add the path first needing to ask the user at the remote side ?
Have not yet check the db proposal, but files / path or anything should be the object linked to physical details and description ... And we could use some kinds of collations to link the movies together like sets.
This is why I wrote in post 1 that the files are identified via the CRC32! this is independent from the file name BUT is very time/disk consuming if the OS is not able to provide it on the fly. Otherwise we should rely on file name.
There could NOT be multiple database ID for the SAME file. It's a nonsense and an error at Kodi level.
If I rename a file it old File x record should be removed OR (if possible) Updated.
(2014-09-09, 11:27)Tolriq Wrote: Have not yet check the db proposal, but files / path or anything should be the object linked to physical details and description ... And we could use some kinds of collations to link the movies together like sets.
Please check the DB as this is very well addressed
(2014-09-09, 14:02)jjd-uk Wrote: The support of multiple versions of one media item is certainly coming, as it's absolutely necessary for Montellese work in allowing media from multiple sources being added to the Library. For example you might have the same movie in:
1. HD version in local Library
2. SD version from UnPnP source e.g. tablet
3. Bookmarked in an addon
With Montellese's work from what I understand then all three of the above could be added to the Library.
So the question is then to what to present to the user? From what I understand concept similar to Movie Sets is seen as the best option, so you will see a single item for that movie, select it and you will then be shown the different versions. With Theatrical and Director versions I'm not sure what the plan is, I guess until there's some way for the scraper to support this then it would be similar to the moment with duplicate looking items being shown, but like now I again guess that you might be able rename how they are displayed e.g. "Film - Theatrical Cut" and "Film - Directors Cut".
Correct is the Version table that binds the three assets. At this point Kodi is free to show them as the user likes.
They can be shown as three movies, as one folder with three assets as three episodes... it's up to Kodi.
The DB will simply have all the correct info (with no, or minimal duplicated info) and very easy ways to recover them
(2014-09-09, 14:36)phate89 Wrote: Is it the best way to handle them as movie sets? In any view available you will have 3 items with same artwork, same title and only different stream details. Very confusing and not very immediate IMO..
Why not something similar to the bluray playlist selection with movie info? Kodi can compare them and simplify it in "sad version", "hd version" and "addon version".
About director's cut if the scraper supports it it's not hard to search "director's cut" or something like this in the file name but in this case we need a "version" attribute that the scraper can fill with the version name if they find it
The DB allow Kodi code and the user to decide what to do. Using version table you have a lot of freedom for example you can decide that Asset 1 will have poster, fanart and all other info and all other Assets versions will not have any info
OR
you can decide that Asset 1 are the defaults for all versions BUT a version can have a different fanart
OR
you can decide that each version will have it's own set of details.
As said the DB supports all of this in an easy way. Kodi should decide how to interact with the user.
(2014-09-09, 15:35)Fice Wrote: I think we should store additional information in the link from a file to an asset, as we have three situations where one movie might have several files.
A) If we have a 1 on 1 local copy from a UPnP source, there is no need to show two entries. And if one of them is watched, all of the copies should be marked as watched as well. (The link from file to asset should probably containt a foreign key to the original file?)
Using CRC32 there will not be 2 files/assets as they are the same
Using filename there could be 2 entries and the user or some Kodi logic should bind them together with the versions table. They can be "local" and "remote"
(2014-09-09, 15:35)Fice Wrote: B) If we have to different versions (uncut versus directors cut) then we should probably show them as a set and if one version is watched, doesn't mean we should automatically mark the other as watched as well (perhabs make it a setting). (The link from file to asset could probbly contain some metadata that is likely to differ: duration/PG rating/Year?!?)
explained before how it works. All possible scenarios fully supported.
(2014-09-09, 15:35)Fice Wrote: C) The same movie, the same version but different qualites. Is there a need for the user to select the qualities? Just play the highest quality the device can play. Would a user actually prefer SD over a HD? Not sure about 3D vs. non 3D version though. (Don't have a 3D tv)
As above, fully supported.