Posts by ABPSoft

  • Bootschleife

    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.

  • [update 0.4-r0] enigma2-plugin-extensions-mediaboot_0.4-r0_mips32el

    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 :winking_face:


    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.

  • [update 0.4-r0] enigma2-plugin-extensions-mediaboot_0.4-r0_mips32el

    Hi,


    danke erstmal allen, die sich so lange mit dem Thema beschäftigt und die Resultate hier in Form von Code und Beiträgen publiziert haben, bis sich aus den drei Threads ein klares Bild zur generellen Vorgehensweise ergab. Ich habe mir damit einen Boot-Stick gebastelt (ohne das Plugin oder Script zu nutzen, ich wollte genau wissen wie es geht) und der hat zu meinem eigenen Erstaunen wirklich beim 1. Versuch gebootet :winking_face:


    Mein ungutes Gefühl war damit aber nicht weg: Bei meiner 7020HD wechselten in der Vergangenheit der USB-Stick und die HDD mit schöner Regelmäßigkeit die Erkennungsreihenfolge, mal war der Stick sda und die HDD sdb und dann mal wieder umgekehrt. Dank UUID-Mount ist das an sich kein Problem, aber UUID-Boot funktioniert nur mit initrd und PARTUUID gibt's erst seit Kernel 3.8. Also muss die Erkennungsreihenfolge für die korrekte Funktion stabil sein, sonst habe ich eine 50-50-Chance dass es nicht bootet. Wie sind denn da die Erfahrungen in der Praxis bei Einsatz des Plugins? Ist ja nun eine Weile in der freien Wildbahn...


    Mein Vertrauen stieg jedenfalls deutlich, als ich diesen Kernel-Parameter entdeckte:

    Code
    usb-storage.delay_use=
                        [UMS] The delay in seconds before a new device is
                        scanned for Logical Units (default 1).


    Ich boote jetzt mit

    Code
    /boot/vmlinux-3.2-dm7020hd.gz rootfstype=ext4 root=/dev/sdb2 usb-storage.delay_use=3 rootdelay=8 rw console=ttyS0,115200

    was heißt, dass der USB-Stick erst ca. 3-4s nach seiner Entdeckung am Bus wirklich als Storage aktiviert wird. In der Zeit hat sich dann die HDD ziemlich sicher gemeldet und ein Race ist sehr unwahrscheinlich. Bis zum Ablauf von rootdelay ist der Stick dann mit Sicherheit da und wird gemountet (* markiert die interessantesten Zeilen):



    Bisher funktioniert das hier prächtig. In Fällen, wo also SATA HDD(s) gegen genau einen USB-Stick gewinnen müssen, damit der an einer stabilen Position landet, erscheint der Parameter daher sehr hilfreich. Ich wollte das nur an die Entwickler und Tester des Plugins zurückgeben, vielleicht hilft es dort ja auch jemandem.


    Thanks,
    An"no more UBIFS sudden death"dre.

  • UBIFS sudden death

    Quote

    Originally posted by Jojojoxx
    Mich wundert, dass die Einträge zu den sporadisch auftretenden Ubifs Fehlern bei der 7020hd alle mindestens ein Jahr alt sind, scheinbar hat niemand das Problem bei aktuellen Images mehr.


    Naja, die Mehrzahl der Regulars hier spielt wohl inzwischen lieber mit 7080HD und 820HD...


    Quote

    Ich habe heute bereits zum zweiten Mal (auf einem aktuellen OE 2.0 Image) das Problem gehabt, dass die Box hängt und dmesg massenhaft fehler der folgenden Form auswirft:


    Code
    May  1 17:52:01 dm7020hd user.err kernel: [ 5710.136000] UBIFS error (pid 6662): ubifs_read_node: bad node at LEB 620:159744, LEB mapping status 0
May  1 17:52:01 dm7020hd user.err kernel: [ 5710.138000] UBIFS error (pid 6662): do_readpage: cannot read page 0 of inode 7186, error -22


    Bei mir ist das Problem auch wieder da, und zwar verschärft. Es fing IIRC Ende März an, als die Box beim halben Ladebalken stehen blieb. Hintergrund war eine kaputte libQt* (weiß nicht mehr exakt welche, aber das sind halt mit die fettesten Files auf der Kiste). Ich hab die aus dem Backup ersetzt. Seitdem geht es aber zunehmend rasanter mit Problemen. Ablauf scheint immer wieder folgender zu sein:


    [list=1]
    [*]Beim Lesen von Files im Flash kommt es zu korrigierbaren ECC-Fehlern und UBI scrubbed den betreffenden LEB (kopiert ihn in einen neuen PEB):

    Code
    [ 1560.247000] brcmnand_ctrl_verify_ecc: Correctable ECC error at 00010000:24afb800
