--- Log for 23.09.102 Server: brunner.openprojects.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16p1 Started: 23 days and 13 hours ago 00.16.37 Nick TotMacher is now known as tot|n8 (tot@pD9520171.dip.t-dialin.net) 00.34.59 *** Saving seen data "./dancer.seen" 00.46.51 Join Jet8810 [0] (~Joshua@adsl-35-1-217.bct.bellsouth.net) 00.50.55 Join langhaarrocker [0] (~Philipp@B49ca.pppool.de) 02.24.37 Join Foxinou [0] (~Julien@lns02v-9-177.w.club-internet.fr) 02.25.04 # hi guys 02.26.25 Part Foxinou 02.29.02 Quit Jet8810 ("Client Exiting") 02.35.01 *** Saving seen data "./dancer.seen" 02.36.35 Quit xtac ("ircN 7.27 + 7.0 for mIRC (2002/01/10 00.00)") 02.43.36 Quit langhaarrocker (Read error: 110 (Connection timed out)) 02.50.14 Nick seb-away is now known as _seb_ (user@bgp420584bgs.union01.nj.comcast.net) 04.17.48 Join PsycoXul_ [0] (psyco@adsl-63-205-46-200.dsl.lsan03.pacbell.net) 04.17.48 Quit PsycoXul (Read error: 104 (Connection reset by peer)) 04.17.56 Nick PsycoXul_ is now known as PsycoXul (psyco@adsl-63-205-46-200.dsl.lsan03.pacbell.net) 04.27.12 Join elinenbe [0] (trilluser@user-0cces0l.cable.mindspring.com) 04.35.04 *** Saving seen data "./dancer.seen" 05.06.12 Nick _seb_ is now known as seb-sleeo (user@bgp420584bgs.union01.nj.comcast.net) 05.06.21 Nick seb-sleeo is now known as seb-sleep (user@bgp420584bgs.union01.nj.comcast.net) 06.09.45 Quit Hes (brunner.openprojects.net irc.openprojects.net) 06.09.45 NSplit brunner.openprojects.net irc.openprojects.net 06.09.45 Quit Hadaka (brunner.openprojects.net irc.openprojects.net) 06.09.45 Quit tot|n8 (brunner.openprojects.net irc.openprojects.net) 06.09.45 Quit seb-sleep (brunner.openprojects.net irc.openprojects.net) 06.09.45 Quit datazone (brunner.openprojects.net irc.openprojects.net) 06.09.45 Quit elinenbe (brunner.openprojects.net irc.openprojects.net) 06.09.45 Quit PsycoXul (brunner.openprojects.net irc.openprojects.net) 06.09.45 Quit mecraw (brunner.openprojects.net irc.openprojects.net) 06.09.45 Quit Synthe (brunner.openprojects.net irc.openprojects.net) 06.09.45 Quit mem (brunner.openprojects.net irc.openprojects.net) 06.09.45 Quit webmind (brunner.openprojects.net irc.openprojects.net) 06.09.45 Quit Schnueff (brunner.openprojects.net irc.openprojects.net) 06.09.45 Quit DownKaos (brunner.openprojects.net irc.openprojects.net) 06.12.46 NHeal brunner.openprojects.net irc.openprojects.net 06.12.46 NJoin elinenbe [0] (trilluser@user-0cces0l.cable.mindspring.com) 06.12.46 NJoin PsycoXul [0] (psyco@adsl-63-205-46-200.dsl.lsan03.pacbell.net) 06.12.46 NJoin tot|n8 [0] (tot@pD9520171.dip.t-dialin.net) 06.12.46 NJoin DownKaos [0] (littldevl@BV2-24.207.202.25.charter-stl.com) 06.12.46 NJoin Hes [0] (~hessu@hessu.zedi.sonera.fi) 06.12.46 NJoin seb-sleep [0] (user@bgp420584bgs.union01.nj.comcast.net) 06.12.46 NJoin mecraw [0] (~mecraw@67.41.113.155) 06.12.46 NJoin Synthe [0] (Synthe@galt.synthe.net) 06.12.46 NJoin datazone [0] ([B5hF+FdPv@207.136.36.203) 06.12.46 NJoin mem [0] (~mem@bl-magsan.sth.bluelabs.se) 06.12.46 NJoin Hadaka [0] (naked@aka.pp.htv.fi) 06.12.46 NJoin webmind [0] (webmind@seal.student.utwente.nl) 06.12.46 NJoin Schnueff [0] (~mah@wjpserver.cs.uni-sb.de) 06.13.32 Quit Schnueff (brunner.openprojects.net irc.openprojects.net) 06.13.32 Quit webmind (brunner.openprojects.net irc.openprojects.net) 06.13.32 Quit mem (brunner.openprojects.net irc.openprojects.net) 06.13.32 Quit Synthe (brunner.openprojects.net irc.openprojects.net) 06.13.32 Quit mecraw (brunner.openprojects.net irc.openprojects.net) 06.13.32 Quit elinenbe (brunner.openprojects.net irc.openprojects.net) 06.13.32 Quit PsycoXul (brunner.openprojects.net irc.openprojects.net) 06.13.45 NJoin elinenbe [0] (trilluser@user-0cces0l.cable.mindspring.com) 06.13.45 NJoin PsycoXul [0] (psyco@adsl-63-205-46-200.dsl.lsan03.pacbell.net) 06.13.45 NJoin mecraw [0] (~mecraw@67.41.113.155) 06.13.45 NJoin Synthe [0] (Synthe@galt.synthe.net) 06.13.45 NJoin mem [0] (~mem@bl-magsan.sth.bluelabs.se) 06.13.45 NJoin webmind [0] (webmind@seal.student.utwente.nl) 06.13.45 NJoin Schnueff [0] (~mah@wjpserver.cs.uni-sb.de) 06.21.11 Quit datazone (Read error: 104 (Connection reset by peer)) 06.21.18 Join datazone [0] ([GvyNP2SjP@207.136.36.203) 06.35.05 *** Saving seen data "./dancer.seen" 06.38.12 Quit Schnueff (brunner.openprojects.net irc.openprojects.net) 06.38.12 NSplit brunner.openprojects.net irc.openprojects.net 06.38.12 Quit webmind (brunner.openprojects.net irc.openprojects.net) 06.38.12 Quit mem (brunner.openprojects.net irc.openprojects.net) 06.38.12 Quit mecraw (brunner.openprojects.net irc.openprojects.net) 06.38.12 Quit elinenbe (brunner.openprojects.net irc.openprojects.net) 06.38.12 Quit Synthe (brunner.openprojects.net irc.openprojects.net) 06.38.12 Quit PsycoXul (brunner.openprojects.net irc.openprojects.net) 06.38.12 Quit Hes (brunner.openprojects.net irc.openprojects.net) 06.38.12 Quit Hadaka (brunner.openprojects.net irc.openprojects.net) 06.38.12 Quit datazone (brunner.openprojects.net irc.openprojects.net) 06.38.12 Quit tot|n8 (brunner.openprojects.net irc.openprojects.net) 06.38.12 Quit seb-sleep (brunner.openprojects.net irc.openprojects.net) 06.38.12 Quit DownKaos (brunner.openprojects.net irc.openprojects.net) 06.38.47 NHeal brunner.openprojects.net irc.openprojects.net 06.38.47 NJoin datazone [0] ([GvyNP2SjP@207.136.36.203) 06.38.47 NJoin Schnueff [0] (~mah@wjpserver.cs.uni-sb.de) 06.38.47 NJoin webmind [0] (webmind@seal.student.utwente.nl) 06.38.47 NJoin mem [0] (~mem@bl-magsan.sth.bluelabs.se) 06.38.47 NJoin Synthe [0] (Synthe@galt.synthe.net) 06.38.47 NJoin mecraw [0] (~mecraw@67.41.113.155) 06.38.47 NJoin PsycoXul [0] (psyco@adsl-63-205-46-200.dsl.lsan03.pacbell.net) 06.38.47 NJoin elinenbe [0] (trilluser@user-0cces0l.cable.mindspring.com) 06.38.47 NJoin tot|n8 [0] (tot@pD9520171.dip.t-dialin.net) 06.38.47 NJoin DownKaos [0] (littldevl@BV2-24.207.202.25.charter-stl.com) 06.38.47 NJoin Hes [0] (~hessu@hessu.zedi.sonera.fi) 06.38.47 NJoin seb-sleep [0] (user@bgp420584bgs.union01.nj.comcast.net) 06.38.47 NJoin Hadaka [0] (naked@aka.pp.htv.fi) 06.44.13 Quit elinenbe (brunner.openprojects.net irc.openprojects.net) 06.44.13 Quit mecraw (brunner.openprojects.net irc.openprojects.net) 06.44.13 Quit Synthe (brunner.openprojects.net irc.openprojects.net) 06.44.13 Quit mem (brunner.openprojects.net irc.openprojects.net) 06.44.13 Quit webmind (brunner.openprojects.net irc.openprojects.net) 06.44.13 Quit Schnueff (brunner.openprojects.net irc.openprojects.net) 06.44.13 Quit PsycoXul (brunner.openprojects.net irc.openprojects.net) 06.44.13 Quit Hes (brunner.openprojects.net irc.openprojects.net) 06.44.13 Quit Hadaka (brunner.openprojects.net irc.openprojects.net) 06.44.13 Quit tot|n8 (brunner.openprojects.net irc.openprojects.net) 06.44.13 Quit datazone (brunner.openprojects.net irc.openprojects.net) 06.44.13 Quit seb-sleep (brunner.openprojects.net irc.openprojects.net) 06.44.13 Quit DownKaos (brunner.openprojects.net irc.openprojects.net) 06.44.42 NJoin datazone [0] ([GvyNP2SjP@207.136.36.203) 06.44.42 NJoin Schnueff [0] (~mah@wjpserver.cs.uni-sb.de) 06.44.42 NJoin webmind [0] (webmind@seal.student.utwente.nl) 06.44.42 NJoin mem [0] (~mem@bl-magsan.sth.bluelabs.se) 06.44.42 NJoin Synthe [0] (Synthe@galt.synthe.net) 06.44.42 NJoin mecraw [0] (~mecraw@67.41.113.155) 06.44.42 NJoin PsycoXul [0] (psyco@adsl-63-205-46-200.dsl.lsan03.pacbell.net) 06.44.42 NJoin elinenbe [0] (trilluser@user-0cces0l.cable.mindspring.com) 06.44.42 NJoin tot|n8 [0] (tot@pD9520171.dip.t-dialin.net) 06.44.42 NJoin DownKaos [0] (littldevl@BV2-24.207.202.25.charter-stl.com) 06.44.42 NJoin Hes [0] (~hessu@hessu.zedi.sonera.fi) 06.44.42 NJoin seb-sleep [0] (user@bgp420584bgs.union01.nj.comcast.net) 06.44.42 NJoin Hadaka [0] (naked@aka.pp.htv.fi) 06.46.19 Join adiamas [0] (~adiamas@as5300-9.216-194-23-128.nyc.ny.metconnect.net) 06.46.34 Nick adiamas is now known as adi|home (~adiamas@as5300-9.216-194-23-128.nyc.ny.metconnect.net) 06.48.31 Quit adi|home (brunner.openprojects.net irc.openprojects.net) 06.48.31 Quit elinenbe (brunner.openprojects.net irc.openprojects.net) 06.48.31 Quit mecraw (brunner.openprojects.net irc.openprojects.net) 06.48.31 Quit Synthe (brunner.openprojects.net irc.openprojects.net) 06.48.31 Quit mem (brunner.openprojects.net irc.openprojects.net) 06.48.31 Quit webmind (brunner.openprojects.net irc.openprojects.net) 06.48.31 Quit Schnueff (brunner.openprojects.net irc.openprojects.net) 06.48.31 Quit PsycoXul (brunner.openprojects.net irc.openprojects.net) 06.48.31 Quit Hes (brunner.openprojects.net irc.openprojects.net) 06.48.31 Quit Hadaka (brunner.openprojects.net irc.openprojects.net) 06.48.31 Quit tot|n8 (brunner.openprojects.net irc.openprojects.net) 06.48.31 Quit datazone (brunner.openprojects.net irc.openprojects.net) 06.48.31 Quit seb-sleep (brunner.openprojects.net irc.openprojects.net) 06.48.31 Quit DownKaos (brunner.openprojects.net irc.openprojects.net) 06.48.38 NJoin adi|home [0] (~adiamas@as5300-9.216-194-23-128.nyc.ny.metconnect.net) 06.48.38 NJoin datazone [0] ([GvyNP2SjP@207.136.36.203) 06.48.38 NJoin Schnueff [0] (~mah@wjpserver.cs.uni-sb.de) 06.48.38 NJoin webmind [0] (webmind@seal.student.utwente.nl) 06.48.38 NJoin mem [0] (~mem@bl-magsan.sth.bluelabs.se) 06.48.38 NJoin Synthe [0] (Synthe@galt.synthe.net) 06.48.38 NJoin mecraw [0] (~mecraw@67.41.113.155) 06.48.38 NJoin PsycoXul [0] (psyco@adsl-63-205-46-200.dsl.lsan03.pacbell.net) 06.48.38 NJoin elinenbe [0] (trilluser@user-0cces0l.cable.mindspring.com) 06.48.38 NJoin tot|n8 [0] (tot@pD9520171.dip.t-dialin.net) 06.48.38 NJoin DownKaos [0] (littldevl@BV2-24.207.202.25.charter-stl.com) 06.48.38 NJoin Hes [0] (~hessu@hessu.zedi.sonera.fi) 06.48.38 NJoin seb-sleep [0] (user@bgp420584bgs.union01.nj.comcast.net) 06.48.38 NJoin Hadaka [0] (naked@aka.pp.htv.fi) 06.58.08 Quit adi|home (Remote closed the connection) 06.58.13 Join adiamas [0] (~adiamas@as5300-9.216-194-23-128.nyc.ny.metconnect.net) 06.58.30 Nick adiamas is now known as adi|home (~adiamas@as5300-9.216-194-23-128.nyc.ny.metconnect.net) 07.00.48 Join Zagor [0] (bjst@as9-5-6.k.s.bonet.se) 07.01.46 Join datazone_ [0] ([NdgZxBeWG@207.136.36.203) 07.16.42 Quit datazone (Read error: 110 (Connection timed out)) 07.16.49 Nick datazone_ is now known as datazone ([NdgZxBeWG@207.136.36.203) 07.18.38 Join LinusN [0] (~linus@labb.contactor.se) 07.23.55 # mecraw? 07.24.21 # or mecraw12? 07.24.38 # morning linus 07.24.47 # morning Zagor 07.25.06 Join rwood [0] (~rdwrockbo@ca-santaanahub-cuda3-c9b-117.anhmca.adelphia.net) 07.25.11 # i'm looking into the poweroff patch 07.25.18 # ok 07.25.30 # i don't want it to run on interrupt 07.25.41 # i want it in the power thread 07.25.45 # uh, definitely not 07.25.50 # i haven't read it yet 07.26.13 # BTW, the ATA thread knows about user activity, doesn't it? 07.26.22 # yes. i was thinking about that too. 07.26.28 # ata_spin() 07.27.01 # ah, last_user_activity 07.27.09 # yup 07.27.35 # but that isn't really user activity, only disk-related user activity 07.27.47 # ah, right 07.28.40 # ok, i was thinking of letting the backlight thread record the user activity, but it seems so "secret", if you know what i mean 07.29.02 # yes, i agree. 07.29.10 # maybe a call from button_irq is still good 07.29.24 # but i want the timekeeping to be done in power_thread 07.29.40 # on a make after loading the current daily build, Updating dependencies for the apps dir fails because lang.h hasn't been built yet - or is this only on cygwin? 07.30.02 # rwood: happens all the time 07.30.17 # LinusN: ignore it? 07.30.21 # yup 07.30.37 Join merwin [0] (~none@12.242.185.10) 07.30.42 # yO 07.30.59 # yo d00d! 07.31.22 # linus! 07.31.34 # * merwin hasn't been very involved lately 07.31.53 # LinusN: it will probably be another week on the player i2c stuff - the city electrical planner has screwed up our move - we are in the new building, but have no power for production or labs 07.32.02 # :-) 07.32.07 # don't worry 07.32.29 # LinusN: is there anything on i2c for recording that would be interesting? 07.32.34 # do you still have your recorder on the operating table? 07.32.41 # LinusN: is recording being dev'd yet? 07.32.51 # LinusN: yes - for the forseeable future 07.33.12 # rwood: but no way of measuring things right now? 07.33.43 # merwin: yes 07.34.04 # LinusN: measuring what? 07.37.08 # i would like to measure EOD, PR and RTW when recording, maybe along with PA15, PB14 and PB15 07.37.30 # the timing info in the data sheets doesn't satisfy me 07.39.29 # LinusN: i can probably add the signals, same problem with getting it done - probably a week or so 07.40.26 # * merwin forsees languages being a pain in the ass for upkeep :-) 07.40.52 # rwood: ok, no need then. thanks anyway 07.41.10 # merwin: we are addressing that problem 07.42.16 # LinusN: how so? 07.44.23 # we will have scripts to keep track of the translation files, much like the coloured build table 07.45.05 # a red square for every untranslated string and so on 07.45.38 # and we will hopefully have maintainers for the languages 07.45.42 # LinusN: ahh... now that is a good idea :-) 07.46.05 # it's not reality yet, though 07.48.26 # * merwin dropped his Ericsson T68i phone ($300+) in a keg... was underwater (beer rather) for about 20 seconds... it's still in perfect condition! 07.49.24 # a friend of mine dropped his cell phone from his shirt pocket into his own coffee cup :-) 07.49.51 # instant phone death 07.50.22 # hehe 07.50.29 # berr-safe phones, eh? 07.50.31 # beer 07.50.57 # never saw that in the advertising 07.51.13 # yeah, I was doing keg stands (standing upside down drinking out of the keg) and it dropped out of my shirt pocket :-) 07.51.19 # this thing is like a rock 07.51.30 # I have a newfound respect for ericsson 07.52.04 # every phone should be designed for keg stands 07.52.10 # common daily use 07.52.27 # merwin: send them the story - next thing you know, you'll be a TV star 07.52.51 # rwood: hehe 07.52.55 # LinusN: damn straight :-) 07.53.24 # straight? rather upside down :-) 07.54.25 # LinusN: well, damn upside down then! ... This morning the LCD was blotchy and looked kind of bad, so I spent $30 and ordered a replacement LCD screen, but 12 hours later it was almost 100% clear again 08.12.22 # f 08.12.30 # ack 08.16.30 Join Bagder [0] (~daniel@as3-3-2.ras.s.bonet.se) 08.16.42 # hey ho 08.16.52 # yo 08.21.39 # only 300 mails to read ;-) 08.24.11 # Zagor: turning the led on in ata_flush before the call to write_sectors and moving the led(false) to after wait_for_end_of_transfer turns the led on until the disk has spun up - i don't know if the transfer is actually complete, but probably close enough that the power off timer will cover the write 08.24.42 # Zagor: read turns the led off after wait_for_end_of_transfer write does it before - any reason? 08.25.10 # no, looks like an error 08.25.30 # Zagor: do you want me to send a patch file? 08.25.39 # nah, i'll fix it here 08.26.43 # Zagor: is there a key combination that could be used for logical power off on the player - pause, ata_flush and power off in sequence? 08.27.43 # rwood: good idea 08.27.54 # how do you mean? 08.28.16 # aha, a shutdown() 08.28.25 # exactly 08.28.38 # i like it 08.28.41 # aha 08.29.05 # well, we are desperately short on keys on the players... 08.29.10 # i'd trade mute for shutdown 08.29.32 # but then i never use mute 08.29.47 # rwood: I wouldn't turn menu+off into poweroff :) 08.29.59 # how about holding menu+on for 2 seconds? 08.30.26 # maybe 1 second 08.30.56 # i'm usually in a hurry getting out of the car when i shutdown 08.30.57 # rwood: we want to be sure that you actually want to turn it off though... 1 second could just mean trying to slowly get into the id3 info screen :) 08.31.07 # rwood: configurable! 08.31.31 # i'll take 2 seconds - another config item would be too much 08.31.37 # rwood: agreed 08.31.54 # rwood: 2 seconds is shorter than you think 08.32.13 # rwood: just think... buy a turbo car and have to wait 60 seconds just to turn it off :-) 08.33.08 # rwood: do you leave the archos in your car or take it with you? 08.33.41 # Zagor: leave it in the car - heat probably isn't good for batteries 08.34.59 # merwin: i went to a consumer focus group to evaluate car options today - one of the options was a finger print reader to replace the key - i'll be that that would take a while before you could start the car 08.35.06 *** Saving seen data "./dancer.seen" 08.35.34 # hehe... a finger point reader? how do you have someone else start your car? 08.35.47 # r/point/print 08.36.02 # recognizes 4 finger prints & key still works 08.36.31 # rwood: sounds like what you really want is this: http://sourceforge.net/tracker/index.php?func=detail&group_id=44306&atid=439121&aid=599623 08.37.14 # rwood: ahh... well, that would probably promote body mutilation :-) "are you the owner of this car?" "yes, why?" "can I shake your hand" (hand reaches out and finger is chopped off) hehehe 08.37.48 # another option was MP3 player built into audio system with cd-rip in car or module loaded on PC 08.37.55 Join linuxstb [0] (~dave@dsl-212-23-31-215.zen.co.uk) 08.38.06 # i dunno 08.38.15 # uh, rockbox feaure mail spammed :-) 08.38.15 # Audio A8 has a radio transmitter in the key. So you only need to have it in your pocket to unlock and start the car 08.38.16 # if they're not willing to beat/shoot you for your key's 08.38.22 # they're probably not willing to start chopping 08.38.28 # Bagder: yeah, I updated a whole bunch 08.38.31 # hehe 08.38.43 # s/Audio/Audi/ 08.38.55 # Zagor: wow, I don't know if I like that either :) 08.39.56 # another option - wireless internet access to your car - lock/unlock, check fuel, turn lights on/off, download MP3 to audio system, etc 08.39.56 # Good morning. 08.40.15 # morning hes 08.40.19 # How's world? 08.40.31 # * merwin is going to bed 08.40.39 # ttyl 08.40.46 Quit merwin () 08.41.14 # Hes: world is fine 08.42.53 # played some music using rockbox at a wedding on saturday night... after our band's gig 08.43.17 # Zagor: i've been looking at the ata read retry - do you want to retry the whole transfer n times and/or read individual sectors after an error? 08.43.27 # recorded the gig on minidisc though 8-) 08.43.31 # Hes: about your charging code, it takes 40s to sample battery voltage levels, and then it sleeps for an additional 60s. So it's 1:40 for each loop? 08.43.44 # Oh, it does? 08.43.58 # That's a bug. It should sleep less. 08.43.58 # sleep(HZ*POWER_AVG_SLEEP); 08.44.13 # the whole transfer, I think. and i think we should retry n seconds, not n times, since the most likely cause of errrors is physical jarring 08.44.21 # POWER_AVG_SLEEP is 10 08.44.36 # Ok, that is correct 08.44.49 # /* sleep for roughly a minute */ 08.44.49 # sleep(HZ*(60 - POWER_AVG_N * POWER_AVG_SLEEP)); 08.45.01 # ah, ok. I am blind 08.45.07 # It sleeps for 20 seconds in the end. The comment is old. 08.45.14 # Sorry for my bad comments again 8-) 08.45.34 # Looking at doing improvements there? 08.45.36 # sorry for my bad eyesight :-) 08.45.52 # Hes: i am looking into putting the auto-poweroff there 08.46.00 # That'd make sense. 08.46.29 # Probably enough to run the auto-poweroff once per minute. 08.46.35 # absolutely 08.46.48 # And only if charger is not plugged in. 08.46.58 # yup 08.47.08 # Bagder: i'm splitting the lcd.c into lcd-player and lcd-recorder. this, of course, makes the simulators very upset. have you given this any thought? 08.47.10 # Zagor: good idea - i'll start working on it 08.47.19 # mecraw has an idea of a sleep timer that shuts off regardless, after a longer timeout 08.47.27 # Zagor: yes, the player sim would need both files 08.48.04 # Zagor: or possibly only the recorder one, with some stubs for the player functions redirected to the recorder versions 08.48.56 # LinusN: and restart charging with the archos charger then? 08.49.12 # Zagor: 1 more question - do you want a tight loop on the retries, or sleep a fraction of a second between retries? 08.49.27 # Hes: hehe, i didn't think of that 08.49.32 # rwood: a small delay is probably good 08.49.50 # Zagor: i agree - let others have a turn 08.50.17 # Hes: i guess it should never shut off when the charger is attached... :-) 08.50.29 # LinusN: nope, since it will auto-poweron anyway. 08.51.09 # and we don't want the users to use the steenkin' Archos charger, do we? 08.51.10 # The little beast powers on if you plug anything in the DC input even if there's no electricity involved. 8-) 08.51.19 # an unpowered charger is fine 08.51.30 # LinusN: Nope, if they don't actually want to 08.51.38 # it's a Good Thing to be able to choose 08.57.31 Join langhaarrocker [0] (~Philipp@B2562.pppool.de) 08.59.57 # Good morning. Has anyone looked at my cuefile patch I sent to the mailing list last night? 09.00.18 # I've been looking forward to the poweroff timer, it's really easy to power the thing on accidentally, especially with spare batteries in the front pocket of the pouch 09.00.45 # I vote for us starting to use the "patch tracker" on sf 09.00.52 # i agree 09.02.30 # Does that mean patchers need a sf login? 09.02.30 # moin 09.03.09 # moin. Must go unfortunately. Have some stupid lessons at some stupid school. 09.03.55 # The controversial part of my patch is that it is in firmware - my view is that it is very closely linked to the id3 information, so it belongs in the same place as id3.c 09.04.41 # langhaarrocker: no, it would mainly mean that patches would be posted to a better system/queue 09.05.24 # linuxstb: i still disagree. id3 is an integral part of mp3 playing. cue files are not. how many mp3 players do you know with built-in cue file support? 09.06.04 # 1 09.06.06 # :) 09.06.06 # i consider playlists more closely linked than cue files. and playlist handling is in apps. 09.06.19 # But cuefiles provide the same information as that contained read by id3.c - track titles and running times. 09.06.46 # yes 09.07.00 # It just seems a lot cleaner to keep it all together - i.e. whenever a an id3 header is read, we know we also need to read the cuefile. 09.07.12 Quit rwood () 09.07.33 # a .cue for this purpose is more like a .m3u 09.07.41 # afaik cue files provide track names, not track titles? 09.07.51 # Schnueff: my point exactly 09.07.54 # so people can click on the .cue later to start playing the associated playlist 09.08.06 # "associated playlist" wrong term 09.08.39 # Schneuff: no - my choice was to make cue support "invisible" - i.e. it is read whenever the user plays an mp3 file containing a cue file. 09.08.59 # an mp3 file does not contain a cue file. a cue file references an mp3 file. 09.09.17 # Zagor: that's true. 09.09.40 # So should the cue file be ignored if the user just plays the mp3 file? 09.09.46 # yes 09.10.03 # .cue should be treated as .m3u 09.10.04 # i think so too 09.10.09 # And should cue files be allowed inside .m3u files? 09.10.12 # no 09.10.21 # i don't get it 09.10.30 # what feature does cuefiles add? 09.10.33 # one could make some new filetype for that 09.10.47 # LinusN: u can play whole-cd-rips trackwise 09.10.51 # whole-cd-rip-as-one-mp3 09.10.59 # and a playlist can not? 09.11.11 # gaps 09.11.22 # what gaps? 09.11.26 # between tracks 09.11.28 # I use it for a different reason - I make a long radio recording, and use a cue file to make marks in the recording - like DVD chapters. 09.11.33 # between files, i mean 09.11.41 # aha, an entire mp3 file wor the whole disk? 09.11.44 # for 09.11.46 # yes 09.11.50 # ic 09.12.22 # if u have it as one single mp3, a playlist is insufficient 09.12.22 # (unless we extend it with time offsets for each track) 09.12.22 # (time offset + length) 09.12.55 # * LinusN fills his coffee cup 09.14.09 # doing this with .cue files is a hack, in my opinion, but winamp has a plugin to support this 09.14.29 # (although i dont use winamp, so i could not try :) 09.14.45 # i think cue file support is cool, but I want it handled like any other playlist 09.15.13 # can playlists reference playlists? 09.15.23 # hm 09.15.33 # structs should not be called *_t. only types are _t 09.15.39 # But I may want to play three or four 30 minute mp3 files in succession, each with a cue file - how would this work. 09.15.39 # PsycoXul: no 09.15.43 # why not? 09.15.47 # Zagor: OK. I'll change that. 09.16.08 # Zagor: I am aware I waste RAM - I'm also going to work on that. 09.16.12 # linuxstb: it doesn't work right now, just like we can't have playlist-in-a-playlist. when that works, cue files in playlist works too 09.16.16 # i guess one can start with .cue file and then make something better 09.16.25 # combined .cue files / playlists 09.17.18 # I've thought about this a lot, and I just think it is more natural for the user to "play" the mp3 file, and for Rockbox to automatically find and use the cue file. 09.17.24 # ideas arise, are implimented, and their seperateness of implimentation slumps into the rest with time and evolves to become a smaller, cleaner part of the whole, and it is good 09.17.55 # amen 09.18.20 # linuxstb: that means we require all mp3 with cue files to have id3v2 'cue' tags 09.18.47 # there's id3v2 'cue' tags? 09.18.51 # No - the current patch just looks for a ".cue" file with the same name as the ".mp3". I don't like id3v2 tags. 09.18.59 # linuxstb: ok 09.19.03 # heh 09.19.09 # there's something like marking specific times in the track 09.19.29 # but i guess it's not meant for trakc times 09.19.47 # can you guys reach www.id3.org? 09.19.59 # no, but i got it in my wwwoffle 09.20.02 # or has it moved? 09.20.02 # :) 09.20.11 # LinusN: i can't reach it 09.20.12 # dunno exactly, had problem too in the past weeks 09.20.16 # _weeks_ 09.20.32 # RIAA has shut it down :-) 09.21.15 # fuck riaa 09.21.16 # linuxstb: also, you can't cut down MAX_ID3_TAGS to four. it's too low. 09.22.04 # Zagor: It's fine for me :-) But this was because of my "stupid" memory management. I'll fix this soon and Cue-file support should only take about 8K of buffer space. 09.22.30 # 8K!!!!! 09.22.45 # linuxstb: optimise more. keep a list of positions instead of the whole file in ram 09.22.46 # LinusN: Is that good or bad? 09.22.53 # bad 09.23.10 # But it needs to know that track and title names of up to 99 tracks. 09.23.14 # what us taking 8K? 09.23.23 # aha 09.23.30 # 99 tracks? 09.23.30 # if one got it merged with playlist, it should take less mem 09.23.31 # linuxstb: that can be read when needed. we don't need it in ram all the time. 09.23.33 # I'll repeat that. Track title and track performer for 99 tracks. 09.24.10 # how common is 99 tracks? 09.24.12 # also cuefile doesn't need to be MAX_PATH. we require it to be in the same dir as the mp3 file. 09.24.32 # OK. I agree that the memory usage can go down a lot. This will be my next priority. 09.24.38 # Zagor: technically it still needs to be MAX_PATH 09.24.56 # it *may* reside in the root, and be 260 bytes long 09.24.57 # LinusN: doh, right 09.25.06 # linuxstb: check what the playlist code does - the playlist is not in memory, just offsets to the file where the actual mp3 filenames are 09.25.44 # you could do the same, store offsets to the track information in the cuefile and read it when you need it 09.25.46 # the behaviour could ne the same 09.25.51 # I will need to buffer MAX_ID3_TAGS number of track titles in RAM from my cue file. 09.26.15 # Hes: That is what my current implementation does - but it buffers the whole cuefile in RAM. 09.26.51 # so using the playlist approach could be the solution? 09.27.13 # I have one problem with merging it with playlists - I want the progress bar to show the entire track, with "tick marks" to indicate the individual tracks. 09.27.14 # could support Huge cue files. 09.27.17 # and if done cool enough, you can use the ordinary shuffle as well! :-) 09.27.49 # But maybe I am on my own with that. 09.27.58 # linuxstb: have you tested having a cue file in a playlist? 09.28.01 Quit langhaarrocker (Read error: 110 (Connection timed out)) 09.28.12 # linuxstb: i think that's a cool thing 09.28.49 # Zagor: No, only in a directory, and then next/prev works between files with and without cuefiles. 09.29.41 # ok. the only thing i'm against, really, is the introduction of application data in the id3 struct 09.30.08 # since cue files are handled in wps.c, it *is* application data... 09.30.38 # Do any files in the firmware directory use the id3 data? 09.31.26 # mpeg.c 09.32.10 # And cuefiles contain the same information as id3 tags... 09.32.44 # hm 09.32.54 # in a sense, yes. but look at how mp3 files are handled. mpeg.c gets a filename, plays it, end of story 09.32.59 # cue files are for makeing the toc on a cd. 09.33.07 # they won't contain all id3 files 09.33.11 # eh tags 09.33.14 # with cue files, it's so much more complicated. we need to simplify it. 09.33.29 # what about supporting time tags on each mp3 09.33.50 # like file.mp3[:30.12-2:30.0] or such thing 09.34.09 # I think my cuefile patch is very simple - tiny change to id3.c and then small changes to wps.c and wps-display.c. 09.34.10 # nah, lets not invent new "standards" :-) 09.34.11 # (cdparanoia-like syntax) 09.34.23 # All the complicated work will be the memory management done by cuefile.c 09.34.32 # linuxstb: yes, the code is simple. but the design gets muddled. 09.34.33 # but one could load a .cue file than like an extended playlist 09.34.40 # * Hes ignores the freezing weather and drives to work 09.34.56 # and one could play a track from one big-mp3 and then from another big mp3 by using extended playlists 09.35.59 # Schneuff - I personally don't use cue files, but they seem to be the only available "standard" for the job. 09.36.06 # i agree, new standard are not desired. but cue files are not really meant for such thing 09.36.13 # linuxstb: yes, i am aware of that 09.36.30 # But people use them (e.g. mp3cue for winamp). 09.36.45 # yes, it would be good to support them 09.36.59 # but it could be easier, by allow playlist entries to have a start time and a length 09.37.17 # There is no harm in allowing that. 09.37.28 # ... but how would you name the track? 09.37.35 # and then u could load a .cue by constructing such a playlist 09.38.02 # linuxstb: hm yes good point 09.38.03 # Schnueff: people don't want to change their data. they simply want us to support it. 09.38.12 # although extended m3u support such things 09.38.30 # (for example for playing a http mp3 stream, u can't tell the name of the stream from the url) 09.38.43 # (but u can still have it in an m3u) 09.38.47 # linuxstb: you could check for (and read) cue file in wps.c:441 09.38.53 # In my mind this is also linked to the eventual "editting of mp3 recordings" that people will be asking for. 09.39.00 # yes 09.39.13 # i.e. 1) Create a cuefile on the rockbox 2) (optionally) split the mp3 file according to cue file. 09.39.40 # linuxstb: how do the .cue files support having 'tags' in them exactly? 09.40.04 # Look at the comments at the start of the cuefile.c that I posted to the mailing list... 09.40.07 # it would be cool to be able to insert queue points while recordding, just press a key for "add queue point" 09.40.15 # yes 09.40.18 # hmm, no that would mean spinning the disk again.. 09.40.27 # (my wps.c:441 idea) 09.40.29 # Zagor: why? 09.40.32 # aha 09.40.33 # ah 09.40.46 # linuxstb: will have a look 09.41.45 # what i'm getting at is that this is an id3 extension. it won't be the last. people will have lyrics files, album cover images, videos, you name it. we can't keep adding that kind of application data to struct mp3info every time. 09.41.59 # mp3entry 09.42.06 # hm, but such things are supported by id3v2.4 09.42.26 # My view is that id3.c should be moved to apps. 09.42.32 # that's not the issue. id3.h is the issue. 09.42.48 # linuxstb: maybe. but then we get sticky issues with mpeg.c instead 09.43.16 # I think I will get sticky issues if I move cuefile.c to apps (but I'll have to think more about that). 09.44.30 # linuxstb: i guess these tags are the things the cd-text support (the track-name-thing for cd players) 09.45.09 # mpeg.c calls the mp3info function, and it is at this time that the cuefile information is also needed. 09.45.22 # so if u burn an audio cd with such a cue and then play it in a cd-text compatible hardware, the names appear 09.47.33 # Zagor: Re: line 441 of wps - I think that may work. 09.47.37 # how about this: we add an apps callback, "read_app_data()" or something, that mp3info calls for each new file. 09.47.50 # linuxstb: no, that would spin up the disk on every track change 09.47.57 # even if mpeg data is already cached 09.48.07 # True. I'll catch up soon.... 09.48.11 # I think a callback sounds fine 09.48.38 # but how will the app know when the data is no longer needed? 09.48.56 # free_app_data() :-) 09.49.04 # morning, all 09.49.09 # hi mecraw 09.49.49 # mecraw: hi! I am applying your patch, with modifications 09.50.12 # howdy 09.50.12 # maybe the app should handle at least two data sets 09.50.12 # did i see some auto-poweroff comments earlier? 09.50.12 # so it can be called for the current and next song, when disk is spinning 09.50.23 # re cuefile path: we already have mp3entry->path. it's just the last 3 chars that differ. that can be handled in a stack var to save 260 bytes/cue file 09.50.27 # i'm letting the power management thread handle the timeout 09.50.31 # LinusN: cool 09.50.49 # i can't see why the sleep timer is in global_settings? 09.51.15 # LinusN: i wasn't exactly sure where to put it, i figured i'd let the Swedish triumvirate decide :) 09.51.43 # i'm leaving the sleep timer out for now 09.52.20 # i'm not sure how we want to handle that in the best way 09.52.51 # so i'll apply the simple auto-poweroff and let the sleep timer be discussed further 09.54.44 Quit elinenbe (brunner.openprojects.net irc.openprojects.net) 09.54.44 NSplit brunner.openprojects.net irc.openprojects.net 09.54.44 Quit PsycoXul (brunner.openprojects.net irc.openprojects.net) 09.54.44 Quit mecraw (brunner.openprojects.net irc.openprojects.net) 09.54.44 Quit mem (brunner.openprojects.net irc.openprojects.net) 09.54.44 Quit webmind (brunner.openprojects.net irc.openprojects.net) 09.54.44 Quit Schnueff (brunner.openprojects.net irc.openprojects.net) 09.54.44 Quit Synthe (brunner.openprojects.net irc.openprojects.net) 09.54.56 NHeal brunner.openprojects.net irc.openprojects.net 09.54.56 NJoin elinenbe [0] (trilluser@user-0cces0l.cable.mindspring.com) 09.54.56 NJoin PsycoXul [0] (psyco@adsl-63-205-46-200.dsl.lsan03.pacbell.net) 09.54.56 NJoin mecraw [0] (~mecraw@67.41.113.155) 09.54.56 NJoin Synthe [0] (Synthe@galt.synthe.net) 09.54.56 NJoin mem [0] (~mem@bl-magsan.sth.bluelabs.se) 09.54.56 NJoin webmind [0] (webmind@seal.student.utwente.nl) 09.54.56 NJoin Schnueff [0] (~mah@wjpserver.cs.uni-sb.de) 09.57.37 # mecraw: who would want an auto-poweroff less than 1 minute? 09.57.56 # "202 messages saved and deleted" the weekend's share of rockbox mail ;-) 09.58.37 # LinusN: I could very well imagine having it set to less 09.58.53 # ugh 09.59.08 # why would I leave it doing nothing for a hole minute? 09.59.25 Quit Schnueff (brunner.openprojects.net irc.openprojects.net) 09.59.25 Quit webmind (brunner.openprojects.net irc.openprojects.net) 09.59.25 Quit mem (brunner.openprojects.net irc.openprojects.net) 09.59.25 Quit mecraw (brunner.openprojects.net irc.openprojects.net) 09.59.25 Quit elinenbe (brunner.openprojects.net irc.openprojects.net) 09.59.25 Quit Synthe (brunner.openprojects.net irc.openprojects.net) 09.59.25 Quit PsycoXul (brunner.openprojects.net irc.openprojects.net) 09.59.25 # the power management thread has a resolution of 1 minute :-( 09.59.29 # how long is the stock archos timeout? 09.59.36 # dunno 09.59.45 NJoin elinenbe [0] (trilluser@user-0cces0l.cable.mindspring.com) 09.59.45 NJoin PsycoXul [0] (psyco@adsl-63-205-46-200.dsl.lsan03.pacbell.net) 09.59.45 NJoin mecraw [0] (~mecraw@67.41.113.155) 09.59.45 NJoin Synthe [0] (Synthe@galt.synthe.net) 09.59.45 NJoin mem [0] (~mem@bl-magsan.sth.bluelabs.se) 09.59.45 NJoin webmind [0] (webmind@seal.student.utwente.nl) 09.59.45 NJoin Schnueff [0] (~mah@wjpserver.cs.uni-sb.de) 09.59.46 # i think 1 minute resolution is ok 09.59.52 # LinusN: ... I would *never* set it less than one minute, didn't I tell you that? B-] 10.00.13 # ok, so 1 minute resolution can be OK? 10.00.22 # * Bagder erases the log too 10.00.50 # let's use that for now and wait for the crowds to complain 10.00.54 # LinusN: yes 10.00.57 # ok 10.01.49 # is a plain integer ok for timeout setting, or should we use a 1,2,3,5,10,30,45,60,120 minute setting approach? 10.02.01 # sleep timeout of less than 5 minutes is probably useless (except for my testing) :) 10.02.01 # plain integer is ok 10.02.18 # 0 for never 10.02.35 # mecraw: how would a user want the sleep timeout to work? 10.02.42 # And we can change the power thread a little to allow for a shorter timeout. 10.02.50 # Hes: true 10.02.56 # To summarise our cuefile discussions - I'll keep it in firmware for now (so mpeg.c can call it at the right time), but improve the memory handling. Is that OK? 10.03.14 # LinusN: "shut off in 10 minutes no matter what" 10.03.18 # I have been thinking about modularizing the thread a bit (moving things from the thread function to other functions it'd call) 10.03.30 # linuxstb: it's ok, but I won't commit it. i want to solve the design issue first. 10.03.39 # would anyone want a longer autopoweroff than, lets say 10 minutes? 10.03.50 # LinusN: probably :-) 10.03.53 # LinusN: I doubt it, then they disable it 10.03.53 # haha 10.04.09 # so a 4-bit field would ne enough? 10.04.12 # be 10.04.13 # Zagor: Do you still want cuefiles to act like playlists? i.e. the user plays the cue file? 10.04.26 # LinusN: I think so, yes 10.04.32 # linuxstb: no, i agree with you that auto-finding the cue file is a good feature 10.05.15 # i just put a bunch of times in just to appease the masses, even though someone will want it to poweroff after 3 hours and 12 minutes.... can't please everyone 10.05.19 # So is "apps or firmware" the only outstanding issue (apart from RAM) ? 10.06.25 # LinusN: people will want sleep poweroff times of longer than 10 minutes... maybe not for idle poweroff though 10.06.50 # linuxstb: it's i little more than just where the files are located. it's about which code does what work. 10.07.33 Quit datazone (Remote closed the connection) 10.08.07 # mecraw: is it intentional to not save the sleep poweroff timer? 10.08.40 # Zagor: Sorry. but I'm not sure I see the difference. 10.09.06 # LinusN: the sleep poweroff should only be used for one use 10.09.30 Part LinusN 10.09.51 # linuxstb: I don't like id3.c doing cuefile work. i much prefer a generic callback. 10.11.14 # Zagor: I understand that point - that's what I meant about putting cuefile stuff in "apps". 10.12.16 # linuxstb: good. then id3.c should not call read_cuefile() but rather read_app_data(), which will in turn call read_cuefile and store that data locally (not in mp3entry struct) 10.13.23 Join LinusN [0] (~linus@labb.contactor.se) 10.13.34 # cue file support with vbr is not very accurate, right? 10.13.52 # nope 10.14.01 # wrong? hm 10.14.01 # Schnueff: not 100%, but shouldn't be too bad either 10.14.03 # only in 1% steps 10.14.32 # iirc, the bitrate was averaged or such thing. but with long rips, the bitrate should vary a great deal 10.14.37 # so in a 100 minute MP3 it would be in 1 minute resolution 10.14.57 # if we use the standard VBR headers 10.15.09 # LinusN: no, it would just be 100% correct in 1 minute resolution. you can still make a decent average estimate for smaller resolution 10.15.19 # hm, for ripping whole cds with cue file (which is the standard application) thats way to bad 10.15.25 # like we do for ffwd/rew 10.16.32 # Work is calling me - I'll have to leave that problem to you for now. Another problem is that even in CBR files, the frame length can vary by one byte (the padding byte). 10.16.55 # Zagor: i stand corrected 10.16.56 # bpt includes that byte, doesn't it? 10.17.02 # bpf, i mean 10.17.10 # Sorry, what's bpf? 10.17.16 # bytes per frame 10.17.46 # That's what I mean - bytes per frame can be either (for example) 576 or 577 bytes, depending on the padding bit. 10.18.16 # very few files use the padding bit, what i know 10.18.39 # maybe internet radion streams 10.18.57 # Yes - but I've found some :-(. I've written a very simple "mp2cut" utility that cuts layer 2 recordings. Some of these have padding bytes. 10.18.57 # but i doubt it 10.19.05 # My examples are digital satellite broadcasts. 10.19.25 # But I agree - it is very rare. 10.19.32 # LinusN: did you see my response to your sleep timer question? 10.20.04 # See you later. 10.20.05 Quit linuxstb ("using sirc version 2.211+KSIRC/1.0") 10.20.14 # mecraw: no 10.20.46 # sleep is only used for one use, so there is no need to save it 10.21.12 # Zagor: FYI, the padding bit can't be included in bpf, since it is different for each frame 10.21.21 # mecraw: i know 10.21.44 # mecraw: people could get tired of adjusting it to their needs (and then they sleep without timer :) 10.21.50 # fun fun fun on the autobahn... 10.21.51 # but the user is expecting the settings to be persistent 10.22.13 # LinusN, mecraw: you are discussing different things. idle poweroff and sleep are two separate functions. 10.22.14 # yes, they might like to use the same sleep timer every time 10.22.20 # i'd rather have a sleep setting, and a "go to sleep" button of some kind 10.22.57 # LinusN: most devices activate the sleep function anew every time. toggling off, 15, 30, 60, 90 minutes or some such. 10.23.22 # Zagor: it could still default to the previous selected time 10.23.26 # that's how my tv works, i have to set it every time 10.24.03 # Bagder: it could, but I don't quite see the point. i say we follow how other devices work. 10.24.12 # the default would be cool, but i didn't want to take up more space in rtc than was necessary 10.24.13 # sure, that's not a big thing 10.24.27 # especially if we only have like 4 different times 10.24.51 Join pyvasene [0] (~pyvasene@ns1.alcove-solutions.com) 10.24.56 # so, the 22 times are too much :) 10.25.20 # hehe, yeah i'd say so :-) 10.25.54 # i'm only implementing the auto-poweroff for now 10.26.08 # for now the really long timeouts will be useful since we can't turn repeat off 10.29.18 # my 5800 file playlist takes a while to complete too :-) 10.29.56 Nick tot|n8 is now known as TotMacher (tot@pD9520171.dip.t-dialin.net) 10.30.14 # Zagor: increase the pitch! ;-) 10.30.15 # is anybody working on the repeat option? 10.30.16 # LinusN: are you going to implement the idle poweroff so it powers off when paused? 10.30.28 # do we want that? 10.30.45 # i think we do 10.30.46 # LinusN: quelsaruk is looking into the repeat stuff 10.30.57 # i think so too 10.31.15 # ok 10.31.50 # i'm setting it to 0..15 minutes, 0 being OFF 10.32.14 # or is 10 enough? 10.32.14 # do we need to limit it so much? waste a byte, to avoid complaints 10.32.30 # sometimes i try to turn off rockbox ~200 songs into a 2200 song playlist, but don't hold stop long enough, so i have to start all over... now i can just pause it with idle poweroff set to 30 seconds and just leave it alone 10.33.06 # mecraw: min idle off is not 1 minute :-) 10.33.16 # i need to implement a set_int with a special case for the 0 value... 10.33.54 # LinusN: use set_option then 10.34.08 # that's why i want to limit the max 10.34.24 # or it would be a HUGE array of options 10.35.04 # well with an option we can quantify it a bit. off,1,2,3,4,5,10,15,20,30 10.35.10 *** Saving seen data "./dancer.seen" 10.35.25 # hence my question before 10.35.38 # why not let it be less than 1 minute? 10.35.44 # i know. i wasn't thinking 10.35.48 # is a plain integer ok for timeout setting, or should we use a 1,2,3,5,10,30,45,60,120 minute setting approach? 10.35.55 # that was my question 10.36.41 # mecraw: because the power thread only wakes up once/minute 10.36.51 # ah 10.36.54 # in the current solution, it can be changed 10.37.15 # i don't quite see the need for <1min shutoff, though 10.37.30 # me neither 10.37.30 # mecraw will simply have to learn to shut off properly :-) 10.37.42 # LinusN: why not do the sleep part too? isn't it a heavily requested feature? 10.37.50 # the "clean" shutdoen idea is good, btw 10.37.52 # Zagor: :p 10.38.09 # i'm not sure i like the UI approach 10.38.16 # it is very frequently requested indeed 10.38.30 # LinusN: how is the approach? 10.38.32 # is it ok to have that in the settings, non-persistent? 10.38.42 # sleep? yes. 10.38.48 # ok, then 10.38.53 # Zagor: i won't have to worry about shutting down properly once you have disk writing working and we can store the settings for each playlist :_ 10.38.57 # :) 10.39.18 # hmm, wait. do we have anything else non-persistent in settings? 10.39.23 # I think the sleep-timer doesn't have to be considered a setting 10.39.32 # it could be a "function" in a menu 10.39.45 # Bagder: exactly what I was thinking :) 10.40.10 # that's why i wanted to wait with the implementation and discuss it first 10.41.30 # commit idle-off first 10.42.03 Nick TotMacher is now known as tot|away (tot@pD9520171.dip.t-dialin.net) 10.42.52 # 8 languages in cvs now, pretty cool 10.45.31 # 0,1,2,3,4,5,6,7,8,9,10,15,30,45,60 10.45.38 # is that OK for the poweroff? 10.46.23 # yup 10.46.57 # i want 83 minutes! 10.46.59 # * mecraw hides 10.47.04 # heh 10.47.22 # * Bagder swings 10.47.24 # ;-) 10.48.04 # * mecraw falls over... due to intoxication and the wind from Bagder's miss 10.53.54 # good night from the Rockies... can't wait to build from CVS in the morning! 10.54.09 # night mecraw 11.03.17 Quit pyvasene ("Leaving...") 11.03.20 Join TotMacher [0] (tot@ip67.rsidus.riege.de) 11.04.19 # any opinions which bugs we should fix for 1.4? 11.04.55 # i'm a little puzzled by the priorities 11.05.10 # explain 11.06.09 # random regularly repeats, is that a confirmed bug? 11.06.25 # regarding 612509, did we fix that fat_mount after the 1.3 release? 11.06.47 # Bagder: let me check 11.07.00 # LinusN: half confirmed :-) i still can't repeat it. 11.07.27 # the discussion has turned into a feature request 11.07.41 # Bagder: that was fixed in 1.3. his problem is a truly odd fat partition, IMHO 11.07.59 # probably yes, but then we could set that to fixed I guess 11.08.45 # Bagder: well, it's still something of a problem since it works with archos firmware 11.09.15 # ah, sorry, I misread your comment, I thought it was fixed _after_ 1.3... ok, then it is a bug 11.10.06 # LinusN: i interpret that request as a workaround for the bug 11.12.54 Join pyvasene [0] (~pyvasene@ns1.alcove-solutions.com) 11.22.27 # Zagor: i don't 11.22.55 # LinusN: his request does not explain the bug 11.23.01 # i think he wants resume to resume in the same playlist, but doesn't want the random seed to be the same 11.23.22 # because he wants "true" random 11.23.29 # sure. but that still doesn't explain the behaviour he gets. 11.24.17 # stopping the player without pausing explains it perfectly 11.25.25 # ah, right. could be that. 11.25.51 # as i explained in my long comment 11.26.34 # i just hate the word wrapping in SF's bug tracker 11.27.24 # i agree 12.25.32 # Bagder: are you there?= 12.35.14 *** Saving seen data "./dancer.seen" 12.51.16 Join Jet8810 [0] (~Joshua@adsl-35-1-217.bct.bellsouth.net) 12.52.57 Join Schnueff_ [0] (~mah@wjpserver.cs.uni-sb.de) 12.53.02 Part LinusN 12.56.59 Quit Jet8810 ("Client Exiting") 13.13.05 Quit Schnueff (Read error: 110 (Connection timed out)) 13.16.41 Join kargatron [0] (~Vincent@ppp-isdn-732.ath.forthnet.gr) 13.17.26 # in request tracker, is high priority # correspond to high or low priority? seen it used both ways 13.18.14 # high # == high prio 13.18.50 # ah, cool (since Zagor bumped up wps tag request :-) 13.18.58 # :-) 13.19.17 # i wish request tracker could sort by last modifed, to see latest comments easily. is that configurable? 13.20.11 # no. sourceforge gives us no last-modified date 13.25.00 Join LinusN [0] (~linus@labb.contactor.se) 13.25.30 Quit tot|away (Read error: 110 (Connection timed out)) 13.25.45 Join tot|away [0] (tot@p5084B1A7.dip.t-dialin.net) 13.27.32 # when completely refreshing/replacing jukebox contents, is it recommended to reformat the drive? to get rid of fragmentation, etc? 13.29.18 # can't hurt 13.33.01 # * Bagder is back 13.33.53 Nick Schnueff_ is now known as Schnueff (~mah@wjpserver.cs.uni-sb.de) 13.38.07 # Bagder: can you look at the playsim? my lcd split broke it in some strange ways 13.38.18 # sure 13.38.22 # the charset break is the least strange :-) 13.42.09 # well, it almost works for me 13.42.18 # just some graphical errors 13.42.46 # and the cursor moves wrong 13.43.19 # how are we gonna solve the charset issue for the player sim? any ideas? 13.45.36 # i want it simulated closely to the real thing. with lcd_define_pattern and all 13.45.51 # maybe we can simply blow it up 2x to get the right "feel" 13.45.59 # too bad no one really cares about the player sim 13.46.05 # yeah 13.47.48 # if someone else fixes the charset(s), can you write the code? 13.48.25 # I could 13.54.31 Quit Schnueff (Read error: 110 (Connection timed out)) 14.05.44 Quit mem ("reset") 14.11.14 Join langhaarrocker [0] (~Philipp@B232c.pppool.de) 14.13.57 # Bagder: And the winner is ... ? 14.14.34 # oh, right 14.14.39 # forgot 14.18.08 # LinusN: red build 14.20.13 # those f*ing simulators 14.20.43 # * Bagder watches LinusN's mouth with soap ;-) 14.20.47 # washes 14.20.55 # * Bagder goes and learns to type 14.21.14 # glrgogoprlrr 14.21.21 # :) 14.24.22 # Bagder: you should wash the keys u, c and k on LinusN's keyboard because it's theam that don't seem to work. 14.24.46 # :-) 14.25.13 Quit langhaarrocker ("Trillian (http://www.ceruleanstudios.com)") 14.26.26 Join langhaarrocker [0] (~Philipp@B232c.pppool.de) 14.28.32 # luc : Vu que tes congés au Japon se sont transformés en congés sans solde... Tu vas meme peut etre devoir de l'argent a Alcove... 14.28.52 # Oups...Sorry 14.29.02 Join Schnueff [0] (~mah@wjpserver.cs.uni-sb.de) 14.34.22 Nick Zagor is now known as Zagor|away (bjst@as9-5-6.k.s.bonet.se) 14.35.15 *** Saving seen data "./dancer.seen" 14.42.25 Join _Snorlax_ [0] (bluah@h135n1fls34o883.telia.com) 14.47.41 Nick seb-sleep is now known as seb-school (user@bgp420584bgs.union01.nj.comcast.net) 15.12.40 # just finished applying mp3gain to my 70GB of mp3s - really does make a postive difference in reducing having to volume adjust a lot (i'd previously peak-normalized). 15.12.52 # hm converting those charsets codes_{old,new}.png with a perl script would spoil the joy of the non-programmers? 15.13.42 # :-) 15.13.56 # Although I'm only halfway through my current jukebox, think i might refresh anew, since i'm constantly fooling with the jb vol. 15.14.01 # please spoilt that :-) 15.14.02 # yeah, was thinking the same, re: perl script. 15.14.12 # i got one 15.14.33 # (though my charset understanding is nil - you don't learn that stuff when you get a physics degree :) 15.15.14 # kargatron: hey, we'll be happy to feed lots of info to you until you get it ;-) 15.16.11 # kargatron: but mp3gain won't help when playing with Rockbox, will it? 15.16.31 # oh, is the header that's adjusted by mp3gain not read by rockbox? 15.16.37 # no 15.16.52 # oh, thought that it was adjusting a std header 15.16.55 # oh well 15.16.57 # I guess we could make it 15.17.10 # makes a difference while listening at my computer, so still worth it 15.17.23 # it's adding an ID3V2 tag, or a field in the Lame INFO header 15.17.57 # YA feature request :) 15.18.12 # i've been thinking of adding support for that, but i haven't come around to that 15.19.03 # regardless, if you listen at your computer, the effort's worthwhile, imo. i notice it. 15.19.41 # row is high-order nibble in those charset? 15.19.43 # charsets 15.20.30 # yes... or is it LSB first? 15.20.42 # * Bagder checks 15.21.54 # LSB first 15.22.00 # hm 15.22.07 # so 0x14 is A 15.22.12 # sorry 15.22.19 # 0x54 is a 15.22.30 # (in old charset) 15.22.56 # uh, you're talking about that png 15.23.03 # yes 15.24.02 # sorry, 45 is A in the old 15.24.15 # 41 in the new 15.24.19 # ok better, i have it that way atm 15.30.07 Join bobTHC [0] (~bobTHC@AMarseille-206-2-1-9.abo.wanadoo.fr) 15.30.14 # hi all! 15.30.46 # yo 15.32.11 Join YeAhx [0] (~aarond@66.81.88.2) 15.32.17 Quit langhaarrocker (Read error: 110 (Connection timed out)) 15.32.21 # i recieve a mail with "eol formats were problematic", what the deal with *.lang end of line ? 15.32.48 # bobTHC: what about them? 15.32.52 # there were problems if the last line didn't have EOL 15.33.05 # ok... 15.33.10 # fixed now 15.33.11 # new builds are released even with no changes? is it automated? 15.33.15 # in the bdf font, yes 15.33.35 # YeAhx: the daily builds are fully automated, yes 15.34.08 # we rebuild every 20 minutes, if a file has changed 15.34.28 # nice 15.34.44 # Im loving the lack of delay between tracks 15.35.11 # YeAhx: took some effotr to remove it 15.35.13 # effort 15.35.56 # my old rio wasnt bad but I dont think I notice any at all on my archos with rockbox 15.36.10 # that only affects tracks that were contiguous but separated? 15.36.21 # or Lame encoded 15.36.35 # or does it shorten gaps between random mp3s? 15.36.52 # kargatron: it removed all non-mp3 info 15.36.53 # (say if lame encoded...) 15.36.59 # removes 15.37.33 # oh its better with LAME encoded? 15.37.55 # no wonder, thats my main encoder how 15.37.56 # now 15.38.20 # i read somewhere that LAME does a better job somehow regarding the gap between tracks 15.38.40 # lame man page documents a --nogap option 15.38.47 # but i think that has to be specially enabled 15.39.08 # so does ogg 15.39.09 # (and it worx on a sets of contiguous .wave files, i presume) 15.40.00 # i guess that it encodes the two files as they were one WAV file, keeping the bit reservior filled in between 15.40.04 # ogg vorbis files are the only type I have got to play with no gaps on my computer 15.40.20 # yes, and if takes sample from the next file to fill mp3 frames, i guess 15.40.24 # s/if/it 15.43.23 Join pimlottc [0] (~pimlottc@a1-1b012.neo.rr.com) 15.45.04 # still, I dont think they playback as well on my computer as they do on the archos with rockbox 15.45.39 # you don't need to suck up to us. we'll be nice to you anyway :-) 15.46.34 # any recommendations for a program to keep sync between hd and archos under linux? 15.46.52 # hm 15.47.23 # pimlottc: I wrote a little perl script that works for me 15.47.34 # updates my archos according to my local dir changes 15.47.43 # bidirectional is more difficult 15.47.47 # Bagder - mind sending a copy? 15.47.55 # http://daniel.haxx.se/stuff/mp3sync 15.48.00 # schnueff - actually unidirection I think is all that I need 15.48.06 # ok 15.48.11 # Bagder - danke. 15.48.27 # I have been trying to use rsync but it seems to be copied a lot more than is necessary 15.48.35 Quit _Snorlax_ ("gittar ny!") 15.48.37 # stupid question - do people talking of 'syncing' their jb have collections that are <= 20GB? 15.48.51 # kargatron - myself, yes 15.49.10 # ok 15.49.11 # rsync usually pays attention on the file date 15.49.30 # was just trying to figure out what synching would mean with collection >> jb 15.49.33 # maybe one has to use --modify-window option to account for the low time resolution on vfat 15.49.56 # Schneuff - it still sems to copy too much with the --size-only option 15.50.12 # hm 15.50.23 # and u set --whole-file too? 15.50.39 # I've also been thinking about what could be done in rockbox to aid the syncing process 15.50.50 # (i'm aware there is no control when usb is plugged in) 15.51.17 # hm strange 15.53.12 # although I admit I haven't come up with much 15.54.34 # I didn't set --whole-file, I thought that only affect the how it copied 15.54.52 # its just to make sure that rsync doesnt try to compute checksums on archos 15.54.59 # (for partially transmitted files and such) 15.55.31 # yes, it only applies after size/time check 15.55.34 Quit YeAhx (Read error: 104 (Connection reset by peer)) 15.56.08 Join YeAhx [0] (~aarond@66.81.88.2) 15.56.12 # I have not set it to use checksums at all 15.56.21 # time to go home, bye all! 15.56.21 # since it'd just have to slurp the whole file over USB 15.56.45 Part LinusN 15.56.57 # pimlottc: i thought that what the -W (--whole-file) switch was for 15.58.09 # schneuff - for what, turning off checksum? 15.58.12 # yes 15.58.46 # as far as I see it doesn't use checksusm unless you specify --checksum 15.59.04 # and the runtime seems to agree 15.59.12 # hm default is to use checksums, i'm quite sure on that 15.59.26 # --checksum says: use checksum even if dates are the same and size matches 15.59.53 # but, as u use --size-only, it shouldnt make much of a difference anyway 15.59.53 Join YeAhx1 [0] (~aarond@66.81.88.2) 16.00.05 # hmm good point looks like you're right 16.00.42 # http://slashdot.org/comments.pl?sid=40423&threshold=1&commentsort=0&tid=100&mode=flat&cid=4306201 16.00.50 # I just know when I do --dry-run it gives results much faster than if it's checksumming everything 16.00.54 # (but maybe u often do tag updates are such things? then it would surely make a difference) 16.01.00 # s/are/and/ 16.02.07 # " The iPod provides no gap suppression, so that in between every track there is a noticeable gap of about 1/2 second (or up to five seconds if the hard disk decides to spin up at the same time.) " 16.02.37 # shocking 16.02.40 # indeed 16.02.51 Join datazone [0] ([p5zkfbdmr@207.136.36.203) 16.03.08 # schnueff - not really, once a file is in the collection it is not likely to be changed (perhaps rarely). I have a staging area for incoming files where I fix all that :) 16.03.09 # " It is incapable of playing music while reading from the hard disk" 16.03.34 # hahaha 16.03.43 # ipod surely seems a bit "limited" in its software 16.03.53 # "So if you have a file that is longer than 32mb, it will play the first 32mb, then pause for 3-5 seconds while reading the next 32mb chunk into memory. " 16.05.16 # pimlottc: hm ok. maybe give it another try with the -W option, to make sure no checksums are used 16.05.54 Quit mecraw (Read error: 104 (Connection reset by peer)) 16.10.26 # read about how one person uses .cue files to remove these gaps on the PJB (Personal Jukebox) 16.11.28 # isn't .cue files for when you have one big file and want it to work as if it was multiple ones? 16.13.05 # its for burning the TOC when u copy an audio cd. 16.13.10 # but u can abuse it for that purpose 16.13.30 # ok 16.13.54 # and there's a plugin for winamp which supports that (mp3cue) 16.14.29 # did he think I was sucking up? hehe 16.14.32 # nah 16.14.44 # I just love rockbox 16.14.52 # I *think* it was a joke, but you never know with Linus ;-) 16.15.06 # * Bagder is always serious 16.15.11 # sure:) 16.15.23 # * Bagder always ignores mail too B) 16.15.32 # sorry I was disconnected and went away for coffee so this probably makes no sense 16.15.37 Quit YeAhx (Read error: 110 (Connection timed out)) 16.16.09 # this is what Im reffering to 16.16.13 # YeAhx: still, I dont think they playback as well on my computer as they do on the archos with rockbox 16.16.14 # LinusN: you don't need to suck up to us. we'll be nice to you anyway :-) 16.16.47 # dont confuse us now:) 16.29.43 Quit YeAhx1 (Read error: 104 (Connection reset by peer)) 16.30.32 Join YeAhx [0] (~aarond@66.81.88.2) 16.32.11 # how crapola 16.33.03 # woops 16.33.05 # hehe 16.33.13 # what is a TOC file anyway? 16.33.49 # I think there is an invisible one on a CD I just bought 16.33.50 # you mean toc header? 16.34.03 # oh 16.34.21 # * Bagder stands silent in a corner 16.34.23 # one that I cant get iTunes to name for me so I cant encode it which is pissing me off 16.34.38 Join edx [0] (~edx@pD9EAB97D.dip.t-dialin.net) 16.34.43 Quit TotMacher () 16.34.43 # I mean I could encode it but not with my choice of encoder 16.35.17 *** Saving seen data "./dancer.seen" 16.40.12 Join YeAhx1 [0] (~aarond@66.81.88.2) 16.40.18 Part YeAhx1 16.40.22 Join YeAhx1 [0] (~aarond@66.81.88.2) 16.41.16 # sorry I guess I should sign off, this connection just has to drop every few minutes and I dont want it to get anoying 16.42.19 Nick edx is now known as edx|studying (~edx@pD9EAB97D.dip.t-dialin.net) 16.44.54 # hm 17.02.15 # who make the pitch code ? 17.02.34 # Linus 17.03.07 # u think it's possible like the ff/fd config menu to configure steps....? 17.04.05 # because it's to bad to listen to much "click" noise 17.04.38 # of course its possible 17.05.58 # it's would be great.... 17.06.11 Quit YeAhx (Read error: 110 (Connection timed out)) 17.06.36 # in all case, thanx a lot to linus for this so good option! 17.06.54 # gotta run 17.06.56 Part Bagder 17.09.37 # there is pitch code? 17.11.00 # yep 17.12.29 # biatchin 17.12.45 # what ? 17.12.46 # the font thing sounds pretty cool 17.12.53 # pitch mode 17.13.06 # >>>biatchin ?? 17.13.30 # hehe yeah totaly 17.13.40 # whats the meaning of that 17.17.07 # sorry 17.17.07 # roflmao 17.17.07 # nevermind 17.17.17 # it just sounds like a handy feature to have 17.18.17 # funny even 17.20.47 Join YeAhx [0] (~aarond@66.81.88.2) 17.21.22 # I was just laughing at your reactions to my use of that word 17.21.43 # it looked like a typo to me 17.21.46 # :) 17.22.08 # well usualy I would say "bitchin" but I like to alter it every once in a while 17.22.42 # and most people dont even know the meaning of "bitchin" I probably dont either, I just use it as an alternative to "thats cool!" 17.23.46 # and what's roflmao ? 17.24.03 # rolling on the floor laughing my ass off 17.24.30 # ok thx.. 17.25.51 # no prob 17.26.33 # biatch is normally only an alternate of the noun form 17.27.36 # ah ic 17.27.39 # oh well 17.29.03 Part kargatron 17.30.04 # oh finaly found lyrics to a song that didnt come from the same source after looking at several pages that had the same one with the same errors 17.30.19 # and it has the ending yeaaah 17.30.42 # Jimi Hendrix - 1983...(A Merman I Should Turn To Be) 17.35.00 # in case anyone was wondering 17.35.30 # I guess I better leave before I keep babling cyas 17.35.49 Quit YeAhx ("yip") 17.39.18 Quit YeAhx1 (Read error: 110 (Connection timed out)) 18.04.47 Join langhaarrocker [0] (~Philipp@Bdb58.pppool.de) 18.09.14 Nick dw|gone0r is now known as dwihno (dwihno@Bald067.Baldakinen.Umea.SE) 18.09.14 DBUG Enqueued KICK dwihno 18.14.39 Quit pyvasene ("Leaving...") 18.32.20 Quit pimlottc (Read error: 110 (Connection timed out)) 18.35.21 *** Saving seen data "./dancer.seen" 18.52.28 Part bobTHC 18.53.03 Quit langhaarrocker (Read error: 104 (Connection reset by peer)) 19.00.12 Join Phantom [0] (Phantom@ASte-Genev-Bois-109-1-1-104.abo.wanadoo.fr) 19.00.15 # HI ! 19.00.24 # bonsoir 19.00.25 # I ve got a big Bug 19.00.42 # bug bug? 19.01.28 # I09:CPUAdrEr 19.01.38 # at 0F00082A 19.03.44 # oops 19.05.50 Quit Phantom () 20.33.49 Join Phantom [0] (Phantom@ASte-Genev-Bois-109-1-2-136.abo.wanadoo.fr) 20.33.54 # HI 20.34.21 # ? 20.34.27 # nobody ? 20.34.49 # I ve a big bug and nobody to talk about 20.35.15 # HELPPP 20.35.24 *** Saving seen data "./dancer.seen" 20.35.28 Part elinenbe 20.38.35 # HEELP : big fatal error 20.45.27 Quit Phantom () 21.12.19 Nick seb-school is now known as seb-away (user@bgp420584bgs.union01.nj.comcast.net) 21.56.24 Quit DownKaos (Read error: 104 (Connection reset by peer)) 22.05.59 Quit edx|studying () 22.14.44 Nick dwihno is now known as dw|gone0r (dwihno@Bald067.Baldakinen.Umea.SE) 22.14.44 DBUG Enqueued KICK dw|gone0r 22.22.13 Join Ennan [0] (~Doe@CC53164-B.GRONI1.GR.HOME.NL) 22.22.29 # helo 22.26.21 # people here 22.26.21 # ? 22.28.16 Quit Zagor|away ("Client Exiting") 22.29.29 # hmm guess not. 22.30.38 Nick seb-away is now known as _seb_ (user@bgp420584bgs.union01.nj.comcast.net) 22.35.25 *** Saving seen data "./dancer.seen" 22.51.56 Join elinenbe [0] (trilluser@user-0cces0l.cable.mindspring.com) 23.28.07 Nick _seb_ is now known as seb-away (user@bgp420584bgs.union01.nj.comcast.net) 23.35.07 Quit Ennan ("Client Exiting") 23.53.52 Nick seb-away is now known as _seb_ (user@bgp420584bgs.union01.nj.comcast.net) 23.56.10 Join DexterAYS [0] (~xxxx@pD950F49C.dip.t-dialin.net) 23.56.27 # hi dudes, do you already have a german translation?