Then a shared database is the only method, as Media Sharing only allows to stream, no editing/Playlist creation on server.

Thanks @Lowlander. It is mostly for the shared Playlists. We both have iPhones and iPads, as well as several iPod and other-branded MP3 players that we sync with MM. We have 100+ existing playlists, and I'm on a mission to familiarize my partner with the playlist creation process so she can create her own - the new MM makes that process easier. But, yes we share and enjoy the common playlists, including new ones we create.

Why do you need a shared database?
- You can each have your own database of the same files. [url=https://www.mediamonkey.com/wiki/WebHelp:Adding_Existing_Files_to_the_Library#Using_Folder_Monitoring_to_Automatically_Update_the_Library]Folder Monitoring[/url] would update the other instances automatically.
- You'd miss shared Playlists and Play Counts.

You could also have non-editing instances access via [url=https://www.mediamonkey.com/wiki/WebHelp:Setting_UPnP_DLNA_Media_Servers]Media Sharing[/url]. This would share Playlists and Play Counts.

SQLite is not designed for simultaneous access, but this is generally expected to work. Backups will be a good recommendation.

Has anyone experimented further with a shared database in MM 2024 (v5) in the five years since this thread started?

I recently spun up an Unraid NAS, and wanted to locate my MediaMonkey 2024 database and files on that NAS. I followed the directions at https://www.mediamonkey.com/support/knowledge-base/mediamonkey-install-config/mediamonkey-in-a-shared-networked-environment/ so I could share the database with several clients on my home network (huge Spouse Approval Factor). One is my main computer where I do any significant modifying / adding / deleting. The other is a family member computer who only uses MM to listen, and does create Playlists. I installed MM on a couple of other computers during testing.

Previously we ran VNC from client machines to a Windows computer instance which acted as an always-on home "server", but in the transition to Unraid which is Linux-based that is no longer an option.

All the instances work fine with the shared database and files on the NAS. Each instance was installed as permanent (non-portable). The ini files live on the client machines, and each was edited as per the referenced directions.

I've asked my partner to check before running her instance, and I ensure she's not running before I start mine. I do weekly database backups at minimum, and more if making changes.

I've read the posts about SQLite as the back end database, and understand that it isn’t designed as a multi-user/networked database. I'm just wondering if any of you have practical experience, good or bad, with multiple users running a shared database instance at the same time.

Yes, in the MMS design the multiple connections are from remote clients to the MMS [b]server application[/b].
This was also one of the main reasons to develop MMS -- as accessing shared sqlite database file in a network environment is potentionaly dangerous and has performance issues/limitations (as you have already stated above and as already users trying this have experienced, e.g. https://www.mediamonkey.com/forum/viewtopic.php?f=1&t=39401 )

As for the Linux client: You can run internet browser and put [MMS_ip_address]:10222 into address bar of the browser to access web UI of MMS where you can browse your collection and play the files.

I decided to do a bit of research. I use SQLite in a lot of products but never myself incorporated it into an application, so way too much time later...

There are all sorts of warnings against using SQLite on file shares. Apparently the issues involved are pretty OS specific, but this warning seems to summarize it (source [url]https://www.sqlite.org/lockingv3.html[/url]):

[quote]SQLite uses POSIX advisory locks to implement locking on Unix. On Windows it uses the LockFile(), LockFileEx(), and UnlockFile() system calls. SQLite assumes that these system calls all work as advertised. If that is not the case, then database corruption can result. One should note that POSIX advisory locking is known to be buggy or even unimplemented on many NFS implementations (including recent versions of Mac OS X) and that there are reports of locking problems for network filesystems under Windows. Your best defense is to not use SQLite for files on a network filesystem.
[/quote]

This actually gives me pause whether multi-threaded access from MM5 with my database on a file share might actually be a bad idea.

There are lengthy discussions there for how write ahead logging works, and implications. Also, that site has data from MANY years ago, so some things may have changed and not been updated (though the reference page is specific to version 3 locking which is current now).

I bring this up partly in case others see this topic, but also because I also saw a note about MMS:

[quote]MMS uses SQLite. There isn't any limit on # of connections, only what your HW allows. And yes, the DB is supposed to by modified concurrently by multiple connections.[/quote]

(From [url]http://www.mediamonkey.com/forum/viewtopic.php?f=31&t=90816[/url]) and it is unclear whether in the MMS design the multiple connections are from remote clients to a server application, or remote clients to the database itself. I hope the former? And it won't do remote connections as file shares?

Well, yes and no (one reading, one writing). I'm not sure how much goes in the database verses the ini or persistent.json file (also concerns for simultaneous access) but MM5 is updating stuff all the time. I had not really thought about the text files until just now, they seem even more likely to have collisions during updates, say one trying to read a file half rewritten (to do an update I assume the file is copied and written back for these).

Or do you keep such locked to synchronize access?

In this case I'm running both as portable from the same folder (one physical, one a network share).

The more I think about this the more I better not run both at once.

Can you get the MMS server ready for production soon? Say by end of day? And a linux client while you are at it? :D

I guess it should be safe unless both the instances want to write at the same time.
i.e. the purpose of your use case should be rather just reading (and use just one instance for writing/editing).
Plus backup your database of course. Otherwise yes, MMS is designed for accessing by multiple client instances.

I set up the portable version on a network share, so I can alternately run it on my desktop, and leave it running as a server on a server.

I have not tried running both at once, for fear bad things happen.

Is it safe to do so? With MM5 (not MMS) can two instances on different systems safely access the same library (etc) at the same time?

I assume once the MMS gets going this question becomes more moot, but my impression was that was less ready for use than MM5, right?

Thanks, Linwood