I'm playing around with a method to fetch thumbnails via threads. Showing folders with a lot of pictures and movies and fetching thumbnails makes the user to wait for a long time.
Does someone has a working threaded solution for this kind of problem? Adding a Callback for a "thumb" gives me the problem how to return the result of a thread to the photo- or videoobject...
Greets
Sascha
You shouldn't have to thread this sort of stuff, most (if not all) of the Plex Apps do this for you already.
Calling this function in a loop for a whole bunch of pictures:
def createPhotoObject(item):
po = PhotoObject(
key = Callback(getUrl, item = item),
rating_key = item['key'],
title = item['title'],
thumb = Callback(getThumb, item = item)
)
return po
... results in a very long time the user has to wait. "getThumb" does an json call to fetch a valid thumb url and returns it.
Hm, cannot get it work that the user does not have to wait while fetching thumbnails. A "Callback" this way will block the system for each fetch-call...
Does your getThumb() return the url directly, or use a Redirect() as discussed here?
The getThumb() will return a DataObject with binarydata for the image in it or a Redirect with a fallback image...
tmp = False
if tmp != False:
return DataObject(tmp, 'image/jpeg')
else:
return Redirect(ICON_PHOTO)
Hmmm... can you paste the line that calls the createPhotoObject() method?
It's called by:
def createMediaObject(item):
if debug == True: Log("Checking item: " + item['path'])
filename, fileext = getFilenameFromPath(item['path'])
fileext = fileext.lower()
# Handle movie files.
if fileext == '.mp4' or fileext == '.mkv' or fileext == '.avi' or fileext == '.mov':
return createVideoClipObject(item)
if fileext == '.jpg' or fileext == '.jpeg' or fileext == '.png' or fileext == '.gif' or fileext == '.bmp' or fileext == '.tif' or fileext == '.tiff':
return createPhotoObject(item)
if fileext == '.mp3' or fileext == '.wav' or fileext == '.aac' or fileext == '.m4a':
return createTrackObject(item)
return False
... and it's used here:
def getDropboxThumbnailForPicture(path):
if debug == True: Log("Fetching thumbnail from dropbox for item: " + path)
mode = Prefs['access_mode'].lower()
tmp = apiRequest("https://api-content.dropbox.com/1/thumbnails/" + mode + path + "?size=m")
tmp = False
if tmp != False:
return DataObject(tmp, 'image/jpeg')
else:
return Redirect(ICON_PHOTO)
Hope this helps...
Running out of ideas at this point...
Are you certain that the thumbnails will always be jpeg format? I would think that providing an incorrect data type would mess things up.
Yes, the Dropbox core api delivers jpeg by default...
Ok. I think the next step is to check the xml generated for your list of objects by walking the XML tree using curl or a browser. Specifically, look at what sort of values are assigned to the 'thumb' attributes of each element.
Calling this function in a loop for a whole bunch of pictures:
... results in a very long time the user has to wait. "getThumb" does an json call to fetch a valid thumb url and returns it.
I think what's happening here is "normal" ... but it's not something we see all that much in typical channels because lots of times we are grabbing jpgs that are already in web pages or possibly cached, but also the calls are probably not throttled the way they would be with dropbox. So when you say "a bunch of images" how many do you mean? If there's 50 images then it's 50 separate HTTP calls for the JSON (assuming it takes a bit of time on their end to generate), parsing, and the another 50 HTTP calls to actually _load_ the jpgs themselves ... so however many images you're (at least) doubling the amount of HTTP calls and likely don't have any advantages of having anything cached. Just about anything doing that number of HTTP calls for a single "page" worth of content is likely going to take a long time.
Got it working. The hint with the wrong picture format was right for me. Don't know why but I've requested .png but told the channel that's a .jpg...
After fixing it the process it threaded and the user gets the "normal loading wheel" without having to wait and seeing a "block".
