Subsonic Forum

Greetings,

I have NEVER had any issue with cover art before in previous versions --- OK, occasionally a Linux dir will have the wrong permissions, but that gets figured out quickly.

In 3.5b1 however, I can't even get Subsonic to SHOW any cover art (snared from Amazon, Allmusic, Discogs, etc.). In all previous versions, when i chose the "Change" link for an album's art, the proceeding Change Cover Art screen would automatically load 3, 4, sometimes as many as 8 or so images for me to choose from. That's not happening anymore.

Furthermore, even when i type in a direct URL to fetch, NOTHING happens at all. I also notice in my browser's bottom status bar that there's some sort of script error. I thought it was just IE, but i get the same problem in Firefox.

I checked subsonic logs and there's no entries at all on the subject. Tomcat is running as tomcat.

All the 1400 or so PREVIOUS album art images that i've set over the past 2 yrs or so under previous versions of Subsonic are still there --- but I can no longer change any of those either.

It's literally as if the Change Cover Art section of Subsonic is completely hosed --- I have no art from which to pick at all. Even manually clicking the "Search Amazon" and "Search Discogs" buttons do nothing.

Has anyone encountered this issue before? Frustrating, because I've succesfully used 3.0, 3.1, 3.3b, and 3.4 with no issues at all. Any ideas greatly appreciated...

Supra92

OK, now THIS is strange.

I rolled back to v3.3b --- and the whole thing blows up on me. Ouch. Subsonic wouldn't even come up right.

I rolled back to v3.4 ---- and wham, COVER ART works!!! I go to change Cover Art for a newly added album, and presto, all those images are automatically snagged on the net. So clearly, something about 3.5b1 is hosing the Change Cover Art function.

Now...... ALSO in my rollback to 3.4...... some of my user accounts don't work anymore INcluding my admin account. I had to log in as my own account.... thinking about it now tho, it's probably because rolling back to an earlier version resulted in a new default password for 'admin'. Heh. I bet that's it.

So.... why would Change Cover Art successfully retrieve album images off the web in 3.4, but not 3.5b1??

Supra92

I just upgraded to 3.5b and so far my cover art update appears to be working still....

After upgrading to 3.5.beta1 (build 561) I have exactly the same problem. I haven't rolled back to see if that fixes it, though.

It looks to me like some server-side processing has failed to take place, judging from the html my browser is being served when I attempt to change cover art:

Code: Select all

<!--[if lt IE 7.]>
<script defer type="text/javascript" src="script/pngfix.js"></script>
<![endif]-->
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<link rel="stylesheet" href="style/default.css" type="text/css"/>
<link rel="shortcut icon" href="/subsonic/icons/favicon.ico"/>
    <script type="text/javascript" src="/subsonic/dwr/interface/coverArtService.js"></script>
    <script type="text/javascript" src="/subsonic/dwr/engine.js"></script>
    <script type="text/javascript" src="/subsonic/dwr/util.js"></script>
    <script type="text/javascript" language="javascript">
        DWREngine.setErrorHandler(null);
        function getImages(service) {
            $("wait").style.display = "inline";
            $("images").style.display = "none";
            ...


Both Firefox and IE chokes on the $("wait"), and it looks like something that should have been processed server-side.

I'm running tomcat5.5. There are no errors in neither the tomcat nor subsonic log.

Richard

I had this problem as well with 3.5b1... cover art update as well as edit tags page stopped functioning. Probably other pages that used the following js files:

/subsonic/dwr/engine.js
/subsonic/dwr/util.js

My problem was I was trying to cache the .js files, which caused any pages dependent on them to break.

Possibly check and see if you can access these js files from your browser, and/or if they are being cached somehow (which will cause problems).

Thanks for your input, zeekay.

However, the files you mention are not cached by my browser(s).

But I did try to fetch the two js-files and that failed. Maybe that could be a clue? I googled the exception but there were no definitive cause or remedy.

Fetching this url:
http://myserver:8180/subsonic/dwr/engine.js
-gave this exception:

Code: Select all

Subsonic encountered an internal error. You can report this error in the Subsonic Forum. Please include the information below.

Exception   javax.xml.transform.TransformerFactoryConfigurationError
Message   Provider org.apache.xalan.processor.TransformerFactoryImpl not found
Java version   Sun Microsystems Inc. 1.6.0_03
Operating system   Linux 2.6.22-14-386
Server   Apache Tomcat/5.5
Memory   Used 24 of 39 MB
Stack trace   javax.xml.transform.TransformerFactoryConfigurationError: Provider org.apache.xalan.processor.TransformerFactoryImpl not found
   at javax.xml.transform.TransformerFactory.newInstance(TransformerFactory.java:119)
   at uk.ltd.getahead.dwr.convert.DOMConverter.(DOMConverter.java:157)
   at sun.reflect.GeneratedConstructorAccessor40.newInstance(Unknown Source)
   at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
   at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
   at java.lang.Class.newInstance0(Class.java:355)
   at java.lang.Class.newInstance(Class.java:308)
   at uk.ltd.getahead.dwr.impl.DefaultConverterManager.addConverterType(DefaultConverterManager.java:54)
   at uk.ltd.getahead.dwr.impl.DefaultConfiguration.loadConverter(DefaultConfiguration.java:165)
   at uk.ltd.getahead.dwr.impl.DefaultConfiguration.loadInits(DefaultConfiguration.java:119)
   at uk.ltd.getahead.dwr.impl.DefaultConfiguration.addConfig(DefaultConfiguration.java:86)
   at uk.ltd.getahead.dwr.impl.DefaultConfiguration.addConfig(DefaultConfiguration.java:66)
   at uk.ltd.getahead.dwr.AbstractDWRServlet.init(AbstractDWRServlet.java:110)
   at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1139)
   at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:791)
   at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:127)
   at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
   at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
   at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
   at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
   at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
   at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874)
   at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
   at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
   at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
   at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
   at java.lang.Thread.run(Thread.java:619)

My exception-trace above is still maybe useful, but I've resolved the problem for myself now.

According to this thread, http://forums.sun.com/thread.jspa?messageID=9591514, the file:/usr/share/tomcat5.5/common/endorsed/xml-apis.jar is causing this type of problem. A brute-force solution is to remove the file and restart tomcat. That solved the issue for me, at least.