Yes, I am receiving limit messages.
I will send an email once my college project is near completion and
ready to go live.
Thanks for Twitter's Dev Team Help!
- Will Mulligan
Worcester Polytechnic Institute
Something just to keep in mind. Try not to postpone integration into a
higher access level stream for last b'coz you might have to process A LOT (I
really mean it!) of tweets. Unless well done it could be over whelming for
the application to integrate with elevated access level stream.
On Tue,
Are you able to tell me how many more?
I know that current am getting about 28 tweets per second that contain
'rt' in them.
I estimated from the twitter.com search, that there are about 40-50
per second, but that is assuming the twitter.com is not limited.
Thanks
If you are using just track predicate, then u should be fine. But in general
gardenhose floods u depending on the time of the day and various other
factors nearly a few thousand tweets per hour on an average or something
similar. But again it depends what u r consuming. My numbers could certainly
Are you receiving limit messages?
If not, than the issue isn't with your Streaming API role, but rather how
you are defining your search terms. You may need a broader predicate set to
catch more of them
If you are receiving limit messages, you can request a higher access level
at
Thanks for the advice. I switched over to streaming and am getting
about 25-30 tweets/sec that contain 'rt'.
Based on main website search, I estimate there are about 45-50 tweets/
sec that contain 'rt'.
So, I am only getting about 50% of the actual tweets. If I applied
for the retweet
both of those are samples -- the streaming API is a sample and the search
API does not return all tweets (not all tweets are indexed by search).
these are the best two options for getting a sample of all the retweets,
unfortunately.
On Sun, Feb 14, 2010 at 11:11 AM, TimeSnag wmulli...@me.com
There's actually an issue in the issue tracker on this:
http://code.google.com/p/twitter-api/issues/detail?id=1348
On Jan 29, 7:29 pm, Abraham Williams 4bra...@gmail.com wrote:
The location of statuses are often times a best approximation. You should
probably do some validation/cleanup
You should be using search.twitter.com for all search API calls.
On Jan 30, 2:05 pm, Josh Roesslein jroessl...@gmail.com wrote:
Hello,
I have discovered that the search methods search and trends seem to
work okay with the domain api.twitter.com.
But the methods trends/current, trends/daily,
1) Looks like the docs got updated.
2) 400 will eventually just be for API calls that are malformed:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.1
Abraham
On Sat, Jan 23, 2010 at 18:40, Andy Freeman ana...@earthlink.net wrote:
(1) When will
(1) When will http://apiwiki.twitter.com/HTTP-Response-Codes-and-Errors
be updated?
(2) How does 420 differ from 400?
On Dec 22 2009, 4:19 pm, Wilhelm Bierbaum wilh...@twitter.com wrote:
Eventually the REST API will return the same 420 response code to
indicate rate limiting. We wanted to
1) When will http://apiwiki.twitter.com/HTTP-Response-Codes-and-Errors
be updated?
(2) How does 420 differ from 400?
On Jan 23, 4:21 pm, Wilhelm Bierbaum wilh...@twitter.com wrote:
In accordance with our previous announcement, we have completed the change
to Search API rate limiting response
i am getting this response code in my twitter search application, how
to resolve the error ?
On Dec 23 2009, 3:44 am, Wilhelm Bierbaum wilh...@twitter.com wrote:
We're changing the response code sent back by the Search API when the
rate limit has been exceeded. At present, it is impossible to
OK ... next question ... are the rate limit HTTP headers from the REST
API now ported to Search and working / documented?
2. HTTP response headers included in all REST API responses which
count against the rate limit:
* X-RateLimit-Limit the current limit in effect
*
So, any news on the matter. This probably means that the number of
search results has deliberately been reduced to give people an
incentive to move to the streaming api's?
-M
--
Dr. Mikio Braun, Beckerstr. 11, 12157 Berlin
Privat: 030 / 42 10 56 42, Büro: 030 / 314 78627, Handy: 0172 / 97 45
Search results are altered to improve result quality. The Streaming API
exists as a full-fidelity alternative for large-scale integrations.
-John Kalucki
http://twitter.com/jkalucki
Infrastructure, Twitter Inc.
On Wed, Jan 20, 2010 at 3:20 AM, Mikio Braun mikiobr...@googlemail.comwrote:
So,
Dear John,
thanks for the reply. We've already started to look into the migration
to the streaming API. Looks very nice so far!
-M
On Wed, Jan 20, 2010 at 3:41 PM, John Kalucki j...@twitter.com wrote:
Search results are altered to improve result quality. The Streaming API
exists as a
Hi,
I saw this geocode parameter. How does this work with search by
location?
For example, if I had a search box with 'Find users near: '.
Do I need to parse this location to long/lat or will Twitter sort this
out for me? If the location needs to be geocoded are their tools
available to do
any tweet created using the ge
On Thu, Jan 7, 2010 at 12:05 AM, Jason jasonstanle...@gmail.com wrote:
Hi,
I saw this geocode parameter. How does this work with search by
location?
For example, if I had a search box with 'Find users near: '.
Do I need to parse this location to long/lat or
(sorry - that was sent too early)
any tweet created using the geotagging API, that is within the specified
radius, will be returned. additionally, the search infrastructure parses
the location field in a user's profile and will return tweets by users who
have set their location to within that
Will you be changing the REST API error code to match the Search API?
RE: 420 = rate limit exceeded.
On Dec 22, 4:44 pm, Wilhelm Bierbaum wilh...@twitter.com wrote:
We're changing the response code sent back by the Search API when the
rate limit has been exceeded. At present, it is impossible
yeah, doesn't make much sense to have two different codes indicating that
the limit is exceeded...
2009/12/23 DustyReagan dustyrea...@gmail.com
Will you be changing the REST API error code to match the Search API?
RE: 420 = rate limit exceeded.
On Dec 22, 4:44 pm, Wilhelm Bierbaum
Eventually the REST API will return the same 420 response code to
indicate rate limiting. We wanted to change as little as possible to
get people comfortable with the new response code.
On Dec 22, 4:07 pm, Marco Kaiser kaiser.ma...@gmail.com wrote:
yeah, doesn't make much sense to have two
@AJ Chen
You are 100% correct when you say that it’s the user’s responsibility
to clean up duplicates in the search results. My issue is not so much
about there being duplicates, but the fact that there are so many of
them. My concept of search is that if there have been new tweets
posted, say 30
I would have to agree with mat. But to each their own. The return
codes frequently make no sense from twitter, so i guess the fact that
it doesn't make sense it is irrelevant, so long as it is consistent.
On Dec 3, 6:29 pm, mat mat.st...@gmail.com wrote:
Given that 400 is bad request, and the
Given that 400 is bad request, and the client SHOULD NOT repeat the
request without modifications (w3.org's emphasis), and 503 means
service unavailable, try again later, and can include a retry-after
header, would it not have made more sense to change the response code
of the REST API to the more
unless I miss something, it's usually user's responsibility to dedup
returned tweets on the client side. if you see duplicates between two feeds,
just remove the duplicates. this is what client application should have in
any case.
if you see no fresh tweets but only old tweets, there may be a
Hi, Raffi
Were you able to raise the cache issue with the search team?
Seems the problem is worse than I thought. I have run my script
(getting 25 results from search every 15 minutes, for Mumbai) for two
days. The first day had 71% duplicate results due to the caching
issue, while the second day
@Abraham
I actually use the geocode with the search api for my script, so using
the search api isn't my problem. My problem is that I get stale
results from the search cache, even when querying after a sufficient
interval. Also the stale results seem hours old (at times, in fact
yesterday at 23:00
unfortunately, there is no (current) way to subscribe to the streaming
API for a particular location. as for the caching issue on the
search, that's unfortunate, and i'll try to raise the issue with the
search team next week.
@Abraham
I actually use the geocode with the search api for my
the streaming API would be ideal for my purposes, so will eagerly wait
and see what new features the twitter api dev team adds before the
final release. Till then, search api is what I will use. Thanks a lot
Raffi, for trying to raise the issue with the search team.
Regards,
Elroy
On Nov 28,
I got some requests to post the query that I am using:
here is the query :
http://search.twitter.com/search.atom?geocode=19.017656%2C72.856178%2C15.0mirpp=25
Do correct me if I am not querying or using the API correctly. (Should
have been my first question actually :) )
Also here is a sample of
Hi Elroy,
I tried your query from python several times within the same minute.
After running the query several times in a row I start getting fresh
results and they remain fresh for a while. I tried changing the least
significant decimal to make it a different query and I get stale
results
Hi Everyone,
I've been running my script as a cron task (every 15 minutes) since
last evening. So far I've got about 1375 results logged, out of which
973 are duplicates (meaning stale entries)...a staggering 70.7076%
or approximately 71%. This is way more than expected..so a shout out
to the
Just a couple of queries: I'm using the Atom format for search results
(As mentioned on http://apiwiki.twitter.com/Twitter-Search-API-Method%3A-search)
.
I get the published date in the atom feed. So I am not sure what you
mean by created_at:Fri, 27 Nov 2009 00:06:44 +. The format
available
@Raffi, thanks for the reply. I now convert the time from UTC to my
local time zone, so my time zone problem is sorted out. On the issue
of search, been going through the streaming api docs. From what I have
gone through so far, there doesn't seem to be a way to query for
status updates from a
On Fri, Nov 27, 2009 at 12:38, enygmatic enygma...@gmail.com wrote:
From what I have
gone through so far, there doesn't seem to be a way to query for
status updates from a certain geographical location, say limited to a
city. I may be mistaken here, so do correct me if I am wrong.
Check out
@Raffi,
Thanks for the info.
Just a couple of queries: I'm using the Atom format for search results
(As mentioned on
http://apiwiki.twitter.com/Twitter-Search-API-Method%3A-search).
I get the published date in the atom feed. So I am not sure what you
mean by created_at:Fri, 27 Nov 2009 00:06:44
hi em.
thanks for the error report, and we'll dig into it further -- but that
seems like it was a transient error. i can, at this moment, hit that
link and it seems to work.
Dear all,
from today Search API's geocode parameter (http://apiwiki.twitter.com/
Except now that I look at it a day later, the results have completely
changed, and seem to be in order.
Why would the results change over time when the same max_id is set,
and was valid at the time of the query? Are the ids of tweets not
generated in ascending order?
On Nov 3, 3:17 pm, TripleM
Apologies for the multiple posts, but as the above links no longer
show the problem, you can replicate as follows:
Go to
http://search.twitter.com/search?rpp=100page=1geocode=-40.900557,174.885971,1000km
Note how long ago the last tweet on that page was posted.
Click 'Older' at the bottom.
I'm experiencing the same. Empty results from the Search API when
using the since_id parameter.
This is really bad and my users are complaining about the Saved
Searches tabs not updating.
If you're lucky you end up at a caching server with up-to-date
information, but it seems as if you can't
If you do something like:
from:louisvillemojo OR louisville OR kentucky
it will do what you describe, but if you want to do something like
from:louisvillemojo OR (louisville AND kentucky)
then it will not work. You would have to do 2 separate queries in that case.
-Chad
On Thu, Oct 29, 2009
A number of people are seeing similar things, especially if you
specify a since_id:
http://groups.google.com/group/twitter-development-talk/browse_thread/thread/e6289b6439c1d26d/e367ca8af09d28d5?lnk=gstq=searches+returning+no+tweetspli=1
My current (extremely bad) solution is to just hire hose
It looks as though it depends on the exact nature of the query.
The following always return up to date results, even with a since_id
(I haven't included those since_ids here)
http://search.twitter.com/search.json?q=hong+kong+OR+kowloonrpp=100
Actually I can confirm my previous supposition, here is the log for an
empty 200 response with a new max_id:
DEBUG: 06:02:44 PM on Mon October 26th Doing CURL fetch with User
Agent: justsignal/1.0 (+http://justsignal.com) and RFERER:
we are seeing the same issue at our end. It gets better in the night
(PST) and then breaks in the morning.
I don't even see 403 but only 200s. Our (5 minutely) search request
comes back with none, one or two results at the max though i know
every minute there are about a 100 messages (as we'v
This is happening RIGHT NOW for the following:
1) Go to search.twitter.com and enter tweetsforboobs OR
tweetforboobs as the search.
2) Go to http://tweetsforboobs.org and see the twitter feed on the
left.
Notice that the last tweet from 2 hours ago (VerticalMeasures) is not
in the twitter feed
Will someone from Twitter please respond if there is an ETA to resolve
this issue. Work arounds can never be really as effective as the real
deal.
I'm having problems with my code because it looks like the search
method is returning the created_at date in the following format: Fri,
16 Oct 2009 16:40:25 +
Everything else, and the documentation is using this format: Tue Feb
24 16:38:44 + 2009
Is this being fixed?
Yes, this
Chad,
Sorry for not being clear. I was thinking about Abraham William's
suggestion above where Twitter Search API works with authenticated
sessions+rate limiting, instead of IP based rate filtering. Just so
you know, AppEngine has 30 second timeout on request to all AppEngine
urls, and 10 second
Search runs of of a different database then the REST API. Currently deleted
statuses do not get propagated to the Search database. It is a know issue:
http://code.google.com/p/twitter-api/issues/detail?id=164
On Sun, Oct 4, 2009 at 04:31, fiskeben fiske...@gmail.com wrote:
Hi,
When searching
I would recommend just using a physical server and uploading a simple
php proxy script. If you have existing webspace, it will save you the
trouble of setting up an complete ec2 build just to run a proxy
script.
On Oct 9, 7:11 pm, Akshar akshar.d...@gmail.com wrote:
Thanks Abraham.
Any
So basically, if its not a 503 on the search API I should be clear?
On Oct 9, 5:11 pm, jmathai jmat...@gmail.com wrote:
Get used to receiving random 502 (and other response codes) from the
Twitter API. If you don't know exactly what the code means I suggest
retrying it. If it's explicit
Get used to receiving random 502 (and other response codes) from the
Twitter API. If you don't know exactly what the code means I suggest
retrying it. If it's explicit that you're being rate limited then
wait before you retry.
http://twitter.com/jkalucki/status/4686847704
Thanks Abraham.
Any pointers on how to setup a proxy on amazon ec2 for GAE?
On Oct 8, 6:07 pm, Abraham Williams 4bra...@gmail.com wrote:
Pretty much. You have limited options:
1) Run your Search API requests through a proxy where you will have
exclusive access to the IP.
2) Wait for V2 of
I have solved a problem like that:
While I receive an error 503 - my application continue knocking to
twitter with query.
Everything works ;)
http://apiwiki.twitter.com/Rate-limiting states that for cloud
platforms like Google App Engine, applications without a static IP
addresses cannot receive Search whitelisting.
Does that mean there is no way to avoid getting HTTP 503 response
codes to search requests from app engine?
On Oct 8,
Pretty much. You have limited options:
1) Run your Search API requests through a proxy where you will have
exclusive access to the IP.
2) Wait for V2 of the Twitter API where the REST and Search APIs get
combined so you can have authenticated search queries.
3) Hope Twitter slaps some duct tape on
I am also facing this issue. I'm only making a couple of requests
from GAE (about 3-4) and none of them are getting through, I keep
getting the following using Twitter4J
Twitter Exception while retrieving status
twitter4j.TwitterException: 400:The request was invalid. An
accompanying
Twitter should really in this case either white list all GAE IPs (I'm
sure an email to Google could get all IPs they use) or allow charging
API requests to an authenticated account rather than by IP (much like
the REST API does). This way each GAE application would just set up a
twitter account
Same here; my app runs on Google App Engine and 40% of the requests to
the Twitter Search API get the 503 error message indicating rate
limiting.
Is there anything we as app authors can do on our side to alleviate
the problem?
/Martin
On Oct 5, 1:53 pm, Paul Kinlan paul.kin...@gmail.com
Hi All,
GAE sites are problematic for the Twitter/Search API because the IPs
making outgoing requests are fluid and cannot as such be easily
allowed for access. Also, since most IPs are shared, other
applications on the same IPs making requests mean that fewer requests
per app get through.
One
Hi Chad,
I am sorry but that doesn't even help in the slightest.
You are essentially saying that we shouldn't develop on the App
Engine, since would now have to also buy a proxy. Which is completely
unfeasible and defeats the purpose of why people are using the app
engine.
I understand that
Hi. I have this problem too.
My application does two request per hour and it get rate limit.
What is wrong? I think it is twitter's problems
On 1 окт, 01:45, Paul Kinlan paul.kin...@gmail.com wrote:
Hi Guys,
I have an app on the App engine using the search API and it is getting
heavily
Hi all,
I am having the same issue. I have tried setting a custom user-agent,
but this doesn't seem to affect the fact that twitter is limiting
based on I.P. address. I'm only making about 5 searches an hour and
80% of them are failing on app engine due to a 503 rate limit.
Twitter needs to
I'm noticing this problem as well. I'm making only a couple requests
per hour. I have tried setting the user-agent and the HTTP_REFERER
headers to a custom name, but Twitter doesn't seem to care.
On Oct 5, 2:59 am, steel steel...@gmail.com wrote:
Hi. I have this problem too.
My application
I am pretty sure there are custom headers on the App Engine that indicate
the application that is sending the request.
2009/10/5 elkelk danielshaneup...@gmail.com
Hi all,
I am having the same issue. I have tried setting a custom user-agent,
but this doesn't seem to affect the fact that
add either -from:user or from:-user to the query (i can't quite remember
which).
On Fri, Oct 2, 2009 at 06:44, Greg gregory.av...@gmail.com wrote:
Is there a way to use the Search API to not return results from a
selected user?
--
Internets. Serious business.
Ya. Sorry bout the miss info I reread the docs and forgot to correct
myself.
Luckily Chad is on the ball though. :)
Abraham
On Mon, Sep 28, 2009 at 17:26, Yaniv Golan yango2...@walla.co.il wrote:
Thanks for that Chad
On Sep 28, 6:03 pm, Chad Etzel c...@twitter.com wrote:
Hello,
The
Abraham, thanks for replying.
something still doesn't make sense...
how come i always get 100 results? I'm sure there are more tweets that
match this search criteria
how can i get the max result per call?
On Sep 28, 7:25 am, Abraham Williams 4bra...@gmail.com wrote:
The 1500 result limit is
John,
My key issue is that my application is hosted on shared
infrastructure. In addition to mine, other applications are hitting
the Search API from a common IP address. If there is a way to identify
my traffic from others', and only rate limit it if it's responsible,
that would solve it.
I am
Hello,
The 1500 result limit _is_ for the Search API. The results are limited
to 1500 or the last 7ish days, whichever occurs first.
Yaniv, the rpp (results per page) parameter is how many results will
be returned with each request. The page parameter is basically an
offset indicator.
To get
(this could be overcome, I suppose, by performing multiple queries,
but that isn't much of a solution if you want to use the stock twitter
js search widget, etc)
On Sep 27, 11:37 am, zapnap npla...@gmail.com wrote:
Search API queries appear to be limited to 140 characters. I mean,
that's cute
Hello,
The limit is indeed 140 and most likely won't be going up any time
soon. The reason for the limit is for performance reasons. In order to
do timely queries we don't allow for longer/arbitrary queries which
could be very complex.
-Chad
On Mon, Sep 28, 2009 at 3:08 PM, zapnap
Thanks for that Chad
On Sep 28, 6:03 pm, Chad Etzel c...@twitter.com wrote:
Hello,
The 1500 result limit _is_ for the Search API. The results are limited
to 1500 or the last 7ish days, whichever occurs first.
Yaniv, the rpp (results per page) parameter is how many results will
be
If you need to search specific users why don't you use the Shadow API
and grab all of their tweets and then search them locally?
On Sep 28, 3:14 pm, Chad Etzel c...@twitter.com wrote:
Hello,
The limit is indeed 140 and most likely won't be going up any time
soon. The reason for the limit is
The 1500 result limit is for the REST API. The Search API is limited based
on time which last I heard was around 7 days.
Abraham
On Sun, Sep 27, 2009 at 18:33, Yaniv Golan yango2...@walla.co.il wrote:
Hi all
I'm submitting this query to twitter search
Hello,
Currently there is no such API, but you can simulate it somewhat by
fetching several pages of your friends_timeline and parsing through
them for keywords. We realize this is not ideal, and we've had several
requests for this feature. It may be added down the road.
-Chad
On Thu, Sep 24,
There's an app called Chatterfly (http://
chatterfly.appaturelabs.com/ ) that allows you to do this, but only
for your friends, not your followers unfortunately.
dpc
On Sep 24, 12:42 pm, Chad Etzel c...@twitter.com wrote:
Hello,
Currently there is no such API, but you can simulate it
The Search API is served from a totally different infrastructure than
api.twitter.com. As such, it has limits that are tuned to protecting a
very different back-end. Even if Search was served through the
api.twitter.com stack, the policies would still be driven by the back-
end.
If you are
PHP libraries / examples are here: http://apiwiki.twitter.com/Libraries#PHP
On Sep 10, 6:55 am, Joel Strellner j...@twitturly.com wrote:
Something like this is going to require a server-side language, like PHP,
Perl, Ruby, etc. JavaScript wont cut it.
I'm not sure how you'd do this without
Something like this is going to require a server-side language, like PHP,
Perl, Ruby, etc. JavaScript wont cut it.
I'm not sure how you'd do this without it being spammy though. IMO it should
be manual, or at least semi-manual using a queue of some sort that you need
to approve prior to it going
Search API will rock if it would only be reliable
what we see looks to be some sort of a funky cache, a query (atom)
can be missing some latest tweets and then after a while they show up,
if you tweak the query you can see 'em.
you ever seen this problem?
also what did you do special with user
The Search team is working on indexing latency and throughput, along
with a many other things. There have been big improvements recently
and more are on the way.
In the mean time, if you need closer to real-time results, consider
the track parameter on the Streaming API.
-John Kalucki
John, the original message of this thread is about rate limit being
totally erratic, as several users have noticed. here is the detail of
what I'm seeing:
http://groups.google.com/group/twitter-development-talk/browse_thread/thread/40c82b4dbc0536bd
Here is another user reporting the problem :
Various APIs have their own rate limiting mechanisms. The www, search
and streaming rate limits are all customized to their usage patterns
and share little to no code and/or state.
-John
On Sep 4, 9:49 am, Reivax xavier.yo...@gmail.com wrote:
John, the original message of this thread is about
Dewald,
I'm not on the search team, but there are a lot of discussions over
there this morning about search api rate limits and related issues.
Search rate limiting issues (vs. www.twitter.com or api.twitter.com)
probably boil down to one of three categories:
1) Search service interruptions -
The rpp defaults to 15 or something if you don't specify it. Sounds
like you need to mess around and play with things a bit more.
The key to max search results isn't in paging or rpp, but in max_id.
Be careful what you ask for. Retrieval of everything available can
take a long time (hours)
The key to max search results isn't in paging or rpp, but
in max_id.
Hi David,
I do not understand how max_id can help me.
If I want to get the 10,000 most recent tweets that match
the phrase michael jackson changing the max_id value
doesn't seem like it's going to help at all.
In fact,
Hello,
All results from the Search API are always returned in reverse chronological
order (most recent first). Number of keywords present in the result does not
play into it.
Thanks,
-Chad
On Thu, Sep 3, 2009 at 9:42 PM, Mike michael...@gmail.com wrote:
Hi,
I'm very amazed by the API.. but
Use the search api
On Wed, Aug 26, 2009 at 10:38 AM, Marc Andrewsbackcirc...@gmail.com wrote:
I've scoured the API documentation, but to my surprise, can't find the
answer...
Does the API allow search for user by first name, last name, or screen
name?
I'm not interested in searching for
http://apiwiki.twitter.com/Twitter-Search-API-Method%3A-search
On Wed, Aug 26, 2009 at 10:51 AM, Kevin Mesiabke...@mesiablabs.com wrote:
Use the search api
On Wed, Aug 26, 2009 at 10:38 AM, Marc Andrewsbackcirc...@gmail.com wrote:
I've scoured the API documentation, but to my surprise,
hi marc.
nope - we don't have a method that will let you do the equivalent of
find people.
I've scoured the API documentation, but to my surprise, can't find the
answer...
Does the API allow search for user by first name, last name, or screen
name?
I'm not interested in searching for
Not yet. It is on the roadmap: http://apiwiki.twitter.com/V2-Roadmap#Users
Abraham
On Wed, Aug 26, 2009 at 15:38, Marc Andrews backcirc...@gmail.com wrote:
I've scoured the API documentation, but to my surprise, can't find the
answer...
Does the API allow search for user by first name, last
Thanks Abraham, that's the answer I was looking for. Appreciate it.
Kevin, the search API is exactly what I don't want, but I appreciate
you taking the time to make an attempt at answering.
I'll get by with users/show?screen_name=... in the REST API.
Thanks,
-Marc
On Aug 26, 1:45 pm, Abraham
Yes, earlier in the week we saw a lot of these reported by TweetDeck
users too. Seems to have tailed off now though.
On Aug 20, 4:42 pm, Marco Kaiser kaiser.ma...@gmail.com wrote:
Hi,
we are receiving an increasing number of reports from users about search
results containing tweets that don't
I have seen the same which is affecting quality of results at
Twaller.com. I have communicated this issue with the Twitter Team, you
can see my post at this forum 3-4 daya back. This seems to be a very
recent phenomenon.
On Aug 20, 7:42 am, Marco Kaiser kaiser.ma...@gmail.com wrote:
Hi,
we are
Hi Chad,
we are getting reports from the users of our desktop clients, so the user
agent will either contain twhirl or Seesmic Desktop. We'll try to get
the queries used from our users, but unfortunately, we'll not be able to
provide any of the other information, as it all happens on users'
On Tue, Aug 11, 2009 at 10:30 AM, David Fishertib...@gmail.com wrote:
While i haven't done scientific testing of this, I was able to run up
to 3-4 instances of my search script prior at a time before it told me
to enhance my calm. Now I'm barely able to run one without hitting the
limit. I
101 - 200 of 354 matches
Mail list logo
