The PSR-500 is a little more "stingy" about CTCSS/DCS/NAC when it's actually looking for a particular tone or code as compared to when Sq Mode is set to "Search" or "None".
If "None", the scanner is only looking for open RF Squelch. If "Search", the scanner is looking for RF Squelch, but will also try to decode the various coded-squelch modes. In both cases, open RF Squelch will give you audio.
If you have a particular CTCSS/DCS/NAC value programmed, the scanner is looking ONLY for that value. The steps go something like this when checking such a CONV object in Scan mode:
1. Tune to frequency
2. Look for RF Squelch - if not present, continue scanning
3. Look for programmed CTCSS/DCS/NAC value - if not present, continue scanning
4. Unmute audio
In step 3, you only get one shot within a small timing window. If the CTCSS tone is "overmodulated" or otherwise "corrupted", the scanner won't see it - and it will continue scanning.
Here, I have a related problem with the Santa Clara County Sheriff on 156.210000. They use a CTCSS tone of 179.9 Hz. The scanner never has a problem "locking onto" the transmission in Scan mode. However, there is a particular female dispatcher whose voice patterns seem to nuke the tone. The scanner, losing the tone for brief periods, will mute audio once in a while. My solution is to set that CONV object's Sq Mode to "CTCSS", but leave "CTCSS Hz" set to "Search". This forces the scanner to analog mode for that CONV object (eliminating any "wait for digital" delay), but also immunizes me against that dispatcher's voice. This only works for me because there are no other users of that frequency nearby.
If nobody else uses the frequency with which you're having problems, I'd recommend setting up that CONV object like I have:
Sq Mode: CTCSS
CTCSS Hz: Search