That's absolutely true. SQLite simply hasn't been designed with shared remote access in mind. Furthermore even other DB's might suffer from transaction deadlocks. Therefore a shared DB setup won't work if more than once instance of MP is accessing it at the same time.
Database sharing (1 Viewer)
- Thread starter Memphys
- Start date
That's absolutely true. SQLite simply hasn't been designed with shared remote access in mind. Furthermore even other DB's might suffer from transaction deadlocks. Therefore a shared DB setup won't work if more than once instance of MP is accessing it at the same time.
I'm pretty sure this causes the "slow shares view in clients" -problem too. But I think it can be improved.
Now it seems that if only MP is running in the server AND has accessed a shared database, ie videodatabase once (maybe even have to start a movie once), THEN, even if MP is unused, idle, but still running, it causes lockups for the clients. ONLY way I found to get out of theese lockups is to shutdown MP in both server and client AND THEN restart MP in the client. Now there is quick access to the database from the client.
I really don't understand why I have to restart Client MP. It should be enough to shut down Server MP to release the database???
Soo... If an idle MP could let go of the database... wouldn't that maybe solve something?
We need a user-selectable read-only mode for MPTVSeries. Then this problem would be solved.
Check this out: if I have four instances of MPTVSeries running in the house, and all of them share a common database, it's only necessary for one of those instances to actually update the database with series and episode info. Right? The others would just slave off of that. They really have no business downloading stuff redundantly anyway.
I understand that I would lose the ability to gray out episodes I've watched. I can accept that. If we really honestly needed that though, it could be stored in a secondary local database.
Check this out: if I have four instances of MPTVSeries running in the house, and all of them share a common database, it's only necessary for one of those instances to actually update the database with series and episode info. Right? The others would just slave off of that. They really have no business downloading stuff redundantly anyway.
I understand that I would lose the ability to gray out episodes I've watched. I can accept that. If we really honestly needed that though, it could be stored in a secondary local database.
- May 20, 2007
- 13
- 0
- Home Country
-
Netherlands
I don't know if you're still interested in a solution, but I think I have one. I was having the same problems with my central database, delay write failures and a corrupted database after a time.
I've made two changes to my setup, I don't know which one was the actual solution or maybe the combination of the two was the trick.
First thing I did was to check if the server used the same MTU size as the client. Well, it didn't so I changed the MTU on the client:
System Key: [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\[Adapter ID]]
Value Name: MTU
Data Type: REG_DWORD (DWORD Value)
Value Data: Default = 0xffffffff
Create a new DWORD value, or modify the existing value, called "MTU" and set it to equal the required MTU size in decimal.
The second thing I did, and then the problem finally went away, was to disable opportunistic locking on the client:
http://support.microsoft.com/kb/296264:
The location of the client registry entry for opportunistic locking has changed from the location in Microsoft Windows NT. In later versions of Windows, you can disable opportunistic locking by setting the following registry entry to 1:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MRXSmb\Parameters\
OplocksDisabled REG_DWORD 0 or 1
Default: 0 (not disabled)