[Icecast] Strange behaviour with admin/stats.xsl disappearing

[epirat07 at gmail.com]

Hi,

On 2 Sep 2024, at 12:19, Marek Dziembowski wrote:

> Greetings icecasting amigos!
>
>
> I’ve had an incredibly frustrating journey getting a new icecast origin server going to supplant an older machine set for retirement.
>
> The setup is relatively simple – a beefy Debian bookworm host running icecast as a relaying slave pulling the streamlist from an icecast2 2.4.4 ingest server, for mass distribution.
> The ingest / origin server runs fine.
>
> I opted for compiling the latest icecast-kh for the slave, but ran into issues with the host unable to fetch the master streamlist to relay. (I think due to compiling without explicitly including libcurl?)

This list is not for Icecast-kh related matters, at this point Icecast-kh is quite diverged from Xiphs Icecast.

If you need help with that, you should seek it elsewhere, where people are more familiar with that, not on the
Xiph Icecast support list.

>
> I then got the prior icecast-kh compiled and it relayed fine, but then I ran into rather bizarre problems consistently displaying the admin/stats.xsl web interface…
> I then tried with icecast2 installed from Debian dpkg, but got annoyed with ssl shortcomings, going back to latest icecast-kh - now with libcurl - and got the relaying working fine with ssl sorted.
>
> But the same issue with the adminpages persist:
>
> After starting the icecast service, the admin/stats.xsl displays as a webpage perfectly, as does /index.html. When trying to open a bogus path that doesn’t exist, the page with text “The file you requested could not be found” is returned as expected.
> When opening any bogus after /admin in the path eg. /admin/statserf, the <icestats> xml is returned.
>
> All fine after startup / restart - but it doesn’t function correctly this way for very long.
>
> After an indeterminate while the admin/stats.xsl and index pages start to return browser’s 404 not found.  (not the page with text “The file you requested could not be found” as above)
> However the icecast xml versions are returned fine.
> And any bogus url – random path will return the expected /admin/stats.xml
>
> Nothing I do can restore the normal admin web pages until I restart the icecast service!!

Are you sure you do not have multiple things listening on the same port, possibly one for IPv4 and the
other with IPv6 or your OS set in a way that it would permit multiple listening processed on the same port?

Make sure you actually see the request for which you get the unexpected response in the Icecast access log,
if you do not, it never gets to Icecast in the first place.

>
> And just as luck of murphy would have it –I cant replicate the problem this morning and it seems to be working normally so far…. But why / how did icecast behave that way before – and how to address the issue if it occurs again?
> I cant just continually restart icecast and kick hundreds of listeners off every time!
>
> Any insight / advise would be greatly appreciated!
>
> Oh and PS: little to nothing substantial to be found in the error.log ☹
>
> Thanks!
> Marek
>
>
>
>
>
>
>
> [cid:image001.jpg at 01DAFD29.32B218F0]
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast