stefrobb / folders2flickr

Automatically exported from code.google.com/p/folders2flickr
1 stars 0 forks source link

Sets seem to be recreated on each run #9

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Upload images 
2. Run uploader a 2nd time - no changes to source
3. Watch the debug.log as all sets are reanalyzed/recreated

What is the expected output? What do you see instead?

I would expect to see very little as no changes have been made, however the 
uploader seems to go through the set creation process from the very beginning 
which can take a long time & is typically unnecessary. I would expect to only 
see this if new photos were to be in the local source to be uploaded though 
perhaps a an option would be useful to enforce the current behaviour in case 
sets are altered via the Flickr web site and I wish to remove those changes

What version of the product are you using? On what operating system?

Folders2Flickr v1.0, Debian Linux running python 2.6

Please provide any additional information below.

Folders2Flickr is working perfectly correctly for me - this issue is more an 
possible optimisation to improve performance. If I create a single new local 
folder with images, F2F properly determines the change and only uploads the new 
images which takes a fairly short time - but then can spend over an hour 
reanalyzing the sets before finally creating the one new set that I require. An 
option to prevent the full reanalysis would be a welcome improvement

Original issue reported on code.google.com by p...@sphardy.com on 17 Jul 2011 at 1:49

GoogleCodeExporter commented 9 years ago
Just rereading Defect #8 
(http://code.google.com/p/folders2flickr/issues/detail?id=8) - maybe this is 
the real source or significant contributor to the apparent slowness on large 
collections? 

Original comment by p...@sphardy.com on 17 Jul 2011 at 1:52

GoogleCodeExporter commented 9 years ago
This is actually more of a feature, the tool is reanalyzing the folders as part 
of the "restore" process e.g. in case you have removed sets on flickr. The more 
the tool will rely on the information stored localy in some DB the easier it 
can get off sync with flickr. I am not sure yet what is greater problem - this 
will require more thinking through ;)

Original comment by pkola...@gmail.com on 1 Aug 2011 at 3:52

GoogleCodeExporter commented 9 years ago
Understood - and it is working well 

I'm using the app to create a private "cloud backup" of my images but which is 
easily accessible, and so will never intentionally touch the sets created by 
folders2flickr. But I checked and it currently takes about 4 hours to run for 
an archive of 13k images even when I've made no changes either locally or on 
flickr. When I do upload new images, any new set created  is invariably the 
last set to be created (perhaps due to my naming convention) which means I 
can't even interrupt the app and so why I suggested that the check might be 
made optional?Eg A switch to disable the check? At least for files already 
uploaded

Original comment by p...@sphardy.com on 1 Aug 2011 at 11:00

GoogleCodeExporter commented 9 years ago
I guess a switch should not be a big issue... I'll put it in the next release.

Original comment by pkola...@gmail.com on 2 Oct 2011 at 7:53

GoogleCodeExporter commented 9 years ago
Hi and thanks for this great app! I've uploaded 150Go of pictures and I'm now 
facing the problem described in this thread.

Did you create this switch to give us the option to not recreate all the sets 
on each run?

Original comment by gawai...@gmail.com on 22 Nov 2013 at 10:05