Kodi Community Forum
Gotham - seeking on some http streams broken - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: OS independent / Other (https://forum.kodi.tv/forumdisplay.php?fid=228)
+---- Thread: Gotham - seeking on some http streams broken (/showthread.php?tid=189963)

Pages: 1 2 3 4 5 6


Gotham - seeking on some http streams broken - DBMandrake - 2014-03-22

I've noticed recently that video playback on some add-ons which use http playback of standard video files (mp4, mkv and so on - not stream transport type files) no longer seeks properly.

After starting playback of an http file you can seek ONCE to anywhere in the file successfully, however further attempts to seek just continue playing at the same location with the following error:

DEBUG: SeekTime - input stream reports it is not seekable

Now I know that any http server that doesn't support resume won't allow seeking so I had assumed that might be the cause, but no - if I switch back to Frodo V12.2 the exact same clip from the exact same server using the same add-on seeks absolutely perfectly, anywhere in the file, instantly, as many times as you like.

I've also confirmed the server in question allows at least two concurrent downloads of the same file (some servers do not) as I've read that the seeking algorithm will first attempt to make a second connection to the same server for the seek point. (Although I can't remember whether that was Frodo or Gotham or find where I read that discussion)

So far I've observed this symptom with http streamed mkv files on one particular addon and I have observed seeking working OK with http streamed mp4 files on another add-on. I need to do a bit more testing to confirm whether it is all mkv's on any add-on, all files on particular add-ons (unlikely) etc.

Before I spend a lot of time capturing debug logs and trying to find a "forum friendly" example of the problem that others can reproduce, I wanted to know if this was a known problem or not. Something has certainly changed in the handling of seeking, possibly related to the rewritten buffering system.


RE: Gotham - seeking on some http streams broken - DBMandrake - 2014-03-22

Ok I think I have a pretty good idea of whats causing this problem now.

When seeking a second connection to the server for the same file is made and if that connection is successful it's used to start downloading from the new resume point. The problem appears to be triggered by the servers in question only supporting two simultaneous downloads of the same file at a time. I tested this by manually downloading the same URL taken from the debug log using CURL in three command prompt windows - the first two CURL's will happily start downloading the mkv file but the third simultaneous attempt for the same URL actually returns an HTTP page similar to this:

Code:
<!DOCTYPE html>
<html>
<head>
<title>Error</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>An error occurred.</h1>
<p>Sorry, the page you are looking for is currently unavailable.<br/>
Please try again later.</p>
<p>If you are the system administrator of this resource then you should check
the <a href="http://nginx.org/r/error_log">error log</a> for details.</p>
<p><em>Faithfully yours, nginx.</em></p>
</body>
</html>

The problem seems to be twofold here -

(1) The first connection is not being closed before the 3rd connection is opened, exceeding the 2 simultaneous connection policy of the server - eg initial playback opens one connection which succeeds, the first attempt to seek in the file opens a 2nd connection which also succeeds, (hence the FIRST seek succeeds) however the 1st connection remains open after the stream is playing from the 2nd connection.

A second attempt to seek does not close the 1st connection before attempting to open the 3rd connection so the 2 simultaneous connection policy of the server is exceeded and the http error page is returned instead of a video file. This shows as error 22 from libcurl in the debug log.

(2) When an unexpected http response is received on the 3rd connection attempt it is not handled gracefully. Instead of closing the 1st now idle connection to free up a connection slot the video simply continues playing on the second connection, with the first connection still open but idle and the stream now marked as un-seekable for the rest of the playback duration.

Here is the relevant section from the debug log:

Code:
12:34:23 T:2691728704   DEBUG: Keyboard: scancode: 0x7e, sym: 0x0111, unicode: 0xf700, modifier: 0x0
12:34:23 T:2691728704   DEBUG: OnKey: up (0xf080) pressed, action is ChapterOrBigStepForward
12:34:23 T:2973429760   DEBUG: CDVDPlayer::SetCaching - caching state 1
12:34:23 T:2973429760   DEBUG: demuxer seek to: 619596
12:34:23 T:2977157120    INFO: easy_aquire - Created session to http://50.7.57.211
12:34:23 T:2977157120   DEBUG: CurlFile::CReadState::Connect - Resume from position 1160990645
12:34:23 T:2691728704   DEBUG: CAnnouncementManager - Announcement: OnSeek from xbmc
12:34:23 T:2691728704   DEBUG: GOT ANNOUNCEMENT, type: 1, from xbmc, message OnSeek
12:34:23 T:2691728704   DEBUG: ------ Window Init (DialogSeekBar.xml) ------
12:34:23 T:2691728704   DEBUG: Window DialogSeekBar.xml was already loaded
12:34:23 T:2691728704   DEBUG: Alloc resources: 3.73m
12:34:23 T:2973429760   DEBUG: Seek - waiting for position 1161023076.
12:34:23 T:2691728704   DEBUG: Keyboard: scancode: 0x00, sym: 0x0136, unicode: 0x0000, modifier: 0x0
12:34:23 T:2691728704   DEBUG: GetActionCode: Trying Hardy keycode for 0xf200
12:34:23 T:2691728704   DEBUG: Previous line repeats 3 times.
12:34:23 T:2691728704   DEBUG: OnKey: 0 (0xf200) pressed, action is
12:34:24 T:2977157120    INFO: easy_aquire - Created session to http://50.7.57.211
12:34:24 T:2977157120   DEBUG: CurlFile::CReadState::Connect - Resume from position 1222613512:34:24 T:2977157120   ERROR: CCurlFile::FillBuffer - Failed: HTTP response code said error(22)
12:34:24 T:2977157120   ERROR: CCurlFile::CReadState::Connect, didn't get any data from stream.12:34:24 T:2977157120   ERROR: CFileCache::Process - Error 36 seeking. Seek returned -1
12:34:24 T:2977157120    INFO: CFileCache::Process - Hit eof.
12:34:24 T:2973429760   DEBUG: SeekTime - seek ended up on time 27936
12:34:24 T:2973429760 WARNING: error while seeking
12:34:24 T:2973429760   DEBUG: CDVDPlayer::HandleMessages - player started 1
12:34:24 T:2973429760   DEBUG: CDVDPlayer::HandleMessages - player started 2
12:34:43 T:2691728704   DEBUG: ------ Window Deinit (DialogSeekBar.xml) ------
12:34:54 T:2691728704    INFO: CheckIdle - Closing session to http://50.7.57.211 (easy=0x213f7400, multi=0x1d613200)
12:35:23 T:2953850880 WARNING: DARWINOSX: underflow (0 vs 4096 bytes)
12:35:33 T:2956017664   DEBUG: CCoreAudioStream::Close: Restoring original physical format for stream 0x0108. ([lpcm] Mixable Interleaved 2 Channel 24-bit Si
gned Integer LE (44100Hz))
12:35:33 T:2956017664   DEBUG: CCoreAudioStream::SetPhysicalFormat: Physical format for stream 0x0108. now active ([lpcm] Mixable Interleaved 2 Channel 24-bi
t Signed Integer LE (44100Hz))12:35:33 T:2956017664   DEBUG: CCoreAudioStream::Close: Closed stream 0x0108.

So shouldn't the first connection actually be closed before the 3rd is opened ? Surely it doesn't take more than two simultaneous connections to implement fast seeking - and many servers don't allow more than two connections anyway. Also if an error occurs establishing an additional seek connection should it not fail gracefully by closing and re-opening the original connection as a resumed connection ?

I haven't investigated to see what Frodo does differently but the same servers do seek perfectly in Frodo. Hopefully this is enough information for someone to investigate further. Setting up an HTTP server sharing video files which gives an HTTP error page if two simultaneous connections is exceeded for the same client should be all thats necessary to reproduce this problem in a controlled environment on a local network.


RE: Gotham - seeking on some http streams broken - ngoal - 2014-03-25

I am thankful that I was not the only one having this problem with Gotham. This issue occurs on both the PC and android version. Some streaming sources are fine but many will only seek once and will refuse to seek after that. I'm currently running both frodo and Gotham only because NHL game center will only work on Gotham. I am surprised that more people are not complaining about this problem as this was not an issue with frodo.


RE: Gotham - seeking on some http streams broken - DBMandrake - 2014-03-25

Ok, I've spent quite a bit of time debugging this problem further, trying to work out what is happening and capturing debug logs etc and have been able to reliably reproduce it without the use of any 3rd party add-ons, so I hope this bug report doesn't go under the radar... Wink

My initial hunch was right - Gotham Beta 2 cannot seek an http stream more than once when the server limits the client to a maximum of two simultaneous connections, while Frodo can. As some servers which serve http streams place a limit on the number of simultaneous connections this can be a serious problem.

To set up a reliable test platform I ended up installing apache2 on raspbmc, sharing a number of test videos using apache, and adding a video source that points to http://localhost - as far as XBMC is concerned it's connecting to files hosted on a website. I was then able to adjust the maximum number of simultaneous client connections apache allowed to simulate the problem, by editing apache2.conf like so:

Code:
# worker MPM
# StartServers: initial number of server processes to start
# MinSpareThreads: minimum number of worker threads which are kept spare
# MaxSpareThreads: maximum number of worker threads which are kept spare
# ThreadLimit: ThreadsPerChild can be changed to this maximum value during a
#              graceful restart. ThreadLimit can only be changed by stopping
#              and starting Apache.
# ThreadsPerChild: constant number of worker threads in each server process
# MaxClients: maximum number of simultaneous client connections
# MaxRequestsPerChild: maximum number of requests a server process serves
<IfModule mpm_worker_module>
    StartServers          1
    MinSpareThreads      25
    MaxSpareThreads      75
    ThreadLimit          64
    ThreadsPerChild      2
#    ThreadsPerChild      25
#    MaxClients          150
    MaxClients          2
    MaxRequestsPerChild   0
</IfModule>

By setting both ThreadsPerChild and MaxClients to the desired limit and restarting apache the issue can easily be reproduced when playing back a local video file shared via Apache without the use of any add-ons.

I tested both Frodo and Gotham Beta 2 with several different maximum simultaneous connection values to see what the behaviour was and how it differed.

Frodo: one simultaneous connection allowed:

Playback starts normally, attempting to seek freezes for approximately 20 seconds then the video either crashes out back to the file list, (.mov) or continues from where it left off. (.wmv, mp4, mkv)

Frodo: two simultaneous connections allowed:

Playback starts normally, attempting to seek works normally. No problems observable. When seeking a second connection is opened however the first connection is closed either just before the second is opened or very quickly afterwards - its too quick to see with the tools I'm monitoring with. For example during playback lsof will show one active connection from XBMC:

Code:
Every 1.0s: lsof -p 15260 | grep TCP | grep -v LISTEN                                           Tue Mar 25 16:25:02 2014

xbmc.bin 15260   pi   18u     IPv6     105896      0t0        TCP raspbmc:53063->raspbmc:http (ESTABLISHED)

As soon as I hit skip the port number changes so I can clearly see that a new connection was made and the old connection was terminated almost immediately:

Code:
Every 1.0s: lsof -p 15260 | grep TCP | grep -v LISTEN                                           Tue Mar 25 16:25:45 2014

xbmc.bin 15260   pi   24u     IPv6     108339      0t0        TCP raspbmc:53064->raspbmc:http (ESTABLISHED)

I didn't test 3 or more connections for Frodo as it's already working fine with two connections.

Gotham: one simultaneous connection allowed:

Playback fails completely with "one or more items failed to play". Gotham is sometimes trying open three simultaneous connections just to start playing the clip. (only some videos though, on others it only tries to open one connection)

Gotham: two simultaneous connections allowed:

On SOME videos (small filesize ?) playback starts normally with one connection open, attempting to seek freezes playback for approx 20 seconds and attempts to open TWO additional connections for a total of three as below:

Code:
Every 1.0s: lsof -p 18309 | grep TCP | grep -v LISTEN                                           Tue Mar 25 16:36:17 2014

xbmc.bin 18309   pi   19u     IPv6     122248      0t0        TCP raspbmc:53085->raspbmc:http (ESTABLISHED)
xbmc.bin 18309   pi   20u     IPv6     120476      0t0        TCP raspbmc:53078->raspbmc:http (ESTABLISHED)
xbmc.bin 18309   pi   23u     IPv6     121961      0t0        TCP raspbmc:53084->raspbmc:http (ESTABLISHED)

The seek succeeds, and two connections remain open rather than dropping back to one like Frodo immediately did, as seen here:

Code:
Every 1.0s: lsof -p 18309 | grep TCP | grep -v LISTEN                                           Tue Mar 25 16:43:25 2014

xbmc.bin 18309   pi   19u     IPv6     128954      0t0        TCP raspbmc:53119->raspbmc:http (ESTABLISHED)
xbmc.bin 18309   pi   20u     IPv6     128467      0t0        TCP raspbmc:53118->raspbmc:http (ESTABLISHED)

On the second attempt to seek the seek fails, playback resumes where it left off, and seeking is no longer allowed during playback of this video.

On some videos (longer files ? Possibly only MKV ?) even two concurrent connections is not enough to allow the video to play as it is attempting to open three simultaneous connections when starting playback of the clip. One example is "big_buck_bunny_1080p_h264.mov".

Gotham: three simultaneous connections allowed:

Playback starts normally, usually with one connection open, seeking succeeds every time. Each time a seek occurs two new connections are opened and the two old connections are closed.

Before a seek:
Code:
Every 1.0s: lsof -p 18309 | grep TCP | grep -v LISTEN                                           Tue Mar 25 16:47:09 2014

xbmc.bin 18309   pi   20u     IPv6     134896      0t0        TCP raspbmc:53145->raspbmc:http (ESTABLISHED)
xbmc.bin 18309   pi   23u     IPv6     134894      0t0        TCP raspbmc:53144->raspbmc:http (ESTABLISHED)

After a seek:
Code:
Every 1.0s: lsof -p 18309 | grep TCP | grep -v LISTEN                                           Tue Mar 25 16:47:31 2014

xbmc.bin 18309   pi   19u     IPv6     136213      0t0        TCP raspbmc:53146->raspbmc:http (ESTABLISHED)
xbmc.bin 18309   pi   23u     IPv6     136219      0t0        TCP raspbmc:53147->raspbmc:http (ESTABLISHED)

Clearly based on the evidence with max connections 2 the third connection is opened before one of the previous connections is closed, and if that third connection fails the situation is not handled gracefully.

Ok now some debug logs with maximum simultaneous connections set to two.

Gotham - successfully playing a video but unable to seek: (The log file went crazy towards the end with errors streaming past even though I was not continuing to attempt to seek)

http://pastebin.com/8KbzPqa4

Frodo - successfully playing the same video and successfully seeking multiple times:

http://pastebin.com/TqUJj1L8

So in summary there seems to be a major regression in the handling of HTTP streams.

Frodo can reliably play an http stream even if the server only allows a single simultaneous download, (although it can't seek and may sometimes abort the entire video during a seek attempt) and can reliably seek within a video if a minimum of two simultaneous downloads is allowed, which seems reasonable. (Although I'm not sure why it wouldn't be possible to fall back to allow seeking even on a single stream if the connection is aborted and resumed)

Gotham can't play a video at all if the http server only allows a single simultaneous download stream, it requires a minimum of two simultaneous downloads just to be able to play the file at all, which seems like a major flaw. A few specific videos seem to trigger three simultaneous downloads right from the beginning, and these files won't play even with two download streams enabled, yet they will play with a single stream on Frodo.

Likewise seeking (more than once) is only possible if the server allows a minimum of three simultaneous download streams - which seems very unnecessary. For some reason it is maintaining a minimum of two open connections once the first seek is performed, the second seek then attempts to open a 3rd connection, when that connection fails the stream is marked as un-seekable.

Hopefully the information I've provided is enough to reproduce this problem and hopefully solve it. As it stands now I'm probably going to be forced to go back to Frodo as some streaming video will not play at all due to these issues, and many are un-seekable. Sad

If any additional testing is required such as testing a fix, now that I have a test environment set up where I can easily reproduce it I'd be glad to help. Although the above testing was on a Raspberry Pi running miappa's March 23 build I can also test it on Mac OS and have duplicated most of the findings on the OS X Beta 2 build.


RE: Gotham - seeking on some http streams broken - popcornmix - 2014-03-25

It sounds multicache related. See:
https://github.com/xbmc/xbmc/pull/3963

On Frodo multicache was only enabled for mov/mp4/avi files.
On Gotham it's enabled for mkv files too.

I don't believe it's enabled for wmv files for example - do they behave differently on frodo and gotham?

Also I note you have "extract thumbails..." enabled. That may be opening an additional connection, so I'd suggest disabling that.


RE: Gotham - seeking on some http streams broken - DBMandrake - 2014-03-25

(2014-03-25, 22:58)popcornmix Wrote: It sounds multicache related. See:
https://github.com/xbmc/xbmc/pull/3963
Ah, thanks for linking that, I had come across that before but couldn't find it again. I notice with interest ulion's comment on how the code should fall back gracefully when concurrent connections are limited:

Quote:by design, when seek to new position out of current cached range, the curl
keep the first connection, then make a new one, then if the new one will
failed, it mark m_multisession 'false', then try to close the original
connection and use that curl handle to seek to the target position again
- if success, then the seek done, but the m_multisession marked false so
next time seek will directly close old and use old handle to seek.
- if the seek still failed, the stream will be marked as unseekable.

code is just there, but this is not strictly tested.
This fall-back definitely isn't working, instead of multi-session being disabled the stream is marked (in the debug log) as un-seekable, and the remaining multiple connections stay open.
Quote:On Frodo multicache was only enabled for mov/mp4/avi files.
On Gotham it's enabled for mkv files too.

I don't believe it's enabled for wmv files for example - do they behave differently on frodo and gotham?
The problem I'm seeing is affecting all file types I've tested although the symptoms vary slightly. I've tried mp4, mov, wmv and mkv - all fail to seek more than once if concurrent connections is limited to two.

Most fail to play at all with one concurrent connection, from memory I think only the WMV was able to play with one concurrent connection, the others all failed to even start playing.

In Frodo all could seek with two connections and all could play with one connection.
Quote:Also I note you have "extract thumbails..." enabled. That may be opening an additional connection, so I'd suggest disabling that.
Yeah I noticed that. I waited until the caching was finished before starting my tests. (Although when I took the debug log its possible that I didn't wait that time as I was in a hurry to finish - but I had already confirmed the issue multiple times before capturing the debug log)

Possibly related is that with Frodo the thumbnail caching seems to stop as soon as you attempt to play one of the files - one connection will be active generating thumbnails, but as soon as the video starts playing that connection is closed and a new one is started to play the video. So none of the available server slots are wasted by caching once playback is requested. (Good for bandwidth reasons too)

On Gotham Beta 2 it appears that more than one concurrent connection is used to cache thumbnails, and that thumbnail caching connections are NOT immediately closed when attempting to play a file, further exacerbating the symptoms - for example if concurrent connections is limited to 2 at the server and there are two thumbnail caching connections already active playback will not start until one of the thumbnail connections terminates - possibly 30 seconds or more later.

So actually getting the video to start playing at all while thumbnail caching is in progress and concurrent connections is restricted is difficult. It either waits a long time until caching is finished or aborts. I didn't mention it because its not directly relevant to internet HTTP streaming which is generally via an add-on rather than through the Files interface - in that case there is no thumbnail caching of a directory occurring.


RE: Gotham - seeking on some http streams broken - DBMandrake - 2014-04-03

(2014-04-03, 00:29)gregnukem Wrote: This seeking issue has been the only reason I can't finally upgrade to Gotham. I am also surprised so few people have noticed/mentioned this bug.
Yes, it's annoying me enough that I've set up a build/debug environment on Windows 7 with VS2010 to try to debug the problem myself. Although I have some coding experience (years ago) I'm not that familiar with C++ or familiar with the XBMC code base at all but that sort of thing has never stopped me trying before. Wink

I'm currently studying DVDInputStreamFile.cpp, FileCache.cpp, and File.cpp, and with the help of some breakpoints and testing with files hosted on an apache server with adjustable concurrent connection limits I'm starting to get a grasp of the problem.

If any devs (or those familiar with the code) are reading and want to point me in the right direction (functions or files to examine) that would be appreciated. I'm still trying to untangle the call structure and layers between the DVD player code requesting the data stream, (presumably in DVDInputStreamFile.cpp) the file cache and the low level file requests, and work out where the multiple streams are implemented - whether they're a part of the file cache, above or below it etc...


RE: Gotham - seeking on some http streams broken - DBMandrake - 2014-04-04

Still working on this. Smile

I decided that instead of pouring over the code for hours trying to find a needle in a large haystack that I'm not familiar with that I'd try doing a git bisect of the last years worth of commits between the Frodo release and present day to pinpoint the exact commit where the problem was introduced.

That's progressing well but due to the number of commits that's 12 rounds of bisecting with about a 15 minute compile time for each round and as I'm doing it on my work PC I'm not going to get it finished before going home for the weekend, but I should know on Monday which commit it was and be able to go from there. The exact cause of the problem should be far more obvious when narrowed down to a single commit.


RE: Gotham - seeking on some http streams broken - Kib - 2014-04-07

Great to see you are trying to find the cause, exactly as you describe these things take up an awful lot of time. Patches more than welcome!


RE: Gotham - seeking on some http streams broken - DBMandrake - 2014-04-07

(2014-04-07, 09:11)Kib Wrote: Great to see you are trying to find the cause, exactly as you describe these things take up an awful lot of time. Patches more than welcome!
Well I've finally narrowed down the precise commit where this problem was introduced.

It's one of four commits from pull request 2229:

https://github.com/xbmc/xbmc/pull/2229

The specific commit is:

https://github.com/ulion/xbmc/commit/b0609b3b0d5534b5ded7c8b30e3874fcb8a10793

Code:
commit b0609b3b0d5534b5ded7c8b30e3874fcb8a10793
Author: ulion <[email protected]>
Date:   Wed Feb 13 10:03:45 2013 +0800

    Fix: now mp4 file on internet url can be played by dvdplayer by double session support of cache.

Despite the description that seems to suggest only mp4 file handling is affected, I can verify that all file types streamed over http are affected.

During my bisecting I was using two test files - big_buck_bunny_1080p_h264.mov (692MB) and Elephant's Dream_10-25_440.wmv (831MB) as they are both free to download and large enough to test with bigstepforward without staying within the cache. The files were hosted with apache2 deliberately set to limit to two simultaneous connections.

On builds before this commit both files play and seek normally, one connection is opened for initial playback, during a large seek a second connection is opened then the first connection is immediately closed after the second has picked up at the seek location. So there is only ever a maximum of two simultaneous connections, briefly while seeking and only one connection during playback.

From this commit onwards big buck bunny fails to play at all with an error message (due to three simultaneous connection attempts at initial playback which cannot be satisfied by the server) and Elephants dream plays but can only seek once before seeks start failing. I notice in DVDInputStreamFile.cpp that .wmv video does not set READ_MULTI_STREAM (confirmed using a breakpoint) and yet still attempts to have three simultaneous connections open during a seek - surely a bug ? All other file types I've tested are also negatively affected, although some more than others, as above. Some simply can't seek, others won't play at all.

With a single simultaneous connection allowed instead of two, no file types will play, where builds before this commit can play all file types with a single simultaneous connection. (But can't seek - an acceptable limitation if a second stream can't be opened)

I've looked at that commit and it looks very invasive to me so I think my chances of figuring out a fix are pretty slim with my limited knowledge of C++ and the XBMC code, I think it's going to take someone who knows that code well to look over it with an experienced eye. I will still have a look though so if I make any further progress I'll report back, but narrowing it down to this commit may be all that I can contribute. (Other than further testing if someone wants me to test a fix)


RE: Gotham - seeking on some http streams broken - wsnipex - 2014-04-07

nice debugging Smile I've pinged ulion on his github


RE: Gotham - seeking on some http streams broken - Kib - 2014-04-08

If every bug out there would have someone do this we would be bugfree in moments Smile


RE: Gotham - seeking on some http streams broken - DBMandrake - 2014-04-08

(2014-04-08, 09:51)Kib Wrote: If every bug out there would have someone do this we would be bugfree in moments Smile
If something annoys me enough I can be quite determined to do something about it. Wink

As a workaround I've hacked CurlFile.cpp to disable multisession on http and https streams:

Code:
diff --git a/xbmc/filesystem/CurlFile.cpp b/xbmc/filesystem/CurlFile.cpp
index 6e29ffc..2d9fc97 100644
--- a/xbmc/filesystem/CurlFile.cpp
+++ b/xbmc/filesystem/CurlFile.cpp
@@ -938,7 +938,7 @@ bool CCurlFile::Open(const CURL& url)
   }

   m_multisession = false;
-  if(url2.GetProtocol().Equals("http") || url2.GetProtocol().Equals("https"))
+  /* if(url2.GetProtocol().Equals("http") || url2.GetProtocol().Equals("https"))
   {
     m_multisession = true;
     if(m_state->m_httpheader.GetValue("Server").find("Portable SDK for UPnP devices") != std::string::npos)
@@ -946,7 +946,7 @@ bool CCurlFile::Open(const CURL& url)
       CLog::Log(LOGWARNING, "CCurlFile::Open - Disabling multi session due to broken libupnp server");
       m_multisession = false;
     }
-  }
+  } */

   if(StringUtils::EqualsNoCase(m_state->m_httpheader.GetValue("Transfer-Encoding"), "chunked"))
     m_state->m_fileSize = 0;

In some brief testing it seems to revert streaming behaviour with limited simultaneous connection availability to that of Frodo and fix the problem outlined in this thread. (From what I can follow multisession is something Frodo didn't have anyway ?)

Obviously just a quick and dirty hack not a true fix, but it will do for me until the underlying issue is solved! Smile I'll try building it for Mac OS tonight which is my primary XBMC system, and do some more thorough testing. (I don't have a build environment to build it for the Raspberry Pi though, unless its possible to build directly on the Pi ?)

PS I've also pushed this patch here if anyone else affected wants to try building it until there is a proper fix:

https://github.com/DBMandrake/xbmc/tree/seek_fix


RE: Gotham - seeking on some http streams broken - DBMandrake - 2014-04-08

I've just noticed something else - with this hack in place, I can now play AND seek on any file type even if I limit the http server to ONE simultaneous connection. Smile Frodo could play (but not seek) with one simultaneous connection, so this is actually an improvement over Frodo.

Does this mean then that there is fall-back code in place to allow seeking with only a single simultaneous connection, and that the bug may simply be that when a seek in multisession mode fails (due to a failed/refused additional connection) it is marking the stream as un-seekable when it should be falling back to disabling multisession ?


RE: Gotham - seeking on some http streams broken - althekiller - 2014-04-08

There's only one point that there are three CReadStates in play there, lines 1172-1210. Give this patch a try: http://nopaste.linux-dev.org/?147629. It eliminates the third CReadState instance, but I didn't really check for repercussions.