Форум » Прочие темы » Traders Tool: Catalogs Comparer » Ответить

Traders Tool: Catalogs Comparer

Wild User: Программа для сравнения музыкальных каталогов в формате XLS. Позволяет искать дубликаты в пределах одного / двух разных файлах или отсутствующие в одном и имеющиеся в другом альбомы. По сути, облегчает составление вишлиста и поиск дубликатов. Наличие установленного MS Excel не требуется... Скриншот - http://www.wild_user.fatal.ru/TT_Catalogs_Comparer.html Программа - http://www.wild_user.fatal.ru/music_soft/TT_Catalogs_Comparer_2.rar Справка - http://www.wild_user.fatal.ru/music_soft/Comparer_help.rar Просьба высказывать мнения, пожелания, советы и сообщения о багах тут, по e-mail или ICQ 246825708. P.S. УБЕДИТЕЛЬНЕЙШАЯ просьба - при описании найденных ошибок, указывайте по возможности подробно суть ошибки, желательно с примерами, на которых эти ошибки проявляются (приветствуется наличие сравниваемых файлов или их части), какие настройки были выставлены (можно прислать ini-файл программы), а также версию программы и операционной системы.

Ответов - 60, стр: 1 2 3 All

Justin_Rage: Приветствую. Программой пользуюсь - хороша, зараза! Только вопрос тут появился: когда идет процесс сравнения, диспетчер задач Windows'а показывает, что ЦП загружен на 100% - в общем, палевно как-то... А пожелание такое: у многих (в крайнем случае, у меня) есть списки альбомов, кои хотелось бы найти, но не всегда получатся узреть, а вручную все проверять долго и муторно: так может сделать отдельную опцию под сеё дело заточенную?

Wild User: Про 100% -ную загрузку процессора. Нет повода для беспокойства. Это любой цикл так работает. У тебя же система не тормозит? Уверен, что всё работает нормально. Это обеспечивается "волшебным" словом Application.ProcessMessages, с помощью которого даётся возможность системе обрабатывать другие сообщения от программ и пользователя. Про списки "любимых" альбомов. Уже приделывалась такая фича, но было мнение, что таковых альбомов не так уж и много на самом деле эта приблуда лишняя.В принципе, можно и вернуть,тем более, что это отключаемо было. Ещё. При включённом режиме добавления в виш альбомов, которые в чужом каталоге есть с более высоким битрейтом, альбомы подсвечиваются цветом, но это теряется при экспорте в файл. Думаю, что лучше сделать, чтоб созжавался отдельный столбец, в котором будет определённая пометка. По ней уже можно будет в сохранённом файле и отфильтровать. Есть у кого идеи/поправки на эту тему?

Damned: Насчет искомых - это было не только мое мнение? :) Я сейчас кстати склонен вести более обширный список поиска, чем 2-5 альбомов, т.к. легче мне "запоминать" хорошие группы, о которых хорошо отзывались рецензии, или я случайно наткнулся на один альбом, и хотел бы достать остальные. Но все равно, я не обламываюсь "вглазную" просмотреть эти случаи. Т.к. их все же не так много, как всего альбомов. Так что если ты эту приблуду не сделал только из-за этого мнения - то это зря :))


Wild User: Тоды верну. Тем более будет отключаться, кому не надо...

Bete_Noire: >>Это обеспечивается "волшебным" словом Application.ProcessMessages а почему бы не сделать отдельнй thread. Не было бы необходимости прибегать к "волшебному" слову, можно было бы легко регулировать приоритет процесса и ставить его на паузу

Wild User: Я ышшо маленький и неразумный - с потоками работать не умею. Но обязательно научусь, позже... :)

UberWolf: Поскорей бы версия новая..:)

Bete_Noire: 2Wild User мне приходилось их использовать не раз, если что, в профиле есть мое мыло...

vhl: Ужасный хостинг! С него ничего не качается :( а насчет пожелания Justin_Rage - в точку! Очень нужная фича, а то сейчас приходится ставить [1] Artist+Year+Album и искать по этой колонке, что я думаю не есть гут (хотя находит чего-то :)) )

