View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010031 | MMA | Synchronization | public | 2012-11-22 02:00 | 2013-01-10 01:20 |
| Reporter | rusty | Assigned To | |||
| Priority | high | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 1.0.1 | ||||
| Target Version | 1.0.1 | Fixed in Version | 1.0.1 | ||
| Summary | 0010031: Errors/Debug logs whenever UPnP/sync servers are enumerated in some environments | ||||
| Description | Every time I sync with build 63 debug logs are uploaded, numerous times e.g. upon navigating the server, upon syncing, on completion of syncing, etc... Note that no user-visible errors occur. However, the fact that error logs are being continually generated seems to imply that something is always going wrong. note: tested against build 1606 | ||||
| Additional Information | Could it be related to 0009915 ? | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 81 | ||||
|
|
I went through the logs and there are two categories of exceptions: 1. During download of autoconverted tracks - media is on list of prepared tracks but when MMA tries to download it, MMA still gets the 202 response code, i.e. it is not ready. 2. Timeouts during waiting on response on metadata upload or modifications upload. The timeouts are set to 20 seconds. |
|
|
Re 1. I will verify the workflow on the MMW side and (I see some glitches there to fix them for 1608) Re 2. I just tested it myself and the processing rate is 150 tracks per second on my machine. So 20 seconds would take processing of 3000 tracks. Marek, I haven't tested 3000 tracks, but do you send it in batches (100 or 1000 tracks at once?). I would say that e.g. 300 tracks at once would be effective as it should take about 2 seconds to process it on MMW side. |
|
|
@Rusty, could you post debug log from MMW to see a possible reason? I guess you don't have 3000 tracks in device? |
|
|
2. I was wrong. In this case, default timeout was used. I implemented uploading in batches to guarantee that MMW manages to send response in time. I prolonged the timeout too. |
|
|
OK, so I guess this can be resolved and re-tested by Rusty in next MMW/MMA builds, i.e. MMW 1608 / MMA 65 |
|
|
tested in build 66, and this is still the case for: - each time the user clicks the UPnP node - When the user clicks the 'Sync Now' node for the first time (causing the list of servers to display) OR each time the user clicks 'Select Sync Server' i.e. it's somehow related to checking for what UPnP servers exist. Note: I have 3 servers: WMP, TwonkeyMedia, and MediaMonkey. BUT the bug occurs even when I disable each of them. i.e. it's something else in the network environment that's causing this. |
|
|
Fixed in build 72 Upgrade of cling library |
|
|
Unfortunately, build 72 still exhibits this problem. |
|
|
Rusty, does it happen if you turn off all computers running Windows 8? I remember that WMP returned IPv6 in Win8 and it might cause the exception in Cling? Are you able to browse WMP? |
|
|
Yes it occurs when _all_ UPnP/DLNA media servers (incl. Win8) are disabled. And I'm able to browse in MM, WMP, and Twonky no problem. But keep in mind that the error doesn't occur on browsing the content of a server--it occurs when the servers are enumerated--even if no servers are found. |
|
|
p.s. another possibility (outside of this being caused by UPnP) is that this is related to the problem where the icons on the list of servers were drawn incorrectly and kept changing (0009971). |
|
|
OK, so it occurs even if all servers (including both hardware and software) are turned off? i.e. just your router/access point is running and it still happens? Does it happen with all your android devices or just e.g. Android OS 4.2 ? I guess that with release version you don't observe any issues? So probably as it happens only to you, and the bug is somewhere deeper in Cling and we cannot fix it then I would suggest to lower priority of this issue. |
|
|
The bug occurs on both GB and JB devices. I'm unable to test with _everything_ off right now (I don't own some devices on the network). The release version works fine--the only reason I thought it was important is that this will make it difficult to get a handle on our bug reports if hundreds of such issues are being reported. i.e. our goal should be to get bug reports approaching 0/day. But if we're getting a lot of these, then we're going to be wasting a lot of time verifying that these are items that we don't want to fix. edit: would it make sense to suppress these logs? |
|
|
Fixed in build 81 |
|
|
Verified 90 |
