Race condition in the picture slideshow

[Sudesh]

There is a race condition in the picture slideshow: the OSD, when updating the playcount, tries to access to the current image's URL, when this URL sometimes hasn't been retrieved yet. This is particularly easy to observe in the Flickr plugin.

Steps to reproduce:
1) Clean your flickr cache: rm -r ~/.moovida/flickr_cache
2) Launch Moovida, go to INTERNET MEDIA / Images / Flickr
3) Enter "Last 7 days interesting", scroll fast to the right and press OK to display a picture (this should be done fast enough so that the picture's information hasn't had time to be loaded)

Expected result: after a possible delay, the picture appears in the slideshow player.

Current result: black screen (picture slideshow with no picture loaded and no OSD), and the following traceback:

Traceback (most recent call last):
  File "/home/osomon/dev/elisa-branches/moovida/elisa-plugins/elisa/plugins/poblesec/slideshow/player.py", line 371, in _on_slideshow_picture_changed
    self._update_playcount_and_timestamp(model)
  File "/home/osomon/dev/elisa-branches/moovida/elisa-plugins/elisa/plugins/poblesec/slideshow/player.py", line 381, in _update_playcount_and_timestamp
    uri = picture.references[-1]
IndexError: list index out of range

[Olivier Tilloy (osomon)]

Can't reproduce here.
Is it happening consistently on the same pictures?

[Sudesh (sudeshc-deactivatedaccount)]

Yes , its happening consistently for same pictures.Right now happening for picture titled 'enigma' in Last seven days interesting.

[Olivier Tilloy (osomon)]

I can reliably reproduce 100% of the time.
The problem is not in some specific Flickr pictures, it's a race condition: the OSD tries to get the URL of an image before it's been retrieved.
I'm going to update the bug description with detailed steps to reproduce.

[Florian Boucault (fboucault)]

In fact in only happens with Flickr. The slideshow assumes that the picture model contains at least one address of where the picture can be retrieved from. It sounds like a safe assumption. Let's investigate the Flickr case.

[Florian Boucault (fboucault)]

Indeed, base's ImageModel specifies 'references' as containing URLs to the actual picture but no API to fill that up. Therefore the slideshow has no way to retrieve these URLs other than looking up the content of 'references'. If, as it is the case in Flickr, that list is filled asynchronously the slideshow cannot be aware of it and cannot wait for that operation to be completed since 1) there is no generic API to access the corresponding deferreds and 2) these deferreds are lost (see plugins/flickr/controller.py:160):

                    dfr, photo = _get_image_available_sizes(flickr_photo)
                    self.register_deferred(photo, dfr)
                    dfr.addErrback(_failure)

Action proposal: do not switch to the slideshow until these references are all retrieved.

[Florian Boucault (fboucault)]

This bug is unique to Flickr. It exposes a lack in Moovida's core API that I deemed as not critical.

As for Flickr the fix involve not calling http://www.flickr.com/services/api/flickr.photos.getSizes.html for each photo but constructing the URLs based on http://www.flickr.com/services/api/misc.urls.html

Lowering Importance.

[Olivier Tilloy (osomon)]

Calling http://www.flickr.com/services/api/flickr.photos.getSizes.html is not optional, since there is no way to guess what sizes are available for an image.

[Florian Boucault (fboucault)]

Plan is to override elisa.plugins.base.models.ImageModel.get_cached_data_path in elisa.plugins.flickr.models.FlickrPhotoModel and add safeguards in the slideshow's OSD code when no references are available.