3.2.0 Bug Report / Feedback Thread

To add: this is generally more of a "feature creep" delay than a botched estimate one - with iOS 9 beta debuting in June, there's a strong likelihood that 3.3 will require iOS 8, so we're trying to cram in as much as we can for users stuck on 7 just as we did last summer for users stuck on 6.

I see. Good stuff! Looking forward to the update.

I already complained about the navigation bar in the pdf reader, since then it happend to me a couple times that I wanted to open the ios bottom drawer menu or just accidentally touched this area and ended up in a random position of the book, not knowing where I was before... that can be annoying. Another thing, when I open the dictionary bubble at the bottom or top the page moves a bit up/downwards, revealing a black bar at the top.

Are you on 3.2.5 now? We fixed several bugs relating to page jumping in that. The second jumping issue (up/down about the height of the status bar) is a harder problem to avoid (occurring pretty deep within our PDF reader library) though we're working on it too.

yes I am on 3.2.5. The second one is not that problematic anyway, just a glitch. The first one, not sure if it's a bug because it's mainly just me touching the navigation bar accidentally. A back button would help to return to the previous position if you can't remember the page number.

Sorry, you mean you're accidentally tapping on the bar on the bottom of the screen? (technically the "navigation bar" is the one on the top of the screen but that's only what developers call it) At the moment the best way to avoid that would be to turn on the vertical scrolling PDF option in Settings / Reader.

Oh right sorry for the confusion, yeah I mean the one at the bottom. Guess I will use vertical scrolling, although I prefer the page-wise navigation.

hey, the tts does an amazing Chinglish accent when you highlight English words to be read.

Is there any traditional forms in the 方正黄草-font atm? For me it always displays exactly the same form for both.

Hardly any, I believe - we're trying to find a fanti-optimized Caoshu font we can pair it with (we'd plan to offer it for free to people who bought the jianti one), our Kai / Song / Xing fonts all include plenty of fanti but we weren't abel to find a Caoshu font with good coverage of both character sets.

For all other fonts, like the Small Seal above, the missing characters will be replace by some other font (some song-font), however for the new Cao font just uses the same form for both. That must be a bug, right? Maybe you could have the replaced by the xing font if that is installed until the new fantizi are added?

Yeah, it's in the nature of how the font is encoded - they point fanti code points at jianti glyphs rather than supplying separate fanti ones.

I think there's a slight bug (or perhaps that's by design but undocumented) in the way the per-dictionary "Search only as fallback" setting works with custom dictionary groups.

I have HanDeDict and CFDICT installed but only want to use them for fallback search. I also have two custom dictionary groups, "Chinese Monolingual Dicts" (C-C) and "Chinese Bilingual Dicts" (C-E), which I use instead of the built-in "All Chinese Dicts" (C), set to "Skip over on button tap." Now when I search from within "C-E", HanDeDict and CFDICT always appear in the search results, which doesn't happen if I use the built-in "C" group. (This applies to Android as well, by the way.)

I can definitely live with it, but just letting you know since I don't think that's intended.

This is actually intentional, though it's a bit confusing - a reflection of the fact that we're in the middle of transitioning from our old system of individual dictionaries to our new system of dictionary groups (which will eventually replace the old system entirely). The "use as fallback" flag when set for an individual dictionary only applies for a) searches of that dictionary by itself (if "skip over on button" is disabled), and b) searches of that dictionary within the "all" groups.

If you want to have fallback dictionaries outside of that, right now the only option is to create a separate group and make the group itself a fallback. Once we complete the transition to all groups we will probably do fallbacks via the group dictionary configuration screen instead of within individual dictionaries' configuration screens.

I've just run into an interesting issue with the custom dictionary groups and user dictionaries. In my setup, I have MoEDict as part of my "monolingual" (C-C) group, as well as AV Chinese and Radicals in my "bilingual" (C-E) group. It all worked well until yesterday I found some formatting problems in my AV Chinese dictionary, and after fixing them in the source .txt file I deleted the old dictionary entirely, re-created it from scratch with the same name, and re-imported all the entries. From then on, every time Pleco is restarted, all the user dictionaries within the custom groups are moved to the "Inactive" section. This happens on Android, too.

