Hi,
When I’m using the manual lookup, sometimes the program will just exit (crash) with no notification, losing all other work that has been done. I couldn’t find a pattern, it seems random to me.
Using the latest version (2.2).
I’d be happy to get feedback, or if this is a known issue.
Thanks!
how many songs are you trying to look up in one hit?
Thanks for reporting. We need to get more information in order to find the cause for the crashes:
-d parameter and make it crashOn Windows you can open a “Command Prompt” window and type "C:\Program Files\MusicBrainz Picard\picard.exe" -d, then press Enter:
This will output a lot of information. Now make Picard crash and post the output (a screenshot is fine) here. I’m mostly interested at the last lines of the output, directly before Picard crashed.
Crashes like this can also be caused by plugins. Please try disabling all plugins and see if the issue goes away. If this fixes the issue, try enabling the plugins one by one again, this should help to figure out which plugin is affected. Also make sure to have all plugins updated, often issues are fixed in newer versions.
Before I read the replies I removed the ‘wikidata genre’ for other reasons and so far I haven’t been able to replicate the problem.
However I also made changes to that particular music folder that contained a few hundred files, so I don’t know if the plugin is to blame.
I’ll experiment some more and keep you posted.
If I get the bug again I’ll post the debug info here.
Thanks for the help so far.
Okay, so I’m back with some more information.
I had no trouble for a while now and managed to go through over 20k files with relative ease.
Now I’m down to a small folder of unsorted files, about 700 songs.
I had some weird experiences with the songs here. In the beginning, every time I made the program automatically lookup song information for the entire folder and then start to look up for songs manually at the same time, it would randomly crash at some point, either when I opened the manual lookup window or sometime after it would close just by itself.
Eventually, I just let it finish, saved everything first and only then continued with one by one lookup.
But unfortunately, I still got a crash. Luckily this time with the debug window open.
So here’s a picture of the debug window after the last crash when using the “search similar tracks” window:
I’m running Windows 7 64bit, MusicBrainz Picard 2.2.2.
I haven’t disabled any plugins just yet, I want to hear your feedback on the debug info first.
Looking forward to hearing back
try with just that song Ooh La La you will probably crash as soon as you try some plugins dont like certain songs. if it is that song you may just need to skip it till you remove the apiseeds lyrics plugin. or till someone can give you a way to fix the problem.
post the image of command prompt here when you do it that way it can be compared to the other one
Thanks a lot for this. Unfortunately this output does not contain a crash reason. If Picard just closed without any further details in the log this would indicate it crashed due to some memory access / threading issue, which is kind of hard to debug if it cannot be reproduced on the development machine. That this does happen randomly also is an indication for this.
For me to better understand under which circumstance this happens: You say this is mostly happening when using the “manual lookup window”. Just so that I understand you correctly, you mean the search result window Picard opens when searching for an album in the search box, right? This one:
Hi,
So I wasn’t able to recreate this with the song st3v3p mentioned, but I did with another song -
.
It opens the window and I guess it crashes when trying to populate results.
I actually got a video capture of what I’m doing when it crashes. I put the video and song on Google drive -
https://drive.google.com/drive/folders/14FLHhHjivqbwh7uLESqP1jw8jX3KysNC?usp=sharing
Thanks a lot for this, this is very helpful. I could identify the issue, I will look into fixing this later.
Anyone have issues with a crash / quit when searching for tracks?
Searching for Albums or Artists is seamless. But track searching will bring up the dialog box, start to search and then blip! poof! 
GAME OVER.
we need more info to help.
like @outsidecontext said up near the top
post an image here of Command Prompt or Terminal when it happens.
if you need the commanded for Terminal you will need to ask as i dont know it.
This is exactly the issue this thread is talking about: Searching in the search dialogs frequently crashes Picard. The issue is present in all three dialogs (track, album, artist), but since it is somewhat timing dependent the experience can be different on different systems.
Anyway, the issue is fixed in the code already (see bug report I linked above) and the fix will be included in Picard 2.2.3 to be released soon.
FWIW, I’ve only ever had issues with Track searches, and it appears that I have installed that fix already. Hmmm…
D: 03:12:08,018 ui.searchdialog.save_table_header_state:424: save_state: artistsearchdialog_header_state
D: 03:12:24,934 webservice.ratecontrol.get_delay_to_next_request:115: ('musicbrainz.org', 443): Last request was 19764 ms ago, starting another one
D: 03:12:24,934 webservice.ratecontrol.increment_requests:135: ('musicbrainz.org', 443): Incrementing requests to: 1
D: 03:12:25,466 webservice.ratecontrol.decrement_requests:143: ('musicbrainz.org', 443): Decrementing requests to: 0
D: 03:12:25,467 webservice._handle_reply:414: Received reply for https://musicbrainz.org:443/ws/2/recording?limit=25&dismax=true&query=pac%5C-man fever: HTTP 200 (OK)
D: 03:12:25,478 ui.searchdialog.restore_table_header_state:415: restore_state: tracksearchdialog_header_state
Traceback (most recent call last):
File "picard/webservice/__init__.py", line 442, in _process_reply
File "picard/webservice/__init__.py", line 429, in _handle_reply
File "picard/ui/searchdialog/track.py", line 138, in handle_reply
File "picard/ui/searchdialog/track.py", line 146, in display_results
File "picard/ui/searchdialog/__init__.py", line 238, in set_table_item
File "picard/ui/searchdialog/__init__.py", line 189, in to_seconds
ValueError: invalid literal for int() with base 10: '3m49s'
Abort trap: 6
logout
Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.
Deleting expired sessions...25 completed.
[Process completed]
/me goes looking at lines of code…
File "picard/ui/searchdialog/__init__.py", line 238, in set_table_item
item = SortableTableWidgetItem(to_seconds(value))
File "picard/ui/searchdialog/__init__.py", line 189, in to_seconds
seconds = seconds * 60 + int(part)
Quite a while back I made some changes in util/_init_.py for display time/length… and I’ve not had any issue anywhere else ~length is displayed … Hmmm…
ms = float(ms)
if ms == 0 and not display_zero:
return "?m??s"
duration_seconds = round(ms / 1000)
if duration_seconds < 3600:
minutes, seconds = divmod(duration_seconds, 60)
return "%dm%02ds" % (minutes, seconds)
else:
hours, remainder = divmod(duration_seconds, 3600)
minutes, seconds = divmod(remainder, 60)
return "%dh%02dm%02ds" % (hours, minutes, seconds)
Ok, this crash is something different. But yes, this is caused by your changes to format time. Looking at this it is kind of a bad idea of the searchdialog to rely on the value of ~length, we can fix this. But in your case either change format time back to default or patch the to_seconds function in picard/ui/searchdialog/__init__.py line 189 to deal with your format.
Okay, now I see it:
for part in timestr.split(':'):
So… I need to “timestr.split” on two separators, m, and s. and I would then imagine that the math is doing something with the minutes side, to get the multiples of 60 and then the remainder for the total.
Would I be correct in saying that the way the code is now it would not handle a track with more than 00:59:59 … or in my case, 59m59s.
A track60+ mins long would probably not be pretty common. 
So, how to adapt that .split() to do on h m and s instead of just :.
I imagine then, something like, if I’m interpreting the python docs accurately.
def to_seconds(timestr):
if not timestr:
return 0
seconds = 0
for part in timestr.split('h|m|s|'):
# for part in timestr.split(':'):
seconds = seconds * 60 + int(part)
return seconds
Or replace h m and s with : and then let it do what it already does.
…or change the part of the code that writes the time to the filename instead. That’s the reason I did the change. Too much voodoo with illegal characters for FAT32, but not HFS+ etc, and I didn’t like the substitute of 00_04_20 on the file system with the replace Windows illegal characters, or OSX automatically making the colon into a forward slash. That looks even worse to me than the underscore.
I have merged a fix for this (see commit 7292c11). This fix is somewhat different, as it refactors the sorting code of the search dialogs and gets rid of the problematic to_seconds alltogether 
If you still want to do the programming exercise of fixing the function, I would split your time string with something like:
re.split("[hm]", "1h42m4s".rstrip("s"))
The rstrip takes care of the trailing s, the re.split(“[hm]”, …) then splits on both an “h” and an “m”. So the result is the expected ['1', '42', '4']. The rest of the function should keep working as before.
More use of the new natsort. 