I have a problem with net streams (shoutcast). Occasionally the stream cannot fill the buffer in time and the stream is starving. Problem is that it does not automatically recover from this condition. I would expect the buffer to be filled again and when it reaches more than 50% I would expect the app to continue playing but that does not happen, it hangs.
About the same problem was described in thread [url:241iag2a]http://www.fmod.org/forum/viewtopic.php?t=11372[/url:241iag2a] but unfortunately there was no answer.
The problem can be reproduced with the netstream example. Let the example program play a stream and shutdown the internet connection for a second (eg. with your firewall). The program displays "STARVING" but when the connection is opened again it does not continue. The example program then has to be stopped with a ^C because is does not respond to any other key.
In my real-life application the whole application hangs at this point and must be closed using the task manager.
Is this behaviour intentional?
What is the recommended action in this situation?
Another strange thing I noticed (is it allowed to address two problems in one topic?) that in the netstream example the buffer percentage starts at about 90%, goes down all the way to 1 or 2% and then starts again at 90%. This is repeated over and over again.
Thanks for reading,
Hans de Rijck
version 4.28, older versions the same problems.
- hansr asked 8 years ago
[quote:3rzajxgg]I think the way I hacked arround this "unresolved" issue was to detect the starving and just release the channel, create another sound and new channel with the same url. (without freeing the original sound as freeing the starving sound would only (often) deadlock my app) [/quote:3rzajxgg]
A hack indeed.
Some words of wisdom would be appreciated here.
Hans de Rijck
If the connection is slow and the sound starves it should recover from the starving state. If the connection to the internet disappears (i.e. unplug cable) the starving state cannot be recovered as the TCP connection is severed.
As icuurd12b42 mentioned you can release the channel at this point, the hang that he mentions has been fixed. You can create a new connection to the netstream and it will continue on cleanly.
Also with regards to the buffering, I just ran the example here and I see it go from 99% down to 50% then back to 99% as expected.
Not every one will have the same conditions… That link works pretty fine to me.
When I was having trouble, the same code would work flawlessly on my brothers PC (another location using another provider).
Also, your provider may trikkle the streaming site…
I think the way I hacked arround this "unresolved" issue was to detect the starving and just release the channel, create another sound and new channel with the same url. (without freeing the original sound as freeing the starving sound would only (often) deadlock my app)
It worked better than that pause suggestion in the example which does not actually work.
The result was pretty much what I suspect the example wanted to convey. To the listener, the sound stops and recovers, starts again at a position relatively around to point it froze (for web casts)
However, the leak pretty much anoyes me. And I am not sure if eventualy the connection is relinquished as the sound is not freed in order not to freeze the game.
Please login first to submit.