View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002376 | MMW v4 | Burning / Disc Handling | public | 2006-02-17 18:57 | 2006-03-02 01:28 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Summary | 0002376: Audio CD Burns are missing tracks when 1 defective file is included | ||||
| Description | Numerous users have complained of burnt CDs missing half of their tracks after a 'defective' track. It turns out, this is easily reproducible: 1) Create a playlist as follows: Track A Track B Track C (defective--meaning MM can't play it) Track D Track E 2) Burn an Audio CD -->Track A and B are decoded, but an error is returned for track C along the lines of: 'This track cannot be decoded possibly due to DRM restrictions. [Ok]' 3) User clicks 'Ok' -->CD burning immediately begins instead of continuing to decode tracks D, and E!! | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 948 | ||||
|
|
Fixed in build 945. |
|
|
Tested build 945, and now what happens is that the burn operation is cancelled when such a file is encountered. This can be very annoying. What should happen is that the current message should appear with '[OK] [Cancel]'. If the user presses [OK]: operation should proceed without the problematic track If the user presses [Cancel]: operation should be halted before the CD burn begins |
|
|
Fixed in build 946. - Buttons [Cancel] [Retry] [Ignore] are present now. |
|
|
Tested 946 and when burning tracks A, B, C, D, E (C is corrupt), and the user presses 'Ignore' then the resultant CD appears as follows: A (plays A) B (plays B) C (plays D!!) D (plays E!!) E (doesn't play anything!!) I don't know if this is intentional, but this certainly shouldn't occur. The only results that would be valid are: Retry --> System tries to decode the file again Ignore --> System pretends that track C was never intended to be burnt (i.e. removes it from the burn list) Cancel --> System halts the entire burn operation Related issue: The terminology of 'Cancel' 'Retry' 'Ignore' is confusing because it's unclear what 'Ignore' means. Given the context, the following would be more meaningful (and we have all three strings), in the order described: [Retry] [[Skip]] [Cancel] Note: this is what appears in XP when attempting to copy a set of files one of which is bad. |
|
|
Fixed in build 947. - The burning issue is fixed, but I'd defer that button change. Although we have 'Skip' we don't have '&Skip' string. |
|
|
It works except for the fact that the user has to click the 'Ignore' button twice. Not that bad, but should be fixed prior to release if it's low risk. Re. the button order, I'll open a new bug for 2.6. |
|
|
Fixed in build 948. - This happened when Leveling was enabled, it's fixed now. |
|
|
Verified 948. |
