Rockbox

I think that’s a good idea.

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.

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.

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.

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…

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.

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

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

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.

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

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