I hate RealPlayer (or RealOne Player as the latest version is called). I have many reasons to hate it. I hate having to use it in the absence of an alternative. I’ve griped about it before, but one thing pisses me off more than anything else.

I like to listen to the radio, and I often listen to both live and pre-recorded broadcasts via the internet. The whole raison d’être of compressed streaming audio is to squeeze a reasonable sounding audio presentation down a narrow pipe.

Is it completely inconceivable, then, that those same narrow pipes might sometimes suffer from network problems? Sometimes, the network is congested. Sometimes—shock! horror!—the link is lost.

These should not be insurmountable problems. In fact, I argue, they should be expected. It’s in the nature of the medium.

So let’s look at what happens when you listen to an audio stream in RealPlayer and lose your network connection.

What happens? Up pops a box. “You may be experiencing network problems.” No shit, Sherlock. I may also be experiencing anger management problems.

What should happen? Well, just maybe, it should attempt to reestablish the connection and continue, either from where it left off in the case of a prerecorded stream, or from the current point if the transmission is live.

However, having already established what happens when the connection is lost, how can you go back to where you want to be? Click “OK” and the player moves on to the next item in the playlist, or simply stops if there is nothing else. Not helpful.

Here’s how to resume listening from the last point you heard:

  • Before clicking OK, note the elapsed time in the window behind.
  • Select the item you were listening to from the playlist, and play again.
  • The stream starts buffering from the start.
  • The position slider is locked out. Wait.
  • When it starts playing, push the slider across to the time position you noted earlier.
  • Wait for the program to buffer the stream again from the desired point.

Makes one long for cassette tapes. But hey! If that’s too much trouble for you, then I’m sorry. It gets worse.

Some prerecorded programmes are split into short sections or “clips”. For example, BBC Radio 4’s Today Programme is three hours long and comes in six half-hour clips. When you are interrupted in one of the later clips, the software will skip on to the next clip when you click OK. So here’s the drill:

  • Make a note of the current clip and elapsed time. Click OK.
  • Try to select the clip you were listening to, and press play.
  • Oh, it doesn’t work—the program goes back to the first clip.
  • Wait for the stream to start playing (from the first clip again).
  • Select the desired clip.
  • Sometimes it works, sometimes it goes back to the start. Patience is required.
  • Wait for the program to buffer the clip and start playing.
  • Push the slider across to where you want to listen from.
  • Wait for it to buffer again.
  • Finally, you can hear the continuation of the clip.

That’s far too much effort. The galling thing, though, is that it is obviously possible to resume a stream from any point, but the program makes the user jump through hoops—flaming hoops no less—to do something really obvious.

Another point. Buffering. No matter how much I adjust the settings, I can’t get the program to buffer ahead well. If I’m listening to an 11kbps stream over a 64kbps connection, that represents an overhead of over 4:1. in other words, if the source is prerecorded, then there is no reason why the software should not burst as much as can reasonably be fitted into memory when it has the chance. With 256MB of RAM and gigabytes of free disk space, there’s no excuse not to. That would provide much better resilience against congestion, particularly that due to intermittent traffic such as web browsing.

Now before someone lays the blame on my meagre bandwidth, I’d like to point out that it doesn’t work a whole lot better on 512kbps or even on 10Mbps internet connections; not in my experience, at any rate. I must conclude that there’s a fundamental architectural flaw in the transmission method.

The current version of RealPlayer, RealOne, is something like the 9th or 10th version of the program. I think they have their development priorities wrong. The only apparent change over the last version is an unnecessary “skinnable” interface. A skinnable interface, by the way, is one that looks and acts differently to every other piece of software, and invariably responds slowly through the bloated weight of all the custom controls.

As far as I can tell, there’s only one reason people use RealPlayer. It’s not because of the skinnable interface. It’s not because of the intrusive advertising. It’s definitely not the user experience.

Nope, it’s because they have to.

If the stream is broadcast only in Real format, they have no choice. I wish I could use another programme. One of the biggest issues of proprietary formats is that there is no competition at the interface end. The user does not have a range of software packages to choose from.

In the unlikely event that anyone from Real is reading this: your software never fails to disappoint. For the next software revision, might I suggest some usability testing, and network tests with real world connections? Work on the functionality, not the skinning and advertising. No matter how efficient your codecs, the program is apalling.

But hey, then again, why should they care? People like me will keep on using their software, because we have no alternative.

RealOne: take it or leave it, you can’t love it.