MusicBrainz events in ListenBrainz and beyond

Hello, the developer of the FestivalGuide app her. I am very curious about the planned integration of MB events into LB. Since I have some experience working with MB events, I want to grain in my two cents about the goals and proposals of GsoC 2026.

For sure you are allowed to take a look at the FestivalGuide app for inspiration. But I hope the app will not render obsolete after events hit LB :wink: Instead I appreciate some cross-linking and shared goals :slight_smile:

Disclaimer: I am not a MetaBrainz Developer, and tho I have no influence on the selection of the GsoC students.

But I contacted @mr_monkey and he said my cents could be worth it. I tag you applicants here in the hope that this will help you. (And I also hope I caught all of you, more than I expected).
Feel free to ask any questions.

@22ashwaniyadav @Haris076 @SohamDeshpande @failure_san

So, let’s begin with the official goals:

MusicBrainz has a concept of events to represent concerts, festivals, competitions, etc.
We want to show this information on ListenBrainz in a few places:

  1. artist pages should list upcoming events (perhaps past events too) the artist appears in
  2. a new dedicated events page both tailored to the user and global, similarly to how the Fresh Releases page functions
  3. the user feed should show notifications for upcoming events for that user’s top artists
  4. or — add a way to manually ā€œfollowā€ an artist and get notified of upcoming events

Associated tickets: LB-1351, LB-757

  1. No brainer. Totally useful. But I have some things to consider:
    a) There are not that many actual/upcoming events in MB. This is some kind of obvious because events which are actual this year are past next year. So think some past events will help to avoid empty space.
    b) Consider a separation between festivals and concerts. Concerts are to 99% simple. single events you can easily display. But festivals are more complex. If you just use the simple browse endpoint of MB API, you will get some results like https://musicbrainz.org/event/32b0f9f7-6728-42ad-a4c4-b1a88fea6c9c when browsing events of the artist Wind Rose which is just a part of Wacken Open Air 2026, Day 4, which is part of Wacken Open Air 2026. so for festivals we have a tree structure. Maybe it is better to show the root event instead of the day event. To get all events in an event tree you can use the new Browse events on event endpoint.
  2. Another great idea. But what is meant by ā€œtailored to the userā€? In some proposals I read about
    a) the location of the user. Keep in mind that not every festivals has a place or area attached. For places the coordinates are helpful. Areas are not so easy because they are also structured like a tree and you can not easily get ā€œevery event in germanyā€ so easily. Regarding Areas and Coordinates
    b) Based on (4)
  3. To clarify, here it is important to create notification for changes on events and their linup/schedule. I can image notifications like
    a) Event added/cancelled
    b) Artist(s) added/ performance cancelled, time added.
    Those notifications can be computed daily or weekly.
    I also plan that for FestivalGuide. If this data will be exposed through an endpoint it would be nice.
    Maybe we can use MB edits as a source? Edit search API
  4. A new follow artist feature. That seems good. I also do that in FestivalGuide. But I use and integer value (1-5) instead of a boolean. That allows the user how hard they are into that artist. I wonder if we can have some kind of sync between FestivalGuide and LB later.
    But I am not sure if this is needed at all for LB. Because LB has the listen data already. You can take the artists the user listened to. Maybe with a setting ā€œJust consider listens newer thanā€¦ā€ And ā€œJust consider artists which have a listen count above ā€¦ā€ (Those settings could also be useful for fresh releases)

Ideas I read in proposals:

  1. Event detail page. You have to make clear how far you would go with the details. Base direct event data, place, event art will be sure. Have you thought about showing setlists? But what about a full artist list of a multi-day multi-stage festival? Her you have the same problems with the tree structure mentioned above. Also normally just the root event will have event art. What about schedule? even more complex. I think the everything more than a simple list of artists will be overkill. Maybe we can deep link to the FestivalGuide app ā€œfor further detailsā€? I think it will work using deep links.
  2. Events tab in search results: Nice.
  3. Interested/Going buttons: I am not sure if this should be part of LB. For me it has nothing to do with the original goals of LB. But I am sure your mentor will decide this. Personally I like this feature more in FestivalGuide. There you can mark planned and seen on event AND performance basis. Performance basis means relation basis in MB terms.
    If events should have this in LB, I also can imagine a sync with FestivalGuide.

My Ideas:

  1. Create a festival playlist. This one matches great with the rest of LB. I already discussed something about it with mayhem and I think he already built something which was not ready for the public before his passing.
    I considered using LB radio, but he said that it is not meant to be used with 100+ artists.
    See https://tickets.metabrainz.org/browse/LB-1556 point (1) and discussion about it.
    In my opinion each festival should have one or more playlists attached, which are not user owned. But I think that is not possible with the actual LB architecture. So I imagine a button, maybe with some options, to generate a festival playlist.
  2. A button on the event detail page to add listens from setlists. And of course the event detail page can show setlists is a more LB way. More beatuiful and resolved as MB. I know, the setlist feature is not widely used in MB, but it would be nice to add listens from a setlist after you have seen a concert live. Maybe the listen can have a marker for ā€œseen liveā€. I don’t know much about what data listens can contain.
  3. We need users to enter more event data. Some users here are already pretty invested, let’s see if we can unite the willing ones and see how we are able to streamline event editing.
  4. If I have more, I will drop them here and post below about the update.

Some things to clarify:

  1. LB will cache MB event data? Cache means keeping the schema from MB? When gets this cache updated?
  2. For artist follow/like/track and event planned/seen we need extra tables in LB. Is that wanted?

I have not used AI :wink: Just 2hours of my time. (Okay, a little for translation purpose, because i do not know every english phrase)

6 Likes

Hi, thank you for your two cents. I will just further the conversation, and give my two cents on your two cents.

Also, cc: @MrKomodoDragon and @teayah, because they also had a proposal for the same.

Why, that is actually really helpful to know. It also makes our life infinitely harder, but it doesn’t seem unsolvable at all. Also, better find out about complications now, while we have time to design, instead of when we are rushing to get the implementations done.

That is quite correct, and truth be told, the more I think about it, the more I hate it. I mean personalized based on artist follows is fine, but the location really seems to complicate things. My approach for example was, if say an event is in Wembley, it is also in London, and it is also in the UK. And we would store that as a list, and check it against the user’s area. But then again, we would need to extract their area’s parents, because just because they live in Manchester, doesn’t mean they might not be interested in shows in London, because they do still live in the UK. And at that point, it feels like it becomes too computationally expensive.

I think the solution might lie in exploring MB, and how it handles the same, because the WS2 endpoint does allow area based filtering, and finally deciding based on the complexity of the solution, if it is within scope, or out-of-scope for a GSoC proposal.

As someone with more experience on such things, what do you think? I had initially considered a daily schedule, but if weekly works, that would probably be better.

Might be possible, though my approach has been to check if it’s cache entry has been updated since the last time we calculated. And I don’t think that data really should be exposed.

Not necessarily for this proposal, but that would in itself, be a rad feature for LB, in my opinion. It opens up the possibility for other features, like new album notifications, and using that information in recommendations even.

As an example, of why this feels superior to me. My old listen history from 2022 or 2023 contains apparently unholy amounts of Shawn Mendes songs, going through heartbreak or something. He is one of my top artists, but I don’t even listen to him anymore. Now of course, this can be mitigated by limiting it to 6 months, or something. But, why play guessing games?

Fun fact, I had integrated this into my original mockup, though I don’t have it anymore. I did realize later, there doesn’t seem to be a way to redirect to an event in the app? Like a redirect link? Or, maybe I just couldn’t find it. I am not very well-versed in Android dev, so I might not be explaining things very well.

I concur, though I do think a watch / follow feature is warranted for individual events, which is what I proposed. This also allows displaying the watch count, which is a nifty party trick, if nothing else!

As for syncing with FG, that doesn’t seem quite right to me, but that’s out-of-scope either way, and not for me to decide.

