Update search3.md

[lachlan-00]

rules for query parameters as discussed in #195

[netlify]

✅ Deploy Preview for opensubsonic ready!

Name	Link
🔨 Latest commit	fcca15d
🔍 Latest deploy log	https://app.netlify.com/projects/opensubsonic/deploys/6a26594895abb300087ce502
😎 Deploy Preview	https://deploy-preview-246--opensubsonic.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[Copilot]

Pull request overview

This PR updates the search3 endpoint documentation to clarify OpenSubsonic server requirements for how the query parameter is parsed and matched, based on the discussion in #195.

Changes:

• Adds a new OpenSubsonic warning block specifying required query parsing/matching rules (per-word matching, grouping, and matching behavior).
• Documents grouping behavior via + or quotes and how grouped vs ungrouped words should match.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Tolriq]

Written like that you prevent servers to use fuzzy search or any improvement to their search algo.

[lachlan-00]

I've implemented the first round, i'll put more information around fuzzy things as well after.

right now i'm also including search* "search term"* and a few others so will need to extend this

[deluan]

I don't think I agree with forcing this over all server implementations, specially defining which fields to search on.

[lachlan-00]

I've added "by default" in the rules and rewritten it a bit looser. This is all based on demo.subsonic.org's behaviour as the "subsonic way".

I think from here there also needs to be a new search endpoint that allows heavier customisation, rules and objects to match which i've raised before.

There needs to be definition of what the standard is otherwise search3 means anything you want which isn't helpful if we're all going to implement the same thing.

I don't care what the standard actually is but we need to do the same things and a clarification of some kind will set that requirement.

[lachlan-00]

Regarding search fields i think there needs to be the subsonic way then the wild way.

A new parameter like anywhere would let you open up the query past the defaults

| `anywhere` | No | **Yes** | 0 | 0,1 Search all available fields instead of just the name/title |

Alternatively MusicBrainz allows query prefixing which is also a possible alternative but i like it less as it's a significant change to implement

https://musicbrainz.org/ws/2/release?query=artist:${artistName}&fmt=json

What i'm trying to push for is some kind of consensus on what to do so it's clear.