Библиотека Либрусек (lib.rus.ec) + MyHomeLib. [FB2] (Новый формат)

Почему именно на телефоне. SD карты и на террабайт есть, а 512ГБ уже вполне доступная штука.

Работать на мобильном устройстве с полной библиотекой неудобно, а на читалках и невозможно, т.к. у них есть ограничение на объём карточки. Поэтому я собрал свою библиотеку и загружаю её на все мобильные и стационарные устройства, которыми пользуюсь. Разумеется, на комплектацию библиотеки требуется время. Я начал сборку после покупки первой электронной книжки и теперь время от времени пополняю библиотеку новыми, интересующими меня книгами.

del

В Alreader (или новая версия AlreaderX) есть встроенный каталогизатор. С полной fb2 коллекцией L на карте памяти вполне себе работает. Данные в каталог берутся из самих fb2. К сожалению из inpx данные не добавить.

а этой раздачей (в плане inpx, а не архивов) вообще можно пользоваться?

сразу скажу, с базами работаю без проблем, и с раздачей флибусты никогда такого не было
тут решил глянуть либрусек, что в нем нового относительно флиб-ы, а то как он монетизировался не заглядывал

импортировал inpx, хожу по книгам и что вижу - часть записей в MHL (далеко не все, но все же) не соответствует книге.
несовпадает от слова СОВСЕМ. т.е это НЕ «дескрипшин от автора файла поправлен в базе на более точный», а «книга от одного автора про одно, с описанием в базе про совсем другую книгу»
была мысль - это косяк генератора inpx, но скачав sql с либрусека убедился, что это идет напрямую из их базы. книги под одним именем файла (соотв. bid в бд/inpx) фигурируют в бд под другим номером, соответственно под тем левое

для примера, на что навскидку наткнулся:
1) файл 115391
в БД: Хури Элиас - يالو
в файле: Д`Алессандро Джеки - Завидный жених
соответствующий реальному файлу id - 158446
1) файл 142068
в БД: Хелле Хелле - Dette burde skrives i nutid
в файле: Перумов Ник - Один на один
соответствующий реальному файлу id - 142069
и т.д., при чем это не «удаленные файлы» или еще какой мусор
сколько таких реально в базе перепутано неизвестно, я только быстрое сравнение по случайной выборке делал, но где десять, там и ко всей бд доверия нет...

пока что сборка либрусек, может работать только через импорт описаний из fb2-файлов, а не inpx/sql
это что, Ларин решил испортить жизнь жителям торрентов и перемешал bid в своих дампах? так зачем тогда их вообще выкладывать?...

кто-нибудь в курсе что и к чему это?

Добрый день, когда планируется свежее обновление? )

Hibor На скорую руку: и д'Алессандро, и Перумов использованы как "затычки", т.е. реально находятся как дубли под номерами 115391 и 142068. По другому MyHomeLib их бы и не увидел. То есть в случае с Перумовым ещё бы прокатило, вот только все файлы после 142068 в этом zip сдвинулись бы. А указанный вами Д'Алессандро 158446 физически находится в другом архиве (fb2-158328-161830). Для Элиаса и Хелле в inpx вбит нулевой размер файла - возможно, во времена формирования тех архивов была допущена ошибка, которую впоследствии подправили на уровне inpx столь странным способом. Проще, конечно, при следующей правке такие записи в inpx привести в соответствие с файлами zip и пометить как удалённые. Но вообще за всё долгое время работы с базой Либрусек серьёзных проблем я не заметил, сборка прекрасно работает в связке с MyHomeLib посредством inpx. Никакой путаницы нет.

PS Посмотрел: этот странный метод применялся до fb2-216642-221999. Есть ли у вас примеры для файлов с номером выше 222000?

Есть такое дело, да. Связано с тем, что на Либрусеке практикуется замена физически удаленных книг(не только помеченное как удаленное, а вообще) новыми записями. С присвоением им отсутствующих bid. На это было обращено внимание администратора, что им признано как действительно не самая удачная идея, но, никаких исправлений или смены этой политики замечено не было. Что с эти делать пока неясно. Но, так как, как правило, это касается т.н. тикетов, т.е. книга только обозначается в базе, для будущей закачки(например на оригинальном языке), а физически она отсутствует, то в INPX она попадает, только если есть файл с её bid(оставшийся в архивах, но убранный из библиотеки), то особой проблемы лично я в этом пока не вижу. Их не очень много, навскидку, пара сотен. По мере накопления раздраженных комментариев, будем думать.

Drunkenmunky Что делать - в inp привести запись в соответствие с файлом, который находится в zip и поставить метку "удалён". К примеру, файл 115391 - это Д`Алессандро Джеки "Завидный жених", вот в inp и написать именно это вместо "Хури Элиас - يالو". Самый простой способ, без правки архивов. Надо будет - займусь, но в августе, не раньше.

