View Issue Details

IDProjectCategoryView StatusLast Update
0018264MediaMonkey 5Install/Configpublic2021-10-01 11:28
Reporterpeke Assigned To 
Status closedResolutionreopened 
Target Version5.0.2Fixed in Version5.0.2 
Summary0018264: Firewall Rules: Auto rules needs to be tweaked in order that MM5 gets discoverable by Devices and MMA
DescriptionAuto rules needs to be tweaked in order that MM5 gets discoverable by Devices and MMA

Currently MM5 add three Auto rules, which are OK fro streaming to other devices, but are in some cases not enough that MM5 is discoverable by MMA (fail server search), by other DLNA capable devices and also when speakers goes to standby or return from standby they can't announce itself to MM5 that they are available.

Attached image of all rules that was tested on 5 internally own devices and with several users and their devices.

- First three are auto rules MM currently set
- Forth and Fifth rule was created based on devices request connection to MM5 regarding announcements, presence check and communication MM5 <-> device
- Six was needed for Lyrics, Auto tag , Album Art, Web Views to work
- Eight rule looks same and covered by rule six but somehow only when this rule is added then MM5 is always accessible on LAN and seen by devices
- Seventh

NOTE: Port 50505 is my local MM5 server port, all custom rules exclude Public as ere tested in LAN/Domain enviroment not in internet access case.
Additional InformationPossibly related to
TagsNo tags attached.
Fixed in build2504


related to 0013261 resolvedLudek MediaMonkey 4 MediaServer: Some Components are still blocked by firewall 
related to 0015176 closedLudek MediaMonkey 5 Playing from portable version to a renderer may fail (as portable version doesn't auto-conf firewall) 
related to 0018310 closedLudek MediaMonkey 5 Improve configuration/management of MM firewall rules 
related to 0018168 closedLudek MediaMonkey 5 Media Server options: Add check button to server tab 



2021-09-09 02:18


bug18264.jpg (64,359 bytes)   
bug18264.jpg (64,359 bytes)   


2021-09-09 09:00

developer   ~0064506

Last edited: 2021-09-09 09:01

View 2 revisions

Peke, based on your screenshot it looks that the main problem is that the auto-conf rules has been created for
but you tested another instance
C:\mediamonkey 5\MediaMonkeyEngine.exe

If you would let MM5 to create auto-conf rules also for C:\mediamonkey 5\MediaMonkeyEngine.exe then I guess that all your inbound custom rules (i.e. 4th, 5th, 7th) would be superseded by our auto-conf rule(s).
Similarly your 8th outbound rule (the last) is superseded by the 6th rule (as [Out|Any] supersedes [Out||1900|UPD]), can you test and confirm?

So to me the only new auto-conf rule considering to add would be the 6th rule (Out|Any), can you confirm?


2021-09-09 10:07

developer   ~0064507

I left C:\MM2433\MediaMonkeyEngine.exe rules as example so that they can be clear from what actually MM5 uses.

I tried adding only 6, but Windows Firewall Control complained about 7, 8 rules as is not standard IP range, so once I added them as seen all worked correctly.

You are most likely right, that adding 6 only will fix the problem.


2021-09-09 10:41

developer   ~0064509

Last edited: 2021-09-10 09:57

View 5 revisions

OK, so can you please test/confirm that combination of current auto-conf rules (1-3) plus adding the outbound rule 6 solves everything?
i.e. just adding rule 6 (Out|Any) solves the issues for affected user(s)?

BTW: I am pretty sure that Windows Firewall enables all outbound rules by default, so there must have been a rule that disabled outcoming connections from MM5 ??
And I guess that you needed to delete such a rule so that rule 6 works? Do you remember name fo such a rule that was blocking the oubound connections?


2021-09-10 09:53

developer   ~0064516

Last edited: 2021-09-10 09:58

View 4 revisions

Further to clarify how it currently works:

If user installs MM5 to a new folder and does not accept UAC (to write our auto-conf rules) then this dialog is shown by Windows on first connection:
If on this "Windows Security Alert" user clicks [Allow Access] then Windows creates 'MediaMonkey' rule in Windows firewall to accept all incoming private connections and all should be OK (no need for auto-conf rules).
But if user just closes the dialog or click [Cancel] then Windows creates 'MediaMonkey' rule in Windows firewall that is blocking all incoming connections!
Therefore when MM5 creates the auto-conf rules it has to always delete the "MediaMonkey" rule created by Windows. Without deleting this rule firewall still blocks the connection (despite the fact whether we added the auto-conf rules or not).

Simply adding whatever custom 'auto-conf' rule by MM5 will not take any effect until the blocking rule is deleted.
So I guess that in your tests the key (for everything to start work) was deletion of the blocking rule which is by default called 'MediaMonkey', isn't it ?


2021-09-10 10:04

developer   ~0064517

Last edited: 2021-09-10 10:20

View 2 revisions

Per IM discussion Peke indicated that third party firewalls handles the rules differently and are ignoring the ANY parameter in rules and requires more strict definitions.
If that's the case I can add further (more strict) rules and let's see how it works in 5.0.2+

EDIT: May be also influenced by Peke's usage of WFC ( ) that creates own set of rules when installing and these rules can interferre with our rules. To be confirmed/tested.


2021-09-10 13:13

developer   ~0064521

As discussed further: AnyDesk, Skype use rules with defining UDP and TCP rules separatelly, so I used the same approach.
As for the rules for service discovery, we use both SSDP ( for UPnP/DLNA/Chromecast and mDNS ( for Chromecast audio. So I combined them in single UDP rule for private/domain.


2021-09-10 13:49

developer   ~0064522

So the new set of default auto-conf rules (when server is not set to accept external IPs) is:
Without public.png (60,104 bytes)   
Without public.png (60,104 bytes)   


2021-09-10 14:02

developer   ~0064523

And if the server is configured to accept external addresses (for public access outside of LAN) then these two TCP rules are added (constrainded to the server port -- 4002 in my example):
public.png (68,703 bytes)   
public.png (68,703 bytes)   


2021-09-10 14:05

developer   ~0064524

Added in

Test note: to re-create the rules you need to re-install MM5 or delete [FirewallRules] section in the MediaMonkey.ini and start MM5
As previously discussed in 0013261:0048541 we might want to add the 'Add Windows firewall exception' button directly to the server config.


2021-09-17 00:18

developer   ~0064684

Verified New firewall rules in 2502

Can you please triage if we will add exception button as talked in 0013261:0048541 and along with rule creation clear out other Auto Conf Rules created on MM installations which as disabled earlier ~48586


2021-09-17 14:50

developer   ~0064724

Last edited: 2021-09-17 17:04

View 4 revisions

I found it!!

In the workflow described how it currently works in my note 0018264:0064516 the problem is that the blocking rules created by Windows (when user cancels the "Windows Security Alert" dialog) are now called "MediaMonkey 5" (and not "MediaMonkey" as in the past in MM4).
Thus subsequently MM5 fails to delete the blocking rules (once user accepts the UAC to add our firewall exception).

=> Fixed in 2504 so that the blocking "MediaMonkey 5" rules are deleted

Assigned back to me to add the '[x] Add Windows firewall exception' checkbox (or button) as suggested in 0013261:0048541

=> Added in 2504


2021-10-01 11:28

developer   ~0064931

Verified 2506

Looks like ne rules set do its work better than old one.

3 users confirmed today that as of 2506 they see MM5 without problems in MMA and other DLNA clients