| Anonymous | Login | Signup for a new account | 22-11-24 05:23 UTC | |
| All Projects | SAS.Планета | Домен, сайт, форум, багтрекер | Доработка карты (ZMP) | Переводы и локализации | Прочее |
| My View | View Issues | Change Log | Roadmap | Search |
| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
| 0002106 | SAS.Планета | [All Projects] Баг | public | 21-08-2013 06:46 | 07-02-2014 07:41 | ||||
| Reporter | vdemidov | ||||||||
| Assigned To | zed | ||||||||
| Priority | normal | Severity | minor | Reproducibility | have not tried | ||||
| Status | resolved | Resolution | fixed | ||||||
| Platform | Windows | OS | 7 | OS Version | Enterprise 64 | ||||
| Product Version | 131111 | ||||||||
| Target Version | 140303 | Fixed in Version | 140303 | ||||||
| Summary | 0002106: В процессе закачки видимой области выскакивают ошибки | ||||||||
| Description | При просмотре карты в режиме Кэш+Интернет на экране регулярно выскакивают ошибки декодирования тайлов. На скриншоте ошибка декодирования png, но бывают похожие ошибки декодирования jpg. Тип кэша проверялся родной файловый и неверсионный беркли - никакой разницы. Инет медленный. Комп очень быстрый Intel Core i7-3770 3.40GHz (8 потоков выполнения) Ума не приложу в чем может быть проблема. Просто идей нет. | ||||||||
| Tags | No tags attached. | ||||||||
| Attached Files |  fail.png [^] (25,033 bytes) 21-08-2013 06:46
 SASPlanet.zip [^] (2,854,006 bytes) 21-08-2013 08:01 1.zip [^] (124,259 bytes) 21-08-2013 08:18 SASPlanet.http.fix.zip [^] (2,853,953 bytes) 22-08-2013 11:17 | ||||||||
 Relationships |
 Notes |
