I've been looking at a way of easily ordering tracks for audio CD's
This is what I've come up with so far...

When audio CD is selected :-
Added tracks are indexed and added to the end of the list thus preserving order.
Tracks can be moved up and down.
Removing tracks preserves the order of the remainder.
For convenience when switching to 'audio' any files already added are indexed.
The indexing method matches the system used when importing a playlist.

The attachement is a hacked down version of pburn I use for trying out ideas but the system of indexing should integrate with the latest version if deemed suitable.
Changes are in 'func' with additional buttons in 'pburn'.

Hi Mike
Thanks for your input. It will be in the next 1.4.0.
I reorganized it a bit. Your function 'index_list' is now called from 'build_burn_list'. Like this we don't need any changes in
'-add_selection'
'-add_all'
'-burnlist_remove'
Also no extra trouble integrating it with the search engine.

The annoying thing is that after moved song up/down, variable $BURNLIST is empty, and I have to select song again to move futher.

I reorganized it a bit. Your function 'index_list' is now called from 'build_burn_list'. Like this we don't need any changes in
'-add_selection'
'-add_all'
'-burnlist_remove'
Also no extra trouble integrating it with the search engine.

This is why 2 heads are often better than one good thinking...cheers for posting the changes I look forward to having a look. Glad you liked the idea.

Quote:

The annoying thing is that after moved song up/down, variable $BURNLIST is empty, and I have to select song again to move futher.

Yes i know...I am a bit hazy on how to solve that one or is it a gtkdialog limitation?

In the demo I sent you I modded the temporary directory function to call gtkdialog fileselect directly so simplifying box_chooser...which in itself I added a box to input a filename for saving..might be handy.
Also added ability to open from a .pbn file (eg with rox mime type) though this would need refining to integrate with other opening options.

Another idea which occured to me was to be able to distinguish between an audio and data .pbn file so the appropriate mode would be selected when opening.
I was thinking in terms of including a file called '.data' in the pburn folder which is removed for audio compilations....would be insignificant for a data burn and not present to cause a problem for audio if you see what I mean.

Ok off to play with the greatest and smallest burning utility in thee world

In the demo I sent you I modded the temporary directory function to call gtkdialog fileselect directly so simplifying box_chooser...which in itself I added a box to input a filename for saving..might be handy.

This is correct, and the logic way to do it, as long as you don't have language support. Also <button cancel></button> shows a prebuild button, but it can't view label 'Avslutt', - as we cancel in Norway.

Quote:

Also added ability to open from a .pbn file (eg with rox mime type) though this would need refining to integrate with other opening options.

In 1.3.0 you can open Pburn with a *.pbn file with 'pburn /path/file.pbn'

Quote:

Another idea which occured to me was to be able to distinguish between an audio and data .pbn file so the appropriate mode would be selected when opening.
I was thinking in terms of including a file called '.data' in the pburn folder which is removed for audio compilations....would be insignificant for a data burn and not present to cause a problem for audio if you see what I mean.

A .data file will be visible in the burnlist , and must be removed while *.pbn opens. Still I personally feel that the 'import playlist' is most logical way to handle this. I use Picker for this purpose. BUT indeed, I'm not the negative guy. Enhanced *.pbn detection - ok with me.

Quote:

Ok off to play with the greatest and smallest burning utility in thee world Smile

This is correct, and the logic way to do it, as long as you don't have language support. Also <button cancel></button> shows a prebuild button, but it can't view label 'Avslutt', - as we cancel in Norway.

I understand..or at least I do in english .How about the enter filename in save box?

Quote:

In 1.3.0 you can open Pburn with a *.pbn file with 'pburn /path/file.pbn'

You are definately light years ahead

Quote:

A .data file will be visible in the burnlist , and must be removed while *.pbn opens.

Been playing with this.
I added '| grep -v .data' in build_burn_list for that but the main problem is that if a file is opened after pburn is launched there seems to be no way to update the radio buttons...would mean an alternative mode selection method...buttons and info box.
Apart from that perhaps a better way would be to use the filename eg
compilation_aud.pbn / compilation_dat.pbn....or *.pba / *.pbd nero style.

By the way well done for interpreting my posts...even I have to read them twice

Hi, I think there is a minor bug in pburn. When I close pburn using the "Χ" (window top right), and then run ps, pburn is still in the running processes.
If I close it through File->Quit, the pburn process is terminated correctly.

1.
Left-click on my directory '/puppy-devx/', then click on 'Add selection' button. Pburn displays 'Busy, please wait...". So I wait a short time, then replaced with a new message 'A data disk contains files .... '. But, 'Minimum disc size:' box DOES NOT CHANGE from zero.
I have to left click on the next directory before it updates. This is the third time I have reported this bug in this forum.

2.
I then left-clicked on my '/puppy-unleashed/' directory, then immediately 'Minimum disc size:' updated, to 371MB (the previous size).

3.
Then I click 'Add selection' again the 'Busy, please wait...', after that has gone, once again 'Minimum disc size:' does not update.

4.
So, I left-click on another directory in the left pane, and this causes 'Minimum disc size:' to update, but to 677Mb, which is too small.

5.
I look in /tmp/pburn, and see that puppy-unleashed is incomplete. All that it has are directories 'boot', 'isolinux-builds', 'kernels', 'packages'. There should be more directories immediately under 'puppy-unleashed' and a couple of dozen files.

6.
I decided to quit Pburn, hit 'Quit' button. Weird, /tmp/pburn still exists, and the contents of /tmp/pburn has only been partially deleted. What remains is /tmp/pburn/puppy-devx, with some subdirectories still in it.

7.
I manually deleted all of /tmp/pburn.

7.
I restarted Pburn, this time selected File -> Preferences -> Burn and chose 'On the fly' and disabled Joliet.

8.
Then I again went ahead and chose my '/puppy-devx/' and '/puppy-unleashed/'. Still the same problem, none of the files immediately underneath these top-level directories are in /tmp/pburn, and some sub-directories are missing. The problem is it seems to be stopping part-way through, even though there is plenty of room in /tmp (there is no tmpfs mounted on /tmp and my laptop has 1GB RAM).

9.
At this point I decided to go to my latest Dingo build...

Running Dingo pre-beta, Pburn 1.3.0
Not running in RAM, booted off a USB Flash drive and have a pup_save, which I already know highlights another weird bug in Pburn...

10.
First thing I did was choose 'File -> Preferences...' but nothing happened. Gtkdialog has a syntax error.

11.
I installed the Pburn default theme package. Now 'File -> Preferences...' came up. So, this version of Pburn mus have a theme installed, even though there is a default gtkrc in the original package.

12.
Again I chose 'On the fly' and disabled Joliet.

13.
Again, selected '/puppy-devx/' and '/puppy-unleashed/'. Okay, 371Mb for the first, after adding the second directory and clicking another directory to force the disk size box to update, this time I get 3329Mb -- wow, what a difference! But, I look in /tmp/pburn, again heaps of files and directories missing.

14.
Anyway, I decide to go ahead and do a burn. I click the 'Burn' button, then 'Burn' again and up comes the gtklogfileview window. Lots of error messages, quite alarming! Mostly about files not being readable and ignoring them.
Here is a quick copy/paste from part of the log window:

genisoimage: No such file or directory. File /tmp/pburn/puppy-unleashed/packages/rox_filer-2.6.1-pup4/ROX-Filer.xpm is not readable - ignoring
genisoimage: No such file or directory. File /tmp/pburn/puppy-unleashed/packages/sgmixer-0.3/sgmixer.xpm is not readable - ignoring
genisoimage: No such file or directory. File /tmp/pburn/puppy-unleashed/packages/usbview-1.0-patched_gtk2/usbview.xpm is not readable - ignoring
genisoimage: No such file or directory. File /tmp/pburn/puppy-unleashed/packages/cgtkcalc-2.1.9/cgtkcalc.xpm is not readable - ignoring
genisoimage: No such file or directory. File /tmp/pburn/puppy-unleashed/packages/gmeasures-0.7/gmeasures.xpm is not readable - ignoring
genisoimage: No such file or directory. File /tmp/pburn/puppy-unleashed/packages/zfind-0.1.0/zfind.xpm is not readable - ignoring
genisoimage: No such file or directory. File /tmp/pburn/puppy-unleashed/packages/0rootfs_skeleton-4.00/dev/core is not readable - ignoring
genisoimage: No such file or directory. File /tmp/pburn/puppy-unleashed/packages/0rootfs_skeleton-4.00/usr/include/X11 is not readable - ignoring
genisoimage: No such file or directory. File /tmp/pburn/puppy-unleashed/packages/0rootfs_skeleton-4.00/usr/share/ghostscript/6.50 is not readable - ignoring

...the above are all symlinks. They are symlinks that point to nothing in their current locations and only point to a valid file after installation. It is WRONG that Pburn is rejecting them.

15.
Hmmm, the log window seems to have frozen. CPU is very busy. It hasn't got to the point of burning anything yet. I'm really worried, as I'm backing up my working puppy-unleashed directory and Pburn is very unpredictable.

16.
Yeah, the log window has frozen. I hit "Emergency stop'. 'ps' shows 'mkisofs' is still running, for some reason I can't kill it. CPU still very busy. I have decided to reboot.

17.
Okay rebooted. I have anxiously examined my working puppy-unleashed directory, hoping it hasn't been compromised. Seems alright. God, I hope so. This time I decide to burn another directory, let's see, 'puppy-unleashed217' can be the guinea pig.

18.
'/puppy-unleashed217/' ...er, it doesn't appear in the right pane. At this point, I have decided to wipe the pup_save file and reboot the USB flash, with Pburn 1.2.2 installed, as that works better -- it has major bugs, but did at least burn something to the DVD.

-----------
19.
Okay, have booted from USB Flash, no pup_save so running in RAM. This buld of Puppy has gtklogfileviewer-0.1, pburn-1.2.2 and pfilesearch-1.1.

20.
I go through same steps as above, choosing /puppy-unleashed21/ ..oh, once again, although I clicked 'Add selecion' it didn't appear in right pane. Ah! Maybe the contents is too big for a DVD! ...so why didn't Pburn tell me?

21.
I quit Pburn, again had to manually delete stuff in /tmp/pburn, in case that causes any trouble next time.

22.
Restarted Pburn. This time I chose /puppy-unleashed-3xxx/ which I know is small enough to fit. I have waited three minutes, CPU very busy, Pburn seems to have hung. Determining the size requirement doesn't take that long. I had launched Pburn from a terminal, and I see lots of error messages about whiteout files -- it seems that the puppy-unleashed-3xx directory accidentally has some whiteout files in it, which has caused Pburn to hang. Why? Pburn should just archive whatever is there, as is. The core reason for this problem and earlier symlinks problem is the method chosen to create a hierarchy of symlinks in /tmp/pburn. Anyway, have decided to reboot.

23.
This time I chose another directory, puppy-unleasghed301. Same problem, does not appear in right side. This time, looking at the terminal from which I launched Pburn, I see it is reporting "no space left on device". Huh? I'm running in RAM and have heaps of space. I have to edit this file in Leafpad, Geany is corrupted.

24.
Rebooted. Did a 'du -m puppy-unleashed301' and it is 1810MB. I give up

25.
This morning I was using v1.2.2 and I did burn to DVD, but I checked the DVD and noticed some files missing, and some files that were completely wrong, which is what started me off on this. Hmm, on that occasion I had a pup_save and 'devx' loaded, so I wonder if something essential was added that enabled it to get as far as burning?
But anyway, there was something I noticed, that is really bad:

