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