DVD writing failure with k3b

I’ve been having problems with using k3b for a while, but the latest problem gave me the opportunity to pin the behavior down a little better. I was writing a DVD, and the process seemed to go properly for the first 1500 MB, more or less. And then it hung. Eventually k3b itself terminated the writing attempt with an error. This time I started k3b from a terminal, so I have some indication of what was happening, and perhaps someone here can figure out what the cause of the problem is. I don’t believe it’s hardware. Here’s the log:


(K3bDevice::Device) /dev/sr0: GET PERFORMANCE dataLen = 72
(K3bDevice::Device) /dev/sr0: GET PERFORMANCE successful with reported length: 68
(K3bDevice::Device) /dev/sr0:  Number of supported write speeds via GET PERFORMANCE: 4
(K3bDevice::Device) /dev/sr0 : 11080 KB/s
(K3bDevice::Device) /dev/sr0 : 8310 KB/s
(K3bDevice::Device) /dev/sr0 : 5540 KB/s
(K3bDevice::Device) /dev/sr0 : 3324 KB/s
QGDict::hashKeyString: Invalid null key
QGDict::hashKeyString: Invalid null key
(K3bDevice::DeviceManager) request for empty device!
(K3bDevice::Device) /dev/sr0: GET PERFORMANCE dataLen = 72
(K3bDevice::Device) /dev/sr0: GET PERFORMANCE successful with reported length: 68
(K3bDevice::Device) /dev/sr0:  Number of supported write speeds via GET PERFORMANCE: 4
(K3bDevice::Device) /dev/sr0 : 11080 KB/s
(K3bDevice::Device) /dev/sr0 : 8310 KB/s
(K3bDevice::Device) /dev/sr0 : 5540 KB/s
(K3bDevice::Device) /dev/sr0 : 3324 KB/s
(K3bDevice::HalConnection) lock queued for /org/freedesktop/Hal/devices/storage_model_DVDRW_LH_20A1P
(K3bDevice::HalConnection) unlock queued for /org/freedesktop/Hal/devices/storage_model_DVDRW_LH_20A1P

The lock was queued for perhaps 15 minutes while k3b was sitting there with full buffers, both software and device. The unlock was queued at the point where the process failed.

Is this Packman k3b?
rpm -qi k3b k3b-codecs

When k3b starts it reports on system problems! Do you see any.

Has this been working ok in the past? Have you tried it with a different burning software?

I found this, but it’s not much help
https://bugzilla.redhat.com/show_bug.cgi?id=187943

I replaced k3b and k3b-codecs with the Packman versions, as you suggested. It made no difference.

Although for a long time I thought k3b was somehow responsible for my drive problems, I no longer believe that since hwinfo --cdrom also gets hung for a while. But I don’t think the problem is related to the drives or even the cables any more – I think it’s something in the system software. Here’s why.

The behavior I observe with both k3b and the hardware test is that when I first start up my system, both programs respond quickly, but after a while they take a very long time to even get started. If I start writing a DVD, the operation starts quickly enough but quits after about 1400 MB. I thought it might have to do with an overheated component, but I checked that hypothesis by rebooting the entire system without powering down. If overheating was the problem, it should have persisted after the reboot. Again, when the computer started up, k3b and the hardware test responded immediately. So there seems to be some kind of logical crud that gradually builds up as the system runs.

Since there are two drives, it seems unlikely that the drives themselves are responsible. I don’t even think it’s a cabling problem, as I previously thought, since the drive programs start promptly when the system starts. (That’s what misled me to think it was a cabling problem.) And I don’t think it’s hardware for the reasons I just gave above.

Since it seems unlikely that anyone can point directly to the source of the problem, are there any tests I can run that at least might narrow it down?

One more piece of information: this is a dual-boot machine and the drives are working correctly under Windows XP.

Yet another observation after some experimentation: the delay gets worse as time elapses since the last boot, even if the CD drives have not been referenced. Response is very fast right after boot and deteriorates thereafter. My guess is that some critical system resource is getting used up, but I don’t know how to verify that or determine which resource is involved.

Are these SATA drives?
Or older PATA which can offer connection on the same cable/channel?

Here’s what hwinfo has to say about the drives:

