Nein, ich habe am VDR nur eine interne Festplatte mit ext4, die alle 1-2 Monate mit einer externen Festplatte ge-rsync'ed wird, die dann wiederum physisch an einen anderen Ort kommt.
Mir geht es einfach darum zu Verhindern, dass das Kind mal in den Brunnen fällt - so ein 10-Stunden-Restore ist auch nicht unbedingt vergnügungssteuerpflichtig.
Mir war auch neu, dass man uninterpretierte Steuerungsrohdaten so einfach bulk ins syslog reinjaucht.
Wie dem auch sei...
ich habe mit folgendem APT-Befehl zwischenzeitlich mal einen rustikalen Rollback aus den Backports gemacht...
apt install libxine2-x:i386=1.2.6-1.3 libxine2:i386=1.2.6-1.3 libxine2-misc-plugins:i386=1.2.6-1.3 libxine2-ffmpeg:i386=1.2.6-1.3 libxine2-console:i386=1.2.6-1.3 libxine2-bin:i386=1.2.6-1.3 ./xineliboutput-sxfe_1.1.0+cvs20150907-3_i386.deb ./libxine2-xvdr_1.1.0+cvs20150907-3_i386.deb ./libavutil54_11.12-1~deb8u9_i386.deb
...und alles läuft wieder geschmeidig. Hatte aber auch extra noch ein Backup vor den Backports gemacht.
Wenn sonst auch niemanden mehr was zu einer evtl. Lösung einfällt, probiere ich halt direkt mal den nächsten Schritt auf Buster.
Kann jemand was dazu sagen, was mich da erwarten würde in Sachen vdr-sxfe/FFMPEG/vdpau und was es generell evtl. zu beachten gibt?
fnu
: Ich will den Archiv-Ordner und die Kategorie-Ordner drunter schützen, damit bei einem versehentlichen Löschen nicht gleich dutzende Aufnahmen oder gar alles im Orkus landet. Darunter möchte ich aber gerne weiterhin Aufnahmen reinschieben oder auch löschen können und der VDR soll bei Bedarf seine resume-Dateien erstellen können.
Ich bin in Sachen POSIX auch relativ unbeleckt: mir erscheint EXT4_APPEND_FL mehr wie eine EXT4-Eigenheit(?)
Was die Nützlichkeit für Leute die auf NAS speichern oder ZFS am laufen haben, natürlich aufheben würde.
Ursprünglich hatte ich eigentlich auch chattr +i im Auge, war dann aber ganz verblüfft über die Erklärung der Wirkungsweise von chattr +a bei StackExchange.
Wie SHF schon sagte: bei Gelegenheit werde ich das auch mal durchtesten.
Wenn man das FS-unabhängig machen wollte, wären vielleicht leere Dateien mit Bezeichnungen wie .nodel oder .protected eine Möglichkeit zur Auswertung vor dem Löschbefehl durch den VDR.
Meine VDR-Ordnerstruktur sieht ungefähr so aus:
Neue Aufnahmen landen unter VDR-Aufnahmen, bei Bedarf werden sie geschnitten in die Unterordner im Archiv-Ordner verschoben.
Jetzt ist es mir schon mehrfach vorgekommen, dass ich versehentlich auf dem Archiv-Ordner oder einem Kategorie-Unterordner die gelbe Löschen-Taste betätigt habe.
Glücklicherweise muss man ja noch bestätigen, aber irgendwann drückt man (oder frau) wohl mal aus Reflex auf OK.
Was habe ich da für Möglichkeiten um das zu Verhindern?
Wäre ein chattr +a auf den Archiv-Ordner eine gute Lösung? (Erklärung)
Wenn ich es recht verstehe, wäre damit wäre dann der Archiv-Ordner samt Unterordnern geschützt, darunter könnte man, frau und VDR aber nach wie vor schalten und walten.
Oder gibt es sonst noch alternative Schutzmöglichkeiten ohne den VDR-Betrieb zu beeinträchtigen?
Astrein, habe es gerade getestet.
Dass mir das all die Jahre durch die Lappen gegangen ist.
Danke seahawk1986!
Das ist das heruntergeladene 50MB syslog in Notepad++ unverändert in UTF8.
Im Anhang mal ein anderer Ausschnitt in ANSI-Kodierung - so sieht es auch nativ übers Terminal im Viewer von MC aus.
Im Anhang mal ein Screenshot, was da für ein Zeichensalat im syslog nach jedem Start auch ohne jede Interaktion auftaucht.
Das kann eigentlich nichts mir LIRC zu tun haben.
Ich hab testweise auch mal die options cx23885 enable_885_ir=1 in der /etc/modprobe.d/cx23885.conf rausgenommen.
Mir ist aber aufgefallen, dass er stark verzögert (15-20 Sekunden) Eingaben manchmal doch aufgreift und z.B. Programme wechselt.
Ein OSD bringe ich aber nie auf den Bildschirm.
Der Zeichensalat beginnt auch immer nach den selben Zeilen im syslog:
Jul 16 15:50:45 vdr vdr-sxfe[854]: [880] [input_osd] Unknown OSD command 10
Jul 16 15:50:45 vdr vdr-sxfe[854]: [880] [input_vdr] invalid parameter in control message OSDCMD
SMR gibt es meines WIssens nach bei WD aktuell nur bis einschließlich 6TB.
Hoffe ich habe das richtig gemacht:
Habe mir direkt am VDR eine neue Konsole (Strg-Alt-F3) geholt, mich als root eingeloggt und xev -display :0 eingegeben.
Dann zurück zum VDR auf Strg-Alt-F2 und dort Keyboardtasten und die Fernbedienung gedrückt.
Zurück auf Strg-Alt-F3, aber nix neues hinzugekommen zu dem hier:
Ich mache das bei neuen Festplatten und SSDs immer so, dass ich sie erst mit head -c xxxGB /dev/zero > zeros.txt bis zur max. Kapazität vollschreibe.
Danach ein smartctl -t short und smartctl -a und wenn dann alles OK ist, nutze ich sie wirklich.
dad401
: Hoffe, dass Du noch WD100EZAZ mit Helium erwischt hast. Neuerdings steigt WD wieder auf Luft um, weil es billiger ist. Hatte letztens mehrere luftgefüllte WD80EDAZ, die lauter und ganze 6°C wärmer liefen (höherer Luftwiderstand, stärkerer Motor nötig, dadurch mehr Wärmeentwicklung und Stromverbrauch) als die heliumgefüllten WD80EMAZ.
Noch als Ergänzung, wie der VDR über vdr-sxfe mit systemd gestarted wird:
Evtl. liegt da irgendwo der Hund begraben.
Oh, herzlichen Dank für den Link zu der DEB, hätte etwas mehr googeln sollen.
Werde ich direkt ausprobieren, wenn ich mein Xine-Debakel gelöst habe.
So, habe geschnallt, dass mir für die zurückgehaltenen Pakete die e-Tobi backports in der sources.list fehlen.
Ergänzt, aktualisiert, reboot und seitdem flutet er mir das syslog mit 2KB/Sekunde mit nachfolgenden Einträgen.
Bedienung des VDR geht nicht mehr, weder mit Maus noch Tastatur.
Irgendwelche Ideen?
Edit: Evtl. hilft der Logauszug noch...
mini73 : Das liegt unter /usr/share/vdr/shutdown-hooks/S10.activitycheck.
Hatte ich vor Jahren mal in einem Forum aufgeschnappt, tut an sich auch das, was es soll, mir ist nur beim Verlängern des Intervalls im Skript heute aufgefallen, dass der Text nie so vom VDR ausgegeben wird. Und da dachte ich einfach, ich frag mal nach.
wmautner
: vdr-plugin-lifeguard-ng gibt es meines Wissens nach nicht für Debian/e-Tobi.
Ich habe hier einen Shutdown Hook, der auf ssh und SMB-Verbindungen testet:
Der funktioniert soweit auch einwandfrei, aber statt der ABORT_MESSAGE sehe ich am TV-Schirm immer nur "Shutdown abgebrochen / Shutdown aborted".
Ist das so gewollt, ein Bug oder ist was falsch in dem Script?
Jetzt habe ich nur noch eine Baustelle: mir werden 2 Pakete als zurückgehalten angezeigt.
Hat jemand dazu noch eine Erklärung bzw. Idee zur Lösung?
So, Lösung gefunden: die Maintainer haben aus unerfindlichen Gründen im Kernel-Modul den RC-Support für die DVBSky S952 per Default abgeschalten:
https://forum.kodi.tv/showthread.php?tid=220265
Mann muss eine /etc/modprobe.d/cx23885.conf erstellen und dort
options cx23885 enable_885_ir=1
reinschreiben.
Reboot und man hat wieder das:
So sah es in den Logs zuvor mit Jessie aus, da wurde der DVBSky RC-Port einwandfrei erkannt und registriert:
Jetzt auf Stretch kommt nach cx23885[0]/0: found at 0000:01:00.0, rev: 4, irq: 16, latency: 0, mmio: 0xbb200000 nichts mehr.
Sollte jemand nach einem Jessie->Stretch-Upgrade auch mal noch das Problem haben, dass Samba nicht mehr geht:
man muss manuell den Ordner /var/lib/samba/private anlegen, ansonsten scheitert es daran
Ebenso sollte man prüfen, ob der Ordner /var/cache/samba/msg auf 0755 ist.
Beides Dinge, die nach dem Upgrade von Samba von 4.2.14 auf 4.5.16 vorausgesetzt werden, aber seitens des Debian-Updateprozesses nicht durchgeführt werden.
