Also, not sure if it’s related but when running the commands directly on my Mac there’s quite a long delay - like about 5-10 seconds - is that normal? Wondering if there’s something which is delaying things so much that the shortcut doesn’t function properly?
Good point, the delay could be causing the Shortcut to timeout. Apple Shortcuts have an indeterminate timeout based, I believe, in part on how much memory the device has. Also, a timeout would help explain why I am not seeing the same behavior as you - my delay is not very long maybe because I have a lot of memory or higher speed local area network, idk. Anyway, it’s a good thread to tug on.
I just installed this in my Mac today (M1 Max, about the fastest you can get) and I’m also seeing a 5+ second delay with commands. My core is a NUC+ROCK, all gigabit. So it’s not just you.
My nuc is pretty basic - an i3 from 2018 but it’s wired into my gigabit network. My iMac on the other hand should be well over specced - an 8 core 3.8GHz i7 with 64GB memory. It is only on Wi-Fi at the moment but has a really good connection to my mesh network.
Is there anything we can do to see the progress of the script and understand what’s slowing it down?
Also @Ronald_Record , can you time how long it takes a command to work on your system?
The delay has already been raised as an issue in the repo. I’ve been meaning to get to it. I think I can improve performance quickly and easily. However, I honestly do not think this is the cause of the problem being discussed here (ssh works with simple command but not with roon command). If Apple is timing out shortcuts after a few seconds then I’d say that is a problem bigger than what we have here.
I will try to fix the delay as quickly as possible and post a test release.
@Etk can you verify for me that the user you are using in the SSH Shortcut is the same as the user in the roon command? To show the user in the roon command, issue the following in a terminal window:
grep ^user /usr/local/bin/roon
Note also that it is this user that must have the public key from the Shortcut added to their ~/.ssh/authorized_keys
I found the issue on the repo, but don’t have an account there to respond. I don’t think ssh is responsible for the delay, if I run python3 /usr/local/Roon/api/zone_command.py -c pause -z desk, I still have the delay. I put some tracing in that script and the delay occurs with the line: roonapi = RoonApi(appinfo, token, server, port). 
Thanks @Scott_Jann good work. I found the same thing, the delay is in the call to RoonApi. I get about a 6 second delay. This is where a connection to the Roon Core is established and actions/media performed using the Roon API.
To circumvent SSH in this part of the process, set LOCAL=true in /usr/local/Roon/etc/pyroonconf or invoke the Python scripts directly as Scott has done. The LOCAL variable, if false, allows you to run the Python Roon API on a another system. Doing this requires SSH but the delay is not that much more pronounced than local execution.
I’ll dig deeper into the pyroon code to try and improve performance but, as I said above, I do not believe the delay is causing the Apple Shortcut problem. We will see.
Thanks both for digging into this. I agree the more I look at this that the delay isn’t the issue - I’ve got a Qobuz-related script that I run over SSH from a shortcut which can sometimes take a minute or two to complete, this works fine and the shortcuts app just sits there waiting before showing it as complete.
@Ronald_Record, the grep command does indeed show the right user - the one which is set in my roon script and the one which I’ve set in Shortcuts and added to the SSH authorised list. Good to know your delay is about the same, Ron - at least we know it’s not something happening on different systems.
Is there any way to locally monitor (on my iMac) what a script is doing that’s been called over SSH?
@Etk you can add “logging” to the script or execute bash -x script .... To add “logging” just add echo commands to the script sprinkled throughout. Better, run bash -x. In your SSH Shortcut, replace the command /usr/local/bin/roon -c stop with the command /bin/bash -x /usr/local/bin/roon -c stop > /tmp/roonlog or something like that. I haven’t tried this yet and I am just typing off the top of my head. If that works then you should have a trace of the roon command’s actions in the file /tmp/roonlog on your iMac.
1 Like
FWIW, I installed the .deb package on an ubuntu vm to see if it behaved the same (it does). I also hacked together a script to play/pause using the node api, it is essentially instant, so something is up with the python api.
I think the Python code is doing some discovery to connect to the Roon core, hence the delay.
I’d need to take a harder look to see if this is really necessary.
That said this shouldn’t stop anything working!
The initialization delay in RoonCommandLine commands has been fixed in the version 0.1.0 release of the pyroon project that provides the roonapi Python Roon API module. Users who installed RoonCommandLine using either the Debian or RPM format package can update the roonapi Python module by issuing the command:
sudo python -m pip install roonapi --upgrade
If you are using a virtual environment for Pip installs you may not need the sudo, depending on your virtual env setup.
New installs of RoonCommandLine will automatically pickup this new version of roonapi. Thanks @GregD !
3 Likes
I can confirm that after updating pyroon, simple commands are much quicker!
> time roon -z desk -c stop
0.13s user 0.05s system 8% cpu 2.253 total
Hmmm…
rene@George etc % time roon -c playpause -z "HQP4 Harry"
roon -c playpause -z "HQP4 Harry" 0.17s user 0.09s system 2% cpu 12.453 total
@RBM Hi René, I assume you are concerned about the “12.453 total” time to execute the roon -c playpause ... command. I am unable to reproduce that here. My times for a similar command are closer to 1.2 seconds and if I update the roonapi Python Pip module to 0.1.1 the time goes down to 0.2 seconds. So 12 seconds is alarming.
My first observation would be that it appears you are using zsh and I have not tested much with zsh. The roon command and all the scripts it executes are Bash scripts so a Zsh will be forking a Bash shell to execute the shell scripts. That might be expected to add some overhead but I am not seeing it. There can be differences in users’ environments. The non-interactive Bash shell that is forked to run a shell script will execute on startup anything in the file specified by the environment variable BASH_ENV.
You can eliminate Bash from this scenario by executing the Python script directly. This will tell us if the excessive time is consumed in Bash or Python/RoonApi. To do so, execute something like the following:
cd /usr/local/Roon/api
time python3 zone_command.py -c playpause -z "HQP4 Harry"
If the total time remains high then the performance problem is not Bash, the roon shell script, or the zone_command shell script. It is either the Python script or the Python Roon API, or something in the environment. If the total time is reduced significantly then the problem is zsh/bash, the roon command, the zone_command shell script, or something in the environment.
If the excessive time is being consumed in Bash you can try and further isolate the issue by executing bash directly as follows:
bash -x /usr/local/bin/roon -c playpause -z "HQP4 Harry"
This may give you further insight into where the roon shell script is spending unwarranted time.
Anyway, I suggest we try and isolate the issue as much as possible. One other thing to check is the value of the LOCAL variable in /usr/local/Roon/etc/pyroonconf. If this variable is set to true then SSH is not used and performance should be better. If LOCAL=false then SSH is used to communicate with the Python Roon API and performance is degraded slightly.
Also, please verify you are running the latest roonapi Python module. You can do this by executing the command:
python -m pip list | grep roonapi
It should return roonapi 0.1.0 or roonapi 0.1.1
Hey @Ronald_Record – thanks for jumping in so quickly!
The issue is definitely when running the roon script in bash – when I call the python script directly, response is near-instant (~0.25s). For my use case (automating a few Roon actions in Apple Shortcuts, this is fine (I have now mapped the click action on an Ortho remote to the playpause command).
And yes – LOCAL is set to true, and roonapi is updated to 0.1.1.
I did a little digging into the slow commands:
time python3 zone_command.py -z desk -c stop → 0.1s
time zone_command -z desk -c stop → 1.1s
… 
. /usr/local/Roon/etc/pyroonconf && time python3 zone_command.py -z desk -c stop → 1.1s
unset PYTHONUSERBASE && time python3 zone_command.py -z desk -c stop → 0.1s
Maybe python is being goofy on the Mac?
grep '^Version' /Library/Python/3.8/site-packages/roonapi-0.1.0.dist-info/METADATA → Version: 0.1.0
pip3 list | grep roonapi → roonapi 0.1.1
@Scott_Jann you’re blowing my mind. Unfortunately, or perhaps fortunately, I cannot reproduce your results here on either my Mac or a test Linux box. What you see is certainly strange.
I notice that Pip thinks you have roonapi 0.1.1 installed while the grep of the roonapi package METADATA shows version 0.1.0. That’s not right. A successful Pip upgrade of the roonapi package would be reflected in the METADATA. Perhaps you have both roonapi 0.1.1 and the remnants of roonapi 0.1.0 somehow? I am just guessing. But, the only difference between 0.1.0 and 0.1.1 was an adjustment to the sleep while waiting for the socket to be ready and that shaved about a second off the delay - an interval that closely matches the discrepancy in delay you are seeing.
I don’t have any other good guess as to what is going on.
On further reflection I would guess that you have both versions of roonapi installed, one locally as your user and one globally. The installation and maintenance of Python modules is something of a mess. They can be installed locally per user and globally. They can be installed in site-packages and dist-packages. And multiple versions of Python can co-exist. That leads to the potential of a system having multiple versions of the same Python module installed in different locations. The one that is picked up depends on env vars and which Python base is used. It’s amazing, to me, that Python works so well and is so widely adopted given this fragile exposure to version mismatch.
The RoonCommandLine scripts utilize a global Python/Pip module install with the Python base specified in /usr/local/Roon/etc/pyroonconf as PYTHONUSERBASE. Maybe I could have handled this better and I would welcome a lecture on Python/Pip package management.
I would suggest double checking to see if there is not a roonapi 0.1.0 installed globally and a roonapi 0.1.1 installed locally. If so, remove the local one and upgrade the global one with:
sudo python -m pip install roonapi --upgrade
If not, then back to scratching my head.
Yes, that was it! Except sudo wouldn’t do it, I had to use sudo -H to get it to update the system one (and the timing is great now). I am not an expert with python, and things like this don’t help, the lecture you proposed sounds like torture. 