Wild User: Про ужасный хостинг не понял, но если это про мой сервак, то вроде подыскал замену зеркало тут - http://www.wild_user.fatal.ru Пока надо протестить, потом окончательно будет видно...

Wild User: Вернул "поисковый" список. Работает ТОЛЬКО в режиме составления "вишлиста". Версия для тестирования выложена тут - http://www.wild_user.fatal.ru/TT_Catalogs_Comparer_2.rar Также добавлена отдельная возможность просмотреть Slave-файл на наличие исполнителей из поискового списка. Ну и так, по-мелочи...

kuliba: Документ не найден (404 Not Found)

UberWolf: Порадовала новая версия. Для некоторого удобства неплохо было бы на Del повесить удаление пунктов из игнор и поискового списков. Также, имхо, при поиске пунктов из поискового списка поиск должен вестись и по колонке album: например, есть у вас десять альбомов некоего исполнителя, а осталось найти один - проще и удобнее будет занести именно название альбома, а не имя исполнителя (в идеале - и исполнителя, и название альбома).

Wild User: 2kuliba Софтину (тестовую версию) временно прибил на сервере для устранения пары глюков. Верну через пару дней. Предыдущая версия - на месте. 2UberWolf Про Del - согласен, будет удобнее. Сделаю. А вот про поиск и по альбомам не совсем согласен. Было мнение, что "любимых" исполнителей не так уж и много и просмотреть их "глазами" труда не составит. Тем более, что это исключит "непопадание" нужного альбома ввиду сильной разности написания в поисковом списке и чужом каталоге. "есть у вас десять альбомов некоего исполнителя, а осталось найти один" В режиме "вишлиста", этот отсутствующий альбом как раз добавится и отметится цветом и в служебной колонке. А вот в режиме "поиска исполнителей из поискового списка" будут выбраны ВСЕ альбомы исполнителей (даже те, что есть). Тогда можно будет посмотреть и их тоже и сравнить названия, битрейт (может есть с более высоким), размер (при одинаковом битрейте), вдруг у тебя альбом не полный, и.т.д.

UberWolf: Да, что-то я не продумал до конца. Кстати, а зачем часы? :)

Wild User: Часы?... Да так, декорация :) А вообще, у меня панель управления скрывается при уходе мыша с неё, а тут время перед глазами... А что, мешаются? :)

UberWolf: Как бы нет, просто уже стал гадать, какая от них польза :)

Wild User: Выложил вроде как... Ссылки в "шапке" подправил, качать по ним. Устранены пара мелких глюков, добавлены несколько "горячих" клавиш и упорядочено переключение компонентов по Tab. Ещё "прикрутил" отключаемое автоопределение номера колонки с битрейтом. Так, для интереса :)

me-laman: неплохо было бы сделать запоминание последнего выбранного каталога (master)? он ведь как правило один, а то заколебало каждый раз искать...

me-laman: И еще... хорошо было бы сделать сохранение выделение цветом при переносе результата в эксель, а то вся прелесть этого новвоведения сразу же теряется..

Wild User: 2me-laman Если у тебя последняя версия, то кроме цвета, в таблице результата есть служебная колонка, последняя, с заголовком "REASON". Она при сохранении не исчезает. Если альбом добавлен по причине более высокого битрейта, там будет пометка - "High Bitrate". Если исполнитель есть в поисковом списке - "Searched", альбомы с неопределённым битрейтом пометятся как - "??? Bitrate". Также возможны их комбинации.

me-laman: Да точтно... соррии... не заметил сразу... а я еще хотел предложить что-то подобное... ты прямо мысли читаешь... :)

Wild User: Очередной закид софтины на сервер... На этот раз без версий. Добавлено - Приём ярлыка эксель файла по драг-дропу (это надо мне, ибо ярлык на мой каталог всегда подрукой) Отображение процента в трее (Удобно, когда программа свёрнута) Несколько улучшено быстродействие при сравнении. (Найдено "слабое" звено :)) Как обычно, найдена и прибита пара глюкофф... и, возможно, добавлено ещё...

Wild User: Закинута v.2.2b Глюкофиксы + Добавлена отключаемая фишка проверки вхождения для исполнителя. Пример: Cathedral Cathedral Serpents Gold CD1 Cathedral Cathedral Serpents Gold [CD 1] (Serpents Treasure) Будут считаться одинаковыми Также часто попадается примерно такое "обрезание" названия- Even Song Of Man's First Disobedience - Expulsion From The Divine Abode Even Song Of Man's First Disobedience Такое различие нечёткое сравнение не "возьмёт", а проверка вхождения даст положительный результат. В принципе это позволит выявлять совпадения и для "довесков" значений, не внесённых в список игнорируемых слов. По-умолчанию проверяется только первое вхождение, но испытание показало, что лучше поставить ещё одну галку для выбора проверки первого вхождения либо вхождения вообще. Например, имеем два альбома и дигипак из этих двух альбомов. Winter Into Darkness Winter Eternal Frost Winter Into Darkness - Eternal Frost Использование только первого вхождения не "поймает" в дубликаты альбом Eternal Frost, в то время как НЕпервое вхождение - "поймает" Т.е. с точки зрения программы все эти три альбома будут одинаковыми... Надеюсь понятно объяснил, если есть какие мнения - высказывайте

Wild User: v2.2.1 Добавлено вышеописанное, немного упорядочены настройки + всякие мелочи...

Syren aureola kaos: Есть небольшой глюк: при сравнении не всегда отсееваются игнор позиции.

Wild User: Спасибо за поднятие топика! Больше ничего не могу сказать, ибо не телепат и не в курсе, что у Вас там в игнор списке находится и из чего оно не отсеивается...

Syren aureola kaos: К примеру ввожу в игнор группы с названием Limp bizkit, linkin park, ну и тому подобные. При сранении каталогов в результатах всёравно появляются эти группы, но не всегда, где-то половину игнор листа он фильтрует.

Wild User: В игнор список слендует вносить не НАЗВАНИЯ ИСПОЛНИТЕЛЕЙ, а ТИПЫ АЛЬБОМОВ, такие как EP, Demo, CD5, Live, Bootleg, Digipak, e.t.c. Нужно немного подробнее осветить подробности сравнения в хэлпе, тут моя недоработка...

DIF': Попробовал сделать сравнение в master файле 10.000 позций в слэйве 18.000 в итоге когда прошло сравнение и нажал на сохранения результата, то через некоторое время произошла ошибка Excel (упс, облом :-) ) в итоге в буфер копернул всё, заметил, что жрет 116 мегов оперативки при таком сранении

Wild User: DIF' пишет: через некоторое время произошла ошибка Excel (упс, облом :-) ) Наверное ты сохранял с сохранением оформления. Такое бывает, пока не знаю как переделать что бы избавиться. Происходит только на некоторых файлах. Рекомендую использовать простое сохранение в Эксель, либо через буфер. Про память - проверю, может утечка где, хотя вроде не замечал такого... P.S. Проверил только что при сравнении двух каталогов 10000 и 12500. Диспетчер показал ~25 mb при сравнении и 19 - после. А ты где смотрел - на вкладке где процессы или где быстродействие?

UberWolf: Тоже есть похожие нарекания. Сравнивал два небольших списка (вишлисты), далее загрузил достаточно большой каталог (2.7мб) - и TT:CC сожрал 118мб памяти.

Wild User: Ещё раз повторю вопрос - где смотрите "сожранную память", на какой вкладке Диспетчера задач? И ещё интересует, в какой момент происходит такое потребление - в момент загрузки каталогов, в процессе сравнения или по-окончании сравнения. Проверяю у себя на двух одинаковых каталогах по 30000 позиций в режиме поиска одинаковых позиций (то есть в результат также попадают 30000 позиций). Итого - в памяти "висят" три таблицы по 30000 позиций (Master, Slave и Результат). Мой диспетчер показал ~65 Mb.

