View Issue Details

IDProjectCategoryView StatusLast Update
0019279MMW 5DB / Backuppublic2023-05-18 23:21
Reporterpeke Assigned To 
PriorityurgentSeveritytweakReproducibilityalways
Status closedResolutionreopened 
Product Version5.0.3 
Target Version5.1Fixed in Version5.1 
Summary0019279: Bit depth field doesn't show for users migrating from an earlier version of MediaMonkey
DescriptionOriginal 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.
Tagstodoc-KB
Attached Files
image.png (19,434 bytes)   
image.png (19,434 bytes)   
image-2.png (18,776 bytes)   
image-2.png (18,776 bytes)   
image-3.png (10,511 bytes)   
image-3.png (10,511 bytes)   
Fixed in build2800

Relationships

related to 0019483 closedmichal 'DB / Tag mismatches' keeps showing some tracks with certain Extended tags 

Activities

Ludek

2022-07-25 11:12

developer   ~0068889

Last edited: 2022-07-25 11:39

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

peke

2022-07-25 13:13

developer   ~0068890

Last edited: 2022-07-25 13:13

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?

Ludek

2022-07-25 20:17

developer   ~0068894

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.

peke

2022-07-25 20:43

developer   ~0068895

Agreed, I wanted to make sure.

Closing

lowlander

2022-10-20 16:49

developer   ~0069890

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).

rusty

2022-10-20 17:16

administrator   ~0069891

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) ?

peke

2022-10-20 18:31

developer   ~0069894

@Michal

Can this be added during track playback or during Volume analyze?

eg. something like tagging inconsistency DB vs. Tags?

Ludek

2022-10-25 16:49

developer   ~0069967

Last edited: 2022-10-25 16:49

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?"

michal

2022-10-25 18:18

developer   ~0069973

Last edited: 2022-10-25 18:20

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.

peke

2022-10-25 23:03

developer   ~0069983

@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

michal

2023-01-10 19:52

developer   ~0070888

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.

peke

2023-05-18 23:21

developer   ~0071984

Verified 2804