pBurn 4.3.19
Greetings zigbert -- Hope your holidays are merry!
I recently ran into a big problem (for me) with pBurn I am using pburn version 3.4.2 running on Puppy Lucid.
The problem manifested itself when trying to burn to a bluray disc. After selecting all the files to burn and hitting the burn gadget, the splashbox ("checking media..." and "building burn command..." messages) would appear and would not go away I could see that the main pBurn GUI would update, but nothing else happens after this.
After some intense debugging contortions, I isolated the issue to the func_burn_options file at line 170 where you are checking the media disc space and just entered the case statement. I believe you are using the MKISOFS command to get a target size, but this command fails if a selected file is greater than 4Gb! Simply adding some udf options to MKISOFS will let it work for those large files!
I came up with a potential solution by adding a simple if test and another variable to be used in the MKISOFS command:
<OLD CODE BEGIN>
case $MEDIASIZE_FREE in *[0-9]*)
TMP="`$MKISOFS -iso-level 3 -D -R -J -joliet-long --print-size -exclude-list $WORKDIR/exclude -graft-points -path-list=$WORKDIR/graft_points | tail -n 1`"
ISOSIZE=$(($TMP*2048))
<OLD CODE END>
<NEW CODE BEGIN>
case $MEDIASIZE_FREE in *[0-9]*)
# 111227 EdV: need options to handle filesizes -gt 4Gb!
if [ "$UDF" = "true" ]; then
UDF_OPTS="-udf -allow-limited-size"
else
UDF_OPTS=""
fi
TMP="`$MKISOFS -iso-level 3 -D -R -J -joliet-long $UDF_OPTS --print-size -exclude-list $WORKDIR/exclude -graft-points -path-list=$WORKDIR/graft_points | tail -n 1`"
ISOSIZE=$(($TMP*2048))
<NEW CODE END>
This worked great and I was able to burn my bluray disc
Unfortunately, this solution only works if you select the udf filesystem before one tries to burn any selected files! If you do not select the udf filesystem and try to burn with any file greater than 4Gb -- pBurn will hang.
To avoid the problem without the udf filesystem being selected, I am thinking that maybe a check needs to be performed when files are selected to burn which checks filesize and if greater than 4Gb without udf selected, a warning message comes up. This has to happen before one hits the burn gadget or it will be too late and pBurn will lock up. I do not have a solution for this yet, but maybe you can figure one out before I can even guess where you collect filesizes during the add file process...
As always, thanks for a great script!
EdV
I recently ran into a big problem (for me) with pBurn I am using pburn version 3.4.2 running on Puppy Lucid.
The problem manifested itself when trying to burn to a bluray disc. After selecting all the files to burn and hitting the burn gadget, the splashbox ("checking media..." and "building burn command..." messages) would appear and would not go away I could see that the main pBurn GUI would update, but nothing else happens after this.
After some intense debugging contortions, I isolated the issue to the func_burn_options file at line 170 where you are checking the media disc space and just entered the case statement. I believe you are using the MKISOFS command to get a target size, but this command fails if a selected file is greater than 4Gb! Simply adding some udf options to MKISOFS will let it work for those large files!
I came up with a potential solution by adding a simple if test and another variable to be used in the MKISOFS command:
<OLD CODE BEGIN>
case $MEDIASIZE_FREE in *[0-9]*)
TMP="`$MKISOFS -iso-level 3 -D -R -J -joliet-long --print-size -exclude-list $WORKDIR/exclude -graft-points -path-list=$WORKDIR/graft_points | tail -n 1`"
ISOSIZE=$(($TMP*2048))
<OLD CODE END>
<NEW CODE BEGIN>
case $MEDIASIZE_FREE in *[0-9]*)
# 111227 EdV: need options to handle filesizes -gt 4Gb!
if [ "$UDF" = "true" ]; then
UDF_OPTS="-udf -allow-limited-size"
else
UDF_OPTS=""
fi
TMP="`$MKISOFS -iso-level 3 -D -R -J -joliet-long $UDF_OPTS --print-size -exclude-list $WORKDIR/exclude -graft-points -path-list=$WORKDIR/graft_points | tail -n 1`"
ISOSIZE=$(($TMP*2048))
<NEW CODE END>
This worked great and I was able to burn my bluray disc
Unfortunately, this solution only works if you select the udf filesystem before one tries to burn any selected files! If you do not select the udf filesystem and try to burn with any file greater than 4Gb -- pBurn will hang.
To avoid the problem without the udf filesystem being selected, I am thinking that maybe a check needs to be performed when files are selected to burn which checks filesize and if greater than 4Gb without udf selected, a warning message comes up. This has to happen before one hits the burn gadget or it will be too late and pBurn will lock up. I do not have a solution for this yet, but maybe you can figure one out before I can even guess where you collect filesizes during the add file process...
As always, thanks for a great script!
EdV
Ripping with PBurn
I saw this
Thanks in advance for insights or guidance
Does this mean that PBurn is lacking richness in the "Ripping" ability. Even though I own many CDs, I have never copied them for storage. But, last week, I had my first Music CD get destroyed. (maybe now is a good time for me to begin media storage, huh...)... It includes ripping functionality similar to that of Asunder ...
Thanks in advance for insights or guidance
Re: Ripping with PBurn
The answer is Yes and No. Let me explain...gcmartin wrote:Does this mean that PBurn is lacking richness in the "Ripping" ability.
Pburn supports copying of Audio-CDs (including CD-text), which requires to rip the CD before actually writing the content to a new disc. But Pburn lacks the ability to store/convert the ripped wav-files to your local harddrive.
Then the next question is obvious... Why not just let the user get the option to use Pburn as a ripper when the feature is already there? Let me explain...
Once upon a time there was this app called Nero. It was a brilliant tool for all kinds of burning. Many loved it, and they earned of course a lot of money on selling it. At next stage they would like to sell it even more, so they found it smart to include new stuff that people couldn't resist; - and wanted to buy a newer version of this brilliant product. After some releases including new extended features, things started to change. People found Nero a bit complex (and big), and it opened the market for other simpler products....
Pburn has not the intention to step into the Nero-trap. As Nero, Pburn are not meant to offer features for
- Album-cover design.
- Audio-CD and DVD-Video ripping (different from copying)
- Video editing
We have other apps that do these things very well, and I do not see any reason for making Pburn even more complex.
When it comes to SimpleBurn, it looks promising, and maybe one day we don't need Pburn anymore. But as is today I find it a bit poorly conceived when iguleder states:
- It is smaller than Pburn, about half the size.
Without comparing the actual features and the size of the unique dependencies, this statement isn't impressive.
- It's a compiled application, not a script. This makes it way faster.
This is a statement also used by jemimah and other, and it is fair to use, but for utilities like Pburn, 1.) Speed doesn't matter that much. 2.) The actual writing-to-disc is the main speed-issue, and it will NOT be faster with SimpleBurn just because it is compiled.
- It includes ripping functionality similar to that of Asunder.
TRUE!
I hope it won't include too many extended features if SimpleBurn is meant to be ..... simple.
Sigmund
I've been burning off a set of MP3s and come across the following problems. One which may be to do with the MP3 decoder or/and corrupt MP3 files. The second may be able to be fixed in PBurn.
1) MP3 file incorrect lengths - for example in PBurn and PMusic the first MP3 is loaded as 6.06 minutes when it is actually 4.00. Gnome-player shows it as 9.09, mhWaveEdit shows it correctly at 4.00. (With k3b I am yet to be able to load MP3). All the MP3 file in the collection are loaded as being longer than they actually are. There is a header error generated - so the information may be missing in the files.
2) CD drive takes a long time to OPC - I converted the MP3s to WAV. k3b can successfully burn these file as it waits a long time for the drive to be ready - burning kicks in after about 2mins on the OPC (Optimum Power Calibration). PBurn quits after 1min of OPC reporting an error with the CD drive (sr0).
1) MP3 file incorrect lengths - for example in PBurn and PMusic the first MP3 is loaded as 6.06 minutes when it is actually 4.00. Gnome-player shows it as 9.09, mhWaveEdit shows it correctly at 4.00. (With k3b I am yet to be able to load MP3). All the MP3 file in the collection are loaded as being longer than they actually are. There is a header error generated - so the information may be missing in the files.
2) CD drive takes a long time to OPC - I converted the MP3s to WAV. k3b can successfully burn these file as it waits a long time for the drive to be ready - burning kicks in after about 2mins on the OPC (Optimum Power Calibration). PBurn quits after 1min of OPC reporting an error with the CD drive (sr0).
edV
Please check 3.4.3 and report back
Sigmund
Please check 3.4.3 and report back
Sigmund
Last edited by zigbert on Sun 01 Jan 2012, 10:25, edited 1 time in total.
darkcity
For you issue nr. 1, you could try to convert mp3-files with ffmpeg -sameq. This will keep the same quality settings as the original file. If this helps, a mass-convert of all files should be possible.
When is comes to your burning issue (OPC), it would be very informative to compare the burning command used by K3b and Pburn. In Pburn this is shown in the advanced tab in the burn-option dialog. I don't know K3b, but there is for sure a log-file..... If you have K3b available, please make a similar dummy-burn on both K3b and Pburn.
Thank you
Sigmund
For you issue nr. 1, you could try to convert mp3-files with ffmpeg -sameq. This will keep the same quality settings as the original file. If this helps, a mass-convert of all files should be possible.
When is comes to your burning issue (OPC), it would be very informative to compare the burning command used by K3b and Pburn. In Pburn this is shown in the advanced tab in the burn-option dialog. I don't know K3b, but there is for sure a log-file..... If you have K3b available, please make a similar dummy-burn on both K3b and Pburn.
Thank you
Sigmund
good news, I have got pburn to work with my drive. after comparing the commands, I changed to pburn options to dao (disc-at-once) and added in gracetime=2. not sure which change made it work. -will report back if I have more burning to do
pburn unsucessful command-
pburn successful command:
(added log files are to be 'opened as text' - .gz extension just so forum would let me upload)
pburn unsucessful command-
k3b successful command-cdrecord -v dev=/dev/sr0 driveropts=burnfree -pad -tao /mnt/home/hddoc2/tempBurn/pburn_tmp/*_pburn.wav
Code: Select all
/usr/bin/wodim -v gracetime=2 dev=/dev/sr0 speed=52 -dao driveropts=burnfree textfile=/tmp/k3bMNGgOa.dat -eject fs=4m -useinfo -audio /mnt/home/hddoc2/tempBurn/k3b_audio_0_01.inf /mnt/home/hddoc2/tempBurn/k3b_audio_0_02.inf /mnt/home/hddoc2/tempBurn/k3b_audio_0_03.inf /mnt/home/hddoc2/tempBurn/k3b_audio_0_04.inf /mnt/home/hddoc2/tempBurn/k3b_audio_0_05.inf /mnt/home/hddoc2/tempBurn/k3b_audio_0_06.inf /mnt/home/hddoc2/tempBurn/k3b_audio_0_07.inf /mnt/home/hddoc2/tempBurn/k3b_audio_0_08.inf /mnt/home/hddoc2/tempBurn/k3b_audio_0_09.inf /mnt/home/hddoc2/tempBurn/k3b_audio_0_10.inf /mnt/home/hddoc2/tempBurn/k3b_audio_0_11.inf /mnt/home/hddoc2/tempBurn/k3b_audio_0_12.inf /mnt/home/hddoc2/tempBurn/k3b_audio_0_13.inf
Code: Select all
cdrecord -v gracetime=2 dev=/dev/sr0 driveropts=burnfree -pad -dao /mnt/home/hddoc2/tempBurn/pburn_tmp/*_pburn.wav
- Attachments
-
- Pburn-tao.gz
- (100.19 KiB) Downloaded 196 times
-
- k3b-log-debug.gz
- (33.23 KiB) Downloaded 463 times
-
- Pburn-dao-grace2.gz
- (128.05 KiB) Downloaded 321 times
Greetings sigbert!
Your fixes in 3.4.3 work for the >4Gb issue!
I was able to "over-write" a BD-RE disc with no problems associated with >4Gb files! However, I was unable to successfully "blank" the BD-RE udf data -- pburn went through the motions, but the udf information was still there. I will have to look into this later (I am guessing we are missing a udf switch on the command).
I must admit that I am not a big fan of the >4Gb solution, although it is clear that it is simple and has minimal impact to the program. The current solution simply turns on the UDf filesystem options without warning the user what has happened. I am more of a geek and want to know what is happening with my equipment and software
I reworked your solution to add a requestor if the proper conditions exist and ask the user if they want to turn on the UDF filesystem or back out to change the selected files listing. I used Xdialog for the requestor because it was easy for me, but I suspect you could use one of your box functions to create the same effect. I present this code for your amusement as I know it is a problem for localization and therefore not a good option...
<Begin Old Code in func_burn_options approx line 167>
#Check for huge files (over 4Gb) that requires udf switch on
if [ $UDF = true ] || [ "`find -L "$TMPDIR" -size +4G`" ]; then
UDF_OPTS="-udf -allow-limited-size" #for next check
UDF=true #activate checkbox if large file is detected
fi
<End Old Code>
<Begin Amusement Code in func_burn_options approx line 167>
#120102 EdV: I prefer a notice instead of just doing it....
if [ "`find -L "$TMPDIR" -size +4G`" -a "$UDF" != "true" ]; then
echo 100 > $WORKDIR/splash #splash is running
Xdialog --screencenter --title "Pburn" --ok-label "Enable UDF" --cancel-label "Go Back" --yesno "WARNING: Burning files greater than 4Gb in size\n is only supported with the UDF filesystem!" 0x0
[ $? -ne 0 ] && exit
UDF="true"
fi
[ "$UDF" = "true" ] && UDF_OPTS="-udf -allow-limited-size"
<End Amusement Code>
EdV
Your fixes in 3.4.3 work for the >4Gb issue!
I was able to "over-write" a BD-RE disc with no problems associated with >4Gb files! However, I was unable to successfully "blank" the BD-RE udf data -- pburn went through the motions, but the udf information was still there. I will have to look into this later (I am guessing we are missing a udf switch on the command).
I must admit that I am not a big fan of the >4Gb solution, although it is clear that it is simple and has minimal impact to the program. The current solution simply turns on the UDf filesystem options without warning the user what has happened. I am more of a geek and want to know what is happening with my equipment and software
I reworked your solution to add a requestor if the proper conditions exist and ask the user if they want to turn on the UDF filesystem or back out to change the selected files listing. I used Xdialog for the requestor because it was easy for me, but I suspect you could use one of your box functions to create the same effect. I present this code for your amusement as I know it is a problem for localization and therefore not a good option...
<Begin Old Code in func_burn_options approx line 167>
#Check for huge files (over 4Gb) that requires udf switch on
if [ $UDF = true ] || [ "`find -L "$TMPDIR" -size +4G`" ]; then
UDF_OPTS="-udf -allow-limited-size" #for next check
UDF=true #activate checkbox if large file is detected
fi
<End Old Code>
<Begin Amusement Code in func_burn_options approx line 167>
#120102 EdV: I prefer a notice instead of just doing it....
if [ "`find -L "$TMPDIR" -size +4G`" -a "$UDF" != "true" ]; then
echo 100 > $WORKDIR/splash #splash is running
Xdialog --screencenter --title "Pburn" --ok-label "Enable UDF" --cancel-label "Go Back" --yesno "WARNING: Burning files greater than 4Gb in size\n is only supported with the UDF filesystem!" 0x0
[ $? -ne 0 ] && exit
UDF="true"
fi
[ "$UDF" = "true" ] && UDF_OPTS="-udf -allow-limited-size"
<End Amusement Code>
EdV
Thank you for the report.Stripe wrote:hi all
@zigbert just ripped a 7500mb dvd shrunk it and then burned it to a single layer dvd (about 4400mb) without any issues, top quality sound and vision.
this was in 3.4.2 (slacko main) will upgrade to 3.4.3 and report back
cheers
Don
It is good to hear when things works, not only when something fails.
Sigmund
Please report on this. There is no problem for me to add the gracetime option (I think). If it DAO that makes the difference, it should be noted in the docs/info/messages....darkcity wrote:good news, I have got pburn to work with my drive. after comparing the commands, I changed to pburn options to dao (disc-at-once) and added in gracetime=2. not sure which change made it work. -will report back if I have more burning to do
Thanks
Sigmund
Hi all. Can anyone tell me does pburn do a correct verification when the data files for the DVD are in the "home" directory, as during a frugal install? It gives an instant verification OK when it obviously hasn't done the check at all.
No problems when running from a live USB though. And it never actually does seem to give any errors.
Thanks!
No problems when running from a live USB though. And it never actually does seem to give any errors.
Thanks!
I am sure PBurn does this,but, I need a little guidance
I have 2 DVD drives on my PC.
I have a Puppy Live media system with its save sessions on the DVD in one of the drives.
I have a Puppy Live media system with its save sessions on the DVD in one of the drives.
- Assuming I have media in one drive and a blank DVD in the other, Can I replicate the contents from one DVD drive "directly" to the other?
- What steps would you recommend in using the PBurn product to replicate?
Does "Burn>Copy Data Disc>On the fly" (in Pburn) not work?
Do you know a good gtkdialog program? Please post a link here
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
The message wouldn't hurt the "newbie", would it?zigbert wrote:Edv
Thank you for your initiative.
I first made a message 'UDF is turned on', but removed it afterwards..... pro and cons..... should we accommodate the neewbie or the geek ??
Do you know a good gtkdialog program? Please post a link here
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
Yes, I tried this using the 2 DVD writers on the system.disciple wrote:Does "Burn>Copy Data Disc>On the fly" (in Pburn) not work?
Results:
I used Puppy 5.28 Upate 3 with Pburn 3.41
Followed the directions to copy a multisession DVD-RW with Lighthouse64 and its save-session to a new DVD-R .
In one I placed the DVD to copy and the other, I place a new, blank DVD-R. The DVD to copy is a multi-session Live media DVD-RW with 2 save sessions on the media.
The process ran thru with progress on a MB basis until it reached last MB and began fixating.
This ended with a failure message from PBURN. The result was a new media that PBURN would NOT identify on subsequent restarts showing ONLY RED at the bottom PBurn screen for the DVD media in the drive.
I asked the question here as I'm sure others may have seen the same thing at some point and maybe found a resolution to copy a multi-session data media, directly, one to the other. Maybe some other PBurn options are known to work in this mode.
If there is something more I can provide for resolution, I will follow any request(s).
Thanks in advance for assistance to resolution.
Did you uncheck the "finalise" option? (Actually, I don't have Puppy here, and am not 100% sure if the finalise option is available when copying a disk...)
Do you know a good gtkdialog program? Please post a link here
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER
Classic Puppy quotes
ROOT FOREVER
GTK2 FOREVER