In spite of the new mDNS feature, I haven’t yet managed to make multicast work between two VLANs, that is, between the jellyfin server and a few clients on another VLAN. 
Have you opened port 5353?
Yes, I added this rule:
/ip firewall filter add action=accept chain=input comment="Allow mDNS" disabled=no dst-address=224.0.0.251 dst-port=5353 log-prefix=mDNS protocol=udp src-port=5353
Anyway, I disabled any reject or drop rule on the firewall temporarily. Same problem. It is like the multicast traffic doesn’t propagate..maybe
In my highly restrictive local communication environment I had to add an addition forward rule like following:
/ip firewall filter add action=accept chain=forward comment="FORWARD FromDevices ToDevices" dst-address-list=ToDevices src-address-list=FromDevices
In my case I have 2 address lists [FromDevices ] [ToDevices] these lists populate IP address of hosts that need to communicate with each other
This rule would be placed just above FORWARD Drop all
That enabled multicast to work for the targeted VLANs and the hosts in question …
I had already added a forward rule between the server and the smart TV in different VLANs. Thanks
It works perfectly for me between two VLANs even without the rule
/ip firewall filter add action=accept chain=input comment="Allow mDNS" disabled=no dst-address=224.0.0.251 dst-port=5353 log-prefix=mDNS protocol=udp src-port=5353
I just created a forward rule to allow traffic between the two devices.
Are you using Windows for testing?
If so, temporarily disable the firewall.
Nope. The server in which Jellyfin runs is a linux machine (firewall disabled) and the client is a smartv.
I am not at all familiar with Jellyfin but in reading some stuff on the web I have hits stating that Jellyfin currently does not support multicasting …
https://features.jellyfin.org/posts/172/allow-multiple-clients-to-view-a-strea
I know that mDNS works well for me … I know that most if not all Linux machines support multicasting but Jellyfin apparently does not but I could be wrong.
I don’t know. It could.
For the record Jellyfin runs a DLNA server.
Tested new mdns-repeat-ifaces feature on ROS DNS using macOS and iOS screen mirroring (AirPlay) and cast from Google Chrome (Google Cast) from isolated VLAN to Android tv box on LAN and it works - discovery and streaming, but had to allow many ports on forward chain from vlan to TV box.
With the current implementation of mDNS I have my Sonos Speakers and Apple Airprint Printers all working flawlessly
Sonos and AirPrint Printer reside on vlan100 — devices that need access to either one of these reside on vlan20 …
Using the 2 firewall rules mentioned in my posting here …
Ah OK, then why do you use mDNS instead of PIM-SM for DLNA/UPnP?
/ip firewall filter add action=accept chain=forward comment="FORWARD FromDevices ToDevices" dst-address-list=ToDevices src-address-list=FromDevices
This completely exposes hosts in list, more secure is to allow just needed ports for hosts in list.
I gave it a try too. It didn’t work.
in my situation I only allow one to one communication - nope, local hosts [and/or devices] are completely secure from each other unless permitted,
I’m always ready to learn, however … 
Not to grave dig but one mistake I made as someone with very little experience with Mikrotik and bought my first device to learn and for 10gig. When I set up VLAN isolation and was blocking traffic between the VLAN’s I didn’t realize you could block established traffic. (I am coming from opnSense).
- User talks to IoT = Pass
- IoT responds to User = Blocked
Changing the VLAN block rule to only block the “new” connection state fixed my issue.
Normally, you should have this filter rule near the top of the forward chain:
/ip firewall filter
add action=accept chain=forward connection-state=established,related,untracked
and for IPv6:
/ipv6 firewall filter
add action=accept chain=forward connection-state=established,related,untracked
And in case fasttrack is needed:
/ip firewall filter
add action=fasttrack-connection chain=forward connection-state=established,related hw-offload=yes
add action=accept chain=forward connection-state=established,related,untracked
It’s like that in the standard defconf firewall configuration or the example from the documentation https://help.mikrotik.com/docs/spaces/ROS/pages/328513/Building+Advanced+Firewall#BuildingAdvancedFirewall-ProtecttheClients.
Those accept rules are placed above the rule that drops traffics. This also improves performance, because most of the normal traffics will be accepted by them and most packets will only need to be processed by a couple of rules.
If you apply this, you won’t need the connection-state=new condition on your drop rules anymore.
@AMMO Did you submit your suggestion to MT for future implementation… I mean your not inventing anything but reflecting a standard that exists correct???
mDNS doens’t use a multicast address not routable?
hosts receiving multicast packets from different networks are not supposed to discard them?
or teher is some nat/relayingin the router?