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

[Marek Dziembowski]

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

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!!

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]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20240902/6083cbbc/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 180354 bytes
Desc: image001.jpg
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20240902/6083cbbc/attachment.jpg>