https://bugs.kde.org/show_bug.cgi?id=137436
--- Comment #26 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
the whole topic of CD layout beyond CD-ROM and CD-DA was already obscure
legacy when i began to learn about CD burning in 2006. For a while i
asked everybody i could find about rea
https://bugs.kde.org/show_bug.cgi?id=137436
--- Comment #28 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
afaik (hearsay from discussions about video UDF):
On Linux udftools have been superseded by UDF write support in the kernel.
Both are not suitable for DVD video because they
https://bugs.kde.org/show_bug.cgi?id=137436
--- Comment #23 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
to clarify the video topic:
libburn and thus cdrskin and xorriso can write a DVD or BD video image
to the medium. But libisofs and thus xorriso cannot produce that image.
It
https://bugs.kde.org/show_bug.cgi?id=137436
--- Comment #22 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
Leslie Zhai wrote:
> > Mixed mode, CD-XA, and other CD formats are not supported.
> > I think the missing features are covered by cdrdao.
> you mentioned th
https://bugs.kde.org/show_bug.cgi?id=137436
--- Comment #20 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
thank you for considering cdrskin and xorriso.
I have to point to some potential problems:
- libburn underneath both programs does on CD media only pure CD-ROM (data)
or pure
https://bugs.kde.org/show_bug.cgi?id=137436
--- Comment #32 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
i see that i did not explain the blanking issue completely:
On DVD-RW, cdrskin "blank=fast" works like "blank=all".
Only "blank=deformat_sequential_quick
https://bugs.kde.org/show_bug.cgi?id=137436
--- Comment #31 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
Leslie Zhai wrote:
> I need to be faimilar with cdrskin command...
I will try to be of help as good as i can.
> +bool K3b::CdrskinProgram::scanFeatures(ExternalBin
https://bugs.kde.org/show_bug.cgi?id=137436
--- Comment #37 from Thomas Schmitt <scdbac...@gmx.net> ---
Correction: "ATA:1,1,0" is "/dev/hdd", not "/dev/hdc".
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=137436
--- Comment #36 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
looking at
https://cgit.kde.org/k3b.git/commit/?id=0cbea61ca4aa60ce3d6fb2dab67023d5ac8e1e4f
i still riddle about the version dependent feature detector in
libk3
https://bugs.kde.org/show_bug.cgi?id=137436
--- Comment #35 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
> https://bugs.kde.org/attachment.cgi?id=102515
> cdrskin: FAILURE : SCSI command 2Ah yielded host problem: 0x1
> SG_ERR_DID_NO_CONNECT (Could not connect before
https://bugs.kde.org/show_bug.cgi?id=137436
--- Comment #72 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
> It is better to use Clang ThreadSanitizer to detect pthread related issue
I currently see no indication that the problem with CDEmu is related to
pthreads. The logs report o
https://bugs.kde.org/show_bug.cgi?id=137436
--- Comment #63 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
sorry, i did not yet get to installing an Archlinux with CDEmu.
Real life and some other free software obligations ...
cdrskin3.log looks like a full success.
(It becomes mo
https://bugs.kde.org/show_bug.cgi?id=137436
--- Comment #41 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
the growisofs log is very sparse. Are you sure it burned the whole session ?
If i do
dd if=/dev/zero bs=1M count=734 | growisofs -Z /dev/null=/dev/fd/0
i get at least a final m
https://bugs.kde.org/show_bug.cgi?id=137436
--- Comment #43 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
about the newest commit
https://cgit.kde.org/k3b.git/commit/?id=c17d307523a08c1e6042381bdbdfe1971fffc84a
> + bin.addFeature("plain-atapi");
> + bin.addFeature(&qu
https://bugs.kde.org/show_bug.cgi?id=137436
--- Comment #44 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
please run on the command line
dd if=/dev/zero bs=2048 count=375808 | /usr/sbin/cdrskin -v -V dev=/dev/sr1
speed=18 -tao -data -tsize=375808s - 2>&1 | tee -i /tm
https://bugs.kde.org/show_bug.cgi?id=137436
--- Comment #45 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
independently of the failure, there seems to be a bug in the composition
of the cdrskin command.
Both options -sao and -tao were given. -tao prevailed because it came
after -sa
https://bugs.kde.org/show_bug.cgi?id=137436
--- Comment #47 from Thomas Schmitt <scdbac...@gmx.net> ---
Correction: "ERITE" is a tyop. I meant "WRITE".
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=137436
--- Comment #46 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
i am now looking into the source code of growisofs (file transport.hxx).
There is no interpretation of
sg_io_hdr_t.host_status
which in case of the cdrskin run
https://bugs.kde.org/show_bug.cgi?id=137436
--- Comment #67 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
for shorter logs you could try to burn only 100 MB to reduce the number
of logged SCSI commands by abo
https://bugs.kde.org/show_bug.cgi?id=137436
--- Comment #66 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
> https://bugs.kde.org/attachment.cgi?id=102629
> cdrskin-burn-archlinux-iso-debugging-output5.txt
This failed due to the allergy of CDEmu towards SCSI command RESERVE TRACK.
https://bugs.kde.org/show_bug.cgi?id=137436
--- Comment #57 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
> Or the code should in that case select a burning tool that can do that.
> (cdrecord? wodim? cdrdao?
That's well an option with cdrecord or wodim.
cdrdao is not as good
https://bugs.kde.org/show_bug.cgi?id=137436
--- Comment #53 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
the reproducible success on the command line and the reproducible
failure underneath K3B is quite riddling.
Please test whether it still succeeds without option -V
dd if=/dev/z
https://bugs.kde.org/show_bug.cgi?id=137436
--- Comment #54 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
the proposal to let libburn ignore SG_ERR_DID_NO_CONNECT is:
- Download the current cdrskin development tarball
http://scdbackup.sourceforge.net/cdrskin-1.4.7.tar.gz
- Unpack i
https://bugs.kde.org/show_bug.cgi?id=137436
--- Comment #55 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
comments about the newest changeset
https://cgit.kde.org/k3b.git/commit/?id=5213bf69e5a0c1aa0d2115b2bbe851e7294bcbf0
> + d->process << "-tao"/* << &
https://bugs.kde.org/show_bug.cgi?id=137436
--- Comment #70 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
https://bugs.kde.org/attachment.cgi?id=102637
shows a failure around the same address (70+ MiB) as with cdrskin-1.4.6
but with a different reason. This time the ioctl(SG_IO) returned
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
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 #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=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=382754
--- Comment #8 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
the current upstream release of libburn and cdrskin is 1.4.6.
Since then there were not many significant changes in the development
version 1.4.7, which one can derive from
git c
https://bugs.kde.org/show_bug.cgi?id=379268
--- Comment #27 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
K3B indeed wrote the second session:
READ TRACK INFORMATION[#2]:
Track State: complete incremental
Track Start Address: 1991984*2KB
Free Blocks:
https://bugs.kde.org/show_bug.cgi?id=379268
--- Comment #30 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
Łukasz wrote:
> I don't see files from first session at all when mount with -t udf.
Aha. That's like with my kernel if i mount with -t udf, or no -t at all.
> I see them c
https://bugs.kde.org/show_bug.cgi?id=379268
--- Comment #31 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
i just misattributed Łukasz's recent problem list to Leslie.
Sorry for that.
Well, user interface of K3B isn't my turf anyway. Nobody shall take
me serious on that topic.
Neverthel
https://bugs.kde.org/show_bug.cgi?id=379268
--- Comment #21 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
> I always choose pure UDF from the list of options.
Now that's a starting point for Leslie's investigations.
Does K3B, when importing a session, take into respect that it is UDF
https://bugs.kde.org/show_bug.cgi?id=379268
--- Comment #22 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
this search in the K3B code
https://github.com/KDE/k3b/search?utf8=%E2%9C%93=udf=
does not yield any suspect for special treatment of UDF add-on sessions
in K3B.
So it become
https://bugs.kde.org/show_bug.cgi?id=379268
--- Comment #23 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
by copy+paste i crippled my last post.
"as is sual" should have been "as is usual".
The second test for my theory should of course contain a mount comman
https://bugs.kde.org/show_bug.cgi?id=379268
--- Comment #36 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
> > I wonder what mount options it uses at this occasion.
> Perhaps -t udf -o nostrict.
Indeed. This option must cause the second session to be mounted.
When i make th
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=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=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 #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=380064
--- Comment #9 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
i see confusions about DVD and BD speed units and about SI compliant
kB = 1000 bytes versus programmer's KiB = 1024 bytes.
"Writing speed: 5678 KB/s (4,1x)" obviously i
https://bugs.kde.org/show_bug.cgi?id=380067
--- Comment #38 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
i think the new message in
https://cgit.kde.org/k3b.git/commit/?id=41e6f110c7f2753b20537c23bad56b8ac4896ba2
is a bit courageous and makes the user wonder why the message is
e
https://bugs.kde.org/show_bug.cgi?id=380067
--- Comment #40 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
> https://phabricator.kde.org/T6316
says
"You Shall Not Pass: Restricted Maniphest Task
You do not have permission to view this object.
Users with the "Can View"
https://bugs.kde.org/show_bug.cgi?id=380067
--- Comment #45 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
although runs 2 and 3 look good, they show different speed settings
and effective speeds.
Run 2 gets set to 4x, runs a long time at 2x and then suddenly goes to 4x.
Run 3 gets set
https://bugs.kde.org/show_bug.cgi?id=380064
--- Comment #12 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
the strange speed value 4.1x seems to stem from a 1024/1000 confusion
in growisofs.
growisofs_mmc.cpp has:
#define BD_1X 4390// 4495.5 * 1000 / 1024
...
_1x =
https://bugs.kde.org/show_bug.cgi?id=380067
--- Comment #3 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
the end of the log looks like drive and medium had problems with
Defect Management. Up to 70.7 % the run had a normal speed for
2x BD media under Defect Management. Then effective
https://bugs.kde.org/show_bug.cgi?id=380067
--- Comment #5 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
> 2. for fix this bug, I need to change the UI to let user to enable such
> extra options, correct?
I was recently asked whether "User Parameters dialog"
https://bugs.kde.org/show_bug.cgi?id=380067
--- Comment #7 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
i have to correct myself:
The cdrskin option for disabling Defect Management on formatted BD
media is
stream_recording=on
not "off".
Sorry for the confusion.
https://bugs.kde.org/show_bug.cgi?id=380067
--- Comment #15 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
the k3b.log in
https://bugs.kde.org/attachment.cgi?id=106023
looks like a successful burn with growisofs at 2x speed.
(growisofs was told to use 4x speed and the drive says it w
https://bugs.kde.org/show_bug.cgi?id=380067
--- Comment #29 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
most important is to find out whether the drive now burns BD-R reliably.
If you experience failure, please post the growisofs log.
If half a dozen successes in a row happen, then y
https://bugs.kde.org/show_bug.cgi?id=380067
--- Comment #19 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
> :-[ WRITE@LBA=596780h failed with SK=4h/ASC=03h/ACQ=01h]: Input/output error
This is not good news.
SK=4h means "Hardware error". SPC-3 table 27:
"Indicate
https://bugs.kde.org/show_bug.cgi?id=380067
--- Comment #21 from Thomas Schmitt <scdbac...@gmx.net> ---
Thomas
Hi,
> Upgrade firmware?
If there is a newer version than "1.02" it would be worth a try.
But usually you need a MS-Windows system to run the firmware installer
p
https://bugs.kde.org/show_bug.cgi?id=380067
--- Comment #33 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
mkisofs writes:
> This size can only be represented in the UDF filesystem.
> Make sure that your clients support and use it.
although having got among its arguments:
> ..
https://bugs.kde.org/show_bug.cgi?id=380067
--- Comment #34 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
the firmware change obviously had an effect on write speeds.
https://bugsfiles.kde.org/attachment.cgi?id=106049
shows that the drive this time announced the ability for 6x speed,
g
https://bugs.kde.org/show_bug.cgi?id=380067
--- Comment #36 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
> so is it ok to ignore
> the warning about "Found files bigger than 2 GB..." or we can change the
> description?
Yes. The warning is old, at least in
https://bugs.kde.org/show_bug.cgi?id=380067
--- Comment #24 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
"Written data verified" is indeed good news.
Let's hope that this success is repeatable with the next burn runs.
Did the pacifier messages of growisofs report speeds aroun
https://bugs.kde.org/show_bug.cgi?id=380067
--- Comment #26 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
i wrote:
> > Did the pacifier messages of growisofs report speeds around "@2.0x"
> > or did it burn with the speed 4x [...] ?
Cristian Aravena Romero
https://bugs.kde.org/show_bug.cgi?id=380067
--- Comment #27 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
when doing copy+paste i left out a digit "2".
My made-up pacifier line should have looked like
2462121984/20729948160 (11.9%) @4.0x, remaining 18:00 RBU
https://bugs.kde.org/show_bug.cgi?id=379268
--- Comment #40 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
i tested my hack with a large file in the first session.
genisoimage refuses to create a suitable test situation.
mkisofs works even in old version 2.01.01.
genisoimage cannot do
https://bugs.kde.org/show_bug.cgi?id=379268
--- Comment #39 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
i finally found my copy of cdrtools-3.02a05.tar.gz and had a look into
mkisofs/multi.c and mkisofs/udf.c.
There is no member "realsize" in struct directory_entry.
In udf.c
https://bugs.kde.org/show_bug.cgi?id=379268
--- Comment #38 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
Leslie (this time really) wrote:
> You are my mentor forever :)
I'm always interested in new adventures around optical media.
> I must read your investigation care
https://bugs.kde.org/show_bug.cgi?id=379268
--- Comment #46 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
Jonathan Riddell wrote:
> > Not having a CD drive or CD-Rs to test is quite a problem for the k3b
> > maintainer!
Leslie Zhai wrote:
> I think CDEmu is good enoug
https://bugs.kde.org/show_bug.cgi?id=137436
--- Comment #75 from Thomas Schmitt <scdbac...@gmx.net> ---
Hi,
Leslie wrote:
> Rok had fixed it https://sourceforge.net/p/cdemu/bugs/101/
Oh. Now it is probably too tolerant. :))
(RESERVE TRACK may not be used with all media types. According
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=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=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 #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 #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 #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=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=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 #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 #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 #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
Thomas Schmitt <scdbac...@gmx.net> changed:
What|Removed |Added
CC||scdbac...@g
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=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=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=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=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 #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 #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=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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
1 - 100 of 188 matches
Mail list logo
