geohei Posted February 16, 2023 Share Posted February 16, 2023 (edited) Hi. First time this happened. I wasted already three BR 50 GB on this. No clue why this happens. I have 50.045.xxx.xxx bytes of data to be written. All goes fine until the very end where ImgBurn 2.5.8.0 is stuck w/ the message "Synchronizing Cache..." (in Log). No error messages, also not in Log. Any ideas why? Thanks Edited February 16, 2023 by geohei Link to comment Share on other sites More sharing options...
LIGHTNING UK! Posted February 16, 2023 Share Posted February 16, 2023 Please post the log of the entire burn session. Sync cache is a command send to the drive once all the data has been transferred to it. The drive then goes off and completes the burn. For whatever reason, your drive appears to be having a problem doing that - maybe because it's right at the edge of the disc? Link to comment Share on other sites More sharing options...
geohei Posted February 16, 2023 Author Share Posted February 16, 2023 I 06:24:32 ImgBurn Version 2.5.8.0 started! I 06:24:32 Microsoft Windows 7 Ultimate x64 Edition (6.1, Build 7601 : Service Pack 1) I 06:24:32 Total Physical Memory: 16.664.720 KiB - Available: 11.269.268 KiB W 06:24:32 Drive X:\ (FAT32) does not support single files > 4 GiB in size. I 06:24:32 Initialising SPTI... I 06:24:32 Searching for SCSI / ATAPI devices... I 06:24:32 -> Drive 1 - Info: ASUS BW-16D1HT 3.00 (K:) (SATA) I 06:24:32 -> Drive 2 - Info: ATAPI iHBS312 2 PL17 (L:) (SATA) I 06:24:32 Found 2 BD-ROM/HD DVD-ROMs, 1 BD-RE and 1 BD-RE XL! I 06:24:44 Project Successfully Loaded! I 06:24:44 File Name: E:\Application Data\ImgBurn\Project Files\Doc_647.ibb I 06:24:49 Operation Started! I 06:24:49 Building Image Tree... I 06:24:49 Calculating Totals... I 06:24:49 Preparing Image... I 06:24:49 Contents: 40 Files, 0 Folders I 06:24:49 Content Type: Data I 06:24:49 Data Type: MODE1/2048 I 06:24:49 File System(s): UDF (2.50) I 06:24:49 Volume Label: Documentary_647 I 06:24:49 Size: 50.045.882.694 bytes I 06:24:49 Sectors: 24.436.485 I 06:24:49 Image Size: 50.046.959.616 bytes I 06:24:49 Image Sectors: 24.436.992 I 06:24:58 Operation Successfully Completed! - Duration: 00:00:08 I 06:24:58 Operation Started! I 06:24:58 Source File: -==/\/[BUILD IMAGE]\/\==- I 06:24:58 Source File Sectors: 24.436.992 (MODE1/2048) I 06:24:58 Source File Size: 50.046.959.616 bytes I 06:24:58 Source File Volume Identifier: Documentary_647 I 06:24:58 Source File Volume Set Identifier: 565033180174E085 I 06:24:58 Source File Application Identifier: ImgBurn v2.5.8.0 I 06:24:58 Source File Implementation Identifier: ImgBurn I 06:24:58 Source File File System(s): UDF (2.50) I 06:24:58 Destination Device: [5:0:0] ASUS BW-16D1HT 3.00 (K:) (SATA) I 06:24:58 Destination Media Type: BD-R (Disc ID: RITEK-DR2-000) I 06:24:58 Destination Media Supported Write Speeds: 2x; 4x I 06:24:58 Destination Media Sectors: 24.438.784 I 06:24:58 Write Mode: BD I 06:24:58 Write Type: DAO I 06:24:58 Write Speed: 4x I 06:24:58 Hardware Defect Management Active: No I 06:24:58 BD-R Verify Not Required: Yes I 06:24:58 Link Size: Auto I 06:24:58 Lock Volume: Yes I 06:24:58 Test Mode: No I 06:24:58 OPC: No I 06:24:58 BURN-Proof: Enabled I 06:24:58 Write Speed Successfully Set! - Effective: 17.984 KB/s (4x) I 06:25:24 Filling Buffer... (80 MiB) I 06:25:24 Writing LeadIn... I 06:25:25 Writing Session 1 of 1... (1 Track, LBA: 0 - 24436991) I 06:25:25 Writing Track 1 of 1... (MODE1/2048, LBA: 0 - 24436991) I 06:25:25 Writing Layer 0... (LBA: 0 - 12219391) I 06:54:33 Writing Layer 1... (LBA: 12219392 - 24436991) I 07:17:48 Synchronising Cache... Link to comment Share on other sites More sharing options...
geohei Posted February 16, 2023 Author Share Posted February 16, 2023 (edited) Yes, it is at the very end of the disc. Nevertheless it shouldn't do so. I did many sessions with similar payload (99% full) and never had this issue before. Edited February 16, 2023 by geohei Link to comment Share on other sites More sharing options...
dbminter Posted February 16, 2023 Share Posted February 16, 2023 If you burned many similar sized discs before and it worked, then the problem could be the drive itself. It may need replacing. You may also want to try a BD-R 50 other than Ritek. Like Verbatim's VERBAT-IM media. Link to comment Share on other sites More sharing options...
geohei Posted February 16, 2023 Author Share Posted February 16, 2023 (edited) Just to make it clear. If the disc reports a capacity to ImgBurn, and ImgBurn knows how much data to write, does this mean that all data (including structures, overhead, ...) fit the disc and will be written successfully? In other words, could it be that the 50.045.xxx.xxx Bytes were too much for the disc and ImgBurn would not complain prioir write, but the drive would eventually just fail to write (like in my case)? Edited February 16, 2023 by geohei Link to comment Share on other sites More sharing options...
LIGHTNING UK! Posted February 17, 2023 Share Posted February 17, 2023 If ImgBurn doesn't tell you that it won't fit, it'll fit. There's just more chance of the drive failing to burn / close the disc on the outer edge. It still shouldn't get stuck forever though. Can you hear the drive doing anything? Does it keep spinning forever? When you eventually force it to end (by powering off the machine or whatever), can you then restart the machine and is the drive able to initialise the disc ok? What comes up in the disc info box on the right when you fire up ImgBurn and go into Write mode? Link to comment Share on other sites More sharing options...
geohei Posted February 17, 2023 Author Share Posted February 17, 2023 Yes, the drive went stuck forever. I can't recall if it was still spinning or not. I had to stop ImgBurn via Task Manager (End Task). Even after that, the drive was flashing and I could not eject the disc. I had to restart the system. After restart of the system, I checked the disc and it looked like all data was on. Since all data had md5 checksums, I ran them. All data was correct! Nevertheless I didn't "trust" this disc, reduced the volume from 50.045... to 50.043... and this time the write operation succeeded! Link to comment Share on other sites More sharing options...
Recommended Posts