View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0019065 | MMW 5 | DB / Backup | public | 2022-05-09 20:18 | 2022-05-11 18:24 |
| Reporter | Ludek | Assigned To | |||
| Priority | immediate | Severity | crash | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 5.0 | ||||
| Target Version | 5.0.3 | Fixed in Version | 5.0.3 | ||
| Summary | 0019065: "Out of memory" crash because of massive extendedTags values in database | ||||
| Description | I have been analyzing why user's database from the ticket # 4168 resulted in "Out of memory" when loading just 30000 tracks into file listing. Then we have found that the original MM4 database had just 245 MB, but MM5.DB upgraded from MM4 has more than 7 GB !!! Analyzing it further it was shown that there are many tracks with massive "Songs.extendedTags" values. The extended tags values include whole METADA_BLOCK_PICTURE blocks of base64 encoded image data which are load to a single string to track.extendedTags field and are huge. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2624 | ||||
|
|
BTW: I believe that extended tags should be handled same way as lyrics and comment. I.e. moved to ReadLongTexts and load the long variants on demand. |
|
|
Fixed in build 2624. MM5 now ignores such large unknown text fields. "Optimize database" now checks also for these values and removes them. For this user's DB it reduced size to 118MB. I did not move extendedTags to long texts, it is risky and problematic change now (and JSONs cannot be cut to some number of chars easily, because it would destroy JSON structure). |
|
|
Verified 2624 I used same METADA_BLOCK_PICTURE to try to clutter MM5 with 16MB image base64 encoded without success. |
