Known Bugs

From openZIM

Jump to: navigation, search

Please report bugs to http://bugs.openzim.org/!

unspecified 
 
NEW (4)
RESOLVED (17)
22
total22

Current List of Bugs

IDPStatusSeverityVersionProductSummary (22 tasks) ⇒ 
16*
16 I already changed the zimlib to check just the first 2 bytes of the 4 bytes version number. In future versions we can then use the remaining bytes for a minor number. The current zimlib then will ignore, if this minor number is not zero, while zimwriter writes a zero minor number.
P1RESOLVEDenhancementunspecifiedopenZIMVersion & Subversion ZIM format handling 
19*
19

So if the last fixes listed in this following email were commited to the SVN https://intern.openzim.org/pipermail/dev-l/2010-April/000398.html

... the zimlib should be 100% compatible with MS Windows cl.exe compiler and the 2GB bug fixed.
P1RESOLVEDblockerunspecifiedopenZIMWindows+MSVisualStudio: Zimlib is unable to deal with ZIM files larger than 2GB 
1*
1 This is not included in the new ZIM format. I have to test it.
P2NEWenhancementunspecifiedopenZIMHandling of categories inside the ZIM format 
10*
10

I added 2 configure options --with-cluster-cache-size=number and --with-dirent-cache-size to tune default cache sizes. Additionally also the environment variables ZIM_CLUSTERCACHE and ZIM_DIRENTCACHE are read, which when set override the cache sizes.

The cluster cache caches uncompressed clusters. By default zimlib caches the last 16 clusters and with the default cluster size of 1MB this means 16MB of memory usage. For small devices the cache size may be reduced.

The dirent cache is by default 512. Dirents are not that big. They take about 30 bytes, so it makes not that much sense to reduce that value.
P2RESOLVEDenhancementunspecifiedopenZIMcaching on low memory devices 
4*
4

We discussed this at our last developer meeting and decided to add a new namespace for that, which is now documented in the wiki. So there is no need for a change in the zim file format.

A possible enhancement is to add better support for that in zimwriter. And also zimdump should look for the entries when printing information about a zim file.
P3RESOLVEDenhancementunspecifiedopenZIMNew header fields 
11*
11 This is done. The mime-types have to be specified by the ZIM file creator in the DB (or done auto. from the building script).
P3RESOLVEDenhancementunspecifiedopenZIMDynamic mime-types 
14*
14

Should also be checked if the HTML content do not have any online dependences. For example <img src=http://....

Also in the CSS.
P5ASSIGNEDenhancementunspecifiedopenZIMzim-check 
2*
2

So if the last fixes listed in this following email were commited to the SVN https://intern.openzim.org/pipermail/dev-l/2010-April/000398.html

... the zimlib should be 100% compatible with MS Windows cl.exe compiler.
P5NEWenhancementunspecifiedopenZIMAdd Windows/ReactOS support 
18*
18

I think this feature request is for Kiwix and not for openZIM.

But, this would be a good idea to keep open this ticket here as zimreader also should (at least the deb. package of zimaread) also provide such script.

In any case, thank you a lot Wizzy for your script, I have integrated it in the Kiwix SVN (see debian/ directory) http://kiwix.svn.sourceforge.net/viewvc/kiwix/moulinkiwix/debian/init.d?revision=1374&view=markup

I have also open a feature request on kiwix side to finish the integration work within the deb. package.

https://sourceforge.net/tracker/?func=detail&aid=2976515&group_id=175508&atid=873518
P5NEWenhancementunspecifiedopenZIMdebian needs an init.d script 
21*
21

The zimlib needs to fully unpack a content before giving delivering it to a third part software.

This has many disadvantages especially if the content is big, a video for example:

  • This will need pretty much memory
  • This will take time
  • You do not have a random access (necessary to seek in an HTML5 video)
It would be a really good usability improvement to have a method which delivers only a part of any content.
P5NEWenhancementunspecifiedopenZIMZimlib should allow to get/unpack only a part of a content 
3*
3 There is a uuid-field already in zim files. This is a 16 bytes random field. It is filled by a md5 sum of the current timestamp induding microseconds as returned by the system function gettimeofday.
P5RESOLVEDenhancementunspecifiedopenZIMAdd a unique identifier header field 
5*
5

Seems to have beed fixed by Tommi:

https://intern.openzim.org/pipermail/dev-l/2009-August/000147.html
P5RESOLVEDmajorunspecifiedopenZIMzimreader on arm: miss-aligned dirent header 
6*
6

Seems to have beed fixed by Tommi:

https://intern.openzim.org/pipermail/dev-l/2009-August/000147.html
P5RESOLVEDblockerunspecifiedopenZIMzimreader on arm: cxxtools/m4/asmtype.m4 broken for arm architecture 
7*
7

It works now on GNU/Linux, Symbian and Windows. Compression method can be configured per mime-type.

I close the feature request.
P5RESOLVEDenhancementunspecifiedopenZIMImprove compression 
8*
8 Is that an option to add to the configure an option to avoid the compilation of the test framework like --enable-tests ? Otherwise the dev. is forced to installed cxxtools what is not really great to my opinion.
P5RESOLVEDnormalunspecifiedopenZIMzimlib unable to simply compile without cxxtools 
9*
9

Bug #10 should resolve that. It is not reasonable to create device specific zim files. Instead Bug #10 makes the number of clusters, which are cached when reading configurable. When the default cluster size of 1MB is used, and the cache size is set to 0, this 1MB is needed, which I feel is a reasonable value. I don't think we need to support devices, which have less memory.

1MB is also the value, which is normally used in compression libraries. So it increasing the value does not lead to better compression ratios. On the other side smaller values lead to worse compression ratios.
P5RESOLVEDenhancementunspecifiedopenZIMoptimize cluster size (small devices limitations) 
12*
12

Reason for the problem was a failed data transfer of zim file. Zimlib correctly replied with a exception when trying to read the cluster, which was not in the file.

While investigating the reason for the problem (it was actually no bug), I discovered, thatn zimwriter does not check, if the file was successfully written. This is fixed now.
P5RESOLVEDblockerunspecifiedopenZIMZimReader freezes 
13*
13

zim::File::find returns always the next article when no excact match was found.

There is another method "zim::File::findx(char ns, const QUnicodeString& title, bool collate = false)". This returns a "std::pair<bool, const_iterator>". The first element is true, if a excact match was found and false otherwise. The second element returns the const_iterator. zim::File::find is actually a wrapper around findx, which throws the bool-flag away and returns just the const_iterator.

You may as well use zim::File::getArticle. This uses findx as well but returns a null article (article.good() returns false) if no exact match was found.
P5RESOLVEDnormalunspecifiedopenZIMzim::File::find always returns an article 
15*
15

There is a operator<< for std::ostream, which prints the hex representation of the uuid. If you want to see the hex representation of a uuid do: 

 zim::Uuid myUuid = ...;
 std::cout << myUuid;

If you really need a std::string, use std::ostringstream: 

 std::ostringstream s;
 s << myUuid;
std::string hexUuid = s.str();
P5RESOLVEDenhancementunspecifiedopenZIMzim::File getUuid() should return an HEX encoded MD5 hash 
17*
17 Me too. I just tested with xz 4.999.9beta on opensuse. In lzma.h I can find #include "lzma/check.h", so it should be ok. If you can offer more information please reopen this bug.
P5RESOLVEDnormalunspecifiedopenZIMlzma_check is undefined in lzmastream.h 
20*
20 Latest version is compling again
P5RESOLVEDmajorunspecifiedopenZIMNot compiling (‘uint16_t’ does not name a type) 
22*
22 The patch adds dependency to boost. This is not really needed. There is a protected constructor and a member in iostream, which allows to initialized the base class without a streambuf and pass the streambuf in the body of the constructor.
P5RESOLVEDblockerunspecifiedopenZIMcrash on opening zim file 
Retrieved from "http://openzim.org/Known_Bugs"
Personal tools