Quote:
Originally Posted by DiapDealer
I'm getting good results with these latest scripts. I'm still trying to find something in one of my books that breaks it, but I'm not having much luck.  |
I just found a book with the same kind of problem:
calibre fetched a scheduled feed just while i was testing some files, so i tried the resulting "periodical" mobi and that was it
It seems the problem is with the INDX parsing, i got the output:
Code:
parsed INDX header:
len 192 nul1 0 type 1 gen 0 start 1256 count 54 code 4294967295 lng 4294967295 total 0 ordt 0 ligt 0
contextual data @ xB
DF 0 -1 1 6
contextual data @ x98
2 2 E2 -1 -1
contextual data @ x127
46 2 E2 -1 -1
which shows that from the second entry everything is mangled.
There's actually an extra VWI in the first "DF" entry so the rest is shifted.
I guess the right way to fix should be to use the TAGX data to reliably know what to expect in the entries.
In this particular case our current "type-based" rules might work if we took into account the differences between book & periodical style indexes...but i'm yet to fiddle with that...
EDIT:
I missed KevinH last post...
Thanks for the tagx code i'll look into it
And yes there were some errors in the sortINDX code
i actually (silently out of shame
) reuploaded the zip earlier with >= replaced by > in the first test and other fixes
EDIT2:
tagx: pretty impressive, many thanks for quickly implementing this tagx bit i had skipped altogether
sortINDX: you got the second ">0" error but missed the one i mentioned above
refactor: i was toying with the oop approach before but wouldn't do it to keep in sync with other versions, but i have a mobiunpack_ootest.py somehere...