View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004949 | MMW v4 | Conversion/Leveling | public | 2008-11-20 15:21 | 2022-04-29 01:11 |
| Reporter | Ludek | Assigned To | |||
| Priority | immediate | Severity | minor | Reproducibility | random |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.1 | ||||
| Fixed in Version | 3.1 | ||||
| Summary | 0004949: CD ripping occassionaly fails for some users and CD drive is lost untill reboot | ||||
| Description | This issue is well desribed in several tickets: http://www.mediamonkey.com/support/staff/index.php?_m=tickets&_a=viewticket&ticketid=2869 http://www.mediamonkey.com/support/staff/index.php?_m=tickets&_a=viewticket&ticketid=2946 http://www.mediamonkey.com/support/staff/index.php?_m=tickets&_a=viewticket&ticketid=2898 and users indicated that randomly (e.g. 4th CDs fails to rip on e.g. 8th track). Studing the logs I found out that the problem occurs on the point of reading TOC, but it is very strange why it occurs only occassionaly (TOC has been read successfuly several times and it failed e.g. on the 8th attempt) We should contact Primo about this problem and we could try to make a workaround (e.g. TOC cache, i.e. TOC would be read only once for all the ripped tracks of a ripped CD) | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Fixed in build | 1221 | ||||
| related to | 0005023 | closed | Ludek | Burn completes but takes hours |
| parent of | 0005853 | closed | Ludek | Some tracks cannot be ripped to the Virtual CD |
| parent of | 0006155 | closed | Ludek | Problem when ripping more than one CD per session |
| 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 | 0005839 | closed | Ludek | Drive initialization takes 30 seconds or forever on some systems |
|
|
Ben confirmed that Primo libs 2.5 doesn't solve the issue, see http://www.mediamonkey.com/support/staff/index.php?_m=tickets&_a=viewticket&ticketid=2869&offset=40 |
|
|
Chris confirmed that he has ripped 6 discs in a row without lockup or failure by using another drive (IDE cable). The faulty CDROM is a SATA cable. He is still waiting for the new factory replacement, but it appears that the problem an issue with faulty/non-responsive equipment on his machine. It seems to be related only to some CDROM drives. viz http://www.mediamonkey.com/support/staff/index.php?_m=tickets&_a=viewticket&ticketid=2898 |
|
|
This was known issue in Nero 7. http://forum.digital-digest.com/archive/index.php/t-71039.html And it looks in Newest nero again SATA -> IDE issue? http://forums.whirlpool.net.au/forum-replies-archive.cfm/1051868.html Google search: http://www.google.com/search?q=SATA+Error+Nero Note: I have tested model Sony-Nec AD7200S (Optirac) SATA without problems the only difference is that Sony-Nec AD7203S have LabelFlash, but again mine Sony-Nec AD-7173A (IDE) work flawlessly and have LabelFlash. Ludek I'm Open to all suggestions Suggestions ideas? |
|
|
I guess we should contact Primo about this issue, hopefully they have a solution or workaround, I try to create a letter for them in this note: Hi, some of our users have troubles with ripping, in general they use a SATA CD-ROM drive (e.g. PHILIPS , DVD+-RW DVD8631 vGD30 (1:0:0)). It happens they lose their CD-Rom drive and must reboot to get it back. Strange thing is that it happens on occassion. i.e. sometimes the CD is ripped successfuly and sometimes it fails when ripping e.g. 8th track. Based on generated MM logs we found that the crash is on the point of reading TOC of the ripped CD. But strange thing is that it reads TOC 7 times correctly and on the 8th attempt it fails, locks the cd drive and drive is lost until reboot. i.e. the issue appears randomly, but users confirmed that have ripped many discs using Windows Media Player without a problem. We have also confirmed that the issue appears also when using the newest (version 2.5) PrimoBurner libs. Is this known problem? Any clues or suggestions? And the hpCDE.log attached to this Mantis issue should be attached to the email. Rusty, could you send it, please? |
|
|
Unfortunatelly Primo has not replied yet :-( Assigning to me in order to make the TOC cache hack that could help. |
|
|
Implemented the TOC cache hack in build 1199. I am about to post 1199 to the user to test whether it helped. |
|
|
The TOC cache hack solved this only partially as described here: http://www.mediamonkey.com/support/staff/index.php?_m=tickets&_a=viewticket&ticketid=2869&offset=80 Now the problem occurs between rips. I guess we should try to re-contact Primo support as they have not replied so far. The email should be the same as in the note 0015049 (which has not been replied) |
|
|
Related ticket: http://www.mediamonkey.com/support/staff/index.php?_m=tickets&_a=viewticket&ticketid=3140&offset=10 |
|
|
User indicated in this ticket: http://www.mediamonkey.com/support/staff/index.php?_m=tickets&_a=viewticket&ticketid=3140&offset=10 "To answer your question, drive D: does work with WMP and I am able to rip and play CDs in it. However D: drive's problem in Media Monkey was never intermmitent, I was never able to rip or play CDs with it from D: drive. That, and Microsoft's autorun repair application indicating that there is a problem with my D: drive "Result: This AutoPlay setting cannot be fixed. Either the device is malfunctioning, or the wizard cannot determine the problem.", makes me think that I just need to replace the drive." The hpCDE2.log attached. The SAMSUNG drive (D:) is the problematic that causing both CD drives (D:,E:) to disappear. The NEC drive (E:) do not cause the drives to disappear. |
|
|
Same issue here: http://www.mediamonkey.com/support/staff/index.php?_m=tickets&_a=viewticket&ticketid=3435 |
|
|
Because we resolved bug 0005023 by adding a prevention from accessing the drive while burning I hope that this could be the same issue therefore I added prevention from double accessing the CD drive in build 1214. It could help. I will ask the users once the build is available. |
|
|
Ben wrote: "I was very optimistic but It failed to fix my problem...." http://www.mediamonkey.com/support/staff/index.php?_m=tickets&_a=viewticket&ticketid=2869 Asking another user here: http://www.mediamonkey.com/support/staff/index.php?_m=tickets&_a=viewticket&ticketid=3435 |
|
|
But based on Ben's last log ( https://rcpt.yousendit.com/644871712/835ba44be3b5bd70382d5dc6d4f13b71 ) it seems that things are much better, he ripped several CDs and it taken 1 hour to reproduce the error. I forgot to cover one place in code which failed after the hour. Should be fixed in build 1218. |
|
|
Both Bex (Ticket ID: YMV-213042 ) and Ryanjo (Ticket ID: TRI-634749 ) confirmed this has not been resolved for them. Because this problem is known also for other software and is related to particular system and equipment I guess it is a low lovel problem related to user's hardware/drivers/equipment. See: http://forums.cnet.com/5208-4_102-0.html?threadID=306456 http://wizardcreations.wordpress.com/2008/01/27/itunes-makes-my-cddvd-drive-disappear/ http://www.gearsoftware.com/wiki/index.php?title=CD/DVD_drives_disappear_after_installing_iTunes I have no other ideas than search the internet for a solution (if any exists). |
|
|
Studing the debug logs (from Ben and Ranyo) further I found that it seems to fail in the part of code that is not necessary for ripping (getting write speeds capabilities of the device). Therefore I removed the useless code where it seemed to fail and added some new debug messages. I am on hope this will solve the issue in build 1221. |
|
|
Things are better (Ben ripped 13 CDs before it failed and drive disappeared). Nevertheless there seems to be a workaround: http://www.mediamonkey.com/forum/viewtopic.php?f=7&t=32640 "There is a setting in the BIOS config for SATA. It comes with it set to ACHI mode. I switched it to Compatibility mode." Maybe something we could add to KB article? |
|
|
You are right, but I doubt it fixed source of problem. As I already explained there this should be very big issue on XP but should not be the issue with Vista, also AHCI is tied to SATA II HDDs and not Optical devises. There is big gap in ACHI (or SATA II Extended Access Calls or whatever it is also called). This smells as same issue when IDE CD-Roms started to be manufactured where ASPI came into place and translated all SCSI calls thru IDE interface, ... I also have some issues when Attaching SATA DVD Burner to Sata Controller that had RAID enabled (it was fixed by manufacturer BIOS Firmware update). I'm not sure should we report all this to Primo and what to do next? Note: that most issues reported are due the fact that most current Laptops have ACHI Enabled by default "forcing" Users to use Vista as both DVD and HDD are SATA. |
|
|
Also Ranyo confirmed that things are better in 1221: "OK so 1221 certainly made things better but eventually the drive still goes away. I am now able to rip many more CDs (I'd guess 15 or 20 one of my three tests) before having to reboot. Still not like it should be but better than it was." |
|
|
Closed due no additional issues reported. |
|
|
This was reported on build 1247 at: http://www.mediamonkey.com/support/staff/index.php?_m=tickets&_a=viewticket&ticketid=4630 |
|
|
Another instance, mentioned by Ludek: http://www.mediamonkey.com/support/staff/index.php?_m=tickets&_a=viewticket&ticketid=5322 |
