1
0
Fork 0
mirror of https://github.com/Lidarr/Lidarr.git synced 2026-03-03 00:26:58 -05:00

Lidar fails on searches with +,-,etc .. #283

Open
opened 2026-02-20 11:20:44 -05:00 by deekerman · 9 comments
Owner

Originally created by @mediabot on GitHub (Jul 5, 2018).

Searching for albums with special character fails and a user is unable to select the ablum during a mail search

To Reproduce
Steps to reproduce the behavior:

  1. Select an artist like Ed Sheeran
  2. Let the automated search begin
  3. Automated Search will come back with not select the results
  4. Manual Search will see the results but will not let you select a result

Expected behavior

Should be able to select albums with special characters

Screenshots
screenshot_2018-07-05_16-57-34
screenshot_2018-07-05_16-58-26

System info (please complete the following information):

  • Lidarr Version: Version 0.3.0.430
  • Mono Version: 5.12.0.226
  • Ubuntu 18.04

Additional context

NA

AB#442

Originally created by @mediabot on GitHub (Jul 5, 2018). Searching for albums with special character fails and a user is unable to select the ablum during a mail search **To Reproduce** Steps to reproduce the behavior: 1. Select an artist like Ed Sheeran 2. Let the automated search begin 3. Automated Search will come back with not select the results 4. Manual Search will see the results but will not let you select a result **Expected behavior** Should be able to select albums with special characters **Screenshots** ![screenshot_2018-07-05_16-57-34](https://user-images.githubusercontent.com/13137007/42347710-b6fcebea-8074-11e8-9097-cf2df720b096.png) ![screenshot_2018-07-05_16-58-26](https://user-images.githubusercontent.com/13137007/42347712-b71d7086-8074-11e8-9504-714fc6cc21ad.png) **System info (please complete the following information):** - Lidarr Version: Version 0.3.0.430 - Mono Version: 5.12.0.226 - Ubuntu 18.04 **Additional context** NA [AB#442](https://dev.azure.com/Servarr/7ab38f4e-5a57-4d70-84f4-94dd9bc5d6df/_workitems/edit/442)
Author
Owner

@Qstick commented on GitHub (Jul 6, 2018):

In Lidarr's eyes "divide" does not equal the division symbol. We need to implement some mapping or alternative titles to make this better.

@Qstick commented on GitHub (Jul 6, 2018): In Lidarr's eyes "divide" does not equal the division symbol. We need to implement some mapping or alternative titles to make this better.
Author
Owner

@mediabot commented on GitHub (Jul 7, 2018):

That would be great or allow some exceptions flow something like:

DIdn't find a match but these came back
Allow the user to select one
after the download is complete use audiofinger printing to determine what the item is
import

@mediabot commented on GitHub (Jul 7, 2018): That would be great or allow some exceptions flow something like: DIdn't find a match but these came back Allow the user to select one after the download is complete use audiofinger printing to determine what the item is import
Author
Owner

@alagave commented on GitHub (Jul 12, 2018):

This is a serious issue. I might suggest that the different UNIX/Windows/Apple user environments will require some standard mappings, perhaps controlled by a user toggle control. Many album names contain "?", ":", "/", "" or "..." (that's question mark, colon, forward slash, back slash and ellipsis} in the name. This violates Windows file naming conventions so it falls on us to find a way to address this since we cannot restrict the artists or record labels creativity:)

Some collectors do not want hyphens in the song title or album name since that is often used as a delimiter in MP3 tag determination. And yes, I rely on MP3 tagging software to maintain my tags. To standardize, some use a semicolon to replace the colon, just leave off the question mark and use an underscore to replace the ellipsis. A user-based configurable translation table could address this. Some standard translations could be defaulted.

And then, there are non-English album names and song titles. All too often, they are anglicized because we are lazy and our English-centric keyboards, displays and software don't help. A volunteer-based translation table could be used to solve this.

This issue will become a serious block if not addressed now, before the Various Artists and Compilation work really gets going.

@alagave commented on GitHub (Jul 12, 2018): This is a serious issue. I might suggest that the different UNIX/Windows/Apple user environments will require some standard mappings, perhaps controlled by a user toggle control. Many album names contain "?", ":", "/", "\" or "..." (that's question mark, colon, forward slash, back slash and ellipsis} in the name. This violates Windows file naming conventions so it falls on us to find a way to address this since we cannot restrict the artists or record labels creativity:) Some collectors do not want hyphens in the song title or album name since that is often used as a delimiter in MP3 tag determination. And yes, I rely on MP3 tagging software to maintain my tags. To standardize, some use a semicolon to replace the colon, just leave off the question mark and use an underscore to replace the ellipsis. A user-based configurable translation table could address this. Some standard translations could be defaulted. And then, there are non-English album names and song titles. All too often, they are anglicized because we are lazy and our English-centric keyboards, displays and software don't help. A volunteer-based translation table could be used to solve this. This issue will become a serious block if not addressed now, before the Various Artists and Compilation work really gets going.
Author
Owner

@Qstick commented on GitHub (Jul 15, 2018):

@alagave most of the windows file name bad guys are addressed here already: github.com/lidarr/Lidarr@5ce214aa8a/src/NzbDrone.Core/Organizer/FileNameBuilder.cs (L242)

This is a toggle setting in media management to enable above mapping. I agree with need to expand this and make the mappings somewhat user customizable.

@Qstick commented on GitHub (Jul 15, 2018): @alagave most of the windows file name bad guys are addressed here already: https://github.com/lidarr/Lidarr/blob/5ce214aa8a5b184581d11c205c929b70168ebc17/src/NzbDrone.Core/Organizer/FileNameBuilder.cs#L242 This is a toggle setting in media management to enable above mapping. I agree with need to expand this and make the mappings somewhat user customizable.
Author
Owner

@mediabot commented on GitHub (Jul 16, 2018):

That would be awesome, the same thing happens with the artist P!nk. The software breaks the automation here and doesn't find anything but manually searching for pink and then manually importing works.

@mediabot commented on GitHub (Jul 16, 2018): That would be awesome, the same thing happens with the artist P!nk. The software breaks the automation here and doesn't find anything but manually searching for pink and then manually importing works.
Author
Owner

@rcdailey commented on GitHub (Apr 20, 2019):

Similar to this, is the fact that normal searches for new artists fail on - characters:

image

I had to use the \ character to escape the hyphen. Searches should treat input characters literally; a hyphen symbol should not cause this behavior.

Is this the same root cause? If not, I can open a new issue. Let me know.

@rcdailey commented on GitHub (Apr 20, 2019): Similar to this, is the fact that normal searches for new artists fail on `-` characters: ![image](https://user-images.githubusercontent.com/1768054/56458173-f0304080-6348-11e9-8140-80f272b8bcd9.png) I had to use the `\` character to escape the hyphen. Searches should treat input characters literally; a hyphen symbol should not cause this behavior. Is this the same root cause? If not, I can open a new issue. Let me know.
Author
Owner

@nopoz commented on GitHub (Oct 3, 2023):

Just to add some technical details to this existing bug ticket, Lidarr is not passing all the required characters to the Indexer.

Here is an example of Lidarr passing the search to Prowlarr with the example artist "Boys Noize" and album title "+/-"

Doing a packet capture of Lidarr sending the request to Prowlarr, the API call in the packet capture is:

/9/api?t=music&cat=3000,3030&extended=1&apikey=<key>&offset=0&limit=100&q=&artist=Boys%20Noize&album=%20%E2%88%95%E2%88%92

Percent decoding the string "%20%E2%88%95%E2%88%92" this equals " ∕−". Prowlarr reports in the web UI "History" the album name search as "/-". Since the album string is missing the necessary "+" character, the search returns no results. To correctly percent encode "+/-", the string should be "%2B%2F%2D".

If I manually do a search in Prowlarr for {Artist:Boys Noize}{Album:+/-} I find results as expected. The API call made by the Prowlarr UI is:

/api/v1/search?query={Artist:Boys Noize}{Album:+/-}&indexerIds=9&categories=3000&type=music&limit=100&offset=0
@nopoz commented on GitHub (Oct 3, 2023): Just to add some technical details to this existing bug ticket, Lidarr is not passing all the required characters to the Indexer. Here is an example of Lidarr passing the search to Prowlarr with the example artist "Boys Noize" and album title "+/-" Doing a packet capture of Lidarr sending the request to Prowlarr, the API call in the packet capture is: ``` /9/api?t=music&cat=3000,3030&extended=1&apikey=<key>&offset=0&limit=100&q=&artist=Boys%20Noize&album=%20%E2%88%95%E2%88%92 ``` Percent decoding the string "%20%E2%88%95%E2%88%92" this equals " ∕−". Prowlarr reports in the web UI "History" the album name search as "/-". Since the album string is missing the necessary "+" character, the search returns no results. To correctly percent encode "+/-", the string should be "%2B%2F%2D". If I manually do a search in Prowlarr for {Artist:Boys Noize}{Album:+/-} I find results as expected. The API call made by the Prowlarr UI is: ``` /api/v1/search?query={Artist:Boys Noize}{Album:+/-}&indexerIds=9&categories=3000&type=music&limit=100&offset=0 ```
Author
Owner

@JamzTheMan commented on GitHub (Nov 18, 2024):

Adding/bumping because I the same issue still. I keep finding my indexers will strip special characters, so Lidarr fails to find Ol’ Dirty Bastard but a manual Prowler search of Ol Dirty Bastard

Can we have an option to strip special characters on index searches and/or have it search both with and without special characters?

@JamzTheMan commented on GitHub (Nov 18, 2024): Adding/bumping because I the same issue still. I keep finding my indexers will strip special characters, so Lidarr fails to find `Ol’ Dirty Bastard` but a manual Prowler search of `Ol Dirty Bastard` Can we have an option to strip special characters on index searches and/or have it search both with and without special characters?
Author
Owner

@bakerboy448 commented on GitHub (Nov 18, 2024):

Adding/bumping because I the same issue still. I keep finding my indexers will strip special characters, so Lidarr fails to find Ol’ Dirty Bastard but a manual Prowler search of Ol Dirty Bastard

Can we have an option to strip special characters on index searches and/or have it search both with and without special characters?

This is unrelated to his topic and covered by raw search and prowlarr.
For support and inquiries, please use our Discord channel. GitHub is designated solely for bug reports and feature requests. It seems that this issue may fall under a support request, so we kindly ask you to visit our Discord for assistance. Thank you.

@bakerboy448 commented on GitHub (Nov 18, 2024): > Adding/bumping because I the same issue still. I keep finding my indexers will strip special characters, so Lidarr fails to find `Ol’ Dirty Bastard` but a manual Prowler search of `Ol Dirty Bastard` > > Can we have an option to strip special characters on index searches and/or have it search both with and without special characters? This is unrelated to his topic and covered by raw search and prowlarr. For support and inquiries, please use our [Discord](http://lidarr.audio/discord) channel. GitHub is designated solely for bug reports and feature requests. It seems that this issue may fall under a support request, so we kindly ask you to visit our Discord for assistance. Thank you.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/Lidarr-Lidarr#283
No description provided.