Сергей П

вы все перепутали. Имя файла, которое указано у вас в конфгурации логирования, оно для лога. Вы можете изменить формат логирования, там есть соответствующий аргумент, а можете открывать надозапись совсем другой файл и писать в него как вам посоветовали в комментариях к вопросу.
А вы, похоже, пытаетесь писать в тот же файл, куда уже пишутся логи. Логи, конечно, перезаписывают то, что вы туда пробовали писать самостоятельно.

Так бывает когда пытаешься переделывать прогу совершенно не понимая что в ней творится. Наймите фрилансера на эту задачу за сто рублей, или учите питон с нуля, он вам может пригодиться и дальше

https://habr.com/ru/post/459112/
Погуглить - не?
Ну а RSS обойти простеньким скриптиком.

Типо Начинающий кодер IT :D, в сообщении нельзя отпрвить видеоролик, который больше допустимого по объёму. Как отправить маленький ролик есть в документации к библиотеке, на которой реализован ваш бот.
Большой фильм можно пересылать только в виде ссылки на страницу просмотра на каком-то ресурсе вроде ютуба, кинопоиска или нетфликсе, или ещё где-то. Невозможно в сообщении прислать фильм целиком в виде вложенного видеоролика. Не поместится.

Один мой стажер делал в качестве тестового задания бота, который ищет через API в базе рутрекера аудиокниги (в разделе аудиокниг) по ключевым слоовам, показывает пронумерованный заголовки раздач. При выборе нужной раздачи запускает скачивание аудиокниги на сверер бота, в процессе апдейтит сообщение о скачивании отражая прогресс, по окончании скачивания присылает ссылку на сгенерированный rss-файл для прослушивания аудикниги в любом подкаст-плеере.
Технически то же самое можно делать и с фильмами, но целиком аудикнига или фильм в сооббщение телеграмма не поместится.

Такого рода проблемы все и всегда решаются однотипно.
1. Необходимо сформулировать критерии наличия проблемы.
Как именно пропадает интернет, насколько часто, как надолго. Это нужно для диагностики. поиска причины и определения ушла ли проблема после принятия каких либо мер.
2. Делить проблему на части и проверять части по отдельности.
Самый эффективный способ делить - это пополам. Отсекаем часть сети и проверяем наличие проблемы в обеих частях (если есть возможность) или в одной из частей.
3. Когда найден минимальный проблемный участок, который уже нельзя или бессмысленно делить - заменяем его.
4. Помним, что чаще всего сложные проблемы - это композиция нескольких более простых. которые по отдельности могут не проявляться. В вашем случае может быть проблема, связанная с нагрузкой на роутер, например, которую создает один из услов из-за плохого контакта обжима и большого объёма биттых пакетов. Устранив одну из причин, вы, может быть, сделаете проявления проблемы реже, но не устраните её полностью. К примеру, если замените ротуер, битые пакеты будут всё равно будут нагружать вашу сеть и портить ее производительность, но это будет не так очевидно. Переобжав коннектор вы избавитесь от части нагрузки, но еслив ваш ротуер работал на переделе, то лишний вафай-клиент или тяжелый видос в сети сможет его снова нагрузить до критического снижения производительности.

Итак, пробежимся по перечисленным пунктам сначала.
1. Критерии. Поиск критериев - это часть решения. Обычно в этом случае нуно сорать необходимую статистику. Есть куча софта, который это умеет делать, но пинг есть всегда под рукой.
Для этой тулзы есть две полезных опции: ключ для бесконечного пинга и размер пакета.
В разных ОС эти ключи немного разные, поэтому ищите их отдельно, у меня нет винды под рукой, поэтому не стану на этом заострять.
Скаж лишь, что пинговать лучше большими пакетами, жалетально превышающими размер TTL, прописанный в роутере. Тогда такой пинг будет реже проскакивать в периоды хорошей связи, то есть выловит больше пролблем.
Пинговать нужно в отдельных окнах сразу несколько хостов:
- ya.ru - этот хост всегда отвечает на пинги и выявит проблемы с DNS
- 8.8.8.8 - это гугловый DNS-сервер, тоже всегда отвечает на пинги, покажет, что связь с инетом есть даже если DNS, прописанныйна компе не правильно работает.
- 192.168.0.1 - или какой там IP у вашего роутера. Нужно. чтбы отделить проблемы с инетом от проблем с внутренней связностью до роутера
- 192.168.0.x - ip одного из компов в сети. Я обычно пингую несколько компов, доступных через баксимальное число потенциально проблемных узлов - ethernet-розеток, свичей, вайфай-соединений... Этот пинг поможет понять где проблема, во внутрисетевой связности или в последней миле.

