Bugzilla – Bug 4412
Debugging settings are not persistent
Last modified: 2008-12-18 11:12:53 UTC
At r10440 prefs (and state?) are not persistent across server restarts. The prefs file is being written to, as seen in the file's modified time, but all changes are lost.
likely also windows-specific, as the prefs are working fine under linux. any custom setup stuff we need to know about?
If I run the server from the console, I'm seeing log output sent to both the console and the log file, with slightly different timestamps. Looks like the messages are sent to the console first, as the timestamps are .0003 or .0004 newer. The uninitialized error below is only sent to the console, however. [15:22:44.2438] main::init (282) SlimServer settings init... [15:22:44.4018] main::init (292) SlimServer strings init... [15:22:44.9154] main::init (295) SlimServer Setup init... 15:22:44.9576 Use of uninitialized value in concatenation (.) or string at C:/Program Files/ SlimServer/server/Slim/Utils/Misc.pm line 145. [15:22:44.9664] main::init (299) SlimServer setting language...
line 145 is a log message for log level info for os.paths. (which I'm sure you are able to confirm for yourself) try setting that log level for that category and you may find what it was trying to look for and which variable is undefined (I suspect $path)
to get rid of that warning: --- Slim/Utils/Misc.pm.old 2006-10-23 11:53:42.278500000 -0700 +++ Slim/Utils/Misc.pm 2006-10-23 12:14:33.012875000 -0700 @@ -138,9 +138,7 @@ sub findbin { # Couldn't find it in the environment? Look on disk.. # XXXX - why only windows? Security issue? - if (Slim::Utils::OSDetect::OS() eq "win") { - - my $path = File::Which::which($executable); + if (Slim::Utils::OSDetect::OS() eq "win" && (my $path = File::Which::which($executable))) { $log->info("Found binary $path for $executable");
One thing I notice: There's a log.conf file being written to the Cache folder, and it picks up the changes I make in the web UI. But it doesn't get written anywhere else in the directory hierarchy. The debug settings are all reset when SlimServer is restarted and the log.conf file is overwritten with the reset settings.
Any progress on this bug? Still seeing it at r10597.
(changing summary to better reflect problem) I just updated my 7.0 installation to the latest r11769, which places the log.conf file in the log directory by default, but the problem with debugging settings not being persistent still exists on my Windows server. What I see is changes that I make to the debugging levels are being saved in log.conf, but when the server is restarted these settings apparently aren't being read.
I think I may have fixed this last night. change 12163.
No luck. I looked at the change and it seems to address writing of the log configuration file. Like I mentioned in comment #7, settings are being written correctly to log.conf, but aren't picked up when the server is restarted. FWIW, the debuggings settings do appear to be in effect when they're set. For instance, if I raise the database.sql debugging level then SQL queries are logged when browsing.
that's unfortunate. they are working fine here, but I never use the installed version. only slimserver.pl with activestate and no funny multi-server hacks (not that those should have any effect). Are you using the --logdir or --logconf args?
(In reply to comment #10) > Are you using the --logdir or --logconf args? No, the log directory is at the default /server/Logs/. --logdir had been working for me at one time in trunk, but it no longer does. Like the --prefsdir and --prefsfile options, it doesn't work when SlimServer is run as a Windows service. https://bugs-archive.lyrion.org/show_bug.cgi?id=4253
(In reply to comment #10) > I never use the installed version. only slimserver.pl with activestate That's also what I'm running. It fails both when run as a service and when run as a user process. Are you saying that you've seen logging prefs persist on a Windows system? Your earlier comment indicated that you thought it might be Windows-specific.
I played with this a bit last night using --debug command line switches, and it looks like it may actually be a problem with the Server Settings > Debugging web page. When I start SlimServer with command line options they're immediately reflected in log.conf and *appear* to be turned on by the activity I see in the log file. But on the debugging web page only one of the settings (I think the first one) is correctly shown in the select drop-downs; the rest continue to display the default level. If the web interface is a work in progress, then I'll just mark this WORKSFORME.
best to leave it open. it does reflect a number of open issues. I'll reduce severity, however.
give this a shot: --- Slim/Utils/Log.pm.old 2007-06-01 10:59:20.430017900 -0700 +++ Slim/Utils/Log.pm 2007-06-01 10:59:29.085880100 -0700 @@ -411,10 +411,11 @@ sub allCategories { my %categories = (); my %config = ($class->_defaultCategories, $class->_customCategories); - while (my ($key, $value) = each %config) { + for my $key (keys %config) { # hide the following as they are not debugging categories next if ($key =~ /additivity|perfmon/); + my $value = $runningConfig{$key}; $key =~ s/^log4perl\.logger\.//;
patch committed at change 12191. Now works for both my linux and windows setups. Marking as fixed, but please reopen if there are still any problems.
This bug is being closed since it was resolved for a version which is now released! Please download the new version of SqueezeCenter (formerly SlimServer) at http://www.slimdevices.com/su_downloads.html If you are still seeing this bug, please re-open it and we will consider it for a future release.