--- Log for 26.05.113 Server: leguin.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 8 days and 21 hours ago 00.14.21 Quit krabador (Read error: Connection reset by peer) 00.20.06 Join krabador [0] (~krabador@unaffiliated/krabador) 00.39.53 *** Saving seen data "./dancer.seen" 00.47.54 Quit funman (Ping timeout: 276 seconds) 01.03.02 Quit krabador (Ping timeout: 260 seconds) 01.06.59 Quit bertrik (Remote host closed the connection) 01.25.55 # has anyone else noticed this: FS#12864 - Automatic Resume behavior inconsistent on 3.13 01.25.56 # http://www.rockbox.org/tracker/task/12864 3Automatic Resume behavior inconsistent on 3.13 (bugs, unconfirmed) 02.04.45 Quit ender` (Quit: Religion is an insult to human dignity. With or without it you would have good people doing good things and evil people doing evil things. But for good people to do evil things, that takes religion. -- Steven Weinberg) 02.05.23 Quit shamus (Read error: Connection reset by peer) 02.05.36 Join shamus [0] (~shmaus@ip-206-192-195-49.marylandheights.ip.cablemo.net) 02.11.45 Quit lebellium (Quit: ChatZilla 0.9.90 [Firefox 22.0/20130521223249]) 02.35.29 Join funman [0] (~fun@rockbox/developer/funman) 02.39.57 *** Saving seen data "./dancer.seen" 02.42.45 Quit Wardo (Read error: Connection reset by peer) 02.43.19 Join SuperBrainAK_ [0] (~Andreas@97-124-74-93.phnx.qwest.net) 02.45.56 Quit SuperBrainAK (Ping timeout: 248 seconds) 02.47.39 Quit SuperBrainAK_ (Ping timeout: 246 seconds) 02.50.48 Quit funman (Ping timeout: 246 seconds) 02.51.42 Join SuperBrainAK [0] (~Andreas@71-36-166-167.phnx.qwest.net) 02.57.38 Join funman [0] (~fun@rockbox/developer/funman) 03.37.31 Quit ball (Quit: I like pie) 03.58.28 Join krabador [0] (~krabador@unaffiliated/krabador) 04.07.36 Quit krabador (Read error: Connection reset by peer) 04.11.51 Quit amiconn (Disconnected by services) 04.11.51 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.11.53 Quit pixelma (Disconnected by services) 04.11.53 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.11.55 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.11.55 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 04.27.10 Nick [Saint] is now known as [Sinner] (~saint@rockbox/user/saint) 04.28.10 Nick [Sinner] is now known as [Saint] (~saint@rockbox/user/saint) 04.39.58 *** Saving seen data "./dancer.seen" 05.11.26 Quit TheSphinX^ (Ping timeout: 240 seconds) 05.12.08 Join TheSphinX^ [0] (~briehl@p5DD457A7.dip0.t-ipconnect.de) 05.39.05 Join efyx__ [0] (~efyx@10.207-241-81.adsl-dyn.isp.belgacom.be) 05.40.49 Quit efyx_ (Ping timeout: 256 seconds) 05.47.17 Quit prof_wolfff (Ping timeout: 248 seconds) 05.55.21 Quit [7] (Disconnected by services) 05.55.29 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 05.58.01 # ohh 05.58.06 # new rockbox 05.58.11 # i have been here but now 05.58.21 # * Mir knows what he will be doing tomorrow 05.58.44 # * Mir is still on 3.10 05.59.45 # <[Saint]> Heh - if RaaA ever makes it to Google Play, we'll have to make sure it is signed by a different machine then the build we push here. Unless I'm reading the new Google Play policy wrong. 06.00.17 # <[Saint]> An app hosted thereon can no longer update or replace itself from an outside source - does this include sideloading? 06.02.51 # what is RaaA 06.03.05 # <[Saint]> Rockbox as an Application 06.10.53 Join saratoga__ [0] (123e1cf8@gateway/web/freenode/ip.18.62.28.248) 06.11.21 # you need to have one machine sign it I think otherwise you wont' be able to push updates since the keys won't match 06.12.22 # you can always sideload anything, but google forbids you to have the app sideload itself automatically 06.18.18 # <[Saint]> The wording makes me unsure of possible scenarios. 06.18.59 # <[Saint]> As far as I can piece it together, if we offered a binary here, it would need to be signed by a different machine than that which signed the one on the Play Store. 06.19.43 # <[Saint]> Since we could potentially offer a signed, yet deliberately crafted malware ridden binary. 06.32.52 # i don't see why 06.33.10 # lots of projects release both store and HTTP downloads 06.33.24 # <[Saint]> I basically read it as: "If its on Google Play, it isn't allowed to update via any outside sources" 06.33.29 # i think you want them both signed by the same machine so that one can update the other (although i'm not sure about that..) 06.33.42 # no it just means the app itself can't side load 06.33.48 # like facebook used to do 06.33.51 # <[Saint]> Yeah, that would be a "no-do" as far as understand. 06.33.59 # where it would download new APKs and install them directly 06.34.01 # <[Saint]> That's what they're combatting specifically. 06.34.09 # they don't care if the user sideloads 06.34.24 Quit bluebrother (Disconnected by services) 06.34.29 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 06.34.40 # they want to avoid the case where someone puts a legit app on the market, and then has it sideload its own malware without the user being aware 06.34.55 # if the user goes and downloads something manually, then they don't care 06.35.08 # since presumably the user knows what they're doing 06.35.51 # <[Saint]> That's rather dangerous, IMO. 06.36.08 # <[Saint]> I would suggest that a lot of users /think/ they know what they're doign :) 06.36.39 Quit fs-bluebot (Ping timeout: 256 seconds) 06.37.20 # <[Saint]> The thing I'm unsure about is whether or not the key can be shared. If it is acceptable to have an instance on the Play Store that is capable of being updated by a sideloaded binary or not. 06.37.36 # <[Saint]> Or, if (safer, much so) they would need seperate keys. 06.37.58 Join fs-bluebot [0] (~fs-bluebo@g226070015.adsl.alicedsl.de) 06.40.02 *** Saving seen data "./dancer.seen" 06.45.07 # Build Server message: 3Build round completed after 487 seconds. 06.52.22 # jhMikeS: if you want an excuse to do some arm asm, can i suggest libopus's kissfft library? 06.53.34 # you can 06.54.06 # Wanted SPC to make up for resampler, which it does, and can call that done 06.55.24 # I do have something going that allows that output samplerate to be set, but it will be a setting. I'll never implement on the fly switching, ever. 06.56.45 # Any preference, 44.1kHz or greater that the hardware supports 06.59.51 # saratoga: the one in libopus/celt, eh? 07.04.08 # having a 48k option would be great 07.04.17 # i've wanted to try that for a long time, but never got a chance 07.04.28 # jhMikeS: yeah the celt one, its quite slow right now 07.04.39 # 2-3x slower than the MDCT lib 07.04.40 # saratoga_: I think jmspeex is talking about reworking it to make it more SIMD-friendly. 07.04.51 # But that is likely weeks/months away. 07.05.03 # derf: probably won't help us too much since we're on armv4-5 07.05.17 Join jmspeex [0] (~jm@mf4-xiph.osuosl.org) 07.05.26 # speak of the devil 07.05.27 # saratoga_: it gets 48k if hardware has it 07.05.39 # I mean, jmspeex is sitting at the desk next to me. 07.05.45 # so basically a user setting for 44.1/48k? 07.06.08 # 44.1 any anything greater that the hardware has 07.06.30 # or, unless it's 48k, just have no option, which could be done 07.06.45 # otherwise is 64, 88, 96 07.06.52 # this is for the entire dsp pipeline or just spc? 07.07.10 # anyway, i still want to look at kissfft, but haven't had time 07.07.11 # dsp, mixer and anything using that 07.07.18 Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) 07.07.18 # ah that would be great 07.07.32 # saratoga_: which kissfft? 07.07.41 # it's basically like that global sound card setting for mixed audio 07.07.41 # isn't that what opus uses? 07.07.51 # maybe i'm forgetting 07.08.36 # saratoga_: I mean I heavily modified it and doesn't look like the original 07.08.37 # bl 07.08.39 # bbl 07.09.13 # anyway, it would be very easy to make a lot faster on armv4/v5 07.10.06 # IIRC, the pre/post rotations and radix-3 and radix-5 (or maybe it was 4???) together are like 30 lines long and account for a majority of the entire decode time 07.10.18 # since gcc makes a mess of them 07.18.26 Quit SuperBrainAK (Quit: pbly gone to sleep (-.-)Zzz...) 07.21.35 # saratoga_: I've also recently made it easy to optimize several other functions by making them all use the same code 07.21.50 # celt_autocorr(), pitch_xcorr(), celt_fir() and celt_iir() 07.22.11 # IIRC, from the ARMv4 benchmarks, libopus would be faster than some commerical AAC decoders with just the FFT changes 07.22.27 # in celt mode at least 07.22.27 # cool. Didn't know AAC sucked that much :-) 07.22.30 # never looked at the rest 07.22.40 # commerical decoders are often not very good, no 07.23.14 # the think with the MDCT is that there's some algorithmic optimizations that are possible 07.23.26 # and generally you want to do those before writing assembly 07.23.48 # IIRC it looked pretty good 07.23.49 # <[Saint]> commercially speaking, realtime on the intended target is the benchmark really...no? 07.24.04 # <[Saint]> anything more than that is wasted effort/wages. 07.24.16 # its basically the ffmpeg MDCT except with kissfft instead of the ffmpeg split radix power of 2 one 07.24.53 # but it was last fall since i looked so maybe i'm forgetting 07.25.05 # saratoga_: Apparently there's a way to merge the first state of the FFT with the MDCT rotations 07.25.15 # Also, possibly getting rid of bitreverse 07.25.37 # otherwise arvm4/5 isn't that complicated. It's SIMD that requires a lotof thinking 07.25.58 # IIRC the tremor MDCT does that 07.26.07 # possibly 07.27.16 # the thing is gcc has so much trouble with this kind of cold on old arm systems that algorithmic changes actually aren't so important 07.28.11 # just getting something that doesn't spent half its time spilling registers to memory is more important 07.28.33 # if you can use the v5E DSP instructions and ldm/stm, thats even better 07.28.47 # saratoga_: Yes I understand, but if you can avoid lots of loads that can still help 07.29.04 # The other issue is maintenance if we end up changing the existing MDCT 07.29.06 # [Saint]: Battery life. 07.29.17 # true 07.29.55 # although I think opus + mp3 are the only codecs we have that actually use their own MDCTs 07.30.02 # People often tend to jump to assembly a bit too soon 07.30.07 # since they're the only ones that have funny sizes 07.30.15 # Well, I mean, Rockbox has been shipping Opus for a year. 07.30.47 # saratoga_: Did you benchmark the Opus MDCT on powers of two against the one you're using 07.31.00 # no i didn't, but it'll lose horribly 07.31.04 # Maybe the solution is to add non-2 radices to your MDCT? 07.31.05 # if ASM is enabled 07.31.24 # No, I mean in an apples-to-apples comparison 07.31.37 # we can decode an entire WMA 128k stream in less time than the Opus FFT (not including MDCT rotations) needs 07.31.44 # The Opus MDCT "does the job", but I certainly welcome something better 07.32.11 # its not clear to me how to reuse bits of the other FFT for non-powers of 2 07.32.35 # i guess it might just be a case of adding the other radix powers 07.33.42 # not sure how the shuffling works in that case 07.34.09 # saratoga_: could also be checking why yours is better and changing the Opus code to do that 07.34.22 # ours is just the ffmpeg one with a lot of arm asm 07.34.24 # e.g. does it have a bitrev step? 07.34.29 # It's better because it wasn't written by gcc. 07.34.34 # we ported it over a couple years ago when we switched from tremor's 07.34.46 # derf: just because of that? 07.34.56 # jmspeex: Have you seen gcc's ARM asm? 07.35.02 # It is atrocious. 07.35.12 # I have 07.35.21 # on v4? 07.35.23 # But it doesn't mean it's the *only* factor 07.35.27 # i gather its better on newer arm systems 07.35.39 # Maybe for very recent gcc's. 07.35.42 # I write ARM assembly in the past for Speex 07.35.46 # It certainly wasn't as of 4.5. 07.35.49 # (not just operators) 07.36.14 # for a while i used the old ffmpeg FFT (before they got a split radix one), and it was actually quite fast when compiled by gcc 07.36.38 # but it was a dumb fft that didn't do anything fancy so that probably helped gcc a lot 07.38.05 # saratoga_: One important questions is what's the mul you want to use 07.38.09 # from the wiki, the old WMA decoder ran at 45MHz for 128k on ARM7TDMI, this was back with an all-c power of 2 FFT 07.38.29 # so thats probably ~25Mhz for MDCT 07.38.39 # i'll see if i can find better measurements 07.39.10 # on armv4 that would be 32x32=64, on newer, it'd be nice if we could use 32x16 but i have no idea if thats possible 07.42.01 # jmspeex: http://pastebin.com/hZ2eQ7sJ (tested on ARM7TDMI) 07.42.23 Quit JdGordon (Ping timeout: 256 seconds) 07.42.34 # mdct_backward (and those other functions) are from libtremor 07.43.09 # saratoga_: Our current kissfft uses 16-bit twiddles and 32-bit data, so you can do 32x16 muls. 07.43.12 # saratoga_: why no idea if it's possible? 07.43.49 # (in fact C_MULC has already been written to use them for ARMv5E) 07.44.40 Join JdGordon| [0] (~jonno@101.174.205.167) 07.44.40 Quit JdGordon| (Changing host) 07.44.40 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) 07.44.44 # oh yeah, forgot I did that :) 07.45.06 # It's been backported to mainline now. 07.45.22 # And used for the forward FFT as well. 07.46.58 # oh cool 07.47.58 Quit yosafbridge (Ping timeout: 246 seconds) 07.49.08 Join yosafbridge [0] (~yosafbrid@li125-242.members.linode.com) 08.03.21 # saratoga_: Maybe it's worth just doing a straight asm optimization of the current MDCT to see where the bottlenecks end up 08.03.39 # It'll be useful in the short term and it could guide further improvements 08.08.31 # yeah 08.08.45 # probably it'll make it fast enough that its not important to make it faster on older cpus 08.09.05 # we could make tremor go faster too right now, but its almost not worth it since we can't clock CPUs low enough 08.12.24 # actually, i'm surprised you guys care about SIMD, I'd think with good ASM, you'd be able to get down under 25 Mhz just using ARMv6 08.12.46 # whereas anything with NEON is or SSE is probably running in the GHz 08.13.08 # saratoga_: BTW, we use a lot of Q15 operators, but it's probably not hard to convert to Q16 08.13.24 # yeah, i just shifted by one and accepted a tiny bit of rounding error 08.14.16 # saratoga_: Well, the 16-bit twiddles dominate the error. If you lose one but on the data, it doesn't matter much 08.14.51 # saratoga_: About optimizing Opus, part of the idea is to free cycles for video and the rest of the audio pipeline (e.g. AEC) 08.15.26 # yeah, but the amount an audio decoder should use is so small 08.15.31 # compared to video 08.15.47 # we also encode 08.16.02 # ah thats true 08.16.11 # but i guess the MDCT probably doesn't dominate on encode 08.16.24 # Does Rockbox use the encoder at all? 08.16.33 # i don't believe so 08.16.42 # Encoding CELT is cheap, MDCT is a big chunk 08.16.51 # we do have encoders (speex) but i don't think we ported opus yet 08.17.12 # i looked, and our current MDCT is about 14MHz per 1x at 44,1k 08.17.20 # using ARMv4 operations only 08.17.35 # mono or stereo? 08.17.45 # SIMD might get you down to 7-8MHz, but thats a lot of work for just a few MHz of total savings 08.17.48 # stereo 08.18.18 # power of 2 though, no idea if thats a big difference (assume no) 08.18.32 # pretty good 08.18.51 # we can decode some entire transform codecs in less than 20 Mhz 08.18.55 # saratoga_: FYI, at complexity 1 (still easily beats MP3), The Opus encoder is just 50% more complex than the decoder 08.19.00 # could probably do much better but why bother 08.19.07 # the screen will lag if you clock that low anyway 08.19.16 # wow 08.19.28 # thats pretty impressive 08.21.12 # wait found some newer numbers 08.21.19 # 16.37MHz for a stereo 128k WMA stream 08.21.39 # on ARMv5E (with memory run at core speed so a little unfair...) 08.21.50 # Because of the way the bit-stream is designed, the encoder and decoder need to do about the same steps 08.22.02 # ~50% of that is the MDCT, so probably 8 Mhz 08.22.23 # of course thats cheating unless you have a device with a lot of SRAM 08.22.39 # The Opus MDCT tends to be about 33% of total decoder 08.23.04 # no ARMv5E instructions either 08.23.31 # similar to AAC than 08.25.58 # someday i need to look at opus closely and understand whats actually happening in the decoder 08.27.12 # still not entirely clear to me why opus seems to bend the quality/compression/performance curve as effectively as it does 08.29.47 # saratoga_: Fortunately, we just wrote a paper about it 08.29.56 # is it published somewhere? 08.30.11 # Just submitted 08.30.20 # But here it is: http://jmvalin.ca/misc_stuff/aes_opus_celt.pdf 08.30.21 # whats the journal? 08.30.26 # AES convention 08.30.26 # oh cool 08.32.42 # In case you find any error in it, we still have a few days to correct them 08.32.56 # haha i wouldn't worry about that 08.33.37 # i just dabble in this stuff so i don't forget how to program and do math 08.36.24 # i noticed that opus is much slower at low delays, do you have any idea why that is? 08.40.05 *** Saving seen data "./dancer.seen" 08.45.00 # some operations have a fixed cost per frame 08.45.08 # e.g. energy decoding, bit allocation 08.46.24 # BTW, I don't know if you've updated to the current git master, but it's worth it 08.46.39 # We landed lots of optimizations in the past week 08.47.57 # no we're somewhat out of date 08.50.07 # i'm not familiar with this Hadamard based time/frequency thing 08.50.39 # IIUC, the idea is that you can take a set of coefficients from multiple short blocks to improve frequency resolution in some set of bands? 08.50.46 # saratoga_: Think of Hadamard as an approximation to the DCT/IDCT 08.51.05 # exactly 08.51.53 # vaguely similar to the MP3 that runs an MDCT on samples from a certain QMF band 08.52.26 # how does this compare to the subband method, where you split things into bands and then MDCT them? 08.52.44 # i guess it lets you decide on a per frame basis if you want to make the tradeoff, but is there some cost? 08.52.56 # I don't understand what you mean 08.53.41 # so in ATRAC, they split the stream into a couple different frequency bands, and then do different MDCT sizes on each 08.54.02 # IIUC, this is a similiar idea, but i guess the advantage is that you can easily turn it on and off? 08.54.16 # can the MDCT size for a certain band vary over time? 08.54.26 # whereas ATRAC is stuck with the filterbank and MDCT regardless of if it is actually useful 08.54.49 # i think in the newest ATRAC it can, but in the 1 and 3 its fixed at some size 08.55.14 # so in our case, we can change at any time. Also, we can even do the reverse. 08.55.28 # Take a long MDCT and improve the time resolution 08.55.52 # the time resolution isn't as good as starting with short MDCTs, but it can still be useful 08.55.56 # IIUC, there is a some efficiency cost associated with subbands because of the transistion band in the delay of the filterbank, so being able to turn it on and off is probably an advantage? 08.56.38 # well, the idea is to adapt to the signal. 08.57.08 # Imagine you have a piano and a high-hat at the same time frame 08.57.10 # yeah 08.57.21 # i guess for atrac they're actually just trying to make the MDCT not have uniform time resolution 08.57.39 # you can decide to have good freq resolution in the lower bands because it's dominated by the piano and then have good time resolution at higher freq for the high hat 08.57.50 # interesting 08.58.56 # one other question: Opus/CELT and WMA are the only codecs i've ever seen that allow more than 2 transform sizes in the same stream, is there some reason thats so uncommon? 08.59.40 # saratoga_: Opus really allows two sizes, it's just that you can change which two on a frame-by-frame basis 09.00.12 # For codecs like Vorbis, you need different overlap handling for each pair of sizes, so it grows in N^2. 09.00.40 # For Opus, we use the same overlap all the time. There's a quality cost, but we have to pay for it because we want to work in real-time applications 09.03.48 Quit kevku (Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/) 09.07.17 Join ender` [0] (krneki@foo.eternallybored.org) 09.08.33 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) 09.13.23 Quit ruskie (Excess Flood) 09.16.01 Join melmothX [0] (~melmoth@unaffiliated/melmothx) 09.17.34 Join ruskie [0] (ruskie@sourcemage/mage/ruskie) 09.26.06 Join Wardo [0] (~Mirandaha@176-120-190-109.dsl.ovh.fr) 09.49.33 Quit akaWolf (Read error: Connection reset by peer) 09.50.33 Join stoffel [0] (~quassel@pD9E40935.dip0.t-ipconnect.de) 09.51.01 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) 10.26.42 Join Horscht [0] (~Horscht@xbmc/user/horscht) 10.28.46 Quit Horscht (Client Quit) 10.40.07 *** Saving seen data "./dancer.seen" 10.41.37 Quit saratoga_ (Quit: Page closed) 10.43.44 Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) 10.44.55 Join Horscht [0] (~Horscht@xbmc/user/horscht) 10.51.05 Quit jhMikeS (Ping timeout: 240 seconds) 10.52.27 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 10.57.42 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 11.05.06 Quit TheSphinX^ (Read error: Operation timed out) 11.05.34 Nick funman is now known as j-b (~fun@rockbox/developer/funman) 11.08.53 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 11.11.51 Nick j-b is now known as b-j (~fun@rockbox/developer/funman) 11.13.03 Join TheSphinX^ [0] (~briehl@p57A398C1.dip0.t-ipconnect.de) 11.15.44 Nick b-j is now known as funman (~fun@rockbox/developer/funman) 11.28.48 Quit stoffel (Ping timeout: 245 seconds) 11.34.03 Quit pamaury (Ping timeout: 246 seconds) 11.34.27 Join pamaury_ [0] (~quassel@rockbox/developer/pamaury) 11.39.57 Quit KiwiCAM_ (Remote host closed the connection) 11.42.11 # does anyone know a chip manufacturer which logo looks like Pi (mathematical letter) or stylish "JL" ? 11.46.10 Join kiwicam [0] (~quassel@101.98.163.139) 11.50.13 Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 12.04.17 Quit pamaury_ (Quit: this->disconnect()) 12.04.27 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 12.31.33 Join n1s [0] (~n1s@nl118-168-30.student.uu.se) 12.31.33 Quit n1s (Changing host) 12.31.33 Join n1s [0] (~n1s@rockbox/developer/n1s) 12.40.08 *** Saving seen data "./dancer.seen" 13.03.34 Quit [Saint] (Remote host closed the connection) 13.04.48 Join [Saint] [0] (~saint@rockbox/user/saint) 13.23.54 Quit Horscht (Quit: quit) 13.28.29 # anyone can help me find some information about a chip ? marking is logo (pi or "jl") + AC1251H7R691-96 13.47.16 Join prof_wolfff [0] (~prof_wolf@62.83.50.196.dyn.user.ono.com) 13.55.40 Join einhirn [0] (~Miranda@p4FF89141.dip0.t-ipconnect.de) 14.00.02 Quit einhirn (Ping timeout: 245 seconds) 14.00.54 Quit y4n (Read error: Connection reset by peer) 14.01.51 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 14.05.47 Join Horscht [0] (~Horscht@xbmc/user/horscht) 14.13.51 Quit froggyman (Ping timeout: 256 seconds) 14.14.26 Join froggyman [0] (~froggyman@unaffiliated/froggyman) 14.26.55 Quit pamaury (Read error: No route to host) 14.27.02 Join pamaury_ [0] (~quassel@2a01:e35:243f:8460:221:6aff:feaa:cdaa) 14.32.31 # pamaury_: do you have a picture ? 14.33.35 # the internet has pages full of manufacturer logos to help identification 14.33.57 # like http://www.advanced-tech.com/ic_logos/ic_logos.htm 14.34.25 # funman: http://amaury.pouly.free.fr/Images/SSL24936.JPG 14.34.28 # a Pi-like logo doesn't ring a bell for me 14.34.34 # I cannot find it in any list 14.34.35 Nick pamaury_ is now known as pamaury (~quassel@2a01:e35:243f:8460:221:6aff:feaa:cdaa) 14.34.54 Quit pamaury (Changing host) 14.34.54 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 14.35.14 # what kind of device is this? 14.35.45 # angry bird speaker :) 14.40.09 *** Saving seen data "./dancer.seen" 14.45.05 # google image search gives some really weird hits on that chip image :) 14.46.02 # yeah, I tried with a hand modified image but didn't get any useful hit 15.29.36 Join krabador [0] (~krabador@unaffiliated/krabador) 15.29.54 Quit n1s (Ping timeout: 264 seconds) 15.30.40 Join n1s [0] (~n1s@rockbox/developer/n1s) 15.33.11 Join kaputnik_ [0] (~kaputnik@p5DD9CD1B.dip0.t-ipconnect.de) 15.52.45 Quit Horscht (Quit: quit) 15.56.13 Quit Wardo (Quit: Blarglarg) 16.02.48 Join einhirn [0] (Miranda@bsod.vpn.tu-clausthal.de) 16.40.11 *** Saving seen data "./dancer.seen" 16.40.34 Quit guymann (Ping timeout: 252 seconds) 16.41.30 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 16.47.19 Quit [Saint] (Remote host closed the connection) 16.48.31 Join [Saint] [0] (~saint@rockbox/user/saint) 16.48.42 Quit pamaury (Ping timeout: 246 seconds) 17.18.49 Quit Xerion (Read error: Connection reset by peer) 17.19.12 Join Xerion [0] (~xerion@5419F5F4.cm-5-2d.dynamic.ziggo.nl) 17.19.19 Join KiwiCAM_ [0] (~quassel@101.98.163.139) 17.19.42 Quit kiwicam (Ping timeout: 264 seconds) 17.23.32 Quit kevku (Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/) 17.42.17 Join kiwicam [0] (~quassel@101.98.163.139) 17.42.27 Quit KiwiCAM_ (Ping timeout: 252 seconds) 18.00.59 Join Wardo [0] (~Mirandaha@176-120-190-109.dsl.ovh.fr) 18.04.01 Join dionoea_ [0] (~dionoea@oyp.chewa.net) 18.04.05 Join ej0rge_ [0] (~alhaz@207.135.137.71) 18.04.57 Join uwe_mobile__ [0] (~uwe@static.88-198-8-117.clients.your-server.de) 18.17.11 Quit Provel (*.net *.split) 18.17.11 Quit dionoea (*.net *.split) 18.17.11 Quit uwe_mobile (*.net *.split) 18.17.12 Quit ej0rge (*.net *.split) 18.24.30 Quit kaputnik_ (Ping timeout: 264 seconds) 18.32.42 Join Provel [0] (~Provel@75-132-18-44.dhcp.stls.mo.charter.com) 18.40.12 *** Saving seen data "./dancer.seen" 18.45.01 Join guymann [0] (~c@unaffiliated/guymann) 19.18.01 Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) 19.38.13 Join jhMikeS [0] (~jethead71@50.4.247.132) 19.38.13 Quit jhMikeS (Changing host) 19.38.13 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 19.39.05 Join TheLemonMan [0] (~LemonBoy@adsl-ull-88-221.50-151.net24.it) 19.39.05 Quit TheLemonMan (Changing host) 19.39.05 Join TheLemonMan [0] (~LemonBoy@unaffiliated/thelemonman) 19.55.19 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 20.10.41 Quit liar (Ping timeout: 264 seconds) 20.13.10 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 20.18.13 Quit liar (Ping timeout: 256 seconds) 20.19.13 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 20.19.31 Join nosa-j [0] (~m00k@184.76.254.130) 20.20.28 Join cydd [0] (~psychocyd@31.193.12.99) 20.20.39 Part cydd 20.27.15 Quit liar (Read error: Operation timed out) 20.29.27 Join Guest35025 [0] (~liar@clnet-p09-185.ikbnet.co.at) 20.35.39 Quit Guest35025 (Read error: Operation timed out) 20.36.40 Join Guest35025 [0] (~liar@clnet-p09-185.ikbnet.co.at) 20.40.14 *** Saving seen data "./dancer.seen" 20.40.41 Quit Guest35025 (Read error: Operation timed out) 20.41.35 Join cydd666 [0] (cydd@cpc24-york4-2-0-cust463.7-1.cable.virginmedia.com) 20.41.48 Part cydd666 20.47.50 Join krnlyng [0] (~liar@clnet-p09-185.ikbnet.co.at) 20.51.52 Join stripwax [0] (~Miranda@rockbox/developer/stripwax) 20.52.11 Quit bertrik (Remote host closed the connection) 20.58.25 Quit mrtux (Read error: Connection reset by peer) 20.58.29 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 20.58.35 Join mrtux_ [0] (~colin@unaffiliated/mrtux) 20.59.11 Nick mrtux_ is now known as mrtux (~colin@unaffiliated/mrtux) 20.59.35 Quit Scall (Ping timeout: 256 seconds) 21.01.53 Join Scall [0] (~chat@unaffiliated/scall) 21.02.25 Quit krnlyng (Ping timeout: 256 seconds) 21.05.09 Quit krabador (Quit: Bah...) 21.07.00 Quit pamaury (Ping timeout: 246 seconds) 21.08.05 Join krnlyng [0] (~liar@clnet-p09-185.ikbnet.co.at) 21.11.29 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 21.25.46 Join SuperBrainAK [0] (~Andreas@97-124-72-176.phnx.qwest.net) 21.35.26 Quit stripwax (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 21.36.04 Quit akaWolf (Ping timeout: 248 seconds) 21.41.07 Quit mrtux (Read error: Connection reset by peer) 21.41.27 Join mrtux [0] (~colin@unaffiliated/mrtux) 21.44.35 Quit mrtux (Read error: Connection reset by peer) 21.45.01 Join mrtux [0] (~colin@unaffiliated/mrtux) 21.47.19 Join salty-horse [0] (~ori@bzq-79-180-102-35.red.bezeqint.net) 21.48.51 # hey. about 3.13's "Deleting files in the active playlist now works as expected" - does this also handle resuming playback at the correct file, after adding some new files to the same directory? 21.55.48 # never mind. commit 212e780 seems to confirm that :) 21.59.56 Quit TheLemonMan (Ping timeout: 276 seconds) 22.22.47 Quit kiwicam (Remote host closed the connection) 22.38.51 Join kaputnik_ [0] (~kaputnik@port-92-206-20-123.dynamic.qsc.de) 22.39.33 Join stoffel [0] (~quassel@pD9E43C18.dip0.t-ipconnect.de) 22.40.15 *** Saving seen data "./dancer.seen" 22.42.37 Quit Lynx_ (Remote host closed the connection) 22.42.52 Join Lynx_ [0] (~bayer@109.171.130.211) 22.43.13 Quit stoffel (Remote host closed the connection) 23.07.26 Join bertrik [0] (~quassel@ip117-49-211-87.adsl2.static.versatel.nl) 23.07.26 Quit bertrik (Changing host) 23.07.26 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 23.08.08 Quit melmothX (Remote host closed the connection) 23.18.57 Quit krnlyng (Read error: Connection reset by peer) 23.19.26 Join krnlyng [0] (~liar@clnet-p09-185.ikbnet.co.at) 23.25.34 Quit krnlyng (Ping timeout: 256 seconds) 23.31.33 Quit pamaury (Ping timeout: 246 seconds) 23.32.41 Join krnlyng [0] (~liar@clnet-p09-185.ikbnet.co.at) 23.34.46 Quit bertrik (Remote host closed the connection) 23.37.18 Quit kevku (Ping timeout: 260 seconds) 23.42.49 Join SuperBrainAK_ [0] (~Andreas@97-124-74-51.phnx.qwest.net) 23.45.53 Quit SuperBrainAK (Ping timeout: 276 seconds) 23.53.36 Quit kaputnik_ (Ping timeout: 246 seconds) 23.55.02 Quit Wardo (Read error: Connection reset by peer)