You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(3) |
Dec
(3) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(5) |
Feb
(4) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(48) |
Jun
(26) |
Jul
(85) |
Aug
(16) |
Sep
(4) |
Oct
|
Nov
(27) |
Dec
(47) |
2011 |
Jan
(16) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(18) |
Nov
(3) |
Dec
|
2012 |
Jan
|
Feb
(10) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(14) |
Dec
(2) |
2014 |
Jan
(10) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Kamil I. <ac...@wp...> - 2014-01-06 19:00:46
|
On 03.01.2014 02:21, Roger wrote: > > mkudffs: Searching mkudffs.c code, return codes for mkudffs seem to be only -1, > 0, and 1, with no other ERROR codes defined within it's headers from what I > can see using fgrep. Basically, if UDF Revision/Version doesn't equal one of > the predefined versions, then return 1. I do see a RETURN 4 & 2 while writing > a disc, but this might be relevant to only packet writing. Also return 'spm' > when writing a partition map, but again not well documented. (Seems to be disc > writing or packet writing related errors, which doesn't seem relevant for brief > usage of mkudffs.) > > dvd+rw: Likely well documented RETURN codes within it's headers, and I think > you're already privy of this and the other tools. ;-) > >>From what I understand of mkudffs, it just works, with it's udffsck supposedly > not being a true fsck from hearsay from others' posts. Again, similar to the > DVD industry, we're probably only focused on mkudffs usage (for write only > once) and not anything else with the UDF filesystem. Great, thank you for the information. I will probably do some investigations on my own, but this is a good start. Best regards, Kamil |
From: Roger <rog...@gm...> - 2014-01-03 01:21:34
|
># Burn Blu-Ray Movie using UDF Filesystem ># mkudffs--udfrev= 0x0201, 0x0200, 0x0150, and 0x0102 ># Omitted, mkudffs uses 0x0201, and is best for BR media or any video related ># material. > ># Create the file container for filesystem >$ truncate --size=50GB ./test.udf > ># Make the UDF Filesystem. ('lvid' shows within Windows as the title volume ># name of the media.) >$ mkudffs --lvid="Name_of_DVD-BR" --utf8 ./test.udf > ># Mount the container filesystem for reading & writing to >$ sudo mount -oloop,rw ./test.udf /mnt/tmp/ > ># Make the user the owner of the sub-folders >$ chown -R roger.roger /mnt/tmp/* > ># Ensure recursive read and write permissions are set >$ chmod -R a+rX /mnt/tmp/* > ># Copy (cp -ax) or sync files to mounted loop filesystem >$ rsync -ax --delete /Some/Files/ /mnt/tmp/ > ># Unmount the mounted filesystem (and maybe recheck files by remounting the ># filesystem) >$ sudo umount /mnt/tmp > ># Can't write full contents using the maximum available size Blu-ray media as ># 256 MB is reserved by default for verification of files. This extra ># reservation of space can be disabled for write once media, having minimal to ># no neglible effects as it's likely used for read-write media. > ># Disable pre-formating or spare space with "use-the-force-luke=spare:none", >saving 256MB > ># dvd+rw-format -ssa=none /dev/sr0 > >Or during usage of growisofs: > ># growisofs -use-the-force-luke=spare:none -dvd-compat -speed=4 -Z /dev/sr0=test.udf mkudffs: Searching mkudffs.c code, return codes for mkudffs seem to be only -1, 0, and 1, with no other ERROR codes defined within it's headers from what I can see using fgrep. Basically, if UDF Revision/Version doesn't equal one of the predefined versions, then return 1. I do see a RETURN 4 & 2 while writing a disc, but this might be relevant to only packet writing. Also return 'spm' when writing a partition map, but again not well documented. (Seems to be disc writing or packet writing related errors, which doesn't seem relevant for brief usage of mkudffs.) dvd+rw: Likely well documented RETURN codes within it's headers, and I think you're already privy of this and the other tools. ;-) >From what I understand of mkudffs, it just works, with it's udffsck supposedly not being a true fsck from hearsay from others' posts. Again, similar to the DVD industry, we're probably only focused on mkudffs usage (for write only once) and not anything else with the UDF filesystem. -- Roger http://rogerx.freeshell.org/ |
From: Roger <rog...@gm...> - 2014-01-02 23:52:40
|
> On Fri, Jan 03, 2014 at 12:03:08AM +0100, Kamil Ignacak wrote: >On 02.01.2014 05:36, Roger wrote: >> Reading further into LDPI book on system(), seems using system() for secure >> set-user-id & set-group-id programs is bad, and should resort to fork() and one >> of the exec() -- other then execlp() and execvp() - directly. >> >> > >cdw uses exec*() since forever. It has been tested with various external >tools and commands in different situations, and it works well. Replacing >the exec*() with system() would require a lot of additional testing, and >this is something that I would rather want to avoid. Yup. The LDPI book states fork() and exec*() to be the more secure method, but more tedious. Since fork() and exec*() are already implemented, it would be rhetorical to rewrite using a less secure method. With your explanations, I'm able to understand CDW's road of travel. -- Roger http://rogerx.freeshell.org/ |
From: Kamil I. <ac...@wp...> - 2014-01-02 22:03:15
|
On 02.01.2014 05:36, Roger wrote: > Reading further into LDPI book on system(), seems using system() for secure > set-user-id & set-group-id programs is bad, and should resort to fork() and one > of the exec() -- other then execlp() and execvp() - directly. > > cdw uses exec*() since forever. It has been tested with various external tools and commands in different situations, and it works well. Replacing the exec*() with system() would require a lot of additional testing, and this is something that I would rather want to avoid. I think that I will go with adding waitpid(.... int *status, ...) to already existing fork() & exec*(). I see that I already call wait() in cleanup code after child process exits (cdw_sys.c), so I guess I can replace wait() with waitpid() and move the call to waitpid() to some more appropriate place. The whole forking and spawning new processes thing was never *very* important to me in cdw. Once I verified that this piece of code worked as expected, I totally forgot about it and focused on handling and parsing stdout and sterr streams from cdrecord, mkisofs & co. Maybe it's time to revisit cdw_thread.c and cdw_sys.c :) Best regards, Kamil |
From: Kamil I. <ac...@wp...> - 2014-01-02 21:52:16
|
On 02.01.2014 01:26, Roger wrote: >> *) maybe I could get this value through environment variable described >> in man exec(3), or maybe I should execute these commands with system(). >> Learning how to get value returned by executed commands should be the >> first thing to do when implementing the procedure you described. > > [...] > > I thought you were already calling some shell commands within the CDW code, as > you could already configure CDW to use custom commands? > Yes, cdw is doing a regular fork() & exec() in src/external_tools/cdw_thread.c/run_command(). But until now I wasn't interested in a value returned by a command. Output (stdout and stderr) from cdrecord, mkisofs and other tools was verbose enough to know when a tool has succeeded, and when (and how and why) it has failed. Running the commands that you listed for handling UDF images may change this. I may need to get the return value from the commands. Best regards, Kamil |
From: Roger <rog...@gm...> - 2014-01-02 04:36:30
|
Reading further into LDPI book on system(), seems using system() for secure set-user-id & set-group-id programs is bad, and should resort to fork() and one of the exec() -- other then execlp() and execvp() - directly. -- Roger http://rogerx.freeshell.org/ |
From: Roger <rog...@gm...> - 2014-01-02 00:57:01
|
>A quick search on Google reveals, >"C - How can i get return value of command passed to execl?" >http://stackoverflow.com/questions/2667095/c-how-can-i-get-return-value-of-command-passed-to-execl > >Likely a very popular and already thought out solution to this one. > >A second result shows, >"how can I get the return value of a program executed by exec?" >http://stackoverflow.com/questions/3776859/how-can-i-get-the-return-value-of-a-program-executed-by-exec > >call_shell_cmd (or exec_shell_cmd) >call_shell_cmd_returnval (or exec_shell_cmd_returnval) > >I thought you were already calling some shell commands within the CDW code, as >you could already configure CDW to use custom commands? Never mind. I'm reading my copy of the Linux Programming Interface, and on page 579, immediately following describing exec(), the system() function is described as the better & cleaner method, however less efficient method. Since CDW doesn't require much resources and we're still passing a significant amount of the demand onto hardware, efficiency is probably the least of our worries here unless we're writing on demand. Of which, I suspect the concern of efficiency when using system() is still extremely minimal. Keep it simple, and push the demand for readable code onto the compiler is what I say. system() is probably the way to go... ;-) -- Roger http://rogerx.freeshell.org/ |
From: Roger <rog...@gm...> - 2014-01-02 00:26:26
|
>Well, looks... complicated :) Yup.. What I hate about programming. It's easy if you yourself writes the code, but if somebody wants to contribute, they have to read & understand the (book of) code to further add to it. ;-) >If memory serves me well, I was able to create an ISO image file with just one >(or maybe two) command executed with exec(), and here we have a series of >commands to be executed in sequence. One of them also depends on user being >able to successfully run commands with sudo without the need to provide user >password. > >It surely could be done, and in first implementation I could just >somehow* capture return value from a command to only get its >success/failure status, to know whether I can execute the next command >in sequence. Maybe later on I could also capture some error messages >printed to stdout/stderr to learn why a command has failed. > >Complicated, but probably doable :) > >*) maybe I could get this value through environment variable described >in man exec(3), or maybe I should execute these commands with system(). >Learning how to get value returned by executed commands should be the >first thing to do when implementing the procedure you described. A quick search on Google reveals, "C - How can i get return value of command passed to execl?" http://stackoverflow.com/questions/2667095/c-how-can-i-get-return-value-of-command-passed-to-execl Likely a very popular and already thought out solution to this one. A second result shows, "how can I get the return value of a program executed by exec?" http://stackoverflow.com/questions/3776859/how-can-i-get-the-return-value-of-a-program-executed-by-exec call_shell_cmd (or exec_shell_cmd) call_shell_cmd_returnval (or exec_shell_cmd_returnval) I thought you were already calling some shell commands within the CDW code, as you could already configure CDW to use custom commands? -- Roger http://rogerx.freeshell.org/ |
From: Kamil I. <ac...@wp...> - 2014-01-01 22:19:23
|
On 27.12.2013 02:39, Roger wrote: > For the past few months, I've experimented with UDF writing and tend to prefer > UDF when compared to ISO image format. > > I'm really trying to read the CDW code, but not getting really far due to the > massive amount of require source code reading. :-/ > > (I got about as far as looking at the menus, and realizing the 'Create ISO > menu' would need to be heavily modified to allow or hook-in another image > writing type.) > > Anyways, for historical reasons and those scanning the web for UDF writing > instructions, here's what I do withing Bash command line with relatively good > success. (Atypically as always, write first to read-write media before doing a > final write to write once media.) > > [...] Well, looks... complicated :) If memory serves me well, I was able to create an ISO image file with just one (or maybe two) command executed with exec(), and here we have a series of commands to be executed in sequence. One of them also depends on user being able to successfully run commands with sudo without the need to provide user password. It surely could be done, and in first implementation I could just somehow* capture return value from a command to only get its success/failure status, to know whether I can execute the next command in sequence. Maybe later on I could also capture some error messages printed to stdout/stderr to learn why a command has failed. Complicated, but probably doable :) *) maybe I could get this value through environment variable described in man exec(3), or maybe I should execute these commands with system(). Learning how to get value returned by executed commands should be the first thing to do when implementing the procedure you described. Best regards, Kamil |
From: Kamil I. <ac...@wp...> - 2014-01-01 22:19:21
|
On 27.12.2013 03:09, Roger wrote: >> (I got about as far as looking at the menus, and realizing the 'Create ISO >> menu' would need to be heavily modified to allow or hook-in another image >> writing type.) > > I think the best uniform & easiest method of hooking in another filesystem > image writing, is to add options within the F2 Misc Menu, adding 'Default > Filesystem Image Type, ISO or UDF?' With this hook-in method, the 'Create > Image' menu option can easily divert into writing the (default) image (type) > with minimal editing of the existing menu code? > > Guess I'll go research what udftools library functions there are for writing > UDF and follow-up. > I didn't want to read the code right now, so I just started the cdw (I've got version 0.7.1 here), and I think that I would let user select image type in a wizard window that shows up when selecting "Create image" from main menu. The main page of the wizard would have for items: 1. volume ID; 2. drop-down list for selecting image format (ISO/UDF, with ISO being the default) 3. image file location (with file extension depending on selection in #2) 4. "More options" button, leading to advanced options suitable for selection made in #2. The contents of drop-down list in #2 would depend on availability of tools on user's system, so it would also be an information for user about what his system supports. Best regards, Kamil |
From: Roger <rog...@gm...> - 2013-12-27 02:09:33
|
>(I got about as far as looking at the menus, and realizing the 'Create ISO >menu' would need to be heavily modified to allow or hook-in another image >writing type.) I think the best uniform & easiest method of hooking in another filesystem image writing, is to add options within the F2 Misc Menu, adding 'Default Filesystem Image Type, ISO or UDF?' With this hook-in method, the 'Create Image' menu option can easily divert into writing the (default) image (type) with minimal editing of the existing menu code? Guess I'll go research what udftools library functions there are for writing UDF and follow-up. -- Roger http://rogerx.freeshell.org/ |
From: Roger <rog...@gm...> - 2013-12-27 01:39:27
|
For the past few months, I've experimented with UDF writing and tend to prefer UDF when compared to ISO image format. I'm really trying to read the CDW code, but not getting really far due to the massive amount of require source code reading. :-/ (I got about as far as looking at the menus, and realizing the 'Create ISO menu' would need to be heavily modified to allow or hook-in another image writing type.) Anyways, for historical reasons and those scanning the web for UDF writing instructions, here's what I do withing Bash command line with relatively good success. (Atypically as always, write first to read-write media before doing a final write to write once media.) # Burn Blu-Ray Movie using UDF Filesystem # mkudffs--udfrev= 0x0201, 0x0200, 0x0150, and 0x0102 # Omitted, mkudffs uses 0x0201, and is best for BR media or any video related # material. # Create the file container for filesystem $ truncate --size=50GB ./test.udf # Make the UDF Filesystem. ('lvid' shows within Windows as the title volume # name of the media.) $ mkudffs --lvid="Name_of_DVD-BR" --utf8 ./test.udf # Mount the container filesystem for reading & writing to $ sudo mount -oloop,rw ./test.udf /mnt/tmp/ # Make the user the owner of the sub-folders $ chown -R roger.roger /mnt/tmp/* # Ensure recursive read and write permissions are set $ chmod -R a+rX /mnt/tmp/* # Copy (cp -ax) or sync files to mounted loop filesystem $ rsync -ax --delete /Some/Files/ /mnt/tmp/ # Unmount the mounted filesystem (and maybe recheck files by remounting the # filesystem) $ sudo umount /mnt/tmp # Can't write full contents using the maximum available size Blu-ray media as # 256 MB is reserved by default for verification of files. This extra # reservation of space can be disabled for write once media, having minimal to # no neglible effects as it's likely used for read-write media. # Disable pre-formating or spare space with "use-the-force-luke=spare:none", saving 256MB # dvd+rw-format -ssa=none /dev/sr0 Or during usage of growisofs: # growisofs -use-the-force-luke=spare:none -dvd-compat -speed=4 -Z /dev/sr0=test.udf -- Roger http://rogerx.freeshell.org/ |
From: Roger <rog...@gm...> - 2013-11-13 00:25:28
|
Ditto. Well said, and don't think I can add anymore. Agree as well as keeping the tools for data orientated. Eh. Just waiting for somebody to now also complain there's too much morse code in the open, and morse code also needs to be encrypted. -- Roger http://rogerx.freeshell.org/ |
From: Kamil I. <ac...@wp...> - 2013-11-12 22:19:33
|
> I've taken time to add code to an old C project to turn it to apply to > different hardware (ie. sctl -> dsctl), so I'm quite aware of the time required > for programming in C. My biggest problem is taking time to trace the code, to > find what each function does. As in your cdw, I ran into a line of uncommented > code containing three functions. I'm a commenter at heart, and sometimes over > comment in an attempt to make code reading or tracing as easy as writing a > book. It's one thing to conquer reserving memory space when coding C, it's > another step to conquer using Structures. But even if it's written in some > scripting, I still rarely ever like retracing my own old scripting code! > > Yup. Overall, time consuming. About the only method I know of making it > easier, is to comment every line of code, to make converting code to English > (or your native language) more easier. There is a risk involved in that method: sooner or later you won't update some comment, and will end up with code saying one thing, and comment saying something else. For some critical lines of code its better to have no comment than to have a comment that is misleading (IMHO). > I would consider learning Python programming language, as I now have a faster > computer, but learned Python has severe issues within being backwards > compatibility with each major version! Due to this, I realized this is a > likely severe issue with the designing or engineering of Python, and have to > speculate as to the overall stability of future path of Python. (ie. Just > because everybody jumps off a bridge, should I too? ;-) Personally I'm torn between wanting to learn Python (supposed ease of use and elegance) and wanting to learn C++ (an ugly and powerful tool that still is in demand). Decisions, decisions... >> Tell me please - does anyone use these types of discs? Is there any real >> need for supporting them in cdw? I've got impression that optical media >> in general is slowly becoming a technology of the past, and BD/Blu-ray >> never became as popular as CDs/DVDs (at least as medium for storing data). > > So far, I see the massive amount of space Blu-ray provides as only really a > demand for people archiving video. And with this thought, video disks > minimally require udftools if they're just (legally) copying them. So I use a > few commands to perform this: > [...] > I have used Blu-ray (BD-R, BD-RE) for performing a mass system backup as well > here. I'm not a big consumer of movies, and I've never tried to add to cdw anything directly related to Video DVD. If I ever attempt to add support for new media, I think that it would be only for data storage. Using libs and tools that are available in Debian's "main" should keep me on the safe side when it comes to "legality" of Blu-ray. > My main interests are just to learn some C/NCurses with free time during > Winter, as their still likely the de-facto of coding per my previously stated > comments. One thing that I've learned from my projects is that C and ncurses are only tools, not the goals in themselves. The unixcw project required doing some code in awk, so I did it. It also forced me to learn a bit of C++/Qt4, so I did this as well. Of course I understand the need for learning a particular language or library, but it's always easier to do so (better motivation) when your pet project (or a project that is vital to you) is using said language or library. Best regards, Kamil |
From: Roger <rog...@gm...> - 2013-11-11 01:02:38
|
> On Mon, Nov 11, 2013 at 12:10:22AM +0100, Kamil Ignacak wrote: >On 07.11.2013 02:47, Roger wrote: >> Aside from dvd+rw-tools supporting BD-R/RE media, xorriso also handles BD-R/RE >> media. >> >> Here's a quick debug log from cdw, specifying xorriso to hand writing type CD media. >> >> --- Snip --- >> --- Snip --- >> >I've seen an opinion that it is easy for FOSS developers to write shiny and >easy applications, but it's harder to do the boring, grunt work that is >necessary to create a really useful piece of code. > >I'm afraid that until now cdw has suffered the same kind of problem, and >implementing proper support for DVDs was all I could take. But maybe >it's time to face the challenge :) I've taken time to add code to an old C project to turn it to apply to different hardware (ie. sctl -> dsctl), so I'm quite aware of the time required for programming in C. My biggest problem is taking time to trace the code, to find what each function does. As in your cdw, I ran into a line of uncommented code containing three functions. I'm a commenter at heart, and sometimes over comment in an attempt to make code reading or tracing as easy as writing a book. It's one thing to conquer reserving memory space when coding C, it's another step to conquer using Structures. But even if it's written in some scripting, I still rarely ever like retracing my own old scripting code! Yup. Overall, time consuming. About the only method I know of making it easier, is to comment every line of code, to make converting code to English (or your native language) more easier. For me to integrate those few definitions, it took roughly four hours, or about a day or so of tracing code. I would consider learning Python programming language, as I now have a faster computer, but learned Python has severe issues within being backwards compatibility with each major version! Due to this, I realized this is a likely severe issue with the designing or engineering of Python, and have to speculate as to the overall stability of future path of Python. (ie. Just because everybody jumps off a bridge, should I too? ;-) >Right now I'm finishing work on some other project (unixcw), and doing a >next dev cycle on another (cwdaemon). After that perhaps I would take a >look at cdw and see if - after 2 years from last release - it still >compiles :) Maybe then I could make some moves towards adding support >for DB *or* Blu-ray. > >Tell me please - does anyone use these types of discs? Is there any real >need for supporting them in cdw? I've got impression that optical media >in general is slowly becoming a technology of the past, and BD/Blu-ray >never became as popular as CDs/DVDs (at least as medium for storing data). So far, I see the massive amount of space Blu-ray provides as only really a demand for people archiving video. And with this thought, video disks minimally require udftools if they're just (legally) copying them. So I use a few commands to perform this: $ truncate --size=50GB ./test.udf $ mkudffs --lvid="MY_LEGAL_VIDEO" --utf8 ./test.udf $ sudo mount -oloop,rw ./test.udf /mnt/tmp/ $ chown -R roger.roger /mnt/tmp/* $ chmod -R a+rX /mnt/tmp/* $ rsync -ax --delete /Some/Files/ /mnt/tmp/ $ sudo umount /mnt/tmp Disable pre-formating with use-the-force-luke=spare:none, saving 256MB. (This 256MB space is used for safer or validated writing during the burn, and isn't necessary.) # dvd+rw-format -ssa=none /dev/sr0 # growisofs -use-the-force-luke=spare:none -dvd-compat -speed=4 -Z /dev/sr0=test.udf I state in the above, "legal video" as there are currently problems with Linux users being able to watch or enjoy their legally purchased Blu-ray encrypted movies or other encrypted media within Linux, as Blu-ray has no public (legal) implementation for enjoying Blu-ray Movies. Or, having something similar to libdvdcss providing encrypted DVD playback. (Too further mention, the already known Blu-ray aacs keys were recently revoked.) Due to this, I do not see Blu-ray media being as popular as DVD, as only Windows users can enjoy the Blu-ray content. To further mention, most Blu-ray content is still produced using similar bitrates as DVD content. (If you've noticed, producers have been selling DVD+Blu-ray media sets, as there are people smart enough not to invest in Blu-ray. ;-) I have used Blu-ray (BD-R, BD-RE) for performing a mass system backup as well here. (Containing pretty much all of my "/home/roger" folder, which has grown significantly since 1997.) However, I've only performed this once or twice a year. I perform more regular backups using a USB/Firewire connected hard drive, as it is much faster. Remote attached hard drives is usually the method I use when my operating system dumps or, files get lost or damaged. I use USB flash media for sporadic file transfers when traveling on foot, or once in a while I test a LiveCD on USB flash media. USB flash media is extremely unreliable in my opinion for backups, as it only takes one little bit of static electricity to almost effectively damage or erase files. I'm constantly see USB flash media here getting corrupted! I still burn live install CD/DVD ISO images for distributions, as the LiveCD optical media just works and is less tedious to do so then trying to install to USB media. In short, optical is still an extremely reliable choice. But for unknownledgeable users, they choose the quickest and cheapest method versus reliability usually. Because of the Blu-ray and/or HDMI spec fiascals, to include performance issues with their implementation, the Blu-ray method seems to be significantly frowned upon within the FOSS community. For example. For me to be able to enjoy any Blu-ray Movie for which I legally purchased, I have to first decrypt the stupid thing and make a backup copy. For which under US Law, it is legal to do so from when I was last briefed on the copyright laws awhile ago. Albeit, it's questionable and likely strongly criticized, but since I have no kids, it's not much of a issue as the unencrypted media will not go outside of this house or be shared. For those with kids, or friends who do not practice an honest lifestyle, this will be an obvious problem. I find it's a ridiculous waste of time and waste of resources, to copy the Blu-ray videos, as I've only done so with my purchased DVD Movies *only* once the DVD Movie becomes damaged! To have to un-encrypt and copy a Blu-ray Movie just to watch here is dumb. (I'm ranting here, but I'm trying to explain a sensible point of view from an ordinary consumer trying to follow the Law, while still being able to enjoy a Movie once they've paid for the product. ;-) So from this, you can see the strong will of the FOSS as well as many others, not to invest into Blu-ray media. Blu-ray media also has been compared to SVCD media, but I think Blu-ray is here to stay. Blu-ray just will not do well at all until the engineers of Blu-ray and HDMI make their products usable by honest users. HDMI is another issue, with the HDMI specifications requiring interleaved video with sound in order for it be used. In other words, a user typically cannot stream only audio over HDMI without a video signal. This is an issue with audiophiles or those wanting to save energy of not wanting their displays wasting energy. Also, many bugs are present within the HDMI coding, causing further problems with performance. In my opinion, HDMI is just another p headache and I just use S/PDIF Toslink. (S/PDIF Toslink has already been stated to have engineered HDMI quality signals, the specifications are just not yet implemented by the major hardware manufacturers.) Bottom line, I just had some free time and decided to do some code reading. Or, just didn't really feel like getting-up and doing work on the house, for which I've been a slave to for the past few years due to others not living an honest living. Eh. My main interests are just to learn some C/NCurses with free time during Winter, as their still likely the de-facto of coding per my previously stated comments. -- Roger http://rogerx.freeshell.org/ |
From: Kamil I. <ac...@wp...> - 2013-11-10 22:14:31
|
On 09.11.2013 02:13, Roger wrote: > I forgot to reference the following page for providing multiple methods of > merging the Doxygen multiple PDF files. > Hello Roger, Regarding all your e-mails about Doxygen: I've never considered the Doxygen to be useful part of the cdw source code tree, I've been using it more as a toy, a thing that is interesting to play for a while, but not to use it as a serious tool. It may have its uses as documentation for library code, but not for such application as cdw. That being said, thank you for sending me your changes. I will include them in cdw's files whenever I will get back to the project. Best regards, Kamil |
From: Kamil I. <ac...@wp...> - 2013-11-10 22:14:30
|
On 07.11.2013 02:47, Roger wrote: > Aside from dvd+rw-tools supporting BD-R/RE media, xorriso also handles BD-R/RE > media. > > Here's a quick debug log from cdw, specifying xorriso to hand writing type CD media. > > --- Snip --- > --- Snip --- > Hello Roger, Thank you for the information about BD and Blu-ray. If memory servers me well, then it wouldn't be *very* hard to add code for support of these media in cdw. If libcdio doesn't fully support them then perhaps some library from libburnia does.I'm also confident that both xorriso and dvd+rw-tools support these media as well. The hard part of the problem would be testing the new functionality added to cdw. I remember that when testing correctness of support of CDs and DVDs in cdw, I've burned literally tens of CDs and DVDs to cover as many use cases as possible: - creating ISO image and then burning the ISO image to disc; - burning files directly to disc; - creating multi-session discs; - creating single-session discs; - trying to create some error states/situations when burning CDs/DVDs; - burning with different speeds; - burning with verification; - burning with different options enabled and disabled; - a mix of the above. As I've said, I had to use tens of discs of different types to be sure that cdw can be released as useful, practical application. The cost of the discs wasn't a major issue for me. What was problematic was time needed to do the testing. I've spent many hours looking at the progress bar during the burning process. This can't be automated. This can't be sped up. Testing how 4.5 GB of data is burned to a disc, and how it is verified, is an exercise in patience. Can you imagine what it would be to test burning 25 GB of data? :D I've seen an opinion that it is easy for FOSS developers to write shiny and easy applications, but it's harder to do the boring, grunt work that is necessary to create a really useful piece of code. I'm afraid that until now cdw has suffered the same kind of problem, and implementing proper support for DVDs was all I could take. But maybe it's time to face the challenge :) Right now I'm finishing work on some other project (unixcw), and doing a next dev cycle on another (cwdaemon). After that perhaps I would take a look at cdw and see if - after 2 years from last release - it still compiles :) Maybe then I could make some moves towards adding support for DB *or* Blu-ray. Tell me please - does anyone use these types of discs? Is there any real need for supporting them in cdw? I've got impression that optical media in general is slowly becoming a technology of the past, and BD/Blu-ray never became as popular as CDs/DVDs (at least as medium for storing data). Best regards, Kamil |
From: Roger <rog...@gm...> - 2013-11-09 01:13:35
|
I forgot to reference the following page for providing multiple methods of merging the Doxygen multiple PDF files. http://stackoverflow.com/questions/4099572/how-to-get-a-single-pdf-document-from-doxygen/6889036#6889036 LaTeX -> dvips -> ps2pdf $ latex refman.tex && dvips refman.tex && ps2pdf refman.ps LaTeX -> dvipdfm $ latex refman.tex && dvipdfm (or dvipdfx?) refman.tex pdflatex (or pdftex for plain TeX) $ pdflatex refman.tex The later command being the only tool that worked error free for me after installing dev-texlive/texlive-latexextra. (Doing a search for all three different command names within Google also provides some posts stating the difference between them.) -- Roger http://rogerx.freeshell.org/ |
From: Roger <rog...@gm...> - 2013-11-09 01:01:13
|
For historical purposes, posting how to use the provided Doxyfile within the root folder of cdw for providing a one (book style) PDF file, otherwise Doxygen makes multiple HTML/PDF files. (Multiple files are a nightmare for EBooks.) REQUISITES: =app-text/texlive-2012, =dev-texlive/texlive-latexextra-2012 1) Make the following changes to the default Doxyfile within the root folder of the cdw source code. # You're install location for the Latex/PDF files, likely ./src -INPUT = /home/acerion/current/cdw/working_copy/cdw/src +INPUT = ./src # This makes Latex/PDF files -GENERATE_LATEX = NO +GENERATE_LATEX = YES # If you're within the US, else leave at default -PAPER_TYPE = a4wide +PAPER_TYPE = letter # Needed as some cdw functions are omitted. -DOT_GRAPH_MAX_NODES = 50 +DOT_GRAPH_MAX_NODES = 80 # The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the # graphs generated by dot. A depth value of 3 means that only nodes reachable 2) Run the following command from within the root folder of the cdw source code. $ doxygen Doxyfile This creates multiple HTML files by default, and with the above changes should create multiple Latex/PDF files as well. 3) Since most want a single (PDF) file for their E-Reading device, just give me one PDF file. $ cd ./doc/doxydoc/latex $ pdflatex refman.tex The command should output refman.pdf, containing all cdw created functions. Function names are hyperlinked, simpler to HTML hyperlinks. -- Roger http://rogerx.freeshell.org/ |
From: Roger <rog...@gm...> - 2013-11-08 20:30:59
|
The Doxyfile within the root folder of cdw contains a static path for your INPUT folder, when the INPUT should contain a non-absolute path for other or all users building Doxyfile. +++ Doxyfile 2013-11-08 11:23:52.066855880 -0900 @@ -581,7 +581,7 @@ # directories like "/usr/src/myproject". Separate the files or directories # with spaces. -INPUT = /home/acerion/current/cdw/working_copy/cdw/src +INPUT = ./src Might want to comment out your other static personal paths as well? -- Roger http://rogerx.freeshell.org/ |
From: Roger <rog...@gm...> - 2013-11-08 20:27:05
|
Getting errors during "doxygen Doxyfile" about too many nodes, not generating document. Doxyfile: -- DOT_GRAPH_MAX_NODES = 50 ++ DOT_GRAPH_MAX_NODES = 80 Seems to work. -- Roger http://rogerx.freeshell.org/ |
From: Roger <rog...@gm...> - 2013-11-07 01:47:55
|
Aside from dvd+rw-tools supporting BD-R/RE media, xorriso also handles BD-R/RE media. Here's a quick debug log from cdw, specifying xorriso to hand writing type CD media. --- Snip --- cdw_string_count_lines():921: INFO: returning 1 for "Getting disc info with xorriso" cdw_string_get_line_len():721: INFO: returning 30 on len < chars_max ("Getting disc info with xorriso") cdw_string_get_line_len():686: INFO: returning 0 for empty string cdw_string_count_lines_new():949: INFO: returning 1 for "Getting disc info with xorriso" cdw_string_get_line_len():721: INFO: returning 30 on len < chars_max ("Getting disc info with xorriso") cdw_string_get_line_len():686: INFO: returning 0 for empty string cdw_string_wrap():825: INFO: returning 1 lines in " Getting disc info with xorriso " cdw_drive_get_drive_fullpath():711: INFO: selecting cdio drive path 0 = "/dev/sr0" cdw_libburn_get_meta_info():80: INFO: speed #0 = 8992 -> 51 cdw_libburn_get_meta_info():80: INFO: speed #1 = 8992 -> 51 cdw_libburn_get_meta_info():97: INFO: might do tao cdw_libburn_get_meta_info():101: INFO: might do sao cdw_libburn_get_meta_info():140: INFO: disc is formatted, size of readable data: cdw_libburn_get_meta_info():149: INFO: 24438784 sectors / 47732.000000 MB cdw_drive_get_drive_fullpath():711: INFO: selecting cdio drive path 0 = "/dev/sr0" cdw_xorriso_create_command_media_info():377: INFO: xorriso command string for media info: "/usr/bin/xorriso -indev /dev/sr0 -toc " cdw_regex_caller():335: INFO: stderr: dispatching to xorriso [... repeated ...] cdw_regex_caller():335: INFO: stderr: dispatching to xorriso cdw_xorriso_handle_media_status():458: INFO: disc is written cdw_xorriso_handle_media_status():471: INFO: disc is closed cdw_regex_caller():335: INFO: stderr: dispatching to xorriso [... repeated ...] cdw_regex_caller():335: INFO: stderr: dispatching to xorriso cdw_disc_resolve_type_label():1147: INFO: disc type label 0 resolved as "unknown" cdw_disc_resolve():990: WARNING: disc in drive is of type "unknown" cdw_disc_debug_print_disc():1254: CURRENT DISC: simple type = "CD" cdw_disc_debug_print_disc():1255: CURRENT DISC: type = "unknown" (0) cdw_disc_debug_print_disc():1256: CURRENT DISC: state empty = "CDW_UNKNOWN" cdw_disc_debug_print_disc():1257: CURRENT DISC: state writable = "CDW_UNKNOWN" cdw_disc_debug_print_disc():1258: CURRENT DISC: type writable = "CDW_UNKNOWN" cdw_disc_debug_print_disc():1259: CURRENT DISC: type erasable = "CDW_UNKNOWN" cdw_disc_debug_print_disc():1262: CURRENT DISC CAPACITY: used = 0 (0.000 MB) cdw_disc_debug_print_disc():1268: CURRENT DISC: file system: = "(null)" cdw_ofs_is_iso():464: INFO: file system 0 / "none" is not ISO9660 cdw_disc_debug_print_disc():1274: CURRENT DISC: -1 write speed(s): cdw_disc_resolve_type_label():1147: INFO: disc type label 0 resolved as "unknown" cdw_disc_resolve():990: WARNING: disc in drive is of type "unknown" --- Snip --- -- Roger http://rogerx.freeshell.org/ |
From: Roger <rog...@gm...> - 2013-11-07 01:27:28
|
CD-INFO of an unformated/unused BD-R DL $ cd-info [...SNIP...] Disc mode is listed as: No information ++ WARN: error in ioctl CDROMREADTOCHDR: Input/output error cd-info: Can't get first track number. I give up. CD-INFO of a formated and used BD-RE DL (ie. BD DL Rewritable) $ cd-info [...SNIP...] Disc mode is listed as: CD-DATA (Mode 1) CD-ROM Track List (1 - 1) #: MSF LSN Type Green? Copy? 1: 00:02:00 000000 data false no 170: 00:02:00 000000 leadout (0 bytes(0 KB raw, 0 bytes0 KB formatted) Media Catalog Number (MCN): not available Last CD Session LSN: 0 __________________________________ CD Analysis Report CD-ROM with unknown filesystem -- Roger http://rogerx.freeshell.org/ |
From: Roger <rog...@gm...> - 2013-11-07 00:26:43
|
See section "Media models and profiles" http://www.gnu.org/software/libcdio/libcdio.html#models_002dprofiles -- Roger http://rogerx.freeshell.org/ |
From: Roger <rog...@gm...> - 2013-11-07 00:17:25
|
If I'm not mistaken, these are handled with dvd+rw tools. Albeit, I've only used these massive sized discs for video which required UDF for my uses around here. (And, only takes four or so bash commands to create the container and write, again using dvd+rw-tools.) As far as integrating support for BD/Blu-ray discs into cdw, I've found most of the definitions for creating BD-R/BDRE support, but am now finding cdio only still returns type CD and type DVD, and no BD type is returned using /usr/include/cdio/cd_types.h. However, I've found /usr/include/cdio/mmc_util.h does have some code for handling BD-R/BD-RE media. I'll attach the patches I have so far for historical purposes here. Stumped at simple_type_label within disc_and_drive/cdw_cdio.h & disc_and_drive/cdw_cdio.c -- Roger http://rogerx.freeshell.org/ |