--- Log for 09.06.111 Server: card.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 7 days and 22 hours ago 00.00.36 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 00.00.36 Quit bertrik (Changing host) 00.00.36 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 00.01.42 Quit ender` (Quit: The moment a person forms a theory, his imagination sees in every object only the traits which favor that theory. -- Thomas Jefferson) 00.06.54 Quit evilnick_B (Quit: Page closed) 00.11.32 Quit bertrik (Ping timeout: 276 seconds) 00.25.50 Quit GeekShadow (Ping timeout: 258 seconds) 00.36.57 Quit n1s (Remote host closed the connection) 00.38.04 Join Scromple [0] (~Simon@115-64-195-104.tpgi.com.au) 00.39.50 Join T44 [0] (~Topy44@g228196196.adsl.alicedsl.de) 00.43.03 Quit Topy44 (Ping timeout: 255 seconds) 00.44.29 Quit domonoky (Read error: Connection reset by peer) 00.45.24 Quit TheLemonMan (Quit: Ex-Chat) 01.24.14 Part toffe82 01.31.43 Quit sideral (Quit: Leaving.) 01.32.32 Join sudoman [0] (20238@ninthfloor.org) 01.47.34 Quit sudoman (Quit: leaving) 01.58.08 *** Saving seen data "./dancer.seen" 02.04.55 Join ChickeNES [0] (~ChickeNES@128.135.100.102) 02.22.30 Quit avacore (Ping timeout: 255 seconds) 02.27.21 Join robin0800 [0] (~robin0800@149.254.186.248) 02.28.45 Join avacore [0] (~avacore@1008ds1-rdo.0.fullrate.dk) 02.32.20 Join Keripo [0] (~Keripo@c-76-28-198-27.hsd1.wa.comcast.net) 02.35.46 Quit Judas_PhD (Ping timeout: 252 seconds) 02.42.18 Quit avacore (Ping timeout: 255 seconds) 02.43.17 Quit user890104 () 02.44.46 Join avacore [0] (~avacore@1008ds1-rdo.0.fullrate.dk) 02.47.51 Part timccc 02.51.39 Quit MethoS- (Remote host closed the connection) 02.56.15 Join MethoS- [0] (~clemens@134.102.106.250) 02.56.51 Join MethoS-- [0] (~clemens@134.102.106.250) 02.57.12 Quit MethoS- (Remote host closed the connection) 03.05.44 Quit efyx (Remote host closed the connection) 03.10.20 Join linuxguy3 [0] (~timj@216-80-116-174.c3-0.lem-ubr1.chi-lem.il.cable.rcn.com) 03.47.17 Join kramer3d [0] (~kramer@ip98-169-194-252.dc.dc.cox.net) 03.47.17 Quit kramer3d (Changing host) 03.47.17 Join kramer3d [0] (~kramer@unaffiliated/kramer3d) 03.54.27 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 03.55.16 Quit ChickeNES (Quit: Computer has gone to sleep.) 03.56.08 Join ChickeNES [0] (~ChickeNES@128.135.100.102) 03.58.12 *** Saving seen data "./dancer.seen" 04.00.06 Join evilnick [0] (~evilnick@rockbox/staff/evilnick) 04.09.48 Quit MethoS-- (Remote host closed the connection) 04.17.44 Quit ChickeNES (Quit: Computer has gone to sleep.) 04.22.22 Quit simonlnu (Remote host closed the connection) 04.25.48 Quit TheSeven (Disconnected by services) 04.25.57 Join [7] [0] (~TheSeven@rockbox/developer/TheSeven) 04.36.03 Join ChickeNES [0] (~ChickeNES@128.135.100.102) 04.38.37 Quit Judas_PhD (Quit: This is a quitting message) 04.43.59 Quit amiconn (Disconnected by services) 04.44.00 Quit pixelma (Disconnected by services) 04.44.02 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.44.02 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.44.04 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.44.06 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.47.42 Join kugel [0] (~kugel@rockbox/developer/kugel) 04.50.41 Quit kugelp (Ping timeout: 240 seconds) 05.05.38 Join Rob2223 [0] (~Miranda@p5DE4BE33.dip.t-dialin.net) 05.07.42 Quit factor (Read error: Connection reset by peer) 05.08.59 Quit Rob2222 (Ping timeout: 240 seconds) 05.09.30 Quit avacore (Ping timeout: 255 seconds) 05.10.05 Quit robin0800 (Read error: Connection timed out) 05.10.58 Join factor [0] (~factor@74.197.205.204) 05.11.46 Join avacore [0] (~avacore@1008ds1-rdo.0.fullrate.dk) 05.12.10 Join robin0800 [0] (~robin0800@149.254.234.248) 05.13.45 Quit krazykit (Ping timeout: 260 seconds) 05.14.57 Quit ChickeNES (Quit: Computer has gone to sleep.) 05.30.28 Quit Horscht (Quit: Verlassend) 05.58.12 Quit Bagder (Ping timeout: 252 seconds) 05.58.14 *** Saving seen data "./dancer.seen" 05.58.40 Join Bagder [0] (~daniel@rockbox/developer/bagder) 06.01.39 Join Transformer [0] (~Transform@ool-4a59e397.dyn.optonline.net) 06.03.24 Quit Transformer (Excess Flood) 06.07.05 Quit mystica555 (Ping timeout: 255 seconds) 06.07.33 Join mystica555 [0] (~Mike@71-33-177-238.hlrn.qwest.net) 06.15.31 Quit robin0800 (Quit: Leaving) 06.16.08 Join robin0800 [0] (~robin0800@149.254.186.248) 06.17.17 Quit robin0800 (Client Quit) 06.17.46 Join robin0800 [0] (~robin0800@149.254.186.248) 06.20.03 Quit robin0800 (Client Quit) 06.23.39 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 06.25.25 Join ChickeNES [0] (~ChickeNES@128.135.100.102) 06.41.00 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 06.41.22 Quit Judas_PhD (Ping timeout: 276 seconds) 06.47.06 Join _jhMikeS_ [0] (~jethead71@rockbox/developer/jhMikeS) 06.47.07 Quit jhMikeS (Disconnected by services) 06.47.07 Nick _jhMikeS_ is now known as jhMikeS (~jethead71@rockbox/developer/jhMikeS) 06.53.25 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 06.57.58 Quit ReimuHakurei (Read error: Connection reset by peer) 07.23.30 Quit xeniter (Ping timeout: 260 seconds) 07.25.05 Quit sinthetek (Read error: Connection reset by peer) 07.27.00 # any news about reaching freqmod? I'm just wondering if it would make sense to ping him in a channel rather than PM - maybe trying to ask him to come here and try to talk to some guys (whom?) 07.27.42 Join Buschel [0] (~chatzilla@p54A3A409.dip.t-dialin.net) 07.30.49 Join sinthetek [0] (~sinthetek@unaffiliated/sinthetek) 07.32.15 Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) 07.33.40 Quit Judas_PhD (Quit: This is a quitting message) 07.37.52 Quit sinthetek (Ping timeout: 268 seconds) 07.43.10 Join sinthetek [0] (~sinthetek@unaffiliated/sinthetek) 07.58.16 *** Saving seen data "./dancer.seen" 08.13.55 Quit Buschel (Quit: ChatZilla 0.9.86.1 [Firefox 3.6.17/20110420140830]) 08.21.23 Quit factor (Read error: Connection reset by peer) 08.22.11 Join sideral [0] (~sideral@rockbox/developer/sideral) 08.23.24 Join factor [0] (~factor@74.197.205.204) 08.23.31 Quit sideral (Remote host closed the connection) 08.24.22 Join sideral [0] (~sideral@213.165.85.248) 08.24.32 Quit sideral (Changing host) 08.24.32 Join sideral [0] (~sideral@rockbox/developer/sideral) 08.24.50 # pixelma: No news. I've repeatedly tried to ping him on IRC (his nick is FreqMod) and via XMPP, without success. I intended to send him an email next. 08.31.13 Join n1s [0] (~quassel@rockbox/developer/n1s) 08.33.46 Quit sideral (Remote host closed the connection) 08.33.58 Join chrisb [0] (~chrisb@pool-71-175-249-115.phlapa.east.verizon.net) 08.34.02 Join sideral [0] (~sideral@213.165.85.248) 08.34.02 Quit sideral (Changing host) 08.34.02 Join sideral [0] (~sideral@rockbox/developer/sideral) 08.34.39 # can the sansa e250 and sansa fuze use the same usb cable? 08.35.56 # <[Saint]> as far as I know, yes. 08.36.21 # <[Saint]> If my understanding is correct all the Sansa dock cables are backward compatible. 08.36.29 # [Saint]: that is so good 08.36.57 # <[Saint]> Just resist the temptation to try an iPod cable ;) 08.37.04 # [Saint]: the e2xx seems to have moved out of production, clip and fuze are still going 08.37.32 # <[Saint]> It *will* fit, as it's just a standard Ridax connector, but the pinout id vastly different and it'll kill your DAP. 08.37.54 # [Saint]: thanks for the warning 08.38.11 # <[Saint]> I found that out the hard way ;) 08.39.11 # speaking of suffering, setting playlists on an iPod classic, which can't be converted to rockbox 08.39.23 Join B4gder [0] (~daniel@www.haxx.se) 08.39.34 Quit B4gder (Changing host) 08.39.35 Join B4gder [0] (~daniel@rockbox/developer/bagder) 08.39.36 Join ReimuHakurei [0] (~reimu@74.112.212.15) 08.39.44 # <[Saint]> WHich "Classic" do you speak of? 08.40.10 # <[Saint]> All iPod versions (except the later Nanos) are able to be Rockbox'ed 08.41.33 # <[Saint]> iPod 1st~4th Gen, 5th~5.5th Gen, and the 6th~6.5th~7th Gen Classics. 08.42.12 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 08.42.26 # [Saint]: i forget now how to identify it, but I did about a year ago when i first got it 08.42.36 # and realized i had screwed up 08.42.50 # silver, 160G drive, ipod classic 08.42.50 # <[Saint]> A lot has changed since then ;) 08.43.05 # <[Saint]> The Classic has been supported for approximatelt 6 months now. 08.43.17 # <[Saint]> (maybe longer?) 08.43.36 # [Saint]: that's great news!!!! 08.44.01 Quit sideral (Remote host closed the connection) 08.44.19 Join sideral [0] (~sideral@rockbox/developer/sideral) 08.44.52 # <[Saint]> chrisb: Presently there is no Rockbox bootloader, so you need to use an application called emCORE to boot the ROckbox image. 08.45.04 # <[Saint]> you can check out the installation details here: http://www.freemyipod.org/wiki/EmCORE_Installation 08.46.34 # <[Saint]> there are some drawbacks, presently there is no dualboot (you won't be able to use the Apple FW, it's completely removed in the install process), battery life is considerably worse than the OF, and installation means completely formatting the device (so you need to back up any media you want to keep beforehand). 08.46.46 # New commit by 03nls (r29987): libtremor: comment out unused struct member. 08.48.07 # <[Saint]> after you have emCORE installed you can get the daily builds from here: http://download.rockbox.org/daily/ipodclassic/ 08.48.29 # sideral: it's freqmod (sometimes with _ and stuff) in #quassel. I'm sure it's him as he contributed to the client and started the android port with the same name. I try to get some others to ping him as I can't easily do this from my phone 08.49.06 # [Saint]: only the 6g are classic! 08.49.31 # <[Saint]> n1s: All classics are supported I thought? 08.49.48 # <[Saint]> Oh...whoops, I totally missinterpreted that. 08.49.50 # except the first 160GB one i think 08.49.56 # r29987 build result: All green 08.50.04 Join xeniter [0] (~xeniter@194.48.133.8) 08.50.18 # <[Saint]> the one with the weird HDD? Yeah, that's working now iirc. 08.50.35 # oh, then all of them should work 08.54.26 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 08.54.31 Quit bertrik (Changing host) 08.54.31 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 08.54.32 Join ender` [0] (krneki@foo.eternallybored.org) 08.55.13 # wow, that's tremendous progress my serial number ends in X9ZS 08.56.18 # <[Saint]> chrisb: http://support.apple.com/kb/HT1353 <-- Identifying iPod models 08.56.35 # i was looking there 08.59.20 Quit Scromple (Read error: Connection reset by peer) 09.00.05 # it's fun to see the build round times coming down gradually since the client change. ccache in action. 09.01.03 # Zagor: will the delta table come back? 09.01.20 # * chrisb thinks he has the "late 2009" 160GB drive iPod classic 09.01.20 # oh right, I forgot about that. yes, I will fix that. 09.01.31 # cool 09.02.07 # [Saint]: thanks for the link to the emCore info 09.02.12 # * chrisb goes to check 09.04.52 Quit Guinness` (Read error: Connection reset by peer) 09.04.58 Join Guinness [0] (Slayer@c-68-55-111-159.hsd1.va.comcast.net) 09.10.49 Quit xeniter (Ping timeout: 260 seconds) 09.14.58 Join keyb_gr [0] (~chatzilla@p4FF038C8.dip.t-dialin.net) 09.15.23 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 09.19.28 Quit iq (Ping timeout: 258 seconds) 09.19.59 Join iq [0] (~iq@unaffiliated/iq) 09.21.16 Join petur [0] (~petur@rockbox/developer/petur) 09.23.55 Join antil33t [0] (~antil33t@124-197-33-15.callplus.net.nz) 09.29.01 Quit sasquatch (Quit: WeeChat 0.3.2) 09.29.26 Join sasquatch [0] (~username@p4FF2CC84.dip.t-dialin.net) 09.33.43 Join GodEater_wg [0] (~93722cc9@giant.haxx.se) 09.34.06 # * chrisb notices all the creeping cryption in the iPods generation after generation 09.34.38 # you only just noticed? Do you live in a cave? :) 09.35.03 # is that the future of all consumer computing devices/ 09.35.37 # GodEater_wg: yes, i've been away from rockbox 09.35.50 # * [Saint] wonders what "creeping cryption" is. 09.35.55 # probably not, it's also worth noting that previous generations also had encrypted firmware but that was easier to break 09.36.18 # <[Saint]> Ah, encryption. 09.36.45 # <[Saint]> Heaven forbid a device manufacturer should try to protect it's interests... ;) 09.37.21 # chrisb - not necessarily - consumer manufacturers are listening - HTC, motorola and Samsung have all agreed to unlock their future devices. 09.37.37 # [Saint]: explain to us exactly how they protect "their interests" this way? 09.37.44 # [Saint]: what *are* their interests? 09.37.46 # * GodEater_wg would also be interested to hear this 09.39.46 # B4gder: Is it possible to have an @rockbox.org address forward to more than one email address? 09.39.58 Join pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) 09.39.58 Quit pamaury (Changing host) 09.39.58 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 09.40.04 # yes sure 09.40.41 # <[Saint]> It's protection, albeit not complete, against average Joe dissassembling/modifying the FW...device manufacturers that actually *want* this to happen are a fairly recent thing. 09.41.06 # this does not explain how it protects the manufacturer's interests. 09.50.27 Quit keyb_gr (Ping timeout: 268 seconds) 09.51.22 Join mem_ [0] (~mem@mem-irc.netnod.se) 09.54.48 Quit wtachi (Quit: ") 09.56.35 Quit jhMikeS (Ping timeout: 255 seconds) 09.58.18 *** Saving seen data "./dancer.seen" 10.02.23 Quit ReimuHakurei (Quit: If I use this, I will disappear, and Shana-tan will remain...) 10.03.40 Quit [Saint] (Disconnected by services) 10.03.41 Join S_a_i_n_t [0] (~st.lasciv@124-197-3-117.callplus.net.nz) 10.16.32 Join TheLemonMan [0] (~lem0n@ppp-84-59.26-151.libero.it) 10.17.50 # pamaury, ping 10.35.05 Quit antil33t (Read error: Connection reset by peer) 10.35.13 Join antil33t [0] (~antil33t@124-197-33-15.callplus.net.nz) 10.35.33 # TheLemonMan: pong 10.36.16 # got some spare time tonight and coded something to extract the blob from an usbsnoop log 10.36.32 # too bad it doesnt seem to work when uploaded to the device 10.37.52 # how do you know it doesn't work ? 10.39.03 # i can resend the payload again without resetting 10.39.27 # that means the device hasnt loaded the payload 10.39.35 # or at least that hasnt reinited the usb 10.40.55 # my guess is that it doesn't reinit usb 10.41.08 # it just handles more commands 10.41.33 # is that possible ? 10.41.37 # yes 10.41.44 # I think so 10.46.02 # do you have the binary blob downloaded on the device ? 10.46.15 # yep 10.46.17 # Would you mind sending it to me ? 10.47.16 # huh, i tried opening it with sbinfo and it gave me "ERROR: invalid key file (not enough keys): Success" 10.47.24 # i guess they used real keys :| 10.47.49 # not so sure 10.48.11 # the key has to be written somewhere on the device, I can't see how could it be different from the one of the main firmware 10.48.11 # well, no, there are 3 keys needed 10.48.20 # the first one is zero 10.48.44 # ok, send it to me, I'll have a look. You don't really need all the keys iirc 10.53.07 Quit n1s (Remote host closed the connection) 10.55.56 # i tried opening it in ida/objdump but all i got was meaningless opcodes 10.56.02 # but strings are all in place 10.56.07 Join GeekShadow [0] (~Antoine@243.162.21.93.rev.sfr.net) 10.56.07 Quit GeekShadow (Changing host) 10.56.07 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 11.02.09 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 11.03.59 Quit ChickeNES (Quit: Computer has gone to sleep.) 11.08.24 # elftosb gives me Bad file version 11.08.31 # * format 11.09.44 # sbinfo says hashes are ok so i guess the file is not corrupted 11.11.00 Quit jfc (Ping timeout: 240 seconds) 11.12.38 # but I enhanced sbinfo to check the format version and apparently is doesn't match. I have to check that 11.13.23 # indeed, minor version doesn't match. weird 11.14.03 # i guess they didnt changed the format that much 11.14.20 # let's see 11.18.14 # ok, the first key is indeed 0 11.18.39 Quit S_a_i_n_t (Quit: Imagination is for turbo-nerds who can't handle how kick-butt reality is. I'm a kick-butt reality master! I would rather die, than be imaginative. I mean that.) 11.18.40 # if you want to make it work, just just use a key file with 3 zeroes keys. The tool will ignore bad ones 11.20.18 # i did that but got a file that looks corrupted 11.20.45 # i can see the strings but when i load it in IDA it gives random opcodes 11.21.33 # New commit by 03pamaury (r29988): sbtoelf: add environment command to ignore format version checks (some files do not match it seems) 11.22.26 Join [Saint] [0] (~st.lasciv@124-197-3-117.callplus.net.nz) 11.24.39 # r29988 build result: All green 11.25.53 # TheLemonMan: it's thumb mode, entry point is at 0xB18 11.26.21 Quit liar (Ping timeout: 258 seconds) 11.26.34 # make sure you are using the latest version of the tool. My repo is not up to date, the reference version is in the rockbox repo 11.27.18 # hurr durr, sbtoelf gives me a segfault 11.27.25 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 11.28.39 # found the problem, you should first check for env variable before using it 11.30.18 # ok I'll fix that, strange that it works on my computer then. And on others too :-/ 11.31.24 # using strcasecmp would be better too 11.34.18 Quit [Saint] (Quit: Imagination is for turbo-nerds who can't handle how kick-butt reality is. I'm a kick-butt reality master! I would rather die, than be imaginative. I mean that.) 11.35.37 # why not 11.37.19 Join keyb_gr [0] (~chatzilla@p4FF02945.dip.t-dialin.net) 11.37.30 Join [Saint] [0] (~st.lasciv@124-197-3-117.callplus.net.nz) 11.37.38 # JdGordon: What's the reason for allowing soft key lock only in the WPS screen? Shouldn't this be a decision of the key map? 11.39.22 # New commit by 03pamaury (r29989): sbtools: always check the result of getenv against NULL, use strcasecmp instead of strcmp more greater flexibility ... 11.42.21 # r29989 build result: All green 11.45.13 Quit Judas_PhD (Quit: This is a quitting message) 11.58.20 *** Saving seen data "./dancer.seen" 12.09.31 Quit GodEater_wg (Quit: CGI:IRC) 12.10.29 Quit antil33t () 12.18.38 # * [Saint] wonders if it's possible (for whoever it is that maintains the forums) to add the field "IRC" to the forum profile information page. 12.20.12 # [Saint]: scorche 12.25.11 Join robin0800 [0] (~quassel@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com) 12.34.41 Join GodEater_wg [0] (~93722cd0@giant.haxx.se) 12.35.25 # B4gder / Zagor - any smart ideas about how I reply to list messages now with my rockbox.org email address as the one I've subscribed to the lists from? 12.35.59 # I just tried replying to a -committers message, but I'm guessing it's just been dumped because it didn't come from the rockbox.org one 12.36.53 # GodEater_wg: some mail client/webmail allow you to send a message from any email address as long as you have proved that you are the owner of this address 12.38.34 # Outlook doesn't it seems. 12.39.09 # GodEater_wg: i pretty much had to make a new account with all the usual settings i have and @rockbox.org set as my reply address 12.39.18 # thunderbird 12.39.46 Quit robin0800 (Remote host closed the connection) 12.41.28 # Can't use anything but outlook here at the office. 12.43.18 # join #rockbox-community 12.43.20 # oops 12.45.26 Quit [Saint] (Ping timeout: 244 seconds) 12.52.06 Join MethoS- [0] (~clemens@134.102.106.250) 13.08.35 Join S_a_i_n_t [0] (~st.lasciv@124-197-3-117.callplus.net.nz) 13.19.54 # there was a post today on the git list about someone tagging every svn commit in git when converted, resuling in over 100K tags and a git repo that crawls... 13.20.08 # Yeah I'm not going to do that :0 13.20.28 # i'm going to write you a nice recipe that finds the git commit for a given svn revision that you can put in backticks 13.20.38 # cool 13.20.39 # or an alias, or whatever. 13.20.47 # based on just the commit message having it in a standard format 13.21.16 # git log searching is fast enough that that's fine 13.21.28 # you just need a sufficently clever regex to eliminate false positives 13.21.39 # well, and it's import-tool-dependent i guess. 13.21.45 # gonna experiment with that one later today 13.22.39 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 13.23.28 Join n1s [0] (~quassel@rockbox/developer/n1s) 13.28.21 Nick S_a_i_n_t is now known as [Saint] (~st.lasciv@124-197-3-117.callplus.net.nz) 13.34.26 Join s__C [0] (~s__C@12-223.63-188.cust.bluewin.ch) 13.34.29 # hello 13.34.52 # for the last few weeks, i'm a happy rockbox user on my ipod classic 13.35.08 # now i just have one problem, which isn't hardware related 13.35.28 # when i update my database, i get 3 times the same song in the taglist 13.35.50 # even if i remove the database and perform a new check it remains 3x 13.35.57 # how to fix it ? 13.36.16 # <[Saint]> check your disk for filesystem corruption. 13.37.15 # ok 13.38.57 Join krazykit [0] (~krazykit@206.183.185.8) 13.39.27 # <[Saint]> Yeah, scan for/fix any filesystem errors, then for a re-init of the database by either manually removing the *.tcd files in /.rockbox or via the tools menu in emCORE 13.39.41 # <[Saint]> *s/for a/force a/ 13.41.48 # will the dock output soon be supported ? 13.41.56 # i mean for the sound 13.43.45 # s__C: If a filesystem repair doesn't fix this: Before you reinitialize the database, could you please make a backup copy of the /.rockbox/database.* files so that I can have a look at the corruption? Assuming you're willing to share the database, of course 13.44.03 # ok no problem 13.44.11 # <[Saint]> People never really enjoy the answers to such questions.... 13.44.36 # <[Saint]> Being a volunteer project & all, the answer is pretty much "maybe it will be, maybe it won't" 13.45.50 # why is there database_0, database_1 in .rockbox ? 13.46.10 # as well as database_idx.tcd ? 13.46.52 # the various files contain different tags, and are all indexed by the _idc file 13.47.05 # s/idc/idx/ 13.47.24 # can i remove all of them ? 13.47.30 # <[Saint]> yes. 13.47.35 # after you have backed them up 13.47.38 # all of them 13.47.41 # :) 13.47.50 # <[Saint]> If you want to guarantee you remove the database...do it via emCORE 13.48.12 # ok 13.48.24 # but i already tried that 4 times unsuccessfully 13.48.54 # that's why i'm asking here 13.49.02 # <[Saint]> what was unseccessful? the file removeal? 13.49.10 # <[Saint]> *removal? 13.49.11 # no 13.49.20 # the process you invited me to do 13.49.47 # [Saint]: why would it be safer through emcore? 13.49.58 # <[Saint]> you've already verified there are no FS errors, and re-inited the database four times already>? 13.50.05 # have you verified that there are indeed no duplicates on the disk, for example in a trashbin folder? 13.50.15 # <[Saint]> n1s: Not safer...just, not prone to user error. 13.50.27 # <[Saint]> emCORE won't miss anything ;) 13.51.24 # that is, if you look at the track's properties (in the DB browser's context menu), do all duplicate entries refer to the same file? 13.51.46 # Also, how many tracks do you have on the device, and are you using automatic DB updating? 13.52.08 # <[Saint]> Hmmmm...maybe it might be handy if Rockbox had a "kill the database" function. 13.52.33 # <[Saint]> Perhaps I'll add .idx and .tcd files to the disktidy plugin. 13.52.35 # Saint: Well, the DB init function pretty much does that 13.52.35 # i thought initialize now was supposed to do that 13.53.33 # <[Saint]> It won't remove them if they're corrupted. reiniting the db will leave corrupt .tcd files in place in my experience. 13.54.10 # Saint: Hmm, that would be a bug. Could you please file a report if you manage to reproduce it? 13.56.02 # <[Saint]> Another reason I think it might be handy to add database files to the disktidy plugin is that you might not want to use the database again after killing it. 13.57.30 # Unimaginable ;) but yeah, why not 13.58.24 *** Saving seen data "./dancer.seen" 14.00.15 # Just make sure they aren't enabled by default, otherwise I suspect we'll get some unhappy punters :) 14.00.16 # all files correctly removed by emcore 14.00.20 # now it updates again 14.01.29 # <[Saint]> AlexP: No files/extensions are supposed to be enabled by default in the disktidy config are they? 14.01.46 # [Saint]: Probably not, but no idea 14.01.54 # I haven't looked at it in a long time :) 14.02.16 # <[Saint]> I seem to remember a warning somewhere in the config saying something vaguely similar. 14.07.14 # mhh 14.07.16 # failed 14.07.33 # do you want my database files ? 14.07.49 # it's like if the update of the database was looped 3 times 14.07.53 # <[Saint]> s__C: Can you verify that there isn't a trash folder on the device? 14.08.04 # yes there is one 14.08.07 # it's emtpy 14.08.21 # <[Saint]> (this may involve the enabling of viewing hidden and system files in Windows) 14.08.49 # the linux user know how to proceed 14.10.24 # yeah the process is looped 14.10.33 # can i stop it once for all ? 14.10.52 # <[Saint]> How do you know it's looping? How are you confirming this? 14.11.30 # when i try to access the database... 14.11.38 # i rebooted once because it was finished 14.11.52 # and when i access it sth is still running 14.12.09 # <[Saint]> Out of curiousity....how are you rebooting? 14.12.34 # with the stop button 14.12.39 # not hard reboot 14.12.47 # with middle and up 14.12.55 # i use play/pause 14.14.03 # s__C: Yes, I do want to have a look at the database files. 14.14.21 # This is with Rockbox 3.8.1 I assume? 14.15.11 # If the files aren't huge or embarrassing / private, could you please open a Flyspray bug report and attach them there? 14.15.21 # embarrassing :) 14.15.32 # "yeah my database is all kylie. all te time." 14.15.53 # s__C: How many tracks do you have on the device, and are you using automatic DB updating? 14.16.12 # yes 14.17.06 # yes to all four questions? ;) 14.20.20 # version is r2964M-110325 14.20.38 # so dunno if it's 3.8.3 14.20.42 # *3.8.1 14.23.01 Quit [Saint] (Ping timeout: 268 seconds) 14.23.42 # s__C: you built it yourself? 14.23.53 # no it's from freemypod 14.24.40 Quit krazykit (Ping timeout: 240 seconds) 14.24.47 # could you try with a rockbox build from our site, either a current or release build? 14.25.52 # tell me how to use it n1s ... 14.25.59 # or anyone else 14.27.06 # http://build.rockbox.org/data/rockbox-ipodclassic.zip unzip it over the old .rockbox dir 14.27.38 # ok thx i'll try right now 14.36.24 # oh 14.36.31 # no more problems.... 14.37.10 # the new build is nicer too 14.37.15 # sorry for all the mess 14.37.36 # i think there was something between the auto update database and all the mounts / unmounts 14.37.41 Part s__C ("WeeChat 0.3.5") 14.42.07 Join krazykit [0] (~krazykit@206.183.182.189) 14.44.56 Join [Saint] [0] (~st.lasciv@124-197-3-117.callplus.net.nz) 14.45.51 Quit B4gder (Quit: Konversation terminated!) 14.50.38 Quit krazykit (Ping timeout: 246 seconds) 14.53.53 Join jfc [0] (~john@static-72-73-80-12.ptldme.east.myfairpoint.net) 14.54.51 # sideral: it wasnt my descision... it was imported from very very old code 14.54.57 # i.e 5+ years ago 14.55.28 # JdGordon: Older than keymaps, possibly? 14.55.39 Join fyrestorm [0] (~nnscript@cpe-24-90-84-81.nyc.res.rr.com) 14.56.27 # <[Saint]> ...Older than Jesus. 14.57.01 # OK, I'll go ask Moses then 15.00.15 # yes, older than keybaps 15.13.22 Join evilnick_B [0] (0c140464@rockbox/staff/evilnick) 15.43.26 Nick evilnick_B is now known as kBe_lvcini (0c140464@rockbox/staff/evilnick) 15.44.08 Nick kBe_lvcini is now known as evilnick_B (0c140464@rockbox/staff/evilnick) 15.51.07 Quit markun (Remote host closed the connection) 15.53.39 Part mem_ 15.56.01 Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com) 15.56.41 Join markun [0] (~markun@ip503cd9a5.speed.planet.nl) 15.56.42 Quit markun (Changing host) 15.56.42 Join markun [0] (~markun@rockbox/developer/markun) 15.58.15 Quit sideral (Quit: Leaving.) 15.58.27 *** Saving seen data "./dancer.seen" 16.23.39 Join wtachi [0] (~wtachi@65.190.12.236) 16.25.50 Quit TheLemonMan (Quit: Ex-Chat) 16.33.16 Quit markun (Ping timeout: 244 seconds) 16.36.15 Quit [Saint] (Quit: Imagination is for turbo-nerds who can't handle how kick-butt reality is. I'm a kick-butt reality master! I would rather die, than be imaginative. I mean that.) 16.37.11 Join jhMikeS [0] (~jethead71@c-68-61-166-99.hsd1.mi.comcast.net) 16.37.11 Quit jhMikeS (Changing host) 16.37.11 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 16.38.11 Join [Saint] [0] (~st.lasciv@124-197-3-117.callplus.net.nz) 16.48.19 Quit GeekShadow (Ping timeout: 250 seconds) 16.54.24 Join markun [0] (~markun@ip503cd9a5.speed.planet.nl) 16.54.31 Quit markun (Changing host) 16.54.31 Join markun [0] (~markun@rockbox/developer/markun) 17.01.01 Part Zagor 17.05.52 Join bluebrother [0] (~dom@g231121230.adsl.alicedsl.de) 17.05.52 Quit bluebrother (Changing host) 17.05.52 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 17.07.40 Quit bluebroth3r (Read error: Operation timed out) 17.09.28 Quit bluebrother-bot (Ping timeout: 255 seconds) 17.18.30 Quit [Saint] (Quit: Imagination is for turbo-nerds who can't handle how kick-butt reality is. I'm a kick-butt reality master! I would rather die, than be imaginative. I mean that.) 17.19.45 Join Topy [0] (~Topy44@g228141186.adsl.alicedsl.de) 17.20.17 Join bluebrother-bot [0] (~bluebroth@g231121230.adsl.alicedsl.de) 17.23.00 Join xeniter [0] (~xeniter@cpe90-146-54-20.liwest.at) 17.23.25 Quit T44 (Ping timeout: 250 seconds) 17.28.09 Quit xeniter (Ping timeout: 240 seconds) 17.30.37 Join [Saint] [0] (~st.lasciv@124-197-3-117.callplus.net.nz) 17.30.54 Quit [Saint] (Client Quit) 17.34.28 Quit robin0800 (Quit: Leaving) 17.41.05 Quit ender| (Ping timeout: 250 seconds) 17.41.18 Quit ender` (Ping timeout: 276 seconds) 17.44.08 Quit GodEater_wg (Quit: CGI:IRC) 17.45.31 Quit mshathlonxp () 17.47.52 Join ender| [0] (krneki@foo.eternallybored.org) 17.58.31 *** Saving seen data "./dancer.seen" 18.01.02 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 18.07.14 Quit petur (Quit: *plop*) 18.25.36 Join TheLemonMan [0] (~lem0n@ppp-84-59.26-151.libero.it) 18.43.22 Join Stummi [0] (~Stummi@rockbox/developer/Stummi) 18.51.17 Quit Judas_PhD (Quit: This is a quitting message) 18.57.53 Join ReimuHakurei [0] (~reimu@74.112.212.15) 19.16.45 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 19.20.01 Join bug2000 [0] (~bug@unaffiliated/bug2000) 19.31.02 Quit chrisb (Ping timeout: 260 seconds) 19.37.10 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 19.48.00 Join Horscht [0] (~Horscht@p5DD569E5.dip.t-dialin.net) 19.48.01 Quit Horscht (Changing host) 19.48.01 Join Horscht [0] (~Horscht@xbmc/user/horscht) 19.58.32 *** Saving seen data "./dancer.seen" 20.12.39 Quit AndyI (Ping timeout: 268 seconds) 20.42.41 Quit TheLemonMan (Quit: Ex-Chat) 20.51.35 Quit factor (Read error: Connection reset by peer) 20.57.24 Join factor [0] (~factor@74.197.205.204) 21.01.20 Quit liar (Ping timeout: 258 seconds) 21.01.49 Join liar [0] (~liar@83.175.83.185) 21.07.26 Join robin0800 [0] (~quassel@149.254.61.208) 21.11.59 Quit bug2000 (Ping timeout: 240 seconds) 21.12.25 Join Horschti [0] (~Horscht@xbmc/user/horscht) 21.12.53 Join Zarggg_ [0] (~zarggg@24.229.139.169.res-cmts.sm.ptd.net) 21.14.54 Quit Horscht (Ping timeout: 252 seconds) 21.15.16 Quit Zarggg (Ping timeout: 252 seconds) 21.16.56 Quit Llorean (Read error: Connection reset by peer) 21.18.02 Join Llorean [0] (~DarkkOne@99-68-45-56.lightspeed.hstntx.sbcglobal.net) 21.18.12 Quit Llorean (Changing host) 21.18.12 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 21.19.56 Quit amiconn (Disconnected by services) 21.19.57 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 21.20.08 Join Curulan [0] (~zarggg@24.229.139.169.res-cmts.sm.ptd.net) 21.20.14 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 21.22.14 Quit Zarggg_ (Ping timeout: 252 seconds) 21.23.36 # Hmmm, release schedule has us freezing on Monday 21.23.44 # Any comments? :) 21.24.37 Quit evilnick (Ping timeout: 255 seconds) 21.28.42 # we should try to make it a r30000 release ;) 21.29.27 # i guess we do that 21.29.36 # :) 21.29.44 Quit n1s (Remote host closed the connection) 21.39.40 Join kugel [0] (~kugel@g231233252.adsl.alicedsl.de) 21.39.40 Quit kugel (Changing host) 21.39.40 Join kugel [0] (~kugel@rockbox/developer/kugel) 21.42.34 Quit kugelp (Ping timeout: 246 seconds) 21.47.24 # our MajorChanges list isn't that long this time 21.47.41 # We haven't done anything :) 21.49.04 Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) 21.58.34 *** Saving seen data "./dancer.seen" 22.03.20 # What status is the FuzeV2 port supposed to be? 22.03.35 Join liar__ [0] (~liar@clnet-p09-185.ikbnet.co.at) 22.03.35 # I don't see it on the front page. 22.03.58 Quit liar (Read error: Connection reset by peer) 22.05.40 Join mudd1 [0] (~cmertes@ip-78-94-202-227.unitymediagroup.de) 22.06.43 Quit robin0800 (Read error: Connection reset by peer) 22.08.14 Quit Stummi (Quit: Bye!) 22.09.16 # I think it's supposed to work fine, just as good as the clip+ for example 22.09.59 # It seems we don't differentiate between players that are different inside but look the same outside on the main page, like clipv1 and clipv2 22.10.07 # Llorean: I believe the intention is that "clip" and "fuze" refer to both versions 22.10.17 Join saratoga [0] (98034408@gateway/web/freenode/ip.152.3.68.8) 22.11.53 # bertrik: We have some v2s listed in separate categories though 22.12.01 # Which can give a strong impression we do differentiate them. 22.12.01 Join robin0800 [0] (~robin0800@149.254.61.163) 22.12.36 # We should probably remove the lamp plugin from the FuzeV2, or demote the port, since people keep reporting hardware issues with its screen. It's clear we're not only doing something wrong, but something potentially damaging on that one. 22.13.22 # Llorean: the brightness is already capped in SVN, its just the older release builds that are a problem 22.13.45 # removing the lamp plugin from the 3.8.1 zip might not be a bad idea though 22.14.05 # apparently theres some other hardware revision that can't handle the maximum brightness 22.14.12 # I guess it's just the max brightness that's a problem, not the lamp plugin 22.14.53 # the lamp plugin sets the screen to maximum brightness though IIRC 22.15.31 # yeah so i changed the max brightness in svn a while ago 22.15.33 # let's fix the maximum brightness, not hide the problem by removing the plugin 22.15.45 Join sideral [0] (~sideral@213.165.85.248) 22.15.45 Quit sideral (Changing host) 22.15.45 Join sideral [0] (~sideral@rockbox/developer/sideral) 22.15.54 # however everyone around here has a normal player that has no problem with even the old max brightness 22.16.57 # Ah, okay 22.17.02 # it may just be that for some players they switched out LEDs or resistors to ones rated for some other current 22.17.06 Quit benedikt93 (Quit: "Facts do not cease to exist because they are ignored." - Aldous Huxley) 22.17.07 # bertrik: you can't fix the release version afterwards which is being talked about despite a new release 22.17.14 # Fixing 3.8.1 would be nice, but if we're getting 3.8.2 in a few weeks, maybe just taking it down temporarily will be good enough 22.17.18 # or maybe they changed something about how they're wired to the voltage regulators 22.17.36 Join simonlnu [0] (pfhnDeQVwM@unaffiliated/simonrvn) 22.18.05 # * amiconn wonders whether he can get X5/M5 dualboot in before the release 22.18.20 # We are getting a 3.9 in 2 1/2 weeks 22.18.22 # well OK, I don't get it 22.18.24 # bertrik: or in this case - since it's a plugin - you can remove the .rock from the zip for the time being 22.18.32 # If we stick to the schedule :) 22.18.44 # amiconn: Isn't that entirely a bootloader issue anyway? 22.19.00 # Yes it is 22.19.09 Quit robin0800 (Ping timeout: 258 seconds) 22.19.19 # but removing the plugin isn't fixing anything, just removing one specific opportunity for the problem to surface 22.19.33 # well, better than doing nothing 22.19.43 # bertrik: the talk is about the current 3.8.1 release not the coming 22.19.58 # It would still be nice to have new bootloaders to go with the release - and the patch is touching crt0.S so it should go in before freeze. Or am I missing something? 22.20.27 # at least get the crt0.S change in, then i guess release bootloaders whenever they're ready 22.20.28 # removing the plugin from 3.8.1 isn't fixing anything either 22.20.41 # Hm, I still need to see if i can fix the ipod settings reset thing before freeze.. 22.20.42 # well hopefully its "fixed" in SVN 22.20.47 # In order for this to work, I have to move the On vs. Hold detection into crt0.S, at least partially 22.21.43 # removing it in 3.8.1 would at least reduce the odds that anyone else breaks their player 22.21.43 Join robin0800 [0] (~robin0800@149.254.61.163) 22.21.43 # bertrik: it's removing one of the sources where people can mess up and get into serious trouble 22.22.01 # ok, probably the most common cause indeed 22.22.18 # saratoga: The crt0.S and bootloader changes are interdependent 22.22.31 # ah ok 22.23.02 # If I'm going for the partial move that is - then crt0.S would have to set a variable that bootloader/iaudio_coldfire.c reads later 22.23.58 # * amiconn wonders whether we can do anything about the OF obviously not liking SSDs 22.24.15 # At least mine - it will shut down after reporting a harddisk error 22.24.21 # With a real hdd, it works 22.24.36 Quit robin0800 (Read error: Connection reset by peer) 22.24.56 # The funny thing is that the preloader (also Cowon's code) is working fine with that same ssd 22.25.18 # Otherwise I wouldn't be able to flash 22.26.05 # Hmm, actually even the preloader might have a problem too. Usually it should delete the flash file after successful flashing, but now I remember that it didn't 22.26.25 # maybe it doesn't like sector size? 22.26.31 # So it probably fails on write, but is reading the ssd fine 22.26.55 # Plain bog standard 512 bytes/sector 22.26.59 # hm 22.28.19 # maybe we could simply pass an argument to main()? 22.28.46 # New commit by 03thomasjfox (r29990): Pandora port: Fix rockbox share directory path (it has to end on /rockbox) 22.31.36 # linuxstb: ping 22.32.26 # r29990 build result: All green 22.33.44 # thomasjfox: Hi 22.33.50 # linuxstb: hey there 22.34.16 # linuxstb: I'd like to commit FS #12148. Could you take a quick look at it? It's a build system modification 22.34.31 # linuxstb: The "FIXME" part is fixed now and will be omited 22.34.42 Quit ReimuHakurei (Quit: If I use this, I will disappear, and Shana-tan will remain...) 22.40.37 # thomasjfox: I've just taken a look, but know nothing about your pandora port. It seems harmless to other ports though... One suggestion would be to change the help text in root.make to something like "pnd - creates rockbox.pnd archive (Pandora builds only)" 22.40.54 # linuxstb: Sounds good to me 22.41.05 # linuxstb: Thanks for the review, I'll change the text 22.43.45 Join robin0800 [0] (~robin0800@149.254.60.35) 22.47.15 Quit robin0800 (Read error: Connection reset by peer) 22.49.04 Join krazykit [0] (~krazykit@206.183.185.8) 22.53.14 Quit saratoga (Ping timeout: 252 seconds) 22.53.52 Join ender` [0] (krneki@foo.eternallybored.org) 22.58.04 # New commit by 03thomasjfox (r29991): Pandora port: Automate rockbox.pnd (=binary archive) build 22.59.37 # I'd like to know whether people are comfortable with removing fuzzy tag matching for database resurrection of tracks that have been renamed and retagged at the same time. This is causing problems with some podcasts that comprise only similar, same-length tracks (typically radio recordings). FS#12076 has the complete story. 22.59.37 # http://www.rockbox.org/tracker/task/12076 3Autoresume feature can start from wrong offset due to resurrection of old runtime stats (bugs, assigned) 23.00.09 # roolku views removing this feature as a regression, which I won't be able to fix before the release. 23.00.36 # So I could either restore the old behavior for the next release, or we live without the buggy feature for a while 23.01.22 # r29991 build result: All green 23.03.16 # "Removing this feature" here means making the fuzzy matching less fuzzy to avoid resurrecting old runtime data for tracks that are actually new 23.04.17 Join ReimuHakurei [0] (~reimu@74.112.212.15) 23.04.47 Join sirrozha [0] (~sirrozha@89.23.217.205) 23.05.25 # sideral: It is a tricky one that 23.06.24 # I'd be inclined to leave the old behaviour until a fix for both can be found, purely as it was "first", and trying to gauge which is the more used feature/bigger problem is hard 23.06.47 # But I don't have a strong opinion either way 23.08.28 Quit MethoS- (Remote host closed the connection) 23.09.23 # Hmm. The old behavior can do the wrong thing (bad stats for a new track), whereas the current, intermediate behavior can miss the right thing (resurrect stats for track that was renamed _and_ retagged). I personally lean towards the latter behavior, which I feel is "more correct". 23.09.38 # But I respect roolku's and your view as well. Tricky indeed 23.09.46 # Well, I don't really have a view 23.10.21 # Only that in the event that it is a tie, I'd probably lean towards the first one, whichever it was 23.10.32 # I'm more likely to be hit by the second myself 23.10.38 # in fact only likely 23.10.52 # As resume is the only bit of the db I use :) 23.11.01 # It's also still unclear how to make the feature work properly. Right now I'm leaning towards fingerprinting the encoded audio data. 23.11.20 # maybe with two chunks at fixed percentages or something? 23.11.49 # I'm trying to think how to try to avoid e.g. blank sections but not taking too much time :) 23.12.23 # I think you are right in retrospect that the second option is "less bad" 23.12.34 # But as I say, I don't mind :) 23.13.22 # My first try will be fingerprinting just the first 512 bytes, under the theory that silence at the beginning of the track typically is not encoded as all zeroes. Silence in digital audio typically is encoded as pink noise with low volume (IIRC) 23.14.04 # Is there a reason for the first 512 as opposed to e.g. 10% in? Avoiding extra disk access or somesuch? 23.14.44 # because it's physically close to the metadata that is already read during the DB update 23.15.13 # Is that significant? (I have no idea what the real cost is.) 23.15.19 # I'd like to avoid seeking as much as possible 23.15.22 # OK 23.15.36 # This is of course a good aim :) 23.16.01 # I just have no feeling how much overhead it'd be to go e.g. 10% into the track @_ 23.16.28 # me neither, especially as I do not own a hard-disk-based player :) 23.17.21 # It can also be costly on flash based targets 23.17.55 # OK 23.18.38 # Depending on how long a track is, reading 10% of it could e.g. take several seconds on Ondio 23.19.05 # amiconn: Not reading 10%, but reading 512 bytes starting at e.g. 10% into the track 23.19.22 # So for a 2 MB track read 512 bytes starting at 200 k 23.19.30 # with a seek? You'd hope that the relevant part of the FAT is already cached, so it would be only 1 seek 23.19.51 # anyway, I have no idea what I'm on about so I'll stop talking :) 23.21.00 # Reading a certain position without taking metadata into account may still miss a track 23.21.49 # Metadata size MAY VARY E:G: FOR ID§V" 23.21.54 # oops 23.22.04 # *may vary, e.g. for id3v2 23.22.09 # Would you guys think that the current, intermediate behavior is a feature regression that requires a -dev discussion? 23.22.35 # amiconn: This would seek into the encoded audio, skipping the header. the metadata parsers tell us where the encoded audio starts 23.22.40 # I have no idea how much that feature is used 23.23.08 # Maybe just drop an email explaining and saying this is what you plan to do and see if anyone shouts? 23.23.19 # * amiconn would usually vote for removing guesstimation, but can't really comment on this one since he never used db runtime data collection 23.23.29 # yeah 23.23.59 # I think most people would agree with the intermediate 23.24.05 # But I have no basis for that :) 23.24.41 # OK, explaining my intention on the mailing list is a good idea 23.25.22 # There will still be time to revert to the old behavior after the freeze. 23.25.44 # I don't guess that'll be necessary 23.25.49 # but you never know :) 23.27.07 # roolku found this important enough to reopen the FS issue :) 23.27.28 # yeah, it is clearly important to some 23.28.22 Quit pamaury (Remote host closed the connection) 23.30.02 # As for new features for the next release: I plan to commit the anti- / basename patches (FS#12132 ) before the freeze 23.30.03 # http://www.rockbox.org/tracker/task/12132 3tagnavi: Support "basename" in formats and conditions; replace in track views (patches, new) 23.30.34 # basename = filename? 23.31.35 # basename = last filename component without the directory paths. (example: basename of /a/b/c.mp3 = c.mp3) 23.31.53 # this will be displayed in lieu of the track name of there's no title tag 23.31.57 # so yeah, filename :) 23.32.10 # anyway, sounds sensible 23.33.47 # There's still one class of DB views left that doesn't adhere to my new track %format (Database->*->), but I likely won't be able to complete this before the freeze. 23.40.59 # I also would have liked to include FS#12054 in the next release, but I probably won't manage to complete it before next week. Configuration is still missing, and there's one annoying misbehavior that still bugs me 23.41.00 # http://www.rockbox.org/tracker/task/12054 3Highlight each album's last-played track in database views - great for audiobooks and podcasts (patches, new) 23.41.45 Quit sirrozha () 23.43.28 Quit evilnick_B (Ping timeout: 252 seconds) 23.46.13 Quit thomasjfox (Remote host closed the connection) 23.50.02 # AlexP, pixelma: Have you been able to contact freqmod in another channel? 23.50.13 # sideral: pixelma has tried 23.50.22 # No response that I'm aware of yet 23.50.43 # OK, that matches my results. I'll try shooting him an email. 23.50.52 Join HaimN [0] (~quassel@95.86.119.222) 23.51.32 # why do you guys want to contact freqmod btw? 23.51.47 # to verify he's the author of the wikipedia plugin 23.52.12 # and that what we think is his real name really is 23.53.29 # ah I see 23.54.56 # kugel: I've read your GSoC weekly report with interest. I think you're heading into the right direction with the API and the dircache rework. But I have one question / concern: 23.56.35 # I think compaction of dircache, tagcache, and probably also skin data is not likely to reap any measurable benefit for the complexity this entails. If I were you, I'd drop this from the scope and focus solely on audio-buffer compaction 23.58.22 # compaction means the entire buffer is compacted, and individual allocation moved around 23.58.36 *** Saving seen data "./dancer.seen" 23.58.36 # individual allocation are generally not compacted