Seekbar is always displayed even without MediaAction.seek about audio_service HOT 10 CLOSED

With this setup the seekbar is always displayed.

 void _updatePlaybackState() {
    List<MediaControl> controls = [];
    AudioProcessingState processingState = AudioProcessingState.ready;

    if (isPlaying) {
      controls = [MediaControl.pause, MediaControl.stop];
    } else {
      controls = [MediaControl.play];
    }

    playbackState.add(PlaybackState(
      controls: controls,
      systemActions: Set.from([MediaAction.play, MediaAction.pause, MediaAction.stop]),
      playing: isPlaying,
      processingState: processingState,
    ));

  }

from audio_service.

You selected "The bug is reproducible on the official example (without any code modifications)"

You should have selected the other option and then followed the instructions.

from audio_service.

You selected "The bug is reproducible on the official example (without any code modifications)"

You should have selected the other option and then followed the instructions.

Sorry about that. The issue is very easily reproducible.

from audio_service.

I have closed the bug report since you did not follow the instructions by providing a minimal reproduction project, and you continued to resist providing one when asked. The rendering and behaviour of the seek bar depends on a number of factors which are outlined in the documentation and there are also individual differences in rendering style depending on the variant and version of Android, but it is impossible to see from what little you provided in your report whether there is actually a bug (I doubt it), whether your code has a bug (likely but I can only see a small portion of it, and I certainly can't clone it and run it since you didn't follow the instructions), or whether it's the rendering style of the particular version or variant of Android you tested on.

from audio_service.

@ryanheise Alright, sure, lovely.

In the example project replacing the original method

  PlaybackState _transformEvent(PlaybackEvent event) {
    return PlaybackState(
      controls: [
        MediaControl.rewind,
        if (_player.playing) MediaControl.pause else MediaControl.play,
        MediaControl.stop,
        MediaControl.fastForward,
      ],
      systemActions: const {
        MediaAction.seek,
        MediaAction.seekForward,
        MediaAction.seekBackward,
      },
      androidCompactActionIndices: const [0, 1, 3],
      processingState: const {
        ProcessingState.idle: AudioProcessingState.idle,
        ProcessingState.loading: AudioProcessingState.loading,
        ProcessingState.buffering: AudioProcessingState.buffering,
        ProcessingState.ready: AudioProcessingState.ready,
        ProcessingState.completed: AudioProcessingState.completed,
      }[_player.processingState]!,
      playing: _player.playing,
      updatePosition: _player.position,
      bufferedPosition: _player.bufferedPosition,
      speed: _player.speed,
      queueIndex: event.currentIndex,
    );
  }

with

PlaybackState _transformEvent(PlaybackEvent event) {
  return PlaybackState(
    controls: [
      if (_player.playing) MediaControl.pause else MediaControl.play,
      MediaControl.stop,
    ],
    systemActions: const {
      MediaAction.play, MediaAction.pause, MediaAction.stop
    },
    androidCompactActionIndices: const [0, 1, 3],
    processingState: const {
      ProcessingState.idle: AudioProcessingState.idle,
      ProcessingState.loading: AudioProcessingState.loading,
      ProcessingState.buffering: AudioProcessingState.buffering,
      ProcessingState.ready: AudioProcessingState.ready,
      ProcessingState.completed: AudioProcessingState.completed,
    }[_player.processingState]!,
    playing: _player.playing,
    speed: _player.speed,
    queueIndex: event.currentIndex,
  );
}

unless I'm mistaken should lead to a seekbar-less widget. If that's expected, please do enlighten me, for sure it might be a dumb mistake on my part.

But the result (API 34):

Please feel free to check the code here.

https://github.com/Sungray/audio_service/tree/minor

The documentation specifies multiple conditions for the seekbar to be displayed, notably having set a duration and enabling it using MediaAction.seek. I set no duration, do not enable seek, seekForward or seekBackward in the systemActions, and yet the seekbar is displayed.

from audio_service.

Can you edit your original bug report please? I have a script to help me interface with the computer and help me work on this plugin. But if the code snippet above is the only change you made, then you have not read the documentation entirely. That is why I explained to you that it depends on a number of factors outlined in the documentation as well as the rendering choices of the particular version/variant of the OS you are using. Saying API 34 does not tell me which phone you are testing on. Each device manufacturer typically uses their own custom version of Android and may make its own choices about rendering the seek bar. You can follow the instructions in the documentation to indicate that you don't want a seek bar, but whether the seek bar completely disappears or a ghost seek bar is displayed where a seek bar would normally be displayed is a choice of the device manufacturer. But if you're getting an actual seek bar that displays the current position, then you are not following the instructions in the documentation in their entirety.

from audio_service.

