--- Log for 28.07.113  Server: pratchett.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 2 days and 5 hours ago

00.01.02 Join    Guest11127 [0] (~Slayer@c-69-143-178-62.hsd1.va.comcast.net)
00.18.35 ***     Saving seen data "./dancer.seen"
00.18.48 Quit    Rower (Quit: soer)
00.19.52 Quit    olspookishmagus (Quit: All for nothing)
00.27.22 Quit    pamaury (Ping timeout: 240 seconds)
00.35.18 Nick    SuperBrainAK is now known as DormantBrain (~andy@shared02.balt01.cd.2g2u.net)
00.52.13 Quit    liar (Ping timeout: 240 seconds)
01.07.43 Quit    theunleet (Quit: CGI:IRC)
01.14.20 Join    syscrash [0] (~syscrash@poipu/developer/syscrash)
01.15.23 Quit    jlbiasini (Remote host closed the connection)
01.31.31 Quit    mirak (Quit: Ex-Chat)
01.42.32 Join    mirak [0] (~mirak@static-176-182-46-92.ncc.abo.bbox.fr)
02.09.22 Quit    bertrik (Ping timeout: 240 seconds)
02.18.39 ***     Saving seen data "./dancer.seen"
03.15.35 Quit    ender` (Quit:  It's not worth doing something unless someone, somewhere, would much rather you weren't doing it.	-- Terry Pratchett)
03.40.56 Join    Beta2K [0] (~Beta2K@d24-36-136-246.home1.cgocable.net)
03.43.50 Quit    lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 23.0/20130722172257])
03.59.53 Join    mrtux_ [0] (~colin@75-167-98-77.desm.qwest.net)
04.01.59 Quit    mrtux (Ping timeout: 264 seconds)
04.01.59 Nick    mrtux_ is now known as mrtux (~colin@75-167-98-77.desm.qwest.net)
04.18.42 ***     Saving seen data "./dancer.seen"
04.29.46 Quit    amiconn (Disconnected by services)
04.29.48 Join    amiconn_ [0] (amiconn@rockbox/developer/amiconn)
04.29.52 Nick    amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn)
04.30.41 Quit    pixelma (Disconnected by services)
04.30.42 Join    pixelma_ [0] (pixelma@rockbox/staff/pixelma)
04.30.44 Nick    pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma)
04.41.33 Quit    mrtux (Quit: ZNC - http://znc.in)
04.42.16 Join    mrtux [0] (~colin@2001:388:f000::26cd)
04.43.14 Quit    mrtux (Changing host)
04.43.14 Join    mrtux [0] (~colin@unaffiliated/mrtux)
04.48.34 Join    Strife89 [0] (~Strife89@adsl-98-80-231-240.mcn.bellsouth.net)
05.13.29 Join    shamus [0] (~shmaus@ip-206-192-195-49.marylandheights.ip.cablemo.net)
05.46.37 Quit    [7] (Disconnected by services)
05.46.50 Join    TheSeven [0] (~quassel@rockbox/developer/TheSeven)
06.18.44 ***     Saving seen data "./dancer.seen"
07.06.37 Quit    CaptainKewl (Read error: Connection reset by peer)
07.09.36 Join    kevku [0] (~kevku@2001:0:c38c:c38c:3c54:79ba:3d69:bedb)
08.03.25 #       * [Saint] notes that the sample rate selector is basically unusable.
08.05.02 #       <[Saint]> I assume there isn't *supposed* to be an audible difference here?
08.07.13 #       <[Saint]> ...that magically fixes itself.
08.07.16 #       <[Saint]> Hummm.
08.10.35 Quit    Strife89 (Ping timeout: 256 seconds)
08.18.48 ***     Saving seen data "./dancer.seen"
08.20.56 Join    Rower [0] (husvagn@v-413-alfarv-177.bitnet.nu)
08.27.45 Nick    syscrash is now known as jvd (~syscrash@poipu/developer/syscrash)
09.36.43 Quit    bluebrother (Disconnected by services)
09.36.48 Join    bluebrother^ [0] (~dom@rockbox/developer/bluebrother)
09.58.57 Quit    shamus (Read error: Connection reset by peer)
10.00.02 Join    shamus [0] (~shmaus@ip-206-192-195-49.marylandheights.ip.cablemo.net)
10.15.01 Join    bertrik [0] (~quassel@rockbox/developer/bertrik)
10.18.51 ***     Saving seen data "./dancer.seen"
10.36.39 Quit    rdn (Remote host closed the connection)
10.41.00 #       <copper> saratoga: well shit, the log is empty
10.42.38 #       <copper> and the battery is full
10.42.50 #       <copper> I saw it running though
10.42.53 #       <copper> dunno what happened
10.43.18 #       <[Saint]> I have seen this happen before now.
10.43.30 #       <[Saint]> It also REALLY chokes on the insane APE.
10.43.47 #       <[Saint]> if you listen to it, its just nasty schreeching and noise.
10.43.52 #       <copper> I removed all ape above c1000, lets see if that fixes it
10.48.45 #       <copper> [Saint]: test_codec decodes as fast as possible, right?
10.49.06 #       <[Saint]> there's no way to do otherwise.
10.49.19 #       <[Saint]> so "yes".
10.50.34 #       <[Saint]> what is the ultimate question behind that one?
10.50.55 #       <copper> I was wondering if instead, it would decode at real time, and measure the CPU frequency or something
10.51.02 #       <copper> in real time*
10.51.39 #       <[Saint]> No. There's no need. As it is trivial to ascertain realtime requirements from the decoding speed.
10.52.06 #       <[Saint]> that would just be a slower, less efficient way of doing what it already does.
10.52.12 #       <copper> last night when I launched it, it put the Fuze+ face down, maybe the abord key was triggered, or something
10.52.22 #       <copper> abort
10.52.48 #       <[Saint]> If so, there should still be logs for everything it completed.
10.53.05 #       <[Saint]> unless it cancelled before a single test finished.
10.53.07 #       <copper> dunno what happened then
10.53.29 #       <copper> right now it's running, and the display is turning on every time it tests a new file, I think
10.58.30 #       <copper> meh
10.58.36 #       <copper> no opus files in the test corpus
11.13.54 Join    jlbiasini [0] (~metaphysi@89.136.132.239)
11.16.23 Join    pamaury [0] (~quassel@rockbox/developer/pamaury)
11.18.08 #       <copper> saratoga: http://pastebin.com/4knGqLKU
11.18.19 Quit    JdGordon (Ping timeout: 246 seconds)
11.23.52 #       <[Saint]> fuck me that's a beast...
11.24.08 #       <[Saint]> that thing is foolishly overpowered.
11.26.20 #       <copper> ah?
11.28.26 #       <copper> oy
11.28.32 #       <copper> MPC is nearly twice as fast as Vorbis
11.32.50 #       <copper> Opus 128kbps: 171.61% real time :-/
11.33.15 #       <[Saint]> 101% is essentially irrelevant.
11.33.30 #       <[Saint]> everything higher than 100% is just a bonus :)
11.36.27 #       <copper> doesn't it mean lower battery life?
11.36.32 Join    JdGordon [0] (~jonno@CPE-121-217-135-158.lnse2.cht.bigpond.net.au)
11.36.32 Quit    JdGordon (Changing host)
11.36.32 Join    JdGordon [0] (~jonno@rockbox/developer/JdGordon)
11.36.52 #       <[Saint]> It does, sure. But I happen to think that anything past 8H is irrelevant.
11.37.02 #       <copper> 8 hours?
11.37.12 #       <copper> because you charge your DAP every night?
11.37.25 #       <[Saint]> Does anyone really *need* 50H+ for a DAP when we can chare basically anywhere these days? :)
11.37.35 #       <copper> chare?
11.37.39 #       <copper> ah
11.37.41 #       <[Saint]> *charge
11.37.51 #       <copper> too much stuff to charge
11.38.07 #       <copper> I appreciate the fact that I only need to charge my DAP like once a week
11.38.13 #       <pamaury> This charging every day habit is killing me
11.38.45 #       <copper> [Saint]: also, fewer battery cycles
11.39.01 #       <[Saint]> I just make sure there's a charger at home, one at work, and one in the car.
11.39.13 #       <pamaury> I appreciate that my daps have longer battery life so that I don't have to bring a charger for example
11.39.17 #       <[Saint]> Haven't had a low battery inyears.
11.40.06 #       <pamaury> And when you phone will last 1 hour on battery will you say "that's ok I have a charger in my pocket" ? ;)
11.40.53 #       <[Saint]> The hilarious thing about that example is that I have been known to charge my DAP from my phone on occasions. :)
11.41.13 #       <[Saint]> And both from my laptop.
11.42.11 #       <[Saint]> Fwiw, I'm not saying that battery life isn't a good thing. I'm just saying that there's no real need to eek out every last cycle for performances sake, really.
11.42.25 #       <[Saint]> There's a point where performance is "Good Enough (TM)"
11.42.57 Quit    JdGordon (Ping timeout: 276 seconds)
11.43.31 #       <pamaury> So one day on battery for your mostly idle phone is good enough ?
11.43.54 #       <[Saint]> How do you come to that conclusion?
11.44.12 #       <[Saint]> I use my phone a LOT, and it does over a full day - so...yes.
11.44.20 Join    JdGordon [0] (~jonno@rockbox/developer/JdGordon)
11.45.09 #       <[Saint]> As long as it lasts me a "working day", I couldn't care less.
11.45.18 #       <copper> [Saint]: double the performance is quite significant IMO
11.45.28 #       <[Saint]> Perhaps I'm a minority. But I see no need for many days worth of battery for devices we use daily.
11.46.02 #       <[Saint]> More to the point, for devices we use for a few hours at a time.
11.46.37 #       <[Saint]> A few years ago, possibly this bothered me...now, charging is so absurdly easy, pretty much anywhere, I couldn;t care.
11.46.50 #       <copper> [Saint]: more charging = less battery life over months or years
11.47.05 #       <bertrik> this doesn't seem right: http://en.wikipedia.org/wiki/Opus_%28audio_format%29#Hardware_support
11.47.29 #       <copper> bertrik: the "hardware" qualification?
11.47.32 #       <bertrik> yes
11.47.40 #       <[Saint]> copper: realistically, honestly, how many batteries have you killed or lessened the lifespan of in a NOTICEABLE fashion?
11.47.42 #       <copper> obviously they mean DAP support
11.48.01 #       <copper> [Saint]: all of my really old gear
11.48.19 #       <[Saint]> If you value said gear. Replace the battery.
11.48.21 #       <copper> especially phones
11.48.26 #       <[Saint]> You'd need to do so eventually anyway.
11.48.34 #       <copper> yes but the later the better
11.48.35 #       <copper> :)
11.48.57 #       <[Saint]> I don't really buy into the "more charging == less lifespan" shit, even if it is true. You'd need to be really anal to notice this.
11.49.22 #       <copper> then let's just say that better performance doesn't hurt? :)
11.49.40 #       <[Saint]> No, I never said it did hurt. I just said it wan't necessarily relevant :)
11.50.07 #       <[Saint]> There is a very clear "Good Enough" line.
11.50.24 #       <copper> running test_codec on opus again, this time with the sampling frequency set to 48kHz
11.50.49 #       <copper> what did you say about that option earlier?
11.51.12 #       <[Saint]> I switched to 48K and everything sounded *reaaaaaaaallly* nasty.
11.51.14 #       <copper> 06:03:26 UTC  * [Saint] notes that the sample rate selector is basically unusable.
11.51.19 #       <[Saint]> Rebooted, and it magically fixed itself.
11.51.23 #       <copper> hmm
11.52.15 #       <copper> bertrik: I think that in that context, "hardware support" usually means anything that doesn't run on a computer
11.52.39 #       <copper> DAPs, hi-fi units, car stereos, etc…
11.53.07 #       <copper> though, I'm not sure how smartphones and tablets should be qualified
11.53.14 #       <copper> those are basically computers
11.53.17 Quit    dv_ (Read error: Operation timed out)
11.54.16 #       <copper> I guess the distinction is whether the hardware platform has a software platform that allows people to write software for it
11.54.28 Join    dv_ [0] (~quassel@chello080108009040.14.11.vie.surfer.at)
11.54.54 #       <copper> explicitely
11.54.57 #       <bertrik> copper: hm, yes, maybe if you twist the meaning of "hardware" enough, you could call it hardware support
11.55.14 #       <copper> that's what people mean by it anyway
11.55.24 #       <copper> it's a shortcut
11.55.56 #       <copper> and that's how people understand it
11.56.22 #       <copper> is there any hardware left with actual hardware support for codecs?
11.56.36 #       <copper> does anyone optimize MP3 playback using a specialized chip anymore?
11.56.48 Quit    JdGordon (Read error: Connection reset by peer)
11.56.54 #       <[Saint]> outside of here?
11.56.57 #       <[Saint]> I doubt it.
11.57.00 #       <copper> even in here
11.57.10 #       <bertrik> I think you still have these gumstick type of very cheap mp3/wma players with some kind of hw accelleration
11.57.14 #       <[Saint]> In here - likely not for many many moons.
11.58.33 #       <bertrik> the gumstick types are too limited to run rockbox
12.00.17 Join    JdGordon [0] (~jonno@rockbox/developer/JdGordon)
12.05.39 #       <copper> the difference in performance between FLAC and everything else is huge
12.06.19 #       <[Saint]> 0.01MHz realtime :)
12.08.28 #       <copper> ok, sampling freq makes no difference in performance for Opus
12.08.35 #       <copper> which was to be expected
12.09.03 #       <bertrik> some nasty re-resampling may be going on for opus though
12.09.27 Join    DuperMan [0] (~Duper@46-116-90-92.bb.netvision.net.il)
12.09.55 #       <bertrik> opus is 48 kHz natively, so it might be that it went from 44.1 kHz source to 48 kHz opus to 44.1 kHz rockbox native to 48 kHz resampled
12.10.09 #       <copper> I know
12.10.30 #       <copper> ah, no, I misread you
12.10.48 #       <copper> is sampling freq is set to 48kHz, why would there be some re-resampling
12.10.49 #       <copper> ?
12.12.17 #       <bertrik> because someone has to make sure and write code that unnecessary resampling is skipped
12.12.43 #       <copper> ah, that's not done yet?
12.13.04 #       <bertrik> it's not clear what the exact status is
12.13.57 #       <bertrik> so, assume the worst :)
12.15.09 #       <copper> the worst would be the DAP exploding in my pocket against my junk
12.15.27 Quit    JdGordon (Ping timeout: 264 seconds)
12.18.55 ***     Saving seen data "./dancer.seen"
12.21.14 #       <[Saint]> Nahhh...nothing there of interest. ;)
12.21.49 Join    y4n [0] (~y4n@unaffiliated/y4ndexx)
12.22.19 Join    JdGordon [0] (~jonno@CPE-121-218-128-223.lnse3.cht.bigpond.net.au)
12.22.25 Quit    JdGordon (Changing host)
12.22.25 Join    JdGordon [0] (~jonno@rockbox/developer/JdGordon)
12.28.31 #       <copper> cpu frequency of the Fuze+: 64000
12.28.42 #       <copper> cpu frequency of the iPod Classic: 54000000
12.28.45 #       <copper> what does it mean?
12.30.05 #       <[Saint]> different units of measure?
12.30.51 #       <copper> so is it really 64MHz and 54MHz?
12.30.58 #       <pamaury> frequencies in the debug screen of the fuze+ are in kHz
12.31.10 #       <[Saint]> copper: yep.
12.31.13 #       <copper> 64 vs 54 doesn't seem much higher
12.31.27 #       <pamaury> 64MHz is the lowest frequency of the fuze+ though
12.31.28 #       <[Saint]> that's the *minimum* clock.
12.31.39 #       <[Saint]> ie. unboosted.
12.31.47 #       <copper> hmmm
12.31.59 #       <copper> I want to test the Clip+
12.32.27 #       <pamaury> why are you interested in cou frequencies ?
12.33.01 #       <copper> 09:24:09 UTC <[Saint]> that thing is foolishly overpowered.
12.34.10 #       <[Saint]> Wow...and you really thought 64MHz was the max clock?
12.34.21 #       <[Saint]> Its MUCh higher :)
12.35.07 #       <copper> I don't know anything!
12.37.14 #       <copper> [Saint]: can you put the Fuze+ into perspective for me?
12.37.26 #       <copper> compared to, say, an iPod Classic and a Clip+
12.37.47 #       <[Saint]> It _should_ eat both for breakfast.
12.38.19 #       <[Saint]> i.mx233 doesn't mess around.
12.39.05 #       <[Saint]> its mac clock is somewhere in the range of 700MHz.
12.39.09 #       <[Saint]> *max
12.39.11 Quit    JdGordon (Ping timeout: 256 seconds)
12.39.17 #       <[Saint]> 680 or so, iirc.
12.39.56 #       <[Saint]> couple that with solid state storage, and the Classic becomes a bit of a dinosaur.
12.41.48 #       <[Saint]> bah...silly memory. I may be thinking of something else. I want to say ~450MHz this time.
12.41.55 #       <DuperMan> iPod mini with a Compact Flash
12.42.01 #       <DuperMan> good balance imo
12.42.17 #       <DuperMan> an opinion grealy prejudiced towarsd what I own
12.42.39 #       <[Saint]> DuperMan: Its a nice, quite underpowered, target.
12.42.51 #       <DuperMan> true. plays very nice with flac
12.43.02 #       <DuperMan> but db things make it insane
12.43.25 #       <DuperMan> that's more to do with it expecting an hdd though, and controlling a cf in actuality
12.43.34 #       <copper> testing both the Classic and the Clip+
12.43.36 #       <DuperMan> wanna buy the original 4gb microdrive though?:D
12.43.49 #       <[Saint]> Nup. I have a small army of them.
12.44.05 #       <[Saint]> copper: turns out I "whoops"ed.
12.44.12 #       <copper> hmm?
12.44.14 #       <DuperMan> hehe. ever buffed the apple logo on the back of the mini? it so shiny
12.44.14 #       <[Saint]> its 454MHz max clock for the F=
12.44.23 #       <[Saint]> *+
12.44.46 #       <[Saint]> which is still pretty nuts.
12.45.02 #       <DuperMan> y b gr... oh. that's the native clock?
12.45.05 #       <DuperMan> oO
12.45.30 #       <DuperMan> fuze plus or clip plus?
12.45.31 #       <[Saint]> Makes your Mini's 80 look a little dated, huh?
12.45.55 #       <DuperMan> nah. I upgraded from my 30mhz palm IIIx a month ago ;)
12.46.40 #       <DuperMan> 454... ain't that best gutted for a cheaper still r-pi?
12.46.45 #       <[Saint]> fUZE+, BTW.
12.46.53 #       <[Saint]> eeeks, kitten-caps.
12.47.07 #       <copper> I guess they needed a speedy CPU for the OF interface
12.47.19 #       <DuperMan> OF?
12.47.27 #       <[Saint]> Original Firmware
12.49.08 #       <DuperMan> wasn't it like 128 by 160? 
12.49.21 #       <DuperMan> mustv'e had mad effects for such a low res to be demanding:D
12.49.27 #       <copper> 240x320
12.49.52 #       <DuperMan> reminds me of my hx4700 behemoth
12.50.11 #       <DuperMan> 600mhz 600x480 iirc intel armstrong hehe
12.50.17 #       <DuperMan> (ppc)
12.50.59 #       <DuperMan> both cf and sd though... also got an hx2700 I should find a new batt for, then tcpmp
12.51.26 Join    lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr)
12.52.00 #       <DuperMan> THE POCKET PC / WINDOWS MOBILE >=6.5 LIVES
12.52.24 #       <copper> Fuze+ performance spreadsheet of codecs that are of interest to me: http://outpost.fr/url/28s7
12.52.24 Join    JdGordon [0] (~jonno@CPE-121-218-128-145.lnse3.cht.bigpond.net.au)
12.52.26 Quit    JdGordon (Changing host)
12.52.26 Join    JdGordon [0] (~jonno@rockbox/developer/JdGordon)
12.53.15 #       <DuperMan> what's coloumn b standing for?
12.53.39 #       <DuperMan> time to decode a frame or frame per x time?
12.54.03 #       <copper> % realtime
12.54.51 #       <DuperMan> so it could transcode otf had you cared for that
12.55.14 #       <copper> ?
12.55.14 #       <DuperMan> big stinky feature request: for targets with wifi, dlna servor?
12.55.16 #       <DuperMan> ^^
12.55.32 #       <copper> transcoding performance is unrelated to Rockbox decoding performance
12.55.45 #       <copper> transcoding performance depends on your computer
12.56.01 #       <DuperMan> too dependant on io perf and other bottlenecks?
12.56.10 #       <[Saint]> The targets we support with wifi all have MUCh better implementations in their own firmware - so...probably not gonna happen.
12.56.11 #       <copper> and "% real time" means nothing to transcoding "on the fly"
12.56.16 #       <DuperMan> I was thinking more along the lines of making the player be a server
12.56.46 #       <DuperMan> copper: I fail to see how the two are seperate
12.56.48 #       <copper> just because encoding is faster than real time, doesn't mean it's fast enough
12.57.03 #       <copper> DuperMan: you don't transcode with Rockbox
12.57.08 #       <copper> you transcode with your computer
12.57.12 #       <DuperMan> but... it... does... all other things being equal
12.57.18 #       <copper> how is Rockbox performance related to your computer's performance?
12.57.21 #       <copper> what?
12.57.29 #       <copper> rockbox doesn't transcode anything
12.57.35 #       <DuperMan> copper, I was being madddddd and suggesting adding a dlna or upnp server in rockbox
12.57.50 #       <DuperMan> not speaking of actual existing features
12.58.10 #       <[Saint]> [22:57:31] <copper> rockbox doesn't transcode anything <--- well...technically...
12.58.18 #       <[Saint]> re: Recording
12.58.20 #       <DuperMan> a dac is a dac
12.58.29 #       <DuperMan> eh [Saint]?
12.58.38 #       <copper> [Saint]: recording means encoding not transcoding
12.58.45 #       <copper> also, doesn't the recorder use WAV?
12.58.48 #       <DuperMan> it transcodes a pcm stream
12.58.50 #       <DuperMan> ><
12.58.58 #       <DuperMan> or repackages for wav
12.59.27 #       <[Saint]> I'm pretty sure we capture everything as raw PCM and then convert if the target file is anything other than that.
12.59.31 #       <copper> it doesn't even encoding anything per se
12.59.32 #       <[Saint]> Not entirely sure, though.
12.59.38 #       <copper> encode*
12.59.53 #       <DuperMan> ^^^ repackage
13.00.05 #       <DuperMan> a wav is a container for a raw pcm stream
13.00.09 #       <copper> I know
13.00.16 #       <DuperMan> Imma clarifies
13.00.19 #       <copper> I don't consider converting raw PCM to WAV "encoding"
13.00.32 #       <[Saint]> options for recording are PCM, Wav, and Mp3...pretty sure there's no magic involved, so it must be doing *something* to get to mp3 in the end :)
13.00.34 #       <DuperMan> I don't consider it converting :P 
13.00.49 #       <copper> MP3, really?
13.00.54 #       <DuperMan> lol real time selective octet handling
13.00.55 #       <DuperMan> :D
13.01.07 #       <DuperMan> it only HEARS the bits relevant to cbr mp3
13.01.10 #       <DuperMan> ;P
13.01.22 #       <DuperMan> also, magic
13.01.27 #       <[Saint]> copper: really really.
13.01.42 #       <copper> hmmm
13.01.43 #       <[Saint]> In which case, we *muct* encode.
13.01.49 #       <[Saint]> but, this is pure pedantism.
13.01.50 #       <DuperMan> anybody wants a screenless iriver h340?
13.01.51 #       <copper> I think the Classic results are going to be somewhat surprising
13.02.02 #       <DuperMan> show 'em
13.02.10 #       <copper> not done yet
13.02.27 #       <DuperMan> I have battery dead x5l and lcd dead h340
13.02.28 #       <DuperMan> :(
13.02.42 #       <DuperMan> srsly, anybody awesome enough to have use for those?
13.02.52 #       <[Saint]> So, yeah, sorry for that - it was really assholeish - but, yeah, Rockbox can technically transcode.
13.03.05 #       <DuperMan> it wasn't! it DOES
13.03.07 #       <DuperMan> arrrgh
13.03.49 #       <DuperMan> it wasn't even pedantic, seeing as you did not point out an irellevent to the topic lingual mistake
13.04.12 #       <copper> I stand corrected about MP3 recording
13.04.20 #       <DuperMan> but pointed out that the action in question is done under a certain scenario
13.04.51 #       <[Saint]> I _think_ there's also a WAV-to-MP3 plugin.
13.05.00 #       <DuperMan> but my original comment wasn't about the actual, but about a trollish feature request
13.05.01 #       <DuperMan> :P
13.05.15 #       <DuperMan> meh. it probably isn't hardware accelerated
13.05.23 #       <DuperMan> so must be sluggish mad
13.05.38 #       <DuperMan> too many possible cpu and dac archs
13.05.54 #       <DuperMan> or kernel has api/hal?
13.06.21 #       <[Saint]> Its not /sooo/ trollish, but realistically, the targets (presently) that have wifi are all "Application" targets, meaning we run as an app hosted in the targets OS, rather than replacing said OS, and the OS almost certainly has a better solution for this than we could implement.
13.06.29 #       <DuperMan> like, for accessing the hw encoding machinary
13.06.55 #       <DuperMan> hmmm... gotta praise the voodoo you do (we do?:D) on making android sound divine though
13.07.14 #       <[Saint]> do what?
13.07.19 #       <[Saint]> ...remind me of the babe!
13.07.24 #       <DuperMan> btw, are my ears better served by the WM1811 DAC in my phone or whatever's in the ipod mini?
13.07.26 #       * [Saint] skulks away
13.07.35 #       * DuperMan is confused
13.07.54 #       <DuperMan> "do what?" guess I placeboed myself
13.08.13 #       <[Saint]> I thought you were quoting from David Bowie's "Dance the Magic Dance" :)
13.08.48 #       <copper> hmmm, how do I quit the test_codec once it's done, on the Classic?
13.08.59 #       <DuperMan> rofl :) no sorry
13.09.42 #       <[Saint]> copper: insane iPod keymap tells me it'll probably be "select+<something>"
13.09.51 #       <[Saint]> menu+select, probably.
13.16.12 #       <copper> iPod Classic codec performance: http://pastebin.com/KfP5Za26
13.16.31 #       <DuperMan> thanks!
13.16.44 #       <copper> http://outpost.fr/url/2lC0
13.17.10 #       <DuperMan> it raped your fuse
13.17.28 #       <[Saint]> errrr...
13.17.29 #       <copper> not really
13.17.37 #       <[Saint]> Are you sure you know what you're looking at?
13.17.38 #       <copper> performance figures are very different though
13.17.57 #       <copper> on the classic, Vorbis is faster than Musepack!!
13.18.06 #       <copper> marginally
13.18.25 #       <DuperMan> me? no
13.18.25 #       <[Saint]> DuperMan: if its not obvious, there's a clear winner here.
13.18.30 #       <[Saint]> ...and it isn;t the Classic.
13.18.35 #       <copper> and the differences between most codecs are much less pronounced
13.18.56 #       <copper> [Saint]: er, not really
13.19.09 #       <copper> LAME and VOrbis are faster on the Classic
13.19.20 #       <[Saint]> ...but, everything else?
13.19.22 #       <DuperMan> whoops. yeah
13.19.23 #       <[Saint]> :)
13.19.34 #       <copper> ALAC too
13.19.35 #       <DuperMan> I assumed the codecs would be stacked samely in both tables
13.19.39 #       <DuperMan> xD
13.19.56 #       <copper> WavPack too
13.20.09 Join    Nephiel [0] (~5332f9b8@www.haxx.se)
13.20.11 #       <DuperMan> MY BAD
13.20.43 #       <copper> APE too!
13.21.00 #       <DuperMan> I have a clip+ around, but need to do the fake jtag thing to revive it's flash
13.21.02 Quit    lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 23.0/20130725195523])
13.21.06 #       <DuperMan> nand*
13.21.22 Join    lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr)
13.22.12 #       <[Saint]> copper: well..hmmm...I would say the winner is clear, even though the Classic is (marginally) faster for a few codecs, look at the CPU usage.
13.22.32 #       <copper> ?
13.22.36 #       <[Saint]> The Classic spends a LOT more CPU doing essentially the same thing.
13.23.03 #       <copper> aw snap, the log on the Clip+ is empty
13.23.03 #       <[Saint]> Fuze+ a52@192
13.23.05 #       <[Saint]> 0.06MHz needed for realtime
13.23.15 #       <[Saint]> Classic?
13.23.16 #       <[Saint]> 18.48MHz needed for realtime
13.23.36 #       <[Saint]> just a bit of a difference ;)
13.23.39 #       <DuperMan> 0.06. must haz teh hawt dac
13.24.00 #       <copper> ah
13.24.27 #       <[Saint]> while the realtime numbers are similar, the CPU usage is by far in favor of the F+
13.24.42 #       <DuperMan> a dac is a discrete cpu though
13.25.52 #       <copper> [Saint]: does that mean the Fuze+ CPU is faster, or the Fuze+ target is more optimized?
13.26.13 #       <TheSeven> damn, I'm *almost* there
13.26.13 #       <DuperMan> copper: probably means the dac unit does most of the work
13.26.21 #       <copper> what
13.26.23 #       <DuperMan> which should count as 'target be optimized'
13.26.25 #       <[Saint]> I believe it to be a combination of a much faster CPU, and much faster storage.
13.26.25 #       <copper> a DAC doesn't decode
13.26.28 #       <DuperMan> and 'target is gooder'
13.26.51 #       <DuperMan> doesn't it? only pure streams? tell that to my denon
13.26.53 #       <copper> a DAC converts PCM to analog
13.27.00 #       <bertrik> The CPU plays a large part in playback performance, but other stuff like memory access speed/latency can have a lot of impact
13.27.23 #       <DuperMan> yeah, caches too
13.27.36 #       <DuperMan> needs to be as much like realtime systems as possible really
13.28.24 #       <copper> re-running the Clip+ test
13.28.35 #       <TheSeven> umsboot v0.2 *almost* connects... but something chews up the CSW of the SCSI INQUIRY transaction...
13.28.52 #       <DuperMan> bloated linux kernel
13.28.57 #       <pamaury> on the fuze+ the memory latency is huge, the ddr clock has a huge impact
13.28.58 #       <TheSeven> fun fact: the very same code and driver works perfectly on a different device (STM32 SoC)
13.30.15 #       <pamaury> TheSeven: is the amsv2 driver rewrite making some progress ?
13.30.40 #       <TheSeven> no idea, I'm doing it in the other direction right now
13.31.02 #       <TheSeven> porting the UMSboot userspace/application layer to the other framework which the USB driver comes from
13.31.30 #       <TheSeven> just to get that part out of the way and to have an actually tested code base for porting to rockbox
13.32.16 #       <TheSeven> but right now it looks like something breaks the second non-EP0 IN transfer for some reason
13.32.26 #       <TheSeven> no matter what I try to send, the host always receives 2 bytes: 00 01
13.32.56 #       <TheSeven> that's kinda suspicious because those bytes might make sense as a GET STATUS EP0 response. but how do they end up on EP1?
13.34.15 #       <pamaury> bad buffer configuration ? I think on this chip you can choose the buffer offsets and possibly overlap them or something like that ?
13.34.25 #       <copper> I added "needed CPU MHz" to the spreadsheets
13.36.07 #       <pamaury> TheSeven: so if I understand correctly, the same code on two different devices, one works while the other doesn't ?
13.37.01 #       <TheSeven> yes, mostly the same code
13.37.07 #       <TheSeven> completely different SoC, but same USB core
13.37.14 #       <TheSeven> different core config though
13.37.22 #       <TheSeven> the ipod is DMA-only, the other one PIO-only
13.37.43 #       <TheSeven> I just checked: even if I don't even attempt to send a CSW, that garbage CSW arrives at the host
13.37.54 #       <TheSeven> I also don't ever send a GET STATUS response or any other 2 byte EP0 packet
13.38.03 #       <TheSeven> so where one earth does that garbage come from?
13.38.23 #       <pamaury> DMA only ? I thought the chip was always capable for PIO
13.39.41 #       <TheSeven> I thought that as well... but PIO seems to be broken on the nano2g as well
13.40.07 #       <TheSeven> I can receive packets using PIO, but I will never ever get a TX fifo empty IRQ, so I can't send
13.40.19 #       <pamaury> On the clip+ I tried PIO but it didn't work much better either, it wasn't fully broken but not better dma
13.43.03 #       <pamaury> at least that means that all the people who tried to write the driver aren't completely dumb, there really is something we don't understand :-/
13.43.45 #       <pamaury> what about reverse engineering the whole nano2g or clip+ driver ? could that help or maybe you already did ?
13.53.54 #       <DuperMan> WHAT ABOUT U DO IT IF IT SEEMS TRIVIAL
13.54.14 #       <DuperMan> sorry reflex
13.55.14 #       <[Saint]> ...are you just here to troll, or...?
14.01.16 #       <DuperMan> to troll and educate myself, as well as lurk for the off chance somebody with a penchant for the mini comes along wanting to become my mentor
14.02.28 #       <[Saint]> You need to stick around for ~1Y+ before you start trolling our active developers ;)
14.03.35 Join    ender` [0] (krneki@foo.eternallybored.org)
14.03.50 #       <pamaury> DuperMan: I'm very aware of what reverse engineering work is if you want to know :)
14.04.09 #       <DuperMan> oh lol well I troll codeworkx on the cyanogen places, even cotulla on xda-devs
14.04.12 #       <DuperMan> no cred? xD
14.04.36 #       <copper> Clip+ codec performance: http://pastebin.com/6mx8Lcdv and http://outpost.fr/url/2odq
14.05.22 #       <DuperMan> pretty equivalent to the classic
14.05.35 #       <copper> not really
14.05.41 #       <copper> Vorbis is twice slower on the Clip+
14.05.47 #       <DuperMan> oO oh
14.05.58 #       <copper> it's actually the slowest codec among those that I'm interested in
14.06.09 #       <DuperMan> flac is more throughput = drains batt but easy to actually play right?
14.06.16 #       <DuperMan> unparses to pcm
14.06.41 #       <DuperMan> vorbis is famously complex, but better than mp3 at similar bitrates derp
14.08.34 #       <copper> the Fuze+ kills the Classic and the Clip+ in FLAC performance
14.09.29 #       <copper> pamaury: given the very low demand for CPU processing on the Fuze+, maybe you could put it in a low power state or something?
14.09.37 #       <copper> is battery usage on the Fuze+ optimized already?
14.10.33 #       <copper> [Saint]: the difference in "needed CPU MHz" between the Fuze+ and the other too is insane
14.10.37 #       <copper> two*
14.10.48 #       <pamaury> it's already super optimised: we run at 64MHz most of the time and sleep the cpu whenever there is nothing to do
14.10.53 #       <copper> ok cool
14.11.06 #       * DuperMan eyes his Palm IIIx
14.11.18 #       <DuperMan> alas, no headphone jack
14.11.20 #       <pamaury> with the upcoming patches for the touchpad we might reach ~40h of battery life
14.11.33 #       <copper> nice
14.12.18 #       <DuperMan> sorry for such obscene trolling, but shame the old creative njb3 series didn't see more love
14.12.21 #       <copper> usually I feel like the Fuze+ takes a long time to charge, do you see the same thing?
14.12.27 Quit    tchan (Quit: WeeChat 0.4.1)
14.14.06 #       <pamaury> honestly I didn't benchmark charging, I think we are already charging at the same current level as the OF, we don't have the battery spec so that's the safest we can go imo
14.15.09 #       <pamaury> if you want to benchmark OF vs RB on this matter, maybe we could have figures
14.17.52 #       <copper> meh, I can't really be bothered to do that
14.18.59 ***     Saving seen data "./dancer.seen"
14.19.05 #       <copper> great job on the Fuze+ anyway, can't thank you enough for that :)
14.19.18 #       <copper> I love that thing (with Rockbox).
14.22.10 #       <jlbiasini> pamaury: ping
14.22.16 #       <pamaury> thanks :) we have made a long way since the beginning !
14.22.19 #       <pamaury> jlbiasini: pong
14.22.19 #       <TheSeven> pamaury: looks like the version of the OTG used in the ipods is a bit older and doesn't have some of the features that my driver relies on for PIO mode
14.22.29 #       <TheSeven> especially it doesn't seem to have an IRQ for that fifo empty condition
14.22.46 #       <TheSeven> how did you deal with that in PIO mode?
14.22.55 #       <TheSeven> were you polling it?
14.23.44 #       <jlbiasini> pamaury: do I have to declare the do_interupt function in the button_target.h? The compiler seems to want that and I don't know how to turn it around otherwise
14.23.50 #       <pamaury> I don't remember honestly, I think I relied on IRQ
14.24.01 #       <TheSeven> the nano2g driver was initially implemented by reverse engineering it btw, but it nevertheless didn't work properly :)
14.24.17 #       <TheSeven> well, there doesn't seem to be an IRQ for this on that core version... maybe there is one on AMS?
14.24.30 #       <pamaury> jlbiasini: no, the do_interrupt() function is already in button-fuzeplus.c, maybe I made a typo like interrupt vs interupt
14.24.45 #       <TheSeven> the core version used in the nano2g seems to be fairly close to the one in the s3c6400x datasheet, which completely lacks the registers and IRQ bits for FIFO management
14.25.14 #       <pamaury> TheSeven: at some point I implemented PIO, maybe you can look at the history of the the driver file or on flyspray to find the code
14.29.42 #       <pamaury> TheSeven: FS#11664
14.30.13 #       <pamaury> search for PIO
14.38.22 #       <copper> maybe it should be recommended somewhere, to unplug all unnecessary USB devices, before connecting a Rockboxed DAP
14.38.27 #       <copper> wrt USB problems
14.38.43 #       <copper> I'm almost certain my USB DAC was the one causing my problems, directly or indirectly
14.40.11 #       <DuperMan> which dac? fiio one?
14.40.17 #       <copper> ODAC
14.40.18 #       <jlbiasini> pamaury: no it wasn't (at least with the actual head, so I added a static void do_interrupt(void); at the beginnig of the button-fuzeplus.c file. Is that the correct way to do?
14.40.22 #       <DuperMan> my e17 bsods often
14.40.35 #       <DuperMan> but fidelity's worth it :P
14.41.27 #       <pamaury> jlbiasini: should be unnecessary: do_interrupt() is in the same file as the caller and before, why do you need to do this ? compile error ?
14.41.39 #       <jlbiasini> yes
14.41.51 #       <pamaury> did you modify my code ?
14.42.37 #       <jlbiasini> not that much only adding the report rate modification
14.43.16 #       <jlbiasini> is that place where appears the do interrupt function important (I means top/end of the fil for instance?)
14.43.55 #       <pamaury> can you pastebin the code ? I don't think the report rate modification is needed by the way. Yes if you call it before it is defined, you need to declare it before: "static void do_interrupt();"
14.45.19 #       <jlbiasini> the report rate has to be lower when in very_low_power
14.45.26 #       <jlbiasini> at least
14.46.32 #       <jlbiasini> well *has* not but I would like to test it to see if it's improving battery life without being anoying
14.46.52 #       <pamaury> ok, but I doubt it, if you don't touch the device, there will be no report sent
14.47.57 #       <jlbiasini> pamaury: ok here http://pastebin.com/MVL4uDgQ
14.48.29 #       <TheSeven> pamaury: looks like you used one TX fifo for all EPs?
14.48.52 #       <pamaury> I don't remember, that was a long time ago and I probably didn't know what I was doing ^^
14.49.46 #       <pamaury> jlbiasini: why put do_interrupt at the end ? it should stay within the #ifdef #endif because it's not needed in the bootloader
14.49.58 Quit    kevku (Ping timeout: 260 seconds)
14.50.17 #       <TheSeven> hm... I have two datasheets that are explicitly contradicting each other
14.50.31 #       <TheSeven> s3c6400x says that everything nonperiodic shall be pointed at fifo 0
14.50.33 #       <jlbiasini> yeah i just moved it to see if it was changing something to my compilation problem
14.50.51 #       <TheSeven> stm32f4 says that each EP shall have its own fifo or things might get messed up
14.50.52 #       <pamaury> TheSeven: I based on the s3c6400x datasheet iirc
14.51.56 #       <TheSeven> mixing the data in a fifo in device mode just sounds like a very bad idea
14.52.01 #       <jlbiasini> pamaury; I thing I deleted the touchpad sensitivity by error
14.52.07 #       <TheSeven> and IIRC is responsible for a whole bunch of USB lockup problems on the classic
14.52.07 #       <jlbiasini> *think
14.52.20 #       <TheSeven> so I tend to not trust the s3c6400x datasheet there
14.52.52 #       <pamaury> ok, seems safer to have each EP have its own fifo
14.53.07 #       <pamaury> if the FIFO large enough to do this, always ?
14.53.27 #       <TheSeven> yes
14.54.30 #       <TheSeven> otherwise you may run into situations where the data that the host is waiting for can't be pushed into the fifo because it is full with data for another EP
14.54.32 #       <pamaury> that fifo config param has been mysterious to me, it's not very well explained
14.54.47 #       <TheSeven> it's much better explained in the stm32f4 datasheet
14.55.09 #       <pamaury> I should read this one ^^
14.55.37 #       <TheSeven> it seems to be for a newer core revision though that handles PIO differently (and more efficiently)
14.55.57 #       <TheSeven> I figure that this PIO change might be one of the reasons why things need to be in the same FIFO on the 6400x
14.56.05 #       <TheSeven> but for DMA it doesn't make any sense
14.57.07 #       <pamaury> I found another chip which uses a very similar core: Rockchip Nano-B uses the same as stm32f2
14.57.24 #       <TheSeven> should be the same one then, f2/f4 are identical
14.57.27 #       <jlbiasini> pamaury: this is the error I get http://pastebin.com/NYU01SAQ (after redoing the touchpad_set_sensitivity()
14.58.21 #       <pamaury> jlbiasini: you need to "static void do_interrupt(void);" at the top of the file if you implement do_interrupt after it is called
14.58.53 #       <jlbiasini> ahah so should I put it above unstead of declaring it?
14.59.09 #       <pamaury> yes, like it was done in the original patch
14.59.20 #       <jlbiasini> ooops sorry
15.10.52 Join    tchan [0] (~tchan@lunar-linux/developer/tchan)
15.20.54 #       <jlbiasini> pamaury: how long is 60 * HZ? 1 minutes?
15.21.10 #       <jlbiasini> or is it device dependend?
15.21.34 #       <gevaerts> 1 minute, yes
15.22.20 #       <gevaerts> I don't believe HZ is different on different devices right now, but it could be, and if everything uses HZ properly, it doesn't matter
15.22.38 #       <gevaerts> HZ is "ticks per second"
15.22.55 #       <gevaerts> So 60 * HZ is "ticks per minute"
15.23.28 #       <jlbiasini> yeah that is what I though thanks for confirmation
15.23.42 #       <[Saint]> copper: Rockboxed devices can do some "Weird Shit (TM)" if left connected to some things.
15.23.45 #       <[Saint]> ...no idea why.
15.23.58 #       <[Saint]> I don't think anyone knows.
15.24.15 #       <TheSeven> pamaury: as far as I can tell the s3c6400x variant of the core can only have in flight transfers on one endpoint at a time in PIO mode
15.24.22 #       <copper> I think it would be a cheap and potentially effective recommendation to make
15.24.28 #       <gevaerts> Normally (i.e. outside of some very specific low-level drivers) you don't need to know that HZ=100 :)
15.24.31 #       <[Saint]> Some BIOS freak the fuck out and just hang, some machines refuse to shut down or hibernate.
15.24.34 #       <[Saint]> Lots of fun things.
15.25.14 #       * gevaerts doesn't like recommendations that are based on vague annecdotes and that can prevent people doing useful things
15.26.27 #       <[Saint]> Where's the recommendation?
15.26.54 #       <copper> [Saint]: recommending to unplug all unnecessary USB devices
15.27.04 #       <copper> prior to connecting a Rockbox device
15.27.23 #       <[Saint]> Ah. I thought that was directed at me. WHoops.
15.28.15 #       <TheSeven> indeed. there's no way for the core to identify which endpoint a packet belongs to if multiple are enabled
15.28.18 #       <pamaury> copper: what ? I've never heard of other usb devices interfering with a rockbox device, actually that seems pretty impossible given how usb works, except for a hub possibly
15.28.37 #       <copper> pamaury: my devices almost always crash when my ODAC is connected
15.28.42 #       <copper> and NEVER crash when it's not
15.28.53 #       <TheSeven> sounds like a buggy driver
15.29.09 #       <copper> doesn't matter what the problem is, until it's fixed
15.29.13 #       <pamaury> yeah, buggy OS, nothing related to rockbox
15.29.30 #       <pamaury> we can't warm against all possibly buggy code in the world
15.29.34 #       <pamaury> *warn
15.29.37 #       <copper> sigh
15.29.51 #       <copper> so you'd rather have people's DAPs crash?
15.30.03 #       <[Saint]> than do weird broken shit? yep.
15.30.12 #       <copper> I mean, you guys already recommend changing skins
15.30.24 #       <copper> isn't that anecdotal evidence?
15.30.44 #       <copper> no-one even knows why skins could be a problem
15.30.55 #       <copper> exactly*
15.31.20 #       <pamaury> which device are you talking about which crashes with this ODAC thing ?
15.31.28 #       <jlbiasini> gevaerts: now that I have you here, did you saw the comment of Lorenzo about that touchdev disable on keylock? he was suggesting to let that function and on devices that don't handle touchdev sleep, to have it just filtering the button reporting output...
15.31.29 #       <copper> Classic, Fuze+, Clip+
15.31.56 #       <copper> thing is, Rockbox crashes, and no-one knows why
15.32.10 #       <[Saint]> as I understand it if Rb works fine without this thing plugged, but doesn't when it is, the other thing is at fault - or the host.
15.32.12 #       <copper> so I mean to do anything that can prevent it from happening
15.32.21 #       <copper> [Saint]: I'm not pointing fingers
15.32.28 #       <copper> that's not the point
15.32.56 #       <copper> rather than tell users, "yeah, sorry, Rockbox crashes", I'd rather tell them "try to unplug everything else"
15.33.20 #       <[Saint]> so, you're asking to Rockbox workaround some unknown fault to "fix" a problem that probably isn't theirs?
15.33.26 #       <jlbiasini> or use the OF usb bootloader
15.33.36 #       <copper> what?
15.34.11 #       <copper> if, for instance, it's a USB driver bug
15.34.32 #       <copper> well, lots of people happen to be using linux with the exact same driver, since it's completely generic
15.34.32 #       <gevaerts> copper: the theme problem has been seen on several devices, by several people. No, we don't know the exact cause, but in my mind it's gone beyone anecdotal
15.35.22 #       <copper> I mean to recommend anything that can help prevent a Rockbox device from crashing, that's all
15.35.37 #       <gevaerts> jlbiasini: no, I haven't. When?
15.35.42 #       <DuperMan> hmmm... db generation creating 4gb files that are just artifacts of the fs malfunctioning
15.35.43 #       * [Saint] recommends not using the device
15.35.53 #       <DuperMan> is it a normal fat32 on 64gb cf ipod thing?
15.35.54 #       <[Saint]> ..it'll definitely not crash then.
15.35.57 #       <copper> [Saint]: ok cool, I'll stop using Rockbox on all my three DAPs!
15.35.59 #       <[Saint]> problem solved.
15.36.07 #       <copper> or did you mean the ODAC?
15.36.31 #       <jlbiasini> gevaerts: it was here http://www.rockbox.org/mail/archive//rockbox-dev-archive-2013-07/0008.shtml on the mailing list
15.36.36 #       <DuperMan> copper: to prevent it from crashing don't use it
15.36.49 #       <copper> that's just silly
15.36.56 Quit    mirak (Quit: Ex-Chat)
15.37.01 #       <DuperMan> that's the only true solution, for any os
15.37.06 #       <DuperMan> even jets
15.37.22 #       <[Saint]> It was my remarkably awesome attempt at absurdium ad reducto.
15.37.46 #       <[Saint]> reductio ad absurdum, even.
15.37.57 #       <DuperMan> you have no idea how absurdium ad reducto really is fitting
15.37.58 #       <DuperMan> ah
15.38.00 #       <DuperMan> hehe
15.38.07 #       <gevaerts> copper: if you qualify the recommendation enough, e.g. "Some people have observed issues when certain specific USB devices are also connected, so if you see USB instability or crashes, you might try disconnecting non-essential devices (and if this makes a difference, tell us about this)", I think it might be a good idea
15.38.14 Join    Epicanis [0] (~kvirc@sdsl-68-238-63-20.static.ngn.east.myfairpoint.net)
15.38.30 #       <DuperMan> so you weren't silly to the point of vanishing
15.38.46 #       * [Saint] vanishes
15.38.48 #       <copper> what
15.38.51 #       <copper> I don't speak latin
15.39.03 #       <gevaerts> DuperMan: what do you mean by "db generation creating 4gb files that are just artifacts of the fs malfunctioning"?
15.39.03 #       <DuperMan> gevaerts: that's oldddddd hat
15.39.31 #       <DuperMan> it was mostly a recommendation for the n00b/moms out there that stick usb things in unpowered ports
15.39.37 #       <gevaerts> DuperMan: you mean I should encourage the discussion going off-topic? No, sorry.
15.39.47 #       <DuperMan> gevaerts: my ipod mini 1st gen does just that
15.40.17 #       <DuperMan> it lists in the fat a 4gb file that doesn't effect real available space
15.40.24 #       <gevaerts> Right
15.41.01 #       <DuperMan> so... is that common, insofar as you're aware?
15.41.23 #       <gevaerts> I've never seen anyone report that specifically, but yes, check the filesystem
15.41.33 #       <DuperMan> I assume I need to compile my own builds and have the build not assume it's talking to an hdd
15.41.39 #       <gevaerts> No
15.41.48 #       <gevaerts> Rockbox should work fine with CF cards
15.41.54 #       <[Saint]> I have only personally seen db generation *really* thrash an already trashed fs.
15.42.23 #       <DuperMan> hmmm... it's been factory reset a few times, but I don't remember formatting it low level
15.42.28 #       <[Saint]> I have not personally seen it actually cause issues in stable devices.
15.42.29 #       <gevaerts> If you're sure you start with a clean filesystem and you end up with a corrupted filesystem, and you didn't have a crash or an unsafe unplug in between, there's a bug
15.42.36 #       <DuperMan> so... "no" to letting itunes format for me?
15.42.46 #       <gevaerts> You don't do low-level formats on non-floppy devices typically :)
15.42.57 #       <DuperMan> hehe yeah but it sure is fun
15.42.58 #       <DuperMan> :)
15.43.07 #       <gevaerts> Well, you typically *can't*
15.43.32 #       <DuperMan> ehrm... disk part is kinda cool like that, but no reconfiguring the controller hhe
15.43.49 #       <DuperMan> I meant a full rather than quick format
15.44.24 #       <gevaerts> That shouldn't make any difference at all
15.44.58 #       <DuperMan> so to be sure I'm working with a workable thingy, I should put the cf in a card reader and manually build the partitions etc.? or my pletorous normal formattings shouldv'e sufficed?
15.45.06 #       <TheSeven> (besides taking longer and wearing out the media)
15.45.11 #       <DuperMan> ^
15.45.33 #       <DuperMan> it's a thing you do when frustrated. I can't be the only one who did...
15.45.36 #       <DuperMan> :P
15.45.42 #       <TheSeven> IF things work right, you should be able to format it through rockbox's USB interface, but then again that isn't exactly the most robust thing
15.45.42 #       * [Saint] giggles
15.45.48 #       <[Saint]> "workable thingy"
15.46.15 #       <DuperMan> well "ipod" isn't a more respectable term
15.46.17 #       <DuperMan> :)
15.46.23 #       <gevaerts> DuperMan: doesn't make *any* difference. If whatever formats the device makes sure the FAT is clean and the root directory is empty, and the partition tables make sense, you're fine
15.47.19 #       <DuperMan> hmmm... wouldn't that make an ipod panic and sadface? not sure if the handover from the bootloader is timed for such a case
15.47.30 #       <DuperMan> like, I won't have the magic apple folder of ipodstuffs
15.48.06 #       <gevaerts> Well, I'm assuming you don't let the tools touch the firmware partition
15.48.12 #       <DuperMan> I'll save us all the trouble. the cf card I use is a dolgix:D
15.48.36 #       <DuperMan> I haven't so far, but that keeps on happening. best results are when I set spindown to 0 to disable it
15.49.32 #       <DuperMan> but it always seem to happen after a while. also; battery use reports are whimsical
15.50.31 #       <DuperMan> if anybody knows, will compiling a build that supports exfat work or will the ipod bootloader won't be able to handoff to the kernel?
15.51.01 #       <DuperMan> (I mean, format it to exfat after I made sure my rockbox will be able to read it. I know it won't be OF compatible)
15.51.23 #       <gevaerts> The ipod bootloader doesn't care about the data partition
15.51.44 #       <gevaerts> Of course, "compiling a build that supports exfat" implies implementing exfat support first, so good luck :)
15.52.03 #       <DuperMan> another idea I had is working with the ipodlinux bootloader, but that's such an old fad I'm unable to find data on it
15.52.10 #       <DuperMan> ah! xD
15.52.16 #       <DuperMan> hehehe thanks, wish I could
16.05.18 Join    kevku [0] (~kevku@2001:0:c38c:c38c:e6:4b86:3d69:bedb)
16.07.03 Quit    akaWolf (Ping timeout: 264 seconds)
16.07.17 Join    akaWolf [0] (~akaWolf@188.134.9.161)
16.07.25 Quit    akaWolf (Changing host)
16.07.25 Join    akaWolf [0] (~akaWolf@unaffiliated/akawolf)
16.07.47 Quit    Guest11127 (Read error: Connection reset by peer)
16.19.02 ***     Saving seen data "./dancer.seen"
16.19.55 #       <soap> !seen linuxstb
16.19.59 #       <soap> .seen linuxstb
16.20.01 #       <soap> gah
16.20.21 #       <bertrik>  /msg logbot seen linuxstb
16.20.30 #       <soap> ty
16.20.39 #       <jlbiasini> gevaerts: so any idea about http://www.rockbox.org/mail/archive//rockbox-dev-archive-2013-07/0008.shtml
16.29.45 #       <gevaerts> jlbiasini: I suspect he knows that part of the code better than I do, so I'll believe him :)
16.30.04 #       <jlbiasini> ok
16.30.15 Part    jvd
16.31.12 #       <jlbiasini> so I will start implementing it then...
16.31.36 Quit    pamaury (Read error: Operation timed out)
16.51.29 Quit    jlbiasini (Quit: jlbiasini)
17.02.29 Quit    [Saint] (Remote host closed the connection)
17.02.48 #       <TheSeven> what the hell...
17.03.08 #       <TheSeven> this OTG decrements the "packets to be sent" counter below zero, wrapping to 1023
17.04.40 Join    [Saint] [0] (~saint@rockbox/user/saint)
17.06.36 Join    webguest53 [0] (~3c1182e6@www.haxx.se)
17.07.17 Quit    webguest53 (Client Quit)
17.17.19 #       <TheSeven> hm
17.17.31 #       <TheSeven> apparently these ipods indeed have a buggy old version of this core
17.29.49 Quit    thegeek (Read error: Connection reset by peer)
17.31.33 Join    thegeek [0] (~thegeek@40.200.16.62.customer.cdi.no)
17.33.43 Quit    kevku (Ping timeout: 245 seconds)
17.42.54 #       <Nephiel> Hi there
17.43.52 #       <Nephiel> I was looking at FS#11376 http://www.rockbox.org/tracker/task/11376
17.47.11 #       <Nephiel> doesn't seem so hard to fix. Am I right in assuming track indexes aren't always in order on playlists?
17.48.06 #       <gevaerts> Well, it's probably easy for someone who knows that subsystem :)
17.48.20 #       <gevaerts> Which could be you, after a few days' work!
17.49.22 #       <Nephiel> well, that's what I am trying to do ;)
17.50.51 #       <[Saint]> I'm not actually sure this is anything that "broke" as the tracker suggests.
17.51.09 #       <[Saint]> I recall seeing this behavior years and years and years ago.
17.51.26 #       <gevaerts> Well yes, it's clearly old
17.51.45 #       <gevaerts> But if I read the report correctly, it's also quite clearly a bug
17.52.01 #       <[Saint]> Oh, yes, no denying that.
17.52.26 #       <Nephiel> well, I've been seeing it for quite a while and I found it quite annoying, that's why I wanted to fix it
17.53.03 #       <[Saint]> that's a good reason. :)
17.53.05 #       <Nephiel> just built from git, bug still there
17.53.38 #       * gevaerts never actually moved a track to before the current track in his playlist
17.53.38 #       <[Saint]> The code that handles this probably hasn;t changed for some time.
17.54.01 #       <gevaerts> It sounds like something only very few playlist powerusers would do
17.54.13 #       <gevaerts> Which is why nobody fixed it yet, probably
17.55.13 #       <Nephiel> Actually it happens whenever you move any track to any position before the currently playing track
17.55.49 #       <Nephiel> except to the first one (that looks like a prepend and works as intended)
17.57.18 #       <[Saint]> Moving a track to before the currently playing track likely occurs rarely, as gevaerts suggested.
17.57.27 #       <[Saint]> I can't think of any use case for it personally.
17.57.52 #       <[Saint]> I want to listen to my tracks, so moving them before the current one seems counterproductive to their playback.
17.58.39 #       <gevaerts> I can imagine some use cases, but none of them is something I'd personally need
17.58.50 #       <gevaerts> e.g. preparing a playlist for later use
17.59.01 #       <gevaerts> (while listening, so you get a proper feel)
17.59.27 #       <[Saint]> I do that on a PC, as its so damn painful on-device.
17.59.41 #       <gevaerts> Well yes, due to this bug :)
17.59.50 #       <Nephiel> I do use it. Suppose I have a track coming up that I don't want to listen to right now, but don't want to remove it from the list as I might want to listen to it later
18.00.06 #       <Nephiel> so I move it above the currently playing one
18.00.15 #       <[Saint]> >>|
18.00.22 #       <[Saint]> that's my solution for that :)
18.00.31 #       <gevaerts> [Saint]: you can only do that when you reach the track
18.01.10 #       <gevaerts> i.e. not three tracks in advance
18.01.44 #       <gevaerts> Hmmm
18.01.53 #       <Nephiel> >>| works but not if you're listening while having a nap
18.02.13 #       <gevaerts> What happens if you move a track the other way, i.e. from before the current track to after? Do things get confused then?
18.02.28 #       <[Saint]> I imagine so?
18.02.55 #       <Nephiel> no, that works. In fact I think I have it figured out, patch incoming
18.03.49 Join    krabador [0] (~krabador_@unaffiliated/krabador)
18.05.50 #       <Nephiel> but I'd like to know if I can simply look at playlist indexes to check if a track comes before another in the playlist
18.06.45 #       <Nephiel> if not, I'll have to look at display_index for each track I want to check
18.09.56 #       * gevaerts has no idea
18.10.18 #       <gevaerts> I'd suggest putting a patch on gerrit using your first assumptions, and waiting for a review by someone who knows
18.11.33 #       * [Saint] suggests looking at http://www.rockbox.org/wiki/UsingGit#Preparing_to_make_changes
18.12.25 #       <[Saint]> (thought it doesn't actually state it there, there's also a Real Name policy)
18.13.42 #       <[Saint]> the git config username should be your realname, and the git config email address the same as the address used in gerrit.
18.14.04 #       <Nephiel> I was about to post it to Flyspray
18.14.31 #       <gevaerts> We do prefer gerrit, but if it's a simple patch I suspect it can go on flyspray
18.14.57 #       <gevaerts> Well, I do prefer bugfixes on flyspray over no bugfixes at all, anyway :)
18.15.57 #       <[Saint]> Shhhhuuuuuush!
18.16.01 #       <[Saint]> He's fixing bugs.
18.16.07 #       <[Saint]> We want him to come back! :P
18.18.53 Quit    krabador (Quit: Sto andando via)
18.19.04 ***     Saving seen data "./dancer.seen"
18.29.05 #       <Nephiel> Submitted http://www.rockbox.org/tracker/task/12887
18.30.23 #       <Nephiel> It doesn't allow me to add FS#11376 as related task but it's linked in the description
18.30.39 #       <gevaerts> Why didn't you just add it to FS#11376?
18.31.41 #       <gevaerts> And especially, why does flyspray want to add lots of empty lines to everything it outputs? While it doesn't *really* break patches, it does break rss feeds...
18.31.58 #       <gevaerts> It didn't use to do that until quite recently
18.32.04 #       <[Saint]> this seems like a new thing.
18.32.06 #       * gevaerts looks for a Swede to look at this
18.32.14 #       <[Saint]> aha, glad I'm not the only that noticed.
18.32.15 #       <Nephiel> oops, you're right, I should have added it to 11376
18.33.06 #       <[Saint]> twice now I've clicked a flyspray patch link and sat there "waiting for the page to load"
18.33.14 #       <[Saint]> ...before realizing I needed to scroll.
18.33.43 #       <gevaerts> [Saint]: well, for me it mainly breaks my new tasks and edited tasks "smart bookmarks"
18.34.43 #       <Nephiel> I had the blank space issue too with patches, but screenshots are worse, they don't load at all
18.38.08 #       <gevaerts> Bagder: do you have any idea why just about anything in php on the server (flyspray, your blog, ...) adds loads of empty lines at the start of all output?
18.38.27 #       <gevaerts> That's fine for html, but it breaks anything els
18.38.28 #       <gevaerts> e
18.59.10 Join    SovonHalder [0] (~RED@115.187.62.29)
18.59.11 #       <Bagder> gevaerts: hm, no I don't but I figure I should look into it
18.59.51 #       <gevaerts> Bagder: you could also try to find Zagor of course :)
19.04.56 #       <Bagder> that's also a good idea! =)
19.06.00 #       <SovonHalder> I posted a thread around 2 hours ago on the forum under 'Support and General Use>Hareware'....haven't received any replies yet..PLEASE help me..I am desperate.. The thread is this : Support and General Use
19.06.06 #       <SovonHalder> http://forums.rockbox.org/index.php/topic,43310.0.html
19.06.25 #       <[Saint]> 2 hours is a VERY short time.
19.06.32 #       <copper> SovonHalder: if all else fails, I suggest reformatting the iPod's drive with emCORE, and then refrain from renaming the drive
19.07.38 #       <copper> does anyone know how Rockbox would react after changing the drive label on the PC?
19.07.56 #       <SovonHalder> really? all this is happening just because RENAME'd my drive name ?
19.08.32 #       <copper> I don't know, but you yourself said that's when the problems started happening
19.08.45 #       <SovonHalder> Apparently yes..
19.08.55 #       <SovonHalder> but I hate to believe such thing
19.09.00 #       <[Saint]> Rockbox shouldn't give a flying fudge about the volume label.
19.10.31 #       <copper> any chance that Windows would be doing something else during that operation, that would explain it?
19.10.47 #       <copper> or maybe it's really a Windows problem altogether?
19.10.58 #       <TheSeven> SovonHalder: looks like there's file system corruption, possibly caused by not properly ejecting the ipod or by hardware malfunction
19.11.24 #       <TheSeven> the battery behavior that you reported is somewhat normal. rockbox only has a crude estimate of the battery state
19.11.25 #       <SovonHalder> I have itunes installed..should I uninstall it ?
19.11.35 #       <SovonHalder> Normal ?
19.11.40 #       <SovonHalder> Holy jeez
19.11.57 #       <TheSeven> so it can happen that it says 95% while it's actually 100%
19.12.06 #       <TheSeven> and it won't even start charging before it drops below 85-90%-ish
19.12.08 #       <[Saint]> Depends how you want to manage your music.
19.12.11 #       <SovonHalder> first two days it worked fine...then suddenly it just like that!!!??
19.12.15 #       <[Saint]> iTune sis no longer required.
19.12.38 #       <TheSeven> the charging is hardware controlled, so it will behave the same as it did with the apple firmware. it's just that our battery meter might be a bit off at times
19.12.46 #       <[Saint]> I rather suspect that at some point you didn't properly eject the device.
19.12.59 #       <[Saint]> This can, and often will, trash the filesystem.
19.13.21 #       <TheSeven> especially in combination with the rather flaky USB support of the classic
19.13.37 #       <SovonHalder> Saint: I think I might have done that
19.14.15 #       <SovonHalder> when the Drive disappeared, i couldn't find an option for safe removal...so I just ejected..
19.14.32 #       <copper> SovonHalder: do you have a copy of your files on your PC?
19.14.38 #       <SovonHalder> :)
19.14.40 #       <SovonHalder> of course
19.15.11 #       <copper> then long press Menu + Select until you get to the emcore menu
19.15.22 #       <copper> downscroll until "Tools"
19.15.32 #       <copper> "reformat data partition"
19.15.41 #       <copper> that should clean up the mess
19.15.42 #       <[Saint]> Argh! No!
19.15.47 #       <copper> why not?
19.15.50 #       <[Saint]> menu+select == bad!
19.15.54 #       <copper> what?
19.16.12 #       <TheSeven> copper: shut it down properly if you can still do so (i.e. if it isn't completely locked up)
19.16.19 #       <[Saint]> You should only do this if you can't avoid it.
19.16.33 #       <TheSeven> menu+select resets physically stress the hard disk drive
19.16.34 #       <copper> sorry, I meant while off
19.16.34 #       <[Saint]> Encouraging it as a shutdown/reset is bad behavior.
19.16.53 #       <[Saint]> ...reset the player, while off?
19.16.55 #       <copper> how do you avoid emcore going directly to rockbox?
19.16.58 #       <[Saint]> why would that be needed?
19.17.01 #       <copper> long press play?
19.17.05 #       <[Saint]> any button.
19.17.08 #       <TheSeven> if you have fastboot enabled? just press and hold any button during boot
19.17.13 #       <copper> ok, sorry
19.17.27 #       <SovonHalder> formatting data partition would recover system files? if they are corrupted?
19.17.35 #       <[Saint]> Hell no. :)
19.17.47 #       <TheSeven> SovonHalder: it will basically revert your ipod to the state that it was in immediately after installing emcore
19.17.52 #       <copper> just unpack the rockbox build zip onto the formatted drive
19.18.00 #       <[Saint]> copper is possibly unwisely skipping that route.
19.18.11 #       <[Saint]> You can of course attempt recovery of the filesystem.
19.18.26 #       <TheSeven> can be tricky if USB is too flaky
19.18.36 #       <[Saint]> see: attempt :)
19.19.12 #       <[Saint]> I always like to try first, beets a format and shifting many GB of data around.
19.19.17 #       <SovonHalder> Saint: so you were telling about system files corruption due to improper unsafe removal of my drive.. then I don't need to reformat data partition right ?
19.19.20 #       <[Saint]> *beats too
19.20.10 #       <SovonHalder> Just tell em what should I do now..
19.20.55 #       <TheSeven> you can try to repair the file system, but these reconnects might be preventing you from doing that
19.20.56 #       <[Saint]> No. You don't *need* to - but, recovery may not work, if you do have your files backed up and the time isn't an issue, then by all means, just format it.
19.21.27 #       <[Saint]> Its not something you need to do, necessarily, but it may be faster to do so in the end.
19.21.58 #       <[Saint]> It just happens to be a pet peeve of mine when recovery of the filesystem isn;t even a first suggested option. :)
19.22.29 #       <SovonHalder> Do I need need iTunes uninstalled ?
19.22.44 #       <SovonHalder> some apple services caused issues last time
19.22.52 #       <SovonHalder> when I was installing
19.23.01 #       <[Saint]> With installation. We're past that now.
19.23.01 #       <SovonHalder> rockbox for the first time
19.23.25 #       <[Saint]> If iTunes is how you manage your music, feel free to leave it there.
19.23.35 #       <SovonHalder> I hate iTunes...
19.23.47 #       <SovonHalder> that's why i installed rockbox..
19.24.09 #       <SovonHalder> I haven't played a single track in last 3 years in iTunes..so I'll uninstall it.. next ?
19.24.18 #       <SovonHalder> how do I format ?
19.24.47 Join    kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee)
19.25.01 #       <TheSeven> SovonHalder: within the emcore boot menu, scroll to the right, there's a "tools" icon
19.25.13 #       <TheSeven> in the tools menu, there's a "reformat data partition" option
19.25.39 #       <[Saint]> it'll give some form of "are you sure?" message - tell it yes.
19.26.14 #       <SovonHalder> reformatting dara parttion..
19.26.25 #       <SovonHalder> It's done..next ?
19.26.47 #       <TheSeven> now just plug it in and check if it works again
19.27.07 #       <TheSeven> (boot rockbox if you haven't done that already)
19.27.14 #       <TheSeven> then extract the rockbox zip file to reinstall that
19.27.16 #       <[Saint]> TheSeven: no new build?
19.27.32 #       <[Saint]> ah - yes: here - http://build.rockbox.org/data/rockbox-ipod6g.zip
19.27.42 #       <SovonHalder> no rockbox directory----installation complete
19.28.00 #       <TheSeven> well, be aware that new (as in younger than a year) builds are likely to show more USB trouble than older ones for some reason
19.28.00 #       <[Saint]> this is expected, you just wiped it out :)
19.28.08 #       <[Saint]> extract the above linked .zip to the root of the device.
19.28.30 #       <SovonHalder> w8
19.28.35 #       <TheSeven> and then just shut it down and boot it back up, then you're running a current rockbox version
19.28.54 #       <[Saint]> RbUtil could also take over at this point if you wanted.
19.29.29 #       <[Saint]> RoLo should fire, no need for shutdown.
19.30.00 #       <SovonHalder> it took 12 seconds to show the drive
19.30.02 #       <SovonHalder> is this normal ?
19.32.15 #       <SovonHalder> how do I shut it down?
19.32.22 #       <SovonHalder> long press the play button ?
19.32.23 #       <[Saint]> hold play.
19.32.27 #       <SovonHalder> okay
19.33.51 #       <SovonHalder> Version: 49bcf35-130724
19.34.57 #       <SovonHalder> Can I use this theme?
19.34.58 #       <SovonHalder> http://themes.rockbox.org/index.php?themeid=1883&target=ipodvideo
19.35.06 #       <[Saint]> yes.
19.35.15 #       <SovonHalder> I mean do themes create problems ?
19.35.18 #       <[Saint]> you can use any of the themes from the iPod Video section.
19.35.26 #       <[Saint]> they can, yes.
19.36.12 #       <SovonHalder> really? I mean are those problems often? If so, I can hang on to the default theme..
19.36.23 #       <SovonHalder> Iy's just the theme is simple
19.36.55 #       <[Saint]> Themes are user submitted - there is no expectation of quality with them.
19.37.27 #       <SovonHalder> By quality did you mean 'stabily' or 'compatibility' ?
19.38.19 #       <[Saint]> We can only guarantee the code parses, not that it is correct, or functions as intended.
19.39.21 #       <SovonHalder> I'm sorry for bothering you all.. my bad.. but I have to transfer over 60GBs of music to my drive now. That's not something one can do whenever he wants..so any words on how do I prevent happening such issues in furute ?
19.39.42 #       <SovonHalder> *future
19.39.52 #       <[Saint]> Always safely remove.
19.39.53 #       <lebellium> [Saint]: although what you say is correct, it seems that you are frightening him :)  I would simply say "they may create problems but most of them don't and if there is any problem with a theme you can always switch back to the default cabbiev2"
19.40.14 #       <copper> SovonHalder: I haven't had problems with that theme
19.40.44 #       <SovonHalder> Cooper: then I'll stick with you..
19.40.54 #       <[Saint]> lebellium: I'm just trying very hard not to say "Yes, it will work as advertised", because I can't make that claim :)
19.41.38 #       <[Saint]> I never said *don't* try it...
19.41.38 #       <SovonHalder> please tell me do I prevent happening such issues in future ?
19.42.03 #       <copper> 17:39:53 UTC <[Saint]> Always safely remove.
19.42.05 #       <[Saint]> The only thing you can do, really, is always safely remove the device.
19.42.06 #       <SovonHalder> rather than safe removal
19.42.11 #       <[Saint]> that's it.
19.42.12 #       <SovonHalder> okay..
19.42.29 #       <SovonHalder> can I rename the drive label /
19.42.31 #       <SovonHalder> ?
19.42.48 #       <[Saint]> In theory, yes.
19.45.12 #       <SovonHalder> I just connected it to my PC & it took 30 seconds to sho me drive.. is this also normal ?
19.45.52 #       <TheSeven> that can be normal
19.45.52 #       <copper> Windows can be sucky that way
19.46.00 #       <TheSeven> windows sometimes reads the whole FAT while mounting
19.46.25 #       <TheSeven> which is ~320MB on a 160GB ipod
19.46.35 #       <TheSeven> so 30 seconds sounds about right
19.49.02 #       <SovonHalder> I just renamed. ..nothing wrong happened.. went A OK..
19.49.31 #       * Nephiel just commited a fix for FS#11376 to gerrit: http://gerrit.rockbox.org/r/#/c/530/
19.54.46 #       <copper> well fuck.
19.55.06 #       <copper> my Fuze+ just crashed while connected to my laptop, after hours of copying files
19.55.13 #       <copper> nothing else connected
19.55.32 #       <SovonHalder> :(
19.55.36 Join    Strife89 [0] (~Strife89@adsl-98-80-224-47.mcn.bellsouth.net)
19.56.25 #       <SovonHalder> I am not a jinx..am i? :P
19.56.46 #       <copper> now fsck.vfat is "Reclaiming unconnected clusters." and it's taking 100% of one CPU core and I have no idea when it will complete
19.56.48 #       <[Saint]> No. It just blew a prior assumption away, that's all.
19.57.00 #       <copper> [Saint]: it doesn't
19.57.15 #       <copper> the ODAC being connected is certainly a trigger
19.57.25 #       <copper> that doesn't mean it is the only cause of Rockbox crashing
19.57.29 #       <[Saint]> you said your devices *never* crashed without the ODAC
19.57.45 #       <copper> yeah
19.58.14 #       <[Saint]> [01:28:40] <copper> pamaury: my devices almost always crash when my ODAC is connected
19.58.14 #       <[Saint]> [01:28:44] <copper> and NEVER crash when it's not
19.58.17 #       <copper> still doesn't erase the fact that they almost always crash with the ODAC connected
19.59.05 #       <SovonHalder> umm...what is the full form of ODAC ?
19.59.13 #       <copper> geez, what's the point of running fsck with -v when there's no progress
19.59.20 #       <copper> SovonHalder: what?
19.59.33 #       <SovonHalder> nevermind..sorry
20.03.23 #       <Nephiel> SovonHalder: I think it's a mix of Objective Desktop Amplifier and Digital-Analog Converter
20.05.56 #       <SovonHalder> when I click on safely remove 'Apple iPo...' in system tray..it shows 'Safe to Romove Hardware' but the USB logo on iPod classic screen doesn't disappear.. then awhen I remove the cable there showed a tiny warning for 12 seconds that somewhat says 'Error Accessing Playlist control file' or something like that...what is this issue ? I haven't copied a single track yet
20.07.15 #       <[Saint]> The USB image is still there. because its still connected. :)
20.07.39 #       <copper> ugh, copying to my 64 GB microSDXC card through the adapter and my laptop's card reader is twice as fast as copying via the Fuze+
20.07.44 #       <[Saint]> It doesn't mean "I'm connected, and mounted", it merely means "I see I'm connected via USB"
20.12.55 Join    Guest11127 [0] (Slayer@c-69-143-178-62.hsd1.va.comcast.net)
20.16.16 Join    krabador [0] (~krabador_@unaffiliated/krabador)
20.19.07 ***     No seen item changed, no save performed.
20.28.23 #       <TheSeven> is there anybody here for whom UMSboot fails to mount properly on nano2g?
20.28.35 #       <TheSeven> I need testers for the new one
20.29.29 #       <SovonHalder> Well, how long the USB Image stays? It's about 3 minutes+ since I saw 'Safe to Remove' banner.
20.30.20 #       <[Saint]> Is it still connected via USB?
20.30.45 #       <SovonHalder> yes
20.30.52 #       <SovonHalder> I haven't unplugged it yet
20.30.57 #       <[Saint]> ...did you read what I wrote above?
20.31.03 #       <[Saint]> It doesn't mean "I'm connected, and mounted", it merely means "I see I'm connected via USB"
20.31.15 #       <SovonHalder> Oo..sorry..
20.31.20 #       <SovonHalder> I missed tat line
20.31.23 #       <[Saint]> the device will give no visual indicator it is safe to eject.
20.31.46 #       <SovonHalder> what about that 'Error Accessing Playlist control file' then ?
20.32.16 #       <[Saint]> I believe that is expected for a first boot.
20.34.50 Quit    krabador (Ping timeout: 260 seconds)
20.39.10 #       <SovonHalder> I disconnected.. turned of my ipod..turned on my ipod..connected via usb---again shows 'Error Accessing Playlist control file'
20.39.31 #       <SovonHalder> I safely removed..connected again... still shows 'Error Accessing Playlist control file'
20.40.09 #       <TheSeven> SovonHalder: how old is that ipod?
20.40.47 #       <SovonHalder> it's iPod Classic 7G 160G.. I bought it around 4 months ago Brand Newq
20.40.51 #       <SovonHalder> *New
20.44.31 #       <TheSeven> fully working (on my device and ubuntu precise) new umsboot source: https://mega.co.nz/#!4Iw3USyD!EK2O-Q-jdumd6xYPeb1FVwfyh0x-tR0ljUvA2AfGU7M
20.44.38 #       <TheSeven> no lcd driver yet, but the rest works just fine
20.44.59 #       <TheSeven> SovonHalder: OK, so I hope we can rule out HW damage
20.45.14 #       <TheSeven> I've seen numerous hard drives fail on the 80GB and 120GB series
20.46.17 #       <SovonHalder> there are about Eight threads on this particular isue on rock box forum saying "" 'Error Accessing Playlist control file' on my bla bla bla""
20.46.52 #       <SovonHalder> everyone says it's not that important
20.47.00 #       <SovonHalder> is that right ?
20.47.42 Join    krabador [0] (~krabador_@unaffiliated/krabador)
20.49.46 Join    lorenzo92 [0] (~chatzilla@host171-106-dynamic.17-79-r.retail.telecomitalia.it)
20.54.05 Join    fs-bluebot [0] (~fs-bluebo@g225252157.adsl.alicedsl.de)
20.57.10 #       <lorenzo92> kugel: did you read about usb suppport on hosted platforms?
20.57.24 #       <lorenzo92> (if you had time :) )
21.05.06 Join    thegeek_ [0] (~thegeek@40.200.16.62.customer.cdi.no)
21.05.41 Quit    thegeek (Read error: Connection reset by peer)
21.05.42 Join    rdn [0] (~oop@cpe-69-204-124-212.buffalo.res.rr.com)
21.06.18 Quit    Nephiel (Ping timeout: 246 seconds)
21.10.57 #       <saratoga> copper:  i guess the clockspeed is reported wrong in plugins?
21.13.28 #       <saratoga> what is the boosted clock speed on the Fuze+?
21.14.37 #       <[Saint]> ~450MHz
21.15.14 #       <[Saint]> maybe plugins expect the clockspeed in Hz?
21.15.30 #       <[Saint]> the F+ (weirdly) reports in KHz
21.18.03 #       <copper> no clue
21.18.20 #       * [Saint] thinks he may have solved that riddle.
21.18.39 #       <[Saint]> That would account for the really low realtime requirement
21.18.48 #       <saratoga> the fuze+ memory is really slow
21.19.02 #       <saratoga> copper:  feel like doing one more benchmark?
21.19.11 #       <saratoga> Bagder:  around?
21.19.18 #       <[Saint]> saratoga: you think its KHz vs Hz?
21.19.23 #       <saratoga> yeah looks like it
21.19.29 #       <saratoga> the numbers are off by a factor of 1000
21.19.34 #       <[Saint]> the debug screen in the F+ reports in KHz
21.19.43 #       <[Saint]> ..no idea why.
21.19.45 #       <saratoga> the define is probably wrong on the fuze+
21.19.54 #       <TheSeven> SovonHalder: it is in most cases an indicator of rockbox not being able to access the file system at all (or write it), which typically IS rather important
21.20.06 #       <kugel> lorenzo92: no, where?
21.20.24 #       <copper> what?
21.20.36 #       <copper> what numbers are wrong?
21.20.43 #       <saratoga> can you run the benchmark one more time with the boost option disabled?
21.20.48 #       <[Saint]> CPU realtime
21.21.01 #       <copper> uh?
21.21.04 #       <saratoga> this will mean that the CPU clock is much lower relative to the memory (or equivalently that the memory seems much faster)
21.21.12 #       <saratoga> i believe there is an option in test_codec to do this
21.21.16 #       <[Saint]> No idea why such foolishly low numbers didn;t arouse suspicion in me earlier.
21.21.29 #       <[Saint]> now I look at it, its so improbable I should've caught it.
21.21.30 #       <copper> cpu real time is within range of the other targets
21.21.48 #       <[Saint]> 0.01MHz?
21.21.57 #       <copper> ah
21.21.59 #       <TheSeven> less than one clock per sample, funny :)
21.22.04 #       <copper> ithought you meant %
21.22.22 #       <[Saint]> I *really* should've caught that earlier.
21.22.26 #       <copper> yes
21.22.29 #       <copper> I blame you
21.22.36 #       <[Saint]> that's fair. :)
21.23.13 #       <copper> saratoga: I'll ping you in about 40 minutes
21.23.27 #       <saratoga> yeah the numbers are fine, but they're just in units of GHz not MHz :)
21.23.33 #       <saratoga> ok
21.23.38 #       <saratoga> also i have Opus files
21.23.48 #       <saratoga> http://web.mit.edu/mgg6/www/opus/
21.23.55 #       <copper> so, * 1000?
21.24.00 #       <saratoga> i've been trying to get Bagder to upload these for months 
21.24.16 #       <saratoga> yeah, but just do 454/realtime*100
21.24.27 #       <copper> wait, what?
21.24.42 #       <saratoga> MHz = 454/%realtime*100
21.25.10 #       <copper> mmmkay?
21.25.20 #       <saratoga> i can fix that later
21.25.32 #       <saratoga> i have a script which formats them for the wiki
21.25.35 #       <saratoga> i can have it do the math itself
21.25.59 #       <saratoga> anyway since the fuze+ never boosts, the boosted test results are probably misleading
21.26.14 #       <saratoga> most likely when the CPU is unboosted the memory latency is far lower, and therefore much less cycles are needed
21.26.40 #       <[Saint]> you can force an unboosted test_codec run, no?
21.26.53 #       <saratoga> yeah i think its in the test_codec plugin
21.27.00 #       <saratoga> IIRC i added it years ago
21.27.10 #       <saratoga> or  at least i think i committed that
21.27.14 #       <saratoga> if its not there then my bad :)
21.27.28 Join    Nephiel [0] (~5332f9b8@www.haxx.se)
21.28.08 #       <saratoga> looking at these results though our MDCT lib does really, really badly on modern targets
21.28.15 #       <saratoga> we definitely over-optimized it for PP
21.29.11 #       <saratoga> stripwax came up with all these neat math that makes the trig tables small enough to fit into IRAM, but they end up having really irregular access patterns which probably ruins caching on devices without IRAM
21.29.13 Quit    SovonHalder ()
21.29.13 #       <copper> did you see my Classic and Clip+ results?
21.29.18 #       <saratoga> yeah i saw them above
21.29.29 #       <copper> ok
21.29.49 #       <saratoga> do you have the build numbers?
21.29.54 #       <saratoga> for the wiki
21.31.23 #       <copper> 49bcf35
21.31.53 #       <saratoga> thanks
21.32.16 #       <saratoga> damn it forgot that my perl script was converted to ruby at some point
21.32.20 #       <saratoga> have to figure out how to run that
21.34.06 Quit    krabador (Ping timeout: 260 seconds)
21.34.10 Nick    DormantBrain is now known as SuperBrainAK (~andy@shared02.balt01.cd.2g2u.net)
21.37.08 #       <lorenzo92> kugel: well there is something bad happening when connecting the usb cable
21.37.37 #       <lorenzo92> kugel: i.e. app crashes, for example when doing a screendump or something else that is not a stub in usb_enable
21.38.07 #       <lorenzo92> now I have setup the serial, I suspect a concurrency issue or something related (memory issue)
21.40.26 #       <saratoga> copper:  http://www.rockbox.org/wiki/CodecPerformanceComparison#Freescale_i.MX21_40454MHz_ARM926EJ_45S_44_Fuze_43_41
21.41.41 #       <copper> nice
21.43.19 Join    krabador [0] (~krabador_@unaffiliated/krabador)
21.44.00 #       <lorenzo92> kugel, pamaury: I confirm, segmentation fault when inserting usb cable and right after doing screendump
21.44.12 #       <lorenzo92> on hosted target ypr0 at least...
21.51.05 #       <saratoga> hmm our ruby script cannot handle comparing some of the old test codec logs to the newer ones
22.00.01 #       <saratoga> according to these tests, vorbis has gotten slower in recent years
22.00.03 #       <saratoga> i wonder why
22.00.08 #       <saratoga> on AMSv2 at least
22.00.22 #       <lorenzo92> kugel: funny, with debug symbols + logf usb screendump doesn't crash when inserting cable, but when removing it \o/
22.02.21 #       <lorenzo92> also funny that gdb doesn't work now pff
22.06.32 Quit    Nephiel (Quit: CGI:IRC)
22.07.29 #       <copper> saratoga: what do you want me to benchmark?
22.07.53 #       <saratoga> can you grab those Opus files and add them to your folder?
22.08.07 #       <saratoga> and then repeat the test, but this time set the boost to off so it tests at 64 MHz?
22.08.16 #       <saratoga> i think there should be an option in test_codec itself to do this
22.10.18 #       <copper> saratoga: I think you forgot wavpack x4 on the wiki
22.12.22 #       <saratoga> the ruby scirpt ignores it for some reason
22.14.37 #       <kugel> lorenzo92: probably too small stack
22.15.04 #       <lorenzo92> kugel: hum and what value do you suggest?
22.15.29 #       <kugel> which thread does the screendump run on?
22.16.00 #       <lorenzo92> "usb"
22.16.33 #       <lorenzo92> but i'm not sure it's due to small stack
22.16.35 #       <kugel> try 1MB or so
22.16.39 #       <lorenzo92> ok
22.17.13 #       <saratoga> kugel:  did you write the test codec ruby script?
22.17.36 #       <kugel> yea
22.19.01 Quit    Raptors (Read error: Connection reset by peer)
22.19.09 ***     Saving seen data "./dancer.seen"
22.19.12 #       <saratoga> any idea why it can't parse "wv_normx4.wv" but works with "wv_fastx3.wv"
22.20.24 #       <lorenzo92> kugel: interesting, with exactly 1 mb it quits with "Killed"...seems like out of memory
22.21.28 Quit    y4n (Quit: Assumption is the mother of all fuckups)
22.23.01 #       <lorenzo92> kugel: 512k, doesn't get killed at startup, but also crashes
22.24.54 #       <kugel> hm. can you get the backtrace from gdb?
22.28.17 #       <copper> saratoga: running new tests now with opus files included, on the Fuze+, Clip+ and iPod Classic
22.28.28 #       <saratoga> thanks
22.28.30 #       <copper> I selected boosting=no on the FUze+ and the Classic
22.28.34 #       <saratoga> nice
22.28.36 #       <copper> I don't see that option on the Clip+
22.28.37 #       <saratoga> those will be interesting
22.28.42 #       <saratoga> yeah the clip+ has boosting disabled
22.28.53 #       <saratoga> it was a bit unstable and we never figured out why
22.29.17 #       <lorenzo92> kugel: i have gdb running atm, what should i do?
22.29.26 #       <kugel> lorenzo92: I dont think concurrency is it, thats generally not a problem with out cooperative thread architecture
22.29.30 #       <copper> ugh, it's a lot slower
22.29.36 #       <copper> this is going to take ages
22.29.57 #       <kugel> lorenzo92: get a backtrace when it crashes
22.31.13 #       <lorenzo92> kugel: http://pastie.org/private/6fk6heneazyjqcb1511bg
22.31.38 #       <kugel> that's without debug symbols right?
22.31.51 #       <kugel> you can look up the addresses in the .map file
22.32.27 #       <lorenzo92> yep no symbols
22.33.08 #       <kugel> you can also try to use arm-*-addr2line to map the addresses to source file lines, but that needs a non-stripped .elf (there should be one in the build dir)
22.34.13 #       <lorenzo92> yes there is the elf, i'll give a try, previous addresses don't tell anything interesting
22.34.59 Join    stripwax [0] (~Miranda@rockbox/developer/stripwax)
22.35.49 #       <lorenzo92> kugel: crtstuff.c ?
22.36.43 #       <kugel> what command did you run?
22.36.59 #       <lorenzo92> arm-ypr0-linux-gnueabi-addr2line -e rockbox.elf -a 0x00050624
22.37.32 #       <lorenzo92> ahh
22.37.34 #       <lorenzo92> wait
22.37.42 #       <lorenzo92> with -f i also get usb_thread
22.37.43 #       <lorenzo92> ;)
22.38.30 #       <kugel> where is crtstuff.c?
22.38.31 #       <lorenzo92> kugel: and also queue_wait
22.38.57 #       <lorenzo92> kugel: http://pastie.org/private/sjzhpkl8dhnaog77aujlw
22.39.57 #       <kugel> ah it seems addr2line can't properly map to the source  files
22.40.18 #       <kugel> perhaps it gives a more useful file if run from the top-level folder?
22.42.35 #       <lorenzo92> nope, but it might be fine, no? actually queue_wait is used in usb_thread
22.43.43 #       <kugel> yea but you have to look up the disassembly to find the actual line
22.44.11 #       <kugel> I dont know how queue_wait can possibly crash.
22.44.36 Join    Zarggg [0] (~zarggg@24.229.140.62.res-cmts.sm.ptd.net)
22.46.26 Join    pamaury [0] (~quassel@rockbox/developer/pamaury)
22.48.44 Join    tertu [0] (~tertu@65-128-181-81.mpls.qwest.net)
22.55.22 #       <lorenzo92> kugel: okay, so it seems that the crash happens right in the first lines, address points to a load instruction
22.58.40 #       <copper> saratoga: if the Clip+ isn't "boosted", why is it so much faster than the other two?
22.59.05 #       <copper> or is it boosted and what didn't work was, erm, "unboosting" it?
23.00.02 #       <kugel> lorenzo92: perhaps called with a NULL pointer?
23.00.22 #       <lorenzo92> i was thinking the safe, i'll place a temporary panic in case, let's see
23.00.26 #       <lorenzo92> *same
23.04.29 #       <copper> saratoga: Clip+ codec performance log: http://pastebin.com/yHV8c2Gy
23.05.14 Quit    Strife89 (Ping timeout: 264 seconds)
23.05.18 #       <copper> the other two are maybe halfway through
23.14.17 #       <lorenzo92> kugel: now stops at switch_thread()
23.19.45 #       <copper> saratoga: opus 128k on the Classic, unboosted: 99.55% real time :-/
23.24.46 #       <lorenzo92> kugel: unfortunately i can't really figure out what's going on atm :(
23.25.27 #       <lorenzo92> i only hope it's not a fault that gets undiscovered in native ports....
23.28.28 #       <ender`> are there any known problems with USB on Clip Zip in current git version? Windows either reports an error, or doesn't detect the player at all when running rockbox for me
23.32.42 #       <saratoga> yeah it doesn't seem to be all that stable
23.32.54 #       <saratoga> copper:  that means it'll very rarely boost, which is not too bad
23.33.24 #       <saratoga> copper:  are you doing this tests with or without the DSP effects (hopefully without)
23.33.26 #       <ender`> ok. is this only a problem in git, or is it the same in stable, too?
23.33.37 #       <copper> without
23.33.47 #       <copper> well
23.34.08 #       <kugel> lorenzo92: can you show how you increased the stack to 512k?
23.34.20 #       <copper> all DSPs are disabled in the normal Rockbox menus, and I didn't select anything else
23.34.38 #       <kugel> if it crashes in different places it really looks like a stack overflow
23.34.43 #       <lorenzo92> kugel: well now I was running on default stack size...anyway just 512*1024
23.34.52 #       <copper> hmm
23.35.20 #       <lorenzo92> kugel: wops is a long
23.35.23 #       <lorenzo92> ^^
23.35.40 #       <kugel> so it was 2MB?
23.35.44 #       <saratoga> copper:  isn't there an option test_codec that asks if you want to benchmark with DSP too?
23.35.45 #       <lorenzo92> yep
23.36.04 #       <lorenzo92> i forgot the /sizeof(long)
23.36.05 #       <copper> yes but I didn't select that
23.36.27 #       <copper> I ran test_codec folder
23.37.14 #       <lorenzo92> kugel: but then the question remains the same (not only the song), why the hell if i place a sleep or printf around i may be lucky and it don't get a crash?!
23.38.02 #       <kugel> dont know
23.38.43 #       <kugel> lorenzo92: are you sure screendump is called from the ui thread?
23.38.47 #       <kugel> usb thread*
23.39.17 #       <kugel> hosted doesn't have screendump so far, for native it's on the usb thread but for sims it's on a separate one
23.39.31 #       <kugel> now I don't know how you implemented it
23.39.48 #       <lorenzo92> yeah, i've just double checked...it's an inline function that calls screen_dump
23.40.06 #       <lorenzo92> well actually screen dump works perfectly, there was just a path problem i solved in another patch
23.40.50 Join    Raptors [0] (~whoneedsa@216-58-33-203.cpe.distributel.net)
23.43.10 #       <lorenzo92> kugel: the point is that even if I fill something in usb_enable (to say a system() call or similar), it crashes ...
23.43.54 #       <kugel> might be OOM, if rockbox claims all memory there's little left for system()
23.44.08 #       <kugel> remember that systems spawns several processes (at least 2)
23.44.45 #       <lorenzo92> pretty sure (i tested it long time ago) that issuing a system() through a menu button perfectly works
23.45.50 #       <lorenzo92> or it may be that usb thread is heavy and memory badly managed, who knows...
23.46.44 #       <kugel> can you do without system()? what are you trying to execute?
23.47.14 Quit    Raptors (Read error: Connection reset by peer)
23.47.30 Join    Raptors [0] (~whoneedsa@216-58-33-203.cpe.distributel.net)
23.47.45 #       <lorenzo92> forgetting about system(), there is still screendump...anyways I have to call a safe-mode-like script for usb mode
23.49.05 #       <lorenzo92> kugel: idea! what if trying to lower memsize a little?
23.49.27 #       <kugel> try it, you can adjust it in configure
23.49.52 #       <lorenzo92> indeed, compiling
23.53.16 #       <lorenzo92> kugel: nope, nothing
23.55.25 Join    jrw_ [0] (~601cd28a@www.haxx.se)
23.57.51 Quit    jrw_ (Client Quit)