Summary: | tags not exported to picasaweb [patch] | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | Philippe ROUBACH <philippe.roubach> |
Component: | Plugin-WebService-Google | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | clement.cc |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | 1.1.0 | |
Attachments: |
Patch agianst kipi-plugins-0.8.0
New patch with fix for multiple tags |
Description
Philippe ROUBACH
2009-07-06 12:35:23 UTC
same pb if you don't select "export app tabs" addendum i put this as tag in the right panel: Architecture/Architecte/Eric Dubosc i found this in iptc Eric Dubosc,Architecte,Architectecture i found this in xmp Architecture/Architecte/Eric Dubosc,Architecture/Architecte,Architecture Mandriva 2010.0b1 digikam 1.0.0b4 kipi-plugins 0.5.0 pb still there *** Bug 175260 has been marked as a duplicate of this bug. *** Mandriva 2010.0rc1 digikam 1.0.0b5 kipi-plugins 0.7 same pb it's a pity if the pb is fixed i need no more to use picasa to export to picasaweb then i can abandon picasa any news ? do you plan to fix it ? Created attachment 38516 [details]
Patch agianst kipi-plugins-0.8.0
This is because the Picasa plugin currently doesn't use the tags at all, even when explicitly told to: picasawebwindow.cpp: 425 void PicasawebWindow::slotUploadImages() 477 if(m_exportApplicationTags->isChecked()) 478 { 479 // tagsFromDatabase=attribs["tags"].asStringList(); 480 } Now, I don't know who put that there. Maybe there was a good reason back then. But if I just copy over whatever the flickr plugin is doing there right now, everything seems to work. Also, I haven't done a lot of Qt programming. But I'm pretty sure you guys meant a checkbox instead of that radiobox with just one choice. And it should probably default to on like they do for the flickr plugin since most people will probably want that. The patch attached fixes both #199145 and #205903. Wait a second. Now I'm getting randomly missed tags. Sometimes if a photo have a dozen tags, only a few of them arrives. Sometimes if I re-upload the exact same image, I get a different set of successful tags. (some of the previously failed ones suddenly works) Maybe they commented that out for good reasons after all. Let me see if I can find the problem. Looks like we must add tags separately after the upload in the Picasa API. And we must add them one by one. That seriously sucks compared to the simplicity in the Flickr API... @siu chung anyway many thanks for your job Alright, I think I know why. Used Wireshark to capture all the packets. The requests are all sent correctly and Google received them. Even returned a "201 Created". But if you look closely at the Google API, they don't implement locking (probably for performance reasons). The way to update something is to download the whole thing and then upload the whole thing. Now consider this sequence: 1. Get tags to add tag 1 (received no tags) 2. Get tags to add tag 2 (received no tags) 3. Set tags to nothing + tag 1. Send. 4. Set tags to nothing + tag 2. Send. Now tag 1 is lost. Classic race condition. If I add a dialog box after every add tag message, it works. Also, the last tag never get lost. That makes me think this is the problem. The Google recommended solution is to use etags. Except that we can't. Because we're updating the tag entry here, not the photo entry. This is an oversight on Google's part IMHO. But not all hope is lost. :-) I studied the official Google libraries and I found that they do this: 1. Upload picture. 2. Use response to construct photo entry object 3. Add keywords and everything to photo entry object 4. Call commit on the photo entry object to send changes. On the wire, this is what happens: 1. Upload picture using HTTP POST 2. Server returns ATOM with all metadata of this picture 3. Library parse this XML into photo entry object 4. Caller modifies photo entry object 5. Caller commits 6. Library constructs new XML and do an HTTP PUT. All we need to do is to emulate that and add all tags in one shot. (only one tag request hence no race conditions) 1. Upload picture using HTTP POST 2. Server returns ATOM/XML with all metadata 3. We parse and modify this XML. Add all the tags we want. 4. Send back this XML using HTTP PUT. This approach has the advantage of allowing other stuff such as Geotags in the future. We can specify that explicitly for image files where Google fails to parse the IPTC Geotags. (saw some bugs on bugs.kde.org) All done in a single shot. I've made a new patch. Seems to work. Tested with around 30 photos with 6 or 7 tags each. All arrived correctly. Feel free to change the coding style if you don't like it. Future wish: would be nice if someone can parallelize the picture resizing. You could resize the next picture while this picture is uploading. Created attachment 38567 [details]
New patch with fix for multiple tags
great job ! :=) (In reply to comment #12) > Created an attachment (id=38567) [details] > New patch with fix for multiple tags if you have time to also fix this bug which is similar but about movie movie export works well but not exporting legend, tags, geotag https://bugs.kde.org/show_bug.cgi?id=215664 this would be complete thanks very much digikam 1.0.0rc kipi-plugins 0.8 same pb : tags are not exported (export tags checked or not digikam 1.0.0rc kipi-plugins 0.9 same pb : tags are not exported ("export tags" checked or not) digikam 1.0.0 kipi-plugins 1.0.0 same pb : tags are not exported ("export tags" checked or not) SVN commit 1067206 by cgilles: apply pâtch #38547 from Siu Chung to export Tags to PicasaWeb BUGS: 199145 M +2 -2 mpform.cpp M +31 -43 picasawebtalker.cpp M +4 -3 picasawebtalker.h M +1 -1 picasawebwindow.cpp M +1 -1 picasawebwindow.h M +4 -1 uploadwidget.ui WebSVN link: http://websvn.kde.org/?view=rev&revision=1067206 |