Sonos steuern

Elektrolurch · 31 Mai 2017, 10:38:37

Hallo Reinerlein,

manchmal finde ich sowas im Log und jetzt habe ich mal stacktrace eingeschaltet. Das scheint bevorzugt aufzutreten, wenn das Gerät frisch am Strom eingeschaltet wird:

2017.05.31 08:35:45 1: readingsUpdate(Sonos_Wohnzimmer,currentTrackPosition,0:00:00) missed to call readingsBeginUpdate first.
2017.05.31 08:35:45 1: stacktrace:
2017.05.31 08:35:45 1: main::readingsBulkUpdate called by ./FHEM/00_SONOS.pm (1252)
2017.05.31 08:35:45 1: main::SONOS_Read called by fhem.pl (3412)
2017.05.31 08:35:45 1: main::CallFn called by fhem.pl (686)
2017.05.31 08:35:45 1: readingsUpdate(Sonos_Wohnzimmer,currentTrackPositionSec,1) missed to call readingsBeginUpdate first.
2017.05.31 08:35:45 1: stacktrace:
2017.05.31 08:35:45 1: main::readingsBulkUpdate called by ./FHEM/00_SONOS.pm (1252)
2017.05.31 08:35:45 1: main::SONOS_Read called by fhem.pl (3412)
2017.05.31 08:35:45 1: main::CallFn called by fhem.pl (686)
2017.05.31 08:35:45 1: readingsUpdate(Sonos_Wohnzimmer,numberOfTracks,3) missed to call readingsBeginUpdate first.
2017.05.31 08:35:45 1: stacktrace:
2017.05.31 08:35:46 1: main::readingsBulkUpdate called by ./FHEM/00_SONOS.pm (9289)
2017.05.31 08:35:46 1: main::SONOS_readingsBulkUpdateIfChanged called by ./FHEM/00_SONOS.pm (1265)
2017.05.31 08:35:46 1: main::SONOS_Read called by fhem.pl (3412)
2017.05.31 08:35:46 1: main::CallFn called by fhem.pl (686)
2017.05.31 08:35:46 1: readingsUpdate(Sonos_Wohnzimmer,currentStreamAudio,1) missed to call readingsBeginUpdate first.
2017.05.31 08:35:46 1: stacktrace:
2017.05.31 08:35:46 1: main::readingsBulkUpdate called by ./FHEM/00_SONOS.pm (9289)
2017.05.31 08:35:46 1: main::SONOS_readingsBulkUpdateIfChanged called by ./FHEM/00_SONOS.pm (1265)
2017.05.31 08:35:46 1: main::SONOS_Read called by fhem.pl (3412)
2017.05.31 08:35:46 1: main::CallFn called by fhem.pl (686)
2017.05.31 08:35:46 1: readingsUpdate(Sonos_Wohnzimmer,currentNormalAudio,) missed to call readingsBeginUpdate first.
2017.05.31 08:35:46 1: stacktrace:
2017.05.31 08:35:46 1: main::readingsBulkUpdate called by ./FHEM/00_SONOS.pm (9289)
2017.05.31 08:35:46 1: main::SONOS_readingsBulkUpdateIfChanged called by ./FHEM/00_SONOS.pm (1265)
2017.05.31 08:35:46 1: main::SONOS_Read called by fhem.pl (3412)
2017.05.31 08:35:46 1: main::CallFn called by fhem.pl (686)

Gruß

Elektrolurch

Phiolin · 01 Juni 2017, 22:25:45

Heute mal wieder abgestürzt, leider aber trotz verbose 5 keine interessanten Meldungen im Logfile:

Code Auswählen

2017.06.01 15:43:21 3: SONOS0: Connection accepted from localhost:45974
2017.06.01 15:43:21 4: SONOS0: Got correct answer from Subprocess...
2017.06.01 15:43:51 3: SONOS0: Connection accepted from localhost:45996
2017.06.01 15:43:51 4: SONOS0: Got correct answer from Subprocess...
Can't call method "kill" on an undefined value at ./FHEM/00_SONOS.pm line 9730, <$client> line 3.

