GNOME Bugzilla – Bug 324425
Clear existing database of Invalid size of entry
Last modified: 2007-05-24 20:02:42 UTC
Please describe the problem: I have not set the titel on my pictures yet, but I found the following text there. Invalid size of entry (8, expected 0 * 1). I did set the titel (in picture view, just below the picture), and this message/titel dissapeared and the one I set is there instead. As it should. Steps to reproduce: 1. Import a new photo (with no tags nor title) 2. Go to Photo view mode (not browser mode) 3. Check the title Actual results: Invalid size of entry (8, expected 0 * 1). Expected results: A blank title (or "Please enter a subject/title for this picture" message) Does this happen every time? Yes Other information: This has been confirmed for Canon S70, Nikon D1, and Canon 20D. Larry commented : Sounds like libexif if complaining an returning that text as the result. I really need to stop using libexif and switch to the code in f-spot.
Image behind this url shows same behaviour (1.1MB): http://varg.dyndns.org/psi/random/dsc_1378.jpg
My libexif is Ubuntu/dapper, package libexif12 version 0.6.12-2.
Distro: Gentoo libexif ver: 0.6.12
Ubuntu/Breezy, package libexif12 version 0.6.12-2
Here's another from my Canon A520 http://www.core.binghamton.edu/~burner/StomachButt/img_2686.html
A duplicate bug of this one was filed (bug #326999)
*** Bug 326999 has been marked as a duplicate of this bug. ***
Debian unstable, libexif 0.6.12-2
Any news on this one?
Actually I haven't seen this behaviour recently; I'm still using a relatively old CVS checkout of f-spot with my own modifications and libexif 0.6.12-2 from Debian unstable, and my last set of imports over the last fortnight didn't exhibit this bug at all.
sorry, it is still there for me. Same libexif (Dapper/Ubuntu), latest CVS checkout though.
this should be fixed now.
Seems to be something within Exif. Did some extra tracing... :) Printout from Exif.cs, Lookup function public ExifEntry Lookup (Tag tag) { Assemble (); foreach (ExifEntry entry in entries) System.Console.WriteLine ("entries >>{0}<< - >>{1}<<", entry, entry.Value); entries >>Exif.ExifEntry<< - >>1/4 sec.<< entries >>Exif.ExifEntry<< - >>f/2.8<< entries >>Exif.ExifEntry<< - >>Exif Version 2.1<< entries >>Exif.ExifEntry<< - >>2000:08:29 21:56:29<< entries >>Exif.ExifEntry<< - >>2000:08:29 21:56:29<< entries >>Exif.ExifEntry<< - >>Y Cb Cr -<< entries >>Exif.ExifEntry<< - >>3.00<< entries >>Exif.ExifEntry<< - >>131072/65536 sec. (APEX: 2)<< entries >>Exif.ExifEntry<< - >>f/2.8<< entries >>Exif.ExifEntry<< - >>0.0<< entries >>Exif.ExifEntry<< - >>2.97<< entries >>Exif.ExifEntry<< - >>65.5 m<< entries >>Exif.ExifEntry<< - >>Center-Weighted Average<< entries >>Exif.ExifEntry<< - >>Flash fired.<< entries >>Exif.ExifEntry<< - >>5.4 mm<< entries >>Exif.ExifEntry<< - >>310 bytes unknown data<< entries >>Exif.ExifEntry<< - >>Invalid size of entry (8, expected 0 x 1).<< entries >>Exif.ExifEntry<< - >>FlashPix Version 1.0<< entries >>Exif.ExifEntry<< - >>sRGB<< entries >>Exif.ExifEntry<< - >>1600<< entries >>Exif.ExifEntry<< - >>1200<< entries >>Exif.ExifEntry<< - >>7766.99<< entries >>Exif.ExifEntry<< - >>7741.94<< entries >>Exif.ExifEntry<< - >>Inch<< entries >>Exif.ExifEntry<< - >>One-chip color area sensor<< entries >>Exif.ExifEntry<< - >>DSC<<
Created attachment 60139 [details] Picture with weird UserComment Larry, I used Eye of Gnome and checked some of my photos, and I can see this User Comment here as well? But I do not see this when I use a Windows program (IrfanView). I attach the photo I have been playing with. Could this be related to libexif? and might be fixed if we use our own?
Also, we need an Update function to remove a possible "Invalid size of entry *" comment, both in database, as well as in exif.
I did not see the problem anymore, since Larry fixed it (comment #12). Bengt, it's possible that you can still see it with eog because f-spot writes data in the Metadata of the file (if the preference is checked). You can remove that from the db using an sql command(do you want it ? really ?), and the new (empty) comment will be written next time you do something on an image (tagging, changing time, ...) Since the bug is fixed, I guess we can close it. Btw, it could be a good help to users if we add a small 'upgrade database' script with the next release, removing all the bad comments and incrementing the db version.
ok, I close this one.
I re-open and change the title of this one, to reflect the fact that we need to update the existing databases, and remove this title. Invalid size of entry (8, expected 0 * 1). I think it is enough to check for Invalid size of entry and if this is found, clear the title.
I'm still seeing this on metadata browser User Comment Invalid size of entry (8, expected 0 x 1).
Could you attach a photo that you get this problem with when you import it to F-Spot?
Created attachment 70629 [details] Example photo
Just tried to import this photo in CVS version of F-Spot, and can confirm that this photo show's the "Invalid size of entry (8, expected 0 x 1)." in Metadata browser. I also imported it with my XMP Import patch, and got the following result. 1 Subject = >><< 2 Predicate = >>http://ns.adobe.com/exif/1.0/UserComment<< 3 Object = >>_<< 4 Meta = >>_<< 5 Uri = >><< 6 Title = >>UserComment<< 7 Value = >>null<< --- Collection YES 8 type = >>Alt<< 9 title = >>22-rdf-syntax-ns#li<< 10 value = >><< UserComment is "" in this case. The XMP Import patch, removes all illegal characters from the start/end of the string though
Could this one be related to bug #356259 (The character's Bug #356259 refers to is removed in the patch I used in comment #23)
I added a reminder note in the Updater.cs to consider cleaning this during the next major db upgrade
I'm about to fix this in SVN, but I need a photos.db with those invalid entries. So, if you have one, send it to me by email
fixed in r3110