Posts by rüsseltier

    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:

    Code
    1. /mnt/VDR-Aufnahmen/Archiv
    2. |--Dokus
    3. |--Filme
    4. |--Musik
    5. |--Reportagen
    6. |--Serien

    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?

    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

    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:

    Code
    1. [Unit]
    2. Description=vdr-sxfe
    3. After=vdr.service
    4. [Service]
    5. ExecStart=/usr/bin/xinit -e /usr/bin/vdr-sxfe --aspect=16:9 --width=1920 --height=1080 --audio=alsa --syslog --reconnect -f xvdr+tcp://127.0.0.1
    6. Restart=always
    7. [Install]
    8. WantedBy=multi-user.target

    Evtl. liegt da irgendwo der Hund begraben.

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

    Code
    1. Die folgenden Pakete werden aktualisiert (Upgrade):
    2. libxine2 libxine2-bin libxine2-console libxine2-ffmpeg libxine2-misc-plugins
    3. libxine2-x libxine2-xvdr xineliboutput-sxfe
    4. Jul 15 21:58:17 vdr vdr-sxfe[871]: [887] [input_vdr] vdr_plugin_parse_control(): unknown control ^A
    5. Jul 15 21:58:17 vdr vdr-sxfe[871]: [887] [input_vdr] unknown control message ^A
    6. Jul 15 21:58:17 vdr vdr-sxfe[871]: [887] [input_vdr] vdr_plugin_parse_control(): unknown control ^C^G^A^A^A^X^C
    7. Jul 15 21:58:17 vdr vdr-sxfe[871]: [887] [input_vdr] unknown control message ^C^G^A^A^A^X^C
    8. Jul 15 21:58:17 vdr vdr-sxfe[871]: [887] [input_vdr] vdr_plugin_parse_control(): unknown control ^A

    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:

    Code
    1. Jul 15 12:12:17 vdr vmunix: [ 4.354199] Registered IR keymap rc-dvbsky
    2. Jul 15 12:12:17 vdr vmunix: [ 4.354443] input: cx23885 IR (DVBSky S952) as /devices/pci0000:00/0000:00:1c.0/0000:01:00.0/rc/rc0/input15
    3. Jul 15 12:12:17 vdr vmunix: [ 4.358358] rc rc0: cx23885 IR (DVBSky S952) as /devices/pci0000:00/0000:00:1c.0/0000:01:00.0/rc/rc0
    4. Jul 15 12:12:17 vdr vmunix: [ 4.362521] lirc_dev: IR Remote Control driver registered, major 245
    5. Jul 15 12:12:17 vdr vmunix: [ 4.363148] IR RC5(x/sz) protocol handler initialized
    6. Jul 15 12:12:17 vdr vmunix: [ 4.364703] rc rc0: lirc_dev: driver ir-lirc-codec (cx23885) registered at minor = 0
    7. Jul 15 12:12:17 vdr vmunix: [ 4.364708] IR LIRC bridge handler initialized

    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

    Code
    1. [2020/07/15 07:42:52.536457,  0] ../lib/util/util.c:216(directory_create_or_exist)
    2.   mkdir failed on directory /var/lib/samba/private/msg.sock: Datei oder Verzeichnis nicht gefunden

    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.

    Habe jetzt mal noch ein systemctl mask lircd-uinput ausgeführt, brachte aber außer einem

    Code
    1. Jul 14 16:05:38 vdr vmunix: [ 2.676346] systemd[1]: lircd-uinput.service: Cannot add dependency job, ignoring: Unit lircd-uinput.service is masked.

    im Log keine Änderung nach einem Neustart.

    Ich hoffe, das Maskieren war nicht kontraproduktiv?

    Firmware von DVBSky ist installiert, TV-Bild und Ton sind da, Tastatur-Bedienung klappt auch.


    dmesg meint