UberWolf: Wild User пишет: Ещё раз повторю вопрос - где смотрите "сожранную память", на какой вкладке Диспетчера задач?Так вроде ясно сказал: "и TT:CC сожрал 118мб памяти" , т.е. на вкладке с процессами. И ещё интересует, в какой момент происходит такое потребление - в момент загрузки каталогов, в процессе сравнения или по-окончании сравнения. Во время загрузки каталогов (а это занимает время - система целерон 1,7 / 256mb ОЗУ) показатель начинает ползти вверх, по окончании загрузки остаётся на достигнутом уровне. И если необходимо, другие подробности: в случае, который я описывал, участвовало два каталога без особых извращений с оформлением; в одном один лист с количеством позиций менее 500, в другом каталоге на одном листе 7000, на втором листе примерно такое же количество.

Wild User: UberWolf пишет: вкладке с процессами Ясно. Просто ещё есть вкладка "Быстродействие" там есть "общее выделение памяти" примерно соответствующее описанному размеру (у меня). В общем, хрен его знает пока... Просмотрел ещё раз, вроде все ресурсы освобождаю после использования... И ещё. Запускаю прогу - в диспетчере показывается 5600 кб. загружаю каталог (~30000 поз) - 24280 кб. Сворачиваю прогу в панель задач (больше ничего не делаю) - 1040 кб. Разворачиваю обратно - 2548 кб и так и стоит, если ничего не делать... Есть какие идеи у кого?

ahv: hint: в таком цикле целесообразнее использовать HandleMessage вместо ProcessMessages, тогда не будет 100%-ной загрузки

Wild User: ahv пишет: hint: в таком цикле целесообразнее использовать HandleMessage Спасибо за хинт - обязательно попробую. но не уверен, что поможет... А можно популярно объяснить, в чём разница то? Судя по хэлпу - одна хрень, прерывающая выполнение программы для обработки Windows-сообщений, только для ProcessMessages не вызывается обработчик OnIdle, если очередь сообщений пуста. Или я не прав?

ahv: ProcessMessages, according to everything I've ever read, cycles the message queue once, processing all messages in it, and resumes execution where it left off. Immediately. This lets you perform all pending repaints and depends on win32's preemptive multitasking (hi Mike!) to let all the other processes get on with their life. If you are crunching numbers but don't want to lose screen updates, this is the way to go. HandleMessages processes just one message from the queue, and does something unexpected when there isn't one. It releases the timeslice. This makes HandleMessages appropriate for use in completely different conditions then ProcessMessages. Imagine that you are implementing an FTP client. You are waiting for command responses, and to make the (non-blocking) socket work, you have to process the messages that trigger OnRead when data comes in. But if there is no such message, you have nothing to do and can (and should)... release the timeslice. The docs seem to say that ProcessMessages is the better bet in all cases, and HandleMessages lets the application go idle and this is bad. It's not; if you have nothing to do except busy-waiting, it's what should happen. Waiting for data to come in on a socket, or waiting for the user to push the "I've read it" button are things that require message processing but not continuous execution - not busy waiting. Should you be running NT and have written your FTP client to call ProcessMessages in the loop that waits for the response to the command you just sent, you may notice that CPU usage goes to 100%. This happens because the program sits in a tight loop and processes every message as it becomes available... but in between messages it will be busy executing the loop and calling ProcessMessages on an empty queue. Calling HandleMessages also processes messages as they become available, but when the queue is empty the program is suspended until its next timeslice comes around - all of 25ms or so later. This should keep CPU usage very near 0%. на практике снижения быстродействия, скорее всего, заметно не будет, но процессор не будет загружен на 100%

Wild User: Цитата - это конечно хорошо, но, повторюсь, я не программист, поэтому и просил объяснить. Желательно с каким-нибудь примером. Провёл простейший эксперимент - прокрутил два одинаковых цикла, с замером времени работы каждого. По времени выполнения (при активном приложении) особой разницы не выявлено - она незначительна. Да, действительно, HandleMessage даёт меньшую загрузку процессора, НО - при свёрнутой в панель задач программе. Загрузка процессора при этом - 0%. При этом цикл "замораживается", пока программа находится свёрнутой и продолжает выполняться, при "развороте". В развёрнутом состоянии загрузка "камня" составляет всё те же 100%. И то, это если в цикле обращаться к компоненту, требующему перерисовки (например, в Edit выводить счётчик цикла). Если не выводить, то и цикл даже не выполняется. Или я что-нибудь не так делаю?

