Just to say that the last 4 builds solved the issue for me. BTW I had reverted back to 32 bit due to drivers fr another device, and had the same problem, so it had nothing to do with 64 bit windows 7. Works like a dream now though!

Ok, replied over e-mail.

Jiri

Only the monitoring hangs, the rest of MM works (although sluggishly). I upgraded to the latest build, 1152, and still had the problem. Thinking this may be a problem with reading certain m3u playlists, I temporarily moved all of my existing *.m3u playlists out of the folders being monitored, then restarted MM. That fixed the issue.

I then exited MM, moved my M3U files back into the folders being monitored, and restarted MM which started the startup file monitoring. Voila, it hangs again (this time on a different M3U playlist). I also note that "Now Playing: Reading Tracks" was taking a VERY long time, but did eventually complete after a few minutes.

These M3U files, BTW, were created by WMP 11 - I had converted and saved my WPL WMP playlists as M3U. I can send you the M3U files if you want to have a look or try it.

I don't have the debug version of 1152 installed, let me know if you need me to do this and send you the log. Feel free to email me directly.

MM fully hangs, or just the scanning thread freezes and MM continues to work? You can e-mail me a debug log of this, just to be sure what's going on...

Jiri

I am experiencing this same problem, with build 1251. I had upgraded to 3.1.0.1251 from the official 3.0.7.1191 release in an attempt to address the podcast/wininet #126 problem.

I'm on Windows Vista Business SP2, with IE8. I too have a shared network database (my MM.DB is on a network share and two computers access it), and my library has over 10000 items.

At startup, MM hangs while monitoring, freezing at "Monitoring at 684 of 723 (\\[Network Path]\2005 04.m3u)", which is a playlist. Subsequent reloads always hang at this same spot.

"Terminating" the hung monitoring results in multiple error message dialog boxes showing "Access violation at address 007DAA04 in module 'MediaMokey.exe'. Read of address 00000008". Had to kill the app using task manager.

Hi,

Is this issue affecting anyone?

If yes, does it occur in earlier 3.1 builds?

(the debug log that had been sent didn't give us much useful info).

-Rusty

[log at: http://www.mediamonkey.com/support/staf ... ketid=4357 ]

The screen "greys out" and won't respond. I sent in a windows debug log to the support site, as no mediamonkey crash report is offered

How exactly does it crash? Does MM give you a change to send a crash report (i.e. pop-up a special window for this purpose)?

Jiri

Great -- sent the log in, thanks.

bilzebub wrote:Where would I find the debug log to send you?

See here: http://www.mediamonkey.com/forum/viewto ... ?f=6&t=341

Hi, i hadn't been using file monitor after the last advice. Moved up to .1228 and since you asked, went back to file monitor, and it still crashes after monitoring the first 500-1000 files. Where would I find the debug log to send you?

Cheers

bill

bilzebub,

So do you mean to say that if you add/rescan a specific directory (with 23k tracks), it works, but if you do the same using the file monitor, MM crashes?

If so, can you please send me a debug log illustrating the crash?

Thx.

-Rusty

I am on 1228, but have gone as per suggestion to using add/rescan only. Apparently monitoring 23000 files is an issue

Hi,

Any news on this issue? Is it resolved? Is anyone experiencing the problem in 1228?

Thx.

-Rusty

I'm thinking that maybe the drive your scanning is turned off (standby) when you start scanning and this causes the problems?

My theory seems to be supported by the fact that if you select the drive (a folder on it) in Add/Rescan Tracks that (even though the selection hangs) the scan works as the drive has been started up again.

Try the following, using Windows Explorer go to the drive look at a folder on it and then directly start MediaMonkey with the File Monitor enabled and see if it hangs or not.