|
|
(0012512) zed (manager) 21-08-2013 07:14 |
Скорее всего из интернета приходят битые/недокачанные данные. Может закачка по таймауту отваливается, а САС этого не замечает, но 99,9% дело в качалке. Как конкретно ругается jpeg? |
|
(0012513) zed (manager) 21-08-2013 07:27 |
И можешь попробовать сохранить содержимое AData перед тем как оно бросает исключение чтобы посмотреть что оно там конкретно накачало и пытается открыть. |
|
(0012514) vdemidov (manager) 21-08-2013 07:29 |
> Скорее всего из интернета приходят битые/недокачанные данные. Если бы все было так просто. Если бы сохранялся битый тайл он бы в кэше и оставался, а так при следующей перерисовке карты он отображается уже нормально и без ошибки. >Как конкретно ругается jpeg? Точно не помню, оно случается гораздо реже png, но общий смысл такой же, только ошибка от libjpeg |
|
(0012515) vdemidov (manager) 21-08-2013 07:31 |
> И можешь попробовать сохранить содержимое AData перед тем как оно бросает исключение чтобы посмотреть что оно там конкретно накачало и пытается открыть. Увы не могу. На этом компе делфы нет и ставить нельзя под угрозой репрессий. |
|
(0012516) zed (manager) 21-08-2013 07:31 |
Но в режиме "Только из кэша" такого не наблюдается? |
|
(0012517) vdemidov (manager) 21-08-2013 07:33 |
>Но в режиме "Только из кэша" такого не наблюдается? Нет, не наблюдается, но это не значит, что виновата именно качалка. Может это из-за ошибки при сохранении тайла. |
|
(0012519) zed (manager) 21-08-2013 07:34 |
>На этом компе делфы нет и ставить нельзя под угрозой репрессий. Ну ты попал :) Скомпилить exe с сохранением AData при ошибке? |
|
(0012520) vdemidov (manager) 21-08-2013 07:35 |
Скомпиль, если не сильно сложно. |
|
(0012522) vdemidov (manager) 21-08-2013 07:37 |
>Ну ты попал :) Ага. Причем это касается любого нелицензионного софта. Даже за Daemon Tools, поставившим его погрозили пальчиком и сказали так больше не делать :) |
|
(0012526) zed (manager) 21-08-2013 08:02 |
Будет сохранять проблемные тайлы в %TEMP% c префиксом "SAS" (в файлы вида SASXXXX.tmp) |
|
(0012527) vdemidov (manager) 21-08-2013 08:18 |
Как ни странно это действительно битые png. |
|
(0012528) vdemidov (manager) 21-08-2013 12:24 |
Воспроизвел ошибку на файловом тайлохранилище, а потом нашел файл похожий на тот что сохранился в темпе. В темпе записалось начало правильного тайла, но только половина. Похоже проблема в том, что в одном потоке мы сохраняем файл, причем ОС уже отрапортовала о завершении операции и мы разлочили синхронизатор, а в другом потоке при чтени мы получаем только начало файла, которое успело записаться. Смущает только то, что воспроизводится на БерклиДБ |
|
(0012529) zed (manager) 21-08-2013 12:43 |
>причем ОС уже отрапортовала о завершении операции и мы разлочили синхронизатор Т.е. хочешь сказать, что оно в буфере винды и на диск ещё толком не записалось? Но для читающего потока винда же должна была отдать из буфера без проблем. А в Беркли к тому же, есть ещё и мем-кэш внутри САС, т.е. оно к диску/БД даже и не должно было обращаться (на чтение). |
|
(0012530) vdemidov (manager) 21-08-2013 12:51 |
Я завел этот инцидет, именно потому что не понимаю что происходит. Факт в том, что записало оно полный файл, а прочитало для отображения меньше половины этого файла. Что удивительно это происходит как с файлами так и берклиДБ. Где оно может портится? |
|
(0012531) zed (manager) 21-08-2013 12:57 |
Может сбоит ITileObjCacheBitmap? |
|
(0012532) vdemidov (manager) 21-08-2013 13:21 |
Нее, проблема еще до декодирования. А ITileObjCacheBitmap хранит уже раскодированные битмапки. |
|
(0012533) zed (manager) 21-08-2013 13:48 |
Перед сохранением в кэш ещё может сработать обрезка/ресайз, которая декодирует тайл. Т.е. у тебя может быть ситуация, что оно обломилось один раз с кропом и тайл таки НЕ сохранился в кэш, а потом пришёл следующий поток и успешно докачал и сохранил тайл. Вот и получилось, что и в кэше есть и ошибку ты увидел. |
|
(0012534) vdemidov (manager) 21-08-2013 13:52 |
Это могло бы быть так, но даже на скриншоте ошибка в Гибрид (Wikimapia) взятом из репозитория. А там никакой обрезки и ресайза при сохранении нет. Даже перекодирования из формата в другой формат быть не может, потому что ожидается только png (или текст, который считается эквивалентным png) |
|
(0012535) vasketsov (manager) 21-08-2013 13:56 |
>прочитало для отображения меньше половины этого файла >а потом пришёл следующий поток и успешно докачал и сохранил тайл Если запустить Filemon - это всё видно будет размеры буферов и порядок вызовов. |
|
(0012538) vdemidov (manager) 22-08-2013 06:42 |
Запустил ProcessMonitor. Все стало очень интересно. Сначала прилетает SetEndOfFileInformationFile EndOfFile: 5 440 Потом пара чтений Потом опять SetEndOfFileInformationFile EndOfFile: 8 416 Похоже дело таки в качалке тайлов. Судя по всему дело в том, что в процессе закачки запросы на закачку тайла ставятся в очередь и отменяются. Но отмененный запрос, частично закачанный, почему-то сохраняется в базу, но потом сразу перетирается неотмененным запросом, но на быстром компе отображалка успевает подхватить тот битый тайл. |
|
(0012539) vasketsov (manager) 22-08-2013 08:24 |
А sacs тоже affected? Я там переделывал сохранение тайла на диск для файловых хранилищ, чтобы в рамках одного открытия файла по хэндлу всё делать, а не через установку размера Stream. |
|
(0012540) zed (manager) 22-08-2013 08:27 |
А Беркли это значит каснулось из-за мем-кэша. В тайловый кэш по-моему так никто мем-кэш и не прикрутил? |
|
(0012541) zed (manager) 22-08-2013 08:29 |
>а не через установку размера Stream А какая разница, если прилетает 2 отдельных запроса на запись? |
|
(0012542) vdemidov (manager) 22-08-2013 08:29 |
>А sacs тоже affected? Не проверял, но подозреваю, что да. > Я там переделывал сохранение тайла на диск для файловых хранилищ, чтобы в рамках одного открытия файла по хэндлу всё делать, а не через установку размера Stream. Там ошибка на уровень выше. То есть, записали битый тайл, а потом переписали полным. Так что воспроизведется на всех типах тайлохранилищ. |
|
(0012543) vdemidov (manager) 22-08-2013 08:30 |
> А Беркли это значит каснулось из-за мем-кэша. В тайловый кэш по-моему так никто мем-кэш и не прикрутил? Без разницы, что с мем-кэшом, что без. Проходят две операции записи в тайлохранилище. А между ними успевает пройти чтение. |
|
(0012544) vasketsov (manager) 22-08-2013 08:35 edited on: 22-08-2013 08:36 |
>Проходят две операции записи в тайлохранилище >если прилетает 2 отдельных запроса на запись? Это ты как понял? По ProcessMonitor-у? ))) |
|
(0012546) vdemidov (manager) 22-08-2013 08:46 |
>Это ты как понял? По ProcessMonitor-у? ))) Ага. Плюс знание, что сейчас там есть блокировка на каждом тайлохранилище. Все операции сериализовались вполне нормально. Так что проблема в качалке. |
|
(0012550) vasketsov (manager) 22-08-2013 10:14 |
Но ты всё же проверь sacs. >проблема в качалке И в чём же она заключается-то в качалке? >сразу перетирается неотмененным запросом В том, что на один тайл непрокачанного экрана может быть 2 запроса на скачку? Так я об этом сто лет назад ещё писал. >Но отмененный запрос Почему запрос отменяется? |
|
(0012551) vdemidov (manager) 22-08-2013 10:37 |
>Но ты всё же проверь sacs. Проверю >>проблема в качалке >И в чём же она заключается-то в качалке? В том, что качалка сохраняет полученные данные, даже если запрос на закачку отменен в процессе обработки, или в том, что оно прерывает запрос, который начал обрабатываться, после сдвига карты. >Почему запрос отменяется? Потому что карту подвинули и нас в первую очередь интересуют уже другие тайлы, чем интересовали раньше. |
|
(0012552) vdemidov (manager) 22-08-2013 10:40 |
>Но ты всё же проверь sacs. Проверил. Все ровно то же самое, что и не удивительно. |
|
(0012553) vasketsov (manager) 22-08-2013 10:45 edited on: 22-08-2013 10:47 |
>сохраняет полученные данные, даже если запрос на закачку отменен Результат (HTTP code) запроса какой будет (должен быть), если он отменён? 200 OK? А какую-нибудь мегастарую версию пробовал запускать? |
|
(0012554) vdemidov (manager) 22-08-2013 10:48 |
>Результат (HTTP code) запроса какой будет (должен быть), если он отменён? 200 OK? ХЗ. Я это в свое время делал для прямого использования WinInet. Потом Zed переделал на TALWinInetHTTPClient. Как оно сейчас работает, для меня почти загадка :) |
|
(0012555) zed (manager) 22-08-2013 10:56 |
При отмене запроса вызывается disconnect, и если у нас не возникает никакого исключения (не уверен, что alcinoe бросает в этом случае что-то) идёт вызов OnAfterResponse, в котором как раз и нету никакой проверки на то, что запрос отменён. |
|
(0012556) zed (manager) 22-08-2013 10:59 |
А Http code там будет 200, потому как вначале прилитают заголовки со статусом, а только потом тело. И если тело пришло не до конца, заголовки-то уже никто не будет исправлять. Конечно, если был разрыв связи на сокете, то мы словим исключение и уже не будем анализировать то что там успело накачаться. |
|
(0012557) vdemidov (manager) 22-08-2013 11:00 |
Ну вот похоже туда и нужно добавить проверку. |
|
(0012558) vdemidov (manager) 22-08-2013 11:15 edited on: 22-08-2013 11:15 |
Zed можешь перед строчками if Result = nil then begin Result := OnAfterResponse( ARequest, FResultFactory ); end; добавить проверку if ACancelNotifier.IsOperationCanceled(AOperationID) then begin Result := FResultFactory.BuildCanceled(ARequest); end; и выложить где-то скомпиленную с этой проверкой версию? |
|
(0012559) zed (manager) 22-08-2013 11:18 |
Сделал так: if (Result = nil) and (not ACancelNotifier.IsOperationCanceled(AOperationID)) and (FDisconnectByServer = 0) and (FDisconnectByUser = 0) then begin Result := OnAfterResponse( ARequest, FResultFactory ); end else begin Result := FResultFactory.BuildCanceled(ARequest); end; Тестируй. |
|
(0012560) zed (manager) 22-08-2013 11:20 |
Меня там по коду в юните смущает доступ к переменным FDisconnectByServer и FDisconnectByUser без синхронизации. Это vasketsov добавлял, если что :) |
|
(0012561) vdemidov (manager) 22-08-2013 11:33 |
>Меня там по коду в юните смущает доступ к переменным FDisconnectByServer и FDisconnectByUser без синхронизации. Это vasketsov добавлял, если что :) Понятия не имею. Я вообще не понял нафиг оно там нужно. В крайнем случае можно заменить флаг построенный на Interlocked* |
|
(0012562) vdemidov (manager) 22-08-2013 11:37 |
Что-то оно у меня вообще качать перестало |
|
(0012563) vasketsov (manager) 22-08-2013 11:42 |
>без синхронизации ЕМНИП это Byte - а операции с Byte атомарны и без синхронизации >не понял нафиг оно там нужно ну очевидно это флаги отбоя по инициативе сервера или по инициативе пользователя >vasketsov добавлял значит известен тикет или хотя бы комментарии какие, почему такое сделано |
|
(0012564) zed (manager) 22-08-2013 11:49 |
> значит известен тикет Changeset: 5096 (9bbf5ab98d53) 1103: обработка дисконнекта для TALWinInetHTTPClient User: vasketsov Date: 2012-02-25 19:59:58 +0400 (18 months) Конечно, все ходы записаны :) |
|
(0012565) zed (manager) 22-08-2013 11:50 |
>Что-то оно у меня вообще качать перестало У меня качает исправно. |
|
(0012566) vdemidov (manager) 22-08-2013 11:53 |
А у меня ни одного скачанного тайла |
|
(0012567) vasketsov (manager) 22-08-2013 11:59 |
>все ходы записаны У меня даже больше инфы есть: http://sasgis.org/mantis/view.php?id=1103#c5629 это про причину, читать от ссылки и далее. |
|
(0012574) vdemidov (manager) 23-08-2013 06:43 |
Я понял почему ошибки именно на слое гибрида викимапии у меня сыпятся - там сервер не отдает Content-Length в заголовке ответа. А у гугла отдает. |
|
(0012641) vdemidov (manager) 28-08-2013 10:06 |
Почитал код, вспомнил что там происходит. Я ошибся. Отмены начатого запроса на закачку тайла не происходит. Точнее происходит, но только если удаляется качальщик по таймауту или при закрытии программы. Так что судя по всему отлуп получаем на уровне сервера, а так как гибрид викимапии не возвращает Content-Length то и получаем недокачанные тайлы. Или я даже не знаю в чем проблема. Вариантов два: 1. понять кто виноват, и что делать 2. не отправлять одновременно одинаковые запросы. Второй вариант логичнее, но возникает вопрос как его реализовывать. Кратко опишу как сейчас работает закачка тайлов: 1. Есть поток отвечающий за закачку видимой области конкретной карты. После каждого существенного сдвига карты пользователем старые запросы помечаются как отмененные, а в очередь запихивается новая пачка запросов. 2. Есть очередь запросов на закачку тайлов, в которую помещаются объекты-запросы содержащие зум, координаты тайла, версию. Очередь тупая FIFO, но у каждого запроса есть признак отменен ли он. 3. Есть определенное количество обработчиков очереди. Каждый обработчик забирает очередной запрос из очереди и начинает обрабатывать. 4. Если запрос уже отменен, то просто ничего не делаем, идем получать следующий запрос. 5. При помощи паскаль скрипта строим запрос на закачку включая хедеры + возможно в процессе выполняем какие-то HTTP запросы при помощи принадлежащего обработчику HTTP-загрузчику. 6. Если запрос отменен, то увы, выбрасываем построенный запрос и идем за следующей задачей. 7. Выполняем HTTP запрос при помощи все того же принадлежащего обработчику HTTP-загрузчику 8. Если мы выполнили HTTP запрос, то даже если запрос на тайл отменен, все равно сообщаем что скачали тайл и сохраняем его, если ошибки не было. Итого вопрос. Куда и как пихать проверку дублирующихся HTTP запросов или как переделать всю эту кухню, что бы оно работало максимально эффективно. |
|
(0012642) vdemidov (manager) 28-08-2013 10:13 |
Возможно стоит добавить проверку наличия тайла непосредственно перед HTTP-запросом, если стоит режим Кэш+Интернет, или закачка идет в режиме без замены тайлов. Но это никак не поможет от одновременных запросов одного и того же тайла, если один из обработчиков очереди уже начал HTTP запрос, который потом отменили и заменили новым, и другой обработчик начал его выполнять. |
|
(0012643) vasketsov (manager) 28-08-2013 10:43 |
>возникает вопрос как его реализовывать Ну вариантов минимум два: 1. Дополнительный признак невозможности пользовательской отмены запроса. Соответственно подымать этот признак и не отменять запрос, если он уже прошёл какую-то стадию (в смысле http). Но при вырубании приложения вырубаются все. Возможно для чего-то другого тоже потребуется такое поведение (например, для операции, которую прерываем после тяжёлых промежуточных этапов, когда остался один простой лёгкий). Универсально и широкоиспользуемо в технике. 2. Внутренний список xyzv в том месте, одном на одну карту, в котором эти параметры ещё есть (возможно в httpdownloader они уже отсутствуют), там держать актуальный список, добавлять в начале закачки, выкидывать в конце закачки. По месту и тормоза. Это если без сильных извратов. >стоит добавить проверку наличия тайла непосредственно перед HTTP-запросом Этого делать точно не стоит ввиду полной бессмысленности: если есть такой же параллельный поток на скачку, тайл ещё просто не упадёт. Кроме того, какой тайл проверять, если скачанный мегатайл нарезается на кучку стандартных? |
|
(0012644) vdemidov (manager) 28-08-2013 11:00 |
1-й вариант совсем ничего не помогает, ибо оно и так не отменяется, а причин не добавлять новый запрос все так же нет. Точнее оно сейчас именно так и есть, и ты бы этого не писал, если бы внимательно прочитал то, что написал я. 2-й ваниант вызывает вопрос. И что делать если тайл уже есть в списке? >>стоит добавить проверку наличия тайла непосредственно перед HTTP-запросом >Этого делать точно не стоит ввиду полной бессмысленности: если есть такой же параллельный поток на скачку, тайл ещё просто не упадёт. А если он уже упал, пока этот запрос в очереди стоял? Шансы очень даже большие. |
|
(0012656) vasketsov (manager) 28-08-2013 13:37 |
>ибо оно и так не отменяется Отменяется - имел в виду подымается отметка об отмене, а не фактическую отмену. >причин не добавлять новый запрос все так же нет Наличие запроса в очереди - не причина? >оно сейчас именно так и есть Неправда. Сейчас отмена операции 146% взводит признак отмены операции, даже если операция фактически выполнилась. Попробуй подумать снова. >2-й вариант вызывает вопрос. И что делать если тайл уже есть в списке? Очевидно ничего, ибо можно дождаться первичного запроса, и не рожать вторичный. |
|
(0012658) vdemidov (manager) 28-08-2013 13:49 |
>Наличие запроса в очереди - не причина? Я же написал, что очередь тупая, там нет метода проверки есть ли какой-то запрос в очереди или нет. Плюс сейчас отменяется все запросы скопом, если захочется делать поштучную отмену, то придется много чего переделывать. >>оно сейчас именно так и есть >Неправда. Сейчас отмена операции 146% взводит признак отмены операции, даже если операция фактически выполнилась. Попробуй подумать снова. Сам подумай. Если начался http запрос то этот признак дальше уже игнорируется и больше не учитывается. >>2-й вариант вызывает вопрос. И что делать если тайл уже есть в списке? >Очевидно ничего, ибо можно дождаться первичного запроса, и не рожать вторичный. В смысле не рожать вторичный? Проигнорировать вторичный. А рожать нужно. Или вводить методы изменения приоритета для запросов, что бы тайлы в нынешнем центре экрана загружались в первую очередь. |
|
(0012660) vasketsov (manager) 28-08-2013 14:13 |
>Если начался http запрос то этот признак дальше уже игнорируется и больше не учитывается А как же проверка после окончания запроса, которая обсуждалась выше? А кроме того, логично, что если запрос нельзя отменить, то ему нельзя и Disconnect руками сделать. Такое ощущение, что всё разжевать надо... >очередь тупая, там нет метода проверки есть ли какой-то запрос в очереди или нет У тебя же сейчас есть хэши - натяни проверку по хэшу xyzv. >вводить методы изменения приоритета для запросов Ты какую-то ересь несёшь. Ну при чём тут приоритеты, если не прокачаться может ЛЮБОЙ участок экрана? |
|
(0012661) vdemidov (manager) 28-08-2013 14:21 |
Так. Давай для начала ты внимательно посмотришь код, а потом будешь писать предположения как оно работает. > А как же проверка после окончания запроса, которая обсуждалась выше? Я сегодня с этого начал, что эта проверка срабатывает только при закрытии программы. Во всех остальных случаях, если запрос на закачку тайла добрался до Http он будет выполнен и его отмена игнорируется. >>очередь тупая, там нет метода проверки есть ли какой-то запрос в очереди или нет >У тебя же сейчас есть хэши - натяни проверку по хэшу xyzv Для этого придется полностью переделывать очередь. Там сейчас только два метода Push и Pop. >Ну при чём тут приоритеты, если не прокачаться может ЛЮБОЙ участок экрана? Ничего не понял. |
|
(0012662) vasketsov (manager) 28-08-2013 15:01 |
>Ничего не понял Это неудивительно. Попробуй завтра попробовать. Сегодня видимо не твой день. Потому что в здравом уме такое написать нереально: вводить методы изменения приоритета для запросов, что бы тайлы в нынешнем центре экрана загружались в первую очередь >придется полностью переделывать очередь. Там сейчас только два метода Push и Pop Почему Push внутри не может это сам проверять? >Давай для начала ты внимательно посмотришь код Давай. >срабатывает только при закрытии программы То есть TDownloaderHttp.OnCancelEvent (и Disconnect оттуда) при сдвиге карты не сработает? Зачем тогда FCancelListener цепляется к ACancelNotifier? |
|
(0012663) vdemidov (manager) 28-08-2013 15:16 |
>>Ничего не понял >Это неудивительно. Попробуй завтра попробовать. Сегодня видимо не твой день. Попробуй завтра написать другими словами. Сегодня ты несешь бред видимо не твой день. (Ты первый начал) >>срабатывает только при закрытии программы >То есть TDownloaderHttp.OnCancelEvent (и Disconnect оттуда) при сдвиге карты не сработает? Зачем тогда FCancelListener цепляется к ACancelNotifier? Я третий раз пишу, что ACancelNotifier это совсем другой CancelNotifier чем тот что передается при создании запроса тайла, и он срабатывает только при удалении объекта обработчика очереди и при завершении работы программы. |
|
(0012664) vasketsov (manager) 28-08-2013 15:45 |
>первый начал Неправда. Сообщения 12641 и 12642 уже содержат признаки тяжёлого повреждения ЦНС. Я лишь отвечаю на твой бред. Например, для начала поясни, каким образом неотправка одинаковых запросов тебя спасёт? А если это будут одинаковые запросы от двух разных включённых слоёв, работающих по одному тайлохранилищу и по одному картосервису? Или отныне сас будет только строем ходить и в ногу? Я не зря призываю тебя подумать ещё раз. То что ты надумал сейчас - ересь 146%. Поверь, что со стороны виднее. Про приоритеты центра экрана - чистейший диагноз. Такое ощущение, что или ты пьян, или аккаунт взломан, но это не vdemidov. >Я третий раз пишу Лучше ответь просто, "да" или "нет", вызывается Disconnect при сдвиге карты или нет? |
|
(0013753) zed (manager) 06-02-2014 21:35 |
В связи с доработкой 0002307 нужно подтверждение воспроизводимости бага в новом свете. |
|
(0013756) vdemidov (manager) 07-02-2014 07:41 |
Да, починилось. Я все еще считаю что качалку видимой области нужно переделать и избавиться от отдельного треда на каждую карту, но и так гораздо лучше чем было. Спасибо. |
|
Notes |
| Users who viewed this issue |
|
| User List | Anonymous (4721x) |
| Total Views | 4721 |
| Last View | 22-11-2024 05:23 |
| Users who viewed this issue |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 21-08-2013 06:46 | vdemidov | New Issue | |
| 21-08-2013 06:46 | vdemidov | File Added: fail.png | |
| 21-08-2013 06:56 | vdemidov | Status | new => confirmed |
| 21-08-2013 07:14 | zed | Note Added: 0012512 | |
| 21-08-2013 07:27 | zed | Note Added: 0012513 | |
| 21-08-2013 07:29 | vdemidov | Note Added: 0012514 | |
| 21-08-2013 07:31 | vdemidov | Note Added: 0012515 | |
| 21-08-2013 07:31 | zed | Note Added: 0012516 | |
| 21-08-2013 07:33 | vdemidov | Note Added: 0012517 | |
| 21-08-2013 07:34 | zed | Note Added: 0012519 | |
| 21-08-2013 07:35 | vdemidov | Note Added: 0012520 | |
| 21-08-2013 07:37 | vdemidov | Note Added: 0012522 | |
| 21-08-2013 08:01 | zed | File Added: SASPlanet.zip | |
| 21-08-2013 08:02 | zed | Note Added: 0012526 | |
| 21-08-2013 08:18 | vdemidov | File Added: 1.zip | |
| 21-08-2013 08:18 | vdemidov | Note Added: 0012527 | |
| 21-08-2013 12:24 | vdemidov | Note Added: 0012528 | |
| 21-08-2013 12:43 | zed | Note Added: 0012529 | |
| 21-08-2013 12:51 | vdemidov | Note Added: 0012530 | |
| 21-08-2013 12:57 | zed | Note Added: 0012531 | |
| 21-08-2013 13:21 | vdemidov | Note Added: 0012532 | |
| 21-08-2013 13:48 | zed | Note Added: 0012533 | |
| 21-08-2013 13:52 | vdemidov | Note Added: 0012534 | |
| 21-08-2013 13:56 | vasketsov | Note Added: 0012535 | |
| 22-08-2013 06:42 | vdemidov | Note Added: 0012538 | |
| 22-08-2013 08:24 | vasketsov | Note Added: 0012539 | |
| 22-08-2013 08:27 | zed | Note Added: 0012540 | |
| 22-08-2013 08:29 | zed | Note Added: 0012541 | |
| 22-08-2013 08:29 | vdemidov | Note Added: 0012542 | |
| 22-08-2013 08:30 | vdemidov | Note Added: 0012543 | |
| 22-08-2013 08:35 | vasketsov | Note Added: 0012544 | |
| 22-08-2013 08:36 | vasketsov | Note Edited: 0012544 | View Revisions |
| 22-08-2013 08:46 | vdemidov | Note Added: 0012546 | |
| 22-08-2013 10:14 | vasketsov | Note Added: 0012550 | |
| 22-08-2013 10:37 | vdemidov | Note Added: 0012551 | |
| 22-08-2013 10:40 | vdemidov | Note Added: 0012552 | |
| 22-08-2013 10:45 | vasketsov | Note Added: 0012553 | |
| 22-08-2013 10:47 | vasketsov | Note Edited: 0012553 | View Revisions |
| 22-08-2013 10:48 | vdemidov | Note Added: 0012554 | |
| 22-08-2013 10:56 | zed | Note Added: 0012555 | |
| 22-08-2013 10:59 | zed | Note Added: 0012556 | |
| 22-08-2013 11:00 | vdemidov | Note Added: 0012557 | |
| 22-08-2013 11:15 | vdemidov | Note Added: 0012558 | |
| 22-08-2013 11:15 | vdemidov | Note Edited: 0012558 | View Revisions |
| 22-08-2013 11:17 | zed | File Added: SASPlanet.http.fix.zip | |
| 22-08-2013 11:18 | zed | Note Added: 0012559 | |
| 22-08-2013 11:20 | zed | Note Added: 0012560 | |
| 22-08-2013 11:33 | vdemidov | Note Added: 0012561 | |
| 22-08-2013 11:37 | vdemidov | Note Added: 0012562 | |
| 22-08-2013 11:42 | vasketsov | Note Added: 0012563 | |
| 22-08-2013 11:49 | zed | Note Added: 0012564 | |
| 22-08-2013 11:50 | zed | Note Added: 0012565 | |
| 22-08-2013 11:53 | vdemidov | Note Added: 0012566 | |
| 22-08-2013 11:59 | vasketsov | Note Added: 0012567 | |
| 23-08-2013 06:43 | vdemidov | Note Added: 0012574 | |
| 28-08-2013 10:06 | vdemidov | Note Added: 0012641 | |
| 28-08-2013 10:13 | vdemidov | Note Added: 0012642 | |
| 28-08-2013 10:43 | vasketsov | Note Added: 0012643 | |
| 28-08-2013 11:00 | vdemidov | Note Added: 0012644 | |
| 28-08-2013 13:37 | vasketsov | Note Added: 0012656 | |
| 28-08-2013 13:49 | vdemidov | Note Added: 0012658 | |
| 28-08-2013 14:13 | vasketsov | Note Added: 0012660 | |
| 28-08-2013 14:21 | vdemidov | Note Added: 0012661 | |
| 28-08-2013 15:01 | vasketsov | Note Added: 0012662 | |
| 28-08-2013 15:16 | vdemidov | Note Added: 0012663 | |
| 28-08-2013 15:45 | vasketsov | Note Added: 0012664 | |
| 22-11-2013 22:25 | vdemidov | Product Version | .Nightly => 131111 |
| 07-01-2014 14:15 | zed | Relationship added | related to 0002307 |
| 06-02-2014 21:35 | zed | Note Added: 0013753 | |
| 06-02-2014 21:36 | zed | Status | confirmed => feedback |
| 07-02-2014 07:41 | vdemidov | Note Added: 0013756 | |
| 07-02-2014 07:41 | vdemidov | Status | feedback => new |
| 07-02-2014 07:41 | vdemidov | Status | new => resolved |
| 07-02-2014 07:41 | vdemidov | Resolution | open => fixed |
| 07-02-2014 07:41 | vdemidov | Assigned To | => zed |
| 07-02-2014 07:41 | vdemidov | Fixed in Version | => 140303 |
| 07-02-2014 07:41 | vdemidov | Target Version | 24xxxx => 140303 |
|
Issue History |
| My View | View Issues | Change Log | Roadmap | Search |
| Copyright © 2007 - 2024 SAS.Planet Team |