From nixphoeni at gmail.com Mon Jul 1 01:57:34 2013 From: nixphoeni at gmail.com (Joe Sapp) Date: Sun, 30 Jun 2013 21:57:34 -0400 Subject: [Shotwell] Filtering files from publishable upload In-Reply-To: References: Message-ID: Hi Lucas, Thanks for the background. My motivation for this is that the service being published to can't handle certain types of videos, so maybe I've limited my focus to a particular solution. It would be fine (but less than ideal) to notify the user that some items weren't successfully published. In that case, the file has to be transferred (even though the server doesn't support it) and I suppose I'd have to modify my error handlers so the end dialog displays something useful. Thanks, Joe On Sun, Jun 30, 2013 at 6:12 PM, Lucas Beeler wrote: > Hi Joe, > > Shotwell's publishing subsystem was designed with the intention of making it > as easy as possible for external contributors to write publishing plugins. > Our hope was that a big plugin ecosystem (SmugMug, ImageShack, Walgreens, > Boots, etc.) would develop if we just made it as drop-dead simple as > possible to write plugins. We did get major contributions in the form of the > Tumblr, YouTube, and Piwigo plugins from the community but, alas, uptake of > the publishing plugin API hasn't been as high as we would've liked. > > Why do I bring this up? I mention this aim for simplicity because it > explains a big part of the design of the Shotwell publishing subsystem. > Namely, the way that publishing in Shotwell works is that Shotwell itself -- > not the individual plugins -- is responsible for serializing and preparing > the files on disk for uploading. This seemed like a good, simplifying > abstraction. After all, why should plugins care which files are written to > disk and how? > > That said, it would be technically straightforward to add the ability for > plugins to filter the files that are serialized. Specifically, the API of > the Spit.Publishing.PluginHost interface could be modified to take a pointer > to a predicate filter function that returns true for publishable items that > should be serialized and false for items that shouldn't be serialized. > > While this is a pretty easy change technically, I'm not sure it's something > we want from a user experience standpoint. In particular, I think that the > user -- not the plugin developer -- should be in control of what files get > published. If the user has selected 3 photos for publishing and then clicks > the "Publish" button, I think all 3 of these photos should be pushed up to > the remote hosting service. I think it violates the principle of least > astonishment if the plugin of its own accord decides to filter 2 of those 3 > photos out, resulting in the user observing only a single file published in > spite of his or her having selected 3 photos. > > However, I'm no longer a technical lead and product manager for the Shotwell > project, so any the decision to modify the publishing API rests with Jim > Nelson. Jim, what do you think? > > Cheers, > Lucas > > > On Thu, Jun 27, 2013 at 6:47 PM, Joe Sapp wrote: >> >> Hi, >> >> I'm writing a publishing module and I need to exclude certain files >> from upload. Any ideas on the best place to do this? I was thinking >> about checking in the create_transaction() function of my >> Publishing.RESTSupport.BatchUploader class, but there doesn't seem to >> be a good way to eliminate the file from upload. Maybe I'm just >> missing something in another plugin, so any pointers would be >> appreciated. >> >> Thanks, >> Joe Sapp From dougie at highmoor.co.uk Sun Jul 7 19:41:51 2013 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Sun, 07 Jul 2013 20:41:51 +0100 Subject: [Shotwell] cannot bulk move/delete Message-ID: <51D9C47F.3070806@highmoor.co.uk> In previous versions of shotwell I used to use the Shift-Del key-combination to delete multiple files. Now when I try this it fails. I can get around the problem by doing the delete in two stages; 1. move to wastebasket then 2. empty wastebasket. But even then I still get an error message, only this time it goes ahead and deletes them anyway. The log shows things like: 5505 2013-07-07 20:30:01 [WRN] DataSource.vala:372: Unable to delete backing for [63337] /store1/images/2010/07/05/[000796].jpg L 5505 2013-07-07 20:30:01 [MSG] MediaDataRepresentation.vala:106: Unable to move original photo /store1/images/2003/09/08/[000235].jpg to trash: Unable to find or create wastebasket directory L 5505 2013-07-07 20:30:01 [WRN] DataSource.vala:372: Unable to delete backing for [62776] /store1/images/2003/09/08/[000235].jpg L 5505 2013-07-07 20:30:01 [MSG] MediaDataRepresentation.vala:106: Unable to move original photo /store1/images/2010/12/28/[000829].jpg to trash: Unable to find or create wastebasket directory L 5505 2013-07-07 20:30:01 [WRN] DataSource.vala:372: Unable to delete backing for [63370] /store1/images/2010/12/28/[000829].jpg L 5505 2013-07-07 20:30:01 [MSG] MediaDataRepresentation.vala:106: Unable to move original photo /store1/images/2003/09/08/[000346].jpg to trash: Unable to find or create wastebasket directory L 5505 2013-07-07 20:30:01 [WRN] DataSource.vala:372: Unable to delete backing for [62887] /store1/images/2003/09/08/[000346].jpg L 5505 2013-07-07 20:30:01 [MSG] MediaDataRepresentation.vala:106: Unable to move original photo /store1/images/2003/09/08/[000260].jpg to trash: Unable to find or create wastebasket directory Thinking that this might be something to do with xfce I googled around and tried to create various promising folders such as .Trash-1000 and .trash (although I haven't tried .wastebasket .... nope, that doesn't help). I'm on Debian Testing running Shotwell 0.14.1 Dougie From dougie at highmoor.co.uk Sun Jul 7 19:54:41 2013 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Sun, 07 Jul 2013 20:54:41 +0100 Subject: [Shotwell] cannot bulk move/delete In-Reply-To: <51D9C47F.3070806@highmoor.co.uk> References: <51D9C47F.3070806@highmoor.co.uk> Message-ID: <51D9C781.50700@highmoor.co.uk> On 07/07/13 20:41, Dougie Nisbet wrote: > > 5505 2013-07-07 20:30:01 [WRN] DataSource.vala:372: Unable to > delete backing for [63337] /store1/images/2010/07/05/[000796].jpg Got it. /store1 is a second harddrive. Although I have permissions to write to /store1/images, I don't (or didn't) to /store1. As soon as I changed the ownership it worked. yup, I now have a /store1/.Trash-1000 folder, full of rubbish files. That's a bit of a pain. I wonder if this has anything to do with the errors I get (permissions errors, can't remember details off hand) when I try and import (copy) images from a samba mounted read-only windows folder mounted over the LAN. From ezelspinguin at gmail.com Sun Jul 7 23:27:59 2013 From: ezelspinguin at gmail.com (pjv) Date: Mon, 08 Jul 2013 01:27:59 +0200 Subject: [Shotwell] Missing Photos don't rescan properly Message-ID: <1373239679.3844.1.camel@defiant> Similar to this thread from April (http://lists.yorba.org/pipermail/sho...il/004812.html), I accidentally disconnected my external storage and started Shotwell. Now 8000 photos (32%) are under "Missing photos". However when I've reattached the external storage and restarted Shotwell, they do not migrate back to the main library. This feature should be working as mentioned on http://www.yorba.org/shotwell/help/other-missing.html. I'm mostly interested in one specific label tag. Behavior is exactly the same as in this thread. Some new info I can offer is that I use a softlink (ln -s) to access that external storage and that this link path is in all of the photo filenames. Also, I'm using cinnamon and no nautilus (possibly dbus is missing for file modification updates??). I even tried to use "UPDATE PhotoTable SET flags=0, file_format=1 WHERE flags=8;" on a (copied) database to try and fix it but I don't understand the full sql logic yet. The photos go back to the main database then, but I lose the tags. I think the "backlinks" column is the culprit. I also posted this on ubuntu forums: http://ubuntuforums.org/showthread.php?t=2160682&p=12721922 Any ideas? >> 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). -- pjv From onefiftyfour at hotmail.com Tue Jul 9 23:26:33 2013 From: onefiftyfour at hotmail.com (eric L) Date: Tue, 9 Jul 2013 18:26:33 -0500 Subject: [Shotwell] from Fedora 17 to 19, video thumbnails gone Message-ID: I've just installed Fedora 19. I've moved my /home partition from Fedora 17 where I had shotwell installed from git but not updated for about 9 months. It was using gstreamer1 and video thumbnails were having no problems generating. Now, after installing Fedora 19, I've just got the latest shotwell git pull. I have all the gstreamer1 packages including Video thumbnails are not there. Running shotwell from the command line gives me this output: Failed to open '/dev/stdout' for writing: Permission denied ( this repeats for as many videos as I have) Monitoring ~/.cache/shotwellshotwell.log, I see this for each video: L 15364 2013-07-09 18:21:28 [WRN] VideoSupport.vala:254: Error creating pixbuf: Unrecognized image file format Any advice? I have these gstreamer packages installed: sudo yum list installed | grep gstreamer PackageKit-gstreamer-plugin.x86_64 gstreamer.x86_64 0.10.36-3.fc19 @koji-override-0/$releasever gstreamer-ffmpeg.x86_64 0.10.13-8.fc19 @rpmfusion-free gstreamer-plugins-bad-free.x86_64 gstreamer-plugins-base.x86_64 0.10.36-4.fc19 @koji-override-0/$releasever gstreamer-plugins-espeak.x86_64 0.4.0-2.fc19 @koji-override-0/$releasever gstreamer-plugins-good.x86_64 0.10.31-9.fc19 @koji-override-0/$releasever gstreamer-plugins-ugly.x86_64 0.10.19-11.fc19 @rpmfusion-free gstreamer-tools.x86_64 0.10.36-3.fc19 @koji-override-0/$releasever gstreamer1.x86_64 1.0.7-1.fc19 @koji-override-0/$releasever gstreamer1-devel.x86_64 1.0.7-1.fc19 @fedora gstreamer1-devel-docs.noarch 1.0.7-1.fc19 @fedora gstreamer1-libav.x86_64 1.0.6-1.fc19 @rpmfusion-free gstreamer1-plugins-bad-free.x86_64 gstreamer1-plugins-bad-free-devel.x86_64 gstreamer1-plugins-bad-free-extras.x86_64 gstreamer1-plugins-bad-freeworld.x86_64 gstreamer1-plugins-base.x86_64 1.0.7-2.fc19 @koji-override-0/$releasever gstreamer1-plugins-base-devel.x86_64 gstreamer1-plugins-base-devel-docs.noarch gstreamer1-plugins-base-tools.x86_64 gstreamer1-plugins-fc.x86_64 0.2-7.fc19 @fedora gstreamer1-plugins-good.x86_64 1.0.7-1.fc19 @koji-override-0/$releasever gstreamer1-plugins-good-extras.x86_64 gstreamer1-plugins-ugly.x86_64 1.0.6-2.fc19 @rpmfusion-free gstreamer1-plugins-ugly-devel-docs.noarch phonon-backend-gstreamer.x86_64 2:4.6.3-1.fc19 @fedora Thanks! -Eric From onefiftyfour at hotmail.com Tue Jul 9 23:30:24 2013 From: onefiftyfour at hotmail.com (eric L) Date: Tue, 9 Jul 2013 18:30:24 -0500 Subject: [Shotwell] from Fedora 17 to 19, video thumbnails gone In-Reply-To: References: Message-ID: Sorry. My second paragraph should say: Now, after installing Fedora 19, I've just got the latest shotwell git pull. I have all the gstreamer1 packages including gstreamer1-libav. Video thumbnails are not there. Running shotwell from the command line gives me this output: > From: onefiftyfour at hotmail.com > To: shotwell at lists.yorba.org > Date: Tue, 9 Jul 2013 18:26:33 -0500 > Subject: [Shotwell] from Fedora 17 to 19, video thumbnails gone > > I've just installed Fedora 19. I've moved my /home partition from Fedora 17 where I had shotwell installed from git but not updated for about 9 months. It was using gstreamer1 and video thumbnails were having no problems generating. > > Now, after installing Fedora 19, I've just got the latest shotwell git pull. I have all the gstreamer1 packages including Video thumbnails are not there. Running shotwell from the command line gives me this output: > > Failed to open '/dev/stdout' for writing: Permission denied ( this repeats for as many videos as I have) > > Monitoring ~/.cache/shotwellshotwell.log, I see this for each video: > > L 15364 2013-07-09 18:21:28 [WRN] VideoSupport.vala:254: Error creating pixbuf: Unrecognized image file format > > Any advice? > > I have these gstreamer packages installed: > > sudo yum list installed | grep gstreamer > PackageKit-gstreamer-plugin.x86_64 > gstreamer.x86_64 0.10.36-3.fc19 @koji-override-0/$releasever > gstreamer-ffmpeg.x86_64 0.10.13-8.fc19 @rpmfusion-free > gstreamer-plugins-bad-free.x86_64 > gstreamer-plugins-base.x86_64 0.10.36-4.fc19 @koji-override-0/$releasever > gstreamer-plugins-espeak.x86_64 0.4.0-2.fc19 @koji-override-0/$releasever > gstreamer-plugins-good.x86_64 0.10.31-9.fc19 @koji-override-0/$releasever > gstreamer-plugins-ugly.x86_64 0.10.19-11.fc19 @rpmfusion-free > gstreamer-tools.x86_64 0.10.36-3.fc19 @koji-override-0/$releasever > gstreamer1.x86_64 1.0.7-1.fc19 @koji-override-0/$releasever > gstreamer1-devel.x86_64 1.0.7-1.fc19 @fedora > gstreamer1-devel-docs.noarch 1.0.7-1.fc19 @fedora > gstreamer1-libav.x86_64 1.0.6-1.fc19 @rpmfusion-free > gstreamer1-plugins-bad-free.x86_64 > gstreamer1-plugins-bad-free-devel.x86_64 > gstreamer1-plugins-bad-free-extras.x86_64 > gstreamer1-plugins-bad-freeworld.x86_64 > gstreamer1-plugins-base.x86_64 1.0.7-2.fc19 @koji-override-0/$releasever > gstreamer1-plugins-base-devel.x86_64 > gstreamer1-plugins-base-devel-docs.noarch > gstreamer1-plugins-base-tools.x86_64 > gstreamer1-plugins-fc.x86_64 0.2-7.fc19 @fedora > gstreamer1-plugins-good.x86_64 1.0.7-1.fc19 @koji-override-0/$releasever > gstreamer1-plugins-good-extras.x86_64 > gstreamer1-plugins-ugly.x86_64 1.0.6-2.fc19 @rpmfusion-free > gstreamer1-plugins-ugly-devel-docs.noarch > phonon-backend-gstreamer.x86_64 2:4.6.3-1.fc19 @fedora > > > Thanks! -Eric > > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From dougie at highmoor.co.uk Sun Jul 14 21:38:54 2013 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Sun, 14 Jul 2013 22:38:54 +0100 Subject: [Shotwell] cannot bulk move/delete In-Reply-To: <51D9C781.50700@highmoor.co.uk> References: <51D9C47F.3070806@highmoor.co.uk> <51D9C781.50700@highmoor.co.uk> Message-ID: <51E31A6E.9000508@highmoor.co.uk> On 07/07/13 20:54, Dougie Nisbet wrote: > On 07/07/13 20:41, Dougie Nisbet wrote: >> >> 5505 2013-07-07 20:30:01 [WRN] DataSource.vala:372: Unable to >> delete backing for [63337] /store1/images/2010/07/05/[000796].jpg > > Got it. > > /store1 is a second harddrive. Although I have permissions to write to > /store1/images, I don't (or didn't) to /store1. As soon as I changed > the ownership it worked. > > yup, I now have a /store1/.Trash-1000 folder, full of rubbish files. > That's a bit of a pain. > > I wonder if this has anything to do with the errors I get (permissions > errors, can't remember details off hand) when I try and import (copy) > images from a samba mounted read-only windows folder mounted over the > LAN. > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell > Sort of on the back of this, it seems I need write access to the directory I'm importing from. That's a bug, yes? From jim at yorba.org Mon Jul 15 18:32:59 2013 From: jim at yorba.org (Jim Nelson) Date: Mon, 15 Jul 2013 18:25:59 -0007 Subject: [Shotwell] cannot bulk move/delete In-Reply-To: <51E31A6E.9000508@highmoor.co.uk> References: <51D9C47F.3070806@highmoor.co.uk> <51D9C781.50700@highmoor.co.uk> <51E31A6E.9000508@highmoor.co.uk> Message-ID: <51e4405d.a4c5440a.6745.ffffbf0e@mx.google.com> I can import photos from a read-only directory. What error are you seeing? -- Jim On Sun, Jul 14, 2013 at 2:38 PM, Dougie Nisbet wrote: > On 07/07/13 20:54, Dougie Nisbet wrote: >> On 07/07/13 20:41, Dougie Nisbet wrote: >>> >>> 5505 2013-07-07 20:30:01 [WRN] DataSource.vala:372: Unable to >>> delete backing for [63337] /store1/images/2010/07/05/[000796].jpg >>> >> Got it. >> >> /store1 is a second harddrive. Although I have permissions to write >> to /store1/images, I don't (or didn't) to /store1. As soon as I >> changed the ownership it worked. >> >> yup, I now have a /store1/.Trash-1000 folder, full of rubbish files. >> That's a bit of a pain. >> >> I wonder if this has anything to do with the errors I get >> (permissions errors, can't remember details off hand) when I try and >> import (copy) images from a samba mounted read-only windows folder >> mounted over the LAN. >> _______________________________________________ >> Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >> >> > Sort of on the back of this, it seems I need write access to the > directory I'm importing from. That's a bug, yes? > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From dougie at highmoor.co.uk Mon Jul 15 18:44:42 2013 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Mon, 15 Jul 2013 19:44:42 +0100 Subject: [Shotwell] cannot bulk move/delete In-Reply-To: <51e4405d.a4c5440a.6745.ffffbf0e@mx.google.com> References: <51D9C47F.3070806@highmoor.co.uk> <51D9C781.50700@highmoor.co.uk> <51E31A6E.9000508@highmoor.co.uk> <51e4405d.a4c5440a.6745.ffffbf0e@mx.google.com> Message-ID: <51E4431A.5090506@highmoor.co.uk> I've had a look at the import log and I don't understand what it's saying. My settings are such that it should import to /store1/images (which is on a separate internal disk) and usually it works fine. Here's an extract from the log: couldn't copy /home/dougie/transport/2013-07-14 09.55.15.jpg to /home/dougie/transport/2013-07-14 09.55.15.jpg error message: Error setting owner: Operation not permitted couldn't copy /home/dougie/transport/2013-07-14 09.55.09.jpg to /home/dougie/transport/2013-07-14 09.55.09.jpg error message: Error setting owner: Operation not permitted couldn't copy /home/dougie/transport/2013-07-14 09.55.04.jpg to /home/dougie/transport/2013-07-14 09.55.04.jpg error message: Error setting owner: Operation not permitted couldn't copy /home/dougie/transport/2013-07-14 09.54.57.jpg to /home/dougie/transport/2013-07-14 09.54.57.jpg error message: Error setting owner: Operation not permitted couldn't copy /home/dougie/transport/2013-07-14 09.54.53.jpg to /home/dougie/transport/2013-07-14 09.54.53.jpg error message: Error setting owner: Operation not permitted couldn't copy /home/dougie/transport/2013-07-14 21.52.10.jpg to /home/dougie/transport/2013-07-14 21.52.10.jpg error message: Error setting owner: Operation not permitted It might be that the permissions got changed to 'nobody:nobody' as the ~/transport directory is one that I copy directly into from a windows PC and it seems to set the permissions to nobody. But I'm puzzled as to why it seems to be copying the file to itself. I could probably set up a more controlled test to reproduce this if it helps. Dougie On 15/07/13 19:32, Jim Nelson wrote: > I can import photos from a read-only directory. What error are you > seeing? > > -- Jim > > On Sun, Jul 14, 2013 at 2:38 PM, Dougie Nisbet > wrote: >> On 07/07/13 20:54, Dougie Nisbet wrote: >> >> On 07/07/13 20:41, Dougie Nisbet wrote: >> >> 5505 2013-07-07 20:30:01 [WRN] DataSource.vala:372: Unable to >> delete backing for [63337] >> /store1/images/2010/07/05/[000796].jpg >> >> Got it. /store1 is a second harddrive. Although I have >> permissions to write to /store1/images, I don't (or didn't) to >> /store1. As soon as I changed the ownership it worked. yup, I now >> have a /store1/.Trash-1000 folder, full of rubbish files. That's >> a bit of a pain. I wonder if this has anything to do with the >> errors I get (permissions errors, can't remember details off >> hand) when I try and import (copy) images from a samba mounted >> read-only windows folder mounted over the LAN. >> _______________________________________________ Shotwell mailing >> list Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell >> >> Sort of on the back of this, it seems I need write access to the >> directory I'm importing from. That's a bug, yes? >> _______________________________________________ Shotwell mailing list >> Shotwell at lists.yorba.org >> http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From joseph.bylund at gmail.com Mon Jul 15 19:17:44 2013 From: joseph.bylund at gmail.com (Joseph Bylund) Date: Mon, 15 Jul 2013 15:17:44 -0400 Subject: [Shotwell] [off-topic] Ubuntu 13.10 Wallpaper Contest Message-ID: <51E44AD8.5070402@gmail.com> Hi all, The Ubuntu 13.10 wallpaper contest has started on Flickr. You can read a little more about it here: http://www.omgubuntu.co.uk/2013/07/ubuntu-13-10-wallpaper-contest-kicks-off And submit your amazing photos here: http://flic.kr/g/kKtj9 best, -Joe Excuse me going a little off topic, I thought this might be of general interest to the list. From dougie at highmoor.co.uk Mon Jul 15 19:32:59 2013 From: dougie at highmoor.co.uk (Dougie Nisbet) Date: Mon, 15 Jul 2013 20:32:59 +0100 Subject: [Shotwell] cannot bulk move/delete In-Reply-To: <51E4431A.5090506@highmoor.co.uk> References: <51D9C47F.3070806@highmoor.co.uk> <51D9C781.50700@highmoor.co.uk> <51E31A6E.9000508@highmoor.co.uk> <51e4405d.a4c5440a.6745.ffffbf0e@mx.google.com> <51E4431A.5090506@highmoor.co.uk> Message-ID: <51E44E6B.2050902@highmoor.co.uk> On 15/07/13 19:44, Dougie Nisbet wrote: > I've had a look at the import log and I don't understand what it's > saying. My settings are such that it should import to /store1/images > (which is on a separate internal disk) and usually it works fine. > Here's an extract from the log: > > couldn't copy /home/dougie/transport/2013-07-14 09.55.15.jpg > to /home/dougie/transport/2013-07-14 09.55.15.jpg > error message: Error setting owner: Operation not permitted > ok, looking at this it suggests very strongly that I have selected 'import in place' rather than 'copy images'. I was convinced I hadn't so I've repeated the test. in the first test it all looked ok, but probably because all the images were duplicates and recognised as such by shotwell so no import was attempted. I tried it again with another mixed batch of images and this time a window pop-up informed me that there were some duplicates but also that the remainder could not be imported because the destination directory was not writeable. The following line appeared in the logfile at this time: L 9743 2013-07-15 20:25:43 [WRN] DirectoryMonitor.vala:846: Directory loop detected at /store1/images/2013/07/07, not exploring which I think may be a coincidence and unrelated. shotwell auto-scanning my image folder perhaps? I've checked the import log and again I'm seeing messages indicating that I'm not the owner of the files that are in the directory I'm importing from. The files are readable, however. The following section shows both messages (dupes and ownership). BTW, I am quite sure I selected 'copy' rather than 'import in place' during import. /home/dougie/transport/2013-07-06 19.27.57.jpg duplicates existing media item /store1/images/2013/07/06/2013-07-06 19.27.57.jpg /home/dougie/transport/2013-07-06 19.28.05.jpg duplicates existing media item /store1/images/2013/07/06/2013-07-06 19.28.05.jpg /home/dougie/transport/2013-07-06 19.28.28.jpg duplicates existing media item /store1/images/2013/07/06/2013-07-06 19.28.28.jpg Photos/Videos Not Imported Because Shotwell Couldn't Copy Them into its Library: couldn't copy /home/dougie/transport/2013-06-16 14.25.29.jpg to /home/dougie/transport/2013-06-16 14.25.29.jpg error message: Error setting owner: Operation not permitted couldn't copy /home/dougie/transport/2013-06-18 19.53.30.jpg to /home/dougie/transport/2013-06-18 19.53.30.jpg error message: Error setting owner: Operation not permitted couldn't copy /home/dougie/transport/2013-07-04 12.44.10.mov to /home/dougie/transport/2013-07-04 12.44.10.mov error message: Error setting owner: Operation not permitted couldn't copy /home/dougie/transport/2013-07-06 19.27.44.mov to /home/dougie/transport/2013-07-06 19.27.44.mov error message: Error setting owner: Operation not permitted couldn't copy /home/dougie/transport/2013-07-06 20.48.35.mov to /home/dougie/transport/2013-07-06 20.48.35.mov error message: Error setting owner: Operation not permitted couldn't copy /home/dougie/transport/2013-07-07 17.47.22.jpg to /home/dougie/transport/2013-07-07 17.47.22.jpg error message: Error setting owner: Operation not permitted couldn't copy /home/dougie/transport/2013-07-07 17.47.31.jpg to /home/dougie/transport/2013-07-07 17.47.31.jpg error message: Error setting owner: Operation not permitted From jim at yorba.org Mon Jul 15 19:37:29 2013 From: jim at yorba.org (Jim Nelson) Date: Mon, 15 Jul 2013 19:30:29 -0007 Subject: [Shotwell] [off-topic] Ubuntu 13.10 Wallpaper Contest In-Reply-To: <51E44AD8.5070402@gmail.com> References: <51E44AD8.5070402@gmail.com> Message-ID: <51e44f7c.0591420a.0fc2.ffffe9ee@mx.google.com> On Mon, Jul 15, 2013 at 12:17 PM, Joseph Bylund wrote: > Excuse me going a little off topic, I thought this might be of > general interest to the list. > That's fine, Joe, I think this is the kind of thing that's of interest to many Shotwell users. Here's to hoping that a Shotwell-enhanced photo makes the cut! -- Jim From jim at yorba.org Tue Jul 16 19:26:48 2013 From: jim at yorba.org (Jim Nelson) Date: Tue, 16 Jul 2013 19:19:48 -0007 Subject: [Shotwell] cannot bulk move/delete In-Reply-To: <51E44E6B.2050902@highmoor.co.uk> References: <51D9C47F.3070806@highmoor.co.uk> <51D9C781.50700@highmoor.co.uk> <51E31A6E.9000508@highmoor.co.uk> <51e4405d.a4c5440a.6745.ffffbf0e@mx.google.com> <51E4431A.5090506@highmoor.co.uk> <51E44E6B.2050902@highmoor.co.uk> Message-ID: <51e59e78.64e5440a.1df5.ffffc593@mx.google.com> I think what you're seeing is a bug in the report code when an import fails on a file, since the duplicate file warnings look correct as far as source/destination go. The directory loop message is suspicious -- that happens when a hard or soft link is present. The DirectoryMonitor is stating that it won't keep searching that directory because it saw it before, probably due to a link of some kind. So, is there a soft link present somewhere here? In /home/dougie/transport or one of it's subdirectories? Or, for that matter, in /store1/images? -- Jim On Mon, Jul 15, 2013 at 12:32 PM, Dougie Nisbet wrote: > On 15/07/13 19:44, Dougie Nisbet wrote: >> I've had a look at the import log and I don't understand what it's >> saying. My settings are such that it should import to /store1/images >> (which is on a separate internal disk) and usually it works fine. >> Here's an extract from the log: >> >> couldn't copy /home/dougie/transport/2013-07-14 09.55.15.jpg >> to /home/dougie/transport/2013-07-14 09.55.15.jpg >> error message: Error setting owner: Operation not permitted >> >> > ok, looking at this it suggests very strongly that I have selected > 'import in place' rather than 'copy images'. I was convinced I hadn't > so I've repeated the test. > > in the first test it all looked ok, but probably because all the > images were duplicates and recognised as such by shotwell so no > import was attempted. > > I tried it again with another mixed batch of images and this time a > window pop-up informed me that there were some duplicates but also > that the remainder could not be imported because the destination > directory was not writeable. The following line appeared in the > logfile at this time: > > L 9743 2013-07-15 20:25:43 [WRN] DirectoryMonitor.vala:846: Directory > loop detected at /store1/images/2013/07/07, not exploring > > which I think may be a coincidence and unrelated. shotwell > auto-scanning my image folder perhaps? > > I've checked the import log and again I'm seeing messages indicating > that I'm not the owner of the files that are in the directory I'm > importing from. The files are readable, however. The following > section shows both messages (dupes and ownership). BTW, I am quite > sure I selected 'copy' rather than 'import in place' during import. > > /home/dougie/transport/2013-07-06 19.27.57.jpg duplicates existing > media item > /store1/images/2013/07/06/2013-07-06 19.27.57.jpg > > /home/dougie/transport/2013-07-06 19.28.05.jpg duplicates existing > media item > /store1/images/2013/07/06/2013-07-06 19.28.05.jpg > > /home/dougie/transport/2013-07-06 19.28.28.jpg duplicates existing > media item > /store1/images/2013/07/06/2013-07-06 19.28.28.jpg > > Photos/Videos Not Imported Because Shotwell Couldn't Copy Them into > its Library: > > couldn't copy /home/dougie/transport/2013-06-16 14.25.29.jpg > to /home/dougie/transport/2013-06-16 14.25.29.jpg > error message: Error setting owner: Operation not permitted > > couldn't copy /home/dougie/transport/2013-06-18 19.53.30.jpg > to /home/dougie/transport/2013-06-18 19.53.30.jpg > error message: Error setting owner: Operation not permitted > > couldn't copy /home/dougie/transport/2013-07-04 12.44.10.mov > to /home/dougie/transport/2013-07-04 12.44.10.mov > error message: Error setting owner: Operation not permitted > > couldn't copy /home/dougie/transport/2013-07-06 19.27.44.mov > to /home/dougie/transport/2013-07-06 19.27.44.mov > error message: Error setting owner: Operation not permitted > > couldn't copy /home/dougie/transport/2013-07-06 20.48.35.mov > to /home/dougie/transport/2013-07-06 20.48.35.mov > error message: Error setting owner: Operation not permitted > > couldn't copy /home/dougie/transport/2013-07-07 17.47.22.jpg > to /home/dougie/transport/2013-07-07 17.47.22.jpg > error message: Error setting owner: Operation not permitted > > couldn't copy /home/dougie/transport/2013-07-07 17.47.31.jpg > to /home/dougie/transport/2013-07-07 17.47.31.jpg > error message: Error setting owner: Operation not permitted > _______________________________________________ > Shotwell mailing list > Shotwell at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell From kaaloo at gmail.com Sun Jul 28 17:51:30 2013 From: kaaloo at gmail.com (Luis Arias) Date: Sun, 28 Jul 2013 19:51:30 +0200 Subject: [Shotwell] How to remove RAW files after having imported RAW+JPEG Message-ID: Hi, I tried to remove some RAW files from an event folder containing RAW and the associated JPEG files by moving them to the trash in the file manager but quickly got frustrated and a bit scared I would loose data. The effect was that once a RAW file was deleted the associated JPEG disappeared from Shotwell even though it was still present in the file system. What would be the best way to remove RAW files while leaving the associated JPEG recognized in Shotwell ? I would like to do this to conserve disk space on photos for which I decide at some point that I don't want to use the RAW format. What I'm planning to do know is to make the decision before importing into Shotwell but this is less convenient and forces me to either decide then and there or be generous with disk space. Thanks! Luis