Re: cdrtools 2.01.01a73: untaring the archive could not create some hardlinks
Marcus Roeckrath marcus.roeckr...@gmx.de wrote: on untaring the cdrtools source archive I got some errors when tar wasn't able to create some harddlinks. What OS and what tar? GNU tar sometimes has problems with tar archves, I recommend star ftp://ftp.berlios.de/pub/star/ But cdrtools compiles fine. OK Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: GNU isofsmk (was: Re: Announcing mkisofs 1.13)
Robert Millan r...@aybabtu.com wrote: On Sun, Jan 10, 2010 at 12:09:50AM +0100, Joerg Schilling wrote: If you really like to take the outdated mkisofs and play with it, I urge you not to use the name mkisofs for this Next release will be renamed to GNU isofsmk to make sure users won't get confused. You still confuse people by publishing a file called mkisofs-1.13.tar.gz that does not match the checksum from the original at: ftp://ftp.berlios.de/pub/cdrecord/mkisofs/old/mkisofs-1.13.tar.gz Please remove this file from ftp.gnu.org. Note that your tar archive contains a file NEWS that makes incorrect claims: - The software you published does not support files = 4 GB The original mkisofs supports files 4 GB (implemented by me) since 3.5 years. This claim isn't incorrect, but perhaps isn't clear enough: It refers to a limit in the size of the filesystem image itself, rather than its content. Mkisofs supports large files for the file system image since 9 years. Claiming that you added this now does not look like a valid statement. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: cdrtools 2.01.01a73: untaring the archive could not create some hardlinks
Marcus Roeckrath marcus.roeckr...@gmx.de wrote: Hallo Joerg, Am Montag, 25. Januar 2010 15:09 schrieb Joerg Schilling: on untaring the cdrtools source archive I got some errors when tar wasn't able to create some harddlinks. What OS and what tar? Eisfair-Server-Projekt; Kernel 2.4.35 On earlier releases of cdrtools including a72 I never had the problem. I unpacked the cdrtools source twice: once using direct tar command and the second time using mc which I also used yesterday. The error messages occured using mc. mc is known to include a very buggy tar implementation - don't use it. Now I compared the unpacked source trees with diff (cdrtools/cdrtools-2.01.01 unpacked with mc the other unpacked with tar commandline): These are the differences: eis # diff -r cdrtools/cdrtools-2.01.01/ cdrtools-2.01.01 File cdrtools/cdrtools-2.01.01/TARGETS/44libs...@!scg is a regular file while file cdrtools-2.01.01/TARGETS/44libs...@!scg is a directory Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.6
Thomas Schmitt scdbac...@gmx.net wrote: Joerg Schilling: Be careful with libcdio, it is in conflict with the Copyright law and thus cannot be legally distributed. The maintainer admits that it is based on code from cdrtools but the code in question never has been published under a license that would permit a redistribution under GPLv3. You will have to discuss this with the FSF which endorses libcdio as part of its OS software. I am not your enemy and i do not support any infringement of your rights. But your legal quarrels with other open source projects are your private affair, not mine. It seems that you completely missunderstand the background. I am a very liberal person and I am open for liberal OSS. Unfortunately, there are some entities that started to attack OpenSource and as these entities at the same time misuse OSS software, it is obvious that we (the OSS community) need to point to the related infringments. It is up to you to decide whether you like to support these infringments (e.g. by depending on illegal projects) or whether you like to stay legal and only depend on legal software. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.6
Thomas Schmitt scdbac...@gmx.net wrote: It is up to you to decide whether you like to support these infringments (e.g. by depending on illegal projects) or whether you like to stay legal and only depend on legal software. I try to live in good neighborship with FSF and GNU. They gave me a lot during the last 20+ years. I recommend you to live in good neighborship with other OSS projects. Just do not depend on software that was created by people who do not take OSS seriously. Just a hint, there is libscg and libscg still is the only generic SCSI transport lib that grants true portability. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
cdrtools-2.01.01a73 ready
Please test and report! cdda2wav added a lot of new features. The old features are not affected but still the new features need testing. Please note that there is not yet support in cdrecord for *.inf files that are related to a hidden track and called xxx_00.inf. Cdrecord will thus write an additional track and shift all track numbers in case of a CD with hidden audio track. The next cdrecord release will include support for writing hidden tracks in a way that is identical to the original disk. NEW features of cdrtools-2.01.01a73: *** NOTE: cdrtools is currently in a state of a release candidate for the next major release. *** *** All man pages have been rewritten for the upcomming final release ** *** Please read the man pages and report hints and proposals ** All: Libschily: Libparanoia (Ported/enhanced by Jörg Schilling, originated by Monty xiphm...@mit.edu): Libedc (Optimized by Jörg Schilling, originated by Heiko Eißfeldt he...@hexco.de): Libcdrdeflt: Libdeflt: Libfind: Libfile: Libhfs_iso: Libsiconv: Libscg: Libscgcmd: Libmdigest: Rscsi: Cdrecord: - The *.inf file parser now supports a new tag Track= that is intended to carry the absolute track number from the original disk. Cdda2wav (Maintained/enhanced by Jörg Schilling, originated by Heiko Eißfeldt he...@hexco.de): - Cdda2wav now permits to use max for the endtrack number. This allows to specify e.g. -t2+max for a list of tracks from track #2 to the last audio track on the disk. - New option -cuefile allows to tell cdda2wav to create a CDRWIN CUE file. This currently only works together with wither -tall, or with -t0+max or -t1+max. Note that due to a misconception in the CDRWIN CUE file definition, it is impossible to create 100% correct CD-audio copy by 100% following the CDRWIN CUE file definition and having separate audio files for each track at the same time. For this reason, it is currently impossible to create CDRWIN CUE files while using cdda2wav -B. - Cdda2wav now only writes a binary *.cdtext file in case that this file would contain more data than a header that tells that there is no further content. - Cdda2wav no longer removes the Index0 entry from a longer Index list if Index0 is -1. - Cdda2wav now automatically scans for hidden audio tracks. This is a complex task as there are drives that do not allow to read the hidden data before track 1. - New option -no-hidden-track allows to prevent cdda2wav from scanning for a hidden audio track. - Cdda2wav now writes the new tag Track= into the *.inf files that is intended to carry the absolute track number from the original disk. - A shortcut for paraopts=sectors-per-track-1,retries=200 was introduced. The name of the shortcut is proof, so just use paraopts=proof for selecting the most stringent paranoia mode. - Cdda2wav now automatically selects paranoia mode in case that the paraopts= option was used. - Cdda2wav now again works in suid root mode on Solaris 11. It seems that the development versions from Solaris 11 did change the behavior with fine grained privileges in a way that was incompatible with the way cdda2wav did try to handle both suid root and fine grained privileges. Readcd: Scgcheck: Scgskeleton: Btcflash: Mkisofs (Maintained/enhanced by Jörg Schilling since 1997, originated by Eric Youngdale): - The man page for mkisofs was enhanced in order to better mention that mkisofs always writes ISO-9660 and that other file systems are thus always added as a hybrid file system. HELIOS TODO: - Add the HELIOS UNICODE mapping code. This needs to be done at UCS-2 level for Joliet and UDF (instead of UTF-8) and only for Rock Ridge (in case of a UTF-8 based target locale) using UTF-8 based translations. - Make the Apple extensions work again with mkisofs -find TODO: - Support correct inode numbers for UDF hardlinks - Support sockets, pipes, char/blk-dev specials with UDF - read Joliet filenames with multi-session if no TRANS.TBL or RR is present. I am looking for a volunteer for this task! Note that this can never be 100% correct as there is no relation between the names on the master (UNIX) filesystem, the ISO-9660 names and the Joliet names. Only the Rock Ridge names are untranslated with respect to the original files on the master (UNIX) filesystem. - add libecc/edc for CDI and similar. The files are located on: ftp://ftp.berlios.de/pub/cdrecord/alpha ... Jörg --
Re: Announcing cdrskin-0.7.6
Thomas Schmitt scdbac...@gmx.net wrote: Just a hint, there is libscg and libscg still is the only generic SCSI transport lib that grants true portability. Interesting proposal. I got cdrtools-2.01.01a64. Where would i learn about the API for Writing portable software requires thinking in a portable way. It seems that your questions are a result of thinking the wrong way: - Listing drives by their OS device file paths, Not possible with most OS. Most OS do not have something like a device path. - Aquiring and releasing drives, An interesting idea You develop on Linux and you should know that this does not even work on Linux because the people who work on software that claims such features are not interested in a working solution. The related software on Linux is a nightmare but not usable. I tried to get in contact with the related people to no avail. - Obtaining Bus,Lun,Target from device file path, See above: Most OS do not have a device file path - Transporting an SCSI CDB plus eventual payload to an aquired drive and retrieving of eventual payload and sense reply from the drive. This and much more is very simple if you have some basic SCSI skills. Just have a look at cdrecord. Everything you need is in a few basic functions. Does libscg get installed system-wide ? Resp. how should an application link to it ? (Assume that it uses a autotools generated empire of ./configure and make.) If you believe that you have problems with the way you use ./configure and make, you seem to use the wrong build system. I encourage you to upgrade to the schily makefile system. What license would we create from our GPLv2 and your cdrtools license when linking our stuff ? The GPLv2 permits GPLv2 programs to link against and to use any external independent library under any license. so where do you see a problem? Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.6
Thomas Schmitt scdbac...@gmx.net wrote: * Experimental SCSI transport adapter via GNU libcdio 0.83git Be careful with libcdio, it is in conflict with the Copyright law and thus cannot be legally distributed. The maintainer admits that it is based on code from cdrtools but the code in question never has been published under a license that would permit a redistribution under GPLv3. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Linux, ISOFS, multi-extent files: what's the status?
Thomas Schmitt scdbac...@gmx.net wrote: I could not reproduce the bug with anything else but CD TAO tracks. Never with CD SAO, never with DVD. The reason for the TAO problem is known: Two non-data sectors at the end of the announced track size. A simple remedy is not to read the last two sectors of any CD track together with larger read chunks, but to always try to read them separately - if ever needed. I don't like 90% solutions. There are known writers that write up to 15 run out sectors in TAO mode. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: [Cdrecord-support] DVD-RAM
ehab aziz ehab_aziz2...@yahoo.com wrote: Dear all, how can I use the cdrecord with LG DVD-RAM drive. The same way as with other supported media. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Cdrtools-2.01.01a72 ready
NEW features of cdrtools-2.01.01a72: *** NOTE: cdrtools is currently in a state of a release candidate for the next major release. *** *** All man pages have been rewritten for the upcomming final release ** *** Please read the man pages and report hints and proposals ** All: Libschily: Libparanoia (Ported/enhanced by Jörg Schilling, originated by Monty xiphm...@mit.edu): Libedc (Optimized by Jörg Schilling, originated by Heiko Eißfeldt he...@hexco.de): Libcdrdeflt: Libdeflt: Libfind: Libfile: Libhfs_iso: Libsiconv: Libscg: Libscgcmd: Libmdigest: Rscsi: Cdrecord: - The CDRWIN cue sheet parser has been enhanced to give better error messages: - There are now hints on what is missing in the CUE file - The error message now also contains the column where the problem was detected - Allow cdrecord to compile again on a pre-C99 compiler (there was a variable delaration past a statement in a function. - A description for the *.inf file fomat was added to the cdrecord man page - New (previously missing) CD-Text tags have been added to auinfo.c (*.inf file parser): Albumsongwriter= Albumcomposer= Albumarranger= Albummessage= Albumclosed_info= Note that these tags do not appear in the CDDB database. Cdda2wav (Maintained/enhanced by Jörg Schilling, originated by Heiko Eißfeldt he...@hexco.de): - New arg all to -t option. cdda2wav -B extracts all audio tacks into separate files cdda2wav -tall extracts all audio tacks into a single files - cdda2wav now by default writes a file xxx.cdtext with raw binary CD-Text data in case cdda2wav was told to retrieve CD-Text. - A new option -no-textfile allows to disable the creation of the file audio.cdtext This version of cdda2wav creates a file audio.cdtext or similar (depending on the set up file name base) in case that there is CD-Text on the medium and that the drives supports to read the CD-Text data with MMC SCSI commands. - Fixed a bug in cdda2wav that caused cdda2wav to set up the file name base too late. This resultes in the files audio.cdindex and audio.cddb alwas to have this name while the *.inf files use the name base from the cdda2wav arguments. Now all files created by cdda2wav honor the file name base. - Cdda2wav by default fills empty track specific CD-Text data with the Disk global value (if present). A new option -no-textdefaults allows to disable this fallback and leaves the related fields empty if they are empty on the mester CD. - Fixed a problem with cdda2wav -interactive (used by GNOME GSTREAMER CD-DAE plugin) that could cause cdda2wav to dump core in case that there is a data session past the last audio track. - New (previously missing) CD-Text tags have been added to the *.inf files: Albumsongwriter= Songwriter= Albumcomposer= Composer= Albumarranger= Arranger= Albummessage= Message= Albumclosed_info= Closed_info= Note that these tags do not appear in the CDDB database. Readcd: Scgcheck: Scgskeleton: Btcflash: Mkisofs (Maintained/enhanced by Jörg Schilling since 1997, originated by Eric Youngdale): - Fixed a bug with file descriptor handling in mkisofs/apple.c HELIOS TODO: - Add the HELIOS UNICODE mapping code. This needs to be done at UCS-2 level for Joliet and UDF (instead of UTF-8) and only for Rock Ridge (in case of a UTF-8 based target locale) using UTF-8 based translations. - Make the Apple extensions work again with mkisofs -find TODO: - Support correct inode numbers for UDF hardlinks - Support sockets, pipes, char/blk-dev specials with UDF - read Joliet filenames with multi-session if no TRANS.TBL or RR is present. I am looking for a volunteer for this task! Note that this can never be 100% correct as there is no relation between the names on the master (UNIX) filesystem, the ISO-9660 names and the Joliet names. Only the Rock Ridge names are untranslated with respect to the original files on the master (UNIX) filesystem. - add libecc/edc for CDI and similar. The files are located on: ftp://ftp.berlios.de/pub/cdrecord/alpha ... Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to
Re: Announcing a fork from mkisofs
Robert Millan r...@aybabtu.com wrote: So if you'd like to create a GRUB bootable disk, you'd do something like: cat boot.img core.img tmp mkisofs --embedded-boot tmp -o grub.iso -r somedir Of course, if you put together all the details (like building core.img and filling up /boot/grub structure), it gets a bit hairy, so grub-mkrescue utility is provided with GRUB: There is no need to implement such a nonstandard thing as mkisofs allows you to call: mkisofs -V $volid -o xxx.iso -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 -boot-info-table somedir What benefit do you see from using your proposal? What benefit do you see from not collaborating with the cdrtools project? Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Linux, ISOFS, multi-extent files: what's the status?
Giulio giul...@gmail.com wrote: I'd like to understand what are the pitfalls, if any, in using multi-extent files, as enabled by mkisofs --iso-level 3 option for files larger than 4GiB-2, on Linux. I'm using - mkisofs 2.01.01a69 - kernel 2.6.18-164.9.1.el5 (RHEL5) When I started to implement support for multi-extent files in Summer 2006 in mkisofs, Linux had a problem with reading multi-extent files that are not a multiple of 2048 bytes. IIRC, this problem disappeared in 2007 already. BTW: IIRC, I received an I/O error for the last read before the bug was fixed. I had made some tests and it seemed to me the kernel I was using was OK. However, yesterday I read Thomas Schmitt message http://lists.debian.org/cdwrite/2010/01/msg00072.html ..My 2.6.18 swallows the last few bytes if the file size is not a multiple of 2048 I don't know what Thomas Schmitt's intentions are, so I cannot comment why he did send his statement... So I looked the git history for isofs/inode.c. Kernel 2.6.18 was released on 2006-09-20. Then on 2009-09-27 this patch was applied [PATCH] I/O Error attempting to read last partial block of a file in an ISO9660 file... http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6-stable.git;a=commit;h=fb50ae7446abb35184be029c51f825e45a4e0670 which seems to have to do with multi-extent files. This patch is not in the RHEL5 kernel, so it should still has this defect. I don't see any other relevant patch in the inode.c history log http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6-stable.git;a=history;f=fs/isofs/inode.c;h=6b4dcd4f2943e632c9d89115a2395084be95adc5;hb=HEAD === This perfectly fits to the problem I have in mind, so it seems that the bug was fixed long time ago. Are you sure that your kernel really does not include the patch? Still, this simple test shows the file is read back OK on RHEL5 2.6.18 kernel; the file is larger than 4GiB-2 and not multiple of 2048: - dd if=/dev/urandom of=filetest bs=100 count=4300 mkisofs -quiet --iso-level 3 -o test.iso filetest sudo mount -o loop test.iso /mnt/cdrom md5sum /mnt/cdrom/filetest md5sum filetest (the 2 md5sum come back the same) - How can I test multi-extent file hadling effectively? I have to stay on RHEL5 kernel I cannot patch or upgrade the kernel. You verified that there currently is no such problem. The only real problem on Linux I am currently aware of is the missing support for hard links in the Linux filesystem implementation. This does however not cause inconsistent data but just makes tar believe that there is no hard link when you try to make a tar archive from a ISO-9660 filesystem with RR. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Linux, ISOFS, multi-extent files: what's the status?
Giulio Orsero giul...@gmail.com wrote: On Sat, 09 Jan 2010 13:07:25 +0100, joerg.schill...@fokus.fraunhofer.de (Joerg Schilling) wrote: Giulio giul...@gmail.com wrote: I'd like to understand what are the pitfalls, if any, in using multi-extent files, as enabled by mkisofs --iso-level 3 option for files larger than 4GiB-2, on Linux. When I started to implement support for multi-extent files in Summer 2006 in mkisofs, Linux had a problem with reading multi-extent files that are not a multiple of 2048 bytes. IIRC, this problem disappeared in 2007 already. BTW: IIRC, I received an I/O error for the last read before the bug was fixed. RHEL5's 2.6.18 kernel originated in 2006, so we are in that time frame. Well, if you can read files 4 GB correctly, it may be that the problem has been fixed in a different way. is there any patch related to iso9660 in your kernel? This perfectly fits to the problem I have in mind, so it seems that the bug was fixed long time ago. Are you sure that your kernel really does not include the patch? Yes, the RHEL5 kernel hasn't got the patch and the patch applies cleanly to it. This is why I'm worried. I was about starting using files 4GB w/o splitting them, my tests were OK, but now I'm worried I may find some corner cases I don't know how to test beforehand. If you tested content and readability, you seem to have made a 100% test. A content verification needs to make sure that the parts 4 GB have different content than anything in the file before. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing mkisofs 1.13
Robert Millan r...@aybabtu.com wrote: On Fri, Jan 08, 2010 at 05:30:09PM +0100, Joerg Schilling wrote: You also do not mention that the even outdated version of mkisofs you are using contains code from me. This is true (at least for files prototyp.h, fctldefs.h, statdefs.h and mconfig.h where your name appears). It's not my intention at all to neglect your contribution, it just happens that I didn't have all the information. If you're so kind to provide a short summary of your improvements in that version, I'll be glad to add your name in AUTHORS file and give proper recognition. What is the reason for creating a fork from a completely outdated and extremely buggy historic version of mkisofs? Please note that I am constantly contributing to the mkisofs project since Spring 1996 and that the first mkisofs version published by Eric Youngdale with a contribution from me was mkisofs-1.10b7-no_ac from February 1997. I remember that my first contribution (in Spring 1996) was the correction of the timezone offset and that e.g. the option -print-size is from me. As many years have past since then, I of course cannot name _all_ contributions anymore. Since Autumn 1999, I am the official primary maintainer and for this reason, the mkisofs that comes with cdrtools is _no_ fork but the original version. There was an official mkisofs-1.13 publishec in June 2000 and you obviously created a clash. If you really like to take the outdated mkisofs and play with it, I urge you not to use the name mkisofs for this and I urge you to withdraw your tar archive from the ftp server as long as you use the original name mkisofs. Note that your tar archive contains a file NEWS that makes incorrect claims: - The software you published does not support files = 4 GB The original mkisofs supports files 4 GB (implemented by me) since 3.5 years. - The software you published contains an extremely outdated Eltorito support. The original mkisofs supports nearly all Eltorito featues (implemented by me) and this is what people today use to create bootable CDs (e.g. for GRUB). If you believe that the current original mkisofs (see ftp://ftp.berlios.de/pub/cdrecord/alpha/) is missing important features, please collaborate with the cdrtools project. The cdrtools project is open for everyone and this is one of the reasons why cdrtools ports to 30 different platforms (not counting different CPUs as different platform). From looking at your tar archive, it seems that you may have some skills with localization (text ranslations) or that you know translators. As the next development cycle of cdrtools will very soon introduce localized strings for all commands, I am looking for translators So are you interested to contribute and to collaborate? Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing mkisofs 1.13
Robert Millan r...@aybabtu.com wrote: I'm proud to announce the release of GNU mkisofs version 1.13. Could you please explain this? Do you like to confuse people with outdated software? This looks like complete nonsense. The official mkisofs is part of cdrtools since a long time and the official mkisofs that is part of cdrtools has major enhancements compared to the completely outdated stuff you present! Also note that there was an official mkisofs with version number 1.13 that has been published on July 20th 2000. This release implements a few new features relative to the previous one (mkisofs 1.12b5). But most importantly, the codebase has been updated to modern standards and the build system has been rewritten from scratch using recent GNU autotools. 1.12b5 was full of bugs. It seems that you like to fool people with buggy software. Well, your source does not even compile As this is the first release of GNU mkisofs in more than 10 years, some explanation is in order: This program was initially written for the GNU system in 1993, by Eric Youngdale, who maintained it up untill 1997. Shortly afterwards, a derivative of GNU mkisofs was incorporated into cdrtools, the CD/DVD recording package. In 2006, the cdrtools version of mkisofs spawned another fork: genisoimage, which was included as part of cdrkit package in the Debian GNU/Linux distribution. You are wrong! The mkisofs in cdrtools is _not_ a fork but the official release. You also do not mention that the even outdated version of mkisofs you are using contains code from me. If you really like to start a project on completely outdated sources, use a different name! Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing mkisofs 1.13
Til Schubbe li...@lists.schubbe.org wrote: Well, your source does not even compile At least it compiles on my machine. Nobody is interested in software from 1997 and with only the features from 1997. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: NO SEEK COMPLETE: Input/output error when burning DVD+R DL
Mark Ryden markr...@gmail.com wrote: I have dvd+rw-tools-7.1-3; I try to burn a file which 6GB in size; my burner does support DVD+R DL, and I have DVD+R DL media. I try: growisofs -dvd-compat -speed=2 -Z /dev/sr0=/setup/myFile.iso Executing 'builtin_dd if=/setup/myFile.iso of=/dev/sr0 obs=32k seek=0' /dev/sr0: splitting layers at 1644752 blocks :-[ SEND DVD+R DOUBLE LAYER RECORDING INFORMATION failed with SK=3h/NO SEEK COMPLETE]: Input/output error Any ideas what is the problem and how to overcome it ? Did you try cdrecord? ftp://ftp.berlios.de/pub/cdrecord/alpha/ What do you get from cdrecord -atip? Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: NO SEEK COMPLETE: Input/output error when burning DVD+R DL
Mark Ryden markr...@gmail.com wrote: (The cdrecord I have is part of the wodim feodra 11 package, of wodim-1.1.9-6.) What do you get from cdrecord -atip? here: (BTW:does the fact that it doesn't mention DL has a significance here ? ) cdrecord -atip Device was not specified. Trying to find an appropriate drive... Detected CD-R drive: /dev/cdrw Using /dev/cdrom of unknown capabilities Device type: Removable CD-ROM Version: 5 Response Format: 2 Capabilities : Vendor_info: 'Optiarc ' Identification : 'DVD RW AD-7170A ' Revision : '1.02' Device seems to be: Generic mmc2 DVD-R/DVD-RW. Using generic SCSI-3/mmc DVD-R(W) driver (mmc_mdvd). Driver flags : SWABAUDIO BURNFREE Supported modes: PACKET SAO I asked you to use _cdrecord_ and not the defective and illegal fork wodim. Please use the original cdrecord as wodim does not support to write DVDs. Cdrecord is here: ftp://ftp.berlios.de/pub/cdrecord/alpha/ Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: NO SEEK COMPLETE: Input/output error when burning DVD+R DL
Mark Ryden markr...@gmail.com wrote: Sorry for the misunderstanding ! wodim was simply installed on my system. I had downloaded from cdrecord ftp://ftp.berlios.de/pub/cdrecord/alpha/. Now, if I may ask, what is the sytax for burning a 6GB file named setup/myFile.iso? cdrecord -v -sao filename.iso the output of ./cdrecord -atip (with the new downlaoded, **non** wodim cdrecord) is different, and it is here below: Cdrecord-ProDVD-ProBD-Clone 2.01.01a71 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2010 J???rg Schilling Linux sg driver version: 3.5.34 Using libscg version 'schily-0.9'. No target specified, trying to find one... Using dev=2,0,0. Device type: Removable CD-ROM Version: 5 Response Format: 2 Capabilities : Vendor_info: 'Optiarc ' Identifikation : 'DVD RW AD-7170A ' Revision : '1.02' Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. Using generic SCSI-3/mmc-3 DVD+R driver (mmc_dvdplusr). Driver flags : NO-CD DVD MMC-3 SWABAUDIO BURNFREE Supported modes: PACKET SAO LAYER_JUMP ./cdrecord: Warning: Cannot read drive buffer. ./cdrecord: Warning: The DMA speed test has been skipped. book type: DVD-ROM, Version (0.1) disc size: 120mm (0) maximum rate:Not specified (15) number of layers:2 track path: Opposite Track Path (1) layer type: Rewritable Area (2) linear density: 0.293 ???m/bit (1) track density: 0.74 ???m/track (0) phys start: 196608 (0x3) phys end:16580607 end layer 0: 2283519 bca: 0 phys size:...16384000 layer break at: 2086912 Category/Version E1 Disk size 0F Disk structure32 Recoding density 10 Manufacturer: 'CMC MAG' Media type: 'D03' Product revision 64 ADIP numbytes 64 Reference speed 37 Max speed 37 L0 init status: 1 L0 data areacap: 1644752 rzone size: 52 rzone number: 1 border number: 1 ljrs: 0 track mode: 7 copy: 0 damage: 0 reserved track: 0 blank: 1 incremental: 0 fp: 0 data mode: 1 lra valid: 0 nwa valid: 1 rzone start:0 next wr addr: 0 free blocks:3289504 blocking factor:16 rzone size: 3289504 last recorded addr: 0 read compat lba:0 next layerjmp addr: 0 last layerjmp addr: 0 Capacity Blklen/Sparesz. Format-type Type 2295104 2048 0x00 No Media Present or Unknown Capacity This looks a bit strange and it may be that growisofs did already destroy the medium (*). Could you try a new mainden medium for this command? *) If you check the cdrecord output, you see that somebody did set the layer break already. Looking at the numbers lets me asume that growisofs did set up an incorrect layer break value. Another point is that the brand CMC is konwn for low quality media, if it does not help to use cdrecord instead of growisofs, I recommend to try Verbatim media. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: NO SEEK COMPLETE: Input/output error when burning DVD+R DL
Mark Ryden markr...@gmail.com wrote: Hello, I failed to burn it with the It could be that the media is not OK; I will try later today to burn with another media, as I don't have another media handy. running: ./cdrecord -v -sao /setup/myiso.iso gave: Cdrecord-ProDVD-ProBD-Clone 2.01.01a71 (x86_64-unknown-linux-gnu) Copyr TOC Type: 1 = CD-ROM Linux sg driver version: 3.5.34 Using libscg version 'schily-0.9'. SCSI buffer size: 32768 No target specified, trying to find one... Using dev=2,0,0. atapi: 1 Device type: Removable CD-ROM Version: 5 Response Format: 2 Capabilities : Vendor_info: 'Optiarc ' Identifikation : 'DVD RW AD-7170A ' Revision : '1.02' Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. Current: DVD+R/DL Profile: DVD+R/DL (current) Profile: DVD+R Profile: DVD+RW Profile: DVD-R/DL layer jump recording Profile: DVD-R/DL sequential recording Profile: DVD-RW sequential recording Profile: DVD-RW restricted overwrite Profile: DVD-RAM Profile: DVD-R sequential recording Profile: DVD-ROM Profile: CD-RW Profile: CD-R Profile: CD-ROM Profile: Removable Disk Using generic SCSI-3/mmc-3 DVD+R driver (mmc_dvdplusr). Driver flags : NO-CD DVD MMC-3 SWABAUDIO BURNFREE Supported modes: PACKET SAO LAYER_JUMP Drive buf size : 1015808 = 992 KB ./cdrecord: Warning: Cannot read drive buffer. ./cdrecord: Warning: The DMA speed test has been skipped. FIFO size : 4194304 = 4096 KB Track 01: data 6424 MB Total size: 6424 MB = 3289486 sectors Current Secsize: 2048 Blocks total: 16580607 Blocks current: 16580607 Blocks remaining: 13291 Starting to write CD/DVD/BD at speed 1 in real SAO mode for single sess Last chance to quit, starting real write0 seconds. Operation starts Waiting for reader process to fill input buffer ... input buffer ready. ./cdrecord: Layer 0 zone capacity already set. ./cdrecord: Cannot open next track. Writing time:0.014s Average write speed 999.0x. Fixating... ./cdrecord: Input/output error. close track/session: scsi sendcmd: no e CDB: 5B 01 01 00 00 01 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 05 00 00 00 00 0A 00 00 00 00 30 05 00 00 Thank you for the log, it seems that I need to find a way to abort the process in this case without trying to close the session. This media cannot be written to anymore except when you hack the writing software and when you have an amount of data that matches the already set up layer break. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: cdrkit 1.1.10 fails to locate libcap
Norbert Preining prein...@logic.at wrote: OpenSuSE 11.2 distributes cdrkit. OpenSuSE 11.2 distributes cdrtools. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: how to rescue this backup data
Zhang Weiwu zhangwe...@realss.com wrote: But then why mount would not work? Jamaica:~ # mount /dev/sr1 /mnt/ mount: block device /dev/hdc is write-protected, mounting read-only mount: wrong fs type, bad option, bad superblock on /dev/hdc, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so If the medium was ever written correctly in multi-border mode, then even a dumb kernel should be able to mont the first session. Jamaica:~ # dmesg | tail wlan0: authenticate with AP 00:25:86:01:8a:de wlan0: authentication with AP 00:25:86:01:8a:de timed out grow_buffers: requested out-of-range block 18446744073708710576 for device hdc UDF-fs: No anchor found UDF-fs: No partition found (1) UDF-fs: No anchor found UDF-fs: No partition found (1) Did you run isodebug -i input-file for the medium? If it does not print something like: ISO-9660 image includes checksum signature for correct inode numbers. ISO-9660 image created at Mon Jan 4 14:33:10 2010 Cmdline: '2.01.01a71 -o ooo OBJ' the images have not been created with mkisofs and for this reason, there may be an incorrect UDF hybrid filesystem on the medium. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: cdrkit 1.1.10 fails to locate libcap
Norbert Preining prein...@logic.at wrote: On Sa, 02 Jan 2010, Joerg Schilling wrote: Cdrkit is undistributable as it is in conflict with the GPL and the Copyright law. Cdrkit is unmaintained since May 6th 2007, so why do you ask for cdrkit? 1. This is a mailing list for CD/DVD writing, not for your personal enjoyment. There are other cd burning programs, and it is valid to ask here. Please stop your hostile trolling, this is a mailing list to discuss CD/DVD/BD writing and you did never write anything that was helpful for this topic. 2. Please provide proofs that it is undistributable, or start a suit case if you are sure that it is in conflict with Copyright law. The proof for my statements is on my website, there os no need to repeat my statements at nauseum. The fact that you ingnore facts is irrelevant and just proves that your only interest is trolling. Note that your mails are called Verleundung unless you _prove_ your claims with facts. So stop mailing or finally prove that the Debian fork is _not_ in conflict with the GPL and not in conflict with the Copyright law. If you continue like that I will request to list master to ban you from this and other lists hosted here. I hope that I don't need to ask to ban you, as you are a person that is only known for frequent trolling. So take care and unless you have something substanceful stop posting to this list. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Wodim: How to read from stdin?
Bill Davidsen david...@tmr.com wrote: This is a limitation of cdrecord and programs derived from it. The growisofs program knows how to do this for DVD but can not do it for CD (one of my problems). In your case you can know the size of the image in advance because you have it. In fact, I wonder why you don't just burn it direct. Growisofs does not write in SAO mode, this is the reason why it can do things that do not work the easy way on SAO mode. In my case I have a data stream of 400-500MB which I wish to burn to CD, but because I can't know the size in advance and don't wish to save it for reasons I won't detail, I am forced to use growisofs and DVD for these little data sets. You are of course not forced to use growisofs. Cdrecord will work for you too if you use it the right way... there is e.g. the -stream-media-size size option for mkisofs and there are plenty of other methods. Mr Schilling noted that there seems a way to do this in some modes, but he provides no information on it. He's probably right that it could be done, but doesn't want ot say how for whatever reason. Sorry, but this is nonsense. The way it can be done is obvious to anyone with some basic skills in CD/DVD/BD writing. The reason why it is not yet implemented in cdrecord is just that there are many more important things to do and that it would not work on all 30+ platforms that cdrecord supports. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: cdrkit 1.1.10 fails to locate libcap
Mark Rosenstand rosenst...@gmail.com wrote: Cdrkit is undistributable as it is in conflict with the GPL and the Copyright law. Cdrkit is unmaintained since May 6th 2007, so why do you ask for cdrkit? The 1.1.10 source package on ftp.debian.org is dated just over a month ago, but yeah, it's unfortunate that it hasn't hit the upstream download area yet. Latest stable release of cdrtools seems to be from 2004 though. The fact that somebody creates new versions does not proof that there is some kind of maintenance. During the last 2.5+ years, there was much less changes in the fork than in a very lazy week of development on cdrtools. There are still more than 100 well known bugs in the fork that do not get fixed. Given the fact that most of these bugs could be fixed in much less than one hour each, it is obvious that the people behind cdrkit do not care about users Cdrkit users are on a dead end, there are no bug fixes and there is no development. I recommend you to use the original software from ftp://ftp.berlios.de/pub/cdrecord/alpha/ I've been using cdrecord for years before cdrkit appeared, but with cdrkit being what most Linux distros package these days, I just go with the flow, as it means less work/headscratching for me in the long run. Well, you are a user and you could ask your Linux distributor why he distributes unmaintained software with legal problems instead of well maintained original software with no legal problems. Given the fact that there have been many new features added to cdrtools since the time some people created the fork, I'm maintaining all packages myself, so the totally non-standard build system in cdrtools is a big minus, especially since pretty much all the default paths, permissions, and even ownership are different from what's casual on Linux systems today. When you have over 1400 source packages to maintain, automation is key. (Sorry, I don't use any of your other software, so I can't justify the time it will take to automate it.) Well, cdrtools uses a standard leading edge build system. The fact that is has extreme similarities to the build system created by David Korn that is written on top of a new make utility nmake but uses the same ideas of just having a list of source files in the leaf makefiles verifies that it uses the right basic ideas. In contrary to other build systems, it grants out of the box compilation on 30+ platforms. It may be that you are not flexible enough to lean new software and that you just not notice that many of the OSS packages that use different build systems just do not compile even on major platforms like Solaris without manually changing significant parts. And BTW: if you like automation, you should already know the advantages of the schily makefilesystem as you just need to call smake. The other packages you may be talking about, force you to call configure manually and usually do not even compile unless you find out some magic parameters you need to add to the configure call in order to get a usefull autoconf result. It may be that you are a victim of the Stickholm syndrom and like what punishes you ;-) There are no known problems with the original software and the original software includes many new features that are missing from the illegal fork. This is a valid point and if GPL'ed software fails, I will likely give it a shot. I were turned off a bit with the whole cdrecord-ProDVD thing and then the CDDL issues, but at least the former seems no longer an issue, and e.g. BluRay writing is indeed a nice feature. There never was such an issue. There have been some hostile people who spread incorrect claims on my software in order to harm. Just in case you don't know: I was the fisrt person who tried to sue companies for violating the GPL and while doing this, I learned that most of the GPL claims cannot be enforced in court. The CDDL is a license that is more liberal and just includes those claims that are enforcable in court. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Wodim: How to read from stdin?
Til Schubbe li...@lists.schubbe.org wrote: In fact, I wonder why you don't just burn it direct. Computer A has the burner inside, but not enough free diskspace to cache the image, which is on computer B... But meanwhile I think about putting the burner into A. One solution for this problem is the RSCSI protocol that I created 10 years ago in order to talk to remote SCSI devices. This let's you run cdrecord on computer B while the burner is in computer A. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Wodim: How to read from stdin?
Thomas Schmitt scdbac...@gmx.net wrote: Bill Davidsen: In my case I have a data stream of 400-500MB which I wish to burn to CD, but because I can't know the size in advance and don't wish to save it for reasons I won't detail, I am forced to use growisofs and DVD for these little data sets. But cdrecord and wodim should be able to do this on CD by option -tao. Their handicap is with DVD only. wodim is unmaintained. Missing features will not appear there... The growisofs program knows how to do this for DVD but can not do it for CD (one of my problems). Any reason why cdrskin does not suffice for your purposes ? It is willing to burn CD, DVD and BD. cdrskin has less features than cdrecord and it does not work on Solaris (cdrskin is Linux only). Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: how to rescue this backup data
Zhang Weiwu zhangwe...@realss.com wrote: Hello. We have a website backup that has to be recovered thanks to webserver hard disk crash. However the person who burned the backup seems to have done it wrong. This is what we investigated what most likely have happened: a. he have a DVD+R that has a session on it. b. he created a backup iso image by merging that session: $ genisoimage -C ... -M /dev/sr0 -o backup.iso website_backup/ c. he burnt the backup to a /different/ DVD+R that also had a session: $ wodim dev=/dev/sr1 backup.iso (or, might also have been $ growisofs -M /dev/sr1=backup.iso ) d. he happily labeled the DVD+R in /dev/sr1 as website backup. no double check. done. 1) wodim does not support to write DVDs (in special DVD+). This is bad in special as it claims that it includes DVD support. 2) If you have wodim on your system, there is a big chance that you used genisoimage (part of the fork) instead of the original software mkisofs. Genisoimage is known to have many bugs that in special hit you in multi-session mode. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: how to rescue this backup data
Zhang Weiwu zhangwe...@realss.com wrote: on a practical level, is there a suggestion what we could do /now/ to recover the website? That would indeed be very helpful. The problem with a lot of backup methods is that it is WORN (write once, read never) until you need it. People should always test their meckup method before there is a need for it. If you need the information whether or not we used mkisofs in order to provide any suggestion on recovering data, the answer is very likely no because all computers here run debian and the previous employees working here (who does the backup), most of them just use whatever debian offers as part of the default installation that contains gnome. I recommend you to start with installing recent original software from ftp://ftp.berlios.de/pub/cdrecord/alpha/ and then to run isoinfo -i devname -d in order to check thether the medium contains a ISO-9660 filesystem at all. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
cdrtools-2.01.01a71 ready
NEW features of cdrtools-2.01.01a71: *** NOTE: cdrtools is currently in a state of a release candidate for the next major release. *** *** All man pages have been rewritten for the upcomming final release ** *** Please read the man pages and report hints and proposals ** All: - include/schily/stat.h now supports nonosecond timestamps in struct stat on AIX. - New autoconf test for nanosecond time stamps on AIX. - conf/mkdir.sh - conf/mkdep-aix.sh was changed to avoid warnings for #pragma weak a = b as the IBM C-compiler calls a non #pragma weak cpp when called with -E Libschily: Libparanoia (Ported/enhanced by Jörg Schilling, originated by Monty xiphm...@mit.edu): Libedc (Optimized by Jörg Schilling, originated by Heiko Eißfeldt he...@hexco.de): Libcdrdeflt: Libdeflt: Libfind: Libfile: Libhfs_iso: Libsiconv: Libscg: Libscgcmd: Libmdigest: Rscsi: Cdrecord: - Cdrecord now is able to use -isosize even in case that the image data is read from stdin. This makes it easier to use mkisofs | cdrecord. Cdda2wav (Maintained/enhanced by Jörg Schilling, originated by Heiko Eißfeldt he...@hexco.de): Readcd: Scgcheck: Scgskeleton: Btcflash: Mkisofs (Maintained/enhanced by Jörg Schilling since 1997, originated by Eric Youngdale): HELIOS TODO: - Add the HELIOS UNICODE mapping code. This needs to be done at UCS-2 level for Joliet and UDF (instead of UTF-8) and only for Rock Ridge (in case of a UTF-8 based target locale) using UTF-8 based translations. - Make the Apple extensions work again with mkisofs -find TODO: - Support correct inode numbers for UDF hardlinks - Support sockets, pipes, char/blk-dev specials with UDF - read Joliet filenames with multi-session if no TRANS.TBL or RR is present. I am looking for a volunteer for this task! Note that this can never be 100% correct as there is no relation between the names on the master (UNIX) filesystem, the ISO-9660 names and the Joliet names. Only the Rock Ridge names are untranslated with respect to the original files on the master (UNIX) filesystem. - add libecc/edc for CDI and similar. The files are located on: ftp://ftp.berlios.de/pub/cdrecord/alpha ... Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Wodim: How to read from stdin?
Til Schubbe li...@lists.schubbe.org wrote: Hi, on 25 May 2007 Thomas Schmitt wrote: | I.e. this does not work: | $ cat /dvdbuffer/fertig.iso | wodim -v dev=0,0,0 - | ... | wodim: Track 1 has unknown length. I'm getting the same errormessage. How can wodim read from stdin? First a question: Why do you like to use defective and illegal software like wodim? Wodim is a dead fork created by a hostile downstream paketzier from a very outdated version of cdrecord. Wodim has many bugs that never have been in cdrecord and wodim cannot be legally distributed as it is in conflict with the GPL and with the Copyright law. There are currently more than 100 well known bugs in the bug tracking systems of the various Linux distibutors that decided to go the illegal way and since May 6th 2007, bug reports for wodim are ignored and even easy to fix bugs stay around since then. I cannot speak for your DVD problem as in wodim, the mature and now 12 year old original DVD support from cdrecord was ripped off and replaced by some half baken code that fails in many cases and does e.g. not support dual layer media at all. I can however tell you why the original software (cdrecord) will behave the same way in your case: In the early years of CD recording, CD writers did only support to write in TAO mode and for this reason, old versions of cdrecord did by default write in TAO mode. In TAO mode, it is possible to write tracks of unknown length as the writer writes the TOC _after_ the data and after interrupting the write process. As the forward error correction used on CDs is computing a result that includes parts of the previous sector, a CD written in TAO mode has unreadable sectors and gives audible clicks (if it is used for audio data). There was a mode better than TAO in these days (RAW mode) but this mode requires to have a working Reed Solomon forward error correction encoding implementation. Such an implementation was made by Heiko Eißfeld in 1998 - 1999 for the cdrtools project and BTW: all current OSS implementations of the RS encoder either use the software from Heiko or software that was derived from Heikos work. In September 1997, the first DVD writer was made by Pioneer and this DVD recorder did _only_ support to write in SAO mode (in SAO mode, the creation of the forward error correction code is done in the drive). I received one of the very early samples of the Pioneer DVD writer in January 1998 and finished the first DVD writing support (in SAO mode) for cdrecord in February 1998. A short time later, SAO mode and RAW mode writing for CDs was added to cdrecord. As in these modes, writing is uninterrupted and the TOC is written first, the size of the tracks needs to be known in advance but the quality of the resulting media is better than when written in TAO mode. Since a while, cdrecord defaults to write in SAO mode because this creates better results than when writing in TAO mode. If you like to write from a pipe, you need to tell cdrecord about the size of the tracks. There is of course an example in the EXAMPLES section of the cdrecord man page, see cdrecord man page. Please note that software that allows to write media without knowing the size in advance is not writing in SAO mode. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Wodim: How to read from stdin?
Norbert Preining prein...@logic.at wrote: On Sa, 02 Jan 2010, Joerg Schilling wrote: First a question: Why do you like to use defective and illegal software like wodim? Please stop calling anything illegal without a legal proof of it. Please go to court and find clarification once and for all, otherwise you in turn can be sued for üble Nachrede. What _you_ are doing is something you may be sued for, so be careful with your hostile trolling. Well everybody who read this mailing list already knows that you did never write something helpful besides your trolling. Wodim is a dead fork created by a hostile downstream paketzier from a very The one that is hostile is you. The name of the hostile person is Eduard Bloch. After he bacame a Debian packaging maintainer, he soon started to send repeated personal insults after he send a patch that was full of bugs and that could not be integrated beacuse of the bugs. It was his unwillingness to fix his bugs that introduced a problem that did not exist with the previous Debian poackaging maintainer. It is the fact that Bloch prefers to attack people instead of colaborating that makes it obvious to call him hostile. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Wodim: How to read from stdin?
Thomas Schmitt scdbac...@gmx.net wrote: Joerg Schilling wrote: Please note that software that allows to write media without knowing the size in advance is not writing in SAO mode. In principle: yes. But cdrskin can combine options -sao and -isosize and thus can burn ISO images which it receives from stdin to CD as SAO resp. to DVD as DAO. cdrskin only works on Linux but cdrecord works on more than 30 different platforms and cdrecord supports a lot more different drives than cdrkin does. Not everything that looks simple in a simple program is simple in a program like cdrecord that honors complex constraints. There are unfortunately several Openrating systems that do not support the FIFO in cdrecord and the FIFO is needed in order to support -isosize with pipes. I did have this feature on my radar since a long time but there have been other more important features with higher priority DVD DAO is said to be preferrable for standalone DVD players (see dvd+rw-tools docs). I am not aware of any such reason if the intended readers are DVD drives in computers. It is a matter of fact that SAO mode gives the best read compatility. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: cdrkit 1.1.10 fails to locate libcap
Mark Rosenstand rosenst...@gmail.com wrote: Hi, I just found the 1.1.10 update on ftp.debian.org by accident as I'm tracking cdrkit.org/releases/ - would be nice if releases were made available through the upstream site as well (or the old releases removed and a message telling to use ftp.debian.org) Cdrkit is undistributable as it is in conflict with the GPL and the Copyright law. Cdrkit is unmaintained since May 6th 2007, so why do you ask for cdrkit? I recommend you to use the original software from ftp://ftp.berlios.de/pub/cdrecord/alpha/ There are no known problems with the original software and the original software includes many new features that are missing from the illegal fork. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
cdrtools-2.01.01a70 ready
NEW features of cdrtools-2.01.01a70: *** NOTE: cdrtools is currently in a state of a release candidate for the next major release. *** *** All man pages have been rewritten for the upcomming final release ** *** Please read the man pages and report hints and proposals ** All: - Added support for Hurd on i686 to the Schily Makefilesystem. - Modified conf/mkdir.sh to work around a deviation found in /usr/xpg4/bin/sed on Solaris - Modified conf/src-get to include conf/src-get in PATH to make recursive calls to src-get work. Libschily: Libparanoia (Ported/enhanced by Jörg Schilling, originated by Monty xiphm...@mit.edu): Libedc (Optimized by Jörg Schilling, originated by Heiko Eißfeldt he...@hexco.de): Libcdrdeflt: Libdeflt: Libfind: - Added $(LIB_ACL_TEST) to the libs for libfind to allow a shared libfind with ACL support on Linux. Libfile: Libhfs_iso: Libsiconv: Libscg: Libscgcmd: Libmdigest: Rscsi: Cdrecord: - Cdrecord now defaults to -sao in case that cuefile=something was specified - man page restructured Cdda2wav (Maintained/enhanced by Jörg Schilling, originated by Heiko Eißfeldt he...@hexco.de): - The default outout format is now .wav for all platforms. Before, the default for Solaris was .au. - man page restructured Readcd: - man page restructured Scgcheck: Scgskeleton: Btcflash: Mkisofs (Maintained/enhanced by Jörg Schilling since 1997, originated by Eric Youngdale): HELIOS TODO: - Add the HELIOS UNICODE mapping code. This needs to be done at UCS-2 level for Joliet and UDF (instead of UTF-8) and only for Rock Ridge (in case of a UTF-8 based target locale) using UTF-8 based translations. - Make the Apple extensions work again with mkisofs -find TODO: - Support correct inode numbers for UDF hardlinks - Support sockets, pipes, char/blk-dev specials with UDF - read Joliet filenames with multi-session if no TRANS.TBL or RR is present. I am looking for a volunteer for this task! Note that this can never be 100% correct as there is no relation between the names on the master (UNIX) filesystem, the ISO-9660 names and the Joliet names. Only the Rock Ridge names are untranslated with respect to the original files on the master (UNIX) filesystem. - add libecc/edc for CDI and similar. The files are located on: ftp://ftp.berlios.de/pub/cdrecord/alpha ... Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
cdrtools-2.01.01a69 ready
Note that this release contains a work around for new drives developed by Pioneer sold under the brands: Pioneer, Plextor and TEAC. NEW features of cdrtools-2.01.01a69: *** NOTE: cdrtools is currently in a state of a release candidate for the next major release. *** All: - Support for 64 Bit compilation was added for IRIX. Call smake CCOM=cc64 or smake CCOM=gcc64 as usual. - C++ compilation support fior IRIX was added to the makefile system - Schily Makefile rules no longer contain Simple Suffix Rules. All default rules are now based on Pattern Matching Rules. This speeds up smake. - Added autoconf test to distinct Linux ACLs from IRIX ACLs Libschily: - Removed some GCC warnings from libschily/getargs.c Libparanoia (Ported/enhanced by Jörg Schilling, originated by Monty xiphm...@mit.edu): Libedc (Optimized by Jörg Schilling, originated by Heiko Eißfeldt he...@hexco.de): Libcdrdeflt: Libdeflt: Libfind: - let libfind deal with the differences between Linux ACLs and IRIX ACLs Libfile: Libhfs_iso: Libsiconv: Libscg: - Removed some GCC warnings from libscg/scsi-sgi.c Libscgcmd: Libmdigest: Rscsi: Cdrecord: - Work around a bug in the firmware from drives developed by PIONEER in November 2009. This affects drives labelled Pioneer, Plextor and TEAC. Do no longer call cdr_buffer_cap() before the drive buffer was not at least filled once to avoid that the the drive throughs away all data. - Man page reworked Cdda2wav (Maintained/enhanced by Jörg Schilling, originated by Heiko Eißfeldt he...@hexco.de): - Man page reworked - Removed some (int) casts before the SNDCTL_DSP_* ioctl()s Readcd: - Man page reworked Scgcheck: - Man page reworked Scgskeleton: Btcflash: - Man page reworked Mkisofs (Maintained/enhanced by Jörg Schilling since 1997, originated by Eric Youngdale): - Various Cstyle changes HELIOS TODO: - Add the HELIOS UNICODE mapping code. This needs to be done at UCS-2 level for Joliet and UDF (instead of UTF-8) and only for Rock Ridge (in case of a UTF-8 based target locale) using UTF-8 based translations. - Make the Apple extensions work again with mkisofs -find TODO: - Support correct inode numbers for UDF hardlinks - Support sockets, pipes, char/blk-dev specials with UDF - read Joliet filenames with multi-session if no TRANS.TBL or RR is present. I am looking for a volunteer for this task! Note that this can never be 100% correct as there is no relation between the names on the master (UNIX) filesystem, the ISO-9660 names and the Joliet names. Only the Rock Ridge names are untranslated with respect to the original files on the master (UNIX) filesystem. - add libecc/edc for CDI and similar. The files are located on: ftp://ftp.berlios.de/pub/cdrecord/alpha ... Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
cdrtools-2.01.01a68 ready
NEW features of cdrtools-2.01.01a68: *** NOTE: cdrtools is currently in a state of a release candidate for the next major release. *** All: - VMS rules for libraries not create an archive XXX.olb instead of libXXX.a - schily/utypes.h enhanced to allow to define maxint_t which is missing on VMS - Better autoconf test for union wait vs. int for platforms that define union wait but use int as wait() parameter. - schily/vfork.h now includes unistd.h as the related definitions are there on Solaris - Fixed a configure bug with opendir() inherited from GNU autoconf - Enhanced the vfork() autoconf test to avoid a hang on VMS Libschily: - libschily/spawn.c now uses vfork() - libschily/fexec.c now supports IO redirection on VMS Libparanoia (Ported/enhanced by Jörg Schilling, originated by Monty xiphm...@mit.edu): - Some #define inline definitions removed as inline is already handled by schily/mconfig.h Libedc (Optimized by Jörg Schilling, originated by Heiko Eißfeldt he...@hexco.de): Libcdrdeflt: Libdeflt: Libfind: - Fixed a typo in idcache.c Libfile: - Some changes for better VMS support Libhfs_iso: - Removed a warning from the HP-UX C-compiler about a possible endless loop Libsiconv: - Add the VMS C-compiler to the list of exceptions for not fully C99 compliant compilers to allow compilation. Libscg: - changed a include path in libscg/scsi-mac-iokit.c to allow compilation on Snow Leopard Libscgcmd: Libmdigest: Rscsi: Cdrecord: - Added a workaround for a firmware oddity with DVD+RW on '_NEC' 'DVD_RW ND-3500AG' with media written from other drives. Cdda2wav (Maintained/enhanced by Jörg Schilling, originated by Heiko Eißfeldt he...@hexco.de): - Added a forgotten modification in ringbuff.c that caused an abort due to a wrong assert() condition. Readcd: Scgcheck: Scgskeleton: Btcflash: Mkisofs (Maintained/enhanced by Jörg Schilling since 1997, originated by Eric Youngdale): - Fixed a bug (writing to stdout instead of stderr) recently introduced with better RR recognition support. - isoinfo now supports iconv() based locales for Joliet. HELIOS TODO: - Add the HELIOS UNICODE mapping code. This needs to be done at UCS-2 level for Joliet and UDF (instead of UTF-8) and only for Rock Ridge (in case of a UTF-8 based target locale) using UTF-8 based translations. - Make the Apple extensions work again with mkisofs -find TODO: - Support correct inode numbers for UDF hardlinks - Support sockets, pipes, char/blk-dev specials with UDF - read Joliet filenames with multi-session if no TRANS.TBL or RR is present. I am looking for a volunteer for this task! Note that this can never be 100% correct as there is no relation between the names on the master (UNIX) filesystem, the ISO-9660 names and the Joliet names. Only the Rock Ridge names are untranslated with respect to the original files on the master (UNIX) filesystem. - add libecc/edc for CDI and similar. ftp://ftp.berlios.de/pub/cdrecord/alpha ... Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
cdrtools-2.01.01a67 ready
NEW features of cdrtools-2.01.01a67: *** NOTE: cdrtools is currently in a state of a release candidate for the next major release. *** All: - Prevent a compiler warning when compiling 64 bit binaries on HP-UX using make CCOM=cc64 - Some files in include/schily/*.h have been enhanced to better support VMS - config.guess now knows about OpenVMS - Changed bash test to use --version instead of -version as bash on OpenVMS is bash-1.x - include/schily/xmconfig.h (containing a static configuration for VMS because configure does not work on VMS) was enhanced. - Trying to add support for OpenVMS to RULES/* - New autoconf tests for the type long double and a new max size type. Libschily: - libschily/*bytes.c now support 64 bit compilation and use a ssize_t typed count parameter instead of int. Libparanoia (Ported/enhanced by Jörg Schilling, originated by Monty xiphm...@mit.edu): Libedc (Optimized by Jörg Schilling, originated by Heiko Eißfeldt he...@hexco.de): Libcdrdeflt: Libdeflt: Libfind: Libfile: Libhfs_iso: Libsiconv: Libscg: Libscgcmd: Libmdigest: Rscsi: - First complete version of a man page for rscsi. Cdrecord: Cdda2wav (Maintained/enhanced by Jörg Schilling, originated by Heiko Eißfeldt he...@hexco.de): - cdda2wav now correctly deals with the case when no sound device was specified. Thanks to Robert Grimm r...@news.robgri.de for reporting. Readcd: Scgcheck: Scgskeleton: Btcflash: Mkisofs (Maintained/enhanced by Jörg Schilling since 1997, originated by Eric Youngdale): - Make isovfy CD-ROM-XA aware - Make isodump CD-ROM-XA aware HELIOS TODO: - Add the HELIOS UNICODE mapping code. This needs to be done at UCS-2 level for Joliet and UDF (instead of UTF-8) and only for Rock Ridge (in case of a UTF-8 based target locale) using UTF-8 based translations. - Make the Apple extensions work again with mkisofs -find TODO: - Support correct inode numbers for UDF hardlinks - Support sockets, pipes, char/blk-dev specials with UDF - read Joliet filenames with multi-session if no TRANS.TBL or RR is present. I am looking for a volunteer for this task! Note that this can never be 100% correct as there is no relation between the names on the master (UNIX) filesystem, the ISO-9660 names and the Joliet names. Only the Rock Ridge names are untranslated with respect to the original files on the master (UNIX) filesystem. - add libecc/edc for CDI and similar. The files are located on: ftp://ftp.berlios.de/pub/cdrecord/alpha ... Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
Rob W wrob0...@gmail.com wrote: Just wanted to follow up with more experimentation ... Previously I was using the JMicron JM20336 USB-SATA bridge. Now I have the JM20329, apparently a simpler (and slower) chip. The BH08LS20 drive connected via USB 2.0, using blank BD-R disc. Using this drive connected to my CentOS machine with JM20329, I tried NeroLinux again, and this time was successful. At 2x, it only took 18 minutes to burn a 9 GB iso image. Perhaps I should try growisofs on the CentOS machine. Cdrecord will be changed to workaound the firmware bug. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Is dvd-r not supported in cdrecord?
Bill Davidsen david...@tmr.com wrote: My assumption, as I posted earlier, is that it is trying to mount media of any type it understands. To guess the media type the first sector is read. This requires a seek to sector zero and a read, leaving the burner at a location which has already been written. Actually, I just had a thought on how to patch hal not to do this, I'll try it sometime this week as I get time. The problem with hald is that it does something when it needs wo be quiet. This is a result of using incorrect rules for detecting media insertion. On Solaris, hald has been patched not to use this buggy algorithm but to call an ioctl() instead that calls correct code which is living in the kernel sd driver. I posted the correct algorithm many times in the net, so it seems that there is little hope to get a fix. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Is dvd-r not supported in cdrecord?
chi kwan zggu...@hotmail.com wrote: wow, it looks like from some documents for elites, where can i find it? and can i fine tune cdrecord so it won't be too specific on medias? You will need to ask the vendor of your drive to give you different firmware that supports this media. Progams like cdrecord cannot influence this kind of media incompatibility. The only chance you have is to reduce the write speed, so try cdrecord speed=1 and cdrecord will write with the lowest speed that the firmware of your drive likes to support. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Is dvd-r not supported in cdrecord?
chi kwan zggu...@hotmail.com wrote: I kill mime and gosh, it is burning at 8x as dummy! Thanks very much for the insight and sorry for not trying it early enough to avoid all the exchanges. life is good again. Thank you for proving my asumption ;-) BTW: I made this proposal as I did already see exactly the same error message as a result from the actions of hald. In the other case, killing hald did fix the problem. I have no idea how hald causes this kind of errors. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Is dvd-r not supported in cdrecord?
Thomas Schmitt scdbac...@gmx.net wrote: what should i do with hald and O_EXCL ? I assume your successful burns were via growisofs. Afaik it opens the device file with option O_EXCL. See man 2 open for usage. The meaning of O_EXCL on Linux storage device files is fewly documented: A further open(O_EXCL|O_RDWR) will fail as long as there is an open file descriptor with O_EXCL|O_RDWR. I did already mention that using O_EXCL is not an option for libscg and cdrtools as using O_EXCL would causes other problems that are even less tolerable. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Is dvd-r not supported in cdrecord?
Thomas Schmitt scdbac...@gmx.net wrote: Hi, Bill Davidsen: the OS provides tools by which applications can prevent this, if the applications fail to use them than the fix lies in the application (and the user who chose the application). I would really like to implement a hald cooperation module in libburn. The authors of hald did introduce a serious problem to CD/DVD writing and I would have expected that they contact me before introducing this problem into Linux distributions. BTW: It seems that hald it outdated anyway and going to be replaced. It does not seem to make sense to take it into account for development. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Is dvd-r not supported in cdrecord?
chi kwan zggu...@hotmail.com wrote: Knowing your reply policies but really getting nowhere from documentation nor google. Cutting all the formalities to save your time, the outputs are bit too long. Well, did you carefully read the error message from cdrecord? Problem: Cannot write dvd-r(w) but with dvd+rw is great dvd-r(w) support of the drive/system is alright using CD/DVD creator comes with Gnome cdrecord version: Cdrecord-ProDVD-ProBD-Clone 2.01.01a66 (x86_64-unknown-linux-gnu) System Spec: Intel(R) Pentium(R) D CPU 2.80GHz stepping 04 1G Ram Fedora Core 6 Media: DVD-R 16x 4.7G, Brand: SoHot, Manufactorer: Imation ATIP: book type: DVD-R, Version 2.0x - 2.1 (2.5) disc size: 120mm (0) maximum rate:Not specified (15) number of layers:1 track path: Parallel Track Path (0) layer type: Rewritable Area (2) linear density: 0.267 m/bit (0) track density: 0.74 m/track (0) phys start: 196608 (0x3) phys end:2159966 end layer 0: 0 bca: 0 phys size:...1963359 copyr prot type: 0 region mgt info: 0 application code:64 physical code: 193 last rec address:16621272 part v./ext code:5/2 ind wr. power: 132 wavelength code: 13 write str. code: 12 98 99 90 Manufacturer: 'CMC MAG. AM3' Command line: cdrecord -v dev=4,0,0 -dummy /bkup/trial.iso cdrecord -v dev=4,0,0 -toa -dummy /bkup/trial.iso cdrecord -v dev=4,0,0 driveopts=burnfree -dummy /bkup/trial.iso results without using -dummy are all the same, dummy to save disks Output (from first command on DVD-R): cdrecord: No write mode specified. cdrecord: Assuming -sao mode. cdrecord: If your drive does not accept -sao, try -tao. cdrecord: Future versions of cdrecord may have different drive dependent defaults. scsidev: '4,0,0' scsibus: 4 target: 0 lun: 0 Linux sg driver version: 3.5.34 SCSI buffer size: 64512 Cdrecord-ProDVD-ProBD-Clone 2.01.01a66 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2009 J?rg Schilling TOC Type: 1 = CD-ROM Using libscg version 'schily-0.9'. atapi: 1 Device type: Removable CD-ROM Version: 5 Response Format: 2 Capabilities : Vendor_info: 'HL-DT-ST' Identifikation : 'DVDRAM GSA-4120B' Revision : 'A117' Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. Current: DVD-ROM Profile: DVD-RAM Profile: DVD-R sequential recording Profile: DVD-RW sequential recording Profile: DVD-RW restricted overwrite Profile: DVD+RW Profile: DVD+R Profile: DVD+R/DL Profile: DVD-ROM (current) Profile: CD-R Profile: CD-RW Profile: CD-ROM Profile: Removable Disk Using generic SCSI-3/mmc-2 DVD-R/DVD-RW/DVD-RAM driver (mmc_dvd). Driver flags : NO-CD DVD MMC-3 SWABAUDIO BURNFREE Supported modes: PACKET SAO Drive buf size : 1114112 = 1088 KB Drive pbuf size: 1966080 = 1920 KB Drive DMA Speed: 13725 kB/s 77x CD 9x DVD 3x BD FIFO size : 4194304 = 4096 KB Track 01: data 3834 MB Total size: 3834 MB = 1963359 sectors Current Secsize: 2048 Total power on hours: 0 WARNING: Phys disk size 1963359 differs from rzone size 2298496! Prerecorded disk? WARNING: Phys start: 196608 Phys end 2159966 Blocks total: 2298496 Blocks current: 2298496 Blocks remaining: 335137 Reducing transfer size from 64512 to 32768 bytes. Starting to write CD/DVD/BD at speed 8 in dummy SAO mode for single session. Last chance to quit, starting dummy write in 9 seconds.. Operation starts. Waiting for reader process to fill input buffer ... input buffer ready. BURN-Free is OFF. Starting new track at sector: 0 Track 01:0 of 3834 MB written.cdrecord: Input/output error. write_g1: scsi sendcmd: no error CDB: 2A 00 00 00 00 00 00 00 10 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 05 00 00 00 00 10 2A 00 00 0C 30 05 00 00 Sense Key: 0x5 Illegal Request, Segment 0 Sense Code: 0x30 Qual 0x05 (cannot write medium - incompatible format) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.002s timeout 200s cdrecord: A write error occured. cdrecord: Please properly read the error message above. write track data: error after 0 bytes It looks like your drive does not like the low quality media you are using. I recommend you to buy better media quality (e.g. Verbatim in packages = 25 pieces). Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Is dvd-r not supported in cdrecord?
Thomas Schmitt scdbac...@gmx.net wrote: Hi, chi kwan: Cannot write dvd-r(w) but with dvd+rw is great dvd-r(w) support of the drive/system is alright using CD/DVD creator comes with Gnome Possibly this uses growisofs as burn engine. (To verify this: have a look with ps -ef | grep growisofs while a DVD burn is going on.) cdrecord is supports to write DVD-R since February 1998, this is _long_ before growisofs even exists and _long_ before commercial DVD writing software exists. Cdrecord does not call growisofs CDB: 2A 00 00 00 00 00 00 00 10 00 Sense Key: 0x5 Illegal Request, Segment 0 Sense Code: 0x30 Qual 0x05 (cannot write medium - incompatible format) Fru Joerg Schilling: It looks like your drive does not like the low quality media you are using. I have sincere doubt that poor media quality can cause a 5,30,05 error. It clearly belongs to a family of complaints about media types It may be that this is a problem caused by hald or it's recent replacement (I belive it is called device-kit or similar) disturbing the write process. You may like to kill all related processes before tryng to write again. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Is dvd-r not supported in cdrecord?
Thomas Schmitt scdbac...@gmx.net wrote: The problem did not appear with cdrskin. Probably because libburn opens the device file with option O_EXCL. This is no insurance against hald problems, of course. hald and burning of sequential media do not play well together. In this case, you just get into other problems ;-) Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Is dvd-r not supported in cdrecord?
Giulio Orsero giul...@gmail.com wrote: ... CDB: 2A 00 00 00 00 00 00 00 10 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 05 00 00 00 00 10 2A 00 00 0C 30 05 00 00 Sense Key: 0x5 Illegal Request, Segment 0 Sense Code: 0x30 Qual 0x05 (cannot write medium - incompatible format) Fru 0x0 It looks like your drive does not like the low quality media you are using. I recommend you to buy better media quality (e.g. Verbatim in packages = 25 pieces). Doesn't Current: DVD-ROM mean this DVD-R has already been written to? The SCSI error message was flagged for sector #0, so it seems that the medium has not yet been written to. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Is dvd-r not supported in cdrecord?
Thomas Schmitt scdbac...@gmx.net wrote: Hi, Giulio Orsero: Doesn't Current: DVD-ROM mean this DVD-R has already been written to? Good point. Some drives announce a closed DVD-R as DVD-ROM. Correct, but this could also be a result from a drive that does not like the media because it is impossible to read the ADIP correctly fro whatever reason. The OP would need to give additonal information as his first mail mentioned a medium that was flagged by the drive as Unformated or Blank Media. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Is dvd-r not supported in cdrecord?
Thomas Schmitt scdbac...@gmx.net wrote: chi kwan: could you please run dvd+rw-mediainfo /dev/... on the media which refused to get burned, so we get more clarity about its state ? This would not give us any more information than cdrecord can give. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Looking for porting account on AIX and others
Rob Bogus ro...@tmr.com wrote: Linux Test machine ready Which Linux? It runs on many CPUs, and at minimum x86_32, x86_64, SPARC and PPC are probably worth testing due to reasonable user base. Reasonable defined more than Hurd in this case. If Linux is written internally in a way that could be called clean and processor independent, then the processor independence of the portability system in cdrtools should be sufficient to hide all specifics of other CPU types. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: My Pioneer DVR-218L i think is behaving like the LG GH20NS10 might hang at the end of DVD-R[W] DAO recording...
Lucas Levrel llev...@yahoo.fr wrote: Le 19 octobre 2009, Joerg Schilling a écrit : Due to the well known bugs in cdrkit aka. wodim, k3b prefers the original software before the broken fork. But beware that some distributions (e.g. openSUSE 10.3) have a symlink /usr/bin/cdrecord - wodim. So depending on PATH installation details of genuine cdrecord, the latter may be unnoticed. If available, one should have a look to k3b logs I guess... Correct, but k3b first looks into /opt/schily/bin in order to find the original software ;-) Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
Andy Polyakov ap...@fy.chalmers.se wrote: On the other hand, looking through the information provided *beyond* requested one allows to draw conclusion that DMA is *in fact* enabled for optical drive in question. Once again, target1-dcd-options is 0xa2 and more important read performance reaches 19MBps[!]. Indeed, there is no way venerable Blade-100 can deliver that much over PIO at *portion* of CPU power(*). As for value of 0xa2. Earlier I said that it denotes UDMA-2. As it turns out this was inaccurate. Upper bits, ones constituting 0xa?, do denote UDMA, but lower bits, ones constituting 0x?2, don't denote UDMA *mode*. Lower bits are meaningful when UDMA is disengaged and seem to denote PIO mode. In other words, while not being specific about UDMA mode, the value still tells that UDMA is actually enabled. This is indeed a real hint that there is DMA. (*) Well, patching uata driver to avoid DMA in atapi_ routines have shown that same experiment, pread(2) with fixed offset in loop, delivers not more than 2.7MBps at 95% of CPU time! I would not expect more than 4 MB/s for PIO Even though above is about SPARC Solaris 8 I found no evidence that DMA default settings for ATA would be different on SPARC Solaris 10 and even OpenSolaris for SPARC. Unfortunately I have no opportunity to confirm this experimentally. The conclusion is based on once observed target?-dcd-options value on SPARC Solaris 10, comparison of binary code for uata driver in all three releases, and on comparison of source code for Solaris 8 and OpenSolaris. The variable atapi-cd-dma-enabled was introduced for Solaris 10. Before _all_ CDs always had no DMA. This is a result of a bad bugtracking entry made by a Sun employee who incorrectly claimed that there are problems when DMA is enabled. As with Solaris 8 and 9 DMA was never used for CDs, I published the related patch that worked fine for Solaris 8 and 9 until recentliy with a Sun provided patch. In the course of discussion it was also implied that cdrecord's Solaris DMA related READMEs are up-to-date with accuracy of 12 months and apply to *all* Solaris releases. To summarize, the READMEs discuss binary They are as correct as they can be with the feedback from users... I do have negative feedback from two sysadmins who both have been unable to use a DVD writer on a sparc based system because of the lack of DMA and the fact that the writer did not like to enable burn-free if DMA is not active. Both could however confirm that using slow DVD-RW media at 2x write speed works. patching of ata binary driver on Solaris 9 x86 as the only way to engage DMA for optical ATAPI units. I don't recall when Solaris 10 was released, but from my 4 years personal experience with Solaris 10 x86 on Sun W1100z (Opteron-based workstation), it's perfectly possible to Opteron is not sparc... control DMA setting for optical ATAPI unit with atapi-cd-dma-enabled boot parameter and no binary patching is required. This applies even to OpenSolaris for x86 (where it's even properly documented in ata(7d)). Then there is enough evidence that the READMEs in question are not applicable to [any recent] SPARC Solaris release. At the very least on SPARC Solaris ATA is implemented by uata driver, which does not even have ata_init_drive_pcidma subroutine. Not to mention above information about DMA *defaults* for SPARC Solaris ATA support. A. As you could see, my patch is for sparc and you should know that with Solaris 11 DMA is finally used by default. If you have been able to do something that other people could not do before (using a DVD drive with DMA on a sparc system), it would be nice if you could tell us how you did manage this. Well, the last sparc related feedback I received is more than a years old, so it is possible that a recent Solaris 10 patch fixed the problem. I did use sparc based systems at my primary desktop between 1988 and December 2007. I did always run the latest OS version and I was never able to see DMA for a PATA based DVD writer. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.2
D. Hugh Redelmeier h...@mimosa.com wrote: I'm not going to judge who is right and who is wrong. This is a long conflict, as far as I know. There is no related long conflict with libburn. You may confuse this with the conflict that has been initiated by a hostile Debian packaging person in May 2004 who did send repeated personal insults for more than a year just because he was unwilling to fix the bugs in a patch that he liked to be integrated into mkisofs. As a user, I'm thankful for Joerg *and* everyone else who has helped to develop this code. OSS code for larger projects is usually developed by more than one person and I believe that is is a matter of courtesy to mention the people who did write parts of the code. The cdrtools project does this and I would expect similar rules for other projects. While I can understand that someone might forget to mention some of the contributors, this does not apply to the current problem. As the maintainers from the libburn project claimed that they did not take any code from the cdrtools project although they did, I was asking them not to write claims that are obviously wrong. I hope this helps to understand the case. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: My Pioneer DVR-218L i think is behaving like the LG GH20NS10 might hang at the end of DVD-R[W] DAO recording...
Julián M. julia...@gmail.com wrote: Joerg: BTW: Cdrecord does honor this firmware specific behavior ftp://ftp.berlios.de/pub/cdrecord/alpha/ I installed cdrecord: ~$ /opt/schily/bin/cdrecord -version Cdrecord-ProDVD-ProBD-Clone 2.01.01a36 (i686-pc-linux-gnu) Copyright (C) 1995-2007 J???rg Schilling (is that the original, or some fork? im still clueless about all the versions out there) This is the original version but it is _very_ old. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: My Pioneer DVR-218L i think is behaving like the LG GH20NS10 might hang at the end of DVD-R[W] DAO recording...
Julián M. julia...@gmail.com wrote: This is the original version but it is _very_ old. I tried to compile from the newest source but i think i didnt succeed... the i installed a .deb, probably thats where the old version came from. Where did you take the package from? a36 is two years old and since then, many things did change. See the announcements on ftp://ftp.berlios.de/pub/cdrecord/alpha/ I think I never told you, im running Kubuntu Hardy 8.04 2.6.24-24-generic #1 SMP Fri Sep 18 16:49:39 UTC 2009 i686 GNU/Linux I'll try to compile the newer cdrecord. Do you know if there's any way to use it with K3B? thats the recording soft I use. Thanks! Due to the well known bugs in cdrkit aka. wodim, k3b prefers the original software before the broken fork. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Looking for porting account on AIX and others
Hi, the next final release for cdrtools is close and I am of course interested in giving the best possible. I unfortunately did not have access to some pf the supported platforms for a long time and it seems that AIX may be the most important platform from this list. Is there somebody who is able to give me ssh login access to an AIX machine with a compiler ready? BTW: this is the current porting situation: SunOS (SunOS-3.x SunOS-4.x) Test machine ready Solaris (SunOS-5.x) Test machine ready AIX --- Apollo Domain --- AmigaOS --- ATARI MiNT --- BeOS--- BSD-OS --- FreeBSD Test machine ready NetBSD Test machine ready OpenBSD Test machine ready DragonFlyBSDTest machine ready DG-UX --- GNU-Hurd--- Cygwin on win32 Test machine ready Cygwin on win64 Test machine ready Max OS XTest machine ready Haiku Test machine ready HP-UX Test machine ready (10.20 % 11.11) IRIX--- Linux Test machine ready NextSTep--- OSF-1 (Digital UNIX)--- OS/2--- SCO OpenServer Test machine ready SCO UnixWareTest machine ready Sony NEWS-OS--- SyllableTest machine ready QNX --- VMS --- ZetaTest machine ready I would love to get porting access to systems that are marked with --- So there are other platforms that are also of interest. Thank you in advance! Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
Rob W wrob0...@gmail.com wrote: Do you still have problems with cdrecord on Solaris ? Thank you for asking Jörg. Today I made some progress. Sorry I have not had time to look at the USB driver bug. Previously I was using the JMicron JM20336 USB-SATA bridge. Now I have the JM20329, apparently a simpler (and slower) chip. The BH08LS20 drive connected via USB 2.0, using blank BD-R disc. Now I no longer get the I/O errors for cdrecord -atip (or -v -minfo). However, even though cdrecord -atip shows that the disc is blank, when I try to burn, cdrecord gives capacity is unknown message. Please advise me what to try next. Here is the output from the attempt to burn image to BD-R. Below that is the output from -v -checkdrive. # cdrecord -v dev=5,0,0 speed=2 driveropts=burnfree image.iso cdrecord: No write mode specified. cdrecord: Assuming -sao mode. cdrecord: If your drive does not accept -sao, try -tao. cdrecord: Future versions of cdrecord may have different drive dependent defaults. Cdrecord-ProDVD-ProBD-Clone 2.01.01a61 (sparc-sun-solaris2.10) Copyright (C) 1995-2009 J\366rg Schilling TOC Type: 1 = CD-ROM scsidev: '5,0,0' scsibus: 5 target: 0 lun: 0 Warning: Using USCSI interface. Using libscg version 'schily-0.9'. Driveropts: 'burnfree' SCSI buffer size: 64512 atapi: 0 Device type: Removable CD-ROM Version: 0 Response Format: 2 Capabilities : Vendor_info: 'HL-DT-ST' Identifikation : 'BD-RE BH08LS20 ' Revision : '1.00' Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. Current: BD-R sequential recording Profile: BD-ROM Profile: BD-R sequential recording (current) Profile: BD-R random recording Profile: BD-RE Profile: DVD-RAM Profile: DVD-R sequential recording Profile: DVD-R/DL sequential recording Profile: DVD-R/DL layer jump recording Profile: DVD-RW sequential recording Profile: DVD-RW restricted overwrite Profile: DVD+RW Profile: DVD+R Profile: DVD+R/DL Profile: DVD-ROM Profile: CD-R Profile: CD-RW Profile: CD-ROM Profile: Removable Disk Using generic SCSI-3/mmc-3 BD-R driver (mmc_bdr). Driver flags : NO-CD BD MMC-3 BURNFREE Supported modes: PACKET SAO LAYER_JUMP Drive buf size : 2097152 = 2048 KB Drive pbuf size: 3932160 = 3840 KB Drive DMA Speed: 3724 kB/s 21x CD 2x DVD 0x BD FIFO size : 4194304 = 4096 KB Track 01: data 14911 MB Total size: 14911 MB = 7634764 sectors Current Secsize: 2048 cdrecord: Disk capacity is unknown. cdrecord: Data will not fit on any CD. cdrecord: DVD/BD capacity is unknown. cdrecord: Cannot write more than remaining DVD/BD capacity. Please send the output from cdrecord -minfo and cdrecord -atip. It may be that your drive has similar firmware bugs for BD-* as we know for DVD-* and DVD+* Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: My Pioneer DVR-218L i think is behaving like the LG GH20NS10 might hang at the end of DVD-R[W] DAO recording...
Julián M. julia...@gmail.com wrote: Hi! I hope im writing to the right mailbox.. I recently purchased a Pioneer DVR-218L SATA dvd recorder, to replace an old IDE Pioneer recorder. The unit works correctly when burning data, and it works correctly under Windows. But when i tried to burn a Video-DVD under Linux (K3B), it gave me an error in the very end of the recording process. I searched for information, and after a while, I found this: http://www.mail-archive.com/cdwrite@other.debian.org/msg12340.html That thread describes my situation almost exactly, except I own a Pioneer, not LG drive. Here are a couple of debug logs of K3B when failing: http://pastebin.com/f416c99d2 http://pastebin.com/f39fb7284 http://pastebin.com/f14fcce74 You are using a defective fork from mkisofs that creates defective filesystems, in special when using the -dvd-video option. I recommend you to use a recent cdrtools from: ftp://ftp.berlios.de/pub/cdrecord/alpha/ http://cdrecord.berlios.de/ Note that your write problems may also go away in case you use cdrecord for writing the medium. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
Rob W wrob0...@gmail.com wrote: Jörg, thank you for looking at this problem again. Please send the output from cdrecord -minfo and cdrecord -atip # cdrecord dev=5,0,0 -minfo Cdrecord-ProDVD-ProBD-Clone 2.01.01a61 (sparc-sun-solaris2.10) scsidev: '5,0,0' scsibus: 5 target: 0 lun: 0 Warning: Using USCSI interface. Using libscg version 'schily-0.9'. Device type: Removable CD-ROM Version: 0 Response Format: 2 Capabilities : Vendor_info: 'HL-DT-ST' Identifikation : 'BD-RE BH08LS20 ' Revision : '1.00' Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. Using generic SCSI-3/mmc-3 BD-R driver (mmc_bdr). Driver flags : NO-CD BD MMC-3 BURNFREE Supported modes: PACKET SAO LAYER_JUMP Mounted media class: BD Mounted media type: BD-R sequential recording Disk Is not erasable data type:standard disk status: empty session status: empty BG format status: none first track: 1 number of sessions: 1 first track in last sess: 1 last track in last sess: 1 Disk Is unrestricted Disk type: DVD, HD-DVD or BD Track Sess Type Start Addr End Addr Size == 1 1 Data 0 -1 0 Last session start address: 0 Last session leadout start address: 0 This definitely _is_ the well known firmware bug in the LG drives that is already known for DVD- and DVD+ I would need to implement a workaround in cdrecord.. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: cdrtools-2.01.01a66 ready
Bill Davidsen david...@tmr.com wrote: TODO: - Support correct inode numbers for UDF hardlinks - Support sockets, pipes, char/blk-dev specials with UDF Another thing I will try before I comment. I forgot to mention that this is of course work that is planned for the next release and not to happen before the recently planned final. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
Andy Polyakov ap...@fy.chalmers.se wrote: When it comes to accuracy of information meant for general public, it's difference between implying things and spelling them in manner that can't be interpreted differently by different people. 1. According to 'man ata' DMA is enabled by default on Solaris 10. To my experience with Sun W1100z it holds true. Whis this is true for Solaris 10 x86 and hard disks, it is definitely not true for the other. Original statement was Solaris 10 in general does not by default enable DMA. Any sane person not intimately familiar with subject would interpret that Solaris 10 never uses DMA by default. Well, we are talking about CD/DVD/BluRay writing and it should be obvious for a scientist, that remarks are done here with thede constraints in mind. General public is far from scientific. But even if it was, it would be even more incentive to stick to most accurate formulations. I cannot see statements of interest in the rest. If you like to prove that there are Sparc machines with Solaris that behave different from what all other users reported, please send the related information: - exactly describe the machine type, the OS release and the drive type. Information can be found in attachments. Looking through the information does unfortunately not show anything that verifies the presence of DMA for the CD-ROM drive in question. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
Rob W wrob0...@gmail.com wrote: That would be 24220008448 bytes (~24.2GB) growisofs pre-formatted the disc for 24.8GB It took approximately 85 minutes for the dd read, so dd read the disc at a rate around 4.75 MBps. Maybe not really really slow, but still slow. I am not sure how you computed the number but this is roughly 1x speed. CentOS experiment with growisofs Yes, but now I need to focus on cdrecord on solaris10. How will the CentOS experiment help me with that? Do you still have problems with cdrecord on Solaris or did you find a solution? Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.2
Thomas Schmitt scdbac...@gmx.net wrote: be invited to try the new version 0.7.2 of my program cdrskin, a burn backend for CD, DVD and BD with a command line interface compatible to cdrecord. When will you correct your wrong claim that states you did not copy any byte from cdrecord's sources? Note that we did already discuss this some time ago and it is obvious that you _did_ copy sources from an older version. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.2
Mario ??ani?? mario.da...@gmail.com wrote: Note that we did already discuss this some time ago and it is obvious that you _did_ copy sources from an older version. You discussed it with yourself. That's way different, don't you think? :) No, the announced code contains (different from that the project itself claims) code parts from an older version of the cdrtools source. Claiming that there was no such code move is a missinformation. Whether this has been done directly or indirectly does not matter as there are enough identifyable parts that have been written by Heiko Eißfeldt for cdrecord. The Copyright law requires to mention the original authors which is not done.. OpenSource gives many permissions but it does not allow to hide things. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: growisofs burns dvd successfully, but
Ingo Krabbe ingo.kra...@eoa.de wrote: On Mon, Oct 12, 2009 at 02:47:11PM +0200, Joerg Schilling wrote: Ingo Krabbe ingo.kra...@eoa.de wrote: As you recommended I changed my usage of growisofs/genisoimage into mkisofs/cdrecord. I see no crash and everything is OK, you may verify this by e.g. calling: Yes you are right. This disk was recorded with mkisofs -dvd-video and actually works. So maybe cdrecord isn't the problem after all, though reading the data from the dvd with readcd gives me an image I can mount with mount -oloop imgfile /mnt/image I would really like to fix this, as it seems to be possible to write dvd disks with cdrecord, but still it fails to write the toc without showing an error report. If you still believe to have problems, please describe your problems in a way that allows to understand them. -dvd-video seems to create a UDF Filesystem. It seems that the toc format of UDF is more stable, which leads me to the assumption that there might be a trick to get the iso9660 filesystem onto the dvd. Otherwise I would have quit this topic, but I just can't see where my drive or any other component fails here. There is no relation between the TOC and UDF. The TOC is something that is in the low level hidden meta data of the medium and related to accessing the media from a drive. UDF is a filesystem type that is required by DVD players and if the medium is readable by the drive, it is only a matter of the higher level code to deal with UDF. If there is really a failure that should be reported somewhere. Then, there is no problem in cdrtools. Your problem is located elsewhere, but without the apropriate information I cannot give you more help that I did already give you. Anyway I think it would be helpfull if you give me a short hint about debug=# and kdebug=# numbers. Sorry, why should I give hints on options that are intended to help me to debug low level problems that are not related to your problem? If there was any relation to your problem, you had been given the needed instructions. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
Andy Polyakov ap...@fy.chalmers.se wrote: When it comes to accuracy of information meant for general public, it's difference between implying things and spelling them in manner that can't be interpreted differently by different people. 1. According to 'man ata' DMA is enabled by default on Solaris 10. To my experience with Sun W1100z it holds true. Whis this is true for Solaris 10 x86 and hard disks, it is definitely not true for the other. Original statement was Solaris 10 in general does not by default enable DMA. Any sane person not intimately familiar with subject would interpret that Solaris 10 never uses DMA by default. Well, we are talking about CD/DVD/BluRay writing and it should be obvious for a scientist, that remarks are done here with thede constraints in mind. I cannot see statements of interest in the rest. If you like to prove that there are Sparc machines with Solaris that behave different from what all other users reported, please send the related information: - exactly describe the machine type, the OS release and the drive type. - send information from prtconf -pv - Send the kernel verbose information from /var/adm/messages that indicate that DMA was in fact enabled for the related drive - send the eeprom(1) output that indicates that the DMA is not disabled for CD-ROM type drive even though the low level kernel layers did set up DMA. - Send a cdrecord -v -checkdrive output for the drive that verifies that the drive is capable to do IO in a speed that requires DMA and thus indicates that DMA is really in effect. If you could verify this, you would be the first person to do so! Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
Andy Polyakov ap...@fy.chalmers.se wrote: cdrecord: I/O error. read disk info: scsi sendcmd: no error CDB: 51 00 00 00 00 00 00 00 04 00 status: 0x0 (GOOD STATUS) resid: 4 on Fri, 9 Oct 2009 22:12:35 -0400: # dvd+rw-mediainfo /dev/rdsk/c3t0d0s0 ... READ DISC INFORMATION: Disc status: blank Number of Sessions:1 State of Last Session: empty Next Track: 1 Number of Tracks: 1 This time the same SCSI command worked. I also assume it worked in NeroLinux. This is not necessarily the same command.. Cdrecord is implemented in compliance to the SCSI standard. Without knowing whether dvd+rw-mediainfo is implemented compliant to the SCSI standard, It feels ridiculous that I have to say this, but what choice do I have facing FUD? I can assure general public that dvd+rw-media, as well as growisofs, is compliant with SCSI standard (modulo http://fy.chalmers.se/~appro/linux/DVD+RW/hcn.html). A. I am sorry to see that you obviously try to spread FUD. If this is rather caused by the fact that youn don't understand, please stay quiet or ask! Just to repease the important sentence: This is not necessarily the same command.. Cdrecord does implement things in a way that forgives problems in the drive and that is as SCSI compliant as possible. If growisofs does some _heuristics_ instead of asking the drive the way the SCSI standard suggests, this may result in different SCSI commands. As I already mentioned: the SCSI error message above was caused by a defective Solaris kernel module and is not a result from a problem in cdrecord. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
Rob W wrob0...@gmail.com wrote: try to burn it via growisofs Seems to be working for growisofs. I started it tonight with a 15+ GB iso file. Will follow up with error messages, if any. Got to go now ... Please note: the fact that this works does not verfiy that it will always work. It seems that growisofs does some heuristiics where cdrecord just asks the drive and at this point becomes a victim of the kernel problems. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.2
Thomas Schmitt scdbac...@gmx.net wrote: Hi, When will you correct your wrong claim that states you did not copy any byte from cdrecord's sources? The claim is uphold. Note that we did already discuss this some time ago and it is obvious that you _did_ copy sources from an older version. I removed the code which was labeled as stemming from cdrdao and was not used by tested parts of libburn anyway. It obviously implemented the Reed-Solomon error correction as described in ECMA-130. One thing is to understand the math behind Reed-Solomon, quite a different thing is to understand the discretization math which leads to the tables in the cdrdao implementation. Lacking the latter math i decided to give up the inherited but never working CD raw modes of Then please inform your users that you cannot grant correctly written CDs on Lite-ON drives and that you will not be able to write SVCDs on Pioneer drives. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
Norbert Preining prein...@logic.at wrote: On Di, 13 Okt 2009, Joerg Schilling wrote: As I already mentioned: the SCSI error message above was caused by a defective Solaris kernel module and is not a result from a problem in cdrecord. No WHAT? Solaris has a defective kernel module? Incredible! Wow ... I have to post that on lkml, another of that pets of JS is fallable!!! We all know that you did never send anything besides trolling to this mailing list. Your mail has been counted, you do not need to confirm your attitude anymore in future - thank you for being quiet in future! Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: cdrtools-2.01.01a66 ready
Bill Davidsen david...@tmr.com wrote: Joerg Schilling wrote: NEW features of cdrtools-2.01.01a66: *** NOTE: cdrtools is currently in a state just before a new major release. You have been saying this for several years, it has less meaning than have a nice day, so either release a new beta or release candidate, or stop promising things you can't deliver. You nit-pick other's posts, so don't complain if you get called on this. You are not currect: I am saying this since three releases as we are currently getting _very_ close to the mext major release. There is not much to do except reworking for the man pages. BTW: since the last major release, more than 30% of the code has been rewritten or replaced and many new funtions have been added so more than 50% of the code is new since the last final release from september 2004. There have been 7100 single file edits in 2900 edit groups, resulting in an average of aprox. 4 file edits per day during this period. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: growisofs burns dvd successfully, but
Ingo Krabbe ingo.kra...@eoa.de wrote: I recommend you to use cdrecord ftp://ftp.berlios.de/pub/cdrecord/alpha/ instead. Note that you also have defective software installed an you don't use mkisofs but a defective fork called genisoimage. I see. I updated to cdrecord and that seems to work now. Update: No, it still has the same problems. When I eject the DVD and reinsert it into the drive the damaged flag is turned on and the DVD cannot mount anymore. My Yamaha DVD Player connected to my TV cannot read the DVD too, another DVD drive cannot read the DVD. If yo see a problem please describe it in a way that allows me to help you. I need sufficient information about your problem. As long as I don't eject the drive, the DVD can be mounted and dvd+rw-mediainfo reports a good track state. What does cdrecord -minfo report? There was actually no change to when I used genisoimage/growisofs builtin dd or mkisofs/cdrecord. Both produce the same problems. Is there a flag for cdrecord that handles the dvd in a different way, that I may write the fixation/index entry later in another way? Cdrecord does things automatically correct. If you have problems please send related information. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: growisofs burns dvd successfully, but
Ingo Krabbe ingo.kra...@eoa.de wrote: As you recommended I changed my usage of growisofs/genisoimage into mkisofs/cdrecord. The minfo command gives me: # cdrecord -minfo dev=1000,1,0 Cdrecord-ProDVD-ProBD-Clone 2.01.01a57 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2009 JÃ?rg Schilling scsidev: '1000,1,0' scsibus: 1000 target: 1 lun: 0 Linux sg driver version: 3.5.27 Using libscg version 'schily-0.9'. Device type: Removable CD-ROM Version: 0 Response Format: 2 Capabilities : Vendor_info: '_NEC' Identifikation : 'DVD_RW ND-4570A ' Revision : '1.02' Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. Using generic SCSI-3/mmc-2 DVD-R/DVD-RW/DVD-RAM driver (mmc_dvd). Driver flags : NO-CD DVD MMC-3 SWABAUDIO BURNFREE Supported modes: PACKET SAO cdrecord: Warning: The DMA speed test has been skipped. WARNING: Phys disk size 1846172 differs from rzone size 0! Prerecorded disk? WARNING: Phys start: 196608 Phys end 2042779 WARNING: Drive returns zero media size. Using media size from ADIP. Mounted media class: DVD Mounted media type: DVD-R sequential recording Disk Is not erasable data type:standard disk status: complete session status: complete BG format status: none first track: 1 number of sessions: 1 first track in last sess: 1 last track in last sess: 1 Disk Is unrestricted Disk type: DVD, HD-DVD or BD Track Sess Type Start Addr End Addr Size == 1 1 Data 0 18461711846172 Last session start address: 0 Last session leadout start address: 1846172 When I write the DVD I get no failure messages in dmesg nor on terminal. If its a problem of the drive I would exchange it, but I don't have instant access to another drive. I see no crash and everything is OK, you may verify this by e.g. calling: readcd f=/dev/null to read back the content. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
Rob W wrob0...@gmail.com wrote: Will dvd+rw-mediainfo work on solaris 10 (sparc) ? you ought to use character-type device entry OK, it looks like it worked, and the results are below However, cdrecord -minfo still reports End Addr = -1 Maybe I have some installation problems solaris10 came with an older version of cdrecord Perhaps the new cdrecord is linking in old shared libs? If your drive returns -1 although there is a recorded session, it looks like your drive has a firmware bug. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
Thomas Schmitt scdbac...@gmx.net wrote: Rob W on Mon, 5 Oct 2009 20:55:55 -0400: cdrecord: I/O error. read disk info: scsi sendcmd: no error CDB: 51 00 00 00 00 00 00 00 04 00 status: 0x0 (GOOD STATUS) resid: 4 on Fri, 9 Oct 2009 22:12:35 -0400: # dvd+rw-mediainfo /dev/rdsk/c3t0d0s0 ... READ DISC INFORMATION: Disc status: blank Number of Sessions:1 State of Last Session: empty Next Track: 1 Number of Tracks: 1 This time the same SCSI command worked. I also assume it worked in NeroLinux. This is not necessarily the same command.. Cdrecord is implemented in compliance to the SCSI standard. Without knowing whether dvd+rw-mediainfo is implemented compliant to the SCSI standard, it may be that it just makes a guess on how much data is available and for unknown reasons does not fail. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
Thomas Schmitt scdbac...@gmx.net wrote: Nevertheless one can learn a lot from studying the operations of dvd+rw-tools and looking them up in the SCSI specs. then please do it ;-) Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
cdrtools-2.01.01a66 ready
NEW features of cdrtools-2.01.01a66: *** NOTE: cdrtools is currently in a state just before a new major release. *** All: - Added support for 64 bit compilation on HP-HX using cc. Use make CCOM=cc64 as usual to switch to 64 bit compilation. Libschily: - libschily/fconv.c reworked to deal with non-C99 compliant systems and to deal with the constraints found in HP-UX-11.11. Libparanoia (Ported/enhanced by Jörg Schilling, originated by Monty xiphm...@mit.edu): Libedc (Optimized by Jörg Schilling, originated by Heiko Eißfeldt he...@hexco.de): Libcdrdeflt: Libdeflt: Libfind: Libfile: Libhfs_iso: Libsiconv: - Fixed a problem in libsiconv in case that the the locale is specified as iconv:name. Libscg: - Make libscg deal with the new error code from HP-UX that is returned for a non-existing ATAPI slave. - Some minor changes in libscg to make scgcheck report less problems with HP-UX Libscgcmd: Libmdigest: Rscsi: Cdrecord: - Better man page with repect to dev= - The cdrecord man page has been restructured. - Fixed a bug in the workaround code for a firmware bug for DVD+R media in HL-DT-ST drives. Cdda2wav (Maintained/enhanced by Jörg Schilling, originated by Heiko Eißfeldt he...@hexco.de): - Better man page with repect to dev= - The cdda2wav man page has been restructured. Readcd: - readcd now only send the Plextor specific SCSI commands for the -cxscan option in case that the drive identifies as Plextor. - Better man page with repect to dev= Scgcheck: - Better man page with repect to dev= Scgskeleton: Btcflash: - Better man page with repect to dev= Mkisofs (Maintained/enhanced by Jörg Schilling since 1997, originated by Eric Youngdale): - mkisofs man page reworked - isoinfo man page reworked - New file mkisofs/rock.h - isodump now prints more information about Rock Ridge attributes to help debugging non-compliant Rock Ridge ISO images. - isoinfo now correctly identifies ISO images made with the Mac OS X program hdiutil by e.g. calling: hdiutil makehybrid -iso -hfs -verbose -o xxx.iso some_dir As filesystems that violate the Rock Ridge standard. Check e.g. by isoinfo -i xxx.iso -d Interpreting Rock Ridge on such images can be enforced by calling: isoinfo -i xxx.iso -lR -debug - mkisofs now ignores the broken Rock Ridge attributes that have been created by the Mac OS X program hdiutil. HELIOS TODO: - Add the HELIOS UNICODE mapping code. This needs to be done at UCS-2 level for Joliet and UDF (instead of UTF-8) and only for Rock Ridge (in case of a UTF-8 based target locale) using UTF-8 based translations. - Make the Apple extensions work again with mkisofs -find TODO: - Support correct inode numbers for UDF hardlinks - Support sockets, pipes, char/blk-dev specials with UDF - read Joliet filenames with multi-session if no TRANS.TBL or RR is present. I am looking for a volunteer for this task! Note that this can never be 100% correct as there is no relation between the names on the master (UNIX) filesystem, the ISO-9660 names and the Joliet names. Only the Rock Ridge names are untranslated with respect to the original files on the master (UNIX) filesystem. - add libecc/edc for CDI and similar. The files are located on: ftp://ftp.berlios.de/pub/cdrecord/alpha ... Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
Andy Polyakov ap...@fy.chalmers.se wrote: As you might know, I send accurate information, so what is your issue? It's not a forum for discussing my issues. If you want to continue discussion, counterargument following: Why do you then bring up your issues that seem to be caused by incorrect information at your side? If you carefully read the Solaris DMA related REAMDEs from cdrtools-2.01, you could get the related information. 1. According to 'man ata' DMA is enabled by default on Solaris 10. To my experience with Sun W1100z it holds true. Whis this is true for Solaris 10 x86 and hard disks, it is definitely not true for the other. 2. 'man eeprom' does not provide any information about DMA settings. Make a bug report against the man page... 3. SPARC Solaris *is* capable of DMA on ATA. To my experience it holds true on Solaris 8 with Pioneer DVR-106: CPU load and performance was adequate in my DVD recording tests and I never had any problems engaging buffer underrun protection. Negotiated settings for every device can be verified with 'prtconf -v'. A. Solaris 8 definitely does not set up DMA, but Solaris 8 is 10 years old and I do no longer have a machine to check whether I could enable DMA by patching the drivers. The READMEs mentioned above contain instructions on how to patch the ata driver for Solaris 9 (x86), but this unfortunately only works for the original release and will no longer help if you installed an ATA patch. As mentioned before: Due to the fact that many DVD drives do not allow to set burnproof in case DMA is not enabled, this is a major problem on Solaris/sparc. As a result, I did get a lot of negative feedback from users that have been unable to write DVDs. The only workaround is to use slow DVD-RW media that allows to write slow enough to work without DMA. Unless this changed during the past 12 months (and this would of curse only be possible for Solaris 10 that is still in maintenance), my information is of course correct and up to date. Hope this helps. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
Rob W wrob0...@gmail.com wrote: Thanks again Jörg. I have not given up on solaris yet. Here are the errors I see with cdrecord -atip ... In this case ... is not related to the media but to the USB drivers This is a Solaris USB kernel driver bug ... Do you remember the bug tracking ID so I can look at it? Perhaps someone has worked that issue for the opensolaris project, but more than likely the fixes would not work on sparc hardware. It is Bug ID 6800130. There are several issues: - There is a problem that is caused from not honoring timeouts correctly. - There is a problem with some commands that do not set up DMA (i.e. do not send or receive any data). - There is a problem with commands that try to receive an odd number of bytes of data. - The returned error information from such commands is illegal and this is why your SCSI error message looks strange. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
Rob W wrob0...@gmail.com wrote: Thomas, thank you for suggesting dvd+rw-tools-7.1 Will dvd+rw-mediainfo work on solaris 10 (sparc) ? cdrecord -atip works, to get some more information, add -v Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
Rob W wrob0...@gmail.com wrote:
Note that my blu-ray drive is connected to my system via USB 2.0
I do not understand why DMA settings may be a problem for cdrecord.
With cdrecord I can write to DVD (Plextor PX-716UF) over USB 2.0
See below
Memorex (actually RITEK) is definitely not the highest quality media.
However, cdrecord -minfo gives the same result with Verbatim discs.
-minfo may give the same results even while you use completely different media.
The media manufacturer and media sub-types are displayed by cdrecord -atip
Here are the errors I see with the cdrecord -atip command:
In this case (-atip), your problem is not related to the media but to
the USB drivers.
# cdrecord dev=3,0,0 -atip
Cdrecord-ProDVD-ProBD-Clone 2.01.01a61 (sparc-sun-solaris2.10)
scsidev: '3,0,0'
scsibus: 3 target: 0 lun: 0
Warning: Using USCSI interface.
Using libscg version 'schily-0.9'.
Device type: Removable CD-ROM
Version: 0
Response Format: 2
Capabilities :
Vendor_info: 'HL-DT-ST'
Identifikation : 'BD-RE BH08LS20 '
Revision : '1.00'
Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM.
Using generic SCSI-3/mmc-3 BD-R driver (mmc_bdr).
Driver flags : NO-CD BD MMC-3 BURNFREE
Supported modes: PACKET SAO LAYER_JUMP
Disk type: 'BDR' (BD-R)
Disk class: 01
Manufacturer: 'RITEK'
Media type: 'BR2'
Disk: is not in cartridge
Media cartrige: write protect is off
{{{ ... gets_hung_for_long_time ... }}}
cdrecord: I/O error. read disk info: scsi sendcmd: no error
CDB: 51 00 00 00 00 00 00 00 04 00
status: 0x0 (GOOD STATUS)
resid: 4
cmd finished after 0.029s timeout 240s
cdrecord: Cannot get disk type.
cdrecord: I/O error. prevent/allow medium removal: scsi sendcmd: no error
CDB: 1E 00 00 00 00 00
status: 0x0 (GOOD STATUS)
cmd finished after 0.039s timeout 100s
This is a Solaris USB kernel driver bug that I reported a year ago and that
does not seem to get fixed. It may help to try out a different USB-ATA/SATA
adaptor.
The next time I try to use cdrecord, it tells me to power cycle the drive.
It is sufficient to replug the USB cable to fix the hang inside the kernel.
This LG drive (and Memorex media) works using Power2Go on Windows,
but I need to use the drive to archive data on my solaris sparc machines.
Please help me to get cdrecord able to read the media correctly,
and then perhaps get it to write my ISO images to blu-ray discs.
You may try to use the USB adaptor from the Plextor drive ;-)
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de(uni)
joerg.schill...@fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
--
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
Andy Polyakov ap...@fy.chalmers.se wrote: On a side note for reference. My system is loaded with one of the newer versions of solaris 10 $ uname -a SunOS my_machine 5.10 Generic_139555-08 sun4u sparc sun4u Note that Solaris 10 in general does not by default enable DMA It's natural to expect that Solaris 10 in general covers x86, isn't? Quoting 'man ata' from Solaris 10: Direct Memory Access (DMA) and PCI-IDE Systems Direct Memory Access is enabled by default. To disable DMA ... but you need it for writing. See eeprom(1) eeprom(1) manual page contains no mention of DMA. Note that Solaris sparc still does not support DMA on ATA interfaces. It's natural to expect that still means from oldest SPARC Solaris implementing support for IDE through latest, isn't it? Well, I can't speak for oldest and latest ones, but otherwise SPARC Solaris is capable of DMA on ATA interfaces to my knowledge. Negotiated value is reflected in targetN-dcd-options in prtconf -v output. Value of 0x00a2 is common for optical media units and denotes UDMA-2 mode. A. I am not sure about what you are interested in The last time I checked Solaris on sparc, I was unable to write a DVD because of the lack of DMA support for ATA. Note that in order to be able to enable burnproof, most drives require DMA to be enabled too. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: How To Read Volume ID from DVD
m mag...@gmail.com wrote: There's various places that discuss burning with growisofs and specifying a volume ID, like $ growisofs -Z /dev/dvdrw1 -R -J -V volly tmp/ but although it seems absurd I can't find any way to read this volume label back once written. volname is discussed but is worthless here: $ volname /dev/dvdrw1 CDROM Use isoinfo -o xx.iso -d Note that if you use non-asci chars in Joliet and like to add -J that you need to use the official cdrtools ftp://ftp.berlios.de/pub/cdrecord/alpha/ as th fork on seveal Linux distros is full of bugs. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
Rob W wrob0...@gmail.com wrote: Trying to burn ISO9660 image to blu-ray disc, and not having much luck. Any help on how to do this on solaris 10 using cdrecord would be appreciated. I noticed some discussion about formatting BD-R discs. Do I have to format new discs before using cdrecord? If so, how? You don't need to do so My system is loaded with one of the newer versions of solaris 10 $ uname -a SunOS my_machine 5.10 Generic_139555-08 sun4u sparc sun4u Note that Solaris 10 in general does not by default enable DMA but you need it for writing. See eeprom(1) Note that Solaris sparc still does not support DMA on ATA interfaces. Built cdrecord from source code (berlios.de) version 2.01.01a61 The drive is LG model BH08LS20 connected via SATA to USB2.0 converter The discs are Memorex single layer BD-R speed 1x - 4x Memorex may not be a high quality media. If I use -atip or -v -minfo flags, cdrecord gets I/O errors Below are the results of -minfo (without -v) and trying to write to disc This should not happen - # cdrecord dev=3,0,0 -minfo Cdrecord-ProDVD-ProBD-Clone 2.01.01a61 (sparc-sun-solaris2.10) Copyright (C) 1995-2009 Jörg Schilling scsidev: '3,0,0' scsibus: 3 target: 0 lun: 0 Warning: Using USCSI interface. Using libscg version 'schily-0.9'. Device type: Removable CD-ROM Version: 0 Response Format: 2 Capabilities : Vendor_info: 'HL-DT-ST' Identifikation : 'BD-RE BH08LS20 ' Revision : '1.00' Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. Using generic SCSI-3/mmc-3 BD-R driver (mmc_bdr). Driver flags : NO-CD BD MMC-3 BURNFREE Supported modes: PACKET SAO LAYER_JUMP Mounted media class: BD Mounted media type: BD-R sequential recording Disk Is not erasable data type:standard disk status: empty session status: empty BG format status: none first track: 1 number of sessions: 1 first track in last sess: 1 last track in last sess: 1 Disk Is unrestricted Disk type: DVD, HD-DVD or BD Track Sess Type Start Addr End Addr Size == 1 1 Data 0 -1 0 Last session start address: 0 Last session leadout start address: 0 I see no error messages. Unless your OS prevents you from sending the needed commands, it seems that your drive has problem to deal with the media. Cdrecord cannot work if it does not get the capacity from the media. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: growisofs burns dvd successfully, but
resend as the mailing list did bork my reply to binary content Ingo Krabbe ingo.kra...@eoa.de wrote: but I can't mount it. I can read the iso with dvdisaster for example and loop mount the iso. The mediainfo tells me: Track State: complete,damaged when I try to mount the disc dmesg tells me: attempt to access beyond end of device Then it did not write correctly. I recommend you to use cdrecord ftp://ftp.berlios.de/pub/cdrecord/alpha/ instead. Note that you also have defective software installed an you don't use mkisofs but a defective fork called genisoimage. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: growisofs burns dvd successfully, but
bin257xcWiAFS.bin Description: Binary data
cdrtools-2.01.01a65 ready
NEW features of cdrtools-2.01.01a65: *** NOTE: cdrtools is currently in a state just before a new major release. *** All: - *BSD comes with a broken sed(1), so we need to go back to tr(1) based code for GNU make in the Schily Makefilesystem. - Added support for amd64-netbsd-cc.rul to the Schily Makefilesystem - Added support for DragonFly BSD to config.guess and config.sub Libschily: Libparanoia (Ported/enhanced by Jörg Schilling, originated by Monty xiphm...@mit.edu): Libedc (Optimized by Jörg Schilling, originated by Heiko Eißfeldt he...@hexco.de): Libcdrdeflt: Libdeflt: Libfind: Libfile: Libhfs_iso: Libsiconv: Libscg: - Added a hack to liscg to allow cdrecord -scanbus to work on NetBSD - Added a hack to liscg to allow cdrecord -scanbus to work on OpenBSD libscg now supports -scanbus and cdrecord's autotarget feature on the following platforms: SunOS (SunOS-3.x SunOS-4.x) Solaris (SunOS-5.x) AmigaOS ATARI MiNT BeOS FreeBSD NetBSD OpenBSD DragonFlyBSD Cygwin on win32 Cygwin on win64 Max OS X Haiku HP-UX IRIX Linux NextSTep OSF-1 (Digital UNIX) OS/2 SCO OpenServer SCO UnixWare VMS Zeta Libscgcmd: Libmdigest: Rscsi: Cdrecord: Cdda2wav (Maintained/enhanced by Jörg Schilling, originated by Heiko Eißfeldt he...@hexco.de): Readcd: Scgcheck: Scgskeleton: Btcflash: Mkisofs (Maintained/enhanced by Jörg Schilling since 1997, originated by Eric Youngdale): - Avoid signed chars ad parameter to toupper HELIOS TODO: - Add the HELIOS UNICODE mapping code. This needs to be done at UCS-2 level for Joliet and UDF (instead of UTF-8) and only for Rock Ridge (in case of a UTF-8 based target locale) using UTF-8 based translations. - Make the Apple extensions work again with mkisofs -find TODO: - Support correct inode numbers for UDF hardlinks - Support sockets, pipes, char/blk-dev specials with UDF - read Joliet filenames with multi-session if no TRANS.TBL or RR is present. I am looking for a volunteer for this task! Note that this can never be 100% correct as there is no relation between the names on the master (UNIX) filesystem, the ISO-9660 names and the Joliet names. Only the Rock Ridge names are untranslated with respect to the original files on the master (UNIX) filesystem. - add libecc/edc for CDI and similar. CYGWIN NT-4.0 NOTES: To compile on Cygwin32, get Cygwin and install it. For more information read README.win32 The files are located on: ftp://ftp.berlios.de/pub/cdrecord/alpha ... Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
cdrtools-2.01.01a64 ready
NEW features of cdrtools-2.01.01a64: *** NOTE: cdrtools is currently in a state just before a new major release. *** All: - The schily makefilesystem now by default sets all locale related envronment variables to C in order to avoid problems. - Make the makefile emulation mode for non-automake aware make programs like SunPro Make and GNU make more immune against oddities in the tr(1) program that are seen with a locale that differs from LC_ALL=C Another step to prevent some tr(1) oddities was to replace the call to tr(1) by a call to sed(1). - Added GMAKE_NOWARN=true to allow to disable the gmake warning - Enhanced include/schily/priv.h to distinct Solaris and AIX process privileges - New include file include/schily/math.h - Try to workaound a problem with GCC on newer AIX versions. It seems that e.g. gcc on AIX is not C99 compliant and does not support isnan(). Note that the current solution may compile and run on newer AIX versions but does not seem to be the optimal solution as it cannot check whether a float is a number or not. It is unfortunate, that we do not have an AIX login that would allow to implement better AIX support. Libschily: Libparanoia (Ported/enhanced by Jörg Schilling, originated by Monty xiphm...@mit.edu): Libedc (Optimized by Jörg Schilling, originated by Heiko Eißfeldt he...@hexco.de): Libcdrdeflt: Libdeflt: Libfind: Libfile: Libhfs_iso: Libsiconv: Libscg: - The low level SCSI transport code for Mac OS X has been reworked. The code now supports cdrecord -scanbus The code now supports cdrecord's autotarget mode The code now supports to communicate with BluRay drives The code now prints a longer help text that instructs what to do in order to work against the diskarbitrationd program on Mac OS that tries to steal us our hardware. If someone is able and willing to help, please send mail! I like to be able to tell diskarbitrationd to give up specific drives and to set up shared access. Libscgcmd: Libmdigest: Rscsi: Cdrecord: - The cdrecord man page now mentions that the -clone mode is a bad idea to copy audio CDs. Cdda2wav (Maintained/enhanced by Jörg Schilling, originated by Heiko Eißfeldt he...@hexco.de): Readcd: - The readcd man page now mentions that the -clone mode is a bad idea to copy audio CDs. Scgcheck: Scgskeleton: Btcflash: Mkisofs (Maintained/enhanced by Jörg Schilling since 1997, originated by Eric Youngdale): HELIOS TODO: - Add the HELIOS UNICODE mapping code. This needs to be done at UCS-2 level for Joliet and UDF (instead of UTF-8) and only for Rock Ridge (in case of a UTF-8 based target locale) using UTF-8 based translations. - Make the Apple extensions work again with mkisofs -find TODO: - Support correct inode numbers for UDF hardlinks - Support sockets, pipes, char/blk-dev specials with UDF - read Joliet filenames with multi-session if no TRANS.TBL or RR is present. I am looking for a volunteer for this task! Note that this can never be 100% correct as there is no relation between the names on the master (UNIX) filesystem, the ISO-9660 names and the Joliet names. Only the Rock Ridge names are untranslated with respect to the original files on the master (UNIX) filesystem. - add libecc/edc for CDI and similar. CYGWIN NT-4.0 NOTES: To compile on Cygwin32, get Cygwin and install it. For more information read README.win32 The files are located on: ftp://ftp.berlios.de/pub/cdrecord/alpha ... Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing xorriso-0.4.2
Thomas Schmitt scdbac...@gmx.net wrote: be invited to try the new release 0.4.2 of my program xorriso, a ISO 9660 Rock Ridge filesystem manipulator. It creates, loads, manipulates and writes ISO 9660 filesystem images with Rock Ridge extensions. Optionally it supports hard links, ACLs, xattr, and MD5 checksums. xorriso can load the management information of existing ISO images and it writes the session results to optical media or to filesystem objects. Hard links are part of the Rock Ridge standard. Did you ever test your hardlinks (on a OS that suppots hard links) for correctness? Just as a note: Linux does not support hard links on ISO-9660. Also please admit that there is no standard for ACLs or xattrs for ISO-9660. What you implement may be a nice toy but it is irrelevent for real world usage. What you implement is your private nonstandard proprietary extension on ISO-9660 that is based on the data structures of a POSIX _draft_ that was withdrawn 10 years ago in 1999 and thus never was a standard. It is not complatible to the ACL and xattr standard that is implemented on many recent OS and that is described here: http://www.ietf.org/rfc/rfc3530.txt See page 50 ff and page 178. Novelties: * New option -md5, new -as mkisofs option --md5 allow to record in the image MD5 checksums for the whole session and for each single data file. Mkisofs does not have a -md5 option. In case that mkisofs will eventually add a -md5 option, I cannot grant that this option will be compatible to what you implement. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.0
Thomas Schmitt scdbac...@gmx.net wrote: be invited to try the new version 0.7.0 of my program cdrskin, a burn backend for CD, DVD and BD. Hi, in cdrskin/README you claim: cdrskin does not contain any bytes copied from cdrecord's sources. This is not true. You even admit that libburn/lec.c is: borrowed HEAVILY from cdrdao Well, the code you borrowed from cdrdao is heavily based on old unoptimized code from cdrtools-2.0 (first added in cdrtools-1.11a30). The code was originally written by Heiko Eißfeldt in 1998-1999 and even in your code it is still possible to find similarities and even 100% identical code. Could you please correct your text? Thank you Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: growisofs problem
Bester, Neville P neville.bes...@amec.com wrote: Hello, I am trying to use growisofs on my HP C8000, under HP-UX 11.11 to record to DVD+R media. Command line is: growisofs -Z /dev/rdsk/c3t0d0 /directory I get the output: unable to INQUIRY: Permission denied I have ensured that the corresponding file c3t0l0 is setup correctly in /dev/rscsi growisofs version is 5.18, mkisofs version is 2.01 You are using a 5+ year old version of mkisofs, so you definitely should upgrade mkisofs... when doing this, you should try out cdrecord to write: ftp://ftp.berlios.de/pub/cdrecord/alpha/ Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
cdrtools-2.01.01a62 ready
NEW features of cdrtools-2.01.01a62: *** NOTE: cdrtools is currently in a state just before a new major release. *** All: - New include files include/schily/ctype.h, include/schily/pwd.h and include/schily/grp.h - All programs are now using schily/stdio.h for orthogonality. - Haiku default install dir is now /boot/opt/schily - New rules RULES/os-cygwin_nt-6.0-wow64.id and RULES/os-cygwin_nt-6.1-wow64.id support Cygwin on 64bit installations of Win Vista and Win 7. - New rules for compiling 64 Bit binaries on cygwin_nt-wow64 NOTE: You need to have a 64 bit aware gcc on Cygwin to use this! - TEMPLATES/temp-gcc.rul and TEMPLATES/temp-xcc.rul now correctly include cc-gcc.rul and cc-dumb.rul and thus make the automake feature working again for completely unknown platforms. - Fixed RULES/rules.inc to make sure we install xx.h instead of xx.h.exe - Workaround an infinite hang in an autoconf test on 64 Bit Vista with Cygwin - Include limits.h in schily/hostname.h for Linux - Several %s formats have been introduced in order to make gcc-4 happy even though the original strings have been pointer to constant and well known strings - Change the option order in the autoconf test for calling the linker in order to avoid problems with the microsoft linker. Libschily: - libschily now is thread aware and uses the thread specific errno value on Solaris, Linux and FreeBSD. Libparanoia (Ported/enhanced by Jörg Schilling, originated by Monty xiphm...@mit.edu): Libedc (Optimized by Jörg Schilling, originated by Heiko Eißfeldt he...@hexco.de): Libcdrdeflt: Libdeflt: Libfind: Libfile: Libhfs_iso: Libsiconv: Libscg: - Raised the SCSI Bus-number limit from 256 to 500 for Linux as a workaround for a resource leak bug in the linux kernel. The workaround lets the problem happen much later but cannot completely avoid it. If you are hit by the Linux kernel resource leak bug, you need to reboot. Libscgcmd: Rscsi: Cdrecord: - Correctly abort the FIFO in cdrecord on BeOS and Haiku in case that the clone ara cannot be made shared. Cdda2wav (Maintained/enhanced by Jörg Schilling, originated by Heiko Eißfeldt he...@hexco.de): Readcd: Scgcheck: Scgskeleton: Btcflash: Mkisofs (Maintained/enhanced by Jörg Schilling since 1997, originated by Eric Youngdale): - Fixed a potential malloc problem in mkisofs The files are located on: ftp://ftp.berlios.de/pub/cdrecord/alpha ... Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Defect management with DVD-RAM on Linux?
Yuri Baranov baran...@gmail.com wrote: Hi, everybody! When I chose DVD-RAM as the backup media for my data, the important factor was built-in hardware defect management. So I took for granted, that any OS which supports UDF writing, should also support automatic verification and reallocation of bad blocks. However, I recently has tried to copy a huge (about 4Gb file) database backup (Ubuntu Linux Server 8.04.3 , mount /dev/dvdram /mnt/dvdram cp /backup/hugefile /mnt/dvdram) I got a non-readable target file. dmesg output contained lines like [34.460831] Buffer I/O error on device sr0, logical block 54040 When I tried to copy smaller files (10-200Mb) to the disk - some of them copied OK and other still contained errors. Not every block of the medium was bad! Did you try sformat from the schily source consolidation at: ftp://ftp.berlios.de/pub/schily/ Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing xorriso-0.4.0
Risto Suominen risto.suomi...@gmail.com wrote: Hi, I had my first contact with xorriso. My aim was to restore hard links from ISOs. But no matter how hard I try, I cannot make it work. I have no idea whether xorriso-0.4.0 supports hard links as it seems to be nonportable and thus testing would be hard ;-) mkisofs supports hard links correctly by default since August 2006 but the problem is that the Linux kernel has no working hard link support for ISO-9660 or Rock Ridge. I recommend you to use a recent mkisofs ftp://ftp.berlios.de/pub/cdrecord/alpha/ as mkisofs grants you that the hard links you created on the media will work on platforms that correctly support hard links (e.g. Solaris). Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: ide-scsi - write_g1: scsi sendcmd: fatal error
Fog_Watch d...@exemail.com.au wrote: On Wed, 27 May 2009 22:26:34 +1000 Fog_Watch d...@exemail.com.au wrote: snip cdrecord: No such device or address. Cannot send SCSI cmd via ioctl. cdrecord: No such device or address. prevent/allow medium removal: scsi sendcmd: fatal error CDB: 1E 00 00 00 00 00 cmd finished after 0.000s timeout 200s The same error is returned with the more recent 2.01.01_alpha57. # uname -r 2.6.24-gentoo-r8 Any clues as to the cause of the error. Remember this one? I used two solutions for this. The first solution was to purchase an old SCSI writer: # cat /proc/scsi/scsi | grep Vendor Vendor: PLEXTOR Model: CD-R PX-W1210S Rev: 1.06 I am not sure about the reason for your mail... You are wuoting another mail in a way that makes it impossible to understand your problem and your current mail does not contain any information that could be related to your problem ...well if you have really strange problems, it always makes sense to look at hald (and kill it) as hald often interupts things on Linux. If you really have a problem, please send enough information to allow to understand your problem. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
cdrtools-2.01.01a61 ready
NEW features of cdrtools-2.01.01a61: *** NOTE: cdrtools is currently in a state just before a new major release. *** All: - Support for 64 bit compilation on mac OS X was added. Call make CCOM=cc64 as on other platforms. - $OLIBSDIR is no longer in the RUNPATH - New include file include/schily/limits.h - Make sure that all include files in include/schily/ include include/schily/mconfig.h - wide character support new - New makefile Mocsw sets defaults for opencsw instead of Blastwave. Mcsw for Blastwave of course continues to exist - New defaults directory DEFAULTS_CSW includes special defaults that compile e.g. for Sparc-V8 in order to get working binaries for older Sparc non 64 Bit hardware. - New autoconf test HAVE_SETBUF and HAVE_SETVBUF - Several modification in hope to better support MINGW Libschily: - wide character support new - sevaral str*.c functions new for orthogonality with the new wcs* code. - Added a wide character patern matcher with: patwcompile(), patwmatch(), patwlmatch() See files: libschily/matchw.c and libschily/matchwl.c - libschily/stdio/*.c fixed to use size_t as length parameter for read*()/write*() operations. Libparanoia (Ported/enhanced by Jörg Schilling, originated by Monty xiphm...@mit.edu): Libedc (Optimized by Jörg Schilling, originated by Heiko Eißfeldt he...@hexco.de): Libcdrdeflt: Libdeflt: Libfind: Libfile: Libhfs_iso: Libsiconv: Libscg: - Added a workaround for the type desaster in the Appls IOKit include files in order to support 64 bit binaries Libscgcmd: Rscsi: Cdrecord: Cdda2wav (Maintained/enhanced by Jörg Schilling, originated by Heiko Eißfeldt he...@hexco.de): - The -interactive option is now mentioned in the -help output and the man page. - Call unit_ready() before retrieving the TOC data in order to work around a Solaris scsa2usb (SCSA to USB Driver) bug. Readcd: - readcd no longer dumps core if the C2Scan function is selected from the interactive interface. Scgcheck: Scgskeleton: Btcflash: Mkisofs (Maintained/enhanced by Jörg Schilling since 1997, originated by Eric Youngdale): - Fixed a typo bug in the mkisofs man page that caused the two synopsis lines to appear as one line when using GNU troff. - isoinfo now prints ??? in case that an illegal month is in a ISO-9660 filesystem. HELIOS TODO: - Add the HELIOS UNICODE mapping code. This needs to be done at UCS-2 level for Joliet and UDF (instead of UTF-8) and only for Rock Ridge (in case of a UTF-8 based target locale) using UTF-8 based translations. - Make the Apple extensions work again with mkisofs -find TODO: - Support correct inode numbers for UDF hardlinks - Support sockets, pipes, char/blk-dev specials with UDF - read Joliet filenames with multi-session if no TRANS.TBL or RR is present. I am looking for a volunteer for this task! Note that this can never be 100% correct as there is no relation between the names on the master (UNIX) filesystem, the ISO-9660 names and the Joliet names. Only the Rock Ridge names are untranslated with respect to the original files on the master (UNIX) filesystem. - add libecc/edc for CDI and similar. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: iomega slim dvd burner
Andrew Wienecke revela...@gmail.com wrote: cd writing works, but dvd writing does not, it works in bsd, but both cd and dvd writing in bsd produce useless coasters. any insight? You unfortunately did not send any information on your problems What software do you use, what drive, what media and what problems do you have? Are you on Linux and use the defective and illegal cdrtools fork called wdoim/cdrkit? Do you use recent official software from: ftp://ftp.berlios.de/pub/cdrecord/alpha/ Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing xorriso-0.4.0
Thomas Schmitt scdbac...@gmx.net wrote: be invited to try the new release 0.4.0 of my program xorriso, a ISO 9660 Rock Ridge filesystem manipulator. It creates, loads, manipulates and writes ISO 9660 filesystem images with Rock Ridge extensions. Optionally it supports hard links, ACLs and xattr. Did you verify correct behavior of the hard link support? Could you please remove ACLs and xattr from your text as there is no such feature in ISO-9660 or Rock Ridge? Novelties: * New option -hardlinks enables recording and restoring of hard link relations. * Improved reading performance with -update_r and -extract. * New option -for_backup as shortcut for -acl -xattr -hardlinks * Operators with option -find : -not, -or, -and, (, ), -if, -then, -else * New -find tests -wholename, -prune Why do ou try to pretend that there is libfind support without supporting a real find(1) command line? Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
