Server does not kill dead source mounts

--===============3226839553765656204==
Content-Type: multipart/alternative; boundary="0000000000003c16a90615884824"

--0000000000003c16a90615884824
Content-Type: text/plain; charset="UTF-8"

Hi all,

I've been completely stymied by this, and am finally reaching out after
exhausting all other options short of digging through the code.

I'm running 2.4.4 with and without TLS on two separate ports.  I find some
of my friends (who are using BUTT on Mac OSX) will drop their stream,
sometimes due to a network failure, or sometimes by manually pressing
"STOP" on their clients.

However, the mount point persists on the server, preventing them from
reconnecting until I manually either kill the source from the web UI, or
restart the server.  We're using "dynamic" mounts, where the client
specifies the name of the mount.  These are not preconfigured in the
icecast.xml file.

I ran an experiment last night, wondering if it was my network setup
(firewall/NAT/etc.) that's leaving these TLS connections stalled.  So, I
installed BUTT locally on a mac here inside the LAN, and did a direct IP
connection to the server, using the non-TLS port.  I pressed "stop" on
BUTT, but the source mount remains in the server admin UI, almost 24 hours
now since I stopped and shut down the BUTT app.  So I think I can eliminate
TLS and/or my network setup.

I don't see much, if any mention of this doing Google searches.

Anyone have any idea?  I have the source code, like I said, but haven't
gone digging into it yet to try to debug.  I'm a fairly skilled C/C++ dev,
so that's my next step.

Regards,
-p

--0000000000003c16a90615884824
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi all,<div><br></div><div>I&#39;ve been completely stymie=
d by this, and am finally reaching out after exhausting all other options s=
hort of digging through the code.</div><div><br></div><div>I&#39;m running =
2.4.4 with and without TLS on two separate=C2=A0ports.=C2=A0 I find some of=
 my friends (who are using BUTT on Mac OSX) will drop their stream, sometim=
es due to a network failure, or sometimes by manually pressing &quot;STOP&q=
uot; on their clients.</div><div><br></div><div>However, the mount point pe=
rsists on the server, preventing them from reconnecting until I manually ei=
ther kill the source from the web UI, or restart the server.=C2=A0 We&#39;r=
e using &quot;dynamic&quot; mounts, where the client specifies the name of =
the mount.=C2=A0 These are not preconfigured in the icecast.xml file.</div>=
<div><br></div><div>I ran an experiment last night, wondering if it was my =
network setup (firewall/NAT/etc.) that&#39;s leaving these TLS connections =
stalled.=C2=A0 So, I installed BUTT locally on a mac here inside the LAN, a=
nd did a direct IP connection to the server, using the non-TLS port.=C2=A0 =
I pressed &quot;stop&quot; on BUTT, but the source mount remains in the ser=
ver admin UI, almost 24 hours now since I stopped and shut down the BUTT ap=
p.=C2=A0 So I think I can eliminate TLS and/or my network setup.</div><div>=
<br></div><div>I don&#39;t see much, if any mention of this doing Google se=
arches.</div><div><br></div><div>Anyone have any idea?=C2=A0 I have the sou=
rce code, like I said, but haven&#39;t gone digging into it yet to try to d=
ebug.=C2=A0 I&#39;m a fairly skilled C/C++ dev, so that&#39;s my next step.=
=C2=A0=C2=A0</div><div><br></div><div>Regards,</div><div>-p</div></div>

--0000000000003c16a90615884824--

--===============3226839553765656204==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Icecast-dev mailing list
[email protected]
http://lists.xiph.org/mailman/listinfo/icecast-dev

--===============3226839553765656204==--