ryanheise / just_audio

Audio Player
1.04k stars 656 forks source link

setUrl not working when screen is locked #205

Closed dankydev closed 3 years ago

dankydev commented 3 years ago

Which API doesn't behave as documented, and how does it misbehave? Just_Audio 0.5.2, Android API 30 and 31. When i turn off the screen of the emulator/physical device, i receive the error reported below after calling audioPlayer.setUrl (when the screen is on, everything goes as it should). Since it seemed to be caused by the Android's sleep policy, i tried changing to the always-on one:

adb shell settings put global wifi_sleep_policy 2 adb shell settings get global wifi_sleep_policy

But the error persists

Minimal reproduction project The example project should be sufficient.

To Reproduce (i.e. user steps, not code) Steps to reproduce the behavior:

  1. Reproduce a track
  2. Lock the screen of your phone/emulator
  3. Wait for the next track to be played: it won't.

Error messages

E/ExoPlayerImplInternal(10602): Source error
E/ExoPlayerImplInternal(10602):   UnknownHostException (no network)
E/AudioPlayer(10602): TYPE_SOURCE: Unable to connect
E/flutter (10602): [ERROR:flutter/lib/ui/ui_dart_state.cc(177)] Unhandled Exception: (0) com.google.android.exoplayer2.upstream.HttpDataSource$HttpDataSourceException: Unable to connect
E/flutter (10602): #0      AudioPlayer._load 
 package:just_audio/just_audio.dart
E/flutter (10602): <asynchronous suspension>
E/flutter (10602): #1      AudioPlayer.load 
 package:just_audio/just_audio.dart
E/flutter (10602): #2      AudioPlayer.setUrl 

Expected behavior I do need connectivity to be constantly active even when the screen is locked: is this related to AudioPlayer or ExoPlayer? a network-oriented music application not working when screen is locked wouldn't be nice...

Screenshots Not needed

Desktop (please complete the following information):

Smartphone (please complete the following information):

Flutter SDK version

Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel stable, 1.22.0, on Microsoft Windows [Versione 10.0.19041.508], locale it-IT)

[√] Android toolchain - develop for Android devices (Android SDK version 30.0.1)
[!] Android Studio (version 3.2)
    X Flutter plugin not installed; this adds Flutter specific functionality.
    X Dart plugin not installed; this adds Dart specific functionality.
[√] VS Code, 64-bit edition (version 1.49.3)
[√] Connected device (2 available)

Additional context I apologize if this behavior is not your responsibility. I do need my app to reproduce music when the screen is locked, this is one of the last milestones to get it done. I would be extremely grateful if you helped me finding a solution. Thanks in advance. Greetings

ryanheise commented 3 years ago

Additional context I apologize if this behavior is not your responsibility. I do need my app to reproduce music when the screen is locked, this is one of the last milestones to get it done. I would be extremely grateful if you helped me finding a solution. Thanks in advance. Greetings

Please read at least the first 3 sentences of the README.

Also in future, please read and follow the instructions in the first section of the bug report carefully.

dankydev commented 3 years ago

1) I read the first 3 sentences, i'm not blind. I specified the method name and how it behaved: what's the point? 2) Since i don't precisely know how just_audio is internally made, i'm reporting an issue here knowing it could be a problem of a third-part library, i've even apologized for that. Next time i won't disturb, or i will directly use another plugin. 3) I managed to solve it by myself, and the problem was not related to just_audio, so i still apologize for wasting your time.

For anyone interested, i report here the solution i found: https://pastebin.com/8rpMyBNS

ryanheise commented 3 years ago
  1. I read the first 3 sentences, i'm not blind. I specified the method name and how it behaved: what's the point?

Please understand that there are many genuine bugs that I need to sort through and fix, and it keeps me extremely busy. If you think you have found a bug, you did the right thing by clicking through to the bug report template, but I have put certain instructions in the bug report template specifically to help me cope with the large number of issues I have in the backlog. They are intended to serve as almost as a check list for the submitted to first establish that it can be classified as a bug (i.e. where the plugin didn't do what the documentation said it would do.)

In this case, the point of the first section of the bug report is not to describe how a method behaves, but rather to explain how that behaviour is "different" from the intended/documented behaviour, and this is necessary to establish that it is a bug, as opposed to it not working the way you personally would like. Ultimately, the plugin is only supposed to work as documented. The only documentation anywhere in this plugin that pertains to what happens when the app is not in the foreground is in the first 3 sentences of the README (i.e. audio_service), so you would need to point to that relevant documentation and explain how you have done what the documentation said in sentence 3 but it still didn't behave as expected, otherwise I would consider this as not a bug (which in fact it is not). So that is the purpose of those instructions. I appreciate that you are willing to submit a bug report, although in future, please ensure that you go through the checklist to ensure that the behaviour you wanted was actually intended behaviour.

For anyone interested, i report here the solution i found: https://pastebin.com/8rpMyBNS

This is not a complete solution because apps are not allowed to keep running in the background after a certain amount of time has elapsed, and so a foreground service is required, which is provided by audio_service, cited in the 3rd sentence of the README file. If you already used audio_service according to its instructions but it failed to maintain the background execution context, then that is a bug in audio_service, and I would encourage to lodge a bug with that project, but it is not clear to me from the present bug report that you actually used audio_service as per sentence 3 of the README. Did you?

dankydev commented 3 years ago

This is not a complete solution because apps are not allowed to keep running in the background after a certain amount of time has elapsed, and so a foreground service is required, which is provided by audio_service, cited in the 3rd sentence of the README file. If you already used audio_service according to its instructions but it failed to maintain the background execution context, then that is a bug in audio_service, and I would encourage to lodge a bug with that project, but it is not clear to me from the present bug report that you actually used audio_service as per sentence 3 of the README. Did you?

Yes, the application implements the latest version of audio_service (0.15.1), and now it seems to work fine with the battery optimization fix i reported. I'll make several tests running the player for long periods, to be sure there are no problems with audio_service. If the error persists, i'll open an issue on that repository. Thanks for your help, i'll make you know.

dankydev commented 3 years ago

This is not a complete solution because apps are not allowed to keep running in the background after a certain amount of time has elapsed, and so a foreground service is required, which is provided by audio_service, cited in the 3rd sentence of the README file. If you already used audio_service according to its instructions but it failed to maintain the background execution context, then that is a bug in audio_service, and I would encourage to lodge a bug with that project, but it is not clear to me from the present bug report that you actually used audio_service as per sentence 3 of the README. Did you?

So, i did many tests and the fix seems to work well. Anyway, i've posted a question on Stackoverflow regarding audio_service, since it's not certain to be a bug. You can find it here: https://stackoverflow.com/questions/64401540/audio-service-need-to-ignore-battery-optimizations-to-keep-the-background-servi

ryanheise commented 3 years ago

Hi @dankydev I would still consider this a likely bug in audio_service, and would recommend submitting a bug report on that project. If you submit a bug report with a minimal reproduction project, reproduction steps and device info, it will be possible for me to investigate.

github-actions[bot] commented 2 years ago

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs, or use StackOverflow if you need help with just_audio.