Thanks 9000, for this beauty script. I wanted to know if you got it working to automatically exec on boot? I tried on the basis specified by Jussi in http://www.mynokiaworld.com/2010/02/...-on-your-n900/

But for some reason the process is not starting. could you please help me out. Thanks

Thanks, I'll show you how to make it starts on startup later on.

Regarding your issue, if you run it directly it should wait for a call indefinitely. Any strange message seen when it exits adnormally?

I am trying to implement this feature on my qt application but w/o much luck. Maybe we can compare notes:

1. I first tried to change the ring tone using dbus on the fly when receiving a call but it did not work. the phone just seems to go back to the default ring tone if you try to change it after the coming signal.

2. then I tried to just implement this solution but thought I could use no file extension for my symlink name first and then tried with mp3. It seems that the phone application either cache the file or resolves the symlink and store the absolute path when you first assign the ring tone to the profile.

did you try other methods before getting to this solution? is that why you created the sym link with a wav file extension?

p.s. it does not seem to work on mine regardless of the file extension... the first time I set the profile ring tone to the symlink it works... if I change the symlink target the phone keeps playing the original file.... am I missing something?

Thanks

Hi frochik,

1. The reason to change symlink instead of changing the acually default is the speed. There might not be enough time between call coming and ringtone playing unless we can put the ringing on hold.

2. Changing the symlink serves as redirection of the pointer to the ringtone. I'd have changed the actually pointer directly if I knew where it is, so this method is in fact tricking the phone app to play different physical files by changing the symlink. It don't matter what default ringtone you choose, the script just make of the file name.

If it played the same ringtone over and over the symlink in question probably broken. You would like to rebuild manually. I think I'll modify the script to include this checking, thanks for your input.

I haven't tried this myself yet (gotta pick a day to settle down and do all the N900 stuff). Though how quick is it? Will it instantly play the new ringtone or is there a silent pause when someone calls?

Oh I haven't notice the pause as the script is monitoring call rather then controlling it.

Actually I'd rather controlling it to prevent race condition. Anyone would show me how is much appreciated!

thanks for reply m8. i will wait for the startup and the complete package . with respect to process not starting, i meant the actual startup process defined in event.d and init.d. Script (directly executed) is running without problems. Thanks again m8, this a very very useful script, patching the disadvs of N900. As i said earlier, i would love to wait for this script to turn into a lovely feature (which is actually quite a necessity -- supported by almost all phones in this range!!) binded into the OS / contacts. Hopefully it happens by next OS update.

I am currently trying something similar and have more or less the same questions and problems regarding the caching behaviour for ringtones. I have started a new thread about this in the development forum, since I think this is a very specialised subtopic of this thread. If you'd like, you could join me there and maybe we'll be able to figure something out together.

@getnani The script doesn't has much error handling so running it at startup would cause all the calls playing default Nokia ringtone when the script encountered any errors. I can post the startup script if you like anyway...

@Manul I've not encountered any caching problem, may it could be disabled somehow. I'll keep track of your post thanks.

BTW, this script can be considered as a workaround solutions for caller-group ringtone as all it does is monitoring the calls. The race condition cannot be prevented in monitoring mode. Though I've not encountered the problem, but someone else did, and in fact it's possible.

I'd consider making a package out of it if I can figure out the to control the calling flow so as to prevent the race condition.

Please advise if you could find any hints. Thanks.