[ 1560.280000] brcmnand_ctrl_verify_ecc: Correctable ECC error at 00010000:24afb800
[ 1560.509000] UBI: scrubbed PEB 2315 (LEB 0:1599), data moved to PEB 2645
[ 1561.456000] brcmnand_ctrl_verify_ecc: Correctable ECC error at 00010000:252c4a00
[ 1561.459000] brcmnand_ctrl_verify_ecc: Correctable ECC error at 00010000:252c4a00
[ 1561.720000] UBI: scrubbed PEB 2347 (LEB 0:1610), data moved to PEB 2623
[ 1569.786000] brcmnand_ctrl_verify_ecc: Correctable ECC error at 00010000:26e56c00
[ 1569.789000] brcmnand_ctrl_verify_ecc: Correctable ECC error at 00010000:26e56c00
[ 1569.807000] brcmnand_ctrl_verify_ecc: Correctable ECC error at 00010000:26e56c00
[ 1570.055000] UBI: scrubbed PEB 2457 (LEB 0:647), data moved to PEB 2595


    [*]Irgendwas schreibt im Flash. Größere Updates sind besonders gefährlich, aber mitunter reicht auch schon das Rewrite von keymap, timers oder autotimers.
    [*]Beim nächsten Bootvorgang zerbröselt es dann fast immer was und die klassischen Fehler tauchen auf (bad node type (255 but expected 1/2/etc)). Dann folgen Fehler wie die von Dir geposteten.
    [/list=1]


    Ich hatte das erst gestern wieder und habe dann - weil es langsam nervt - wiederholt das gesamte / in place mit dem letzten tar (wo grad alles noch ging) überschrieben. Das Problem ist nun, dass dabei ständig weitere ECC scrubs stattfinden. Ich mach anschließend ein sync, drop_caches und check dann mit md5sum -c gegen ein Digestfile für das gerade ausgepackte tar. Meistens liefert das weitere ECC scrubs, manchmal sogar neue Lesefehler. Man sollte annehmen, dass das irgendwann mal aufhört, wenn alle altersschwachen Erase Blocks ausgemustert wurden, tut es aber leider nicht. Ich kann mich irgendwie nicht des Eindrucks erwehren, dass das ECC scrubbing manchmal daneben schießt und die falschen EBs trifft...


    Quote

    Nach allem was ich dazu finde hilft wohl nur ein Neuflashen.


    Speziell da habe ich meine Zweifel. Das Neuflashen der 7020HD vom 2nd aus ist ja leider nicht UBI-aware (zumindest war es das nicht, als ich zuletzt geguckt habe), d.h. es zerstört die komplette Nutzungsstatistik von UBI (Erase Counters). Man flasht also zunehmend in EBs, die hohe ECs hatten oder gar zuvor schon wegen correctable ECC errors ausgemustert wurden (nur die komplett kaputten Blöcke werden ausgespart). Wenn obige Theorie zutrifft, dann nimmt das Problem anschließend lawinenartig zu - und mein Verdacht ist, dass das bei mir grade anfängt...


    Quote

    Das habe ich zuvor dann auch gemacht, aber nach einiger Zeit kommt der Fehler zurück. Gibt es inzwischen irgendeine Möglichkeit, dass dieser Fehler dauerhaft verschwindet?!


    Ich spiele mit dem Gedanken, alles auf einen USB-Stick zu verlagern und nur noch von dem zu booten. Schöner wäre es natürlich, wenn die Kiste mit dem eingebauten Flash vernünftig funktionieren würde. Und komisch ist, dass wir ja mal ein reichliches Jahr Ruhe hatten - und in der Zeit kamen noch wesentlich mehr Updates als heute. Die Vermutung liegt nahe, dass der zu Grunde liegende Bug mal gefixt war, aber wieder da ist. Oder aber, dass er schon immer von ECC scrubs getriggert wurde und die mit dem zunehmenden Alter des Flashs jetzt immer häufiger werden...


    Fragt sich halt, ob das jemals wirklich gefixt war oder ob das "wir mounten UBIFS nicht mehr sync, weil es das Problem beseitigt" nur die Rate des Auftretens reduziert hat. Ein echter Fix war das allein ja eh nicht, denn man muss von einem Filesystem schon verlangen können, dass es auch bei sync mount korrekt funktioniert. Wenn der Bug im BCM Blob steckt, dann Gute Nacht...


    HTH & TIA,
    Andre.

  • Was passiert alle 30 Sekunden hier im Board?

    Quote

    Originally posted by Kaiser Wilhelm
    FF legt bei mir die temporären Sachen auf die hdd, da ich noch immer der Meinung bin, dass die ssd länger lebt, wenn ich ihr nicht jeden Schreibzyklus aufzwinge.


    Naja, an sich sind ordentliche SSDs wesentlich robuster, als bisweilen kolportiert wird. Die meisten Beschwerden kamen ja schon zu Zeiten der Intel Postville von Leuten, die zwar unbedingt eine SSD haben mussten, aber keine Intel bezahlen wollten - die damals schnell auftauchenden Trittbrettfahrer waren nun mal nicht ausgereift. Heute ist die Lage besser, es gibt genug Produkte die wirklich was taugen. HDDs kommen mir nicht mehr in die Nähe meiner Laptops und Workstations, außer über USB für Backup :winking_face:


    Das ist ja das Ätzende: Alles, was normalerweise auf meinem OS so abgeht, macht nur die Schreibzugriffe die wirklich nötig sind. Und ich hab sogar eine Swap-Partition auf der SSD, nur ist halt auch genug RAM drin damit die praktisch nie gebraucht wird. Und dann kommt so ein dämlicher Browser daher und meint, Größenordnungen mehr schreiben zu dürfen als alles, was ich so ernsthaft mit der Kiste anstelle. Dank hdplop (wmhdplop oder in GKrellM) fällt einem zum Glück auf, wenn was austickt, wobei ich das mit FF auch erst gemerkt habe, nachdem mir das S.M.A.R.T.-Monitoring von Total_LBAs_Written bei einer neuen SSD Suspekt wurde.


    Quote

    Aber alle 15sec eine Sicherung der Tabinhalte ist wirklich nicht notwendig, zumal die Sicherung ja nur nach einem Crash benutzt wird, oder?


    Yep, wenn man den Browser sauber beendet, dann schreibt er den Session Store eh noch mal raus. Ich bin ja im Prinzip ein großer Freund des regelmäßigen Sicherns - die Tabs sind mein Exobrain, ohne die sähe ich ziemlich alt aus. Bookmarks ersetzen das nicht, vor allem wegen des Kontexts (History hinter jedem Tab). Daher wäre mir eine zeitnahe, Crash-konsistente Sicherung dieser Daten durchaus wichtig. Nur ist die Ausführung halt mangelhaft. Wieso müssen bei einer Änderung an einem Tab alle anderen (95% davon in dieser Session nie geöffnet) mitgesaved werden? Doch nur, weil das alles in ein einziges File gepappt wurde (noch dazu ein 10MB großer JSON-Einzeiler, viel Spaß dabei da drin was flicken zu wollen). Und das File geht bei Systemcrashes auch gern mal kaputt, was natürlich nachvollziehbar ist bei der Größe und Änderungsrate. Ein File pro tabview-tab und die Welt sähe schon anders aus...


    HTH,
    Andre.

  • Was passiert alle 30 Sekunden hier im Board?

    Quote

    Originally posted by cepheus
    refesh des shoutbox?


    Genau das. Der Impact ist im FF verheerend, wenn dieser mit den Standardwerten für seine Zustandssicherung arbeitet. Ich hatte das mal analysiert, als mir spanisch erschien, wieso mein System stündlich Gigabytes auf die Platte schreibt. Konkret macht FF mit Standardeinstellungen aller 15s ein State Save. Aus irgendwelchen Gründen resultiert es in zwei State Saves direkt nacheinander, im Rhythmus von 30s (aber wenn man sieht, wie dieses Feature sonst so gecodet ist, wundert einen das auch nicht weiter). Ein State Save ist so groß wie sessionstore.js (zu finden im Profilordner), bei meinen bescheidenen 500 offenen Tabs sind das schon mal 10MB, also saved das Ding 20MB aller 30s (40MB pro Minute, macht 2400MB jede Stunde! Das sind 57GB am Tag - schöne Grüße an die SSD...). Nun tut er das immerhin nur, wenn er einen Anlass sieht, den State saven zu müssen - und eine offene Shoutbox auf der IHAD Hauptseite triggered das genau so wie andere Seiten mit Auto-Refresh.


    Ich empfehle dringend das Tuning von browser.sessionstore.interval in about:config. Achtung, das sind Millisekunden (man lasse sich das auf der Zunge zergehen - wollen die die Platte saturieren?). Bei mir steht das jetzt auf 300000 und damit gibt es State Saves nur noch aller 5min. Die Coder von dem Spaß können gern wiederkommen, wenn sie einen selektiven State Save beherrschen, bei dem man nur wegschreibt, was sich auch wirklich geändert hat. Glaub aber nicht dass da wer was fixt, wenn man liest wie gelegentliche Reporter dieses Problems von den Verantwortlichen oder ihren Fanbois zurechtgewiesen werden. Möchte nicht wissen, wie viele SSDs die schon mit auf dem Gewissen haben...


    HTH,
    Andre.

  • Overscan...und das "Stricheproblem"!

    Quote

    Originally posted by Pocky
    Das ist die Austastlücke wo auch z.B. der Videotext mit übertragen wird.


    Wobei das, was man hier konkret sieht, die WSS (Wide Screen Signaling)-Zeile 22 ist, bei der man sich streiten kann, ob das noch Austastlücke oder schon aktives Bild ist. Den Teletext sieht man eigentlich nur bei starker Fehlstellung des Syncs, die WSS (eingeführt mit PALplus, danach essenziell für den Umstieg auf "anamorphes" 16:9) gerät hingegen sehr leicht ins Blickfeld, weil sie erst im Overscan verschwindet. Das Pendant dazu unten ist VHS-Schmutz, der auch besser gnädig im Overscan geblieben wäre :winking_face:


    HTH,
    Andre.

  • Geminibackup

    Quote

    Originally posted by cklahn
    Vielleicht habt Ihr noch eine Idee?


    Das NAS ist mit NFS gemounted und schreibt auf ein POSIX-konformes Filesystem? Das riecht nämlich so, als wären da Symlinks schlicht nicht supported. Es gibt auch noch ein paar mehr Probleme mit dem NFS-Export von Symlinks, weswegen da vielleicht sogar Sicherheitsmechanismen greifen (die etwa absolute Symlinks und solche relativen, die aus dem NFS-Mount heraus zeigen würden, schlicht verhindern, weil die potenziell auf dem Server oder anderen Clients Unheil anrichten könnten) - das wissen dann die Spezialisten für das jeweilige NAS.


    Was ich mich fragen würde, wenn ich eine OE2.2-Kiste hätte - wieso muss da doppelt und dreifach kopiert werden? Kriegt man das nicht (mit passenden Excludes und zur Not mit ein paar bind-Mounts) so hin, dass es in einem Stream liest, tared und komprimiert, womit am Ziel genau der Platz gebraucht wird, der für das Resultat nötig ist (und kein Feature jenseits von "man kann da ein File zum Schreiben öffnen und vollmachen")?


    HTH,
    Andre.

  • dreamDroid - Open-Source Enigma2 Client für Android

    Quote

    Originally posted by albatos
    Wlan müsste stark genug sein. Habe volle signalstärke angezeigt. Das wlan geht über einen netgear router, an den auch die dm800s per lan angeschlossen ist. Was für ptobleme könnten da vorliegen?


    Das Problem hieß bei mir 2.4GHz. Im ISM-Band ist in urbaner Umgebung nichts mehr zu reißen, die Interferenzen machen es für Streaming unbrauchbar. Der Stream wurde magisch stabil (720p, über Stunden, auf Galaxy S4 mini) nachdem ich das 2.4GHz-Radio im AP ausgeschaltet hatte. Da Android ja der letzte Dreck beim WLAN Roaming ist, muss man den Holzhammer nehmen - auf die Idee 5GHz zu nutzen kommt es in den seltensten Fällen von alleine.


    Jetzt heißt es nur Daumen drücken, dass 5GHz nicht demnächst genau so zugeschissen ist wie das 2.4GHz ISM heute. Wobei die meisten SOHO-Kisten nur im U-NII-1 und evtl. U-NII-2 senden. Das nächste große Ding wird sicherlich, auf U-NII-2 extended auszuweichen (Kanäle 100-140), weil es dort noch halbwegs ruhig ist...


    HTH,
    Andre.

  • [gelöst] WebIF

    Quote

    Originally posted by speedy73
    Gibt es den eine Möglichkeit die Senderliste in den VLC-Player zu bekommen?


    Genau so wie Bschaar zwei Postings weiter oben schrieb. Das Bouquet als Playlist (.m3u) downloaden, im VLC öffnen (oder VLC mit dem m3u als Parameter aufrufen), View/Playlist wählen und schon kann man flott (im Rahmen der zu erwartenden Umschaltgeschwindigkeit des Stream Proxy) rumzappen.


    HTH,
    Andre.

  • DM7020 HD - Geringe Datenübertragungsrate

    Quote

    Originally posted by Bundy00
    Nun habe ich aktuell gerade mal ~ 2- 2,5 MB/s (egal in welche Richtung) und habe keine Ahnung woran das liegen könnte.


    Neben der bereits geäußerten Primärvermutung (eine neu hinzugekommene Interferenzquelle) wäre noch zu sagen, dass 802.11n gern bei solchen Datenraten sättigt, wenn die eingebauten Mechanismen für Frame Aggregation abgeschaltet sind. Das wiederum wird manchmal getan, um die Stabilität des Empfangs am Rand der Zelle zu verbessern. Vielleicht schlägt ja ein Automatismus zu, der das für Dich entschieden hat, oder Du hast eine Einstellmöglichkeit a la "Reichweite vs. Durchsatz". Ich kenn die verwendeten Geräte nicht, aber man kann ja mal in dieser Richtung forschen.


    HTH,
    Andre.

  • Hilfe -> /usr/share/enigma2/keymap xml defekt

    Quote

    Originally posted by m0rphU
    Im Übrigen würde ich mich immer fragen, warum die Datei kaputt ist. Vllt. ist ja bei dem Stromausfall noch größerer Schaden im Dateisystem eingetreten.


    IMO ist keymap.xml ein Canary für unsauberes Runterfahren, was ja bei einem Stromausfall notgedrungen eintritt. Oder wenn die Kiste so hängt, dass einem außer Power Off nix mehr bleibt. Hatte das selbst schon. Hintergrund ist anscheinend, dass keymap.xml bei jedem Booten von irgendwas (hab nicht näher geguckt, wahrscheinlich eine der QuickButton-Inkarnationen) angefasst, modifiziert und neu geschrieben wird. Und wenn das mal nicht mehr sauber gesynced werden kann, isses kaputt - und E2 fliegt dann auch beim nächsten Booten auf die Fresse. Ansonsten schreibt man ja eher wenig im Flash rum, nur bei Updates und vielleicht noch die epg.dat, deren Verlust aber nicht so fatal ist. Es ist also sehr wahrscheinlich, dass es bei sowas nur und ausschließlich die keymap.xml zerlegt hat, aber Ausnahmen bestätigen die Regel.


    BTW, ich hab eine Kopie von keymap.xml auf'm /media/usb liegen, weil enigma2 reinstall sich immer etwas zieht. Ist so mit das größte Paket was auf der Box rumfliegt. Also beim opkg install nicht die Luft anhalten :winking_face:


    HTH,
    Andre.

  • Hilfe -> /usr/share/enigma2/keymap xml defekt

    Quote

    Originally posted by gero11
    Bleiben die Pugins (GP3.2, Mediaportal, CCCam, usw) vom "force reinstall" unberührt, oder müssen die Plugins danach neu installiert werden?


    Der angegebene Befehl ist das minimalinvasive Verfahren, wieder zu einem laufenden E2 zu kommen. Es geht nichts verloren, außer evtl. Patches an E2 oder an der keymap.xml selbst. Da das auch bei jedem einzelnen Update des Pakets enigma2 passiert, kannst Du sicher sein, dass nicht mehr kaputt geht als bei eben einem solchen Update - in der Regel also gar nichts. Kein Vergleich zu neu flashen. Das force reinstall klingt vielleicht brutal, ist hier aber auch nur nötig, um opkg überhaupt zur Arbeit zu verleiten - es würde eigentlich keinen Grund sehen, das Paket in der selben Version noch mal zu installieren, die ist ja schon aktuell und braucht kein Update. Was opkg nicht wissen kann, ist dass da drin ein File kaputt ist und Du bewusst diesen Befehl nutzt, um es zu reparieren.


    Da sich E2 bei Dir u.U. in einer Dauer-Restart-Schleife befindet, garnierst Du das opkg vielleicht noch mit einem vorherigen init 4 und einem abschließenden init 3 rein zur Vorsicht.


    HTH,
    Andre.

  • Hohe Absätze für Set-Top-Boxen mit UHD und HEVC erwartet

    Quote

    Originally posted by Paulchen P.
    Zu Full HD Spezifikation gehört auch 1080i und nein; kein Sender sendet in 1080p, weil das nicht zur jetzigen DVB-S2 Spezifikation gehört.


    So wie ich das gehört habe, ist der Hauptgrund, warum man bei diversen Broadcastern auf (mehr Endgeräte mit) HEVC wartet, dass man damit endlich 1080p50/60 auch auf den Sender bekommen kann - und das wird als wesentlich wichtiger empfunden als 4k. Niemand will schon wieder alle Studios, Produktionswege etc erneuern, aber es wär schon schön, wenn man erstmal das inzwischen üblicherweise bei der Produktion anfallende HD-Material auch in der Quellqualität versenden könnte. Weder das Runterskalieren auf 720p50/60 und schon gar nicht der Eierschneider auf 1080i50/60 sind wirklich adäquate Verfahren zum Umgang mit Full-HD-Material. Ausnahmen bestätigen die Regel. Aber man ist ja letztlich froh über jeden Sender, der in sowas wie HD und ohne angeflanschte Schutzgelderpressung zu einem durchdringt...


    An"KD hat immer noch nicht ausgebaut"dre.

  • Filme von der Box zum NAS überspielen

    Quote

    Originally posted by Schnello

    Code
    root@dm7020hd:/media/net# rsync -aPn 192.168.1.1:/dreamboxlog/ /media/hdd/test/
