Open GoogleCodeExporter opened 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
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
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
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
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
Original issue reported on code.google.com by
p...@sphardy.com
on 17 Jul 2011 at 1:49