JDownloader Community - Appwork GmbH
 

Reply
 
Thread Tools Display Modes
  #461  
Old 07.08.2019, 21:39
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 65,940
Default

I just uploaded first bunch of files to first post. rest will come tomorrow
__________________
JD-Dev & Server-Admin
Reply With Quote
  #462  
Old 07.08.2019, 22:14
Hass Hass is offline
Junior Loader
 
Join Date: Aug 2019
Posts: 10
Default

Quote:
Originally Posted by Jiaz View Post
@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.

Last edited by Hass; 07.08.2019 at 22:21.
Reply With Quote
  #463  
Old 07.08.2019, 22:31
extramalto extramalto is offline
Modem User
 
Join Date: Jul 2019
Posts: 3
Default

Quote:
Originally Posted by Jiaz View Post
I just uploaded first bunch of files to first post. rest will come tomorrow
Thank you.
Reply With Quote
  #464  
Old 07.08.2019, 22:39
Hass Hass is offline
Junior Loader
 
Join Date: Aug 2019
Posts: 10
Default

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.
Reply With Quote
  #465  
Old 08.08.2019, 00:20
Hass Hass is offline
Junior Loader
 
Join Date: Aug 2019
Posts: 10
Default

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

Last edited by Hass; 08.08.2019 at 00:45.
Reply With Quote
  #466  
Old 08.08.2019, 12:47
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 65,940
Default

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

Quote:
Originally Posted by Hass View Post
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
__________________
JD-Dev & Server-Admin

Last edited by Jiaz; 08.08.2019 at 12:58.
Reply With Quote
  #467  
Old 08.08.2019, 12:52
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 65,940
Default

Quote:
Originally Posted by Hass View Post
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!

Quote:
Originally Posted by Hass View Post
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?


Quote:
Originally Posted by Hass View Post
[*]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
__________________
JD-Dev & Server-Admin

Last edited by Jiaz; 08.08.2019 at 12:57.
Reply With Quote
  #468  
Old 08.08.2019, 18:19
Hass Hass is offline
Junior Loader
 
Join Date: Aug 2019
Posts: 10
Default

@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.

Last edited by Hass; 08.08.2019 at 18:23.
Reply With Quote
  #469  
Old 08.08.2019, 18:29
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 65,940
Default

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
__________________
JD-Dev & Server-Admin
Reply With Quote
  #470  
Old 08.08.2019, 18:38
Hass Hass is offline
Junior Loader
 
Join Date: Aug 2019
Posts: 10
Default

@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.
Reply With Quote
  #471  
Old 08.08.2019, 18:49
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 65,940
Default

Quote:
Originally Posted by Hass View Post
@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.
Yes, JDownloader only uses the original files OR the ones with 1509 in name. It doesn't matter what version is in those files. It was just a fast hack to allow manual using of newer version without overwriting the original one. I will add 'checking for highest number' when I find time for it
__________________
JD-Dev & Server-Admin

Last edited by Jiaz; 08.08.2019 at 18:51.
Reply With Quote
  #472  
Old 08.08.2019, 18:50
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 65,940
Default

Quote:
Originally Posted by Hass View Post
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)
You should use JDK8 for compiling the library.
__________________
JD-Dev & Server-Admin
Reply With Quote
  #473  
Old 08.08.2019, 19:18
Hass Hass is offline
Junior Loader
 
Join Date: Aug 2019
Posts: 10
Default

Quote:
Originally Posted by Jiaz View Post
Yes, JDownloader only uses the original files OR the ones with 1509 in name. It doesn't matter what version is in those files. It was just a fast hack to allow manual using of newer version without overwriting the original one. I will add 'checking for highest number' when I find time for it
Okay, I thought I already tested this by replacing the original files with the ones I compiled, but now the version is correctly recognized (that were non-intuitive and I were just assuming):

--ID:36TS:1565280918086-8/8/19 6:15:18 PM - [org.jdownloader.extensions.extraction.multi.Multi(isAvailable)] -> Supported SevenZipJBinding|Version=16.02-2.01beta|RAR5=true|CPU_ARCH=ARM|OS_FAM=LINUX|OS=DEBIAN_BUSTER|64Bit_JVM=false|64Bit_ARCH=false

I'm testing this now and report back later - will take some time now.
Reply With Quote
  #474  
Old 08.08.2019, 19:30
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 65,940
Default

Thanks for the feedback!
__________________
JD-Dev & Server-Admin
Reply With Quote
  #475  
Old 08.08.2019, 22:24
Hass Hass is offline
Junior Loader
 