Blockdevice:    /dev/sr1
Generic device:
Vendor:         LITE-ON
Description:    COMBO SOHC-5232K
Version:        NK04
Write speed:    3324
Profiles:       DVD-ROM, CD-ROM, CD-R, CD-RW
Read Cap:       DVD-ROM, DVD+RW, DVD+R, CD-ROM, CD-R, CD-RW
Write Cap:      CD-R, CD-RW
Writing modes:  SAO, TAO, RAW, SAO/R96P, SAO/R96R, RAW/R16, RAW/R96P, RAW/R96R
Reader aliases: /dev/sr1
------------------------------
Blockdevice:    /dev/sr0
Generic device:
Vendor:         LITE-ON
Description:    DVDRW LH-20A1P
Version:        KL0N
Write speed:    3324
Profiles:       DVD-ROM, DVD-R Sequential, DVD-R Dual Layer Sequential, DVD-R Dual Layer Jump, DVD-RAM, DVD-RW Restricted Overwrite, DVD-RW Sequential, DVD+RW, DVD+R, DVD+R Dual Layer, CD-ROM, CD-R, CD-RW
Read Cap:       DVD-ROM, DVD-R, DVD-R Sequential, DVD-R Dual Layer, DVD-R Dual Layer Sequential, DVD-R Dual Layer Jump, DVD-RW, DVD-RW Restricted Overwrite, DVD-RW Sequential, DVD+RW, DVD+R, DVD+RW Dual Layer, DVD+R Dual Layer, CD-ROM, CD-R, CD-RW
Write Cap:      DVD-R, DVD-R Sequential, DVD-R Dual Layer, DVD-R Dual Layer Sequential, DVD-R Dual Layer Jump, DVD-RW, DVD-RW Restricted Overwrite, DVD-RW Sequential, DVD+RW, DVD+R, DVD+R Dual Layer, CD-R, CD-RW
Writing modes:  TAO, Restricted Overwrite, Layer Jump
Reader aliases: /dev/sr0

I know they aren’t SATA drives; they are both connected on the same IDE cable using cable select, so I assume they are PATA.

Whatever the analysis, it needs to account for the fact that the drives work correctly and quickly at first. If there was a major misconfiguration, that wouldn’t be happening.

You need to set One to master and the other to Slave. The cable will be marked that way too. Normally, the very end connector is master and the one spliced in along the line is slave, but check. And the jumpers on the drives need to set accordingly.

I tried recabling the other way with explicit master/slave, as you suggested, and it didn’t make any difference. The behavior is just the same as it was using cable-select.

Well your only other approach now is to disconnect the slave and see how the One performs on it’s own. This will either resolve the issue or confirm the issue is system related.

I was wondering if you had tried a failsafe boot. And see how they behave then?

I disconnected the second drive, and so far the delays seem to be gone, though my previous experience shows that it’s hard to be sure of that for quite a while. Now I wonder why having the second drive is so troublesome and if there’s a way to attach it after all.

Well, give it time. To be sure.

I guess the obvious is check and double check the mater slave settings. I was in a thread last week where that proved to be the solution and I know it has been covered a number of times over the years.

See how it goes.

I tried disconnecting the second drive, but I still have the problem after waiting for a while.

At first it appeared that I had a hardware problem, but the facts that (a) it gradually gets worse with time, and (b) rebooting causes it to revert to the initial short wait, seem a strong indication that it’s software, not hardware. A hardware problem such as overheating would not go away after a reboot.

And it’s really slow. At the moment I’m copying a CD to an iso image, and after 7 minutes it only got through 35 MB. The one that I copied right after a reboot sailed right through, as it was supposed to.

The most likely explanation, I think, is that there’s some resource required for the CD operations that is getting used up with time, regardless of whether or not I’m actually doing CD operations. I think there’s a reportable bug here, though I’ll be ****ed if I can say how to reproduce it on another machine.

The error that you reported in post #1 suggest a QT issue.

What version of kde are you using? And is your system fully updated.?

I would like to see the result of:

zypper lr

and

zypper lu

I’m using KDE 3.5.10, release 21.11. The system is fully updated, but that’s probably not too relevant since I’ve been having this problem for quite some time.

And here’s the zypper information you asked for:

