GNOME Bugzilla – Bug 521196
Conduit does not sync F-Spot photos with changed tags/captions
Last modified: 2008-07-17 02:44:18 UTC
The current implementation of the Photo data type does not handle photo metadata (such as tags/captions) changing as most providers only supply a Rid with a LUID and no hash or mtime element. To reproduce: 1) Export photos from F-Spot to another provider that accepts tags 2) Modify photo tags in F-Spot 3) Re-sync 4) Observer that the destinatino provider was not updated.
Created attachment 106847 [details] [review] Hash photo metadata so changes are detected and re-exported
Does this work for all photo sinks? Which ones did you test?
I've tested it primarily with a sink that I'm still developing. A quick test with a few of the other providers shows that Conduit is now correctly calculating what has changed within F-Spot and calling the put method of the sinks appropriately. I don't have accounts for most of the photo gallery providers, but I could test Picasa web. There is no logic in Picasa handler to remove/modify tags after the initial upload so although the Picasa dataprovider is correctly called nothing changes on the website. Scanning the code that none of the current Image based data providers will take advantage of the fixed functionality. Fixing that is outside the scope of this patch in my opinion.
Matt, I have emailed you with the details of how to run the test suite with appropriate login information so you can test this with the other photo data providers Implementation looks fine, except instead of + hash_data = "%s%s%s" % (file_hash, self.get_photo_size(), + self.get_caption()) you can do hash_data = hash((file_hash, self.get_photo_size(), self.get_caption()))
Any progress on this?
I've applied Matt's patch, it correctly detectes changes in size, caption and tags. At this time no image provider implements _replace_photo, so I've made a quick and dirty implementation in Image.py that should work for most of them. It simply deletes the photo and uploads the modified version. I've tested this with f-spot as source and Picasa and flickr as sinks and it seems to work well, although given the _replace_photo implementation, for every modified photo in the source appears a deletion conflict in the sink. So a better _replace_photo implementation should be done for every provider. I've found a extrange behavior of sync manager. In one way syncs, sync manager treats added and modified items the same way, both being sent to the sink with the overwrite flag set to False, so the photo is uploaded every time there's some change in its tags or caption. IMHO Synchronization.py should be modified to treat differently added and modified items. I don't know how it might affect the providers of other data types.
Created attachment 114319 [details] [review] This patch provides an implementation of _replace_photo for Picasa
Created attachment 114650 [details] [review] Implementation of _replace_photo for Zoto
(In reply to comment #6) > I've applied Matt's patch, it correctly detectes changes in size, caption and > tags. > > At this time no image provider implements _replace_photo, so I've made a quick > and dirty implementation in Image.py that should work for most of them. It > simply deletes the photo and uploads the modified version. Was this missing from the patch? > > I've tested this with f-spot as source and Picasa and flickr as sinks and it > seems to work well, although given the _replace_photo implementation, for every > modified photo in the source appears a deletion conflict in the sink. So a > better _replace_photo implementation should be done for every provider. > > I've found a extrange behavior of sync manager. In one way syncs, sync manager > treats added and modified items the same way, both being sent to the sink with > the overwrite flag set to False, so the photo is uploaded every time there's > some change in its tags or caption. IMHO Synchronization.py should be modified > to treat differently added and modified items. I don't know how it might affect > the providers of other data types. You mean because it may be more efficient to just update the metadata (if that makes sense), instead of just deleting the old image and adding a new one?
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report. Closing this bug and cloning to describe the new problem