download users as csv in Google Apps

CV had a problem downloading list of Google Apps users as CSV - the option was grayed out in the control panel.

This post seemed to have the solution:

http://www.google.com/support/forum/p/Google+Apps/thread?tid=5a8c21e76144b065&hl=en

So, sign in, and then use the following url for the csv file:

https://www.google.com/a/cpanel/urdomain.com/DownloadUserData/UserData-urdomain.com-20110727.csv

where you must change the date 20110727 for the relevant date. We also have to remember that google servers use US time, so today is still 28 July for them and not 29 July.

Telugu stream playlist - Extended m3u to simple m3u

PB passed on the following info.

cat 26th_JULY.m3u | sed /^#/d | tr '\\' '\n' | tr '\r' '\n' | sed '/\(.mp3\)\|\(.MP3\)\|\(.Mp3\)/!d' | sed 's/^/\/home\/sgh\/audio\//' > 260711.playlist.telugu


sed /^#/d Remove the lines starting with #

tr '\\' '\n' The windows path backslash (\) is changed to line feed

tr '\r' '\n' The Carriage return is changed to line feed

sed '/\(.mp3\)\|\(.MP3\)\|\(.Mp3\)/!d' Remove the lines not having .mp3 or .MP3 or .Mp3

sed 's/^/\/home\/sgh\/audio\//' Add the path /home/sgh/audio at the beginning of each line.




Added tr '\r' '\n' on 26th July 2011.
The line used to end with both \r\n which made ices fail to start the playlist.

\r - Carriage Return - 0D in Hex
\n - Line feed - 0A in Hex

problem playing file from finder for live broadcast

There was some difficulty with using the technique I had used in April for playing an announcement file directly from Finder into the live broadcast. Going through the steps, found that the following sequence is required: First change system audio out to Jack device using Audio MIDI setup utility. Then the Jack setup file which I had created earlier can be loaded.

But in general, this is a bit risky - a better way to do announcement insertion would be to drag and drop the relevant files into the timeline on Reaper. This can be done even when Reaper is recording. The track into which the file is dropped should not be armed for recording - only then will the file play back if Reaper is recording on another track.

more ports on server

We wanted some more ports open on the server firewall, for future expansion if required. The service provider said they have opened the ports, but ShoutCast complained that it could not bind to those ports.

Did some troubleshooting by starting the server from the command line.

Found that the reason it gives for the other ports not to work is:
error opening client socket! FATAL ERROR! Some other process is using this port!

So it is not the service provider's fault.

When I test with telnet, I find (after stopping shoutcast)

telnet stream.radiosai.org 8021
Trying 66.249.27.181...
Connected to stream.radiosai.org.
Escape character is '^]'.
200 1500
GET / HTTP/1.1
fxÚ
ÍËÎË/ÏSHÎÏÍMÌKÑ5

Yesterday when I tested, ports 8023, 24 and 25 were also probably occupied by the other process. Today, those ports were open, and shoutcast could use those ports.

Using
Netstat -a -b -n -o > c:\netstatnames.txt

and searching for 8021 in that file,
found that the process is
G6FTPSERVER.EXE

So, requested that the Gene ftp be tweaked so that it uses only ports above 8100 for listening, like 8121 etc. That solved the issue.

procedure to change over to live broadcast

On stream.radiosai.org I have created services 8002, 8002live, 8020 and 8020live in addition to the services for the other streams. Batch files

c:\startlive.bat and c:\stoplive.bat do the work of

net stop 8002

sleep 5

net start 8002live

etc

(similarly for the 8020 stream, and similarly for stoplive)

Shortcuts on desktop for these bat files have been created. So, one minute before the live broadcast is to start, like 4.29 pm for the evening programme, just login with Remote Desktop and double-click on the respective icon.

To stop live, wait 70 seconds after the ending point - usually the Jaikar after Arati - and double-click the stoplive bat file. The BUTT has to be running during these 70 seconds too. This is because of buffering of the stream by the Shoutcast servers.

Edit: Initially we experimented with using Scheduled Tasks to automate the changeover, at least for the startlive which was a fixed time. But Scheduled Tasks don't run if the password is changed, and then we would also have issues when DST kicked in. So, decided manual change-over was better. And the next day the manual change-over came in useful when we had a long power outage at the Studio and could not change to live till 50 minutes into the morning session - recorded filler was played on air at that time.