The guy who want more, and more, and ... - Airtime Development Discussions on Sourcefabric Forum

Albert FR

I've said that before, great job guys for the last version ;)

But now, for the next versions of airtime some features are really waiting by a lot of us (I'm suppose)

- live integration
- programmed live integration
- streams with different bitrates and point them to different Icecast/Shoutcast servers
- Service monitoring from the browser
- etc.

A really good feature for a lot of us is a playlist generator with rules (constraints on the length, style, album, year, title for example) or in a first time an import of .m3u playlist

my 2 €

YounesDesign

+1000

Josh McLain

Hi Albert,

As always, thanks for the feedback, we truly appreciate it. I can tell you that you aren't alone in requesting that we develop a live assist mode so that users can broadcast live as well as automated. As such, it's something we plan on working on in the future. As for the third and fourth requests, keep your eyes open, you might be seeing those soon. :) Also, thank you for all of your help assisting other people on the forums as well. If you don't mind me asking, can you tell me about the project you have Airtime in mind for?

-Josh

Romeo

Guys, do you know that Liquidsoap has harbor input support?

It allows to broadcast directly to airtime-playout engine without icecast server.

I used this options long time ago, since liquidsoap 0.3.6.

the simpliest LS script to do that was something like that (0.9 version):

set("harbor.bind_addr","0.0.0.0")

set("harbor.port",8090)

set("harbor.password", playlistPasswd)

liveInput = input.harbor( id="live",

"live.ogg",

buffer=2.,

password=livePasswd)

playlistInput = input.harbor(id="playlist",

"playlist.ogg",

buffer=10.,

password=playlistPasswd)

noiseInput = noise(id="noise")

noiseInput = amplify(id="noiseAmp", 0.05, noiseInput)

noiseInput = rewrite_metadata([("title","no signal")], noiseInput)

#Master Input

input=fallback( id="mainFallback",

track_sensitive=false,

# transitions=[crossfade, crossfade, crossfade],

[liveInput, playlistInput, noiseInput])

out192 = output.icecast.mp3( id="192mp3",

bitrate=192,

input,

restart=true,

password=omegaRelayPasswd,

mount="rvk192",

name=streamTitle,

genre=streamGenre,

url=streamUrl,

description=streamDescr)

Let me explain the architecture and logic of this script. There was 2 external stream generators. one - automated playlist (SAM Broadcaster), second - live stream from various DJ's studios and internal noise generator. Live has highest priority, playlist - middle, noise - is the default fallback that emulates FM "no signal" condition. it lets listeners to make shure the radio is alive. I think it's much better than streaming blank when there's no show.

This setup was built without using airtime, but some techniques can be easily adopted

krzakx

"Service monitoring from the browser"

What about the monit http://en.flossmanuals.net/airtime/using-monit/ ?

Albert FR

that's not false krzakx ;)

Albert FR

thank's to you ;)

I'm waiting for that ;)

I'm working with a lot of non profit organization who want a media solution ( and also with professionals)
and airtime is really a good app. for doing that ;)

But, I really waiting the first and second requests ;)

camerin

I don't know if this should go here, but i am currently looking into it my self. I love airtime, but we all have want to broadcast live (there seems to be a huge demand for it anyway) i am curious if it may be easier to allow the users to inject a stream using a third party app. I know it would be prefferable to keep it all in the airtime interface, but my philosophy has been find solutions not projects. the team at Mixxx does have a good software package that allows the users to push to an Icecast2 server, i am curious if integration with a software package like that would be easy, possible, or even plausible.

Camerin

Albert FR

@camerin that's sure, we can do that, and for the moment a lot of us do that.
But that's not really a solution.

I'm explain why :
You can't schedule a programmed live to use an emission of another radio at a fixed time or for example to save it and repost later (If you're using a dedicated server)

an automation system will do that to be use in real situation.

camerin

Reply to @Albert+FR: I am not at all an expert, only been in this game since august so i am pretty much snowballing for ideas at this point, but would it be feasible to have 2 icecasts stations running, one designed just to handle live streams, the other being the stock airtime stream, and then in the airtime software make the user select the live stream as basically the "song to be played". i know this would make any logging songs that were played messy.

In words this seams confusing i put a diagram on google docs if you want to look at it (it was acting weird so i can't post it here. you may need to download it to view. Picture

Albert FR · Post edited by Albert FR at 2011-12-04 16:02:11

@Romeo, that's sure, and this what we waiting ;)

some peoples like us can do that, but not everyone.
And when i'm installing airtime that's really boring to explain that, and find solutions for recording, upload, etc
And if something change, you'll must modify the config file ( a thing not really easily to understand for the end user...)

Romeo

@Albert+FR: Shure, end user must not think about editing configs. Click-click-done approach must be used instead.

camerin

Reply to @Romeo: Yeah that will "work" but we are by-passing a key feature of airtime that i like and need, user identification. i don't want my DJs to high-jack shows that they shouldn't be playing during. This feature is required for me. If i am wrong, let me know i will put it into production, but from looking through that code i think i am right it the assumption that this is not what i am looking for.

Martin Konecny

We are aware of input.harbor, and will consider using it when we implement live support.

Romeo · Post edited by Romeo at 2011-12-05 00:06:14

Reply to @camerin: This is harbor.input() description in LS docs. Did you mention an auth function? It can be used to check if a DJ with certain username should play right now.

I agree that auth is very imortant. My current implementation is simple, but gives you live support right now. If it doesn't "work" for you, don't use it. It's just a kind of idea.

input.harbor

(?id:string,?auth:((string,string)->bool),?buffer:float,
 ?debug:bool,?dumpfile:string,?icy:bool,
 ?icy_metadata_charset:string,?logfile:string,?max:float,
 ?metadata_charset:string,
 ?on_connect:(([(string*string)])->unit),
 ?on_disconnect:(()->unit),?password:string,?port:int,
 ?timeout:float,?user:string,string)->
source(audio='#a+1,video=0,midi=0)

Retrieves the given http stream from the harbor.

id (string – defaults to ""): Force the value of the source ID.
auth ((string,string)->bool – defaults to fun (_,_) -> false): Authentication function.f(login,password) returns true if the user should be granted access for this login. Override any other method if used.
buffer (float – defaults to 2.): Duration of the pre-buffered data.
debug (bool – defaults to false): Run in debugging mode by not catching some exceptions.
dumpfile (string – defaults to ""): Dump stream to file, for debugging purpose. Disabled if empty.
icy (bool – defaults to false): Enable ICY (shoutcast) protocol.
icy_metadata_charset (string – defaults to ""): ICY (shoutcast) metadata charset. Guessed if empty. Default for shoutcast is ISO-8859-1. Set to that value if all your clients send metadata using this charset and automatic detection is not working for you.
logfile (string – defaults to ""): Log buffer status to file, for debugging purpose. Disabled if empty.
max (float – defaults to 10.): Maximum duration of the buffered data.
metadata_charset (string – defaults to ""): Metadata charset for non-ICY (shoutcast) source protocols. Guessed if empty.
on_connect (([(string*string)])->unit – defaults to fun (_) -> ()): Function to execute when a source is connected. Its receives the list of headers, of the form: (<label>,<value>). All labels are lowercase.
on_disconnect (()->unit – defaults to {()}): Functions to excecute when a source is disconnected
password (string – defaults to "hackme"): Source password.
port (int – defaults to 8005): Port used to connect to the source.
timeout (float – defaults to 30.): Timeout for source connectionn.
user (string – defaults to "source"): Source user.
(unlabeled) (string): Mountpoint to look for.

Howdy, Stranger!

Categories

Poll

Top Posters