View Issue Details

IDProjectCategoryView StatusLast Update
0005906MediaMonkey (current)Burning / Disc Handlingpublic2010-10-07 21:33
Status closedResolutionfixed 
Product Version 
Target Version4.0Fixed in Version4.0 
Summary0005906: Ripping CD: Possible ripping slow-down after finishing of the first track
DescriptionRipping CD:
Way to reproduce:
1. New MM library.
2. Insert CD
3. Add CD to Library
4. Select All tracks From CD
5. Start Playback
6. Start RIP and RIP-ing will not start (this is working on MM
7. Stop Playback and CD RIP Will start at 40x
8. After first track Rip Will slowdown to 16x and whole CD will be ripped on 16x
Additional InformationTicket:
TagsNo tags attached.
Fixed in build1301


duplicate of 0005900 closedLudek CD ripping doesn't work when a track from the CD is paused in Now Playing 
related to 0005839 closedLudek Drive initialization takes 30 seconds or forever on some systems 
related to 0004910 closedLudek HPCDE Primo: new version 2.5.8 engine should be included 
related to 0005899 closedpeke AudioCD: Playback, Virtual CD, Sync Functionality Broken in 3.1 
related to 0003887 closedLudek MediaMonkey causes some devices not to function correctly (Primo) 



2009-08-11 16:38

developer   ~0018626

Seems to be duplicate of 0005900


2009-08-18 01:09

developer   ~0018651

Similar but more related to RIP Speed


2009-08-20 03:40

developer   ~0018660

Reported here


2009-09-01 13:07

developer   ~0018708

Last edited: 2009-09-01 13:09

I have no issues on my laptop Lenovo ThinkPad SL500, Core 2 Duo, Win XP SP2.
Whole CD is ripped into M4A in 2 minutes.

Maybe it is somehow Quad core or Vista related.
Asked the user BluBear from the forum link for some additional tests that could show us more.


2009-09-01 16:25

developer   ~0018709

We will see I doubt as I have same issue on AMD X2 Dual Core and XP SP3 and also in Win 7 x64


2009-09-03 19:48

administrator   ~0018719

Peke, can you please verify whether 3.1.2 resolves this issue on your machine. If not, please provide Ludek with updated logs.


2009-09-08 01:24

developer   ~0018745

Verified in 1265


2009-09-14 15:14

developer   ~0018819

Reopened, because one user still experiences the problem:


2009-09-14 15:22

developer   ~0018820

Fixed in build 1267.


2009-09-18 03:21

developer   ~0018896

One user seems to have the same problem even after upgrading to 1266 and trying updated hpcdburn.dll, I'm awaiting a debug log from the user:


2009-09-29 14:09

developer   ~0019004

Last edited: 2009-09-29 14:14

Fixed in build 1270.


2009-10-15 21:18

developer   ~0019179

user in eSupport verified fix and multiple users in forum verified as well in build 1273


2009-12-17 10:49

developer   ~0019854

Re-opened, because one user still experienced this problem, see:

I was solving it with him, but he finally couldn't reproduce it anymore to confirm the fix, nevertheless I added a hack to prevent from this.

Fixed in build 1301.


2010-06-02 15:27

administrator   ~0020223

Ludek, not for 3.2.1?


2010-06-02 21:10

developer   ~0020227

No, as I wrote it was just another hack that hasn't been confirmed by the one user that still experienced the problem. Most users have already verified the fix in 3.2.0 and we don't seem to have more reports. In addition it is rather a bug on Drive Firmware level or Primo libraries level (not a problem in our code).


2010-10-07 21:33

developer   ~0020663

Closing as there was no additional reports. Re Verified in 1314 using steps to reproduce on several Machines and 6+ different Drives.