suillus2:~ # zypper lr
# | Alias                | Name                  | Enabled | Refresh
--+----------------------+-----------------------+---------+--------
1 | Libdvdcss repository | Libdvdcss repository  | Yes     | Yes
2 | Packman Repository   | Packman Repository    | Yes     | Yes
3 | openSUSE 11.1-0      | openSUSE 11.1-0       | No      | No
4 | repo                 | VideoLan Repository   | Yes     | Yes
5 | repo-debug           | openSUSE-11.1-Debug   | No      | Yes
6 | repo-non-oss         | openSUSE-11.1-Non-Oss | Yes     | Yes
7 | repo-oss             | openSUSE-11.1-Oss     | Yes     | Yes
8 | repo-source          | repo-source           | No      | Yes
9 | repo-update          | repo-update           | Yes     | Yes
suillus2:~ # zypper lu
Loading repository data...
Reading installed packages...
S | Repository          | Name                    | Version                | Arch
--+---------------------+-------------------------+------------------------+-------
v | openSUSE-11.1-Oss   | FirmwareUpdateKit       | 1.1-2.6                | i586
v | openSUSE-11.1-Oss   | SDL-devel               | 1.2.13-104.1           | x86_64
v | openSUSE-11.1-Oss   | SDL_Pango-devel         | 0.1.2-164.101          | i586
v | openSUSE-11.1-Oss   | Xerces-c                | 2.8.0-29.37            | x86_64
v | openSUSE-11.1-Oss   | alsa-devel              | 1.0.18-8.9             | x86_64
v | openSUSE-11.1-Oss   | busybox                 | 1.12.1-1.14            | i586
v | openSUSE-11.1-Oss   | clucene-core-32bit      | 0.9.21-1.6             | x86_64
v | openSUSE-11.1-Oss   | cyrus-sasl-saslauthd    | 2.1.22-182.1           | x86_64
v | openSUSE-11.1-Oss   | db43                    | 4.3.29-125.5           | i586
v | openSUSE-11.1-Oss   | dmapi                   | 2.2.8-96.8             | x86_64
v | openSUSE-11.1-Oss   | emacs-el                | 22.3-4.6               | x86_64
v | openSUSE-11.1-Oss   | fam-server              | 2.7.0-130.1            | i586
v | Packman Repository  | ffmpeg                  | 0.5-0.pm.2             | x86_64
v | openSUSE-11.1-Oss   | glitz-32bit             | 0.5.6-185.1            | x86_64
v | openSUSE-11.1-Oss   | gtk-32bit               | 1.2.10-1084.3          | x86_64
v | openSUSE-11.1-Oss   | gwenview                | 1.4.2-116.45           | x86_64
v | openSUSE-11.1-Oss   | gwenview-lang           | 1.4.2-116.45           | x86_64
v | openSUSE-11.1-Oss   | gxmhtml                 | 1.4.2-11.1             | i586
v | openSUSE-11.1-Oss   | i4lfirm                 | 2008.12.9-1.1          | i586
v | openSUSE-11.1-Oss   | isapnp                  | 1.26-613.29            | i586
v | openSUSE-11.1-Oss   | jack                    | 0.109.2-63.6           | i586
v | openSUSE-11.1-Oss   | k3b-lang                | 1.0.5-48.22            | x86_64
v | openSUSE-11.1-Oss   | kdeartwork3-sound       | 3.5.10-1.62            | i586
v | openSUSE-11.1-Oss   | kdebase3-kdm            | 3.5.10-17.4            | x86_64
v | openSUSE-11.1-Oss   | kdebase4-openSUSE-lang  | 11.1-66.4              | x86_64
v | openSUSE-11.1-Oss   | kdegames3-card          | 3.5.10-1.35            | x86_64
v | openSUSE-11.1-Oss   | kdemultimedia4          | 4.1.3-4.11             | x86_64
v | openSUSE-11.1-Oss   | kdenetwork3-vnc         | 3.5.10-12.10           | x86_64
v | openSUSE-11.1-Oss   | libFLAC++6-32bit        | 1.2.1-68.8             | x86_64
v | VideoLan Repository | libass3                 | 0.9.6-2.1              | x86_64
v | openSUSE-11.1-Oss   | libavc1394              | 0.5.3-129.3            | i586
v | Packman Repository  | libavcodec52            | 0.5-0.pm.2             | x86_64
v | Packman Repository  | libavdevice52           | 0.5-0.pm.2             | x86_64
v | Packman Repository  | libavformat52           | 0.5-0.pm.2             | x86_64
v | Packman Repository  | libavutil49             | 0.5-0.pm.2             | x86_64
v | VideoLan Repository | libavutil50             | 0.5.0.18507-1.1        | x86_64
v | openSUSE-11.1-Oss   | libcap1                 | 1.10-5.41              | x86_64
v | openSUSE-11.1-Oss   | libcdio7-32bit          | 0.80-5.26              | x86_64
v | openSUSE-11.1-Oss   | libdc1394-22            | 2.0.2-10.23            | x86_64
v | openSUSE-11.1-Oss   | libdc1394_control12     | 1.2.2-10.23            | x86_64
v | VideoLan Repository | libdvdcss               | 1.2.10-6.1             | x86_64
v | openSUSE-11.1-Oss   | libedit0                | 2.11.snap20080712-1.39 | x86_64
v | VideoLan Repository | libfaac0                | 1.26-15.53             | x86_64
v | openSUSE-11.1-Oss   | libflashsupport         | 1.2-4.20               | i586
v | openSUSE-11.1-Oss   | libgluezilla0           | 2.0-10.39              | x86_64
v | openSUSE-11.1-Oss   | libgnomecups-lang       | 0.2.3-108.12           | x86_64
v | openSUSE-11.1-Oss   | libgnutls-extra26       | 2.4.1-24.1             | x86_64
v | VideoLan Repository | libkate1                | 0.3.1-1.1              | x86_64
v | openSUSE-11.1-Oss   | libkdecore4-32bit       | 4.1.3-4.9              | x86_64
v | openSUSE-11.1-Oss   | liblazy1-32bit          | 0.2-35.34              | x86_64
v | Packman Repository  | libmp4v2                | 1.5.0.1-10.pm.1        | i586
v | openSUSE-11.1-Oss   | libmysqlclient15-32bit  | 5.0.67-12.11           | x86_64
v | openSUSE-11.1-Oss   | libpoppler-doc          | 0.10.1-1.4             | x86_64
v | openSUSE-11.1-Oss   | libraw1394              | 1.3.0-16.45            | i586
v | openSUSE-11.1-Oss   | libstrigi0-32bit        | 0.5.11-39.11           | x86_64
v | Packman Repository  | libswscale0             | 0.5-0.pm.2             | x86_64
v | VideoLan Repository | libvlc2                 | 0.9.9-1.5              | x86_64
v | VideoLan Repository | libvlccore0             | 0.9.9-1.5              | x86_64
v | Packman Repository  | libxine1                | 1.1.16.3-0.pm.0        | x86_64
v | Packman Repository  | libxine1-codecs         | 1.1.16.3-0.pm.0        | x86_64
v | Packman Repository  | libxine1-gnome-vfs      | 1.1.16.3-0.pm.0        | x86_64
v | Packman Repository  | libxine1-pulse          | 1.1.16.3-0.pm.0        | x86_64
v | openSUSE-11.1-Oss   | libzvbi0                | 0.2.33-1.30            | x86_64
v | openSUSE-11.1-Oss   | perl-XML-Bare           | 0.30-1.47              | x86_64
v | openSUSE-11.1-Oss   | portaudio               | 19-234.50              | x86_64
v | openSUSE-11.1-Oss   | pwlib                   | 1.10.10-120.51         | x86_64
v | openSUSE-11.1-Oss   | rinetd                  | 0.61-930.28            | i586
v | openSUSE-11.1-Oss   | rsh-server              | 0.17-706.15            | i586
v | openSUSE-11.1-Oss   | slang-32bit             | 2.1.1-57.43            | x86_64
v | openSUSE-11.1-Oss   | smb4k                   | 0.9.8-1.27             | x86_64
v | openSUSE-11.1-Oss   | speex                   | 1.1.99.91-1.30         | i586
v | openSUSE-11.1-Oss   | src_vipa                | 2.0.4-1.5              | i586
v | openSUSE-11.1-Oss   | syslogd                 | 1.4.1-708.14           | i586
v | openSUSE-11.1-Oss   | tcpd-32bit              | 7.6-855.11             | x86_64
v | VideoLan Repository | vlc                     | 0.9.9-1.5              | x86_64
v | VideoLan Repository | vlc-aout-pulse          | 0.9.9-1.5              | x86_64
v | VideoLan Repository | vlc-gnome               | 0.9.9-1.5              | x86_64
v | VideoLan Repository | vlc-noX                 | 0.9.9-1.5              | x86_64
v | VideoLan Repository | vlc-qt                  | 0.9.9-1.5              | x86_64
v | VideoLan Repository | x264                    | 0.67-10.1              | i586
v | openSUSE-11.1-Oss   | xbase                   | 2.0.0-251.14           | i586
v | openSUSE-11.1-Oss   | xorg-x11-libXdmcp-32bit | 7.4-1.23               | x86_64
v | openSUSE-11.1-Oss   | zvbi                    | 0.2.33-1.30            | x86_64
suillus2:~ #  

