LibRusLib
Четверг, 28.03.2024, 12:28
Приветствую Вас Гость | RSS
 
Главная ФорумРегистрацияВход
[ Новые сообщения · Участники · Правила форума · Поиск · RSS ]
Архив - только для чтения
Форум » Архив "MultiLib - Библиотекарь" » Бета-тестирование » Бета-тестирование (Бета-тестирование)
Бета-тестирование
burbondДата: Четверг, 31.10.2013, 12:48 | Сообщение # 316
Генерал-майор
Группа: Проверенные
Сообщений: 252
Репутация: 0
Статус: Offline
Цитата drserj ()
А вот ошибка эта.... Была как-то, но не могу понять кто ее генерит, это какая-то внутренняя ошибка, где-то в таблице разрабы накосячили и, похоже, происходит обращение к несозданному элементу. Поскольку это "плавающий" дефект - вычислить его крайне сложно, надо в процессе работы поймать отладчиком, а оно, сцуко, не появляется...

Предлагаю попробовать найти этот глюк следующим образом: поставить на закачку с Флибусты несколько файлов заблокированного автора, к примеру, Звягинцева Василия, Головачёва Василия или Ивановича Юрия. Пока программа будет под нагрузкой, пощелкать  в быстром темпе закладками, в том числе в таблице "Загрузки", открыть в быстром темпе несколько файлов в таблице "Загружено", попробовать быстро удалить поодиночке файлы из таблицы "Загружено с ошибками". Должно получиться yes

Добавлено (31.10.2013, 11:48)
---------------------------------------------
Цитата drserj ()
Дело в том, что я сейчас сижу и думаю, как сделать так, что бы актуализация работала быстрее. Добавил поиск книги в таблице по усеченному МД5 и скорость рухнула на пару порядков... Ибо в конструкции запроса LIKE "%..." индекс не работает

Наверное, не нужно создавать лишние трудности - хватает уже существующих. smile Поскольку есть функционал, позволяющий разместить в архиве библиотеки или внешней папке файлы с полным MD5, то зачем ориентироваться на специфические заморочки другого разработчика. У него путь поиска определяет полный MD5, но с разбивкой попарно по первым шести символам, поэтому усеченный MD5 в поиске и не будет быстро работать - количество проверяемых папок резко увеличивается. Предлагаю зафиксировать поиск по полному MD5 и не мучиться. yes Алгоритм получится простой: выгрузка архива в "формате" MD5 - сканирование и конвертация  MultiLib-ом - Актуализация. Тем более, что фактически это получится одноразовая операция.


Сообщение отредактировал burbond - Четверг, 31.10.2013, 13:22
 
drserjДата: Четверг, 31.10.2013, 13:41 | Сообщение # 317
Генералиссимус
Группа: Администраторы
Сообщений: 4693
Репутация: 30
Статус: Offline
Цитата burbond ()
Наверное, не нужно создавать лишние трудности - хватает уже существующих.


Да, согласен smile Просто хотелось дать возможность не меняя формата контента работать с двумя программами одновременно. Теоретически, я уже сделал рабочий вариант. Можно попробовать, насколько это будет грустно выглядеть. Удалить кусок кода - не проблема, потом его наново писать - сложнее smile


drSerj
 
drserjДата: Четверг, 31.10.2013, 13:43 | Сообщение # 318
Генералиссимус
Группа: Администраторы
Сообщений: 4693
Репутация: 30
Статус: Offline
Я вот еще что думаю... Добавлять сразу сотню тысяч книг - прога может и загнуться smile Может сделать, как я делал в либгене, отдельно опцию импорта скачанного, в котором не будет таблиц в которые выводится сотня тыщ записей...
Всё-таки актуализация - это контроль за изменениями контента, а не его импорт, назначение у актуализации несколько иное...


drSerj
 
burbondДата: Четверг, 31.10.2013, 14:20 | Сообщение # 319
Генерал-майор
Группа: Проверенные
Сообщений: 252
Репутация: 0
Статус: Offline
Цитата drserj ()
Да, согласен Просто хотелось дать возможность не меняя формата контента работать с двумя программами одновременно. Теоретически, я уже сделал рабочий вариант. Можно попробовать, насколько это будет грустно выглядеть. Удалить кусок кода - не проблема, потом его наново писать - сложнее

Смысла не вижу, разработчик MyRuLib в последнее время что-то не проявляет интереса к своему детищу, функционал программы работает неустойчиво, постоянные проблемы с закачкой, глюки с сохранением базы. Поэтому в MyRuLib меня интересует только архив, а как библиотека она значение потеряла. Во всяком случае, пока.

