sounds like we're getting a pattern.  bug 5609 and bug 5611 are likely to therefore all be the same issue.  however, this is not yet reproducible for me. I cannot even check on this on, simply becuase I do no use windows for the server.  Try nuking the plugin-data.yaml file in the cache folder and restarting.  Lets see if refreshiing all of the plugin data has some effect.  

Was this an upgrade over 6.5.x or a fresh install?

Created attachment 2198 [details]
drop optionsurl

the optionsurl in the install.xml gives the server the location of the settings page.  As there are no settings for PreventStandby, there should be no optionsurl.

I saw this behaviour with 7 installed into a separate directory to 6.5 but using my 6.54 prefs file.

Install.xml for PreventStandyBy lokks like this 
<?xml version="1.0"?>

<extension>
        <id>BFACABFD-6334-4743-95BA-43A60E159560</id>
        <name>PLUGIN_PREVENTSTANDBY</name>
        <module>Slim::Plugin::PreventStandby::Plugin</module>
        <version>1.0</version>
        <description>PLUGIN_PREVENTSTANDBY_DESC</description>
        <creator>Julian Neil, Slim Devices/Logitech</creator>
	<email>support@slimdevices.com</email>

	<defaultState>enabled</defaultState>
        
        <homepageURL>http://www.slimdevices.com/</homepageURL>
        <optionsURL>slim://PreventStandby/content/settings.html</optionsURL>
	<type>2</type><!-- type=extension -->

        <targetApplication>
  	        <id>SqueezeCenter</id>
                <minVersion>7.0a</minVersion>
                <maxVersion>7.0+</maxVersion>
        </targetApplication>

	<targetPlatform>Windows</targetPlatform>

</extension>




The plugin-data.yaml contains this for PreventStandby


Slim::Plugin::PreventStandby::Plugin: 
  basedir: C:\Program Files\SlimServer7\server\Slim\Plugin\PreventStandby
  creator: Julian Neil, Slim Devices/Logitech
  description: PLUGIN_PREVENTSTANDBY_DESC
  email: support@slimdevices.com
  error: 0
  homepageURL: http://www.slimdevices.com/
  id: BFACABFD-6334-4743-95BA-43A60E159560
  module: Slim::Plugin::PreventStandby::Plugin
  name: PLUGIN_PREVENTSTANDBY
  optionsURL: slim://PreventStandby/content/settings.html
  state: 1
  targetApplication: 
    id: SlimServer
    maxVersion: 7.0+
    minVersion: 7.0a
  targetPlatform: Windows
  type: 2
  version: 1.0



...so it does seem like a specified file is not present.

take the optionsURL line out of plugin-data.yaml and the settings link will be greyed out.

fixed at change 13401

Tested again

SqueezeCenter Version: 7.0 - 13344 - Windows XP - EN - cp1252
Server IP address: 163.33.84.62
Perl Version: 5.8.8 MSWin32-x86-multi-thread
MySQL Version: 5.0.22-community-nt


Windows/Classic skin.

When I go to the server settings, prevent standby does not have an item in the drop down menu like many of the other plugins, but if I go to extra's and click on the Jigsaw puzzle image, I still get

Settings | Disable | Enable 

buttons

My plugin-data.yaml looks like this now.

Slim::Plugin::PreventStandby::Plugin: 
  basedir: C:\Program Files\SlimServer\server\Slim\Plugin\PreventStandby
  creator: Julian Neil, Slim Devices/Logitech
  description: PLUGIN_PREVENTSTANDBY_DESC
  email: support@slimdevices.com
  error: 0
  homepageURL: http://www.slimdevices.com/
  id: BFACABFD-6334-4743-95BA-43A60E159560
  module: Slim::Plugin::PreventStandby::Plugin
  name: PLUGIN_PREVENTSTANDBY
  optionsURL: slim://PreventStandby/content/settings.html
  state: 1
  targetApplication: 
    id: SqueezeCenter
    maxVersion: 7.0+
    minVersion: 7.0a
  targetPlatform: Windows
  type: 2
  version: 1.0

Maybe the change didn't make it into the nightly.

erase plugin-data.yaml and restart

I'll need to wait for the next nightly, the 1-Oct nightly still has the install.xml for PreventStandby below.
I've made your change to my system and t fixes the inssue, but it hasn't made it to the install.xml on my system.
The nightly is only  up to change 13344

<?xml version="1.0"?>

<extension>
        <id>BFACABFD-6334-4743-95BA-43A60E159560</id>
        <name>PLUGIN_PREVENTSTANDBY</name>
        <module>Slim::Plugin::PreventStandby::Plugin</module>
        <version>1.0</version>
        <description>PLUGIN_PREVENTSTANDBY_DESC</description>
        <creator>Julian Neil, Slim Devices/Logitech</creator>
	<email>support@slimdevices.com</email>

	<defaultState>enabled</defaultState>
        
        <homepageURL>http://www.slimdevices.com/</homepageURL>
        <optionsURL>slim://PreventStandby/content/settings.html</optionsURL>
	<type>2</type><!-- type=extension -->

        <targetApplication>
  	        <id>SqueezeCenter</id>
                <minVersion>7.0a</minVersion>
                <maxVersion>7.0+</maxVersion>
        </targetApplication>

	<targetPlatform>Windows</targetPlatform>

