0
0

Hi,

For some reasons that I can not explain, I encountered a shoutcast stream that fails to play with FMOD Ex under both Linux 32 and 64 bit systems. The error returned can be seen below, this was tested with an unmodified netstream (just typed make, so it’s the c++ version) example with the latest version (both development 4.11.03 and stable 4.10.03) but I also noticed this in 4.10.00.

The stream that fails is Radio Schwarze Welle (german gothic radio), I am not affiliated with them but give it here only as a reference for reproducing the problem.

It plays fine with mplayer, so the stream seems not to be at fault but something must be different (why does FMOD try to seek an internet stream?).

Looking at the network connection I see nothing unusual, it receives some bytes and then just resets the connection.

Output is through ALSA.

I hope you will be able to reproduce this.

Regards,
Carsten

[code:xznixjqf]$ ./netstream http://85.25.86.209:7500

NetStream Example. Copyright (c) Firelight Technologies 2004-2005.

Press space to pause, Esc to quit

FMOD error! (20) Couldn’t perform seek operation. This is a limitation of the medium (ie netstreams) or the file format.
[/code:xznixjqf]

  • You must to post comments
0
0

Thanks for the bug report, I have had a look into this and I can see what the problem is. Inside the stream there is a lot of ID3 data, 4k of it to be exact. The correct way to avoid this would be to use FMOD_IGNORETAGS when creating the stream, ID3 tags don’t really make sense in a shoutcast stream anyway since shoutcast has it’s own info tags.

You get a seek error because after reading the 4k of ID3 data we seek back to the start of the stream (normally this is fine because it fits in our 2k file buffer size), it’s just that the ID3 data is too large.

Using the FMOD_IGNORETAGS flag won’t be enough to fix this issue for you though since our MPEG codec currently only searches through the first 4k looking for the start of the actual MPEG data (which isn’t quite enough to get past the ID3 data). I have logged this as a bug on our system, we may need to expose the search size to the end user so you could specify the whole file if you liked to search for the start. This will be looked at after the holidays (so probably early in the new year).

  • You must to post comments
0
0

Is this due to be fixed soon? If not, is there a workaround you can think of for this? I’m running into this issue when streaming from my Firefly media server. I’ve looked at the tag on one of the MP3’s that fails, and it doesn’t seem to be bigger than 4K, it’s very small actually. I’m not sure how the MP3 data could be starting past the 4K mark..

My current workaround is to just download the whole file into memory then send it to FMOD without netstream. Not ideal obviously. Can you think of a better workaround? I could modify Firefly to add an option to strip tags I suppose, but that would be error-prone.

  • You must to post comments
0
0

I haven’t looked at the problem but if it is to do with the mpeg codec needing to search further use the FMOD_MPEGSEARCH flag and see if it helps.

  • You must to post comments
Showing 3 results
Your Answer

Please first to submit.