Druckbare Version
Hallo,
bin gerade am testen des OTRPiDecoders, bei Dekodieren kommt die Meldung:
Aufruf:
~/otrdecoder/otrpidecoder -d -e mail -p *** -D . -O ***.mpg.HQ.avi ***.mpg.HQ.avi.otrkey
Die Fehlermeldung hilft mir leider nicht weiter, was kann das Problem sein?Code:OTRPiDecoder, v1.2
Verbinde zum Server...
cURL error: Failed writing body (1000 != 3880)
Versuch mal:
Falls das nicht hilft:Code:sudo apt.get install libmcrypt4 curl
Code:sudo apt-get install libmcrypt-dev libcurl4-openssl-dev
Danke Guenni.
Die Pakete sind installiert, die *dev jetzt ebenfalls.
Leider bleibt trotzdem der Fehler, auf dem Pi 1B+ läuft Raspbian (stretch).
Code:ldd ./otrpidecoder
/usr/lib/arm-linux-gnueabihf/libarmmem.so (0xb6fa7000)
libmcrypt.so.4 => /usr/lib/libmcrypt.so.4 (0xb6f56000)
libcurl.so.4 => /usr/lib/arm-linux-gnueabihf/libcurl.so.4 (0xb6eda000)
libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xb6ead000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6d6e000)
libnghttp2.so.14 => /usr/lib/arm-linux-gnueabihf/libnghttp2.so.14 (0xb6d40000)
libidn2.so.0 => /usr/lib/arm-linux-gnueabihf/libidn2.so.0 (0xb6d0e000)
librtmp.so.1 => /usr/lib/arm-linux-gnueabihf/librtmp.so.1 (0xb6ce5000)
libssh2.so.1 => /usr/lib/arm-linux-gnueabihf/libssh2.so.1 (0xb6cb0000)
libpsl.so.5 => /usr/lib/arm-linux-gnueabihf/libpsl.so.5 (0xb6c93000)
libssl.so.1.0.2 => /usr/lib/arm-linux-gnueabihf/libssl.so.1.0.2 (0xb6c34000)
libcrypto.so.1.0.2 => /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.2 (0xb6ab2000)
libgssapi_krb5.so.2 => /usr/lib/arm-linux-gnueabihf/libgssapi_krb5.so.2 (0xb6a69000)
libkrb5.so.3 => /usr/lib/arm-linux-gnueabihf/libkrb5.so.3 (0xb69b2000)
libk5crypto.so.3 => /usr/lib/arm-linux-gnueabihf/libk5crypto.so.3 (0xb6973000)
libcom_err.so.2 => /lib/arm-linux-gnueabihf/libcom_err.so.2 (0xb6960000)
liblber-2.4.so.2 => /usr/lib/arm-linux-gnueabihf/liblber-2.4.so.2 (0xb6944000)
libldap_r-2.4.so.2 => /usr/lib/arm-linux-gnueabihf/libldap_r-2.4.so.2 (0xb68ef000)
libz.so.1 => /lib/arm-linux-gnueabihf/libz.so.1 (0xb68c8000)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xb689f000)
/lib/ld-linux-armhf.so.3 (0xb6fbd000)
libunistring.so.0 => /usr/lib/arm-linux-gnueabihf/libunistring.so.0 (0xb6790000)
libgnutls.so.30 => /usr/lib/arm-linux-gnueabihf/libgnutls.so.30 (0xb6603000)
libhogweed.so.4 => /usr/lib/arm-linux-gnueabihf/libhogweed.so.4 (0xb65c6000)
libnettle.so.6 => /usr/lib/arm-linux-gnueabihf/libnettle.so.6 (0xb657f000)
libgmp.so.10 => /usr/lib/arm-linux-gnueabihf/libgmp.so.10 (0xb650c000)
libgcrypt.so.20 => /lib/arm-linux-gnueabihf/libgcrypt.so.20 (0xb643b000)
libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xb6428000)
libkrb5support.so.0 => /usr/lib/arm-linux-gnueabihf/libkrb5support.so.0 (0xb640f000)
libkeyutils.so.1 => /lib/arm-linux-gnueabihf/libkeyutils.so.1 (0xb63fc000)
libresolv.so.2 => /lib/arm-linux-gnueabihf/libresolv.so.2 (0xb63d7000)
libsasl2.so.2 => /usr/lib/arm-linux-gnueabihf/libsasl2.so.2 (0xb63b0000)
libp11-kit.so.0 => /usr/lib/arm-linux-gnueabihf/libp11-kit.so.0 (0xb6352000)
libidn.so.11 => /lib/arm-linux-gnueabihf/libidn.so.11 (0xb6311000)
libtasn1.so.6 => /usr/lib/arm-linux-gnueabihf/libtasn1.so.6 (0xb62f1000)
libgpg-error.so.0 => /lib/arm-linux-gnueabihf/libgpg-error.so.0 (0xb62d1000)
libffi.so.6 => /usr/lib/arm-linux-gnueabihf/libffi.so.6 (0xb62b9000)
Hast du noch eine Idee was das Problem sein kann?Zitat:
Zitat von Guenni
Habe es auf einem PI3 probiert mit gleicher Fehlermeldung.
Nein, leider habe ich da keine Idee mehr. Bei mir läuft der aktuelle ARMv7 Decoder sowohl auf einem RPi 3 unter Jessie als auch auf einem 3B+ unter Stretch ohne Probleme.Zitat:
Zitat von 0daredevil0
War bei Verbindungsproblem, jetzt geht es.
Bei dem Decoder gibt es keine Optionen zur Verifikation, wie man es vom 64Bit Linux Decoder kennt?
... hat zwar gemerkt, dass die Datei zu klein ist, aber trotzdem Dekodiert.Code:OTRPiDecoder, v1.2
Verbinde zum Server... OK
Decodieren...
[ ] 0% /
Datei ist zu klein.
Ich habe e nicht ausprobiert, aber vielleicht ohne die "-d" Option = überprüfen, ohne zu dekodieren?
Eine Verifikation scheint es bei dem Decoder nicht zu geben.
Allerdings beobachte ich seit einiger Zeit, dass immer mal die Meldung "Serverantwort fehlerhaft." kommt.
Wenn ich mehrere Dateien Dekodiere z.B. per Skript, dann wird zum Beispiel die 1. Datei korrekt Dekodiert, die beiden anderen danach nicht mehr ...
Eben hatte ich 2 Dateien zu Dekodieren, beides wurden mit "Serverantwort fehlerhaft." abgebrochen. Einige Minuten später läuft es durch. :confused:
Auch wenn es nervt, dies alleine wäre großes Problem, allerdings wird jedes mal mit "Serverantwort fehlerhaft." auch eine Dekodierung gezählt. Über das Jahr sammelt sich so einiges an.
Der Raspberry ist direkt per LAN mit dem Router verbunden und die Verbindung ist vollkommen unausgelastet und stabil auf meiner Seite, daran kann es nicht liegen.
Auf dem Raspberry läuft Debian stretch mit dem Decoder:
http://www.onlinetvrecorder.com/down...8.17_armv7.zip
Zur seit der Dekodierung läuft keine weitere Ressourcenressende Aufgabe, idle.
Code:$ ~/otrdecoder/otrpidecoder -h
OTRPiDecoder, v1.2
otrpidecoder [-h] [-d] [-e <Email>] [-p <Passwort>] [-D <Zielverzeichnis>] [-O <Ausgabedatei>] <otrkey-Datei>
Optionen
-h | Zeigt diese Hilfe an
-d | Decodieren
-D | Zielverzeichnis
-O | Ausgabedatei
Ich dekodiere seit Jahren alle mein OTR-Keys auf dem RPi, inzwischen mehrere Tausend. Ich kriege nur Fehlermeldungen, wenn
1) OTR gerade mal nicht erreichbar ist
oder
2) der Key defekt ist (Neuladen von einem anderen Mirror und dann geht es).
Ich verwende den gleichen Dekoder, erst unter Jessie, nun unter Stretch. 2017 nußte ich den Dekoder wechseln (neue Version).
Für mich sieht das nach einem Netzwerkproblem aus.
@ Guenni
Die Internetverbindung ist von meiner Seite nicht belastet, im Router werden keinen Verbindungsabbrüche angezeigt.
Es sieht eigentlich alles gut aus, auch keine Probleme bei anderen Verbindungen vom RPI.
Eine Idee wie ich den Grund weiter untersuchen kann?
hm, ich war mir sicher, dass es nur am otr Server liegen kann und der Decoder vielleicht mit einer schlechten Verbindung zum Server nicht zurecht kommt. Verifikation hat dieser wie gesagt auch nicht.
@0daredevil0
Welchen RPi hast du?
@Guenni
Einen Raspberry PI 3B.
Also keinen 3B+. Ich wollte das nur wissen, weil beim 3B+ Netzwerkprobleme mit manchen Routern auftreten können.Zitat:
Zitat von Guenni
Das gilt aber nicht für einen 3B.
Eigentlich ist es mir dann eine Rätsel. Bei mir funktioniert es seit Jahren einwandfrei.
@Guenni
Ja, das Modell ohne Plus.
Der Docoder gibt auf dem Terminal noch eine hex? Tabelle aus.
Der Anfang mit 0D bis 39 ist immer gleich, der Rest (entfernt mit *) unterschiedlich.Code:OTRPiDecoder, v1.2
Verbinde zum Server... OK
Serverantwort:
00000000 0D 0A 09 09 09 09 41 39 ** ** ** ** ** ** ** ** |......**********|
...
00000160 ** ** ** ** ** ** |****** |
00000166
Serverantwort fehlerhaft.
Die Hextabelle habe ich auch schon ein paar Mal bekommen. Dann war aber immer der Otrkey fehlerhaft (von einem anderen Mirror runtergeladen und dann ging es).
@Guenni
hm, kam bei dem Fall danach auch die Meldung "Serverantwort fehlerhaft." ?
Das weiß ich nicht mehr (kam ja auch nur sehr selten vor).Zitat:
Zitat von 0daredevil0
Man könnte noch versuchen die Konfigurationen zu vergleichen.
ok, Danke.
@sv00010
Welche Konfiguration meist du?
Die von den Raspberry pi wo alles funktioniert und die von deinem.Zitat:
Zitat von 0daredevil0
Das ist komplizierter als du denkst. Meine Raspberry Pis erfüllen eine Vielzahl von Aufgaben. Also ist auch eine Unmenge von Software, Bibliotheken usw. installiert. Sie laufen alle von Festplatte (auf der SD-Karte befindet sich nur der Boot-Sektor).Zitat:
Zitat von sv00010
@Guenni
Meins läuft noch von SD-Karte, habe allerdings auch schon mal daran gedacht alles auf eine HDD zu verschieben.
Läuft es bei dir von einer externen USB-Festplatte? Geht dadurch nicht noch mehr über den Flaschenhals USB Schnittstelle?
Ja, allem meine RPis laufen mit einer (oder mehreren) USB-HDDs. Sie sind wesentlich langlebiger als SD-Karten und trotz des USB-2-Flaschenhalses deutlich schneller als die allermeisten SD-Karten. Du solltest USB 3.5 Platten mit eigener Stromversorgung verwenden. Bei 2.5-Laufwerken mit Betriebssystem kann es zu Dateifehlern kommen, wenn die Stromversorgung (per RPi) zu früh abgeschaltet wird und die Platte noch Daten im internen Cache hat.Zitat:
Zitat von 0daredevil0
Ich rate z. B. dringend davon ab, mein rpiotrtool ohne Festplatte zu verwenden. Es werden so große Datenmengen geschrieben, daß man damit die Lebendauer seiner SD-Karte drastisch reduzieren würde. Man merkt dabei allerdings auch, daß das USB-2-Interface ein Flaschenhals ist: Das Schneiden von OTR-Videos dauert wesentlich länger als auf einem Desktop-PC und der Grund ist nicht die Prozessorleistung, sondern die relativ langsame (ca. 27 MB/sec) Festplattengeschwindigkeit. Beim "Smartmkvmerge"-Verfahren werden die Daten mehrfach gelesen und geschrieben und das dauert einfach. Das eigentliche Smart-Rendering (Neu-Encodierung an den Schnittstellen) benötigt hingegen nur ein paar Sekunden.
Aber nur wenn die Festplatte direkt an dem PI angeschlossen ist, bei einem Hub mit Stromversorgung sollte es ja kein Problem sein?Zitat:
Zitat von Guenni
... oder eine externe Festplatte mounten und darauf schneiden, sollte auch gehen.Zitat:
Zitat von Guenni
Ja zu beidem. Ich habe einen RPi mit einer 2.5 Festplatte, die das Betriebssystem enthält. Da hatte ich bei jedem Neustart Dateifehler, bis ich einen Hub mit eigener Stromversorgung dazwischengeschaltet habe.Zitat:
Zitat von 0daredevil0
Auch das zweite geht: Betriebssystem auf SD lassen, aber externe Festplatte zum Schneiden (auch zum Herunterladen und Dekodieren) der otrkeys benutzen. Dann vermeidet man das exzessive Schreiben auf die SD-Karte.
Wobei die HDD (mit dem OS) sicher nie zu ruhe kommen wird (spin-down). Es ist ja sicher keine NAS Festplatte bei dir dran, welche für einen Dauerbetrieb ausgelegt ist, das wird die HDD Lebenszeit verkürzen.
Jedenfalls nutze ich momentan die Konstellation SD+HUB+2.5erHDD. Da diese Fehlermeldung eher zufällig bei mir auftaucht, wüsste ich nicht wie ich das weiter Debuggen kann.
Die Konfiguration vom PI vergleichen erscheint mit auch schwierig, vielleicht irgend etwas spezielles davon?
@Guenni Danke.
Kannst du dich melden, wenn so eine Fehlermeldung bei dir wieder auftauchen sollte?
Werde ich machen.Zitat:
Zitat von 0daredevil0
Ich hatte ja versprochen, mich zu melden, wenn es bei mir wieder passiert. Heute sind 5 Dekodierungen (im Batch nacheinander) fehlgeschlagen mit der üblichen Fehlermeldung. Ein paar Minuten später sind alle (mit den gleichen otrkey-Dateien) problemlos durchgelaufen. Es lag also nicht an defekten Otrkeys. Dumm nur, daß die abgebrochenen, fehlerhaften Dekodierungen mit gezählt wurden.
Es scheint sich also doch um ein Netzwerkproblem zu handeln, vielleicht wenn der OTR-Server zu stark ausgelastet ist. In der Häufung habe ich es aber noch nie zuvor erlebt.
Dann würdest Du keine Antwort erhalten. Mal abgesehen davon, dass hier im Forum geschätzte 2000 Threads wären a la "erst nach dem x.ten Versuch wird dekodiert, aber vorher Freidekodierungen abgezogen.". Es wird keine Serverüberlastung sein.Zitat:
Zitat von Guenni
MfG
MCMUPPET
Und warum bekomme ich dann fünfmal hintereinander (5 verschiedene Dateien) eine solche Fehlermeldung:Zitat:
Zitat von MCMUPPET
OTRPiDecoder, v1.2
Verbinde zum Server... OK
Serverantwort:
00000000 0D 0A 09 09 09 09 69 31 59 56 4E 77 36 59 31 38 |......i1YVNw6Y18|
00000010 34 72 53 6E 49 56 36 4C 71 72 47 4D 48 33 67 56 |4rSnIV6LqrGMH3gV|
00000020 59 69 75 42 6A 51 46 30 46 43 37 33 4C 50 47 7A |YiuBjQF0FC73LPGz|
00000030 33 4D 79 30 39 68 4B 4F 53 50 52 47 68 74 72 67 |3My09hKOSPRGhtrg|
00000040 46 6C 4F 39 6A 6C 6B 66 62 46 62 57 4A 39 4C 78 |FlO9jlkfbFbWJ9Lx|
00000050 58 41 44 50 4F 50 6F 4F 53 36 50 78 6E 52 6D 37 |XADPOPoOS6PxnRm7|
00000060 65 4E 56 59 30 4A 52 38 31 65 5A 78 65 76 4C 66 |eNVY0JR81eZxevLf|
00000070 57 33 68 45 50 6D 57 50 49 52 4D 6E 62 78 7A 37 |W3hEPmWPIRMnbxz7|
00000080 44 51 41 33 4C 53 70 4D 62 71 41 73 56 39 66 50 |DQA3LSpMbqAsV9fP|
00000090 46 73 65 6C 4E 4C 67 75 61 55 5A 54 6F 6A 64 6E |FselNLguaUZTojdn|
000000a0 62 73 75 64 77 74 79 35 79 35 6A 70 42 76 45 32 |bsudwty5y5jpBvE2|
000000b0 74 7A 75 42 30 47 4A 54 5A 4E 54 6E 56 57 67 71 |tzuB0GJTZNTnVWgq|
000000c0 55 45 6C 63 67 75 39 73 6B 2B 6E 43 53 32 41 68 |UElcgu9sk+nCS2Ah|
000000d0 72 73 51 69 41 36 38 68 45 47 67 4A 48 65 65 6F |rsQiA68hEGgJHeeo|
000000e0 61 4A 78 70 4B 77 50 43 66 62 4F 78 52 75 54 37 |aJxpKwPCfbOxRuT7|
000000f0 76 73 53 50 61 41 55 55 66 46 79 52 53 35 4D 46 |vsSPaAUUfFyRS5MF|
00000100 72 58 6F 4F 68 79 74 46 51 69 4A 70 6E 79 58 34 |rXoOhytFQiJpnyX4|
00000110 4C 56 71 49 79 77 2F 62 4F 4E 47 37 65 62 79 31 |LVqIyw/bONG7eby1|
00000120 44 43 4D 34 38 73 4B 59 70 75 77 66 4B 62 6A 59 |DCM48sKYpuwfKbjY|
00000130 5A 34 46 72 72 69 50 48 75 6F 6E 6D 35 37 4E 67 |Z4FrriPHuonm57Ng|
00000140 6A 46 52 57 33 65 45 79 56 6F 55 68 6A 43 67 74 |jFRW3eEyVoUhjCgt|
00000150 69 34 45 4D 68 35 53 55 64 7A 34 52 57 47 49 54 |i4EMh5SUdz4RWGIT|
00000160 64 6D 72 70 33 68 |dmrp3h |
00000166
Serverantwort fehlerhaft.
5 Minuten später gingen die Dekodierungen fehlerfrei durch.
Wenn ich die Antwort auf Deine Frage hätte, stände sie bereits hier im Thread. Nur ist das, was Du derzeit vermutest eigentlich auszuschließen.Zitat:
Zitat von Guenni
MfG
MCMUPPET
Vermutlich kann uns nur der Autor des Dekoders sagen, in welchen Fällen diese Fehlermeldung kommt. Wie schon gesagt, bei mir passiert das nur sehr selten und und noch nie zuvor in dieser Häufigkeit.Zitat:
Zitat von MCMUPPET
0dardevil0 hatte mich ja gebeten, mich zu melden, wenn der Fehler nochmal auftritt.