Feature Request: Configurable value for nested RAR levels to extract / Issue: CRC errors on nested RAR sets

[piefke84]

First of all, this is an amazing piece of software, I am very impressed by the speed given the different layers required to make it all work... Great work!

I guess I have a slightly different use case than most other users. I have a collection of NZB files that I want to access via AltMount (e.g. for ease of access and to copy single files). These NZB files come in two flavors:

1. NZB is obfuscated by a passworded RAR archive and should be unpacked before mounting. The password-protected RARs may contain another nested RAR set which should not be unpacked (e.g. I want to be able to access the actual RAR files within the password-protected RAR set).
2. NZB contains the data I would like to access directly (e.g. not obfuscated by a passworded RAR archive), no unpacking required at all

For NZB type 1, AltMount works fine and displays the content of the password-protected RAR archive as expected. However, I noticed the following:

1. All files inside the password-protected RAR are displayed in the root level. Any subdirs within the RARs are not preserved (e.g. MyContentInTheRar/Subdir/file.txt is displayed as MyContentInTheRar/file.txt)
2. If the password-protected RAR set contains a nested RAR set, the files are displayed correctly (e.g. no nested unpacking). Some files however fail checksum checks (CRC32/SFV). This does only affect the last RAR file of the nested RAR sets (e.g. rar->r18, r18 will be broken). I did compare the correct file (manually downloaded from the NZB) and the file presented by AltMount. The AltMount file does contain a few bytes of extra data at the file end (approx. 10 bytes, but varies). See screenshots below.

Correct file (last bytes highlighted):

Corrupt file (same bytes highlighted, note the extra bytes at the end):

For NZB type 2, AltMount extracts the RAR content and displays the content of the RAR set (which is intended, but not suitable for my use case).

It would be great to have the following features/fixes:

Have a configurable value for RAR levels to extract:

-0: Display NZB content as is, no extraction at all
-1: Extract first level RAR set, display content as is (even if it contains a nested RAR set)
-2: Extract RAR sets included in the obfuscated RAR set
This would allow flexibility on what to display from the imported NZBs. It would be preferred to be able to configure this per imported NZB (for example when using the "Queue" page to import NZBs).

Find root cause of the extra bytes on a nested RAR set

I understand that the few extra bytes are not an issue for most use cases (e.g. using *arr stack integration with JellyFin for media files, etc.), however as explain in the paragraph above, it is a concern for my particular use case. I am happy to provide an example NZB for testing.

Preserve subdir structure within nested RAR set

A file MyContentInTheRar/Subdir/file.txt in a nested RAR set should be displayed as MyContentInTheRar/Subdir/file.txt.

[piefke84]

I did some more research on the CRC errors with nested files in password-protected RAR archives. I think altmount is adding some random data at the end to fill up the gap to the next 16 bytes. That is also why it is only happening on the last part of the multi-part archive, all other parts are cleanly dividable by 16 bytes already. It happens on all files, not only RAR archives.

Original file: 856 bytes (856/16=53.5) --> not dividable by 16!
Broken file; 864 bytes (864/16 = 54) ---> dividable by 16! 8 random bytes added

[MythodeaLoL]

i see this CRC bug in past, with rclone, maybe javi will need the file to test, keep nzb file in your hand.

[javi11]

@piefke84 can you please share the file with me in discord?

[piefke84]

@piefke84 can you please share the file with me in discord?

Yes of course! I looked for a Discord link, couldn't find any though. Could you send it across please @javi11?

[javi11]

https://discord.gg/HeWCk3fxX

[javi11]

Issue fix it in last commit to main

[piefke84]

Hey @javi11, thanks for looking into this, much appreciated.
I pulled the latest Docker image ("dev" tag), now running version "dev-c93e14131924226c750809e884917b7dfaf8c5db (c93e141)", which should be the latest commit.

I tested the following:

• re-checked CRC on an already imported NZB
• re-triggered NZB processing via the "Queue" dashboard, then re-checked CRC
• added a new NZB and checked CRC once imported

All tests failed with the same result as described in my initial post, still seeing the additional data being added to the broken files.

Anything I am missing? How did you test?

[javi11]

Ok, once the dev build ends, you can try. You will need to import the file again

[piefke84]

Awesome, you fixed it @javi11! Confirmed working by:

• re-triggered NZB processing via the "Queue" dashboard, then re-checked CRC
• added a new NZB and checked CRC once imported

Should I open an additional "issue" for the other feature requests I mentioned in my initial post?

[javi11]

I assume is the folder structure not preserved? Can you share an nzb having that issue?

[piefke84]

NZB for the subdir preservation issue shared in Discord 👍

The last thing on the list would be the feature request for "Have a configurable value for RAR levels to extract". Let me know if I should separate this one into it's own issue. Cheers!