Date: Mon, 21 Dec 2015 15:15:28 +0100 From: Guido Falsi <madpilot@FreeBSD.org> To: Stefan Esser <se@freebsd.org>, freebsd-ports@freebsd.org Subject: Re: minidlna server not visible in network Message-ID: <56780980.60203@FreeBSD.org> In-Reply-To: <56766075.7030305@freebsd.org> References: <20151218230340.62617190@kirk> <56753EE1.9090203@b1t.name> <56755184.8020105@FreeBSD.org> <56766075.7030305@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/20/15 09:01, Stefan Esser wrote: > Am 19.12.2015 um 13:45 schrieb Guido Falsi: >> On 12/19/15 12:26, Volodymyr Kostyrko wrote: >>> On 19.12.15 00:03, Dr. Peter Voigt wrote: >>>> Today I have upgraded net/minidlna to latest version. I am on FreeBSD >>>> 10.2-RELEASE-p8 (amd64). >>>> >>>> Access via web interface on port 8200 is working fine. But the MiniDLNA >>>> server is not seen in my network and correspondingly I cannot access >>>> any of my FLAC audio files. I do not host any other media besides the >>>> FLAC files. >>>> >>>> I strongly assume this is related to upgrading to version 1.1.5. >>>> >>>> Can anyone reproduce this behavior? >>> >>> That's not correct. >>> >>> 1. If you already queued any files on your UPnP client whey will play >>> correctly. >>> 2. If you leave you UPnP client open for some time it will eventually >>> find your server. >>> 3. If your UPnP client is already open restarting minidlna will make it >>> visible. >>> >>> So I'd say it just fails responding to probes. >>> >> >> I posted a reply to the bug report. >> >> I'll investigate this one further in thee next few days. I'll followup >> in the bug report with anything I find out. > > I tried to add some information to the bug report, but bugs.freebsd.org > denied access and there does not seem to be a way to reset the password. > (I thought it was the Kerberos password, but that did not work.) > AFAIK it IS the kerberos password. Don't knoww why it's not working for you. > > A sensible test would be a tcpdump of traffic between minidlna server > and a client, that is started before the minidlna server. My guess is, > that minidlna replies to a client polling for reachable UPnP servers, > and that minidlna does not announce its availability when started, but > only in response to clients polling for a server. I did a tcpdump, but I also discovered why I could not notice this problem. I run minidlna in a jail, and jails don't get multicast packets, so in my case mindlna never replies to those probes anyway, that's why I lowered the announce timer, which is a good workaround but not a real solution to the problem. To the OP, Are you using minidlna in a jail on on the base machine? I'll repeat the test with minidlna on my base machine soon, so I can check what's different. Next step, locating the code which should reply the probes in minidlna and check for diffs against the previous version. -- Guido Falsi <madpilot@FreeBSD.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56780980.60203>