[k3b] [Bug 381074] [MATSHITA BD-MLT UJ240AS] Does not write image "debian-8.8.0-amd64-BD-1.iso"

[Thomas Schmitt]

https://bugs.kde.org/show_bug.cgi?id=381074

--- Comment #12 from Thomas Schmitt <scdbackup at gmx.net> ---
Hi,

i have to correct a copy+paste error of mine.
It's not line 691
                return i18n("Please insert an empty medium into
drive<p><b>%1</b>", deviceString);
but line 728

                return i18n( "Please insert an empty medium of size %1 or
larger into drive<p><b>%2</b>",


My theory that the medium was not recognized is dwindling.
STATE_EMPTY means that the medium is blank, not that the tray is empty.
(According to libk3bdevice/k3bdevicetypes.h that would be STATE_NO_MEDIA.)

But the size is told because there is no particular medium type requested,
not because that size was too large for the given medium.

----------------------------------------------------------------------

Now i ended up at the spot where Leslie put a comment in june.
  https://cgit.kde.org/k3b.git/tree/src/k3bemptydiscwaiter.cpp#n146
  K3b::Device::MediaType K3b::EmptyDiscWaiter::waitForDisc

I understand from a comment above
  https://cgit.kde.org/k3b.git/tree/src/k3bemptydiscwaiter.cpp#n189
      if( !d->waitingDone ) {
that this function is called even if a medium is already detected, and
that it should return immediately in this case.
Obviously it does not return.

It looks like the state
  d->waitingDone
changes inside
  https://cgit.kde.org/k3b.git/tree/src/k3bemptydiscwaiter.cpp#n196
  void K3b::EmptyDiscWaiter::enterLoop()
but currently i do not understand how this loop works and were the state
is changed.

Will try to get insight later today. But this looks like C++ idiom which
an old C programmer has difficulties to grasp.


Have a nice day :)

Thomas

-- 
You are receiving this mail because:
You are the assignee for the bug.