Vindicar

Во-первых, оформи код, нечитаемо. Кнопка </> в помощь.
Во-вторых, matchTemplate(), насколько я знаю, не-инвариантна к поворотам и масштабу. Иными словами, поворот или изменение размера целевого объекта сломают сопоставление.
В-третьих, на показанном кадре более одного экземпляра целевого объекта. Так предполагается или нет? Если предполагается, сколько экземпляров ожидается? Потому что разница очень большая с точки зрения методики.

Варианта тут три.
1. пытаться обучать под задачу нейронку. А лучше дообучить существующую, скажем, YOLOv5. Но тебе потребуется минимум несколько сотен размеченных изображений объекта в разных комбинациях, плюс в 2-3 раза больше похожих изображений без целевого объекта. Готовить такую базу будет утомительно, да и само обучение требует понимания что ты делаешь.
2. попробовать зафиксировать угол поворота или масштаб (т.е. допустить, что он всегда одинаков). Тогда другой параметр можно будет подбирать. Например, мы фиксируем масштаб и делаем 16 изображений объекта в разных поворотах, а потом поочерёдно ищем каждый вариант на кадре. Потом анализируем силу откликов - сколько их, насколько они сильные и т.д. Скорее всего, будет медленно
3. взять за основу поиск по локальным особенностям. Он справляется с масштабом и поворотом, но не справляется с несколькими экземплярами объекта. Это можно забороть, если использовать скользящее окно. Иными словами, находим на кадре узнаваемые точки - локальные особенности (желательно достаточно много и достаточно плотно), используя алгоритмы вроде ORB или SIFT. Затем выбираем те из них, которые попадают в прямоугольную рамку-окно. Затем сверяем эти особенности с особенностями объекта, используя RANSAC или подобный метод. Если получилось хороше совпадение - значит, в этой рамке есть объект или значительная его часть, и мы можем оценить его позицию в кадре в целом. Повторяем процесс, сдвигая рамку, пока оно не "обойдёт" всё изображение. Тоже может быть небыстро, так как нам требуется неоднократный поиск по картинке.

Тебе модель, скорее всего, отдаст экземпляр класса Detections.
Если его посмотреть, там есть несколько полезных методов, например, render(), который возвращает список обработанных изображений с отрисованными объектами. А ещё у него есть свойства imgs, xywh и names, чтобы получить обработанные изображения, рамки и классы найденного. Экспериментируй с ними
Не забываем, что модель рассчитана на подачу пачки изображений, просто эта пачка может содержать и только одно изображение. Отсюда и множественное число, и постоянные массивы.

Открываем документацию к discord.py, изучаем.
Вот тебе ссылка на нужный раздел.
Искать информацию по незнакомой теме тоже нужно учиться.

C:\Users\Владелец\OneDrive\Рабочий стол\faeil не делает ровным счётом ничего.
Если ты пытаешься сменить текущий рабочий каталог, тебе нужно использовать команду cd.
А так как твой путь содержит пробелы, его нужно заключить в кавычки.
cd "C:\Users\Владелец\OneDrive\Рабочий стол\faeil"

Проблема, я полагаю, та же что и всегда - несколько обработчиков с func=lambda call: True.

Ну во-первых, у тебя четыре задачи.
1. Фронт. На каких платформах планируешь клиенты? Веб-клиент позволяет охватить много устройств, но он также может оказаться наиболее прожорливым по ресурсам. Если планируешь отдельные клиенты под отдельные платформы - надо смотреть отдельно под каждую платформу. Сразу исходи из того, что универсального решения не будет.
Под веб, разумеется, надо учить веб-стэк - как вообще работает HTTP, основы HTML+JS+CSS, скорее всего, придётся ознакомиться с каким-то JS-фреймворком, потому что на голом JS удобно писать только достаточно простой клиент. Стоит также заглянуть в сторону вебсокетов.
2. Протокол обмена. Их много разных - и это если не изобретать свой велосипед. Текстовые протоколы проще в отладке. Бинарные - компактнее (экономит трафик). Некоторые протоколы работают строго в рамках модели запрос клиента -ответ сервера (как HTTP), некоторые позволяют любому концу соединения проявлять инициативу. В твоей задаче запрос-ответ будет работать так себе. Читай про существующие универсальные протоколы обмена, такие как JSON-RPC или gRPC. Загляни в сторону REST. Да хоть старичка IRC посмотри. Важны моменты: многословность протокола (сколько надо передать байт по сети на N символов текста? А на N байт бинарного контента?), ограничения на передаваемые данные (например, можно ли передавать произвольные бинарные данные?), наличие библиотек для работы с протоколом, устойчивость к разрывам соединения, и т.д.
3. Бэк (сервер). В твоей задаче бэку лучше быть событийно-ориентированным, поэтому надо понимать суть событийно-ориентированной архитектуры. Соответственно, исходя из выбора протокола, выбираешь язык, для которого есть библиотеки под этот протокол, и в идеале который тебе знаком. Разбираешься, как организуется работа с этими библиотеками.
Продумываешь, какими сущностями ты будешь оперировать. Например, у тебя будут только чаты 1 на 1, или будут групповые чаты? А если групповые чаты, они будут одноранговые, или будут иметь структуру, типа серверов в Дискорде? Затем продумываешь, как ты это будешь хранить в базе данных.
Да, с базами данных надо быть знакомым.

