I was thinking about a set and forget approach, so you select a big playlist once and shuffle takes care that you are not waking up every morning with the same track. I had not guested that there are users who take the time to compile a playlist every night for the next morning, but now i know
No, reason being that i did not know what to change . I do have a few open points for other extensions though, so I donāt know when I will look into this.
Ah, thatās a pity. Because I might have a second request:
In Sonos all weekly alarms are persistent, meaning I donāt have to activate, say, the āMondayā alarm, for the next week each time after it has run. Just this morning I discovered that in your Alarm Clock extension I do have to do that. So at least once a week I need to set all alarms to āactiveā. Maybe it would be possible to add an option to make the weekly alarm settings permanent?
But of course the most important thing is that your Alarm Clock works and it does. With the fade-in set to one minute, a charming Haydn symphony (No. 82 ālāOursā, for the die-hard classical fans) glided into our bedroom this morning and awoke us in a very pleasant manner. So, thanks once again!
Sorry for the misunderstanding, Jan, but I was under the assumption that the option āRepeatā referred to repeating the playlist that was chosen to be played at wake-up time, and did not refer to the alarm setting itself. With hindsight I was stupid not to check out the exact working of this āRepeatā setting. If I may venture a guess as to why I didnāt, I think it was caused by my huge frustration with the change in the Sonos UI that was introduced some time ago, where a playlist that is chosen to be played as an alarm is ALWAYS repeated, without a way for the user to change this strange and utterly unwanted behaviour.
My apologies, of course!
As a result of your latest post I have immediately set all āRepeatā settings to āEnabledā in the Alarm Clock extension.
Promise is debt, as they say, so here is my experience with a āfrom scratchā installation of the extension manager on a clean machine. Today I have installed a headless āRoon Serverā on a Windows i5 laptop. For my 2 week trial I had first installed the full Roon (Core plus UI) on the PC I work on daily, but now that I have decided to become a permanent member of the Roon family, I wanted to migrate the Core to a machine that is somewhat more energy efficientā¦
Of course it would be nonsensical to keep having the Extension Manager (and thus the Alarm Clock) installed on my Windows i7 PC, and so I had to install it on the i5 laptop as well. Where I had followed a somewhat less than efficient and quite erratic installation path the first time around, this time all went well using the setup-win64-v0.5.2.exe that I had downloaded from here.
I could just sit back this time and watch the command box screen be filled as follows:
Iām having a problem with Alarm Clock (0.7.4) starting music on my Naim Mu-so 2nd gen. Things worked fine for a while. Then after an update to the Mu-so firmware (or some such), Alarm Clock does start music, but it always plays at minimum volume, so that I cannot hear anything. I can walk over to the Mu-so and manually turn up the volume and hear music, so there was indeed a āsessionā begun. If, on the other hand, I use Roon Remote (on an Android tablet) to start music (either internet radio or music from my local library) on the Mu-so, the music starts at a decent (audible) volume.
The alarm is set to play at volume 50 an internet radio station, with transition (fading) of 1 minute.
@Jan_Koudijs
Quick question: If I group an endpoint for which an alarm is programmed, will it work for the grouped endpoints?
Iāll find out in the morning anyway.
Sorry to disturb you but Iām having a problem with the Alarm Clock extension. In the past few weeks it has happened three times that the music stopped after some 10 to 30 seconds, while the fade-in was still in progress. I use three Sonos zones grouped as one: Slaapkamer, Keuken and Badkamer. This morning the music paused at 14 seconds into the first track in the queue. I reached for my phone, started the Roon app and noticed that the volume on the āSlaapkamerā Sonos Zone was muted (the light on the Sonos unit also burned permanently), while the two other Sonos Zones were still at volume level 46, just I had set them the night before. I pushed the Play button to start up the music again and changed the volume setting of the āSlaapkamerā Sonos back up to 46 again. I did this using the ā+ā button as can be seen in the logging)
Hereās the relevant part of this morningās log:
Might this be a case of a āfading problemā, as you yourself named it somewhere else in this topic?
Unfortunately the log file is empty. To have a look at the issue I need the output of the Alarm Clock extension. If you use the Extension Manager you can do a āRestart (with logging)ā for the Alarm Clock extension, as described in this post:
Thanks for the tip.
This morning however, I have uninstalled the Extension Manager (as well as the Roon core and clients on my Windows machines) and have started anew to see if my (other) performance issues will disappear or persevere.
This time around I will wait till the core is absolutely stable before I install the Extension Manager again.
As soon as I have done so I will test the Alarm Clock again and let you know!
@Jan_Koudijs is it allowable or problematic to have more than one Alarm Clock instance running on the network. If one has 2 RPiās running Ropieee with the AC turned on or perhaps a windows setup and a RPI will things break or will there just be 2 nodes that can be used for alarms?
Sorry about that. I just had a look and indeed the log file in my own directory is also empty. Must have made a copy-paste error of some sort.
Unfortunately I donāt have the original log file anymore. Iāll just have to test again.