• Status Closed
  • Percent Complete
  • Task Type Feature Requests
  • Category Rbutil
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by Peter D. - 2008-04-14
Last edited by Steve Bavin - 2008-04-21

FS#8886 - RockBox and Voice syncronisiation


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?

Closed by  Björn Stenberg

Reason for closing:  Fixed
Additional comments about closing:  

Closing all feature requests.

Linus Nielsen Feltzing commented on 2008-04-14 06:04

I think that’s a good idea.

Dominik Wenger commented on 2008-04-19 11:24

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.

Peter D. commented on 2008-04-19 12:27

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.

Dominik Riebeling commented on 2008-04-19 14:48

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.

Nils Wallménius commented on 2008-04-22 14:18

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…

Dominik Wenger commented on 2008-04-22 16:26

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.

Linus Nielsen Feltzing commented on 2008-04-22 19:14

The version number in the voice file is for the voice file format, and has nothing to do with the voice clips themselves.

Nils Wallménius commented on 2008-04-22 19:50

“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.

Dominik Riebeling commented on 2008-04-22 19:56

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.

Steve Bavin commented on 2008-04-23 05:44

I would suggest we warn (”Your voice file is outdated” clip and splash), then continue to play voice anyway - scrambled is better than none.

Hussein Patwa commented on 2009-08-19 15:45

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 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).


Available keyboard shortcuts


Task Details

Task Editing