Syntax Error Downloading Track if Name is Senseless UTF Garbage

[rehashedsalt]

Platform: Linux Flatpak, host OS is Fedora 40

Nuclear version: Flatpak v0.6.31

Description of the issue: This track, which is actually a real piece of music and not me making shit up, fails to download on Nuclear:

Title:    ƪ. ◖ƪ❍⊁◞.|◗щ (*ᄋ△+⁎❝᷀ົཽ*ೃ:(꒡͡ ❝᷀ົཽ ꉺ ̈.·*:・✧⃛(ཽ๑
Artist:   ⣎⡇ꉺლ༽இ•̛)ྀ◞ ༎ຶ ༽ৣৢ؞ৢ؞ؖ ꉺლ
Album:    )✧⃛*

Whenever Nuclear tries to look this track up, it fails with a syntax error:

  renderer › An error has occurred when searching for streams with Youtube for "⣎⡇ꉺლ༽இ•̛)ྀ◞ ༎ຶ ༽ৣৢ؞ৢ؞ؖ ꉺლ - ƪ. ◖ƪ❍⊁◞.|◗щ (*ᄋ△+⁎❝᷀ົཽ*ೃ:(꒡͡ ❝᷀ົཽ ꉺ ̈.·*:・✧⃛(ཽ๑."
  renderer › Error: Failed to parse contents from data. (SyntaxError: Unexpected token < in JSON at position 0)
    at file:///app/main/resources/app.asar/dist/284.b4f8447cf1c36a15b3d0.js:344619:15
    at Generator.next (<anonymous>)
    at fulfilled (file:///app/main/resources/app.asar/dist/284.b4f8447cf1c36a15b3d0.js:344568:58)

I have no further insight into why this happens, but gutfeel is maybe a sanitization issue before passing the track name into a search query.

This bug may signify a larger issue with handling certain characters in titles, but I have no evidence to support that nor any examples.

[nukeop]

As much as it sounds tempting to blame unicode in this case, I can find this artist using Discogs, and his music is found on Youtube (and encoded correctly when searching, e.g. https://www.youtube.com/results?search_query=%E2%A3%8E%E2%A1%87%EA%89%BA%E1%83%9A%E0%BC%BD%E0%AE%87%E2%80%A2%CC%9B)%E0%BE%80%E2%97%9E%20%E0%BC%8E%E0%BA%B6%20%E0%BC%BD%E0%A7%A3%E0%A7%A2%D8%9E%E0%A7%A2%D8%9E%D8%96%20%EA%89%BA%E1%83%9A%20%CC%9F%CC%9E%CC%9D%CC%9C%CC%99%CC%98%CC%97%CC%96%D2%89%CC%B5%CC%B4%CC%A8%CC%A7%CC%A2%CC%A1%CC%BC%CC%BB%CC%BA%CC%B9%CC%B3%CC%B2%CC%B1%CC%B0%CC%AF%CC%AE%CC%AD%CC%AC%CC%AB%CC%AA%CC%A9%CC%A6%CC%A5%CC%A4%CC%A3%CC%A0%D2%88%CD%88%CD%87%CD%89%CD%8D%CD%8E%CD%93%CD%94%CD%95%CD%96%CD%99%CD%9A%CD%9C%CD%A2%CD%A2%CD%A2%CD%A2%CD%A2%CD%A2%CD%A2%CD%A2%CD%A2%CD%A2%CD%A2%CD%A2%CD%A2%CD%A2%CD%85%20%E0%B0%A0%E0%B1%80%E0%A9%82%E0%B3%A7%E0%BA%B9%E0%BF%83%E0%A5%82%E0%A9%82%E2%9C%A7%E0%B7%85%CA%85%CD%A1%CD%A1%CD%A1%CD%A1%CD%A1%CD%A1%CD%A1%CD%A1%CD%A1%CD%A1%CD%A1(%C6%AA%E2%9D%8D%E2%8A%81%E2%97%9E..%E2%97%9F%E2%8A%80%20%CC%9F%CC%9E%CC%9D%CC%9C%CC%99%CC%98%CC%97%CC%96%D2%89%CC%B5%CC%B4%CC%A8%CC%A7%CC%A2%CC%A1%CC%BC%CC%BB%CC%BA%CC%B9%CC%B3%CC%B2%CC%B1%CC%B0%CC%AF%CC%AE%CC%AD%CC%AC%CC%AB%CC%AA%CC%A9%CC%A6%CC%A5%CC%A4%CC%A3&sp=EgIQAQ%253D%253D

Though I see the same error you're talking about, it's actually caused by Youtube not always returning correct json where Nuclear expects it. If you let Nuclear reload it a couple of times, I see that eventually it succeeds and can play the track.

I will leave this bug open because it reproduces and it should be eliminated nonetheless.

[rehashedsalt]

If you let Nuclear reload it a couple of times, I see that eventually it succeeds and can play the track.

Does it? I encountered the issue when a playlist I imported from Spotify stalled 45 minutes into listening. It was trying to acquire this track the whole time.

[nukeop]

Youtube is notorious for handling search and stream lookups differently based on your region, A/B tests, and other semi-random, hard to reproduce factors. So it might have worked for me, but it's completely possible that it won't work for you. Though if I fix the underlying issue, it won't have to keep retrying in the first place.