With the code below I have been connected to the telegram using telethon for about one year!
client = TelegramClient(
SESSION,
API_ID,
API_HASH
)
client.connect()
# the rest of my code
Yesterday when I want to connect to my session with the code I got this error:
telethon.errors.rpcerrorlist.AuthKeyDuplicatedError: An auth key with the same ID was already generated
The error does not tell anymore and in the doc there is no more description about this error message. How can I retrieve my session?
one of the ways to produce this error is to run 2 instances of the same session in separate locations simultaneously(or at least with a small difference in their connection time to TG)
if you have access to those phone numbers(or any other active sessions of them e.g. Android app), you can do the below procedure, otherwise as far as I know, I afraid that you can't do anything for other compromised clients that you don't have access to their numbers(or any other active sessions in other applications):
First, make sure that no Telethon session instances are running on your server(s)(at least for those you have access to). Second, you can kill that session manually(in "active session" part of telegram applications e.g. Android). third, delete ".session" files from your server. fourth, sign in to your client in the server again.
Related
We have a Multitrack web conference implementation using AMS 2.4.1 version. Its working great for our use case, except in one scenario. When there are N (< 3) number of users and they on there camera simultaneously, then few remote users are not rendered as we don't receive the video tracks for those users in newStreamAvailable. We only receive the audio track for those users. We are able to reproduce this quite frequently.
As a backup, I am trying to poll AMS using getTrackList with the main track Id to get all available streams, but I am not getting any message trackList
var jsCmd =
{
command : "getTrackList",
streamId : streamId, // this is roomId or main track id
token : token
}
Any insight would be helpful.
Thanks,
We were able to resolve the issue, posting here to help anyone who might be facing a similar issue.
With push notifications from the server, we might encounter issues when for some reason push operation doesn't succeed. In that case, it's better to have a backup plan to pull from the server and sync.
The Ant Media Server suggests pulling the server periodically for the room info. The server will respond with active streams and the application should synchronize.
For reference, please refer to following link https://resources.antmedia.io/docs/webrtc-websocket-messaging-reference
I want to schedule a telegram bot message to be sent at a specific unixtime.
As from telegrams official api (https://core.telegram.org/api/scheduled-messages) that should be possible by setting the schedule_date flag.
To schedule a message, simply provide a future unixtime in the schedule_date flag of messages.sendMessage or messages.sendMedia.
However I was not able to set that flag. To be more precisely, I do not even know how to set a flag, or if I am using the correct api.
What I have tried is to use the api directly via the browser (could use curl as well) like so: https://api.telegram.org/botBOT:TOKEN/sendMessage?chat_id=ID&text=Test&schedule_date=1653503351
I also did not find any way to access this flag via https://pypi.org/project/pyTelegramBotAPI/#description https://telepot.readthedocs.io/en/latest/#send-a-message, nor https://github.com/nickoala/telepot.
I want to implement this feature in a python environment, but any working suggestion would be much appreciated.
EDIT:
I decided to save the intention to send a telegram bot message at a certain unixtime in a database. I then create an infinite loop that checks if there are any unsent messages before the current timestamp. If the loop detects such a message it sends the message and sets a flag, that that message has been sent.
And as promised, here is a fully dockerized example of that behaviour in action: https://github.com/Sokrates1989/nameTheCountDown-lightweight
It creates a bot that you can pass a name and the duration. Once the duration has passed it sends a message with the passed name. Basically a simple countdown that you can give several names, that run simltaniously. As it is a telegram chat, you can modify the way you are informed about the end of a countdown by modifying the notificaiton of that chat.
And here is the Bot in action: http://t.me/NameTheCountdownBot
We can't do this by bot API itself, and there's no schedule_date parameter in sendMessage method:
https://core.telegram.org/bots/api#sendmessage
And what you've read is for Telegram clients, not bot API consumers.
If you don't really need unixtime, you can simply create a table for scheduled messages with a text, chat_id and a publish_time column (like 22:15), and run a command every minute to look if there's a message for current time to send. Then send the message and delete the record.
Note that the python-telegram-bot library has a built-in solution for scheduling tasks: The JobQueue. This feature is based on the APScheduler library, which you can ofc also use without python-telegram-bot.
Disclaimer: I'm currently the maintainer of python-telegram-bot.
https://core.telegram.org/method/messages.sendScheduledMessages
Now you can send scheduled messages right away
I have a single web client and a few Lambda functions which use the Admin SDK. I've noticed recently that I've bumped into the 100 simultaneous connection limit but I really shouldn't be anywhere near that limit. Also it would appear that the connections established by my Lamba functions are not dropping off even after the function has completed.
Any idea on:
how I can prevent this run-up on connections from happening?
how I can release connections established by past Lambda scripts?
how can I monitor which processes/threads/stacks are holding connections?
Note: this is a testing environment I'm working out of so I'd prefer to keep this in the free tier and my requirements should definitely not be running into the 100 active limit. I am on a paid plan in prod.
I attempt to avoid calling initializeApp more than once by using the following connection code. In the example I'm talking about I only have a single database as a backend and so the default "name" of DEFAULT is used each time.
const runningApps = new Set(firebase.apps.map(i => i.name));
this.app = runningApps.has(name)
? firebase.app()
: firebase.initializeApp({
credential: firebase.credential.cert(serviceAccount),
databaseURL: config.databaseUrl
});
I'm now trying to explicitly close connections with goOffline but that leads to another issue where on the second connection -- aka, where the DEFAULT application is already setup and it just reuses the connection already established I get the following logging:
# Generated as result of `goOnline`
Connecting to Firebase: [https://xyz.firebaseio.com]
appears to be already connected
# Listening on ".info/connected" comes back as true, resulting in:
AbstractedAdmin: connected to [DEFAULT]
# but then I get this error
NotAllowed: You must first connect before using the database() API at Object._getFirebaseType
The fact that you have unexpected incoming connections to the database, makes it seem like the stale instances keep an open connection.
Best I can think off is to call goOffline() in your function before it completes to explicitly disconnect. That would probably also mean you have to call goOnline at the start of the function, since it might be running on an instance that previously went offline. Both goOnline and goOffline are synchronous calls afaik, but there's definitely going to be some time between going online and the data becoming available in your app.
If Lambda has a way for you to detect life-cycle events of its instances, that would be the preferred place to call goOffline and goOnline.
admin.initializeApp should only get called once in your script/node app.
The Firebase SDK's talks HTTP2 to the Firebase cloud system, so I'm not sure why you would encounter max connection issues as unique sockets are not stood up per call.
One thing to look out for is that calls to 3rd part API's (such as sendgrid) are not supported on the free tier.
Since the Drive SDK v3 we are able to receive push notifications from Google Drive whenever a file has changed. At the moment I'm working on a Drive application in Python and I would like to receive such notifications. Do I really need a web server for this or can I implement this maybe with a socket or something like this?
I know that I can get changes by polling the changes.list method but I want to avoid this because of so many API calls. Is there maybe a better way to get informed if a file has changed?
EDIT: I captured my web traffic and saw, that the original Google Drive Client for Windows uses push notifications. So in some way it must be possible to get push notifications in a desktop application but is this maybe some sort of Google magic which we can't use with the current API
For Google Drive apps that need to keep track of changes to files, the Changes collection provides an efficient way to detect changes to all files, including those that have been shared with a user. The collection works by providing the current state of each file, if and only if the file has changed since a given point in time.
Retrieving changes requires a pageToken to indicate a point in time to fetch changes from.
# Begin with our last saved start token for this user or the
# current token from getStartPageToken()
page_token = saved_start_page_token;
while page_token is not None:
response = drive_service.changes().list(pageToken=page_token,
fields='*',
spaces='drive').execute()
for change in response.get('changes'):
# Process change
print 'Change found for file: %s' % change.get('fileId')
if 'newStartPageToken' in response:
# Last page, save this token for the next polling interval
saved_start_page_token = response.get('newStartPageToken')
page_token = response.get('nextPageToken')
I want to send a string from a website to a local machine.
My local machine is connected into a network through a router.
Thanks You
email Id: manish.m.meshram#gmail.com
Well, that largely depends on what the receiving computer needs to do with that string.
If you only need to notify the user of this, I would suggest the easier way is to go with the net send command.
Since you are wking in ASP.net, you can use the Process and ProcessStartInfo class to launch a command like
net send YourPC "String to send"
If you need to do something more sophisticated with the string message, you could for example print it in some sort of log file and then read it from the destination machine.
If you can give more information on your needs, we'll be probably able to help you better.
Luca
I suggest you poll the webapp for messages.
For instance, let the webapp have an URL that simply returns the timestamp of the most recent message, at http://thesite.com/messages/MostRecentTimetamp.aspx
The page should return the timestamp only, in an format you can parse, for instance:
2009-08-29 14:00:00
Then, on another URL, http://thesite.com/messages/FromLastHour.aspx display the list of messages for the last N hours (or other suitable time period). This page could return one message per line, with the message timestamp at the start of the line.
For instance:
2009-08-29 13:58:20 A message
2009-08-29 13:59:30 Here's a message
2009-08-29 14:00:00 Another message
On your local machine, create a program that as often as needed reads and parses http://thesite.com/messages/MostRecentTimetamp.aspx. If the program detects that the timestamp has changed, read http://thesite.com/messages/FromLastHour.aspx and process the new messages.
Adjust the timing according to your needs.
Or even better, have an URL: http://thesite.com/messages/MoreRecentThan.aspx?timestamp=2009-08-29 13:50:00.
That returns messages that are newer than the timestamp passed in. The program on your local machine should then pass the timestamp of the most recent message it has handled.
Of course, your web site has to keep track of outgoing messages in some sort of queue. You could use a database table for this. The web app can delete old messages from this table periodically.
If you want to get fancy, you could implement this as a SOAP web service. Or you could let the URLs return the data formatted as JSON.