Can you edit your original bug report please? I have a script to help me interface with the computer and help me work on this plugin. But if the code snippet above is the only change you made, then you have not read the documentation entirely. That is why I explained to you that it depends on a number of factors outlined in the documentation as well as the rendering choices of the particular version/variant of the OS you are using. Saying API 34 does not tell me which phone you are testing on. Each device manufacturer typically uses their own custom version of Android and may make its own choices about rendering the seek bar. You can follow the instructions in the documentation to indicate that you don't want a seek bar, but whether the seek bar completely disappears or a ghost seek bar is displayed where a seek bar would normally be displayed is a choice of the device manufacturer. But if you're getting an actual seek bar that displays the current position, then you are not following the instructions in the documentation in their entirety.

I cannot find anything else in the documentation apart from the part I linked in my OP.
API 34 meaning the official Android VM from Google, and also reproduced on a physical Samsung S21 Ultra running Android 14. No, of course it's not displaying the actual progress, it's a ghost seek bar.

from audio_service.

I cannot find anything else in the documentation apart from the part I linked in my OP.

In the part of the documentation you quoted, the very next paragraph says:

Note that specifying MediaAction.seek in systemActions will enable a seek bar in both the Android notification and the iOS control center, but on Android, it will show only if the media item's duration has been set.

Your code snippet does not show you setting the duration of the media item to null.

API 34 meaning the official Android VM from Google

API 34 refers to the API level, not the specific device. Finally you have revealed that you were using the emulator image.

Android 14. No, of course it's not displaying the actual progress, it's a ghost seek bar.

Wait, so you KNEW that your particular test device/image will, of course, display a ghost, and you think that it's a bug that this plugin is showing a ghost where the seek bar would normally appear if the seek action is included and the duration is set? Then I don't understand why you are submitting the bug report in the first place.

from audio_service.

Quote war, yey.

Your code snippet does not show you setting the duration of the media item to null.

Nowhere in the doc does it say that for the seekbar to NOT be displayed, the duration should be set to null. (and I did try that, with no success).

API 34 refers to the API level, not the specific device. Finally you have revealed that you were using the emulator image.

so the doc does not apply to the official images?

Wait, so you KNEW that your particular test device/image will, of course, display a ghost, and you think that it's a bug that this plugin is showing a ghost where the seek bar would normally appear if the seek action is included and the duration is set? Then I don't understand why you are submitting the bug report in the first place.

No, you misunderstood. I was saying that of course, the progress is not tracked since I removed everything related to the seekbar, there would be no way for the progress to be updated. I was following the information available, and seeing that I was testing on two massively popular and up to date images (latest OneUI & official Google) and getting the same results, not on par with the documentation, I was thinking there was something wrong somewhere.

Again, the seek action is not included, the duration is not set, and yet there is a seek bar (albeit a ghost bar - a term I did not know before reading it from you). It's in complete contradiction with the documentation, again considering that I am not testing this on some obscure devices or images, but on the two most massively adopted images available. So yes, concluding to a bad configuration on my end or to a bug on the plugin is not so far fetched.

I don't understand why you are taking this so personally, Chill out.

from audio_service.

and seeing that I was testing on two massively popular and up to date images (latest OneUI & official Google)

Neither of which you mentioned in your bug report (and you still haven't - you just wrote "Android" without specifying).

Again, the seek action is not included, the duration is not set

That is not true according to your minimal reproduction project which has this:

  static final _item = MediaItem(
    id: 'https://s3.amazonaws.com/scifri-episodes/scifri20181123-episode.mp3',
    album: "Science Friday",
    title: "A Salute To Head-Scratching Science",
    artist: "Science Friday and WNYC Studios",
    duration: const Duration(milliseconds: 5739820),
    artUri: Uri.parse(
        'https://media.wnyc.org/i/1400/1400/l/80/1/ScienceFriday_WNYCStudios_1400.jpg'),
  );

Note the duration is set. That means you probably would not be getting a ghost, you might get a progress bar but not a seek bar. The docs say that you need to do both on Android: remove the seek action and also don't set the duration. Whether you get a seek bar, a progress bar or neither depends on the combination of these. Whether the "absence" of a seek bar is rendered as nothing, or a ghost, is up to the manufacturer's own decisions.

I don't understand why you are taking this so personally, Chill out.

I didn't like your disregard of the instructions. It wastes time, and disrespects the reason for why those instructions are there in the first place. It is very painful for me to work with computers, the instructions ensure that the person submitting the issue puts in every effort to ensure that the bug report is ready so that I minimise my interaction with the computer.

Disregard will be met with disregard. Respect would have been met with respect. You disregarded the instructions. Repeatedly.

I am locking this issue since you are now arguing about something which is entirely pedantic. The plugin is behaving correctly, and it is the OS's design decision how it wants to render the absence of a seek bar. If it wants to display a ghost where the seek bar "would have" appeared, then so be it. Not all versions/variants of Android are going to display the absence of a seek bar in the same way.

If you ever open a new issue in the future, please follow and respect what the instructions say because there is a reason why the bug report must be submitted correctly.

from audio_service.