</extension>

Sorry to post again so soon. Just tested this change it works fine.
However, I still get a Settings button, that is enabled, but does nothing.

Should I raise a separate bug. Plugins with no <optionsURL> tag should result in the Setting button being disabled or not present at all. The current situation is confusing. There's a button that does nothing.

that's not a bug.  the settings button is present, but greyed out.  Verified yet again on my setup.
if that's not the case make sure you've cleared the browser cache. 

Created attachment 2205 [details]
Firefox screengrab

Screen grab of the settings page in Firefox with Firebug enabled.

I've retested again using the 2-Oct windows nightly.
The Settings button does nothing, but is not correctly greyed out. I've inspected the HTML with firebug and the disabled tag is incorrect.

<tr id="PLUGIN_PREVENTSTANDBY-div" style="">
<td/>
<td>
<input type="button" disabled="" value="Settings"/>
<input id="PLUGIN_PREVENTSTANDBY.toggle" type="submit" value="Disable" name="PLUGIN_PREVENTSTANDBY.disable"/>
<input id="PLUGIN_PREVENTSTANDBY.uninstall" type="submit" value="Uninstall" name="PLUGIN_PREVENTSTANDBY.uninstall"/>
</td>

.. it should be 

<input type="button" disabled="true" value="Settings">

See attached image.

I'm still not seeing any problem, but will reopen anyway. However, I admit that I have not checked the classic skin.

Ok, so I've looked at Settings is disabled correctly in Default, but enabled in classic.

Didn't realise the skin would make a difference. Not a big deal. Maybe could be left as TODO.

not sure what to say here.  Classic looks fine to me.  the code for the page is like so:

[% IF settings AND enabled %]

<input type="button" value="[% 'SETTINGS' | string %]" onClick="location.href='[% webroot %][% settings %][% IF player %]?player=[% playerURI %]&amp;playerid=[% playerURI %][% END %]'">

[% ELSE %]

<input type="button" value="[% 'SETTINGS' | string %]" disabled>

[% END %]

I don't know where you are getting this line from:
<input type="button" disabled="" value="Settings"/>

as the above would simply be an onClick link OR this:
<input type="button" value="Settings" disabled>

The only page that handles this template is HTML/EN/settings/server/plugins.html, so it shouldn't be skin dependent.  Perhaps something has been left behind from an earlier install (not that I can find anything in svn that shows a different version in the history), or a caching issue (albeit I can't explain how what you are seeing would have gotten into the cache). Are you able to find any copies of plugins.html in your HTML tree?  If so, where are they and can you attach them.

Ross, could you look at this and see how easy it is to reproduce?  We need to figure out if we need to fix this for 7.0.

I don't even see an 'extra' for prevent stand by in 7 trunk, was it removed?

it is only enabled on windows, and only shows up under the settings page for extras as there is no ui for it.

Sorry but I'm a little confused. I'm using XP, I browse to SqueezeCenter settings, then Extras, and I see plugins but I do not see the prevent standby plugin. Should I see settings for prevent standby? 

its one of the puzzle items on the SC Settings->Extras page, with the name "Windows: Prevent System Standby While Playing"

(In reply to comment #10)
>  the settings button is present, but greyed out.  Verified
> yet again on my setup.

Thank you KDF. I'm also seeing the button present, but greyed out, in both default and classic. 

Okay, so is there still really a bug here?  A grayed out button doesn't sound too bad.

grayed out is what it is supposed to be.  Original reporter is not seeing that, despite everything else being equal.  I have no explanation and cannot reproduce. If the setting button is to be removed, that's an enhancement but I suspect that will not help in this specific case because the code presented from the page is already not something generated by the current server.

okay thanks KDF.  So the current bug, looking at Mick's posts, is that he has a button that looks normal but does nothing, when he should have a grayed-out button.  And you and we can't reproduce it.

that's correct.  The source example posted doesn't look match up with what can be produced by the template (see comment 15).  Best I can suggest is to blow away the cache folder (Cache\templates, specifically) and perhaps even the HTML folder and reinstall to make sure there are no garbage templates floating about.  

Ok, so the button behaves correctly on Windows IE7, but Firefox on the same machine sohws the button enabled.

The image I attached was in Firefox, with the buttons tag displayed in firebug.

sorry, but I use firefox all the time, and it is greyed out here.  the word "settings" still shows through when using teh default skin (classic templates for settings), but the button style is faded out.  

I have no idea what firebug is doing with this, but it is most certainly NOT the real code.  Here is the source form http://localhost:9000/classic/settings/server/plugins.html:

			<tr id="PLUGIN_PREVENTSTANDBY-div" style="display: none;">
				<td>&nbsp;</td>
				<td>
					<input type="button" value="Settings" disabled>
					<!-- XXXX - need to check for pending uninstall / install -->

You button styles are also incorrect.  Are you running an old firefox?  are you blocking javascript? I'm sorry, but I really can't keep treating this as a bug.  It seems a setup issue somewhere.

Created attachment 2219 [details]
firefox 2.0.0.7 capture, classic skin. WinXP SP2

Mick do you still see this? If not I'd like to close this bug. 

Appears to be resolved.  Please reopen if it's still happening.