Library sharing improvements?
Moderator: Gurus
Library sharing improvements?
Any plans to improve library sharing between multiple PCs? I had instances in MM4 of database corruption when trying to share the library by accessing it from a network drive with multiple PCs.
Re: Library sharing improvements?
Sqlite is not multiuser and so trying to do that will cause corruption as you have seen. 5 still uses Sqlite so the restriction is still there.
Where's the db and ini stored
Reporting Bugs
Where tags are stored
Not affiliated with MediaMonkey ... just a RABID user/lover
DTSig
Reporting Bugs
Where tags are stored
Not affiliated with MediaMonkey ... just a RABID user/lover
DTSig
-
- Posts: 1308
- Joined: Mon Oct 17, 2011 8:28 am
- Location: Central Europe
Re: Library sharing improvements?
I would like to see such improvements too.
Unfortunately, SQLite says:
Unfortunately, SQLite says:
andIf many threads and/or processes need to write the database at the same instant (and they cannot queue up and take turns) then it is best to select a database engine that supports that capability, which always means a client/server database engine.
SQLite only supports one writer at a time per database file. But in most cases, a write transaction only takes milliseconds and so multiple writers can simply take turns. SQLite will handle more write concurrency that many people suspect. Nevertheless, client/server database systems, because they have a long-running server process at hand to coordinate access, can usually handle far more write concurrency than SQLite ever will.
Source: http://www.sqlite.org/whentouse.htmlIf there are many client programs sending SQL to the same database over a network, then use a client/server database engine instead of SQLite. SQLite will work over a network filesystem, but because of the latency associated with most network filesystems, performance will not be great. Also, file locking logic is buggy in many network filesystem implementations (on both Unix and Windows). If file locking does not work correctly, two or more clients might try to modify the same part of the same database at the same time, resulting in corruption. Because this problem results from bugs in the underlying filesystem implementation, there is nothing SQLite can do to prevent it.
● Magic Nodes v4.3.3 (2018-10-03) last free version ● SQL Viewer v2.4 (2009-10-25)
● ExternalTools v1.4 (2011-05-09) ● iTunesMonkey 1.0 + Acoustid
● Calculate Cover Size v1.7 (2012-10-23) ● RegExp Find & Replace v4.4.9 (2018-10-03) last free version
● ExternalTools v1.4 (2011-05-09) ● iTunesMonkey 1.0 + Acoustid
● Calculate Cover Size v1.7 (2012-10-23) ● RegExp Find & Replace v4.4.9 (2018-10-03) last free version
Re: Library sharing improvements?
I guess this is a "not anytime soon" then?
-
- Posts: 1308
- Joined: Mon Oct 17, 2011 8:28 am
- Location: Central Europe
Re: Library sharing improvements?
I would say: No.cncb wrote:I guess this is a "not anytime soon" then?
But you can try to copy your entire (master-) database to different network drives or -directories or different computers. It's not really sharing anymore, but at least you can read your data at the same time from different machines.
As soon as you write informations back to the database, this is obviously impracticable.
● Magic Nodes v4.3.3 (2018-10-03) last free version ● SQL Viewer v2.4 (2009-10-25)
● ExternalTools v1.4 (2011-05-09) ● iTunesMonkey 1.0 + Acoustid
● Calculate Cover Size v1.7 (2012-10-23) ● RegExp Find & Replace v4.4.9 (2018-10-03) last free version
● ExternalTools v1.4 (2011-05-09) ● iTunesMonkey 1.0 + Acoustid
● Calculate Cover Size v1.7 (2012-10-23) ● RegExp Find & Replace v4.4.9 (2018-10-03) last free version
Re: Library sharing improvements?
To me, this is one of the most requested and ignored features by the developers. It would probably take just a few days of development to create a server app and plugin that could do this. Like SQLite says, a server-side app can queue up database reads and writes. It would handle the actual database modifications. Heck, just create a server-install mode of the mediamonkey client that is simply a database middleman. Then put a small module in the client that allows you to point the database handler to the server instead of a local file.
Even something as simple as a built-in "sync to network location" that periodically synced them up would make most users happy. We are all tired of having to manage multiple 10000+ track databases or deal with the errors and risks associated with sharing them. Simple network database manipulation has been a staple of computer operations since the 1970's.
Even something as simple as a built-in "sync to network location" that periodically synced them up would make most users happy. We are all tired of having to manage multiple 10000+ track databases or deal with the errors and risks associated with sharing them. Simple network database manipulation has been a staple of computer operations since the 1970's.
Re: Library sharing improvements?
Hi,
We are actually thinking about the same, but I can't say more.
We are actually thinking about the same, but I can't say more.
Best regards,
Peke
MediaMonkey Team lead QA/Tech Support guru
Admin of Free MediaMonkey addon Site HappyMonkeying
How to attach PICTURE/SCREENSHOTS to forum posts
Peke
MediaMonkey Team lead QA/Tech Support guru
Admin of Free MediaMonkey addon Site HappyMonkeying
How to attach PICTURE/SCREENSHOTS to forum posts
Re: Library sharing improvements?
Tried that, been there, learned not to share the database the hard way. I hope for the best with Peke's words. In any case, I'm looking forward to MM5 very muchshuck wrote:To me, this is one of the most requested and ignored features by the developers. (snip)..(snip) We are all tired of having to manage multiple 10000+ track databases or deal with the errors and risks associated with sharing them.
Re: Library sharing improvements?
I'd like to have my meta-data in the cloud to be able to access it from all device that I use...