--- Log for 25.02.122 Server: molybdenum.libera.chat Channel: #rockbox --- Nick: rb-logbot Version: Dancer V4.16 Started: 18 days and 18 hours ago 00.48.38 *** No seen item changed, no save performed. 01.02.37 # why would a sid emulator need floating point? the commodore 64 didn't even have one. 01.02.48 # HW wise 02.40.15 Quit nihilazo (Ping timeout: 256 seconds) 02.40.30 Join nihilazo [0] (~nihilazo@tilde.town) 02.48.40 *** Saving seen data "./dancer.seen" 04.29.06 Join megamaced [0] (~megamaced@static-90-255-226-34.vodafonexdsl.co.uk) 04.48.41 *** No seen item changed, no save performed. 05.03.14 # braewoods: maybe because the SID is an analog synthesis chip? :) 06.48.42 *** No seen item changed, no save performed. 07.52.30 Join massiveH [0] (~massiveH@ool-4a5862ee.dyn.optonline.net) 07.55.38 Quit koniu (Ping timeout: 252 seconds) 08.09.55 Join koniu [0] (~koniu@cpc107003-dals23-2-0-cust91.20-2.cable.virginm.net) 08.48.43 *** Saving seen data "./dancer.seen" 08.53.47 Quit massiveH (Quit: Leaving) 10.47.11 Join ac_laptop [0] (~ac_laptop@2001:910:107e:1:56ee:75ff:fe00:97ac) 10.48.46 *** Saving seen data "./dancer.seen" 10.59.42 # why would one not want to tag their music but use the database? If you don't use tags simply don't use the database. There's still the file browser ... 11.29.05 Quit ac_laptop (Quit: WeeChat 3.4) 11.57.43 Join bilgus_ph [0] (~bilgus_ph@172.58.190.142) 11.59.12 # Bluebrother, trying it out its v. Annoying to have UNTAGGED in the tracks list and try to browse through 12.01.48 # G#4247 should help in all the menus 12.04.42 # Your namesake must be missing https://gerrit.rockbox.org/r/c/rockbox/+/4247 12.06.58 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:9427:c7d8:fb6f:7258) 12.09.02 Quit bilgus_ph (Quit: Connection closed) 12.11.17 Quit ZincAlloy (Ping timeout: 240 seconds) 12.42.33 Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) 12.48.47 *** Saving seen data "./dancer.seen" 13.04.45 Quit megamaced (Quit: megamaced) 13.12.25 Join lebellium [0] (~lebellium@2a01cb04012c0900607828298b87e765.ipv6.abo.wanadoo.fr) 13.32.25 Quit ufdm (Remote host closed the connection) 13.32.57 Join ufdm [0] (~ufdm@c-68-46-16-107.hsd1.mn.comcast.net) 13.35.12 Quit ufdm (Read error: Connection reset by peer) 13.38.54 Join ufdm [0] (~ufdm@c-68-46-16-107.hsd1.mn.comcast.net) 14.07.01 Quit speachy (Read error: Connection reset by peer) 14.12.40 Join speachy [0] (~speachy@172.109.154.42) 14.12.40 Quit speachy (Changing host) 14.12.40 Join speachy [0] (~speachy@rockbox/developer/speachy) 14.12.40 Mode "#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat) 14.48.51 *** Saving seen data "./dancer.seen" 15.51.51 Quit Bobathan_ (Quit: ZNC 1.8.2+deb2+b1 - https://znc.in) 15.53.59 Join Bobathan [0] (~admin@cpe-65-29-248-157.wi.res.rr.com) 16.00.02 Quit speachy (Quit: WeeChat 3.4) 16.48.52 *** Saving seen data "./dancer.seen" 17.21.17 Quit rogeliodh (Quit: The Lounge - https://thelounge.chat) 17.21.41 Join rogeliodh [0] (~rogeliodh@rogeliodh.dev) 17.31.18 Quit lebellium (Quit: Leaving) 18.09.34 Quit ZincAlloy (Quit: Leaving.) 18.17.28 # <_bilgus> I dont't see how this ever worked https://github.com/Rockbox/rockbox/commit/6a24a7a90363bfbf4c5a0be0585da425506adfab#diff-cf1e6d4dfc52739b33cd6065c7a0bbb5c9c5e736ee403a9fc801f2a53e41bcbfR1386 18.18.49 # <_bilgus> ok so the clause is dependent on the same tag so we use the already defined filter? 18.19.25 # <_bilgus> but how does that get our match? well clearly it doesn't BUT.. 18.48.53 *** Saving seen data "./dancer.seen" 19.18.05 Join massiveH [0] (~massiveH@ool-4a5862ee.dyn.optonline.net) 20.35.10 # <_bilgus> so far I have, clauses are added by saving a tag, clause type, navifileoffset 20.36.37 # <_bilgus> those are (atleast for non numeric tags) later turned into a filter which is indexed to a databasefile (0-10) 20.37.32 # <_bilgus> so filters are a tag and the file descriptor of the databasefile 20.48.54 *** No seen item changed, no save performed. 21.29.42 # <_bilgus> SO It appears that the logical OR is not carried over to filters and it then gets applied to whatever the next valid clause 21.31.45 # <_bilgus> then you get the filtered items (which works) but the OR gets applied to the next clause and it causes weird things 21.32.31 # <_bilgus> Problem is I'm not sure how to decide to eliminate that OR (maybe if the clause prior is a filter and after is a filter? but then I need to keep state 21.33.07 # <_bilgus> I think maybe the better idea is to just keep all clauses in the case of an OR 21.33.23 # <_bilgus> it'll be slower but at least it'll be correct 22.05.00 # <_bilgus> https://gerrit.rockbox.org/r/c/rockbox/+/4248 Tagcache Don't create filters when parsing a logical OR 22.34.41 # <_bilgus> I guess that should be Don't reuse filters since they still get made into filters 22.48.56 *** No seen item changed, no save performed. 23.06.04 Quit massiveH (Quit: Leaving)