Kodi Community Forum

Full Version: Xbmc not working for blind users.
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
A friend of mine told me that the Windows installer didn't work for him. He's on Windows 8 and he just got this machine recently. I guess everything seems to install properly but he gets no speech. I decided that since I have been with this project since the beginning, it was a good idea to try and install with the installer too. I happen to be on a WinXP machine right now. I installed XBMC and the TTS, but I checked the launch XBMC checkbox before I realized that XBMC TTS Installer wanted me to reboot. So, I arrowed around, had no speech, so I went into Enabled Addons and selected Auto as it didn't have a default voice selected out of the box. I then exited XBMC and noticed the installer wanted a reboot. So I rebooted and launched XBMC and still got no speech. However, this time I was greeted with an error that said "Script Failed: Main.py." I don't know if this is the same error that my friend had but the result was the same, no speech. I tried launching with Auto selected using SAPI, JAWS and NVDA. Any ideas?
(2014-04-17, 22:00)byron27 Wrote: [ -> ]A friend of mine told me that the Windows installer didn't work for him. He's on Windows 8 and he just got this machine recently. I guess everything seems to install properly but he gets no speech. I decided that since I have been with this project since the beginning, it was a good idea to try and install with the installer too. I happen to be on a WinXP machine right now. I installed XBMC and the TTS, but I checked the launch XBMC checkbox before I realized that XBMC TTS Installer wanted me to reboot. So, I arrowed around, had no speech, so I went into Enabled Addons and selected Auto as it didn't have a default voice selected out of the box. I then exited XBMC and noticed the installer wanted a reboot. So I rebooted and launched XBMC and still got no speech. However, this time I was greeted with an error that said "Script Failed: Main.py." I don't know if this is the same error that my friend had but the result was the same, no speech. I tried launching with Auto selected using SAPI, JAWS and NVDA. Any ideas?

I'll have to do some testing on the windows machines I have access to. There's too many variables involved for me to guess at the error Smile
I'll let you know what I find.
It looks like I added some dependencies to the addon and forgot to update the installer to install them. This doesn't cause an error if a previous addon install already trigger an install of the dependency, so it won't always cause the error. I'll fix it Smile
The installer is fixed and should work now.

I tried using the new F12 to disable on Windows 8 and it caused XBMC to freeze. Disabling with the 'Disable' button works fine. I'll have to look into what the deal is.
Looks like using F12 to disable only freezes on Frodo. Must be a bug that was fixed. I'll put some code to test for XBMC version. That means it will only work on Gotham.
ruuk:

I've done some more testing/troubleshooting with regard to the problem I had when first installing 0.0.37 and xbmc completely crashing when it tried to connect to localhost and got a connection refused.

As I expected, with the correct IP set, xbmc also will crash in the same way if I stop the wavserver causing xbmc to get a connection refused again.

I messed around a bit with the code that writes the wav from the remote server and came to the conclusion that once the runCommand() method finishes, if there was a problem, then xbmc ends up trying to play a broken/empty .wav file and that's where it all goes to hell.

So I split the wav writing into two steps. The reading from the remote server, and then the writing, and made runCommand return True or False accordingly, then edited base.py and had it check the return code for runCommand and only go on to try and play the sound if it was True.

This has solved the crashing issue, and speech resumes again as soon as I restart the wavserver.

From what I can tell, the reason my original ttsd backend didn't cause this problem was because I didn't have any exception trapping, so an exception would be thrown and the addon would just completely die and xbmc would never try and play the broken/empty .wav, but I'd also need to reboot/jump through other hoops to get the addon running again.

Anyway, hope this helps.
Added a new version to my repository: 0.0.40.

Get it or the repository from the Downloads Page.

Changes v0.0.40:
  • Fix for XBMC version detection

Changes v0.0.39:
  • HTTP Speech Wav Server backend will no longer crash XBMC on server errors
  • HTTP Speech Wav Server backend will now drop to a fallback backend on errors
  • Using F12 key now requires Gotham or greater for disabling/enabling
  • Removed the memory fix setting from Advanced - addon now checks XBMC version
