View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0012837 | MMW v4 | DLNA/UPnP | public | 2015-08-31 09:19 | 2015-11-12 14:01 |
| Reporter | Ludek | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 4.0 | ||||
| Target Version | 4.1.9 | Fixed in Version | 4.1.10 | ||
| Summary | 0012837: Transcoded tracks served via UPnP may not match | ||||
| Description | There seem to be several reports the MMW Server sends a different file (audio) then file data (tags) to a client. The reason is that MM stores transcoded files to temporary directory based on its ID in database, but if a user re-scans whole database for some reason (or delete/re-add some tracks) then track ids no longer match the data in \AppData\Local\Temp\Transcoded_Media_Files\ Workaround is to clean up the \Transcoded_Media_Files\ directory. | ||||
| Additional Information | XGE-628-14642 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1765 | ||||
|
|
Fixed in 4.1.9.1755 and merged into 5.0.0 |
|
|
May I suggest that you optimize it a little in order to avoid not needed transcoding and prior to delete compare transcoded -> track added timestamp and if added is newer than delete it, otherwise use transcodded track as it is most likely the right one. |
|
|
It is covered by the MD5 hash (*.hsh files), previously the hash included only convert-settings fingerprint, the new hash includes also track length in milliseconds to fingerprint also the track. And yes, they are re-converted all (as consequence of the hash change). |
|
|
I see, you suggest to keep the old hash, but just compare timestamp of the file insertion to the library with the timestamp of the already converted temporary file. yes, this wouldn't require the needless re-convert then, but I am just not sure whether a time discrepance couldn't be an issue there (between the drive where the transcoded files resides and MM database), but this shouldn't be the case for majority of users most probably I guess I can revert the hash and change to the timestamp solution for 1756: i.e. re-convert whenever the auto-convert hash doesn't match OR the timestamp of the converted file is older than the date added to library |
|
|
As talked on IM that should work for majority of users and if not we can create new hash then and force first reconvert where along new hash introduced in fix 0012837:0042861 we will add Added timestamp to hash fo future comparison and better accurancy. |
|
|
Changed to the timestamp solution in build 4.1.9.1756 and merged into 5.0.0 |
|
|
Verified 1756 |
|
|
Re-opened, although the timestamp solution fixed the issue, I found that in some cases a confirmation dialog to rewrite the auto-converted file appears, this needs to be supressed. Fixed in 4.1.10.1765 |
|
|
To understand better: the problem there was that if user deleted whole database and created another he got another song with same id as in the old DB And for such a song there was unwanted confirmation dialog to replace the converted file in temporary directory, the fix in 4.1.10 is that the confirmation dialog doesn't appear and file is replaced. i.e. The timestamp solution is still valid |
|
|
Thank you Ludek Verified 1765 |
