Re: Issues brining BD disks from the command line - write failures
Volker Kuhlmann wrote: On Thu 09 May 2013 19:01:12 NZST +1200, Thomas Schmitt wrote: This happens only with CDs which were written in write type TAO. Ehh, I'm very sure I've seen it with DVDs too, and the read-ahead size there was larger. Nevertheless, that is a _read_ problem. Dale has a problem with write errors. Sure, but you asked him to test afterwards by reading back. The read-ahead bug has never been observed with DVD or BD, anyway. I have to disagree for DVD, and can't speak for BD, not having tried it. To my experience, 128 KB is enough. Tradition is 300 KB, out of a wrong perception of Linux bug and MMC specs. Actually it depends on the size of reading ahead. So it might vary. I got so sick of it, I set the value in my script to 2MB to be done with it. I know it's too big, but I don't care. And what are the options for UDF (which is becoming increasingly necessary)? mkudffs and cp. But for what, particularly ? Random-file-access backups. TBH I stopped burning because 4.2GB isn't of much use these days, but wouldn't mind burning some larger disks. I used ext2 in the past, useless for reading from, but good enough for dd'ing back to disk before reading. With larger sizuseless for reading from es that becomes a bit annoying. Why useless for reading from? What problems do you have when mounting read-only for use? Haven't done it in a while, but I don't recall doing anything magic, and I certainly have used such media to preserve odd filesystem things like hard links, ACLs, etc. I create an empty file, make a filesystem on it, mount it, copy what I need, umount it, and burn. I had to do a bunch of those two years ago. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org Archive: http://lists.debian.org/518e815c.9050...@tmr.com
Re: 2-session DVD: Windows show old content Linux show new?
Gildor Oronar wrote: Hello. Using xorriso to burn DVD the second time (without -multi, a.k.a. there is no 3rd session). The image is created using genisoimage -C (but not using -M, a.k.a. the old and new content are not related). The burnt DVD - with Linux (gnome), new content is mounted. With Windows XP, old content is mounted and show. So my question is: 1. Did I do anything wrong? Or does Windows/Linux handle session display differently? 2. If I can reliably reproduce this issue, wouldn't that be a way to prepare different content for Windows/Linux? e.g. for a Game CD, have windows installer and Linux installer on the same CD but different track/session. Have you tried mounting on a Win7 system? XP is quite old, and particularly if it is not fully patched this behavior may reflect a design decision changed decades ago. It would also be instructive to try this on another burner, just on the off chance that some subtle design choice in the firmware is in play. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org Archive: http://lists.debian.org/4f96b48a.9050...@tmr.com
Re: 2-session DVD: Linux shows new session's data while windows shows old sessions
Zhang Weiwu wrote: On Mon, 23 Apr 2012, Thomas Schmitt wrote: That might make a difference to the reading drive. Some drives present some types of closed DVD as DVD-ROM. It might be that MS-Windows does not expect a DVD-ROM to have multiple sessions. So if the drive does this with DVD-R but not with DVD+R, then this might be the trigger. Maybe some MS-Windows software can tell you more about how the drive presents the medium. If not, consider to boot a Live-CD with Linux that contains dvd+rw-mediainfo, cdrskin, or xorriso. E.g. RIPLinux. 1. Doses Windows/Linux handle multi-session differently? Either this, or the drive makes the difference, or both. I tried to reproduce another multi-session DVD-R from the same pack, except I use 'cdrskin -multi' this time. Then I did a few tests: For what it's worth, very good testing, and clearly indicates that the media and mounting host OS are the most important determinants. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org Archive: http://lists.debian.org/4f972d42.9040...@tmr.com
Re: Q: state of the art in burning a BD
Thomas Schmitt wrote: Hi, since Christmas I have a blu-ray writer. Congrats. What is the state-of-the-art in generating a BD especially when it comes to generating files of size greater than 4 Gb? P.S. Nero-linux writes an UDF system which can be mounted by Linux. mkisofs says it has only UDF support in alpha state. There are content format specifications for Blu-ray entertainment (video) disks. But elsewise you are free to store on them any filesystem or archive format that you deem suitable. As with CD or DVD. I myself use ISO 9660 (level 3) with Rock Ridge extensions via my program xorriso. Currently it can create images with files of up to 400 GB. This limit is artificial, though. The only hard limit is 8 TB overall image size (32 bit block address, block size 2048 = 2 exp 11). With BD-RE you may create read-write filesystems and run them like giant floppies resp. slow USB sticks. This media type resembles much DVD-RAM or formatted CD-RW. All UDF examples which mention these media and state should apply to BD-RE too. Examples for DVD+RW or formatted DVD-RW should work too. On my GNU/Linux system i have /usr/src/linux/Documentation/filesystems/udf.txt BD-R media media resemble DVD+R (and somewhat CD-R). You will need a burn program for writing them, and a formatter program to produce the image that shall be written. I prefer to use BD-RE this way, too. Throughput is much better. Especially if one disables automatic checkreading. I can see disabling checkreading if you don't care if you can't read what you wrote, such as video, where a bit or two or even on 32k sector isn't going to spoil the use. But in general I write a boatload of data on the media to preserve it, and would happily trade double the time for more reliable operation. For critical operation an additional software protection program like dvdisaster would be useful as well, there are something you really don't want to lose. Just my thinking on picking the right speed and size vs. reliability point. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org Archive: http://lists.debian.org/4f08c9bd.2020...@tmr.com
Re: Blu-Ray GUI burning tool
Helmut Jarausch wrote: Hi, which (GUI) tool do you use for burning Blu-Ray-disks? Since I don't use KDE nor GNOME, I'd prefer something like TkDVD or the good old xcdroast. What has to fixed for these tools to enable them burning a Blu-Ray disk? Is it just the missing capacities which are not listed? It might be worth the time to learn to use the command line tools, then you would know what the tools are really doing. I've been bitten by GUI tools which don't actually *do* anything, but call the command line tools to do it for them. And if something changes under them, you don't even get a warning, just a coaster. Then you get distributions which trick you and put bogus programs of their own devicing installed with the names of working programs. The most common case is a bogus 'cdrecord' which is actually something called 'worful' or maybe 'woodn' or something like that. Best program for making BD-coasters ever, but for saving data not so much. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org Archive: http://lists.debian.org/4f08c67e.8010...@tmr.com
Re: what difference xorriso is it going to make on the user interface?
Joerg Schilling wrote: Thomas Schmittscdbac...@gmx.net wrote: As we are at it, mkisofs can produce HFS images and simple UDF, which xorriso cannot. I am planning to remove HFS support in the future as it seems to be unlikely tha there is a noticable number of Mac OS 9 users left over today. As noted below others are using it. I assume that the effort of maintaining the capability is low (zero?) and making an effort to remove a feature which is being used takes your time and gives one more thing for someone to complain about. Note that mkisofs of cource supports much more than simple UDF. While genisoimage is dead since it has been begun and stays as the feature set from September 2004, mkisofs has seen many enhancements - in special for UDF. There are e.g. Apple specific UDF enhancements. HFS is needed for production of bootable Debian images for PowerPC. (They still have to use genisoimage for that.) Here i lack entirely of specs and would have to explore open source code. If they use this, they are doing it wrong. That is possible, but it's being usefully employed, and it's their distribution. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org Archive: http://lists.debian.org/4de3dc42.50...@tmr.com
Re: problems with LG BH10LS30 BD-RE
Volker Kuhlmann wrote: On Tue 26 Apr 2011 04:22:24 NZST +1200, Thomas Schmitt wrote: Hi, Hello Thomas and J?rg, thanks much for your fast replies! Well, i did not see Joergs's first one. Jörg has not posted to this list in many months. For a while now this list has been so quiet I had started to wonder whether everyone moved to another one. I think it is more a case that fewer people are having problems with current tools. Those who do have problems are using forks like wodim in some cases, AFAIK the maintainers (if any) aren't here. A tad more spam filtering would be nice, but clients can do it at their end still. I am sorry Joerg no longer posts here, I suspect I miss his updates if he does them. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org Archive: http://lists.debian.org/4dd2c125.2070...@tmr.com
Re: what difference xorriso is it going to make on the user interface?
Thomas Schmitt wrote: Hi, If you imagine the difference between xorriso and older utilities, what do you think is the main difference that can be reflected on the user experience? That is, what difference does it make if a desktop DVD burning application make use of xorriso that it can offer a unique feature or competition advantage over others? The combination of mkisofs, cdrecord and growisofs still covers most needs of the users. One needs to know the particular properties of the various media types, though. I consider xorriso to be more consistent in its unified view on all kinds of storage media: CD, DVD, BD, block devices, disk files, character devices, pipes. This advantage is best visible if one uses its own commands rather than the emulations of mkisofs and cdrecord. Nevertheless, the cdrecord emulation extends the CD multi-session model for ISO 9660 images to nearly all DVD types and to both BD types. (Use option --grow_overwriteable_iso) xorriso covers the whole life cycle of an ISO image: Creation, expansion, manipulation, extraction of files. It lists the existing sessions and helps with mounting any of them on Linux and FreeBSD. (Solaris is incapable in some cases.) It has strong extra features for data backup. - MD5 checksums of each data file and of the whole session. It has commands for verifying the checksums and for printing them. - Incremental backups may be based either on inode+time, MD5, or plain comparison of file contents. - Transparent zisofs compression (readable on Linux only). - Visible gzip compression. - External filter programs for other compression or encryption. (Quite slow due to forking the filter processes twice per filtered data file.) - Recording and restoring of Linux ACLs and Linux xattr. - Fast mass extraction of files without rattling the DVD drive. xorriso is prepared to serve as slave process under a frontend program. Its options -dialog, -mark and -pkt_output allow the master to send commands into xorriso's stdin and to receive their results and messages from xorriso's stdout. Last but not least, i try to offer user-friendly support. :)) That you do. The one feature of cdrecord which seems to be unique is burning VCD and SVCD images. Since the price of DVD media has dropped and more people have hardware support, use of CD for video is a very special case. I confess I have not used anything other than cdrecord to burn audio CD, so I can't speak for how well that works in other tools. And I still use command line tools directly, based on decades of experience with tools which sit between the user and the command line tool, they have a tendency to make the the process easier to use, and and to make work. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org Archive: http://lists.debian.org/4dd2c39a.6070...@tmr.com
Re: what difference xorriso is it going to make on the user interface?
Thomas Schmitt wrote: Hi, Rob Bogusro...@tmr.com wrote: The one feature of cdrecord which seems to be unique is burning VCD and SVCD images. Since the price of DVD media has dropped and more people have hardware support, use of CD for video is a very special case. cdrecord and its clones implement knowledge about CD recording which i cannot read completely from the MMC specs. I guess i could implement most of the exotic stuff in SAO mode but raw CD recording is still quite a riddle to me. The main reason why i never made experiments in that direction is that i simply have no use case and no users for this. We have stacks of CD media and a few people who actually like VCD format, so short stuff does get put in the way. It is a skill which must be refreshed or you wind up working from notes without understanding. Besides, if the tool chain breaks, who would know if we didn't do this? I confess I have not used anything other than cdrecord to burn audio CD, so I can't speak for how well that works in other tools. CD TEXT is another point where i lack of technical details. I could probably learn from libcdio if an interested user would show up. xorriso does only sessions with a single data track. cdrskin is able to record pure audio CDs, but not the CD-XA format that is prescribed for CD which contain audio and data tracks. As we are at it, mkisofs can produce HFS images and simple UDF, which xorriso cannot. HFS is needed for production of bootable Debian images for PowerPC. (They still have to use genisoimage for that.) Here i lack entirely of specs and would have to explore open source code. UDF would allow to record video DVDs which comply to the specs for livingroom DVD players. UDF is openly specified as ECMA-167 plus UDF-2.60. Mind twisting. I happily find excuses to do other things first. But you can generate an image to a disk file and burn it as just data for many of these (which don't need arcane write formats). I confess that we burn ext2 filesystems to DVD, since they are for use with Linux systems and ISO9660 is not needed. We just write them to a file loop mounted and formatted, then burn the image. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org Archive: http://lists.debian.org/4dd2dd33.2070...@tmr.com
Re: CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB: not harmless?
Thomas Schmitt wrote: Hi, me: Such a message is rarely harmless. Jens: Well, that's what I thought, but Andy Polyakov commented here: http://www.mail-archive.com/cdwrite@other.debian.org/msg12106.html Oh indeed. Now i remember. I stepped into that puddle previously. So for now we count it as harmless. It is quite out of suspicion anyway. See below. smally$ sudo cmp /dev/sr1 /video/oldc_backup.udf ; echo $? /dev/sr1 /video/oldc_backup.udf differ: byte 8585217, line 20010 (my command seemed simpler :-) and as effective) I wanted to truncate /dev/sr1 to the exact size just in case all bytes before match the original and trailing trash would cause false alert. When I read the block from /dev/sr0 what I get back is all-zeroes. The corresponding block on the udf image is full of non-zero data. the next 2048-byte block following 8585216 on /dev/sr1 is non-zero. Ouchers. That looks much like a failure of transport or drive. It happens far before any Close Session failure could spoil it directly, and it is hard to imagine how such a final problem should leave 8 MB unaltered and spoil a single block of 2048 bytes. If possible try to find out whether there are more differing blocks in the image. It is a bit astounding that a first altered block at that address disturbed the UDF tree without any error message. Did you check your kernel logs already ? Spare Area:65088/65536=99.3% free Could it be that there was a defect and things were relocated? I don't really know how the spare area is used. Actually i never saw it doing any good. It should be transparent to the reader in any case. If the drive hands out logical block 4192 then this should be the corrected data which belong to that address. Any physical address change should be hidden from the reader. It seems the Defect Management had reason to exchange some physical blocks. Of course it is suspicious if the media shows altered blocks afterwards. Normally at least the error detection precautions should have indicated a failure. So this could be a failure of the firmware to correctly perform Defect Management. Is it possible that this is caused by a relocated block, and for some reason the read is returning the bad block in stead of the relocation? In other words, did this mount somehow tell the device to ignore relocation? Might this be fixed with only a mount option (which I certainly didn't see)? On BD-RE i normally disable it in favor of triple speed and own MD5 checkreading. I have a BD burner and a BD reader drive so that with bulk backups i reach nearly triple throughput by simultaneaously writing and reading. -- E. Robert Bogusta It seemed like a good idea at the time -- 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
Joerg Schilling wrote: 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 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. 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 -- E. Robert Bogusta It seemed like a good idea at the time -- 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
Joerg Schilling wrote: Rob Bogus ro...@tmr.com wrote: Unsupported, undocumented, self-written, run as root... for problems any method which provides useful information is appropriate. This is not I am sorry to see that you seem to be interested to further increase the confusion. Let me try to help to reduce confusion. Thomas Schmitt unfortunately caused confusion by asking the OP to check /proc/ although this is unrelated to cdrtools. But it may be related to solving the poster's problem. You seem to have it both ways, any problem could not be in cdrecord so it must be in Linux, but any investigation of the Linux characteristics if confusing because it isn't cdrecord. Do you not see how you are contradicting yourself? Thomas Schmitt unfortunately caused confusion by asking the OP to test dev= parameters that are ducumented to be wrong. Thomas Schmitt unfortunately caused confusion by introducing cdrskin although the OP is interested in rscsi. rscsi is a protocol that is part of libscg. Software that makes use of the collaboration in the OSS community and uses libscg may work on any OS platform and gets the ability to use rscsi for free. cdrskin does not use libscg. Rob Bogus added a lot of other unrelated things. Cdrecord depends on a correctly working kernel and correctly working drivers. Had you said that rather than commenting on some vanilla kernel I would not have gotten into this, but the truth is that there isn't a standard compilation configuration, and virtually all vendor kernels have at least some patches applied which haven't made it to stable. If the OP replaces the ugly but working PATA HDD driver by ide-scsi that may not work correctly on his Linux version, then the OP needs to be prepared for a non working cdrecord. There are many reasons for using ide-scsi, but I agree that recent kernels seem to do burners for optical media fine without ide-scsi. It still seems desirable to use it for certain ide tape drives, and for ZIP and LS120 ide drives. There are basically two methods to fix this problem. 1) fix ide-scsi or let it be fixed by the linux kernel folks 2) use the supported PATA HDD driver (i.e. remove ide-scsi) Again we agree, I would like to see (1), but (2) is easier. -- E. Robert Bogusta It seemed like a good idea at the time -- 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
Joerg Schilling wrote: Thomas Schmitt scdbac...@gmx.net wrote: Hi, Fog_Watch: cdrecord using ide-scsi returns an error that I don't understand. ... cdrecord: No such device or address. Cannot send SCSI cmd via ioctl. Joerg Schilling: This is a Linux kernel problem, please ask the related people. 2.6.24-gentoo-r8 Well, ide-scsi is said to be deprecated with kernel 2.6. This is not a helpful reply. One should at least find out a bit more before exposing oneself at LKML. What do you get from this command ? cdrecord -scanbus If the OP did create an own rotten kernel this will not help. Custom does not imply rotten many people build kernels without support things for hardware they lack and features they avoid. ide-scsi seems to be buggy and unmaintained in newer Linux releases. I would say lightly tested for sure, based on one machine still using that feature, it seems to work using a ZIP100 drive as a scsi disk. cdrecord -scanbus on a _vanilla_ Linux kernel will work as well as There *is* no vanilla kernel, virtually every distribution and developer picks different configuration options to build the kernel, even though the code base is the same. just calling cdrecord ... _without_ dev= parameter Most users have only one drive and in this case, cdrecord will automagically search for the right device. I doubt your assumption is right about most users, but in the case where only a single drive is present the application does identify it and use it. This is how the typical output from a cdrecord -scanbus call looks on a vanilla 2.6.13 Linux kernel: cdrecord -scanbus Cdrecord-ProDVD-ProBD-Clone 2.01.01a60 (i686-pc-linux-gnu) Copyright (C) 1995-2009 Jörg Schilling Linux sg driver version: 3.5.27 Using libscg version 'schily-0.9'. scsibus0: 0,0,0 0) 'QUANTUM ' 'ATLAS10K2-TY184L' 'DA40' Disk 0,1,0 1) * 0,2,0 2) * 0,3,0 3) * 0,4,0 4) * 0,5,0 5) * 0,6,0 6) * 0,7,0 7) * scsibus1001: 1001,0,0 100100) 'MITSUMI ' 'CD-ROM FX4830T!B' 'R02J' Removable CD-ROM 1001,1,0 100101) * 1001,2,0 100102) * 1001,3,0 100103) * 1001,4,0 100104) * 1001,5,0 100105) * 1001,6,0 100106) * 1001,7,0 100107) * As you see, there is no need to hand craft e linux kernel - cdrecord works around the oddities in the Linux device addressing ;-) The usual reason for trimming the configuration is to get a compile done before the next revision of the kernel comes out. Related question: does cdrecord do the right thing if the only burner is on rscsi? -- E. Robert Bogusta It seemed like a good idea at the time -- 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
Joerg Schilling wrote: Thomas Schmitt scdbac...@gmx.net wrote: cdrecord -scanbus Full record. Something like this ? scsibus0: 0,0,0 0) 'TSSTcorp' 'CDDVDW SH-S203B ' 'SB00' Removable CD-ROM 0,1,0 1) * .. (This is a SATA attached drive. It appears as SCSI without ide-scsi emulation.) eject /dev/sr0 Yes. Then try cdrecord dev=/dev/sr0 -dao ... rather than cdrecord dev=0,0,0 -dao ... Is there any reson to recommend _unsupported_ command line usage? Unsupported, undocumented, self-written, run as root... for problems any method which provides useful information is appropriate. This is not endorsement for production use, only a suggestion for characterizing the problem. Note, I don't say solving but do imply understanding. cdrecord works just fine out of the box if you either _don't_ use dev= at all or id you use the official SCSI device syntax. It works fine out of the box providing I want to use the burner it chooses. Having more than one is no longer unusual, a number of systems come with a reader and a burner these days. As to official, I have no doubt that you can cite some organization which says to do things the way you do, and you have decided they do it your way and so are official. I'm old enough to remember SCSI back when, and where were always four numbers, not the three you choose to support. These were the slot number, the bus number, the device number and the LUN number, and that was back when device number was 0..7 and LUNs often selected 556bpi tape drives. If it does not work this way, there is a bug in the kernel code. Jörg -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: cdrecord floating point exception
Parker Jones wrote: Hi Thomas, It is advisable to use a different program for DVD purposes. E.g: growisofs, cdrecord, cdrskin, xorriso. (I am author of the latter two.) DVD+RW should be simply writeable via their device file. Try: dd if=newworld.iso bs=2048 of=/dev/dvd Maybe the kernel is smarter than the burn program. I tried this and here's the output: $ dd if=~/newworld.iso bs=2048 of=/dev/dvd dd: writing `/dev/dvd': No space left on device 2+0 records in 1+0 records out 2048 bytes (2.0 kB) copied, 0.080821 s, 25.3 kB/s I guessed this was because the media needed formatting which I did with dvd+rw-format /dev/dvd but the outcome was still the same. I tried cdrecord because growisofs didn't work (see thread about a fortnight ago). So this may not be software related. But it would still be nice to get a clear error message indicating what has gone wrong. I don't think you burner likes this media, but I would suggest formatting as a separate step, with cdrecord or dvd+rw-format, then leave off options like -dao and let the software pick a mode. I agree about the messages not be clear to a typical user, but your results with dd indicate issues other than the application. -- E. Robert Bogusta It seemed like a good idea at the time
Re: cdrecord floating point exception
Joerg Schilling wrote: Thomas Schmitt scdbac...@gmx.net wrote: Hi, The fork (when started in september 2006) removed the original DVD code and replaced it by something that does not work. I have no idea why the initiators of the fork replaced working code... To my observation the timeline was: - Fork of cdrkit (cdrecord became wodim). I think that's right, and by big complaint is that they called their fork cdrecord because people didn't use wodim. - Introduction of DVD code into the fork (from program dvdrecord ?). - Soon later you released the cdrecord-ProDVD functionality as cdrtools source tarball. It looks as if you are a victim of the FUD spread by Debian :-( There always was only one cdrecord source code since it's creation in late 1995. The first DVD support code was added in February 1998 but could not be made OpenSource due to an NDA. Anyway, the DVD support in cdrecord code became OpenSource long before the fork wodim was created. Perhaps before the name was used, but there was a fork with DVD capability before cdrecord got the ProDVD code. I used it because I had too many problems with the licensing of ProDVD and couldn't get permission to install it. Why don't you inform yourself from the official cdrecord website? Official how? It's your version of history, your memory, your inside information. That doesn't make it right or wrong, but it's no more official or authoritative than the Debian version or my own recollection. We did burn DVDs with other software before cdrecord included the code, if you believe it or not. Maybe you and Dr Norbert could take your pissing contest to email and off this list. As i stated towards Parker Jones: If growisofs cannot handle drive and media then there is few hope that others can. (I deem my programs not worse than growisofs but they cannot claim to be better when it comes to DVD writing.) If you observe the net, you will see that there are many people who report that they use cdrecord to write DVDs because growisofs is not working for them.. Jörg -- E. Robert Bogusta It seemed like a good idea at the time
Re: cdrecord floating point exception
Thomas Schmitt wrote: Hi, There always was only one cdrecord source code since it's creation in late 1995. The first DVD support code was added in February 1998 but could not be made OpenSource due to an NDA. Anyway, the DVD support in cdrecord code became OpenSource long before the fork wodim was created. Indeed the sequence was 1) End of ProDVD (May 2006) 2) Fork of cdrkit (Oct 2006) But the release of ProDVD functionality in cdrtools source tarballs marks exactly the point where the fork took off: http://lists.debian.org/cdwrite/2006/05/msg00021.html Here you announce cdrtools-2.01.01a09 and mention CDDL. The fork of cdrkit is based on cdrtools-2.01.01a08. http://en.wikipedia.org/wiki/Cdrkit So they probably did not take your DVD code because they assumed that it is not under GPL. But there were other programs capable of burning DVDs before that, based on hacked cdrecord code. They may not have been wodim, or were not called wodim, but they certainly existed. They even worked, if you found the right media for your burner. I don't miss SCSI burners a bit! -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: cdrecord floating point exception
Norbert Preining wrote: On Fr, 30 Jan 2009, Joerg Schilling wrote: that are responsible for introducing various bugs and license violations call themself Debian packet maintainer. Stop talking nonsense and lies on a debian list, or I will try to get you banned from that list. What is it that you claim is a lie? 1 - that the changes from cdrecord to wodim were done by people called Debian packet maintainer 2 - that those changes don't introduce bugs (or the failures to work are somehow not bugs) 3 - that wodim is distributed under a different and conflicting license from the original cdrecord When you call someone a liar in a public forum, it's good to be able to back up your claim. Best wishes Norbert --- Dr. Norbert Preining prein...@logic.atVienna University of Technology Debian Developer prein...@debian.org Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- EWELME (n.) The smile bestowed on you by an air hostess. --- Douglas Adams, The Meaning of Liff -- E. Robert Bogusta It seemed like a good idea at the time
Re: cdrecord floating point exception
Joerg Schilling wrote: From zoubi...@hotmail.com Fri Jan 30 21:07:19 2009 You did not install cdrecord correctly as you see from this messages. Cdrecord needs to be installed suid root in order to be able to open all needed devices and in order to send all needed SCSI commands. When are you going to fix that? Other software can burn without being root, clearly it can be done. If there are better commands to use with a drive a check can be made to see if cdrecord is running as root. Actually I thought that you had provided an option, -mmc or similar, to use only the commands common to the standard. As people become more careful about security fewer systems will allow setuid root programs. Trying to clear drive status. This may be from a drive firmware bug or frim running hald (hald is non-cooperatively). Try to kill hald and retry cdrecord after correctly installing it suid root. Time to learn to use a scalpel instead of a chain saw... You don't just kill hald on most modern distributions, things stop working. And the problem is not in hald at all, it's in the rules given to hald for handling the drive, usually a 70_something rule, which you can edit or remove to prevent probing and automounting. This problem looks like firmware or bad media though. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Thoughts on writing CD from stdin
Thomas Schmitt wrote: Hi, Dave Platt wrote: Unfortunately, determining the end-of-data (end-of-track) location on a data CD is one of those things which is difficult-to-impossible to do reliably. This is actually a matter of the device driver and not so much of drive and media. The size of a logical track as obtained by MMC commands is reliable. One just has to be aware that not all types of sectors can be read by the SCSI command for reading data blocks. In the special case of CD TAO data tracks there are two such non-data blocks at the end of each track. (Not related to Darth Bane's Rule Of Two.) With CD SAO data tracks there are no such non-data blocks in the range of the official track size. All DVD types seem to be clean in that aspect, too. (No non-data sectors are defined for non-CD in MMC.) - The last data block reads back reliably. Attempting to read the block following it does return an error, but only after a substantial delay. - The last data block (or even the last couple of data blocks) are unreadable. Attempting to read them results in an I/O error. ... when transitioning between tracks having different modes ... The behavior of the Linux block device driver created several urban legends. To my theory it reads in larger chunks up to the track end. When the last chunk of a TAO track is read, the two unreadable sectors are encountered and let the whole chunk fail. If the driver would retry with a chunk size that is two sectors smaller, then it would be ok. But the driver does not. It just declares i/o error. The readahead size can be set by the 'blockdev' command, but smaller sizes hurt performance. I believe the error was fixed a few kernel versions ago, so that a clean partial read count is returned. I haven't validated that for all write modes, and perhaps I should for purposes of discussion. Chunk size is smaller than 300 kB. That's why that size of padding is a traditional remedy for track content which can recognize its proper end. Whatever, if you read the CD TAO track by own SCSI read commands it is easy to retrieve the exact amount of data which has been written to that track. libburn test program telltoc can demonstrate that. The readable amount includes any padding by formatter and burn program, of course. So padding, which helps with the block device driver, is rather counterproductive if you have a reader which works flawless. With a correct reader one has to memorize the amount of padding and ignore that many bytes at the end of the data. Padding at write time and ignoring pad bytes at read time is just a guess how to fool the CD TAO bug in the Linux driver. Bill Davidsen wrote: The data is in 64k chunks, so all writes are sector complete. I haven't had any issues with reading the data off DVD, or off CD Having data aligned to a size larger than 2 blocks (= 4 kB) can be another remedy for the driver problem. It depends on the assumption that the driver will not attempt to read ahaead of the data amount which is demanded by the user space program. Large alignment size will probably help to fulfill that assumption. Have a nice day :) Thomas -- E. Robert Bogusta It seemed like a good idea at the time
Re: What does this error mean ?
Gregoire Favre wrote: Hello, How about telling us which software you used and which OS? And if you use something called cdrecord is it the version from the author, or the fake some Linux distributions include which is confusingly called by the same name, so scripts would use their software instead of the original. a burn ended like this : Track 01: 3219 of 4227 MB written (fifo 100%) [buf 100%] 4.3x. 99.79% done, estimate finish Tue Dec 23 20:52:18 2008 Track 01: 3227 of 4227 MB written (fifo 100%) [buf 100%] 4.1x.Total translation table size: 0 Total rockridge attributes bytes: 3728 Total directory bytes: 2048 Path table size(bytes): 26 Max brk space used 0 2164544 extents written (4227 MB) Track 01: 4227 of 4227 MB written (fifo 100%) [buf 100%] 4.3x. Track 01: Total bytes read/written: 4432986112/4432986112 (2164544 sectors). Writing time: 868.604s Average write speed 3.7x. Min drive buffer fill was 99% Fixating... cdrecord: Input/output error. flush cache: scsi sendcmd: no error CDB: 35 00 00 00 00 00 00 00 00 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 71 00 03 00 00 00 00 0A 00 00 00 00 73 04 00 00 Sense Key: 0x3 Medium Error, deferred error, Segment 0 Sense Code: 0x73 Qual 0x04 (program memory area update failure) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 57.902s timeout 1000s Trouble flushing the cache cdrecord: Cannot fixate disk. Fixating time: 57.902s cdrecord: fifo had 45095 puts and 45095 gets. cdrecord: fifo was 0 times empty and 30117 times full, min fill was 99%. Thanks. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: cdrtools-2.01.01a42 ready
Joerg Schilling wrote: Rob Bogus [EMAIL PROTECTED] wrote: Libedc (Optimized by Jörg Schilling, originated by Heiko Eißfeldt [EMAIL PROTECTED]): - Fixed array index overrun in L1 coder. Thanks to Heiko Eißfeldt. The problem was reported by the coverity test. Note that the L1 coder is not used by cdrtools. Verified operation with DVD+DL 8GB images, SVCD, FC9. Burning looks solid with all versions of the kernel I tried, and all major variations. Thank you for this test! It is however not related to the libedc change ;-) I know, but after the discussion of layer-break, I wanted to just give it a large image and let cdrecord figure out the break. Then I had some other stuff, on various other operating system, so I did the test. It was all stuff I had to do, but I did move the data between machines a few times to allow testing with various O/S. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01.01a42 ready
Joerg Schilling wrote: NEW features of cdrtools-2.01.01a42: *** NOTE: cdrtools is currently in a state just before a new major release. *** All: Libschily: Libparanoia (Ported/enhanced by Jörg Schilling, originated by Monty [EMAIL PROTECTED]): Libedc (Optimized by Jörg Schilling, originated by Heiko Eißfeldt [EMAIL PROTECTED]): - Fixed array index overrun in L1 coder. Thanks to Heiko Eißfeldt. The problem was reported by the coverity test. Note that the L1 coder is not used by cdrtools. Verified operation with DVD+DL 8GB images, SVCD, FC9. Burning looks solid with all versions of the kernel I tried, and all major variations. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: WRITE@LBA=3e0c30h failed with SK=3h/WRITE ERROR]: Input/output error (DL)
Joerg Schilling wrote: Gregoire Favre [EMAIL PROTECTED] wrote: On Thu, May 15, 2008 at 05:20:31PM +0200, Joerg Schilling wrote: I asume that cdrecord works also? If you speak about single layer DVD, yes, cdrecord works just perfectly :-) But if we speak about DVD+R DL no it has the same behaviour than cdrskin. If you get a write error, this is an incompatibility of the drive and the medium. That is likely to be true, but I was able to avoid this behavior with manual layer break. Thoughts on that? Media are expensive, tricks to save them cheap. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: WRITE@LBA=3e0c30h failed with SK=3h/WRITE ERROR]: Input/output error (DL)
Thomas Schmitt wrote: Hi, I would like to just try to burn one big file into a DVD+R DL (about 8Gb), what command using cdrskin would you recommend ? In general it should work on DVD with the same options as cdrecord accepts for DVD and some options known from cdrecord with CD. Well, meanwhile you found out yourself: COMCD=-speed=$3 -v dev=2,0,0 -dao fs=1000m ... mkisofs $OPTS -V $1 $2|cdrskin $COMCD tsize=$SIZEs - This should be ok. Track 01: 4211 of 8138 MB written (fifo 100%) [buf 99%] 4.0x.cdrskin: FATAL : SCSI error on write(2156064,16): key=3 asc=0Ch ascq=00h That's the same write error as with growisofs. Only at a different sector address. From the specs: 3 0C 00 WRITE ERROR More is not explained by this code. The address is suspiciously near the layer break address. The error occurs at 2156064 * 2048 = 4415619072 bytes Media capacity of both layers together is reported as: Free Blocks: 4173824*2KB The error spot is 69152 blocks = 140 MB _after_ the middle of this size. That is much more than any buffer delay in the drive could cause. So i can see no systematic correlation between layer break and error spot. (The layer break is what mainly distinguishes DVD+R DL from all other widely used DVD media.) To me it looks like bad media. If only Nero would be so nice to produce a misburn too ... (The cdrecord error which you reported on May 9 happens quite exactly at half image size and issues an error code 0 00 03 which is not listed in MMC-5 specs. So that error is still suspicious of systematic correlation with the layer break.) ata3: limiting SATA link speed to 1.5 Gbps ata3: hard resetting link ata3: COMRESET failed (errno=-16) ata3: reset failed, giving up ata3.00: disabled I am not a kernel expert. Hard to say whether this documents the cause or the consequences of the write error. Any other ideas ? cdrskin announces the size to the drive in advance if -dao is given or the size is known. With -tao or with unknown size, it would start a write run with unannounced size. (Here it deviates much from cdrecord on DVD.) So you could try this: COMCD=-speed=$3 -v dev=2,0,0 -tao fs=1000m ... mkisofs $OPTS -V $1 $2|cdrskin $COMCD - But i do not really expect that this is the decisive difference. If it works, i would suspect it to be a lucky incident, as i suspect with Nero. You may check whether my prediction is correct that the next error will happen at a different sector address or that some write runs even succeed completely. (I believe your growisofs run nearly made it.) I suspect that layer break is a (the?) cause here, if it would be possible to specify the break a percent or two short of half the advertised capacity, I suspect it would work, based on some attempts I made a few months ago (with older versions of all the software). It's not clear how the layer break is determined if it isn't specified, the method was explained in conflicting ways in what I read, so I assumed that the break didn't happen by itself, even with a single large ISO image. Is it intended that butning an 8.2GB image would just work? I tried the current versions of various software (va36 of cdrecord, I believe) and none worked without specifying a break. You should verify that Nero really reproducibly can write the full media without errors. Verify whether the image file on disk is really identical to the image on media: diff /dev/sr0 disk_file If you can get different media, try them. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
Thomas Schmitt wrote: Hi, What is it with desire to bypass defect management? I mean I can perfectly understand Thomas's curiosity, but why would end-user such as Giulio want it off? I can squeeze some scenarios out of my phantasy. Like: 1 hour 40 minutes is too long for a backup window. That I can accept, I was going to post something similar. Or: The media are perfect and never ever show any bad spot. That sounds like a fairy tale. But i agree that disabling defect management needs good reasons and skilled handling of the consequences. So you say my time is so precious that I must have faster write at any cost, ... so I can have time to verify afterwards? Wearing my scdbackup hat, i object the equivalence of hardware defect management and a verification which uses the same means as a future restore run. Agree, if you want trust you are going to verify the backup anyway. It's nice to know that the drive cares for error detection and spare block management. But it is not overly trustworthy. I evaluated DVD-RAM a few years ago and found them less reliable than DVD+RW (with my old LG drive). I used growisofs-6.0 and the original formatting which still is: formatted: 2236704*2048=4580769792 00h(800): 2236704*2048=4580769792 00h(800): 2295072*2048=4700307456 01h(800): 2226976*2048=4560846848 01h(800): 2217248*2048=4540923904 This obviously includes defect management reserves. At least it ran at 0.7x DVD speed. Today defect management worked, although terribly slow, where plain writing yielded a bad burn. Maybe it's also a matter of drive and firmware. I would say that the drives have been designed to make writing work, without adding cost to make them work *well*. The only obvious way to get the speed up is a full read after write head, which introduces several cost factors. These drives are being used out of their intended use pattern, and show it. The user has a choice of solutions, none really satisfactory. But as backup programmer i need my own test or i cannot lean back and smile. So the argument that one cannot save time by disabling defect management depends on the use case. Ideally a copy of the backup would be held for byte-by-byte verify, and bad spots (only bad spots) would be rewritten. That assumes that they CAN be written successfully eventually. All solutions are ugly. Your opinion wins in many of those cases, i confess. such as what would it take for *another* kind of application. I begin to ponder how i can convince the libisofs developers of having a defect list in the ISO formatter. Possibly they will call me insane. Good. I have a reputation to defend. Have a nice day :) Thomas -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Blanking/Formating a BD-RE
Arnold Maderthaner wrote: Hi ! I applied the patch and now I get this: [EMAIL PROTECTED] bin]# ./cdrecord dev=3,0,0 blank=all Cdrecord-ProDVD-ProBD-Clone 2.01.01a37 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2008 J?rg Schilling scsidev: '3,0,0' scsibus: 3 target: 0 lun: 0 Linux sg driver version: 3.5.34 ./cdrecord: Warning Linux Bus mapping botch. ./cdrecord: Warning Linux Bus mapping botch. ./cdrecord: Warning Linux Bus mapping botch. ./cdrecord: Warning Linux Bus mapping botch. Using libscg version 'schily-0.9'. Device type: Removable CD-ROM Version: 5 Response Format: 2 Capabilities : Vendor_info: 'LITE-ON ' Identifikation : 'BD B LH-2B1S' Revision : 'AL09' Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. Using generic SCSI-3/mmc-3 BD-RE driver (mmc_bdre). Driver flags : NO-CD BD MMC-3 BURNFREE Supported modes: PACKET SAO LAYER_JUMP Starting to write CD/DVD/BD at speed 2 in real BLANK mode for single session. Last chance to quit, starting real write0 seconds. Operation starts. Running pad based emulation to blank the medium. secsize 2048 padbytes 25025314816 padblocks 12219392 maxblocks 12219392 Track 00:0 of 23866 MB pad written. ./cdrecord: Input/output error. write_g1: scsi sendcmd: no error CDB: 2A 00 00 13 38 86 00 00 1F 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 72 0B 00 00 00 00 00 0E 09 0C 00 00 00 02 00 00 Sense Key: 0x0 No Additional Sense, Segment 11 Sense Code: 0x00 Qual 0x02 (end-of-partition/medium detected) Fru 0x0 Sense flags: Blk 0 (not valid) resid: 63488 cmd finished after 231.684s timeout 100s write track pad data: error after 2579771392 bytes ./cdrecord: Input/output error. read buffer cap: scsi sendcmd: fatal error CDB: 5C 00 00 00 00 00 00 00 0C 00 resid: 12 cmd finished after 0.000s timeout 100s ./cdrecord: Cannot blank disk, aborting. ./cdrecord: Input/output error. prevent/allow medium removal: scsi sendcmd: fatal error CDB: 1E 00 00 00 00 00 cmd finished after 0.000s timeout 100s You are running as root, correct? This looks like stuff I used to get when no running as root. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [dvd+rw-tools] problem erasing DVD+RW
Thomas Schmitt wrote: Hi, on_: I'm having problems with a few of my DVD+RW, after only 1 to 3 burn Joerg Schilling: To erase, use a _recent_ cdrecord and call cdrecord blank=fast Now i am curious what SCSI commands you issue on a DVD+RW for blanking it fast. The source is available, look at any of his last ten messages ;-) I'd like to know if it worked any better. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dual-Layer DVD Burn Failure
Joerg Schilling wrote: Rob Bogus [EMAIL PROTECTED] wrote: This is one of the rare times I would agree with Joerg that trying cdrecord is desirable, even though there may be a need to create a huge ISO image and burn from that. I have not had a problem with either program, but without some effort I can't tell you which drives and media I've been using, as I'm not on the right machines. I never had the need to try growisofs besides cdrecord Cdrecord does all I need (CD/DVD/BluRay) in a single program. It may do all you need, but growisofs is vastly easier to use for multiple sessions. It's not about /capability/ but about /usability/ in this case, adding sessions is just more convenient. -- E. Robert Bogusta It seemed like a good idea at the time
Re: Dual-Layer DVD Burn Failure
Joerg Schilling wrote: Rob Bogus [EMAIL PROTECTED] wrote: I never had the need to try growisofs besides cdrecord Cdrecord does all I need (CD/DVD/BluRay) in a single program. It may do all you need, but growisofs is vastly easier to use for multiple sessions. It's not about /capability/ but about /usability/ in this case, adding sessions is just more convenient. The main reason why I do not use growisofs is that growisofs is much harder tro use then cdrecord. In my reality running multiple commands and copying the cryptic numbers output by one into the command string of another and then creating an iso to be used by a third is a lot harder than one simple giving the device name of a partially written DVD and a list of stuff to add. I'm virtually certain that your reality differs. :-( -- E. Robert Bogusta It seemed like a good idea at the time
Re: Dual-Layer DVD Burn Failure
CJ Kucera wrote: Hello - I'm having some issues burning a dual-layer DVD. Yesterday I burnt my last DVD+R DL disc (Memorex 2.4x) so I got another pack of essentially the same, though this was rated at 8x. It looks like that's the one difference between the two packs of discs. Now, whenever I try to burn to these new discs, I get the following, apparently right around the layer split: 50.08% done, estimate finish Thu Jan 10 12:28:35 2008 :-[ [EMAIL PROTECTED] failed with SK=3h/ASC=73h/ACQ=03h]: Input/output error :-( write failed: Input/output error I know that this corresponds to POWER CALIBRATION AREA ERROR but that doesn't help much... I've found plenty of other references to this error online, but it looks like all of those are happening at LBA=0h, right at the start of the disc, not at the layer transition. Since my previous discs were just 2.4x, they were getting burnt at a slower rate. I can't get these discs to burn at anything other than 4.1x, though. I've tried -speed 1 and -speed 2 but growisofs always reports: My man page says the format is -speed=2 for that, although I would expect the program to whine if it didn't know what you meant. This is one of the rare times I would agree with Joerg that trying cdrecord is desirable, even though there may be a need to create a huge ISO image and burn from that. I have not had a problem with either program, but without some effort I can't tell you which drives and media I've been using, as I'm not on the right machines. /dev/dvd: splitting layers at 2061632 blocks /dev/dvd: Current Write Speed is 4.1x1352KBps. 0.12% done, estimate finish Thu Jan 10 18:26:46 2008 Nothing shows up in dmesg during the burn process. Mostly I'd just really like to find a way to force the burn process to go slower. It seems that the most major thing that's changed is that it's trying to burn faster, which I don't really care about. If I could get it to burn at 2x (I'd even settle for 1x at this point) and have it work, I'd be fine with that. The new, blank discs look like this with dvd+rw-mediainfo: # dvd+rw-mediainfo /dev/dvd INQUIRY:[Optiarc ][DVD RW AD-7170A ][1.02] GET [CURRENT] CONFIGURATION: Mounted Media: 2Bh, DVD+R Double Layer Media ID: RITEK/S04 Current Write Speed: 6.1x1385=8467KB/s Write Speed #0:6.1x1385=8467KB/s Write Speed #1:5.1x1385=7056KB/s Write Speed #2:4.1x1385=5645KB/s Write Speed #3:3.1x1385=4234KB/s Write Speed #4:2.0x1385=2822KB/s Write Speed #5:1.0x1385=1411KB/s GET [CURRENT] PERFORMANCE: Write Performance: 4.0x1385=5540KB/[EMAIL PROTECTED] - 4173824] Speed Descriptor#0:00/4173824 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Speed Descriptor#1:00/4173824 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Speed Descriptor#2:00/4173824 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s READ DVD STRUCTURE[#0h]: Media Book Type: 00h, DVD-ROM book [revision 0] Legacy lead-out at:2086912*2KB=4273995776 DVD+R DOUBLE LAYER BOUNDARY INFORMATION: L0 Data Zone Capacity: 2086912*2KB, can still be set READ DISC INFORMATION: Disc status: blank Number of Sessions:1 State of Last Session: empty Next Track: 1 Number of Tracks: 1 READ TRACK INFORMATION[#1]: Track State: blank Track Start Address: 0*2KB Next Writable Address: 0*2KB Free Blocks: 4173824*2KB Track Size:4173824*2KB ROM Compatibility LBA: 0 READ CAPACITY: 0*2048=0 It looks like under the Speed Descriptor sections that the slowest the disc will support is 4.0x... Is there any way to override that? After the (failed) burn, the disc looks like this: # dvd+rw-mediainfo /dev/dvd INQUIRY:[Optiarc ][DVD RW AD-7170A ][1.02] GET [CURRENT] CONFIGURATION: Mounted Media: 2Bh, DVD+R Double Layer Media ID: RITEK/S04 Current Write Speed: 6.1x1385=8467KB/s Write Speed #0:6.1x1385=8467KB/s Write Speed #1:5.1x1385=7056KB/s Write Speed #2:4.1x1385=5645KB/s Write Speed #3:3.1x1385=4234KB/s Write Speed #4:2.0x1385=2822KB/s Write Speed #5:1.0x1385=1411KB/s GET [CURRENT] PERFORMANCE: Write Performance: 4.0x1385=5540KB/[EMAIL PROTECTED] - 4123264] Speed Descriptor#0:00/4123264 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Speed Descriptor#1:00/4123264 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Speed Descriptor#2:00/4123264 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s READ DVD STRUCTURE[#0h]: Media Book Type: 00h, DVD-ROM book [revision 0] Legacy lead-out at:2086912*2KB=4273995776 DVD+R DOUBLE LAYER BOUNDARY INFORMATION: L0 Data Zone Capacity: 2061632*2KB, can no longer be set READ DISC INFORMATION: Disc status: appendable Number of Sessions:1 State of Last Session: incomplete Next Track: 1 Number of Tracks: 1 READ TRACK INFORMATION[#1]:
Re: Doesn't wodim close disk ?
Gregoire Favre wrote: On Mon, Dec 31, 2007 at 06:40:12PM +0100, Joerg Schilling wrote: Wodim does not support writing DVDs. The existence of half baken code does not proof usability. Oh please... AKAIK it's the only way to write udf DVD under linux now. Under gentoo I can't easyly have both cdrtools and cdrkit so the choice is done. I am puzzled why you are using wodim instead of growisofs for this, since it has just the -dvd-compat option you need. And if gentoo has a problem letting you install it, that's your choice of a fascist distribution. Please could we stop here about other software and remain upon wodim. Sorry, I thought you wanted to solve the problem, if wodim doesn't support -fix then you can either use another tool or live with the choice of a broken or limited tool. You might also see of wodim supports -dao for the initial burn, and if that closes the session. This sounds confused, please explain. I can perfectly mount all my DVD under linux, but not under OSX, please see the output of dvd+rw-mediainfo to see what the media looks like : dvd+rw-mediainfo /dev/sr0 INQUIRY:[LITE-ON ][DVDRW SH-16A7S ][WS04] GET [CURRENT] CONFIGURATION: Mounted Media: 1Bh, DVD+R Media ID: SONY/D21 Current Write Speed: 16.0x1385=22160KB/s Write Speed #0:16.0x1385=22160KB/s Write Speed #1:12.0x1385=16620KB/s Write Speed #2:8.0x1385=11080KB/s Write Speed #3:6.0x1385=8310KB/s Write Speed #4:4.0x1385=5540KB/s Write Speed #5:2.4x1385=3324KB/s GET [CURRENT] PERFORMANCE: Write Performance: 6.4x1385=8864KB/[EMAIL PROTECTED] - 15.4x1385=21296KB/[EMAIL PROTECTED] Speed Descriptor#0:00/2146271 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Speed Descriptor#1:00/2146271 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Speed Descriptor#2:00/2146271 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Speed Descriptor#3:00/2146271 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Speed Descriptor#4:00/2146271 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Speed Descriptor#5:00/2146271 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s READ DVD STRUCTURE[#0h]: Media Book Type: 00h, DVD-ROM book [revision 0] Legacy lead-out at:2295104*2KB=4700372992 READ DISC INFORMATION: Disc status: appendable Number of Sessions:2 State of Last Session: empty Next Track: 2 Number of Tracks: 2 READ TRACK INFORMATION[#1]: Track State: invisible Track Start Address: 0*2KB Free Blocks: 0*2KB Track Size:2146272*2KB ROM Compatibility LBA: 262144 READ TRACK INFORMATION[#2]: Track State: blank Track Start Address: 2148320*2KB Next Writable Address: 2148320*2KB Free Blocks: 146784*2KB Track Size:146784*2KB ROM Compatibility LBA: 262144 FABRICATED TOC: Track#1 : [EMAIL PROTECTED] Track#AA : [EMAIL PROTECTED] Multi-session Info:[EMAIL PROTECTED] READ CAPACITY: 2146272*2048=4395565056 wodim comes with a broken variant of mkisofs, don't use it. Oh interesting, I don't understand why it works so well under linux sofar. I am only asking how I could end with DVD moutable on other OS, nothing more... Maybe I should add a wodim -fix ... after writing the disk ? Thank, -- E. Robert Bogusta It seemed like a good idea at the time
Could someone turn the bozo filter back on?
Was the filter for crap turned off deliberately, or ??? In any case a Merry Christmas or seasonal holiday to all the real users of the list. I'm happy to report that I finally got the SVCD creation under Linux going, and have been knocking out various projects for non-profits as a result. Unfortunately many cheap DVD players don't do SVCD, so the solution is only marginally reducing the cost of giving away various useful things. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: changing book-type on dvd burn?
Miles Fidelman wrote: Hi Folks, I have a debian box and a Lite-On SHM-165PS cd/dvd drive. I'm having a devil of a time burning bootable DVDs - they seem to burn, be readable, but when I try to boot, the system crunches a bit, the drive lite flashes, then boots from the hard drive. (It boots from CDs just fine.) It looks like the default software (Nautilus and whatever is behind that) sets the book-type to DVD-ROM, and from what I gather by googling a bit, that might be my problem - and that I'd have better luck if it was setting book-type to DVD+R. The other suggestion I've received is to update the firmware on my drive. So... a few questions: - is that likely diagnosis? I like the firmware better, but it depends on your method of *creating* the ISO images. non-bootable images are a more common problem than book type. - if yes, how might I go about getting things to burn as book type DVD+R? and/or - are there any linux tools that I can use to update the firmware (Lite-On seems to only distribute Windows tools) There is, but not having used it in a very long time I can't be positive of the current state, or even what tool is maintained these days. The tool I remember was pxupdate from joerg Schilling, and he might be willing to tell you if it is current, where to get the recent version, etc. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: No supported write modes with LG GSA-H62N SATA DVD+RW
Joe MacDonald wrote: I've seen a couple of discussions about similar problems to mine with different models (the H30N seemed to be a hot topic about six weeks ago) but I haven't seen any suggestions that make things work (or at least point to a cause of the failure) for me. First, the facts. - I bought this drive back in the spring. It appears to work fine in WinXP with Nero 7.something or other. - I started off with Ubuntu 6.10 and upgraded to 7.04, neither of which seemed to work. - cat /proc/version Linux version 2.6.20-16-generic ([EMAIL PROTECTED]) (gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)) #2 SMP Fri Aug 31 00:55:27 UTC 2007 - I went and grabbed the latest official cdrecord: cdrecord -version Cdrecord-ProDVD-ProBD-Clone 2.01.01a35 (i686-pc-linux-gnu) Copyright (C) 1995-2007 J�rg Schilling Do realize some things about this software, unlike most other CD burning software it must be run as root, due to using some restricted commands which other burning software packages avoid. You might try cdrskin software and see if that works better, or wodim which I thought came with ubuntu. - It seems to find the drive okay: cdrecord -scanbus Cdrecord-ProDVD-ProBD-Clone 2.01.01a35 (i686-pc-linux-gnu) Copyright (C) 1995-2007 J�rg Schilling Linux sg driver version: 3.5.34 Using libscg version 'schily-0.9'. scsibus0: 0,0,0 0) 'HL-DT-ST' 'DVDRAM GSA-H62N ' 'CL00' Removable CD-ROM 0,1,0 1) * 0,2,0 2) * 0,3,0 3) * 0,4,0 4) * 0,5,0 5) * 0,6,0 6) * 0,7,0 7) * - Any attempt to write (-tao, -sao, -dao, -raw) gives me what appears to be the same errors: cdrecord -v speed=1 dev=0,0,0 -audio gbtrack_01.wav gbtrack_02.wav cdrecord: No write mode specified. cdrecord: Asuming -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.01a35 (i686-pc-linux-gnu) Copyright (C) 1995-2007 J�rg Schilling TOC Type: 0 = CD-DA scsidev: '0,0,0' scsibus: 0 target: 0 lun: 0 Linux sg driver version: 3.5.34 Using libscg version 'schily-0.9'. SCSI buffer size: 64512 atapi: 1 Device type: Removable CD-ROM Version: 5 Response Format: 2 Capabilities : Vendor_info: 'HL-DT-ST' Identifikation : 'DVDRAM GSA-H62N ' Revision : 'CL00' Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. Current: CD-R 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 (current) Profile: CD-RW Profile: CD-ROM Profile: Removable Disk Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC-3 SWABAUDIO BURNFREE Supported modes: Drive buf size : 1053696 = 1029 KB Drive pbuf size: 1966080 = 1920 KB Drive DMA Speed: 16457 kB/s 93x CD 11x DVD 3x BD FIFO size : 4194304 = 4096 KB cdrecord: Drive does not support SAO recording. cdrecord: Illegal write mode for this drive. Does anyone have any suggestions? -- -Joe. -- E. Robert Bogusta It seemed like a good idea at the time
Re: Burning video DVD+R
Thomas Schmitt wrote: Hi, While DVD+R burn without error message, they don't work in most readers. You used growisofs, i assume. Afaik it does not close DVD+R even if option -dvd-compat or -dvd-video is given. Seems Andy Polyakov had some bad feedback about closed DVD+R. I don't know which, yet. Actually I have tried growisofs and cdrecord, both the Fedora version and the official version. However, I used -dvd-compat, not -dvd-video, if you think that has any chance of helping I'll try that. There is code to fill up a DVD+R with zeros instead. From growisofs.c: * - 'growisofs -M /dev/cdrom=/dev/zero', this is basically a counter- * intuitive kludge assigned to fill up multi-session write-once * media for better compatibility with DVD-ROM/-Video units, to keep * it mountable [in the burner unit] volume descriptors from previous * session are copied to the new session; I understand this can be done with your already burned not-so-well working DVD+R media. If you got some blank media left it may be worth a try to use cdrskin without option -multi. This will close the media after burning. Since you mention VCD, what is the correct burning magic for cdrskin? Currently none, i fear. This exotic CD stuff is described in proprietary books owned by Philips. MMC standard tells something about how to control it, but not for what purpose which control has to be applied. The rumors found in the web contradict each other and also do not 100 % match what i read from MMC. (E.g mode names and their alleged sector sizes.) On the off-chance this will be useful, mplayer and vcdimager have some of the imformation you might need, although you really probably need to look at the cue sheet stuff in software which supports that. http://www.mplayerhq.hu/DOCS/HTML/en/vcd.html http://www.vcdimager.org/pub/vcdimager/manuals/0.7/vcdimager.html#SEC4 If somebody could prescribe me in the terms of MMC what to do with the one or more source files of a VCD then i would implement this in libburn. The other path to wisdom would be a VCD player which is capable of playing CD-RW, a few VCD media examples for getting an impression of the disc structure, and then to iterate over the finite list of possibilities offered by MMC. If it plays then it is right - for that particular player. Have a nice day :) Thomas -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VCD
Joerg Schilling wrote: Thomas Schmitt [EMAIL PROTECTED] wrote: Hi, How about if I just try a burn with raw96r and see if that works? Worth a try. But man cdrecord says: -raw Set RAW writing mode. Using this option defaults to -raw96r So probably you cannot expect better results than with cdrecord -raw. During my adventures in google i found this http://www.os2world.com/cdwriting/vcdtools/readme.htm http://packages.debian.org/stable/otherosfs/vcdtools It uses cdrdao for the job of burning. Looks like the author already went through the adventures which libburn would have to pass in order to get VCD ready. You need the right kind of data for a vcd. The data from vcd formatters usually contains preformatted sectors and a cue sheet file. Writing a vcd should be possible with cdrdao (using SAO mode). Writing a svcd unly works with cdrdao if you can write it in SAO mode and if your writer supports to write complex data in SAO mode. If you need to write a svcd in RAW mode (e.g. because you use a Pioneer drive) you are lost with cdrdao and need to use cdrecord. Cdrdao does not handle cue sheet file based writing in RAW mode correctly. One of the options is to create an image with 2336 (mode2) sector layout. Unfortunately I can't find information on what size it uses by default. Bah! -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord problems
Joerg Schilling wrote: Thomas Schmitt [EMAIL PROTECTED] wrote: But reading wodim's source for write-mode detection i have to conclude that hald would have to _reliably_ sabotage at least half a dozen consequtive attempts to set the write parameters by mode page 05h. If this part of wodim has bot been bastardized, cdrecord would behave the same but the only way to find this out is to try a non-bastardized source from http://cdrecord.berlios.de/ The people who did create the wodim fork did add many intentional indentation changes in order to pretend work in progress. As wodim is also based on a very old version of cdrecord, it is hard to compare the source I think that updating wodim is a good idea anyway, Agreed. NO, it definitely does not make sense to put any effort in a dead fork. Another point against wodim is that it intentionally added bugs during it's lifetime because it's maintainer did believe it is possible to write CDs on Linux without having root privileges. Yes, and important capability cdrecord still lacks. And a good reason to try other software, because most sensible administrators don't want all their users having root access. Burning as root is suitable for personal, home, and hobby systems, but is not acceptable as a solution to application software limitations in a production environment. These bugs never have been removed before the fork died 3 months ago. Offtopic: Hal on Linux is a nightmare. As long as the Linux kernel developers and the developers for hal on Linux do not listen to experienced people, there is little hope that this will ever change. If there are problems in hal (and I totally agree there are), they are in hal, and it's not a kernel problem if someone writes an ill-behaved application and then runs it as root. And I think nightmare is an exaggeration, annoyance might be closer, since hal is not a required process. Solaris did change to hal a year ago (because of Gnome). Before, Solaris did use the old 1992 Sun vold that did never have any problem with CD/DVD writing. For this reason, I was afraid that Solaris was changing from software that worked on Solaris for many years to something that creates a lot of problems on Linux. The big difference between the Linux folks and the Solaris folks is that the Solaris folks take possible issues with CD/DVD recording very seriously. The person who did implement the code transition did listen very carefully to my explanations on why cdrecord works on Solaris and why it does not work on Linux. This is why there are no kown problems even after the change. And all this time I thought it was because everyone else could figure out how to do burning on Linux without root and you can't. Or because you wanted to claim the problems are in the kernel instead of limitations in your own software. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord problems
Joerg Schilling wrote: Vladimir Nadvornik [EMAIL PROTECTED] wrote: On Friday 27 July 2007 12:00, Joerg Schilling wrote: Vladimir Nadvornik [EMAIL PROTECTED] wrote: Hi, It might be this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413960 (LG drive on /dev/sg) It is fixed in wodim 1.1.6. This is a bug _introduced_ by wodim! It never has been in the original cdrtools. This is not true. I just verified the bug with the original cdrtools-2.01.01a30, without any modification, run as root, on openSUSE 10.2 with DVDRAM GSA-4120B connected via external usb box. Sorry, but this kind of communication is not helpful, you claim things that you do not prove. If you have problems, make a bug report. http://cdrecord.berlios.de/old/private/problems.html Your claim is no bugreport, it is no more than an unproven claim. Wrong! You must supply the proof, since you made the claim that this behavior was because he was using something other than your version of cdrecord. He pointed out that the bug is in your latest released code, so it's up to you to show that his fix isn't needed. You need to include the output of cdrecord -scanbus and the output of the failing/working command as well as the related command line. Are you willing to cooperate? He posted a bug related to Debian software, since it's your claim that this relates to your software, the burden of proof is on you. He even told you where to find the problem description and fix, but he did cooperate with the authors of the software he uses. You and your software are irrelevant. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unidentified subject!
Joerg Schilling wrote: Bill Davidsen [EMAIL PROTECTED] wrote: I recommend you to read the documentation from cdrtools to learn that your claim is not true: cdrecord of course can burn from a pipe. To be more correct, cdrecord can not burn from a pipe with anything useful writing the pipe, while growisofs can. cdrecord requires that the You seem to have an narrow and incorrect sight of the world In the same narrow minded manner, I could claim that you cannot do anythign useful with growisofs (see below.). total size of the data be known before starting, which means that the usual benefits of using a pipe are not possible: * avoid having to write an image to disk when space is tight * allow overlapping of image creation and burning time * allow burning data which changes in size between observation This is if course not true, see below for more information. You ignore the first case, I assume you agree it is correct. You ignore the 2nd case, I assume you agree it is also correct. And the 3rd case is one which is readily used, so claiming it's not true is futile. Consider: find /var/spool/ordersys/closed -type f -mnewer /usr/ordersys/lastbkup | cpio -o -Hcrc | gzip -8 | growisofs -Z /dev/dvd=/proc/self/fd/0 How do I use cdrecord in this situation? The size of the data is not known, and each run may or may not include the same files. Obviously the size of the individual files doesn't change, each run is static, but run to run isn't. So if you can't know the exact size of the image before you start, you can't burn from a pipe. Actually, I don't think you can burn at all with dynamic data, there are old posts here indicating that even using the builtin mkisofs, if the files are growing there can be problems. The final size can be on the command line or in the ISO image, but must be known at the start of the burn. See the man page isosize and tsize= descriptions. The latter explains that cdrecord uses modes which require the information early. It seems that you are uninformed - sorry but growisofs uses mkisofs! No, it does not use mkisofs when reading from a pipe. It write the incoming data to the media directly, and it need not be an ISO image at all. Mkisofs is definitely not designed to work on a dataset that changes while mkisofs is running. Other than my mention that I expected problems, mkisofs is not mentioned. The issue is that cdrecord with not read pipes and burn media unless the size of the data is known in advance. This is the only issue related to the three limitations I noted above. Whether you _believe_ that you have been able to write something useful with growisofs, while the dataset mkisofs is working on changes, is irrelevent. In most cases, the resulting DVD will be just unusable or mkisofs will even _abort_ because a file did change it's size between the creation of the metadata part of it's output and the time when reading of the related file. Repeat after me, ISO images created by mkisofs are not the only data you can burn to a DVD. CONCLUSION: growisofs _may_ in some rare cases be able to create you a usable DVD, but this is nothing you may rely on. Growisofs cannot give you more than cdrecord gives you with pipes. Irrelevant. BTW: because it is a well known problem to make backups from life filessystems, modern Operating Systems did develop filesystem snapshots. If you use snapshots, there are no problems with _both_ growisofs _and_ cdrecord and this is the only _reliable_ way to use pipes with mkisofs on life filesystems. As long as a consistent dataset is written to the pipe with every run, filesystem snapshots are irrelevant. Most database applications can write a consistent dataset, not limited to just database programs like Oracle, mysql, etc. If you do not run a modern OS and thus lack snapshots, I recommend you to upgrade to a modern OS that supports snapshots. Both Solaris and FreeBSD support filesystem shapshots since ~ Y2000. See above, o/s level snapshots are not needed for database, and may actually freeze the data in the database in an inconsistent state. The only other reliable way to do streaming backups from filesystems is to use the method from the time _before_ filesystem snapshots have been introduced: - Bring you computer down to single user mode - Make the backup from a now stable filesystem - Bring the system back to multi-user mode If you are on an older OS and cannot upgrade to a recent OS, this is the only way you may do backups. Actually, as long as the backup dataset is consistent, I don't see that the method of ensuring consistency is relevant. Some are more convenient that other, I freely agree! Jörg -- E. Robert Bogusta It seemed like a good idea at the time
Re: growisofs WRITE@LBA=230540h error blanking DVD+RW media
BitBucket wrote: Thomas Schimitt has it right -- the LBA=230540h is 2,295,104 decimal, which is the total number of blocks on the DVD+RW medial Since the LBA addressing starts from zero, an attempt to address that block is trying to address on past the last LBA block on the DVD. (I originally checked this, but for some stupid reason failed to make the translation from hex to decimal, no doubt due to frustration and carelessness.) So the error message is correct -- it is an incorrect argument. There must be some error then in the source code, since the program clearly knows the size of the DVD media, and shouldn't be trying to write past the end of the disc. But more importantly, the resulting media is not blanked back to its virgin state, but is merely nulled. That is, there is still a Session 1 - track 01 structure, 4700372992 bytes long. This I was trying to blank out entirely, to start fresh. My reading of the man pages for growisofs was that this was accomplished by the command I used: growisofs -Z e:=/dev/zero although the /dev/zero does seem to indicate that the track 01 should just be zeroed out (filled with nulls), not eliminated entirely. Also, the [EMAIL PROTECTED] is being hidden with EMAIL PROTECTED. As I am new to this list, I assume the subscribers are getting the actual text, whereas the protected overwrite is for the mail list. My further questions: 1. What then is the command to blank the DVD+RW media, and return it to virgin state? The dvd+rw-format command is used to format dvd+rw. It is at the URL you list below. 2. Who do I notify about the error in the code that causes it ti attempt a write beyond the disc limit? I think size checking is done only for ISO images. If you feed from a source, using a non-ISO image, I believe you bypass that logic. Unlike cdrecord, growisofs can burn from a pipe. Thank you in advance for your help with this. Well I have no competing product to flog, so I can actually try to help you. -- Roy Zider Windows binaries from http://fy.chalmers.se/~appro/linux/DVD+RW/tools/win32/ growisofs.exe29-Jan-2006 mkisofs.exe03-Jul-2006 Pioneer DVR-111C 1.06 -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dvd+rw-tools: DVD-RW discs are burned as protected on LG GSA-4163B
Joerg Schilling wrote: Piotr Paw³ow [EMAIL PROTECTED] wrote: Hello, I have a problem with burning DVD-Video on a DVD-RW media. Burned discs won't play on most software and hardware players. While it plays in Windows Media Player, it won't play in VLC on Windows, neither VLC or Xine or Mplayer on Linux, and won't play on any standalone player I tried. Start with a clean setup: create the image with a _recent_ mkisofs ftp://ftp.berlios.de/pub/cdrecord/alpha/ and use mkisofs -dvd-video to create the image use cdrecord to write to the medium If the DVD-RW medium has been written by growisofs before you need to cleanup the medium with cdrecord -v blank=all before. Make sure you use the official and unmodified cdrecord and not a bastardized version from one of the Linux distributors. And let us know how it works. -- E. Robert Bogusta It seemed like a good idea at the time
Re: problem with dvd-rw on Plextor PX-704A
Joerg Schilling wrote: Andrea [EMAIL PROTECTED] wrote: 3- Only if I use dvdrecord I can blank the dvd, but if I do it in fast mode, gnomebaker gives me this error if I attempt a new burning: dvdrecord does not exist Please stop assuming that everything you didn't write is broken, a bad clone, obsolete, unofficial, etc. It appears he was not asking about your software, so your answer to use yours instead is not helpful. And if you had just added DVD support instead of forking the Pro stuff there wouldn't be so damn many variants! And if you would add the capability to conveniently append to CD/DVD (like -M in growisofs) people would have less need to use other software. Doing append multisession is highly useful for a non-volatile backup of ongoing work, and should be used by more people than it is. Or do you speak about the dead and broken junk fork from an ex Rad Hat employee? This is based on a 6 year old cdrecord source where someone did replace the working DVD support by someting half baken. Please use the official cdrtools ftp://ftp.berlios.de/pub/cdrecord/alpha/ (recent version is 2.01.01a20) and tell the authors of nautilis to add working support for cdrecord. Jörg -- E. Robert Bogusta It seemed like a good idea at the time
Re: mkisofs bug? creating cdrom image for bulk files with -old-root - enter infinite loop?
Joerg Schilling wrote: å¼ é?¡æ¦ [EMAIL PROTECTED] wrote: Further report in case it is helpful for debugging it: Because I am a bit in hurry (now is 23:55, better finish today's backup before 00:00) I tried to issue command to mkisofs replacing '-M /dev/hdd' with '-M /tmp/first.iso' where first.iso is the iso image for the CDR I burnt first time. By doing so I can separate the mkisofs failure with possible DVD-RW driver problem (because driver is not used when doing this mkisofs). The behavior: mkisofs starts to run, and hang pretty soon there, taking up NO CPU RESOURCE. It simply hang there. Ctrl+C and TERM signal is ignored, KILL signal cause it to quit. In any case, it is impossible to help you as long as you use this 2 year old outdated version. I can only help if you first test the latest version. 2.0.1 IS the latest rellease version... unless you put the later releases somewhere else. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Debian Kicks Jörg Schilling
It appears that Debian has become disenchanted with Jorg... I'm sorry it had to happen, but presumably there will now be a burning program which makes an effort to work with the reality of the kernel and not just tell everyone they are doing it wrong. http://linux.slashdot.org/article.pl?sid=06/09/04/1335226 -- E. Robert Bogusta It seemed like a good idea at the time
Re: In defense of TAO
bill wrote: I understand that the author of cdrecord is considering dropping support for TAO ? I would like support for TAO to continue based on the following arguments. Most newer units support TAO Overwrite for CD-RWs if there is only one track/session recorded ( the case at least for me when it's data only ). This means there is no need to blank the disc prior to recording. There is also no need for a gap which means more space on the disc for real data. CD-RW in DAO mode works good too but it requires blanking before you can use it again. There is no such thing as DAO Overwrite. Is there ? CD-RW in Packet mode has overwrite capability but it requires extra formatting. And if I have a small (less than 700 megs) amount of data to backup, why use a DVD ? In these cases, which are frequent for me, a CD-RW in TAO mode is my choice everytime. No blanking, no extra formatting. I'm lazy. And a lot of drives still don't support DAO in firmware, so cdrecord needs to fake with raw96 or some other trick. Using libscg version 'schily-0.7' Device type: Removable CD-ROM Version: 0 Response Format: 2 Capabilities : Vendor_info: 'PIONEER ' Identifikation : 'DVD-RW DVR-104 ' Revision : '1.40' Device seems to be: Generic mmc2 DVD-R/DVD-RW. cdrecord: This version of cdrecord does not include DVD-R/DVD-RW support code. cdrecord: If you need DVD-R/DVD-RW support, ask the Author for cdrecord-ProDVD. Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC-3 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R Just as an example. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems when writing DVDs with growisofs
Volker Kuhlmann wrote: I did a blockdev --setra 8 /dev/hdd as root ( 8*512 byte = 4k ). Unfortunately the problem remains the same. It is necesssary to first test whether you're running into said kernel bug, before considering other possibilities. For this, you will need to set read-ahead to zero, not something small. hdparm -a0 /dev/hdd will do it. So might blockdev. Check with hdparm /dev/hdd AFAIK different layers. hdparm works on the drive, blockdev may work in the o/s, since I can ret readahead far larger than the drive claims to support. And I believe on CD/DVD blockdev is sufficient, it works for me when verifying copies. However, by all means set or check it both ways, I haven't waded through the code. Note this will make your DVD drive very slow. It is sufficient to disable read-ahead from another shell while your reading is going on, as long as you make sure that you do it well before the kernel reads near the end of the recording. What next ? Provide missing info ;) Volker -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Repeatability of mkisofs?
Joerg Schilling wrote: Rob Bogus [EMAIL PROTECTED] wrote: Old versions put command line info in the image, creation date is preobably there, and quite likely the atime has changed on parts. I use sumdir to embed md5sums in the directory(s). Old versions did not put commandline info in the image. Newer versions (since April 2000) write an anomymized command line and version info. Broken (hacked) versions may behave like old versions. You didn't say anything about atime. If atime changes with every backup, of course they will be different. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Repeatability of mkisofs?
Michael Shell wrote: I've got an interesting one. I keep track of the md5sums of all the images I burn. Now, it just so happened that I had deleted an image file that I later needed. So, I rebuilt a new image via mkisofs from the exact same directory structure used to create the old image. Now, the two images had the exact same byte count, but, much to my surprise, they differed with respect to their md5sums! Why is this? Old versions put command line info in the image, creation date is preobably there, and quite likely the atime has changed on parts. I use sumdir to embed md5sums in the directory(s). I used almost the same command line each time: mkisofs -dvd-video -o image.img directory The only difference was in the name/path of the output file. I would expect mkisofs to be deterministic in that the same input data will produce an identical output result (for the same version of mkisofs, in my case this is 2.01). Several possibilities for the differing output files come to mind: 1. mkisofs somehow makes use of a random number generator 2. mkisofs is embedding or using the current time in the output 3. mkisofs is embedding the output filename/path or the command line as it was invoked within the created image It would also be good to know if there is a combination of command line options which will result in identical images with repeated calls to mkisofs (and if not, maybe this would be a good feature to add to mkisofs in the future). Thanks in advance for any info that sheds light on this, Mike Shell -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: startsec problem?
Joerg Schilling wrote: Alexey Toptygin [EMAIL PROTECTED] wrote: On Mon, 24 Apr 2006, Joerg Schilling wrote: Alexey Toptygin [EMAIL PROTECTED] wrote: OK, I have built cdrecord from this source: ftp://ftp.berlios.de/pub/cdrecord/cdrtools-2.01.tar.bz2 and I have changed the drive specification in /etc/default/cdrecord to ATA:0,1,0. I read 2 known-good pressed audio CD with official readcd -clone and wrote them with official cdrecord -clone. Both times I got the same error, which is the same as with the unofficial Debian version. The coasters produced cause the drive to take too long when trying to cdrecord -toc or cdrecord -atip, and the bus is reset, and DMA turned off. Here is the output of cdrecord: What error are you talking of? This is what I called an error, it is the only indication that anything is wrong until I try to read the CD that was just burned: YOu did absolutely not give any indication for a problem. How should I help you? If you like help, you would need to give us the reason why you cannot use the resulting CD. He did, you deleted and ignored it: As I said, the burn results in a coaster that causes some drives to take a very long time to respond to commands, and some drives to act as if there's no media. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [SPAM] Re: growisofs 6.1 fails to allocate shared memory beyond 16m
Robert Demski wrote: growisofs ... -use-the-force-luke=bufsize:16M ... I run with growisofs ... -use-the-force-luke=bufsize:8M ... It's a great program, but personally I find that the cuteness of -use-the-force-luke faded LONG ago! -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Burning Problem
Dan Smythe wrote: I am using growisofs on OpenBSD 3.8. I am using a USB DVD burner that only averages .3x speed. My DVDs always burn fine if I am using a DVD+R or DVD-R that goes from 1-4x. However, when I use the new 1-8x DVDs, it always seems to burn fine, but I can't copy the information or play it on a DVD player. I also tried setting the speed to 1x with the growisofs command, but no luck. Any suggestions? My first thought is that you are having a firmware problem, so I'd look and see if there's an upgrade. After that you could consider media brand, but that's unlikely to be a solution. Is your USB an old USB-1.0 by chance? I burn 8x here. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mkisofs gives 'file too large for defined data type' error on 4.3GB file
Asfand Yar Qazi wrote: Hi, How can I write a single file to a DVD+R(W)? I tried to use mkisofs's -stream-media-size 2291000 option (2291000 giving me just under the DVD's full capacity), but it would not work (after 500MB, it would stop reading standard input.) Buggy to say the least. I think you want to reread the man pages. If you want to create an ISO image you don't need the option, and if you just want to write the file you don't want to use mkisofs at all. Your misunderstanding of what the software does is not a bug. So, I thought - let's just make a 4.3 GB file. And when mkisofs tries to read it, I get the 'file too large for defined data type' message. Great. Let's see, is 4.3 larger than 2? Did you read the doc on what you can do with iso9660 filesystems and the limits on individual files? Doesn't sound like it. Can I just do a growisofs -Z /dev/dvdrw=/tmp/dvd-bak-1.tar or something? Then wouild a 'tar --multi-volume -t -f /dev/dvdrw' access the archive? I really need to do this backup soon, since I haven't done one since setting up my new Gentoo system. That you can do, although getting tar to create one volume at a time may be interesting, and creating all at once will require a lot of disk. On the other hand, I have been unable to get growisofs to burn a stream from stdin lately, since I have a new o/s version, new distro, and new growisofs version I have put chasing that one on the list of things to do when I can't find a workaround. Help... Also, the mailing list won't let me subscribe to it. I've tried several different addresses through the http://lists.debian.org/cdwrite/ page, and nothing happens. So please CC me - the mailing list software seems to hate me for some reason. Probably because your spam filter is killing the message which asks if you really want to join or something... -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Plextor PX-750A/DVD+R/DVD+RW/growisofs
David Jobet wrote: Hello, I've ran into problems burning DVD with growisofs. As a summary : * growisofs DVD+R : works but at 0.5X (instead of 16X) * growisofs DVD+RW : fail with message --- :-[ [EMAIL PROTECTED] failed with SK=5h/ASC=30h/ACQ=05h]: Wrong medium type :-( media is not formatted or unsupported. :-( write failed: Wrong medium type --- I had a try with cdrecord with a generated iso image and DVD+RW. It worked but with 1X speed (instead of 4X) cdrecord also reported some strange problem : --- Disk type:unknown dye (reserved id code) Manuf. index: -1 Manufacturer: unknown (not in table) cdrecord: WARNING: Could not manage to find medium size, and more than 90 mins of data. cdrecord: WARNING: Drive returns wrong startsec (0) using -150 --- Anyway I want to make my dvd writer works ok with growisofs... I would start with a different brand of media and be sure you can read CD on that device. I'm running - Mandriva 2006, kernel 2.6.12 smp mode/i686. - growisofs version 5.21 I've started reporting those information on mandriva's bug report without any success yet : http://qa.mandriva.com/show_bug.cgi?id=21013 You will find there several attachements. I know I'm not giving too much details but the problem is I don't really know where to search. Kind regards and thanks for your help David PS : can you cc me ? (I'm not subscribed) -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dvd+rw-tools update [6.0, DVD-R DL]
Joerg Schilling wrote:
Bill Davidsen [EMAIL PROTECTED] wrote:
My belief is that if O_DIRECT is in the kernel headers it works. I would
love to have time to test timing of O_DIRECT on (a) disk, (b) partition,
(c) file on disk, and alignment on minimal vs. page size boundaries.
Doing O_DIRECT writes of anything avoids buffer pool collisions. To test
either hack mkisofs to write with O_DIRECT or pipe into Dwriter or
similar and see the difference in create time of a DVD image. I may
actually do the hack and enable it when -o is used (and on Linux). If I
do I'll put up the patch and post a link here. Then Joerg can reject it
because it makes mkisofs run faster on Linux.
Statements like this one from self called Linux specialists are an important
reason why Linux specialists constantly disqualify themself :-(
If you take the time you needed to write this for running a test, you would
know that O_DIRECT makes file I/O slower than by using the standard method.
Star needs only 40% of the system CPU time when using O_DIRECT, but slows
down by 30%.
And BTW: You cannot use O_DIRECT on Linux without defining __USE_GNU
but doing this uncovers broken prototypes that prevent compilation.
I'm attaching a tiny program to show that isn't the case. It's for
zeroing out large files. If you have a disk intensive application you
might run this to zero out say 50GB or so, and compare the impact on the
application with dd of /dev/zero using 1024k buffer size. The program
has compiled on rh7.2 thru FC4, SuSE, ubuntu, etc, no kernel headers or
GNU needed, you want the POSIX behaviour, or at least I do.
I used 04 instead of O_DIRECT for my tests.
Needed only on really old installs, since any distribution which shipped
a kernel with the feature also should ship the user headers to compile.
My source has a check, I am running a 2.6.15 kernel on a RH7.3 hacked
base, so after the includes are read it will do the define if needed.
Jörg
--
E. Robert Bogusta
It seemed like a good idea at the time
// O_DIRECT test - measure speed of direct write
#include unistd.h
#include stdio.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
/* this allows compilation on a OLD test machine (RG 7.3) */
#ifndef O_LARGEFILE
#define O_LARGEFILE 010
#endif /* old includes */
#ifndef O_DIRECT
#define O_DIRECT 04
#endif /* old includes */
#ifdef DIRECT
#define Attribs (O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE|O_DIRECT)
#else /* not direct */
#define Attribs (O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE)
#endif
#define MB (1024*1024)
int
main(int argc, char *argv[])
{
char *buffer, *temp;
int i, j, NumMB, stat, fd;
char *filename;
// sanity check
if (argc 3) {
fprintf(stderr,
Minimum two args!\n\n
Usage: zerofile len_MB file1 [ file2 [... fileN ] ]\n
);
exit(1);
}
NumMB = atoi(argv[1]);
// allocate the buffer aligned in every case
stat = posix_memalign(buffer, getpagesize(), MB);
if (stat) {
fprintf(stderr,
Aligned buffer allocation of %d MB failed\n,
NumMB
);
exit(2);
}
// create and write the files
for (i = 2; i argc; ++i) {
filename = argv[i];
fd = open(filename, Attribs, 0644);
if (fd 0) {
fprintf(stderr,
Unable to create file %s, skipping and
continuing\n,
filename
);
continue;
}
// write the data to the file
for (j = 0; j NumMB; ++j) {
stat = write(fd, buffer, MB);
if (stat MB) {
fprintf(stderr,
Write error on %s, short file\n
1 MB write only sent %d bytes after %d
MB written\n,
filename, stat, j
);
break;
}
}
// close the file
fsync(fd);
close(fd);
}
exit(0);
}
Re: PX-716SA growisofs won't write DVD
Steve Adeff wrote: updated to latest firmware and used the media that came with the drive and it burned fine. Now I guess I just have to find media the drive likes. rather dissapointing in that its a plextor, I'd expect it to burn to anything, but at least now I know it works! Have you tried other quality media after the update, and/or manually reducing the speed? I've had pretty good luck using computer show media, white label stuff with undocumented media codes, as well as quality media for more demanding uses, of course. thanks, Steve On Saturday 17 September 2005 10:01, Rob Bogus wrote: Steve Adeff wrote: Robert, with the media that previously failed to write: # dvd+rw-mediainfo /dev/dvd1 INQUIRY:[PLEXTOR ][DVDR PX-716A ][1.06] GET [CURRENT] CONFIGURATION: Mounted Media: 1Bh, DVD+R Media ID: CMC MAG/E01 Current Write Speed: 8.0x1385=11080KB/s Write Speed #0:8.0x1385=11080KB/s Write Speed #1:6.0x1385=8310KB/s Write Speed #2:4.0x1385=5540KB/s GET [CURRENT] PERFORMANCE: Write Performance: 6.0x1385=8310KB/[EMAIL PROTECTED] - 8.0x1385=11080KB/[EMAIL PROTECTED] Speed Descriptor#0:02/2295104 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Speed Descriptor#1:02/2295104 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Speed Descriptor#2: 02/2295104 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s READ DVD STRUCTURE[#0h]: Media Book Type: A1h, DVD+R book [revision 1] Legacy lead-out at:2295104*2KB=4700372992 READ DISC INFORMATION: Disc status: appendable Number of Sessions:1 State of Last Session: incomplete Next Track: 1 Number of Tracks: 1 READ TRACK INFORMATION[#1]: Track State: blank Track Start Address: 0*2KB Next Writable Address: 0*2KB Free Blocks: 2295104*2KB Track Size:2295104*2KB FABRICATED TOC: Track#1 : [EMAIL PROTECTED] Track#AA : [EMAIL PROTECTED] Multi-session Info:[EMAIL PROTECTED] READ CAPACITY: 1*2048=2048 is there a way to disable the drive from doing any media check and just writing? No, because the drive hardware needs to be tuned by the firmware to produce correct results. But looking at the output, you also support 6x writing in your drive. I would try writing this media at 6x, since it's a supported speed. That's about the upper end of how fast you write a CD at 48x, as a data point. It may be that the firmware indicates it can operate at 8x, but can't, at least with this media. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PX-716SA growisofs won't write DVD
Steve Adeff wrote: Robert, with the media that previously failed to write: # dvd+rw-mediainfo /dev/dvd1 INQUIRY:[PLEXTOR ][DVDR PX-716A ][1.06] GET [CURRENT] CONFIGURATION: Mounted Media: 1Bh, DVD+R Media ID: CMC MAG/E01 Current Write Speed: 8.0x1385=11080KB/s Write Speed #0:8.0x1385=11080KB/s Write Speed #1:6.0x1385=8310KB/s Write Speed #2:4.0x1385=5540KB/s GET [CURRENT] PERFORMANCE: Write Performance: 6.0x1385=8310KB/[EMAIL PROTECTED] - 8.0x1385=11080KB/[EMAIL PROTECTED] Speed Descriptor#0:02/2295104 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Speed Descriptor#1:02/2295104 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s Speed Descriptor#2:02/2295104 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s READ DVD STRUCTURE[#0h]: Media Book Type: A1h, DVD+R book [revision 1] Legacy lead-out at:2295104*2KB=4700372992 READ DISC INFORMATION: Disc status: appendable Number of Sessions:1 State of Last Session: incomplete Next Track: 1 Number of Tracks: 1 READ TRACK INFORMATION[#1]: Track State: blank Track Start Address: 0*2KB Next Writable Address: 0*2KB Free Blocks: 2295104*2KB Track Size:2295104*2KB FABRICATED TOC: Track#1 : [EMAIL PROTECTED] Track#AA : [EMAIL PROTECTED] Multi-session Info:[EMAIL PROTECTED] READ CAPACITY: 1*2048=2048 is there a way to disable the drive from doing any media check and just writing? No, because the drive hardware needs to be tuned by the firmware to produce correct results. But looking at the output, you also support 6x writing in your drive. I would try writing this media at 6x, since it's a supported speed. That's about the upper end of how fast you write a CD at 48x, as a data point. It may be that the firmware indicates it can operate at 8x, but can't, at least with this media. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What is the failure here when growisofs'ing a new disk?
David Bullock wrote: Hi folks, I'm wondering if someone would characterise my growisofs problem for me, since I am not making much of the diagnostic output. What's going on here? First up, some background on the system, in case it's relevant (sorry about not using Debian!): arwen# uname -a FreeBSD arwen.lorien.dawnbreaks.net 4.9-PRERELEASE FreeBSD 4.9-PRERELEASE #0: Tue Sep 9 21:47:28 CST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ARWEN i386 arwen# camcontrol devlist PIONEER DVD-RW DVR-105 1.30 at scbus0 target 0 lun 0 (cd0,pass0) arwen# usbdev usbdev: Command not found. arwen# usbdevs addr 1: UHCI root hub, VIA addr 2: Keyboard NT6881, NOVATEK addr 3: USB2.0 Storage Device, Cypress Semiconductor Now, the output of persistently running the same instruction to growisofs (3 tries, same DVD. Same output for 2 'out of the packet' DVD disks): arwen# growisofs -dvd-compat -Z /dev/cd0c=dvd1.iso Executing 'builtin_dd if=dvd1.iso of=/dev/pass0 obs=32k seek=0' :-( unable to PERFORM OPC: Input/output error arwen# growisofs -dvd-compat -Z /dev/cd0c=dvd1.iso Executing 'builtin_dd if=dvd1.iso of=/dev/pass0 obs=32k seek=0' /dev/pass0: Current Write Speed is 4.1x1385KBps. :-( unable to [EMAIL PROTECTED]: Input/output error builtin_dd: 784*2KB out @ average 0.6x1385KBps :-( write failed: Input/output error /dev/pass0: flushing cache /dev/pass0: updating RMA /dev/pass0: closing disc arwen# growisofs -dvd-compat -Z /dev/cd0c=dvd1.iso :-( /dev/cd0c: media is not recognized as recordable DVD: 10 And some output from dmesg: arwen# dmesg [...] umass0: Cypress Semiconductor USB2.0 Storage Device, rev 2.00/0.01, addr 3 umass0: Get Max Lun not supported (STALLED) cd0 at umass-sim0 bus 0 target 0 lun 0 cd0: PIONEER DVD-RW DVR-105 1.30 Removable CD-ROM SCSI-0 device cd0: 650KB/s transfers cd0: cd present [1 x 2048 byte records] [...] umass0: BBB reset failed, TIMEOUT My first thought is that your drive doesn't like these media. Is the firmware at the current level? -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PX-716SA growisofs won't write DVD
Steve Adeff wrote: drive is a SATA drive that works fine for CDR's. growisofs -Z /dev/dvd1=file.ISO Executing 'builtin_dd if=file.ISO of=/dev/dvd1 obs=32k seek=0' /dev/dvd1: Current Write Speed is 8.2x1385KBps. 32768/4008509440 ( 0.0%) @0.0x, remaining 14271:43 32768/4008509440 ( 0.0%) @0.0x, remaining 20388:10 32768/4008509440 ( 0.0%) @0.0x, remaining 28543:26 32768/4008509440 ( 0.0%) @0.0x, remaining 34659:53 32768/4008509440 ( 0.0%) @0.0x, remaining 40776:20 32768/4008509440 ( 0.0%) @0.0x, remaining 48931:36 dmseg output: Device sr0 not ready. Attached scsi generic sg0 at scsi2, channel 0, id 0, lun 0, type 0 Attached scsi generic sg1 at scsi3, channel 0, id 0, lun 0, type 5 Attached scsi generic sg2 at scsi6, channel 0, id 0, lun 0, type 0 Attached scsi generic sg3 at scsi6, channel 0, id 2, lun 0, type 0 parport0: FIFO is stuck parport0: BUSY timeout (1) in compat_write_block_pio DMA write timed out Device sr0 not ready. parport0: FIFO is stuck parport0: BUSY timeout (1) in compat_write_block_pio DMA write timed out parport0: FIFO is stuck parport0: BUSY timeout (1) in compat_write_block_pio DMA write timed out parport0: FIFO is stuck parport0: BUSY timeout (1) in compat_write_block_pio DMA write timed out SCSI error : 3 0 0 0 return code = 0x2 parport0: FIFO is stuck parport0: BUSY timeout (1) in compat_write_block_pio DMA write timed out ata4: command 0xa0 timeout, stat 0xd0 host_stat 0x20 SCSI error : 3 0 0 0 return code = 0x2 parport0: FIFO is stuck parport0: BUSY timeout (1) in compat_write_block_pio DMA write timed out parport0: FIFO is stuck parport0: BUSY timeout (1) in compat_write_block_pio DMA write timed out parport0: FIFO is stuck parport0: BUSY timeout (1) in compat_write_block_pio DMA write timed out Same thing I told David, your drive (firmware) may not like the media. Things to try are other brands of media and firmware upgrade. That device not ready sounds as if the firmware didn't like the media. Other thought: try the mediainfo command and see if that provides enlightenment. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CLOSE SESSION failed on DVD+R only
[EMAIL PROTECTED] wrote: Hallo Thomas, Op 23 Aug 05 schreef [EMAIL PROTECTED] aan [EMAIL PROTECTED]: s i just see that you considered to try other s media but had no opportunity up to now. Alas, using different media did not help a lot :( At this point I suspect firmware. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord doesn't appear to support high speed media (4x-12x)
Steven Friedrich wrote: I'm running FreeBSD 4.11-STABLE and I have a Toshiba SD-R5002 (DVD-RW) but I'm using it to create a CD. High speed media, i.e., Memorex 4x-12x doesn't generate any error messages until I try to mount it. Memorex 1x-4x media works fine. I even tried speed=4 with cdrecord when using the high speed media, but it fails in same fashion. Since I burn 40x all the time using Linux and cdrecord, I think you look in the wrong place for the problem. In the order I think most likely: 1 - drive firmware 2 - media 3 - BSD not configured properly for the operation and only then 4 - some obscure cdrecord bug which doesn't hit Linux and Solaris users Under FreeBSD ports, the description for cdrecord gives this web site: http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/cdrecord.html but it's no longer there. I would like to hear more about that... -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a way to backup large file ?
Grgoire Favre wrote: On Mon, May 23, 2005 at 12:28:21PM +0200, [EMAIL PROTECTED] wrote: ... and you have to expect operating systems where the ISO filesystem driver cannot cope with 2GB ? How about a raw 1:1 copy on DVD media then ? Like growisofs ... -Z /dev/sr0=/my/mpeg.mpg (or an according cdrecord-ProDVD command). In fact, I tried directly with one cheap DVD to write a 2.7 Gb file and three smaller one : it works perfectly ??? I don't know why I thought there was a 2 Gb limit on filesize ? Thank you very much for your answer, I think you are considering the file size limit of a single file in an ISO9660 filesystem. -- E. Robert Bogusta It seemed like a good idea at the time
Re: support for dual-layer dvds?
Geoffrey wrote: I've been googling around and such, but can't find anything on this. Is there support for burning dual-layer dvds? I'm running SuSE 9.2 and Red Hat Workstation 4. Pointers to any docs would be appreciated. Seeing no reply after all this time I assume you're on your own. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Speed problems with PX-716A
Joerg Schilling wrote: If you did not use cdrecord-ProDVD in the first case, then you did not use cdrecord but a hacked command that is NOT cdrecord. Do not expect any help for bastardized cdrecord variants here. Jörg Put a sock in it! This mailing list is not reserved to your personal private versions of software. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Speed problems with PX-716A
Roberto Sebastiano wrote: I sent two mails in the past on this list about recording speed problems. I repost it here .. Hi, I have a NEC 3500 Dvd Writer. I have problems with the recording speed. I tried two different brand of dvd-r (one from princo that is certified for 4x recording, and one from philips that is certified for 8x), but cdrecord-ProDVD always writes the DVDs at 6x speed. Here is the output of the program; tell me if I can supply additional debugging data. newdeal:/pub/temp# cdrecord-dvd -dev=/dev/hdc -speed=4 -dao -data data.iso Cdrecord-ProDVD-Clone 2.01.01a01 (i686-pc-linux-gnu) Copyright (C) 1995-2004 Jörg Schilling Unlocked features: ProDVD Clone Limited features: This copy of cdrecord is licensed for: private/research/educational_non-commercial_use cdrecord-ProDVD: Warning: Running on Linux-2.6.10 cdrecord-ProDVD: There are unsettled issues with Linux-2.5 and newer. cdrecord-ProDVD: If you have unexpected problems, please try Linux-2.4 or Solaris. Have you tried open source CD/DVD burning programs? This one clearly states that it has not completed upgrading to support the 2.6 kernel (unsettled issues) and something with source available will be easier to debug. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unidentified subject!
Joerg Schilling wrote: Rob Bogus [EMAIL PROTECTED] wrote: Okay, I'll put them on a web site and send them off to a few vendors who have their own version anyway. That way you won't have to worry about losing it. It looks as if using a trailing dot will be more natural: Ex: /usr/local/src/. /opt/tmr/. /home myron/. instead of haveing to write graft-points: /usr/local/src=/usr/local/src /opt/tmr=/opt/tmr /home /home myron=/home myron since I doubt anyone writes that way, and backing up directories using the original names is useful. What you try to propose is nothing that could be accepted for the official mkisofs. The more you write on it the less benefits I see. /usr/local/src/. does not help at all as mkisofs could not know how much of the original path should be visible on the CD. If /usr/local/src/. is a shorthand for /usr/local/src=/usr/local/src with graft points, why would it be any easier to figure out just because it was a hell of a lot easier to use for multiple directories? I suspect what you mean is that it isn't your idea so you're against it. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unidentified subject!
Joerg Schilling wrote: Rob Bogus [EMAIL PROTECTED] wrote: If that's what you want -graft-points var.www.1=/var/www/1 (you will need options for having multiple dots). And what I said works, at least here, -graft-points /var/www/1=/var/www/1 preserves everything. That's the whole point of addir backups. Joerg, would you accept a patch such that /var/www/1= with no trailing copy of the same string would be a shorthand for this behaviour? I am not sure if this would really make sense as you could easily write var.www.1=/var/www/1 instead of var.www.1= in special when you run scripts. The idea is not to solve the original poster's problem, but to avoid /var/www/1=/var/www/1 many times repeated when what is really wanted is to say /usr/local/src (or similar) and not have to use graft-points and say /usr/local/src=/usr/local/src. To say that the current behaviour is inconvenient when saving a large number of directories *in the original location*, since graft-points are needed. Also please note that I did not yet start with a new development cycle for cdrtools as I am currently working on Star's incremental restores. Sending patches now could easily get lost :-( Okay, I'll put them on a web site and send them off to a few vendors who have their own version anyway. That way you won't have to worry about losing it. It looks as if using a trailing dot will be more natural: Ex: /usr/local/src/. /opt/tmr/. /home myron/. instead of haveing to write graft-points: /usr/local/src=/usr/local/src /opt/tmr=/opt/tmr /home /home myron=/home myron since I doubt anyone writes that way, and backing up directories using the original names is useful. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unidentified subject!
_N4R3N_ wrote: hi all If i have a dir named /var/www/1.If i make an image using mkisofs with common options and write it on a cd I will see a copy of directory '1' on a cd . But i want to preserve the entire path such that the directory i m going to get should have the name 'var.www.1' Plz note that using graft points gives a diff result.How do i do this. Any ideas. Thanks in anticipation If that's what you want -graft-points var.www.1=/var/www/1 (you will need options for having multiple dots). And what I said works, at least here, -graft-points /var/www/1=/var/www/1 preserves everything. That's the whole point of addir backups. Joerg, would you accept a patch such that /var/www/1= with no trailing copy of the same string would be a shorthand for this behaviour? -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: give me the command to write DVD to DVD directly
robinboby . wrote:
hai ,
i have to take a copy of one DVD using dvdrecord command
my DVD write is SONY DVD RW secdary Master
and one samsung DVD R Secondary Slave
let me know how to take a copy of DVD directly (DVD to DVD copy) with
creating an image to disc...
i try with
this is the detaisl whiile i run dvdrecord -scanbus
[EMAIL PROTECTED] root]# cdrecord --scanbus
Cdrecord 2.0 (i686-pc-linux-gnu) Copyright (C) 1995-2002 Jrg Schilling
Linux sg driver version: 3.1.24
Using libscg version 'schily-0.7'
cdrecord: Warning: using inofficial libscg transport code version
(schily - Red Hat-scsi-linux-sg.c-1.75-RH '@(#)scsi-linux-sg.c
1.75 02/10/21 Copyright 1997 J. Schilling').
scsibus0:
0,0,0 0) 'SONY' 'DVD RW DRU-710A ' 'BY01' Removable CD-ROM
0,1,0 1) *
0,2,0 2) *
0,3,0 3) *
0,4,0 4) *
0,5,0 5) *
0,6,0 6) *
0,7,0 7) *
I count one device. Assuming (1) you really have two but one is not
visible to dvdrecord, and (2) the read device *is* visible to readcd,
and (3) readcd will read all of a DVD, you might try running the output
of readcd into dvdrecord with -waiti option and - as the source.
Ex: readcd {options} | dvdrecord dev=0,0,0 -pad -waiti fs=6m -
or something like that. No promises, but it certainly is possible to
burn from a stream, even when the stream is coming over the network. Set
speed and fs to prevent underrun!
and i try following command
dvdrecord -v dev=0,0,0 speed=8 /dev/cdrom
dvdrecord -v -dao fs=6m dev=0,0,0 /dev/cdrom -
but both fail to give the output proper.
help me to find proper command..
--
E. Robert Bogusta
It seemed like a good idea at the time
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: :-( allocation length isn't sane
Carsten Neumann wrote: On Tue, 26 Oct 2004, Wayne Topa wrote: Carsten Neumann([EMAIL PROTECTED]) is reported to have said: On Mon, 25 Oct 2004, RonGroen wrote: Content-Type: text/html; name=unnamed Content-Transfer-Encoding: quoted-printable Content-Description: Your E-mailer is broken! It composes mails containing HTML-junk which inappropriate, especially for mailing lists. Please fix your mailer setup or use a working one. Gee, his mail is readable in mutt. Maybe it's your mail client? Don't use Kmail here so might it be your setup?? Wayne It's not my e-mailer which composes HTML-junk. It's not that I couldn't read this mail. My versions of kmail are able to render HTML-junk or only render the plain-text part if available. It is the simple fact that M$ ship their junkware with bogus defaults, which in this case unnecessarily blow up messages without any single bit of extra information. This wastes space and time. Some mailing lists will not even archive those mails. Talk about waste... you post an off-topic troll to complain about waste? -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need help splitting a directory
_N4R3N_ wrote: hi I want to split a directory in to two sub directories If my home dir is 1000 Mb I can't write it completely on one cd So i want to split it in to two directories namely 1)naren.bak.1 2)naren.bak.2 so that my /home/naren directory will be split in to two temporary directories .. so that i can write the images of thus formed using mkisofs on two cdroms and afterwards i also need help how do i combine them again. so that after copying two backup directories from the cdrom naren.bak.1 and naren.bak.2 in to /tmp directory I want to combine this two to make it again one directory say naren How do i do this I won't say this is the best thing to do, but the simple solution is links. Create as many subdirectories as you need, filled with links to the appropriate files, then back up each to a CD. I have some tools which help with this, but until I find time to get my ftp server back up I have no easy way to release them. I use that as motivation to get to rebuilding the server ;-) -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dvd+rw-tools Write Error
Bikrant Neupane wrote: On Sunday 17 October 2004 18:07, Rob Bogus wrote: Bikrant Neupane wrote: Hi, I have been using dvd+rw-tool for writing data in dvds for more than 7-8 months without any problem. I am running Red Hat Linux 7.2 with 2.4.24. I have no problem with HP dvd+rw 4.7GB (1x/2x) disc. But I came into this problem with new Memorex DVD+RW 4.7 Gb discs. I am using dvd+rw-tools-5.21.4.10.8 and Polaroid DVD Drive. Are you at the latest firmware revision? And who actually makes this drive? I assume Polaroid is just OEMing something else. Well I haven't upgraded the firmware. It is working fine. I am having problem only with new Memorex media. If it doesn't support certain brands of media then I would think it isn't "working fine," and is a candidate for upgrade. If the firmware doesn't support the media (properly) it's sometimes better to upgrade than to shop for old media, particularly if the media in question works for other people. Your choice, of course. -- E. Robert Bogusta It seemed like a good idea at the time
Re: dvd+rw-tools Write Error
Bikrant Neupane wrote: Hi, I have been using dvd+rw-tool for writing data in dvds for more than 7-8 months without any problem. I am running Red Hat Linux 7.2 with 2.4.24. I have no problem with HP dvd+rw 4.7GB (1x/2x) disc. But I came into this problem with new Memorex DVD+RW 4.7 Gb discs. I am using dvd+rw-tools-5.21.4.10.8 and Polaroid DVD Drive. Are you at the latest firmware revision? And who actually makes this drive? I assume Polaroid is just OEMing something else. This is the command I use to burn dvds growisofs -dvd-compat -Z /dev/scd0=backup.iso And the error I am getting with the new dvds: # ./growisofs -dvd-compat -Z /dev/scd0=/backup/Encrypted-iso/backup.iso Executing 'builtin_dd if=/backup/Encrypted-iso/backup.iso of=/dev/scd0 obs=32k seek=0' /dev/scd0: pre-formatting blank DVD+RW... /dev/scd0: Current Write Speed is 1.0x1385KBps. :-[ [EMAIL PROTECTED] failed with SK=5h/ASC=30h/ACQ=06h]: Input/output error :-( media is not formatted or unsupported. :-( write failed: Input/output error #./dvd+rw-format /dev/scd0 * DVDRW/-RAM format utility by [EMAIL PROTECTED], version 4.10. * 4.7GB DVD+RW media detected. * formatting -:-[ STOP DE-ICING failed with SK=5h/ASC=30h/ACQ=06h]: Input/output error Media info for Memorex # ./dvd+rw-mediainfo /dev/scd0 INQUIRY:[DVDRW ][IDE1004 ][0039] GET [CURRENT] CONFIGURATION: Mounted Media: 1Ah, DVD+RW Current Write Speed: 1.0x1385=1385KB/s Write Speed #0:1.0x1385=1385KB/s :-( reported write performance might be bogus GET [CURRENT] PERFORMANCE: Write Performance: 1.0x1385=1385KB/[EMAIL PROTECTED] - 2295104] Speed Descriptor#0:00/0 [EMAIL PROTECTED]/s [EMAIL PROTECTED]/s READ DVD STRUCTURE[#0h]: Media Book Type: 92h, DVD+RW book [revision 2] Media ID: MBIPG101/W03 Legacy lead-out at:2295104*2KB=4700372992 READ DISC INFORMATION: Disc status: blank Number of Sessions:1 State of Last Session: empty Number of Tracks: 1 READ TRACK INFORMATION[#1]: Track State: blank Track Start Address: 0*2KB Next Writable Address: 0*2KB Free Blocks: 2295104*2KB Track Size:2295104*2KB READ CAPACITY: 1*2048=2048 -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dvd burning problem, dvd+rw-tools, LG GSA-4120B
Ronny Haryanto wrote: On Sun, Sep 26, 2004 at 12:50:58AM +1000, Ronny Haryanto wrote: :-[ [EMAIL PROTECTED] failed with SK=4h/ASC=09h/ACQ=01h]: Input/output error builtin_dd: 1716384*2KB out @ average 3.8x1385KBps :-( write failed: Input/output error /dev/hdc: flushing cache :-[ FLUSH CACHE failed with SK=4h/ASC=09h/ACQ=01h]: Input/output error /dev/hdc: updating RMA /dev/hdc: closing disc Hmm. I checked the disc physically and saw a big scratch right where the the last data was written. I tried again with another media, and this time it worked until it finished 100% and I checked all the files was working fine. I'm almost certain it's the media now. Sorry for the noise, folks. Hopefully somebody could benefit from my postings and not use the same media (Mr.Data DVD-R 8x; CMC MAG. AE1) with LG GSA-4120B. I know I won't buy CMC again. I doubt any other media will work better with a "big scratch" and it's unlikely to have been added in manufacturing. You may want to avoid media with big scratches, and your firmware may be deficient, but I don't think either of those indicates a general problem with CMC. -- E. Robert Bogusta It seemed like a good idea at the time
Re: cdrtools-2.01 ready
Joerg Schilling wrote: After nearly 2 years of hard work for Free Software, i am proud to announce the final version of cdrtools-2.01. Check ftp://ftp.berlios.de/pub/cdrecord/ for the sources. Jörg Thanks! -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord problems with TDK 440n DVD+/-rw
On Mon, 19 Jul 2004, Joerg Schilling wrote: From: Bill Davidsen [EMAIL PROTECTED] Dan wrote: On Sat, 2004-07-17 at 19:19, Bill Davidsen wrote: lsof and see what process is causing the problem. Here's a ps -A and lsof of when I kill as much as I can and still have the problem: PID TTY TIME CMD 1 ?00:00:02 init 2 ?00:00:01 migration/0 3 ?00:00:00 ksoftirqd/0 I do not rember to have ever get information from you that would make the above information useful. The original discussion suggested that another process might be accessing the drive. I suggested using lsof to see if there was such a process. I didn't add or delete you from the original list of recipients as it came to me. -- Bill Davidsen @ TMR Associates . inc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Backup thousands of files 1 at a time with growisofs?
Volker Kuhlmann wrote: I would particularly like to have my music uncompressed, untarred so I can just put the dvd into a machine and play them. This would require each disk to have an in itself complete iso fs with a subset of the files. Each disk may be slightly underfull. http://www.serice.net/shunt/ Brilliant piece of software by the looks of it. Thanks for the URL! Check whether it creates disks with a complete filesystem, or whether it creates one huge filesystem with a piece of the filesystem on each disk. In the latter case individual disks wouldn't be accessible. Alternatively, you could hack up some script which reads through your music directory, sizing up as many files as fit on one disk, burn that disk, and then proceed with the next file in the directory. I have a generalized perl script which reads a file in size-name format, and generates output file(s) of items which will fit on a single media. The size of a media and the per-item overhead are command line parameters. This isn't limited to files, I use du -S to generate backups with all of a single directory on a single media. It also tries to equalize the content on each media, so you don't get a bunch of full media ending with one having virtually nothing. That's just my preference, it could be optional (and may be, I don't have the code in front of me). I originally wrote it in awk a few decades ago when I run a UNIX BBS and backed up my 20MB hard drive to 400k floppies. World changed, problems unchanged, backup media is still too small. In either case you have no control over which file goes on which disk, i.e. it'll be somehwat random. Yes, that's a problem. And the processing time needed to get a really perfect packing can be great if the data just fit on N media (or just don't quite fit). -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 100% system CPU usage with cdrecord
Joerg Schilling wrote: From: Rob Bogus mail account [EMAIL PROTECTED] I *strongly* suggest using ide-scsi with 2.4 kernels. You want to boot with something like hdc=ide-scsi I believe, that what I use for all my working 2.4 systems. The device will probably be 0.0.0, but do check by looking at /proc/scsi/scsi to be sure. I have not had any problems with ide-scsi under 2.6 kernels since 2.6.2 or so, but the ATAPI interface is much easier on the CPU for audio burn. The ATAPI: interface has no DMA at all The ATA: fixes a DMA bug that should be ficed the same way for ide-scsi. It is just annoing to see that the Linux kernel folks first copied the code from ide-scsi just to create this unneeded new interface and later onlu fixed the bug in the copy but not in the original Thank you for catching this! The original post had ATAPI and I read it as ATA (brain fart). What he said, what I meant, not what I said. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problem burning DVD's with one batch of Ritek DVD-R blanks
On Tue, 29 Jun 2004, Bill Sidhipong wrote: Hello folks, I am just getting started with burning DVD's for backup purposes. So far I have burned about 10 disks from a small trial pack :-) and I thought all was set to go for the real thing when the pack was used up. Wrong. On the new pack (same manufacturer, same media ID), I cannot burn DVD's successfully. The burning process stops at same point in to the media. I have burned five coasters this way with reboots, stopping automount daemons, disabling DMA's, etc. Any help is appreciated. Two things come to mind, either your batch of media is garbage (it happens) or your o/s or hardware has gone bad (unlikely unless you were doing something with it). Can you read all of the files on a previous media? Can you boot to another operating system and try a burn? Have you tried a batch of another vendor's media? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 100% system CPU usage with cdrecord
On Wed, 30 Jun 2004, Charles Steinkuehler wrote: The only kind of odd thing I'm doing is using the ATA support in cdrecord to talk to the burner rather than SCSI emulation (I was having problems getting that going...apparently I don't yet fully understand the interaction of the new libata and the hda=scsi kernel command line parameter), but trolling the mailing list seems to indicates this should be faster than the older scsi emulation. The actual cdrecord command I'm using: cdrecord dev=ATAPI:0,0,0 driveropts=burnfree speed=48 -dao -v image.iso I *strongly* suggest using ide-scsi with 2.4 kernels. You want to boot with something like hdc=ide-scsi I believe, that what I use for all my working 2.4 systems. The device will probably be 0.0.0, but do check by looking at /proc/scsi/scsi to be sure. I have not had any problems with ide-scsi under 2.6 kernels since 2.6.2 or so, but the ATAPI interface is much easier on the CPU for audio burn. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: HD_BURN
On Tue, 22 Jun 2004 [EMAIL PROTECTED] wrote: On 21. June 2004 at 6:27PM -0400, Bill Davidsen [EMAIL PROTECTED] wrote: I just got a dual-layer DVD burner which includes a feature identified as HD_BURN, which claims to be able to put 1.4GB on a CD blank readable in a DVD reader (any DVD reader). Interesting. What model/brand is that? Optorite DD1203. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Best way to write DVD+R?
Joerg Schilling wrote: From: [EMAIL PROTECTED] The same command as above Note that with dev=ATAPI: you will never get DMA and writing is s slow. I thought that had been fixed, I would swear that cdrecord uses DMA with ATAPI and 2.6 kernels. Now I have to go back and check, I replaced the CD-R drive with an unsupported DVD unit which doesn't work with anything. I'm a bit confused myself. The documentation isn't too clear about the difference between dev=ATA and dev=ATAPI. I tend to use dev=ATA with linux 2.6. This is the general problem with Linux :-( They invent a new incompatible interface every even year If you have problems, ask the Linux kernel people. How would the kernel people know what your software does. to restate, cdrecord seems to use DMA with 2.6, write audio very fast with little or no CPU use. Does pro-dvd also use DMA? That's a yes/no question, although any clarification would be useful. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Best way to write DVD+R?
Joerg Schilling wrote: From: [EMAIL PROTECTED] The same command as above Note that with dev=ATAPI: you will never get DMA and writing is s slow. I thought that had been fixed, I would swear that cdrecord uses DMA with ATAPI and 2.6 kernels. Now I have to go back and check, I replaced the CD-R drive with an unsupported DVD unit which doesn't work with anything. I'm a bit confused myself. The documentation isn't too clear about the difference between dev=ATA and dev=ATAPI. I tend to use dev=ATA with linux 2.6. This is the general problem with Linux :-( They invent a new incompatible interface every even year If you have problems, ask the Linux kernel people. How would the kernel people know what your software does. to restate, cdrecord seems to use DMA with 2.6, write audio very fast with little or no CPU use. Does pro-dvd also use DMA? That's a yes/no question, although any clarification would be useful. -- E. Robert Bogusta It seemed like a good idea at the time
Re: Best way to write DVD+R?
Joerg Schilling wrote:
From: Gregoire Favre [EMAIL PROTECTED]
Normally, I use this script to write my DVD (video):
#!/bin/tcsh
setenv SIZE `mkisofs -dvd-video -f -q -print-size -V $1 $2`
setenv CDR_SECURITY 8:d ...
mkisofs -dvd-video -f -V $1 $2 | cdrecord-prodvd -v dev=ATAPI:0,0,0 fs=64m speed=1 -eject -dao tsize={$SIZE}s -
(I am running kernel 2.6.5-mm6)
What should I do to use the DVD+R and become a maximum DVD video
compatibility?
The same command as above
Note that with dev=ATAPI: you will never get DMA and writing is s slow.
I thought that had been fixed, I would swear that cdrecord uses DMA with
ATAPI and 2.6 kernels. Now I have to go back and check, I replaced the
CD-R drive with an unsupported DVD unit which doesn't work with anything.
--
E. Robert Bogusta
It seemed like a good idea at the time
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Best way to write DVD+R?
Joerg Schilling wrote:
From: Gregoire Favre [EMAIL PROTECTED]
Normally, I use this script to write my DVD (video):
#!/bin/tcsh
setenv SIZE `mkisofs -dvd-video -f -q -print-size -V $1 $2`
setenv CDR_SECURITY 8:d ...
mkisofs -dvd-video -f -V $1 $2 | cdrecord-prodvd -v dev=ATAPI:0,0,0 fs=64m speed=1 -eject -dao tsize={$SIZE}s -
(I am running kernel 2.6.5-mm6)
What should I do to use the DVD+R and become a maximum DVD video
compatibility?
The same command as above
Note that with dev=ATAPI: you will never get DMA and writing is s slow.
I thought that had been fixed, I would swear that cdrecord uses DMA with
ATAPI and 2.6 kernels. Now I have to go back and check, I replaced the
CD-R drive with an unsupported DVD unit which doesn't work with anything.
--
E. Robert Bogusta
It seemed like a good idea at the time
Re: cannot setup HP7200 anymore
Joerg Schilling wrote: To: [EMAIL PROTECTED] I was suddenly hit by recent changes in linux. I tried today to use my old HP 7200 parallel port CD-Writer and there is no way I could make it appear as scsi device. I manage to load all the modules and I get pg: pg version 1.02, major 97 pg0: Sharing parport0 at 0x378 pg0: epat 1.02, Shuttle EPAT chip c6 at 0x378, mode 5 (EPP-32), delay 1 pg0: HP CD-Writer+ 7200, slave but when I try to load ide-scsi I can't see it as SCSI device. I wanted to try the new ide-cd interface but don't know how pg0 should be addressed. I'm pretty desperate. Why things that WERE working are broken now. Who is so stupid to do this? Sorry for that but I'm getting pretty desperate. The apripriate driver is pg, not ide-scsi . Linux confusion 99% of all HP CD-Writer+ 7200 are dead now. What he said. You should be using ide-scsi for this drive. And if you don't want things to change don't update your kernel. We're all fighting with changes from 2.4 to 2.6. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cannot setup HP7200 anymore
Joerg Schilling wrote: To: cdwrite@other.debian.org I was suddenly hit by recent changes in linux. I tried today to use my old HP 7200 parallel port CD-Writer and there is no way I could make it appear as scsi device. I manage to load all the modules and I get pg: pg version 1.02, major 97 pg0: Sharing parport0 at 0x378 pg0: epat 1.02, Shuttle EPAT chip c6 at 0x378, mode 5 (EPP-32), delay 1 pg0: HP CD-Writer+ 7200, slave but when I try to load ide-scsi I can't see it as SCSI device. I wanted to try the new ide-cd interface but don't know how pg0 should be addressed. I'm pretty desperate. Why things that WERE working are broken now. Who is so stupid to do this? Sorry for that but I'm getting pretty desperate. The apripriate driver is pg, not ide-scsi . Linux confusion 99% of all HP CD-Writer+ 7200 are dead now. What he said. You should be using ide-scsi for this drive. And if you don't want things to change don't update your kernel. We're all fighting with changes from 2.4 to 2.6. -- E. Robert Bogusta It seemed like a good idea at the time
Re: LF-D311 support?
Colette Dryden wrote: We are looking for a repair place that fixes these dvd ram drives? Also for the older style LF-D211V. Is there a place that does repair on panasonic dvd drives? You may want to investigate the cost of repair vs. the cost of a new unit. If there is a new unit which you can use, the TCO over a few years may be sugnificantly lower. That's why repair places are so hard to find and vendors usually exchange rather than repair waranty failures. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LF-D311 support?
Colette Dryden wrote: We are looking for a repair place that fixes these dvd ram drives? Also for the older style LF-D211V. Is there a place that does repair on panasonic dvd drives? You may want to investigate the cost of repair vs. the cost of a new unit. If there is a new unit which you can use, the TCO over a few years may be sugnificantly lower. That's why repair places are so hard to find and vendors usually exchange rather than repair waranty failures. -- E. Robert Bogusta It seemed like a good idea at the time
Re: Updated DVD patch for cdrecord
Warly wrote: Available at http://people.mandrakesoft.com/~warly/files/cdrtools/ Updated DVD patch (at present against a25) with a better DVD+RW formatting and burning support. scanbus will also display dev=ATA scanning if no dev option is passed on the command line, mostly because we are defaulting on ide-cd with 2.6 linux kernel. One question: is this against the Mandrake modified cdrecord in the same directory, or the unmodified source from Joerg? Or are the 'mdk' versions just stock source labeled to indicate the source? -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: extension of mkisofs for incremental backups
Joerg Schilling wrote: From: Rob Bogus [EMAIL PROTECTED] The alternative would be to group them by function, such as putting things which affect the device (dev=, speed=, burnfree, etc) in one group, things which affect format (-D -R -N, etc) in another, things which affect how the content is scanned (-f, etc), information visibility (various -hide and -hidden options), and rename options (-graft-points, etc). Functional grouping makes it faster to find things if you are looking for a way to keep long filenames or something like that, alphabetical is easier if you know the option and want to check what it does. Functional grouping makes it harder for the people who need the manual because the know little about the program. That's silly! If I know I want to set the speed, or enable burnfree, if I don't know the name of the option I need to read every one, where if if the options affecting writing are in one place I find it quickly. Likewise if I want to find out about the drive, having -atip, -prcap, and -msinfo all in one place would make sense to anyone, again better than reading every entry! -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: extension of mkisofs for incremental backups
Joerg Schilling wrote: From: Rob Bogus [EMAIL PROTECTED] The alternative would be to group them by function, such as putting things which affect the device (dev=, speed=, burnfree, etc) in one group, things which affect format (-D -R -N, etc) in another, things which affect how the content is scanned (-f, etc), information visibility (various -hide and -hidden options), and rename options (-graft-points, etc). Functional grouping makes it faster to find things if you are looking for a way to keep long filenames or something like that, alphabetical is easier if you know the option and want to check what it does. Functional grouping makes it harder for the people who need the manual because the know little about the program. That's silly! If I know I want to set the speed, or enable burnfree, if I don't know the name of the option I need to read every one, where if if the options affecting writing are in one place I find it quickly. Likewise if I want to find out about the drive, having -atip, -prcap, and -msinfo all in one place would make sense to anyone, again better than reading every entry! -- E. Robert Bogusta It seemed like a good idea at the time
Re: Compilation problem under SuSE 9.0
Plamen Neykov wrote: Hi all, I have problem compiling the cdrtools 2.01a25 under SuSE 9.0. The error message is: /usr/lib/gcc-lib/i586-suse-linux/3.3.1/../../../../i586-suse-linux/bin/ld: cannot find -lscg No clue, although adding the location of the library to the exvironment symbol LD_LIBRARY_PATH might help (that should be exported, of course). and in libscg I get the following error message: == COMPILING OBJ/i686-linux-cc/scsihack.o In file included from scsihack.c:127: scsi-linux-sg.c: In function `sg_settimeout': scsi-linux-sg.c:1135: error: `HZ' undeclared (first use in this function) scsi-linux-sg.c:1135: error: (Each undeclared identifier is reported only once scsi-linux-sg.c:1135: error: for each function it appears in.) make[2]: *** [OBJ/i686-linux-cc/scsihack.o] Error 1 make[2]: Leaving directory `/root/src/cdrtools-2.01/libscg' make[1]: *** [all] Error 2 make[1]: Leaving directory `/root/src/cdrtools-2.01/libscg' That looks like a cdrtools bug, the package depends on a non-standard setup of include files, and of course in recent kernels there is no such symbol, the current value is accessed from a function call. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: extension of mkisofs for incremental backups
Joerg Schilling wrote: From: Patrick Ohly [EMAIL PROTECTED] The patch to the man page indserts things disordered Where would you like me to insert the description of the new options? A while ago, I did try to have the options in alphabetical order. This seems to be the best when a command as s many options. The alternative would be to group them by function, such as putting things which affect the device (dev=, speed=, burnfree, etc) in one group, things which affect format (-D -R -N, etc) in another, things which affect how the content is scanned (-f, etc), information visibility (various -hide and -hidden options), and rename options (-graft-points, etc). Functional grouping makes it faster to find things if you are looking for a way to keep long filenames or something like that, alphabetical is easier if you know the option and want to check what it does. Both have advantages, this is just a comment and not a complaint. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Compilation problem under SuSE 9.0
Plamen Neykov wrote: Hi all, I have problem compiling the cdrtools 2.01a25 under SuSE 9.0. The error message is: /usr/lib/gcc-lib/i586-suse-linux/3.3.1/../../../../i586-suse-linux/bin/ld: cannot find -lscg No clue, although adding the location of the library to the exvironment symbol LD_LIBRARY_PATH might help (that should be exported, of course). and in libscg I get the following error message: == COMPILING OBJ/i686-linux-cc/scsihack.o In file included from scsihack.c:127: scsi-linux-sg.c: In function `sg_settimeout': scsi-linux-sg.c:1135: error: `HZ' undeclared (first use in this function) scsi-linux-sg.c:1135: error: (Each undeclared identifier is reported only once scsi-linux-sg.c:1135: error: for each function it appears in.) make[2]: *** [OBJ/i686-linux-cc/scsihack.o] Error 1 make[2]: Leaving directory `/root/src/cdrtools-2.01/libscg' make[1]: *** [all] Error 2 make[1]: Leaving directory `/root/src/cdrtools-2.01/libscg' That looks like a cdrtools bug, the package depends on a non-standard setup of include files, and of course in recent kernels there is no such symbol, the current value is accessed from a function call. -- E. Robert Bogusta It seemed like a good idea at the time
Re: extension of mkisofs for incremental backups
Joerg Schilling wrote: From: Patrick Ohly [EMAIL PROTECTED] The patch to the man page indserts things disordered Where would you like me to insert the description of the new options? A while ago, I did try to have the options in alphabetical order. This seems to be the best when a command as s many options. The alternative would be to group them by function, such as putting things which affect the device (dev=, speed=, burnfree, etc) in one group, things which affect format (-D -R -N, etc) in another, things which affect how the content is scanned (-f, etc), information visibility (various -hide and -hidden options), and rename options (-graft-points, etc). Functional grouping makes it faster to find things if you are looking for a way to keep long filenames or something like that, alphabetical is easier if you know the option and want to check what it does. Both have advantages, this is just a comment and not a complaint. -- E. Robert Bogusta It seemed like a good idea at the time
Re: how to read second track of a multisessioned dvd+r, in the burner ?
Andrea Tasso wrote: Hi all, I burn a dvd+r, with multisession. The commands I issued were: growisofs -Z /dev/dvd -R -J firstfile growisofs -M /dev/dvd -R -J secondfile how can I access secondfile ? I am trying to do it in the same recorder I used to burn the dvd, not in a dvd-ROM ... if I try mount -t iso9660 /dev/scd0 /mnt I see only firstfile. I tried the session=x option of mount, too, but it does not work. I was not able to guess if and how to use the sbsector=xxx option. Below you can see the output of dvd+rw-mediainfo for my dvd ... any help ? thanks and bye, Andrea The session info, like the partition table on a hard disk, is cached, it seems. If you eject and reload it should work fine. -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Interesting DVD behaviour
Dan The Carpetman wrote: I have the same problem. After spending 5 hours with Sony tech support all the way up to their engineers, I found that once you upgrade the firmware to 1.40 + your drive will burn 1X 2X DVD at 1X only. 4X DVD will burn at 2X. The upgrade cut back the speed so the drive won't burn out if you use 4X media.The Sony site had a warning that you must upgrade the firmware or you will damage your drive using 4X media. It also states the this upgrade will improve your drives performance! Sony say that they are working on changing their webpage to give the correct info. I just purchased 50 Pioneer certified ProDisk 2X blanks. Nero will only let them burn at 1X. Now that I've upgraded my drive is only half the speed it used to be. Sony told me that their is no way change the firmware back! The bottom line here is not to upgrade the firmware and don't use 4X media. Did you actually try running an older firmware back in? Or if your drive is supported by Joerg's loader, did you try that? A 2x drive which doesn't burn 2x media is broken, you should look to RMA it or get a refund if they don't make it work correctly. -- E. Robert Bogusta It seemed like a good idea at the time
Re: how to read second track of a multisessioned dvd+r, in the burner ?
Andrea Tasso wrote: Hi all, I burn a dvd+r, with multisession. The commands I issued were: growisofs -Z /dev/dvd -R -J firstfile growisofs -M /dev/dvd -R -J secondfile how can I access secondfile ? I am trying to do it in the same recorder I used to burn the dvd, not in a dvd-ROM ... if I try mount -t iso9660 /dev/scd0 /mnt I see only firstfile. I tried the session=x option of mount, too, but it does not work. I was not able to guess if and how to use the sbsector=xxx option. Below you can see the output of dvd+rw-mediainfo for my dvd ... any help ? thanks and bye, Andrea The session info, like the partition table on a hard disk, is cached, it seems. If you eject and reload it should work fine. -- E. Robert Bogusta It seemed like a good idea at the time
[Fwd: [Fwd: [ANNOUNCE] linux-libc-headers 2.6.2.0]]
For people writing software against Linux 2.6, this info may be useful.
--
E. Robert Bogusta
It seemed like a good idea at the time
---BeginMessage---
Send to mn/l
--
bill davidsen [EMAIL PROTECTED]
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
---BeginMessage---
Available at: http://ep09.pld-linux.org/~mmazur/linux-libc-headers/
Changes:
- applied changes from 2.6.2 kernel
- added an empty linux/compiler.h (I really hate myself for doing this, but
don't have much choice... many apps include it as a workaround for broken
headers that come with linux)
- some minor changes... mostly removing duplicate definitons and replacing
them with calls to glibc's headers
Enjoy.
--
Kady czowiek, ktry naprawd yje, nie ma charakteru, nie moe go mie.
Charakter jest zawsze martwy, otacza ci zgnia struktura przeniesiona z
przeszoci. Jeeli dziaasz zgodnie z charakterem wtedy nie dziaasz w ogle
- jedynie mechanicznie reagujesz. { Osho }
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
---End Message---
---End Message---
