--- Log for 05.05.111  Server: zelazny.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 1 day and 3 hours ago

00.01.59 Quit    Jerom1 (Quit: Leaving.)
00.05.24 ***     Saving seen data "./dancer.seen"
00.07.29 Quit    bertrik (Read error: Connection reset by peer)
00.09.12 Quit    pamaury (Remote host closed the connection)
00.18.43 #       <CIA-87> New commit by 03bluebrother (r29824): Rockbox Utility: add build id to version string. ...
00.21.40 Quit    silbo (Read error: Connection reset by peer)
00.23.22 Quit    n1s (Remote host closed the connection)
00.26.36 Quit    liar (Quit: hallowed are the ori!)
00.28.08 #       <bluebroth3r> hanging build?
00.28.18 #       <CIA-87> r29824 build result: All green
00.28.37 Join    Gnos [0] (~chatzilla@adsl-99-120-26-236.dsl.dytnoh.sbcglobal.net)
00.28.42 #       <bluebroth3r> ah, slow one only
00.29.51 #       <Gnos> not a big deal, but maybe someone would like to know about this:  If you update RB, disconnect, and the player immediately voices the battery level, the prompt to reboot RB disappears.
00.31.33 #       <sideral> Thanks Gnos! It would be nice if you could file a bug report, though, otherwise this issue likely will get lost
00.32.23 #       <Gnos> sideral: okay I will file bug rep
00.33.16 #       <sideral> thanks!
00.33.28 Quit    Beta2K (Ping timeout: 246 seconds)
00.40.35 Quit    ender` (Quit:  Where there's a will, there's an inheritance tax.)
00.41.06 Join    Beta2K [0] (~Beta2K@d24-36-131-14.home1.cgocable.net)
00.42.05 #       <sideral> bluebrother: The comment in the commit you just checked in needs fixing: it talks about BUILD rather than BUILDID
00.42.20 Join    Scromple [0] (~Simon@115-64-195-104.tpgi.com.au)
00.45.04 Quit    bieber (Ping timeout: 240 seconds)
00.46.21 #       <Gnos> Here's the "ROLO prompt disappears when battery level is voiced" FS:  http://www.rockbox.org/tracker/task/12098
00.48.22 Quit    Gnos (Quit: ChatZilla 0.9.86.1 [Firefox 3.6.17/20110420140830])
00.55.16 Join    fxb [0] (~felixbrun@h230n1c1o1037.bredband.skanova.com)
01.05.50 Quit    sideral (Quit: Leaving.)
01.06.30 Join    Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com)
01.08.05 Quit    Unhelpful (Read error: Connection reset by peer)
01.08.23 Join    Unhelpful [0] (~quassel@rockbox/developer/Unhelpful)
01.09.46 Join    japc [0] (~japc@bl16-225-203.dsl.telepac.pt)
01.22.14 Join    cjcopi [0] (~craig@charon.craig.copi.org)
01.33.02 Join    CaptainKewl [0] (~captainke@207-38-215-126.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com)
01.34.34 Join    T44 [0] (~Topy44@g228228216.adsl.alicedsl.de)
01.38.18 Quit    Topy44 (Ping timeout: 240 seconds)
01.47.26 Quit    DerPapst (Quit: Leaving.)
01.47.31 Quit    fxb ()
01.52.51 Quit    [Saint] (Ping timeout: 240 seconds)
01.59.31 Join    [Saint] [0] (~st.lasciv@124-197-3-117.callplus.net.nz)
02.05.27 ***     Saving seen data "./dancer.seen"
02.08.51 Quit    gevaerts (Ping timeout: 250 seconds)
02.09.36 Join    gevaerts [0] (~fg@rockbox/developer/gevaerts)
02.17.51 Quit    Beta2K (Ping timeout: 260 seconds)
02.18.16 Join    n17ikh [0] (~n17ikh@c-174-56-148-108.hsd1.sc.comcast.net)
02.18.19 Quit    MethoS- (Remote host closed the connection)
02.18.34 Join    Beta2K [0] (~Beta2K@d24-36-131-14.home1.cgocable.net)
02.28.06 Quit    mudd1 (Read error: Operation timed out)
02.34.56 Quit    dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.)
02.35.33 Quit    [Saint] (Disconnected by services)
02.35.35 Join    S_a_i_n_t [0] (~st.lasciv@124-197-3-117.callplus.net.nz)
02.36.07 Quit    plux (Quit: qux)
02.49.22 Join    plux [0] (~yogurt@h-34-156.A238.priv.bahnhof.se)
02.51.56 Nick    S_a_i_n_t is now known as [Saint] (~st.lasciv@124-197-3-117.callplus.net.nz)
03.28.47 Join    Keripo [0] (~Keripo@eng100.wireless-resnet.upenn.edu)
03.29.01 Quit    japc (Ping timeout: 260 seconds)
03.29.08 Quit    Keripo (Client Quit)
03.29.37 Join    Keripo [0] (~Keripo@eng100.wireless-resnet.upenn.edu)
03.30.42 Quit    Keripo1 (Ping timeout: 264 seconds)
03.32.45 Join    bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com)
03.32.54 Join    Keripo1 [0] (~Keripo@eng100.wireless-resnet.upenn.edu)
03.33.52 Quit    Keripo (Ping timeout: 241 seconds)
03.36.01 Join    japc [0] (~japc@2.82.172.230)
03.36.58 Quit    tchan (Read error: Connection reset by peer)
03.37.51 Join    tchan [0] (~tchan@lunar-linux/developer/tchan)
03.42.30 Quit    niekie (Quit: No Ping reply in 180 seconds.)
03.43.04 Join    niekie [0] (~niek@CAcert/Assurer/niekie)
04.02.10 Quit    [7] (Disconnected by services)
04.02.17 Join    TheSeven [0] (~TheSeven@rockbox/developer/TheSeven)
04.02.53 Quit    ChickeNES (Quit: Computer has gone to sleep.)
04.03.50 Join    jhMikeS [0] (~jethead71@adsl-99-150-168-211.dsl.sfldmi.sbcglobal.net)
04.03.50 Quit    jhMikeS (Changing host)
04.03.50 Join    jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS)
04.05.31 ***     Saving seen data "./dancer.seen"
04.10.41 Quit    pixelma (Disconnected by services)
04.10.42 Quit    amiconn (Disconnected by services)
04.10.42 Join    amiconn_ [0] (quassel@rockbox/developer/amiconn)
04.10.43 Join    pixelma_ [0] (quassel@rockbox/staff/pixelma)
04.10.45 Nick    pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma)
04.11.00 Nick    amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn)
04.12.13 Join    danszr__ [0] (~dan@ool-457618b0.dyn.optonline.net)
04.12.55 Quit    Judas_PhD (Quit: This is a quitting message)
04.15.24 Join    Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com)
04.23.36 Join    ChickeNES [0] (~ChickeNES@128.135.100.102)
04.26.31 Quit    japc (Quit: Ex-Chat)
04.28.21 Join    kugel_ [0] (~kugel@rockbox/developer/kugel)
04.31.34 Quit    kugel (Ping timeout: 246 seconds)
04.46.32 Quit    wtachi (Quit: &)
04.54.53 Quit    bluefoxx_ (Quit: Can we, should we, will we?)
05.01.14 Quit    CaptainKewl (Read error: Connection reset by peer)
05.06.31 Quit    danszr__ (Ping timeout: 258 seconds)
05.13.19 Quit    ChickeNES (Remote host closed the connection)
05.13.36 Join    Rob2223 [0] (~Miranda@p4FFF32BE.dip.t-dialin.net)
05.17.10 Quit    Rob2222 (Ping timeout: 240 seconds)
05.19.33 Join    bluefoxx [0] (fuzzylomba@S0106485b3917092d.vs.shawcable.net)
05.35.27 Quit    Horscht (Quit: Verlassend)
05.54.21 #       <JdGordon> rasher: how's your java?
05.55.49 #       <JdGordon> http://code.google.com/p/a-simple-lastfm-scrobbler/source/browse/trunk/a_simple_lastfm_scrobbler/src/com/adam/aslfms/receiver/BuiltInMusicAppReceiver.java is probably what we *should* be doing
05.57.12 Quit    Judas_PhD (Ping timeout: 248 seconds)
06.05.32 ***     Saving seen data "./dancer.seen"
06.07.09 Join    slooopy [0] (~sloo@95-90-30-123-dynip.superkabel.de)
06.18.42 Quit    slooopy (Ping timeout: 240 seconds)
06.22.32 Join    JoshuaChang [0] (~JoshuaCha@180.175.4.98)
06.29.39 Join    Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com)
07.01.40 Quit    Scromple (Read error: Connection reset by peer)
07.02.07 Join    Scromple [0] (~Simon@115-64-195-104.tpgi.com.au)
07.09.33 Join    BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey)
07.13.24 Quit    Judas_PhD (Ping timeout: 258 seconds)
07.27.17 Join    Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com)
07.27.35 Quit    Judas_PhD (Client Quit)
07.30.03 Quit    BHSPitMonkey (Ping timeout: 246 seconds)
07.41.00 Quit    jhMikeS (Ping timeout: 276 seconds)
07.41.29 #       <rasher> JdGordon: that seems to rely on the mediastore at a quick glance - a no-go for Rockbox
07.43.14 #       <JdGordon> im not so sure
07.43.38 #       <JdGordon> line 136+
07.44.15 Join    BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey)
07.47.59 Join    Buschel [0] (~chatzilla@p54A3AF5A.dip.t-dialin.net)
08.00.09 Join    mem_ [0] (~mem@mem-irc.netnod.se)
08.04.54 Quit    L-Strife89 (Quit: Leaving)
08.05.33 ***     Saving seen data "./dancer.seen"
08.08.42 Join    DerPapst [0] (~Alexander@nat2-149.fh-giessen.de)
08.20.33 Join    liar [0] (~liar@clnet-p09-185.ikbnet.co.at)
08.21.35 Join    Bagder [0] (~daniel@rockbox/developer/bagder)
08.21.51 Join    mudd1 [0] (~cmertes@ip-78-94-202-227.unitymediagroup.de)
08.25.50 #       <rasher> JdGordon: ah.. in my defense I was reading the code on my phone..
08.26.16 #       <rasher> So we set audioid = -1 and add stuff to the intent.
08.26.26 Quit    Buschel (Quit: ChatZilla 0.9.86.1 [Firefox 3.6.17/20110420140830])
08.26.46 #       <JdGordon> rasher: I guess so.. I dont really know
08.26.54 #       <rasher> Well that's what it looks like :)
08.26.56 #       <JdGordon> that does seem like the most sane way to do it
08.27.37 #       <rasher> This does have the problem that we'd have to keep up with any future (and past!) changes in the native music player, whereas the scrobbledroid api is probably unlikely to change, since it already has what's needed
08.27.46 #       <rasher> But I agree it seems nicer to emulate the native app
08.27.59 #       <rasher> s/native/built-in/
08.28.06 #       <JdGordon> and re-reading the logs, I misunderstood a bit... i agree that our suport shuold probably repsect the rockbox setting
08.30.55 #       <JdGordon> OK, well really the best way would be writing a seperate rbutil app and have a setting in that which listens for rockbox-specific broadcasts, and then in that we can choose which media playeer to emulate
08.30.58 #       <rasher> Just seems wasteful that we'll be writing the logfile still :\
08.31.11 #       <JdGordon> we wouldnt need to
08.31.12 #       <rasher> That seems vastly overkill
08.31.23 #       <rasher> JdGordon: some people seem very attached to the idea of keeping the log
08.31.59 #       <JdGordon> this is a good reason for rbutil
08.32.13 #       <JdGordon> actually no thats stupid, rbutil should just do the scrobbling by itself
08.32.18 #       <JdGordon> or pass off to another app
08.32.25 #       <rasher> Then we're re-inventing the wheel again
08.32.38 #       <JdGordon> yeah, but this time we'll get it right!
08.32.55 #       <rasher> But we already have several perfectly good and circular wheels!
08.41.53 #       <n17ikh> what if my road is like this? http://www.maa.org/mathland/WAGON1.JPG
08.46.18 Join    Zagor [0] (~bjst@46.35.227.87.static.tab.siw.siwnet.net)
08.46.18 Quit    Zagor (Changing host)
08.46.18 Join    Zagor [0] (~bjst@rockbox/developer/Zagor)
08.50.35 Join    ender` [0] (krneki@foo.eternallybored.org)
08.50.40 Join    kevku [0] (~kevku@2001:470:28:773:babe:feed:dead:bee)
08.52.03 Quit    BHSPitMonkey (Remote host closed the connection)
08.52.21 Quit    balintx (Remote host closed the connection)
08.52.36 Join    balintx [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu)
08.58.25 Join    sideral [0] (~sideral@213.165.85.248)
08.58.25 Quit    sideral (Changing host)
08.58.25 Join    sideral [0] (~sideral@rockbox/developer/sideral)
09.04.04 Quit    JoshuaChang (Quit: ChatZilla 0.9.86.1 [Firefox 4.0.2pre/20110429182132])
09.12.25 Join    petur [0] (~petur@rockbox/developer/petur)
09.13.17 Join    einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de)
09.21.00 Join    pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net)
09.21.00 Quit    pamaury (Changing host)
09.21.00 Join    pamaury [0] (~quassel@rockbox/developer/pamaury)
09.25.30 Quit    JesusChrysler (Quit: JesusChrysler)
09.27.37 Quit    Scromple (Quit: Gone)
09.29.25 Join    utanapischti [0] (~username@p4FF2DB89.dip.t-dialin.net)
09.33.26 Quit    sasquatch (Ping timeout: 276 seconds)
09.42.02 Quit    mudd1 (Ping timeout: 252 seconds)
09.52.58 #       <[Saint]> That reminds me...
09.53.04 #       <[Saint]> dionoea, ping?
09.53.37 #       <JdGordon> an hour of silence?
09.53.50 #       <Llorean> dionoea: In the Rockbox Android Widget, for me at least, the Prev/Next buttons don't seem to do anything if I have Skip Length set. I didn't build myself, so I can't test on other builds, and it does have two patches (which I believe should be unrelated)
09.53.56 #       <Llorean> They work like normal in the WPS though.
09.54.12 #       <[Saint]> I'm thinking that the "Small Square" widget could be done a little better also.
09.54.21 #       <[Saint]> I've looked, but the codes a bit foreign to me.
09.54.30 #       <Llorean> I'm only interested in the "Line" widget anyway. :)
09.54.40 #       <Llorean> It fits nicely on the screen with my Pandora and Audible widgets.
09.54.41 #       <[Saint]> IMO, the RB logo should be swapped out with the "while playing" image when there's playback.
09.55.00 #       <Llorean> The RB logo does look a little funny in the Line widget too.
09.55.28 #       <[Saint]> It's ok when the widget isn't playing audio.
09.55.32 #       <Llorean> But pause on headphone resume, unpause on headphone reinsert and "being able to skip back 30 seconds with a single button" are the three things I want it to do.
09.55.46 #       <Llorean> The first has a patch, not sure about the second, the third would be available if not for a bug.
09.55.48 #       <[Saint]> but, it looks funny on anything other than "square" while there's playback IMO
09.56.25 #       <Llorean> [Saint]: I dunno. It feels like there's too much empty space around it for me. It'd be nice if we developed a square-form of our Logo for such uses.
09.56.42 #       <Llorean> It's a narrow rectangle in space clearly meant to be filled by a nearly square object (album art) and looks odd to me.
09.56.50 #       <Llorean> But that's just aesthetics, and not a big deal
09.56.53 #       <[Saint]> I think it looks ok when there's no playback.
09.57.07 #       <[Saint]> But, when there is, the RB logo is too much for "small square"
09.57.19 #       <[Saint]> it should swap for the "now playing" image during playback.
09.57.26 #       <Llorean> I haven't seen it in small square. As I said, only used line.
09.57.28 #       <[Saint]> this keeps it in sync with the wps also
09.57.31 Join    JesusChrysler [0] (~JesusChry@c-69-253-15-232.hsd1.pa.comcast.net)
09.57.54 #       * Llorean also wishes hitting the play button in the widget could start Rockbox even if it's not running, and resume, but that's not as important.
10.00.06 #       <[Saint]> Llorean: it does.
10.00.22 #       <[Saint]> As long as the service is started, it will start.
10.00.47 #       * [Saint] just tested this.
10.00.51 #       <Llorean> I did say "start Rockbox if it's not running" though
10.01.13 #       <[Saint]> well, it's not "running".
10.01.17 #       <[Saint]> but it's *been* started.
10.01.39 #       <Llorean> What's that state, exactly?
10.01.53 #       <Llorean> I mean "start Rockbox when clicking the middle of the widget would show you the boot screen, rather than going directly to the menu".
10.01.58 #       <[Saint]> ie. "start RB, shut down, use play button on the widget, rb starts"
10.02.16 #       <Llorean> Hrm, didn't do that for me earlier. Let me test again.
10.02.58 #       <Llorean> Hmm, seems to work now
10.03.02 #       <Llorean> Maybe it was just being buggy at the time
10.03.05 #       <[Saint]> yay!
10.03.09 #       <Llorean> It's been having the occasional playback bug for me.
10.03.12 #       <Llorean> It would just... stop playing
10.03.17 #       <[Saint]> errr...yay working, not yay buggy.
10.03.20 #       <Llorean> It would say it's playing, but the progress bar wouldn't move any more
10.03.27 #       <[Saint]> yeah, known bug.
10.03.33 #       <[Saint]> Can you build you own .apk?
10.03.37 #       <Llorean> Nope
10.03.42 #       <[Saint]> want one?
10.03.55 #       <Llorean> I wasn't really expecting to use it much yet, so I didn't bother learning how yet. I should
10.04.22 #       <Llorean> [Saint]: What's in it? Right now I've got two of bluebroth3r's patches (one offloads some of the data to the SD card, the other increases the buffer because of skipping on his phone)
10.05.02 #       <[Saint]> Oh, you have those? The second you mentioned there is the main one in my build I was expecting to fix it.
10.05.27 #       <[Saint]> Odd, it cleared up the issues for pixelma, myself, and bluebroth3r
10.05.35 ***     Saving seen data "./dancer.seen"
10.05.38 #       <[Saint]> weird that you're still getting audio-dropouts.
10.05.38 #       <Llorean> I don't get any skipping at all
10.05.46 #       <Llorean> There's no small dropouts or anything
10.06.01 #       <Llorean> It just stops and stays stopped until I trigger an actual Stop/Resume.
10.06.03 #       <[Saint]> No, but big "I'm just not going to play, anything" dropouts?
10.06.09 #       <Llorean> Seeking or pausing/unpausing do nothing
10.06.18 #       <Llorean> Yes, big "I'm done playing now" dropouts
10.06.20 #       <[Saint]> Yeah, that's what I was experiencing too.
10.06.29 #       <[Saint]> bluebroth3r's patch fixed that up for me.
10.06.35 #       <Llorean> Hrm
10.06.37 #       <[Saint]> perhaps you need *more* buffer still?
10.06.57 #       <Llorean> I dunno, I thought it was more about buffer underruns and "skips" in the audio.
10.07.01 #       * Llorean maybe misunderstood
10.07.27 #       <[Saint]> I've looked at the code, but I can't quite follow what's really happening.
10.07.46 #       <Llorean> I've got tons of RAM free, and nothing really going on that I'd expect to interfere with playback. It's an extremely low bitrate MP3, so I'd be rather surprised.
10.07.48 #       <[Saint]> I can see what the patch does, but the mechanism is insane (to me :))
10.07.56 Quit    kevku (Quit: KVIrc 4.0.4 Insomnia http://www.kvirc.net/)
10.08.15 #       * Llorean shrugs.
10.08.39 #       <Llorean> Do you remember the patch number?
10.08.50 #       <[Saint]> You're not running a task killer or any sillyness like that?
10.08.55 #       <[Saint]> (have to ask, some do)
10.08.58 #       * JdGordon wants headphone detection in raaaoa in svn
10.09.10 Nick    kugel_ is now known as kugelp (~kugel@rockbox/developer/kugel)
10.09.15 #       <Llorean> [Saint]: Nothing.
10.09.18 #       <[Saint]> JdGordon: Yeah, I was going to ask Llorean where he found that patch. ;)
10.09.30 #       <[Saint]> but I got sidetracked re: audio-dropouts.
10.09.30 #       <Llorean> JdGordon: Does our headphone detection support "resume on insert" or not? I've never really used it.
10.09.36 #       <JdGordon> yes
10.09.42 #       <Llorean> [Saint]: It's on the tracker. Bluebrother put it up there yesterday.
10.09.53 #       <[Saint]> Ah, explains why I haven't seen it yet.
10.09.55 #       <[Saint]> thanks.
10.09.56 #       <Llorean> The only problem he mentions is that it's a little delayed, since detection is slow on Android.
10.10.10 #       <[Saint]> that's cool.
10.10.13 #       <Llorean> Which should be fixable - I have other apps that do it without any 'leaked' audio through the speakers
10.10.24 #       <[Saint]> better than blasting myself with my incredibly loud internal speaker ;D
10.10.43 #       <JdGordon> also in the build im using the lock screen controls dont control rockbox
10.10.44 Join    efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net)
10.10.45 #       <Llorean> With headphone detection and a working "skip back 30 seconds" button on the widget, I'll be set.
10.10.55 #       <Llorean> JdGordon: Lock screen controls?
10.11.10 #       <[Saint]> JdGordon: Like, the "cancel" button?
10.11.45 #       <[Saint]> that seems...weird. but, maybe useful.
10.11.52 #       <JdGordon> the pause button starts the stock media player
10.12.25 #       <[Saint]> "lock screen controls"?
10.12.33 #       <[Saint]> ...now I'm confused.
10.12.53 #       <[Saint]> I can't control media while the screen is locked.
10.12.56 #       <Llorean> Ah, some ROMs seem to have a lock screen with music controls
10.13.10 #       <[Saint]> Hmmm, good idea.
10.13.23 #       <Llorean> Or even display some of your widgets on it
10.13.33 #       <kugelp> [Saint], Llorean:  I'm seeing no rockbox logo but album art :-)
10.13.48 #       <[Saint]> kugelp: stop playback
10.14.00 #       <Llorean> kugelp: Album Art is fine. I just wish we had a more album art shaped Rockbox logo for use there. :)
10.14.50 #       <[Saint]> for "small square" the logo is displayed when there's no playback, and dissappears when there is, but there's enough room to put the "now playing" image, and IMO it looks weird without it.
10.15.31 #       <kugelp> [Saint]: I know the logo. you said it should change while playing, it changes to album art for me :-)
10.16.07 #       <[Saint]> Yeah, seems I was getting confused between small/big square.
10.17.09 #       <[Saint]> and I forgot what actually annoyed me it seems. Now I have my phone in front of me it's clear. in "Square" the "now playing" image is always displayed.
10.17.21 #       <[Saint]> whether there's playback or not.
10.18.20 #       <[Saint]> Also, the default sizes of the widgets are weird.
10.19.01 #       <[Saint]> for "Square" on 240x320, there's *no* point in having the widget smaller than 4x4 (fullscreen) or the text gets cut off while playing.
10.19.39 #       <[Saint]> yet the default creation size is 3x3
10.19.51 #       <[Saint]> *"big square" rather
10.20.32 #       <Llorean> [Saint]: 3x3 contains plenty of space on a higher resolution target.
10.20.34 #       <[Saint]> "square" is the same.
10.20.37 #       <Llorean> Which is probably more common.
10.20.43 #       <Llorean> It might be nice if there was a 4x4 option by default
10.20.50 #       <[Saint]> Default creation size is 2x2, which is again far too small to fit everything.
10.20.58 #       * Llorean doesn't like "square", "line", "small square" and prefers "4x1", "2x2", etc
10.21.50 #       <Llorean> [Saint]: It seems the widgets are definitely oriented around 480x800 screens. I'm not seeing that problem, and I've got a very long track name.
10.22.04 #       <[Saint]> Yeah, I'm pretty sure the widgets weren't tested very thoroughly on "small" screens
10.22.16 #       <[Saint]> 240x320, 320x480
10.23.04 #       <[Saint]> for "big square", if I leave the defaults, I get half a line of text for metadata
10.24.09 #       <kugelp> adding a 4x4 widget should be easy
10.24.26 #       <kugelp> huge square :-)
10.24.45 #       <[Saint]> we don't need a million widgets. But, can we check the screen size and use a sane default for the layout?
10.25.01 #       <Llorean> [Saint]: Sounds like it mainly just needs better font size selection?
10.25.09 #       <[Saint]> I mean, for 240x320, the defaults are useless for everything but "line"
10.25.18 #       <Llorean> Based on the DPI of the screen rather than absolute size, perhaps.
10.25.33 #       <[Saint]> Llorean: Nah, if the font did fit...it couldn;t possibly be read by the human eye ;)
10.26.02 #       <Llorean> [Saint]: If that's true, then 2x2 and 3x3 are both pointless anyway on those targets, right?
10.26.12 #       <[Saint]> Yep.
10.26.26 #       <Llorean> Should we really offer different sized widgets for different screens?
10.26.45 #       <[Saint]> No, I just think we should offer sane defaults based on screen size.
10.27.03 #       <Llorean> I'm confused.
10.27.12 #       <Llorean> You said 2x2 and 3x3 are pointless.
10.27.19 #       <[Saint]> same widgets, but with variable creation time size defaults.
10.27.22 #       <Llorean> I don't get options for the size, "large square" is always 3x3
10.27.39 #       <Llorean> If it's 4x4 it's not the same widget, is it?
10.27.39 #       <[Saint]> really? odd.
10.27.47 #       <[Saint]> yes.
10.27.55 #       <[Saint]> you can resize any widget to any size.
10.28.04 #       <[Saint]> well...*I* can.
10.28.08 #       <Llorean> And that's not some app you've got doing that?
10.28.12 #       <[Saint]> if you can't, that's..odd.
10.28.19 Join    n1s [0] (~quassel@rockbox/developer/n1s)
10.28.31 #       <[Saint]> I had assumed it was a part of the widget creation.
10.28.49 #       <Llorean> When I create the Rockbox widget, it asks me if I want cover art, prev, stop, play/pause, and next buttons. That's it.
10.28.57 #       <[Saint]> perhaps it's my launcher doing this.
10.29.12 #       <[Saint]> Hmmm.
10.29.13 #       <Llorean> That'd be my guess.
10.29.24 #       <Llorean> What would be the point in having a 2x2 and a 3x3 if you could just resize the box to any size at creation?
10.29.27 #       <Llorean> We'd instead just do that.
10.30.10 #       <[Saint]> Perhaps we *should* be doing that.
10.30.26 #       <[Saint]> I probably wouldn't use the widgets if I couldn;t resize them.
10.30.32 #       <[Saint]> apparently it's possible to do so.
10.30.50 #       <[Saint]> I just didn't think it was my launcher doing it, but it seems so.
10.31.04 #       <[Saint]> s/it/the resizing/
10.31.29 #       <Llorean> We should probably drop the 3x3 for a 4x4
10.31.36 #       <Llorean> Which would meet your needs, and 3x3 is a really odd size anyway
10.33.24 #       <[Saint]> that still leaves "smal square"
10.33.37 #       <Llorean> Small square is fine on higher res targets
10.33.38 #       <[Saint]> which defaults to 2x2 on my device, and is unusable like that.
10.33.44 #       <Llorean> We'd have 2x2, 4x1, and 4x4
10.33.55 #       <[Saint]> 2x2 is pointless on thses screens
10.33.59 #       <Llorean> People with your device would likely choose 4x4, while people on mine might choose 2x2 if they're short on space.
10.34.08 #       <Llorean> [Saint]: And 4x4 is a huge waste of space on screens like mine.
10.34.41 #       <[Saint]> Yeah, so we really need a way to offer either configuration at creation time, or offer sane defaults based on screen dimension.
10.34.59 #       <Llorean> 2x2 and 4x4 *would* be sane defaults.
10.35.04 #       <[Saint]> configuration at creation time would be awesome.
10.35.20 #       <[Saint]> Um...no.
10.35.31 #       <[Saint]> unless you're talking about dropping a widget.
10.35.35 #       <Llorean> According to you, your screen the only sane default for a box is 4x4
10.35.45 #       <Llorean> There's very little difference between small box and large box other than their size
10.35.50 #       <[Saint]> for "small square" the default is 2x2 on my phone. this is unusable.
10.35.51 #       <Llorean> If they're both 4x4, one's not small any more is it?
10.36.07 #       <Llorean> You're talking about having two different 4x4 widgets.
10.36.13 #       <Llorean> For targets with your screen resolution
10.36.28 #       <Llorean> This isn't "sane defaults". Some people just want a play/pause button and don't even care about the track title
10.36.33 #       <Llorean> 2x2 should manage that fine even on your device.
10.36.58 #       <[Saint]> Yes, but half of AA and 3px of metadata look awful.
10.37.05 #       <Llorean> So turn off AA
10.37.07 #       <Llorean> It's an option.
10.37.18 #       <Llorean> Don't use the small box if you want AA on a tiny screen.
10.37.36 Join    komputes [0] (~komputes@ubuntu/member/komputes)
10.37.54 #       <Llorean> Stretching small box to fullscreen just to show AA rather defeats the purpose of offering a small widget that doesn't take up much space. Let people use them as intended - small for minimalist controls, large for more information.
10.37.55 #       <[Saint]> It seems as though small square probably shouldn;t even be an option on this screen size.
10.38.13 #       <[Saint]> It's only usable because I can resize it with the launcher at creation time.
10.38.31 #       <Llorean> [Saint]: You're too obsessed with AA. Using it for a play/pause button without having to go back to the app would work, wouldn't it?
10.39.03 #       <Llorean> Turn off everything but the Play/Pause button.
10.39.58 #       <[Saint]> Yeah, actually, that's pretty much the only way it's usable.
10.40.04 #       <Llorean> That's pretty much what it should be for.
10.40.26 #       <Llorean> We shouldn't take away the option for someone to have a widget that only takes up a couple spots, just because it can't show AA.
10.40.29 #       <[Saint]> Hmmm, I wonder if we could default cover art etc off for the small square then.
10.40.32 #       <[Saint]> that's a start.
10.40.36 #       <Llorean> Probably should
10.40.40 #       <Llorean> They seem to all default to the same options.
10.41.35 #       <Llorean> I think small box should stay 2x2, large box should go up to 4x4 (as 3x3 seems senseless to me - it sacrifices most of the rest of your space for anything but icons or a line anyway) and line should stay the same (size-wise)
10.42.34 #       <[Saint]> Yep, I agree. With the exception (as mention earlier) that small square should default cover art and (maybe?) prev/next off also.
10.44.07 #       <Llorean> Yeah
10.44.32 #       <Llorean> Personally, I'd default to offering the "Play/Pause" and "Prev" buttons, but I use it for audiobooks and have "Prev" set to "skip back 30 seconds"
10.44.39 #       <Llorean> A button Audible offers and comes in very handy
10.44.40 #       <[Saint]> and "big square" needs to not display "now playing" *all the time* ;)
10.46.19 #       <[Saint]> hah...during this conversation I ended up with 14 RaaA widgets on 7 homescreens... ;)
10.53.13 #       <[Saint]> Llorean: Just looked at the pause on unplug tracker task, made a comment there but figured I can talk to you here with more ease. I think it's possible (if the delay is indeed unavoidable between detecting unplug and pausing) that the application you're talking about is muting playback when it catches the unplug event.
10.53.33 #       <[Saint]> And, if so, we should probably do the same to avoid the "bleeding" through the internal speaker.
10.53.36 #       <Llorean> [Saint]: I thought the delay was between unplug and detection of unplug
10.53.43 #       <Llorean> I can't imagine a delay in *pausing* would be the unavoidable part.
10.54.03 #       <Llorean> Since we can obviously pause nearly instantly on button press.
10.54.16 #       <[Saint]> Oh, ah...yes. It seems I read it incorrectly.
10.54.37 #       <[Saint]> He states "this is an Android limitation"..I wonder how the app you're talking of gets around it.
10.55.02 #       <Llorean> I can imagine a delay in detection of the unplug happening, but I imagine Android is still playing back through the headphone port during this delay, so nothing 'leaks' through the speaker (though we may lose a fraction of a second of audio)
10.55.14 #       <Llorean> So you don't 'see' the delay
10.55.21 #       <Llorean> Possibly followed by a slight rewind to make up for the delay
10.56.50 #       <n1s> the delay is after rockbox detects the unplug but before it sends the event, to debounce on glitchy  jacks it double checks, while i *guess* that the redirection to speaker is something android does
10.57.06 #       <Llorean> n1s: Do we need to debounce on android, or can we depend on the OS to do it?
10.57.17 #       <Llorean> I don't see the icon on the status bar flickering during plugs, so I'm guessing they might
10.57.19 #       <n1s> no idea
10.58.18 #       * Llorean suggests we should try it without debouncing first.
11.12.50 Join    wodz|work [0] (~5f303f8a@giant.haxx.se)
11.15.44 Join    smk [0] (~smk@115.113.152.3)
11.16.31 #       <wodz|work> Do we have error codes comming from storage layer standarized? (aka error codes from sd_read_sectors()/sd_write_sectors() )
11.17.15 Quit    wodz|work (Client Quit)
11.17.25 Quit    [Saint] (Quit: I'm only going to Heaven if it feels like Hell, I'm only going to Heaven if it tastes like caramel...)
11.17.50 #       <smk> hi. anyone here who can help me with aac/libfaad?. was working on the libfaad task in Mr.SomeOne's list
11.18.18 #       <smk> have some questions.
11.19.21 #       <n1s> smk: just ask
11.19.21 Join    wodz|work [0] (~5f303f8a@giant.haxx.se)
11.20.09 Quit    komputes (Read error: Operation timed out)
11.20.10 Join    [Saint] [0] (~St.]@124-197-3-117.callplus.net.nz)
11.20.47 #       <smk> ok. i put debug info in faad_malloc where malloc is being called. and played m4a songs in the sim. for every song played, 3 calls to malloc are made. i traced these calls and replaced them with static allocations. it's working properly. what should i do now?
11.22.01 #       <smk> and also, there are places in code where faad_malloc is called,. but these aren't run when i play the m4a songs. i only considered on scenario where faad_malloc could be called. that is, playing a song.. :P
11.22.11 #       <smk> *one scenario
11.23.35 #       <pamaury> wodz|work: I don't think there are standard error codes
11.23.57 #       <smk> so, when i play the aac songs now, no calls to malloc are made...hmm is that the task? or should i be taking care of something else?
11.24.49 Quit    DerPapst (Quit: Leaving.)
11.26.12 #       <wodz|work> pamaury: maybe we should agree on some standard errors?
11.27.08 #       <pamaury> I don't know, would it be useful ?
11.28.25 #       <[Saint]> smk: Nice work, by the way.
11.28.29 #       <[Saint]> Congratulations.
11.28.43 #       <wodz|work> pamury: now you have to dig through the code to understand what error -11; in bootloader means :-)
11.29.15 #       <wodz|work> with standard error codes we can map this to error messages
11.29.46 #       <smk> thanks :). but as i said, some parts of the code still have calls to malloc, but i didn't care to replace them , as they didn't actually make the calls when the audio was run. what should i do next?
11.30.47 #       <pamaury> that's true, but that would mean going through a lot of code and also possibly introduce some more strings to translate about errors. But I agree this would be easier for debugging
11.30.52 #       <[Saint]> I would maybe investigate when those calls to malloc *are* made?
11.31.04 #       <[Saint]> smk: ^
11.31.15 Quit    markun (Ping timeout: 240 seconds)
11.31.41 #       <wodz|work> pamaury: I don't think we need to translate low level errors
11.32.39 Join    markun [0] (~markun@ip503cd9a5.speed.planet.nl)
11.32.40 Quit    markun (Changing host)
11.32.40 Join    markun [0] (~markun@rockbox/developer/markun)
11.32.51 Quit    efyx (Read error: Operation timed out)
11.33.53 #       <pamaury> I guess that (perhaps after some discussion) we could introduce standard error code, starting at -100 so that standard code don't interfere with ad hoc ones and slowly begin to use them
11.34.33 Join    efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net)
11.36.32 #       <wodz|work> pamury: yeh, coexisting new codes with old ones is a must. No one will fix all at once
11.38.27 #       <n1s> smk: there are different kinds of aac files that use different features of the codec, maybe all your files are the same profile? Also how did you decide on the size for those static allocations? and you should probably talk to Buschel, since he did some work on that codec not long ago
11.41.43 #       <smk> [Saint]: yeah, i found where the calls are coming from, found out how much memory is each such call asking for. and replaced them with static alloc.
11.43.04 #       <[Saint]> as n1s just mentioned, there are different types of AAC files, have you thrown all test cases at it?I'd recomend using the files from test_files
11.43.22 #       <smk> n1s: yes, i have considered only one test case. there would be others. some of the replacements were straight-forward. where a pointer to a struct is malloc'd , i replace it with struct itself and also replace the used areas.. as in structPointer -> abc becomes struct.abc
11.44.18 #       <n1s> ah, ok so they were already statically sized
11.44.33 #       <smk> yeah.
11.44.38 #       <[Saint]> smk: for other instances of AAC files, you might make use of http://download.rockbox.org/test_files/
11.45.24 #       <[Saint]> I'm not actually certain there are any in there though.
11.45.30 #       <[Saint]> been a while since I looked.
11.46.02 #       <n1s> the nero* files are aac, definitely try the he files
11.46.15 #       <smk> [Saint]: will sift through them. yeah there are some m4a files here, will need to check the other formats though.
11.46.50 #       <n1s> and it's possible that the different bitrates use different features so try perhaps 96 and 400 kbps
11.47.35 #       <n1s> we don't seem to have any raac files
11.47.56 #       <smk> oh yeah, raac also will use faad.
11.48.05 #       <[Saint]> rockbox as a codec? ;)
11.51.08 Join    robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com)
11.57.11 Join    Buschel [0] (~c2795aa3@giant.haxx.se)
11.58.08 #       <pamaury> wodz|work: do you a room in a hotel or something for devcon ? when do you leave ?
11.59.22 #       <Buschel> smk: please check FS#8923 and r29778. I made several changes to libfaad in the past weeks to get rid of malloc. if you enable FAAD_STATIC_ALLOC there will be only 3 mallocs left. those are called from libm4a/demux.c and will *heavily* differ from file to file (see FS#8923)
11.59.36 #       <Buschel> smk: allocation go up to 540 KB for a single song
12.00.54 #       <Buschel> smk it would be technically easy to remove malloc, but imho we will then have to use a large static buffer and use a libfaad-internal malloc-implementation to efficiently use it. 
12.01.38 #       <Buschel> smk: it is not reasonable to use static buffers for each single malloc that is used
12.03.30 #       <Buschel> smk: it is even reasonable to not define FAAD_STATIC_ALLOC (svn does also not define it) to not waste RAM with static buffers which are not used (e.g. when playing AAC-LC files)
12.04.10 Quit    Elfish (Ping timeout: 260 seconds)
12.04.12 Quit    n1s (Remote host closed the connection)
12.04.25 Join    bzed_ [0] (~bzed@devel.recluse.de)
12.05.39 ***     Saving seen data "./dancer.seen"
12.05.55 Quit    boghog (Ping timeout: 260 seconds)
12.05.56 Quit    bzed (Ping timeout: 260 seconds)
12.06.00 #       <smk> Buschel: right. what other approach then?
12.06.00 Nick    bzed_ is now known as bzed (~bzed@devel.recluse.de)
12.06.08 Join    Elfish [0] (amba@2a01:4f8:100:90a1:abc:abc:abc:abc)
12.06.20 Join    boghog [0] (~aphax@2001:980:34c7:0:1e6f:65ff:fe86:1e03)
12.08.49 #       <Buschel> smk: create a large static buffer, write libfaad-specific malloc (can be easily derived from the current one) and use it :) the size of the static buffer can then be of different size for different targets
12.09.09 #       <Buschel> smk: I do not see any other elegant possibility
12.11.36 #       <smk> Buschel: the size of the buffer would then be a worst-case size. we might not use the whole or most part of the buffer for most of the time.
12.12.54 #       <Buschel> smk: there is no worst case. the memory requirements of demux.c will mostly scale with both the type of m4a-structure used and the length of the file (number of frames).
12.13.18 #       <Buschel> smk: as I wrote -> 540 KB for ~2h duration m4a
12.13.40 #       <Buschel> smk: but might also be 170 KB for 2h... depends on the file...
12.14.09 #       <smk> Buschel: didn't think of a 2h duration file :)
12.14.14 #       <wodz|work> pamury: I didn't booked hotel yet. I have return flight 05 june 17:50
12.14.34 #       <Buschel> smk: but we must be able to play those
12.14.51 #       <smk> ok.
12.15.20 #       <Buschel> smk: we should not loose playability through any changes
12.15.38 Join    DerPapst [0] (~Alexander@p57916EC7.dip.t-dialin.net)
12.16.06 #       <Buschel> smk: btw, did you see r29778? from your posts today I got the impression you worked a similar approach on older code of rockbox?
12.17.33 #       <Buschel> smk: for large files you might take a look inot FS#8923. there are links to some very long files
12.17.39 #       <Buschel> *into
12.17.50 #       <smk> Buschel: i had started earlier. then xams came. resuming now... m still using the old code though :P. 
12.18.52 #       <Buschel> smk: you should sync to the current one. It has changed a lot regarding malloc and static buffer usage.
12.19.33 #       <Buschel> smk: ok, gotta go now. see you later!
12.19.37 Quit    Buschel (Quit: CGI:IRC)
12.19.57 #       <smk> Buschel : sure. thanks :). Will update.
12.40.17 #       <[Saint]> pixelma: froggyman: Llorean: (possibly?)  - http://www.datafilehost.com/download-16d6fabb.html 
12.40.19 #       <[Saint]> "current svn head with: antialiased fontset, large iconset (480x800 build only), "eye-candy" Rockbox logo (app and widgets), resources on uSD, fix audio dropouts, headphone detection, meier crossfeed, adjustable inter-ear delay, shutdown in main menu, icon/list spacing, quickscreen timeout"
12.41.44 #       <[Saint]> 320x480 build lacks my custom theme, but a: it has a few quirks, and b: cabbieV2 is still the default for the build anyway.
12.42.07 Part    smk ("Leaving")
12.42.22 #       <[Saint]> (it's quite usable, though, it's me default theme...but, I'm biased as I built it)
12.42.31 #       <[Saint]> *s/me/my/
12.44.27 #       <[Saint]> ps-auxw: sorry about the ~15MB download, it was easier to package them all together.
12.44.59 #       <[Saint]> damn nick completion, sorrp ps-auxw, 'twas supposed to be "PS:"
12.53.29 Join    jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS)
12.54.57 Join    DerPapst1 [0] (~Alexander@p57954323.dip.t-dialin.net)
12.57.31 Quit    DerPapst (Ping timeout: 276 seconds)
12.57.56 #       <kugelp> how is meier crossfeed?
12.58.21 Join    ibhan [0] (~user@195.41.77.232)
12.58.48 #       <[Saint]> It's nice, but I personally prefer using the adjustable inter-ear delay.
12.59.59 #       <kugelp> why aren't those in svn? bertrik put them up didn't he?
13.00.18 #       <[Saint]> Yes, he did. And I'm not sure why to be honest.
13.00.54 #       <[Saint]> The two patches work together very nicely if you want to use the meier crossfeed or continue to use the rb one with adjustable delay.
13.02.05 #       <kugelp> I'll justgive your build a try :-) 
13.10.24 Quit    boghog (Quit: boghog)
13.11.55 #       <kugelp> Llorean: 3x3 is my favorite widget
13.17.04 #       <Llorean> kugelp: I guess it just seems a strange size to me. It leaves too little room for most other widgets, and to me seems it may as well be 4x4. But we could just offer 2x2, 3x3, and 4x4 anyway
13.18.32 #       <Torne> Llorean: i dunno, almost all of my "widgets" are just shortcut icons, so 3x3 leaves room for seven of them :)
13.18.40 #       * [Saint] just discovered that depends vastly on ones desktop setup
13.19.05 #       <Torne> and most of the remainder are 4x1 so there's room for one of those also
13.19.24 #       <[Saint]> I mean, I can set the desktop colums to 8, so 3x3 is nothing.
13.20.19 #       <[Saint]> is the default desktop colums always 4?
13.21.09 #       <Llorean> [Saint]: Default desktop is 4x4
13.21.20 #       <Llorean> If you're 8x8 I can easily see why you might have difficulty seeing things on a 3x3
13.21.39 #       <Llorean> Especially on a 240x320 screen. Jeeze.
13.21.40 #       <[Saint]> Oh, no...I just discovered I could change that now.
13.22.03 #       <[Saint]> when I was playing earlier it was 4X4
13.22.17 #       <kugelp> [Saint]: you obviously have a non-standard homescreen setup
13.22.36 #       <Llorean> Torne: I seem to use a lot of 4x1 and a few 4x2 widgets.
13.22.51 #       <Torne> Llorean: right. so 3x3 is not entirely useless..
13.23.00 #       <Torne> 4x1, 3x3, and three icons
13.23.03 #       <Llorean> Yeah
13.23.09 Quit    user890104 (Read error: Connection reset by peer)
13.23.15 #       <Llorean> I don't mean to say totally useless, it just seems like an odd (pardon the pun) size
13.23.19 #       <Torne> heh :)
13.23.23 #       <Llorean> The 2x2 fits just as much information on my screen
13.23.28 #       <kugelp> normally you are limited to 4x4 and can't reside widgets, but I know many launcher don't have this limitation
13.23.30 #       <Torne> i've not actualyl used rockbox on android yet
13.23.34 #       <Torne> so.. yeah
13.23.35 #       <Llorean> So the 3x3 feels like it's just wasting space to waste space more than anything
13.23.45 #       <Torne> i have no idea if it's reasonable from the POV of what is actually displayed
13.23.51 #       <[Saint]> kugelp: yes, custom launcher.
13.23.54 #       <Torne> Llorean: maybe people with really long song titles :)
13.24.08 #       <Llorean> I feel like if we're going to only offer three widgets (something I don't actually care about, 4 or more is fine by me) 2x2 and 4x4 is better than 2x2 and 3x3
13.24.09 #       <[Saint]> I actually thought that RaaA was doing the widget resizing initially, not my launcher.
13.24.15 #       <[Saint]> as I never use any other widgets.
13.24.16 #       <kugelp> resize*
13.25.44 #       <kugelp> and yea, the layout of our widgets are not prepared for being resized
13.26.07 #       <kugelp> Llorean: no reason we couldn't offermore widget sizes
13.26.08 #       <[Saint]> it's quite fun to be able to stretch and resize widgets...I was a little dissappointed when I found out it was the launcher handling this.
13.26.19 #       <[Saint]> I assumed it was some awesome feature RaaA had ;)
13.26.36 #       <Llorean> kugelp: Yeah, I don't see why we shouldn't. Someone just said they didn't think we did, and my response was "well if we limit ourselves to three, I think 2x2, 4x4 and 4x1 is better than 2x2, 3x3, and 4x1"
13.27.25 #       <[Saint]> Instead of having ten million widgets in the list though...could there be one RaaA widget, which you then select the setup of?
13.27.45 #       <[Saint]> that would seen a lot nicer to me personally.
13.27.48 #       <kugelp> well, opinions :-) imo the 2x2 one would be the one to drop :-)
13.28.02 #       <[Saint]> As opposed to having 5 or 6 different rockbox widgets listed.
13.28.22 #       <kugelp> [Saint]: I don't think that's possible
13.28.28 #       <[Saint]> Awww :/
13.28.31 #       <[Saint]> Oh well.
13.29.34 #       <Torne> you can have options that change what is dispalyed *in* the widget, but the widget's size is fixed, yes
13.30.03 #       <Torne> the option popup, if present, is entirely the widget provider's business, the launcher is not involved in processing it
13.30.13 #       <[Saint]> kugelp: The widgets actually handle being resized quite well, just not *very* well ;)
13.30.44 #       <[Saint]> the logo and the icons resize decently, but AA, metadata placement is screwed up if you go too small.
13.32.10 #       <[Saint]> Torne: Well, after RaaA pops up it's config options, immediately after pressing "create" my launcher shows me another popup to choose the displayed size.
13.32.22 #       <[Saint]> It took me a while to figure out it was the launcher doing that.
13.32.38 #       <[Saint]> I assumed it was part of the widget setup.
13.32.45 #       <Torne> [Saint]: I *think* that's a dramatic abuse of APIs and will break lots of widgets or make them display oddly
13.32.57 #       <Torne> because the widget interface is pretty much not designed for that :)
13.33.09 #       <Torne> so relying on that is not a sensible idea :)
13.33.18 #       <Torne> and trying to support it explicitly is going to run into limitations
13.33.33 #       <[Saint]> works fine. It's so it can handle resizing the widgets for different homescreen orientations.
13.33.57 #       <[Saint]> though I realise it's "non-standard" (now)
13.34.44 #       <Llorean> We could just make a 1x1, 2x1 and 2x2 allowing the 2x1 and 2x1 to only contain track names or album art (for the 2x2) , and the 1x1 to contain any of the single buttons we already offer, then just let the user figure out how they want to distribute them on the screen. :-P
13.35.04 #       <[Saint]> 1x1?
13.35.17 #       <[Saint]> "touch to launch rockbox"? ;)
13.35.21 #       <Llorean> I'm guessing you didn't read all the way through before saying that?
13.35.26 #       <[Saint]> like....an *icon*? ;P
13.35.30 #       <Torne> [Saint]: I have a 1x1 widget for my podcast player, works fine
13.35.36 #       <Llorean> I was in part joking
13.35.42 #       <Torne> it's a play-pause button with a progress bar
13.35.49 #       <kugelp> why should we explicitly limit the options what to display?
13.35.50 #       <Torne> if you hit play when nothing's queued it creates a playlist automatically
13.35.54 #       <Torne> Works perfectly
13.35.57 #       <Llorean> But you could make the play/pause button a 1x1, the stop a 1x1, each skip a 1x1, and the user can then fit them on their screen how they like. :-P
13.35.57 #       <Torne> I never launch the app ;)
13.36.22 #       <Llorean> Torne: Mainly I use a Play/Pause button and a "rewind 30 seconds" button for audiobooks/podcasts.
13.36.23 #       <[Saint]> kugelp: Because for some sizes of widget, all the options don't fit.
13.36.32 #       <[Saint]> or don't fit properly.
13.37.04 #       <Llorean> Torne: Audible offered me the "skip back 30" button and I found myself using it more than I expected.
13.37.32 #       <kugelp> Llorean: don't we have "rewind bit" after unpause in by now?
13.37.47 #       <Llorean> kugelp: I believe we do, but that's not what I use it for.
13.38.07 #       <Llorean> If I'm listening, and some noise distracts me, or I find my thought wandering, it's easy to skip back a short amount to re-listen.
13.38.22 #       <Llorean> Especially since you can't click-and-hold in a widget.
13.38.41 #       <Llorean> Rockbox already lets you skip back 30 seconds with "skip length" except that seems currently broken on the widget, so I still need to be in the WPS to do it.
13.38.55 #       <Llorean> It's also especially helpful since seeking in Rockbox on Android in very long tracks is hardly ideal at the moment. Not fine enough.
13.39.03 #       <kugelp> you can toggle playback quickly and don't mess with the skip length setting I guess
13.39.27 #       <Llorean> kugelp: Pausing and unpausing 6 or more times rather than just pressing one button is kinda annoying.
13.39.57 #       <Llorean> I don't want my rewind-on-unpause particularly long for the times I pause intentionally. I usually have it set to only about 2 seconds.
13.40.20 #       <kugelp> speaking of seeking, the ffwd/rew touchregions don't work properly in cabbie, did something change?
13.40.31 #       <Llorean> But it's 5 on Rockbox due to limitations
13.40.40 #       <[Saint]> Llorean: seek isn't fine enough? Can't you adjust the minimum seek step to like 1 second or something?
13.41.13 #       <[Saint]> how fine do you need it?
13.41.19 #       <Llorean> [Saint]: Mine's set to 1s, but if the track is 5 hours long, 480 pixels being addressed with a finger doesn't give you nearly that fine of control
13.41.32 #       <[Saint]> that's the themes fault.
13.41.37 #       <[Saint]> not RaaAs
13.41.51 #       <[Saint]> seeking with the playbar is just...silly
13.41.54 #       <Llorean> Nah
13.41.56 #       <[Saint]> if you want a fine grain.
13.41.59 #       <Llorean> Try other apps, they have a much better way to do it.
13.42.19 #       <Llorean> Put your finger on the bar, then move it up/down away from the bar, and you get half/sized steps, move it further you get quarter/sized steps
13.42.27 #       <[Saint]> I have, and for fine grained seeking...using a bar is just useless IMO
13.42.29 #       <Llorean> So you can get very fine seeking but with finger-style controls
13.42.39 #       <Llorean> [Saint]: You haven't used the right ones then.
13.42.42 #       * [Saint] shrugs
13.43.04 #       <Llorean> I can seek to where I want in a good app much faster than I can with Rockbox's "press-and-hold-and-wait" seeking.
13.43.16 #       <kugelp> this style of progress bar OS unknown to me too
13.43.18 #       <[Saint]> I know RaaA's seeking with the playbar is crap...but I'd never personally use it and expect to have a very fine grain personally.
13.43.19 #       <Llorean> Tap where you want on the bar, then move away from the bar and 'nudge' with your finger to narrow it down.
13.43.22 #       <kugelp> is*
13.43.29 #       <Llorean> kugelp: It's common on the iPhone, but it's also on a few android apps.
13.43.31 #       <[Saint]> I use it for skipping large periods.
13.43.44 #       <[Saint]> and I use actual ffwd/rew buttons for fine seeking.
13.43.52 #       <Llorean> kugelp: I'd suggest trying Audible to see it, but I don't know about availability and you'd need content.
13.44.20 #       <kugelp> it sounds nice indeed
13.44.45 #       <kugelp> [Saint]: do you know more about the touchregion issue?
13.44.56 #       * Llorean doesn't care too much about seeking though.
13.45.01 #       <[Saint]> Oh? kinda similar to drilling down alphabetically in the contacts list?
13.45.11 #       * Llorean just wants the buttons on the widget to work right, and no more crashes.
13.45.12 #       <[Saint]> kugelp: Which issue is this?
13.45.25 #       <kugelp> I wrote it a few lines up
13.46.10 #       <Llorean> [Saint]: Imagine if moving your bar 40 pixels right on the progress bar moved you forward 4 minutes. If you moved your finger directly up/down from the bar and *then* 40 pixels over, it'd seek 2 minutes instead. Further away and you'd get 1 minute. Etc.
13.46.24 #       <Llorean> Basically, you're "scaling" the amount seeked based on your distance from the bar.
13.46.46 #       <[Saint]> kugelp:  Ah, yep. Something changed. * now means "Hold, and repeat the action" and & means "hold, and do one action only"
13.46.54 #       <[Saint]> pixelma got hit by that too.
13.47.01 #       <[Saint]> Seems a lot of people missed the commit.
13.47.31 #       <kugelp> [Saint]: well that sucks. why break themes this way?
13.47.42 #       <[Saint]> because it was needed.
13.47.54 #       <kugelp> and even without fixing default themes in SBM?
13.47.54 #       <[Saint]> otherwise "mute" was impossible to use on a hold action.
13.48.01 #       <[Saint]> it fired on/off at the repeat rate.
13.48.22 #       <kugelp> swap * and &, then nothing breaks?
13.48.29 #       <[Saint]> yes.
13.48.54 #       <[Saint]> And I do apologise for not updating the touchscreen themes as yet.
13.48.57 #       <kugelp> s/sbm/svn/
13.49.09 #       <[Saint]> the fact that no ones's noticed yet is a little telling how many people use them though ;)
13.49.22 #       <kugelp> we should swap them anyway
13.49.35 #       <[Saint]> Oh, sure.
13.50.09 #       <[Saint]> I was supposed to do that after the commit, but...earthquakes and various other stuff decided to alter my schedule
13.50.50 #       <kugelp> how old is the change?
13.51.01 #       <[Saint]> ~2 weeks
13.51.12 #       <[Saint]> ish
13.51.48 #       <gevaerts> wodz|work: did someone already tell you about the devcon hotel situation?
13.52.09 #       <gevaerts> wodz|work: if you need a cheap solution, I'd recommend talking to kugelp or petur 
13.52.18 #       <[Saint]> It was needed because it's more sane to put mute on a hold action so it's not always accidentally being pressed, but when things like mute are on hold actions (before the change) they fired on/off at the repeat rate.
13.52.20 #       <wodz|work> gevaerts: no
13.52.28 #       <[Saint]> so muting/unmuting was a game of chance ;)
13.53.09 #       <wodz|work> kugelp: any suggestions with hotel for devcon than?
13.53.26 #       <petur> wodz|work: #rockbox-community
13.54.34 #       <wodz|work> petur: can I join -community with our web irc client?
13.54.46 #       <petur> think so, yes
13.55.04 #       <[Saint]> Hmmm...that commit to touchregions is a lot older than I thought.
13.55.20 #       <[Saint]> It's not in "last 4 weeks", damn. I dropped the ball there.
13.55.32 #       <[Saint]> I just plain forgot about the "other" touch targets.
14.05.43 ***     Saving seen data "./dancer.seen"
14.10.22 Quit    robin0800 (Quit: Leaving)
14.14.17 Join    LambdaCalculus37 [0] (~rmenes@c-68-36-232-73.hsd1.nj.comcast.net)
14.14.28 Quit    LambdaCalculus37 (Changing host)
14.14.28 Join    LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37)
14.15.56 Join    user890104 [0] (~Venci@6bez10.info)
14.17.19 Join    robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com)
14.26.16 #       <wodz|work> I have target with single SD slot and internal NAND which operates in raw mode + FTL. What defines should I use? How this multivolume framework is working?
14.28.09 #       <pamaury> there are two different things iirc: multi drive and multi volume
14.28.32 #       <pamaury> multi drive is about having several drives as the names implies and multi volume is about having several partitions per drive
14.29.16 #       <wodz|work> nice, and that means?
14.31.08 #       <pamaury> that you need to enable multi drive but not I'm not sure you need to enable multi volume. You also want multi storage because you have SD + NAND, the fact that there is a FTL is a driver details I think but you could ask TheSeven for example
14.32.02 #       <pamaury> I don't exactly remember how you register the different drives so that that rockbox knows drive 0 i
14.32.09 #       <pamaury> s NAND and 1 is SD for example
14.32.45 #       <pamaury> iirc, each storage subsystem (NAND, SD) has an init function which says how many drive of this type it has
14.32.55 #       <wodz|work> hmm
14.33.52 #       <wodz|work> if I implement only NAND stubs for now, will file I/O calls fallback to the SD driver?
14.35.23 #       <pamaury> depends on how you implement stub. If you nand init function reports one drive, you stub will get the I/O (and fail) for NAND. The system will not fallback to SD for this drive
14.36.30 #       <pamaury> perhaps you want an example of cod ?
14.36.31 #       <pamaury> *code
14.36.37 #       <wodz|work> sure
14.37.02 #       <pamaury> ok, give me a few minutes
14.37.59 Quit    robin0800 (Quit: Leaving)
14.41.02 Join    dfkt [0] (~dfkt@unaffiliated/dfkt)
14.45.39 #       <pamaury> I'm nearly done
14.48.47 #       <pamaury> wodz|work: http://pastebin.com/BdqQa9xB
14.48.54 #       <pamaury> I hope I didn't forget anything
14.51.51 #       <wodz|work> ok, now is there a special way to access data on this drives? I mean how to read something from SD with standard fopen/fread ?
14.51.53 #       <pamaury> In this precise example, drive 0 will be first SD drive (sd_first_drive = 0), and drive 1 will be first NAND drive (nand_first_drive=1), since the storage system inits sd before nand but you don't have to know this
14.52.29 #       <pamaury> wodz|work: storage_read_sectors, storage_write_sectors
14.52.43 Nick    kugelp is now known as kugel (~kugel@rockbox/developer/kugel)
14.52.44 #       <pamaury> for raw access
14.54.29 #       <pamaury> for files this is a little bit more tricky. There is a main drive which will be rooted at / and other drive are rooted at special locations like /<magic_name_%d>
14.54.42 #       <kugel> wodz|work: there's a few ports with nand/sd, IIRC all of them pretty much only support the sd
14.54.46 #       <pamaury> I don't remember the magic_name, it depends on whether you have MD or not
14.55.03 Part    mem_
14.55.19 #       <pamaury> I also don't remember how you specify which drive is the main one
14.56.15 #       <pamaury> Actually I might have be wrong, you might need multi-volume :)
14.56.36 #       <Torne> iirc one implies the other
14.56.54 #       <pamaury> I think MD implies MV
14.56.59 #       <Torne> yeah
14.57.01 #       <Torne> sounds right.
14.57.08 #       <Torne> multivolume is whether we mount more than one filesystem
14.57.14 #       <pamaury> yes, just check config.h
14.57.20 #       <Torne> multidrive is whether there's more than one storage device driver instance
14.57.26 #       <pamaury> It's automatic so no worries
14.59.07 #       <pamaury> wodz|work: assuming the nand is the main drive, the SD will be mounted at /<microSD0> I think (see firmware/include/dir.h)
15.02.44 Join    benedikt93 [0] (~benedikt9@unaffiliated/benedikt93)
15.03.27 #       <pamaury> Actually, that's quite horrible because rockbox works on volume. The disk (disk.c) part has a mapping from volume to drives. And then the storage layer has a mapping from drive to subsystems.
15.05.25 #       <wodz|work> so now the last question is how to assign what is main drive
15.05.31 #       <TheSeven> pamaury: I don't have any MV/MD devices
15.08.00 #       <pamaury> I don't have either.
15.08.05 Quit    Xerion (Read error: Operation timed out)
15.09.42 #       <pamaury> The code works as follow: upon opening of /PATH, strip_volume(/PATH) is called to get the volume number. The volume is a FAT volume but the disk system maps volumes to drive which maps to subsystems. So somewhere there must be some code define which one is the main drive :D
15.10.55 #       <pamaury> Let me have a look at the D2 code, it has nand and sd and has special code because sd is the main drive
15.12.49 #       <pamaury> gevaerts: do you know how this works ?
15.13.33 Join    Xerion [0] (~xerion@5419A078.cm-5-2c.dynamic.ziggo.nl)
15.15.06 Join    evilnick_B [0] (0c140464@rockbox/staff/evilnick)
15.15.48 #       <gevaerts> pamaury: picking drive 0?
15.16.19 #       <pamaury> yes but you can't really choose since the storage.c code has a fixed initialization order
15.16.37 #       <pamaury> thus drive 0 will be SD and 1 will be NAND if you don't do anything special
15.16.56 #       <gevaerts> yes, that's how it works
15.16.57 #       <wodz|work> so SD will be the main
15.17.09 #       <wodz|work> right?
15.17.13 #       <pamaury> yes
15.17.17 #       <wodz|work> cool
15.17.27 #       <pamaury> the only way I see is to change storage.c if you are not happy with that
15.18.02 #       <Torne> surely the bit to fix is the assumption that drive 0 is the one to mount as the root :)
15.18.14 #       <Torne> rather than caring about which drive is which number.
15.19.13 Quit    wodz|work (Quit: CGI:IRC)
15.19.15 #       <pamaury> that's right, I *think* it's easy to fix but there might be lots of places which assume it
15.23.10 #       <Torne> well presumably only strip_volume and whatever mounts the root
15.23.19 #       <Torne> i say presumably
15.23.22 #       <Torne> i mean hopefully
15.24.51 Quit    LambdaCalculus37 (Quit: This computer has gone to sleep)
15.29.41 Join    LambdaCalculus37 [0] (~rmenes@c-68-36-232-73.hsd1.nj.comcast.net)
15.29.41 Quit    LambdaCalculus37 (Changing host)
15.29.41 Join    LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37)
15.39.23 Join    jerl92 [0] (~androirc@184.151.127.201)
15.41.03 Quit    jerl92 (Quit: AndroIRC)
15.42.40 Join    jerl92 [0] (~androirc@184.151.127.201)
15.45.25 Part    ibhan ("ERC Version 5.3 (IRC client for Emacs)")
15.49.33 Quit    Xerion (Ping timeout: 240 seconds)
16.05.47 ***     Saving seen data "./dancer.seen"
16.07.02 Join    slooopy [0] (~sloo@95-90-30-123-dynip.superkabel.de)
16.09.36 Join    Xerion [0] (~xerion@5419A078.cm-5-2c.dynamic.ziggo.nl)
17.05.50 Join    n1s [0] (~quassel@rockbox/developer/n1s)
17.09.27 Join    milk_ [0] (~milk@94-193-93-226.zone7.bethere.co.uk)
17.11.34 Join    L-Strife89 [0] (~Strife89@168.16.232.173)
17.16.01 Quit    Bagder (Quit: Konversation terminated!)
17.24.21 Join    mem_ [0] (~mem@mem-irc.netnod.se)
17.29.11 Quit    [fred] (Ping timeout: 276 seconds)
17.32.30 Part    Zagor
17.33.31 Join    [fred] [0] (fred@ircop.efnet.at)
17.38.26 Quit    [Saint] (Disconnected by services)
17.38.27 Join    S_a_i_n_t [0] (~st.lasciv@124-197-3-117.callplus.net.nz)
17.43.53 #       <kugel> Unhelpful: what does buflib_buffer_out() exactly do?
17.44.39 Join    boghog [0] (~aphax@2001:980:34c7:0:1e6f:65ff:fe86:1e03)
17.48.44 Quit    bluefoxx (Quit: Can we, should we, will we?)
17.50.31 Quit    sideral (Quit: Leaving.)
17.51.56 Quit    petur (Quit: *plop*)
17.55.02 #       <kugel> dircache is pretty tricky
17.55.50 Quit    tmzt (Ping timeout: 276 seconds)
17.58.22 Join    bluefoxx [0] (fuzzylomba@S0106485b3917092d.vs.shawcable.net)
18.03.02 Join    tmzt [0] (~tmzt@76.211.2.68)
18.04.31 Nick    S_a_i_n_t is now known as [Saint] (~st.lasciv@124-197-3-117.callplus.net.nz)
18.05.48 ***     Saving seen data "./dancer.seen"
18.06.10 Join    bertrik [0] (~bertrik@90-145-31-197.bbserv.nl)
18.06.10 Quit    bertrik (Changing host)
18.06.10 Join    bertrik [0] (~bertrik@rockbox/developer/bertrik)
18.09.13 Quit    LambdaCalculus37 (Quit: This computer has gone to sleep)
18.12.50 Join    t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201)
18.15.10 Quit    n1s (Remote host closed the connection)
18.15.12 Quit    milk_ (Quit: baaaiiii)
18.17.59 Quit    t0rc (Quit: WeeChat 0.3.4)
18.21.07 Quit    scorche|sh (Read error: Operation timed out)
18.21.11 Join    scorche|sh [0] (~scorche@squisch.net)
18.21.21 #       <kugel> dircache.c is *dirty*
18.23.26 #       * pamaury loads his railgun and aims at kugel
18.24.29 #       <pamaury> some parts tricky, I can accept that :)
18.24.33 #       <pamaury> *are tricky
18.25.14 #       <kugel> more than some :)
18.25.47 #       <pamaury> lol
18.26.36 #       <pamaury> the cache building uses some obscure fat functions but the rest is quite simple
18.28.03 #       <kugel> I'm only looking at the memory management
18.28.20 Join    u42p [0] (~v35b@d082014.adsl.hansenet.de)
18.28.58 #       <pamaury> ah, ok that part is dirty :)
18.31.05 #       <kugel> :)
18.32.42 Quit    krazykit (Quit: all hail the flying spaghetti monster)
18.33.40 #       <pamaury> actually the cache doesn't change too often so I don't think it's a big deal
18.34.13 Quit    einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org)
18.34.26 #       <kugel> I'm analyzing buffer_alloc() users for my buflib project
18.35.33 Join    TheLemonMan [0] (~lem0n@ppp-105-147.98-62.inwind.it)
18.36.39 #       <pamaury> one problem of this one is that you can't predict the size of it of course, and you don't want to allocate too much memory for the cache also
18.36.52 #       <kugel> I don't think that's a problem
18.37.12 #       <kugel> most problematic is if references or parts of the buffer are exposed to other modules
18.41.29 Join    Jerom1 [0] (~jerome@95.171.148.84)
18.42.37 Join    robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com)
18.45.17 Join    domonoky [0] (~Domonoky@rockbox/developer/domonoky)
18.46.51 Join    Buschel [0] (~chatzilla@p54B66D02.dip.t-dialin.net)
18.47.57 Quit    bluefoxx (Quit: Can we, should we, will we?)
18.50.58 Quit    robin0800 (Quit: Leaving)
18.52.54 Join    toffe82 [0] (~chatzilla@maf.wirelesstcp.net)
18.56.43 #       <saratoga> woot has the clip+ cheap today if anyone still doesn't have one:  http://sellout.woot.com/
18.57.24 #       <u42p> damn
18.58.05 #       <bluebroth3r> Llorean: for the "more album art logo" in the widget we could use the clef or "Rb" icon since those are square (reminds me, I haven't committed my move-all-logo-sources-into-a-folder patch)
18.58.52 #       <bluebroth3r> and for the audio dropouts ... in my case playback was simply stopping as well. I can very well imagine that the playback buffer should be even bigger. I can make you an apk with a bigger buffer if you want to give it a try
19.00.19 #       <bluebroth3r> JdGordon: any concerns about headphone detection aka FS#12097? I wouldn't mind committing it even with the delay issue, that can get fixed later
19.00.27 #       <kugel> gevaerts: I just analyzed dircache.c, it seems convertible with modifications to buflib (some sort of buflib_get_everything()). compaction will be a bit more tricky but should be doable in a safe way
19.00.58 #       <kugel> I also hacked on buflib a bit; named allocation and a print_allocations() for debugging purposes
19.01.14 #       <gevaerts> Sounds like a good start
19.01.23 #       * bluebroth3r goes trying to remove the headphone debouncing
19.02.15 #       <kugel> gevaerts: I think I generally understood it; except for buflib_buffer_in() and _out() but I'll try to ping Unhelpful about it
19.02.34 #       <pamaury> kugel: are you sure compaction is a good idea for dircache ? It's basically a bunch of pointers all over the place
19.02.48 Join    Stummi [0] (~Stummi@rockbox/developer/Stummi)
19.03.01 #       <kugel> it should be manageable
19.04.28 #       <pamaury> I mean, the cache is usually allocated at once, and it doesn't get really fragmented. Furthermore on each major FS action, it's rebuilt
19.04.48 #       <[Saint]> He didn't ask if it was managaeable ;)
19.04.51 Join    bluefoxx [0] (fuzzylomba@S0106485b3917092d.vs.shawcable.net)
19.04.55 #       <[Saint]> He asked if it was a good idea.
19.05.05 #       <bluebroth3r> [Saint]: what phone and Android version do you have?
19.05.10 #       <kugel> pamaury: I'm not asking to compact the dircache :)
19.05.34 #       <[Saint]> GT-i5503T (Baby Galaxy S) and 2.1.1
19.05.39 #       <[Saint]> bluebroth3r: ^
19.05.53 #       <kugel> but it should work in an environment where the dircache buffer is moved due to compaction of the main memory
19.06.52 #       <kugel> pamaury: it's only rebuild on boot and usb-unplug, no?
19.07.05 #       <pamaury> all disk mount/unmount too
19.07.21 #       <kugel> what I said :)
19.07.32 #       <pamaury> on compaction, basically half of the content will change since it will invalidate all pointers, except if you do it in a relative address mode
19.07.43 #       <pamaury> you can unplug sd card
19.07.52 #       <kugel> ah right
19.08.53 #       <kugel> pamaury: I can walk the entire dircache to fix up pointers, and a relative address mode is already used
19.08.58 #       <pamaury> Ok, so actually by explicitely using offsets instead of pointers, dircache can be made rather transparent to compaction
19.08.58 #       <[Saint]> bluebroth3r: Howcome?
19.09.53 #       <kugel> I can also make buflib call a user-supplied compaction function (it now does a simple memmove, but for dircache something with knowledge about the allocation might be better)
19.10.33 #       <kugel> pamaury: that too, I just need to be careful about dircache_get_entry_ptr()
19.10.47 #       <bluebroth3r> [Saint]: just wondering what devices are affected by this audio stops issue
19.11.32 #       <pamaury> kugel: there are places other that dircache.c which use dircache pointers I think
19.11.40 #       <bluebroth3r> hmm, posting SYS_PHONE_UNPLUGGED directly in button_tick doesn't fix the lag issue. It's much shorter now but still audible
19.12.33 Quit    [Saint] (Quit: I'm only going to Heaven if it feels like Hell, I'm only going to Heaven if it tastes like caramel...)
19.13.20 #       <bluebroth3r> or I'm doing something wrong
19.14.17 Quit    Buschel (Ping timeout: 276 seconds)
19.14.46 Join    Buschel [0] (~chatzilla@p54B66D02.dip.t-dialin.net)
19.14.52 #       <kugel> pamaury: like I said, every dircache_get_entry_ptr() caller needs special care, but the rest should work
19.18.35 #       <pamaury> in fact there in only one dircache_get_entry_ptr() call in the firmware/ part and it's easily handled. However play_list.c stores explicit pointers so it needs care. And there tagcache which uses it too :(
19.19.05 #       <CIA-87> New commit by 03bluebrother (r29825): deploy.py: support adding a build id. ...
19.20.31 #       <kugel> pamaury: in playlist.c it's done in a thread which seems to be just there to handle the case of the pointers getting invalid :)
19.22.39 #       <CIA-87> r29825 build result: All green
19.24.08 #       <pamaury> I don't know, playlist.c is rather huge so beware :)
19.24.35 Quit    Keripo1 (Read error: Connection reset by peer)
19.25.13 #       <kugel> great, it stores the pointer in a buffer_alloc'd buffer, that's my thing :p
19.26.58 #       <pamaury> kugel: if you plan to change things in dircache.c, tell me because there might be an opportunity to reduce the memory footprint of dircache
19.27.27 Part    u42p ("Leaving")
19.28.06 #       <kugel> pamaury: firstly I'll only drop-in replace buffer_alloc() with buflib_alloc(), compaction is a later step
19.28.20 #       <kugel> and also resolve the nasty audiobuf[] access
19.36.37 Quit    L-Strife89 (Ping timeout: 258 seconds)
19.38.43 #       <kugel> I wonder if it's possible to have an git mirror at github?
19.44.24 Join    sideral [0] (~sideral@213.165.85.248)
19.44.24 Quit    sideral (Changing host)
19.44.24 Join    sideral [0] (~sideral@rockbox/developer/sideral)
19.46.59 Quit    jerl92 (Ping timeout: 252 seconds)
19.47.47 #       <B4gder> kugel: I'd guess it should be possible
19.50.55 Nick    GodEater_ is now known as GodEater (~bibble@rockbox/staff/GodEater)
19.58.53 Quit    TheSeven ()
19.59.10 Join    TheSeven [0] (~TheSeven@rockbox/developer/TheSeven)
19.59.18 Join    Horscht [0] (~Horscht@p5DD5703D.dip.t-dialin.net)
19.59.22 Quit    Horscht (Changing host)
19.59.22 Join    Horscht [0] (~Horscht@xbmc/user/horscht)
20.05.49 ***     Saving seen data "./dancer.seen"
20.09.29 #       <kugel> B4gder: it would be nice because, because github has nice collaboration features, including an overview over the forks and a acceptable web interface
20.09.51 #       * B4gder has a bunch of projects on github...
20.10.32 #       <B4gder> although, github does "attract" a slightly different work flow that doesn't always work fine with group efforts such as Rockbox
20.10.53 #       <B4gder> like the pull requests
20.11.13 #       <kugel> we won't have pull requests I guess if it's just a mirrow
20.11.31 #       <B4gder> you can't turn them off though so they will come...
20.11.58 #       <kugel> I'd just like to quickly see what other rockbox'ers (who use git) are working on
20.12.46 #       <B4gder> I'm a git and github fan so you have my sympathy
20.12.54 #       <kugel> great :)
20.13.14 #       <kugel> who's going to do the script work? :p
20.13.41 #       <kugel> (/me thinks a github mirror is at the very least way better than the current rockbox.org one)
20.18.50 Join    Xerion_ [0] (~xerion@5419A078.cm-5-2c.dynamic.ziggo.nl)
20.20.44 Quit    Xerion (Ping timeout: 240 seconds)
20.20.44 Nick    Xerion_ is now known as Xerion (~xerion@5419A078.cm-5-2c.dynamic.ziggo.nl)
20.27.55 Quit    saratoga (Ping timeout: 252 seconds)
20.32.40 Join    ibhan [0] (~ibhan@195.41.77.232)
20.34.06 #       <pixelma> to add to the earlier discussion... I prefer the "unusable on 240x320 (my) screen" small square version of the widget with all buttons but no album art. I couldn't have told which number x number that actually refers to as I'm not informed or asked about it while creating the widget
20.34.23 #       <bluebroth3r> B4gder: in case of a git mirror, can we use realname in the commits?
20.35.04 #       <bluebroth3r> (i.e. use --authors-file with git-svn)
20.35.24 #       <pixelma> and I agree with kugel that the touch region commit is the wrong way around - &action should have stayed what it is and the added version that triggers only once should have gotten the *action
20.38.47 #       <Llorean> bluebroth3r: I'd love to try one with an even larger buffer (and headphone unplug with debouncing removed if you managed that) :)
20.39.52 Quit    Buschel (Ping timeout: 240 seconds)
20.40.23 #       <bluebroth3r> Llorean: well, removing debouncing for headphone unplug didn't work for me.
20.40.41 #       <Llorean> Oh?
20.41.53 #       <bluebroth3r> maybe I changed the wrong code, haven't figured yet :)
20.42.30 #       <Llorean> Aaah
20.42.48 #       <Llorean> Well I'll happily try just the larger buffer too.
20.43.03 #       <bluebroth3r> building right now.
20.43.30 Join    Buschel [0] (~chatzilla@p54B66D02.dip.t-dialin.net)
20.47.46 #       <bluebroth3r> Llorean: new apk uploaded. Includes headphone detection, updated buffer (I used 16* minimum size) and resources on SD.
20.48.04 Nick    kugel is now known as kugelp (~kugel@rockbox/developer/kugel)
20.48.15 #       <Llorean> Could you re-send me the link?
20.48.29 #       <bluebroth3r> Llorean: http://www.alice-dsl.net/dominik.riebeling/rockbox/
20.50.02 Join    SJB [0] (~2e3ba363@giant.haxx.se)
20.50.15 #       <Llorean> Thanks
20.50.28 #       <SJB> hi, i got a porblem with rock box on sandisk e200
20.50.40 #       <SJB> doesnt shutdown
20.50.44 #       <bluebroth3r> you're welcome :)
20.50.45 #       <SJB> cant do anything
20.50.57 #       <Llorean> SJB: Hold the power button for 30 seconds.
20.50.59 #       <SJB> "Shutting down.."
20.51.28 #       <SJB> k 
20.51.30 #       <SJB> wotks
20.51.35 #       <SJB> works D
20.51.48 #       <SJB> and the clock bug is fixed after "reboot"
20.52.02 #       <Llorean> bluebroth3r: I'll let you know if it freezes again. What's the FS number for the increased buffer (if there is one)?
20.52.04 #       <SJB> clock was showing random numbers 
20.52.28 #       <SJB> 1-2times per soecond it switched the time
20.52.28 #       <pixelma> it would be way nicer and read better if you could try putting more of your thoughts one one line, not using enter as punctuation ;)
20.53.33 #       <bluebroth3r> Llorean: FS
20.53.34 #       <bluebroth3r> FS
20.53.41 #       * bluebroth3r curses keyboard
20.53.42 #       <AlexP> FFS? :)
20.53.45 #       <bluebroth3r> Llorean: FS#12064
20.53.57 #       <bluebroth3r> german keyboard has # next to enter ...
20.54.11 #       <AlexP> mine too (UK)
20.55.42 #       <Llorean> bluebroth3r: Is there an expected downside of the larger buffer?
20.56.26 Quit    Horscht (Read error: Connection reset by peer)
20.56.57 #       <bluebroth3r> Llorean: none that I'm aware of. It uses more memory of course :)
20.57.28 #       <bluebroth3r> but given the amount of memory those devices have I don't see a problem here.
20.57.35 #       <Llorean> bluebroth3r: I'm not too worried about that personally. I'm still using less than half of my phone's RAM.
20.58.20 #       <AlexP> What does Rockbox do in regards to that on phones?
20.58.26 #       <AlexP> Allocate a fixed amount?
20.58.47 Join    Horscht [0] (~Horscht@p5DD5703D.dip.t-dialin.net)
20.58.47 Quit    Horscht (Changing host)
20.58.47 Join    Horscht [0] (~Horscht@xbmc/user/horscht)
20.58.52 #       <bluebroth3r> Llorean: I haven't checked if the buffer size has effects on the responsiveness of playback.
20.59.15 #       <Llorean> It doesn't *seem* to
20.59.18 #       <Llorean> At least it pauses instantly
20.59.28 #       <kugelp> I'd expect higher latency
21.00.02 Join    mudd1 [0] (~cmertes@ip-78-94-202-227.unitymediagroup.de)
21.00.35 #       <bluebroth3r> there's a noticable lag when skipping with the 16* buffer on my phone
21.01.39 Join    gartral [0] (~gareth@ip184-189-215-49.cl.ri.cox.net)
21.01.55 #       <bluebroth3r> but _if_ this fixes the audio stops issue for you we at least have another success report :)
21.02.10 #       <bluebroth3r> (which is the reason I've used such a high value
21.02.29 #       <Llorean> bluebroth3r: It already got stuck unpausing and pausing a couple times with headphone unplugging. But I'll see if it gets stuck with normal listening.
21.02.34 #       <gartral> is there a problem in the recent nightlies that prevents the microSD card from mounting over usb on the Sansa e200?
21.02.44 #       <gartral> known problem*
21.02.45 #       <kugelp> 48k is still just ~.25s Aug audio so probably not a problem
21.02.47 #       <Llorean> bluebroth3r: I'd guess it's not a buffer issue then.
21.02.53 #       <bluebroth3r> hmm.
21.04.21 #       <bluebroth3r> kugelp: I've used 16*getMinBufferSize(). The latter is 12ki on my phone, so it ends up with 192k. That's a noticable amound of lag :)
21.04.50 #       <Llorean> On a related note, when I pause, and it resumes, it plays a little bit of audio *then* it skips back the 5 seconds it's supposed to.
21.04.53 #       <Llorean> It's a little bit odd.
21.05.01 #       <Llorean> Resumes on headphone replug, that is.
21.06.01 #       <bluebroth3r> Llorean: I guess that is caused by the big buffer (and I assume there is nothing done about that buffer on pause-rewind)
21.06.19 #       <Llorean> Yeah, that was my guess.
21.06.20 #       <bluebroth3r> which might also be the thing when skipping with such a big buffer.
21.06.31 Quit    slooopy (Ping timeout: 248 seconds)
21.06.38 #       <Llorean> Is this build from before or after the playback rework?
21.07.03 #       <bluebroth3r> after. I.e. it's current svn.
21.07.21 #       <Llorean> Isn't there a problem like this happening since the playback rework too? I remember some mention of it on the Clip?
21.07.41 #       <bluebroth3r> don't know, haven't paid much attention to that
21.07.57 #       <Buschel> playback hangs up reproducibly
21.08.06 #       <Llorean> Buschel: Under what conditions?
21.08.41 #       <pixelma> really? I couldn't reproduce hangs with the new engine yet
21.08.44 #       <bluebroth3r> hmm, with the 4* buffer I need for stable playback on my phone there is also a hearable lag on jumping in the track
21.08.45 #       <Buschel> for me: play a playlist (all tracks) for ~1h -> hangs up
21.09.08 #       <Buschel> see FS#12093, learman reports the same
21.09.12 #       <bluebroth3r> so maybe we need some Android buffer invalidation in that cases
21.09.36 #       <Llorean> Buschel: For me it seems to be after 4 hours, but this is 48kbps or 32kbps audio
21.09.40 #       <Llorean> So it may be a similar amount of buffer use...
21.09.46 Quit    bertrik (Read error: Connection reset by peer)
21.09.50 #       <pixelma> mostly using my M5 currently for listening longer times (and a mix of flac and mp3)
21.10.04 #       <Llorean> Buschel: I haven't looked at the exact time, rather, but I know it seems to happen after I've been listening 'quite a while'
21.10.46 #       <Buschel> from what I see so far (and what jhMike suggests) it might be connected to rebuffering... let's see, I am confident he will find the cause
21.11.09 #       <Llorean>  bluebroth3r: Maybe we shouldn't worry about the problem I'm having until the playback engine issue is nailed down. :)
21.12.07 #       <kugelp> bluebroth3r: perhaps a combination of larger buffer and refilling earlier works best
21.12.14 #       <pixelma> maybe it has to do with ARM then too as rebuffering happens quite often with flac on a 16MB RAM target and I haven't experienced this yet
21.13.11 #       <bluebroth3r> Llorean: thinking about it, that lag on headphone pause might also be related to that buffer thing
21.19.03 #       <kugelp> once it's in the buffer it can't be stopped
21.19.30 #       <Llorean> Why does pause/unpause seem so responsive then?
21.19.48 #       <Llorean> If we've got that buffer that will get consumed either way.
21.20.00 #       <Llorean> I'm not trying to contradict you, rather just wondering what's going on in general. How it works.
21.20.40 #       <pixelma> is the Clip+ one of the players we don't do an automatic reboot into OF (I tend to mix up the newer AMS Sansas)
21.21.07 #       <CIA-87> New commit by 03bluebrother (r29826): Fix whitespace errors aka tabs.
21.22.05 #       <Llorean> pixelma: I believe so, yes.
21.24.45 #       <CIA-87> r29826 build result: All green
21.26.15 Join    Strath [0] (~IceChat77@173-31-153-77.client.mchsi.com)
21.39.10 Join    bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl)
21.39.10 Quit    bertrik (Changing host)
21.39.10 Join    bertrik [0] (~bertrik@rockbox/developer/bertrik)
21.40.36 Quit    Stummi (Quit: Bye!)
21.47.11 Quit    evilnick_B (Quit: Page closed)
21.51.17 Quit    SJB (Quit: CGI:IRC)
21.52.21 Quit    Buschel (Ping timeout: 246 seconds)
21.55.20 Part    ibhan
21.55.37 Quit    froggyman (Quit: Ex-Chat)
21.55.49 Join    froggyman [0] (~seth@unaffiliated/froggyman)
21.56.54 Quit    guymann (Quit: brb)
21.56.55 Quit    gartral (Read error: Connection reset by peer)
22.02.08 Quit    benedikt93 (Quit: Welcome to the Internet, where the men are men, the women are men and the children are agents of the FBI)
22.05.51 ***     Saving seen data "./dancer.seen"
22.07.27 #       <B4gder> bluebroth3r: we're still not talking about a two-way mirror though so no commits from git would get back to svn
22.08.13 #       <bluebroth3r> B4gder: I wasn't expecting that :)
22.08.36 #       <bluebroth3r> but even for a one way svn -> git mirror it would be nice to see real names in the git log
22.08.42 #       <B4gder> true
22.09.17 #       <B4gder> well, anyone can just try it out and see what's working
22.09.20 #       <bluebroth3r> and that can also clean up with the different casing used issue in svn
22.10.01 #       <bluebroth3r> the name translation thingy or mirroring at github?
22.10.06 #       <B4gder> both
22.10.12 #       <sideral> Llorean: I've observed similar skip-back behavior with the rewind-on-pause patch (FS#11931). jhMikeS advised that the new playback engine requires a call to audio_pre_ff_rewind prior to any skipping to plush the pcm buffer (SWCODEC only), and that took care of my problem. Maybe this call missing in the path you're exercising?
22.10.29 #       <sideral> s/plush/flush/
22.10.53 #       <bluebroth3r> flushing the pcm buffer seems like something Android could use too
22.11.17 #       * bluebroth3r would try mirroring at github but doesn't have a machine running permanently to do that.
22.11.42 #       <B4gder> well, to test out you could just do single-shot runs every now and then
22.11.55 #       <B4gder> and once things work we can put the magic on the svn server
22.29.11 DEBUG   EOF from server (No route to host) (snapshot: netstuff.c line 545)
22.29.11 ***     Cleanup
22.29.11 ***     Cleanup
22.29.11 ***     No seen item changed, no save performed.
22.29.11 ***     Exit
22.29.13 ***     Started Dancer V4.16
22.29.13 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.29.13 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.29.13 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.29.13 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.29.13 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.29.13 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.29.13 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.29.13 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.29.13 ***     Unable to connect to irc.freenode.net on port 6667 (tried 8 times)
22.29.13 ***     Cleanup
22.29.13 ***     Cleanup
22.29.13 ***     No seen item changed, no save performed.
22.29.13 ***     Exit
22.30.53 ***     Started Dancer V4.16
22.30.53 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.30.53 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.30.53 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.30.53 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.30.53 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.30.53 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.30.53 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.30.53 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.30.53 ***     Unable to connect to irc.freenode.net on port 6667 (tried 8 times)
22.30.53 ***     Cleanup
22.30.53 ***     Cleanup
22.30.53 ***     No seen item changed, no save performed.
22.30.53 ***     Exit
22.32.40 ***     Started Dancer V4.16
22.32.40 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.32.40 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.32.40 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.32.40 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.32.40 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.32.40 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.32.40 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.32.40 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.32.40 ***     Unable to connect to irc.freenode.net on port 6667 (tried 8 times)
22.32.40 ***     Cleanup
22.32.40 ***     Cleanup
22.32.40 ***     No seen item changed, no save performed.
22.32.40 ***     Exit
22.34.22 ***     Started Dancer V4.16
22.34.22 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.34.22 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.34.22 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.34.22 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.34.22 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.34.22 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.34.22 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.34.22 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.34.22 ***     Unable to connect to irc.freenode.net on port 6667 (tried 8 times)
22.34.22 ***     Cleanup
22.34.22 ***     Cleanup
22.34.22 ***     No seen item changed, no save performed.
22.34.22 ***     Exit
22.36.01 ***     Started Dancer V4.16
22.36.01 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.36.01 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.36.01 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.36.01 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.36.01 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.36.01 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.36.01 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.36.01 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.36.01 ***     Unable to connect to irc.freenode.net on port 6667 (tried 8 times)
22.36.01 ***     Cleanup
22.36.01 ***     Cleanup
22.36.01 ***     No seen item changed, no save performed.
22.36.01 ***     Exit
22.37.49 ***     Started Dancer V4.16
22.37.49 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.37.49 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.37.49 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.37.49 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.37.49 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.37.49 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.37.49 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.37.49 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.37.49 ***     Unable to connect to irc.freenode.net on port 6667 (tried 8 times)
22.37.49 ***     Cleanup
22.37.49 ***     Cleanup
22.37.49 ***     No seen item changed, no save performed.
22.37.49 ***     Exit
22.39.31 ***     Started Dancer V4.16
22.39.31 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.39.31 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.39.31 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.39.31 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.39.31 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.39.31 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.39.31 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.39.31 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.39.31 ***     Unable to connect to irc.freenode.net on port 6667 (tried 8 times)
22.39.31 ***     Cleanup
22.39.31 ***     Cleanup
22.39.31 ***     No seen item changed, no save performed.
22.39.31 ***     Exit
22.41.10 ***     Started Dancer V4.16
22.41.10 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.41.10 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.41.10 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.41.10 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.41.10 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.41.10 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.41.10 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.41.10 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.41.10 ***     Unable to connect to irc.freenode.net on port 6667 (tried 8 times)
22.41.10 ***     Cleanup
22.41.10 ***     Cleanup
22.41.10 ***     No seen item changed, no save performed.
22.41.10 ***     Exit
22.42.57 ***     Started Dancer V4.16
22.42.57 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.42.57 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.42.57 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.42.57 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.42.57 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.42.57 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.42.57 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.42.57 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.42.57 ***     Unable to connect to irc.freenode.net on port 6667 (tried 8 times)
22.42.57 ***     Cleanup
22.42.57 ***     Cleanup
22.42.57 ***     No seen item changed, no save performed.
22.42.57 ***     Exit
22.44.39 ***     Started Dancer V4.16
22.44.39 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.44.39 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.44.39 DEBUG   gethostbyname(2) failed for irc.freenode.net (Connection timed out) (snapshot: netstuff.c line 99)
22.44.39 ***     Connected to irc.freenode.net on port 6667
22.44.39 ***     Logfile for #rockbox started
22.45.12 Mode    "logbot :+i" by logbot
22.45.15 ***     Server message 501: 'logbot :Unknown MODE flag'
22.45.15 Join    logbot [0] (~rockbox@giant.haxx.se)
22.45.15 Join    gartral [0] (~gareth@unaffiliated/gartral)
22.45.15 Join    jmaslibre [0] (~user@fsf/member/jmaslibre)
22.45.15 Join    sideral [0] (~sideral@rockbox/developer/sideral)
22.45.15 Join    lovasoa [0] (~lovasoa@cac94-9-88-162-232-8.fbx.proxad.net)
22.45.15 Join    JesusFreak316 [0] (~JesusFrea@pool-173-65-83-240.tampfl.fios.verizon.net)
22.45.15 Join    guymann [0] (~charles@66-159-172-85.adsl.snet.net)
22.45.15 Join    froggyman [0] (~seth@unaffiliated/froggyman)
22.45.15 Join    bertrik [0] (~bertrik@rockbox/developer/bertrik)
22.45.15 Join    Strath [0] (~IceChat77@173-31-153-77.client.mchsi.com)
22.45.15 Join    mudd1 [0] (~cmertes@ip-78-94-202-227.unitymediagroup.de)
22.45.15 Join    Horscht [0] (~Horscht@xbmc/user/horscht)
22.45.15 Join    Xerion [0] (~xerion@5419A078.cm-5-2c.dynamic.ziggo.nl)
22.45.15 Join    TheSeven [0] (~TheSeven@rockbox/developer/TheSeven)
22.45.15 Join    bluefoxx [0] (fuzzylomba@S0106485b3917092d.vs.shawcable.net)
22.45.15 Join    toffe82 [0] (~chatzilla@maf.wirelesstcp.net)
22.45.15 Join    domonoky [0] (~Domonoky@rockbox/developer/domonoky)
22.45.15 Join    Jerom1 [0] (~jerome@95.171.148.84)
22.45.15 Join    TheLemonMan [0] (~lem0n@ppp-105-147.98-62.inwind.it)
22.45.15 Join    scorche|sh [0] (~scorche@squisch.net)
22.45.15 Join    tmzt [0] (~tmzt@76.211.2.68)
22.45.15 Join    boghog [0] (~aphax@2001:980:34c7:0:1e6f:65ff:fe86:1e03)
22.45.15 Join    [fred] [0] (fred@ircop.efnet.at)
22.45.15 Join    mem_ [0] (~mem@mem-irc.netnod.se)
22.45.15 Join    dfkt [0] (~dfkt@unaffiliated/dfkt)
22.45.15 Join    user890104 [0] (~Venci@6bez10.info)
22.45.15 Join    DerPapst1 [0] (~Alexander@p57954323.dip.t-dialin.net)
22.45.15 Join    jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS)
22.45.15 Join    Elfish [0] (amba@2a01:4f8:100:90a1:abc:abc:abc:abc)
22.45.15 Join    bzed [0] (~bzed@devel.recluse.de)
22.45.15 Join    markun [0] (~markun@rockbox/developer/markun)
22.45.15 Join    JesusChrysler [0] (~JesusChry@c-69-253-15-232.hsd1.pa.comcast.net)
22.45.15 Join    utanapischti [0] (~username@p4FF2DB89.dip.t-dialin.net)
22.45.15 Join    pamaury [0] (~quassel@rockbox/developer/pamaury)
22.45.15 Join    balintx [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu)
22.45.15 Join    ender` [0] (krneki@foo.eternallybored.org)
22.45.15 Join    Rob2223 [0] (~Miranda@p4FFF32BE.dip.t-dialin.net)
22.45.15 Join    kugelp [0] (~kugel@rockbox/developer/kugel)
22.45.15 Join    pixelma [0] (quassel@rockbox/staff/pixelma)
22.45.15 Join    amiconn [0] (quassel@rockbox/developer/amiconn)
22.45.15 Join    niekie [0] (~niek@CAcert/Assurer/niekie)
22.45.15 Join    tchan [0] (~tchan@lunar-linux/developer/tchan)
22.45.15 Join    bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com)
22.45.15 Join    plux [0] (~yogurt@h-34-156.A238.priv.bahnhof.se)
22.45.15 Join    Beta2K [0] (~Beta2K@d24-36-131-14.home1.cgocable.net)
22.45.15 Join    n17ikh [0] (~n17ikh@c-174-56-148-108.hsd1.sc.comcast.net)
22.45.15 Join    gevaerts [0] (~fg@rockbox/developer/gevaerts)
22.45.15 Join    T44 [0] (~Topy44@g228228216.adsl.alicedsl.de)
22.45.15 Join    cjcopi [0] (~craig@charon.craig.copi.org)
22.45.15 Join    Unhelpful [0] (~quassel@rockbox/developer/Unhelpful)
22.45.15 Join    avacore [0] (~avacore@1008ds1-rdo.0.fullrate.dk)
22.45.15 Join    bluebroth3r [0] (~dom@rockbox/developer/bluebrother)
22.45.15 Join    Zarggg [0] (~zarggg@24.229.139.169.res-cmts.sm.ptd.net)
22.45.15 Join    merbanan [0] (~banan@c-94-255-221-202.cust.bredband2.com)
22.45.15 Join    yosafbridge [0] (~yosafbrid@li125-242.members.linode.com)
22.45.15 Join    Slasheri [0] (miipekk@rockbox/developer/Slasheri)
22.45.16 Join    simonlnu [0] (simon@unaffiliated/simonrvn)
22.45.16 Join    GodEater [0] (~bibble@rockbox/staff/GodEater)
22.45.16 Join    rasher [0] (~rasher@rockbox/developer/rasher)
22.45.16 Join    FOAD [0] (~dok@83.161.135.61)
22.45.16 Join    Buganini [0] (~buganini@2001:288:c237:0:dead:beef:cafe:babe)
22.45.16 Join    jordan` [0] (~gromit@ALagny-154-1-26-60.w83-112.abo.wanadoo.fr)
22.45.16 Join    eGen [0] (generat0r@gate.mmdecin.cz)
22.45.16 Join    swilde [0] (~wilde@aktaia.intevation.org)
22.45.16 Join    alexbobp [0] (~alex@ppp-70-253-82-23.dsl.austtx.swbell.net)
22.45.16 Join    Guinness [0] (Slayer@c-68-55-111-159.hsd1.va.comcast.net)
22.45.16 Join    Llorean [0] (~DarkkOne@rockbox/user/Llorean)
22.45.16 Join    Strife89 [0] (~Strife89@168.16.226.82)
22.45.16 Join    advcomp2019__ [0] (~advcomp20@unaffiliated/advcomp2019)
22.45.16 Join    soap_ [0] (~soap@rockbox/staff/soap)
22.45.16 Join    knittl [0] (~knittl@unaffiliated/knittl)
22.45.16 Join    literal [0] (hinrik@w.nix.is)
22.45.16 Join    CIA-87 [0] (~CIA@208.69.182.149)
22.45.16 Join    Farthen [0] (~Farthen@static.225.178.40.188.clients.your-server.de)
22.45.16 Join    ved [0] (ved@ddsbox.co.cc)
22.45.16 Join    Hadaka [0] (~naked@naked.iki.fi)
22.45.16 Join    ranmachan [0] (ranma@yumi.tdiedrich.de)
22.45.16 Join    @ChanServ [0] (ChanServ@services.)
22.45.16 Join    crwl [0] (~crwlll@dsl-jklbrasgw1-fe8edf00-29.dhcp.inet.fi)
22.45.16 Join    preglow [0] (thomj@rockbox/developer/preglow)
22.45.16 Join    ack` [0] (~ack@mingbai.org)
22.45.16 Join    aevin [0] (eivindsy@unaffiliated/aevin)
22.45.16 Join    feisar-_ [0] (jljhook@ihq.in)
22.45.16 Join    kkit|sh [0] (~kkit@li135-248.members.linode.com)
22.45.16 Join    jepler [0] (~jepler@emc/developer/pdpc.professional.jepler)
22.45.16 Join    linuxguy3 [0] (~timj@adsl-76-202-250-104.dsl.emhril.sbcglobal.net)
22.45.16 Join    pikytcus [0] (~bigd@failbox.co.cc)
22.45.16 Join    JdGordon [0] (~jonno@rockbox/developer/JdGordon)
22.45.16 Join    Barahir [0] (~jonathan@fb08schindler24.anorg.chemie.uni-giessen.de)
22.45.16 Join    logvelc [0] (~erik@elbereth.midgard.liu.se)
22.45.16 Join    Staphylo [0] (staphylo@hyperion.epimeros.org)
22.45.16 Join    jae [0] (~jae@dedicated.jaerhard.com)
22.45.16 Join    ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123)
22.45.16 Join    linuxstb [0] (~linuxstb@rockbox/developer/linuxstb)
22.45.16 Join    Rondom [0] (~rondom@2a01:488:66:1000:b24d:4f2f:0:1)
22.45.16 Join    zu [0] (~zu@ks355000.kimsufi.com)
22.45.16 Join    bthomson [0] (~bthomson@pool-71-114-64-197.washdc.dsl-w.verizon.net)
22.45.16 Join    jfc [0] (~john@pool-72-73-80-12.ptldme.east.myfairpoint.net)
22.45.16 Join    Zambezi [0] (Zulu@unaffiliated/zambezi)
22.45.16 Join    AlexP [0] (~alex@rockbox/staff/AlexP)
22.45.16 Join    YPSY [0] (~ypsy@geekpadawan.de)
22.45.16 Join    ender| [0] (krneki@foo.eternallybored.org)
22.45.16 Join    B4gder [0] (~daniel@rockbox/developer/bagder)
22.45.16 Join    tguinot [0] (~tguinot@ks22840.kimsufi.com)
22.45.16 Join    maraz_ [0] (maraz@kapsi.fi)
22.45.16 Join    pjm0616 [0] (~user@110.8.235.86)
22.45.16 Join    TBCOOL [0] (~tb@c-3c3671d5.09-42-73746f22.cust.bredbandsbolaget.se)
22.45.16 Join    parafin [0] (parafin@paraf.in)
22.45.16 Join    ThomasAH [0] (~thomas@aktaia.intevation.org)
22.45.16 Join    Torne [0] (~torne@rockbox/developer/Torne)
22.45.16 Join    Galois [0] (djao@efnet-math.org)
22.45.16 Join    z35 [0] (~z35@ool-18bdad71.dyn.optonline.net)
22.45.16 Join    dionoea [0] (~dionoea@videolan/developer/dionoea)
22.45.16 Join    Utchy [0] (~Utchy@rps6752.ovh.net)
22.45.16 Join    sinthetek [0] (~sinthetek@unaffiliated/sinthetek)
22.45.16 Join    simabeis [0] (~simabeis@lobmenschen.de)
22.45.16 Join    FoH [0] (~foh@adsl-98-83-123-68.bhm.bellsouth.net)
22.45.16 Join    mystica555 [0] (~mike@71-33-152-71.hlrn.qwest.net)
22.45.16 Join    mc2739 [0] (~mc2739@rockbox/developer/mc2739)
22.45.16 Join    scorche [0] (~scorche@rockbox/administrator/scorche)
22.45.16 Join    martii [0] (martii@sokrates.mimuw.edu.pl)
22.45.33 #       <B4gder> ick, there it is!
22.45.48 #       <B4gder> Llorean: well, it would be easy to provide such output at least
22.45.57 #       <bluebroth3r> Llorean: the problem is that the svn repository holds commits that don't belong to Rockbox itself (i.e. www) so the number would be off
22.46.05 #       <B4gder> we could do a "commit-count + hash"
22.46.09 #       <Llorean> bluebroth3r: It's already off, isn't it?
22.46.16 #       <bluebroth3r> sure
22.46.21 #       <Llorean> So I don't see a problem with that.
22.46.46 #       <B4gder> if we just make our own describe command, we can get the "rev number" similar to the svn revision, and then we add the hash for git convenience
22.46.50 #       <bluebroth3r> my local repository is at start-28408-g7d6ac7c but svn is at Revision: 29826
22.46.55 #       <Llorean> B4gder: I mean, to me, the only important thing is that there's some sort of constant sequential identifier. Since the tag can change arbitrarily and may not include identifiers that place it in time, a total commit count + hash would probably be better.
22.47.47 #       <Llorean> bluebroth3r: Well, we'd know that all new identifiers come from after the changeover thanks to the inclusion of the hash anyway, so if they don't match / follow it's not too big a deal as long as they work from git-advent forward.
22.47.50 #       <B4gder> "git log --oneline | wc -l" gives the number, then we do git log --oneline -1 | cut "-d " -f1 to get the hash to append to it
22.48.04 #       <B4gder> and voila, very svn-like
22.48.08 #       <gartral> B4gder: how long was the site down?
22.48.16 #       <B4gder> ~30 minutes
22.49.16 Join    stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk)
22.50.01 #       <lovasoa> Maybe I didn't install rockbox correctly... Or is it "normal" that utf8 filenames don't show up correctly?
22.50.43 #       <stripwax> is your codepage set to utf8?
22.50.55 Quit    stripwax (Changing host)
22.50.55 Join    stripwax [0] (~Miranda@rockbox/developer/stripwax)
22.51.47 #       <sideral> Hey AlexP, have you had a chance to try out FS#12073 (incrementally add files to DB) yet?
22.54.05 #       <stripwax> lovasoa - my question was directed to you (in case it wasn't clear!)
22.55.15 Quit    lovasoa (Ping timeout: 276 seconds)
22.56.46 #       <stripwax> oh well
22.57.01 Join    lovasoa [0] (~lovasoa@cac94-9-88-162-232-8.fbx.proxad.net)
23.00.52 #       <AlexP> sideral: Sorry, completely slipped my mind
23.01.04 #       <AlexP> I'm away this weekend, but will try ASAP
23.01.04 Quit    lovasoa (Ping timeout: 240 seconds)
23.01.56 #       <sideral> AlexP: I'd like to cash in on your Promise :)
23.02.20 #       <stripwax> lovasoa - is this link relevant (from a quick google)  -  http://forums.rockbox.org/index.php?topic=13207.0;wap2
23.02.37 Quit    Zambezi (Read error: Operation timed out)
23.02.38 #       <stripwax> lovasoa - specifically the bit that says "  VFAT uses UCS-2 to encode the filenames, you can't simply use utf8 "
23.02.43 Join    Zambezi [0] (Zulu@80.67.9.2)
23.03.23 Join    bluebrother [0] (~dom@rockbox/developer/bluebrother)
23.03.54 Quit    bluebroth3r (Read error: Operation timed out)
23.04.22 #       <sideral> AlexP: Not the one you made 3 minutes ago, the other one -- The Promise
23.07.21 #       <AlexP> I don't have some sort of weird ring if that is what you mean :)
23.07.35 #       <AlexP> That boat has long since sailed
23.07.54 #       <sideral> :)
23.08.02 #       <sideral> AlexP: "2011-01-22 (00:37:57) AlexP: sideral: btw, did you ever get the chance to look if tracks can be added to the db as and when?  I'll love you long time if that is possible :)"
23.08.21 #       <AlexP> oh right, that :)
23.08.59 #       <sideral> so, hurry up! ;)
23.10.38 #       <AlexP> hehe :)
23.14.14 #       <sideral> git heads, this may have scrolled by a little quickly in the heated discussion: 
23.14.14 #       <sideral> I'd like to commit FS#11880 (Include git commit ID in version string, as in "r29820+4406ff0-110505"). It concerns only us git users, no one else will notice and care. And it's in line with Torne's similar change for bzr. Any concerns?
23.14.35 #       <Torne> sideral: how many characters are you going to include?
23.14.47 #       <Torne> the number git decides is unique, or a fixed number?
23.15.11 #       <sideral> right now is "+", 7 digits, plus an "M" if the checkout was modified
23.15.40 #       <Torne> seems reasonable
23.15.56 #       <Torne> i suggest you do it
23.15.57 #       <Torne> :)
23.16.54 #       <pamaury> Torne: you changed something to have the bzr version ?
23.17.01 #       <Torne> yes, years ago :)
23.17.12 #       <sideral> git uses 40-digit hex hashes, but 7 digits will be sufficiently unique, especially as long as the latest svn revision is included as well. It could even be much shorter than 7 digits
23.17.18 #       <pamaury> ah ok, I thought it was recent :)
23.17.19 #       <Torne> if you use bzr-svn to work on rockbox and compile somethign that's not a svn version you get r12345+bzr5342-date
23.17.22 #       <Torne> or whatever
23.17.35 #       <Torne> so that my revision numbers are meaningful :)
23.18.32 #       <sideral> I chose 7 digits to have my version strings at the same length as Torne's ;)
23.18.42 #       <Torne> sideral: actually mine are typically 8
23.18.56 #       <Torne> so the git ones would be shorter
23.19.05 #       <sideral> dang
23.19.24 #       <AlexP> mine go to 11
23.19.25 #       <Torne> the bzr revnos are similar in magnitude to the svn ones
23.19.34 #       <Torne> (but different because my bzr repo only hast runk)
23.19.39 #       <Torne> so they're 5 digits, plus "bzr"
23.20.38 Join    ibhan [0] (~ibhan@109.56.19.181)
23.20.55 #       <sideral> I see. Anyway, I find it indispensable to have the git commit id included in my test builds. Before I did this, I often lost track of what I actually tested
23.22.25 #       <B4gder> we should have a test suite...
23.22.31 Part    jmaslibre ("ERC Version 5.3 (IRC client for Emacs)")
23.22.39 #       <Torne> sideral: yes, it's a very good thing, just commit it :)
23.23.05 #       <AlexP> Some sort of automated testing would be luverly
23.23.38 #       <B4gder> I would also agree that it would be more useful than switching version control
23.24.35 #       <Torne> right.
23.24.39 #       <AlexP> What sort of testing is envisaged?
23.24.42 #       <bluebrother> with the help of the sim we could test quite a lot of code
23.25.02 #       <sideral> I'd like to know if any of the git users would be concerned with the git commit ID in the version string
23.25.03 #       <Torne> There's two slightly seperate things we could do that come under the banner of "testing" here
23.25.08 #       <bertrik> I'm not really motivated to work on a test suite, to be honest
23.25.20 #       <AlexP> sideral: doesn't bother me
23.25.22 #       <Torne> we could start having actual tests that check rockbox works, which someone would have to write
23.25.34 #       <Torne> and seperately we could have a way to queue patches to be built by the build system
23.25.41 #       <Torne> with/without that also implying some actual testing
23.25.55 #       <AlexP> In related stuff, I'd like to have a test questionnaire for users for RCs
23.25.57 #       <Torne> both would be useful, and the effort required to implement the two are unrelated
23.26.07 #       <Torne> AlexP: that would definately be good
23.26.12 #       <bluebrother> AlexP: wasn't that proposed on the ML some time ago?
23.26.18 #       <Torne> yes, but nobody wrote it yet :)
23.26.22 #       <AlexP> bluebrother: It has come up a couple of times
23.26.30 #       <bluebrother> something to work on during devcon ;-)
23.26.39 #       <AlexP> I'll volunteer to have a bash at the questions
23.26.44 #       <bluebrother> hmm, we need to extend devcon to 2 months to get all things done ;-)
23.27.03 #       <AlexP> But it'd be nice to have a webpage for them to input it in
23.27.28 #       <AlexP> Torne: How would a patch builduing system work?
23.27.44 #       <bluebrother> well, that would basically one of those web based surveys
23.27.50 #       <AlexP> bluebrother: yeah
23.27.59 #       <Torne> AlexP: modify our current build system such that the master can tell teh slaves a diff as well as a revision number
23.27.59 #       <bluebrother> and there should be something around that we could use, shouldn't it?
23.28.08 #       <Torne> AlexP: and then seperate the results out somewhere different.
23.28.21 #       <Torne> AlexP: this also works very well tying into a patch review system :)
23.28.25 #       <AlexP> Torne: So devs could request test builds essentually?
23.28.28 #       <Torne> AlexP: yes.
23.28.35 #       <AlexP> sounds a good plan
23.28.39 #       <Torne> AlexP: and if you also have a patch review system you can have the test build results appear on the patch review
23.28.49 #       <AlexP> right
23.29.05 #       <pamaury> what would tests look like ? I mean, a huge of our code is hard to test
23.29.07 #       <AlexP> bluebrother: I'll wang it on the devcon agenda
23.29.18 #       <Torne> actual tests are orthogonal as i said :)
23.29.27 #       <Torne> just having a test build system that purely built things would have value
23.29.35 #       <Torne> one that also did some testing woul dbe better, of course
23.29.55 #       <B4gder> pamaury: we would start with testing the functions that are easy to test...
23.30.19 #       <pamaury> if there are easy to test, they will never break
23.30.27 #       <B4gder> that's not true
23.30.38 #       <Torne> the easiest way to do full UI tests, though maybe not the best, would be to automate the sim with a regular UI testing framework
23.30.39 #       <B4gder> tests also give people courage to rewrite and do larger changes
23.30.43 #       <bluebrother> AlexP: something like that maybe? http://www.limesurvey.org/
23.30.56 #       <Torne> we could do that without modifying our code at all
23.31.28 #       <Torne> the sim is just an app with normal input and output, there already exist UI test systems that can test that kind of stuff with varying degrees of cleverness :)
23.32.00 #       <Torne> doing anything intricate there would be tricky, probably, but you can test that, say, initialising the database with a particular set of files didnt' crash.
23.32.26 #       <AlexP> pamaury: Things may be easy to test, but it is impossible for a dev to test all tarrgets/combinations of features
23.32.38 #       <AlexP> And with an ever growing number of targets...
23.33.04 #       <AlexP> bluebrother: Yeah, something like that
23.33.22 #       <bluebrother> AlexP: hehe, that "web questionnaire" is also topic in the thread linked in the "Testing" entry above :)
23.33.23 #       <pamaury> I agree it's impossible and requesting a build on all targets is sensible. But beyong that, you need the real hardware
23.34.11 #       <bluebrother> pamaury: you can test almost all UI code without any hardware. We just need a stub target for that which implements all features
23.34.39 #       <bluebrother> "implement" as in "provides the functions, not the functionality"
23.34.51 Quit    TheLemonMan (Remote host closed the connection)
23.35.48 Part    ibhan
23.35.51 #       <pamaury> Ok, let me rephrase: what would these tests catch and would it be valuable ? That's a real question
23.36.15 #       <B4gder> pamaury: you never worked in a project with tests?
23.36.46 #       <B4gder> they are good at making sure things work as they are supposed to, when things are modified
23.37.06 #       <B4gder> if done right, they can work fine for debugging problems
23.37.32 #       <B4gder> like imagine a test set mounting a FAT image running our target fs code
23.37.44 #       <pamaury> I understand why tests are useful, but lots of our actual bugs/problems come from intricate hardware/software interaction
23.37.55 #       <B4gder> I have no doubts we'd be able to find and fix several bugs that way
23.38.26 #       <B4gder> pamaury: yes, and hw-related problems will still be there and will not be caught by tests that aren't on target
23.38.54 #       <TheSeven> that's where a second on-target driver test suite might come into play
23.39.08 #       <B4gder> true
23.39.24 #       <bertrik> writing tests will usually also make you aware of flaws in the specifications/intended features :)
23.39.57 #       <bluebrother> and it can prove if someone claims a functionality to work a specific way if it does (or not)
23.40.24 #       <TheSeven> that kind of on-hw tests would not only help doing regression testing, but also ease porting to new targets, as bugs can be caught at a way lower level
23.41.01 #       <TheSeven> e.g. I wouldn't have spent several days tracking down why codec performance was terrible on the ipod classic before I realized that there was actually a bug in the PCM driver
23.41.25 Join    ibhan [0] (~ibhan@109.56.19.181)
23.41.58 #       <pamaury> unfortunately there will always be cases like this one :-/
23.42.18 #       <bluebrother> sure, but minimizing the number of those cases is a good thing
23.42.18 #       <TheSeven> yeah, but that particular one could have been caught really easily
23.42.25 #       <bluebrother> and it's doable :)
23.42.49 #       <TheSeven> the question is whether it's worth the effort, but I'm fairly sure it is...
23.43.02 Quit    n17ikh (Ping timeout: 240 seconds)
23.43.51 #       <bluebrother> I'm pretty sure it's worth it.
23.44.23 #       <bluebrother> my personal feeling is that Rockbox has become less stable and more buggy in the last years.
23.44.52 #       <bluebrother> and since it's kinda feature complete (what features are really missing?) improving quality should really become a goal
23.45.05 #       <bluebrother> (as in: become even more a goal than it is these days)
23.49.50 Quit    Staphylo (Ping timeout: 240 seconds)
23.55.45 Quit    domonoky (Read error: Connection reset by peer)
23.57.19 Join    n17ikh [0] (~n17ikh@c-68-59-25-51.hsd1.sc.comcast.net)
23.58.10 Part    ibhan ("ERC Version 5.3 (IRC client for Emacs)")