Thank you, i think i found the issue.
About the scan time, indeed 4 min it's very long. it's because ManaGunZ is loading in mem all the ICON0 & covers. Perhaps, it will be better to load them in a background task...
when reading your messages with aldo i could not avoid to brainstorm a bit, im always like this sorry, heheheh
Scanning lot of .iso files to search for the ICON0.PNG or any other file inside them for sure is going to be a processor stressing task, the thread that scans the .iso is going to push the main processor core at 90% load or even more, there is no way to change that even doing the function super efficient (trying to minimize math calculations, using register variables, and tricks like that) the scan for... lets say 200 .iSO files is going to take some minutes
For the "standard user" that doesnt knows what the program is doing and the more anxious you can display an advise like "scan in progress" but still the scan is a problem because in the meantime the program needs to "pause" until it completes
The real solution is what you said... background tasks but let's take this idea further
Im not sure if what im going to say is technically posible, and no idea of how to do it, but anyway, here it goes
To make the scan (or better said, the multiple scans for every game format) it makes sense to take advantage of the CELL processor arquitecture with multithreading
http://www.blachford.info/computer/articles/CellProgramming1.html
What im thinking is to separate each scan function in a thread, one thread for PS3 ISO, another for PS2 ISO, another for PS1 ISO, another for PSP ISO, and another one for PS3 JB (raw reading from folders)
This makes a total of 5 threads
Managunz runs in the main processor core (PPE ?) so the scan threads could be loaded in the coprocessors (SPE) to run in paralell
Im not sure what is posible to do from a SPE process, but at least i think it could be used to do the math calculations needed to find the offset inside the .ISO of the files you want to access (ICON0.PNG or any other)
If the scan functions are compiled as a .sprx it needs to be the most smaller and efficient posible and compiled separatedlly with sdk, maybe there is some sample of this kind of code in one of the open source published plugins ?