Damned: Дайте пожалуйста линк на последнюю версию без багов основного функционала (сравнение).

Wild User: 2 Damned Линк - в шапке темы.

ahv: даешь opensource и совместные проекты :)

Whats: Прога классная, но я что-то не пойму - при сравнении битрейтов есть настройки "Не добавлять, если в Master <= ..., а в Slave >- ...", т.е. по сути битрейты не сравниваются друг с другом, а лишь проходят проверку на это условие. Можно ли в этой проге просто сделать так чтоб сравнивались битрейты между собой, и тогда находились все битрейты, которые выше чем в Master. Потому что, как я понял, настройками программы просто нельзя охватить все случаи

Wild User: Whats пишет: "Не добавлять, если в Master <= ..., а в Slave >- ..." Во-первых не "НЕ добавлять", а "ДОБАВЛЯТЬ". Whats пишет: чтоб сравнивались битрейты между собой Это и должно происходить, при правильном указании колонок с битрейтом. Whats пишет: находились все битрейты, которые выше чем в Master Насколько выше то? На 1 кбит/сек или на 10? Грести всё подряд, лишь бы чуть выше? По-моему, нет смысла "улучшать" битрейт абы как. Величиной "...если в Мастер <=..." задаётся битрейт, который для тебя есть достойный улучшения (например - 128). Далее - величина "...а в Слэйв >=..." указывает битрейт, который является приемлемым для улучшения (например - 256). Чем не устраивает такой вариант? Если уж улучшать битрейт, то сразу, на максимальную величину, а не на единицы кбит/сек при каждом сравнении каталогов. Хотя... Может ещё кого не устраивает реализация? ИМХО - смысла нет!

Whats: Насколько выше то? На 1 кбит/сек или на 10? Грести всё подряд, лишь бы чуть выше? По-моему, нет смысла "улучшать" битрейт абы как Можно добавить возможность указывать минимальную величину улучшения "...если в Мастер <=..." задаётся битрейт, который для тебя есть достойный улучшения (например - 128). Далее - величина "...а в Слэйв >=..." указывает битрейт, который является приемлемым для улучшения (например - 256) Тогда во многих случаях альбомы с качественно лучшим битрейтом определятся не будут, например: если в мастере 64, а в слейве 192; в мастере 96, а в слейв 224; в мастере 160, а в слейве 320. Да и вообще как ни настраивай эти 2 параметра - куча вариантов всё равно выпадает, и по-моему единственное решение - сравнивать напрямую битрейты мастера и слейва, плюс если сделать возможность выставлять минимальную величину улучшения битрейта, будет вообще отлично

Die Hard: Программа безусловна классная. Но вот сегодня, она меня просто убила, выдав «Вот зараза – опять ошибка!». Но так как вручную, уже влом мне сравнивать каталоги по 5 с лишним тыс. позиций, то решил найти источник ошибки. Выяснилось, что один из столбцов, ссылается на другой. Своего рода, проверка на новинки. Удалил оба столбца, все заработало. Может быть в новой версии такого нет, надо будет попробовать. У меня сейчас v2.0.2.

Wild User: 2 Die Hard Да, такое иногда бывает. Нужно наверное изменять метод загрузки из экселя. Возможно, если сам не наковыряю что-нибудь, придётся просить помощи у более опытных товарищев :). А пока... Лечится либо описанным тобой методом, либо пересохранением эксель-файла в csv и последующей загрузкой в компарер. Кстати, у TableComparer такого вроде не наблюдается, может его автор захочет подсказать, что не так я делаю... А нельзя ли мне тот файл прислать, в оригинале (на котором глюк проявляется)? Мыло в профиле... Добавлено. Урра! Вроде удалось победить сей глюк. Но хотелось бы проверить, поэтому предложение прислать "тот" файл - в силе. Кстати, TableComparer страдает той же "болезнью"...

