cops
cops copied to clipboard
Issue with Calibre 5 ?
Hello,
Since I upgraded to Calibre 5, I cannot see anything on my cops install. Only a grey page.
I have 3 cops 1.1.3 installed with 3 associated calibre bdd. I noticed the problem on my main one.
I tried to look at the log of my server, I have this error now :
AH01071: Got error 'PHP message: PHP Fatal error: Uncaught Error: Call to a member function fetchColumn() on bool in /var/www/vhosts/ANONYM.COM/cops.ANONYM.COM/lib/Base.php:147 Stack trace: #0 /var/www/vhosts/ANONYM.COM/cops.ANONYM.COM/lib/Base.php(154): Base::executeQuerySingle() #1 /var/www/vhosts/ANONYM.COM/cops.ANONYM.COM/lib/Author.php(42): Base::getCountGeneric() #2 /var/www/vhosts/ANONYM.COM/cops.ANONYM.COM/lib/Page.php(110): Author::getCount() #3 /var/www/vhosts/ANONYM.COM/cops.ANONYM.COM/lib/JSON_renderer.php(198): Page->InitializeContent() #4 /var/www/vhosts/ANONYM.COM/cops.ANONYM.COM/getJSON.php(14): JSONRenderer::getJson() #5 {main} thrown in /var/www/vhosts/ANONYM.COM/cops.ANONYM.COM/lib/Base.php on line 147', referer: https://cops.ANONYM.COM/
I tried to open with the calibre 5 one of the other library, and now, I have the same problem on it. I never opened the third one with calibre 5, and cops is still working fine.
Tell me if you need something more from me ?
Thanks in advance for your help.
I have installed:
- cops 1.1.3 (on debian 10)
- calibre 5.2 (on debian 10)
- library made with calibre < 5
- library made with calibre 5.0
- library touched/acessed with calibre 5.2
and so far (touch wood) no problems when accessing from OSX Firefox.
Have you cleaned your (browser) cache?
Later this evening I will try with other clients.
Thanks for your test and help. In light of this comments, I did some more test.
I did not specify it before, but I moved my server on a plex instance. It was working so I did not change anything, but now, when trying some parameter, I tried to use the composer extension on the cops that where not working. It installed some extension I think called sauce/sausageprod.
After that, the error changed to :
AH01071: Got error 'PHP message: PHP Fatal error: Uncaught Error: Class 'Base' not found in /var/www/vhosts/ANONYMOUS.COM/cops-bd.ANONYMOUS.COM/index.php:19 Stack trace: #0 {main} thrown in /var/www/vhosts/ANONYMOUS.COM/cops-bd.ANONYMOUS.COM/index.php on line 19'
Then, I added a line in my config.php like that :
require_once dirname(__FILE__) . '/lib/Base.php';
It then changed anew to another error :
AH01071: Got error 'PHP message: PHP Fatal error: Uncaught Error: Class 'doT' not found in /var/www/vhosts/ANONYMOUS.COM/cops-bd.ANONYMOUS.COM/index.php:52 Stack trace: #0 {main} thrown in /var/www/vhosts/ANONYMOUS.COM/cops-bd.ANONYMOUS.COM/index.php on line 52'
So it seems to me that the lib part are not integrated anymore, but I don't know where and how they where before if it's really the problem.
I searched to see on my 3 install with grep :
root@plesk: ~# grep -R Base.php /var/www/vhosts/ANONYMOUS.COM/cops-sharleen.ANONYMOUS.COM/
/var/www/vhosts/ANONYMOUS.COM/cops-sharleen.ANONYMOUS.COM/vendor/composer/autoload_classmap.php: 'Base' => $baseDir . '/lib/Base.php',
/var/www/vhosts/ANONYMOUS.COM/cops-sharleen.ANONYMOUS.COM/vendor/composer/autoload_static.php: 'Base' => __DIR__ . '/../..' . '/lib/Base.php',
root@plesk: ~# grep -R Base.php /var/www/vhosts/ANONYMOUS.COM/cops-bd.ANONYMOUS.COM/
/var/www/vhosts/ANONYMOUS.COM/cops-bd.ANONYMOUS.COM/config.php:require_once dirname(__FILE__) . '/lib/Base.php';
root@plesk: ~# grep -R Base.phpgrep -R Base.php /var/www/vhosts/ANONYMOUS.COM/cops.ANONYMOUS.COM/
The -sharleen one is the one that still work. I see some loading of the lib in composer directory The -bd, I see only the one I added. The last one, it's the main one, I see nothing.
Finaly, I tried to copy the release anew from scratch in my -bd install. I was back on the first error, then after a new composer update, the second one.
Have you seen #477?
To install cops (and only cops, not the webserver) you can do 3 things:
- download the latest cops release: https://github.com/seblucas/cops/releases/download/1.1.3/cops-1.1.3.zip, then unzip and change config_local.php to your liking.
- install fron source. take care to install the right composer version #477 <2!
- copy a working cops install to a new server.
Okay, I tried to install anew as it was done in the issue you spoke of.
No luck. Still the same stack trace error :
AH01071: Got error 'PHP message: PHP Fatal error: Uncaught Error: Call to a member function fetchColumn() on bool in /var/www/vhosts/ANONYMOUS.COM/cops-bd.ANONYMOUS.COM/lib/Base.php:147
Stack trace:
#0 /var/www/vhosts/ANONYMOUS.COM/cops-bd.ANONYMOUS.COM/lib/Base.php(154): Base::executeQuerySingle()
#1 /var/www/vhosts/ANONYMOUS.COM/cops-bd.ANONYMOUS.COM/lib/Author.php(42): Base::getCountGeneric()
#2 /var/www/vhosts/ANONYMOUS.COM/cops-bd.ANONYMOUS.COM/lib/Page.php(110): Author::getCount()
#3 /var/www/vhosts/ANONYMOUS.COM/cops-bd.ANONYMOUS.COM/lib/JSON_renderer.php(198): Page->InitializeContent()
#4 /var/www/vhosts/ANONYMOUS.COM/cops-bd.ANONYMOUS.COM/getJSON.php(14): JSONRenderer::getJson()
#5 {main}
thrown in /var/www/vhosts/ANONYMOUS.COM/cops-bd.ANONYMOUS.COM/lib/Base.php on line 147', referer: https://cops-bd.ANONYMOUS.COM/
I also tried to copy the working install but as soon as I try to use the calibre -BD base, it don't work.
Finaly, I tried to specify the checkconfig.php directly. (I forgot this pages exist before) When I run it on the working install, it end with :
Check if Calibre database file contains at least some of the needed tables
OK
But when I run the script on the Calibre 5 database, it end with :
Check if Calibre database file contains at least some of the needed tables
Without the ok and the footer of the webpage.
I tried to check with only changing the path to my calibre folder into config_local.php. Each time I try to access the calibre 5 database, I have the same problem.
I join the metadata.db file of my -bd calibre. Maybe you will be able to reproduce the problem with it.
For me your metadata.db worked just fine.
I tried with php 7.3 and php 5.6 and no problems.
Can you check it is not just an access rights problem? (Chmod 777 metadata.db)
Important edit!!!
I can now reproduce your error if I use checkconfig.php.
The error is: Check if Calibre database file contains at least some of the needed tables
This is with PHP version (5.3.3-7+squeeze19). This probably means that the php-sqlite version is not compatible with Calibre5. The sqlite3 version (sqlite3 -version) = 3.7.3
If you can update the PHP version (preferably to 7.x)
Hello,
Sorry for the delay, I didn't see your edited message before.
I use PHP 7.4.11 not 5.3.X I looked at my phpinfo, I have sqlite 3.7.17 support in it.
I don't know how I can help you more (and me by extension ;-)
sqlite3 version 3.7.11 is from 2013-05-20!!! https://sqlite.org/changes.html
PHP 7.4.11 should have a much more modern version of sqlite3 Debian 10 (32 bits) has PHP version 7.3.19 with sqlite3 3.27.2 DEbian 9 (64 bits) has PHP version 7.0.33 with sqlite3 3.16.2
I'm pretty sure your problems are (for the most part) related to an outdated sqlite3 version.
Can you update the sqlite version on your system? (to at least version 3.9)
I don't know if I can. I have centos, it use backport so the version number don't fully reflect the function sometime. It also means I cannot use a simple apt update to have a new version.
I will try to look at what I can do still to try and update the sqlite version as a test at least
I thought "let's have some fun". so I installed CentOS 8 in virtualbox. It turned out to be not so much fun, but anyway in the end I got CentOS running with https (Apache) and PHP 7.4. (I hate firewalls when I do not need them)
Installing COPS was a breeze ;-) but then I found out it is not possible to install the calibre libraries in /home/useer with this version of PHP on CentOS 8. I got a metadata.db not found error. (symlinks to the /home directory dot not work either).
BeginEdit: I temporarily killed/disabled SeLinux [setenforce 0] and .... access to anything but /home!! Don't like Selinux! EndEdit
Just for testing I installed the calibre libraries in /var/www/html/cops.
And COPS worked fine as expected with calibre 3, 4 and 5 libraries.
The sqlite3 version is 3.26.0
Ok, I tried to change the sqlite version on my server. I managed to install sqlite 3.33.0, but only as a CLI thing...
For PHP, it use it's own pdo_sqlite driver that is still 3.7.11 and for now, I did not manage to change it as I don't want to break anything else on the server.
With everything I already tried, I seems to already have destroyed some configuration, as the pdosqlite don't appears anymore in my phpinfo for cops and the checkconfig.php tell me it won't work without it now.
I also looked to upgraded my centos 7 to centos 8 as you said it seems better. But plesk, that I use to manage the server, don't provide an upgrade path for now.
If I have some more time, I will maybe continue to look at that and also keep you posted if I found something new.
I will just have to use Calibre only for the time being. I can live with that.
Thanks a lot for your help and all the testing you did.
I installed CentOS 7 in virtual box with http and php 7.4.
I can confirm that php-sqlite is version 3.7.17! And also the problems with Calibre 5 libraries.
Haven't found an easy way to "upgrade" php-sqlite, so did not try (yet).
Some sources say that installing PHP 7.3 should fix the too low sqlite version. I might try downgrading or reinstalling later this week.
Edit: Installed CentOS 7 with PHP 7.3 in virtualbox: still the same shitty version of php-sqlite3. Installing CentOS 8 seems the way to go for Calibre & COPS (but then Plesk does not work). Downgrading Calibre to version 4 is the only workable solution for centOS 7 & COPS for now........... :-(
I have been playing with this issue with my "old" QNAP NAS, which is running COPS for a while now and also failed when upgrading to Calibre 5. The issue is that the new DB design has 4 extra tables "annotations_fts_*" and they have "WITHOUT ROWID" In their TABLE CREATE statement, which isn't supported by the "older" sqlite versions. ( believe <3.8.2). I have been able to create a workaround/hack in de "lib\Base.php" file which will:
- Create a new metadata.dbv4 based on the specified metadata.db when not existing or when the metadata.db is newer:
- Dump the v5 db with: exec('/opt/bin/sqlite3 '.$dbfilename.' -cmd ".output /tmp/metadatav5.sql" .dump')
- Remove old v4 db;
- Create new v4 db with: exec('/opt/bin/sqlite3 '.$dbfilenamev4.' < /tmp/metadatav5.sql')
- Set COPS to use the v4 version of the database
This seems to be working fine and I am back in business. Above changes are done in "public static function getDb ($database = NULL)" and are shown below.
Cheers, Jos EDIT: Update below code: Added fields to define the sqlite3 program and temp dumpfile and to debug when having issue. To debug you can open url: getJSON.php?complete=1
public static function getDb ($database = NULL) {
// Define to show extra output info when opening url for testing the below:
// getJSON.php?complete=1
$debug = false;
//=== Define sqlite3 program and dumpfile
//--- used with QNAP NAS ---
$sqlite3pgm = '/opt/bin/sqlite3';
$dumpfile = '/tmp/metadatav5.sql';
//--- used with Win10 testing ---
//$sqlite3pgm = "\"C:/Program Files (x86)/SQLite ODBC Driver/sqlite3.exe\"";
//$dumpfile = 'd:/temp/metadatav5.sql';
if (is_null (self::$db)) {
try {
// define v5 and v4 database names
$dbfilename = self::getDbFileName ($database);
$dbfilenamev4 = $dbfilename.'v4';
// Get Modification DateTime for both
$mod_date = filemtime($dbfilename);
if (file_exists($dbfilenamev4)) {
$mod_datev4 = filemtime($dbfilenamev4);
} else {
$mod_datev4 = 0;
}
if ($debug) echo("v4:$dbfilenamev4 - $mod_datev4\n");
if ($debug) echo("v5:$dbfilename --- $mod_date \n");
// regenerate v4 db when v5 db was updated
if ($mod_datev4 < $mod_date) {
//***dump current v5 db
exec($sqlite3pgm.' '.$dbfilename.' .dump >'.$dumpfile , $out, $retval);
if ($debug) {
echo("Dump $dbfilename \n");
echo($sqlite3pgm.' '.$dbfilename.' .dump >'.$dumpfile);
var_dump($retval);
print_r($out);
}
//***remove current v4 db
exec('rm -f '.$dbfilenamev4, $out, $retval);
if ($debug) {
echo("remove v4 db \n");
var_dump($retval);
print_r($out);
}
//***Import dump from v5 db which will remove the: near "without": syntax error
exec($sqlite3pgm.' '.$dbfilenamev4.' < '.$dumpfile, $out, $retval);
if ($debug) {
echo("Create $dbfilenamev4 \n");
var_dump($retval);
print_r($out);
}
}
if (is_readable ($dbfilename)) {
self::$db = new PDO('sqlite:'. $dbfilenamev4);
if (useNormAndUp ()) {
self::$db->sqliteCreateFunction ('normAndUp', 'normAndUp', 1);
}
} else {
self::error ($database);
}
} catch (Exception $e) {
self::error ($database);
}
}
return self::$db;
}
As discussed in a similar BicBucStriim issue this problem is most probably caused by the "USING fts5" option for the two new tables "annotations_fts" and "annotations_fts_stemmed". I've had the same problems as described here and solved it by deleting those two tables from the Database with the tool db browser. For further information take a look at https://github.com/rvolz/BicBucStriim/issues/343.
As discussed in a similar BicBucStriim issue this problem is most probably caused by the "USING fts5" option for the two new tables "annotations_fts" and "annotations_fts_stemmed".
Correct and is the same as I stated in my post above. ;)
The issue is that the new DB design has 4 extra tables "annotations_fts_*" and they have "WITHOUT ROWID" In their TABLE CREATE statement, which isn't supported by the "older" sqlite versions. ( believe <3.8.2).
I simply didn't want to delete stuff in the original Calibrev5 database, so opted to dump the database and import it again into a new version each time the original changes, and use that for the COPS setup. This import will give some errors for those 4 extra "annotations_fts_*" tables , so they are simply skips by this import process, which is essentially the same result with leaving the original Calibrev5 db intact.
I tried several different way that is supported by the old version of sqlite3 to make an automated fix and this is the only one that worked for me. Also trying to delete those tables from the database design table "sqlite_master" gave the error:
General error: 11 malformed database schema (annotations_fts_stemmed_config) - near "WITHOUT": syntax error
The overhead is only a few seconds when the original DB(s) are changed, so I am not worried about that.
@jvanderzande
Nice fix, however it does not work for me :(
line:
exec($sqlite3pgm.' '.$dbfilename.' -cmd ".output '.$dumpfile.'" .dump', $out, $retval);
gives me an error:
/usr/bin/sqlite3: Error: too many options: ".output $dumpfile"
(sqlite is in /usr/bin/ in Debian)
Even if I do all on the command line I get an error if importing from $dumpfile.
Lucky for me is that my very old Synology on DSM 5.2 has PHP 5.5, so Calibre 5 libraries still work. The only device where is does not work is really EOL with PHP 5.3.
@marioscube,
I do not have COPS installed on a raspberry Debian setup, but tried the following from the Rapberry commandline in a test directory which is working fine and dumping the database:
/usr/bin/sqlite3 metadata.db -cmd ".output ./test.dump" .dump
Have you tried in manually to see what it tells you exactly as you state the dump is working ?
This is what I get:
pi@testpi ~ $ cd test/
pi@testpi ~/test $ /usr/bin/sqlite3 metadata.db -cmd ".output ./test.dump" .dump
pi@testpi ~/test $ ls -l
total 9716
-rwxrw-rw- 1 root root 5505024 Nov 5 18:31 metadata.db
-rw-r--r-- 1 pi pi 4443058 Nov 9 16:52 test.dump
pi@testpi ~/test $ /usr/bin/sqlite3 metadatav4.db <test.dump
Error: near line 28445: no such function: sortconcat
Error: near line 28476: no such function: books_list_filter
Error: near line 28488: no such function: books_list_filter
Error: near line 28500: no such function: books_list_filter
Error: near line 28512: no such function: books_list_filter
Error: near line 28524: no such function: books_list_filter
Error: near line 28556: no such function: title_sort
Error: near line 28883: no such function: books_list_filter
pi@testpi ~/test $ ls -l
total 14400
-rwxrw-rw- 1 root root 5505024 Nov 5 18:31 metadata.db
-rw-r--r-- 1 pi pi 4794368 Nov 9 17:04 metadatav4.db
-rw-r--r-- 1 pi pi 4443058 Nov 9 16:52 test.dump
pi@testpi ~/test $
@jvanderzande On a Tonidoplug2 with Debian Squeeze and php 5.3:
root@TonidoPlug2:/var/www/tmp# sqlite3 -version
3.7.3
root@TonidoPlug2:/var/www/tmp#
root@TonidoPlug2:/var/www/tmp# sqlite3 metadata.db -cmd ".output ./test.dump" .dump
sqlite3: Error: too many options: ".output ./test.dump"
Use -help for a list of options.
root@TonidoPlug2:/var/www/tmp#
root@TonidoPlug2:/var/www/tmp# sqlite3 metadata.db
SQLite version 3.7.3
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .output test.dump
sqlite> .dump
sqlite> .exit
root@TonidoPlug2:/var/www/tmp#
root@TonidoPlug2:/var/www/tmp# ls -l
total 588
-rwxrw-rw- 1 root root 479232 Oct 19 13:36 metadata.db
-rw-r--r-- 1 root root 113156 Nov 9 19:21 test.dump
root@TonidoPlug2:/var/www/tmp#
root@TonidoPlug2:/var/www/tmp# sqlite3 metadatav4.db < test.dump
Error: near line 1159: near "WITHOUT": syntax error
Error: near line 1161: near "WITHOUT": syntax error
Error: near line 1167: near "WITHOUT": syntax error
Error: near line 1169: near "WITHOUT": syntax error
Error: near line 1172: no such function: sortconcat
Error: near line 1203: no such function: books_list_filter
Error: near line 1215: no such function: books_list_filter
Error: near line 1227: no such function: books_list_filter
Error: near line 1239: no such function: books_list_filter
Error: near line 1251: no such function: books_list_filter
Error: near line 1283: no such function: title_sort
root@TonidoPlug2:/var/www/tmp#
root@TonidoPlug2:/var/www/tmp# ls -l
total 788
-rwxrw-rw- 1 root root 479232 Oct 19 13:36 metadata.db
-rw-r--r-- 1 root root 200704 Nov 9 19:21 metadatav4.db
-rw-r--r-- 1 root root 113156 Nov 9 19:21 test.dump
if I remove the line exec($sqlite3pgm.' '.$dbfilename.' -cmd ".output '.$dumpfile.'" .dump', $out, $retval);
in your code and then copy/rename the created files to the right place in cops and the calibre database it works.
On my very old synology with php 5.5where I do not need your code fro calibre v5 libraries to work:
DiskStation> sqlite3 -version
3.8.10.2 2015-05-20 18:17:19 2ef4f3a5b1d1d0c4338f8243d40a2452cc1f7fe4
DiskStation>
DiskStation> sqlite3 metadata.db -cmd ".output ./test.dump" .dump
DiskStation>
DiskStation> ls -l
-rwxrwxrwx 1 syno users 479232 Oct 19 13:36 metadata.db
-rw-r--r-- 1 root root 113280 Nov 9 19:33 test.dump
DiskStation>
DiskStation> sqlite3 metadatav4.db < test.dump
Error: near line 1174: no such function: sortconcat
Error: near line 1205: no such function: books_list_filter
Error: near line 1217: no such function: books_list_filter
Error: near line 1229: no such function: books_list_filter
Error: near line 1241: no such function: books_list_filter
Error: near line 1253: no such function: books_list_filter
Error: near line 1285: no such function: title_sort
DiskStation>
DiskStation> ls -l
-rwxrwxrwx 1 syno users 479232 Oct 19 13:36 metadata.db
-rw-r--r-- 1 root root 204800 Nov 9 19:33 metadatav4.db
-rw-r--r-- 1 root root 113280 Nov 9 19:33 test.dump
As you can see, the only difference is the sqlite3 version. With version 3.7.3 it does not work, with version 3.8.10 it does.
What version of sqlite3 do you use?
Test Debian has sqlite3 v 3.8.7.1 (2014-10-29) and also works. Guess we need to figure out how to multiple "."commands on a single line to make it work for all. Just for test: Does this give the same error?: sqlite3 metadata.db -cmd ".output test.dump" .dump Or else maybe this works for you: sqlite3 metadata.db .dump > ./test.dump
That last one seems to work fine for me too and looks like the best candidate. :)
sqlite3 metadata.db .dump > ./test.dump
Works! Thank you.
However, I use cops with multiple libraries (I get a database error in checkconfig.php).
Makes sense as that separate php files gets the original db name (metadata.db) from this function , which provides the original name and then tries to do an sqlite call on it:
public static function getDbFileName ($database = NULL) {
return self::getDbDirectory ($database) .'metadata.db';
}
Do you want to work towards an complete fix or making it backwards-compatible, as that was not my approach and simply wanted to fix my setup? ;)
No need for me.
I had not used that device in months, and then only for testing.
It’s more that I like to know how things work or not work and how to fix it.
I'll have look to add some of the hardcode variables to the localconfig and move the copy part of the code to the getDbFileName function so it can be configured whether you want to use this fix or not. ...stay tuned..
I've made a fork of the Branch and just committed a change which makes this fix configurable: https://github.com/jvanderzande/cops/commit/9abeffa462b3c72984931ac3e44300931f387767 This fix also supports the /checkconfig.php page and has these added options in config_local.php to make it all easy configurable:
// --------------------------------------------------------------------------------
// -- Fix for incompatibility older sqlite3 & Calibre v5 database format
// true will create metadata.dbv4 and use that copy
$config['sqlite_fix'] = true;
$config['dumpfile'] = '/tmp/metadata.dump';
$config['sqlite3pgm'] = '/opt/bin/sqlite3';
// leave this false unless debugging is required with url /getJSON.php?complete=1
$config['sqlite_fix_debug'] = false;
// --------------------------------------------------------------------------------
Have a play with those changes and I can make a pull request in case you want to add it to your branch.
NIce addition!
It now runs out of the box with the unsupported sqlite3.
Let me know in case you want a pull request. I do think the default should change to:
$config['sqlite_fix'] = false;
I run COPS on a couple of Centos servers, one v7 and v8. As noted by Althor84, when I upgraded my local version of Calibre to 5.6, and copied the dataset out to the servers, COPS stopped working on Centos 7 but not on Centos 8. The issue is indeed the old sqlite3.7.17 whereas Centos 8 runs sqlite3.26.0. You can test which versions of sqlite3 will open the Calibre 5.x database from the command line with:
sqlite3.x.x /path/to/metadata.db then: sqlite> .tables
This will list out the tables if it can open the db but zilch if it cannot.
As marioscube notes, there is not an obvious Centos supported upgrade for the sqlite3 component. It seems to play a central role in the management of the OS and is tightly integrated. If you just drop a different version of sqlite3 into /usr/bin then "bad things may happen".
However, I did find a post in a Reddit discussion from a user who had similar problems with Ruby on Rails who gave instructions for using a fedora packages from the Fedora Project. Namely:
wget https://kojipkgs.fedoraproject.org//packages/sqlite/3.8.11/1.fc21/x86_64/sqlite-devel-3.8.11-1.fc21.x86_64.rpm wget https://kojipkgs.fedoraproject.org//packages/sqlite/3.8.11/1.fc21/x86_64/sqlite-3.8.11-1.fc21.x86_64.rpm sudo yum install sqlite-3.8.11-1.fc21.x86_64.rpm sqlite-devel-3.8.11-1.fc21.x86_64.rpm
check the sqlite3 version with: sqlite3 --version.
I tried this out in a VM of Centos 7. It seemed to work fine with no complaints. The sqlite3 version checked out as as 3.8.11. Running info.php on the local Apache server (PHP was 7.4.14) gave a pdo_sqlite = 3.8.11 as well as sqlite3 = 3.8.11. COPS now works fine on the 5.6 database. The server itself appears to be running normally, updates are processed as you might expect. I had initially thought that PHP would pick up its sqlite from its extension module but that does not seem to be the case.
There may be other rpm packages which incorporate later versions of sqlite3 but v3.8.11 seems to work with the new Calibre db.
I have the same issue here with an older QNAP TS-212p NAS. Deleting the "annotations_fts" and "annotations_fts_stemmed" tables worked, but not for long, as calibre rebuilded the database during next run. I tried the fork made by jvanderzande but this doesnt work. I´am not able to change php or sqlite Versions on my NAS. Any change to get it running again? checkconfig result:
Check if PHP version is correct OK (5.6.40) Check if GD is properly installed and loaded OK Check if Sqlite is properly installed and loaded OK Check if libxml is properly installed and loaded OK Check if Json is properly installed and loaded OK Check if mbstring is properly installed and loaded OK Check if intl is properly installed and loaded Please install the php5-intl / php7.0-intl extension and make sure it's enabled Check if Normalizer class is properly installed and loaded Please make sure intl is enabled in your php.ini Check if the rendering will be done on client side or server side Client side rendering Check if Calibre database path is not an URL OK Check if Calibre database file exists and is readable OK Check if Calibre database file can be opened with PHP OK Check if Calibre database file contains at least some of the needed tables
@hannesausmwald Your COPS checkconfig shows that your php doesn't have the intl module installed. It will still balk at running if there are errors shown here. If you can access and run the info.php file on your system and it shows that php is accessing the older sqlite3 then it won't run with the version 5 unmodified Calibre db tables. I haven't tried any of the other modifications noted here as I could upgrade the sqlite3. I am actually in the process of moving my servers from Centos to Ubuntu given the sudden cessation of support for Centos8 and the move to Centos Stream. If none of the potential fixes noted here don't work your only real solution is to reinstall Calibre 4.x
@hannesausmwald Your COPS checkconfig shows that your php doesn't have the intl module installed. It will still balk at running if there are errors shown here. If you can access and run the info.php file on your system and it shows that php is accessing the older sqlite3 then it won't run with the version 5 unmodified Calibre db tables. I haven't tried any of the other modifications noted here as I could upgrade the sqlite3. I am actually in the process of moving my servers from Centos to Ubuntu given the sudden cessation of support for Centos8 and the move to Centos Stream. If none of the potential fixes noted here don't work your only real solution is to reinstall Calibre 4.x
@GG-Doc-Smith my info.php is getting the following:
SQLite3 support | enabled |
---|---|
SQLite3 module version | 0.7-dev |
SQLite Library | 3.8.10.2 |
@hannesausmwald My version of PHP is 7.4.15 running under Apache2
info.php would seem to be giving slightly different output in my system compared to yours. For the pdo_sqlite entry the SQLite library is 3.8.11 For the sqlite3 entry the SQLite library is 3.8.11 There is a pointer to the PHP extension_dir of /usr/lib64/php/moudules (this would include the sqlite3 module although the evidence in my system indicates that PHP isn't using it.
Your SQLite Library is marginally early than mine although in the sqlite3 release history (https://sqlite.org/changes.html) there would appear to be no functional differences in the releases. You can check (if you haven't done so already) the release version and date of release from the terminal with: sqlite3 --version
I have no specific entry for a [SQLite3 module version] but if it is 0.7-dev on your system and that is what PHP is using then it won't work.
I would still address the issue with the "intl" module that is shown in the Calibre config before you lay the blame on the version of sqlite3. If you have had COPS working previously something you have done would seem to have caused it to become uninstalled.