Rockbox

Tasklist

FS#8886 - RockBox and Voice syncronisiation

Attached to Project: Rockbox
Opened by Peter D. (PeterD) - Monday, 14 April 2008, 03:13 GMT
Last edited by Steve Bavin (pondlife) - Monday, 21 April 2008, 07:40 GMT
Task Type Feature Requests
Category Rbutil
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

Hi,

I have found that it is possible to upgrade RockBox, and not upgrade the Voice file. It causes menu reading to be hopelessly scrambled.

Can rbutil detect that a Voice file is installed?

If so, when a RockBox upgrade is done can the user be warned that there could be an incompatibility and suggest / force a matching update for the Voice file as well?
This task depends upon

Closed by  Björn Stenberg (zagor)

Reason for closing:  Fixed
Additional comments about closing:  Closing all feature requests.
Comment by Linus Nielsen Feltzing (linusnielsen) - Monday, 14 April 2008, 06:04 GMT
I think that's a good idea.
Comment by Dominik Wenger (Domonoky) - Saturday, 19 April 2008, 11:24 GMT
Yes this is a good idea.
But i am still thinking about how to best implement it.
At the moment rbutil doesnt know if it does a update or a first install, as it is normally the same.
So i am unsure where to put such a detection and warning.

Unfortunatly there is no good way to detect if a voicefile matches a installed build (no revision in the voicefile header), so the best we could do is a warning while installing rockbox.
Comment by Peter D. (PeterD) - Saturday, 19 April 2008, 12:27 GMT
I have not even attempted to look at the code - so feel free to tell me that I am completely wrong...

Can you just check for the existence of .rockbox/langs/<language>.voice when rbutil connects to the DAP and assume that is either RockBox or Voice is installed/upgraded the other should be too? Would checking the date of the file <language>.voice give enough information? Can a revision number be added to the voicefile header?

Failing all of that, a simple warning would be an improvement.
Comment by Dominik Riebeling (bluebrother) - Saturday, 19 April 2008, 14:48 GMT
I think it would be a much nicer solution to simply put the svn revision number / a version number somewhere in the header of the voice file like plugins do. Or put it at the end so it doesn't break compatibility until Rockbox itself does this detection.
Comment by Nils Wallménius (nls) - Tuesday, 22 April 2008, 14:18 GMT
The voice files actually have a proper version field and rockbox checks this, however when people make compatibility breaking changes they don't bump the version...
Comment by Dominik Wenger (Domonoky) - Tuesday, 22 April 2008, 16:26 GMT
Yes i have seen the version in the voicefile header.
But this Version is hardcoded in the voicefont tool. (at 4 at the moment)

Also its a bit hard to know when to update this version, as you change Lang files and not voicefiles.
But they still get incompatible because they are generated out of the langfile.
Comment by Linus Nielsen Feltzing (linusnielsen) - Tuesday, 22 April 2008, 19:14 GMT
The version number in the voice file is for the voice file format, and has nothing to do with the voice clips themselves.
Comment by Nils Wallménius (nls) - Tuesday, 22 April 2008, 19:50 GMT
"The version number in the voice file is for the voice file format, and has nothing to do with the voice clips themselves."

Sure, we could introduce another version field for whichever revision is the oldest it will work with (or use a similar scheme as plugins) or maybe mark lang files with a version and the voice must match that.

But this also brings up another issue, what should we do when the check fails, is it better for a blind user to have a partially scrambled (probably pretty confusing ui) or one that suddenly doesn't speak at all after an update? Maybe we could ship a single clip with rockbox that tells the user there's an error with the voice file in this case?

"Also its a bit hard to know when to update this version, as you change Lang files and not voicefiles."

We really shouldn't change lang files so that they become incompatible... which has become harder to keep track of because of the 'features' system.
Comment by Dominik Riebeling (bluebrother) - Tuesday, 22 April 2008, 19:56 GMT
No idea if this is feasible at all, but how about a "your voicefile is outdated" clip that is _always_ the first in the voice file? That way we don't need to ship another clip and can notify blind users.
Comment by Steve Bavin (pondlife) - Wednesday, 23 April 2008, 05:44 GMT
I would suggest we warn ("Your voice file is outdated" clip and splash), then continue to play voice anyway - scrambled is better than none.
Comment by Hussein Patwa (patwa) - Wednesday, 19 August 2009, 15:45 GMT
A long time since this was updated but it was in the TODO updated today. I'd agree that this needs to be looked at, as a few people have had this problem lately updating Rockbox after a while and using out of date voice files. Also, a poor voice is definitively better than none at all, as it at least gives the user some concept to work with as to where they are (from a VI user perspective). As for rbutil, it's not fully accessible to VI users atm but that idea is a good one. I woder if something could be done with the ..tools/configure script as well? It would need to map the voice file to an rb build, but tat would at least allow VI users to build their own files through the console which is accessible by all screen readers (that I know of).

Loading...