Fix lrclib lyrics

[snejus]

Fixes #5102

LRCLib lyrics backend fixes

Bug Fixes

• Fixed fetching lyrics from lrclib source. If lyrics for a specific album, artist, and title combination are not found, the plugin now searches for the artist and title and picks the most relevant result, scoring them by
  1. Duration similarity to the target item
  2. Availability of synced lyrics
• Updated the default sources configuration to prioritize lrclib over other sources for faster and more reliable results.

Code Improvements

• Added type annotations to fetch method in all backends.
• Introduced LRCLyrics and LRCLibItem classes to encapsulate lyrics data and improve code structure.
• Enhanced error handling and logging enchancements to the LRCLib backend. These will be added to the rest of the backends in a separate PR.

Tests

• Added new tests to cover the updated functionality and error handling scenarios.

To Do

• Documentation. (If you've added a new command-line flag, for example, find the appropriate page under docs/ to describe it.)
• Changelog. (Add an entry to docs/changelog.rst to the bottom of one of the lists near the top of the document.)
• Tests. (Very much encouraged but not strictly required.)

[snejus]

The build on win32 is failing to install reflink because it's only supported until Python 3.7.

I will address this in a separate PR and rebase this one accordingly once the fix is merged.

Note: this issue popped up now because I added a new requests-mock dependency which invalidated cached dependencies.

[bal-e]

This is a much better implementation now, well done. I especially like that you've managed to remove the test resources -- I wasn't expecting 2000 lines of lyrics in there.

[tranxuanthang]

Hey, LRCLIB author here 👋. It would be great if you could make the /search API a fallback for the /get API (instead of replacing it entirely) when no result is found. The /get API is more performant on LRCLIB's side, whereas the /search API is much slower.

Also, the /get API has been updated recently, and the album_name parameter is no longer a hard requirement.

If you have any ideas for further improvements to LRCLIB's API, feel free to let me know!

[snejus]

Hey, LRCLIB author here 👋. It would be great if you could make the /search API a fallback for the /get API (instead of replacing it entirely) when no result is found. The /get API is more performant on LRCLIB's side, whereas the /search API is much slower.

Also, the /get API has been updated recently, and the album_name parameter is no longer a hard requirement.

If you have any ideas for further improvements to LRCLIB's API, feel free to let me know!

Hi @tranxuanthang, thanks for popping in! Absolutely, that's no problem at all. This should make most lyrics queries even speedier on our side.

Now that we're on this topic, I think it may be a good idea to also add caching: for example, if we're getting lyrics for two separate files

1. Artist - Title (Some Remix)
2. Artist - Title

Ideally we should only ask for Artist - Title lyrics once when Artist - Title (Some Remix) is not found.

@tranxuanthang thanks for a reliable and performant API!

[snejus]

The issue I'm thinking of is more for when there are multiple synced lyric providers. Imagine there's LCRLib and bilRCL, both can provide synced lyrics. As it is now, if I understand it correctly, if LRCLib is first in the sources list and only has plain lyrics for a song, the plugin will apply the plain lyrics, despite the fact that bilRCL might have synced lyrics.

I see! You're correct, the plugin now picks any kind of lyrics returned by the first source that returns something.

What I'm suggesting is to have the approach you have made here for LCRLib and expand it for all backends.

This makes sense - I am myself after synced lyrics if possible, so if there was another source that provides them, I would indeed try to engineer a way to retrieve them.

• If you want synced lyrics, and the first source that supports synced lyrics has them, use them (in all cases - if they match the duration and other parameters).
• If the first source only has plain lyrics, check the next source that supports lyrics.
• If no synced source has synced lyrics, use the plain lyrics from the first source.
• Sources are checked in order of preference as specified by the order of the sources config field.

This looks like a good approach. This of course depends on knowing in advance which sources provide synced lyrics, so that we can try them first.

• If no synced source has synced lyrics, use the plain lyrics from the first source.

I'd say we may even want to have a separate source priority list for non-synced lyrics: for example, I found that I prefer lyrics from LRCLib only if they are synced. Otherwise, I'd rather get them from Genius where they've been reviewed by the community.

Alternatively, if users want synced lyrics, we firstly query backends that provide them (respecting their order in the sources configuration), and then query the rest if synced weren't found. This way, if I have the following configuration:

lyrics:
  sources: [genius, lrclib, tekstowo, bilrcl]
  synced: yes

The plugin tries LRCLib and bilRCL first and returns the first valid synced lyrics, if found. If not, it tries Genius, then (cached) plain lyrics from LRCLib, then Tekstowo, and finally bilRCL.

[edgars-supe]

I think your suggestions make perfect sense! If you were to implement it like that, I wouldn't be mad at all. Though this probably warrants a bigger discussion with more maintainers, I would imagine. At any rate, I'll leave this idea with you, since you're working a lot on this plugin and you're way better suited for the task, if you choose to accept it, than I am.

[snejus]

@edgars-supe for now I will keep it as it is, but I noted this idea for the future when another source providing synchronised lyrics pops up!