New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Userstream not working anymore. #190
Comments
Same here. The problem started 2013-11-23 for one app and three days later for another one. I thought it was some sort of isolated outage maybe related to my apps or recent change in client IP and reported it here, but that’s getting less likely with every day I can’t find any of the other countless users of the Twitter API reporting similar problems. (Except in this thread.) The sample stream works for me as well. |
When I insert a
|
It’s also using 100% of one of my cores, which may be related to this fix. I hacked in a one-second sleep for now until this is fixed. |
Glad I'm not the only one with problems. I mean if we are doing something wrong when connecting to it, it should at least disconnect us. |
The only reports of problems that I can find are here. If it were a general problem with the Twitter API, the Internet would be flooded with reports. I also sniffed my connection, and while it was encrypted of course, so that I couldn’t see the package content, I could reliably trigger bigger packages by listening to the stream and then favoriting and unfavoriting tweets with the respective account. That also indicates that the problem is not solely with the API (unless it was some crazy degree of coincidence paired with my human bias to see patterns in random noise). |
I don't think it would hurt to report the problem. The worst that could happen is that they close the ticket as invalid. |
Hi, I've encountered this problem as well. I had thought it was a problem with my experimental code until I realized the socket isn't receiving data at all. Not really sure what changed. |
I hope this will get fixed eventually. This library has by far the sanest API I’ve seen. The easiest way is probably to delegate all the HTTP-related functionality to requests. All this low-level socket-listening is yucky to me, so I haven’t figured out what exactly the problem is, but I’ve created a fork of Twython where I have replaced their awkward streaming contraption with a yield (pretty much just like this library does it). There may’ve been advantages to their error handling, but I removed that as well for consistency, and so you’re no longer forced to subclass the streamer to use it. (Once this is fixed, I’ll switch back so I’ll no longer have to maintain the fork.) Careful, by the way, Twython expects the authentication parameters in the order |
Hi, I've this problem too with my app. It's very embarrassing and I'm surprise nobody knows where the problem coming from. I hope a solution... Regards. |
Twitter is moving all of its APIs towards HTTP1.1. https://dev.twitter.com/blog/deprecating-http-1.0-streaming-api Userstream passed already mid-november and has been borken for this lib since On Jan 6, Twitter will apply it as weel for all the other stream methods, meaning they probably would be all broken. The problem was in two pieces. First with this commit, we stop asking for gzip encoded data for streaming calls: for the HTPP1.0 calls, this was not taken into account anyway, but with HTTP1.1 the answer is now chunked and should therefore not caught zipped. (First part of fix for userstream and soon all streams cf python-twitter-tools#190 python-twitter-tools#116)
Chunked data sent via HTTP1.1 by Twitter is not as straight forward to read, chunks indicating size of tweets are present no matter what, so we find the json start in the buffer and forget the rest for now. (Second part of correction for userstream and soon all streams. Fix python-twitter-tools#190 python-twitter-tools#116)
I also have problems with getting tweets. Until november 2013 these statements worked: |
@pauldebeurs 2 different pull requests propose fixes you can use by switching to one of their respective branches: |
Oh, some good work there. Thank you both! <3 |
This is great! I hope the changes gets merged soon. |
Sorry for the delay. PR #196 is merged, and 1.11.0 is released with the fix. Big thanks to the contributors who did all the work on this! (It totally wasn't me.) |
Twitter is moving all of its APIs towards HTTP1.1. https://dev.twitter.com/blog/deprecating-http-1.0-streaming-api Userstream passed already mid-november and has been borken for this lib since On Jan 6, Twitter will apply it as weel for all the other stream methods, meaning they probably would be all broken. The problem was in two pieces. First with this commit, we stop asking for gzip encoded data for streaming calls: for the HTPP1.0 calls, this was not taken into account anyway, but with HTTP1.1 the answer is now chunked and should therefore not caught zipped. (First part of fix for userstream and soon all streams cf python-twitter-tools#190 python-twitter-tools#116)
Chunked data sent via HTTP1.1 by Twitter is not as straight forward to read, chunks indicating size of tweets are present no matter what, so we find the json start in the buffer and forget the rest for now. (Second part of correction for userstream and soon all streams. Fix python-twitter-tools#190 python-twitter-tools#116)
I'm having problems with user streams since a few days back.
I can use the example in the README file and it seems to connect fine.
But I don't get any messages what so ever.. And the stream connection seems to still be alive. I seems to be alive because even if I set the socket timeout to be about 1 min it never times out.
It doesn't seem to raise any errors either so I don't really know what to do now.
"Normal" streams IE just TwitterStream without specifying domain works so I have no Idea what the problem could be.
The text was updated successfully, but these errors were encountered: