New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Strange Search results on Galaxy Tab 3 when searching for Japanese words #290

Closed
GoogleCodeExporter opened this Issue Mar 14, 2015 · 21 comments

Comments

Projects
None yet
2 participants
@GoogleCodeExporter
Collaborator

GoogleCodeExporter commented Mar 14, 2015

What steps will reproduce the problem?
1. open Aedict and enter a Japanese word in the omni search box using hiragana 
or Kanji (I use Google Japanese Keyboard)

2. Search...

What is the expected output? What do you see instead?
The dictionary entry of this word should be displeayed (maybe sevaral as there 
could be several homophone word = same pronounciation but different 
meanings/kanji)
Instead on (empty) result is displayed for each hiragana/kanji entered.

Seach works fine for english words...

See Screenshots for more details

What version of Android are you using?
Android: 4.2.2
Kernel-Version: 3.4.34-2545684
Model: GT-P5210 (Samsung Galaxy Tab 3 WiFi)
Aedict Version: 3.4.19

Please provide any additional information below.
I also own a Samsung Galaxy S3 and a S3-mini and Aedict 3.4.19 works nicely on 
both.
I have tried to compare my settings on S3-mini and Tab and they seem to be the 
same... however i cannot garantee that the defect is not between keyboard and 
chair (or tablett and couch in this case) (^_~)v


Original issue reported on code.google.com by Nedo...@googlemail.com on 12 Jul 2014 at 6:13

Attachments:

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 14, 2015

Collaborator
Oh no. This is most definitely NOT between keyboard and chair - exactly the 
same problem was reported by another user a year ago, on the same device. She 
resolved the issue by buying another tablet... The worst part is that I do not 
have a slightest idea, what the problem is, and I do not own the Galaxy Tab 3 
myself. Would you be so kind and help me resolving the issue? For starters, I 
will need the Aedict log (Aedict logs what it is doing, into the device system 
log. Please see http://code.google.com/p/aedict/wiki/FAQ#Q:_Aedict_3_log for 
details) - perhaps I can discover more on what is going on. Please note that 
the log may contain sensitive information such as phone numbers you have dialed 
etc - please review it before posting here.
Thanks!

Original comment by martin.v...@gmail.com on 14 Jul 2014 at 8:10

Collaborator

GoogleCodeExporter commented Mar 14, 2015

Oh no. This is most definitely NOT between keyboard and chair - exactly the 
same problem was reported by another user a year ago, on the same device. She 
resolved the issue by buying another tablet... The worst part is that I do not 
have a slightest idea, what the problem is, and I do not own the Galaxy Tab 3 
myself. Would you be so kind and help me resolving the issue? For starters, I 
will need the Aedict log (Aedict logs what it is doing, into the device system 
log. Please see http://code.google.com/p/aedict/wiki/FAQ#Q:_Aedict_3_log for 
details) - perhaps I can discover more on what is going on. Please note that 
the log may contain sensitive information such as phone numbers you have dialed 
etc - please review it before posting here.
Thanks!

Original comment by martin.v...@gmail.com on 14 Jul 2014 at 8:10

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 14, 2015

Collaborator
I have created a logfile and will attach it here ...
If there is anything that I can do (like extra tests etc.) to help you 
debug&fix this issue let me know...

Original comment by Nedo...@googlemail.com on 14 Jul 2014 at 9:09

Attachments:

Collaborator

GoogleCodeExporter commented Mar 14, 2015

I have created a logfile and will attach it here ...
If there is anything that I can do (like extra tests etc.) to help you 
debug&fix this issue let me know...

Original comment by Nedo...@googlemail.com on 14 Jul 2014 at 9:09

Attachments:

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 14, 2015

Collaborator
Hmm, the log is missing vital information. For example, when searching for 
"ha", the log should contain entries as follows:

07-14 13:00:48.759  26081-26415/sk.baka.aedict3 I/s*.b*.a*.s*.JMDictQuery﹕ 
Running query jp:"WはW" OR jp:"Wは" OR jp:"Wハ" OR jp:"Wha" OR sense:"ha"
07-14 13:00:49.430  26081-26223/sk.baka.aedict3 I/s*.b*.a*.s*.JMDictQuery﹕ 
Received 65 items; Lucene search 1133ms / boost 0ms / wrap 0ms

