Ok, so I have saving the config.json file working on my NAS. its clearly a security issue and I have granted too pervasive permission to the sub-folder I store it in right now and will work it back later, but its working.
@peter_richardson – so, thinking about a new user attempting to setup your solution using the docker image you publish. For them to be able to keep an instance of a config.json file between updates, they will need an initial one first.
put a blank or template config.json file in a directory for the docker image to use
map the host config.json to the image config.json file
start up the image
so, we need a default config.json file to go with the initial install, or we create an empty config.json file on the host, and on first startup your package builds the content of the file.
not exactly. Using compose yaml or any UI won’t create the file.
Also, are you saying IF I create an empty file and setup the yaml file, your app will write all the initial configuraiton data into the file OR are you expecting the initial config.json file to have some data in it? (if it can be blank, then the instructions are to just first create the empty file before mapping and starting)
@Evan_Kohn1, the file is writeable on the synology nas - i tested with a subdir on my rheos directory first then re-tested in my main directory – the issue is just permissions which i have to figure out minimum security – for right now ‘everyone’ as full control of the sub-dir where i keep the config.json file - this works (but is not a great idea) - everyone does not have access higher up the folder chain so little risk - so rogue process hacks my rheos config file…ha
under my docker folder, i have a folder for the test label of rheos extension - lacking imagination, i named it: roon_rheos_extension_label_test
under this, I create two folders: scratch - so when I bash into the rheos image i can copy whatever i want into the scratch folder as a copy and get to it on the host
and config - place to keep config.json
permissions on the config and scratch folder is everyone full control, r/w
@peter_richardson - i suspect i can do the same for the log file to get it available on the host? once i find where you have it, map it and create an empty file on the host?
@peter_richardson I am yest again having issues with RHEOS not playing gapless. Can you try the album below for me to see how it behaves for you if you have Qobuz its available on there. I have local files and its the same for these or Qobuz, even tried the 44.1 version still the same get gaps after 2nd movement then get them again and again. Via other Roon zones no issue.
If you can try playing from here as this seems to trip it up all the time. If you look at signal path whilst playing if it not gapless it will drop the signal between tracks. It seems to happen with the shorter ones only oddly. I can go back and start on a different piece and it will be ok on the gap then the next one will have a gap. If i go back in the track it will then play gapless over the track boundary. It all very odd and ruins something like this where a lot of them dont have breaks and flow from one to the other. Be good to know if its just my system or you or others can repeat it.
I can certainly confirm some strange behaviour with this album. On my system the shorter tracks end and then nothing plays for several seconds … the progress bar shows it’s searching …
When I transfer to the RAAT enabled Devialet nothing is playing at all
On a my M10NAD it seems to play normally.
Further investigation required, but I suspect its something about how the tracks in this album are identified. squeeze2upnp has special code for dealing with short tracks. I’ll take a look but not sure I can change much.
Good that it’s not me then. This is the same behaviour I flagged with you before but that’s been on regular tracks not short ones. I don’t want to use flow as it resamples all to a fixed rate. I tried different buffer sizes didn’t help.
Just seen this post similar behaviour to what we get.
Here’s the situation regarding squeeze2upnp and short tracks. according to Phillipe:
Handling of end of UPnP next URI and end of track is difficult because there is a lot of diversity between players. When the webserver has sent everything it should normally continues to linger and when LMS sends a new track we should use nextURI so that the player moves automatically to the next track when it has exhausted data with the current one. Sounds logical, but that’s not how some do
and they will NOT request nextURI but instead try to re-open the current one, especially if they receive a track with no duration and icy metadata. Although it is possible to rely on workarounds like refusing to reopen a fully served resource when requested again from the beginning, some players will still fail and cause a weird sequence that lead to false LMS “next” request and all sort of uncontrolled things. I’ve decided to never use the nextURI option, so no gapless when playing a track with no duration. This way, we’ll always expect a stop so the transition will be under control. Still, we need to refuse reopening fully served resourced when requested again from the beginning, which also is a way for the stop to happen, but without the uncertainty of what might be a stop in some cases or a real next in some others. Short tracks are also a problem and are gapped-in and gapped-out for safety. There is a need to delay the decision that the player has really stopped in case LMS has
not yet sent the new track, so a grace of 5s will be added after.
I will see what I can discover about HEOS and what could possibly be done in the specific case. But this will take some time!
I’m just here to say THANK YOU for doing this work. This is something that ROON should have implemented from the start and skipped the Airplay altogether. Other “Roon Ready” devices do use UPnP without issues by default (Cambridge Audio), and HEOS devices work with UPnP apps (Bubble UPnP), just not with Roon. So frustrating. Now I will have to convert my Roon Rock to a Windows machine, just to have this extension.
@Vladimir_Edelman I agree with your sentiments on Roon adding this, but so grateful to Peter for building a solution. No need to move server to Windows…just find a host for the extension. Rasp Pi is what I use. Simple and easy to implement.
They don’t use UPnP for good reasons it has a lot of limitations and every vendor does their own secret sauce so they all don’t work the same its got no proper certification process and is open to interpretation. I applaud Roon for not ever looking at it as it just doesn’t fit. Peter’s had to do so much to get it to work at all. I used the plugin it’s based on in the past when I used LMS and never got it to work properly at all with the UPnP kit I had, so I went full squeezbox and then Roon. UPnP is fine if you don’t want to mix and match from different vendors as soon as you do you realise its shortcomings and have it rely on 3rd party apps that also struggle.
It seemed less daunting than setting up a RaspberryPi, figuring out cooling, power, ethernet and having one more device running all the time in addition to the the rock/or windows machine that is already will be on 24/7.
Maybe I will give it a try with the pi first, because moving the whole library and transferring rock settings will bring it’s own challenges.
Thanks again for making it possible.
