Unfortunately, I've seen many really crappy HTTP stacks in commercial products. RFC1945 and RFC2616 are clear about that. There are many cases where the source simply does not know the length of what it's about to send. In HTTP, content-length is optional and they should not rely on it.
This is very bad practice and not compilant. Feels like the attempt to re-open and read with an offset of 128k on mp3 although only ~30k have been sent confirms that. I think, in your case, that the HTTP stacks wants a content-length in the GET response and shuts off the connection when it does not get one. I've seen a lot of players with very bad HTTP/UPnP stacks, not respecting specifications. interestingĪnyway, the issue is not what I thought, it's a problem with your UPnP device, very likely. Anyone else? Anything I can try to get more information?
Logs, config, and device description XML attached.Īny ideas what the problem could be? One other person (issue #133) saw this before. The device works fine playing from all other UPnP/DLNA players I've tried. read_line:1186 fd: 17 read error: Connection reset by peer http_parse:1105 cannot read method http_thread_func:1079 HTTP close 17 In the logs, the key error always seems to be: If I pause from the player the device says "Paused 00:00".
SOFAPLAY OPERATING INFO MAC
When airupnp starts up, it finds the device and exposes it, but if I try to play music to it from Apple Music (on Mac or iPhone) the device says only "Streaming from AirConnect" with a spinner or (if MP3 mode is selected in the config) goes quickly to "End of Queue". I'm running AirUPnP on a Mac to expose a Cambridge Audio Minx Xi (UPnP device) as an Airplay speaker.
0 kommentar(er)
