Posts by wfaust

    Ich habe bei meinen remote Clients Lifeguard für ssh ausgeschaltet, da es ab und zu vorkam, daß eine Verbindung nicht korrekt beendet wurde und es dann ewig dauerte, bis das System das mitbekam. Wird denn (wie von lifeguard getestet) mit

    Code
    1. ss -t -o state established | tail -n +2 | awk '{print $3}' | grep ":ssh\b"

    eine ssh Verbindung angezeigt?


    Nebenbei (ich weiß, es ist nicht die einfache und schnelle Hilfe die Du erwartest, dennoch, vielleicht nicht uninteressant für den einen oder anderen Leser):


    Du kannst es auch so wie ich machen und eher darauf schauen, ob wirklich Daten über den SSH Port laufen. Ich nutze dazu folgende iptables Befehle beim Booten (iptables-persistent Paket installieren):


    Code
    1. iptables -N TRAFFICIN
    2. iptables -I INPUT -j TRAFFICIN
    3. iptables -A TRAFFICIN -p tcp --dport 22 -j ACCEPT
    4. iptables -A TRAFFICIN -p tcp --sport 22 -j ACCEPT


    Dann lasse ich per cron alle 2 Minuten folgendes Script unten laufen. Sollte ausreichend Traffic gefunden werden, verhindert das Script per Lifeguard das Ausschalten für DELAYOFFSECS Sekunden. So schaltet das System auch nicht aus, wenn mal kurz eine Störung der SSH Verbindung z.B. der wegen einer Zwangstrennung da ist. Du kannst die 3000000 Bytes Traffic Abfrage im Script leicht an Deine Bedürfnisse anpassen und so z.B. zwischen SFTP Datentransfers mit viel Traffic und interaktive Nutzung mit wenig Traffic unterscheiden. Oder Du kannst bei extrem wenig Traffic eine aktive aber ungenutzte SSH Verbindung annehmen und dann doch das Ausschalten erlauben....



    Wobei Du per template dann in /etc/vdr/lifeguard.conf folgende Option hinzufügst:

    Code
    1. file /tmp/.delayoff Warte\ noch\ etwas mit\ Shutdown\ nach\ SSH\ Zugriff.

    Von Haus aus benutzt yaVDR 0.61 scheinbar kein Pinning? Ich hatte noch yavdr stable per Pinning bevorzugt und mir ist aufgefallen, daß das stable PPA eine ältere Version von vdr-addon-avahi-linker anbietet:


    Code
    1. apt-cache policy vdr-addon-avahi-linker
    2. vdr-addon-avahi-linker:
    3. Installiert: 20151223011414stable-0yavdr0~trusty
    4. Installationskandidat: 20160313134933unstable-0yavdr0~trusty
    5. Versionstabelle:
    6. 20160313134933unstable-0yavdr0~trusty 0
    7. 500 http://ppa.launchpad.net/yavdr/main/ubuntu/ trusty/main amd64 Packages
    8. *** 20151223011414stable-0yavdr0~trusty 0
    9. 500 http://ppa.launchpad.net/yavdr/stable-vdr/ubuntu/ trusty/main amd64 Packages
    10. 100 /var/lib/dpkg/status


    Da stellt sich mir jetzt die Frage, sollte ich das Pinning bei 0.61 entfernen? Sollte das stable PPA nicht höhere Prio haben als das main PPA?

    Einer meiner User hatte ein kleines Problem mit dem obigen upstart Scripts wenn regelmäßig Nachts um 03:00 der Rechner mittels /etc/vdr/vdr-addon-acpiwakeup.conf gestartet wird. Anstatt das VDR den Rechner schnell wieder ausschaltet, kann der Rechner jetzt frühestens nach der in Kodi eingestellten Zeit ausschalten. Ich habe daher mal versucht, das Script so zu erweitern, daß Kodi zur mit ACPI_REGULAR_TIME angegeben Aufwachzeit nicht gestartet wird. Bei normalen Timeaufnahmen hingegen sehe ich weniger ein Problem und hier sollte auch Kodi normal weiter gestartet werden:


    Leider ist dies nicht wirklich eine gangbare Lösung hier. Ich habe daher ca. 8 Std. damit verbracht yaVDR 0.61 neu auf dem Zotac ND22 zu installieren. Das Problem scheint zumindest vorerst weg zu sein und stop vdr braucht nur noch die üblichen 5 Sek anstatt 65 Sek. Irgendetwas an der alten Installation war wohl schiefgelaufen.

    Angesichts Deiner alten Hardware und den diversen Problemen anderer User hier, könnte es an der alten Hardware liegen. Die Lösung scheint bei einigen Usern der Wechsel auf den alten nvidia 304 Treiber zu sein... Bei mir hilft in der grub config pci=nomsi, damit Netzwerk/Bildschirm usw. nicht sterben (kannst Du beim booten in grub einfach mal angeben und ausprobieren)


    Ich weiß nicht, ob sich yavdr 0.61 noch so verhält wie 0.6: Wenn Du ohne Internet installierst, bekommst Du den 304 Treiber installliert. Bei einem Internetzugang den 340. Insofern versuche mal yaVDR ohne Internetzugang zu installlieren.


    Aber ansonsten hat mini73 schon recht, wie sollen wir ohne mehr Info helfen können?

    Mit avahi4vdr plugin braucht mein VDR 1 Minute länger zum beenden auch wenn kein anderer yavdr Rechner an ist. Ich habe mal eine frische 0.61 Installation vorgenommen und hier scheint das Plugin keine Verzögerung zu verursachen. upstart/avahi-linker.log ist völlig unauffällig, aber beim syslog gibt es direkt vor der einen Minute Wartezeit ein paar letzte Meldungen von avahi4vdr-helper, die bei der frischen Installation nicht erscheinen:



    Ich habe auch schon versucht die avahi Pakete/Plugins per reconfigure zurückzusetzen.


    Irgendeine Idee, woran die Wartezeit liegen könnte oder wo ich mal weiter nachschauen sollte? Mir gehen die Ideen aus.

    beinhart :


    Ich hatte keine Probleme mit dem Wechsel von Kodi auf VDR wie Du, jedoch beim Wechsel von Passtrough auf PCM via HDMI (sowohl in softhddevice als auch Kodi). Ich hatte hier

    Code
    1. -D
    2. -a plughw:NVidia,3
    3. -p hw:0,3


    erfolgreich mit Passthrough verwendet. Aber Dein


    Code
    1. -D
    2. -v vdpau
    3. -w alsa-close-open-delay


    löst auch mein Problem auf bessere weise. Danke. Mit alsa-close-open-delay hatte ich auch erfolglos experimentiert. Das -v vdpau scheint wohl entscheidend. Nebenbei, softhddevice.conf wird evtl. bei Updates/webif Aufrufen überschrieben. Um es Updatesicher zu machen, folgende Befehle als root ausführen:


    Code
    1. mkdir -p /etc/yavdr/templates_custom/etc/vdr/conf.avail/softhddevice.conf/
    2. echo "-v vdpau" >/etc/yavdr/templates_custom/etc/vdr/conf.avail/softhddevice.conf/22_audiodevices
    3. echo "-w alsa-close-open-delay" >>/etc/yavdr/templates_custom/etc/vdr/conf.avail/softhddevice.conf/22_audiodevices
    4. chown root:root /etc/yavdr/templates_custom/etc/vdr/conf.avail/softhddevice.conf/*
    5. chmod 644 /etc/yavdr/templates_custom/etc/vdr/conf.avail/softhddevice.conf/*
    6. process-template /etc/vdr/conf.avail/softhddevice.conf
    7. cat /etc/vdr/conf.avail/softhddevice.conf

    Habe gerade mal die edid Daten eines Sony TV die hier noch rumlagen rüberkopiert und es läuft... also muss ich wohl nur an die richtigen Samsung TV edid Daten kommen und den Onkyo Verstärker vergessen. Ich werde jetzt noch ein bischen Testen (nvidia 304 Treiber?, yavdr 0.5,...), Denke aber, daß Problem läßt sich jetzt lösen...


    Tausend Dank

    Danke seahawk1986.... Ich hatte eine ähnliche Vermutung schon gehabt und den Bildschirm neu auslesen lassen/rebootet. Doch das mit den 1920x1200 habe ich übersehen. Wenn ich eine Datei mit 1280x720@29.97 abspiele, bekomme ich 1920x1080. Also habe ich mir mal angeschaut, was die edid Daten sagen auf meinen beiden 0.6 Rechnern (Zotac ND22 und M4N78Pro):



    Wenn ich mich richtig erinnere, lieferte der Onkyo Verstärker durchaus die vom Samsung TV gelisteten Bildschirmmodi. Derzeit vermute ich, daß die edid Daten nicht korrekt ausgelesen werden. Ich werde mal nachschauen, was die edid Daten unter 0.5 liefern und notfalls evtl. den TV direkt an den VDR Rechner hängen. Da dies wegen langer Kabel nur schwer geht, stellt sich die Frage, kann ich einfach die edid Datei /etc/X11/edid.0.yavdr austauschen/kopieren? Ich vermute, ich muss danach irgendein Template oder so neu aufrufen/erstellen?


    Zumindest weiß ich jetzt erstmal, wo ich suchen muss.... Danke

    Frage: Hat hier jemand mit Kodi 16.0 Probleme 1920x1080 mit 29.97 Hz abzuspielen?


    Bei mir bleibt der Bildschirm einfach schwarz und der Verstärker zeigt auch keinerlei HDMI Signal am Eingang an. Soweit ich es sagen kann, tritt das Problem nur auf, wenn man die Bildschirmrate anpassen läßt (der Samsung TV kann 24/25/30/50/60) und wenn die Daten FullHD sind. 1280x720 mit 29.97 Hz macht scheinbar keine Probleme. Kodi 15.2 macht keine Probleme. Irgendeine Idee, woran das liegen könnte? Habe nur ich das Problem?


    Unten das Kodi 16 Log. Im Vergleich zu dem Log mit der 1280x720 Version sehe ich eigentlich keinen großen Unterschied. Teilweise sind die Fehlermeldungen an anderer Stelle (wohl einfach nur unterschiedliches Timing...):


    Hustler :


    Ich denke, wir sollten klar machen, wovon wir hier reden. Du hast scheinbar zwei Probleme???


    1. Dein System friert ein? Hier hilft bei mir wie gesagt pci=nomsi. Allerdings habe ich eben drei PCI Sat Karten im System und keine PCI-Express. Wenn Du also weiterhin Probleme mit dem Einfrieren hast, würde ich mal neben/anstatt pci=nomsi ein paar weitere Sachen probieren (inbesondere die nopic und pci=routeirq Option scheint mir interessant). Siehe auch https://wiki.ubuntuusers.de/Bootoptionen/


    2. Dein Ton geht bei Alsa nicht. Bei PulseAudio geht er nachdem Du die gewünschte Ausgabe einstellst bis zu einem Reboot???


    Also, Deine lspci/log Ausgaben oben scheinen mir vollkommen normal. Das gewünschte Ausgabedevice Karte 0: NVidia [HDA NVidia], Gerät 3: HDMI 0 [HDMI 0] ist da. SAA7134 dürfte von einer Deiner Sat Steckkarten herkommen. Ich habe da auch einige zusätzliche Soundkarten durch meine Sat Karten (CX8811, CX8801). Ich hatte ja oben schon im meinem Posting nachträglich die aplay Ausgabe gestrichen, eben weil ich erkannt hatte, daß Du bei PulseAudio einen Ton bekommst. Das wäre nicht möglich, wenn der NVidia Treiber und zumindest die lowlevel Funktionen der verwendeten Alsa Treiber nicht gehen würden. Insofern sollte die oben gepostete kleine asound.conf mit Alsa funktionieren. Hast Du auch in Alsamixer den Ausgang unmuted?


    Aber vielleicht ist es angesichts Deiner Alsa Probleme erst einmal einfacher auf PulseAudio zurückzuschalten, da Du hier ja einen Ton bekommst. Ich vermute, nachdem Du in PavuControl das gewünschte Ausgabedevice usw. gewählt hast? Das die Einstellung nach einem Reboot gerne wieder verloren geht, ist hier im Forum ja schon (siehe hier und hier) schon beschrieben worden. Wie gesagt, hier hilft es normalerweise, mittels /var/lib/vdr/plugins/pulsecontrol/startup.script nach dem Booten wieder auf das gewünschte Ausgabegerät/Profil in PulseAudio umzuschalten. Ich vermute set-card-profile 0 output:hdmi-stereo in der Datei dürfte reichen.

    Noch eine Warnung: Wenn Du wie oben beschrieben die Einstellungen für grub und softhddevice änderst, werden diese bei Updates bzw. webif Aufrufen evtl. wieder überschrieben. Du mußt also templates verwenden, wenn die Änderungen dauerhaft gespeichert bleiben sollen. Hier die nötigen Befehle (vorher mittels sudo su root werden):


    nomsi Option bei grub dauerhaft installlieren:

    Code
    1. mkdir -p /etc/yavdr/templates_custom/etc/default/grub
    2. echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT pci=nomsi"' >/etc/yavdr/templates_custom/etc/default/grub/12_nomsi
    3. chown root:root /etc/yavdr/templates_custom/etc/default/grub/*
    4. chmod 644 /etc/yavdr/templates_custom/etc/default/grub/*
    5. process-template /etc/default/grub
    6. update-grub


    Falls Du die Audiodevices für softhddevice angeben willst:

    Code
    1. mkdir -p /etc/yavdr/templates_custom/etc/vdr/conf.avail/softhddevice.conf/
    2. echo "-a plughw:NVidia,3" >/etc/yavdr/templates_custom/etc/vdr/conf.avail/softhddevice.conf/22_audiodevices
    3. echo "-p hw:0,3" >>/etc/yavdr/templates_custom/etc/vdr/conf.avail/softhddevice.conf/22_audiodevices
    4. chown root:root /etc/yavdr/templates_custom/etc/vdr/conf.avail/softhddevice.conf/*
    5. chmod 644 /etc/yavdr/templates_custom/etc/vdr/conf.avail/softhddevice.conf/*
    6. process-template /etc/vdr/conf.avail/softhddevice.conf


    Rein aus Interesse, da Du PCI-Express-Karten hast: Hat denn nomsi bei Dir geholfen? Oder musstest Du evtl. noch mit noapic experimentieren? Wollte demnächst evtl. zwei 952 installieren.

    Hustler :


    1. Die Angabe des plughw:NVidia,3 Ausgabedevices für softhddevice ist wie beschrieben nur nötig, wenn Du passthrough (z.B. mit der obigen 5.1 asound.conf) verwendest. Bei normalen HDMI Stereo mit der kleinen asound.conf oben brauchst Du das wohl nicht und ich weiss noch nicht einmal, ob plughw:NVidia,3 mit der kleinen asound.conf überhaupt exisitiert?


    2. Hatte überlesen, daß bei Dir PulseAudio geht. Damit hast Du auch das HDMI Ausgabedevice: Erscheint bei aplay -l das HDMI Ausgabedevice überhaupt? Ist es auch card 0/device 3? Ich habe den normalen Ubuntu 340 Treiber installiert. Wenn ich das richtig mitbekommen habe, wird dieser auch bei einer yaVDR Installation mit Internet-Zugang installiert (ohne Internet gibt's die 304?). Ich frage mich, ob überhaupt das System korrekt installiert wurde, bedenkt man die massiven Probleme die ich ohne nomsi hatte. Vielleicht doch noch einmal mit nomsi neu installieren?


    Code
    1. aplay -l**** List of PLAYBACK Hardware Devices ****card 0: NVidia [HDA NVidia], device 0: VT1708S Analog [VT1708S Analog] Subdevices: 1/1 Subdevice #0: subdevice #0card 0: NVidia [HDA NVidia], device 1: VT1708S Digital [VT1708S Digital] Subdevices: 1/1 Subdevice #0: subdevice #0card 0: NVidia [HDA NVidia], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0



    3. Schalte noch einmal kurz zu PulseAudio zurück. Dann reboote. Wie gesagt, das Umschalten auf Alsa klappte bei mir auch zweimal nicht auf Anhieb. Keine Ahnung wieso.


    4. Ansonsten klappt ja auch PulseAudio, wenn Du jedes mal nach dem Booten in Pavucontrol das richtige Ausgabedevice/Profil auswählst. Du mußt jetzt nur noch via VDR Plugin dies nach dem Booten automatisieren. Dazu mußt Du eine Datei /var/lib/vdr/plugins/pulsecontrol/startup.script mit dem entsprechenden Umschaltbefehl erstellen (siehe andere Postings hier im Forum). Ich glaube beim M4N78Pro MB war set-card-profile 0 output:hdmi-stereo als Umschaltbefehl ok.

    Auch ich hatte zuerst den Eindruck das es am NVidia Treiber liegt, doch beim Testen fiel mir teilweise auf, daß die Fehlermeldungen im Syslog einfach keinen Sinn ergaben. Es gab teilweise Ausfall des Netzwerks, dann war es die Grafik, kein USB, kein Ton usw. . Dies deutete letztlich auf ein Problem des Kernels mit dem Motherboard/Steckkarten hin und ich fing an die diversen Kernel Optionen (noapic, nomsi,...) in Grub auszuprobieren. Letztlich war es wirklich einfach nur die nomsi Option. Seit zwei Wochen läuft das System nun hier mit 0.6 und hatte nur einen Kodi-Absturz. Derart zuverlässig war yaVDR 0.3-0.5 bei mir bei weitem nicht ;-)


    Kein Ton? Trotz nomsi? Taucht das HDMI Audio Device in bei der aplay Liste auf? Verwendest Du Pulseaudio oder Alsa? Ich nehme Alsa, da man bei PulseAudio erst noch via VDR plugin nach dem Booten auf das passende Profile umschalten müsste, um Ton zu bekommen. Da fand ich Alsa einfach zuverlässiger. Wie hier schon im Forum geschildert, mußte ich durchaus mehrmals zwischen PulseAudio und Alsa umschalten, bis ich nach einem Reboot bei Alsa einen Ton hatte. Keine Ahnung wieso, tritt auch mit anderen Motherboards manchmal auf.


    Die funktionierende /etc/asound.conf Einstellung für HDMI Stereo lautet (ist glaube ich die per webif auch default eingestelllte Config):



    Falls Du 5.1 Sound mit passthrough ausgeben willst, hier meine /etc/asound.conf die auch in Kodi mit AAC 5.1 funktioniert:


    Ich denke, die 5.1 asound.conf Datei läßt sich sicherlich noch deutlich aufs Wesentliche verschlanken, doch dazu hatte ich noch keine Zeit. Ich war schon froh, daß damit scheinbar alles mit meinem Verstärker in Kodi korrekt funktioniert.
    Wie oben erwähnt, musst Du bei obiger 5.1 asound.conf noch das Ausgabedevice für softhddevice ändern und in Kodi war bei mir das letzte der beiden gelisteten "HDMI" Ausgabegeräte das richtige für PCM, damit nach Passtrough wieder ein Ton bei PCM kommt.


    Tja, das war eigentlich schon alles, was bei mir für das M4N78Pro Motherboard bei yaVDR 0.6 nötig war.

    Hustler :


    Ich habe auch das M4N78 Pro Motherboard hier im Einsatz und hatte auch bei 0.6 das Problem, daß das System kurz nach dem Booten Probleme machte. Die Lösung war in /etc/default/grub bei GRUB_CMDLINE_LINUX_DEFAULT die Option pci=nomsi hinzuzufügen und danch sudo update-grub aufzurufen. Es hat bei mir mehrere Anlaufe gebraucht, da das System sich oft schon beim Booten oder sehr kurz danach verabschiedete.


    Ansonsten läuft der nvidia 340 Treiber hier sehr gut. Probleme gibt es bei Softhddevice+Kodi beim Ton mit Alsa, wenn man Passthrough beim Ton verwendet. Hat man einmal Passthrough verwendet, klappt der normale PCM Ton danach nicht mehr. Hier muss man evtl. in /etc/vdr/conf.d/50-softhddevice.conf das Ausgabedevice angeben, wobei bei mir seit 2 Wochen folgendes fehlerlos klappt:


    Code
    1. [softhddevice]
    2. -D
    3. -a plughw:NVidia,3
    4. -p hw:0,3

    Ich verwende die 32 und 64 GB Versionen. Suche einfach bei Amazon nach "SanDisk Extreme USB-Flash-Laufwerk" und Du solltest die richtigen finden (EUR 24,19 (32GB) bzw. EUR 40,99 (64GB) ). Falls Du andere Sticks findest die ähnlich schnell sind bei kleinen Schreibbefehlen zu einem günstigeren Preis, lasse es mich wissen. Ich senke gerne meine Kosten ;-)


    Ja, ich habe damit auch Aufnahmen auf den Stick gemacht.

    Auf meinem M4N78 Pro Motherboard hatte einmal der SATA Controller den Geist aufgegeben und ich habe mehrere Wochen yaVDR vom USB Stick Clone der Festplatte benutzt. Dabei ist jedoch zu beachten, daß bei yaVDR die Geschwindigkeit des USB Sticks gerade bei kleinen Lese- und Schreibzugriffen enorm wichtig ist. Bei "normalen" Sticks bekommt man schnell massive Probleme, wenn mehrere Sachen gleichzeitig auf den USB Stick inbesondere geschrieben werden. Das System friert fast regelrecht ein, wenn Linux Logs schreibt während eine Aufnahme läuft. Dann schlagen bei yaVDR Aufnahmen fehl, der Stick bootet nicht richtig, u.v.m. . Daher mein dringender Rat, ein paar Euro mehr ausgeben und einen USB Stick kaufen, der z.B. bei den CrystalDiskMark 4K Write Benchmarks gut ist. Ich persönlich lande daher immer bei den Sandisk Extreme USB 3.0 Sticks. Allerdings Vorsicht, es soll angeblich Motherboards geben, wo einige der USB Sticks sich nicht booten lassen (je nachdem ob diese sich als Wechsellaufwerk oder Festplatte zu erkennen geben... Sandisk hat dies wohl geändert). Bei keinem meiner Motherboards gab es allerdings damit Probleme. Scheint ein eher seltenes Problem zu sein.

    Wenn ich an meinen yaVDR USB Sticks etwas ändern will, mache auch ich von den Sticks mittels Linux vorher ein Backup. Zuerst installiere ich dazu unter Ubuntu/yavdr 0.6 zwei kleine Kommandozeilentools, die das Backup beschleunigen helfen. Es würde auch ohne gehen, aber mit den Tools geht es deutlich schneller.


    Code
    1. sudo apt-get install pigz pv


    Der Befehl zum Backup von USB Stick /dev/sdb in die Datei usbstick_yavdr06.img.gz lautet dann folgendermaßen (vorher z.B. mittels sudo su root werden):

    Quote

    dd if=/dev/sdb conv=sync,noerror ibs=512 obs=64K | pv -trab -B 500M -e | pigz -c | dd of=usbstick_yavdr06.img.gz bs=128K status=noxfer


    Der Befehl komprimiert das Backup mittels pigz (ein gzip kompatibles Tool mit multithread Support) und pv hilft (evtl.) bei der Geschwindigkeit mittels Pufferung. Wenn Du bei pv noch die Option -s $(blockdev --getsize64 /dev/sdb) angibst, bekommst Du auch die Zeit bis zur voraussichtlichen Fertigstellung angezeigt. Selbst bei einer mittelmäßigen CPU sollte das die Geschwindigkeit von USB Stick / Zielspeicher halbwegs erreichen.


    Für das Zurückspielen des Backups verwende ich:

    Quote

    pigz -dc usbstick_yavdr06.img.gz | pv -trab -B 500M -e | dd of=/dev/sdb


    Ist der USB Stick nur zu einem geringen Teil gefüllt, kann es hin und wieder sinnvoll sein, nicht benutzte Bereiche des Sticks mit Nullen zu füllen, damit die Komprimierung schneller und besser funktioniert. Angenommen die Daten liegen auf /dev/sdb1 :


    Wie seahawk1986 schon sagte, kannst Du z.B. mittels Clonezilla Backups erstellen, wobei hier leere Stellen übersprungen werden. Ich bin aber kein Fan davon, noch einen weiteren USB Stick extra für Clonezilla zu erstellen, zumal es auch hier teilweise zu Problemen beim Zurückspielen kam, weshalb ich dd einfach wegen der hohen Zuverlässigkeit bevorzuge. Im Notfall kann man auch einfacher das dd Image mounten um an Dateien ranzukommen. Da Clonezilla wohl meistens partclone verwendet, kannst Du auch den obigen Befehl etwas nach der Installation des partclone Befehl anpassen, z.B. um eine ext4 Partition ähnlich wie Clonezilla zu backupen. Das geht aber nur partitionsweise:


    Quote

    partclone.ext4 -c -d -s /dev/sdb1 -o - | pv -q -B 500M | pigz -c | dd of=usbstick_yavdr06.pcloneimg.gz bs=128K status=noxfer


    Nach meinen Tests geht dies zwar schneller als obiger Befehl, wenn die Partition sehr große Leerbereiche hat, aber der Preis ist nunmal die Sicherheit/Kompatibilität, die nicht so gut ist wie bei dd. Auch kannst Du im Notfall mit fast jeder Linux Live-CD das Backup zurückspielen, ohne das Du erst lange Software suchen/installieren mußt.