StockSubmitter - программа для автосабмита изображений - Страница 163

sbw · 22.02.2012, 10:31

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

Спасибо

niak_ris · 22.02.2012, 10:41

Цитата:

Сообщение от sbw

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

Спасибо

А если посмотреть на статусы файлов по дримстайму, то видно ли какие файлы не загрузились? По идее, если файл не дошёл на 100% статус должен быть Готово к загрузке, а не Загружено(это легко посмотреть с помощью нового фильтра из прошлого поста)

К тому же в ближайшее время мы сделаем "Историю Загрузок" всех файлов заливаемых сабмиттером.

sbw · 22.02.2012, 11:20

Файл считается загруженным, но не засабмиченным. Поэтому приходится его перезагружать, изменив статус для дримса на "готов к загрузке". Я так понимаю, что факт недохода до дримса файла узнать негде? Они как-то пропадают, и все, с концами.

Еще хотел высказать предложение, а почему бы не хранить базу по файлам отдельно, чтобы не читать каждый раз из каждого файла все атрибуты и ключевые (программа при старте на сотне файлов в каталоге подвисает примерно на пару минут на проце п4-3ггц, 2 гб озу, пока этот каталог считывает) - как это сделано в дипмете, но догадываюсь, что были весомые соображения, о которых я не знаю, а длительная загрузка - не самая большая проблема, вероятно.

А "история загрузок" будет полезной (для каждого файла для каждого стока), да!

niak_ris · 22.02.2012, 11:59

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

Метаданные файлов довольно тяжелая штука(вкупе с весом самих файлов), поэтому для работы с такими файлами нужен быстрый компьютер. Желательно многоядерный с большим количеством оперативной памяти. Я тестирую приложение на 3000 векторных файлах (eps+jpg со средним весом в 10 мб). Скорость обработки около 10 секунд. Мы очень много времени и сил уделили оптимизации скорости работы с данными и на сегодняшний момент практически уперлись в максимум производительности.

Следует знать, что работа с файлами через wifi, внейшний USB диск или с Касперским(или другим АВ, который проверяет ВСЕ ОПЕРАЦИИ с каждым файлом) может серьёзно уменьшить скорость чтения и записи метаданных.

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

sbw · 22.02.2012, 12:34

Цитата:

Сообщение от niak_ris

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

Ну, по-идее, при переносе файла и потере его базой можно было бы его потом "найти" (указать размещение), как в лайтруме, сверить контрольную сумму. То есть, разделить импорт и хранение, а не импортировать весь каталог каждый раз при запуске.
Как я понимаю, кроме как для этой программы инфа внутри файла (сведения о загрузке на другие стоки и категории раздельно) никому больше не нужны?

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

Цитата:

Сообщение от niak_ris

sbw:
Метаданные файлов довольно тяжелая штука(вкупе с весом самих файлов), поэтому для работы с такими файлами нужен быстрый компьютер. Желательно многоядерный с большим количеством оперативной памяти. Я тестирую приложение на 3000 векторных файлах (eps+jpg со средним весом в 10 мб). Скорость обработки около 10 секунд. Мы очень много времени и сил уделили оптимизации скорости работы с данными и на сегодняшний момент практически уперлись в максимум производительности.

Что тяжелая - это понятно, но откуда бы такая разница в скорости? Релоад каталога - около минуты для пентиум 4 D - 3Ghz, 2Gb ram, 160gb SATA samsung, i945 чипсет.

В момент релоада 100 файлов exiftool.exe грузит проц на 50% на 50 секунд, после этого сам стоксабмиттер грузит проц на 95% на 15 секунд.

Цитата:

Сообщение от niak_ris

sbw:
Следует знать, что работа с файлами через wifi, внейшний USB диск или с Касперским(или другим АВ, который проверяет ВСЕ ОПЕРАЦИИ с каждым файлом) может серьёзно уменьшить скорость чтения и записи метаданных.

Нет, ничего такого подобного нет, файлы на том же винте и разделе, что и операционка. Антивируса тоже нет. Не в 32 битности ХР же дело?

И еще одна небольшая просьба: в разделе "релизы" можно исправить так, чтобы сохранялось взаимное расположение и размеры столбцов таблицы? У меня длинные названия у релизов, приходится все время увеличивать ширину первого столбца, а оно не запоминает, по-умолчанию видно плохо.

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

Вообще, не устану благодарить за эту программу

