| freemangordon | Wizzup: that query results in valid id when called from within miner | 07:44 |
|---|---|---|
| freemangordon | starting to look like race condition | 07:44 |
| sunshavi | a count before the select? | 10:34 |
| Wizzup | freemangordon: what is the id? | 11:20 |
| freemangordon | urn:uuid:bb8cbccd-320e-456c-9383-9a23124e4328 | 11:46 |
| freemangordon | but there is no such id when I select from the shell | 11:47 |
| Wizzup | maybe it's some id that is itself temporaraily adds | 11:50 |
| Wizzup | I wonder if you can just check if there is a result, and see if the first result is "None" | 11:50 |
| freemangordon | or sqlite caches data | 11:50 |
| freemangordon | no, first result is urn\ | 11:51 |
| Wizzup | I wouldn't blame sqlite3 here, but maybe how tracker uses sqlite3 | 11:51 |
| Wizzup | aha | 11:51 |
| Wizzup | got the full query for me? | 11:51 |
| freemangordon | 'SELECT ?u { GRAPH <urn:uuid:472ed0cc-40ff-4e37-9c0c-062d78656540> { ?u a nfo:FileDataObject ; tracker:available true ; a ?class . FILTER (?class IN (nfo:Media,nfo:Icon,nfo:Document,nmm:Playlist,nmm:MusicPiece,nfo:Audio,nfo:PlainTextDocument,nmm:Video,nfo:SourceCode,nfo:HtmlDocument,nfo:Video,nfo:SoftwareApplication,nfo:EBook,nmm:Photo,nfo:VectorImage,nfo:TextDocument,nfo:PaginatedTextDocument,nfo:FilesystemImage,nfo:Image,nfo:M | 11:51 |
| freemangordon | do you want me to pastebin it? | 11:52 |
| Wizzup | I can work with this I think | 11:52 |
| Wizzup | so you say from cli this returns nothing? | 11:52 |
| Wizzup | oh actually it is cut off | 11:52 |
| freemangordon | this returns no result in the shell and uuid in tracker-miner-fs | 11:52 |
| freemangordon | yes | 11:52 |
| freemangordon | and there is no such uuid in the database | 11:53 |
| Wizzup | is there anything other than uuid in the row? | 11:53 |
| freemangordon | no, see the query | 11:53 |
| freemangordon | ?u a nfo:FileDataObject | 11:53 |
| Wizzup | so one possibility is that this is some tmp file | 11:53 |
| Wizzup | I've seen tracker-miner-fs find various tmp files in /var/tmp | 11:53 |
| Wizzup | no, hang on, that is not right | 11:53 |
| Wizzup | I've seen it on dbus-monitor as picked up by some inotify daemon, but not tracker-miner-fs | 11:54 |
| Wizzup | but maybe it is some tmp file that it picks up when the program starts up | 11:54 |
| freemangordon | Wizzup: i debugged to the pont where sqlite returns result | 11:55 |
| freemangordon | *point | 11:55 |
| freemangordon | this is *not* tracker caching something or picking up wrong file or whatever | 11:55 |
| freemangordon | it id DB returning stalled data | 11:56 |
| freemangordon | tracker sparql -q 'SELECT * WHERE { ?u a nfo:FileDataObject. FILTER (?u = urn:uuid:bb8cbccd-320e-456c-9383-9a23124e4328)}' returns nothing in the console | 11:56 |
| bencoh | sqlite showing stalled data might mean that two processes opened the db | 11:56 |
| Wizzup | freemangordon: you mean that you stopped gdb? | 11:57 |
| Wizzup | stopped it from gdb? | 11:57 |
| freemangordon | bencoh: yes, looks like that | 11:57 |
| Wizzup | sqlite3 has a notion of transations, journals, write ahead log, and so oh, so this doesn't have to be a sqlite3 problem | 11:57 |
| freemangordon | Wizzup: stooped? no, stepped :) | 11:57 |
| freemangordon | and yes, I started tracker-miner-fs from gdb | 11:58 |
| Wizzup | like if tracker-miner-fs starts a transaction, crawls fs, adds something, then runs that query before commit, only it will see it | 11:58 |
| Wizzup | I mean you know all of these things, but just saying | 11:58 |
| freemangordon | look at the select | 11:58 |
| Wizzup | right | 11:58 |
| freemangordon | it has a condition | 11:58 |
| freemangordon | and (i suspect) that gets set by tracker-extract | 11:58 |
| Wizzup | tracker-extract doesn't run at the time of this query though | 11:59 |
| freemangordon | yes | 11:59 |
| freemangordon | and DB as such is correct | 11:59 |
| freemangordon | but it seems there is cached data in the miner | 11:59 |
| freemangordon | as bencoh said, because we have 2 processes opening the DB | 11:59 |
| freemangordon | I see the same issue with mafw-tracker-source | 11:59 |
| Wizzup | but only one active process :) | 12:00 |
| freemangordon | where sparql queries return some obsolete data | 12:00 |
| freemangordon | does not matter | 12:00 |
| Wizzup | ok, well, this still does not look like a sqlite3 problem to me at all, but you clearly spent a lot more time on it | 12:00 |
| Wizzup | maybe in how gnome folks use it | 12:00 |
| freemangordon | so it is either sqlite or how tracker uses it | 12:00 |
| freemangordon | right | 12:00 |
| freemangordon | but I see nothing special in how they open the db | 12:01 |
| Wizzup | still it would be good to know where this row comes from | 12:01 |
| freemangordon | result = sqlite3_open_v2 (db_interface->filename, &db_interface->db, mode | SQLITE_OPEN_NOMUTEX, NULL); | 12:01 |
| freemangordon | that's look fine to me | 12:01 |
| Wizzup | the pragma's they run afterwards matter more | 12:01 |
| freemangordon | *that looks | 12:01 |
| freemangordon | yeah | 12:01 |
| freemangordon | lemme chech what they do | 12:01 |
| freemangordon | *check | 12:01 |
| Wizzup | is there any way to run tracker-miner-fs in a way where it *prints* what files it finds / wants analysed? | 12:02 |
| Wizzup | well, I guess it does write that to the log (Creating new item) | 12:02 |
| freemangordon | 'PRAGMA synchronous = OFF;' | 12:02 |
| Wizzup | I've seen tracker-extract run a lot of pragma's, but tracker-miner-fs not so much, but I maybe did not see it restart as often | 12:03 |
| Wizzup | freemangordon: yes, because they use journal mode and wal, I think that is fine | 12:03 |
| freemangordon | you have to G_MESSAGES_DEBUG=all | 12:03 |
| Wizzup | do you see tracker-miner-fs add any file before running that select, or not? | 12:04 |
| Wizzup | I'm not sure yet how you know the problem isn't just within the tracker-miner-fs transaction/session | 12:04 |
| freemangordon | yes, I see adding many files | 12:05 |
| freemangordon | or rather it checks db for consistency on startup | 12:05 |
| freemangordon | looks fine to me | 12:05 |
| Wizzup | also in the odd behaviour where it keeps starting extract? | 12:05 |
| freemangordon | odd behaviour is because it thinks there is something to be extracted | 12:05 |
| freemangordon | because the query returns result | 12:05 |
| Wizzup | yes, but something has to be written to be db for that to return results | 12:06 |
| freemangordon | https://pastebin.com/fJ4iAxFx | 12:06 |
| freemangordon | pragmas | 12:06 |
| Wizzup | and I doubt that tracker-extract adds new rows by itself, it should just update them with data, no? | 12:06 |
| freemangordon | hmm, maybe you are right | 12:06 |
| Wizzup | those are the same pragma's as with tracker-extract at least | 12:06 |
| freemangordon | I have a full startup log, lemme see where this uuid comes form | 12:07 |
| freemangordon | hmm, maybe I shall delete most of the music, to speed-up the process | 12:17 |
| freemangordon | Wizzup: ok, what I think happens is: | 12:22 |
| freemangordon | miner crawls all directories and inserts files that are extract subject | 12:23 |
| freemangordon | the tracker-extract (or tracker-store) deletes those records once processed | 12:23 |
| freemangordon | somehow a stale data for a deleted record remains in the miner sqlite connection | 12:24 |
| rafael2k_ | hi all! I'm flying to conference today, but on Sunday I'm back and can leave the PPP on and accessible over the VPN for anyone wanting to help with h-d and everything else! | 12:30 |
| freemangordon | rafael2k_: thanks, I guess Wizzup will unpack his device finally :) | 12:31 |
| rafael2k_ | eheheh | 12:31 |
| rafael2k_ | cool! | 12:31 |
| freemangordon | I am kind of reluctant to do development on a device noone has physical access to | 12:32 |
| rafael2k_ | I'll use openvpn, as I already settled it up, but running to the airport now | 12:32 |
| freemangordon | in theory I can have a runaway process that will melt the cores | 12:32 |
| rafael2k_ | ehehehe | 12:32 |
| freemangordon | no, really | 12:32 |
| rafael2k_ | I always do this when compiling the kernel | 12:32 |
| rafael2k_ | :P | 12:32 |
| freemangordon | hehe | 12:32 |
| rafael2k_ | and now with 6 cores... | 12:32 |
| freemangordon | but you know it will finish at some points | 12:33 |
| freemangordon | runaway process will most-probably destroy the device if left running for sevral days | 12:33 |
| Wizzup | back | 12:33 |
| rafael2k_ | btw, libcamera properly list the cameras, and Pinchart will add to libcamera some tuning files for the rk1isp | 12:33 |
| rafael2k_ | for photo / video, PPP will work well | 12:34 |
| Wizzup | freemangordon: I don't know if tracker-extract deletes or update records but this sounds correct | 12:34 |
| freemangordon | deletes them | 12:34 |
| Wizzup | ok | 12:35 |
| freemangordon | tracker sparql -q 'SELECT * WHERE { ?u a nfo:FileDataObject}' | 12:35 |
| Wizzup | well, tracker-extract doesn't find the record, do they even use the same kind of queries? | 12:35 |
| freemangordon | who cares? the same query gives no results from the cli | 12:35 |
| freemangordon | execute ^^^ query | 12:35 |
| Wizzup | right, it's not in the same transaction | 12:35 |
| Wizzup | in any case it sounds like what you said above seems correct, but we still might want to know what this stale row is, where it comes from | 12:36 |
| Wizzup | it doesn't seem like tracker-extract is doing anything wrong, is what I mean, it just starts, sees nothing, stops | 12:36 |
| freemangordon | it comes from the initial inserts in the miner | 12:36 |
| freemangordon | exactly | 12:36 |
| sunshavi | But when you open from the cli. Yo do not use sqlite3_open_v2 which is multi-thread. so conn is different | 12:36 |
| freemangordon | and miner restarts it because it thinks extract has something to do :) | 12:36 |
| freemangordon | sunshavi: so? it is still the same db | 12:37 |
| Wizzup | freemangordon: but it seems to be wrong in this belief, so I'm wondering where this stale record comes from | 12:37 |
| rafael2k_ | * Kieran Bingham will help with the ISP side | 12:37 |
| freemangordon | Wizzup: exactly | 12:37 |
| Wizzup | rafael2k_: great @ libcamera (sorry caught up in this tracker issue chat :) ) | 12:37 |
| Wizzup | freemangordon: the uuid doesn't show which one it is in the logs I guess? | 12:37 |
| freemangordon | miner does not print uuds | 12:38 |
| Wizzup | I'm kind of surprised that the table with the record wouldn't contain the *path* of the file, like how does tracker-extract what to do | 12:38 |
| rafael2k_ | Wizzup, : )) I wish good luck with it! | 12:38 |
| freemangordon | but it does not matter eitehr | 12:38 |
| freemangordon | Wizzup: it does | 12:38 |
| Wizzup | like, how does tracker extract know what to do with it* | 12:38 |
| Wizzup | freemangordon: ok | 12:38 |
| freemangordon | it does know, while the record is still there | 12:38 |
| Wizzup | can we get the path from tracker-miner-fs when it runs this query? | 12:38 |
| freemangordon | sparql -q 'SELECT * WHERE { ?u a nfo:FileDataObject; nie:url ?url. FILTER (?u = urn:uuid:14ec2b01-d9ad-432a-a4ce-12474c0f1f97)}' | 12:38 |
| freemangordon | was giving me file:///home/user/Xorg.0.log, urn:uuid:14ec2b01-d9ad-432a-a4ce-12474c0f1f97 | 12:39 |
| freemangordon | before extract did his job | 12:39 |
| freemangordon | and none after it did | 12:39 |
| freemangordon | that's why I said extract (or store) deletes the records that were put there by the miner | 12:39 |
| Wizzup | ok, so this record is there saved in the db before tracker runs, regardless of whether you look from miner-fs or not? | 12:39 |
| Wizzup | or is this just -a- record, not the stale one ? (sorry I'm bad at matching uuids :D ) | 12:40 |
| freemangordon | what is 'tracker' in this context? | 12:40 |
| Wizzup | tracker-extract, my bad | 12:40 |
| freemangordon | yes, just a record | 12:40 |
| Wizzup | ok | 12:40 |
| freemangordon | a valid one | 12:40 |
| Wizzup | btw, just to double check, when I run: | 12:40 |
| Wizzup | $ tracker sparql -q 'SELECT * WHERE { ?u a nfo:FileDataObject}' | 12:40 |
| Wizzup | Results: None | 12:40 |
| freemangordon | mhm | 12:40 |
| Wizzup | I get the above, and that is not a 1 row result, yeah? | 12:40 |
| freemangordon | everything is deleted | 12:40 |
| Wizzup | ok | 12:40 |
| freemangordon | no, this is empty result | 12:41 |
| Wizzup | ok | 12:41 |
| freemangordon | in the same time miner gets results for teh same (lets assume) query | 12:41 |
| freemangordon | so, to me it is sqlite cached something | 12:41 |
| freemangordon | give me 2 minutes to debug something | 12:42 |
| Wizzup | k, it might be that miner-fs doesn't finish/flush it's work | 12:42 |
| freemangordon | oh, still extracting ::( | 12:42 |
| Wizzup | before it does a search itself, but even that should work | 12:42 |
| freemangordon | hmm, wait | 12:42 |
| freemangordon | maybe it is on the opposite | 12:42 |
| freemangordon | it has it in its cache, but it is not flushed to the db | 12:43 |
| freemangordon | is that possible? | 12:43 |
| sunshavi | Yes that could be possible. before doing commit or rollback | 12:44 |
| freemangordon | does it read uncommited? | 12:44 |
| Wizzup | freemangordon: sure it is possible, but then it would flush a stale record to the db, that is also weird | 12:45 |
| Wizzup | at least I am still under the assumption that tracker-miner-fs doesn't actually have any work that needs done | 12:47 |
| freemangordon | Wizzup: seems sqlite does "read uncommited" if a query is in the same transaction | 12:47 |
| Wizzup | yes, that is how it should be | 12:47 |
| Wizzup | I don't know if tracker-miner-fs does these things though | 12:48 |
| freemangordon | so it is possible that miner does not commit the last transaction | 12:48 |
| Wizzup | (just didn't look at the src) | 12:48 |
| Wizzup | yup, that would be hella stupid, but it's possible | 12:48 |
| freemangordon | so it will see the data, while noone else will | 12:48 |
| freemangordon | well, I don;t see any other plausible option | 12:48 |
| Wizzup | yes, that would make sense if we can't see it, even it tracker-extract does not run | 12:49 |
| freemangordon | either that or sqlite3 is FUBAR :) | 12:49 |
| Wizzup | freemangordon: can we change tracker-miner-fs and print the rows it finds? | 12:49 |
| Wizzup | before it runs tracker-miner-fs ? | 12:49 |
| Wizzup | er | 12:49 |
| Wizzup | tracker-extract | 12:49 |
| freemangordon | as I said, I already did | 12:49 |
| freemangordon | what do you mean "rows"? | 12:49 |
| freemangordon | url? | 12:49 |
| Wizzup | to get the filename | 12:49 |
| Wizzup | yeah | 12:49 |
| freemangordon | what data do you need? | 12:49 |
| freemangordon | ok, sec | 12:49 |
| Wizzup | btw, this is super unrelated, but probably also want to tweak the actual files that tracker looks at, there is the gsettings ignore rules and rules in /usr/share/tracker-miners/extract-rules | 12:50 |
| Wizzup | but we probably* | 12:50 |
| freemangordon | right | 12:50 |
| sunshavi | what tracker has to do with an X log file? | 12:52 |
| Wizzup | nevermind the log file, that is a red herring | 12:52 |
| Wizzup | sunshavi: GNOME tracker reads all kinds of files in various places, including the Xorg.0.log file in /home/user | 12:52 |
| freemangordon | this is a text file | 12:53 |
| freemangordon | there is no reason for it to not be indexed | 12:53 |
| Wizzup | freemangordon: tracker indexes text files for full text search | 12:53 |
| Wizzup | which actually is quite awesome | 12:53 |
| Wizzup | so there is a reason for it, but not for OMP | 12:53 |
| Wizzup | it also extracts text from PDFs | 12:54 |
| sunshavi | but that log file should have nothing interesting. It could be important If You are searching for an ERR perhaps | 12:54 |
| Wizzup | sunshavi: again, red herring, just nevermind | 12:54 |
| Wizzup | :) | 12:54 |
| freemangordon | Wizzup: I didn;t say it is bad | 12:57 |
| freemangordon | "there is no reason for it to not be indexed" | 12:57 |
| Wizzup | misread :) | 12:57 |
| sunshavi | excluding that file does not help? | 12:57 |
| Wizzup | sunshavi: *red herring*, it's not related to the problem :D | 12:57 |
| freemangordon | sunshavi: this file has nothing to do | 12:57 |
| freemangordon | period :) | 12:57 |
| sunshavi | perhaps on the miner's codepath a commit or rollback have been forgotten? | 12:59 |
| Wizzup | perhaps, we'll find out | 12:59 |
| freemangordon | Wizzup: runnung the new miner that will dump all the 'stale' rows | 13:01 |
| freemangordon | the fuck | 13:02 |
| freemangordon | I deleted most of the music and now it works ok | 13:02 |
| freemangordon | (tracker-miner-fs:17937): Tracker-DEBUG: 14:01:49.455: Not starting extractor. Nothing to do. | 13:02 |
| freemangordon | ok, lemme add data back | 13:02 |
| Wizzup | lol: 06 Dec 2023, 13:03:51: Tracker: Processing file 'file:///usr/share/applications'... | 13:04 |
| Wizzup | 06 Dec 2023, 13:04:15: Tracker: Creating new item 'file:///usr/share/applications/hildon-status-menu/ham-notifier.desktop'\ | 13:04 |
| Wizzup | not sure why but ok | 13:04 |
| freemangordon | it indexes applications as well | 13:05 |
| freemangordon | I think they disabled that in 3.0 | 13:05 |
| Wizzup | $ gsettings get org.freedesktop.Tracker.Miner.Files index-recursive-directories | 13:05 |
| Wizzup | ['&DESKTOP', '&DOCUMENTS', '&MUSIC', '&PICTURES', '&VIDEOS', '/mnt/sd/'] | 13:05 |
| Wizzup | it shouldn't I think, but ok | 13:05 |
| freemangordon | hmm, looks like I am not hitting the bug with the modified query :( | 13:13 |
| freemangordon | or I still don;t have enough music | 13:13 |
| freemangordon | Wizzup: Result [0]: urn:uuid:d8630ae1-784b-4112-8e9b-47edd6060d8c, file:///home/user/MyDocs/.sounds/Blind%20Guardian/(1986-1987)%20-%20Lucifer's%20Heritage%20E.P.'s/(1987)%20-%20Battalions%20Of%20Fear/05%20-%20Run%20For%20The%20Night.mp3 | 13:21 |
| freemangordon | hmm, wait | 13:22 |
| freemangordon | this is the first time after restart so it is normal | 13:22 |
| Wizzup | mhm | 13:23 |
| freemangordon | the second time it still says "(tracker-miner-fs:18865): Tracker-DEBUG: 14:21:25.565: Not starting extractor. Nothing to do." | 13:23 |
| freemangordon | lemme add more music | 13:23 |
| freemangordon | maybe the changed query made it run properly, dunno | 13:24 |
| freemangordon | I added OPTIONAL {?u nie:url ?url} in the select clause | 13:24 |
| Wizzup | it might take a bit of time to get into this problem | 13:27 |
| freemangordon | looks like, yeah | 13:27 |
| Wizzup | I'm also reindexing my files, even though I did the same yesterday but some how it got lost I guess | 13:29 |
| freemangordon | will take some time until music gets copied over ssh | 13:31 |
| Wizzup | freemangordon: hm pvr on my d4 is unhappy, any debug I can get for you? | 13:38 |
| freemangordon | elaborate on 'unhappy' | 13:38 |
| Wizzup | screen is stuck, nothing happens, dmesg is filled with repeating messages | 13:38 |
| freemangordon | I don;t think I can do anything about it | 13:38 |
| Wizzup | interestingly it starts with: | 13:39 |
| Wizzup | Dec 6 13:07:54 localhost kernel: [130585.629302] PVR_K: User requested SGX debug info | 13:39 |
| freemangordon | in the newer blobs they say reset works properly | 13:39 |
| freemangordon | no idea what that means | 13:39 |
| Wizzup | xorg log says: | 13:39 |
| Wizzup | [130585.607] (EE) OMAP(0): ERROR: waitForBlitsCompleteOnDeviceMem: PVR2DQueryBlitsComplete failed with error code: -8 (Blit not complete) | 13:40 |
| Wizzup | [130588.704] (EE) OMAP(0): ERROR: sgxCopyNextBatch: PVR2DBlt failed with error code: -2 (Device unavailable) | 13:40 |
| Wizzup | [130589.204] (EE) OMAP(0): ERROR: waitForBlitsCompleteOnDeviceMem: PVR2DQueryBlitsComplete failed with error code: -8 (Blit not complete) | 13:40 |
| freemangordon | sgx crashed | 13:40 |
| freemangordon | this shall be handled in the driver/blobs | 13:40 |
| freemangordon | but it is not | 13:40 |
| freemangordon | in our version of the blobs that is | 13:41 |
| Wizzup | ok | 13:41 |
| Wizzup | I'll restart the device when tracker finishes | 13:41 |
| Wizzup | brb | 13:41 |
| freemangordon | see the commit message https://git.ti.com/cgit/graphics/omap5-sgx-ddk-um-linux/commit/?h=1.17.4948957/mesa/glibc-2.35&id=337832df9662f0842ce4704342c0e42acab22209 | 13:42 |
| freemangordon | "Hardware recoveries work now,..." | 13:42 |
| freemangordon | ok, we I hit the bug again | 13:44 |
| freemangordon | Result [0]: urn:uuid:9b88e7a9-30de-4153-8b60-e8b6ea7ed1a3, file:///home/user/MyDocs/.sounds/Hammerfall/Renegade/06%20-%20The%20Way%20Of%20The%20Warrior.mp3 | 13:44 |
| freemangordon | seems tracker does not like Hammerfall :) | 13:44 |
| freemangordon | have to join a mtg, bbl | 13:46 |
| Wizzup | freemangordon: looks like my phone is in this state again | 13:58 |
| Wizzup | the tracker one | 13:58 |
| freemangordon | mine as well | 14:00 |
| Wizzup | when I then run tracker daemon -k, it loses -all- the data | 14:00 |
| freemangordon | but will continue debuggin when have time | 14:00 |
| Wizzup | sigh | 14:00 |
| freemangordon | Wizzup: seems tracker misuses sqlite API | 15:25 |
| freemangordon | they use sqlite3_prepare_v2() and deprecated sqlite3_expired() | 15:26 |
| freemangordon | also, no check is made for the result of sqlite3_reset() | 15:28 |
| sunshavi | perhaps it is old code never updated | 15:33 |
| freemangordon | no, there is a note there | 15:33 |
| sunshavi | mmm | 15:33 |
| sunshavi | what about checking the res of sqlite3_reset(). Does that helps? | 15:38 |
| freemangordon | hehe, that's what I am trying to do now | 15:41 |
| freemangordon | waiting for it to be hit | 15:41 |
| sunshavi | ok. | 15:43 |
| freemangordon | hmm, now sqlite3_step does not return an error | 15:47 |
| freemangordon | it returns SQLITE_ROW | 15:48 |
| sunshavi | according to documentation two alternatives sqlite3_reset | sqlite3_step | 15:54 |
| freemangordon | sunshavi: seems to be uncommitted data | 15:55 |
| sunshavi | then commit first? | 15:56 |
| freemangordon | hmm? | 15:56 |
| sunshavi | or rollback (more context would be needed to reach the right alternative) | 15:56 |
| freemangordon | where? | 15:56 |
| sunshavi | that uncommited data should be flushed? then commit otherwise rollback | 15:57 |
| freemangordon | where? | 15:57 |
| freemangordon | I know what has to be done | 15:57 |
| sunshavi | at which point in the source code commit is going to be hit?. this data never flushes cos commit never happens. is this a kind of daemon?. Yes it is cos it reuses the connection. could I do a clone of this code to see the specific line we are talking about? | 16:08 |
| Wizzup | sunshavi: he's telling you that he knows what you know, but he needs to find the place in the tracker code and find where it is not flushed | 16:08 |
| freemangordon | sunshavi: believe me, I know the theory | 16:09 |
| sunshavi | ok | 16:09 |
| freemangordon | the code in question is tracker | 16:09 |
| freemangordon | no idea where in it the bug is | 16:09 |
| freemangordon | Wizzup: ok, at least one issue - tracker reset -r deletes sqlite db, but mafw never knows about that | 16:16 |
| freemangordon | so it keeps the deleted files openend :) | 16:16 |
| Wizzup | yes that is a problem that I also experience | 16:16 |
| Wizzup | but it's not the cause for our troubles | 16:16 |
| freemangordon | one of them being some file called $something-shm | 16:16 |
| freemangordon | could be | 16:17 |
| freemangordon | but I will try to fix that first | 16:17 |
| Wizzup | I had the trouble occur when mafw source tracker was stopped | 16:17 |
| freemangordon | yes, I know | 16:17 |
| freemangordon | I had it stopped here as well | 16:17 |
| freemangordon | but we have multiple issues | 16:17 |
| freemangordon | anyway, have to run now, bbl | 16:18 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!