| freemangordon | Wizzup: somehow miner managed to work on a deleted db | 08:47 |
|---|---|---|
| freemangordon | no wonder it reads stale data | 08:47 |
| freemangordon | Wizzup: and that happens every time. ok, mystery revealed. Now I only have to find out who deletes those files :) | 09:04 |
| freemangordon | hmm, sqlite returns SQLITE_CORRUPT at some pint | 09:34 |
| freemangordon | and tracker-extract deletes the db | 09:34 |
| Wizzup | freemangordon: huh | 11:25 |
| Wizzup | freemangordon: how did you confirm this? | 11:38 |
| Wizzup | freemangordon: the first thing that comes to mind are the various settings that tracker sets, re cache size and such | 11:41 |
| Wizzup | freemangordon: do you know where tracker_db_set_default_pragmas is defined? | 11:44 |
| Wizzup | found it I think | 11:45 |
| freemangordon | Wizzup: I confirmed this with gdb | 11:47 |
| Wizzup | ok | 11:49 |
| Wizzup | I don't think SQWLITE_CORRUPT is as bad as it sounds, so removing the db doesn't make sense I think | 11:49 |
| Wizzup | https://www.sqlite.org/howtocorrupt.html maybe relevant | 11:49 |
| freemangordon | yes, I had a look at it | 11:49 |
| freemangordon | but didn't get any idea what happens here | 11:49 |
| Wizzup | For maximum reliability and for robustness against database corruption, SQLite should always be run with its default synchronous setting of FULL. | 11:51 |
| Wizzup | tracker_db_interface_execute_query (iface, NULL, "PRAGMA \"%s\".synchronous = NORMAL", database); | 11:51 |
| Wizzup | *cough* | 11:51 |
| 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 | 11:51 |
| freemangordon | yes, but they say corruption ca happen because of macine poweroff etc | 11:51 |
| freemangordon | this is not the case here | 11:52 |
| Wizzup | the docs do say: WAL mode is safe from corruption with synchronous=NORMAL | 11:52 |
| freemangordon | *machine | 11:52 |
| Wizzup | ok | 11:52 |
| freemangordon | that break is very strange, because call stack contains hundreds if not thousands of frames | 11:52 |
| freemangordon | maybe some recursion happens that overflows the stack | 11:53 |
| Wizzup | I wonder if they hit some limit, either of transaction size or something else | 12:00 |
| freemangordon | looks like | 12:01 |
| freemangordon | running yet another gdb session | 12:02 |
| Wizzup | so in src/libtracker-sparql/core/tracker-db-manager.c they contains most of what they set | 12:02 |
| freemangordon | mhm | 12:02 |
| Wizzup | one observation, probably not relevant, but tracker seems to set synchronous=normal regardless of whether they enable WAL or not | 12:04 |
| Wizzup | (which is not safe) | 12:04 |
| Wizzup | not saying any of this is the real problem, just catching up on my sqlite knowledge | 12:04 |
| freemangordon | umm, they always enable wal, no? | 12:04 |
| Wizzup | no | 12:05 |
| Wizzup | the code has an option to enable it or not | 12:06 |
| Wizzup | but from the log files I saw they do enable wAL | 12:06 |
| Wizzup | hah the author had a commit earlier this year: | 12:06 |
| Wizzup | libtracker-sparql: Use setlocale() directly to query locale | 12:06 |
| Wizzup | Long long ago, this was an integration point since the Maemo platform | 12:06 |
| Wizzup | (I thought I'd never write that in 2023) had some infrastructure to | 12:06 |
| Wizzup | allow on-the-fly locale changes. | 12:06 |
| Wizzup | freemangordon: db_set_params has an enable_wall option | 12:07 |
| freemangordon | IIUC, once enabled, it cannot be disabled | 12:07 |
| Wizzup | btw https://chromium.googlesource.com/chromium/src/+/HEAD/sql/recovery.cc#1006 | 12:08 |
| freemangordon | ok, but why the corruption? | 12:09 |
| Wizzup | I was reading https://www.sqlite.org/howtocorrupt.html | 12:10 |
| freemangordon | I didn;t find any possible way tracker can corrupt | 12:10 |
| freemangordon | could be that I just missed something | 12:11 |
| Wizzup | I would maybe set synchronous to FULL just to be sure, but yeah, I am not sure either atm | 12:12 |
| Wizzup | I have not looked at the actual sqlite3 code in tracker yet | 12:12 |
| Wizzup | freemangordon: in any case the code that deletes that db should be closely inspected as well | 12:14 |
| freemangordon | "g_unlink (interface->filename);" | 12:14 |
| freemangordon | which is plain stupid | 12:15 |
| freemangordon | as it does not delete wal or shm files | 12:15 |
| freemangordon | hmm, but that does not happen every time | 12:15 |
| freemangordon | what the? | 12:15 |
| freemangordon | ok, lemme delete *all* tracker files and start from scratch | 12:16 |
| freemangordon | hmm | 12:17 |
| 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' | 12:17 |
| freemangordon | tracker-extract log is full of similar | 12:18 |
| Wizzup | freemangordon: this shouldn't cause that problem though right? | 12:36 |
| freemangordon | well, I see 200 songs without album | 12:37 |
| Wizzup | I mean, a different problem perhaps :) | 12:37 |
| freemangordon | yeah | 12:37 |
| freemangordon | also, seems mafw-tracker-source opens new tracker connection everytime it is inited and never closes it | 12:38 |
| 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 | 12:39 |
| freemangordon | ugh, gnome crashed, time for lunch obviously :) | 12:39 |
| freemangordon | yeah, maybe | 12:39 |
| freemangordon | ttyl | 12:39 |
| Wizzup | btw,#gnome-tracker on this network is where the maintainers seem to be | 12:40 |
| Wizzup | it looks like they did a lot of work since 3.3 | 12:41 |
| Wizzup | now at 3.6 | 12:41 |
| freemangordon | Wizzup: maybe check if we can build the latest debian version | 12:54 |
| freemangordon | either ways I'll have to port mafw tracker source to tracker 3 api at some pount | 12:54 |
| freemangordon | and if we don't use deprecated version, we can hope on some support from upstream | 12:55 |
| Wizzup | oh, I thought we were on the newer version already | 12:55 |
| freemangordon | no, we are on tracker 2 :) | 12:56 |
| Wizzup | so tracker 3 supports the tracker 2 api? | 12:56 |
| Wizzup | it does sound like building the recent debian release would be useful to try, since this isn't really working | 12:56 |
| Wizzup | not sure if things will really improve, but yeah... | 12:56 |
| Wizzup | debian has 3.4, so that's also a lot behind upstream | 13:00 |
| freemangordon | no, tracker 3 does not support tracker2 API | 13:06 |
| freemangordon | but changes are small | 13:06 |
| freemangordon | and it is still sparql | 13:06 |
| freemangordon | which debian is 3.4? unstable? | 13:06 |
| Wizzup | yes, sid | 13:13 |
| Wizzup | bookworm is also 3.4 | 13:14 |
| Wizzup | https://packages.debian.org/source/bookworm/armhf/tracker | 13:14 |
| freemangordon | still, better than what we have | 13:28 |
| freemangordon | also, my issue is with the packaging | 13:28 |
| freemangordon | we can always pull the source or individual fixes | 13:29 |
| Wizzup | freemangordon: what do you mean is 'why issue is with the packaging' ? | 13:33 |
| Wizzup | what do you mean with* | 13:33 |
| freemangordon | debian packaging | 13:41 |
| freemangordon | I don't want to create our own | 13:41 |
| freemangordon | I don;t think upstream tracker has any packaging | 13:42 |
| Wizzup | I still don't understand what the specific issue is, we can use debian packaging? | 13:42 |
| freemangordon | yes, but we have to create it from scratch, no? | 13:42 |
| freemangordon | if we pull upstream code | 13:43 |
| freemangordon | *maybe* debian packaging for 3.4 will work for 3.6, but who knows? | 13:43 |
| Wizzup | I think it'd probably work ok | 13:43 |
| freemangordon | yeah, could be | 13:43 |
| Wizzup | but yeah, I agree it would be some work | 13:43 |
| freemangordon | mhm | 13:44 |
| Wizzup | I just worry that trying to solve some weird sql corruption issue on the older version could be a time waste | 13:44 |
| freemangordon | work mtg, ttyl | 13:44 |
| Wizzup | ttyl | 13:44 |
| freemangordon | Wizzup: in experimental it is 3.6.1 | 15:27 |
| freemangordon | sorry, 3.6.0 | 15:30 |
| Wizzup | freemangordon: in experimental it said no such pkg for me | 15:35 |
| Wizzup | weird | 15:35 |
| freemangordon | https://packages.debian.org/source/experimental/armhf/tracker | 15:35 |
| Wizzup | yeah I see it now | 15:35 |
| Wizzup | weird | 15:35 |
| freemangordon | not that we will bve able to build it :) | 15:35 |
| Wizzup | https://packages.debian.org/experimental/armhf/tracker | 15:35 |
| freemangordon | there is source package | 15:36 |
| Wizzup | yeah | 15:36 |
| Wizzup | does it need something we don't have? | 15:36 |
| freemangordon | mhm\ | 15:36 |
| freemangordon | sec | 15:36 |
| freemangordon | installing deps that we have | 15:36 |
| freemangordon | to see what will remain | 15:37 |
| freemangordon | gi-docgen libsoup-3.0-dev | 15:39 |
| freemangordon | even 3.4 require that | 15:43 |
| Wizzup | and we don't have libsoup-3.0-dev? hm | 15:46 |
| freemangordon | mhm | 15:46 |
| freemangordon | we're getting old :) | 15:46 |
| freemangordon | and building it requires apache?!? | 15:47 |
| Wizzup | doesn't sound like things would improve | 15:47 |
| Wizzup | :D | 15:47 |
| freemangordon | maybe for testing | 15:47 |
| freemangordon | (unit tests) | 15:47 |
| 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) | 15:47 |
| Wizzup | right @ unit tests | 15:47 |
| freemangordon | ok, but now tracker is unusable | 15:48 |
| freemangordon | or almost | 15:48 |
| Wizzup | yeah, it's worth trying to see if 3.6 works | 15:51 |
| Wizzup | we could also see if some pkgs are in backports | 15:51 |
| freemangordon | btw I think I found a workaround | 15:51 |
| Wizzup | now I have to prepare for a work mtg btw :) | 15:51 |
| freemangordon | but want to be sure first | 15:51 |
| arno11 | sicelo: calls seems to work with no particular tweaks now (no overclock but with light transitions). and no priority stuff | 17:54 |
| arno11 | thx to PA in user mode and new DDX (h-d works better) | 17:55 |
| 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 | 17:57 |
| Wizzup | great | 18:13 |
| arno11 | yeah :) | 18:14 |
| Wizzup | freemangordon: I'm curious as to the workaround btw | 19:58 |
| freemangordon | reset the db and the delete .local/share/tracker/ | 20:04 |
| freemangordon | *then | 20:04 |
| freemangordon | Wizzup: ^^^ | 20:04 |
| freemangordon | BTW, there are couple of leaks in mafw-tracker-source | 20:05 |
| Wizzup | hm, but won't that cause the problems again? | 20:05 |
| freemangordon | will try to fix them later today | 20:05 |
| Wizzup | ok | 20:05 |
| freemangordon | Wizzup: how do I know? :) | 20:05 |
| freemangordon | at least for now that fixed the issue here | 20:06 |
| freemangordon | YMMV | 20:06 |
| Wizzup | freemangordon: well I did that a few times | 20:08 |
| Wizzup | and it keeps getting back to the same problem | 20:08 |
| Wizzup | like that's how I go to a clean state to trigger the problem | 20:08 |
| freemangordon | even after deleting the tracker-store journal? | 20:11 |
| freemangordon | you did what a few times? | 20:11 |
| freemangordon | I am not talking about .cache/tracker directlry | 20:11 |
| freemangordon | but .local/share/tracker/ | 20:11 |
| freemangordon | tracker-store keeps some strange file tehre | 20:12 |
| freemangordon | this is not sqlite db directory | 20:12 |
| freemangordon | Wizzup: ^^^ | 20:15 |
| Wizzup | hmmm | 20:17 |
| Wizzup | ok, I will try that tonight | 20:17 |
| Wizzup | (in 20 mins) | 20:18 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!