Posts by ABPSoft

    Quote

    Originally posted by Schnello
    Also wäre mein Vorhaben ziemlich viel gefrickel. Schade...


    Als das anfing (ich hatte noch das Problem, dass ich ein x86-Userland auf einem x86-64-Kernel fahre, womit der Build auch nicht zurecht kommt) habe ich mir mit schroot eine stabile Build-Umgebung basierend auf Debian Wheezy amd64 angelegt, danach lief das alles wieder prächtig. Heute gibt's mehr Container-Lösungen als ich an einer Hand abzählen könnte, leider kenn ich mich mit keiner davon aus um detaillierte Empfehlungen geben zu können...


    HTH anyway,
    Andre.

    Quote

    Originally posted by DJens
    Die 3TB Platte ist intern an SATA angeschlossen. Kann man der Erkennung der Platten auf irgendeine Art und Weise mehr Zeit geben?


    Natürlich: :guckstdu:


    Das läuft bei mir, wo sich SATA und USB-Stick gern mal abwechseln, seit 2 Jahren stabil. Hat inzwischen zwei verreckte USB-Sticks überstanden (einer war platt, einer wurde Read-Only).


    HTH,
    Andre.

    Quote

    Originally posted by __QT__
    Damit das so funktioniert, musst Du eine der beiden Festplatten per NFS auf der jeweils anderen einbinden, so dass der ausgeführte Befehl beide Festplatten im Zugriff hat. Ohne geht es nicht.


    Strenggenommen geht es auch ohne, ich hab beim letzten Plattenwechsel rsync remote verwendet. Damit das noch zu Lebzeiten fertig wird, will man es aber nicht durch ssh tunneln (oder besser gesagt durch dessen Crypto), daher wird es dann doch etwas komplizierter als ein Befehl. Man braucht auf einer Seite den rsync Daemon. Die nötigen Schritte hab ich hier irgendwann mal gepostet, wer will kann das gern ausgraben. Das schöne an rsync ist, dass man immer wieder neu ansetzen kann, bis es mal fertig ist - bei mehreren TB auf der Platte und nur 100Mbps NICs ist das essenziell, weil es halt tagelang laufen wird bis es fertig ist. Der Charme von rsync mit NFS ist, dass es ohne den Daemon auskommt, für NFS hinzukriegen sich hoch und runter HOWTOs finden lassen und es dann praktisch fast genau so gut funktioniert (Wiederansetzen für die letzte, unvollständig übertragene Datei ist nicht so effizient, aber auch nur wenn die halbfertige überhaupt schon daliegt - macht rsync nur wenn man es ihm explizit befiehlt).


    Ich hab es nicht probiert (und erwarte irgendwie, dass mir ein BusyBox-lobotomisiertes wget in den Rücken fällt), aber der Wunsch nach einem einfachen Befehl könnte auch durch ein rekursives wget auf den FTP der anderen Box erfüllt werden. Wenn man Auth und das Ansprechen des richtigen Quellpfades hinkriegt. Probieren sei dem Leser zum Exerzieren überlassen.


    HTH,
    Andre.

    Quote

    Originally posted by hardlog
    [...]
    (1) kann ich das so dauerhaft laufen lassen ohne das ich die Box zu sehr belaste (CPU auslastung ....)?


    Meine 7020HD läuft seit Jahren mit dauerhaftem E2-Log in ein File auf dem USB-Stick. Bisher keine Probleme damit beobachtet ;)


    Quote

    (2) wie kann ich die oben genannte Befehle automatisieren, das sie nach nem Reboot wieder da sind.


    Ich manipulier bei mir einfach /usr/bin/enigma2.sh und füge eine Zeile ein wie die #3 hier:

    Bash
    #!/bin/sh
    exec > /media/usb/log/e2.`date +%Y%m%d%H%M%S`.log 2>&1
    prefix=/usr
    exec_prefix=/usr
    datarootdir=${prefix}/share
    [...]


    Das Zielverzeichnis (hier /media/usb/log) muss natürlich existieren, die Änderung ist nach jedem Update von enigma2 zu wiederholen und ein einziger Fehler, bei dem Du Dir dieses File vergurkst, sorgt dafür dass E2 nicht mehr startet. Kein Weltuntergang (opkg --force-reinstall install enigma2 spult zurück auf Anfang) aber man sollte grob wissen, was man da tut.


    HTH,
    Andre.

    Quote

    Originally posted by LukaNoah
    Obwohl ich den Crash auch im alten holo.GP nicht nachstellen kann. Es sei denn Du hast in der skin.xml was in der Farbdefinition geändert.


    Um das wirklich nachzustellen, muss vielleicht mehr zusammenkommen. Mir ist es nämlich auch gerade um die Ohren geflogen, und ich habe ebenfalls genau das OoZooN-Image laufen wie der OP. Genaugenommen habe ich nach einem Jahr ohne wesentliche Änderungen gerade eben auf diese Version upgraded und dann war der GS da. Nach ein wenig Code-Recherche wirkt das auf mich, als wäre ein Fix nicht mehr da, der mal eingebaut worden sein muss, damit man colorDisabled im Skin benutzen kann. Ob das im OoZooN oder im AutoTimer kaputt gegangen ist, kann ich nicht sagen.


    Siehe die Diskussion, die zu diesem Patch geführt hat.


    Der Q&D-Fix bei mir war, in skin_user.xml den kompletten betroffenen Screen (AutoTimerOverview) zu replizieren und im entries-Widget das colorDisabled="grey" zu entfernen:

    Code
    - <widget backgroundColor="background" colorDisabled="grey" enableWrapAround="1" itemHeight="30" name="entries" position="30,65" scrollbarMode="showOnDemand" size="820,450" transparent="1"/>
    + <widget backgroundColor="background" enableWrapAround="1" itemHeight="30" name="entries" position="30,65" scrollbarMode="showOnDemand" size="820,450" transparent="1"/


    Ich werd noch mal recherchieren, welche Version von AT ich jetzt eigentlich habe. Das Version-Tag, das eigentlich in plugin.py zu finden sein sollte, fehlt schon mal. Und der Epoch Jump auf eine wahrscheinlich ältere Version hier

    Code
    Upgrading enigma2-plugin-extensions-autotimer on root from 1:3.999+git5128+a019497-r0 to 2:3.999+git4808+ca897f0-r0...
    Downloading http://update.oozoon.de/opendreambox/2.0/experimental/mips32el/enigma2-plugin-extensions-autotimer_3.999+git4808+ca897f0-r0_mips32el.ipk.
    Removing obsolete file /usr/lib/enigma2/python/Plugins/Extensions/AutoTimer/web-data/tplAutoTimerTest.htm.
    Removing obsolete file /usr/lib/enigma2/python/Plugins/Extensions/AutoTimer/Logger.pyo.
    Removing obsolete file /usr/lib/enigma2/python/Plugins/Extensions/AutoTimer/Logger.py.
    Removing obsolete file /usr/lib/enigma2/python/Plugins/Extensions/AutoTimer/SimpleThread.pyo.
    Removing obsolete file /usr/lib/enigma2/python/Plugins/Extensions/AutoTimer/web-data/tplAutoTimerAbout.htm.
    Removing obsolete file /usr/lib/enigma2/python/Plugins/Extensions/AutoTimer/SimpleThread.py.
    Removing obsolete file /usr/lib/enigma2/python/Plugins/Extensions/AutoTimer/web-data/style_modern.css.
    Removing obsolete file /usr/lib/enigma2/python/Plugins/Extensions/AutoTimer/web-data/autotimereditor_style.css.


    kam mir gleich irgendwie komisch vor...


    Edit: Ist wohl ein Build- oder Repository-Glitch bei OoZooN. Der Git Commit ca897f0 ist von März 2014, daher fehlt dem der Patch - und sicher haufenweise andere Fixes. Das vermeintliche Upgrade war wohl eher ein Downgrade. Jemand nicht gemerkt, dass Schwerkraft Geschichte ist und der Kram inzwischen von GitHub kommt? Irgendwie alles unlogisch, es ist auch nicht der selbe Commit wie in Release (der ähnlich steinalt ist, aber da weiß man warum)...


    Edit2: Und da das nicht nur den AT betrifft sondern dem Anschein nach noch mehr meiner Plugins (alles von Schwerkraft?) in die Steinzeit zurückgebombt wurden (ein beherztes opkg list-installed | grep ca897f0 zeigt das ganze Drama) hab ich dann mal ganz schnell das Backup von vorm Upgrade zurückgespielt.


    HTH,
    Andre.

    Quote

    Originally posted by yoker77
    Wie führst Du die Messungen durch? Nutzt Du einfach zwei PCs oder spezielle Messgeräte?


    Eine Zertifizierung geht ausschließlich mit geeigneten Messgeräten. Seinerzeit (Cat5) war das ein MicroTest Pentascanner. Heute will man meist Cat6A messen können, und aufgrund der Aufkäufe in diesem Markt landet man da mehr oder weniger automatisch bei einem Fluke. Ja, das ist professionelles Zeug in einer professionellen Preisklasse. Liegt aber in der Natur der Sache. Um mal schnell was zu messen, was man privat zusammengestoppelt hat, borgt man sich am besten ein Messgerät aus - entweder hat man eins auf Arbeit bzw. kennt jemanden, der eins hat oder man findet einen professionellen Verleih. Das ist auch nicht gerade billig, speziell wenn man erst noch lernen muss, mit dem Gerät umzugehen. Daher gut planen - oder den Kenntnisträger gleich mit ausleihen - sprich, die Installationsleistung samt Zertifizerung doch vom Profi machen lassen.


    HTH,
    Andre.

    Quote

    Originally posted by JCool


    Nun war es bereits zweimal so als ich aus dem Urlaub kam, dass die Box dann eine Woche nicht mehr aufgenommen hat, weil sie gleich zu Beginn meiner Urlaubsabwesenheit nicht korrekt bootete und dann eine Woche lang mit folgender Meldung am Display stand:


    IP-Adresse (über DHCP erhalten, also nicht die IP, die ich normalerweise statisch vergeben habe)
    *** SERIAL SETUP ***


    Ja, die existenzialistische Angstvorstellung schlechthin. Und man kann nichts dagegen tun - das passiert offenbar auf der 7020HD gelegentlich, wenn der SSL beim Booten meint, an der seriellen Console (also dem Mini-USB) was entdeckt zu haben. Irgendeine race condition. Auftrittsfrequenz ca. 1mal aller 1,5 Jahre oder so. Wenn man täglich bootet (5h Ausschalttimer hier und die Kiste wacht um 17:00 von EPGrefresh getriggert automatisch auf), dann erwischt man den irgendwann. Leider hat DMM zwar einen 5h-Standby ins E2 gebaut, aber in den serial SSL würde auch einer gehören (am besten ein reboot nach 1h ohne jegliche serielle Aktivität).


    Notbehelfe:

    • Wenn man wegfährt, die Kiste durchlaufen lassen. Also den Stromspar-Ausschalttimer abschalten. Sie ist dann halt im Idle und zieht Strom.
    • Seriellen Consoleserver an den USB. Dazu auf'm Router, dem NAS oder was sonst durchläuft einen geeigneten Dienst drauf. Oder einen mit RasPi bauen. Oder oder oder. Dann im Notfall remote da drauf (man landet im SSL-"BIOS"-Screen) und rebooten (Exit & Save Settings IIRC).
    • Über IP schaltbare Steckdosenleiste ans LAN und Zugang über den Router ermöglichen. Dann wieder remote kicken. Oder einen Monitor basteln (z.B. auf dem Router), wenn die Kiste zu einer Zeit, wo sie eigentlich unbedingt aktiv sein müsste nicht pingt, dann die Steckdose power cyclen lassen. Wobei, ich meinte mich zu erinnern, dass die im SERIAL SETUP eigentlich gar keine IP hatte - wenn die sich aber hier wie im SSL üblich eine per DHCP zieht, dann kommt man auch direkt mit telnet ins BIOS und kann sie kicken. Passiert halt auch wieder zu selten, als dass man Erfahrung damit sammeln könnte (zum Glück).


    Ja, ist alles hässlich und nervt. Wäre schöner, wenn das einfach nicht passieren würde. Ich glaube aber ehrlich nicht, dass auf der 7020HD daran noch irgendwas passiert. Ist ja nicht erst seit gestern bekannt...


    HTH,
    Andre.

    Quote

    Originally posted by Schnello
    >/dev/null sendet die Meldungen ins Nirvana.


    Strenggenommen schließt es in dem für die Ausführung des Kommandos neu erzeugten Prozess den zuvor von der Shell ererbten Filedescriptor 1 (STDOUT, die Standardausgabe, zeigt interaktiv normalerweise auf das Terminal, in dem die Shell läuft) und öffnet /dev/null neu auf diesem Filedescriptor. Das wirkt sich dann so aus, dass alles, was der Prozess auf STDOUT ausgibt, im Nulldevice versenkt wird. Dort landen alle normalen Ausgaben eines typischen Unix-Kommandos, außer Fehlermeldungen (die gehen auf STDERR aka 2).


    Quote

    Was macht denn aber nun </dev/null


    Es schließt den FD 0 (STDIN, die Standardeingabe, typisch wieder das Terminal) und öffnet neu /dev/null auf diesem FD. Lesen von /dev/null führt zu sofortigem EOF (im Gegensatz zu /dev/zero, von dem man einen endlosen Stream von Null-Bytes lesen kann).


    Quote

    und warum führt es dazu das ffmpeg nun die Variablen richtig übernimmt?


    Um das zu beantworten, müsste man mehr von Deinem Script sehen. Typischerweise hat sowas oft mit der Funktion isatty(3) zu tun, die prüft, ob ein bestimmter FD auf ein Terminal zeigt. Einige Programme benutzen isatty(0) (also für die Standardeingabe) zum Test, ob sie interaktiv laufen oder in einem Script und verhalten sich dann unterschiedlich. Einige Programme verhalten sich auch unterschiedlich, je nachdem wie viele Parameter sie bekommen. Sie könnten z.B. bei Aufruf ohne Parameter von STDIN lesen und auf STDOUT ausgeben (Unix-Slang "Filter", der einfachste Filter ist cat(1)), mit einem Parameter hingegen vom angegebenen File lesen und auf STDOUT ausgeben und mit zwei Parametern vom ersten Filenamen lesen und auf den zweiten ausgeben. Es kann auch welche geben, die bei genau einem Parameter von STDIN lesen wollen - und sich dann anders verhalten, wenn das ein TTY ist oder EOF liefert etc. Details findet man sicher in der Manpage von ffmpeg und mit ein paar Tests. Dazu am besten das Script mit den Flags -xv laufen lassen, dann wird es sehr gesprächig (set -xv am Anfang, oder -xv hinter den Interpreter-Shebang).


    Klassische Übungsaufgabe: Erklären Sie die Abläufe in der File Descriptor Table und die resultierenden Auswirkungen auf den Befehl command bei diesem Bourne Shell Befehl und diskutieren Sie, ob die Reihenfolge, in der die E/A-Umleitungen angegeben wurden, beliebig änderbar ist:

    Code
    command </dev/null >/dev/null 2>&1


    HTH & SCNR,
    Andre.

    Quote

    Originally posted by mcscout
    Habs am PC mit HD Tune Pro physisch geprüft und der hat keine Fehler gefunden.


    Und was macht der? Reiner Lesetest? Schreiben?


    Was steht auf der Dream kurz nachdem das Filesystem RO gegangen ist im Kernel Log (Befehl dmesg)? Normalerweise häufen sich da die I/O Errors auf bestimmten Blöcken. Zusammen mit SMART weiß man dann, woran man ist.


    HTH,
    Andre.

    Hi,


    auch wenn sich das Folgende u.U. schroff liest, es ist nicht böse gemeint. Ich kann nur nicht anders, wenn sich irgendwo bestimmte Misconceptions (in Ermangelung eines gut passenden deutschen Wortes, Irrglaube ist etwas zu meta und Missverständnis ist semantisch kaum deckungsgleich) häufen und für die Zukunft betoniert werden, dann juckt es mir in den Fingern und ich muss die korrigieren. Klassischer Fall von XKCD 386. BTW, ich empfehle die Wikipedia-Artikel zu Common Misconceptions - öffnet einem die Augen zu dem, was man auf fremden Fachgebieten sicher zu wissen meint, was aber kompletter Unfug ist (z.B. das Napoleon klein war). Aber zurück zum Thema:


    Quote

    Originally posted by Micha_123
    also, nur weil auf dem kabel cat5e steht, heist es lange nicht das es auch so ist,


    Ein Kabel (verlegter Link von Patchpanel zu Dose oder Patchkabel aus der Tüte) ist genau dann Cat5e, wenn es eine Cat5e-Messung erfolgreich bestanden hat. Und genau so lange, wie es sie weiterhin besteht. Insofern hast Du Recht, was drauf steht ist völlig Wurst. Spätestens, wenn man paar mal kräftig drauf gelatscht ist, besteht auch ein vormalig gutes Kabel den Test nicht mehr. Wenn mir jemand sagt, dass etwas Cat5e ist, gehe ich daher immer davon aus, dass er Beweise dafür hat (ein Messprotokoll mit OK hinten dran).


    Quote

    sprich ich habe schon massenweise kabel gesehen mit cat5e kennzeichnung, die aber in den steckern einfach 1 zu 1 verdrahtet wurden und nicht die adernpaare beachtet worden sind, sprich 1+2, 3+6, 5+4, 7+8 so muss das normal im stecker verbunden sein. oft habe ich aber cat5e kabel gesehen die einfach 1+2, 3+4, 5+6, 7+8 im stecker verbunden gewest sind,


    Wo siehst Du solche Kabel? Das ist Ausschuss, Müll und je nach Situation (Neukauf) sogar Betrug. Klar ist das heutzutage üblicherweise in China verpresstes und nur durch minimale QA gelaufenes Zeug, mit dem die wer weiß was in den Rest der Welt entsorgen (noch jemand der Meinung, dass die verwendeten Weichmacher nach Verwesung stinken?) - aber meine Erfahrung sagt eher, dass das Zeug eine Fehlerrate im einstelligen Prozentbereich hat. Nahezu jedes Kabel, das frisch aus der Tüte kommt und gut behandelt wurde, besteht erstmal den Test. Ich kenne die von Dir beschriebenen Kabel, aber die werden nicht mit Cat5e beschriftet und sind für klassische Telefonieanwendungen gedacht (Analog, Systemtelefon oder ISDN, DSL auf der Seite vor dem Modem etc).


    Quote

    glaub mir, das kabel ist immer noch ein cat5e aber falsch verdrahtet, ergo kein gigabit.


    Glauben ist ein gutes Stichwort. Und nein, ich glaube das natürlich nicht - ein falsch aufgelegtes TP kann die Cat5e-Messung nicht bestehen. Es fliegt einem schon bei Cat5 um die Ohren (wobei Cat5 ja praktisch nicht mehr existiert, was die EIA/TIA angeht - es gibt nur noch 5e und das ist Class D), mit relativ hoher Wahrscheinlichkeit (je nach Länge) auch schon bei einer Cat3-Messung. Da geht noch bissel was, ich hab seinerzeit Cat3 schon mal mit je einem Pärchen aus zwei verschiedenen Sternvierern zum Laufen gebracht, aber das geht auch wirklich nur noch mit Cat3 (also 10Base-T). Ab 100Base-TX (was ja schon Cat5 voraussetzt) fliegt einem eine Fehlverdrillung ganz schnell um die Ohren. Klar, ein 0,5m-Patchkabel geht evtl. noch weil es nur wie ein aufgedrießeltes TP-Kabelende wirkt, aber das wird zunehmend instabil. Erfolgreich auf Cat5(e) Messen kann man das kaum.


    Quote

    zum anderen cat5e biss zu 100 meter, klar die verbundenen geräte komunizieren da mit gigabit( die geräte handeln da 1000base-t aus) , aber die effektive übertragung ist meist bei ca. 500 -600 mbit.


    Die 100m stehen im Standard. Und nein, die Bitrate kann nicht runtergehen, das gibt der Standard gar nicht her. Natürlich kann ein Kabel, das keine Cat5e-Messung bestanden hat, zu Fehlern beim Empfang von Frames führen (schlichte FCS-Fehler oder Framing-Fehler wie vorgebliche Runts und Giants sind die häufigsten Effekte). Wenn dann z.B. TCP zurückregelt, mag die resultierende "gefühlte Geschwindigkeit" auf irgendwas einbrechen (worauf konkret hängt von der Fehlerrate ab). Das ist aber was anderes, da gibt es echt Paketverluste und bei z.B. RTP (über UDP) wäre das fatal - man hätte z.B. prasseln im Audio oder Klötze im Video. Adieu, IPTV über Multicast...


    Quote

    also ich habe mein netzwerk mit cat6 dosen und cat5e kabeln (ca. 40 meter) nie annähernd 90 % der netzlast gehabt bei datei übertragung, da lag es meist im bereich von 60 MB/s zwischen 2 pcs,


    Diese Infrastruktur war mit einem geeigneten Messgerät erfolgreich auf Cat5e, also Class D Link gemessen worden? Falls ja, dann lagen schlechte Datenraten an den Geräten, die nicht hinterherkamen (volles Gigabit war lange nicht ganz einfach, mit einer klassischen PCI-Karte schafft man es z.B. schon mal nicht und einige Onboard-NICs waren früher mit lächerlichen Techniken angebunden, die schon bei 30MByte/s ins Schwitzen kamen - die 250MByte/s die man im Duplex-Vollast-Fall braucht wurden erst mit PCIe massentauglich). Ansonsten lag es einfach daran, dass etwas, das man aus CatX-Kabeln und CatX-Dosen zusammenschraubt noch lange nicht automatisch CatX ist - das zertifiziert nur eine Messung.


    Quote

    bei cat7 die ich jetzt verwende im ganzen haus, ist die übertragung zwischen 2 pcs, bei ca 100 MB/s und sogar etwas mehr. und das mit den gleichen dosen, switches usw. klar cat7 ist etwas übertrieben für den heim gebrauch, da würd cat6 vollkmmen ausreichen. aber wenn mann das netzwerk schon neu macht....


    "Cat7" existiert nicht. Und Du kannst da auch kein Cat7 haben, weil das mit RJ45-Steckgesichtern gar nicht geht. Effektiv hast Du sicher das gemacht, was man heute üblicherweise tut: Man verlegt Cat7 Kabel (also das, was die Hersteller so darunter verstehen) und legt es dann auf Cat6A- oder gar Cat6-Panels/Dosen auf. Das Resultat ist eine Infrastruktur, die eine Cat6A- oder Cat6-Zertifizierungsmessung bestehen kann. Und zumindest erstere ist eine Größenordnung zu gut für 1000Base-T, weil sie für 10GBase-T eingeführt wurde (mit Alien Crosstalk etc als Zusatzmessungen).


    Quote

    mann bedenke das die 100meter bei cat5e alles optimal laborwert angaben sind, da cat5e kabel im gegensatz zu cat6 ist kaum geschirmt sind und ziemlich leicht störanfällig auf aussensignalle sind erreicht mann kaum bzw. nur bei kurzen verbindungen (5 biss 10 meter) die vollen gigabit übertragungen.


    Die 100m sind kein Laborwert, die stehen im Standard. Allerdings als Summe aus verlegter Infrastruktur und angeschlossenen Patches (typisch 90m Link + 2*5m Patch, wobei der Standard das nicht wirklich festnagelt). Und ich muss Dich enttäuschen, wenn die 100m Cat5e (aka Link Class D) gemessen wurden, dann geht da 1000Base-T mit voller Bandbreite drüber, mit weniger Fehlern als der Standard zulässt (AFAIR 10^-13, aber nagel mich nicht drauf fest, kann auch bei Kupfer etwas schlechter gewesen sein - auf jeden Fall ist da höchstens aller paar Milliarden Frames mal ein FCS-Fehler). Klar ist UTP empfindlicher als STP und SFTP, PiMF etc wird immer besser - aber so lange der Standard UTP zulässt, ist der Schirm optional. In der Praxis macht natürlich niemand 100m mit UTP (jedenfalls in unserer Gegend, es gibt da draußen auch so einige Probleme, die man ohne Schirmung gar nicht hat und in der Folge hat UTP eine beträchtliche Fanbase, gerade dort wo die Stromversorgung im Favela-Style daherkommt). Andererseits, wenn mir jemand ein UTP-"Patch"kabel verkauft, das 100m lang ist und Cat5e spezifiziert (also einen Test besteht, wenn es nicht gerade DOA und ein Fall für RMA oder Gewährleistung ist), dann geht darauf auch 1000Base-T. Das ist das schöne an der Messung: sie garantiert das. Auch wenn Du ein zweites solches Kabel danebenlegst. Wass sie natürlich nicht vorhersehen kann, ist das dritte fremde und ungemessene Kabel welches Du daneben legst und das Störschnee sendet wie Sau. Aber das machst Du ja nicht, weil die Messung ja etwas zertifizieren soll ;)


    So, genug gekratzt, HTH anyway,
    Andre.

    Quote

    Originally posted by Micha_123
    ich denke das liegt am kabel, haste ein fertiges gekauft ? oft sind bilige kabel einfach 1 zu 1 verbunden, da werden die verdrillten pärchen nicht beachtet und bei längeren kabeln hat mann dann so probleme.


    Der OP schrieb es sei Cat5e. Das heißt es erfüllt alle Parameter des Standards und kann damit 1000Base-T über bis zu 100m tragen, völlig egal was es gekostet hat, ob es geschirmt ist oder nicht (UTP) oder ob es grün ist. Wenn Cat5e, dann Gigabit, Punkt.


    Quote

    also bei längeren kabeln sollte mann zumindest auf cat6 setzen wenn mann gigabit nutzen möchte.


    Quatsch. Cat5e wurde genau für 1000Base-T geschaffen, und zwar weil Cat5 zwar meistens funktioniert hat, 1000Base-T aber einige Eigenschaften des TP stresst, die in Cat5 nie gemessen wurden. Genau die wurden bei Cat5e zusätzlich aufgenommen.


    Cat6 macht niemand. Wenn, dann macht man Cat6A weil dort - so ähnlich wie bei Cat5e - wieder zusätzliche Parameter überlagert (Augmentiert) wurden, die den Betrieb mit 10GBase-T erlauben. Aber bis das unsere Residential Gateways ereilt, wird es noch lange dauern - der Energieverbrauch der PHYs ist nach wie vor zu hoch. Wahrscheinlich kommen eher irgendwelche Multigigs, weil die PHYs einfach da sind und die SOCs in den Geräten das irgendwann mitbringen.


    BTW, wenn zwei 1000Base-T fähige Geräte auf einem Cat5e nur 100Base-TX sprechen, dann kann das zwei Ursachen haben:

    • Unvollständige Verkabelung. Wenn statt vier Doppeladern nur zwei anliegen, dann kann nur 100Base-TX funktionieren. Gigabit braucht alle vier DA (acht Adern). Sparverkabelung wurde lange Zeit benutzt, wenn weniger Kabel in der Wand liegt als benötigt wird, typischerweise mit Splittern (z.B. für ISDN/Anlagentelefon + LAN). Natürlich ist das ein Fall von "nicht wirklich Cat5e", aber in der Praxis leider sehr verbreitet.
    • Eine der beiden Seiten handelt im Auto Negotiation-Protokoll explizit auf 100 herunter. Sowas kann u.U. verklausuliert als Stromsparmaßnahme ("green") daherkommen.


    HTH,
    Andre.

    Quote

    Originally posted by Fred Bogus Trumper
    (e)SATA ist immer /dev/sda, am USB Port könnte die Platte auch mal /dev/sdb werden.


    Garantiert ist das auch nicht wirklich. Bei mir haben früher der USB-Stick und die eingebaute 3TB WD Red mit schöner Regelmäßigkeit die Plätze getauscht - ich musste bei Low-Level-Aktivitäten immer vorher gucken was was ist oder halt die UUID-Symlinks nutzen. Für den USB-Boot war mir das zu unsicher - zum Glück gab es in meinem speziellen Fall (nur ein USB-Device und das ist der Boot-Stick, dazu keine wechselnde Anzahl weiterer Storage Devices) eine Lösung, die 100% Stabilität in die Erkennungsreihenfolge bringt: Den USB-Stick mit usb-storage.delay_use verzögert aktivieren. Das bootet seit mehr als einem Jahr mindestens einmal täglich und bisher absolut zuverlässig.


    FMI :guckstdu:


    HTH,
    Andre.

    Quote

    Originally posted by latte
    kann ich irgendwie aus der EPG-Auswahl einen Autotimer anlegen?


    So herum nicht (dass ich wüsste). Im Autotimer hast Du aber im Menü (nicht auf den Farbtasten, sondern die MENU-Taste drücken) ein "Import Timer from EPG". Ist leider schwer zu entdecken, wenn man es nicht weiß - dabei ist das IMO die beste Methode, einen Autotimer zu erzeugen, bevor man ihn tuned.


    HTH,
    Andre.

    Quote

    Originally posted by mrvica2
    oder googeln, "files recursiv löschen"
    ohne Gewähr


    Nur ging es nicht ums Löschen, sondern ums Zurückumbenennen. Wenn man das Directory wirklich im Zugriff einer Shell hat (nicht über ftp), dann geht das natürlich auch zu scripten. Hier kein komplettes Rezept, da das viel zu gefährlich ist, wenn man nicht genau weiß was man tut. Nur als Hinweis für eine mögliche Herangehensweise:

    Code
    root@dm7020hd:~# name="file.del"
    root@dm7020hd:~# echo ${name%.del}
    file


    Mit find eine Schleife zu füttern, die diese Substitution durchführt und an mv verfüttert, ist ein klassischer Ad-Hoc-Script. Leider gibt's auf der Dream ja kein mmv.


    Natürlich führen noch unzählige weitere Wege zum Ziel (oder dem völligen Verlust der Files). Ich würde aus Impedanzgründen den von Trial vorgeschlagenen Weg empfehlen.


    HTH,
    Andre.

    Hi,


    irgendein Update die Tage hat mir 3.0.1 auf die Box gebracht und seitdem sah ich keine Pending Timers mehr. Ich dachte erst, IBTS wäre komplett kaputt, aber ein testweise gestarteter Timer wurde angezeigt. Verwirrend war besonders, dass die diesbezüglichen Einstellmöglichkeiten auch gar nicht mehr auftauchten. Also mal in die Quellen geguckt: Da ist ja seit 3.0.0 kein Stein mehr auf dem anderen ;)


    Kurze Inspektion zeigte, dass das jetzt in Handler/Timers.py steckt. Und ein Blick ins E2-Log deckte dann auf:

    Code
    InfoBarTunerState start
    [IBTS Plugins]: Files: ['StreamWebIf', 'Live', 'StreamServer', 'StreamOpenWebIf
    ', 'Timers', 'Records', 'Unknown']
    [IBTS Plugins] Load exception: No module named pprint
    [IBTS Plugins] No module available: Timers


    Klar, wenn Timers nicht geladen wird, dann kommt da auch nix. Und die Zeile davor sagt uns auch warum:

    Code
    root@dm7020hd:/usr/lib/enigma2/python/Plugins/Extensions/InfoBarTunerState# grep pprint Handler/Timers.py
    import pprint
    #pprint.pprint(timer_list)
    #pprint.pprint(toremove)


    Entweder ist das eine undeklarierte Dependency oder (wie's mir eher aussieht) ein Kommentarzeichen zu wenig. Hier hat dann ein beherztes opkg install python-pprint auch prompt geholfen ;)


    HTH & Thanks,
    Andre.

    Quote

    Originally posted by champ67
    [...]
    3. Papierkorb
    Leert sich nicht automatisch (siehe Anlage), egal ob ich das auf täglich oder wöchentlich einstelle. Es wird zwar angezeigt, wann die nächste automatische Leerung erfolgen soll - das passiert dann aber nicht.


    Die Zeiten im Screenshot legen irgendwie nahe, dass da mehr als eine Woche gar kein Löschen stattgefunden haben kann. Bist Du sicher, dass die Box zum Zeitpunkt des Löschens an und im Idle war? Gelöscht wird nur, wenn die Box läuft, Idle ist und keine Aufnahmen laufen oder in den nächsten Minuten anstehen. Ist sie immerhin an, aber eine der anderen Bedingungen greift nicht, dann beginnt ein Timer, der das im konfigurierten Zeitintervall erneut überprüft. Im Prinzip wiederholt der die Prüfung ewig, es sei denn man schaltet die Box aus (Standby).


    Quote

    Aufbewahrungsfrist habe ich auf 2 Tage gestellt. Zwischenzeitlich sammeln sich im Papierkorb aber bereits Filme der letzten drei Wochen.


    Das sollte orthogonal sein. Wie gesagt, da sein dem 8.11. gar kein Löschlauf stattgefunden hat, konnte auch die Aufbewahrungsfrist nicht greifen. Zu klären wäre also, wieso das Löschen seit drei Wochen nicht zur Ausführung kommen konnte.


    Am besten stellst Du die Funktion mal auf täglich, lässt die Box zu dem Zeitpunkt im Idle und wenn das wieder nicht klappt, dann mach beim nächsten Durchlauf ein E2-Log. Kenn jetzt die 7080 und OE2.2 nicht wirklich, aber hier unter OE2.0 geht das seit Ewigkeiten exakt so wie vorgesehen. Meine Box wird von EPGrefresh um 17:00 geweckt, bootet in den Idle und startet mit dem Abklappern des EPG. Startzeitpunkt der Papierkorbleerung der AMS ist 17:05. Geht nur schief, wenn die Box zu der Zeit unerwartet läuft (Wochenende, Feiertage, Aufnahmen) - dann klappt es mit dem Löschen meist an einem der Folgetage. Was natürlich passieren kann ist eine Verkettung unglücklicher Umstände: Wenn das von vornherein nur einmal wöchentlich probiert wird, zu dem Zeitpunkt dann jeweils grade was aktiv ist was den Start behindert und die Kiste dann z.B. direkt nach einer Aufnahme runterfährt, weil die 5h Euro-Standby erreicht sind, dann geht das schon mal schnell für einen Monat schief. Deswegen besser täglich auf einen gut geeigneten Zeitpunkt platzieren und die Aufbewahrungsfrist etwas höher setzen, falls man doch mal noch was retten will (hatte die anfangs auf 3 Wochen, aber die Platte hier ist auch notorisch am Überlaufen und inzwischen sind es nur noch ein paar Tage).


    HTH,
    Andre.

    Quote

    Originally posted by Kaiser Wilhelm
    Ok, dass wusste ich nicht. Dann ist die Einzelsendersuche ja irgendwie nicht mehr zeitgemäß.


    Die Einzelsenderangabe wird übrigens auch zunächst auf die wirklich notwendigen Services ausgedünnt, bevor diese angesprungen werden. Das läuft immer optimal, ob Du nun ganze Bouquets oder doch einzelne Sender benennst. Insofern hat diese Variante durchaus ihren Verwendungszweck, wenn z.B. jemand mit riesigem Bouquet nur einen Teil davon im EPG haben will.


    HTH,
    Andre.

    Quote

    Originally posted by m0rphU
    z.B. um Teil 2 an Teil 1 anzuhängen:
    cat 002.ts > 001.ts


    Oops, so nicht - danach ist 001.ts Geschichte und enthält nur noch das, was in 002.ts steht. Du wolltest sicher >> verwenden, aber generell finde ich es unglücklich, die Originaldateien zu manipulieren bevor man weiß ob das wirklich funktioniert (bei TS ist das relativ wahrscheinlich, aber exakt weiß man es erst nach einem Test, die Reelbox könnte auch irgendwelche Header und/oder Footer eingefügt haben). Daher besser sowas wie:

    Code
    cat 00001.ts 00002.ts 00003.ts > all.ts


    Dabei kann man für die Quellfiles natürlich Wildcards benutzen (z.B. wenn das pro Aufnahme ein eigenes Directory ist einfach 0*.ts), als Ziel einen relativen oder absoluten Pfad nach anderswo angeben (z.B. ../ReelCat/MyMovie08154711.ts) etc...


    HTH,
    Andre.

    Quote

    Originally posted by John McClane
    ist das bei den aktuellen Images denn immer noch ein Problem?


    Bei mir ist es vor wenigen Monaten wieder aufgetaucht und wurde so prekär, dass ich jetzt testweise von USB boote. Davor war mal ein reichliches Jahr Ruhe. Ich hab ja hier OoZooN, ist also nicht ganz vergleichbar - aber da gab es das letzte größere Update im März und irgendwie passt das gut zur Rückkehr dieses Problems...


    HTH,
    Andre.

    Quote

    Originally posted by TiTitan

    Code
    tar -cjpf /media/hdd/backup/my_mediabootstick_backup.tar.bz2 /


    oder müsste das Kommando anders lauten?


    Ich würde kein bzip2 auf die arme CPU in der Dream loslassen. Selbst gzip mit Standard-Suchtiefe (6) schleppt sich schon ziemlich dahin. Da auf der HDD gewöhnlich endlos Platz im Vergleich zur Größe des Root-FS herrscht, kann man darauf auch verzichten. Oder man schickt den Compressor später mit nice hinterher.


    Gegen das Problem, weitere Mountpoints (wie die unter /media) vom tar auszuschließen, hilft am besten ein bind mount, der das Root-FS vereinzelt. Mal alles zusammen:

    Code
    D=`date +%Y%m%d%H%M`
    mkdir /tmp/backup-root
    mount --bind / /tmp/backup-root
    cd /tmp/backup-root
    tar cf /media/hdd/backup/root-${D}.tar .
    cd /media/hdd/backup
    umount /tmp/backup-root && rmdir /tmp/backup-root
    nice -n 19 gzip root-${D}.tar


    Das ist jetzt ad hoc hingeschrieben, in ein Script packen, testen und in Cron hängen sei dem Leser als Übung überlassen ;)


    Ob das reicht - nun, zumindest ist das Root-FS komplett drin und damit wiederherstellbar. Bequemer wäre es für das Zusammenflicken eines Ersatz-Sticks, auch noch ein tar vom /boot zu machen sowie eine Kopie vom MBR zu haben. Oder gleich ein dd-Image vom Anfang des Sticks bestehend aus MBR und der ersten Partition - die ist klein und man hat das FAT16 auch gleich mit abgefrühstückt. Da führen viele Wege zum Ziel...


    HTH,
    Andre.