Subsonic Forum

I absolutely love SS, donating member, user since 2003, etc. etc. But the most recent 4.4 version seems to really have some bugs when it comes specifically to the Linux/Tomcat .WAR version.

I'm getting fullblown java bean errors on Search, and the Cover Art link under Settings results in a 404 resource not found error. I've talked with a few other people who are using the standalone jetty version and they are not having these same issues.

I'll be back-rev'ing either to my previous 4.1 version (if time is lacking), or I'll try reverting to the previous 4.3 and see what happens. I've confirmed several times that 4.1 runs perfectly.

Scientific Linux 5.5, Apache Tomcat 6.

Supra92

What version of java are you running on? Im runing on the sun jdk/jvm and have none of these issues, but I have seen strange things with the openJDK before.

hey baaldemon,

From the SS About screen, server section:

Apache Tomcat/6.0.29, java 1.6.0_22, Linux (71.1 MB / 135.3 MB)

... and confirmed from the linux shell:

# rpm -q jdk
jdk-1.6.0_22-fcs.i586


I just did a yum update, however, and there's a more recent package for SL5.5 -- I'm grabbing that now and will post with what happens!

Cheers,
Supra92

sadly, no dice. 'yum update' updated the jdk to:

# rpm -q jdk
jdk-1.6.0_24-fcs.i586


I then put SS 4.4 back in place, and fired up Tomcat6. Same deal - both Cover Art and Search are completely dead. Search results in that "Invalid property 'offset' of bean class [net.sourceforge.subsonic.command.SearchCommand]: Bean property 'offset' is not readable or has an invalid getter method" error message, while clicking Settings -> Cover Art results in this:



What do you think?

Supra92

Incredibly... I downloaded 4.3 to backrev just one version. Exact same issues -- CoverArt link produces a 404 error and Search results in the bean property offset error. Just like 4.4

Going all the way back to 4.1 resolves all problems! Baffling...

Supra92

I take it you have downloaded the war file from the download options. Do you have much experience with java? I would suggest trying to build the war on your own system, yes java is technically build once run anywhere but there may be some problems.

For the 404 have you looked at your catalina.out file to see what error message is showing in there

indeed, the entire contents of the error message that occurs when i hit the Search button are dumped into the catalina.out file. I'll post a sample of it below. I'm also seeing some memory leak statements, but they would make a lot more sense if all Subsonics failed, including 4.1. But 4.1 works perfectly.

The other thing I'm seeing, and I'm starting to wonder if perhaps this is an issue, is the fact that simply renaming the "Subsonic" folder to "Subsonic_4.1" prior to installing the new 4.4 version.. seems to cause conflicts within the catalina.out file. Meaning.... I have full SS folder trees in Tomcat6's webapps dir, called "subsonic_402b", "subsonic_41", "subsonic_43"... then I deploy the Subsonic 4.4 WAR file and it becomes "subsonic". I'm wondering if leaving all those old Subsonic versions in webapps (despite being renamed) is causing conflicts.

Here's some catalina.out contents:

Code: Select all

[2011-04-07 13:18:49,862] WARN  org.springframework.web.servlet.PageNotFound - No mapping found for HTTP request with URI [/subsonic/coverArtSettings.view] in DispatcherServlet with name 'subsonic'

and

Code: Select all

Apr 7, 2011 1:21:18 PM org.apache.coyote.http11.Http11Protocol pause
INFO: Pausing Coyote HTTP/1.1 on http-8443
Apr 7, 2011 1:21:19 PM org.apache.catalina.core.StandardService stop
INFO: Stopping service Catalina
Apr 7, 2011 1:21:19 PM org.apache.catalina.loader.WebappClassLoader clearReferencesJdbc
SEVERE: The web application [/subsonic] registered the JBDC driver [org.hsqldb.jdbcDriver] but failed to unregister it when the web application was stopped. To prevent a memory leak, the JDBC Driver has been forcibly unregistered.
Apr 7, 2011 1:21:19 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/subsonic] appears to have started a thread named [HSQLDB Timer @15c998a] but has failed to stop it. This is very likely to create a memory leak.
Apr 7, 2011 1:21:19 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/subsonic] appears to have started a thread named [Timer-0] but has failed to stop it. This is very likely to create a memory leak.
Apr 7, 2011 1:21:19 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/subsonic] appears to have started a thread named [pool-1-thread-1] but has failed to stop it. This is very likely to create a memory leak.
Apr 7, 2011 1:21:19 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/subsonic] appears to have started a thread named [pool-1-thread-2] but has failed to stop it. This is very likely to create a memory leak.
Apr 7, 2011 1:21:19 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/subsonic] appears to have started a thread named [pool-2-thread-1] but has failed to stop it. This is very likely to create a memory leak.
Apr 7, 2011 1:21:19 PM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: The web application [/subsonic] appears to have started a thread named [pool-3-thread-1] but has failed to stop it. This is very likely to create a memory leak.
Apr 7, 2011 1:21:21 PM org.apache.coyote.http11.Http11Protocol destroy
INFO: Stopping Coyote HTTP/1.1 on http-8443
Exception in thread "HSQLDB Timer @15c998a" java.lang.NullPointerException
        at org.hsqldb.lib.HsqlTimer.nextTask(Unknown Source)
        at org.hsqldb.lib.HsqlTimer$TaskRunner.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:662)
