Display or DBase issue? Retrieval of data
Running Ubuntu 13.10, Gourmet 0.16.1 and MySQL server 5.1.73 on a remote server (LAN).
I have setup Gourmet Recipe Manager so it stores its data through MySQL on a remote server, accessible for multiple clients.
Entering data works like a charm. I can easily add recipies that are then stored in the database. Using MySQL Workbench under Linux, as well as through phpmyadmin, I can verify that all data is correctly stored in the correct collation.
However, when I open recipe cards, some will not show all the data (often the preparation method is not visible, less often the instructions AND the ingredients, even less often nothing at all), some will open up perfectly, showing all the data previously entered. What I do notice is that the application remains seems to be busy (I see Ubuntu's equivalent of the hour glass). Interestingly enough, they are always the same recipies that show up perfectly as well as the same recipies that seem to be missing data... (consistent behaviour).
Then, thinking I might have forgotten to add the instructions, when I try to change instructions (or ingredients for that matter), the window that opens does not show all the tabs the "original" window showed when I entered the data, so there is for example no tab to add/alter instructions.
However, if I add ANY recipe to the grocery list (my most important requirement), that works perfectly, even if the recipe card does not display ANY info (no title, no ingredients, no instructions). Again: all the data that is not showing is perfectly stored in the MySQL database and seems to be queried correctly once I add a recipe to the grocery list.
What am I overlooking here? Do not hesitate to ask for error logs (if any exist; where would I find those?).
Thanks for your response!
Question information
- Language:
- English Edit question
- Status:
- Solved
- For:
- Gourmet Edit question
- Assignee:
- No assignee Edit question
- Solved by:
- Harald Franzen
- Solved:
- Last query:
- Last reply:
Revision history for this message
|
#1 |
Please run gourmet from a Terminal, try to reproduce those issues you described, and paste the error messages you get on the terminal here.
Revision history for this message
|
#2 |
Thanks, Bernhard! I should have thought of that myself :-(
This is what I did:
gourmet --database-
The program started and in the recipe list, I browsed one page to open the recipe card for one of the recipes I knew would show the issue. I opened this one recipe, then closed it and closed the program.
Below, I have posted both the terminal output as well as the contents of "Gourmet.log" (see the command above).
I left out the login information out of the logs, but both registered it correctly in compliance with the (anonymised) version above.
The logs show at least an issue with utf-8 encoding. As an example in the terminal output:
[quote]
GError: Fout in regel 1 teken 722: Ongeldige UTF-8-gecodeerde tekst - niet geldig
[/quote]
Which, translated into English, would read something like
"GError:Error in line 1 character 722: Invalid UTF-8-encoded text - invalid".
But also color marking goes awry (if an instruction contains, "cook for 10 minutes", I noticed the software will add a hyperlink to the countdown-timer and will effectively mark it as such (color blue and underline):
[quote]
/usr/lib/
[/quote]
"Kleur" is Dutch for color.
At the end of "Gourmet.log", there's a problem with "Escaping text".
Anyway, we do use heaps of those diacritical characters like ë é è ê à and so on, both in Dutch (our native language) as well as in some of the recipes, like the French "vélouté de cèpes" :-)
A work around could be to remove all those, but I wonder why on input all goes well and on output it doesn't.
I do apologize for the horrid mix of English, French and Dutch below!
Best regards,
Harald
This is the terminal output:
/usr/lib/
self.
/usr/lib/
'search_
/usr/lib/
'search_
/usr/lib/
'search_
/usr/lib/
'search_
/usr/lib/
'search_
/usr/lib/
'search_
/usr/lib/
'search_
/usr/lib/
'search_
/usr/lib/
gtk.main()
/usr/lib/
self.
/usr/lib/
'edit_
/usr/lib/
self.
Traceback (most recent call last):
File "/usr/lib/
self.
GError: Fout in regel 5 teken 16: Ongeldige UTF-8-gecodeerde tekst - niet geldig ‘600 g c�pes
3 stuks knoflookteen
60 g boter (zout)
15 cl slagroom
5 cl olijfolie’
Traceback (most recent call last):
File "/usr/lib/
module.
File "/usr/lib/
self.
File "/usr/lib/
self.
File "/usr/lib/
PangoBuffer
File "/usr/lib/
self.
GError: Fout in regel 5 teken 16: Ongeldige UTF-8-gecodeerde tekst - niet geldig ‘600 g c�pes
3 stuks knoflookteen
60 g boter (zout)
15 cl slagroom
5 cl olijfolie’
/usr/lib/
self.
Traceback (most recent call last):
File "/usr/lib/
self.
GError: Fout in regel 5 teken 16: Ongeldige UTF-8-gecodeerde tekst - niet geldig ‘600 g c�pes
3 stuks knoflookteen
60 g boter (zout)
15 cl slagroom
5 cl olijfolie’
Traceback (most recent call last):
File "/usr/lib/
self.
File "/usr/lib/
self.
File "/usr/lib/
PangoBuffer
File "/usr/lib/
self.
glib.GError: Fout in regel 5 teken 16: Ongeldige UTF-8-gecodeerde tekst - niet geldig ‘600 g c�pes
3 stuks knoflookteen
60 g boter (zout)
15 cl slagroom
5 cl olijfolie’
Traceback (most recent call last):
File "/usr/lib/
self.
GError: Fout in regel 1 teken 722: Ongeldige UTF-8-gecodeerde tekst - niet geldig ‘S�parer la t�te du pied des c�pes. A l�aide de papier absorbant, essuyer le chapeau. Retirer l�extr�mit� du pied et l��plucher finement. D�tailler les champignons en d�s. Hacher l�ail.Dans une po�le antiadh�sive faire suer les champignons avec un peu d�huile. Egoutter. Mettre � cuire les champignons dans une po�le, ajouter l�ail, le sel et le poivre. Laisser revenir environ 5 mn puis couvrir d�eau froide. Porter � �bullition puis laisser cuire environ 20 mn � feu moyen, en couvrant la casserole.A la fin de la cuisson, mixer une premi�re fois. Hors du feu, ajouter la cr�me et une noix de beurre. Mixer � nouveau jusqu�� obtenir un m�lange onctueux. Laisser mijoter environ 5 mn � feu tr�s doux.Servir chaud.’
Traceback (most recent call last):
File "/usr/lib/
w=reccard.
File "/usr/lib/
self.show()
File "/usr/lib/
self.
File "/usr/lib/
self.
File "/usr/lib/
self.
File "/usr/lib/
widg.
File "/usr/lib/
make_
File "/usr/lib/
PangoBuffer
File "/usr/lib/
self.
glib.GError: Fout in regel 1 teken 722: Ongeldige UTF-8-gecodeerde tekst - niet geldig ‘S�parer la t�te du pied des c�pes. A l�aide de papier absorbant, essuyer le chapeau. Retirer l�extr�mit� du pied et l��plucher finement. D�tailler les champignons en d�s. Hacher l�ail.Dans une po�le antiadh�sive faire suer les champignons avec un peu d�huile. Egoutter. Mettre � cuire les champignons dans une po�le, ajouter l�ail, le sel et le poivre. Laisser revenir environ 5 mn puis couvrir d�eau froide. Porter � �bullition puis laisser cuire environ 20 mn � feu moyen, en couvrant la casserole.A la fin de la cuisson, mixer une premi�re fois. Hors du feu, ajouter la cr�me et une noix de beurre. Mixer � nouveau jusqu�� obtenir un m�lange onctueux. Laisser mijoter environ 5 mn � feu tr�s doux.Servir chaud.’
/usr/lib/
widget.
This is the output in "Gourmet.log"
We have a db_url and it is, mysql:/
Problem encountered escaping text: "Doe alle ingrediënten in de kom van bijvoorbeeld een KitchenAid of broodbakmachine. Kneed er in ongeveer <span underline="single" color="blue">10 minuten</span> een soepel deeg van. Overdoen in een ingevette kom.1e rijs: <span underline="single" color="blue">1 - 1 1/2 uur</span>.Verdeel dan met een deegsteker het deeg in 12 - 14 gelijke stukjes en maak er bolletjes van. Leg ze op een bakplaat.2e rijs: ongeveer <span underline="single" color="blue">1 uur</span>.Verwarm tijdens het laatste kwartier van de rijstijd de oven voor op 200 °C. Bestrijk voor 'boterbolletjes' de gerezen bolletjes met gesmolten roomboter, voor 'zadenbroodjes' bestrijken met losgeklopt ei/melkmengsel en bestrooien met sesamzaad of maanzaad.In <span underline="single" color="blue">12 - 15 minuten</span> gaar en bruin bakken. Bestrijk de 'boterbolletjes' direct na het afbakken weer met gesmolten roomboter. Af laten koelen op een rooster."
Problem encountered escaping text: "100 g zalm, gerookt
20 g spinazie, blad
75 g kruidenkaas
1 eetlp. bieslook
2 eetlp. crème fraîche"
WARNING: Exception raised by <gourmet.
Problem encountered escaping text: "100 g zalm, gerookt
20 g spinazie, blad
75 g kruidenkaas
1 eetlp. bieslook
2 eetlp. crème fraîche"
Problem encountered escaping text: "Meng een Boursin 2 lepels crème fraîche en wat bieslooksnippers tot een smeuïge, homogene mengeling.Leg de plakjes zalm uit en leg er wat blaadjes spinazie in.Leg nu de mengeling van de Boursin er op.Rol de zalm op met behulp van bakpapier en leg de rollen, gewikkeld in het papier, enkele uren in de diepvriezer.Even voor het serveren haalt u de rollade uit de diepvriezer en snijdt u er kleine rondjes van.Leg de hapjes op een schotel en versier met enkele snippers sinaasappelschil of wat bieslook"
Revision history for this message
|
#3 |
Just to add a little word.
I had one recipe in English (usually without é, è and so on), that didn't show its instruction properly. Using appropriate database tools, I found out that the very last sentence was in Dutch, using the word "ingrediënten" (note the ë in there). Replaced it with a normal e and voilà; it turns op perfectly.
Also, the issue of not being able to edit the instructions and/or not getting the various tabs on the recipe card whilst editing, had been resolved for that recipe.
So the diacritical marks seem to be the culprit. The MySQL-collation is: UTF-8 Unicode (utf8), the MySQL connection collation: utf8_general_ci and the database tables: utf8_general_ci.
Revision history for this message
|
#4 |
And here the locale settings for the local workstation:
LANG=nl_NL.UTF-8
LANGUAGE=
LC_CTYPE=
LC_NUMERIC=
LC_TIME=nl_NL.UTF-8
LC_COLLATE=
LC_MONETARY=
LC_MESSAGES=
LC_PAPER=
LC_NAME=nl_NL.UTF-8
LC_ADDRESS=
LC_TELEPHONE=
LC_MEASUREMENT=
LC_IDENTIFICATI
LC_ALL=
Revision history for this message
|
#5 |
It seems from this thread like the recipes are being stored correctly but
storage is breaking with unicode pulled from MySQL -- is that right? Can
you confirm that the MySQL DB has the information stored in it perchance?
The other thing you could do to check is try accessing those recipes in
another way -- printing or exporting them, for example, or using the
experimental web-based interface if that's packaged w/ Gourmet (I forget if
it's in the plugins directory we ship out or not). There's a decent chance
one of those methods will display the data that gets broken on the way to
the GUI, though of course that depends on where the bug is occurring. I can
confirm that using the SQLite database, I am able to save and display
accented characters w/ no problem.
Tom
On Fri, Feb 7, 2014 at 11:31 AM, Harald Franzen <
<email address hidden>> wrote:
> Question #243472 on Gourmet changed:
> https:/
>
> Harald Franzen gave more information on the question:
> And here the locale settings for the local workstation:
> LANG=nl_NL.UTF-8
> LANGUAGE=
> LC_CTYPE=
> LC_NUMERIC=
> LC_TIME=nl_NL.UTF-8
> LC_COLLATE=
> LC_MONETARY=
> LC_MESSAGES=
> LC_PAPER=
> LC_NAME=nl_NL.UTF-8
> LC_ADDRESS=
> LC_TELEPHONE=
> LC_MEASUREMENT=
> LC_IDENTIFICATI
> LC_ALL=
>
> --
> You received this question notification because you are a member of
> Gourmet Recipe Manager, which is an answer contact for Gourmet.
>
Revision history for this message
|
#6 |
Thank you Tom!
You pointed in the right direction so I managed to resolve it. The cause is in the MySQL server settings.
This might touch other users too choosing a MySQL-database for Gourmet, so I will post the solution here for those users that run into the same trouble. Feel free to reuse in wiki or FAQ.
This solution is at least valid for the following configuration:
Gourmet 0.16.1
Client: Ubuntu 13.10
Server: Ubuntu 10.04.4 LTS
MySQL-server: 5.1.73 on a remote server (Ubuntu 10.04.4 LTS).
By default, a MySQL server, once installed, will use the latin1-collation as the server collation. Even if all other collations are set to utf8, you might suffer when using diacritical marks, like é ö à when using a MySQL database for Gourmet.
Open an appropriate tool for your MySQL-database like phpmyadmin and execute the following query:
[code]
SHOW VARIABLES LIKE 'char%';
[/code]
The output will look like this:
[code]
+------
| Variable_name | Value |
+------
| character_
| character_
| character_
| character_
| character_
| character_
| character_
| character_sets_dir | /usr/share/
+------
8 rows in set (0.00 sec)
[/code]
Note the variable: "| character_
In Ubuntu (use appropriate commands for your OS) login to the server environment (via SSH for example) and execute the following command to stop the MySQL-server. I have posted the commands for an Ubuntu server below; use appropriate commands for your server-OS.
[code]
sudo service mysql stop
[/code]
Edit the my.cnf file:
[code]
sudo nano /etc/mysql/my.cnf
[/code]
Find the section named [mysqld] and add the following:
[code]
character-
skip-character-
[/code]
Save my.cnf
Start the server:
[/code]
service mysql start
[code]
Verify the changed setting by executing the same query:
[code]
SHOW VARIABLES LIKE 'char%';
[/code]
Job done! Gourmet should now now longer struggle displaying diactritical marks.
Revision history for this message
|
#7 |
Now the issue seems to be reversed; stored recipes with diacritical marks work perfectly, but I cannot seem to store recipes with diacritical marks :-(
I will investigate and see if I can find out why...
Revision history for this message
|
#8 |
These are the errors I am getting when entering diactritical marks and trying to save. Suggestions are welcome:
/usr/lib/
cursor.
/usr/lib/
cursor.
/usr/lib/
cursor.
Revision history for this message
|
#9 |
And the solution is to force the connection to use utf8, so your connect string for Gourmet should read:
gourmet --database-
where, USER, PASSWORD, SERVER and DATABASENAME are your specific parameters.
Revision history for this message
|
#10 |
Good thing you solved it yourself! Now ideally, I'd like to solve this by programmatically forcing that setting, but of course, we have no influence on people's MySQL collation settings. Could you check if it also works if you reset those to latin1?
-------- Ursprüngliche Nachricht --------
Von: Harald Franzen <email address hidden>
Datum:
An: <email address hidden>
Betreff: Re: [Question #243472]: Display or DBase issue? Retrieval of data
Question #243472 on Gourmet changed:
https:/
Status: Open => Solved
Harald Franzen confirmed that the question is solved:
And the solution is to force the connection to use utf8, so your connect
string for Gourmet should read:
gourmet --database-
url=mysql:
where, USER, PASSWORD, SERVER and DATABASENAME are your specific
parameters.
--
You received this question notification because you are a direct
subscriber of the question.
Revision history for this message
|
#11 |
BTW, as for that "kleur" issue, that's a bug in the Dutch translation file (where someone accidentally translated HTML attribute names and values to Dutch). Fixed now by https:/
Revision history for this message
|
#12 |
Hello Bernhard,
There were TWO issues involved.
The first is the MySQL-setting, that should be resolved in ANY utf-8 environment. The reason for the latin1 as the server collation is a silly one; originally, MySQL was developed by a Swedish company, and they used latin1 for their diacritical marks. The web has 100s of pages on this issue, but one is used to find most stuff in utf8 these days, so one tends to overlook it.
The second issue was the parsing of the text by SQLAlchemy; it doesn't use utf-8 by default, but unicode (if I have understood correctly; I am not a programmer). This discrepancy causes the requirement to force the engine to use utf8 on startup.
Only then is all the traffic between the application and the data store streamlined into utf8 only and all will work correctly.
It would be a long shot trying to solve this programmatically (not trying to diminish your capabilities); once a user starts deploying a MySQL database for Gourmet (as opposed to a user that will be happy to do the standalone using SQLAlchemy and the default SQLite3 database), they will be probably be sufficiently adept to follow the necessary instructions to correctly setup those two parameters.
A good FAQ should do the trick, I think :-)
Can I assist with the Dutch translations in any way? There's a little typo when you edit a recipe: the button to edit the notes reads "Notiities bewerken" (the English will probably read: "Edit notes"). That's a small typo: it should read "Notities bewerken" (note on 'i' less in the correction). There's also a few translations missing here and there.
Revision history for this message
|
#13 |
Sorry, I didn't make myself clear enough. I was curious if things would keep working for you if you kept the charset=utf8 SQLAlchemy connection parameter, but switched back MySQL's character_
As for translating, help is greatly appreciated! Our translations are actually done here on Launchpad (see the "Translations" link on top of this page -- Dutch would be at https:/
Revision history for this message
|
#14 |
That is fair comment Bernhard. I stand corrected.
I reverted the server back to the original settings, so the variable "character-
Then I started Gourmet with the connect string forcing the utf8 collation and then it works perfectly as well.
Tried entering a test recipe with heaps of ééé and àà and so on and it stores correctly in the MySQL database and is retrieved correctly as well.
Again, I am not a programmer, but maybe forcing utf8 in the connect string will cause issues for those that are not in a utf8-environment?
As for the translations: I'll make sure to give it a go. There seems to have been a Flemish person involved in translating too, because I see plenty of terms that are actually Flemish, not Dutch. Strangely enough, we share the same dictionary, but the languages are not entirely identical; much like British English and American English. Are there any guidelines I should follow? For example, I see an ingredient named "witloof" (which is very Flemish) which in Dutch (and in our shared dictionary of the Dutch language) is actually called "witlof" (so one "o" less). We'd all understand the term, but Dutch would either see this as a spelling error or understand it's a Belgian that did the translating :-) Same for "selder" which would read "selderij" in Dutch.
As I have a practical use case for this software, I might be able to give you some input as well on the user-side of things as well; let me know -maybe through PM- if you guys would be interested.
Cheers,
Harald
Revision history for this message
|
#15 |
Thanks for testing! You're right, we need to make sure that forcing utf8 won't cause any issues, but I'm optimistic that it will work (I'll try it with the default SQLite backend for starters).
As for the Dutch/Flemish situation, that's something very familiar for this Austrian ;-) Fortunately, that's something that gettext (the underlying translation framework) supports, and we even have nl_BE.po (and de_AT.po) files (in https:/
So what you could do instead for now is install a translation files editor like poedit (which is what I use) from the Ubuntu Software Center and work on nl.po directly (don't use nl_NL.po, I'd like to remove that one -- as well as e.g. de_DE.po and pt_PT.po -- as those are redundant). Are you familiar with git? Ideally you could fork the git repo on GitHub and clone it locally, work on the file, push it to your fork and submit pull requests. But if that whole git workflow is new to you, I don't want to force it on you -- you can just download the current nl.po from the GitHub location noted above, work on it, and send it to me.
I'm very interested in field experience from users -- feel free to either PM me, or maybe better yet, sign up for our team and (very, very low traffic) mailing list at https:/
Revision history for this message
|
#16 |
Now about those Flemish or German Austrian translations not showing up in Launchpad, that's really strange as they are apparently there -- they're just not listed, see e.g. https:/
(Just posted https:/