Hi, i am the author of xorriso, which learned several essential DVD things from growisofs. In reply i try to help its users when Andy is not present. So have a few technical comments to your bugs.
------------------------------------------------ > [Ubuntu bug] 600770 : Input/output error closing session on BD-R burn > 600871 : disk-at-once (--use-the-force-luke=dao) a no-op for BD-R burns Andy promised to fix that in the next release. He stated it was not a show stopper. There are no different write modes DAO versus Incremental with BD media. BD-R writing resembles DVD+R, BD-RE writing is much like DVD-RAM. ------------------------------------------------ > 600869 : transport.hxx:366: error: INT_MAX was not declared in this scope > transport.hxx needs a #include <limits.h> On Linux, FreeBSD or Solaris this is ok. One would have to test the others or make this inclusion conditional. ------------------------------------------------ > 600893 : buffer size rounding for >2G fails > we run a high risk of buffer underr...@1m Underruns are not as fatal with DVD or BD as they once used to be with CD burners. The fifo buffer was introduced quite late in the life of growisofs. I understand it shall mainly smoothen the data stream and thus make use of the full possible media speed. ------------------------------------------------ > 600893 : erroneous reassignment to variable (keypunch?) > (profile&=0xF0)==0x40) // BD-R[E] Wow. That one looks dangerous on the first glimpse. But "profile" is a local variable which gets not used afterwards. The test result is ok. So the code is correct by accident. ------------------------------------------------ > 600898 : timeout delay in write loop too long for BD-R[E] > device buffer underrun/cache coherency > firmware problem affecting apparently only BD-R on Buffalo BRHC-6316U2 > (LG GGW-H20N) firmware level XJ03, I have 'HL-DT-ST' 'BD-RE GGW-H20L' rev 'YL03'. No problems with BD-R. (I make daily updates of a few dozen MB. But in the past there were full burns of 22 GB.) > cmd.timeout(dao_toggle?180:60); If i understand it right then this is a timeout for situations when the MMC command does not end voluntarily. Hard to believe that reducing the number has a positive effect on i/o performance or cache sanity. How does the problem express itself ? (Symptoms ?) Would you be willing to make tests with xorriso ? > buffer underrun protection and zero-loss linking features are not yet > universal). Since growisofs always formats BD-R there is really nothing to fear with buffer underruns. Media in that state and with the WRITE10 command as used by growisofs will checkread while writing and eventually replace bad blocks from a spare area. (That gives truly poor performance.) I prefer full speed with the large burns and use WRITE12 or unformatted media. Even then i did not experience any buffer underrun damages with my tests. ------------------------------------------------ > 601092: 64k block size for BD-R write It seems needed for WRITE12 if the Streaming bit is on. This is the method i use to get full speed out of formatted BD media. > // should I check if lba+nbl is multiple of 64K in BD case? xorriso writes full 64 K chunks to BD, aligned to 64 K addresses (i.e. LBA % 32 == 0). It seems not very natural to use other sizes. 64 K chunks also may have a positive effect on USB throughput to DVD recorders. So i personally use 64 KB with all DVD types, too. ------------------------------------------------ > 601125: code maintainability, modularity and readability issues Do you really want to convince Andy of a re-write ? My own project has a much more elaborate architecture (only in part my work) and similar features. I learned a lot about MMC from dvd+rw-tools code. Comparing both, i would say it is not harder to understand Andy's code than ours. Where you have to hop forth and back in his source, you have to drill holes through several layers of abstraction in ours. Yes, Andy's C tricks are smart with implicite limitations. I prefer to write more dull code and leave it to the optimizer to be smart. I see a more serious problem, nevertheless: On Linux, growisofs and its children perform block device driver operations and generic SCSI driver operations on the same device during the same program run. Both drivers are fewly coordinated. ------------------------------------------------ Have a nice day :) Thomas -- 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/94860511711...@192.168.2.69