getlyrics not getting lyrics

[elif1789]

first of all this is my very first post in GitHub, so have pity.

It seems lyrics are not returned, whether the id3 tag is populated, empty, or missing.

executing this api call curl "HTTP://MYSERVER:MYPORT/index.php/apps/music/subsonic/rest/getLyrics.view?u=MYUSER&p=MYKEY&artist=Stereophonics&title=Dakota" I get

<?xml version="1.0" encoding="UTF-8"?>

  

The answer is the same whether the tag is populated with something, empty, or missing. test executed in this way: edited the id3 using beets, saved, rebuilt the library, executed the curl and also the call to the api using Safari. the answer was always as reported above. I would expect to receive the lyrics in the response instead.

music app version 1.5.0 installed from marketplace, owncloud installed on Linux. everything is shown correctly on the web interface (I am able to see lyrics in the info panel).

[paulijar]

Thanks for the report. This API is supposed to work, and for me, it does work as expected: If the track in question has lyrics in its tags (as shown in the info panel), those are returned from this Subsonic API.

One thing to notice is that the track title and artist name given as arguments of the API call are case-sensitive: they need to be given exactly like they are in the tags of the file in question. Response like the one shown above indicates that the Subsonic controller didn't actually find any matching tracks for the given artist and title. If, on the other hand, the track was found but lyrics extraction failed, then the title and the artist name would be shown in the result.

[elif1789]

hi pauljar, thanks for your help! the library was tested containing only this one song, rebuilt ad hoc. the title and artist are exactly like the id3 tags and also like the same fields shown (I checked multiple times to be sure of that). I tested three scenarios: lyrics tag removed, lyrics tag present and empty, lyrics present with one single word "testlyrics" (no quotes) and with full lyrics text downloaded with Beets into the id3 tag. in all cases, result was the same. can you share how you populate the id3 tag for lyrics? do you have special characters, or manage carriage returns in some specific way? It could be that I just have to tweak the tag if for you it is working.

[paulijar]

Nothing special in how I populate the id3 tag, and the app can handle line breaks as LF, CR, or CRLF. But the contents of the lyrics tag is almost certainly not relevant here. Here's how the response looks for me when I query lyrics for a file which doesn't even have the tag:

<subsonic-response status="ok" version="1.16.1">
    <lyrics artist="Apocalyptica" title="In Memoriam"/>
</subsonic-response>

Note how the artist and title attributes are present. As your result does not have them, it indicates that the file was not found. Hence, it doesn't matter what kind of lyrics your file has or doesn't have because the app never even tries to parse those. Now the million dollar question is why the app can't find the file which should be present in the library.

[paulijar]

If you want to share your test file with me, I can check if the file can be found in my system. You can find my email address from my github profile.

[elif1789]

thanks pauljar, I will this afternoon. the odd thing is that I can stream and can get the cover art, and see the file in the library in browser. so maybe it's the call that is not ok. maybe it's quotes or something in it. can you share the curl call for which you get as response <lyrics artist="Apocalyptica" title="In Memoriam"/>

[paulijar]

can you share the curl call for which you get as response

Nothing fancy, just curl 'https://<domain>/nextcloud/index.php/apps/music/subsonic/rest/getLyrics.view?u=pauli&p=XXXXXXXXXXXXXXXX&artist=Apocalyptica&title=In%20Memoriam'

[elif1789]

hi, sorry for the late reply. I added again the lyrics tag. this is the result of beet info for the song (cutting most tags, keeping what is relevant for us):

         album: Language. Sex. Violence. Other?
         albumartist: Stereophonics
         albumartist_credit: 
         albumartist_sort: Stereophonics
         albumartists: 
         albumdisambig: 
         albumstatus: official
         albumtype: album
         artist: Stereophonics
         artist_sort: Stereophonics
         artists: 
         encoder: Lavf55.14.102
         format: FLAC
         genre: 
         genres: 
         grouping: Dakota
         language: eng
         lyrics: test_text_of_some_kind
         script: Latn
         title: Dakota

so basically what I did was creating the lyrics tag back, with a string text_of_some_kind (literally this value). I then recreated the library that contains this one song only. now I get the response right, but still cannot get the lyrics content from the api call.

Since I have only one song I used randomsong api to verify that the song is there: curl "HTTP://SERV:PORT/index.php/apps/music/subsonic/rest/getRandomSongs.view?u=USER&p=PSW"

<?xml version="1.0" encoding="UTF-8"?>
<subsonic-response status="ok" version="1.16.1">
  <randomSongs>
    <song id="track-96" parent="album-11" title="Dakota" artist="Stereophonics" isDir="false" album="Language. Sex. Violence. Other?" year="2005" size="65695522" contentType="audio/flac" suffix="flac" duration="297" bitRate="1767" isVideo="false" albumId="album-11" artistId="artist-10" type="music" created="2022-02-12T10:47:51.000Z" track="5" genre="(Unknown genre)" coverArt="album-11"/>
  </randomSongs>
</subsonic-response>

with this info, I try

curl "HTTP://SERV:PORT/index.php/apps/music/subsonic/rest/getLyrics.view?u=USR&p=PSW&artist=Stereophonics&title=Dakota"

<?xml version="1.0" encoding="UTF-8"?>
<subsonic-response status="ok" version="1.16.1">
  <lyrics artist="Stereophonics" title="Dakota"/>
</subsonic-response>