Well, you say the system is up to date, yet you have a long list of updates.

zypper up
will update

FYI:
Once libdvdcss is installed from VLC/libdvdcss, you should disable both those repo’s and do update all unconditionally in Packman.

I tried the zypper update as you suggested, but it doesn’t appear to have made any difference.

But I tried a totally different experiment: on the same machine, I ran the trial version of Kubuntu 8.10, which runs off a DVD. I called k3b and it came up right away with both drives described correctly. I waited for about an hour and then did the same thing again, with the same result: k3b came up right away and was usable. I tested it by copying a CD to an image, and had no trouble with that.

This second experiment seems to confirm what I’ve thought all along: that it’s an OpenSUSE-specific software problem, not a hardware problem.

I was wondering how much you are attached to SUSE? You could always change distros. Or have you used SUSE before 11.1? Say 11.0 - if so, how was it?

I’m very attached to SUSE, but I do have to use Fedora currently on my Box as I had issues with 11.1 - But not related to k3b or cd drives. I considered going back to 11.0 but as I do most of my work on my Laptop, I decided to leave Fedora and actually though it’s Gnome by default, I have kde4.2 on there and it is just great. k/ubuntu I know are popular but it would the last straw for me. You might like Linux Mint (ubuntu based).

But it could be worth a run on 11.0

