Roon Security via Profile -- aka "Party Mode" / "Do No Harm" [On roadmap, low on list]

From a previous thread

Biggest limitation of a Pi configured as suggested is that you can’t search so it doesn’t give a guest anything remotely close to the Roon experience.

They can simply start or pause the current album and skip the tracks. They can’t change albums, access Qobuz or Tidal etc so it’s just like letting them control your CD player but not letting them have a rummage through your cd collection and chance CDs in case they put the discs back in the wrong box.

To be honest I’d have no problems giving my friends my iPad or phone to play around with as I know they wouldn’t add or delete stuff. Anyone I didn’t know well enough to trust Roon wouldn’t be allowed anywhere near my hifi anyway :slight_smile:

1 Like

Trying to adapt this product for my wife’s dance studio. It is closest I have come to a suitable solution. There are standard songs she uses for specific classes. The playlists are 100 or so songs and she would create them in her profile and make them shareable. I did this thinking they would be read-only by other profiles but they were not as I deleted a song while using my profile. I never thought shareable would mean shared and modifiable by others. Am I missing something on this.

I looked for a way to lock profiles, but see no way to do it. Each of her teachers would have their own profiles with their own musical selections and she would not want them to be able to switch to someone else’s profile. Again I might be missing something.

No, I don’t think you are missing anything. In Roon, all profiles are equal and effectively have ‘Admin’ powers to delete anything, including any of your settings, your music and your library. Feature requests have tried to change the situation (party mode) but no change so far…

That’s unfortunate, but one more person requesting it will help the cause.

There is also a request to “Lock Playlists” even for the creator/originator of the Playlist.

Here your wife could create the Playlists for the classes, and make then available in a locked form to other users.

If necessary, as creator/originator, she could unlock them to modify/adjust them, and then lock them again, but it would be deliberate change being made by her and is only available to her.

1 Like

Sadly in Roon about the only thing that IS secure is command line access to the Roon OS core systems.

Really it is about time this changed…well it should have been built in from the ground up but here we are years later and still no progress.

Having run projects to add security into established programs, it is a pain to add later than at the beginning. But, in this case, the framework may indeed be there, just not activated.

1 Like

Ooh, you tease! :grinning:

I hope so as to me it makes sense to be able to make a playlist read-only or at least lockable by the creator. If someone has a separate profile I doubt they would want their shared playlists modifiable.

Surprised this isn’t a feature… in my trial period and was thinking about lifetime membership, but this is a huge gap in the feature set.

I’m more surprised it has been a feature request for five years now and no progress or development has ever been made or announced (other than “it’s difficult”).

It’s not exactly mirrors and beads, it’s a basic software feature, especially when its makers promote multi-user, multi-room usage.

2 Likes

What you may consider a “basic software feature” does not mean it is simple to implement…

I point I make regularly at work, in fact more “to make a feature look and work simply and effectively, is in fact very difficult and takes time”
But doesn’t stop us doing it, just need to understand the requirements and think through the operation and implementation.

I am well aware of that. But “not simple to implement” does not automatically mean you can’t make and/or communicate any (plans for) progress at all in five years time. :wink:

Well, @Grump, this “feature request” require Roon to implement “access control”. This requires Roon to scope out just how far they want to take “access control”. That is not basic nor simple. Whatever level of access control they would decide to provide, they would have to work out the UI and the overall user experience. I would argue that this is nothing short of a huge feature to add that would require a rewrite of a ton of existing code plus adding a bunch more new code. How many Roon subscribers do you think actually need “access control”?

Big decisions…lot’s of work…limited need…nope, not surprised it has yet to implemented.

I appreciate that.

That still doesn’t automatically mean you can’t make and/or communicate any (plans for) progress at all in five years time. After all, five years ago, Danny said in this thread:

His last comment is from 2017:

So I still understand this. But we’re talking years here, that was all I was basically saying.

Totally agree, Roon make a big point about never touching your local files, except to delete them! Does the “Delete Album” function exist primarily for removing streaming albums (I don’t stream)? If so, perhaps it could be limited to streaming services only? Otherwise, IMO the “feature” should go.

1 Like

Do you remember when Roon had the option for managing your library via a one way import? I argued then that Delete should go when the rest of that stuff was removed. Although, now that they have added a CD-Ripping function, there exists a point for Delete.

I wrote that “big point”.

Many programs modify your tags during edits or try to keep their own app-specific metadata in your files by changing their tags. This is what Roon does not do.

Roon doesn’t ever modify your files. In fact, Roon doesn’t even delete them. You do it, by hitting the delete button and then acknowledging that you want to do this with big red warnings making sure you understand.