distinct: unique: dupe:, not updating results is wrong

Discussion related to "Everything" 1.5.
Post Reply
therube
Posts: 5719
Joined: Thu Sep 03, 2009 6:48 pm

distinct: unique: dupe:, not updating results is wrong

Post by therube »

viewtopic.php?t=17679
distinct:/unique: will no longer add new results
dupe: will not add new results.
existing results will be updated in realtime when using dupe:
unique: and distinct: now behave the same.
The reason for the change is because adding new results doesn't re-apply the unique: or distinct: rules and the results are too confusing.
And I was not confused at all, thinking it was rather obvious what happened.
And, maybe even beneficial, as you see the before & after results, giving you a chance to ponder...

distinct: unique: dupe:, not updating results is wrong, IMHO.


MUCH prefer the old behavior.
At the least, there should be an .ini to choose.

Current behavior utterly hampers my usages.

---


nope, that is WRONG, IMHO

i would MUCH rather have something unexpected turn up
rather then to have something expected NOT turn up

in 1 window, i renamed a file, knowing that it would
turn up in a different window

in that 2nd window, it was not there, & i'm like, huh?

& i look through Undo, & it shows what i did was what
i expected & so it should be there - but it is not?

& i look through Journal, & it shows what i did was
what i expected & so it should be there - but it is
not?!

& i check my searches, & they look fine too,
& then, after all of that, i'm like, OH, my Filter
includes distinct:, & i think, wasn't there something
about distinct: & so i change to Everything Filter,
& then, like magic, out of the blue, there is the
file that i'd been missing

&... with that, so here we are

not adding results results in far more confusing
then if the results were added - even if that might
(which i can't fathom why) confuse one, momentarily

i can say, oh, i did this, & that is why that happend

that is far different from saying
i did this, & what did happen, where did it go ???

OK, this is absolutely wrong
i use distinct: all the time
i have a window /distinct:/ & i run a command on a file there
& it creates a new file, out.<filename>, & i can no longer see
it cause i have distinct:, so i have to disable/re-enable just
to see, that is wrong.

i'm expecting to see it, i just created it, yet, i cannot find
it, why? it renders anything done in distinct:/unique:,
useless. maybe distinct-lock: for those who want the current
method.

i might have 10 copies of 1000 files, & i am concerned that i
do have them (at all), & not where they might be, so i only
need to /see/ 1,000 file rather then 10,000 files

& when i'm looking to do an action on them, i only need to know
that they are, & when i (especially purposely) create a new file
i (now) no longer know it exists, because distinct: is now
blocking that knowledge from me

& in that respect, totally breaks (my) value of distinct:

what i used to be able to do in 1 tab, i now need to deal
with multiple windows to accomplish (or to regularly jump
back & forth between filters to both be able to see that
i do have & then to filter those results in a more
meaningful manner)

AH !!!
even if you Find <Column> Duplicates, that too locks things.
sorry, that is just so wrong, IMHO, heh.

i dup'd by Length, transcoded a video (so same Length) & when it
was done, i went to compare, but it was nowhere to be seen,
so then i refreshed, which then forced me to
Find <> Duplicates - again, & was on the wrong column,
so then i had to Find <> Duplicates - again, this time on
the correct column, before i got to see my expected file
void
Developer
Posts: 19863
Joined: Fri Oct 16, 2009 11:31 pm

Re: distinct: unique: dupe:, not updating results is wrong

Post by void »

Thanks for the feedback therube,

What is your distinct: search?
-is it just
distinct:
? (ie: distinct name)

Do you ever specify a property with distinct: and if so, what properties?

I am assuming you just use distinct: to find distinct names, so for that case I will add new results in the next update.
For any other properties, distinct: will not add new results.
therube
Posts: 5719
Joined: Thu Sep 03, 2009 6:48 pm

Re: distinct: unique: dupe:, not updating results is wrong

Post by therube »

Most often I use them in Filters.
(And yes, I call my "distincts" "UNIQ" - because it is more understandable to my brain ;-).)

"UNIQ",0,0,0,0,0,0,0,0,0,"video: sort:length distinct: ","","Size",1,,,597
"UNIQ - online",0,0,0,0,0,0,0,0,0,"video: sort:name: distinct: online:","","",0,,,
"UNIQ - online !/delme",0,0,0,0,0,0,0,0,0,"video: sort:length distinct: !/delme","","",0,,,


-


dupe:size

