This could be an IE only bug, related to bug 2206.  
How many rss items do you have in teh prefs?  After about 9, IE seems to go
non-reactive to the form submit.

I only have 6 RSS feeds configured in the RSS News Feed plugin.  I haven't 
changed that configuration for some time (about 3 weeks).  I think I've 
changed other plugin prefs since I last added a RSS feed (but can't be sure).

Phil: what happens if you do a shift-reload (or otherwise flush your cache) in IE?

*** Bug 2206 has been marked as a duplicate of this bug. ***

I have tried forcing a refresh.  I have tried deleting all temporary internet 
files.

I have also tried using both fishbone and default skins.

What about temporarily moving your prefs file.  Let the server start with a
blank slate and see if you can change any prefs.  Other option to test is to
remove all plugins (even the included ones), add them one by one and test until
you hopefully come across the one that starts the problem.  I'll put this on my
list to try as well at some point, but as you know I've got quite a list :)

I have seen this, but so far only with a long list of rss feeds. I've looked on
google for anything related for form submits failing with IE, but have found
nothing that seems to cover this case.

Might sound stupid, but I once meant to experience this problem when my browser 
was in offline mode...

With today's nightly release, this problem has gone away.

I suspect it was something to do with the Random Mix plugin (or an effect of 
having too many items in a form, which perhaps causes a problem in IE6, as KDF 
was speculating).

The Random Mix has now moved from the Server Settings -> Plugin page to 
options in the Random Mix browse mode.

I can now change other Server Settings -> Plugins.

However, I cannot change any of the Mix Settings.  I also cannot add Random 
Songs to end of playlist (although I can see the current playlist refresh, no 
songs are added - perhaps the function doesn't work, rather than associated 
with this problem report where form submission doesn't occur).  Add random 
artists/albums/years seems to add something to the end of the current playlist.

I have 143 genres (mainly because a lot of them are wrong, and I haven't 
corrected them yet) - maybe this is makes the list of checkboxes too long for 
form submission?

I also notice that "Number of upcoming songs in a random mix:" is "10", but 
the pref item I have been trying to change is "Number of old songs in a random 
mix:" which is currently blank (trying to change to 10).  Perhaps the blank 
option is causing a problem?

This seems to be due to some sort of limit on input fields that IE will allow. 
Stripping down to 6 or so plugins, I can get up to about 16 rss feeds before it
stops allowing any input, adding will then fail to respond. Strangely, simply
blanking one of the other fields works, so it isn't just the actual quantity of
existing fields, or maybe it has to do with fields that have text in them.  

ok, here is the real deal:

http://www.webmasterworld.com/forum21/6607.htm
"I believe the max URI length is 4,095 and the max query string length is 2,053,
this applies to ie6. As tedster pointed out, it does vary from browser to
browser. I too had issues with this a year ago and we had to rethink the
strategy of the query."


As a sample, here is the d_http output for a submit on the plugin page (I'll
leave the counting as an excercise for the reader):

 14:56:28.3613 HTTP request: from 127.0.0.1
(HTTP::Daemon::ClientConn=GLOB(0x3f1fa40)) for GET HTTP/1.1
/setup.html?player=f0%3A5a%3Af4%3A24%3A93%3A98&playerid=&page=PLUGINS&plugin
=0&pluginlist0=0&pluginlist0=1&pluginlist1=0&pluginlist1=1&pluginlist2=0&pluginlist2=1&pluginlist3=0&pluginlist3=1&pluginlist4=0&pluginlist4=1&pluginlist5=0&pluginlist5=1&pluginlis
nlist6=1&pluginlist7=0&pluginlist7=1&pluginlist8=0&pluginlist8=1&pluginlist9=0&pluginlist9=1&pluginlist10=0&pluginlist10=1&pluginlist11=0&pluginlist11=1&pluginlist12=0&pluginlist12
ist13=0&pluginlist13=1&pluginlist14=0&pluginlist14=1&pluginlist15=0&pluginlist15=1&pluginlist16=0&pluginlist16=1&pluginlist17=0&pluginlist17=1&pluginlist18=0&pluginlist18=1&pluginl
uginlist19=1&pluginlist20=0&pluginlist20=1&pluginlist21=0&pluginlist21=1&pluginlist22=0&pluginlist22=1&pluginlist23=0&pluginlist23=1&pluginlist24=0&pluginlist24=1&pluginlist25=0&pl
=1&pluginlist26=0&pluginlist26=1&pluginlist27=0&pluginlist27=1&pluginlist28=0&pluginlist28=1&pluginlist29=0&pluginlist29=1&pluginlist30=0&pluginlist30=1&pluginlist31=0&pluginlist31
ist32=0&pluginlist32=1&pluginlist33=0&pluginlist33=1&pluginlist34=0&pluginlist34=1&pluginlist35=0&pluginlist35=1&pluginlist36=0&pluginlist36=1&pluginlist37=0&pluginlist37=1&pluginl
uginlist38=1&pluginlist39=0&pluginlist39=1&pluginlist40=0&pluginlist40=1&pluginlist41=0&pluginlist41=1&pluginlist42=0&pluginlist42=1&pluginlist43=0&pluginlist43=1&pluginlist44=0&pl
=1&pluginlist45=0&pluginlist45=1&pluginlist46=0&pluginlist46=1&pluginlist47=0&pluginlist48=0&pluginlist48=1&pluginlist49=0&pluginlist49=1&pluginlist50=0&pluginlist50=1&pluginlist51
ist51=1&pluginlist52=0&pluginlist52=1&pluginlist53=0&pluginlist53=1&pluginlist54=0&pluginlist54=1&pluginlist55=0&pluginlist55=1&MMSport=10002&plugin_albumreview_refresh=0&plugin_al
remove_brackets=0&plugin_albumreview_cache=999999&scrobbler-user=&scrobbler-password=&scrobbler-auto-submit=1&scrobbler-max-pending=1&plugin_biography_slideshow=0&plugin_biography_
plugin_biography_cache=999999&plugin_biography_ignorelist=test&plugin_calculator_forget_time=60&plugin_calculator_clear_after=1&plugin-Execute-open=%28none%29&plugin-Execute-play=%
plugin-Execute-stop=%28none%29&plugin-Execute-power_on=%28none%29&plugin_Forecaster_units=0&plugin_Forecaster_partner=&plugin_Forecaster_license=&plugin_maximumedgenews_location=0&
imumedgenews_checktime=60&plugin_podcast_feeds0=http%3A%2F%2Fpodcastalley.com%2FPodcastAlleyTop50.opml&plugin_podcast_feeds1=http%3A%2F%2Fpodcastalley.com%2FPodcastAlley10Newest.op
podcast_feeds2=http%3A%2F%2Frss.cbc.ca%2Fbusinessnews.xml&plugin_podcast_feeds3=&plugin-Email-check-when=5&plugin-Email-display=10&plugin-Email-audio=0&plugin-Email-servers=&plugin
rs=&plugin-Email-passwords=&plugin_recentlyplayed_trackcount=40&rescan-scheduled=0&rescan-time=12%3A00+AM&plugin_RssNews_items_per_feed=2&plugin_RssNews_feeds0=http%3A%2F%2Fnews.bb
rss%2Fnewsonline_world_edition%2Ffront_page%2Frss091.xml&plugin_RssNews_feeds1=http%3A%2F%2Fnews.com.com%2F2547-1_3-0-5.xml&plugin_RssNews_feeds2=http%3A%2F%2Fwww.nytimes.com%2Fser
l%2Frss%2Fnyt%2FHomePage.xml&plugin_RssNews_feeds3=http%3A%2F%2Fwww.rollingstone.com%2Frssxml%2Fmusic_news.xml&plugin_RssNews_feeds4=http%3A%2F%2Fslashdot.org%2Findex.rss&plugin_Rs
s5=http%3A%2F%2Frss.news.yahoo.com%2Frss%2Fbusiness&plugin_RssNews_feeds6=http%3A%2F%2Fcia.navi.cx%2Fstats%2Fproject%2FSlimServer%2F.rss&plugin_RssNews_feeds7=http%3A%2F%2Frss.cbc.
oriesnews.xml&plugin_RssNews_feeds8=http%3A%2F%2Frss.cbc.ca%2Fbritishcolumbianews.xml&plugin_RssNews_feeds9=http%3A%2F%2Frss.cbc.ca%2Fbusinessnews.xml&plugin_RssNews_feeds10=http%3
.cbc.ca%2Fbusinessnews.xml&plugin_RssNews_feeds11=http%3A%2F%2Frss.cbc.ca%2Fbusinessnews.xml&plugin_RssNews_feeds12=http%3A%2F%2Frss.cbc.ca%2Fbusinessnews.xml&plugin_RssNews_feeds1
2F%2Frss.cbc.ca%2Fbusinessnews.xml&plugin_RssNews_feeds14=&plugin_RssNews_feeds15=&plugin_screensaver_superdatetime_city=60613&plugin_screensaver_superdatetime_temperature=0&plugin
er_superdatetime_offset=-01&plugin_screensaver_superdatetime_baseball=Chicago+Cubs&plugin_screensaver_superdatetime_refresh=5&plugin_screensaver_superdatetime_time=5&plugin_screens
datetime_score=3&plugin_tophits_trackcount=40

If the form is changed to be one group per form, this will fix the problem. 
Drawback is that changing settings in multiple groups in one shot will no longer
be possible.  Each plugin would have to be changed, then click change, then do
teh next plugin.

Other option, use POST method.  Jacob mentioned that was now possible, but I'm
not sure how to convert to POST or if it is even possible with the existing
templates.

jacob, any thoughts?

note for later, just in case.  group forms require teh following before line
2697 of Setup.pm:
$groupparams{'page'} = $paramref->{'page'};
$groupparams{'player'} = $paramref->{'player'};
$groupparams{'playerid'} = $paramref->{'playerid'};

I know this came up before, with less than enthusiastic reaction (myself
included).  Maybe one compromise is to make it just the plugin page that does
per-group forms, and the rest are per-page

What's the objection to using POST ?

Does someone want to own this?

if I can figure out how to deal with a post, I had been planning to offer 
something. hoped for some tips in here.  I thought I saw mention of being able 
to handle them in slimserver, but I haven't the foggiest idea of where that 
gets done.

POST is the solution, but SlimServer doesn't handle POST yet...

Would this help?  

http://search.cpan.org/~cwest/HTTP-Request-Params-1.01/lib/HTTP/Request/Params.pm

I thought Jacob mentioned that some changes he made a while back would allow
post? maybe I'm confusing it with something else.  Anyway, HTTP::Request looks
like it might do the trick.  I might play around a bit with this and see if I
can pick up an idea.  I can't promise anything. 

I made it possible to retrieve the raw POST data, for the RPC plugin. There's no parsing of parameters from 
POST yet.

ok, this looks easier than I thought.  We probably don't even need
HTTP:Request::params (it requires the whole Email bundle anyway)

If we switch to POST, then what used to be the query string now comes through as
$request->content().  If I simply do:
if ($request->method() eq "POST") {
	$query = $request->content();
}

then it seems the rest of processHTTP already handles the complicated parsing
stuff and the page works.  

Created attachment 901 [details]
use and parse post

I've just changed Fishbone and Default for setup forms only.  With just the few
extra lines in HTTP.pm, IE now happily allows the form submit and the server
parses the content string as if it were the get query.

This also save us having to add HTTP::Request::Params, Email::Simple,
Email::Address, Email::MIME, Email::MessageID, Email::MIME::ContentType,
Email::MIME::Encodings and Email::MIME::Modifier.

I suppose we could use all of the above and replace a large section of
Slim::Web::HTTP.pm, but its hard to say how much gain there is in that if it is
all being scrapped for Apache for 7.0

kdf - I've applied your patch as subversion change 4597

All - this will be in the 2005-10-13 nightly