【发布时间】：2013-07-23 05:10:30
【问题描述】：
我正在使用 MediaPlayer 类从 Android 应用程序中的 IceCast 2.3.2-kh29 服务器加载 MP3 流。 播放效果很好，但有时会停止。如果在 IcyStreamMeta 类中看到服务器对 ID3 标签的响应，则这种情况下会出现 404 错误。 它也发生在 Windows 7 中：Firefox 和其他浏览器。
这里是正常的标题（一些数据***）：
http://***:14534/***.mp3
GET /***.mp3 HTTP/1.1
Host: ***:14534
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
HTTP/1.1 200 OK
Server: nginx/1.4.1
Date: Tue, 23 Jul 2013 21:22:00 GMT
Content-Type: audio/mpeg
Transfer-Encoding: chunked
Connection: keep-alive
icy-br: 192
ice-audio-info: bitrate=192;samplerate=44100;channels=2
icy-description: MP3 192 Kbps
icy-genre: ***
icy-name: ***
icy-pub: 1
icy-url: ***
Cache-Control: no-cache
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Pragma: no-cache
因此，流有时只播放大约一分钟或更短的时间，有时几秒钟就停止了。 404错误的可能原因是什么？在其他设备中进行了稳定工作的测试。网速还不错。路由器会导致这样的事情吗？另外，IceCast 可能需要一些特殊的 HTTP 请求标头（如果它们不存在，它会给出 404）？还是在某些情况下是内部服务器错误？
So, from WireShark:
2973 53.630385000 SERVER'S IP 192.168.100.6 TCP 1466 14534 > 59847 [ACK] Seq=1284017 Ack=1 Win=63 Len=1412
2976 53.636352000 SERVER'S IP 192.168.100.6 TCP 1157 14534 > 59847 [PSH, ACK] Seq=1285429 Ack=1 Win=63 Len=1103
2978 53.671606000 SERVER'S IP 192.168.100.6 TCP 60 14534 > 59847 [PSH, ACK] Seq=1286532 Ack=1 Win=63 Len=5
2980 53.678606000 SERVER'S IP 192.168.100.6 TCP 60 14534 > 59847 [FIN, ACK] Seq=1286537 Ack=2 Win=63 Len=0
【问题讨论】：
-
当你说它停止时，具体会发生什么？服务器是否断开客户端？客户端是否与服务器断开连接？你能上传一个实际发生的问题的数据包捕获吗？
-
不知道，这个怎么判断？导致 FileNotFoundException 或 404。
-
在您的示例中，有 200。404 不能在中途出现。听起来您的源客户端正在随机断开连接。
-
如果查看 IceCast 错误修复，有一些 404 错误的情况，所以有可能是其他问题。我通过查看每 5 秒加载一次的 ID3 标签得到此错误。
-
查看 Wireshark 以深入了解正在发送的原始数据包。过去我在使用 Icecast 和 Android 时遇到过麻烦，但它因 Android 的构建而异。此外，某些设备实现了硬件编解码器，这意味着它们在支持某些类型的流方面可能有所不同。
标签： http audio streaming http-status-code-404 icecast