View Issue Details

IDProjectCategoryView StatusLast Update
0013261MediaMonkey (current)DLNA/UPnPpublic2020-12-10 13:31
Reporterpeke Assigned To 
Status resolvedResolutionfixed 
Target Version4.1.18Fixed in Version4.1.18 
Summary0013261: MediaServer: Some Components are still blocked by firewall
DescriptionEven MMW is added itself to firewall white list in some cases windows is still blocking MMW DLNA/Sync Server to be seen on network.

One of the solutions we used in past were to change port so that windows ask for firewall exception where MMW is allowed complete access.

Unfortunately in some cases even on LOW firewall settings (Digitally signed apps are allowed) this do not work and MMA do not see MMW server.

I have found that not all MMW EXE files are authorized adn needs to be entered manually which is not possible under some systems versions adn on some it is even more complicated due the their architecture (like Windows Server 2012 R2)

In remote session with user I have found that after adding all exe files to firewall exception MMW was seen on MMA
Steps To ReproduceTesting:
1. Remove all the MM Firewall rules
2. Execute Firewall creation script from ~48578
3. Start MM
4. Check and if existing and Remove all the MM Firewall rules that do not belong MediaMonkey Firewall Group
4. Check MMA if it see MMW DLNA server
Additional InformationRNH-615-77910
TagsNo tags attached.
Fixed in build1845


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 0016580 closedLudek MediaMonkey 5 DLNA: MM5 sometimes fails to see some DLNA Servers 
related to 0017209 closedLudek MediaMonkey 5 UAC prompt is shown after every re-install (also in Portable mode) 



2016-05-03 17:10

developer   ~0044537

This is long standing issue and it should be fixed.

Easiest way to replicate is to start Winamp.exe in order to start MMW or use some other app to start MMW like clicking on downloaded MMIP in firefox where parent app will be firefox, which is then translated by firewall taht Mediamonkey.exe is not actual taht wants to be available on network but parent app that uses MMW to access network.


2016-05-03 17:13


Firewall_issue.jpg (55,417 bytes)   
Firewall_issue.jpg (55,417 bytes)   


2016-05-03 17:22

developer   ~0044538

Assigned for triage.


2016-05-04 10:08

developer   ~0044546

Last edited: 2016-05-04 10:09

View 2 revisions

I tried to replicate, but I cannot.

I run .../MediaMonkey/winamp.exe and even if this is not allowed in
Windows Firewall > Allowed programs
the MediaMonkey server is seen normally (because .../MediaMonkey/MediaMonkey.exe is in allowed programs).
I tested on Windows 7's default Windows Firewall

Assigned to Peke for more information:
a) which firewall app it was ?
b) to find how we could auto-configure the app ?


2016-05-04 21:42

developer   ~0044551

One of teh possible reasons could be explained with

I'll check if I can find more, I also suspect on Win 10 where most reports are referred to.


2016-05-09 00:51

developer   ~0044567

Problem is that somehow Widows firewall rules Change from Block unknown outbound change to block al incoming and outbound.

Using WFC Ive found that these two exceptions always work.

Exceptions attached as WPW file.


2016-05-09 00:51



2016-05-09 12:33

developer   ~0044569

Last edited: 2016-05-09 12:45

View 5 revisions

Ok, so we could probably set this via command line (netsh) on MM start:

We just need to find how to detect the misconfigurations so that the elevate prompt does not popup on each MM start.

Another alternative is to do it via HNetCfg OLE object (or INetFwMgr interface - )
as we already use for port forwarding/opening on NAT (when '[x] Allow external IPs' is enabled)


2016-05-09 13:57

developer   ~0044570

Last edited: 2016-05-09 15:31

View 4 revisions

Fixed in

When MediaMonkey server is starting it checks for existence of 'MediaMonkey auto-conf NUMBER' rule (where NUMBER is hash from the application exe path like C:\...\MediaMonkey.exe)

If the rule doesn't exist (e.g. on first run) then it runs the elevator and:

a) deletes all "MediaMonkey" rules added automatically by Windows Firewall (that can be unchecked if the user closed the prompt for allowing MM connections)

b) adds the 'MediaMonkey auto-conf NUMBER' rule to Windows Firewall > Allowed programs


2016-05-09 21:02

