dollar

MKV достаточно универсален. Поэтому люди, которые делают рипы, не заморачиваются, не создают себе проблем, и делают рипы в MKV.
Почему не MP4? В основном потому, что контейнер MKV поддерживает все хоть сколько-нибудь популярные кодеки (H.264, H.265, QuickTime...). MP4 - нет. Хотя в данном случае это касается в основном кодеков звука. Потому что вариантов кодирования звука очень много.
Почему не AVI? Он слишком старый и простой. В него нельзя поместить часть нужной информации, плееры иногда должны угадывать параметры сами. Как написали выше, например, это размер пикселя. Хоть я и сомневаюсь, что кто-то из авторов рипов в наше время заморачивается с размерами пикселя, с AVI такого не провернешь. Он популярен, например, в архивах и библиотеках - где нужен максимально простой, не вызывающий никаких проблем контейнер. Кстати, я бы не назвал его популярным, его популярность осталась в начале нулевых. Сейчас у нас в основном MP4, потом примерно поровну MOV и MKV.

В общем и целом MKV используют потому, что это привычно и удобно. А вам, как качающему, должны быть в принципе все равно.

Нет тут никакого кольца.
Есть только ответы от 95.167.94.213 о том, что Destination Unreachable.
Это могло случиться по причине, например, того, что по какой-то причине падала BGP-сессия у провайдерского маршрутизатора с вышестоящим, и, пока переподнималась, он банально "не знал" куда дальше слать ваши данные.
Две-четыре минуты - вполне похоже на время переустановки всей маршрутной информации. Или внутри провайдерской сети какой-то транзитный маршрутизатор перезагружался, и ваш участок в это время выпал из магистральной сети.

Banan44, ваш вопрос дублирует другой ваш вопрос Не работает реализация алгоритма, поможете найти ошибку?

Что значит в реальном времени, у вас ОС реального времени?

1)Может вам не состояние сохранять а вести журнал всех изменений, и по требованию восстанавливать структуру воспроизводя действия из журнала в том же порядке. Как БД делают с транзакциями, журнал транзакций, сначала пишем в него, а потом уже пытаемся выполнить. Только не удалять потом из него, что то вроде Event Sourcing получается. Таким подходом у вас в любой момент можно восстановится до последнего состояния до сбоя/выключения. но лог огромным может быть, их помоему можно склеивать.

Идея такая - посмотреть как работают Inmemory DB, SQL, NoSQL.

2)Идеально было бы не заморачиваться так.
Возможно сдлеать что то типо команд.
В ПО летит команда - сделай что то с объектом.
Вы эту команду кидаете менеджеру.
Менеджер хранит две копии одинаковых объектов, и для каждого из них держит две одинаковые очереди команд. Когда объект готов, он берет команду из своей очереди, и выполняет ее.
Вы нажимаете сохранить копию объекта на диск.
Менеджер берет говорит одному из объектов - сохранись на диск, тот перестает выполнять поступающие команды, и сохраняется на диск. После этого продолжает выполнять команды, догоняя своего соседа. Догонит он его или нет не понятно, но вот что он будет его копией на момент времени Х, определенно.
Памяти будет кушать много (два объекта, две очереди, одна из которых может "опаздывать/догонять"), но в теории должно работать.
Это напоминает асинхронную реплику, только в памяти и там том же устройстве.

2.1) В памяти может быть только один объект. Менеджер при поступлении служебной команды на сохранения объекта, может продолжать складировать обычные команды в очередь дальше, как объект сохраниться, он продолжит брать команды из нее.
Приложение не будет зависать, но и мгновенное выполнение команд не гарантируется.

3) Сделать клон в памяти быстрее чем на диске. Делаем клон в памяти, и сохраняем его на диск, после удаляем (мержить и догонять не нужно, проще удалить целиком и сделать новый когда потребуется).

Используйте fork, дочерний процесс за счёт механизма Copy-on-Write в наследство практически бесплатно получает копию памяти родителя (это если у вас Linux).

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

Мы таким образом дампим индекс размером в десятки гигабайт практически без влияния на производительность и почти без роста затрат памяти, ровно так же это делает например redis (rdb).

Считать, изменить значение ключа, записать назад.

data = json.load(file)
data['Users'] = new_data
json.dump(data, file)

Если под "читабельным" имеются ввиду отступы, то применить indent к json.dump
json.dump(data, file, indent=4)

наиболее точное: зевака
менее точное: зритель

Само слово lurker не имеет четкого значения и употребляется по-разному. Так что и на русский оно переводится не единственным образом: пассивный наблюдатель, паразит, халявщик, зевака. Перевод зависит от того, что именно делает человек и как именно.

Думаю это должно помочь
Венгерская нотация

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

Корридор модульной разницы скиллов - должен быть обязательно.
Иначе не будет: у первых - возможности выиграть, у вторых - интереса/прогресса.
Слитие скилла привязать не к поражениям, а к совокупности: частота игр + поражения (если часто стал проигрывать и играет часто - левел не снижать!).