Игнор ошибок в теле книг

Oct 21, 2013 at 10:51 AM
Здравствуйте! Отличная программа!

Единственная просьба: можно ли добавить в программу галочку, чтобы она игнорировала ошибки в теле книг?

А то в библиотеке либрусека 10% книг с ошибками.
Coordinator
Oct 21, 2013 at 1:59 PM
Нет.
Oct 21, 2013 at 2:15 PM
А почему? Я уже предлагал отказоустойчивый парсер.
Coordinator
Oct 21, 2013 at 2:55 PM
Edited Oct 21, 2013 at 3:30 PM
Потому, что есть определенные правила и законы. "Отказоустойчивый" XML парсер - это оксюморон (даже если на основе его и удастся переписать библиотеку fb2librarynet и конвертеры fb2epub, в чем лично я весьма сомневаюсь).

Иначе просто нельзя; это будет возврат к книгам в текстовых файлах с непонятной кодировкой, в rtf документах и всему тому "мессу", от которого потихоньку за десятилетие удалось уйти.

P.S. Конструктивный вариант - это создать (на основе лог-файла) список ошибочных книг, собрать инициативную группу из библиотекарей на Либрусеке/Флибусте/"The-ebook"-е, и начать "чинить" подобные книжки с помощью FBE, потихоньку "перезаливая" их обратно на сервера. В случае с либрусеком, это даст исполнителям даже определенный бонус (помимо сознания того, что они делают правильное дело) - бесплатный доступ к библиотеке.
Oct 21, 2013 at 3:34 PM
Да я все понимаю, соблюдение стандартов - это прекрасно, но к сожалению мы живем в неидеальном мире вынуждены подстраиваться под правила игры. Вот, например, сколько разных mime типов существует для fb2? И используемый в TinyOPDS application/fb2 можно назвать стандартным лишь с большой натяжкой. А приходиться использовать именно его, иначе большинство клиентов не сможет скачивать книги из каталога.

Ни TinyOPDS, ни моя программа, не служат для создания новых книг (в этом случае необходимость следования стандартам не оспаривается), а служат всего лишь для катологизации коллекций пользователей, и если у пользователя 10% книг с ошибками, то наша задача - хотя бы попытаться их прочитать. Тот же WebBrowser пытается показать страницу пользователю, не смотря на ошибки в HTML верстке.
Coordinator
Oct 21, 2013 at 3:45 PM
Edited Oct 21, 2013 at 3:49 PM
Поскольку OPDS не стало еще/пока ISO-стандартом, и развивается "наколеночно", на энтузиазме (что, в общем, вызывает у меня недоумение, честно говоря - маркет-то огромный!), то в этом удивительного ничего нет. Вывод TinyOPDS я писал, ориентируясь на реализацию OPDS флибусты (благо, и сорцы, и сервер (иногда) доступны :) ).

Говоря об ошибках в XML, замечу, что XML отличается от HTML принципиально. Если в HTML мы можем себе позволить некоторую fuzzy logic, и рендерить по "сверху вниз", то само определение XML не допускает разногласий... Ну, как ты будешь отрабатывать тэги, если внутри напиханы открывающие и закрывающие скобки ("<", ">") в непонятном порядке? Я понимаю, что можно, конечно, "извратиться", но делать этого НЕ нужно.

Лично я этого не буду делать принципиально; я большой сторонник fb2, и очень не люблю все эти epub-ы и прочую аморфную ерунду. Превращать же стройный fb2 в эту ерунду для меня равносильно святотатству :)

P.S. Я же предложил конструктивный вариант - нужно просто править книжки. Period! Сотни людей на флибусте сидят целый день и страдают фигней - постят бессмысленные комментарии, фотки "котегов", флейм. Если бы каждый из них отредактировал хотя бы одну-две книги, проблему невалидных книг можно было-бы решить за неделю!
Oct 21, 2013 at 5:55 PM
SeNS wrote:
Поскольку OPDS не стало еще/пока ISO-стандартом, и развивается "наколеночно", на энтузиазме (что, в общем, вызывает у меня недоумение, честно говоря - маркет-то огромный!), то в этом удивительного ничего нет. Вывод TinyOPDS я писал, ориентируясь на реализацию OPDS флибусты (благо, и сорцы, и сервер (иногда) доступны :) ).
Ну, конечно, не ISO стандарт, но всё же официальная спецификация существует