and it is found! but, it does not return the lyrics. instead I would have expected to return the value _text_of_somekind which is also reported in the info panel of the song in the webui.

...so my understanding is: getlyrics needs the lyrics tag to return title and artist otherwise even if the song is in the index it will not be found by the getlyrics (which makes perfect sense - parse only what has lyrics). however, I still have a mismatch between the webui and the response of the api when some value is present.

this happens for Owncloud 10.5.0 , latest version of the music app.

[paulijar]

getlyrics needs the lyrics tag to return title and artist otherwise even if the song is in the index it will not be found by the getlyrics

This is not correct, in my previous example the song In Memoriam by Apocalyptica didn't have any kind of lyrics tag. The Music app doesn't store any information about the availability of the lyrics in its database. So when getLyrics is called, the operation always has two steps:

1. Do a database lookup to find the desired song
2. Parse the metadata of that song file and try to find the lyrics tag among the metadata

One interesting thing is that your test file is in FLAC format. I have done most of the testing with MP3 files and it's possible that the app is not handling the lyrics tags of the FLAC files correctly. It's also possible that there are more than one way to tag the lyrics to a FLAC file (this is certainly the case with MP3s). It would be helpful if you could provide the sample file.

[elif1789]

here is a zipped FLAC for this song. https://we.tl/t-QdtxAM4kN9

[elif1789]

I think you got it right. I am ffmpegging the file to mp3 with ffmpeg -i Dakota.flac -ab 320k -map_metadata 0 -id3v2_version 3 dakotamp3.mp3 and I see that LYRICS : test_text_of_some_kind becomes USLT : test_text_of_some_kind I tried adding uslt tag via beets, seems to work but it still shows the metadata as "lyrics". I replaced Dakota.flac with the Dakota.mp3 file above (renamed). Dakota.flac does not exist anymore (I used ls -ato check inside the folder), I rebuilt the Music app library a few times, but it still shows a supposed Dakota.flac file as part of the library and metatadata are no longer visible in the info tab. I used beets to recreate the id3 tags for the new .mp3 file erasing the old ones, and rebuilt again the Music library, but the problem persists. so I guess I also found a way to inadvertently trash the library rebuild ... sorry :D a note about what I did with Beets, in my subsonic library (with a subsonic server) I had both flac and mp3, both playing nice with lyrics and everything, and all was created with beets with the same configuration so I do not think the issue is beets. attaching the mp3 file as well here. https://we.tl/t-WH4HlKPX8G

[elif1789]

if the issue is not .flac itself, maybe also worth to ask you, can you guide me a bit on what is best for metadata for this app: ID3v2.4 , ID3v2 or ID3v1 or it's the same. I am also very new to this difference, but can try to fine-tune beets and mutagen to get whatever is needed.

[paulijar]

Thanks for the sample file, indeed the problem was that the Music app was not handling the lyrics tag correctly there. This is now fixed in the master branch but it will probably take at least weeks before I'm making the next public release of the app. If you want to monkey patch your installation, you may download the file https://raw.githubusercontent.com/owncloud/music/master/lib/Utility/DetailsHelper.php and replace the corresponding file on your server with it.

Note that although the web UI was showing the lyrics in the details pane, it didn't work even there as intended: The lyrics are supposed to show up on their dedicated tab but they were being shown on the "General" tab among with all the other generic tags.

I replaced Dakota.flac with the Dakota.mp3 file above (renamed). Dakota.flac does not exist anymore (I used ls -a to check inside the folder), I rebuilt the Music app library a few times, but it still shows a supposed Dakota.flac file as part of the library and metatadata are no longer visible in the info tab.

Did you make the renaming of the file via the Linux command line, as using ls -a kind of hints towards that? Because that's something you are not supposed to do. Files within your ownCloud should be created, deleted, moved, and renamed only through the ownCloud web UI or the ownCloud client apps which exist for PC and mobile. Altering the file tree directly from the Linux file system causes the internal book keeping of ownCloud to fall out-of-sync with the reality.

what is best for metadata for this app: ID3v2.4 , ID3v2 or ID3v1

I would recommend using ID3v2.4. The Music app can read any of those tag types but especially the ID3v1 is very out-dated with severe limitations. If all your metadata is written in Latin alphabet, then any ID3v2.x version is okay but for non-Latin content, v2.4 is the best as it supports UTF-8 character encoding. Using UTF-8 ensures the best compatibility with various current and future music players.

[elif1789]

Did you make the renaming of the file via the Linux command line, as using ls -a kind of hints towards that? Because that's something you are not supposed to do -> Yes, I confess. thanks for pointing that out! so just to understand the music library reads the OC database? I sort of thought it had its own db. for OC, I rescan via crontab overnight to correct any issue and also scheduled the music rescan.

Concerning the patch, I'll just wait for general release, test and close this issue. thanks!

for the ID3v2 I will also put some links on how to strip ID3v1 and rewrite with v2.4 only, using beets, in case someone needs to enforce a cleanup of old tag versions.

[paulijar]

so just to understand the music library reads the OC database? I sort of thought it had its own db.

Yes, the Music app operates on top of the internal file system of ownCloud. From the point of view of the Music app, a file exists if and only if it has been indexed by ownCloud.

The Music app does have its own DB tables but those are not used to store things which are already stored in the standard DB tables of ownCloud. Instead, the tables of the app are used to store things like artist and album names and music genres. Those are then linked to the files found from the standard ownCloud DB tables.

[paulijar]

The fix for this is now released in Music v1.5.2.