Самый простой способ - составление списка проблемных bid, с регулярным его пополнением, так как это дело на месте не стоит. Далее, согласно этому списку нужно делать(опять таки регулярно) заплатки. Займитесь, да, дело нужное.

Alter Old, странное объяснение... номер внутри архива касается только MHL с его sqlite базой где присутствует InsideNo для архива, а тут путаница еще на уровне sql-дампов самого либрусека, где про архивы вообще ничего нет, только bid (id - имя файла-книги)

Drunkenmunky Понятно... Жаль, у меня на дампах автоматическая обработка идет, чистка, дубли, пропись описания и т.д., а с такой изначальной базой чревато, даже если файлов немного. И не сделаешь ничего, если на либрусеке добавляют новые записи, на существующие в архивах книги... Спасибо за инфу, возвращаюсь на Флибусту

Почему же. Тикеты имеют нулевой размер файла, их можно предварительно, перед генерированием INPX, удалять. В расширенном INPX так и делаю. В отдельном .inp содержатся выловленные записи полностью удаленных файлов. Штук 700 вроде, так что они в актуальное не попадают. Там своего бардака хватает, и не факт, что он лучше. Сделал Flibustu 2.0, в меру своего понимания, проблемы частично пофиксил.

Hibor Первые архивы Флибусты и Либрусека, до fb2-168103-172702.zip, совпадают. Все ваши примеры касаются именно этих, первых, архивов. То есть можно взять из Флибусты правильные inp, записи в которых соответствуют файлам внутри zip, и всё, вопрос решён. Или же исправить самостоятельно, с проверкой обоих inp по содержимому zip. А объяснение - что же странного? Альтернативное (в Либрусеке на дубли зачем-то придумали сторонних авторов и забыли пометить как удалённые) звучит гораздо страннее.

Drunkenmunky если для таких «замен» размер обязательно 0 и это только запись, тогда приемлемо

а к Флибусте я давно привык, там большинство бардака поддается автоотлову за Flibusta 2.0 спасибо, пользуюсь USR частью (epub)

Alter Old вопрос не только в файлах-книгах, а именно в базе, т.е. заменив от Флибусты получим нарушение цепочек удален/заменен плюс другие описания (ведь вносили правки пользователи разных ресурсов, хоть и во многом совпадающие)

как раз объяснение Drunkenmunky абсолютно логично - ошибка в логике работы бд, не учли наличия архивов с удаленными (все же в первую очередь базы для работы сайта, а не сторонних трекеров ) и забили на исправление правда зачем заранее добавлять запись без наличия файла - не понятно, я бы такое во временное кидал пока полноценной связки запись-файл не будет... хотя чем не угодили 700Т счетчика тож непонятно, для бд это ничто...

Hibor Ну была ошибка, но сейчас-то можно привести inp в соответствие с архивами. По крайней мере, по признаку "ноль байт" - ведь именно этих книг в этих местах на самом деле нет. Можно сравнить оба файла inp, и спорные места попутно сравнить ещё и с лично сделанным inp - ну, чтоб уж напроверяться вдоволь ; ). И - да, конечно же, это будет нескорый полуавтоматический процесс, и надо сначала продумать алгоритм, и посомневаться раз пять на тему: "А нужно ли?", но тем не менее... Лишь бы начать до того, как разочаруешься в самой идее. Радует, что править inp гораздо проще, чем пересобирать архивы.