SeNS wrote:
Говоря об ошибках в XML, замечу, что XML отличается от HTML принципиально. Если в HTML мы можем себе позволить некоторую fuzzy logic, и рендерить по "сверху вниз", то само определение XML не допускает разногласий... Ну, как ты будешь отрабатывать тэги, если внутри напиханы открывающие и закрывающие скобки ("<", ">") в непонятном порядке? Я понимаю, что можно, конечно, "извратиться", но делать этого НЕ нужно.
Нужно или не нужно - разговор отдельный, а вот с такого рода ошибками парсер справляется на ура.

SeNS wrote:
Лично я этого не буду делать принципиально; я большой сторонник fb2, и очень не люблю все эти epub-ы и прочую аморфную ерунду. Превращать же стройный fb2 в эту ерунду для меня равносильно святотатству :)
Ok
Coordinator
Oct 21, 2013 at 6:24 PM
Нужно просто взять список всех невалидных книг, прогнать их через твой fb2fix, а потом залить их на флибусту/либрусек, и перевыложить раздачу ;)
Oct 21, 2013 at 6:55 PM
SeNS wrote:
Нужно просто взять список всех невалидных книг, прогнать их через твой fb2fix, а потом залить их на флибусту/либрусек, и перевыложить раздачу ;)
Это уже кто-то, когда-то предлагал. Но народ очень настороженно относится ко всяким автоматическим "исправляторам", так-что тема заглохла. Но это будет решением проблемы ТС - он может прогнать локальную коллекцию через Fb2Fix.
Coordinator
Oct 21, 2013 at 8:07 PM
Согласен. Попрошу редактора добавить данный совет в FAQ.
Oct 21, 2013 at 9:04 PM
Gremlin2 wrote:
<...> прогнать локальную коллекцию через Fb2Fix.
эммм... Если исходная книжная коллекция упорядочена -- книжки разложены по каталогам (например, как в библиотеке Траума), после обработки fb2fix исправленные книги все окажутся в одной директории?
Ну да, TinyOPDS все равно упорядочит это дело в OPDS... но на диске то будет свалка... Что-то такой метод не очень нравится...

PS А к fb2fix, оказывается, и GUI есть. ))
Oct 22, 2013 at 9:54 AM
Krok_us wrote:
PS А к fb2fix, оказывается, и GUI есть. ))
Есть, но это не моя заслуга.
Oct 22, 2013 at 9:56 AM
Link100 wrote:
А то в библиотеке либрусека 10% книг с ошибками.
А можно мне на admin@fb2library.net пару примеров книг с ошибками?
Oct 22, 2013 at 8:32 PM
Жаль, что у автора такая жёсткая позиция по этому вопросу. Ядро fb2fix'a прекрасно справилось с присланными мне примерами, да и встроить его в существующую инфраструктуру TinyOPDS дело пары минут. Но хозяин - барин. Если передумаешь, ты знаешь где меня найти.
Coordinator
Oct 22, 2013 at 10:23 PM
Gremlin2 , пришли патч (желательно для этого файла https://tinyopds.codeplex.com/SourceControl/latest#trunk/TinyOPDS/Parsers/fb2Parser.cs . Кстати, у меня там есть уже некоторые workarounds).

Если будет нормально работать, добавлю опционально, для любителей невалидных xml - пусть читалки вылетают :)
Oct 23, 2013 at 10:55 AM
Предлагаю такое решение:
  1. Интегрировать fb2fix в TinyOPDS.
  2. В TinyOPDS при сканировании игнорировать книги с ошибками.
  3. При запросе книги пропускать её через fb2fix и отправлять на клиент уже исправленный вариант.
