Skip to content
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

Add support for 7zip compressed ROMs #133

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ashishekka97
Copy link

Apparently, the apache commons compress' 7zip implementation does not support streams.
This PR uses the SevenZFile API rather than the stream implementation.

@Swordfish90
Copy link
Owner

Swordfish90 commented Nov 28, 2020

Hi @ashishekka97 . Thank you very much for this contribution. I'm sorry, but I was not aware apache compress did not support compressed input streams and you're definitely right there is no straightforward way to do so.

This is implementation looks good from a code standpoint, but I do have a couple of concerns:

  1. Wouldn't this copy each 7z file into the cache directory every time a scan is performed?
  2. What are the performances of this approach? Have you tried scanning thousands of 7zip roms?

@ashishekka97
Copy link
Author

Hi @Swordfish90.

Yes, your concerns regarding the performance during scanning are valid.

  1. It will copy each 7z file into the cache directory for each scan.
  2. I haven't checked by scanning a large number of 7z files, but the operation indeed would be too slow. I'll check on this one.

Meanwhile, I'm still looking for another viable approach, i.e to use android's Uri to get the file directly (perhaps extracting the actual filePath??).
Let me know if you have any ideas regarding this.

@Swordfish90
Copy link
Owner

Hi @ashishekka97 ,

With the latest Android versions, it's no longer possible to retrieve a standard file path from content providers so the only option would be to pass from the ContentResolver.

The only option I can think of is this to retrieve a file descriptor and pass it down to some C++ code which can open 7z files with a native library which extract the info Lemuroid requires (hash, filename and size). This is probably required only during the scanning phase, afterwards, we can probably live with the double copy.

Needless to say, this is a lot more involved than I originally thought this issue would be...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants