Hi,

I have apparently a problem for some weeks now. YACReaderLibraryServer works fine, I can access my comics from iOS and I can view any comics indexed in the library locally under Ubuntu using YACReader.

But when I request the update of the library, the process runs for about 10minutes, completes "correctly" but the new comics are not added. I have run the process in console to increase the log level to debug. I keep geting the same 2 lines:
! _7z.c:191: 7z support requires 7z SDK (define HAVE_7Z)
- zip.c:104: Skipping directory entry "Les Tuniques Bleues - T65 - LEnvoye special/"
but I do not think it is a problem (I have read selmf remark on 7z and none of my zips are 7z)
At the end, I have:
Processing comics...................................................................................................................................................................................................................................................................................................................................................................................................Done!
Number of comics processed = 387
Which tends to confirm that the process works.
I have new covers in the covers directory
But the library.ydb is untouched since January 31st and the probably 387 new comics I have added since that date are not present in the library. Anyway, if I run the update-library again, it reruns again the 387 comics.

As mentioned in previous posts, I am a bit of a heavy user with somethings like 11000 comics so I wonder if I do not hit some form of size limit or something got updated in my Linux on January 31st blocking the process.

Unfortunately even with --loglevel at trace, I do not get any additional message in the console

Thanks in advance for any help

Regards
STephane

Could you pack a few images in a zip file and add it to the library, then update, is the update process seeing and adding that file?

I have found a totally different explanation although it's a bit of a problem.

In fact on February 4th (and not exactly on January 31st but same consequence), I have changed my setting for NAS mounting with samba. I upgraded from Version 1 to Version 3. For some reason, it interferes very specifically with the writing of the SQLite file.

For test I had removed 100% of the comics and started fresh from on directory with 5 comics.
I was still taking an error like when I tried to recreate the library after removing 2000 comics to go back bellow 10000
- If that directory is on a normal directory (local mounted disk) it works just fine
- If that directory is on a smb mounted NAS file with version3 activated it fails
- If I revert the settings of the smb mounted NAS file with version 1 then it works again
Now what is very strange is that this new way of mounting the directory does not interfere whatsoever with the program. It is not a problem of authorisation has the covers are created just fine but for some reasons, it prevents specifically the wrting of the SQLite library

If you have any insight on the reason, I'd be happy to know because I do not want to revert my samba settings back to version 1

Regards
STephane

By the way, known issue of sqlite failing over cifs
Any chance there is a way to specify the location of the db away from the directory where the comics are?

Bug fully validated in that I've reverted to Samba Version 1 and rebuilt the entire library with the 11617 comics without any problem.

For the time being I'll switch to v1 when I update the library and revert to v3 rest of the time.

Did you try this? www.yacreader.com/forum/support-linux/64...he-library-cifs#2957

Samba and sqlite is a troublesome combination. The core issue is that sqlite relies on the filesystems capabilities to lock the database files against writes from another process and that this mechanism is often not working correctly with network file systems. The common workaround is to disable file locking via mount options.

If it used to work before, you should file a regression bug with the samba project.

We have discussed some measures like allowing different storage locations for the library and maybe implementing some diagnostics to see if a directory is correctly working with sqlite and file locking, but as this is a rather obscure (albeit somewhat common) bug this gets pushed back in our work log.

We can't do anything about the samba problems, but if you want you can open a bug on our github page so we can keep track of the problem and implement some diagnostics next time we work on the library backend.