Uploaded image for project: 'Picard'
  1. Picard
  2. PICARD-2539

Picard crashes on huge releases if no cover art provider is active

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: High High
    • 2.8.4
    • 2.8.3
    • None
    • None
    • Linux (Fedora 36) @ x86_64, picard 2.8.3 (the last released version), all plugins are disabled.

      Attempt to tag a huge release, like 30-CDs The Complete Elvis Presley Masters causes Picard interface to freeze. The system shows the dialog "The MusicBarinz Picard is not responding". That's not a big deal, but Picard prints error to the terminal window:

      Traceback (most recent call last):
      File "/usr/lib64/python3.10/site-packages/picard/webservice/__init__.py", line 572, in _process_reply
          self._handle_reply(reply, request)
        File "/usr/lib64/python3.10/site-packages/picard/webservice/__init__.py", line 559, in _handle_reply
          handler(document, reply, error)
        File "/usr/lib64/python3.10/site-packages/picard/album.py", line 357, in _recordings_request_finished
          self._finalize_loading(error)
        File "/usr/lib64/python3.10/site-packages/picard/album.py", line 547, in _finalize_loading
          self._finalize_loading_album()
        File "/usr/lib64/python3.10/site-packages/picard/album.py", line 476, in _finalize_loading_album
          for track in self._new_tracks:
      AttributeError: 'Album' object has no attribute '_new_tracks'. Did you mean: '_load_tracks'?
      

      Some times later Picard starts to respond. I am not sure all the information is loaded correctly. If I press Ctrl+R to refresh the release, Picard prints the same stack trace and error again, and crashes:

      Traceback (most recent call last):
        File "/usr/lib64/python3.10/site-packages/picard/webservice/__init__.py", line 572, in _process_reply
          self._handle_reply(reply, request)
        File "/usr/lib64/python3.10/site-packages/picard/webservice/__init__.py", line 559, in _handle_reply
          handler(document, reply, error)
        File "/usr/lib64/python3.10/site-packages/picard/album.py", line 357, in _recordings_request_finished
          self._finalize_loading(error)
        File "/usr/lib64/python3.10/site-packages/picard/album.py", line 547, in _finalize_loading    self._finalize_loading_album()
        File "/usr/lib64/python3.10/site-packages/picard/album.py", line 476, in _finalize_loading_album
          for track in self._new_tracks:
      AttributeError: 'Album' object has no attribute '_new_tracks'. Did you mean: '_load_tracks'?
      Aborted (core dumped)
      

      See the attached picard.log.zip file for the complete Picard log and gdb.log for GDB dump of the core file.

      Another huge release, 40-CDs The Masterworks, also causes Picard to crash. Another huge release, 50-CDs The Original Elvis Presley Collection, also causes Picard crash.

      The previous Picard version, 2.8.2, behaves in the same way.

      I increased network timeout (Options → Advanced → Network → Request timeout in seconds) from 30 s to 100 s and didn't notice any change. Even 600 s din't help: Picard still crashes on huge releases.

      I tried to add not all tracks but only a small part of them, it didn't help either.

        1. gdb.log
          39 kB
        2. Picard.ini
          22 kB
        3. picard.log.zip
          2.64 MB

          [PICARD-2539] Picard crashes on huge releases if no cover art provider is active

          With the last changes also the root cause for the issue has been fixed, hence I consider this resolved.

          Philipp Wolfer added a comment - With the last changes also the root cause for the issue has been fixed, hence I consider this resolved.

          Thanks a lot, I could finally reproduce the issue and narrow it down: The issue happens if you have the options enabled to either save cover art as files or to tags, and have all cover art providers disabled (or have "local cover art" be the only provider). I only tested with cover art options completely turned off.

          The code in regards to these Album._finalize_loading calls is really awkward and needs some serious refactorings. But currently it comes down to different call order between the load of a small release, which gets loaded in one go, and loading a huge release with additional calls.

          Normal loading with single call does:

          self._run_album_metadata_processors()
          self._requests -= 1
          self._finalize_loading()

          But huge release loading does

          self._requests -= 1
          self._run_album_metadata_processors()
          self._finalize_loading()

          Because of the way the cover art logic works it also does at least a single call to Album._finalize_loading, but in case of a selected cover art provider this happens asynchronous in the background and then it's working as intended.

          Anyway, the above is more a note to myself. I have prepared a patch, but need to test this. And at some point we'll hopefully also refactor the entire logic of how plugins and cover art providers d async loading of additional data.

           

          Philipp Wolfer added a comment - Thanks a lot, I could finally reproduce the issue and narrow it down: The issue happens if you have the options enabled to either save cover art as files or to tags, and have all cover art providers disabled (or have "local cover art" be the only provider). I only tested with cover art options completely turned off. The code in regards to these Album._finalize_loading calls is really awkward and needs some serious refactorings. But currently it comes down to different call order between the load of a small release, which gets loaded in one go, and loading a huge release with additional calls. Normal loading with single call does: self._run_album_metadata_processors() self._requests -= 1 self._finalize_loading() But huge release loading does self._requests -= 1 self._run_album_metadata_processors() self._finalize_loading() Because of the way the cover art logic works it also does at least a single call to Album._finalize_loading, but in case of a selected cover art provider this happens asynchronous in the background and then it's working as intended. Anyway, the above is more a note to myself. I have prepared a patch, but need to test this. And at some point we'll hopefully also refactor the entire logic of how plugins and cover art providers d async loading of additional data.  

          Van de Bugger added a comment -

          > Can you maybe share your faulty picard.ini?

          Sure. See the attached Picard.ini. I just dropped few values which can be sensitive (oauth_* and acoustid_apikey). The problem is still reproducible with this config.

          Van de Bugger added a comment - > Can you maybe share your faulty picard.ini? Sure. See the attached Picard.ini . I just dropped few values which can be sensitive ( oauth_* and acoustid_apikey ). The problem is still reproducible with this config.

          Philipp Wolfer added a comment - - edited

          It's really strange, I have still no clue how this happens. Yes, track_ars must be set for Picard to use this code path, but that's also what I tested with. It must be some other setting being responsible, with disabling track_ars you just bypass this completely. Can you maybe share your faulty picard.ini?

          Philipp Wolfer added a comment - - edited It's really strange, I have still no clue how this happens. Yes, track_ars must be set for Picard to use this code path, but that's also what I tested with. It must be some other setting being responsible, with disabling track_ars you just bypass this completely. Can you maybe share your faulty picard.ini?

          Van de Bugger added a comment -

          Ok, I have downloaded picard-master.zip from GitHub (it seems your change is already merged to the master branch), unpack it, and run:

          $ python setup.py build
          ...
          $ cd build
          $ PYTHONPATH=./lib.linux-x86_64-3.10/ ./scripts-3.10/picard
          I: 01:05:09,893 /home/vdb/prj/Alien/picard-master/build/lib.linux-x86_64-3.10/picard/config._save_backup:375: Backing up config file to /home/vdb/.config/MusicBrainz/Picard-2.8.3.ini
          W: 01:05:55,534 /home/vdb/prj/Alien/picard-master/build/lib.linux-x86_64-3.10/picard/album._finalize_loading:542: Album._finalize_loading called for already loaded album <Album de7b5a17-1d54-40b5-bcbc-dbaf38414fa6 'The Complete Elvis Presley Masters'> at /home/vdb/prj/Alien/picard-master/build/lib.linux-x86_64-3.10/picard/album.py:361 in _recordings_request_finished
          

          Van de Bugger added a comment - Ok, I have downloaded picard-master.zip from GitHub (it seems your change is already merged to the master branch), unpack it, and run: $ python setup.py build ... $ cd build $ PYTHONPATH=./lib.linux-x86_64-3.10/ ./scripts-3.10/picard I: 01:05:09,893 /home/vdb/prj/Alien/picard-master/build/lib.linux-x86_64-3.10/picard/config._save_backup:375: Backing up config file to /home/vdb/.config/MusicBrainz/Picard-2.8.3.ini W: 01:05:55,534 /home/vdb/prj/Alien/picard-master/build/lib.linux-x86_64-3.10/picard/album._finalize_loading:542: Album._finalize_loading called for already loaded album <Album de7b5a17-1d54-40b5-bcbc-dbaf38414fa6 'The Complete Elvis Presley Masters' > at /home/vdb/prj/Alien/picard-master/build/lib.linux-x86_64-3.10/picard/album.py:361 in _recordings_request_finished

          Van de Bugger added a comment - - edited

          I have 3 private plugins. They are not proprietary, but I did not publish them yet. Anyway, I believe plugins do not cause this problem, because:

          1. All plugins (including my 3 plugins) are disabled. I specially disabled all the plugins to make sure the problem is in Picard, not in Picard plugins.
          2. Also, I removed all the plugins (by removing the plugin directory ~/.config/MusicBrainz/Picard/plugins), and the problem is still present.

          > Also does it make a difference if you load the release directly instead of get it loaded automatically by pulling in the files?

          Sorry, I do not know how to load a release directly. Do you mean I should enter release id (e. g. de7b5a17-1d54-40b5-bcbc-dbaf38414fa6) into the field right to the drop-down list with items "Album', "Artist", and "Track"? I just tried to do it, result is exactly the same: Picard prints "AttributeError: 'Album' object has no attribute '_new_tracks'. Did you mean: '_load_tracks'?" to the terminal window.

          > See code changes in pull request #2140 submitted by phw.

          Thanks, I'll try to use it.

          Meanwhile, I have some progress: If I remove my ~/.config/MusicBrainz/Picard.ini, the problem disappears. Something in the configuration causes the problem. Now I am trying to figure out what parameter is guilty in the Picard misbehavior.

          UPD: Ok, I found the key parameter: it is track_ars. If track_ars=false, the problem disappears. If track_ars=true, Picard prints the error I wrote in the top. Looks like this parameters controls loading the track artists: composers and lyricists.

          Van de Bugger added a comment - - edited I have 3 private plugins. They are not proprietary, but I did not publish them yet. Anyway, I believe plugins do not cause this problem, because: 1. All plugins (including my 3 plugins) are disabled. I specially disabled all the plugins to make sure the problem is in Picard, not in Picard plugins. 2. Also, I removed all the plugins (by removing the plugin directory ~/.config/MusicBrainz/Picard/plugins ), and the problem is still present. > Also does it make a difference if you load the release directly instead of get it loaded automatically by pulling in the files? Sorry, I do not know how to load a release directly. Do you mean I should enter release id (e. g. de7b5a17-1d54-40b5-bcbc-dbaf38414fa6 ) into the field right to the drop-down list with items "Album', "Artist", and "Track"? I just tried to do it, result is exactly the same: Picard prints " AttributeError: 'Album' object has no attribute '_new_tracks'. Did you mean: '_load_tracks'? " to the terminal window. > See code changes in pull request #2140 submitted by phw. Thanks, I'll try to use it. Meanwhile, I have some progress: If I remove my ~/.config/MusicBrainz/Picard.ini , the problem disappears. Something in the configuration causes the problem. Now I am trying to figure out what parameter is guilty in the Picard misbehavior. UPD: Ok, I found the key parameter: it is track_ars . If track_ars=false , the problem disappears. If track_ars=true , Picard prints the error I wrote in the top. Looks like this parameters controls loading the track artists: composers and lyricists.

          So I added some checks to the code that in theory should prevent the crashes. But I still see how these additional calls to Album._finalize_loading would happen in your case. My best bet is still that one of the plugins is responsible, so it would be great if you could share them.

          Philipp Wolfer added a comment - So I added some checks to the code that in theory should prevent the crashes. But I still see how these additional calls to Album._finalize_loading would happen in your case. My best bet is still that one of the plugins is responsible, so it would be great if you could share them.

          GitHub Bot added a comment -

          See code changes in pull request #2140 submitted by phw.

          GitHub Bot added a comment - See code changes in pull request #2140 submitted by phw .

          I can't reproduce this here. You have a couple of custom plugins ("Release type joiner", "Sort name fixer", "Stable lists"), could you share those? Maybe they are doing unpecpected calls to album._finalize_loading). Also does it make a difference if you load the release directly instead of get it loaded automatically by pulling in the files?

          Philipp Wolfer added a comment - I can't reproduce this here. You have a couple of custom plugins ("Release type joiner", "Sort name fixer", "Stable lists"), could you share those? Maybe they are doing unpecpected calls to album._finalize_loading). Also does it make a difference if you load the release directly instead of get it loaded automatically by pulling in the files?

            outsidecontext Philipp Wolfer
            van.de.bugger Van de Bugger
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:

                Version Package
                2.8.4