SHOUTcast2 configuration builder

[thinktink]

All fixed up and the configuration files are now downloadable, even when viewing it from a local directory.

DrO, I sent you a PM. I had to add alot of stuff to it to get the local-only download working. Worth it though since it doesn't rely on a server and therefore remains portable.

[thinktink]

Coming soon: Calendar!

*shoves nose even deeper into grindstone*

[thinktink]

Calendar xml config file is done.



P.S.
Happy New Year!

[thinktink]

Finally got rid of those damn red squiggly FireFox spell check lines. They were hurting my eyes.

In accordance with what DrO is doing, I've renamed and moved the files into it's namesake own folder.

http://bogproghome.hopto.org/config_...g_builder.html

I just also tested it with FireFox on linux. Works as expected including the downloader stuff.

[PhoenixWarez]

I must say, exelent e work @thinktink, cheers!

[thinktink]

ty Phoenix

[thinktink]

Finally got the damn config settings backup stuff working right. Also did some retooling on some background stuff to work-around IE problematic cookie stuff.

I think I have one more thing to add to it...

[thinktink]

Now includes the symbolically named playlists settings. Probably gonna be a while before I get new ideas.

Latest release now live at usual location.

Time for a nap...

[fc*uk]

great job on this thinkthink

This is going to save people massive amounts of time.

Since we are on about it and I am the last one that edited this thread, anyone object to me throwing a link to this in the "Need SHOUTcast help" thread", located here: http://forums.winamp.com/showthread.php?t=246636???

[jaromanda]

to make it idiot proof ... adding a DJ "automatically" add a calendar dj event for that DJ

[giss68]

I guess we have to delete sc_serv_basic.conf and sc_trans_basic.conf and just use this conf builder output?

[DrO]

fc*uk: should be fine to do that especially if thinktink's given the ok to ship it officially

Originally Posted by jaromanda

to make it idiot proof ... adding a DJ "automatically" add a calendar dj event for that DJ

good idea that

Originally Posted by giss68

I guess we have to delete sc_serv_basic.conf and sc_trans_basic.conf and just use this conf builder output?

you can save the configuration files generated by this to any filename you want. the sc_serv_*.conf files included in the distribution packages are mainly there for getting to know what can be done with the configuration options and to show off different aspects though if you've not happy with editing text files / having issues then trying this out is more likely to give what is wanted.

-daz

[thinktink]

@DrO: Got your PM, will have a look at it when I get off work.

@fc*uk: Yes, but hold off a bit while some finalization/reconciliation work is in progress.

@jaromanda: I had thought of that before but I forgot to put it in. Should be easy enough to do on a simple level but I want to try to get some kind of dynamic link between what is added so that if a change is made in one section it updates the other. Will have a look into it when I get home off work.

@giss68: There's really no need to delete anything. Just save the file as is and pass it as the parameter instead of one of the other ones. I purposely made the default of the downloaded config file name in such a way as to not overwrite any of the other example config files (based on the latest current public install) so that it won't mess up anything else and you can revert back to the other confs if you want/need to. It will work just fine with other unused confs in the same folder.

I'm also gonna see if I can add a batch-file/linux-command-script download thingy to make it even easier. I dunno if it'll work though there might be a security issue with that but I dunno, gotta test it first.

bbl/brb, Mondays suck...

...mostly...

[thinktink]

DrO and I are playing ping-pong with the files atm.

I had to dump the idea of linked dj->calendar event settings, it was causing more problems than it solved and it really didn't seem congruent to the nature of calendar events. But I did add an add-dj-to-the-calendar button. Did the same with the named playlists. It's not published yet but hopefully soon.

I'm thinking I should finally put something in my sig...

[thinktink]

I found some flaws in the config backup/restore stuff, about 3 other background bugs, removed some unused, and a small amount of repetitive code. Also includes the above mentioned buttons.

[fc*uk]

just drop me a pm when you would like this added and I will see it done.

[thinktink]

Cool, I'm just waiting on DrO who has, at the moment, a mound of other priorities.

[DrO]

i just need to make some additions about when it is run locally and then i'm done on it for the time being i think (as a locally running swf for the download button just won't do what i'd like it to do even with manually compiled versions set never to try to access the internet ).

/me shakes a fist at flash security mumbo jumbo rubbish

-daz

[thinktink]

DrO did some excellent work although I needed to tweak some things in the CSS so that it would look the same in IE as in FF and rename some stuff to match the current convention (internal stuff.)

