Vindicar

Ты пытаешься сделать рандомный выбор из введённых значений?
А на кой пельмень ты вообще соединяешь args? Если они разделяются пробелом, то так

# команда вызывается как !choice вариант1 вариант_2 "вариант 3"
@commands.command(pass_context=True)
async def choice(self, ctx, *args:str):
  chosen = random.choice(args)

А если прямо нужно через запятую, то лучше так:

# команда вызывается как !choice вариант1, вариант 2, вариант 3
@commands.command(pass_context=True)
# discord.py интерпретирует * как "всю остальную строку засунь в следующий параметр" 
async def choice(self, ctx, *, args:str): 
  choices = [arg.strip() for arg in args.split(',')]
  chosen = random.choice(choices)

Нужно немножко включить голову и почитать про то, как работает SSH и оболочка Unix системы. Гуглинг типа "SSH keep program running" быстро бы вывел тебя на то что нужно.
1. Когда ты подключаешься по SSH, сервер запускает копию bash или sh (или какая там оболочка используется) с правами твоего пользователя.

<br>
sshd<br>
  - bash<br>

При вводе команды в этой оболочке программа ищется в системном PATH, а в нём находится второй питон.

2. Потом, когда ты делаешь activate, ты переходишь в виртуальное окружение. Оно отличается тем, что питон там ищется по умолчанию другой, так как там поменян PATH (и ещё кое что). И происходит этот переход за счёт запуска дочерней командной оболочки.

<br>
sshd<br>
  - bash<br>
      - activate <br>
          - bash<br>

3. Ты запускаешь свой скрипт. Он запускается из под оболочки внутри activate.

<br>
sshd<br>
  - bash<br>
      - activate<br>
          - bash<br>
              - python3 your_script.py<br>

4. Ты закрываешь putty. SSH сервер регистрирует отключение клиента, и посылает дочернему bash сигнал HUP - обычно он интерпретируется как сигнал на завершение. Тот передаёт этот сигнал своему дочернему процессу, и так далее.

<br>
sshd "sshd: эй, bash, завершайся"<br>
  - bash "bash: эй, activate, завершайся. А теперь я сам завершусь."<br>
      - activate "activate: эй, bash, завершайся. А теперь я сам завершусь"<br>
          - bash "bash: эй, python3, завершайся. А теперь я сам завершусь"<br>
              - python3 your_script.py "python3: хорошо, завершаюсь."<br>

В итоге получаем только работающий ssh сервер
sshd
И когда ты переоткрываешь сессию, activate уже перестал существовать, и ты снова попадаешь в обычный bash, где в PATH прописан только второй питон.

Теперь главное: как же это обойти? Нужно сделать так, чтобы python3 проигнорировал сигнал о завершении. Есть несколько способов.
Самый простой - использовать такой синтаксис:
nohup python3 your_script.py &
Амперсанд в конце означает "запусти программу и вернись в оболочку, не дожидаясь когда программа закончит работать". А команда nohup запускает указанную программу с указанными аргументами, но при этом она проигнорирует сигнал HUP, т.е. "эй, завершайся". А потому когда ты закроешь putty, бот должен остаться работать.
Минус - после переподключения ты не будешь видеть вывод бота в консоль. Так что пиши логи!
Чтобы остановить бота, придётся использовать ps чтобы узнать ID его процесса, и kill чтобы этот процесс прибить. Ну или можешь предусмотреть команду выхода в самом боте, которая завершит работу скрипта изнутри. Это удобнее.

Второй способ - использовать программу screen, если она установлена. Документацию по ней гугли. Если коротко, screen позволяет создать виртуальную рабочую сессию, к которой можно подключатсья и отключаться, не прерывая её. При этом весь вывод на экран сохраняется между переподключениями. Удобно если бот пишет много в консоль, но несколько муторно, и надо учить сочетания клавиш.

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

Не будучи на сервере - нет, насколько я знаю.

