Bugzilla – Bug 5143
View log file from web interface
Last modified: 2009-09-08 09:15:22 UTC
Add a possibility to display the contents of the log file from the web interface, from Server Settings/Debugging. This will simplify debugging and error reporting since it provides an installation independent way of viewing the log file.
This already exists in 6.5.2, see the link at the top of the debugging page. this is, however, gone from 7.0 by design, instead reporting the location of the server and scanner log files.
> gone from 7.0 by design Why? What's the benefit?
Sorry I missed that this was already (partly) available. Why not open a window with a scroll bar with the complete log? Another improvement would be to indicate somewhere that there have been serious errors with more information in the log. My log contains several "fatal" error suchs as unitialized strings, errors saving playlists etc. But NO information at all when this occured. I think that the user shall be informed of the fact that there have been serious problems, definitely when using the web intface (perhaps indicating this on a line at the top with a link to the log file and a possibility to clear the notification.
The logging has completely been rewritten. In 7.0 there will not only be different levels of messages (warn, info, debug), but there will be a time stamp as well.
> Sorry I missed that this was already (partly) available. Why not open a window > with a scroll bar with the complete log? The log file could be massive. Older events are likely irrelevant to anything that you're troubleshooting. It also wouldn't be 'live' like the tail display is, continually refreshing with newly added log events. You could manually refresh the display of the entire log, but if it's a large file, that doesn't work at all well.
The old logging URL was very useful and only maintained a tail of a few kilobytes of data. Would it be possible to add the same facility back in, but with the new logging framework?
*** Bug 6204 has been marked as a duplicate of this bug. ***
Will look at this post-7.0.
I have on my todo list to build a live log interface using File::Tail or something like that. Bug yeah, post-7.0.
That's great. It's a feature that was lost and I've been missing. Feel free to grab it for a particular target release sooner, andy.
Fixed in change 15744. You can now access /log.txt, /server.log, or /scanner.log to view the log file. The webpage will update in real-time. Add a ?lines=X param to change the number of initial lines to show (defaults to 5).
Bugs: In IE6 - It hangs no matter what. When /server.log is requested a 'downloading' dialog box appears and then hangs. In FF2 - It hangs when the log file is empty, as with an empty scanner.log. - Missing log files don't hang, but nothing happens, either. The web browser never receives a 404 reply. - When the log file is served, it appears that the page never completely loads. The hourglass is displayed continuously, and any other loading status animations run constantly. - When first loaded, the HTTP header appears in the output. I see five log lines, the HTTP header, five more lines from the log. - A request for a nonexistent, unrecognized .log file (e.g. /servr.log) shows HTML output in the web browser. Bad or missing HTTP headers?
That's how it's supposed to work, it will update in real-time as long as you let it load.
(In reply to comment #13) > That's how it's supposed to work, it will update in real-time as long as you > let it load. I guess you're just referring to this? > When the log file is served, it appears that the page never completely loads. > The hourglass is displayed continuously, and any other loading status > animations run constantly. That's mostly just annoying. This might be a good use for AJAX. Or perhaps serve a page with a hidden frame in which the log is displayed Then the constant hourglass should go away while the page within the frame continues to load. The rest of the bugs should be addressed.
Reopening, as this really is broken in a few ways. Andy - aren't we going too far with this? Those of us who want to keep an eye on the logs are working in a shell anyway. Most of the others will be told by us or support to get a log. In these cases five lines isn't enough, adding a parameter asking for trouble... Why don't we just return the full log file? Stupid and simple. But in that case support or whoever at least gets all the information available.
The full log file is way too big, though. We could do like we used to and just return the last N lines, what was it like a few hundred?
It's a shame that this feature is being released like this. Can I suggest changing the Version to 7.0 so that the problems remain on the radar?
Let's have it just tail the file like before. Users can hit reload if they need it loaded. A progressive download isn't that useful.
change 18081 - create simple tail using File::Backwards instead of File::Tail
Verified Fixed Version: 7.0.1 - 19422 SC > Settings > Status page now includes different Log View options (100, 500, 1000 lines)
This bug has recently been fixed in the latest release of SqueezeCenter 7.0.1 Please try that version, if you still see the error, then reopen this bug. To download this version, please navigate to: http://www.slimdevices.com/su_downloads.html
Reduce number of active targets for SC