description.xml not served when GUI disabled about gerbera

[whyman]

So this is an interesting one as we only enforce that setting in web_callbacks.cc and we provide pupnp with a buffer of the xml description so it should be always provided.

We also don't do any initialisation of the library different in either case... I wonder if we are running into a pupnp bug here?

My C is even worse than my C++ so perhaps @gburca could take a look at pupnp?

It certainly sounds like https://sourceforge.net/p/pupnp/bugs/8/

[whyman]

Can you try e4c0f5c?

[whorfin]

Good news and bad news.
Good news - that fixed it! description.xml is now published when "ui enabled=no"
also - if I go to the GUI url, I briefly see the GUI before being redirected to a "disabled" page
whereas before this was a straight up 404. there might be some exploits there...

Bad news - things seemed to get a little more fragile as far as SIGHUP is concerned, which might explain the messages and warnings in the code and references to pupnp...
Typically a single SIGHUP results in nothing being served and audio playback dying.
A second or third SIGHUP is needed to get things working again.
after which, a SIGHUP will break it again...
Log appears reasonable, showing the restart, but serving is down until the SIGHUP dance happens
the right number of times.

Big progress regardless, thanks!

[whorfin]

...also, after a clean shutdown, this version will sometimes come up not serving files, until the SIGHUP dance is done.
...turns out, the previous version [before this commit] had the same issue some times; looking through the logs, I can see that the "Initialized port:" is actually incrementing, and not the one specified.
It will usually come back around to the requested port.

Also, doing some SIGHUP testing I also saw some database troubles:
ERROR: Exception caught: error while doing select: [big SELECT statement]
Exception raised in [/home/whorfin/mediatomb/mediatomb-whorfin/src/storage/sql_storage.cc:936] _findObjectByPath(): error while doing select: [same big SELECT statement]

So I don't think this version is actually a regression, as the SIGHUP issue pre-exists, but may be made worse in some circumstances.

[gburca]

I've seen that problem as well where it starts on the next port, as if the one it's configured for is in use. This has been happening since forever in my case. I tried waiting a bit after the shutdown thinking the restart is happening too fast, but it didn't seem to make a difference.

[whyman]

Okay great. Lets close this and @whorfin can split out the SIGHUP stuff into a new issue.