Describe the bug
Our data structure is relevant perhaps: We have over 1600 folders containing a wide variety of 3d and technical files, but each folder always contains exactly 1 JPG image which shows what the product looks like. We love Tagspaces, and want to use it to classify all of these products by tagging each image file in each folder with categorization info. This would allow turbocharged powerful file system searches thanks to how the tags are in the file names. We're hitting a work flow problem though.
Tagspaces generates thumbnails if you visit a folder, but this is impossible with so many folders. We need Tagspaces to recursively generate its own thumbnails without human involvement.
Running a search for "jpg" from the Gallery Perspective seems to initiate some thumbnail generation, but it always seems to halt or crash after only producing maybe 60-100 thumbnails. We upgraded to pro to have better filter controls. We also hoped that this glitch would be resolved in pro, but no change. We can now do powerful search filtering to simulate a "gallery" experience, but Tagspaces just won't generate thumbnails reliably.
We have repeatedly closed tagspaces, deleted all .ts folders at the file system level and re-launched in the hopes of finding some pattern but we're stumped at this point. Tagspaces never behaves gracefully in the above use case. Manually recreating the index does nothing to initiate thumbnails it seems. Under advanced settings we disabled the option to run indexing and thumbnails in separate processes, but see no change in behavior. We're stumped.
To Reproduce
Steps to reproduce the behavior:
Have thousands of nested folders with one jpg image in each folder. (Plus other extensions which we use the location settings > ignore pattern pro feature to suppress since they aren't relevant.)
In gallery perspective, search for "jpg"
If it doesn't lock up and freeze, it will abort after a short while of intense thumbnailing activity and enter a funky state whereby you can't click anything or get anywhere.
Clicking an un-thumbnailed image doesn't generate a thumbnail. Re-running search doesn't do it. Only restarting Tagspaces seems to allow it to work normally... Until again running the "jpg" search which allows it to generate a few more before again failing.
Expected behavior
It should simply generate thumbnails when it finds an image that is lacking one on a query results page. It might take a long time in the beginning, but that's what computers are good at: showing progress meters while doing repetitive processing jobs. ;-) A "regenerate all thumbnails" feature would be great...
Screenshots
Screenshots aren't interesting, it's merely a search query for "jpg" with lots of discovered images - some thumbnailed, most not..
Desktop Application:
Operating System: Linux Mint, up to date.
Browser - n/a
TagSpaces Version 5.9.2 pro, installed from .deb
Additional context
Small things noticed:
seems to cap out at 1,000 search results. Hitting that point is very quick as my computer is quite powerful. This tells me that if there is an arbitrary 1,000 result limit, it should be raised to 10 million - and spin off a background thumbnailing process - akin to how Kodi, Thunderbird, Nemo file manager and other programs seem to handle background cache generation.
Gallery view enters a funky state each time this 'jpg' query is run whereby you can't navigate any more. Going to the folder view kind of returns things to normal, but restarting the app seems the only foolproof way to get it back to 'normal'.
When searching for 'jpg', TagSpaces sometimes locks up (cpu drops from very high to zero and UI freezes. Only an app kill / restart is possible.
Describe the bug Our data structure is relevant perhaps: We have over 1600 folders containing a wide variety of 3d and technical files, but each folder always contains exactly 1 JPG image which shows what the product looks like. We love Tagspaces, and want to use it to classify all of these products by tagging each image file in each folder with categorization info. This would allow turbocharged powerful file system searches thanks to how the tags are in the file names. We're hitting a work flow problem though.
Tagspaces generates thumbnails if you visit a folder, but this is impossible with so many folders. We need Tagspaces to recursively generate its own thumbnails without human involvement.
Running a search for "jpg" from the Gallery Perspective seems to initiate some thumbnail generation, but it always seems to halt or crash after only producing maybe 60-100 thumbnails. We upgraded to pro to have better filter controls. We also hoped that this glitch would be resolved in pro, but no change. We can now do powerful search filtering to simulate a "gallery" experience, but Tagspaces just won't generate thumbnails reliably.
We have repeatedly closed tagspaces, deleted all .ts folders at the file system level and re-launched in the hopes of finding some pattern but we're stumped at this point. Tagspaces never behaves gracefully in the above use case. Manually recreating the index does nothing to initiate thumbnails it seems. Under advanced settings we disabled the option to run indexing and thumbnails in separate processes, but see no change in behavior. We're stumped.
To Reproduce Steps to reproduce the behavior:
Expected behavior It should simply generate thumbnails when it finds an image that is lacking one on a query results page. It might take a long time in the beginning, but that's what computers are good at: showing progress meters while doing repetitive processing jobs. ;-) A "regenerate all thumbnails" feature would be great...
Screenshots Screenshots aren't interesting, it's merely a search query for "jpg" with lots of discovered images - some thumbnailed, most not..
Desktop Application:
Additional context Small things noticed: