-
Notifications
You must be signed in to change notification settings - Fork 162
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
open folder / limitation? #868
Comments
Bug, but we can not reproduce it, subdirs are still well scanned on our side By the way, using the command line version may be better for such slow task ;-). |
You mean the memory usage for the latest version? Talking for version 24.05.1: thanks for the hint with the cli. will give it a try |
Could you spot a minimum directory structure that demonstrate such issue?
Weird there, we don't see what we could have changed which would have an impact there.
classic usage: |
i will try, give me some time.
just played around with the cli and took some notices from task-manager: 32-bit cli: the task is starting, the memory usage is increasing and the whole task stops @ ~100mb memory usage. the output json is 0byte. 64-bit cli: it works! the memory usage is ~150mb (highest peak), the output json is complete with every entry (as in v23 gui) |
So something related to 32-bit (GUI still uses the 32-bit build internally, the 64-bit is for the Explorer integration) vs 64-bit but not the total memory usage, fun... Maybe a file makes MediaInfo to try to temporary allocate a big amount, it would be great if you can find which file(s) are the trigger for the missing output, and then share a use case (email at [email protected] if the link can not be shared publicly). |
tried it with: it fails when opening "D:\test". it doesn't show up any result. It seems, like the new dialog is not going recursively through the sub-directories. it succeeds when opening "D:\test\Some.Movie.Name" |
Also with 32-bit CLI?
The new dialog provides the same info (a path name) to the underlying library so it should not have any impact, weird. |
test-folder32-bit-cli: working original-folder32-bit-cli: fails as noted above i think there are 2 bugs. the new dialog in 24.5 and the issue that not all results are processed |
From what you write, it seems that... I can reproduce this issue, I check why.
Sorry, still need your help on this one, for knowing which file is creating the issue. |
i will try to help you. could not figure out if its because of a certain file yet. |
I can reproduce the subfolder issue. The new dialog returns the path of the selected folder without a trailing backslash and passes it to MediaInfoLib. What happens though is at the check before this part. |
Thanks @cjee21, so seems to be a BCB issues? |
I can make a patch to just check that it returns a non-empty directory path and not care about whether there are actually files in it. Tested that it works on my demo folder with sub-folders and many files. PS By the way, have you seen my branch for implementing WebView2 (#857 (comment))? Wondering if you want to proceed with that. If so I'll make a PR for that. |
Please do.
Still on my todo-list. |
Done
Okay, no hurry. Just wondering if you have seen it. |
I cannot reproduce the other bug with my sub-directories that have a total of 90+ files. All of them load after waiting for some time. I don't see any change for Windows GUI in regards to opening folders in version 24.01 or 24.01.1 (v23.11...v24.01.1#diff-ad45e0d3e6311c81d8158055867ab84f3dd36b245a048b283123f0e1b01565bb). |
yeah, i can reproduce it only with folders with 1500+ files. it's not the folder count or files count. i will run some more tests |
the bug is also in the cli, not only gui. |
Then likely in the MediaInfoLib which I know nothing about. |
On my side. @schimschewski, this ticket is for the GUI issue and it will be closed when the GUI issue is resolved, please open a MediaInfoLib ticket for the other one common to GUI and CLI. |
i'm using very often the "open folder"-feature to export the entire movies in subdirectories e.g.
this was working like a charm in <= version 23.x
since 24.0.1 there seems to be a limitation or some cache problems, it does not show up all results. reopening the folder results in getting some missing files (sometimes only 5 and 10) from the first attempt.
since 24.0.5 it does not show up anything, seems like no recursive search in subdirectories is done.
it this a bug or an expected behaviour? see screenshots attached.
The text was updated successfully, but these errors were encountered: