SDK level 8 (Froyo) has introduced the native capability for the MediaPlayer to connect to a streaming source, like Shoutcast. Previous SDK versions were able to do workarounds, such as run a local proxy on the device (see NPR).
I took the same approach as NPR and am using a StreamProxy. However, NPR first checks if the currently running SDK is less than 8. If so, it uses the proxy. Otherwise, it connects directly.
My StreamProxy requests metadata from the Shoutcast server, so it does not simply route the data from Shoutcast to my client. Instead, it parses out metadata and uses it accordingly, and only routes the music data.
When trying to use the StreamProxy at SDK level 8 or above, the MediaPlayer fails to prepare. My StreamProxy receives the connection and accepts it, but after successfully writing out the status line and headers to the client, the next write produces java.net.SocketException: Connection reset by peer
. This results in the client's mediaplayer throwing an Error(1,-1007)
.
I am trying to figure out why the MediaPlayer is unable to connect to my local proxy. It should be the same as connecting to the original source without the metadata, which does work. I am forwarding on all headers from the external source, through my proxy, which includes content-type.
I will continue looking into it, but I feel like I'm at a dead-end. Let me know if more details are needed.
EDIT: Ok I now believe I have the answer!
Stagefright is strict when it comes to line-endings in the HTTP-header; They have to be CR,LF and not just LF which has worked earlier.
So if you build your own headers, replace any "\n" with "\r\n" and you should be fine.
(If you want to check this for yourself, look at receive_line() in media/libstagefright/HTTPStream.cpp)
I can now stream shoutcast with Metadata on 2.2/Stagefright phones...
...
I have been running into the same problem;
First I tried writing the streamed data to a fixed length file and wrapping - and playing it with setLooping(true). This causes glitches when the MP3 loops, even though I extract whole MP3 frames and tried to pad the uneven bytes at the end with both 0xff and 0x00. This might still be an acceptable solution if you have a big enough file.
Then I did the proxy thing which works on my Samsung Galaxy S (v2.2) but not in the emulator and apparently not on the Desire (Not working = Error -1007 as mentioned above). One hint may be that the Galaxy S Mediaplayer asks for HTTP1.0, while it is 1.1 in the emulator.
The brute-force method would be to open 2 streams in parallel, reading meta-data from one and streaming from the other ;)
Anyway, I also want to hear if anyone else has had more luck...