https://bugs.kde.org/show_bug.cgi?id=429584
--- Comment #9 from Thomas Schmitt ---
Hi,
Leslie Zhai wrote:
> Lng time no see :)
Hehe. I'm still around, trying to uphold ISO 9660 and burning on free
operating systems. (Just no talent for working on GUIs.)
Stay well and ...
Hav
https://bugs.kde.org/show_bug.cgi?id=429584
Thomas Schmitt changed:
What|Removed |Added
CC||scdbac...@gmx.net
--- Comment #7 from Thomas
https://bugs.kde.org/show_bug.cgi?id=397732
--- Comment #6 from Thomas Schmitt ---
Hi,
Armin Mohring wrote:
> I am using Manjaro with k3b version 18.12.3.
> Now the written data size is reported correctly.
> Solved!
If some code change in K3B caused this improvement, then i fail to
https://bugs.kde.org/show_bug.cgi?id=398190
--- Comment #4 from Thomas Schmitt ---
Hi,
Leslie Zhai wrote:
> Is it better to *remove* the unusual -raw96r option by default, what I mean,
> just set writingMode's default value to TAO or SAO? Welcome suggestion.
Well, we shall not ta
https://bugs.kde.org/show_bug.cgi?id=398190
--- Comment #2 from Thomas Schmitt ---
Hi,
the wodim option -raw96r is unusual and (years ago) was a source of trouble
for me. Any idea how K3B came to think that it is good to use it ?
It is chosen in libk3b/projects/k3bcdrecordwriter.cpp if
d
https://bugs.kde.org/show_bug.cgi?id=397732
--- Comment #2 from Thomas Schmitt ---
Hi,
@Leslie:
I am the backend guy. Operating K3B is not really my turf and my K3B is old.
(But i just pulled the freshest code from git.)
@Armin Mohring:
As far as i can see, the numbers for the progress
https://bugs.kde.org/show_bug.cgi?id=360184
--- Comment #7 from Thomas Schmitt ---
Hi,
guyvf wrote:
> https://en.wikipedia.org/wiki/Hash_function_security_summary
This is about intentional manipulations of checksums, not about their
suitability for detecting incidential transport or stor
https://bugs.kde.org/show_bug.cgi?id=257602
--- Comment #32 from Thomas Schmitt ---
Hi,
i got feedback from Daniel Pielmeier, the Gentoo maintainer of libburn.
He fulfilled my wish to remove the problematic configuration option by:
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id
https://bugs.kde.org/show_bug.cgi?id=257602
--- Comment #31 from Thomas Schmitt ---
Hi,
> [ebuild R] dev-libs/libburn-1.4.8-r1::gentoo USE="track-src-odirect
> -debug -static-libs" 0 KiB
Here we have the trigger which activates my mistake of 2009.
I wonder why no
https://bugs.kde.org/show_bug.cgi?id=257602
--- Comment #29 from Thomas Schmitt ---
Hi,
i can reproduce the cdrskin problem by configuring libburn with option
--enable-track-src-odirect
The bug is a regression from end of 2009 by release 0.7.4, when cdrskin
forgot that it must prepare
https://bugs.kde.org/show_bug.cgi?id=257602
--- Comment #28 from Thomas Schmitt ---
Hi,
if the O_DIRECT theory is correct, then this should work without errno 22
cdrskin --allow_emulated_drives -v dev=stdio:/dev/null fs=32m -eject \
-waiti - <$path
and report as many read bytes
https://bugs.kde.org/show_bug.cgi?id=257602
--- Comment #27 from Thomas Schmitt ---
Hi,
grrr. The waste of your BD-R is to blame on libburn's automatic decision
to handle this burn under the SAO/DAO model: Known track size, as much
write preparations in advance as possible.
Afte
https://bugs.kde.org/show_bug.cgi?id=257602
--- Comment #26 from Thomas Schmitt ---
Hi,
> The error ImgBurn gives me is something like "invalid address for write".
> Other users receiving that error were told it's because of the medium
> quality,
It's probably a
https://bugs.kde.org/show_bug.cgi?id=257602
--- Comment #23 from Thomas Schmitt ---
Hi,
there is still the riddle why ImgBurn on Wine produces mostly failing
results but sometimes succeeds.
An the first glimpse this does not look much like a filesystem format
problem but more likely it is a
https://bugs.kde.org/show_bug.cgi?id=257602
--- Comment #22 from Thomas Schmitt ---
Hi,
> I already have a directory containing a BDMV subtree (and CERTIFICATE).
I can only google for these terms to learn what they mean.
But in general this looks like a good start for exercising the last
st
https://bugs.kde.org/show_bug.cgi?id=388120
--- Comment #12 from Thomas Schmitt ---
Hi,
your friendly inconspicious mirroring service:
http://scdbackup.webframe.org/kde_bug_388120_file.tar.xz
MD5 0d7eb8debc4b27d9b242cc18b4f7c4e7
The name "file.tar.xz" was a bit to general. So i
https://bugs.kde.org/show_bug.cgi?id=257602
--- Comment #19 from Thomas Schmitt ---
Hi,
King_DuckZ wrote:
> Because I'm literally writing an UDF
> 2.5 bluray disk as we speak, through ImgBurn/wine. Windows app or not, it's
> still a userland program running on kernel 4.4
https://bugs.kde.org/show_bug.cgi?id=257602
--- Comment #17 from Thomas Schmitt ---
Hi,
please excuse my clear language in this case:
dev.d...@gmail.com wrote:
> The real problem is, that Linux still is unable to create UDF 2.50 or
> UDF 2.60 images:
When it comes to data storage on o
https://bugs.kde.org/show_bug.cgi?id=257602
--- Comment #16 from Thomas Schmitt ---
Hi,
> That sounds fair, if you guys have an account on librepay or bountyhunter
> let me know and I'll do what I can.
I myself am not hyngry enough for UDF.
As said, the specification is pub
https://bugs.kde.org/show_bug.cgi?id=257602
--- Comment #13 from Thomas Schmitt ---
Hi,
Dkottmair, 2010:
> K3B also can't handle ISOs generated with UDF 2.5 in Nero,
> so you cannot even distribute ready-made Bluray/AVCHD-ISOs for burning!
This should now be possible after Le
https://bugs.kde.org/show_bug.cgi?id=388120
--- Comment #10 from Thomas Schmitt ---
Hi,
Dr. Chapatin wrote:
> https://1drv.ms/u/s!AkEb8acM9pYjghsa_vagLwgBLvZS
After enabling Javascript (i.e. Meltdown and Spectre) it asked me for
my "Microsoft password". But on reload it offered m
https://bugs.kde.org/show_bug.cgi?id=388120
--- Comment #7 from Thomas Schmitt ---
Hi,
Leslie Zhai wrote:
> I have no idea why cdrecord failed to work...
Did cdrecord start at all ?
The log only shows "started" and then complaints begin.
It is not clear to me whether K3b::Aud
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #38 from Thomas Schmitt ---
Hi,
> I noticed that when the ISO file is not recognizable, "Burn image" window
> shows no info about the file despite burning process is successful
> (screenshot).
Ahum. My olde Debian K3B
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #36 from Thomas Schmitt ---
Hi,
> Why "invalid"?
Because it is not an ISO 9660 filesystem, regardless of its suffix ".iso".
Insofar the message of K3B is correct.
If i was annoyed by the dialog window about unrec
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #34 from Thomas Schmitt ---
Hi,
> I just burned the ISO from my link in a CD-RW.
So now our changes reached your desktop.
Next try whether it works with blu-ray sized images too.
> But the warning is not correct and it sho
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #30 from Thomas Schmitt ---
Hi,
just in case somebody wonders: I deleted the uploaded copy of
udf+image+created+with+nero.iso . So the link is now supposed to be dead.
Have a nice day :)
Thomas
--
You are receiving this mail because
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #29 from Thomas Schmitt ---
Hi,
the MD5 checksum matches the one i get here.
Somehow the K3B version of Dr. Chapatin is not the same as the one of Leslie.
The only idea i have is that Leslie instructs Dr. Chapatin how to download
current
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #27 from Thomas Schmitt ---
Hi,
i have put a copy of the image at
http://scdbackup.webframe.org/udf+image+created+with+nero.iso
Have a nice day :)
Thomas
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #25 from Thomas Schmitt ---
Hi,
the given URL seems not to work without Javascript. But i found in
its lengthy HTML this URL
http://download864.mediafire.com/7l3plzb6fzqg/26outwdcybhtzyp/udf+image+created+with+nero.iso
When fetched with
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #19 from Thomas Schmitt ---
Hi,
but mkisofs has no stake in image burning. It _makes_ images.
Are you sure you have chosen the right job in K3B ?
(Normally i'd ask to run the mkisofs command in a shell and to watch for
an abort me
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #17 from Thomas Schmitt ---
Hi,
> Arch Linux, K3b 17.11.90
Google brings me to the page of "k3b 1:17.11.90-1"
https://www.archlinux.org/packages/kde-unstable/x86_64/k3b/
and after some URL manipulation i g
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #14 from Thomas Schmitt ---
Hi,
@Dr. Chapatin:
Did you verify that your K3B source does have these lines in
in
src/misc/k3bimagewritingdialog.cpp
?
if (d->foundImageType == IMAGE_UNKNOWN) {
if (KMessage
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #13 from Thomas Schmitt ---
Hi,
the main riddle now is why the image is not copied to medium after
the warning has been accepted and overridden by the user.
@Leslie:
I propose you create some dummy image file and make test with CDemu
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #10 from Thomas Schmitt ---
Hi,
regardless of the question why K3B does not recognize the image file as
ISO 9660 there stays the question whether and why it then really refuses
to write.
So please answer the question what happened after
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #6 from Thomas Schmitt ---
Hi,
another interesting point is why your image is not recognized as IMAGE_ISO
by K3B.
What do you get from command "file" ?
file /path/to/image/file
The following code reasoning and your mentioni
https://bugs.kde.org/show_bug.cgi?id=387765
Thomas Schmitt changed:
What|Removed |Added
CC||scdbac...@gmx.net
--- Comment #5 from Thomas
https://bugs.kde.org/show_bug.cgi?id=384750
--- Comment #17 from Thomas Schmitt ---
Hi,
> I changed "Formats" to en-US in KDE regional settings
(I wonder how it looks if you choose Inuit or Samaritan Aramaic.)
> progress bars are working now.
So the cheapest, but possibly
https://bugs.kde.org/show_bug.cgi?id=384750
--- Comment #15 from Thomas Schmitt ---
Hi,
> 0,08% done, estimate finish Thu Dec 7 07:05:20 2017
I guess the comma instead of the decimal point is to blame.
It probably stems from internationalization (i18n) which could be a new
feature
https://bugs.kde.org/show_bug.cgi?id=384750
Thomas Schmitt changed:
What|Removed |Added
CC||scdbac...@gmx.net
--- Comment #13 from Thomas
https://bugs.kde.org/show_bug.cgi?id=385667
--- Comment #5 from Thomas Schmitt ---
Hi,
i cannot find the message text "APPENDABLE DATA ERROR" in the current K3B
source. Please post the original message.
Also please post the output of program run
dvd+rw-mediainfo /dev/sr0
when
https://bugs.kde.org/show_bug.cgi?id=387599
Thomas Schmitt changed:
What|Removed |Added
CC||scdbac...@gmx.net
--- Comment #2 from Thomas
https://bugs.kde.org/show_bug.cgi?id=387384
--- Comment #18 from Thomas Schmitt ---
Hi,
Dr. Chapatin wrote:
> K3b should prevent this situation and/or show a better warning when it
> occurs.
At least the little window should not hide parts of the text which tells
which kind of med
https://bugs.kde.org/show_bug.cgi?id=387384
--- Comment #16 from Thomas Schmitt ---
Hi,
Dr. Chapatin wrote:
> On Arch Linux sometimes K3b asks for a "suitable medium" even when an empty
> cd-rw is already inserted.
> Is this situation related to the problem described here?
https://bugs.kde.org/show_bug.cgi?id=387384
--- Comment #13 from Thomas Schmitt ---
Hi,
Aloysius wrote:
> Is that all that is required in case one wanted to backport the fix to 17.08
> and 17.04 ?
Good question. That bug report has a long discussion ...
We have the two occurences in
https://bugs.kde.org/show_bug.cgi?id=387384
--- Comment #12 from Thomas Schmitt ---
Hi,
i wrote:
> > - mt = K3b::Device::MEDIA_WRITABLE_DVD;
> > + mt = K3b::Device::MEDIA_WRITABLE_DVD | K3b::Device::MEDIA_WRITABLE_BD;
> >
> > - mt = K3b::Device::MEDIA_WRITAB
https://bugs.kde.org/show_bug.cgi?id=387384
--- Comment #9 from Thomas Schmitt ---
Hi,
i wrote:
> > dvd+rw-mediainfo /dev/sr0 when the DVD-RW is inserted
Aloysius wrote:
> See attached log.
But https://bugsfiles.kde.org/attachment.cgi?id=109147 is from a BD-RE
medium. My question
https://bugs.kde.org/show_bug.cgi?id=387384
--- Comment #3 from Thomas Schmitt ---
Hi,
it would also be interesting to see whether the DVD-RW medium is formatted.
BD-RE media are always formatted, but DVD-RW can be used unformatted and
then need a blanking run to get re-usable.
Formatted media
https://bugs.kde.org/show_bug.cgi?id=386401
Thomas Schmitt changed:
What|Removed |Added
CC||scdbac...@gmx.net
--- Comment #2 from Thomas
https://bugs.kde.org/show_bug.cgi?id=367639
--- Comment #59 from Thomas Schmitt ---
Hi,
i don't think that bugs 378157 and 386401 are duplicates of 367639.
367639 (and 373523) is about a wrong growisofs option which was used by K3B
because it was not aware of the special needs of BD-R
https://bugs.kde.org/show_bug.cgi?id=384471
--- Comment #5 from Thomas Schmitt ---
Hi,
the new commit looks good to me.
If we do not jump into the adventure of verifying the implicit assumptions
about media types and write modes, then this bug report can be closed.
Have a nice day :)
Thomas
https://bugs.kde.org/show_bug.cgi?id=384471
--- Comment #3 from Thomas Schmitt ---
Hi,
looks ok for me, besides another mistake by me:
K3b::WritingAppCdrdao is not a complete criterion for the need for CD.
The criterion in the code is distributed over two if-statements.
As one statement it is
https://bugs.kde.org/show_bug.cgi?id=384471
--- Comment #1 from Thomas Schmitt ---
Hi,
already the first bug in my bug report. Implemented decision 5 is indeed:
5. If not decided yet: DVD and BD media types.
This seems to assume that all CD use cases are completely covered by the
previous
https://bugs.kde.org/show_bug.cgi?id=384471
Bug ID: 384471
Summary: Media type selection for Image burning is partly
wrong, comments are very wrong
Product: k3b
Version: unspecified
Platform: Other
OS: Linux
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #82 from Thomas Schmitt ---
Hi,
> now in the official patch only a line is edited
> https://cgit.kde.org/k3b.git/commit/?id=a359173975e574c4cae62214f7de28648d14167c
This is not the fix for Bug 381074 but rather the cleanup after t
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #79 from Thomas Schmitt ---
Hi,
the outcome of the sha512sum run indicates full success as far as K3B
is concerned.
This bug is indeed completely done.
Have a nice day :)
Thomas
--
You are receiving this mail because:
You are watching
https://bugs.kde.org/show_bug.cgi?id=384443
--- Comment #3 from Thomas Schmitt ---
I meant "the only sure way to bring BD-RE to full speed".
Some few drives burn at full speed if there is no Spare Area with replacement
blocks.
--
You are receiving this mail because:
You are watchi
https://bugs.kde.org/show_bug.cgi?id=384443
Thomas Schmitt changed:
What|Removed |Added
CC||scdbac...@gmx.net
--- Comment #2 from Thomas
https://bugs.kde.org/show_bug.cgi?id=380067
--- Comment #52 from Thomas Schmitt ---
Hi,
> What do I do now?
About the failure to burn successfully (Bug 380067):
If it happens again, gather experience about which media fail and
which succeed.
We found no evidence that K3B or growisofs are
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #77 from Thomas Schmitt ---
Hi,
forget my first question whether the burn run ended successfully.
I just found
https://bugsfiles.kde.org/attachment.cgi?id=107723
which looks very good. Effective speed around 2x with Defect Management
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #76 from Thomas Schmitt ---
Hi,
i forgot to mention that
dd if=/dev/sr0 count=11223478 bs=2048 | sha512sum
will last about 1200 seconds at average 4x read speed and probably make
some noise when it reaches 6x or 8x speed near the end
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #75 from Thomas Schmitt ---
Hi,
> Help...
I am riddling what we see with your fgrep run.
Did you copy+paste my fgrep line together with my three output lines ?
Somehow the shell "bash" tried to execute the lines which wer
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #71 from Thomas Schmitt ---
> Now the qDebug() statements about "Bug 381704" need to be removed.
Oops. Number flip. qDebug() statements about "Bug 381074", of course.
--
You are receiving this mail because:
Y
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #70 from Thomas Schmitt ---
Hi,
Ja ! I knew it when i saw it ... now in hindsight ... :))
I had gnawed on the code for the wrong task "Data" rather than "Image".
This little shell beauty in my K3B git clone finally g
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #66 from Thomas Schmitt ---
Hi,
> I get lost ... Please tell me to download the commit
Excuse my enthusiasm. :))
And forget about the qDebug() proposal of Comment 62 for now.
Edit file
libk3b/jobs/k3biso9660imagewritingjob.cpp
Th
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #64 from Thomas Schmitt ---
Hi,
if the change in line 264 does not help, try the same in line 252 ff.:
else if( d->isDvdImage )
mt = K3b::Device::MEDIA_WRITABLE_DVD |
K3b::Device::MEDIA_WRITABLE
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #63 from Thomas Schmitt ---
Hi,
i found a suspect:
https://cgit.kde.org/k3b.git/tree/libk3b/jobs/k3biso9660imagewritingjob.cpp#n232
void K3b::Iso9660ImageWritingJob::startWriting()
{
...
else {
mt = K3b::Device
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #62 from Thomas Schmitt ---
Hi,
do we get through this piece of code ?
https://cgit.kde.org/k3b.git/tree/libk3b/projects/datacd/k3bdatajob.cpp#n699
bool K3b::DataJob::waitForBurnMedium()
{
// start with all media types supported
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #61 from Thomas Schmitt ---
Hi,
this qDebug and its "<<" methods are a little debugger on its own.
I would have expected some hex number which we'd need to decipher to
a list of media types. But this is comfortab
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #57 from Thomas Schmitt ---
Hi,
> * k3b_log_file.txt is empty
So those messages came out of stderr, not stdout.
It may be that macro K3B_DEBUG is not defined and thus the qDebug()
statements did not get compiled. Try what happens if
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #54 from Thomas Schmitt ---
Hi,
those warnings are kind of a reminder of a developer who did not
finish his work yet. If no error messages appear, then k3b is probably
ready to run.
But don't ask me where the executable program fi
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #52 from Thomas Schmitt ---
Hi,
> What log?
I can only guess where qDebug() messages show up.
The web talks of "application output". An example on
http://www.qtcentre.org/threads/19534-redirect-qDebug%28%29-to-file
indicat
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #49 from Thomas Schmitt ---
Hi,
there is no need to upload. Just change the code, build K3B, and test what
it reports. If you find the messages in the log, then show them together with
the code piece by which you printed it.
Have a nice
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #48 from Thomas Schmitt ---
Hi,
if you feel adventurous enough: I propose something like
qDebug() << "Bug 381074: wanted: "
<< __PRETTY_FUNCTION__ << d->wantedMediaType
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #44 from Thomas Schmitt ---
Hi,
the changeset is labeled "master". So i assume
git clone git://anongit.kde.org/k3b
or in a cloned directory of git://anongit.kde.org/k3b
git pull
Then build and run with a blank BD-R (check
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #42 from Thomas Schmitt ---
Hi,
we not only need to know the wanted properties but also the properties
which K3B sees as present at that point in the code.
To my understanding that would be:
medium.diskInfo().mediaType
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #39 from Thomas Schmitt ---
Hi,
just to summarize the riddle we are trying to solve:
K3B reports to see an empty BD-R medium but in the same window demands
to get fed by an empty medium of at least 21.4 GiB.
An empty (in SCSI/MMC terms
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #38 from Thomas Schmitt ---
Hi,
@Cristian:
Leslie asks you to run K3B under control of the program gdb, to set a
"breakpoint" at line 257 of k3bemptydiscwaiter.cpp, and to let gdb
print the desired variable content when it stops
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #34 from Thomas Schmitt ---
Hi,
i just did a git pull in my clone from git://anongit.kde.org/k3b.git
and cannot see any related commit by git log.
Can you point me to the changeset which puts the print statements into
the code ?
(My
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #30 from Thomas Schmitt ---
Hi,
are the proposed print commands already in place ?
If so, how would they look ?
Are they supposed to show up in
https://bugs.launchpad.net/k3b/+bug/1713485/+attachment/4940133/+files/JournalErrors.txt
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #24 from Thomas Schmitt ---
Hi,
i am out of ideas, except that Leslie prepares a test version of K3B
by which Cristian can build and test.
It should show the information mentioned in
https://bugs.kde.org/show_bug.cgi?id=381074#c15
I am
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #22 from Thomas Schmitt ---
Hi,
> BD R empty
> https://bugs.kde.org/attachment.cgi?id=107536
Indeed. Unformatted and unused.
Does this medium produce the messages from
https://bugsfiles.kde.org/attachment.cgi?id=106037
when you
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #20 from Thomas Schmitt ---
Hi,
the given BD-R medium is not blank but rather seems to have been
used already with growisofs. Only growisofs formats BD-R to state SRM+POW:
Mounted Media: 41h, BD-R SRM+POW
The first track is
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #18 from Thomas Schmitt ---
Hi,
if there is no simple code change which circumvents that size check,
then you will have to prepare the printing of the decision criteria
for Cristian, so that he can try.
With the data type "Msf&
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #15 from Thomas Schmitt ---
Hi,
@Leslie:
Maybe you can determine the expectations of slotMediumChanged without having
a BD-R medium and drive.
Try by creating a data file of 21.5 GiB size
dd if=/dev/zero bs=2048 count=11272192 of
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #14 from Thomas Schmitt ---
Hi,
Leslie Zhai wrote:
> QEventLoop http://doc.qt.io/qt-5/qeventloop.html
This does not help much with understanding under which circumstances
the particular medium waiting loop shall end.
I searched
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #12 from Thomas Schmitt ---
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%1", deviceString);
but line 728
retur
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #11 from Thomas Schmitt ---
Hi,
the screenshot message
https://bugsfiles.kde.org/attachment.cgi?id=106037
does not really look to me as a complaint about lack of medium space.
It rather looks like the medium is not recognized at all
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #10 from Thomas Schmitt ---
Hi,
i would need to search for the 8.8.0 ISO, because now 9.1.0 is in the
"current" directory at the Debian download site.
Let's have a look at 9.1.0. It should suffice to get the 450 KB Jigdo
https://bugs.kde.org/show_bug.cgi?id=382941
--- Comment #20 from Thomas Schmitt ---
Hi,
some final remarks about the comments:
---
This rumor can be deleted. It is not relevant in any way:
// Some CDs writer
https://bugs.kde.org/show_bug.cgi?id=382941
--- Comment #19 from Thomas Schmitt ---
Hi,
i was not really in patch mood yet, but still in the stage of making up
theories.
Nevertheless, the new commit should really fix the problem.
Mark reports in
https://bugs.kde.org/show_bug.cgi?id=382941
https://bugs.kde.org/show_bug.cgi?id=382941
--- Comment #17 from Thomas Schmitt ---
Hi,
the proposed cdrskin run has a wrong redirection sequence.
It must be
cdrskin -V dev=/dev/sr0 >/tmp/cdrskin_scsi_log 2>&1
(I tested mine with "| less". When changing this to ">
https://bugs.kde.org/show_bug.cgi?id=382941
--- Comment #16 from Thomas Schmitt ---
Hi,
Mark's workaround justifies itself by mere arithmetics. The new "if"
prevents computation from being performed if it would yield 0 or less.
The remaining question is why this computation is m
https://bugs.kde.org/show_bug.cgi?id=383211
--- Comment #8 from Thomas Schmitt ---
Hi,
Leslie, i am crossing fingers for you and your health.
My best wishes. Get well soon.
> Then could I apply Henryk Hecht's patch? sorry for my reading function...
Do it.
Have a nice day :)
Thomas
https://bugs.kde.org/show_bug.cgi?id=383211
--- Comment #6 from Thomas Schmitt ---
Hi,
> I experienced Brain spasm [...]
> I feel really difficult to read and write English
Go see a doctor. A good one, who does what is needed, not just what he can.
> please give me some hint about h
https://bugs.kde.org/show_bug.cgi?id=383211
--- Comment #3 from Thomas Schmitt ---
Hi,
it's too early in the morning. My post needs mending:
> The real size given the fact that growisofs always formats BD-R and that
> all burn programs have to format BD-RE, a hardcoded size seems
https://bugs.kde.org/show_bug.cgi?id=383211
--- Comment #2 from Thomas Schmitt ---
Hi,
> ask Thomas for help :)
Shouldn't that have been "asking Thomas for help" ?
Your statement sounds like you urge Henryk to ask me. But you Cc'ed
me to this bug. So i under stand that
https://bugs.kde.org/show_bug.cgi?id=383140
Thomas Schmitt changed:
What|Removed |Added
CC||scdbac...@gmx.net
--- Comment #1 from Thomas
https://bugs.kde.org/show_bug.cgi?id=382754
--- Comment #22 from Thomas Schmitt ---
Hi,
> https://cgit.kde.org/k3b.git/commit/?id=4a6aa76ea4d80dfdf530921d54060fac3647c9ac
The commit message is quite misleading. I already thought you'd go
full speed ahead without investigating the
https://bugs.kde.org/show_bug.cgi?id=382754
--- Comment #20 from Thomas Schmitt ---
Hi,
Leslie Zhai wrote:
> it needs more detailed feature checker for cdrecord, growisofs, cdrdao
> and other K3bConcreteWriter.
> [...]
> it is better to provide detailed checkSystem at startup, so
https://bugs.kde.org/show_bug.cgi?id=382754
--- Comment #18 from Thomas Schmitt ---
Hi,
In
https://github.com/KDE/k3b/blob/master/src/k3bsystemproblemdialog.cpp
it should not be recorded as CRITICAL if only one of cdrecord or cdrskin
is not usable.
A quick solution would be to report the
1 - 100 of 190 matches
Mail list logo
