Roon Extension and Android App: it'roXs!

Don’t think so, load_config and save_config are part of the roon api.

What I do not understand:
When you do an ‘npm install’ (one line in your docker file), a lot of files are downloaded and written. So why is saving ‘config.json’ a problem?

It’s not a real problem, but i must create a docker volume.

So i must add all the app in a volume (same folder level).

Dont worry, it will be working :wink:

I thing issue is resolved by this fix

comassky/itroxs:wrapper 

and

comassky/itroxs:latest

are updated

If you still get this NetworkError and unpaired thing… could you please just run the standalone executable of the extension and see if this changes anything? Just to make sure this is not another docker related issue. Thanks!

Sorry I have been off the grid for some family issues. I am trying the standalone on my pc now and will update with results.

Hi Boris I have been having a similar problem overnight (every night) since I put the Dietpi distro in place.
Works perfectly well up to the point when I go to bed and then in the morning connection refused message. I normally I go to work and reboot the pi in the evening. I am off today so I will reboot now and see if it is still running this evening, so to check if it is not an overnight event but so.mething that happens after a certain amount of time.

(I am using the extension manager to run it but had the same issue when I ran it locally on the Pi, but not on Windows)

Mike

When you get the connection refused error, is the extension still running? What is the status in Roon -> settings -> extensions?
And why do you reboot your pi every day? Does it work if you do not reboot?

Boris thanks for the quick response.
I only reboot the pi when the extension fails, as I am running the pi just for your extension.

I have rebooted it this morning and it is working now. I will check the extension screen on the next failure.
I am assuming that this is a pi issue (as I got it running through the extension manager and locally) as I never had 8t running under windows.
I will update you on the next results.

Regards

Mike

Hi Boris, doesn’t seem to be an overnight thing as I just went to change track and it has happened again.

Is what I see on my phone.

I then went to the extension manager as you requested.

a quick reboot and everything looks to be back in order and given the message it looks like it is a Pi issue

I do end up with the same problem if I don’t run it through Pi extension manager.

I could try a different distro and see how that goes
Regards

Mike

1 Like

You can bind mount the config.json file into the container at container creation time. First you create an empty file:

touch /path/on/host/config.json

Then you create the container with docker run and supply the absolute path of the file as part of the -v option:

docker run <options> -v /path/on/host/config.json:/path/in/container/config.json <image>

Setting changes end up in the file on the host and can be used again when the container is recreated.

Thanks @Michael_Harris
My extension probably crashes… I ordered an RPi, so I can try to reproduce it, hopefully tomorrow…

@Jan_Koudijs
Is it possible to get the output of the terminated process? Or the stack trace?

It’s a solution i Can use, but i dont want to force users to create the file.

IMO docker image must works without any interaction :slight_smile:

Boris if you need help testing I will be happy to be of service

Regards

Mike

@Boris_Schaedler, @Michael_Harris

Extension output can be written to a log file. To do this you restart it’roXs “with logging” via the Extension Manager and then after the event you download the log by clicking the Extension Manager @DietPi link in the extensions overview in Roon.

1 Like

Boris I will try this later today and see what I get from it.
Mike

Thanks, just send the log to the email address you can find in the app (about dialog).
I will get an RPi later this day, I will set it up with DietPi and ExtensionManager, so hopefully I will be able to reproduce your issues…

Thanks Boris I had a day out yesterday and have brought all the equipment together today for testing on a single switch so should be able to get you log files tomorrow.
From what I am seeing on first startup the service seems to crash and then startup again

Regards

Mike

Hi Boris did you make any significant changes? After opening up the Pi and bringing the gear into the same room it has worked overnight for the first time.

I was concerned that the pi was overheating, but possibly not. I see this morning it has updated from 1.0.3 to 1.0.5

Regards

Mike

Hi Mike,

I released the test version yesterday, that means, if the extension crashes, it just restarts itself. If you want, you can ssh into your dietpi and have a look at the following folder:

root@DietPi:~/.RoonExtensions/lib/node_modules/roon-extension-itroxs

Does this folder contain a file called exception.txt? If yes, you can email me this file. If not, there was no crash.

There will be an app update soon: the extension (v1.0.5) will report crashes to the app and the user can then send the crash log to me. I think this is easiest way to get some crash logs.

I have a DietPi with ExtensionManager and it’roXs now running for two days without any issues. So it would be really helpful to get some crash reports from you! :nerd_face:

Thanks for your help!

Boris interesting that, as I could hear my nucs fan (for the first time ever) for a couple of days during all the crashes but now that I have 1.0.5 running it’s mostly silent. Currently stressing out the CPU with multiple MQA streams from Tidal to give it a good testing.

I will have music on most of the day so I will use it’roXs to change volume and tracks and look at the logs.
All the equipment is in bits at the moment on my study table, hopefully it all goes back together and in place this evening nice and stable again :grin:

Regards
Mike

Boris so far there is only one line in this file and I have been using it most of the day so far

{“timestamp”:1601111783470,“stack”:“Error: connect EHOSTUNREACH 192.168.1.252:91
00\n at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1145:16)”}

I have moved everything away from the main router for now for testing, so it is running through an Orbi mesh router, so while very good, is not the same as being directly connected to the main router. It will go back this evening or tomorrow morning

Regards

Mike