View Issue Details

IDProjectCategoryView StatusLast Update
0003007MMW v4Burning / Disc Handlingpublic2008-12-07 16:46
Reporterrusty Assigned To 
PriorityurgentSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version3.0 
Fixed in Version3.1 
Summary0003007: Disc fails to refresh in Explorer (XP) after several burns
DescriptionIf MM is used to burn a CD (noticed this problem after burning Data CDs and DVDs), then although the CDs/DVDs are burned correctly, neither Windows nor MediaMonkey can show the contents of the disc UNTIL MM is closed!

I would like to test this further but don't have time. Try to replicate by burning a couple of DVDs and then a couple of CDs and then try browsing the contents of the burned discs.

Note: This may be related to bug 2934 in which MM fails to burn a second CD
Additional Informationhttp://help.lockergnome.com/general/Cdrom-Drive-Won-39-Refresh-Xp-ftopict6968.html
TagsNo tags attached.
Fixed in build

Relationships

related to 0002072 resolvedLudek Data Disc Burning: Verify Data functionality (fails for auto-conversion) 
related to 0002934 resolvedLudek MediaMonkey often fails to burn > 1 CD 
related to 0004180 closedLudek CD Burning: Improved status bar feedback during + on completion 
related to 0002741 closedrusty No writeable drive is reported when burned CD is inserted 
related to 0004910 closedLudek HPCDE Primo: new version 2.5.8 engine should be included 

Activities

Ludek

2007-04-19 08:58

developer   ~0009050

Last edited: 2007-04-19 08:58

I found out a method in hpcde. It is IDevice11::Reset. By using this method the problem seems to be resolved, but I've tested it only 10x times. This method is also useful to reset the device when a writing operation failed (there is no need to reboot system now).

So I hope that by adding this method it is resolved, if is not then re-open this issue, please.

Ludek

2007-04-19 09:46

developer   ~0009051

After some other attempts it still doesn't seem to be resolved :-(

rusty

2008-11-17 22:58

administrator   ~0014961

This seems to be resolved in via the v2.5 sdk.

rusty

2008-11-20 05:39

administrator   ~0015011

Verified 1193.