AlienBBC and SMIL playlists

[Ed Hughes]

Jules - here's the playlist in question:
http://www.npr.org/dmg/dmg.php?prgCo...=&mediaPref=RM

And here's the relevant mplayer/lame/transcoder logging (my comments in <<>>). It looks
to me like LAME gets EOF and shuts down normally, which causes transcoder to restart
everything:

<<end of current stream, 20041126_atc_9.rm.conf>>
13000/466034 ( 3%) 3:16:41 Message: ds_fill_buffer: EOF reached (stream: audio)
ds_fill_buffer: EOF reached (stream: audio)
decaudio: declen=65536 out=65536 (max 262144)

EOF code: 1

*** uninit(0x64A)
Uninit audio filters...
[libaf] Removing filter dummy
uninit audio: realaud
DEMUXER: freeing demuxer at 0x85354f8
DEMUXER: freeing sh_audio at 0x852ef40


<< getting the next stream in playlist, 20041126_atc_10.rm.conf >>
[[[uninit getch2]]]
Config poped level=3
Config pushed level is now 4
get_path('20041126_atc_10.rm.conf') -> '/home/ehughes/.mplayer/20041126_atc_10.rm.conf'

[[[init getch2]]]

Playing
rtsp://real.npr.na-central.speedera.net:80/real.npr.na-central/atc/20041126_atc_10.rm.
Filename for url is now
rtsp://real.npr.na-central.speedera.net:80/real.npr.na-central/atc/20041126_atc_10.rm
Message: Resolving real.npr.na-central.speedera.net for AF_INET...
Message: Connecting to server real.npr.na-central.speedera.net[63.210.103.14]:80 ...


<< stats below are from LAME - it prints these out when it's done with a stream... and is
exiting normally >>
13013/466034 ( 3%)| 0:07/ 4:46| 5:38/ 3:22:11| 42.491x| 3:16:32
average: 128.0 kbps MS: 13015 (100.0%)
block types granules percent
long: 52060 100.000%
start: 0 0.000%
short: 0 0.000%
stop: 0 0.000%
mixed: 0 0.000%

ReplayGain: -2.9dB
Lame has aborted. Cleaning up (waitpid returned: 27958)



Jules Taplin wrote:
> Hi Ed.
>
> Did you attach the logging?
>
> This could be troublesome, actually. Can you send me a playlist, or
> point me to one?
>
>
> -- Jules
>
>
> Ed Hughes wrote:
>
>> I installed AlienBBC to listen to NPR RealAudio streams. Sounds great
>> - thank you for
>> this! The only issue occurs when using an SMIL playlist: the first
>> stream plays through
>> and continually repeats.
>>
>> Using verbose logging for lame and mplayer (see below), it looks like
>> when mplayer gets
>> EOF on the first stream, the pipe between lame and mplayer is broken.
>> The
>> transcoder_proxy.pl restarts mplayer, resulting in the first playist
>> entry being
>> repeated.
>>
>> The same issue does not occur when $use_lame = 0.
>> Versions: MPlayer-1.0pre5, lame-3.96.1, alienbbc_0.11
>>
>> Any ideas?
>> -Ed

[Jules Taplin]

Hi Ed.

Well... I think the technical term for that is 'Arse'

You're right... if either lame or mplayer abort, then the transcoder
stops the stream, and closes it's socket. In response, slimserver
reconnects, and then it starts from the beginning again.

As it happens, it wouldn't be impossible for the transcoder to simply
restart lame, and get on with it again, but I'm not sure it's safe. Bear
in mind that the proxy is unlikely to tell the difference between an
abort because it has a problem, and a natural termination

Triode has some pretty exciting changes in mind, however, so we may
eventually find a better way to deal with this, although I'm not sure
what it will mean for this sort of thing.

For now, I think we're just stuck with it


-- Jules

Ed Hughes wrote:

