d'oh! I forgot to remove the 'no-cache' http header in 0.75, which evil nature prevents caching and generates unneccessary traffic when serving favicon, pictures and any other files (excluding always reloading main interface). fixed 0.75 is re-uploaded.

Here's my latest version of the Opera/Firefox sidebar, updated to include album art as offered in 0.7.5, and also simplified much more:This screenshot shows it in combination with the brand new Opera 9.5 skin.

I installed it on my girl friend's computer, who listens to her music on a desktop computer, but she prefers using her laptop on her sofa for other geeky activities. So she was interested in having a tool to control her music remotely.

There is a problem, though. When she connects to foo_httpcontrol server using Firefox, it quickly reaches 99% CPU usage, and she has to kill Firefox. She has a 512MB / 1.5GHz laptop with Win XP SP2, she uses Firefox 2.0.0.14 and foo_httpcontrol 0.75.I tried to connect to her server with my own laptop (4GB / 2.6GHz dual core under Win XP SP3) and I get 50% CPU usage for 10 to 20 seconds, then it drops to 0-3% for a while, and jump back to 50%.

Her playlist is big, which is probably the problem (but I read you are testing the plugin on a 23k playlist). She has about 38k tracks.

--

BTW, I personnally use foo_httpcontrol in conjunction with a edcast streaming server and a secured ssh connection with a tunnel. The stream is public, non secured, but the http control can only be performed locally (So I ssh/tunnel the http requests). It works very well with my 10k playlist, but I do not tried with the last version of foo_httpcontrol.

38k tracks is an obvious overload.it takes some time for plugin to process so many tracks internally, but it should be less than a second. and, what's more significant, generated html page size in this case is enormous, something around 5Mb. apparently mozilla is having troubles loading and displaying such big pages.perhaps it is a good idea to try opera 9.5. 23k playlist displays just fine, even with instant page redrawing option turned on.but in my opinion, the only comfortable solution in case of a (very) big playlists is to uncheck 'retrieve playlist' in plugin settings.

but in my opinion, the only comfortable solution in case of a (very) big playlists is to uncheck 'retrieve playlist' in plugin settings.

Thank you. I was thinking of such possibility, but I did not look at the settings. I was also wondering if it would be possible to reduce the size of the web page by, e.g., only displaying the list of artists or albums, and when you click on one of them, it retrieves the list of tracks for the particular artist / album.This is probably far more complex to implement since the playlist is not necessarily ordered by artist/album.

An alternative solution would be to retrieve tracks according to a query that would be given through a web form. So, if the query is carefully chosen, there would not be a huge list to display.

To reduce the page size wouldn't it be possible to display only a limited amout of the playlist splitted in multiple pages ?For exemple : with a 10k songs playlist. Only display 1k songs at once but splitted in 10 pages.The number of songs displayed per page could be defined in the préferences

I've just tested it with your default template and found out that the fit function doesn't have any effect in quirks mode when using IE6 or IE7. If I remove the doctype declaration in my own otherwise XHTML compliant template and thus force the browser to interpret it in quirks mode I experience the same problem. In standards compliance mode however IE7 correctly applies the fit function to make the playlist scrollable while in IE6 it still doesn't work (which is either my fault or that of IE6). But as I said, the playlist gets eaten by IE7 if the code inside the "if (npelem)" condition is executed. Just accessing npelem.offsetTop, offsetHeight or scrollTop triggers the bug. So you don't even have to change any values, which means that even code like below already causes the problem:

I've had a problem with 0.76: the playlist wasn't shown anymore. Tried in various browsers, switched to the original template and saw the same. But then I stopped the music, switched playlists and things started working properly again. After some more trying, I figured out that after switching to a new playlist, it tries to automatically go to the page were the 'now playing' song is on - even though that song is not present on the newly chosen playlist. If the page number is not available in the new playlist because it is shorter, the playlist will not be shown at all.