From xavierviader at gmail.com Mon Apr 1 11:01:40 2013 From: xavierviader at gmail.com (Xavi) Date: Mon, 01 Apr 2013 13:01:40 +0200 Subject: [Shotwell] Shotwell 0.14 on debian wheezy (catalan OK) In-Reply-To: <51508D5C.1080605@gmail.com> References: <514F905B.4030700@gmail.com> <515000AC.1070706@highmoor.co.uk> <515069D1.2070702@gmail.com> <51508D5C.1080605@gmail.com> Message-ID: <51596914.5060700@gmail.com> Hi all, I need to compile from source as I use catalan interface and It isn't in precompiled packages on experimental neither yorba ppa. I've already got it on my LMDE (Mint Debian Edition). I've done this: 1- Add this repos: deb http://ftp.es.debian.org/debian/ sid main contrib non-free #SID deb-src http://ftp.es.debian.org/debian/ sid main contrib non-free #SID deb http://ftp.debian.org/debian experimental main #Debian EXPERIMENTAL deb-src http://ftp.debian.org/debian experimental main #Debian EXPERIMENTAL 2- Install: apt-get install desktop-file-utils libgconf2-dev libgee-dev libgexiv2-dev libglib2.0-dev libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev libgtk-3-dev libgudev-1.0-dev libexif-dev libgphoto2-2-dev libraw-dev librest-dev libsoup2.4-dev libxml2-dev libsqlite3-dev m4 valac-0.18 libjson-glib-dev webkitgtk-3.0 3- ./configure ---- make ---- make install Thanks for your help Xavi Al 25/03/13 18:46, En/na Rolf Steinort ha escrit: > On 25.03.2013 17:17, Dougie Nisbet wrote: >> On 25 March 2013 15:14, Rolf Steinort wrote: >>> On 25.03.2013 08:45, Dougie Nisbet wrote: >>>> deb http:///ftp.uk.debian.org/debian/ experimental main >>>> >>>> to my sources.list and trying to manually install some of the >>>> dependencies >>>> from: >>>> >>>> http://packages.debian.org/experimental/amd64/shotwell/download >>>> >>>> but the results look similar. >>>> >>>> Interestingly I've not gone from running 0.13.1 to 0.12.3 (the default >>>> version for Wheezy) and not missing anything essential yet. >>> >>> I installed 0.14 from experimental, it's there already compiled. >>> http://packages.debian.org/experimental/gnome/shotwell >>> >> um, yes it was the experimental package I tried, except that it was >> the 64 bit version. Could try the 32bit I guess but doubt it'd make >> any difference. Are you on Debian Testing? > > Yes, Wheezy 64 bit with some Experimental filled in. > > > $ dpkg -l shotwell > Desired=Unknown/Install/Remove/Purge/Hold > | > Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend > |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) > ||/ Name Version Architecture Description > +++-==============-============-============-================================= > > ii shotwell 0.14.0-1 amd64 digital photo organizer > > Rolf >> > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From lucas at yorba.org Mon Apr 1 18:37:42 2013 From: lucas at yorba.org (Lucas Beeler) Date: Mon, 1 Apr 2013 11:37:42 -0700 Subject: [Shotwell] Shotwell Facebook Upload Problem Message-ID: Hi Paul, > Shotwell grab'ed my photos from a file 29 this > time and I put them to Facebook and it said completed! I look > for them and they never come up in Facebook What version of Shotwell are you running? Cheers, Lucas From thomas at xyz.pp.se Mon Apr 1 18:42:37 2013 From: thomas at xyz.pp.se (Thomas Novin) Date: Mon, 1 Apr 2013 20:42:37 +0200 Subject: [Shotwell] Unable to upload video to Picasa (because it's too large) Message-ID: Hello Just was about to upload an album to Picasa. Somewhere along the task it failed. This is from shotwell.log: L 6110 2013-04-01 20:24:58 [WRN] RESTSupport.vala:167: Publishing error: Service http://picasaweb.google.com/data/feed/api/user/xxxx/albumid/5861940469430831585 returned HTTP status code 413 Request Entity Too Large L 6110 2013-04-01 20:24:58 [WRN] RESTSupport.vala:168: response validation failed. bad response = 'Video file size exceeds 104857600'. I can see a number of feature requests/bugs in this behaviour so I'm not sure how to report it. 1. Why try to upload files that are too big to begin with? Maybe per-plugin settings which limits this. 2. The error presented to the user isn't very user-friendly. shotwell.log was even better (said what the maximum size was). 3. After this one failed file, why not continue and upload the rest? 4. After the error, I have no idea on the progress except for looking in Picasa. Rgds//Thomas From lucas at yorba.org Mon Apr 1 18:50:51 2013 From: lucas at yorba.org (Lucas Beeler) Date: Mon, 1 Apr 2013 11:50:51 -0700 Subject: [Shotwell] Unable to upload video to Picasa (because it's too large) In-Reply-To: References: Message-ID: Hi Thomas, > I can see a number of feature > requests/bugs in this behaviour > so I'm not sure how to report it. When the publishing subsystem was first written several years ago, we ignored limit checking. That said, we should be doing this now that publishing in Shotwell is mature. I've ticketed it here: http://redmine.yorba.org/issues/6720. Cheers, Lucas On Mon, Apr 1, 2013 at 11:42 AM, Thomas Novin wrote: > Hello > > Just was about to upload an album to Picasa. Somewhere along the task > it failed. This is from shotwell.log: > > L 6110 2013-04-01 20:24:58 [WRN] RESTSupport.vala:167: Publishing > error: Service http://picasaweb.google.com/data/feed/api/user/xxxx/albumid/5861940469430831585 > returned HTTP status code 413 Request Entity Too Large > L 6110 2013-04-01 20:24:58 [WRN] RESTSupport.vala:168: response > validation failed. bad response = 'Video file size exceeds 104857600'. > > I can see a number of feature requests/bugs in this behaviour so I'm > not sure how to report it. > > 1. Why try to upload files that are too big to begin with? Maybe > per-plugin settings which limits this. > 2. The error presented to the user isn't very user-friendly. > shotwell.log was even better (said what the maximum size was). > 3. After this one failed file, why not continue and upload the rest? > 4. After the error, I have no idea on the progress except for looking in Picasa. > > Rgds//Thomas > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From lucas at yorba.org Thu Apr 4 00:26:06 2013 From: lucas at yorba.org (Lucas Beeler) Date: Wed, 3 Apr 2013 17:26:06 -0700 Subject: [Shotwell] Shotwell 0.14.1 is Here! Message-ID: We are pleased to announce the release of Shotwell 0.14.1, the first maintenance release in the Shotwell 0.14 family. Shotwell 0.14.1 is a significant update to Shotwell 0.14, boasting the following features: - Fixes a critical issue where Shotwell could close unexpectedly when working with RAW photos in direct-edit mode - The Facebook Connector now recovers smoothly from type 7 errors - EXIF-oriented photos uploaded to Facebook now appear in their correct orientation, even when the strip metadata option is turned on in the Facebook Connector - Fixes an issue where incorrect view filter settings were applied on tag and event pages - The Camera Developer is now disabled for RAW images that lack a suitable paired or embedded JPEG - Updated translations for many languages, including an updated Catalan translation that corrects a problem where incorrect event dates could be displayed - Assorted smaller bug fixes The Shotwell 0.14.1 tarball is available for download immediately here: http://yorba.org/download/shotwell/stable/shotwell-0.14.1.tar.xz. Ubuntu users can also find pre-packaged binaries for Ubuntu Precise (12.04) and Ubuntu Quantal (12.10) on the Yorba PPA here: https://launchpad.net/~yorba/+archive/ppa. Shotwell 0.14.x will ship as the default photo manager in the upcoming Ubuntu Raring (13.04) release. Raring users will receive Shotwell 0.14.1 as part of their normal software update process. Regards, Lucas ------- Lucas Beeler Shotwell Project Technical Lead Yorba Foundation San Francisco, California From mailing.lists at octgsoftware.com Thu Apr 4 01:32:32 2013 From: mailing.lists at octgsoftware.com (Jason Long) Date: Wed, 03 Apr 2013 20:32:32 -0500 Subject: [Shotwell] Shotwell 0.14.1 is Here! In-Reply-To: References: Message-ID: <1365039152.19300.0.camel@localhost.localdomain> Are there any Fedora repositories? On Wed, 2013-04-03 at 17:26 -0700, Lucas Beeler wrote: > We are pleased to announce the release of Shotwell 0.14.1, the first > maintenance release in the Shotwell 0.14 family. Shotwell 0.14.1 is a > significant update to Shotwell 0.14, boasting the following features: > > - Fixes a critical issue where Shotwell could close unexpectedly when > working with RAW photos in direct-edit mode > - The Facebook Connector now recovers smoothly from type 7 errors > - EXIF-oriented photos uploaded to Facebook now appear in their correct > orientation, even when the strip metadata option is turned on in the > Facebook Connector > - Fixes an issue where incorrect view filter settings were applied on > tag and event pages > - The Camera Developer is now disabled for RAW images that lack a > suitable paired or embedded JPEG > - Updated translations for many languages, including an updated Catalan > translation that corrects a problem where incorrect event dates could be > displayed > - Assorted smaller bug fixes > > The Shotwell 0.14.1 tarball is available for download immediately here: > http://yorba.org/download/shotwell/stable/shotwell-0.14.1.tar.xz. Ubuntu > users can also find pre-packaged binaries for Ubuntu Precise (12.04) and > Ubuntu Quantal (12.10) on the Yorba PPA here: > https://launchpad.net/~yorba/+archive/ppa. Shotwell 0.14.x will ship as the > default photo manager in the upcoming Ubuntu Raring (13.04) release. Raring > users will receive Shotwell 0.14.1 as part of their normal software update > process. > > Regards, > Lucas > > ------- > Lucas Beeler > Shotwell Project Technical Lead > Yorba Foundation > San Francisco, California > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From jim at yorba.org Thu Apr 4 01:36:11 2013 From: jim at yorba.org (Jim Nelson) Date: Thu, 04 Apr 2013 01:29:11 -0007 Subject: [Shotwell] Shotwell 0.14.1 is Here! In-Reply-To: <1365039152.19300.0.camel@localhost.localdomain> References: <1365039152.19300.0.camel@localhost.localdomain> Message-ID: <515cd90a.e907420a.744d.0036@mx.google.com> If there are, we don't maintain them. ?Perhaps someone knows of one? -- Jim On Wed, Apr 3, 2013 at 6:32 PM, Jason Long wrote: > Are there any Fedora repositories? > > On Wed, 2013-04-03 at 17:26 -0700, Lucas Beeler wrote: > >> We are pleased to announce the release of Shotwell 0.14.1, the first >> maintenance release in the Shotwell 0.14 family. Shotwell 0.14.1 is >> a >> significant update to Shotwell 0.14, boasting the following >> features: >> >> - Fixes a critical issue where Shotwell could close unexpectedly >> when >> working with RAW photos in direct-edit mode >> - The Facebook Connector now recovers smoothly from type 7 errors >> - EXIF-oriented photos uploaded to Facebook now appear in their >> correct >> orientation, even when the strip metadata option is turned on in >> the >> Facebook Connector >> - Fixes an issue where incorrect view filter settings were >> applied on >> tag and event pages >> - The Camera Developer is now disabled for RAW images that lack a >> suitable paired or embedded JPEG >> - Updated translations for many languages, including an updated >> Catalan >> translation that corrects a problem where incorrect event dates >> could be >> displayed >> - Assorted smaller bug fixes >> >> The Shotwell 0.14.1 tarball is available for download immediately >> here: >> http://yorba.org/download/shotwell/stable/shotwell-0.14.1.tar.xz. >> Ubuntu >> users can also find pre-packaged binaries for Ubuntu Precise >> (12.04) and >> Ubuntu Quantal (12.10) on the Yorba PPA here: >> https://launchpad.net/~yorba/+archive/ppa. Shotwell 0.14.x will >> ship as the >> default photo manager in the upcoming Ubuntu Raring (13.04) >> release. Raring >> users will receive Shotwell 0.14.1 as part of their normal software >> update >> process. >> >> Regards, >> Lucas >> >> ------- >> Lucas Beeler >> Shotwell Project Technical Lead >> Yorba Foundation >> San Francisco, California >> _______________________________________________ >> 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 cpolymeris at gmail.com Fri Apr 5 05:54:41 2013 From: cpolymeris at gmail.com (Camilo Polymeris) Date: Fri, 5 Apr 2013 01:54:41 -0400 Subject: [Shotwell] Call for Testing: Shotwell 0.14 In-Reply-To: References: Message-ID: On Wed, Mar 27, 2013 at 5:13 PM, Lucas Beeler wrote: > > And it looks suspiciously like the stack trace we get when building > Shotwell with versions of Vala that are too new; see this ticket for > details: http://redmine.yorba.org/issues/6689 > > So, the best advice I can give you now is to downgrade your Vala > compiler and try again! > > Thank you. Downgrading to 0.18.0 fixed the issue. Regards, Camilo From rileyrg at gmail.com Fri Apr 5 06:23:41 2013 From: rileyrg at gmail.com (Richard Riley) Date: Fri, 5 Apr 2013 07:23:41 +0100 Subject: [Shotwell] deleting photos : confusion + gimp integration Message-ID: Hi, Ive been using shotwell quite a lot the past week or so. A nice solid alternative. Could someone explain in detail the delete photo and subsequent "empty waste basket" operation. This isn't overly clear: "This will remove the photo from your Shotwell library. Would you also like to move the file to your desktop wastebasket?" WHat does "Library" mean in this case? Since when I do this the photos are still there in the directory imported from - I just dont see them. If I put something in the shotwell wastebasket I shouldnt be seeing it in the library directory imo since its reimported at a later date - I frequently seem to end up with duplicates! And for some reason when I say "move" it takes an *age*. Can it really take almost a minute to delete 50 photos? In addition, is there any ongoing integration of Gimp? If I can see a jpg and there is a correspondingly named xcf in the same directory I would like to be prompted to open the xcf file with Gimp : tighter integration of the two would be great since shotwell is easily the easiest to user file viewer. Ideally of course shotwell would show a preview of xcf files clearly marked next to the jpg pr png. thanks for your patience. From lucas at yorba.org Sat Apr 6 00:46:03 2013 From: lucas at yorba.org (Lucas Beeler) Date: Fri, 5 Apr 2013 17:46:03 -0700 Subject: [Shotwell] deleting photos : confusion + gimp integration Message-ID: > Ive been using shotwell quite a lot the > past week or so. A nice solid alternative. Thank you! > Could someone explain in detail the delete > photo and subsequent "empty waste basket" > operation. This isn't overly clear. You're not the first person to point this out. Indeed, we at Yorba think that the whole thing could be clearer too -- we even have a feature request on this topic here: http://redmine.yorba.org/issues/2645. First, a few things to keep in mind. Shotwell has the notion of a "library directory," which is the folder on disk where the photo files in Shotwell's library are stored (provided you selected the default "Copy to Library" option when you imported the photos). Second, Shotwell has its own Wastebasket that is separate from the system Wastebasket. When you select some photos in Shotwell and then press the "Delete" key on your keyboard, the photos are moved to Shotwell's private Wastebasket. While the photos change locations within Shotwell, the location of the photo files on your hard disk does not change. In particular, Shotwell does not move the photo files into the system Wastebasket on your desktop. The photo files stay right where they were -- in your library directory. Now, let's say that after a few hours of using Shotwell, you've reached the point where you're really, really, terribly sure that you do actually want to delete the photos in Shotwell's private Wastebasket. In this case, once again, "delete" means "delete from Shotwell" and not "delete the actual photo file on disk." To do this, in Shotwell, you switch to the Wastebasket page and click the "Empty Wastebasket" button. At this point, you will have deleted the photos from within Shotwell, but this says nothing about what happens to the actual photo files on disk. So Shotwell asks you "Do you want to move the file(s) to the system Wastebasket?" This question pertains to the photo files. If you say yes, the photo files will be moved from your library directory into the system wastebasket. If you say no, the photo files will stay put in the library directory. Either way, the photos will be deleted from within Shotwell. > In addition, is there any ongoing integration > of Gimp? If I can see a jpg and there is a > correspondingly named xcf in the same > directory I would like to be prompted to > open the xcf file with Gimp. There are no immediate plans to more closely integrate Shotwell and Gimp. But if you turn on library monitoring, you can get most of what you want from Shotwell. In particular, if you open an XCF and then export it from Gimp as a JPEG, writing it over an existing JPEG that Shotwell manages, even if Shotwell didn't launch Gimp for you, Shotwell will detect that the JPEG has changed and re-import it. Regards, Lucas From kenny3794 at outlook.com Sun Apr 7 00:42:17 2013 From: kenny3794 at outlook.com (Kenneth Jernigan) Date: Sat, 6 Apr 2013 20:42:17 -0400 Subject: [Shotwell] Slow Import with many duplicates... Message-ID: Hello, When trying to import from an SD card of 1600 photos on Ubuntu 12.10 (Shotwell version 0.14.1), shotwell slowed to a crawl. After several attempts, each one ramping 1 of my CPUs to 100%, I never made it past 12% complete. I killed the Unity Photo Lens (which was consuming 30% of the second CPU), but saw no change in the import. After giving this several tries, I gave up for an afternoon. Back at it this evening and having seen a comment on an old bug #3867 about importing photos from folder rather than SD card, I decided to give this a try. In this case, it only took about 4 minutes to import approx 88 photos with 1300 considered duplicates. However, another "293 photos/videos failed to import because the photo library folder was not writable". I have 1.3 GB left on the partition where I store pictures, so being unsure why this is called not writable, I studied the import error log and saw the following good and bad examples: /media/lUSERNAME/CANON_DC/DCIM/103___02/IMG_1539.JPG duplicates existing media item /media/Media/Pictures/2013/02/10/IMG_1539.JPG Photos/Videos Not Imported Because Shotwell Couldn't Copy Them into its Library: couldn't copy /media/USERNAME/CANON_DC/DCIM/104___03/IMG_1793.JPG to /media/USERNAME/CANON_DC/DCIM/104___03/IMG_1793.JPG error message: Error opening file '/media/Media/Pictures/2013/03/02/IMG_1793.JPG': Permission denied It was at this time that I realized that my folder permissions on that partition had most likely been damaged recently. Looking at my partition's user permissions (set to ensure multiple users can see the photos), I realized the setgid flag was cleared. Having fixed the setgid flag, I was able to import the remaining 293 files in 5 minutes. I'm perplexed, however, over the behavior observed when initially doing the SD card import. Is this a possible bug? Need me to clear the setgid flag and try again providing some debug output? Or is shotwell primarily designed for single user systems, such that multiple partitions and shared pictures directories not considered nominal use case? Thanks, Ken From dougie at highmoor.co.uk Sun Apr 7 09:26:27 2013 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Sun, 07 Apr 2013 10:26:27 +0100 Subject: [Shotwell] Shotwell 0.14 on debian wheezy In-Reply-To: <515079F0.4010306@gmail.com> References: <514F905B.4030700@gmail.com> <515000AC.1070706@highmoor.co.uk> <515069D1.2070702@gmail.com> <515079F0.4010306@gmail.com> Message-ID: <51613BC3.1020707@highmoor.co.uk> On 25/03/2013 16:23, Joseph Bylund wrote: > > Here's the script that keeps my shotwell (and dependencies) current: [ ... ] Thanks for this. Using this (especially the gexiv2 section) along with Rolf's pointers I'm now running 0.14.1 Dougie From thomas.moschny at gmail.com Sun Apr 7 10:55:03 2013 From: thomas.moschny at gmail.com (Thomas Moschny) Date: Sun, 7 Apr 2013 12:55:03 +0200 Subject: [Shotwell] Shotwell 0.14.1 is Here! In-Reply-To: <1365039152.19300.0.camel@localhost.localdomain> References: <1365039152.19300.0.camel@localhost.localdomain> Message-ID: 2013/4/4 Jason Long > > Are there any Fedora repositories? Shotwell 0.14.1 has been built for Rawhide and Fedora 19. Not sure yet if we will also update the Fedora 18 package. Meanwhile, you can get it from my side repo: http://repos.fedorapeople.org/repos/thm/shotwell . There won't be a Fedora 17 version, because of the GStreamer 1.0 dependency. -- Thomas From preining at logic.at Sun Apr 7 11:23:46 2013 From: preining at logic.at (Norbert Preining) Date: Sun, 7 Apr 2013 20:23:46 +0900 Subject: [Shotwell] Slow Import with many duplicates... In-Reply-To: References: Message-ID: <20130407112346.GB19296@gamma.logic.tuwien.ac.at> On Sa, 06 Apr 2013, Kenneth Jernigan wrote: > When trying to import from an SD card of 1600 photos on Ubuntu 12.10 (Shotwell version 0.14.1), shotwell slowed to a crawl. After several attempts, each one ramping 1 of my CPUs to 100%, I never made it past 12% complete. I killed the Unity Photo Lens (which was consuming 30% of the second CPU), but saw no change in the import. After giving this several tries, I gave up for an afternoon. I agree, I had the same problem with import from both SD card and from iPhone. Copying the files to a new dir on the hard drive, and importing from there worked like a breeze. Something is broken in the import I guess. Norbert ------------------------------------------------------------------------ PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ------------------------------------------------------------------------ From lucas at yorba.org Tue Apr 9 23:49:13 2013 From: lucas at yorba.org (Lucas Beeler) Date: Tue, 9 Apr 2013 16:49:13 -0700 Subject: [Shotwell] Slow Import with many duplicates... In-Reply-To: References: Message-ID: Hi Ken, As Norbert noted, some of the problems you see may have something to do with an interaction between the Shotwell import subsystem and your particular memory card or card reader. That said, this error: > Photos/Videos Not Imported Because Shotwell > Couldn't Copy Them into its Library: > > couldn't copy /media/USERNAME/CANON_DC/DCIM/ > 104___03/IMG_1793.JPG > to /media/USERNAME/CANON_DC/DCIM/104___03/ > IMG_1793.JPG > error message: Error opening file '/media/Media/Pictures/ > 2013/03/02/IMG_1793.JPG': Permission denied Is almost certainly due to the permissions problem on the library destination directory that you described in your message. You also asked this question: > Or is shotwell primarily designed for single > user systems, such that multiple partitions > and shared pictures directories not considered > nominal use case? This is covered somewhat in the "Can I access a Shotwell library across a network, possibly from multiple machines?" section of the Shotwell FAQ here: http://redmine.yorba.org/projects/shotwell/wiki/ShotwellFAQ. While the FAQ entry describes one specific and particularly dangerous problem, sharing the same library directory between multiple Shotwell instances is not recommended or supported. Cheers, Lucas On Sat, Apr 6, 2013 at 5:42 PM, Kenneth Jernigan wrote: > Hello, > > When trying to import from an SD card of 1600 photos on Ubuntu 12.10 > (Shotwell version 0.14.1), shotwell slowed to a crawl. After several > attempts, each one ramping 1 of my CPUs to 100%, I never made it past 12% > complete. I killed the Unity Photo Lens (which was consuming 30% of the > second CPU), but saw no change in the import. After giving this several > tries, I gave up for an afternoon. > > Back at it this evening and having seen a comment on an old bug #3867 > about importing photos from folder rather than SD card, I decided to give > this a try. In this case, it only took about 4 minutes to import approx 88 > photos with 1300 considered duplicates. However, another "293 > photos/videos failed to import because the photo library folder was not > writable". I have 1.3 GB left on the partition where I store pictures, so > being unsure why this is called not writable, I studied the import error > log and saw the following good and bad examples: > > > /media/lUSERNAME/CANON_DC/DCIM/103___02/IMG_1539.JPG duplicates existing > media item > /media/Media/Pictures/2013/02/10/IMG_1539.JPG > > Photos/Videos Not Imported Because Shotwell Couldn't Copy Them into its > Library: > > couldn't copy /media/USERNAME/CANON_DC/DCIM/104___03/IMG_1793.JPG > to /media/USERNAME/CANON_DC/DCIM/104___03/IMG_1793.JPG > error message: Error opening file > '/media/Media/Pictures/2013/03/02/IMG_1793.JPG': Permission denied > > > It was at this time that I realized that my folder permissions on that > partition had most likely been damaged recently. Looking at my partition's > user permissions (set to ensure multiple users can see the photos), I > realized the setgid flag was cleared. Having fixed the setgid flag, I was > able to import the remaining 293 files in 5 minutes. I'm perplexed, > however, over the behavior observed when initially doing the SD card > import. Is this a possible bug? Need me to clear the setgid flag and try > again providing some debug output? Or is shotwell primarily designed for > single user systems, such that multiple partitions and shared pictures > directories not considered nominal use case? > > Thanks, > Ken > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From preining at logic.at Wed Apr 10 03:32:17 2013 From: preining at logic.at (Norbert Preining) Date: Wed, 10 Apr 2013 12:32:17 +0900 Subject: [Shotwell] Slow Import with many duplicates... In-Reply-To: References: Message-ID: <20130410033217.GC5145@gamma.logic.tuwien.ac.at> Hi Lucas, On Di, 09 Apr 2013, Lucas Beeler wrote: > As Norbert noted, some of the problems you see may have something to do > with an interaction between the Shotwell import subsystem and your > particular memory card or card reader. That said, this error: I am not 100% sure. I have the very same extrem slowdown of shotwell when importing either from iPhone or from the laptop-builtin sd-card reader. Copying the files from these devices to the hard drive works liek a breeze. So it seems that something *is* wrong in the import. Finding time I will try to debug it. Norbert ------------------------------------------------------------------------ PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ------------------------------------------------------------------------ From joseph.bylund at gmail.com Wed Apr 10 13:52:18 2013 From: joseph.bylund at gmail.com (Joseph Bylund) Date: Wed, 10 Apr 2013 09:52:18 -0400 Subject: [Shotwell] Profiling Specific Actions in Shotwell Message-ID: <51656E92.3090403@gmail.com> There seem to be a few reasons at the moment that it would be nice to profile/benchmark specific actions in shotwell (event merge, import, viewing folders in sidebar). Does anyone happen to know of a good way of doing this? -Joe From schuetz.marc at gmx.de Wed Apr 10 18:15:31 2013 From: schuetz.marc at gmx.de (Marc) Date: Wed, 10 Apr 2013 20:15:31 +0200 Subject: [Shotwell] Shotwell 0.14.1 is Here! In-Reply-To: References: <1365039152.19300.0.camel@localhost.localdomain> <51657E54.4040804@gmx.de> Message-ID: <5165AC43.3020906@gmx.de> Hi all, I notice that a Bug from 0.13trunk still exist (for me?) in 0.14.1 When I? at the Library all Photos have a shadow, when I'm sroll down some hundred of photos then the shadow of all photos become pixel from other pictures. So that there is no normal grey/black shadow every shadow becomes colored. When I? scrolling up again, the newest photos were displyed correct again. So there seems to be a border. Anyone else who experience some an issue? thanks and kind regards Marc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From joseph.bylund at gmail.com Wed Apr 10 18:19:38 2013 From: joseph.bylund at gmail.com (Joseph Bylund) Date: Wed, 10 Apr 2013 14:19:38 -0400 Subject: [Shotwell] Shotwell 0.14.1 is Here! In-Reply-To: <5165AC43.3020906@gmx.de> References: <1365039152.19300.0.camel@localhost.localdomain> <51657E54.4040804@gmx.de> <5165AC43.3020906@gmx.de> Message-ID: <5165AD3A.9030906@gmail.com> Marc, Any chance you can grab a screenshot of the incorrect state? Is there already a bug report for this? -Joe On 04/10/2013 02:15 PM, Marc wrote: > Hi all, > > I notice that a Bug from 0.13trunk still exist (for me?) in 0.14.1 > When Im' at the Library all Photos have a shadow, when I'm sroll down > some hundred of photos then the shadow of all photos become pixel from > other pictures. > So that there is no normal grey/black shadow every shadow becomes colored. > > When Im' scrolling up again, the newest photos were displyed correct > again. So there seems to be a border. > > Anyone else who experience some an issue? > > > thanks and kind regards > Marc > > > > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From clinton at yorba.org Wed Apr 10 18:36:15 2013 From: clinton at yorba.org (Clint Rogers) Date: Wed, 10 Apr 2013 14:36:15 -0400 Subject: [Shotwell] Shotwell 0.14.1 is Here! In-Reply-To: <5165AD3A.9030906@gmail.com> References: <1365039152.19300.0.camel@localhost.localdomain> <51657E54.4040804@gmx.de> <5165AC43.3020906@gmx.de> <5165AD3A.9030906@gmail.com> Message-ID: Good morning all, To chime in here, Marc, are you, by any chance, running on a machine with Intel GMA 915, GMA 945 or similar graphics hardware? On my work desktop (GMA 945), I have occasionally seen crazily-coloured shadows in Shotwell before, but this usually occurred alongside visual glitches in other applications as well, leading me to believe it was some kind of hardware or driver problem (I've seen it in multiple distros, across multiple window managers, and with multiple compositors). At any rate, if you could get a screenshot as well as post your system specs, that may help us pin down what's happening, and whether it's a problem in Shotwell, or some other component. Cheers, -c On 10 April 2013 14:19, Joseph Bylund wrote: > Marc, > Any chance you can grab a screenshot of the incorrect state? Is there > already a bug report for this? > -Joe > > > On 04/10/2013 02:15 PM, Marc wrote: > >> Hi all, >> >> I notice that a Bug from 0.13trunk still exist (for me?) in 0.14.1 >> When Im' at the Library all Photos have a shadow, when I'm sroll down >> >> some hundred of photos then the shadow of all photos become pixel from >> other pictures. >> So that there is no normal grey/black shadow every shadow becomes colored. >> >> When Im' scrolling up again, the newest photos were displyed correct >> >> again. So there seems to be a border. >> >> Anyone else who experience some an issue? >> >> >> thanks and kind regards >> Marc >> >> >> >> >> ______________________________**_________________ >> 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 > -- --------------------------- "I don't know what (b? - 4ac) equals, and I don't care," Tom said indiscriminately. From schuetz.marc at gmx.de Wed Apr 10 19:51:33 2013 From: schuetz.marc at gmx.de (Marc) Date: Wed, 10 Apr 2013 21:51:33 +0200 Subject: [Shotwell] Shotwell 0.14.1 is Here! In-Reply-To: References: <1365039152.19300.0.camel@localhost.localdomain> <51657E54.4040804@gmx.de> <5165AC43.3020906@gmx.de> <5165AD3A.9030906@gmail.com> Message-ID: <5165C2C5.3010901@gmx.de> Hi Clinton, Hi Joe, Hi all that was good point for me to check because I'm using a Beta-graphicsdriver one of my machine. So I started up my laptop with Intel HD graphic, copied db+cache and started shotwell. But the error exists on both :-( http://img839.imageshack.us/img839/6615/shotwellshadow.png here you can see the border from good shadow, to bad shadow. If anyone experience the same it would be nice to compare our systems. Because - Don laugh pls ;-) - I'm using the xorg-edgers on both ubuntu 12.04 64bit machines. Everything, sure, everything is stable for me. One with Amd-Card, the other with intel hd graphic. So if noone uses xorg-edgers and don experience this problem it should be based there. But I? nearly unable to purge the ppa on both at the moment. Will try to check an VMinstall if I find any time. thanks and kind regards Marc Am 10.04.2013 20:36, schrieb Clint Rogers: > Good morning all, > > To chime in here, Marc, are you, by any chance, running on a machine with > Intel GMA 915, GMA 945 or similar > graphics hardware? On my work desktop (GMA 945), I have occasionally seen > crazily-coloured shadows in Shotwell before, but this usually occurred > alongside visual glitches in other applications as well, leading me to > believe it was some kind of hardware or driver problem (I've seen it in > multiple distros, across multiple window managers, and with multiple > compositors). > > At any rate, if you could get a screenshot as well as post your system > specs, that may help us pin down what's happening, and whether it's a > problem in Shotwell, or some other component. > > Cheers, > -c > > > On 10 April 2013 14:19, Joseph Bylund wrote: > >> Marc, >> Any chance you can grab a screenshot of the incorrect state? Is there >> already a bug report for this? >> -Joe >> >> >> On 04/10/2013 02:15 PM, Marc wrote: >> >>> Hi all, >>> >>> I notice that a Bug from 0.13trunk still exist (for me?) in 0.14.1 >>> When Im' at the Library all Photos have a shadow, when I'm sroll down >>> >>> some hundred of photos then the shadow of all photos become pixel from >>> other pictures. >>> So that there is no normal grey/black shadow every shadow becomes colored. >>> >>> When Im' scrolling up again, the newest photos were displyed correct >>> >>> again. So there seems to be a border. >>> >>> Anyone else who experience some an issue? >>> >>> >>> thanks and kind regards >>> Marc >>> >>> >>> >>> >>> ______________________________**_________________ >>> 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 >> > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From clinton at yorba.org Wed Apr 10 19:57:23 2013 From: clinton at yorba.org (Clint Rogers) Date: Wed, 10 Apr 2013 15:57:23 -0400 Subject: [Shotwell] Fwd: Shotwell 0.14.1 is Here! In-Reply-To: References: <1365039152.19300.0.camel@localhost.localdomain> <51657E54.4040804@gmx.de> <5165AC43.3020906@gmx.de> <5165AD3A.9030906@gmail.com> <5165C2C5.3010901@gmx.de> Message-ID: Apologies, I left the list out of the loop... ---------- Forwarded message ---------- From: Clint Rogers Date: 10 April 2013 15:56 Subject: Re: [Shotwell] Shotwell 0.14.1 is Here! To: Marc Marc, This is very much like the graphical corruption I've seen (although I'm not xorg-edgers). Do you get, say, black horizontal bars across text if you scroll quickly in Firefox? If so, I'd feel a bit more confident in blaming the graphics drivers at this point. Cheers, -c On 10 April 2013 15:51, Marc wrote: > Hi Clinton, Hi Joe, Hi all > > that was good point for me to check because I'm using a > Beta-graphicsdriver one of my machine. > > So I started up my laptop with Intel HD graphic, copied db+cache and > started shotwell. > But the error exists on both :-( > > http://img839.imageshack.us/img839/6615/shotwellshadow.png > > here you can see the border from good shadow, to bad shadow. > > If anyone experience the same it would be nice to compare our systems. > Because - Don laugh pls ;-) - I'm using the xorg-edgers on both ubuntu > 12.04 64bit machines. > Everything, sure, everything is stable for me. One with Amd-Card, the > other with intel hd graphic. > > So if noone uses xorg-edgers and don experience this problem it should > be based there. But I? nearly unable to purge the ppa on both at the > moment. Will try to check an VMinstall if I find any time. > > thanks and kind regards > Marc > > > > Am 10.04.2013 20:36, schrieb Clint Rogers: > > Good morning all, > > > > To chime in here, Marc, are you, by any chance, running on a machine with > > Intel GMA 915, GMA 945 or similar > > graphics hardware? On my work desktop (GMA 945), I have occasionally > seen > > crazily-coloured shadows in Shotwell before, but this usually occurred > > alongside visual glitches in other applications as well, leading me to > > believe it was some kind of hardware or driver problem (I've seen it in > > multiple distros, across multiple window managers, and with multiple > > compositors). > > > > At any rate, if you could get a screenshot as well as post your system > > specs, that may help us pin down what's happening, and whether it's a > > problem in Shotwell, or some other component. > > > > Cheers, > > -c > > > > > > On 10 April 2013 14:19, Joseph Bylund wrote: > > > >> Marc, > >> Any chance you can grab a screenshot of the incorrect state? Is there > >> already a bug report for this? > >> -Joe > >> > >> > >> On 04/10/2013 02:15 PM, Marc wrote: > >> > >>> Hi all, > >>> > >>> I notice that a Bug from 0.13trunk still exist (for me?) in 0.14.1 > >>> When Im' at the Library all Photos have a shadow, when I'm sroll down > >>> > >>> some hundred of photos then the shadow of all photos become pixel from > >>> other pictures. > >>> So that there is no normal grey/black shadow every shadow becomes > colored. > >>> > >>> When Im' scrolling up again, the newest photos were displyed correct > >>> > >>> again. So there seems to be a border. > >>> > >>> Anyone else who experience some an issue? > >>> > >>> > >>> thanks and kind regards > >>> Marc > >>> > >>> > >>> > >>> > >>> ______________________________**_________________ > >>> Shotwell mailing list > >>> Shotwell at lists.yorba.org > >>> http://lists.yorba.org/cgi-**bin/mailman/listinfo/shotwell< > 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< > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell> > >> > > > > > > > > -- --------------------------- "I don't know what (b? - 4ac) equals, and I don't care," Tom said indiscriminately. -- --------------------------- "I don't know what (b? - 4ac) equals, and I don't care," Tom said indiscriminately. From preining at logic.at Wed Apr 10 21:57:10 2013 From: preining at logic.at (Norbert Preining) Date: Thu, 11 Apr 2013 06:57:10 +0900 Subject: [Shotwell] Shotwell 0.14.1 is Here! In-Reply-To: <5165C2C5.3010901@gmx.de> References: <1365039152.19300.0.camel@localhost.localdomain> <51657E54.4040804@gmx.de> <5165AC43.3020906@gmx.de> <5165AD3A.9030906@gmail.com> <5165C2C5.3010901@gmx.de> Message-ID: <20130410215710.GA7676@gamma.logic.tuwien.ac.at> Hi everyone, chiming in. Thanks Marc for reminding me, I have seen this bug since long, too, but always ignored it ... I am using Debian/testing/unstable, that is xserver-xorg-video-intel: 2:2.20.14-1.1 xserver-xorg: 1:7.7+2 I attach a typical artifact > Everything, sure, everything is stable for me. One with Amd-Card, the > other with intel hd graphic. Same here, with intel in laptop Norbert ------------------------------------------------------------------------ PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ------------------------------------------------------------------------ From preining at logic.at Wed Apr 10 22:35:52 2013 From: preining at logic.at (Norbert Preining) Date: Thu, 11 Apr 2013 07:35:52 +0900 Subject: [Shotwell] Shotwell 0.14.1 is Here! In-Reply-To: <20130410215710.GA7676@gamma.logic.tuwien.ac.at> References: <1365039152.19300.0.camel@localhost.localdomain> <51657E54.4040804@gmx.de> <5165AC43.3020906@gmx.de> <5165AD3A.9030906@gmail.com> <5165C2C5.3010901@gmx.de> <20130410215710.GA7676@gamma.logic.tuwien.ac.at> Message-ID: <20130410223552.GC7676@gamma.logic.tuwien.ac.at> On Do, 11 Apr 2013, Norbert Preining wrote: > chiming in. Thanks Marc for reminding me, I have seen this bug since > long, too, but always ignored it ... > > I am using Debian/testing/unstable, that is > xserver-xorg-video-intel: 2:2.20.14-1.1 > xserver-xorg: 1:7.7+2 > > I attach a typical artifact Attachment didn't go through, see: http://www.preining.info/shotwell-shadow.png > > Everything, sure, everything is stable for me. One with Amd-Card, the > > other with intel hd graphic. > > Same here, with intel in laptop Norbert ------------------------------------------------------------------------ PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ------------------------------------------------------------------------ From rileyrg at gmail.com Thu Apr 11 15:42:46 2013 From: rileyrg at gmail.com (Richard Riley) Date: Thu, 11 Apr 2013 16:42:46 +0100 Subject: [Shotwell] Deleting using Debian Wheezy repo Message-ID: Is there any improvement in latest versions with emptying the wastebasket in Shotwell? It takes an *age* when I tell it to actually remove the files too (or move to trash in shotwell terminology). Which brings me to real use cases with Shotwell and suggestion for impovement Its typical with modern DSLR cameras to fire off hundreds of shots. 99% will be deleted before any processing. Suggestion #1 : allow "delete" from the preview image in the shotwell app. Suggestion #2 : allow complete bypass of the slightly convoluted wastebasket.Simply put the original image directly in the trash can or "hard delete" immediately depending on a setting. No DB access at all. Users are savvy enough to recover from the trash can - it's why its there. This will also not leave the user sat there for 15 minutes twiddling the thumb when he elects to empty the shotwell wastebasket in order to physically remove the files from the event file hierarchy. Thanks a lot Except for the long delay in wastebasket and frequent freeze when writing metadata (at 99%) its generally a joy to use shotwell. Keep up the good work. From sk at skaiser.at Thu Apr 11 20:15:55 2013 From: sk at skaiser.at (Siegfried Kaiser) Date: Thu, 11 Apr 2013 22:15:55 +0200 Subject: [Shotwell] remake the thumbs from the files possible? Message-ID: <1365711355.2697.5.camel@sk-MS-7368> Hello all, I have a little problem with my shotwell data : I had to copy the files from one disk to another and seem to have forgotten the thumbnails. So I have following problem: I have consistently a wrong thumbnail for my images. When I search for a tag, I get the correct number of wrong thumbnails, when I click on a thumbnail I get the correct image file - there is no problem. Is there an easy way to generate the correct thumbs? - I do not want to throw away my tags, they still work correctly but is a bit frustrating to have to click first to get the correct image when I have searched for a tag. Thanks, Siegfried From lucas at yorba.org Thu Apr 11 21:03:12 2013 From: lucas at yorba.org (Lucas Beeler) Date: Thu, 11 Apr 2013 14:03:12 -0700 Subject: [Shotwell] remake the thumbs from the files possible? In-Reply-To: <1365711355.2697.5.camel@sk-MS-7368> References: <1365711355.2697.5.camel@sk-MS-7368> Message-ID: Hi Siegfried, What version of Shotwell are you running? If you're running Shotwell 0.14.0 or later, you can simply delete your ~/.cache/shotwell directory while Shotwell isn't running and then restart Shotwell. Thumbnails will then be regenerated. Depending on how many photos you have, it might take a while. Note that removing the thumbnail cache directory will have no effect on your tags, events, or anything else. Shotwell 0.14.0 and later were designed under the assumption that because it's a cache directory, its contents could disappear at any time. Cheers, Lucas On Thu, Apr 11, 2013 at 1:15 PM, Siegfried Kaiser wrote: > Hello all, > > I have a little problem with my shotwell data : I had to copy the files > from one disk to another and seem to have forgotten the thumbnails. So I > have following problem: I have consistently a wrong thumbnail for my > images. When I search for a tag, I get the correct number of wrong > thumbnails, when I click on a thumbnail I get the correct image file - > there is no problem. > Is there an easy way to generate the correct thumbs? - I do not want to > throw away my tags, they still work correctly but is a bit frustrating > to have to click first to get the correct image when I have searched for > a tag. > > Thanks, > Siegfried > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From lucas at yorba.org Thu Apr 11 21:57:38 2013 From: lucas at yorba.org (Lucas Beeler) Date: Thu, 11 Apr 2013 14:57:38 -0700 Subject: [Shotwell] Profiling Specific Actions in Shotwell In-Reply-To: <51656E92.3090403@gmail.com> References: <51656E92.3090403@gmail.com> Message-ID: Hi Joe, I use sysprof (available in the Ubuntu repos). Sysprof's user interface has gotten worse in recent versions (namely, it's much harder to find the "drill down" view that shows the call stack for profiled functions), but sysprof has the advantage that it's a system-wide profiler and you don't have to do anything special to Shotwell or its Makefile to use it. My colleague Clint uses gprof, though this requires a little tinkering around in the Makefile to pass the flags gprof needs through from the Vala compiler to GCC. Anyway, that's my two cents! Cheers, Lucas On Wed, Apr 10, 2013 at 6:52 AM, Joseph Bylund wrote: > There seem to be a few reasons at the moment that it would be nice to > profile/benchmark specific actions in shotwell (event merge, import, > viewing folders in sidebar). Does anyone happen to know of a good way of > doing this? > > -Joe > ______________________________**_________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-**bin/mailman/listinfo/shotwell > From lucas at yorba.org Thu Apr 11 22:19:53 2013 From: lucas at yorba.org (Lucas Beeler) Date: Thu, 11 Apr 2013 15:19:53 -0700 Subject: [Shotwell] Slow Import with many duplicates... In-Reply-To: <20130410033217.GC5145@gamma.logic.tuwien.ac.at> References: <20130410033217.GC5145@gamma.logic.tuwien.ac.at> Message-ID: Hi Norbert, Is your import from devices slow even when there are no duplicates present? We know of an issue involving duplicates ( http://redmine.yorba.org/issues/3687) that can cause Shotwell to become unresponsive, but if a usual-case import (i.e. no duplicates) slows Shotwell to the point of being unresponsive, that's a serious problem and we should open a new ticket for it. Curiously, does import speed seem in any way proportional to the number of photos you have in your library? If you've got an empty library, is import faster than in your personal photo library with (I'm guessing) thousands of photos? I ask because a slowdown proportional to library size suggests that the duplicate detection code path might be involved. Cheers, Lucas On Tue, Apr 9, 2013 at 8:32 PM, Norbert Preining wrote: > Hi Lucas, > > On Di, 09 Apr 2013, Lucas Beeler wrote: > > As Norbert noted, some of the problems you see may have something to do > > with an interaction between the Shotwell import subsystem and your > > particular memory card or card reader. That said, this error: > > I am not 100% sure. I have the very same extrem slowdown of shotwell > when importing either from iPhone or from the laptop-builtin sd-card > reader. Copying the files from these devices to the hard drive works > liek a breeze. > > So it seems that something *is* wrong in the import. > > Finding time I will try to debug it. > > Norbert > > ------------------------------------------------------------------------ > PREINING, Norbert http://www.preining.info > JAIST, Japan TeX Live & Debian Developer > DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 > ------------------------------------------------------------------------ > From joseph.bylund at gmail.com Thu Apr 11 22:32:44 2013 From: joseph.bylund at gmail.com (Joseph Bylund) Date: Thu, 11 Apr 2013 18:32:44 -0400 Subject: [Shotwell] Profiling Specific Actions in Shotwell In-Reply-To: References: <51656E92.3090403@gmail.com> Message-ID: <51673A0C.70506@gmail.com> At the risk of getting slightly off topic... The reason that I asked about profiling is that I'm experiencing terribly slow copy imports of raw files. I don't think it's getting 1/second. My hardware isn't top of the line but it isn't bad either. I experience this behavior even if there are no photos in the library, and jpg imports are blinding quick. I'll do a little more testing before opening a bug and I'll try to provide you with a profile, who knows maybe I'll even see an easy solution. Clint, any chance you could add a configure or make flag to add the necessary gprof flags? -Joe On 04/11/2013 05:57 PM, Lucas Beeler wrote: > Hi Joe, > > I use sysprof (available in the Ubuntu repos). Sysprof's user > interface has gotten worse in recent versions (namely, it's much > harder to find the "drill down" view that shows the call stack for > profiled functions), but sysprof has the advantage that it's a > system-wide profiler and you don't have to do anything special to > Shotwell or its Makefile to use it. My colleague Clint uses gprof, > though this requires a little tinkering around in the Makefile to pass > the flags gprof needs through from the Vala compiler to GCC. Anyway, > that's my two cents! > > Cheers, > Lucas > > > On Wed, Apr 10, 2013 at 6:52 AM, Joseph Bylund > > wrote: > > There seem to be a few reasons at the moment that it would be nice > to profile/benchmark specific actions in shotwell (event merge, > import, viewing folders in sidebar). Does anyone happen to know > of a good way of doing this? > > -Joe > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > From clinton at yorba.org Thu Apr 11 22:45:18 2013 From: clinton at yorba.org (Clint Rogers) Date: Thu, 11 Apr 2013 18:45:18 -0400 Subject: [Shotwell] Profiling Specific Actions in Shotwell In-Reply-To: <51673A0C.70506@gmail.com> References: <51656E92.3090403@gmail.com> <51673A0C.70506@gmail.com> Message-ID: Hi Joe, That's a good idea, and it isn't a terribly intrusive change, so it should be easy to get approved. Let me make up a ticket for it so we can track it the right way, but I think I can have this at least submitted for review in a matter of minutes. I'll start on it now. Cheers, -c On 11 April 2013 18:32, Joseph Bylund wrote: > At the risk of getting slightly off topic... > > The reason that I asked about profiling is that I'm experiencing terribly > slow copy imports of raw files. I don't think it's getting 1/second. My > hardware isn't top of the line but it isn't bad either. I experience this > behavior even if there are no photos in the library, and jpg imports are > blinding quick. I'll do a little more testing before opening a bug and > I'll try to provide you with a profile, who knows maybe I'll even see an > easy solution. > > Clint, any chance you could add a configure or make flag to add the > necessary gprof flags? > > -Joe > > > On 04/11/2013 05:57 PM, Lucas Beeler wrote: > > Hi Joe, > > I use sysprof (available in the Ubuntu repos). Sysprof's user interface > has gotten worse in recent versions (namely, it's much harder to find the > "drill down" view that shows the call stack for profiled functions), but > sysprof has the advantage that it's a system-wide profiler and you don't > have to do anything special to Shotwell or its Makefile to use it. My > colleague Clint uses gprof, though this requires a little tinkering around > in the Makefile to pass the flags gprof needs through from the Vala > compiler to GCC. Anyway, that's my two cents! > > Cheers, > Lucas > > > On Wed, Apr 10, 2013 at 6:52 AM, Joseph Bylund wrote: > >> There seem to be a few reasons at the moment that it would be nice to >> profile/benchmark specific actions in shotwell (event merge, import, >> viewing folders in sidebar). Does anyone happen to know of a good way of >> doing this? >> >> -Joe >> _______________________________________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >> > > > -- --------------------------- "I don't know what (b? - 4ac) equals, and I don't care," Tom said indiscriminately. From clinton at yorba.org Thu Apr 11 23:00:09 2013 From: clinton at yorba.org (Clint Rogers) Date: Thu, 11 Apr 2013 19:00:09 -0400 Subject: [Shotwell] Profiling Specific Actions in Shotwell In-Reply-To: References: <51656E92.3090403@gmail.com> <51673A0C.70506@gmail.com> Message-ID: Hi again, Joe, Unfortunately, I have a few other issues on my plate that are also pressing, so I can't work on this just yet, but if you want profiling information to be generated with what's already there, simply navigate to lines 440 and 444 of the current Makefile and add '-pg' to CFLAGS, then rebuild and rerun the application. Once you've generated some stats, you can point the profiler at it; for more info, please see http://www.thegeekstuff.com/2012/08/gprof-tutorial/ . Cheers, -c On 11 April 2013 18:45, Clint Rogers wrote: > Hi Joe, > > That's a good idea, and it isn't a terribly intrusive change, so it should > be easy to get approved. Let me make up a ticket for it so we can track it > the right way, but I think I can have this at least submitted for review in > a matter of minutes. > > I'll start on it now. > > Cheers, > -c > > > On 11 April 2013 18:32, Joseph Bylund wrote: > >> At the risk of getting slightly off topic... >> >> The reason that I asked about profiling is that I'm experiencing terribly >> slow copy imports of raw files. I don't think it's getting 1/second. My >> hardware isn't top of the line but it isn't bad either. I experience this >> behavior even if there are no photos in the library, and jpg imports are >> blinding quick. I'll do a little more testing before opening a bug and >> I'll try to provide you with a profile, who knows maybe I'll even see an >> easy solution. >> >> Clint, any chance you could add a configure or make flag to add the >> necessary gprof flags? >> >> -Joe >> >> >> On 04/11/2013 05:57 PM, Lucas Beeler wrote: >> >> Hi Joe, >> >> I use sysprof (available in the Ubuntu repos). Sysprof's user interface >> has gotten worse in recent versions (namely, it's much harder to find the >> "drill down" view that shows the call stack for profiled functions), but >> sysprof has the advantage that it's a system-wide profiler and you don't >> have to do anything special to Shotwell or its Makefile to use it. My >> colleague Clint uses gprof, though this requires a little tinkering around >> in the Makefile to pass the flags gprof needs through from the Vala >> compiler to GCC. Anyway, that's my two cents! >> >> Cheers, >> Lucas >> >> >> On Wed, Apr 10, 2013 at 6:52 AM, Joseph Bylund wrote: >> >>> There seem to be a few reasons at the moment that it would be nice to >>> profile/benchmark specific actions in shotwell (event merge, import, >>> viewing folders in sidebar). Does anyone happen to know of a good way of >>> doing this? >>> >>> -Joe >>> _______________________________________________ >>> Shotwell mailing list >>> Shotwell at lists.yorba.org >>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >>> >> >> >> > > > -- > --------------------------- > "I don't know what (b? - 4ac) equals, and I don't care," Tom said > indiscriminately. > > > > > > -- --------------------------- "I don't know what (b? - 4ac) equals, and I don't care," Tom said indiscriminately. From clinton at yorba.org Fri Apr 12 00:39:34 2013 From: clinton at yorba.org (Clint Rogers) Date: Thu, 11 Apr 2013 20:39:34 -0400 Subject: [Shotwell] Deleting using Debian Wheezy repo In-Reply-To: References: Message-ID: Hi Richard, > Is there any improvement in latest versions with emptying the wastebasket > in Shotwell? As luck would have it, we've been having some discussions about profiling and optimization here recently, and although no work was done directly on moving to the trash as such, I can tell you that we're currently focusing on exactly the type of performance problem you've noted. I wonder if it's something akin to the performance problems detailed in http://redmine.yorba.org/issues/979... > Which brings me to real use cases with Shotwell and suggestion for > impovement > > Its typical with modern DSLR cameras to fire off hundreds of shots. 99% > will be deleted before any processing. > > Suggestion #1 : allow "delete" from the preview image in the shotwell app. This makes sense; I'll ticket it right away. > Suggestion #2 : allow complete bypass of the slightly convoluted > wastebasket.Simply put the original image directly in the trash can or > "hard delete" immediately depending on a setting. No DB access at all. If I'm understanding this correctly, rather than have Shotwell's internal wastebasket as a tier above your desktop's, you'd rather just use your desktop's wastebasket directly. A setting seems like it might confuse some less-savvy users - would it be better to have, say, Shift+Delete or holding Shift when adding something to Shotwell's trash? (This key combination seems to be fairly common among other Linux programs, does about the same thing, and, as such, would be least likely to negatively surprise or confuse people.) Either way, though, I'll add a feature request for an insta-trash as well, and we can talk about the UI as we work on it. > This will also not leave the user sat there for 15 minutes twiddling the > thumb This seems like the crux of the matter here - simply trashing a group of files should NOT take terribly long, and while there is going to be a little per-file overhead, as you might expect, we feel that it could be far better than it is at the moment. > Thanks a lot > > Except for the long delay in wastebasket and frequent freeze when writing > metadata (at 99%) Are you on the version that comes with a new install of Wheezy by default (0.12.3)? Metadata writing should be dramatically improved in 0.13 and beyond; if you're seeing this in something later than 0.12.x, then it's a regression, and we'd like to know about it. > its generally a joy to use shotwell. Keep up the good > work. We do try, and it's exactly these kinds of compliments and words of encouragement that make it worthwhile. Thanks for bringing these issues to our attention. Cheers, -c -- --------------------------- "I don't know what (b? - 4ac) equals, and I don't care," Tom said indiscriminately. From clinton at yorba.org Fri Apr 12 00:42:43 2013 From: clinton at yorba.org (Clint Rogers) Date: Thu, 11 Apr 2013 20:42:43 -0400 Subject: [Shotwell] Deleting using Debian Wheezy repo In-Reply-To: References: Message-ID: Hi again, One minor thing to note - because we rely on GPhoto to do the actual work of communicating with a camera, if GPhoto can't delete an image from a particular device, than neither can we, so this may not work equally well on all devices. On 11/04/2013, Clint Rogers wrote: > Hi Richard, > >> Is there any improvement in latest versions with emptying the wastebasket >> in Shotwell? > > As luck would have it, we've been having some discussions about > profiling and optimization here recently, and although no work was > done directly on moving to the trash as such, I can tell you that > we're currently focusing on exactly the type of performance problem > you've noted. > > I wonder if it's something akin to the performance problems detailed > in http://redmine.yorba.org/issues/979... > >> Which brings me to real use cases with Shotwell and suggestion for >> impovement >> >> Its typical with modern DSLR cameras to fire off hundreds of shots. 99% >> will be deleted before any processing. >> >> Suggestion #1 : allow "delete" from the preview image in the shotwell >> app. > > This makes sense; I'll ticket it right away. > >> Suggestion #2 : allow complete bypass of the slightly convoluted >> wastebasket.Simply put the original image directly in the trash can or >> "hard delete" immediately depending on a setting. No DB access at all. > If I'm understanding this correctly, rather than have Shotwell's > internal wastebasket as a tier above your desktop's, you'd rather just > use your desktop's wastebasket directly. A setting seems like it > might confuse some less-savvy users - would it be better to have, say, > Shift+Delete or holding Shift when adding something to Shotwell's > trash? (This key combination seems to be fairly common among other > Linux programs, does about the same thing, and, as such, would be > least likely to negatively surprise or confuse people.) > > Either way, though, I'll add a feature request for an insta-trash as > well, and we can talk about the UI as we work on it. > >> This will also not leave the user sat there for 15 minutes twiddling the >> thumb > This seems like the crux of the matter here - simply trashing a group > of files should NOT take terribly long, and while there is going to be > a little per-file overhead, as you might expect, we feel that it could > be far better than it is at the moment. > > >> Thanks a lot >> >> Except for the long delay in wastebasket and frequent freeze when writing >> metadata (at 99%) > Are you on the version that comes with a new install of Wheezy by > default (0.12.3)? Metadata writing should be dramatically improved in > 0.13 and beyond; if you're seeing this in something later than 0.12.x, > then it's a regression, and we'd like to know about it. > >> its generally a joy to use shotwell. Keep up the good >> work. > We do try, and it's exactly these kinds of compliments and words of > encouragement that make it worthwhile. > > Thanks for bringing these issues to our attention. > > Cheers, > -c > > -- > --------------------------- > "I don't know what (b? - 4ac) equals, and I don't care," Tom said > indiscriminately. > -- --------------------------- "I don't know what (b? - 4ac) equals, and I don't care," Tom said indiscriminately. From lucas at yorba.org Fri Apr 12 18:47:45 2013 From: lucas at yorba.org (Lucas Beeler) Date: Fri, 12 Apr 2013 11:47:45 -0700 Subject: [Shotwell] remake the thumbs from the files possible? In-Reply-To: <1365762839.10877.7.camel@sk-MS-7368> References: <1365711355.2697.5.camel@sk-MS-7368> <1365762839.10877.7.camel@sk-MS-7368> Message-ID: Hi Siegfied, > But, -but the recreating of the thumbs > does not happen in one sweep, > -shotwell stops first after 200 thumbs > ( I have around over 19000 fotos > and videos), the only way to convince > shotwell it should continue to > work is to click one of the blank thumbs. All you should have to do is scroll the blank thumbnails into view and then wait. Shotwell will automatically enqueue background tasks to thumbnail the photos. Unfortunately, for a 19000 photo library, this is going to take a while. Large RAW photos easily require 5 seconds to thumbnail. Videos can require a similar amount of time. If half of the media items in your library are RAWs and/or videos, we're talking 9500 * 5 = 47500 seconds = 792 minutes = 13 hours. My belief is that if you wait long enough, you should be okay. Take care, Lucas On Fri, Apr 12, 2013 at 3:33 AM, Siegfried Kaiser wrote: > Hi Lucas, > I have followed Your advice and updated to 0.14.0, ( I am running Ubuntu > 12.04) and deleted the .cache/shotwell directory - it is better now, > because I had blank thumbs instead of wrong ones. > But, -but the recreating of the thumbs does not happen in one sweep, > -shotwell stops first after 200 thumbs( I have around over 19000 fotos > and videos), the only way to convince shotwell it should continue to > work is to click one of the blank thumbs. > Did I do something wrong or is it a feature? > > Thanks > > Siegfried > Am Donnerstag, den 11.04.2013, 14:03 -0700 schrieb Lucas Beeler: > > Hi Siegfried, > > > > What version of Shotwell are you running? If you're running Shotwell > > 0.14.0 or later, you can simply delete your ~/.cache/shotwell > > directory while Shotwell isn't running and then restart Shotwell. > > Thumbnails will then be regenerated. Depending on how many photos you > > have, it might take a while. Note that removing the thumbnail cache > > directory will have no effect on your tags, events, or anything else. > > Shotwell 0.14.0 and later were designed under the assumption that > > because it's a cache directory, its contents could disappear at any > > time. > > > > Cheers, > > Lucas > > > > > > > > On Thu, Apr 11, 2013 at 1:15 PM, Siegfried Kaiser > > wrote: > > Hello all, > > > > I have a little problem with my shotwell data : I had to copy > > the files > > from one disk to another and seem to have forgotten the > > thumbnails. So I > > have following problem: I have consistently a wrong thumbnail > > for my > > images. When I search for a tag, I get the correct number of > > wrong > > thumbnails, when I click on a thumbnail I get the correct > > image file - > > there is no problem. > > Is there an easy way to generate the correct thumbs? - I do > > not want to > > throw away my tags, they still work correctly but is a bit > > frustrating > > to have to click first to get the correct image when I have > > searched for > > a tag. > > > > Thanks, > > Siegfried > > > > _______________________________________________ > > Shotwell mailing list > > Shotwell at lists.yorba.org > > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > > > > > > From joseph.bylund at gmail.com Fri Apr 12 22:21:04 2013 From: joseph.bylund at gmail.com (Joseph Bylund) Date: Fri, 12 Apr 2013 18:21:04 -0400 Subject: [Shotwell] Raw Imports with Camera Developer are LibRaw Bound Message-ID: <516888D0.9020103@gmail.com> Hi all, I did a little experimentation with profiling raw imports (you can find an example sysprof profile here: http://ubuntuone.com/6PrDbY32fdP2QXT2g8LSbf). And found that libraw is actually the limiting factor during imports while using the camera developer (probably 75%+ of time). Is it reasonable to file a bug against slow importing? thanks, -Joe From lucas at yorba.org Fri Apr 12 22:33:49 2013 From: lucas at yorba.org (Lucas Beeler) Date: Fri, 12 Apr 2013 15:33:49 -0700 Subject: [Shotwell] Raw Imports with Camera Developer are LibRaw Bound In-Reply-To: <516888D0.9020103@gmail.com> References: <516888D0.9020103@gmail.com> Message-ID: I've seem similar behavior so I opened up a bug report here: http://redmine.yorba.org/issues/6812. Feel free to add your own comments! Cheers, Lucas On Fri, Apr 12, 2013 at 3:21 PM, Joseph Bylund wrote: > Hi all, > > I did a little experimentation with profiling raw imports (you can find an > example sysprof profile here: http://ubuntuone.com/** > 6PrDbY32fdP2QXT2g8LSbf ). > And found that libraw is actually the limiting factor during imports while > using the camera developer (probably 75%+ of time). Is it reasonable to > file a bug against slow importing? > > thanks, > -Joe > ______________________________**_________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-**bin/mailman/listinfo/shotwell > From sf.rique at gmail.com Sat Apr 13 01:54:17 2013 From: sf.rique at gmail.com (Henrique Santos Fernandes) Date: Fri, 12 Apr 2013 22:54:17 -0300 Subject: [Shotwell] Shotwell 0.14.0 Released In-Reply-To: References: Message-ID: Thanks! I keep a close look. I think shotwell is by far the best for linux. Only missing vide metadata and face detection/recognize ( i know about the facetools ) []'sf.rique On Wed, Mar 27, 2013 at 5:07 PM, Lucas Beeler wrote: > Hi Henrique, > > > The video metadata can now be save in the video file? > > Alas, there are no changes to video metadata handling in Shotwell > 0.14, so Shotwell does not write any metadata changes to the video > container files. This is something that we do want to do. About a year > ago, it seemed virtually impossible, but now that GStreamer 1.0 has > been released, we may be able to manipulate video data effectively. > Stay tuned for this feature in a future release of Shotwell! > > Cheers, > Lucas > > On Tue, Mar 26, 2013 at 9:10 PM, Henrique Santos Fernandes > wrote: > > Hello, > > > > I know from previuls realeases that the tags and stuff are save only on > the > > image files, on videos files it all stays on shotwell database. > > > > The video metadata can now be save in the video file? So we can only > > backup the files and not the database or share this tags in other > programs. > > > > Thanks! > > > > > > []'sf.rique > > > > > > On Wed, Mar 20, 2013 at 3:54 PM, Lucas Beeler wrote: > > > >> > I did have to add the gstreamer > >> > developers ppa (ppa:gstreamer- > >> > developers/ppa) in order to get > >> > gstreamer 1.0 for Precise. Was > >> > that the right thing to do? > >> > >> That was indeed the right thing to do! I'm calling it out here so that > >> other users take note. Thanks for mentioning this! > >> > >> Lucas > >> > >> On Wed, Mar 20, 2013 at 2:34 AM, Colin Law > wrote: > >> > On 19 March 2013 23:20, Lucas Beeler wrote: > >> >> Hi Colin, > >> >> > >> >> Sorry about the broken Precise build. We just fixed it and our PPA > >> >> should be ready and waiting for you to upgrade Shotwell! > >> > > >> > Many thanks, all working now. I did have to add the gstreamer > >> > developers ppa (ppa:gstreamer-developers/ppa) in order to get > >> > gstreamer 1.0 for Precise. Was that the right thing to do? > >> > > >> > Colin > >> > > >> >> > >> >> Lucas > >> >> > >> >> On Tue, Mar 19, 2013 at 8:17 AM, Colin Law > >> wrote: > >> >>> On 19 March 2013 13:51, Colin Law wrote: > >> >>>> On 19 March 2013 10:13, Colin Law wrote: > >> >>>>> On 19 March 2013 00:16, Clint Rogers wrote: > >> >>>>>> Dood evening, one and all, > >> >>>>>> > >> >>>>>> It's my privelege to announce the release of Shotwell 0.14; the > >> >>>>>> download, as well as installation instructions are available at > >> >>>>>> http://yorba.org/shotwell/install.html, and Ubuntu users may > get it > >> >>>>>> from our PPA at https://launchpad.net/~yorba/+archive/ppa. > >> >>>>>> Among the many enhancements and fixes this release brings are: > >> >>>>> > >> >>>>> On 12.04 (32 bit), with the ppa enabled, sudo apt-get update && > sudo > >> >>>>> apt-get dist-upgrade is not giving me shotwell 0.14. > >> >>> > >> >>> csola48 has pointed out there were build failures on the build for > >> Precise: > >> >>> Packages in ?yorba?: > >> >>> shotwell - 0.14.0-1~precise1 (changes file) lucas-yorba 17 > >> hours > >> >>> ago Published Precise Gnome There were *build > >> >>> failures. amd64 i386* > >> >>> > >> >>> Colin > >> >>> _______________________________________________ > >> >>> 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 thomas.moschny at gmail.com Sat Apr 13 18:40:03 2013 From: thomas.moschny at gmail.com (Thomas Moschny) Date: Sat, 13 Apr 2013 20:40:03 +0200 Subject: [Shotwell] Shotwell 0.14.1 is Here! In-Reply-To: References: <1365039152.19300.0.camel@localhost.localdomain> Message-ID: 2013/4/7 Thomas Moschny : > Shotwell 0.14.1 has been built for Rawhide and Fedora 19. Not sure yet > if we will also update the Fedora 18 package. Shotwell 0.14.1 is now in Fedora 18's updates-testing repository, see https://admin.fedoraproject.org/updates/FEDORA-2013-5458 . Whether it should be pushed to updates-stable or not seems to be a bit controversial though. So it would be nice if you could test and vote for it. -- Thomas From lucas at yorba.org Mon Apr 15 19:16:11 2013 From: lucas at yorba.org (Lucas Beeler) Date: Mon, 15 Apr 2013 12:16:11 -0700 Subject: [Shotwell] Fast (?) question In-Reply-To: References: Message-ID: Hi Michael, First, good luck on your master's thesis work! We're really happy that Shotwell can be used as a shell to help you with your work! You wrote: > My intention is to extract the info during > import and store it somewhere where it > will be available later on during the > slideshow. If I were to design this feature, here is what I would do. But, first, let me make sure that I understand the functionality you want. As I understand it, what you want is some packet of additional data (let's call it "computed image data") associated with each photo. This computed image data will be computed from the pixel values in the photo image, so this computation can only be done after the pixbuf for a photo becomes available. Later, this computed image data will be used to generate sound waveforms that will be played in a slideshow. So, if the above is what you are thinking of doing, here's how I would go about it. First, I would not touch BatchImport or any of the import subsystem. All of that code is complex, brittle, and is soon to be changed. It involves pools of worker threads that pass off partially imported photo information to other pools of worker threads. It's really not something you need to get into to do what you want. Instead, I would lazy-initialize the computed image data when needed. Once I had computed it, I would write it to a new column in the database so I wouldn't have to compute it again (I'm assuming computing it could be a somewhat lengthy process) for a given photo. Here's how I imagine the user interface would work. You select a bunch of photos and choose a new menu option called something like "Play Slideshow with Sounds." When the user chooses this menu option, check to see if every selected photo already has sound data computed for it. If one or more photos doesn't have sound data computed for them, pop up a progress dialog box that says "Please wait. Computing sound data" and then compute the sound data. When you're done computing the sound data, write it to the database so it doesn't have to be computed again, and then start the slideshow with sounds. Why do I recommend doing it this way? Because if you do it the way I've described it above, you have effectively added a new feature to Shotwell that is not dependent on Shotwell itself. Think about it. You've added a whole new menu option and a new action that's not really tied into any existing Shotwell subsystem. What this means is that as Shotwell changes, your sound generation code can remain pretty much the same. When Shotwell 0.15 comes out, you could easily rebase your sound generation code on top of Shotwell 0.15 since your sound generation code isn't closely coupled to Shotwell in any way. Note that if you try to wire your code into a fundamental Shotwell subsystem like batch import, your sound generation code may break whenever Shotwell changes. I hope this gives you some direction for how to proceed on your master's thesis work! Cheers, Lucas On Wed, Apr 10, 2013 at 12:06 AM, Katachanas Michael wrote: > Hi Lucas, > > Many many thanks for your reply. > > My intention is to extract the info during import and store it somewhere > where it will be available later on during the slideshow. > I have given it a thought and maybe my best bet would be to place the code > right after successful import (in batchimport? not very pretty). However, > it fits more inside each "xxxsupport" files (e.g. jfifsupport.vala). Reason > is that I want the new code be format-independent. > > Great job you guys have done there with Shotwell's code by the way. > > Thanks again, > Kind Regards, > michael > > > > > On Wed, Apr 10, 2013 at 2:51 AM, Lucas Beeler wrote: > >> > I am trying to extract some additional >> > data from photos. These, later during >> > slide show, will be sent to another >> > program to generate sounds. >> >> When do you want to extract this information? When photos are initially >> imported, or later via some kind of explicit command? >> >> Lucas >> >> >> On Sun, Apr 7, 2013 at 4:27 AM, Katachanas Michael wrote: >> >>> Hi Lucas, >>> >>> Sorry for bothering you. I am modifying Shotwell a little bit in the >>> scope of my MSc essay. >>> >>> I am trying to extract some additional data from photos. These, later >>> during slide show, will be sent to another program to generate sounds. >>> >>> Therefore, I need to run some algorithms on each photo's pixbuf and then >>> store the extracted data in params.row. >>> >>> Tried doing this within the sniffers/detection side (e.g.: in >>> JfifSupport). Problem is that I have only the 'file' information available >>> there and could not figure out how to use it in order to gain access to the >>> photo pixbuf (tried some stupid workarounds creating a temp photo object >>> inside sniffer but ended up with recursive importing loops). >>> >>> Adding it in Photo.vala seems also reasonable but the points which >>> appear fit (--> have visibility of params.row e.g. in prepare_for_import) >>> are *static* which causes problem with the methods I need to use. >>> >>> I would be really grateful if you could provide me with a hint or a >>> suggestion as of how I could implement this. >>> >>> (Did not want to place this question to the Yorba forum since it is >>> totally irrelevant to the standard functionality of Shotwell). >>> >>> Thanks a lot in advance, >>> Kind Regards, >>> Michael >>> >>> PS1.: please bare with me if I am talking nonsense when it comes to an >>> object oriented concept. This is the first time I am seriously working with >>> an OO language. >>> >>> PS2.: My occupation is telecom engineer in 2G, 3G, 4G Networks. >>> >> >> > From jim at yorba.org Mon Apr 15 19:47:48 2013 From: jim at yorba.org (Jim Nelson) Date: Mon, 15 Apr 2013 14:47:48 -0500 Subject: [Shotwell] Shotwell 0.14.1 is Here! In-Reply-To: References: <1365039152.19300.0.camel@localhost.localdomain> Message-ID: Shotwell 0.14 does include feature additions, but the majority of the work is bug fixes, as we wanted to give our users a more stable experience, especially with video and RAW+JPEG support. When is Fedora 19 planned to be released? Did the delay in Fedora 18 push it out, or will Fedora return to a release cycle closer to GNOME's in this next release? -- Jim On Sat, Apr 13, 2013 at 1:40 PM, Thomas Moschny wrote: > 2013/4/7 Thomas Moschny : > > Shotwell 0.14.1 has been built for Rawhide and Fedora 19. Not sure yet > > if we will also update the Fedora 18 package. > > Shotwell 0.14.1 is now in Fedora 18's updates-testing repository, see > https://admin.fedoraproject.org/updates/FEDORA-2013-5458 . Whether it > should be pushed to updates-stable or not seems to be a bit > controversial though. So it would be nice if you could test and vote > for it. > > -- Thomas > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From schuetz.marc at gmx.de Thu Apr 18 07:31:20 2013 From: schuetz.marc at gmx.de (Marc) Date: Thu, 18 Apr 2013 09:31:20 +0200 Subject: [Shotwell] Fwd: Shotwell 0.14.1 is Here! In-Reply-To: References: <1365039152.19300.0.camel@localhost.localdomain> <51657E54.4040804@gmx.de> <5165AC43.3020906@gmx.de> <5165AD3A.9030906@gmail.com> <5165C2C5.3010901@gmx.de> Message-ID: <516FA148.9080109@gmx.de> Hi Clint, no didn't get such corruption in firefox/scrolling in any of my machines. Everything is fine so far. Norbert posted his images, his artefacts are on the bottom, I get such artefacts on the right-side only. Norbert, I don't think that this is x-related, I'm not a xorg-technical, but could this be related to newest mesa packages? which one are you using in debian? ii libgl1-mesa-glx 9.2.0~git20130404+9.1.980f84c3-0ubuntu0ricotz~precise free implementation of the OpenGL API -- GLX runtime kind regards Marc Am 10.04.2013 21:57, schrieb Clint Rogers: > Apologies, I left the list out of the loop... > > ---------- Forwarded message ---------- > From: Clint Rogers > Date: 10 April 2013 15:56 > Subject: Re: [Shotwell] Shotwell 0.14.1 is Here! > To: Marc > > > Marc, > > This is very much like the graphical corruption I've seen (although I'm not > xorg-edgers). Do you get, say, black horizontal bars across text if you > scroll quickly in Firefox? > > If so, I'd feel a bit more confident in blaming the graphics drivers at > this point. > > Cheers, > -c > > > On 10 April 2013 15:51, Marc wrote: > >> Hi Clinton, Hi Joe, Hi all >> >> that was good point for me to check because I'm using a >> Beta-graphicsdriver one of my machine. >> >> So I started up my laptop with Intel HD graphic, copied db+cache and >> started shotwell. >> But the error exists on both :-( >> >> http://img839.imageshack.us/img839/6615/shotwellshadow.png >> >> here you can see the border from good shadow, to bad shadow. >> >> If anyone experience the same it would be nice to compare our systems. >> Because - Don laugh pls ;-) - I'm using the xorg-edgers on both ubuntu >> 12.04 64bit machines. >> Everything, sure, everything is stable for me. One with Amd-Card, the >> other with intel hd graphic. >> >> So if noone uses xorg-edgers and don experience this problem it should >> be based there. But I? nearly unable to purge the ppa on both at the >> moment. Will try to check an VMinstall if I find any time. >> >> thanks and kind regards >> Marc >> >> >> >> Am 10.04.2013 20:36, schrieb Clint Rogers: >>> Good morning all, >>> >>> To chime in here, Marc, are you, by any chance, running on a machine with >>> Intel GMA 915, GMA 945 or similar >>> graphics hardware? On my work desktop (GMA 945), I have occasionally >> seen >>> crazily-coloured shadows in Shotwell before, but this usually occurred >>> alongside visual glitches in other applications as well, leading me to >>> believe it was some kind of hardware or driver problem (I've seen it in >>> multiple distros, across multiple window managers, and with multiple >>> compositors). >>> >>> At any rate, if you could get a screenshot as well as post your system >>> specs, that may help us pin down what's happening, and whether it's a >>> problem in Shotwell, or some other component. >>> >>> Cheers, >>> -c >>> >>> >>> On 10 April 2013 14:19, Joseph Bylund wrote: >>> >>>> Marc, >>>> Any chance you can grab a screenshot of the incorrect state? Is there >>>> already a bug report for this? >>>> -Joe >>>> >>>> >>>> On 04/10/2013 02:15 PM, Marc wrote: >>>> >>>>> Hi all, >>>>> >>>>> I notice that a Bug from 0.13trunk still exist (for me?) in 0.14.1 >>>>> When Im' at the Library all Photos have a shadow, when I'm sroll down >>>>> >>>>> some hundred of photos then the shadow of all photos become pixel from >>>>> other pictures. >>>>> So that there is no normal grey/black shadow every shadow becomes >> colored. >>>>> >>>>> When Im' scrolling up again, the newest photos were displyed correct >>>>> >>>>> again. So there seems to be a border. >>>>> >>>>> Anyone else who experience some an issue? >>>>> >>>>> >>>>> thanks and kind regards >>>>> Marc >>>>> >>>>> >>>>> >>>>> >>>>> ______________________________**_________________ >>>>> Shotwell mailing list >>>>> Shotwell at lists.yorba.org >>>>> http://lists.yorba.org/cgi-**bin/mailman/listinfo/shotwell< >> 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< >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell> >>>> >>> >>> >>> >> >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 555 bytes Desc: OpenPGP digital signature URL: From preining at logic.at Thu Apr 18 15:38:21 2013 From: preining at logic.at (Norbert Preining) Date: Fri, 19 Apr 2013 00:38:21 +0900 Subject: [Shotwell] Fwd: Shotwell 0.14.1 is Here! In-Reply-To: <516FA148.9080109@gmx.de> References: <51657E54.4040804@gmx.de> <5165AC43.3020906@gmx.de> <5165AD3A.9030906@gmail.com> <5165C2C5.3010901@gmx.de> <516FA148.9080109@gmx.de> Message-ID: <20130418153821.GJ6107@gamma.logic.tuwien.ac.at> On Do, 18 Apr 2013, Marc wrote: > no didn't get such corruption in firefox/scrolling in any of my > machines. Everything is fine so far. Here, too, only Shotwell. > Norbert posted his images, his artefacts are on the bottom, I get such > artefacts on the right-side only. I get also artefacts on the right side, sometimes a white line. They are not always the same. > Norbert, I don't think that this is x-related, I'm not a > xorg-technical, but could this be related to newest mesa packages? which > one are you using in debian? > ii libgl1-mesa-glx > 9.2.0~git20130404+9.1.980f84c3-0ubuntu0ricotz~precise > free implementation of the OpenGL API -- GLX runtime I have a much older version: 8.0.5-4 of libgl1-mesa-glx, so I don't think that this is the reason. Norbert ------------------------------------------------------------------------ PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ------------------------------------------------------------------------ From roywig at gmail.com Mon Apr 22 05:53:06 2013 From: roywig at gmail.com (Roy Wiggins) Date: Mon, 22 Apr 2013 00:53:06 -0500 Subject: [Shotwell] Missing Photos don't rescan properly Message-ID: So, I'm having a problem in 0.14 under Ubuntu (and previous versions)- it doesn't re-find missing photos properly. If I start up Shotwell with my external drive unplugged, it (of course) realizes it can't actually find the photos on it, and removes them. The problem is, when I mount the drive, close shotwell and re-open it, it looks like it's scanning to see if they've come back... and doesn't find any of them, silently stops scanning and leaves me with an empty library. They are, however, all there and visible to Nautilus, etc in the same place that the extended information dialog says they should be. I'd love to be able to simply turn off this feature, but I'd settle for the re-scan to actually work and repatriate my photos. Can I flip a toggle in the database "by hand' to mark them "present"? Right now my photos are all in purgatory: present, but I can't do anything with them in Shotwell. Oddly, the "remove from library" button is *also* greyed out on the 'missing' photos. P.S: My ~/.shotwell directory is... not there anymore, after upgrading to 0.14. Though my library seems to be still somewhere, because it knows about all my missing photos. Where did it go?! From thomas at xyz.pp.se Mon Apr 22 07:32:59 2013 From: thomas at xyz.pp.se (Thomas Novin) Date: Mon, 22 Apr 2013 09:32:59 +0200 Subject: [Shotwell] Missing Photos don't rescan properly In-Reply-To: References: Message-ID: On Mon, Apr 22, 2013 at 7:53 AM, Roy Wiggins wrote: > P.S: My ~/.shotwell directory is... not there anymore, after upgrading to > 0.14. Though my library seems to be still somewhere, because it knows about > all my missing photos. Where did it go?! > Explained in the FAQ; http://redmine.yorba.org/projects/shotwell/wiki/ShotwellFAQ From preining at logic.at Mon Apr 22 08:05:34 2013 From: preining at logic.at (Norbert Preining) Date: Mon, 22 Apr 2013 17:05:34 +0900 Subject: [Shotwell] Fwd: Shotwell 0.14.1 is Here! In-Reply-To: <20130418153821.GJ6107@gamma.logic.tuwien.ac.at> References: <51657E54.4040804@gmx.de> <5165AC43.3020906@gmx.de> <5165AD3A.9030906@gmail.com> <5165C2C5.3010901@gmx.de> <516FA148.9080109@gmx.de> <20130418153821.GJ6107@gamma.logic.tuwien.ac.at> Message-ID: <20130422080534.GA9203@gamma.logic.tuwien.ac.at> On Fr, 19 Apr 2013, Norbert Preining wrote: > > Norbert posted his images, his artefacts are on the bottom, I get such > > artefacts on the right-side only. > > I get also artefacts on the right side, sometimes a white line. > They are not always the same. Attached is another screenshot ... actually the shadows on the bottom are moving/changing - a bit The Matrix style ;-) Norbert ------------------------------------------------------------------------ PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ------------------------------------------------------------------------ From preining at logic.at Mon Apr 22 08:07:25 2013 From: preining at logic.at (Norbert Preining) Date: Mon, 22 Apr 2013 17:07:25 +0900 Subject: [Shotwell] Fwd: Shotwell 0.14.1 is Here! In-Reply-To: <20130422080534.GA9203@gamma.logic.tuwien.ac.at> References: <5165AC43.3020906@gmx.de> <5165AD3A.9030906@gmail.com> <5165C2C5.3010901@gmx.de> <516FA148.9080109@gmx.de> <20130418153821.GJ6107@gamma.logic.tuwien.ac.at> <20130422080534.GA9203@gamma.logic.tuwien.ac.at> Message-ID: <20130422080725.GB9203@gamma.logic.tuwien.ac.at> On Mo, 22 Apr 2013, Norbert Preining wrote: > > > Norbert posted his images, his artefacts are on the bottom, I get such > > > artefacts on the right-side only. > > > > I get also artefacts on the right side, sometimes a white line. > > They are not always the same. > > Attached is another screenshot ... actually the shadows on the bottom > are moving/changing - a bit The Matrix style ;-) Got lost it seems ... http://www.preining.info/shotwell-shadows2.png Norbert ------------------------------------------------------------------------ PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ------------------------------------------------------------------------ From preining at logic.at Mon Apr 22 08:31:51 2013 From: preining at logic.at (Norbert Preining) Date: Mon, 22 Apr 2013 17:31:51 +0900 Subject: [Shotwell] Slow Import with many duplicates... In-Reply-To: References: <20130410033217.GC5145@gamma.logic.tuwien.ac.at> Message-ID: <20130422083151.GD9203@gamma.logic.tuwien.ac.at> Hi Lucas, sorry for the late reply, I was somewhere between Europe and Japan ... On Do, 11 Apr 2013, Lucas Beeler wrote: > Is your import from devices slow even when there are no duplicates present? I moved away my shotwell folders (in .cache and .local/share) and restarted shotwell, importing from the card, and that worked without any problem, very quick. Importing direct into the full library of 8 photos worked till all the 8 photos flashed by on the screen, and then shotwell got stuck badly at 100% CPU and no reaction. I had to kill it. (30000+ photos in shotwell) > We know of an issue involving duplicates ( It seems that this is the reason ... but not only. Why would an import from folder into the full library be so blazingly fast ... is there no duplicate check done I assume. If this is the case, then yes. > Curiously, does import speed seem in any way proportional to the number of > photos you have in your library? If you've got an empty library, is import > faster than in your personal photo library with (I'm guessing) thousands of > photos? I ask because a slowdown proportional to library size suggests that > the duplicate detection code path might be involved. Yes, I have this feeling. I will also play around with the profiling code. BTW, where is the duplication code (in the source code), I can look into the actual code, too?! Norbert ------------------------------------------------------------------------ PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ------------------------------------------------------------------------ From jim at yorba.org Mon Apr 22 18:15:31 2013 From: jim at yorba.org (Jim Nelson) Date: Mon, 22 Apr 2013 18:08:31 -0007 Subject: [Shotwell] Fwd: Shotwell 0.14.1 is Here! In-Reply-To: <20130422080725.GB9203@gamma.logic.tuwien.ac.at> References: <5165AC43.3020906@gmx.de> <5165AD3A.9030906@gmail.com> <5165C2C5.3010901@gmx.de> <516FA148.9080109@gmx.de> <20130418153821.GJ6107@gamma.logic.tuwien.ac.at> <20130422080534.GA9203@gamma.logic.tuwien.ac.at> <20130422080725.GB9203@gamma.logic.tuwien.ac.at> Message-ID: <51757e47.4209440a.1469.ffff8307@mx.google.com> Norbert, the URL gives a 404. ?Can you try again? -- Jim On Mon, Apr 22, 2013 at 1:07 AM, Norbert Preining wrote: > On Mo, 22 Apr 2013, Norbert Preining wrote: >> > > Norbert posted his images, his artefacts are on the bottom, I >> get such >> > > artefacts on the right-side only. >> > >> > I get also artefacts on the right side, sometimes a white line. >> > They are not always the same. >> >> Attached is another screenshot ... actually the shadows on the >> bottom >> are moving/changing - a bit The Matrix style ;-) >> > Got lost it seems ... > http://www.preining.info/shotwell-shadows2.png > > > > Norbert > > ------------------------------------------------------------------------ > PREINING, Norbert > http://www.preining.info > JAIST, Japan TeX Live & Debian > Developer > DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 > B094 > ------------------------------------------------------------------------ > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From lucas at yorba.org Mon Apr 22 18:35:32 2013 From: lucas at yorba.org (Lucas Beeler) Date: Mon, 22 Apr 2013 11:35:32 -0700 Subject: [Shotwell] Slow Import with many duplicates... In-Reply-To: <20130422083151.GD9203@gamma.logic.tuwien.ac.at> References: <20130410033217.GC5145@gamma.logic.tuwien.ac.at> <20130422083151.GD9203@gamma.logic.tuwien.ac.at> Message-ID: Hi Norbert, > BTW, where is the duplication > code (in the source code), I can > look into the actual code, too?! The best place to start examining the import code is by reading through BatchImport.vala. Now, I freely admit that this source file is complicated and a little convoluted, but Jim wrote very clear and informative comments that explain what's going on. If you spend some time reading through the file, I think you'll be able to pick up the basics of how import works rather quickly. Lucas On Mon, Apr 22, 2013 at 1:31 AM, Norbert Preining wrote: > Hi Lucas, > > sorry for the late reply, I was somewhere between Europe and Japan ... > > On Do, 11 Apr 2013, Lucas Beeler wrote: > > Is your import from devices slow even when there are no duplicates > present? > > I moved away my shotwell folders (in .cache and .local/share) and > restarted shotwell, importing from the card, and that worked without > any problem, very quick. > > Importing direct into the full library of 8 photos worked till all > the 8 photos flashed by on the screen, and then shotwell got stuck > badly at 100% CPU and no reaction. I had to kill it. > (30000+ photos in shotwell) > > > We know of an issue involving duplicates ( > > It seems that this is the reason ... but not only. > > Why would an import from folder into the full library be so blazingly > fast ... is there no duplicate check done I assume. If this is the > case, then yes. > > > Curiously, does import speed seem in any way proportional to the number > of > > photos you have in your library? If you've got an empty library, is > import > > faster than in your personal photo library with (I'm guessing) thousands > of > > photos? I ask because a slowdown proportional to library size suggests > that > > the duplicate detection code path might be involved. > > Yes, I have this feeling. > > I will also play around with the profiling code. > > BTW, where is the duplication code (in the source code), I can look > into the actual code, too?! > > Norbert > > ------------------------------------------------------------------------ > PREINING, Norbert http://www.preining.info > JAIST, Japan TeX Live & Debian Developer > DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 > ------------------------------------------------------------------------ > From preining at logic.at Mon Apr 22 21:23:51 2013 From: preining at logic.at (Norbert Preining) Date: Tue, 23 Apr 2013 06:23:51 +0900 Subject: [Shotwell] Fwd: Shotwell 0.14.1 is Here! In-Reply-To: <51757e47.4209440a.1469.ffff8307@mx.google.com> References: <5165AD3A.9030906@gmail.com> <5165C2C5.3010901@gmx.de> <516FA148.9080109@gmx.de> <20130418153821.GJ6107@gamma.logic.tuwien.ac.at> <20130422080534.GA9203@gamma.logic.tuwien.ac.at> <20130422080725.GB9203@gamma.logic.tuwien.ac.at> <51757e47.4209440a.1469.ffff8307@mx.google.com> Message-ID: <20130422212351.GA3375@gamma.logic.tuwien.ac.at> On Mo, 22 Apr 2013, Jim Nelson wrote: > Norbert, the URL gives a 404. ?Can you try again? Ugg, sorry, typo http://www.preining.info/shotwell-shadow2.png > Attached is another screenshot ... actually the shadows on the bottom > are moving/changing - a bit The Matrix style ;-) Norbert ------------------------------------------------------------------------ PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ------------------------------------------------------------------------ From roywig at gmail.com Mon Apr 22 21:50:20 2013 From: roywig at gmail.com (Roy Wiggins) Date: Mon, 22 Apr 2013 16:50:20 -0500 Subject: [Shotwell] Missing Photos don't rescan properly In-Reply-To: References: Message-ID: Aha, there it is. I tried setting the "flags" field to 0 (they were all 8) in the database by hand, and my photos all reappear, but most events are gone and the photos only show up in the whole-library view. So I'm still stuck. On Mon, Apr 22, 2013 at 2:32 AM, Thomas Novin wrote: > On Mon, Apr 22, 2013 at 7:53 AM, Roy Wiggins wrote: > >> P.S: My ~/.shotwell directory is... not there anymore, after upgrading to >> 0.14. Though my library seems to be still somewhere, because it knows >> about >> all my missing photos. Where did it go?! >> > > Explained in the FAQ; > http://redmine.yorba.org/projects/shotwell/wiki/ShotwellFAQ > From jim at yorba.org Mon Apr 22 23:32:17 2013 From: jim at yorba.org (Jim Nelson) Date: Mon, 22 Apr 2013 23:25:17 -0007 Subject: [Shotwell] Missing Photos don't rescan properly In-Reply-To: References: Message-ID: <5175c882.a433440a.7245.65e7@mx.google.com> Roy, when your photos disappear they should be located in a folder called "Missing Files" at the bottom of the left-hand sidebar. ?You can select the photos there. ?If you bring up View -> Extended Information, that will display where Shotwell thinks the file should be. ?Does that match Nautilus' location? -- Jim On Mon, Apr 22, 2013 at 2:50 PM, Roy Wiggins wrote: > Aha, there it is. I tried setting the "flags" field to 0 (they were > all 8) > in the database by hand, and my photos all reappear, but most events > are > gone and the photos only show up in the whole-library view. So I'm > still > stuck. > > On Mon, Apr 22, 2013 at 2:32 AM, Thomas Novin > wrote: > >> On Mon, Apr 22, 2013 at 7:53 AM, Roy Wiggins >> wrote: >> >>> P.S: My ~/.shotwell directory is... not there anymore, after >>> upgrading to >>> 0.14. Though my library seems to be still somewhere, because it >>> knows >>> about >>> all my missing photos. Where did it go?! >>> >>> >> Explained in the FAQ; >> http://redmine.yorba.org/projects/shotwell/wiki/ShotwellFAQ >> >> > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From roywig at gmail.com Tue Apr 23 00:30:06 2013 From: roywig at gmail.com (Roy Wiggins) Date: Mon, 22 Apr 2013 19:30:06 -0500 Subject: [Shotwell] Missing Photos don't rescan properly In-Reply-To: <5175c882.a433440a.7245.65e7@mx.google.com> References: <5175c882.a433440a.7245.65e7@mx.google.com> Message-ID: Yes, I checked that- they are there, in the missing files section, and the Extended Information shows the correct path. Of course they briefly weren't there: when I started up Shotwell without the external drive plugged in, but now it's mounted and everything's back as it was. It's as if Shotwell isn't properly rescanning the missing files, though it does briefly say "updating library" or similar, and then it seems to finish updating, but all my photos are still listed as Missing. On Mon, Apr 22, 2013 at 6:32 PM, Jim Nelson wrote: > Roy, when your photos disappear they should be located in a folder called > "Missing Files" at the bottom of the left-hand sidebar. You can select the > photos there. If you bring up View -> Extended Information, that will > display where Shotwell thinks the file should be. Does that match > Nautilus' location? > > -- Jim > > > On Mon, Apr 22, 2013 at 2:50 PM, Roy Wiggins wrote: > > Aha, there it is. I tried setting the "flags" field to 0 (they were all 8) > in the database by hand, and my photos all reappear, but most events are > gone and the photos only show up in the whole-library view. So I'm still > stuck. On Mon, Apr 22, 2013 at 2:32 AM, Thomas Novin > wrote: > > On Mon, Apr 22, 2013 at 7:53 AM, Roy Wiggins wrote: > > P.S: My ~/.shotwell directory is... not there anymore, after upgrading to > 0.14. Though my library seems to be still somewhere, because it knows about > all my missing photos. Where did it go?! > > Explained in the FAQ; > http://redmine.yorba.org/projects/shotwell/wiki/ShotwellFAQ > > _______________________________________________ Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > > From jim at yorba.org Tue Apr 23 00:40:18 2013 From: jim at yorba.org (Jim Nelson) Date: Tue, 23 Apr 2013 00:33:18 -0007 Subject: [Shotwell] Missing Photos don't rescan properly In-Reply-To: References: <5175c882.a433440a.7245.65e7@mx.google.com> Message-ID: <5175d86f.a813420a.17c3.6014@mx.google.com> So if you copy the path in Extended Information and paste it into the console like this: $ file where, of course, path is the Shotwell path, do you see information about the file? -- Jim On Mon, Apr 22, 2013 at 5:30 PM, Roy Wiggins wrote: > Yes, I checked that- they are there, in the missing files section, > and the Extended Information shows the correct path. Of course they > briefly weren't there: when I started up Shotwell without the > external drive plugged in, but now it's mounted and everything's back > as it was. It's as if Shotwell isn't properly rescanning the missing > files, though it does briefly say "updating library" or similar, and > then it seems to finish updating, but all my photos are still listed > as Missing. > > On Mon, Apr 22, 2013 at 6:32 PM, Jim Nelson wrote: >> Roy, when your photos disappear they should be located in a folder >> called "Missing Files" at the bottom of the left-hand sidebar. ?You >> can select the photos there. ?If you bring up View -> Extended >> Information, that will display where Shotwell thinks the file should >> be. ?Does that match Nautilus' location? >> >> -- Jim >> >> >> On Mon, Apr 22, 2013 at 2:50 PM, Roy Wiggins >> wrote: >>> Aha, there it is. I tried setting the "flags" field to 0 (they were >>> all 8) >>> in the database by hand, and my photos all reappear, but most >>> events are >>> gone and the photos only show up in the whole-library view. So I'm >>> still >>> stuck. >>> >>> On Mon, Apr 22, 2013 at 2:32 AM, Thomas Novin >>> wrote: >>> >>>> On Mon, Apr 22, 2013 at 7:53 AM, Roy Wiggins >>>> wrote: >>>> >>>>> P.S: My ~/.shotwell directory is... not there anymore, after >>>>> upgrading to >>>>> 0.14. Though my library seems to be still somewhere, because it >>>>> knows >>>>> about >>>>> all my missing photos. Where did it go?! >>>>> >>>>> >>>> Explained in the FAQ; >>>> http://redmine.yorba.org/projects/shotwell/wiki/ShotwellFAQ >>>> >>>> >>> _______________________________________________ >>> Shotwell mailing list >>> Shotwell at lists.yorba.org >>> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >>> >> > > From roywig at gmail.com Tue Apr 23 00:52:04 2013 From: roywig at gmail.com (Roy Wiggins) Date: Mon, 22 Apr 2013 19:52:04 -0500 Subject: [Shotwell] Missing Photos don't rescan properly In-Reply-To: <5175d86f.a813420a.17c3.6014@mx.google.com> References: <5175c882.a433440a.7245.65e7@mx.google.com> <5175d86f.a813420a.17c3.6014@mx.google.com> Message-ID: Yeah, "JPEG image data, EXIF standard 2.21" like you'd expect. If I clear the flags field and reload Shotwell, I can view my images just fine (not just the thumbnails, so they really are there), but the events are mostly missing (the pictures *are* all there, in the Library view, but the events are missing). On Mon, Apr 22, 2013 at 7:40 PM, Jim Nelson wrote: > So if you copy the path in Extended Information and paste it into the > console like this: > > $ file > > where, of course, path is the Shotwell path, do you see information about > the file? > > -- Jim > > > On Mon, Apr 22, 2013 at 5:30 PM, Roy Wiggins wrote: > > Yes, I checked that- they are there, in the missing files section, and the > Extended Information shows the correct path. Of course they briefly weren't > there: when I started up Shotwell without the external drive plugged in, > but now it's mounted and everything's back as it was. It's as if Shotwell > isn't properly rescanning the missing files, though it does briefly say > "updating library" or similar, and then it seems to finish updating, but > all my photos are still listed as Missing. > > On Mon, Apr 22, 2013 at 6:32 PM, Jim Nelson wrote: > >> Roy, when your photos disappear they should be located in a folder called >> "Missing Files" at the bottom of the left-hand sidebar. You can select the >> photos there. If you bring up View -> Extended Information, that will >> display where Shotwell thinks the file should be. Does that match >> Nautilus' location? >> >> -- Jim >> >> >> On Mon, Apr 22, 2013 at 2:50 PM, Roy Wiggins wrote: >> >> Aha, there it is. I tried setting the "flags" field to 0 (they were all >> 8) in the database by hand, and my photos all reappear, but most events are >> gone and the photos only show up in the whole-library view. So I'm still >> stuck. On Mon, Apr 22, 2013 at 2:32 AM, Thomas Novin >> wrote: >> >> On Mon, Apr 22, 2013 at 7:53 AM, Roy Wiggins wrote: >> >> P.S: My ~/.shotwell directory is... not there anymore, after upgrading to >> 0.14. Though my library seems to be still somewhere, because it knows about >> all my missing photos. Where did it go?! >> >> Explained in the FAQ; >> http://redmine.yorba.org/projects/shotwell/wiki/ShotwellFAQ >> >> _______________________________________________ Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >> >> > From jim at yorba.org Tue Apr 23 01:47:35 2013 From: jim at yorba.org (Jim Nelson) Date: Tue, 23 Apr 2013 01:40:35 -0007 Subject: [Shotwell] Fwd: Shotwell 0.14.1 is Here! In-Reply-To: <20130422212351.GA3375@gamma.logic.tuwien.ac.at> References: <5165AD3A.9030906@gmail.com> <5165C2C5.3010901@gmx.de> <516FA148.9080109@gmx.de> <20130418153821.GJ6107@gamma.logic.tuwien.ac.at> <20130422080534.GA9203@gamma.logic.tuwien.ac.at> <20130422080725.GB9203@gamma.logic.tuwien.ac.at> <51757e47.4209440a.1469.ffff8307@mx.google.com> <20130422212351.GA3375@gamma.logic.tuwien.ac.at> Message-ID: <5175e839.035a440a.7916.1fa1@mx.google.com> It really does look like a compositor or video driver problem. ?On Ubuntu there's the X.org Edger's PPA, which has latest-and-greatest drivers for a lot of video cards. ?Have you tried looking for newer drivers? ?Or, if they're open-source drivers, have you tried the closed source variety? ?Not that they need to stay installed, but it might give you a clue where the problem lies (and therefore who to report the problem to). -- Jim On Mon, Apr 22, 2013 at 2:23 PM, Norbert Preining wrote: > On Mo, 22 Apr 2013, Jim Nelson wrote: >> Norbert, the URL gives a 404. ?Can you try again? >> > Ugg, sorry, typo > http://www.preining.info/shotwell-shadow2.png > >> Attached is another screenshot ... actually the shadows on the >> bottom >> are moving/changing - a bit The Matrix style ;-) >> > Norbert > > ------------------------------------------------------------------------ > PREINING, Norbert > http://www.preining.info > JAIST, Japan TeX Live & Debian > Developer > DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 > B094 > ------------------------------------------------------------------------ > From vincentp at lankaz.net Tue Apr 23 18:51:20 2013 From: vincentp at lankaz.net ([Lankaz] Vincent Philippot) Date: Tue, 23 Apr 2013 20:51:20 +0200 Subject: [Shotwell] Shotwell and Owncloud Message-ID: <5176D828.4040508@lankaz.net> Hi Shotwell user for a few months. I wondered if it was intended to include exporting to Owncloud in the future. Sorry for my english and thank you for your work. Regards -- Vincent Philippot (+33) 06-50-21-86-11 vincentp at lankaz.net XMPP:vincentp at im.lankaz.net Site internet: http://www.lankaz.net From jim at yorba.org Tue Apr 23 21:08:09 2013 From: jim at yorba.org (Jim Nelson) Date: Tue, 23 Apr 2013 14:08:09 -0700 Subject: [Shotwell] Shotwell and Owncloud In-Reply-To: <5176D828.4040508@lankaz.net> References: <5176D828.4040508@lankaz.net> Message-ID: We don't have Owncloud support in Shotwell. We have a plugin system for uploading photos to various web services, and that would be the best way to implement it. I've ticketed it for reference: redmine.yorba.org/issues/6850 Shotwell's plugin system is documented at http://redmine.yorba.org/projects/shotwell/wiki/ShotwellArchWritingPlugins -- Jim On Tue, Apr 23, 2013 at 11:51 AM, [Lankaz] Vincent Philippot < vincentp at lankaz.net> wrote: > Hi > Shotwell user for a few months. I wondered if it was intended to include > exporting to Owncloud in the future. > > Sorry for my english and thank you for your work. > Regards > > -- > Vincent Philippot > (+33) 06-50-21-86-11 > vincentp at lankaz.net > XMPP:vincentp at im.lankaz.net > Site internet: http://www.lankaz.net > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From joseph.bylund at gmail.com Wed Apr 24 03:39:53 2013 From: joseph.bylund at gmail.com (Joseph Bylund) Date: Tue, 23 Apr 2013 23:39:53 -0400 Subject: [Shotwell] Shotwell and Owncloud In-Reply-To: <5176D828.4040508@lankaz.net> References: <5176D828.4040508@lankaz.net> Message-ID: <51775409.4030808@gmail.com> Vincent, In the meanwhile Owncloud supports a protocol named WebDAV, which actually allows you to mount your owncloud as a drive. Once you do that exporting a file from shotwell will "publish" to your owncloud. There's a bit of a walkthrough for mounting a webdav drive here: http://ubuntuforums.org/showthread.php?t=202761 , obviously this applies to box.net and not owndrive, but it should be pretty similar. And you can get your webdav address for your owncloud from the personal menu under your username in the upper right. hope that helps, -Joe On 04/23/2013 02:51 PM, [Lankaz] Vincent Philippot wrote: > Hi > Shotwell user for a few months. I wondered if it was intended to include > exporting to Owncloud in the future. > > Sorry for my english and thank you for your work. > Regards > From emailgrant at gmail.com Fri Apr 26 04:27:33 2013 From: emailgrant at gmail.com (Grant) Date: Thu, 25 Apr 2013 21:27:33 -0700 Subject: [Shotwell] Shotwell crashes when importing with "Copy Photos" Message-ID: I've been having a problem with Shotwell crashing when importing with the "Copy Photos" option as opposed to "Import in Place" which does not crash. I was having this problem with 0.13.1 as described in this thread: http://shotwell.996238.n3.nabble.com/Crashes-when-importing-td56658.html and now 0.14.0. I have tried deleting .gconf/org/yorba/shotwell (.gconf/apps/shotwell does not exist) but the result is the same. I get various errors in the console such as these: (shotwell:6623): GConf-CRITICAL **: gconf_engine_pop_owner_usage: assertion `engine->owner_use_count > 0' failed (shotwell:14699): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed ERROR:gconfsettingsbackend.c:205:gconf_settings_backend_remove_notifier: assertion failed: (notifier && g_str_equal (path, notifier->path)) I'm on Gentoo fully up-to-date. - Grant From lucas at yorba.org Fri Apr 26 18:56:57 2013 From: lucas at yorba.org (Lucas Beeler) Date: Fri, 26 Apr 2013 11:56:57 -0700 Subject: [Shotwell] Shotwell crashes when importing with "Copy Photos" In-Reply-To: References: Message-ID: Hi Grant, You're the only person who's ever reported having this problem, and -- unfortunately -- it looks like you've been having it for a while too, given that we sent some messages back-and-forth about this six months ago. Out of curiosity, have you re-installed your operating system between then and now? If you haven't, it might be something to consider. There may be something about the configuration mapper on your machine that is just broken. Other than advising that, there's little more we can do on this end. You very helpfully submitted stack traces and log files late last year and, upon examining them, it was clear that the problem occurred deep inside of the GSettings-to-GConf mapper (gconfsettingsbackend). This might be an issue for you to take up on their mailing list or Bugzilla. In Shotwell, we use GSettings in way wholly compliant with GSettings best practices. Another place you might want to bring this up is on a Gentoo mailing list. Specifically, I'd ask the Gentoo packagers why they're using a GSettings-to-GConf mapper, because GSettings is designed as an evolution over GConf and should have no relation to it whatsoever. This is discussed in the GNOME Goal Blueprint Paper on GConf to GSettings Migration here: https://live.gnome.org/GnomeGoals/GSettingsMigration. Take care, Lucas On Thu, Apr 25, 2013 at 9:27 PM, Grant wrote: > I've been having a problem with Shotwell crashing when importing with > the "Copy Photos" option as opposed to "Import in Place" which does > not crash. I was having this problem with 0.13.1 as described in this > thread: > > http://shotwell.996238.n3.nabble.com/Crashes-when-importing-td56658.html > > and now 0.14.0. I have tried deleting .gconf/org/yorba/shotwell > (.gconf/apps/shotwell does not exist) but the result is the same. I > get various errors in the console such as these: > > (shotwell:6623): GConf-CRITICAL **: gconf_engine_pop_owner_usage: > assertion `engine->owner_use_count > 0' failed > > (shotwell:14699): GLib-CRITICAL **: g_propagate_error: assertion `src > != NULL' failed > > ERROR:gconfsettingsbackend.c:205:gconf_settings_backend_remove_notifier: > assertion failed: (notifier && g_str_equal (path, notifier->path)) > > I'm on Gentoo fully up-to-date. > > - Grant > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > From emailgrant at gmail.com Fri Apr 26 20:09:25 2013 From: emailgrant at gmail.com (Grant) Date: Fri, 26 Apr 2013 13:09:25 -0700 Subject: [Shotwell] Shotwell crashes when importing with "Copy Photos" In-Reply-To: References: Message-ID: > You're the only person who's ever reported having this problem, and -- > unfortunately -- it looks like you've been having it for a while too, given > that we sent some messages back-and-forth about this six months ago. Out of > curiosity, have you re-installed your operating system between then and now? > If you haven't, it might be something to consider. There may be something > about the configuration mapper on your machine that is just broken. Other > than advising that, there's little more we can do on this end. You very > helpfully submitted stack traces and log files late last year and, upon > examining them, it was clear that the problem occurred deep inside of the > GSettings-to-GConf mapper (gconfsettingsbackend). This might be an issue for > you to take up on their mailing list or Bugzilla. In Shotwell, we use > GSettings in way wholly compliant with GSettings best practices. Another > place you might want to bring this up is on a Gentoo mailing list. > Specifically, I'd ask the Gentoo packagers why they're using a > GSettings-to-GConf mapper, because GSettings is designed as an evolution > over GConf and should have no relation to it whatsoever. This is discussed > in the GNOME Goal Blueprint Paper on GConf to GSettings Migration here: > https://live.gnome.org/GnomeGoals/GSettingsMigration. Thank you for the info. This should be enough to get me going in the right direction. I'll report back if I find anything. - Grant >> I've been having a problem with Shotwell crashing when importing with >> the "Copy Photos" option as opposed to "Import in Place" which does >> not crash. I was having this problem with 0.13.1 as described in this >> thread: >> >> http://shotwell.996238.n3.nabble.com/Crashes-when-importing-td56658.html >> >> and now 0.14.0. I have tried deleting .gconf/org/yorba/shotwell >> (.gconf/apps/shotwell does not exist) but the result is the same. I >> get various errors in the console such as these: >> >> (shotwell:6623): GConf-CRITICAL **: gconf_engine_pop_owner_usage: >> assertion `engine->owner_use_count > 0' failed >> >> (shotwell:14699): GLib-CRITICAL **: g_propagate_error: assertion `src >> != NULL' failed >> >> ERROR:gconfsettingsbackend.c:205:gconf_settings_backend_remove_notifier: >> assertion failed: (notifier && g_str_equal (path, notifier->path)) >> >> I'm on Gentoo fully up-to-date.