Coordinator
Oct 23, 2013 at 1:05 PM
Link100, твое решение не подойдет: невалидную книжку TinyOPDS просто не добавит в базу, а значит, не будет знать о ее существовании. IMHO, все-таки лучший вариант (для максималистов, которым очень нужна эта тысяча неряшливо сделанных Ларинским авто-конвертером книжек):
  • просканировать библиотеку;
  • сделать grep на TinyOPDS.log, чтобы извлечь все ошибочные книжки;
  • обработать их fb2fix;
  • запустить сканирование еще раз (пройдет намного быстрее, собственно, будут обработаны только отсутствующие в базе книги).
Если кто-то сможет проделать все это сам (для эксперимента), а потом внятно (по шагам) описать процесс, то я добавлю это в FAQ, и, таким образом, проблема будет решена.
Oct 23, 2013 at 1:26 PM
Edited Oct 23, 2013 at 1:27 PM
SeNS wrote:
Gremlin2 , пришли патч (желательно для этого файла https://tinyopds.codeplex.com/SourceControl/latest#trunk/TinyOPDS/Parsers/fb2Parser.cs . Кстати, у меня там есть уже некоторые workarounds).

Если будет нормально работать, добавлю опционально, для любителей невалидных xml - пусть читалки вылетают :)
Хорошо, так и сделаем.
Coordinator
Oct 23, 2013 at 2:22 PM
Спасибо!
Oct 23, 2013 at 7:02 PM
SeNS wrote:
Спасибо!
Пожалуйста! Куда патч заливать?
Coordinator
Oct 23, 2013 at 7:42 PM
Edited Oct 24, 2013 at 5:12 AM
Мне на мыло: sens точка boston на gmail точка ком (не знаю, "пасутся"-ли тут спам-боты) или куда-нить себе (типа, на dropbox). Заодно выложи свою сборку, если можно: пусть ТС и желающие протестируют сразу.

P.S. И какую информацию в окошко About добавить?
Oct 23, 2013 at 8:22 PM
SeNS wrote:
Мне на мыло: sens точка boston на gmail точка ком (не знаю, "пасутся"-ли тут спам-боты) или куда-нить себе (типа, на dropbox). Заодно выложи свою сборку, если можно: пусть ТС и делающие протестируют сразу.
Отослал, желающие могут загрузить тестовую сборку отсюда
P.S. И какую информацию в окошко About добавить?
Ссылку на страницу проекта fb2fix, если тебе будет не трудно.
Coordinator
Oct 23, 2013 at 8:46 PM
Gremlin2 wrote:
Ссылку на страницу проекта fb2fix, если тебе будет не трудно.
Абсолютно не трудно :)
Oct 23, 2013 at 9:55 PM
Edited Oct 23, 2013 at 9:57 PM
SeNS wrote:
Link100, твое решение не подойдет: невалидную книжку TinyOPDS просто не добавит в базу, а значит, не будет знать о ее существовании.
Уважаемый SeNS, предлагаю проверять только секцию <description> при добавлении книги в базу, а <body> пропускать не проверяя. А затем, при выдаче, прогнать книгу через fb2fix и отправить уже исправленный вариант.

Данное решение, как мне кажется, имеет преимущества:
  1. Не придётся испрвлять всю библиотеку.
  2. Работу практически не замедляет.
Исправление всей библиотеки кажется делом довольно сложным.
Например библиотека librusec (которая имеется у меня, — не знаю насколько она официальная, скачивал с торрентов) состоит из 64 zip-архивов и весит около 100 Гб.
  1. fb2fix не умеет исправлять ошибки и помещать обратно в архив: она кладёт их все в один каталог. Придётся запускать программу 64 раза с разными параметрами, а затем 64 раза создавать архив. Хотя, конечно, можно придумать батник для этого, но тогда смотри 2-3 пункты. Кстати, стандартным winrar'ом zip-файл такого объёма (~1.5 Гб) не создать.
  2. Даже если исправить все ошибки и поместить их в архивы как было — очередное обновление убьёт всю проделанную работу.
  3. Торрент уже нельзя будет запустить, т.к. файлы будут изменены.
