MediaMonkey forum

Greetings all,

I'm posting to see if anyone else has this issue with MM not shutting down and not responding to Task Manager->end process all that speedily (up to 20 minutes, sometimes reboot required)

OS is Windows 7 64 bit Home Premium.
MediaMonkey 4.0.6.1501 (soon to be debug version)
Can't give other stats as system is restarting and will be back online in .... 30 min or so due to how munged up it is.

I've taken a whack at resolving all of the UAC issues - both admin, and standard users have full control of the C:\Program Files(x86) folder, standard user is set so that the application runs as administrator all the time.

Library of music resides on a network share (via CENTOS 6/SAMBA share)
Have tried to use networked copy of MM.DB, and also allowed app to create local copy as part of testing.

Sometimes, after a bad exit, MM comes up and states it's reading files, but never seems to load anything.

I'm going through a clean boot now after installing the debug version for 4.0.6.1501, and have pulled in DgbView and will attempt to replicate for support, but before I open a ticket, I thought I'd post this query since I didn't see anyone having quite the same issue.

Like most, I love MM, and my teenagers are in withdrawal for the past 3 week since I've had to recover from the actions of a guest who's actions lead to a complete reload of the computer from scratch (which is why the library of music is on a Linux host no one else has admin rights to! )

At this point, Windows logs have only given me a couple of MM stopped responding messages, but nothing else is logged hence the load of the debug version.

-Suzukiginsu

suzukiginsu wrote:30 min or so due to how munged up it is.

Sounds like a lot is wrong with your system and this may cause instabilities with programs like MediaMonkey.

I would recommend not putting the database on a shared drive, there are various performance and file locking problems that can occur that will likely corrupted the db beyond salvage (always have a recent backup copy).

Lowlander,

This is a rebuilt OS install - I formatted the drives etc. All external devices that were plugged into the system when my guest (10 yr. old nephew with a penchant for online web games) did his magic, or one of those sites did it's magic. I've loaded the bare minimum of what's needed at this time - MS Office, Avast! Antivirus, Adobe bits and bobs, and of course Firefox. There isn't a whole lot of stuff to really lead to driver issues etc. I had a lot more stuff loaded on this system before the events that lead to the reload, and no issues, but I was running a 3.x version of MediaMonkey at that time. At any rate, I'm going to run through the debug steps because it doesn't matter if I'm Local Admin or a standard user.

I'm dealing with a Quad Core, 2.33 GHz system, with 8 GB of RAM, two 1TB SATA drives in a RAID1 config.

To address Technojnky's comment - I understand the comments re locked files etc. (I'm a UN*X admin by training, with a strong background in SAN/NAS types of storage) The reason for the shared location is so that all of the systems in the house access the one DB, and consequently, one set of playlists. As part of my testing for this, however, as you've suggested, I had removed the MediaMonkey.ini file that was setup to use the UNC paths to the network share, and the problem persists, so I think, other than the music's on the network, I'm good from a file open/close/read/write performance perspective.

I'm no fan of Windows, as I find troubleshooting with it to be more arcane art than science compared to the many flavours of UN*X I've worked with. If there was a version of MediaMonkey that was LINUX based, I'd be building a custom system for just that purpose - some of the low power micro and pico ATX systems really appeal to the builder in me.

Thank you both for your comments, I suspect I've got a new issue of some sort, so I'll try to get the dedicated time to run the debugging session and get the data off to support to review - this system is currently in heavy demand as the school year has started up.

-Suzukiginsu

well, sqlite itself is not really well suited for multiple/shared access. And since you already seem to be aware of the file locking problems, I would make sure you have daily/weekly backups incase multiple people do something that tries to update the db at the same time.

Yup. That's why it sits on a Linux box, scripting, and backup are much easier for me there.

That, and well intentioned family cannot make adjustments "for the better".

<laughs maniaclly>