Music-Player-GO
Music-Player-GO copied to clipboard
enricocid
[FR] Storage capabilities (delete, tags, share...)
What feature would you like to see?
- [ ] Ability to delete songs (#473)
- [ ] Ability to modify songs tags
- [ ] Ability to modify songs filename (#470)
- [ ] Share
- [ ] Scan specific folders (see #48 by @angryseptagon)
- [ ] Solve "Second space" issues on Xiaomi phones (see #377 by @codebreaker332)
- [ ] Solve "Open with" issues (see #303 by @ItsIgnacioPortal)
- [ ] Show folders hierarchy (see #457 by @sojusnik
What kind of level is this feature request?
Advanced, a nightmare!
More info
The original @Friptick request:
Please add a delete button somewhere (anywhere!) to delete the track from disk (not just from the queue).
This is a super useful feature when listening to podcasts. If one is using Music Player Go for podcasts (maybe unusual, but I am), then the files are likely being synced or copied. Unlike music, you typically listen to podcast episodes once, then you get rid of them. (Not enough space on mobile devices to let them pile up.)
Right now, you can browse the files in Music Player Go, you can listen to them, you can change the playback speed (a podcast feature which almost no other music players have), but you can't banish them once finished. You need to go into a separate file manager and hunt around to identify the file in order to delete it. Very frustrating.
I have tried every possible music player, and this is the best one for podcasts. All that's missing is this tiny but magic feature!
Thanks for considering, and thanks for your work.
Code of Conduct
- [X] I agree to follow this project's Code of Conduct
Just to let you know @enricocid, this kind of feature is nearly impossible on modern android. You either need to roll back the target SDK or use this maze of flaky APIs filled with restrictions that are nominally meant for "privacy" but in reality are meant to discourage you from doing it in the first place.
Yeah, storage management is pure madness. I'd probably end up increasing crashes statistics to +5000% or more. 🤣
From this exchange I deduce that there is not much chance of this feature happening. If so, perhaps just say so and delete the request.
I must admit, as a non-Android dev I'm having trouble seeing how this can be such an issue. Any file manager app can delete a file permanently with immediate effect. For example, Simple File Manager can, with no crashes at all. Yet Music Player Go and Simple Music Player both have this phantom-file issue. To reproduce:
- "delete" the file in Simple Music Player (which has a delete button), and observe that it is gone in Music Player Go too
- open Simple File Manager - the file is still there!
- now open SMP or MPG again - the "deleted" file has come back from the dead!
So this must mean it is a sync issue with the media database, as you hint.
What I don't get: why can't you just use whatever system call Simple File Manager uses? I.e., "delete this from the disk right now", then tell MediaStore to rescan the disk?
If it's any help, I can confirm that Phonograph can do it. It has a delete button that works. Unfortunately it doesn't have adjustable playback speed, which is a dealbreaker for spoken-word audio.
Right now, to consume offline podcasts (i.e., ephemeral "listen-once-only" audio) on Android, you basically need two apps. So frustrating but thanks anyway.
Yeah, but phonograph is not scoped storage compliant.
It actually uses an option to opt out scoped storage.
In fact, it goes only up to android 10 and the latest commit is dated September 2020.
Unfortunately there are a lot of storage behavior changes to take into account across all the major android releases and many implementations/solutions/APIs you find are kinda hacky.
Just have a look at the complexity of this open source file manager.
https://github.com/zhanghai/MaterialFiles
File managers are usually premium apps developed by software houses or teams (mpgo is a one-man-show) or expert devs leading a small team who not only have a job as android developers/eng but are supported by the community.
Advanced music players too are premium apps with milion of downloads...
As I already said to another user I will probably try to implement this functionality limited to android 10 and above, but consider this is a time consuming one and I have a job so...
Sorry.
I also want to add that Material Files gets around storage limitations by rolling back their SDK to API 29 (Android 9!) and hacking in new SDK features like dynamic coloring. This is really not desirable for apps that want to stay up to date and not face an increasingly restrictive compatibility sandbox.
As for automatic scanning, this is also a bit of a weird feature since you can't just recieve a broadcast and have to keep some callback around to detect updates, which if you know the state of background work on android is not ideal in the slightest. It is still feasible though, and I've been wanting to work on a modern implementation of something like that.
Generally, if you want the best UX, and if you don't have a whole team of devs willing to work around every quirk and OEM issue, you'll want to just make a media app read-only. Don't blame us. It's really google encouraging this, as they want nothing more than to kill the filesystem and turn every app into an iOS-style data funnel to a far away server.
Had experienced storage madness a while ago working on a gallery. Simple tasks require a lot of complexity and file system APIs are often inconsistent with each other. As You said, it is really difficult to ensure compatibility across all android versions and OEM. If you don't deal with this properly you'll 110% get a shitty UX, i.e. lot of crashes/ANR and user complaints.
FRAGMENTATION...
Google devs are actually working on a new library, namely ModernStorage, to simplify file system interactions. The library is still experimental and lacks many features. Hopefully they will add support for files deletion (even though I think NOT: scoped storage changes are meant to discourage devs to interact with files other than the app-specific ones... they will probably focus on mediatore and pickers)...
At least google is doing something. Of course, in typical google fashion, they paper over the terrible nature of their APIs with some compat library and then say "Look! Fixed!" while completely ignoring the actual problem. See: RemoteViews/AppWidgets, Database Management, The myriad of MediaStore metadata issues, Background work, etc. etc. etc.
OK thanks for the explanation. So it's a symptom of Google's creeping privatization of Android. Makes sense, sadly.
In strategic terms, for a media app not to be able to do file operations, that does seem like a pretty alarming situation to be in. Perhaps it's time for AOSP to fork definitively from Googleware Android.
OK thanks for the explanation. So it's a symptom of Google's creeping privatization of Android. Makes sense, sadly.
In strategic terms, for a media app not to be able to do file operations, that does seem like a pretty alarming situation to be in. Perhaps it's time for AOSP to fork definitively from Googleware Android.
I'm considering using MediaStore/content resolver to do so, and to limit the feat. to Android 10 and above. :)
PS technically it is possible, the real challenge here is to write reliable code that works on multiple android versions (8+)/OEMs (they usually introduce framework customizations ...). Pretty impossible given the state of art. 💩
From this exchange I deduce that there is not much chance of this feature happening. If so, perhaps just say so and delete the request.
I must admit, as a non-Android dev I'm having trouble seeing how this can be such an issue. Any file manager app can delete a file permanently with immediate effect. For example, Simple File Manager can, with no crashes at all. Yet Music Player Go and Simple Music Player both have this phantom-file issue. To reproduce:
- "delete" the file in Simple Music Player (which has a delete button), and observe that it is gone in Music Player Go too
- open Simple File Manager - the file is still there!
- now open SMP or MPG again - the "deleted" file has come back from the dead!
So this must mean it is a sync issue with the media database, as you hint.
What I don't get: why can't you just use whatever system call Simple File Manager uses? I.e., "delete this from the disk right now", then tell MediaStore to rescan the disk?
If it's any help, I can confirm that Phonograph can do it. It has a delete button that works. Unfortunately it doesn't have adjustable playback speed, which is a dealbreaker for spoken-word audio.
Right now, to consume offline podcasts (i.e., ephemeral "listen-once-only" audio) on Android, you basically need two apps. So frustrating but thanks anyway.
Its not comfortable like its tiring to find the song and every other music player has this
"Every other music player" usually means:
- A music player with multiple developers that can work around every single quirk and issue.
- A music player that has not been updated in years and operates in a compatibility sandbox.
We aren't in either of those categories.
We aren't in either of those categories.
Exactly. Quality and stability first.
For info, I've been using Metro app by MuntashirAkon (apparently a libre fork of RetroMusicPlayer).
It has the usual two views, "Songs" and "Files". And on every song there is a "Delete from device" menu option. This does what it says and no more.
In parallel, I have a separate F-Droid app SD Scanner. It has one button, which syncs the MediaStore.
What I still don't get is why it is so hard to to provide a Delete from device button that just does an SD rescan. The operation only takes a second if scoped to the directory (SD Scanner can do this). Maybe you see it as too brutal or inelegant? But even as a hidden setting it would be soooo useful.
Being able, from the song view, to reliably get rid of "flow content" like podcasts (as opposed to listen-again-and-again "stock content" like music) is just a game-changer in terms of UX.
Thanks for reading and for your work.
(Android 9 here BTW. Works fine, really reluctant to spend a fortune and damage the Earth just for 2 extra features.)
Just had a look at the SAF implementation of Metro and I find it very confusing and prone to error. I (yeah, I'm the team) don't want to waste my time dealing with fragmentation, fixing errors/ANRs and users complaints.
SD scanner latest version is dated 2017. Most of the methods used to force MediaStore to update its records are now deprecated and possibly not available/working on recent/all android versions/devices supported.
For all others developers, those using the magic
android:requestLegacyExternalStorage="true"
in their manifest.
There will be a time when they'll not be able to post updates to their apps until they will adapt to scoped storage changes or remove these features...
Most of them have already abandoned their projects. Our projects are still alive instead
Google is working on a new library to help developers to better/easily interact with storage. It is still a wip and many features are still missing. I'm just waiting for it...
Well thanks a bunch for dashing my hopes AGAIN :)
just joking. I do appreciate the explanation, your dilemma is making a bit more sense. Might as well do things the official way if it makes your app more future-proof.
Given that file deletion is looking impossible (good reasons, see above), what's the end game for your app here? I'm struggling to imagine the implications of preventing apps from doing basic file operations. "Read-only audio player" feels like "read-only text editor". What does Google want independent apps to do, exactly, going forward? Just play some kind of black-box playlist streamed from Google servers or something? Will you then be hired as a Google employee? Surely all this cannot end well for Android if it claims to be a proper OS.
In practical terms, I'm trying to imagine workarounds. At some point there needs to be a level of abstraction for getting rid of content, especially for the ephemeral podcast workflow. The problem is that the "remove from playlist" paradigm doesn't apply here: with ephemeral content you need to actually remove the files or you'll quickly run out of space.
One solution would be to "mark" the files somehow, and then follow up by deleting the marked files elsewhere. Somehow. But I guess if you can't delete them you won't be able to flag them or modify them either.
Another idea would be to share files one-by-one with an app dedicated to file operations, a file manager basically, which can then delete them or whatever, reliably.
What a PITA.
I guess the underlying situation is that big tech doesn't want us to worry about these things called "files" at all any more. It's too complex for us. We should just tell them what we want and they'll give us what's best for us.
Infuriating. This shit is making me question everything, up to and including getting rid of Android and even the toy it's installed on.
You hit the nail on the head. Music that you own hurts google's bottom line. They want you to be a good consoomer and listen to your AlgoPop StreamMix™ from some far away server that they control.
Everything they have done in the past few years, from gimping services, to scoped storage, to the new partition model, to (likely) fuschia, all of it is meant to turn android into an iOS-like sandbox and make every dev maintaining an app using local storage to quit.
Time to think about another future with a genuine FOSS mobile OS? Plasma and friends?
Big challenge, I know. Means giving up a bunch of locked-down things like social, banking, NFC and so on. Mass adoption will never follow.
But this can't go on.
I see a terrible parallel with podcasting, actually. Somehow it's stayed free right up till today. Still based on open RSS files! Nobody has managed to lock it down - YET. Well, I just cannot see this situation lasting. Now podcasting has gone mainstream, there's just too much money at stake. And then what? It will go the way of music streaming and ebooks. To listen to anything popular will mean using spyware on a tethered device. It's coming. It must be.
But somehow it hasn't happened yet so I am savoring the time it lasts. And perhaps daring to dream, just a bit, that I've got this all wrong and a better future is possible.