[Tom Parker]

Twitter provides information (http://twitter.com/account/rate_limit_status.xml) about the allowed rate limits. This patch adds an "automatically" option to the refresh interval, which sets the interval to 2/3rds (to try and avoid accidentally hitting the limits) of whatever Twitter says is ok (typically 100 updates/hour).

Automagic refresh interval

Improved automagic

I've just uploaded a v2 edition of the patch that instead of feeding off of the hourly limit (which will fail badly if you've got other tools also accessing Twitter at a fast rate) and instead looks at the requests remaining for this hour and the time till next reset in order to determine a sane rate to refresh at. For users who aren't accessing Twitter with anything else, this should behave as the previous patch, but will interact sanely with other programs if needed. The "I've run out of requests" support is still untested, but should be ok...

Thanks for the patch! I'll try to review it later this weekend.

• assigned_to: nobody --> bpepple

Still reviewing this patch. I've had a few crashes over the weekend due to a thread issue, and need to see if I can track down what's causing it. Hopefully, I'll have some time to do that this weekend. ;)

I've been running with this patch (plus a couple of others I've recently submitted) on the SVN trunk for the past week, and haven't seen any issues yet.

Yeah, I've been able to reproduce this bug, so I'm going to need to do some investigation first before committing this. How long are your running each instance? I'm able to reliably recreate this crash with a bit over an hours worth of running.

<snip>
Parser: Remaining limit is 58, speed is 0.038284, seconds is 1515, hourly limit is 137.821782
Network: Auto reloading. Timeout: 4218
Network: Get: https://twitter.com/statuses/friends_timeline.xml
Network: Timeline response: 200
Network: Get: https://twitter.com/account/rate_limit_status.xml
Network: Limit is 91, reload time is 39560
Network: Starting timeout id: 4247
Network: Parsing timeline
E: thread-posix.c: Assertion 'pthread_setspecific(t->key, userdata) == 0' failed at pulsecore/thread-posix.c:200, function pa_tls_set(). Aborting.
<snip>

I've been running it pretty much 24/7 (machine it's on gets left on overnight), and haven't seen *any* crashes. Can you get a full ("thread apply all bt" to gdb) stacktrace? I might be able to do something with that (I do various bug triage and fixing for the Gnome project :-)