I have now acquired a github account and the wavserver (httpttsd) can be found there.

My repo is: https://github.com/sjhoran/httpttsd

I've cleaned it up a bit since I first shared it here.

ruuk: Feel free to add it to your downloads page.

I'm still very new to git, so please also let me know if I've made any glaring omissions.
@@
Hi,

There seems to be a bug in the latest revisions. I haven't tried 0.0.39, but it's there in .40 and .41. I suspect it's related to your playsfx fix.

On my raspberry pi, running OpenELEC 3.95.5, I just get the same thing spoken over and over again, typically "Window: Home" as tht's the first thing said upon startup.

I can see that the wavserver is receiving requests for the correct things and sending them back, and I can even see that the wav files being created are right (I copied a couple and manually checked).

I changed to the espeak backend and the problem persisted. It did however switch to espeak first, but then repeated the first thing said with that engine.

Don't have the time right now to take an in depth look to see if I can spot what's going on with this. Hopefully you'll read this and it'll be immediately obvious.

Another interesting quirk is that after I changed to espeak and it kept repeating "addon information" as that's the first thing said after going "OK", I went back into configure and switched back to ttsd, went OK, and it started repeating "Window: Home" again, which suggests whatever caching oddness is going on is engine bound.

Let me know if there's anything you'd like me to do to test.

Hope you're having a good weekend.
(2014-04-19, 22:26)eckythump Wrote: [ -> ]I have now acquired a github account and the wavserver (httpttsd) can be found there.

My repo is: https://github.com/sjhoran/httpttsd

I've cleaned it up a bit since I first shared it here.

ruuk: Feel free to add it to your downloads page.
Will do.
(2014-04-19, 22:26)eckythump Wrote: [ -> ]I'm still very new to git, so please also let me know if I've made any glaring omissions.
I've been using it for a year, and there's still a lot I don't know Smile
But the basics aren't too bad. I just use everything else infrequently enough that I forget it by the time I need it again.
(2014-04-20, 05:26)eckythump Wrote: [ -> ]There seems to be a bug in the latest revisions. I haven't tried 0.0.39, but it's there in .40 and .41. I suspect it's related to your playsfx fix.

On my raspberry pi, running OpenELEC 3.95.5, I just get the same thing spoken over and over again, typically "Window: Home" as tht's the first thing said upon startup.

I can see that the wavserver is receiving requests for the correct things and sending them back, and I can even see that the wav files being created are right (I copied a couple and manually checked).

I changed to the espeak backend and the problem persisted. It did however switch to espeak first, but then repeated the first thing said with that engine.

Don't have the time right now to take an in depth look to see if I can spot what's going on with this. Hopefully you'll read this and it'll be immediately obvious.

Another interesting quirk is that after I changed to espeak and it kept repeating "addon information" as that's the first thing said after going "OK", I went back into configure and switched back to ttsd, went OK, and it started repeating "Window: Home" again, which suggests whatever caching oddness is going on is engine bound.
Well, it's not related to the fix, I think, so much as it's related to my detection of when to use the fix.

When using XBMC to output speech, the addon uses xbmc.playSFX() to play the wavs. playSFX() was designed just to load a few sound effects, and it caches the wav for quick playback. So the first problem with this for the addon was that if you play a wav with the same file name, it will just use the cached wav. To overcome this I created each wav with a different file name. This quickly led me to discover that the wav cache is never cleared (other than on a skin change) and so it basically just keeps filling memory. So what the fix does is add a useCached parameter to playSFX() that when set to False, will dump the cached wav and play the new one instead.
When using this fix, the same file name is used (otherwise you would still be adding cached wavs, not to mention this is more convenient). Now if you're using a version that doesn't have the fix and the addon thinks it does, it will use the same file name and you will get the behavior you described.
I'm not sure why it was speaking Window: home again after you changed the engine, but it's probably related to whatever I did wrong in detecting the presence of the fix.
I'll look at it and see what's wrong.

