View Single Post
Old 06-22-2012, 06:19 AM   #15
knc1
Embedded Cheerleader
knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.knc1 ought to be getting tired of karma fortunes by now.
 
knc1's Avatar
 
Posts: 6,666
Karma: 5850002
Join Date: Feb 2012
Device: Too many.
Quote:
Originally Posted by silver18 View Post
I understood the problem: I wrote the code thinking about a folder containing files with only one name pattern (03_XXX) and not two (03_XXX and CreditsXX).

I'm working on it!!


@DRIVER733: both files are mis-named as knc1 stated above!
The mis-named files above show another pattern where the page number is inserted after the volume number.
T == Title
V == Volume
P == Page
X == ?
E == Extension
Under-bar replacing spaces.

File name: TT_TT_VVV_XXX.cbz
Created directory name: TT_TT_VVV_XXX
Cover name: TT_TTVVV_PP_XXX.jpg
Page names: TT_TTVVV_PP_XXX.png

So they do sort into page order before adding a leading page number. Adding a leading page number should not changing their sorted order.

But you will have to sort them in your code (I admit, I didn't read your code to see if you are already doing that).

You can't depend on the contents of the zip (cbz) or rar (cbr) to be in sorted order, the most common order will be "source directory order". Which may or may not be sorted.

The unarchive process maintains the order of contents -> ctime order.
FAT-32 does not have enough resolution in the time fields for this relationship to be useful.

Programming languages "normally" return directory contents in directory order. Where "directory order" depends on the (in *nix) hashed value of the name.

When looking at the directory contents from the command line:

The *nix list (ls) command normally returns the names in sorted order. You have to pass the "-f" option to see the directory (hash) order.
And if the list (ls) command on the Kindle is provided by Busybox, it may or may not be listing files in sorted order, it may or may not have an "-f" option.

Translation: The order of the files returned by "ls" may not be the order your program sees them - you will have to sort them.

- - -

The Title field is "mixed" (bumpy) case and being written to a FAT-32 volume on Linux.
So check the mount options of that USB storage area -
The mount command without arguments shows what options current file systems have been mounted with:
(non-Kindle, but a FAT-32 volume on Linux as an example)
Code:
/dev/sde1 on /media/A80E-9247 type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks)
Your looking for what Amazon/lab126 decided to use for the "shortname" and "character set" options.

The result of their choice of options may also have to be dealt with even though these are "long names".

Edit:
The names are bumpy case, the XXX is not. So a token of some kind?
RHN == Right Hand Number == trailing volume number, trailing page number?
I.E: Process string right to left, first character sequence describes where the page numbers are at in the string?

With that information, then you know how to compute the file name of a page number. No sorting and renaming with a leading sequence number required.

Duh... Just guessing. First digital comic book I have ever looked at - mine where on paper.

Last edited by knc1; 06-22-2012 at 08:25 AM.
knc1 is offline   Reply With Quote