SiezurE, потому что надо ловить сообщения вообще, например, по content_types=['any'].
Но это всё равно не заработает. Потому что chat_id должен быть чатом группы, где оставлено исходное сообщение. А при форварде информация передаётся только о пользователе-отправителе.
В данном примере ещё и chat_id = личный чат с этим пользователем. А предполагался видимо id чата, где это сообщение оставлялось. Вообще говоря, использовать user_id в качестве chat_id это само по себе плохо, потому что даже для приватных чатов никто не гарантирует, что chat_id будет равно user_id всегда.
Советую попробовать попересылать сообщения боту @ShowJsonBot и посмотреть, какая инфа доходит при пересылке.
blackbb, sqlite3 это файл, а файл будет исчезать время от времени.
Нет, дело не в postgres, дело в том, что media хранить в локальной файловой системе на heroku невозможно от слова "совсем". Они там не храняться никак, вообще. Гуглить heroku ephemeral filesystem.
Jack444, при печати объекта реально вызывается от него метод __str__ или __repr__, который может вернуть что угодно, это вообще крайне редко валидный python-код. Не стоит советовать подобную ерунду.
Идея дурацкая - пытаться записывать строковые представления классов. Они, как правило (но бывают исключения), нужны только для того, чтобы программисту было бы удобнее отлаживать код, и содержат далеко не все данные объекта.
Какая вообще задача стоит? Решение может очень сильно от неё зависеть.
Phanthom, советую попробовать ls совсем без параметров, можно даже 'ls' (чтобы он alias с именем ls не раскрывал). В Linux это хорошо помогает избегать подобных проблем. Список вывести в файл за пределами этого каталога.
Ещё можно попробовать так:
cd /to/target/directory/
'ls'|xargs rm
xargs будет получать из буфера имена файлов и пачками их скармпливать rm.
Армянское Радио, лично я не очень в курсе особенностей *BSD, но автор говорит что с системой что-то становится не так. В Linux можно всё же получить список файлов без вызова stat на каждый.
zenondd, по сути надо при запуске бота заново инициализировать расписание в aioschedule, а для этого хранить его само в базе или генерировать из исходных данных заново.
SYS ADM, не вижу смысла в канале в этой ситуации. Хотя, конечно, можно форвардить пользователю сообщения канала, но тогда нужно где-то организованно хранить соответствие нужных данных со ссылками на посты в канале. Но зачем, если можно просто отправлять пользователю прямо от имени бота?
Я делал бота, который имеет свою менюшку и в некоторых разделах сопровождает тексты картинками. Для этого я сделал в базе данных таблицу files "имя+file_id". При отправке раздела с картинкой я проверяю наличие file_id в базе, если по имени файла есть file_id, то я отправляю его, если нет - я загружаю файл в Telegram и записываю file_id в базу. В итоге каждый файл я гружу в Telegram всего один раз (и не засоряю его сервера одинаковыми файлами), всегда могу быстро и легко добавить любые файлы в меню, а пользователи полуают ответ бота быстрее, чем при загрузке файла каждый раз.
i3stone, "переустановка" как метод решения проблем - это типичный win-way. В линуксе если повторить те же действия, что были раньше, то как правило ничего не поменяется.
Если читать внимательнее, то видно, что не найден autoreconf при попытке собрать libffi. Вообще, он входит в пакет autoconf, но скорее всего в инструкции по сборке и так ставились пакеты, у которых он есть в зависимостях. Можно, конечно, поставить его самому, но наверняка там ещё десяток других недостающих вылезет.
Илья, никак, такого в Bot API не предусмотрено. Можно ловить только вступления в группу, а точнее даже там ловятся не сами вступления (такого события нет!), а сообщения (объект Message) в чат "такой-то вступил в группу". В канале таких сообщений нет, поэтому узнать о вступлении прямого способа тоже нет.
Получить список подписчиков канала можно только через клиентский (MTProto) API.
Но это всё равно не заработает. Потому что chat_id должен быть чатом группы, где оставлено исходное сообщение. А при форварде информация передаётся только о пользователе-отправителе.
В данном примере ещё и chat_id = личный чат с этим пользователем. А предполагался видимо id чата, где это сообщение оставлялось. Вообще говоря, использовать user_id в качестве chat_id это само по себе плохо, потому что даже для приватных чатов никто не гарантирует, что chat_id будет равно user_id всегда.
Советую попробовать попересылать сообщения боту @ShowJsonBot и посмотреть, какая инфа доходит при пересылке.