Gotham - seeking on some http streams broken
#61
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.
Reply
#62
(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.

You'll need to provide some more details about what kind of streams you're trying to seek on - not all streams are seekable. This patch only addresses the problem of trying to seek when concurrent connections are limited by the server. Also if you are compiling your own build try compiling the master branch instead of the Gotham branch to see if there is any difference - they are quite similar but not the same.
Kodi 18.3 - Mid 2007 Mac Mini, 4GB, 2TB HD, Windows 7 SP1
Kodi 18.3 - Vero4k, Raspberry Pi 2. OSMC.
Reply
#63
Sure, might not even be the same issue. I was testing some different setups and just realized I couldn't seek in files over http, seeing "SeekTime - input stream reports it is not seekable" in the log. Here it is: http://xbmclogs.com/show.php?id=177996 (master branch, but made no difference)

Server is `davserver`. Both vlc and ffplay can seek just fine so server definitely allows it.
Reply
#64
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.
Kodi 18.3 - Mid 2007 Mac Mini, 4GB, 2TB HD, Windows 7 SP1
Kodi 18.3 - Vero4k, Raspberry Pi 2. OSMC.
Reply
#65
(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? 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.

Here's server log:

Code:
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
Reply
#66
(2014-04-18, 16:34)takoi Wrote:
(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?
Settings->System->Debugging->Enable Debug Logging. (You did do that before your first log, right ?)

Then below that verbose logging->Verbose Logging for CURL library.
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.
Kodi 18.3 - Mid 2007 Mac Mini, 4GB, 2TB HD, Windows 7 SP1
Kodi 18.3 - Vero4k, Raspberry Pi 2. OSMC.
Reply
#67
(2014-04-18, 17:16)DBMandrake Wrote: Settings->System->Debugging->Enable Debug Logging. (You did do that before your first log, right ?)

Then below that verbose logging->Verbose Logging for CURL library.
Well that's new:) I've used advancedsettings to get rid of the osd, so no I haven't seen that before

(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.
Reply
#68
http://pastebin.com/B27k0ZPm
http://pastebin.com/UkG5itjy

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?

It doesn't send Accept-Ranges either so maybe it doesn't even support it(?). Still don't know how other players mange it though
Reply
#69
Please dont post logs on forum, but use pastebin or xbmclogs
Reply
#70
(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 though
I'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:

http://en.wikipedia.org/wiki/Chunked_transfer_encoding

It seems chunked encoding is an alternative to the normal Content-Length header that allows data to be sent in blocks when the file size is not known before hand (eg dynamically generated content) and that if Transfer-Encoding is chunked, there should not be a Content-Length header - the whole point of the chunked encoding is that the server wants to start sending the data without knowing the length of the file.

Your dav server is sending both Transfer-Encoding: chunked, AND a Content-Length header, which would seem at first glance to be invalid or outside the spec.

When XBMC sees Transfer-Encoding: chunked, it ignores the size value retrieved from the Content-Length header - I would say that the other players you have which are able to seek simply use the Content-Length header regardless and ignore the Transfer-Encoding chunked header.

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 ?

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 ?
Kodi 18.3 - Mid 2007 Mac Mini, 4GB, 2TB HD, Windows 7 SP1
Kodi 18.3 - Vero4k, Raspberry Pi 2. OSMC.
Reply
#71
(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 ?

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 ?
That's the question. I have no idea either, it does seem picky though.
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..
Reply
#72
You arent using dav functionality even right?

Normal apache or nginx would just work in that case.
Reply
#73
(2014-04-18, 20:31)Kib Wrote: You arent using dav functionality even right?

Normal apache or nginx would just work in that case.
What, everything but apache and nginx "wrong" now? I'm using pywebdav, I said so in the beginning.
Reply
#74
(2014-04-18, 20:30)takoi Wrote:
(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 ?

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 ?
That's the question. I have no idea either, it does seem picky though.
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..
Have a look at the pywebdav documentation - looks like there is a config option to disable chunk support:

Quote:0.9.4 (April 15 2010)

Add somme configuration setting variable to enable/disable iterator and chunk support [Stephane Klein]

https://pypi.python.org/pypi/PyWebDAV
Kodi 18.3 - Mid 2007 Mac Mini, 4GB, 2TB HD, Windows 7 SP1
Kodi 18.3 - Vero4k, Raspberry Pi 2. OSMC.
Reply
#75
You totally misunderstood me.

I just meant that if you want to test apache you don't need the WebDAV plugin, since you don't use dav functionality. Right?
Reply

Logout Mark Read Team Forum Stats Members Help
Gotham - seeking on some http streams broken0