Page Type: SYMPTOM
The Rangecast Java player can cease playback for arbitrary periods of several minutes, due to an apparent bug in the Java audio system. There is a workaround available.
When this problem is happening the Java player shows "Reading Audio" (indicating that the audio system is attempting to download content) for up to several minutes. During this time the player buttons remain operational, for example, banks can be toggled between on and off. But there is no audio playback.
The test - and the likely workaround - is to try changing the network route used to deliver audio to this player. If audio playback is restored then the problem is confirmed to be due to an known bug in the Java audio system. The method to change the route is below.
As a workaround to this bug in the Java audio system, a hub administrator must change the network route used to deliver audio content.
After this change is made, an affected user with an open Java player should log back into the system.
[FAQ-1057] How to fix Java player freeze problem by activating alternate audio routing.Due to what appears to be a bug in the Java audio system, on occasion the Java audio system experiences extended freezes when requesting audio through certain network paths (as happens when requesting from a specific domain name). Rangecast audio is stored at Amazon, and normally obtained directly. We have the option of activating an alternate route, where a Rangecast server is used as a proxy between Amazon and the Java player. This option can be enabled/disabled on a hub's status page.
This FAQ entry only relates to the Java player, not the HTML5 player.
This problem is often described as a problem "with a hub", as if the problem relates to the way Rangecast audio is recorded. This is not correct, the problem is with the PC where the audio is played. There is a hub-level selection available for a workaround, but that selection sets the Java player's configuration at login (and has no direct effect on how audio from that particular hub is routed.)
As a workaround, Rangecast can deliver audio directly or indirectly (if one route is affected by the Java bug, the other usually works.) The Java player is told which route to use at login, based on a hub-level setting at the hub hosting the user account (e.g. for user 'user@example', the routing is determined by a setting at the hub 'example'.)
Note that once the player is told which route to use, this route will be used for audio received through that Java player from ANY hub - not just 'example', but any other authorized content the user may access from other hubs. And the routing used by the player will be that selected at hub 'example', NOT the routing selected at the hubs from which the content originates.
To make this clearer: When a PC is affected, the problem will manifest with any access to audio stored at Amazon S3 from that PC -- using any Rangecast user name, reading audio from any hub. If the user has access to audio from multiple hubs, this usually leads to a description of the problem as "hub X is affected, and also hub Y, and hub Z". But the problem is with the PC, and users elsewhere listening to the same content (from other PCs, definitely other local networks) will see no problem at all when using Rangecast.
Although the fix is applied at the hub level, that's really just a quick way to get a command sent to an affected PC accessing Rangecast saying "use the proxy", on the assumption that the user is using a particular login, and this is a practical way to get a special command sent to the affected Java player when that login is applied.