Страницы: Пред. 1, 2, 3 ... 221, 222, 223 ... 248, 249, 250 След.
| Автор |
Сообщение |
| iso9660
|
Очень интересно и познавательно.
Немного иначе себе все это представлял.
А есть мысли почему принято решение не править метаданные в книгах? Ну хотя бы в тех для которых правок не было больше полугода?
|
|
|
| Hibor
|
iso9660 писал(а): А есть мысли почему принято решение не править метаданные в книгах? Ну хотя бы в тех для которых правок не было больше полугода? А зачем? Если править возникает проблема обновления архивов. * сейчас полная раздача уже 400Гб в архивах грубо 1-8Гб * правок много и книги правятся не по порядку, а как кто-то заметит - нет сроков * любое изменение влечет за собой перепаковку и перезакачку всего архива + одно изменение может затрагивать сразу много архивов (например, название серии или автор - разброс в годы) * делать раздачу 1 архив = 1 книга для легких правок не выгодно - очень большие накладные расходы * потому и "удаленные", замененные лучшими вариантами книги в архивах остаются, просто в inpx помечены Вообщем, все сводится к выбору или все изменения сколько бы ни было в 30Mb inpx, или куча перекачиваний в добавок к стандартному месячнику. Выбор очевиден. Неизменяемые месячники и inpx - оптимальный вариант для общего удобства. А пропись/правка мета-данных, удаление замененных и дублей, выборки, правки структуры+вложений и многое другое - это удел личных коллекций. p.s. Кому нужны правленные метаданные в файлах-книгах для электр.читалок обычно пользуются функцией "перезаписывать заголовки" при экспорте, в большинстве каталогизаторов она есть (и MHL) Для примера, я держу частную переработанную коллекцию - куча правок структуры, вложений, оптимизация и т.д. Действительно много. При сохранении русскоязычного наполнения и не худ.лит. английского из 400Гб осталось всего 200Гб. Ради этого я преобразую в вид архив-1книга. Но да же для личной коллекции я не решусь вместо обработки месячника (и потом минимальной общей коллекции) каждый месяц по сути перепаковывать и обрабатывать 200+Гб данных, да же с отслеживанием изменений и в несколько потоков, и с кэшем в рам. И только ради случаев когда книгу открывают вне доступа программы-коллекции (да и у той вариант прописи при экспорте есть). Овчинка выделки не стоит.
|
|
|
| Crystal
|
wowan_zh Обычно в начале каждого месяца я заливаю ежедневки (и Fb2, и USR) за предыдущий на файлообменник Терабокс. Не всегда прям первого числа, так как это не самая приоритетная задача, но второго-третьего, как правило, всё же заливаю. Ссылка есть на первой странице, спойлер "Дополнительные ссылки". Это так, для справки. Объём предоставляемого дискового пространства там 1 Тб, так что до заполнения ничего удаляться не будет. А до этого ещё далеко 
|
|
|
| www00
|
Crystal писал(а): wowan_zh Обычно в начале каждого месяца я заливаю ежедневки (и Fb2, и USR) за предыдущий на файлообменник Терабокс. Не всегда прям первого числа, так как это не самая приоритетная задача, но второго-третьего, как правило, всё же заливаю. Ссылка есть на первой странице, спойлер "Дополнительные ссылки". Это так, для справки. Объём предоставляемого дискового пространства там 1 Тб, так что до заполнения ничего удаляться не будет. А до этого ещё далеко Подскажите, где взять inpx для ежедневок, которые на Terabox?
|
|
|
| Hibor
|
www00 писал(а): Подскажите, где взять inpx для ежедневок, которые на Terabox? так там старые ежедневки, за предыдущие месяцы - к ним уже везде вложены inpx (в виде как для месячного архива), см. там же в спойлере первого поста (или из этой раздачи, отдельная ветка есть и т.д.) на террабоксе в основном для тех кто по каким-либо причинам не качает с торрента а по свежим (за тек.месяц) ежедневкам из https://booktracker.org/viewforum.php?f=253 inpx не генерится, пока в разряд месячника не перейдут - накладно раз в день перебирать 400Гб архивов (или inpx будет неполный, если только по дампу создавать) если есть желание - можно и каждый день самостоятельно создавать, кратенько здесь писал https://booktracker.org/viewtopic.php?p=306294#306294 (последняя часть сообщения и спойлер)
|
|
|
| Hibor
|
Если в августе обновления раздачи не будет: временно вот почти аналогичный inpx https://disk.yandex.ru/d/0Q439T-ocCg6lQ
(почти, т.к. не известны параметры используемые автором раздачи, в этом «--read-fb2=all --prefer-fb2=complement»)
берете раздачу, два последних месячника fb2 из https://booktracker.org/viewforum.php?f=255 (июнь, июль) и inpx -> профит!
|
|
|
| GGOwl
|
А что - после 1.06.2023 полная сборка не обновляется?
|
|
|
| Hibor
|
GGOwl писал(а): А что - после 1.06.2023 полная сборка не обновляется? на отдыхе до сентября https://booktracker.org/viewtopic.php?p=305051#305051
|
|
|
| Mr.Shniv
|
Есть ли какая-нибудь возможность сжать это дело, раза в 2? Или фантастика? Пускай даже в счет скорости открытия. Также хочу выразить величайшую благодарность всем тем кто делает возможным чтение данных книг. Уже больше 10 лет эта библиотека у меня на диске. Сортировка по "Сериям" - одна из лучших особенностей.
|
|
|
| Hibor
|
Mr.Shniv писал(а): Есть ли какая-нибудь возможность сжать это дело, раза в 2? Или фантастика? Пускай даже в счет скорости открытия. только если переделать в частную, т.е. уйти с раздачи и перелопатить коллекцию (и поддерживать уже самостоятельно) удалить не нужные языки, удалить «удаленные» (те что имеют явно указанную замену), удалить дубли вложений, не подвязанные и уменьшить экстра-большие обложки (там бывает на маленький рассказик лежит png-шка как будто так себе по качеству скан плакатом печатать решили), оптимизировать и т.д. в моей частной как раз выходит ~50% от раздачи но вообще можно и дальше пойти - убрать журналы (те что только номер, они тупо не поддаются поиску - только полнотекстовый, но индекс на треть объема кому это надо, удобнее отдельно нужные качать в pdf), почистить дубли (те что в самой библиотеке не помечены как замененые - таких много, но тут или в ручную, или авто но "с потерями"), перепаковать в zip-lzma (и в каталогизатор поддержку вставить), преобразовать вложения в более экономные форматы - все без прозр. и >8b в jpg, остальное в оптимизированный png и т.д. - все зависит от навыков и желания вкладываться но все сводится к : 1) начинаешь переделывать -> уходишь с раздачи, поддержка уже на тебе 2) готовься к загрузке компа на 2-3 суток при первой обработке и день потраченного личн. времени на ручную правку, плюс каждый месяц при обнове - грубо полчаса внимания 2) коллекция будет не "архивы-месячники", а много файлов 1 архив=1 книга по директориям - без этого работать крайне медленно и неудобно, но так нагрузка чуть больше 3) НУЖНЫ минимальные навыки работы с автоматизацией работы, sql, xml, графикой и остальным что в голову придет (какой-нибудь язык неплохо бы) 1) варианты перейти на какой-нибудь другой алгоритм сжатия, что во все времена библиотек предлагались, упираются в то что основной объем - почти несжимаемые вложения-картинки, так что выигрыш при пережатии например в PPMd что вроде как для текстов хорошо - незначителен я как-то ради эксперимента пробнул подобный "лучший" (если не глубляться совсем в дебри сжатия) вариант «упаковки» : a) из fb2 извлекаются все вложения (кладутся в поддиректорию) (экономия в 4/3 к 3/3 т.е. 33% веса картинок без учета сжатия) b) извлеченные вложения пакуются специализированными пакерами вроде packjpg или brunsli (~10% для jpg, для png сильно вариативно - там речь чисто о подборе оптимального варианта фильтров/стратегии, а не о доп.сжатии) c) весь текст (все книги в выборке, для примера - месячник) пакуем слитно (solid) PPMd с префильтром - так как там только текст (xml) то сжатие сильное d) добавляем к "C" "B" в быстрый solid (просто для скорости, сжатие мизерное если без дублей) и ту да же батник с утилитками для обратного преобразования вообщем в таком виде выигрыш в ~30% относительно изначального ZIP-месячника, но вот о скорости доступа к конкретной книге речи вообще нет - просто фан, не более 2) обычно те кто хотят уменьшить объем своей коллекции без навыков и желания особо вникать, заниматься идут по 2м вариантам: 1) удаляют не свои языки, «удаленные» в библиотеке на конкретное число и без проверок (точно будут «потери» и расхождения) и начинают резать жанры 2) удаляют все вложения, максимум оставляют мини-обложку - вариант уменьшить объем кардинально, но соответственно для многих книг это уже совсем не то 3) кстати, пока делаете «частную» коллекцию заодно будете править «глупость человеческую» - чего там только нет, начиная от webp и ani-gif'ок (которые в формате вообще не предусмотрены, как следствие читалки что работают сами, а не конвертируют в html их пропускают), заканчивая полным не знанием формата (для примера - дубли id во вложениях), это уж не говоря о структурных ляпах, обложках в теле а не дскриптионе и т.п. зато своя коллекция будет более «причесана» 
|
|
|
| Mr.Shniv
|
Hibor писал(а): Mr.Shniv писал(а): Есть ли какая-нибудь возможность сжать это дело, раза в 2? Или фантастика? Пускай даже в счет скорости открытия. только если переделать в частную, т.е. уйти с раздачи и перелопатить коллекцию (и поддерживать уже самостоятельно) удалить не нужные языки, удалить «удаленные» (те что имеют явно указанную замену), удалить дубли вложений, не подвязанные и уменьшить экстра-большие обложки (там бывает на маленький рассказик лежит png-шка как будто так себе по качеству скан плакатом печатать решили), оптимизировать и т.д. в моей частной как раз выходит ~50% от раздачи но вообще можно и дальше пойти - убрать журналы (те что только номер, они тупо не поддаются поиску - только полнотекстовый, но индекс на треть объема кому это надо, удобнее отдельно нужные качать в pdf), почистить дубли (те что в самой библиотеке не помечены как замененые - таких много, но тут или в ручную, или авто но "с потерями"), перепаковать в zip-lzma (и в каталогизатор поддержку вставить), преобразовать вложения в более экономные форматы - все без прозр. и >8b в jpg, остальное в оптимизированный png и т.д. - все зависит от навыков и желания вкладываться но все сводится к : 1) начинаешь переделывать -> уходишь с раздачи, поддержка уже на тебе 2) готовься к загрузке компа на 2-3 суток при первой обработке и день потраченного личн. времени на ручную правку, плюс каждый месяц при обнове - грубо полчаса внимания 2) коллекция будет не "архивы-месячники", а много файлов 1 архив=1 книга по директориям - без этого работать крайне медленно и неудобно, но так нагрузка чуть больше 3) НУЖНЫ минимальные навыки работы с автоматизацией работы, sql, xml, графикой и остальным что в голову придет (какой-нибудь язык неплохо бы) 1) варианты перейти на какой-нибудь другой алгоритм сжатия, что во все времена библиотек предлагались, упираются в то что основной объем - почти несжимаемые вложения-картинки, так что выигрыш при пережатии например в PPMd что вроде как для текстов хорошо - незначителен я как-то ради эксперимента пробнул подобный "лучший" (если не глубляться совсем в дебри сжатия) вариант «упаковки» : a) из fb2 извлекаются все вложения (кладутся в поддиректорию) (экономия в 4/3 к 3/3 т.е. 33% веса картинок без учета сжатия) b) извлеченные вложения пакуются специализированными пакерами вроде packjpg или brunsli (~10% для jpg, для png сильно вариативно - там речь чисто о подборе оптимального варианта фильтров/стратегии, а не о доп.сжатии) c) весь текст (все книги в выборке, для примера - месячник) пакуем слитно (solid) PPMd с префильтром - так как там только текст (xml) то сжатие сильное d) добавляем к "C" "B" в быстрый solid (просто для скорости, сжатие мизерное если без дублей) и ту да же батник с утилитками для обратного преобразования вообщем в таком виде выигрыш в ~30% относительно изначального ZIP-месячника, но вот о скорости доступа к конкретной книге речи вообще нет - просто фан, не более 2) обычно те кто хотят уменьшить объем своей коллекции без навыков и желания особо вникать, заниматься идут по 2м вариантам: 1) удаляют не свои языки, «удаленные» в библиотеке на конкретное число и без проверок (точно будут «потери» и расхождения) и начинают резать жанры 2) удаляют все вложения, максимум оставляют мини-обложку - вариант уменьшить объем кардинально, но соответственно для многих книг это уже совсем не то 3) кстати, пока делаете «частную» коллекцию заодно будете править «глупость человеческую» - чего там только нет, начиная от webp и ani-gif'ок (которые в формате вообще не предусмотрены, как следствие читалки что работают сами, а не конвертируют в html их пропускают), заканчивая полным не знанием формата (для примера - дубли id во вложениях), это уж не говоря о структурных ляпах, обложках в теле а не дскриптионе и т.п. зато своя коллекция будет более «причесана» Огромное спасибо за развернутый ответ, я пожалуй решу проблемы покупкой нового диска. Отказываться от обновлений не хочется, я помню данная раздача начиналась чуть ли не с 80Гб, а сейчас вон оно какое. 
|
|
|
| Hibor
|
Mr.Shniv писал(а): Отказываться от обновлений не хочется не, не совсем отказываться просто обновлять придется именно что самому - качать последний месячник отсюда (или дейлики), чистить его аналогично своей коллекции и генерить по ней свой inpx, т.е. просто качнуть с раздачи новый архив и новый inpx уже не выйдет - придется каждый месяц чуть усилий и знаний прикладывать но, да, в целом если именно чистить и упорядочивать коллекцию желания нет, а только объем беспокоит - проще винт купить Mr.Shniv писал(а): раздача начиналась чуть ли не с 80Гб, а сейчас вон оно какое. мне больше нравится сравнивать развитие с HarryFan CD Загуменова, если брать именно цельные "раздачи" (не сайт и не отдельные подборки книг) представьте цельный компакт (еще не особо распространенный) с 400+Mb хорошо отформатированного текста в архивах и с отличной БД, с классикой и соврем., русскими и переводами - с упором на фантастику и чуть детективы/боевики. для чистого текста это очень много и это во времена жестко ограниченного нета, когда тексты на дискетках таскали или в лучшем случае с ббски качали более поздние «Библиотеки в кармане» с Мошковской библиотекой такого ощущения уже не давали - и формат так себе (просто слитые html-ки), и бд-каталогизатор на скорую руку, да и инет уже был в порядке вещей хоть и модемный все еще образ и сканы обложек на винте держу, ностальжи... 
|
|
|
| Nab0y
|
Mr.Shniv писал(а): Отказываться от обновлений не хочется, я помню данная раздача начиналась чуть ли не с 80Гб, а сейчас вон оно какое. Раз все пошли в воспоминания, как сейчас помню в 2011 я сидел на Либрусеке, тогда он был 63Гб, потом у них случился кризис, ну там "мы теперь официальные, все пиратское удаляем и т.п.", ну я и перешел на эту раздачу. Шли годы, раздача росла, сначала перенес на внешний террабайтник, но индексация хоть и по USB3 но все равно занимала от получаса до часа, потом новый комп, два террабайтных SSD, почти пол террабайта, под эту раздачу. В начале этого года обзавелся NAS, первым делом переехали аудиокниги в Audiobookshelf (кто не видел, люто рекомендую) и эта раздача, проблема встала с клиентом MyHomeLib все же виндовый клиент, а NAS - Linux и вообще не в квартире. Нашел inpx-web от Букпаука, которому тоже низкий поклон, видел он тут пробегал пару раз, там и OPDS есть, так что PoketBook нормально цепляется, не говоря уже о других читалках, его Liberama, просто шедевр, лично я полностью отказался от FBReader и прочих Alreader, все в браузере, все настраивается, место остановки синхронизируется между сессиями. Потом настроил torrent клиента в NAS на автоматическую закачку раздачи при изменении, после раздачи x3 от скаченного оно само отключается, inpx-web тоже на автомате начинает перестройку, как почует, что .inpx индекс изменился, короче я вообще сейчас руками ничего не трогаю, просто захожу и пользуюсь. А семитеррабайтных дисков на NAS думаю мне еще лет на 20 хватит расширения раздачи.
|
|
|
| Motoren
|
Добрый день, версия myhomelib более новая поддерживается? Или иная программа, в этой так неудобно иной раз ориентироваться...баги
|
|
|
| Hibor
|
Motoren писал(а): Добрый день, версия myhomelib более новая поддерживается? Или иная программа, в этой так неудобно иной раз ориентироваться...баги А что за баги? Сам формат inpx не менялся. От программы к программе (относительно inpx) разница только в поддержке разных доп.полей в таблицах (в версиях MHL это не менялось). Так что новые версии MHL должны работать, если нет (новые баги) - откатитесь на старую стабильную 2.3.3.829 (она годы пользовалась всеми пока автор про нее не вспомнил и не начал «улучшать»).
|
|
|
|
