The result from my system looks same.
root@sblplex01:~ $ echo NULL NULD | od -bc
0000000 116 125 114 114 040 116 125 114 104 012
N U L L N U L D \n
0000012
root@sblplex01:~ $ echo INTO MNTO | od -bc
0000000 111 116 124 117 040 115 116 124 117 012
I N T O M N T O \n
0000012
root@sblplex01:~ $
I’m currently in process of running smartctl -t long /dev/nvme0 to do a SMART Self-Test on the NVMe drive. The short test came back okay and the drive doesn’t show any other errors. Still need to run a memtest86.
All this said, I think I may have corrected it altogether: I did an export of the database using DB Browser for SQLite GUI and choosing to export every table except for the statistics_bandwidth table. That seems to be where everything was breaking down. After I exported the tables, I created a new database and imported the SQL output using the Plex SQLite server (because importing in DB Browser had issues), then I manually recreated the statistics_bandwidth table and indexes using the info I found in the thread about the PM-3483 account_id excessive logging bug here.
That new DB is now back to the rough size of where it was back in December when the last successful backup happened (around 280MB), and my Plex server seems to be running just fine with it and has all the correct media, user, and history information, from what I can tell, and a PRAGMA integrity_check; comes back OK on the new database file.
