Network DB extremely slow

[James.P]

That's a good question... Here's where I'm at with this problem:

Following tech support's suggestion, I moved the MM.db from the NAS to a local PC on the network (at first, on my main workstation, later on the HTPC). This works flawlessly on either PCs and the HTPC is far from a powerful machine (Atom 330 1.6ghz, 2gb RAM, 5400rpm drive). The music files are on the NAS, as always. The problem occurs only when the DB file itself is on the NAS. Support's conclusion was that this obviously singled the NAS out as the culprit so that was the end of that... in reality, it's more complicated.

I uninstalled MM completely and rolled back to the latest MM3 build (before they moved to MM4). This works perfectly even with the DB on the NAS. Obviously MM3 is not a viable solution (I wish!) because Tag from Web is broken, but I wanted to test... so it seems the issue is the way MM4 queries the DB has changed since MM3, and that change is negatively impacting relationship with the NAS.

This is really puzzling and frustrating. My problem differs from yours a little bit in that when the DB is on the HTPC (with music files on the NAS) (as opposed to you with the DB on a server still causing problems), I can access the DB from my workstation without lag or any issues. So that's a relative workaround for me, though it requires that the HTPC be always on (which it pretty much is so that's fine). I would greatly like to understand what happened with MM4 so that it's now essentially unusable with the DB on a NAS though!

[rerickson]

Great to find this thread, as I have almost the identical setup/problem....

I have two machines (Win7 Ultimate on both, SSD system drives on both, 1st one is my main workstation, seconf one is an HTPC, and using Windows Home Server for all my media). I too have run MM3 for quite some time with great success sharing the MM.DB. In my case, I kept the MM.DB on my main workstation for two reasons -- one, just to keep it local to the machine instead of having to do SQL over the network, and two in order to take advantage of the solid state drive speed and maximize query performance. Again, the DB is NOT on the SAN/Svr. Now, as soon as I tried to go to MM4 on my main workstation, everything went to heck performance wise. All the same issues others have sited. I went to MM4 in hopes of finally getting back to iOS compativility (iOS5), but I cannot even use MM4 now it is so slow. Had to go back to MM3, but that doesn;t do me much good with 4 iOS 5 devices in the house for me, my wife, and the kids. Any thoughts?

Thanks in advance!

[James.P]

Just wanted to post that the problem isn't actually fixed, I'm still encountering terrible lag even though the DB is no longer on the NAS. It doesn't happen as often and might take longer to 'kick in' but it's still a fairly regular issue.
So as of now, MM is pretty much unusable using a shared DB over a network. This is definitely disappointing, after putting so much time and effort to organize my library in this software and buying a gold license, I now have to contemplate turning to something else. FFS, my setup is so simple even iTunes can handle it... very, very sad that MM is broken.

[Lowlander]

As usual debug logs (step 4b) are essential in these scenarios due to the many variables involved: viewtopic.php?f=7&t=69

Also note that File > Maintain Library with complete optimization and make sure the database file isn't fragmented on the HDD can make a huge difference in performance.

[James.P]

As usual debug logs (step 4b) are essential in these scenarios due to the many variables involved: viewtopic.php?f=7&t=69

Also note that File > Maintain Library with complete optimization and make sure the database file isn't fragmented on the HDD can make a huge difference in performance.

The problem with debug logs is, there's nothing in them. The program doesn't crash, it just becomes excruciatingly slow and unresponsive for 1-2 minutes, then works fine again. That is, until I try to expand a new node and it slows again. I tried logging it but nothing gets written in the log.

I did a complete optimization of my library when I first posted this (it's in the first suggestions) and that didn't change anything. How do I check if the DB file is fragmented on the HDD? Any guide on that?
In my case the DB is a drive that doesn't have a ton of stuff on it, just a clean Win7 x32 install and a few utilities (it's on the HTPC).

[Lowlander]

Then you're doing it wrong as no crash is needed. You need to install the debug version of MediaMonkey, you may need to run DBGView as Administrator and logs should be created immediately for everything you do in MediaMonkey.

I use defraggler which can show individual files and defragment individual files.

[James.P]

Then you're doing it wrong as no crash is needed. You need to install the debug version of MediaMonkey, you may need to run DBGView as Administrator and logs should be created immediately for everything you do in MediaMonkey.

I use defraggler which can show individual files and defragment individual files.

Thanks for the reply, both points are very helpful. I wasn't using the debug version of MM, so that might be what's wrong with my log-making endeavors. I'll give defraggler a spin and see about the fragmentation.

[Lowlander]

You will definitely need the debug version.

[Guest]

If I may contribute to this ...

I had been having problems with very slow updating of file tags on my NAS (see another thread), so I decided to try an experiment.

I uninstalled MM4, and did a clean install (with new MM.DB and ini files etc). I added 4500 files from a LaCIE 1TB USB drive directly added to my computer. It took 2 minutes and 33 seconds.

I again uninstalled MM4, and did another clean install (with new MM.DB and ini files etc). I added the SAME 4500 files, this time from a LaCIE 2TB NAS (wired via 100mbps router, not wireless). So far, it has taken about 10 minutes, and it is on 610. It is on target to take an hour to import the same files that were imported from the USB drive in less than 3 minutes ...

