minidlna server not visible in network

[Stefan Esser]

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.)


Anyway: I had been using minidlna-1.1.5 for a few weeks in order to
test the patch that makes it use poll() instead of select() in order to
allow for large media collections (some 8000 directories in my case)
and kqueue() notifications for file changes.

I noticed, that no initial service announcements were sent, but given
enough time, the minidlna server would be noticed by clients. Since I
had not tested the unpatched minidlna-1.1.5 (without the poll-patch),
I had assumed that the problem was in my poll-patch.


I'd assume that the initial SSDP packet is not sent by minidlna. I do
not know whether the situation is fixed by a timer based SSDP packet
being sent at a later time, or by the client trying to reach the server
(but I guess the latter case applies).


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.

Since I do not have time to further diagnose this before mid of January,
I went back to 1.1.4 for the time being.

Regards, STefan