Re: Possible way to get better bug reports/support requests for CDRecord
Lourens Veen <[EMAIL PROTECTED]> writes: > Yesterday, MPlayer crashed on me. In itself that's not so > interesting, but what was interesting was their crash handler. A > message popped up explaining that MPlayer had crashed, and that > that was a bug. Then it proceeded to explain how to get basic > debugging info, with a reference to a web page explaining how to > submit bug reports. It also told me not to expect any reply unless > I followed these rules to the letter. > > I'm wondering, would this be a useful feature for CDRecord? It could > print such a message when an error occurs, perhaps with a command > line switch to turn it off for expert users who know that what > they're doing might go wrong, or for use in shell scripts that only > want a return value. > > I know there's a feature freeze now, but perhaps this could be > included before the next release still? I bet a lot of people will > upgrade and have problems, this may well be a good way to manage > the chaos a bit better. Well, this kind of crash handler is just a signal handler - some code which is executed when the operating system tells a process (a program being executed) that it has done something way wrong. It replaces the default behaviour of dumping the core. So the process has to do something what the operating system can recognize as being wrong. By now I never saw cdrecord crashing in this way. cdrecord certainly outputs SCSI error messages if something goes wrong, but these are errors detected by cdrecord itself. The operating system stays completely cool about them. So what's needed is some translation of plain SCSI error messages to instructions what could be done to fix it. However this is a feature already wished for a dozen times, which requires knowledge about: - SCSI MMC standards & Co - the hardware out there and its behaviour - the behaviour of involved software like the operating system (for all the many flavours and versions) There was already the idea of extracting the mailings to this list to a database for easiness of search. Well, I personally go with a searchable mailing list archive. Regards, Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Haftalik Bulten
Title: YURT PARTISI Mail Listemizden Çýkmak Ýstiyorsanýz Lütfen Týklayýnýz. Ýrde Ýnternet Hizmetleri
Re: CDRecord-ProDVD
From: Joerg Schilling <[EMAIL PROTECTED]> Subject: Re: CDRecord-ProDVD Date: Sun, 27 Oct 2002 16:12:35 +0100 (CET) Message-ID: <[EMAIL PROTECTED]> schilling> >From [EMAIL PROTECTED] Fri Oct 25 18:54:35 2002 schilling> schilling> >I am not even sure why are you even on this list if everything is schilling> >answered in the man pages or readmes. schilling> schilling> >Remember, not all questions are directed at you. I don't remember schilling> >emailing you, but emailing the mailing list. There are many other people schilling> >on the list who might answer a question even though the answer might be schilling> >hidden deep inside a man page in a poorly written sentence. If you feel schilling> >that the answer is in the man page, just keep that to yourself. schilling> schilling> ... ans none of the other people did answer within a day schilling> schilling> Jörg Äh... sorry... WHAT ? keep hacking! Meino -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Possible way to get better bug reports/support requests for CDRecord
Yesterday, MPlayer crashed on me. In itself that's not so interesting, but what was interesting was their crash handler. A message popped up explaining that MPlayer had crashed, and that that was a bug. Then it proceeded to explain how to get basic debugging info, with a reference to a web page explaining how to submit bug reports. It also told me not to expect any reply unless I followed these rules to the letter. I'm wondering, would this be a useful feature for CDRecord? It could print such a message when an error occurs, perhaps with a command line switch to turn it off for expert users who know that what they're doing might go wrong, or for use in shell scripts that only want a return value. I know there's a feature freeze now, but perhaps this could be included before the next release still? I bet a lot of people will upgrade and have problems, this may well be a good way to manage the chaos a bit better. Comments? Lourens PS: Oh, I'm willing to write the text if you want me to. I'm not a native English speaker but my written English is as good as that. -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CDRecord-ProDVD
>From: csj <[EMAIL PROTECTED]> >> If you believe that the man page should be rewritten, you are welcome >> to do the job! >> >> I would be happy if at least some of the cdrtools users leave their >> attitute of only waiting for being supplied with free software. >Since the discussion drifted to language, I'd like to comment on the >following cdrecord output: >Track 01:5 MB written (fifo 100%) [buf 100%] 10.6x. 2.47% done, >estimate finish Sat Oct 26 04:57:16 2002 >I believe "estimate finish" is better rendered as "estimated finish", >unless the phrase expands to "I estimate the burn will finish at [*]". >Otherwise I tend to read it as "The burn's estimated finish is at [*]", >where "estimated" is used as a participle modifiying the noun "finish." >Constructions similar to this would be "unwritten law" or "estimated >time of arrival" (ETA). The text is not from cdrecord but from mkisofs and has been writtn by Eric Youngdale - a nativ English speaking american. Jörg EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) If you don't have iso-8859-1 [EMAIL PROTECTED] (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CDRecord-ProDVD
>From: Karl Bellve <[EMAIL PROTECTED]> >As far as reading man pages and readmes...I bet I am one of the few >people on this planet that has gotten rscsi to even work! If you know how to use and set up 'rsh' commands on your system, it is pretty simple. Setting up RSCSI on win32 really is not trivial, but this is caused by win32 constraints. Jörg EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) If you don't have iso-8859-1 [EMAIL PROTECTED] (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CDRecord-ProDVD
>From [EMAIL PROTECTED] Fri Oct 25 18:54:35 2002 >I am not even sure why are you even on this list if everything is >answered in the man pages or readmes. >Remember, not all questions are directed at you. I don't remember >emailing you, but emailing the mailing list. There are many other people >on the list who might answer a question even though the answer might be >hidden deep inside a man page in a poorly written sentence. If you feel >that the answer is in the man page, just keep that to yourself. ... ans none of the other people did answer within a day Jörg EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED] (uni) If you don't have iso-8859-1 [EMAIL PROTECTED] (work) chars I am J"org Schilling URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix ,. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cdrtools-1.11a39 ready
NEW features of cdrtools-1.11a39: Please have a look at the German open Source Center BerliOS at www.berlios.de BerliOS will continue to support free hosting of cryptography projects even when US laws change and don't allow to host cryptography projects in the USA. Also look at sourcewell.berlios.de, the first Open Source announcement service that itself is implemented as Open Source project. * Important news For the 'Slottable Source Plugin Module' SSPM Features read README.SSPM * Please Test * There will soon be a new final release for cdrtools. Please do not send new patches for new features before the final is out. Please note that the DVD-Video patch was a big modification (it took a week for only cleanly integrating the patch) so please test! ** IMPORTANT: In order to prepare a new major release, I now declare a feature freeze. Only important Bug Fixes will be applied to the source until the next major release has been published. With 1.11a39 all known problems for cdrtools have been fixed. 1.11a39 is the first release candidate for the upcoming next major release. After 1.11a39 only important and major bugs will be fixed ** All: - Makefilesystem changed $(MAKE) to "$(MAKE)" to allow spaces in pathnames - Small fixes for VMS Libparanoia: Libedc: Libscg: - Try to fix problems with a bad patch send by Linus Torvalds Clear O_NONBLOCK directly after opening a device to allow libscg to work with old sg drivers. - Fixed several typo's. - Avoid to read from the media (when using the new experimental Linux ATAPI transport) while trying to clear old sg driver status. - Woraround for Linux kernel design bug: CDROM_SEND_PACKET sets errno to EINVAL in case SCSI sense key is "Invalid command". Rscsi: Cdrecord: - Warn to use cdrecord blank=all if a drive rejects cdrecord blank=fast - Fixed a bug that became obvious with Yamaha AudioMaster mode and CD-Text The problem was caused by the fact that cdrecord did not allow to overwrite the lead in start time in cdrecord's internal data structures. - Fixed a bug with recognition of complete disks that came up after cdrecord did allow to deal with >= 90 minute CD's. - Changed Text "BURN-Free was not used" to "BURN-Free was never needed" because people did believe that the old text means that Burn-Proof has been disabled. - Man page now includes a hint that padsize is always using 2048 as sector size. - Fixed a bug with padsize=xxx if sector size was not 2048 bytes. Cdrecord in this case did just divide the number of pad bytes by the number of bytes in an output sized sector (e.g. 2448 or 2352 bytes). This did result in a too low number of padding sectors. The fix caused a complete rewrite of the pad size handling. - Treat packet mode similar to normal writing: Print Drive buffer fill ratio and current write speed. - Treat padding similar to normal writing: Print Drive buffer fill ratio and current write speed. - Make verbose printing consistent and non-jumping - A new experimental feature of the -immed flag is to tell cdrecord to try to wait short times wile writing to the media. This is expected to free the IDE bus if the CD/DVD writer and the data source are connected to the same IDE cable. In this case, the CD/DVD writer would otherwise usually block the IDE bus for nearly all the time making it impossible to fetch data from the source drive. As this is an experimental feature, I would like to get feedback. /*--*/ New driveropts= option "tattoofile=". Use together with -checkrive to write an image of the right size to disk. DiskT@2 hints: In order to have "DISKTATTOO" listed in the "Driver flags", the disk currently inserted must be usable for the DiskT@2 feature. This means that there needs to be enough space on it. You need an B&W image with 3744 pixels per line Best start with a 3744 x 320 pixel image. The correct size may be retrieved with cdrecord driveropts=tattooinfo -checkdrive To get RAW image data: - Take 'xv' and save the image in PBM/PGM/PPM (raw) mode - use a binary aware (must support unlimited linelength) editor such as 'ved' and remove the header lines. These lines look like: P5 # CREATOR: XV Version 3.10a Rev: 12/29/94 (PNG patch 1.2) # CREATOR: XV Version 3.10a Rev: 12/29/94 (PNG patch 1.2) 3744 144 255 N
