Revert cast platform polling mode

[OttoWinter]

Description:

We used to rely on the cast device notifying us of all media status changed via callbacks. However, some apps like Netflix sometimes didn't send those callbacks even though the state had changed. In #13275, I introduced a semi-polling mode for the cast platform: we would still respond to all callbacks, but in addition we would poll the chromecast device every 30 seconds for the current state to resolve the Netflix media status issue.

However, it turned out that some other apps on the other hand don't like the polling mode at all :(. When polled for the current state via a GET_STATUS request, they responded with the media status of the most recent callback media status, not the actual media status (but only for a some apps 🤬). As there's no information in the MEDIA_STATUS messages to which timestamp the currentTime attribute corresponds, there's no good way to solve this IMHO.

This PR reverts #13770 and partially reverts #13275 to go back to the old callback-only method. It has its own issues, but is a lot better than the issues mentioned in #13770.

I must say, the cast protocol is extremely weird with lots of these things. I seriously would have expected a better quality out of one of google's products.

Related issue (if applicable): fixes #

Example entry for configuration.yaml (if applicable):

media_player:
  - platform: cast

Checklist:

• The code change is tested and works locally.
• Local tests pass with tox. Your PR cannot be merged unless tests pass

If the code does not interact with devices:

• Tests have been added to verify that the new code works.

[dersger]

Do we know if there are any apps that will send MEDIA_STATUS updates periodically even if polling isn't used? If updates are received then the new_media_status() calculations can be kept to avoid unnecessary state attribute updates. But that code is not needed if we do not get MEDIA_STATUS updates.

[OttoWinter]

All apps I've seen only send MEDIA_STATUS if something has actually changed. Though some (like Netflix) don't even send a MEDIA_STATUS message even if something changed (hence the half-polling mode).

[dersger]

Ok.

I tested Spotify a little without polling. It seems to sometimes (for example if pausing) send an old current_time even without polling. But it then also soon after sends another update with a good current_time. So the bad position doesn't last for long.

Is it only Spotify that's misbehaving? It's a rather common app though...

[OttoWinter]

@dersger I have YouTube and the default media receiver do the same during my testing... And it's true there is this old current_time callback but that only seems to happen when connecting (AFAIK pychromecast sends a GET_STATUS request when a connection is established)

[dersger]

I didn't get any problem when I used YouTube from an Android phone. But I do get the polling problem when using screen mirroring from the phone, or if using mirroring from a Chrome browser in Win10. I get media_position 0.0 and state playing repeatedly during mirroring.

[balloob]

I think that if we want to re-introduce this behavior again in the future, we should limit it to apps that are known broken, like netflix.