LyricWiki talk:SOAP

From LyricWiki

SOAP Failures

The SOAP webservice logs the most common failed requests. This serves to

1. Show the most desired songs that aren't on the site yet
2. Help reveal ways in which the SOAP can be improved to automatically make a higher response-rate.

Check it out :) -Sean Colombo 18:31, 23 January 2007 (EST)

Tweaks

• I had a minute to code whilst I was on the phone, so I debugged a weird issue and got some really ridiculously misspelled titles to resolve correctly now. That brought the sum on the SOAPfailures page from 6131 down to 5614! That's a pretty sizeable difference for such a small tweak. If you have a minute, go over and make that number drop some more :)
  -Sean Colombo 20:39, 4 March 2007 (EST)
• Now artist names are parsed to remove everything after " feat." and " ft." so that the original artist's name is used. -Sean Colombo 03:05, 22 March 2007 (EDT)
• Redirects that were redirecting to pages with special-characters (unicode) in their title were not working but are now fixed. -Sean Colombo 23:05, 4 May 2007 (EDT)
• Songs with " - " in them, now work if the area after the " - " is the song name (also works if the " - " is actually in the song-name as before). Many songs had the form "TRACKNUM - Artist - Album - Song" or some variation, and now the SOAP accounts for that.
• Certain "non-artists" are now automatically ignored. For example, if the artist is "Baby Einstein" (an all-instrumental product line of classical music), "Apple Inc." (the artist name for Apple's podcasts), or just "Soundtrack", the song is instantly skipped instead of using all of the database-checks normally used before a song is determined to be not-found.
• Multiple-spaces in a row are now trimmed down to single spaces (NOT TESTED).
• Fixed a problem where all numbers 4 or less were getting replaced by wrong words because of an error in using strtr (I had the replacements comma-delimited instead of associative).

getLyrics vs. getSong

Why is the method to get a lyric listed as getLyrics on this page, but implemented as getSong? Or is the getLyrics function meant for something different? - Florob 14:29, 17 September 2006 (PDT)

I just forgot to change the documentation after implementing it (it's fixed now). Thanks for catching this!

-Sean Colombo 14:38, 17 September 2006 (PDT)

Java && AXIS

hi, i tried to to use the wsdl with java and AXIS but i got Exceptions. The compiler means that the AlbumResult is referenced but not defined. Is it possible that the wsdl is wrong? Other wsdl like google had worked just fine with my setup.

Hmm, weird. Every SOAP client seems to have a different bug, and I'd like to figure out a way to hack the WSDL to work with all major SOAP clients (and AXIS is certainly major). So far it has been tested (and used quite a bit) in nuSOAP (PHP) and in .NET (v2 and v3). Can you paste the whole error you are getting? (btw... album result is defined, if you look at the WSDL it has

<xsd:complexType name="AlbumResult">
	<xsd:all>
		<xsd:element name="artist" type="xsd:string"/>
		<xsd:element name="album" type="xsd:string"/>
		<xsd:element name="year" type="xsd:int"/>
	</xsd:all>
</xsd:complexType>

... but we'll still try to figure out how to get it working in AXIS.

Thanks for any additional information you can give,

-Sean Colombo 09:03, 3 October 2006 (PDT)

I got the WS via JAX-RPC working by changing the lines

<xsd:attribute ref="SOAP-ENC:arrayType" wsdl:arrayType="AlbumResult[]"/>
<xsd:attribute ref="SOAP-ENC:arrayType" wsdl:arrayType="AlbumData[]"/>

to

<xsd:attribute ref="SOAP-ENC:arrayType" wsdl:arrayType="tns:AlbumResult[]"/>
<xsd:attribute ref="SOAP-ENC:arrayType" wsdl:arrayType="tns:AlbumData[]"/>

in the WSDL file. -Michael Rauscher 21:57, 30 December 2006 (CET)

Sweet... is that something you should just hack into the JAX-RPC version, or is that something you think I should try to cram in to the WSDL for all versions (I'm not sure how to do that using nuSOAP yet, but I'm sure I could get it done).

-Sean Colombo 20:20, 30 December 2006 (EST) (if I don't respond quickly, please nudge me on my talk page)

Since this is my first "approach to web services, xml schemas, ..." I can't tell you very much. As far as I understand things so far I think the WSDL file is wrong. There's a default namespace defined for the schema

<xsd:schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:LyricWiki">

Now, there's no namespace given for the wsdl:arrayType attribute, therefore the default namespace will take in effect. E.g. the attribute value "AlbumResult[]" turns into "xmlns:AlbumResult[]" which isn't defined. Again, I might be totally wrong but it seems logical to me. In any case it seems to be good practice to avoid ambiguities by providing namespace explicitly, so I think you should place the namespaces in the WSDL file. -Michael Rauscher 84.151.49.50 03:26, 31 December 2006 (EST)

C++ and SOAP

Hi, looking good on this site and congrats on the new server! I am working on a small application in C++ to call this WSDL, but it tends to bottom out (note that Google, Amazon, and Babelfish work for me). There error is as follows once the Services are added and a build is attempted:

Error 9 error LNK2022: metadata operation failed (80131195) : Custom attributes are not consistent: (0x0c0001c2). AssemblyInfo.obj Error 10 error LNK2022: metadata operation failed (80131195) : Custom attributes are not consistent: (0x0c0001cc). AssemblyInfo.obj ...

That's saying that there's a mismatch in the WSDL and the way the C++ app is trying to read it. If you'd like any help developing the services, please let me know, I'd be glad to help :)

Thanks, James

Hi, I haven't used this or any other webservice through C++ before... do you have any idea what could be causing the errors above?

-Sean Colombo 20:12, 30 December 2006 (EST)

Using in VS2005

Hi,

The webservice is looking great. I am using C#/VS2005 and the webservice works fine within VS however when I build the app and try and call the service (using getSong) I get an error "Item has already been added. Key in dictionary: 'urn:LyricWiki/encodedTypes:ArrayofString' Key being added: 'urn:LyricWiki/encodedTypes:ArrayofString'

Any ideas?

Thanks, John

OK - I've got it to work by not generating the serialisation assembly (i.e. deleting the .XMLSerialization.dll file which can be generated by VS). Any ideas why this would cause a problem?

Janet Jackson - Control: Site is fine, webservice don't

Hello there,
this is a great webservice guys!
I'm having an issue right now, some of the songs can be access through the standard website interface:
http://www.lyricwiki.org/Janet_Jackson:Control
but when you try to call getsongs ("Janet Jackson", "Control") it doesnt return the lyrics.
Any ideas?
Thanks
--Raul

Hi Raul,

I tried it out, and I got the result for Janet Jackson:Control just fine using the webservice... what does it return to you, "No match found" or an error?

-20:17, 30 December 2006 (EST)

getSong case-sensitive

It seems that getSong is case-sensitive. As an example getSong("Die Ärzte", "Komm zurück (unplugged)") does not return Die Ärzte:Komm Zurück (Unplugged). I think this is a bit suboptimal, because sometimes song capitalisation is not always cleary and misscapitalization is a common mistake. The wiki itself performs the search case-insensitive. Would it be possible to have getSong act case-insensitive? Florob 10:02, 31 December 2006 (EST)

 :( Hmm... it's not supposed to be case-sensitive. There is a function in there that tries to fix all incoming title names to match the standard of the site. I'm not sure whether it's the umlauts or the parenthetical that's messing up the match (it's probably the "u" after the parentheses if I had to make a guess), but I'll look at it and see if I can fix it.

-Sean Colombo 14:22, 31 December 2006 (EST)

FIXED! Sweet... I looked into it more, and it was just the parentheses. I should explain: with the MediaWiki framework, it is relatively easy to check if a page exists... you create the title then call an ->exists() function on it. The catch being that you need the case to be correct since pages in the wiki are case-sensitive. The search page on the wiki is insensitive because it is using mySQL to search through all pages (and mySQL comparisons are case-insensitive by deafult).

It is much faster to just call $title->exists() than to perform our own queries on the various tables (a single page is actually spread over multiple tables... one for the article, one for the content of the page which may or may not be valid and may or may not be an old or deleted revision). Therefore, I wrote a function to take all incoming requests and format them to meet the standards on the site. This includes capitalizing all the words, but PHP's doesn't recognize special characters as word-boundaries, so I had to put in a special case for hyphens and now for parentheses. If you can think of any other time that there would be special (non-space) characters at the beginning of a word, please let me know so I can put that into the SOAP script. Thanks!

-Sean Colombo 20:07, 31 December 2006 (EST)

Cool, seems to work pretty good now (except reaching the server is very slow). Do you handle quotes (" or ') at the beginning of words, or aren't those valid characters?

-Florob 14:24, 2 January 2007 (EST)

The SOAP doesn't do anything special with quotes. If they are actually in the title of the song, they should be in the request too.

-Sean Colombo 22:48, 7 January 2007 (EST)

I had problems fetching lyrics for A-HA. Correcting it to A-Ha worked fine. However I fail with ACDC, AC DC, Ac Dc. Any ideas?

-Ronson 13:51, 7 January 2007 (EST)

Hi, I couldn't reproduct the A-Ha problem. Did you have this problem today? One of the fixes yesterday involved making even ALL CAPS TITLES WORK. I wouldn't have thought this was an issue, but ucword("HELLO WORLD") yields "HELLO WORLD" so I just changed it to ucword(strtolower("HELLO WORLD")) to get "Hello World". So this isn't supposed to be an issue as of some time yesterday.

As for AC DC, This problem is caused by the same code (may or may not have) fixed "A-HA". So now the SOAP is looking for Ac Dc:Little Lover instead of AC DC:Little Lover since AC DC is technically wrong using our title formatting standard. There's really no way to... fix that since the wiki data made the mysql tables case-sensitive. Normally if the title is weird we'd do a redirect to the other title... but that would mean we'd have to move the pages to Ac Dc due to technical restrictions.

So it appears we have two choices (unless someone can think of another)

1. Move all pages to work with the standard so that AC DC would be moved to Ac Dc and just look sorta weird but work.
2. Not allow the SOAP to get results from artists with non-standard-capitalization in their titles.

Thoughts?

-Sean Colombo 22:45, 7 January 2007 (EST)

A-Ha and A-HA now work both. Maybe I tried A-HA already on Saturday evening or Sunday morning and there it didn't work.

I don't understand your second suggestion. Would this mean, that one gets an exception when he queries e.g. A-HA? Does this make sense?

I'm not very much into your way of finding the articles, but wouldn't it be possible to check first for the standard-capitalization article and if none is found, automatically check for the article with artist and song name exactly as the given parameters. E.g. if one checks for AC DC Thunderstruck, you'll convert it to Ac Dc Thunderstruck, you'll find nothing, therefore you'll check for AC DC Thunderstruck find the desired article and return it. Maybe this behaviour should also be controllable with parameters, e.g. labelled "searchMode" (overloads of the methods, or a property?).

-Ronson 13:21, 8 January 2007 (EST)

Another problematic artist concerning capitalization is INXS.

-Ronson 11:46, 15 January 2007 (EST)

... and Lutricia McNeal. To sum it up: There are several artists (and also song titles) which have non-standard capitalization. With the current SOAP-implementation there is NO way (also no cheating) to retrieve the lyrics for these songs. If possible, please consider my comment of 8 January: Implement another query method that avoids automatic capitalization of the query parameters and instead takes them as they are.

-Ronson 12:02, 21 January 2007 (EST)

Yeah, we really have to do something about that. If we made a second version of the function though... you'd call that version every time the original request fails, right? In that case it would be simpler to just add one more check into every failing request to see if the originally capitalized version could be found. I was hesitant to do that earlier since every failing request would now have one another database query... but it seems to be worth it to fix this annoying bug. Do you see any reason that this would be worse/better than making a seperate function?

-Sean Colombo 05:31, 22 January 2007 (EST)

Yes, you're right. I would call the separate function everytime the first one fails. So to minimize roundtrip times and - as you said - reduce server load, you should do it in one step at the server. Of course you could check if the spelling given by the user and the capitalized spelling are different at all, before doing the second check. So I don't think two methods are necessary.

Best would be a completely case independent search, and maybe a somewhat "forgiving" search to correct misspelling. But this is probably too resource consuming.

-Ronson 06:07, 22 January 2007 (EST)

I've fixed it so that artist names that are all-capitalized are left in tact since that actually goes with LyricWiki:Page names and fixes the above problems. I was confused... the standard is and always has been to leave names that are all-caps like "AC DC" as all-caps. I've tested the fix and it works (as long as no one is searching for "Ac Dc").

-Sean Colombo 18:23, 22 January 2007 (EST)

Thanks, I'll test it. But that probably does not yet fix issues with Lutricia McNeal or Maria McKee.

-Ronson 04:12, 23 January 2007 (EST)

AC DC now works (though having problems to fetch AC DC:T.N.T.).

-Ronson 15:02, 23 January 2007 (EST)

Thanks Sean, now a lot of issues are fixed right now (as far as I can see): Lutricia McNeal, Maria McKee, ZZ Top, etc. now do work. Only few things are real bugs: AC DC:T.N.T. and also all songs by R.E.M. don't seem to work, so dots seem to be a problem. Furthermore, since you strip off parentheses from requested song titles, some titles cannot be retrieved if the parentheses are part of the song title, e.g. Michael Bublé:A Foggy Day (In London Town). Another application of our "double-search" which we've discussed a couple of times now.

-Ronson 18:54, 23 January 2007 (EST)

Hi. The parentheses are only chopped off if the original title isn't found, so it should behave as expected. I ran a test for Michael Bublé:A Foggy Day (In London Town) and I got a successful result. Did it fail for you or did you not get a chance to test it?

-Sean Colombo 12:07, 24 January 2007 (EST)

It fails for me: Requested song title A Foggy Day (In London Town) and requested artist name Michael Bublé. Maybe a problem with the artists accent? Any ideas for the problems with R.E.M.?

-Ronson 12:15, 25 January 2007 (EST)

Right now even non-critical titles fail like Xavier Naidoo:Sie Sieht Mich Nicht. So probably my previous post is worthless because of fundamental problems.

-Ronson 12:22, 25 January 2007 (EST)

I tested the issues of my last two posts and they are fixed.

-Ronson 07:39, 1 February 2007 (EST)

I seem to have problems getting Lyrics for Die Ärzte:Meine Ex(plodierte Freundin) right now. My first guess was, that the "p" after the "(" is being capitalized, doesn't make sense if you also search with the original string though...

Florob 18:40, 3 February 2007 (EST)

Fixed. It was the "P".

-Sean Colombo 10:43, 23 April 2007 (EDT)

It fails on Senses Fail - NJ Falls Into the Atlantic -- however Senses Fail:NJ Falls Into The Atlantic works (note the difference in the/The). Remiss 10:18, 27 February 2007 (EST)

My guess is that it was the capital J in NJ that was doing it. The capitalization is fixed and it seems to work now: [1]

-Sean Colombo 10:43, 23 April 2007 (EDT)

Server returning response in iso-8859-1

The server seems to be returning responses in ISO-8859-1 even if I request UTF-8. This seems to be causing some signs like "'" to be messed up, even though not all the time. I see the wiki is using UTF-8 encoding when talking to the browser and the characters are displayed correctly then. Any ideas? Remiss 04:15, 10 January 2007 (EST)

Uhm, ' works ok I think, but more special signs like ‘ and ’ are problematic. Remiss 04:25, 10 January 2007 (EST)

Yet another thought, if you still need a solution on the soap page failures not being removed when the pages are created you could check for it when you are updating the cached version of the soap page failures. Sorry if I'm not making much sense, but I've been up for 24 hours Remiss 04:43, 10 January 2007 (EST)

Hi, you said even if I request UTF-8... how is that done? I don't know how to change encodings in nuSOAP yet, but I might be able to figure that out, or at the very least throw a utf8_encode() around the results before I return them.

-Sean Colombo 23:31, 15 January 2007 (EST)

I was setting all kind of headers and specifying that the request was encoded in utf-8 as well. The correct header to set would be Accept-Charset [2] and put the encoding name for utf-8 there (can't remember what it is right now) when one wants UTF-8 -- Anyway, I believe the soap-script always should return result in UTF-8 or reencode them in the charset it is sending it back in as they (as far as I can figure out) is stored in an UTF-8 database. The correct header to set when sending back the reply is Content-Type

Know you're probably busy with pedlr, but any progress on this? Remiss 08:34, 21 February 2007 (EST)

I think it's fixed now but have limited abilities to test it. Let me know if it's still messed up

-Sean Colombo 14:35, 10 April 2007 (EDT)

Hi guys! Im also having trouble with encoding. Swedish charcters becomes messed up. I have tried converting from iso-8859-1 to UTF-8 with no success. If I lookup the song on lyricwiki.org the lyrics are all fine. It seems to be an issue on the actual webservice. Im coding in vb.net in VS 2005. My request (also containing swedish characters) works just fine. Heres my call:

       Dim lw As LyricWiki
       Dim lr As LyricsResult
       lw = New LyricWiki
       lr = lw.getSong("Staffan Hellstrand ", "Lilla Fågel Blå")
       Debug.Print(lr.lyrics)

Any ideas on this? --Pär 15:45, 7 October 2007 (EDT)

Hi,

What is the result of that call? Can you paste the XML result (if vb.net lets you see the whole thing)?

Thanks,

-Sean Colombo 18:42, 7 October 2007 (EDT)

Hi Sean, Sorry, my fault, that song did not look ok on the website either and needs to be fixed. The following code converts from ISO-8859-1 to UTF8 so that swedish characters work ok.

       Dim Lyrics As String
       Dim lw As LyricWiki = New LyricWiki
       Dim lr As LyricsResult = lw.getSong(Artist, Song)
       Dim iso8859 As Encoding = Encoding.GetEncoding("ISO-8859-1")
       Lyrics = Encoding.UTF8.GetString(iso8859.GetBytes(lr.lyrics))

Thanks, --Pär 16:53, 8 October 2007 (EDT)

I am still stuck with this problem. If I request songs in utf-8, I get ISO-8859-1 back. If I request this song: http://lyricwiki.org/%D0%A1%D0%BF%D0%BB%D0%B8%D0%BD:%D0%A4%D0%B5%D0%BB%D0%BB%D0%B8%D0%BD%D0%B8 in utf-8, I get in the response all ?????? instead of artist/title. So how do I request (using soap) the above song? and how (in what encoding) do I get the result back. In short: Why doesn't it just work with utf-8, and why don't I get utf-8 back?

I've been working on the encoding the last few days, and ran into some interesting problems. For some reason, I can't just take the data out of the database, encode it a certain way and serve it. It appears that I have to encode it differently based on how it was stored (this boggles my mind!). Interestingly, the API seems to handle your example really well as a REST request [3]. I see what you're talking about w/the SOAP version though. I'll look into that.

Thanks for the bug-report

-Sean Colombo (talk|contribs) 08:55, 12 June 2008 (EDT)

It is a soap request I do. And there it fails,

Request: <?xml version="1.0" encoding="UTF-8"?> <SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tns="urn:LyricWiki"> <SOAP-ENV:Body> <tns:getSong xmlns:tns="urn:LyricWiki"> <artist xsi:type="xsd:string">Феллини</artist><song xsi:type="xsd:string">Сплин</song></tns:getSong></SOAP-ENV:Body></SOAP-ENV:Envelope> This is valid, utf-8 request (I hope wiki does not mangle it to much) request.response: <?xml version="1.0" encoding="UTF-8"?><SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:si="http://soapinterop.org/xsd" xmlns:tns="urn:LyricWiki"><SOAP-ENV:Body><ns1:getSongResponse xmlns:ns1="urn:LyricWiki"><return xsi:type="tns:LyricsResult"><artist xsi:type="xsd:string">?????</artist><song xsi:type="xsd:string">???????</song><lyrics xsi:type="xsd:string">Not found</lyrics><url xsi:type="xsd:string">http://lyricwiki.org</url></return></ns1:getSongResponse></SOAP-ENV:Body></SOAP-ENV:Envelope>

It seems REST with xml also goes wrong: [4]

More proof that rest isn't liking this either, this is what I get from libxml: http://lyricwiki.org/api.php?artist=Queensrÿche&song=Take%20Hold%20Of%20The%20Flame&fmt=xml Entity: line 3: parser error : Input is not proper UTF-8, indicate encoding ! Bytes: 0xFF 0x63 0x68 0x65 Queensr�che

Please, if you say you output to UTF-8, output UTF-8.

It looks like every request made where the artist/title can be encoded using a ISO-8859-1 is not displayed in the result as utf-8. if the artist/title contains f.e. russian or japanese characters it works, but queensrÿche and a few others don't. I hope this helps tracking down the issue?

Returning empty lyrics though song exists (probably redirect !?)

The webservice returned an empty string (not "Not found") when I was querying for A-Ha:Dark Is The Night. The article exists and redirects to A-Ha:Dark Is The Night For All. This is an undesired behaviour. The webservice should return the lyrics for the redirected article or at least a "Not found" and not an empty string.

-Ronson 11:28, 20 January 2007 (EST)

I've seen the same bug in some other pages that are on Special:Soapfailures. For example, Nirvana:Smells Like Teens Spirit (note the extra "s" in "Teens"). Not sure what I did wrong there, but I'll look into it.

-Sean Colombo 18:25, 22 January 2007 (EST)

Fixed. I actually didn't do any explicit fixes for this, but it works now. This must have been fixed by something else I did.

-Sean Colombo 18:28, 23 January 2007 (EST)

Accessing the SOAP web service from javascript

Discussion moved from User talk:Sean Colombo

Hi,

Is there a way you can query the web service with all the parameters and the soap action (ex: getSong) listed in url format: For example: http://lyricwiki.org/server.php?wsdl&method=getSong&artist=artist&song=song ?

The reason I ask is that I'm trying to access the web service using the activex object "Microsoft.XMLHTTP" and javascript.

Or are there other ways to access it using javascript?

/ThePike

Hi ThePike... there isn't a way to do that yet (which just means that you are the first to ask for it, it wouldn't be hard to do). Are you comfortable POSTing with AJAX or just with GETs? (generally it's stanadard to make requests use GET, but things where you are sending data (like updating lyrics) use POST).

I'm sure I can get this set up soon for you (how close is your site/page to being done?). If you have a link to what you're doing so that I can understand it better, that's always appreciated too :)

Thanks,

-Sean Colombo 20:00, 5 December 2006 (EST)

Ok I see. I'm working on a Windows Vista sidebar gadget that displays the current album cover (from amazon) for playing song in winamp and

I thought it would be a nice addition to be able to view lyrics too.

Unfortunately there's no project page or similar online.

So there would be only GET requests...

/ThePike

Actually I think I'll go in another direction. I'll create a COM object in C# that uses the web service and just call it from within the gadget.

Will searchSongs() be implemented soon?

Tried the getSong() method and it works fine but it misses many requests due to spelling since it requires an exact match.

Are there any search tips? For example certain characters that are to be left out or replaced?

/ThePike

Hi, there isn't a planned date for the searchSongs() method... there's always so much to do that I just wait till someone asks for it basically :)

So if you need it soon, I can get on it. Usually the getSong() can be made to get most music that actually is on the site (I can never find my instrumental techno on here, lol).

Anyway... the best ways to make sure you get the results you want from getSong() are to follow the naming conventions that mostly go like this:

1. Capitalize The First Letter Of Every Word
2. Bands that have "The" should start with "The" so search for "The Prodigy", not "Prodigy, The"
3. Most of the time remove parenthesis and other extra dashes, etc. from the end of the title. So search for Akon:Smack That not Akon:Smack That (ft. Eminem - dirty version - DJ Clue remix ft. blahhh)

In addition... if you are using getSong() more, instead of working on searchSong() there are some improvements I could do to getSong() that will make more hits likely. Basically, there are a bunch of mispellings/diff capitalizations and abbreviations of bands; we have a ton of redirects on the site that take care of this, but they are only for the artist page... I could make the SOAP understand that if there is no page match, it should look for the artist name that is redirected to by the provided artist name and see if there is a song that matches that.

Ok, that might have been semi-greek, but basically... I can make getSong() better.

-Sean Colombo 16:16, 7 December 2006 (EST)

Ok thanks. Sounds good. A "smarter" getSong() method would be great!

/ThePike

Heya, just remembered that most of those tips (capitalization, etc.) are done by the SOAP itself already. I didn't do the parentheses-choppng yet, but I can do that if the successful-result rate is still low. I started logging the stats yesterday, and this morning I implemented that redirection-trick (therefore botching todays stats since I did it in the middle of the day). By the end of tomorrow, I should know if that really helped much or not.

-Sean Colombo 19:00, 9 December 2006 (EST)

About those questionmarks...

FYI... the questionmarks on the SOAP failures are probably just foreign characters... but they might be actual question marks (if that turns out to be the case, I'll ignore them automatically)... still looking into it.
-Sean Colombo 18:39, 23 January 2007 (EST)

BTW, forgot to mention... turned out that they were not foreign characters. So now the "???" artists/titles have been ignored, so they don't show up in the SOAP failures anymore.

-Sean Colombo 22:01, 29 January 2007 (EST)

When using ruby, i get questionmarks instead of umlauds é's á's and other special chars

Using:

require 'soap/wsdlDriver'

driver = SOAP::WSDLDriverFactory.new("http://lyricwiki.org/server.php?wsdl").create_rpc_driver

driver.getSong("coldplay","talk")

What I've heard from multiple other testers (after spending a lot of time trying to "fix" our end of it) is that it turns out that Ruby (or maybe just the SOAP client?) just doesn't do UTF8 correctly yet, and it's apparently a known issue. Now that Rails is popular, I think people are working on it, but I haven't heard a planned date to release fixes or anything.

Sorry,

-Sean Colombo 10:35, 23 April 2007 (EDT)

Ruby and Rails can indeed use UTF8 quite well as I have a RoR project that uses it right now. So I suspect the problem lies in the SOAP client. (anon guy just passing through looking for API info)

SOAP Page Failures - (report as fixed) problem

One of the songs listed in the failure list is The All American Rejects - Can't Take It. When I try to report as fixed, it gives this (emphasis added): Sorry, but The All American Rejects:Can song still failed. It looks like it is getting cut off at the apostrophe. There is probably a problem with escaping the string for the database lookup. This is somewhat of a problem, because it may also represent a security problem, specifically SQL injection.

- teknomunk (talk,E) 18:43, 23 January 2007 (EST)

Thanks for the heads-up! I looked into it, and everything is still safe server-side from a mysql-injection... when I was making the link to report the song as fixed, I had forgotten to urlencode() the artist and song name, so only "The All American Rejects:Can" was being taken as the URL and the rest was just trash in the HTML tag. So the link works now, but oddly the song still isn't showing up as fixed :-/

Thanks again,

-Sean Colombo 09:23, 25 January 2007 (EST)

Could you please give me an explanation or a link to an explanation, what this "fixed" link for failed SOAP requests means and causes? What's the purpose? Thanks.

Ronson 12:07, 25 January 2007 (EST)

Oops, I should have put that on there before. There is now an explanation on Special:Soapfailures

-Sean Colombo 22:11, 29 January 2007 (EST)

No results for Janet Jackson:Got 'Til It's Gone

Could not get a result for Janet Jackson:Got 'Til It's Gone. Any guesses why?

- Ronson 16:00, 11 February 2007 (EST)

My guess is something with those single-quotes. I'll look into it.

-Sean Colombo 13:55, 26 February 2007 (EST)

Ampersands

There were a bunch of failed requests for Cassie:Me when the real song name is Cassie:Me & U. Has anyone else noticed issues with ampersands, or might this just be someone's mislabeled song in their player?
-Sean Colombo 13:56, 26 February 2007 (EST)

Additional notes-to-self

1. The all-caps exception for artists isn't there for songs, so Foo Fighters:DOA doesn't work through the SOAP.
2. Maybe there should be another page for seeing the artists with the most failed requests? Use this query:

   select request_artist,sum(numRequests) as requests from lw_soap_failures group by request_artist order by requests desc limit 50;

3. Benny Benassi:Who's Your Daddy? doesn't work... probably because the Who's is parsing to Who'S. Revisit the rules for this.

Song not working using SOAP

Hello All,

Thanks for the great service. I found this problem today using SOAP getSong method, the

song: Joaquin Sabina:Esta Boca Es MíA artist: Joaquin Sabina

Is not returning any lyrics. I though was the "í" char, but there are other accentuated chars that are working great.

Thanks in advance

--Raul

Hi, the problem was that the A on the end was capitalized and the SOAP makes assumptions about capitalization (to try to be able to find the songs no matter how they are given to it. I've moved the page and put a redirect in from the old capitalization so it should work now.

For more info, please see Page Names.

Thanks,

-Sean Colombo 10:31, 23 April 2007 (EDT)

SearchSongs only returnes Beethoven

When i try to search using the searchSongs() method, it returnes song: "'Moonlight Sonata', artist: 'Beethoven'" every time. Is it me doing something wrong, or is the problem in the service?

Hi, that function's not done yet. If you're making an app that really needs it, we could try to finish it for you. Let me know (preferably on my talk page

Thanks,

-Sean Colombo 11:59, 20 May 2007 (EDT)

Is this fixed now? I still find searchSongs() only returning: song: "'Moonlight Sonata', artist: 'Beethoven'" every time.

How do I search for a song if I don't know the artist name using the web service?

Search Functions

I'm working on a PHP app, just a personal project, to do album/artist/song searches and displaying them on a web site.

Are the functions mentioned under Current Progress the only functions currently complete? I noticed for example that the searchArtists function returns wrong values; I made a search for Nightwish and got Pink Floyd.

Technically, I could do a check if the artist exists or is valid by using the getArtist function, but that seems like a waste of resources, since if the artist exists, it would return a boat load of information. e.g. Nightwish or Metallica. It would be easier if a search function, like searchArtist could do the job for me and just return TRUE or FALSE values. Then another query could be used to get the actual data.

Is this the original purpose of the search functions or am I way off?

--Datamike 04:19, 5 June 2007 (EDT)

Yeah, the SOAP (interface / documentation) is a little behind :) There is a checkSongExists() so it would make sense also to have a checkArtistExists(). Also, the getSOTD() suggests creating a getAOTW() as well. Sounds like a project :) --Mischko 13:39, 5 June 2007 (EDT) PS that's a hint :)

SOAP and Borland Delphi

Hi all.

Firstly, thanks for a gr8 site. I am developing a small app in Delphi 7 that gets the lyrics for my songs via SOAP. Most of the functions works correctly except for getArtist. When i am executing the function it gives me the following error.

"SOAP Response Packet: result element expected"

I was searching for the discography of Busted.

This is the full error report:

SOAP Response Packet: result element expected, received 
"<ns1:getArtistResponse xmlns:ns1="urn:LyricWiki"><artist xmlns:xsi="http://
www.w3.org/2001/XMLSchema-instance" xsi:type="xsd:string">Busted</
artist><albums xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:type="SOAP-ENC:Array" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/
encoding/" SOAP-ENC:arrayType="tns:AlbumData[1]"><item 
xsi:type="tns:AlbumData"><album xsi:type="xsd:string">Busted</album><year 
xsi:type="xsd:int">2002</year><amazonLink xsi:type="xsd:string">http://
www.amazon.com/exec/obidos/redirect?link_code=ur2&tag=motiveforcell-
20&camp=1789&creative=9325&path=external-search%3Fsearch-
type=ss%26index=music%26keyword=Busted%20Busted</amazonLink><songs 
xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="xsd:string[13]"><item 
xsi:type="xsd:string">What I Go To School For</item><item 
xsi:type="xsd:string">Crash And Burn</item><item 
xsi:type="xsd:string">Britney</item><item xsi:type="xsd:string">Losing You</
item><item xsi:type="xsd:string">Year 3000</item><item 
xsi:type="xsd:string">Psycho Girl</item><item xsi:type="xsd:string">All The 
Way</item><item xsi:type="xsd:string">Sleeping With The Light On</
item><item xsi:type="xsd:string">Dawson's Geek</item><item 
xsi:type="xsd:string">When Day Turns Into Night</item><item 
xsi:type="xsd:string">Everything I Knew</item><item 
xsi:type="xsd:string">Without You</item><item xsi:type="xsd:string">Loser 
Kid</item></songs></item></albums></ns1:getArtistResponse>"

Any help regarding this error will be appreciated. Thanks. TheUnknown 06:30, 22 October 2007 (EDT)

Unsing webservice from python

Hi, how to use this webservice from python? I tried to search for some Czech songs (I added) from python using SOAPpy and ZSI (see description), but I have encoding and not found problem. Anyone use it with success?--PavelD 04:01, 26 October 2007 (EDT)

Update

Query for song name Jaromír Nohavica:Zatímco Se Koupeš via ZSI is resolved as Jaromír Nohavica:Zatímco Se Koupe? (some of the nonASCII chars are replaced by question marks) - now it is on Special:Soapfailures. It this because of error on phyton side (missing information about encoding or so) and have I report bug to the ZSI developers or your webservice don't resolve correct query and you are able to fix it? Thanks --PavelD 06:05, 26 October 2007 (EDT)

api.php

SOAP is still a bit incomplete, why standard MediaWiki http://lyricwiki.org/api.php does not work? exe 04:51, 23 November 2007 (EST)

At the time that we made our api.php file, MediaWiki did not have a normal api.php yet (and we didn't know they were planning on making one).

-Sean Colombo (talk|contribs) 09:03, 14 June 2008 (EDT)

getArtist for Britney Spears

When I try and return an array of albums from Britney Spears, it just returns 1 array with songs in it and no albums. It'll work with every other artist I've tried though.

$artist = 'Britney Spears';
$result = $client->call('getArtist', array('artist' => $artist ));
print_r($result);

Am I doing something wrong?

lyric Tags in Lyrics

Hi All,

I have noticed in some songs e.g. http://lyricwiki.org/Nine_Inch_Nails:Right_Where_It_Belongs

when you fetch the lyrics you will get tags like

<./lyric.>
= = V2 = =
<.lyrics.>

inside the lyrics string. Is there a way to parse this?

Much appreciate pointing me in the right direction.

Thanks in advance, McoreD

P.S: I put . in the middle otherwise even this post gets parsed.

Another url showing this: http://lyricwiki.org/api.php?artist=In%20Extremo&song=Davert-Tanz&fmt=xml

Vb.net and german language

I have big problems to parse this site correctly: http://lyricwiki.org/B%C3%B6hse_Onkelz:Dunkler_Ort

((?:.|\n)*?)

", "")<br/>            ret = ret.Replace("

I don't know why, but all german special letters like 'ä,ö,ü,' and so on are wrong.

solved****
i changed to 
Dim url As String = "http://lyricwiki.org/api.php?artist=B%C3%B6hse_Onkelz&song=Dunkler_Ort&fmt=text"
and everything is ok

SOAP fails "all of a sudden"?

I have been accessing the page with PHP for a couple of weeks now and retrieved data via SOAP without problems until about yesterday. Now, all I get returned are the following values:

Result

Array
(
    [artist] => Thursday
    [song] => A Hole in the World
    [lyrics] => Not found
    [url] => http://lyricwiki.org
)

artist and song being correct (capitalized how I posted it though), lyrics and url seem to give me a "Not found" response. The entry clearly exists though, and the script used to work w/o problems until hours ago as well.

PHP-Code

<?php
require_once("nusoap/lib/nusoap.php");

$lyricwiki = array(
    "user" => "e*****e",
    "pass" => "*******",
    "server" => "http://lyricwiki.org/server.php?wsdl"
);

print_r(get_lyrics("Thursday", "A Hole In The World", $lyricwiki));

/**
  * Return the lyrics for a given artist/song pair
  *
  * @author mag. mario rader / k9soft.com
  * @param $artist string artist name
  * @param $tracktitle string track title
  * @param $param array lyricwiki params
  * @return array result
  * @copyright mag. mario rader / k9soft.com
  */
function get_lyrics($artist = false, $tracktitle = false, $params) {
    $client = new soapclient($params['server'], true);

    $err = $client->getError();
    if ($err) {
        //msg
    }
    else {
    	$proxy = $client->getProxy();
    	if(($params['user'] != "") || ($params['pass'] != "")){
            $headers = "<username>" . $params['user'] . "</username><password>" . $params['pass'] . "</password>\n";
    	    $proxy->setHeaders($headers);
    	}
    	
    	$result = $client->call(
    	    'getSong',
    	    array('song' => ucwords(strtolower($tracktitle)), 'artist' => ucwords(strtolower($artist))),
    	    'uri:playlist',
    	    'uri:playlist/getLyrics'
    	);
    }

    if ($client->fault) {
        //msg
    }
    else {
        $err = $client->getError();
        if ($err) {
            //msg
        }
        else {
            return $result;
        }
    }
    
    return false;
}
?>

--Emocide 06:55, 25 February 2008 (EST)

Hi, thanks for reporting this... In the future, the quickest way to get a hold of me if it seems like a problem on LyricWiki's end (and not just general discussion about the API) would be to leave a message on my talk page. I get email-alerts when people change that page.

Anywho... this was a temporary issue due to a bug I had created, then fixed that night. There is more information here.

-Sean Colombo (talk|contribs) 10:43, 26 April 2008 (EDT)

Please correct the Encoding-Handling

The Server got a big Problem: If you request a document and use "ISO 8859-1" as Encoding in the Request-Header, the server answers with a encoding of "ISO 8859-1" (both in HTTP-Header and XML-Document). The big problem is: The lyrics ARE acutaly encoded in UTF-8, so the whole XML-File is not valid at all because it claims to be ISO 8859-1 but is in fact UTF-8, at least the lyrics. Please fix this, because this might be the problem for the ruby, perl and other clients. Theomega 05:15, 25 April 2008 (EDT)

Hmm... interesting problem. The lyrics themselves are actually UTF-8 though and I don't think they can be accurately put into ISO 8859-1 all the time if they're stored in utf8 (or can they?). So is the correct solution just to utf8-decode the results and shoot them out, or is there a place to set which encodings are accepted. If ISO 8859-1 is fine with international characters then I guess I can just set the encoding of the response to match the request and it should just work. Do you happen to know?

-Sean Colombo (talk|contribs) 07:27, 25 April 2008 (EDT)

The following solution would imho be the best: Use UTF-8 everytime on response (for ALL responses, regardless of the request-encoding). So send UTF-8 and also declare the document as UTF-8. Imho this is the only solution which will guarantee that every character entered here is send out as a soap-response. --Theomega12:05, 1 May 2008 (EDT)

I try many hours finally found out it was server side's problem. The text format is good, but XML, HTML format is bad. Ex.text_correct、 XML_wrong、 HTML_wrong--Tomin 17:32, 9 May 2008 (EDT)

Thank you for the links, they are very helpful in testing. I'm kind of confused because any time I fix those songs, it is breaking other languages. It appears that different inputs will need to be handled differently. For instance, French, Mandarin? (is that the language you provided?), and Czech all appear to give completely different results.

For my own reference, here are a bunch of different links. Once they ALL work, then the system is probably working correctly:

• French title: [API: Michael_Bublé:Moondance as text, html, xml] (test)
• French lyrics: [API: Joe_Dassin:Et_Si_Tu_N'existais_Pas as text, html, xml] (test)
• Mandarin: [API: 1976:態度 as text, html, xml] (test)
• Czech: [API: Jaromír_Nohavica:Zatímco_Se_Koupeš as text, html, xml] (test)
• English: [API: Tool:Schism as text, html, xml] (test)
• German: [API: Böhse_Onkelz:Dunkler_Ort_German as text, html, xml] (test)
• Not Found: [API: Fake:Not_A_Real_Song as text, html, xml] (test)

-Sean Colombo (talk|contribs) 20:50, 8 June 2008 (EDT)

Yes, they are Mandarin. Thanks, Sean. I'm so happy it works now. But 'artist' and 'song' tag in XML are still question marks(????). example--Tomin 10:41, 10 June 2008 (EDT)

Just had another report about encoding issues... turns out the "Not Found" doesn't return UTF-8 header. Added to list of test-cases.

-Sean Colombo (talk|contribs) 14:34, 21 July 2008 (EDT)

Fixed. -Sean Colombo (talk|contribs) 23:20, 21 July 2008 (EDT)

Sweet! I'm declaring victory now :-D! Hopefully that isn't too premature, but of all of the test-cases above, they all work now (some results will be bad in the cache for the next 5 hours but that will fix itself). If anyone finds any problems with the encoding stuff, please let me know as soon as possible on my talk page so I can jump on it while this stuff is still fresh in my mind.

Thanks to everyone for the detailed bug reports and for your patience as I really dragged my feet trying to figure this one out.

-Sean Colombo (talk|contribs) 23:20, 21 July 2008 (EDT)

Yet another encoding issue

I'm using Orcas WCF in .NET 3.0 to create proxies and connect to your webservice.

I DO use UTF-8 encoding in request, but the response is always been returned in ISO 8859-1. The problem is: the WCF engine does not support ISO 8859-1 encoding for message exchange. Can you fix this, please?

This is the same issue as above, but nevertheless it should be fixed fast! Theomega 11:33, 8 May 2008 (EDT)

NOTE: Just to tie up the lose-ends - I'm pretty sure this part of the problem has been fixed. There are more encoding problems though. See this thread above for more info.

-Sean Colombo (talk|contribs) 14:42, 21 July 2008 (EDT)

Weird messages on top of lyrics?

I am getting weird messages on top of lyrics from the api. Like: Doors polyphonic ringtones Doors sheet music Concert tickets

See: [5]

I checked it out, those lines were actually on the page. My guess is that someone pasted the lyrics from another site which had that at the top of it. I've fixed it now for that song.

Thanks for the head's-up,

-Sean Colombo (talk|contribs) 08:37, 14 June 2008 (EDT)

Another encoding problem

It seems that the encoding problem happened again...

Below is a simple script to test the encoding problem related to Chinese Characters(and Japanese too)

the URL to this lyrics is http://lyricwiki.org/陶喆:小镇姑娘 ,you can compare the output of the script to the original lyrics.:

#!/usr/bin/env python

# -*- coding: UTF-8 -*-

import urllib

from ZSI import ServiceProxy

artist = "陶喆"

title = "小镇姑娘"

wsdlFile = "http://lyricwiki.org/server.php?wsdl"

lyricServer = ServiceProxy.ServiceProxy(wsdlFile)

lyrics = lyricServer.getSong(artist=urllib.quote(artist), song=urllib.quote(title))['return']["lyrics"]

print lyrics

Yegle 07:44, 17 June 2008 (EDT)

Hello??Anybody there??Yegle 11:25, 21 June 2008 (EDT)

Sorry for not replying. If you ever don't hear from me, please leave a message on my talk page which will send me an email-alert.

I'm working on the encoding issues right now... it seems to be a total mess where I can't fix one set of languages without breaking another set. Gonna keep hammering away at it and hopefully it'll come together.

I'm going to keep track of the progress in this thread. Sorry for the delays.

-Sean Colombo (talk|contribs) 14:40, 21 July 2008 (EDT)