Perhaps the logcat does not catch the entire log? Can you please try to install 
the Android SDK and run the "adb logcat" command from shell, as stated here: 
http://developer.android.com/tools/debugging/debugging-log.html ? You can get 
the SDK here: http://developer.android.com/sdk/index.html - you don't need the 
SDK with IDE, click "GET THE SDK FOR AN EXISTING IDE". Download the zip, find 
"adb.exe" and run it in cmd.exe as follows: adb logcat
Thanks!

Original comment by martin.v...@gmail.com on 14 Jul 2014 at 11:07

Collaborator

GoogleCodeExporter commented Mar 14, 2015

Hmm, the log is missing vital information. For example, when searching for 
"ha", the log should contain entries as follows:

07-14 13:00:48.759  26081-26415/sk.baka.aedict3 I/s*.b*.a*.s*.JMDictQuery﹕ 
Running query jp:"WはW" OR jp:"Wは" OR jp:"Wハ" OR jp:"Wha" OR sense:"ha"
07-14 13:00:49.430  26081-26223/sk.baka.aedict3 I/s*.b*.a*.s*.JMDictQuery﹕ 
Received 65 items; Lucene search 1133ms / boost 0ms / wrap 0ms

Perhaps the logcat does not catch the entire log? Can you please try to install 
the Android SDK and run the "adb logcat" command from shell, as stated here: 
http://developer.android.com/tools/debugging/debugging-log.html ? You can get 
the SDK here: http://developer.android.com/sdk/index.html - you don't need the 
SDK with IDE, click "GET THE SDK FOR AN EXISTING IDE". Download the zip, find 
"adb.exe" and run it in cmd.exe as follows: adb logcat
Thanks!

Original comment by martin.v...@gmail.com on 14 Jul 2014 at 11:07

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 14, 2015

Collaborator
You can run "adb logcat >log.txt" to obtain the log as a file.

Original comment by martin.v...@gmail.com on 14 Jul 2014 at 11:08

Collaborator

GoogleCodeExporter commented Mar 14, 2015

You can run "adb logcat >log.txt" to obtain the log as a file.

Original comment by martin.v...@gmail.com on 14 Jul 2014 at 11:08

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 14, 2015

Collaborator
OK, second try ... I got the SDK and ran:

adb logcat | find "/s*.b*.a*" > AedictLog_20140714_3.txt

I removed the blank lines but nothing else. result is attached...

Original comment by Nedo...@googlemail.com on 14 Jul 2014 at 5:43

Attachments:

Collaborator

GoogleCodeExporter commented Mar 14, 2015

OK, second try ... I got the SDK and ran:

adb logcat | find "/s*.b*.a*" > AedictLog_20140714_3.txt

I removed the blank lines but nothing else. result is attached...

Original comment by Nedo...@googlemail.com on 14 Jul 2014 at 5:43

Attachments:

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 14, 2015

Collaborator
Thank you very much, your effort is really appreciated. Now the log is 
complete, please let me analyse it...

Original comment by martin.v...@gmail.com on 15 Jul 2014 at 4:41

Collaborator

GoogleCodeExporter commented Mar 14, 2015

Thank you very much, your effort is really appreciated. Now the log is 
complete, please let me analyse it...

Original comment by martin.v...@gmail.com on 15 Jul 2014 at 4:41

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 14, 2015

Collaborator
As a first rough hint, please try opening the search properties (upper-right 
"screwdriver" icon) and make sure that you are not searching in the example 
sentences.

Original comment by martin.v...@gmail.com on 15 Jul 2014 at 5:01

Collaborator

GoogleCodeExporter commented Mar 14, 2015

As a first rough hint, please try opening the search properties (upper-right 
"screwdriver" icon) and make sure that you are not searching in the example 
sentences.

Original comment by martin.v...@gmail.com on 15 Jul 2014 at 5:01

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 14, 2015

Collaborator
[deleted comment]
Collaborator

GoogleCodeExporter commented Mar 14, 2015

[deleted comment]
@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 14, 2015

Collaborator
It doesnt make a difference whether I use "search in¨ with dict, kanjidict or 
examples. Same result always.
In the log there should be searches for all three (or at least dict and 
kanjidict) as I tried to include most of the options from the screwdriver menue.

