View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0015500 | MMW 5 | FileMonitor / Find Missing | public | 2019-02-24 01:05 | 2019-07-04 05:53 |
| Reporter | peke | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Target Version | 5.0 | Fixed in Version | 5.0 | ||
| Summary | 0015500: Adding some network M4A files to library is slow | ||||
| Description | When adding Network path using INS adding is too slow <1 File a second. Expected: As Folder content is already loaded using INS should use already cached Data from Current view and not fully re-scan folder. LOG File Uploaded to FTP | ||||
| Steps To Reproduce | 1. Browse network folder using Folders -> Network -> [NETWORKPATH] -> Music -> Billboard 1000 hits 2. Wait till folder is loaded and tags are read 3. Press INS 4. Select Music Type 5. Press OK Scan is too slow with rate <1 track a second | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
Based on the debug log the scanning speed is good for most of the files, but e.g. each 10th file is slow. i.e. it scans 9 files fast and on the 10th there is more than one second lag: e.g. for file \\192.168.0.250\Download\transmission\completed\!!!SerijeDownload\INGA YouTube\333. Cher Lloyd - None Of My Business.m4a 459.68542480 [3992] MP4Parser: Parse begin 461.72940063 [3992] MP4Parser: Found FTYP atom, FileSize: 3044683 i.e. it took more than 2 seconds to find FTYP atom in MP4 tag And later for the file \\192.168.0.250\Download\transmission\completed\!!!SerijeDownload\INGA YouTube\343. Justin Jesso - Getting Closer.m4a 462.19906616 [3992] MP4Parser: Atom found: meta, dataSize=519 464.42178345 [3992] MP4Parser: Atom found: hdlr, dataSize=33 i.e. another 2 seconds lag to find hdlr atom |
|
|
The slowest was \\192.168.0.250\Download\transmission\completed\!!!SerijeDownload\INGA YouTube\023. Tom Walker - Leave a Light On.m4a that took almost 4 seconds to parse. 291.67785645 [3992] f_mp4: FORMAT_OpenFile 293.20504761 [3992] MP4Parser: Parse begin 293.50537109 [3992] MP4Parser: Found FTYP atom, FileSize: 2989016 ... 294.87127686 [3992] MP4Parser: Atom found: tkhd, dataSize=92 ... 295.54382324 [3992] MP4Parser: Atom found: mdat, dataSize=2951520 |
|
|
@Peke, please upload the 3 files above somewhere and assign to @Michal then -- to look whether the M4A tag reading can be optimized -- or whether it is the network location access issue that is not fixable in MM5 ? |
|
|
Sent files to Michal offline. Network Path should not be an issue as I have 2Gbits Wired connection and in tests 100+ Megabytes/s bandwidth MM4 is scanning OK (same path) |
|
|
Peke, could you retest this? It does not seem to be problem with parser at all, as the lags were during opening file and reading first 12B, not during parsing, i.e. problematic was getting data from the http stream. There were some fixes in this, please retest, if this is still the issue, thanks. |
|
|
@Michal you are right, No issues in 2185 Tests, Resolving and closing Further tests found that MM5 is Much Slower than MM4 and that process of Manual Scanning to Library can be improved. Will be handled in New Bugs 0015820 and 0015821 |
