@Solo0815: Mir scheint es als wenn die Sterne beim speichern eingefügt werden, da schon ein anderer User dieses Problem beklagte...
Fritz!Load - (Oneclickhoster-) Down- und Uploads via FB
- Ersteller koepie
- Erstellt am
lol die sterne hat Fritz!Load wohl nur beim kopieren eingefügt, vorhin also beim Anzeigen warn die Nicht da :/
Jedenfalls hab ich die aktuelle Rev version ^^
Jedenfalls hab ich die aktuelle Rev version ^^
Ich hab folgenden Fall, welchen Grund hat Fritz!Load Dateien bei "fehlgeschlagenen" Downloads unter Fehler zu schieben obwohl die eigentlich laufen sollten und nur wegen Verzögerungen oder langen warte pausen auf Fehler laufen.
Dann hab ich gerade festgestellt, z.b. bei Rapidshare stand Wartezeit 18.000, wenn ich den Prozess gekillt hab und nochmal gestartet hab waren es aufeinmal nur noch 70 sek. Wie kommt das zustande das die Wartezeit auf 18.000 läuft?
Gibt es irgend welche "Must-Have" Einstellungen die man einstellen sollte um ggf. diese Probleme zu verhindern?
Dann hab ich gerade festgestellt, z.b. bei Rapidshare stand Wartezeit 18.000, wenn ich den Prozess gekillt hab und nochmal gestartet hab waren es aufeinmal nur noch 70 sek. Wie kommt das zustande das die Wartezeit auf 18.000 läuft?
Gibt es irgend welche "Must-Have" Einstellungen die man einstellen sollte um ggf. diese Probleme zu verhindern?
@drdiablo:
hab den gleichen Fehler ... auf der RS Seite kommt Popup mit:
hab den gleichen Fehler ... auf der RS Seite kommt Popup mit:
ein Reconnect hilft nicht :noidea:
also bei mir klappt es plötzlich doch direkt auf die HDD zu speichern, keine ahnung wie, aber ich kann euch ja meine genauen schritte schildern bis es dann plötzlixh geklappt hat.
erstens hab ich bei FL bei download verzeichniss selber den link rein geschrieben statt wie ihn bisher aus der liste bei den unmount einstellungen zu kopieren.
zudem habe ich bei den FB einstellungen unter nas einstellungen "nur sichere ftp verbindungen zulassen" das häckchen weg gemacht, und seitdem klappt es auch. wem es hilft und das gleiche problem hat kann es ja mal ausprobieren.
und danke nochmal an alle hier im forum.
Edit:
Download klappt wunderbar direkt auf die HDD mit trunk version 1385, aber unrar im selbigen verzeichniss wurde komischerweise nicht ausgelöst.
Ich hab auch genau das selbe verzeichnis angegeben, es hat sich nichts getan nd er gibt mir diesen fehler:
ERROR: extract-dir does not exists
obwohl es das selbe verzeichnis ist mit nem anderen unterordner.
was kann man da machen oder hat einer von euch nen tip für mich?
erstens hab ich bei FL bei download verzeichniss selber den link rein geschrieben statt wie ihn bisher aus der liste bei den unmount einstellungen zu kopieren.
zudem habe ich bei den FB einstellungen unter nas einstellungen "nur sichere ftp verbindungen zulassen" das häckchen weg gemacht, und seitdem klappt es auch. wem es hilft und das gleiche problem hat kann es ja mal ausprobieren.
und danke nochmal an alle hier im forum.
Edit:
Download klappt wunderbar direkt auf die HDD mit trunk version 1385, aber unrar im selbigen verzeichniss wurde komischerweise nicht ausgelöst.
Ich hab auch genau das selbe verzeichnis angegeben, es hat sich nichts getan nd er gibt mir diesen fehler:
ERROR: extract-dir does not exists
obwohl es das selbe verzeichnis ist mit nem anderen unterordner.
was kann man da machen oder hat einer von euch nen tip für mich?
Zuletzt bearbeitet:
Hier habe ich otrtool von http://github.com/pyropeter/otrtool statisch kompiliert.
Falls Interesse besteht könnte man es ja in F!L integrieren.
Falls Interesse besteht könnte man es ja in F!L integrieren.
Code:
# time ./otrtool -x -e <email> -p <password> <otrkey-file (132 MB)>
OTR-Tool, v0.9-0-gf977991
Trying to contact server...
Server responded.
Keyphrase: <keyphrase>
Decrypting...
[========================================] 100%
real 2m 15.46s
user 0m 59.68s
sys 0m 23.82s
zupipo
Neuer User
- Mitglied seit
- 6 Apr 2007
- Beiträge
- 143
- Punkte für Reaktionen
- 0
- Punkte
- 16
Feedback 1385: MU scheint wieder zu funktionieren, prima! Dafür ist bei RS-Free immer noch eine Seite dazwischen, so dass Content-Type mismatched: received (text/html; charset=UTF-8) ausgelöst wird. Kein Download möglich.
Gruß
zupipo
Gruß
zupipo
@all: Es ist mal wieder ein RS update fällig, da sie nun irgendwie 3 Arten von links haben... (svn1386)
Es wird jetzt http://rapidshare.com/#!download|123|12345643|name.rar|12345 und http://rapidshare.com/files/12345643/name.rar unterstützt. Wobei letztere verschiedene Ausgabe erzeugen kann, aber das nur am Rande.
NACHTRAG: Nun auch links wie: http://rs12l345.rapidshare.com/#!download|123|12345643|name.rar|4567 (svn1387)
Es wird jetzt http://rapidshare.com/#!download|123|12345643|name.rar|12345 und http://rapidshare.com/files/12345643/name.rar unterstützt. Wobei letztere verschiedene Ausgabe erzeugen kann, aber das nur am Rande.
NACHTRAG: Nun auch links wie: http://rs12l345.rapidshare.com/#!download|123|12345643|name.rar|4567 (svn1387)
Zuletzt bearbeitet:
Danke, mein Ego ist geschmeichelt. Den reconnect hat jedoch Solo0815 überarbeitet also auch ihm und den restlichen fleissigen ein: :groesste: 
Deshalb auch gleich nochmal die Frage ans Testpublikum. Gibt es noch Probleme beim reconnect oder nicht (ab svn1385)? Ich für meine Begriffe habe nichts feststellen können, bei mir geht alles wie geschmiert... Wenn das geklärt ist kommt auch der neue release v0.37.
Deshalb auch gleich nochmal die Frage ans Testpublikum. Gibt es noch Probleme beim reconnect oder nicht (ab svn1385)? Ich für meine Begriffe habe nichts feststellen können, bei mir geht alles wie geschmiert... Wenn das geklärt ist kommt auch der neue release v0.37.
@wetzstein513 - Von mir gibt es auch nur positives. Reconnect funktioniert immer.
Ihr seit wirklich die Größten :groesste:
Ihr seit wirklich die Größten :groesste:
Der Reconnect läuft jetzt prima.. besten Dank!
Edit 2: Auf den OTR-Servern werden die Aufnahmen seit einiger zeit als AVI angeboten.
Deshalb scheint das otrtool, zum Entschlüsseln der Key-Files, nicht mehr notwendig zu sein.
Gruß
Silverline
Edit 2: Auf den OTR-Servern werden die Aufnahmen seit einiger zeit als AVI angeboten.
Deshalb scheint das otrtool, zum Entschlüsseln der Key-Files, nicht mehr notwendig zu sein.
Gruß
Silverline
Zuletzt bearbeitet:
neues Fritz!Load Release
Hallo zusammen,
Fritz!Load Release 0.37 wurde freigeben. Vielen Dank an alle Helfer.
Die neue Version gibt es wie üblich auf der Projektseite http://sourceforge.net/projects/avmload/ oder indem man bei Online Update den Wert "1388" bei "Update auf SVN-Trunk-Revision" einträgt.
Unter http://sourceforge.net/apps/trac/avmload/wiki/FritzLoadVersionen gibt es eine Übersicht der Änderungen zur letzten Version.
Viel Spaß
Hallo zusammen,
Fritz!Load Release 0.37 wurde freigeben. Vielen Dank an alle Helfer.
Die neue Version gibt es wie üblich auf der Projektseite http://sourceforge.net/projects/avmload/ oder indem man bei Online Update den Wert "1388" bei "Update auf SVN-Trunk-Revision" einträgt.
Unter http://sourceforge.net/apps/trac/avmload/wiki/FritzLoadVersionen gibt es eine Übersicht der Änderungen zur letzten Version.
Viel Spaß
@silverline
Schön, dass der OTR-Download bei dir funktioniert. Nur eine kleine Anmerkung: Resume geht zur Zeit nicht. Ich könnte es einfach einbauen, würde aber dadurch das Warteschlangenpositionsfeedback verlieren.
Schön, dass der OTR-Download bei dir funktioniert. Nur eine kleine Anmerkung: Resume geht zur Zeit nicht. Ich könnte es einfach einbauen, würde aber dadurch das Warteschlangenpositionsfeedback verlieren.
@roadman: reicht es nicht curl/download einfach --resume zu übergeben. Das müßte doch unabhängig vom feedback sein?
@wetzstein
Das Problem, dass ich bei OTR hatte, als ich nur die Headder geladen hatte, war dass sich PRIO-Downloads "vorgedrängelt" haben, obwohl ich schon mit dem Download dran war. Das Ergebnis war natürlich ein fehlerhafter Download. Nun lade ich jedesmal Headder und Dateiinhalt und lösche danach den Dateiinhalt, falls es sich um eine HTML-Seite handelt. Für Resume müsste ich wahrscheinlich vor dem Download die Dateigröße von der vorhanden Datei überprüfen, bevor ich sie lösche. Falls die Datei zu klein ist, könnte sie durch die Fehler-HTML-Seite ergänzt und damit fehlerhaft werden. Dies habe ich jedoch noch nicht ausprobiert.
Das Problem, dass ich bei OTR hatte, als ich nur die Headder geladen hatte, war dass sich PRIO-Downloads "vorgedrängelt" haben, obwohl ich schon mit dem Download dran war. Das Ergebnis war natürlich ein fehlerhafter Download. Nun lade ich jedesmal Headder und Dateiinhalt und lösche danach den Dateiinhalt, falls es sich um eine HTML-Seite handelt. Für Resume müsste ich wahrscheinlich vor dem Download die Dateigröße von der vorhanden Datei überprüfen, bevor ich sie lösche. Falls die Datei zu klein ist, könnte sie durch die Fehler-HTML-Seite ergänzt und damit fehlerhaft werden. Dies habe ich jedoch noch nicht ausprobiert.
@roadman: Danke für die Erklärung. Mir ist gerade noch aufgefallen zu "convert OTR-Download-Link (NORM, PRIO, PAID) without clicking on it from webpage". Das ist egal ob man es anklickt oder nicht, da der Download jedem Benutzer zugeordent werden kann. Der Link enthält verschlüsselt die AnmeldeInfos. Aber das nur zur Info...
Neueste Beiträge
-
[Sammlung] AVM-Gateway-kompatible Zigbee-Geräte
- Letzte: rabbe
-
Be.IP hinter Fritzbox Fiber
- Letzte: Robert Mayr
-
Asterisk und bookworm
- Letzte: Manfred3
-
[Problem] 5690 wlan modul- Letzte: NDiIPP
-
[Problem] Fritz!App Fon Gespräch abweisen
- Letzte: Dudadudadey