Whats: Wild User, мой пост ты не заметил или проигнорировал?

Wild User: Whats пишет: Wild User, мой пост ты не заметил или проигнорировал? Заметил, однако (хотя, учитывая специфику форума, можно и проморгать). Но не проигнорировал, ибо своё мнение я уже выразил выше и добавить мне нечего. Возможно я пересмотрю его, но позже, потому как в программе обнаружились глюки при загрузке некоторых Эксель файлов и на текущий момент эта проблема мне кажется более важной. Ещё что хочу сказать... Про предложенное тобой решение. Подумаю, как будет время, над этим, но пока останется так как сейчас. Ну и... Хотелось бы послушать мнение и других юзеров программы по поводу "лучшести" того и другого способов, дабы определиться, стоит ли городить огород. Ведь вроде кроме тебя никто не жаловался, что его не устраивает имеющееся...

Wild User: Очередная бетка... Текущие изменения: 1. ПОЛНЫЙ отказ от работы через Эксель. Загрузка и сохранение выполняется программой внутренними методами. Разделитель для csv определяется автоматически (если будет некорректно работать - пишите, добавлю ручной выбор разделителя). 2. Незначительные изменения интерфейса. Заменены контролы, которые периодически глючили при прорисовке. 3. Добавлена возможность "улучшать" битрейт порогово, т.е. при превышении битрейта альбома Мастер-файла на заданную величину. (этe идею предлагал чуть выше Whats , но хоть она и не получила ничьих отзывов, всё равно была добавлена экспериментально). 4. Различные мелкие переделки-доработки для функции сохранения результата. Формат файла выбирается в диалоге выбора пути для сохранения. 5. + всякие мелочи... Ссылки в шапке, если что не так - сообщайте.

ahv: этe идею предлагал чуть выше Whats , но хоть она и не получила ничьих отзывов, всё равно была добавлена экспериментально я тогда подумал, что он прав, и промолчал

Wild User: 2 Ahv Ты промолчал про то что Whats прав, другие промолчали что не прав, остальные молчат и всякую фигню думают :) В общем, что б не спорили - добавил :)

ahv: никто не спорит => я спор выиграл, он прав. hooray for me!

Whats: супер, терь всё отлично))) только неплохо было бы диапазон битрейта сделать не от 10-ти, а от 3-4рёх - чтобы надёжней шло сравнение по размерам альбомов

Wild User: Обновление до версии 2.3 Главным образом, переделаны все алгоритмы сравнения для увеличения скорости. Думаю, что повысить скорость удалось значительно. А заодно и улучшить качество сравнения. Например, для программы являются одинаковыми такие написания, как - Игорь Тальков = Тальков Игорь = Igor' Tal'kov = Tal'kov Igor' Это позволяет определять "транслитерированных" русских исполнителей и "перевёртыши" (часто встречается для имён собственных). Ну и - С НАСТУПАЮЩИМ ВСЕХ!

Exchangenewage: Заметил один глюк у программы. При небольшом проценте допуска уходит в бесконечный цикл. З.Ы. Предпочитаю пользоваться программой TableComparer, так как она показывает проценты сравнения для всех альбомов.

Wild User: Exchangenewage пишет: При небольшом проценте допуска Сколько и в каком режиме сравнения?

Exchangenewage: Процент допуска: 30. Способ сравнения: нестрогое. Действие: "поиск имеющегося" или "поиск дубликатов". В сравниваемых каталогах по 2000 альбомов.

Wild User: Не смог воспроизвести. Два каталога по ~5500 позиций, время сравнения - 20 секунд. А зачем такой низкий процент выставлять? 70-80 будет достаточно. ЗЫ. А если 50 или 60 выставить, то тот же результат, что и при 30?

Exchangenewage: При 60 уже нормально работает. Низкий процент выставлял, когда определял, какой процент будет оптимальным для программы.



полная версия страницы