False reports of drive and media status after load

[scdbackup@…]

If the media tray is not loaded when i init libburn:

The first burn_disc_erasable() says it is appendable. The second try says it is full. I reload the CD-RW. Now it is reported blank.

Calling burn_drive_get_write_speed(): The drive speed is 8448 on previously unloaded tray and 2112 on already loaded tray.

It looks like the drive would need more time to make up its mind after loading.

Correct speed and media status are needed for cdrskin -atip.

Workaround: I meanwhile employ a complicated dance of

init+scan(loading) - grab - release - grab - release - finish - init+scan - grab - release - grab

in order to get plausible results.

[scdbackup]

I made a quite wasted effort to analyze the further use of drive file descriptors between end of scanning and next drive grab. When my greps got fooled by the names of function pointers and by the wealth of sg_issue_command() calls, i inserted trace prints. Brute force. Shrug.

Result: My drive is approached via sg_issue_command() after enumerate_common() has ended and before sg_grab() is called next time. Thus we cannot simply close a drive after its scanning is done.

More: we seem not to have any clean "grabbing" at all. Drives are grabbed at scan time and the API function burn_drive_grab merely sets a few internal state variables and ensures that the file descriptor is really open. Grabbing in the sense of aquiring exclusive access to a single drive which was *not exclusive* before, seems not to happen at all.

Two remedies in mind :

- The older idea of an API close call for any drive except one that is given as parameter (use whitelist ? would become unorthogonal). The app would be responsible for not groping longer than absolutely needed. This idea still has to be evaluated. Best on a system with really two burner drives which really can work simultianeously.

- An auto-opener in sg_issue_command() which calls sg_grab() if it encounters drive's fd closed. That would quite completely burry the idea of grabbing a drive. This is not neatly implemented anyway, as i believe to know by now.

Are there any application programmers besides me who could issue an opinion about usability ? For cdrskin alone, i would leave the groping as is. The vanilla libburn API concept makes it a big problem. (One would need to make stoopid cdrskin runs to make it a problem in practice: cdrskin with no device address or one of pseudo-bus 0.)

[scdbackup]

Printouts, Re: my comment about failed code analysis and successful tracing

[scdbackup]

Ok. How to remove a misplaced comment and a misplaced attachment ? Sorry, this was for ticket #18 (O_EXCL)

[scdbackup]

Some progress has been made (revision 109):

The release-grab cycle is not longer needed for a correct result of burn_disc_erasable(). The false reply from burn_drive_get_write_speed() could not be solved yet.

This intermediate result makes possible to give up the release-grab cycle for all known purposes except cdrskin -atip. There it does not help either. Only a full finish-initialize cycle of the library gets the correct speed after the tray had to be loaded. This is on both of my drives with all three of my Linux systems.

[scdbackup]

Meanwhile, there is function burn_disc_read_atip() which supplies functions burn_drive_get_write_speed() and burn_drive_get_min_write_speed() with media related speed info.

The full finish-initialize cycle of the library is for now avoided only in the cdrskin version compiled with -experimental. After release 0.2.6 there will probably no such cycle in the standard version.

[scdbackup]

The problems seem to have come from a missing call to d->getcaps() in burn_drive_grab() (resp. its subordinates).

I'm testing the positive effect since two weeks now and there was no false status report any more. The workarounds will be obsolete with the next release.

[pygi]

Milestone 0.2.8 deleted

[carlisle1981]

As for women, nothing is as attractive as jewelry which let them enjoy the satisfaction to their heart's content. Nothing could be worse than those exaggerated and luxurious ones. Since once the jewels and dresses are well matched, the personal taste and qualities will be revealed. There are many wonderful jewelry options available, but not all of them are suitable for you. Make sure that both the face shape and hairstyle are considered when selecting jewelries. The following are some tips; hope to help you in some way! It would be great pride if the tips being provided here about match of jewelry have been of help to you. When choosing jewels, make sure that the jewels are matched with your complexion, dresses, personalities, profession, etc. The most important principle: don't make your jewels go the same with your face shape as well as go opposite to it. An oval face is slightly greater in length than in width, whose soft line and classic shape will be accented well with any jewels, such as pearl earrings, a matching pearl silver links of london bracelets necklace or a trendy ensemble of circle jewelry. The traditional bun matched with drop earrings will give others an impression of elegance. The extremely fashionable gold charm bracelets should be avoided. Black dresses are perfectly matched with links of london sweetie bracelets with bright and shining color. When visiting friends or relatives, wearing jewels that are fit for certain occasion will impress others as attractive as well as approachable. These over-shining jewels are less suitable for people with dim skin who should keep their eyes on ones with less bright color, like silver. Compared with the large size charm bracelet , the small and delicate ones are more suitable for people with nice hour-glass figure. But for middle-aged and elderly people, they will pay more attention on the gold charm bracelets with dark color and traditional design.