Clearly there is something very odd going on with access to the NAS. It is not rocket fast in normal performance, but this is silly ...

Brian

[jflower]

I was glad to find this thread although it's very concerning. I also use MM on a laptop with all music stored on a server (hp mediasmart). It's always been slow, but it sounds like version 4 will likely be worse. I just installed version 4 on my new laptop. My problem is that the 20,000 tracks or so are not importing from the server - only 3,000 and then it says that the rest don't meet the criteria. I don't know what's happening with that. I am very intrigued at the possibility that storing a database locally could possibly help somewhat. If anyone can give directions for how to try that, I'd be grateful.

[Nova5]

at nearly 11K tracks I don't yet see this problem, though i am hosting the DB on a WHS2011 system. 2 fulltime running clients (one on the server for DLNA devices, one on my HTPC for piping music into my backyard via the wireless speakers I have. Laptop connects at random. usually add music from it to the DB and music store location, also on the server. It is possible your NAS's and such may have file access limitations causing you these delays, MM3 may run more things through one connection than MM4 does. Not really sure how it all works in MM itself so this is just a USWAG. Things might work better if they convert it to a fully realized SQL Database and use MS SQL Express to host the DB. Client systems can then talk directly to real SQL server under far more robust and powerful conditions.

http://www.microsoft.com/sqlserver/en/u ... press.aspx
Best is SQL Express is free!

[James.P]

So here's an update on the situation... I've been trying some stuff and various workarounds. Also, I tried defragmenting the DB file using defraggler, that didn't change anything.

I decided to try something a bit unorthodox: I did a portable MM installation directly on my NAS (in a MediaMonkey folder), so the .ini and DB files are now hosted in the same folder, all on the NAS. Music files are of course still on the same NAS.
So instead of running a local instance of MM that's trying to access a networked DB, I run a networked instance of MM accessing something akin to a local DB (in the sense that the DB is in the same local folder).
Surprise (or not!), this works like a charm! I do get some bottleneck issues that are probably related to my relatively low-quality NAS combined with a green drive (5400ish rpm) but these are 'normal' length and predictable, ie: when moving a bunch of .flac files + editing data on a bunch of tracks + playing some other files all at the same time. And they don't result in MM freezing for 5 minutes.

This, to me, completely validates the fact that neither the NAS or the network are to blame for these performance issues, but rather isolates MM as the source of the problem. I know less than nothing about SQL so I couldn't begin to say what might be the cause but now I'm pretty much convinced that something was changed in MM4 that screwed up how it handles network queries, that used to work fine in MM3.

So for anyone else having this issue, a portable MM install on the NAS is a workaround that doesn't involve a ton of user sacrifice, at least for me. I'm kinda looking around for a machine to build my first server on so eventually I'll just switch over to a DLNA setup (with an always-on server) but for now that'll have to do.

[Lowlander]

That makes little sense anyway you look at it. The only reasonable explanation would seem that the drive where MM was installed locally has speed issues. One would expect that moving all to NAS would be slower as more has to be read/written to the NAS which has a slower network connection (than internal HDD connection) and furthermore has a slow drive. Alternatively your local install has been an upgraded (several times) install and/or has addons the portable network install doesn't that slow things down. Another alternative would be how Windows manages running an application of a local drive vs. a network drive (maybe more caching in memory thus faster speeds).

One thing that may be of use here is to create a test sequence (a sequence of operation in MM) execute them for both a local install and a network install and log both in separate debug logs. The differences between the logs may give the developers clues as to where the problem may lie.

[Panander]

Just like to add that I too suffer this same problem and have done since I updated the v4 shortly after its release. Never did solve it despite using debug MM etc . I put up with it which saddens me as the problem seems to be just ignored by the MM developers of whom I have the highest regard. Would love to see it solved. I use many programs that access my NAS unit - only MM4 falls over. MM3 was lightning fast.

You are not alone.

[boomshanker]

I am very relieved to have found this topic. I thought I was losing my mind.

I too have a D-Link DNS-323 NAS where I store the MM.db file and all my music. My network is Gigabit. I have three WinXP machines of various configurations that access the db, although NEVER at the same time. MM3 worked flawlessly in this setup. MM4 does not. Nothing in my setup, network, or machines had changed when I did the first upgrade from MM3 to MM4, and nothing in my setup, network, or machines have changed since I upgraded to MM4.0.5.1496 the day before yesterday.

Moving the MM.db locally to my crappiest machine resolves the issues and gives me the performance that I used to get when that same db was stored on my NAS.

Moving the db file to the NAS gives me the same issues that everyone else in this thread has experienced: performance renders MM4 unusable.

As the author of this thread has painstakingly illustrated, this is an issue that was introduced in MM4. There is no debate required on this fact.

So, after being a Gold lifetime licensee for the past four years, I too am faced with either having to rollback to MM3 and lose those bug fixes (web update, duplicate playlist track dialog under my taskbar, etc) or move to other SW. This saddens me that so many people are experiencing the same, identical problem yet development is still not taking this issue seriously.

Please take this seriously and help to resolve this issue. I love MM but am frustrated by the lack of resolution.