Actually, I run OpenSUSE on my desktop and Kubuntu on my laptop. I’ve been running SuSE since something like Version 6.0. I like having different systems on different machines, since I can then see the advantages and disadvantages of each.

Now that I have pretty strong evidence that there’s an (obscure) software defect causing my DVD access problems, I’m trying to figure out what to do about it. I don’t remember when the misbehavior started, but I think it was about a year ago. I did have it with 11.0 as well as with 11.1, I think.

Good luck with that, I’ve just started looking in the threads for a slightly different K3B problem than yours, and if I find my problem answered somewhere, then ok, but if I haven’t corrected the problem myself, or if I don’t find my problem already solved somewhere, then I’ll ask for help in a separate thread, but when I bring K3B up, to burn an ISO image of OpenSUSE 11.1, to upgrade from 10.3, it says

“No CD/DVD writer found.
K3b did not find an optical writing device in your system. Thus, you will not be able to burn CDs or DVDs. However, you can still use other K3b features like audio track extraction or audio transcoding or ISO9660 image creation.”

However, when I first installed 10.3, just a day or two ago, switching from Mandriva because of a certain persistent problem with it all of a sudden showing the installation process every time I start my system, when previously I had been using it ok, I was able to play audio CDs, and “rip” CDs, etc., the auto-play worked fine too, but none of those work now for some reason and I have one of these CD/DVD-ROM drives that “supports” LightScribe where you can burn labels unto the CD/DVD.

It also now shows,

“Mp3 Audio Decoder plugin not found.
K3b could not load or find the Mp3 decoder plugin. This means that you will not be able to create Audio CDs from Mp3 files. Many Linux distributions do not include Mp3 support for legal reasons.
Solution: To enable Mp3 support, please install the MAD Mp3 decoding library as well as the K3b MAD Mp3 decoder plugin (the latter may already be installed but not functional due to the missing libmad). Some distributions allow installation of Mp3 support via an online update tool (i.e. SuSE’s YOU).”

That message hadn’t appeared before either, and actually these two messages have “cropped up” after running the security update with the 3 recommended updates that the OpenSUSE Updater said was available.

Of course that may only be a coincidence that these problems have “cropped up” right after running the update, but it makes me wonder if it has anything to do with this “new” problem.

Well back to searching the threads to see if my particular problem has been addressed somewhere,

Bernard