Roon Extension: Alarm Clock v0.9.1 (current)

Yes, on a (mostly) dedicated Zero W. Starting the alarm always works, so a bit strange.

Thanks for the clarification. If it uses the -g flag to install the extensions, then that makes total sense. Mainly trying to run roon extension manager and its installed extensions in an isolated environment.

Not a single one (apart from some general purpose packages) :slight_smile:

I made it work by setting the prefix environment variable (export NPM_CONFIG_PREFIX=~/.RoonExtension). This is also covered in the manual installation instructions.

I would rather make ‘an isolated environment’ part of the default installation instructions as to make sure it doesn’t interfere with other projects, or the other way round, the other projects somehow interfere with yours.

If that’s the goal then my advice is to run the Docker image:

Hello @Jan_Koudijs, ever since the recent Roon update the alarm clock extension seems to keep crashing. Are you aware of any issue or change with the update?

Thanks.

Hi @Nathan_Wilkes,

Thanks for your report.

I know that at the night the Roon core got its update there was also an update of the Roon API. I wasn’t aware that one of these updates is causing problems and will dive into it.

1 Like

Is this the crash anyone is seeing?

Specifically the last bit - this.moo.close is not a function. This seems to happen whenever an extension unpaired due to response timeout, or extension is removed (View -> remove) etc.

RollingLog.js:27
*** Uncaught Exception:
RollingLog.js:28
*** Message: this.moo.close is not a function
RollingLog.js:36
*** Stack: TypeError: this.moo.close is not a function
RollingLog.js:40
    at Transport.close (D:\GitHub\roon-extension-deep-harmony\node_modules\node-roon-api\transport-websocket.js:47:18)
    at WebSocket.Transport.ws.onclose (D:\GitHub\roon-extension-deep-harmony\node_modules\node-roon-api\transport-websocket.js:18:14)
    at WebSocket.onClose (D:\GitHub\roon-extension-deep-harmony\node_modules\node-roon-api\node_modules\ws\lib\WebSocket.js:446:14)
    at WebSocket.emit (events.js:182:13)
    at WebSocket.cleanupWebsocketResources (D:\GitHub\roon-extension-deep-harmony\node_modules\node-roon-api\node_modules\ws\lib\WebSocket.js:950:8)
    at Socket.emit (events.js:182:13)
    at onwriteError (_stream_writable.js:425:12)
    at onwrite (_stream_writable.js:456:5)
    at _destroy (internal/streams/destroy.js:40:7)
    at Socket._destroy (net.js:606:3)
    at Socket.destroy (internal/streams/destroy.js:32:8)
    at afterWriteDispatched (internal/stream_base_commons.js:75:17)
    at writeGeneric (internal/stream_base_commons.js:70:3)
    at Socket._writeGeneric (net.js:761:5)
    at Socket._write (net.js:773:8)
    at doWrite (_stream_writable.js:410:12)

Have you already tried to update the extension?

If you are using the Extension Manager, then update that first. Once the Extension Manager is updated you can update the Alarm Clock.

Please let me know if this helps.

1 Like

@Jan_Koudijs, Thanks for the suggestion. I had previously tried updating the alarm clock, as well as uninstall / reinstall, but I had not updated the extension manager explicitly. I have done that now, and then updated the alarm clock, and I’ll see if the alarm clock crashes.

To my recollection, the version numbers did not change. (.71 and .60).

I’ve lost the ability to see the extension manager in my windows core where it was installed. I’ve tried to uninstall node is and reinstall with the installer (as administrator) but never see the node js service listed in services.

@Jan_Koudijs any suggestions? W10 B354

Correct, during an update the latest versions of the API modules are pulled in. My extensions don’t use fixed module versions (yet).

1 Like

You probably have to perform a full uninstall before the reinstall.

Thanks. The extension hasn’t crashed in a day, so the update process seems to have fixed the problem.

1 Like

Thanks Jan that did the trick…have bookmarked the page on my windows system this time too - for those that want a results of the install script detail…

Just installed the extension and doing a first trial and I encounter a ‘Wintertime’ issue.

I’m running Roon on QNAP. The time indicated on the QNAP itself is correct.
However the Alarm starts 1 hour later than requested in the alarm.

Where does the extension get its time info from?

Are you running the Docker image of the Extension Manager in QNAP ContainerStation?

If you do so, it is important that you set the correct timezone for the container by setting the TZ environment variable. More information about getting the settings right is in this thread:

My bad. My core is on QNAP, but I have in between dietpi endpoints where I installed the extension manager and the alarm clock extension and this dietpi had the wrong time.

1 Like

Alarm Clock v0.7.0 is now available

This version includes source selection for Play alarms!

You can read more about it in the feature thread:

I hope you like it, suggestions are welcome.

How to install / update

The recommended way to install or update is via the Roon Extension Manager .

If the manager has auto update enabled then the changes will be pulled in the next time the update is performed. It is also possible to update manually via the Settings dialog, select the Alarm Clock from the Playback category and perform the update action.

7 Likes

Many thanks Jan! You nailed it!

2 Likes

Mad props to @Jan_Koudijs

for this update!

Works like a charm

2 Likes

Alarm Clock v0.7.4 is now available

This is a bug fix release.

The bug that is fixed is the one reported by @Bart_Maguire in this thread:

How to install / update

The recommended way to install or update is via the Roon Extension Manager .

If the manager has auto update enabled then the changes will be pulled in the next time the update is performed. It is also possible to update manually via the Settings dialog, select the Alarm Clock from the Playback category and perform the update action.

1 Like