--- Log for 09.08.123  Server: erbium.libera.chat  Channel: #rockbox
--- Nick: rb-logbot  Version: Dancer V4.16  Started: 1 month and 13 days ago

00.37.11 Quit    m01 (Quit: Konversation terminated.)
00.39.52 Join    m01 [0] (~quassel@vps-b172b88b.vps.ovh.net)
00.48.51 Quit    _bilgus (Read error: No route to host)
00.49.30 Join    _bilgus [0] (~bilgus@162.154.213.134)
01.07.20 Quit    advcomp2019 (Read error: Connection reset by peer)
01.08.47 Join    advcomp2019 [0] (~advcomp20@user/advcomp2019)
01.49.55 ***     Saving seen data "./dancer.seen"
02.52.18 Quit    pixelma (Quit: .)
02.52.18 Quit    amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
03.22.29 #       <Nyaa> _bilgus, bl808 is probably a better target than esp32
03.23.23 #       <Nyaa> https://wiki.pine64.org/wiki/Ox64
03.25.26 Join    pixelma [0] (marianne@p200300ea870e0e00305e95fffec66ff3.dip0.t-ipconnect.de)
03.25.26 Join    amiconn [0] (jens@p200300ea870e0e00305e95fffec66ff3.dip0.t-ipconnect.de)
03.32.53 #       <Nyaa> also the class d amp is for the haptic feedback engine
03.32.57 #       <Nyaa> in the one you linked
03.33.26 #       <Nyaa> it uses a linear resonance actuator so you could in theory use it as a crappy speaker 
03.34.58 #       <jssfr> _bilgus, wasn't the issue with ESP cores that they have too little ram?
03.36.31 #       <Nyaa> yeah it has 8MB of ram
03.36.37 #       <Nyaa> the bl808 has 64
03.37.31 #       <jssfr> I still have a electrosmith daisy on my shopping list for some rockbox tinkering
03.39.24 #       <Nyaa> neat, BL808 is still better both hardware-wise and cost-wise though lol
03.40.39 #       <Nyaa> [though you would need an I2S DAC if you get a BL808, still cheaper overall than the daisy even including one of those though lol]
03.41.04 #       <jssfr> bl808 is an entirely new architecture tho
03.41.47 #       <Nyaa> yeah, but that also gives an excuse for trimming out a lot of cruft 
03.42.57 #       <jssfr> fair
03.43.14 Join    advcomp2019_ [0] (~advcomp20@user/advcomp2019)
03.43.17 #       <jssfr> then again, I'm not good at analogue stuff, so I'll appreciate a board with good DAC and analogue stages already there.
03.44.05 #       <Nyaa> the I2S bit is digital so you'd only need to pick out a good DAC to pair with it
03.45.13 #       <Nyaa> Wolfson, for example, makes quite a few of those
03.45.54 #       <Nyaa> [though the better a DAC you get, the more expensive it'll b e]
03.46.46 Quit    advcomp2019 (Ping timeout: 256 seconds)
03.47.28 #       <Nyaa> technically cirrus now but yeah
03.49.13 #       <jssfr> right, but the analogue side of the DAC, filters, headphone connectors, stuff like that (I'd go with the daisy pod for experimentation. Even more $$, but has buttons and jacks)
03.49.59 ***     Saving seen data "./dancer.seen"
03.53.10 #       <Nyaa> no idea how the quality is but https://www.amazon.com/dp/B097PZQPMM looks like it would work just fine 
03.55.30 #       <jssfr> hm, interesting idea to use pi addons
03.55.33 #       <jssfr> for i2s
03.55.45 #       <Nyaa> i mean, i2s is i2s, the only thing that makes it pi is the header
03.55.50 #       <jssfr> yep
03.55.55 #       <jssfr> hadn't considered that so far honestly
03.59.35 #       <Nyaa> the only annoying bit with the ox64 is that you need a usb UART/TTL adapter to program it
04.00.04 #       <Nyaa> but if you've done hardware stuff before you probably already have one of those, if not several
04.01.46 #       <jssfr> right
04.02.33 #       <Nyaa> [or a device that has UART]
04.03.50 Quit    CH23_M (Ping timeout: 245 seconds)
04.04.17 Join    CH23_M [0] (~CH23@revspace/participant/ch23)
04.09.38 #       <Nyaa> hmm, yeah SID playback just does not seem to work correctly on ipodvideo
04.17.56 Quit    advcomp2019_ (Ping timeout: 256 seconds)
04.34.43 #       <Nyaa> [at least on the 32MB ram model, not sure about the 64MB one]
05.27.56 #       * Nyaa shrugs
05.28.04 #       <Nyaa> i might as well poke around that voice generation code
05.29.04 #       <Nyaa> speachy, do you know how to use git bundles, i prefer them over plain patches because they preserve pgp signatures on commits [and i somewhat insist that my commits remain signed if merged in]
05.29.24 #       <Nyaa> [they're not difficult to use lol, just a slightly different workflow really]
05.30.20 #       <Nyaa> a git bundle is basically an export of git objects, can be a commit, several commits, or an entire repository 
05.50.03 ***     Saving seen data "./dancer.seen"
05.59.40 Quit    Riviera (Ping timeout: 245 seconds)
06.09.46 Quit    Nyaa (Remote host closed the connection)
06.10.03 Join    Nyaa [0] (Nyaaori@cyberia.club/meow/nyaaori)
06.12.24 Join    Riviera [0] (~Riviera@user/riviera)
07.29.29 Join    user___ [0] (~user@104.238.188.74)
07.50.04 ***     Saving seen data "./dancer.seen"
07.52.57 #       <speachy> I don't know if gerrit supports git bundles as you describe them, and that's what we use for our workflow.
07.55.30 #       <speachy> Nyaa: as for SID, early this year we switched to using cRSID, but there have been other changes that would have hurt performance on slower targets (and older ipods are probably the slowest we support, oddly enough)
07.57.22 #       <speachy> _bilgus: BTW, most of that ESP32's RAM is "PSRAM" ie spi-attached.  So horrid latency.  Also IIRC the hardware is limited to talking to 4MB at a time, so we'd have to bank-switch which is not... ideal.
07.59.24 #       <jssfr> that would also apply to the Ox64 target, right?
07.59.31 #       <jssfr> (the wiki page says "embedded 64MB PSRAM memory"
08.01.42 #       <speachy> I'm not sure exactly what that means.  The ESP32's PSRAM is a separate spi-attached chip, but this might be embedded DRAM that pretends to be SRAM from the system's perspective?
08.02.09 #       <speachy> depends on how it's attached internally. As long as it's not stuck going through an internal serial interface it ought to be ok
08.03.30 #       <speachy> running rockbox as a linux application would be the quickest approach towards something demonstrable.
08.04.00 #       <speachy> (bringing up a new bare metal CPU arch would be a lot of effort)
08.05.19 Quit    __builtin (*.net *.split)
08.05.20 Quit    SammysHP (*.net *.split)
08.05.20 Quit    ParkerR (*.net *.split)
08.05.38 Join    __builtin [0] (~quassel@rockbox/developer/builtin)
08.05.39 Join    SammysHP [0] (~SammysHP@faol.sammyshp.de)
08.05.39 Join    ParkerR [0] (ParkerR@znc.withg.org)
08.06.49 Quit    user___ (Quit: quit)
08.07.09 Join    user___ [0] (~user@104.238.188.74)
08.09.36 #       <speachy> I _think_ it's a SiP approach -- ie the pSRAM is not part of the main die.  (and supposedly you can get it with 32MB flash and 1GB psram)
08.10.15 #       <speachy> I wonder if the radio is usable without a massive binary library running on the main CPU
08.12.41 #       <speachy> huh, 3 cores with wildly different capabilities.
08.15.33 Quit    user___ (Quit: quit)
08.16.24 Join    user___ [0] (~user@104.238.188.74)
08.17.38 #       <speachy> and PSRAM clock is up to 200MHz.  A lot better than the ESP32, but it's still gonna be relatively slow.  It's probably going to end up roughly on par with our higher-end ARM targets.
08.17.56 Quit    Riviera (Ping timeout: 260 seconds)
08.20.00 #       <speachy> BL808 has an onboard audio codec that supports line level output and a 10-band EQ, huh.
08.26.51 #       <speachy> I still think teh Daisy Seed is a better rb port candidate.  :D
08.27.44 Quit    user___ (Quit: quit)
08.31.04 #       <Nyaa> oh yeah i forgot about the built in codec on the BL808
08.35.15 #       * Nyaa tries a build from 1 year ago to see if it doesn't have the SID freezing issue
08.35.44 #       <Nyaa> [that was the newest pre-crsid build the web archive had cached lol]
08.39.25 #       <Nyaa> plays perfectly fine
08.40.35 #       <Nyaa> so, 2021-07-21: sid playback works fine; current: sid playback makes device unusably unresponsive
08.40.59 #       <speachy> it's probably the cRSID change from early 2023.
08.42.13 #       <Nyaa> yeah i see it, that change happened on 2023-02-07
08.42.52 #       <Nyaa> does the second cpu in these ipods get used at all 
08.43.12 #       <Nyaa> [well, second core]
08.48.39 #       <Nyaa> if not than perhaps making the sid playback threaded would fix it
08.51.26 #       <Nyaa> quickest way i could think of doing that which would hopefully not require too major of changes would be to run the audio generation on secondary core and 6502/6510 emulation on primary core
08.55.48 #       <Nyaa> [at least, if I'm remembering correctly, SID playback is similar to NSF playback in that both require being able to execute actual 6502 instructions]
08.56.53 #       * Nyaa looks at the sid playback code
08.57.51 #       <Nyaa> yep, there's a CPU emulation section
08.59.24 #       <Nyaa> it also looks to be pure interpreter which means there are potential optimisations to be made there
09.08.02 #       <Nyaa> guess i'll try to get a local build environment working
09.13.51 #       <Nyaa> [why does the dev environment script try to download ISL twice?]
09.15.33 #       <speachy> don't see why it would even attempt unless you're building multiple toolchains.  and if you are, it'll used a cached copy instead of re-downloading it.
09.16.12 #       <Nyaa> first run, picked ARM, it tried to download ISL twice [though it used the cached copy second time]
09.17.08 #       <Nyaa> binutils => ISL => gcc => GMP => MPFR => MPC => ISL => [building]
09.18.17 #       <speachy> multi-stage GCC build?
09.19.44 #       <Nyaa> uh, no idea, that was the order it downloaded things, all i did was run it and select a to set up the arm version lol
09.20.09 Quit    benjaoming (Quit: ZNC - https://znc.in)
09.20.14 #       <Nyaa> build completed, lets see if it works lol
09.20.26 Join    benjaoming [0] (~benjaomin@37.139.19.237)
09.20.59 #       <Nyaa> [build of the toolchain completed i mean, building rockbox now]
09.21.37 #       <Nyaa> done, time to test if it runs 
09.25.35 #       <Nyaa> takes longer to copy over than it took to build lol
09.28.25 Quit    CH23_M (Ping timeout: 240 seconds)
09.31.06 #       <Nyaa> "ver: rolling" i think it worked lol
09.31.32 Join    CH23_M [0] (~CH23@revspace/participant/ch23)
09.40.22 Quit    CH23_M (Ping timeout: 256 seconds)
09.41.13 Join    CH23_M [0] (~CH23@revspace/participant/ch23)
09.49.27 #       <Nyaa> well, i decided to try building with -O3 instead of -Os just to see if anything would change, and it's no longer unusably unresponsive, but still extremely slow and playback buffer keeps running out
09.50.05 ***     Saving seen data "./dancer.seen"
09.51.10 #       <Nyaa> [honestly i'm surprised it even booted with -O3, was expecting it to immediately crash]
09.56.23 #       <speachy> might be worth compiling just the SID code with -O3
09.56.32 #       <speachy> (or even -O2)
09.57.41 #       <speachy> and lookin at the makefile:  $(CRSID) : CODECFLAGS += -O3
09.57.54 #       <Nyaa> ah, there's different makefiles for each?
09.58.00 #       <Nyaa> does it override the global variable
09.58.26 #       <Nyaa> [what does setting the top level one change? it definitely made a difference, albeit not a big one]
09.58.40 #       <speachy> it's all one invocation but there are nested makefiles lying around for different components
09.59.18 #       <speachy> the top-level change sets teh default, but the codecs in particular usually override that with their own options
09.59.24 #       <Nyaa> oh also lcd-16bit errors saying .rowstart and .nextpixel are already defined when compiled with -O3, for that one thing i had it compile it with -Os
10.00.05 #       <speachy> I have some WIP changes to enable LTO, though it's currently limited to codecs and plugins
10.01.12 #       <Nyaa> which codecs already make use of both cpu cores
10.02.02 #       <speachy> offhand I don't know.  
10.02.12 #       <Nyaa> ah, do you know at least one so i can look at it
10.02.38 #       <speachy> I'd wager the basic mp3 stuff probably is
10.03.10 #       <speachy> we can schedule threads independently regardless, but I don't think many codecs are explicitly multithreaded.
10.06.39 #       <speachy> most of the benefit comes from simply pushing the audio codec to one core and everything else on the other.
10.07.12 #       <Nyaa> hmm, if it was already doing that, why would the interface get unresponsive
10.07.40 #       <speachy> our OS/scheduling is quite primitive.  :)
10.08.11 Quit    CH23_M (Read error: Connection reset by peer)
10.08.48 Join    CH23_M [0] (~CH23@revspace/participant/ch23)
10.10.01 #       <speachy> for the most part higher optimizations simply make the code too _large_, rather than exposing latent bugs/crashes.
10.11.29 #       <Nyaa> hm, makes sense, though probably depends on target too
10.12.09 #       <Nyaa> also given how old the compiler is, i would probably blame any optimisation crashes on the toolchain lol
10.12.25 #       <speachy> by this point the codebase is pretty free of that stuff, especially as we use bleeding-edge toolchains on the sim targets which cover most of the codebase.
10.12.37 #       <Nyaa> ahh, well that makes sense 
10.13.05 Quit    CH23_M (Read error: Connection reset by peer)
10.13.47 Join    CH23_M [0] (~CH23@revspace/participant/ch23)
10.15.01 #       <Nyaa> if a good chunk of the codebase already works on newer toolchains, what prevents bumping to something newer than the nearly 10 year old gcc 4.9 series :p
10.17.55 Quit    CH23_M (Ping timeout: 240 seconds)
10.18.16 Join    CH23_M [0] (~CH23@revspace/participant/ch23)
10.56.50 Join    Riviera [0] (~Riviera@user/riviera)
11.13.03 #       <speachy> all the target-specific stuff, of course.  Or rather, _testing_ that stuff out.
11.13.26 #       <Nyaa> looks like the answer to that is: nothing, at least for ipodvideo
11.13.34 #       <speachy> bringing everything up to 4.9 (from a 4.0, 4.4, and 4.5) was quite an ordeal.
11.13.34 #       <Nyaa> i built it with gcc 13.2.0 and it seems fine 
11.13.57 #       <speachy> we do some tweaks to the arm toolchain (mainly along the lines of disabling exceptions in builtin code)
11.14.21 #       <Nyaa> unless there's more shenanigans going on with the build script and it mixed 13.2.0 and 4.9.4 somehow 
11.14.36 #       <speachy> I have a bump to 8.5 ready to go, still some lingering warnings.
11.14.52 #       <Nyaa> i did have to add -fcommon to get it to build due to headers not using `extern` but other than that it built fine
11.15.15 #       <speachy> the biggest hiccup is usually binutils, or rather, the linker. we have some pretty horrid stuff going on in our linker scripts.
11.17.54 #       <speachy> I haven't been able to get anyone with an m68k or hosted arm target to smoke test my gcc8 builds.
11.20.14 Quit    jacobk (Read error: Connection reset by peer)
11.36.07 Join    jacobk [0] (~quassel@47.189.170.32)
11.49.28 Quit    othello7 (Remote host closed the connection)
11.50.08 ***     Saving seen data "./dancer.seen"
11.51.01 Join    othello7 [0] (~Thunderbi@pool-100-36-166-8.washdc.fios.verizon.net)
12.29.31 #       <Nyaa> hmm, i don't think i have any devices that fall under that lol
12.29.48 #       <Nyaa> how were the optimisation levels for each codec picked btw
12.29.51 Join    advcomp2019 [0] (~advcomp20@user/advcomp2019)
12.30.58 #       <Nyaa> i tried -Ofast on a few and they seem to work fine lol
12.35.31 #       <speachy> -Ofast is probably most relevant for floating point stuff
12.36.15 #       <speachy> codec optimization was about balancing code size (ie "make it fit") with performance ("make it run fast enough")
12.36.37 #       <speachy> larger code sizes often made things _slower_ due to hot codepaths not fitting in caches or things like that.
12.36.56 #       <speachy> those flags probably _way_ predate even GCC4 toolchains fwiw.
12.41.48 #       <Nyaa> yeah, makes sense, i guess setting them to most optimal would be a per-target thing too 
12.56.57 #       <speachy> there's some of that too
13.09.07 #       <speachy> there's a codec benchmark tool, that was used to tune things
13.16.37 #       <Nyaa> apparently ipodvideo can drain battery faster than it charges
13.16.47 #       <Nyaa> at least on usb
13.17.17 #       <Nyaa> and i don't have one of those funny firewire charging cables 
13.21.25 #       <Nyaa> hmmm "rating: 5-30V"
13.21.36 #       <Nyaa> usb power delivery to firewire power cable when lol
13.23.28 #       <speachy> that's pretty common
13.38.01 Quit    CH23_M (Read error: Connection reset by peer)
13.38.24 Join    CH23_M [0] (~CH23@revspace/participant/ch23)
13.42.37 Quit    CH23_M (Ping timeout: 246 seconds)
13.43.12 Join    CH23_M [0] (~CH23@revspace/participant/ch23)
13.45.37 Quit    CH23_M (Read error: Connection reset by peer)
13.47.14 Join    CH23_M [0] (~CH23@revspace/participant/ch23)
13.50.12 ***     Saving seen data "./dancer.seen"
14.04.48 Join    lebellium [0] (~lebellium@2a01cb040610e000587e05d9ef49104d.ipv6.abo.wanadoo.fr)
14.23.55 Quit    CH23_M (Read error: Connection reset by peer)
14.24.16 Join    CH23_M [0] (~CH23@revspace/participant/ch23)
15.50.16 ***     Saving seen data "./dancer.seen"
15.50.22 #       <Nyaa> turns out i had to set charge on usb to force instead of on
15.51.09 #       <braewoods_> nyaa: perhaps the device supports USB BCS but the charger or usb port doesn't?
15.54.06 #       <Nyaa> an 18 year old ipod? i kinda doubt it would support something that was released 2 years after it was :p
15.55.34 #       <speachy> it's realistically going to take a "PC" or at least something that can negotiate USB descriptors, or get limited to 200ma charging.
15.55.43 #       <braewoods_> 500ma you mean?
15.55.44 #       <Nyaa> 500ma* 
15.55.49 #       <Nyaa> it's a 2.0 device not a 1.0 device
15.56.07 #       <braewoods_> 500ma was the limit for 1.0 too, afaik it didn't increase until 3.0, BCS, and more came out.
15.56.21 #       <Nyaa> oh i thought 1.1 was what bumped the limit to 500
15.56.43 #       <Nyaa> tbf you never see 1.0 in like anything lol
15.57.03 #       <speachy> correction; it's 100 ma max without some sort of negotiation.
15.57.24 #       <braewoods_> i was referring to the maximum allowed under early USB
15.57.39 #       <speachy> usb 1.x maxed out at 500ma, yes.
15.57.54 #       <braewoods_> same with 2.0, until it was extended with BCS and more.
15.58.04 #       <braewoods_> allowing up to 1500
15.58.43 #       <braewoods_> it's kinda funny to find USB to barrel jack cables today that can do voltage negotiation.
16.00.58 #       <Nyaa> lol
16.01.27 #       <braewoods_> based on QC or PD.
16.01.43 #       <Nyaa> who even uses QC anymore now that PD has been out for a while 
16.02.03 #       <braewoods_> you'd be surprised. a lot of stuff is still QC only.
16.02.14 #       <Nyaa> plus the EU mandates PD after 2024 :p
16.02.21 #       <braewoods_> it tends to be compatible with QC anyway to a degree.
16.02.35 #       <braewoods_> or maybe devices just support both.
16.02.54 #       <Nyaa> oh, i think i heard that the most recent QC spec is literally just PD but with like, one thing added that i doubt anyone uses lol
16.04.06 #       <braewoods_> speachy, any ideas how to calculate surge current from farads?
16.04.28 #       <Nyaa> don't you need to know the internal resistance too
16.05.31 #       <braewoods_> probably. i was trying to figure out the surge current for a buck converter's input capacitor for finding a suitable switch, or is surge current not an issue for mechanical switches?
16.08.33 #       <Nyaa> you should be able to just use ohm's law to find out the absolute maximum current it can release, voltage / internal resistance = maximum current
16.09.10 #       <braewoods_> which is likely to be super high, given it is a dc power converter
16.09.54 #       <braewoods_> the circuit voltage on the input ranges from like 20v to 30v.
16.14.07 #       <Nyaa> for say, a 24v ceramic capacitor, peak output current would be around 1600 amps
16.14.37 #       <Nyaa> though ceramic capacitors tend to not have very much charge capacity, so you're looking at fractions of a millisecond there 
16.15.37 #       <braewoods_> From what i'm reading the buck converter i was considering uses... "A 100 F, 50 V aluminium electrolytic capacitor located near
16.15.37 #       <braewoods_> the input and ground pin provides sufficient bypassing."
16.16.01 #       <braewoods_> sorry, uF (some fancy u)
16.16.06 #       <Nyaa> µ
16.16.18 #       <braewoods_> microfarads
16.16.26 #       <Nyaa> aluminium?
16.16.31 #       <braewoods_> yea that's what it says
16.18.30 #       <Nyaa> those tend to have 2-7 ohms ESR so 7-25 amps 
16.18.44 #       <Nyaa> [at least for charging it]
16.19.44 #       <Nyaa> if it's a low-ESR one, than 0.3-1.6 ohms are typical, so 31-167 amps
16.20.16 #       <braewoods_> so probably nothing to fret about in terms of the initial arcing that occurs
16.20.45 #       <Nyaa> can you see what model of capacitor it uses
16.20.49 #       <braewoods_> for my inverters i prime the capacitors with a strong resistor before connecting the battery directly...
16.20.50 #       <Nyaa> would be easier to just look up a datasheet 
16.20.57 #       <braewoods_> unfortunately not at present
16.21.33 #       <Nyaa> switching power supplies tend to use low-ESR ones for their higher output 
16.21.51 #       <Nyaa> more specifically, better ability to handle current ripples 
16.22.12 #       <braewoods_> does that matter if the input supply is a battery?
16.22.32 #       <Nyaa> is the output A/C?
16.22.53 #       <braewoods_> No. In this case it's a LM2596 board.
16.22.59 #       <braewoods_> a dc to dc buck converter
16.23.06 #       <Nyaa> ah, in that case i don't think so
16.24.06 #       <braewoods_> i'm working on a battery project which has a box with integrated LED strip that is designed to run off 12v range directly but i wanted to install 24v battery.
16.24.24 #       <Nyaa> tbf generally it doesn't hurt to use overrated capacitors 
16.24.27 #       <braewoods_> only reason i'm considering a power converter.
16.24.56 #       <braewoods_> the higher voltage would probably cause too much current to flow otherwise
16.25.45 #       <braewoods_> the other option is to build a voltage divider circuit to cut it in half roughly
16.25.58 #       <braewoods_> but that is probably harder to do and more limited
16.29.30 #       <Nyaa> capacitors are weird 
16.32.37 #       <Nyaa> but anyway if you're worried about accidentally spot welding contacts together, low-ESR 100µF aluminium electrolytic capacitors can definitely do that
16.35.04 #       <Nyaa> [though given how short lived the current spike is, the contacts usually don't stick too hard]
16.45.04 #       <braewoods_> i may just use a thermistor
16.45.43 #       <braewoods_> its resistance varies and can be used to deal with surge currents
16.45.57 #       <braewoods_> slows down the capacitor charging
16.46.09 #       <braewoods_> then returns to a more normal level
17.10.49 #       <Nyaa> so it turns out that it is indeed the cpu emulation part of sid playback that's the problem 
17.11.18 #       <Nyaa> running it at 1/10th the clockrate runs just fine
17.11.31 #       <Nyaa> that said, it's also 10x slower lol
17.50.17 ***     No seen item changed, no save performed.
18.03.47 Quit    lebellium (Quit: Leaving)
18.50.19 Quit    danwellby (Quit: Watch out For sysops carrying carpet and quicklime)
18.51.22 Join    danwellby [0] (~danwellby@cynthiajndevey.plus.com)
18.52.41 Join    massiveH [0] (~massiveH@2600:4040:a982:c800:27f2:68af:c6b:c898)
19.46.20 Quit    Schimon (Ping timeout: 245 seconds)
19.50.19 ***     Saving seen data "./dancer.seen"
19.51.08 Quit    jacobk (Ping timeout: 252 seconds)
19.51.44 Join    jacobk [0] (~quassel@47.189.170.32)
20.27.00 Quit    speachy (Quit: WeeChat 3.6)
20.29.46 Quit    jacobk (Ping timeout: 256 seconds)
21.31.34 Join    jacobk [0] (~quassel@47.189.170.32)
21.49.23 Quit    massiveH (Quit: Leaving)
21.50.20 ***     Saving seen data "./dancer.seen"
23.50.23 ***     No seen item changed, no save performed.