Replies: 2 comments 1 reply
-
Dropping a few notes here to help anybody else that might run in to similar issues I did. Ran in to this as well. I had some of the individual sub dirs in outputs as symlinks instead of the whole outputs folder. There wasn't any reason to keep it split like that, so I moved the whole outputs dir to a sysmlink. Next issue was minor, "Include images in sub directories" is disabled by default. Didn't know that setting existed on this fork. This fork scans a lot slower than the original. Thought maybe it was still not working, but after several minutes it threw an error when hitting a file that I had moved in the meantime. Even though I have been cleaning out the outputs folders once in a while, it still had a stupid number of images stored. Getting the totals to <15k seems to make it happy. |
Beta Was this translation helpful? Give feedback.
-
@Kadah Thanks for collecting the notes here.
That's strange, I don't think I have changed anything in the scanning part. It certainly shouldn't take minutes. Did you use the main branch?
My biggest folder just happens to have just under 15k... I'll try making a bigger folder and test it on that. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
When I merged #1, image browser seemingly stopped working for me. The reason for this is, that my outputs-directory is a symlink to a hdd. I suspect other people do the same.
So to get it running for now, I've changed realpath to abspath. While not optimal, this at least still takes care of ".." traversals.
Beta Was this translation helpful? Give feedback.
All reactions