View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008341 | MMW v4 | Playlist / Search | public | 2011-09-06 19:33 | 2017-09-15 21:13 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 4.0 | ||||
| Target Version | 4.1.18 | Fixed in Version | 4.1.18 | ||
| Summary | 0008341: Find more from same Computer fails for CIFS network using IP address | ||||
| Description | If the user scans a track at \\192.168.15.21\Music\U2-Boy.mp3 and then right-clicks 'Find more from same (computer)' --> nothing happens. In that case MM should open a node with that path in the My Computer node. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1849 | ||||
| related to | 0007755 | closed | Ludek | Cannot easily access non-browsable networks |
| has duplicate | 0014379 | closed | Ludek | Find more from same doesn't work for tracks on the network |
| has duplicate | 0009671 | closed | rusty | Network Playback of track can't use Find more from Same -> Folder (My Computer) |
| related to | 0010725 | closed | Ludek | Network: Navigating, Network Shares is too slow, confusing and outdated |
|
|
I reproduced it once, but the hourglass disappeared after 30 seconds and the operation was finished successfuly. It seems that the [Netwrork > Miscrosoft Windows Network] node sometimes takes long time to enumerate/open. The next re-try is instaneous then. Supposing you can consistently replicate, could you please generate debug log? |
|
|
Testing more it seems that the first try after PC restart takes more than 30 seconds (with hourglass) while all the subsequent re-tries are instaneous until the PC is restarted again. Do you see the same? Just to be sure that we are talking about same issue? EDIT: WNetOpenEnumW takes 30 seconds for the 'Miscrosoft Windows Network' node after PC restart. |
|
|
Note: This bug just surfaced to the top because 0014379 was closed as a duplicate of this long-standing issue. Note also: the bug always occurs (whether on restart or after multiple such operations have been performed). Both Peke and I can replicate. |
|
|
Now (if the other computer on my network is turned off) seeing the issue too. Actually the enumeration of 'Microsoft Windows Network' fails completely. WNetOpenEnumW returns ERROR_EXTENDED_ERROR (1208) after 20 seconds of enumerating. After calling WNetGetLastError() with corresponding params I am getting 'Error 6118: The list of servers for this workgroup is not currently available.' Trying to expand the 'Network' node in Windows Explorer freezes too (hourglass cursor for 20 seconds ) If I turn the computer on again then the enumeration of the computers in the workgroup (in MMW) takes 20 - 30 seconds. The same time it takes when calling 'net view' from the command line. Windows Explorer (tested Windows 7) seems to cache the network resources, i.e. the hourglass appears only when expanding the 'Network' node, but in the view the previously available resource remains. So workaround for MMW could be also some kind of caching and/or an alternate enumerating (asynchronous) method. EDIT: Moved to 0010725 |
|
|
i.e. FMFS takes long time (with hourglass spinning) because it re-enumerates all network resources again. i.e. it is like if you go there through the main tree. But Windows Explorer caches the "old" resources. We need to introduce a caching too. Probably for MM5. EDIT: Rusty refers the resources that aren't enumerable. e.g. \\192.168.15.21\ manually entered to the add/re-scan dialog. While I was testing only enumerable resources -- those that are listed under the Network subnode (discovered). |
|
|
To clarify, I'm saying that any time a path is known (i.e. network discovery isn't required), MMW should be able to find the content within the network location. So if the user is able to select a track that is stored to a network location (which means that the path to the network location is known) MMW should be able to find all other tracks in that directory since discovery (and any bugs associated with network discovery) can be bypassed. |
|
|
Fixed in 4.1.18.1849 together with the caching issues (0010725) |
|
|
Verified 1849. |
