Client VDR, CIFS Mount und Kernel > 4.19.y

  • Hallo zusammen,


    ich brauche mal eine Idee zur Fehlersuche:

    Ich betreibe hier einen Haupt-VDR (2.4.x) auf x64 sowohl als Hauptsystem, als auch Streamdev-Server (und Samba 4.9.5).

    Als Client ein RPi2 mit ebenso VDR-2.4.x. Dessen Video-Verzeichnis zeigt per CIFS-Mount auf das Video-Verzeichnis des Haupt-VDRs.

    (Samba wegen Widelinks auf einen Windows-Server).


    Bisher lief der Haupt-VDR unter Kernel 4.19.y. Der RPi2 (dort Kernel egal) kann das Video-Verzeichnis bei Start mounten, die Aufnahmen abrufen und abspielen oder Live-TV zeigen. Läuft so schon Jahre problemfrei...


    Da nun immer wieder unpassende Patche in die LTS Kernel wanderten, habe ich den Server mal auf den aktuellen Stable 5.7.y aktualisiert.

    "Natürlich" hat ein Vollhonk (per "media: smipcie: add universal ir capability" Commit a49a7a4635dea5b799a8f77e227ef5c648fa29ec) die Fernbedienung zerlegt ( doppelte / falsche / gar keine Tasten) - aber das ist ja schnell reverted.


    Nur mag der RPi2-VDR das Video-Verzeichnis des SAMBA 4.9.5 (debian buster) mit diesem Kernel nicht mehr einlesen:

    Code
    Aug  2 18:12:13 sara vmunix: [  861.421148] CIFS VFS: \\roadrunner No task to wake, unknown frame received! NumMids 4
    Aug  2 18:12:13 sara vmunix: [  861.429402] 00000000: 424d53fe 00000040 00000000 00000012  .SMB@...........
    Aug  2 18:12:13 sara vmunix: [  861.429427] 00000010: 00000001 00000000 ffffffff ffffffff  ................
    Aug  2 18:12:13 sara vmunix: [  861.429446] 00000020: 00000000 00000000 00000000 00000000  ................
    Aug  2 18:12:13 sara vmunix: [  861.429465] 00000030: 00000000 00000000 00000000 00000000  ................
    Aug  2 18:12:13 sara vdr: epg2vdr: Updating recording list table
    Aug  2 18:12:14 sara vdr: [2535] max. latency time 39 seconds


    Läuft der VDR auf dem RPi, kann man auch per SSH / MC nur mit 28 sec Delay pro Verzeichnis auf das gemountete Verzeichnis zugreifen. Stoppt man den VDR funktioniert der CIFS-Mount wieder "normal".


    Stelle ich den Server temporär auf 4.19.y zurück, starte den Pi neu, lasse ihn die Aufnahmen (>3k) einlesen, reboote den Server wieder auf Kernel 5.7.y ist der Pi bis zum nächsten Neustart zufrieden. Inklusive Aufnahmen... :wow

    Was zum Teufel könnte das sein (CIFS-Mount ist in beiden Fällen mit smb 3.1.1 aktiv)?


    Stefan

  • Ich würde das Logging für Samba aufdrehen und es mal nur mit IP-Adressen anstelle des Hostnamens versuchen.

    Ansonst mit "sec=ntlmssp, vers=3.1.1" versuchen.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!