PDA

View Full Version : Working around bugs in native ogg streaming?



dsdreamer
2008-12-27, 13:38
I know there are some long-standing bugs that prevent me from streaming ogg radio stations to my SB3, but it must be fairly easy to configure Squeezecenter to transcode these for me. I can't seem to find a solution to this in the forums, so I am wondering if anyone has a solution they can share?

It should be a fairly easy hack of custom-convert.conf, but strangely I haven't seen one...

--dsdreamer

bpa
2008-12-27, 13:55
WebUI - Settings/Advanced/FileTypes - disable "native" for OGG.

dsdreamer
2008-12-27, 16:41
WebUI - Settings/Advanced/FileTypes - disable "native" for OGG.

Is there a way to transcode Icecast ogg/flac streams to native flac for decoding on SB3? I'm not sure that sox knows what to do with an ogg/flac stream.

Best regards,

--dsdreamer

bpa
2008-12-27, 16:46
Probably - create your own new file types and add appropriate lines in a custom-convert.conf file.

Examples would be AlienBBC which enables support of RealAudio over RTSP or the AACplus which hooks into SC ICY handling but lets mplayer decode AACplus into WAV.

JJZolx
2008-12-27, 21:01
WebUI - Settings/Advanced/FileTypes - disable "native" for OGG.

What a bassackwards thing to have to do to address a problem with streaming radio. Then you also disable native streaming of local Ogg content. Seems users have had mixed results using this as a workaround:

http://bugs.slimdevices.com/show_bug.cgi?id=4418

There seem to be so many oddball problems with streaming radio, many of them popping up overnight and (apparently) near impossible to fix, that there should be a separate way to address handling of remote streams vs. local content.

dsdreamer
2008-12-27, 23:37
Probably - create your own new file types and add appropriate lines in a custom-convert.conf file.

Examples would be AlienBBC which enables support of RealAudio over RTSP or the AACplus which hooks into SC ICY handling but lets mplayer decode AACplus into WAV.


Well, I tried the following and got only silence. mplayer from the command line works fine and can figure out the stream type by itself. But even if you force it as below, the UI claims that it is playing 129kbps ogg, even though I am playing VBR ogg/flag. These rules are at least being read, because I can see the use of mplayer under file types in for ogg in the SC UI. I can't see mplayer in the task manager process list, either.



# ogg audio replacement rules
ogg wav * *
# IR
[mplayer] -ac ffflac -demuxer ogg -vc null -vo null -nocache -af volume=0,resample=44100:0:1,channels=2 -ao pcm:nowaveheader:file=#PIPE# $FILE$
ogg mp3 * *
# IRB:{BITRATE=-B %B}
[mplayer] -ac ffflac -demuxer ogg -vc null -vo null -nocache -af volume=0,resample=44100:0:1,channels=2 -ao pcm:nowaveheader:file=#PIPE# $FILE$ | [lame] --silent -r -x -q $QUALITY$ -b $BITRATE$ - -
ogg flc * *
# IR
[mplayer] -ac ffflac -demuxer ogg -vc null -vo null -nocache -af volume=0,resample=44100:0:1,channels=2 -ao pcm:nowaveheader:file=#PIPE# $FILE$ | [flac] -cs --totally-silent --endian=little --channels=2 --sign=signed --bps=16 --sample-rate=44100 --compression-level-0 -


Any further clues would be appreciated.

--dsdreamer

bpa
2008-12-28, 02:21
My guess is your rules are not being used when the stream is being streamed.

Check using logging (Settings/advanced/logging) by setting player.source to INFO. You will see what rules are applied in the log.

I think you will need to create a new File Type which identifiies your stream type by the MIME type not by the extension.

