Its a great extension to have supported & included in the Ropieee.org RPi OS with Roon Bridge and a bunch of other streaming options in the XL version.
Hi @Hans_Valeton,
Thanks for the detailed reports of the issue, I will do my best to use them to improve the user experience and avoid further frustration in the future.
Let me first explain how the timezone handling is intended to work.
During DietPi installation the timezone should be set in the DietPi configuration. Then when the Extension Manager gets installed it detects the set timezone after which it will be used as the default setting during Alarm Clock installation. I realized that setting the timezone was not described in the documentation, so now I added that (together with the keyboard layout, for completeness).
I have placed it on my TODO list to see if the timezone handling can be improved.
The timestamps in the log files are UTC, so the 2 hours difference is expected. For inserting the timestamps I rely on Docker functionality, there is no setting to change this.
This is done to avoid that a single log file contains information from different versions of an extension, or from different installation settings (in this case the timezone).
Please let me know if any issues remain, or that everything is working now.
Hi @Jan_Koudijs
Thanks for your quick reaction.
Sorry but it seems I have not been entirely clear in my description of the events this morning, but the most important fact is that again the alarm did not go off.
Yes, if I set it to go off within a few minutes’ time, it works, as it has done the past week whenever I tested it with an alarm that was planned to go off within a few minutes. But these short term successes appear to present a kind of Pyrrhic victory. Because the alarm NEVER goes off after the passing of the night. So I was hoping you could draw some conclusion from the loggings I uploaded earlier. In these logs you can clearly see how, after a night’s rest (maybe some system alertness is lost during the night??) the alarm’s fade-ins are “terminated” immediately after the alarm expired. See my earlier post:
This clearly is not the intended behaviour.
Somewhate later in the same log you can see what should have happened at wake-up time.
From 2021-07-07T07:36:04 onwards every second a slight increase in volume for all three zones is logged.
But the pressing question remains: why does it work in the short term during the day and not after a good night’s sleep?
Thanks in advance!
Good morning @Jan_Koudijs ,
This morning the alarm did go off!!
I can’t be absolutely sure but perhaps the thing that did it was the fact that yesterday evening I changed the “Check for Updates” setting under the Extension settings:
I deleted the time and pressed the “Save” button, after which the “Check for Updates” field remained empty.
Let me explain. First I’ll re-upload the loggings of the 7th of July:
Now the reason I disabled the automatic update of the Extension manager was because it had occurred to me that in the Roon Extension Manager logs of the night / early morning of the 7th of July, after the
2021-07-07T01:00:04.804449000Z It’s update time!
and this one:
2021-07-07T01:00:07.949688000Z Inf: Extension Manager already up to date
a repetition of 238 times (two every minute) of the following entries followed:
2021-07-07T01:00:07.949968000Z → CONTINUE 1 Changed {“message”:“Extension Manager already up to date”,“is_error”:false}
—//—
2021-07-07T02:57:31.053739000Z → CONTINUE 1 Changed {“message”:“Extension Manager already up to date”,“is_error”:false}
And then this slightly alarming entry:
2021-07-07T02:57:45.189308000Z Core lost: SCHUBERT
Luckily, some entries later the core is found again:
2021-07-07T02:58:15.711279000Z Core found: SCHUBERT
Shortly thereafter a repetition of 720 times (again two every minute) of the following entries:
2021-07-07T02:58:16.017653000Z → CONTINUE 1 Changed {“message”:“Extension Repository loaded (v1.0.8)”,“is_error”:false}
—//—
2021-07-07T08:57:15.957577000Z → CONTINUE 1 Changed {“message”:“Extension Repository loaded (v1.0.8)”,“is_error”:false}
The repetitive entries as shown above continued while the wake-up alarm I had set for 09:00 (07:00 CET) expired, as was shown in the Roon Extension Alarm Clock logs, at 06:59 CET, almost immediately followed by the entries indicating the termination of the fade-ins.
Perhaps the Extension manager was so busy putting out the “Extension Repository loaded (v1.0.8)” log entries that the Alarm clock failed to continue its fade-ins as planned?
And that suspicion is what made me decide to de-activate the daily (in fact: nightly) update of the Extension manager.
The Roon Extension Alarm Clock logs of the past night look a bit different than before. Only four entries in the log between the time I went to bed and the moment the wake-up alarm expired. And those four look quite innocent. They are of the type “zones_removed”, and “zones_added” (purely informative ones?)
And then, at the right time the alarm went off, not only proven by the logging but also by the fact that my wife and I actually woke up to the queued music!
The Roon Extension Manager logs of the past night are still replete with hundreds of the following entries:
2021-07-09T05:59:05.015527000Z → CONTINUE 1 Changed {“message”:“Extension Repository loaded (v1.0.8)”,“is_error”:false}
2021-07-09T05:59:05.016237000Z → CONTINUE 1 Changed {“message”:“Extension Repository loaded (v1.0.8)”,“is_error”:false}
2021-07-09T05:59:05.016282000Z → CONTINUE 1 Changed {“message”:“Extension Repository loaded (v1.0.8)”,“is_error”:false}
2021-07-09T06:00:05.016276000Z → CONTINUE 1 Changed {“message”:“Extension Repository loaded (v1.0.8)”,“is_error”:false}
So, perhaps I was wrong in assuming the Extension manager update had anything to do with the problem?
Well, a number of question come to mind:
- Is the automatic update attempt really necessary?
- Will my “solution” last for more than one night?
- Would setting the automatic update time to e.g. 14:00 (instead of 02:00) also do the trick?
The story continues:
For this morning I had set an extra alarm, by way of an extra experiment, 4 minutes later than the first (that actually woke us up) and also with a fade-in of 1 minute. But I could barely register this second alarm, while I lay yawning in bed. Perhaps I did hear a slight popping sound but I’m not sure.
After having woken up I reset the second alarm for some ten minutes later, and again I thought I heard a plopping sound, as if the music was stopped and then started again with only a few milliseconds between.
The loggings confirm what I heard, the expiration of both extra alarms were logged, shortly followed by entries that indicate that the volumes of the three Sonos zones were (set) at 45, 50 and 50, respectively. So no fade-in was actually performed.
- Is this intended behaviour (as I think it must be)?
By the way, here are the loggings of the past night:
1 Like
Please keep the auto update disabled for the moment in order to find out if this gives repeatable success or that it was a single occurrence.
I see in the logs that you use an alarm on a grouped zone with three devices, if disabling updates doesn’t give stable results then using an ungrouped zone might be worth a try.
Let me know the results of the above two points. I will have a more in depth look at the log files and will get back to you.
1 Like
The communication between the extensions and your Roon core is unstable, communication with the core often drops and there are crashes of the Roon API.
What does your setup exactly look like? I see that there are 2 SHUBERTs around. What roon applications do you run on your Windows PC, only the all-in-one Roon application or the separate server and remote? Is the old PC still connected in the system?
Edit:
The crashes are very similar to the one reported in this thread:
Please perform the steps for reconfiguring the firewall, as described by @DrCWO.
Hi @Jan_Koudijs, thanks for looking into my problems!
First off, the alarm did go off this morning too (the second time in a row!) on all three Sonos zones and complete with the fade-ins.
Perhaps a bit confusingly both my new Windows PC and the new Roon core on this machine are named “SCHUBERT”. Similarly both the old PC and its Roon core were named “BEETHOVEN”. That never created any problems.
Which Roon API do you mean?
The DietPi (on which the Roon Extension manager runs) is installed as a VM on the SCHUBERT PC, so how can it lose communication with the Core that resides within the Windows install on the same physical machine?
I already double-checked all my Firewall settings a number of times. Inbound traffic is allowed for all Roon processes both Private and Public.
On the BEETHOVEN I once configured an Outbound rule for the Raatserver, but I don’t think that was actually necessary.
With the current settings in place a daughter of mine (who lives in Leiden) can remotely gain access to the SCHUBERT core using ZeroTier.
The SCHUBERT PC is connected to my intranet via WiFi. The motherboard came with WiFi and so I saw no harm in actually using it while I built the machine and then installed all the software on it, and in this way I did not have to use a very long UTP cable to connect the PC to my network.
SCHUBERT has been standing in the living room for about a month now because at first it was quite unstable (lots of BSOD’s) and I had to do a lot of troubleshooting on it before it finally became stable.
Also, in the summer the temperature in the living room is more agreeable in the living room than it is in my study, where SCHUBERT will eventually will end up being placed, just like its predecessor BEETHOVEN.
I have installed the separate server and remote, just as I was used to on the old BEETHOVEN.
I remember however that importing the backed-up database was a bit of a pain in the ass. I vaguely remember that the result was never satisfactory. In the end I just copied the complete Database directory (C:\Users\hansv\AppData\Local\RoonServer\Database) from BEETHOVEN to SCHUBERT and that worked out fine.
I have stopped the Roon core “BEETHOVEN” and disabled its autostart with Windows.
The Roon extension manager on Beethoven hoewever is still alive. How do I uninstall it? I believe I had to install it into something called ‘git’ but I completely forgot all about that. Is there an uninstall guide for that?
The Roon API is a piece of software provided by Roon that allows extensions to communicate with the Roon core.
OK , then both the server and remote are named SCHUBERT. I don’t know if this is an issue, you could try to name the remote something else.
I don’t know why zones would disappear an reappear over night, I see this very often happening to HANS7 and SM-T720. What are these devices?
Another question, for the cases that the alarm did not work, was the Alarm Clock still listed in the extensions list in Roon or was a restart required for it to reappear?
Hi @Jan_Koudijs
At this moment I’m on holiday and though I did bring my SCHUBERT to our holiday home, circumstances are quite different here without the presence of the Sonoses for example. So I won’t be able to continue testing for the coming weeks.
This doesn’t seem to be the case. The following screenshot was taken form the ‘About’ page and suggests the Remote and the Core do bear different names:
HANS7 is my mobile phone, Samsung S7, hence the name.
The SM-T720 is my Samsung Galaxy Tab S5e tablet.
I’ll get back to you after the holiday!
Aha, these Android devices then probably are enabled as a zone in Roon. I have seen in the past that these zones cause at lot of “removed” and “added” events, but I don’t know if this can cause the issue you are having.
I apologize if this has been answered previously.
- I change my cores frequently and they are all on the same network.
- I run my extension manager on a Pi3 under dietpi.
- I create an alarm on Core 1 for a zone example PhoneLH
- I move my core to Core 2 on which there is no zone PhoneLH
- I try to modify the alarms on Core 2 but it will not let me. It only crashes the Alarm extension.
Previous to Docker I could run the uninstall from Roon and reinstall and redo the alarms. Now this command keeps the previous database of alarms. I now need to go to Dietpi and remove the extension manager AND docker and reinstall to clear the data base. Is it possible to clear this database by uninstalling from Roon.
I love this extension!
Further testing:
It would appear that if even on the same Core and a Zone referenced in an alarm but not present (physically turned off) that the Alarms cannot be accessed. This may also cause erratic behavior of other Alarms.
Thanks for the bug report, it definitely shouldn’t be necessary to uninstall anything. I will look into this.
Alarm Clock v0.9.0 is now available
This is a maintenance release with some bug fixes and small improvements. Changes are:
- Bug Fix: Configured offline zones no longer make Alarm Clock crash (@Progisus, thanks for the report)
- Bug Fix: A Transfer is only made if the source zone is actually playing
- Bug Fix: The pending alarms list now displays the destination zone in case of a Transfer
- Improvement: The Settings dialog displays the local time, allowing for timezone verification
2 Likes
Thank you very much!
Love this extension. Any chance of incorporating:
- force stop of all zones together
- force roon backup
I like to make sure all zones are stopped just before my scheduled backup. Setting a stop for each zone doesn’t always ensure a stop and adding or removing zones means revisiting each stop alarm.
Thanks again for this extension.
The Roon API has no interface to trigger a backup, so I cannot provide that. Stopping all zones should be possible, I’m wondering if there are others who have a use case for this function.
Hi Jan,
I have a problem with my Marantz AVR 7013 - I dont know whether is it a matter of the extension or the AVR. The Marantz (roon tested) cooperates via Airplay with roon. The alarm starts at the set time, the AVR switches on but there is no sound. Only when I adjust the volume one more step it works. The weird thing is - sometimes it works sometime it doesnt. I have no more idea to handle the problem.
Thank you in advance for your opinion.
Jochen
Hey,
I’m using and loving the alarm extension. However, I’m one of these obnoxious types who loves to listen to full albums.
What I do for the alarm is set a playlist to play at my wake-up time *1, that playlist contains usually just a single album, and I’m changing the contents of the playlist when I need other music to wake up to *2
Now, when the alarm goes off, it always queues and plays the tracks contained in the playlist in random order. Even if I don’t change the playlist’s contents (or that specific alarm’s settings at all), the next time around, the order changes, again, as if there was shuffle on (which isn’t. If I queue anything else to play in that zone, it will be queued in the proper order).
If I play or queue that specific playlist just regularly via the roon app, the order is maintained properly.
All of this behaviour is regardless of which zone I use the alarm extension in.
Anyone seen similar?
I do have and occasionally use the Random Radio extension, but this behaviour also shows up regardless of Random Radio on or off (or actually even Roon Radio on or off in that zone), so I really think it’s the queueing function that does something weird.
Also, is there a way to completely remove alarms I don’t need anymore, other than disabling and living with the clutter?
*1: I also have an (usually different) album playing to fall asleep too, so just playing the remainder of the queue won’t work for me.
*2: Will there be a feature to just select an album to play when the alarm goes off?
Thanks for any insight into this. If there are relevant logs, I’ll have a look at those, too.
Hi @Jan_Koudijs. Hoping I might be able to ask for your help with a problem with the Alarm Clock extension. I have a problem similar to some described above, where the radio is often playing, but at 0, 1 or 2 volume (I have it set to fade up to 14). Sometimes though it doesn’t play at all, and the extension crashes.
I wanted to be able to present logs with this request for technical assistance, but unfortunately I don’t seem to be able to get these either. When I follow your logging instructions, I don’t see any option to ‘collect logs’, I just see ‘enabled’ or ‘disabled’ options (it’s currently ‘enabled’). I can’t seem to change this, either - it just hangs indefinitely at ‘Saving…’ if I do so.
The Roon core is a QNAP server, it’s always been super stable and effective, and the extension used to work perfectly when I used it in a different zone. Since switching the zone however, it’s rarely worked at all, sometimes with the low-volume problem, sometimes by crashing. Can you possibly help?
Many thanks!
The shuffle behavior is intended functionality of the Alarm Clock extension. I choose to always shuffle a playlist because I assumed the selected playlist to be pretty static and wanted to avoid waking up every day with the same song, but your use case is clearly different.
I previously described my thought process here:
There I also described that album selection is not provided because it would be a terrible experience when dealing with thousands of albums.
Back to the shuffling of playlists, the Roon API provides the functionality to play a playlist in order but that requires an update of the extension. I might include this in the next release, but no ETA.