Scan folder recursively misbehaviour #297
Comments
|
hi, thanks for reporting. the preview tiles do not properly handle recursive scans. this is because it might become very complex (i.e. if the root folder is selected) and due to design issues in our loader. I will keep this issue open, but it might take a while because we need to redesign the loader to properly fix this behavior. best, |
|
It has been 20 months. Any updates? Current status on arch linux running nomacs v3.17.0 with "Scan folder recursively" set appears to be that it displays images found in one of the directories that was found recursively. |
|
Noticing similar behavior with it not including subfolders. Any plans to implement now that it's been a couple of years? This is on Linux using version 3.17.0 |
|
nomacs 3.17.2206 [x64] (Aug 13 2020, Portable), OpenCV 4.3.0, Qt 5.14.2, Microsoft Windows [Version 10.0.19045.2846] — same. Do I understand correctly that "Scan Folder Recursive no longer works" (#797, Aug 8, 2021) discusses the same problem of not being able to display all images from all subfolders of the current folder, as implemented in IrfanView? |
|
seeing the same issue here, still present in 3.19. |
|
it looks like the code that's supposed to do this never worked. from the original implementation (0da0072) shipped in 1.6.4, this line was already commented: nomacs/ImageLounge/src/DkCore/DkImageLoader.cpp Lines 1686 to 1687 in e4e0746 that code is still there, unchanged. i wonder why? maybe recursive scans didn't work so well? actually, scratch all of that, QDirIterator is supposed to handle recursive parsing on its own, something else is going on here. the problem is the "recursive" parser is explicitly built (since the beginning) to stop at the first folder with images: https://github.com/nomacs/nomacs/blob/master/ImageLounge/src/DkCore/DkImageLoader.cpp#L1707-L1715 testing a patch. |
i would say so, yes. |
It seems the original code did everything to do recursion into subfolders except it explicitly stopped at the first folder with images. This made browsing folders weird; it would find some subfolder (any subfolder, not necessarily the first one listed in the file explorer) and show *that*. We change that behavior and just bite the bullet: we take *everything* the QDirIterator gives us and throw that in the QFileInfoList, which is really a QList. According to the documentation: "This operation is relatively fast, because QList typically allocates more memory than necessary, so it can grow without reallocating the entire list each time." https://doc.qt.io/qt-6/qlist.html#append That said, obviously that list can grow to be absolutely huge, but doing otherwise would need to refactor the loader into something that returns an iterator (which raises the question of why we're not just passing along that QDirIterator, probably because we're sorting things...) Closes: nomacs#797 Closes: nomacs#297
It seems the original code did everything to do recursion into subfolders except it explicitly stopped at the first folder with images. This made browsing folders weird; it would find some subfolder (any subfolder, not necessarily the first one listed in the file explorer) and show *that*. We change that behavior and just bite the bullet: we take *everything* the QDirIterator gives us and throw that in the QFileInfoList, which is really a QList. According to the documentation: "This operation is relatively fast, because QList typically allocates more memory than necessary, so it can grow without reallocating the entire list each time." https://doc.qt.io/qt-6/qlist.html#append That said, obviously that list can grow to be absolutely huge, but doing otherwise would need to refactor the loader into something that returns an iterator (which raises the question of why we're not just passing along that QDirIterator, probably because we're sorting things...) This also doesn't work so well for directories that have multiple layers of subdirectories. From what I can tell from experience, the images in the final list come out of order, and all mixed up together. For example, if you have: Photos/2024/01/01/foo.jpg Photos/2024/01/01/bar.jpg Photos/2024/01/02/quux.jpg quux.jpg might be inserted between foo and bar. On the other hand, if you have: Photos/2024-01-01/foo.jpg Photos/2024-01-01/bar.jpg Photos/2024-01-02/quux.jpg ... the new code seems to handle this fine. Either way, this *feels* to me like an improvement to the current code, but I'll let the maintainers decide of that. Closes: nomacs#797 Closes: nomacs#297
It seems the original code did everything to do recursion into subfolders except it explicitly stopped at the first folder with images. This made browsing folders weird; it would find some subfolder (any subfolder, not necessarily the first one listed in the file explorer) and show *that*. We change that behavior and just bite the bullet: we take *everything* the QDirIterator gives us and throw that in the QFileInfoList, which is really a QList. According to the documentation: "This operation is relatively fast, because QList typically allocates more memory than necessary, so it can grow without reallocating the entire list each time." https://doc.qt.io/qt-6/qlist.html#append That said, obviously that list can grow to be absolutely huge, but doing otherwise would need to refactor the loader into something that returns an iterator (which raises the question of why we're not just passing along that QDirIterator, probably because we're sorting things...) This also doesn't work so well for directories that have multiple layers of subdirectories. From what I can tell from experience, the images in the final list come out of order, and all mixed up together. For example, if you have: Photos/2024/01/01/foo.jpg Photos/2024/01/01/bar.jpg Photos/2024/01/02/quux.jpg quux.jpg might be inserted between foo and bar. On the other hand, if you have: Photos/2024-01-01/foo.jpg Photos/2024-01-01/bar.jpg Photos/2024-01-02/quux.jpg ... the new code seems to handle this fine. Either way, this *feels* to me like an improvement to the current code, but I'll let the maintainers decide of that. Closes: nomacs#797 Closes: nomacs#297
Scenario 1:
Scenario 2:
The text was updated successfully, but these errors were encountered: