[Feature Request] Close track player and remove from notifications

[arthurgeron-work]

What is the need and use case of this feature?
When a user is playing a content through other means (e.g. a ultra low latency stream using aws's react-native player) it's misleading to show media controls in the notification center.

Describe the ideal solution
A clear and concise description of what you want to happen.
Having a clear method to close and remove track player from notification center, which would then open again if "setup" is called. Better still would be if I could pass an argument during it's initial setup so that it'd automatically close if nothing is being streamed/played.

[jspizziri]

@arthurgeron-work please see this option https://react-native-track-player.js.org/docs/api/objects/android-options

[arthurgeron-work]

@arthurgeron-work please see this option https://react-native-track-player.js.org/docs/api/objects/android-options

That API refers to a Android specific event based behaviour which depends on the app being killed, not a cross-platform on-demand solution (e.g. triggered via a JS method exported by the lib) or a behavior based on empty tracks queue as described.

[jspizziri]

In that case please see this feature request #1786 its also possible reset is something you're looking for.

But I don't think I know what you're trying to achieve. Are you trying to use this library as a way to headlessly control expoplayer being initialized in another app? That's not really what this project is designed to do. I'm not sure what the reference to AWS's native player means. I think I'm missing a link here.

[arthurgeron-work]

In that case please see this feature request #1786 its also possible reset is something you're looking for.

But I don't think I know what you're trying to achieve. Are you trying to use this library as a way to headlessly control expoplayer being initialized in another app? That's not really what this project is designed to do. I'm not sure what the reference to AWS's native player means. I think I'm missing a link here.

Yes, headless play of content was the intended use, the confusion here is that the lib we previously used, react-native-music-control, had that feature but was incompatible with android sdk 30+ (forcing us to migrate to another solution), that lib's readme tells devs to "use this lib instead" and neither lib's readme files mentions the change in how headless play is supported. Maybe it'd be interesting to add that to the read me file.

Regarding the play/stop and forgetting about mixing other concepts (like ivs), the issue is that customers find deeply annoying to have a empty lockscreen player that can't be closed, specially for background apps that might stay running, which ultimately leads to the user being induced to always kill the app after playing some media content. Summing up, it'd be really nice if I could programatically remove the player from the notification center, or have it do that automatically when the track queue is empty.

Reset only cleans the state but keeps the player in the notifications, as far as I understood about the stop in #1786 it doesn't intend in doing that either:

In general we don't want the lockscreen players to be removed after calling stop(), since we would want to allow the user to hit play again.

[jspizziri]

@arthurgeron-work this project does support headless control/playback. However, it's all based around controlling playback for tracks and audio that are managed by the library itself, not for generic purposes of controlling exoplayer/avplayer headlessly.

Regarding having something that programmatically removes the notification, I agree with that usecase. My intuition is that stop and/or reset (one of the two) would be the appropriate place to handle something like this. With all of that said the following would be needed:

1. Feedback/approval from the below individuals.
2. Someone willing to do the implementation.

I'm going to add this issue to the issue backlog now that I understand the desire and use case. This is where all feature requests go that we'd like to get to eventually but aren't actively being worked on.

@dcvz @puckey I'd be interested if you have thoughts or a preference on the following:

stop() should also remove the mediaplayer notification from Android/iOS.

[arthurgeron-work]

@jspizziri

Sounds great, I appreciate it! That being the case I believe this issue should be left open right?

[martinivanalfonso]

clearNowPlayingMetadata() successfully hides the notification on iOS and Android.

It does have an interesting issue (#1653), however by programatically calling updateNowPlayingMetadata() right after play() you are able to fully control the notification at all times which is what this issue is about.

I don't think deprecating (#1909) clearNowPlayingMetadata was a good idea, maybe backtracking on that and fixing (#1653) will help solve this issue?