Radio Ban Option

Thank you for that Brian. Could I just ask though exactly what you mean by ‘properly tagged’? Is this user tags (and if so, which and what do they have to be set to?) or does this only apply to items that Roon has identified (through normal online Rovi identification) as audiobook/podcast?

Roon treats media as a podcast if any of the following are true:

  • The file has a tag called PCST with any value
  • The file has a tag called TCON with value Podcast
  • The file has a tag called ISPODCAST with any value

Roon treats media as an audiobook if any of the following are true:

  • The file has a tag called PCSp with any value
  • The file has a tag called TCON with value Literature
  • The file has a tag called ISAUDIOBOOK with any value

In both cases, the first tag is most likely coming from the iTunes store, the second reflects some existing conventions for MP3 files, and the third is a readable option that we support in case people want to tag media from other sources manually and maintain some level of legibility in the tags.

1 Like

Many thanks, that is very useful to know. I have a lot of tag checking to be getting on with! :slight_smile:

It would appear that you are saying that the Radio is really for Tidal and not our local library. The method you suggest I use to play my local library without certain songs sounds quite onerous to implement. In fact, I don’t see how it can be done without touching every song in my library.

It seems you are saying you don’t care about people with large local libraries. I still prefer to buy content so I use Tidal to find music I like and then buy it. I guess you want to discourage that. I wish I knew that you guys were going to basically abandon people with local libraries when I bought my lifetime subscription.

Maybe you could create a tag for tracks that we could set/populate that the Radio would then not play.

It IS onerous, but so would be reviewing every song for radio suitability one by one.

Look at the very end of my last post–help me out there. What are these tracks that Roon is picking that cause so much trouble? Is there a way we could recognize and handle them properly automatically?

The only way you could read that out of my statement is if you’re miffed that I didn’t give the answer you wanted. I get it, no-one likes a “no”, but come on, really?

We are people with large local libraries too, but we are also smart enough to realize that there are a lot of people out there who don’t have them (or can’t be bothered to digitize/import them in a world where streaming services exist), but could benefit from Roon’s way of presenting and navigating music. Are you really saying we shouldn’t try to reach those people?

I gave several reasons that have nothing to do with where the radio feature is going–complex mental model, complicated to explain, newcomers will have to confront this choice too early, adds something confusing to every screen in the app, difficult to communicate via iconography, etc. Even if radio were staying exactly as-is, those would be enough to give us pause with this.

Maybe, will give it some thought.

If you want to accomplish a highly controlled shuffle within your library, there are ways to do that–for example, you could focus the album or track browser on the stuff you want to play, then exclude a tag from the focus that means “stuff I don’t want to hear randomly”, and then shuffle-play that browser. You could also manually dump a bunch of content into a playlist or tag and tightly control a random play experience by playing or shuffle-playing the playlist/tag.

It seems like radio banning could be done on the fly. Following your method above, when a track comes on radio that one would like to ban, add that tag to it. Kind of like a thumbs down in this context. Trying to identify and sort everything in a collection at once would, for me, make this hobby aversive!

How about every song on the Genesis album “The Lamb Lies Down on Broadway”. Or all but 2 or 3 songs on Pink Floyd’s “The Dark Side of the Moon”. Most songs on The Who’s “Tommy” and “Quadrophenia”. I could go on and on and on…

There are scores of albums in my collection that have tracks I only want to here in the context of the album that I don’t want to hear in isolation via the Radio. There should be a way to make that happen.

No, I am saying you should not cater to them to the point that you alienate people that do have large libraries and that may not using Tidal or not using Tidal the way you describe. Tidal is an optional service and, the way things are going, may be out of business soon. I could turn off my Tidal subscription tomorrow and I would expect Roon to still offer me something in regards to Radio functionality.

If you are going toward a Tidal-only model with the Radio, you need to give us something to use with our local libraries. As things are today, the Radio is useless to me because I can’t stop it from playing tracks I don’t want to hear without crippling album play.

No, I read that because you told me that playing my local library is not what you guys care about…and yes, that caused me to be miffed. You make it sound like Roon is striving to be an improved Spotify and that is what will be important moving forward. That made it sound like folks with local libraries aren’t going to see anything for them.

Sonic Youth - Daydream Nation - Providence.

Cowboy Junkies - Live at City Winery - Band Intro

Both of the above tracks popped up in my radio play at work last week and both are examples of things i would want to hear during an album play but not on radio.

The first is a voicemail recording over a piano track and while it works in the context of the album its terribly jarring playing during radio. Another example would be any of the songs in the Trilogy or the same album. The composition would be fine but a lot would be lost with any of them being played as a single.

The second example is just one of many similar tracks (song intros/band intros/crowd banter) from live albums/concert recordings in my library that have been picked up by radio. Im sure you can see how these could be an annoyance. Why would i want to hear a song being introduced and then the next track on the radio is something completely different by a different artist?

We are not going to a TIDAL-only model with Radio. Roon will still work without TIDAL, including Radio. I also did not “tell you that playing your local library is not what we care about”. We are also not “catering to them to the point where you [we] alienate people with large libraries”. These are speculations (and also not true). Please stop assuming the worst possible implementation. It’s not a constructive discussion if 80% of it is you speculating wildly and me rebutting.

What we are doing is broadening the product to make it usable by people with small/no libraries. I’ve seen what we’re working on, and I know what it is. It will benefit people with libraries, too, while at the same time changing Roon from “useless unless you have a lot of files” to “great no matter how many files you have”.

I’m interested in ways for Roon to automatically/transparently identify tracks that aren’t suitable for Radio (in a global way). Getting this right would make a better experience for everyone, especially the vast majority of people who are not willing to do any manual grooming of their library to annotate tracks one by one.

