View Full Version : SHOUTcast Feature Request
Okay over the course of these forums several features for SHOUTcast have been suggested. However there has yet to be a common place for all these ideas to be compiled so the developers can just go to one spot to see them. So that is what this is for (although I can not guarantee the developers will read this either). But anyway if you have any suggestions or think an idea here is good speak up and we might see it in the future.
Here is a wish list of features that have been mentioned in the past:
DSP
Auto-connect feature
DNAS
Configurable buffer (some find the lag brought about by the 1 MB buffer bothersome)
Ability to make the HTML found at http://IP:PORT not available
HTML generated at http://IP:PORT that dynamically lists (links) all files in the content directory.
Addition of starting the DNAS in the directory that has the content folder in the SHOUTcast Readme file (also adding "C:\Program Files\SHOUTcast\" for the Start in line for the GUI version).
That is all I can remember for now.
Tom
SHOUTcast yp
Requested by: Kambriel
Short Version: Have the yp on SHOUTcast rank by unique connections but also list total connections that way multiple users of NATs are accounted for and people trying to tune in will know the stream is full. (Still rank by unique so yp can not be abused easily).
More info: http://forums.winamp.com/showthread.php?threadid=51290
Maestro20001
1st June 2001, 05:43
I really would like to see an easier way to edit the ini file for shoutcast. A gui would be really nice. I know it's not entirely that important to setting up the server, but for those who don't like to type it would make setting it up easier.
Maybe you could do it like a wizard? I dunno.
grommit
1st June 2001, 10:41
Subdirectories and symbolic links in the content/ folder?
grommit
1st June 2001, 10:54
Another feature request:
Something like Real Audio's surestream. Encode a live stream at different bandwidths simultaneously - sc_serv will then send the appropriate one according to the client's available bandwidth.
I realize that this might be a bit complex it would be a great feature to allow a small amount of communication to the user from the admin page of the server.
Of course you wouldn't want to try to communicate to a bazillion listeners but in a small system it would be possible to send an anouncement OR communicate to a specific user.
Easiest method would require the use of winamp by the user then incorp the feature .. simple message box. Possibly one way communication where admin could request the user contact them etc.
Romilar_D
3rd June 2001, 16:01
I'd like to see the ability to stop/restart the server remotely thru the web admin interface. I'd also like to have web posting of extended logging info reimplimented as well as tighter security integrated into the server.
club977
3rd June 2001, 16:21
I'd like to see a feature that allowed the SHOUTcast server to go find HTML (like your webpage) or be able to send HTML to the server and have that information displayed in the Title and Artist section for the broadcast. Some of us only use the WinampDSP for the encoding process and not the actually playing of the music.
aaron@dr-yo.com
22nd June 2001, 00:17
I second the request for subdirectories and symbolic links in the /content folder.
Tom says that subdirectories are on the way; thanks dude.
As for symbolic links, I'm not sure what the best way to do this under Windows is. Perhaps .M3U or .PLS metafiles, perhaps Windows shortcuts?
Any way to save disk space, and preserve/utilize users' existing file organization would be great.
Aaron Ross
aaron@dr-yo.com
22nd June 2001, 01:48
Oh yeah, a couple other things.
Please make on-demand listeners count toward the total number of listeners! That way, on-demand streams won't run afoul of bandwidth limitations. If everybody starts skipping, nobody is happy.
Hand in hand with that is listing the on-demand users in the admin page, with the ability to kick them, etc., just as with regular stream listeners. With the current arrangement, there is no way to do so.
Thanks
Aaron
aaron@dr-yo.com
22nd June 2001, 14:29
Regarding Tom Pepper's statement on the mailing list, I see his point about advertisement of stream listeners not being sullied by on-demand listeners. However, there must be some way for admins to monitor/kick users, and to prevent bandwidth bottlenecks. The server must therefore prevent users from exceeding bandwidth limits, regardless of what's advertised on the shoutcast yp.
Perhaps a mechanism could exist to track on-demand users, make them count toward bandwidth limits, but not toward number of stream listeners as posted on the yp.
Aaron
bjjocsdradio
23rd June 2001, 03:40
You should have a way to let listeners make a request right from the YP to the stream..so that when people click on the Request button near,say the chat button next to the YP listing,they can fill a form to request a song,and then have the request pop up in the DSP.
maligree
25th June 2001, 22:57
I second the request for an option to customize the internal buffer size of the DNAS.
The the server should play the backup stream file when a client connects, but no source is connected (currently, it plays that backup stream only when the source disconnects). there's only the problem determining the correct bitrate ... maybe the bitrate from the last source connection could be used or be taken from the backup stream file.
it would also be a nice feature when i can specify a "backup playlist" instead of a backup file. then the server can "send" around the clock and various moderators can connect when they want to...
(sorry about my bad english)
cya
maligree
blackanthem
26th June 2001, 02:28
Hell, i could be going about this all wrong,,, but what the hell.
I have several relays, I would like to hand out a link to a iM networks, or other I tunes type. Problem is,,, the link goes to a server and not the cluster itself. I think It would be great if the Shoutcast server could re-direct listners to a relay that had less listners, rather than a static server.
Thanks,,,
carndt
3rd July 2001, 22:03
I second the request for a configurable buffer. At 24 kbps, it's taking 2 minutes for my fire scanner traffic to make it to the listener, and 2 minutes can be a long time in scanner time.
vBulletin® v3.8.6, Copyright ©2000-2013, Jelsoft Enterprises Ltd.