Учтите, что проблемы часто бывают комбинированные и каждое сочетание симптомов будет свидетельствовать о раных проблемах.
Да, тревожным принаком может служить не только пропадание пакетов, но и скачки в длительности их возврата, особенно если такие длительности достигают 500мс и выше. Но и скачки от 3мс до 250мс тоже будут свидетельствовать о каких-то проблемах.

Запускать пинг на всех компах лучше одновременно и на некоторое время. Например минут на 20. Потом по статистике будет видно сколько где пакетов пропало.

2. Если критерии наличия проблемы позволяют, то можно попробовать отрубать части сети и смотреть наличие проблемы. Это я в том смысле, что если проблема происходит в среднем раз в пару-тройку часов, то отрубать на многие часы части сети при диагностикем ожет быть неприемлемым.
Редкеи пробемы дольше отлавливать. Но напоминаю, что критерии можно детализировать, ведь если пакеты у вас пропадат относительно редко, то скачки времени их возврата могут случаться чаще и подсвечивать проблему. Также можно сделать рамер пакета близким к максимальному, это должно тоже в некоторых случаях участить проявление проблемы.
Иногда не мешает нагрузить сеть комированием по локалке большого файла. В линуксе можнно с помощью утилиты tc послать большой поток рандомных байт на любой сокет..
3. Плавающие проблемы случаются из-за плохого обжима, перебитого жверью кабеля, перегрызенного UTP в плинтусе, из-за умиращих конденсаторов в блоке питания роутера (БП может не выдавать необходимого при нагрузках тока, но вольтметром такая неисправность не будет различима без нагрузки). Вообще старые (да и не только) роутеры могут страдать поплывшими электролитическими конденсаторами не только в блоках питания.
Хорошо, когда можно подменить роутер.
4. ну с четвертым пунктом ничего не пососветуешь, только разделать и тестировать все по отедльности и в разных сочетания и да поможет нам ктулху.

А для тех, кто дочитал этот опус до конйа - интересная задачка. Что пингуют эти команды, как и почему?

ping 1.1
ping 2130706433

Тех, кто знает, попрошу не спойлерить=)
Пусть для кого-то будет сюрпризом этот дивный мир=)

UPD. Простите за адское количество опечаток в тексте. Писал в спешке и с непривычной клавиатуры. Исправлю всё попозже. Не ожидал, что многим ответ придётся по душе. Вроде ж накапитанил как мог.

С помощью TTS я через AlReader слушал. В принципе, приемлемо. Но всё же предпочитаю искать на торрентах книги в живлй озвучке и слушать Podcast Addict'ом.
Даже наловчился скриптом rss делать и заивать на vds, чтобы книга не сразу весь объём на смартфоне занимала, а по главам загружалась, хотя с современными смартфонами это вообще не критично.

"x.x.x.x" - это невалидный ip-адрес и домена такого не существует.
С чего вы взязли, что проблема в CORS? При GET-запросах CORS не задействуется.

Дополню соседний ответ для ясности.
Не нужно городить монолит из совершенно разных сервисов.
Если боту не обязательно реагировать на появление новых уведомлений в БД очень быстро, то можно сделать чтобы бот просто читал с некоторой периодичностьб ту же БД, что прописана в джанго. Можно построить индекс по таймштампу события и вычитывать все, что позднее прошлой проверки. Это будет и быстро и эффективно.
Если реакция нужна очень быстрой, то лучше сделать очередь и применить pub\sub механизм. Бот подписывается на тред событий, а джанго пушит в него сообщения.
Вполне можно в этом качестве использовать, например, rabbitmq.

Если это просто односторонние уведомления, то, кстати, можно слать их прямо из кода на джанго через API. Но это если у бота нет интерактиности никакой с пользователем.

Джанго также отлично позволяет обрабатывать много урлов одним view. Можно просто зароутить все после слеша и парсить хвост урла как адресную цепочку.

