pBurn 4.3.19

[zigbert]

sebus
Looking at your log, this line is interesting

Code: Select all

wodim: CUE sheet still not accepted. Please try to write in RAW (-raw96r) mode.

Would you please try to set burn mode to raw. Since burning cue, don't show the burn-options dialog, you have to set this in the exec-file: /root/.pburn/tmp/exec

After selected the cue-file, pburn shows up a confirmation-dialog before the actual burning starts. Now, Pburn has built the command, and it is time to edit the exec file:

change -dao to -raw96r

Do you have an uncommon/old burner device?


Sigmund

[sebus]

The log file also shows what device is used:

http://support.dell.com/support/edocs/s ... /specs.htm

DVD+-RW GSA-H73N

The exec does NOT get created while the dialog waits for an input! (see attached)

I can try to run cdrecord from command line, but it does not do cue with raw!

Code: Select all

# cdrecord dev=/dev/sr0 -raw96r  -v -text cuefile="/mnt/sdb1/Music/ADELE-21.cue"
wodim: The cuefile= option only works with -dao.
Usage: wodim [options] track1...trackn

Use	wodim -help
to get a list of valid options.

Use	wodim blank=help
to get a list of valid blanking options.

Use	wodim dev=b,t,l driveropts=help -checkdrive
to get a list of drive specific options.

Use	wodim dev=help
to get a list of possible SCSI transport specifiers.

An "ancient" threads with same error (but also a mention of a bug):

http://us.generation-nt.com/bug-401308- ... 07061.html

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402222

It seems that update to an ancient cdrecord is needed (at least in Fatdog64)

Cdrecord-yelling-line-to-tell-frontends-to-use-it-like-version 2.01.01a03-dvd

So I updated (compiled) cdrecord from

http://cdrecord.berlios.de/private/cdrecord.html
ftp://ftp.berlios.de/pub/cdrecord

to

Cdrecord-ProDVD-ProBD-Clone 3.00 (x86_64-unknown-linux-gnu) Copyright (C) 1995-2010 Jцrg Schilling

and can burn .cue/bin with no problems (log attached) from command line

./cdrecord dev=/dev/sr0 -dao -v -text cuefile="/mnt/sdb1/Music/ADELE-21.cue"

sebus

[otropogo]

..

....

I noticed that 2GBsd was the first entry (alphabetically) in the /sda3 partition. So I renamed /sda3/pburntmp to sda3/1pburntmp, and tried resetting it as the temp directory. This time, it took effect. Makes no sense to me but, perhaps to others...

NB: after closing and re-opening Pburn, I find that the temporary directory has defaulted back to /root/my-documents/tmp, just as it has in previous versions.

NB2: When I discover this, I try changing the temporary file from the /file/preferences menu. There, /sda3/pburntmp gives the same:

Code: Select all

selection is not a directory

message, while from the "burn" window, it's still accepted (but reverts again as soon as I close the window and reopen it - so who knows if it works?)

This sounds strange, so I gave it a test.
I can not reproduce your trouble. What type of filesystem are you working on?



Also checked that the setting is new in the burn-options dialog.


Sigmund

Ok. I tested setting temp folder to /sda3/pburn again, and got the same error message as previously.

BTW the partition is formated vfat.

I then used the folder 1pburntmp, and succeeded as before in entering it in the temp field. This time, however, I hit the save button (previously neglected), and saved the file pburn.pnb to /root.

Now, the temp file preference appears as changed after closing and reopening pburn. Of course, this still doesn't explain the previous refusals with /sda3/pburn and /sda3/pburntmp, which made getting to the save stage impossible, since the preference couldn't be entered.

