E: 139836956702464 21:25:09 Traceback (most recent call last):
File "./picard/album.py", line 133, in _parse_release
run_album_metadata_processors(self, m, release_node)
File "./picard/metadata.py", line 334, in run_album_metadata_processors
processor(tagger, metadata, release)
File "./picard/coverart.py", line 178, in coverart
config.setting["caa_image_types"].split())
TypeError: descriptor 'lower' requires a 'unicode' object but received a 'str'
Counter was 0 if request queue was empty but Picard was still waiting for replies,
with this change, counter is set to 0 only if no active request left.
This fixes a regression since e16b2533c where picard no saves vocal ARs
with no type set as generic "performer" ars; appearing in the UI like
Performer []: Some Vocalist
Performer [guest]: Some Guest Vocalist
Add special handling for the vocal relationship type to use a fallback
string if there is no vocal type set. The fallback string is "vocals"
(earlier versions of picard used "vocal"), for consistancy with the
current vocal type strings, which look like "lead vocals", "background
vocals", etc.
The previous use of "selection_mutex" didn't really prevent race conditions.
The only thing really stopping them was the hackish "throttling" implemented
using self.updating and self.update_pending. If self.update was called while
another update was already in-progress, it'd set self.update_pending to True
and return, thereby reducing the chance that two update threads would execute
simultaneously.
Another thing to note is that race conditions here are almost impossible to
reproduce in CPython by default, because the interpreter only checks for
possible thread switches every 100 virtual instructions or so (configurable
using sys.setcheckinterval). Still, relying on such behavior bothers me.
The new attempt here reduces the need for locking considerably, because
instead of having a constant, shared self.tag_diff object, each update
thread creates its own and passes it on as the result.
So, selection_mutex is now simply used to protect the cached selection vars
while they're being set in _update_selection and read in _update_tags. As
mentioned, CPython's default behavior makes selection_mutex pretty much
unnecessary, but I don't think it adds much overhead given its limited use.
Tested on Mac and Windows.
Introduce helpers to clarify and fix code:
- is_front_image()
- save_this_image_to_tags()
- image_type_from_id3_num()
- image_type_as_id3_num()
Fixes:
- honor "save_only_front_images_to_tags" option for apev2 format too
- save only caa front image to tags when "save_only_front_images_to_tags" is set
and image source is CAA, use 'front' flag from json.
Other sources should have only 1 front image anyways.
The _make_filename and _script_to_filename methods actually *do* need
to be passed a custom settings dict, so that the renaming examples
can update instantly.
