--- Log for 26.01.117 Server: nylund.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 21 days and 3 hours ago 00.00.50 # wrap the tip in solder and dip it in flux before you turn it on then place over something that molten solder won't hurt 00.02.17 Quit ender` (Quit: It's not a dictatorship. It's an alternate democracy.) 00.02.44 Join alexweissman [0] (~alexweiss@149-160-130-67.dhcp-bl.indiana.edu) 00.08.13 # Bilgus_, will do. I'm going to start on it in a little bit. 00.08.33 Quit xorly (Ping timeout: 276 seconds) 00.15.15 Quit ender| (Ping timeout: 252 seconds) 00.21.36 Join ender| [0] (krneki@2a01:260:4094:1:42:42:42:42) 00.22.46 # pamaury, ren the ZEN wiki article bootloader, I added the new version: https://www.rockbox.org/wiki/bin/compare/Main/CreativeZENPort?rev1=24&rev2=25&render=sidebyside&context=&skin= 00.22.52 Quit Bray90820 (Remote host closed the connection) 00.23.20 Join Bray90820 [0] (~bray90820@173-25-204-30.client.mchsi.com) 00.32.56 Quit Senji_ (Ping timeout: 255 seconds) 00.46.28 Quit paulk-collins (Ping timeout: 245 seconds) 00.46.36 Quit pamaury (Ping timeout: 252 seconds) 00.46.38 *** Saving seen data "./dancer.seen" 00.50.43 Join dunx [0] (~yulax@edinhacklab/member/duncan) 00.52.53 Part dunx ("WeeChat 1.5") 01.13.06 # <__builtin> how are plugin libraries linked? 01.16.10 # <__builtin> are they part of the core? 01.27.42 Quit ZincAlloy (Quit: Leaving.) 01.30.08 # furrywolf, were all your failed Shuffle -> Yes attempts made through the Quick Screen? 01.41.19 Quit MrZeus2 (Ping timeout: 255 seconds) 01.55.09 Quit elensil1 (Ping timeout: 276 seconds) 02.04.46 # __builtin: part of the core when used by the core 02.05.50 # <__builtin> hmm. ok 02.06.48 Join Rondom [0] (~rondom@modo.nonmodosedetiam.net) 02.07.23 # <__builtin> I could probably (ab)use overlays to make SDL dynamically loadable from multiple plugins, right? 02.08.13 Join elensil [0] (~edhelas@2001:1c02:1903:d800:11ed:8e78:f037:f9fd) 02.08.30 # __builtin: I have never used overlay stuff 02.22.43 Quit cc___ (Ping timeout: 255 seconds) 02.26.38 Quit [Saint] (Ping timeout: 240 seconds) 02.34.15 Quit Bilgus_ (Remote host closed the connection) 02.34.29 Join Bilgus_ [0] (~Bilgus@gateway/tor-sasl/bilgus) 02.41.24 Quit alexweissman (Remote host closed the connection) 02.41.45 Join [Saint] [0] (~sinner@rockbox/staff/saint) 02.46.41 *** Saving seen data "./dancer.seen" 02.51.03 Quit Petri152 (Ping timeout: 245 seconds) 02.52.30 Join Petri152 [0] (~Petri@petritrebs.ca) 02.55.03 Quit skapazzo (Quit: leaving) 03.07.24 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) 03.26.24 Quit alexweissman (Remote host closed the connection) 03.27.39 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) 04.09.45 Join dunx [0] (~yulax@edinhacklab/member/duncan) 04.10.36 # hi, i added some tracks to my device, but for some reason, i am unable to see them in the database. they're clearly there, because i can access and play them with the file manager on the device. how does one refresh the database on the device? 04.46.44 *** Saving seen data "./dancer.seen" 04.54.38 Join chrisb [0] (~chrisb@pool-71-175-250-44.phlapa.east.verizon.net) 05.24.24 Join saratoga_ [0] (123e1c1b@gateway/web/freenode/ip.18.62.28.27) 05.24.33 # dunx: do you see any tracks in the database? 05.25.46 # saratoga_: it lists one album that i added the first time. 05.26.10 # but it doesn't see the new album you added? 05.26.15 # but now i have other albums and tracks, and it won't show them. 05.26.24 # saratoga_: exactly. 05.27.08 # IIRC it should automatically update 05.27.14 # but i don't regularly use the database 05.28.38 # hmm, is there a "correct" place to put the tracks? 05.29.18 # currently i just place them all in a folder called "Music" at the root of the disk, connwcted over Mtp. 05.31.17 # ah i found an option in settings. auto-updating it was set to off... 05.35.43 # it shouldn't matter where you put the files, although if you use MTP the file names will often get screwed up 05.35.54 # plus MTP tends to be pretty slow 05.38.59 # i don't have a CF card reader atm. but my problem has been solved, so... 05.42.01 # not sure i understand 05.43.20 # i mean, having a CF card reader for the player's drive (a CF card) would be faster, right 05.44.01 # I guess if you can remove the CF card somehow 05.44.09 # i just meant using MSC would be faster than MTP 05.44.34 Quit jhMikeS (Ping timeout: 240 seconds) 06.05.39 Quit Jack87 (Ping timeout: 245 seconds) 06.12.21 Quit TheSeven (Ping timeout: 240 seconds) 06.12.48 Join Jack87 [0] (Jack87@nasadmin/admin/jack87) 06.13.11 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 06.15.50 Quit furrywolf (Ping timeout: 255 seconds) 06.37.00 Quit naleo (Remote host closed the connection) 06.39.01 Join naleo [0] (~naleo@unaffiliated/naleo) 06.46.45 *** Saving seen data "./dancer.seen" 06.47.45 Join Thoranaga [0] (567c25ef@gateway/web/freenode/ip.86.124.37.239) 06.53.34 Quit chrisb (Ping timeout: 240 seconds) 06.54.23 # I have two Creative Zen devices ( 4GB and 8GB European version) and they work fine with 2014 bootloader and with firmware_zen_lcd . No lockups just one or two crashes when adding files to database, but nohting to worry about. . 06.58.33 # The Zen 8Gb version shows white screen( for 100 -200msec ) when booting , before loading bootloader and when shutting down but after that everithing works as expected . 07.03.14 # The Zen 4Gb device keepd frezeezing with stock OF but with rockbox everything runs smoothly . 07.03.41 # Thank you all who developed this project ! 07.04.51 Quit Thoranaga (Quit: Page closed) 07.17.09 Quit dys (Ping timeout: 258 seconds) 07.20.18 Quit saratoga_ (Quit: Page closed) 07.55.05 Quit girafe (Read error: Connection reset by peer) 07.55.15 Quit pixelma (Quit: .) 07.55.15 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 07.58.37 Join pixelma [0] (~pixelma@rockbox/staff/pixelma) 07.58.38 Join amiconn [0] (~amiconn@rockbox/developer/amiconn) 08.19.09 Join dys [0] (~dys@ip-109-44-1-147.web.vodafone.de) 08.22.02 Join ender` [0] (krneki@foo.eternallybored.org) 08.26.16 Join asymsucon [0] (bcaf21ee@gateway/web/freenode/ip.188.175.33.238) 08.26.36 Part asymsucon 08.29.38 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:20da:e74b:8fe2:be6c) 08.46.04 Quit naleo (Ping timeout: 240 seconds) 08.46.46 *** Saving seen data "./dancer.seen" 08.53.53 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 09.18.08 Join petur [0] (~petur@91.183.48.77) 09.18.08 Quit petur (Changing host) 09.18.08 Join petur [0] (~petur@rockbox/developer/petur) 09.28.49 Quit ZincAlloy (Quit: Leaving.) 09.38.47 # prof_wolfff: I have bad news. I resurected my n2g, installed HEAD build of rockbox and I still have issues with usb. Not as severe as was before designware driver rework. Device enumerates but fails on copying files. I can copy in apple disk mode without problems so this is not hardware problem. 09.41.17 # prof_wolfff: Could it be g#843 case? 09.41.18 # 3Gerrit review #843 at http://gerrit.rockbox.org/r/843 : 3Fix cache coherency on ARM940T (and other ARMv4T cores). by Michael Sparmann 10.18.55 # TheSeven: ping 10.23.22 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 10.24.43 Join paulk-collins [0] (~paulk@gagarine.paulk.fr) 10.39.59 Join robertd1 [0] (~root@186-90-12-124.genericrev.cantv.net) 10.46.48 *** Saving seen data "./dancer.seen" 10.56.19 Quit pamaury (Ping timeout: 256 seconds) 10.59.44 Join xorly [0] (~xorly@193.85.203.185) 11.07.19 Quit petur (Ping timeout: 245 seconds) 11.11.48 Quit xorly (Ping timeout: 240 seconds) 11.19.50 # ok, with g#843 my n2g does not mount 11.19.51 # 3Gerrit review #843 at http://gerrit.rockbox.org/r/843 : 3Fix cache coherency on ARM940T (and other ARMv4T cores). by Michael Sparmann 11.21.23 Join shdwprince [0] (~textual@78.111.190.204) 11.25.24 Join skapazzo [0] (~skapazzo@151.9.205.1) 11.30.08 Join petur [0] (~petur@91.183.48.77) 11.30.08 Quit petur (Changing host) 11.30.08 Join petur [0] (~petur@rockbox/developer/petur) 11.32.06 Quit WakiMiko (Max SendQ exceeded) 11.32.43 Join WakiMiko [0] (~WakiMiko@unaffiliated/wakimiko) 11.56.21 Join pamaury [0] (~quassel@wks-50-63.mpi-sws.org) 11.56.21 Quit pamaury (Changing host) 11.56.21 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 12.25.51 Join xorly [0] (~xorly@193.85.203.185) 12.30.14 Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) 12.32.36 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:6093:ef53:a4cd:986c) 12.44.22 # pamaury, you might be interested to know that two RBed ZENs here (G, Q) wake the backlight when a jack is inserted. Three others (P, L and M) don't. FWIW, M is on internal power and the others on external. 12.46.50 *** Saving seen data "./dancer.seen" 13.18.56 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 13.20.16 Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) 13.51.28 Quit xorly (Ping timeout: 260 seconds) 14.46.51 *** Saving seen data "./dancer.seen" 14.50.31 # Thoranaga, thanks for the report. How did you determine that your ZENs are European version? e.g. firmware version number? Territory of purchase? Something else? 14.52.07 Quit JanC (Read error: Connection reset by peer) 14.54.01 Join JanC [0] (~janc@lugwv/member/JanC) 14.56.47 # wodz: the cache_range issue is solved on the designware driver by not using commit/discard_dcache_range on s5l8701 (it commits/discards the whole cache), there was some issues on s5l8701 about EPROTO_ERROR, it seems that errors on physical layer are not correctly handled by the USB PHY and corrupted data is introduced into rx FIFOs, i didn't found a way to identify these situations (i.e. some status register or an USB PHY interrupt) 14.56.47 # , really i dont know if such thing exists because s5l8702 does not show this issue, so the workaround tries to identify these situations and flushes the FIFOs 14.58.08 # wodz: the workaround works well on my nano2g, tested mainly on linux, i will try to do more exhaustive tests on next days 14.59.04 # prof_wolfff: For me the driver fails quite early during files copying (like a couple of megabates is enough to trigger). 14.59.21 # using windows? 14.59.34 # prof_wolfff: linux, two different machines 14.59.56 # is there any unusual trace on dmesg logs 14.59.59 # ? 15.01.01 # i tried it reading/writing the whole flash (2gb on my model) various times with no issues, but i will try to do more testing next weekend 15.02.37 # prof_wolfff: http://paste.debian.net/910701/ 15.03.11 # prof_wolfff: scrap that, this is on build with g#843 15.03.13 # 3Gerrit review #843 at http://gerrit.rockbox.org/r/843 : 3Fix cache coherency on ARM940T (and other ARMv4T cores). by Michael Sparmann 15.04.51 # prof_wolfff: I'll post dmesg log when I get home 15.06.07 # ok, i will try the latest git next weekend, i it goes well on my nano then i could try to add debug traces to the driver so you can probe it to get more info 15.06.54 # prof_wolfff: Sure. Hopefully it will not trash FTL on the unit again :-) 15.07.00 # gtg 15.07.03 # :) 15.08.34 # IN the Voice Strings if I add a conditional say under *: "" does that screw up the lang strings? Do I need to instead add it to the end of the LANG file? 15.09.11 # Actually it would be all the headings , , 15.11.29 Quit wodz (Ping timeout: 245 seconds) 15.16.22 Join dfkt [0] (~dfkt@unaffiliated/dfkt) 15.19.07 Quit dfkt (Read error: Connection reset by peer) 15.25.20 # chrisjj: could you try this bootloader on your various ZEN ? https://www.dropbox.com/s/bv2mensuxgb1io4/firmware_zen_regdump.nk?dl=0 15.25.20 # more precisely: this bootloader dumps all regiter on boot and wrtes them to a file called stmp3700_reglist.txt on the internal storage. I would appreciate if you can send me those files for at least the unit that fails all the time (N ?) and another one 15.27.53 # for reference, this corresponding code is g#1536 15.27.54 # 3Gerrit review #1536 at http://gerrit.rockbox.org/r/1536 : 3stmp3700: dumps registers on boot in a file (DONT PUSH) by Amaury Pouly 15.30.35 Join furrywolf [0] (~randyg@70-1-129-116.pools.spcsdns.net) 15.35.02 Join dfkt [0] (~dfkt@unaffiliated/dfkt) 15.55.23 Quit TheSeven (Remote host closed the connection) 16.06.22 Quit ZincAlloy (Quit: Leaving.) 16.18.52 Join Thoranaga [0] (567c25ef@gateway/web/freenode/ip.86.124.37.239) 16.20.11 # chrisjj: How did you determine that your ZENs are European version? -> by firmware name "e" version . 16.25.21 Quit Thoranaga (Quit: Page closed) 16.31.54 Join naleo [0] (~naleo@unaffiliated/naleo) 16.34.06 Join Senji_ [0] (~Senji@85.187.103.250) 16.34.16 Quit gbl08ma (Ping timeout: 252 seconds) 16.46.55 *** Saving seen data "./dancer.seen" 16.56.36 Quit naleo (Ping timeout: 255 seconds) 17.08.09 Quit megal0maniac (Ping timeout: 240 seconds) 17.08.21 Join megal0maniac [0] (~megal0man@unaffiliated/megal0maniac) 17.22.57 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 17.33.29 Quit petur (Quit: Connection reset by beer) 17.53.57 Quit elensil (Ping timeout: 256 seconds) 17.54.40 Join xorly [0] (~xorly@193.85.203.185) 18.01.34 Quit The_Prospector (Read error: Connection reset by peer) 18.02.00 Join The_Prospector [0] (~The_Prosp@unaffiliated/cornman) 18.03.04 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:8b3:ac5f:bd77:411c) 18.12.50 Join elensil [0] (~edhelas@2001:1c02:1903:d800:a1c8:a6b8:4b61:c697) 18.37.39 Quit MrZeus_ (Ping timeout: 240 seconds) 18.42.56 Quit Moarc (Ping timeout: 264 seconds) 18.43.37 Join Moarc [0] (~chujko@a105.net128.okay.pl) 18.46.56 *** Saving seen data "./dancer.seen" 18.52.55 # pamaury: Here are the register dumps. 18.53.45 # http://pastebin.com/dmLrwu3h from ZEN N, the unit on which .rockbox launch usually crashes with a data abort. 18.54.32 # http://pastebin.com/UDDMpPSw from ZEN AC, a unit on which .rockbox runs without any problem found, though not soak-tested. 18.56.10 # Thoranaga, Do you know the firmware at time of new purchase said "e"? 18.56.44 Quit shdwprince (Ping timeout: 264 seconds) 19.04.56 Quit paulk-collins (Remote host closed the connection) 19.07.50 Quit pamaury (Remote host closed the connection) 19.09.50 Join mutnai [0] (6db91733@gateway/web/freenode/ip.109.185.23.51) 19.11.00 Join Thoranaga [0] (567c25ef@gateway/web/freenode/ip.86.124.37.239) 19.12.20 Quit pamaury_ (Ping timeout: 264 seconds) 19.14.00 # chrisjj ZEN_PCFW_L22_1_20_02e updated later by me to ZEN_PCFW_L22_1_21_03e 19.17.01 # chrisjj That is for the 4GB Zen ! As for the 8GB I do not have records as I installed Rockbox very quickly. 19.28.18 Quit Thoranaga (Quit: Page closed) 19.38.32 # Thoranaga, Thanks. To view a Rockboxed ZEN's OF version number, hold Play while turning on. 19.40.54 Join lebellium [0] (~chatzilla@89-93-177-91.hfc.dyn.abo.bbox.fr) 19.47.07 Join Thoranaga [0] (567c25ef@gateway/web/freenode/ip.86.124.37.239) 19.51.06 # chrisjj v1.20.02_0.3.1 for the 8Gb Zen . They are second hand units .This unit had denmark language selected so I presume european also . 19.51.24 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 20.02.26 # chrisjj: thanks, I'll have a look at the dumps see if anything stands out 20.08.58 Quit Thoranaga (Quit: Page closed) 20.14.24 # <[Saint]> Incedentally, isn't the OF version reported in Rockboxinfo and/or debug? 20.14.48 # <[Saint]> If it can be grabbed that easily via the bootloader...well, yeah. 20.20.39 Quit Moarc (Ping timeout: 240 seconds) 20.21.33 Join johnb3 [0] (~johnb2@p5B296B0F.dip0.t-ipconnect.de) 20.21.43 Join Moarc [0] (~chujko@a105.net128.okay.pl) 20.22.17 # Mihail: Is rockbox-clip+-cvdd2_scaling-9.zip the one I should continue testing or do you have some changes in mind? 20.30.55 Quit johnb3 (Ping timeout: 256 seconds) 20.43.59 Quit xorly (Ping timeout: 245 seconds) 20.47.00 *** Saving seen data "./dancer.seen" 20.49.23 Quit mutnai (Ping timeout: 260 seconds) 20.49.30 Join girafe [0] (~girafe@LFbn-1-11729-221.w2-7.abo.wanadoo.fr) 20.51.42 # Thoranaga, thanks. Yes then I think it safe to count your two units as European. 20.59.03 Join johnb3 [0] (~johnb2@p5B296B0F.dip0.t-ipconnect.de) 21.10.11 Join mutnai [0] (6db91733@gateway/web/freenode/ip.109.185.23.51) 21.18.28 Join naleo [0] (~naleo@unaffiliated/naleo) 21.27.05 Quit johnb3 (Quit: Nettalk6 - www.ntalk.de) 21.31.32 Join wodz [0] (~wodz@89-74-169-198.dynamic.chello.pl) 21.32.39 # prof_wolfff: pure HEAD failing on my n2g http://paste.debian.net/910818/ 21.47.25 Join thomasjfox_ [0] (~thomasjfo@dslb-084-057-187-043.084.057.pools.vodafone-ip.de) 21.51.58 Quit thomasjfox_ (Client Quit) 21.52.14 Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) 21.55.54 # chrisjj: the only difference I found between the two devices is RAM size. Unit N has 64MB while Unit AC has 32MB. 21.56.13 # I have never seen a ZEN with 64MB before but it shouldn't be a problem since Rockbox is configured to use 32MB 21.56.41 # so a priori I would say this is not the source of the problem 21.56.58 # <[Saint]> Generally speaking the geographic location of a hardware product's sale or manufacture makes very little difference, although in some instances it certainly can. 21.57.24 # <[Saint]> European units are usually only distinct for the reason of having a specific firmware because of EU volume regulation standards. 21.57.49 # but since I was not aware that ZEN with 64MB even existed, it is possible that there are other hardware difference that matters, I don't know 21.58.04 # <[Saint]> generic substitutions with like-or-similar ICs are very common, even among units in the same production batch. 21.58.26 # <[Saint]> But in my experience the substitutions very rarely require specific handling and are just drop-in replacements. 21.59.22 # <[Saint]> Probably just relating to the fabricator running out of part X and swapping it out for "functionally identical part Y". 22.04.12 # well there is clearly special handling here 22.04.27 # the OF initialises 64MB of memory instead of 32 22.04.48 # that suggest it's not just part substitution 22.06.12 # * [Saint] nods 22.06.29 Join shdwprince [0] (~textual@130.180.218.217) 22.06.42 # <[Saint]> Makes me wonder for what reason. 22.07.37 # <[Saint]> Like you say, if it was just a substitution they would just throw in 64MB and keep treating it like it was 32MB. 22.08.40 # I see two possible explanation: the RAM init code is capable of and goes to the effort of probing RAM size, detects 64MB and use it. Or it's a model variant. 22.08.53 # <[Saint]> Perhaps the developers of the OF just thought they might as well make use of the full potential a substituted part from a different fabricator? 22.09.19 # that would make sense 22.10.12 # <[Saint]> It may or may not even be deliberate, that didn't occur to me but you're probably right. It's likely smart enough to simply make use of the available RAM it can initiate. 22.10.35 # <[Saint]> That's not a particularly difficult problem to solve in software. 22.10.55 # * [Saint] is once again foiled by simple logic 22.13.23 # I could check the RAM init code, but it's long and tedious 22.13.50 # it's doesn't make much sense to probe RAM size in embedded systems though, if you already know which size you have 22.24.59 # * pamaury thinks he needs to have the units in his hands to understand the problem 22.28.10 # <[Saint]> or perhaps the space between the chair and keyboard. :p 22.28.30 Quit wodz (Quit: Leaving) 22.30.33 # anyone have any objections? In backlight timeouts we have ON, OFF, 1s... I want to call them ALWAYS, NEVER, 1s... 22.31.01 Join xorly [0] (~xorly@ip-89-176-102-19.net.upcbroadband.cz) 22.34.37 # Also no one ever answered me.. under LANG_NEVER I have lcd_sleep: "Never" if I instead make it *:"Never" do I need to put it at the end of the language file or can I just add it without screwing up lang strings? 22.35.55 Join petur [0] (~petur@rockbox/developer/petur) 22.41.39 # Chrisjj: how many Sony Mp3 players do you own, and have you had? 22.45.51 # <__builtin> a statistical estimate on my part would be 33 or so 22.46.47 # Creative or SOny? 22.47.03 *** Saving seen data "./dancer.seen" 22.47.14 # <__builtin> I assume Bilgus_ meant creative 22.47.54 # Bilgus_: iirc, you must not remove a string, or it will break horribly. Not sure about changing it's pre-condition 22.48.21 # So try and see then I guess 22.48.34 # maybe the wiki has some info 22.48.56 # I think the problem is about voice files 22.49.05 # if you change the lang file, you'll break voices 22.49.11 # you don't want to break voices 22.49.19 # ;) 22.50.19 # Bilgus_: https://www.rockbox.org/wiki/LangFiles 22.50.31 # "When updating a language, you are asked to solely change the dest and voice strings. Changing id, source or desc will either break-up everything or turn the subsequent update job into real pain. " 22.50.34 # already there :) 22.51.24 # you could deprecate the old string 22.51.56 # and then put the new one at the end?? 22.52.06 # yeah, I think it's the proper way 22.53.05 # but then won't the ID clash with the new one?? 22.53.13 # Bilgus_: to be fair though, a quick git log on lang files suggests the rule was broken already 22.54.41 # so you might go for it and just change the entry, if it breaks anything, it will only add to the existing breakage so... 22.54.48 # lol ok 22.54.54 # gevaerts: any thoughts ? 22.55.09 Quit fs-bluebot (Ping timeout: 240 seconds) 22.55.40 # About language things? 22.55.51 # Not a lot, I've never done much with those 22.56.04 # I believe rasher has been the resident expert at times 22.56.48 Quit bluebrother (Ping timeout: 276 seconds) 22.58.09 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 23.09.15 Join fs-bluebot [0] (~fs-bluebo@xd9befd21.dyn.telefonica.de) 23.20.05 Quit Bilgus_ (Remote host closed the connection) 23.20.35 Join Bilgus_ [0] (~Bilgus@gateway/tor-sasl/bilgus) 23.26.33 Quit cc___ (Quit: WeeChat 1.6) 23.26.58 Join MrZeus [0] (~MrZeus@2a02:c7f:7008:3400:94f5:cbcb:7d40:4443) 23.33.30 Quit skapazzo (Quit: leaving) 23.38.17 Quit thomasjfox (Quit: Konversation terminated!) 23.41.03 Quit Moarc (Ping timeout: 240 seconds) 23.43.33 Join Moarc [0] (~chujko@a105.net128.okay.pl) 23.56.20 Quit alexweissman (Remote host closed the connection) 23.56.40 Quit lebellium (Quit: ChatZilla 0.9.93 [Firefox 50.1.0/20161208153507])