| Главная· Трекер· Поиск· RSS· Правила· FAQ· Группы· Пользователи · «Буквица» |
|
|
Библиотека Либрусек (lib.rus.ec)
|
|
Главная » Архивы библиотек » Библиотека Либрусек » Полные сборки библиотеки Либрусек |
| |
Как вы считаете - какая должна быть периодичность выхода обновлений?
| по мере выхода очередного архива-тысячника |    |
2% | [ 2 ] | |
| два раза в месяц | |
5% | [ 4 ] | |
| раз в месяц (как было ранее) | |
91% | [ 67 ] |
Всего проголосовало : 73
|
|
| Автор | Сообщение |
|---|---|
| Shooter667 |
|
| Drunkenmunky |
|
| rupor |
Drunkenmunky писал(а): Ну, эта самая FLibrary борется за высокое звание каталогизатора, нет? Если же использовать их как front-end для заранее подготовленных каталогов - годятся обе, FLibrary на данный момент КМК однозначно сильнее, хотя бы потому, что MHL не развивается уже очень долгое время. Хочу заметить, что без таких, даже несовершенных front-ends вся кутерьма со сбором и распространением архивов наворованных книг становится совершенно бессмысленной - как не являются особенно продуктивными саркастические замечания при общении с авторами программ  |
| Drunkenmunky |
rupor писал(а): Если же использовать их как front-end для заранее подготовленных каталогов Цитата: Хочу заметить, что без таких, даже несовершенных front-ends вся кутерьма со сбором и распространением архивов наворованных книг становится совершенно бессмысленной Цитата: как не являются особенно продуктивными саркастические замечания при общении с авторами программ |
| Tom_tam |
rupor писал(а): Хочу заметить, что без таких, даже несовершенных front-ends вся кутерьма со сбором и распространением архивов наворованных книг становится совершенно бессмысленной - как не являются особенно продуктивными саркастические замечания при общении с авторами программ  |
| heimdallrnsk |
Tom_tam писал(а): rupor писал(а): Хочу заметить, что без таких, даже несовершенных front-ends вся кутерьма со сбором и распространением архивов наворованных книг становится совершенно бессмысленной - как не являются особенно продуктивными саркастические замечания при общении с авторами программ |
| rupor |
Это скорее всего off-topic, но поскольку отдельной темы нет, а большинство заинтересованных здесь присутствует, то попробую написать здесь.
Постарался прочитать все трекер темы относящиеся к flibusta/librusec сборкам за последние 10 лет - entertaining read metabib (используемый для генерации inpx в этой теме) претерпел некоторые изменения и дорос до версии 2. Кратко, но по делу : теперь поддерживаются все типы файлов, программа обрабатывает и fb2 и usr архивы во всех подкоммандах. Интересным (но опасным) добавлением является новая "inpx" подкомманда, которая поддерживает --where и --slice-by и позволяет производить "альтернативные" наборы inpx (если я не ошибаюсь, это то, чем занимается Drunkenmunky). LeaF для вас ничего не изменилось, программа по умолчанию работает в FB2 режиме, может потребовать перегенерить database manifest и, возможно, merged jsonl. INPX результаты не отличаются от того, что было. Я знаю, что вы не используете fetch и rollup - но они теперь умеют создавать "месячные" архивы автоматически (как для fb2, так и для usr, независимые lineage) - так что может иметь смысл почитать readme, там много нового и интересного. Тестировал я на полном "наследии" flibusta (~1.5Tb usr наследия и моя сборка flibusta fb2 ~0.5Tb) - полученные "all" inpx работают в текущей версии FLibrary (можно экспортировать не fb2 книги) и в MHL, но тут есть ньюанс: текущие сборки MHL имеют противный баг: вместо выбранного usr файла они выбрасывают полный "содержащий" архив. А.Пеньков (он же koreec) все это починил (без напоминаний, спасибо ему) - так что начиная с MHL 2.6.1 все работает и там. heimdallrnsk На всем текущем "наследии" flibusta имеется 3 файла, которые FLibrary из моих inpx не может "найти". В МHL (который работает по индексам такой проблемы нет, там есть другие ) Код: Archive: usr-153851-158324.zip Book ID: 156164 Title: Сара (рассказы) \ Sarah Filename: Jt_Leroy_Sara_rasskazyi_\_Sarah.rar INPX fields: - FILE: Jt_Leroy_Sara_rasskazyi_\_Sarah Код: | `f.usr-440801-444899.zip` | `443936` | Погребения на городищах лесной полосы раннего железного века | `M. V. Gusakov\x04\x12\x12\x0f\x14\x16\x0e \x17\x18\x19\x04\x12\x12\x0f\x14\x16\x0e \x17\x18\x19_Pogrebeniya na gorodishchah lesnoy polosy rannego zheleznogo veka \x1a\x0b \x0b\x1d\x12\x19\x18\x19\x10 \x0c\x0b\x15\x06\x10.pdf` | `M. V. Gusakov\x04\x12\x12\x0f\x14\x16\x0e \x17\x18\x19\x04\x12\x12\x0f\x14\x16\x0e \x17\x18\x19_Pogrebeniya na gorodishchah lesnoy polosy rannego zheleznogo veka \x1a\x0b \x0b\x1d\x12\x19\x18\x19\x10 \x0c\x0b\x15\x06\x10` | `pdf` | `0x04` | `M. V. Gusakov%04\x12\x12\x0f\x14\x16\x0e \x17\x18\x19%04\x12\x12\x0f\x14\x16\x0e \x17\x18\x19_Pogrebeniya na gorodishchah lesnoy polosy rannego zheleznogo veka \x1a\x0b \x0b\x1d\x12\x19\x18\x19\x10 \x0c\x0b\x15\x06\x10` | | `f.usr-440801-444899.zip` | `444746` | Історія з відьмами. Суди про чари в українських
воєводствах Речі Посполитої
XVІІ-XVІІІ століття | `Katerina Disa_Istoriya z vidmami. Sudi pro chari v ukrayinskih\n voievodstvah Rechi Pospolitoyi\n XVII-XVIII stolittya.djvu` | `Katerina Disa_Istoriya z vidmami. Sudi pro chari v ukrayinskih\n voievodstvah Rechi Pospolitoyi\n XVII-XVIII stolittya` | `djvu` | `0x0A` | `Katerina Disa_Istoriya z vidmami. Sudi pro chari v ukrayinskih%0A voievodstvah Rechi Pospolitoyi%0A XVII-XVIII stolittya` | Цитата: All INPX generators treat filename fields as lookup keys. `FILE` and `EXT` preserve physical archive-entry spelling more strictly than display fields: non-breaking spaces, literal percent signs, tabs, and other non-structural bytes are left unchanged. Only characters that would break the INPX row format are escaped with a visible tilde sequence: field separator `0x04` becomes `~04`, carriage return becomes `~0D`, and line feed becomes `~0A`. This is a narrow metabib convention rather than full URL percent-encoding; INPX consumers need matching decode support to resolve such archive entries during import or extraction. Literal `~04`, `~0D`, and `~0A` in archive names are ambiguous escape sequences; generators warn when such names are encountered. Ну и имеется "общий" случай с multi-volume rar/7z книгами, которые добрые люди натолкали в наследие. Всего таких 75. Я создаю inp record по первому файлу, что делать дальше - не знаю. Про "битые" архивы, FB2 книги в usr архивах и плохие fbd я даже не говорю. Если кому интерено: Код: # Archive Manifest Statistics Source: `build/metabib.log` Command input: `cache --archives C:\syno\backup\library\flibusta_usr --archives C:\syno\backup\library\flibusta` Scope: per-archive `Archive manifest created` records only. Final aggregate summary lines were not used. ## Manifest Records | Archive set | Files | Manifest records | `usr_fb2_entries_ignored` | `fb2_non_fb2_entries_ignored` | |---|---:|---:|---:|---:| | `fb2-*` | 283 | 703,783 | 0 | 0 | | `usr-*` | 19 | 11,195 | 4 | 0 | | `d.usr-*` | 3 | 320 | 1 | 0 | | `f.usr-*` | 201 | 126,504 | 184 | 0 | | **Total** | **506** | **841,802** | **189** | **0** | USR-family subtotal: 223 files, 138,019 manifest records, 189 `usr_fb2_entries_ignored`, 0 `fb2_non_fb2_entries_ignored`. ## Ignored Records | Category | Count | |---|---:| | `FB2 archive entry ignored in USR scope` | 189 | | `Unpaired FBD sidecar ignored` | 6 | ## Ignored FB2 Entries By Container | Container | Count | |---|---:| | `zip` | 154 | | `rar` | 23 | | no `container_extension` field | 10 | | `7z` | 2 | ## Related Non-Ignored Events | Event | Count | Behavior | |---|---:|---| | `Nested archive volume continuation skipped` | 75 | `emit_root_opaque_record` | | `Nested multi-volume RAR inspection skipped` | 4 | `emit_opaque_record` | | `Nested archive inspection failed` | 68 | `emit_opaque_record` | ## WARN Lines By Cause Total `WARN` lines: 263. | Cause | Count | `usr-*` | `d.usr-*` | `f.usr-*` | `fb2-*` | |---|---:|---:|---:|---:|---:| | FB2 content found inside USR archive entry | 189 | 4 | 1 | 184 | 0 | | Invalid ZIP data | 31 | 2 | 0 | 29 | 0 | | Nested FBD sidecar read offset error | 19 | 0 | 0 | 19 | 0 | | RAR decode/open failed | 8 | 2 | 0 | 6 | 0 | | FBD sidecar has no matching payload entry | 6 | 0 | 0 | 6 | 0 | | Multiple nested FBD sidecars | 5 | 0 | 0 | 5 | 0 | | Nested FBD sidecar parse failed | 5 | 0 | 0 | 5 | 0 | ## WARN Lines By Message | Message | Count | |---|---:| | `FB2 archive entry ignored in USR scope` | 189 | | `Nested archive inspection failed` | 68 | | `Unpaired FBD sidecar ignored` | 6 | ## Nested Inspection Failures By Cause | Cause | Count | |---|---:| | Invalid ZIP data | 31 | | Nested FBD sidecar read offset error | 19 | | RAR decode/open failed | 8 | | Multiple nested FBD sidecars | 5 | | Nested FBD sidecar parse failed | 5 | |
| Drunkenmunky |
rupor писал(а): Кратко, но по делу : теперь поддерживаются все типы файлов, программа обрабатывает и fb2 и usr архивы во всех подкоммандах. Интересным (но опасным) добавлением является новая "inpx" подкомманда, которая поддерживает --where и --slice-by и позволяет производить "альтернативные" наборы inpx (если я не ошибаюсь, это то, чем занимается Drunkenmunky). |
| rupor |
Drunkenmunky Попробую ответить по порядку:
1. "Опасным" потому что "защита от дурака" там не работает, наковыраять можно практически все, что угодно, так что за выход отвечает тот, кто делает. Почитайте readme - и вы поймете, что скажем по языкам задать как генерить отдельные inp легко, а вот по, скажем, сериям или жанрам - весьма не так однозначно. Впрочем, я думаю, вам это отлично известно. 2. почитайте readme, попробуйте и напишите чего, по вашему мнению, не хватет? Вполне возможно я что-то пропустил. Кратко - mhl-inpx использует индексы (как было всегда), в "inpx" имеются и индексы и имена оригинальных архивов, а для "flib-inpx" предложена схема "escaping". В jsonl ничего этого не нужно. 3. Мультисерийность в inpx поддерживается так же, как и для FLibrary - путем вставления multiple records. Никаких типов (я так понимаю авторский/publisher сегодня не поддерживается, об этом интересно было бы поговорить, возможно поиски смысла приведут к расширению функциональности?). Что касается merged jsonl - там просто есть все. С указанием откуда взято. Что с этим делать решает тот, кто использует. Если чего-то нет - я добавлю, это ошибка. 4. Вам все же надо сначала почитать readme, прежде чем трясти - там же ясно написано, что генерится независимый, полный, определенный строгой JSON схемой provenance capable jsonl файл - и он же предлагается для использования. Генерация inpx сделана для демонстрации возможностей и чтобы поддержать старых пользователей и уже существующие программы. Людям трудно Тот же кореец, к слову, без всяких просьб, в pre-release MHL добавил прямое чтение из jsonl, ну или попытался, для нового нужно время. Ну и в качестве обменного artifact INPX лучше - он сильно меньше по размерам. CSV вы можете сделать сами из jsonl если очень нужно - там будут проблемы точно такие же как и в INP, строго говоря INP и есть (весьма странная) разновидность CSV. 5. Тут я вообще не понял - ваша ссылка ведет в целый раздел, куда именно там смотреть? Я трекерами пользуюсь редко, так что не в теме. Может вы изложите словами, что именно есть "произвольная структура файлов в раздачах"? |
| heimdallrnsk |
rupor писал(а): На всем текущем "наследии" flibusta имеется 3 файла, которые FLibrary из моих inpx не может "найти". usr-153851-158324.zip/Jt_Leroy_Sara_rasskazyi_\_Sarah.rar  Если его же и записать в inp, то FLibrary эту книжку "видит". С прочими архивами 7z.dll работает как ожидается, слэши на своих местах. Цитата: имеют в названии символы, которые inpx переварить не может - 0x04, 0x0A, 0x0D. В lib2inpx и предыдущих версиях metabib я такое просто выкидывал, что приводит ко вполне понятному результату - MHL их находит по index, FLibrary не находит. Теперь я проимплементировал простейший минимальный encoding: Цитата: All INPX generators treat filename fields as lookup keys. `FILE` and `EXT` preserve physical archive-entry spelling more strictly than display fields: non-breaking spaces, literal percent signs, tabs, and other non-structural bytes are left unchanged. Only characters that would break the INPX row format are escaped with a visible tilde sequence: field separator `0x04` becomes `~04`, carriage return becomes `~0D`, and line feed becomes `~0A`. This is a narrow metabib convention rather than full URL percent-encoding; INPX consumers need matching decode support to resolve such archive entries during import or extraction. Literal `~04`, `~0D`, and `~0A` in archive names are ambiguous escape sequences; generators warn when such names are encountered. |
| rupor |
|
| LeaF |
|
| Abu101 |
Большое спасибо.
  |
| Jeca |
LeaF, большое спасибо за Ваш труд. В этом году обновление совпало с праздником
|
| bookreader66 |
|
|
Страница 237 из 243 Страницы: Пред. 1, 2, 3 ... 236, 237, 238 ... 241, 242, 243 След. |
|
|
Главная » Архивы библиотек » Библиотека Либрусек » Полные сборки библиотеки Либрусек |