"No UPnP" error appears on every other PPA update

[tehowe@…]

MythTV Version : v0.24.1-120-g294968b MythTV Branch : fixes/0.24 Network Protocol : 63 Library API : 0.24.20110505-1 QT Version : 4.6.2 Options compiled in:

linux profile using_alsa using_oss using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_crystalhd using_directfb using_dvb using_firewire using_frontend using_hdhomerun using_hdpvr using_iptv using_ivtv using_joystick_menu using_lirc using_mheg using_opengl_video using_opengl_vsync using_qtdbus using_qtwebkit using_v4l using_x11 using_xrandr using_xv using_bindings_perl using_bindings_python using_mythtranscode using_opengl using_vdpau using_ffmpeg_threads using_live using_mheg

"No UPnP" frontend message seems to come up upon the installation of *every other* PPA update. So for the updates that seem to knock out networked backend -> frontend connectivity, I have to use Mythtv at the server.

This is across my network, which has one central frontend/backend server and two wireless notebooks running slave frontends.

This pattern, though odd, has been consistent - I've been using MythTV for months now.

The server is Natty Ubuntu Studio , the notebooks are Lucid Studio and stock Natty, all on the Mythbuntu 0.24 PPA. The router, if that's relevant, is a Dlink DIR-628. I'm using an HDHomerun for capture.

Let me know how I can improve this report! Sorry I don't have more to go on, but I felt I had to file this as I've been living with it for a while now.

[tehowe@…]

frontend log, reveals database login fail

[robertm]

This sounds like something you will need to speak to your packager about-- we provide neither a PPA, nor binary packages of any kind.

[tehowe@…]

It took me a while to make some new observations, but I didn't think the packaging had anything to do with it.

So sure enough, once the most recent update for MythTV was pushed out, my backend was again no longer visible to the remote frontends on the network. This time I had gupnp handy, and was able to watch the uPNP activity on each box.

On this most recent version of MythTV (0.24.1-126) switching my VPN on or off is *another* way to disable MythTV's uPNP functionality. However, running the gupnp control monitor is enough to somehow kick the connection into an active state again, and all my frontend devices can see it.

Installing an update is probably disruptive in the same way flipping my VPN on is. (Once gupnp is running, however, I can use my server box either on the VPN or off, it seems irrelevant to the local network IP)

That doesn't seem like a downstream error, but a uPNP implementation issue - this bug should be open.