Цитата drserj ()
Я вот еще что думаю... Добавлять сразу сотню тысяч книг - прога может и загнуться

Не-е-е-ет... Зачем сразу  сотню тысяч книг wacko Мы медленно-медленно спустимся с горы и обслужим все стадо biggrin

Цитата drserj ()
Может сделать, как я делал в либгене, отдельно опцию импорта скачанного, в котором не будет таблиц в которые выводится сотня тыщ записей...

Возможно, это будет лучший вариант yes А чем плох поиск по полному MD5?


Сообщение отредактировал burbond - Четверг, 31.10.2013, 14:26
 
drserjДата: Четверг, 31.10.2013, 16:24 | Сообщение # 320
Генералиссимус
Группа: Администраторы
Сообщений: 4693
Репутация: 30
Статус: Offline
Цитата burbond ()
Не-е-е-ет... Зачем сразу  сотню тысяч книг Мы медленно-медленно спустимся с горы и обслужим все стадо


Шо, по одному каталогу? smile

Цитата burbond ()
А чем плох поиск по полному MD5?


Да ничем... Наоборот, это был бы идеальный вариант... Но у людей уже есть коллекции, и они не хотят менять имена файлов... Я изначально так и планировал, но ...


drSerj
 
drserjДата: Четверг, 31.10.2013, 18:02 | Сообщение # 321
Генералиссимус
Группа: Администраторы
Сообщений: 4693
Репутация: 30
Статус: Offline
А такой вопрос, а в таблице актуализации сортировка-выборка нужны? А если я отключу? Тогда можно будет хоть миллион записей выводить без особых тормозов, и импортировать большие коллекции...

drSerj
 
burbondДата: Четверг, 31.10.2013, 18:56 | Сообщение # 322
Генерал-майор
Группа: Проверенные
Сообщений: 252
Репутация: 0
Статус: Offline
Цитата drserj ()
Шо, по одному каталогу?

Не-а... smile По жанрам deal

Цитата drserj ()
Да ничем... Наоборот, это был бы идеальный вариант... Но у людей уже есть коллекции, и они не хотят менять имена файлов... Я изначально так и планировал, но ...

Новое всегда с трудом пробивает себе дорогу...  yes Я бы лично не отказался и думаю, что на такой вариант нашлось бы очень много желающих. У меня, к примеру, архивы уже раз пять полностью обновлялись, когда менял электронные библиотеки.

Цитата drserj ()
А такой вопрос, а в таблице актуализации сортировка-выборка нужны? А если я отключу? Тогда можно будет хоть миллион записей выводить без особых тормозов, и импортировать большие коллекции...

Не совсем понял, а что тогда будет в полях таблицы? unsure Только количество найденных новых книг? А что в строке будет указано?


Сообщение отредактировал burbond - Четверг, 31.10.2013, 19:00
 
drserjДата: Четверг, 31.10.2013, 19:24 | Сообщение # 323
Генералиссимус
Группа: Администраторы
Сообщений: 4693
Репутация: 30
Статус: Offline
Цитата burbond ()
Не совсем понял, а что тогда будет в полях таблицы? Только количество найденных новых книг? А что в строке будет указано?


Да нет, я про то, что клик по колонке не будет сортировать smile Т.е. в таблице будет вся инфа, но в заголовке не будет фильтра и клик по заголовку не будет осуществлять сортировку.

Цитата burbond ()
Новое всегда с трудом пробивает себе дорогу...  Я бы лично не отказался и думаю, что на такой вариант нашлось бы очень много желающих. У меня, к примеру, архивы уже раз пять полностью обновлялись, когда менял электронные библиотеки.


Я уже думал, чем спорить со всеми - просто выпустить еще один плаг, который будет работать по тому принципу, который я считаю правильным smile Но сначала надо закончить рабочий минимум...


drSerj
 
1_абрамДата: Четверг, 31.10.2013, 22:06 | Сообщение # 324
Генералиссимус
Группа: Друзья
Сообщений: 1207
Репутация: 0
Статус: Offline
Цитата burbond
Новое всегда с трудом пробивает себе дорогу... Я бы лично не отказался и думаю, что на такой вариант нашлось бы очень много желающих. У меня, к примеру, архивы уже раз пять полностью обновлялись, когда менял электронные библиотеки.

 
 
+1
 
burbondДата: Четверг, 31.10.2013, 22:12 | Сообщение # 325
Генерал-майор
Группа: Проверенные
Сообщений: 252
Репутация: 0
Статус: Offline
Цитата drserj ()
Да нет, я про то, что клик по колонке не будет сортировать Т.е. в таблице будет вся инфа, но в заголовке не будет фильтра и клик по заголовку не будет осуществлять сортировку.

По- моему, очень удачная мысль. yes Особенно в плане увеличения скорости обработки.

Цитата drserj ()
Я уже думал, чем спорить со всеми - просто выпустить еще один плаг, который будет работать по тому принципу, который я считаю правильным

Я буду первый в очереди на испытания!!! respect

Добавлено (31.10.2013, 21:12)
---------------------------------------------

Цитата 1_абрам ()
+1

bye
 
1_абрамДата: Четверг, 31.10.2013, 22:14 | Сообщение # 326
Генералиссимус
Группа: Друзья
Сообщений: 1207
Репутация: 0
Статус: Offline
Кстати, 
 
http://www.the-ebook.org/forum....17e3daf
 
 
 
на нетоповом ПК пятилетней давность скорость сканирования фб2 в зипах свободно достигала 100-120 файлов в секунду, при загрузке процессора в 2-3 процента (т.е. все упиралось в дисковую систему). Если перемещать много фб2 в один зип (много - порядка тысячи фб2 в зипе), то скорость возрастала на порядок, про ссд вообще молчу... (речь про встроенный в AlReader2 библиотекарь).
 
Т.е.  архивы - тысячники  оптимальны.  
 
drserjДата: Четверг, 31.10.2013, 22:22 | Сообщение # 327
Генералиссимус
Группа: Администраторы
Сообщений: 4693
Репутация: 30
Статус: Offline
Цитата burbond ()
Особенно в плане увеличения скорости обработки.

Скорее в плане увеличения скорости отображения и уменьшении торможения...

Цитата 1_абрам ()
Т.е.  архивы - тысячники  оптимальны.
  
Оптимальны - единичные файлы с мд5 в имени упакованные 7z (накрайняк, zip у которого компрессия меньше). Структуру можно частично позаимствовать у МайРуЛиба, несколько модифицированную, и с полным именем и расширением. 
Архив-тысячник удобен на локальной машине, но при хранении на сервере и доступе по сети - менее удобен. А если делать возможность доступа для других (по фтп, вебу и т д) - единственно правильный - первый вариант.


drSerj
 
drserjДата: Пятница, 01.11.2013, 13:01 | Сообщение # 328
Генералиссимус
Группа: Администраторы
Сообщений: 4693
Репутация: 30
Статус: Offline
Добавил в маску имени %M (%m) - MD5. Т.е. Теперь при копировании на устройство или экспорте можно в качестве имени получать МД5.
Но, возник вопрос.
Предположим, маска у нас %m.
Сейчас формируется имя так:
Имя, сформированное по маске + расширение.
т.е. 09fc9525f51006e97114593cc908ab91.fb2
Если сжимаем - добавляется еще .zip.
В итоге мы получаем, скажем, такое имя: 09fc9525f51006e97114593cc908ab91.fb2.zip

Вопрос в том, нужно ли в архиве указывать реальное расширение (.fb2) перед .zip
Второй вопрос - правильно ли принудительное добавление к имени расширения самого документа, или надо добавить еще один тэг (%E) который пользователь сам добавит в маску? Тогда без тэга %E имена будут соответственно 09fc9525f51006e97114593cc908ab91 и 09fc9525f51006e97114593cc908ab91.zip

Сейчас расширение формируется следующим образом:
Если у исходного файла в репозитории (коллекции) имеется расширение самого документа (скажем .fb2) то оно и берется, если расширения у исходного файла нет - оно берется из поля таблицы "Тип".

Сразу скажу, в упакованном файле .zip будет в любом случае, ибо тогда невозможно будет определить что собой представляет файл 09fc9525f51006e97114593cc908ab91 - просто файл или архив.


drSerj
 
1_абрамДата: Пятница, 01.11.2013, 13:58 | Сообщение # 329
Генералиссимус
Группа: Друзья
Сообщений: 1207
Репутация: 0
Статус: Offline
Цитата drserj
Вопрос в том, нужно ли в архиве указывать реальное расширение (.fb2) перед .zip


 
 
 
Не могу придумать зачем оно может понадобится.
 
drserjДата: Пятница, 01.11.2013, 14:04 | Сообщение # 330
Генералиссимус
Группа: Администраторы
Сообщений: 4693
Репутация: 30
Статус: Offline
Цитата 1_абрам ()
Не могу придумать зачем оно может понадобится.


Хотя бы для того, что бы определить, какой документ в архиве не раскрывая его... Если заметил - у библиотек именно так и сделано...

Т.е. лучше добавть тэг %E и автоматом не формировать?


drSerj
 
Форум » Архив "MultiLib - Библиотекарь" » Бета-тестирование » Бета-тестирование (Бета-тестирование)
Поиск:

Copyright LibRusLib © 2024