I have just now mounted that DVD, and looking at /mnt/hdb/puppy-unleashed/packages/0rootfs_skeleton-4.00/usr/etc, what I see is gtk/etc-gtk.xpm. What SHOULD BE THERE is etc/gtk where the gtk is a symlink to /etc/gtk. Earlier on I had been debugging petget, fixing a bug that win2000 reported, and I had modified /usr/etc/gtk from a symlink to an actual directory /usr/etc/gtk with a file in it, etc-gtk.xpm -- but, this experimenting is in the absolute path /usr/etc, not in the /mnt/hda3/puppy-development/puppy-unleashed (and hence packages/0rootfs_skeleton-4.00/usr/etc that I had chosen to burn to DVD. Pburn had followed the symlink /mnt/hda3/puppy-development/puppy-unleashed/packages/0rootfs_skeleton-4.00/usr/etc/gtk and burnt the absolute path /usr/etc/gtk/etc-gtk.xpm to the DVD.

CONCLUSIONS
Missing directories, missing files, symlinks totally stuffed up. There are also other issues as reported above,. TkDVD on the other hand, works flawlessly. I have tested TkDVD on all the puppy-unleashed directories. Perhaps it would be useful to examine the code in TkDVD and do it the same way._________________http://barryk.org/news/

<action>refresh:ISOSIZE</action>
is missing from the 'add selection' button..seems to solve the size update problem...right click to add was ok.

Quote:

If using 'diff' to verify burnt files, it would be best I think to use the '-q' option. See reference:

Have you noticed this contradictory statement?

Quote:

Differing binary files are considered to cause trouble because the resulting diff output does not capture all the differences. This trouble causes diff to exit with status 2. However, this trouble cannot occur with the --a or --text option, or with the -q or --brief option, as these options both cause diff to treat binary files like text files.

wasn't sure what to make of that but

Quote:

If diff thinks that either of the two files it is comparing is binary (a non-text file), it normally treats that pair of files much as if the summary output format had been selected (see Brief), and reports only that the binary files are different. This is because line by line comparisons are usually not meaningful for binary files.

diff determines whether a file is text or binary by checking the first few bytes in the file; the exact number of bytes is system dependent, but it is typically several thousand. If every byte in that part of the file is non-null, diff considers the file to be text; otherwise it considers the file to be binary.

seems to be saying that diff will select the right mode anyway....confused...I was...though simply verifying that 2 binary files are identical is valid.

I tried various options...cmp , md5sum, cksum and all gave roughly the same performance. There doesn't seem to be anything else in the linux world to perform this function...all roads lead to diff.!....the bottleneck seems to be in reading data regardless of the method used. Only suggestion may be a notice mentioning verifying a dvd will take a long time.

Can't really comment on the missing subdirectories/files and symlink problem though there does seem to be something amiss....don't remember seeing that in early versions as I vaguely remember trying it.

This was an outstanding report
Even with my bad English knowledge, I felt I understood your point. As I earlier have told you, I have my reasons for keeping the symlink tree. BUT, I think I see a rather easy solution. 'readlink' reads only 1 level of a symlink, so the symlink in /tmp/pburn/ will point to the original symlink, and not its file.

There is no time for this right now. I need 48 hours to check this out, and maybe bring up a new version with -graft-points or another solution.

I did some more testing. I was puzzled why Pburn hung on some of my puppy-unleashed directories, and on some managed to get as far as burning to DVD.
I found that my puppy-unleashed3.01 and puppy-unleashed3.xx directories have some whiteout files in the xfce_BASE package, for example:
packages/xfce_BASE-4.3.99.2/usr/share/pixmaps/exo-0.3/.wh.__dir_opaque

/tmp/pburn is inside the Unionfs (except for Puppy 3.01 with a pup_save on the internal hard drive, which has a tmpfs mounted on /tmp) and creating symlinks to whiteout files is causing something chaotic to happen.

Ideally, Pburn should archive puppy-unleashed3.xx as-is, but for the current situation in Pburn, you could simply check for any files starting with '.wh.' and ignore those.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum