I'm experiencing the same problem. Moreover, working with shoutcast is sometimes very frustrating: when selecting "Internet->Shoutcast Directory" the list appears blank, and to refresh it I need to hide and repoen side panel or to hide Amarok in tray and then restore. Maybe it's just my internet connection that is slow, but there is no progress bar that indicating that amarok is doing something (please reintroduce it as in Amarok 1.4...). The same thing happens when the list is finally displayed. If I open a category, the tree icon switches form "+" to "-", and the guitar icon changes into a loading icon, but the subtree never seems to open. Again I need to force refresh by hiding and reopening the window. Finally, when you select a station, again there is no progress indication for bufferization.

My system: Fedora 10 x86_64, KDE 4.2.4, Amarok 2.1 (but the problem persists from Amarok 2.0)

Setting to confirmed

This doesn't really have to do with filtering. The Shoutcast service stays blank randomly about half of the time.

This bug has been there since the beginning of time. Noone can figure out if KIO is to blame, or our code. I've checked our code and it looked OK.

With my Nostradamus hat on, I predict this bug will stay until judgment day and beyond.

Did this bug exist in 1.xx amarok?  I've only noticed it in Amarok 2.  

Is it just taking a (really) long time to load the station list, or is it succeeding in loading and just not refreshing the view?

Most of the time this manifests for me as the list being empty when I open the Amarok window; after repeated closing and reopening it eventually fills.  Today I also noticed the list suddenly populating while the window was open, making it seem like the download process had just finished in the background or something.

Is it possible to add a progress bar, or even if not progress, something to say that it's waiting for the station list to load?

Is it possible to cache the list?

The Shoutcast service in Amarok is buggy, and always have been, and this has directly to do with buggy code in Amarok 1.4, and, moreover, with buggyness in xine-lib managing Shoutcast streams. Xine had always managed those streams without any feedback, without letting me see if the thing is really connected, if it failed, or if it crashed. I still remember the "Philosocrash" (open Amarok 1.4, select the "Philosomatika" stream, and BOOM!, Amarok locks up!) Amarok 1.4 notified me of failures half of the time, and the other half it crashed because it didn't know what to do. Now, with Phonon and KNotify in the mix, Amarok doesn't tell me what is doing, Amarok keeps crashing, and Amarok isn't reliable with Shoutcast.

More than that: when Amarok crashes, I have to manually kill all kio-http processes related to Amarok. I have to do it because if I don't do it, I won't have any hope of making Amarok work.

My thoughts about this:

1. Xine isn't able to manage MORE THAN ONE Shoutcast stream at the time. KIO can and does manage more than one, almost all the time. So, when I limit myself to ONE Shoutcast connection (opening a list of streams, opening a stream), Shoutcast under Amarok works. When I have more than one connection open (say, I'm downloading a PLS and at the same time I try to listen to the stream I want to, or when I want to change streams quickly) Amarok refuses to work. You can replicate this almost all the time, and this explains this erratic behaviour.

2. I WANT and I NEED the same level of user notification that I had in Amarok 1.4, and that can be easily done with KNotify. KNotify is now stable, so, if the stream indeed failed, there must be a message in the KNotify queue.

3. Can you replicate this behaviour in Phonon and take any workaround available to avoid xine-lib buggy behaviour? Maybe the GStreamer backend work must be resumed (GStreamer does not have this problem, because it was designed to work concurrently from day 1) and Xine left in the dust.

Since the shoutcast services has been removed in Amarok 2.2, this report is obsolete.