Completed Public and private playlists

[Anielarias 23]

23 minutes ago, cayars said:

Yes

what is the eta?

[Carlo 4330]

I can't say other than it's on the radar.  I'll refer you to:

On 11/12/2022 at 1:12 AM, Anielarias said:

am running the beta but i dont see this option, what is the ETA for this to be avalible? And thank you. 

On 11/12/2022 at 10:12 PM, Luke said:

It will be in the beta channel in the near future. Thanks.

and

On 3/9/2023 at 6:59 PM, Luke said:

Has anyone used collaborative playlists on Spotify? That seems to be a good model to look at, although in our case you'll just be checking off users that are already in the system, not inviting over email.

Luke already said a few months back it would be in the beta channel in the near future.  So that tells you we're committed to it. You can see Luke asking specific questions and talking about models of systems that did this pretty well.

I think that's enough to say it's getting closer to beta and a lot of thought has been put into how to handle permissions and access rights.  The problem in general with giving an ETA is development could switch on a dime to something else for some unknown reason.  If you say you're going to do X but have to call an audible and Y gets done instead, it gets some people upset and just causes turmoil. So instead of trying to guess at an ETA, how about we say we want it to be a reality sooner than later and advice you to watch the next set of betas that will become the next version of Emby Server.

BTW, that doesn't mean it will be in the first or second beta release of the cycle as we might want focus on testing on some other things first. We often focus beta releases on specific things to test especially if it's a foundational part of what will be built on. With that said Luke already said it will be in the beta channel in the near future so that's a pretty strong indication we plan on it being in the next Server release. 

Again, anything could happen that would force us to change focus temporarily for the first couple beta releases, but it should be clear the intention is to get it into the release sooner than later.

Carlo

[Anielarias 23]

is there a place where i can keep an aye on upcoming features including this one? 

Edited March 12, 2023 by Anielarias

[Junglejim 351]

6 minutes ago, Anielarias said:

is there a place where i can keep an aye on upcoming features including this one? 

Try here https://emby.media/community/index.php?/topic/21348-emby-latest-versions/ ...  Beta release notes.

It gets updated with each beta release with the newer stuff at the top.

[Anielarias 23]

36 minutes ago, Junglejim said:

Try here https://emby.media/community/index.php?/topic/21348-emby-latest-versions/ ...  Beta release notes.

It gets updated with each beta release with the newer stuff at the top.

thanks

[Armageus 67]

On 10/03/2023 at 13:43, Luke said:

It's all related though.

 

On 10/03/2023 at 20:12, cayars said:

Correct, but if we are revamping part of the system then we usually also look at related requests as well as internally talk about further ways to improve the functionality.

Which is all well and good, but honestly the people requesting features would rather have the basic feature they've requested in a reasonable time frame, instead of waiting years for you to overhaul multiple features of the same category.

 

On 11/03/2023 at 00:24, Anielarias said:

what is the eta?

32nd of Neverember 

[roaku 795]

7 hours ago, Armageus said:

 

Which is all well and good, but honestly the people requesting features would rather have the basic feature they've requested in a reasonable time frame, instead of waiting years for you to overhaul multiple features of the same category.

 

32nd of Neverember 

That's absolutely not what they described.

[kikinjo 162]

13 minutes ago, roaku said:

That's absolutely not what they described.

They also did not describe that this FR will be 5 years in the waiting room...

[roaku 795]

2 minutes ago, kikinjo said:

They also did not describe that this FR will be 5 years in the waiting room...

I didn't say they did.

[kikinjo 162]

51 minutes ago, roaku said:

I didn't say they did.

Point from me and few others is that we are waiting far too long for basic FR that was asked, so we don't need philosophy of expanding something that isn't there for 5 years.

[roaku 795]

14 minutes ago, kikinjo said:

Point from me and few others is that we are waiting far too long for basic FR that was asked, so we don't need philosophy of expanding something that isn't there for 5 years.

My point is that there were real reasons it took five years to start work on this feature.

There's a chance discussing those might improve delivery times of future features.

Making up fake reasons to complain about isn't going to do that.

[ebr 14913]

9 hours ago, Armageus said:

Which is all well and good, but honestly the people requesting features would rather have the basic feature they've requested

We really can't win here as when we do this (or even when we try not to) we get complaints with people saying "why would you implement X without Y and Z - that's just stupid" (I read one of those just this morning).  

13 minutes ago, roaku said:

there were real reasons it took five years to start work on this feature

Yes, because it requires some changes to some very fundamental parts of the system - which then ripples out everywhere.  We finally were able to undertake that and, since we are, we are trying to design a more complete feature (of course, it won't really be complete, but we'd like to get it very usable).

[kikinjo 162]

23 minutes ago, roaku said:

My point is that there were real reasons it took five years to start work on this feature.

No one saying there weren't. But 5 years, common.  If someone is faking reasons..that's not emby users for sure.

[roaku 795]

10 minutes ago, kikinjo said:

No one saying there weren't. But 5 years, common.  If someone is faking reasons..that's not emby users for sure.

You want to argue about something else. No need to keep quoting me.

[Carlo 4330]

  

1 hour ago, kikinjo said:

No one saying there weren't. But 5 years, common.  If someone is faking reasons..that's not emby users for sure.

Just a bit of perspective on the time frame. As of today this request only has 35 likes so it's not exactly super popular or in high customer demand.
It wasn't until almost 2 years ago that the 20th person commented in the thread. This of course is only one of many metrics, but I think it shows why other things were done before it as they had a bigger following.

Regardless of popularity any idea we think improves Emby will likely make it into the product at some point. If the item is highly popular it will likely get done sooner than something else , all things being equal. By that I mean there is no prep work or foundational work needed first.  Even a super popular request might get pushed to later with other requests done first if foundational work should/needs to be done first.

