WWWinamp Status Update
26 February 2008Just a quick status update to everyone who stops by my blog for news on WWWinamp 
I’m currently working on fixing socket errors I’m seeing when interacting with Safari on Windows (I haven’t tested on my Apple computers yet). This issue is also related to a hanging socket issue I’ve noticed with the iPhone switches from EDGE to Wi-Fi. These issues can result in partially loaded data and messed up UI in the browser. Firefox and I.E. don’t seem to have these issues, and if they do they’re able to recover.
Part of my work around is making an active IP Table which will track active connections allowing you to restrict how many connections from a client are being serviced, as well as being able to link resource usage to a specific connection. This way administrators can restrict say, how many files a person is allowed to download at a time. It will also help in debugging WWWinamp as I’m going to implement a verbose debugging option that will dump all vital information to an XML file. This trace log will allow me to better assist people in identifying possible issues with WWWinamp.
Also planned for this new version is a few features requested here on the site. One in particular that never crossed my mind was suggested by “dawolf” here that the HTTP server still function even though an instance of Winamp cannot be found. This way WWWinamp could also serve as a lightweight HTTP daemon (as a simpler alternative to Apache or IIS).
Look for this new version coming within the next week.
Cheers!
2 Responses to “WWWinamp Status Update”
February 28th, 2008 at 1:26 pm
Thanks for considering my input. My reason for the request was that i would like to put wwwinamp in autostart and launch winamp from the web interface.
A few more observations: My version 4.2 b2955 seems to have a problem with paging (the page=N parameter). I cant browse the library using the “next page”/”prev page” links. Looks like wwwinamp ignores the page parameter. Search still works. Anybody able to reproduce this?
Another thing i noticed while trying to create a custom skin… the *.wwa files are always taken from the webroot directory. I cant put a modified library_file.wwa file in a /search subdirectory and use that file. I cant put another skin in a subdirectory (eg. /iphone) and use it from there because the .wwa files are always taken from the webroot.
February 29th, 2008 at 9:44 am
I’ll reply to the topics here to keep it easy to read
Paging Issue - I’ll look into this issue tonight. I’ve made quite a few changes to how the web server handles form/url data, so it may no longer be an issue in the current build I’m using.
Usage of the *.WWA files - This is actually a good point. I had never thought (before the iPhone skin) that someone might run multiple skins at the same time, just in different folders. I think the best solution to this problem would be to use the *.wwa files in the current path of the file using the “|LIBRARY|” or “|PLAYLIST|” tags. This way you can have multiple skins nested in sub-directories and custom WWA files for each.
How do these sound??
Thanks again for your feedback!