developer   ~0044573

Verified 1791


2016-05-25 10:40

developer   ~0044746

Last edited: 2016-05-25 10:41

View 2 revisions

Re-opened, for one user the elevator fails to set up the rules for some reason and pop-ups on each MMW start!



2016-05-25 11:49

developer   ~0044747

Last edited: 2016-05-25 11:51

View 4 revisions

Fixed in build 1798.

Although I don't know why the elevator fails to write the rules for the particular user I changed the workflow this way:

If MMW finds that the rule was not registered yet then it runs the elevator, but if there is any other exception than "Elevation Canceled" or if there is a success then it never checks for the rules again.
If user just canceled the elevator then it is checked up again on next server run.


2016-05-25 13:13

administrator   ~0044751

fyi, could this user's experiences be related (config settings re. web node fail to stick)?


2016-05-27 01:57

developer   ~0044772

That should not be related.

This latest change should fix the problem.


2016-05-31 13:55

developer   ~0044816

Verified 1798

Not additional regression reports were filed by users since release of 1798


2016-08-11 11:12

developer   ~0045390

Last edited: 2016-08-11 11:18

View 2 revisions

Tech. test note for troubleshooting (re 0013261:0044747) :
There is a section [FirewallRules] in MediaMonkey.ini. If you delete the section then the rules will be added again.

Note that the rule is created for each MM.exe location. So if you install MM to another folder then new rule is added (as noted here 0013261:0044570). So for the troubleshooting is better to suggest the users just to install to another folder (easier and better than editing the INI)


2016-08-11 13:45

developer   ~0045392

Last edited: 2016-08-11 14:35

View 3 revisions


Peke indicated that Windows 10 anniversary update disables our rules and that re-installing MM to another folder resolves the issue (per my suggestion above).

Assigned to Peke to check:
a) Whether "MediaMonkey auto-conf ..." rules are really disabled (checkbox disabled) in Windows Firewall > Allowed Programs

If a) is true then MM could auto-detect this situation and add the rules again (by running the elevator on server run)

On the other hand it would be a hack, because if user disables our rules manually then MM will enable them again on each MMW/server start.

Rusty suggested to re-create them on MM re-install.


2016-08-11 21:41

developer   ~0045397

Last edited: 2016-08-11 21:42

View 3 revisions

Peke indicated that the rules were blocked after the update (Action: Block)

Fixed in build 1805.

After MM re-install the MM rules are deleted and created again.


2016-08-13 01:10

developer   ~0045408

Today MS introduced cumulative security update KB3176495 on Win 10 Pro x64 1607 that addressed many issues.


2016-08-16 09:39

developer   ~0045433

Verified 1805 and also confirmed by one of our users


2016-08-26 16:03

administrator   ~0045501

Wi-Fi sync functionality still doesn't work in my environment after installing I then tried rebooting Windows and running MMW
Windows popped up a message indicating that it was blocking certain traffic from MMW (allow local/trusted, but don't allow public). I enabled all access for testing purposes, and from this point forward Wi-Fi sync worked.

The problem is that:
a) users shouldn't have to reboot Windows
b) even if the step of rebooting windows is unavoidable, the user has no idea why Wi-Fi sync isn't working. If MMW is in a state where it is being blocked by the firewall, MMW should at least give the user some feedback to that effect so that they know to try rebooting. e.g.
MediaMonkey appears to be blocked by a firewall. See [knowlegebase]. (link to which would link to ).


2016-08-28 17:04

developer   ~0045505

Last edited: 2016-08-28 18:48

View 8 revisions

a) Based on today's intensive testing/review I probably found what could cause this.
I've done also some others improvements in this area.
So please re-test with 1807 and report whether it is all right.

b) There is a problem for MMW how to detect a blocked incoming connection.
I've spent several hours on this, but haven't found a general way for MMW to detect this situation.
The firewall rules can be set to block only 'public' or only 'wireless' incoming connections and there doesn't seem to be a way for MMW to find this.

