PasTim;635123 Wrote: > I could use the commercial email address for feedback if that suits. > Let me know.Yes. That would be fine thanks.
PasTim;635123 Wrote: > I do notice that the content range in the last flac log looks very > strange and there are errors "Requested Range Not Satisfiable" and > "Range: bytes=0-1" looks weird, but then I don't know the protocol.It is my > theory that these HTTP Range requests are the root of the problem with the Humax. They are certainly very unusual, and I have encountered no other player that makes such. As you notice, before starting a transaction, it does a "HTTP HEAD Range: bytes=0-0" request (read the response headers corresponding to a GET of one byte); and if that fails, it does a "HTTP GET Range: bytes=0-1" (actual read of two bytes). The release version of Whitebear accepts such range requests when transcoding music because it CAN deliver these first one or two bytes. However in the test version I sent you, I decided to see what would happen if Whitebear would reject such range requests (416 Requested Range Not Satisfiable) because, even if it can deliver the first 1 or 2 bytes, it would later be in a pickle if asked to deliver the NEXT one or two bytes. This is because when transcoding via flac.exe and lame.exe you can never be exactly sure of the time offset in the input file that would be needed in order to deliver a coresponding byte offset in the output stream. Not to mention that mp3 streams deliver data in samples that are always larger than one or two bytes. By the way, the reason it works with the Humax when playing native mp3 files is that, since the server has the actual mp3 file in its hands, it CAN deliver exactly any range of bytes requested. Unlike the case when double transcoding where the server has to make guesses on the fly. Frankly, I am not sure WHY the Humax is doing these fancy HEAD or GET Range requests. I suppose it is trying to determine the full length of the stream from the response Content-Range header before it actually launches the full download of the music the stream using a proper full blown GET. As an aside, for example Windows Media Player, also always does two full blown GETs, of which the first one is immediately aborted; so the Humax is not alone in behaving oddly... Of course we still have the other theory about the UUUs in the mp3 file too... So, in my next test build, I shall do two things: 1) revert to accepting these odd Range requests, so that the response Content-Range header is delivered properly, and 2) capture the delivered stream in parallel to a disk file, so that you can then later test if the disk file plays as a native file on the Humax (UUUs and all). -- AndrewFG Regards, AndrewFG Try out Whitebear. The middleware that joins the two worlds of: 1. UPnP/DLNA media clients and media players, and, 2. Squeezebox Server and Squeeze Players Download it for free here: http://www.whitebear.ch/mediaserver ------------------------------------------------------------------------ AndrewFG's Profile: http://forums.slimdevices.com/member.php?userid=15838 View this thread: http://forums.slimdevices.com/showthread.php?t=87559 _______________________________________________ plugins mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/plugins
