--- Log for 17.06.112  Server: kornbluth.freenode.net  Channel: #rockbox
--- Nick: logbot_  Version: Dancer V4.16  Started: 2 days and 0 hours ago

00.03.29 Join    domonoky [0] (~Domonoky@rockbox/developer/domonoky)
00.05.29 Quit    Elfish (Ping timeout: 264 seconds)
00.06.39 Join    GermanMushroom [0] (~c@s5146db6a.adsl.wanadoo.nl)
00.07.26 Join    Thra11_ [0] (~thrall@84.93.154.59)
00.07.50 Quit    Thra11 (Read error: Connection reset by peer)
00.12.39 Join    mystica555_ [0] (~Mike@97-118-131-45.hlrn.qwest.net)
00.14.25 Join    Elfish [0] (amba@2a01:4f8:100:90a1:abc:abc:abc:abc)
00.20.09 Quit    petur (Quit: Leaving)
00.23.47 Quit    Thra11_ (Read error: Connection reset by peer)
00.24.00 Join    Thra11 [0] (~thrall@84.93.154.59)
00.34.13 Join    Horscht [0] (~Horscht@p5DD57E43.dip.t-dialin.net)
00.34.14 Quit    Horscht (Changing host)
00.34.14 Join    Horscht [0] (~Horscht@xbmc/user/horscht)
01.01.58 Quit    ciscon (Ping timeout: 246 seconds)
01.02.39 Quit    zu (Quit: leaving)
01.04.25 Quit    n1s (Quit: Ex-Chat)
01.06.50 #       <bertrik> has anyone tried to use the clang static code analyzer?
01.07.03 #       <bertrik> (as far as I understand, this is different from using clang as a compiler)
01.10.32 Join    enthdegree [0] (~enthdegre@wikimedia/enthdegree)
01.17.23 ***     Saving seen data "./dancer.seen"
01.22.46 Quit    Wardo (Read error: Connection reset by peer)
01.24.56 Quit    liar (Ping timeout: 246 seconds)
01.27.04 Join    liar [0] (~liar@clnet-p09-185.ikbnet.co.at)
01.42.28 Quit    lebellium (Quit: ChatZilla 0.9.88.2 [Firefox 14.0/20120612164001])
01.50.41 Quit    Elfish (*.net *.split)
01.50.41 Quit    Riviera (*.net *.split)
01.52.51 Join    Elfish [0] (amba@fuplz.co.cc)
01.55.29 Quit    Thra11 (Remote host closed the connection)
01.59.53 Quit    bertrik (Ping timeout: 260 seconds)
02.02.19 Quit    domonoky (Read error: Connection reset by peer)
02.10.37 Quit    Rower85 (Quit: Hmmm...)
02.32.49 Quit    liar (Ping timeout: 246 seconds)
02.39.12 Join    Riviera [0] (~Riviera@92.51.147.16)
02.43.54 Join    perrikwp [0] (~quassel@cpe-071-076-186-186.triad.res.rr.com)
02.49.54 Quit    [Saint] (Remote host closed the connection)
02.51.48 Join    JdGordy [0] (~jdgordon@rockbox/developer/JdGordon)
02.52.02 Join    [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940)
03.00.37 Quit    JdGordy (Read error: Connection reset by peer)
03.01.54 Join    JdGordy [0] (~jdgordon@rockbox/developer/JdGordon)
03.04.07 Quit    JdGordy (Read error: Connection reset by peer)
03.07.01 Join    JdGordy [0] (~jdgordon@rockbox/developer/JdGordon)
03.09.06 Quit    JdGordy (Read error: Connection reset by peer)
03.12.11 Join    JdGordy [0] (~jdgordon@rockbox/developer/JdGordon)
03.14.33 Quit    JdGordy (Read error: Connection reset by peer)
03.17.24 ***     Saving seen data "./dancer.seen"
03.32.47 Join    webguest56 [0] (~46be935b@www.haxx.se)
03.33.48 #       <webguest56> I want to watch a movie on my mp3 player, but I want to put them in gzip files so they take up less space on my 8gb drive.
03.34.11 #       <webguest56> The only way I can think of to do that is the lua plugin.
03.34.40 #       <[Saint]> Lua has integrated gzip now?
03.34.41 #       <webguest56> Is there an implementation of gzip in lua
03.34.43 #       <webguest56> ?
03.34.46 #       <webguest56> No.
03.35.07 #       <[Saint]> Yeah, sorry. That wasn't really a question.
03.35.23 #       <webguest56> I  was wondering if there is a gzip-reading program, written in lua, that I could use on rockbox.
03.35.43 #       <[Saint]> Nope.
03.35.53 #       <webguest56> Oh.
03.35.57 #       <webguest56> OK.
03.36.03 #       <webguest56> Thanks anyway.
03.36.11 Quit    webguest56 (Client Quit)
03.37.53 Quit    GermanMushroom (Ping timeout: 260 seconds)
03.55.10 Join    zu [0] (~zu@ks387228.kimsufi.com)
04.02.47 Quit    copper (Ping timeout: 246 seconds)
04.03.03 Join    TheSphinX^ [0] (~briehl@p5B323517.dip.t-dialin.net)
04.03.44 Join    copper [0] (~copper@sd-12090.dedibox.fr)
04.03.45 Quit    copper (Changing host)
04.03.45 Join    copper [0] (~copper@unaffiliated/copper)
04.04.09 Quit    TheSphinX_ (Read error: Operation timed out)
04.20.50 Join    eckoit [0] (~ryan@50.65.10.24)
04.38.33 Quit    amiconn (Disconnected by services)
04.38.33 Join    amiconn_ [0] (amiconn@rockbox/developer/amiconn)
04.38.37 Nick    amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn)
04.40.41 Quit    pixelma (Disconnected by services)
04.40.41 Join    pixelma_ [0] (pixelma@rockbox/staff/pixelma)
04.40.43 Nick    pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma)
04.44.45 Quit    TheSeven (Disconnected by services)
04.44.47 Join    [7] [0] (~quassel@rockbox/developer/TheSeven)
04.48.47 Quit    prof_wolfff (Ping timeout: 246 seconds)
05.11.09 Quit    jfc (Ping timeout: 240 seconds)
05.17.28 ***     Saving seen data "./dancer.seen"
05.24.09 Join    jfc [0] (~john@stat-bng-72-73-80-12.ngn.east.myfairpoint.net)
05.38.04 Quit    eckoit (Quit: eckoit)
05.42.57 Join    Horschti [0] (~Horscht@p57B57C38.dip.t-dialin.net)
05.42.57 Quit    Horschti (Changing host)
05.42.57 Join    Horschti [0] (~Horscht@xbmc/user/horscht)
05.43.47 Join    eckoit [0] (~ryan@50.65.10.24)
05.46.49 Quit    Horscht (Ping timeout: 260 seconds)
05.48.49 Quit    enthdegree (Quit:  HydraIRC -> http://www.hydrairc.com <-)
06.24.35 Join    kevku [0] (x@heaaqi4aafadxhrbshyaidz32e4.dyn.reverse.name)
06.25.24 Quit    anewuser ()
06.42.36 Join    Keripo [0] (~Keripo@c-50-135-159-85.hsd1.wa.comcast.net)
07.17.30 ***     Saving seen data "./dancer.seen"
08.29.07 Quit    Keripo (Quit: Leaving.)
08.32.20 Join    BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey)
08.45.28 Join    stoffel [0] (~quassel@pD9E41F68.dip.t-dialin.net)
09.15.59 Join    n1s [0] (~n1s@nl118-175-223.student.uu.se)
09.15.59 Quit    n1s (Changing host)
09.15.59 Join    n1s [0] (~n1s@rockbox/developer/n1s)
09.17.33 ***     Saving seen data "./dancer.seen"
09.29.35 Join    TheLemonMan [0] (~LemonBoy@adsl-ull-135-220.50-151.net24.it)
09.42.28 Join    bertrik [0] (~bertrik@rockbox/developer/bertrik)
09.49.35 Join    pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net)
09.49.36 Quit    pamaury (Changing host)
09.49.36 Join    pamaury [0] (~quassel@rockbox/developer/pamaury)
09.50.39 Join    Ward [0] (~Mirandaha@bpb01-1-88-162-4-186.fbx.proxad.net)
09.51.03 Nick    Ward is now known as Guest97185 (~Mirandaha@bpb01-1-88-162-4-186.fbx.proxad.net)
10.07.11 Join    liar [0] (~liar@clnet-p09-185.ikbnet.co.at)
10.08.39 Join    mortalis [0] (~mortalis@77.108.98.177)
10.09.53 Quit    ruskie (Quit: ...)
10.15.47 Quit    n1s (Read error: Connection timed out)
10.16.14 Join    n1s [0] (~n1s@nl118-175-223.student.uu.se)
10.16.15 Quit    n1s (Changing host)
10.16.15 Join    n1s [0] (~n1s@rockbox/developer/n1s)
10.20.33 Quit    [Saint] (Remote host closed the connection)
10.25.12 Join    [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940)
10.27.33 Quit    [Saint] (Read error: Connection reset by peer)
10.27.39 Join    [Saint_] [0] (~Saint]@unaffiliated/saint/x-8516940)
10.36.10 Join    mirak [0] (~mirak@89-92-229-26.hfc.dyn.abo.bbox.fr)
10.38.33 Join    Aliveee [0] (~alive-666@37.112.200.168)
10.39.02 #       <Aliveee> привет, на русском тут общаются?
10.39.33 #       <copper> +1
10.40.12 Join    lebellium [0] (~chatzilla@g231086116.adsl.alicedsl.de)
10.40.39 Join    ruskie [0] (ruskie@sourcemage/mage/ruskie)
10.41.54 Quit    lebellium (Client Quit)
10.42.18 Join    lebellium [0] (~chatzilla@g231086116.adsl.alicedsl.de)
10.44.07 Quit    n1s (Read error: Connection timed out)
10.45.25 Part    Aliveee
10.45.34 Join    Aliveee [0] (~alive-666@37.112.200.168)
10.45.40 Part    Aliveee
10.45.53 Quit    BHSPitMonkey (Remote host closed the connection)
10.52.25 Quit    stoffel (Ping timeout: 265 seconds)
11.01.26 Join    fyre^OS [0] (~nnscript@cpe-24-90-87-68.nyc.res.rr.com)
11.04.07 Quit    fyrestorm (Ping timeout: 246 seconds)
11.17.37 ***     Saving seen data "./dancer.seen"
11.18.39 Quit    [7] (Ping timeout: 244 seconds)
11.23.25 Join    webmind [0] (~webmind@2a02:898:109::198:1)
11.23.28 #       <webmind> good morning
11.23.53 #       <webmind> I'm trying to convert a ttf font to fnt, but it seems to clip the upper bit of the font a little
11.24.07 #       <webmind> is there a way of fixing that?
11.29.45 #       <bluebrother> check the options to convttf
11.30.14 #       <bluebrother> maybe specifying a different font size helps
11.31.15 Quit    TheLemonMan (Quit: WeeChat 0.3.8)
11.31.15 #       <webmind> I tried 8 and 15
11.31.17 #       <webmind> same problem
11.32.07 #       <webmind> I'll try a few more
11.32.15 Join    TheSeven [0] (~quassel@rockbox/developer/TheSeven)
11.32.41 #       * bluebrother is not too familiar with convttf
11.32.55 #       <webmind> hm
11.33.09 #       <webmind> it's only the capitals it seems that cut off a few pixels
11.33.38 #       <webmind> also on sizes 14 and 12
11.33.41 Join    Rower85 [0] (husvagn@v-413-alfarv-90.bitnet.nu)
11.43.54 #       <[Saint_]> webmind: you must manually adjust the ascent and descent values.
11.44.17 #       <[Saint_]> Run convttf without arguments for a list of accepted flags.
11.46.05 #       <[Saint_]> As a helper, set the flag to review output in the terminal...so you don't have to run it on target or in a sim just to see you e fucked up (which gets tiring real quick, I know)
11.46.16 Join    TheLemonMan [0] (~LemonBoy@adsl-ull-135-220.50-151.net24.it)
11.46.53 #       <[Saint_]> You'll get the hang of it.
11.48.27 Join    prof_wolfff [0] (~prof_wolf@82.159.1.234.dyn.user.ono.com)
11.53.19 Quit    liar (Quit: huiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii)
12.15.23 Join    xnamkcor [0] (~xnamkcor@ip72-223-94-26.ph.ph.cox.net)
12.16.57 #       <xnamkcor> The website says the way to tell if I have a Clip v1 or v2 is the firmware version number, but since I've installed Rockbox I have forgotten which I have and the firmware version is no longer "01" or "02". Is there a Way to tell which I have?
12.17.36 #       <[Saint_]> Boot the original firmware.
12.17.49 #       <[Saint_]> Consult the manual for this.
12.19.10 #       <[Saint_]> (Iirc, its holding left during boot...but it sounds like you should probably look over the manual anyway)
12.21.38 #       <xnamkcor> Looks like it tries and then it says it's upgrading the firmware. I think I left the firmware update files on there.
12.23.09 #       <bluebrother> if you have Rockbox installed you can simply check in /.rockbox/rockbox-info.txt
12.24.46 #       <[Saint_]> Well...he doesnt have it installed anymore :)
12.24.56 #       <[Saint_]> But the file will still be there.
12.25.30 #       <[Saint_]> Also, doesn't that only apply to rbutil (likelyin this instance) installs?
12.26.59 #       <bluebrother> no
12.27.10 #       <bluebrother> rockbox-info.txt is part of rockbox.zip
12.27.19 #       <bluebrother> there's rbutil.log which is specific for Rockbox Utility
12.27.29 #       <[Saint_]> Oh, whoops...I guess it depends if its an unmodified firmware file sitting on the disk or not. 
12.27.30 #       <bluebrother> which holds all files and versions it installed
12.28.30 #       <[Saint_]> bluebrother: aha, right. I mixed up rbutil.log and rockbox-info
12.29.39 #       <[Saint_]> In that case, I guess simply plugging it in and letting rbutil autodetect would tell which version it is. I forgot about this.
12.30.29 #       <bluebrother> clip and clipv2 also have different USB IDs.
12.31.13 #       <xnamkcor> Time to download RBUtil again then.
12.32.09 #       <bluebrother> hmm. If you use a wrong string in the unit test the test is unlikely to pass, even if the code tested is correct :o
12.32.25 #       <[Saint_]> You don't have to, do you? Firmware installation doesn't wipe the disk.
12.33.25 #       * bluebrother isn't sure he's really understanding the problem right now
12.33.55 #       <bluebrother> since Rockbox is installed simply check rockbox-info.txt on th eplayer
12.34.11 #       <xnamkcor> Sansa Clip (Stable)
12.34.18 #       <bluebrother> it's a simple text file, so no need for any fancy tools. You can even do that using the text editor plugin
12.34.19 #       <xnamkcor> so I guess I have v1
12.34.44 #       <bluebrother> yes, the v2 is "Sansa Clip V2"
12.35.14 #       <xnamkcor> I should probably do an update while I have the utility open.
12.35.36 #       <[Saint_]> Now for the magic question: "why was this important?" :-)
12.37.24 #       <xnamkcor> Because the theme section is split into v1 and v2 sections. I didn't want to download a theme for the wrong device.
12.37.26 #       <bluebrother> for the sake of knowing it?
12.37.48 #       <bluebrother> you can download themes using Rockbox Utility btw :)
12.38.02 #       <bluebrother> and all themes for v1 should also work on v2
12.38.25 #       <[Saint_]> xnamkcor: the theme section for v1 and v2 are identical.
12.38.40 #       <[Saint_]> Its actually sorted by screen type, not player type.
12.39.00 #       <bluebrother> [Saint_]: not exactly :)
12.39.10 #       <[Saint_]> So, you can happily install a v1 theme on a v2 device.
12.39.26 #       <bluebrother> it's sorted by player, and the themes are checked against the players
12.39.58 #       <[Saint_]> What? I thought it was sorted only by resolution?
12.40.03 #       <bluebrother> but since clip v1 and v2 are pretty much identical in that area (same screen size, same list of supported tags) ...
12.40.22 #       <bluebrother> no. Sorting by resolution was the old themesite. Like 3 years ago (or even more?)
12.40.51 #       <[Saint_]> Fuck me...I've been here too long. :)
12.41.04 #       <bluebrother> the problem is that some themes _would_ be compatible screensize-wise, but are rejected by the theme loader due to unsupported wps tags
12.41.15 #       <bluebrother> like RTC supported in one device but not another
12.41.21 #       <[Saint_]> Errrr ..."twiddle-dee-dee", I mean.
12.41.31 #       <bluebrother> mrobe100 has a RTC, h100 doesn't. But IIRC they have the same screen size
12.41.43 #       <bluebrother> so a mr100 theme is not necessarily compatible with h100
12.41.53 #       <[Saint_]> That shouldn't matter...if the theme is coded properly.
12.42.01 #       <xnamkcor> I should probably backup my files before I update, right?
12.42.03 #       <bluebrother> so you upload a theme, the themesite runs checkwps against it :)
12.42.09 #       <[Saint_]> That's bloody broken. People should just not code busted themes.
12.42.32 #       <[Saint_]> That's why there's checks for the likes OFRTC and friends in the skin tags :)
12.42.38 #       <bluebrother> xnamkcor: depends on which files. If you have a really old installation of Rockbox it might make sense backing that up. For music files it's not necessary.
12.43.01 #       <bluebrother> unless you're using the Sandisk firmware upgrade, no idea if that harms the disk (though I doubt it)
12.43.20 #       <bluebrother> [Saint_]: maybe, but there was a time when that wasn't there
12.44.07 #       <xnamkcor> It's only 2GB. Shouldn't take long over USB 2.0. I could go get a drink in the time that takes. Might as well
12.44.09 #       <[Saint_]> I absolutely cannot think of an instance where hardware differences couldn't be negated by proper coding of the theme.
12.45.11 Join    domonoky [0] (~Domonoky@rockbox/developer/domonoky)
12.45.36 #       <xnamkcor> If two devices have the same resolution but only one had HW support for OGL 4.x and the theme depends on OGL 4.x. Though that's a really bad non-existant example.
12.46.25 #       <[Saint_]> Yrs, lets stick to examples that exist :)
12.47.27 #       <Torne> probably the only really problematic one is themes designed for touchscreens
12.47.41 #       <Torne> which happen to be the same resolution as a nontouchscreen.
12.47.45 #       <[Saint_]> There's checks for touch, recording, FM, ...which is all I can think of at present that would matter. And if the theme includes one of these tags but not a false case for it, it will just never go true...so its ignored and irrelevant.
12.48.06 #       <Torne> right, but even if you check for touch support, i'd expect you to end up to basically need to make two different themes anyway
12.48.52 #       <[Saint_]> My touchscreen 240x320 theme runs happily on both. Its posssible, and easily so, with "correct" coding.
12.49.20 #       <Torne> but does it make optimal use of the available screen space on both, i mean
12.49.32 #       <[Saint_]> It does indeedy.
12.49.58 #       <xnamkcor> I think the Clip+ has the same resolution as the Vlip, but Clip+ can run Doom, while Clip cannot. So there might be a problem if the theme uses too much ram or cpu power.
12.50.12 #       <[Saint_]> No.
12.50.36 #       <[Saint_]> Its just a RAM issue art: Doom
12.50.41 #       <[Saint_]> *wrt
12.51.05 #       <Torne> we dynamically allocate the skin buffer these days, right?
12.51.15 #       <[Saint_]> Yep.
12.51.39 #       <Torne> so yeah.
12.52.29 #       <[Saint_]> Themes have been smart enough to (for instance) not load an .fms if there's no FM support, or not load an .reps if there's no remote, also.
12.52.42 #       <[Saint_]> +for ages now.
12.53.17 #       <[Saint_]> Bah! Stupid keyboard. *rwps
12.53.46 #       <[Saint_]> So...I'm really not understanding why themes are split into device type.
12.53.47 #       <xnamkcor> Someday I'll update my player and I'll be able to play Doom on it. Until then I will have to settle with only being able to play Doom on my PC, PSP, PS2, WM6.x phone, and Android tablet
12.54.08 #       <[Saint_]> Especially as the hardware checks I mentioned have existed for years.
12.54.11 #       <xnamkcor> for safety reasons we don't realise now but may exist regardless?
12.54.29 #       <xnamkcor> Or for neat sorting?
12.54.48 #       <[Saint_]> xnamkcor: nah....I'm pretty sure its some now irrelevant edge case :)
12.55.34 #       <[Saint_]> I'd love to be wrong, if there's a hardware difference between targets that I can't code my way out of or sane checks can't pick up on...I'd like to know about it.
12.55.35 #       <xnamkcor> Updating Rockbox is so simple it's almost confusing. I downloaded the latest version and then it rbutil downloads it automatically anyway
12.57.46 #       <xnamkcor> Success. And nothing died or caught on fire. Thanks
13.03.38 #       <xnamkcor> The "Record" Option has the potential to be used as a hearing aid, but a hardware "feature" or flaw makes it so I can head my fingers rubbing on the player long before I can amplify any distant sound.
13.04.45 #       <CIA-47> Commit 94555a0 in rockbox by 03Dominik Riebeling: Move download URL construction to ServerInfo.
13.04.46 #       <CIA-47> Commit d3ddad9 in rockbox by 03Dominik Riebeling: Read release candidate information from build-info.
13.04.46 #       <CIA-47> Commit a3d9ace in rockbox by 03Dominik Riebeling: Support release-candidate entry format for releases.
13.04.47 DBUG    Enqueued KICK CIA-47
13.04.47 #       <CIA-47> Commit 14727b1 in rockbox by 03Dominik Riebeling: Implement unit test for ServerInfo input parsing.
13.04.48 #       <CIA-47> Commit 9760d41 in rockbox by 03Dominik Riebeling: Make ServerInfo parsing slightly more robust.
13.04.58 #       <[Saint_]> Its no feature. Just a crappy internal mic.
13.05.13 #       <[Saint_]> Not at all designed to pick up sound at a distance.
13.05.47 #       <[Saint_]> The case also makes a fine chamber to amplify the sounds of anything touching the car.
13.05.57 #       <[Saint_]> s/car/case/
13.06.20 #       <xnamkcor> My old Zen Microphoto was pretty good mic-wise. I could turn it on and leave it in my pocket and it recorded anything I could hear, but it had no live monitoring feature. So it was worthless as hearing aid.
13.07.02 #       <CIA-47> 9760d41 build result: All green
13.07.24 #       <xnamkcor> maybe I can open up the Clip and see how hard it would be to make a more external mic setup. Or something.
13.09.29 #       <[Saint_]> Its actually very possible le to hack the mic on these to an external 3.5mm mono jack.
13.11.13 #       <[Saint_]> I seem to recall seeing a walkthrough for this...somewhere. its trivial, anyway. basically being able to solder a fine pitch and drill a hole + $5 of materials.
13.13.18 #       <xnamkcor> I'd probably use 2.5mm but I'll look that up.
13.16.06 #       <xnamkcor> If I were more adventurous I would go all out and redo the eraphone jack as a 3.5mm TRRS connector
13.17.12 #       <[Saint_]> This is sliding offtopic, but, that's probably quite possible also. Though somewhat more involved.
13.17.40 ***     Saving seen data "./dancer.seen"
13.17.49 #       <xnamkcor> I wonder why TRRS isn't more popular of a connector with high end earphones
13.18.19 #       <xnamkcor> In any case. Thanks for the help. I'm gonna go to sleep now.
13.18.57 Part    xnamkcor ("Leaving")
13.42.05 Join    anewuser [0] (~anewuser@190.207.133.120)
13.42.06 Quit    anewuser (Changing host)
13.42.06 Join    anewuser [0] (~anewuser@unaffiliated/anewuser)
13.47.56 #       <bertrik> is there a check to verify that all file descriptors are really closed when USB is connected?
13.50.39 Join    Thra11 [0] (~thrall@146.90.92.230)
13.51.10 #       <gevaerts> I don't think there is
13.51.16 #       <gevaerts> Hm,
13.51.20 #       <gevaerts> maybe I'm wrong
13.52.00 Join    amithkk [0] (u4289@2buntu/writers/amithkk)
13.52.11 #       <gevaerts> Yes
13.52.44 #       <gevaerts> disk_unmount() calls release_files(), which marks file descriptors as closed
13.56.32 Nick    amithkk is now known as amith (u4289@2buntu/writers/amithkk)
13.56.36 #       <bertrik> hm, but we don't really do anything about it, except just mark it as closed, we're not really closing the files or warning about it
13.56.46 Nick    amith is now known as amithkk (u4289@2buntu/writers/amithkk)
13.57.03 #       <Torne> yah, it'sjust a last resort to ensure that if something tries to use the filehandle it'll fail
14.02.18 Ctcp    Ignored 1 channel CTCP requests in 0 seconds at the last flood
14.02.18 #       * [Saint_] wants to know some more about this themesite madness
14.03.17 #       <[Saint_]> I guess its too much to ask for authors to consider cases for hardware they don't own. Even if they should.
14.03.34 #       <[Saint_]> Though, even if they didn't it should 'just air's.
14.03.48 #       <[Saint_]> Ummm...*just work
14.04.03 #       <AlexP> I think it is too much to ask, yes
14.04.14 #       <AlexP> People tend to make themes for their own devices
14.04.51 #       <AlexP> If we said you can't share this until you have made it work for all other possible ones of the same res (with different features/touchscreen etc) then most people I would guess would just not bother to share
14.05.26 #       <AlexP> And I don't blame them
14.05.41 #       <[Saint_]> The thing is...is should *just work*.
14.05.51 #       <[Saint_]> Without any special coding at all.
14.06.28 #       <[Saint_]> Cases for tags that the device doesn't support will just be ignored if no false case isgiven.
14.06.50 #       <AlexP> That doesn't mean it'll work, either at all (e.g. touchscreen) or look how the author intended
14.07.08 #       <AlexP> It may work as in not fail/not load, but that isn't the same as work in my book
14.07.34 #       <[Saint_]> Why would touchscreen matter?
14.07.52 #       <[Saint_]> Iirc it defaults to grid mode if no touch tags are present.
14.07.59 #       <AlexP> If you write a skin for non-touchscreen and then try to use it on a touchscreen of the same res it would not be useable
14.08.08 #       <AlexP> grid mode is not useable
14.08.17 #       <AlexP> Not unless you are specifically looking for it
14.08.47 #       <[Saint_]> That's subjective. And most targets have some form of hw navigation keys also.
14.08.51 #       <AlexP> If the theme site said "This theme works on touchscreen" then you would not expect on installing it that it would switch to some obscure grid mode that you probably know nothing about
14.09.21 #       <AlexP> I would fight hard against us offering that, it is massivly user unfriendly
14.10.10 #       <[Saint_]> Its seems weird to differentiate against themes that would otherwise load happily to me.
14.10.38 #       <[Saint_]> Andorra touch is the only instance...that's one thing. FM and recording shouldn't matter at all.
14.10.44 #       <[Saint_]> *and if
14.10.52 #       <AlexP> Yes, it is a shame when it means that a theme that would work isn't offered, but it guards against offering a theme that *technically* works, but is not as intended/really useable
14.11.24 #       <AlexP> What might be handy is if themes for target a could be flagged by users/devs/whoever as also working fine on target b
14.13.17 #       <[Saint_]> I don't think switching to grid mode would be an issue if we informed the user about it. Which we don't do, and probably should.
14.13.46 #       <AlexP> I think it would
14.13.48 #       <[Saint_]> "No touchscreen support in theme: switching to grid mode" etc.
14.13.54 #       <AlexP> Not nice
14.13.58 Join    n1s [0] (~n1s@rockbox/developer/n1s)
14.14.17 #       <AlexP> I think (and yes, no way to prove it) that most users would consider grid mode largely unuseable
14.14.41 #       <[Saint_]> It at least let's the use know what happened. We switch to grid mode if the fallback loads without telling the use what happened and expect them to deal with that.
14.14.50 #       <[Saint_]> *the user
14.15.07 #       <AlexP> Yes, and that isn't nice either
14.15.23 #       <AlexP> But because we do one not nice thing doesn't mean we should do another
14.15.34 #       <AlexP> It instead says we should improve the first not nice thing
14.18.11 #       <[Saint_]> Another (admittedly edge case) thing is that a user might specifically load a non-touch theme on a touch device because their target allows for hw button navigation. And presently although that would be perfectly well and good, iiuc, the themesite wouldn't allow said theme to be displayed as compatible.
14.19.23 #       <AlexP> If someone is doing that I feel they are capable of downloading it from the page for another device and installing manually
14.19.25 #       <[Saint_]> A good example is the phone I'm on now, its touchscreen, but I never us the touchscreen if its avoidable as I have a nice hw dpad (like many touchscreen DAPs do)
14.19.37 Join    pandrew [0] (~andrew@86.125.234.246)
14.19.41 #       <AlexP> A pain I agree, but it depends who we are trying to "protect"
14.19.59 #       <AlexP> And I feel we should make it easier for the less advanced rther than the more advanced user
14.20.11 #       <[Saint_]> Yeah, this is a bit of a ness with no clean way out..  :-(
14.20.30 #       <[Saint_]> *mess, even.
14.20.31 #       <bertrik> I would like some kind of notification if we mark open files as closed. We're now basically *hiding* a potential problem
14.20.57 #       <bertrik> a panic is probably too harsh, but a splash perhaps
14.21.45 #       <[Saint_]> bertrik: there's quite a few instances where a splash would be nice.
14.21.58 #       <bertrik> A quick check currently shows no open files in a "happy-flow" scenario, BTW
14.22.14 #       <bertrik> [Saint_], ok, which other ones?
14.22.33 #       * bertrik thinks about a kind of syslog
14.22.44 #       <bertrik> we have logf, but that's a compile-time decision IIRC
14.23.20 #       <[Saint_]> I mentioned one earlier where if the fallback theme is loaded on a touchscreen device there's no indication to the user that the touch mode changed.
14.23.37 #       <[Saint_]> It's not unsafe, but its non-obvious and annoying.
14.23.57 #       <AlexP> bertrik is talking about things to indicate problems in the code though IIRC
14.24.01 #       <AlexP> Which is quite different
14.25.31 #       <AlexP> *IIUC
14.25.45 #       <[Saint_]> Right. My point was more that we're a little slack on notifying the user about potentially important happenings.
14.26.05 #       <AlexP> Splashes are hugely annoying and show be used with extreme reluctance IMO
14.26.42 #       <Torne> they're also easy to miss
14.26.46 #       <[Saint_]> I thought of another instance a few days ago...and I told myself to write it down, dammit. It'll pop up again if it annoyed me that much.
14.26.48 #       <bertrik> true
14.26.53 #       <Torne> if they don't happen while you are actually looking
14.27.26 #       <[Saint_]> You could make the user need to dismiss it, were it truly of importance.
14.28.44 #       <[Saint_]> I think the touchscreen mode changing should be splashed, as if its a broken theme that caused the fallback to load, loading a non-broken theme wont "fix" it.
14.28.48 #       <AlexP> I'd dismiss a sticky splash by throwing it out the window
14.28.48 #       <pandrew> hey guys! is it possible to get a stack trace somehow on a Data Abort exception?
14.29.19 #       <[Saint_]> Then the user now wonders why their touchscreen is "broken".
14.29.26 #       <bertrik> pandrew, I think we already have that, on ARM
14.30.31 #       <pandrew> bertrik: i have an arm target (ipodvideo), how should i go about getting that stack trace?
14.30.32 #       <bertrik> but I think there are cases we can't completely reconstruct the stack trace
14.30.41 #       <Torne> pandrew: it just displays it on the screen when it crashes, if you have a new enough version
14.30.45 #       <Torne> though the display is only the addresses.
14.31.00 #       <Torne> since keeping all the symbols would use a bunch of memory :)
14.31.12 #       <Torne> i forget exactly when it was added, but it's been in a while
14.31.23 Quit    untrack (Read error: Connection reset by peer)
14.31.25 #       <pandrew> Torne: bertrik: i'm using the newest GIT version, compiled with Debug support. but i'm only seeing the top of the stack
14.31.34 #       <[Saint_]> This year...sometime, iirc.
14.31.36 #       <Torne> it unwinds it as far as the unwinder can manage.
14.31.48 #       <Torne> it's doing it using a weird trick that cannot unwind all possible code
14.31.54 #       <pandrew> all i can see is that it fails inside strchr()
14.31.58 #       <Torne> if that's not enough then probably we have a function that's confusing it
14.32.09 #       <Torne> hm
14.32.12 #       <Torne> that shouldn't be confusing it :)
14.32.16 #       <Torne> what exactly does the screen say?
14.32.29 #       <bertrik> can you reproduce it easily? and in a simulator too?
14.35.13 #       <pandrew> i can reproduce it easily on the ipod. 1) Make an extra long playlist 2) Open it from Playlist Catalogu 3) scroll down really fast.   Result is: Data abort at 00054D98 (0)\n bt pc: 00054D98, sp: 4000AA18\b bt end
14.35.42 #       <pandrew> i can't reproduce it on the simulator, because i can't scroll that fast on the simulator
14.35.51 #       <[Saint_]> How long is "extra long"?
14.36.12 #       <Torne> if that PC is in strchr i would guess the stack is corrupt
14.36.19 #       <Torne> which explains both the abort and the failure to unwind
14.38.52 #       <pandrew> [Saint_]: extra long is 2120 songs , in my case
14.39.08 #       <Torne> that's not particularly long
14.39.42 #       <Torne> anyway. unfortunately we can't always produce a backtrace; soemtimes because the code is too difficult to unwind but more often because the crash is caused by data on the stack having been corrupted ;?
14.39.52 #       <[Saint_]> I can't get RaaA to choke on 20K tracks.
14.40.10 #       <Torne> and strchr is kinda a generic one :/
14.40.12 #       <Torne> so that might be tricky
14.40.35 #       <gevaerts> [Saint_]: what sort of playlist? Dynamic, or m3u?
14.41.20 #       <[Saint_]> Formerly dynamic, saved to disk, so .m3u one supposes
14.44.12 Join    stoffel [0] (~quassel@pD9E4382E.dip.t-dialin.net)
14.46.10 #       <pandrew> i don't know if it's relevant but many of the song tags contain Hungarian characters
14.46.54 #       <pandrew> i don't think it should be relevant, because the bug can only be reproduced when scrolling really fast
14.49.43 Join    untrack [0] (utrack@199.127.226.22)
14.56.05 Quit    [Saint_] (Remote host closed the connection)
14.58.22 Join    [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940)
14.58.29 #       <pandrew> it looks like i'm having a different problem too with my self-compiled git head. i'm getting Codec: cannot read file errors, when i'm trying to play back some mp3 files.
14.59.15 #       <[Saint]> Time for fsck methinks
14.59.50 #       <Torne> how are you installing your build?
15.00.44 #       <pandrew> extracting the .zip in the root directory
15.03.46 Quit    zu (Quit: leaving)
15.05.52 Join    zu [0] (~zu@ks387228.kimsufi.com)
15.07.35 #       <bertrik> we *could* be a bit more robust about slightly messed up file systems
15.08.30 Join    wodz [0] (~wodz@89-76-160-35.dynamic.chello.pl)
15.09.14 #       <wodz> bertrik: From time to time someone passes our codebase through clang static analyzer and a few bugs was discovered this way IIRC
15.09.57 #       <wodz> Torne: Have you seen my question about relocations?
15.15.02 #       <pandrew> fsck reported no errors, and didn't help. http://purdea.ro/volatile/rockbox.zip (this is ipod video)
15.17.00 #       <pandrew> this was a clean compile from GIT head
15.17.43 ***     Saving seen data "./dancer.seen"
15.21.44 #       <[Saint]> Obvious question: have you a - tested the release? b - tried a current build from our build system, c - managed to bisect the offending revision?
15.26.48 #       <[Saint]> a and b are useful for determining whether its tour problem or a problem in general, and for helping to find a min/max known good revision for c if it is a general problem
15.27.02 #       <[Saint]> *your problem
15.33.22 Quit    stoffel (Ping timeout: 244 seconds)
15.37.31 #       <CIA-47> Commit cd1b6a1 in rockbox by 03Marcin Bukat: Fix cabbiev2 on iaudio x5 remote
15.39.14 #       <CIA-47> cd1b6a1 build result: All green
15.39.33 Quit    Beta2K (Quit: Changing server)
15.39.45 Join    Beta2K [0] (~Beta2K@cl-476.chi-02.us.sixxs.net)
15.40.41 Quit    zu (Quit: leaving)
15.44.10 Join    zu [0] (~zu@ks387228.kimsufi.com)
15.50.37 Quit    fs-bluebot (Ping timeout: 246 seconds)
15.51.56 Join    fs-bluebot [0] (~fs-bluebo@g226069248.adsl.alicedsl.de)
15.51.58 Quit    bluebrother (Ping timeout: 244 seconds)
15.53.58 Join    bluebrother [0] (~dom@rockbox/developer/bluebrother)
15.57.33 #       <pandrew> [Saint]: finally i found what's causing the problem. The codec errors happen when i'm compiling with DEBUG.
15.57.48 Quit    kevku (Ping timeout: 248 seconds)
15.59.39 #       <[Saint]> pandrew: that's, interesting.
16.00.15 #       <[Saint]> I don't suppose you've found a known-good revision?
16.01.26 #       <pandrew> i didn't look for one yet
16.01.28 #       <[Saint]> For example, check-out the revision the last release was branched from. If its bad, go back further, if its good, try a revision approximately halfway between release and head.
16.01.48 #       <[Saint]> Rinse, repeat.
16.02.00 #       <[Saint]> Eventually you'll have the offending commit.
16.03.10 Quit    zu (Quit: leaving)
16.04.22 Join    zu [0] (~zu@ks387228.kimsufi.com)
16.05.07 Quit    Horschti (Quit: Verlassend)
16.19.58 Quit    Guest97185 (Read error: Connection reset by peer)
16.22.50 #       <kugel> pandrew: do you do only make bin
16.22.52 #       <kugel> ?
16.36.05 #       <pandrew> [Saint]: I went back as far as 3.7, and it still fails if i compile with (D)ebug, it can't load the codecs.
16.36.07 #       <pandrew> kugel: i'm doing ../tools/configure, followed by make -j 4; followed by make zip, and then i remove the old .rockbox folder from my ipod, and extract the new one in its place
16.37.22 #       <webmind> [Saint], thanks, I'm not sure what flag is supposed to do what, but I'll check it out
16.37.38 #       <bluebrother> pixelma: did you find time checking g#247 again? Otherwise I might just go and submit it (you can do as well if you want to)
16.37.39 #       <fs-bluebot> 3Gerrit review #247 at http://gerrit.rockbox.org/r/247 : Filter LaTeX output for errors.  by Dominik Riebeling (changes/47/247/3)
16.38.59 #       <pixelma> no, I haven't, sorry. Feel free to go ahead though, I'll have to deal with it
16.39.08 #       <bluebrother> ok :)
16.39.24 #       * bluebrother goes finishing RC installation support first though
16.39.51 #       <[Saint]> webmind: running convttf without arguments will provide a help text/brief description
16.45.57 #       <webmind> sweet fixed
16.46.05 #       <webmind> [Saint], I got confused by the 'trim'
16.46.25 #       <webmind> I though, it's already trimmed.. but I can give negative numbers :)
16.46.50 #       <webmind> if anyone needs a rockbox font for dyslectics, I've got it converted :)
16.48.20 #       <[Saint]> Can dyslexics use it too? ;)
16.49.07 #       <webmind> it improves reading for people with dyslexicts
16.49.24 #       <webmind> especially designed for it
16.54.14 #       <[Saint]> I can't think of a wiki section that fits this...you're free to post it on the forum assuming you're licensed to do so though.
16.54.37 #       <[Saint]> If the license is in any way unclear, best not to.
16.55.35 #       <bluebrother> you could start a wiki page and simple name the font and convttf parameters used for converting
16.56.13 #       <webmind> [Saint], best not then
16.56.35 #       <webmind> setting for convttf: convttf -Td 3 -Ta -3 
16.57.09 #       <CIA-47> Commit 74af18e in rockbox by 03Dominik Riebeling: Add support for installing release candidate builds.
16.58.22 #       <webmind> [Saint], maybe an idea to provide the convert settings for nonfree fonts on the wiki?
16.58.54 #       <AlexP> webmind: That sounds like a good idea
16.59.15 #       <CIA-47> 74af18e build result: All green
16.59.42 #       <bluebrother> isn't that what I just suggested? ;-)
16.59.50 #       <webmind> lemme see if I still have a wiki account
17.02.20 #       <webmind> nope
17.05.22 #       <webmind> can I be added to WikiUsersGroup ?
17.05.26 #       <webmind> I'll make the page
17.08.27 #       <AlexP> webmind: What is your wiki name?
17.10.01 Join    kevku [0] (x@heaaqi4aafadxg4qrbugbunq4l4.dyn.reverse.name)
17.12.54 #       <webmind> SebastianStellingwerff
17.15.40 #       <[Saint]> Did the weirdness with the two wikiusersgroup lists get sorted out?
17.16.29 #       * [Saint] prods AlexP since he's there
17.17.44 ***     Saving seen data "./dancer.seen"
17.18.11 Quit    wodz (Quit: Leaving)
17.26.01 #       <bertrik> "WARNING, bad file name lacks slash: backdrops/cabbiev2.bmp" and no backdrop in the sim
17.31.25 Quit    jfc (Ping timeout: 246 seconds)
17.32.43 Join    jfc [0] (~john@stat-bng-72-73-80-12.ngn.east.myfairpoint.net)
17.33.36 #       <[Saint]> bertrik: which cabbie is this?
17.33.53 #       <[Saint]> All, a specific one, one of mine?
17.42.14 Join    evilnick [0] (~evilnick@rockbox/staff/evilnick)
17.49.29 #       <[Saint]> bertrik: ?
17.50.00 Quit    TheLemonMan (Quit: WeeChat 0.3.8)
17.51.07 Quit    jfc (Ping timeout: 240 seconds)
17.51.43 Quit    evilnick (Ping timeout: 246 seconds)
17.53.40 #       <webmind> [Saint], was here? :)
17.54.18 #       <[Saint]> ?
17.56.02 Quit    [Saint] (Read error: Connection reset by peer)
17.56.08 Join    [Saint_] [0] (~Saint]@unaffiliated/saint/x-8516940)
17.59.31 Quit    [Saint_] (Read error: Connection reset by peer)
18.01.51 Join    [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940)
18.04.13 Join    jfc [0] (~john@stat-bng-72-73-80-12.ngn.east.myfairpoint.net)
18.05.58 #       <webmind> [Saint], 'was' since he didn't respond after your prod
18.08.38 Join    Saratoga [0] (~AndChat41@cpe-024-088-253-098.nc.res.rr.com)
18.09.21 #       <Saratoga> Bertrik: I badly want some error logging mechanism that is on by default
18.10.55 #       <Saratoga> Something like logf except flushed to the disk and reserved for critical errors
18.13.10 Join    TheLemonMan [0] (~LemonBoy@adsl-ull-135-220.50-151.net24.it)
18.16.25 Join    Ward [0] (~Mirandaha@176-120-190-109.dsl.ovh.fr)
18.16.48 Nick    Ward is now known as Guest3349 (~Mirandaha@176-120-190-109.dsl.ovh.fr)
18.18.07 Quit    TheLemonMan (Quit: WeeChat 0.3.8)
18.20.27 Quit    jfc (Ping timeout: 265 seconds)
18.20.39 Quit    eckoit (Quit: eckoit)
18.22.47 #       <bertrik> [Saint], I mean the default cabbie v2
18.23.02 #       <bertrik> Saratoga, shouldn't be too hard I think
18.23.19 Join    jfc [0] (~john@stat-bng-72-73-80-12.ngn.east.myfairpoint.net)
18.23.26 #       <gevaerts> Well...
18.23.49 #       <gevaerts> how do you log errors involving things accessing unmounted filesystems in the first place?
18.24.28 #       <Saratoga> Yeah I have an old hack to logf to disk, but it would need to be integrated into the current buffering system like the config files
18.25.05 #       <Saratoga> Wait for it to remount or just lose the info
18.25.18 #       <bertrik> gevaerts, you can always think of *something* that can't be logged
18.25.51 #       <gevaerts> bertrik: of course, but this is the one that started this particular conversation :)
18.26.06 #       <Saratoga> I guess we could add another partition for logging data if someone were debugging msc
18.30.14 Join    benedikt93 [0] (~benedikt9@unaffiliated/benedikt93)
18.31.20 Quit    anewuser (Read error: Connection reset by peer)
18.41.19 Quit    mortalis (Quit: KVIrc 4.1.3 Equilibrium http://www.kvirc.net/)
18.43.46 Quit    user485763 (Quit: Leaving.)
18.51.32 Quit    ChanServ (*.net *.split)
18.53.32 Nick    Jack87|Away is now known as Jack87 (Jack87@nasadmin/admin/jack87)
18.58.25 #       <[Saint]> bertrik: *all* of them?
19.00.44 #       <[Saint]> If that's the case, something wrt parsing broke.
19.01.21 #       <[Saint]> Oh...actually, no. Not necessarily. There was a recent change to wpsbuild
19.05.49 Quit    mc2739 (Ping timeout: 244 seconds)
19.07.47 Join    mc2739 [0] (~mc2739@71.20.87.137)
19.12.24 Quit    Saratoga (Quit: Bye)
19.14.26 Join    ChanServ [0] (ChanServ@services.)
19.14.26 Mode    "#rockbox +o ChanServ   " by kornbluth.freenode.net
19.16.53 Join    evilnick [0] (~evilnick@rockbox/staff/evilnick)
19.17.48 ***     Saving seen data "./dancer.seen"
19.24.25 Quit    mc2739 (Quit: leaving)
19.25.37 Join    lebellium_ [0] (~chatzilla@e179064036.adsl.alicedsl.de)
19.25.46 Join    mc2739 [0] (~mc2739@71.20.87.137)
19.25.46 Quit    mc2739 (Changing host)
19.25.46 Join    mc2739 [0] (~mc2739@rockbox/developer/mc2739)
19.27.12 Join    stoffel [0] (~quassel@pD9E4382E.dip.t-dialin.net)
19.27.34 Quit    lebellium (Ping timeout: 260 seconds)
19.27.48 Nick    lebellium_ is now known as lebellium (~chatzilla@e179064036.adsl.alicedsl.de)
19.28.57 Quit    evilnick (Ping timeout: 244 seconds)
19.32.33 Join    ender` [0] (krneki@foo.eternallybored.org)
19.35.41 Quit    stoffel (Ping timeout: 244 seconds)
19.46.50 Join    lgp171188 [0] (~lgp171188@122.167.16.105)
19.48.58 #       <lgp171188> Hi, I have a Sansa Clip Zip player with the latest rockbox beta installed. I also installed the doom plugin and started the game. The keys don't work in the game and I am not able to quit the game as well. I pressed the power button and the menu came up. When I select quit game and press the select button, the control returns to the game. I am unable to power off the player as well. Any ways to work around?
19.51.12 Join    evilnick [0] (~evilnick@92.40.254.59.threembb.co.uk)
19.51.13 Quit    evilnick (Changing host)
19.51.13 Join    evilnick [0] (~evilnick@rockbox/staff/evilnick)
19.53.14 #       <[Saint]> lgp171188: the player should always respond to whatever its version of a hard power down is (usually holding the power button for some time)
19.54.27 Quit    benedikt93 (Quit: Bye ;))
19.54.58 #       <[Saint]> Doom not working, while still an issue, isn't really a priority. These types of thing are usually not implemented with perfection in early ports, as its not really a stretch to say that Doom is just a novelty.
19.55.07 #       <lgp171188> [Saint]: By experimenting, I started a new game and the game started working and I was able to quit it as well. Maybe it is just a case of me not knowing the controls of the device wrt to rockbox well. thanks for the help :) I tried hard power down by holding it for about 3-4 seconds and nothing happened in the screen that comes up on starting the game.
19.55.42 Join    amayer [0] (~amayer@72.25.62.15)
19.55.59 #       <[Saint]> Its quite likely the keymap is incomplete.
19.56.06 #       <[Saint]> I can't check right now.
19.56.35 #       <AlexP> lgp171188: Try the manual, it should have keymaps
19.57.23 #       <gevaerts> lgp171188: 3 or 4 seconds isn't anywhere near the time for a hard power down
19.57.58 Quit    [Saint] (Remote host closed the connection)
19.58.09 #       <lgp171188> [Saint]: I know the amount of wonderful work that has been done on rockbox and I was just exploring the stuff on rockbox as I am totally new to it and in the process chanced upon doom :) Rockbox team has done an unbelievably awesome job and I can't find enough words to convey my appreciation. I never had an mp3 player that rockbox could run, so this time when I had to buy a new one, I was particular about buying one that is compatible and the first th
19.58.32 Join    [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940)
19.58.53 #       <lgp171188> AlexP: I am now going through the manual now to get a better understanding of how rockbox works and the keymaps. The manual seems to be missing screenshots and I can help with preparing them so that manual can be updated.
19.59.34 #       <AlexP> yeah, it is and that would be great
20.00.57 #       <lgp171188> AlexP: I see some notes on the manual saying that the screenshots could be taken with a simulator. Is it possible to take screenshots on the actual player itself?
20.01.07 #       <AlexP> yes, check the manual :)
20.01.14 #       <AlexP> It might not be in there actually
20.01.43 #       <AlexP> But if it has been implemented there is an option somewhere (maybe debug menu) that changes it so that when you insert USB it takes a screenshot
20.01.53 #       <AlexP> The sim is usually more convenient
20.02.19 #       <lgp171188> ok, let me try the simulator as well
20.05.43 #       <[Saint]> Isn't/wasn't there an ss generating script?
20.05.58 #       <AlexP> Not complete I don't think
20.06.07 #       <[Saint]> Seems like that would be a handy thing to have if I imagined it.
20.06.22 #       <AlexP> rasher was doing it many moons ago
20.07.34 #       <rasher> It never really worked terribly well, for some reason. It worked by opening a unix pipe through which you could inject keypresses into the button queue
20.11.31 Join    bitcraft [0] (~bitcraft@173-23-42-120.client.mchsi.com)
20.12.41 #       <lgp171188> And one more thing I found out - the brickmania game, I completed the first level and still I wasn't taken to the next level. I was still left to bounce the ball in the empty screen. Looked like a bug.
20.13.39 #       <bertrik> lgp171188, yes that's a known issue
20.14.02 #       <bertrik> actually, there's some bricks that won't fit on the screen
20.14.43 Nick    alexbobp is now known as capitalthree (~alex@capitalthree.pwnz.org)
20.28.15 Join    domonoky1 [0] (~Domonoky@agsb-5d871a70.pool.mediaWays.net)
20.28.39 #       <amayer> hey all
20.29.13 Quit    domonoky (Ping timeout: 246 seconds)
20.31.09 #       <amayer> ive been doing research for a couple of hours now about whether or not my IPod is supported. it is gray with a black wheel, has 120Gb capacity.
20.31.23 #       <amayer> some sites say its a 2nd Gen and others say it is a 6th gen
20.31.45 #       <amayer> I always thought it was a Ipod Video(seeing as it plays videos)
20.32.40 #       <amayer> on the apple website it just says "IPod Classic" it doesnt say what generation(And there is no "IPod Video" on the apple website)
20.32.47 #       <gevaerts> That's a Classic, which is a 6th gen. It might be the 2nd revision of that which explains the 2nd gen :)
20.33.32 #       <[Saint]> So, its "supported" but we can't really help with installation. 
20.34.03 #       <gevaerts> Rockbox does run on those, but you can't dual-boot and you need to install it using the tools from http://www.freemyipod.org/, which is why it's still classified as "unusable" in our terms (although "unusable" is a very misleading term in this case)
20.34.40 #       <amayer> what documentation should i use for this? Ipod video?
20.34.57 #       <[Saint]> None of ours.
20.35.15 #       <[Saint]> The site gevaerts linked has full installation details.
20.35.34 #       <gevaerts> For general usage, I'd say video, yes. For installation, http://www.freemyipod.org/
20.36.14 #       <[Saint]> Oh...right. I forgot "documentation" also == "manual".
20.36.38 #       <[Saint]> Yes, the video is /practically/ identical wrt the manual.
20.39.39 #       <amayer> thanks all
20.52.12 Quit    bitcraft (Remote host closed the connection)
20.55.07 Join    bitcraft [0] (~bitcraft@173-23-42-120.client.mchsi.com)
21.00.06 Join    petur [0] (~petur@rockbox/developer/petur)
21.00.24 Quit    bitcraft (Remote host closed the connection)
21.00.49 Quit    evilnick (Quit: Leaving)
21.02.29 Join    bitcraft [0] (~bitcraft@173-23-42-120.client.mchsi.com)
21.08.04 Join    evilnick [0] (~evilnick@rockbox/staff/evilnick)
21.17.07 Quit    bitcraft (Remote host closed the connection)
21.17.52 ***     Saving seen data "./dancer.seen"
21.36.50 Quit    Thra11 (Ping timeout: 246 seconds)
21.38.19 Join    pamaury_ [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net)
21.38.52 Quit    pamaury (Ping timeout: 246 seconds)
21.39.50 Join    Thra11 [0] (~thrall@87.112.155.44)
21.41.08 Quit    jfc (Ping timeout: 248 seconds)
21.44.16 Join    jfc [0] (~john@stat-bng-72-73-80-12.ngn.east.myfairpoint.net)
21.46.50 Join    liar [0] (~liar@clnet-p09-185.ikbnet.co.at)
21.52.52 Quit    lgp171188 (Ping timeout: 248 seconds)
22.12.04 Join    ender [0] (krneki@foo.eternallybored.org)
22.13.40 Quit    ender` (Ping timeout: 248 seconds)
22.14.27 Quit    ender| (Ping timeout: 260 seconds)
22.15.37 #       <dionoea> hi
22.15.55 Quit    kevku (Ping timeout: 248 seconds)
22.16.00 #       <dionoea> does rockbox support sdxc cards on sandisk devices? (e200v1 more specificaly)
22.16.15 #       <dionoea> I'm not sure if sdxc is software only or if hardware also needs support
22.16.45 #       <gevaerts> It's software only for current cards I think
22.17.06 #       <dionoea> so it should "just" work in rockbox?
22.17.18 #       <gevaerts> Yes
22.17.20 #       <dionoea> nice
22.17.29 #       <dionoea> thanks
22.17.35 #       <gevaerts> Some people are using 64GB cards on various players
22.17.41 #       <evilnick> SDXC (as per the spec) is formatted as exFAT, so make sure that you format the partition as FAT32 first
22.18.13 #       <dionoea> ok, nice to know
22.18.27 #       <dionoea> do micro sdxc 128GB cards exist? (I can't seem to find any on amazon)
22.18.39 #       <evilnick> Not yet, I don't think
22.19.41 #       <gevaerts> Future cards may not work. IIRC there's something about doing things differently in incompatible ways at some "level" of sdxc
22.21.10 #       <dionoea> SDXC 4.0 according to wikipedia
22.21.14 #       * dionoea is reading that page
22.21.32 #       <dionoea> I wonder why they changed to exFAT. is that more efficient in the way it handles flash storage?
22.21.53 #       <evilnick> Larger max. filesize for one advantage
22.21.56 #       <gevaerts> it supports large files
22.21.58 #       <dionoea> (it looks like SDXC 4.0 only adds optional bits)
22.21.59 #       <dionoea> ah ok
22.22.29 #       <gevaerts> Not interesting for most audio use, but 2GB/4GB is not that small for video
22.22.36 #       <gevaerts> s/small/large/
22.22.59 #       <dionoea> indeed
22.23.57 #       <gevaerts> What I don't get is why a card protocol spec even talks about the filesystem
22.25.25 #       <evilnick> Is exFAT patent-encumbered?
22.25.28 Quit    jfc (Ping timeout: 246 seconds)
22.25.41 #       <gevaerts> I think so
22.26.15 #       <evilnick> And is it from Microsoft?
22.26.19 #       <gevaerts> yes
22.26.30 #       <evilnick> I think that you've answered your own question :)
22.26.49 #       <dionoea> I guess that they want to have a card that plugs and plays everywhere. So having a unique filesystem makes sense from a "user" perspective
22.26.52 #       <gevaerts> sure, but SDXC isn't only microsoft!
22.27.22 Join    ender| [0] (~ender1@2a01:260:4094:1:42:42:42:42)
22.28.45 Join    jfc [0] (~john@stat-bng-72-73-80-12.ngn.east.myfairpoint.net)
22.29.05 Join    kevku [0] (x@heaaqi4aafadxg35plvxt2ugh3a.dyn.reverse.name)
22.55.18 Join    telliott [0] (~Tim@d27-96-170-180.evv.wideopenwest.com)
23.01.40 Join    [Saint_] [0] (~Saint]@unaffiliated/saint/x-8516940)
23.02.31 Quit    n1s (Quit: Ex-Chat)
23.04.16 Quit    [Saint] (Ping timeout: 246 seconds)
23.05.44 Quit    Thra11 (Quit: No Ping reply in 180 seconds.)
23.05.56 Quit    [Saint_] (Ping timeout: 248 seconds)
23.10.56 Join    saratoga [0] (18c7cfab@gateway/web/freenode/ip.24.199.207.171)
23.11.48 #       <saratoga> bertrik:  i guess what i'd like to see is something like LOGFILEF which uses the storage callbacks to maintain a log of serious errors
23.12.38 #       <saratoga> or perhaps with an argument that determines the seriousness of the event, and a preprocessor macro that eliminates events below a threshold set at compile time
23.12.48 #       <saratoga> that way we could merge in the existing LOGF stuff into it
23.12.48 #       <bertrik> if an error is really serious we might just as well spin up the disk to write it immediately
23.12.56 #       <saratoga> yeah
23.13.23 #       <saratoga> one thing i was wondering, is it possible to write things like stack traces to disk during a data abort?
23.13.49 #       <saratoga> i don't know how much of the code is still intact at that point
23.14.02 #       <bertrik> but some kind of buffer could still be useful, if the filesystem has been shut down to make way for USB (like gevaerts mentioned)
23.14.32 #       <bertrik> I'd say a data abort is too serious to attempt anything with the file system after that
23.14.40 #       <saratoga> i suppose as a compile time option it would be pretty easy to specify that the log should be written to a different partition then is exposed over MSC
23.15.01 #       <saratoga> but logf is already available in that case to a large extent
23.15.14 #       <saratoga> i was mainly thinking of some way to have basic error logging for normal users 
23.15.33 #       <saratoga> for things like codec errors, database errors, etc 
23.15.51 #       <bertrik> yes, sounds useful
23.16.13 #       <bertrik> we still have plenty of cases where users say that a song was skipped mysteriously
23.16.42 #       <saratoga> yes, i would very much like to see what the actual error codes coming out of codecs (or maybe buffering?) are in those cases
23.17.03 #       <saratoga> anyway, just looking at the battery bench plugin, it seems like its pretty easy to tie this into the existing delayed write mechanism and of course we already have the LOGF code, so this is probably not too much work to implement
23.17.06 Join    [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940)
23.17.22 #       <saratoga> hardest part will probably just be going back through the code and deciding what should be logged :)
23.17.39 #       <bertrik> indeed
23.17.53 ***     Saving seen data "./dancer.seen"
23.17.54 #       <saratoga> i think at first we should leave the current LOGF system alone
23.18.11 #       <saratoga> so perhaps call this LOGFILEF?
23.18.17 Quit    telliott (Quit: Leaving)
23.19.41 #       <pandrew> what's at 0x4000f140?
23.20.08 #       <bluebrother> something
23.20.15 #       <pandrew> sorry, what's at 0x40001f40 on ipod video?
23.20.26 #       <saratoga> you'd have to check the map file for your build
23.20.29 #       <bluebrother> an address
23.20.34 #       <bluebrother> likely to be RAM
23.20.52 #       <saratoga> the addresses aren't constant across different builds
23.20.53 #       <bertrik> saratoga, any name is fine with me :)
23.21.03 #       <saratoga> you think its worth doing preprocessor magic with this?
23.21.17 #       <saratoga> or just compile everything even if its not used
23.21.48 #       <bertrik> I don't know yet
23.21.56 #       <saratoga> i guess at least the archos players may not want this enabled
23.22.04 #       <saratoga> or at least very little of it
23.22.46 #       <saratoga> perhaps LOGF(error_level, ...) could be preprocessed to throw out all log messages below the current threshold so that they don't bloat the binary
23.23.02 #       <saratoga> then just set the threshold to 0 on LOWMEM targets
23.23.05 #       <pandrew> i taught it was some memory mapped hardware
23.23.11 #       <bertrik> sounds like a good plan
23.23.23 #       <pandrew> but it's 'iram', and the map file says it's codec_thread.o
23.23.39 #       <saratoga> check one of the codec map files
23.24.04 #       <saratoga> which everyone you were playing when you got that address
23.24.10 #       <saratoga> which ever one
23.24.23 #       <saratoga> on the downside, i would have to look up how preprocessor stuff works :(
23.25.36 #       <pandrew> can more than one codec be loaded at the same time in rockbox?
23.25.58 #       <saratoga> no
23.26.08 #       <saratoga> each one uses the entire 1MB of space and all codec IRAM
23.26.19 #       <saratoga> on your player thats probably 80KB of IRAM IIRC
23.26.30 #       <bluebrother> well, we have the speech coded that is running the same time. But is that loaded or compiled into Rockbox?
23.26.38 #       <saratoga> that runs in core
23.26.50 #       <bluebrother> ok
23.26.52 #       <saratoga> theres actually a stripped down speex decoder compiled into the main binary IIRC
23.27.01 #       <saratoga> fortunately its a very lightweight codec so theres not much cost 
23.27.22 #       <saratoga> amazing i still remember that, i didn't even have SVN access when we were talking about that
23.28.05 #       <saratoga> anyway, i'm out, will think about this more later
23.28.21 #       <saratoga> have to defend this week so i should probably be worrying about other things
23.28.51 Quit    saratoga (Quit: Page closed)
23.29.50 #       <bertrik> on the sim, function usb_wait_for_disconnect() returns nearly immediately
23.38.55 Quit    jfc (Ping timeout: 246 seconds)
23.40.21 #       <bertrik> bah, I'm getting lost in our event broadcast system
23.40.28 Join    jfc [0] (~john@stat-bng-72-73-80-12.ngn.east.myfairpoint.net)
23.42.24 Part    copper
23.42.42 #       <bertrik> oh, usb_wait_for_disconnect only does stuff  #ifdef USB_FULL_INIT
23.44.25 Quit    pamaury_ (Remote host closed the connection)
23.44.44 #       <bertrik> ... which is never true in the sim
23.46.47 #       <bertrik> can anyone explain why that #ifdef is there? (around line 148 in uisimulator/common/sim_tasks.c)
23.48.37 Quit    jfc (Ping timeout: 245 seconds)
23.51.56 Join    jfc [0] (~john@stat-bng-72-73-80-12.ngn.east.myfairpoint.net)
23.57.19 Join    anewuser [0] (~anewuser@190.207.142.142)
23.57.19 Quit    anewuser (Changing host)
23.57.19 Join    anewuser [0] (~anewuser@unaffiliated/anewuser)