XamarinCommunityToolkit icon indicating copy to clipboard operation
XamarinCommunityToolkit copied to clipboard

[Bug] MediaElement inconsistent setting of CurrentState property

Open davidbritch opened this issue 4 years ago • 3 comments

Description

MediaElement includes a CurrentState bindable property that indicates the current status of the control. This property has a default of MediaElementState.Closed.

Here's the description of each MediaElementState enumeration member from the UWP docs:

  • Closed indicates that the MediaElement contains no media.
  • Opening indicates that the MediaElement is validating and attempting to load the specified source.
  • Buffering indicates that the MediaElement is loading the media for playback. Its Position property does not advance during this state. If the MediaElement was playing video, it continues to display the last displayed frame.
  • Playing indicates that the MediaElement is playing the media source.
  • Paused indicates that the MediaElement does not advance its Position property. If the MediaElement was playing video, it continues to display the current frame.
  • Stopped indicates that the MediaElement contains media but it is not being played or paused. Its Position property is 0 and does not advance. If the loaded media is video, the MediaElement displays the first frame.

The description of each member seems reasonable.

After looking at the renderers, I noticed that:

  • The iOS renderer never sets the Closed, Opening or Buffering states.
  • The Android renderer never sets the Closed or Opening states.
  • Only the UWP renderer sets all 6 states.

The doc can clarify this, but it's not ideal (the view being that the user experience shouldn't leave users scratching their heads wondering what's going on).

So after loading a video file (with AutoPlay=false), I'd expect the CurrentState property to be Stopped. Instead, here's what it actually is:

  • iOS: Closed
  • Android: Paused
  • UWP: don't care

I'm hoping there isn't a good reason for the above, and that it's a bug. When you use custom transport controls you don't want to enable your Play button until the video has loaded. However, it's harder to do this when an inconsistent CurrentState is set on each each platform. In particular you lose the elegance of having a combined Play/Pause button, where the Text is changed by a DataTrigger based on the CurrentState value, and the ability for a DataTrigger to enable/disable buttons.

So overall I have two points:

  1. Should the MediaElementState enum be reduced to members that are all implemented on our primary platforms?
  2. Should the CurrentState property have a consistent value after loading a video (but not having hit the play button)?

davidbritch avatar Feb 17 '20 17:02 davidbritch

Any update on this issue?

Dolfik1 avatar May 07 '20 16:05 Dolfik1

I have experienced this as well, on iOS, the default "Closed" state surprised me a little bit.

Kapusch avatar Jan 18 '22 18:01 Kapusch

I've created a repository showcasing some of the MediaElement bugs, including this one: https://github.com/ewerspej/MediaCustomTransport

ewerspej avatar Mar 31 '23 17:03 ewerspej