It detects if the song is not in the library, but if it finds the song it displays the message "Ugh", but it does in fact work, it played every song I tried, you just have to have the spelling 100% for both the song and artist

It detects if the song is not in the library, but if it finds the song it displays the message "Ugh", but it does in fact work

Ha! Thanks for pointing that out.  That was a debug message added in frustration during testing, which I evidently forgot to remove.   Fixed for the next build.

it played every song I tried, you just have to have the spelling 100% for both the song and artist

It actually tries an exact match first, then falls back to MySQL's SOUNDEX() function.  So it *should* allow a bit of deviation from precise spellings, although you have to get the sound of the word right (in MySQL's opinion)... for example:

Code: [Select]

mysql> select title from tracks where soundex(title)=soundex('your majesty') \G
*************************** 1. row ***************************
title: Yer Majesty
1 row in set (0.06 sec)

mysql> select title from tracks where soundex(title)=soundex('safe me') \G
*************************** 1. row ***************************
title: Save Me
1 row in set (0.00 sec)

We may try to make this more flexible in future versions, it's just that SOUNDEX() is the only feature offered by MySQL to do "fuzzy matching" at the moment, and performance-wise it wouldn't be ideal to load the entire database into memory to run more complicated tests against the track list.  And we don't want to prompt the user to select from a list of possible matches, because we don't want to divulge any info to the public about what tracks the station has available.

Yes I have been building people search searches the past few months I tried SOUNDEX also but found LIKE to work better

SONG LIKE '%$title%' OR ARTIST LIKE '%$artist%'

My variables were firstname, lastname and the % allowed me to fine tune the results because I wanted the last name to be exact but first name had wildcard only at the end (ie. John Smith,Jonathan Smith, Johnny Smith)

FIRSTNAME '$firstname%' AND LASTNAME '$lastname'

Yes  if the server has 10's of thousands of tracks it can take a few seconds, weak servers could stress a little, but not mine!

The problem there is that you're doing substring matches, and we're looking for an exact match.

Say you searched for a title like "away" and an artist like Seether has tracks called "Take Me Away" and "Fade Away"... you'd never reliably get the song you were looking for.

Worse, if an artist like Breaking Benjamin has an actual track called "Away", as well as tracks entitled "Fade Away" and "Blow Me Away", then searching for artist "Breaking Benjamin" and title "Away" with substring matching would not reliably return the track entitled "Away" even though you're requesting it explicitly, by name... you'd get whichever of the above 3 tracks happened to be returned first by MySQL.

Workarounds of varying complexities are of course possible, but I'd rather just avoid substring matching altogether and require a complete song name.  Something like Levenshtein distances was more along the lines of what I was contemplating for the future.

Steve I noticed there is a new playlist titled "Automated Song Requests" but it was, by default disabled, is this something different as they were working even with it disabled.

The Automated Song Requests playlist is an internal playlist where song requests are queued before they're played.  The enabled/disabled state is managed automatically depending on whether there are any song requests queued... if you request a song, you'll see it switches to the Enabled state.

The only reason it's visible in the admin area is so that, should the admin want to do so, he can go in, review the list of requested songs, and remove any that he doesn't want played.