Disable AirUPnP?

[allizo]

Is there any way to disable AirUPnP if I don't need it?

[1activegeek]

Unfortunately, there is not. I focused on ensuring this was easy and works for either method users are needing. Is there a specific reason you desire turning off the AirUPnP functionality?

[allizo]

In my home environment, there are certain devices that appear more than once, and I have quite a few devices throughout the house. For example, I have certain TV’s that show up on my AirPlay list because of AirUPnP, but those same TV’s also have Chromecasts plugged in which are picked up by the AirCast package and also displayed on my list of AirPlay devices. In my testing, Airplay to Chromecast devices has been a lot more stable, and it would be nice to have an option to remove all of those duplicate devices picked up by AirUPnP.

[allizo]

By the way, thank you for your work on this project. This has been the easiest way to set up AirPlay to Chromecast devices by far.

[1activegeek]

Ahh, got it. My quick suggestion might be to leverage the config files to rename the extra devices. Perhaps specifying them to be a z_dontuse/2/3/4 etc might work. Not perfectly elegant, but def an option for a short term patch. Longer term, it will definitely take some more work on the logic of the container. Unfortunately at the moment I just don't have the bandwidth to dig in and adjust the startup scripts to account for this. I'll leave this open though as an enhancement request and come back to it if I'm able to.

Thank you for the kind words as well, though I think more credit is due to the creator of the app than me. I'm just an admirer who wanted a quick/easy/portable way to run the app.

[allizo]

Of course. I’ll share the kudos with them as well. Much appreciated!

[dmatora]

So why not check for some ENV var and only start one daemon if requested?

[1activegeek]

Feel free to make a pull request. As mentioned - I don't have the bandwidth at this time, and will require testing once code is pulled to have the test building recreated with the new GitHub actions.

[dmatora]

This is little above my head, never worked with docker hub For now just connecting to container console and killing one of processes does the job

[cbckly]

I desire the disabling of one of the services as well as it just creates menu clutter. It doesn't look like we'll get this functionality, but you can work around it.

Using the customization environment variables, you can ask the service to do some discovery and then exit.

In my case, I don't want aircast (ChromeCast->AirPlay) to stay running so I set: -e 'AIRCAST_VAR'='-i /tmp/discoverandexit.xml'

You can do the same thing to airupnp (UPNP, Sonos, Heos, etc->AirPlay) with the AIRUPNP_VAR variable.

[1activegeek]

Thanks for the workaround! Sounds like a nifty little way to achieve the desired outcome. I will look back into making this a built-in option, but a bit stretched thin with the holidays and having to move my entire smarthome system to a fresh platform. On top of that, the builder is actually failing now to re-build weekly, so I have to dive into that firstly, but this is still on my radar.

[1activegeek]

K folks, the time has come. I've now enabled the AIRCAST_VAR and AIRUPNP_VAR to accept kill as their entry. This will essentially remove the startup file that runs these binaries. If you'd like to test it out before it goes to master, use the :dev tag when running. This version currently has this logic available and running. If no issues arise, I'll close this issue out.

Sorry again for how long it took, but as promised it was on the list! 😛

[joshuacurtiss]

Greetings, I'm a silent beneficiary of your excellent wrapper for airconnect for quite some time and just had some problems and found this, thought I'd share here, hope you don't mind. I used AIRUPNP_VAR=kill to avoid port conflicts with Plex and it works great, except the services don't come back correctly when a container with this env variable is restarted. If it is recreated, it then works again. Is anyone encountering this?

[1activegeek]

Thanks for sharing this - it's a good point. I see what I believe to be happening, and on a restart the startup script is having an error because it's trying to do a sed and failing which I believe may be breaking the file. Let me work on getting an adjustment made and pushed out.

[1activegeek]

Ok I did a bunch of head banging to realize what the real error was - I used sed to eliminate lines by number. If you restart the container, it would then delete those lines again, which was in turn removing the config needed to run by supervisor. 😄 I finally realized my error when I stopped and actually logged into the container to see the state of things. Long story short, I modified some logic in the 30-install to now be able to check if it already commented the line, then skip, or on first run, comment it out.

Try out the :dev branch and let me know how it goes @joshuacurtiss. That should be functioning now, and should work on a reboot as well. If anyone happens to run this on other ARCH as well, please chime in and let me know how it's working. Just want to be sure I'm not playing whackamole with my logic in this key startup file! 😛

[joshuacurtiss]

I confirm that the dev branch works on restart as well as destroying and recreating! 👍 Very nice, thanks for your prompt attention!

[1activegeek]

Think I missed closing this one out, but after some up and down lately, I think we've got this one nailed pretty good. Please feel free to use latest branch as this is the most current version that is working for all architectures.