Open kcharwood opened 14 years ago
I can confirm this behaviour. In our app, we don't handle error conditions in the streamer itself, but rather delegate these to a watchdog. Upon EOF we then recreate the streamer with the last URL. This seems to work fine, however I wonder whether it would be better to handle an EOF transparently by trying to reopen the CFNetworkStream instead.
Happens to me too. In the background it seems to be able to get the HTTP headers at least (I printed them to console), however it fails out with "Audio queue start failed. err: (garbaged characters)". Maybe I should just do like mickeyl, let another class do the connection + downloading.
I've been using the AudioStreamer in iOS4, and have noticed a few issues. When I am streaming audio while on WiFi, and move to 3G, the streamer seems to drop and the only way to get it playing is to completely restart it.
I've also noticed that if I have an audio stream playing with multitasking, and pause the stream, iOS pretty quickly will close the network connection (on the order of 4-5 minutes) for the stream. The only way to get it back is to recreate the streamer completely.