beetbox / beets

music library manager and MusicBrainz tagger
http://beets.io/
MIT License
12.89k stars 1.82k forks source link

Lyrics are wrong #2969

Closed Flurrywinde closed 4 years ago

Flurrywinde commented 6 years ago

Problem

I used all default values in my config file, and beets imported lyrics successfully. However, for Manowar's "Fast Taker", they were wrong, so I added the following to my config file (/home/kanon/.config/beets/config.yaml):

lyrics:
    google_API_key: [redacted]
    sources: google

The same wrong lyrics appeared, despite google's regular search turning up different, better lyrics. (The first result in the "beets custom search engine" is different from both of these.)

Is there a way to tell which source beet is getting the lyrics from?

Also, is there a way to select which google source is used?

Is there a list of sources? For example, I see "lyrics.com" and "lyricwiki" on beets.readthedocs.io.

Running this command in verbose (-vv) mode:

$ beet -vv  lyrics -fp manowar fast taker

Led to this problem:

user configuration: /home/kanon/.config/beets/config.yaml
data directory: /home/kanon/.config/beets
Sending event: pluginload
no config file found at /home/kanon/.beetsconfig
library database: /home/kanon/Music/musiclibrary.db
library directory: /home/kanon/Music
Sending event: library_opened
google lyrics backend error: accessNotConfigured
got lyrics from backend: fetch_lyricswiki
fetched lyrics: Manowar - Fast Taker
Sending event: write
Sending event: after_write
Sending event: database_change
[lyrics here]

I notice it says: "google lyrics backend error: accessNotConfigured". Here is how I set up my google api key: opera snapshot_2018-06-29_002558_console developers google com

Is that correct? Why isn't it working?

Setup

My configuration (output of beet config) is:

directory: ~/Music

import:
    copy: no
lyrics:
    google_API_key: AIzaSyDELPsVTGyXRywPrXx[redacted]
    sources: google
    auto: yes
    fallback:
    google_engine_ID: 009217259823014548361:lndtuqkycfu
library: ~/Music/musiclibrary.db

plugins: fromfilename fetchart lyrics
fetchart:
    cautious: no
    maxwidth: 0
    auto: yes
    remote_priority: no
    google_search: no
    cover_names:
    - cover
    - front
    - art
    - album
    - folder
sampsyo commented 6 years ago

That’s certainly strange! The verbose output says:

got lyrics from backend: fetch_lyricswiki

But that seems wrong, since you clearly only have the google source enabled, not lyricswiki. I don’t know why the plugin doesn’t seem to be respecting your configuration there.

I notice you seem to be on a pretty old version of beets (1.3.8). Have you tried using the most recent version?

Flurrywinde commented 6 years ago

I installed via the Ubuntu repositories, so that's what version is there. I now installed via pip, and it's now version 1.4.7. I ran beet -vv lyrics -f -p manowar fast taker again and got:

user configuration: /home/kanon/.config/beets/config.yaml
data directory: /home/kanon/.config/beets
plugin paths: 
Sending event: pluginload
library database: /home/kanon/Music/musiclibrary.db
library directory: /home/kanon/Music
Sending event: library_opened
lyrics: failed to fetch: https://www.googleapis.com/customsearch/v1?key=AIzaSyDELPsVTGyXRywPrXxgVJBZySoKz1HLTSc&cx=009217259823014548361:lndtuqkycfu&q=Manowar%20Fast%20Taker (403)
lyrics: google backend returned no data
lyrics: lyrics not found: Manowar -  - Fast Taker
[current local lyrics output]

The verbose output is much more helpful now. :) The url told me how to fix things, and running the command again succeeded:

user configuration: /home/kanon/.config/beets/config.yaml
data directory: /home/kanon/.config/beets
plugin paths: 
Sending event: pluginload
library database: /home/kanon/Music/musiclibrary.db
library directory: /home/kanon/Music
Sending event: library_opened
lyrics: Bad triggers detected: ['Manowar']
lyrics: got lyrics from www.azlyrics.com
lyrics: got lyrics from backend: Google
lyrics: fetched lyrics: Manowar -  - Fast Taker
Sending event: write
Sending event: after_write
Sending event: database_change

What does "Bad triggers" mean?

The lyrics are still wrong, so two of my questions from above still apply:

And now a new question:

sampsyo commented 6 years ago

Cool! I’m glad the sources issue has gone away in the current version.

I don’t know what the “bad trigger” thing is meant to indicate—it seems to be part of the heuristic that decides whether a page actually contains lyrics. I’ll have to rely on @Kraymer to clarify his intent there.

stale[bot] commented 4 years ago

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

wisp3rwind commented 4 years ago

I don’t know what the “bad trigger” thing is meant to indicate—it seems to be part of the heuristic that decides whether a page actually contains lyrics. I’ll have to rely on @Kraymer to clarify his intent there.

In fact, it looks like this is due to a typo: The idea is to check whether the artist name occurs in the lyrics (which is unlikely, hence an indicator, that the plugin didn't scrape the actual lyrics). However, the typo means that the plugin never actually checks whether the artist name occurs in the text. The following patch should correct this. @Kraymer could you briefly check whether this is correct?

diff --git a/beetsplug/lyrics.py b/beetsplug/lyrics.py
index f53191d8..1291f2a5 100644
--- a/beetsplug/lyrics.py
+++ b/beetsplug/lyrics.py
@@ -552,7 +552,7 @@ class Google(Backend):

         bad_triggers = ['lyrics', 'copyright', 'property', 'links']
         if artist:
-            bad_triggers_occ += [artist]
+            bad_triggers += [artist]

         for item in bad_triggers:
             bad_triggers_occ += [item] * len(re.findall(r'\W%s\W' % item,

This bug is quite old, is was introduced in 117d16f2adf256ef872dbb78e97b17511da840cc.

Kraymer commented 4 years ago

@wisp3rwind yes your fix seems correct

wisp3rwind commented 4 years ago

Closing this issue, it appears that the original issue with the google source was already resolved. If this wasn't the case, feel free to re-open and add some details, @Flurrywinde.