1&2 are being pushed beyond 4.0.

-Rusty

Hello Rusty

I can't reproduce the point 1 from my hard disk, because MM tag very faster than before, but if the song are in a usb drive, and I move before the tag process is terminated, i got the error.

I got the error too, if I try to move songs currently converted, from flac to mp3 for example.

My current version is 1436

Thanks. Issue 3 will be properly fixed--it should resume playback at the next available track.

Issue 1&2 won't be resolved in MM4.0.

-Rusty

Hello.

I see that you solve the point 3 (I don't test the 1 & 2) in the 1431. But the playback stop after the deletion, even some tracks stay on the playlist. Can you not continue the playback to the next song on the playlist?

Serge

Thanks!!

Tools > Options > Playback Rules and change 'Play Now' Action to one of the Selected only options and repeat for all Types. This also had to be done in MediaMonkey 3.

nohitter151 wrote:

Kobsa wrote:A bug: once you clear the "Now Playing" playlist, and then play a song, the now playing list is filled with the entire library again, although the otion of auto DJ is unchecheked and "autmatically retain []" is set to None

That's not a bug, it's due to your double-click action.

Didn't get it - How do you switch to a different song w/o double clicking on another song? How can avoid filling the Now playing playlist as a result?

Congratulation for the 1430.

Around 20 kill process last week-end and 0 today.

Better than the 3.2.4

Kobsa wrote:A bug: once you clear the "Now Playing" playlist, and then play a song, the now playing list is filled with the entire library again, although the otion of auto DJ is unchecheked and "autmatically retain []" is set to None

That's not a bug, it's due to your double-click action.

A bug: once you clear the "Now Playing" playlist, and then play a song, the now playing list is filled with the entire library again, although the otion of auto DJ is unchecheked and "autmatically retain []" is set to None

This is very pleasing to hear.

THX for feedback.

Hello

I try to reproduce the problem with the last build (1430) and I never have a freeze with a filtered collection. The time can be little bit long when I expand some node the first time, but the cache work very good for the next times and the expand is immediate.

I think that from the build 1428, you resolve some big problems already present on the 3.x versions, because I never have a reactive media monkey like this.

Serge

Thanks.

1&2 tracked at: http://www.ventismedia.com/mantis/view.php?id=8356
3 tracked at: http://www.ventismedia.com/mantis/view.php?id=8357

Re. the tree never expanding, can you please PM me a copy of your DB (using mediafire.com or similar service), and tell me exactly which nodes are problematic?

Thanks.

-Rusty

3) Tools > Options > Confirmations and disable Confirm deletion of currently playing file.

Hello.

I see that some errors persists on MM4

1) When MM4 Tag some files and I move the same files with MM (Ctrl+R), I get an error on each files that indicate an error while moving the currently tagged file. But MM know what he doing? He can't wait that the tag operation is finished before moving the file?

2) The same for the deletion. If I delete an album, why MM continue to tag the files of this album and give me an error on each files?

3) Idem when i delete an album, and this album is currently playing. For each files I get a confirmation message because the file is playing. Can you not stop to ask the confirmation after the first file or add a yes for all button?

4) The tree expand never finish. I have a big collection of music. When I expand the albumartist node of the music collection with all files, no problems, that take less than 10 seconds. I have another collection with a filter on the path that contains only some files included on the music collection, and when I expand the albumartist node of the filtered collection, the operation never finish and I have to kill MM with the task manager. And it is always the same if the collection is empty!

Thanks for answer.

Serge