Original comment by Nedo...@googlemail.com on 15 Jul 2014 at 5:11

Collaborator

GoogleCodeExporter commented Mar 14, 2015

It doesnt make a difference whether I use "search in¨ with dict, kanjidict or 
examples. Same result always.
In the log there should be searches for all three (or at least dict and 
kanjidict) as I tried to include most of the options from the screwdriver menue.

Original comment by Nedo...@googlemail.com on 15 Jul 2014 at 5:11

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 14, 2015

Collaborator
Thanks for your patience and I am sorry for the inconvenience. Can you please 
contact me at vysny@baka.sk? I will send you an update version of Aedict which 
logs more verbosely. Perhaps we will find something.

However, there is something very weird going on: on your tablet the search for 
本 shows 0 results:
I/s*.b*.a*.s*.JMDictQuery( 3654): Running query jp:"W本W" OR jp:"W本W" OR 
jp:"W本W" OR jp:"W本W"
I/s*.b*.a*.s*.JMDictQuery( 3654): Received 0 items; Lucene search 15ms / boost 
0ms / wrap 0ms

on my phone, it returns 2 results:
07-15 08:47:38.196  31073-31113/sk.baka.aedict3 I/s*.b*.a*.d*.CheckableL*﹕ 
Loader Query:JMDictQuery{本: jp:"W本W" OR jp:"W本W" OR jp:"W本W" OR 
jp:"W本W" exampleSearch=false analysisFallback=true}: returned 2 item(s) in 
1630ms


Original comment by martin.v...@gmail.com on 15 Jul 2014 at 7:00

Collaborator

GoogleCodeExporter commented Mar 14, 2015

Thanks for your patience and I am sorry for the inconvenience. Can you please 
contact me at vysny@baka.sk? I will send you an update version of Aedict which 
logs more verbosely. Perhaps we will find something.

However, there is something very weird going on: on your tablet the search for 
本 shows 0 results:
I/s*.b*.a*.s*.JMDictQuery( 3654): Running query jp:"W本W" OR jp:"W本W" OR 
jp:"W本W" OR jp:"W本W"
I/s*.b*.a*.s*.JMDictQuery( 3654): Received 0 items; Lucene search 15ms / boost 
0ms / wrap 0ms

on my phone, it returns 2 results:
07-15 08:47:38.196  31073-31113/sk.baka.aedict3 I/s*.b*.a*.d*.CheckableL*﹕ 
Loader Query:JMDictQuery{本: jp:"W本W" OR jp:"W本W" OR jp:"W本W" OR 
jp:"W本W" exampleSearch=false analysisFallback=true}: returned 2 item(s) in 
1630ms


Original comment by martin.v...@gmail.com on 15 Jul 2014 at 7:00

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 14, 2015

Collaborator
So, basically, if you try to search for 本 in Dict with exact matching, it 
should return exactly 2 results. On Galaxy Tab 3, it returns 0 results. I have 
also tried to force the en_US locale, perhaps it might help. But we need to 
test this. Please contact me and I will send you further instructions.

Original comment by martin.v...@gmail.com on 15 Jul 2014 at 7:02

Collaborator

GoogleCodeExporter commented Mar 14, 2015

So, basically, if you try to search for 本 in Dict with exact matching, it 
should return exactly 2 results. On Galaxy Tab 3, it returns 0 results. I have 
also tried to force the en_US locale, perhaps it might help. But we need to 
test this. Please contact me and I will send you further instructions.

Original comment by martin.v...@gmail.com on 15 Jul 2014 at 7:02

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 14, 2015

Collaborator
It is as I feared: on my phone and on any Android device *other* than Galaxy 
Tab 3, the query runs as follows:

 07-15 12:34:19.870  32226-32341/sk.baka.aedict3 I/s*.b*.a*.s*.JMDictQuery﹕ Running query jp:"W日本W" OR jp:"W日本W" OR jp:"W日本W" OR jp:"W日本W"
07-15 12:34:20.464  32226-32341/sk.baka.aedict3 I/s*.b*.a*.s*.JMDictQuery﹕ 
Received 1 items; Lucene search 593ms / boost 0ms / wrap 0ms

