Fehler "Keine Ethernetverbindung" während Wiedergabe

Für mich ist das Log zu viel, können andere vielleicht mehr mit anfangen. Klar, Fehler findet man zu smb. Sieht aber auch so aus, als wäre SMB-Signing wieder aktiv. Also ich würde das nochmals sorgfältig prüfen (ich gab den Hinweis, dass auf dem Windows-Rechner nur die Server-Seite ne Rolle spielen sollte, würde aber sicherheitshalber beide genannten Parameter nehmen, also auch Client-Seite). Anfang des Logs fehlt (wo man beispielsweise Cache Einstellungen sehen würde).

Wundere mich bisschen, dass ich überall nur SMB2 sehe. Bei nur leidlich aktuellem Windows, der als SMB-Server arbeitet, würde ich SMBv3.x erwarten. Mag aber sein, dass die "2" sich einfach nur auf das Signing bezieht. Ansonsten, hast du die Parameter verstellt zu SMB in Kodi? (Mag sein, dass das schon diskutiert wurde, aber nach über 2 Wochen Pause ...)

Zu anderen Hinweisen habe ich bislang keine Rückmeldungen gesehen (Reboot, Last auf dem Server).

Zitat von guidegame

Der Fehler passierte ca. bei Uhrzeit 17:02 Uhr.

Frage zum log file:

ist kodi neu gestartet worden ?

denn du hast eine kodi.old.log angehängt. Wenn du NICHT neu gestartet hast, ist das letzte (aktuelle) Log file Kodi.log

Frage zu den Movies:

hast mal den Film genau an der Stelle, an der der auf der Shield abschmiert auf einer anderen Kiste abgespielt.

- nur zum check, ob der Film wirklich als Fehlerquelle ausschliessbar ist -

Leider bin auch nicht der Log file Leser, aber mir fällt dies auf:

2025-01-20 17:02:41.307 T:16690   debug <general>: Thread JobWorker start, auto delete: true
2025-01-20 17:02:41.307 T:16690   debug <general>: [threads] name: 'JobWorker' priority: '-9'
2025-01-20 17:02:41.308 T:15432   debug <general>: Thread FileCache 199368637632 terminating
2025-01-20 17:02:41.312 T:15431   debug <general>: CSMBFile::Close closing fd 10000
2025-01-20 17:02:41.314 T:15431   debug <general>: smb: cli_close failed on smb://USERNAME:PASSWORD@192.168.178.75/Filme%202/Harry%20Potter%20Filmreihe/Harry%20Potter%20und%20der%20Stein%20der%20Weisen%20(2001)/Harry%20Potter%20und%20der%20Stein%20der%20Weisen%20(2001).m2ts. purging server.
2025-01-20 17:02:41.314 T:15431   debug <general>: smb: smbc_error 1 233 (0xe9) -> 32
2025-01-20 17:02:41.314 T:15431   debug <general>: smb: smbc_remove_usused_server: 0x2c1de4dd80 removed.
2025-01-20 17:02:41.314 T:15431   debug <general>: Thread VideoPlayer 199349841088 terminating
2025-01-20 17:02:41.315 T:16690    info <general>: Deleting settings information for files videodb://movies/sets/169/418?setid=169

vlt. hilft es ja (wenn möglich) per ssh auf der shield in einem terminal "journalctl -f" mitlaufen zu lassen.

Das loggt hauptsächlich kernel messages. Vlt. spinnt die Verbindung ja shield-seitig irgendwie ....

Ist das Zeitfenster immer gleich lang, nachdem der Film abgebrochen wird ?

hier [leider mit unvollständigem log] steigt das Teil nach ~18 Minuten aus.

