--- Log for 02.04.110 Server: zelazny.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 4 days and 5 hours ago 00.00.03 # tagcache in ram just makes browsing tagcache faster 00.00.04 # ok, so first dircache, then database. I think that achieving this by some sort of priority thing still makes most sense though 00.00.13 # dircache being scanned makes almost *everything* faster 00.00.20 # er, scan beign done, i mean 00.00.40 # Maybe update dircache if the disk is idle for 100ms, and do database things if it's idle for 200ms? 00.00.52 # Or similarly different numbers 00.02.34 # i guess. 00.02.46 # i dunno what effect *updating* the db has, btw 00.02.51 # i don't have autoupdate turned on 00.02.56 # and i've never updated while actualyl using the plpayer 00.03.07 # i just know that you can use it while it's not done loading to ram yet :) 00.03.56 # I only have the database for occasional pictureflow testing/showing, so I don't have autoupdate either 00.05.00 # i use it to pick random things :) 00.05.05 Join huelk_ [0] (~huelk@dtmd-4db78ea6.pool.mediaWays.net) 00.05.22 # and occasionally to find songs on mix cds. 00.05.49 Quit fyrestorm (Quit: Ur skills' fireproof like a wooden panel -- U got feds talking leet on your IRC channel!) 00.06.51 # New commit by 03bluebrother (r25430): Fix multiple warnings when network is unreachable. ... 00.06.54 # New commit by 03bluebrother (r25431): Fix leaking file descriptors on error. 00.08.58 # Zagor: can you have a look at flyspray? It seems to not do attachments anymore 00.10.14 Quit dfkt (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.) 00.13.07 Quit kio (Quit: Leaving) 00.15.28 Quit dockimble1 (Quit: WeeChat 0.2.6.3) 00.16.59 Quit Schmogel (Read error: No route to host) 00.17.10 Join dockimble [0] (~dockimble@77.227.1.24) 00.17.21 Join RoronoaZoro [0] (~vijay@202.3.77.11) 00.22.28 Quit funman (Quit: free(random());) 00.23.01 Quit komputes (Read error: Operation timed out) 00.23.06 Quit shaggy-h (Ping timeout: 240 seconds) 00.23.54 Join shaggy-h [0] (~kiwi@78-86-164-31.zone2.bethere.co.uk) 00.26.08 Quit jgarvey (Quit: Leaving) 00.28.09 Quit bertrik (Quit: De groeten) 00.28.12 Quit anewuser () 00.30.17 Quit einhirn_ (Read error: Connection reset by peer) 00.31.56 Quit user124345 (Quit: Page closed) 00.32.14 Join froggyman [0] (~me@unaffiliated/froggyman) 00.41.34 Quit adnyxo (Ping timeout: 265 seconds) 00.42.35 Join komputes [0] (~komputes@ubuntu/member/komputes) 00.43.26 # New commit by 03gevaerts (r25432): Add GSoC acceptance to the news 00.43.39 # Zagor, B4gder: maybe another homepage push? 00.43.54 # done 00.44.30 # I reverted the suexec change, so now the builds are back again, too. I'll give it another go when I have a few more hours spare. 00.44.53 # Ah, flyspray accepts attachments again as well 00.44.58 Quit perfectdrug (Quit: Leaving.) 00.45.02 # good 00.49.36 Join xiainx [0] (~iain@wpa106051.Wireless.McGill.CA) 00.49.46 Quit Zagor (Quit: Clint excited) 00.52.17 Join Luca_S [0] (~5712526b@giant.haxx.se) 00.59.21 Quit ender` (Quit: With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC1925) 01.00.59 *** Saving seen data "./dancer.seen" 01.01.45 Quit dockimble (Quit: WeeChat 0.2.6.3) 01.03.32 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 01.04.59 Join Guest62701F [0] (Status@gentoo.lonis.org) 01.05.06 Quit Status (Read error: Connection reset by peer) 01.08.46 # fuzev2 scrollwheel works great ;) time on my 01.08.55 # device seems offset by 65284500 seconds 01.10.01 # that is, rockbox is 65284500 seconds in the future 01.10.01 Quit dmb (Quit: Leaving) 01.11.00 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 01.11.34 # the build table shows red for the as3525v2 boot loaders, related to the scrollwheel 01.20.03 Nick Guest62701F is now known as Status (Status@gentoo.lonis.org) 01.20.50 # recording seems to work, but I had a panic 01.21.03 # i2sin error: 0x4e = push 01.21.17 Quit komputes (Remote host closed the connection) 01.24.13 Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) 01.28.48 Join tarnzwerg [0] (~abc@188-195-103-184-dynip.superkabel.de) 01.30.07 Join komputes [0] (~komputes@ubuntu/member/komputes) 01.31.48 Join orby_alt [0] (~Miranda@ip28-116.kullen.RWTH-Aachen.DE) 01.32.37 Quit orby_alt (Client Quit) 01.34.46 Join totonono [0] (~thomas@196.207.219.211) 01.40.25 Join orby_alternative [0] (~oe@ip28-116.kullen.RWTH-Aachen.DE) 01.40.25 Quit Luca_S (Quit: CGI:IRC (EOF)) 01.40.56 # /join #testlalalalal 01.41.33 Quit tarnzwerg (Quit: Verlassend) 01.42.44 Quit domonoky (Read error: Connection reset by peer) 01.45.45 Quit bmbl (Quit: Bye!) 01.48.41 Quit sevard (Ping timeout: 260 seconds) 01.49.52 Join Tomis2 [0] (~Tomis@70.134.81.146) 01.49.58 Quit orby_alternative () 01.50.47 Quit Tomis (Ping timeout: 245 seconds) 01.50.47 Nick Tomis2 is now known as Tomis (~Tomis@70.134.81.146) 01.54.13 Quit arbingordon (Quit: `) 01.54.38 Quit xiainx (Quit: Good Bye!) 01.55.08 Join arbingordon [0] (~w@unaffiliated/arbingordon) 01.57.21 Join merbanan [0] (~banan@c-62-220-165-110.cust.bredband2.com) 01.57.44 Join Tomis2 [0] (~Tomis@70.134.100.51) 01.58.05 Quit Tomis (Ping timeout: 240 seconds) 01.58.05 Nick Tomis2 is now known as Tomis (~Tomis@70.134.100.51) 02.04.05 Quit huelk_ (Ping timeout: 240 seconds) 02.06.27 Join sevard [0] (sev@216.164.6.24) 02.06.28 Quit merbanan (Ping timeout: 264 seconds) 02.17.48 Join dmb [0] (~Dmb@unaffiliated/dmb) 02.24.19 Quit efgpinto (Quit: Lost terminal) 02.26.48 # we should release a bootloader for the fuzev2 02.34.15 Join CaptainKewl [0] (~jason@207-237-106-60.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 02.38.37 Quit JohannesSM64 (Ping timeout: 264 seconds) 02.41.21 # RoronoaZoro: I would start out by outlining the steps you'll need to do and estimating how long you think they'll take 02.41.44 # i would include a brief explanation of the benefits of your project as you see them 02.41.50 # ok 02.42.03 # and I would explain your reasoning behind chosing the project, and why you think its feasible 02.42.35 # your proposal is interesting, it'll mostly be about convincing people you are serious about it and able to do it 02.42.45 # and explaining your ideas in detail will help a lot with that 02.44.40 # ok 02.45.40 # unfortunately I can't really give you any specific advice for the project because I've never worked on mpegplayer and am not too familar with video decoding 02.46.17 # i will suggest that for audio codecs, adding AC3 support might be a good goal though, since its a fast and efficient codec already in rockbox (for audio files only) that is commonly used with mpeg video 02.47.30 # as to why is it feasible meaning what should i tell....like currently i can only tell that as per my knowledge of c and asm are concerned i can tell that i can port the code but how do i tell that to the mentors 02.47.52 # *i mean related to ffmpeg 02.48.15 # i would address the computational feasibility too, these are slow systems, so you should try to assure people that they're fast enough for the formats you want to add 02.50.25 # so i can list in maybe some example of fps or comparision with other codecs 02.50.44 # yeah 02.51.09 # theres lots of papers showing mpeg performance on various arm cpus too, and some companies publish cpu requirements for embedded decoders too 02.51.24 # k 02.51.28 # i think it should be possible to estimate the minimum cpu speeds needed for 15 fps or 20 fps playback 02.51.37 Join JohannesSM64 [0] (~johannes@cm-84.215.75.42.getinternet.no) 02.51.40 # yes 02.53.37 # and as for the timeline what do i consider the dates that i give to the project to be till ... i mean the end date only ... 02.54.23 # give an estimate for how long you think you it'll take to do each part of the project 02.55.21 # the refactoring of the original code will take me about 1-2 weeks 02.56.54 # for the porting i am assuming about 3-4 weeks .... not much sure as i have only seen the documentation not the code 02.57.05 # have you had a chance to look at the mpegplayer code ? 02.57.09 # yes 02.59.05 Join RadicalR [0] (~radicalr@c-69-255-49-110.hsd1.va.comcast.net) 02.59.43 # how much of it is just the mpeg1/2 decoder and how much is actually the player part? 03.01.04 *** Saving seen data "./dancer.seen" 03.01.29 # mpeg2dec is the decoder files 03.01.43 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 03.01.55 Quit adnyxo (Remote host closed the connection) 03.02.42 # and also the stream.c and .h they check the format of the file 03.03.35 Quit totonono (Quit: Quitte) 03.03.47 # so i think about 1/2 is the part that is mpeg1/2 specific 03.06.14 # i am still having a problem i am not able to get the cross compiler working so i am not able to build rockbox yet 03.07.35 # what is your problem? 03.09.46 Join anewuser [0] (anewuser@unaffiliated/anewuser) 03.12.24 # http://pastebin.com/fN81v1L7 03.13.05 # this is what happens when i run rockboxdev.sh 03.14.32 Quit robin0800 (Remote host closed the connection) 03.15.29 # RoronoaZoro: what kind of computer is that? 03.16.23 # you could also try deleting those temp files and redownloading them in case they really are corrupt 03.17.58 Quit JohannesSM64 (Max SendQ exceeded) 03.21.59 Join Blue_Dude [0] (~chatzilla@adsl-235-206-131.mco.bellsouth.net) 03.22.14 # Keymaps! I gotcher keymaps right here! 03.24.26 # New commit by 03Blue_Dude (r25433): Switch on hotkey on several targets. Stole the WPS Show Track Info key for most of them. Made up a free key for the rest. 03.24.36 # where do the temp files get stored .... i am not able to find... 03.27.17 # your logs mention /tmp/rbdev-dl 03.27.26 # i would check there 03.27.36 # failing that, open up the script and see where it stores things 03.29.36 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 03.30.13 # dircache was the cause of the slow boots then? 03.37.53 # * RoronoaZoro proxy really troubles 03.38.25 Join CGL [0] (~CGL@190.207.232.114) 03.39.19 # does anything useful actually get stored in /tmp/rbdev-dl ? I just ended up deleting it... 03.39.22 # Oooops. 03.41.16 Join sustineo [0] (~42116ef5@giant.haxx.se) 03.41.51 # still the same problem http://pastebin.com/RXpkEsWb 03.41.53 # New commit by 03Blue_Dude (r25434): Fix someone elses yellow and red 03.42.28 # ----unrelated---- hey, i was making a wps, and i was wondering if there is a way to put images / text info over the album art. is there? 03.42.41 # * RoronoaZoro says this time rockboxdev.sh downloaded the files 03.42.54 # sustineo: not reliably... 03.43.04 Join Tomis2 [0] (~Tomis@70.134.100.53) 03.43.13 # @saint: it crashes if you do? 03.43.52 # No, it just doesn't ever seem to look right, there is little controll (actually none) over what gets drawn first. 03.43.59 # oh 03.44.10 # It all gets drawn in one big batch at the end. 03.44.33 # alternatively, can you rotate text data? (like 90 degrees) 03.44.56 # not without getting *really* creative with viewports 03.45.38 # >_> 03.45.40 # thanks 03.45.46 Quit CGL (Ping timeout: 245 seconds) 03.45.49 Quit sustineo (Client Quit) 03.45.59 Join Beta2K [0] (~Beta2K@d24-36-126-101.home1.cgocable.net) 03.46.13 Join n1s [0] (~n1s@rockbox/developer/n1s) 03.46.36 Quit Tomis (Ping timeout: 252 seconds) 03.46.36 Nick Tomis2 is now known as Tomis (~Tomis@70.134.100.53) 03.48.29 # 22:36:49 gevaerts Was the WPS loaded at boot back in the pre-sbs days? <- No, it was a "recent" change 03.49.17 Part froggyman 03.49.55 Part RoronoaZoro ("Ex-Chat") 03.50.14 Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.2/20100316074819]) 04.03.41 Join Barahir [0] (~jonathan@gssn-5f757aa7.pool.mediaWays.net) 04.05.20 Quit komputes (Quit: I haven't slept for ten days, because that would be too long.) 04.07.12 Quit Barahir_ (Ping timeout: 264 seconds) 04.16.24 Join JohannesSM64 [0] (~johannes@cm-84.215.75.42.getinternet.no) 04.20.36 Quit linuxguy3 (Read error: Operation timed out) 04.32.45 Join Rob2222 [0] (~Miranda@p4FDCB716.dip.t-dialin.net) 04.33.09 Quit Adubb () 04.35.43 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 04.35.54 Nick S_a_i_n_t_ is now known as S_a_i_n_t (S_a_i_n_t@203.184.1.208) 04.36.35 Quit Rob2223 (Ping timeout: 265 seconds) 04.45.29 Join angelwolf71885 [0] (~chatzilla@cpe-173-171-133-36.tampabay.res.rr.com) 04.46.55 Quit angelwolf71885 (Client Quit) 04.53.04 Join TillW [0] (~Till@CPE0018395fb63b-CM00195ee38f2c.cpe.net.cable.rogers.com) 04.58.49 Join saratoga_lab [0] (~9803c20d@gateway/web/freenode/x-tmegqaqlgrgwjthu) 05.01.08 *** Saving seen data "./dancer.seen" 05.07.51 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 05.28.07 Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 05.32.24 # S_a_i_n_t: i don't see how messing w/ viewports could let you rotate text... 05.34.48 Join blairb [0] (~blairb@121-73-216-35.broadband.telstraclear.net) 05.35.42 # soap: realistically this needs the *rest* of an AVC decoder to matter. isn't codec video player on the GSoC list for this year? 05.36.04 # did you mean to highlight soap, Unhelpful? 05.36.53 # soap: i might have, you thought this might be worth moving, i wanted to give you an idea what else we need for the IPU filter to help 05.37.03 # for I was speaking in much more general terms, not at all attempting to be specific to the task at hand (as it were) 05.37.19 # it could optionally be used to clean up mpeg-1/2 video now, if somebody can figure it out 05.39.28 # what does it actually do? resize or more stuff like iDCT? 05.39.36 # that's re: jhMikeS's question also i suppose. you don't need deblock, it's not anywhere in the spec, but running it on the decoded frames before display can pretty up your low-bitrate stream a good bit. 05.40.02 # Unhelpful: well, not "automatically" rotate *any* text, but I've proven (with much viewport fuckery) that its possible to get text to scroll/display top to bottom/bottom to top. 05.40.24 # I thought that was more the effect he was after, not rotating a specific block of text. 05.41.29 Join jeffp [0] (~jeffp@barmen.interhost.no) 05.41.37 # jhMikeS: as long as you're here, how difficult will it be to separate the mpeg1/2 stuff from the core of mpegplayer? 05.41.43 Part jeffp 05.42.04 # saratoga_lab: it's a smoothing filter intended to blend together macroblock boundaries. it's helpful with low-bitrate mpeg-1/2 streams, and a specific deblocking filter is part of the decode process for AVC 05.42.21 # oh its just the h264 deblocking filter? 05.42.40 # a good chunk of AVC's quality/bitrate improvement probably comes from making deblock mandatory and doing it before frames are used as references 05.43.03 # saratoga_lab: (sorry, wasn't watching this closely and thought I was in this channel actually) I planted some seeds there, but didn't go full out. It would take some thought but its not a from-scratch job. 05.43.10 # saratoga_lab: the IPU has a postproc filter that at least claims to be able to filter per the AVC spec. 05.43.40 # * jhMikeS slowly recovers his bearings 05.43.52 # jhMikeS: is the basic app (buffering, audio thread, seeking) able to work with any format or would any parts need to be reimplemented? 05.44.25 # i don't know much about video decoding beyond the high level transform stuff, so its hard for me to judge what one of these projects involves 05.45.41 # saratoga_lab: the video/audio threads probabaly need better abstraction. they're rather tied to the codecs themselves. seeking, buffering and parsing are pretty much abstracted each other. 05.45.56 # did you email that student? 05.46.08 # saratoga_lab: yes I did 05.46.20 # great, i felt bad since no one could answer any of his questions 05.47.15 Join Finixlives [0] (~4a22104a@giant.haxx.se) 05.49.03 # saratoga_lab: np. I hope they aren't _too_ esoteric about the codecs' nitty-gritty. Well, whatever, I'll give it my best. 05.49.24 # i don't think hes a codec person at all, so probably not 05.50.35 # i suggested some combination of AC3 support, MPEG4 video and implementing resizing 05.50.45 # so expect questions about what that would involve 05.52.11 Quit JohannesSM64 (Quit: WeeChat 0.3.2-dev) 05.55.10 # saratoga_lab: I guess its one of those things where once you get the multi-format going, the rest would be easier. 06.00.37 Quit katyl (Quit: Ex-Chat) 06.02.33 Quit panni_ (Read error: Connection reset by peer) 06.07.33 Quit Finixlives (Quit: CGI:IRC (EOF)) 06.08.55 Quit CaptainKewl (Remote host closed the connection) 06.20.05 Join kramer3d [0] (~kramer@unaffiliated/kramer3d) 06.30.51 Quit anewuser () 06.35.56 Join Adubb [0] (~aldubuc@67.201.160.144) 06.46.03 Quit xiainx (Ping timeout: 246 seconds) 06.49.51 Join jeffp [0] (~jeffp@barmen.interhost.no) 06.51.28 Part jeffp 07.01.10 *** Saving seen data "./dancer.seen" 07.17.34 Quit leavittx__ (Ping timeout: 258 seconds) 07.17.34 Quit leavittx_ (Ping timeout: 258 seconds) 07.17.34 Quit leavittx (Ping timeout: 258 seconds) 07.26.36 Join CGL [0] (~CGL@190.79.148.166) 07.29.39 Join leavittx [0] (~leavittx@89.221.199.187) 07.30.07 Join leavittx__ [0] (~leavittx@89.221.199.187) 07.30.09 Join leavittx_ [0] (~leavittx@89.221.199.187) 07.33.20 Quit Horscht (Ping timeout: 264 seconds) 07.33.40 Join Horscht [0] (~Horscht2@xbmc/user/horscht) 08.02.19 Join mitk [0] (~mitk@195.117.162.130) 08.03.07 Part Tomis 08.04.58 Join kramer3d_ [0] (~kramer@unaffiliated/kramer3d) 08.06.18 Quit kramer3d (Ping timeout: 258 seconds) 08.11.43 Quit BHSPitMonkey (Remote host closed the connection) 08.28.13 Quit CGL (Quit: Saliendo) 08.30.02 Join funman [0] (~fun@rockbox/developer/funman) 08.31.15 Join ender` [0] (krneki@foo.eternallybored.org) 08.43.09 # 12h40 runtime on Clip+ and running, battery level 17% 08.43.59 Join froggyman [0] (~me@unaffiliated/froggyman) 08.44.27 Join moos [0] (moos@rockbox/staff/moos) 08.44.36 Join webguest67 [0] (~5edf559a@giant.haxx.se) 08.45.21 Quit webguest67 (Client Quit) 08.47.39 Quit dionoea (Changing host) 08.47.39 Join dionoea [0] (~dionoea@videolan/developer/dionoea) 08.47.52 # funman: What file you are running/listening on your Clip+ actually? 08.48.18 # mp3 stereo 44.1kHz @192kbps 08.49.27 # So I think you almost beat Fuze v1 actually. Congratulations. 08.51.47 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 09.00.23 Quit dmb (Quit: Leaving) 09.00.56 Quit froggyman (Ping timeout: 265 seconds) 09.01.12 *** Saving seen data "./dancer.seen" 09.01.12 Join froggyman [0] (~me@unaffiliated/froggyman) 09.01.18 Quit dmb_ (Quit: Leaving) 09.01.59 # rated battery life is only 15 hours, so getting 13 now is really impressive 09.03.05 # that makes me think we forgot something really stupid in the AMSv1 09.03.16 Quit ender` (Quit: Smoking is one of the leading causes of statistics.) 09.03.31 # it would be nice to dump the as3517 registers when the OF is running and playing to compare 09.16.34 Join ender` [0] (krneki@foo.eternallybored.org) 09.21.22 Quit leavittx_ (Ping timeout: 258 seconds) 09.21.31 Quit leavittx__ (Ping timeout: 240 seconds) 09.21.45 Quit leavittx (Ping timeout: 258 seconds) 09.24.04 # funman: did that patch I did for you work? 09.24.18 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 09.24.41 # didn't test 09.25.05 # do you have a target with FM ? 09.26.26 # not for another week or so when my boxes get here 09.27.28 # it used to be about an extra hour battery life if you leave it in the menus yeah? 09.27.32 # i thought kugel might be more aware than me of what/how needs to be done 09.27.37 # (general target independant rule) 09.27.42 # hm? 09.27.53 # randomly asking the channel... 09.28.19 Join Luca_S [0] (~5d3fc54b@giant.haxx.se) 09.28.56 Join stooo [0] (~sto@g227066084.adsl.alicedsl.de) 09.29.36 Quit stooo (Client Quit) 09.30.46 # hm that can't be right, GPIOB_PIN1 should be the fm i2c scl, but it is the home button on fuzev2 .. 09.30.53 Quit togetic (Ping timeout: 245 seconds) 09.33.05 # gevaerts, Torne: The strange thing is that I observe this boot slowdown on archos as well, which doesn't have dircache at all 09.33.44 # Boot charting is in svn now, but that doesn't help when going back... 09.35.19 # Torne: If it has no ill side effects, we could probably turn on LBA48 for all ata targets except the archoses 09.35.45 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 09.36.00 # The latter is due to the fact that you can't use >128GiB on those anyway without taking additional measures, since the usb-ata bridge doesn't support lba48 either 09.36.34 # (You'll need a multivolume build and two partitions, having access to the 2nd partition in rockbox *only*) 09.38.14 Quit linuxstb (Ping timeout: 258 seconds) 09.40.50 # * JdGordon starts a batt bench in the menu to compare with wps usage 09.40.58 # have a good weekend all 09.41.03 Quit JdGordon (Quit: Leaving.) 09.46.17 # funman: when looking at debug ports, pressing the home button does not change the value of any of the GPIO indicator 09.46.21 Join einhirn [0] (~Miranda@p54858DB8.dip0.t-ipconnect.de) 09.46.46 # does home button work anyway? 09.47.03 Join einhirn_ [0] (Miranda@vpn10.rz.tu-clausthal.de) 09.47.04 # "hotkey not set" in the file browser 09.47.14 # so, it does something 09.47.22 # in the wps, it takes me to the playlist 09.48.00 # btw about the date I did that: change in rockbox, reboot to OF, change in the OF => and then both were synced 09.48.40 # ok, trying right now (damn me, today I forgot the sansa cable at home) 09.49.22 # mc2739: does this ring you a bell about RTC on sansas ? 09.50.31 Quit einhirn (Ping timeout: 240 seconds) 09.51.23 # ok, works for me too 09.52.07 Join flydutch [0] (~flydutch@host225-165-dynamic.15-87-r.retail.telecomitalia.it) 09.52.19 # did you see the report about i2s panic I had last night? 09.52.33 Join togetic [0] (~togetic@unaffiliated/ibuffy) 09.53.00 # yeah 09.53.13 # I was messing with recording etc 09.53.23 # but I only had it once 09.53.31 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 09.53.54 Join stoffel [0] (~quassel@p57B4C277.dip.t-dialin.net) 09.53.56 Quit einhirn_ (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 09.54.16 Join einhirn [0] (~Miranda@p54858DB8.dip0.t-ipconnect.de) 09.55.20 # how strange.. the wps just disappeared o_O 09.55.30 # I activated random folder advance 09.55.36 # then pressed next while playing 09.55.50 # and the wps backdrop disappeared 09.56.06 # ah so i wasn't dreaming yesterday =) 09.56.07 # reappeared by opening the menu and back 09.56.54 # also: the volume can't be set to mute (other samsa have this glitch, isn't it?) 09.57.06 # yes i think it's written in SansaAMS wiki 09.57.13 # moving the scrollwheel does not turn on the backlight 09.57.32 # other buttons do? 09.57.44 # (in the wps screen) 09.57.44 # yes 09.58.03 Join JanDo [0] (~JanDo@212.44.150.75) 09.58.34 # well, not exactly true 09.59.02 # it makes it brighter when its dim, but does not turn it on when it's off 09.59.11 # maybe it's by design? 09.59.59 Join mischasworld [0] (~quassel@p5B215158.dip.t-dialin.net) 10.00.14 # no change in brightness for me 10.00.24 # * pamaury has got a shinny new Clip+ ! :) 10.00.37 # but yeah it doesn't turn the backlight on 10.00.46 # pamaury: great! quick write the USB driver ! :) 10.00.50 # :D 10.00.58 # yeah, do we have some doc ? 10.00.59 # the power button is on 2nd bit from the left of D2, confirmed (on the wiki page it says Power?) 10.01.08 # pamaury: how boring ... you want a rockboxed used clip+ :) 10.01.25 # pamaury: give me your email and i send you the linux patches for as352x/as353x 10.01.26 # * pamaury first need to install rockbox on it, and even before, need to open the box 10.01.31 # (replace D2 with GPIOD) 10.01.56 # Luca_S: you have a wiki account, 10.01.58 # ?* 10.02.21 # life is beautiful: jewels works fine! :D now my boss has to threaten me to get me back to work :D 10.03.14 # funman: maybe, long time ago I sent a wps - will need to check if i can recall the credentials 10.04.00 # pamaury: we have a lot of info on the USB controller, see the USB note here: http://www.rockbox.org/wiki/SansaAMS#Port_Status 10.04.14 # saratoga_lab: it might be a little different from as3525 though 10.04.35 # ah good point 10.04.47 # btw I tried to write some code for AMSv1 but i still don't understand completely although I had some feedback in both the OS & the device (sometimes) 10.06.30 # funman: I'm not on the wikiusers page so no, I don't have an account 10.06.44 # create one and we'll approve you 10.07.09 # though I'm on the UserList 10.07.25 # LucaLeonardoScorcia 10.09.54 # you're in WikiUsersGroup so it should be ok i guess 10.11.02 Join kramer3d [0] (~kramer@unaffiliated/kramer3d) 10.13.37 Quit kramer3d_ (Ping timeout: 246 seconds) 10.17.35 # Luca_S: i don't know why backlight isn't shown when scrollwheel is turned, perhaps kugel will know 10.18.25 # I start to suspect there's something wrong with the debug io/ports screen 10.18.38 # why ? 10.18.57 # the hold button doesn't show any change, but it gets detected 10.19.18 # (i.e. it works) 10.19.29 # same for the home button 10.19.49 # if i read correctly, one has to write on some pins before reading buttons 10.20.02 # so you won't necessarily see it in IO ports 10.20.11 Quit shaggy-h (Ping timeout: 240 seconds) 10.20.43 Quit einhirn (Ping timeout: 260 seconds) 10.21.07 # ah, that would explain it - I won't change the wiki page then. maybe a dedicated item in the debug screen "test button readings" would be useful 10.21.22 # if they work in rockbox, no need to test =) 10.21.39 # strange that the power button gets detected all the time as a gpio change however 10.22.19 Join merbanan [0] (~banan@c-62-220-165-110.cust.bredband2.com) 10.23.41 # jhMikeS: Do you think you'll be around Rockbox this summer and able to help out with any mpegplayer SoC project? 10.25.29 # jhMikeS: do you have plans for the voltage/freq scaling on the beast+ 10.25.36 # s/+/? 10.28.15 Join anubisfremen [0] (~c18cf902@gateway/web/freenode/x-paxbhnyyubyobmee) 10.28.44 Nick anubisfremen is now known as Guest12483 (~c18cf902@gateway/web/freenode/x-paxbhnyyubyobmee) 10.29.14 # pamaury: you say you find the storage_* integration awkward. Do you mean something else than that the current patch is done half in ata.c and half in storage.c in a random looking way? 10.31.32 Quit togetic (Ping timeout: 260 seconds) 10.31.33 # no I mean that :) Perhaps there should be a cleaner interface between storage.c and ata.c/mmc.c/... regarding this point but perhaps I'm wrong, I know nothing about the storage, it's juste that I find it bizarre :) 10.32.20 # OK, everything is fine then :) That's the bit that needs work 10.33.04 # Guest12483: which codec were you interested in? 10.33.34 # As to whether it makes sense for flash, I'd say yes. While latency is of course much lower, these background threads are still using up valuable bandwidth that's needed by user-visible things like actually buffering 10.33.35 Quit Guest12483 (Quit: Page closed) 10.35.39 Quit phanboy4 (Ping timeout: 265 seconds) 10.36.02 Join emrecelikten [0] (~c18cf902@gateway/web/freenode/x-qabfmrgrnpjvdavj) 10.36.06 # OK, I am back 10.36.13 # Well I am interested in AAC 10.36.20 # The difference seems quite big 10.36.40 # I think I may be able to improve the performance of that one. 10.37.22 # emrecelikten: thats a good project 10.37.27 # i think a lot could be improved there 10.37.43 # have you done any codec stuff before 10.38.13 # Sadly, no. But I am generally interested in signal processing, I think I can handle it 10.38.41 # i take it you've done a DSP course before? 10.39.24 # Well, sort of. Not officially though, yet 10.39.30 # Went to the lectures 10.40.26 # I plan to go for a Ph. D. in speech synthesis 10.40.48 # have you taken a class in fourier series or transforms or any related math? 10.42.15 Quit Kitr88 (Ping timeout: 258 seconds) 10.43.02 Join Kitr88 [0] (Kitr88@BSN-182-4-208.dial-up.dsl.siol.net) 10.43.32 # Not officially, as I have said. But I am sure that I can handle it :) 10.44.19 # thats ok 10.44.38 # its not required that you have done all the calculus, though the project may be a little harder if you have not 10.44.43 # emrecelikten: Do you have any C and/or assembly language experience? 10.45.09 # Yes, I do. I'm a third year computer engineering student. 10.45.20 # Also with a minor on electronics and communications engineering 10.46.07 # have you done any ARM programming before? 10.46.10 # I can program a 8051 with assembler 10.46.13 # No, I haven't 10.46.28 # MIPS? 10.46.46 # thats what we did when i was in undergrad anyway 10.47.00 # emrecelikten: I don't think that's a problem though - ARM is very easy to pick up if you're comfortable with low-level programming. 10.47.33 # I think I may be able to learn that easily, they're almost all the same 10.47.50 # emrecelikten: Do you own any Rockbox devices? 10.48.24 # No, I won't be able to test the code on a real device 10.48.35 # But I remember that you had emulators for that? 10.48.40 # no 10.48.46 # I can buy one as well 10.48.56 # We have simulators, not actual emulators 10.49.00 # Yes, you really need to get at least one if you're going to work on Rokcbox. 10.49.07 # Ok, will do 10.49.16 # The simulator is the Rockbox code compiled to run on a PC - so not useful for benchmarking etc. 10.49.35 # we can develop codecs on PC, but actual optimization requires hardware 10.49.48 # True 10.49.59 # If you'd get accepted, you get enough money to buy one cheap second hand player :) 10.50.00 # so usually its something like verify algorithmic correctness on PC, then move to the device for optimization 10.50.23 # I was thinking about algorithmic optimizations first 10.50.35 # yes thats something that can begin on PC 10.50.49 # certainly in the case of libfaad since we'll probably want to rewrite large parts of it 10.50.51 # But I will buy one then 10.51.27 # depending on where you are, sandisk players can be very cheap and are arm9 based 10.51.49 # that reminds me, are you familar with the idea of fixed point calculation? 10.52.00 # i don't expect that anyone who hasn't done codecs has actual experience with it 10.53.30 # Well, you are right :) 10.53.43 # ok so thats another thing to look at 10.54.00 # basically its just doing decimal operations approximated with integers rather then floats 10.54.11 # lots and lots of that involved in this project 10.54.38 # since we think the ffmpeg versions of most of the algorithms involved in AAC-LC (and probably all of the AAC-HE) are better then the ones we have 10.54.42 # but they're all floating point 10.54.48 # which we can't use 10.54.59 # So we have to convert them to fixed-point, right? 10.55.05 # yeah 10.55.25 # Okay 10.55.42 # so all the * operations become function calls 10.55.49 # I have found some Sansa players, is there a specific one that you recommend? 10.56.15 # Like C240 for example 10.56.15 # the e200, clip, or fuze 10.56.24 # the c240 will work as well 10.56.30 # Or will any E2x0 will do? 10.56.40 # the e series is good too 10.56.42 # well, c240v1 will work. c240v2 might not 10.56.53 # good point 10.56.53 # the e series all work 10.57.09 # which time zone are you in? 10.57.14 # GMT+2 10.57.40 # I will get an E then 10.58.22 # in the US at least, the clips are the cheapest by far 10.58.55 Quit bluebrother (Disconnected by services) 10.58.55 Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) 10.59.13 Nick bluebroth3r is now known as bluebrother (~dom@rockbox/developer/bluebrother) 10.59.42 # clip may not be much fun for video though 11.00.00 # n1s: this is audio I think 11.00.05 # ah, wron project, sorry 11.00.20 Quit kramer3d (Quit: Leaving) 11.01.16 *** Saving seen data "./dancer.seen" 11.02.45 # Hmm OK then 11.02.50 # Anything else that I should know? 11.03.21 # c200v2 works quite well, some patching might be involved though but we can provide help on this 11.03.51 # your proposal should try and show that you're motivated, aware of what the project will involve, etc 11.04.43 # Clip+ 15h runtime, still running \o/ (at 60MHz, will try 24MHz when this test is finished) 11.04.47 # but looking into how the aac spec actually works is probably impractical given the complexity of it 11.04.55 # wow 11.04.59 # beating the OF already 11.05.16 # emrecelikten: My advice would be that very few potential students get involved with Rockbox before SoC. If you do that, and show you know what you're doing, you would increase your chances. 11.05.30 # Luca_S: could you bench the battery on your fuzev2 ? 11.05.39 # wow...nice runtime for the clip+ 11.05.43 # congrats. 11.06.49 # Okay, thanks for the tip. I know I haven't done any work on this field before but this one seems quite interesting for me, that's why I'm here 11.06.59 # I will try to progress before SoC 11.07.20 # SoC is not that important actually, I want to spend my summer working on something 11.07.37 # And SoC would force me to do it 11.07.38 # well even if you don't end up doing SoC you're certainly welcome to hang out here 11.07.44 # Thanks 11.09.27 # I will try to learn about fixed point arithmetic in my spare time now, then 11.09.35 # That's almost the first think I need to do anyway 11.09.40 # Thanks for the tips, I have to go now 11.09.40 # that should be pretty straight forward 11.09.50 # *thing 11.09.51 # its mostly just annoying more then anything 11.10.28 # i told someone else who asked about the codec projects to look at how jpeg works on wikipedia 11.10.54 # since its basically the simplist codec possible, and most of the stuff in jpeg is in all codecs for audio or video 11.11.14 # jpeg is based on DCT? 11.11.37 # correct 11.11.41 # :) 11.11.45 # not jpeg2000, though 11.11.48 # that uses wavelets 11.11.53 # no wonder it fails :D 11.13.50 # fails how? it's smaller at the same and has a number of interesting features... it's just too slow and complex :/ 11.14.05 # I think it's shown that wavelets don't work well with image 11.14.11 # at least the recent implementations 11.14.18 # is wavelet used with audio signals? 11.14.42 # funman: it's been tried by a number of forgotten proprietary codecs ;) 11.15.30 # it's of some benefit with handling transients but never seems to beat mdct overall 11.15.56 # funman: not today unluckily: it's not fully charged and i forgot the cable at home. from a subjective estimate the consumption seems in line with the OF, the battery indicator also seems well calibrated. I'll charge this evening and bench it tonight. 11.16.28 Quit emrecelikten (Ping timeout: 252 seconds) 11.16.51 # funman: no, the DCT family seems to work better then wavelets for audio 11.17.02 # Luca_S: i plugged the output to my soundcard and record PCM (needs loads of free space), and I look at the recorded data to see at which time it stopped 11.17.13 # i don't think theres ever been a wavelet audio coder outside of scientific literature 11.17.38 # some (biased?) view on wavelets in video coding: http://x264dev.multimedia.cx/?p=317 11.18.22 # i think the reason the dct is so hard to beat is that our ears are basically fourier transformers, so its hard to beat a fourier transform based coder 11.18.33 # its sort of the "natural" choice 11.19.38 Join togetic [0] (~togetic@unaffiliated/ibuffy) 11.19.50 Quit saratoga_lab (Quit: Page closed) 11.24.00 # hm.. after a panic, rockbox rebooted and as soon as it booted, the 'shutting down' message appeared and shutted down the player 11.24.33 # i've seen that also 11.31.29 # Kohlrabi: my experience has been that jpeg2k looks better at high compression, but as one of the commenters points out, a wavelet codec can effectively encode the image at a lower resolution to achieve high compression ratios 11.32.00 # I'd guess that it also highly depends on the source 11.32.24 # Sinc efrom my understanding wavlets can effectively code global patterns 11.32.29 # Since from* 11.32.55 # I never dug into coding, though :( 11.33.36 # clip+ stopped at 15h30 11.33.47 Quit mischasworld (Ping timeout: 245 seconds) 11.33.53 # nice... 11.34.10 # :O 11.34.15 # afaik the most useful thing done for audio with anything quite like wavelets is transform-based lossless (useful since the transform approximates mdct and can scale to lossy) 11.34.31 # OF+30, that's not to be sneezed at, in this stage of development. 11.35.13 # wow 11.35.22 # I didn't chekc rb for some time 11.35.33 # How did the Clip+/v2 port progress that fast? :O 11.35.41 # funman? 11.35.45 # ;) 11.35.46 # amazing 11.35.55 # most of Clipv1 code could be reused as-is, some other parts needed only little modifications 11.36.09 # modest...I like it ;) 11.36.22 # Now I wished I didn't give my Clipv2 away 11.36.28 # oh well 11.36.54 # "Externalk Storage": "Yes" means that you can also read the micro-SD? 11.37.13 # funman: Congratulations on your work 11.37.26 # Kohlrabi: right 11.37.31 # oh my 11.37.47 # That's so awesome, after 1.5 years I wil use rb again :D 11.38.50 # funman: any caveats before I put rb on my Clip+? 11.39.42 Quit n1s (Ping timeout: 252 seconds) 11.40.13 # everything is written on SansaAMS page of the wiki but basically: writing doesn't work, expect some crashes, and volume can't be set very low 11.40.40 Join dfkt [0] (dfkt@unaffiliated/dfkt) 11.41.49 # OF is advertised as running 15 hours, so we already do better 11.41.59 # great 11.42.14 # The battery lifetime with vorbis q5 already starts to annoy me a bit 11.42.46 # wait 11.42.59 # I hope the SansaAMS is no april fool's page? :D 11.43.25 # i didn't try vorbis though 11.44.58 # funman: Hello. My Clip+ runtime 15h40min and still running. Played FLAC v8 75%vol(-13) in KOSS the PLUG 11.45.11 # JanDo: nice ! 11.45.39 # i'm just recharging it and will try a build with reduced CPU speed 11.46.01 # can you compile your own rockbox build? 11.46.40 # JanDo: btw which revision did you run ? 11.46.41 # yes, yesterday i co SVN code and setup Cygwin. 11.47.17 # now testing at r25423 11.47.21 # http://pastie.org/900094 <- here is the patch i'm going to try 11.50.28 # funman: do you know about the pitch hifts in the orignal firmware? Is rockbox affected by that, too? 11.51.41 Join n1s [0] (~n1s@rockbox/developer/n1s) 11.55.46 # I have my music organized as /Artist/Album/Track.mp3. is there any way to say "play everything" without using the database? 11.56.25 # * S_a_i_n_t suspects to see better than 15:30 going down to 24MHz 11.56.40 # Kohlrabi: http://www.rockbox.org/tracker/task/10906 11.56.48 # the previous test was at 60MHz, no? Or was it at 30? 11.57.22 # Luca_S: make a playlist? 11.57.31 # saratoga: 11.57.33 # ops 11.58.42 # thanks 11.59.15 # sorry, i meant S_a_i_n_t: fuzev2 doesn't have write support - I got close with random folder advance, but with it the shuffle setting is useless since it shuffles in the current folder 12.00.06 # make playlist manually, on a PC? 12.00.36 # wow...apparently I miss words at random now...ooops :/ 12.01.38 # oh, I didnt think of that - is the file format documented anywhere? i can't seem to find it in the wiki 12.02.30 # having not ever used a playlist once, I can't say sorry...perhaps the manual? 12.02.40 # (note: not a RTFM comment) 12.02.58 Join Multiplex [0] (~5773e1e8@giant.haxx.se) 12.04.27 # is the only way of getting the source to use SVN? I mean it used to be possile to get a tarball of the source 12.04.50 # Google will help me, thank you. RTFM would have been perfectly fine anyway :D 12.06.49 # Source Tarball used to be on the Daily Build page, I take it that isn;t the case anymore? 12.08.50 Quit Adubb (Read error: Connection reset by peer) 12.09.31 # No, - I followd the link from currnet builds page that said that "Daily builds, voices, fonts and source" but I can't see the source or the voices there 12.10.03 Join einhirn [0] (~Miranda@p548584F9.dip0.t-ipconnect.de) 12.11.20 # S_a_i_n_t: 60MHz yes 12.12.18 # Kohlrabi: i didn't measure the real pitch, I assume there would be no difference between Clipv1 & Clipv2/+ but feel free to verify 12.12.22 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 12.13.03 # hm sorry, since we run the PLL at a different frequency it will be different 12.13.09 # ah 12.13.17 # good 12.13.42 Join BlackSwan [0] (~kvirc@80.93.115.29) 12.13.58 # Hi 12.15.19 # Where can I found DominikWenger? 12.16.18 # he's domonoky on irc, he's often here on the evenings but he'll read the logs 12.16.30 Join leavittx [0] (~leavittx@89.221.199.187) 12.16.32 Join leavittx_ [0] (~leavittx@89.221.199.187) 12.18.07 Quit Rob2222 (Ping timeout: 265 seconds) 12.18.12 # funman: O... 12.18.23 # BlackSwan: Also, ask your question to the channel, maybe someone else could answer you. 12.19.11 # BlackSwan: evening means evening in european time 12.19.12 # I want speek about his themes on summerOfCode2010 12.19.51 # BlackSwan: there are not "his" themes. He's volunteered as potential mentor for some project ideas. 12.20.32 # Hm... And what that means? 12.20.42 # BlackSwan: The mentor for this project has not been decided yet. 12.21.17 Quit Multiplex (Quit: CGI:IRC (EOF)) 12.21.24 # * bluebrother wonders what the project is BlackSwan is talking about 12.21.31 Quit liar (Ping timeout: 258 seconds) 12.21.55 # But if I want to try help You with web-site... With him i must speak? 12.21.57 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 12.21.57 # besides, as a student you should generally consider the community your primary mentor. The assigned mentor is responsible for some paperwork stuff 12.22.05 # theme editor ? Although now that I think of it, maybe I jumped to a conclusion too quickly 12.22.11 # BlackSwan: talk to the community. 12.22.27 # * bluebrother 's guess was the "web services" stuff 12.22.48 Join Rob2222 [0] (~Miranda@p4FDCB716.dip.t-dialin.net) 12.23.43 # I can code on PHP,HTML, some JavaScript... Works with mySQL... 12.24.09 # BlackSwan: if you have questions just ask. This channel is logged, so people can read the logs. If they don't someone can point them to the logs :) 12.25.39 # Question is - how and with who I nedd comunicate, to help with web services? 12.25.49 # *need 12.28.17 # how is easy: the same way all other developmen communication happens. Most happens on IRC, but the mailing list is also a channel (though noticably less used than IRC for development talk) 12.29.53 # Oh... I dont think that posting here my e-mail but... grafmailgraf@mail.ru 12.29.59 # who is a bit more complicated as a couple of people did work in the web services we already have. domonoky is the one who was recently working on the theme site. 12.30.11 # I hope there are no spammers ^) 12.30.15 # BlackSwan: err ... I was not saying anything about posting an email address. 12.30.16 # :) 12.30.30 # amiconn: well, if you extract the bootchart patch you can apply it to older revisions, and just throw away the bits that don't apply ;) 12.30.44 # I was saying that the mailing lists are used as well for development talk. 12.31.31 # do we have somewhere i can upload some test builds to, or shall i just stick tehm on my own httpd 12.31.45 # I assume you've read the "Information for students" section on the SummerOfCode2010 wiki page? 12.32.05 # bluebrother: O, it was my idea :) 12.32.14 Quit funman (Quit: free(random());) 12.32.28 # Torne: I don't think we have 12.32.37 # I usually just host test builds myself 12.32.54 # BlackSwan: your idea as in that you didn't pick it out of the project ideas on the SummerOfCode2010 page? 12.33.39 # bluebrother: my idea was posting e-mail... 12.34.36 # gevaerts: the list of people having problems of one kind or another that might plausibly be caused by the startup workaround thingy is getting rather long, so I'm gonna do a big pile of builds with the clearing-iram fix in instead 12.36.35 # Torne: I've forgotten to ask, how's your ipod going since that patch? 12.37.11 # I must go away... I hope some body from developers send to my E-mail... 12.37.20 # S_a_i_n_t: still works perfectly fine 12.37.40 # S_a_i_n_t: but the instant i started bisecting the other day and went to an old revision, my ipod immediately locked up and needed resetting after shutdown ;) 12.37.55 # S_a_i_n_t: which kinda proves that my player still does it. Just not if you clear iram. So i think we win :) 12.38.01 Quit BlackSwan (Quit: When two people dream the same dream, it ceases to be an illusion. KVIrc 3.4.3 Shiny(svn-3438) http://www.kvirc.net) 12.38.32 # is there a FS task where I can follow this? 12.39.00 # 11149, sorry for asking before looking 12.39.30 Join kugel [0] (~kugel@rockbox/developer/kugel) 12.40.45 # anyway, when i'm actually properly awake I am going to do a test build with that change for all the relevant models based on current and 3.5 12.40.59 # in the hope that *some* of the people affected will test ;) 12.42.22 # Or give "shutdown troll" something new to complain about ;) 12.44.04 # Torne: Any idea how long iram will keep its content? 12.44.44 # linuxstb: eternally, as far as i understand 12.44.55 # well, yaknow. until the battery runs out. 12.45.04 # I think it's kept powered when the pcf goes to deep standby 12.45.18 # i could be wrong 12.45.23 # OK, so the time the ipod is "off" shouldn't affect the reliability of power-on? 12.45.32 # don't think so. 12.45.46 # I have previously had the poweron issue come up immediately after powering off, or when powering on after it being off all night 12.46.08 # tbh i am wildly speculating here 12.46.19 # the clearing iram thing is basically a big guess with no "scientific" basis ;) 12.46.26 # but it appears to work 12.46.53 # Well, the Apple bootloader checks iram for things, so it's a plausible theory. 12.47.24 # What if you write the "diskmode" magic to iram, then power-off? Does it always then start in disk mode? 12.47.29 Join Geert_van_Dijk [0] (~chatzilla@cc412026-a.zwoll1.ov.home.nl) 12.47.30 # Ooh 12.47.35 # That sounds like science :) 12.47.39 # i'll try that in a few 12.47.40 # * linuxstb apologises 12.47.53 Nick Geert_van_Dijk is now known as geertvdijk (~chatzilla@cc412026-a.zwoll1.ov.home.nl) 12.48.09 # the parts of the bootloader i have disassembled basically mean that when it boots the OF it writes some magic string to iram 12.48.20 # and if it sees that magic string *again* on next boot it assumes the battery is dead 12.48.37 # because it assumes that spinning up the hard disk caused the voltage to drop too low to run the system 12.48.37 # That also sounds like science... 12.49.05 # which is a fair-enough thing to do 12.49.26 # it avoids the Beast reboot loop situation, i suspect ;) 12.49.43 # so i think we are maybe triggering *some* of this logic by accident 12.49.58 # (probably not all of it, there's more than just the one thing in iram, it has several flags that i've not figured out) 12.50.15 # so we're sending the bootrom down a path that it shouldn't ever see and it's doing half of the "no battery" logic then falling over 12.50.55 # but logically the bootrom should always work if IRAM is empty, because that's what happens after the battery *does* die completely and then gets recharged, and probably also on hard-reset 12.52.11 # what would happen if the IRAM would get cleared on poweroff? Shouldn't that be similar to when the battery got ran out completely? 12.52.28 # * bluebrother finds that error message on shutdown pretty annoying 12.54.40 # bluebrother: yes, that's what I'm doing 12.54.45 # bluebrother: FS#11149 12.54.58 # bluebrother: i've tested this for a week or so on my player and not had the poweron issue. 12.55.05 # i'm gonna put up test builds in a bit 12.55.59 # I've failed to see the "batt low" icon on shutdown once, the only time I see that icon it usually means "white screen of death" on the nanos 12.56.16 # nice. Got to try this (though my mini was rarely affected by the shutdown problem anyway) 12.56.29 Quit leavittx (Ping timeout: 240 seconds) 12.56.37 # S_a_i_n_t: it appears that on some players it is either relly hard to see or actually not visible 12.56.47 # S_a_i_n_t: our shutdown process has already turned off the backlight *and* the lcd where possible 12.56.58 # S_a_i_n_t: but on at least some models/firmwares the OF turns the lcd back on 12.57.12 # (though not the backlight) 12.57.33 Quit leavittx_ (Ping timeout: 258 seconds) 12.57.38 # On my nanos at least, if the backlight is off, and the idle shutdown occurs it actually turns the backlight *on* for shutdown. 12.57.51 # not sure if thats some setting of mine or not though. 12.58.05 # Both generations? 12.58.16 # pretty sure. 12.58.22 # the backlight coming on when idle shutdown kicks in is normal.. 12.58.24 # i think. 12.58.28 # I'll check, one sec. 12.58.30 # the "idle shutdown" event counts as a UI interaction 12.58.37 # so it makes the backlight come on ;) 12.58.44 # The shutdown process later does turn the backlight off. 12.58.53 # Ah, I thought it was a bit weird...thats all. 12.59.42 # New commit by 03bluebrother (r25435): Warn when selecting system proxy settings with invalid values. ... 13.01.18 *** Saving seen data "./dancer.seen" 13.08.35 Join leavittx [0] (~leavittx@89.221.199.187) 13.08.47 Join leavittx_ [0] (~leavittx@89.221.199.187) 13.11.25 # Torne: Yes I can do that (and there is no ;) ), but that would have been a reason to leave it as a patch 13.11.42 Quit stoffel (Ping timeout: 246 seconds) 13.13.22 Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) 13.14.58 # amiconn: well, it's not just for looking into the past.. 13.20.25 Part JanDo (" www.qip.im ") 13.24.14 Join Casainho [0] (~chatzilla@87-196-52-105.net.novis.pt) 13.25.32 Join JanDo [0] (~JanDo@212.44.150.75) 13.39.15 # ah, blue fixed my yellow 13.39.24 # i didn't notice because the buildserver was broken ;) 13.40.34 # moos: you might want to try FS#11167 14.05.07 Join funman [0] (~fun@rockbox/developer/funman) 14.05.36 Join jeffp [0] (~jeffp@barmen.interhost.no) 14.06.57 Part jeffp 14.07.01 # should a battery charging graph look logarithmic ? (charges slower and slower) 14.10.09 # bluebrother, AlexP_, others: I cleaned up goban.tex in two parts - the button table and used [item] for the submenus as well - (a) I'm not a 100% sure if we agreed on the latter, does someone remember? (b) is it worth it to split a commit into two parts or not? 14.10.34 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 14.11.24 Quit geertvdijk (Read error: Connection reset by peer) 14.13.32 Join webguest44 [0] (~5edf559a@giant.haxx.se) 14.13.41 Quit webguest44 (Client Quit) 14.13.50 Join stoffel [0] (~quassel@p57B4C277.dip.t-dialin.net) 14.14.29 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 14.17.17 Quit stripwax (Read error: Connection reset by peer) 14.20.06 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 14.20.32 # I opened a poll for frequency of crashes on Clipv1 : http://forums.rockbox.org/index.php?topic=24375.0 14.21.01 # funman: is "Official test builds" really the place for that? 14.21.10 # I figured "Official Test Builds" was the good forum category since you need the Official (Test) Current build 14.21.26 # The current build is not a test build 14.21.42 # No ? 14.22.22 # no. That forum is for modified builds by developers who want to get more widespread testing of a patch 14.22.57 # Where shall I put this forum poll ? 14.23.32 # Audio Playback perhaps 14.24.03 # pixelma: I'm not aware of an agreement on using items for submenus or not (but maybe I simply didn't notice) but IMO it's a good idea. 14.24.12 # I'd say general discussion. That's where Torne put the ipod shutdown poll, so there's a precedent. Audio Playback might be good as well 14.24.30 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 14.25.02 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 14.25.10 # pixelma: no idea if it's worth splitting the patch in two commits. Won't hurt but I don't think it's necessary. 14.25.22 # as the changes rely to the same thing 14.25.51 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 14.28.42 Quit JanDo (Ping timeout: 246 seconds) 14.28.42 # bluebrother: I just saw that there are even more changes in this file. In the introduction there are a few \\ to force newlines which I removed 14.29.51 Quit mitk (Quit: Leaving) 14.29.56 # pixelma: there was some talk about forcing newlines with \* a while ago. It might be good to discuss if paragraphs should use indents or blank lines 14.37.52 # ok, so leave the change out of the commit for now? 14.38.08 # just referring to the newline one 14.38.40 # pamaury: regarding your question about translations the other day: I'm not aware of any policy for that. If you update a translation and feel confident enough about it just commit it. 14.39.15 # at least I can just commit contributed translations, and I haven't seen anyone reviewing them before. It would be good to have, though. 14.39.19 # ok, I'm not sure about consistency mainly 14.39.30 # it's just that someone needs to understand the language for reviewing :) 14.39.42 # but go on, I'll continue this week-end or tonight 14.39.50 # I guess it's better than nothing 14.39.51 Join steve|m [0] (~steve@p4FD47C96.dip.t-dialin.net) 14.39.59 # pixelma: well, \\ forces a newline while \* a new paragraph so those are a bit different. 14.41.42 # funman: I get some error messages about playlists not found when trying to playback vorbis files on Clip+ 14.42.36 # Kohlrabi: if playback starts fine after the message, then it's alright: it's just complaining that it can't write a playlist file to disk 14.42.45 # ah 14.42.50 # It starts fine 14.43.01 # though the text is a bit garbled on the display 14.43.18 # But all in all it works very well already. 14.45.04 # yeah, rockbox on Clip+ !! 14.45.51 # it didn't use to run on the clip+ right? (new port?) 14.46.12 # it's unstable 14.46.36 # so is the gigabeat S port. but that's what I'm using and its flawless :D 14.47.13 # arbingordon: only for some people ;) 14.48.06 # bluebrother: is that a yes or no - or shall I replace \\ with \* ? 14.48.39 # arbingordon: just wait until that thing decides to format its disk right when you wanted music :) 14.48.46 # funman: I can confirm that the volume doesn't get very low, if you still had a doubt :) 14.49.00 # pixelma: I would remove the \\ if it makes sense. 14.49.08 # i.e. go with what you currently have :) 14.49.34 Quit xavieran (Quit: ➤➤➤➤➤➤ UniCode shall rein forever! ➤➤➤➤➤➤) 14.49.53 # I should probably do some test compiles which would also tell me how it looks in the PDF... ;) 14.50.22 Join xavieran [0] (~xavieran@ppp118-209-242-153.lns20.mel6.internode.on.net) 14.54.32 Join JanDo [0] (~JanDo@212.44.150.75) 14.57.36 Quit stripwax (Quit: http://miranda-im.org) 15.01.19 *** Saving seen data "./dancer.seen" 15.05.26 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 15.08.00 Part JanDo (" www.qip.im ") 15.10.26 Join Schmogel [0] (~Miranda@p3EE21B8F.dip0.t-ipconnect.de) 15.13.35 Join JanDo [0] (~JanDo@212.44.150.75) 15.14.12 # http://forums.rockbox.org/index.php?topic=24376.0 <- does this make sense 15.14.17 # (test build for startup issue) 15.14.39 # domonoky: I noticed on DevConEuro2010 that your name is on the list of people who'll attend DevCon, but not on the list of people who want a bed 15.15.21 # uh, someone must have removed that.. 15.16.59 Quit FlynDice_ (Remote host closed the connection) 15.33.35 # * Torne tries to remember all teh things he told people he would do/investigate so he can make a proper todo list, and fails 15.37.04 # hm too bad the Fuzev2 crashed while testing battery 15.37.52 Quit Casainho (Quit: ChatZilla 0.9.86 [Firefox 3.6.2/20100316060223]) 15.38.29 # and the Clip+ stops charging at 63% ? 15.42.58 Quit pamaury (Quit: Quitte) 15.47.10 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 15.50.57 Join xou [0] (niko@eris.feh.name) 15.51.12 Quit funman (Quit: free(random());) 15.52.12 Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 15.55.34 # funman: which capacity is your fuze? 15.55.46 # Torne: Did you try writing the diskmode magic to iram before power-off? 15.55.52 # linuxstb: not yet 15.55.59 # gonna test that in a few 15.56.54 # mine is 8gb (+8gb uSD) tonight i'll try to fill it up to see if it reads correctly on the entire space 16.01.20 # hi, i'm thinking about applying for a GSoC-project at Rockbox 16.01.50 # the "Rockbox as an App" caught my attention 16.02.26 # is that project still available? :) 16.03.27 # xou: All projects are "available" until a student is selected. 16.04.25 # yes, the fuze has some problems. for example, sometimes playback just stops instead of continuing (I suspect the rebuffering fails) 16.04.52 # linuxstb: or two :) 16.05.12 # we might have 2 students working on RaaA (independently) since we want it so badly 16.05.31 # but that seems unlikely 16.05.32 Quit n1s (Ping timeout: 276 seconds) 16.06.04 # kugel: Anything is possible. But it's not worth thinking about until we have all the applications, and know how many student slots google give us. 16.06.06 # btw, I noticed that my fuze seems to get quickly hot when running the fft plugin 16.06.22 # now i stopped it to let it cool a bit 16.06.39 # i will try in a few minutes to exclude the "warm hands" cause :P 16.06.46 # ok... im really interested in having this feature beacause my iPod is probably breaking down soon and i already thought about making an app out of rockbox a few weeks ago 16.07.33 # and im probably going to buy some sort of android-based device as an replacement for my ipod 16.08.04 # you will need a decent application, we appear to have multiple applicants for RaaA 16.08.15 # ok 16.09.37 # hey wait what 16.09.46 # i just updated my regular build and now it *doesn't* take six seconds to load the font any more 16.10.01 # nah, I probably just left it on the laptop, sorry for the noise about the fft plugin.. 16.10.27 # what are the requirements for working on this project? i did a lot of C/C++ coding and some Java for University and some smaller projects, but mostly commandline-stuff, nothing with GUIs 16.10.41 # Torne: Congratulations - you fixed it! 16.10.48 # linuxstb: haha 16.10.52 # (unless it now takes 10 seconds...) 16.10.58 # linuxstb: no, it's practically instant now 16.11.05 # even if i delete glyphcache 16.11.12 # but i haven't changed anything! 16.12.14 # i didn't even catch up very far in svn, I was already only a few days out of date 16.12.23 # would i be required to have the knowledge on building GUI/Android apps already, or do you think it is possible to learn all that stuff while working on the project? 16.12.42 Quit Strife89 (Quit: Leaving.) 16.13.26 # xou: there are no "requirements", but you should expect that any experience in the items listed under skills involved helps a lot 16.13.48 # xou: In my view, the main requirement is that you're motivated and willing to put the hours into the project over the summer. But you should also realise that (in my view at least) a lot of the project won't be dealing with Android at all, it will be changing lots of parts of Rockbox to separate the "application" part from the "firmware/OS" part, and preparing an infrastructure for porting to something like Android. 16.15.07 # ok, thank you! 16.15.20 # linuxstb: no, it doesn't start diskmode if you write the string out before shutdown 16.15.33 # linuxstb: so that doesn't really prove anything either way :) 16.15.35 # Torne: I'm not sure what that proves though... 16.15.39 # ;) 16.17.18 # Oops. 16.17.26 # Bootchart has broken the ondio backlight mod :) 16.17.32 # i've stolen the letter "b" in configure from it by accident 16.19.25 # New commit by 03torne (r25436): Change bootchart to be "c" in configure, instead of "b" which clashes with the ondio backlight mod 16.26.59 Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) 16.27.56 # gevaerts: why do you need the info about the thread for fs#11167 16.27.57 # ? 16.29.26 # kugel: because the thing only cares about disk accesses if they were done by another thread 16.30.37 Join mitk [0] (~mitk@chello089078013146.chello.pl) 16.31.47 Quit pamaury (Ping timeout: 252 seconds) 16.33.33 Quit stoffel (Remote host closed the connection) 16.36.35 # saratoga: I was reading http://forums.rockbox.org/index.php?topic=13883.30 and wondered if you were aware that "VOB" is an an mpeg program stream? i.e. the container mpegplayer already supports. Or do you mean something else? 16.45.01 Join plauclair [0] (~p-l_aucla@dsl7-141.express.oricom.ca) 16.51.44 Quit linuxstb (Ping timeout: 258 seconds) 16.53.33 # this is my current draft if someone wants to look at it: http://pastie.org/900367 16.53.40 # comments are welcome 16.56.58 Quit xiainx (Ping timeout: 260 seconds) 17.01.21 *** Saving seen data "./dancer.seen" 17.03.57 # kugel: http://www.rockbox.org/irc/log-20100402#09:57:13 17.05.07 Part plauclair 17.05.15 # Luca_S: yes, I know about this issue, but I have no idea where the problem is 17.05.43 # ah, ok, sorry 17.07.02 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 17.07.50 Join xiainx [0] (xiainx@wpa062030.Wireless.McGill.CA) 17.08.51 # Luca_S: it's very strange 17.10.44 # also, i set the wheel light to always on. but when backlight goes off, it goes off the wheel light too 17.11.40 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 17.12.49 Join jgarvey [0] (~jgarvey@cpe-065-190-066-089.nc.res.rr.com) 17.13.04 # that's possible 17.13.05 Quit stripwax (Client Quit) 17.14.15 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 17.14.26 # I'm not sure if we can fix that 17.16.48 Join dockimble [0] (~dockimble@77.227.1.24) 17.17.09 Join anewuser [0] (anewuser@unaffiliated/anewuser) 17.18.48 Join stoffel [0] (~quassel@p57B4C277.dip.t-dialin.net) 17.18.53 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 17.18.59 # the brightness setting is not always coherent: often (but not always) if I move slowly from 1 to 2, the brightness stays the same. if I cycle between 1 and 2 repeatedly, it sometimes changes brightness. 17.22.37 # we'll look into it once we have fixed the real problems :) 17.23.28 # aha, i figured out why font_load takes 6 seconds for cabbie on my ipod 17.23.37 # the 15pt version of Helvetica is *way* bigger than the other sizes 17.24.05 # cabbie only uses 15pt on 320x240 or 240x320 screens, i.e. ipodvideo/beast 17.24.17 Join CGL [0] (~CGL@190.79.138.162) 17.25.43 # i guess the 15pt version contains more characters than the others 17.25.56 # it still shouldn't really take 6 seconds :( 17.26.07 # but if i load a smaller font it takes <0.5s 17.26.07 Quit merbanan (Ping timeout: 276 seconds) 17.26.15 Join merbanan [0] (~banan@c-62-220-165-110.cust.bredband2.com) 17.26.33 # switched to a wireless card that works 17.26.52 # Torne: profile it! 17.27.59 Quit stripwax (Read error: Connection reset by peer) 17.28.06 # saratoga: ping 17.29.13 # you're pitching yourself as a student for the RaaP GSoC project, kugel? 17.29.23 # RaaA even 17.30.50 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 17.30.57 # kugel: aha, it'sb ecause it's too big to load the whole font 17.31.07 # kugel: if the font's over 60000 bytes it has to use the glyph cache stuff 17.31.14 # if it's less than that it just loads the whole font file in one go 17.31.17 # which is way more efficient 17.31.34 # it seems like a bad idea to have the font used by the default theme be one that provokes this behaviour ;) 17.31.46 # since for me it makes font loading over ten times slower 17.31.58 # (might just be the 5.5G's crappy disk) 17.32.11 # Torne: But it's also good for the default font to support lots of characters.... 17.32.19 # linuxstb: yes, but it doesn't on every other device 17.32.29 # do ls -l *Helvetica* on the fonts 17.32.38 # the 15pt one is *way* bigger than all the others 17.32.46 # and onlt 320x240 devices use 15pt 17.32.56 # other devices use smaller (or bigger) versions, which presumably have less characters 17.33.02 # so if that's the motivation, we're not applying it very well ;) 17.33.25 # The "fix" to that problem isn't the one you want though... 17.33.30 # heh, indeed 17.33.55 # has someone got a non-ipodvideo device they can test on, with the bootchart? 17.34.06 # and see how long it takes to load a font that fits vs one that doesn't? 17.34.25 # 14-Adobe-Helvetica vs 15-Adobe-Helvetica 17.35.29 # playback stuck on fuzev2 (not a panic, just stopped playing while still responsitive, pausing and resuming does not help): would it be useful to tell you the values in the debug > buffer screen? 17.35.40 Join jennifur [0] (~bunnytaur@cpe-72-224-19-1.nycap.res.rr.com) 17.36.47 # Torne: I'll test in a minute 17.36.56 # gevaerts: thanks 17.37.16 # togetic: yes 17.37.34 Join Adubb [0] (~aldubuc@67.201.160.144) 17.37.56 # topik: ^ 17.38.25 # I mean, I apply, but I don't make the decision whom to pick 17.38.37 # you bring quite the resume 17.39.04 # RaaA is an exciting direction 17.39.20 # gevaerts: i'm not sure how the font cache works entirely but it *looks* like it will result in font loading being dozens/hundreds of read() calls 17.39.30 # gevaerts: wheras a font that fits without caching is *one* read() call 17.39.43 # so that's a horribly bad case in general, but *especially* on the 5.5G with the sector emulation 17.39.44 # Torne: I seem to vaguely remember some discussion about that a while ago 17.39.54 Quit merbanan (Remote host closed the connection) 17.39.56 # which makes small reads way worse than on other devices 17.40.12 # I thought the glphcache is a simple dump of the font buffer 17.40.18 Join stripwax_ [0] (~Miranda@87-194-34-169.bethere.co.uk) 17.40.30 # kugel: i mean the mechanism to load/render fonts larger than the buffer 17.40.34 # not just loading the cache specifically 17.40.37 Quit stripwax_ (Client Quit) 17.41.12 # * linuxstb wonders how many people make use of the 345 Ethiopic glyphs in 15-Adobe-Helvetica 17.41.13 # and no, the cache only saves the indexs of the glyphs, it looks like 17.41.22 # Crap, yes. That's what it does. 17.41.25 # see glyph_cache_load 17.41.28 Join merbanan [0] (~banan@c-62-220-165-110.cust.bredband2.com) 17.41.33 # it reads 2 bytes at a time from .glyphcache 17.41.40 # then goes and reads taht *one* glyph from the font 17.41.47 # hundreds/thousands of tiny reads 17.41.57 # Torne: 25 ticks to load 15-Adobe-Helvetica on gigabeat F 17.43.49 # Torne: I mean I thought the glyphcache would be read with a single() 17.43.54 # kugel: nope. 17.44.05 # kugel: and even if it was, that wouldn't help, because it reads *each glyph* from the font seperately 17.44.15 # the cache is, sadly, not a copy of the font buffer 17.44.20 # it is just a list of what characters are in there. 17.44.34 # gevaerts: hm, that's not very slow ;( 17.45.35 # gevaerts: but what is it for 14? 17.46.51 # Torne: maybe it should be a changed so that it's a simple dump 17.47.13 # kugel: maybe. it wouldbreak if someone changed the font file, then 17.47.16 # but I assume you might get out of sync with the font if it changes between boots 17.47.19 # Torne: 7 ticks 17.47.39 # gevaerts: right. and i think it will get *slower* the more you use the cache, also 17.47.48 # gevaerts: since if your cache just mentions the ascii chars it won't load anything else.. 17.47.53 # Yes, probably. 17.48.00 # but if your cache also mentions, say, a bunch of CJK glyphs it will take *longer* 17.48.05 # up to the limit of the size of the cache 17.48.19 # So just changing the font would clear it, and then it would slowly getting slower 17.48.29 # so yeah. it's 4 times slower for you 17.48.49 # but it's more like 20 times slower for me, probably because of the sector emulation 17.49.17 # small random reads are bad in our fat implementation anyway but they are *much worse* when emulating a different sector size ;) 17.51.33 # for me it's 22 ticks to load 14, ~600 ticks to load 15 17.51.40 # so yeah, over 25 times slower :) 17.52.04 # sucks to be me 17.52.13 # I've put rockbox on my FuzeV2, and I keep getting a Panic error about 1 to 2 seconds in when I play a file from the uSD card. 17.52.14 # fortunately i don't actually use cabbie normally 17.52.20 # so this doesn't affect my actual use of the player 17.52.31 # it just affects the boot time every time i try and test something with the default settings ;) 17.53.25 # i'm gonna raise a FS# for this so other people can see more easily 17.54.15 # Torne: The metadata parsers may also have that problem (lots of small reads). So the slow database times on the 5.5g may not only be because they normally hold lots of files. 17.54.28 # linuxstb: yeah 17.54.52 # i'm primarily concerned about this font thing because it's affecting the boot time with default settings, though 17.54.59 # which affects *all* users who haven't picked another theme yet :0 17.55.12 # i guess it's not so bad on the other devices if it only takes 250ms to load 17.55.18 # but even 250ms is not quick 17.55.23 # and 6 seconds is just crazy 17.57.49 # this is only on the 80GB 5.5g, right? 30GB 5.5g unaffected? 17.58.10 # likewise 5g 17.59.41 # stripwax: i assume it's only the 1024-byte-sector disks, yes 17.59.57 # but even on a disk without that problem it's still4-5 times slower 18.00.12 # 250ms is still not very nice when it could be 70ms 18.00.21 # bluebrother, pixelma: I have a patch that removes all the \* and the \\ etc and changes the latex settings to have new paragraph have a blank line rather than an ident (I *much* prefer this, I think it is much easier to read.) This also means that there is e.g. a blank line after a note without having to force it. I need to sync it and clean it up, then I'll stick it on flyspray 18.01.47 # http://www.rockbox.org/tracker/task/11168 <- bug raised 18.02.21 Part JanDo (" www.qip.im ") 18.02.25 # AlexP_: nice. 18.03.18 # Torne: there's another option. Increase the font buffer on ipod video :) 18.03.23 # gevaerts: This is true 18.03.32 # the font buffer is 60000 bytes on devices with >2mb ram 18.03.45 # we could go higher on devices with >16, or similar 18.04.45 Join funman [0] (~fun@rockbox/developer/funman) 18.05.03 # the font in question is 227KB though 18.05.10 # so we'd ahve to make it 256KB or whatever 18.05.24 # is losing 200KB of ram to make fat fonts load faster worth it? :) 18.06.12 # If this were an ideal world, all ipods with the affected disk would have 64mb ram 18.06.15 # 35 of the 73 fonts we provide currently fit in 60000 bytes 18.06.40 # if we increased it to 256kb then 61 of them would fit 18.06.53 # gevaerts: i'm still not sure if they do or not 18.07.30 # kugel: if your application is read by google, s/OF/OF (Original Firmware)/g 18.07.57 Quit stoffel (Remote host closed the connection) 18.09.22 # This will probably be even worse if you use multifont 18.09.25 # Yup 18.09.29 # or is it? 18.09.35 # does it load the extra fonts to the font buffer? 18.09.39 # or does it put them in the skin buffer? 18.09.54 # It puts them in the skin buffer, with I think 10K per font 18.10.07 # 10K? 18.10.17 # that's.. way too small :) 18.10.17 # I'm not sure 18.11.25 # anwyay, i dunno what the best thing to do is 18.11.29 # but i think we should do *something* :) 18.12.14 # gevaerts: anyway, now that i've solved that mystery i'm gonna test your patch 18.12.17 # The best thing to do is of course to make the glyph cache code less seek-happy 18.12.20 # gevaerts: and see if i can get my boot time down any lower :) 18.12.26 # gevaerts: i'm wondering if the cache is even in order 18.12.29 # if not that would be *punishingly* bad 18.12.48 # It probably isn't 18.12.54 # that would explain it ;) 18.13.52 # yeah, it saves them by doing lru_traverse 18.14.21 # so i would guess we're probably doing several hundred seeks at minimum 18.14.51 # FAT will cache different 512-byte sectors, even though the cache is useless 18.15.02 # and then the ATA code will cache different 1024-byte sectors too, even though that cache is also useless 18.15.07 # kugel: your application looks good (i noted a few typos in #rockbox-community) 18.15.08 # so, huge amounts of seeking and copying all round. 18.17.37 Quit mitk (Quit: Leaving) 18.19.24 # Luca_S: i have a 8gb fuzev2 , crashes are expected (I experienced them the most when loading several plugins in a row on Clip+), I believe it is due to SD driver but test_disk will help to confirm once writing works 18.20.29 # funman: I've been experiencing some crashes too on my fuzev2, but only when I try to play a track from the uSD card. 18.20.40 Join tomers [0] (~chatzilla@bzq-84-109-85-100.red.bezeqint.net) 18.20.56 Quit dockimble (Quit: WeeChat 0.2.6.3) 18.21.15 # yeah. internal storage seems more stable (it's slower IIRC?) 18.21.32 # In viewer.c:viewer_draw(), what exactly is the size of the arrays scratch_buffer and utf8_buffer?! 18.21.51 # funman: md5 can "verify" as well, can't it? 18.22.04 # unsigned char scratch_buffer[max_columns + 1]; - and max_columns is a global variable... Any ideas? 18.22.30 # tomers: that's C99 18.23.31 # bluebrother: does rockbox is written to c99? 18.23.35 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 18.24.19 # there are a number of places that use C99 features. I don't think we *try* to use all features of C99 though (don't see a reason to do so anyway). 18.26.19 # thank so the explanation. does all our code compile with C99 features (but we may choose not to use them), or does those specific places in the code are configured by makefiles to compile with C99 features enabled? 18.26.56 # when scrolling through art in pictureflow, on ipodvideo, what is the limiting factor (it's pretty slow) - disk reads (from the image cache) or lcd updates? 18.27.12 # or even the rendering 18.27.47 # tomers: gcc defaults to using C99, so if you don't want it you explicitly need to turn it off. I don't think its done anywhere in Rockbox' Makefiles 18.28.34 # I don't see much point in not using C99 features unless you want the code to compile with other compilers that don't support C99. 18.28.48 # bluebrother: can i use this C99 feature, 'variable-length arrays', say, in firmware/drivers/lcd-bitmap-common.c firmware/font.c ? 18.29.17 # sure, it's a language feature. It's a different question if it makes sense using it. 18.29.17 # jennifur: yes it seems microSD works less fine since we switched to dynamic CPU frequency 18.29.20 # I mean, will it be accepted if I use it? It would really help me with FS#11095 18.29.45 # kugel: md5 could work yes, we just need to patch md5 plugin to not write its result on storage but rather on screen 18.30.15 # * funman slaps dionoea for that 18.30.18 # tomers: yah, sure. we generally use whatever gcc will accept 18.30.26 # tomers: I'm not aware of any policy to not use language features in firmware code (or any other place). 18.30.32 # tomers: too much of it is highly useful to ignore ;) 18.30.49 # Torne, bluebrother: great, thanks a lot 18.30.54 # C99 has quite a bunch of nice and useful features. 18.31.06 # * tomers agrees 18.31.12 # we use gnu extensions also, so yeah, knock yourself out :) 18.31.20 # unfortunately the numbers of C compilers supporting C99 is pretty small. Even MSVC doesn't support C99. 18.31.24 Quit Luca_S (Quit: CGI:IRC) 18.31.38 # (which is the major reason why you can't build Rockbox Utility using VS) 18.31.46 # bluebrother: as long as we can use it, I don't care :-) 18.32.05 # rockbox is quite dependant on gcc anyway 18.32.17 # well, we do want a free toolchain so MinGW is the way to go anyway 18.33.03 # tomers: we're also pretty much tied to gcc because of inline assembly. There's no language standard for that, so other compilers do it different. Same goes for the assembly code itself. 18.34.21 # I had tried to use RVCT armcc and the first showstopper was dependencies generation 18.35.35 # bluebrother: thanks for explaining :-) 18.42.01 Join captainkewllllll [0] (~2669ecc2@gateway/web/freenode/x-lbxmmpcnkobmrhca) 18.43.22 Quit jennifur (Quit: jennifur) 18.44.16 Quit sevard (Ping timeout: 252 seconds) 18.45.38 # New commit by 03tomers (r25437): Manual: Document new 'alignment' option in text viewer, and remove now obsolete limitation 18.47.13 Quit anewuser () 18.49.38 # http://www.rockbox.org/tracker/task/10756 has this been committed already? (freeing init code) 18.50.01 # yes 18.50.15 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 18.50.51 # r25013 18.59.42 # Torne: Read access through the sector cache shouldn't cause noticeable slowdown. Writing single 512 byte sectors is what suffers a lot 19.01.24 *** Saving seen data "./dancer.seen" 19.01.51 Join sevard [0] (sev@216.164.6.24) 19.03.24 # In fact it should be slightly faster 19.03.48 # Hmm, well, unless it's jumping back & forth between files, in which case it will be slower (but not much) 19.04.39 # I've made an attempt at cleaning FS#11167 up. It still might need to be generalised to be usable by non-dircache 19.09.37 # tomers, bluebrother: We do use C99 features in various places. It's just that we don't want *some* of those features, by convetion 19.10.23 # Two examples are C++ style line comments ( // ), and mixed declaration and code 19.10.56 # // comments and mixed declaration and code area already present in several places? 19.11.12 Quit sevard (Read error: Operation timed out) 19.11.50 # If they are, it's a violation of our coding style 19.12.43 # funman: we also don't want bugs, but we still have some 19.12.53 # mixed declaration and code is against our coding style? I didn't know that 19.12.59 # amiconn: I always mix declaration and use of variables 19.13.08 # and // comments although less than the above 19.13.21 # amiconn: our coding style says to not use mixed declarations and code? 19.13.49 # also in my understanding coding style is left to the desire of the developer creating the file, as long as individual files respect the same style 19.14.22 # it's true that CONTRIBUTING specifically mentions /* */ over // 19.14.27 # * linuxstb remembers the same as amiconn, but it's not in docs/CONTRIBUTING.... 19.14.56 # funman: Brace placement style is left to the desire of the developer 19.15.24 # If CONTRIBUTING does not mention not to mix declarations and code, that should be added 19.15.32 Join sevard [0] (sev@216.164.6.24) 19.15.45 # no 19.16.06 # % grep -Ie "[^:]"// *|wc -l 19.16.06 # 30219 19.16.33 # IMO mixing declaration and code is a good idea: declare variables when they are used, not 80+ lines over when they are used 19.16.36 # if we don't want to mix declarations and code it should really be added. I'm doing it all the time (though in C++ code). But why should we not want to use that feature? The only reason I can think of is C89 compatibility 19.16.37 # the mix rule is new to me 19.16.49 # funman: If it's 80 lines away, your functions are too big... 19.17.14 # * bluebrother wants a monitor that can show 80 LOC 19.17.28 # true, but really I learned that gcc -pedantic (-std=c89?) produced warning for declarations made inside code 19.17.37 # + when I joined rockbox community 19.17.45 # * AlexP_ spots jhMikeS on the mailing list 19.17.50 Nick AlexP_ is now known as AlexP (~ap@rockbox/staff/AlexP) 19.17.58 # Not mixing declarations and code helps improving code quality, imo 19.18.11 # AlexP: ? 19.18.24 # kugel: What? 19.18.42 # "* AlexP_ spots jhMikeS on the mailing list" 19.18.50 # I don't know how else to explain that 19.18.53 # I'm *not* saying that all declarations have to be at the beginning of each function, just at the beginning of a block 19.19.13 # are you talking about the guy that want to apply for gsoc? 19.19.14 # Does mixing declarations and code count as a "C++ism"? (I don't know C++) 19.19.16 # (wherever it is allowed in C89) 19.19.32 # declaring loop counters just before the for() is better for me 19.20.32 # kugel: No, jhMikeS - Mike Sevakis, the Rockbox developer 19.20.35 # * bluebrother wouldn't consider mixing declarations and code as C++ism, though imagines that some people would 19.20.53 # linuxstb: at least it's ok with -pedantic -std=c99 19.20.58 # * bluebrother points to IrcNicks 19.21.21 # funman: it's a C99 feature, so it should be ok with that options ;-) 19.22.29 # i don't know to which point gcc is laxist, but mixing code and declarations only produce a *warning* with *-pedantic* for C89 19.23.17 # funman: you sure? 19.23.59 # 101% 19.24.38 # gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) 19.24.51 # funman: not for me 19.25.17 # 4.4.3 on F12: test.c:9: warning: ISO C90 forbids mixed declarations and code 19.25.33 # that's with gcc -o test -std=c89 -pedantic test.c 19.26.05 # without -pedantic it compiles 19.26.28 # http://pastie.org/900568 19.27.04 # (cc points to gcc) 19.27.26 # * linuxstb recalls Bagder and LinusN being strongly against mixing code and declararations, and commits being criticised for that. But things must have become slacker... 19.27.56 # well, that's the same I'm seeing here (and which is correct): -pedantic -std=c89 errors out. 19.28.12 # though I'm not sure if I consider it good behaviour to not error out without -pedantic 19.28.17 # only a warning 19.29.07 # ah, overlooked that. True. IMO it should error out in c89 mode 19.29.24 # * bluebrother assumes that you can make it do so with the correct command line option 19.30.00 # -Werror 19.31.59 # rockbox doesn't build with -std=gnu99 -pedantic 19.35.31 # New commit by 03funman (r25438): Only build alarm_menu.c if needed 19.37.06 # funman: it seems I can't charge my clip+ while running rockbox, too. I had it connected to a Motorola mobile phone charger for more than 5h today and now it is at 77% ... I think it was about the same level when I started 19.37.31 # ThomasAH: it charged from 0% up to 63% for me, then I had to use the OF 19.37.41 # funman: but the charging icon was displayed, even when starting that high 19.37.48 # yeah 19.38.31 # funman: getting below 63% isn't that easy if I connect it regularly with OF to copy new rockbox builds, voice file, talk clips, ... :) 19.38.50 # * funman bets ThomasAH doesn't listen to his Clip+ 15 hours in a row 19.39.13 # funman: right ... only about 1-2h each day 19.40.01 # funman: though it might be more these days, I bought a short connector to connect it to the kitchen radio :) 19.40.06 Quit kugel (Remote host closed the connection) 19.40.17 # amiconn, linuxstb: if you think mixing declarations and code in rockbox (gnu)C(99) code should be forbidden, please bring it on the mailing list 19.42.49 # (oh, and I copied two jpegs of smurfs to it yesterday (harmony and a generic smurf) :) 19.43.31 # no smurfette? you crazy Oo 19.44.22 # funman: thought about it, but she wasn't in the mood to be copied to a smurf smurf :) 19.44.50 # ok, of for dinner ... 19.47.35 Quit linuxstb (Ping timeout: 276 seconds) 19.50.50 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 19.52.38 Quit antil33t (Read error: Connection reset by peer) 19.52.44 Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) 19.53.03 Quit funman (Quit: free(random());) 19.58.37 Quit linuxstb (Ping timeout: 240 seconds) 19.59.23 # The 170ms it takes to load the built-in sbs with cabbiev2 on my gigabeat f seems to be entirely spent on loading the backdrop. I guess that means the sbs change itself does indeed have no effect on boot time 20.03.11 Quit sevard (Ping timeout: 276 seconds) 20.03.16 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 20.07.02 Quit linuxstb (Read error: Operation timed out) 20.09.38 Join sevard [0] (sev@216.164.6.24) 20.12.12 Quit tomers (Ping timeout: 265 seconds) 20.12.30 Quit TillW (Quit: This now concludes our broatcast day.) 20.22.02 Quit xiainx (Ping timeout: 276 seconds) 20.22.52 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 20.25.30 # linuxstb: no i didn't realize they were identical 20.27.01 # Obviously most VOBs contain AC-3 audio, and that's stored differently to mpeg audio. 20.28.39 # VOBs are just a restricted form (e.g. certain maximum buffer sizes, fixed-size (2048 byte) packets) of mpeg-2 program streams. They also have extra things (e.g. subtitle streams, navigation info) as private streams within the program stream. Plus even more extra stuff on DVDs as IFO files. 20.33.45 Quit saratoga (Quit: Page closed) 20.36.24 # bluebrother: Another key point (to me) is that if characters aren't showing, a user is likely to ask "how do I fix this" or check the manual. If boot is slow, they're more likely to just think "oh, that's how things are, I guess." 20.37.09 # Llorean: right. 20.37.45 # in any way, making boot slower is definitely the worst option. 20.37.49 # Agreed 20.38.22 # given that my mini needs around 6 seconds already. I did even flash my h100 to make booting faster (which is really great) 20.38.31 # Between gevaerts's dircache fix and getting the right combination of font size and buffer, the iPod 5G should have a pretty snappy boot again. 20.38.40 # bluebrother: Is your mini using dircache? 20.38.52 Quit flydutch (Quit: /* empty */) 20.39.09 # yes. Wanted to try gevaerts dircache fix today, didn't get around till now. 20.39.26 # though I wonder how much of a difference it will make -- my mini is cf modded. 20.44.51 Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) 20.45.32 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 20.46.14 Join killan_ [0] (~nnscript@c-38fd70d5.06-397-67626721.cust.bredbandsbolaget.se) 20.46.28 Quit killan (Read error: Connection reset by peer) 20.50.05 # the dircache patch sounds great - presumably would prevent disk thrashing too, and hence speed up buffering also? 20.50.10 # Llorean: ok, on my mini the difference is not noticable, at least not when timing it with an ordinary stopwatch. I guess it's related to the CF mod. 20.50.25 # stripwax: yes, that's the point 20.50.33 # but what is "the known bug that Slasheri told me would fix" ? 20.51.01 # It might be known, but not by me :) 20.51.04 # gevaerts - wasn't sure if the point was to prevent disk thrashing, or just speed up the boot to main menu. everyone's a winner though. 20.51.55 # gevaerts, stripwax : I don't have time right now but I'll explain it to you later ;) 20.52.32 # Can't you summarize? 20.52.34 # stripwax: basically the boot is slow because of thrashing. It's possible to fix that by putting the dircache init later in the sequence, but then the thrashing potentially interferes with buffering. The patch basically inserts a sleep in the dircache thread at the place it yields anyway in case another thread has accessed the disk recently 20.53.58 Join jennifur [0] (~bunnytaur@cpe-72-224-19-1.nycap.res.rr.com) 20.54.39 # It might be useful to do this for database updates as well, but then we have to think hard about making sure that dircache and tagcache don't wait for each other 20.56.20 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 20.57.14 # can we record the thread id of the thread that most recently accessed the disk - and then tagcache waits unless the thread id is dircache? (or vice versa) 20.59.03 # that's one way to do it 21.00.06 # The way I thought of yesterday was to just make the time intervals for "recent" different enough, which would give one of the two priority as well 21.01.28 *** Saving seen data "./dancer.seen" 21.04.07 Quit sevard (Ping timeout: 240 seconds) 21.05.31 # Hrm. Seems RockBox boots *much* faster than the OF here :) 21.11.17 # gevaerts, stripwax, Llorean : bug description follows 21.11.21 Join sevard [0] (sev@216.164.6.24) 21.12.37 # The known bug is quite technical bug one consequence is for example that if you open a file while dircache is on, then dircache got deactivated and then is renable, the file is not more considered opened by dircache, so there is an inconsistency 21.13.41 # And any operation that modifies the metadata of a file during that dircache rebuild might lead to inconsistent dircache state (where the dircache data is not the real one) 21.14.33 # The deactivate/activate thing won't be impacted by boot changes I think 21.14.53 # The other one, hm. What about the playlist control file? 21.15.14 # playlist control is the mainly affected file 21.15.55 # gevaerts: the bug will be more visible because the rebuild will take longer so during that time, more files can be opened/modified 21.16.14 # It will take a bit longer. Not really much though 21.16.16 # when dircache is enabled, don't you need to reboot for it to take effect? i'm not sure I understand how dircache can be enabled while a file is already opened. 21.16.48 # when dircache rebuilds, it's disabled, it passes though to dir_uncached 21.17.07 # (basically) 21.17.09 # and dircache can't see/query file open status? 21.17.31 # it's not that simple 21.20.06 # This bug is not super hard to fix but (a) Slasheri said he'll do it but I think it hasn't got time (b) it's a bit tricky, need to go into details, think hard ;) 21.21.41 # And furthermore, whathever the implementation you choose, you can end up in a situation where you have no choice but to redo the rebuild because you can't keep track of all the changes that happened during that time in a constant space 21.22.09 # maybe, but that's better than an inconsistent state 21.22.23 # Would it be possible to make the filesystem read-only during the background dircache scan? 21.22.36 # New commit by 03bluebrother (r25439): Implement system proxy values retrieval on OS X. 21.22.41 # I mean, there's a lot less likelihood someone will want to write to their filesystem in the first three seconds after boot. 21.23.02 # Llorean: the problem isn't really the "someone" I think, it's the "something", i.e. playback 21.23.10 # For me it's 12 seconds 21.23.15 # Llorean: that also happens during tagcache rebuild 21.23.17 # gevaerts: Well, deny it writing until dircache is complete? 21.23.40 # read-only is clearly not a solution to me 21.23.57 # pamaury: Why? 21.24.16 # too much impact elsewhere 21.24.28 # Rockbox can do almost everything on our read only targets as it is. 21.24.37 # During the tagcache build, what's it preventing that will be a problem? 21.24.46 # You suddenly have to make *everything* that writes to disk able to handle intermittent write failures 21.25.14 # You don't know, these are background things. Anything could be running 21.25.26 Join stripwax_ [0] (~Miranda@87-194-34-169.bethere.co.uk) 21.25.28 # and that's a mess, for example if it happend during playback, playlist control file will be read-only, I think it will trigger an error message 21.26.07 # You could handle one or two instances, but all of them including plugins? What about e.g. recording? 21.27.11 # * gevaerts is assuming that dircache can have the same issues durin partial rebuilds 21.27.25 # My point is that here is a solution to this problem, it's just that there has to be some code for this problem and that it's not very fun to write it, but I should write it 21.32.26 # * pamaury also notes that to make this run with only a small memory overhead, it requires a bit of trickery, otherwise, it will eat several KiB of memory 21.33.40 # pamaury: you recently made it eat around 30K less, you have some margin :) 21.35.35 # gevaerts: true but that would be stupid. I mean, if you keep track of every modified file during the rebuild, you have to save the name => 250 bytes/file. It can be done if much less (I think it can be done in 4 bytes/file :)) but there are some corner cases that have be stupied. The bigger problem is deletion I believe 21.38.16 # Can some features just be disabled during dircache background scan? If someone tries to delete, splash "Dircache is committing. Please wait for disk use to end and try again." 21.38.58 # I don't see that the dircache scan needs to be 100% invisible to the user, just have a "minimal" impact. 21.39.43 Quit stripwax (Read error: Connection reset by peer) 21.39.55 # Well, for me a cache has to be transparent, but that's my opinion. 21.40.12 # Llorean: again, it might not be this easy. File operations are not only triggered directly by users through the GUI 21.40.28 # You'd have to track down all cases and fix them 21.40.39 Join carl_sagan [0] (~steve@adsl-68-88-123-124.dsl.lgvwtx.swbell.net) 21.40.51 # it's easier to modify *just* dircache than all the rest :) 21.41.50 # ok question. i installed rockbox on an ipod and it installed fine, but when i shut down the ipod and restarted it, it said the bootloader could not be found and to boot with disk mode 21.42.12 # so i did that, and tried to reformat the ipod. however, under disk mode it says the ipod is write only 21.42.46 # but i discovered that it would boot with the old ipod firmware if the hold switch was on when it started 21.42.55 # so i reformatted with no problem from the old firmware 21.43.02 # And by the way, dircache code is already using magic tricks, so one more will not make the code horrible ^^ 21.43.27 # so obviously the old firmware is intact, but every time i start the ipod it still says rockbox bootloader could not be found and says to boot with disk mode 21.43.47 # carl_sagan: Rockbox doesn't tell you that the bootloader is missing. That's the Rockbox bootloader telling you the main build is missing. 21.43.58 # ok... 21.44.04 # which means you installed only parts of it. How did you install? 21.44.05 # but if i reformatted it how is the bootloader still there? 21.44.14 # It's in the same place as the original firmware. 21.44.16 # I.e. did you use "complete install" or the "Installation" tab? 21.44.36 # i used the complete install 21.44.45 # it was fully functional with rockbox before i turned it off 21.45.03 # the Ipod uses a firmware partition. Rockbox modifies that to boot the Rockbox bootloader first. Then it can boot either Rockbox (which is placed on the main data partition) or the Apple firmware, which is also located in that firmware partition 21.45.17 # How did you reformat? 21.45.35 # also, what host are you using? Mac? 21.45.36 Quit bmbl (Quit: Bye!) 21.45.46 # i turned the ipod on with the hold switch on so that the apple firmware would load 21.45.48 # And which exact ipod is it? 21.45.51 # then i opened the ipod with itunes 21.45.55 # nano version 2 21.46.08 # reset it with itunes, and then used windows reformat to reformat it 21.46.29 # * bluebrother has this strange "declaration doesn't declare anything" error again :( 21.47.08 # you don't want to format an Ipod using the window format 21.47.38 # i reformatted it several times. i also used some that were referenced for use with ipods 21.47.46 # like i think its the HP one? or something 21.48.14 # but every time, it reformats fine, but when i restart it in disk mode, the computer detects it as unformated 21.48.25 # It sounds like you have a bad disk. 21.48.25 # and if i try to format it with disk mode on, it says it is write only 21.48.36 # or various forms of "the format failed" 21.48.36 # Which would also explain why rockbox.ipod vanished / became corrupted. 21.48.53 # thats...possible i suppose 21.49.05 # but why was the ipod functional with apple firmware before i installed rockbox? 21.49.17 # well, if you want to reformat you should use the restore functionality of itunes, not windows format. Windows is keen on formatting everything as NTFS, which doesn't work on the ipod 21.49.33 # did you reformat it before installing Rockbox? 21.49.44 # with itunes, yes 21.50.11 # restoring it using itunes doesn't remove the rockbox bootloader? That sounds strange 21.50.29 # it does. 21.50.38 # at least it did for me (on a Mac though) 21.51.09 # carl_sagan: if you tell itunes to restore it, and do *nothing* else, what happens? 21.51.37 # it does just like it would with a normal ipod "the reformat is complete, restarting ipod in 5 etc." 21.51.58 # and the the ipod restarts and comes up with the bootloader could not load rockbox.ipod 21.52.40 # Does itunes make a difference between "reformat" and "restore"? 21.53.00 # it says "restore" but that is the only option listed 21.53.36 # * gevaerts has neither an ipod nano nor itunes, so he can only work from hearsay, but that definitely does not sound normal 21.54.14 # itunes only knows about restore 21.54.40 # ? 21.55.03 # sounds like the flash is bad. How old is the ipod? 21.55.37 # it is definately old 21.55.42 # Isn't there a way to reset the FTL, or does the restore do that? 21.55.57 # ftl? 21.56.47 # carl_sagan: I think your best bet is to come back later. Our main nano2g specialist (TheSeven) isn't here right now 21.57.00 # alright i'll check back 21.57.04 # thanks for the help guys 21.57.35 Quit carl_sagan (Quit: Leaving) 21.59.30 # * bluebrother feels like the compiler error is a naming clash with OS X APIs again :( 22.02.07 Quit sevard (Ping timeout: 240 seconds) 22.04.37 Join Blue_Dude [0] (~chatzilla@adsl-235-206-131.mco.bellsouth.net) 22.05.10 # Updating the manual to reflect new keymaps. I probably missed some things. 22.06.56 # restore (iTunes restore) *should* reset the FTL, unless something is going drastically wrong somewhere... 22.07.18 Join jeffp [0] (~jeffp@barmen.interhost.no) 22.10.02 Part jeffp 22.10.17 # though, definitely *definitely* come back & talk to TheSeven... 22.11.13 # New commit by 03Blue_Dude (r25440): Manual update for keymaps, hotkeys 22.12.26 Quit stripwax_ (Quit: http://miranda-im.org) 22.16.14 Quit Zagor (Quit: Leaving) 22.17.25 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 22.21.35 Quit pamaury (Quit: Page closed) 22.22.36 Quit robin0800 (Remote host closed the connection) 22.23.13 Quit pixelma (Disconnected by services) 22.23.13 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 22.23.16 Quit amiconn (Disconnected by services) 22.23.18 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 22.23.33 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 22.23.40 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 22.25.08 Join sevard [0] (sev@216.164.6.24) 22.29.50 Join tvelocity [0] (~tony@weg38-1-82-237-37-150.fbx.proxad.net) 22.34.13 # S_a_i_n_t: itunes does not reset the ftl, but we have tools to do that 22.38.03 Quit dfkt (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.) 22.38.39 Join geertvdijk [0] (~chatzilla@cc412026-a.zwoll1.ov.home.nl) 22.39.11 # AlexP: does that mean I would break your patch if I committed the removal in goban.tex already? Besides... I have to find out first why my patch is breaking the (or at least some manuals)... 22.39.48 # pixelma: No, go ahead - the patch is well out of date and needs significant fiddling anyway :) 22.40.12 Join dfkt [0] (dfkt@unaffiliated/dfkt) 22.41.04 Quit geertvdijk (Read error: Connection reset by peer) 22.43.08 Join tomers [0] (~chatzilla@bzq-84-109-85-100.red.bezeqint.net) 22.44.45 Quit liar (Ping timeout: 258 seconds) 22.45.21 # AlexP: alright, I hope I'll find the error soonish, tex is not being helpful :\ 22.46.00 Join geertvdijk [0] (~chatzilla@cc412026-a.zwoll1.ov.home.nl) 23.00.39 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 23.01.29 *** Saving seen data "./dancer.seen" 23.04.09 Join S_a_i_n_t_ [0] (S_a_i_n_t@203.184.2.219) 23.04.45 Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) 23.05.02 Quit S_a_i_n_t (Ping timeout: 260 seconds) 23.10.56 Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.2/20100316074819]) 23.15.30 Join Smith [0] (~4b519c19@gateway/web/flash/gateway.tiramisu.in/x-ydzwsqwqvsovgabn) 23.16.35 Part Smith 23.21.16 Quit jgarvey (Quit: Leaving) 23.22.54 Quit captainkewllllll (Quit: Page closed) 23.24.22 # New commit by 03bluebrother (r25441): Move utils.cpp functions into separate class and split it up. ... 23.24.38 # * pixelma reads months old dev list emails and notices that the 23rd of March went by silently 23.26.06 # did the release cycle "reset" after the last release which was postponed, so that the 3 months time to the next release count from the actual release date? 23.26.53 # I think it would be a bad idea to do a two-month cycle suddenly. 23.27.14 Quit xiainx (Ping timeout: 264 seconds) 23.27.37 # I personally also think that a four month cycle is slightly better 23.27.45 # not a "cycle", just getting back on track. But I always thought releasing every 3 months was a but much 23.28.17 # bit too 23.28.18 # IMO we shouldn't get into a release cycle with a release around christmas 23.28.26 # that too 23.29.02 # I'm not sure the time between releases matters too much. 23.29.09 # One way or another it always seems to take people by surprise. 23.29.27 # And of course there's the usual "I want to squeeze this in before the freeze" mentality that, I think, doesn't benefit our users much. 23.29.47 # * Llorean thinks a "oh, the freeze is coming, I may as well just let my big change happen after the release so there's more time to test" benefits users more. 23.30.15 # The freeze should mostly be about clearing up known bugs, not trying to track them down in last-minute added big new code. 23.30.51 # I haven't seen this now... no-one seemed to even remember that 23rd of March would have been the usual date 23.31.26 # I'm still convinced that the last release was a couple of weeks ago :) 23.31.31 # It seems like it 23.31.34 # I think we may want to reconsider what the release is. Not just the cycle, but come up with a solid reason why we're doing it and *how* we're going to do it, because I think different people see it as far too different of a thing. 23.32.36 # For some it's a time "to get things done by" when it's remembered. Others (or at least, me) thing things should generally start slowing down before the release even if there's not an explicit freeze, to try to make sure stability is ramping up or at least not getting worse as the freeze approaches. 23.32.51 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 23.32.53 # New commit by 03bluebrother (r25442): System Info: display OS X version number and architecture too. 23.33.12 # * gevaerts wants a four month cycle, but he also thinks that we should release soon because there seem to be no large changes right now... 23.34.13 # Llorean: I agree with the "don't commit right before release (or freeze)" and I am aware that there was this big discussion last time which I just skimmed again, but didn't get the feeling that this was a "usual" attitude 23.34.15 # * Llorean wouldn't mind a four month cycle, and is more just concerned about general release awareness and care to try to avoid delays. 23.34.27 # pixelma: It's not a "usual" attitude over everyone. 23.34.34 # It's a specific attitude among some people though. 23.34.36 # Last release was 2nd Feb, so 4 months would be two days before devcon. 23.35.44 # that could be good or bad 23.35.52 # Yes, I'm not sure which... 23.36.15 # Devcon as "let's write new code, it doesn't have to work", or "Let's fix bugs!" 23.36.22 # it might make sense to pick a dedicated release manager for each release. 23.36.37 Quit tomers (Ping timeout: 265 seconds) 23.37.41 # gevaerts: If we've branched, we can do both... 23.37.56 # i.e. release on the final day of devcon. 23.38.12 # Llorean: I'm just against generalisation and would want to try avoiding bad blood beforehand 23.39.53 # pixelma: I'm just suggesting that we decide whether we want to say "please try to avoid significant changes to functionality for (some time period) before the freeze to help ensure the manual is up to date and stability is at its best" or just say "the freeze is the only period where commits matter, even one day before it is fair game" 23.40.08 # If you have a policy in place in advance, it helps avoid arguing about it later. 23.41.40 # Well, basically, "to help ensure the manual is up to date and stability is at its best" is what the freeze itself is for, but yes, *too* intrusive changes should stop a bit sooner 23.41.42 # ok, thanks for the clarification. That's probably worth talking about... 23.42.03 # gevaerts: Well that's why I said "significant" rather than "any" 23.42.10 # I guess definition for "significant" would also be important 23.42.13 Quit xavieran (Ping timeout: 276 seconds) 23.42.26 # One basic problem we have is that there just aren't enough testers for some of the features 23.43.04 # I think it's fine to make the user base also our tester base. It's just ideal to do so right *after* the branch so that there's a recent stable version for them to use too. 23.43.22 # The longer something that needs heavy testing has before it's in a release, the better. 23.50.18 Quit ender` (Quit: There is no reason anyone would want a computer in their home. -- Ken Olson, president, chairman and founder of DEC) 23.51.37 Quit Status (*.net *.split) 23.51.37 Quit preglow_ (*.net *.split) 23.51.37 Quit blithe_ (*.net *.split) 23.51.37 Quit Farthen (*.net *.split) 23.51.37 Quit stavrob_ (*.net *.split) 23.51.48 Join Status [0] (Status@gentoo.lonis.org) 23.52.52 Join preglow_ [0] (thomj@tvilling2.pvv.ntnu.no) 23.52.52 Join blithe_ [0] (~blithe@72.14.176.144) 23.52.52 Join Farthen [0] (~Farthen@static.225.178.40.188.clients.your-server.de) 23.52.52 Join stavrob_ [0] (~sam@78-105-125-218.zone3.bethere.co.uk) 23.54.37 Join xavieran [0] (~xavieran@ppp118-209-62-101.lns20.mel4.internode.on.net) 23.55.23 Part jennifur 23.55.25 Join temp1234 [0] (~8c718113@gateway/web/freenode/x-wksmgufhfnftbpry) 23.57.50 Quit merbanan (Read error: Operation timed out) 23.58.17 # Llorean: the big problem is that I don't really like rockbox not working with some systems if there is a known way to make it work...