I noticed recently that the content server isn't working correctly; I think this started coincident with the new version I installed.
When I connect with Calibre Companion, I'm not able to retrieve any of the list of books.
Looking at the Error log: inside of the preferences panel, I see this:
Quote:
[11/Sep/2016:00:02:03] HTTP Traceback (most recent call last):
File "site-packages/cherrypy/_cprequest.py", line 656, in respond
File "site-packages/cherrypy/lib/encoding.py", line 188, in __call__
File "site-packages/cherrypy/_cpdispatch.py", line 34, in __call__
File "site-packages/calibre/library/server/utils.py", line 54, in do
File "site-packages/calibre/library/server/opds.py", line 488, in opds_navcatalog
File "site-packages/calibre/library/server/opds.py", line 423, in get_opds_all_books
File "site-packages/calibre/library/server/opds.py", line 389, in get_opds_acquisition_feed
File "site-packages/calibre/library/server/opds.py", line 326, in __init__
File "site-packages/calibre/library/server/opds.py", line 209, in ACQUISITION_ENTRY
UnboundLocalError: local variable 'mi' referenced before assignment
|
which appears suspicious.. Taking a quick look inside the application wrapper didn't reveal anything specific due to the compiled python files vs. source code.
I tried applying the pending OSX update from 10.11.5 to 10.11.6 to see if that (or a reboot) might help, but it doesn't appear to.
This seems specific to using Calibre Companion... in the Access Log, I see:
Quote:
10.200.253.24 - - [11/Sep/2016:00:01:55] "GET / HTTP/1.1" 200 6461 "" "Apache-HttpClient/UNAVAILABLE (java 1.5)"
10.200.253.24 - - [11/Sep/2016:00:01:55] "GET /opds HTTP/1.1" 200 3715 "" "Apache-HttpClient/UNAVAILABLE (java 1.5)"
10.200.253.24 - - [11/Sep/2016:00:02:03] "GET /opds/navcatalog/4f6e6577657374 HTTP/1.1" 500 805 "" "Apache-HttpClient/UNAVAILABLE (java 1.5)"
|
Now, I'm not sure if there is an issue with Calibre Companion making unwarranted assumptions, but I think that the cherrypi web server shouldn't be throwing an error like the one in the log when handed a bogus URL..
Just pointing a web browser to the content server directly seems to yield the expected result.