They can be moved back to the "Active Dictionaries", at which point they work normally, or the settings can the restored from backup to the same effect, but at some point the user dictionaries will inevitably become "Inactive" again (a restart is the sufficient condition for this to happen but it might also be triggered by something else, I'm not certain here).

On Android I also intermittently saw an all-empty entry when rearranging the dictionaries under "Choose Dictionaries" in the group settings, which would suggest there is some orphaned dictionary entry on that list possibly causing this issue but I couldn't reproduce this issue anymore now to take a screenshot.

Resetting all the settings and restoring them from backup doesn't solve this problem (tested on Android). I'll try to create a new dictionary group as maybe this only happens when dictionaries are added or removed after a group was created. Edit: Happens with a newly-created group as well (tested on iOS).

Thanks - we actually partially fixed this bug in 3.2.5 (before that you would often find that user dictionaries were buried at the bottom of Manage Dicts + had their settings reset) but it seems like our fix didn't fully cover dictionary groups so we'll make sure that's covered in 3.2.6.

The problem relates to user dictionaries taking too long to load. We don't load user dictionaries before the app starts up because it can take too long - if a database was closed uncleanly / needs to be patched up by the database engine that can take 5-10 seconds by itself, or if you simply have a whole lot of big / complicated user dictionaries that can often cause an unacceptable delay too. So the bug comes up when Pleco stays open too long without user dictionaries and reaches a point where it saves out its current state to disk (in case of a crash) - as far as the app is concerned there's no difference between a user dictionary that hasn't opened yet and a user dictionary that was permanently deleted, so that state is saved out without any user dictionaries, thus causing the settings reset when they eventually do load.

As a temporary workaround I'd suggest that you delete / disable as many user dictionaries as you can stand to - that should hopefully get startup to be fast enough that this won't be a problem.

I did some follow-up tests (for convenience, on Android) regarding the user dictionaries missing from custom groups upon restart and it seems it's not caused by an excessive number of user dictionaries installed.

First, I assumed MoEDict to be the main culprit since it's significantly larger but removing it didn't resolve the issue. Then I entertained the possibility that it's something wrong with my regenerated AV Chinese dictionary: the previous version populated on Android was 3.14 MiB in size, while the new one, created on iOS, ended up being 3.33 MiB despite not having anything added (in fact I removed one duplicate entry and fixed duplicate quotation marks in 58 defintions, so, holding all else constant, the file should be smaller). I disabled the full-text search index, to no change, and finally removed the dictionary altogether.

My third guess was the flashcards database, which got somewhat large, so I erased it as well (using the menu function). No change here either. Finally, I removed all the user dictionaries and with an empty flashcard database added the smallest of them all, Radicals-120605 (212 KiB). Whether the dictionary is copied manually to /sdcard/Android/data/com.pleco.chinesesystem/files/databases/ or I use the menu option to install it, the issue is still there. Also, I've been able to reproduce the all-empty entry on the dictionary list, and took a screenshot of it (attached). It happens when the new dictionary (Radicals in this case) is added, and appears on the bottom of the list, after I drag it up.

Another thing I noticed is that when there are no *.pqb files whatsoever, Pleco takes less than a second to start up, whereas as soon as there is any .pqb file present it spends as much as 3 seconds on the grey background before the interface appears.

It really looks as if there is (are) some ghost dictionary entries or other settings that cause this problem and they persist despite the settings being reset (tried that again just a moment ago, also repeated the final attempt with the AV Chinese dictionary instead of the Radicals). I'll now wipe all the Pleco data from /sdcard/Android/data/com.pleco.chinesesystem/* uninstall the app completely and install it again, and I have a hunch this will solve the problem (will update the post) but would like to know what caused it in the first place, if anything so that I don't do it again. Hope the above helps with debugging, it's possible the original fix you had in mind (increasing the timeout) might not be necessary at all.

Increasing the timeout as a workaround isn't really a good idea because the timeout is designed to preserve your settings in the event of a crash - i.e., there would be negative consequences for its intended purpose. But we have another solution that we've deployed in the recently-submitted 3.2.6 update on iOS which we can try on Android as well.

The gray screen on startup is more of a mystery - it may be that threading or filesystem access on some devices is set up in such a way that even if the dictionaries are loading on a background thread they end up blocking another operation on the main thread, Android bug fixing often feels like watching 100 violinists all play at the same time and trying to figure out which one is out of tune

I'm about to wipe everything and reinstall to see if it starts working again but if there's any way I can help to identify the reason while the problem is still there, I'll do it; please let me know. Right now it's a situation when even with no flashcards and a single small dictionary, the custom group settings for user dictionaries don't persist, so it's somewhat interesting. I also checked the logcat during Pleco startup for some additional cues but the only thing of interest was this:

As a side observation, not sure if related, the "Copyright" field is not preserved when a user dictionary is created or edited on Android (at least now for me). After a restart, it becomes empty again (for the AV Chinese dictionary, I put there a link to the Pleco forums thread). I even had Pleco crash on me once while trying to save this field but unfortunately I don't have a logcat/trace/tombstone of what happened.

Sorry for bothering you about all this. I hope you know I'm not deliberately looking for some obscure problems, just like to take advantage of all the available features: I can live without some of them if they're not there, but would like to have everything set up in advance so that there are no surprises later on. Once it's all set, I tend not to tweak anything anymore, so I'll not be posting in this thread forever.

I think we need to do some more work on this here before we'll have any idea what kind of outside information we'd need - right now we're kind of busy getting some things in order before we go into Crazy Summer OS Update Catchup Mode starting with the launch of iOS 9 Beta 1 next Monday.

Copyright thing is a known bug, fixed in 3.2.5 on iOS and soon on Android too.