GNOME Bugzilla – Bug 329588
Photo's are not moved when adjusting time
Last modified: 2018-07-12 00:03:57 UTC
After some getting-used-to, I've grown to like the fact that all my pictures are in ~/Photos/YYYY/M/D/. However, when adjusting time, photos are not moved to the right direction. Offcourse, only pictures in ~/Photos/ should be moved automatically.
This should be a (minor) bug, and not an enhancement I would say. Perhaps something could be reused from bug 302566, since I added a method for renaming a photo to PhotoStore.cs
Ok, I just imported 1400 scanned photos, and set the correct date manually by using the Adjust Time function in F-Spot. But all 1400 photos are still in the folder which represent the date they were scanned.
This bug is open for more than a year and still not fixed? That's too bad. I just found out about this AFTER I adjusted time and date for over 3000 photos :( So if you ever fix this, pls deliver also a command line option (for the first few releases after it got fixed) that will move all photos to their correct place.
(In reply to comment #3) > This bug is open for more than a year and still not fixed? > > That's too bad. Patch are welcome...
(In reply to comment #4) > (In reply to comment #3) > > This bug is open for more than a year and still not fixed? > > > > That's too bad. > > Patch are welcome... What a reply! I know that all maintainers really appreciate it, when someone delivers patches, but I can't help you here. And in fact I don't have any intentions to learn C# for submitting a patch. I am just using F-Spot because it's the least sucking photo management software, using GTK+, I could find. I think these are thing, that could have been really easy implemented, but now it is much harder to fix it, if you want also deliver something for all the people who are angry now to fix their libraries. But maybe I expect too much, as we are talking about Novell software...
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > This bug is open for more than a year and still not fixed? > > > > > > That's too bad. > > > > Patch are welcome... > > > What a reply! > Great, you just insulted the best and hardest working f-spot contributor. I guess people will now be _really_ eager to fix it! > And in fact I don't have any intentions to learn C# for submitting a patch. I > am just using F-Spot because it's the least sucking photo management software, > using GTK+, I could find. > Use a qt one then, if they are better. > I think these are thing, that could have been really easy implemented, but now > it is much harder to fix it, if you want also deliver something for all the > people who are angry now to fix their libraries. > > But maybe I expect too much, as we are talking about Novell software... > Man, this is such a load of stop energy; please don't reply if you don't have anything constructive to say.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > (In reply to comment #3) > > > > This bug is open for more than a year and still not fixed? > > > > > > > > That's too bad. > > > > > > Patch are welcome... > > > > > > What a reply! > > > > Great, you just insulted the best and hardest working f-spot contributor. I > guess people will now be _really_ eager to fix it! Sorry, but this is my personal opinion. I think it's better to say the truth (IMHO) than telling lies or say that something is better than it actually is. Furthermore I think bugs should get fixed because of their priority, not because the comments individuals post on them. But maybe you're right and noone will fix this from now, just to not make me happy. > > And in fact I don't have any intentions to learn C# for submitting a patch. I > > am just using F-Spot because it's the least sucking photo management software, > > using GTK+, I could find. > > > > Use a qt one then, if they are better. Hmm, maybe my words were a little bit too strong, but what I meant was, that F-Spot was the best photo software I could find. And like many of new GTK software many people now seem to need (also Tomboy, Beagle and so on) it is written in C#. If you think that's the way to go: fine. But the only C# program I had no problems with was Tomboy, so I am not very fond of the programs actually using this "technology". I always try to use GTK apps, as I just don't like the UI of the Qt ones. But this is another story... > > I think these are thing, that could have been really easy implemented, but now > > it is much harder to fix it, if you want also deliver something for all the > > people who are angry now to fix their libraries. > > > > > But maybe I expect too much, as we are talking about Novell software... > > > > Man, this is such a load of stop energy; please don't reply if you don't have > anything constructive to say. Hmm, I thought it would be very constructive to push this bug and tell you my story with it. My intention was to help you to improve F-Spot. And I would be able to fix this myself I would supply a patch, but I just can't.
I was going to answer this one (comment #3) but sort of lost interest after his follow up comments. Especially to the one major bug fixer who is closing a lot of various serious bugs for us. Patches are always welcome, and it has a much higher chance to be accepted into the mainstream F-Spot for sure. No patch, then it is up the various developers to find the time and energy to actually write the patch. Since this patch is not the highest priority (but I totally agree, would be nice to have) it might have to wait a bit. And comments that would make possible developers/contributers annoyed will not really enhance the chance that a patch would be created by them. After all, if you are not happy with the progress of free software, feel free to contribute (http://f-spot.org/Get_Involved) or find another software to use. Bugs (especially constructive ones/feedback) are always welcome, but very negative/sarcastic comments will not help your case. Anyway. Here are two solutions for you. Actually three. 1) Workaround, which demands starting from scratch with importing all the photos again. Ensure you have all tags stored as Metadata into the photos itself. One way to ensure that if you are uncertain, Edit -> Preferences, Untag Write metadata to file. Tag EVERY photo with a dummy tag. Edit -> Preferences, Select Write metadata to file Remove dummy tag from EVERY photo. This will force f-spot to write the embedded information to every photo again. Move the Photos (I presume you copied all the photos to ~Photos) to ~Photos.old remove the ~/.gnome2/f-spot/photos.db Start f-spot, and re-import all photos. ALl photos should now be in the proper directory. This is what I had to do after changing the time on a few thousand photos as well. I did not have comments on the photos though. Only tags. Not sure f-spot writes the comment to the photo itself yet. 2) I am planning to write an extension (plugin) which will do ensure all photos are stored in the proper directory. But have no timeline on when I will have time to do it. Bug #302566 has the code for it though. 3) Try to get the patch in bug #302566 working :) Which I can imagine is a bit like flying into space for a non developer, but it is "a" solution.
Calm down guys... :) Apparently, you didn't liked my short answer... here's a longer one: This bug is not fixed yet cause, even if it looks trivial to fix, it's really hard to do it right ant it raises a lot of concerns: - What about people relying on a fixed path for their photos (symlinks, used by other applications, 'Recent Files', for backups, ...) - What to do with unmanaged photos, esp. if the user defined tree is, like f-spot one, sorted by date (or month, or whatever...). How to guess if a photo is managed or not ? - What's the correct destination if, in the f-spot livetime, the user changed the path to the Photos directory ? - What to do if, while moving an image to a new folder, the destination folder already conatains a picture with the exact same name ? Rename one of the images ? sounds _really_ bad... That being asked, you now could see that fixing that minor issue for some peoples will cause big ones for a lot of others. You should also think (as it's done in f-spot design) at a higher level and forget about files and directories. The 'Photos' thing is a kind of blackbox, a big hashed repository for files so the interface can deal with it. Hopefully for the users, f-spot do cares about the users and their precious pictures, so the blackbox is in fact a folder sorted by date, so, if anything goes wrong, the user never looses his photo. If you can't make that abstraction, Bengt is currently writing an extension that will let you (but only if you really ask) make a mess out of your repository. So wait a few more weeks.
(In reply to comment #9) > Calm down guys... :) > > Apparently, you didn't liked my short answer... here's a longer one: > > [...] Hi Stephane, I have to admit, that I haven't thought of some of the points (for example the symlinks). On the other hand, I think most people fixed the time just after importing, and the time will probably never change again. If you look at banshee, there is an option in GConf to tell banshee to further manage your library (not just at importing files), this might be also an option for F-Spot, when the plug-in is finished. Like Bengt, I had yesterday also the "idea" for an plug-in for this, just I do not have the C#-skills. Thanks for your replies, and sorry if some of my words were choosen unwisely.
I'm moving from digiKam to f-spot because I like your tagging interface and simple support for upload to picasa. Most of my photoes are already in (tediously manually sorted) folders by year. The scanned negatives ALL have extremely wrong dates. digiKam doesn't try to rearrange my folder structure on import at all. DigiKam will only allow me to update the exif date one photo at a time.. ..I really like the date adjustment tool in f-spot. I read the thread where it was discussed earlier. At present importing my images into _a folder structure that f-spot manages_ will badly break my tediously manually created folder structure. **This is because the data I'm putting in is crap.** I accept that, but using f-spot to adjust that data, at present, wont fix the changes f-spot makes to my folder structure on initial import Thanks Bengt for the workaround. It's not quite starting from scratch as you suggested... it's similar to using something like jhead (cli) before importing into f-spot... ...except its hard & tedious to adjust the date with a cli before importing into a photo viewer. Stephane Would you have these problems if the image had the 'right' date set on initial import? There is a text box to add tags on import. I'm yet to use it. It would be a sensible place to adjust the time, given your on disk structure is set up around time, rather than tags... re: breaking links when changing dates, why not add an 'opt in' checkbox or preference to (effectively) re-import the image with the correct date, automating Bengt's workaround. Anyway, I'm talking to you because I think f-spot is the best of quite a few options. thx & regards e
*** Bug 412659 has been marked as a duplicate of this bug. ***
> This bug is not fixed yet cause, even if it looks trivial to fix, it's really > hard to do it right ant it raises a lot of concerns: > > - What about people relying on a fixed path for their photos (symlinks, used by > other applications, 'Recent Files', for backups, ...) > > - What to do with unmanaged photos, esp. if the user defined tree is, like > f-spot one, sorted by date (or month, or whatever...). How to guess if a photo > is managed or not ? > > - What's the correct destination if, in the f-spot livetime, the user changed > the path to the Photos directory ? > > - What to do if, while moving an image to a new folder, the destination folder > already conatains a picture with the exact same name ? Rename one of the images > ? sounds _really_ bad... Why not just give the user the option NOT to have F-spot organise their photos at all? What about just having F-spot watch a given folder, just like Rhytmbox does with music, and add them AUTOMATICALLY to the collection when new photos are found? I love F-spot's interface and features, I really do, but the way it stores photos is just terrible to my taste. Please give me the option to store them myself and use F-spot to work with them.
(In reply to comment #13) > Why not just give the user the option NOT to have F-spot organise their photos > at all? You can already do that by importing pictures WITHOUT copying them in the Photos folder. > What about just having F-spot watch a given folder, just like Rhytmbox > does with music, and add them AUTOMATICALLY to the collection when new photos > are found? There's a request filed at bug 312613 for that.
(In reply to comment #14) > You can already do that by importing pictures WITHOUT copying them in the > Photos folder. I know, but that is too cumbersome. Most times I copy some pictures to my photos directory -I do that manually to avoid F-spot's YYYY/MM/DD structure- I don't have the time to open F-spot and manually import them. Later on I don't remember if I did or not, which results in lots of pictures present in my photos folder but missing from my collection. In the end I usually just delete everything from the collection and re-import the whole directory again, but that's far from ideal and results in me using F-spot much less than I would like to.
I think we're getting sidetracked here. This bug is about f-spot ceasing to manages files that it has been asked to manage after initially taking ownership of their management. The user (that's me) has asked for them to be managed F-spot starts managing the files and rearranges everything to it's liking. F-spot then stops managing them silently. To my mind this is a serious bug. It has work arounds, but they make the program EXTREMELY tedious to put scanned negatives into. EXTREMELY tedious. Importing files, editing their exif time, removing them and reimporting them is... ...work for a program, not a person... I really don't think there's any other way to see it.
My small extension for finding Orphans is slowly getting closer to a Release Candidate stage, and it will most likely include a button to fix photos that are not stored in the correct directory according to their EXIF time stamp.
You rock
Hello, Is it possible to have a short status on this feature request, please ? I would like to see if I can help on this, by either testing the patches or even help coding. bug 302566 is becoming quite old now and I am not sure whether the code is in the SVN respository or not. Basically I would like to know the following : - Is this work still being worked on ? - Are the patches in bug 302566 still valid (and rebased upon the current SVN version) ? - Have the patches in bug 302566 been already commited to SVN ? On my side I am thinking about making a short perl or python script which will move files to the correct directory by date according to exif data and update f-spot db of course. This will not be a very hard work and of course this will be temporary until an extension is delivered. The thing is I really need such a tool for backup purpose ... Be sure I will post the script here when finished ! Thank you very much for your help !
(In reply to comment #19) > Is it possible to have a short status on this feature request, please ? The extension for f-spot orphaned photos and move photos based on date is being worked on, and maybe will even land to the official repository not far in the future. otherwise it will be uploaded here.
Ok, thank you for the status.
*** Bug 541760 has been marked as a duplicate of this bug. ***
As I was recently bitten by this bug too I figured I'd put my workaround here: If you have photos without exif data you can just touch them to the right date before importing them: touch --date='2002-10-02 00:00' *
*** Bug 561901 has been marked as a duplicate of this bug. ***
*** Bug 565264 has been marked as a duplicate of this bug. ***
*** Bug 571405 has been marked as a duplicate of this bug. ***
woooza, this is quite an old bug and sadly still open and itching. So here are my 2ct (mostly to/on comment #9) what about an opt-in tick box to move the file to the according folder when changing the date? This would certainly not solve all the issues listen in #9 :-/
@seb: that would be nice (preferrably checked by default). However, I would be most interested in a tool that will allow me to retroactively fix all the photos that are in my collection that are now misplaced due to this bug. Whether it's a CLI tool, a command within f-spot or even some workaround method within f-spot isn't that important, but I would like my photos to be correctly sorted.
Created attachment 154575 [details] db check script Here's a script that will check for such errors. The database schema changed since I wrote it so it'll need some adjustment. You should also be able to hack it into fixing it fairly easily.
Thanks @Johannes. However, that really seems to solve none of the problem. The script appears to find images with problems (assuming it's updated to how f-spot works now, which I'm not able to do myself). But then, given a list of the images affected by the bug: how do I fix them? Individually searching for each of them in f-spot is not an option. It appears that @Bengt Thuree is working on something in #17, but the last life signs on that are from 2007-12-03...
But fixing it should be easy enough, you move the file on the filesystem and update f-spot's database from the script? In fact I am pretty sure I did that at one point to fix up all my scanned images, but seem to no longer have the script, or maybe I just did one on the fly.
You may well call it developer-easy, but it certainly isn't enduser-easy.
Well, yes, that is true. I don't really have time right now to help you out fix up the script, but maybe somebody else can take it as a basis.
F-Spot has moved to https://github.com/f-spot/f-spot/issues If this Bugzilla ticket is still valid in a recent version of F-Spot, please feel free to post this topic as a ticket in the F-Spot project on GitHub. Closing this report as WONTFIX as part of Bugzilla Housekeeping as we are planning to shut down GNOME Bugzilla in favor of GNOME Gitlab.