Конечно, самым радикальным и идеальным способом является исправление библиотеки и выкладывание её в интернет, но как уже писал уважаемый Gremlin2, с этим проблемка. Народ у нас не очень-то активный чтобы исправлять вручную, а всяких автоматических вещичек побаиваются.
Coordinator
Oct 23, 2013 at 10:02 PM
Link100 , опробуй, pls, пропатченную версию, которую камрад Gremlin2 выложил (двумя постами выше). Думаю, что это решит проблему.
Oct 23, 2013 at 11:07 PM
SeNS, проверил пропатченную версию. Ошибок при добавлении книг стало всего ничего. Проверил только один zip-файл с 23000 книг, нашёл только 45 ошибок. Это замечательно! Начинаю верить, что такими темпами мы таки построим коммунизм :)

Теперь осталось только 1 пожелание: исправление книги на лету во время её выдачи.
Coordinator
Oct 24, 2013 at 1:51 AM
Это чуть сложнее будет имплементировать: ведь не будешь каждую книгу в обязательном порядке прогонять через fb2fix (кстати, Романов конвертер (fb2epub) делает это при создании epub-ов, но для нормальных fb2 этого хотелось-бы избежать).

В общем, нужно думать... Тут камраду Gremlin2-у, как говорится, и карты в руки ;) (только patch лучше делать не через git!)
Coordinator
Oct 24, 2013 at 4:35 AM
Edited Oct 24, 2013 at 2:37 PM

Результаты тестирования патча от Gremlin2

Решил протестировать патч "нестрогого" парсера XML и был, признаться, немного разочарован результатами. Для теста использовалась копия флибусты 3-х месячной давности из раздачи на торрентс.рус.ек.
Число zip-архивов: 34, размер архивов: 42,714,625,212 байта, общее число fb2 файлов: 169100

C новым парсером:

Image

Cо старым парсером:

Image

Во-первых, сканирование с новым парсером дало неверный результат: 173390 файлов вместо 169100
Во-вторых, выигрыш составил всего 162184-159629 = 2555 книжек (замечу, явно не лучшим образом форматированных и оформленных книжек!)
В-третьих, скорость сканирования замедлилась в 2 раза

Резюмируя: со старым алгоритмом было "потеряна" 9471 книга, из которых 6288 дубли (т.е. старые версии книг), т.е. реальных потерь - 3183 документа, что составляет : 100 / 169100 * 3183 = 1.88%

Так что я пока не созрел для коммитта данного изменения в транк. Камраду Gremlin2-у я все равно глубочайше признателен, так что ссылку на его сайт в About-е дам в любом случае :)

P.S. Тестирование "оригинального" парсера проводилось последней сборкой вот отсюда https://www.dropbox.com/sh/7bdoinns0te2vwd/jjOI2U5wu7
Link100, ты, видимо, сканировал официальной версией 1.1? С тех пор уже много воды утекло - используй сборку из транка. Если все будет хорошо - скоро выйдем на официальную бету и релиз.
Oct 24, 2013 at 9:25 AM
Edited Oct 24, 2013 at 9:25 AM
Господа,
http://downloads.fb2library.net/TinyOPDS.zip (выложенная Gremlin2)
и
https://www.dropbox.com/sh/7bdoinns0te2vwd/jjOI2U5wu7 (выложенная SeNS)
это разные версии, хотя у обоих в свойствах стоит версия 1.2.0.0. Exe-шники отличаются по размерам.

