View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005023 | MMW v4 | Burning / Disc Handling | public | 2008-12-11 02:27 | 2009-01-19 20:38 |
| Reporter | Assigned To | ||||
| Priority | immediate | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.1 | ||||
| Fixed in Version | 3.1 | ||||
| Summary | 0005023: Burn completes but takes hours | ||||
| Description | build 1201, burn cd audio (not mp3/data), appears to sucessfully burn, however it takes several hours to complete. | ||||
| Additional Information | http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=34906 | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Fixed in build | 1214 | ||||
| related to | 0004910 | closed | Ludek | HPCDE Primo: new version 2.5.8 engine should be included |
| parent of | 0005386 | closed | Ludek | Burn another copy doesn't work for audio CD burning (regression) |
| related to | 0003887 | closed | Ludek | MediaMonkey causes some devices not to function correctly (Primo) |
| related to | 0005149 | closed | Ludek | MM freeze on Vista when reading CD-Text for a particular CD sometimes (issue with autostart) |
| related to | 0004949 | closed | Ludek | CD ripping occassionaly fails for some users and CD drive is lost untill reboot |
| related to | 0006254 | closed | peke | Burning Audio CD takes 8 hours on particular Windows 7 (64 bit) systems |
| related to | 0008071 | closed | Ludek | Data CD/DVD burning problems with some old drives |
|
|
Additional info: windows xp X64 |
|
|
Teknojunky, works fine for me, does this problem occur in build 1198 too? If no then it is caused by update to Primo 2.5.1 and we should revert to 2.5. There is nothing in 2.5.1 we currently need. |
|
|
I have a burn going on 1198 (re-installed over 1201), and it appears to have the same problem... it got stuck at 3%, stopped for a few minutes, burned to 17% and paused again. Gonna let it go over night and attach the new log of 1198 in the morning. |
|
|
bleh, looks like note didn't accept the whole paste, but I will upload the whole thing in the morning. If someone wants to remove the partial log above, go ahead please. |
|
|
Ok, attach rather C:\hpcde.log, it seems to be Primo's issue caused by the 2.5 update, we can contact them for a fix/solution. Also confirm (re-test) that it works in MM 3.0 in order to ensure that it is not a HW issue. Also try whether it depends on selected write method (TAO/DAO) and check whether it is related to the 'On the fly audio burning'. It might be due to slow decoding (i.e. which files do you burn - MP3s)? |
|
|
uploaded hpcde and debug logs for 1198, also I just burned the same disc with 3.0.6.1190 and it took about 2 minutes, so it definately seems to be affecting 3.1.x series. |
|
|
Forwarded this to Primo...awaiting response. |
|
|
from Primo: We think this is an issue with MM. From the MM logs it seems data is fed by MM at low rate and the device falls back to 2x or 1x to prevent buffer under run. Because of the low speed it takes longer (up to 80 min at 1x) to burn a full audio CD. |
|
|
Reminder sent to: Teknojunky, could you please do the test with the '[ ] On the fly audio burning' checkbox unticked? So that we could ensure that it is/isn't related to decoding. And if you can then also try whether it depends on selected write method (TAO/DAO), but the former test is more important. Thx. |
|
|
Reminder sent to: Teknojunky, do you noticed my reminder? Could you please do the test with '[ ] On the fly audio burning' unticked. |
|
|
attaching debug and hpcde log for 1203, simulated burn with on the fly burning unchecked. |
|
|
Teknojunky, from the log is seen that you burnt 21 tracks in 20 minutes, this is not so bad as in the previous case, isn't it? So unchecking '[ ] On the fly audio burning' does the trick??? Which files you burn (FLAC, MP3, M4A ??) Nevertheless I upgraded to Primo 2.5.2, added some debug messages and improved handling of setting burn speed when burning audio CD, because it could be "set burn speed issue", so please try 1204 when it is available. |
|
|
Now I see the log again: All 21 tracks are MP3s and are prepared in a minute?? So they are too short, aren't they? What was the overal time of the 21 tracks? This would imply that unchecking '[ ] On the fly audio burning' does not do the trick. Let me know. |
|
|
all are mp3 except for 1 flac file. yes it was faster than without on the fly checked, however there were still several pauses where burning appeared to stop and then later resume, just like before. The computer is a quad core q6600 (2.4 ghz, 4 gig ram) so it is pretty fast to process files. The total of the tracks is 1:19:13 (79m13s) according to the track list. burn session starts @ 12.31.31 pauses 2% @ 12.31.41 resumes 2% @ 12.33.12 pauses 16% @ 12.35.11 resumes 16% @ 12.35.41 pauses 16% @ 12.35.41 resumes 16% @ 12.36.41 pauses 16% @ 12.36.41 resumes 16% @ 12.38.11 pauses 16% @ 12.38.12 resumes 16% @ 12.39.41 pauses 16% @ 12.39.42 resumes 16% @ 12.41.12 pauses 35% @ 12.42.11 resumes 35% @ 12.43.12 pauses 58% @ 12.43.41 resumes 58% @ 12.44.11 pauses 58% @ 12.44.11 resumes 58% @ 12.45.11 and so on until finish @ 12.50.26 so yes it was faster than before, but still not normal. I will give 1204 a try once available. Thanks! |
|
|
Studing both logs I found out that 1% is burnt in 2 seconds, i.e. 100% should be burnt in 200 seconds, i.e. in 3 minutes. But as you indicated there are unexpected delays (pauses) in both cases. Something is interferring with burning on your system and causes the burn operation to stop for a minute or two. Looking the logs it looks like WMDM could cause the stops. Could you try to rename the d_WMDM.dll to d_WMDM.dll.off and see if it helps. But it looks like also other actions (like receiving windows messages) are done in the one minute breaks. Hard to say what causes this 1 or 2 munutes long delays in burning. |
|
|
uploading logs for 1204 with wdm, and running logs now without wdm, both still have pauses and take long time. |
|
|
ok, so WMDM probably isn't cause of the occassional pauses. Another thing you might want to try is to invite Options|Performance sheet and increase the priority for background tasks. |
|
|
uploaded without wdm logs, trying with background process priority set to Normal and still pausing, will upload logs for it when it finishes. |
|
|
attached logs with 1204 normal background priority |
|
|
Problems are still the same despite the fact he burns on the fly or not. So in summary: From all the logs is seen that 1% is burnt in 2 seconds, i.e. 100% should be burnt in 200 seconds, i.e. in 3 minutes, but there are unexpected delays (pauses) in both cases. Something is interferring with burning on the system and causes the burn operation to stop for a minute or two. Hard to say what causes this 1 or 2 munutes long delays in burning, probably an Primo's optimization on the quad core q6600 machines? i.e. it seems that Primo introduced this regression between versions 2.10 and 2.5. |
|
|
I'd suggest to further try to eliminate what exactly causes the problem. Since 3.0.6 seems to work fine, we could create a special build for Teknojunky that uses the latest MM code, but the Primo version we had in 3.0.6. We can further decide then. Then we could also send Teknojunky testing applications from the latest Primo SDK, in order to see whether they exhibit the same problem. Interesting thing is that there are exactly 30 seconds delays in the log, i.e. that there is something burned, then nothing for 30 seconds and then again some small chunk. |
|
|
yes, it all seemed very strange. I am willing to test either/or custom mm or test apps |
|
|
Teknojunky, please download this file to your MM install directory http://www.yousendit.com/download/TTZsZ296aysxUUIzZUE9PQ and give a try. (i.e. replace your hpCDBurn.dll by this one). Thx. |
|
|
the linked hpcdburn.dll had no pauses and appeared to burn normally (and fast). attaching logs. |
|
|
Ok, so please give a try with this Primo's sample app: http://www.yousendit.com/download/TTZrWGJIQzN6NExIRGc9PQ |
|
|
I get an error 'this application has failed to start because the application configuration is incorrect. reinstall the app may fix the problem'. I tried this both in the MM folder and in a separate folder. |
|
|
Sorry, try this http://www.yousendit.com/download/TTZrT0NTeFVIcWRMWEE9PQ in a separate folder. |
|
|
i was able to run a simulation of that and there did not seem to be any pauses, however it was not an exact reproduction that I had been doing with mediamonkey (different tracks, only partial cd-text). attaching logs |
|
|
Strange, It should do the pauses as well, because it was the Primo Burner 2.5. update that caused this issue as confirmed by testing the linked hpcdburn.dll. Could you run the exact reproduction that you had been doing with mediamonkey (same tracks, same cd-text). I will look into the sample app whether they changed something. |
|
|
And try also this http://www.yousendit.com/download/TTZrT0NjQ1AwMEVLSkE9PQ hpCDBurn.dll that writes 10 blocks at once instead of 32 as the Primo's sample app does. Thx. |
|
|
the 10 block dll seemed to work better, but there are still long pauses attaching logs |
|
|
I attempted to burn this using my laptop (thinkpad xp sp3), and it appeared to burn normally. So this seems specific to my home machine & the updated primo. I will try regular xp/32 and vista/64 later to see if it is OS specific. |
|
|
I forgot to mention, the burn with xp sp3 was with 1205. Uploading logs from vista x64, with and without on the fly. Both experienced pauses, but burn completed in a reasonable time period. |
|
|
Ok well now we seem to be getting somewhere... xp32 appeared to burn with no pauses xp64 has long pauses vista64 has shorter pauses so it seems that something in the new burn engine is not getting along with 64 bit windows |
|
|
I am running a log again on xp 64, but it appears to be taking long pauses still, so will upload it later after it finishes. |
|
|
Ok, thank you for observations. No need for too many logs. I wonder whether the Primo's sample app has pauses on the xp64 / vista64 OS? Additionaly please also try MM whether changing write method (Track-at-once, Disk-at-one)takes effect? |
|
|
track at once also has pauses/takes hours (xp64). Have not yet tried exact repro with primo, only @ comment (0015827). |
|
|
see also another user having problem with vista x64 @ http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=35532 |
|
|
Please try exact repro with the Primo sample app so that we could re-contact them and resolve the problem somehow. Thx. The sample app ( http://www.yousendit.com/download/TTZrT0NTeFVIcWRMWEE9PQ ) should behave same as this https://www.yousendit.com/download/WnBUTkFxbEplcEpMWEE9PQ hpCDburn.dll (I've gone through the code and compared all - all is same as in the app) - powered by the Primo's 2.5.2 libs. |
|
|
no delay with primo app, small (but not hour) delays with that last hpcdburn.dll |
|
|
Ok, so in summary results are: 1. Delays appear despite the fact whether MM burns on the fly or not (it is not dependent on the decoding thread) 2. Delays appear only on the xp64 (long pauses) and vista64 (shorter pauses), on xp32 works fine (no pauses). 3. Delays appear only with Primo v2.5 libs and higher 4. Delays are shorter if block chunk is 10 instead of 32 5. Delays are various (from 2 seconds up to 2 minutes) 6. Delays don't appear with the Primo's sample app I have no ideas, it looks like a side effect, maybe another MM thread causes the delays in burning? Are you accessing the CD somehow via MM when burning? |
|
|
that seems to be accurate no other use is being done, in fact I stop all use while doing this test and not use the computer during it. I am suspecting it something to do with 64 bit windows and how primo uses it. I would tell primo try testing with 64 bit vista if they can't get xp 64. |
|
|
Teknojunky, please perform one more try with this https://www.yousendit.com/download/WnBSckhkOW4zS3AzZUE9PQ hpCdBurn.dll, I have added more debug messages in order to pinpoint where exactly are the delays. It doesn't seem to be when writing data to the device buffer, but on another point. If the log is too large then use yousendit.com as I used for posting this hpCDBurn.dll. Thank you. |
|
|
uploading log with latest hpcdburn.dll & 1208 |
|
|
7. from the last log can be seen that the delays are in the Primo's IDevice::LockOutputBuffer Method which locks a portion of the IDevice output buffer for writing. So it seems that we should compose an email from these 7 items for Primo to help (I will do). Tejnojunky, sorry for bothering, but could you test one more hpcdBurn.dll ( https://www.yousendit.com/download/WnBTQ3Q3TERHa01LSkE9PQ ), I don't need any log this time, just run a test. I decreased block chunk from 10 to 1 so that burning would be performed per each block and I just wonder whether this could be a workaround. Thx. |
|
|
Teknojunky, we tried to reproduce on Vista 64 and we cannot reproduce, so it is rather combination of New Primo's engine, 64-bits OS and (Quad core or CD-RW drive)? Nevertheless could you do the test with this DLLs https://www.yousendit.com/download/WnBTQ3R6b0I1UjUzZUE9PQ ? Just extract all three DLLs to the MM install directory and give a try. I don't need logs, but just your indication whether it helped or not. Thank you. |
|
|
still pauses with those 3 & 1208 |
|
|
And the dll with per each block burning mentioned in note 16008 ? |
|
|
16008 no apparent change, still pauses |
|
|
Based on what we found we could try to ask Primo for an idea, because it is related to the Primo's 2.5 update and there is something that Primo changed that caused the delays when calling their method IDevice::LockOutputBuffer. Sent to Primo: As described previously, we've observed a strange problem after updating to Primo libs version 2.5 (previously we used verison 2.10 and we had no such problems), where burns can take hours. Following your last response, we've done extensive research on this, but are currently at a loss as to how to proceed. The Problems are strange, because they only appears on 64-bit Windows systems, but only for some users (probably related to CD/DVD drive or to the fact that the user has Quad core processor). Burning successfuly completes, but takes hours, because there are delays in burning that occur when calling the IDevice::LockOutputBuffer method. Strangely enough, the bug doesn't seem to occur with your sample app. Here are the fact about the delays: 1. Delays appears whether MM burns on the fly or not (it is not dependent on the decoding thread) 2. Delays appear only on the xp64 (long pauses) and vista64 (shorter pauses); xp32 works fine (no pauses). 3. Delays don't appear on all 64-bits system, so it is probably related to the CD/DVD RW drive type or Quad core. 4. Delays appear only with Primo v2.5 libs and higher (with v2.10 works fine) 5. Delays are in the IDevice::LockOutputBuffer Method which locks a portion of the IDevice output buffer for writing. 6. Delays are various (from 2 seconds up to 2 minutes) 7. Delays seems to be shorter shorter if block chunk is 10 instead of 32 Do you have any ideas about how to solve this? Thank you. |
|
|
Fixed in 1214 (verified by Teknojunky). |
|
|
Btw. the fix related to this issue seems to fix also another issue, see: http://www.mediamonkey.com/support/staff/index.php?_m=tickets&_a=viewticket&ticketid=3626&highlight=--+Mixed+--&ticketsearchid=1244 |