On Galaxy Tab 3, the query runs as follows:
07-15 11:30:21.470 I/s*.b*.a*.s*.JMDictQuery( 3356): Running query 
jp:"W日本W" OR jp:"W日本W" OR jp:"W日本W" OR jp:"W日本W"
07-15 11:30:21.480 I/s*.b*.a*.s*.JMDictQuery( 3356): Received 0 items; Lucene 
search 8ms / boost 0ms / wrap 0ms

I have no idea as to why this happens. The only way to solve this is to buy 
Galaxy Tab 3 and debug the Lucene library on that very tablet. This is not easy 
as the Lucene library is pretty complex... As a last resort, can you please try 
to switch the tablet to english (US)?
Regarding the tablet: is it this one? 
http://www.alza.sk/samsung-galaxy-t2100-tab-3-7-wi-fi-white-16gb-cz-d454740.htm

Original comment by martin.v...@gmail.com on 15 Jul 2014 at 10:56

Collaborator

GoogleCodeExporter commented Mar 14, 2015

It is as I feared: on my phone and on any Android device *other* than Galaxy 
Tab 3, the query runs as follows:

 07-15 12:34:19.870  32226-32341/sk.baka.aedict3 I/s*.b*.a*.s*.JMDictQuery﹕ Running query jp:"W日本W" OR jp:"W日本W" OR jp:"W日本W" OR jp:"W日本W"
07-15 12:34:20.464  32226-32341/sk.baka.aedict3 I/s*.b*.a*.s*.JMDictQuery﹕ 
Received 1 items; Lucene search 593ms / boost 0ms / wrap 0ms

On Galaxy Tab 3, the query runs as follows:
07-15 11:30:21.470 I/s*.b*.a*.s*.JMDictQuery( 3356): Running query 
jp:"W日本W" OR jp:"W日本W" OR jp:"W日本W" OR jp:"W日本W"
07-15 11:30:21.480 I/s*.b*.a*.s*.JMDictQuery( 3356): Received 0 items; Lucene 
search 8ms / boost 0ms / wrap 0ms

I have no idea as to why this happens. The only way to solve this is to buy 
Galaxy Tab 3 and debug the Lucene library on that very tablet. This is not easy 
as the Lucene library is pretty complex... As a last resort, can you please try 
to switch the tablet to english (US)?
Regarding the tablet: is it this one? 
http://www.alza.sk/samsung-galaxy-t2100-tab-3-7-wi-fi-white-16gb-cz-d454740.htm

Original comment by martin.v...@gmail.com on 15 Jul 2014 at 10:56

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 14, 2015

Collaborator
I have just saw the Aedict installation statistics and Aedict is actually 
installed on several Galaxy Tabs; nobody complained, so perhaps only a subset 
of these devices are not working correctly? I'm guessing german Galaxy Tabs as 
the only other user which complained was also user from Germany.

Original comment by martin.v...@gmail.com on 15 Jul 2014 at 11:01

Collaborator

GoogleCodeExporter commented Mar 14, 2015

I have just saw the Aedict installation statistics and Aedict is actually 
installed on several Galaxy Tabs; nobody complained, so perhaps only a subset 
of these devices are not working correctly? I'm guessing german Galaxy Tabs as 
the only other user which complained was also user from Germany.

Original comment by martin.v...@gmail.com on 15 Jul 2014 at 11:01

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 14, 2015

Collaborator
After a lot of trial and error, it seems that upgrading Lucene to 3.6.2 helped, 
for unknown reason. Thank you Marko for your kind testing :)

Original comment by martin.v...@gmail.com on 22 Jul 2014 at 8:27

Collaborator

GoogleCodeExporter commented Mar 14, 2015

After a lot of trial and error, it seems that upgrading Lucene to 3.6.2 helped, 
for unknown reason. Thank you Marko for your kind testing :)

Original comment by martin.v...@gmail.com on 22 Jul 2014 at 8:27

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 14, 2015

Collaborator
Okay, the problem persists even with Lucene 3.6.2. This is very weird:

D/s*.b*.a*.d*.LuceneSear*(26806): EXAMPLE_SENTENCES/tatoeba: Query jp:"本当" 
produced 0 results (result size was limited to 100) in 6ms; wrapped as 
ExamplesEntry
and
D/s*.b*.a*.d*.LuceneSear*(27486): EXAMPLE_SENTENCES/tatoeba: Query jp:"本當" 
produced 0 results (result size was limited to 100) in 26ms; wrapped as 
ExamplesEntry
produce absolutely NOTHING!
but
D/s*.b*.a*.d*.LuceneSear*(26286): EXAMPLE_SENTENCES/tatoeba: Query jp:"本当" 
OR jp:"本當" produced 100 results (result size was limited to 100) in 179ms; 
wrapped as ExamplesEntry
gets 100 results?

The first query is problematic: it should produce 100 results instead. I will 
implement a sanity checker which will run these problematic queries.

Original comment by martin.v...@gmail.com on 24 Jul 2014 at 5:27

Collaborator

GoogleCodeExporter commented Mar 14, 2015

Okay, the problem persists even with Lucene 3.6.2. This is very weird:

D/s*.b*.a*.d*.LuceneSear*(26806): EXAMPLE_SENTENCES/tatoeba: Query jp:"本当" 
produced 0 results (result size was limited to 100) in 6ms; wrapped as 
ExamplesEntry
and
D/s*.b*.a*.d*.LuceneSear*(27486): EXAMPLE_SENTENCES/tatoeba: Query jp:"本當" 
produced 0 results (result size was limited to 100) in 26ms; wrapped as 
ExamplesEntry
produce absolutely NOTHING!
but
D/s*.b*.a*.d*.LuceneSear*(26286): EXAMPLE_SENTENCES/tatoeba: Query jp:"本当" 
OR jp:"本當" produced 100 results (result size was limited to 100) in 179ms; 
wrapped as ExamplesEntry
gets 100 results?

The first query is problematic: it should produce 100 results instead. I will 
implement a sanity checker which will run these problematic queries.

Original comment by martin.v...@gmail.com on 24 Jul 2014 at 5:27

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 14, 2015

Collaborator
Marko:
 Running this code:
    String tou = "当";
    String hon = "本";
    String nichi = "日";
    Log.d("com.example.myfirstapp.compare", "Compate " + hon + " to " + nichi + ": " + hon.compareTo(nichi));
    Log.d("com.example.myfirstapp.compare", "Compate " + tou + " to " + nichi + ": " + tou.compareTo(nichi));
    Log.d("com.example.myfirstapp.compare", "Compate " + tou + " to " + hon + ": " + tou.compareTo(hon));
    Log.d("com.example.myfirstapp.compare", "Compate " + tou + " to " + tou + ": " + tou.compareTo(tou));

S3mini says:
07-30 18:22:59.297: D/com.example.myfirstapp.compare(15381): Compare 本 to 
日: 327
07-30 18:22:59.297: D/com.example.myfirstapp.compare(15381): Compare 当 to 
日: -1682
07-30 18:22:59.297: D/com.example.myfirstapp.compare(15381): Compare 当 to 
本: -2009
07-30 18:22:59.297: D/com.example.myfirstapp.compare(15381): Compare 当 to 
当: 0


Tab3 says:
07-30 18:23:10.250: D/com.example.myfirstapp.compare(31396): Compare 本 to 
日: -1
07-30 18:23:10.250: D/com.example.myfirstapp.compare(31396): Compare 当 to 
日: -1
07-30 18:23:10.250: D/com.example.myfirstapp.compare(31396): Compare 当 to 
本: 1
07-30 18:23:10.250: D/com.example.myfirstapp.compare(31396): Compare 当 to 
当: 0

Original comment by martin.v...@gmail.com on 31 Jul 2014 at 7:43

Collaborator

GoogleCodeExporter commented Mar 14, 2015

Marko:
 Running this code:
    String tou = "当";
    String hon = "本";
    String nichi = "日";
    Log.d("com.example.myfirstapp.compare", "Compate " + hon + " to " + nichi + ": " + hon.compareTo(nichi));
    Log.d("com.example.myfirstapp.compare", "Compate " + tou + " to " + nichi + ": " + tou.compareTo(nichi));
    Log.d("com.example.myfirstapp.compare", "Compate " + tou + " to " + hon + ": " + tou.compareTo(hon));
    Log.d("com.example.myfirstapp.compare", "Compate " + tou + " to " + tou + ": " + tou.compareTo(tou));