Так вот, 1 версия практически без ошибок добавляет книги: вышло 45 ошибок на 22807 книг. Вторая: 1322 ошибки на 22807 книг.
Coordinator
Oct 24, 2013 at 12:49 PM
Link100, я доверяю тому, что лично сам вижу. Я привел данные воспроизводимого теста; данный тест меня лично не устроил по причинам, описанным выше. Могу еще, смеха ради, проверить на архиве либрусека, но почти уверен, что результат будет похожим...

P.S. Откуда ты взял эти 22807 книг?
Oct 24, 2013 at 1:24 PM
SeNS, картинки не видны. Откуда разница в количестве, я честно говоря, не знаю. Её быть не должно, так-как патч не затрагивает код сканирования, он изменяет способ загрузки XDocument'a, что ну никак не может повлиять на количество файлов. Да скорость сканирования замедлилась, но за всё нужно платить. Эту проблему можно решить либо через настройки программы, сделав парсер fb2fix'a опциональным, либо использовать его после того, как основной парсер выбросил исключение.

Исходя из лога, присланного мне Link100, большинство ошибок происходят уже после загрузки XDocument'a, сегодня вечером постараюсь разобраться с этим и если получится, выложу новую версию для тестов.
Coordinator
Oct 24, 2013 at 2:44 PM
Edited Oct 24, 2013 at 3:23 PM
Gremlin2, на счет разницы в количестве разобрался: я скопировал файлы библиотеки на скоростной SSD, и, видимо, запустил TinyOPDS, когда сканирование еще не завершилось, а флажок отслеживать изменения был включен :) Да, парсер не должен влиять никак. Сейчас делаю второй эксперимент - сканирую полный либрусек, результаты приведу позже.

Gremlin2 wrote:
использовать его после того, как основной парсер выбросил исключение.
Это, как мне кажется, лучший вариант. И так уже настроек для "tiny" программы слишком много, на мой взгляд.

P.S. Андрей, только делай, пожалуйста, patch через svn или стандартный diff; git-патчи приходится редактировать (убирать заголовки git-а).
Coordinator
Oct 24, 2013 at 5:49 PM
Edited Oct 24, 2013 at 5:54 PM
Закончил сканирование либрусека. Результаты у нового парсера чуть получше, но и старый вовсе не пропускает 10%. Разница всего в 2515 ошибочных книг, что составляет лишь 1%.

Скорость сканирования ниже в те-же 2 раза.

C новым парсером:

Image

Cо старым парсером:

Image

Если удастся добиться приемлимой скорости, используя новый парсер только при исключениях, то можно будет включить в mainline код. Хотя остается открытым вопрос: как выдавать невалидные книжки читалкам?..
Oct 24, 2013 at 7:18 PM
SeNS wrote:
Если удастся добиться приемлимой скорости, используя новый парсер только при исключениях, то можно будет включить в mainline код. Хотя остается открытым вопрос: как выдавать невалидные книжки читалкам?..
У меня есть на этот счет одна идея, но, к сожалению, раньше выходных не получится выделить время для TinyOPDS. Новой тестовой версии раньше субботы тоже ждать не стоит.
Sorry. Совсем завал на работе.
Coordinator
Oct 24, 2013 at 7:40 PM
Edited Oct 25, 2013 at 4:20 AM
Don't be sorry, take your time :)

Никто никуда не торопится особо - не хватало мне еще дедлайнов для хобби-прожекта! :D Для официального релиза Слава должен поработать еще над xsl трансофрмацией.
Oct 26, 2013 at 4:06 PM
Залил на сайт новую версию для тестов. Патч лежит в разделе Patches

SeNS дай мне знать, если с ним возникнут проблемы.
Coordinator
Oct 27, 2013 at 1:22 PM
Edited Oct 27, 2013 at 2:30 PM
Спасибо! Только вчера ночью смог опробовать, результат вполне удовлетворительный, закоммиттил в транк.

Image

