[jjd-uk]

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..

That's not what I said at all, you'll have one parent item for the Movie in the Library views, then when you select the item it will open a new view showing just the different versions of the Movie that have been added , I only mentioned Movie Sets because it's a similar way of grouping and displaying several linked items.

[phate89]

ok my mistake

[phate89]

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)

We need to le the user chose if mark as watched all the versions of the same movie but we won't let him play his sd file even if he wants to?
There are several reasons to have sd versions like bandwidth, different dubbing, different crop (i have some disney bd with it's dvd version because they did a poor job cropping only to have them in 16:9) and decoding limitations (even more now since hevc is rising and is only software).

[Fice]

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)

We need to le the user chose if mark as watched all the versions of the same movie but we won't let him play his sd file even if he wants to?
There are several reasons to have sd versions like bandwidth, different dubbing, different crop (i have some disney bd with it's dvd version because they did a poor job cropping only to have them in 16:9) and decoding limitations (even more now since hevc is rising and is only software).

My main point was: We have different reasons for having several files per asset, and the db somehow has to reflect that. (because they might differ in behaviour).

C) is not really a use case for me right now, so I don't care I'm fine with asking the user beforehand. All I thought about was importing a youtube video and I would be really annoyed to always have to choose the quality before playing (perhabs have a option to remeber my quality choice per asset, and always reuse that).

There is also the big question about playlists. What if I use 'play from here' on a tv show. What version/quality do we play (we can ask for the first episode of course, but what about the next one? Especially if they have different qualities/different names for the versions). I suspect that's not a DB layout issue, so that can be solved later.

[Tolriq]

Same problem for remotes

Maybe different version needs to have some kind of a TAG representing the version difference, this would allow to play all with same tag, and remotes to play a movie ID with default TAG, or queue specific tag to not have to deal with path on client side to differentiate items.

[phate89]

Same problem for remotes

Maybe different version needs to have some kind of a TAG representing the version difference, this would allow to play all with same tag, and remotes to play a movie ID with default TAG, or queue specific tag to not have to deal with path on client side to differentiate items.

With some good api i don't think it's an issue.
For example if you ask to play from remote and there is only one file it will play, if it's not only one it won't play and in the response kodi adds a list of the various version so the remote can display a list and send another request with also the version specified..
For other things like playlists it's harder and a "default" one is probably needed.

[garbear]

Requests:
1) RetroPlayer being mainlined sooner or later might as well consider adding stand-alone games and game ROMs launched via emulators into the scope of the database model right away as well.
a. Added: Games are just an asset. Please let me know which properties we need specific for a game

from https://github.com/garbear/xbmc/blob/ret...eInfoTag.h

the fields I use in Game info tag:

• File path
  
• Title
  
• Platform
  
• Game Code (unique ID embedded in ROM)
  
• Region
  
• Publisher / Licensee
  
• Format (PAL/NTSC)
  
• Cartridge Type, e.g. "ROM+MBC5+RAM+BATT" or "CD"
  

I started with these fields because they can be populated directly from the ROM's data. you could get ideas about fields to add from thegamesdb.net (http://thegamesdb.net/game/1318/ ) like player count, release date, etc

keep in mind that another layout is needed for save states. the example save state database i created had fields for savestate path, rom path, rom CRC and gameclient used to create the savestate.

[pecinko]

The original point was to have the possibility of using different DB servers as shared library among different XBMC.
In addition to optimize how the DB is managed (real transactions, one connection to db non thousands, etc..).

This lead to me thinking a new, simple but very flexible db structure to host all possible contents.

First of all many thanks and good luck with the project, I hope you'll manage to pull it off.

Some thoughts, in no particular order:

* It might be interesting to take a look at Plex media server (PMS) as well. HTPC client runs on XBMC fork after all and is open source. PMS is not open BUT, it uses SQLite DB and REST API is available via server_ip:32400/library. Thus, you should be to get a pretty good picture about what's going on. DB itself supports pretty much everything that is/was discussed here with exception of profiles. This is just in case you find it useful, not to say this DB is worse or better than MediaPortal/Browser's.

* Centralized server / distributed model / local content: I can see the point of local library when media is hosted on HTPC itself or attached USB disk as well as for centralized model running some kind of Kodi server.

