--- Log for 11.03.121 Server: beckett.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 5 days and 8 hours ago 00.00.43 # i may end up in a situation where i only allow file transfers when i know rockbox is idle 00.01.50 # MTP is mainly for file transfer but it would still be nice to be able to do other stuff with it too or even while playing music 00.09.29 Join advcomp2019__ [0] (~advcomp20@unaffiliated/advcomp2019) 00.12.31 Quit advcomp2019_ (Ping timeout: 256 seconds) 00.14.42 Quit ac_laptop (Ping timeout: 246 seconds) 00.44.07 # <_bilgus> braewoods no clue we do have storage is idle events 00.47.48 Quit pixelma (Read error: Connection reset by peer) 00.47.48 Quit amiconn (Read error: Connection reset by peer) 00.47.57 Join pixelma_ [0] (marianne@rockbox/staff/pixelma) 00.47.57 Join amiconn_ [0] (jens@rockbox/developer/amiconn) 00.47.57 Nick pixelma_ is now known as pixelma (marianne@rockbox/staff/pixelma) 00.47.57 Nick amiconn_ is now known as amiconn (jens@rockbox/developer/amiconn) 01.02.13 Quit pixelma (Quit: .) 01.02.13 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 01.05.10 Join amiconn [0] (jens@rockbox/developer/amiconn) 01.05.11 Join pixelma [0] (marianne@rockbox/staff/pixelma) 01.18.09 Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) 01.20.29 *** Saving seen data "./dancer.seen" 01.24.21 Quit Rower (Ping timeout: 246 seconds) 02.03.11 Join bonfire_ [0] (~bonfire@c-24-2-109-9.hsd1.ut.comcast.net) 02.05.18 Quit bonfire (Ping timeout: 260 seconds) 02.26.18 Quit emacsomancer (Ping timeout: 260 seconds) 02.30.04 Join emacsomancer [0] (~runner@c-174-52-88-123.hsd1.ut.comcast.net) 02.43.47 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 02.43.47 Quit pixelma (Quit: .) 02.44.03 Join amiconn [0] (jens@rockbox/developer/amiconn) 02.44.04 Join pixelma [0] (marianne@rockbox/staff/pixelma) 03.15.48 # speachy: how does USB handle data? does it wait to send more until the past data was processed? 03.15.56 Join eevan_ [0] (~eevan@telesto.hot-chilli.net) 03.20.33 *** Saving seen data "./dancer.seen" 03.57.50 Quit koniu (Ping timeout: 268 seconds) 04.07.58 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) 04.08.57 Quit emacsomancer (Ping timeout: 264 seconds) 04.09.43 Join vmx [0] (~vmx@ip5f5ac61f.dynamic.kabel-deutschland.de) 04.11.21 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 04.15.47 Quit berber (Quit: The Lounge - https://thelounge.chat) 04.16.11 Join berber [0] (~berber@v2202101107577140883.nicesrv.de) 04.22.16 Join emacsomancer [0] (~runner@c-174-52-88-123.hsd1.ut.comcast.net) 04.33.01 Nick gevaerts_ is now known as gevaerts (~fg@rockbox/developer/gevaerts) 04.42.43 Join eevan57 [0] (5e3b35b3@94.59.53.179) 04.43.50 Quit eevan57 (Client Quit) 04.47.39 Part eevan_ 04.48.09 Join eevan [0] (~eevan@telesto.hot-chilli.net) 04.48.32 Nick eevan is now known as Guest39193 (~eevan@telesto.hot-chilli.net) 04.56.09 Part Guest39193 04.58.26 # braewoods: from rockbox's perspective, the host is control of everything. 04.59.22 # it's request-driven; host says it's sending or expecting X, set up a transfer to achieve that. 05.00.12 # each given endpoint can only have one open transaction at a time. 05.01.32 # now if the higher-level protocol allows muxing multiple streams/operations simultaneously, that's up to that layer, but at the "USB" layer, it's "transfer X bytes to/from endpoint Y, block/callback when complete." 05.20.34 *** Saving seen data "./dancer.seen" 05.23.18 Quit bertrik (Quit: Lost terminal) 05.23.37 # so an MTP implementation will only interact with the USB stack in three places; the initial descriptor specification (ie defining the endpoints), registering the callback for traffic received on a given endpoint, and sending data to a given endpoint. 05.25.16 # and on the other side of the MTP implementation, you'll have a pile of hooks into the filesystem code, eg getting directory listings, reading/writing [chunks of] a given file, and perhaps other stuff like deleting. 05.25.58 # the stuff in the middle doesn't otherwise care about rockbox, beyond standard OS helper functions like malloc/memcmp and so forth. 05.28.10 # I'd recommend that MTP be treated the same as MSC initially, in that it get exclusive modal access to the disk -- ie playback etc is halted. Otherwise one has to worry about altering stuff that's actively playing, and that's complexity that isn't worth it at this stage. 05.28.57 # (not to mention the greatly inreased potential for running out of RAM) 05.29.10 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 05.33.54 # speachy: i see. ok. 05.35.27 # i'm also planning to investigate the possibility of disabling file access through MTP so the rest of the stateless protocol can still function perhaps 05.35.51 # so it might still be possible to remotely control rockbox 05.35.58 # just not transfer files 05.36.26 # i don't know, just some ideas i've had 05.36.43 # unless you know of a better USB method for controlling rockbox remotely 05.38.04 # though to be honest... mtp reminds me a lot of HTTP from reading the spec 05.38.28 # server (responder) can't send data to the client (initiator) unti the client acts 05.40.01 # there's always bluetooth's AVRCP! 05.46.05 # speachy: can you investigate the possibility of enabling the HID driver in charging only mode? 05.46.26 # so it can still report battery levels 05.46.30 # in the background 05.47.36 # sure, that just needs the UI to allow the user to select between mass storage+everything, full HID, HID status only, and charge only. 05.48.23 # truth be told, we can't enable all drivers at all times due to endpoint limitations 05.48.36 # MTP is pretty much going to be on its own 05.48.42 # for many devices 05.48.48 # since it'll use up all the endpoints for itself 05.48.57 # it requires 3 to be recognized as an MTP device 05.49.05 # even though it only really uses 2 05.49.08 # what's up with that 05.50.12 # right now chargeonly means just that, no endpoitns advertised. 05.50.27 # and the charge state is visible on-screen 05.51.47 # the HID implementation is all-in, either it's active (and owning the UI) or it's not. charge-status-only requires that to be split up/rejiggered. 05.52.16 # I see. 05.52.26 # well given the design of the HID driver 05.52.29 # so that's the place to start -- we already have "hid mode" as an option 05.52.41 # we could just enable it and not use the other input reports 05.52.45 Join advcomp2019_ [0] (~advcomp20@65-131-179-208.sxct.qwest.net) 05.52.45 Quit advcomp2019_ (Changing host) 05.52.45 Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) 05.53.00 # since the background reports are sent on demand now by the host 05.53.02 # patches welcome.. 05.53.11 # it's all possible 05.53.14 # i'll look into it later 05.53.20 # right now got a mor important project 05.53.32 # i would rather review this once we got some more usable drivers 05.53.50 # i'm planning to have two modes of operation for MTP if i can pull this off 05.54.04 # one that mainly allows file transfer, exclusive mode 05.54.15 # and shared mode or so which allows (in theory) remote control 05.54.29 # but still got code to write 05.55.54 Quit advcomp2019__ (Ping timeout: 245 seconds) 05.56.51 # speachy: what's the recommended way of unpacking byte packed data? a packed struct? or manually extracting it from the data stream in a regular struct? 05.57.00 # i know packed structs have penalties for alignment. 05.57.41 # packed structure is preferable, but only works when the struct is a fixed size and known in advance. 05.58.10 # ok. 05.58.11 # structs with variable length elements (especially ones in the middle!) mean you pretty much have to parse it field-by-field 05.58.21 # i rarely use packed structs so i wasn't really sure. 05.58.24 # but i've seen both methods 05.58.33 # for USB etc transfers we can ensure operations are properly aligned (for DMA purposes) 06.00.17 # i think i'll start with adding MTP support for basic stateless stuff that is viable in any mode of use 06.00.33 # mostly to test that my code is working 06.01.13 # speachy: does RB already do sufficient buffering in its file IO APIs? 06.01.31 # or will i need one for MTP to buffer the USB data until there's enough to flush to disk? 06.02.17 # MTP has overhead granted but i would like to try to make it efficient if i can 06.20.04 # I guess that depends on the max size of an individual MTP request. 06.21.11 # the USB stack won't notify the upper layer that a transfer is complete until the entire operation is finished, so you'll need to buffer that much at a time, both reading and writing. 06.22.05 # but I'd be surprised if MTP mandated support for transfer sizes over 64K. Heck, I'd be surprised if it mandated even 4K minimums. 06.22.21 Join tomato [0] (t0mato@gateway/vpn/mullvad/tomato) 06.44.33 # speachy: going by what android does to expose itself as MTP... 06.44.47 # i think i need to add an interface string to rockbox's usb core. 06.45.04 # most of the libmtp examples use these 06.45.09 # android just exposes an MTP string 06.45.27 # seems mandatory to placate libmtp too 06.45.53 # i think i will copy what android does to get hosts to recognize it as MTP 06.46.57 # "interface string" meaning an USB interface containing endpoints, described in 06.47.03 # ..in the descriptor? :D 06.48.05 # meaning iInterface isn't set to 0 06.48.14 # yep. 06.48.30 # in any case 06.48.39 # it's a trivial change 06.48.54 # just trying to solve our MTP by starting from the foundation 06.49.07 # start with that patch already in gerrit, seriously.. 06.49.07 # i plan to work on basic crapola first and test hat 06.49.20 # which one? 06.49.20 # it'll save a ton of boilerplate if nothing else. 06.49.38 # i'm probably already referencing it 06.50.12 # but i'm gradually implementing this piecemeal to help me learn stuff 06.50.39 # whoops, I meant flyspray 06.50.40 # https://www.rockbox.org/tracker/task/10764 06.50.55 # I even rebased it vs master-as-of-sep-2020 06.51.30 # or, er, no, just squashed everything to make it easier to rebase 06.52.04 # yea, i'm already using that as a reference point 06.52.23 # i just noticed the original author couldn't decide how to expose MTP to the host 06.52.38 # and times have changed; windows vista and such are no longer relevant 06.52.53 # so we can probably copy android's technique for it and call it a day 06.53.25 # "android's technique" is inherently tied to the patched android linux kernel. 06.53.45 # is it? i thought their MTP was implemented in user space 06.54.08 # it's exposed via the usbgadget stuff 06.54.37 # indeed but it seems the interface descriptor is done in userspace in any case 06.54.48 # under linux's hood, it works out more or less the same way as this patch -- adding stuff into the usb configuration descriptors 06.54.58 # in any case 06.55.21 # i need to decide on how we'll expose MTP's existence and there's only a few ways to do so where libmtp will even notice it 06.55.47 # hardcode it. 06.56.25 # i know... 06.56.33 # i'll have to, but which set of values? 06.56.37 # adding in config options and spllicing descriptors on the fly is something you do afer your get the hard stuff done. 06.56.47 # i wasn't planning to do that 06.56.51 # lol 06.57.03 # i was planning to find a single static set to use and leave it at that 06.57.17 # assuming that'll even work in reality 06.57.52 # (and "Vista" might not matter, but Win10 surely does, and most rockbox users are using Windows) 06.58.22 # interesting, umtp responder uses the PTP method 06.58.51 # (there's MTP-as-specified, and MTP-as-the-dominant-client-OSes-implement-it) 06.59.09 # i'm probably going to lean towards the right 07.01.45 # there's no realistic alternative if you want the code to be useful. 07.02.29 # that was one of the original reasons why that patch was left fallow 07.02.59 # indeed and which is why i only intend to do a partial implementation initially 07.03.07 # mostly to prototype how it works under Linux and such 07.03.20 # see what compatibility issues i might run into 07.03.42 # well, from what i've gathred from existing responders 07.04.01 # Android does this approach. it sets 255, 255, 0 for the typical interface class/ protocol / ... 07.04.04 # family 07.04.11 # the other responders do 6 1 1 07.04.37 # both set an interface string containing MTP 07.05.19 # which i believe was missing from the original 07.06.23 # indeed it was 07.08.25 Join eevan_ [0] (~eevan@telesto.hot-chilli.net) 07.08.48 Quit koniu (Remote host closed the connection) 07.09.16 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 07.10.38 # https://github.com/viveris/uMTP-Responder/issues/16 07.10.39 # interesting 07.10.55 # but not too important for RB since the host is the one that is going to do all the updating 07.20.35 *** Saving seen data "./dancer.seen" 07.22.59 Quit tomato (Quit: Ping timeout (120 seconds)) 07.25.22 Part eevan_ 07.43.13 Join tomato [0] (t0mato@gateway/vpn/mullvad/tomato) 07.47.11 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-c0bc-866c-59bc-4ed4.res6.spectrum.com) 07.50.23 # it's quite sad how many bluetooth stacks were aquired by qualcomm and eventually kille 08.02.14 Join _bilgus_ [0] (~bilgus@cpe-107-11-237-184.columbus.res.rr.com) 08.03.40 Join spectrumanalyst [0] (~admin@198.46.152.45) 08.05.19 Join fs-bluebot_ [0] (~fs-bluebo@55d4a316.access.ecotel.net) 08.05.37 Join vmx_ [0] (~vmx@ip5f5ac61f.dynamic.kabel-deutschland.de) 08.05.53 Quit ps-auxw (Disconnected by services) 08.06.01 Join ps-auxw [0] (~arneb@p548d56ce.dip0.t-ipconnect.de) 08.06.17 Join Ckatt [0] (~Ckat@xn--z7x.xn--6frz82g) 08.06.56 Join SovietShaman [0] (quassel@024-217-039-226.res.spectrum.com) 08.07.05 Join Strife89|Home [0] (~quassel@adsl-74-250-153-79.ags.bellsouth.net) 08.07.15 Join gsora_ [0] (~gsora@unaffiliated/gsora) 08.07.27 Join shrizza_ [0] (~shrizza@oki-180-131-209-187.jptransit.net) 08.07.35 Quit spectrum- (Ping timeout: 256 seconds) 08.07.35 Quit gsora (Ping timeout: 256 seconds) 08.07.35 Quit _bilgus (Ping timeout: 256 seconds) 08.07.36 Quit vmx (Ping timeout: 256 seconds) 08.07.36 Quit SovietShaman__ (Ping timeout: 256 seconds) 08.07.36 Quit vup (Ping timeout: 256 seconds) 08.07.36 Quit asabas (Ping timeout: 256 seconds) 08.07.36 Quit Strife89 (Ping timeout: 256 seconds) 08.07.36 Quit fs-bluebot (Ping timeout: 256 seconds) 08.07.36 Quit beencubed (Ping timeout: 256 seconds) 08.07.36 Quit shrizza (Ping timeout: 256 seconds) 08.07.36 Quit Ckat (Ping timeout: 256 seconds) 08.07.37 Join asaba [0] (~asaba@103.113.159.184) 08.07.38 Join beencubed_ [0] (~beencubed@209.131.238.248) 08.07.48 Nick Ckatt is now known as Ckat (~Ckat@xn--z7x.xn--6frz82g) 08.08.09 Join vup [0] (~~~~@46.101.193.235) 08.18.39 Quit tomato (Quit: Ping timeout (120 seconds)) 08.18.54 Join tomato [0] (t0mato@gateway/vpn/mullvad/tomato) 08.19.52 Quit Romster (Ping timeout: 276 seconds) 08.38.39 Join mendelmunkis [0] (~mendelmun@ool-43568247.dyn.optonline.net) 08.40.37 Join Romster [0] (~romster@unaffiliated/romster) 08.41.40 Quit ender| (Read error: No route to host) 08.41.46 Join MrZeus_ [0] (~MrZeus@89.238.130.71) 08.43.22 Quit tomato (Quit: Ping timeout (120 seconds)) 08.46.13 Join ender| [0] (~ender1@2a01:260:4094:1:6045:6fff:fedd:cbf3) 08.47.08 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach) 08.48.52 Join ubervison [0] (~ubervison@2a02:aa12:b106:1b80:4978:337a:24bd:4bbc) 08.51.17 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 09.03.32 Join tomato [0] (t0mato@gateway/vpn/mullvad/tomato) 09.12.02 Quit Saijin_Naib (Ping timeout: 264 seconds) 09.20.39 *** Saving seen data "./dancer.seen" 09.23.44 Quit bonfire_ (Quit: Leaving) 09.31.31 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-c0bc-866c-59bc-4ed4.res6.spectrum.com) 10.00.49 Quit Saijin_Naib (Disconnected by services) 10.00.53 Join Saijin-Naib [0] (~Saijin_Na@2603-7081-1d05-7230-f87d-7b09-3f64-97aa.res6.spectrum.com) 10.01.26 Quit vmx_ (Quit: Leaving) 10.10.22 Quit tomato (Quit: Ping timeout (120 seconds)) 10.20.40 Join tomato [0] (t0mato@gateway/vpn/mullvad/tomato) 10.27.53 Quit ubervison (Quit: Leaving) 10.33.59 Quit tomato (Quit: Ping timeout (120 seconds)) 10.37.31 Quit massiveH (Quit: Leaving) 10.54.10 Quit Huntereb (Quit: See ya!) 10.55.33 Join Huntereb [0] (~Huntereb@2603:9001:5a04:bbe7:21e:37ff:fe4e:f43a) 11.03.23 Quit pamaury (Ping timeout: 265 seconds) 11.20.41 *** Saving seen data "./dancer.seen" 11.40.07 Join amachronic [0] (5284b902@82.132.185.2) 11.45.11 # can anyone tell me what happens to the volume if you divide a PCM sample by 2, in terms of dB? I am pretty much a noob at this stuff & after some googling, I'm thinking it should only reduce volume by ~0.5 dB, but I'm not sure I'm doing my math right. Thanks. 11.46.49 # whoops, my mistake... I mean ~5 dB 12.00.26 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 12.41.55 Quit amachronic (Quit: Connection closed) 12.48.27 Quit jdarnley (Ping timeout: 256 seconds) 12.49.19 Join J_Darnley [0] (~J_Darnley@d51a44418.access.telenet.be) 12.56.59 # amiconn: /2 = 3dB, I'd think. 13.05.25 # Yes 13.13.14 Quit Saijin-Naib (Ping timeout: 264 seconds) 13.20.43 *** Saving seen data "./dancer.seen" 13.34.10 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-f87d-7b09-3f64-97aa.res6.spectrum.com) 13.40.31 # <__builtin> amachronic (logs): 10 log(0.5) ~= -3 dB 13.53.31 Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) 13.57.42 # Halving the amplitude means -6 dB 13.58.37 # For power it's 10 * log(), but for amplitude it's 20 * log() 13.59.23 # (this is of course in order to match, because power is proportional to amplitude^2 14.13.44 Quit edhelas_ (Remote host closed the connection) 14.18.21 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) 14.28.53 # Build Server message: New build round started. Revision bd507fc7b4, 293 builds, 9 clients. 14.39.56 # Build Server message: Build round completed after 663 seconds. 14.39.59 # Build Server message: Revision bd507fc7b4 result: All green 14.43.50 # Build Server message: New build round started. Revision 043e8a0c5c, 293 builds, 9 clients. 14.44.11 Join amachronic [0] (5284b85f@82.132.184.95) 14.47.20 Join penseur [0] (b2a9ca3b@178-169-202-59.beloslav.ddns.bulsat.com) 14.47.22 # amiconn: thanks for the clarification... I was hoping to get rid of SW volume on my M3K port, maybe -6 dB will be just enough. 14.48.32 Quit penseur (Client Quit) 14.56.47 # Build Server message: Build round completed after 778 seconds. 14.56.50 # Build Server message: Revision 043e8a0c5c result: All green 15.05.38 Quit Rower (Ping timeout: 256 seconds) 15.10.39 # amachronic: if the codec doesn't have hw volume control, rockbox's sw control works automagically. but IIRC the codec requires 32-bit PCM data input... at least under the linux port. 15.11.19 # amachronic: honestly you're probably better off just fixing the ak4376 to full-scale 0dB volume and letting rockbox handle the SW control. 15.11.27 # SW volume I mean 15.13.08 # oh cool it supports 16bpp natively. (yay, janky FiiO linux port..) 15.13.25 # speachy: I'm trying to minimize dependence on the SW volume to reduce power consumption. The native ports also have a different SW volume implementation that's only 16 bits. 15.13.57 # the SW volume control is a rounding error compared to the decoding overhead 15.14.14 # indeed, the main argument against it is "rounding error" :D 15.15.18 Join calebccff [0] (~calebconn@connolly.tech) 15.15.19 # Hey! I've been slowly working on (attemping to..) port Linux to the iPod classic 1G, or 6th gen. Right now I've barely got the kernel booting but it's getting there. As part of that I've added the ability to boot a Linux kernel with a DTB to the rockbox bootloader (for the classic). Would you guys be interested in taking that upstream? 15.15.33 # Perhaps not now, but if I manage to get a Linux port in any way usable :> 15.15.34 # to get the volume control rb users expect, we have to go to a bizzare combo hw/sw model, which largely obliviates the power consumption argument. 15.16.16 # calebccff: you mean getting the linux stuff upstream, or rockbox-specific changes? 15.16.45 # I mean submitting patches to rockbox to make the bootloader capable of booting modern Linux 15.16.54 # *iPod classic bootloader 15.17.31 # hmm. I'm okay with that in principle, but it does seem that it would make the bootloader a lot more complicated. 15.20.02 # speachy: yeah, that's a fair point. It doesn't require much changing of the actual code flow, a new function in rb-loader to load regular files into memory, check for a particular button press and if so then call some load_linux function to load the kernel, dtb and potentially initrd and boot it 15.20.28 # the ipod bootloaders are effectively unmaintained these days -- we make sure they still compile but that's about it. they haven't seen a new build/release in quite some time. 15.20.44 *** Saving seen data "./dancer.seen" 15.21.32 # I'll see what I come up with. There's definitely some cleanup needing done in the 6g bootloader, and a few other minor changes, I'll prepare a patch series and see what you think :) 15.22.08 # I'm happy to review patches.. just not in a position to test anything. 15.23.21 # ah right, np. Thanks 15.24.43 Quit amachronic (Quit: Connection closed) 15.25.03 Join amachronic [0] (5284b85f@82.132.184.95) 15.44.53 Join jdarnley [0] (~J_Darnley@d51a44418.access.telenet.be) 15.46.45 Quit J_Darnley (Ping timeout: 264 seconds) 15.47.40 Quit amachronic (Quit: Connection closed) 15.58.28 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 16.09.56 Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) 16.38.19 Quit lebellium (Quit: Leaving) 17.20.46 *** Saving seen data "./dancer.seen" 17.42.23 # i guess i'm weird; i prefer to add new features to the USB stack instead 17.42.32 # since that'll see more general use 18.05.08 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") 18.10.09 Join Rower- [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) 18.11.57 Quit Rower (Ping timeout: 264 seconds) 18.23.21 Quit calebccff (Quit: Idle timeout reached: 10800s) 18.49.06 Quit Rower- (Ping timeout: 246 seconds) 18.49.31 Join eevan_ [0] (~eevan@telesto.hot-chilli.net) 18.50.29 Part eevan_ 18.59.41 Quit ac_laptop (Quit: WeeChat 3.0) 18.59.57 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 19.00.28 Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) 19.06.41 Quit pamaury (Ping timeout: 272 seconds) 19.20.47 *** Saving seen data "./dancer.seen" 20.36.33 Quit MrZeus_ (Ping timeout: 264 seconds) 21.20.08 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) 21.20.48 *** Saving seen data "./dancer.seen" 21.40.45 Quit cockroach (Quit: leaving) 21.41.12 Join ufdm [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) 22.00.45 # why is it so hard to find good headphones? 22.07.03 Nick mendelmunkis is now known as mendel_munkis (~mendelmun@ool-43568247.dyn.optonline.net) 22.24.42 Join f1reflyylmao [0] (~f1refly@dynamic-095-112-012-036.95.112.pool.telefonica.de) 22.27.09 Quit f1refly (Ping timeout: 245 seconds) 22.27.09 Nick f1reflyylmao is now known as f1refly (~f1refly@dynamic-095-112-012-036.95.112.pool.telefonica.de) 22.30.10 # mendel_munkis: what defines "good"? 22.31.26 # good point. I do want slightly esoteric headphones. 22.31.49 # (behind the neck, on ear with bluetooth and a 3.5mm port) 22.40.03 Quit ac_laptop (Ping timeout: 245 seconds) 23.04.01 Quit Soap_ (Read error: Connection reset by peer) 23.20.49 *** Saving seen data "./dancer.seen"