View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002106SAS.Планета[All Projects] Багpublic21-08-2013 06:4607-02-2014 07:41
Reportervdemidov 
Assigned Tozed 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformWindowsOS7OS VersionEnterprise 64
Product Version131111 
Target Version140303Fixed in Version140303 
Summary0002106: В процессе закачки видимой области выскакивают ошибки
DescriptionПри просмотре карты в режиме Кэш+Интернет на экране регулярно выскакивают ошибки декодирования тайлов.
На скриншоте ошибка декодирования png, но бывают похожие ошибки декодирования jpg.
Тип кэша проверялся родной файловый и неверсионный беркли - никакой разницы.
Инет медленный.
Комп очень быстрый Intel Core i7-3770 3.40GHz (8 потоков выполнения)

Ума не приложу в чем может быть проблема. Просто идей нет.
TagsNo tags attached.
Attached Filespng file icon fail.png [^] (25,033 bytes) 21-08-2013 06:46


zip file icon SASPlanet.zip [^] (2,854,006 bytes) 21-08-2013 08:01
zip file icon 1.zip [^] (124,259 bytes) 21-08-2013 08:18
zip file icon SASPlanet.http.fix.zip [^] (2,853,953 bytes) 22-08-2013 11:17

- Relationships
related to 0002307resolvedzed В процессе закачки видимой области "моргают" тайлы 

-  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

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

- Users who viewed this issue
User List Anonymous (3682x)
Total Views 3682
Last View 30-05-2020 15:35

- 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 22xxxx => 140303



Copyright © 2007 - 2020 SAS.Planet Team