Fritz!Load - (Oneclickhoster-) Down- und Uploads via FB

[n.primera]

/bin/led-ctrl gibt es ja auch erst ab xx.04.67. Frühere Firmwares müssen die "Alte" Led-Steuerung verwenden...

diese Meldung kommt bei mir bei der "Alten" Ledsteuerung. Da ich die xx.04.59 nutze hab ich diese auch eingestellt. Die anderen Fehler lagen bei mir, der Download wird nun gestartet aber die Meldung bleibt die gleiche.

./fritzload.sh: line 953: /bin/led-ctrl: not found
./fritzload.sh: line 953: /bin/led-ctrl: not found
++++++
oneclickhoster: http://rapidshare.com/files/xxxxxxxxx.part08.rar
== 15:37:54 Uhr == rapidshare
ash: 53
53: bad number
Warte 53

mfg

 

[TomTomNavigator]

Komischerweise habe ich dieses Problem auch ab und zu. Aber erst seitdem die neue Firmware drauf ist...
Und beenden lässt sich der Prozess auch nicht, weder mit killall sh noch mit kill und PID.
Strange.

 

[SagHalt]

@TelefonSparbuch: Wegen dem unstrukturierten Coding hat jemand schon auf sourceforge versucht das Coding etwas mehr zu strukturieren. Siehe http://avmload.cvs.sourceforge.net/viewvc/*checkout*/avmload/avmload/fritzload.sh?revision=1.32

@TomTom: Den SH-Prozess mit der hohen CPU Last habe ich auch bemerkt. Killen kann man diesen mit der Anweisung "kill -kill PID" (PID ist die Prozess Id; Befehl ps).

Vermutlich bleibt die letzte Telnet Verbindung offen und zieht zeimlich viel Last. Sehr dubios.

 

[TelefonSparbuch]

Vermutlich bleibt die letzte Telnet Verbindung offen und zieht zeimlich viel Last. Sehr dubios.

Eventuell genügt es, noch den Eingabestream "</dev/null " anzugeben.

./fritzload.sh -u list_ul.txt > log/nohup_ul.out 2>&1 </dev/null &

 

[TelefonSparbuch]

So noch mal eine Aktualisierung. Jetzt sollte auch der Upload (Freeuser) funktionieren. Allerdings denke ich, dass das noch optimiert werden kann, da dort immer die Accountdaten verwendet werden, die bei Freeuser-Upload nicht unbedingt erforderlich sind.

 

[hei_q]

Komischerweise habe ich dieses Problem auch ab und zu. Aber erst seitdem die neue Firmware drauf ist...

Wie ich bereits sagte, das Problem tritt erst seit FW 54.04.67 auf, davor gabs nie Probleme.

Und beenden lässt sich der Prozess auch nicht, weder mit killall sh noch mit kill und PID.
Strange.

@TomTom: Den SH-Prozess mit der hohen CPU Last habe ich auch bemerkt. Killen kann man diesen mit der Anweisung "kill -kill PID" (PID ist die Prozess Id; Befehl ps).

Funktioniert bei mir wunderbar! Ich habe mir diesen Befehl einfach in eine Stapelverarbeitungsdatei geschrieben die dann bei Bedarf mit Doppelklick die erwünschte Wirkung bringt.
Gut, man muss daran denken, aber das ist doch mal ne Hilfe!

Vielen Dank dafür!! :groesste:

Edit: leider ändert sich die PID jedesmal, ist also doch nicht ganz so bequem wie ich dachte. Aber trotzdem wissen wir nun mal was das Problem ist.

 

[Jabba-deHut]

@musti19:
hast du denn auch grafiken bei fritzload?
gibts einschrenkungen zu aktuellen versionen?

 

[carstenwell]

Hallo,

mit der letzten Version habe ich keine RS Downloads, sondern nur dauernde
reconnects. Die DL werden aber aus list_dl.txt gelöscht, allerdings nicht in fertige DL weiterverschoben, runtergeladen wird aber garnichts.

Ich bleib jetzt erstmal bei meiner Altversion.

Viele Grüße
Carsten

 

[TelefonSparbuch]

Bei Fehlermeldungen wäre es hilfreich, wenn auch die Meldungen geliefert werden (meinetwegen auch per PN). So weiß ich nicht an welcher Stelle es etwas zu korrigieren gibt. Bei mir laufen die Downloads für die erstellten Testdateien...

Grüße
Harald

 

[TelefonSparbuch]

Den Fehler mit der verschwindenen Downloadliste ist nun auch behoben.

EDIT: ZIP Archiv aktualisiert / Aktueller Stand ist nun auch im CVS
Etliche Opimierungen bei den Hostern...

Grüße
Harald

 

[zupipo]

EDIT: ZIP Archiv aktualisiert / Aktueller Stand ist nun auch im CVS

Zwei Fragen zu dieser Version:

1. Läuft die auch mit lighttpd oder nur mit apache?
2. Fehlt da nicht was? Z.B. Im Fritzload-Hauptverzeichnis schon mal die index.html oder index.php?

Gruß
zupipo

 

[TelefonSparbuch]

1. Läuft die auch mit lighttpd oder nur mit apache?

Im Prinzip sollte es egal sein. Es bedingt allerdings weiterhin PHP. Getestet habe ich es allerdings nur mit lighttpd.

2. Fehlt da nicht was? Z.B. Im Fritzload-Hauptverzeichnis schon mal die index.html oder index.php?

Da das gesamte Paket ca. 1.6 Mbyte sind habe ich nur die relevanten (geänderten) Dateien angeboten (60 Kbyte). Im Prinzip einfach das Archiv über die bestehenden Dateien entpacken...

Grüße
Harald

 

[zupipo]

Danke! Ich probiere es mal aus.

Hier schon das erste feedback: Der Download von Rapidshare läuft gerade, beginnt aber mit:

ash: 2: unknown operand
++++++

läuft trotzdem bislang fehlerfrei.

Gruß
zupipo

 

[TelefonSparbuch]

Neue Version. RSDF und CCF Import.

ash: 2: unknown operand

Vermutlich fehlt noch die Variable für die LED Steuerung. Ansonsten aktiviere in der fritzload.sh die DEBUG Option (ganz oben in der Datei...).

EDIT: Update (17:20 Uhr)
- Neuer Hoster sharebase.to
- Fehler bei unbekanntem Hoster behoben
- Kommentarzeilen in der Downloadliste sind möglich (Zeilen die mit dem Rautezeichen "#" beginnen)

Grüße
Harald

 

[newbiecrd]

einige Fragen

Hallo,

erst mal toll was Ihr hier programmiert! Ich habe noch ein paar Fragen zu diesem Projekt.

Zuerst meine Hardware:
Fritz.Box: Firmware-Version 54.04.67 "ohne freetz"
WD My Book Festplatte 500 GB, Fat 32
Windows Vista Rechner (Linux Live-CD verfügbar)

1.) Liegt es an der zu neuen FW das ich die Gui nicht zum laufen bekomme? PHP-Info wird angezeigt, wenn ich PHP und lighttpd installiert habe. Den Unterordner kann ich nicht aufrufen, ein Verschieben der Dateien in das www Verzeichnis bringt auch keine besserung.

2.) ist es ratsam die Festplatte auf EXT2 umzuformatieren? Welche Vorteile gibt es noch, außer die Geschwindigkeit? Klar die Benutzerrechtevergabe und die möglichkeit symbolischer Links unter Linux, dafür muß ich diese aber von hand mounten.

3.) Reichen die Aussagen bis jetzt um festzustellen wieso die RSDF bei mir nicht klappen

Newbiecrd

 

[kadolf]

Auch bei mir ging es (bei ähnlicher Konfiguration) zuerst nicht.
Hab dann mal hier im Thread gelesen, scheinbar (wenn ich es richtig verstanden habe) ist das ganze ein Problem zwischen lighttpd und der Firmware 54.04.67 für die 7270... Habe statt lighttpd dann apache genutzt (siehe Seite 53, ab #1051) - funktioniert sehr gut...

Das einzige was noch nicht klappt ist der RSDF-Upload - scheint ein Problem bei Konfiguration vom Apache zu sein, wahrscheinlich müsste ich den temporären Upload-Pfad in der php.ini noch anpassen, der ist im moment nicht gesetzt und sollte eigentlich automatisch vergeben werden, dass wird aber scheinbar nicht richtig unterstützt...
EDIT: Hat sich soeben gelöst - hab mir einfach mal die zuständige PHP angeschaut und gesehen, dass FritzLoad die hochgeladene RSDF in /var/tmp/ erwartet, php.ini angepasst & Apache neu gestartet und funktioniert

 

[AtomicStryker]

1A! :groesste:



Support für das DLC-Containerformat wäre genial, wobei ich nicht weiss, ob das technisch machbar ist.

Eine andere Sache: Dass man die FB nach Abziehen eines USB-Sticks immer neu starten muss, damit das 01-Phantom weggeht (und Fritzload wieder geht), ist bei uns etwas problematisch. Die dranhängende ISDN-Anlage kommt damit nicht klar und hängt sich immer auf.
Kann man nicht irgendwie unmount-Befehle nutzen?

 

[wetzstein513]

@AtomicStryker: DLC Support ist leider nicht möglich, da dieses Containerformat noch nicht geknackt wurde.

Mit dem 01-Problem das wär ne feine Sache. Täte mich auch mal interessieren...

 

[SagHalt]

EDIT: Update (17:20 Uhr)
- Kommentarzeilen in der Downloadliste sind möglich (Zeilen die mit dem Rautezeichen "#" beginnen)

Hallo Harald,

Vielen Dank für die neue Version und den Einbau des Kommentarzeilenparsing. Solch ein Feature wollte ich auch demnächst einbauen.
Idee: Wie wäre es die Kommentarzeile auch in die finished_dl.txt zu schreiben?

Das überarbeitet Coding hat nun eine deutliche Qualitätssteigerung und ist strukturierter + leichter zu lesen

Was mir noch aufgefallen ist: Wird nun bei rapidshare und uploaded.to nach dem Downlaod immer ein Reconnect durchgeführt? Wäre es nicht besser, nur wenn die Wartezeit zu hoch ist ein reconnect durchzuführen? Von meinem Empfinden her sollten die Reconnects nur in wirklich benötigten Fällen durchgeführt werden.

Viele Grüße

 

[TelefonSparbuch]

Es gibt Möglichkeiten, an die Links vom dlc Container zu gelangen (Jdownloader liegt ja im Quellcode vor, man könnte da sicherlich das Link-Handling auch in eine Datei umleiten...) - und den JDownloader als Linksammler/Decrypter weiter nutzen... Wer sich mit Java auskennt könnte das ja mal angehen

Es gibt noch einen Bug mit den Kommentarzeilen, so dass das Programm in einer Endlosschleife hängen bleibt und die Logdateien mit Leerzeilen überflutet...

Anbei die korrigierte Fassung.

Grüße
Harald