Adding folders as playlist

[Akendo]

Hello I would like to add a folder as a part of the playlist. I wasn't able to do so, maybe I missed it. Else I like to have something like this. I like to add all of my music at once so it should be possible to add the basic folder as well.

Best regards 4k3nd0

[tilboerner]

Hi Akendo,

there's a feature close to what you want: in the Tracks part of the listing, there's a button to [add all tracks to current playlist]. You'll have to open the folder (aka "collection") first, though, and there have to be tracks in it.

I guess now the question is: should there be a way to add a Collection to a playlist? And since a Collection is a directory which can contain other directories... what exactly would be added?

[Akendo]

I do remember this button, but I had no one on the basic folder. Getting all files at once into a playlist would mean: Go to each Collection and add them by hand, that take way to long on time.

At least what I saw, maybe I missed something. But thanks for your fast responses.

best regards 4k3nd0

[tilboerner]

So, in other words, there should be a way to add all tracks in the folder you're currently viewing and all its subfolders, and their subfolders, and so on? That's potentially a humongous list. :whale2: Approximately how many tracks are we talking about, in your case?

Or do you simply want a playlist containing all the tracks in your collection? That's a special case of the more general feature above, but could be handled in a very different way.

[Akendo]

Right now I have around 510 Element's within the folder, I like to add all containing files of the collection to a playlist. That was what I imaging.

This was one test case for me, the next one will be with some more ;-). 12580 should be in the end.

[tilboerner]

Oy, I started mixing up terms again. To be clear:

all containing files of the collection

means all the files Cherrymusic knows about, right?

In general, having fixed playlists with thousands or even hundreds of items is A Bad Idea. There are a number of reasons for this, which I might elaborate on another day. ;) For the kind of thing you have in mind, it would be better to have something like smart playlists :tm:, or smart items that can be put into playlists, which figure out what to play based on some sort of filter.

[Akendo]

Yes Cherrymusic does know of them.

I would love to hear the reason for the playlist issue, a link would help me as well. Where would be the limit? I just one have something simple. Maybe it's possible to create a playlist of playlists.

[tilboerner]

Here are some reasons against large playlists, off the top of my head:

• CherryMusic implementation: loading a playlist from the server incurs additional data requests to the server, proportionally to the playlist size;
• web client performance: a playlist is always loaded completely, which means that all its data goes into the browser's memory, and for every playlist element HTML is generated and displayed;
• human manageability: trying to manage a huge list visually, without programmatic access, is bound to be painful;
• mangling of concepts: at least in my mind, a playlist is a somewhat limited selection of tracks that are supposed to play together; it's not a set of tracks that might get played if you wait long enough.

There's no hard limit to playlist size. The actual limit depends on things like available resources (for server and client device), the network bandwidth and your patience.

Maybe it's possible to create a playlist of playlists.

It's possible, but not likely to happen. We decided it introduces way too many complications for not enough benefit.

All in all, it seems to me as if some smart mechanism which decides what to play next would be more in line with what you'd like to have. Such a thing would be a great feature, anyway, because it's bound to have many uses that I can't even think of right now. :heart_eyes_cat:

[Akendo]

Thank you for this detailed review. Maybe it would be possible to add the function of play all? Rather then creating a playlist of this or would this create similar issues?

[marky1991]

I don't think maneagability is a valid concern. When you have a huge playlist, generally the idea is "I don't care about one particular song, so I don't plan on looking anyway" but even if you did want to look for one particular song, it's trivial to use the search bar. It's not painful at all in my opinion.

I don't think the last point is a fair criticism unless you plan on providing a concept that will serve to replace it. I don't think that I personally have ever had a collection of media files that specifically belong together and have to all be played together, but I've quite often (i.e. every time I use it) considered a playlist as a collection of media files that I want to hear for now. (If I close out before I hear them all, that's okay too)

I don't really see how recursive song collection is an issue. You could include a user-defined max playlist size (with some reasonable default) so if you hit the max length, you simply stop recursing and return what you've got so far. In most cases, you won't hit the length requirement and all will be well. When you do, you return what you can. The idea of recursion is independent of a large list. You can have a flat folder with millions of songs and cherrymusic will happily (try to) add them all to your playlist.

[tilboerner]

@marky1991, thanks for your input! I'll address the individual points, but let's start at the end. :)

I don't really see how recursive song collection is an issue. You could include a user-defined max playlist size...

Absolutely, but it kind of breaks the concept of "add all". If you intend to create a playlist from all of This Stuff Right Here, what's the point if some of that stuff is left out? You can't even control which of the stuff you end up with. That goes for flat folders, as well.

I think it comes down to there being different concepts, as I hinted in that last point above.

When CherryMusic was created, a playlist was meant to be an ordered set of tracks that should play together, with a size that's easy to grasp, manage and listen to in one go. Kind of like an extension of the album concept, but customizable, and not limited to the capacity of one CD. Order plays a role here, as does manageability. The implementation was done accordingly, with that concept in mind. Why? Because it fit the way we were using our music.

Turns out this concept is too limited. What if you want to pick a certain subset from all the music, to serve as a pool for tracks to be played from, maybe in no particular order? You could call that a playlist as well, but it's different from how CherryMusic understands the term. So, for the sake of clarity, let's call them pools for the moment.

Anyway, it would be really neat if we could have pools like that. If you want to add a huge amount of stuff to a playlist, you really want to create a "pool" and not a "playlist" that gets capped at some arbitrary point. Heck, I want to have a feature like that!

There are two things we could do at this point:

1. Allow recursive adding of tracks and put an upper limit on playlist length. That's the easier option, but it tries to cram a pool into a playlist and will therefore leak in all sorts of ways.
2. Introduce a new feature to implement this concept of pooling. Way to go! We could do some very cool stuff then. We've been thinking about having "smart playlist items" for a while now, which would be a way to go about this. It will take much more time and effort, though.

We might even do :one: first, followed by :two:. Before, though, some more opinions?

[6arms1leg]

i agree with @tilboerner. :+1: the pool concept is a neat idea, i would go for that. personally, i dont need that feature though. also, we should always keep in mind, that cherrymusic was designed for huge music collections. for such a setup, adding all tracks of the collection to a single playlist would be pointless and mad.

[Akendo]

I agree with :two: : :+1: , I like to have a pool of all my music in the moment. Wish I had more insight of CherryMusic, but time doesn't allow this to me.

But many Thanks for your feedback.

[devsnd]

First of all, I'm glad so many people contribute to this discussion of where CM should go in the future!

But I have to be clear about :one:: I don't like that idea. It reveals an opaque layer of implementation specific limitiations to the user. We just had that problem in #389, where it wasn't clear why some folder would be presented as "compact listing", while another does not. I don't want to make the same mistake twice, even though I think that compact listing is still the only feasable way to solve the problem of huge music libraries.

In regard to :two:: Implementation wise, I think we should start to implement something like a meta track. A meta track replaces itself with a real track once the user requests it being played. in this way, we could implement different kinds of meta tracks, which e.g. choose a random file from the library or a file recursively from a specific subfolder. This means we could implement both random playlists and possibly infinitly recursing playlists, without needing to preload anything. Furthermore we don't need to introduce the concept of pools (as something diffent to a playlist), even though I like the term. Maybe we should call them lazy tracks, because meta is such a broad term.

EDIT: i forgot the obligatory emoticon. :walking:

[tilboerner]

we should start to implement something like a meta track. A meta track replaces itself with a real track once the user requests it being played.

Yeah, that's what I was thinking about the whole time. Except for one detail: When requested, the "meta track" comes up with a real track that gets inserted before it. This can happen more than once. If there are no more real tracks, the meta track disappears. That way a proper playlist is generated within the Queue, from a possibly infinite pool, :) with working previous and next. We still might want to limit playlist size and eliminate tracks from its beginning when a playlist gets too large.

So, it's not really a track after all, but a track generator or pool or whatever name we want to give it. There's lots more to talk about, anyway. :octopus:

This is gonna be great fun I'm sure, but I think we should work on the RESTful API first. :speak_no_evil:

[devsnd]

We still might want to limit playlist size and eliminate tracks from its beginning when a playlist gets too large.

I don't think so. Any user knows how stuff like this works. If cherrymusic becomes unresponsive after listening to a random playlist for 36 hours people will understand. I have some analogy about transporting chicken on bicycles in my head... well, i guess you now what i mean. :chicken: :bike:

This is gonna be great fun I'm sure, but I think we should work on the RESTful API first.

:+1:

[tilboerner]

If cherrymusic becomes unresponsive after listening to a random playlist for 36 hours people will understand.

In my opinion, people shouldn't need to understand, because CherryMusic shouldn't become unresponsive. I understand that my printer runs out of paper occasionally, but I prefer it wouldn't. If there's an easy fix, we should try to find and use it.

Mind that we can probably get rid of "playingPlaylists" with this feature. If there's only the Queue, it could have a (large) upper limit on size.

But this is a discussion we can have later, I suppose. ^^

[vext01]

I would also like the ability to add songs and all songs in sub-directories recursively.

Thanks

[Suika]

As the topic started with adding folders, jQuery UI has a nice function that is Droppable: https://jqueryui.com/droppable using the revert option and that would be it. I mean it's also possible to do it with jQuery Mobile

[devsnd]

add songs and all songs in sub-directories recursively.

This functionality has been implemented in the lazytrack branch of CM. see: 2b10760

It still needs cleanup and isn't really performing so great and is possibly bug-ridden, so enjoy responsibly! :beers:

[Akendo]

Gosh! Awesome!

[bagage]

Any chance this branch goes merged in devel/mastersomeday? If not I should start compiling it by myself, but otherwise I will be glad to wait a bit :-).

[j0ack]

It would be great to be able to drag and drop a folder directly in the playlist to add recursively songs in the playlist instead of using the "Add all recursively" button.

Should I open a new feature for this or is it a part of this one ?

Then I would like to contribute to CM development but don't really know how to begin. Any hints or suggestions are welcome.

[6arms1leg]

Hello @j0ack,

great to hear that you would like to contribute -- it's much appreciated! If you would like to add a new feature (e.g. the drag and drop functionality you mentioned for the file browser), but don't know where to start, I recommend to combine both in a new issue. Have a look at #500, for example. This way, we can give you the specific information you need to get you started. For basics and general information, please head over to our wiki. Maybe you will already find there all the information you need. Have fun! :confetti_ball:

[j0ack]

Thank you @6arms1leg I will open a new feature then to have specific information and propose my help.

[tilboerner]

Hi @bagage, sorry for the late reply!

Any chance this branch goes merged in devel/master someday?

There's definitively a chance, but I think neither @devsnd nor I will have the time for it in the near future. Have a look at #522, though. :) If you're interested, maybe talk to @j0ack if you guys want to team up?