![]() ![]() It means that each chunks starts with the size of the chunk and \r\n, then the data. You see that transfer-mode is chunked which means that data is divided in chunks. Icy-notice2:SHOUTcast Distributed Network Audio Server/Linux v1.9.5Īccess-Control-Allow-Headers: Origin, Accept, X-Requested-With, Content-TypeĪccess-Control-Allow-Methods: GET, OPTIONS, HEAD Icy-name:Fluid: Drown in the electronic sound of instrumental hiphop, future soul and liquid trap. Maybe you can try to make sofaplay stream a webradio and do a wireshark capture so that, if it works, I can see if there is a way I can handle this non-compliant behavior w/o becoming non-compliant myself I'm going to upload in a few mins a version (0.2.28.5) with a bit more logs to confirm that w/o requiring you to take wireshark. When I receive the request for a range and I can't answer to that, I do one of the compliant answer which is a 200 with the whole file and no content-length. Unfortunately, per my previous post, this is a non-compliant practice. Sofplay, which again knows the size of the file answers with a 206 and after that the player requests the full size that has been indicated in the 206. So I'm still wondering, is the device behaving differently when it is given a stream from AirUPnP as opposed to getting one from its own UI? Is there any way to make AirUPnP just publish the stream at a URL (like in the example above) and not try to do anything to the device itself, and then I can point the device at the URL from its UI?ġ/ In the "SetAVTransport" the DIDL header contains a "size" field which is known by sofaplay but can't be known in the can or AirPlayĢ/ Then, the player requests first a chunk (range 0-127999) of 128k to, I assume, try to guess the size of the file to be received. Both get one header and then just transfer data. I tried curl -trace on the Soma stream and AirUPnP's and could not see any difference. The MIME type is different (audio/mp3 vs audio/mpeg) but I also suspect that does not matter. The 'chunked' is different but does not seem to affect behavior as said. I'm not trying to be picky, if I could, I would add content-length but the very nature of an AirPlay to UPnP bridge is that I receive a real time continuous/synchronous stream of audio that I transform into a ressource available asynchronously (with some rules to discard elapsed audio)Ĭonnecting to 192.168.100.4:63427. Mine is not a reference, but I don't sell anything :-) ![]() 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". 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 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |