SHOUTcast2 configuration builder

[thinktink]

WHAMMO!

thinktink's SHOUTcast2 config builder

YouTube Video Walkthrough

Done with all client-side JavaScript so no information gets passed to the server. Compatible with both Firefox and Internet Explorer. You need to enable JavaScript though.

I will continue to tweak it but at least potential SHOUTcasters will have an easier framework with which to build on but it does work straight up with both SC2/YP2 and legacy SC/YP1.

Feedback, whether positive or negative, is welcome.

[ServerRoom]

Nice work!

[thinktink]

Thanks.

P.S.
It's been updated to include more options and storing the settings in cookies for ease of use.

[jaromanda]

nevermind ... I ran it wrong

[thinktink]

nevermind ... I ran it wrong

Thanks... ...I think...





Update now includes:

• Installation and Paths settings for daemon/service installs
• Transcoder Admin port
• DJPort and DJPort2 (SC2)
• Calendar file and setting
• DJ settins with multiple DJs
• Live Audio Capture configs

[thinktink]

Updated:

• Replay Gain
• Misc settings (including DNAS/Transcoder intro & backup files)
• Fixed bug on path delimiter handling on merge of base & setting during init.
• YP settings

Later on I will probably add a floating helper box that will give hints and warnings as appropriate. Could probably use some help from DrO, SC_faisal, and other veterans on that.

Merry Christmas.

[PhoenixWarez]

Hello, thinkkthink;

Wich file does onne save the configuration text to?

Please reply.

[thinktink]

At the bottom of the page the first large box contains the contents to copy/paste into the sc_serv.conf file.

The other big box next to it is for the sc_trans.conf file.

[DrO]

PhoenixWarez: you can save it to any text filename that you want to, you just have to make sure to pass that filename to sc_serv2 when running it.

thinktink: i've not had a chance to properly look at this though looks great from a quick check. i had been toying with the idea of something like this myself as there seems to be a complete issue with people following the newer example files *shrugs* though this saves me some work (though i should really learn a bit more about javascript at some point soon ).

only thing i'm not personally keen on is with it filling in things which are otherwise already set as a default value by the tool as a wall of 50 lines seems to scare the life out of most noobies.

also am wondering (once i've got the wiki pages sorted out) if help links or something like that could be done between this and the wiki probably in a mini 'help' frame.

-daz

[thinktink]

@PhoenixWarez:
DrO is correct, you could save the files as "muckamuckafracknarf.barf" and "muckamuckafrackgas.chuck" and as long as you passed the file name in the startup line it would still work. (ie: "sc_serv.exe muckamuckafracknarf.barf" and "sc_trans.exe muckamuckafrackgas.chuck" respectively.)

@DrO:
Actually, it had been a while since the last time I played with JavaScript and I had to relearn a bunch of stuff but because JavaScript is pretty close (in format) to C++ it wasn't terribly painful. lol Oh, and you're welcome to look at the JavaScript source if you want.

I had considered a bit about the defaults. Most of them described in the docs do make sense. The problem with defaults though is that sometimes they change between builds (not that there's anything wrong with that intrinsicly) After thinking about it I decided that "Konsistency is King." If, for example, someone was to report an error or a problem with the configs generated I would know what to expect as far as what was originally specified and could confidently attempt to replicate the error/problem for testing later on. There are alot of options though that if the fields are left blank (or manually erased) the script won't output the corresponding config option at all thereby setting that option to the current build's default. One of the goals of the page though is to make consistently replicable and successful configs across current and future sc_serv/sc_trans builds regardless of what the defaults could be in the future. I thought that would be best. It is negotiable though.

For the wiki, if the SHOUTcast team or AOL would like to include the configurator by either linking to it or just ripping it off my server and hosting it themselves (which would probably be a better idea although if they do I would like to be able to edit it myself should the need arise (but it's not a requirement)) I don't mind.

[DrO]

Actually, it had been a while since the last time I played with JavaScript and I had to relearn a bunch of stuff but because JavaScript is pretty close (in format) to C++ it wasn't terribly painful. lol Oh, and you're welcome to look at the JavaScript source if you want.

already had a quick look and it makes more sense to me than some of the other javascript i've looked at recently

One of the goals of the page though is to make consistently replicable and successful configs across current and future sc_serv/sc_trans builds regardless of what the defaults could be in the future. I thought that would be best.

yeah that makes complete sense. only mentioned it based on what i've been seeing from other threads where too much on a page / file seems to cause more confusion. though maybe it could be tweaked to have a 'full' mode and an 'expert' mode which just strips out what isn't needed. and yes it makes sense about defaults being changed though i guess it makes more sense to only support the most current versions of the tools and / or provide a legacy option as an older page or something like that (just thunking out-loud at the moment). though with the few defaults i've changed in the second round of drops and the changes for the next round i'm probably not helping things (though am changing only default paths on the windows versions to prevent some of the Vista / Windows 7 access issues that have been reported recently).

For the wiki, if the SHOUTcast team or AOL would like to include the configurator by either linking to it or just ripping it off my server and hosting it themselves (which would probably be a better idea although if they do I would like to be able to edit it myself should the need arise (but it's not a requirement)) I don't mind.

i was actually going to ask if you'd be ok about that as it seems a bit silly to re-invent the wheel to do the same thing as you've done as i was looking to do anyway though i can happily sort out help links, etc for things. something to talk about over the next few days i think as i'd possibly thought of shipping the configurator directly so a known version would always be in the distro for the version(s) being setup

-daz

[thinktink]

already had a quick look and it makes more sense to me than some of the other javascript i've looked at recently

lol, properly named variables ftw! Thanks for the compliment.

...i'd possibly thought of shipping the configurator directly...

That's an interesting thought and I can't think of a legit reason to be against it at the moment.

[thinktink]

Updated...


...because I'm a dumbass.


Somebody, please find a spoon and stab me in the throat with it...



Fixed.

[DrO]

/me gets out a spork...

btw, just noticed that you've got it starting from _0 for the sc_serv stream configs (from the other discussion about such things).

-daz

[thinktink]

I tested it and it worked. Straight up copy and paste to the config files. Thing is though the errors from sc_trans complaining about not being able to connect to the shoutcast server with metadata stopped. Odd. I thought it wouldn't matter what the index started with just as long as the sid's matched.