home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
Development
General Development (no feature request here!)
MERGING MediaPortal Url Source Splitter & IPTV Filter
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="doskabouter" data-source="post: 1287613" data-attributes="member: 98267"><p>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).</p><p>But I must say it's not 100% foolproof...</p><p>That being said, I didn't encounter any noticable differences in behavior between all released versions, so your reark surprises me a bit.</p><p></p><p>Do you have a specific case where you can get a (near-) 100% successrate with 2.2.22 and failure with 2.26?</p><p>Only big change which could theoretically cause this was when updating ffmpeg in 2.24.</p><p>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?</p></blockquote><p></p>
[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]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Development
General Development (no feature request here!)
MERGING MediaPortal Url Source Splitter & IPTV Filter
Contact us
RSS
Top
Bottom