Инструменты пользователя

Инструменты сайта


draft

Платформа

Нажмите, чтобы отобразить

Нажмите, чтобы скрыть

  1. Hard.
    • Бесшумный рабочий компьютер: временные наброски для сборки fanless PC:
      1. Кулер для пассива Nofan CR-95C IcePipe Fanless, но скорее всего именно Prolimatech Genesis как в два раза более дешевый;
      2. Core i5, возможно на Sandy Bridge, а не на новом Ivy Bridge, который якобы горячее. Например i5-2500K (чем K отличается от не-K? видео?), из новых это i5-3570K;
      3. память 2 планки по 4 Гб, возможно 4 по 4;
      4. SSD OCZ Agility 3;
      5. Корпус пока под вопросом.
    • Новый рабочий сервер: временные наброски, пока дороговат
      1. Кулер Noctua NH-U14S ~$90 1);
      2. CPU Intel Core i7-4771 - не брать 4770K (~$350) т.к. это обрезанная версия без виртуализации, можно взять обычный 4770 (~$300), но лучше золотую середину 4771 (~$330), который имеет все фишки 4770 и скорость 4770K, только без разгона, который не нужен для сервера, подождать пока появятся предложения с нормальной гарантией т.к. 4771 вышел в сентябре 2013-го. Второй вариант 4770S [он и выбран!] (~$310) - частота 3.1 по умолчанию, раскачивается до тех же 3.9, но зато тепловой пакет 65W, а не 84W и стоит чуть дешевле! ~$300-350 2);
      3. память 2 планки по 8 Гб, возможно 4 по 8 - но пока цены СИЛЬНО выросли, с ~90-100 за пару до ~150-160 (2) или ~$320 за четыре, можно временно использовать вторую планку с домашнего компа 3);
      4. Материнская плата на Z87 с минимум 3 PCI-E слотами и двойной гигабитной сетью, стоимость очень большая! От $250 4);
      5. Корпус остается старый.
    • NAS. Конфигурация сегодняшнего дня: тут ничего выдающегося (используется как NAS + сервер для обработки траффика, проксирования и прочих полезных вещей):
      1. Большой корпус (Chieftec BA-01, Big Tower), много места под HDD (8 внутренних 3.5«, 6 отсеков 5.25»), отличная вентиляция 5)
      2. Материнская плата с 8 SATA-II (Intel D975XBX2, 4 SATA чипсетные, 4 от Marvel, 3 PCI-E разъема) 6)
      3. ECC память Kingston 2 Gb 7)
      4. Отдельный контроллер на еще 8 SATA-II для RAID (3ware 9650-SE) 8)
      5. Гигабитная сеть на базе D-Link DES-1216T с доработанным вентилятором 9)
      6. SATA Backplane в 3 отсека 5.25« (SNT-3051 SATA) на 5 дисков, для их быстрого подключения 10)
    • DAS. Кофигурация обдумываемая: пока много белых пятен: с раздельным запуском винчестеров, выключением/включением по необходимости, каблированием, созданием рамы и т.п.; буду рад любой помощи. Основная задача - пускай и с потерей скорости, но иметь доступ ко всем винчестерам:
      1. Отсутствие корпуса как такового (!), рамой будут служить рейки, с прикрученными к ним винчестерам. Вентиляция посредством 120мм вентиляторов, по одному-два на блок из 5 винчестеров (всего места зарезервировано под 20 винчестеров), установленных перед ними, и закрепленных так, чтобы было возможно их быстро снять
      2. Порт мультипликатор (на Sil3726, 5 внутренних SATA, 1 внешний eSATA), по одному на каждые 5 винчестеров
      3. Отдельный контроллер на 4 внеших eSATA-II (HighPoint RocketRAID 2304, PCI-E 4x) для установки в NAS (!). При наличии двух свободных PCI-E 4x+ можно обойтись парой более дешевых SiL3132 (A-400 например). Но можно также рассмотреть вариант с восьмипортовым HighPoint RocketRAID 2680, PCI-E 4x, при условии если найти длинный кабель Mini-SAS (4 шт.) на eSATA (ниже) и чтобы два таких кабеля стоили меньше $200+стоимость 8 eSATA-eSATA кабелей :)
      4. 8 eSATA-eSATA кабелей либо 2 Mini-SAS-eSATA кабеля для соединения NAS и DAS
      5. БП (~300-400 Вт, с запасом по 12В линиям, но не сильно мощный, даже 20 винчестеров в процессе работы не потребляют больше 150 Вт (с поправкой на КПД), важно только пускать их по очереди, или по необходимости); переходники SATA питания и питания вентиляторов, короткие SATA кабели (возможно придется поискать чтобы сделали под заказ разной длины?) для подключения к мультпликатору
    • DAS. Кофигурация собираемая: конечная цель - полка на 32 винчестера, подключаемая одним SAS кабелем к NAS серверу (плюс COM/USB для управления), 8 групп по 4 винчестера и 1 вентилятору (120×120) на каждую, вентиляторы контролируются чем-то вроде Amtel COM/USB, возможно также использовать датчики температуры, чтобы запускать вентиляторы по необходимости, при их дороговизне переложить контроль на сервер.
      1. Вентиляторы 120×120 на долговечных подшипниках (Scythe SFF21D 800 (альтернативы на будущее с учетом использования реобаса: SFF21E 1200, SFF21F 1600, SFF21G 1900)). Стоимость: $17 * 8, куплено 11)
      2. Реобас 4 канальный с датчиками температуры (Scythe Kaze Server 5.25). Для контроля пары вентиляторов на вдув/выдув и автоматическом отключении каждой из 4 пар при низкой температуре (!). После покупки обдумать куда ставить датчик температуры, возможно в самую середину между 8-ю винчестерами. Стоимость: $57, не куплено 12)
      3. Корпус самодельный, конфигурация обдумывается, т.к. зависит от размеров БП, экспандера, того как запитать экспандер, как проложить кабели и будут ли использованы backplane. Стоимость: ???, не куплено
      4. БП промышленный, раздельно для 12В (~210-240 Вт) и 5В (~150-160 Вт). Расчет произведен на базе данных с сайта WD для WD20EARS, с небольшим запасом. Обязательно использовать амперметры (до 20А?) чтобы наглядно видеть что происходит с нагрузкой! Благо стрелочные весьма дешевые, если будет двухрежимный электронный, пристроить его. Стоимость: ???, не куплено
        ЛИБО
        БП модульный (Thermaltake Cable Management?). Самый «слабый» это на 450 Вт. Подумать как самому сделать такие же модульные кабели нужной для корпуса длины. Распиновка модульного кабеля (слева направо, в БП, защелка сверху: 3.3V, 5V, GND, GND, 12V). Также можно запитать экспандер от разъема для мат.платы. Стоимость: ~$60, не куплено 13)
      5. SAS Backplane (4U Supermicro BPN-SAS-846-7EL1 SAS8467EL1 SAS/SATA 24-Port SAS1 Backplane) - является частью корпуса Supermicro 846 и позволяет подключить 24 диска. Питание - 6 молексов, три SFF-8086 коннектора, причем только один на вход, остальные два для каскадирования. Б/у на ебей можно найти за ~$100 (есть и дороже, по 200). Теоретически именно такой бекплейн лучше всего позволяет собрать корпус с 24/48/72/96 дисками в вертикальном исполнении. Вопросы будут только с промежуточным охлаждением и размещением блока питания.
      6. SAS экспандер (HP SAS Expander 468406-B21, «зеленый» с прошивкой 1.52+ 14)) с одним внешним SFF-8088 коннектором и восемью внутренними SFF-8087 коннекторами. Позволит подключить 32 винчестера к 4 портам внешнего SAS контроллера. Требует PCI-E для питания, поэтому придется что-то специально делать для его подключения (Распиновка PCI-E разъема: http://en.wikipedia.org/wiki/PCI_Express, резистор на 10 кОм надо подключить МЕЖДУ A10 (+3.3V) и A11 (PWRGD) на стороне PCI-E коннектора. Также надо взять: +12V от БП ко всем пинам на PCI-E: A2, A3, B1, B2, B3; +3.3V от БП ко всем пинам на PCI-E: A9, A10, B8, B10 (aux); PWRGD от БП подключить к PCI-E: A11; В свою очередь пин A11 получит свои 3.3V через резистор от пина B10 (или от A10); Также думаю что надо соединить и землю от БП к пинам на PCI-E: A4, B4, B7 (вопрос, надо ли объединить все земельные пины, включая A12, A15, A18, B13, B16 и B18?); Итого 12 (18?) проводков + ответвление на резистор). Стоимость: $300, куплено 15) 16) 17)
      7. Кабель SFF-8088↔SFF-8088 для соединения SAS HBA с SAS экспандером. Стоимость: $23, куплено 18)
      8. Кабель SFF-8088↔4xSATA для тестов и соединения SAS HBA с SATA винчестерами напрямую. Стоимость: $26, куплено 19)
      9. Кабель SFF-8087→SFF-8482 (либо SFF-8087↔SFF-8087 если найдется недорогой backplane board) для соединения SAS экспандера с винчестерами. К данному коннектору подводится питание молексом. Т.е. соединять винчестер удобно. Однако уточнить питание на 15pin или на 4pin - 8442 вроде как не держит нормального SATA питания (для SAS винчестеров достаточно 4pin!) и все равно требуется вставлять «адаптер»! Обдумать имеет ли это смысл или стоит взять более дешевые SFF-8087→4xSATA. Обязательно проверить сколько пинов в MiniSAS разъеме - 26 или 36, т.к. оказывается что в разных карточках по-разному, хотя именно 36 это стандарт для SFF-8087 ;( Также на основании чертежа корпуса выяснить необходимую длину: 0.5 или 1м. Стоимость: ~$12-20*8, не куплено
      10. SAS HBA в сервер (LSI SAS3801E) с двумя внешними SFF-8088 коннекторами на 8 портов. Позволит в теории подключить две полки на 64 винчестера в сумме, но винчестеры не больше 2 Тб! :) Стоимость: $125, куплено 20)
      11. SAS HBA (LSI SAS3801E-R) с двумя внутренними SFF-8087 коннекторами на 8 портов. Альтернатива для предыдущей, подходит для внутреннего подключения к экспандеру при условии double-link'а и конечного числа портов в 24, на будущее 21)
      12. SAS HBA в сервер (LSI SAS 9200-8E) с двумя внешними SFF-8088 коннекторами на 8 портов. Позволит в теории подключить две полки на 64 винчестера в сумме и винчестеры больше 2 Тб! Стоимость: $170, куплено 22)
      13. (на будущее) Лучший вариант - LSI 9207-8i на чипе LSI 2308. Нет ограничений на диски свыше 2ТВ (как в старых LSI HBA на чипах 1068), и работает безглючно на всех Xeon'ах от 53xx до e5-26xx, в отличие от предыдущего чипа LSI 2008.
    • Конфигурация на 45 HDD пример (очень дорого): http://blog.backblaze.com/2009/09/01/petabytes-on-a-budget-how-to-build-cheap-cloud-storage/
    • DAS на 45 HDD. Фирменный (очень дорого): http://www.supermicro.com/products/chassis/4U/847/SC847E16-RJBOD1.cfm 23)
    • Что важно: когда дисков много, в них очень легко запутаться. Чтобы такого не случалось, каждый диск промаркирован маркером на спиртовой основе (легко смывается при необходимости) сзади, на стороне разъемов, та же метка диска ставится на файловую систему (disk label). Клиенты - ноутбуки (под Linux), HTPC, который берет файлы по сети.
  2. Soft. В качестве основы для хранения своей коллекции я выбрал Linux. Работая долгое время под Windows я постоянно сталкивался с рядом ограничений, в частности с запретом на использование некоторых важных символов (двоеточие, знак вопроса, три точки в конце и т.п.). К счастью, бурное развитие Linux как платформы для работы и отказ от ориентации исключительно на серверное применение позволил мне полностью перейти на Linux.
  3. На файловом уровне используется XFS. Такой выбор обусловлен рядом причин: XFS на порядок лучше работает с большими файлами, доступная емкость диска больше чем у ext3 (на ~1%) и равна емкости NTFS. Каждый диск имеет собственную метку (disk label) в дополнение к UUID, чтобы различать их и автоматически (TODO) монтировать в нужные папки.
  4. На транспортном уровне используется NFS (для Linux клиентов), т.к. Samba из-за своей Windows сущности не пропускает те самые спец. символы 24). Для Windows клиентов (тот же HTPC, чтобы воспроизводить образы или простые игрушки) работает workaround, сделаны симлинки на папки без тех самых, так мною любимых, спец. символов и запущена Samba.


