|
Looking at the collections.json after I manually (i.e. using the kindle's UI) put the rogue files into collections, I'm seeing some weird "ASIN" values.
To take an example, the file with the lpath:
documents\Douglas Adams\HHGTTG 01 the Hitch Hikers Guide to the Galaxy (H0tHHGttG-DAHGttGT1).mobi
Gets an ASIN (via the usual formula, and te one used in the script) of:
*ffccd1edd94d20b512450535de6a42e0181d7df3
Now, that file doesn't show up as being in a collection on the kindle's UI. However, that asin is in all the right places in the collections.json file (and Calibre thinks it's in those collections). If I then, using the kindle, put that "rogue" file into a collection and have a look at the collections.json, I see this "asin" id being used for that file:
#B000XUBC2C^EBOK
The asin from the script (*ffccd1edd94d20b512450535de6a42e0181d7df3) is still there in the collections.json but is being ignored by the kindle.
Any idea how/why the kindle is deriving this new value? It's not because of any clash of asin ids (I checked - no other files share the same asin), it's not coming from amazon.com (I have wireless switched off) and the form isn't a one-off one, as I got similar results for other "rogue" files (eg #B000R4LGMA^EBOK and #B000JMKTE6^EBOK - all of the form "#B00[XXXXXXX]^EBOK", where "[XXXXXXX]" is a sequence of 7 characters, each of which is numeric or upper-case alphabetic).
It must be being derived from the mobi files consistently in some fashion, though, and not involving timestamping (if I remove the mobi and re-send it to the kindle I get the same "rogue" id generated).
Just some food for thought: And if anybody can figure this bit out then the script can be made more reliable.
|