S3mini says:
07-30 18:22:59.297: D/com.example.myfirstapp.compare(15381): Compare 本 to 
日: 327
07-30 18:22:59.297: D/com.example.myfirstapp.compare(15381): Compare 当 to 
日: -1682
07-30 18:22:59.297: D/com.example.myfirstapp.compare(15381): Compare 当 to 
本: -2009
07-30 18:22:59.297: D/com.example.myfirstapp.compare(15381): Compare 当 to 
当: 0


Tab3 says:
07-30 18:23:10.250: D/com.example.myfirstapp.compare(31396): Compare 本 to 
日: -1
07-30 18:23:10.250: D/com.example.myfirstapp.compare(31396): Compare 当 to 
日: -1
07-30 18:23:10.250: D/com.example.myfirstapp.compare(31396): Compare 当 to 
本: 1
07-30 18:23:10.250: D/com.example.myfirstapp.compare(31396): Compare 当 to 
当: 0

Original comment by martin.v...@gmail.com on 31 Jul 2014 at 7:43

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 14, 2015

Collaborator
Samsung Germany has been notified of the issue.

Original comment by martin.v...@gmail.com on 1 Aug 2014 at 1:26

Collaborator

GoogleCodeExporter commented Mar 14, 2015

Samsung Germany has been notified of the issue.

Original comment by martin.v...@gmail.com on 1 Aug 2014 at 1:26

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 14, 2015

Collaborator
As per an email discussion with the developer, I believe this issue is limited 
to the Samsung Galaxy Tab 3 10.1" model (GT-P5210).  I have the 8" model 
(SM-T310) and I have not had any issues with with Aedict3 since purchasing it 
earlier this year (prior to v3.4.20, which is when the issue above was 
detailed).

Although I couldn't tell you why (other than "architectural 
differences"...endianness?) I believe the issue may stem from the fact that the 
10.1" model (GT-P5210) uses an Atom processor whereas the 7" and 8" models are 
ARM-based.

I have included the results from Settings > Expert > Self-test as requested:

---begin transcription---

All 15 tests ran OK

PASSED (448ms): examples query jp:本当: got 100 results, expected 100

PASSED (87ms): examples query jp:本當: got 0 results, expected 0

PASSED (211ms): examples query jp:本当 OR jp:ラララ: got 100 results, 
expected 100

PASSED (175ms): examples query jp:本当 OR jp:本當: got 100 results, 
expected 100

PASSED (127ms): ResolveKanjis{?}: got 1 results, expected 1

PASSED (33ms): ResolveKanjis{本}: got 1 results, expected 1

PASSED (29ms): ResolvedKanjis(当}: got 1 results, expected 1

PASSED (33ms): ResolveKanjis{本当}: got 2 results, expected 2

PASSED (77ms): KanjidicQuery{mother: pinyin:mother OR meanings:mother} got 11 
results, expected 11..20

PASSED (356ms): JMDictQuery{母: jp:W母W analysisFallback=false}: got 1 
results, expected 1

PASSED (495ms): JMDictQuery{to eat: sense:to AND sense:eat 
analysisFallback=false}: got 94 results, expected 90..130

PASSED (456ms): JMDictQuery{mother: sense:mother analysisFallback=false}: got 
138 results, expected 100..200

PASSED (234ms): JMDictQuery{本當: jp本 AND jp:當 analysisFallback=false}: 
got 1 results, expected 1

PASSED (267ms): JMDictQuery{バザー: jp:WバザーW analysisFallback=false}: 
got 1 results, expected 1

PASSED (117ms): SkipQuery{4-1-4}: got 7 results, expected 7

---end transcription---

I hope this helps anyone interested in using Aedict on Galaxy Tab devices in 
the 7" or 8" form factor, and perhaps in narrowing down the root cause of issue 
if possible.

Original comment by sixi...@gmail.com on 15 Sep 2014 at 1:17

Collaborator

GoogleCodeExporter commented Mar 14, 2015