Doing something with this idea in the thumbs up/down area is the most interesting refinement that I have heard so far, since it localizes the impact on the user experience into a radio-specific place instead of making people confront this technicality on every screen.

Hi @brian

in generally I don’t have a problem with the latest incarnation of Radio. Before it was a bit too much in love with some songs and was playing repeatedly but now it is a lot better and I look forward to machine learning implementation.
However I have to say that I found annoying when during a radio session start the occasional track from the live album where there is the intro of the band or the little chat of the singer. Obviously I wouldn’t expect Roon to recognize these automaticaly but I would appreciate to be able to tag them to avoid in the future to be played again in a radio session. I understand the difficulty of implementing exception, even more if you try to do through machine learning so my suggestion would be to let the algorithm do its thing and then compare the selection toward a “radio banned” Tag. if the song is in the list you simply skip it and choose another one otherwise you play it. In this way you don’t mess up with the Radio engine and you allow users who are interested in managing their collection to skip songs they don’t want in the radio.
My .2 cents


This requires me to be reactive during Radio play which is the opposite of what I want when listening to the Radio. Nor is it particularly efficient. For those of us that are willing to be proactive, there should be a way to tag tracks so they do not play via the Radio but do play when we play an album.

For example, it would be great to be able to view the tracks of an album, select a set of tracks, and be able to enter edit mode and set a flag that enables/disables their play via Radio. Just like I can do now with the “Pick” setting. That would take care of your “making people confront this technicality on every screen” objection.


For those of us that are willing to be proactive, there should be a way to tag tracks so they do not play via the Radio but do play when we play an album.

For example, it would be great to be able to view the tracks of an album, select a set of tracks, and be able to enter edit mode and set a flag that enables/disables their play via Radio. Just like I can do now with the “Pick” setting. That would take care of your “making people confront this technicality on every screen” objection.

Introducing an inline editing mode for just this one thing creates a longer list of UX issues to resolve than we started out with, so the idea doesn’t really move things in the right direction for you :stuck_out_tongue:.

The problem is not “this feature, exactly as specified above doesn’t exist”. The problem is that Roon Radio picks some stuff that you don’t want to hear.

You’ve jumped ahead to an exclusively manual metadata-grooming solution that will work for you and a handful of others willing to put in substantial up-front effort to ban content manually, If we build the feature you’re suggesting, as you’ve specified it, a small number of people will use it. That may work out for you, but it will be a poor use of effort in terms of serving our member base as a whole. What about the other people who are suffering from these radio picks but aren’t willing to manually groom their library?

I want to solve the bad picks problem, but I’m not comfortable taking a swing at it unless the solution works for a wider group of people. And you seem to only want to talk about one fairly narrowly targeted solution. Which is why we are not making a lot of progress here.

That said, this discussion has not been a waste at all. It has given us some things to think about in regards to improving the radio experience and determining/avoiding bad picks. I think it’s clear at this point that a radio-ban feature that is purely done as an edit for people willing to groom their library isn’t something we are interested in building on its own, but I’m very interested in solving the broader problem, and I could imagine solutions that incorporate a manual tagging aspect in context of a larger system.


The proactive method I suggested could certainly work with a reactive method tied to the “thumbs” interface. The tag I propose could be set by the “thumbs” interface and could be unset or set using the edit track interface.

The current “thumbs” interface works on a per Radio “session” basis now. So I am not sure how you can modify that without creating a lot more havoc. That’s why I thought to use the current “Ban” interface. But you didn’t like that idea either…

It’s not necessary to be reactive throughout a Radio play session, if that’s what you mean. I generally spend a minute or two at the beginning of a Radio session reviewing the suggestions made by Radio, and using thumbs up/down to refine the queue. This has the effect of banning tracks from the Radio queue and producing a playlist that can last hours at a time. Now, whether the thumbs down selections should be “sticky” and be noted for future Radio sessions is perhaps a tricky issue. I’m not sure that it would work for me.

1 Like

That’s not what I meant. If this feature were implemented via some mechanism in Radio only, it means I would have to react to what Roon Radio was serving up.

Now, I don’t think it would be bad to have a way of doing what I want via the Radio. But, changing the behavior of the “thumbs” interface from “session only” to “sticky” would cause many people to be unhappy. Plus, there would have to be some mechanism put in place that would allow you to un-stick the choice. That’s why I suggested having the tag be accessible via the track editor. This would provide a mechanism that would allow one to be proactive and to undo the setting if done somehow using the “thumbs” interface.

I am trying to come up with a way to do this that doesn’t alter how people do things today. I am not privy to how the Radio will be changed in the future. All I know is there a lot of tracks that I never want to hear on the Radio but I do want to hear during album play. I know there are many people out there like me. But certainly not a huge amount. Does that mean a feature request like this should be cast aside? I don’t think so. It’s really should have been an option all along. I see no way to have Roon automate this. You can’t use computer or human heuristics to figure this out. The choices are just plain unique to each person. So, it comes down to a user interface elegance exercise.


How would you go about solving the bad picks problem I brought up with a “sticky” setting while the Radio is playing? The current Radio “Thumbs Up/Thumbs Down” interface only works before the song is played and it is not “sticky”. It only works for that session. Also, wouldn’t modifying that interface to do more also add to the complexity and confuse people? Wouldn’t you need to create another button?

I am all for a reactive metadata grooming but every way I can think of you say adds complexity to the UI and you have been against that. You have been against a proactive manual process too. Even if you have a reactive interface for this, you still need a way to edit tracks so they are no longer excluded from play. That can’t be in the Radio interface since the tracks would no longer show up there. It can be the proactive manual metadata grooming idea I proposed.

The “Picks” interface is completely manual. Do people even use it?