Apr 7, 2011 1:26:14 PM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/java/jdk1.6.0_22/jre/lib/i386/client:/usr/java/jdk1.6.0_22/jre/lib/i386:/usr/java/jdk1.6.0_22/jre/../lib/i386:/usr/java/packages/lib/i386:/lib:/usr/lib
Apr 7, 2011 1:26:15 PM org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8443
Apr 7, 2011 1:26:15 PM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 1121 ms
Apr 7, 2011 1:26:15 PM org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
Apr 7, 2011 1:26:15 PM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.29
Apr 7, 2011 1:26:15 PM org.apache.catalina.startup.HostConfig deployDescriptor
INFO: Deploying configuration descriptor host-manager.xml
Apr 7, 2011 1:26:15 PM org.apache.catalina.startup.HostConfig deployDescriptor
INFO: Deploying configuration descriptor manager.xml
Apr 7, 2011 1:26:15 PM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive subsonic.war
Apr 7, 2011 1:26:18 PM net.sf.ehcache.Cache initialise
WARNING: Cache: musicFolderCache has a maxElementsInMemory of 0. It is strongly recommended to have a maximumSize of at least 1. Performance is halved by not using a MemoryStore.
Apr 7, 2011 1:26:18 PM net.sf.ehcache.Cache initialise
WARNING: Cache: chatCache has a maxElementsInMemory of 0. It is strongly recommended to have a maximumSize of at least 1. Performance is halved by not using a MemoryStore.
Apr 7, 2011 1:26:19 PM org.apache.catalina.startup.HostConfig deployWAR


And lastly, the error about the Search engine:

Code: Select all

[2011-04-07 13:54:38,441] ERROR org.springframework.web.servlet.tags.form.HiddenInputTag - Invalid property 'offset' of bean class [net.sourceforge.subsonic.command.SearchCommand]: Bea
n property 'offset' is not readable or has an invalid getter method: Does the return type of the getter match the parameter type of the setter?
org.springframework.beans.NotReadablePropertyException: Invalid property 'offset' of bean class [net.sourceforge.subsonic.command.SearchCommand]: Bean property 'offset' is not readable
or has an invalid getter method: Does the return type of the getter match the parameter type of the setter?
        at org.springframework.beans.BeanWrapperImpl.getPropertyValue(BeanWrapperImpl.java:540)
        at org.springframework.beans.BeanWrapperImpl.getPropertyValue(BeanWrapperImpl.java:532)
        at org.springframework.validation.AbstractPropertyBindingResult.getActualFieldValue(AbstractPropertyBindingResult.java:79)
        at org.springframework.validation.AbstractBindingResult.getFieldValue(AbstractBindingResult.java:226)
        at org.springframework.web.servlet.support.BindStatus.<init>(BindStatus.java:120)
        at org.springframework.web.servlet.tags.form.AbstractDataBoundFormElementTag.getBindStatus(AbstractDataBoundFormElementTag.java:172)
        at org.springframework.web.servlet.tags.form.AbstractDataBoundFormElementTag.getPropertyPath(AbstractDataBoundFormElementTag.java:192)
        at org.springframework.web.servlet.tags.form.AbstractDataBoundFormElementTag.getName(AbstractDataBoundFormElementTag.java:158)
        at org.springframework.web.servlet.tags.form.AbstractDataBoundFormElementTag.writeDefaultAttributes(AbstractDataBoundFormElementTag.java:121)
        at org.springframework.web.servlet.tags.form.HiddenInputTag.writeTagContent(HiddenInputTag.java:44)
        at org.springframework.web.servlet.tags.form.AbstractFormTag.doStartTagInternal(AbstractFormTag.java:90)
        at org.springframework.web.servlet.tags.RequestContextAwareTag.doStartTag(RequestContextAwareTag.java:77)
        at org.apache.jsp.WEB_002dINF.jsp.search_jsp._jspx_meth_form_005fhidden_005f0(search_jsp.java:724)
        at org.apache.jsp.WEB_002dINF.jsp.search_jsp._jspService(search_jsp.java:204)
        at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
        at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:377)
        at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:313)
        at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:646)
        at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436)
        at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374)
        at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302)
        at org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:236)
        at org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:257)
        at org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1183)
        at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:902)
        at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:807)
        at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:571)
        at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:511)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:265)
        at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
        at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
        at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
        at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166)
        at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
        at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
        at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
        at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142)
        at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
        at org.acegisecurity.wrapper.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:81)
        at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
        at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173)
        at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
        at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271)
        at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
        at org.acegisecurity.ui.logout.LogoutFilter.doFilter(LogoutFilter.java:110)
        at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
        at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
        at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
        at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:149)
        at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at net.sourceforge.subsonic.filter.RequestEncodingFilter.doFilter(RequestEncodingFilter.java:43)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at net.sourceforge.subsonic.filter.ParameterDecodingFilter.doFilter(ParameterDecodingFilter.java:54)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at net.sourceforge.subsonic.filter.BootstrapVerificationFilter.doFilter(BootstrapVerificationFilter.java:54)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857)
        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
        at java.lang.Thread.run(Thread.java:662)


