Ticket #28 (new bug)
Post your unclear problem sightings here, for now
| Reported by: | scdbackup | Owned by: | scdbackup |
|---|---|---|---|
| Priority: | trivial | Milestone: | |
| Component: | libburn | Version: | 0.2.2 |
| Keywords: | collective ticket for unclear incidents | Cc: |
Description
Hi,
i want to document a strange incident when burning a CD. I am quite sure that my kernel resp. the whole SuSE 9.0 and my whole hardware setup is to blame. Nevertheless it seems to be the occasion to start a ticket for strange sightings in general.
Maybe one should have a ticket department for such reports. For now we shall collect them here, i propose.
Sighting 1:
While i ran a checkread of a DVD+RW on my DVD-ROM i simultaneously burned a 4x CD-RW on the DVD/CD burner. This is quite a stunt because both devices sit on the same IDE controller. One can hardly read a DVD while burning another one (via growisofs). Both processes become extremely slow.
One can, nevertheless, usually checkread a 10x CD-RW while burning another - if one waits for the checkread to have gotten ~50 MB before blanking and subsequent burning start. With burning 4x CD-RW the controller can provide the DVD-ROM problemlessly, usually.
This time, for once, it was different:
Checkread did not slow down a bit (as usual), burner gnawed on CD-RW, cdrskin did not report actual start of blanking. The media type had *not* been evaluated, because scdbackup was told to assume CD-RW. (Saves time and moaning sounds from burner)
The gnawing did not end. 5 minutes long. No move of cdrskin.
I pressed Ctrl+C. No reaction.
I pressed the burner's eject button. Nothing happened.
I ended the checkread ... 30 seconds later cdrskin came back to life, blanked sucessfully (as it seems) and then the next cdrskin run burned without problems.
The result verifies as any other of my backups. I did this verification software myself and i trust it. Unconditionally. MD5 is more safe from error than earth is from impact of 10 km asteroids within the timespan of ten minutes.
The Ctrl+C was totally ignored. By my system, i have to assume. Possibly in cooperation with my workaround to ticket 10.
cdrskin version 0.1.4, emerging provisory stable, no O_EXCL experiments included yet. Thus vanilla drive handling as in both libburns' development versions. I used this for months now. (The CVS+whitelist, not my own now obsoleted patchwork libburn.)
A theory which would involve libburn here:
I rarely did DVD-checkreading together with CD writing. I never do DVD-read + DVD-write.
Can it be we have realtime processing aspects in libburn which show up when the overall system shows slow or delayed reaction ? See ticket #8 : False drive status immediately after loading the tray.
Not much idea what cdrecord would do in the same situation and absolutely no courage to try. Any weirdo here who wants to ? Report your eventual survival please :))
