however, it is a result of the fix imposed on us by bug 358341
basically Gwibber was (one of many) clients cheating the system by using POST requests for the timeline(s). Twitter were only measuring GET requests against the rate limit so Gwibber was able to get away with whatever it wanted.
currently you are allocated 100 requests an hour and you can query your current remaining number of hits from the API yourself and when your count was last reset to 100:
{{{
$ curl -u username http://twitter.com/account/rate_limit_status.json
{"hourly_limit":100,"reset_time":"Sun Apr 12 23:32:59 +0000 2009","reset_time_in_seconds":1239579179,"remaining_hits":57}
}}}
so if you have your refresh time set to 1 minute, then just Messages & Replies will trigger your count in 50 minutes
if you have any gwibber:user profile tabs, hash tags or search tabs open these will also count towards your limit so you'll run out even quicker
this bug was incorrectly marked as a duplicate.
however, it is a result of the fix imposed on us by bug 358341
basically Gwibber was (one of many) clients cheating the system by using POST requests for the timeline(s). Twitter were only measuring GET requests against the rate limit so Gwibber was able to get away with whatever it wanted.
currently you are allocated 100 requests an hour and you can query your current remaining number of hits from the API yourself and when your count was last reset to 100: twitter. com/account/ rate_limit_ status. json limit": 100,"reset_ time":" Sun Apr 12 23:32:59 +0000 2009"," reset_time_ in_seconds" :1239579179, "remaining_ hits":57}
{{{
$ curl -u username http://
{"hourly_
}}}
so if you have your refresh time set to 1 minute, then just Messages & Replies will trigger your count in 50 minutes
if you have any gwibber:user profile tabs, hash tags or search tabs open these will also count towards your limit so you'll run out even quicker