Fire up your favourite IRC-client (e.g. AmIRC) add one of the servers listed below and /join #AmigaZeux ... that's all folks! random server: irc.amigazeux.net irc.de.amigazeux.net irc.nl.amigazeux.net irc.fi.amigazeux.net irc.uk.amigazeux.net irc.us.amigazeux.net irc.amigazeux.de zeux.amigazeux.de
Digital radio is not crap, but you have to be sensible about what you can play. Expecting CD quality streamed mp3 on a 56k modem is just not realistic. But there are things you can do to make the performance as good as possible on your current setup. Read this section of the FAQ thoroughly.
Because 56k modems can't actually do 56k. They do about 45k (about 4500cps) on most phone lines, even the better ones. In-built modem compression makes up for this sometimes, but mp3 is already compressed so this has no effect here. You could try using an accelerated serial port (which will also take some load off the CPU), but be warned - the speed increase is not great at all!
No. Your connection is just not fast enough. This is not ANR's fault.
This may depend on the stream, how far away it is (in geographical terms) and the quality of the routers between you and the stream server. In other words, it depends on the internet. Try to pick a stream closer to where you are, or if that fails just pick a better stream. Even if you have a T1 ethernet connection that Russian 128kbps stream just might not be able to get to you fast enough. Also, it can depend on your CPU and graphics system (if you don't have a GFX card). If you are placing too much strain on your CPU or chipset, transfer will suffer. There are issues with some ethernet cards and/or drivers sucking CPU too, particularly if you use Miami/MiamiDX without MNI drivers. PCMCIA cards are also major CPU drains. AHI is also a CPU sucker. Don't use 14bit on paula unless you have an 060 or better, and try 28KHz (or less) if you just can't keep that 44.1KHz speed up. Also, if you use the standard Amiga serial port for internet this is a serious bottleneck, especially if you run deeper AGA screens like 7 or 8 bit - or even worse - VGA modes like DblPAL or Multiscan. AGA just isn't up to it. You can compensate by turning some of the quality options down.
ANR needs CPU power to play mp3 and to stream. Some stuttering is unavoidable on weaker CPUs in multitasking situations. Try reducing scope effects or mpeg quality to get some CPU time back. Also, running Petri Nordlund's excellent Executive can "steal" CPU time away from ANR. If you really don't like the stuttering, try setting the priority of the AmiNetRadio task above the dynamic priority range, or set to Leave Alone. If you don't run Executive, you can also use the cli argument (or tooltype) DECODERPRI=1. See "Shell arguments" in the guide for more info.
It's not ANR that's crap here... get out of the stone age or don't complain. ;) But seriously, if you want the best streams, you must consider a faster connection. 56k will allow you to listen in, but the quality will suffer for it.
First, we're sorry but we can only make sure it works 100% on MorphOS. If you see corrupted graphics on other systems, try using other GUI modules (only ANRNG really has problems on non-MOS systems), and remove all .elf files from the distribution. If it still doesn't work, not much we can do, although updated guigfx and render libs might help. At the time of writing, old libraries are why the ANRNG GUI looks nasty on non-MOS systems. If you still have problems, visit "irc.amigazeux.net #amigazeux" and we'll see what we can do. Read the full FAQ through first, or we may eat you.
You may not have enough pens on your workbench screen. Try running a screenmode with more colours or close other apps to free some pens.
ANR is coded in E and needs no external stack. If it crashes, it's not a stack problem. StackAttack and other nasty hacks won't help, in fact they'll probably make things worse. A clean system almost always is more stable.
Don't use them at the same time! Why would you do that anyway? This is not a bug, just a limitation of the plugin wrapper concept. Either delete the amplifierplugin.library that comes with ANR (NEVER copy this file to LIBS:!) or don't run AMPlifier at the same time.
Umm...err...use your time machine to get back to the present?
Sadly, this seems to be the fault of AOL server software used for these channels interacting badly with Miami and MiamiDX, and it seems to be AOL's fault for not respecting an RFC. It's not an ANR problem, and doesn't occur with Genesis or AmiTCP. The only thing we can recommend is that, when you load one of these servers, open the streams window (Streams in the Window menu item) and pick a stream in the cluster that doesn't have :80/stream/1040 but something like :8010. But since this server is usually full it's not always an option. This is a big problem. You can also stream ANR from a proxy running on a non-Amiga system (privoxy is a nice, free choice). But we really hope AOL fix their server software one day.
If you read the player description, you would know. :P But for dummies, I'll explain: first you configure the cdda.player in the prefs, then you open an ASL requester like you're going to open a file, and put cdrom:// in the path. Leave the filename blank and click ok. Your CDDA should play. It's possible that your drive will not support reading in this way. It's unlikely, but some cheap drives or special combo drives don't. Almost all drives don't support reading if you haven't put a CD in, we're told.
There are lots of reasons why this might fail. First, remember to have the xad package installed to use packed skins. Otherwise they can't be unpacked and will be ignored. Then, remember that only 'classic' WinAMP skins will load (WinAMP v3 and below). The newer skins use XML and we can't support them. Also there seems to be a bug/limitation in the default MorphOS BMP datatype (and maybe some others, like the CGX package one) in that it doesn't load some kinds of compressed BMP. If you don't want to install a different datatype, try unpacking the archive (if its archived) and converting the BMP files to another format. Don't rename them.
Sure you can. ANR checks the URL argument for .pls and if yes will stream from the URL in the .pls file. Simply set a x-scpls MIME type for .pls files on your browser and set AmiNetRadio as the viewer. For example, in IBrowse: SYS:AmiNetRadio/AmiNetRadio URL %r.
Don't suffer in silence, you can do summink about it. The priority for players can now be specified in a separate file that accompanies the player in the player directory. The separate file is named after the player like for example mpega.player will have a file called mpega.pri, the .pri file has to contain a number from -128 (lowest) over 0 (default) to 127 (highest). Players with a higher priority are checked first against songs. We can't change the behaviour of mpega.library and other libraries. So this isn't ANR's fault when they get the identification wrong.
Streams only allow a certain amount of users, which can be anything from thousands to just one or two. You cannot connect to a server which is full. Try waiting for some minutes and connecting again, as maybe one of those lusers...er, users - has dropped out. ;)
Don't worry, ANR creates a copy of the playlist in library.donotedit!.bak. Just rename or duplicate the file to library.donotedit! again.
Some digital radio stations don't use a single stream but a group of them on different URLs - a cluster. All the URLs in the cluster are playing the same stream. Clusters allow a lot of users to connect to one server. ANR allows you to select between picking an URL in the cluster manually, or attempting to connect to each URL in turn. It's just a strange Shoutcast thing so don't worry about it. ;)
ANR relies upon metatags in the stream for the song name. Sometimes the radio channels forget to send them or change them and ANR can't tell if a new song has started. The fault lies with the stream, not ANR, so this cannot be fixed.
The difference in quality is easy to hear. Low bitrate streams sound crackly and tinny, lack bass and treble and are usually in mono. Put less scientifically, they're more sucky. ;)
Make sure the pitch is set to 100%. If it is, then you have hit the Amiga sound DMA barrier. If you're running in a PAL/NTSC screen then you must either set the maximum AHI frequency to 28KHz or reduce the mpeg samplerate to 1:2. You could also try running a VGA screen such as DBLPal if you have a multiscan or VGA/SVGA monitor. If you have a graphics card, you must set the env-variable AUDIO56KHZ to 1 (only later versions of CyberGraphX4) or run C:AddAudioModes DBLSCAN. See the AHI guide for more details.
For the scopes, try setting a different update frequency. Faster updates will look smoother but will eat more CPU time - on weaker CPUs they may actually look more jerky. Another important thing is to remember that the display and the scopes need a lot of CPU time to be smooth. A 040/40 at least is recommended if you want to use the scopes.
I put songs into the playlist. All is great. But then I come back three days later and the songs don't work. They still work from the search window, though, and will work if I add them again to the playlist. What's up?
Not our fault. Shoutcast stations sometimes change the rn number (their location in the shoutcast index). It happens rarely, but it happens. You could try putting in the IP or DNS directly, which should happen if you ADD the station from the history window. Remember too, though, that IPs do change sometimes too. Named DNS entries (e.g. nectarine.ipsyn.net:8002) are best and almost never change, but you may have to go to the website of the station to get one (or use Resolve/MiamiResolve).