/hydrus/ - Hydrus Network

Hey, I am sorry about this. I happened to run into my own boot problems this week and improved the emergency shutdown code so this sort of error should shut down the client properly in future.

That error is saying that when your client tried to initialise a new database (and specifically the very first line it attempts to do so), it encountered a problem reading from your hard drive.

I am not sure why it would throw this error. It could be because your hard drive is having a problem and is literally unable to deliver data in the way my db library wants, or you might be operating from an unusual RAID scenario or over-the-network hdd connection that might not provide everything the db needs, or it might be a permissions issue (although running as admin would probably overrule that). Maybe your installation directory is somehow read only? Putting hydrus in a protected location like 'program files' can also cause problems, because it wants to write to its own directory. Still, running as admin should have worked in that case.

Maybe you have a very aggressive defragger that put some sort of lock on the db file as soon as it was created, or maybe some anti-virus?

If you open install_dir/db in explorer, is there a file called 'client.db'? Does it have size 0KB? Is there a client.db-wal or client.db-journal?

If you double-click sqlite3.exe in that same directory and type the following:

.open client.db

SELECT * FROM sqlite_master;

.exit

Does it throw a new error, maybe with more information? There are a whole bunch of sub-error codes here–

https://sqlite.org/rescode.html#extrc

–that a Disk I/O error can have, but I don't think I can access exactly which from inside the client.

That SELECT line is essentially what is throwing the error inside the client. It shouldn't return anything because there isn't anything in your db yet.

Now I look at the list of sub-errors, perhaps your hard drive doesn't want to do WAL journaling. If the previous test ran ok, please run sqlite3.exe again and do this:

.open client.db

PRAGMA journal_mode = WAL;

SELECT * FROM sqlite_master;

.exit

Please let me know how you get on.

>>1763

I had hoped sqlite3.exe would give more information naturally. I can't see a way in its help docs to specifically give verbose recent error information.

The problem on my end is that I am accessing sqlite through a python wrapper that doesn't seem to give me access to the underlying C call that would give the extended error code. That bit of 'disk I/O error' text is the only message I get.

You could try:

.open client.db

.dbinfo

.exit

If I do that on a garbage file, it gives me a different bit of error text than if I try a SELECT statement.

If you substitute 'client.db' for any other filename, sqlite3 will create a new db file at that location, which should start with size 0KB. If you do those original two tests again, but for say '.open test', what happens then?

And if you delete the three 'client.db' files and try to run the client again, do you get the same problem?

If it repeats, you might try SQLiteStudio, which you can get here:

http://sqlitestudio.pl/

Trying to open a broken client.db in that might give a better error since surely plugs into the C code and has a good gui. Although my test garbage file just gives a generic 'could not connect to that db'.

I have updated to the latest sqlite.dll and sqlite3.exe for the Windows release I will put out later today, so you may wish to try this again in that, just in case some bug on their end has been fixed.

>>1766

On client.db, dbinfo works and returns the following:

database page size:  1024
write format:        2
read format:         2
reserved bytes:      0
file change counter: 1
database page count: 1
freelist page count: 0
schema cookie:       0
schema format:       0
default cache size:  0
autovacuum top root: 0
incremental vacuum:  0
text encoding:       0
user version:        0
application id:      0
software version:    3009002
number of tables:    0
number of indexes:   0
number of triggers:  0
number of views:     0
schema size:         0

Creating a new database, SELECT returns nothing, and dbinfo returns simply

unable to read database header

Deleting all the files and trying again from scratch produces the same result.

As for SQLite Studio, it can't even open the file, and I can't seem to get it to produce any kind of meaningful error message in either the GUI or the CLI. Sorry, I know that's not very helpful, but it's about all I can tell you.

I'll wait and try again with a clean install of the new version, and let you know if the problem persists.

>>1769

If a new db returns nothing on the SELECT call rather than raising a disk i/o error, then I suspect there is a problem with WAL journalling. WAL needs some clever shared memory call from the OS to maintain that client.db-shm, and perhaps that is a problem for your motherboard/OS or something.

I've written a little test in hydrus's db init that'll try to read from the db in WAL, and if that fails, it'll fallback to the simpler TRUNCATE. v190 may magically work for you, or the problem might be something completely different.

>>1770

Well, fuck.

With v190, the exact same thing happened on first launch, except the traceback ended with:

File "C:\code\Hydrus\include\HydrusDB.py", line 135, in _InitDB
File "C:\code\Hydrus\include\HydrusDB.py", line 170, in _InitDBCursor

Although the second time (and subsequent times), it was

File "C:\code\Hydrus\include\HydrusDB.py", line 135, in _InitDB
File "C:\code\Hydrus\include\HydrusDB.py", line 158, in _InitDBCursor

On the bright side, the alerts pop up in the right order and the program terminates properly now. (Not to sound sarcastic; I'm glad you're working so hard on this project.)

>>1775

Well, we are changing things at least! I think we are onto something. It might not be WAL at all, or it might be it can switch WAL on, but once it does, it can't do anything, including switching it off.

I discovered that we may get better error information if we do '.log stdout', so please open up sqlite3 again and try:

.open new_filename

.log stdout

SELECT * FROM sqlite_master;

PRAGMA integrity_check;

PRAGMA journal_mode = WAL;

SELECT * FROM sqlite_master;

PRAGMA integrity_check;

.exit

Apparently you'll get a better error code like '(522) error details'. If you do this, do the first SELECT/PRAGMA calls cause any errors?

>>1781

Oh man.

Looking at the error codes, it seems the disk was marked as 'dirty'. I have no idea how or when that happened, and it hadn't affected anything else, but that was almost certainly the problem.

Unfortunately, I tried to get a little too cheeky while fixing that, and in doing so royally fucked up the disk. So now I'm in the process of recovering it, which should be no problem, but will take quite a while.

I'll let you know in a day or two whether it was purely my retardation, or if a problem still persists. Thanks for your patience. orz

>>1784

That sucks. Take your time getting back to this–I hope you can recover anything you lost!

>>1789

Well whadda ya know, it works!

Sorry for wasting your time. The only reason I tried so hard to install Hydrus in the first place is because it's exactly what I need, so thanks for all you've done.

>>1805

Great! I am glad you got it fixed. Don't think of it as wasted time, either–I learned a whole bunch about sqlite error reporting!

Let me know if anything else breaks, or if, after a week or so, there was anything you found initially confusing. Feedback from new users is always helpful.