Library sharing improvements?

Help improve MediaMonkey 5 by testing the latest pre-release builds, and reporting bugs and feature requests.

Moderator: Gurus

cncb
Posts: 59
Joined: Wed Sep 07, 2011 1:59 pm

Library sharing improvements?

Post by cncb »

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.
dtsig
Posts: 3588
Joined: Mon Jan 24, 2011 6:34 pm

Re: Library sharing improvements?

Post by dtsig »

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
MMuser2011
Posts: 1308
Joined: Mon Oct 17, 2011 8:28 am
Location: Central Europe

Re: Library sharing improvements?

Post by MMuser2011 »

I would like to see such improvements too.
Unfortunately, SQLite says:
If 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.
and
If 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.
Source: http://www.sqlite.org/whentouse.html
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
cncb
Posts: 59
Joined: Wed Sep 07, 2011 1:59 pm

Re: Library sharing improvements?

Post by cncb »

I guess this is a "not anytime soon" then?
MMuser2011
Posts: 1308
Joined: Mon Oct 17, 2011 8:28 am
Location: Central Europe

Re: Library sharing improvements?

Post by MMuser2011 »

cncb wrote:I guess this is a "not anytime soon" then?
I would say: No.

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
shuck
Posts: 7
Joined: Tue Mar 03, 2009 3:10 am

Re: Library sharing improvements?

Post by shuck »

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.
Peke
Posts: 17457
Joined: Tue Jun 10, 2003 7:21 pm
Location: Earth
Contact:

Re: Library sharing improvements?

Post by Peke »

Hi,
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
Image
Image
Image
How to attach PICTURE/SCREENSHOTS to forum posts
Macarena
Posts: 642
Joined: Mon Oct 15, 2007 5:39 am
Location: Prague, Czech republic

Re: Library sharing improvements?

Post by Macarena »

shuck 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.
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 much :)
skrutm
Posts: 23
Joined: Mon Apr 16, 2012 9:32 am

Re: Library sharing improvements?

Post by skrutm »

I'd like to have my meta-data in the cloud to be able to access it from all device that I use...
Post Reply