I've gone through almost a whole 10-pack of BD-R DL's, trying to reproduce and isolate this issue. And I am guessing, based on the evidence, that it has something to do with Imgburn not being able to find the layer switch point for a large file.
Drive 1 - Info: HL-DT-ST BD-RE WH16NS40 1.02-A0 (E:) (SATA)
I've burned a few BD-R's before, and most of them worked. I've bought two 10-packs so far, both Verbatim BD-R DL's 6x. But they only burn right at 4x speed. The first few failed, and I found that switching speeds from AWS to 4x worked, but increasing to 6x failed.
On my second pack, the first two ISOs I burned worked fine. The third, which I let run overnight, hanged at the "reserving track" phase. In the morning, it had been stuck there for almost nine hours. Cancelling did nothing, trying to eject the disc did nothing, and Windows Explorer hanged when I tried browsing to My Computer, so I had to reset the computer.
Tested burning a different ISO, worked fine.
So then I took the problematic ISO, extracted all the files, and tried burning them directly to a new disc. This hanged on "reserving track" too.
After some trial and error, I found this.
There are three large files on the ISO. They are:
00000.m2ts - 17.7 GB
00001.m2ts - 10.5 GB
00002.m2ts - 16 GB
As an experiment, I tried burning these files, just these files, directly, still using BD Video settings. It failed. The total size is 44.2 GB, so these should fit.
Next, I tried burning just the first two files. It worked! Obviously the disc isn't playable, but the test was to see if the files would burn or not, and they did.
Then I tried burning the second and third files, but not the first. This also worked.
Based on these tests, I am guessing that Imgburn can't reconcile splitting the middle file across two layers. I know the Blu-Ray standard supports this, I have commercial discs where 00000.m2ts alone is greater than 25GB.
My next test *would* be to try to burn these files:
00000.m2ts - 17.7 GB
00001.m2ts - 6 GB
00002.m2ts - 6 GB
00003.m2ts - 16 GB
on the hypothesis that 0+1 fit on layer 0, and 2+3 fit on layer 1. But right now I'm out of discs, and these tests are getting expensive.
This is both bug report, and a request for advice on a workaround.