View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0014880 | MMW 5 | Tagging / organizing (properties / auto-tools) | public | 2018-06-16 00:39 | 2020-03-12 01:34 |
| Reporter | peke | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Target Version | 5.0 | Fixed in Version | 5.0 | ||
| Summary | 0014880: Sync Tags: Sync tags fail in some cases | ||||
| Description | If Path+Filename is >251 and MMW needs to use Temp file to write tags (eg. .xxxxx) than tagging fail due the fact that Filename pass 255 Characters and MMW fail to write such file. Either We Should use Shorter Temp name or We do not use Unicode filenames in Conversion. | ||||
| Additional Information | JFR-421-96364 MMW always reported unsynced tracks due the this bug | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2114 | ||||
| related to | 0008020 | closed | michal | MMW v4 | f_video: MM is not importing/playing some MOV Files |
| related to | 0011799 | closed | Ludek | MMW v4 | Scanning: Full filename and path larger than 260 chars can result in MMW crash |
| related to | 0014487 | closed | michal | MMW v4 | MP3 file may be deleted by tagging when locked (with the new id3lib) |
|
|
Peke, I cannot replicate, I've tested with path long 251 chars: C:\Temp\LongPath\LongPath\aaaaaLongPath\LongPath\LongPath\Lon555gPath\LongPath\LongPath\LongPath\LongPath\ongPath\LongPath\aaaaaLongPath\LongPath\LongPath\LongPath\LongPath\LongPath\LongPath\LongPath\ongPath\LongPath\aaaaaLongPath\03 Bathroom Girl.mp3 and before passing to the MP3 plugin MM creates short path version (8.3 alias) like this (225 chars): C:\Temp\LongPath\LongPath\AAAAAL~1\LongPath\LongPath\LON555~1\LongPath\LongPath\LongPath\LongPath\ongPath\LongPath\AAAAAL~1\LongPath\LongPath\LongPath\LongPath\LongPath\LongPath\LongPath\o ngPath\LongPath\AAAAAL~1\03BATH~1.MP3 and tags the file successfully. Have you tested this yourselve? User from JFR-421-96364 indicates that " The changes we made did not solve the problem I am having" so probably user has another issue (not related to path+filename Windows length limit)? |
|
|
Otherwise id3lib.dll seems to be using the '.XXXXXX' suffix while tagging. We should probably adjust it and instead of 'filename.mp3.XXXXXX' we could use just 'filename.XXX' as the temporary file and this way the filename length would be the same? Assigned to Michal for revision and fix in id3lib. |
|
|
Yes I tested it personally, I had 2h Remote session with user and can repeat it if needed. Problem was with FLAC files also not just with MP3. |
|
|
ok, left assigned to Michal to revise the plugins, but I would rather fix this for MM5 because: a) the issue probably appears only on systems when 8.3 aliasing is disabled b) the change might be risky because of new compiler for id3lib, details in in 0014487 |
|
|
Re a) tested using plain Delphi code and 8.3 can be force created on request by delphi do not know why it works as like you pointed it should not work I have disabled it on all of my volumes https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff633453(v=ws.10) and https://support.microsoft.com/en-gb/help/121007/how-to-disable-8-3-file-name-creation-on-ntfs-partitions |
|
|
Fixed in build 2114 by using "\\?\" prefix instead of unreliable and not always possible shortening by 8.3 names. The change is very risky and problematic for MM4, so leaving only for MM5. |
|
|
OK, to be tested on various systems. In case of issues we could add [x] Ignore files with paths longer than 256 chars checkbox to Options > Library just below the checkbox '[x] Ignore files shorter than [15] Seconds' |
|
|
Verified 2114 Looks stable, tested on various Folder operations and file scanning |
|
|
Re verified 2231 Even there was some reports for MM4 in remote sessions I confirmed that MM5 do not observe same issues on same folders. |
