Login at Kodi Home

Haggy · 2009-03-14, 18:08

Hi!

I'm experiencing problems using xbmc's builtin last.fm function. I can connect to last.fm with my username and password, but selecting any stream or searching for artists and playing those results in a short progress window and nothing else.

In the log i see:

Code:
56:45 T:3367967056 M:2622717952   DEBUG: Curl::Debug About to connect() to ws.audioscrobbler.com port 80 (#0)

56:45 T:3367967056 M:2622717952   DEBUG: Curl::Debug   Trying 195.24.233.55...

56:45 T:3367967056 M:2622717952   DEBUG: Curl::Debug Connected to ws.audioscrobbler.com (195.24.233.55) port 80 (#0)

56:45 T:3367967056 M:2622717952   DEBUG: Curl::Debug GET /radio/xspf.php?sk=aef5798f6ef9dc43078d842af7e452c4&discovery=0&desktop= HTTP/1.1

56:45 T:3367967056 M:2622717952   DEBUG: Curl::Debug User-Agent: XBMC/pre-9.04 r18477M (Linux; Linux 2.6.28-ARCH; http://www.xbmc.org)

56:45 T:3367967056 M:2622717952   DEBUG: Curl::Debug Host: ws.audioscrobbler.com

56:45 T:3367967056 M:2622717952   DEBUG: Curl::Debug Accept: */*

56:45 T:3367967056 M:2622717952   DEBUG: Curl::Debug Connection: keep-alive

56:45 T:3775223840 M:2622717952   DEBUG: ------------------- GUI_MSG_WINDOW_DEINIT

56:45 T:3775223840 M:2622717952   DEBUG: Progress dialog

56:45 T:3775223840 M:2622717952   DEBUG: -------------------

56:45 T:3367967056 M:2624606208   DEBUG: Curl::Debug HTTP 1.0, assume close after body

56:45 T:3367967056 M:2624606208   DEBUG: Curl::Debug HTTP/1.0 200 OK

56:45 T:3367967056 M:2624606208   DEBUG: Curl::Debug Date: Sat, 14 Mar 2009 15:56:47 GMT

56:45 T:3367967056 M:2624606208   DEBUG: Curl::Debug Server: Apache/1.3.39 (Unix)

56:45 T:3367967056 M:2624606208   DEBUG: Curl::Debug X-Proxy-Fix-Up: headers fixed up

56:45 T:3367967056 M:2624606208   DEBUG: Curl::Debug X-Web-Node: www178

56:45 T:3367967056 M:2624606208   DEBUG: Curl::Debug Connection: close

56:45 T:3367967056 M:2624606208   DEBUG: Curl::Debug Content-Type: text/plain;charset=utf-8

56:45 T:3367967056 M:2624606208   DEBUG: FileCurl::Close(0x7f86c8befa90) http://ws.audioscrobbler.com/radio/xspf.php?sk=aef5798f6ef9dc43078d842af7e452c4&discovery=0&desktop=

56:45 T:3367967056 M:2624606208   DEBUG: Curl::Debug Expire cleared

56:45 T:3367967056 M:2624606208   DEBUG: Curl::Debug Closing connection #0

56:45 T:3367967056 M:2624606208   ERROR: LastFmManager: Unable to parse tracklist Error: Error reading Element value.

56:45 T:3367967056 M:2624606208   DEBUG: CacheTrackThumb: Done (time: 0 ms)

57:15 T:3775223840 M:2622525440    INFO: CheckIdle - Closing session to http://ws.audioscrobbler.com (easy=0x3261790, multi=0x3074230)

57:15 T:3775223840 M:2620985344    INFO: CheckIdle - Closing session to http://ws.audioscrobbler.com (easy=0x3258d70, multi=0x2fc6f80)

As you can see LastFmManager is unable to parse the responded xml file though it is valid - i opened it in firefox and it showed fine.

This is on svn -r18477 and x86_64 on Arch Linux.

Any hints?

Haggy · 2009-03-16, 11:41

*bump*

Nobody having any issues with last.fm? On x86_64?

althekiller · 2009-03-16, 16:40

It's linuxport in general, something to do with the filecurl changes I suspect. You could help by narrowing down an approximate range of revs where the bug may have been introduced.

Haggy · 2009-03-16, 16:52

OK, thanks for the hint. Unfortunately i never had lastfm working on xbmc. I'm a rather new xbmc user. On Atlantis it refused to work due to a known login issue on x86_64 which got fixed in svn around -r17000 i think. I then switched to svn mainly because of that bug and the introduction of vdpau, so i cannot narrow the revision down to where it used to work.

tslayer · 2009-03-16, 17:23

This looks like we don't properly handle HTTP 1.0 responses where there is no content-length or chunked transfer.

Can you file a trac ticket with the exact steps you took reproduce?

Thanks.

tslayer · 2009-03-16, 17:41

Hmm.. I just tested and it does work in my environment:

Code:
36:14 T:3052242784 M: 71151616   DEBUG: FileCurl::Open(0xbfdb77fc) http://ws.audioscrobbler.com/radio/xspf.php?sk=baeaf307821fba2336cc3fa6397d751c&discovery=0&desktop=

36:14 T:3052242784 M: 71151616    INFO: easy_aquire - Created session to http://ws.audioscrobbler.com

36:14 T:3052242784 M: 71176192   DEBUG: Curl::Debug About to connect() to ws.audioscrobbler.com port 80 (#0)

36:14 T:3052242784 M: 71176192   DEBUG: Curl::Debug   Trying 195.24.233.55...

36:14 T:3052242784 M: 71176192   DEBUG: Curl::Debug Connected to ws.audioscrobbler.com (195.24.233.55) port 80 (#0)

36:14 T:3052242784 M: 71176192   DEBUG: Curl::Debug GET /radio/xspf.php?sk=baeaf307821fba2336cc3fa6397d751c&discovery=0&desktop= HTTP/1.1

36:14 T:3052242784 M: 71176192   DEBUG: Curl::Debug User-Agent: XBMC/pre-9.04 r18599M (Linux; Ubuntu 8.04.2; Linux 2.6.24-23-generic; http://www.xbmc.org)

36:14 T:3052242784 M: 71176192   DEBUG: Curl::Debug Host: ws.audioscrobbler.com

36:14 T:3052242784 M: 71176192   DEBUG: Curl::Debug Accept: */*

36:14 T:3052242784 M: 71176192   DEBUG: Curl::Debug Connection: keep-alive

36:15 T:3052242784 M: 71229440   DEBUG: Curl::Debug HTTP 1.0, assume close after body

36:15 T:3052242784 M: 71229440   DEBUG: Curl::Debug HTTP/1.0 200 OK

36:15 T:3052242784 M: 71229440   DEBUG: Curl::Debug Date: Mon, 16 Mar 2009 15:36:09 GMT

36:15 T:3052242784 M: 71229440   DEBUG: Curl::Debug Server: Apache/1.3.39 (Unix)

36:15 T:3052242784 M: 71229440   DEBUG: Curl::Debug X-Proxy-Fix-Up: headers fixed up

36:15 T:3052242784 M: 71229440   DEBUG: Curl::Debug X-Web-Node: www114

36:15 T:3052242784 M: 71229440   DEBUG: Curl::Debug Connection: close

36:15 T:3052242784 M: 71229440   DEBUG: Curl::Debug Content-Type: text/plain;charset=utf-8

36:15 T:3052242784 M: 71229440   DEBUG: Curl::Debug Closing connection #0

36:15 T:3052242784 M: 71229440   DEBUG: FileCurl::Close(0xbfdb77fc) http://ws.audioscrobbler.com/radio/xspf.php?sk=baeaf307821fba2336cc3fa6397d751c&discovery=0&desktop=

36:15 T:3052242784 M: 71229440   DEBUG: RequestRadioTracks: Done (time: 1203 ms)

So. perhaps it is related to the version of libcurl being used? Which version do you have installed?

**xnappo** · 2009-03-16, 17:51

tslayer Wrote:Hmm.. I just tested and it does work in my environment:

Does yours continue to play the next song is a song list? I am wondering if this bug is related to the 'not playing next song' issue.

xnappo

Haggy · 2009-03-16, 17:58

tslayer Wrote:So. perhaps it is related to the version of libcurl being used? Which version do you have installed?

It's curl 7.19.4 and libcurl 4.1.1 from the stable arch linux repository.

Code:

haggy@aereogramme ~ $ yaourt -Si curl

Repository     : extra

Name           : curl

Version        : 7.19.4-1

URL            : http://curl.haxx.se

Licenses       : MIT  

Groups         : None

Provides       : None

Depends On     : zlib  openssl>=0.9.8b  bash  ca-certificates  

Optional Deps  : None

Conflicts With : None

Replaces       : None

Download Size  : 554.85 K

Installed Size : 1468.00 K

Packager       : Eric Belanger <[email protected]>

Architecture   : x86_64

Build Date     : Wed 04 Mar 2009 02:07:24 AM CET

MD5 Sum        : 29feac880edde7a42bd9cf8fd0c41f90

Description    : An URL retrival utility and library

Code:
haggy@aereogramme ~ $ ls -l /usr/lib/libcurl*

-rw-r--r-- 1 root root 521454 2009-03-04 02:07 /usr/lib/libcurl.a

lrwxrwxrwx 1 root root     16 2009-03-04 02:07 /usr/lib/libcurl.so -> libcurl.so.4.1.1

lrwxrwxrwx 1 root root     16 2009-03-04 02:07 /usr/lib/libcurl.so.4 -> libcurl.so.4.1.1

-rwxr-xr-x 1 root root 317816 2009-03-04 02:07 /usr/lib/libcurl.so.4.1.1

tslayer · 2009-03-16, 18:02

Ya, there seems to be some paplayer(maybe?) bug where the next track isn't playing unless you pause/unpause and then it starts. But that is a different issue than this. File another trac ticket for that.

Haggy · 2009-03-16, 18:06

Trac ticket is in: http://trac.xbmc.org/ticket/6090

tslayer · 2009-03-16, 18:19

I'm using an older version of libcurl with ubuntu 8.04. I wonder if this fix in newer libcurl caused the failure for you:

CURLINFO_CONTENT_LENGTH_DOWNLOAD and CURLINFO_CONTENT_LENGTH_UPLOAD are -1 if unknown

http://curl.haxx.se/changes.html

Haggy · 2009-03-16, 18:25

well that might be the problem. will provide you a full debug log on trac tonight - i'm not at home at the moment. do you rely on a content-length header for xml parsing?

tslayer · 2009-03-16, 18:35

Yes, it depends on it in our FileCurl implementation.

The issue here is that with my libcurl version, CURLINFO_CONTENT_LENGTH_DOWNLOAD returns the correct length even though there is no content-length header (and having no content-length header is fine with http 1.0 since it can read until the server closes the connection).

My guess is that your version returns -1 and therefore no body is read.

Maybe we can add some logic to try and read the body even if CURLINFO_CONTENT_LENGTH_DOWNLOAD is -1.

Haggy · 2009-03-16, 19:03

tslayer: According to this: http://curl.haxx.se/mail/lib-2001-03/0003.html one may try CURLINFO_CONTENT_LENGTH_UPLOAD to get the filesize on the remote side (yes, this is misleading as said in that post). could this be a fix even for http 1.0 requests? i always thought curl was developed to NOT have to hassle with sockets and protocols :-)

tslayer · 2009-03-16, 19:08

That makes an assumption that a HEAD request will actually return a Content-Length header. I guess I can test this with Fiddler and see.