Hi, I had the same conclusions about harbor: at some point it should share more code. If I remember well it duplicated code from Http_source and Server (for the scheduler).
It's fine to have a separate scheduler for the harbor server, but it's not necessary. It's not needed to duplicate the scheduler's code in any case. However, it seems necessary that when starting streaming a different thread is launched which actively pulls the data as long as possible: that's the only to use the stream decoders currently. I'd not change that now, without any good insights on the benefits. > My solution would be to move source's part of harbor to sources/, then start a > server from tools/ with a proper thread when set to. Split if you want to, but the code should be quite concise once it shares what has to be shared, and for now it does not *have to* be split. > current harbor thread does not respect the paradigm with Tutils: although the > begining of client handling is done the same way as for telnet, as soon as a > client is connected and a request is handled, then no hand is given back to > main thread, so the thread is locked. Aha, it does look like the event handler locks the scheduler by decoding the stream... This should be done in a separate thread, you're right. I'm surprised that nobody noticed that harbor fails to accept two clients at once yet, just hanging on the second one, even unable to kick it out. It's very cool that you review this module, since it's really close to work cleanly, I believe. The problem balbinus had was that harbor didn't recognize a liquidsoap MP3 stream (probably set to talk to icecast rather than shoutcast). Any news regarding that ? Actually, I just managed to have liquidsoap connect to harbor using both icecast.vorbis and icecast.mp3.. did anyone fix anything ? Cheers. -- David PS: I started using input.lastfm() and it works great!
