Reply to thread

Message

Strange, don't have that at my end. (although skipping forward can take a while because it has to wait until data is downloaded. This can go good if server respect the range bytes= header (then it can imediately start downloading from requested position) but if server doesn't support that it has to wait until current download is on that position).
But I must say it's not 100% foolproof...
That being said, I didn't encounter any noticable differences in behavior between all released versions, so your reark surprises me a bit.

Do you have a specific case where you can get a (near-) 100% successrate with 2.2.22 and failure with 2.26?
Only big change which could theoretically cause this was when updating ffmpeg in 2.24.
So can you get me the onlinevideos.log of such a case? And if you want, also test with 2.23 and 2.24 so updating ffmpeg could be ruled out?

<blockquote data-quote="doskabouter" data-source="post: 1287613" data-attributes="member: 98267">Strange, don't have that at my end. (although skipping forward can take a while because it has to wait until data is downloaded. This can go good if server respect the range bytes= header (then it can imediately start downloading from requested position) but if server doesn't support that it has to wait until current download is on that position).But I must say it's not 100% foolproof...That being said, I didn't encounter any noticable differences in behavior between all released versions, so your reark surprises me a bit.Do you have a specific case where you can get a (near-) 100% successrate with 2.2.22 and failure with 2.26?Only big change which could theoretically cause this was when updating ffmpeg in 2.24.So can you get me the onlinevideos.log of such a case? And if you want, also test with 2.23 and 2.24 so updating ffmpeg could be ruled out?</blockquote>

[QUOTE="doskabouter, post: 1287613, member: 98267"] Strange, don't have that at my end. (although skipping forward can take a while because it has to wait until data is downloaded. This can go good if server respect the range bytes= header (then it can imediately start downloading from requested position) but if server doesn't support that it has to wait until current download is on that position). But I must say it's not 100% foolproof... That being said, I didn't encounter any noticable differences in behavior between all released versions, so your reark surprises me a bit. Do you have a specific case where you can get a (near-) 100% successrate with 2.2.22 and failure with 2.26? Only big change which could theoretically cause this was when updating ffmpeg in 2.24. So can you get me the onlinevideos.log of such a case? And if you want, also test with 2.23 and 2.24 so updating ffmpeg could be ruled out? [/QUOTE]