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
MediaPortal 1 Plugins
Popular Plugins
OnlineVideos
SVT Play
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="georgius" data-source="post: 934387" data-attributes="member: 107951"><p>If it is possible, try to make logs from other videos on SVT site for comparing. Your decryption times are very long (one fragment of data, approx. 2 MB, takes 5 seconds). So problem is not in your download speed, but in decryption.</p><p> </p><p></p><p>Because only HTTP protocol return total length of data to download, then only for HTTP protocol is returned correct buffered length of data and correct total length of data. For all other protocols is total length just guessed and adjusted while receiving data (this is cause why buffered percentage skips from 75% back to 50%). Maybe I change this in later versions.</p><p> </p><p></p><p>I guess that transfer was interrupted and filter cannot open connection again, but logs are needed in this case. Filter always make logs (MPUrlSourceSplitter.log, maybe MPUrlSourceSplitter.bak) in default MP logs directory.</p></blockquote><p></p>
[QUOTE="georgius, post: 934387, member: 107951"] If it is possible, try to make logs from other videos on SVT site for comparing. Your decryption times are very long (one fragment of data, approx. 2 MB, takes 5 seconds). So problem is not in your download speed, but in decryption. Because only HTTP protocol return total length of data to download, then only for HTTP protocol is returned correct buffered length of data and correct total length of data. For all other protocols is total length just guessed and adjusted while receiving data (this is cause why buffered percentage skips from 75% back to 50%). Maybe I change this in later versions. I guess that transfer was interrupted and filter cannot open connection again, but logs are needed in this case. Filter always make logs (MPUrlSourceSplitter.log, maybe MPUrlSourceSplitter.bak) in default MP logs directory. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
MediaPortal 1 Plugins
Popular Plugins
OnlineVideos
SVT Play
Contact us
RSS
Top
Bottom