There is no reason to keep those subsonic folders in the webapp directory. They are just simply the decompressed war files (so you have a backup of those files if you have the war file). Those directories could be causing conflicts but I havent messed around with keeping old directories like that before.

I would suggest just as a trouble shooting step to stop your tomcat service remove all your old directories out of the webapp context and place them just somewhere else on your server so they wont be served up to the web. Delete your current subsonic directory. Then go ahead and restart tomcat, let it redeploy 4.4 and see what happens.

Just did exactly that. I kept the old dirs mostly because I've modified a few of the jpegs and some of the frame widths in the jsp files, and of course the stock .WAR files wouldn't have those mods, so I kept the old ones. However, I did take all of them and moved them out of the $TOMCAT home and over to /home/supra92 so they'd be out of the way.

I then deleted the 'subsonic' folder and all WAR files, and for good measure rebooted the linux server.

When it came back up i stopped the Tomcat6 service, unzipped the 4.4 WAR file into the webapps dir, and then fired up Tomcat again. Sadly it's the exact same issues: SS4.4 streams music fine, but I get the 404 Not Found error when clicking Cover Art, the java bean property error when trying to Search, and of course the newer jwplayer fails as well (though that last one is fixable by copying the old 5.0 jwplayer from SS4.1 into the 4.4 folder...)

At this stage, I can't figure that the older SS installs are interfering with 4.4 anymore -- it's gotta be something that was introduced after 4.1. 4.3 has the identical issues as 4.4 does...

Have you cleared the /var/subsonic/ folders as along with the tomcat webapp?

To me (and believe me I don't know what I'm talking about) it looks like it may be a corrupted aspect of either your Index (located in var/subsonic) or maybe the Databases.

Other thought: Maybe one of your recently added media files has a nasty Character in it that is throwing the search function off? I'm just thinking about how funky characters can really throw off path functions. example: python mod Glob can't handle "[" chars and returns nothing for the dir containing it. I'm not trying to say there is any connection between java and python, but I have noticed SS do some weird things on certain obscure characters.

Hmmm... I've not cleared /var/subsonic, but mostly because I've taken the time over years past to write a whole boatload of album reviews that are there in SS -- they appear underneath the album artist/title/rating, and above the tracklisting. That is stored in the DB, and if i were to clear out the DB entirely (as opposed to just re-indexing which i do nightly) then I'd lose all those reviews (and ratings). That would be tough.

As for the special chars, I actually disallow every single "special char" plus any char that isn't allowed in a windows FS (even tho i run linux, my end-user laptop is Windows)... such as ? or / or \ or %.

One thing that did occur based on your comments is that I added a "music folder" for videos (since that was new for 4.3).... the 3 videos appeared in the left frame, but they wouldn't play and I did see errors in the SS log about being unable to read the video metadata..... So... I removed those 3 vids, deleted the folder, and removed it from the Music Dirs section. Restarted Tomcat, and reindexed.

Still same errors, damn I really thought that might be it there, the videos mucking with the Search, etc.

HOWEVER....

That said... I do believe we've got the problem with the CoverArt 404 Not Found. I hovered the mouse over that link and it showed ".../Subsonic/coverArtSettings.view?"

Well, I looked in the $SUBSONIC/WEB-INF/jsp folder and there is no such file. But I looked back at the 4.1 SS and indeed, there is a "coverArtSettings,jsp" file!

So, Sindre, if you're reading this thread -- looks like the packaged 4.4 WAR file is missing that coverArtSettings.jsp file. I tossed the one from 4.1 into the 4.4 folder, and sure enough that resolved the 404 Not Found issue.

