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
VideoDatabaseV5 design issue
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="Anthony Vaughan" data-source="post: 1285314" data-attributes="member: 153283"><p>I believe that the design for VideoDatabaseV5 originated in the Kodi design for a similar database. Somewhere down the line the MP design departed from the original design and, I think, there is a problem with the MP design. I have been a user of MP1 since 1.11 and have had issues with this database on several occasions owing to this flaw.</p><p></p><p>Here is an entity diagram of the MP design:</p><p></p><p>[ATTACH=full]209021[/ATTACH]</p><p></p><p>Here is an entity diagram of what I think is the fix and is, in essence, the same as the Kodi design:</p><p></p><p>[ATTACH=full]209022[/ATTACH]</p><p></p><p></p><p>The MP design has movie linked to path and files linked to path and movie. But, because there is a movie record for every files record, idFile and idMovie in the files table should always have the same value. However, when the data becomes corrupted, these values start to differ and the database becomes unusable. As I say, this has happened to me often over the years and the only solution is to start with a fresh VideoDatabaseV5 file, losing everything. Furthermore, I can't understand why movie would come between path and files when strPath and strFilename are clearly meant to be linked.</p><p>I am suggesting that a change to the second design would eradicate this problem completely.</p><p>Under the MP design there is another problem. The vast majority of files are usually not movies, but a movie record has to be written for every files record, even when the files record is not a movie. Wouldn't is be better to only write movie records when the files record is a movie. I believe that the second design can handle that as well.</p><p>I recognize that this is not trivial and would require a significant change but I think it would result in a more stable, and more logical, system.</p><p></p><p>Tony</p></blockquote><p></p>
[QUOTE="Anthony Vaughan, post: 1285314, member: 153283"] I believe that the design for VideoDatabaseV5 originated in the Kodi design for a similar database. Somewhere down the line the MP design departed from the original design and, I think, there is a problem with the MP design. I have been a user of MP1 since 1.11 and have had issues with this database on several occasions owing to this flaw. Here is an entity diagram of the MP design: [ATTACH type="full"]209021[/ATTACH] Here is an entity diagram of what I think is the fix and is, in essence, the same as the Kodi design: [ATTACH type="full"]209022[/ATTACH] The MP design has movie linked to path and files linked to path and movie. But, because there is a movie record for every files record, idFile and idMovie in the files table should always have the same value. However, when the data becomes corrupted, these values start to differ and the database becomes unusable. As I say, this has happened to me often over the years and the only solution is to start with a fresh VideoDatabaseV5 file, losing everything. Furthermore, I can't understand why movie would come between path and files when strPath and strFilename are clearly meant to be linked. I am suggesting that a change to the second design would eradicate this problem completely. Under the MP design there is another problem. The vast majority of files are usually not movies, but a movie record has to be written for every files record, even when the files record is not a movie. Wouldn't is be better to only write movie records when the files record is a movie. I believe that the second design can handle that as well. I recognize that this is not trivial and would require a significant change but I think it would result in a more stable, and more logical, system. Tony [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Development
Improvement Suggestions
VideoDatabaseV5 design issue
Contact us
RSS
Top
Bottom