A clue may exist in that, after achieving this save (or apparent save, as I haven't actually tested it with a burn), I then tried changing the preference again to /sda3/pburn, and now, for the first time ever, the entry was accepted without any error message!

I then saved, and got the warning 'pburn.pbn exists. Replace?' and chose replace. Again the preference selection survived closing and reopening pburn.

I then changed the name of /sda3/1pburntmp to /sda3/pburntmp and set the temp preference to that and saved.

Now, when I open pburn, it displays /sda3/pburntmp as the temporary folder. However, I note that BOTH the pburntmp AND pburn folders display a folder named pburn_symlink_tree.

Hope this helps.

As for the unverified burn - in retrospect, my statement that "it works" may not mean much, since I have the Puppy528.sfs file written to the hard drive, so the CD only boots the system and loads the sfs and 2fs files into memory from the hard drive.

[zigbert]

sebus
So, the answer is this; Pburn burns cue-files as long as the backend does.

[zigbert]

otropogo
I wonder if the problem is because of the VFAT filesystem.
Maybe I should change the text in the startup-check.
Isn't it so, that VFAT does NOT support links, and that will corrupt Pburns temporary storage.




Sigmund

[sebus]

sebus
So, the answer is this; Pburn burns cue-files as long as the backend does.

I do not know, but would assume yes (did the actual burn from command line, NOT using pburn).

Maybe there should be some version check, otherwise you are fighting something that is not your problem...

And at what point the exec gets actually built?

sebus

[otropogo]

otropogo
I wonder if the problem is because of the VFAT filesystem.
Maybe I should change the text in the startup-check.
Isn't it so, that VFAT does NOT support links, and that will corrupt Pburns temporary storage.




Sigmund

I know nothing about vfat and symlinks, but let's not jump to conclusions.

I ran some more tests just now, and now that I've got the temp directory set (albeit via a Byzantine route) to the vfat directory, it seems to work fine. So there's a flaw it the setting mechanism, not in vfat's ability recognize the link.

OTOH, I ran into another bothersome issue. Namely, Pburn 3.5 will not allow anything but SR0 to be used to blank a disc.

I discovered this because my sr0 has been performing a bit unreliably for booting Puppy lately (once puppy is running, it seems to work just fine, except for the error message I posted above). So I've been using sr1 to boot. Since I wanted to avoid any possible side issues, such as a problem with the burner, I tried to test the use of the temporary storage function with the latter, sr1.

However, over repeated attempts, Pburn popped up:

Please insert disc if disk is already in the tray please reload it

drive: /dev/sr0

I ejected and reloaded the sr1 tray several times with the same result, and looked for a way to set the burner device for this function, but couldn't find any. In the end, I had to admit defeat and use sr0 to blank the disc.

Happily, that worked. But had my sr0 burner been unable to blank the disk, then circumventing this limitation would have required shutting down the system, opening the case, disconnecting the power connector to sr0 or switching the data cables, and then rebooting, all just to change the designation of sr1 to sr0.

I would urge you to fix this in the next version.

Another issue I discovered along the way is that if one forgets to blank a target disk before starting the burn using temporary storage, there is no way to blank the disk without aborting the entire process. It would be nice (especially when large ISOs in the GB range are involved) to have the option to save the iso already copied to the temporary folder, so one doesn't have to copy the entire disk again after blanking the target disk.

I'm sure many would appreciate that convenience too.

After blanking the CD-RW successfully, I placed the source disk (again, my lupu5.2.8 LiveCD) in sr1, and started the data disc copy process using temporary storage, which pburn showed as /sda3/pburntmp, just as I had saved it during my previous Puppy session. The data was written uneventfully, I replaced the source disc with the blanked one as prompted, and the burn started and completed uneventfully also.

While the burn was in progress, I opened the /sda3/pburntmp folder, and noted the iso file of 130MB displayed there. When the burn was finished, there was an option to save the iso.

However, there was no option to verify the burn, which I consider very desirable.

I then rebooted with the copied disc, and am using it right now.

Finally, I would reiterate my frustration at having to redesignate the entire path and filename to the folder where I want my burn logs to go every time I save a log, even during the same pburn session.

I've been unable to find any way to set the folder. Every time I want to save a burn log, the same path to a folder in the root directory pops up, and I have to navigate to the partition and folder I want, then type or edit the log name. It seems such a needless waste of time and energy...

So to recap, as far as I can determine:

1.One CAN successfully set the temporary burn folder in a vfat partition, but it may require the use of the first folder (alpha-numerically) in that partition. Once that's done, the folder can be renamed. This is the only way I've been able to do it.

2. It's impossible to blank a CD or DVD using sr1, as pburn 3.5 only looks at sr0 for this task.

3. There's no option to verify a copy of a data disc in pburn 3.5

4. There's no way to save one's own preference of destination folder for burn logs in pburn 3.5, even temporarily (ie. for the existing session)

5. There's no way to choose and save a naming format for burn logs in 3.5, so that sequential logs are not overwritten.

[sebus]

Code: Select all

else #let Pburn define burn engine. cdrtools is prefered if both is present.
	export CDRECORD="wodim"; export CDDA2WAV="icedax"; export MKISOFS="genisoimage"
	if which cdrecord > /dev/null 2>&1; then export CDRECORD="cdrecord"; export CDDA2WAV="cdda2wav"; export MKISOFS="mkisofs"; fi

wodim comes from http://www.cdrkit.org/

Is Pburn relying ONLY on its command line?

cdrkit, will retain a user interface compatible with the corresponding programs from the cdrtools 2.01.01a08 release, at least for the near future

cdrtools-3.0 from http://cdrecord.berlios.de/private/cdrecord.html

might (I have no checked deeply) some/many differences

Will Pburn be able to deal with it?

sebus

[zigbert]

1.One CAN successfully set the temporary burn folder in a vfat partition, but it may require the use of the first folder (alpha-numerically) in that partition. Once that's done, the folder can be renamed. This is the only way I've been able to do it.

At the moment, I have nothing more to come up with at this topic.

2. It's impossible to blank a CD or DVD using sr1, as pburn 3.5 only looks at sr0 for this task.

You can choose burner device in the burn-option dialog or permanent in the preferences

3. There's no option to verify a copy of a data disc in pburn 3.5

It is not possible (as far as I know) to verify when burning multisession. You have to choose to close the disc to get the verify option in the finish dialog..... more in help file.

4. There's no way to save one's own preference of destination folder for burn logs in pburn 3.5, even temporarily (ie. for the existing session)

true

5. There's no way to choose and save a naming format for burn logs in 3.5, so that sequential logs are not overwritten.

true

[zigbert]

might (I have no checked deeply) some/many differences

Will Pburn be able to deal with it?

I have no idea.
My target is to develop Pburn on the latest official Puppy. I am not the one to decide what burning engine Puppy will provide. On the other hand, I am not unwilling to improve the code to become as good as possible. Many of the latest bugfixes are related to other distros, and are reported/fixed by other. I have just secured the patches from a Puppy-view.

When it comes to cue-burning, I have never used it. Only added the support, because it is documented in the cdrecord manual. wodim is supposed to be compatible, but has not been maintained well.
If you find cdrecord to work for cue-burning, I can add a message about this in the burning dialog (if wodim is the existing engine).


Thank you
Sigmund

[zigbert]

And at what point the exec gets actually built?

I just took it for granted that the command was built before the dialog shows up. But the cue burning is not following the standard Pburn-infrastructure. If interested, the code is placed in /usr/local/func_toc_cue. Line 56 builds the burning command.

If the command can be executed in terminal, there should be no reason why Pburn shouldn't work with it. After all, that is the only thing Pburn is doing; - Building a command for execution.


Sigmund

[sebus]

My target is to develop Pburn on the latest official Puppy. I am not the one to decide what burning engine Puppy will provide.

Sigmund

But the default burning engine is awfully old & buggy

I think it would be better to add an option to select what burning engine to use (so user at least can opt for a new engine)

sebus

[zigbert]

I think it would be better to add an option to select what burning engine to use (so user at least can opt for a new engine)

Please specify. If you install cdrtools, Pburn will prefer this. Also possible to override this with the pburn -g parameter.

I am sure Barry/Mick will consider cdrtools as the default choice if we can point to obvious weaknesses in cdrkit.

I have noted issues related to engine choice, the list is not long:
- Wodim will not burn from cue-files while cdrecord does. (today )
- Burn iso gives wrong md5sum when using wodim. (I doubt this, since this topic hasn't been up for the last 2 years)
- cdrecord won't connect to cddb for cdtext information, while wodim works. (today feecddb.org is down, so it won't work for any, else the cddb server setting has been changed)

[Jades]

I humbly submit the following addition to the Potential Pitfalls section:-

Pay close attention to the minimum and maximum writing speeds of your media, and compare them with the maximum writing speeds of your drive. Writing to media with a minimum speed setting higher than your drive is capable of will result in failure - for example, attempting to write to a 4x-10x CDRW on a drive with a maximum RW speed of 2x. This is most likely to be an issue when using new discs in an old system.

Added. Thanks a lot. I have never thought of this, but it is sure obvious.

To be fair, it's something that's only obvious if you encounter it yourself. Even then it took me a little while and careful inspection of the media's packaging and the drive specs to figure it out. The majority of writers available these days will write pretty much anything, and I suspect that most people using Puppy aren't likely to be using setup as ancient as my retrogaming machine. Writer's a Sony CRX-100E, it's in a circa 1999 Time 300 Series, with a K6-2 500 CPU. I doubt the writer is that much younger than the computer...

The PC I'm typing this on is considerably more modern. It has a Pentium D 3.4GHz CPU, and the writer is a Lite-On SHM-165P6S, which was released in early 2006 and writes pretty much all CDs and DVDs. It had been gathering dust in a cupboard for about four years as it wasn't compatible with the system we bought it for. I finally dug it out and installed it after this machine started to develop serious hard drive problems. Funny how backing up can suddenly rise to the top of the agenda, without Puppy (LiveCD with pupsave on USB stick) and Pburn it would be unlikely I would have managed to salvage much.

[sebus]

... it would be unlikely I would have managed to salvage much.

Ofcourse you could just copy it to remote machine via network, or to a local USB stick...

sebus

[otropogo]

...

2. It's impossible to blank a CD or DVD using sr1, as pburn 3.5 only looks at sr0 for this task.

You can choose burner device in the burn-option dialog or permanent in the preferences

Ok. That works, thanks.

3. There's no option to verify a copy of a data disc in pburn 3.5

It is not possible (as far as I know) to verify when burning multisession. You have to choose to close the disc to get the verify option in the finish dialog..... more in help file.

Nope. I wasn't burning an iso, but "copying a data disk". So far as I know, there was no option to burn multisession, and indeed the original disk I copied wasn't multisession either. Nor do I recall an option to "close the disk".

[zigbert]

Nope. I wasn't burning an iso, but "copying a data disk". So far as I know, there was no option to burn multisession, and indeed the original disk I copied wasn't multisession either. Nor do I recall an option to "close the disk".

I'll check, thank you
Sigmund

[Jades]

... it would be unlikely I would have managed to salvage much.

Ofcourse you could just copy it to remote machine via network, or to a local USB stick...

That assumes that I have a remote machine or a USB stick with enough spare capacity to receive the data, and in the case of the former that the network connection is reliable enough for backup purposes (it probably isn't).

The truly mission-critical stuff had been copied to other machines ages ago, the stuff I ended up burning to disc was more in the category "would be nice to salvage" or were save files from games. Pburn came in handy very after XP wouldn't boot at all.

[zigbert]

Version 3.5.1
See main post

Changelog
- Verify copied data-disc. (thanks to otropogo)
- If more than 1 device is detected, show startup-check window. (thanks to Jades)
- Choose temporary-storage-directory is now more flexible. (thanks to sebus)
- Set a unique date/time tag to default logfile name. (thanks to otropogo)
- Do not show terminal pre-operation window if ffmpeg is NOT in command.
- Open support of xterm as an alternative terminal to rxvt. (thanks to big_bass)
- Accept netsurf, midori, chrome, iron as alternative html viewers.
- NLS: Removed: LOC317
- NLS: Helpfile: New item in chapter 4, potentional pitfalls. (thanks to Jades)

[zigbert]

item 2 involves 2 optical devices, which I don't have...... untested.

item 1 partly involves 2 optical devices....