> Таблица это сама есть, базу данных я перебросил в корень с исполняемым файлом.
Т.е. ты не пытаешься запаковать БД, так?
А ты уверен, что скрипт её находит? Указываешь полный путь до файла с БД? Или как всегда, относительный, и авось текущая рабочая директория будет правильной?
Просто некоторые py -> exe упаковщики при запуске экзешника распаковывают скрипт во временный каталог, и работают оттуда... а тогда файл БД окажется не рядом со скриптом. Не помню, делает ли так py2exe, выясни.

Кек, сам задавал такой вопрос сегодня на зачёте. Но время что-то не сходится.

Общее:
- Адресное пространство
- - Как следствие, исполняемый код
- - Как следствие, переменные окружения
- Открытые дескрипторы

Различается:
- Стэк: у каждого потока свой, в одном адресном пространстве. но в разных его местах
- Обработчики структурных исключений
- Ну и вообще контекст потока: регистры процессора и т.п.

Питон видит, что ты присваиваешь start_id что-то, и решает что это локальная переменная. А потом понимает, что ты выше её читаешь, и ругается. Это намеренное поведение, так как в противном случае либо:
а) до присваивания бы читалось значение глобального start_id, а после - локального,
б) глобальная переменная всегда изменялась бы вместо локальной, и появление новой глобальной переменной с тем же именем что и локальная где-то в функции приводило бы к её неожиданному изменению.
И то и то неочевидно и могло бы привести к "молчаливому"(без исключений) но неправильному поведению программы.

Если не присваивать, то локальной переменной start_id не существует, и чтение осуществляется из глобальной.

Если так надо менять глобальную переменную, то явно пропиши её в начале функции как global start_id.
А лучше не используй глобальные переменные без нужды. Если их более одной, стоит переделать это в класс.

Как-то так. Никаких гарантий, что дискорд не пошлёт твоего бота далеко и надолго за спам.

@client.command()
async def test(ctx):
    await ctx.author.send(f'test')
    # сохраняем набор и порядок каналов на случай, если он поменяется в процессе отправки.
    channels = list(ctx.guild.text_channels)
    # формируем пачку корутин, выполняющих отправку
    send_coroutines = [channel.send('test') for channel in channels]
    # планируем одновременное выполнение этих корутин и ждём завершения. 
    # Исключения будут возвращены наравне с результатами, а не выброшены.
    results = await asyncio.gather(*send_coroutines, return_exceptions=True)
    # анализируем results на предмет ошибок. 
    # Успешная отправка вернёт объект сообщения, неудачная вернет (а не выбросит!) объект исключения.
    failed = [ (ch.name, str(res)) for res, ch in zip(results, channels) if isinstance(res, (Exception, asyncio.CancelledError)) ]
    if failed: # были ошибки?
        await ctx.author.send('Failed to send to the following channels:\n' + '\n'.join(f'- {ch}: {msg}' for ch, msg in failed))
    else: # ошибок не было
        await ctx.author.send('Message has been spammed successfully.')

Дело не в версии питона, а в том что у тебя для первого i в i['key'] не содержится строка "full.zip". В этом случае питон 3.9 даст точно такую же ошибку, так как первый if не отработает, а второй обратится к time_create.
А вот почему так - уже совсем другой вопрос. Может, разные пакеты установлены на двух версиях питона. Может, просто файлы в files_dict оказываются в немного разном порядке. Я бы посоветовал починить алгоритм в целом, т.е. инициализировать time_create каким-то значением до цикла.

Как всегда, достаточно внимательно прочитать документацию.
Guild.voice_channels: List[VoiceChannel]
Т.е. это список, а ты дергаешь у него какие-то посторонние свойства.
Вот у отдельного VoiceChannel и впрямь есть свойство members: List[Member].

Этот подход удобен для инициализации количества участников при запуске бота.
А вот для отслеживания можно не дергать вышеописанное каждый раз, а поступить иначе. Если before.channel is None, то человек вошел в войс-чат. Если after.channel is None, то человек вышел из войс-чата. Если ни тот ни другой, человек просто перешел из одного войс-канала в другой. Тогда хранишь количество юзеров, и делаешь ему +1/-1 согласно этим условиям.