As per an email discussion with the developer, I believe this issue is limited 
to the Samsung Galaxy Tab 3 10.1" model (GT-P5210).  I have the 8" model 
(SM-T310) and I have not had any issues with with Aedict3 since purchasing it 
earlier this year (prior to v3.4.20, which is when the issue above was 
detailed).

Although I couldn't tell you why (other than "architectural 
differences"...endianness?) I believe the issue may stem from the fact that the 
10.1" model (GT-P5210) uses an Atom processor whereas the 7" and 8" models are 
ARM-based.

I have included the results from Settings > Expert > Self-test as requested:

---begin transcription---

All 15 tests ran OK

PASSED (448ms): examples query jp:本当: got 100 results, expected 100

PASSED (87ms): examples query jp:本當: got 0 results, expected 0

PASSED (211ms): examples query jp:本当 OR jp:ラララ: got 100 results, 
expected 100

PASSED (175ms): examples query jp:本当 OR jp:本當: got 100 results, 
expected 100

PASSED (127ms): ResolveKanjis{?}: got 1 results, expected 1

PASSED (33ms): ResolveKanjis{本}: got 1 results, expected 1

PASSED (29ms): ResolvedKanjis(当}: got 1 results, expected 1

PASSED (33ms): ResolveKanjis{本当}: got 2 results, expected 2

PASSED (77ms): KanjidicQuery{mother: pinyin:mother OR meanings:mother} got 11 
results, expected 11..20

PASSED (356ms): JMDictQuery{母: jp:W母W analysisFallback=false}: got 1 
results, expected 1

PASSED (495ms): JMDictQuery{to eat: sense:to AND sense:eat 
analysisFallback=false}: got 94 results, expected 90..130

PASSED (456ms): JMDictQuery{mother: sense:mother analysisFallback=false}: got 
138 results, expected 100..200

PASSED (234ms): JMDictQuery{本當: jp本 AND jp:當 analysisFallback=false}: 
got 1 results, expected 1

PASSED (267ms): JMDictQuery{バザー: jp:WバザーW analysisFallback=false}: 
got 1 results, expected 1

PASSED (117ms): SkipQuery{4-1-4}: got 7 results, expected 7

---end transcription---

I hope this helps anyone interested in using Aedict on Galaxy Tab devices in 
the 7" or 8" form factor, and perhaps in narrowing down the root cause of issue 
if possible.

Original comment by sixi...@gmail.com on 15 Sep 2014 at 1:17

@GoogleCodeExporter

This comment has been minimized.

Show comment
Hide comment
@GoogleCodeExporter

GoogleCodeExporter Mar 14, 2015

Collaborator
Issue 437 has been merged into this issue.

Original comment by martin.v...@gmail.com on 2 Mar 2015 at 2:53

Collaborator

GoogleCodeExporter commented Mar 14, 2015

Issue 437 has been merged into this issue.

Original comment by martin.v...@gmail.com on 2 Mar 2015 at 2:53

@mvysny

This comment has been minimized.

Show comment
Hide comment
@mvysny

mvysny Mar 16, 2015

Owner

This bug can only be fixed at Samsung's side - I cannot override the String.compareTo() function which is internal and cannot be changed. Replacing all calls to String.compareTo() in Lucene would require very heavy patching and I don't even know if it is possible at all. Unfortunately, I have to mark this as won't fix.

Owner

mvysny commented Mar 16, 2015

This bug can only be fixed at Samsung's side - I cannot override the String.compareTo() function which is internal and cannot be changed. Replacing all calls to String.compareTo() in Lucene would require very heavy patching and I don't even know if it is possible at all. Unfortunately, I have to mark this as won't fix.

@mvysny

This comment has been minimized.

Show comment
Hide comment
@mvysny

mvysny Aug 23, 2015

Owner

To sum this up, GT-P5210 incorrectly compares Japanese strings, which confuses all libraries and causes all searches to return zero or weird results. This is definitely bug in GT-P5210's Android's String.compareTo(). I cannot create a workaround for such basic function as it is used heavily all over in Android.

Owner

mvysny commented Aug 23, 2015

To sum this up, GT-P5210 incorrectly compares Japanese strings, which confuses all libraries and causes all searches to return zero or weird results. This is definitely bug in GT-P5210's Android's String.compareTo(). I cannot create a workaround for such basic function as it is used heavily all over in Android.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment