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.
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?
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
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:
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:
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.
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?
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.
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 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.
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.
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
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.