It is a 1,1 mB zip file containing 1) the Java application and 2) the manual. The manual explains the architecture, how to install it, how to configure it etc.
Next I’ll make the source code of the current version available via a github repository.
I use watchtower to update the other containers when they get updated on dockerhub. IIRC I had to ssh onto the qnap to get it running (no way to pass the docker.sock via the GUI) but keeps everything shiny.
I also see the problem where the Naim app switches to the UPnP input after starting the stream. This could be a big problem for wider adoption if the only solution is for people to run the proxy in a different subnet to their audio gear.
The most obvious way to run it is on the NAS that runs your UPnP server which is going to be on the same subnet as the streamers. If the only workaround is running a dedicated device on a different subnet I think this would put a lot of people off.
I wonder if there’s a solution to this? I know you’ve asked Naim for help. @stevesky, can you explain why this happens and whether there might be a simpler workaround?
The documentation you have written is very thorough and explains the setup process well. However, I do think that containerising the app would simplify installation and management for the majority of users. I’d be happy to have a go at this when you have the code up on Github.
The device switching over to UPnP is because it’s pushing the product firmware into a use-case that it doesn’t really handle. aka - it’s a Vtuner URL pointing to a raw FLAC file. The code just assumes that somehow the system has been asked to play a music file and treats that as UPnP as the fall back.
As this is a private project thing (and top work on getting this all working), we won’t be putting any extra logic in product side to support it.
What gets returned to the Naim is a Wav, not a Flac (as I don’t get this working on a Naim).
If the “address-of-the-proxy” is in the same subnet as the Naim, the app swiches to UPnP. If I put the proxy in another subnet, like the Cloud, or even another subnet in my own local network, than it works as expected; the app perceives the URL as an iRadio URL.
So nothing to do with the music format, but all with the network. It looks like the app considers an iRadio station in the same subnet as an UPnP device.
Set this up today on my NAS - I already had a Ubuntu VM on my Synology DS220 with static IP, java and ffmpeg so it took 30 seconds to install.
Absolutely fabulous effort. I’ll likely bind a second IP to the Ubuntu box on a different subnet and add routes to BT smart hub (wifi-cable interchange) and Cisco to get round the uPnP issue, but I could happily live with as it is! Guessing I’ll need to hack the code to choose which IP FWP binds to.
Indeed, if you’ve the supporting things like Java, a static IP etc installed, than it’s just a matter of extracting the file, changing some paths and you’re done.
I’m not a die hard GitHub guy. I’ll duplicate my private repo to a public one and post the info here.
The application logic is, according me , quite straigth forward. There are also some “experimental” bits in it, currently not used, but maybe useful and inspirational for others.
I’ll write some documentation and hope to publish this in one of the coming days.
Binding a second IP address in another subnet on the same network interface is easy.
Although not a network expert, I guess the device (in my case also a PI running Minim in the same subnet as the Naim) has to act as gateway than? Don’t see how to add a route on my home router.
Thats’s correct. Gen 1 devices block FLAC radio stations.
Adding http://158.101.168.33:9000/xxxx in vTuner, where xxxx refers to one of the “Path” entries in the table above, will give you the FLAC stations in WAV.
So, for RP, replace xxxx with one of these in red.
I was getting drop outs fairly frequently so I stick to my minimserver flac streams. But recently I had the RP main mix running while my NAS was offline and it didn’t buffer once during the half hour I listened.