View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0013443 | MMW 5 | Casting (Google Cast / UPnP) | public | 2016-08-03 13:09 | 2020-07-10 00:44 |
| Reporter | Ludek | Assigned To | |||
| Priority | urgent | Severity | feature | Reproducibility | have not tried |
| Status | closed | Resolution | reopened | ||
| Fixed in Version | 5.0 | ||||
| Summary | 0013443: "Create public access" feature on media server | ||||
| Description | Currently in MM4/MM5 if one wants to add a server for public access (outside of NAT, e.g. from coffee-room) then he need to right-click 'Media Servers' node > Add Server and put the link to the device description file manually. This requires so that user knowns his public IP + the link. Better alternative would be "Create public access" feature that would be available only at home (behind the NAT) and automatically: a) finds the public IP and stores the device description link b) open ports for the server using NAT-PMP protocol for UPnP enabled routers (so that it doesn't require any manual gateway configuration) -- as in 0012826 | ||||
| Tags | todoc-KB | ||||
| Attached Files | |||||
| Fixed in build | 2230 | ||||
|
|
Added in build 2029. Leaving opened because of b) that doesn't always work and thus we need to add error handling + [Help] button with link to KB article for users to manually forward/map the port. |
|
|
Added in 2029. New strings added for error handling: '%s cannot be reached' 'To resolve go to your router configuration and enable UPnP or set up port forwarding for port %d' 'Then try it again' [Help] button goes to http://www.mediamonkey.com/connect_error where we can add KB article with link to e.g. http://portforward.com/ |
|
|
I'm going to leave this for Peke to test out, however, I would suggest a couple of design tweaks: 1) Create public access --> Configure remote access 2) '+' icon --> 'gears' icon 3) Change '%s cannot be reached.' 'To resolve go to your router configuration and enable UPnP or set up port forwarding for port %d.Then try it again.' --> 'Remote access to %s cannot be auto-configured via UPnP/NAT-PMP.' 'To resolve go to your router configuration and enable UPnP/NAT-PMP or configure port forwarding for port %d to IP address xxx.xxx.xxx.xxx and try again.' 4) A functional issue: if I'm running a UPnP server on NAS2 (a NAS--not my router), why does MM5 give a message that NAS2 cannot be reached--shouldn't it be attempting to configure port-forwarding on the _router_ rather than the NAS (port forwarding and UPnP auto-configuration _is_ enabled on the router)? note: I've added a redirect to http://portforward.com, but it is from /upnp-nat-pmp-error |
|
|
1&2) are fixed in 2033 3) OK, I changed the strings as suggested in build 2033. Note that previously I just wanted to unify the error strings with the "Add server" feature (that we have already in MM4). i.e. the situation when user is already in a public area (coffee shop) and knows the device description link in the form http://publicIP:port/DeviceDesc.xml In that case I just left: http://publicIP:port/DeviceDesc.xml cannot be reached ... [Help][OK] That said the http://www.mediamonkey.com/connect_error probably shouldn't just go to http://portforward.com but to our KB article describing this kind of error in the greater detail (to cover also the "Add server" feature). I am just thinking about the message in case of success, currently showing 'New media server has been added <servername>' (united with the "Add server" feature), but in case of "Configure remote access" it doesn't make much sense as it in fact just _publishes_ a local server so the message should be rather something like "Remote access to <servername> was successfuly configured"? => Fixed in 2033 4) To clarify how the "Configure remote access" feature works: a) MM knows http://privateIP:port/DeviceDesc.xml (thanks to the SSDP auto-discover) b) MM lookups publicIP and configures NAT-PMP table on the router to add "MediaMonkey" entry for the port to forward to the privateIP. The table of all entries can be seen e.g. by apps like Albertino Port Mapper, Port mapper, Port forward utility. c) MM tries to access the http://publicIP:port/DeviceDesc.xml to see whether the configuration was correct, note that it always tries to access (even in case of NAT-PMP failure), because user could set port forwarding manually (or DMZ) and it could work even without NAT-PMP d) in case the c) was successful then MM adds the publicIP:port/DeviceDesc.xml into database and use this server permanently under MediaServers node (together with the local that are auto-discovered) I added more debug messages to build 2033 to see why it fails for your NAS. Note that if you have more routers in a row (serially plugged) then MM can config NAT-PNP only on the nearest gateway router, but maybe there are father routers behind that are filtering the packets. Note that e.g. on my router the NAT-PMP sometimes doesn't work and if I disable UPnP and enable it again then it is working again. I also attached a screenshot what UPnP PortMapper utility shows when NAT-PNP cannot be configured, we should add something similar to the KB article. |
|
|
1/2) The context menu entry to 'Configure remote access' should be added explicitly (not as a contextual entry) to the device entry that appears in the tracklist (as a 'gear' icon to the right of the server name) since users will not realize the existence of a context menu in Touch mode. 3) Suggested text seems reasonable. Also, I've updated the KB article for UPnP client connection issues. Please review. Also, note that it is linked via: http://www.mediamonkey.com/upnp-client-connect-error 4) I've attached a log file (line 2071). 5) I've added a new bug re. improvements to the related Add Media Server dialog |
|
|
1/2) I rather moved it to overflow menu so that user can see also the legend "Configure remote access" otherwise one would think that the "gear" icon is something about server options. We could add further items to the overflow, e.g. "Pin it"? 3) The KB article looks good, but there is an additional "1." See the red circle on the attached screenshot natpnp.png to see what I mean. 4) I see an exception in the log when creating COM object HNetCfg.NATUPnP. It seems that your router either does not support NAT-PMP/UPnP ot it is disabled on the router. I guess that if you download either: "PortForward utility": http://www.codeproject.com/Articles/13285/Using-UPnP-for-Programmatic-Port-Forwardings-and-N or "Albertino Port Mapper" utility: http://www.softpedia.com/get/Network-Tools/Misc-Networking-Tools/Albertino-Port-Mapper.shtml that you are also unable to set it up, right? I wonder what kind of error these apps show? Are you sure that you are accessing the "public" router and not a sub-router? Maybe disabling the UPnP an re-enabling could also does the trick for you (as was in my case)? |
|
|
1/2) OK, but note that I don't see the overflow menu in build 2036. 3) Clicking help in the error dialog still links to http://www.mediamonkey.com/connect_error ! Re. the KB Article, thanks-I fixed the formatting. 4) My router does support UPnP, and I've enabled the relevant option: http://www.asus.com/support/FAQ/114484 However, when I test with UPnP Port Mapper, although it successfully retrieves port mappings, it can't save them due to an error related to failure to detect the routers _internal_ address. So I guess it's not an MM5 bug, though others will have to test this out. |
|
|
Re 1/2 ,3: 2036 is one week old, I've fixed them yesterday -- so you will need 2037 to test these. 4) OK. I expanded the log messages further for 2037, so please generate one more log with 2037, but probably nothing more we can do ATM. |
|
|
Tagging as resolved since this is actually fixed (issue 4 isn't an MM issue). When I test it out I'll generate a log, but as I said testing with other products confirms that it's not an MM issue. |
|
|
1-2): Upon starting MM5 and clicking the overflow button, an AV occurred and MM5 was frozen. Debug / crash logs attached. 4) New debug log attached. 5) The 3-dot overflow menu isn't aligned correctly with the text of the server name. 6) Because the server name is in blue, it is sometimes completely obscured. e.g. 1 select the server 2 click 'configure remote access' > OK --> Server is selected in a tone of blue that obscures the server name completely note: the server name can also be _partially_ obscured by visiting the content of the server and then going back to the servers dialog. |
|
|
1/2, 5&6 are fixed in 2040 4) I see in the log "The requested resource is in use" either for HNetCfg.NATUPnP COM object or StaticPortMappingCollection. I added further messages to see for which one from these it is. Anyhow it is strange that Albertino Port Mapper was even able to get the port mapping collection, but maybe the Albertino could somehow block the resource? If you have a chance you can generate another log using 2040+ while keeping the Albertino mapper app closed. |
|
|
Re-opened: 7) there is a crash ( 0D782E98 ) when user is not connected to the internet. 8) User's are unaware what this feature does, it was suggested to add a tooltip, but IMO better would be to add confirmation dialog with the explanation what is going to be auto-configured. Details at https://www.mediamonkey.com/forum/viewtopic.php?f=30&t=96037&p=465749#p465747 |
|
|
7) Fixed in 2230 8) Implemented in 2230 using this confirmation dialog: https://www.dropbox.com/s/456ud6e5ejffof4/screenshot%202020-03-04%2017.36.31.png?dl=0 And this dialog is shown in case of successful auto-configuration: https://www.dropbox.com/s/sbqnnyltauzqfjt/screenshot%202020-03-04%2017.09.13.png?dl=0 |
|
|
I've adjusted the wording a bit for grammar and to clarify what's being configured: server vs network vs client / UPnP vs generic remote access. Btw, is there also a message if the user tries to configure remote access from the remote location (rather than from the local network)? -- This will auto-configure rules on your router to allow the '<device name>' UPnP/DLNA server to be accessible from a public/external network (using UPnP/NAT-PMP). Do you want to proceed? -- Remote UPnP/DLNA access to '<device name>' was successfully configured. If you want to use another UPnP/DLNA client to remotely access '<device name>', enter the following server destination to the client: _http://......._ -- Remote access to '<device name>' could not be auto-configured via UPnP/NAT-PMP. To resolve, enable UPnP/NAT-PMP in your router configuration or manually configure port forwarding on your router and try again: port 8200 to IP address 192.168.0.147 |
|
|
ok, adjusted the wording as suggested by Rusty. => Fixed in 2230 >> Btw, is there also a message if the user tries to configure remote access from the remote location (rather than from the local network)? No, there is no message, but in fact MM5 cannot know whether user is sitting at home or whether he is sitting in a public location. But in the public location mostly no servers are auto-discovered (to be configured for remote access) except for the servers running on the same laptop, but for those the explanatory text says "This will auto-configure rules on your router ... " So it is self-evident that your router cannot be configured from a public location. If you think that it is not self-evident then we might want to adjust the explanatory text further. |
|
|
hmm... it probably won't be self-evident for less technical users. This might be more clear--or do you think it's overkill? This will auto-configure rules on your router to allow the '<device name>' UPnP/DLNA server to be accessible from a public/external network. Configuration is via UPnP/NAT-PMP which only works if this device is on the same network as the router. Do you want to proceed? |
|
|
Sounds good, added in 2230 |
|
|
Verified 2234 I agree for now it is ok. Simpler way to of configuration should be reserved for future versions. |
|
|
Re verified 2259 Closing even some users confirmed that it works. |
