Bulk Meta Data Editor

[Luke 42378]

39 minutes ago, dukeofhurl said:

Hilarious. How far in the future?

Hi, I don't have an ETA, but it's in our plans. Thanks.

[te5s3rakt 5]

Just here to throw another vote on the pile 

Vote number 69... Giggity 

Edited February 5 by te5s3rakt

[dukeofhurl 3]

3 hours ago, te5s3rakt said:

Just here to throw another vote on the pile 

Vote number 69... Giggity 

Nice.

[HanSolo 23]

+1 

This would be very useful; I'm going to try Vic's tool for now. 

EDIT: I tried Vic's tool, I do apricate his hard work but it is very hard to use. It shouldn't be a reason not to implement this feature request as native functionality

 

Edited March 27 by HanSolo

[dukeofhurl 3]

Is this still coming soon or not?

[Luke 42378]

2 hours ago, dukeofhurl said:

Is this still coming soon or not?

hi, bulk edit features are planned for future updates. Thanks.

[Smitty018210 152]

2 hours ago, Luke said:

hi, bulk edit features are planned for future updates. Thanks.

It's been in the "future plans" stage for ten+ years. lol

Coming soon to Emby 2040!

[nospotify 189]

I hope the Emby development team continues to delay or completely abandon this idea. Emby is wonderful server software, not library software. Everyone who wants bulk editing of metadata should download MP3tag or a similar program and edit their media files to their heart's content, with the added benefit that if a user changes server software in the future, their data files will still reflect the edited metadata.

[MBSki 1121]

@nospotifyBulk editing is for metadata fields not accessible outside of Emby like Emby tags.

[nospotify 189]

9 minutes ago, MBSki said:

@nospotifyBulk editing is for metadata fields not accessible outside of Emby like Emby tags.

That may be your desire, and that would be fine, but there are many other people in this thread that are asking for more complete metadata editing. And given Emby's famously opaque dev process, I'm just putting in my vote that they not focus on any of this and instead, as @ebr noted a screen or two above, focus on other functionality.

[Smitty018210 152]

2 hours ago, nospotify said:

That may be your desire, and that would be fine, but there are many other people in this thread that are asking for more complete metadata editing. And given Emby's famously opaque dev process, I'm just putting in my vote that they not focus on any of this and instead, as @ebr noted a screen or two above, focus on other functionality.

I don't even think I would use this all that much. I just think it's funny/sad as heck that Devs keep saying it's in their "future plans" after ten years! If you can't get to something in that amount of time then just say why it has not happened and/or close the request. IT'S BEEN TEN YEARS! 

Edited April 20 by Smitty018210

[ebr 16396]

Just because something that we'd like to do in the future hasn't made it to the top of the priorities list doesn't mean we should deny it ever happening.

[evil_crab 25]

On 4/20/2026 at 8:58 PM, ebr said:

Just because something that we'd like to do in the future hasn't made it to the top of the priorities list doesn't mean we should deny it ever happening.

The problem is that there are multiple highly popular features (e.g., this one, watch together, alternative TVDB orders, user recommendations, etc.) that were requested 5-10 years ago, and we keep hearing that they are planned for the future. A bit more transparency on priorities and timelines would not hurt. Something like a yearly post with the retrospective and plans for the next year.

Also, I personally really like the idea of having the month of "What the Heck?!", which is occasionally organized by the Home Assistant team and focuses on resolving a bunch of easy-to-fix pain points reported by the community.

[dukeofhurl 3]

I just keep telling myself that it's only $4 a month so don't expect it.

[nospotify 189]

32 minutes ago, evil_crab said:

The problem is that there are multiple highly popular features (e.g., this one, watch together, alternative TVDB orders, user recommendations, etc.) that were requested 5-10 years ago, and we keep hearing that they are planned for the future. A bit more transparency on priorities and timelines would not hurt. Something like a yearly post with the retrospective and plans for the next year.

Also, I personally really like the idea of having the month of "What the Heck?!", which is occasionally organized by the Home Assistant team and focuses on resolving a bunch of easy-to-fix pain points reported by the community.

What I find so puzzling is the Embys developers' continuing inability to communicate better with this engaged, enthusiastic user base. I understand why developers of any paid software wouldn't want to publicly reveal their detailed timeline, but there's no reason not to share general - and realistic - priorities and plans. It would save 20-30% of the posts and grumbles here - and probably 40% of @Luke's time - if he would dispense with the phlegmatic, control-v "that's something we plan to implement" and instead be able to refer users to a clear, meaningful, realistic page that lists what is actually being worked on in the short, middle, and long term. 

[travismccannon 1]

On 5/20/2021 at 12:10 PM, MBSki said:

With the increase in tag use in the latest stable version, can we now get bulk editing for metadata? I'd like to tag channels, but I have no

interest in individually setting tags for 30+ channels.

 

[HanSolo 23]

On 4/27/2026 at 11:03 AM, nospotify said:

What I find so puzzling is the Embys developers' continuing inability to communicate better with this engaged, enthusiastic user base. I understand why developers of any paid software wouldn't want to publicly reveal their detailed timeline, but there's no reason not to share general - and realistic - priorities and plans. It would save 20-30% of the posts and grumbles here - and probably 40% of @Luke's time - if he would dispense with the phlegmatic, control-v "that's something we plan to implement" and instead be able to refer users to a clear, meaningful, realistic page that lists what is actually being worked on in the short, middle, and long term. 

Hi, 

I'd like to take a stab at this, it's not intended in any way other than a friendly explanation, no ill will indented at all. I know this has been going for a long time and waiting for features is frustrating. I'm not part of the Emby team but I'd like to shed a little light on this, having some firsthand experience. Since I'm not part of the team, I don't know how big the Emby team is, and I'm making some assumptions based on my experience. I don't think the team is that big, I would be surprised if it's over 10 full time developers, I wouldn't be surprised to learn it's 1.

In general software is incredibly difficult to develop even things that seem simple can often be much more complex under the surface. On top of that, project management is hard and predicting the future is impossible for humans (which doesn't stop us from trying). There are also dependencies and tradeoffs that are outside of the development team's control which add time and complexity to even the simplest projects. It is not abnormal for features such as this to be added and/or dropped in the middle of release cycles, sometimes multiple times. Software teams are generally opaque for these reasons; this is not something unique to Emby. One example of this is Apple who is famously mum about their development plans and commits to almost nothing. In my experience any commitment to software timelines and feature sets don't come from the development team, they come from marketing.

For Emby specifically the surface area that I can see is incredibly complex, think of it as a multiplication problem where every server version, client version and app store adds features work that must be done. Then there is this feature itself, without knowing full details, I would guess would be at least a medium level of complexity to implement. 

This is not in an excuse, just sort of a small peek behind the curtain if you will. Hope it all makes sense.

-HS

PS sorry for the typos I'm sure I missed some and I didn't use an LLM to correct this.