The only way (partial solution) seems to be to use dump of Windows Firewall Rules (using command line "netsh advfirewall firewall show rule name="MediaMonkey") and parse it to detect whether MMW is set as blocked or disabled, but this would work only for Windows Firewall (not for third party firewalls). In addition this rule is auto-deleted while user accepts the elevator that creates the "MediaMonkey auto-conf *" rules. So the situation currently can happen only when user cancels the MMW elevator. In that case we could show something like:
"MediaMonkey hasn't enough rights to configure Windows Firewall, Wi-Fi sync might not work".


2016-09-02 12:56

developer   ~0045551

Verified 1807 On my PC no regression.


2016-09-02 12:57

developer   ~0045552

Reminder sent to: rusty

Can you please confirm fix on your PC that observed last report and close.


2016-09-02 18:30

administrator   ~0045553

Last edited: 2016-09-02 18:37

View 2 revisions

I'm unable to verify as the problem only occurred upon system upgrade to Windows 1607 and this is my production system.

I can, however, confirm that updating to this new version didn't cause any loss of connectivity.


2016-09-07 00:26

developer   ~0045594

Verified 1808 had one PC not upgraded yet.


2016-10-09 21:47

developer   ~0045868

Last edited: 2016-10-09 21:47

View 2 revisions

Reopen As this do not apply is PC is falsely connected to Public network.


2016-10-09 21:49

developer   ~0045869

There is nothing we can do about that as opening MMW to Public is security risk and I updated
to reflect these findings.


2016-10-09 21:54

developer   ~0045870

By default Windows treat only first connected network as Private and all others as Public.


2017-07-31 17:32

developer   ~0048428

Last edited: 2017-07-31 17:56

View 6 revisions

As discussed offline there are still users experiencing issues after MMW upgrade (e.g. ). This is most probably related to 0013261:0045392 where MMW re-creates the rules after re-install and it fails in some environments for some reason.

Basically I see three possible reasons for a failure:
1) The update (re)creates "MediaMonkey auto-conf NUMBER" rules that doesn't work for some environments (maybe the DOMAIN is missing?) as it creates only PUBLIC and PRIVATE rules?
2) The update fails to delete all the other MediaMonkey related rules that blocks the connection?
3) The update fails to create "MediaMonkey auto-conf NUMBER" rule, has not enough privilegies?

@Peke: Do you know which of these cases is the most often? i.e. based on your experiences when analyzing the user's rules?

As for the case 1) -- Maybe changing it to include protocol "Any" (not only TCP/UPD) and profile "All" (not only public/private) could solve the issues?

=> changed in build and resolved for testing


2017-08-06 12:28

developer   ~0048473

Last edited: 2017-08-06 12:45

View 3 revisions

Hmm, but I just see my note in the code "we need to add rule separatelly for 'private' and 'public', because 'any' incoming connections are auto-blocked in some environments", so I guess I will create additional 'private' and 'domain' rules separately and we will see how it is going to work in the various user environments. It seems kind of magic :-/

=> changed in build and resolved for testing


2017-08-07 03:19

developer   ~0048474

For testing purposes can you please add/create MediaMonkey Firewall group and add autoconf rules there?

That should allow us an easier tracking and managing.


2017-08-11 14:46

administrator   ~0048513

Another report:


2017-08-14 13:07

developer   ~0048532

The user indicated that the rule TCP/Private was missing. I guess that the commands for DELETE "old", CREATE "new" can run asynchronously somehow and this might be the cause of the random troubles. Looking into it...


2017-08-14 13:49

developer   ~0048533

Last edited: 2017-08-14 13:55

View 3 revisions

@Peke: Adding group is not possible

Nevertheless I changed the flow and now runs all the Netsh AdvFirewall Firewall Commands as single command line (commands separated by '&') to ensure the correct order for the DELETE+ADD. I guess it was the root of all the problems (I also simulated this once). To be confirmed by users.

Fixed in and merged to


2017-08-15 17:01

administrator   ~0048541

Last edited: 2017-08-28 22:36

View 2 revisions

Build hasn't been created yet, but I just want to revisit the idea of including this functionality in the UI since telling users to re-install to fix the issue is not intuitive (and since escalation shouldn't be forced for MM in Portable Mode).

The ideas discussed were:
a) 'Add Windows firewall exception' button

This would add/reset the firewall rule.

b) '[x] Add Windows firewall exception' checkbox

It would be enabled by default (if MM isn't in portable mode), but if the user disables it / applies it, it would remove the firewall settings, and if they enable it / apply, then it would add them back.