Join Date: Aug 2019
Posts: 10
Default

I'm about to quit the error-hunting, but here I found an error inside journal:

Aug 08 21:14:41 WDMyCloud kernel: CPU: 0 PID: 28250 Comm: java Not tainted 4.15.0-rc6 #2

I need to add info about my setup: I'm not only running JD on my NAS and this NAS is kinda homebrewed, normally I wouldn't have such access to it. I'm also running nzbget, sane, samba, cups, mysql, nginx and so on. From what I can see, it seems another process was reponsible and killed JD.

In between I fixed some other problems like low space for root partition. This problem could be a config problem on my end, but on the other hand, I know a similiar problem like JD works without crashes for me, but makes use of packages like unrar and such.

P.S.: There's also another error I'm trying to fix now:
mvpp2 f10f0000.ethernet eth0: failed to refill BM pools

A longer log can be found here:
**External links are only visible to Support Staff****External links are only visible to Support Staff**

Edith: Depending the second error, I need to update my kernel now.

Last edited by Hass; 08.08.2019 at 22:38.
Reply With Quote
  #476  
Old 09.08.2019, 19:06
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 65,940
Default

Thanks for sharing your findings. Yes, the kernel looks doesn't look good. Did you compile Kernel by yourself because as far as I remember, the default MyCloud kernel used incompatible pagesize to most software and would require a custom compiled java. Of course my memory may play fool to me and I remembered it for different NAS device.
__________________
JD-Dev & Server-Admin
Reply With Quote
  #477  
Old 09.08.2019, 20:40
StanislavGrof StanislavGrof is offline
I will play nice!
 
Join Date: Aug 2019
Posts: 3
Thumbs up Works on Raspberry Pi 4

Quote:
Originally Posted by Hass View Post
[...]
And because of restrictions:
Armv7 32bit 15.09: mega url + #!deAUkYjY!9kirUFJRNt7kLpxybQLYdpeXydF82Q4-_KlMK1LnCYI
[...]
Thank you! I have tested version 15.09 with several RAR5 archives on my Raspberry Pi 4 and it works flawless.
Reply With Quote
  #478  
Old 11.08.2019, 03:06
Hass Hass is offline
Junior Loader
 
Join Date: Aug 2019
Posts: 10
Default

@StanislavGrof: Np, I'm glad it could help more ppl. I'm a lil bit surprised it even works on Armv8 as Raspi 4 should be one.

@Jiaz: The kernel was compiled by user fox_exe who invested a ton of work to mod WDCloud NAS drives. (DSM on WD lol) The kernel I got from here: **External links are only visible to Support Staff****External links are only visible to Support Staff** and it worked flawlessly so far. For some reason self-compiled kernels aren't working and it is difficult to figure out whats the problem and for sure I bricked the drive. Without UART knowledge and equipment this board isn't recoverable for me, but the drive survived the procedure.

I got another storage and set up everything from scratch again and test it within the next days. Kernel is the same and if this problem occurs on this NAS again, I'm leaving it as it is. (got 1G instead of 512M RAM) The other custom kernels I could get got even more problems than the most up-to-date one I had and have.

P.S.: @StanislavGrof version 16.02 should also work for you btw. You just need to rename the files from xxx1602xxx to xxx1509xxx.

Last edited by Hass; 11.08.2019 at 03:08.
Reply With Quote
  #479  
Old 12.08.2019, 17:28
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 65,940
Default

Quote:
Originally Posted by Hass View Post
@StanislavGrof: Np, I'm glad it could help more ppl. I'm a lil bit surprised it even works on Armv8 as Raspi 4 should be one.
Armv8 is Armv7 backwards compatible. (as long as same/compatiple floating unit mode)
__________________
JD-Dev & Server-Admin
Reply With Quote
  #480  
Old 12.08.2019, 17:36
Jiaz's Avatar
Jiaz Jiaz is offline
JD Manager
 
Join Date: Mar 2009
Location: Germany
Posts: 65,940
Default

@Hass: Thanks for the feedback. So I was right about it being *pain* to compile kernel for this NAS and get it working properly. I just remember that it uses/used a non normal pagesize that caused normal compiled software to fail and required special/self compiled versions.
__________________
JD-Dev & Server-Admin
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

All times are GMT +2. The time now is 05:51.
Provided By AppWork GmbH | Privacy | Imprint
Parts of the Design are used from Kirsch designed by Andrew & Austin
Powered by vBulletin® Version 3.8.10 Beta 1
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.