FS#7556 - Initial display of menu during playback is not spoken
I encountered several bugs that were introduced by/after the new voicefiles. Fixing these bugs would certainly improve the usability of Rockbox.
- The voice that is used in the daily builds says the letter A as in “a file”, whereas it should spell it like in “ABC”. A fix for the pronunciation can solve this issue, if this is available under Linux(?).
- Entering the main menu (pressing the Record button) while playing a file seems to do nothing. But strangely enough it opens the menu after three presses. When the menu has been opened once, the Record button suddenly behaves normally. But as soon as you change directory it breaks again.
- Pressing Long Record during playback caused my player to crash and after rebooting the whole configuration(file) was reset to the default settings. I haven’t been able to reproduce this bug yet though.
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
I modified the summary to make sense:
The fact that the voice may sound funny or whatever is something you should bother the speech synthesis makers with and is not a Rockbox bug.
“The fact that the voice may sound funny or whatever is something you should bother the speech synthesis makers with and is not a Rockbox bug.”
Yes, but as I understood from the voice howto it is possible to adapt the pronunciation (at least under Windows). A bad voicefile can be rather annoying, so why not fix it if it’s possible? But if it’s really hard to do then just keep it this way…
I believe you’re referring to a howto that explains how to generate the voice files under windows. These ones are generated on Linux using Festival and I’m not aware of any particular tweaks to make it sound better.
Ah well, never mind. I’ll just attempt to create my own voicefile under Windows (if I can get voicefont to work again).
It would be great to have the other bugs fixed though. :)
Some more ifno:
It seems that the menu opens correctly when you press the Record button, but without any voice support. When you return to the WPS and try again Rockbox will be talking as usual.
This is starting to get confusing (and is why multiple bugs in one entry is a bad idea to start with).
Are you saying that #2 in your original report no longer is like you described it there then? I take it the #3 crash still happens?
I thought there happened nothing when you pressed the Record button while playing, since I only used the voice (not the LCD). But I suppose it goes into the menu, so it should be a voice issue. This applies to #2.
For #3: I haven’t been able to reproduce this error and I’m not sure what caused it. So the only really problem is #2.
I’ll do some more testing this afternoon…
After some testing it appears that this problem is introduced on 06-Aug-2007. Could it be in this file:
http://svn.rockbox.org/viewvc.cgi/trunk/apps/talk.c?view=log&pathrev=14221
By the way, can I get earlier SVN builds, so I can test more than one build of that day to see which change causes the trouble?
I can reproduce a similar problem in the simulator. Basically after you first start playback, pressing the MENU button returns you to the menu but doesn’t talk. Pressing MENU again to return to the WPS, followed by a third time back to the menu does talk ok.
After browsing the changelogs, I think this bug is caused by (a wrong implementation of) this functions:
http://svn.rockbox.org/viewvc.cgi/trunk/apps/talk.c?r1=13584&r2=13615&pathrev=14221&diff_format=u
Also, I’d like to suggest more hardcoded functions. In stead of “talk_menu_disable++;” it could be “talk_menu_disable = 1;”. This to prevent errors when the talk_enable_menus-function is called more than once.
No, that needs to allow for multiple overlapping “disables”, and it should only start talking when all corresponding “enables” have occurred.
Right, but could this be the error? Like one missing disable or one too many somewhere else in the code?
Davy,
I just retested this and it seems to be fixed here. Please retest and let us know if you still see the problem. If not, I’ll close this as Fixed.
I tested it on my iAudio X5 and it indeed seemed to work normally. Thus I request the closing of this bug. :)