feature request: multiple passwords per mount
feature request: multiple passwords per mount
One feature that would be helpful would be to allow more than one password on a mount. If I let other people use my steamcast server, I'd like to be able to assign individual passwords to each one of them. Ideally this would be in an external password file that I could update without having to restart steamcast.
Maybe it could be in the form of "SourcePass=/passwordfile.txt", where if the password starts with a forward slash, steamcast interprets that as a filename, and reads it as a return delimited password file. Or perhaps a new SourcePassFile=passwordfile.txt could be defined.
Ideally, it would support usernames and passwords, and could then record in the log files which user is connected as the source. (This is another important bit I want really like, to know who is connected and when.)
Anyway, eventhough steamcast is a beta, I've gotten some pretty stable service out of it (except that yellowpages seg fault problem ). I can see it becoming pretty powerful in time. Congrats!
Maybe it could be in the form of "SourcePass=/passwordfile.txt", where if the password starts with a forward slash, steamcast interprets that as a filename, and reads it as a return delimited password file. Or perhaps a new SourcePassFile=passwordfile.txt could be defined.
Ideally, it would support usernames and passwords, and could then record in the log files which user is connected as the source. (This is another important bit I want really like, to know who is connected and when.)
Anyway, eventhough steamcast is a beta, I've gotten some pretty stable service out of it (except that yellowpages seg fault problem ). I can see it becoming pretty powerful in time. Congrats!
So you're suggesting I set up a separate instance of steamcast for every guest dj? I would have two problems with that. One is obvious when you consider a dozen or two guest dj's. That means a lot of steamcast running. The other problem comes when many of them connect at the same time. That's a lot of connections using up bandwidth without a listener. Ideally, if a source is busy, they *can't* login. That really means they all need to connect to the same mount. I can do that now if they share a password. (me no like password sharing! )
Also, FYI, I've been experimenting with automatically switching between streams as relays. I basically nest them, two at a time, with the first mount listing the second mount as a backup. I can't do three in a row in one instance of steamcast, as it just won't work. But if I stick to two, and nest them, I can get three (and probably more) auto switching streams to work. In this way, I can have a top broadcast who will take over the stream if he/she connects, then a middle layer for guest dj's that casts if there is no top broadcaster, and then a bottom relay source (an sc_trans instance) that casts if neither top nor middle are casting. All of this feeds through a single public steamcast instance so the listener only ever sees one place to mount. The switches aren't transparent, but they function. Whatever is in the buffer from before gets cast out before the new content comes after a switch.
Also, FYI, I've been experimenting with automatically switching between streams as relays. I basically nest them, two at a time, with the first mount listing the second mount as a backup. I can't do three in a row in one instance of steamcast, as it just won't work. But if I stick to two, and nest them, I can get three (and probably more) auto switching streams to work. In this way, I can have a top broadcast who will take over the stream if he/she connects, then a middle layer for guest dj's that casts if there is no top broadcaster, and then a bottom relay source (an sc_trans instance) that casts if neither top nor middle are casting. All of this feeds through a single public steamcast instance so the listener only ever sees one place to mount. The switches aren't transparent, but they function. Whatever is in the buffer from before gets cast out before the new content comes after a switch.
I see what you mean. That would work as long as their isp doesn't block any ports. (And we know how isp's like to do that! ) ) But I would then need a way to first check if their stream was running, and then automatically switch to it. I could possible write a server script to do that. I would need a separate conf for each dj with a mount that had their connection as a relay. I could then run a steamcast instance with their conf.
The one downside is they would have to be tightly scheduled for it to work automatically. They couldn't easily pop in whenever it was free and do an unscheduled broadcast. Well, maybe I could write yet another script they could access from a web page to poke the checker script to begin relaying them.
ok, with lots of scripts, and with requiring the dj's to run their own steamcast or shoutcast, and if they aren't blocked by a firewall, it could be done. It would be simplier and easier if steamcast supported multiple passwords on a mount, but at least I can see a way to make it more or less work.
I'm beginning to think bribery might be the way to get multiple passwords on a mount from you! Can you be bought Jay?
The one downside is they would have to be tightly scheduled for it to work automatically. They couldn't easily pop in whenever it was free and do an unscheduled broadcast. Well, maybe I could write yet another script they could access from a web page to poke the checker script to begin relaying them.
ok, with lots of scripts, and with requiring the dj's to run their own steamcast or shoutcast, and if they aren't blocked by a firewall, it could be done. It would be simplier and easier if steamcast supported multiple passwords on a mount, but at least I can see a way to make it more or less work.
I'm beginning to think bribery might be the way to get multiple passwords on a mount from you! Can you be bought Jay?