Facing the same issue. Most responses point to thr RAR5 Mega download links but the Windows link no longer works.

Can someone re-upload, please?

Windows file no longer available.

[raztoki]

The missing library(s) should be be resolved within the next day or two.

raztoki

[raztoki]

The missing library(s) should be be resolved within the next day or two.

raztoki

[pspzockerscene]

Please be patient / bitte abwarten!

-psp-

[Jiaz]

I will replace the links in first post with working ones later this day or beginning of next week, depends on how much time I'll find today. sorry for the inconvenience and delay

none of the files work :(Ii really need this if anyone can re-up or sned me in the NEW direction to find the files?

I finally managed to get it working for Arm7 (WDMyCloud) and here I'm sharing the compiled files:
**External links are only visible to Support Staff****External links are only visible to Support Staff**

The files from .bismarck didn't worked for me and I got errors stating, that the extension couldn't find the path "Linux-arm2". I now realized one could set this path either through config, webinterface or app (in the settings for Extraction Extension) - I've chosen the difficult path and recreated the jar-files by adding a "Linux-arm2" folder to sevenzipjbinding1509LinuxArmVersion.jar.

There's still a problem left with JD crashing, but this could be due to running out of RAM (512 MB). At first the Archive Settings on the download page were still greyed out for me and then it started working after some time and I were able to select any of the provided options.

In the end all needed info was written in this thread, everyone can compile this for themself from source if you need the RAR5-Support soonTM. Just make sure u got cmake and that you checkout the correct version 15.xxxx.

The above folder includes my compiled Arm7-Version (32 bit) and the modified version of .bismarck, which should also be 32 bit, but isn't being recognized or faulty for me. I don't want to test it but probably the lib7-Zip.so from bismarck must be replaced with the ones inside sevenzipjbinding1509LinuxArmVersion.jar. I compiled with Debian Buster.

If you also want or need to recreate the mentioned jar-file, just issue "jar cf sevenzipjbinding1509LinuxArmVersion.jar Linux-arm Linux-arm2 META-INF sevenzipjbinding-platforms.properties" i.e. inside a folder where you got all the needed files. All files can be retrieved from the source you compiled. 2 files should be in the Linux-arm folder inside the source. The structure of the jar file can be easily looked up by opening sevenzipjbindingLinuxArmVersion.jar (the original one) with 7zip or similiar tools. The files inside Linux-arm and Linux-arm2 are just the same.

@Jiaz I think you shouldn't wait for Boris to update the source, since you probably don't know when he is done. Instead you should issue an update, since it seems to much people struggle with setting this up correctly and there's definitely a need for it. I appreciate your work, but your choice to wait isn't the right way to manage this problem and additionally causes a lot of work, since the compiled files are down. Why does it take so long to upload some files? Probably no backup, right? Sorry, but this is unacceptable. Additionally I could've helped out some ppl earlier if this forum wouldn't be more restrictive than Area 51.

Oh yeah, right ... the links aren't shown for users ...
type in the mega url and add the key: #!BOwXhAZL!BnvXEZFvU2J27PDeB3Vl_N_kiZu2QvcVVhEfnTLPm98

Die Edit: Even 2 years ago Jiaz wrote the same: https://board.jdownloader.org/showpo...16&postcount=2 and even back then it were about RAR5-Support. Think about it: Having a large thread with lots of ppl complaining, let bismarck and others do the work and then be like "nah, just waiting" compared to "okay, okay, let's update, what could possibly go wrong". Have fun on your holidays, but when you're back please for ffs update this specific lib. I don't care anymore, the extraction is functional at least, but you could spare others the hours they need to invest in what you could fix within minutes. (w/o compiling)

[Jiaz]

@Hass: Thank you very much! I will include your lib on first page when I refresh the links .
Thanks for the detailed step by step and side details

About your crashes, do you have hs_err file in your JDownloader folder that might hold additional information about the crash and possible cause of it.

[Jiaz]

Originally Posted by Hass

Why does it take so long to upload some files? Probably no backup, right? Sorry, but this is unacceptable.

I've got backup of the files but I didn't find time yet to create new account and upload there. We don't want to upload to account because we're still fighting the copyright claims and changes are high that the new links will be abused again....

[Jiaz]

I just uploaded first bunch of files to first post. rest will come tomorrow

Originally Posted by Jiaz

@Hass: Thank you very much! I will include your lib on first page when I refresh the links .
Thanks for the detailed step by step and side details

About your crashes, do you have hs_err file in your JDownloader folder that might hold additional information about the crash and possible cause of it.

Nope, I can't find any file (used find inside jd-folder and the logs didn't got any hint what happened. Since I had enough I set up a quick and dirty cronjob to restart JD when the service isn't running. Later I found out some files are damaged but the archives got deleted, like they should. So yeah, like I said, it's quick and dirty and doesn't help much.

Don't use the file Armv7 from .bismarck I included, like mentioned it doesn't work, which can be easily found out by checking the version in the extension-log.

The only more information I can give: The "folder" of links I'm extracting contains several archives with partX to partY. Actually >20 splitted archives and a total of >200 archives. After like 2-3 (in-)complete extractions JD seems to crash. I don't use the Shutdown Extension so this could also not be the cause. To be more specific the last extraction before the (assuming here) crash, is incomplete and the resulting file isn't usable. For sure 512 MB RAM isn't much, but this NAS is able to extract much larger archives with unrar (nzbget). And yes I know, JD utilizes 7zip for rar-files - spent way to much time on this now.

[extramalto]

Originally Posted by Jiaz

I just uploaded first bunch of files to first post. rest will come tomorrow

Thank you.

Btw, the original structure of sevenzipjbindingLinuxArmVersion.jar is:
- Linux-arm
- Linux-arm2
- Linux-arm3
- Linux-armpi
- Linux-armpi2
- META-INF
- sevenzipjbinding-platforms.properties

I now found out the files inside the "Linux" folders are actually different and I'm not sure if the files in Linux-arm work or when this path is normally used. From what I've read my version should at least work with Raspi 3 and even 3 B+. Depending file-size Linux-arm2 and Linux-armpi2 contents have the same file-size.

I will add an even newer version (1602) later, maybe I can fix errors this way.

Alright, here in short how to compile (I'm not a crack and I can't solve occuring errors - just install cmake, git and dependencies and maybe you're good to go):

• git clone github[dot]com/borisbrodski/sevenzipjbinding[dot]git SevenZipJBinding (replace [dot] with ...)
• cd SevenZipJBinding
• git checkout bind_16.02 (or git checkout migrate-to-15.09-try2)
• cmake .
• make
• make package
• mkdir -p jar-package/{Linux-arm,Linux-arm2,META-INF}
• unzip sevenzipjbinding-16.02-2.01beta-Linux-arm.zip (or check for name of created zip)
• mv sevenzipjbinding-16.02-2.01beta-Linux-arm/lib/sevenzipjbinding.jar jar-package/sevenzipjbinding1602.jar (or replace 1602 with 1509 and choose correct path for unzipped files)
• echo jar-package/Linux-arm/ jar-package/Linux-arm2/ | xargs -n 1 cp -a Linux-arm/.
• cp MANIFEST.MF jar-package/META-INF/ && cp sevenzipjbinding-platforms.properties jar-package/
• cd jar-package
• jar cf sevenzipjbinding1602LinuxArmVersion.jar Linux-arm Linux-arm2 META-INF sevenzipjbinding-platforms.properties (or 1509 instead of 1602)

Done!

Short explanation of what we're doing here:

1. clone the repo and choose a branch (15.09 and 16.02 are currently the best choices)
2. compile the source to match your system
3. create folders and mime the structure of the original sevenzipjbinding<platform>.jar
4. put in generated files from our compilation
5. create a jar-file from the prepared structures for our platform

Now just copy the generated files to your jdownloader/libs folder, restart jdownloader, maybe delete jdownloader/tmp:

• sevenzipjbinding????.jar
• sevenzipjbinding????LinuxArmVersion.jar

If everything works, clean up by issuing "cd .. && cd .. && rm -R SevenZipJBinding". No guarantee this works, but it should make the process more clear. The commands are slightly different for other version of sevenzipjbinding. To check if the correct version was loaded, look up newest "ExtractionExtension.log.0". It should have a line like this:

--ID:36TS:1565211714581-8/7/19 11:01:54 PM - [org.jdownloader.extensions.extraction.multi.Multi(isAvailable)] -> Supported SevenZipJBinding|Version=15.09-2.01beta|RAR5=true|CPU_ARCH=ARM|OS_FAM=LINUX|OS=DEBIAN_BUSTER|64Bit_JVM=false|64Bit_ARCH=false

@Jiaz, I was going through the logs again and found this crash-log:
**External links are only visible to Support Staff****External links are only visible to Support Staff**

On first sight it doesn't provide much more info, but maybe you have use for it. The 16.02 version doesn't works for me aka isn't being recognized by JD and falls back to 4.65.

I'm attaching the 16.02 armv7 32-bit version, maybe it works for someone else:
**External links are only visible to Support Staff****External links are only visible to Support Staff**

And because of restrictions:
Armv7 32bit 15.09: mega url + #!deAUkYjY!9kirUFJRNt7kLpxybQLYdpeXydF82Q4-_KlMK1LnCYI
Armv7 32bit 16.02: mega url + #!UOBQVS4Y!Lx0AInDJQ0b0h6Td2s0i4hGg_A0RST7LDUyo3i8b5ac

[Jiaz]

@Hass: Thanks for sharing details step-by-step and leading through the compilation process

Originally Posted by Hass

On first sight it doesn't provide much more info, but maybe you have use for it. The 16.02 version doesn't works for me aka isn't being recognized by JD and falls back to 4.65.

the filenames must start with sevenzipjbinding1509. JDownloader prefers these files over the original ones, so you can easily downgrade/revert by just deleting those files. so the filename scheme must be the same. it's just a quick solution to have different versions in same folder and I know that it works fine with 16.02 too just keep the same names in place

[Jiaz]

Originally Posted by Hass

Don't use the file Armv7 from .bismarck I included, like mentioned it doesn't work, which can be easily found out by checking the version in the extension-log.

I know those working for some ppl. It's important to have the correct Arm Version. Choosing wrong compiled version will result in crash!

Originally Posted by Hass

For sure 512 MB RAM isn't much, but this NAS is able to extract much larger archives with unrar (nzbget). And yes I know, JD utilizes 7zip for rar-files - spent way to much time on this now.

I don't think this is connected to memory as I know about devices with less memory working fine. it might be caused by bugs in extraction library or buggy java version.
what java version are you using? errors in extraction library will crash java for sure. do you encounter thr crashes with 15.09 and (soon to be tested) 16.02?

Originally Posted by Hass

[*]echo jar-package/Linux-arm/ jar-package/Linux-arm2/ | xargs -n 1 cp -a Linux-arm/.

No need to change the folder/naming/id. JDownloader will try out arm compilations in following order, Linux-arm2, Linux-arm, Linux-arm3
You can have multiple versions in same jar file and you can also specify/force to use a specific ID with -DsevenzipLibID=Linux-XXX JVM Parameter. JDownloader
will rememeber this one and try it again on next startup, so no need to use that parameter each time

@Jiaz okay that's a lot, but I try to bring some light in misunderstandings:

1. I manually created the jar-files because I got an error stating that JD cannot read the properties-file. I then found out the Linux-arm2 it was searching for wasn't part of my jar-file and this way lead to that error. If I compile on my machine only Linux-arm is being created.

2. Maybe I misunderstand you but JD should make a check on the files to find the newest version so it should prefer sevenzipjbinding1602 over sevenzipjbinding1509? Just look at the links I added, I think I sticked to that scheme for naming.

3. The java version which is probably used (java -version):
java version "1.8.0_151"
Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
Java HotSpot(TM) Client VM (build 25.151-b12, mixed mode)

Edit: My init-script also makes use of Java 8: JAVA="/usr/lib/jvm/java-8-oracle/jre/bin/java"

4. I checked 16.02 again but I can't get it to being recognized. Also my platform is Arm7l to be more specific.

5. The crashes just happened with 15.09, since I weren't able to get 16.02 running. After my testing I were able to extract like 5 or 6 splitted archives and there were no error. Then later JD shutdown, so it might not be caused by extraction but something else. Maybe you're right and my Java setup is faulty.

[Jiaz]

1.) Those are just identifiers, by default the Library only creates one default but you can rename it whatever you want. For plattforms with different CPU, like ARM, JDownloader tries multiple versions, like Linux-arm, Linux-arm2, Linux-arm3. You can also give them fancy names like Nice-extraction and just specify the id manually with -DsevenzipLibID=Nice-extraction

2.) The 1509 naming scheme is just a workaround to allow to place newer library besides original ones and in case of errors, just delete those and JDownloader will fallback to original one. You can also just leave the names as JD ones and overwrite the files. That way there is no easy *downgrade*. Maybe I'll add 'use highest' but can't tell when I will find time for it.

3.) thanks, maybe try with newer version, for example from here adoptopenjdk.net/releases.html

4.) did you rename the files to 1509 naming scheme? any errors shown in log?

5.) thanks for the info

@Jiaz:

Sorry, I still dont get it: Do I have to rename the files 1602 to 1509 to get it working, since JD isn't checking for highest number? I'm compiling and trying it again now and report back.

Do I need to use JDK8 or should I get another version to test with? Earlier in this thread I read you could also compile for specific java version, maybe that parameter does the trick. (I always ran without specifying anything more)

Jdownloader is running simultaneously, maybe it crashes again, if not it is probably a faulty sevenzip-lib, else I'm out of ideas.