Fyi, with new Firmware 1.0.5
Version with dinfo[32+4]
[EMAIL PROTECTED] dvd+rw-tools-5.17.4.8.6]# ./testf /dev/scd2
00 20 1e 01 01 01 01 01 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
Version with dinfo[32]
[EMAIL PROTECTED] dvd+rw-tools-5.17.4.8.6]#
Fyi, with new Firmware 1.0.5
...
Version with dinfo[32]
[EMAIL PROTECTED] dvd+rw-tools-5.17.4.8.6]# ./testfno4 /dev/scd2
00 20 1e 01 01 01 01 01 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^^ looking good.
There was one more thing that was brought to Plextor attention (see
Joerg Schilling wrote:
From: F. Poncin [EMAIL PROTECTED]
Fyi, with new Firmware 1.0.5
Version with dinfo[32+4]
[EMAIL PROTECTED] dvd+rw-tools-5.17.4.8.6]# ./testf /dev/scd2
00 20 1e 01 01 01 01 01 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
F. Poncin wrote:
Would you please turn off the receipt requests on your email F. Poncin,
you should NEVER post to a list with such a request.
--
Until later, Geoffrey Registered Linux User #108567
Building secure systems inspite of Microsoft
--
To UNSUBSCRIBE, email to
Fyi, with new Firmware 1.0.5
Version with dinfo[32+4]
[EMAIL PROTECTED] dvd+rw-tools-5.17.4.8.6]# ./testf /dev/scd2
00 20 1e 01 01 01 01 01 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
Version with dinfo[32]
[EMAIL PROTECTED] dvd+rw-tools-5.17.4.8.6]#
Fyi, with new Firmware 1.0.5
...
Version with dinfo[32]
[EMAIL PROTECTED] dvd+rw-tools-5.17.4.8.6]# ./testfno4 /dev/scd2
00 20 1e 01 01 01 01 01 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^^ looking good.
There was one more thing that was brought to Plextor attention (see
From: F. Poncin [EMAIL PROTECTED]
Fyi, with new Firmware 1.0.5
Version with dinfo[32+4]
[EMAIL PROTECTED] dvd+rw-tools-5.17.4.8.6]# ./testf /dev/scd2
00 20 1e 01 01 01 01 01 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
Version with dinfo[32]
[EMAIL
Andy Polyakov wrote:
Fyi, with new Firmware 1.0.5
...
Version with dinfo[32]
[EMAIL PROTECTED] dvd+rw-tools-5.17.4.8.6]# ./testfno4 /dev/scd2
00 20 1e 01 01 01 01 01 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
^^ looking good.
There was one more thing that was brought to Plextor
Joerg Schilling wrote:
From: F. Poncin [EMAIL PROTECTED]
Fyi, with new Firmware 1.0.5
Version with dinfo[32+4]
[EMAIL PROTECTED] dvd+rw-tools-5.17.4.8.6]# ./testf /dev/scd2
00 20 1e 01 01 01 01 01 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
Version with dinfo[32+4]
==
[EMAIL PROTECTED] dvd+rw-tools-5.16.4.8.5]$ ./test /dev/scd0
:-( unable to READ DISK INFORMATION: Input/output error
==
The above program uses READ DISK INFORMATION with length parameter used
by cdrecord.
Version with dinfo[32]
Have you dealt with anyone at Plextor that I might try to explain this to?
No, I have no contact with Plextor. I considered 708 unit when it was
initially released, as they mentioned DVD+MRW support in specification
sheet. But they couldn't clarify what does it really mean in practice
[well,
Andy, what that last error meant is that I was specifying the device the
wrong way (it is /dev/scd0 for me). Anyway, here is the actual result:
Version with dinfo[32+4]
==
[EMAIL PROTECTED] dvd+rw-tools-5.16.4.8.5]$ ./test /dev/scd0
:-( unable to READ DISK INFORMATION: Input/output
Version with dinfo[32+4]
==
[EMAIL PROTECTED] dvd+rw-tools-5.16.4.8.5]$ ./test /dev/scd0
:-( unable to READ DISK INFORMATION: Input/output error
==
The above program uses READ DISK INFORMATION with length parameter used
by cdrecord.
Version with dinfo[32]
, 2004 12:13 PM
To: Thomas J Magliery PhD
Cc: cdwrite@other.debian.org
Subject: Re: plextor px-708uf: cannot get disk type
Version with dinfo[32+4]
==
[EMAIL PROTECTED] dvd+rw-tools-5.16.4.8.5]$ ./test /dev/scd0
:-( unable to READ DISK INFORMATION: Input/output error
Have you dealt with anyone at Plextor that I might try to explain this to?
No, I have no contact with Plextor. I considered 708 unit when it was
initially released, as they mentioned DVD+MRW support in specification
sheet. But they couldn't clarify what does it really mean in practice
[well,
Rob Bogus wrote:
Volker Kuhlmann wrote:
What I meant was those autothingies should keep their hands off a disk
while a burn process is happening. Dunno whether it's possible to detect
this, but isn't that the way it should be?
The burner software can open exclusive - see man open.
After
Andy, sorry this took me so long. I did as you asked. I get the
following message upon running *either* version of the program:
:-( unable to READ DISK INFORMATION: Bad file descriptor
What does this mean? Incidentally, I had a blank DVD+R in the drive.
Is this what you wanted for this
Andy, what that last error meant is that I was specifying the device the
wrong way (it is /dev/scd0 for me). Anyway, here is the actual result:
Version with dinfo[32+4]
==
[EMAIL PROTECTED] dvd+rw-tools-5.16.4.8.5]$ ./test /dev/scd0
:-( unable to READ DISK INFORMATION: Input/output
Rob Bogus wrote:
Volker Kuhlmann wrote:
What I meant was those autothingies should keep their hands off a disk
while a burn process is happening. Dunno whether it's possible to detect
this, but isn't that the way it should be?
The burner software can open exclusive - see man open.
After looking
Andy, sorry this took me so long. I did as you asked. I get the
following message upon running *either* version of the program:
:-( unable to READ DISK INFORMATION: Bad file descriptor
What does this mean? Incidentally, I had a blank DVD+R in the drive.
Is this what you wanted for this test?
From: Ambrose Li [EMAIL PROTECTED]
I just did run a test that verifies that the 708 in fact
returns 36 bytes. So the problem is definitely caused by a
Linux driver bug.
I tend to believe that growisofs just does not check the SCSI
status byte and for this reason is not aware of the
From [EMAIL PROTECTED] Sat Jan 31 16:27:44 2004
The GUI is a user interface and should do for the user what the user
wishes done. Having the volume management (and that term means something
else in most contexts) in the GUI allows the user to control how the
system will behave when a
I am sure that if growisofs would check all relevant information
returned by the driver, it would fail too.
Thomas! Could you run attached program with your /dev/dvd as argument?
Then remove +4 from dinfo declaration, recompile and re-run. To compile
save it in dvd+rw-tools source catalog and
From: Ambrose Li [EMAIL PROTECTED]
I just did run a test that verifies that the 708 in fact
returns 36 bytes. So the problem is definitely caused by a
Linux driver bug.
I tend to believe that growisofs just does not check the SCSI
status byte and for this reason is not aware of the
I am sure that if growisofs would check all relevant information
returned by the driver, it would fail too.
Thomas! Could you run attached program with your /dev/dvd as argument?
Then remove +4 from dinfo declaration, recompile and re-run. To compile
save it in dvd+rw-tools source catalog and
On Sat 31 January 2004 22:46, Volker Kuhlmann wrote:
What I meant was those autothingies should keep their hands
off a disk while a burn process is happening. Dunno whether
it's possible to detect this, but isn't that the way it
should be?
The burner software can open
Lourens Veen wrote:
On Tue 27 January 2004 11:16, Lourens Veen wrote:
On Tue 27 January 2004 08:06, Lourens Veen wrote:
Then there is autofs
(http://freshmeat.net/projects/autofs/?topic_id=142, can't find
a real homepage) and KDE uses fam
Joerg Schilling wrote:
Well, if you do it right, then then the automounter is the wrong
place for this functionality:
- The task os an automounter is to watch where you try to step in.
If you step into some magic land, it opens a door for you.
If you go out of the magic land, the
Volker Kuhlmann wrote:
What I meant was those autothingies should keep their hands off a disk
while a burn process is happening. Dunno whether it's possible to detect
this, but isn't that the way it should be?
The burner software can open exclusive - see man open.
--
E. Robert Bogusta
It
Joerg Schilling wrote:
From: Lourens Veen [EMAIL PROTECTED]
NO, if you like to check for a media change you need to access
the TOC.
Thanks, but that's not what I was asking. What I want to know is, if
I were writing a volume
On Sat 31 January 2004 16:30, Rob Bogus wrote:
Volker Kuhlmann wrote:
What I meant was those autothingies should keep their hands off
a disk while a burn process is happening. Dunno whether it's
possible to detect this, but isn't that the way it should be?
The burner software can open
What I meant was those autothingies should keep their hands off
a disk while a burn process is happening. Dunno whether it's
possible to detect this, but isn't that the way it should be?
The burner software can open exclusive - see man open.
Yes, even better if the burning software
The burner software can open exclusive - see man open.
You mean O_EXCL? That doesn't seem to make sense?
You must be referring to the fact that O_EXCL is essentially undefined
without O_CREAT. It's absolutely true, but it doesn't mean that it's not
passed down to kernel, most notably when
On Sat 31 January 2004 22:46, Volker Kuhlmann wrote:
What I meant was those autothingies should keep their hands
off a disk while a burn process is happening. Dunno whether
it's possible to detect this, but isn't that the way it
should be?
The burner software can open
Joerg Schilling wrote:
From: Lourens Veen [EMAIL PROTECTED]
NO, if you like to check for a media change you need to access
the TOC.
Thanks, but that's not what I was asking. What I want to know is, if
I were writing a volume
On Sat 31 January 2004 16:30, Rob Bogus wrote:
Volker Kuhlmann wrote:
What I meant was those autothingies should keep their hands off
a disk while a burn process is happening. Dunno whether it's
possible to detect this, but isn't that the way it should be?
The burner software can open
What I meant was those autothingies should keep their hands off
a disk while a burn process is happening. Dunno whether it's
possible to detect this, but isn't that the way it should be?
The burner software can open exclusive - see man open.
Yes, even better if the burning software
I just did run a test that verifies that the 708 in fact returns 36 bytes.
So the problem is definitely caused by a Linux driver bug.
I tend to believe that growisofs just does not check the SCSI status
byte
Quoting myself. Under Linux kernel 2.4 growisofs counts on sr_mod to
check the
I just did run a test that verifies that the 708 in fact returns 36 bytes.
So the problem is definitely caused by a Linux driver bug.
I tend to believe that growisofs just does not check the SCSI status
byte
Quoting myself. Under Linux kernel 2.4 growisofs counts on sr_mod to
check
On Fri, Jan 30, 2004 at 02:15:00PM +0100, Andy Polyakov wrote:
Sorry, you repeat useless statements :-(
Does anybody else feel that way?
Surely you've picked up by now that if you're not Joerg you must be
wrong. By definition, I guess... :-(
--
Steve McIntyre, Cambridge, UK.
On Thu, Jan 29, 2004 at 11:28:03AM -0500, Thomas J. Magliery, Ph.D. wrote:
Well, I've played with this for way more than an hour already. Why not?
The folks at linux-usb-devel (i.e., Alan Stern) also want me to recompile my
linux kernel with usb-storage debugging on. So this could take a
On Thu, Jan 29, 2004 at 11:05:41PM +0100, Joerg Schilling wrote:
I just did run a test that verifies that the 708 in fact
returns 36 bytes. So the problem is definitely caused by a
Linux driver bug.
I tend to believe that growisofs just does not check the SCSI
status byte and for this
I just did run a test that verifies that the 708 in fact returns 36 bytes.
So the problem is definitely caused by a Linux driver bug.
I tend to believe that growisofs just does not check the SCSI status
byte
Quoting myself. Under Linux kernel 2.4 growisofs counts on sr_mod to
check the
From [EMAIL PROTECTED] Wed Jan 28 17:11:59 2004
Cdrecord does not squeeze the drive
Did I say that cdrecord squeezes the drive? No! If I wanted to say
Of course you did!
You wrote that growisofs works in contrary to cdrecord besauce it does _not_
squeezes the drive.
This meant that
From [EMAIL PROTECTED] Wed Jan 28 21:01:50 2004
Is there any way at all to check whether a CD is being written
without disturbing the writing process?
NO, if you like to check for a media change you need to access the TOC.
This is why accessing the drive for writing needs to suspend the
On Thu 29 January 2004 12:34, Joerg Schilling wrote:
From [EMAIL PROTECTED] Wed Jan 28 21:01:50 2004
Is there any way at all to check whether a CD is being written
without disturbing the writing process?
NO, if you like to check for a media change you need to access
the TOC.
Thanks, but
From: Andy Polyakov [EMAIL PROTECTED]
Does
this answer mean that cdrecord fundamentally checks some data that is always
going to give me an error,
Let me re-phrase. Growisofs pulls DISC INFORMATION (that's what the
command 0x51 in question does) in a way different from cdrecord, which I
From: Volker Kuhlmann [EMAIL PROTECTED]
Ok, I already said before I consider this matter closed, but someone
doesn't want to get it.
*
* YOU ARE A SPAMMER because you use an illegal mail address
*
This is the most idiotic definition of spammer
From: Lourens Veen [EMAIL PROTECTED]
NO, if you like to check for a media change you need to access
the TOC.
Thanks, but that's not what I was asking. What I want to know is, if
I were writing a volume management system, and I wanted to make
sure it didn't interfere with a write in
From [EMAIL PROTECTED] Thu Jan 29 17:28:18 2004
Would you be willing to do a test with Solaris?
Get the Solaris CD images from:
http://wwws.sun.com/software/solaris/binaries/get.html#x86
for free... installation is simple and takes less than one hour.
If you start with CD 1
On Thu, Jan 29, 2004 at 05:43:46PM +0100, Joerg Schilling wrote:
Note that I always
install Linux in an extedned partition because Linux likes to call a Solaris
Partition a Linux Swap partition. Fortunately, it does not swap on it
immediately if there is no Linux swap signature on it.
That's
On Tue 27 January 2004 11:16, Lourens Veen wrote:
On Tue 27 January 2004 08:06, Lourens Veen wrote:
Then there is autofs
(http://freshmeat.net/projects/autofs/?topic_id=142, can't find
a real homepage) and KDE uses fam
(http://oss.sgi.com/projects/fam/), however I don't think fam
From [EMAIL PROTECTED] Wed Jan 28 17:11:59 2004
Cdrecord does not squeeze the drive
Did I say that cdrecord squeezes the drive? No! If I wanted to say
Of course you did!
You wrote that growisofs works in contrary to cdrecord besauce it does _not_
squeezes the drive.
This meant that
Volker,
I can burn
DVD+Rs using growisofs, but I get the above error with cdrecord-ProDVD.
I can smell a dead simple solution here...
===
The original problem I was trying to solve was to get xcdroast to work,
which requires cdrecord-ProDVD to burn DVDs. I actually had thought of your
True, but having an automounter like autofs would be an easy way of
implementing this, and it has the advantage that it'll also work
from outside of the DE.
Hm, true. Any distro actually using autofs though? SuSE isn't, don't
know about others. Can one assume that people who use the command
The original problem I was trying to solve was to get xcdroast to work,
which requires cdrecord-ProDVD to burn DVDs.
I hear k3b is better anyway? You could try a wrapper script which magles
-prodvd arguments into something useful for growisofs, but I'm unable to
help (no time).
I assume Yes
-a broken drive.
Again, since growisofs works, I doubt this, but perhaps cdrecord avails
itself of some facility that growisofs ignores. Is this the case? In other
words, WHY would growisofs either not have or not be stopped by this error,
while cdrecord is? Recall that cdrecord is
cdrecord development
was then suspended for a while, and Andy Polyakov made dvd+rw-tools
(growisofs) which is mainly meant for DVD+ drives, and is open
source under the GPL.
cdrecord release schedule was never a driving force for dvd+rw-tools, it
was availability of technology and personal
-a broken drive.
Again, since growisofs works, I doubt this, but perhaps cdrecord avails
itself of some facility that growisofs ignores. Is this the case? In other
words, WHY would growisofs either not have or not be stopped by this error,
while cdrecord is? Recall that cdrecord
On Wed 28 January 2004 16:07, Joerg Schilling wrote:
From [EMAIL PROTECTED] Tue Jan 27 21:08:37 2004
Aha, thanks for explaining that. This does pose a bit of a
problem though if you have both: say I insert a CD, then the
volume manager sees it and mounts it. Then I go to my magic
From [EMAIL PROTECTED] Tue Jan 27 21:08:37 2004
Aha, thanks for explaining that. This does pose a bit of a problem
though if you have both: say I insert a CD, then the volume manager
sees it and mounts it. Then I go to my magic automounter directory
and it tries to mount it too. Problem.
From: Volker Kuhlmann [EMAIL PROTECTED]
*
* YOU ARE A SPAMMER because you use an illegal mail address
*
WHEN WILL YOU FINALLY follow the nettiquette?
Note that because you don't follow usual agreements, I usually don't
reply to your mails.
From: Volker Kuhlmann [EMAIL PROTECTED]
that cdrecord-ProDVD
This is commercial binary-only software.
Looks like you confuse binary with commercial.
Or was dvdrecord just some
Red Hat package of cdrecord-ProDVD?
No. Various distributions shipped dvdrecord some while ago, because it
Does
this answer mean that cdrecord fundamentally checks some data that is always
going to give me an error,
Let me re-phrase. Growisofs pulls DISC INFORMATION (that's what the
command 0x51 in question does) in a way different from cdrecord, which I
believe is/offer as the explanation for why
Did I say that cdrecord squeezes the drive? No! If I wanted to say
that, I'd say Unlike cdrecord, growisofs... But I said nothing of that
sort! I said that growisofs asks only for information I consider
required for intended purpose in a colorful way. I was basically
answering Thomas'
It seems that the Sun volume mamager performs a dummy mount for
empty medium and remains quiet until you call eject cd.
Upon CD/DVD media load Solaris volume manager arranges kind of bypass
device entry under /vol and then invokes rmmount. Rmmount analyzes the
media to identify the file system
I assume Yes was the answer to have to do this by hand? Ugh.
Correct, sorry. It's not possible to say in one sentence how to do this,
and I don't know of any howto. Don't do it again... You could look at
files with about the same timestamp and delete those after venturing a
guess whether they
On Wed 28 January 2004 00:28, Volker Kuhlmann wrote:
or whatever. Then when the user actually opens the drive, the
automounter kicks in and it is mounted.
In this case, you simply don't need an automounter, and SuSE
shows that nicely. User wants to open hard disk? - Click
harddisk icon.
Volker,
I can burn
DVD+Rs using growisofs, but I get the above error with cdrecord-ProDVD.
I can smell a dead simple solution here...
===
The original problem I was trying to solve was to get xcdroast to work,
which requires cdrecord-ProDVD to burn DVDs. I actually had thought of your
True, but having an automounter like autofs would be an easy way of
implementing this, and it has the advantage that it'll also work
from outside of the DE.
Hm, true. Any distro actually using autofs though? SuSE isn't, don't
know about others. Can one assume that people who use the command
The original problem I was trying to solve was to get xcdroast to work,
which requires cdrecord-ProDVD to burn DVDs.
I hear k3b is better anyway? You could try a wrapper script which magles
-prodvd arguments into something useful for growisofs, but I'm unable to
help (no time).
I assume Yes
-a broken drive.
Again, since growisofs works, I doubt this, but perhaps cdrecord avails
itself of some facility that growisofs ignores. Is this the case? In other
words, WHY would growisofs either not have or not be stopped by this error,
while cdrecord is? Recall that cdrecord is
cdrecord development
was then suspended for a while, and Andy Polyakov made dvd+rw-tools
(growisofs) which is mainly meant for DVD+ drives, and is open
source under the GPL.
cdrecord release schedule was never a driving force for dvd+rw-tools, it
was availability of technology and personal
On Wed 28 January 2004 16:07, Joerg Schilling wrote:
From [EMAIL PROTECTED] Tue Jan 27 21:08:37 2004
Aha, thanks for explaining that. This does pose a bit of a
problem though if you have both: say I insert a CD, then the
volume manager sees it and mounts it. Then I go to my magic
From: Volker Kuhlmann [EMAIL PROTECTED]
*
* YOU ARE A SPAMMER because you use an illegal mail address
*
WHEN WILL YOU FINALLY follow the nettiquette?
Note that because you don't follow usual agreements, I usually don't
reply to your mails.
that cdrecord-ProDVD
This is commercial binary-only software.
Looks like you confuse binary with commercial.
I believe it's being sold, which makes it commercial. (Note I never
criticized this.) I assume you're not refuting the binary-only.
DVDs. Not quite accurate, but it goes along
It seems that the Sun volume mamager performs a dummy mount for
empty medium and remains quiet until you call eject cd.
Upon CD/DVD media load Solaris volume manager arranges kind of bypass
device entry under /vol and then invokes rmmount. Rmmount analyzes the
media to identify the file system
On Tue 27 January 2004 00:51, Joerg Schilling wrote:
From: Lourens Veen [EMAIL PROTECTED]
On Fri 23 January 2004 20:39, Thomas J Magliery PhD wrote:
Joerg, I only can detect one message in single-user mode, and
it's not too helpful:
Jan 23 14:23:09
Magicdev is a daemon that runs within the GNOME environment and
detects when a CD is removed or inserted. Magicdev handles running
autorun programs on the CD
Ick - insert CD, run a program on it. Sounds like desaster to me.
Thanks for the warning.
I'm using KDE, it's never given any
Joerg, I removed magicdev (rpm -e magicdev) and I *still* got this
error. (Lourens, I also saw this on Google; thanks for the suggestion.)
I removed the file Autorun.desktop from .kde/autostart and this
stopped the kernel/module message. (I probably should have mentioned I
use KDE, not
On Tue 27 January 2004 08:06, Lourens Veen wrote:
Then there is autofs
(http://freshmeat.net/projects/autofs/?topic_id=142, can't find a
real homepage) and KDE uses fam
(http://oss.sgi.com/projects/fam/), however I don't think fam
actually mounts devices by itself, it just watches files. I
From: Lourens Veen [EMAIL PROTECTED]
On Fri 23 January 2004 20:39, Thomas J Magliery PhD wrote:
Joerg, I only can detect one message in single-user mode, and
it's not too helpful:
Jan 23 14:23:09 reganlinux kernel: cdrom: This disc doesn't have
any tracks I
: cannot get disk type
Joerg, I removed magicdev (rpm -e magicdev) and I *still* got this
error. (Lourens, I also saw this on Google; thanks for the suggestion.)
I removed the file Autorun.desktop from .kde/autostart and this
stopped the kernel/module message. (I probably should have
From [EMAIL PROTECTED] Mon Jan 26 23:24:48 2004
Joerg, I removed magicdev (rpm -e magicdev) and I *still* got this
error. (Lourens, I also saw this on Google; thanks for the suggestion.)
I removed the file Autorun.desktop from .kde/autostart and this
stopped the kernel/module message.
From: Lourens Veen [EMAIL PROTECTED]
Package: magicdev (1.1.5-1)
A GNOME daemon for automatically mounting/playing CDs
Magicdev is a daemon that runs within the GNOME environment and
detects when a CD is removed or inserted. Magicdev handles running
autorun programs on the CD, updating the
On Tue 27 January 2004 20:11, Thomas J Magliery PhD wrote:
You might recall from my first emails that I was also getting
this error from within xcdroast, which used the (same) authentic
binary from your site. I didn't realize that the command line
used the RLH9 RPM installation of dvdrecord.
On Tue 27 January 2004 12:06, Joerg Schilling wrote:
From: Lourens Veen [EMAIL PROTECTED]
Package: magicdev (1.1.5-1)
A GNOME daemon for automatically mounting/playing CDs
Magicdev is a daemon that runs within the GNOME environment and
detects when a CD is removed or inserted. Magicdev
On Tue 27 January 2004 21:25, Joerg Schilling wrote:
From: Lourens Veen [EMAIL PROTECTED]
Well, first there was cdrecord, which is GPL. Then DVD writers
appeared, and someone adapted cdrecord to be able to record to
his DVD drive, and called it dvdrecord. He didn't make very
clear that
this was a modified version of cdrecord (or at least not clear
enough as far as Jörg's concerned) which according to Jörg violates
section 2a of the GPL. Hence his calling it illegal.
Yeah, and as far as I am concerned, I'll just ignore Jörg's output on
that topic. He seems to be the only
or whatever. Then when the user actually opens the drive, the
automounter kicks in and it is mounted.
In this case, you simply don't need an automounter, and SuSE shows that
nicely. User wants to open hard disk? - Click harddisk icon. User
wants to open CD? - Click CD icon. I'm sure my mother
On Wed, Jan 28, 2004 at 12:19:17PM +1300, Volker Kuhlmann wrote:
this was a modified version of cdrecord (or at least not clear
enough as far as Jörg's concerned) which according to Jörg violates
section 2a of the GPL. Hence his calling it illegal.
Well, I think it's pretty lame to have
Well, I think it's pretty lame to have done a s/cdrecord/dvdrecord/,
but no s/Cdrecord/Dvdrecord/ in the manpage at least.
Agreed. But as the program is history, there's no point in losing any
more bandwidth over it. Constructive would be to point out that history
bit rather than going into a
Joerg, I removed the RHL9 RPMs of cdrecord, cdrecord-devel and
dvdrecord, and I ran a make INS_BASE=/usr install for cdrtools. I put
the cdrecord-ProDVD binary and a wrapper in /usr/bin. Unfortunately,
again, this makes no difference:
===
[EMAIL PROTECTED] xcdroast]#
I can burn
DVD+Rs using growisofs, but I get the above error with cdrecord-ProDVD.
I can smell a dead simple solution here...
Incidentally, do I
correctly understand that the dvdrecord command no longer exists
You can probably still download it from somewhere. There's no point in
using
From: Lourens Veen [EMAIL PROTECTED]
Well, first there was cdrecord, which is GPL. Then DVD writers
appeared, and someone adapted cdrecord to be able to record to his
DVD drive, and called it dvdrecord. He didn't make very clear that
this was a modified version of cdrecord (or at least not
From [EMAIL PROTECTED] Tue Jan 27 23:13:34 2004
Um, thanks for the info on dvdrecord, but I really need to know (1) why the
program (cdrecord-ProDVD) isn't working and (2) if there is a quick way to
remove cdrtools from /usr/local (see below for both).
The drive works fine for me on Linux
The drive works fine for me on Linux 2.4.10-4GB
Are you using the 708A? Because I'm actually using the 708UF. It's the
same drive, but with a USB2.0/firewire interface. Could the problem be with
USB2.0? Sadly, I don't have a firewire port on this PC, but I can drop in
an Audigy soundcard with
From [EMAIL PROTECTED] Wed Jan 28 00:55:56 2004
The drive works fine for me on Linux 2.4.10-4GB
Are you using the 708A? Because I'm actually using the 708UF. It's the
same drive, but with a USB2.0/firewire interface. Could the problem be with
USB2.0? Sadly, I don't have a firewire port on
On Wed 28 January 2004 00:28, Volker Kuhlmann wrote:
or whatever. Then when the user actually opens the drive, the
automounter kicks in and it is mounted.
In this case, you simply don't need an automounter, and SuSE
shows that nicely. User wants to open hard disk? - Click
harddisk icon.
On Tue 27 January 2004 00:51, Joerg Schilling wrote:
From: Lourens Veen [EMAIL PROTECTED]
On Fri 23 January 2004 20:39, Thomas J Magliery PhD wrote:
Joerg, I only can detect one message in single-user mode, and
it's not too helpful:
Jan 23 14:23:09
1 - 100 of 140 matches
Mail list logo
