View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0016497 | MMW 5 | Sync | public | 2020-04-06 22:05 | 2020-04-22 02:45 |
| Reporter | peke | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | reopened | ||
| Fixed in Version | 5.0 | ||||
| Summary | 0016497: Do not allow MM5/MM4/MMS on same PC use same Port for DLNA/Sync | ||||
| Description | If MM4 and MM5 Uses same Port for library sharing they both fail and MMA Can't sync. We should add at least MM detect other MM instance uses same port and warn user. | ||||
| Steps To Reproduce | 1. Set for example bit torrent Application (Any application that listens port can be used, in user case he had MM4 started) to use same port as MM DLNA server 2. Make sure MM5 is closed 3. Start bit torrent application 4. start MM5 5. Use MMA to access MM5 over UPnP -> Fail 6. Close MM5 7. Close Bit torrent app 8. Start MM5 9. Use MMA to access MM5 over UPnP -> All OK | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2240 | ||||
|
|
I think that the real solution is not allowing to run the two instances simultaneously (like we do in MM4). i.e. if there is '[x] Allow just one instance of MediaMonkey' checked then MM5 shouldn't be allowed to run when MM4 is running and vice-versa. |
|
|
I am not sure that it is the right solution, especially as both MM4 and MM5 can coexist together as apps. maybe simple on start probe would be simple just before MM creates/init DLNA server or when DLNA server starts Listening to a port and gets some error code. Simple return from tcpclient like https://docs.microsoft.com/en-us/dotnet/api/system.net.sockets.tcpclient?view=netframework-4.8 would be enough. Or maybe something like this examples could help https://stackoverflow.com/questions/2156151/how-to-check-if-a-tcp-port-is-available-with-delphi or https://stackoverflow.com/a/60205169 or http://synapse.ararat.cz/doku.php/start |
|
|
Sure, we could show a warning that another instance of MM is running, but is this really needed espacially when user set '[x] Allow just one instance of MediaMonkey' ? I would say that MM5 shouldn't be allowed to start in the first place. Assigned to Rusty for review. @Rusty: If you think that a warning suggested by Peke makes sense then suggest a wording. |
|
|
This issue do not have any issues with multiple MM instances started, but with fact that two instances of MM or any other application can already open port that MM is using for DLNA and Sync and MM do not check if port is open or not just tries to open port. We should implement open port checks like I pointed at 0016497:0057509 so that MM no matter what app is listening that port MM know that and do not assign port and show warning that DLNA/Sync will not be available as other app (no matter if MM4/MMS/MM5/WMP/... already uses that port). As for multiple instances started I am Ok that multiple same MM5 exe are not executed, but that is completely different issue. |
|
|
Note that it is not about opening port, but using ports. i.e. we would need to check whether another app is using the port which might not be reliable and could slow server start. |
|
|
Implemented the warning in 2240. The current message is '<servername> server could not start, port <number> is already in use' @Rusty: review the wording |
|
|
Re-opened as thinking about it better wording would be: '"<servername>" media server could not start, port <number> is already in use. Check whether another instance of MediaMonkey isn't already running or change the port in Options > Media Sharing' => Fixed in 2240 Example: https://www.dropbox.com/s/kgk8yaji7hh92l4/screenshot%202020-04-08%2023.08.04.png?dl=0 |
|
|
Verified Functionality in 2240 Assigned for feedback to Rusty on wording/clarification. |
|
|
"Media server '<servername>' could not start: port <number> is already in use. Check whether another instance of MediaMonkey is already running or change the port # in Options > Media Sharing." |
|
|
Wording updated in 2241 |
|
|
Verified Wording in 2242 |