Как правило в таких способах представления адреса нужно стараться избегать отдельных запросов к БД по стране, городу, улице, дому. В идеале нужно доставать всю необходимую информацию за один запрос.
Тут становится важным как устроена ваша БД. Обычно адресные элементы индентифицируются не по названию, ведь название, в данном случае, - это плохой идентификатор. Он с одной стороны громоздкий (Санкт-Петербург), а, с другой, есть проблемы с уникальностью для мелких населенных пунктов. А ещё топонимы чаще всего интенационализируются, то есть на разных языках они пишутся по-разному. Кроме того, адреса в рахных странах могут записываться по-разному, встречаются совершенно разные уровни административного деления, разные схемы подчинения административных единиц.
К примеру, в РФ есть области (автономные области, края), районы, сёла, посёлки городского типа, микрорайоны, да и дома - это не рпосто нумерация, там есть дроби, литеры, корпуса...
Каждй раз когда я вижу, что кто-то пытается такую сложныю предметную область формализовать в виде элементов URL, я срашиваю, а зачем это вообще нужно? URL - это не самая удобная штука для непосредственного ввода человеком. Особенно много вопросов вызовут топонимы с пробелами, дефисами, сокрашениями (С. Петербург, Питер). Для чего всё это? Не проще ли воспользоваться идентификатором адресной единицы от одного из адресных справочников вроде OKATO? Понятно что в разных странах эти справочники разные, но тут в любом случае надо делать разную логику.
Я бы не заморачивался излишней читаемостью урлов в таком вот случае, а просто добавил бы префикс, однозначно указывающий на "домен" адресного пространства, и следом бы указывал идентификатор внутри этого адресного пространства. Вот смотрите сколько их бывает: https://classifikators.ru
К примеру:
/okato/70228870004

Зачем искать расстановку, если этого не требуется по условию задачи?
Представим, что мы знаем самую оптимальную расстановку жуков на окружности.
Нужно найти время, когда все жуки займут свое место, и это время будет не ранее, чем последний жук займёт свое место, то есть жук, которому идти самый длинный путь.
Таких жуков может быть несколько. В одном из частных случаев все жуки в 0.0 и им всем идти R секунд до своего места, а займут они свое место одновременно. В этом случае не важно какого жука мы выберем последним.

Итак, у нас есть жук, которому ползти максимальное время до своей точки на круге. Для каждого жука можно найти самую дальнюю точку окружности. Последним жуком будет (скорее всего) тот, который ближе всего к своей самой дальней точке.
На каждых 1\N радианах дуги окружности должна быть одна финальная точка.
Нужно найти самую дальнюю дугу длиной R/N от всех жуков, а потом жука, который ближе всех к одному из краёв этой дуги. Остальные жуки уж точно доползут до своих точек быстрее этого.

Тут не поощряется публикация заданий без попытки самостоятельного решения.
В ответе тоже не буду давать вам готового решения, поскольку это "медвежья услуга".

Могу дать подсказку как решать вашу задачу.
Во-первых, следует отметить, что во втором, заблокированном вашем вопросе, формат входных данных отличается от озвученного здесь. Нужно тщательнее и аккуратнее приводить примеры.
Любую относительно сложную задачу нужно разбивать на блее простые подзадачи и решать их отдельно и изолированнно.

В данном случае входной список вам следует сначала разделить на набор отдельных списков, где в каждом первым элементом будет ваш идентификатор, а дальше список ключей и значений. Это можно оформить отдельной функцией. В том, втором вопросе было видно, что разделить входную последовательность можно, например, по значению 'ID'. В примерах, приведённых здесь, нет такихэлементов, поэтому тут придётся ориентироваться на тип или четность...
Когда у вас будет последовательность списков, первый элемент - ключ всего списка, легко отделить слайсом, а весь хвост можно легко превратить в пары ключ-значение вот таким вот способом:

In [1]: lst=[1,2,3,4,5,6]

In [2]: dict(zip(itr:=iter(lst), itr))
Out[2]: {1: 2, 3: 4, 5: 6}

Ну а если вы не сообразите, как увязать воедино все приведенные мной тут примеры, то вам еще рано решать такие задачи, нужно сделать пару шагов назад и осваивать базовые основы языка.

У вас 3.11 питон. Гляньте есть ли совместмость у ваших библиотек с этой версией. Возможно они еще не сделали релиз под 3.11.

Загрузитесь с LiveCD или загрузочной флешки с Ubuntu, примонтируйте раздел и удалите.

Вы слишком широко вопрос поставили. Почему сразу не спросили как стать богатым и знаменитым? Ну и чтобы вам ещё и денег дали в доказательство работоспособности ответа.

К предыдущему ответу по существу могу вот нагугленный с первой попытки вопрос со стэк-оверфлоу предложить: https://stackoverflow.com/questions/35097837/captu...

Однако, судя по постановке вопроса, не думаю, что вы сможете собрать всё это в работоспособную кучу.