(2016-11-02, 16:02)LongMan Wrote: I saw the changes. No problem, it is worth waiting for.
I actually have one more question concerning users. Should it still be possible to select a specific user even if an API key has been provided (to limit access to certain items only available to a specific user)? In case this is desired should that user also be authenticated with a password or does the knowledge of the API key overrule any user-specific authentication?
(2016-11-02, 23:58)null_pointer Wrote: One of these is comms and event management between the systems, keeping each other updated with the latest event and changes to media, this includes not just addning new items as they are added to the server but also that some new info about a media item is available (description, cast etc) but also that and item was just watched in a different room of the house on a different device. Or that the client just finished playing something or is currently playing something.
The way we handle this in the Emby4Kodi addon is using a combination of the internal KodiMonitor event manager in Kodi for letting the server know the client is doing something or has done something. Also the Emby server has a WebSocket mechanism that Emby4Kodi addon uses via a WebSocket client to listen for media changes and update the local Kodi DB with the changes
The media import system supports updating/removing items automatically in general. With UPnP we can receive update calls from the server which are then passed to the proper importer etc. And we can send updates from the importing instance to the server to tell it that an item has been watched/unwatched/... The same goes for the Emby importer but there I only added watched/unwatched updates right now. I haven't looked into the websocket stuff yet but I've seen it in the docs.
(2016-11-02, 23:58)null_pointer Wrote: There is also the problem of initial sync when you first start a client, this was a big pain point for Pi users, having to process all items on the server to see if any changed was not really an option so we had to implement two mechanisms. The first is a change HASH, it is effectively a hash of the item in question, it is returned with the items details from the server and we can use it to quickly check if an item has changed just by looking at the hash and the hash we saw last time for the item, if it changed then we need to sync this item.
Yes initial sync is not very fast because it has to retrieve all items, compare them to the previously imported items and find all differences. Unfortunately the Kodi database schema doesn't provide anything to improve this right now and I didn't want to make to many changes to the existing layout so far to make the integration easier.
(2016-11-02, 23:58)null_pointer Wrote: The second mechanism to help reduce the sync workload was to add an endpoint to return a list if items/id of items that changed since last update. This is what we refer to as fast sync and has greatly helped in reducing the time to start. This is critical as people want to boot their client and play something new, i.e. a TV epp that was made available last night, if they have to wait 5 min for a full sync the wife is not happy.
In general this is supported by the importer because it has full control over the list of already imported items and the list of retrieved items which are passed on to the synchronisation task. It could e.g. just remove any item from the list of already imported items which haven't changed and only pass on the ones that might have changed and the synchronisation task will only care about those items and ignore all others. That way partial imports/synchronisations are possible as well.
(2016-11-02, 23:58)null_pointer Wrote: Another thing to consider is how users filter their content once it is on the client, most users of a media management system like Emby are going to put a lot of effort into building a well formatted media library with sections and categories and if you dont allow then to mirror this in the client it will feel back. The way we do this in Emby4Kodi is using tags, we add a lot of tags to the items so filters can be applied and to allow user to build menus and lists of items in the same way they did on the server.
As explained further below this is not really the main goal of media importing. It can import tags set on the Emby server but it does not care about user presentation. It simply adds the items to the local library and then it's up to the user to configure Kodi's library in the way he/she wants.
(2016-11-02, 23:58)null_pointer Wrote: - Can I use the new import system from an addon building a bunch of business logic around the import like I have outlined above, i.e. let the addon work out what and when things need to be imported / updated and use the import lib to do all the DB interaction?
Not yet as I'm still working out the interface for importing so providing addon bindings is out of scope right now until the interface has been proven to work for different use cases.
(2016-11-02, 23:58)null_pointer Wrote: - What are importers written in, C++, Python?
Right now they are written in C++ and as part of Kodi but my goals are to be able to write importers as binary addons (in C/C++) and as python addons. All you need is some kind of thread that handles media provider detection and an implementation of the importer interface capable of importing items from the media provider.
(2016-11-03, 06:10)angelblue05 Wrote: I'm late to the party. I haven't tested anything yet, however I do have some questions.
What is your plan for long term maintenance? Is this going to replace the need for the Emby for Kodi add-on? I guess I don't understand the approach for a project of this scale. Are you planning on maintaining every external database out there? Would it not be best to allow add-ons to utilize your import system and they each build their own process?
Regardless, I appreciate the progress on your project, I'm looking for more information regarding what to expect.
Tags: We use them to split the user's library into the library sections they have in Emby.
Subtitles: We use the Emby HTTP endpoint to provides the subtitles for files over HTTP. We append them using the Kodi api: http://mirrors.kodi.tv/docs/python-docs/...tSubtitles Unfortunately, due to the current Kodi api limitation, there's no way to label HTTP subtitles. So right now, we are downloading the subtitles locally on the fly just to have the right language tag appear.
Edit: Also, I wish you reached out to us. I feel slightly blindsided by the approach taken assuming what I asked above is the direction the project is taking...
Right now this is just a proof of concept. I started out with UPnP importing because Kodi already supports UPnP so it was the easiest remote access path available. But it's very hard to test because you have to run two instances of Kodi etc. After having written the whole media importing interface with UPnP as the first importer I wanted to look into other importers to see if the interface works and if it requires additional stuff. I chose Emby because I've seen before that it has a REST and JSON-based API which is easy enough to use from Kodi. But as already mentioned before I've never used Emby before and I've never installed or used any Emby add-on in Kodi so basically what I did is try to figure out how to access movies, tvshows and music videos.
This is not meant to replace any existing add-on and I'm not even sure if it will be part of the initial media importing work if it ever gets merged into Kodi mainline. As I've already explained to some team members there's a big difference between my media importing and backend specific add-ons (like for Emby, Plex, Netflix, ...) and that is that media importing tries to integrate the media items from any backend and make it look like regular Kodi without the user having to know where the data is coming from and how it got into the Kodi user interface etc. Backend specific add-ons on the other hand often try to make Kodi look similar to the backend and give the user the exact same experience as if they were using the backend with the backend's native client. They also try to provide the user with an exact representation of the media structure in the backend.
