SDR Sessions - Help

There is no audio/video!

This may happen, as not all announced sessions are active around the clock. It's some sort of a challenge to find out which sessions are active without the calendar function that comes with sdr.

Obviously not all of the sessions can be properly viewed with the Real player. Sorry about that. Any hints on how to distinguish the ones working from the ones that do not are appreciated and will (if feasible) be integrated into the script. The NASA HQ video and Places all over the World are always a good bet.

The Real player can play H.261 video; you might have to download the plugin, but the player will do that for you when it becomes necessary, if you wish. IP Multicast is referred to as Scalable Multicast by Real, and that's what it is, isn't it??

If you get frequent hang-ups, you might want to increase the settings in
Options -->
Preferences... -->
Connection -->
Network Time-Out Settings ... -->
Connection time-out & Server time-out

Hard to tell if it really helps...

Browser Configuration

Your browser has to be configured such that on receiving a file of type application/x-sdp (and/orapplication/sdp) the Real player (or any other player capable of interpreting SDP files and showing the audio/video streams) is started. This is in general automatically configured when you install the Real player.

Web Server Configuration

For the the guy who offers this page (in case the script circulates around the world): In mime.types (Apache web server, do not ask me about any other web server) a line has to be included, if not already present:
application/x-sdp   sdp
(and/or
application/sdp   sdp)
If it's not present, you see only the content of the sdr announcement instead of immediately launching the Real player, if you click on one of the Real links above.

Automatic Page Update

sdr periodically writes cache files, the default seems to be every 60 minutes. You can force sdr to write the cache files more often by adding a line
set save_interval 60000
(for 60000ms = 60s, choose any interval you like) to the ~/.sdr/prefs file.

Furthermore, add lines

proc periodic_save {interval} {
	after \$interval "write_cache; exec {/path-to-the-script/sdrcache2sdp}; periodic_save \$interval"
	}
(overwriting the existing routine) in your ~/.sdr/sdr.tcl file (create it if it does not exist) to make sdr call the script after each update. Tested with sdr 2.4a6n on Digital Unix.

Alternatively to the two modifications, use a ~/.sdr/sdr.tcl file like the following

proc periodic_save {interval} {
	after 60000 "write_cache; exec {/path-to-the-script/sdrcache2sdp}; periodic_save \$interval"
	}

# just to make sure the global variable is set, although it is ignored
# in periodic_save
proc user_hook {} {
        set save_interval 60000
        }

It is 'normal' that sdr freezes during writing the cache files and subsequent execution of the perl script. Yes, this may be called abusing sdr. It may be possible to call the script in the background (&) above.

What does the script do anyway??

It just copies the cache files of an sdr, deletes the first two lines of them (which are apparently not needed and contain strings n=.... and k=) and generates this page. That's it. No mystery involved.
Oh, yes, and it generates the sdr announcement list, a little transformed.

May I ...??

Sure. Copy the script, modify it, do what you like with it (almost).
I am grateful for comments, especially improvements of course, but also requests for further functionality, thanks!
Written by Stefan, who should be doing something completely different.