[Marcus]

Ja, das ist ganz normal bei mir. Das artet immer aus. Arzt sagt das sei unheilbar. 
Es wird aber noch besser. Wenn die Aufnahmen größer werden, stürzt der VDR beim Verschieben irgendwann ab. Wahrscheinlich wartet er auf das Beenden des Script und wenn es ihm zu lange dauert, macht er einen emergencyexit.

[Marcus]

Man muss das Script in den Hintergrund verschieben, dann blockiert das den VDR nicht mehr. Die Scripte ausführbar machen und auf das Zeilenende achten, wenn man unter Windows arbeitet.

/usr/share/vdr/recording.d/50_move.sh:

Code: [Select]

#!/bin/sh

/root/move.sh $@ &
/root/move.sh:

Code: [Select]

#!/bin/sh

SOURCEMP="mnt/e452bda1-7e77-4d61-aa2d-1ad61c27d313"
TARGETMP="mnt/a22b93627956a61ed127db92215c3cba"
SOURCEDIR="${2//\/data\//\/"$SOURCEMP"\/}"
TARGETDIR="${2//\/data\//\/"$TARGETMP"\/}"
TARGETDIR2=`dirname "$TARGETDIR"`

case "$1" in
before)
mkdir -p "$SOURCEDIR" >/dev/null #Verzeichnis erstellen, damit ggf. 00002.ts auf dem Stick landet
;;
after)
while [ -f /"$SOURCEMP"/tv/.move >/dev/null ]; do # Läuft noch ein anderer Verschiebevorgang?
svdrpsend.sh "MESG Es wird bereits eine Aufnahme verschoben..." >/dev/null
sleep 5
done
touch /"$SOURCEMP"/tv/.move  >/dev/null
svdrpsend.sh "MESG Aufnahme beendet, verschiebe auf den Server..." >/dev/null
if [ -d "$TARGETDIR" ]; then
mv "$SOURCEDIR"/* "$TARGETDIR" >/dev/null
if [ $? != "0" ]; then
svdrpsend.sh "MESG FEHLER während des Verschiebens!" >/dev/null
else
svdrpsend.sh "MESG Verschieben der Aufnahme beendet." >/dev/null
fi
rm -df "$SOURCEDIR" >/dev/null
rm "$TARGETDIR"/index >/dev/null #index löschen, muss neu generiert werden, damit Länge passt.
vdr --genindex="$TARGETDIR" >/dev/null
else
mkdir -p "$TARGETDIR2" >/dev/null
mv "$SOURCEDIR" "$TARGETDIR2" >/dev/null
if [ $? != "0" ]; then
svdrpsend.sh "MESG FEHLER während des Verschiebens!" >/dev/null
else
svdrpsend.sh "MESG Verschieben der Aufnahme beendet." >/dev/null
fi
fi
touch /data/tv/.update
rm /"$SOURCEMP"/tv/.move  >/dev/null
;;
esac


Und noch die fstab:

Code: [Select]

# stock fstab - you probably want to override this with a machine specific one

/dev/root            /                    auto       noatime              1  1
proc                 /proc                proc       defaults              0  0
devpts               /dev/pts             devpts     mode=0620,ptmxmode=0666,gid=5      0  0
tmpfs                /run                 tmpfs      mode=0755,nodev,nosuid,strictatime 0  0
tmpfs                /var/volatile        tmpfs      defaults              0  0

# uncomment this if your device has a SD/MMC/Transflash slot
#/dev/mmcblk0p1       /media/card          auto       defaults,sync,noauto  0  0


UUID=731E-4AA7 /boot auto noatime 1 2


UUID=e452bda1-7e77-4d61-aa2d-1ad61c27d313 /mnt/e452bda1-7e77-4d61-aa2d-1ad61c27d313 auto subvol=@data 0 2
192.168.50.11:/export/VDR /mnt/a22b93627956a61ed127db92215c3cba auto soft,_netdev 0 0
/mnt/e452bda1-7e77-4d61-aa2d-1ad61c27d313:/mnt/a22b93627956a61ed127db92215c3cba /data mergerfs category.create=eplfs,direct_io,use_ino,fsname=/dev/sda2:192.168.50.11/export/VDR,_netdev 0 0

[clausmuus]

Du hättest natürlich auch einfach den "after" Block in klammern packen können, und hinter die schließende Klammer das & schreiben. Dann kannst DU auch gleich das >/dev/null nur einmal schreiben:

Code: [Select]

after)
    (
    ...
    ) & >/dev/null
vermutlich muss auch noch stderr und stdin nach /dev/null umgelenkt werden, damit der VDR Prozess freigegeben wird.

Code: [Select]

after)
    (
    ...
    ) & >/dev/null 2>&1 </dev/null


[Marcus]

Ja, das macht es etwas einfacher, danke. Dann entfällt /root/move.sh und /usr/share/vdr/recording.d/50_move.sh sieht jetzt so aus:

Code: [Select]

#!/bin/sh

SOURCEMP="mnt/e452bda1-7e77-4d61-aa2d-1ad61c27d313"
TARGETMP="mnt/a22b93627956a61ed127db92215c3cba"
SOURCEDIR="${2//\/data\//\/"$SOURCEMP"\/}"
TARGETDIR="${2//\/data\//\/"$TARGETMP"\/}"
TARGETDIR2=`dirname "$TARGETDIR"`

case "$1" in
before)
mkdir -p "$SOURCEDIR" #Verzeichnis erstellen, damit ggf. 00002.ts auf dem Stick landet
;;
after)
(
while [ -f /"$SOURCEMP"/tv/.move ]; do # Läuft noch ein anderer Verschiebevorgang?
svdrpsend.sh "MESG Es wird bereits eine Aufnahme verschoben, warte..."
sleep 5
done
touch /"$SOURCEMP"/tv/.move
svdrpsend.sh "MESG Verschiebe Aufnahme auf den Server..."
if [ -d "$TARGETDIR" ]; then
mv "$SOURCEDIR"/* "$TARGETDIR"
if [ $? != "0" ]; then
svdrpsend.sh "MESG FEHLER während des Verschiebens!"
else
svdrpsend.sh "MESG Verschieben der Aufnahme beendet."
fi
rm -df "$SOURCEDIR"
rm "$TARGETDIR"/index #index löschen. Muss neu generiert werden, damit die Länge passt.
vdr --genindex="$TARGETDIR"
else
mkdir -p "$TARGETDIR2"
mv "$SOURCEDIR" "$TARGETDIR2"
if [ $? != "0" ]; then
svdrpsend.sh "MESG FEHLER während des Verschiebens!"
else
svdrpsend.sh "MESG Verschieben der Aufnahme beendet."
fi
fi
touch /data/tv/.update
rm /"$SOURCEMP"/tv/.move
) & >/dev/null 2>&1 </dev/null
;;
esac



[Marcus]

Übrigens, wenn eine Aufnahme verschoben wird, während sie abgespielt wird, dann passiert einfach mal gar nix. Der VDR bekommt das nicht mit. Mergerfs macht da einen verdammt guten Job! DAS hätte ich nicht erwartet. Aber das ist wie immer. Da wo man die Probleme erwartet, passiert nichts. Aber da wo man denkt, das funktioniert wohl einfach so, da lauern die Probleme.

[clausmuus]

Der Trick dabei ist, dass eine geöffnete Datei nicht auf den Pfad zeigt, sondern auf die Datei ID. Solange eine Datei auf dem selben Dateisystem verschoben wird, ändert sich diese nicht, und ein Verschieben stört nicht. Mergerfs erzeugt, je nach Einstellung, eigene IDs die sich beim Verschieben der Datei im Hintergrund wohl auch nicht ändert

[Marcus]

Ja, das ist schon cool. Eigentlich funktioniert das Verschieben jetzt perfekt.

Um das Herunterfahren habe ich mich aber noch nicht gekümmert. Unklar, ob ich das überhaupt brauche. Denn ich habe bei Aufnahmen der ÖR in HD die gleichen Probleme, wie beim direkten Schreiben auf den Server. Der Stick ist USB3 und, getestet, sehr schnell. Die Aufnahmen sind nicht zu gebrauchen, völlig zerstört. Es liegt also nicht am Server. Hat mich eh gewundert. Der ist zwar nicht superschnell, schafft aber gut 35 MB/s schreibend. Offensichtlich ist der Wyse 3040 schlicht zu langsam. Und das verstehe ich nicht. Der VDR lief früher auch auf nem Celeron mit 266 MHz, der nur einen Kern hatte. Und da hat er auch die TS Daten (damals noch PES) auf die Platte (die ebenfalls langsamer war) geschaufelt. Und so viel mehr an Daten ist das doch nicht geworden?

EDIT: Und ein Raspberry PI 2 schafft es doch auch?

[Marcus]

Gegenprobe OHNE mergerfs. Zwei HD Aufnahmen (ÖR, 720p) gleichzeitig und eine davon per Timeshift gucken, funktioniert fehlerfrei. Load ist kurz vor 4 und alle CPU-Kerne über 80%. Das alles bei nur 480 MHz, da die TDP von Dell (absichtlich oder fälschlicherweise?) auf nur 2 Watt festgelegt wurde. Vorher mit mergerfs und einer Aufnahme, ohne Timeshift-Wiedergabe, gab es bei einer Load von 2,5 und einer CPU-Auslastung von 50-60% über alle Kerne schon massiv Fehler. Und ich rede da von rund 1.000 Fehler pro Minute. Da geht alles kaputt.

Ohne mergerfs werden die Daten kontinuierlich auf den Stick geschrieben. Mit mergerfs in Intervallen, mit entsprechend hohen Datenraten, gefolgt von langen Pausen. Ich weiß nicht, ob das per Design so sein soll, oder ob mergerfs ein Problem hat, bzw ungünstig parametriert ist.

Ist echt schade, weil mergerfs hier echt Vorteile hatte. Kein extra Ordner "Server" und Verschieben während Wiedergabe möglich.

Btw, warum wird mergerfs grundsätzlich verwendet, wenn man NFS-Mounts einbindet? Auch wenn es der einzige Mount für /data ist? Eigentlich macht es doch nur dann Sinn, wenn man mehrere Dateisysteme auf den gleichen Mountpoint einhängen möchte. Oder übersehe ich was?

[clausmuus]

Leider produziert Mergerfs auf schwachen Systemen (oder nur bestimmten Systemen) wie z.B. dem RPI2 eine recht hohe Systemlast. Auf Intel Systemen (auch schwachen) konnte so etwas bisher nicht beobachtet werden.
Grundsätzlich is Mergerfs nicht sonderlich performant, was da dran liegt, dass es ein Userspace Filesystem ist und die dafür verwendete Schnittstelle des Kernels halt langsam ist. Warum das auf manchen Systemen zu echten Problemen führt, auf anderen (ähnlich schwachen) Systemen aber nicht, weiß ich nicht.

Beim nfs wird pauschal immer Mergerfs verwendet, weil das der einzige Weg ist den ich finden konnte, um sicher zu stellen, dass es auch bei verzögerten Mount (oder aussetzern) keine Probleme gibt. Mergerfs ist halt mega robust
Wenn Du sicher bist, dass Deine NAS immer verfügbar ist, und das Mounten sofort klappt, kannst Du ja mal testen, ob es hilft, wenn Du den NFS Mount (hard mount) direkt nach /data machst, und auf alle anderen Spielerein verzichtest. Ich hatte zuvor leider nicht mehr an den Mergerfs Trick gedacht, und auch nicht da dran, dass Mergerfs auf einem Intel System Performance Probleme machen kann. Ansonsten hätte ich das schon früher vorgeschlagen.
Ob es wirklich ein hard Mount sein muss, oder auch soft mount oder die Dritte variante am besten passt (hab grad vergessen wie die heißt), musst Du ausprobieren. Beim hard Mount wird der Boot Vorgang unterbrochen, biss der Mount erfolgt ist. Bei soft passiert das im Hintergrund, egal wie lange es dauert.

[Marcus]

Vielen Dank für die Erklärung, das leuchtet natürlich ein.

Ich bin mir noch nicht sicher, ob ich mergerfs aufgeben will. Es gibt ja nun mehrere Gründe, warum man es nutzen sollte. Es hatte ja für meinen Anwendungsfall auch ein paar nette positive Eigenschaften. Ich sehe zwei Möglichkeiten, wie das noch was werden könnte. Ich spiele mal etwas mit den Mount-Optionen, scheint ja ganz gut dokumentiert zu sein. Unklar, ob dabei was rum kommt, das habt ihr ja sicherlich auch schon getan. Die zweite Möglichkeit wäre, das Biest aus dem Atom frei zu lassen. Dazu brauche ich den Intel-RAPL-Treiber. Der Wyse läuft, dank Dell, derzeit nur auf 1/4 seiner (CPU-) Leistung. Die CPU kann 1920 MHz, derzeit auf 480 MHz begrenzt. Es könnte sein, dass das ausreichend ist. Thermisch sollte das nicht viel ausmachen. So wie mergerfs arbeitet, sind die höheren Taktfrequenzen immer nur sehr kurz nötig.

[clausmuus]

Ich habe mich jetzt mal um Dein PowerCap Problem gekümmert. in 15 Minuten gibt es ein Kernel Update. Damit sollte die Schnittstelle verfügbar sein.

[Marcus]

Claus, du bist der Allerbeste! Ich danke dir. Leider bin ich gerade beruflich unterwegs und komme erst am Wochenende heim. Kann es aber kaum erwarten. 

[Marcus]

Hallo Claus.

Ich wollte gerade den Kernel updaten. Habe auf deine Paketquellen gewechselt und sehe einen neuen Kernel zum Updaten. Leider gibt es dann einen 404 - not found.

[Marcus]

Der Kernel ist wohl im falschen Ordner gelandet. Der Kernel ist hier: https://mld6.minidvblinux.de/nightbuild/deb/genericx86_64/ und die Packages Datei die ihn beinhaltet hier: https://mld6.minidvblinux.de/claus/deb/genericx86_64/

[clausmuus]

Der neue Kernel wurde im Nightbuild erstellt, also nicht meine Paketquelle.