Roon Extension: Deep Harmony - rich feature set for Logitech Harmony

OK thanks for that clarification.

Logs sent to pm

Deep Harmony 2.1.4 Released

This should already indicated as an available update. As this appears to fix the issues that @CrystalGipsy was experiencing and includes some cleanup of historic issues that have crept into settings for some people, then this means I can start to again look at some other planned features including those requested here.

Change History



  • Fixed issues with applying settings that could sometimes result in all controls being removed (causing Add Source Control to not appear).
  • Attempt to block bad SSDP responses that could result in undefined hub (underlying cause unknown).
  • Added settings cleaner during startup to remove known invalid keys (including undefined hub).



  • Fixed corrupt extension status web link.
  • Add ToC to readme.



  • Update to latest Roon SDK (1.2.1) modules to pick up bug-fix.
  • Add Roon pairing reset option.

Note, I am following a release pattern of only updating the docker images around significant releases, so only the console apps are updated in this release. The existing docker images can self update to this release.

1 Like

Thanks, cleared up my phantom extension entries.

1 Like

Great - it was your logs that showed the need for some cleanup :slight_smile:

Hi all. I am having a problem setting up the extension. I actually put my question up in support, but it probably should have been here! So, here’s the link. I appreciate the help. Thanks. JCR

Update: my MQA endpoint for the rpi3 on which I installed Docker and the Deep Harmony extension has reappeared on its own on my network. That indeed was the issue, as the extension now appears in Roon as expected.

I have to say thank you @Adam_Goodfellow for this extension it makes my 2nd systems so much easier to use.

1 Like

Hi, I am running " docker run --detach --restart unless-stopped --network host khazul/roon-extension-deep-harmony" on a pi3 to get the extension running…I find that when I reboot my pi3, the extension does not automatically start. Is there a way to set it up so that it does? Thanks! Hammer

--restart unless-stopped or always should do that. A quick google around suggests that not all versions of docker honour this on boot (unless a user logs in) and so you may have either try a later version of docker.

google search docker boot


I’ve been using and monitoring your extension for several weeks now.
Everything is working, no crash of the container happened.

However, I noticed that after a few days, the container starts to consume a lot of memory and therefore is eating all my NAS memory. Memory usage highest peak was above 900 MB for the container only.

Have you any idea about this possible memory leak ?

I just checked the memory usage on my Synology NAS and it is running at 99mb,

It has been been running for 7 days, and I don’t think has increased in that time.

I’m using docker.

I mention for comparison purposes. I’m afraid I’m no expert in this area.

Hope you get to the bottom of it

I noticed this to on my QNAP. I reduced the amount available to the docker and it’s still running fine.

I havnt seen any evidence of a leak, however ill keep an eye on it now it has been brought up.

1 Like

A question for those of you who are suspicious of a memory leak - are you making a lot of use of favourites with possibly big playlists?


I have tried running a memory profiler, however it seems that the profiler library I tried seems to cause more trouble than it helps resolve due to it using massive amounts of memory and not releasing it for some time, so that need some fixing/taming to be useful.

In order to keep an eye on this, once I have tamed the memory profiler, then I will probably include a means of memory use logging and heap snapshotting in the next update as both will be useful diagnostic aids in future.

@AdZero where in the NAS UI did you see 900MB? Also are you running the latest version of the extension (V2.1.4+254)? 900MB seems about right for a V1 docker image.

@Stampie - 99MB is a little more than I might have expected, but not if multiple hubs, lots of zones etc. (BTW - this size is about right for a V2 docker image size rather than process memory use)

For reference, this is the extension process running in docker on my QNAP NAS (Apps / resource monitor / processes - the full process name will probably be truncated as below):

I would expect the memory use to jump around a bit (tends to slow rise, then quickly fall) because of the way garbage collection works when unconstrained. I generally see around 63MB-75MB on here. It is quite reasonable for some users with multiple hubs and many zones to see higher figures, but not vastly higher. I do know of some operations that can cause temporary jumps in memory use (up to another 60MB, but they do not occur in normal use).

The V1 extension was both a disc and memory hog in docker which was part of why I switched over to compiling it. It was basically a prototype to gage interest while I figured out the tech.

Wow, just checked again, and it has gone up to 428mb!. I only have a single hub and zone, so not a complicated set-up

I restarted it and the memory usage has gone down to 31mb

Let me know if you want any logs / testing done to help locate the root cause

Thanks - it is best to wait till I make an update that is capable of memory snapshots and memory usage logging - the logs are unlikely to tell me anything useful about memory usage.

It may be worth also limiting memory use by the container to 150MB for now.


Here’s the answers to your two questions :

  1. Memory usage in the appropriate container window on Synology Docker UI, as in shown in last @Stampie post.
  2. I’m using a v2 image (tag latest) which has been updated several times. I’m currently on the last version (V2.1.4+254)

Memory consumption is currently stable at 90 MB since last container restart two days ago. I guess something must trigger this memory consumption.
It only appears after a long period and has been noticed twice since moving to V2.

OK - thanks for clarification.


As an addition to the previous posts, here’s another proof of high memory consumption.
Not my best score but almost :grinning:

Thanks for update. I havn’t forgotten this. I am still looking for a decent way to get some useful diagnostics on this included in the extension that doesn’t cause more harm than it solves.

Meanwhile unfortunately I am not seeing this here.