On Mon, 12 Feb 2024 11:35:30 +0000
Philipp Schafft <phschafft at country.loewenfelsen.net> wrote:
> Good morning,
>
> as nobody else jumped in, let me try to figure it out. :)
>
> On Mon, 2024-02-05 at 16:33 -0700, Dave Serls wrote:
> >
> > ?I'm using the Debian stable version 3.4.4-4 with the original
ices.
> > ?Yes, that's correct. Up to 3.4.4-1? all has been well.
> > ?Some type of protocol error is producing:
> > ?? EROR connection/_handle_connection HTTP request parsing failed?
> > ?? EROR admin/admin_handle_request Error parsing command string or
> > ?? unrecognised command: !POKE
>
> POKE-requests are part of libshout performing detection of sever
> features and bugs. This is for compatibility with both very old
> Icecast servers or when for example talking to some other software
> that never implemented everything.
>
>
> > ?? on every change of tune.
>
> I'm not sure about this part. My guess is that you talk to ICY
> metadata updates in the legacy format support. From having a quick
> look at the code, it might be true that libshout does a POKE here for
> every update.
>
>
> > ?? Needless to say ices has not changed in many a moon.
> > ?? What other icecast.xml change might produce this?
>
> This is something related to libshout's implementation. So an update
> on that might have changed things. Also keep in mind that this is
> purely source client side, so this doesn't depend on the Icecast or
> it's config at all.
>
> So generally speaking this is totally fine to happen. And not a
> problem at all. No actions required.
> If in fact it does this for every update in the legacy code path that
> is a bit unfortunate. Maybe we can have a look at that and see if we
> can cache the result. But beside an error.log entry there is no harm
> to it.
>
> Hope that helped! :)
>
>
> With best regards,
>
Thanks much, Philipp. When I saw that libshout was the origin, I
realized that Icecast was not involved, but knew that you could
sort it out. This use-case is a hobbyist imbedded audio server on
old i386 hardware. I have the luxury of not needing to upgrade.
Thanks again.
--
************************************************************************
* Dave Serls Littleton, CO, USA *
* dashs.denver.co.us http://www.dashs.com *
************************************************************************