Posts by Fred Bogus Trumper

    Die alten Loader funktionieren nicht mehr mit den aktuellen Browsers.


    Entweder den aktuellen socond stage loader od seriell flashen und dann das Image hinterher über den Browser oder eine alte Firefox Portable Version verwenden, damit sollte das Flashen klappen


    ch würde die version 3.5.x nehmen

    findest du auf sourceforge.net


    Wenn ein aktuelles Image geflasht wird, wird auch der loader auf den letzten Stand gebracht

    Nachtrag:


    du kannst sonst auch die Inhalte von /media/hdd/movie und /media/hdd/movie: vergleichen.
    Der verbrauchte Speicherplatz in bytes und die Anzahl der Ordner, Dateien und Symbolischen Links müsste ident sein und die Dateien/Aufnahmen von der vermeintlichen Quelle dürften gar nicht vorhanden sein


    Code
    for directory in /media/hdd/movie /media/hdd/movie:;do echo used space in bytes of $directory:;du -sb $directory;echo directories, files and symbolic links in $directory;for filetype in d f l;do find $directory -type $filetype|wc -l;done;done


    Hier sieht das dann so aus - ich vergleiche aber den internen u. externen movie Ordner (es sind keine Aufnahmen auf der externen Platte) - bei dir müssten die Zahlen ident sein, wenn du /media/hdd/movie und /media/hdd/movie: vergleichst - die bytes könnte etwas abweichen

    mit


    rsync -av /dev/sdb /media/hdd/movie/ /dev/sda /media/hdd/movie:


    kopierte ich den Inhalt (0.3 TB) des angegebenen Pfades auf die neue Disk, welche bereits 0.4 TB Daten der DM920 enthielt.


    dem widerspreche ich :winking_face:


    du hast den Ordner movie auf der 3TB Platte (/dev/sda) und die beide Gerätedateien /dev/sda und /dev/sdb in den Ordner movie: auf die 3TB Platte kopiert.

    rsync kann mit mehreren sourcen umgehen, der letzte Pfad ist immer das target

    rsync <option> <source> <source> <source> <target>


    im Grunde hast du also die beiden Dateien /dev/sda, /dev/sdb und den Ordner /media/hdd/moive ins Ziel /media/hdd/movie: kopiert - also den Order movie unter einem anderen Namen auf die selbe Platte kopiert und dort noch sda und sdb reingepackt (0byte Dateien)


    Der Inhalt von /media/movie und /media/hdd/movie: müsste also ident sein - bis auf die zwei leeren Dateien sda und sdb



    Zum Verständnis:
    /dev/sda und /dev/sdb sind die Gerätenamen der Festplatten in der Reihenfolge wie sie vom Kernel erkannt wurden. Der Name wird vom Kernel vergeben. Auf /dev/sda oder /dev/sdb befinden sich keine Daten, ausser du hast keine Partitionen erstellt und das raw device formatiert


    /dev/sda1 /dev/sdb1 sind die ersten Partitionen auf den Platten, auf den Partionen wird das Dateisystem (in dem Fall ext4) erstellt. Auf diese Partition werden die Daten geschrieben - aber erst nachdem zu sie gemountet hast!


    Nach deinen df Ausgaben im vorigen Post war /dev/sdb1 nie gemountet, was aber in diesem Fall egal ist, weil du /media/hdd/movie nach /media/hdd/movie: kopiert hast - ergo hast du nicht von b nach a kopiert sonder von a nach a



    Du hättest die Platte von der du kopieren möchtest, zuerst mounten - und dann kopieren müssen



    /dev/sda und /dev/sdb haben in deinem rsync command nichts verloren, da wurden nur die Gerätedateien angesprochen und nicht wie von dir vermutlich gewünscht das Gerät selbst.




    Wie wäre es richtig gewesen?


    Annahme:
    /dev/sda ist interne 3TB Platte die nach /media/hdd gemountet ist

    /dev/sdb ist die externe über USB angeschlossene Platte - und du möchtest Daten von b (extern) nach a (intern) kopieren:


    1. mit df -h oder mount prüfen ob die interne Platte gemountet wurde. Wir nehmen mal an, /dev/sda1 ist ist die interne Platte und nach /media/hdd gemountet. Kann man prüfen mit df oder mount

    Code
    root@dm900:~# df -h /dev/sda1
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/sda1       1,8T  1,5T  351G  81% /media/hdd
    root@dm900:~# mount|grep /dev/sda1
    /dev/sda1 on /media/hdd type ext4 (rw,relatime,data=ordered)
    root@dm900:~#


    2. Die Platte von der die Daten von extern nach intern (/dev/sda) kopiert werden wird an die Box gestöpselt und die erhält dann überlicherweise den Gerätenamen /dev/sdb, sofern keine weiteren USB-Platten oder USB-Stick bereits angeschlossen waren.


    Damit man rausfindet, welcher Gerätename welches Device ist hat man mehrere Möglichkeiten, z.B.

    Code
    root@dm900:~# ls /dev/sd?
    /dev/sda  /dev/sdb
    root@dm900:~#

    Hier sind nur zwei Blockgeräte vorhanden (Festplatten, USB-Sticks etc. über SATA oder USB angeschlossen)


    Einfach prüfen, welche Partionen auf /dev/sdb erstellt wurden

    Code
    root@dm900:~# ls /dev/sdb*
    /dev/sdb  /dev/sdb1
    root@dm900:~#


    /dev/sdb1 ist die erste und einzige Partiton, jetzt könnte man noch nachsehen welches Filesystem auf /dev/sdb1 erstellt wurde

    Code
    root@dm900:~# blkid /dev/sdb1
    /dev/sdb1: LABEL="STORAGE" UUID="4b4549f3-e242-4c2d-a48c-82851c7c2fa4" TYPE="ext4" PARTLABEL="storage" PARTUUID="027667df-e94b-4a23-a79e-31b8a0454a15"
    root@dm900:~#


    TYPE="ext4" - d.h. diese Partionen kann ohne weiteres gemountet werden, dazu erstellt man einen Ordner in /tmp/ oder /media oder nimmt einen bestehenden - es sollte nichts in diesem Ordner gemountet sein



    Ich nehme mal /tmp zum einfacheren Verständnis. Nach dem das eine externe Platte ist, nenne ich ihn hdd-ext und mounte dann die erste und einzige Partition der externen Platte nach /tmp/hdd-ext


    Code
    root@dm900:~# mkdir /tmp/hdd-ext
    root@dm900:~# mount /dev/sdb1 /tmp/hdd-ext/



    das sieht dann so aus:

    Code
    root@dm900:~# df -h /dev/sd?1
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/sda1       1,8T  1,5T  351G  81% /media/hdd
    /dev/sdb1       1,8T  658G  1,2T  37% /tmp/hdd-ext
    root@dm900:~#


    die interne 2TB Platte is nach /media/hdd gemoutet, die externe 2TB Platte nach /tmp/hdd-ext



    Der Inhalt von /tmp/hdd-ext sieht folgendermaßen aus:

    Code
    root@dm900:~# ls /tmp/hdd-ext/
    lost+found  movie  pve-backup
    root@dm900:~#



    Wenn man den Inhalt nach movie der externen Platte noch movie der internen Platte kopieren möchte hat man mehrere Möglichkeiten. Will man rsync verwenden und wie in deinem Fall Dateien überspringen die im Zielordner neuer sind als am Quellordner


    rsync -au /tmp/hdd-ext/movie/ /media/hdd/movie

    Achtung beim Setzen des letzen slash beim Quellverzeichnis: Die beiden Befehle


    rsync -au /tmp/hdd-ext/movie/ /media/hdd/movie vs. rsync -au /tmp/hdd-ext/movie /media/hdd/movie


    liefern unterschiedliche Ergebnisse!
    siehe z.B.: https://wiki.ubuntuusers.de/rsync/


    Wenn der Kopiervorgang abgeschlossen ist, /tmp/hdd-ext wieder aushängen oder die Box rebooten.


    umount /tmp/hdd-ext

    Wurde auch ein apt-get update vor dem install Befehl ausgeführt?


    apt-get update && apt-get install rsync



    Dann sieht man auch auch gleich, wenn Fehler beim Aktualisieren der Paketlisten auftreten. Wenn das auch nicht klappt, versuch vorab ein


    dpkg --configure -a



    sonst die Fehlermeldung posten

    Das funktioniert aber nur mehr mit deaktivierten Sicherheitsmaßnahmen im WebInterface (Tokenbasierente Sicherheitsmaßnahmen, anti-hijack). Wenn die aktiv sind, muss vorab die Session ID abgefragt werden und dann mit dem Behel als POST command mitgeben


    das funktioniert ganu gut mit curl


    @Fred Bogus Trumper: Dateisystemüberprüfung lässt sich nicht durchführen, Box hängt sich auf..


    Gibt es eine Fehlermeldung? Enigma2 ist da leider nicht sehr gesprächig

    Gibt es eine SWAP Partition auf der Patte? Die wird überlicherweise von Enigma2 vor der Dateisystemüberprüfung aktiviert. Wenn die zu überprüfende Partition mehr als 500GB hat, schmiert die Box mangels RAM ohne aktiven SWAP gerne ab ..


    sonst manuell prüfen


    alle ssh, telnet, ftp Verbindungen die auf die Platte zugreifen trennen

    wenn samba und nfs server laufen und /media/hdd freigegeben ist die beiden Server beenden

    Dateisystem manuell prüfen


    Annahme: die interne Platte hat den Gerätenamen /dev/sda, die erste Partioin mit dem ext3 Dateisystem und den Aufnahmen sollte /dev/sda1 sein

    sonst den Befehl entsprechend ändern. Erstmal die Partition aushängen


    umount /dev/sda1



    Wenn es hier einen Fehler gibt, greift noch ein Dienst auf die Platte zu, der das Aushängen verhindert - das könnte u.U. auch der Grund für den Fehler bei der Dateisystemüberprüfung im Gerätemanager gewesen sein.

    Swap starten - vorausgesetzt es gibt ein Swap Partition, sonst eine Swap Partition oder ein mind. 512MB Swapfile auf USB erstellen und aktiveren


    swapon /dev/sda2



    Wenn es geklappt hat, die Prüfung manuell starten.


    fsck.ext3 -v -p -f /dev/sda1


    Wenn es Fehler gibt, die Aussgabe hier posten


    Wenn du dann schon dabei bist, wären die S.M.A.R.T. Informationen der Platte auch hilfreich, eventuell muss das Paket smartmontools nachinstalliert werden. Eventuell ist ja auch die Platte am sterben ...


    smartctl -a /dev/sda

    im Gerätemanager die Platte auswählen -> Dateisystemüberprüfung


    Ich würde das aber im Terminal machen und auch mal die S.M.A.R.T. Werte der Platte mit smartctl auslesen - sofern smartmontools online (noch) online installierbar ist.


    die Meldung "Festplatte voll" deutet eher auf einen Dateisystemfehler oder Festplattendefekt hin. Im Grunde hatte man im OE2.0 alle Werkzeuge für eine "Untersuchung" auf der Box bzw. am Feed zu Verfügung. Im OE1.6 bin ich mir nicht so sicher. Ich weiß auch nicht, ob man im OoZoon Image noch etwas online installieren kann. Falls nicht, backup vom flash Image erstellen und ein OE2.0 Image installieren - dann sollte man alle Werkzeuge zur Verfügung haben.


    Falls aus irgendeinem Grund nicht geht, ich die Platte ausbauen und mit einem Linux System rangehen (Live CD etc.)

    Unter Windows hat man da mit (vermutlich) ext3 weniger Möglichkeiten - vor allem um die Daten zu retten.

    Ein Image mit aktiven online feed würde der Box jedenfalls nicht schaden.

    und weil ich schon mal dabei bin, habe ich auch mein qnap nas/1 Gb home network getestet mit der one ueber kabel connected:

    Code
    root@DMOne:/media/qsw# dd if=/dev/zero of=/media/qsw/writetest bs=1M count=1000
    1000+0 records in
    1000+0 records out
    1048576000 bytes (1000.0MB) copied, 99.578788 seconds, 10.0MB/s

    das is nix. geht wohl nichts ueber eine interne disk.



    das kann man nicht vergleichen

    direkter I/O am device und über ein Netzwerkprotokoll geschrieben sind völlig andere Dinge. Der direkte I/0 am QNAP ist hundertproztentich mind. 10x schneller

    In deinem Fall ist der Flashenhals entweder die Netzerkkonfiguration oder das verwendete Protokoll (NFS oder SMB?)

    10MB/s deutet für mich hin, dass über die Netzwerkschnittstelle nur 100Mbit drüberlaufen. Da musst du also wo anders suchen


    Vielleicht mal mit ethool die konfiguration des NIC der Two überprüfen. Es sollte auch bekannt sein, dass z.B. die Fritz! im Green Mode gerne auf 100Mbit/s drosselt. Ein defektes Kabel, Switch kann man auch nicht ausschließen


    Das ist nicht Äpfeln mit Birnen vergleichen sondern Äpfel mit Zuchinni ...

    das glaube ich nicht


    Ich habe mal 6 oder 7 Aufnahmen gleichzeitig mit der DM800SE v1! auf die interne HDD gemacht. Mangels FBC und Tuner Steckplätzen von Sendern die am selben Transpondern liegen, Das war überhaupt kein Problem

    Auf der SE v1 hatte ich etwa 50-65MB/s permanante Schreibraten auf die interne HDD mit dd

    Wenn die SSD in einem guten Gehäuse mit entsprechendem Controller per USB3.0 an die One/Two angeschlossen ist, sollten diese Schreibraten locker erreicht bzw. übertroffen werden.


    Für Timeshift oder 1-2 Aufnahmen scheint eine SD zu reichen, für mehr wohl nicht. Ich denke, dass da auch der verbaute Cardreader einen Strich durch die Rechnung macht - und nicht die SD Card.

    Eine SATA III SSD an einem SATA II Controller schaft auch nur Schreibraten von ca. 250MB/s am PC, obwohl die SDD 560MB/s hergeben würde bzw. diese auch an einem SATA III Anschluss erreicht, wenn die restliche Hardware entspricht.

    Das sollte eigentlich klar sein. Ist zwar beides ein Flashspeicher, aber dennoch unterschiedliche Technologie.

    Ich vermute, das beim Schreiben auf USB und SD Flashspeicher in den RAM zwischengepuffert wird und dann der Datenräger nicht mit dem syncen nachkommt.

    Wenn man z.b. nur 50 oder 100MB auf die SD schreibt sind die Datenraten höher. Das sieht man auch, wie die Datenraten runtergehen wenn man mit der Option status=progess schreibt

    Vielleicht sind auch nur die Messwerte bei geringeren Datenmengen ungenauer


    mit hdparm kann man auch einen benchmark starten, ein vollwertiges hdparm binary liegt am feed


    SD vs. SATA

    der 1. Befehl misst die direkten Leseraten, der 2. die Leseraten mit cache


    Man sieht auch das lt. hdparm test SD und HDD beim cached read fast gleich schnell sind aber beim direkten Lesen die HDD 6x schneller ist

    Ich glaube aber nicht, dass das Problem mit dem von SMR Platten vergleichbar ist. Die Schreibrate bricht ja deshalb ein, weil ab einem Füllstand von ca. 50% Daten auf die überlappenden Spuren doppelt geschrieben werden werden müssen (bestehende Daten lesen, alte + neue Daten neu schreiben)

    ich vermute bei Aufnahmen auf der SD eher, dass hin und wieder hohe bitraten gleichzeitig auf allen drei Sender reinkommen und die SD damit dann kurzfristig überfordert ist. Wie gesagt, die Schreibraten bei einer Aufnahme sind ja nicht konstant.

    Treten die Ruckler auch bei 3 Aufnahmen auf - also ohne Timeshift?

    Interessant


    eigentlich müssten auf der dm920 mit der SanDisk 512 GB Extreme PRO eher zwei Aufnahmen machbar sein als auf der Two. Jedenfalls scheint die schnellere SD in der dm920 verbaut zu sein.


    Um Äpfel mit Äpfeln zu vergleichen müssten die gleichen Transponder aufgezeichnet werden.

    Vielleicht wurde der Test ja mit dm920 mit 2 UHD Aufnahmen gemacht und auf der Two mit zwei HD Sendern.
    Es macht auch einen Unterschied ob z.B. ORF HD oder Servus TV HD mit hohen Datenraten aufgenommen wurden oder Transponder mit geringeren Datenraten. Zudem schwanken ja die bitraten der Transponder somit auch die Schreibraten, während dd die nullen mit max. Schreibraten auf die SD knallt.



    Zum Vergleich eine ca. 4 Jahre alte SanDisk Ultra R80 microSDHC 16GB, UHS-I, Class 10, max. 80MB/s in der dm900
    wobei ich glaube, dass sich R80 auf bis zu 80MB/s Lesen und nicht Schreiben bezieht. Die effektiven maximalen Schreibraten sind meist um einiges geringer

    Aufnahmen schreibe ich allerdings nicht auf die SD


    Code
    root@dm900:~# dd if=/dev/zero of=/media/sd/writetest bs=1M count=1000 status=progress
    1041235968 bytes (1,0 GB, 993 MiB) copied, 78,0639 s, 13,3 MB/s
    1000+0 records in
    1000+0 records out
    1048576000 bytes (1,0 GB, 1000 MiB) copied, 78,6712 s, 13,3 MB/s
    root@dm900:~# 

    D.h. dann müsste die "langsamere" SD in der Two höhere Schreibraten erreichen. Das könnte auch am verbauten Card Reader liegen.


    Ein einfacher Schreibtest würde da helfen um herauszufinden wie sich die Boxen unterscheiden.

    Schreibt ein 1GB Testfile gefüllt mit Nullen ("/mountpointSD" durch den korrekten mountpoint ersetzen, z.B. /media/sd etc.)


    dd if=/dev/zero of=/mountpointSD/writetest bs=1M count=1000



    wenn man noch status=progress anhängt, kann man die performance "mitlesen"


    dd if=/dev/zero of=/mountpointSD/writetest bs=1M count=1000 status=progress

    Was hat das mit Support von BA zu tun?

    Ein USB-Stick oder SD Card kann aus allen möglichen Gründen plötzlich schreibgeschützt sein. Das passierte mir auch schon zwei mal - ohne BA.

    Wenn der TE nur schreibt, dass die SD write prodtcted ist - ohne Angabe wann/wie das passiert, kümmert sich niemand darum ob das BA Support ist oder nicht.

    Und wenn er die SD einfach nur gerne weiterverwenden möcht, ohne BA darauf zu installieren. Ist das deine Meinung nach dann auch BA Support?
    In diesem Threat ging es NUR darum, den Schreibschutz einer SD zu entfernen - um nichts anderes!


    Ich gehöre vermutlich zu den letzten, der BA hier oder sonst wo supporten würde. Und ich glaube, dass ist kein Geheimnis ...

    Wenn du nichts fachliches Beitragen kannst, troll doch bitte wo anders rum.

    Check first if your SD card is physically locked by tape or slider. You can use the command prompt and diskpart on Windows or on linux (dreambox) hdparm to unlock your SD card. Since there is no information about your used Dreambox may be no full hparm binary is installed or available and the busybox hdparm does not support unlock write protection.

    In DreamOS hdparm can be installed online:


    apt-get update && apt-get install hdparm



    To find out the correct device name of your SD Card use blkid or lsblk, for example on a DM900UHD:



    be aware! /dev/mmcblk0 is the internal emmc flash - do not touch!


    /dev/mmcblk1 should be the SD Card and should be unmounted. To unlock the write prodection try


    hdparm -r0 /dev/mmcblk1



    And sometimes google is your friend. I found at least 5 different ways to unlock a SD Card on different devices within one minute :winking_face:


    How To Remove Write Protection From an SD Card

    3 Ways to Remove Write Protecion on a SD Card