Version: 2.3.1-GIT (using Devel) OS: Linux The wiki widget is not showing anything for me, except for the artist Modest Mouse. All others show just the circular working indicator. This not bug 23567. I looked at xsession-errors (see below for actual) and Modest Mouse results are retreived from cache even though I removed all of my cache and temp dirs from outside of kde (is this my cache or wikipedia cache?). No errors are shown for artists not retrieved and I am no the only person with this happening to except they get a few more artists (again including Modest Mouse) see http://forum.kde.org/trunk/viewtopic.php?f=115&t=88798&p=163136&hilit=amarok+wiki#p163198 xsession-errors: === Modest Mouse - wiki widget displays information ==================== "http://en.wikipedia.org/w/index.php?title=Modest%20Mouse%20%28band%29&useskin=monobook" kio_http(24199)/kio_http_debug HTTPProtocol::maybeSetRequestUrl: "http://www.dailymotion.com/rss/rated/search/Modest%20Mouse%20Horn%20Intro" kio_http(24212)/kio_http_debug HTTPProtocol::maybeSetRequestUrl: "http://en.wikipedia.org/w/index.php?title=Modest%20Mouse%20%28band%29&useskin=monobook" kio_http(24199)/kio_http_debug HTTPProtocol::resetSessionSettings: Using proxy: false URL: "" kio_http(24212)/kio_http_debug HTTPProtocol::resetSessionSettings: Using proxy: false URL: "" kio_http(24199)/kio_http_debug HTTPProtocol::resetSessionSettings: Window Id = "" kio_http(24199)/kio_http_debug HTTPProtocol::resetSessionSettings: ssl_was_in_use = "" kio_http(24212)/kio_http_debug HTTPProtocol::resetSessionSettings: ssl_was_in_use = "" kio_http(24199)/kio_http_debug HTTPProtocol::proceedUntilResponseContent: kio_http(24199)/kio_http_debug HTTPProtocol::proceedUntilResponseHeader: kio_http(24199)/kio_http_debug HTTPProtocol::sendQuery: kio_http(24199)/kio_http_debug HTTPProtocol::satisfyRequestFromCache: kio_http(24212)/kio_http_debug HTTPProtocol::satisfyRequestFromCache: ============ Charlie Haden - nothing in wiki widget ========================= "http://en.wikipedia.org/w/index.php?title=Charlie%20Haden%20%28band%29&useskin=monobook" kio_http(24212)/kio_http_debug HTTPProtocol::maybeSetRequestUrl: "http://en.wikipedia.org/w/index.php?title=Charlie%20Haden%20%28band%29&useskin=monobook" kio_http(24212)/kio_http_debug HTTPProtocol::resetSessionSettings: Using proxy: false URL: "" kio_http(24212)/kio_http_debug HTTPProtocol::resetSessionSettings: Window Id = "" kio_http(24212)/kio_http_debug HTTPProtocol::resetSessionSettings: ssl_was_in_use = "" kio_http(24212)/kio_http_debug HTTPProtocol::proceedUntilResponseContent: kio_http(24212)/kio_http_debug HTTPProtocol::proceedUntilResponseHeader: kio_http(24212)/kio_http_debug HTTPProtocol::sendQuery: kio_http(24212)/kio_http_debug HTTPProtocol::satisfyRequestFromCache: kio_http(24212) HTTPProtocol::sendQuery: Sending Header: kio_http(24212) HTTPProtocol::sendQuery: "GET /w/index.php?title=Charlie%20Haden%20%28band%29&useskin=monobook HTTP/1.1" kio_http(24212) HTTPProtocol::sendQuery: "Host: en.wikipedia.org" kio_http(24212) HTTPProtocol::sendQuery: "Connection: Keep-Alive" kio_http(24212) HTTPProtocol::sendQuery: "User-Agent: Mozilla/5.0 (compatible; Konqueror/4.4) KHTML/4.4.90 (like Gecko) SUSE" kio_http(24212) HTTPProtocol::sendQuery: "Pragma: no-cache" kio_http(24212) HTTPProtocol::sendQuery: "Cache-control: no-cache" kio_http(24212) HTTPProtocol::sendQuery: "Accept: text/html, image/jpeg;q=0.9, image/png;q=0.9, text/*;q=0.9, image/*;q=0.9, */*;q=0.8" kio_http(24212) HTTPProtocol::sendQuery: "Accept-Encoding: x-gzip, x-deflate, gzip, deflate" kio_http(24212) HTTPProtocol::sendQuery: "Accept-Charset: utf-8, utf-8;q=0.5, *;q=0 Reproducible: Always Steps to Reproduce: play a song, view wiki widget Actual Results: circular working indicator Expected Results: wiki page displayed
This is happening for me too, and I've been testing (on random) since reading the forum post. Still getting a few more bands to add to my list of working wikipedia pages, but since I don't know if it is something special about these band pages, I don't know if it's worthwhile to list them. Still, just in case it's useful: Evanescence, L7, Santana, The Beatles, M83, Joy Division, Kenny Loggins, Foo Fighters, The Fray, Bush, Often lyrics aren't fetching either, but again, sometimes they are displayed. It seems to be quite independent of the wikipedia problem, since sometimes they both work, sometimes neither, and sometimes one, sometimes the other. Again, no error in the output from --debug --nofork.
Confirmed by Valorie
@Valorie I can confirm Beatles, Kenny Loggins and Santana also work for me (only ones you listed that I have).
up'ed today to amarok-2.3.1.60svn20100625-37.7.x86_64.rpm and it appears that the wiki widget is working again (at least for me and this version). I got 7 for 7 artists.
Unlikely it is really fixed, since Valorie runs a current git version and still has the bug, your's is older. But I can't reproduce this with my version which is the same as Valorie has, on the same Kubuntu 0.04 system. So maybe it is a network setting in the individual systems?
I didn't change any network settings, only other thing I did (other than update Amarok) is yesterday I up'ed KDE to 4.4.92 from 4.4.90
Created attachment 48750 [details] Patch to fix network error handling in wiki applet
Investigated this issue and found out that this is probably a regression caused by commit 1b1ecbb50f51d2a2c19756701710f535d9f208e3 (adding commiter Rick W. Chen to CC). This commit made several context view applets use the network access manager class. The new code cancels a wiki search on every network error reply, also a 404 (page not found) error. However the wiki applets performs several url refinements until it finds a valid wiki-url. This mechanism wasn't working anymore, because a 404-error immediately canceled the complete wiki-algorithm, instead of starting a new and refined wiki-search. The attached patch should fix this problem by not aborting the wiki-fetch in case of a 404 network-reply. This should also fix BR238874. Patch additionally contains some minor whitespace fixes.
Thanks Rainer for the patch. I've since fixed that problem in my local branch. It's actually not a simple fix, since I changed a lot on how refinements are handled. This is for a feature I'm introducing, which is to support all languages from wikipedia. It's pretty much done, but I need to test it a bit more so I'm not sure when I'll be merging that into master. Though I don't mind if anyone wants to commit the patch and fix this problem quickly.
Rainer: The madness that is if( m_wiki.contains("wgArticleId=0") && (m_wiki.contains("wgNamespaceNumber=0") || m_wiki.contains("wgPageName=\"Special:Badtitle\"") ) ) // The article does not exist is there because we want to find out we are being served the custom 404 page. If we are then the refinements are tried next. By stripping those out the refinements don't get called. This is all pretty hackish since we're parsing the html but there's a better solution to see if a page exists by using mediawiki's listing apis.
Isn't this the same bug than bug 238874? Seems to be a duplicate.
I agree that https://bugs.kde.org/show_bug.cgi?id=238874 seems to be a duplicate, because in both cases the refinement mechanism isn't working. @Rick: Great news that you're working on further improving the wiki applet. Hope we're seeing your changes soon. Pls. let us know if you need someone to test your local branch. Regarding merge of the patch: no problem from my side to wait until Rick has finished his work. Although the patch seems to work properly for me, I'm able to update it with regards to comment #10, if it's needed quickly.
*** This bug has been marked as a duplicate of bug 238874 ***