Blocking call to videoscan command in update page's view can be potentially very slow.

[bcipolli]

Line 277 of main/views.py
def update(request):
call_command("videoscan") # Could potentially be very slow, blocking request.

We do a blocking call to videoscan on every update page request. If a scan is actually necessary, this can take a potentially long time.

Proposed fix:
Trigger this check through AJAX. Have some text indicating the scan is proceeding, and either update the page (or message the user that a refresh is required) if something in the scan was actually found.

Priority:
Low priority. It's a confusing user experience (just hangs for a while) for something that's very infrequent. Otherwise, it's a slight performance hit, but no real worry there.

@gimick This would be something good to check on the Rpi, however; if performance there is poor, we should increase the priority.

[jamalex]

Not sure if this was always so slow on the RPi, or if it has to do with some of the recent signals/cache invalidation stuff, but with a new DB (no VideoFiles), but 2500 videos on disk, the update page takes over 5 minutes to load for the first time.

[bcipolli]

This definitely got slower. I would suggest two changes:

1. Run videoscan on server startup, to avoid webpages from hanging. It would be clearer to the admin what's going on. This shouldn't be too much work, as there's a wrapper around the server starting already.
2. In order for videoscan to do bulk creation, it will need to call into the signal directly from videoscan.

[bcipolli]

This is easy - just call videoscan from the api request to get the annotated topic tree!