Hi,

I've installed mediatomb on my PC but it doesn't launch at boot because
the interface I've specified in the config file with <interface> doesn't
exist at the point when the program is ran. The following is present in
the log file:

2009-06-24 09:18:51   ERROR: Could not determine interface address:
Cannot assign requested address
2009-06-24 09:18:51   ERROR: Could not find interface: eth3

It works if I restart via the init script after the machine is booted.

I tried moving the script later in the sequence by increasing the place
in the init ordering but this had no effect.

Iain

# Automatically generated email from bts, devscripts version 2.10.35lenny3
#also happens in sid
found 534504 0.12~svn2018-3

Similar problem here. eth0 is managed by Network Manager, so it's not
brought up until the user is logged in, long after /etc/init.d/mediatomb
runs.

Possible solutions:
1) Manage eth0 with /etc/network/interfaces, bypassing Network-Manager.
/etc/init.d/ifupdown runs before /etc/init.d/mediatomb

2) Startup Mediatomb as a user. Change /etc/default/mediatomb to
nostart=yes, and run as a user, "mediatomb --daemon --logfile
/home/user/.mediatomb/mediatomb.log" etc.

3) Have a user "sudo /etc/init.d/mediatomb start" after they've logged
in.

Options 2) and 3) can both be automated, but both depend upon the user
being logged in for eth0 to be available. Use option 1) if you want the
media server to be always on no matter who is logged in.

BDL

/etc/network/interfaces was my workaround too. My connection was
managed as a systemwide connection by NM. I'm not sure when it comes
up in this case. I guess mediatomb could keep retrying or block on
some signal if one exists in this case.

Hello,

to solve the problem described by other persons, I've created two small
scripts that start and stop mediatomb when the interfaces are being
brought up and down. There is also a diff file for
/etc/default/mediatomb that adds a variable DELAYED (yes/no) to
disable/enable those small scripts.

Few remarks:

1. the current default is DELAYED=yes, which enables the script. It
doesn't really hurt as mediatomb is restarted, and should work in all
situations (with and withou NetworkManager).

2. I'm not sure I correctly understood the meaning of the "INTERFACE"
variable (mine is empty), so my check might be incorrect as I only restart/stop
if the interface given by INTERFACE is being stopped/started
($IFACE = $INTERFACE). Someone with more knowledge of mediatomb's internas
might want to check if this is the right decision.

3. if INTERFACE=lo, then the scripts do something if and only if the 'lo'
interface is brought up or down, again, it might not be the right logic.

4. the attached tar file contains the files and diff with correct
relative position (don't unpack in root direcotry unless it's what you want
to do!).

Hope this helps,
Eric

I understand from the context of the bug that the issue seems to be that
mediatomb must not be started before the network interface is up and
running. Why can't this be fixed be changing the initscript ordering?

The race condition is present on *all* systems, so no need to make this
fix configurable.

What about the case that a system has 2 interfaces and mediatomb is
serving to both interfaces at the same time: Restarting one interface is
likely to disconnect users connected via that interface, but would this
affect users via the second interface as well?

I guess this is a saftey guard to avoid unnecessary restarts if
mediatomb is configured to serve only on one specific interface and
other interfaces are restarted. Which seems to suggest an answer to my
previous question.

what do they do exactly?

I see that your if-updown scripts call the init script. That means that
depending on the context the init script is called, it behaves
differently. I find this a bit odd.

How about dumping the init script altogether and implement starting and
stopping mediatomb solely from if-updown scripts? This way there was no
need for the DELAYED=yes flag and the race condition would be avoided as
well.

Simplest thing to do I think would be to have the if-updown scripts just run
the mediatomb init script.

https://bugs.launchpad.net/ubuntu/+source/mediatomb/+bug/212441/comments/19

Here's a patch for this bug I've been using on Ubuntu. Note that it uses
upstart, so probably won't solve the problem for pure Debian.

Still, it would be nice if we could push this patch or something like it
into the Debian source rather than relying on downstream Ubuntu patching.

- Daniel

Dear submitter,

as the package mediatomb has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see http://bugs.debian.org/662020

The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@debian.org.

Debian distribution maintenance software
pp.
Luca Falavigna (the ftpmaster behind the curtain)

Hi!

The real problem here is that it seems mediatomb unneedingly forces
itself to know the IP of an (outbound) interface at startup and refuses
to work otherwise. Here's a quick (and possibly bogus) analysis of the
code involved:

,---
src/tools.cc (interfaceToIP):

  Returns nil and logs an error if it cannot retrieve the IP of the
  interface (which I guess is more or less fine, although the output
  is annoying).

src/server.cc (Server::upnp_init):

  Calls interfaceToIP(iface) if there's no explicit IP specified to the
  daemon, and aborts if one cannot be retrieved, otherwise calls
  UpnpInit() with the IP, port, etc. Then calls UpnpGetServerIpAddress()
  again to retrieve the found address if the IP was not valid (which
  cannot be because we've bailed out before). It also tries to start
  sending UPnP advertisements.

tombupnp/upnp/src/api/upnpapi.c (UpnpInit):

  If HostIP is !NULL it uses that as LOCAL_HOST, otherweise it tries
  again to retrieve a local host IP and uses that instead as LOCAL_HOST
  (all this by crawling through the physical interfaces).
`---

The correct and proper fix seems to me, would be to:

  1) If either no explicit interface or IP has been specified on the
     command-line, use getaddrinfo with node == NULL and
     hints.ai_flags == AI_PASSIVE, so that we get the INADDR_ANY.
  2) Bind to that address for listening.
  3) Move the IP retrieval and interface sieve for when sending
     outbound advertisement messages, and handle the case of no
     interfaces being UP or only loopback as non-errors.

I'm not sure how much work that would imply though, but a media server
like minidlna is doing something like that (not to mention the myriad
of other server software around), and works just fine w/o an initially
setup (outbound) interface.

(BTW, while digging I noticed there's an embedded fork of libupnp,
which from a quick look does not seem to handle this gracefully
either...)

regards,
guillem

I just had a fresh install of Debian 7.7.0, and had the same problem with
mediatomb. After I configured INTEFACE to eth0 in /etc/default/mediatomb I
got this error in /var/log/mediatomb.log at startup:

2015-01-09 22:46:08   ERROR: Could not determine interface address: Cannot
assign requested address
2015-01-09 22:46:08   ERROR: Could not find interface: eth0

The problem appears to be in minissdpd service. For some reason it was
added to startup together with mediatomb. I don't know which dependency
pulled this service and why it was enabled by default. After removing
minissdpd package I have meditomb running just fine at startup.