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 ...
Have a n
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 fa
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 take aw
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 <scdbac...@gmx.net> ---
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 in
https://bugs.kde.org/show_bug.cgi?id=257602
--- Comment #32 from Thomas Schmitt <scdbac...@gmx.net> ---
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/gent
https://bugs.kde.org/show_bug.cgi?id=257602
--- Comment #31 from Thomas Schmitt <scdbac...@gmx.net> ---
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 200
https://bugs.kde.org/show_bug.cgi?id=257602
--- Comment #29 from Thomas Schmitt <scdbac...@gmx.net> ---
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
https://bugs.kde.org/show_bug.cgi?id=257602
--- Comment #28 from Thomas Schmitt <scdbac...@gmx.net> ---
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
a
https://bugs.kde.org/show_bug.cgi?id=257602
--- Comment #27 from Thomas Schmitt <scdbac...@gmx.net> ---
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 po
https://bugs.kde.org/show_bug.cgi?id=257602
--- Comment #26 from Thomas Schmitt <scdbac...@gmx.net> ---
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
>
https://bugs.kde.org/show_bug.cgi?id=257602
--- Comment #23 from Thomas Schmitt <scdbac...@gmx.net> ---
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
p
https://bugs.kde.org/show_bug.cgi?id=257602
--- Comment #22 from Thomas Schmitt <scdbac...@gmx.net> ---
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 g
https://bugs.kde.org/show_bug.cgi?id=388120
--- Comment #12 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
your friendly inconspicious mirroring service:
http://scdbackup.webframe.org/kde_bug_388120_file.tar.xz
MD5 0d7eb8debc4b27d9b242cc18b4f7c4e7
The name "file.tar.xz
https://bugs.kde.org/show_bug.cgi?id=257602
--- Comment #19 from Thomas Schmitt <scdbac...@gmx.net> ---
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 runnin
https://bugs.kde.org/show_bug.cgi?id=257602
--- Comment #17 from Thomas Schmitt <scdbac...@gmx.net> ---
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 c
https://bugs.kde.org/show_bug.cgi?id=257602
--- Comment #16 from Thomas Schmitt <scdbac...@gmx.net> ---
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 s
https://bugs.kde.org/show_bug.cgi?id=257602
--- Comment #13 from Thomas Schmitt <scdbac...@gmx.net> ---
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 po
https://bugs.kde.org/show_bug.cgi?id=388120
--- Comment #10 from Thomas Schmitt <scdbac...@gmx.net> ---
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&q
https://bugs.kde.org/show_bug.cgi?id=388120
--- Comment #7 from Thomas Schmitt <scdbac...@gmx.net> ---
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 clea
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #38 from Thomas Schmitt <scdbac...@gmx.net> ---
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).
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #36 from Thomas Schmitt <scdbac...@gmx.net> ---
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 annoy
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #34 from Thomas Schmitt <scdbac...@gmx.net> ---
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
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #30 from Thomas Schmitt <scdbac...@gmx.net> ---
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 rec
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #29 from Thomas Schmitt <scdbac...@gmx.net> ---
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. Chapat
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #27 from Thomas Schmitt <scdbac...@gmx.net> ---
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 wa
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #25 from Thomas Schmitt <scdbac...@gmx.net> ---
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+ne
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #19 from Thomas Schmitt <scdbac...@gmx.net> ---
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
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #17 from Thomas Schmitt <scdbac...@gmx.net> ---
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
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #14 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
@Dr. Chapatin:
Did you verify that your K3B source does have these lines in
in
src/misc/k3bimagewritingdialog.cpp
?
if (d->foundImageType == IMAG
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #13 from Thomas Schmitt <scdbac...@gmx.net> ---
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 an
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #10 from Thomas Schmitt <scdbac...@gmx.net> ---
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 qu
https://bugs.kde.org/show_bug.cgi?id=387765
--- Comment #6 from Thomas Schmitt <scdbac...@gmx.net> ---
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 re
https://bugs.kde.org/show_bug.cgi?id=387765
Thomas Schmitt <scdbac...@gmx.net> changed:
What|Removed |Added
CC||scdbac...@g
https://bugs.kde.org/show_bug.cgi?id=384750
--- Comment #17 from Thomas Schmitt <scdbac...@gmx.net> ---
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
https://bugs.kde.org/show_bug.cgi?id=384750
--- Comment #15 from Thomas Schmitt <scdbac...@gmx.net> ---
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) wh
https://bugs.kde.org/show_bug.cgi?id=384750
Thomas Schmitt <scdbac...@gmx.net> changed:
What|Removed |Added
CC||scdbac...@g
https://bugs.kde.org/show_bug.cgi?id=385667
--- Comment #5 from Thomas Schmitt <scdbac...@gmx.net> ---
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-me
https://bugs.kde.org/show_bug.cgi?id=387599
Thomas Schmitt <scdbac...@gmx.net> changed:
What|Removed |Added
CC||scdbac...@g
https://bugs.kde.org/show_bug.cgi?id=387384
--- Comment #18 from Thomas Schmitt <scdbac...@gmx.net> ---
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 tell
https://bugs.kde.org/show_bug.cgi?id=387384
--- Comment #16 from Thomas Schmitt <scdbac...@gmx.net> ---
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 t
https://bugs.kde.org/show_bug.cgi?id=387384
--- Comment #13 from Thomas Schmitt <scdbac...@gmx.net> ---
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
https://bugs.kde.org/show_bug.cgi?id=387384
--- Comment #12 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
i wrote:
> > - mt = K3b::Device::MEDIA_WRITABLE_DVD;
> > + mt = K3b::Device::MEDIA_WRITABLE_DVD | K3b::Device::MEDIA_WRITABLE_BD;
> >
> > - mt = K
https://bugs.kde.org/show_bug.cgi?id=387384
--- Comment #9 from Thomas Schmitt <scdbac...@gmx.net> ---
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 B
https://bugs.kde.org/show_bug.cgi?id=387384
--- Comment #3 from Thomas Schmitt <scdbac...@gmx.net> ---
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
https://bugs.kde.org/show_bug.cgi?id=386401
Thomas Schmitt <scdbac...@gmx.net> changed:
What|Removed |Added
CC||scdbac...@g
https://bugs.kde.org/show_bug.cgi?id=367639
--- Comment #59 from Thomas Schmitt <scdbac...@gmx.net> ---
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 s
https://bugs.kde.org/show_bug.cgi?id=384471
--- Comment #5 from Thomas Schmitt <scdbac...@gmx.net> ---
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.
https://bugs.kde.org/show_bug.cgi?id=384471
--- Comment #3 from Thomas Schmitt <scdbac...@gmx.net> ---
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-stat
https://bugs.kde.org/show_bug.cgi?id=384471
--- Comment #1 from Thomas Schmitt <scdbac...@gmx.net> ---
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 c
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:
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #82 from Thomas Schmitt <scdbac...@gmx.net> ---
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 38107
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #79 from Thomas Schmitt <scdbac...@gmx.net> ---
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 thi
https://bugs.kde.org/show_bug.cgi?id=384443
--- Comment #3 from Thomas Schmitt <scdbac...@gmx.net> ---
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 m
https://bugs.kde.org/show_bug.cgi?id=384443
Thomas Schmitt <scdbac...@gmx.net> changed:
What|Removed |Added
CC||scdbac...@g
https://bugs.kde.org/show_bug.cgi?id=380067
--- Comment #52 from Thomas Schmitt <scdbac...@gmx.net> ---
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
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #77 from Thomas Schmitt <scdbac...@gmx.net> ---
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 aro
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #76 from Thomas Schmitt <scdbac...@gmx.net> ---
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
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #75 from Thomas Schmitt <scdbac...@gmx.net> ---
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 exec
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #71 from Thomas Schmitt <scdbac...@gmx.net> ---
> Now the qDebug() statements about "Bug 381704" need to be removed.
Oops. Number flip. qDebug() statements about "Bug 381074", of course.
--
You are rec
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #66 from Thomas Schmitt <scdbac...@gmx.net> ---
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
li
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #64 from Thomas Schmitt <scdbac...@gmx.net> ---
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 |
K3
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #63 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
i found a suspect:
https://cgit.kde.org/k3b.git/tree/libk3b/jobs/k3biso9660imagewritingjob.cpp#n232
void K3b::Iso9660ImageWritingJob::startWriting()
{
...
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #62 from Thomas Schmitt <scdbac...@gmx.net> ---
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 wi
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #61 from Thomas Schmitt <scdbac...@gmx.net> ---
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. B
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #57 from Thomas Schmitt <scdbac...@gmx.net> ---
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 comp
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #54 from Thomas Schmitt <scdbac...@gmx.net> ---
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 exec
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #52 from Thomas Schmitt <scdbac...@gmx.net> ---
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-q
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #49 from Thomas Schmitt <scdbac...@gmx.net> ---
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 whi
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #48 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
if you feel adventurous enough: I propose something like
qDebug() << "Bug 381074: wanted: "
<< __PRETTY_FUNCTION__ << d-
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #44 from Thomas Schmitt <scdbac...@gmx.net> ---
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
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #42 from Thomas Schmitt <scdbac...@gmx.net> ---
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.di
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #39 from Thomas Schmitt <scdbac...@gmx.net> ---
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
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #38 from Thomas Schmitt <scdbac...@gmx.net> ---
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 varia
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #34 from Thomas Schmitt <scdbac...@gmx.net> ---
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 stat
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #30 from Thomas Schmitt <scdbac...@gmx.net> ---
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/
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #24 from Thomas Schmitt <scdbac...@gmx.net> ---
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_b
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #22 from Thomas Schmitt <scdbac...@gmx.net> ---
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/attac
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #20 from Thomas Schmitt <scdbac...@gmx.net> ---
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 S
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #18 from Thomas Schmitt <scdbac...@gmx.net> ---
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 th
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #15 from Thomas Schmitt <scdbac...@gmx.net> ---
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 b
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #14 from Thomas Schmitt <scdbac...@gmx.net> ---
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 shal
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #12 from Thomas Schmitt <scdbac...@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%1", deviceStrin
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #11 from Thomas Schmitt <scdbac...@gmx.net> ---
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
https://bugs.kde.org/show_bug.cgi?id=381074
--- Comment #10 from Thomas Schmitt <scdbac...@gmx.net> ---
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
https://bugs.kde.org/show_bug.cgi?id=382941
--- Comment #20 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
some final remarks about the comments:
---
This rumor can be deleted. It is not relevant in a
https://bugs.kde.org/show_bug.cgi?id=382941
--- Comment #19 from Thomas Schmitt <scdbac...@gmx.net> ---
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.k
https://bugs.kde.org/show_bug.cgi?id=382941
--- Comment #17 from Thomas Schmitt <scdbac...@gmx.net> ---
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". Whe
https://bugs.kde.org/show_bug.cgi?id=382941
--- Comment #16 from Thomas Schmitt <scdbac...@gmx.net> ---
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
https://bugs.kde.org/show_bug.cgi?id=383211
--- Comment #8 from Thomas Schmitt <scdbac...@gmx.net> ---
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
https://bugs.kde.org/show_bug.cgi?id=383211
--- Comment #6 from Thomas Schmitt <scdbac...@gmx.net> ---
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.
> plea
https://bugs.kde.org/show_bug.cgi?id=383211
--- Comment #3 from Thomas Schmitt <scdbac...@gmx.net> ---
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 ha
https://bugs.kde.org/show_bug.cgi?id=383211
--- Comment #2 from Thomas Schmitt <scdbac...@gmx.net> ---
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 u
https://bugs.kde.org/show_bug.cgi?id=383140
Thomas Schmitt <scdbac...@gmx.net> changed:
What|Removed |Added
CC||scdbac...@g
https://bugs.kde.org/show_bug.cgi?id=382754
--- Comment #22 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
> https://cgit.kde.org/k3b.git/commit/?id=4a6aa76ea4d80dfdf530921d54060fac3647c9ac
The commit message is quite misleading. I already thought you'd go
full speed ahea
https://bugs.kde.org/show_bug.cgi?id=382754
--- Comment #20 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
Leslie Zhai wrote:
> it needs more detailed feature checker for cdrecord, growisofs, cdrdao
> and other K3bConcreteWriter.
> [...]
> it is better to provide detailed chec
https://bugs.kde.org/show_bug.cgi?id=382754
--- Comment #18 from Thomas Schmitt <scdbac...@gmx.net> ---
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
https://bugs.kde.org/show_bug.cgi?id=382754
--- Comment #15 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
just as technical background info:
libburn underneath cdrskin is well tested since 10 years.
It supports CD data and CD audio, but not the more exotic CD sector
formats, simply bec
1 - 100 of 188 matches
Mail list logo
