photos edited in gallery do not display edited in "My Photos" scope

Not sure who's to blame here. I suspect it's not unity-scopes-api, but more likely some interaction between the shell and the scope implementation.

I just tried this with the new thumbnailer, which isn't to blame. Basically, what's happening is that, after rotating the photo, the image file under ~/Pictures/com.ubuntu.camera is correctly re-writting, including its rotation information. If you look at the rotated photo with the gallery app, it is correctly shown with its new rotation, meaning that the thumbnailer correctly realised that the image was updated and generated a new thumbnail.

However, the photo scope fails to realize that the image was touched. It looks like the photo scope does its own thumbnailing, but ignores the rotation data or some such.

At any rate, this isn't a problem in the thumbnailer.

@Michi & @Pawel: Is the problem that unity8 simply continues to use the original cached result because it has no way to know it has changed (the URI is unchanged)?

Note: the scope uses image://thumbnailer/PATH to display the result.Art.

Not surprisingly: the same thing happens with other edits in Gallery, for example crop.

> Is the problem that unity8 simply continues to use the original cached result

Almost certainly, yes. The thumbnailer will realise that the file has changed an it will re-create the thumbnail for it, but only if someone actually asks the thumbnailer for the thumbnail again.

I suspect that this could be fixed the same way you fixed it during the spring, by appending some suffix to the image URL that changes each time a photo is edited. (A counter might work.)

@Michi:

Appending a timestamp param (image://thumbnailer/PATH&TIMESTAMP) to every photo's art uri accomplishes the goal: on refresh edited photos display edited in surfafed results

I assume this approach does not force the thumbnailer to rethumbnail every photo every time (even though the URIs are now always new) because when there has been no edit of the photo the file modification time has not changed. Please correct me if this assumption is incorrect.

That sounds good. The thumbnailer will re-thumbnail if and only if mtime or ctime have changed. So, if you append the timestamp only when there actually was an edit, that will trigger a re-thumbnail only when the time stamp changes.

And setting the image source to the modified URL invalidates the QML cache, so QML triggers a refresh of the thumbnail.

This all sounds good. If you want to verify that it behaves as you expect, just run a trace on dbus.log, and you'll be able to exactly when the thumbnailer does any work for that image.

fixed with com.canonical.scopes.photos-local_1.27_armhf.click in clicks branch.

Penk, can you please arrange for QA?

@Ethan, could you please verify this issue with the latest click package, thanks!

Hello Ethan,

Please find attached one Kyle pushed,
thanks.

Verified with photos-local 1.27.

David Morely found that in the latest latest bq-aquaris.en-proposed image no photos show with 1.27 in my photos, which I confirm in build 283 & 286. Strange, since both I and Ethan found 1.27 worked. Reopening bug.

Unity seems to need another slash now in the result art uri:

* "image://thumbnailer/pathtoimage" fails
* but "image://thumbnailer//pathtoimage" works

So I've adjusted the result art uri accordingly.

fixed in 1.28 attached to bug and pushed to clicks since this is probably needed for OTA10.

I'm surprised that this has ever worked, and works with the double slash possibly only by accident.

According to the doc (https://developer.ubuntu.com/en/apps/qml/tutorials/use-ubuntu-thumbnailer/), it should be

image://thumbnailer/file://pathtoimage

I strongly suspect that the fix really should be to include "file:" as above.

Ah, thanks Michi.

Attaching version 1.29 (also in clicks branch) to pick up the mod Michi recommends.

Apologies: please use 1.30 attached here and in clicks branch

While testing tarballs discovering that the MTP use case isn't served by this fix, discussing with kyleN whether or not a new bug is needed.

Hi Allan,

This fix handles photos taken by the camera (then rotated in gallery) and photos downloaded through the browser(then rotated in gallery), to name two.

I am guessing this is therefore a different issue, perhaps something to do with MTP & mediascanner & gallery. Therefore, I think this needs a new bug and we can release with the current fix.

Added mediascanner2 because we don't know yet what's actually causing this.

Michi, This is a new issue now tracked in https://bugs.launchpad.net/savilerow/+bug/1562121

cheers

This was fix released a long time ago.

I tested version com.canonical.scopes.photos-local_1.38_armhf.click in clicks (which was in ota 13) and the photo rotated from gallery then displays rotated in photos-local (My Photos) scope.