Summary
FastPlay 0.6.6 fails to play two working Polish Radio Browser entries:
Both endpoints are currently reachable and advertise a 128 kbps audio/mpeg stream, but playback does not start in FastPlay.
Steps to reproduce
- Open Internet Radio.
- Choose the Radio Browser search.
- Search for
Radio eM.
- Try to play either Radio eM (homepage: radioem.pl; Katowice) or Radio eM Kielce.
Expected result
The selected station starts playing, like other MP3 radio streams.
Actual result
Playback fails for both stations.
Protocol details
The two streams expose useful edge cases:
Radio eM Katowice
The server returns the legacy Shoutcast status line:
ICY 200 OK
content-type: audio/mpeg
icy-br: 128
icy-metaint: 4096
It identifies itself as Shoutcast DNAS 1.9.4.
Radio eM Kielce
The direct URL intentionally ends in a semicolon. The server returns:
HTTP/1.0 200 OK
content-type: audio/mpeg
icy-br: 128
icy-sr: 44100
icy-metaint: 16384
It identifies itself as Shoutcast DNAS 2.6.1. The trailing ; should be preserved when resolving or normalizing the URL.
Suggested direction
Could FastPlay preserve unusual but valid Radio Browser stream URLs and add a tolerant fallback for legacy ICY/Shoutcast responses when the normal BASS URL open fails? It may also help to expose/log the exact BASS_ErrorGetCode() value after each failed attempt, so it is clear whether the failure happens during URL resolution or stream creation.
This should preferably be a general compatibility fix rather than a station-specific exception.
Additional compatibility/regression candidates
These have also caused intermittent compatibility problems in other players. They are not yet confirmed as the same FastPlay failure, but would be useful regression cases for the general radio-stream handling:
Together these cover legacy ICY status lines, HTTP/1.0 Icecast responses, OGG and MP3 streams, PLS resolution, redirects, unusual URL endings, and ICY metadata.
Summary
FastPlay 0.6.6 fails to play two working Polish Radio Browser entries:
Both endpoints are currently reachable and advertise a 128 kbps
audio/mpegstream, but playback does not start in FastPlay.Steps to reproduce
Radio eM.Expected result
The selected station starts playing, like other MP3 radio streams.
Actual result
Playback fails for both stations.
Protocol details
The two streams expose useful edge cases:
Radio eM Katowice
The server returns the legacy Shoutcast status line:
It identifies itself as Shoutcast DNAS 1.9.4.
Radio eM Kielce
The direct URL intentionally ends in a semicolon. The server returns:
It identifies itself as Shoutcast DNAS 2.6.1. The trailing
;should be preserved when resolving or normalizing the URL.Suggested direction
Could FastPlay preserve unusual but valid Radio Browser stream URLs and add a tolerant fallback for legacy ICY/Shoutcast responses when the normal BASS URL open fails? It may also help to expose/log the exact
BASS_ErrorGetCode()value after each failed attempt, so it is clear whether the failure happens during URL resolution or stream creation.This should preferably be a general compatibility fix rather than a station-specific exception.
Additional compatibility/regression candidates
These have also caused intermittent compatibility problems in other players. They are not yet confirmed as the same FastPlay failure, but would be useful regression cases for the general radio-stream handling:
audio/ogg, 128 kbps, 48 kHz stereo.audio/mpeg, 128 kbps, ICY metadata.http://radio.tyflopodcast.net/.audio/mpeg, 192 kbps. The HTTP address redirects to HTTPS.Together these cover legacy ICY status lines, HTTP/1.0 Icecast responses, OGG and MP3 streams, PLS resolution, redirects, unusual URL endings, and ICY metadata.