Hi Moe, > Is that because the JPEG files were renamed to P000000_ARW.jpg and > I have to set every JPEG back to P000000.JPG, how filenames look > usually out of camera?
Yes, that's exactly it; Shotwell 'expects' the part of the filename before the extension to match, so with P000000.ARW, 'P000000_ARW.jpg' won't be paired, but 'P000000.JPG' will. I hope this helps you out, but if you have any other questions, please let us know. Cheers, -c On 16 March 2013 16:26, Moe Blue <[email protected]> wrote: > Hi there > > > >> It only happened with the old photos from the database, that were >> already imported as miss-paired ones. >> >> > Have you found a way to re-combine miss-paired ones? > > I tied the following: > > 1. copied a set of mis-paired RAW+JPEG from the pictures folder over to a > DCIM folder on my camera > 2. moved the set of Photos to trash inside shotwell. empty trash inside > shotwell (and delete files) > 3. removed remaining files from my pictures folder > 4. removed *_shotwell and *_embedded files from the DCIM folder on my > camera. (now only the original .ARW and the _ARW.jpg are left). > 5. did a new import from camera. > > did non work :( that is, files are not paired properly. Still, RAW and > JPEG are imported separately and embedded jpeg will be extracted. > > Is that because the JPEG files were renamed to P000000_ARW.jpg and I have > to set every JPEG back to P000000.JPG, how filenames look usually out ouf > camera? Or are any traces to the files and the development settings left > back from the first wrong import? I thought these were cleared out of the > database in step 2. > > best > Moe > > > > > > Indeed it looks like Shotwell handles new imports much better now. I >> did’t have any problems with this. >> >> These checks have always occurred as part of EXIF reading; we modified >>> Shotwell slightly to report more of these kinds of errors (this >>> message in particular is from libgexiv2, which tends to be a bit >>> verbose when it finds something in an image that it doesn't quite >>> like). As for slow performance and/or metadata reading and writing >>> when the application is first started, are you seeing this every time, >>> and does the metadata progress bar ever complete? If not, then you >>> may be seeing an alternate case of >>> http://redmine.yorba.org/**issues/4297<http://redmine.yorba.org/issues/4297>, >>> and we definitely need to know >>> about this. >>> >>> Thank you for taking time to let us know about what you're seeing. If >>> you have any other feedback, please let us know. >>> >> >> I had the problem from Bug#4297, but it is fixed with 0.13 for me. >> >> Shotwell does not popup "Writing metadata" progres bar while this is >> happending. Starting up the program I get "Refreshing database" and >> "Importing photos" progres bars for just a short time (1 sec). >> >> After this Shotwell is using my external HDD very intensively for about >> 5 minutes (tried both NTFS and ext4 file systems). All operations are >> very slow during this period and I am not able to delete photo, export >> image, etc. When the HDD finally stops spinning everything is OK. >> >> >> Best regards, >> Miloš >> >> ______________________________**_________________ >> Shotwell mailing list >> [email protected] >> http://lists.yorba.org/cgi-**bin/mailman/listinfo/shotwell<http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell> >> >> > ______________________________**_________________ > Shotwell mailing list > [email protected] > http://lists.yorba.org/cgi-**bin/mailman/listinfo/shotwell<http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell> > -- --------------------------- "I asked if Sodium, Bromine and Oxygen wanted to hang out, but they were like 'Na Br O'..." _______________________________________________ Shotwell mailing list [email protected] http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
