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:00 |
02:24:37 | | Join Foxinou [0] (~Julien@lns02v-9-177.w.club-internet.fr) |
02:25:04 | Foxinou | 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:00 |
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:00 |
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:00 |
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 |
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 | LinusN | mecraw? |
07:24:21 | LinusN | or mecraw12? |
07:24:38 | Zagor | morning linus |
07:24:47 | LinusN | morning Zagor |
07:25:06 | | Join rwood [0] (~rdwrockbo@ca-santaanahub-cuda3-c9b-117.anhmca.adelphia.net) |
07:25:11 | LinusN | i'm looking into the poweroff patch |
07:25:18 | Zagor | ok |
07:25:30 | LinusN | i don't want it to run on interrupt |
07:25:41 | LinusN | i want it in the power thread |
07:25:45 | Zagor | uh, definitely not |
07:25:50 | Zagor | i haven't read it yet |
07:26:13 | LinusN | BTW, the ATA thread knows about user activity, doesn't it? |
07:26:22 | Zagor | yes. i was thinking about that too. |
07:26:28 | Zagor | ata_spin() |
07:27:01 | LinusN | ah, last_user_activity |
07:27:09 | Zagor | yup |
07:27:35 | LinusN | but that isn't really user activity, only disk-related user activity |
07:27:47 | Zagor | ah, right |
07:28:40 | LinusN | 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 | Zagor | yes, i agree. |
07:29:10 | LinusN | maybe a call from button_irq is still good |
07:29:24 | LinusN | but i want the timekeeping to be done in power_thread |
07:29:40 | rwood | 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 | LinusN | rwood: happens all the time |
07:30:17 | rwood | LinusN: ignore it? |
07:30:21 | LinusN | yup |
07:30:37 | | Join merwin [0] (~none@12.242.185.10) |
07:30:42 | merwin | yO |
07:30:59 | LinusN | yo d00d! |
07:31:22 | merwin | linus! |
07:31:34 | * | merwin hasn't been very involved lately |
07:31:53 | rwood | 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 | LinusN | :-) |
07:32:07 | LinusN | don't worry |
07:32:29 | rwood | LinusN: is there anything on i2c for recording that would be interesting? |
07:32:34 | LinusN | do you still have your recorder on the operating table? |
07:32:41 | merwin | LinusN: is recording being dev'd yet? |
07:32:51 | rwood | LinusN: yes - for the forseeable future |
07:33:12 | LinusN | rwood: but no way of measuring things right now? |
07:33:43 | LinusN | merwin: yes |
07:34:04 | rwood | LinusN: measuring what? |
07:37:08 | LinusN | i would like to measure EOD, PR and RTW when recording, maybe along with PA15, PB14 and PB15 |
07:37:30 | LinusN | the timing info in the data sheets doesn't satisfy me |
07:39:29 | rwood | 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 | LinusN | rwood: ok, no need then. thanks anyway |
07:41:10 | LinusN | merwin: we are addressing that problem |
07:42:16 | merwin | LinusN: how so? |
07:44:23 | LinusN | we will have scripts to keep track of the translation files, much like the coloured build table |
07:45:05 | LinusN | a red square for every untranslated string and so on |
07:45:38 | LinusN | and we will hopefully have maintainers for the languages |
07:45:42 | merwin | LinusN: ahh... now that is a good idea :-) |
07:46:05 | LinusN | 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 | LinusN | a friend of mine dropped his cell phone from his shirt pocket into his own coffee cup :-) |
07:49:51 | LinusN | instant phone death |
07:50:22 | merwin | hehe |
07:50:29 | LinusN | berr-safe phones, eh? |
07:50:31 | LinusN | beer |
07:50:57 | LinusN | never saw that in the advertising |
07:51:13 | merwin | 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 | merwin | this thing is like a rock |
07:51:30 | merwin | I have a newfound respect for ericsson |
07:52:04 | LinusN | every phone should be designed for keg stands |
07:52:10 | LinusN | common daily use |
07:52:27 | rwood | merwin: send them the story - next thing you know, you'll be a TV star |
07:52:51 | merwin | rwood: hehe |
07:52:55 | merwin | LinusN: damn straight :-) |
07:53:24 | LinusN | straight? rather upside down :-) |
07:54:25 | merwin | 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:00 |
08:12:22 | merwin | f |
08:12:30 | merwin | ack |
08:16:30 | | Join Bagder [0] (~daniel@as3-3-2.ras.s.bonet.se) |
08:16:42 | Bagder | hey ho |
08:16:52 | Zagor | yo |
08:21:39 | Bagder | only 300 mails to read ;-) |
08:24:11 | rwood | 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 | rwood | Zagor: read turns the led off after wait_for_end_of_transfer write does it before - any reason? |
08:25:10 | Zagor | no, looks like an error |
08:25:30 | rwood | Zagor: do you want me to send a patch file? |
08:25:39 | Zagor | nah, i'll fix it here |
08:26:43 | rwood | 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 | merwin | rwood: good idea |
08:27:54 | Zagor | how do you mean? |
08:28:16 | LinusN | aha, a shutdown() |
08:28:25 | rwood | exactly |
08:28:38 | LinusN | i like it |
08:28:41 | Zagor | aha |
08:29:05 | Zagor | well, we are desperately short on keys on the players... |
08:29:10 | rwood | i'd trade mute for shutdown |
08:29:32 | rwood | but then i never use mute |
08:29:47 | merwin | rwood: I wouldn't turn menu+off into poweroff :) |
08:29:59 | merwin | how about holding menu+on for 2 seconds? |
08:30:26 | rwood | maybe 1 second |
08:30:56 | rwood | i'm usually in a hurry getting out of the car when i shutdown |
08:30:57 | merwin | 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 | merwin | rwood: configurable! |
08:31:31 | rwood | i'll take 2 seconds - another config item would be too much |
08:31:37 | LinusN | rwood: agreed |
08:31:54 | merwin | rwood: 2 seconds is shorter than you think |
08:32:13 | merwin | rwood: just think... buy a turbo car and have to wait 60 seconds just to turn it off :-) |
08:33:08 | Zagor | rwood: do you leave the archos in your car or take it with you? |
08:33:41 | rwood | Zagor: leave it in the car - heat probably isn't good for batteries |
08:34:59 | rwood | 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 | merwin | hehe... a finger point reader? how do you have someone else start your car? |
08:35:47 | merwin | r/point/print |
08:36:02 | rwood | recognizes 4 finger prints & key still works |
08:36:31 | Zagor | 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 | merwin | 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 | rwood | 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 | PsycoXul | i dunno |
08:38:15 | Bagder | uh, rockbox feaure mail spammed :-) |
08:38:15 | Zagor | 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 | PsycoXul | if they're not willing to beat/shoot you for your key's |
08:38:22 | PsycoXul | they're probably not willing to start chopping |
08:38:28 | Zagor | Bagder: yeah, I updated a whole bunch |
08:38:31 | Bagder | hehe |
08:38:43 | Zagor | s/Audio/Audi/ |
08:38:55 | merwin | Zagor: wow, I don't know if I like that either :) |
08:39:56 | rwood | 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 | Hes | Good morning. |
08:40:15 | Bagder | morning hes |
08:40:19 | Hes | How's world? |
08:40:31 | * | merwin is going to bed |
08:40:39 | merwin | ttyl |
08:40:46 | | Quit merwin () |
08:41:14 | LinusN | Hes: world is fine |
08:42:53 | Hes | played some music using rockbox at a wedding on saturday night... after our band's gig |
08:43:17 | rwood | 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 | Hes | recorded the gig on minidisc though 8-) |
08:43:31 | LinusN | 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 | Hes | Oh, it does? |
08:43:58 | Hes | That's a bug. It should sleep less. |
08:43:58 | LinusN | sleep(HZ*POWER_AVG_SLEEP); |
08:44:13 | Zagor | 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 | LinusN | POWER_AVG_SLEEP is 10 |
08:44:36 | Hes | Ok, that is correct |
08:44:49 | Hes | /* sleep for roughly a minute */ |
08:44:49 | Hes | sleep(HZ*(60 - POWER_AVG_N * POWER_AVG_SLEEP)); |
08:45:01 | LinusN | ah, ok. I am blind |
08:45:07 | Hes | It sleeps for 20 seconds in the end. The comment is old. |
08:45:14 | Hes | Sorry for my bad comments again 8-) |
08:45:34 | Hes | Looking at doing improvements there? |
08:45:36 | LinusN | sorry for my bad eyesight :-) |
08:45:52 | LinusN | Hes: i am looking into putting the auto-poweroff there |
08:46:00 | Hes | That'd make sense. |
08:46:29 | Hes | Probably enough to run the auto-poweroff once per minute. |
08:46:35 | LinusN | absolutely |
08:46:48 | Hes | And only if charger is not plugged in. |
08:46:58 | LinusN | yup |
08:47:08 | Zagor | 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 | rwood | Zagor: good idea - i'll start working on it |
08:47:19 | LinusN | mecraw has an idea of a sleep timer that shuts off regardless, after a longer timeout |
08:47:27 | Bagder | Zagor: yes, the player sim would need both files |
08:48:04 | Bagder | Zagor: or possibly only the recorder one, with some stubs for the player functions redirected to the recorder versions |
08:48:56 | Hes | LinusN: and restart charging with the archos charger then? |
08:49:12 | rwood | 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 | LinusN | Hes: hehe, i didn't think of that |
08:49:32 | Zagor | rwood: a small delay is probably good |
08:49:50 | rwood | Zagor: i agree - let others have a turn |
08:50:17 | LinusN | Hes: i guess it should never shut off when the charger is attached... :-) |
08:50:29 | Hes | LinusN: nope, since it will auto-poweron anyway. |
08:51:09 | LinusN | and we don't want the users to use the steenkin' Archos charger, do we? |
08:51:10 | Hes | The little beast powers on if you plug anything in the DC input even if there's no electricity involved. 8-) |
08:51:19 | Hes | an unpowered charger is fine |
08:51:30 | Hes | LinusN: Nope, if they don't actually want to |
08:51:38 | Hes | it's a Good Thing to be able to choose |
08:57:31 | | Join langhaarrocker [0] (~Philipp@B2562.pppool.de) |
08:59:57 | linuxstb | Good morning. Has anyone looked at my cuefile patch I sent to the mailing list last night? |
09:00 |
09:00:18 | Hes | 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 | Bagder | I vote for us starting to use the "patch tracker" on sf |
09:00:52 | LinusN | i agree |
09:02:30 | langhaarrocker | Does that mean patchers need a sf login? |
09:02:30 | Schnueff | moin |
09:03:09 | langhaarrocker | moin. Must go unfortunately. Have some stupid lessons at some stupid school. |
09:03:55 | linuxstb | 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 | Bagder | langhaarrocker: no, it would mainly mean that patches would be posted to a better system/queue |
09:05:24 | Zagor | 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 | Schnueff | 1 |
09:06:06 | Schnueff | :) |
09:06:06 | Zagor | i consider playlists more closely linked than cue files. and playlist handling is in apps. |
09:06:19 | linuxstb | But cuefiles provide the same information as that contained read by id3.c - track titles and running times. |
09:06:46 | Schnueff | yes |
09:07:00 | linuxstb | 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 | Schnueff | a .cue for this purpose is more like a .m3u |
09:07:41 | Zagor | afaik cue files provide track names, not track titles? |
09:07:51 | Zagor | Schnueff: my point exactly |
09:07:54 | Schnueff | so people can click on the .cue later to start playing the associated playlist |
09:08:06 | Schnueff | "associated playlist" wrong term |
09:08:39 | linuxstb | 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 | Zagor | an mp3 file does not contain a cue file. a cue file references an mp3 file. |
09:09:17 | linuxstb | Zagor: that's true. |
09:09:40 | linuxstb | So should the cue file be ignored if the user just plays the mp3 file? |
09:09:46 | Zagor | yes |
09:10:03 | Zagor | .cue should be treated as .m3u |
09:10:04 | Schnueff | i think so too |
09:10:09 | linuxstb | And should cue files be allowed inside .m3u files? |
09:10:12 | Zagor | no |
09:10:21 | LinusN | i don't get it |
09:10:30 | LinusN | what feature does cuefiles add? |
09:10:33 | Schnueff | one could make some new filetype for that |
09:10:47 | Schnueff | LinusN: u can play whole-cd-rips trackwise |
09:10:51 | Schnueff | whole-cd-rip-as-one-mp3 |
09:10:59 | LinusN | and a playlist can not? |
09:11:11 | Zagor | gaps |
09:11:22 | LinusN | what gaps? |
09:11:26 | Zagor | between tracks |
09:11:28 | linuxstb | 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 | Zagor | between files, i mean |
09:11:41 | LinusN | aha, an entire mp3 file wor the whole disk? |
09:11:44 | LinusN | for |
09:11:46 | Zagor | yes |
09:11:50 | LinusN | ic |
09:12:22 | Schnueff | if u have it as one single mp3, a playlist is insufficient |
09:12:22 | Schnueff | (unless we extend it with time offsets for each track) |
09:12:22 | Schnueff | (time offset + length) |
09:12:55 | * | LinusN fills his coffee cup |
09:14:09 | Schnueff | doing this with .cue files is a hack, in my opinion, but winamp has a plugin to support this |
09:14:29 | Schnueff | (although i dont use winamp, so i could not try :) |
09:14:45 | Zagor | i think cue file support is cool, but I want it handled like any other playlist |
09:15:13 | PsycoXul | can playlists reference playlists? |
09:15:23 | Schnueff | hm |
09:15:33 | Zagor | <Code Police>structs should not be called *_t. only types are _t </Code Police> |
09:15:39 | linuxstb | 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 | Zagor | PsycoXul: no |
09:15:43 | PsycoXul | why not? |
09:15:47 | linuxstb | Zagor: OK. I'll change that. |
09:16:08 | linuxstb | Zagor: I am aware I waste RAM - I'm also going to work on that. |
09:16:12 | Zagor | 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 | Schnueff | i guess one can start with .cue file and then make something better |
09:16:25 | Schnueff | combined .cue files / playlists |
09:17:18 | linuxstb | 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 | PsycoXul | 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 | LinusN | amen |
09:18:20 | Zagor | linuxstb: that means we require all mp3 with cue files to have id3v2 'cue' tags |
09:18:47 | PsycoXul | there's id3v2 'cue' tags? |
09:18:51 | linuxstb | 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 | Zagor | linuxstb: ok |
09:19:03 | PsycoXul | heh |
09:19:09 | Schnueff | there's something like marking specific times in the track |
09:19:29 | Schnueff | but i guess it's not meant for trakc times |
09:19:47 | LinusN | can you guys reach www.id3.org? |
09:19:59 | Schnueff | no, but i got it in my wwwoffle |
09:20:02 | LinusN | or has it moved? |
09:20:02 | Schnueff | :) |
09:20:11 | Zagor | LinusN: i can't reach it |
09:20:12 | Schnueff | dunno exactly, had problem too in the past weeks |
09:20:16 | Schnueff | _weeks_ |
09:20:32 | LinusN | RIAA has shut it down :-) |
09:21:15 | webmind | fuck riaa |
09:21:16 | Zagor | linuxstb: also, you can't cut down MAX_ID3_TAGS to four. it's too low. |
09:22:04 | linuxstb | 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 | LinusN | 8K!!!!! |
09:22:45 | Zagor | linuxstb: optimise more. keep a list of positions instead of the whole file in ram |
09:22:46 | linuxstb | LinusN: Is that good or bad? |
09:22:53 | LinusN | bad |
09:23:10 | linuxstb | But it needs to know that track and title names of up to 99 tracks. |
09:23:14 | LinusN | what us taking 8K? |
09:23:23 | LinusN | aha |
09:23:30 | LinusN | 99 tracks? |
09:23:30 | Schnueff | if one got it merged with playlist, it should take less mem |
09:23:31 | Zagor | linuxstb: that can be read when needed. we don't need it in ram all the time. |
09:23:33 | linuxstb | I'll repeat that. Track title and track performer for 99 tracks. |
09:24:10 | LinusN | how common is 99 tracks? |
09:24:12 | Zagor | 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 | linuxstb | OK. I agree that the memory usage can go down a lot. This will be my next priority. |
09:24:38 | LinusN | Zagor: technically it still needs to be MAX_PATH |
09:24:56 | LinusN | it *may* reside in the root, and be 260 bytes long |
09:24:57 | Zagor | LinusN: doh, right |
09:25:06 | Hes | 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 | Hes | you could do the same, store offsets to the track information in the cuefile and read it when you need it |
09:25:46 | LinusN | the behaviour could ne the same |
09:25:51 | linuxstb | I will need to buffer MAX_ID3_TAGS number of track titles in RAM from my cue file. |
09:26:15 | linuxstb | Hes: That is what my current implementation does - but it buffers the whole cuefile in RAM. |
09:26:51 | LinusN | so using the playlist approach could be the solution? |
09:27:13 | linuxstb | 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 | Hes | could support Huge cue files. |
09:27:17 | LinusN | and if done cool enough, you can use the ordinary shuffle as well! :-) |
09:27:49 | linuxstb | But maybe I am on my own with that. |
09:27:58 | Zagor | 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 | Zagor | linuxstb: i think that's a cool thing |
09:28:49 | linuxstb | Zagor: No, only in a directory, and then next/prev works between files with and without cuefiles. |
09:29:41 | Zagor | ok. the only thing i'm against, really, is the introduction of application data in the id3 struct |
09:30:08 | Zagor | since cue files are handled in wps.c, it *is* application data... |
09:30:38 | linuxstb | Do any files in the firmware directory use the id3 data? |
09:31:26 | Zagor | mpeg.c |
09:32:10 | linuxstb | And cuefiles contain the same information as id3 tags... |
09:32:44 | Schnueff | hm |
09:32:54 | Zagor | 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 | Schnueff | cue files are for makeing the toc on a cd. |
09:33:07 | Schnueff | they won't contain all id3 files |
09:33:11 | Schnueff | eh tags |
09:33:14 | Zagor | with cue files, it's so much more complicated. we need to simplify it. |
09:33:29 | Schnueff | what about supporting time tags on each mp3 |
09:33:50 | Schnueff | like file.mp3[:30.12-2:30.0] or such thing |
09:34:09 | linuxstb | 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 | Zagor | nah, lets not invent new "standards" :-) |
09:34:11 | Schnueff | (cdparanoia-like syntax) |
09:34:23 | linuxstb | All the complicated work will be the memory management done by cuefile.c |
09:34:32 | Zagor | linuxstb: yes, the code is simple. but the design gets muddled. |
09:34:33 | Schnueff | 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 | Schnueff | and one could play a track from one big-mp3 and then from another big mp3 by using extended playlists |
09:35:59 | linuxstb | Schneuff - I personally don't use cue files, but they seem to be the only available "standard" for the job. |
09:36:06 | Schnueff | i agree, new standard are not desired. but cue files are not really meant for such thing |
09:36:13 | Schnueff | linuxstb: yes, i am aware of that |
09:36:30 | linuxstb | But people use them (e.g. mp3cue for winamp). |
09:36:45 | Schnueff | yes, it would be good to support them |
09:36:59 | Schnueff | but it could be easier, by allow playlist entries to have a start time and a length |
09:37:17 | linuxstb | There is no harm in allowing that. |
09:37:28 | linuxstb | ... but how would you name the track? |
09:37:35 | Schnueff | and then u could load a .cue by constructing such a playlist |
09:38:02 | Schnueff | linuxstb: hm yes good point |
09:38:03 | Zagor | Schnueff: people don't want to change their data. they simply want us to support it. |
09:38:12 | Schnueff | although extended m3u support such things |
09:38:30 | Schnueff | (for example for playing a http mp3 stream, u can't tell the name of the stream from the url) |
09:38:43 | Schnueff | (but u can still have it in an m3u) |
09:38:47 | Zagor | linuxstb: you could check for (and read) cue file in wps.c:441 |
09:38:53 | linuxstb | In my mind this is also linked to the eventual "editting of mp3 recordings" that people will be asking for. |
09:39:00 | Schnueff | yes |
09:39:13 | linuxstb | i.e. 1) Create a cuefile on the rockbox 2) (optionally) split the mp3 file according to cue file. |
09:39:40 | Schnueff | linuxstb: how do the .cue files support having 'tags' in them exactly? |
09:40:04 | linuxstb | Look at the comments at the start of the cuefile.c that I posted to the mailing list... |
09:40:07 | LinusN | it would be cool to be able to insert queue points while recordding, just press a key for "add queue point" |
09:40:15 | Schnueff | yes |
09:40:18 | Zagor | hmm, no that would mean spinning the disk again.. |
09:40:27 | Zagor | (my wps.c:441 idea) |
09:40:29 | LinusN | Zagor: why? |
09:40:32 | LinusN | aha |
09:40:33 | Schnueff | ah |
09:40:46 | Schnueff | linuxstb: will have a look |
09:41:45 | Zagor | 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 | Zagor | mp3entry |
09:42:06 | Schnueff | hm, but such things are supported by id3v2.4 |
09:42:26 | linuxstb | My view is that id3.c should be moved to apps. |
09:42:32 | Zagor | that's not the issue. id3.h is the issue. |
09:42:48 | Zagor | linuxstb: maybe. but then we get sticky issues with mpeg.c instead |
09:43:16 | linuxstb | 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 | Schnueff | linuxstb: i guess these tags are the things the cd-text support (the track-name-thing for cd players) |
09:45:09 | linuxstb | mpeg.c calls the mp3info function, and it is at this time that the cuefile information is also needed. |
09:45:22 | Schnueff | 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 | linuxstb | Zagor: Re: line 441 of wps - I think that may work. |
09:47:37 | Zagor | how about this: we add an apps callback, "read_app_data()" or something, that mp3info calls for each new file. |
09:47:50 | Zagor | linuxstb: no, that would spin up the disk on every track change |
09:47:57 | Zagor | even if mpeg data is already cached |
09:48:07 | linuxstb | True. I'll catch up soon.... |
09:48:11 | Bagder | I think a callback sounds fine |
09:48:38 | Zagor | but how will the app know when the data is no longer needed? |
09:48:56 | Zagor | free_app_data() :-) |
09:49:04 | mecraw | morning, all |
09:49:09 | Zagor | hi mecraw |
09:49:49 | LinusN | mecraw: hi! I am applying your patch, with modifications |
09:50:12 | mecraw | howdy |
09:50:12 | Schnueff | maybe the app should handle at least two data sets |
09:50:12 | mecraw | did i see some auto-poweroff comments earlier? |
09:50:12 | Schnueff | so it can be called for the current and next song, when disk is spinning |
09:50:23 | Zagor | 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 | LinusN | i'm letting the power management thread handle the timeout |
09:50:31 | mecraw | LinusN: cool |
09:50:49 | LinusN | i can't see why the sleep timer is in global_settings? |
09:51:15 | mecraw | LinusN: i wasn't exactly sure where to put it, i figured i'd let the Swedish triumvirate decide :) |
09:51:43 | LinusN | i'm leaving the sleep timer out for now |
09:52:20 | LinusN | i'm not sure how we want to handle that in the best way |
09:52:51 | LinusN | 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 | LinusN | mecraw: who would want an auto-poweroff less than 1 minute? |
09:57:56 | Bagder | "202 messages saved and deleted" the weekend's share of rockbox mail ;-) |
09:58:37 | Bagder | LinusN: I could very well imagine having it set to less |
09:58:53 | LinusN | ugh |
09:59:08 | Bagder | 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 | LinusN | the power management thread has a resolution of 1 minute :-( |
09:59:29 | Bagder | how long is the stock archos timeout? |
09:59:36 | LinusN | 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 | Zagor | i think 1 minute resolution is ok |
09:59:52 | Bagder | LinusN: ... I would *never* set it less than one minute, didn't I tell you that? B-] |
10:00 |
10:00:13 | LinusN | ok, so 1 minute resolution can be OK? |
10:00:22 | * | Bagder erases the log too |
10:00:50 | Bagder | let's use that for now and wait for the crowds to complain |
10:00:54 | Zagor | LinusN: yes |
10:00:57 | LinusN | ok |
10:01:49 | LinusN | 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 | mecraw | sleep timeout of less than 5 minutes is probably useless (except for my testing) :) |
10:02:01 | Zagor | plain integer is ok |
10:02:18 | Schnueff | 0 for never |
10:02:35 | LinusN | mecraw: how would a user want the sleep timeout to work? |
10:02:42 | Hes | And we can change the power thread a little to allow for a shorter timeout. |
10:02:50 | LinusN | Hes: true |
10:02:56 | linuxstb | 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 | mecraw | LinusN: "shut off in 10 minutes no matter what" |
10:03:18 | Hes | 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 | Zagor | linuxstb: it's ok, but I won't commit it. i want to solve the design issue first. |
10:03:39 | LinusN | would anyone want a longer autopoweroff than, lets say 10 minutes? |
10:03:50 | Zagor | LinusN: probably :-) |
10:03:53 | Bagder | LinusN: I doubt it, then they disable it |
10:03:53 | LinusN | haha |
10:04:09 | LinusN | so a 4-bit field would ne enough? |
10:04:12 | LinusN | be |
10:04:13 | linuxstb | Zagor: Do you still want cuefiles to act like playlists? i.e. the user plays the cue file? |
10:04:26 | Bagder | LinusN: I think so, yes |
10:04:32 | Zagor | linuxstb: no, i agree with you that auto-finding the cue file is a good feature |
10:05:15 | mecraw | 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 | linuxstb | So is "apps or firmware" the only outstanding issue (apart from RAM) ? |
10:06:25 | mecraw | LinusN: people will want sleep poweroff times of longer than 10 minutes... maybe not for idle poweroff though |
10:06:50 | Zagor | 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 | LinusN | mecraw: is it intentional to not save the sleep poweroff timer? |
10:08:40 | linuxstb | Zagor: Sorry. but I'm not sure I see the difference. |
10:09:06 | mecraw | LinusN: the sleep poweroff should only be used for one use |
10:09:30 | | Part LinusN |
10:09:51 | Zagor | linuxstb: I don't like id3.c doing cuefile work. i much prefer a generic callback. |
10:11:14 | linuxstb | Zagor: I understand that point - that's what I meant about putting cuefile stuff in "apps". |
10:12:16 | Zagor | 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 | Schnueff | cue file support with vbr is not very accurate, right? |
10:13:52 | LinusN | nope |
10:14:01 | Schnueff | wrong? hm |
10:14:01 | Zagor | Schnueff: not 100%, but shouldn't be too bad either |
10:14:03 | LinusN | only in 1% steps |
10:14:32 | Schnueff | iirc, the bitrate was averaged or such thing. but with long rips, the bitrate should vary a great deal |
10:14:37 | LinusN | so in a 100 minute MP3 it would be in 1 minute resolution |
10:14:57 | LinusN | if we use the standard VBR headers |
10:15:09 | Zagor | 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 | Schnueff | hm, for ripping whole cds with cue file (which is the standard application) thats way to bad |
10:15:25 | Zagor | like we do for ffwd/rew |
10:16:32 | linuxstb | 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 | LinusN | Zagor: i stand corrected |
10:16:56 | Zagor | bpt includes that byte, doesn't it? |
10:17:02 | Zagor | bpf, i mean |
10:17:10 | linuxstb | Sorry, what's bpf? |
10:17:16 | LinusN | bytes per frame |
10:17:46 | linuxstb | 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 | LinusN | very few files use the padding bit, what i know |
10:18:39 | LinusN | maybe internet radion streams |
10:18:57 | linuxstb | 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 | LinusN | but i doubt it |
10:19:05 | linuxstb | My examples are digital satellite broadcasts. |
10:19:25 | linuxstb | But I agree - it is very rare. |
10:19:32 | mecraw | LinusN: did you see my response to your sleep timer question? |
10:20:04 | linuxstb | See you later. |
10:20:05 | | Quit linuxstb ("using sirc version 2.211+KSIRC/1.0") |
10:20:14 | LinusN | mecraw: no |
10:20:46 | mecraw | sleep is only used for one use, so there is no need to save it |
10:21:12 | LinusN | Zagor: FYI, the padding bit can't be included in bpf, since it is different for each frame |
10:21:21 | LinusN | mecraw: i know |
10:21:44 | Schnueff | mecraw: people could get tired of adjusting it to their needs (and then they sleep without timer :) |
10:21:50 | Zagor | fun fun fun on the autobahn... |
10:21:51 | LinusN | but the user is expecting the settings to be persistent |
10:22:13 | Zagor | LinusN, mecraw: you are discussing different things. idle poweroff and sleep are two separate functions. |
10:22:14 | Bagder | yes, they might like to use the same sleep timer every time |
10:22:20 | LinusN | i'd rather have a sleep setting, and a "go to sleep" button of some kind |
10:22:57 | Zagor | LinusN: most devices activate the sleep function anew every time. toggling off, 15, 30, 60, 90 minutes or some such. |
10:23:22 | Bagder | Zagor: it could still default to the previous selected time |
10:23:26 | mecraw | that's how my tv works, i have to set it every time |
10:24:03 | Zagor | Bagder: it could, but I don't quite see the point. i say we follow how other devices work. |
10:24:12 | mecraw | the default would be cool, but i didn't want to take up more space in rtc than was necessary |
10:24:13 | Bagder | sure, that's not a big thing |
10:24:27 | Zagor | especially if we only have like 4 different times |
10:24:51 | | Join pyvasene [0] (~pyvasene@ns1.alcove-solutions.com) |
10:24:56 | mecraw | so, the 22 times are too much :) |
10:25:20 | Zagor | hehe, yeah i'd say so :-) |
10:25:54 | LinusN | i'm only implementing the auto-poweroff for now |
10:26:08 | mecraw | for now the really long timeouts will be useful since we can't turn repeat off |
10:29:18 | Zagor | 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 | Bagder | Zagor: increase the pitch! ;-) |
10:30:15 | LinusN | is anybody working on the repeat option? |
10:30:16 | mecraw | LinusN: are you going to implement the idle poweroff so it powers off when paused? |
10:30:28 | LinusN | do we want that? |
10:30:45 | Zagor | i think we do |
10:30:46 | mecraw | LinusN: quelsaruk is looking into the repeat stuff |
10:30:57 | mecraw | i think so too |
10:31:15 | LinusN | ok |
10:31:50 | LinusN | i'm setting it to 0..15 minutes, 0 being OFF |
10:32:14 | LinusN | or is 10 enough? |
10:32:14 | Zagor | do we need to limit it so much? waste a byte, to avoid complaints |
10:32:30 | mecraw | 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 | Zagor | mecraw: min idle off is not 1 minute :-) |
10:33:16 | LinusN | i need to implement a set_int with a special case for the 0 value... |
10:33:54 | Zagor | LinusN: use set_option then |
10:34:08 | LinusN | that's why i want to limit the max |
10:34:24 | LinusN | or it would be a HUGE array of options |
10:35:04 | Zagor | 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 | LinusN | hence my question before |
10:35:38 | mecraw | why not let it be less than 1 minute? |
10:35:44 | Zagor | i know. i wasn't thinking |
10:35:48 | LinusN | 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 | LinusN | that was my question |
10:36:41 | Zagor | mecraw: because the power thread only wakes up once/minute |
10:36:51 | mecraw | ah |
10:36:54 | LinusN | in the current solution, it can be changed |
10:37:15 | Zagor | i don't quite see the need for <1min shutoff, though |
10:37:30 | LinusN | me neither |
10:37:30 | Zagor | mecraw will simply have to learn to shut off properly :-) |
10:37:42 | mecraw | LinusN: why not do the sleep part too? isn't it a heavily requested feature? |
10:37:50 | LinusN | the "clean" shutdoen idea is good, btw |
10:37:52 | mecraw | Zagor: :p |
10:38:09 | LinusN | i'm not sure i like the UI approach |
10:38:16 | Bagder | it is very frequently requested indeed |
10:38:30 | Zagor | LinusN: how is the approach? |
10:38:32 | LinusN | is it ok to have that in the settings, non-persistent? |
10:38:42 | Zagor | sleep? yes. |
10:38:48 | LinusN | ok, then |
10:38:53 | mecraw | 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 | mecraw | :) |
10:39:18 | Zagor | hmm, wait. do we have anything else non-persistent in settings? |
10:39:23 | Bagder | I think the sleep-timer doesn't have to be considered a setting |
10:39:32 | Bagder | it could be a "function" in a menu |
10:39:45 | Zagor | Bagder: exactly what I was thinking :) |
10:40:10 | LinusN | that's why i wanted to wait with the implementation and discuss it first |
10:41:30 | Zagor | commit idle-off first |
10:42:03 | | Nick TotMacher is now known as tot|away (tot@pD9520171.dip.t-dialin.net) |
10:42:52 | Bagder | 8 languages in cvs now, pretty cool |
10:45:31 | LinusN | 0,1,2,3,4,5,6,7,8,9,10,15,30,45,60 |
10:45:38 | LinusN | is that OK for the poweroff? |
10:46:23 | Zagor | yup |
10:46:57 | mecraw | i want 83 minutes! |
10:46:59 | * | mecraw hides |
10:47:04 | Schnueff | heh |
10:47:22 | * | Bagder swings |
10:47:24 | Bagder | ;-) |
10:48:04 | * | mecraw falls over... due to intoxication and the wind from Bagder's miss |
10:53:54 | mecraw | good night from the Rockies... can't wait to build from CVS in the morning! |
10:54:09 | Bagder | night mecraw |
11:00 |
11:03:17 | | Quit pyvasene ("Leaving...") |
11:03:20 | | Join TotMacher [0] (tot@ip67.rsidus.riege.de) |
11:04:19 | Zagor | any opinions which bugs we should fix for 1.4? |
11:04:55 | LinusN | i'm a little puzzled by the priorities |
11:05:10 | Zagor | explain |
11:06:09 | LinusN | random regularly repeats, is that a confirmed bug? |
11:06:25 | Bagder | regarding 612509, did we fix that fat_mount after the 1.3 release? |
11:06:47 | Zagor | Bagder: let me check |
11:07:00 | Zagor | LinusN: half confirmed :-) i still can't repeat it. |
11:07:27 | LinusN | the discussion has turned into a feature request |
11:07:41 | Zagor | Bagder: that was fixed in 1.3. his problem is a truly odd fat partition, IMHO |
11:07:59 | Bagder | probably yes, but then we could set that to fixed I guess |
11:08:45 | Zagor | Bagder: well, it's still something of a problem since it works with archos firmware |
11:09:15 | Bagder | ah, sorry, I misread your comment, I thought it was fixed _after_ 1.3... ok, then it is a bug |
11:10:06 | Zagor | 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 | LinusN | Zagor: i don't |
11:22:55 | Zagor | LinusN: his request does not explain the bug |
11:23:01 | LinusN | 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 | LinusN | because he wants "true" random |
11:23:29 | Zagor | sure. but that still doesn't explain the behaviour he gets. |
11:24:17 | LinusN | stopping the player without pausing explains it perfectly |
11:25:25 | Zagor | ah, right. could be that. |
11:25:51 | LinusN | as i explained in my long comment |
11:26:34 | LinusN | i just hate the word wrapping in SF's bug tracker |
11:27:24 | Zagor | i agree |
12:00 |
12:25:32 | Zagor | 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:00 |
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 | kargatron | in request tracker, is high priority # correspond to high or low priority? seen it used both ways |
13:18:14 | Zagor | high # == high prio |
13:18:50 | kargatron | ah, cool (since Zagor bumped up wps tag request :-) |
13:18:58 | Zagor | :-) |
13:19:17 | kargatron | i wish request tracker could sort by last modifed, to see latest comments easily. is that configurable? |
13:20:11 | Zagor | 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 | kargatron | when completely refreshing/replacing jukebox contents, is it recommended to reformat the drive? to get rid of fragmentation, etc? |
13:29:18 | Zagor | 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 | Zagor | Bagder: can you look at the playsim? my lcd split broke it in some strange ways |
13:38:18 | Bagder | sure |
13:38:22 | Zagor | the charset break is the least strange :-) |
13:42:09 | Bagder | well, it almost works for me |
13:42:18 | Bagder | just some graphical errors |
13:42:46 | Bagder | and the cursor moves wrong |
13:43:19 | Bagder | how are we gonna solve the charset issue for the player sim? any ideas? |
13:45:36 | Zagor | i want it simulated closely to the real thing. with lcd_define_pattern and all |
13:45:51 | Zagor | maybe we can simply blow it up 2x to get the right "feel" |
13:45:59 | Bagder | too bad no one really cares about the player sim |
13:46:05 | Zagor | yeah |
13:47:48 | Zagor | if someone else fixes the charset(s), can you write the code? |
13:48:25 | Bagder | I could |
13:54:31 | | Quit Schnueff (Read error: 110 (Connection timed out)) |
14:00 |
14:05:44 | | Quit mem ("reset") |
14:11:14 | | Join langhaarrocker [0] (~Philipp@B232c.pppool.de) |
14:13:57 | langhaarrocker | Bagder: And the winner is ... ? |
14:14:34 | Bagder | oh, right |
14:14:39 | Bagder | forgot |
14:18:08 | Zagor | LinusN: red build |
14:20:13 | LinusN | those f*ing simulators |
14:20:43 | * | Bagder watches LinusN's mouth with soap ;-) |
14:20:47 | Bagder | washes |
14:20:55 | * | Bagder goes and learns to type |
14:21:14 | LinusN | glrgogoprlrr |
14:21:21 | Zagor | :) |
14:24:22 | langhaarrocker | 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 | Bagder | :-) |
14:25:13 | | Quit langhaarrocker ("Trillian (http://www.ceruleanstudios.com)") |
14:26:26 | | Join langhaarrocker [0] (~Philipp@B232c.pppool.de) |
14:28:32 | pyvasene | 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 | pyvasene | 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:00 |
15:12:40 | kargatron | 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 | Schnueff | hm converting those charsets codes_{old,new}.png with a perl script would spoil the joy of the non-programmers? |
15:13:42 | Bagder | :-) |
15:13:56 | kargatron | 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 | Bagder | please spoilt that :-) |
15:14:02 | kargatron | yeah, was thinking the same, re: perl script. |
15:14:12 | Schnueff | i got one |
15:14:33 | kargatron | (though my charset understanding is nil - you don't learn that stuff when you get a physics degree :) |
15:15:14 | Bagder | kargatron: hey, we'll be happy to feed lots of info to you until you get it ;-) |
15:16:11 | LinusN | kargatron: but mp3gain won't help when playing with Rockbox, will it? |
15:16:31 | kargatron | oh, is the header that's adjusted by mp3gain not read by rockbox? |
15:16:37 | LinusN | no |
15:16:52 | kargatron | oh, thought that it was adjusting a std header |
15:16:55 | kargatron | oh well |
15:16:57 | Bagder | I guess we could make it |
15:17:10 | kargatron | makes a difference while listening at my computer, so still worth it |
15:17:23 | LinusN | it's adding an ID3V2 tag, or a field in the Lame INFO header |
15:17:57 | kargatron | YA feature request :) |
15:18:12 | LinusN | i've been thinking of adding support for that, but i haven't come around to that |
15:19:03 | kargatron | regardless, if you listen at your computer, the effort's worthwhile, imo. i notice it. |
15:19:41 | Schnueff | row is high-order nibble in those charset? |
15:19:43 | Schnueff | charsets |
15:20:30 | Bagder | yes... or is it LSB first? |
15:20:42 | * | Bagder checks |
15:21:54 | Bagder | LSB first |
15:22:00 | Schnueff | hm |
15:22:07 | Schnueff | so 0x14 is A |
15:22:12 | Schnueff | sorry |
15:22:19 | Schnueff | 0x54 is a |
15:22:30 | Schnueff | (in old charset) |
15:22:56 | Bagder | uh, you're talking about that png |
15:23:03 | Schnueff | yes |
15:24:02 | Bagder | sorry, 45 is A in the old |
15:24:15 | Bagder | 41 in the new |
15:24:19 | Schnueff | 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 | bobTHC | hi all! |
15:30:46 | LinusN | 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 | bobTHC | i recieve a mail with "eol formats were problematic", what the deal with *.lang end of line ? |
15:32:48 | Bagder | bobTHC: what about them? |
15:32:52 | LinusN | there were problems if the last line didn't have EOL |
15:33:05 | bobTHC | ok... |
15:33:10 | LinusN | fixed now |
15:33:11 | YeAhx | new builds are released even with no changes? is it automated? |
15:33:15 | Bagder | in the bdf font, yes |
15:33:35 | Bagder | YeAhx: the daily builds are fully automated, yes |
15:34:08 | LinusN | we rebuild every 20 minutes, if a file has changed |
15:34:28 | YeAhx | nice |
15:34:44 | YeAhx | Im loving the lack of delay between tracks |
15:35:11 | LinusN | YeAhx: took some effotr to remove it |
15:35:13 | LinusN | effort |
15:35:56 | YeAhx | my old rio wasnt bad but I dont think I notice any at all on my archos with rockbox |
15:36:10 | kargatron | that only affects tracks that were contiguous but separated? |
15:36:21 | LinusN | or Lame encoded |
15:36:35 | kargatron | or does it shorten gaps between random mp3s? |
15:36:52 | LinusN | kargatron: it removed all non-mp3 info |
15:36:53 | kargatron | (say if lame encoded...) |
15:36:59 | LinusN | removes |
15:37:33 | YeAhx | oh its better with LAME encoded? |
15:37:55 | YeAhx | no wonder, thats my main encoder how |
15:37:56 | YeAhx | now |
15:38:20 | LinusN | i read somewhere that LAME does a better job somehow regarding the gap between tracks |
15:38:40 | Schnueff | lame man page documents a −−nogap option |
15:38:47 | Schnueff | but i think that has to be specially enabled |
15:39:08 | YeAhx | so does ogg |
15:39:09 | Schnueff | (and it worx on a sets of contiguous .wave files, i presume) |
15:40:00 | LinusN | i guess that it encodes the two files as they were one WAV file, keeping the bit reservior filled in between |
15:40:04 | YeAhx | ogg vorbis files are the only type I have got to play with no gaps on my computer |
15:40:20 | Schnueff | yes, and if takes sample from the next file to fill mp3 frames, i guess |
15:40:24 | Schnueff | s/if/it |
15:43:23 | | Join pimlottc [0] (~pimlottc@a1-1b012.neo.rr.com) |
15:45:04 | YeAhx | still, I dont think they playback as well on my computer as they do on the archos with rockbox |
15:45:39 | LinusN | you don't need to suck up to us. we'll be nice to you anyway :-) |
15:46:34 | pimlottc | any recommendations for a program to keep sync between hd and archos under linux? |
15:46:52 | Schnueff | hm |
15:47:23 | Bagder | pimlottc: I wrote a little perl script that works for me |
15:47:34 | Bagder | updates my archos according to my local dir changes |
15:47:43 | Schnueff | bidirectional is more difficult |
15:47:47 | pimlottc | Bagder - mind sending a copy? |
15:47:55 | Bagder | http://daniel.haxx.se/stuff/mp3sync |
15:48:00 | pimlottc | schnueff - actually unidirection I think is all that I need |
15:48:06 | Schnueff | ok |
15:48:11 | pimlottc | Bagder - danke. |
15:48:27 | pimlottc | 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 | kargatron | stupid question - do people talking of 'syncing' their jb have collections that are <= 20GB? |
15:48:51 | pimlottc | kargatron - myself, yes |
15:49:10 | kargatron | ok |
15:49:11 | Schnueff | rsync usually pays attention on the file date |
15:49:30 | kargatron | was just trying to figure out what synching would mean with collection >> jb |
15:49:33 | Schnueff | maybe one has to use −−modify-window option to account for the low time resolution on vfat |
15:49:56 | pimlottc | Schneuff - it still sems to copy too much with the −−size-only option |
15:50:12 | Schnueff | hm |
15:50:23 | Schnueff | and u set −−whole-file too? |
15:50:39 | pimlottc | I've also been thinking about what could be done in rockbox to aid the syncing process |
15:50:50 | pimlottc | (i'm aware there is no control when usb is plugged in) |
15:51:17 | Schnueff | hm strange |
15:53:12 | pimlottc | although I admit I haven't come up with much |
15:54:34 | pimlottc | I didn't set −−whole-file, I thought that only affect the how it copied |
15:54:52 | Schnueff | its just to make sure that rsync doesnt try to compute checksums on archos |
15:54:59 | Schnueff | (for partially transmitted files and such) |
15:55:31 | Schnueff | 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 | pimlottc | I have not set it to use checksums at all |
15:56:21 | LinusN | time to go home, bye all! |
15:56:21 | pimlottc | since it'd just have to slurp the whole file over USB |
15:56:45 | | Part LinusN |
15:56:57 | Schnueff | pimlottc: i thought that what the -W (−−whole-file) switch was for |
15:58:09 | pimlottc | schneuff - for what, turning off checksum? |
15:58:12 | Schnueff | yes |
15:58:46 | pimlottc | as far as I see it doesn't use checksusm unless you specify −−checksum |
15:59:04 | pimlottc | and the runtime seems to agree |
15:59:12 | Schnueff | hm default is to use checksums, i'm quite sure on that |
15:59:26 | Schnueff | −−checksum says: use checksum even if dates are the same and size matches |
15:59:53 | Schnueff | 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 |
16:00:05 | pimlottc | hmm good point looks like you're right |
16:00:42 | elinenbe | http://slashdot.org/comments.pl?sid=40423&threshold=1&commentsort=0&tid=100&mode=flat&cid=4306201 |
16:00:50 | pimlottc | I just know when I do −−dry-run it gives results much faster than if it's checksumming everything |
16:00:54 | Schnueff | (but maybe u often do tag updates are such things? then it would surely make a difference) |
16:01:00 | Schnueff | s/are/and/ |
16:02:07 | Bagder | " 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 | Bagder | shocking |
16:02:40 | Schnueff | indeed |
16:02:51 | | Join datazone [0] ([p5zkfbdmr@207.136.36.203) |
16:03:08 | pimlottc | 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 | Bagder | " It is incapable of playing music while reading from the hard disk" |
16:03:34 | Bagder | hahaha |
16:03:43 | Bagder | ipod surely seems a bit "limited" in its software |
16:03:53 | Bagder | "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 | Schnueff | 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 | elinenbe | read about how one person uses .cue files to remove these gaps on the PJB (Personal Jukebox) |
16:11:28 | Bagder | 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 | Schnueff | its for burning the TOC when u copy an audio cd. |
16:13:10 | Schnueff | but u can abuse it for that purpose |
16:13:30 | Bagder | ok |
16:13:54 | Schnueff | and there's a plugin for winamp which supports that (mp3cue) |
16:14:29 | YeAhx1 | did he think I was sucking up? hehe |
16:14:32 | YeAhx1 | nah |
16:14:44 | YeAhx1 | I just love rockbox |
16:14:52 | Bagder | I *think* it was a joke, but you never know with Linus ;-) |
16:15:06 | * | Bagder is always serious |
16:15:11 | Schnueff | sure:) |
16:15:23 | * | Bagder always ignores mail too B) |
16:15:32 | YeAhx1 | 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 | YeAhx1 | this is what Im reffering to |
16:16:13 | YeAhx1 | YeAhx: still, I dont think they playback as well on my computer as they do on the archos with rockbox |
16:16:14 | YeAhx1 | LinusN: you don't need to suck up to us. we'll be nice to you anyway :-) |
16:16:47 | Schnueff | 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 | YeAhx | how crapola |
16:33:03 | YeAhx | woops |
16:33:05 | YeAhx | hehe |
16:33:13 | YeAhx | what is a TOC file anyway? |
16:33:49 | YeAhx | I think there is an invisible one on a CD I just bought |
16:33:50 | Bagder | you mean toc header? |
16:34:03 | Bagder | oh |
16:34:21 | * | Bagder stands silent in a corner |
16:34:23 | YeAhx | 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 | YeAhx | 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 | YeAhx1 | 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 | Schnueff | hm |
17:00 |
17:02:15 | bobTHC | who make the pitch code ? |
17:02:34 | Bagder | Linus |
17:03:07 | bobTHC | u think it's possible like the ff/fd config menu to configure steps....? |
17:04:05 | bobTHC | because it's to bad to listen to much "click" noise |
17:04:38 | Bagder | of course its possible |
17:05:58 | bobTHC | it's would be great.... |
17:06:11 | | Quit YeAhx (Read error: 110 (Connection timed out)) |
17:06:36 | bobTHC | in all case, thanx a lot to linus for this so good option! |
17:06:54 | Bagder | gotta run |
17:06:56 | | Part Bagder |
17:09:37 | YeAhx1 | there is pitch code? |
17:11:00 | bobTHC | yep |
17:12:29 | YeAhx1 | biatchin |
17:12:45 | bobTHC | what ? |
17:12:46 | YeAhx1 | the font thing sounds pretty cool |
17:12:53 | YeAhx1 | pitch mode |
17:13:06 | bobTHC | >>>biatchin ?? |
17:13:30 | YeAhx1 | hehe yeah totaly |
17:13:40 | Schnueff | whats the meaning of that |
17:17:07 | YeAhx1 | sorry |
17:17:07 | YeAhx1 | roflmao |
17:17:07 | YeAhx1 | nevermind |
17:17:17 | YeAhx1 | it just sounds like a handy feature to have |
17:18:17 | Schnueff | funny even |
17:20:47 | | Join YeAhx [0] (~aarond@66.81.88.2) |
17:21:22 | YeAhx | I was just laughing at your reactions to my use of that word |
17:21:43 | Schnueff | it looked like a typo to me |
17:21:46 | Schnueff | :) |
17:22:08 | YeAhx | well usualy I would say "bitchin" but I like to alter it every once in a while |
17:22:42 | YeAhx | 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 | bobTHC | and what's roflmao ? |
17:24:03 | YeAhx | rolling on the floor laughing my ass off |
17:24:30 | bobTHC | ok thx.. |
17:25:51 | YeAhx | no prob |
17:26:33 | pimlottc | biatch is normally only an alternate of the noun form |
17:27:36 | YeAhx | ah ic |
17:27:39 | YeAhx | oh well |
17:29:03 | | Part kargatron |
17:30:04 | YeAhx | 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 | YeAhx | and it has the ending yeaaah |
17:30:42 | YeAhx | Jimi Hendrix - 1983...(A Merman I Should Turn To Be) |
17:35:00 | YeAhx | in case anyone was wondering |
17:35:30 | YeAhx | 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:00 |
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 |
19:00:12 | | Join Phantom [0] (Phantom@ASte-Genev-Bois-109-1-1-104.abo.wanadoo.fr) |
19:00:15 | Phantom | HI ! |
19:00:24 | dwihno | bonsoir |
19:00:25 | Phantom | I ve got a big Bug |
19:00:42 | dwihno | bug bug? |
19:01:28 | Phantom | I09:CPUAdrEr |
19:01:38 | Phantom | at 0F00082A |
19:03:44 | dwihno | oops |
19:05:50 | | Quit Phantom () |
20:00 |
20:33:49 | | Join Phantom [0] (Phantom@ASte-Genev-Bois-109-1-2-136.abo.wanadoo.fr) |
20:33:54 | Phantom | HI |
20:34:21 | Phantom | ? |
20:34:27 | Phantom | nobody ? |
20:34:49 | Phantom | I ve a big bug and nobody to talk about |
20:35:15 | Phantom | HELPPP |
20:35:24 | *** | Saving seen data "./dancer.seen" |
20:35:28 | | Part elinenbe |
20:38:35 | Phantom | HEELP : big fatal error |
20:45:27 | | Quit Phantom () |
21:00 |
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:00 |
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 | Ennan | helo |
22:26:21 | Ennan | people here |
22:26:21 | Ennan | ? |
22:28:16 | | Quit Zagor|away ("Client Exiting") |
22:29:29 | Ennan | 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:00 |
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 | DexterAYS | hi dudes, do you already have a german translation? |