Структура папок

Нажмите, чтобы отобразить

Нажмите, чтобы скрыть

  1. Контент я для себя поделил на классы, типы и форматы. Деление несколько условное (в частности «форматом» может быть просто категория), но отвечает моим потребностям:
    1. Классы: files, games, audio, video
    2. Типы: lib (files), linux (files), palmos (files), linux (files), psp (files), scripts (files), windows (files), pc (games), psp (games), xbox360 (games), mobile (games), music (audio, video), sounds (audio), animation (video), clips (video), movies (video), serials (video), sport (video)
    3. Форматы: категории файлов (files), fullrip (games), rip (games), java (games), iso (games), compressed (audio), lossless (audio), screen (video), tvrip (video), vcd (video), dvd (video), sdrip (video), hdrip720 (video), hdrip1080 (video), hdremux (video), hddvd (video), bluray (video)
  2. В результате получаю довольно ясную структуру (пример, могут быть внесены небольшие изменения по необходимости):
    audio/
    audio.music/
    audio.music.compressed/
    audio.music.lossless/
    audio.sounds/
    files/
    files.lib/
    files.linux/
    files.palmos/
    files.psp/
    files.scripts/
    files.windows/
    games/
    games.pc/
    games.pc.casual/
    games.pc.files/
    games.pc.installed/
    games.pc.sources/
    games.psp/
    games.psp.fullrip/
    games.psp.rip/
    games.xbox360/
    games.xbox360.iso/
    video/
    video.animation/
    video.animation.dvd/
    video.animation.sdrip/
    video.clips/
    video.movies/
    video.movies.bluray/
    video.movies.dvd/
    video.movies.sdrip/
    video.movies.hdremux/
    video.movies.hdrip1080/
    video.movies.hdrip720/
    video.movies.tvrip/
    video.music/
    video.music.bluray/
    video.music.hdremux/
    video.music.vcd/
    video.other/
    video.serials/
    video.serials.sdrip/
    video.serials.hdrip1080/
    video.sport/
    video.sport.dvd/
    video.sport.sdrip/
  3. Именование внутри форматов осуществляется по своим правилам и зависит в первую очередь от класса, в настоящее время регламентируются только игры (в процессе, т.к. добавляется сложный тип ps3) и видео:
    1. Игры (games): именуются по алфавиту, по-английски, каждое слово начинается с заглавной буквы, при отсутствии английского названия, по-русски. Пока не используется двойное именование как в видео, хотя вполне возможно.
    2. Видео (video): именуются по сложной схеме, где разделителем является дефис:
      • Одиночные релизы:
        1. год выпуска фильма (для сезонов, концертов на рубеже годов - ранний; диапазон годов пишется в квадратных скобках, если наименование уже не содержит его, ниже)
        2. русское наименование (если есть)
        3. английское наименование (если есть)
        4. оригинальное наименование (если есть и не русское/английское).
        5. При наличии употребимых альтернативных наименований, они пишутся в скобках сразу после каждого из наименований, желательно опускать повтор для английского и оригинального наименований.
        6. Затем (если есть) диапазон лет (выше), и в самом конце каждого из наименований в скобках через пробел версия (Театральная, без цензуры, режиссёрская и т.п.) на языке наименования, если версий более двух, используется вид: X в 1 и X In 1 для русского и английского/оригинального наименований.
        7. В самом конце названия релиза в квадратных скобках можно писать необходимую информацию о релизе, которая относится к: физическому носителю [DE, US] (только если более одного релиза в одинаковом формате); ревизии [Copolla Restoration, Remastered] (но не режиссёрская, театральная и т.п.); серии [Acoustic Experience]; производителю диска [Decca, 2L]; метке сериала (пока единственное, что по-русски) [Сериал] либо [Сериал 2005-2006] (в этом случае диапазон годов после названий не пишется), причем номер сезона не указывается. Не злоупотреблять, т.к. как правило, производитель, если важно, указан в _note. Квадратные скобки могут быть только одни, учитывать это при их использовании! Есть редкие релизы вроде 2007 - Репортаж - [REC], у которых название содержит квадратные скобки. В таком случае они остаются как есть.
      • Сборники:
        1. год самого раннего и самого позднего через дефис без пробела (1992-1993)
        2. русское наименование сборника (если есть)
        3. английское наименование сборника (если есть).
        4. В качестве наименования можно использовать наименования фильмов, включенных в сборник, разделив их точкой с запятой.
        5. Альтернативные наименования не пишутся
        6. Версии не пишутся
        7. Доп. информация в квадратных скобках не пишется
        8. Внутри сборника обязаны быть директории, названные в соответствии с именованием одиночных фильмов (кстати, надо учесть это при копировании, т.к. эти символы не будут убираться симлинками, также если один и тот же фильм будет находится внутри разных сборников, они пересекутся в общем виртуальном списке…)
      • Сериалы (сложный и на данный момент полностью нерешенный вопрос):
        1. серии могут иметь свой imdb id, но никогда не имеют свой kinopoisk id (за исключением специфических сериалов-сборников вроде Том и Джерри, где серии это самостоятельные короткометражки), поэтому когда серия выложена в сборнике, то возникает дилемма какой imdb указывать - родительского сериала или конкретной серии (как должны были бы делать если бы релиз был сериальный…)
        2. серии могут быть размещены на отдельных релизах, по одной серии (!) на релиз из одного диска
        3. сериалы могут не иметь отдельно выделенных серий (например: Вольф Мессинг, Котовский), т.е. это т.н. тв-сериал или мини-сериал и их не касается вопрос выделения отдельных серий! Помечаются как и раньше, при помощи [Сериал]. К ним относятся и сериалы, у которых эпизоды не имеют собственных названий.
        4. из вышеуказанного вытекает проблема невозможности обработки сериалов как сборников, т.е. при одинаковом диапазоне годов и общем названии хеш релиза не будет уникальным, добавлять же в него название серии странно (пример: Atlas Discovery, первый сезон), но придется
        5. т.к. только для сборников обрабатываются внутренние фильмы, то сериалы придется именовать диапазоном лет, даже если это один год (2006-2006), что приведет к дублированию при разных годах (2006-2007 и в [Сериал 2006-2007]) и, возможно, к тому, что придется всегда указывать диапазон годов для тех сериалов, которые содержат выделенные сериий (выделенная серия, та, которая имеет свой год и название, тот же Atlas Discovery).
        6. т.к. серии внутри будут как правило иметь один и тот же год, то для правильного их порядка их придется именовать, начиная с номера серии внутри сезона таким способом: XXXX - SyyEzzz - Русское название - Английское название, где XXXX это год, yy номер сезона (01, 02, .., 99) и zzz номер эпизода (001, 002, …, 999)
        7. для сериалов с огромным количеством коротких серий (Смешарики) список серий со своими описаниями приводить не нужно, т.е. они останутся помечены как [Сериал] или [Сериал XXXX-YYYY], но не будут содержать список серий внутри. Как вариант, перечислять все серии, но в таком случае мы можем получить десятки фактически пустых директорий и огромную простыню при их просмотре
      • Разрешенные и запрещенные символы:
        • Разрешены все символы из базового набора ASCII/UTF8 RU, за исключением слеша: /, т.к. он недопустим в файловой системе. Вместо него используется символ u2215: ∕. Он отображается как в Linux, так и в Windows. Из-за того, что он взят из u22 ряда, Dune отображает его как знак вопроса. Это единственное исключение из запрета на расширенный набор UTF8.
        • Из UTF8 базового (u00) набора разрешены четыре символа (градусы, степени, дроби): u00B0: °, u00B2: ², u00B3: ³, u00BD: ½
        • Из UTF8 расширенного (u20) разрешены два символа (длинное тире и три точки): u2014: — 25), u2026: …
        • Запрещено использование расширенного набора UTF8 (а хорошо бы было использовать ⅓ вместо 1/3, точнее как сейчас: 1∕3), т.к. они не отображаются в Dune и могут привести к другим проблемам.
        • Одиночные кавычки используются только в словах, везде, где необходимо, используются двойные.
        • Не используются символы: = _ ~ ` ^ * { } < > а также вертикальный слеш | (ранее он использовался как замена слеша /) и @ (фильмов таких не было еще, а вот, например, с $ есть)
        • На сегодня не используются спец. иностранные символы (умлауты, штрихи и т.п.) в названиях и хотя этому ничего не препятствует (они из базового UTF8 набора), не хочется усложнять. Поэтому Belphégor это Belphegor.
  4. Некоторые примеры наименований:
    • 2008 - Тачки: Байки Мэтра - Mater's Tall Tales [Сериал 2008-2010]
    • 1991 - Tori Amos: Live At Montreux 1991-1992
    • 1991 - Красавица и чудовище (Оригинальная театральная версия + Специальная расширенная версия) - Beauty And The Beast (Original Theatrical Version + Special Extended Edition)
    • Брюс Ли (Брюс Ли, мой брат) - Bruce Lee (Bruce Lee, My Brother)
    • 1992-1995 - Музыкант - El Mariachi; Отчаянный - Desperado
      1992 - Музыкант - El Mariachi
      1995 - Отчаянный - Desperado
    • 2009 - Аватар (3 в 1) - Avatar (3 In 1) [Extended Edition]


Критерии выбора фильмов/мульфильмов

Нажмите, чтобы отобразить

Нажмите, чтобы скрыть

  • За долгое время сформировались основные подходы к тому как осуществлять выбор среди множества различных релизов, особенно сейчас, когда к 2D добавились и 3D диски. Здесь bluray, bluraymux, hdremux относятся и к 3D если не указано иного. Основные правила:
    1. Оригинальные bluray: Должны присутствовать, при их наличии, всегда! Под оригинальным подразумевается релиз, в котором русский язык (либо только субтитры) присутствует изначально. Даже если качество видео/аудио плохое (в этом случае дополнительно желательно иметь bluraymux/hdremux с нормальным видео/аудио). Единственное исключение - их неработоспособность (для 3D - неработоспособность в 3D режиме).
    2. Дополнительные переводы: Если фильм представляет собой определенную ценность, то в дополнение к bluray/bluraymux допустимо иметь либо bluraymux, либо hdremux (но не оба одновременно) с авторскими/студийными переводами.
    3. 2D+3D: Являются отдельными сущностями. Поэтому допустима ситуация, когда имеется bluray и 3dbluray, а к ним bluraymux/hdremux и 3dbluraymux/3dhdremux. При рабочем 2D/3D диске и отсутствии 2D диска допустимо не иметь 2D ремукс. Но при появлении 2D диска его необходимо иметь. Есть странные релизы, где один из дисков 2D, а другой 3D (Пример: Спартак: Боги Арены). Поэтому из-за наличия внутри iso-файла их надо размещать в 3d секциях, несмотря на наличие 2D папки!
    4. Версии: При наличии разных версий (Театральная, без цензуры, режиссёрская и т.п.) следует стремиться к наличию всех. Релизы 2 в 1 и т.п. могут поглощать собой одиночные. Исключение - bluraymux 2 в 1 не может заменить Театральную (и т.п.) версию оригинального bluray.
    5. Ремастеринг: Сопоставлять качество видео с имеющимися релизами. Следует стремиться иметь наилучшее качество хотя бы в одном из фоматов (bluray, bluraymux, hdremux).
    6. Минимализм: Всегда следует стремиться минимизировать количество релизов, руководствуясь вышеизложенными правилами.


Индексация, правила внутреннего структурирования релизов

Нажмите, чтобы отобразить

Нажмите, чтобы скрыть

  • В процессе работы с различными форматами, содержанием, особенностями релизов и т.п. сформировалось видение того, что вся основная и дополнительная информация должны быть размещены в так называемой мини базе данных. Форматом после долгих мук выбора (рассматривал и SQL/YAML/XML и т.п.) остановился на XML, как достаточно понятному при обычном просмотре, дающему необходимую функциональность, платформонезависимому и отличной поддержке в разных языках программирования (именно по этой причине «отвалился» YAML - а его форматирование выглядит значительно проще). Т.е. каждый релиз (отдельный фильм, игра и т.п.) должен иметь файл _xml, который содержит исчерпывающую информацию как о технической (размер, sha1 сумма, форматы и т.п.) составляющей, так и информационной (описания, комментарии, примечания и т.п.).
  • Т.к. работа по _xml не закончена, информация содержится в отдельных файлах (_count, _sha1, _date, _glitch, _ids, _note, _parse, _source, _txt и специализированных _db и _note2 - также есть особенности, связанные с мультирелизами (выше, в правилах именования)). В дальнейшем они будут сконвертированы в _xml. Однако при необходимости. Т.к. есть сомнения в том, что _xml будет читаем для, например, быстрого прочтения описания. Файл _db будет оставлен, т.к. содержит в себе закодированную и сжатую информацию о релизе (восстановимую парсером), _note2 скорее всего переместится в _xml, в его служебную часть.
  • Заполнение служебных файлов (_note, и т.п.) осуществляется по своим правилам и зависит в первую очередь от класса, и частично от типа и формата. Здесь bluray, bluraymux, hdremux относятся и к 3D если не указано иного.
    1. Все классы: общее для любого класса
      1. _count: внутренний счетчик
      2. _date: дата добавления релиза в формате DD.MM.YYYY
      3. _db: служебный файл
      4. _glitch: файл, в котором можно описать любые повторяемые проблемы с релизом (не воспроизводится частично/полностью, не запускается без доп.настройки и т.п.)
      5. _sha1: служебный файл с SHA1 суммой для всех файлов релиза, исключая файлы, начинающиеся с _ и пустые директории, генерируется при первоначальном индексировании, используется для проверок целостности
      6. _source: источник релиза, домен либо N/A если неизвестно.
    2. Игры (games):
      1. _ids: не используется, возможно будет использоваться для некой базы данных игр
      2. _genre: файл с жанром игры, скорее всего будет убран в последующем
      3. _note: служебная информация с датой релиза, источником (если надо), языками - в настоящее время не используется, требуется проработка
      4. _language: файл с доступными языками, располагается в директории EUR, RUS, USA, JPN, необходимо заменить на _note
      5. _year: файл с годом релиза, располагается в директории EUR, RUS, USA, JPN, необходимо заменить на _note, а релизы именовать как в видео ([EUR] в конце наименования)
      6. _txt: описание игры
    3. Видео (video):
      • Общее для видео:
        1. ! и !!: Просмотрен ли релиз полностью или частично. Под частичным подразумевается просмотр 2D версии 3D фильма и также просмотр конкретного фильма в другом формате. Для личного использования.
        2. _note: если в фильме присутствуют несколько версий (Театральная, режиссёрская и т.п.), то в каждом из подразделов (Звук и Субтитры) они расписываются отдельно. При полном соответствии все версии допустимо писать в одну строку через знак плюс: «Театральная версия (Theatrical Cut) + Специальное переиздание (Special Edition Re-release Cut) + Расширенная версия (Extended Cut):»
        3. _note2: служебный файл, сохраняется при декодировании (ручном) базы данных парсинга для вывода Звука и Субтитров в собственном виде. Является основой для формирования _note.
        4. _parse: служебный файл, если при парсинге ошибочно выбирается два видео-файла либо необходимо увеличить количество обрабатываемых файлов, в него вносится значение от 1 до (условно) бесконечности. По-умолчанию используется автоматическое определение (1 либо 2).
      • Одиночные релизы:
        1. _ids: различные базы данных, IMDB (imdb) и Kinopoisk (kino). Формат: BD:ID (на отдельной строчке). В корне релиза.
        2. _note: служебная информация с датой релиза, источником (если надо), звуком и субтитрами, примечанием и дополнительными материалами (для bluray, bluraymux)
        3. _txt: описание фильма, для музыки дополнительно tracklist (если есть).
      • Сборники:
        1. _ids: различные базы данных, IMDB (imdb) и Kinopoisk (kino). Формат: BD:ID (на отдельной строчке). В каждой из директорий наименований, входящих в сборник.
        2. _note: служебная информация с датой релиза, источником (если надо), звуком и субтитрами, примечанием и дополнительными материалами (для bluray, bluraymux). Каждое именование, входящее в сборник, описывается также, как если бы они были разными версиями фильма (выше).
        3. _txt: описание фильма, для музыки дополнительно tracklist (если есть). В каждой из директорий наименований, входящих в сборник. Допустимо иметь также глобальное описание сборника в корне.
  • Общий подход к размещению файлов и директорий:
    1. одиночные видео/аудио/субтитры в корне релиза. Если доп. аудио дорожки лежат вместе с BDMV структурой, то их необходимо прилинковать (ln -s) из BD/BDMV/STREAM/00000.dts (дорожка для 00000.m2ts файла). Данный вариант работает только для единых файлов видео и в режиме BD-Lite/File. Нельзя добавить более одной дорожки (надо менять симлинк!).
    2. одиночные директории образов в корне релиза. Именования: DVD = DVD, Bluray = BD, HD DVD = HDDVD. При более чем одном диске: BD1, BD2, …, BD9. Если 10 дисков и более: BD01, BD02, …, BD10. Для 3D: BD.iso или BD1.iso, BD2.iso и т.п.
    3. EUR, RUS, USA, JPN: директория для игры (временно). Таким образом ранее отделялись регионы. Будут перенесены в одиночные релизы.
  • Оформление коллекции осуществляется с ориентацией на плееры Dune 26). Локальная генерация происходит в процессе обработке релиза и последующих групповых обработок. Рассматривается вопрос по генерации на базе одиночного диска, для работы коллекции у других людей. Некоторые неструктурированные замечания:
    1. внутри одиночного релиза должен находиться базовый dune_folder.txt с бекграундом и иконкой (иконка используется для списка). Добавляем все свои файлы и директории в system_files, чтобы они не отображались. в релиз не надо добавлять ничего, связанного с тем, что может быть изменено глобально (например, при изменении фона придется подключить ВСЕ диски!), только специфические вещи. Новой вещью может быть привязка серий сериалов и сборников к конкретным дискам в многодисковых/многофайловых релизах.
    2. Основные сложности возникают с многодисковыми/многофайловыми/сборниками. Т.к. для них уже невозможно создать корректный способ запуска фильма. Дело в том, что Dune прикрывается фоном и не показывает списка файлов. И нажимая на Enter мы просто запускаем первый файл/директорию. Перемещаться можно, нажимая влево-вправо, и это хорошо видно на плеерах с экраном (Base 3.0/3D, Duo, Max), но это же не вариант!
    3. Возможным решением проблемы может служить исключительно создание виртуальных папок, со ссылками на фактический релиз (по хешу хорошо, но тогда без дюны у человека не будет возможность скопировать фильмы - используем проверенный video.by.name) и содержащиеся в нем директории/файлы. Тут также присутствует проблема со сборниками (надо ли для них иметь отдельный релиз) и сериалами (их можно «вычислить» по тому что они изначально считаются сборниками и имеют метку [Сериал]).
    4. Все это также означает и то, что в этом случае нам не стоит создавать внутри релизов ничего, связанного с dune_folder.txt (ни иконок, ни фона) либо создавать специальную папку для хранения иконок, фонов, но использовать их исключительно через внешние ссылки (используя хеш релиза или, лучше, его имя подготовленное video.by.name имя).
  • Языком программирования выбран PHP. Он довольно прост, гибок, быстродействие, обеспечиваемое им (даже для неоптимизированного кода), в данном случае достаточно. Для импорта/экспорта будут использоваться PHP классы (XML Writer и Generic XML Parser) (фактически же сейчас используются массивы, сохраненные в файл), для выделения информации о файлах (аудио, видео) используется Mediainfo (ссылка на сборку под amd64 на главной странице), который работает под Windows и есть порт под Linux.
  • В настоящее время вопрос стоит в доработке шаблонов XML (это то, где я «плаваю» - любая помощь приветствуется) и дальнейшее кодирование (и сопутствующие проблемы, которые всегда всплывают в самый неподходящий момент). В принципе, возможно будет перенести PHP файлы на Windows при условии доработки кода - если есть желающие, пишите.
5) есть разные модификации, главное чтобы это был Big Tower, желательно брать без встроенного БП
6) уже устарела, но все работает, была в списке совместимости с 3ware 9650-SE
7) рисковать данными не стоит, вероятность ошибки записи при круглосуточной работе достаточно велика для меня
8) сейчас считаю что куплен зря, надо было софт-рейд делать, и покупать SAS HBA контроллер
9) только нормальный свитч сможет прокачать быстро и без задержек весь траффик
10) все равно требуется отвертка для крепления винчестера в корзину, тем не менее, идеальная вещь в своем роде
11) на nix.ru
12) появляется на nix.ru время от времени
13) есть на nix.ru
14) последняя 2.06/2.09, прошить в домашних условиях невозможно, т.к. требуется RAID контроллер от HP! Искать локальные контакты
16) можно чуть дороже здесь: http://www.compuvest.com/Desc.jsp?iid=1582058
17) по итогу куплено через HardForum.com у SynergyDustin через посредника
18) , 19) на eBay у hdmihome2010
20) б/у на eBay, новая стоит дорого, около $300
22) на AliExpress, новая стоит дорого, около $300
23) наверное шумит как самолет, каскадируется ли однопортовый E16? Стоимость: в Москве ~$2800-2900, на provantage.com - ~2300 с доставкой на Украину, неизвестно как с растаможкой и можно ли слать в РБ…
24) ищу утилиту/патч чтобы перекодировать такие папки/файлы на лету - ранее была нужная функциональность в CIFS, но она не работает
25) в качестве собственно тире (среднее тире u2013: – отображается похоже) для фильмов вида: Гринч — Похититель Рождества - How The Grinch Stole Christmas и сложных дат вида Далекая война: Сентябрь 1939 — Май 1940 - Distant War: September 1939 — May 1940, чтобы отделить тире от дефисов-минусов, разделяющих года и названия. Несмотря на то, что с датами лучше бы использовать среднее (u2013), но принято решение не усложнять (особенно из-за того что все диапазоны, включая года в сериалах и сборниках должны были бы иметь среднее тире) и у нас остается только одно тире (u2014), всегда отбиваемое пробелами! проверяем совпадения своим verify_dash. Добавить в разрешенный набор и замену для поиска? но в базе тире не меняется…
draft.txt · Последние изменения: 2015/09/17 01:48 — admin