Immer wieder Freeze der Raspis 3B+ mit AMP2 und M2P

[sugarcube premium]

sugarcube premium

10. Juli 2020 at 17:00 #49279

Hi alle,

ich habe vier Bundles mit Raspis und der AMP2 Soundkarte installiert. Alle sind mit Kühlkörpern ausgestattet. Die drei Raspis, auf denen der Squeezeboxserver nicht läuft, hängen sich leider immer wieder auf. Das passiert ca. 1-2 Mal die Woche. Zu bemerken ist es natürlich daran, dass die Einheiten nicht mehr in der Liste der Geräte aufgeführt werden und bei synchronisierten Geräten ausfallen. Auch ein Ping auf die Geräte ist dann nicht mehr möglich.
Dabei ist es unerheblich, ob die Geräte gerade in Verwendung waren oder nicht. Zunächst bin ich von einem Hitzeproblem ausgegangen, und deshalb habe ich Kühlkörper angebracht. Dazu passt aber nicht, dass der Server-Raspi, der am meisten leisten muss, nie ausfällt.
Die Temperaturen liegen bei allen Geräten übrigens bei ca. 54°C und damit im moderaten Bereich.
Meine Frage ist nun, ob hier jemand eine ähnliche Erfahrung gemacht hat und wie ich eine Lösung für dieses Problem finden kann. Die Raspis sind teilweise nicht leicht zugänglich, so dass es lästig ist, wenn mann periodisch „den Stecker ziehen“ muss.

Ich kann gerne Logs und weitere Daten liefern. Mir fehlt aber der richtige „Griff“ an der Sache.

[MarioM Moderator]

MarioM Moderator

14. Juli 2020 at 13:17 #49299

Hallo sugarcube,

Wie hast du deine Geräte mit dem Internet verbunden? Falls sie per WLAN verbunden sind, könnte das zu Problemen führen. Ansonsten könnte uns evtl. die Log-Datei des Squeezebox Servers helfen, kurz nachdem die Player ausgefallen sind. Auch die Audioplayer Debug Info von den betroffenen Playern könnte hilfreich sein.

[sugarcube premium]

sugarcube premium

14. Juli 2020 at 14:10 #49305

Hallo Mario,
Ok, die fraglichen Raspis sind alle per WLan angeschlossen und da gibt es auch keine Alternative. Ich habe weitere Raspis, die alle per WLan angeschlossen sind und problemlos durchlaufen (einer z.B. mit OSMC-Kodi). Ist das ein spezielles M2P-Problem oder geht es um allgemeine Bedingungen?
Gerade eben ist ein Player wieder Offline (taucht nicht in der Liste der Player auf, kein ping möglich, ergo auch kein Shutdown per ssh->unschön). Er war übrigens nicht in Verwendung, als er offline ging.
Das Serverlog habe ich gesichert. Wie soll ich es dir denn senden? Dann auch: Wo finde ich das Debug-Log des fraglichen Players?

[MarioM Moderator]

MarioM Moderator

14. Juli 2020 at 14:38 #49307

Hallo sugarcube,

Am besten du schickst uns die Logs per Mail an [email protected] mit einer kurzen Beschreibung deines Problems und ggf. einem Verweis auf diesen Forenbeitrag. Den Debug Log des Player findest du im Webinterface des Player auf der Seite Audioplayer ganz unten.

Hier noch ein paar Fragen, um das Problem weiter einzugrenzen:

– Welche Pis verwendest du? Welche Images (Jezzy, Stretch, Buster) hast du installiert und welche Max2Play Version läuft auf den Pis (Server und Player)?
– Hast du schon versucht das Image auf eine andere neue SD-Karte zu brennen und eines deiner Geräte darüber laufen zu lassen? Du kannst ein Backup deines aktuellen Images mit unserem Imageburner Plugin erstellen.
– Sind die SD-Karten alle Class 10 oder höher?
– Zeigt der Health Checker auf der Einstellungen/Reboot Seite eine Überlastung an?

[sugarcube premium]

sugarcube premium

17. September 2020 at 11:39 #49724

So, um dieses Thema zu schließen poste ich für die Nachwelt mal den aktuellen Status:

Das vom Support angeratene Aufspielen der Beta-Version hat nicht den gewünschten Erfolg gebracht. Leider verabschiedeten sich die Raspis immer noch aus dem Netzwerk.

Ich habe mir dann ein Script geschrieben, das per cron alle 5 Minuten aufgerufen wird, und ein Ziel in meinem Wlan anpingt. Dabei war meine Vermutung, dass das Problem damit zusammenhängt, dass der Raspi sich irgendwie bei der Wlan-Connection verschluckt, und dadurch weder aus- noch eingehender Traffic bedient werden kann. Weil mir die Zeit fehlt, dem Problem intensiv auf den Grund zu gehen, bin ich ums Problem herumgelaufen und damit auch erfolgreich gewesen.

Das Script versucht die Außenwelt zu erreichen, und wenn das geht, beendet es sich. Falls es aber mehrfach innerhalb von einigen Sekunden keinen Ping durchbekommt, startet es erst das Wlan neu. Hilft das nicht, startet es den Raspi neu.
Dadurch hat sich das Verhalten der Raspis verändert. Ich habe innerhalb von vier Wochen keine Drop-outs mehr gehabt. Alle Raspis sind zuverlässig ansprechbar. Dabei zeigen die Logs aber sehr wohl mehrere Fehlversuche beim Pingen und auch einen Neustart.
Für mich ist das „good enough“.