From owner-freebsd-ports@freebsd.org Sun Dec 20 08:11:59 2015 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9822BA4DA91 for ; Sun, 20 Dec 2015 08:11:59 +0000 (UTC) (envelope-from se@freebsd.org) Received: from mailout08.t-online.de (mailout08.t-online.de [194.25.134.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 624341F18; Sun, 20 Dec 2015 08:11:59 +0000 (UTC) (envelope-from se@freebsd.org) Received: from fwd13.aul.t-online.de (fwd13.aul.t-online.de [172.20.27.62]) by mailout08.t-online.de (Postfix) with SMTP id D9CD17A413; Sun, 20 Dec 2015 09:02:01 +0100 (CET) Received: from [192.168.119.17] (XV4w6uZcohiqYTll465E-EIhWKAb9Wl6lmKf4lVyKDqXQ+M9qLfqkZA7wLS8QmLQjy@[84.154.99.156]) by fwd13.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1aAYwI-2Ho0iO0; Sun, 20 Dec 2015 09:01:58 +0100 Subject: Re: minidlna server not visible in network To: freebsd-ports@freebsd.org References: <20151218230340.62617190@kirk> <56753EE1.9090203@b1t.name> <56755184.8020105@FreeBSD.org> From: Stefan Esser X-Enigmail-Draft-Status: N1110 Message-ID: <56766075.7030305@freebsd.org> Date: Sun, 20 Dec 2015 09:01:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <56755184.8020105@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ID: XV4w6uZcohiqYTll465E-EIhWKAb9Wl6lmKf4lVyKDqXQ+M9qLfqkZA7wLS8QmLQjy X-TOI-MSGID: e7a41536-361d-4184-baf6-4ce9da9bd8e4 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2015 08:11:59 -0000 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