[galvanash]

Im having some trouble with a plugin I am trying to write...

Essentially I am using a combination of httpapi/vfs to pull library data and thumbnails/fanart from a running xbmc install. This is being done from a plugin on _another_ xbmc install (which is running Dharma RC1). Im essentially trying to write a plugin that acts more or less like a remote library. I plan on switching to jsonrpc at some point, but I digress...

I have it all working except for one thing. When I do this (example is hardcoded just to demonstrate the problem):

Code:

listitem.setProperty( "fanart_image", "http://user:[email protected]:83/vfs/special://masterprofile/Thumbnails/Video/Fanart/7112eafe.tbn" )

in my plugin, the property is getting set correctly. The url is valid, I have tested numerous times in a browser. However, the fanart is never displayed and the logs have this in it:

Code:

21:11:58 T:1132 M:2530697216   DEBUG: CTextureCache::GetImageHash - unable to stat url http://user:[email protected]:83/vfs/special://masterprofile/Thumbnails/Video/Fanart/7112eafe.tbn

I do the pretty much exactly the same thing for the thumbnails, and they work just fine. I can see the debug output for the thumbnail loads and it all looks normal. Its only the fanart doing this.

Any ideas? I have never run into this behavior before - and I have done lots of plugins, although never one that uses vfs urls (don't see how that would matter though)...

When I do "Movie Information" on an item, it will _occasionally_ (about 1 in 20 times) load the fanart in the dialog, but it is never displayed in the listview. I suspect those loads are uncached, and none of the fanart ever seems to get written to the xbmc fanart cache folder.

[jmarshall]

Do you need to URL encode the path in the vfs perhaps?

[galvanash]

Do you need to URL encode the path in the vfs perhaps?

Tried that, and I tried without a username or password set. Same error

Code:

00:10:38 T:4888 M:2395361280   DEBUG: CTextureCache::GetImageHash - unable to stat url http://1.2.3.4:83/vfs/special%3A//masterprofile/Thumbnails/Video/Fanart/ddb08dbf.tbn

The only thing I have not tried is running on the default port of 80... I have to reconfigure my router to do that and I was hoping to avoid it. Im at a complete loss as to what is going on - the url loads fine in a browser (encoded or unecoded).

EDIT: I figured out a way to quickly switch to using port 80 without a lot of hassle - it didn't make any difference...

[galvanash]

I also just copied my plugin over to my xbox running a build of xbmc4xbox that is about a week old. It worked fine there - there has to be something funky with the Dharma RC1...

[galvanash]

I had a friend of mine try my plugin on xbmc/win32 r34379. The plugin works properly on that build too. I think this is a regression sometime between then and now. I will comb through the svn logs and try to find a clue...

[galvanash]

I have spent the last 3 hours trying to debug this in xbmc. I don't get it. The place in the code where things seem to go wrong is here (line 1084 FileCurl.cpp):

Code:

if(result == CURLE_HTTP_RETURNED_ERROR)
  {
    long code;
    if(g_curlInterface.easy_getinfo(m_state->m_easyHandle, CURLINFO_RESPONSE_CODE, &code) == CURLE_OK && code == 404 )
      return -1;
  }

urls that point to my xbmc vfs paths always return 404s, so the if block returns -1 and everything goes poof... But the paths are valid - browsers can load them fine. The url2 structure looks correct - everything looks correct - it just wont load the url.

This is the path I am using (I simplified everything to get rid of possible variables, port is set to 80 for httpapi on my source xbmc machine, username and password are blank:

http://192.168.0.2/vfs/special%3a//maste...62a107.tbn

If I load that path in my browser, it loads up just fine. It works when the plugin is run on an xbmc4xbox install, and it works when run from an older build of xbmc, just not on Dharma RC1...

I can't figure this out and it is driving me nuts... It has to be something in libcurl that has changed, and I can't trace into that.

[galvanash]

Ok, I finally figured it out...

This block of code was added fairly recently (in the last few months).

FileCurl.cpp line 1087:

Code:

if(result == CURLE_HTTP_RETURNED_ERROR)
  {
    long code;
    if(g_curlInterface.easy_getinfo(m_state->m_easyHandle, CURLINFO_RESPONSE_CODE, &code) == CURLE_OK && code == 404 )
      return -1;
  }

Since this block returns -1 for a result of CURLE_HTTP_RETURNED_ERROR, it effectively hides the code that immediately follows it. The code immediately after it appears to retry the request as a get if the head request failed.

FileCurl.cpp line 1094:

Code:

if(result == CURLE_GOT_NOTHING
  || result == CURLE_HTTP_RETURNED_ERROR
  || result == CURLE_RECV_ERROR /* some silly shoutcast servers */ )
  {
    /* some http servers and shoutcast servers don't give us any data on a head request */
    /* request normal and just fail out, it's their loss */
    /* somehow curl doesn't reset CURLOPT_NOBODY properly so reset everything */
    SetCommonOptions(m_state);
    SetRequestHeaders(m_state);
    g_curlInterface.easy_setopt(m_state->m_easyHandle, CURLOPT_TIMEOUT, 5);
    g_curlInterface.easy_setopt(m_state->m_easyHandle, CURLOPT_RANGE, "0-0");
    g_curlInterface.easy_setopt(m_state->m_easyHandle, CURLOPT_WRITEDATA, NULL); /* will cause write failure*/
    result = g_curlInterface.easy_perform(m_state->m_easyHandle);
  }

If I comment out the first if block, my plugin works again. So 1+1=2 and bob's your uncle - the builtin http server in xbmc does not respond properly to head requests. I tested with a standalone http testing tool and it does indeed return 404s for any and all head requests.

So the question is: Do I submit a bug for the not responding to head requests, or do I submit a bug to re-instate the previously functioning work-around (which appears to have been intended for shoutcast servers, but it works equally well with xbmc's http server).

I know that the httpapi is deprecated, but I suspect this is a bug in the actual server itself (which is probably used by json-rpc as well when used over http).

Thoughts?

[jmarshall]

The former.