UPnP/DLNA is a way to share your Library. This is a standard many manufacturers/softwares use to share music. Two key components are the Server and the Client. MediaMonkey can be the server and client. All you do is share the master Library through UPnP and the other clients will access it through UPnP (available in the Media Server node). This means all playlists of the master library are available to clients and any plays from the clients will be registered in the master library.
There are drawbacks as you can't edit tracks in the clients (nothing can be saved back to master library through UPnP) and not all fields that MediaMonkey supports are available through UPnP.

As SQLite is inherently few user friendly you might want to add support to the ability to use alternative database engines in MediaMonkey like SQL Server or MySQL which are much more robust. The added advantage is that some NAS's support MySQL database's natively and that even SQL Server offers a free variant. For developers it might also be a boon as it might be easier to integrate into other projects.

Jiri,
thanks for the honest reply. I understand that you have to make choices although we are really not happy with this one.

File monitor is not an option I think; we do keep all metadata in the tracks but with file monitor we cannot share playlists and playcount.
I cannot find information about the UPnP option. Could you tell me where to look?

Regards, Willy

To be honest, I wouldn't expect any significant improvement in this scenario anytime soon. The thing is that although SQLite can work quite well for very _few_ users, we have MM operations tuned to be as fast as possible for one user. Although we support >1 user per DB, it's preferable to have 1 DB per user and only share files, possibly keep in sync using File Monitor or e.g. newly in MM 4.0 UPnP.

Jiri

Rusty,
I've cleaned up the library, and several issues are gone now. Testing is difficult if several things are wrong at the same time but I suppose I don't have to tell you that...

The slowness is still there sometimes, but it is this issues again (still): http://www.mediamonkey.com/forum/viewto ... =7&t=59254
To summarize: MM slows down if MM on another PC accesses the same MM DB. This even continues after the second PC has stopped. This is not due to limitations in SQLite, because SQLiteSpy does not show this behaviour.

It just happened that my husband looked up something in MM while I was doing the testing.... and that makes my MM slow until I restart it.

This means that the originally reported issue in this thread is solved, as far as I can see.
I would really appreciate it if this multi-user issue could also be solved (or improved). It is THE issue in MM that takes away a lot of the fun for two music lovers here.
Is there any hope? Is it of any use to report that issue in the Beta forum?

Regards, Willy

Willy,

Can you see if this is replicable in your environment with a clean library (i.e. after you do a fresh scan of your system) since there are some anomalies in your library (the mismatched album artists) that may be triggering this.

Thanks.

-Rusty

It is not solved. MM doesn't say reading files anymore, but the simple masks is still very, very slow at times. restarting MM does not always solve the problem.

Regards, Willy

First impression of 1442 is very positive, it seems to have solved this issue.
Thanks!
Regards, Willy

Rusty,
yes, indeed this happens, exactly! It happens also if I run a MN query that does not give any results.

Note that the "reading files"does not run literally indefinitely, it just takes quit a long time but does come to a correct end.
And the UI is not fully functional, the upper browsers cannot be accessed.
Maybe this helps to find the cause of the problem, in case that is not yet clear.

This slowness disappears after a full clean up of the library, then MN is fast as ever. In our case, a simple restart does not always have this effect.
Or we have a second problem...

Regards, Willy

Willyvds,

I think I was able to reproduce the problem you're experiencing, though the problem wasn't that bad because although mm showed 'Reading files...' indefinitely, the query appeared to complete, and the UI was functional.

See details at:
http://www.ventismedia.com/mantis/view.php?id=8481

If you're experiencing this differently, please share a Jing video and debug log to go with the video.

Thanks.

-Rusty

Yes, that's what I meant. The ones that modify the database (like the ones that tag) might be the cause behind this spoiling. I wouldn't know if a specific addon is to blame, or that MediaMonkey poorly handles addons that update the database.

We have a bunch of add ons (Magic Nodes, Lyricator, Tagging inconsistencies etc). Is that what you mean?
Is this a known problem of one of them? Can we do anything to reduce the problem?
Regards, Willy

What scripts are involved in your install? Especially tagging and auto-tagging scripts? They might be involved in database spoiling.

Willy,

normally there really shouldn't be any need for frequent cleaning or maintaining library. In MM4 it actually shouldn't be needed at all, since we do some basic analysis after each scan of significant amount of tracks. There definitely shouldn't be any change after just using the library. It looks like there's something going wrong on your machine. We could start by generating a debug log and sending it to me.

Thanks,
Jiri

First: sorry for posting in a new thread, I thought that's how it should be done.

Anyway, it still strikes me that our library gets easily "spoiled". I have to do a full clean up every one or two weeks in order to keep performance decent.

More precisely: sometimes MM becomes really very, very slow. Particularly Magic Nodes and similar add ons. It is my experience that this improves greatly if I do a full clean up of the library. Note that the DB is not corrupt, and the content is okay. I find it just a bit annoying to have to do this clean up every other week or so.

So some questions:
- Is there a rule of thumb how often the library has to be cleaned? Is it normal that we have to do this so often?
- What could be the explanation for this? Could we do anything to prevent the spoiling?

Regards, Willy

Rusty,

I happened to check the test mask an hour ago, then it took less than 1 second. Since then, I've played a couple of songs and added 1 album art. Now the mask takes 30 seconds!
After these 30 seconds, MM keeps on "reading files", for more than 10 minutes. In the meantime, I cannot click on the items in the upper 3 browsers.

A full library clean up solves this issue, but I've done that just a few days ago. It shouldn't be necessary to do that so often.

I will send you the link via PM.

Regards, Willy