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...
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.
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.