This is still on my idea list from the very first day. This randomly popped into my head while brainstorming, and I loved it so much. But, the project scope is already massive, and I haven’t really been able to fit it in, or even spare much time to think about it. But, if possible, I would love to steal this. And even if it’s not stolen, I think this should be implemented after this feature is done, anyways.

Yep, that is how most things already work. This is presumably to keep LB from hammering the MB API to death. And also increase speeds, of course.

As for schema, no, I don’t think any proposal at all suggests keeping the MB schema. The MB schema is (and I went over this in my proposal) in layman terms, spread out as fuck. For LB, where the goal is really only to display this data a certain way, and is needed only a certain way, just a JSON blob is likely adequate.

As for when this cache gets updated, I had initially thought it would need to be updated quite frequently, in case events were cancelled, or something along those lines. But, honestly, LB can’t keep up with that, and it’s not LB’s job either, I think. So, I would suggest a daily or maybe even weekly increment is probably fine.

I can’t really answer your question, because I am not a maintainer, but I don’t see why not. Especially for the follow artist feature, that really seems a natural extension of the existing follow user feature. The rest is debatable, but more tables is just part of the game, I guess, as the project gets new features added.

Anyways, quite a long reply from me. I am quite a voracious replier. Thank you for your two cents, they were quite a bit more!

4 Likes

also adding my two cents, since I do a good bit of event editing

everything y’all have mentioned is pretty exciting to me~

this might be out of the scope of GSoC, but this could eventually be synced with MusicBrainz collections, as interested/going/attended collections are created by default for new editors


also, we probably want to support non-concert and festival events. I’m specifically looking at conventions and expos (categorized together as one event type)

in my experience, these have a very similar relationship structure as festival events, so handling them should be pretty similar too, but might require slightly different handling. while you might show that Wind Rose played at Wacken Open Air 2025, we could show that My Little Romance played at Coltchella 6 or at HarmonyCon 2025 or even both somehow (I don’t know what my preference is on this tho)


another point, we may want special handling of virtual or online events, like in-game concerts and livestreams. most of these should be categorized under [worldwide], so it should be pretty simple

maybe we just show this as ā€œOnlineā€ or something

2 Likes

Thanks for you reply.

I think weekly is enough, but let’s see how heavy the computation will be. I update the events once a week, usually on Thursday/Friday, using my bot. But if it is not that expensive, daily would be nice, of course.

Okay. May approach would be to look at the edits, like mentioned here: Edit search API
The notifications then are pushed to the user feed right? Maybe we can go that route because there is already an endpoint for that: /1/user/(mb_username: *user_name* )/feed/events

I think that is possible with so call deep links and will be more work on app side. You just need to create the specific link. And I think I need a fallback page, where the user lands when FestivalGuide is not installed.
What does @mr_monkey say, about linking to FestivalGuide directly?

Yeah, having the stats about number of visitors like other sites would be nice.
With syncing I mean an API with PUT and GET for event planned and seen. Then I can implement the ā€œsyncā€ part. Another way to think about is. that LB can import a FastivalGuide backup file.

Ahh forgot about that collections. I think when this feature will be implemented, we should only have/promote one. The collections OR LB events. For me collections always look like a workaround for such things.

Unitl now FestivalGuide just uses concert and festival types. Would you want to see events like you mentioned in FestivalGuide? I avoided it because I maybe need a separate view for them.

I think the option to sync would be good, but I’d be fine with this entirely in ListenBrainz too. that way you wouldn’t need to create a MusicBrainz account* to actually use this feature

*as of right now, a MusicBrainz account is required, but I know there’s work being done to not require this

I think it could be good to have in FestivalGuide, and fairly easy to add, since as mentioned, the relationship structure is fairly similar (tho in the case of conventions, the music isn’t usually the focus of the event). I don’t know for sure that I’d personally use it or not, as I’m usually the one adding convention events I’d be interested in to MusicBrainz, lol

that said, for a ListenBrainz feature, I definitely don’t want conventions to be missed, especially if festivals are added

1 Like