Meistens ist es so, dass der Prozess an einem Tag abstürzt, wo auch ein FHEM Restart gemacht wurde, meistens auch relativ zeitnah (heute knapp 30 Minuten nach dem restart). Wenn der FHEM Prozess erst mal längere Zeit läuft, stürzt das Modul scheinbar auch nicht mehr ab.

Werde das morgen noch mal versuchen zu reproduzieren und dabei auch global verbose auf 5 setzen.

Tobias · 02 Juni 2017, 15:23:05

Hi,
ich habe heute ein FHEM Update gemacht und seitdem generiert das "mute" kein Event mehr
Das LastActionResult wird noch als event mit "SetMute: off" gesetzt, aber "Mute" generiert selbst kein Event mehr.
Folge ist, das die Rückmeldung ins TableUI ausbleibt

Das Attribut generateVolumeEvent ist auf 1 gesetzt

Reinerlein · 02 Juni 2017, 15:54:41

Hi Tobias,

ist denn auch eines der Attribute "minVolume", "maxVolume", "minVolumeHeadphone" oder "maxVolumeHeadphone" gesetzt?

Grüße
Reiner

Tobias · 02 Juni 2017, 15:58:57

minVolume ist auf 0 gesetzt

Phiolin · 04 Juni 2017, 12:07:07

Heute mal wieder ein Update & Restart gemacht, prompt ist der SONOS Prozess nicht mal 2 Stunden später auch wieder abgestürzt.

Leider trotz verbose 5 im SONOS und im Global Device keine wirklich spannenden Meldungen im Logfile, so dass ich jetzt hier auch erst mal ausgezählt bin. Vermutlich kommen wir hier ohne das generieren weiterer Debug-Meldungen nicht viel weiter...

Einziger Anhaltspunkt, in den 2-3 Sekunden vor dem Fehler im Log sind einige Blocking-Calls vom TRAFFIC Modul im Log... aber ob da ein Zusammenhang besteht...?

Code Auswählen

