(2014-04-09, 18:01)althekiller Wrote: @DBMandrake https://github.com/t-nelson/xbmc/commits...o_in_multi
Give that a try, it's all in the blind, so I may have made a mess. Is there a plugin that presents this behavior I could be testing with? Your logs seem to be testing on a local httpd.
I used git cherry-pick to take your three commits and apply them to a new branch on top of master.
I've done some testing on this and I'm happy that the first two commits work and are clean enough to be obviously correct but the third commit makes me really nervous.
First commit:
https://github.com/t-nelson/xbmc/commit/...7e3a16bb29
Already tested earlier - this reduces the maximum simultaneous connection attempts from three to two preventing problems with two simultaneous connections, but still has problems with only one simultaneous connection.
Second commit: (applied on top of the first)
https://github.com/t-nelson/xbmc/commit/...1872c25d65
This also works perfectly as expected - with only one simultaneous connection allowed, on failure of a second connection attempt m_multisession is set to false and the recursive call to Seek works to automatically retry the connection without the calling function knowing anything went wrong. (So should be perfectly seamless) The commit is also simple and obvious enough that you can tell by looking at it that it's correct.
Third commit: (on top of the other two)
https://github.com/t-nelson/xbmc/commit/...1a749d2336
It's hard to follow the changes made here and what they're trying to do - were you only wanting to clean up the code but keep the functionality the same ? Because I've immediately noticed that this code behaves quite differently.
More specifically with commit 1 & 2 the connection flow (with two or more connections allowed) is as follows:
On initial startup connection 1 is opened. On first seek connection 2 is opened and starts streaming, connection 1 is left open. (and idle ?)
On second seek connection 1 is closed, connection 3 is opened and starts streaming, connection 2 is left open. (and idle ?)
On third seek connection 2 is closed, connection 4 is opened and connection 3 is left open and idle.
So the two connections "roll over" with the oldest connection of the pair being closed before a new connection is opened. Am I right in thinking this is the correct behaviour to allow the double cache to work properly ?
----
With commit three applied the connection sequence is:
On initial startup connection 1 is opened. On first seek connection 2 is opened and starts streaming, connection 1 is left open. (and idle ?)
On second seek connection 2 is closed, connection 3 is opened and starts streaming, connection 1 is left open. (and idle ?)
On third seek connection 3 is closed and connection 4 is opened, connection 1 is left open.
So the two connections no longer roll over - the initial connection stays open permanently and each seek causes the active connection to immediately close, thus double caching wouldn't work properly ?
So my (non coders) opinion is that commits 1&2 are no brainers and solve the problem completely but commit 3 either needs reworking or leaving out due to risk of additional unintended side effects...
Now on to test ulion's patch....