--- Log for 12.02.114 Server: cameron.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 4 hours and 57 minutes ago 00.03.02 Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 28.0/20140205162153]) 00.03.29 # * [Saint] frowns. 00.03.40 # <[Saint]> How can you get a Stkov for the audio buffer? 00.04.19 # * [Saint] removes the and buffer from that sentence, as writing it severaltimes failed rather dramatically 00.08.00 # <[Saint]> No RaaAoA on my phone is kinda heartbreaking. Google Music is so...meh. 00.08.14 Join fs-bluebot [0] (~fs-bluebo@g224236041.adsl.alicedsl.de) 00.08.32 # [Saint]: any way to do gdb to it? 00.08.41 # have you tried in the sim? 00.09.01 Quit rela (Read error: Connection reset by peer) 00.09.14 # <[Saint]> I didn't think an SDL build could accurately represent RaaAoA. 00.09.25 # <[Saint]> (so, no, I didn't try as yet) 00.09.50 # you dont know if it is the JNI or warble or what code causing the problem 00.10.16 # <[Saint]> I would build RaaAoA myself, but apparently that is impossible these days. 00.10.35 # <[Saint]> My fix/kludge to get it building with a modern toolchain no longer works. 00.11.01 # <[Saint]> and its impossible to get the older S/NDK from a trusted source (apparently?). 00.11.44 # <[Saint]> JdGordon: Well...I know warble works fine, if that's any consolation. 00.11.53 # <[Saint]> But I don't think that's really indicative of much. 00.12.48 # <[Saint]> For all I know, it may be a problem with rasher's builds...but I can't really check that, as it involves way too much effort on my part to get it building here. 00.13.26 # <[Saint]> (and if I did get it building again with a modern S/NDK, I couldn;t rule out any problems as being introduced by said workaround) 00.15.27 # <[Saint]> And I can't get a map file from rasher's builds... 00.15.30 # <[Saint]> Gah. 00.18.16 # <[Saint]> I'm left to wonder if it is somehow just my problem, and it affects all my devices, or if no one uses RaaAoA anymore (at least not a modern version thereof). 00.23.25 Quit onder` (Ping timeout: 252 seconds) 00.25.17 Join onder` [0] (~onder@dyn-dsl-to-76-75-112-23.nexicom.net) 00.31.27 Join onder`_ [0] (~onder@dyn-dsl-to-76-75-112-23.nexicom.net) 00.31.57 Quit onder` (Ping timeout: 260 seconds) 00.32.02 Nick onder`_ is now known as onder` (~onder@dyn-dsl-to-76-75-112-23.nexicom.net) 00.39.00 # [Saint]: I think I still have some builds sitting in my Dropbox; what's your phone's resolution? 00.41.39 # Last successful builds were made on Dec. 26. 00.46.52 Quit ender` (Quit: Remember: A secretary isn't permanent until she's been screwed on the desk...) 00.58.17 Join soap [0] (~soap@cpe-174-102-103-175.woh.res.rr.com) 00.58.17 Quit soap (Changing host) 00.58.17 Join soap [0] (~soap@rockbox/staff/soap) 01.05.32 Quit markun (Quit: leaving) 01.06.02 *** Saving seen data "./dancer.seen" 01.10.44 Quit ZincAlloy (Quit: Leaving.) 02.37.17 # <[Saint]> Crap. Sorry Strife89, didn't see the notification. If you have 480x800 compiled it would run on all the devices I own. 02.37.37 # <[Saint]> I'll prod at it when I get home. 02.40.24 # [Saint]: Yup, I have it. Here. https://www.dropbox.com/s/az1mqxva2frvr2o/ally-2013-12-26.apk 02.41.12 Join pedro_angelo [0] (~pedro_ang@201-19-53-120.user.veloxzone.com.br) 02.41.37 # <[Saint]> Excellent. Thanks. 03.01.53 Join onder`_ [0] (~onder@dyn-dsl-to-76-75-118-5.nexicom.net) 03.04.43 Quit onder` (Ping timeout: 260 seconds) 03.04.49 Nick onder`_ is now known as onder` (~onder@dyn-dsl-to-76-75-118-5.nexicom.net) 03.06.03 *** Saving seen data "./dancer.seen" 03.14.42 Join plain-user [0] (~plain-use@ppp121-45-162-235.lns20.syd6.internode.on.net) 03.38.13 Quit Ooga_Booga (Remote host closed the connection) 03.38.18 Join JeremyGoodwin [0] (6c14a639@gateway/web/freenode/ip.108.20.166.57) 03.40.47 Quit JeremyGoodwin (Client Quit) 03.41.34 Join krabador [0] (~krabador@unaffiliated/krabador) 04.02.32 Quit krabador (Quit: Sto andando via) 04.27.43 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.27.43 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.27.43 Quit amiconn (Disconnected by services) 04.27.43 Quit pixelma (Disconnected by services) 04.27.46 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 04.40.11 Quit plain-user (Quit: Leaving) 05.01.25 Nick DormantBrain is now known as SuperBrainAK (~andy@74.112.200.73) 05.02.19 # hey guys hows your evening/morning? 05.03.32 # i was wondering does the sansa clip zip processor have any spare I/O? 05.04.12 # <[Saint]> What is it you're wanting to achieve? 05.05.12 # does the thing have headphone detection? 05.05.30 # <[Saint]> I believe so. 05.05.37 # idk some sort of volume knob like a continuous rotation pot or rotary encoder 05.05.47 # no it doesnt 05.06.00 # idk 05.06.06 *** Saving seen data "./dancer.seen" 05.06.08 # i dont know 05.06.15 # <[Saint]> It probably does. But we may not make use of it. 05.06.24 # ah 05.06.25 # yea 05.06.32 # saratoga on the forums says only insert which is pretty sueless 05.06.44 # <[Saint]> Its a very young port still and things like that tend to get neglected. 05.07.28 # well you wouldnt really need to know if the jack is detected really it doesnt have external speakers to switch to 05.08.32 # pause on unplug.... 05.08.42 # <[Saint]> You could probably hijack the mic input via the dock. 05.10.25 # <[Saint]> But, in general, if you want to play with things like this a DAP isn't really the best candidate. 05.10.49 # <[Saint]> Sounds like you want to play with something you can actually sink your teeth into the hardware of. 05.11.16 # <[Saint]> One of the bajillion ARM dev boards out there is probably a good start. 05.11.43 # <[Saint]> (and you could run Rockbox on that, too :)) 05.12.16 # <[Saint]> Another option, I guess, if its enabled in the port, is HID. 05.12.23 Quit pedro_angelo (Remote host closed the connection) 05.16.26 Quit TheSeven (Disconnected by services) 05.16.38 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 05.21.57 Quit ruskie (Quit: ...) 05.30.09 Join uw [0] (~uw@unaffiliated/uw) 05.32.43 Join ruskie [0] (ruskie@sourcemage/mage/ruskie) 05.36.37 Quit Strife89 (Quit: Leaving) 05.36.38 Join Strife1989 [0] (~Strife89@adsl-98-80-214-9.mcn.bellsouth.net) 05.42.48 Join saratoga [0] (123e11e0@gateway/web/freenode/ip.18.62.17.224) 05.43.05 # IIRC the manual says it can detect an insert but not a remove 05.44.00 # i guess you could probably unsolder some of the buttons or LEDs and use that for IO 05.44.07 # a lot of them are just GPIO pins 05.44.23 # <[Saint]> COuld you not use the dock? 05.44.37 # <[Saint]> As I said earlier, perhaps hijack mic in off the dock? 05.45.23 # theres no dock on the zip 05.49.58 # <[Saint]> Oh. Crap. Indeed. 06.10.49 Nick SuperBrainAK is now known as DormantBrain (~andy@74.112.200.73) 06.56.29 Join tapiralec [0] (~alec@cpe-76-184-244-146.tx.res.rr.com) 07.06.10 *** Saving seen data "./dancer.seen" 07.43.33 Join n1s [0] (~n1s@rockbox/developer/n1s) 07.51.29 Join fragilematter [0] (~fragilema@unaffiliated/fragilematter) 07.53.26 Join mortalis [0] (~kvirc@213.33.220.118) 08.06.22 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) 08.07.27 Quit akaWolf (Client Quit) 08.10.21 Join ender` [0] (krneki@foo.eternallybored.org) 08.27.23 Join wodz [0] (~wodz@89-75-151-160.dynamic.chello.pl) 08.28.11 # Zagor: (log) I get 'remote: warning: unable to access '/root/.config/git/attributes': Permission denied' when git pull. I don't recall seeing this message before 08.32.55 # pamaury: (log) http://pastie.org/8725047 when building regtools after todays git pull 08.33.02 Quit fragilematter (Quit: Leaving.) 08.43.56 # pamaury: (log) qeditor is affected also. After fixing std::vector vs std::list I get some undefined references to hwstub stuff and pretty suspicious warning http://pastie.org/8725073 08.48.14 # pamaury: (log) my bad, I forgot to build the lib. It would be great if the build system remembers about this and build libhwstub. a instead of throwing error 08.51.02 # pamaury: (log) hwstub_shell also suffers from std::vector vs std::list. Cumulative patch to fix definitions http://pastie.org/8725086 08.55.14 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 09.01.15 Quit Strife1989 (Ping timeout: 250 seconds) 09.02.12 Join Zagor [0] (~bjst@80.239.169.203) 09.02.12 Quit Zagor (Changing host) 09.02.12 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 09.06.14 *** Saving seen data "./dancer.seen" 09.06.55 Join fragilematter [0] (~fragilema@unaffiliated/fragilematter) 09.26.05 Quit bertrik (Ping timeout: 245 seconds) 09.28.07 Quit wodz (Ping timeout: 250 seconds) 09.36.49 # pamaury (logs): https://outpost.fr/tmp/nDI.txt 09.37.33 # I guess I was right to suspect the sd card 09.38.06 Join kugel [0] (~kugel@193.174.67.16) 09.38.06 Quit kugel (Changing host) 09.38.06 Join kugel [0] (~kugel@rockbox/developer/kugel) 09.51.11 Quit kugel (Read error: Connection reset by peer) 09.59.40 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 10.04.40 Join kugel [0] (~kugel@193.174.67.16) 10.04.40 Quit kugel (Changing host) 10.04.40 Join kugel [0] (~kugel@rockbox/developer/kugel) 10.05.32 # [Saint]: works for me (right channel this time) 10.06.36 # <[Saint]> Forgive me if I don't repeat my rant in here. :) 10.08.14 # there are many problems on android that I cannot reproduce, and unless I get serious help I'm unable to make it any better 10.08.43 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 10.09.21 # like the app hanging after playing a few tracks for me 10.09.48 # unfortunately I haven't found a pattern yet 10.10.41 # pamaury: logs 10.12.15 # <[Saint]> pixelma: yeah, thats a fun one. 10.12.48 # <[Saint]> force closing several times in a row and then magically working is another good one. 10.13.42 # <[Saint]> Boot. Nope! Boot. Nope! Boot. Ok, I'll work now. 10.14.31 Join stoyan [0] (~io-headqu@77.70.0.98) 10.15.58 Quit stoyan (Client Quit) 10.16.51 # having the wrong colours in the notification dropdown (or whatever it's called) on my SE ICS phone is also a nice one I couldn't figure out yet. It's the only app I've seen so far doing this 10.19.31 Quit tchan (Quit: WeeChat 0.4.2) 10.20.37 # though not terribly important 10.21.33 # copper: thanks, I need to go, I'll be back this afternoon to study this file 10.22.41 # <[Saint]> If I had the same issues with Rockbox on a DAP, it would be a lot easier to gather the motivation to do something about it. 10.22.49 # cool 10.23.22 # <[Saint]> But its difficult to think the same way about Android with so many functional alternatives. 10.26.32 Quit pamaury (Ping timeout: 272 seconds) 10.28.32 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 11.01.51 Join kuldeepdhaka [0] (~kuldeepdh@unaffiliated/kuldeepdhaka) 11.02.17 Quit kuldeepdhaka (Max SendQ exceeded) 11.06.17 *** Saving seen data "./dancer.seen" 11.08.07 # [Saint]: the skin engine is not the problem 11.08.19 # <[Saint]> Its certainly *a* problem. 11.08.24 # we could have disabled it for the time being 11.08.43 # <[Saint]> That was the very first step in the whole "maybe we're not thinking about this right" phase of RaaAoA. 11.08.50 # our entire architecture is a bad fit for android 11.09.06 # <[Saint]> You won;t see me arguing there. 11.11.45 # but perhaps you don't realize how bad the fit is :) 11.12.40 # <[Saint]> No, I do. Which is one of the reasons I'm surprised it progressed so far, and lasted as long as it did. 11.13.00 # * [Saint] notes he's using past tense and tries not to 11.14.05 # <[Saint]> It really is a credit to you, and all the others involved that it is as functional as it is. 11.14.56 # <[Saint]> I'm not trying to discredit the work, not at all. 11.16.09 # <[Saint]> But looking back, its easy (now) to say "What was who thinking when we thought this could work?" 11.20.20 Quit kugel (Ping timeout: 248 seconds) 11.22.00 Join kuldeepdhaka [0] (~kuldeepdh@unaffiliated/kuldeepdhaka) 11.33.22 Join Rower [0] (husvagn@90-230-142-55-no41.tbcn.telia.com) 11.33.32 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 11.34.44 Quit dfkt (Ping timeout: 248 seconds) 11.55.18 Quit sciopat (Quit: Leaving) 12.25.34 Join ZincAlloy [0] (~Adium@pD9EE9107.dip0.t-ipconnect.de) 12.32.50 Quit tapiralec (Quit: Ex-Chat) 12.45.06 Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) 12.56.10 # wodz (logs): yeah you're right, I forgot to fix some programs, the warning is normal, it's just because I compare the current version of hwstub to the reported one and since it's currently 0 the "<" chek is always false 13.06.19 *** Saving seen data "./dancer.seen" 13.14.15 # Build Server message: 3New build round started. Revision c35e4a4, 250 builds, 33 clients. 13.15.06 # wodz (logs): compilation should be fixed now, the undefine references in qeditor seem weird though, the qmake adds the hwstub library to the linker 13.17.17 # Build Server message: 3Build round completed after 183 seconds. 13.17.29 # copper: I will need to send you a new build, I would not have expected the code to fail at this point and I need more debug information 13.17.46 # that's ok 13.21.58 Quit ikeboy (Quit: Leaving) 13.22.06 Join dfkt [0] (OxO29A@unaffiliated/dfkt) 13.33.56 Quit fragilematter (Quit: Leaving.) 13.36.10 # copper: https://www.dropbox.com/s/rf06athk6c0x96n/rockbox_debug_msd_fuzep2.zip 13.36.39 Join fragilematter [0] (~fragilema@unaffiliated/fragilematter) 13.41.49 # got it 13.49.47 # pamaury: not sure that's going to help much: https://outpost.fr/tmp/hHG.txt 13.52.16 # ok interesting, apparently a transfer fails and the card stops responding 13.52.30 # * [Saint] wonders what's up with that link that hover-preview fails on it 13.52.51 # <[Saint]> all your outpost.fr links screw up hover-preview for me, actually. Hmmm. 13.52.54 # copper: I will need more debug :) 13.59.16 # hehe 13.59.33 # [Saint]: using embed.ly? 14.00.33 # <[Saint]> Using....whatever quassel uses to do hover-preview, which seems to work for everything else but your links. 14.01.04 # <[Saint]> (vastly offtopic, just something I noticed since you brutishly forced me into clicking a link :P) 14.03.16 Join wodz [0] (~wodz@89-75-151-160.dynamic.chello.pl) 14.03.42 # copper: https://www.dropbox.com/s/rzacco8lerlcxkl/rockbox_debug_msd_fuzep3.zip 14.04.10 # [Saint]: can't see why, I'm not doing anything special in that .txt link 14.15.34 # pamaury: trying to run into the bug, no luck yet 14.23.43 # ah, finally 14.25.01 # pamaury: https://outpost.fr/tmp/Z89.txt 14.26.56 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 14.43.25 Join amayer [0] (~amayer@173.189.251.62) 14.48.51 Join krabador [0] (~darkarch@host131-142-dynamic.59-82-r.retail.telecomitalia.it) 14.48.51 Quit krabador (Changing host) 14.48.51 Join krabador [0] (~darkarch@unaffiliated/krabador) 14.49.09 Quit krabador (Client Quit) 14.49.51 Join krabador [0] (~darkarch@unaffiliated/krabador) 14.50.00 Quit krabador (Client Quit) 14.50.29 Join krabador [0] (~darkarch@unaffiliated/krabador) 14.53.36 Quit wodz (Ping timeout: 260 seconds) 15.03.10 Quit fragilematter (Quit: Leaving.) 15.06.15 # copper: so the problem is that the card times out and does not answer anymore 15.06.22 *** Saving seen data "./dancer.seen" 15.06.26 # this looks like a bug of the card to me 15.07.05 # jesus 15.07.07 # it's brand new 15.07.20 # and a replacement for my other fucked up card 15.07.41 # and I checked, SanDisk didn't send me back the same card 15.07.45 # different serials 15.08.11 # pamaury: if it's the card, I should run into the bug with a Clip+ too, right? 15.08.45 # not necessarily, the drivers are slightly different, it could be a timing issue 15.09.38 # ok, first I'm going to try a build from when kugel fixed the theme bugs 15.13.00 # what is puzzling is why 64GB cards seems to more prone to this issue 15.14.19 # they do? 15.14.41 # metaphys bricked a 64GB card recently on the fuze+ 15.15.12 Join fragilematter [0] (~fragilema@unaffiliated/fragilematter) 15.15.33 # I guess that's what happened to my previous card too 15.16.07 # but bricked card is a firmware bug, except by frying it you cannot brick a card with software commands 15.16.28 # well I've had many USB flash drive controllers get bricked, too 15.17.01 # those things seem flaky as shit 15.17.48 # this issue though looks different, it may be a problem with the driver but what ?! 15.18.07 # I'm trying to run into the bug with the kugel build right now 15.18.28 # what is the kugel build ? 15.19.39 # short hand for "a build from when kugel fixed the theme bugs" 15.19.48 # 193911a to be precise 15.20.05 # because I don't remember having that problem back then, but it could just be a coincidence 15.20.35 # if I can't manage to run into the bug with that build, then maybe there's something on the Rockbox side 15.21.37 # ok, nope 15.21.42 # just ran into the bug 15.22.14 # ok let's try the Clip+ now 15.23.26 Quit fragilematter (Quit: Leaving.) 15.24.08 # * [Saint] doesn't understand the concept of software "bricking" sdcards. 15.24.22 # <[Saint]> Surely its a firmware issue if it is possible for this to happen. 15.24.31 # <[Saint]> ...or an overvoltage, or something. 15.25.06 # <[Saint]> The latter can definitely do it, I know that, be we should certainly be safe there. 15.25.39 # <[Saint]> In my mind, for this to happen in some way, even if it is triggered by a driver fault, the card has to be defective in some way. 15.26.08 # <[Saint]> If it wasn't, surely the worst that could happen is a trashed filesystem? 15.27.08 # maybe you could brick it by sending some vendor specific commands that do nasty undocumented stuff 15.27.24 # <[Saint]> Hmmm. Right. 15.27.36 # but since the SD bus is CRC'd, that's very unlikely 15.27.41 # I'm sick of those flimsy flash devices 15.28.04 # <[Saint]> The flash is likely fine. 15.28.10 # <[Saint]> This seems like afirmware issue. 15.28.16 # <[Saint]> *a firmware 15.28.29 # I'm talking about the devices as a whole 15.28.39 # <[Saint]> AH. Sorry. Too literal. 15.29.17 # I've never stopped having problems with those, ever since I bought my first USB flash drive in, what, 2000 or something? 15.30.06 # it's because the problem is far from trivial 15.30.34 # the illusion that you can use a NAND flash as a block device is fundamentally flawed from the start 15.31.29 # that's why flash file systems exist 15.32.10 # <[Saint]> Yeah, this ^ 15.32.16 # on big devices like SSD you can probably compensate by adding some RAM which makes it easier for the firmware but on microSD stuff everything has to be horribly small 15.33.29 # god, that toy is so damn small (the Clip+) 15.35.13 # any news about the clip sport ? 15.36.07 # http://www.sandisk.com/about-sandisk/press-room/press-releases/2014/sandisk-announces-new-mp3-player-designed-for-athletes-and-fitness-enthusiasts/ 15.36.20 # <[Saint]> I'm slightly suspicious (and possibly hopeful) of it being a recycled model in a different case. 15.36.37 # <[Saint]> (with some firmware additions to make it seem justifiable) 15.37.48 # you've seen the pics, right? http://www.head-fi.org/t/697524/clip-zip-sport-16gb/45 15.38.07 # yeah but the inside ? 15.38.22 # I guess someone here has to buy one ^^ 15.38.28 # has nobody tried to reach a recovery mode for example ? 15.38.54 # <[Saint]> No one I know of has one. 15.42.19 Join fragilematter [0] (~fragilema@unaffiliated/fragilematter) 15.46.27 # I think it's rather save to assume that they upgraded the hardware for better battery life. 15.50.24 # Clip+ refuses to crap out 15.50.42 # Anyone else notices the warning from lib/unwarminder/backtrace.c? 15.51.14 Nick PurlingNayuki_ is now known as PurlingNayuki (uid20107@gateway/web/irccloud.com/x-pywbegcdrzcjusjv) 15.51.54 # lib/unwarminder/backtrace.c:111:15: warning: variable 'r' set but not used [-Wunused-but-set-variable] 15.51.54 # UnwResult r; 15.52.22 # But I checked that file and see variable r is used lines below definition 15.52.56 # PurlingNayuki: it's not used 15.53.04 # It's set, but nothing reads it 15.53.17 # Which compiler are you using? 15.53.31 # r = UnwindStart(pcAddr, spAddr, &cliCallbacks, (void *)line); 15.53.35 # Isn't this use r? 15.53.51 # That's the "set" part of "set but not used" 15.54.26 # I'm using arm-linux-androideabi-gcc 4.8 from Android NDK 15.54.45 # Right. That's the sort of thing that's not unexpected with newer compilers 15.55.37 # note that the build you produce could be faulty because of using an unsupported compilers 15.56.12 # PurlingNayuki: if it wan't set at all you'd get a "defined but not used" warning 15.56.21 # pamaury: did we ever actually specify an ndk version to use? 15.56.38 # * [Saint] assumes this isn;t for Android 15.56.39 # Despite of the warning it does work on real Android targets. 15.57.22 # ah yeah for android I guess it's fine 15.57.54 # That's a library for arm, but not for arm that runs Android right? 15.58.58 # I think the unwinder is compiled on Android too 15.59.24 # And there's also another warning in apps/menus/main_menu.c, line 251 15.59.36 # but I don't have rockboxed android device so I don't know if it's actually used 16.00.17 # * [Saint] is curious, if this is indeed for Android, what S/NDK version is being used, and what trickery was needed to compile Rockbox for Android thereon. 16.00.39 # <[Saint]> The tools we rely on haven't been present for several revisions. 16.02.06 # <[Saint]> I managed to get it to compile a few revisions ago, but my kludge for that stopped working a while back. 16.02.54 # <[Saint]> PurlingNayuki: ^ 16.10.02 # [Saint]: Are you talking about apkbuilder? 16.10.25 # <[Saint]> among others. 16.11.00 # As a simple solution, I added it back to my modified source but we should really use aapt. 16.11.05 # <[Saint]> replacing apkbuilder alone doesn't get the job done. 16.11.28 # <[Saint]> It /may/ work, if you updated the S/NDK in place from prior revisions, and they are left over. 16.11.47 # <[Saint]> From a clean installation, I have had exactly zero success. 16.12.29 # I can't remember what I did but anyway I got this compiled. 16.13.01 # Bump the SDK version in android.make may help. 16.13.29 # <[Saint]> I suspect that the tools apkbuilder itself calls were left over in your SDK installation. 16.13.37 # <[Saint]> I can't think of another way it would work. 16.14.11 # I've said that I added it back to my source. 16.15.14 # I should write to use aapt but I'm a lazy guy. 16.16.23 # <[Saint]> I know you added apkbuilder back, but that itself relies on tools that either moved and/or are no longer present. 16.16.50 # <[Saint]> So at the least I would expect some linking magic. It would be nice to know, that's all. 16.17.29 # And thanks to your notice I remember I set links for those missing files. 16.18.34 # <[Saint]> Aha. Right. 16.18.49 # That should be enough for a instant fix. 16.19.17 # Anyway we should turn to aapt right? 16.19.50 # <[Saint]> I sincerely doubt anyone would prevent you from doing so. 16.20.42 # That's it.;-) 16.20.44 # <[Saint]> I'll have another go at setting this up again, I couldn't get it to work even following my own directions last time. :) 16.22.04 # I will try this maybe in one week ir two 16.22.05 # <[Saint]> A small part of me doesn't want to get it working. As then I'll want to start fixing things that annoy me, and I'll get all depressed about doing what I feel is heading in the wrong direction. 16.22.13 Quit n1s (Quit: Ex-Chat) 16.23.01 # <[Saint]> I used to believe very strongly that RaaA on Android had a future. Not so much anymore. 16.23.54 # <[Saint]> I love it to bits for its features, but the approach is wrong in so many ways. Well beyond my technical ability to fix. 16.24.08 # becaue nobody has an mp3 player anymore. everbody needs to have the latest, greatest device? :D 16.24.20 # <[Saint]> No. 16.24.31 # <[Saint]> Because bringing our UI with us was a terrible idea. 16.25.01 # yeah. I can hardly imagine how that would work well 16.25.07 # <[Saint]> (note: the views of [Saint] are not wholly representative of the Rockbox project :)) 16.25.25 # A one for iPhone may have an equal future, if there is :D 16.26.14 # <[Saint]> Is that a cryptic way of saying "no future"? :) 16.26.53 # <[Saint]> I don't quite believe that. As a playback library, I believe Rockbox has a future on many devices and platforms. 16.27.07 # <[Saint]> well, I would like to. 16.28.56 # <[Saint]> Its depressing being passionate about something when you don't have the technical ability nor the time to correct the flaws you see. 16.28.58 # Actually I released several versions of RaaA and the strongest voice from thousands of users is, it's wonderful, excluding its UI 16.30.00 # <[Saint]> I agree completely. 16.30.31 # <[Saint]> Which is why I see Rockbox as having a future on Android as a playback library open for other applications to use. 16.31.09 # I have taken measures to solve that, temporarily. 16.31.32 # That's pre-packed themes. 16.31.37 # <[Saint]> In the past, I believed very strongly that we could overcome the issues with the UI. But rotation and resolution agnostic UIs proved to be all but impossible. 16.31.55 # <[Saint]> A binary per resolution would never fly in the wild. 16.32.59 # <[Saint]> (were it to ever be a "product") 16.33.04 # I agree this. 16.33.44 # I have a simple solution to resolution too. 16.34.03 # <[Saint]> Oh? 16.34.11 # it's far from perfect but at least usable. 16.35.02 # <[Saint]> The only way I know of is making sure the theme is the same size or smaller than target resolution. 16.35.57 # <[Saint]> But then it gets pinned to 0,0 and you get a black border to the side and bottom. 16.36.18 # Simply zoom the outputs to the resolution as the devices' 16.37.32 # <[Saint]> Ah, cute. 16.38.52 # <[Saint]> Now, in later versions of Android, we hae other fun things to worry about. 16.39.06 # And we have got this working 16.39.10 # <[Saint]> Like dynamic navigation soft keys and status bar. 16.39.35 # <[Saint]> *we have 16.39.50 # Oops, another we 16.40.35 # <[Saint]> Errrr, sorry. I was correcting myself. 16.42.15 # The best is to adapt to Android NATIVE UI using jni at present 16.46.18 # And we can drop theme support for the very first versions 16.48.40 # Yeah I know that's one of the main features but most users want a usable one, not a fully-customizable one. 16.51.36 Join scorche|1h [0] (~scorche@squisch.net) 16.51.36 Quit scorche|1h (Changing host) 16.51.36 Join scorche|1h [0] (~scorche@rockbox/administrator/scorche) 16.52.36 # I recall suggesting percent positioning quite a long time ago... :-) 16.53.08 # of course, talking is easy 16.53.51 # scaleable graphics would be useful for this 16.55.57 # <[Saint]> Zagor: i recall you doing more than suggesting it. 16.56.22 # yeah, right. I did some work too. never finished though. 16.56.40 Quit ruskie (*.net *.split) 16.56.40 Quit fs-bluebot (*.net *.split) 16.56.41 Quit rbert (*.net *.split) 16.56.41 Quit Provel (*.net *.split) 16.56.41 Quit scorche|sh (*.net *.split) 16.57.01 Join Provel [0] (~Provel@97-88-171-31.dhcp.stls.mo.charter.com) 16.57.18 # <[Saint]> I seem to recall you trying and then some form of "crap, this is harder than it should be". 16.57.50 # <[Saint]> And then lots of discussion around native ui. 16.58.47 # I don't remember exactly. but I knew it was never going to be a perfect solution, so I can imagine that put a damper on my enthusiasm for spending long hours fixing it. 16.59.02 # <[Saint]> right. 16.59.38 # a rockbox lib and native UI is basically the only sane way 17.00.17 # <[Saint]> I regret not seeing that earlier on SOOO much. 17.01.04 # :) 17.01.10 Quit Zagor (Quit: Clint excited) 17.01.25 Quit fragilematter (Quit: Leaving.) 17.01.43 # <[Saint]> I feel partly responsible for it. I was adamant that the skin engine could be made to work around the areas we fell down in. 17.02.14 Join ruskie [0] (ruskie@sourcemage/mage/ruskie) 17.02.22 Join rbert [0] (~robin@141.70.11.4) 17.02.57 # <[Saint]> What a fool hindsight can make one seem. :-/ 17.04.49 Quit krabador (Quit: It's Time To Take The Time!!!) 17.06.23 *** Saving seen data "./dancer.seen" 17.11.00 Join krabador [0] (~darkarch@unaffiliated/krabador) 17.44.50 Join wodz [0] (~wodz@89-75-151-160.dynamic.chello.pl) 17.45.17 # pamaury: with your fixes commited I get this: http://pastie.org/8726658 17.48.13 # wodz: did you compile the hwstub library in utils/hwstub/lib ? 17.53.01 Quit uw (Quit: Leaving) 17.53.48 Quit mortalis (Ping timeout: 250 seconds) 18.30.42 # i see that the new clip model is somewhat available in various stores around the US, has anyone gotten a hold of one and opened it yet? 18.31.19 # i'm betting on it being imx233 fwiw 18.31.38 # I bet you'd win that bet 18.32.26 # with any luck we can delay pamaury's phd even more 18.32.35 # LOL 18.39.22 # as you guys are using the imx far more efficiently than sandisk you might get an incredible battery life out of the clip sport.. 18.39.52 # <[Saint]> Gah. 18.40.13 # <[Saint]> The manual entry for the WPS context menu is...somewhat lacking. 18.40.31 # <[Saint]> "Like the context menu for the File Browser, the WPS Context Menu allows you quick access to some often used functions." :-/ 18.40.46 # oh wel 18.40.47 # l 18.40.50 # <[Saint]> Technically correct, rather bland. 18.41.05 # <[Saint]> Yay. .tex for me when I wake up. 18.41.14 # <[Saint]> (note: not yay at all) 18.45.10 # seems like the clip sport updates its database way faster than the clip zip: http://anythingbutipod.com/forum/showthread.php?t=73402&page=6 18.52.07 Quit krabador (Remote host closed the connection) 18.54.43 Join bertrik [0] (~quassel@ip117-49-211-87.adsl2.static.versatel.nl) 18.54.43 Quit bertrik (Changing host) 18.54.43 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 19.05.14 Quit scorche|1h (Ping timeout: 272 seconds) 19.05.56 Join scorche|sh [0] (~scorche@rockbox/administrator/scorche) 19.06.24 # 128x128 - is the screen bigger than the zip's 96x96, or just finer resolution? 19.06.26 *** Saving seen data "./dancer.seen" 19.06.33 # it's bigger 19.06.46 Join krabador [0] (~darkarch@unaffiliated/krabador) 19.07.21 # 1.44" 19.07.53 # Zip was, 1.1" I think? 19.08.01 # I think so, yes. 19.08.52 # according to the reviewer, the clip sport's screen is much better than the clip zip's. that's good news.. 19.09.49 # stiffer buttons and tighter headphone jack, too. but his clip zip might just be worn out.. 19.13.22 # Here's a mock-up someone did of Rockbox running on it: http://cdn.head-fi.org/f/f2/500x1000px-LL-f2dc6edf_sansa_clip_generations.jpeg 19.14.29 # I prefer the cabbie themed model: http://oi62.tinypic.com/mm78rb.jpg 19.21.44 Join lebellium [0] (~chatzilla@89-93-178-161.hfc.dyn.abo.bbox.fr) 19.25.54 Nick whiskers75 is now known as whisk (~whiskers7@unaffiliated/whiskers75) 19.26.02 Nick whisk is now known as whiskers75 (~whiskers7@unaffiliated/whiskers75) 19.27.34 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 19.45.08 Quit pamaury (Ping timeout: 272 seconds) 19.51.13 # looking forward to hacking a clip zip sport 19.52.00 # It sure looks like a big improvement over the clip zip other than the stop button issue.. 19.52.06 Quit wodz (Ping timeout: 260 seconds) 19.53.44 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 19.55.31 # <[Saint]> Given the stated information, I'm not sure how you can come to that conclusion. 19.55.45 # <[Saint]> All we know is it has a feature we probably won't us, and a pretty case. 19.55.48 # <[Saint]> *use 19.55.56 # bertrik: Clip Sport* :P 19.59.24 # they even dropped the Sansa name 20.01.01 # What feature we won't use? Certainly we would use the 128x128/1.44" screen real estate, and the faster processor, and the doubled storage :) 20.01.13 # oh, saw it still mentioned on amazon. Is it already up on the sandisk web page? 20.01.20 # yes 20.01.29 # and they have a forum for it, too 20.01.35 # ZincAlloy: they already dropped it before. On the recent Clip+ it's written "sandisk" instead of "sansa" on the front. And on the Clip Zip it's also written Sandisk 20.01.57 # Best Buy has the 4 & 8 ones in the US on sale now, 16s are showing up on eBay from Israel. 20.02.14 # but the clip zip still has the sansa logo on the back 20.02.22 # Ok, I see it on the sandisk page. I hope it's bascially a zip with an upgraded screen, for easy porting 20.03.28 # The back says sandisk. It is bigger than the zip, not just the screen. 20.04.01 # interesting. according to the specs it was pretty much the same size 20.04.55 # look at the pics in page 4 of this thread: http://www.head-fi.org/t/697524/clip-zip-sport-16gb/45 20.05.56 # so is a clip+ the same size as a clip zip? 20.06.59 # <[Saint]> toehser1: ....errrr...the SoC has been confirmed? 20.07.40 # <[Saint]> re: what feature won't we use? - that crappy FM gym/fitness center local radio crap. 20.08.13 # Oh - right. I so much "won't use" that, that I had already tuned it out (so to speak). 20.08.36 # <[Saint]> Care to comment on your apparent inside knowledge of the SoC? 20.08.48 # would that be any different from a regular fm tuner? 20.09.03 # <[Saint]> ZincAlloy: Not at all. :) 20.09.16 # I vaguely remember unlocking the diagnostic mode on my zip by pressing *all* buttons at once during boot, I'll try that again. Maybe if someone does that on the sport, we can get some extra info about the internals. 20.09.20 # <[Saint]> Doesn't stop them advertising it as a feature. 20.09.42 # sounds like good marketing to me 20.11.43 # * [Saint] puts the SoC statement down to assuming that probablies are definitlelies 20.11.57 # <[Saint]> (but feel free to hit me with a source if there is one) 20.13.07 # <[Saint]> I'm willing to believe that the mold hasn't been broken from the other past variants and the HW is very much what we'll expect it to be 20.14.17 # does anyone know what the current firmware version of the clip sport is? 20.14.46 # no 20.14.56 # I'm extrapolating from the user who found that db operations were much faster than on previous ones, but that may be because they've fundamentally changed their database implementation, not because of the hardware, based on other comments. 20.14.58 # we know nothing about it because usual users don't care about anything 20.15.10 # devs are obliged to buy it :) 20.18.17 # clip zip is slightly bigger than clip plus, but not nearly as much bigger as the sport seems to be. I haven't found the dimensions posted, but there is the side-by-side with a clip+ picture, and there are side-by-sides of course between zip and plus. 20.18.57 # <[Saint]> toehser1: such extrapolation is flawed 20.19.07 # <[Saint]> It could simply boil down a a faster NAND. 20.19.30 Quit rbert (Quit: Verlassend) 20.19.34 # <[Saint]> Its likely, indeed, but I'd like to avoid pure speculation. 20.20.35 # we can only speculate as long as noone bothers to buy a player ^^ 20.21.23 # <[Saint]> No, we know two things at least. It has a "pretty" case and an FM non-feature. 20.21.26 # <[Saint]> ;) 20.21.46 # and a larger screen. and better battery life. 20.22.10 # <[Saint]> Well, we know the stated battery life. 20.22.19 # <[Saint]> Runtime has yet to be seen in the wild. 20.22.30 # and since the player is physically bigger than the clip zip that can mean two things: it uses a more efficient chip or it has a bigger battery. 20.22.58 # I assume it's somewhat realistic 20.23.15 # <[Saint]> How does bigger player == more efficient SoC? 20.23.30 # bigger screen 20.23.32 # it means a bigger battery could fit in 20.24.57 # <[Saint]> The battery part is understandable. But I don't quite get how bigger player directly equates to a more efficient SoC. 20.25.28 # it doesn't. more efficient SoC is a possible explanation for the better battery life 20.25.46 # <[Saint]> I'm almost willing to bet cash money on it being an SoC we've seen in this range before. 20.26.04 # That's very likely 20.26.18 # I hope so - that makes a port much easier, doesn't it? 20.26.23 # considering their history 20.26.28 # <[Saint]> Much so. 20.27.03 # <[Saint]> It would be fun to disassemble and see what lessons, if any, they learned from Rockbox. 20.27.09 # my guess is its probably a fuze+ in a different package, imx is so cheap no sense designing something new 20.27.21 # <[Saint]> saratoga: That's what I'm guessing too 20.27.26 # considering the firmware reviews: probably not much at all 20.27.32 # <[Saint]> Just a pretty case on the same old same old. 20.27.52 # which is not a bad thing 20.28.02 # retail price of the whole SOC is like 4 dollars 20.28.10 # * [Saint] nods 20.28.11 # order 10 million and its probably way less 20.28.39 # <[Saint]> They possibly even fabricate themselves? 20.28.45 # <[Saint]> Big enough to. 20.29.32 # <[Saint]> I wouldn't be terribly surprised if they had holdings in a fabrication plant. 20.30.34 # freescale would handle that 20.32.19 # parts like this are fabbed on some ancient process familiar to the vendor to keep costs low, porting it to some modern fab would be cost prohibitive 20.32.52 # plus the analog bits are not friendly to porting 20.36.06 # <[Saint]> Oh. Yeah. Right. Indeed, if they aren't making their own flash controllers for sd, its unlikely they're fabricating SoCs. 20.36.25 # <[Saint]> I have no idea why I didn't think of that. 20.38.05 # <[Saint]> (partial backstory: like almost everyone else they seem to be doing little more than repackaging Toshiba controllers) 20.38.05 # funny that they haven't bothered to include microsdxc support 20.38.31 # looking on line its done in 90 nm lp, so probably some old motorola fab left over from the mid-2000s 20.38.53 # although thats quite a bit newer than AMS, so probably why battery life is better 20.39.05 # <[Saint]> 90nm?!? 20.39.12 # <[Saint]> Slightly larger than I expected. 20.39.41 # <[Saint]> I guess these don;t really need such fine processing, though. 20.40.29 # AMS was 130 nm 20.40.36 # most PP was 180 nm 20.40.46 # theres a reason these things cost a few dollars each 20.40.51 # <[Saint]> I knew PP was huge (not really, for its time). 20.41.13 # * whiskers75 hugs [Saint] 20.41.13 # its funny to see these ancient processors on semi-modern fab processes though 20.41.21 # ARM9E was designed on 250 nm I think 20.41.23 # <[Saint]> But the other two I find a little surprising 20.41.32 # arm7tdmi isn't much younger then CMOS itself 20.41.52 # * [Saint] looks at his faithful iPod 20.42.16 # * whiskers75 looks at his faithful Sansa Clip+ 20.43.06 # "Samsung microSD cards contain an ARM7TDMI controller with 128 KB of code." 20.43.08 # haha 20.43.18 # so they have the 7tdmi at least running on 45 nm, maybe newer 20.43.46 # hug a developer day! 20.43.53 # * whiskers75 hugs saratoga 20.45.14 # <[Saint]> A little offtopic, but I wonder if we will ever actually see 2TB SDXC in our lifetime, or ever. 20.45.35 # <[Saint]> (for instance, if a newer format comes along and kills uSD) 20.45.49 # <[Saint]> However unlikely that may be. 20.45.54 # probably in SDXC 20.46.02 # maybe not microSDXC 20.46.17 # <[Saint]> whoops. right. forgot a u 20.46.33 # i don't see SDXC going away anytime in the next decade 20.46.56 # <[Saint]> I'm surprised SD has lasted as long as it has. 20.47.08 # i'm not sure if it will be possible to put 2TB in a uSDXC card using CMOS flash cells 20.47.15 # <[Saint]> Hell...some things use CF still. 20.48.41 # <[Saint]> I suppose we'll have to look semi-seriously into exFAT support in the near-ish future, assume the project survives and maintains relevance. 20.48.50 # <[Saint]> *assuming 20.48.52 # i don't think it would be very hard to do 20.49.02 # the exfat libraries i saw looked fairly simple 20.49.27 # theres not a huge need at the moment though since reformatting to fat32 is pretty easy 20.49.39 # <[Saint]> Hah. 20.49.45 Join rela [0] (~x@pdpc/supporter/active/rela) 20.49.52 # <[Saint]> I managed to completely miss exFAT going GPL 20.50.26 # i think theres at least 2 different libraries 20.50.46 # i think samsung open sourced one as well 20.51.15 # <[Saint]> Yeah, hence my prior comment. I found it surprising. 20.51.42 # <[Saint]> Last time I looked there was a very function RE'd implemenation. 20.51.42 # its a simple file format, so reverse engineering it was probably very easy 20.51.51 # compared to say a FTL 20.52.35 Join wodz [0] (~wodz@89-75-151-160.dynamic.chello.pl) 20.53.00 Quit krabador (Quit: It's Time To Take The Time!!!) 20.54.49 Join krabador [0] (~darkarch@unaffiliated/krabador) 20.55.05 # <[Saint]> Oh. Hmmmm. 20.55.22 # <[Saint]> I'm somewhat confused about the legality of the use of exFAT. 20.55.38 Part LinusN 20.55.40 # <[Saint]> It seems it is "open", but still very much protected. IANAL. 20.56.29 # the code is GPL but may still be patent-encumbered in some jurisdictions, notably the USA 20.56.35 # <[Saint]> As in, they gave us the /ability/ to use it, but not the /right/ to. 20.56.50 # <[Saint]> Basically what Galois just said, yeah. 20.57.03 # <[Saint]> TL;DR: Stupid US patent laws shitting on things 20.57.07 # similar to mp3 a few years ago, before the mp3 patents expired 20.58.01 # <[Saint]> Didn't the US extend the term of utility patents fairly recently? 20.58.14 # <[Saint]> (recent in terms of "not a massive amount of time ago) 20.58.19 # no? it's 20 years from date of filing 20.58.25 # the last extension was in like 1992 or something 20.58.57 # <[Saint]> Oh geez. How do I remember 1995? 20.59.05 # you're right, 1995 20.59.07 # <[Saint]> Man... 20.59.14 # "For applications filed before June 8, 1995, the term is either 17 years from the issue date or 20 years from the earliest claimed domestic priority date, whichever is longer." 20.59.22 Quit chrisjj (Ping timeout: 245 seconds) 20.59.31 # <[Saint]> Where'd you dig that up? 20.59.39 # wikipedia https://en.wikipedia.org/wiki/United_States_patent_law 20.59.49 # <[Saint]> Ah. Thanks. 20.59.54 # copyright terms were extended in 1998, by 20 years, to protect mickey mouse 21.00.12 Quit saratoga (Ping timeout: 245 seconds) 21.00.14 # count on another extension of copyright terms in 2018, when mickey mouse comes under threat again 21.00.57 # <[Saint]> Getting wildly offtopic, but if Mickey Mouse is still relevant enough to need that protection in 2018, I fear I may kill myself. 21.01.46 # why does mickey mouse need copyright protection at all? wouldn't the appearance be trademarked? 21.02.13 # the early films are, of course, copyrighted. Disney doesn't want you copying those exact movies. 21.06.27 *** Saving seen data "./dancer.seen" 21.06.35 Quit rela (Read error: Connection reset by peer) 21.10.01 Quit y4n (Quit: AMIGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAHAHAHAAAAAAAAAAAAHAHAAA) 21.10.11 Join LinusN [0] (linus@giant.haxx.se) 21.14.45 # <[Saint]> ZincAlloy: or the stripped down version " 'cos, USA". 21.15.40 Quit shamus (Ping timeout: 245 seconds) 21.15.54 # <[Saint]> Land of the free, harley davidson, bald eagles, and the violently litigious. 21.16.05 Join shamus [0] (~shmaus@ip-206-192-193-180.marylandheights.ip.cablemo.net) 21.20.38 Join pedro_angelo [0] (~pedro_ang@201-19-53-120.user.veloxzone.com.br) 22.01.53 Quit [Saint] (Remote host closed the connection) 22.04.02 Join [Saint] [0] (~saint@rockbox/staff/saint) 22.24.43 Quit ender` (Quit: Documentation is like sex: when it's good, it's very good, and when it's bad it's still better than nothing.) 22.28.38 # pamaury: (log) Yes, hwstub/lib was not compiled and this was my complaint about build system. Anyway recent qeditor crashes when attempting to connect with older hwstub. I didn't try with recent hwstub yet. 22.31.25 Quit amayer (Quit: Leaving) 22.31.38 Join amayer [0] (~amayer@mail.weberadvertising.com) 22.31.50 Quit amayer (Remote host closed the connection) 22.34.02 Join LittleAnon [0] (~smuxi@g138199.upc-g.chello.nl) 22.34.10 # yes, here I am again. 22.36.16 # my sansa clip doesnt seem to want to read what I have on my sd card! I thought it would do it automaticly, ive rebooted a few times and used the Initiliaze + update now setting a few time, and waited for hours while I assumed it was doing that in the background, but it STILL doesnt read it and I have no indication that it actually did something 22.36.21 # so what do I do? 22.37.02 # In which file sits database code? 22.39.46 # What do you mean? 22.39.48 Quit kuldeepdhaka (Ping timeout: 250 seconds) 22.41.14 Quit fyre^OS (Quit: quit) 22.42.10 # LittleAnon: This question wasn't directed to you. 22.45.27 Quit wodz (Quit: Leaving) 22.48.29 Quit bluebrother (Disconnected by services) 22.48.34 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 22.54.04 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 22.59.43 # wodz (logs): can you trace back the crash of hwstub lib ? 23.00.20 # the newer version certainly won't work with older hwstub since I changed the protocol but it shouldn't crash 23.00.21 Quit myndzi (Ping timeout: 265 seconds) 23.02.09 Join myndzi [0] (myndzi@2600:3c00::f03c:91ff:fedf:3d4e) 23.03.04 Quit LittleAnon (Remote host closed the connection) 23.03.24 # <[Saint]> LittleAnon: My first though would be to check that you haven't excluded this path from database scanning. 23.04.16 # <[Saint]> *first thought 23.06.28 *** Saving seen data "./dancer.seen" 23.28.16 Quit bertrik (Read error: Connection reset by peer) 23.28.23 Quit pamaury (Read error: Operation timed out) 23.30.00 Join fs-bluebot [0] (~fs-bluebo@g231121243.adsl.alicedsl.de) 23.30.14 Quit pedro_angelo (Remote host closed the connection)