P.S. Выложил новые сборки на старое место https://www.dropbox.com/sh/7bdoinns0te2vwd/jjOI2U5wu7
Nov 1, 2013 at 7:40 AM
Edited Nov 1, 2013 at 7:49 AM
Что у вас за процессор, если не секрет?
У меня, результаты по времени сканирования просто впечетляющие, и памяти почему-то ест немеряно. А в остальном всё замечательно всего 690 ошибочных книг
При чём почти все ошибки вида:
11.01.2013 00:28:05.9   E       ZipScanner      Book.Parse() exception The object was used after being disposed. on file: /media/bravo123/HTPC-DATA/eBook/Tr$
11.01.2013 00:28:06.0   E       ZipScanner      Book.Parse() exception The object was used after being disposed. on file: /media/bravo123/HTPC-DATA/eBook/Tr$
11.01.2013 00:28:06.1   E       ZipScanner      Book.Parse() exception The object was used after being disposed. on file: 
и так далее.

Image
Nov 1, 2013 at 7:50 AM
Edited Nov 1, 2013 at 7:50 AM
.
Nov 1, 2013 at 8:32 AM
BraVo123 wrote:
У меня, результаты по времени сканирования просто впечетляющие, и памяти почему-то ест немеряно. А в остальном всё замечательно всего 690 ошибочных книг
При чём почти все ошибки вида:
и так далее.
Если вам не трудно, хотелось бы получить пару примеров ошибочных книг мне на почту: admin@fb2library.net
Спасибо.
Nov 1, 2013 at 9:51 AM
Отправил
Coordinator
Nov 1, 2013 at 1:14 PM
BraVo123 wrote:
Что у вас за процессор, если не секрет?
Не секрет, Intel Core i7-4770. Для данных тестов я скопировал архивы на высокопроизводительный SSD от Samsung (840 Pro series). Система: Windows 8 Pro, 16 GB RAM (этой мой development PC, кстати, далеко не самый дорогой)
Nov 3, 2013 at 9:17 AM

1. Результаты парсинга отличные.

Всего книг в базе: 252021
Ошибочных книг: 1111
Пропущено книг: 0
Дубликаты: 12968
Обработано книг: 266100.
Прошло времени: 03:26:08
Скорость: 1291 books/min
Статус: ЗАКОНЧИЛ

2. Памяти жрёт немеряно.

После сканирования процесс весит 987 Мб. Флажок "Режим экономии памяти" взведён.

3. Найдено три типа ошибок.

Ошибка A): 11.03.2013 05:34:20.4 E ZipScanner Book.Parse() exception Значение не может быть неопределенным.
Ошибка B): 11.03.2013 05:34:26.5 E ZipScanner Book.Parse() exception Пустая строка "" не является допустимым локальным именем.
Ошибка C): 11.03.2013 06:04:43.4 E ZipScanner Book.Parse() exception Не удается добавить в содержимое знаки, отличные от пробела.

4. Количество ошибок в статистике и лог-файле отличается.

Итого количество в лог-файле
Ошибка A): 72 штуки
Ошибка B): 4 штуки
Ошибка C): 1 штука
Итого: 76, а должно быть 1111.

В библиотеке всего 64 zip-файла. А вышеописанные ошибки относятся только к первым 8 файлам.
Такое чувство, что начиная с какого-то момента он перестал писать ошибки в лог-файл.

Примеры ошибочных книг отправил на admin@fb2library.net

Image
Coordinator
Nov 3, 2013 at 2:40 PM
Edited Nov 3, 2013 at 2:41 PM
Link100, большое спасибо за тестирование и анализ! Проекту фатально не хватает бета-тестеров...

По пунктам:

2) Да, это так, к сожалению: и сама база хранится в памяти, и все операции с базой проходят в RAM при помощи "жрущих" LINQ запросов. Также, очень вероятно, при сканировании есть утечки памяти (штука, сложная для отладки и устранения, даже при профилировании). Не знаю, может, камрад Gremlin2 взглянет по свободе - так сказать, принцип "второго взгляда" может оказаться полезным (мне-то код примелькался).
Режим "экономии памяти" работает только в обычном режиме (не сканировании); при этом не грузятся в память book description (как правило, состоящие из множества строк и занимающие изрядно места).

