Re: Linux problems
Thomas Schmitt [EMAIL PROTECTED] wrote: Joerg Schilling: Alan Cox [...] with his answers to Mr. Bloch, he was correct, but I did not see him writing this claim. That's what i understand from this statement by Alan Cox http://lkml.org/lkml/2007/3/31/175 OK, it seems that I forgot about the less important parts. I interpret this like: Kids, manage this yourself, like the Terminalovski brothers from the neighbor house did. Well, Dialup Terminalovski is an ageing web criminal now. Uucp Terminalovksi lost his job to the Internet. Kermit Terminalovski went back to showbiz. Do they really want us to end up like that ?! Well, this kind of rant verifies that he has no clue. The tty dial in/out problem is unrelated to the SCSI / removable media problem. The tty problem has been solved more than 25 years ago. There are two devices /dev/ttya /dev/cua0 The dialout device cua0 is blocked as long as a dial in is active and the dial in device is blocked as long as a dial out is active. This is a simple task compared to what cdrecord does on UNIX. There are only two programs with completely different tasks for ttys. There are many different taks related to CD/DVD sersives. Joerg Schilling: If he did really write that it is a Linux userland only problem, he is of course wrong. This becomes evident by my failure to coordinate cdrskin and libblkid. Ted T'so is my witness that i did consider any known locking mechanism and that each of them failed to match our needs. Those needs are not exotic. Forget usual locking mechanisms, they will all not work. I'm open to proposals. (Expect some counter arguments from my side but be assured that i hope to lose in my role as advocatus diavoli.) You cannot find a solution for Linux as long as the related people are unwilling acept a solution. As long as Linux implements 3 or more unrelated and unsynchronized paths to the same hardware it is impossible to even add the basic support that works on Solaris sine a long time. There are issues that are even not solved on Solaris but you cannot solve them on Linux if the basics are impossible. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: Linux problems
If you are willing to tolerate deadlock, a simple kernel patch suffices. Such a solution is, surely, ugly, but may be a better alternative than no solution at all. -Original Message- From: Joerg Schilling [mailto:[EMAIL PROTECTED] Sent: Sunday, July 29, 2007 8:25 AM To: [EMAIL PROTECTED]; cdwrite@other.debian.org Subject: Re: Linux problems Thomas Schmitt [EMAIL PROTECTED] wrote: Joerg Schilling: Alan Cox [...] with his answers to Mr. Bloch, he was correct, but I did not see him writing this claim. That's what i understand from this statement by Alan Cox http://lkml.org/lkml/2007/3/31/175 OK, it seems that I forgot about the less important parts. I interpret this like: Kids, manage this yourself, like the Terminalovski brothers from the neighbor house did. Well, Dialup Terminalovski is an ageing web criminal now. Uucp Terminalovksi lost his job to the Internet. Kermit Terminalovski went back to showbiz. Do they really want us to end up like that ?! Well, this kind of rant verifies that he has no clue. The tty dial in/out problem is unrelated to the SCSI / removable media problem. The tty problem has been solved more than 25 years ago. There are two devices /dev/ttya /dev/cua0 The dialout device cua0 is blocked as long as a dial in is active and the dial in device is blocked as long as a dial out is active. This is a simple task compared to what cdrecord does on UNIX. There are only two programs with completely different tasks for ttys. There are many different taks related to CD/DVD sersives. Joerg Schilling: If he did really write that it is a Linux userland only problem, he is of course wrong. This becomes evident by my failure to coordinate cdrskin and libblkid. Ted T'so is my witness that i did consider any known locking mechanism and that each of them failed to match our needs. Those needs are not exotic. Forget usual locking mechanisms, they will all not work. I'm open to proposals. (Expect some counter arguments from my side but be assured that i hope to lose in my role as advocatus diavoli.) You cannot find a solution for Linux as long as the related people are unwilling acept a solution. As long as Linux implements 3 or more unrelated and unsynchronized paths to the same hardware it is impossible to even add the basic support that works on Solaris sine a long time. There are issues that are even not solved on Solaris but you cannot solve them on Linux if the basics are impossible. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux problems
Hi, Seth Kurtzberg: If you are willing to tolerate deadlock, a simple kernel patch suffices. Such a solution is, surely, ugly, but may be a better alternative than no solution at all. By deadlock you mean that both contestants are denied access ? Not that anything gets stuck if it wants non-blocking i/o, i hope. Such a solution would indeed be an improvement. But is it beautiful enough to replace the current behavior in the main stream kernels ? I.e. can we convince the decisive people to accept it ? It would not help much if we had to prescribe kernel patching before proper burning of CD and DVD is possible. I myself would frown on that and rather do what has to be done to make my /dev/s[gr][0-9]* safe. No automats groping my drives. Basta. But the goal of cdrskin is to be installable on any modern Linux distro. So i can neither demand people to calm down their autmats nor can i demand them to create custom kernels. Nevertheless and anyway: What does this patch do ? Is it explainable to userland programmers ? Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord problems
Joerg Schilling wrote: Bill Davidsen [EMAIL PROTECTED] wrote: Paragraph 4.3.7 DVD+R Dual Layer is much more detailed about the layer hop. Nevertheless there is a statement which makes me believe it is worth a try to just write to it as to a fat DVD+R. That seems to work. I did some backups that way, creating big files and just burning them. I believe I used growisofs but I can't be sure after the fact. Reading the data back produced no read errors and a correct md5sum, I did wipe the original and test restore, though. ;-) As you don't know what you did, it is a good idea not to believe you... Not setting the layer break on DVD+R/DL may work in principle but it causes a lot of headaches. If you do not set the layer break, you need to write both complete surfaces. Of course! That is exactly what I said I did, I wrote the data to a big file, ~8.2GB, then burned. As for both complete surfaces, the last volume was only 6.7GB or so, and read back fine. So having to write an image covering both complete surfaces (what you said) doesn't seem required.. Did you ever try just writing an 8GB image to a DL, without specifying the layer break, to see what it does? Or is that a requirement of your software and not growisofs and the enhanced cdrecord which Fedora provides? -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux problems
Joerg Schilling wrote: The tty dial in/out problem is unrelated to the SCSI / removable media problem. The tty problem has been solved more than 25 years ago. There are two devices /dev/ttya /dev/cua0 The dialout device cua0 is blocked as long as a dial in is active and the dial in device is blocked as long as a dial out is active. This is a simple task compared to what cdrecord does on UNIX. There are only two programs with completely different tasks for ttys. There are many different taks related to CD/DVD sersives. Two? Which two of getty, ppp, slip, uucico/uucp, kermit, X10power, and nut? Not to mention the getty+ alternatives which include fax and voice mail. You were right saying the problem was solved, but your count of applications is low. NOTE: nut is one of the serial applications which monitor a UPS, there are others. If a good solution is available, applications will change to use the solution. -- bill davidsen [EMAIL PROTECTED] CTO TMR Associates, Inc Doing interesting things with small computers since 1979 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord problems
Bill Davidsen [EMAIL PROTECTED] wrote: As for both complete surfaces, the last volume was only 6.7GB or so, and read back fine. So having to write an image covering both complete surfaces (what you said) doesn't seem required.. Did you ever try just writing an 8GB image to a DL, without specifying the layer break, to see what it does? Or is that a requirement of your software and not growisofs and the enhanced cdrecord which Fedora provides? ? You seem to be missinformed again. Fedora does not provide an enhanced cdrecord. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux problems
Bill Davidsen [EMAIL PROTECTED] wrote: Joerg Schilling wrote: The tty dial in/out problem is unrelated to the SCSI / removable media problem. The tty problem has been solved more than 25 years ago. There are two devices /dev/ttya /dev/cua0 The dialout device cua0 is blocked as long as a dial in is active and the dial in device is blocked as long as a dial out is active. This is a simple task compared to what cdrecord does on UNIX. There are only two programs with completely different tasks for ttys. There are many different taks related to CD/DVD sersives. Two? Which two of getty, ppp, slip, uucico/uucp, kermit, X10power, and nut? Not to mention the getty+ alternatives which include fax and voice mail. You were right saying the problem was solved, but your count of applications is low. Your claims are not related to the Linux removable media problems. Why do you try to start an off-topic discussion? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord problems
Thomas Schmitt wrote:
Hi,
Bill Davidsen:
I did recently discover that it [cdrskin] has limitations
doing odd raw burns, but that's not a usual requirement,
Would it be indiscrete to ask for the use case and what
cdrecord write mode option you wanted to apply ?
Not in the least, I was trying a vcd creation program which said I
should burn the output file with -raw so I did.
libburn contains code for raw write modes and i implemented
in cdrskin option -raw96r without knowing much of the
technical background.
If you think that will work better I will be glad to try it, burning
with -raw and cdrecord worked but the media doesn't play, so I presume
something else is amiss.
I'm just trying to take a bunch of clips and make a how to do it vcd
from them, so I can give it to people with questions. I've about given
up on doing it in Linux, and I ship stuff to a Windows user providing a
clip and a title for each, and she has a program which actually can
write a usable media providing nothing but the clip name, clip title,
and title for the menu.
The programs I find either don't work, assume you know whuch obscure
formats to use, require writing of large xml programs, or have no
documentation beyond works just like {Windows prog}. At this point I
have decided there is no simple program in Linux, there is in Windows,
and I just won't mention the subject when talking about how great Linux
apps are. ;-)
But to my experience this mode is unappealing for data
recording although it allows higher throughput and
capacity:
- The time sharing granularity of my system becomes awful,
Yes, even with a tuned cfs scheduler. If you run 2.6.22 or later I can
suggest some tuning values which might help.
- one of my drives can become totally unusable afterwards,
That happened with cdrecord as well, so I wasn't sure if it was hardware
or software. It'not your software alone.
- the higher capacity is at expense of less error detection
and correction.
Not an issue here, I suspect.
Nevertheless, if you give me hints about what and why then
i would begin and try to learn about subchannels and all.
How about if I just try a burn with raw96r and see if that works? As in
successfully writes a vcd my DVD player won't play? I'll let you know,
the system is sitting on a chair right now, I needed space in a bay for
another machine, so the test box is out until late tonight, or Tuesday
if I don't get time today.
--
bill davidsen [EMAIL PROTECTED]
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord problems
Bill Davidsen [EMAIL PROTECTED] wrote: Thomas Schmitt wrote: Hi, Bill Davidsen: I did recently discover that it [cdrskin] has limitations doing odd raw burns, but that's not a usual requirement, Would it be indiscrete to ask for the use case and what cdrecord write mode option you wanted to apply ? Not in the least, I was trying a vcd creation program which said I should burn the output file with -raw so I did. libburn contains code for raw write modes and i implemented in cdrskin option -raw96r without knowing much of the technical background. If you think that will work better I will be glad to try it, burning with -raw and cdrecord worked but the media doesn't play, so I presume something else is amiss. If you used the official cdrecord and not a bastardized clone, it only depends on the data you give to cdredord. svcds need to be written with cue= Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord problems
Bill Davidsen [EMAIL PROTECTED] wrote: Joerg Schilling wrote: Bill Davidsen [EMAIL PROTECTED] wrote: http://www.arklinux.org/projects/dvdrtools/ This page is temporarily down because of spammer attacks; until it comes back, you can download dvdrtools from svn ... Now who would do a thing like that? Who can understand the anti-social mind anyway? It looks a bit strange that the first person who did abuse the cdrtools code for his anti-social games, tries to hide behind alleged net attacks. In special as it is obvious that he himself did only remove _all_ dvdrtools related pages from his webserver while other pages remained accessible. I would be interested to know why he did this surprisingly at the same time when other people started another speudo-fork on cdrtools. These other people did start another anti-social game against OSS users. Why are you making this vague claim of wrong doing with my name on it? If you are accusing me of something, have the balls to come out and say If you do not read a text, you should not send a reply. Instead of sending childish personal offenses against me, read the text and try to understand it. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cdrecord problems
Joerg Schilling wrote: Bill Davidsen [EMAIL PROTECTED] wrote: http://www.arklinux.org/projects/dvdrtools/ This page is temporarily down because of spammer attacks; until it comes back, you can download dvdrtools from svn ... Now who would do a thing like that? Who can understand the anti-social mind anyway? It looks a bit strange that the first person who did abuse the cdrtools code for his anti-social games, tries to hide behind alleged net attacks. In special as it is obvious that he himself did only remove _all_ dvdrtools related pages from his webserver while other pages remained accessible. I would be interested to know why he did this surprisingly at the same time when other people started another speudo-fork on cdrtools. These other people did start another anti-social game against OSS users. Why are you making this vague claim of wrong doing with my name on it? If you are accusing me of something, have the balls to come out and say it! And if you're talking about someone else, why did you leave my name on on this swill, instead of naming the person accused? You certainly deleted the names of all the other involved posters, and some of their email addresses from the post as well! Or are you afraid that if you actually say something instead of mumbling vague innuendo people will tell you you're full of crap? Petty backbiting whining, like a sniveling 13 year-old. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VCD (was: cdrecord problems)
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. What i could learn about VCD within an hour: Google hit #1 for VCD lets me believe that it needs some deep knowledge in and beyond MMC http://www.videohelp.com/vcd One mode 2 mixed form ISO-9660 track containing file pointers to the information areas. Up to 98 multiplex-ed mpeg-1 audio/video streams or cd-da audio tracks. This contains several keywords to be explored in MMC and in man cdrecord. Then i read http://www.geocities.com/athens/forum/2496/vcdfaq.html and get to http://www.mplayerhq.hu/DOCS/HTML/en/vcd.html where i read the usual statement: The definition of the Video CD standard is called the Philips White Book and it is not generally available online as it must be purchased from Philips. But also: The first track is in mode 2 form 2 format which means it uses L2 error correction. The track contains an ISO-9660 filesystem with 2048 bytes/sector. Somehow i can not recognize in MMC specs mode 2 form 2 with 2048 bytes/sector. 2048 is associated with form 1. man cdrecord brings me to the idea to try -xa. That would match the plan to write further tracks. The second and remaining tracks are generally raw 2324 bytes/sector MPEG [...] These are in mode 2 form 1 format Within man cdrecord only -xa2 promises 2324 bytes/sector. I assume the mplayer FAQ confuses form 1 and form 2. I see not much chance with current cdrskin. If you get cdrecord to work for you, tell me which options are actually needed. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VCD (was: cdrecord problems)
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. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily -- 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: VCD
Rob Bogus wrote: No he didn't, I was working on the rack next to Robbie's machine, and unlocked the screen to read the list. Then I replied as him. My bad, any disagreement with what I wrote under his name should fall on me. Joerg Schilling wrote: 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! But I do see that option. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