you rename a file,
immediately, UNDO
& it is no longer there :(

- you have to Refresh for it to show up
therube
Posts: 5719
Joined: Thu Sep 03, 2009 6:48 pm

Re: distinct: unique: dupe:, not updating results is wrong

Post by therube »

aside from my distinct: Filters

searchbar searches (that i've long had on hand):
  • dupe:size;!name;dm !/$recycle !/corrupt
    dupe:size;!name !/$recycle !/corrupt
    distinct:size;name dupe:size !/$recycle !/corrupt
    distinct:size;name dupe:length !/$recycle !/corrupt !/delme
    distinct:size;name dupe:Length /MOVIE
    unique:size;len !/$recycle !/delme !offline:
(now, these, i know that i do have to manually refresh, & i'm OK with that.
& [now] with, session_store_restore_on_demand=1, i only have to actually
do that in 1 tab, cause all the rest do that, automatically, [only] when i
physically land on them)

& aside from Filters & searchbar searches, i'll also regularly use the
  • Find <col> Duplicates function
- be it alone or in conjunction with Filter/searchbar
therube
Posts: 5719
Joined: Thu Sep 03, 2009 6:48 pm

Re: distinct: unique: dupe:, not updating results is wrong

Post by therube »

i have a set of files that i'm working on

Code: Select all

    33,214,016    14:13 out.zzz.TT-TTTTTTT.mp4
    33,214,016    14:13 out.zzz.TT-TTTTTTT.mp4
    33,213,898    14:13 zzz.TT-TTTTTTT.mp4
    33,213,898    14:13 zzz.TT-TTTTTTT.mp4
    33,212,396    14:13 zzz.avi.no.op.TT-TTTTTTT.mp4
    33,212,396    14:13 zzz.avi.no.op.TT-TTTTTTT.mp4
    33,212,396    14:13 zzz.avi.beg.TT-TTTTTTT.mp4
    33,212,396    14:13 zzz.avi.beg.TT-TTTTTTT.mp4
    33,076,016    00:00 zzz.avi.frag.TT-TTTTTTT.mp4
    33,076,016    00:00 zzz.avi.frag.TT-TTTTTTT.mp4
different names, sizes, lengths, & they are all dup'd & other then the
dup's, which are actual dups, they are all different, in some way,
internally, & yet, at the same time, they are all identical as far as
the actual video & audio content are concerned

so... how to approach things to get an idea of what i've got, & why?

sort by size, that's a good start, each size is demarked, colored, size
dups stand out easily
- great, that helps

but, as i'm dupe:size (actually, Find Size Duplicates) if i do something
that creates another file that meets my search, 'TT-TTTTTTT'
- it will NOT be seen
unless, i realize the creation process has finished, unless i know that
i did in fact name that output file as TT-TTTTTTT (& not TT-TTTTTT), &
that i then manually refresh my search, which, at that point, will pick
up the newly create file


that aside, i mentioned above that the files, internally, are identical.
yes, i said that, & i "know" that to be the case, but i want to verify
that.

& i also know that i have dups of each file, that are in fact actually
dups - every file has an exact copy of itself.

so what do you do at that point? no need to verify the internal
identical-ness of 10 items, i only need to verify internal
identical-ness of 5 items. should take half the amount of time - great!

& how do you do that? well, distinct: of course. so i fire up my
distinct: filter

& with that, i'm only looking at 5 items that i need to deal with, & i
can send those 5 to my hashvideo program.

sweet.

& that tells me that in fact i was wrong about my "identical-ness"
statement. while the video is exactly the same in all the clips, the
audio is the same in 2 of them, & the same in the 3 others.

i in fact have 2 different (sets of) audio. what is up with that? so i
take 1 of each of those 2 files, differing audio, & throw them to my
audio analyzer (theorically, here ;-)), & it spits out a new file named,
"c:/out/out.AA.TT-TTTTTTT.mp4"

but guess what, because i'm on a distinct: filter i won't see that file.
i have to know that the AA program finished, that the output file was
created, that it was named correctly, & then, i have to manually refresh
my results so that i know it is there.

before, in both circumstances - with dupe: & with distinct:, the files
would have turned up automatically. perhaps "wrongly", in a "true"
sense of dupe: or distinct: (at a specific point in time)
- but to my benefit


something i can see, i can deal with, i can say, oh, that really
shouldn't be there, is not appropriate for me to see at this particular
time, & i can filter it out (which a refresh might accomplish)

but something i cannot see, that i do not know exists, that might only
exist... in the future, that, i cannot deal with because i do not know
(necessarily) that it happened to come about (& now, dupe: & distinct:
& unique:... are hiding that from me [or at least, more so then before])

& for that, i am (IMO) worse off, then had something inadvertently made
its way into my dupe: or distinct:


(now, my scenario here may not be, exactly, how things worked before, in
alpha, but IMO, things worked better before, then they do now)


if there were a .ini switch, that would cover both camps...
(but maybe it is more the just an .ini switch, as in actual programing
considerations...
anyhow, i still stand by my stance, however it may turn out :-).)


also note that i cannot rely on name, directory, size, date, or length
- alone, to understand what i've got. i have to take multiple factors
into consideration. & in the end, i only really need to deal with 2
files to truely understand what i've got going on - not 5 files, much
less 10.
void
Developer
Posts: 19863
Joined: Fri Oct 16, 2009 11:31 pm

Re: distinct: unique: dupe:, not updating results is wrong

Post by void »

- it will NOT be seen
unless, i realize the creation process has finished, unless i know that
What about pressing F5 in Everything to refresh your distinct: search? -just curious..
therube
Posts: 5719
Joined: Thu Sep 03, 2009 6:48 pm

Re: distinct: unique: dupe:, not updating results is wrong

Post by therube »

First thought is, because it is not automatic.
Because there is now an action I need to explicitly take.
Because I may be too early in my F5. The file will be there - just not as of when I Refreshed.

I may not want my earlier results disturbed.
Typically I'm working down sets of files, & I rather not have "everything" Refresh, but I am not against seeing something new, turn up, necessarily. And when I'm specifically working on particular sets of files, & do something that creates a new file that falls into that same set, I do not want that new file to be "hidden" from me.

(Oh, I don't know, just coming up with excuses ;-).)


-


so i do a search, & i do a <Find Length Dupes>
cause it lays things out nicely & such

& i have 2 files, both ".mpg"
yet neither are .mpg
1 is .avi, & is .m1v
so i rename them, & on doing so,
the Length of .m1v is lost
(happens to be the case, & I'll get to that at some later time)
so i MUX the audio from .mpg into .m1v
(.m1v, by definition, i suppose, are video only, so not expected to have audio)

&... and... &... i don't see the newly create file ;-)
(heh, i did that purposely - because i [now] know that
i won't see them ;-))

so i refresh, & thar'she'is
& as i didn't want the file (to begin with - just wanted to see what would happen),
i delete it & all was good

except.

except that i now see a 0-byte file, that i didn't see, initially on Refresh.
this 0-byte file happened on my first MUX attempt - which failed.
but i didn't see this file, initially - cause dupe: blocked it from showing,
& i didn't see this file, the 2nd time, after my Refresh, cause it didn't occur to me that it might
even be there, that "something" was created

so, because the file never showed up, & while it was there, i didn't see it when it initally was
created, & also also didn't see it after a physical Refresh - though... in alpha, i /might/ have
caught it when it was initially created - maybe.
void
Developer
Posts: 19863
Joined: Fri Oct 16, 2009 11:31 pm

Re: distinct: unique: dupe:, not updating results is wrong

Post by void »

Everything 1.5.0.1414b adds a few options to update duplicate results:

dupe_research_on_result_change

When enabled, Everything will re-apply your dupe:/distinct:/unique: search when the results change.
This will keep your results up-to-date.
Enabling can drastically increase the CPU usage of Everything.
-it's not so bad when combined with other filters, but global dupe: searches will constantly be updating.

To enable dupe_research_on_result_change:
  • In Everything 1.5, from the Tools menu, click Options.
  • Click the Advanced tab on the left.
  • To the right of Show settings containing, search for:
    dupe
  • Select: dupe_research_on_result_change
  • Set the value to: true
  • Click OK.


dupe_add_new_results (old behavior)

When enabled, Everything will always add new results, even when the new results don't match your dupe:/distinct:/unique: search.

To enable dupe_add_new_results:
  • In Everything 1.5, from the Tools menu, click Options.
  • Click the Advanced tab on the left.
  • To the right of Show settings containing, search for:
    dupe
  • Select: dupe_add_new_results
  • Set the value to: true
  • Click OK.


Please let me know if dupe_research_on_result_change is useful.
dupe_add_new_results can probably be removed.
Post Reply