3) Думаю, Gremlin2 сможет это пофиксить. Впрочем, хочу напомнить: пока никаких действий с невалидными fb2 не производится, и они выдаются читалкам как есть (as is). Теоретически, это тоже можно пофиксить; дружно просим уважаемого Gremlin2-а добавить код fb2fix (в случае больших архивов, я все равно распаковываю и пережимаю в zip; пропустить stream через fb2fix не должно быть сильно накладно. Впрочем, это все нужно имплементировать и тестировать).

4) Вполне может быть как баг в логе, так и при сканировании (не всегда пишутся сообщения об ошибках в лог). Возможно, это как-то связано и с утечкой памяти, исходя из твоего анализа. Будем посмотреть... (хотя подобного рода ошибки очень сложно отлавливать).
Nov 25, 2013 at 6:53 AM
SeNS wrote:
Link100, большое спасибо за тестирование и анализ! Проекту фатально не хватает бета-тестеров...

3) Думаю, Gremlin2 сможет это пофиксить. Впрочем, хочу напомнить: пока никаких действий с невалидными fb2 не производится, и они выдаются читалкам как есть (as is). Теоретически, это тоже можно пофиксить; дружно просим уважаемого Gremlin2-а добавить код fb2fix (в случае больших архивов, я все равно распаковываю и пережимаю в zip; пропустить stream через fb2fix не должно быть сильно накладно. Впрочем, это все нужно имплементировать и тестировать).
У меня наконец то появилось немного времени для этого проекта, я протестировал присланные мне файлы и все они добавились без ошибок, Так что, пока я слоняюсь к мнению, что эти ошибки были вызваны недостатком памяти. По поводу отдачи невалидных файлов. Была такая идея: про сканировании помечать такие файлы специальным флагом и при отдачи их пользователю пропускать их через fb2fix. Вот только я не знаю, возможно ли безболезненно изменить класс Book (добавить новое поле/свойство) , что-бы ничего не поломать.
4) Вполне может быть как баг в логе, так и при сканировании (не всегда пишутся сообщения об ошибках в лог). Возможно, это как-то связано и с утечкой памяти, исходя из твоего анализа. Будем посмотреть... (хотя подобного рода ошибки очень сложно отлавливать).
Надо будет запустить под профайлером и посмотреть где возможно не освобождается память. Я, по своему опыту, могу сказать, что при таких объемах обрабатываемых данных "вылазят" очень неочевидные нюансы. Профайлер у меня есть осталось найти достаточный объем данных для тестов.
Coordinator
Nov 25, 2013 at 1:17 PM
Edited Nov 25, 2013 at 1:19 PM
Gremlin2 wrote:
У меня наконец то появилось немного времени для этого проекта,
Везет тебе (завидуя "по белому")! А у нас, как обычно, под Xmas вместо деда Мороза приходит дед Лайн :)

Gremlin2 wrote:
По поводу отдачи невалидных файлов. Была такая идея: про сканировании помечать такие файлы специальным флагом и при отдачи их пользователю пропускать их через fb2fix. Вот только я не знаю, возможно ли безболезненно изменить класс Book (добавить новое поле/свойство) , что-бы ничего не поломать.
Совсем "безболезненно" не получится, придется все-таки базы старой версии патчить на лету при загрузке и сохранять в новом формате (как было сделано в предыдущей версии - я добавил в класс Book дату добавления. Ну, т.е. для пользователей это будет достаточно "безболезненно" :)
C другой стороны, пока еще ни один человек не пожаловался, что добавленные таким путем книжки не читаются , все клеймили в основном на то, что не ищутся ;) Я предлагаю поставить это в виш-лист и on hold, до первых реквестов - дабы не тратить твое время.

