When I first pointed the WD TV Live Plus at my UPnP server any attempt to play video would fail. I could browse the ContentDirectory just fine.
The log files indicate that the TVL+ was issuing rapid-fire GETs for the media, but closing the socket very quickly. It seemed stuck in an infinite loop that would continue no matter how you browsed using the remote. The only way to get it to play anything else was to reboot it.
After many tcpdumps I discovered that the HEAD response from my UPnP server used Content-encoding:chunked, and included a “0” in the payload of the response.
I suspect what was happening is that the TVL+ does not even try to read the “0”, and reused the socket to submit a new request. The 0 then appeared before the HTTP/1.1 200 OK, and this confused the response parser, causing the TVL+ to close the socket and re-establish the connection.
This problem did NOT occur when playing a URL from a server that responded to a HEAD with a 501 Not Implemented (and had no payload).
I altered my software to not have any payload in its HEAD response. However, it might be worthwhile to figure out why the TVL+ goes into an infinite loop fetching from the bad server to the exclusion of all other media until it is rebooted.
Umm, the correct reponse to a HEAD request is to send all of the headers that would be sent for a GET request but without the content.
So your Content-Length header should give the actual or estimated content length.
As far as I have figured out, the frequent GET rquests at the start of playing is the WDTVLive trying to determine how long the media stream is. If you look closely it should have Range headers in these requests.
I have not yet worked out a good way to tell the WDTVLive not to send these requests after the initial HEAD response.
But given that, I have not found anything in the UPNP specs that say it should not send all of those GET requests with the Range headers.
As far as I have figured out, the frequent GET rquests at the start of playing is the WDTVLive trying to determine how long the media stream is. If you look closely it should have Range headers in these requests.
I have not yet worked out a good way to tell the WDTVLive not to send these requests after the initial HEAD response.
But given that, I have not found anything in the UPNP specs that say it should not send all of those GET requests with the Range headers.
The thing I have observed in my tcpdumps is that it issues GET requests as fast as it can, then closes the connection and opens the next. The first one has no Range: header in the request. The rest all ask for Range: bytes=0- . They’re in a separate socket from the HEAD request so part of my earlier theory is bogus.
If it were asking for different Range-s it would be perfectly normal. That’s how modern software finds the moov atom in an MP4, or how they handle seeking.
They probably just need to add some doom-detection logic in the IO loop. It’s never the first thing you code when you are creating software from scratch, but eventually you get around to it.