So... one down and one to go -- CoverArt fixed, but Search still a no-go re: the "Invalid property 'offset' of bean class" error. Really appreciate this help, guys...

Supra92

Correction to above. The coverArtSettings.jsp file is indeed missing from the 4.4 WAR archive, but.... moving the 4.1 file over (and ensuring proper owner/group/permissions) does NOT resolve. It still results in:

Code: Select all

HTTP Status 404 -

type Status report

message

description The requested resource () is not available.
Apache Tomcat/6.0.29

Restarting Tomcat6 each time in full for good measure -- why it's not seeing the coverArtSettings.jsp file I copied in there, is strange.

Supra92

Alright you have me completely confused, where exactly is this link you are looking at. None of the ones I see reference coverArtSettings.jsp at all (because that file doesnt exist), there are two jsp files
/srv/tomcat6/webapps/subsonic/WEB-INF/jsp/changeCoverArt.jsp
/srv/tomcat6/webapps/subsonic/WEB-INF/jsp/coverArt.jsp

Where exactly is the link you are referencing, can you post a screen shot of where it is?


Also why are you manually deploying the war file and not letting tomcat deploy the war file for yourself. If you are modifying files within the war then you should really be creating your own war file. Do you have mvn installed, can you simply build your own war... you will see that the jsp file you are looking for doesnt exist in the project at all.

Here's the 4.4 subsonic-main code from the svn repository doing a search jsp files with over in the name.

Code: Select all

:~/subSrc4.4/subsonic-main> find ./ -name "*over*.jsp"
./src/main/webapp/WEB-INF/jsp/changeCoverArt.jsp
./src/main/webapp/WEB-INF/jsp/coverArt.jsp
./target/subsonic/WEB-INF/jsp/changeCoverArt.jsp
./target/subsonic/WEB-INF/jsp/coverArt.jsp


Looking at the tags in the repo it appears that the jsp you are referencing hasnt existed since 4.1... which also explains why you are unable to use any newer versions properly. So there are still remnants of a previous version on your server.... can you try what I mentioned before, except this rather than manually deploying the war file let tomcat automatically deploy it when it comes online. There is no reason to restart your system, just do an: /etc/init.d/tomcat stop
Then clean up your webapps directory, and I would suggest deleting /var/subsonic/db/subsonic.lck to avoid other potential issues if it exists, and then do: /etc/init.d/tomcat start

Absolutely... here ya go:



Note, too, that hovering over the other menu choices near "Cover Art" correctly show FireFox pointing to the other .jsp files that do exist as well.

Now, clicking that Cover Art link results in this:



And that's what makes no sense. However in 4.1, that coverArtSettings.jsp file does exist --- if it was removed in 4.4, then it seems illogical that the Cover Art link up top would still point to it.

Lastly, here's the Search box failure:




As for the WAR deployment, definitely not manually deploying. The way I'm deploying is downloading the latest war zip file from SS site, unzipping it in my home directory, and then copying the .WAR file into $SUBSONIC_HOME/webapps. When I do a "service tomcat6 start", Tomcat automatically deploys that WAR file and creates the "subsonic" directory and subdirs. That's how I deployed the 4.4 version of the screenshots above.

The system reboot was purely a one-off, first time I'd done it. Generally (as with most things Linux) a simple service restart will suffice (service foo restart, for sysV flavours).

As for the cleanup -- all old versions of Subsonic are completely gone from $SUBSONIC_HOME. I have not yet, however, touched anything in /var/subsonic --- but I will give that a shot now, particularly the "subsonic.lck" suggestion you just made.

Question, however: when you hover over the "Cover Art" link in that upper menu under Settings.... what does your browser show as the destination URL, for 4.4? is it "coverArt.jsp"?

OK, more digging. And definitely agreeing now that somehow an old version of SS is sticking around. Reason: it's not that the "Cover Art" link is pointing to a nonexistent or wrongly-named file.... it's that the link itself apparently shouldn't even be there in 4.4.

Here's the first two lines of the ../jsp/settingsHeader.jsp file, for 4.1:

Code: Select all

<c:set var="categories" value="${param.restricted ? 'personal password player' : 'musicFolder general advanced personal user player network transcoding internetRadio podcast search coverArt'}"/>

But now here's those same two lines from the ../jsp/settingsHeader.jsp file, for 4.4:

Code: Select all

<c:set var="categories" value="${param.restricted ? 'personal password player' : 'musicFolder general advanced personal user player network transcoding internetRadio podcast search'}"/>

So somehow, even after I've wiped out all earlier versions, the 4.4 install still shows "Cover Art" as the final link under Settings, when according that settingsHeader.jsp file that link shouldn't even exist...