Eurobilltracker-site Feedback.

[MDeen]

When you click the link to show your hits with him, his name is shown as p€ñ𥣠while is proper name is P€ÑÐ¥£. So lowercase P, lowercase N-tilde and lowercase eth.
Other names are also converted to lowercase, but apparently the search algorithm can cope with this when normal characters are used.
So there are two ways of solving this:
1) don't convert names to lowercase (why is this done anyway?)
2) make sure the search algorithm is also case insensitive for special characters

[lmviterbo]

When you click the link to show your hits with him, his name is shown as p€ñ𥣠while is proper name is P€ÑÐ¥£. So lowercase P, lowercase N-tilde and lowercase eth.

At first thought, I figured this might be some confusion between the similar looking characters eth, D with stroke and African D. Well, it isn't. The problem is not a single character, because in other names all of these strange characters work well in searches.
The only search that doesn't work, as far as we know, is that name (P€ÑÐ¥£). In fact, P€Ñ or p€ñ isn't found using the search box. If you search for p€a, though, you'll find both P€ÑÐ¥£ and P€€T. Weird. So the problem should be related to the euro sign alone.

[eddydevries]

1) don't convert names to lowercase (why is this done anyway?)

My idea is (I don't know if it really is the reason) that if you don't convert, you won't find everything.

An example:
If you're searching now for "vibeuf", you will find now both the user (vibeuf) as the city (Vibeuf).
If the searching-name wasn't converted, I think you would only find the user (vibeuf) and not the city (Vibeuf), because the cityname starts with a capitol. To find the city you would have to search for "Vibeuf".

If this is true, this would be a reason to convert on purpose.
(Maybe the searchsystem doesn't recognize the Ñ als the capitol of ñ)

[ErGo]

Is it possible to create the note table from scratch?

There are some combinations, where the number in the table doesn't match any longer to the amount of notes behind (and no, its not a caching mechanism, because some of the differences exist for month) like:
D/X (6) - 2
E/T (37) - 30
F/U (379) - 100
F/X (60) - 38
G/N (218) - 147
G/V (255) - 40
G/P (290) - 128
and so on ...

(the number in the brackets are the number in the table, the number behind is the real amount of notes)

And if all the combinations with "0" disappear it is a positive side effect too

[dserrano5]

Is it possible to create the note table from scratch?

Not knowing the details, I'd say it's periodically created from scratch, based on how frequently it updates. Right now the footer says "cached (last update: Wed Feb 27, 18:38:30, next update in 34 hours)" (emphasis mine). The amount of time it takes until the next update suggests that it's a heavy operation, which in turn suggests that the entire database may be read to update the table.

Should this be true, a better solution would be to fix those entries wherever possible; too bad it's against EBT policy to edit note data.

[avij]

Is it possible to create the note table from scratch?

Yes, will be done. It pulls these figures from a "summary" table, which has apparently diverged from the truth over time. That table would need to be recreated from the main note entries table. Unfortunately this isn't a particularly quick operation, but I'll put this on my todo list. Getting rid of the zeroes was a quicker operation, you shouldn't see the zeroes after the next update.

[avij]

Is it possible to create the note table from scratch?

This has now been done. I tried to clear the cache as well, so the numbers should look a bit better now.

Edit: It appears that I'll need to regenerate another table to get the individual note listings working properly. The numbers in the table should now be correct, though. I'll save this task for some other night..

Edit 2: I found a script to regenerate that other table as well. Everything should be fine now regarding these lists.

[lmviterbo]

Here's some wonderful stats I'd love to see if it's not too difficult to get them done: what percentage of notes was registered with a wrong combination denomination/printer code/serial? (The basis can be the — as I'm writing, yet unfinished — amazing work that's been done by giulcenc. First post here.) My guess is that it's a really low number, around 0.3%.

Also, when the mere combination denomination/1st letter of printer code/1st letter of serial is not possible, it would be nice to see those figures in red on the note table. Or, probably better, since the good ones are the vast majority, it would be nice to see those highlighted.

[avij]

I'd like to get a statement from the Database WG regarding that proposal first. Sadly we need to deal with abuse, and it might be harmful to show to the abusers what we consider "incorrect". In an ideal world with zero abuse things would be much different..

[ErGo]

Here's some wonderful stats I'd love to see if it's not too difficult to get them done: what percentage of notes was registered with a wrong combination denomination/printer code/serial? [...]My guess is that it's a really low number, around 0.3%.

Its lower, its around 0,138%! The number of wrong combinations are about 160.000, and the number of entered notes is around 116.250.000.

As avij already mentioned, the entries of wrong combinations are an easy way for the database group to recognize fakers. But since this is only one of our methods and since there will be also a significant change with the new series of Euro-notes, where the character of the printercode will be the first character of the serialnumber, lets see, how the notes table will evolved.

[ErGo]

This has now been done. I tried to clear the cache as well, so the numbers should look a bit better now.

Thank you, but the results are a little bit odd.

Two examples:
D/L: 6 notes
before the recreation, the number in the notes table were also 6, but in the detail list were only the first 2 notes listed. Now, the value in the table is also 6 notes and in the list are 6 notes shown, so the result is now correct, but why were the other 4 notes not listed before?!

on the other side
E/T: 37 notes
The value in the table is with 37 unchanged. But before the rebuild, there were 32 notes in the list shown, now there are only 28 in the list. Some notes from 2007, which are still exist, are now not showing any more: #1, #2, #3.

But i know this is nut picking, so don't waste your time with it.

[avij]

MySQL is awfully slow when searching for entries like "printer code starts with E, serial number starts with T, denomination is 10". It would scan all the notes that have a T prefix in the serial number (some 1.5M at the moment), and then check if the other conditions also apply. To make these queries quite a lot faster, EBT keeps a separate list of recent entries for each type of note. This list is trimmed nightly to keep its size reasonable. When someone enters a large amount of unusual combinations that are later on fixed or deleted, the list of recent entries is unfortunately not replenished. This may cause some notes to not get listed, as they're no longer in the recent notes list. I've increased the size of the recent notes list a bit, so this problem should show up less often. There are other better solutions to this problem, but they'd require some more programming.

The above was the reason why the D/L notes were not previously shown on the list. As for the E/T notes, the "oldest" such note is note ID 40869313 (entry date 2006-03-19), but all the other notes in that note ID range were entered in early 2008 or so. So the date for that entry has been changed at some point. I don't know/remember the details, but most probably it was related to the .com/.eu split and the database merge that happened later on. In any case, the fact that the oldest entry does not also have the lowest note ID confuses some internals a bit. This is really a bug and it'd need to be fixed at some point.

[edit: bug fixed]

[ErGo]

Thank you for the explanation.

[lmviterbo]

Here's some wonderful stats I'd love to see if it's not too difficult to get them done: what percentage of notes was registered with a wrong combination denomination/printer code/serial? [...]My guess is that it's a really low number, around 0.3%.

Its lower, its around 0,138%! The number of wrong combinations are about 160.000, and the number of entered notes is around 116.250.000.

Wow, great, thanks! (My interpretation for the lower-than-I-expected figure: ebters are generally young and do not need glasses as much as I do to read the printer code. )

[Moise]

Today entering of brandnew notes doesnt work.When entering in the "Defaults" fields,it only copies the values when adding one or two "space"s.Ofcourse that doesnt work in the printercode field
Probably happened,because of adjusting site for new
IE9