So I am wondering if anyone on here knows if the intro file that is in icecast has to be a audio file, as what I want to do is have it load a script that then loads the intro mp3.
I am wondering if this can be done and if anyone has done this before?
TL;DR - no
Icecast documentation on this topic
intro
An optional value which will specify the file those contents will be
sent to new listeners when they connect but before the normal stream
is sent. Make sure the format of the file specified matches the
streaming format. The specified file[name] is appended to [the] webroot [path] before
being opened.
There are some tricks you could possibly play:
Replace the file from time to time
Trigger the replacement based on a url-auth request. This may not be 100% reliable in situations where many clients connect in close succession.
Patch the Icecast source code
Pay one of the companies that have patched Icecast in similar ways for hosting.
Related
I am trying to loop audio from my Icecast server 24/7.
I have seen examples where people talk about storing their audio files on the EC2 instance or in an S3 bucket.
Do I also need a source client running on my EC2 Instance to be able to stream audio to the server? Or is there a way to play static files from Icecast?
Icecast and SHOUTcast servers work by passing a live audio stream from a source on to the users. You need something to produce a single audio stream in realtime from those source files.
The flow looks something like this:
Basically, you'll need to do everything you would in a normal radio studio, but automated. You'll stream the files from your bucket, play them to a raw audio stream, send that stream to your encoder to be compressed with the codec, and then sent to your streaming servers for distribution.
You can't simply push your audio files as-is to the Icecast server, for a few reasons:
Stream must be realtimeThe server doesn't really know or care about the timing of the stream. It takes the data its given and sends that off to the client. Therefore, if you push data faster than realtime, the server will attempt to deliver it to the client at this faster rate. Some clients will attempt to buffer this fast stream, but most will put backpressure on the stream, causing the TCP window to close, causing the client to eventually get far enough behind that the server drops the connection.
Consistent format is requiredChances are, your source files have varying sample rate, channel count, and even codec. Most clients are unable to take a change in sample rate or channel count mid-stream. I don't know of any client that supports a codec change mid-stream. (Theoretically possible with Ogg and Matroska/WebM, but yeah... not worth messing with.)
Stream should be free of ID3 tags and other file format cruftIf you simply PUT your files directly to your Icecast server, the output stream will contain more than just the audio data. At a minimum, you'd want to remove all that. Depending on your container format, you'll need to deal with timestamps as well.
Solutions
There are a handful of ways to solve this:
Radio automation softwareMany folks simply run something like RadioDJ on cloud-based servers. If you already have a radio station that uses automation, this might be a good solution. It can be expensive though, and not as flexible. You could even go as low as VLC or something for playout, but then you wouldn't have music transitions and what not.
Custom playout script (recommended)I use a browser engine, such as Chromium, and script my channels with normal JavaScript. From there, I take the output stream and pass it off to FFmpeg to encode and send to the streaming servers. This works really well, as I can do all my work in a language everybody knows, and I have easy access to data on cloud-hosted services. I can use the Web Audio API to mix and blend audio based on what's happening in realtime. As an alternative, there is Liquidsoap, but I do not recommend it these days as its language is difficult to deal with and it is not as flexible as a browser engine.
I have Django running on an Nginx Webserver, with uwsgi as application server.
I need to generate a large .xlsx file by combining multiple smaller ones. Then that file needs to be downloaded to a client.
After googling a lot, I have not been able to find anything that really answers my question, so I am asking here.
I am using an openpyxl WriteOnly Worksheet. Upon trying to save the worksheet the process always gets killed.
My question is, whether I can stream the workbook to the client via a uwsgi socket and save it there.
It would be greatly appreciated if someone could provide some sample code for an implementation, that can save or stream the file to a client!
I am working on an application that, among other applications, allows users to send emails. It works by writing everything onto an SQL server, so you can have multiple instances of an application.
The email sending currently works with an "Outbox" table on the SQL server, to which application instances directly write the data with SQL statements. I have, however, hit an issue, that a requirement for attachments on the emails has arisen.
My thinking is that if I can send the attached files to a directory on which the SQL server resides (possibly the TEMP directory?), and then store the path to that file (or a UUID, if the file is constant) in the table. The issue is I have no idea particularly where to start with sending the file, as I am still vaguely new to C++.
One term I have come across is sending it with sockets, but am struggling with where to start with it and do not know if it is indeed the best option. Could anyone provide some advice on this matter?
Thanks in advance.
If I correctly understand the way it works (applications save the emails to SQL then another application takes them out and sends them) you have two choices:
Save the attachment as binary in the SQL and have the mailer application do the rest.
Use sockets to transfer the file to the SQL server and save the path to it just as you said.
I'd say option 1 would be the best option if I understood correctly the way its currently working. And as for option 2, there are probably other ways to transfer the file but sockets would be the easily cross-platform option.
Its not hard to get started with sockets, there are a lot of examples all over the internet.
winsock
more winsock
sys/socket.h
more sys/socket.h
I record some calls on my PBX and save them as .wav files in /tmp/ on the PBX server. I would then like to transcode them to mp3 and email them to various recipients as attachments.
My concern is that transcoding from wav to mp3 can be resource intensive as the number of users grow so I would like to send the wav file along with its metadata (CallerID, email adresses of recipients, time and date recorded) to another server that will be dedicated to transcoding to mp3 and emailing the resulting files. This offloads the PBX server to only handling calls and it also doesn't hog the call while waiting for the conversion to finish.
I am not sure how to proceed to transmit the metadata and the files to the transcoding server.
I thought of feeding the wav file and the metadata to a PHP script running on the transcoding server with cURL but would that be the most efficient way?
I also though about transferring the wave file over a shared NFS mount with unique directory names and have the metadata saved in a text file along a cron to process whatever jobs are waiting there every 5 minutes. The process of extracting the metadata from the text file seems a bit convoluted and not very elegant either.
I am quite interested to read how more seasoned coders would approach and solve this problem.
Cheers!
instead of pushing the file from the asterisk server, i would rather try pulling it from the transcoding machine. at the end of each transcoding operation i would check to see if there are any more files in the source directory, and pull the oldest one that i found, or sleep for a few seconds if there is nothing to do and try again. a shell script should be good enough. you can throttle the load of your encoding processor, have one or more encoding processes running simultaneously, etc. NFS, ftp or scp would be just about as good.
I have a c++ project (server-side) which sends the data to the client side with the help of event source. Now for debugging purposes I have maintained a trace file (text). On all the critical areas in the c++ code where there is a fear of code-break, I have added a line which writes the "success" text to this trace file. It works fine. I can know where the code is success and where it failed.
But I am on the server side. I want to avail this facility to the client too. However, I am unsure about how to do that? Should I stream the file on web-browser, or is there any other way I can send the data "live" to web-browser?
I checked this link, however, I am not sure if I can use this. http://www.tutorialspoint.com/cplusplus/cpp_web_programming.htm
Thanks
your question is a bit confusing, and without any sample of your code it is a bit unclear of what you want to do. however, the best suggestion i can give is to do this:
Store the text document on a server of your choice.
write a program to contact the server and download the data. (Using Winsock.h)
OR
Directly send the file to the computer. you'll have to write a program to contact the server at which point B is located.
for information on writing an application using Winsock.h, check here:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms737629(v=vs.85).aspx
if you really must store the data live in a web browser, then take a look at Java or VisualBasic, as both are heavily supported in all web browsers, while C++ is not.
Let me see if I understand you correctly. You want to send success / failure of the webserver to your client program?
Well, that's part of the job of a webserver, as dictated by the http protocol. A webserver will respond to a client request with a response header, followed by the requested page (if it exists as a valid resource on the server).
For more information on http response headers have a look at this article, or this wikipedia page, which both detail the request / response conversation between browser and webserver.
Hope this helps.