2017.06.04 11:42:51 4: Connection accepted from telnetPort_127.0.0.1_47450
2017.06.04 11:42:51 5: Cmd: >{BlockingStart('68')}<
2017.06.04 11:42:51 5: Cmd: >{TRAFFIC_FinishUpdate('traffic;;;normal;;;{"READINGS":{"status":"OK","duration_in_traffic_min":28,"duration
_in_traffic":"28 mins","duration_min":31,"eta":"12:10:57","duration":"31 mins","delay_min":0,"state":"OK","delay":"0 min","distance":"33.9 km"},"HEL
PER":{"GoogleMapsCenter":"51.5659077,6.9934656","Poly":"fW12eUhlfHRpQG9CakF4QHhFVHBBTm5Ab0ZsQntAQlBkQGZAakFsQG5BfEBiQn5AdEF8QGhBYEBg\nQGBBckB0QGBAdk
BWakBIbEFCfkFNbEZrQHhGbUB4QEFqQEpoQFBgRH5BbkF2QHRBZEF0QXJBfERi\nRmBBZkF4QHhATlxYWGpAakBWUmBEakJyR3JER35BSXJCR35ASVhNUlVOU0JZRU1LTVNbX0FrQWNM\nZ0BrRm
FAfUNLXUlVbUBlSW1BZ1JrQ2VhQGtDfWBAa0BvSlN5RFVfRk9xRlNzTD9tSEBxRU5vSlxp\nTHxDa3lAUnlJRHFDQGNFP3tES2dHX0B1S2NHY2hBX0F7UG1CaV1nQ3NfQHtAfUxtQmVYc0B5SV9A
\ne0RtQHtFdUFfSnVCX01rRGlTcUFvR29JeV9AfUZ9V2VFbVJlQW9GX0F3RmdAb0RnQGlFa0B1RmdA\nd0dZfUVbX0lFd0NJeUZBcUZOZ11Sd15CZU1Bc0NJb0ZLZUVZaUhhQHNHc0BjSWdCa09v
TF9lQW1D\nbVVhQGtEWWtEbUBnSV9AeUhRb0hHYUpfQXNsQE93R01tRVFnRWdAYUlZZ0RzQHlHd0BhR3tAcUZ7\nQXFJcUV1VmlDZU9hQm1KV31Dd0FtSWlEZVJnRW9WbUJ5S1VlREVxQT9rQkhl
QU51QXRAa0VYbUFY\neUBkQHlAakB3QF5dXFVwQF9AakFjQFJRWEt6QFlaS1RZekBTdkhhQnJHdUF6Tn1DYkV5QGBEZUBy\nRm1AYENPdERPbklLYklHekZNfENPYEVfQGBEY0B2QmFAfkdhQmpC
aUBiSWNDZkdnQmpDc0B4R3dB\nakVzQGxDXWBNe0F0RntAckNpQGRFZUFiRGdBZkJzQGpCe0B0QmlBbENhQnxAbUBoRWdEfkJxQmxB\na0FmQmtCbEJxQmBHYUdmRHdDakRfQ25EZ0J8QW1AakN3
QHhBX0B0Ql1gQ1l8QlF+QUluTVVqSU1i\nRVFwQ1NiRGFAfEFVeENtQH5EY0F4Q2FBfENpQXZDb0FsSntEdEt3RXREb0JsQXVAckJfQmxBa0Fm\nQnVCfkBzQXxBY0N8QXdDZEJhRWhBY0RwQXtF
ekBxRHBBeUdwQXFJfkBpSHxIY25AaEF5SWhJfW9A\nZENxUmhCYU5yQHlFYkBrRGhBbUhuQHtEekJjTVJfQGBCcUhsQGFDTFNOZ0BmQG1BXG1AWFluQGFA\nYEBNYkFJYEBPTE1QV1BtQERvQEFn
QkF7QEZTRlVIT05ZXkVwQEduQEl4QUl6QURkQEhqQExyQVxg\nQWRAYkF0QHhBekFsQ3JEXFpwQnJBbEBcdEFiQGhASmZARGxAQGBARW5EZUBoQUFkQUxiQlxsR3RE\ndEF4QGZCfEBgQVxsQVRq
QUxiQUJ+QEFiQ1d4RGtAdERzQHJAT2xDZUB0QFVwQltqRntAfEdxQWZE\ncUBkSGNCclBzRWRFYUFwQ2dAbkJbYEFPdkFJfEBHXD9OTFxKUEZoQGBAXmxAWHJAXGJBXGhAXlpo\nQFBqQEpaQkVo
Q1FuSkV8RD9iUERmRER2QVh8Q1JkQ1R0RkRwQT9kQ0VyQUtmQVdqQmtAdkJ5QWZG\nd0BwQ31AdEJbYkFdYkJDeEBpQHBCbUFqRXdAdENRWFduQFNuQGtAbkJ3QHhDY0ByQmtAdEJzQX5F\nb0B0
QlN8QFd4QUNkQUlqQF9DaFBPbEA=\n"}}')}<
2017.06.04 11:42:51 4: Connection accepted from telnetPort_127.0.0.1_47452
2017.06.04 11:42:51 5: Cmd: >{BlockingStart('69')}<
2017.06.04 11:42:51 5: Cmd: >{TRAFFIC_FinishUpdate('traffic;;;return;;;{"HELPER":{"Poly":"eWRleUhhe2JrQE5tQG5BfUloQHdETHdATF1MV1RnQW5AZU
N5RGFEc0F9QGdCeUBrRXFBfUZrQV9E\neUBRRWlATXdEX0FtQGRGUWxAYUBqQGNAXmlASF1BVUlTR29AZUB5QnNCT1FhQ2FHYUtoSHlDbEJd\nQnNAYEBhRGxDX0BYYUB2QEdFV0hVVEVQP0hTQl
NCfUBcbUBKY0FDd0FVcUBDaUBEc0RyQXlCdkBj\nQEpXS2tAUWtAYUBpQGFBW3NBSW1CSF9DTG1CQWlBQndEQ3FCT2dDb0B7RnFAZUVlQGFFYUBtRktf\nREVtRUZxRV5zSWRAc0h6QHdQUHlJRG
tHRWVIRXtDWWVJW3lGcUBlSXVAY0hzQGdHW2lDQGtARWlA\ndUB9SWtAbUh9QHlPYUBtTUJnQD9ZP29ASHdAUG9AVmNAUEtWS1ZBVkZiQFxadEBKeEA/bEBFZkBN\nakBPXllgQFdcR1RjQ2ZEbU
B6QHdCZERnRHRGcUFgQ2FGfEpvRGRJdUB+Qkt2QGNCbkVxRG5LZUJ4\nRmFCYEdpRHZOc0FqR2NDbk1nRGBUZ0ZmX0BxS3h6QGlJcm9AZUN0Um9BdElrQnpKeUBwRHNAZkNh\nQGpBX0JuRXtAbE
JxQmJFfUFgQ2dCeEJnQWxBX0ZuRHdFbkNlQ2hBd0xiRnVFbkJ9R2pDcUV0QX1E\nfkBfRnhAb0NWfUhmQHtJTn1FQG9HVHVCTnlFZEB5Rm5Ba0JsQHVEYEJhQWZAaUNkQmFFZERxRGxE\nY0NqQ1
9EZERhRHxDYUVoRG1FeEN7Qm5BeUFyQHVEfEFhRnxBcUVgQWFHYEFfR3RAX0dyQGNEYEB9\nR2hBYURyQGFDbkBvRGJBb0xuRGNDdEB9RWxBeUZiQXdGaEBrQ05nS1BrSkhtRERlRVB5R2pAZUZy
\nQHNFekBxTnpDZ01uQ3VATltDW0BtQ2BAdUFSZ0FWY0NoQF9KakJ1QmRAdUBOa0BMZUFJZ0BTWV1L\nXUtrQD91QEJlQExpQFJbVlVkQEleSGBAYkBaekBIXn5AeElqQWBKYkNmT2xDfk5oRmpa
ZkFmR3BA\nbENkQHhCWmZCakBgQ3ZDdlBuSHRhQH5CdE10QXRKfkBkSnpAZk1cZkpwQGBgQFpuVEJ4R0JwQUJu\nQVh6SWhAbEpiQG5GbkRuW2xDeFV4SGhxQGZCcE9qQHBHZEB0SFRmRkxqRkhw
RkB+Q0VkTk1+VEtg\nVUlqUEJoR1BqSmhAZk14QHZLZEBuRWpAfkV6QHpGekB6RXZBfkdqQnBJYkdoWG5LbGZAdEFkSGJE\nbFJsQmBMcEFsSWZBdkpiQHxFbEFyUWpFYm5AZkR8bEBuSGZ0QVpm
SUxsR0JyRkVwR1FySWlEeH5A\nW25NS3BNRHZNVnhMbEB+TWBCcldqRmx4QHJBblN8QGpMYkFqS3pBck5AYENDbkBLYkBbZEBVSmFA\nRltTT1VRZ0BLdUB1QHdLdUB7S0JPQFVCUVBpQEhhQFlR
aUBhQF1ZVUddXXVAd0B3QWVCdURxRVdX\nc0FnQWVBc0BjRXVCaUBRa0BLeUBAd0FOb0toQV9CTGFAP3dBTXdAV1VNYUJnQV9Ca0JfQXVBfUBj\nQm1Ab0FPWUJpQERfQEZRbkZtQk9vQFVxQXlA
eUVuQmtB\n","GoogleMapsCenter":"51.4774144,7.2288135"},"READINGS":{"state":"OK","delay_min":0,"duration":"29 mins","distance":"35.9 km","delay":"0 m
in","duration_min":29,"duration_in_traffic_min":28,"duration_in_traffic":"28 mins","status":"OK","eta":"12:11:03"}}')}<
Can't call method "kill" on an undefined value at ./FHEM/00_SONOS.pm line 9730, <$client> line 3.

Vielleicht einfacher, wenn man hier um die passende Zeile herum einen entsprechenden Check einbaut und den SONOS Prozess neu startet?
Wenn ich den Prozess jetzt über disable/enable neu starte, läuft er mit hoher Wahrscheinlichkeit wieder tagelang problemlos durch, zumindest bis zum nächsten FHEM restart.

Hattest du übrigens schon Gelegenheit, den Workaround/Fix für die wide-character Problematik bei der Hash Generierung einzubauen?

Reinerlein · 04 Juni 2017, 14:17:30

Hi Phiolin,

das kann schon sein. ich habe mal gerade mein Fhem mit einem "{ sleep(45) }" als Kommando blockiert, und eine Playerwiedergabe mit dem Controller gestartet.
Das Ergebnis war überhaupt nicht erfreulich... Mein Fhem war (nach den 45 Sekunden) nicht mehr über die Wenoberfläche erreichbar.

Wohl eine Mischung aus: der Subprozess wird seine Daten irgendwie nicht los, und in der Datenschlange auf Fhem-Seite lungern dann plötzlich Pakete, die nicht mehr sauber zugestellt werden...

Ich weiß noch überhaupt nicht, wie ich das in den Griff bekommen kann.
Bei dir vermute ich mal, dass dein Traffic irgendwann nach einem Neustart besonders viel Laden möchte, und du nach einem Neustart auch zuhause bist, und natürlich auch gerade Musik hörst

Ein Zusammenkommen mehrere (unglücklicher?) Umstände sozusagen

Das andere ist schon drin, da ich aber noch gerade eine andere Baustelle offen habe, kann ich es noch nicht einchecken...

Grüße
Reiner

Phiolin · 05 Juni 2017, 18:35:15

Ich behelfe mir jetzt erst mal damit, dass ich alle paar Minuten via Cron schaue ob der 00_SONOS.pm Prozess noch läuft. Gegebenenfalls switched das Script dann über den telnet Port mal eben kurz das Device auf disabled/enabled, damit der Prozess neu gestartet wird.

Fixel2012 · 05 Juni 2017, 19:10:38

Zitat von: Phiolin am 05 Juni 2017, 18:35:15
Ich behelfe mir jetzt erst mal damit, dass ich alle paar Minuten via Cron schaue ob der 00_SONOS.pm Prozess noch läuft. Gegebenenfalls switched das Script dann über den telnet Port mal eben kurz das Device auf disabled/enabled, damit der Prozess neu gestartet wird.

Nette Idee, wärst du so nett und stellst den Cron Zeiler hier für die Allgemeinheit zur Verfügung?

habe letze Woche verschlafen weil der Sonos Prozess abgestürzt ist, dies sollte damit dann nicht mehr vorkommen!

Dankende Grüße,

Fixel

Phiolin · 06 Juni 2017, 08:23:51

Crontab Eintrag, prüft alle 10 Minuten:

Code Auswählen

*/10 * * * * /opt/fhem/check_sonos.sh

Dazugehöriges bash Script:

Code Auswählen

#!/bin/bash
ps aux|grep [0]0_SONOS.pm > /dev/null
if [ $? -gt 0 ]
then
  echo attr Sonos disable|telnet localhost 7072
  sleep 5
  echo deleteattr Sonos disable|telnet localhost 7072
fi

Ist recht simpel gehalten. Funktionierte bei meinem Test problemlos, also schnell mal den 00_SONOS.pm Prozess gekillt und gewartet was passiert. Prozess wird dann bei der nächsten Ausführung über cron neu gestartet.
Wichtig ist hier nur, dass das Script auf dem FHEM Server ausgeführt wird, ansonsten muss das telnet Kommando entsprechend angepasst werden.

Eventuell muss der Name des Sonos Devices angepasst werden, das Script geht davon aus, dass das Device in FHEM "Sonos" heißt.

Phiolin · 07 Juni 2017, 07:26:37

Meine Probleme werden offenbar schlimmer. Heute Nacht ist der SONOS Thread gut ein Dutzend mal verstorben, und das obwohl Nachts praktisch auf der FHEM Installation nichts los ist - klar, wir schlafen halt.

Die gute Nachricht ist, dass mein Auto-Restart Script zumindest funktioniert, aber eine endgültige Lösung scheint mir das noch nicht zu sein.

Ich werde jetzt zuerst mal das "reuseport" Setting ausprobieren. Vielleicht gehe ich auch mal zurück auf die SONOS Modul Version von vor dem 15. Mai, da ich mich nicht erinnern kann, dass ich diese Probleme in dem Ausmaß schon immer hatte. Eigentlich lief das Modul mal sehr stabil und zuverlässig.

Ein paar neue Fehlermeldungen aus dem Log habe ich auch noch:

Code Auswählen

2017.06.06 23:26:18 3: SONOS1: Start temporary playing of "\\10.0.0.107\SonosSpeak/RINCON_949F3E85047601400_MR_Speak_e5809200b92a0d0aed129afec9fbc948
3cf00abe.mp3"
2017.06.06 23:26:18 2: SONOS1: Error during UPnP-Handling: Can't use an undefined value as an ARRAY reference at ./FHEM/00_SONOS.pm line 2400.

2017.06.06 23:26:19 3: SONOS1: UPnP-Thread wurde beendet.

Code Auswählen

2017.06.06 23:50:19 3: SONOS0: Connection accepted from localhost:45956
Can't call method "kill" on an undefined value at ./FHEM/00_SONOS.pm line 9730, <$client> line 46.
Perl exited with active threads:
        2 running and unjoined
        1 finished and unjoined
        0 running and detached

Code Auswählen

2017.06.06 05:57:03 5: SONOSPLAYER0: Notify: transportState: STOPPED
2017.06.06 05:57:03 5: SONOS0: Player: Sonos_Schlafzimmer ~ Slaves: []
Use of uninitialized value in numeric gt (>) at ./FHEM/00_SONOS.pm line 5041, <$client> line 4.
Use of uninitialized value $location in concatenation (.) or string at FHEM/lib/UPnP/ControlPoint.pm line 325, <$client> line 4.
400-URL-Absolute-Error! Location: "", Content: "400 URL missing
" at ./FHEM/00_SONOS.pm line 5047 thread 6.
Use of uninitialized value $location in concatenation (.) or string at FHEM/lib/UPnP/ControlPoint.pm line 326, <$client> line 4.
Loading device description failed with error: 400 URL missing (Location: ) at ./FHEM/00_SONOS.pm line 5047 thread 6.
Thread 6 terminated abnormally: Can't call method "children" on an undefined value at ./FHEM/00_SONOS.pm line 5051, <$client> line 4.
2017.06.06 05:57:04 5: SONOSPLAYER0: Notify: transportState: ERROR

Code Auswählen

2017.06.05 22:48:10 3: SONOS7: Event: End of Transport-Event for Zone "Sonos_Schlafzimmer".
2017.06.05 22:48:11 5: SONOS0: Player: Sonos_Schlafzimmer ~ Slaves: []
2017.06.05 22:48:11 5: SONOS0: Player: Sonos_Schlafzimmer ~ Slaves: []
2017.06.05 22:48:11 5: SONOS0: Player: Sonos_Schlafzimmer ~ Slaves: []
2017.06.05 22:48:11 5: SONOS0: Player: Sonos_Schlafzimmer ~ Slaves: []
2017.06.05 22:48:11 5: SONOS0: Player: Sonos_Schlafzimmer ~ Slaves: []
Use of uninitialized value in numeric gt (>) at ./FHEM/00_SONOS.pm line 5041, <$client> line 4.
2017.06.05 22:48:13 3: SONOS6: Restorethread has found a job. Waiting for stop playing...
2017.06.05 22:48:14 3: SONOS6: Restoring playerstate...
Use of uninitialized value $old{"CurrentURI"} in concatenation (.) or string at ./FHEM/00_SONOS.pm line 5075, <$client> line 4.
Use of uninitialized value $old{"CurrentURI"} in pattern match (m//) at ./FHEM/00_SONOS.pm line 5077, <$client> line 4.
2017.06.05 22:48:14 3: SONOS1: Event: Received Transport-Event for Zone "Sonos_Schlafzimmer".
2017.06.05 22:48:14 3: SONOS4: Event: Received Transport-Event for Zone "Sonos_Schlafzimmer".
2017.06.05 22:48:14 3: SONOS6: Playerstate restored!
2017.06.05 22:48:14 3: SONOS7: Event: Received Transport-Event for Zone "Sonos_Schlafzimmer".
Use of uninitialized value $trackProviderRoundURL in concatenation (.) or string at ./FHEM/00_SONOS.pm line 6951, <$client> line 4.
Use of uninitialized value $trackProviderQuadraticURL in concatenation (.) or string at ./FHEM/00_SONOS.pm line 6952, <$client> line 4.
Use of uninitialized value $trackProviderRoundURL in concatenation (.) or string at ./FHEM/00_SONOS.pm line 6951, <$client> line 4.
Use of uninitialized value $trackProviderQuadraticURL in concatenation (.) or string at ./FHEM/00_SONOS.pm line 6952, <$client> line 4.
Use of uninitialized value $trackProviderRoundURL in concatenation (.) or string at ./FHEM/00_SONOS.pm line 6979, <$client> line 4.
Use of uninitialized value $trackProviderQuadraticURL in concatenation (.) or string at ./FHEM/00_SONOS.pm line 6980, <$client> line 4.
Use of uninitialized value $trackProviderRoundURL in concatenation (.) or string at ./FHEM/00_SONOS.pm line 6979, <$client> line 4.
Use of uninitialized value $trackProviderQuadraticURL in concatenation (.) or string at ./FHEM/00_SONOS.pm line 6980, <$client> line 4.
Use of uninitialized value $trackProviderRoundURL in concatenation (.) or string at ./FHEM/00_SONOS.pm line 6951, <$client> line 4.
Use of uninitialized value $trackProviderQuadraticURL in concatenation (.) or string at ./FHEM/00_SONOS.pm line 6952, <$client> line 4.
Use of uninitialized value $trackProviderRoundURL in concatenation (.) or string at ./FHEM/00_SONOS.pm line 6979, <$client> line 4.
Use of uninitialized value $trackProviderQuadraticURL in concatenation (.) or string at ./FHEM/00_SONOS.pm line 6980, <$client> line 4.
2017.06.05 22:48:14 3: SONOS4: Event: End of Transport-Event for Zone "Sonos_Schlafzimmer".
2017.06.05 22:48:14 3: SONOS1: Event: End of Transport-Event for Zone "Sonos_Schlafzimmer".
2017.06.05 22:48:14 3: SONOS7: Event: End of Transport-Event for Zone "Sonos_Schlafzimmer".

Update: Gerade ein FHEM update gemacht und danach den RasPi rebooted. 3 Minuten nach dem FHEM Start stürzt das SONOS Modul wieder ab.
Habe jetzt nur die 00_SONOS.pm zurück auf die Version aus rev 13952 vom 9. April gedreht. Mal gucken ob die ältere Version wieder stabil läuft.

Hotbird · 09 Juni 2017, 10:58:41

wie schließe ich das Sonos Modul eigentlich komplett aus nem update raus. Hab grad nen altes Backup auf meine Karte gespielt und will natürlich die anderen Module updaten.

Nach
attr global exclude_from_update 21_SONOSPLAYER.pm

und einem update ist FHEM abgestürzt. Muss ich auch noch die 00_Sonos.pm excludieren?

// geht übrigens so

attr global exclude_from_update 21_SONOSPLAYER.pm 00_SONOS.pm

dann werden beide von Update in Ruhe gelassen

JoWiemann · 09 Juni 2017, 12:52:12

Soweit ich weiß, ja, alle abhängigen Module. Und, ich bin mir nicht sicher, ob wild Cards gehen. Also SONOS.*.pm.

Grüße Jörg

Phiolin · 12 Juni 2017, 13:23:15

Seit ich die 00_SONOS.pm auf den Stand vom 09. April zurück gesetzt habe (SVN Rev 13952), habe ich keine Probleme mit Abstürzen mehr.
Die Auslöser für die Abstürze sollten sich also in den Änderungen vom 14./15. Mai finden lassen.
Die sind leider ziemlich umfangreich, so dass ich beim drüber schauen jetzt nicht sofort einen konkreten Verdacht habe.

Hotbird · 13 Juni 2017, 12:12:50

@Phiolin
kannst Du mir nen Tip geben wie das mit dem zurücksetzen ging?