<freemangordon>
but didn't get any idea what happens here
<Wizzup>
For maximum reliability and for robustness against database corruption, SQLite should always be run with its default synchronous setting of FULL.
<freemangordon>
but, if you attach gdb while extract is running after db being reset (on the first pass), you will see that at some point it will break with the message from the line 2348 in tracker-db-interface-sqlite.c
<freemangordon>
yes, but they say corruption ca happen because of macine poweroff etc
<freemangordon>
this is not the case here
<Wizzup>
the docs do say: WAL mode is safe from corruption with synchronous=NORMAL
<freemangordon>
*machine
<Wizzup>
ok
<freemangordon>
that break is very strange, because call stack contains hundreds if not thousands of frames
<freemangordon>
maybe some recursion happens that overflows the stack
<Wizzup>
I wonder if they hit some limit, either of transaction size or something else
<freemangordon>
looks like
<freemangordon>
running yet another gdb session
<Wizzup>
so in src/libtracker-sparql/core/tracker-db-manager.c they contains most of what they set
<freemangordon>
mhm
<Wizzup>
one observation, probably not relevant, but tracker seems to set synchronous=normal regardless of whether they enable WAL or not
<Wizzup>
(which is not safe)
<Wizzup>
not saying any of this is the real problem, just catching up on my sqlite knowledge
<freemangordon>
umm, they always enable wal, no?
<Wizzup>
no
<Wizzup>
the code has an option to enable it or not
<Wizzup>
but from the log files I saw they do enable wAL
<Wizzup>
hah the author had a commit earlier this year:
<Wizzup>
libtracker-sparql: Use setlocale() directly to query locale
<Wizzup>
Long long ago, this was an integration point since the Maemo platform
<Wizzup>
allow on-the-fly locale changes.
<Wizzup>
(I thought I'd never write that in 2023) had some infrastructure to
<Wizzup>
freemangordon: db_set_params has an enable_wall option
<freemangordon>
IIUC, once enabled, it cannot be disabled
<freemangordon>
I didn;t find any possible way tracker can corrupt
<freemangordon>
could be that I just missed something
<Wizzup>
I would maybe set synchronous to FULL just to be sure, but yeah, I am not sure either atm
<Wizzup>
I have not looked at the actual sqlite3 code in tracker yet
uvos__ has joined #maemo-leste
<Wizzup>
freemangordon: in any case the code that deletes that db should be closely inspected as well
<freemangordon>
"g_unlink (interface->filename);"
<freemangordon>
which is plain stupid
<freemangordon>
as it does not delete wal or shm files
<freemangordon>
hmm, but that does not happen every time
<freemangordon>
what the?
<freemangordon>
ok, lemme delete *all* tracker files and start from scratch
<freemangordon>
hmm
<freemangordon>
Could not insert metadata for item "file:///home/user/MyDocs/.sounds/Accept/Accept%20-%2098%20-%20Worldwide/13.%20Fast%20As%20A%20Shark.mp3": Subject `urn:uuid:fd0bdac2-7640-41af-9101-1b8ef1d3ed5d' is not in domain `nie:DataObject' of property `nie:dataSource'
<freemangordon>
tracker-extract log is full of similar
<Wizzup>
freemangordon: this shouldn't cause that problem though right?
<freemangordon>
well, I see 200 songs without album
<Wizzup>
I mean, a different problem perhaps :)
<freemangordon>
yeah
<freemangordon>
also, seems mafw-tracker-source opens new tracker connection everytime it is inited and never closes it
freemangordon has quit [Quit: Leaving.]
freemangordon has joined #maemo-leste
<Wizzup>
freemangordon, there does seem to be a lot of work ongoing on the tracker git, as recently as a few days ago, I wonder if it makes sense to pull their work in
<freemangordon>
ugh, gnome crashed, time for lunch obviously :)
<freemangordon>
yeah, maybe
<freemangordon>
ttyl
<Wizzup>
btw,#gnome-tracker on this network is where the maintainers seem to be
<Wizzup>
it looks like they did a lot of work since 3.3
<Wizzup>
now at 3.6
uvos__ has quit [Ping timeout: 245 seconds]
<freemangordon>
Wizzup: maybe check if we can build the latest debian version
<freemangordon>
either ways I'll have to port mafw tracker source to tracker 3 api at some pount
<freemangordon>
and if we don't use deprecated version, we can hope on some support from upstream
<Wizzup>
oh, I thought we were on the newer version already
<freemangordon>
no, we are on tracker 2 :)
<Wizzup>
so tracker 3 supports the tracker 2 api?
<Wizzup>
it does sound like building the recent debian release would be useful to try, since this isn't really working
<Wizzup>
not sure if things will really improve, but yeah...
<Wizzup>
debian has 3.4, so that's also a lot behind upstream
<freemangordon>
no, tracker 3 does not support tracker2 API
<freemangordon>
and building it requires apache?!?
<Wizzup>
doesn't sound like things would improve
<Wizzup>
:D
<freemangordon>
maybe for testing
<freemangordon>
(unit tests)
<Wizzup>
I really think we should stay on the base we are until we have some other core things working btw (re: we're getting old)
<Wizzup>
right @ unit tests
<freemangordon>
ok, but now tracker is unusable
<freemangordon>
or almost
<Wizzup>
yeah, it's worth trying to see if 3.6 works
<Wizzup>
we could also see if some pkgs are in backports
<freemangordon>
btw I think I found a workaround
<Wizzup>
now I have to prepare for a work mtg btw :)
<freemangordon>
but want to be sure first
enviosity has quit [Ping timeout: 260 seconds]
enviosity has joined #maemo-leste
ceene has quit [Ping timeout: 252 seconds]
arno11 has joined #maemo-leste
<arno11>
sicelo: calls seems to work with no particular tweaks now (no overclock but with light transitions). and no priority stuff
<arno11>
thx to PA in user mode and new DDX (h-d works better)
<arno11>
the only bug: ringtone doesn't work the first time you receive a call after starting cmt_pulse, then it works for the second
pere has quit [Ping timeout: 252 seconds]
<Wizzup>
great
<arno11>
yeah :)
pere has joined #maemo-leste
arno11 has left #maemo-leste [#maemo-leste]
akossh has joined #maemo-leste
slep has joined #maemo-leste
<Wizzup>
freemangordon: I'm curious as to the workaround btw
<freemangordon>
reset the db and the delete .local/share/tracker/
<freemangordon>
*then
<freemangordon>
Wizzup: ^^^
<freemangordon>
BTW, there are couple of leaks in mafw-tracker-source
<Wizzup>
hm, but won't that cause the problems again?
<freemangordon>
will try to fix them later today
<Wizzup>
ok
<freemangordon>
Wizzup: how do I know? :)
<freemangordon>
at least for now that fixed the issue here
<freemangordon>
YMMV
<Wizzup>
freemangordon: well I did that a few times
<Wizzup>
and it keeps getting back to the same problem
slep has left #maemo-leste [#maemo-leste]
slep has joined #maemo-leste
<Wizzup>
like that's how I go to a clean state to trigger the problem
<freemangordon>
even after deleting the tracker-store journal?
<freemangordon>
you did what a few times?
<freemangordon>
I am not talking about .cache/tracker directlry
<freemangordon>
but .local/share/tracker/
<freemangordon>
tracker-store keeps some strange file tehre
<freemangordon>
this is not sqlite db directory
<freemangordon>
Wizzup: ^^^
<Wizzup>
hmmm
<Wizzup>
ok, I will try that tonight
<Wizzup>
(in 20 mins)
pere has quit [Ping timeout: 246 seconds]
DFP has quit [Quit: Leaving]
pere has joined #maemo-leste
rafael2k has joined #maemo-leste
rafael2k has quit [Ping timeout: 252 seconds]
Ascavasaion is now known as Oksana
<Wizzup>
freemangordon: ok, tried that now, let's see if this works out
<Wizzup>
I see this btw:
<Wizzup>
$ tracker daemon -s
<Wizzup>
Starting miners…
<Wizzup>
(tracker daemon:30492): Tracker-CRITICAL **: 00:32:48.217: Could not create proxy on the D-Bus session bus, Error calling StartServiceByName for org.freedesktop.Tracker1.Miner.Extract: Timeout was reached
<Wizzup>
freemangordon: there is also .cache/tracker btw