[cdvdburn] Re: CDBurn/RO 4.39 issue

  • From: dave higton <davehigton@xxxxxxxxxxxxx>
  • To: cdvdburn@xxxxxxxxxxxxx
  • Date: Fri, 23 Mar 2012 14:07:39 +0000

Quoting lists <Stuartlists@xxxxxxxxxxxxxxxxxxxxx>:

> I've not seen any traffic on this list for a long time so I hope it's
> still active. (Also posted to c.s.a.apps)
> It's been a long time since I attempted burning any CDs as I now have a
> NAS and do all my back-ups to it. However, it occurred to me the other
> day, that it might be a good idea to have some back-ups stored away from
> the house (I always used to keep a set at work when I was working).
> My first thought was to burn on my PC (quicker) but it looses some of the
> RO file-types in the process, (no surprise there) so I decide to do the
> job directly. 
> I sorted out some files and commenced preparing an Isoimage. It seemed to
> be getting on with the job quite happily when, suddenly, all the windows
> closed, it disappeared off the icon bar and left an undeletable open file.
> I shut down the computer and, after a re-start, attempted the procedure
> again with the same result. I tried different sets of files and each time
> the result was the same.
> The above was all on my Kinetic running RO4.39
> Using my older RPC, which doesn't have a burner fitted and is at 4.37, the
> procedure worked quite satisfactorily and an Isoimage was produced. I have
> not yet had the time to transfer the image to my Kinetic to try burning it
> but I was wondering if there are known issues.
> Both machines have CDBurn 1.61.
> I realise I can upgrade to CDVDBurn but for the occasional burn like this,
> being a mean old sod, (It's also /that/ time of the year) I would rather
> not unless I have to and can be sure that it would work properly if I did.

If it's any help, I have used a recent (probably experimental, I can't
remember) of CDVDBurn to create a DVD on a BeagleBoard with external USB
DVD writer.  It was very slow (Steffen says it only works at x1), but it
did run to completion, and the result was readable.

Another option may be to use SparkFS without compression.  I haven't
tried this myself - I intend to do so soon - but I believe that the file
types will be preserved.  You should also be able to do it with compression,
but (a) for lots of files it might well take a long time; (b) there seems
to be a possible failure mechanism because of the time involved.  I don't
understand nearly enough about that yet.  I favour the experimental route:
try it; if it works for you, go with it :-)

The basic point being that SparkFS will retain the RISC OS filetypes.


Other related posts: