Check metadata title for URI hints before discarding

[jjlawren]

A change in #896 caused certain titles (most obviously from CIFS shares) to be incorrectly discarded as they were contained in the track URI. This was naive as even single-word strings would trigger the discard behavior. This PR adds an additional hurdle which requires the track to contain some URI components before it is discarded, such as path and query arguments or an .m3u8 extension.

I've also added tests to validate expected processing of metadata from a variety of sources. This should help ensure we're going all we can to get correct results and also prevent future regressions.

Note: This includes the commit from #904 in order to pass tests. Once that PR is merged this can be rebased to simplify the changes.

Fixes: #903

[jjlawren]

This is not handled ideally, but it mirrors what is displayed in the native Sonos app. Perhaps should also be discarded?

[jjlawren]

Radio stations usually provide the station name in a separate call (SoCo.get_current_media_info()["channel"]) which could be used as a fallback title, but that should probably be handled by the downstream application.

[pwt]

Radio stations usually provide the station name in a separate call (SoCo.get_current_media_info()["channel"]) which could be used as a fallback title, but that should probably be handled by the downstream application.

Just to note that to get radio show names, I fall back to using avTransport events with something like:

sub = speaker.avTransport.subscribe()
event = sub.events.get(timeout=0.5)
radio_show = event.variables[
       "current_track_meta_data"
].radio_show.rpartition(",")[0]

[jjlawren]

Just to note that to get radio show names, I fall back to using avTransport events with something like:

Yep, that's the exact same data as what get_current_media_info() provides and how I solve this problem downstream today. I was talking in terms of a pure polling workflow using the built-in methods and making this "automatic" for simpler use-cases.

[pwt]

Just to note that to get radio show names, I fall back to using avTransport events with something like:

Yep, that's the exact same data as what get_current_media_info() provides and how I solve this problem downstream today. I was talking in terms of a pure polling workflow using the built-in methods and making this "automatic" for simpler use-cases.

get_current_media_info() gets the radio channel, but not the radio show (i.e., the equivalent of the title). At least, not in my experimentation.

[jjlawren]

get_current_media_info() gets the radio channel, but not the radio show (i.e., the equivalent of the title). At least, not in my experimentation.

Ah, yes, I didn't read the attributes closely enough. You're absolutely right and I have not seen that payload in polling calls, either.

I was thinking about the radio station, which would require an additional call to the speaker. The radio show is simply not available without separately consuming subscription events.

Assuming the user would want to use the radio station/channel as the title may not be a safe assumption and should not be done here.

[pwt]

I've merged #904. @jjlawren Do you want to rebase this PR, or should I commit it as-is? Ah ... you just answered my question :)

Once committed, I'll issue a patch release.

Nice work. Great to see all the validation tests.