Danke für den Tipp. Über SSH wurde das Sonderzeichen nur mit einem ? dargestellt. der Rest war richtig..
War wohl ein Fehler im FreeNas System. Nach einem Update des FreeNas' scheint alle so zu laufen wie es soll..
Ich hatte diesen Text zurück genommen weil beim Testen hab ich JDownloader als Root gestartet. Damit gings wieder nicht. Aber als JDuser scheint es jetz doch richtig zu funktionieren. Ich werd es weiter beobachten..

Viele Dank nochmal.

[Jiaz]

Danke fürs Feedback! Bitte dran denken die Eigentümer zu korrigieren sobald man den JDownloader mal als root gestartet hat.
sudo chown -R user:group /pfad

Also irgendwie ist das komisch.. Wenn ich JDownloader als Service starte:

jd_start()
{
        umask 000
        su JDuser -c '/JDownloader/start.sh &'
}

hab ich wieder diese komischen Namen.. Wenn ich aus der Shell

su JDuser /JDownloader/start.sh

starte klappt es mit den richtigen Namen.
Wenn ich im Startscrtipt das "-c" weglass, startets garnicht.

Müssen wohl doch mal wieder ne Teamviewer Session machen :-)

Grüßle,
Baschtlwaschtl.

[Jiaz]

die umask änderung bringt nichts, da du mit su -c eine neue Shell startest und die umask ja für die aktuelle shell umgebung geändert wurde
den umask befehl muss in start.sh rein
Welche Shell hat JDUser denn? Evtl werden falsche Locales gesetzt?
#!/bin/bash
umask 000
export LC_ALL=de_DE.UTF-8
export LANG=de_DE.UTF-8
export LANGUAGE=de_DE.UTF-8
java -jar JDownloader.jar.....

Das umask is im Startscript nochmal drin. Hattest du mal eingefügt.

 cat /JD*/start.sh
#!/bin/sh
umask 000
/usr/local/bin/java -Dsun.jnu.encoding=UTF-8 -Djava.awt.headless=true -jar /JDownloader/JDownloader.jar &

und locale is auf en-US bei root und bei JDuser.
Beim manuellen Start über Shell gehts ja...

root@Jdownloader:/ # locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL=

su JDuser
% locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_ALL=

Welche Shell? also bei etc/passwd steht bei JDuser hinten /bin/csh
bei root steht das gleiche.

[Jiaz]

Schreib mal die export noch mit rein. de_DE kannst durch en_US ersetzen
LC_ALL ist nicht gesetzt

hab das eingefügt..
mit locale zeigt er mir immernoch en-US an.. aber jetz hat es funktioniert.. Ich probier mal nen Jail Neustart..
edit:
Nach Jailneustart gehts immernoch!!
super, danke dir..
locale zeigt immernoch en-US.
aber ok.. Ich meld mich wieder :-)
Vielen Dank

[Jiaz]

Danke fürs Feedback! freut mich das ich helfen konnte

Ich ziehe gerade vom Raspberry Pi 2 auf ein neues Board um. Aber der frisch gedownloadete und mit Oracle JAVA 8 gestartete JDownloader startet, ungefragt, nur im Headless Mode! Auf dem Raspberry sehe ich hingegen die grafische Oberfläche. Was könnte der Fehler sein?

Beide starten mit

java -jar JDownloader.jar

Ich habe probehalber auch mal das gesamte alte JDownloader-Verzeichnis rüberkopiert und gestartet. Es startet ebenfalls nur headless. Ich meine auch ganz kurz am Anfang die Meldung "headless detected" (oder ähnlich) vorbeifliegen gesehen zu haben.
Wie kann ich die grafische Ausgabe erzwingen?

Auf beiden Boards läuft der Xorg Desktop in einer virtuellen VNC-Session auf Arch Linux ARM, falls das wichtig ist.

---
English translation:
My new JDownloader only starts in headless mode. How to force graphical mode? It's running over VNC. It worked for a long time on the Raspberry Pi 2, but not on the new board. Same OS (Arch Linux ARM) and same VNC server, using a virtual VNC session. I think I saw the message "headless detected" at the start of JDownloader. How to override this?

[Jiaz]

