Those values are used by the QSettings class when it is constructed using the empty constructor.
This saves having to repeat this information each time a QSettings object is created.
Some libs (ie. Phonon) require those to be set
Context menu listing other releases is using main information from release,
often it is enough, but sometimes two or more items in the list are exactly
the same, user have to select each one to determine which is matching for him.
This patch is improving a bit the situation by adding packaging, barcode, or even
disambiguation comment if needed.
As an example, it often happens when a CD is released in jewel case and digipak,
with same label, date, country, barcode, etc..
Use more explicit '[no barcode]' instead of '[none]'.
A test case was added for this feature.
As per bitmap's review comments, I have relocated the errant space from
one file to the other.
Damn pesky spaces - always sneaking off and repositioning themselves
where you don't want 'em.
Reduce down to one counter variable.
Eliminate decrement at unqueue/increment at start request
Update counter emit aligned with counter increment/decrement.
Currently only user name/password is encrypted using HTTP basic
encryption, but user's personal data (e.g. collections) is not
encrypted.
It is now generally accepted that all personal data should be encrypted,
and this fix applies encryption to any mblogin network requests (which
implies personal data is being loaded / saved).
There are examples in MB database of two label/catalog numbers where
labels are different but catalog numbers are the same. Since these are
is stored in separate tags, this fix avoid duplicate catalog numbers.
Picard receives Labels/Catalog Number pairs and separates these into
different tags. Where a two catalog numbers are from the same Label, the
label gets duplicated in the label tag, and this fix prevents that.
Limit browser integration to localhost by default.
It can be changed in Advanced > Network > Browser Integration options.
Browser Integration options changes are now applied only after user validation.
Fix compilation flag incorrectly set by Picard, track featured artists don't indicate compilation.
Sophist explained:
Ideally the MB database would show a secondary type of Compilation accurately, but since it (presumably) doesn't, Picard tries to determine whether it is a compilation by seeing if all the tracks are by the same artist, the implication being that it is a compilation album if there are tracks with different artists.
There are a few problems with this:
1. Picard was comparing both primary and secondary track artists, so if all tracks have the same main artist but some also have featured artists (which is NOT a compilation), then Picard was flagging this (incorrectly) as a compilation.
2. Picard was not checking the release-group secondary-type field for Compilation - so e.g. a Greatest Hits album is a compilation, but since often all tracks have the same artist, Picard was flagging this (incorrectly) as NOT a compilation.
The functions _insert_bytes_no_mmap and _delete_bytes_no_mmap call
mutagen.util.lock, which in turn uses the fnctl module which isn't
available on Windows.