>Jules - here's the playlist in question:
>http://www.npr.org/dmg/dmg.php?prgCo...=&mediaPref=RM
>
>And here's the relevant mplayer/lame/transcoder logging (my comments in <<>>). It looks
>to me like LAME gets EOF and shuts down normally, which causes transcoder to restart
>everything:
>
><<end of current stream, 20041126_atc_9.rm.conf>>
>13000/466034 ( 3%) 3:16:41 Message: ds_fill_buffer: EOF reached (stream: audio)
>ds_fill_buffer: EOF reached (stream: audio)
>decaudio: declen=65536 out=65536 (max 262144)
>
>EOF code: 1
>
>*** uninit(0x64A)
>Uninit audio filters...
>[libaf] Removing filter dummy
>uninit audio: realaud
>DEMUXER: freeing demuxer at 0x85354f8
>DEMUXER: freeing sh_audio at 0x852ef40
>
>
><< getting the next stream in playlist, 20041126_atc_10.rm.conf >>
>[[[uninit getch2]]]
>Config poped level=3
>Config pushed level is now 4
>get_path('20041126_atc_10.rm.conf') -> '/home/ehughes/.mplayer/20041126_atc_10.rm.conf'
>
>[[[init getch2]]]
>
>Playing
>rtsp://real.npr.na-central.speedera.net:80/real.npr.na-central/atc/20041126_atc_10.rm.
>Filename for url is now
>rtsp://real.npr.na-central.speedera.net:80/real.npr.na-central/atc/20041126_atc_10.rm
>Message: Resolving real.npr.na-central.speedera.net for AF_INET...
>Message: Connecting to server real.npr.na-central.speedera.net[63.210.103.14]:80 ...
>
>
><< stats below are from LAME - it prints these out when it's done with a stream... and is
>exiting normally >>
>13013/466034 ( 3%)| 0:07/ 4:46| 5:38/ 3:22:11| 42.491x| 3:16:32
>average: 128.0 kbps MS: 13015 (100.0%)
>block types granules percent
> long: 52060 100.000%
> start: 0 0.000%
> short: 0 0.000%
> stop: 0 0.000%
> mixed: 0 0.000%
>
>ReplayGain: -2.9dB
>Lame has aborted. Cleaning up (waitpid returned: 27958)
>
>
>
>Jules Taplin wrote:
>
>
>>Hi Ed.
>>
>>Did you attach the logging?
>>
>>This could be troublesome, actually. Can you send me a playlist, or
>>point me to one?
>>
>>
>>-- Jules
>>
>>
>>Ed Hughes wrote:
>>
>>
>>
>>>I installed AlienBBC to listen to NPR RealAudio streams. Sounds great
>>>- thank you for
>>>this! The only issue occurs when using an SMIL playlist: the first
>>>stream plays through
>>>and continually repeats.
>>>
>>>Using verbose logging for lame and mplayer (see below), it looks like
>>>when mplayer gets
>>>EOF on the first stream, the pipe between lame and mplayer is broken.
>>>The
>>>transcoder_proxy.pl restarts mplayer, resulting in the first playist
>>>entry being
>>>repeated.
>>>
>>>The same issue does not occur when $use_lame = 0.
>>>Versions: MPlayer-1.0pre5, lame-3.96.1, alienbbc_0.11
>>>
>>>Any ideas?
>>>-Ed
>>>
>>>
>
>

[Ed Hughes]

> Triode has some pretty exciting changes in mind, however, so we may
> eventually find a better way to deal with this, although I'm not sure
> what it will mean for this sort of thing.

Sounds good, and let me know if you guys could use some help.

[Niek Jongerius]

> As it happens, it wouldn't be impossible for the transcoder to simply
> restart lame, and get on with it again, but I'm not sure it's safe. Bear
> in mind that the proxy is unlikely to tell the difference between an
> abort because it has a problem, and a natural termination

FWIW, I currently run a spin-off from the alienstream stuff (compiled and
tweaked the Xine libs a bit, runs using stdin/stdout/sockets instead of
via pipes). For some reason, every now and then the WMA stream from the
radio station gets interrupted, causing alienstream to bail out. I have
added a few lines of code in my script that keep track of the last few
"crashes". If the crashes are happening too frequently and too quickly in
succession, the script assumes that the Internet stream somehow has gone
away completely (for instance, when it was streaming a single radio show
like H2G2) and it quits, shutting down the socket to the SlimServer.
However, when the crashes are infrequent, the script simply sets up the
connection to the Internet stream again (starting the alienstream and lame
processes).

In effect this construction keeps the socket from SS to the alienstream
daemon alive over the occasional stream interrupt. The only effect for the
listener is a gap of silence for about 10-20 seconds (the time it takes
the script to reconnect to the stream). I gather this same construction
could be applied to AlienBBC as well.

Regards, Niek.