So, how about leaving Kodi (client) local library as is with a possibility to announce it's media on LAN via UPNP or something else. In addition, for those who want it, there can be separate app, Kodi server, that could run on a separate PC or NAS. This one could offer more advanced library, manageable via web interface. For those wanting advanced library but not wanting to use server/NAS - they can install Kodi server locally, on the same HTPC.

This way we don't need to worry about library upgrade on Kodi and server app can be made and tested independently. Less savvy users can stick with what we have now if they prefer or if they find installing Kodi server app to complicated.

* Different movie versions, HD/SD etc - I would sacrifice this (and alike niche features) in a moment in order to simplify things and help library improvements get finally implemented.

Once again, thanks and good luck mate.

[Tolriq]

Same problem for remotes

Maybe different version needs to have some kind of a TAG representing the version difference, this would allow to play all with same tag, and remotes to play a movie ID with default TAG, or queue specific tag to not have to deal with path on client side to differentiate items.

With some good api i don't think it's an issue.
For example if you ask to play from remote and there is only one file it will play, if it's not only one it won't play and in the response kodi adds a list of the various version so the remote can display a list and send another request with also the version specified..
For other things like playlists it's harder and a "default" one is probably needed.

This is not the solution at all, the API can not say no I do not play what you ask, it must provide all needed info before and have an API to play what is asked ...
It means you need to have before the needed information to select the media before starting it, and using multiple long path, is not network and usage efficient.
Not talking about user friendly for selection, this means the API would be completely broken to allow a same database ID to hold different media version. As you'd go from 1 id - some info to 1 id - x * some info. No backward compatibility is possible.

Makes offline files hard to implement on media renaming, ... (For that something that would be useful even without all this is a CRC or MD5 of the file(s) in db and API that would help))

[phate89]

Why exactly can't say no? When I hit play in the interface it says no and prompt me the choice. It's the same exactly.In this way it work EXACTLY as the interface probably will be.
Of course it's probably better to set the old method to play the default one if it doesn't know what to play and add a different one for the different behavior to preserve the old compatibility.
Also it's not hard to add an API to get more info and to show with the old one the default stream info to preserve compatibility.
This is a concept change. Right now library is based on list of files, in this schema it will be based on the actual content. It's a deeper change than it looks.
also kodi will have similar problems. What stream detail you will show? Best quality? No info?
I'm not saying that my solution above is perfect at all but that with code you can find a good solution providing good API. In theory it's even possible to not change a bit how API works and display a list with duplicate movies exactly how it works right now..

[Tolriq]

Perhaps because it's slow and inefficient ? Not talking about complexity for simpler programmable remotes like Creston.

And if the API says not then give new info for choice, then you need to have a way to start the media with the correct choice, so the API implement the direct correct media in play so the api have to return before the needed information to directly propose the choice for play and not having to try to play, does it work ? yes no, oups no it does not work propose the list to the user after a potential long delay then the user choose then play .... While all could have be done before and better ...

[phate89]

Actually every play you do can fail or say no. That's not the actual problem. If you say it's better to have that info and know what media have more than one file i agree with you and i already said it's needed new api to get that info.
As i said it's not a perfect solution at all. But all possible with code and better api. It's not a db layout issue.

[Tolriq]

The choice about 1 ID per real media or 1 ID by meta data is a db layout issue and this choice impact all the rest.

And yes obviously anything is possible with code, but some things are efficient some are not, and efficiency should be think about during db layout definition, since usage drives the layout.

If ID does not represent unique media then synchronization becomes complicated, and tons of things too and this should not be forgotten before stopping at the basic case when press play what happens.
(Of course could also be addressed as media ID and file ID, and with files CRC, file renaming could keep the file ID and correct adjustment to API / internals could be a solution).

But please as always in this thread think more global.

[phate89]

Actually have the same info more times in the database like it is now is inefficient.
Also not be able to know that file x and file y are the same movie is a big flaw in the logic of the current database. Logically one thing is the movie itself and another is the file and this becomes trivial with montellese's work.
But even in this case you still have a single id for the file to identify the specific file and handle file renaming and stuff like that if you want.
About play if you can parse the file infos you can already point to the right file without problems. Of course we also need a "default play" behavior for stupid remotes (or just print the list on screen when playing)

[Tolriq]

Well read again, I never say current db is correct or perfect.

I you had read better you'd see I talk about ID for media or ID for meta data, in every way meta data should be common the point is not here, only the schema change. (Entry point and relations)

No need to answer I'll stop polluting this thread