Posts by theMario

    Hallo CPI,


    ich schreibe sicher zu spät, aber für Andere vllt. hilfreich. Um auf das Webinterface von pyload via WAN zu gelangen, musst du im Router natürlich den Port (8100 bei mir - ist aber der gleiche, wie bei der Anmeldung im Heimnetz) freigeben und auf die Adresse vom rPi verlinken. Protokoll ist tcp

    Um pyload via App zu steuern, brauchst du im Router den Port 7227 bzw, wenn im Webinterface zu Hause geändert, eben den einstellen. Alles Andere sollte klar sein und wenn sich der rPi von außen nur über https ansteuern lässt, dann dies in den Einstellungen aktivieren. Ach ja - im Playstore zu Google Android ist glaube die pyload App vor Jahren schon raus geflogen. Aber der Store ist ja nicht der Einzige... .


    Übrigens, pyload lief als 4.9.5 auf dem QNAP NAS 4 Wochen sauber nach dem 180305 update. Dann kam ein Blitz und aus der TS453A wurde eine TS453B - pyload läuft (noch) nicht wieder.

    Lass es dir gut gehen.


    Mit pyload kann man sich eben sein ganzes Leben beschäftigen.

    Danke für deine Antwort.


    Natürlich habe ich jd2 auch auf dem rPi am Laufen. Jedoch finde ich die Bedienung etwas ... nennen wir es "anders" und nicht meins. Die Unterschiede sind ja bekannt. Natürlich zieht jd2 bei mir auch alles in den gleichen Ordner wie pyload auf dem NAS. Nur ändert das ja alles nix an der (Nicht)Funktion von pyload.
    Auf meinem NAS (QNAP TS453A) läuft pyload bis 4.2.x - aber da ich OVPN nutzen will und natürlich mit der Zeit gehe, ging ich auf 4.3.3 Pyload ist nicht mehr im Paketzentrum und nur noch über Umwege zu installieren, die eben nicht zuverlässig sind. Ergebnis ist da...
    Zitat pyload: JS engine: fehlt
    Zitat System: js -version JavaScript-C 1.6 pre-release 1 2006-04-04 (OSSP js 1.6.20070208) & node --version v4.5.0


    Welche Verlinkung liegt da quer?


    Du siehst, es ist nicht immer einfach.

    Hallo Gemeinde,


    habe wegen aktueller Probleme auf meinem QNAP NAS mit pyload (pyload erkennt die installierte JS Umgebung nicht) mir mal pyload auf dem rPi 3 angetan. Was liegt näher, als sich hier im rPi Forum Hilfe und Unterstützung an zu lesen?
    Allerdings... pyload läuft auch hier nicht. Man braucht sich auf dem hier verwiesenen github- Link (#225 07.04.2016, 21:34:27) auch nicht einlassen. Es fehlen ein paar grundlegende Sachen. So auch die pyloadCore.py
    Was mache ich falsch?
    Pyload selbst ist von pyload.org auf pyload.net umgezogen. Die empfohlene Installation dort führt auch nicht zum Erfolg. Pyload lässt sich installieren, aber der UpdateManager ist veraltet und Zippyshare funktioniert auch nicht.
    Mir ist bewusst, dass der Thead hier in die Jahre gekommen ist, aber pyload ist ja nicht tot!



    LG theMario


    Aria2 als Alternative zu empfehlen ist nicht sinnvoll, da Dieser Containerdateien (.dlc) nicht verarbeiten kann, oder liege ich da auch falsch?

    aeppsi


    belese dich einfach mal in das Projekt "Kodi" ein. Das ist zwar etwas umfangreicher, bedarf eine grafische Oberfläche, also ein Display, aber selbst dafür gibt es hier Anleitungen. Für unterwegs wäre dann noch eine USV nötig. Auch dafür gibt es hier Anleitungen. Oder hier
    Dein Projekt ist etwas umfangreich. Drum verweise ich nicht direkt auf eine der vielen Anleitungen. Die für dich Passende wird dabei sein. Sie zu finden, ist ... deine Aufgabe.



    LG
    theMario

    Habe mir den JD2 auf meinen rPi zum Laufen gebracht und er funktioniert bis zu dem Punkt, wo er beginnen sollte zu laden. Ich kann ihn also ausführen, ich kann von meinem Notebook aus via Click 'n load die Aufgaben übergeben, der rPi legt sie in den Linksammler. Ich kann sie dann anstubsen und den Download starten. Es wird auch wie gewünscht, der Ordner erstellt. Die Rechtevergabe funktioniert, jedoch beginnt er nicht mit dem Laden. Die vergebenen Links sind auch ladbar.


    Die Logs sind ja nun sehr reichlich. Aktuell zu meinem tun fand ich in der JDownloader/logs/147070137945*/Log.L.log.0 passend folgende Einträge.



    Wer kann mir bitte helfen, den Fehler zu finden


    Danke im voraus


    theMario

    meigrafd


    du wirst ne Menge mehr wissen für Linux als ich, abr als ich deinen Text las, sagte ich mir halt ... putty und ich dachte richtig.


    Code
    pi@rpi ~ $ ps aux |grep watch
    root 3996 0.0 0.3 1740 1680 ? SLs 15:25 0:03 /usr/sbin/watchdog
    pi 4281 0.0 0.1 4144 856 pts/0 S+ 17:06 0:00 grep --color=auto watch

    Der braucht kein Passwort,er ist es ja selbst, der den Wachhund los lässt. Somit sollte das auch machbar sein. Aber das nur am Rande.


    Im Grundsatz hast du Recht, einen Fehler umgeht man nicht, den räumt man aus. Ist schliesslich kein Riff und der rPi kann nicht (allein) schwimmen. Jeder Vergleich hinkt.
    Das Auskommentieren einer Ursache wird gern genommen, um eine Wirkung zu ändern. Was Anderes haben wir also auch nicht gemacht, als umfahren. Ahoi.


    Ich werde mal schauen, wie der rPi die kommenden zwei Wochen läuft. In der Zeit kann ich mich auch mit Andreas seiner Erfindung auseinander setzen.
    Habe noch ein anderes Problem, aber da muß ich wahrscheinlich einen neuen Thread aufmachen.


    ps aux liefert mir einen (wichtigen) Prozess - allerdings unter einem User, den es nicht gibt.


    Code
    pi@rpi ~ $ ps aux |grep fetch
    111 3150 1.2 0.7 6940 3504 ? Ss 11:44 4:18 /usr/bin/fetchmail -d 900 -f /etc/fetchmailrc --pidfile /var/run/fetchmail/fetchmail.pid --syslog


    Wer macht sich da zum superuser?


    Während top meint,

    Code
    3150 fetchmai 20 0 6940 3504 1956 S 0,0 0,7 4:21.34 fetchmail


    Mysterien sollte ich ja suchen, oder? :wallbash:
    Ach ja, hier im Forum, nicht in den Unterwelten meines rPi :angel:


    LG theMario

    So, habe mir mal die ganzen Zusammenhänge noch einmal angelesen.
    Im Grunde führt er Wachhund einen reboot aus, weil ihm die CPU-Last nicht gefällt. Einen reboot im herkömmlichen Sinne führt er nun auch nicht aus, sondern

    Quote


    Wenn das System gerade viel zu tun hat aber den Watchdog nicht rechtzeitig anpingt, macht der Watchdog kein reboot sondern macht das selbe als wenn ihr mitten im Betrieb das Stromkabel zieht!


    Das geht ja nun garnicht. Warum läuft er dann überhaupt noch? Wenn ich den Stecker zog, war das Dateisystem in zwei von drei Fällen nicht mehr zu gebrauchen. :@


    Lange Rede kurzer Sinn, die # ist erst einmal gesetzt. Lösungen werde ich mir anlesen. Aber nicht heute.


    Andreas

    Quote

    Das Programm habe ich hier im Forum hochgeladen... Du kannst es gern an Deine Bedürfnisse anpassen.


    Das werde ich mir einmal suchen.


    Ich bedanke mich für eure aufklärenden Sätze.


    theMario


    Kommentier diesen ganzen max load krams einfach aus oder setz es auf 0 .... das macht eh kein Sinn, vorallem nicht "last 1 min"


    meigrafd


    das kann nicht die Lösung sein. Wenn wir jedes Hilfssystem abschalten, weil es nicht verständlich läuft, sterben viele Leute. Jeder Vergleich hinkt.
    Mir pers. ist es lieber, der rPi bootet einmal in der Woche neu, als das er im Netz hängt, nicht ansprechbar ist und die Lösung dann ein "Netzstecker ziehen" sein soll. Von diesen anfänglichen Maßnahmen wegen Fehler an der Tastatur wollte ich weg sein. Habe mir so das Dateisystem öfters zerschossen und auch nicht immer gleich (mit "fsck.ext4 & co") retten können. Meist hilft da nur noch ein Backup vorziehen und drüber bügeln. Das ist viel mehr Aufwand und der rPi ist stundenlang offline. Schliesslich bin ich nicht 24/7 für meine Hardware da. Ist wohl kaum jemand.
    Ich muß noch dazu schreiben, am rPI hängt weder Tastatur, noch Monitor und um Letzteres zu ändern, bedarf es auch ein herunter fahren, oder "der Knochen kommt zum Hund" (40" TV zum rPi in den Keller tragen)
    Der rPi hat ein Problem, schreibt mir das noch brav und ich nehme ihn jetzt "den Stift weg" ?
    Das kann es dann nicht sein, oder?

    Kein Problem.


    Die Datei wurde von mir nicht bearbeitet. Ok, ganz sicher bin ich nicht, aber wenn ich das so lese, was da drin steht - nö - kenne ich nicht.


    Danke für die schnellen Antworten.


    Zunächst erst einmal, der rPi hat nicht viel zu tun.
    Er läuft nur noch als Mailserver und ejabbert eumelt vor sich hin. Darüber war aber zum Zeitpunkt des reboot keiner am werkeln. Das Projekt ist auch noch in Testphase. Texten und Bild-Datei-Versand funktionieren (soweit Empfänger auch online ist) aber voice oder gar Videochat (noch:angel:) nicht.


    Die Ausgabe der watchdog.conf

    Code
    pi@rpi ~ $ cat /etc/watchdog.conf | grep -i max-load
    max-load-1 = 24
    #max-load-5 = 18
    #max-load-15 = 12


    theMario

    Hallo Gemeinde,


    Mein rPi schickt mir alle 4 -7 Tage eine Mail mit dem Inhalt:


    Code
    Betreff: rpi.fritz.box is going down!
    Message from watchdog:
    The system will be rebooted because of error -3!


    Die üblichen Verdächtigen abgeklappert in /var/log/ erklären mir:



    Ich kann jedoch damit nichts anfangen.


    Meine Softwareumgebung:


    Code
    pi@rpi ~ $ uname -a
    Linux rpi 3.12.28+ #709 PREEMPT Mon Sep 8 15:28:00 BST 2014 armv6l GNU/Linux


    und mein rPi ist ein "B" ohne plus


    Wer kann helfen?


    LG theMario

    Ihr könnt mich hauen, teeren und federn, aber ich habe nicht neu formatiert.
    Habe beide Sticks ausgehangen und in meiner DS713+ angeschaut. Sie war meiner Meinung - ext4 aber beide!
    Wieder angesteckt... an den rpi und ... UUID hat sich geändert.
    Ich bin mir sicher, dass ich seit dem Auslesen des UUID und eintragen in fstab keinen Stick formatiert habe, aber dennoch... .





    Also ist das mit dem UUID jetzt geklärt. Hoffe mal, der ändert sich nur, wenn man einen Stick formatiert und nicht nur mal aushängt und abzieht.


    Ich danke euch für eure Hartnäckigkeit.


    :danke_ATDE:


    theMario
    [hr]
    Habe gerade nachgelesen, dieses faule Tool blkid
    Das liest die UUID nur einmalig von einem angeschlossenen Gerät und trägt es in eine Datei ein. Danach wird nur noch aus der Datei gelesen. Ich liebe solch copy&paste Kollegen.

    :thumbs1:tmaex - danke dir:bravo2:





    Ist das nun gelöst, oder brauchen wir noch ein reboot zur Sicherheit?


    Ich denke mal, ich hätte die Sticks aushängen sollen, nach dem edit der fstab vor dem reboot !?


    Und für meigrafd - ich war selber mit dolphin drauf :stumm: sag nix.


    Code
    pi@mariosds ~ $ sudo blkid
    /dev/sda1: UUID="a9035bf3-c448-49d1-8e8f-1760d30fc73f" TYPE="ext4"
    /dev/sdb1: UUID="e053c322-c15e-4444-837b-cab0daaf2f7d" TYPE="ext4"
    /dev/mmcblk0p1: SEC_TYPE="msdos" LABEL="boot" UUID="2654-BFC0" TYPE="vfat"
    /dev/mmcblk0p2: UUID="548da502-ebde-45c0-9ab2-de5e2431ee0b" TYPE="ext4"


    Aber dennoch



    Wer lügt mich hier an von den beiden Ausgaben?


    FAT32 versteht nicht die Dateirechte von Linux. Laut fdisk ist /dev/sda1 aber FAT32 ... also kann das nix werden ;)


    Deine fstab Einträge sind somit auch falsch, weil du da ext4 angibst aber laut fdisk ist es vFat


    Sorry, aber auch du solltest erkennen, dass es nicht vfat sein kann. Das verrät dir schon mal die Länge des UUID. VFAT formatierte Datenträger haben eine viel Kürzere. Korrigiere mich... .

    Sorry, brauche für eine Antwort noch 30min.


    Derzeitige Antwort:


    Code
    pi@mariosds ~ $ sudo umount /dev/sda1
    umount: /media/backup: device is busy.
    (In some cases useful info about processes that use
    the device is found by lsof(8) or fuser(1))
    umount: /media/hdd: device is busy.
    (In some cases useful info about processes that use
    the device is found by lsof(8) or fuser(1))


    Muß erst mal herumtelefonieren, wer da wieder auf dem rPi herum bastelt.


    Bis nachher.


    theMario

    Hallo Gemeinde,


    alles war so schön mit meinem rPi. Alles, was ich wollte - lief. Schön war die Zeit.
    Dennoch verabschiedete sich beim letzten Upgrade das Dateisystem und (gerade ich) hatte kein aktuelles Backup.
    Dem will ich nun vorbeugen. Ein Script, ein zweiter Stick (am aktiven Hub) und alles wird gut.
    Im Grunde läuft der ja auch, allerdings blinkt der alte Stick nun mit und ich habe Zugriffsprobleme beim Einbinden in meinem NAS (DS713+) Via Fedora auf dem Notebook komme ich auf beide Sticks bzw. auf die Mountpoints.
    Des weiteren gibt es Probleme beim Auswerten der Sticks via "blkid" und "fdisk". So recht kann ich denen nicht glauben.


    Wer kann hier mir auf die Sprünge helfen?


    Fangen wir im Urschleim an





    Und jetzt mein Problem.



    Ich gestehe, beide Sticks sind definitiv ext4 formatiert.
    Gemountet will ich die Sticks mittels fstab haben.



    Heraus gekommen ist nun alles ein wenig Anders.


    Ein weiteres Problem ist die Rechtevergabe. Ich kann in putty hinein kriechen, aber die Rechte des Ordners /media/backup zu ändern, erlaubt er mir nicht. Er schluckt zwar meine Änderungswünsche ohne Meldung, aber ändern tut sich nichts



    Das sieht alles nicht aus.



    LG theMario


    PS: Keine Ahnung was Dich am Hoover stört. Ist ein Link auf mein Backuprogramm und davon habe ich einen SD Kartenclone gezogen, mit dem ich dann den upgrade und Test durchgezogen habe.


    Ganz einfach, ich dachte, da gibt es ein Script, wie man ganz schnell zu seiner Wiederherstellung eines ehemaligen Zustandes der SD-Karte kommt. Der Link führt jedoch nur zum Backupscript. Das Script benutze ich mittlerweile auch auf einer SD-Card, allerdings lagere ich den Speicherort aus (Synology DS713+)
    Eigentlich soll ja der rpi aus Kostengründen die Aufgaben der 24/7 laufenden DS713+ übernehmen.
    Kostet € 10.- / Monat - der rpi nur € 1,xx ... . Geiz ist eben goil.


    Aber, mir fehlt verdammt noch einmal dieser gewisse Satz in deinem letzten Post. Ok, Schwamm drüber.


    So viel Ahnung habe ich ja nicht, von Linux Debian und Co. Allerdings gab es ein kernel-update / rpi-update.
    Ob und was da nun wieder geändert wurde, keine Ahnung.


    Wäre aber schön, wenn einer der Mittlesenden das Problem noch einmal aufgreift und vielleicht eine Lösung findet.


    LG theMario

    Framp, erst einmal Danke, daß du dir diese Mühe in der Woche gemacht hast. Natürlich habe ich die Syslogs nicht angeschaut. Mein Pech, ich weiß.


    Aber während du meine Texte nur überflogen hast, habe ich Deine immer gelesen und du hast etwas nicht berücksichtigt.


    Meiner:

    Code
    pi@rpi ~ $ uname -a
    Linux rpi 3.10.25+ #622 PREEMPT Fri Jan 3 18:41:00 GMT 2014 armv6l GNU/Linux




    Deiner:

    Code
    root@raspberrypi:~# uname -a
    Linux raspberrypi 3.6.11+ #538 PREEMPT Fri Aug 30 20:42:08 BST 2013 armv6l GNU/Linux


    Ich schrieb ja, bis Ende 2013 war alles gut. Und ich schrieb auch, mit einem Image aus 9.2013 läuft das auch. Jedoch ein upgrade auf eben meine hier geschriebene Version lässt die Brücke nicht wieder zu.


    Vorschlag, wenn du Zeit hast - mach ein upgrade auf diese aktuelle Version. Wir werden zwar nicht heiraten, aber ein "Ja, du hast Recht" würde ich dann schon gern lesen.


    Ansonsten werde ich nochmals die Brücke auf der neuen Version zum laufen bringen und du sagst mir, welche log Files ich dir hier reinbauen soll. Geht mir ja nicht darum, hier zu streiten, sondern nur darum, daß der pi mit einer SD Card lebt und die 2. (die mit der 9.2013 Version und funktionierender Brücke) wieder in meine Kamera kommt.


    Guts Nächtle


    theMario


    Anmerkung: Das du gestresst bist, erkenne ich schnell. Ein MouseOver über deinen ersten Link "dieses Script" in deinem letzteen Beitrag hier erklärt dir auch, daß du dir ein wenig mehr Zeit lassen solltest.