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
Improvement Suggestions
Database Vs Shares UI
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="fforde" data-source="post: 341014" data-attributes="member: 52082"><p>Hrmm.. well to begin with the Shares view should not inherently be slower because it is the shares view. If it is slow that means there are problems with the implementation. Ultimately though both "Shares" view and "Database" view are just two ways to organize your video files based on meta-data about a file and it's contents. One should not necessarily be faster than another. If anything I'd expect the database view to be slower, since it is dealing with more information and more artwork.</p><p></p><p>Setting all that aside though, I think the reason the shares view is the default is because MyVideos is not devoted 100% to movie content. The database view is (at least currently) based on <em>movie</em> data pulled from sites like IMDb. But the MyVideos module is meant for more than just movie content. The shares view allows the user to browse <em>all</em> of their content regardless of whether it is a movie file and regardless of whether it has been (correctly) scanned with meta-data pulled from online.</p><p></p><p>So... given the current situation, even though the shares view may be slower, I think it does not make sense to start in the "Database" view unless MyVideos drops all support for non-movie related media. </p><p></p><p>But, all that being said, I still think this is the wrong dicussion to be having. We shouldn't be asking which view should we use, Shares or Database. We should be asking how can we combine both views in a way that makes sense and makes it easier for people to navigate their media.</p></blockquote><p></p>
[QUOTE="fforde, post: 341014, member: 52082"] Hrmm.. well to begin with the Shares view should not inherently be slower because it is the shares view. If it is slow that means there are problems with the implementation. Ultimately though both "Shares" view and "Database" view are just two ways to organize your video files based on meta-data about a file and it's contents. One should not necessarily be faster than another. If anything I'd expect the database view to be slower, since it is dealing with more information and more artwork. Setting all that aside though, I think the reason the shares view is the default is because MyVideos is not devoted 100% to movie content. The database view is (at least currently) based on [i]movie[/i] data pulled from sites like IMDb. But the MyVideos module is meant for more than just movie content. The shares view allows the user to browse [I]all[/I] of their content regardless of whether it is a movie file and regardless of whether it has been (correctly) scanned with meta-data pulled from online. So... given the current situation, even though the shares view may be slower, I think it does not make sense to start in the "Database" view unless MyVideos drops all support for non-movie related media. But, all that being said, I still think this is the wrong dicussion to be having. We shouldn't be asking which view should we use, Shares or Database. We should be asking how can we combine both views in a way that makes sense and makes it easier for people to navigate their media. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Development
Improvement Suggestions
Database Vs Shares UI
Contact us
RSS
Top
Bottom