1,5 Stunden? Ich glaube da ist jeder Timeout aktiv.
Ja klar ... mit den 1.5h ist auch die Länge der Playlist (wohlgemerkt, über die ganzen Interpreten und Alben verstreute Titel) gemeint, nicht das laden. Darauf liegt im Moment mein Augenmerk. Kurze Playlisten schaffen es rechtzeitig in die Box, lange nicht ....
Das Gedudel, wie du es nennst ist fest im Radio hinterlegt, sollte also auch funktionieren, wenn man das LAN komplett abklemmt.
Das ist auch meine Annahme. Offensichtlich bekommt xmrx aber noch nicht mal ein Gedudel serviert wenn seine Box den Timeout hat, muss wohl am Gerätetyp liegen.
... oder eben auch nicht. Noch immer funktioniert es manchmal, dann aber wieder nicht. Es gibt allerdings etwas was ich mir mittlerweile ziemlich sicher bin: Es muss wohl ein Timeout (von ziemlich sicher 60s) an der Box geben welches überhaupt zum Problem führt. Wenn man also dieses Timeout für das warten der Box auf das LMS und die Übertragung/Pufferung einer Playlist erhöhen/einstellen könnte wäre die Welt wieder in Ordnung.
Trotzdem erscheint mir das ganze mittlerweile irgendwie seltsam. Ich bin nämlich in jeder anderen Hinsicht mit der Funktionsweise und Performance meiner gesamten Sequeezebox-Installation und Fernsteuerung sehr zufrieden und kann ansonsten weit und breit keine Probleme ausmachen. Wenn ich an irgendeinem Gerät mittels irgendeiner Steuerung (lokal, PC im Netz, SqueezeCommander auf Handy oder Pad oder gar per Inet im Büro) irgendeine Playlist zum abspielen auswähle dauert es nie und nimmer 60s bis die Musik spielt.
Das muss also irgendwie das Zusammenspiel der Netz- und NAS-Komponenten inkl. Box sein was in Kombination mit irgendwelchen Sleep- oder Standby-Modi von einem oder mehrer beteiligten Hard- und Softwarekomponenten dazu führt dass das Timeout immer wieder überschritten wird.
Was ich bereits tue: 5min vor Wecker rufe ich von extern das LMS-Browser-Interface auf. Die HDs an meinem NAS haben SleepMode-Verbot und ich hab sämtliche verwendeten Playlists auf ca. 1h zusammengestrichen.
Was ich gerne noch probieren würde: Sicherstellen dass alle beteiligten Komponenten zum Weckzeitpunkt hellwach und aufnahmefähig sind. So etwas wie ein Weckruf, quasi ein stiller Wecker vor dem Wecker (selbstverständlich auf der weckenden Squeezebox) der selbstständig nur grad so 1-2min. läuft dafür aber sicherstellt dass alle Komponenten aufmerksam sind. Ich wäre sehr dankbar wenn jemand dazu einen geeigneten Vorschlag hat!
Wenn eine ganzganz kurze Playlist keine Probleme bereitet, stell Dir nochmal einen Wecker vor dem Wecker mit einer solchen. Oder mit nem Defaultsignal. Lautstärke für diesen Wecker runter.
Das war ja auch mein erster Gedanke. Nur gibt es da eine kleine Schwierigkeit: Sowohl die Weckerlautstärke als auch die Weckerdauer lassen sich nur global einstellen, nicht indivduell.
Das bedeuet nun: Wenn ich eine ganz kurze Playlist, oder ein einzelner Titel einstell dann kommt anschliessend einfach Default-Gedudel bis die Weckdauer rum ist .... und solange ein Wecker aktiv ist wird kein zweiter aktiv (hab ich hier irgendwo gelesen). Die Weckerlautstärke einfach runter nehmen geht damit auch nicht sonst hör ich meine "richtigen" Wecker ja nicht mehr. Dafür hab ich mir schon ausgedacht ein mp3-File mit viiiiel stille zu generieren, damit ich die Lautstärke icht runternehmen muss, bleibt aber immer noch die erste Schwierigkeit .... eine verzwickte Sache
....Heute Morgen war wieder gar nix mit ordentlichem wecken obwohl ich Gestern extra noch exakt die Weck-Playlist geladen hatte für den Sleepmode. Mir fällt bald nichts mehr ein, eine wirklich bescheuerte Sache....
Hier wieder mal ein Update der letzten Beobachtungen (slimp3 als Wecker):
- Wecken mit Internetradio scheint zuverlässig zu funktionieren (spielt zuerst kurz (2-3s) was vom Buffer, dann Ruhe, dann kommt die aktuelle Musik)
- Wecken mit Musik auf einem USB Stick ("Solid State") am NAS funktioniert zuverlässig
- Wecken mit Musik von NAS HDs funktioniert nur ab und zu
Inzwischen habe ich auch auf DSM4.1 upgraded. Der einzige Unterschied ist, dass ich nun viele dieser Meldungen in den NAS logs habe - aber das ist wohl ein anderes Problem:
Sep 18 07:18:13 kernel: [596874.701193] ata1: wake up from deepsleep, reset link now
Sep 18 07:18:13 kernel: [596875.119396] ata1: device plugged sstatus 0x1
Sep 18 07:18:16 kernel: [596877.708617] ata1: exception Emask 0x10 SAct 0x0 SErr 0x4050002 action 0xe frozen
Sep 18 07:18:16 kernel: [596877.716113] ata1: irq_stat 0x00000040, connection status changed
Sep 18 07:18:16 kernel: [596877.722256] ata1: SError: { RecovComm PHYRdyChg CommWake DevExch }
Sep 18 07:18:20 kernel: [596881.696365] ata2: wake up from deepsleep, reset link now
Sep 18 07:18:20 kernel: [596882.052730] ata2: device plugged sstatus 0x1
Sep 18 07:18:22 kernel: [596883.500365] ata1: link is slow to respond, please be patient (ready=0)
Sep 18 07:18:23 kernel: [596884.703565] ata2: exception Emask 0x10 SAct 0x0 SErr 0x4050002 action 0xe frozen
usw. für alle 4 HDs
Nachdem ich die Nase voll hatte von dem Gedudel hab ich mal alle Wecker gelöscht und nur einen einzigen neuen gebaut, der halt nun von Montag bis Freitag dieselbe Playlist abspielt, was tatsächlich (meistens) geht. Empfindlich scheint das System auf Änderungen eines Weckers und oder viele Wecker zu sein, je mehr davon desto weniger funktioniert es.
Ich denk ich werde in nächster Zeit immer mal wieder den einen Wecker gleich ganz löschen und einen neuen bauen wenn ich die Playliste ändern möchte, geht ja nur Sekunden mit dem SqueezeCommander oder Web-Interface. Wenn das funktioniert ist es zwar keine eigentliche Lösung aber immerhin ein Workaround.....
... mit den 1.5h ist auch die Länge der Playlist (wohlgemerkt, über die ganzen Interpreten und Alben verstreute Titel) gemeint, nicht das laden. Darauf liegt im Moment mein Augenmerk. Kurze Playlisten schaffen es rechtzeitig in die Box, lange nicht ....
serviert wenn seine Box den Timeout hat, muss wohl am Gerätetyp liegen.
