Weather zip problem

[rholcombe]

I installed the weather-zip script and have come across an issue.

It gets to the point where it says that it successfully download - please stand by. After this it hangs up. Running asterisk -rvvvvvv verified that it did just go the the hangup. I found this in /var/log/asterisk/full

[Feb 7 22:35:47] DEBUG[26992] app_flite.c: Text passed to Flite: "Please hold a moment while we contact the National Weather Service for your report."
[Feb 7 22:35:47] VERBOSE[26992] logger.c: -- <Zap/1-1> Playing '/tmp/flite_buf_9rFt0b' (language 'en')
[Feb 7 22:35:52] VERBOSE[26992] logger.c: -- Executing [947@from-internal:8] AGI("Zap/1-1", "nv-weather-zip.php|53051") in new stack
[Feb 7 22:35:52] VERBOSE[26992] logger.c: -- Launched AGI Script /var/lib/asterisk/agi-bin/nv-weather-zip.php
[Feb 7 22:35:55] VERBOSE[26992] logger.c: -- AGI Script Executing Application: (flite) Options: (Your report was successfully downloaded. Please stand bye.)
[Feb 7 22:35:55] VERBOSE[26992] logger.c: == Parsing '/etc/asterisk/flite.conf': [Feb 7 22:35:55] VERBOSE[26992] logger.c: Found
[Feb 7 22:35:55] DEBUG[26992] app_flite.c: Text passed to Flite: Your report was successfully downloaded. Please stand bye.
[Feb 7 22:35:55] VERBOSE[26992] logger.c: -- <Zap/1-1> Playing '/tmp/flite_buf_cw4dSD' (language 'en')
[Feb 7 22:36:00] VERBOSE[26992] logger.c: -- AGI Script nv-weather-zip.php completed, returning 0
[Feb 7 22:36:00] VERBOSE[26992] logger.c: -- Executing [947@from-internal:9] NoOp("Zap/1-1", "Wave file: tts/tts-8ea41e655e2c59fc968d3f3f5758077e") in new stack
[Feb 7 22:36:00] VERBOSE[26992] logger.c: -- Executing [947@from-internal:10] Playback("Zap/1-1", "tts/tts-8ea41e655e2c59fc968d3f3f5758077e") in new stack
[Feb 7 22:36:00] WARNING[26992] file.c: File tts/tts-8ea41e655e2c59fc968d3f3f5758077e does not exist in any format
[Feb 7 22:36:00] WARNING[26992] file.c: Unable to open tts/tts-8ea41e655e2c59fc968d3f3f5758077e (format 0x44 (ulaw|slin)): Permission denied
[Feb 7 22:36:00] WARNING[26992] app_playback.c: ast_streamfile failed on Zap/1-1 for tts/tts-8ea41e655e2c59fc968d3f3f5758077e
[Feb 7 22:36:00] VERBOSE[26992] logger.c: -- Executing [947@from-internal:11] Hangup("Zap/1-1", "") in new stack

So it never creates the file in /var/lib/asterisk/sounds/tts/

Any ideas?

 

[wardmundy]

chmod 777 /var/lib/asterisk/sounds/tts/

Then try again.

 

[tshif]

I have no idea why, but amportal restart always clears this up for me. It seems to happen from time to time whenother changes to the system are made. I haven't been able to track down WHAT cahnges trigger this behaviour yet.

 

[rholcombe]

yep I'm retarded

chmod 777 to /var/lib/asterisk/sounds/tts cleared it up, previously I saw that /tmp wasn't writeable and did the same to that

...All is well thanks Ward!!

 

[wardmundy]

Actually you need to set the sticky bit for /tmp to make sure other people don't delete each other's files:

chmod 1777 /tmp

 

[rholcombe]

Looks like the latest update-fixes took care of it.

Thanks

 

[frontline]

I have no idea why, but amportal restart always clears this up for me. It seems to happen from time to time whenother changes to the system are made. I haven't been able to track down WHAT cahnges trigger this behaviour yet.

Just another note on this problem. I have checked meticulously to insure the permissions on both the tts directory and /tmp are correct. Nevertheless the messages fail to write to the tts directory at some point. Restarting renews the ability to write to tts and all is well for a time. It definitely is not limited to the directory permissions problem on my install.

I typically do restart and reloads from the shell but did one (successfully) from the web interface earlier. Whether that had any effect on this problem I cannot say at this point.

 

[jeffmac]

I experienced this problem today after rebooting. I thought I had fouled the php file when I converted it from flite to swift (but it HAD been working with swift). At any rate, I reinstalled the original script and it was working. Then I made the changes for swift again and it was still working.

I studied Ward's code for a few minutes. It looks to me like it should detect when it can't write the temp files - but there was no such indication in the log file.

The permissions are still fine (I never touched them - before or after) and its still working fine.

There's definitely something odd going on here....

 

[frontline]

Referring back to my earlier note:
I confirmed that the web reload appears irrelevant. Today when the script failed I was able to determine that the /tmp file is in fact created and unlinked appropriately but fails to write the wave file to the tts directory. In addition, at the same time I can invoke nv-weather-zip.php from the shell command line and it completes perfectly. In the later case the .wav file is written.
Back to interactive execution from a phone dialing 947 and once again the .wav file is not created.

 

[The Deacon]

I've been experiencing this problem over the past couple of days, but since I'm the only one who uses this feature, I didn't bother looking into it until today.

I thought I had the same permission problems, but after looking at the permissions, they were fine. It wasn't until I did a amportal restart that it started working again... Weird.

 

[frontline]

The solution is in one of the other "weather" threads here. Essentially you need to link /usr/bin/swift to /usr/local/bin/swift as I recall. Ward just posted the exact command line to achieve that.

 

[wardmundy]

ln -s /opt/swift/bin/swift /usr/bin/swift