View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002543 | MMW v4 | Burning / Disc Handling | public | 2006-07-12 15:29 | 2006-08-06 05:34 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | ||
| Product Version | 2.5.3 | ||||
| Fixed in Version | 2.5.4 | ||||
| Summary | 0002543: Burning large file to MP3 Data CD --> "The Layout cannot be set" error | ||||
| Description | User reports that attempting to burn a 2hour MP3 file to a data CD --> the burn operation never even starts and an error message is returned: " Burning was not successful: The layout could not be set." | ||||
| Additional Information | Reported by John White jola68 at hughes.net (and a similar error was reported by Audrey van der Linde) Log file posted to ftp. Comment from Ludek: I saw the log. Obviously it crashed due to this line: hpCDEBurn: Image size in blocks: 2097180 > Free space: 299850 but it is ~4 GB ! that is quite bullshit for one file. From my experience such unreasonably large images our burner can create in case of one of the tracks physicaly doesn't exist. We have filter for it beforehand (line 596 in FormBurningWizard.pas): (( FileExistsW( SD.path) or ((SD.CacheStatus = CACHE_CACHED)and FileExistsW( CacheDir+SD.CacheName)))) but function for getting track path used in hpCDEBurner.pas (line 313) looks like function GetSongFilePath(....) .... if UpdateSDpath( SD)=0 then ...... .... if not preferCache and (SD.CacheStatus=CACHE_CACHED) then begin result := FileExistsW( CacheDir+SD.CacheName); fname := CacheDir + SD.CacheName; if result then exit; end; ..... and its return value is not tested! When you look at the burned track it looks like a Virtual CD track: C:\Documents and Settings\john white\My Documents\church services\sidney church sunday 4-2-06.mp3 Because return value of GetSongFilePath() is not tested, if UpdateSDpath( SD)<>0 we could obtain VCD path ( which may not exists due to conversion), Does the conversion change attributes like SD.CacheStatus properly? From my point of view it is the only way I see which could make some sense in solving this problem. Take it as my brainstorming. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 970 | ||||
|
|
Unfortunately I cannot reproduce it at all, but I've made some steps to make code safer, so that I could know more from debug logs in the future - revision 1320 and should be merged into 2.5.4. |
|
|
Tagging as resolved--I'll get users to test it in the next build. |
|
|
It should be resolved by 0002565. |
|
|
John White confirmed that this issue has been resolved on his machine. |
