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
Moving Pictures
Stuck at "Retrieving possible matches".
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="RoChess" data-source="post: 925396" data-attributes="member: 18896"><p>The problem is not always "read" permission on the database, but an SQL-lock on the table/cell. These locks can also be placed when you are just "Reading" at SQLite level. But the lock prevents data from being written then if MovPic at that exact same time needs it as well. SQLite supports concurrency, but it needs to be coded in and MovPic is not specifically written for that scenario, hence multi-user setups are unsupported. The best way to go about it is to "copy" the database at Windows API level, because then you are truly 'just reading' the file and Windows API will still be able to process any write API requests from MovPic at the same time to the source.</p><p> </p><p>So just 'copy' movingpictures.db3 to say movingpictures.php.db3 and then do your PHP thing with that copy. I've got 4k+ entries and my movingpictures database is 35MB, a 'copy' action takes a split second and that is on a slow HDD. If you are setup with an SSD or have write-cache enabled it will take a few nanoseconds. To be sure that your 'copy' did not corrupt. Say for example nanosecond 1 you copy first half, then nanosecond 2 MovPic makes a change and nanosecond 3 you copy the last half, you end up with a corrupted copy. Simply run an SQL integrity command on the copy i.e.: pragma integrity_check;</p><p> </p><p>If result is "OK", then you are good to go.</p></blockquote><p></p>
[QUOTE="RoChess, post: 925396, member: 18896"] The problem is not always "read" permission on the database, but an SQL-lock on the table/cell. These locks can also be placed when you are just "Reading" at SQLite level. But the lock prevents data from being written then if MovPic at that exact same time needs it as well. SQLite supports concurrency, but it needs to be coded in and MovPic is not specifically written for that scenario, hence multi-user setups are unsupported. The best way to go about it is to "copy" the database at Windows API level, because then you are truly 'just reading' the file and Windows API will still be able to process any write API requests from MovPic at the same time to the source. So just 'copy' movingpictures.db3 to say movingpictures.php.db3 and then do your PHP thing with that copy. I've got 4k+ entries and my movingpictures database is 35MB, a 'copy' action takes a split second and that is on a slow HDD. If you are setup with an SSD or have write-cache enabled it will take a few nanoseconds. To be sure that your 'copy' did not corrupt. Say for example nanosecond 1 you copy first half, then nanosecond 2 MovPic makes a change and nanosecond 3 you copy the last half, you end up with a corrupted copy. Simply run an SQL integrity command on the copy i.e.: pragma integrity_check; If result is "OK", then you are good to go. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
MediaPortal 1 Plugins
Popular Plugins
Moving Pictures
Stuck at "Retrieving possible matches".
Contact us
RSS
Top
Bottom