Picard tries to open 192.168.1.80

As of today, when I try to do anything in Picard that launches a browser (“Lookup in Browser,” “Submit Disc ID,” “Help,” etc.), it launches a browser, but tries to load a URL beginning with 192.168.1.80, which is the local device.

I have Picard 2.13.3, running on Linux Mint 21.3. My default browser was Vivaldi, but I changed the default browser to Firefox to see what would happen. Same result, regardless of the browser.

I can’t find anyplace in Picard where this is defined, and this has not happened before. This worked correctly just a couple weeks ago. I’m not sure how to troubleshoot. Has anyone seen such behavior?

Can we have some screen shots?

Of what? I can’t think of any image that would clarify anything. In Picard, I select any function that launches a browser. Even pressing F1 for Help, which should launch the default browser to MusicBrainz Picard — MusicBrainz Picard v2.13.3 documentation, instead launches the default browser to http://192.168.1.80:[port number], which, in the case of Firefox, resolves to my Plex server.

Strangely, yesterday, when Vivaldi was the default browser, the browser would launch and display an error (which I did not screenshot). Today, Vivaldi is working correctly. When Picard launches Help, or “Submit Disc ID,” it correctly launches the browser to the correct Musicbrainz page. Firefox still launches Plex.

This all looks rather strange, not sure where it would get this IP from or why it would use it for all those URLs. Especially since e.g. the docs URLs are hard coded constants inside Picard.

Have you changed the MB server URL in the general settings?

Could you share the debug log output produced when you open something in the browser from Picard?

The first two lines resulted from pressing F1 in Picard for Help. The rest of the log was recorded when I selected Looked Up a CD, and clicked on “Submit Disc ID” in the “CD Lookup” dialog:

D: 08:50:04,054 config.event:261: Config file update requested on thread 133731138105344

D: 08:50:17,378 config.event:261: Config file update requested on thread 133731138105344

D: 08:51:14,065 disc.read:65: Reading CD using device: b'/dev/sr0'

D: 08:51:17,017 disc._set_disc_details:91: Read disc ID vP23ty6Rpr7IcJZpyfb7V1Wu6PU- with MCN 0000000000000

D: 08:51:17,023 webservice/ratecontrol.get_delay_to_next_request:127: ('musicbrainz.org', 443): Last request was 1499721 ms ago, starting another one

D: 08:51:17,025 webservice/ratecontrol.increment_requests:147: ('musicbrainz.org', 443): Incrementing requests to: 1

D: 08:51:17,889 webservice/ratecontrol.decrement_requests:155: ('musicbrainz.org', 443): Decrementing requests to: 0

D: 08:51:17,890 webservice._handle_reply:559: Received reply for https://musicbrainz.org/ws/2/discid/vP23ty6Rpr7IcJZpyfb7V1Wu6PU-?cdstubs=no&inc=artist-credits%2Blabels -> HTTP 200 (OK)

D: 08:51:17,891 webservice._handle_reply:572: Response received: {'sectors': 350614, 'releases': [{'label-info': [{'label': {'disambiguation': '', 'label-code': None, 'type-id': 'a2426aab-2dd4-339c-b47d-b4923a241678', 'sort-name': 'Musical Concepts', 'id': '800772a0-4e3f-4ef8-a826-0e4cc3faacf9', 'name': 'Musical Concepts', 'type': 'Production'}, 'catalog-number': 'MC 151'}], 'cover-art-archive': {'darkened': False, 'artwork': True, 'back': True, 'front': True, 'count': 5}, 'disambiguation': '', 'date': '2014', 'title': 'The Piper of Dreams', 'text-representation': {'language': 'eng', 'script': 'Latn'}, 'barcode': '5055354471513', 'packaging-id': 'ec27701a-4a22-37f4-bfac-6616e0f9750a', 'quality': 'normal', 'media': [{'format': 'CD', 'track-count': 17, 'title': '', 'position': 1, 'id': '65338de8-ffb0-43fc-9bca-2615df93ac76', 'format-id': '9712d52a-4509-3d4b-a1a2-67c88c643e31', 'discs': [{'id': 'vP23ty6Rpr7IcJZpyfb7V1Wu6PU-', 'sectors': 350614, 'offset-count': 17, 'offsets': [150, 18870, 41940, 62086, 87549, 100636, 123474, 153047, 188282, 239237, 276468, 287433, 294978, 301788, 315948, 326613, 340654]}]}], 'packaging': 'Jewel Case', 'asin': None, 'artist-credit': [{'joinphrase': '', 'artist': {'type': 'Person', 'name': 'Christopher Ball', 'id': 'bada67ae-c8de-4c44-ae78-b090e9b1fded', 'sort-name': 'Ball, Christopher', 'type-id': 'b6e035f4-3ce9-331c-97df-83397230b0df', 'country': 'GB', 'disambiguation': 'musician'}, 'name': 'Christopher Ball'}], 'status-id': '4e304316-386d-3409-af2e-78857eec5cfe', 'country': 'XE', 'id': '4b4cb418-8211-491b-bfbe-337fb7ba8ae6', 'status': 'Official', 'release-events': [{'area': {'type-id': None, 'type': None, 'name': 'Europe', 'id': '89a675c2-3e37-3518-b83c-418bad59a85a', 'sort-name': 'Europe', 'disambiguation': '', 'iso-3166-1-codes': ['XE']}, 'date': '2014'}]}], 'offset-count': 17, 'offsets': [150, 18870, 41940, 62086, 87549, 100636, 123474, 153047, 188282, 239237, 276468, 287433, 294978, 301788, 315948, 326613, 340654], 'id': 'vP23ty6Rpr7IcJZpyfb7V1Wu6PU-'}

D: 08:51:17,908 ui/cdlookup.restore_header_state:140: restore_state: cdlookupdialog_header_state

D: 08:51:20,117 browser/filelookup.launch:80: webbrowser2: https://musicbrainz.org/cdtoc/attach?id=vP23ty6Rpr7IcJZpyfb7V1Wu6PU-&tracks=17&toc=1+17+350614+150+18870+41940+62086+87549+100636+123474+153047+188282+239237+276468+287433+294978+301788+315948+326613+340654&tport=8000

D: 08:51:20,126 ui/cdlookup.save_header_state:147: save_state: cdlookupdialog_header_state

D: 08:51:20,132 webservice/ratecontrol._out_of_backoff:231: ('musicbrainz.org', 443): oobackoff; delay: 1000ms -> 1000ms; slow start; window size 9.000 -> 10.000

D: 08:51:20,133 config.event:261: Config file update requested on thread 133731138105344

Something else I just noticed: When Vivaldi is the default browser, the Lookup CD function correctly finds the MB release. (As I said earlier, Vivaldi is now working correctly):

When Firefox is the default browser, Lookup CD can’t find it:

This appears to be a system problem, and not an MB issue. I just clicked a link in an email (in Gnome Evolution email app), which launched Firefox (default browser at the time). It loaded Plex, rather than the actual target of the link. When Vivaldi is the default, the same email link launched the correct website.

Never. I don’t think I’ve ever even looked at that setting.

Well, never before this incident. Last night I tried switching it to the beta, but the same problem occurred. I switched it back to the non-beta, and the problem persists.