Conversation
The schema creator for 3.0.2 seeds the table's AUTOINCREMENT counter
before inserting into it:
INSERT INTO sqlite_sequence VALUES('Information',1);
INSERT INTO Information ([uuid], ...) VALUES (?, ...);
With the counter already at 1, the row lands at id 2. Engine keeps
exactly one row in that table and keeps it at id 1: a Denon-written
stick has it at 1, and so does the database a Prime 4 writes for itself.
A Prime 4 given a 3.0.2 library created by this library reports the
stick as corrupt and replaces `m.db` with an empty database of its own,
discarding every track. Renumbering the row to 1 and changing nothing
else is enough to stop that.
The `Information` table is also where the schema version lives, so it is
the first thing anything reading the library looks at, `detect_schema()`
included.
Only 3.0.2 seeds the counter; no other schema version in that directory
does, and libraries created at 1.x and 2.x already come out with the row
at id 1. Dropping the statement leaves the same end state a real
library has: the row at id 1, and `sqlite_sequence` reading 1 for the
table, written by the insert itself.
New tests assert the row's id for every 2.x and 3.x schema version, and
the doc comment on `information_row::id` -- which called the value not
especially meaningful -- now says what hardware expects of it.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes the
Informationrow landing at id 2 in libraries created at schema 3.0.2, which a Prime 4 rejects as a corrupt database. Issue: #201.schema_3_0_2::create()seeds the table's AUTOINCREMENT counter before inserting into it:so the row lands at id 2. Only 3.0.2 does this; every other schema version in that directory leaves the counter alone and comes out with the row at id 1, which is where a Denon-written stick has it, and where a Prime 4 puts it in the database it writes for itself.
Dropping the statement leaves exactly the state a real library is in: the row at id 1, and
sqlite_sequencereading 1 for the table, written by the insert itself. Verified by creating a 3.0.2 library and reading both back.Also here:
information_table_testfor v2 and v3, asserting the row's id for every 2.x and 3.x schema version. With thesqlite_sequencestatement put back, exactly the 3.0.2 case fails and the other nine pass.information_row::idcalled the value "not especially meaningful"; it now says what hardware expects of it.Tested on Ubuntu 24.04 (CMake 3.30.5, GCC 13.3.0):
ctestpasses 14/14, the two new test targets included.Thank you for libdjinterop, and for the quick turnaround on #200. This one cost us a stick's worth of tracks to find, so it felt worth writing up properly.