re-searching on it's own

[Karanight]

Here's a frustration when working to get perfect meta data
I've found that when I edit an artist songs every now and then the program researches the name
I'm using ver 1b1
1, search for artist ie Meatloaf
2, when the search is complete start to edit the songs
3 no problem to start with but as I edit more the screen goes blank and the activity window shows that its searching and also saving.
I don't understand why it's re-searching when I've not been near the search bar

[dave]

sorry it's taken me so long, i'm working on it! I'll have an answer for you by tuesday at the latest

[dave]

Here's the trick:

do NOT sort by something that will change.

eg: if you're sorted by "Song Name", and you do a search which produces results, then in the search results you change a song's name, you've just invalidated the current sort, which will cause it to re-sort.

So, instead, sort by "PLI", which stands for "Play List Index", and that will never change.

[DeusExMachina]

I understand what is going on here behind the scenes, and why this changed from how it used to be, but I have to say, the old behavior was better. Quite often the whole point of searching is to edit metadata, and sorting by a particular columns how you group the tracks together that you are trying to edit to get perfect metadata. This is also, coincidentally, almost always the same item you are searching on, since that is what prompted the metadata edit in the first place. Having to sort on a non-changing column not only adds another step, but it often also makes these metadata edits impracticable if not impossible on large batches.

[dave]

hmm, as far as i know, it never worked the way you suggest, or if it did, it was a terrible bug. and i'm trying to be funny here, but to me it sounds a bit like saying "i hate it when i step on the brakes that this red light comes on on the back of the car!, and even worse, the car slows down!"

ie: you can't tell the app to sort by name and then have it NOT sort by name, right?

sorry but there's just no way to do what you're asking, and there never has been (not in a supported way)

a trick i use to get around the limitation you're running into, and yes, it IS "another step", is that once you do your sort and search, select all the songs you want to operate on and move JUST THEM to a new playlist. then sort that playlist by PLI. Now, they're still all in a group so you can see them, but they're NOT now sorted by something that you're about to change.

[DeusExMachina]

I am fairly certain that when you used to do a search, you were free to edit the results however you wished. There never used to be a dialog, prior to several versions ago, that popped up telling you you can't change a value in a sorted field. In fact, I relied on that quite frequently while editing metadata.
Regardless, once a search is completed, why does it matter if you edit a value out of the search parameters? I understand that kJams is now trying to re-sort using the new values, and that causes the need to re-search, but why can't the search result be static, and remain as returned until a new sort or the search is canceled. Again, I am pretty sure that is how it used to work. Unless I was hallucinating.

[dave]

sorry, i tried to be clear. if it was ever "working" in the past, it was a bug and was actually NOT doing the correct thing.

kJams uses a model-view-controller paradigm (google it).
when you change the model, the view MUST update. there's nothing you can do about that, nor should you. The moment the model is changed the VIEW is out of date, you'd be looking at old data. Yes, when you edit a song name, kjams updates the view of THAT song real quick, before it tells the model (since model -> view updates are slow), but the data is still considered stale. Once kJams tells the model, it invalidates all views on that model.

If that doesn't make sense to you, sorry. you'll have to trust me there's nothing that can be done about this right now. What you're used to is "fast searching" with iTunes, where you don't even NOTICE that you did a search because it happened so quickly. When kJams has that, this will be a non-issue.

[DeusExMachina]

Yes, yes, I know. It makes perfect "sense". I am saying there was clearly a "bug" in previous versions, since it only started complaining recently. And the bug was a feature!

[dave]

yes, i get it how the bug was a feature, but that bug had to be fixed, sorry.

"fast searching" in 2.0 will make this all moot