Ну и задача №0, которую я описываю последней. Определи, под какую нишу ты делаешь свой мессенджер, кто будет им пользоваться, что для них будет важно? Условно, мессенджер, который предназначен для координации действий группы людей на реальной местности, это не то же, что месседжер, предназначенный для общения внутри корпорации, и не то же, что мессенджер, предназначенный для домовой/общажной локалки, где может не быть одного выделенного сервера.
В частности, важным вопросом будет структура сети. Централизованная, как Телеграм? "Лес", где может быть несколько серверов, но они не вазимодействуют? Федеративная, как e-mail или matrix, где можно поднять свой сервер, и взаимодействовать с клиентами других серверов? Одноранговая (P2P), как Tox? Это сильно повлияет и на целевую аудиторию, и на устройство протокола.

Плохой образец для подражания выбрал - там почему-то код на питоне вперемешку с HTML-разметкой.
Лучше поищи официальные доки и учись по ним.

Делишь задачу на под-задачи. Допустим, у тебя есть строка-исходный текст text и строка-ключ key, а также список строк, содержащий алфавит языка alpha.
Определяешь функцию, заменяющую символ по шифру:

# принимает символ открытого текста, его позицию в тексте, строку-ключ и алфавит
# возвращаем символ шифротекста
def viginere_encode(text_char: str, i: int, key: str, alpha: list[str]) -> str:
  if text_char not in alpha:  # незнакомый символ?
    return text_char  # оставляем его как есть
  text_char_code = alpha.index(text_char)  # номер символа открытого текста в алфавите
  key_char = key[i % len(key)]  # символ ключа, соответствующего i-му символу открытого текста 
  key_char_code = alpha.index(key_char)   # номер символа ключа в алфавите
  cypher_char_code = (text_char_code + key_char_code) % len(alpha)  # номер символа шифротекста
  return alpha[cypher_char_code]  # возвращаем символ шифротекста

А дальше применяем эту функцию к строке:

cipher_text = ''
for i in range(len(text)):
  cipher_text += viginere_encode(text[i], i, key, alpha)

Вот и всё. Да, тут много чего можно оптимизировать, но я старался писать как можно проще.

Я бы не советовал трогать crontab.
Есть же cron.hourly, cron.daily, и т.п., в которых можно создать свой, отдельный скрипт.
Или есть cron.d, в котором каждый файл интерпретируется как мини-crontab.

У тебя, судя по скрину, используется виртуальное окружение проекта (.venv).
Ты в него ставил либу, или в глобальный интерпретатор?

Всё проще.
У тебя во второй и третьей строке у start() скобки пропущены.

Вот только цикл while там ну очень не очень. Хотя бы задержку секунд 20 поставь, а то нарвёшься на бан на сайте, или просто подвесишь комп диким числом потоков.

Как правильно посоветовали в комментариях, разбей задачу на меньшие.
1. Как получить данные с сайта университета? Смотри в сторону пакета requests.
Также тебе потребуется понять, как сам сайт выкладывает эти данные. Просто сохрани скачанную страницу в файл и посмотри, есть ли внутри данные, которые тебе нужны. Вообще советую сохзранять страницу в файл при любой ошибке, чтобы понять, не послал ли тебя сервер на крайний север. =)

Если данные записаны прямо в страницу, можешь использовать, скажем, BeautifulSoup, чтобы выцарапать их из HTML разметки.
Если же данных в странице нет, значит, сайт делает отдельный XHR запрос для подгрузки данных. Открой страницу расписания, и на этой вкладке открой панель разработчика в бразуере (обычно F12), а затем обнови страницу. Посмотри на запросы (там может быть фильтр по XHR, используй его) и найди тот, который подгружает что-то, похожее на нужные данные.
Тут могут быть два варианта: подгружается HTML разметка - тогда снова смотри в сторону BeautifulSoup. Или подгружается JSON - тогда используй встроенный в питон модуль json.
2. Так или иначе, ты должен будешь построить структуру данных, которая хранит требуемую тебе инфу. Например, список из словарей, где каждый словарь описывает одну пару. Структуру строй так, чтобы тебе с ней было удобно работать. Анализируя полученные в п. 1 данные, заполни эту структуру.
3. Выбери, с каким календарём ты всё-таки работаешь, и погугли, есть ли у него API. Привыкай искать и читать оригинальную документацию! Чатгпт и прочее может врать или ссылаться на устаревшие сведения.
Скорее всего API будет сводиться к HTTP запросам, которые можно будет выполнить с помощью всё того же requests.

Т.е. тебе нужно конкатенировать списки, а потом преобразовать?
Простой способ будет:

all_lists_together = sum(lists, [])  # склеиваем списки в один, по порядку
all_lists_as_string = '\n'.join(all_lists_together)  # а дальше обрабатываем этот список

Можно без питона. Посмотри в сторону Планировщика задач в винде, например. Планируешь выполнение утилиты shutdown чтобы отключить комп, а чтобы разбудить - планируешь запуск любой проги и ставишь галку ""Включить компьютер для этой задачи".

Какой эквивалент для пробуждения в никсах - не знаю, увы. А вот shutdown есть и там.

send_length += b' ' * (HEADER - len(send_length))
Я не вполне понял, но зачем ты сразу после длины сообщения дописываешь пробелы?
Да ещё с ориентировкой на длину строкового представления длины сообщения?
Не говоря уже о том, что ты фиксируешь длину сообщения в символах, а передаёшь сообщение в байтах в некоторой кодировке... а ведь есть многобайтовые кодировки, типа utf-8. Там эти длины не будут совпадать, и более того, две строки одной длины в символах могут иметь разную длину в байтах, и наоборот.
Ну и до кучи, ты передаёшь длину сообщения как строку. А как ты определишь длину этой строки?

Позволяет. Использовать эту возможность не советую, и в придачу к приведённым выше причинам добавлю ещё одну, очень простую: ключевые слова и вся стандартная библиотека языка на латинице. Задолбаешься переключать раскладку.