Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Marcus

16
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/

17
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.

18
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.  ;D

19
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. 8) 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.

20
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?

21
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?

22
Ü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.

23
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


24
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

25
Ja, das ist ganz normal bei mir. Das artet immer aus. Arzt sagt das sei unheilbar.  ;D
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.

26
Neue Version. Wenn man auf dem Stick VOR der Aufnahme bereits das Verzeichnis anlegt, landen auch die 00002.ts Dateien dort. Beim Verschieben darf man dann aber nicht den ganzen Ordner verschieben, sondern nur die Dateien darin. Denn der Ordner existiert ja im Ziel bereits. Den Ordner auf dem Stick muss man dann löschen, sonst gibt das Durcheinander. index, resume und info landen sonst auch irgendwann dort. Und den Index muss man neu erstellen lassen, damit die länge wieder passt. Warum das nötig ist, verstehe ich zwar nicht, aber man muss auch nicht alles verstehen.
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"`

touch /"$SOURCEMP"/tv/.move  >/dev/null

case "$1" in
before)
mkdir -p "$SOURCEDIR" >/dev/null #Verzeichnis erstellen, damit ggf. 00002.ts auf dem Stick landet
;;
after)
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
;;
esac
rm /"$SOURCEMP"/tv/.move  >/dev/null


EDIT: "$" vergessen

27
Mir ist gerade aufgefallen, je nachdem welche Version von mergerfs wir benutzen, dass die Mountoptionen "direct_io" und "use_ino" deprecated sind. Siehe https://trapexit.github.io/mergerfs/latest/config/deprecated_options/

28
So funktioniert es, mit Einschränkungen*:

Code: [Select]
#!/bin/sh

SOURCEMP="mnt/e452bda1-7e77-4d61-aa2d-1ad61c27d313"
TARGETMP="mnt/a22b93627956a61ed127db92215c3cba"

case "$1" in
after)
svdrpsend.sh "MESG Aufnahme beendet, verschiebe auf den Server..." >/dev/null
SOURCEDIR="${2//\/data\//\/"$SOURCEMP"\/}"
TARGETDIR=`dirname "${2//\/data\//\/"$TARGETMP"\/}"`
mkdir -p "$TARGETDIR" >/dev/null
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
touch /data/tv/.update
;;
esac

Einschränkung: Wenn man wie oben, eine laufende Aufnahme abbricht und erneut programmiert, landet die 00002.ts direkt auf dem Server, weil das Verzeichnis dort bereits existiert. Das ist schlecht, weil der VDR dabei wieder abschmiert, weil er den Datenstrom nicht in Echtzeit wegschreiben kann. Irgendwas ist immer.

29
Beim Verschieben gibt es das Problem, dass wenn man eine Aufnahme abbricht und danach nochmal aufnimmt, würde VDR normalerweise eine 00002.ts statt einer 00001.ts im gleichen Verzeichnis anlegen. Da letztere aber verschoben wurde, legt VDR ein neues Verzeichnis auf dem Stick an, mit einer 00001.ts drin. Und das Verschieben scheitert, weil das alles auf dem Server schon existiert. Schwieriger als ich dachte.

Das ist das Script bisher:
Code: [Select]
#!/bin/sh

case "$1" in
after)
svdrpsend.sh "MESG Aufnahme beendet, verschiebe auf den Server..." >/dev/null
TARGETDIR=`dirname "${2//\/tv\//\/tv\/Server\/}"`
mkdir -p "$TARGETDIR" >/dev/null
mv "$2" "$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
touch /data/tv/.update
;;
esac

An der Stelle müsste man das wohl mit dem mergerfs so machen, wie du weiter oben beschrieben hast. Dann würde der VDR das erkennen?

EDIT: Das geht auch nicht. Selbst wenn man mergerfs beibringen kann, dass das Schreiben auf ein bestimmtes Dateisystem erfolgen soll, würde der VDR ja immer da drauf schreiben. Also auch die resume, oder beim Verschieben in Unterordner per OSD. Das würde dann alles auf dem Stick landen, selbst wenn es vorher schon auf dem Server lag.

EDIT: Könnte doch gehen. Mit der Mountoption
Code: [Select]
category.create=eplfs statt der MLD-default
Code: [Select]
category.create=epmfs nutzt mergerfs für "create, mkdir, mknod, symlink" das Dateisystem mit dem geringsten freien Speicher (vs. MLD-default meisten freien Speicher), welches dann der USB-Stick sein wird. Alle anderen Dateioperationen finden auf dem Dateisystem statt, auf dem sich die Datei bereits befindet. Das ist genau das, was ich brauche. Jetzt muss ich nur noch herausfinden, wie ich aus $2 (dem Aufnahmeverzeichnis, so wie es der VDR sieht, sprich "/data/tv/'name'/'datum'.rec") die Pfade für die Mountpoints generiere. Es muss "/data/" durch "/mnt/'uuid'" ersetzt werden.

30
Verschieben nach der Aufnahme geht. Vielen Dank für die Tips. Du hattest Recht, bei Serienaufnahme hätte das nicht funktioniert. Teste das noch etwas, dann poste ich das ferige Script hier. Jetzt muss ich dem VDR nur noch beibringen, dass er mit dem Herunterfahren wartet, bis das Verschieben abgeschlossen ist. Sowohl wenn man ihn per Power-Taste ausschaten will, als auch wenn er zur Aufnahme aufgewacht ist und anschließend wieder herunterfahren will. Da ist zwar eine Verzögerung von 5 Minuten drin, ich weiß aber nicht, ob die immer sicher ausreicht.