[jmarshall]

your analysis is mostly correct.

i've rewritten the routine to use the common functions - i suspect much of these were not in existence when this routine was originally written.

i'll test it out and get it in to cvs.

cheers,
jonathan

[goofygrin]

sah-weet....

i'm building xbmc now... man it takes forever

what all did you change? (so i can get the right things from cvs to play with)

[jmarshall]

i just changed the xbmcgetcurrentlyplaying() routine.

the main issue i think is not with that routine at all.

see xbmccommand(). after it gets a command from the httpapi thread, it issues a threadmessage. these are processed by the main xbmc thread each frame - it then calls xbmccommand() which then calls the appropriate xbmc*() command.

after that though it sleeps for 100ms in release builds. this is a sleep of the main xbmc gui thread - thus obviously reducing the framerate somewhat (by at least 5 frames).

i've dropped that back to 10ms, and added a comment for the original dev of this code which may know more about why this is here.

cheers,
jonathan

[goofygrin]

wow... that's interesting...

the comment in there is that they have to make it 500ms if they are debugging...

i'm rebuilding now and will see how it affects what happens with my client... (my wife is going to kill me if she finds out i'm working on this stuff instead of spending time with her )

[goofygrin]

ok... here's the result of my testing (i got the xbmchttp.cpp from cvs that you checked in):
at 10ms, i was still getting stuttering in the visualization (like every second or so...

i looked and the thread that comes in (xbmcprocesscommand) has a wait on it... i'm not sure why the response process is waiting at all.

so, i took the wait out completely.  now there's no stuttering at all and the web interface seems to be pretty snappy (e.g. the returns are happening much faster now).  in fact, i was able to make the refresh every 900 ms rather than 500ms (which lowers the load even more).

so, we need to find out why that delay is there in the first place (it makes no sense to me...).

thanks!

edit: duration isn't showing up (it's returning "")...  i'm sure it's a minor thing...
for my purposes, i hacked in there:

cstdstring strtime;
stringutils::secondstotimestring((int)g_application.gettotaltime(), strtime);
output+=closetag+opentag+"duration:"+strtime;

[pike]

some new issue introduced with jm's changes

after a cpl of hours when i played many songs and used the test/test.html interface someone did (sorry too tired to look up who made it), and after playing some videos (debug log was 1mb) webserver stopped responding, and also nothing in log when it fails to respond. i get a timeout in ff

[goofygrin]

pike, that's the one i made...

i've seen similar issues as well... i'm not sure what's happening.

heck, i've made xbmc lockup just browsing my media collection (no logs though)

[goofygrin]

the changes also lost the song number, so the playlist (on my app) doesn't get set right:

tmp.format("%i",g_playlistplayer.getcurrentsong());
output+=closetag+opentag+"songno:"+tmp;

[pike]

also, this used to work:

http://xbox/xbmccmds/xbmchttp?command=takescreenshot&parameter=test.jpg;true;0;720;576;95;true;imgtag

on firefox (not ie) but stopped with jm's change

[goofygrin]

i've made some updates...

here: test-6

same rules, extract and copy to your xbox...

new features:
- file browser
- can add to and remove from playlist

there are a couple issues:
- without the fix for the total time and the filenumber i outlined above, the playlist doesn't update right (correctly highlighting the current song) and the player doesn't display the total time
- the logic i made for the image copy is somewhat broken (it leaves extra jpgs in the /web folder)
- the file browser doesn't filter out non audio tracks
- it only works with music bookmarks
- having the page open makes xbmc unable to exit (since the webserver is still receiving requests)

as always, i've tested it with ie 6 and firefox 1.5.
the layout/colors/etc. are all controlled by css in the style.css and can be tweaked to your heart's desire...

[goofygrin]

also, this used to work:

http://xbox/xbmccmds/xbmchttp?command=takescreenshot&parameter=test.jpg;true;0;720;576;95;true;imgtag

on firefox (not ie) but stopped with jm's change

this could be why the delay is in there... but i'd say that if this is the only operation that needed the delay, we should only pause when that operation is called.

