[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 87267] Constantly refreshing CD makes ripping very slow
From:       Andrey Shytov <shytov () cmt ! harvard ! edu>
Date:       2004-09-13 21:25:12
Message-ID: 20040913212512.12299.qmail () ktown ! kde ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
        
http://bugs.kde.org/show_bug.cgi?id=87267        




------- Additional Comments From shytov cmt harvard edu  2004-09-13 23:25 -------
I also came across this bug. My hardware is Dell Inspiron 5100, CD drive is: \
HL-DT-STDVD-ROM GDR8082N, IDE-ATAPI, no scsi emulation, x86, CDROM is /dev/hda. The \
bug occurs only in KDE 3.3.0,  and not in KDE 3.2.3. cdparanoia works fine. Copying \
tracks from konqueror also does not create any problems. 

I investigated this bug, and found that it is due to different behaviour of libwm in \
KDE-3.2.3 and KDE-3.3.0. In KDE 3.2, libwm remembers the drive state after \
wm_cd_destroy (). In KDE 3.3, libwm forgets everything. Look into in \
kscd/libwm/cdrom.c for KDE-3.3.0: 

int wm_cd_destroy( void )
{
    // .....
    drive.proto = NULL; // In KDE-3.2.3, there is nothing like that. 
}

Now, what happens when  we query drive status on the next poll: 

int
wm_cd_status( void )
{
    static int oldmode = WM_CDM_UNKNOWN;
    int mode, err, tmp;
    if(!drive.proto) {
        // After wm_cd_destroy drive.proto == NULL, so we arrive here
        // every time kaudiocreator calls wm_cd_status . 
        // Therefore, oldmode == WM_CDM_UNKNOWN, always. 
        oldmode = WM_CDM_UNKNOWN;
        err = wmcd_open( &drive );
        // ...
    }
    // ...
}

One can see from this code, that every time kaudiocreator polls the drive
(TracksImp::timerDone), oldmode == WM_CDM_UNKNOWN (I added some 
fprintf for debugging, and see that indeed oldmode == WM_CDM_UNKNOWN 
on every call to wm_cd_status from kaudiocreator, no matter what).  
For that reason, wm_cd_status will read TOC (about ten lines below): 

if(WM_CDS_NO_DISC(oldmode) && WM_CDS_DISC_READY(mode)) {
   // ...
   if(read_toc() || 0 == thiscd.ntracks)  
   // ... 
}

In contrast to that, in KDE-3.2.3 libwm does not set drive.proto to NULL, 
and thus remembers the result of the previous poll. As a result, 
wm_cd_status does only ioctl (CDOMSUBCHNL, ...), and does not read TOC.
(I straced kaudiocreator both in KDE-3.2.3 and KDE-3.3.0)

Reading TOC is very time-consuming, because it requires repositioning
(on my CDROM drive, it is also makes a very distinct and annoying sound). 

> From what I found, it is not clear how one can cope with this problem. 
Currently, the way libwm opens and closes /dev/cdrom seems to be completely \
incompatible with kaudiocreator polling approach.  As a workaround, one can probably \
disable polling in kaudiocreator during the ripping process.  (If, for example, the \
user will remove disc from the drive, audiocd ioslave will probably complain, right? \
So it is not clear to me why the polling  is necessary during the ripping process. \
When the drive is idle, polling does not cause that much trouble, because it does not \
require repositioning).


[prev in list] [next in list] [prev in thread] [next in thread]