Port conflict with any UPNP server

[fluffypony]

I run AirServer Universal on my media centre PC, which hogs port 5000, as it's the standard UPNP port (so it's used for auto-discovery by the protocols AirServer uses).

Unfortunately, ScreenBloom provides neither a command-line option to set the port, nor does it use an ostensibly-unused port. It also doesn't handle the failure - it appears to have started just fine, but since the HTTP call just never returns the browser sits with a blank window, waiting for a response.

I would recommend either picking a port not already in use by a major protocol (here's the GRC port DB entry for port 5000, and the SpeedGuide entry for port 5000), or at least handle a port conflict better than silently failing but appearing to be running.

My python-fu is, unfortunately, quite weak otherwise I'd do the latter myself and submit a PR, and I don't want to make a major change (like the default port) on someone else's project:) Thanks for the excellent work!

[kershner]

Hey there! I wonder what version of ScreenBloom you're running? I can't remember when I introduced it, but there is definitely handling for port collision in the latest version.

Check this guy out: https://github.com/kershner/screenBloom/blob/master/app/modules/startup.py#L103

If a socket error is encountered it should just increment the port until it can connect.

[fluffypony]

@kershner I'm running 2.2, downloaded a few days ago, so it should be current.

netstat -a -b definitely shows AirServer.exe listening on port 5000, and killing AirServer.exe makes ScreenBloom work just fine.

[kershner]

Well that's annoying, haha. socket.error totally catches port collisions like that on Windows. I'll add this to the list of things to investigate. Thanks for bringing it up!

[fluffypony]

No problem, let me know if I can help test anything:)