For example, both collections and playlists stored their information in text files vs a database and we had both already planned to migrate to a database. We did exactly that for Collections and it takes a lot of design, planning and especially testing to make sure things migrate smoothly for the userbase. We could have followed up the Collection migration right away with a playlist migration, but we also knew we had music library changes planned to improve the music library. Since music is a big part of playlist use it only makes logical sense to do the music changes before any playlist changes.

The release that included collection changes and the release including the music changes were the two longest beta cycles I can remember in a long time and maybe the two longest ever. Those two releases really needed to be done first to pave the way for the playlist changes requested. Beside these two completed items there is additional foundational type work that needed to be done in order to have a concept of public vs private access. On top of that you need to have another layer of permissions management in place that isn't limited to admins but controllable by users to grant other users access to their lists or to make them available globally.  You need admin control over what a user is allowed to do or not allow to do with playlists.  You need the server APIs to understand these new permissions so that search results, displays and any other use of data understand public vs private and be able to quickly apply filters based on these new permissions.

If you follow Luke's posts recently, you'll see comments and questions on this new layer of permissions and how they might be handled in the UI. Some users following along probably already understood how it would fit in, as it's one of the last needed pieces to make this type of control over playlists a reality. Hopefully most will understand we design something like this to be useful throughout the system for use with future improvements and new features and not just add it for only one part of the system such as playlists. The logical first use of this is of course new Playlist functionality.

So, while you might say the request is 5 years old. I could just as easily say it really wasn't a request with much support behind it until about 2 years ago and we have been working on the foundation of Emby to make this and some other requests possible.  The reality of this is probably somewhere in the middle of those two points of reference with the team laying the groundwork needed to add this functionality. Hopefully this gives you a different perspective on things as the team did really like this request and have been working on things behind the scenes for quite a while to make this happen.

Carlo

 

 

[Anielarias 23]

7 hours ago, roaku said:

You want to argue about something else. No need to keep quoting me.

please dont tell me u wait 5 years to get your car oil or brake change when u go to the dealer or wait 5 years to get medical attention when you go to an emergency room. this forum is full of "for the future" and vague answers like this, like we the customers who paid a price for a paid product are some kind of ignorants. we deserve a better and more profesional customer service and transparency. maybe publish a timeline of things u have in the pipeline. but i guess this is what u get when a bunch of developers with no sense of customer service run a company. 

[roaku 795]

13 minutes ago, Anielarias said:

please dont tell me u wait 5 years to get your car oil or brake change when u go to the dealer or wait 5 years to get medical attention when you go to an emergency room. this forum is full of "for the future" and vague answers like this, like we the customers who paid a price for a paid product are some kind of ignorants. we deserve a better and more profesional customer service and transparency. maybe publish a timeline of things u have in the pipeline. but i guess this is what u get when a bunch of developers with no sense of customer service run a company. 

 

 

[Happy2Play 8282]

33 minutes ago, Anielarias said:

forum is full of "for the future" and vague answers like this

True and would rather the DEV provide a different answer (but they will not blatantly say NO for a feature that will happen in the future.  When is never known.), but these requests go on a to do list that changes with every build in reference to priority.  So where some would call this a high priority others would say why I don't need it so low priority.

Are there other areas that should have priority over playlist yes, but everything can't be done at once and changing already designed features almost always breaks other areas.

As a paying customer has absolutely nothing to do with features that do not exist.  So it will be ready when it is ready.  As you would just as peeved if a beta went out the broke many other areas just to have this feature that I don't believe the majority will every use.

[GreatFlashMan 75]

23 hours ago, ebr said:

Yes, because it requires some changes to some very fundamental parts of the system - which then ripples out everywhere.  We finally were able to undertake that and, since we are, we are trying to design a more complete feature (of course, it won't really be complete, but we'd like to get it very usable).

We understand that.

Regardless of "likes" to the topics, this (as i am sure all of us agree) is a pretty fundamental feature that really should have been implemented at the same time that playlists were. This has been requested on and off for several years, and I am sure will continue to do so.

This change is not just in the ownership of a playlist, but must of course alter a lot of the inner workings of Emby itself, and i can understand how that can be a foreboding prospect, and this image attached shows how much it filters through the system (as this is also obviously undesirable).

Of course, there's an easier way to do it, and that's to add a folder within the playlists bearing the name of the user (formed from the username replacing invalid chars). Then only allow the user themselves, and admin, to access and return results from the playlist. But, this (as a coder), though being a simpler way to achieve it, feels like a bit of a coding cludge.

i take it that the format of playlists will be changing from a txt based format to XML or a database driven structure so that an USERID/USERNAME can be added as a field? This would of course be a far better way to achieve the desired outcome, plus also future proof more in light of possible later enhancements.

[Luke 37068]

Making a private playlist public:

[Luke 37068]

Make a public playlist private again:

[Vicpa 556]

Hi @Luke

Looks good. Is the default on a new playlist always private? 

-vicpa

[Luke 37068]

Just now, Vicpa said:

Hi @Luke

Looks good. Is the default on a new playlist always private? 

-vicpa

Yes. Any previously created playlists as well as playlist files that are just mixed in with your media libraries won't have these functions, so they'll just be visible or not per normal library access rules.

[Vicpa 556]

Sounds right to me,

[Vicpa 556]

@Lukefeature comment

Hi,

More opinions/preferences,

Can the display (playlist page) show them grouped by  type and  then sorted by sortname?

All the public playlist would be grouped together and my private stuff would be grouped and maintain my custom sort order.

Hope this makes sense.

-vicpa