|
Notes |
|
|
|
Судя по всему вы не выбрали тип файлов в исходном хранилище, точнее неправильно введено расширение.
|
|
|
|
(0010099)
|
|
Papazol
|
01-12-2012 08:00
(edited on: 01-12-2012 08:14) |
|
Ну вроде как правильно выбрал расширение.
Однако решил проверить, что у меня в кэше. И оказалось, что в папках с z9 по z14 имеются файлы *.png. Откуда они взялись - вопрос не суть, но. Получается, что если в кэш затесался хотя бы один "не такой" файл, процесс может прерваться на самом интересном месте? Хорошо, у меня сразу попался *.png, ничего не успело начаться даже. И где искать этот "не такой"?
Нельзя просто игнорировать файлы с несовпадающим расширением?
Добавлено
Удалил указанные папки с мусором. Так всё равно то же самое происходит. Указал вообще одну маленькую папку, там точно только *.jpg, не работает.
|
|
|
|
|
|
Нет. Оно свалилось еще до начала любых операций после того как не нашло такого зарегистрированного в программе расширения. А файлы с другим расширением оно просто не заметило бы. Все вопросы по этому конвертеру к Zed. |
|
|
|
(0010101)
|
|
Papazol
|
01-12-2012 08:17
(edited on: 01-12-2012 09:38) |
|
Да, вопросы к zed. Надо, понимаешь, срочно конвертнуть, а тут вон чаго.
Самое интересное - релиз от 10 октября работает нормально с тем же кэшем.
|
|
|
|
|
Дружище, это сработала проверка на _входе_ в файловое хранилище что не определился первичный тип файла (contenttype).
Ни до какого конкретного тайла (файла), ни тем более до его чтения, ни уж тем более до СУБД дело даже не дошло.
Так что вполне очевидно, что чистка "мусора" ничего не дала.
Попробуй jpeg указать а не jpg. |
|
|
|
(0010103)
|
|
Papazol
|
01-12-2012 11:34
(edited on: 01-12-2012 11:37) |
|
Во-первых, jpeg - это неправильно, если речь о расширении файлов, а поле названо именно так. И если действительно нужно там писАть jpeg, то это ваще круто! Во-вторых, я уже сконвертировал этот кэш с помощью релиза, всё прошло OK. Все параметры, устанавливаемые в окошке, абсолютно такие же, в том числе и jpg.
Вообще-то надо бы подробно описать весь процесс, а то я, например, конвертировал всего два раза, и в обоих случаях были какие-то проблемы.
Кстати, jpeg не помогает, и даже png, не имеющий разночтений, всё равно не конвертируется.
Да, а что, разве у всех остальных в последней ночнушке это нормально работает?
|
|
|
|
|
>Да, а что, разве у всех остальных в последней ночнушке это нормально работает?
Не знаю. Просто, вероятно, им никто больше не пользуется. Я этого окошка даже не видел ни разу в живую. Только разок в дизайнере открывал. |
|
|
|
(0010106)
|
|
Fetser
|
|
01-12-2012 12:27
|
|
>Просто, вероятно, им никто больше не пользуется.
Пользуюсь регулярно, но конечно не каждый день. Последний раз конвертил 13 ноября и тогда всё сработало без вопросов. Точно какая версия программы была трудно проверить но обычно стоит ночнушка, ну максимум двух дневной давности. Сейчас проверил релиз работает, ночнушка за 19 ноября уже не работает как и все последующие. Более ранних версий увы не сохранилось. |
|
|
|
(0010107)
|
|
zed
|
|
01-12-2012 13:45
|
|
vdemidov
>Все вопросы по этому конвертеру к Zed
Вот только не нужно переводить стрелки. Да, этот конвертер делал я, но затем, ты провёл там типа рефакторинг и сломал его. Причём, очевидно, что после рефакторинга ты даже и не пробовал запускать этот конвертер, потому что валится он стабильно и БД тут совершенно ни при чём.
Баг исправил, но ночнушку придётся долго ждать, у меня пока что сильно ограничен доступ к интернету.
P.S. А раширение можно указывать в различных вариантах: "*.jpg" или ".jpg" или просто "jpg" |
|
|
|
|
>Причём, очевидно, что после рефакторинга ты даже и не пробовал запускать этот конвертер
Конечно не пробовал. Точно так же я не проверяю еще сотню других разных функций. Я уже писал, что я вообще ни разу не запускал ибо он мне не нужен. С моей точки зрения не самый необходимый функционал. А проверяю я самый базовый. Я бы на твоем месте вообще задал расширение не полем ввода, а комбобоксом, все равно оно непредусмотренные расширения не воспримет. А еще я бы сделал выбор исходного и результирующего хранилищ двумя вариантами, или из списка zmp и тогда дополнительно ничего больше выбирать не нужно, или постороннее хранилище и тогда нужно задавать кучу параметров. Но еще раз повторяю, что мне этот функционал не нужен и переделывать я его не собираюсь. |
|
|
|
|
>у всех остальных в последней ночнушке это нормально работает?
Я в БД копировал кэш не через конвертер, а через "операции-скопировать", с указанием версии. После реализации копирования в БД оно работает. EXE-ха есть в доработке про СУБД.
>я бы сделал выбор исходного и результирующего хранилищ двумя вариантами
Вообще говоря да. И "операции-скопировать" в принципе тоже. Вводить руками то что уже и так есть в zmp - потенциально багоопасно. |
|
|
|
|
|
Есть ли вообще смысл иметь данную процедуру в двух местах одновременно? Может, оставить одно что-то, скорей всего в копировании как в более общем варианте? |
|
|
|
|
>смысл иметь данную процедуру в двух местах одновременно?
Это разные процедуры.
См. 5 параграф описания хотелки 1709. |
|
|
|
|
Хотелка 1709 чуть о другом, причём так сходу понять, о чём именно, весьма трудно. В отношении данного вопроса я понял, что различия упомянутых процедур в том, что одна из них обрабатывает весь кэш, а другая - только выделенную область. Выделенной областью может быть в том числе и весь кэш, поэтому процедура копирования может полностью охватить все случаи. Это может быть неудобно из-за необходимости выделять "весь мир", но работать-то это будет. Можно даже внести в интерфейс опцию "Выделить всё", и тогда вообще без проблем.
Так понял я, а как на самом деле? |
|
|
|
(0010116)
|
|
Fetser
|
|
02-12-2012 10:36
|
|
|
Я так понимаю, что разница в том что изначально пытается программа конвертить. В случае копирования программа ищет все файлы в области и если их нет то тратит время на проверку и поиск тайлов которых нет в кэше. А менеджере кэша она не проверяет отсутствующие тайлы, а конвертит те что есть в кэше, без проверки отсутствующих. |
|
|
|
|
>но работать-то это будет
Как быстрее скопировать папку z18, в проводнике руками, или выделив весь сир и копируя выделенную область? Понятно почему?
Так вот менеджер кэша по идее копирует как проводник СОДЕРЖИМОЕ, а не перечисляя все тайлы. |
|
|
|
|
Ладно, согласен оставить оба варианта:)
Но проверять работоспособность придётся у обоих. Кстати, подумалось: а есть смысл конвертировать выделенную область в БД? Как применять это?
Это оффтоп, пока новую ночнушку ждём. |
|
|
|
|
>а есть смысл конвертировать выделенную область в БД? Как применять это?
Смысл есть, например перенести на другую машину не весь многогигабайтный кэш, а лишь нужную область.
>Как быстрее скопировать папку z18, в проводнике руками, или выделив весь сир и копируя выделенную область? Понятно почему?
Кстати, если сделать новый итератор для задач перебора лишь существующих тайлов (что применимо к экспорту, копированию, удалению, даже построению карты заполнения), то можно приблизить скорость перебора к скорости менеджера кэша. Итератор при этом должен идти по папкам кэша в ограничивающем прямоугольнике и проверять найденные файлы на попадание в полигон и лишь тогда выдавать их на выход. Для оптимизации можно для каждого Х (и каждого Y/1024) сначала построить внутри список существующих файлов, проверить его на попадание в полигон, и потом выдать в сортированном по Y виде. Тогда вообще "выхлоп" будет аналогичен существующему итератору, только во много раз быстрее. Во всяком случае для дефолтного файлового кэша. Для БД не уверен. |
|
|
|
(0010124)
|
|
DJ VK
|
03-12-2012 16:22
(edited on: 03-12-2012 19:38) |
|
>>Сейчас проверил релиз работает, ночнушка за 19 ноября уже не работает как и все последующие.
Релиз и последующие ночнушки (недели 2 давности может) у меня работают нормально. но системный кэш растет и через некоторое время съедает всю(!) свободную озу. Она не съедается вся, но конкретно занята и все тормозит. Но это не винда глючит, а планета какими-то скрытыми механизмами винду притормаживает. По закрытию планеты ОЗУ вновь восстанавливается, приходится скачав несколько полигонов :-((( перезапускать программу. Работает после этого шустро. Скачивается сразу в Беркли, думаю дело в этом... Может только xp64 такая глючная?
|
|
|
|
|
|
А в чем вопрос то? Растет системный кэш так как идет работа с кучей файлов. А в случае берклидб это далеко немелкие файлы. |
|
SASPlanet.Debug.elf (38,153) 30-11-2012 20:05
sasmem.jpg (237,679) 03-12-2012 16:27