Ich meine irgendwas hämmert dazwischen, obwohl es (wie ich's verstehe) mehrfach smb-technisch einwandfrei funktioniert ...

===

wireshark ?

Zitat von guidegame

Habe dann die beiden Befehle aus #14 wieder umgekehrt, also so eingestellt wie es werksmäßig ist und habe anschließend auch gestern und heute ca. 10 Filme laufen lassen. Auch hier kein Fehler [buers: mit Windows Client].

Es ist für mich nicht klar aus der Formulierung, ob die Fehler im Log mit den Befehlen aus #14 $False oder $True geschah. Dass das einem Windows Client nix ausmacht, ist zu erwarten. Bei einem Linux/Android/... Client kann das anders sein (und ist Bestandteil tausender Diskussionen im Internet, seit MS das für Win 24H2 geändert hat).

In der Tat trat dein Fehler wieder auf, auch beim Deaktivieren von SMB Signing - aber bezieht sich das Log darauf? Möglicherweise gibt es da auch eine Koinzidenz, irgendwas zufälliges, was mal auftrat, und zu falschen Schlüssen führt. Ich habe auch bei Aufnahmen normalerweise keine Fehler, aber hin und wieder ist einer drin. Ist ja schon auffällig, dass zunächst das Deaktivieren des Signing zu helfen schien und dass es halt die zeitliche Korrelation mit 24H2 gibt.

In den Logausschnitten, die ich sah, waren jedenfalls immer Fehler zu SMB drin. Ich sehe allerdings nicht, das typische Muster, wenn die Bandbreite nicht ausreicht.

Was die Größe der Anhänge angeht: kenne das Limit nicht, aber bequemer für Leser ist paste.kodi.tv. Besser als Anfang Wegschneiden bei so einem Problem: Sagen wir Kodi startet um 15:00, Film startet um 15:03, Fehler tritt 16:00 auf, dann wird Kodi beendet. Wenn File zu groß, am besten die Zeilen zwischen 15:05 und 15:55 löschen.

Scheint du hast Komponenten-spezifisches Debug-Logging eingeschaltet? Falls ja - jedenfalls für mich bringt FFMPEG-Bibliothek für dieses Problem nix (und das scheint an zu sein?). SMB mag hier was bringen. Du wurdest (nicht von mir ...) nach Debug-Log gefragt. Konvention hier im Forum ist bei solchen Anfragen, dass wenn nicht explizit gefordert, die bei der komponenten-spezifische Protokollierung normalerweise alles auf aus ist. Das kann die Länge (und Lesbarkeit) des Logs extrem beeinflussen.

EDIT: Wenn Debug-Logging an ist, sieht man CPU-Auslastung des Systems. Hast du mal darauf geachtet? War die hoch und evt. sogar besonders hoch, als das Problem auftrat? Ggf. wäre es auch interessant zu beobachten, ob CPU-Auslastung sich signifikant ändert, abhängig von der SMB-Signing-Einstellung.

Zitat von guidegame

Nur die Shield macht das Problem.

na dann:

die Shield kann doch Streaming.

was hält dich ab dort mal ein paar Filme zu sehen.

wenn die dabei auch abbricht, dann ist's die Shield...

wenn's aber mit Win10 und der Shield geht, ist's wahrscheinlich doch nicht die Shield...

warum bleibst du dann nicht bis Okt. bei win10. Win11 scheint ja noch ein paar Baustellen zu haben, wie ich so lese ...

===

habe gestern mal in der Samba-Fehler-DB und im INet gesucht: peanuts !

der Fehler scheint schwierig, weil es kein Muster gibt, den zu re-produzieren.

ein ding das zu naglen wäre wireshark oder - sofern möglich (mache nix mit freigaben oder habe keine shield) - die log-file-Stärke beidseitig zu erhöhen.

Bei herkömmlichem Samba (Linux) kann man dran drehen, bei Win habe ich keine Ahnung (bis auf die umfangreicheren windows Log Files [siehe screenshots von einem Win10];

erreichbar via: im Dateiexplorer: Rechtsklick auf "Dieser PC" => Verwalten => dann links durchhangeln zu den Logs.

TIP: vlt. die Logfiles mit Rechsklick vorm Test löschen; siehe screenshot_2