GNOME Bugzilla – Bug 618573
F-Spot is fracturizing my pictures and messing them up COMPLETELY
Last modified: 2010-07-13 18:46:25 UTC
Wow... this was mindblowing. So, to begin: F-Spot is working very very slow and at some point crashed my whole system (freezing). I had to kill it (yes, sort of pulling the plug). Fun thing is: I rebooted and started it up again. Suddenly lots of my pictures are completely fractured (with parts of other pictures in them). Even those that I haven't been working (tagging only) on! As I started it over the terminal it gave me this for infinity: GLib.GException: Unrecognized image file format at Gdk.PixbufLoader.Write (System.Byte[] buf, UInt64 count) [0x00000] in <filename unknown>:0 at PixbufUtils+AspectLoader.Load (System.IO.Stream stream, PixbufOrientation orientation) [0x00000] in <filename unknown>:0 at FSpot.ImageFile.Load (Int32 max_width, Int32 max_height) [0x00000] in <filename unknown>:0 at ImageLoaderThread.ProcessRequest (.RequestItem request) [0x00000] in <filename unknown>:0 Exeption while reading jpeg headers System.Exception: Invalid marker found 229 at JpegHeader+Marker.Load (System.IO.Stream stream) [0x00000] in <filename unknown>:0 at JpegHeader.Load (System.IO.Stream stream, Boolean metadata_only) [0x00000] in <filename unknown>:0 at JpegHeader..ctor (System.IO.Stream stream, Boolean metadata_only) [0x00000] in <filename unknown>:0 error checking orientation Some of the pictures are not jpgs anymore. I get this, when trying to open them with eye of gnome: "Error interpreting JPEG image file (Invalid JPEG file structure: SOS before SOF)" Some of the pictures have been put to other places (meaning the contents of some pictures have overwritten others!). What sort of horror show is this? I'm lucky to have this stuff backed up... but holy cow... what HAPPENED?! I'm running on Archlinux x64, and latest stable of f-spot (currently 0.6.15), 4GB Ram, Intel DualCore, nvidia Graphics
That's scary indeed! Not something I can explain through the workings of f-spot itself. How full is your filesystem? Did you recently check it? My guess is that it became corrupted at some point. The freezing is probably a memory leak, we need to track those down, a high priority task.
(In reply to comment #1) > That's scary indeed! Not something I can explain through the workings of f-spot > itself. How full is your filesystem? Did you recently check it? My guess is > that it became corrupted at some point. > > The freezing is probably a memory leak, we need to track those down, a high > priority task. well, the filesystem seems to be okay. I ran a filesystem scan lately (no bad blocks so far). It's a ntfs filesystem inside a truecrypt volume. The disk is not full either, nor is my root filesystem (yet) ;) It seems as if the file headers have been modified. The memory leaks seem to be related to the background task syncing the metadata to files. If I run f-spot via terminal it always freezes the system while "writing metadata to file..." I know that just turning off the computer was not the best choice, but at that moment in time it seemed the only option... :/ I'm really not sure where to put all this
This is a zip with some messed up pictures, temp files and actually one picture still working in there: http://dl.dropbox.com/u/502921/Misc/f-spot-bug.zip
(In reply to comment #3) > This is a zip with some messed up pictures, temp files and actually one picture > still working in there: http://dl.dropbox.com/u/502921/Misc/f-spot-bug.zip Some of the broken pictures that come with a tmp file alongside produce this error message while opening: Error interpreting JPEG image file (Not a JPEG file: starts with 0x7d 0xfb)
This is a pretty serious corruption. Let's track this down: * Does this happen with all files? * Does this also happen if you store your photos on ext3 instead of ntfs? I'm suspecting that this is either a problem with NTFS (in which case this will be a tough nut to crack), or a problem with our JPEG parsing/writing. The latter case will get fixed once we switch to taglib#.
The problem right now occurs with some newer (!= newest) files and luckily not all files. I put some tags on these photos and after tagging some to have them on a upload queue the computer went unresponsive. Couldn't even get to tty1 or something to kill the processes. Complete system freeze. That's when the fun started because after reboot f-spot began messing with them so weirdly. So I replaced them with the originals (plain copy/paste over nautilus), but after a restart of f-spot it messed with them again. So I'm not too sure if another copy/paste action will finally get some better results or not... :> It's just a subset of some of the newer pictures being affected, which makes it so unexplainable to me. There is still plenty of room on the drive... I will test with some pictures that I'll put on ext3/ext4 and add them to the collection (while keeping their residence on that partition).
Make sure you send me some of these files in their uncorrupted form, I want them in our regression testing set for Taglib#
these are the unmodified originals of the messed up pictures above: http://dl.dropbox.com/u/502921/Misc/originals.zip I will now try to replace all the folders with broken pictures with the originals again and see what happens if f-spot 0.6.2 tries to handle them. to be continued... :>
There's indeed something strange with these files, when I run them through the Taglib# unit test framework, I get bad parsing before even writing. We'll need to investigate these. Adding Mike to CC.
Tested these files with Taglib# and they are working now. Should be safe. If this still happens with 0.7.1, then I'm not sure if it is related with F-Spot. Please reopen when it does.