win7 64bit with some mcafee crap on it
i had SBS 7.5.2b and it would startup and run on every reboot for months.
have installed a recent 7.5.3b and now SBS will not load at startup. why? i have no idea. the shortcut for the tray tool is in the startup folder and i get a UAC prompt for it when i manually click it. after that it does start the tray tool and it does start SBS. after that, i can see that the tray tool DOES have the 'load the server automatically at startup' (or whatever) checked.
it used to work as expected. now, with 7.5.3b it doesn't. why?
should i try telling it not to run as admin? i didn't change it from what it was tho...
(btw, i don't see SBS listed as a service, only mysql, but SBS runs anyway, normal?)
Results 1 to 10 of 15
2011-01-03, 21:01 #1
Bug? other issue? SBS 7.5.3b won't autostart
Last edited by MrSinatra; 2011-01-03 at 21:05.
2011-01-04, 11:24 #2
2011-01-05, 15:13 #3
well, without any help beyond the link posted above, i found some answers. this has been annoying, and i want to walk thru it b/c it leaves a lot of unanswered questions for the devs to resolve.
i had various "r" versions of 7.5.2b on win7 64bit running for months with np. everything started and worked fine regardless of which r release.
a week or so ago i installed 7.5.3b and at first glance all seemed to be well. however what i realized after a few days was that on reboot of the machine, SBS was no longer loading as it had been.
i still do not know why. the tray tool shortcut was present in the startup folder, but SBS was not loaded. when manually clicked on, i got a UAC prompt, and even when i clicked thru that, the tray tool / SBS didn't work. i eventually got rid of the UAC prompts by telling the shortcut / app via the properties to NOT run as admin. when it was 7.5.2 that didn't seem to be a problem.
regardless of that, i came across the link in my last post, and i did that, which worked to get SBS listed as a service again. why was that necessary? why was SBS no longer listed as a service? i still don't know. it had been listed as a service when it was 7.5.2 but as 7.5.3 suddenly it wasn't.
even then all was not well.
yes, i could now access SBS, but the music was all gone, it said i had no library configured. it had NO reaction to "clear and rescan" yet it had all the right settings. there was no "home > artists" no "home > albums" etc... no error messages, ugh.
i looked in the server log, and i noticed a lot of mentions of 7.5.2 and the lazy search plugin near each other. why, whats that about? annoying.
so i go to the plugins page and uncheck that plugin, restart SBS and voila, everything is back! reboot the machine, and everything is back to normal.
so why does the plugin kill the SBS/DB communication? and why does SBS allow it to run if it isn't compatible? i have "update plugins automatically" enabled.
here's an idea for a plugin for SBS: plugin verifier!
it would disable any plugin that wasn't rated to work with the SBS version you're using. that would have saved me a nasty problem. when it evetually automatically updates, it can take effect again when its rated to work with the SBS version installed.
i do not know if the plugin is what removed SBS as a service, or if its just a co-incidental issue.
but anyway, this was a lot of crap to wade thru for just innocently going from 7.5.2b to 7.5.3b
it would be nice if the devs would at least acknowledge this, meaning that they would take steps to keep such things from happening again going forward.
Last edited by MrSinatra; 2011-01-05 at 15:23.
2011-01-05, 15:18 #4
Anyway, 7.5.3 should not have broken a plugin that works in a previous 7.5 build, so I'd be curious about the contents of your log file.
2011-01-05, 15:19 #5
Also it's possible your 7.5.3 build was screwed up by our nightmare of a build system. You might try running the svn version.
2011-01-05, 15:43 #6
first, thx for the replies, i really appreciate that.
second, are you saying that you think your build system is the reason why SBS wasn't listed as a service anymore? and why the tray tool was messed up?
i really don't mean to bitch, but perhaps you guys should fix your nightmare build system? i got the DL from a link saying its safe to do so:
i don't know how to use the SVN stuff, why its different, or really anything about it, i'm not that advanced.
personally, i don't think its your build system, but i wouldn't know. i just think these kinds of problems should be avoided by you all at ALL costs. whatever actually is causing nonsense like this, needs fixed permanently!
as to the plugins...
i understand what you are saying, but thats the point of my plugin suggestion. if someone used my plugin verifier, what it would do is disable any plugin where the developer doesn't specifically indicate that it has been verified to work with the SBS point version installed. so somewhere in the lazy search plugin for example, would be a line that says "verified with 7.5.3b"
i will copy the server log here later if the entries still exist.
thx again for replying!
2011-01-05, 16:07 #7
Hey all I can say is it's a beta, sometimes it doesn't work. But 7.5.3 is essentially done and will be released in a few weeks most likely. And given that it's been 6+ months since 7.5.1 (7.5.2 doesn't count) and lots of people have been using this code without any problems, I can't think what else it might be other than:
* bad build somehow
* user error
2011-01-05, 19:22 #8
- Join Date
- Apr 2005
There do seem to be a number of reports lately of either SbS 7.5.x/7.6 being unable to install itself as a Windows service, or of it not starting up at boot time. Does the installer uninstall the service and then reinstall it again (which is how it does most things)? That would account for that latter if users don't realize the service wasn't reinstalled.
2011-01-05, 22:13 #9
However, this doesn't work, I've tried it and got a lot of complaints because users that wanted to use my plugin with a SBS version which I hadn't tested the plugin with yet. I got a lot more complains with the limitation than what I get today with no limitation.
The issue is that no plugin developer can safely say that a plugin works with 7.6.x beta because it might be compatible today but there might be changes tomorrow that makes it incompatible. In the system you want, it wouldn't be enough to say that it's compatible with the 7.6.0 beta, you would have to say that it's compatible with 126.96.36.199711 (where 31711 is the revision number of a specific nightly build).
If the plugin developers set the max version to a specific revision number it would mean that people running beta on the latest major version would not be able to use third party plugins. Third party developers don't really do this as their work, they don't get payed, they do this on their spare time for free, so you can't expect them to do a new verification after each nightly build. We already today have some problem that third party developers (including myself) don't have enough spare time or motivation to do a new verification after each official production release.
The problem is a bit less with the beta version of the next minor version, 7.5.3 in this case, because as Andy say it mostly doesn't contain any changes that breaks plugins. Basically if a plugin has been tested with 7.5.0 it should also work with 7.5.3.
What I've personally done is:
1. I've limited the automatic download to 7.* (in repository xml file) which means that my plugins can be downloaded from the plugin tab in any 7.x release but not in 8.0 beta when we get there.
2. If the plugin is downloaded and installed manually, it's still possible to use, because my install.xml contains maxTarget=* which allows it to be manually installed in any version.
I can't change point 1 to 7.5.* because then I would get a lot of complains that no one using 7.6 beta can use my plugins and I don't have the time to verify them once a week with 7.6 to update the version number to something like 188.8.131.52711. Most people running a beta version prefer to be able to use the plugin and help with the plugin verification and report to the plugin developer if they get any problems.
Theoretically, a possible solution would be to have an option where you in SBS can specify that you want to allow unverified plugin versions, but the issue is still the same because some plugin developers (including myself) doesn't always have time to do the verification after each official release. So it would result in that more or less all users that use third party plugins would have to have this option checked and then it's a pretty useless option.
The main usage of the current system is to make it possible for a plugin developer to provide one plugin version for 7.4.x and another version for people that use 7.5.x, this is very useful and avoids a lot of complains/issues for users who run an older SBS release.Erland Isaksson (My homepage)
(Developer of many plugins/applets (both free and commercial).
If you like to encourage future presence on this forum and/or third party plugin/applet development, consider purchasing some plugins)
You may also want to try my Android apps Squeeze Display and RSS Photo Show
Interested in the future of music streaming ? ickStream - A world of music at your fingertips.
2011-01-06, 01:07 #10
Same people that uses plugins and certainly yours are also willing to beta test.
So no plugins almost no beta testers it's that simple .
Your plugins also perform essential squeezebox functions the system does not work without them.
To compound this i would loathe to go back to 7.5 I find many of the improvements essential too .
So I'm "stuck" in 7.6 , That looks like a setup
Now I must participate in bug hunts for both Logitech and whoever's plugin breaks in 7.6--------------------------------------------------------------------
Main hifi: Touch + CIA PS +MeridianG68J MeridianHD621 MeridianG98DH 2 x MeridianDSP5200 MeridianDSP5200HC 2 xMeridianDSP3100 +Rel Stadium 3 sub.
Kitchen: Touch + powered Fostex PM0.4
Misc use: Radio (with battery)
iPad1 with iPengHD & SqueezePad
(in storage SB3, reciever ,controller )
server HP proliant micro server N36L with ClearOS Linux