I just got my Raspberry Pi a couple of days ago and originally tested these versions with OpenELEC 3.95.6 and it worked fine.
(2014-04-19, 22:28)VIJO Wrote: [ -> ]So I have been playing with it a lot lately. Currently using latest Gotham Beta and Your TTS add on with NVDA for the speech. After a lot of messing around in Windows only, NVDA seems to be much better than using SAPI TTS engine. I have to say it has been quite reliable. I have had a couple things that don't read, Like after one of the addon updates what I am told looked like a webpage listing change log didn't read at all. And there was another window which didn't read, but had no sighted folks around to tell me what it was for.
Have you installed the keymap from settings, and if so, did you try pressing F2 in these instances?
(2014-04-19, 22:28)VIJO Wrote: [ -> ]However, The important stuff seems to reads awesome. However, The real test is coming as I just got my nuc to setup as a dedicated media center and I hope to share this with a few people I know will be interested.

I have yet to be able to get a pvr setup, The Sagetv plugin for my sage setup doesn't work like I was hoped. I'm going to explore alternative tv backends as I get some time. Which leads me to a question, (And before I ask please note that I am in no way asking anyone here to go and do this and infact would prefer ya'll keep working on xbmc), Could in theory the method you used to give Frodo and Gotham TTS be used to add speech to other XBMC PVR software like Mediaport, NPVR and such?
I have no idea, but I doubt it. I don't think there is anything out there that has such a comprehensive addon system, and I was still barely able to make it work Smile
Even many of the ones based off XBMC were forked off before the addon system got to this level, or don't use the addon system at all.
(2014-04-19, 22:28)VIJO Wrote: [ -> ]You all have inspired me, I picked up a couple python for beginners books. I have long ways to go before I can understand at the level you folks are, But After a several chapters I think I can learn it.
Python is my favorite programming language. I think it's a great programming language to start out with. I think it's pretty easy to learn, and you have the power to do most of the things you can do with a compiled language, without having to worry as much about the lower level details. Combine this with its fairly large and comprehensive standard library and it's easy to quickly write code that actually does something.
If you have any questions, don't hesitate to ask Smile
eckythump: I just booted my Raspberry Pi with OpenELEC 3.95.5 and got the repeating speech. I can confirm that this build does not have the fix in XBMC but the addon thinks it does.
I originally thought (from some previous experience I don't specifically remember) that passing an extra argument to playSFX() was ignored, so I was trying to use version testing. Later, I got an error passing an extra argument when one was not expected so I figured I was wrong. That combined with the fact that I found that I could not reliably use the version to determine if the fix was available led me to change to testing by playing an empty wav with an extra argument. Unfortunately, this doesn't seem to be throwing an error like I experienced before. I'll have to poke at it some more. I'm sure I must be misunderstanding something here Smile
'
eckythump: I've found the problem. It looks like sraue added the fix in as a patch for that version. This was before some requested changes by the XBMC team one of which was to make the default argument be True, so I changed from ignoreCache=False to useCached=True. So the argument was there, but reversed from what the addon was expecting. The good news is that this should only affect that particular version of openelec, so I won't need to change anything. I had to cross-reference a bunch of dates and commits to finally figure this out Smile

So if you upgrade to 3.95.6, all should be well.
ruuk:

I did a fresh install of OpenELEC 3.95.6 on another SD card and installed the tts addon. It no longer repeats.

However, I'm getting a lot of crashes, to the point it's unusable. I have been unable to get into addon settings as it crashes as soon as I move the selector bar onto XBMC TTS, even before I hit enter, and before it says that list item.

It also crashed while browsing videos/music, too.

This is just using all default out-of-the-box settings. Fresh install of openelec, install of your repo, install of xbmc tts, and absolutely nothing else changed.

Hopefully you'll be able to reproduce this behaviour. If not, I'll try and put some time aside to do some debug work for you and see what the logs have to say.

And just to be clear, by crashing, I mean the xbmc process completely dies.

Thanks again for all your time and effort on this. It's getting more and more solid all the time, and the predictable teething problems aside, I expect in a couple of months we'll have something very trusty and reliable.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30