Die grafische Ausgabe benötigt eine X11 Desktop und diese Variable ist sehr wahrscheinlich nicht gesetzt.
Ist in der VNC Session denn eine DISPLAY variable gesetzt?
echo $DISPLAY

Das hier wird ausgegeben (in der VNC Session):

$ echo $DISPLAY
:1.0

[Jiaz]

Ich kann mir das gerne via Teamviewer mal anschauen, dann via VNC weiter.
Email an support@jdownloader.org

Bekomme den Teamviewer leider nicht zum Laufen. "Unsupported Architecture", sagt die armv7 32bit Version. Das Board ist armv8 64bit (ODROID-C2).

[Jiaz]

Meinte auch eher Teamviewer auf deinem Windows/Linux Rechner und von dort aus via VNC oder wie auch immer weiter. Der Odroid wird ja nicht dein einziger Rechner sein

Ach so, habe ich falsch verstanden.

Es hat sich was getan:
Mit dem OpenJDK 9 von Arch Linux funktioniert der JDownloader jetzt. Der Fehler muss wohl in einer Weise an Oracles für ARM 64 angebotenem Download liegen. Ich habe beim Testen mit der Option -Djava.awt.headless=false bemerkt, dass im 32-Bit-Download (den der Raspberry nutzen kann) eine Datei vorhanden ist, die dem 64-Bit-Download fehlt, und über deren Fehlen JDownloader in seinem Konsolenoutput meckert:

32-Bit: jre/lib/arm/libawt_xawt.so vorhanden
64-Bit: jre/lib/aarch64/libawt_xawt.so fehlt

Könnte es sein, dass der JDownloader mit der 64-Bit-Variante noch nicht ganz kompatibel ist?

Hier mal Links zum Download:
Die ARM Binaries gibt es momentan wohl nur für Java 8.
http://www.oracle.com/technetwork/ja...s-2133151.html
Linux ARM 32 Hard Float ABI 77.94 MB jdk-8u152-linux-arm32-vfp-hflt.tar.gz
Linux ARM 64 Hard Float ABI 74.88 MB jdk-8u152-linux-arm64-vfp-hflt.tar.gz

[Jiaz]

Die 64Bit ARM Version ist headless, die libawt_xawt.so fehlt
Daher läuft JDownloader auch nur Headless mit dieser Java version.

ich habe das Problem dass bei nach einer frischen Installation auf FreeNas in einem Jail das Entpacken nicht funktioniert. Jemand einen Lösung?

kurzes Update:
das Kompilieren von 7zip-jbinding auf FreeNas 11 klappt irgendwie nicht mehr.
Hab dann ein bisschen rumgespielt und compat9 installiert (pkg search compat - dann das richtige kopieren und pkg install compat9XXXXXXXX)

so klappt dann das entpacken auch problemlos

[Jiaz]

@Frosch1482: Danke fürs Feedback. Wahrscheinlich hat nur eine Abhängigkeit der Entpacker-Library gefehlt , welche durch die Installation von compact9 gelöst wurde.

EDIT: Okay, hat sich erledigt. War der Anleitung auf der 1. Seite gefolgt und hatte demnach das JD2 Verzeichnis einer Installation auf einem anderen OS einfach rüberkopiert auf meine NAS. Dass man das nicht machen soll, steht leider erst viel weiter hinten im Thread. Sollte im 1. Thread drauf hingewiesen werden.
Nach Neuinstallation auf der MyBookLive über java -jar JDownloader.jar -norestart funktioniert nun auch der Archive Extractor.


Hallo Helfer,

hatte gerade schon ein Ticket hierzu eröffnet: Ticket ID #NAT-432-84525
Auf meiner MyBookLive NAS ist das Entpacken nicht möglich.

Gibt es schon die sevenzipjbind Lib für PowerPCs?

MyBookLive:~# uname -a
Linux MyBookLive 2.6.32.11-svn70860 #1 Thu May 17 13:32:51 PDT 2012 ppc GNU/Linux

MyBookLive:~# cat /proc/cpuinfo
processor : 0
cpu : APM82181
clock : 800.000008MHz
revision : 28.131 (pvr 12c4 1c83)
bogomips : 1600.00
timebase : 800000008
platform : PowerPC 44x Platform
model : amcc,apollo3g
Memory : 256 MB