View Single Post
Old 11-03-2012, 04:54 PM   #437
pdurrant
The Grand Mouse 高貴的老鼠
pdurrant ought to be getting tired of karma fortunes by now.pdurrant ought to be getting tired of karma fortunes by now.pdurrant ought to be getting tired of karma fortunes by now.pdurrant ought to be getting tired of karma fortunes by now.pdurrant ought to be getting tired of karma fortunes by now.pdurrant ought to be getting tired of karma fortunes by now.pdurrant ought to be getting tired of karma fortunes by now.pdurrant ought to be getting tired of karma fortunes by now.pdurrant ought to be getting tired of karma fortunes by now.pdurrant ought to be getting tired of karma fortunes by now.pdurrant ought to be getting tired of karma fortunes by now.
 
pdurrant's Avatar
 
Posts: 71,514
Karma: 306214458
Join Date: Jul 2007
Location: Norfolk, England
Device: Kindle Voyage
Quote:
Originally Posted by NiLuJe View Post
Just a quick heads up: I'm using a trimmed down version of MobiUnpack in the latest K5 ScreenSavers hack . (I say trimmed down, because I only needed to extract the cover, so I chopped off everything I didn't need ).

It works surprisingly well (after a painful cross-compile of Python 2.7.3 >_<") so far, the only thing of notice I ran into was a MemoryError on the loadSection() of the last section.
I looked at how Calibre was doing it, and saw that it wrapped it in a try/except block to catch OverflowError exceptions (and, indeed, a bit of good old printf debugging seems to point out that after looks like an overflow on the last section).
I tweaked that a bit:

Code:
@@ -267,7 +67,12 @@
     def loadSection(self, section):
         before, after = self.sections[section:section+2]
         self.stream.seek(before)
-        return self.stream.read(after - before)
+        try:
+            return self.stream.read(after - before)
+        # This bombs out with a MemoryError on Kindle on the last section (where after overflows)
+        except (OverflowError, MemoryError):
+            self.stream.seek(before)
+            return self.stream.read()
And it does the job, but I was wondering if there wasn't a cleaner way to achieve that... (I feel a bit dirty catching a MemoryError exception...).
It's trying to do something clever to be usable with both files and streams, and so didn't get the file length. The version I'm currently working on abandons the attempt to work with streams (since it seems completely unnecessary), and so should eliminate this infelicity.
pdurrant is offline   Reply With Quote