dsdreamer
2008-12-28, 15:42
[08-12-28 13:56:42.2120] Slim::Player::Song::open (302) http://shuttle:8000/stream.ogg
[08-12-28 13:56:42.2179] Slim::Player::TranscodingHelper::getConvertCommand 2 (451) Error: Didn't find any command matches for type: ogg
[08-12-28 13:56:42.2189] Slim::Player::Song::open (323) seek=false time=0 canSeek=0SEEK_ERROR_TYPE_NOT_SUPPORTEDogg
[08-12-28 13:56:42.2236] Slim::Player::TranscodingHelper::getConvertCommand 2 (454) Matched: ogg->flc via: [mplayer] -vc null -vo null -nocache -af volume=0,resample=44100:0:1,channels=2 -ao pcm:nowaveheader:file=#PIPE# $FILE$ | [flac] -cs --totally-silent --endian=little --channels=2 --sign=signed --bps=16 --sample-rate=44100 --compression-level-0 -
[08-12-28 13:56:42.2246] Slim::Player::Song::open (340) Transcoder: streamMode=I, streamformat=flc
[08-12-28 13:56:42.2256] Slim::Player::Song::open (364) Opening stream (no direct streaming) using Slim::Player::Protocols::HTTP [http://shuttle:8000/stream.ogg]
[08-12-28 13:56:42.6637] Slim::Player::Song::open (385) URL is a song (audio): http://shuttle:8000/stream.ogg, type=ogg
[08-12-28 13:56:42.6681] Slim::Player::Song::open (457) Tokenized command "C:\Program Files\SqueezeCenter\server\Bin\MSWin32-x86-multi-thread\mplayer.exe" -vc null -vo null -nocache -af volume=0,resample=44100:0:1,channels=2 -ao pcm:nowaveheader:file=#PIPE# "-" | "C:\Program Files\SqueezeCenter\server\Bin\MSWin32-x86-multi-thread\flac.exe" -cs --totally-silent --endian=little --channels=2 --sign=signed --bps=16 --sample-rate=44100 --compression-level-0 -
[08-12-28 13:56:42.7048] Slim::Player::Pipeline::new (93) Launching process with command: "C:\Program Files\SqueezeCenter\server\Bin\MSWin32-x86-multi-thread\socketwrapper.exe" -d -i 4242 -w -o 4241 -c "\"C:\Program Files\SqueezeCenter\server\Bin\MSWin32-x86-multi-thread\mplayer.exe\" -vc null -vo null -nocache -af volume=0,resample=44100:0:1,channels=2 -ao pcm:nowaveheader:file=#PIPE# \"-\" | \"C:\Program Files\SqueezeCenter\server\Bin\MSWin32-x86-multi-thread\flac.exe\" -cs --totally-silent --endian=little --channels=2 --sign=signed --bps=16 --sample-rate=44100 --compression-level-0 -"
[08-12-28 13:56:42.7529] Slim::Player::StreamingController::_Stream (956) xx:xx:xx:xx:xx:cd: stream
[08-12-28 13:56:42.7769] Slim::Player::StreamingController::_Stream (985) Song queue is now 0,0
[08-12-28 13:56:42.7806] Slim::Player::StreamingController::_setPlayingStat e (1779) new playing state BUFFERING
[08-12-28 13:56:42.7815] Slim::Player::StreamingController::_setStreamingSt ate (1792) new streaming state STREAMING
[08-12-28 13:56:42.8963] Slim::Player::Player::_buffering (1172) Buffering... 0 / 261120
[08-12-28 13:56:43.2806] Slim::Player::Player::_buffering (1172) Buffering... 0 / 261120
[08-12-28 13:56:43.3280] Slim::Player::Pipeline::acceptWriter (230) Pipeline writer connected
[08-12-28 13:56:43.3350] Slim::Player::Pipeline::acceptReader (199) Pipeline reader connected


Many things are working as they should, e.g., my mplayer command is being asked to run under socketwrapper, but no bytes are ever forthcoming from the stream. Perhaps someone who knows more about the internals can comment on what might be going on?

--dsdreamer

bpa
2008-12-28, 15:56
It looks like Mplayer is not getting any data from SC ?
You need to find the blockage - either
- SC to socketwrapper
- socketwrapper to mplayer
- mplayer back to socketwrapper
- sockwtwrapper to FLAC.

More debug.

Run SC from a command prompt (this is a good start http://wiki.slimdevices.com/index.php/AlienBBC#Windows_2 but a bit out of date) and set player.source to DEBUG that way you will get debug info from socketwrapper. Socketwrapper will then indicate if it read any data from SC.

CatBus
2008-12-29, 10:57
What a bassackwards thing to have to do to address a problem with streaming radio. Then you also disable native streaming of local Ogg content.

This is not necessarily a problem. There are bugs in streaming local Ogg content that are also fixed by disabling native decoding. And as of the new streaming code, AFAICT transcoded streams have complete feature parity with native streams (seeking, etc), so there's no downside to doing this unless you have a low-powered NAS that can't keep up.

My local collection is 100% Ogg Vorbis, and I haven't been able to use native playback for one reason or another for the past several years. I'm keeping my fingers crossed for 7.3.2 though...

bpa
2008-12-29, 11:20
There are bugs in streaming local Ogg content that are also fixed by disabling native decoding.


As I understand it, not so much a bug as some encoding of OGG streams result in a requirement for large decoding table which the SB does not have enough memory so native decoding is needed as PC has the memory.

However I think the thread title is misleading as the user is using an SC unsupported combination of Flac/OGG/Icecast. I think the spec sheet just support OGG/Vorbis not Ogg/Flac.

The title should be " Working around unsupported combinations of ogg streaming"

CatBus
2008-12-29, 11:44
As I understand it, not so much a bug as some encoding of OGG streams result in a requirement for large decoding table which the SB does not have enough memory so native decoding is needed as PC has the memory.

That's one bug (or whatever terminology applies), but it's not the one I run into. The other one is bug#6442, and that's definitely just a plain old bug, and it's the reason I've never used native Ogg playback.

dsdreamer
2008-12-30, 12:36
As I understand it, not so much a bug as some encoding of OGG streams result in a requirement for large decoding table which the SB does not have enough memory so native decoding is needed as PC has the memory.

However I think the thread title is misleading as the user is using an SC unsupported combination of Flac/OGG/Icecast. I think the spec sheet just support OGG/Vorbis not Ogg/Flac.

The title should be " Working around unsupported combinations of ogg streaming"

I bent the intend of the original thread, since I was originally interested in getting ogg/Vorbis running (which was easily done by the first answer) and then, I wanted to extend that to ogg/flac. The reason is that with an in-home streaming solution I have plenty of bandwidth for ogg/flac using SB3 boxes as the end-points but it is not strictly necessary as ogg/Vorbis Q=10 has very few audible artifacts.

Best regards,

--dsdreamer