The JavaWebStart FreeCast Node can be restarted via the JavaWebStart Application Manager. You can find the shortcuts to every FreeCast configurations you used (one by webradio in fact).
If JavaWebStart Application Manager doesn't display the wanted FreeCast shortcut, you may never start FreeCast with this configuration, go to the wanted webstation website.
There is no station concept into FreeCast. When you're using the JavaWebStart FreeCast Node (started via your browser), the listened stream is configured for you by the webradio administrator. If you want to listen something else (with FreeCast), go to the website of another webradio which uses FreeCast and following the link to start a new node.
Technically, a FreeCast Node starts, it register into a given FreeCast Network. This network only provides a given stream.
You need to start a FreeCast node to listen the FreeCast stream. Participating to a FreeCast Network requires complex software mecanisms which are not available in classic audio players.
When your FreeCast node is running, you can use your favorite player to listen/watch. If the FreeCast broadcaster allows it, the http player is started, so you can connect your player on http://localhost:8001/stream.ogg (the port 8001 is used by default, but it can be changed).
By default your FreeCast Node can relay the stream to other listeners. By this way, others nodes will be able to ask to your node the stream data and you'll support the webradio you're listening. You can relay the stream without listening it, you just need to click on the speaker icon to mute the audio player. If you stop the FreeCast node, the program doesn't stay in background.
If your system has a firewall (that's a good thing), you need to accept the usage of the udp ports by the FreeCast Node.
You must be aware of peer-to-peer video broadcast characteristics.
A video broadcast requires a “large” bandwidth (in comparaison to an audio one). This (natural) requirement creates two problems:
A peer-to-peer broadcast is limited by the peer upload. In the best configuration, each listener node is behind a DSL line. The video stream must be upload to one or more other nodes via this line. So the video stream bandwidth must not exceed half of the upload average bandwidth (something like 128kb for most of the ISPs).
To conclude, peer-to-peer video broadcast are not impossible, at this time they require accommodations. The DSL upload growing and next FreeCast developments (with your help) will make easier.
Icecast (and other stream servers which use the same principle) uses a classic client/server transport, each client is connected directly to the server. In this way, the network problems are less frequent (a big data cache can hide most of them) and clients simply read the data sent by the server. In reverse sens, the server can have quickly a bandwith problem. With a standard DSL line, you might experience problems with more than four listeners. To have more listen, you need to rent a stream server (or a part of it), which can be expensive.
FreeCast provides a solution to this bandwith problem.
A lot of applications can help you to provide a stream to your FreeCast network:
According to the application, the FreeCast root node will:
See the FreeCast userguide for more details about receiver configuration.
Share your experience with other FreeCast broadcasters via the FreeCast user mailing-list.