From snap.56k at gmail.com Thu Dec 1 15:42:27 2011 From: snap.56k at gmail.com (snap.56k at gmail.com) Date: Thu, 01 Dec 2011 10:42:27 -0500 Subject: [Shotwell] Introduction of a new member :) Message-ID: <4ED7A063.2040504@gmail.com> Hello ! I am a happy Shotwell user and I would like to contribute to the project. I would like to write a plugin that would show on a map where the photos were taken. I know OOP languages but not Vala. I hope this is not too much ambitious. Is the plugin system ready? My plugin would modify the user interface and I am not sure that existing plugins that already do this. I joined Redmine and I had a quick look at the code / doc. If you have any suggestions to getting me started faster (such as "find out how Shotwell does x,y,z") you're more than welcome :) !! Also what should I do to get my patches reviewed ? Many thanks -- Snap From el.cameleon.1 at gmail.com Thu Dec 1 15:52:34 2011 From: el.cameleon.1 at gmail.com (Vincent) Date: Thu, 1 Dec 2011 16:52:34 +0100 Subject: [Shotwell] Introduction of a new member :) In-Reply-To: <4ED7A063.2040504@gmail.com> References: <4ED7A063.2040504@gmail.com> Message-ID: Welcome Snap, I think that you should start to give a look to: Feature #2875 [patch] basic map widget implementation 2011/12/1 > Hello ! > > I am a happy Shotwell user and I would like to contribute to the > project. I would like to write a plugin that would show on a map where > the photos were taken. I know OOP languages but not Vala. I hope this is > not too much ambitious. > > Is the plugin system ready? My plugin would modify the user interface > and I am not sure that existing plugins that already do this. > > I joined Redmine and I had a quick look at the code / doc. If you have > any suggestions to getting me started faster (such as "find out how > Shotwell does x,y,z") you're more than welcome :) !! > > Also what should I do to get my patches reviewed ? > > Many thanks > > -- > Snap > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From adam at yorba.org Thu Dec 1 15:52:41 2011 From: adam at yorba.org (Adam Dingle) Date: Thu, 01 Dec 2011 07:52:41 -0800 Subject: [Shotwell] Introduction of a new member :) In-Reply-To: <4ED7A063.2040504@gmail.com> References: <4ED7A063.2040504@gmail.com> Message-ID: <4ED7A2C9.9090304@yorba.org> On 12/01/2011 07:42 AM, snap.56k at gmail.com wrote: > Hello ! > > I am a happy Shotwell user and I would like to contribute to the > project. Welcome, Snap, and thanks for your interest in contributing to Shotwell. > I would like to write a plugin that would show on a map where > the photos were taken. This would certainly be a nice feature to have. One user has done some work toward this - see http://redmine.yorba.org/issues/2875 and the patches attached there. The last patch there is about 4 months old, so I'm not sure whether it will build with the current trunk. You might want to look at that work and see if it would make a good starting point. If you do start working on this you should also let us know via a comment to that ticket, which is a reasonable place for further discussion about this feature. > I know OOP languages but not Vala. I hope this is > not too much ambitious. Vala shouldn't be too hard to learn if you know Java (or C#), especially if you also know C. There are good learning resources available at http://live.gnome.org/Vala . > > Is the plugin system ready? My plugin would modify the user interface > and I am not sure that existing plugins that already do this. Shotwell's plugin system currently only allows you to add new publishing destinations and slideshow transitions. So you won't be able to implement this as a plugin: it will simply be an enhancement to the Shotwell code base. > > I joined Redmine and I had a quick look at the code / doc. If you have > any suggestions to getting me started faster (such as "find out how > Shotwell does x,y,z") you're more than welcome :) !! You should definitely read our architecture overview at http://redmine.yorba.org/projects/shotwell/wiki/ShotwellArchitectureOverview . > > Also what should I do to get my patches reviewed ? As described at http://redmine.yorba.org/projects/shotwell/wiki : To submit a patch, please format it using `git format-patch`, attach it to a new or existing Shotwell ticket, and change the ticket's status to Review. adam From snap.56k at gmail.com Thu Dec 1 16:05:04 2011 From: snap.56k at gmail.com (snap.56k at gmail.com) Date: Thu, 01 Dec 2011 11:05:04 -0500 Subject: [Shotwell] Introduction of a new member :) In-Reply-To: <4ED7A2C9.9090304@yorba.org> References: <4ED7A063.2040504@gmail.com> <4ED7A2C9.9090304@yorba.org> Message-ID: <4ED7A5B0.703@gmail.com> Vincent and Adam, thank you very much ! PS: I configured the list to send my own posts, but it does not seem to work. S From camille.hamon at gmail.com Sat Dec 3 21:26:06 2011 From: camille.hamon at gmail.com (Camille Hamon) Date: Sat, 3 Dec 2011 22:26:06 +0100 Subject: [Shotwell] Use google to login on Flickr Message-ID: Hello, Let me first thank you for your excellent software. It is a pleasure to use it! I've had a problem though: I would like to publish some pictures on Flickr and my Flickr account is linked to my google account, but I cannot log in using my google account in Shotwell. I saw that this issue has been raised before there: http://redmine.yorba.org/issues/3043 I was wondering if this problem is going to be fixed in future versions of Shotwell, or if there was already some solution that I've missed. Camille From adam at yorba.org Mon Dec 5 18:49:38 2011 From: adam at yorba.org (Adam Dingle) Date: Mon, 05 Dec 2011 10:49:38 -0800 Subject: [Shotwell] Use google to login on Flickr In-Reply-To: References: Message-ID: <4EDD1242.60805@yorba.org> On 12/03/2011 01:26 PM, Camille Hamon wrote: > Hello, > > Let me first thank you for your excellent software. It is a pleasure to use > it! Thanks! > > I've had a problem though: I would like to publish some pictures on Flickr > and my Flickr account is linked to my google account, but I cannot log in > using my google account in Shotwell. > I saw that this issue has been raised before there: > http://redmine.yorba.org/issues/3043 > > I was wondering if this problem is going to be fixed in future versions of > Shotwell, or if there was already some solution that I've missed. > I've just marked this bug for the upcoming 0.12 release - no promises, but we'll see what can do. In the meantime, maybe you can use the workaround suggested by twchambers on the ticket above: === If it makes any difference, I have found that it is possible to sign in using a google account. Instead of trying to left-click the google logo, right-click and use 'open link'. You can then sign in and use the features as intended. === adam From davidvj at frontier.com Wed Dec 7 01:36:02 2011 From: davidvj at frontier.com (davidvj) Date: Tue, 6 Dec 2011 17:36:02 -0800 (PST) Subject: [Shotwell] Image Dates Message-ID: <1323221762397-50113.post@talk.nabble.com> I have just re installed Shotwell and am having a problem with images being 'misplaced' by date. For instance a large number of images are sorted by Shotwell and displayed under a July 2009 time-frame where all of the exif data indicates that the material was shot in 2006, 2005, 2004 and earlier. Exactly what date is Shotwell reading to locate the images? I set the date import structure to simply give me Year and Month ... but Shotwell insists on providing Year/Month/Day/Weekday ... and then often 2 or more entries for the dame day. What is going on? David Ubuntu 11.10 latest Shotwell release. -- View this message in context: http://shotwell.3510.www.nabble.com/Image-Dates-tp50113p50113.html Sent from the Shotwell mailing list archive at Nabble.com. From rom at rom1v.com Sun Dec 11 08:26:10 2011 From: rom at rom1v.com (Romain Vimont =?ISO-8859-1?Q?=28=AEom=29?=) Date: Sun, 11 Dec 2011 09:26:10 +0100 Subject: [Shotwell] =?utf-8?q?Updating_library=E2=80=A6?= In-Reply-To: References: <1318447373.2405.52.camel@rom-laptop> <1319511037.7639.10.camel@rom-laptop> Message-ID: <1323591970.2323.82.camel@rom-laptop> So, there is no way to make shotwell work correctly on an encrypted volume ? Each time I start it, it nearly freezes my computer for at least 2 minutes, I can't do anything else during this "update"? and it is just for "updating a library" where I know there is no changes at all, never (I always import using shotwell). Le mardi 25 octobre 2011 ? 12:11 -0700, Lucas Beeler a ?crit : > > Is it possible to disable this check ? > > No. It's a fundamental part of the Shotwell startup process. > > > My /home is encrypted (with ecryptfs), > > so maybe it makes the check fail. > > I know rsync always considers a file > > is modified (even if it isn't) when > > the filesystem is encrypted, I have > > to use rsync -c. > > The modification time issue is the problem here. It forces Shotwell to > reimport every photo file, thinking that you modified it an external > application (e.g., you browsed your photos in Nautilus, selected a > photo, opened it in the GIMP and changed it). Check to see if > encryptfs has mount options to prevent this behavior. > > Cheers, > Lucas > From list at heinrich-muenz.de Mon Dec 12 10:23:34 2011 From: list at heinrich-muenz.de (Heiner) Date: Mon, 12 Dec 2011 11:23:34 +0100 Subject: [Shotwell] Strange *.jpg_original files Message-ID: <4EE5D626.2070502@heinrich-muenz.de> Hi, I've detected a lot of "*.jpg_original" files lately inside my photo folders. This is quite strange, because I don't use shotwell for editing purposes. My workflow is as follows: I copy CR2 raw files from my camera into a directory (without using shotwell). Then I use Canon Digital Photo Professional (via wine) to develop the raws and safe them as jpg files in the same directory. Finally, I drag'n drop the files from this directory into a shotwell window using the "copy" option, which will result in paired RAW+JPG. Just the tagging is done inside shotwell. So where do all these *.jpg_original files come from? And how can I get rid of them without crashing my database? Thanks Heiner From dougie at highmoor.co.uk Mon Dec 12 10:32:42 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Mon, 12 Dec 2011 10:32:42 +0000 Subject: [Shotwell] Strange *.jpg_original files In-Reply-To: <4EE5D626.2070502@heinrich-muenz.de> References: <4EE5D626.2070502@heinrich-muenz.de> Message-ID: <4EE5D84A.7090300@highmoor.co.uk> On 12/12/11 10:23, Heiner wrote: > Hi, > > I've detected a lot of "*.jpg_original" files lately inside my photo > folders. This is quite strange, because I don't use shotwell for editing > purposes. My workflow is as follows: Do you use 'exiftool' anywhere in the workflow, or anything that might call exiftool? e.g. geosetter. exiftool, and no doubt other utilities, create files with an _original suffix whenever changes are made, although it can be overridden on the command line with --overwrite_original (I think, from memory). From list at heinrich-muenz.de Mon Dec 12 10:38:51 2011 From: list at heinrich-muenz.de (Heiner) Date: Mon, 12 Dec 2011 11:38:51 +0100 Subject: [Shotwell] Strange *.jpg_original files In-Reply-To: <4EE5D84A.7090300@highmoor.co.uk> References: <4EE5D626.2070502@heinrich-muenz.de> <4EE5D84A.7090300@highmoor.co.uk> Message-ID: <4EE5D9BB.2000804@heinrich-muenz.de> Thanks, Dougie! indeed, i do use exiftool to copy tags into files after editing them in GIMP! This might be the solution. I'll try to simply delete these files. Heiner Am 12.12.2011 11:32, schrieb Dougie Nisbet: > On 12/12/11 10:23, Heiner wrote: >> Hi, >> >> I've detected a lot of "*.jpg_original" files lately inside my photo >> folders. This is quite strange, because I don't use shotwell for editing >> purposes. My workflow is as follows: > > Do you use 'exiftool' anywhere in the workflow, or anything that might > call exiftool? e.g. geosetter. exiftool, and no doubt other utilities, > create files with an _original suffix whenever changes are made, > although it can be overridden on the command line with > --overwrite_original (I think, from memory). > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From tim at night-shade.org.uk Mon Dec 12 10:49:38 2011 From: tim at night-shade.org.uk (Tim Fletcher) Date: Mon, 12 Dec 2011 10:49:38 +0000 Subject: [Shotwell] Strange *.jpg_original files In-Reply-To: <4EE5D9BB.2000804@heinrich-muenz.de> References: <4EE5D626.2070502@heinrich-muenz.de> <4EE5D84A.7090300@highmoor.co.uk> <4EE5D9BB.2000804@heinrich-muenz.de> Message-ID: <1323686978.23014.5.camel@hickory.parrswood.manchester.sch.uk> On Mon, 2011-12-12 at 11:38 +0100, Heiner wrote: > Thanks, Dougie! > > indeed, i do use exiftool to copy tags into files after editing them in > GIMP! This might be the solution. I'll try to simply delete these files. Maybe try moving them out of the way first rather than deleting them? -- Tim Fletcher From list at heinrich-muenz.de Mon Dec 12 12:12:16 2011 From: list at heinrich-muenz.de (Heiner) Date: Mon, 12 Dec 2011 13:12:16 +0100 Subject: [Shotwell] Strange *.jpg_original files In-Reply-To: <1323686978.23014.5.camel@hickory.parrswood.manchester.sch.uk> References: <4EE5D626.2070502@heinrich-muenz.de> <4EE5D84A.7090300@highmoor.co.uk> <4EE5D9BB.2000804@heinrich-muenz.de> <1323686978.23014.5.camel@hickory.parrswood.manchester.sch.uk> Message-ID: <4EE5EFA0.6050303@heinrich-muenz.de> Am 12.12.2011 11:49, schrieb Tim Fletcher: > On Mon, 2011-12-12 at 11:38 +0100, Heiner wrote: >> Thanks, Dougie! >> >> indeed, i do use exiftool to copy tags into files after editing them in >> GIMP! This might be the solution. I'll try to simply delete these files. > Maybe try moving them out of the way first rather than deleting them? > Of course, I'll do this step by step! From spyro2 at gmail.com Mon Dec 12 14:39:06 2011 From: spyro2 at gmail.com (Ian Molton) Date: Mon, 12 Dec 2011 14:39:06 +0000 Subject: [Shotwell] =?utf-8?q?Updating_library=E2=80=A6?= In-Reply-To: <1323591970.2323.82.camel@rom-laptop> References: <1318447373.2405.52.camel@rom-laptop> <1319511037.7639.10.camel@rom-laptop> <1323591970.2323.82.camel@rom-laptop> Message-ID: <4EE6120A.5030901@gmail.com> On 11/12/11 08:26, Romain Vimont (?om) wrote: > So, there is no way to make shotwell work correctly on an encrypted > volume ? Why not use whole disk encryption with LVM. I see zero issues with this method. I have 30,000 photos or so and the startup time is under 5 seconds. From kahing at gmail.com Sat Dec 10 23:15:17 2011 From: kahing at gmail.com (Ka-Hing Cheung) Date: Sat, 10 Dec 2011 15:15:17 -0800 Subject: [Shotwell] shotwell import failure Message-ID: I've been trying to import photos recently and the operation always fails after importing a few (most of the time only one) photos, and then it would pop up a dialog saying "X photos failed to import due to a file or hardware error". Retrying again would (sometimes) import some more, and if I keep trying, eventually either shotwell crashes, or I can import the entire collection. I am using shotwell 0.11.6, and ubuntu 11.10, but it's happened with prior versions as well (but not all the versions, I remember it didn't used to happen). I didn't capture a backtrace but the assertion for the crash is: ERROR:src/MediaViewTracker.c:510:media_accumulator_real_uninclude: assertion failed: (self->photos > 0) Aborted Running shotwell in terminal results in lots of: ?C9 : data corrupted at 1630556 0* hd : data corrupted at 1762984 ?$xd : data corrupted at 1630487 : data corrupted at 1642091 and the like. Setting SHOTWELL_LOG=1 produced the attached log file. The problem happens regardless if I am importing directly from the camera card, or from a local directory after copying the photos over. I don't think the photos are corrupted, since if I keep trying all of them eventually import fine. From adam at yorba.org Mon Dec 12 18:37:43 2011 From: adam at yorba.org (Adam Dingle) Date: Mon, 12 Dec 2011 10:37:43 -0800 Subject: [Shotwell] shotwell import failure In-Reply-To: References: Message-ID: <4EE649F7.2090503@yorba.org> Ka-Hing, thanks for the bug report. We saw a crash like this a few months back, but were unable to reproduce it so we closed the bug: http://redmine.yorba.org/issues/3994 That crash seemed to be related to RAW photos. Do you have RAW photos in your collection? We didn't receive your log file since our mailing list doesn't allow attachments. You can either mail it the Yorba team at shotwell at yorba.org, or open a ticket in our Redmine bug tracker and attach it there. It might also be helpful if you could do either or both of the following: - Build the latest Shotwell sources from git master and see if the crash still occurs. (If it doesn't, it's presumably fixed already and we will probably not investigate further.) - Run Shotwell under GDB to generate a stack backtrace, which might be informative. See http://redmine.yorba.org/projects/shotwell/wiki/ShotwellFAQ#I-found-a-bug-in-Shotwell-How-can-I-report-it adam On 12/10/2011 03:15 PM, Ka-Hing Cheung wrote: > I've been trying to import photos recently and the operation always > fails after importing a few (most of the time only one) photos, and > then it would pop up a dialog saying "X photos failed to import due to > a file or hardware error". Retrying again would (sometimes) import > some more, and if I keep trying, eventually either shotwell crashes, > or I can import the entire collection. I am using shotwell 0.11.6, and > ubuntu 11.10, but it's happened with prior versions as well (but not > all the versions, I remember it didn't used to happen). > > I didn't capture a backtrace but the assertion for the crash is: > > ERROR:src/MediaViewTracker.c:510:media_accumulator_real_uninclude: > assertion failed: (self->photos> 0) > Aborted > > Running shotwell in terminal results in lots of: > > ?C9 : data corrupted at 1630556 > 0* hd : data corrupted at 1762984 > ?$xd : data corrupted at 1630487 > : data corrupted at 1642091 > > and the like. Setting SHOTWELL_LOG=1 produced the attached log file. > The problem happens regardless if I am importing directly from the > camera card, or from a local directory after copying the photos over. > I don't think the photos are corrupted, since if I keep trying all of > them eventually import fine. > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From adam at yorba.org Mon Dec 12 20:46:54 2011 From: adam at yorba.org (Adam Dingle) Date: Mon, 12 Dec 2011 12:46:54 -0800 Subject: [Shotwell] Image Dates In-Reply-To: <1323221762397-50113.post@talk.nabble.com> References: <1323221762397-50113.post@talk.nabble.com> Message-ID: <4EE6683E.8000607@yorba.org> David, On 12/06/2011 05:36 PM, davidvj wrote: > I have just re installed Shotwell and am having a problem with images being > 'misplaced' by date. > For instance a large number of images are sorted by Shotwell and displayed > under a July 2009 time-frame where all of the exif data indicates that the > material was shot in 2006, 2005, 2004 and earlier. > Exactly what date is Shotwell reading to locate the images? Shotwell looks for these EXIF tags in this order: Exif.Photo.DateTimeOriginal Exif.Photo.DateTimeDigitized Exif.Image.DateTime So it's surprising that Shotwell is placing these photos in July 2009. Could you print out all the EXIF data for one of your photos (e.g. 'exiv2 -pa myphoto.jpg')? What does it look like for these tags? > > I set the date import structure to simply give me Year and Month ... but > Shotwell insists on providing Year/Month/Day/Weekday ... and then often 2 or > more entries for the dame day. What is going on? Are you talking about the directory hierarchy where Shotwell places imported files, or the event hierarchy displayed in Shotwell's sidebar? These are two unrelated concepts. The date import structure you set in Shotwell's preferences affects only the directory hierachy - it will have no effect on anything you see in the sidebar. If you import photos taken on a single day into Shotwell on two different occasions, then it will create two distinct events for that day. I consider this a bug: http://redmine.yorba.org/issues/3565 adam From josep at cols.name Tue Dec 13 09:50:15 2011 From: josep at cols.name (josep Cols) Date: Tue, 13 Dec 2011 10:50:15 +0100 Subject: [Shotwell] Save metadata to photo file. Message-ID: <4EE71FD7.2080704@cols.name> Hello: I'm testing Shotwell 0.11.6. I've checked the 'save metadata to file' check box on preferences, but metadata (tags) are not saved to file. I did someting wrong? Can I force this save? How? Thanks From josep at cols.name Tue Dec 13 10:56:31 2011 From: josep at cols.name (josep Cols) Date: Tue, 13 Dec 2011 11:56:31 +0100 Subject: [Shotwell] (Solved) Save metadata to photo file. In-Reply-To: <4EE71FD7.2080704@cols.name> References: <4EE71FD7.2080704@cols.name> Message-ID: <4EE72F5F.9070401@cols.name> Sorry: The files was read-only. After changed to read-write, all works ok. Regards Al 13/12/11 10:50, En/na josep Cols ha escrit: > Hello: > > I'm testing Shotwell 0.11.6. > I've checked the 'save metadata to file' check box on preferences, but > metadata (tags) are not saved to file. > I did someting wrong? > Can I force this save? How? > > Thanks > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From gawith at gmx.de Tue Dec 13 12:27:31 2011 From: gawith at gmx.de (Steinhauer Juergen) Date: Tue, 13 Dec 2011 13:27:31 +0100 Subject: [Shotwell] Exporting original JPEG Message-ID: <20111213132731.10332utobf6lcibk@mail.gawith.de> Hi all, I'm importing RAW+JPEG pictures. How can I export the original JPEG from the camera? The 'unmodified' option exports the RAW picture and the 'current' option a size-reduced JPEG. Thanks in advance. Regards, J?rgen ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From adam at yorba.org Tue Dec 13 16:31:45 2011 From: adam at yorba.org (Adam Dingle) Date: Tue, 13 Dec 2011 08:31:45 -0800 Subject: [Shotwell] Exporting original JPEG In-Reply-To: <20111213132731.10332utobf6lcibk@mail.gawith.de> References: <20111213132731.10332utobf6lcibk@mail.gawith.de> Message-ID: <4EE77DF1.107@yorba.org> J?rgen, you're right: unfortunately there's no way to export the original JPEG from a RAW+JPEG pair today. I've created a new ticket for this at http://redmine.yorba.org/issues/4482 . The best you can do now is to right click the photo and choose Show in File Manager, then find the JPEG file yourself in the Nautilus window. The RAW+JPEG support in Shotwell 0.11 is unfortunately somewhat wobbly - we ran out of development time for that release and didn't test as thoroughly as we should have. And so there are a number of related bugs as you can see in our bug tracker. We're planning to improve the situation significantly for the 0.12 release (coming in February). adam On 12/13/2011 04:27 AM, Steinhauer Juergen wrote: > Hi all, > > I'm importing RAW+JPEG pictures. > How can I export the original JPEG from the camera? The 'unmodified' > option exports the RAW picture and the 'current' option a size-reduced > JPEG. > > Thanks in advance. > > Regards, > J?rgen > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From lucas at yorba.org Tue Dec 13 18:48:25 2011 From: lucas at yorba.org (Lucas Beeler) Date: Tue, 13 Dec 2011 10:48:25 -0800 Subject: [Shotwell] Save metadata to photo file. In-Reply-To: <4EE71FD7.2080704@cols.name> References: <4EE71FD7.2080704@cols.name> Message-ID: Hi Josep, If metadata writing is turned on, then metadata should be written to your photo files whenever you modify them. So this sounds like a bug. To help us debug this problem, could you do the following: (i) Turn logging on and run Shotwell. You can learn how to run Shotwell with diagnostic logging turned on in the "I found a bug in Shotwell. How can I report it?" section of the Shotwell FAQ here: http://redmine.yorba.org/projects/shotwell/wiki/ShotwellFAQ (ii) While running Shotwell with logging turned on, add tags or change the title of a photo -- this will cause Shotwell to attempt to write metadata back to the original photo file. (iii) Email the log file Shotwell generates to shotwell at yorba.org along with a brief description of the problem. You can probably just copy and paste what you've already written in this message. Cheers, Lucas On Tue, Dec 13, 2011 at 1:50 AM, josep Cols wrote: > Hello: > > I'm testing Shotwell 0.11.6. > I've checked the 'save metadata to file' check box on preferences, but > metadata (tags) are not saved to file. > I did someting wrong? > Can I force this save? How? > > Thanks > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From josep at cols.name Tue Dec 13 18:53:53 2011 From: josep at cols.name (Josep Cols) Date: Tue, 13 Dec 2011 19:53:53 +0100 Subject: [Shotwell] Save metadata to photo file. In-Reply-To: References: <4EE71FD7.2080704@cols.name> Message-ID: <4EE79F41.8010708@cols.name> Thanks, Lucas. This problem is solved ... and is my problem: the files was read-only.... After changing the files to read-write, shotwell woks properly. In fact, now I'm migrating from f-spot to shotwel... Thanks a lot Al 13/12/11 19:48, En/na Lucas Beeler ha escrit: > Hi Josep, > > If metadata writing is turned on, then metadata should be written to > your photo files whenever you modify them. So this sounds like a bug. > To help us debug this problem, could you do the following: > > (i) > Turn logging on and run Shotwell. You can learn how to run Shotwell > with diagnostic logging turned on in the "I found a bug in Shotwell. > How can I report it?" section of the Shotwell FAQ here: > http://redmine.yorba.org/projects/shotwell/wiki/ShotwellFAQ > > (ii) > While running Shotwell with logging turned on, add tags or change the > title of a photo -- this will cause Shotwell to attempt to write > metadata back to the original photo file. > > (iii) > Email the log file Shotwell generates to shotwell at yorba.org along with > a brief description of the problem. You can probably just copy and > paste what you've already written in this message. > > Cheers, > Lucas > > On Tue, Dec 13, 2011 at 1:50 AM, josep Cols wrote: >> Hello: >> >> I'm testing Shotwell 0.11.6. >> I've checked the 'save metadata to file' check box on preferences, but >> metadata (tags) are not saved to file. >> I did someting wrong? >> Can I force this save? How? >> >> Thanks >> _______________________________________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From josep at cols.name Wed Dec 14 19:42:53 2011 From: josep at cols.name (Josep Cols) Date: Wed, 14 Dec 2011 20:42:53 +0100 Subject: [Shotwell] crash importing f-spot database photos Message-ID: <4EE8FC3D.90407@cols.name> Hi: It's a new shotwell 0.11.6-1-natty1 install on a Ubuntu 11.04. I'm importing 25.000 photos from my f-spot database. The first try, about 5.100 photos was imported before shotwell crash. After crash, a pop-up window says something about 'no memory available' (sorry, the original message was in catalan...) The second try adds about 1.500 more photos My system is a 32 bits one with PAE kernel. 8 Gb RAM 16 Gb swap and only few used (100 Mb) Any idea on how to proceed? Thanks From clinton at yorba.org Wed Dec 14 20:13:10 2011 From: clinton at yorba.org (Clinton Rogers) Date: Wed, 14 Dec 2011 12:13:10 -0800 Subject: [Shotwell] crash importing f-spot database photos In-Reply-To: <4EE8FC3D.90407@cols.name> References: <4EE8FC3D.90407@cols.name> Message-ID: Hi Josep, We're sorry you're encountering import problems. Looking at what you wrote about your setup, it seems like you should have more than enough memory available for the import to succeed, so this is likely a Shotwell bug. (I'm assuming the message in question wasn't from the OOM killer, which, as far as I know, doesn't display a popup). Can you try the following: 1) Bring up two command shells, and in one of them, type "top" and press Enter. 1) In the other shell, type "gdb shotwell" ...and press Enter. 2) At the "(gdb)" prompt, type "run". 3) Attempt the F-Spot import again, and carefully observe the shell running 'top'. (Shotwell will most likely be using a considerable amount of memory at this point, but shouldn't be able to use it all.) 4) If Shotwell crashes again, note the memory usage in the 'top' shell, and type "backtrace" in the 'gdb' shell, and email the text that appears after this to myself and the list. Hopefully, assuming the machine really isn't out of memory, this will tell us what Shotwell was doing right before it crashed, and may help us fix the problem or provide a workaround. As for posting error messages in Catalan, please feel free to - the list is read around the world, so there may be other Catalan speakers present, and, at least in print, Catalan is similar enough to other Romance languages that we'll be able to figure it out. Cheers, -c On 12/14/11, Josep Cols wrote: > Hi: > > It's a new shotwell 0.11.6-1-natty1 install on a Ubuntu 11.04. > > I'm importing 25.000 photos from my f-spot database. > The first try, about 5.100 photos was imported before shotwell crash. > After crash, a pop-up window says something about 'no memory available' > (sorry, the original message was in catalan...) > The second try adds about 1.500 more photos > > My system is a 32 bits one with PAE kernel. > 8 Gb RAM > 16 Gb swap and only few used (100 Mb) > > Any idea on how to proceed? > > Thanks > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From lucas at yorba.org Wed Dec 14 20:43:05 2011 From: lucas at yorba.org (Lucas Beeler) Date: Wed, 14 Dec 2011 12:43:05 -0800 Subject: [Shotwell] crash importing f-spot database photos In-Reply-To: References: <4EE8FC3D.90407@cols.name> Message-ID: Hi Josep, Just to add to what Clinton said, this might be a problem we're aware of: the Shotwell F-Spot import code is not robust to data inconsistencies in the underlying F-Spot database (see our bug ticket for this issue here: http://redmine.yorba.org/issues/4487. You might want to read over that bug description and see if any of the markers of this problem are similar to what you're seeing. Lucas On Wed, Dec 14, 2011 at 12:13 PM, Clinton Rogers wrote: > Hi Josep, > > We're sorry you're encountering import problems. ?Looking at what you > wrote about your setup, it seems like you should have more than enough > memory available for the import to succeed, so this is likely a > Shotwell bug. ?(I'm assuming the message in question wasn't from the > OOM killer, which, as far as I know, doesn't display a popup). > > Can you try the following: > 1) Bring up two command shells, and in one of them, type > ? "top" > and press Enter. > 1) In the other shell, type > ? ?"gdb shotwell" > ...and press Enter. > 2) At the "(gdb)" prompt, type "run". > 3) Attempt the F-Spot import again, and carefully observe the shell > running 'top'. ?(Shotwell will most likely be using a considerable > amount of memory at this point, but shouldn't be able to use it all.) > 4) If Shotwell crashes again, note the memory usage in the 'top' > shell, and type "backtrace" in the 'gdb' shell, and email the text > that appears after this to myself and the list. > > Hopefully, assuming the machine really isn't out of memory, this will > tell us what Shotwell was doing right before it crashed, and may help > us fix the problem or provide a workaround. > > As for posting error messages in Catalan, please feel free to - the > list is read around the world, so there may be other Catalan speakers > present, and, at least in print, Catalan is similar enough to other > Romance languages that we'll be able to figure it out. > > Cheers, > -c > > On 12/14/11, Josep Cols wrote: >> Hi: >> >> It's a new shotwell 0.11.6-1-natty1 install on a Ubuntu 11.04. >> >> I'm importing 25.000 photos from my f-spot database. >> The first try, about 5.100 photos was imported before shotwell crash. >> After crash, a pop-up window says something about 'no memory available' >> (sorry, the original message was in catalan...) >> The second try adds about 1.500 more photos >> >> My system is a 32 bits one with PAE kernel. >> 8 Gb RAM >> 16 Gb swap and only few used (100 Mb) >> >> Any idea on how to proceed? >> >> Thanks >> _______________________________________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >> > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From josep at cols.name Thu Dec 15 21:30:41 2011 From: josep at cols.name (Josep Cols) Date: Thu, 15 Dec 2011 22:30:41 +0100 Subject: [Shotwell] crash importing f-spot database photos In-Reply-To: References: <4EE8FC3D.90407@cols.name> Message-ID: <4EEA6701.9080702@cols.name> Thanks a lot!!! I think my problem is... all of them... and not enougth memory. Let me explain. I've tried to import 5 times. The fists 3 of them, the virtual memory used was < 2.5 Gb, but shotwell imported the oldest photos... I know those oldest photos was a lot of differences between Databae tags and tags in photos and, also, many differences between IPTC and XMP information. So, the first 3 times I think that shotwell crased due to those differences. The last 2 imports, shotwell used about 3.1 Gb or Virtual Memory before crash. I think that 3 Gb is the limit for the virtual memory that can use a 32 bits program... So, I will retry the import until end... For the last import, I've have the crash traceback: ------------------begin traceback------------------ [Thread 0xaaaf5b70 (LWP 1520) exited] (process:1223): GLib-ERROR (recursed) **: /build/buildd/glib2.0-2.28.6/./glib/gmem.c:239: failed to allocate 64 bytes aborting... Program received signal SIGABRT, Aborted. 0xb7fe1424 in __kernel_vsyscall () (gdb) backtrace #0 0xb7fe1424 in __kernel_vsyscall () #1 0xb5b2ce71 in raise () from /lib/i386-linux-gnu/libc.so.6 #2 0xb5b3034e in abort () from /lib/i386-linux-gnu/libc.so.6 #3 0xb5e0bf27 in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0 #4 0xb5e0bf62 in g_log () from /lib/i386-linux-gnu/libglib-2.0.so.0 #5 0xb5e09c3c in g_realloc () from /lib/i386-linux-gnu/libglib-2.0.so.0 #6 0xb5e2664f in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 #7 0xb5e26dac in g_string_insert_len () from /lib/i386-linux-gnu/libglib-2.0.so.0 #8 0xb5e26f8c in g_string_append () from /lib/i386-linux-gnu/libglib-2.0.so.0 #9 0xb5e0b0f1 in g_log_default_handler () from /lib/i386-linux-gnu/libglib-2.0.so.0 #10 0xb5e0bb0f in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0 #11 0xb5e0bf62 in g_log () from /lib/i386-linux-gnu/libglib-2.0.so.0 #12 0xb5e09b3d in g_malloc () from /lib/i386-linux-gnu/libglib-2.0.so.0 #13 0xb5e23789 in g_strdup () from /lib/i386-linux-gnu/libglib-2.0.so.0 #14 0xb7fbd0d3 in ?? () from /usr/lib/libgee.so.2 #15 0xb7fbd02b in ?? () from /usr/lib/libgee.so.2 #16 0xb7fbd02b in ?? () from /usr/lib/libgee.so.2 #17 0xb7fbd02b in ?? () from /usr/lib/libgee.so.2 #18 0xb7fbd02b in ?? () from /usr/lib/libgee.so.2 ---Type to continue, or q to quit--- #19 0xb7fbd02b in ?? () from /usr/lib/libgee.so.2 #20 0xb7fbd02b in ?? () from /usr/lib/libgee.so.2 #21 0xb7fbd02b in ?? () from /usr/lib/libgee.so.2 #22 0xb7fbd02b in ?? () from /usr/lib/libgee.so.2 #23 0xb7fbd490 in ?? () from /usr/lib/libgee.so.2 #24 0xb7f8b538 in gee_abstract_collection_add () from /usr/lib/libgee.so.2 #25 0xb7f9537a in gee_collection_add () from /usr/lib/libgee.so.2 #26 0x0818e8be in hierarchical_tag_index_add_path (self=0xbe7d3650, tag=0xbfddc9d8 "p060", path=0xbfdfae08 "/Format Original/diaPositiva/p060/p_054") at src/tags/HierarchicalTagIndex.c:272 #27 0x0818ead6 in hierarchical_tag_index_from_paths (client_paths=0xeb70e18) at src/tags/HierarchicalTagIndex.c:217 #28 0x0818ebb4 in hierarchical_tag_index_get_global_index () at src/tags/HierarchicalTagIndex.c:244 #29 0x08241c0f in library_photo_source_collection_real_postprocess_imported_media (base=0x884e800, media_sources=0xbfbf4368) at src/Photo.c:15651 #30 0x08312d6b in media_source_collection_postprocess_imported_media ( self=0x884e800, media=0xbfbf4368) at src/MediaDataRepresentation.c:3631 #31 0x08313ae9 in media_source_collection_real_import_many (self=0x884e800, media=0xbfbf4368) at src/MediaDataRepresentation.c:3614 ---Type to continue, or q to quit--- #32 0x08312d4b in media_source_collection_import_many (self=0x884e800, media=0xbfbf4368) at src/MediaDataRepresentation.c:3620 #33 0x0824d36b in batch_import_flush_ready_sources (self=0xeb72d48) at src/BatchImport.c:4844 #34 0x0824d759 in batch_import_report_completed (self=0xeb72d48, where=0x83b66c4 "completed preparing files, all outstanding imports completed") at src/BatchImport.c:3827 #35 0x08255db0 in batch_import_on_import_files_completed (job=0x80ea8118, self=0xeb72d48) at src/BatchImport.c:4496 #36 _batch_import_on_import_files_completed_completion_callback ( job=0x80ea8118, self=0xeb72d48) at src/BatchImport.c:3989 #37 0x080b9d9a in background_job_on_notify_completion (self=0x80ea8118) at src/threads/BackgroundJob.c:730 #38 _background_job_on_notify_completion_gsource_func (self=0x80ea8118) at src/threads/BackgroundJob.c:681 #39 0xb5dfe311 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 #40 0xb5e02aa8 in g_main_context_dispatch () from /lib/i386-linux-gnu/libglib-2.0.so.0 #41 0xb5e03270 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 #42 0xb5e0392b in g_main_loop_run () from /lib/i386-linux-gnu/libglib-2.0.so.0 #43 0xb6484c39 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 ---Type to continue, or q to quit--- #44 0x08300616 in application_start (self=0x84ccf18) at src/Application.c:141 #45 0x081cde44 in library_exec (mounts=0x846a000, mounts_length1=0) at src/main.c:1124 #46 0x081cf3c5 in _vala_main (args=0xbffff444, args_length1=1) at src/main.c:1592 #47 0x081cf658 in main (argc=1, argv=0xbffff444) at src/main.c:1657 (gdb) ^CQuit (gdb) -----------------------------------------------end traceback------------------------- Thanks Al 14/12/11 21:43, En/na Lucas Beeler ha escrit: > Hi Josep, > > Just to add to what Clinton said, this might be a problem we're aware > of: the Shotwell F-Spot import code is not robust to data > inconsistencies in the underlying F-Spot database (see our bug ticket > for this issue here: http://redmine.yorba.org/issues/4487. You might > want to read over that bug description and see if any of the markers > of this problem are similar to what you're seeing. > > Lucas > > On Wed, Dec 14, 2011 at 12:13 PM, Clinton Rogers wrote: >> Hi Josep, >> >> We're sorry you're encountering import problems. Looking at what you >> wrote about your setup, it seems like you should have more than enough >> memory available for the import to succeed, so this is likely a >> Shotwell bug. (I'm assuming the message in question wasn't from the >> OOM killer, which, as far as I know, doesn't display a popup). >> >> Can you try the following: >> 1) Bring up two command shells, and in one of them, type >> "top" >> and press Enter. >> 1) In the other shell, type >> "gdb shotwell" >> ...and press Enter. >> 2) At the "(gdb)" prompt, type "run". >> 3) Attempt the F-Spot import again, and carefully observe the shell >> running 'top'. (Shotwell will most likely be using a considerable >> amount of memory at this point, but shouldn't be able to use it all.) >> 4) If Shotwell crashes again, note the memory usage in the 'top' >> shell, and type "backtrace" in the 'gdb' shell, and email the text >> that appears after this to myself and the list. >> >> Hopefully, assuming the machine really isn't out of memory, this will >> tell us what Shotwell was doing right before it crashed, and may help >> us fix the problem or provide a workaround. >> >> As for posting error messages in Catalan, please feel free to - the >> list is read around the world, so there may be other Catalan speakers >> present, and, at least in print, Catalan is similar enough to other >> Romance languages that we'll be able to figure it out. >> >> Cheers, >> -c >> >> On 12/14/11, Josep Cols wrote: >>> Hi: >>> >>> It's a new shotwell 0.11.6-1-natty1 install on a Ubuntu 11.04. >>> >>> I'm importing 25.000 photos from my f-spot database. >>> The first try, about 5.100 photos was imported before shotwell crash. >>> After crash, a pop-up window says something about 'no memory available' >>> (sorry, the original message was in catalan...) >>> The second try adds about 1.500 more photos >>> >>> My system is a 32 bits one with PAE kernel. >>> 8 Gb RAM >>> 16 Gb swap and only few used (100 Mb) >>> >>> Any idea on how to proceed? >>> >>> Thanks >>> _______________________________________________ >>> Shotwell mailing list >>> Shotwell at lists.yorba.org >>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >>> >> _______________________________________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From josep at cols.name Thu Dec 15 21:45:37 2011 From: josep at cols.name (Josep Cols) Date: Thu, 15 Dec 2011 22:45:37 +0100 Subject: [Shotwell] After importing from f-spot, a lot of tags 'repeat': as a flat one and in their correct hierarchy Message-ID: <4EEA6A81.1050600@cols.name> Hello: After importing a lot of photos from f-spot, some tags are repeated: as a flat one and in their corect hierarchy. Selecting photos for a tag from the 'flat version' and fom the 'hierarchical version' sometimes the selected photos are not the same. Can I do someting in order to restore the situation? I have about 10.000 tags and about 1.500 'repeated' Thanks From josep at cols.name Thu Dec 15 21:54:39 2011 From: josep at cols.name (Josep Cols) Date: Thu, 15 Dec 2011 22:54:39 +0100 Subject: [Shotwell] Improvement: save the thumbs in a directory tree Message-ID: <4EEA6C9F.8000505@cols.name> Hello: Shotwell saves the thumbs in a flat directory. I propouse create a directory tree for thumbs to improve scalability. For instance: For the firsts 16K photos, a flat directory can be used For the next photos, 1 new directory, in the main directory, can be created to acomodate another 16K thumbs Whit this schema, and the same actual name schema, it is not needed to save the full path for every thumb because it can be computed from te file name. Regards From adam at yorba.org Thu Dec 15 23:45:02 2011 From: adam at yorba.org (Adam Dingle) Date: Thu, 15 Dec 2011 15:45:02 -0800 Subject: [Shotwell] After importing from f-spot, a lot of tags 'repeat': as a flat one and in their correct hierarchy In-Reply-To: <4EEA6A81.1050600@cols.name> References: <4EEA6A81.1050600@cols.name> Message-ID: <4EEA867E.9000803@yorba.org> Josep, I believe we fixed this bug in Shotwell 0.11.2: http://redmine.yorba.org/issues/4081 What version of Shotwell are you running? adam On 12/15/2011 01:45 PM, Josep Cols wrote: > Hello: > After importing a lot of photos from f-spot, some tags are repeated: > as a flat one and in their corect hierarchy. > Selecting photos for a tag from the 'flat version' and fom the > 'hierarchical version' sometimes the selected photos are not the same. > Can I do someting in order to restore the situation? I have about > 10.000 tags and about 1.500 'repeated' > Thanks > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From adam at yorba.org Fri Dec 16 00:11:27 2011 From: adam at yorba.org (Adam Dingle) Date: Thu, 15 Dec 2011 16:11:27 -0800 Subject: [Shotwell] Improvement: save the thumbs in a directory tree In-Reply-To: <4EEA6C9F.8000505@cols.name> References: <4EEA6C9F.8000505@cols.name> Message-ID: <4EEA8CAF.1000706@yorba.org> Hi Josep, this is a reasonable idea - I've ticketed it at http://redmine.yorba.org/issues/4489 . You should know, however, that we're thinking about storing thumbnails in photo directories themselves at some point: http://redmine.yorba.org/issues/2250 With this approach, we'd create a .thumbnail directory in each photo directory and store thumbnails there. At that point there would be no need for a directory tree as you propose. Cheers - adam On 12/15/2011 01:54 PM, Josep Cols wrote: > Hello: > Shotwell saves the thumbs in a flat directory. > I propouse create a directory tree for thumbs to improve scalability. > > For instance: > For the firsts 16K photos, a flat directory can be used > For the next photos, 1 new directory, in the main directory, can be > created to acomodate another 16K thumbs > > Whit this schema, and the same actual name schema, it is not needed to > save the full path for every thumb because it can be computed from te > file name. > > Regards > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From camille.hamon at gmail.com Fri Dec 16 08:15:09 2011 From: camille.hamon at gmail.com (Camille Hamon) Date: Fri, 16 Dec 2011 09:15:09 +0100 Subject: [Shotwell] Use google to login on Flickr Message-ID: Hello, I tried the workaround suggested by twchambers but, unfortunately, it doesn't work for me (nothing happens when I right click, no menu appears). Camille On 12/03/2011 01:26 PM, Camille Hamon wrote: > Hello, > > Let me first thank you for your excellent software. It is a pleasure to use > it! Thanks! > > I've had a problem though: I would like to publish some pictures on Flickr > and my Flickr account is linked to my google account, but I cannot log in > using my google account in Shotwell. > I saw that this issue has been raised before there: > http://redmine.yorba.org/issues/3043 > > I was wondering if this problem is going to be fixed in future versions of > Shotwell, or if there was already some solution that I've missed. > I've just marked this bug for the upcoming 0.12 release - no promises, but we'll see what can do. In the meantime, maybe you can use the workaround suggested by twchambers on the ticket above: === If it makes any difference, I have found that it is possible to sign in using a google account. Instead of trying to left-click the google logo, right-click and use 'open link'. You can then sign in and use the features as intended. === adam From adam at yorba.org Fri Dec 16 17:40:28 2011 From: adam at yorba.org (Adam Dingle) Date: Fri, 16 Dec 2011 09:40:28 -0800 Subject: [Shotwell] crash importing f-spot database photos In-Reply-To: <4EEA6701.9080702@cols.name> References: <4EE8FC3D.90407@cols.name> <4EEA6701.9080702@cols.name> Message-ID: <4EEB828C.6070406@yorba.org> Josep, thanks for reporting this crash. As Lucas mentioned, we're already aware of a potential crash that can result from F-Spot database inconsistencies. But the other crash you described, where Shotwell is using an enormous amount of memory, is new. I've created a ticket for this here: http://redmine.yorba.org/issues/4498 We should investigate this for the upcoming 0.12 release. adam On 12/15/2011 01:30 PM, Josep Cols wrote: > Thanks a lot!!! > > I think my problem is... all of them... and not enougth memory. > > Let me explain. > I've tried to import 5 times. > > The fists 3 of them, the virtual memory used was < 2.5 Gb, but > shotwell imported the oldest photos... > I know those oldest photos was a lot of differences between Databae > tags and tags in photos and, also, many differences between IPTC and > XMP information. So, the first 3 times I think that shotwell crased > due to those differences. > > The last 2 imports, shotwell used about 3.1 Gb or Virtual Memory > before crash. I think that 3 Gb is the limit for the virtual memory > that can use a 32 bits program... > > So, I will retry the import until end... > > For the last import, I've have the crash traceback: > > ------------------begin traceback------------------ > [Thread 0xaaaf5b70 (LWP 1520) exited] > > (process:1223): GLib-ERROR (recursed) **: > /build/buildd/glib2.0-2.28.6/./glib/gmem.c:239: failed to allocate 64 > bytes > aborting... > > Program received signal SIGABRT, Aborted. > 0xb7fe1424 in __kernel_vsyscall () > (gdb) backtrace > #0 0xb7fe1424 in __kernel_vsyscall () > #1 0xb5b2ce71 in raise () from /lib/i386-linux-gnu/libc.so.6 > #2 0xb5b3034e in abort () from /lib/i386-linux-gnu/libc.so.6 > #3 0xb5e0bf27 in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0 > #4 0xb5e0bf62 in g_log () from /lib/i386-linux-gnu/libglib-2.0.so.0 > #5 0xb5e09c3c in g_realloc () from /lib/i386-linux-gnu/libglib-2.0.so.0 > #6 0xb5e2664f in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 > #7 0xb5e26dac in g_string_insert_len () > from /lib/i386-linux-gnu/libglib-2.0.so.0 > #8 0xb5e26f8c in g_string_append () from > /lib/i386-linux-gnu/libglib-2.0.so.0 > #9 0xb5e0b0f1 in g_log_default_handler () > from /lib/i386-linux-gnu/libglib-2.0.so.0 > #10 0xb5e0bb0f in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0 > #11 0xb5e0bf62 in g_log () from /lib/i386-linux-gnu/libglib-2.0.so.0 > #12 0xb5e09b3d in g_malloc () from /lib/i386-linux-gnu/libglib-2.0.so.0 > #13 0xb5e23789 in g_strdup () from /lib/i386-linux-gnu/libglib-2.0.so.0 > #14 0xb7fbd0d3 in ?? () from /usr/lib/libgee.so.2 > #15 0xb7fbd02b in ?? () from /usr/lib/libgee.so.2 > #16 0xb7fbd02b in ?? () from /usr/lib/libgee.so.2 > #17 0xb7fbd02b in ?? () from /usr/lib/libgee.so.2 > #18 0xb7fbd02b in ?? () from /usr/lib/libgee.so.2 > ---Type to continue, or q to quit--- > #19 0xb7fbd02b in ?? () from /usr/lib/libgee.so.2 > #20 0xb7fbd02b in ?? () from /usr/lib/libgee.so.2 > #21 0xb7fbd02b in ?? () from /usr/lib/libgee.so.2 > #22 0xb7fbd02b in ?? () from /usr/lib/libgee.so.2 > #23 0xb7fbd490 in ?? () from /usr/lib/libgee.so.2 > #24 0xb7f8b538 in gee_abstract_collection_add () from > /usr/lib/libgee.so.2 > #25 0xb7f9537a in gee_collection_add () from /usr/lib/libgee.so.2 > #26 0x0818e8be in hierarchical_tag_index_add_path (self=0xbe7d3650, > tag=0xbfddc9d8 "p060", > path=0xbfdfae08 "/Format Original/diaPositiva/p060/p_054") > at src/tags/HierarchicalTagIndex.c:272 > #27 0x0818ead6 in hierarchical_tag_index_from_paths > (client_paths=0xeb70e18) > at src/tags/HierarchicalTagIndex.c:217 > #28 0x0818ebb4 in hierarchical_tag_index_get_global_index () > at src/tags/HierarchicalTagIndex.c:244 > #29 0x08241c0f in > library_photo_source_collection_real_postprocess_imported_media > (base=0x884e800, media_sources=0xbfbf4368) at src/Photo.c:15651 > #30 0x08312d6b in media_source_collection_postprocess_imported_media ( > self=0x884e800, media=0xbfbf4368) at > src/MediaDataRepresentation.c:3631 > #31 0x08313ae9 in media_source_collection_real_import_many > (self=0x884e800, > media=0xbfbf4368) at src/MediaDataRepresentation.c:3614 > ---Type to continue, or q to quit--- > #32 0x08312d4b in media_source_collection_import_many (self=0x884e800, > media=0xbfbf4368) at src/MediaDataRepresentation.c:3620 > #33 0x0824d36b in batch_import_flush_ready_sources (self=0xeb72d48) > at src/BatchImport.c:4844 > #34 0x0824d759 in batch_import_report_completed (self=0xeb72d48, > where=0x83b66c4 "completed preparing files, all outstanding > imports completed") at src/BatchImport.c:3827 > #35 0x08255db0 in batch_import_on_import_files_completed (job=0x80ea8118, > self=0xeb72d48) at src/BatchImport.c:4496 > #36 _batch_import_on_import_files_completed_completion_callback ( > job=0x80ea8118, self=0xeb72d48) at src/BatchImport.c:3989 > #37 0x080b9d9a in background_job_on_notify_completion (self=0x80ea8118) > at src/threads/BackgroundJob.c:730 > #38 _background_job_on_notify_completion_gsource_func (self=0x80ea8118) > at src/threads/BackgroundJob.c:681 > #39 0xb5dfe311 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 > #40 0xb5e02aa8 in g_main_context_dispatch () > from /lib/i386-linux-gnu/libglib-2.0.so.0 > #41 0xb5e03270 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 > #42 0xb5e0392b in g_main_loop_run () from > /lib/i386-linux-gnu/libglib-2.0.so.0 > #43 0xb6484c39 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 > ---Type to continue, or q to quit--- > #44 0x08300616 in application_start (self=0x84ccf18) at > src/Application.c:141 > #45 0x081cde44 in library_exec (mounts=0x846a000, mounts_length1=0) > at src/main.c:1124 > #46 0x081cf3c5 in _vala_main (args=0xbffff444, args_length1=1) > at src/main.c:1592 > #47 0x081cf658 in main (argc=1, argv=0xbffff444) at src/main.c:1657 > (gdb) ^CQuit > (gdb) > -----------------------------------------------end > traceback------------------------- > > Thanks > > Al 14/12/11 21:43, En/na Lucas Beeler ha escrit: >> Hi Josep, >> >> Just to add to what Clinton said, this might be a problem we're aware >> of: the Shotwell F-Spot import code is not robust to data >> inconsistencies in the underlying F-Spot database (see our bug ticket >> for this issue here: http://redmine.yorba.org/issues/4487. You might >> want to read over that bug description and see if any of the markers >> of this problem are similar to what you're seeing. >> >> Lucas >> >> On Wed, Dec 14, 2011 at 12:13 PM, Clinton Rogers >> wrote: >>> Hi Josep, >>> >>> We're sorry you're encountering import problems. Looking at what you >>> wrote about your setup, it seems like you should have more than enough >>> memory available for the import to succeed, so this is likely a >>> Shotwell bug. (I'm assuming the message in question wasn't from the >>> OOM killer, which, as far as I know, doesn't display a popup). >>> >>> Can you try the following: >>> 1) Bring up two command shells, and in one of them, type >>> "top" >>> and press Enter. >>> 1) In the other shell, type >>> "gdb shotwell" >>> ...and press Enter. >>> 2) At the "(gdb)" prompt, type "run". >>> 3) Attempt the F-Spot import again, and carefully observe the shell >>> running 'top'. (Shotwell will most likely be using a considerable >>> amount of memory at this point, but shouldn't be able to use it all.) >>> 4) If Shotwell crashes again, note the memory usage in the 'top' >>> shell, and type "backtrace" in the 'gdb' shell, and email the text >>> that appears after this to myself and the list. >>> >>> Hopefully, assuming the machine really isn't out of memory, this will >>> tell us what Shotwell was doing right before it crashed, and may help >>> us fix the problem or provide a workaround. >>> >>> As for posting error messages in Catalan, please feel free to - the >>> list is read around the world, so there may be other Catalan speakers >>> present, and, at least in print, Catalan is similar enough to other >>> Romance languages that we'll be able to figure it out. >>> >>> Cheers, >>> -c >>> >>> On 12/14/11, Josep Cols wrote: >>>> Hi: >>>> >>>> It's a new shotwell 0.11.6-1-natty1 install on a Ubuntu 11.04. >>>> >>>> I'm importing 25.000 photos from my f-spot database. >>>> The first try, about 5.100 photos was imported before shotwell crash. >>>> After crash, a pop-up window says something about 'no memory >>>> available' >>>> (sorry, the original message was in catalan...) >>>> The second try adds about 1.500 more photos >>>> >>>> My system is a 32 bits one with PAE kernel. >>>> 8 Gb RAM >>>> 16 Gb swap and only few used (100 Mb) >>>> >>>> Any idea on how to proceed? >>>> >>>> Thanks >>>> _______________________________________________ >>>> Shotwell mailing list >>>> Shotwell at lists.yorba.org >>>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >>>> >>> _______________________________________________ >>> Shotwell mailing list >>> Shotwell at lists.yorba.org >>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From josep at cols.name Fri Dec 16 19:39:48 2011 From: josep at cols.name (Josep Cols) Date: Fri, 16 Dec 2011 20:39:48 +0100 Subject: [Shotwell] crash importing f-spot database photos In-Reply-To: <4EEB828C.6070406@yorba.org> References: <4EE8FC3D.90407@cols.name> <4EEA6701.9080702@cols.name> <4EEB828C.6070406@yorba.org> Message-ID: <4EEB9E84.6010702@cols.name> Thanks, Adam. For your information: The lasts 2 imports (when 3.1 Gb of virtual memory is used) imported only 1.200 photos every import. I think the quatity of photos imported and/or the mount the memory used is due to the tags. I've about 10.000 tags at the last level and about 13.000 tags in total on the database. The low level tags has 3-5 levels. Every photo as a minimum of 6 tags and an average of 8-10 tags (and a maximum of 20 tags). Also, the photos are jpg from 10 OR 15 Mpixels camera (between 4 and 8 Mbytes each). If you need more information, I can run tests for you and/or install specific software for test pourposes, etc. Regards Al 16/12/11 18:40, En/na Adam Dingle ha escrit: > Josep, > > thanks for reporting this crash. As Lucas mentioned, we're already > aware of a potential crash that can result from F-Spot database > inconsistencies. But the other crash you described, where Shotwell is > using an enormous amount of memory, is new. I've created a ticket for > this here: > > http://redmine.yorba.org/issues/4498 > > We should investigate this for the upcoming 0.12 release. > > adam > > On 12/15/2011 01:30 PM, Josep Cols wrote: >> Thanks a lot!!! >> >> I think my problem is... all of them... and not enougth memory. >> >> Let me explain. >> I've tried to import 5 times. >> >> The fists 3 of them, the virtual memory used was < 2.5 Gb, but >> shotwell imported the oldest photos... >> I know those oldest photos was a lot of differences between Databae >> tags and tags in photos and, also, many differences between IPTC and >> XMP information. So, the first 3 times I think that shotwell crased >> due to those differences. >> >> The last 2 imports, shotwell used about 3.1 Gb or Virtual Memory >> before crash. I think that 3 Gb is the limit for the virtual memory >> that can use a 32 bits program... >> >> So, I will retry the import until end... >> >> For the last import, I've have the crash traceback: >> >> ------------------begin traceback------------------ >> [Thread 0xaaaf5b70 (LWP 1520) exited] >> >> (process:1223): GLib-ERROR (recursed) **: >> /build/buildd/glib2.0-2.28.6/./glib/gmem.c:239: failed to allocate 64 >> bytes >> aborting... >> >> Program received signal SIGABRT, Aborted. >> 0xb7fe1424 in __kernel_vsyscall () >> (gdb) backtrace >> #0 0xb7fe1424 in __kernel_vsyscall () >> #1 0xb5b2ce71 in raise () from /lib/i386-linux-gnu/libc.so.6 >> #2 0xb5b3034e in abort () from /lib/i386-linux-gnu/libc.so.6 >> #3 0xb5e0bf27 in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0 >> #4 0xb5e0bf62 in g_log () from /lib/i386-linux-gnu/libglib-2.0.so.0 >> #5 0xb5e09c3c in g_realloc () from /lib/i386-linux-gnu/libglib-2.0.so.0 >> #6 0xb5e2664f in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 >> #7 0xb5e26dac in g_string_insert_len () >> from /lib/i386-linux-gnu/libglib-2.0.so.0 >> #8 0xb5e26f8c in g_string_append () from >> /lib/i386-linux-gnu/libglib-2.0.so.0 >> #9 0xb5e0b0f1 in g_log_default_handler () >> from /lib/i386-linux-gnu/libglib-2.0.so.0 >> #10 0xb5e0bb0f in g_logv () from /lib/i386-linux-gnu/libglib-2.0.so.0 >> #11 0xb5e0bf62 in g_log () from /lib/i386-linux-gnu/libglib-2.0.so.0 >> #12 0xb5e09b3d in g_malloc () from /lib/i386-linux-gnu/libglib-2.0.so.0 >> #13 0xb5e23789 in g_strdup () from /lib/i386-linux-gnu/libglib-2.0.so.0 >> #14 0xb7fbd0d3 in ?? () from /usr/lib/libgee.so.2 >> #15 0xb7fbd02b in ?? () from /usr/lib/libgee.so.2 >> #16 0xb7fbd02b in ?? () from /usr/lib/libgee.so.2 >> #17 0xb7fbd02b in ?? () from /usr/lib/libgee.so.2 >> #18 0xb7fbd02b in ?? () from /usr/lib/libgee.so.2 >> ---Type to continue, or q to quit--- >> #19 0xb7fbd02b in ?? () from /usr/lib/libgee.so.2 >> #20 0xb7fbd02b in ?? () from /usr/lib/libgee.so.2 >> #21 0xb7fbd02b in ?? () from /usr/lib/libgee.so.2 >> #22 0xb7fbd02b in ?? () from /usr/lib/libgee.so.2 >> #23 0xb7fbd490 in ?? () from /usr/lib/libgee.so.2 >> #24 0xb7f8b538 in gee_abstract_collection_add () from >> /usr/lib/libgee.so.2 >> #25 0xb7f9537a in gee_collection_add () from /usr/lib/libgee.so.2 >> #26 0x0818e8be in hierarchical_tag_index_add_path (self=0xbe7d3650, >> tag=0xbfddc9d8 "p060", >> path=0xbfdfae08 "/Format Original/diaPositiva/p060/p_054") >> at src/tags/HierarchicalTagIndex.c:272 >> #27 0x0818ead6 in hierarchical_tag_index_from_paths >> (client_paths=0xeb70e18) >> at src/tags/HierarchicalTagIndex.c:217 >> #28 0x0818ebb4 in hierarchical_tag_index_get_global_index () >> at src/tags/HierarchicalTagIndex.c:244 >> #29 0x08241c0f in >> library_photo_source_collection_real_postprocess_imported_media >> (base=0x884e800, media_sources=0xbfbf4368) at src/Photo.c:15651 >> #30 0x08312d6b in media_source_collection_postprocess_imported_media ( >> self=0x884e800, media=0xbfbf4368) at >> src/MediaDataRepresentation.c:3631 >> #31 0x08313ae9 in media_source_collection_real_import_many >> (self=0x884e800, >> media=0xbfbf4368) at src/MediaDataRepresentation.c:3614 >> ---Type to continue, or q to quit--- >> #32 0x08312d4b in media_source_collection_import_many (self=0x884e800, >> media=0xbfbf4368) at src/MediaDataRepresentation.c:3620 >> #33 0x0824d36b in batch_import_flush_ready_sources (self=0xeb72d48) >> at src/BatchImport.c:4844 >> #34 0x0824d759 in batch_import_report_completed (self=0xeb72d48, >> where=0x83b66c4 "completed preparing files, all outstanding >> imports completed") at src/BatchImport.c:3827 >> #35 0x08255db0 in batch_import_on_import_files_completed >> (job=0x80ea8118, >> self=0xeb72d48) at src/BatchImport.c:4496 >> #36 _batch_import_on_import_files_completed_completion_callback ( >> job=0x80ea8118, self=0xeb72d48) at src/BatchImport.c:3989 >> #37 0x080b9d9a in background_job_on_notify_completion (self=0x80ea8118) >> at src/threads/BackgroundJob.c:730 >> #38 _background_job_on_notify_completion_gsource_func (self=0x80ea8118) >> at src/threads/BackgroundJob.c:681 >> #39 0xb5dfe311 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 >> #40 0xb5e02aa8 in g_main_context_dispatch () >> from /lib/i386-linux-gnu/libglib-2.0.so.0 >> #41 0xb5e03270 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 >> #42 0xb5e0392b in g_main_loop_run () from >> /lib/i386-linux-gnu/libglib-2.0.so.0 >> #43 0xb6484c39 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 >> ---Type to continue, or q to quit--- >> #44 0x08300616 in application_start (self=0x84ccf18) at >> src/Application.c:141 >> #45 0x081cde44 in library_exec (mounts=0x846a000, mounts_length1=0) >> at src/main.c:1124 >> #46 0x081cf3c5 in _vala_main (args=0xbffff444, args_length1=1) >> at src/main.c:1592 >> #47 0x081cf658 in main (argc=1, argv=0xbffff444) at src/main.c:1657 >> (gdb) ^CQuit >> (gdb) >> -----------------------------------------------end >> traceback------------------------- >> >> Thanks >> >> Al 14/12/11 21:43, En/na Lucas Beeler ha escrit: >>> Hi Josep, >>> >>> Just to add to what Clinton said, this might be a problem we're aware >>> of: the Shotwell F-Spot import code is not robust to data >>> inconsistencies in the underlying F-Spot database (see our bug ticket >>> for this issue here: http://redmine.yorba.org/issues/4487. You might >>> want to read over that bug description and see if any of the markers >>> of this problem are similar to what you're seeing. >>> >>> Lucas >>> >>> On Wed, Dec 14, 2011 at 12:13 PM, Clinton Rogers >>> wrote: >>>> Hi Josep, >>>> >>>> We're sorry you're encountering import problems. Looking at what you >>>> wrote about your setup, it seems like you should have more than enough >>>> memory available for the import to succeed, so this is likely a >>>> Shotwell bug. (I'm assuming the message in question wasn't from the >>>> OOM killer, which, as far as I know, doesn't display a popup). >>>> >>>> Can you try the following: >>>> 1) Bring up two command shells, and in one of them, type >>>> "top" >>>> and press Enter. >>>> 1) In the other shell, type >>>> "gdb shotwell" >>>> ...and press Enter. >>>> 2) At the "(gdb)" prompt, type "run". >>>> 3) Attempt the F-Spot import again, and carefully observe the shell >>>> running 'top'. (Shotwell will most likely be using a considerable >>>> amount of memory at this point, but shouldn't be able to use it all.) >>>> 4) If Shotwell crashes again, note the memory usage in the 'top' >>>> shell, and type "backtrace" in the 'gdb' shell, and email the text >>>> that appears after this to myself and the list. >>>> >>>> Hopefully, assuming the machine really isn't out of memory, this will >>>> tell us what Shotwell was doing right before it crashed, and may help >>>> us fix the problem or provide a workaround. >>>> >>>> As for posting error messages in Catalan, please feel free to - the >>>> list is read around the world, so there may be other Catalan speakers >>>> present, and, at least in print, Catalan is similar enough to other >>>> Romance languages that we'll be able to figure it out. >>>> >>>> Cheers, >>>> -c >>>> >>>> On 12/14/11, Josep Cols wrote: >>>>> Hi: >>>>> >>>>> It's a new shotwell 0.11.6-1-natty1 install on a Ubuntu 11.04. >>>>> >>>>> I'm importing 25.000 photos from my f-spot database. >>>>> The first try, about 5.100 photos was imported before shotwell crash. >>>>> After crash, a pop-up window says something about 'no memory >>>>> available' >>>>> (sorry, the original message was in catalan...) >>>>> The second try adds about 1.500 more photos >>>>> >>>>> My system is a 32 bits one with PAE kernel. >>>>> 8 Gb RAM >>>>> 16 Gb swap and only few used (100 Mb) >>>>> >>>>> Any idea on how to proceed? >>>>> >>>>> Thanks >>>>> _______________________________________________ >>>>> Shotwell mailing list >>>>> Shotwell at lists.yorba.org >>>>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >>>>> >>>> _______________________________________________ >>>> Shotwell mailing list >>>> Shotwell at lists.yorba.org >>>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >> _______________________________________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From adam at yorba.org Fri Dec 16 19:45:26 2011 From: adam at yorba.org (Adam Dingle) Date: Fri, 16 Dec 2011 11:45:26 -0800 Subject: [Shotwell] crash importing f-spot database photos In-Reply-To: <4EEB9E84.6010702@cols.name> References: <4EE8FC3D.90407@cols.name> <4EEA6701.9080702@cols.name> <4EEB828C.6070406@yorba.org> <4EEB9E84.6010702@cols.name> Message-ID: <4EEB9FD6.6080201@yorba.org> Josep, thanks for the additional information - I've appended it to the ticket for this bug (http://redmine.yorba.org/issues/4498). The best way to continue discussion about this is by adding comments to that ticket. That way, people who are interested in this issue can easily follow the discussion. Thanks! adam On 12/16/2011 11:39 AM, Josep Cols wrote: > Thanks, Adam. > > For your information: > > The lasts 2 imports (when 3.1 Gb of virtual memory is used) imported > only 1.200 photos every import. > I think the quatity of photos imported and/or the mount the memory > used is due to the tags. > > I've about 10.000 tags at the last level and about 13.000 tags in > total on the database. The low level tags has 3-5 levels. > Every photo as a minimum of 6 tags and an average of 8-10 tags (and a > maximum of 20 tags). > > Also, the photos are jpg from 10 OR 15 Mpixels camera (between 4 and 8 > Mbytes each). > > If you need more information, I can run tests for you and/or install > specific software for test pourposes, etc. > > Regards > > Al 16/12/11 18:40, En/na Adam Dingle ha escrit: >> Josep, >> >> thanks for reporting this crash. As Lucas mentioned, we're already >> aware of a potential crash that can result from F-Spot database >> inconsistencies. But the other crash you described, where Shotwell >> is using an enormous amount of memory, is new. I've created a ticket >> for this here: >> >> http://redmine.yorba.org/issues/4498 >> >> We should investigate this for the upcoming 0.12 release. >> >> adam From josep at cols.name Fri Dec 16 19:49:43 2011 From: josep at cols.name (Josep Cols) Date: Fri, 16 Dec 2011 20:49:43 +0100 Subject: [Shotwell] After importing from f-spot, a lot of tags 'repeat': as a flat one and in their correct hierarchy In-Reply-To: <4EEA867E.9000803@yorba.org> References: <4EEA6A81.1050600@cols.name> <4EEA867E.9000803@yorba.org> Message-ID: <4EEBA0D7.3030907@cols.name> Hello Adam: My shotwell version is the version 0.11.6-1-natty1 that installs on ubuntu 11.04 (after adding the yorba repository |ppa:yorba/ppa |) Perhaps the poblem is due to the fact I've informed both the IPTC and the XMP metadatas and, sometimes, with different information!! Of course, if you need more information, let me say and I will try to send. Also if you whant an example photo (.jpg with 4-8Mbytes in size) Regards Al 16/12/11 00:45, En/na Adam Dingle ha escrit: > Josep, > > I believe we fixed this bug in Shotwell 0.11.2: > > http://redmine.yorba.org/issues/4081 > > What version of Shotwell are you running? > > adam > > On 12/15/2011 01:45 PM, Josep Cols wrote: >> Hello: >> After importing a lot of photos from f-spot, some tags are repeated: >> as a flat one and in their corect hierarchy. >> Selecting photos for a tag from the 'flat version' and fom the >> 'hierarchical version' sometimes the selected photos are not the same. >> Can I do someting in order to restore the situation? I have about >> 10.000 tags and about 1.500 'repeated' >> Thanks >> _______________________________________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From adam at yorba.org Fri Dec 16 21:59:20 2011 From: adam at yorba.org (Adam Dingle) Date: Fri, 16 Dec 2011 13:59:20 -0800 Subject: [Shotwell] After importing from f-spot, a lot of tags 'repeat': as a flat one and in their correct hierarchy In-Reply-To: <4EEBA0D7.3030907@cols.name> References: <4EEA6A81.1050600@cols.name> <4EEA867E.9000803@yorba.org> <4EEBA0D7.3030907@cols.name> Message-ID: <4EEBBF38.70100@yorba.org> Josep, what would really help us is a reproducible case that demonstrates this problem with a small library. For example, start F-Spot with a new, empty library, and import your JPEG photo. Now start Shotwell with an empty library for testing (e.g. run 'shotwell -d foo' on the command line), and run the Import from F-Spot feature. Do you end up with a repeated tag? If so, we'd love to have a bug report from you, and we should be able to solve this. Unfortunately, when the error occurs only with a large library that we don't have here at Yorba, it's much harder for us to debug a problem like this (though we can still sometimes try). adam On 12/16/2011 11:49 AM, Josep Cols wrote: > Hello Adam: > > My shotwell version is the version 0.11.6-1-natty1 that installs on > ubuntu 11.04 (after adding the yorba repository |ppa:yorba/ppa |) > > Perhaps the poblem is due to the fact I've informed both the IPTC and > the XMP metadatas and, sometimes, with different information!! > > Of course, if you need more information, let me say and I will try to > send. Also if you whant an example photo (.jpg with 4-8Mbytes in size) > > Regards > > Al 16/12/11 00:45, En/na Adam Dingle ha escrit: >> Josep, >> >> I believe we fixed this bug in Shotwell 0.11.2: >> >> http://redmine.yorba.org/issues/4081 >> >> What version of Shotwell are you running? >> >> adam >> >> On 12/15/2011 01:45 PM, Josep Cols wrote: >>> Hello: >>> After importing a lot of photos from f-spot, some tags are repeated: >>> as a flat one and in their corect hierarchy. >>> Selecting photos for a tag from the 'flat version' and fom the >>> 'hierarchical version' sometimes the selected photos are not the same. >>> Can I do someting in order to restore the situation? I have about >>> 10.000 tags and about 1.500 'repeated' >>> Thanks >>> _______________________________________________ >>> Shotwell mailing list >>> Shotwell at lists.yorba.org >>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >> >> _______________________________________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From josep at cols.name Sat Dec 17 01:06:24 2011 From: josep at cols.name (Josep Cols) Date: Sat, 17 Dec 2011 02:06:24 +0100 Subject: [Shotwell] After importing from f-spot, a lot of tags 'repeat': as a flat one and in their correct hierarchy In-Reply-To: <4EEBBF38.70100@yorba.org> References: <4EEA6A81.1050600@cols.name> <4EEA867E.9000803@yorba.org> <4EEBA0D7.3030907@cols.name> <4EEBBF38.70100@yorba.org> Message-ID: <4EEBEB10.6050302@cols.name> Adam: I will try to reproduce on a limited and reproducible testcase. Let me 2-3 days to prepare it. Regards Al 16/12/11 22:59, En/na Adam Dingle ha escrit: > Josep, > > what would really help us is a reproducible case that demonstrates > this problem with a small library. For example, start F-Spot with a > new, empty library, and import your JPEG photo. Now start Shotwell > with an empty library for testing (e.g. run 'shotwell -d foo' on the > command line), and run the Import from F-Spot feature. Do you end up > with a repeated tag? If so, we'd love to have a bug report from you, > and we should be able to solve this. Unfortunately, when the error > occurs only with a large library that we don't have here at Yorba, > it's much harder for us to debug a problem like this (though we can > still sometimes try). > > adam > > On 12/16/2011 11:49 AM, Josep Cols wrote: >> Hello Adam: >> >> My shotwell version is the version 0.11.6-1-natty1 that installs on >> ubuntu 11.04 (after adding the yorba repository |ppa:yorba/ppa |) >> >> Perhaps the poblem is due to the fact I've informed both the IPTC and >> the XMP metadatas and, sometimes, with different information!! >> >> Of course, if you need more information, let me say and I will try to >> send. Also if you whant an example photo (.jpg with 4-8Mbytes in size) >> >> Regards >> >> Al 16/12/11 00:45, En/na Adam Dingle ha escrit: >>> Josep, >>> >>> I believe we fixed this bug in Shotwell 0.11.2: >>> >>> http://redmine.yorba.org/issues/4081 >>> >>> What version of Shotwell are you running? >>> >>> adam >>> >>> On 12/15/2011 01:45 PM, Josep Cols wrote: >>>> Hello: >>>> After importing a lot of photos from f-spot, some tags are >>>> repeated: as a flat one and in their corect hierarchy. >>>> Selecting photos for a tag from the 'flat version' and fom the >>>> 'hierarchical version' sometimes the selected photos are not the same. >>>> Can I do someting in order to restore the situation? I have about >>>> 10.000 tags and about 1.500 'repeated' >>>> Thanks >>>> _______________________________________________ >>>> Shotwell mailing list >>>> Shotwell at lists.yorba.org >>>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >>> >>> _______________________________________________ >>> Shotwell mailing list >>> Shotwell at lists.yorba.org >>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From j.hoffmann at fh-aachen.de Sat Dec 17 17:52:34 2011 From: j.hoffmann at fh-aachen.de (Jobst Hoffmann) Date: Sat, 17 Dec 2011 18:52:34 +0100 Subject: [Shotwell] LIBRAW_BAD_CROP Message-ID: Hello, I've just updated my shotwell files, but I can't compile the trunk: the error message is ... make[1]: Leaving directory `/opt/LinuxSources/tar/shotwell/shotwell/plugins' cc -c `pkg-config --cflags atk gdk-3.0 gdk-x11-3.0 gee-1.0 gexiv2 gio-unix-2.0 glib-2.0 gmodule-2.0 gstreamer-0.10 gstreamer-base-0.10 gstreamer-pbutils-0.10 gtk+-3.0 gudev-1.0 libexif libgphoto2 libsoup-2.4 libxml-2.0 sqlite3 unique-3.0 webkitgtk-3.0 gthread-2.0` -I./vapi -D_PREFIX='"/usr/local"' -D_VERSION='"0.11.90+trunk"' -DGETTEXT_PACKAGE='"shotwell"' -D_LANG_SUPPORT_DIR='"/usr/local/share/locale"' -D_LIB='"lib"' `./libraw-config --cflags` -O2 -g -pipe -fPIC -DG_UDEV_API_IS_SUBJECT_TO_CHANGE -o src/photos/GRaw.o src/photos/GRaw.c /opt/LinuxSources/tar/shotwell/shotwell/src/photos/GRaw.vala: In function 'graw_throw_exception': /opt/LinuxSources/tar/shotwell/shotwell/src/photos/GRaw.vala:278:8: error: 'LIBRAW_BAD_CROP' undeclared (first use in this function) /opt/LinuxSources/tar/shotwell/shotwell/src/photos/GRaw.vala:278:8: note: each undeclared identifier is reported only once for each function it appears in make: *** [src/photos/GRaw.o] Error 1 I've looked at the code, but I can't see any reason, why this happens. Can you give me a hint? Kind regards J. Hoffmann From adam at yorba.org Sat Dec 17 18:55:08 2011 From: adam at yorba.org (Adam Dingle) Date: Sat, 17 Dec 2011 10:55:08 -0800 Subject: [Shotwell] LIBRAW_BAD_CROP In-Reply-To: References: Message-ID: Jobst, what version of Shotwell are you trying to build? git master? The sources from the 0.11.6 tarball? Some other version? What operating system and version are you running? Do you know which version of libraw is present on your system? adam On Sat, Dec 17, 2011 at 9:52 AM, Jobst Hoffmann wrote: > > Hello, > > I've just updated my shotwell files, but I can't compile the trunk: > > the error message is > > ... > make[1]: Leaving directory > `/opt/LinuxSources/tar/shotwell/shotwell/plugins' > cc -c `pkg-config --cflags atk gdk-3.0 gdk-x11-3.0 gee-1.0 gexiv2 > gio-unix-2.0 glib-2.0 gmodule-2.0 gstreamer-0.10 gstreamer-base-0.10 > gstreamer-pbutils-0.10 gtk+-3.0 gudev-1.0 libexif libgphoto2 libsoup-2.4 > libxml-2.0 sqlite3 unique-3.0 webkitgtk-3.0 gthread-2.0` -I./vapi > -D_PREFIX='"/usr/local"' -D_VERSION='"0.11.90+trunk"' > -DGETTEXT_PACKAGE='"shotwell"' > -D_LANG_SUPPORT_DIR='"/usr/local/share/locale"' -D_LIB='"lib"' > `./libraw-config --cflags` -O2 -g -pipe -fPIC > -DG_UDEV_API_IS_SUBJECT_TO_CHANGE -o src/photos/GRaw.o src/photos/GRaw.c > /opt/LinuxSources/tar/shotwell/shotwell/src/photos/GRaw.vala: In function > 'graw_throw_exception': > /opt/LinuxSources/tar/shotwell/shotwell/src/photos/GRaw.vala:278:8: error: > 'LIBRAW_BAD_CROP' undeclared (first use in this function) > /opt/LinuxSources/tar/shotwell/shotwell/src/photos/GRaw.vala:278:8: note: > each undeclared identifier is reported only once for each function it > appears in > make: *** [src/photos/GRaw.o] Error 1 > > > I've looked at the code, but I can't see any reason, why this happens. > Can you give me a hint? > > Kind regards > J. Hoffmann > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From dougie at highmoor.co.uk Sun Dec 18 17:10:26 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Sun, 18 Dec 2011 17:10:26 +0000 Subject: [Shotwell] empty tags automatically deleted Message-ID: <4EEE1E82.6070101@highmoor.co.uk> I'm sure this has cropped up before but I can't remember what the outcome was. I notice that tags with no images are automatically deleted upon exit. So if I carefully create a tag in a specific location in my tag cloud it will be removed if I don't assign images to it. Or if I do assign images but at any point the tag has no images associated with it, it is removed. Is this WAD? What's the rationale? It's exasperating for me. regards Dougie From dougie at highmoor.co.uk Sun Dec 18 17:39:41 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Sun, 18 Dec 2011 17:39:41 +0000 Subject: [Shotwell] A quick F8 thought Message-ID: <4EEE255D.6040208@highmoor.co.uk> When I hit F8 I notice the cursor doesn't automatically focus into the search field. So the order is hit F8, then click in the search field, then type. If you press F8 when the entire library is selected, it can take several seconds for entered text to appear anyway so it's not always immediately obvious that the focus is not there. It'd be more intuitive for the F8 hotkey to automatically focus the cursor in the text box. Dougie From pt at traversin.org Sun Dec 18 19:59:23 2011 From: pt at traversin.org (pt) Date: Sun, 18 Dec 2011 20:59:23 +0100 Subject: [Shotwell] empty tags automatically deleted In-Reply-To: <4EEE1E82.6070101@highmoor.co.uk> References: <4EEE1E82.6070101@highmoor.co.uk> Message-ID: On 18 December 2011 18:10, Dougie Nisbet wrote: > > I notice that tags with no images are automatically deleted upon exit. So if > I carefully create a tag in a specific location in my tag cloud it will be > removed if I don't assign images to it. Or if I do assign images but at any > point the tag has no images associated with it, it is removed. > AFAIK it is by design. I don't like it either, I resolved using a few dummy images tagged with the top-level tags and all subtags (e.g. location, subject, keywords). Cheers, Piergi -- Web: http://traversin.org GNU/Linux user 190604 From adam at yorba.org Sun Dec 18 21:07:03 2011 From: adam at yorba.org (Adam Dingle) Date: Sun, 18 Dec 2011 13:07:03 -0800 Subject: [Shotwell] A quick F8 thought In-Reply-To: <4EEE255D.6040208@highmoor.co.uk> References: <4EEE255D.6040208@highmoor.co.uk> Message-ID: Dougie, note that the Ctrl+F key (= Edit->Find) opens the search bar and gives focus to the search field. Is that not good enough? adam On Sun, Dec 18, 2011 at 9:39 AM, Dougie Nisbet wrote: > When I hit F8 I notice the cursor doesn't automatically focus into the > search field. So the order is hit F8, then click in the search field, then > type. If you press F8 when the entire library is selected, it can take > several seconds for entered text to appear anyway so it's not always > immediately obvious that the focus is not there. It'd be more intuitive for > the F8 hotkey to automatically focus the cursor in the text box. > > Dougie > ______________________________**_________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-**bin/mailman/listinfo/shotwell > From dougie at highmoor.co.uk Sun Dec 18 21:26:45 2011 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Sun, 18 Dec 2011 21:26:45 +0000 Subject: [Shotwell] A quick F8 thought In-Reply-To: References: <4EEE255D.6040208@highmoor.co.uk> Message-ID: <4EEE5A95.60709@highmoor.co.uk> On 18/12/2011 21:07, Adam Dingle wrote: > Dougie, > > note that the Ctrl+F key (= Edit->Find) opens the search bar and gives > focus to the search field. Is that not good enough? > > adam ah right. I thought that F8 and Ctrl-F were synonymous. But F8 = search bar. Ctrl-F = search. No, Ctrl-F is fine. Dougie From adam at yorba.org Mon Dec 19 15:24:17 2011 From: adam at yorba.org (Adam Dingle) Date: Mon, 19 Dec 2011 07:24:17 -0800 Subject: [Shotwell] empty tags automatically deleted In-Reply-To: References: <4EEE1E82.6070101@highmoor.co.uk> Message-ID: <4EEF5721.6080507@yorba.org> On 12/18/2011 11:59 AM, pt wrote: > On 18 December 2011 18:10, Dougie Nisbet wrote: >> I notice that tags with no images are automatically deleted upon exit. So if >> I carefully create a tag in a specific location in my tag cloud it will be >> removed if I don't assign images to it. Or if I do assign images but at any >> point the tag has no images associated with it, it is removed. >> > AFAIK it is by design. I don't like it either, I resolved using a few > dummy images tagged with the top-level tags and all subtags (e.g. > location, subject, keywords). > > Cheers, > Piergi Dougie and Piergi, thanks for pointing this out. This is a bug. I've ticketed this here: http://redmine.yorba.org/issues/4515 I hope we can fix this for 0.12. By the way, in Shotwell 0.10 and earlier, tags could never be empty. In Shotwell 0.11, when we added hierarchical tags we also allowed changed Shotwell to allow empty tags. Since empty tags are now allowed, they should persist across Shotwell sessions. adam From gawith at gmx.de Tue Dec 20 21:18:15 2011 From: gawith at gmx.de (Steinhauer Juergen) Date: Tue, 20 Dec 2011 22:18:15 +0100 Subject: [Shotwell] Compilation error Message-ID: <20111220221815.10861ufd6058enq8@mail.gawith.de> Hi all, I try to compile from git, but I get src/photos/PhotoMetadata.vala:131.13-131.75: error: Return: Cannot convert from `uchar?[]' to `uint8[]' return owner.exiv2.get_preview_image(props[number]).get_data(); I'm using valac 0.16 from http://ppa.launchpad.net/ricotz/testing/ubuntu. Where's my fault? Thanks! Regards ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From adam at yorba.org Tue Dec 20 21:23:02 2011 From: adam at yorba.org (Adam Dingle) Date: Tue, 20 Dec 2011 13:23:02 -0800 Subject: [Shotwell] Compilation error In-Reply-To: <20111220221815.10861ufd6058enq8@mail.gawith.de> References: <20111220221815.10861ufd6058enq8@mail.gawith.de> Message-ID: <4EF0FCB6.1020301@yorba.org> Steinhauer, Vala 0.16 hasn't been released yet (http://live.gnome.org/Vala), so more accurately you're running a daily build of Vala in the 0.16 development series. We haven't tested building Shotwell with daily Vala builds. I recommend that you install Vala 0.15.0 from the Vala PPA (https://launchpad.net/~vala-team/+archive/ppa) and use it to build Shotwell. Alternatively, you can build Vala 0.15.0 from source. adam On 12/20/2011 01:18 PM, Steinhauer Juergen wrote: > Hi all, > > I try to compile from git, but I get > > src/photos/PhotoMetadata.vala:131.13-131.75: error: Return: Cannot > convert from `uchar?[]' to `uint8[]' > return > owner.exiv2.get_preview_image(props[number]).get_data(); > > I'm using valac 0.16 from http://ppa.launchpad.net/ricotz/testing/ubuntu. > > Where's my fault? > > Thanks! > > Regards > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From gawith at gmx.de Tue Dec 20 21:48:11 2011 From: gawith at gmx.de (Steinhauer Juergen) Date: Tue, 20 Dec 2011 22:48:11 +0100 Subject: [Shotwell] Compilation error In-Reply-To: <4EF0FCB6.1020301@yorba.org> References: <20111220221815.10861ufd6058enq8@mail.gawith.de> <4EF0FCB6.1020301@yorba.org> Message-ID: <20111220224811.7190343pq5146n40@mail.gawith.de> Hi, > We haven't tested building Shotwell with daily Vala builds. I > recommend that you install Vala 0.15.0 from the Vala PPA > (https://launchpad.net/~vala-team/+archive/ppa) and use it to build > Shotwell. Alternatively, you can build Vala 0.15.0 from source. > > adam Thanks, for your quick response. Using valac from the ppa above works! Thanks again! Regards ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From j.hoffmann at fh-aachen.de Thu Dec 22 16:59:00 2011 From: j.hoffmann at fh-aachen.de (Jobst Hoffmann) Date: Thu, 22 Dec 2011 17:59:00 +0100 Subject: [Shotwell] LIBRAW_BAD_CROP Message-ID: Adam, first: thank you for your quick response! second: I found the error by myself. I had an old version of libraw laying around :-(, I removed it and now everything works fine again :-)! You're doing a great job, I'm curious about every new version of Shotwell. One question: I'm using an external drive for storing most of my photos. If I start shotwell and I've forgotten to mount the drive, the database gets cleaned up without any error message. As far as I know, I have to reimport all the photos. Is there a better method? And a second question: can I prohibit the cleaning of the database? Kind regards Jobst -- Prof. Dr. Jobst Hoffmann ? ? ? ? ? ?Tel: ? +49 (241) 6009-5 31 59 Fachhochschule Aachen Abt. J?lich ? Fax: ? +49 (241) 6009-5 31 89 Fachbereich 09 ? ? ? ? ? ? ? ? ? ? ?email: j.hoffmann at fh-aachen.de From insomniacpenguin at googlemail.com Thu Dec 22 17:45:40 2011 From: insomniacpenguin at googlemail.com (Andy Stevens) Date: Thu, 22 Dec 2011 17:45:40 +0000 Subject: [Shotwell] LIBRAW_BAD_CROP In-Reply-To: References: Message-ID: What do you mean by "cleaned up"? I'd have expected the whole library to show up under "Missing Photos", and be restored when you restart with the drive mounted again. Andy. On 22 Dec 2011 16:59, "Jobst Hoffmann" wrote: > Adam, > > first: thank you for your quick response! > > second: I found the error by myself. I had an old version of libraw > laying around :-(, I removed it and now everything works fine again :-)! > > You're doing a great job, I'm curious about every new version of > Shotwell. > > One question: I'm using an external drive for storing most of my photos. > If I start shotwell and I've forgotten to mount the drive, the database > gets cleaned up without any error message. As far as I know, I have to > reimport all the photos. Is there a better method? > > And a second question: can I prohibit the cleaning of the database? > > Kind regards > Jobst > -- > Prof. Dr. Jobst Hoffmann Tel: +49 (241) 6009-5 31 59 > Fachhochschule Aachen Abt. J?lich Fax: +49 (241) 6009-5 31 89 > Fachbereich 09 email: j.hoffmann at fh-aachen.de > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From patriciasantanacruz at gmail.com Wed Dec 28 14:04:19 2011 From: patriciasantanacruz at gmail.com (Patricia Santana Cruz) Date: Wed, 28 Dec 2011 14:04:19 +0000 Subject: [Shotwell] nautilus-sendto in Shotwell Message-ID: Hello everybody! I am Patricia Santana Cruz, one of the interns for the new round of internships of the GOPW. I also worked in the organization of the Desktop Summit 2011 in Berlin this year and met some of you there! :-))). During my internship, I will be working on the Cheese Project. I am integrating nautilus-sendto in Cheese in order to add support for sharing images and videos, and during my "investigation" process, I found out that you also use nautilus-sendto to send images and videos, but not for sharing them within different social technologies (facebook, youtube, flicker, etc...). For this you use your own developed services. Going through the code of nautilus-sendto I realised, that it uses internally libsocialweb, which also offers the before mentioned social technologies, so my question, and what I was wondering, is: Why did you decide to use your own developed services for Facebook, Flickr, Youtube, etc... if nautilus-sendto is already providing this through libsocialweb? I am just very curious about this issue, because I am planning to use it too, so your advice would also be very appreciated :)) Thanks in advance and best regards, Patricia. From lucas at yorba.org Fri Dec 30 22:44:39 2011 From: lucas at yorba.org (Lucas Beeler) Date: Fri, 30 Dec 2011 14:44:39 -0800 Subject: [Shotwell] nautilus-sendto in Shotwell In-Reply-To: References: Message-ID: Hi Patricia, Great to hear from you! I hope your holidays were splendid! To answer your question, we developed our own "connectors" (this is what Shotwell calls them) for Facebook, Flickr, etc., because at the time we began development (mid-to-late 2009), nautilus-sendto had no support for publishing to social web services. Furthermore, our ultimate vision for the Shotwell web connectors is that they be bidirectional (i.e., not only can you publish your photos from Shotwell to Flickr but you can import a Flickr photoset into Shotwell). In the longer term, we'd also like Shotwell to support automatic cloud synchronization, so that when you adjust the color of a photo in Shotwell, the colors of that photo are also adjusted automatically in the published version of the photo on Flickr and Facebook. With these requirements, nautilus-sendto is just too simple a tool to support our needs. That said, if all you're going to be doing is moving from photos from Cheese onto social websites, nautilus-sendto may work great for you. I can't wait to see you at GUADEC next year! Lucas