View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0019279 | MMW 5 | DB / Backup | public | 2022-07-24 15:06 | 2023-05-18 23:21 |
| Reporter | peke | Assigned To | |||
| Priority | urgent | Severity | tweak | Reproducibility | always |
| Status | closed | Resolution | reopened | ||
| Product Version | 5.0.3 | ||||
| Target Version | 5.1 | Fixed in Version | 5.1 | ||
| Summary | 0019279: Bit depth field doesn't show for users migrating from an earlier version of MediaMonkey | ||||
| Description | Original Summary: Bit Depth field should be re added fro formats that support it on Rebuild library Original Description: Bit Depth field should be re added for formats that support it on Rebuild library, Old libraries do not have it and it is not shown in Bit Depth column. EDIT (by Rusty): When users migrate from an earlier version of MM to a new version that supports new tags/audio properties, the new version doesn't automatically display all of the new tags/properties for existing tracks since they're unlikely to be rescanned. | ||||
| Tags | todoc-KB | ||||
| Attached Files | |||||
| Fixed in build | 2800 | ||||
|
|
I don't think that the bit depth is related to "Rebuild library" but rather to "Re-scan" as the info is included within the file itself. So I guess that settings like this should take care of the re-scan: Options > Library [x] Update file info from tags when re-scanning files --[..] Only for files with changed timestamp or size EDIT: Testing this and re-scanning works fine to add the bit depth info. Tested with above settings with DB imported from MM4 |
|
|
Retested and you are correct. Problem is that default setting is (which do not work): Options > Library [x] Update file info from tags when re-scanning files --[X] Only for files with changed timestamp or size I guess that this is for to-doc then? |
|
|
Yes, I wouldn't change the default settings as it would result in performance penalty --> to always needlessly re-scan all files even when there hasn't been a change made to them. |
|
|
Agreed, I wanted to make sure. Closing |
|
|
As part of the upgrade process (from < MediaMonkey 5 to MediaMonkey 5) MediaMonkey should offer to rescan files for newly supported fields. Similarly to updating the database for the new version. It shouldn't be left to the user to have to change setting and rescan. Anytime MM adds newly supported fields, and user upgrades from a version that didn't support it, the install/first run process should offer to rescan files for these newly supported fields (ignoring timestamp/setting). |
|
|
Agreed. A possible approach could be that when the Database update process is run (when support for new fields are added), MM should rescan all files in the database. e.g. This version of MediaMonkey supports new tags (tag 1, tag2). Would you like to rescan all files now in order to read these tags? Possible issue: Should such a scan operation update _only_ the tags in question (i.e. to prevent unintended consequences for any tracks that have DB/Tag mismatches) ? |
|
|
@Michal Can this be added during track playback or during Volume analyze? eg. something like tagging inconsistency DB vs. Tags? |
|
|
Yep, such a tracks now appears in the FIles to Edit > DB / Tag mismatches, but can't by synced by using 'Update tags' => this will be fixed by Michal in course of 0019483:0069964 for 5.0.4 where 'Update tags' scan operation update _only_ the tags in question (i.e. to prevent unintended consequences for any tracks that have DB/Tag mismatches) For 5.1 we might want to introduce what Rusty suggested (and requires new string to localize/translate): "This version of MediaMonkey supports new tags (tag 1, tag2). Would you like to rescan all files now in order to read these tags?" |
|
|
Just note, Bit Depth is not taggable field, it is read only, so it is not compared in Edit > DB /Tag mismatches. That is why I cannot fix it there during Update tags, as such files won't be there mostly. Left for 5.0.4 as is. 0019483 will be fixed separately, it was different problem. |
|
|
@Michal Especially as like you said it is read only, why not update library accordingly on playback (that info needs to be read anyway by decoder)? It is non destructive library field just file info, Like I pointed in 0019279:0069894 |
|
|
Fixed in build 2800. Implemented Rusty's proposal. I think it is enough and allows to scan easily all files again just after DB update made in this build. Only Bit depth is updated from the files, the rest is untouched. It automatically skips e.g. all MP3s, because Bit depth is not part of this format, so it could be mostly quite fast. Note, decoder cannot update Bit depth in DB, information, that it is missing there, is not known to decoder. But I think it is not needed. |
|
|
Verified 2804 |
