[Montellese]

Right now our logic to extract streamdetails for video items is causing quite a few problems (especially with JSON-RPC and UPnP) and will get worse (or rather become completely broken) when the headless work is progressing. The reason is that we only read/load streamdetails when browsing the library in the GUI and we only load the details for the items that we are currently seeing in the GUI listing. That means that when a user adds a new video source and scans it there will be no streamdetails (and no cached artwork) for the scanned items. If the user now decides to use an android/iOS/whatever remote to control Kodi several data for the newly scanned items are missing or wrong (e.g. the runtime). A similar problem exists when the user lists the video library using a UPnP client. There we have logic to load the details of every listed item but it significantly slows down the response (especially if it first has to extract the streamdetails and cache the artwork).

Basically I can see two/three improvements with advantages and disadvantages:

1. Extract streamdetails and cache artwork during scanning.
   
   1. Do it synchronously for every item.This will significantly slow down library scanning, especially for low powered devices.
      
   2. Do it asynchronously while continuing to scan for more items.This will also slow down library scanning but the library will be filled faster but details won't be available immediately and the overall time the scanning takes will be similar to when doing it synchronously.
      
2. Asynchronously extract streamdetails and cache artwork after finishing a scan. That way the actual library scanning will stay as fast as it is and the user will be able to start browsing his library but additional details will only be loaded asynchronously. This might also lead to conflicts if we want to keep the background loading when browsing the library in the GUI leading to two background loaders running simultaneously.
   

So what is the preferred/best way to improve this? Are there any other approaches that we could take? Do we want to limit the user experience on "powerful" hardware because there are lower power devices that will suffer? Or should we let the user choose when to perform the task?

[natethomas]

I'm mostly happy to leave this up to more skilled devs than I, but my presumption is that extracting after scanning is the much preferred method. I'm not sure if I understand how doing it that way would limit the user experience on more powerful hardware. Assuming the hardware is speedy, the extraction at the end should not take a great deal of time under any circumstance, and certainly no more time than if it were to occur during the actual scan.

It seems to me that most other programs that do something similar to this only do so when there are resources available to do so. Could the passive scanner (for lack of a better term) not first check to make sure the user isn't already actively browsing the library before starting, and then accept a command from the active scanner (also for lack of a better term) to stop while the active scanner is working?

[natethomas]

Or secondary option. Could the scan be called in more ways than just through the GUI? If the scan is fast enough to work during a GUI browsing session, surely it should be just as fast when doing a JSON browsing session or a UPnP browsing session (not sure if those are the same thing). It seems like a JSON call to the library should result in the same scanning task as a GUI call to the library.

edit: To be clear, I'm obviously not saying a JSON call does result in the same scanning right now. I'm saying that if we are happy with how a GUI call performs for the user, then wouldn't it make sense to try to alter JSON calls so they can do the same thing?

[Ned Scott]

Whichever is decided, I'm guessing the new chapter thumbnails could be done along side the other streamdetails extraction?

[Montellese]

It seems to me that most other programs that do something similar to this only do so when there are resources available to do so. Could the passive scanner (for lack of a better term) not first check to make sure the user isn't already actively browsing the library before starting, and then accept a command from the active scanner (also for lack of a better term) to stop while the active scanner is working?

TBH I haven't thought this through all the way. While writing the text I simply realized that a "post-scan" extraction might result in running two extraction threads if the user decides to go into the library. It's probably not even a problem but we might end up extracting the streamdetails etc multiple times. But yes we could make the extractor cleverer in that we keep track of what has already been done and support syncing multiple extractors or set priorities on the items being extracted.

Or secondary option. Could the scan be called in more ways than just through the GUI? If the scan is fast enough to work during a GUI browsing session, surely it should be just as fast when doing a JSON browsing session or a UPnP browsing session (not sure if those are the same thing). It seems like a JSON call to the library should result in the same scanning task as a GUI call to the library.

edit: To be clear, I'm obviously not saying a JSON call does result in the same scanning right now. I'm saying that if we are happy with how a GUI call performs for the user, then wouldn't it make sense to try to alter JSON calls so they can do the same thing?

The problem here is that when showing our GUI we have full control over what is happening. We can load the items (without streamdetails), show it to the user and whenever new streamdetails have been loaded we can update the GUI list with the new items. On JSON-RPC we get a request out of the blue and the requester wants the response as fast as possible so we simply send back whatever we have. We can't asynchronously start loading additional information and then let the requester know that something has changed. Same goes for UPnP but there we take the time to extract the details before sending the response.

Whichever is decided, I'm guessing the new chapter thumbnails could be done along side the other streamdetails extraction?

Probably yeah and we might also be able to include looking for external subtitles so we don't have to do that in all kinds of other places as well.

[Ned Scott]

I like the idea of consolidating all that extra lookup/extraction stuff, instead of doing it on demand. I think that actually makes it easier to use things on a low powered device, because you can get it all done in one go. The library scan might be slower, but it sounds like it would improve browsing speed.

[popcornmix]

So what is the preferred/best way to improve this? Are there any other approaches that we could take? Do we want to limit the user experience on "powerful" hardware because there are lower power devices that will suffer? Or should we let the user choose when to perform the task?

I'd like a JSON request to extract the stream details.
I'd then use a script like Milhouse's texturecache to update this automatically (e.g. at night from a cron job).
You could also automate the extraction from external tools (like sickbeard).

Extraction on scan could be an option, but don't make it compulsory. I suspect it will make scans several times slower.

[Kib]

I would love asynchronous extraction after finishing the scan / after being idle for x minutes.

[Martijn]

So what is the preferred/best way to improve this? Are there any other approaches that we could take? Do we want to limit the user experience on "powerful" hardware because there are lower power devices that will suffer? Or should we let the user choose when to perform the task?

I'd like a JSON request to extract the stream details.
I'd then use a script like Milhouse's texturecache to update this automatically (e.g. at night from a cron job).
You could also automate the extraction from external tools (like sickbeard).

Extraction on scan could be an option, but don't make it compulsory. I suspect it will make scans several times slower.

This sounds less than optimal and still requires some extra addon or extra effort from users.

Making it cleverer and letting it run during or after scan seems most preferable. Benchmarking would tell which is most preferred

[da-anda]

I'd prefer triggering the extration after an item was added to the library - be it by hand (by pressing "i" on a share with configured media type) or via a library scan. The extraction should be done with low priority in background (it MUST not slow down GUI responsiveness). And for the case the GUI is requesting streamdetails/etc before they got extracted, the request could check if the extraction for this file is already in queue and if so change it's priority and if not it'll be added with highest priority. I think this should work out pretty well this way (extractor might need it's own job queue).

[topfs2]

IMO 2 is the most appropriate to do always, however we could add more power user functions to jsonrpc (which upnp could use) which could be useful. I.e. if a user starts scanning and the library and movie A is scanned (but hasn't probed stream details) they are able to append a param which signifies that its happy to wait for streamdetails (for example by asking for streamdetails in metadata). So if movie A is scanned but has no streamdetail (and scanning is currently being done) and a request goes through which requests stream details we do a probe for that files stream details and when the scan is completed that file will be skipped.