Updated: 8 October 2026 · Applies to: Centova Cast v3 (3.3.4, from Centova documentation); script checks tested with Icecast 2.4.4, curl 8.14.1 and jq 1.7.1 on Debian 13

No. According to Centova, when a script connects to your stream's audio feed (the same URL that listeners tune in to), Centova Cast has no way to tell it apart from a real media player, so every connection is saved as a listener session in your statistics. The fix is in the script: make it read the streaming server's status page, a Centova Cast widget or the Centova Cast API instead. Centova Cast does not count status page requests as listener sessions.

Why polling the audio feed is a problem

  • Useless statistics. Uptime monitors, "now playing" scripts and bots that open the stream every few seconds leave thousands of one-second sessions, so listener counts and listening hours stop meaning anything.
  • Slow statistics pages. According to Centova, scripts that poll several times a second can grow the statistics table (visitorstats_sessions) to several gigabytes, and the statistics pages then load slowly or time out. See Centova Cast statistics pages load slowly or time out.
  • Wasted bandwidth. Each poll downloads audio. In our test every one-second request to the feed transferred between about 50 and 70 KB.

What a test showed

We ran Icecast 2.4.4 in a container with a test source on /live.mp3, then sent 10 requests to the status page and 5 one-second requests to the audio feed. Icecast's own listener_connections counter (from /admin/stats) did not move for the status page and went up by one for every audio request:

== before
<listener_connections>3</listener_connections>
== 10 status page requests
200 200 200 200 200 200 200 200 200 200
<listener_connections>3</listener_connections>
== 5 audio feed requests
<listener_connections>8</listener_connections>

According to Centova, the streaming server's access log is what Centova Cast uses to build your statistics. In a second run, the status page requests and the audio requests looked like this (timestamps removed):

"GET /status-json.xsl HTTP/1.1" 200 825 "-" "curl/8.14.1" 0
"GET /status-json.xsl HTTP/1.1" 200 825 "-" "curl/8.14.1" 0
"GET /status-json.xsl HTTP/1.1" 200 825 "-" "curl/8.14.1" 0
"GET /live.mp3 HTTP/1.1" 200 49276 "-" "curl/8.14.1" 1
"GET /live.mp3 HTTP/1.1" 200 57676 "-" "curl/8.14.1" 1
"GET /live.mp3 HTTP/1.1" 200 67476 "-" "curl/8.14.1" 1

The last number is the connection time in seconds, and the user agent (curl/8.14.1 here) usually gives the script away. In Centova Cast you can see the same details under Statistics > Listeners (IP address, user agent and listen time of everyone connected) and Statistics > Logs (the access log).

Better ways for a script to check your stream

  1. Centova Cast API (SHOUTcast and Icecast accounts). The server.getstatus method returns, according to Centova, fields such as sourceconnected (1 or 0), listenercount, currentsong and bitrate. Centova recommends POST rather than GET, because GET parameters (including your password) end up in the web server's access log. Use your stream's username and password and the address you use to log in to the panel:
    curl -s https://panel.example.com:2199/api.php \
      -d 'xm=server.getstatus' -d 'f=json' \
      -d 'a[username]=YOUR_USERNAME' \
      --data-urlencode 'a[password]=YOUR_PASSWORD'
    With -d, curl sends a POST request. --data-urlencode protects passwords that contain characters such as @ or &: in our test the password p@ss&word was sent as a[password]=p%40ss%26word.
  2. Icecast status page. Icecast 2.4 (we tested 2.4.4) serves a JSON status page at http://SERVER:PORT/status-json.xsl. This script reports UP only when a source is connected to the mount point, and never opens the audio feed:
    #!/bin/sh
    # Reads the Icecast status page; never opens the audio feed.
    STATUS_URL="http://127.0.0.1:8000/status-json.xsl"
    MOUNT="/live.mp3"
    
    if curl -fsS --max-time 10 "$STATUS_URL" \
       | jq -e --arg m "$MOUNT" '[.icestats.source] | flatten | map(select((.listenurl // "") | endswith($m))) | length > 0' >/dev/null
    then
        echo "UP"
    else
        echo "DOWN"
        exit 1
    fi
    In our test it printed UP with one mount and with two mounts, and DOWN (exit code 1) when the /live.mp3 source stopped and when no source was connected at all. The listener counter stayed the same throughout. Replace the address, port and mount with your own (shown in your Centova Cast panel).
  3. Centova Cast widgets for websites. To show the current song, listener count or online status on your site, use the code from Configuration > Widgets (for example Stream Status Summary or Stream Details). They get their data from Centova Cast and refresh it at regular intervals, so you do not need your own polling script.

Whichever method you use, checking once a minute is plenty for uptime monitoring.

Cleaning up statistics that are already affected

Fixing the script stops new bogus sessions, but it does not remove the old ones. If you have root access (for example on a Centova Cast dedicated server), this article shows Centova's SQL queries to find the account with the most sessions and delete its old ones. On our Shoutcast and Icecast hosting or reseller accounts the statistics database is on our server, so open a support ticket with the account username and ask us to check it.

Related: the Current Listeners page is not showing the current listeners and the current song does not show on my website.

Official documentation: Centova: statistics pages load slowly or time out, Centova Cast JSON API.

Was this answer helpful? 26 Users Found This Useful (339 Votes)