2014-04-18, 11:57
What commits are we talking about here? Is it supposed to be fixed? (sorry, I haven't followed this thread.) Tried latest gotham branch as of today (4540f8092d) but still can't seek in these streams.
(2014-04-18, 11:57)takoi Wrote: What commits are we talking about here? Is it supposed to be fixed? (sorry, I haven't followed this thread.) Tried latest gotham branch as of today (4540f8092d) but still can't seek in these streams.Its pull request #4546, I've been testing on the master branch but I see now that it has also been merged into the Gotham branch.
(2014-04-18, 14:01)DBMandrake Wrote: Ah. The problem I was seeing was with plain http/https - webdav may be a bit different, and its likely a completely separate issue. Does it fail to seek on the first attempt ?
If it does then its probably the case that the stream is being marked as unseekable during the initial connection opening (m_seekable=false) so that seeks are not even attempted, rather than attempted and failing.
Try enabling verbose logging for the CURL library in the debugging options and capturing another debug log - this will also capture all HTTP request and response headers and may provide a clue why it thinks the stream is not seekable.
2014-04-18 16:05:00,961 INFO Starting up PyWebDAV server (version 0.9.8)
2014-04-18 16:05:00,961 INFO chunked_http_response feature ON
2014-04-18 16:05:00,961 INFO http_request_use_iterator feature OFF
2014-04-18 16:05:00,961 INFO http_response_use_iterator feature ON
2014-04-18 16:05:00,961 INFO Initialized with share http://localhost:8000/
2014-04-18 16:05:00,961 WARNING Authentication disabled!
2014-04-18 16:05:00,961 INFO Serving data from share
Listening on localhost (8000)
2014-04-18 16:05:06,740 INFO Serving content of http://localhost:8000/sample.mkv
127.0.0.1 - - [18/Apr/2014 16:05:06] - XBMC/14.0-ALPHA1 Git:20140418-49d1cc3 (Linux; Arch Linux; 3.14.0-4-ARCH x86_64; http://xbmc.org) - "HEAD /sample.mkv HTTP/1.1" 200 -
2014-04-18 16:05:06,740 INFO Headers:
HTTP/1.1 200 OK
Server: DAV/0.9.8 Python/2.7.6
Connection: close
Date: Fri, 18 Apr 2014 14:05:06 GMT
Content-type: video/x-matroska
Transfer-Encoding: chunked
Date: Fri, 18 Apr 2014 14:05:06 GMT
DAV: 1,2
Last-Modified: Sun, 01 Sep 2013 13:17:55 GMT
Connection: Keep-Alive
Keep-Alive: timeout=15, max=86
Content-Length: 0
2014-04-18 16:05:06,752 INFO Range: bytes=0-
User-Agent: XBMC/14.0-ALPHA1 Git:20140418-49d1cc3 (Linux; Arch Linux; 3.14.0-4-ARCH x86_64; http://xbmc.org)
Host: localhost:8000
Accept: */*
Accept-Charset: UTF-8,*;q=0.8
2014-04-18 16:05:06,752 INFO Serving range 0 -> 4685563872 content of http://localhost:8000/sample.mkv
127.0.0.1 - - [18/Apr/2014 16:05:06] - XBMC/14.0-ALPHA1 Git:20140418-49d1cc3 (Linux; Arch Linux; 3.14.0-4-ARCH x86_64; http://xbmc.org) - "GET /sample.mkv HTTP/1.1" 206 -
2014-04-18 16:05:06,752 INFO Headers:
HTTP/1.1 206 Partial Content
Server: DAV/0.9.8 Python/2.7.6
Connection: close
Date: Fri, 18 Apr 2014 14:05:06 GMT
Content-type: video/x-matroska
Transfer-Encoding: chunked
Date: Fri, 18 Apr 2014 14:05:06 GMT
DAV: 1,2
Last-Modified: Sun, 01 Sep 2013 13:17:55 GMT
Connection: Keep-Alive
Keep-Alive: timeout=15, max=86
Content-Length: 4685563872
Content-Type: video/x-matroska
(2014-04-18, 16:34)takoi Wrote:Settings->System->Debugging->Enable Debug Logging. (You did do that before your first log, right ?)(2014-04-18, 14:01)DBMandrake Wrote: Ah. The problem I was seeing was with plain http/https - webdav may be a bit different, and its likely a completely separate issue. Does it fail to seek on the first attempt ?
If it does then its probably the case that the stream is being marked as unseekable during the initial connection opening (m_seekable=false) so that seeks are not even attempted, rather than attempted and failing.
Try enabling verbose logging for the CURL library in the debugging options and capturing another debug log - this will also capture all HTTP request and response headers and may provide a clue why it thinks the stream is not seekable.
Debugging options where? How do you do that, enable curl logging?
Quote: I don't think webdav have anything to do with it though. It's added as a plain http uri (see above log) and none of the webdav functionality is used.Well it works fine for normal http, so there must be some difference with webdav. A full debug log with the verbose options is needed to see what's happening though - a server log won't show nearly as much.
(2014-04-18, 17:16)DBMandrake Wrote: Settings->System->Debugging->Enable Debug Logging. (You did do that before your first log, right ?)Well that's new:) I've used advancedsettings to get rid of the osd, so no I haven't seen that before
Then below that verbose logging->Verbose Logging for CURL library.
(2014-04-18, 17:16)DBMandrake Wrote: Well it works fine for normal http, so there must be some difference with webdav. A full debug log with the verbose options is needed to see what's happening though - a server log won't show nearly as much.You might be right. With twistd web server it works. Yet other players have no problems with davserver. Let me come back with that debug log.
(2014-04-18, 18:41)takoi Wrote: Here's the two sessions. davserver respond with Transfer-Encoding: chunked, and xbmc appears to immediately set seekable to false https://github.com/xbmc/xbmc/blob/3aaa80...e.cpp#L949 not even try to send range requests. Is this correct?I'm not familiar with the code but yes it appears to be the case that if Transfer-Encoding is reported by the server as chunked then XBMC will assume that the file size is unknown and thus not attempt to seek the stream. (XBMC won't try to seek on streams of unknown length)
Quote:It doesn't send Accept-Ranges either so maybe it doesn't even support it(?). Still don't know how other players mange it thoughI'm not that familiar with some of the finer points of the http protocol, (I haven't heard of chunked encoding before) but this wikipedia page suggests to me that the server is sending out an invalid combination of headers:
(2014-04-18, 19:32)DBMandrake Wrote: So is the problem the server is sending two incompatible headers in the same response ? (It shouldn't even need to use chunked to send a file of known file size anyway, its only intended for dynamically generated content) Or is XBMC too literal in its interpretation of the headers - if it finds a Content-Length header should it just use it anyway ?That's the question. I have no idea either, it does seem picky though.
I don't know. I'm sure that the test you highlighted on line 949 was put there for a reason...
Is there a config option on your dav server to disable chunked encoding ?
(2014-04-18, 20:31)Kib Wrote: You arent using dav functionality even right?What, everything but apache and nginx "wrong" now? I'm using pywebdav, I said so in the beginning.
Normal apache or nginx would just work in that case.
(2014-04-18, 20:30)takoi Wrote:Have a look at the pywebdav documentation - looks like there is a config option to disable chunk support:(2014-04-18, 19:32)DBMandrake Wrote: So is the problem the server is sending two incompatible headers in the same response ? (It shouldn't even need to use chunked to send a file of known file size anyway, its only intended for dynamically generated content) Or is XBMC too literal in its interpretation of the headers - if it finds a Content-Length header should it just use it anyway ?That's the question. I have no idea either, it does seem picky though.
I don't know. I'm sure that the test you highlighted on line 949 was put there for a reason...
Is there a config option on your dav server to disable chunked encoding ?
For me, I think I'll at least install the webdav module to apache and try that before doing any debugging or fixing of davserver or xbmc. I might not even end up using that server anyway..
Quote:0.9.4 (April 15 2010)
Add somme configuration setting variable to enable/disable iterator and chunk support [Stephane Klein]