root@192.168.1.1's password:


    Wobei genau das kein Daemon-Zugriff war sondern SSH, was man schon daran sieht, dass er nach einem Passwort fragt. Um den Daemon anzusprechen verwendet man zwei Doppelpunkte (oben wäre das also 192.168.1.1::/dreamboxlog/ gewesen) oder schreibt stattdessen einen rsync:// URL.


    HTH,
    Andre.

  • Gelöst ;Festplatte:Zweimal getauscht in 9 Monaten ?

    Quote

    Originally posted by ddinc
    Habe bemerkt,daß die Aufnahmen immer in der 59.Min. stoppen und RO mount.


    Das klingt ja nun ganz schwer nach irgendeiner verbuggten Powersave-Funktion oder sowas seitens der externen Box. Wann würgt es ihn ab, wenn Du die Platte fünf Minuten vor Beginn einer Aufnahme pingst, so dass sie etwas eher anläuft? Dein Idle ist 600s, die sollte dann also bis zum Beginn der Aufnahme duchlaufen und in der 54. oder 55. Minute wegfliegen, wenn die Theorie stimmt. Hänge bitte auch den Output von dmesg an, kurz nachdem das wieder passiert ist - der e2 debug log hilft hier weniger.


    HTH,
    Andre.

  • Nach misslungenem Aufspielen eines vorher gesicherten *.nfi fährt Festplatte ständig hoch/runter

    Quote

    Originally posted by drharry
    [...] bin nicht davon ausgegangen, das durch Flashen auch mit einem evtl defekten Image ne Platte gehimmelt wird.....


    Wird sie auch nicht. Aber so ein Upgrade ist (je nachdem, wie man die Box sonst betreibt) u.U. der erste Power Cycle seit Wochen, wenn nicht Monaten (ich hab hier eine DM800 mit 931 Tagen Uptime, die hat halt keinen FP). Und wenn HDDs mechanisch kaputtgehen, dann meistens bei einem Power Cycle...


    Du kannst noch die Rettungswerkzeuge bereit legen und den Kühlschrank probieren, aber ich würde mir wenig Hoffnungen machen. Aktuelle Platten sind mechanisch so hochgezüchtet, dass sie bei solchen Symptomen normalerweise ein Fall für den Elektroschrott sind - oder für Kroll Ontrack und Konsorten, die u.U. Spindeln in Platter zerlegen, neu zusammensetzen[1] und in neue Gehäuse mit anderer Elektronik verfrachten können. Im Reinraum. Für gesalzen viel Geld. Kommt ganz auf den Wert der Daten an...


    [1] Wobei ich meine, die Jahre irgendwo gelesen zu haben, dass es damit inzwischen auch vorbei ist. Kriegt man nie wieder so exakt justiert, dass es was nützt. Aber ich kann mich da irren.


    HTH,
    Andre.

  • Dateien von Dreambox zu Dreambox kopieren

    Quote

    Originally posted by white_raffaelo
    möchte jetzt meine Aufnahmen von der 8000 HD auf die 7080 HD übertragen.
    Arbeite mit TotalCommander ( ftp ).
    Wenn ich die Datein kopieren möchte ( also von 8000 HD auf 7080 HD ), bekomme ich leider die Fehlermeldung:
    Übertragung fehlgeschlagen - entfernte Übertragung wird vom Server wahrscheinlich nicht unterstützt.
    Der Umweg über den PC geht, leider nicht von DM auf DM !?


    Das ist wohl ein Bug/Misfeature/Entwickler-Ignoranz in vsftpd, ich hatte das hier mal auseinandergenommen. So lange das niemand fixt (oder sich mal anguckt, ob man das beim Build konfigurieren kann und dann OE2.x entsprechend anpasst) wird das mit Proxy-FTP nicht gehen.


    Quote

    Hat jemand hier einen guten Rat für mich, wie ich am besten direkt übertrage/verschiebe ?


    Ich empfehle da rsync, wobei man tunlichst nicht durch SSH tunneln will. Bei solchen Kopieraktionen geht es ja um Terabytes, eine der beteiligten Kisten hat nur 100Base-TX, da ist alles was bremsen kann unerwünscht und es wird sowieso schon Tage dauern. Insofern ist rsync doppelt clever, weil es mehrfach wieder aufsetzen kann.


    Um SSH zu umgehen, startet man auf der Empfängerseite den rsync-Daemon und spricht den von der Senderseite aus direkt an. Bei mir hat sich da folgendes in /etc/rsyncd.conf bewährt:


    Wenn einem das mit dem Daemon zu kompliziert wird, kann man auch einen NFS-Mount zwischen den Kisten etablieren und rsync dann "lokal" kopieren lassen, ist aber ineffizienter.


    Ansonsten wäre auch wget nutzbar, um auf der Zielbox die Files von der Quellbox zu ziehen. Musst Du rumprobieren, ob das wieder mal an BusyBox-Lobotomie scheitert oder ob das wget auf der Box alles kann was gebraucht wird. Ich persönlich bevorzuge rsync gegen den Daemon, da weiß man was man hat.


    HTH,
    Andre.

  • Synology

    Quote

    Originally posted by cs_e
    Das mit den WD Red stimmt...die sollen durchlaufen.


    Wieso behauptet das hier neuerdings jeder? Forenspezifisches Mem? Liest kein Mensch mehr Datenblätter? Als ich zuletzt nachgesehen habe, hatte die WD Red doppelt so viele Parkzyklen spezifiziert wie vergleichbare Green, genau weil sie in jedem typischen SOHO-NAS bei Nichtbenutzung in den Standby geschickt werden. Jetzt könnte man argumentieren, dass Power Off nicht das selbe ist wie Standby, aber bevor ich das glaube hätte ich gern eine externe Quelle mit einem zumindest minimalen Vertrauensbonus oberhalb von Schwafelclub. Das einzig Beunruhigende was ich kenne ist die Ausfallrate von WD Red 3TB bei einem Billig-Cloud-Storage-Provider, die hier letztens referenziert wurde - aber dort laufen die 24/7 ohne Standby, kann also kaum als Auslöser für dieses Gerücht dienen. Wo kommt das her?


    HTH,
    Andre.

  • Image für OE 2.2 bauen - (nicht dm7080)

    Moin,


    momentan baut grad gar nix, weil apt_1.0.9.tar.xz von sämtlichen Mirrors verschwunden zu sein scheint. Da liegt nur 1.0.9.1. Wer's noch in sources liegen hat schätze sich glücklich :winking_face:


    Anyway, bevor das nicht zuverlässig läuft würde ich's eh nicht flashen...


    Andre.