+-Serie DS412+ / Unrar-Performance-Probleme

[Jaroslaw]

Hallo zusammen,

nun bin ich stolzer Besitzer einer DS412+.
Alles schön und gut, jedoch kaum in Betrieb genommen, schon das erste Problem.

Ich nutze solch' ein böses 3rd Party App, genannt "SabNZBd".
Nun stelle ich gerade fest, dass nach einem geglückten Download (ca. 20GB mehrteiliges RAR-Archiv) der Entpacken-Vorgang bereits etwa 20 Minuten dauert und Unrar ist gerade mal beim 16 File von 76 Files angekommen.
Kann mir jemand erklären, was da schief läuft? Der Intel Atom 2700 hat deutlich mehr Power und wäre, in einem anderen Setup, schon längst fertig.

Bin ich etwa der Einzige, der solch' ein Problem hat? Google spuckt nämlich gar nichts zu diesem Problem aus.
Toll wär's, wenn jmd. 'n Ansatz hätte.

Liebe Grüße,
Jaroslaw

 

[trininja]

Du bedenkst aber schon, das bei Usenet noch die decodierung der Binärdateien hinzukommt und nicht direkt die RARs in Angriff genommen werden, ausser das App übernimmt das schon direkt nach dem Download, wobei ich das bezweifel.

 

[Jaroslaw]

Du bedenkst aber schon, das bei Usenet noch die decodierung der Binärdateien hinzukommt und nicht direkt die RARs in Angriff genommen werden, ausser das App übernimmt das schon direkt nach dem Download, wobei ich das bezweifel.

Dekodierung? Das Einzige, was zu Dekodieren ist, ist die SSL-Verbindung. Und das passiert während des Downloads "on-the-fly". Es ist tatsächlich der Unrar-Prozess, der sich ziemlich Zeit lässt. Und nur zur Info: Bevor ich mir die DS412+ gekauft hatte, habe ich einen Thecus N5550 hier stehen gehabt. CPU dort ist 'n Intel Atom D2550. SabNZBd war dort ebenfalls im Einsatz und dort hat der komplette Verify/Unpack-Vorgang keine 5 Minuten gedauert.
Also, irgendwas ist da faul!

 

[trininja]

Du weisst schon das Binärdaten im Usenet generell codiert sind mit yEnc, Base64 oder UUencode um überhaupt erst hochgeladen werden zu können? Das hat nichts mit SSL zu tun. Zumindest war es so vor 25 Jahren im Usenet, das letztemal als ich noch aktiv im Usenet in binaries Gruppen unterwegs war vor 5 Jahren auch noch, wüsste nicht das sich hier was verändert hat an den RFCs zum Thema Usenet, die ja sogar älter sein dürften als ich es bin.

Ich halt mich da nunmal raus, da ich aktuell nicht im Usenet unterwegs bin und kein SabNZBd laufen hab, sondern nur pyLoad.

 

[Jaroslaw]

Du weisst schon das Binärdaten im Usenet generell codiert sind mit yEnc, Base64 oder UUencode um überhaupt erst hochgeladen werden zu können? Das hat nichts mit SSL zu tun. Zumindest war es so vor 25 Jahren im Usenet, das letztemal als ich noch aktiv im Usenet in binaries Gruppen unterwegs war vor 5 Jahren auch noch, wüsste nicht das sich hier was verändert hat an den RFCs zum Thema Usenet, die ja sogar älter sein dürften als ich es bin.

Ich halt mich da nunmal raus, da ich aktuell nicht im Usenet unterwegs bin und kein SabNZBd laufen hab, sondern nur pyLoad.

Du hast durchaus Recht. Daran hat sich selbstverständlich nichts geändert. Jedoch beginnt der Unrar-Prozess erst dann, wenn die Archivdateien in ihrem Rohformat auch tatsächlich vorliegen. Das Dekodieren von yEnc passiert schon deutlich eher.

 

[trininja]

K, das wollte ich damit nur zum Ausdruck bringen, weis ja nicht wie SabNZBd das handhabt, hatte früher nen Client auf dem Rechner, der hat den Decode erst gemacht als es ans entpacken ging. Hab da so in die Richtung gedacht. Hab gerade mal aus Spaß in pyLoad nen Download gemacht mit ner 70GB Splitarchivgeschichte mit .rev Dateien, ausser das mir Phyton mit 800MB zwischendurch rennt beim entpacken, geht es recht flott, er hat die Datei in ca. 10 Minuten geprüft und entpackt gehabt.

Hast ja demnach schon IPKG drauf, lad dir darüber mal die aktuelle unrar ins System, evtl. hilfts, ich hab die zusammen mit pyLoad manuell nachinstalliert.

 

[Jaroslaw]

Hm, sonst niemand eine Idee?

 

[Hubfront]

Hallo, es gibt eine Lösung für das unrar performance Problem zumindest für Synology mit atom. Kurz gesagt: einfach das linux-binary von der rarlab webseite nehmen (Kommandozeile). Die Performancesteigerung zum unrar von sabnzbd bzw. Nzbget lag bei mir bei über 350 Prozent. Details hier: https://github.com/SynoCommunity/spksrc/issues/847