-
-
Notifications
You must be signed in to change notification settings - Fork 140
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Playlists #36
Comments
this would be great, +1. |
This will be added, however the flow with importing m3u files yet is not certain. |
I didn't know where to post feedback but this app is fantastic, really the only reason I can't use it is because of playlists. once that's added this will be the best music app. looking forward to it! |
Glad you like the app @ludificorpayne, this feature is still a ways away though. I want to make the current music experience as good as possible before I go ahead with such a complex addition. Rushing a half-baked playlist feature just to be like Phonograph/Retro/Vanilla just isn't right. |
Could you elaborate on this?
So we would be "liking" songs in the app, would it be implemented with a bool, or a star system? |
The former, not the latter. I have no idea how a filter-based addition system would work.
More like a playlist of songs that you "liked" in-app. |
In players like iTunes, and some versions of Foobar2000 the user can specify a database query whose results are saved as a playlist and updated automatically as the library evolves over time. In iTunes they were called "Smart Playlists". |
this would be extremly cool but i imagine also technically really complex and pain to implement. i would be 100% for it tho. |
I was always going to go for SQLite, which is standard for android. While technically it's better to use Room, I've found that it increases compile times by ~3 times and has this weird issue where old database items are never removed, so I just use the more verbose method. Thanks for the images by the way. Something like this would be an extremely far off feature however. I'd imagine that implementing the built-in Liked Songs playlist would allow me to at least have a framework for query-based playlists, however I feel like exposing it in the UI would be the largest problem, as it requires a ton of options and is probably really hard to cram intp a phone screen. If I were to guess what my roadmap is for Auxio right now, it would be something like:
|
I am very sorry this feature is taking very long to implement. It's easily one of the most technically challenging systems I've worked on, and I don't want to deliver a half-baked implementation for the sake of implementing playlists quickly. I don't really have an ETA on when I'll implement it. |
by me, take your time. I see there are a lot more technical things that have to be tackled for auxio to have a solid playback experience. I am ok to wait for this feature, because i know once it does come out it will already be solid and usable. |
Okay, I had the realization that much of the technical complexity of playists comes from liked songs, and not from playlists themselves. This is because liked songs are sort of a hybrid between library attributes and playlists, and I need to find a way I can implement them without really bad efficiency issues. I think I'll try to deliver a MVP of playlists first and then push liked songs further into the future. |
very nice! i'd like if playlists had in mind the m3u workflow (importing and refreshing from .m3u and .m3u8 files) from the start, rather than be an afterthought. |
Yeah, M3U import and export will be implemented, but playlists themselves won't be backed by M3U instances. This is because google has deprecated the |
good good. well i didn't quite mean "backed up" as in constatnly synced to the m3u files, but if you could just remember where the m3u file was located in storage, and give the user an option to "refresh" the playlist by internally re-importing it. again, this is not a feature that needs to come from the start with playlists, just something to keep in mind so as to not be impossible to add once the whole system is implemented. |
That requires the playlists database, which is deprecated. Besides, I really don't want to back playlists with someone as unstable and spec-dependent as a M3U file. An internal database with import and export is much easier to implement without android screeching at me. |
how do you mean? can't you just make a button that does the filesystem call to read and parse the m3u file again, overwriting the current playlist? basically just same as the import but without the need of selecting the path (to save time & also because you already have the path from first import) you do not have to sync up or do whatever with the playlist after, the whole point is so "refreshing" a playlists (or multiple) doesent take extremly long |
Oh, okay. That makes more sense. That was already what I was planning from my playlist system. |
I think the last blocker for this should be #202. Playlists must use Auxio IDs, but the ID system really needs to be reworked to become more formalized, backwards-compatible, and reliable. Adding support for MusicBrainz IDs in particular will allow users to avoid a behavior where changing a song's metadata causes Auxio to "forget" it, which would be terrible for playlist functionality. |
I have tested the debug apk as of today and could see a playlist. Where do the content of the playlist come from? I only ask, because I have exported a m3u file from within Strawberry on Linux with 600 songs and relative paths. Most other media players can use this playlist and I have all 600 songs in the specified sorting. I think Auxio don't use this as of now, since the current implementation use some internal playlist and I see only 43 files in the implementation. If my wish will be supported in a later version, im fine with that. Also any other format with relative paths is welcome, as long as Strawberry can create it. I will keep an eye on this feature. |
I've only implemented playlists in the UI, everything else currently is "junk" data for testing. I will be busy for the next month and a half and will likely be unable to work further on playlists until then. |
atleast you can see how happy people are about this feature coming to the app 😁😁 |
Yes, its the only feature i really miss. Away from that, this is by far the best player, including commercial players. |
So happy to see progress in this. I really can't express my respect to Alex for spending time on this ever missing feature besides every other thing in his life. Wishing great success to you, brother. ❤️ |
Came here to comment on playlist, which I saw missing. Hope in 2023 this feature comes into action. Love the project. Thank you. |
output.mp4 |
awesome! have a version to test?
|
The latest CI build should have this functionality @ildar. It's just missing playlist editing, persistence, and has a ton of rough edges. |
Ah! tested that. Works nicely. Just needs to get to some "stable" point.
I'd say, the minimal list of features to be added:
1. Ability to delete a playlist
2. Ability to delete an item.
With the above you can release then add more features like moving items in
a list etc.
Just my IMHO. Thanks for your efforts!
|
All of that is planned before release @ildar. My hope is that I'll be able to trivially port the queue editing system to the playlist view and implement song deletion and re-ordering in parallel. |
All fundamental playlist editing is now done. output.mp4Remaining work is now polishing the existing implementation. Song editing in particular should look a lot better in final release. |
Playlists are now done. Download Auxio_Canary.zip to access the functionality early and bugtest it. Note that it is a debug build, so it will be noticeably more sluggish than normal. This will not be present in release. Note that the initial playlist release does not include the following:
Additionally: Please refer to the bug report process if you find an issue. Simply saying there's a crash is not enough to help me fix issues. A 3.1.0 release is expected soon as I can do some minor fixes/changes. @foss- @ildar @KraXen72 @Donkey-Doug @amalka-ari @jethi @illdeletethis @madenerrgy @projjalm @PranavBhattarai |
https://bin.kv2.dev/~6469b4bee599576ea02c75e3 Latest CI sometimes crashes when I'm adding track to the playlist. But overall everything works great! 2_5427290571246939666.mp4 |
New APK, hopefully with the fixes for @madenerrgy's bug. |
Oh, thank you so much pro! It only remains to work on the friezes when opening and animation .. 2_5427290571246940382.mp4 |
The former is because of the debug build slowing down the amount of layouts. I do agree more animation for playlist editing would be good, but I'm holding on that until I can nail a good framework for that (Eye candy is frustratingly buggy on android). Expect that in a 3.2.0 release, which I'm planning to have a bunch of mild UX improvements. @madenerrgy |
Got it, thanks for your efforts :) |
im missing the functionality to quickly add new songs from a newly created playlist. i understand the intended workflow is that you search for a song and add it from there, however, it's unintuitive to be left with a blank screen after creating a new playlist. |
That's one of the features I'm leaving for another release, honestly @KraXen72. Far too easy to mess up.
That should not be happening @illdeletethis, and I can't reproduce it in the release build. Does it persist after completely force stopping and starting the app? |
yes, force stop fixed it 🙂 |
The current plan for playlists is a self-contained database with optional M4A exporting.
Auxio's playlist implementation will have:
Last added/top tracks don't benefit my usage, so they will be omitted.
The biggest hold-up with this feature is the sheer technical difficulty of it. Playlisting is far more complicated than it seems internally, especially when you want a bug-free implementation.
The text was updated successfully, but these errors were encountered: