(2014-08-31, 01:49)Tolriq Wrote: (2014-08-30, 22:52)m.savazzi Wrote: (2014-08-30, 20:02)Tolriq Wrote: Keep in mind also that the way to access media can be dual as a file might be accessible by one instance and not another one and then should access the media from the first instance (Either automatic fallback or configurable per source).
Or include a way to sync sources with password but with tons of security problems.
About scraping you also need to keep in mind some actual limitation / configuration of XBMC. Images are cached at some defined sizes depending on lots of things.
And since each client could need different size in it's cache the main source either needs to store the best quality one and the local cache for it's need. As sending a low resolution image to be upscaled on the client would just be awful...
There's really a lot of things to think and as Montellese said it needs to be possible to do it step by step. (This image quality problem is already present in current XBMC UPnP sharing from an rpi for example, don't know if something is planned about it).
To have UPnP work well is a HUGE amount of work and troubles, security, circular references (direct and multiple ways, consider you have 3 PC with Kodi each one will have K1, K2, K3 library. Now K1 will import K2, K2 import K3, K3 imports K1.... BUM!)
Not saying it should not be done but do consider not even Microsoft, Samsung, LG, Google, Netflix got it working right... UPnP has been there for years and it's usage is very limited...
Maybe is better to focus efforts to get DB and Library management working very well as it will impact all users... not just a few.
Sharing the folder and a shared DB achieves the same functionality and is far easier.
IF thumbs are small enough they can be saved in the DB as Objects... thus no duplicates at all!
Anyway as future reference note that once the new DB is in place a Kodi istance can connect to multiple DBs on multiple NAS/PC if you want.
It's just a code problem... not anymore a data issue
You need to read better before answering
I never talk about UPnP in what I said. And I do not talk either about source import (that if done correctly as source with a master, does handle the 3 cases easily ...)
Ops sorry
I got rumbled away by the UPnP story
(2014-08-31, 01:49)Tolriq Wrote: I talk about media access and thumbnail access.
And no storing images in DB for display is not a good idea at all, and you'll always need images at the correct size stored in cache as you'll need local cache as there's no faster way to handle this .... (And sharing the source path does not work for local thumbs near media for local media for example) ....
Well to add BLOBs to DBs is very easy once we have a good structure in place. To save them locally is not an issue...
(2014-08-31, 01:49)Tolriq Wrote: For storage, if Kodi1 have access to a local drive, Kodi2 need to have access to the media too or source sharing is useless ... So a path like /var/media does not work and you either need upnp / http sharing this is the base of central db.
Same for NAS sources with for example NFS exported only to one host and not all host, or password protected smb shares.
I do agree. The path story should be defined quite well.
From a DB structure it is independent but we need to clean it.
Using a shared DB for local content can be done but some prerequisite should apply, IF the content should be always available to remote Kodi clients the folder where content is saved should be shared (o reachable from a share)
Otherwise all other Kodi instances will see the content as offline (or will not see it, this is application logic, using the path structure I designed is very easy to exclude paths not accessible at query level)
My suggestion is to always use a share path even for local files. On the same machine it will be resolved by the local OS without using the network layer so without any cost in terms of perfomarce.
Let's assume on Kodi 1 you have folder c:\TV Shows and is shared as TVShows
on the DB you will not add contents as c:\TV Shows\show 1 but as \\Kodi 1\TVShows\show 1
In this way the content is accessible even from remote
If you too can provide me examples of contents / paths I can check the DB structure if it works and show how I would apply it
(2014-08-31, 12:24)da-anda Wrote: as for the "source" identification. To be able to indicate that some asset is offline (NAS down, Kodi instance holding the file down), we need to know where it came from, and this must not be some query parsing for a specific flag in a "path" field - so along with the "path" you need some "source" field holding the unique local identifier for the source. And with local I really mean local. From how I understood Montellese, the import sources are speficic to each installation (and probably stored in a XML?) - thus each source will have a instance specific unique ID and this ID should be linked to in a separate field within the files table (along with the path). Having an UNC path in the table and your instance is not able to access it (maybe credentials required) doesn't necessarily mean that the source which could forward it to you isn't able to access the file. So file access checks by just the "path" only won't probably be enough - and at least then you'd need to know from which configured import source this is coming to a) check if that source is even online and b) it can serve that file.
On the UNC it works and you have 2 options either the share is mounted at OS level OR you have to store username and password. This is not complex..., I can add username and Password at Path level in the db
(2014-08-31, 12:24)da-anda Wrote: And I don't agree that users MUST be stored in the DB and also don't like the bitfield for user IDs. I'd rather see a permission groups table IN the DB which profiles can be assigned to. So permission check in DB will be done via permission groups and not users/profiles. This also allows profiles to share permissions + simplifies reusing of permission configurations. Also, profiles could have their own DB (completely separate) for which there might be good reasons - so it wouldn't be possible to store them IN the db anyways.
You must have users in the DB if you want to filter content. If you do not like the bitfield we can use a table.
(2014-08-31, 18:06)Montellese Wrote: (2014-08-30, 18:43)m.savazzi Wrote: I do not have MySQL in mind, I have in mind a shared DB scenario
99,9999% of the users has a library on a nas and 99% of the nas natively supports DB or can host SQLite db files (thus being a shared DB).
This (invalid) assumption is the main reason of the whole discussion in the last two days. First of all I'm guessing (I don't have any facts) 99+% of Kodi users don't have a NAS. They have a single Kodi installation on some machine. They also never make it into this or any other Kodi-related forum (otherwise we'd have a million users registered).
Therefore you can't assume that everyone will use a "central" shared database. There may be users who simply have a box running Kodi with a local library. Then one day they decide that it would be nice to also be able to use the the same library on their phone but they don't have the necessary knowledge to setup a NAS or MySQL or whatever. They just want to be able to import all the items from their existing Kodi installation on their phone and maybe take some movies with them on a trip to watch them their while they have no connection to their existing Kodi installation at home.
In that case there's no way the user will use one "central"/shared database so there needs to be a way to synchronise the library of the local Kodi installation with the installation on the mobile device. It doesn't matter how that synchronisation is done (we've started with UPnP because it's already well integrated into Kodi itself but ideally we'd use something else). I have been working on this for a while now and I first tried to do it on a per-file basis. Then I realized that there are items that don't have a file (tvshows, seasons, albums, artist, ... - in general all collections of media items). Then I went over to using the path. But in the end the SQL queries got so complicated that I had to introduce separate tables for sources. Then I realized that for some sources it might make sense to import different media types from different source paths. You could e.g. import a few very specific movies from an addon without importing all of them. In that case both come from the same source (i.e. addon XYZ) but for the automatic synchronisation it is important to know that we shouldn't sync all movies from that source. Therefore we need to have "import locations" belonging to a source which specify the actual locations on the source that need to be synchronised. A source can have as many import locations as the user requires. In case of single items being imported every item has its own import location. In other cases the import location may be the same as the source if the user simply wants to import all movies from a source. So in the end I ended up with three additional tables: "source" contains a list of sources from which a Kodi installation can import items from. "imports" contains a list of imports (each belonging to a source) which is basically a path and a media type and tells Kodi which media items to import from where. "importlinks" links an import to a media item.
(2014-08-30, 18:43)m.savazzi Wrote: Note that there is a high probability that when Kodi 1 detects Kodi 2 the reverse happens so Kodi 2 will detect Kodi 1 library... this because both PC have UPnP active.
Now how you avoid circular references? Kodi 1 detects a movie on Kodi 2 and adds it to the library. Kodi 2 detects Kodi 1 asks for the library and gets even the reference to it's own library via UPnP... this becomes an infinite loop
This is very easy to solve by following the rule that every Kodi instance must only offer items for synchronisation that it can access itself directly. So when Kodi 1 syncs with Kodi 2 and vice versa Kodi 1 will only offer the items from its local database for synchronisation and after having synchronised with Kodi 2 and Kodi 2 synchronises with Kodi 1 it doesn't get the items it offered to Kodi 1. The same rule makes sense when Kodi 1 also imports items from an addon. You can't synchronise those items because you can't know whether Kodi 2 has the same addon installed or not. If not it wouldn't be able to play that media item which would be a bad user experience.
Got your point and is good. As I said UPnP and the new DB are not conflicting but complementing each other.
Also the new DB is not only a SHARED DB, is a better DB for all cases.
It will allow better library management, asset management, filtering, user bindign to content... AND it will work well in a shared scenario