in my testing over the last couple hours, removing the pause works just fine for normal stuff (like playing, adding to/removing from the playlist).

[goofygrin]

the thread sleep was added in revision 1.38 of xbmchttp.cpp by xbmcapi with the comment:
fixed:made it more thread safe
added: getcurrentlyplaying now provides both picture and audio information if music is being played during a slideshow

so the change was probably made for "thread safety."

[pike]

ok, some more info

takescreenshot fails after you started running goofygrin's test. probably related to one of these:

27-03-2006 07:01:29 debug xbmchttpshim: received command setresponseformat (closefinaltag;true)
27-03-2006 07:01:29 debug httpapi start command: setresponseformat paras: setresponseformat; closefinaltag;true
27-03-2006 07:01:29 debug httpapi finished command: setresponseformat
27-03-2006 07:01:29 debug webs: accept request
27-03-2006 07:01:29 debug xbmchttpshim: received command setresponseformat (opentag;<li>)
27-03-2006 07:01:29 debug httpapi start command: setresponseformat paras: setresponseformat; opentag;<li>
27-03-2006 07:01:29 debug httpapi finished command: setresponseformat
27-03-2006 07:01:29 debug webs: accept request
27-03-2006 07:01:29 debug xbmchttpshim: received command setresponseformat (closetag;</li>)
27-03-2006 07:01:29 debug httpapi start command: setresponseformat paras: setresponseformat; closetag;</li>
27-03-2006 07:01:29 debug httpapi finished command: setresponseformat
27-03-2006 07:01:29 debug webs: accept request
27-03-2006 07:01:29 debug xbmchttpshim: received command setresponseformat (webheader;true)
27-03-2006 07:01:29 debug httpapi start command: setresponseformat paras: setresponseformat; webheader;true
27-03-2006 07:01:29 debug httpapi finished command: setresponseformat
27-03-2006 07:01:29 debug webs: accept request
27-03-2006 07:01:29 debug xbmchttpshim: received command setresponseformat (webfooter;true)
27-03-2006 07:01:29 debug httpapi start command: setresponseformat paras: setresponseformat; webfooter;true
27-03-2006 07:01:29 debug httpapi finished command: setresponseformat
27-03-2006 07:01:29 debug webs: accept request
27-03-2006 07:01:29 debug xbmchttpshim: received command setresponseformat (header
27-03-2006 07:01:29 debug httpapi start command: setresponseformat paras: setresponseformat; header;
27-03-2006 07:01:29 debug httpapi finished command: setresponseformat
27-03-2006 07:01:30 debug webs: accept request
27-03-2006 07:01:30 debug xbmchttpshim: received command setresponseformat (footer
27-03-2006 07:01:30 debug httpapi start command: setresponseformat paras: setresponseformat; footer;
27-03-2006 07:01:30 debug httpapi finished command: setresponseformat

i have a playlist of ~240 items, which causes heavy load using goofygrin's test (it seems to load the tags of each item) (nice stress test btw) if i seek around a bit and then

1. go back to playlist
2. (possibly) swith back to filesview
3. play some more, 1 + 2

im likely to "kill" webserver. once i had database errors, 2 times after i tested there were no error's at all in Debug Log.

[goofygrin]

the first part that you quoted was something i did to make the response more "xmlish" so that i could load it into an xml dom easier...

if you restart xbmc and don't run my client, does take a screenshot work? (that would be really odd if it did).

as far as the heavy load for the playlist, this is something i was worried about. someone previously on this thread asked if we could display the tag title vs. the filename since itunes did something wierd to the filename.... so now, i go through, for each file in the playlist and load it's taginfo (only once as long as the window's open).

i'd thought about doing something similar to slimserver and only showing the previous x number of songs and next y number, which would lower my memory usage (among other things).

however, if your playlist is in random mode, i'm not sure how that works... (not party mode, i've not looked at all at that).

as far as not getting logs, i"m not sure what's happening there... i don't know anything about that webserver, so i'm as lost as the next guy with it

[nate12o6]

is this project dead?