Я наберусь наглости, и попрошу тебя (если, конечно, есть на то желание!) посмотреть в сторону рефакторинга класса Library (это я в стиле project manager-ов называю рефакторингом то, что означает "произвести полный R&D" :D - готовлюсь, понимаешь ;) ). Если без шуток, то хотелось-бы попробовать переписать работу с базой через embeddable SQL server какой-нибудь: MySQL, Микрософтовскую имплементацию или еще какую-нибудь. Главное - чтобы работало на Mono, и на arm-е (в дополнение к стандартному .NET-у и x86/64).
Все-таки было-бы любопытно запустить TinyOPDS на моем RPi (хотя я ему сейчас нашел и другое применение, см Image

P.S. Если не возражаешь, я добавлю тебя в команду девелопером с правами коммита.
Nov 29, 2013 at 2:34 PM
SeNS wrote:
Gremlin2 wrote:
У меня наконец то появилось немного времени для этого проекта,
Везет тебе (завидуя "по белому")! А у нас, как обычно, под Xmas вместо деда Мороза приходит дед Лайн :)
Он к нам уже приходил и обещал вернуться :)
Gremlin2 wrote:
C другой стороны, пока еще ни один человек не пожаловался, что добавленные таким путем книжки не читаются , все клеймили в основном на то, что не ищутся ;) Я предлагаю поставить это в виш-лист и on hold, до первых реквестов - дабы не тратить твое время.
Ок
Я наберусь наглости, и попрошу тебя (если, конечно, есть на то желание!) посмотреть в сторону рефакторинга класса Library (это я в стиле project manager-ов называю рефакторингом то, что означает "произвести полный R&D" :D - готовлюсь, понимаешь ;) ). Если без шуток, то хотелось-бы попробовать переписать работу с базой через embeddable SQL server какой-нибудь: MySQL, Микрософтовскую имплементацию или еще какую-нибудь. Главное - чтобы работало на Mono, и на arm-е (в дополнение к стандартному .NET-у и x86/64).
Тут всё сложно :( В качестве ORM можно попытаться использовать BLToolkit (он должен работать и на Mono), а вот что использовать в качестве встраиваемой БД? Да ещё и на arm? Мне сейчас только sqlite-net приходит в голову, но я не знаю на сколько производительным будет такое решение. MySQL отпадает по лицензионным соображениям - MySQL Connector распространяется под GPL, a DevArt dotConnect только для Windows платформы.
Все-таки было-бы любопытно запустить TinyOPDS на моем RPi (хотя я ему сейчас нашел и другое применение
:) Супер!
P.S. Если не возражаешь, я добавлю тебя в команду девелопером с правами коммита.
Буду рад.
Coordinator
Nov 29, 2013 at 4:48 PM
Gremlin2 wrote:
Тут всё сложно :(
Хе-хе, было-бы просто, сделал-бы сам :) Вот что говорят люди на SO: http://stackoverflow.com/questions/684595/embedded-database-for-net
Но, конечно, разобраться с этим - нужно время. Плохо, что у меня мало database/sql experience; у меня с "полпинка" не получится разобраться, что нам подойдет, а что нет.

Идеальным, наверное, была-бы embedded SQL/LINQ compatible СУБД, написанная на том-же CLR - собралось-бы и под arm без проблем. Какой-то особой сверх-производительности нам не нужно; что нам нужно (на мой непросвященный первый взгляд): поддержка таблиц :), поддержка индексов, простейшие select запросы. Нам не нужны ни триггеры, ни stored proc, ни прочие SQL-ные навороты. Т.е. по-хорошему, нужен только самый-самый базис. Главное - избежать хранения всех данных в RAM, и жрущих RAM, "как свинья желуди" LINQ запросов к этим данным.

Теоретически, наверное можно обойтись и без db engine вообще ;) Можно попробовать модифицировать имеющийся код: вместо загрузки всей базы в памяти, создавать индексированные "таблицы" (Dictionaries) в памяти (для авторов, книг и серий) и т.д. (полагаю, что ты понял ход мысли)...
Буду рад.
Отлично, welcome to the team! :)