Узнал про нее сравнительно недавно, она помогает экономить реально кучу времени!

niak_ris · 22.02.2012, 13:56

"Ну, по-идее, при переносе файла и потере его базой можно было ...
... никому больше не нужны?"
Это усложнит работу с программой, а как показывает практика 90% юзеров сабмиттера всеми любимые девушки, которые не очень разбираются в ПО и понятие "база данных" их немного смущает. За историю сабмиттера есть очень много полезных функций, котоырми пользуются 2% пользователей. Вот подключение БД примерно тоже самое, к тому же реализовать это равносильно сделать ядро программы заново...
пентиум 4 D - 3Ghz, 2Gb ram, 160gb SATA samsung, i945 чипсет. Это довольно старый компьютер. Среднестатиситические стокеры обладают гораздо более мощным компьютером (фотошоп, иллюстратор, видеоредакторы, 3д и т. п.) Поэтому мы максимально увеличиваем производительность засчёт ресурсов компьютера, а в вашем случае их просто очень мало. Я тестирую программу на netbook с intel Atom 1.6 1024x600. Так вот даже на этом "компьютере" она может выполнять свои функции хоть это и не очень быстро. Сделать программу менее требовательной к железу это по сути замедлить её работу в несколько раз, что неприемлемо!

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

По поводу цвета иконок я соглашусь, нужно подобрать более различные цвета.
Релизы поправим так как вы сказали. Ждём ещё предложений

sbw · 22.02.2012, 14:21

А какие ресурсы нужны программе для "полета", то есть, что там критично? скорость винта? проца? размер озу? операционка? Что именно жрет ресурс?
Я так думал, что суть импорта данных в том, что "открыть файл - считать поле - запомнить в переменную", вроде бы не сжатое оно там? Или еще идет какой-то сложный анализ? Превью картинки берется из экзифа, или джипег распаковывается целиком?

"Сделать программу менее требовательной к железу это по сути замедлить её работу в несколько раз, что неприемлемо!" - а что именно из "железных" возможностей используется?

"Вот у меня например 12 сайтов сейчас используется, до конца месяца я планирую добавить ещё 4. итого 16."
Ну вот если бы оно столбиком выстраивалось, к примеру? Столбик постоянной высоты, а размер его ячеек зависит от количества подписных стоков. Наводишь на него мышкой (не нажимаешь) - появляется help в виде статуса по стокам.

Спасибо, я подумаю

Были мысли в определенные моменты, когда натыкался на что-то неожиданное, или в самом начале работы, но щас уже не вспомню. Смирился и приспособился, наверное

anytka · 22.02.2012, 14:43

Цитата:

Сообщение от niak_ris

"Ждём ещё предложений

1) Проверка орфографии в тайтле, дескрипшене и ключевиках - это было бы мега-круто!!!
2) Сортировка сайтов по желанию пользователя. Например чтобы я, как пользователь, могла рассортировать сама куда мне засылать файлы в первую очередь, а куда можно попозже. Соответственно те стоки, что интересуют в первую очередь могли бы быть сверху.
3) В релизах поменять местами имена-фамилии, поскольку в алфавитном порядке все равно сортируется всё по фамилиям, которые стоят на втором месте.

sbw · 22.02.2012, 15:13

Цитата:

Сообщение от anytka

3) В релизах поменять местами имена-фамилии, поскольку в алфавитном порядке все равно сортируется всё по фамилиям, которые стоят на втором месте.

Я релизы ввожу так: в одно поле ("имя") - имя-фамилию, в другое поле ("фамилия") - дату и сюжет съемки, чтобы искать было проще. Таким образом у меня получается сортировка по дате, но она стоит не первым словом, а первым получается имя (и по нему нельзя отсортировать)

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

Хотя, разнообразие релизов на одного и того же человека от айса идет, который требует релиз на каждую съемку. Другие стоки, вроде бы, не требуют, может и не стоит так заморачиваться и плодить лишние релизы? Типа, на все съемки на одного человека - один релиз, на все годы

anytka · 22.02.2012, 15:28

Цитата:

Сообщение от sbw

Хотя, разнообразие релизов на одного и того же человека от айса идет, который требует релиз на каждую съемку. Другие стоки, вроде бы, не требуют, может и не стоит так заморачиваться и плодить лишние релизы? Типа, на все съемки на одного человека - один релиз, на все годы

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