skogsbrus / photo_organizer Goto Github PK

Example:

2019
    Spain
        ....
    Germany
        ....

In progress in branch add-gps.

TODO:

• QA
• Installation instructions of new libraries

Given an existing file x and a colliding file y, a third file z which collides with x but is identical to y will be stored as x_collision2 instead of being skipped (since y has already been saved as x_collision_1.

Currently, subfolders are named as the images' parent folder as follows:

photos/2013/12/party/img_001.png ➡️ restructured/failed/party/img001.png

Instead, rename them like:

photos/2013/12/party/img_001.png ➡️ restructured/failed/2013_12_party/img001.png

or, keep the folder structure:

photos/2013/12/party/img_001.png ➡️ restructured/failed/2013/12/party/img001.png

Currently, if the process is terminated (power outage, random reboot etc) and you wish to resume it, the script will need to go through all files again, including those it has already processed.

Thus, for large input filetrees it would be nice with the following workflow:

1. Backup the input photo directory
2. run ./photo_renamer.py --delete-after-copy ...

This would continually reduce the number of files in the input directory, such that if we need to restart the process, all files in the input directory are unseen.

Globbing works, but takes a lot of time for large trees.

Evaluate if there is a faster library/method than glob or if glob can collect files with different file endings

User should be able to paus and resume the process (not kill and resume).

Project lacks structure.

• Readme
• License
• Pipenv, or equivalent
• PEP8
• Installation instructions

This makes it easier to verify that all images were considered and that there hasn't been any loss of photos.

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python3.6/threading.py", line 916, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.6/threading.py", line 864, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3.6/concurrent/futures/process.py", line 295, in _queue_management_worker
    shutdown_worker()
  File "/usr/lib/python3.6/concurrent/futures/process.py", line 253, in shutdown_worker
    call_queue.put_nowait(None)
  File "/usr/lib/python3.6/multiprocessing/queues.py", line 129, in put_nowait
    return self.put(obj, False)
  File "/usr/lib/python3.6/multiprocessing/queues.py", line 83, in put
    raise Full
queue.Full

This occurs after processing 41148 images.

One theory is that processes have been throwing a lot of exceptions and putting them inside a queue, and now that queue is full.

When renaming a file to a date which already exists:

• If date and image hash is the same - abort the current copy
• If date is the same, but the image hash is not (i.e one of them has been edited), keep both and put them in /collision
  • rename them with 'collision-1' and 'collision-2' suffices etc.