Bug 1079679
| Summary: | gthumb constantly complaints "Error: XMP Toolkit error 203" and moves like in a tarpit | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> | ||||||
| Component: | gthumb | Assignee: | Christian Krause <chkr> | ||||||
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | unspecified | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 22 | CC: | chkr, michal | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2016-07-19 11:13:33 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
Close to beginnig of xmp data there is something which looks like: xpacket begin='<U+FEFF>' Apparently bugzilla interface swallowed some stuff not to its liking. Hi Michal, please can you attach a complete picture with the offending EXIF data? Created attachment 897374 [details] sample picture file making gthumb to complain "XMP Toolkit error 203". > Hi Michal, please can you attach a complete picture with the offending EXIF data? It appears that you can easily produce a sample loading some jpeg picture into gimp, possibly doing some edits, and overwriting an original. Anyway, here is one of results. It generates at least two, sometimes more, ""Error: XMP Toolkit error 203" complaints. At this time I do not see "Warning: Failed to decode XMP metadata". Quite possibly some underlying libraries changed in the meantime. It turns out that 'jhead' has -dx option which removes XMP section from exif headers. After such picture processing gthumb stops these complaints. I made rough stop-watch measurements how fast I can walk with a gthumb over a directory of 35 jpeg files (sizes 2848x2136) by hitting a space bar. With XMP data present this takes on my test box around 180 seconds. Dropping XMP as above makes that a bit faster (around 4-5 seconds per picture) but not that fast after all. In a contrast with gthumb-2.10.11-8.el6.x86_64 on a CentOS installation I can switch through the same pictures as fast as I can hit a space bar. So a general slowdown does not seem to be really a result of XMP complaints. Is there any simple way of extracting XMP exif data in such format? exiftool does not seem to have a way to keep tags. This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22 Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |
Created attachment 877708 [details] stuff added by gimp which is causing gthumb inscrutable complaints Description of problem: While viewing with a gthumb a directory of pictures in JPEG format one is constantly nagged with a stream of error messages like that: ..... Error: XMP Toolkit error 203: Duplicate property or field node Warning: Failed to decode XMP metadata. Error: XMP Toolkit error 203: Duplicate property or field node Warning: Failed to decode XMP metadata. Error: XMP Toolkit error 203: Duplicate property or field node Error: XMP Toolkit error 203: Duplicate property or field node .... Not sure if this is a cause but now switching between images in gthumb take REALLY loooooong time and after hitting a space bar or "next" one often wonders if gthumb already crashed because there is no visible reaction. On my machine it may take 10 seconds (on a stopwatch) to get from one picture to the next; although this time is not constant even with outwardly similar pictures. Older versions of gthumb were not crippled that way. Version-Release number of selected component (if applicable): gthumb-3.2.6-1.fc20 How reproducible: always Expected results: gthumb shows the next picture in one-two seconds like it used to and does not spam me with messages which really do not say very much. Additional info: It appears that XMP data were added by gimp. Still "molasses effect" is still present when looking at original messages from a camera which include EXIF headers but are clean of XMP stuff. Is a time wasted in droves looking for this junk? I attach sample XMP data as extracted from a file edited by gimp (version gimp-2.8.10-4.fc20.x86_64).