@DrO I will be PMing you the updated version very soon.

[DrO]

not as good as the work you've done on it all

-daz

[SC_faisal]

just stopping by and saying what an amazing tool this is!!! awesome! great work guys.

[thinktink]

Thank you DrO & SC_faisal.

Update:
DrO found an error in the config output for "saveriplistonexit" and has brought it to my attention. It has been fixed.

[jaromanda]

the config builder has become a little bit awesome!!

but, a question. It states in help for "Auth Hash", that you need a unique Auth Hash per Endpoint ... yet on shoutcast my stations, it talks of "Stations", which implies (or more correctly I've inferred) that the auth key is per station, so if you have 3 different bitrate streams for example, for the one station, you would use the same Auth Hash

that's how I understand it, anyway

[thinktink]

When I first asked to join the ranks of the YP2 beta testing I was informed I needed a separate and unique auth hash for each endpoint regardless of bitrate. The station name for each endpoint-registered-auth-hash is still the same but each endpoint itself (I was told) requires a unique hash.

[DrO]

you can use the same authhash for different endpoints (is what i've seen from testing out things) and is basically there to group different streams to be provided as the one station. i'll check the docs and amend this as appropriate.

-daz

[thinktink]

If this is true then it would appear I was mis-informed.

[DrO]

i'll double check for certain but that's how it has seemed from what i've been doing under testing.

-daz

[thinktink]

k, if after you've verified it's for certain then it means the config builder is gonna need some changing.

[DrO]

how so as i thought it's working fine in that it just populates the streamauthhash for the stream config being used as is required so i don't think there's a need to change anything as entering the hash per stream makes more sense (even if they can be shared).

-daz

[thinktink]

True, but the intent of it is for one named station with the possibility for one or multiple endpoints of the same stream name/title. Since this configures both sc_serv and sc_trans (of which currently sc_trans only supports one stream name/title to all endpoints per instance) that means that one sc_trans instance serves the DNAS and it only serves the same stream name/title/metadata for each endpoint. It would make more sense therefore that if the above is true you don't need or really want to individually specify an auth-hash for each endpoint as that doesn't logically flow in-line with what's going on. Of course it could be left the way it is and just re-inform the user to use the same auth-hash for each endpoint but that's a bit repetitive and also could cause confusion on the part of the user. And not just that if it can be presented to the user in a simpler manner (while leaving the more advanced options available) without harming the ability to create successful configs I think it should.

I can't think of a reason not to change it (if, of course, the above is true.)

I will, of course, wait for official word though.

Shouldn't be terribly hard anyway, one less array and one more static input (hidden and shown as appropriate.)

[DrO]

the other option (as i've used this to make multi-station configs so being able to enter different hashes is useful) is to have a master input field like the mp3 encoder parts and use that in all cases unless a per-stream option is entered.

is just a thought and so the docs are wrong from what i can tell with re-testing so i've got the fun of changing that tomorrow now so i can add in the option along with updating the docs at the same time if you're happy with it or not

-daz

[thinktink]

Originally Posted by DrO

the other option (as i've used this to make multi-station configs so being able to enter different hashes is useful) is to have a master input field like the mp3 encoder parts and use that in all cases unless a per-stream option is entered. just a thought.

Now that you mention it that might actually be better since removing the individual auth-hash inputs will break previously created configuration backups.

I'll do that.



[EDIT /]

Originally Posted by DrO

...and so the docs are wrong from what i can tell with re-testing so i've got the fun of changing that...

Is that the official word?

[DrO]

well that's what my tests are showing. either way it makes sense to change the auth hash handling to what has been suggested and i'll sort out fixing the docs.

-daz

[jaromanda]

so is auth hash 1 per station, or 1 per stream?

saying "the docs are wrong" doesn't really say which is the correct answer, though from the rest of the conversation I gather "1 per station" is correct

[DrO]

1 station per hash is how it's been working with my tests.

-daz

[thinktink]

k, I'm finally back home...

[thinktink]

Updated. Now includes a default auth hash setting and settings+downloaders for launcher scripts/batches.

[thinktink]

Yo DrO, did you get my PM from last night?

[DrO]

yup though haven't had a chance to look at it yet or finish my doc updates

-daz

[thinktink]

Updated:

• None, all, or custom modes has been added for debug logging options, initial work done by DrO.
• A grip of code was added to allow coding of the automatic updating of items in the calendar when DJ or Playlist names are changed.