finbar wrote:Hop
This is the initail reply from the vendor, please advise about DLNA 1.5 from your persepctive
Dear Finbar,
Our DPS1000 box supports DLNA 1.5 and the NessieDVB does not seem to be 100% compliant with DLNA 1.5 since DLNA 1.5 has no live stream support. This is from Oregan’s quick reply.
I really don't want to start any flamewar, but I must say they it is not true.
There is no explicitely specified that serving objects must be static files.
And more - there (In DLNA Guidelines) you can find Appendix chapter which perfectly
describes something called "Tuner object":
A Tuner is a component of a server device that makes audio and video content
available to a Rendering Endpoint. This content can come from an audio or AV tuner.
A key characteristic of a Tuner is the ability to decode or demultiplex a single media
stream from a number of available audio or AV streams. Note that in this Appendix
we refer to the abstract entity represented on the home network as a Tuner
(capitalized) and the physical building block inside the server doing the decoding and
demultiplexing as a tuner (without capitalization).
...
But again - I think we can use even file objects for respresentation of live streaming
content. The only thing we have to do is to signal to the client (renderer device)
that we not support any AV controls (what we do already).
The second option we can disscuss is, if Oynnx client is able to work without
using RANGE header support. Currently we are simply ignoring any RANGE
header in request what seems to work for most of clients we tested so far.
Specification of DLNA (unfortunatelly we have only 1.0 version of documentation)
says regarding requests with RANGE header and live content:
7.8.22.7 If any requested range for the specified URI can
never be processed/satisfied by the HTTP server, for
example, in the case of real-time transcoding or live
contents, the HTTP server must respond with 406 (Not
Acceptable).
So, if we do not ignore request with RANGE header and send
406 response on it, the client should understood that. Don't
know if it is a case of Oynnx client.
For checking that I just prepared new beta image (1.3.6) where
you can enable option "DLNA strict mode", which do exactly
406 answer if server detects RANGE header in request.
Please upload that beta image and recheck with enabled
"DLNA strict mode" option. Thanks.
BTW, could you please let us know how the device fails? Are you able to browse content?
If you have any other inquires or comments, please feel free to contact service@mitlondon.com.
Best Regards,
Digital Stream Technology
Do you think I should contact them directly? If it can simplify and speed up
problem fixing, then I can do it.
/Honza