| 00:14:52 | amiconn | Bagder: Your pointer idea was indeed helpful. I have to use this in video.rock :) |
| 00:15:42 | | Quit gromit``` (Read error: 110 (Connection timed out)) |
| 00:19:36 | webguest79 | I have a question for whoever admins the website... |
| 00:22:23 | webguest79 | ok, i'll rephrase :) is there anybody here who can make changes on the website |
| 00:22:27 | webguest79 | ? |
| 00:25:38 | | Quit webguest79 ("CGI:IRC 0.5.4 (2004/01/29)") |
| 00:27:00 | | Quit _aLF ("bye") |
| 00:34:00 | | Quit mecraw__ (Read error: 104 (Connection reset by peer)) |
| 00:34:21 | | Join mecraw__ [0] (~lmarlow@69.2.235.2) |
| 00:40:03 | | Join PhatPat [0] (~44b8d1f1@labb.contactor.se) |
| 00:41:03 | | Quit PhatPat (Client Quit) |
| 00:42:35 | | Join mecraw_ [0] (~lmarlow@69.2.235.2) |
| 00:43:01 | | Quit mecraw__ (Read error: 104 (Connection reset by peer)) |
| 00:56:03 | *** | Saving seen data "./dancer.seen" |
| 01:00 |
| 01:04:18 | | Join frsyj [0] (s336156@student.uq.edu.au) |
| 01:05:23 | frsyj | Does anyone know what causes the message 'Playlist buffer full' to appear whenever I try and play a song in rockbox? |
| 01:10:02 | Sebulba02 | Your playlist size is too small? |
| 01:15:26 | frsyj | Can't I just turn it on and press play on a song? |
| 01:15:40 | amiconn | frsyj: (1) How many songs are in that directory? (2) What is "Max playlist size" set to? (3) Do you have a full installation (especially: does the .rockbox directory exist)? |
| 01:15:54 | | Join mecraw__ [0] (~lmarlow@69.2.235.2) |
| 01:18:14 | frsyj | 1) 11. 2) Not sure, looking for the setting now. 3) Yes. Got the 2.2 release for recorder v1 last night. Extracted it to the root of archos. .rockbox folder exists with a bunch of subdirectories and a couple of files (.playlist_control and ROCKBOX.UCL) |
| 01:19:19 | amiconn | Hmm. When there are only 11 files it should definitely work... the lowest possible settings for Max playlist size is 1000. But I recommend that you try and install a daily build anyway. |
| 01:20:22 | frsyj | ok, I'll give it a whirl |
| 01:20:58 | amiconn | Rockbox 2.2 is way old... |
| 01:24:37 | frsyj | Can I delete .DS_Store? |
| 01:26:25 | amiconn | I don't know. .DS_Store is not a rockbox part |
| 01:27:01 | frsyj | seems like there's a few weird files/directories.. windows must make them? System Volume Information sounds windowsy |
| 01:27:50 | amiconn | Yes, SVI is windows' system restore folder for that drive |
| 01:28:12 | | Quit mecraw_ (Read error: 110 (Connection timed out)) |
| 01:29:18 | amiconn | .DS_Store is MacOS X "folder information" |
| 01:29:59 | frsyj | Aah.. .Trashes might be from there too.. I deleted it anyway.. |
| 01:30:15 | frsyj | Daily build is working! Thanks! :) |
| 01:50:06 | | Join webguest35 [0] (~80c10006@labb.contactor.se) |
| 01:50:55 | | Nick webguest35 is now known as bagawk (~80c10006@labb.contactor.se) |
| 01:54:32 | bagawk | Bagder: are you there? |
| 02:00 |
| 02:03:36 | | Quit Sebulba02 ("brb") |
| 02:05:41 | | Quit frsyj (".") |
| 02:06:25 | | Quit amiconn (" nite") |
| 02:20:27 | | Quit bagawk ("CGI:IRC (EOF)") |
| 02:45:46 | | Quit mecraw__ ("Trillian (http://www.ceruleanstudios.com)") |
| 02:56:05 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:19:53 | | Quit AciD (Read error: 104 (Connection reset by peer)) |
| 04:00 |
| 04:40:12 | | Join webguest02 [0] (~cfd5ade7@labb.contactor.se) |
| 04:44:07 | | Quit webguest02 (Client Quit) |
| 04:56:06 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:09:01 | | Part scott666_ |
| 05:54:35 | | Quit plok ("I'm outta here!") |
| 06:00 |
| 06:48:47 | | Join LinusN [0] (~linus@labb.contactor.se) |
| 06:56:10 | *** | Saving seen data "./dancer.seen" |
| 07:00 |
| 07:12:55 | | Join methangas [0] (methangas@0x50a476ab.virnxx10.adsl-dhcp.tele.dk) |
| 07:32:42 | | Join ashridah [0] (ashridah@220.253.121.133) |
| 07:52:04 | dwihno | Greetings everyone! |
| 07:52:22 | LinusN | hola |
| 07:53:07 | dwihno | Okay, tell me how crazy you find this idea: |
| 07:53:55 | dwihno | Using a stock stereo handsfree and replacing the headphones with a pair from my "old" MDR-70 |
| 07:54:21 | dwihno | Using a bunch of converters and cords, I've tested using my MDR71 phones with my cell phone, and the result isn't that bad really! |
| 07:54:39 | dwihno | So with MDR70 phones, music will be more enjoyable |
| 07:55:14 | dwihno | Crazy of brilliant? :) |
| 07:56:13 | LinusN | silly! :-) |
| 07:59:49 | dwihno | How come? :) |
| 08:00 |
| 08:00:37 | dwihno | I thihk the idea is crazy and cool :) |
| 08:06:53 | LinusN | maybe i don't get it |
| 08:07:21 | LinusN | why have MDR70 phones for your cell phone? |
| 08:08:17 | dwihno | My phone is mp3-capable |
| 08:09:54 | LinusN | yes, but why not use your archos? |
| 08:10:21 | dwihno | I ride my bike every day and during the winter the unit is prone to RLD's all the time :/ |
| 08:33:44 | | Join amiconn [0] (~jens@pD9E7E2DC.dip.t-dialin.net) |
| 08:34:06 | | Join Zagor [242] (~bjst@labb.contactor.se) |
| 08:34:24 | amiconn | Morning |
| 08:35:02 | Zagor | hi |
| 08:43:53 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 08:56:08 | Zagor | amiconn: why did you rename default_event_handler? |
| 08:56:12 | *** | Saving seen data "./dancer.seen" |
| 08:57:03 | Zagor | oh, my mistake. |
| 08:57:33 | LinusN | jörg did it |
| 08:57:39 | LinusN | and he didn't rename it |
| 08:57:59 | Zagor | amiconn committed it anyway |
| 08:58:10 | LinusN | oh, my mistake then |
| 08:58:12 | LinusN | :-) |
| 08:58:56 | LinusN | i'm not sure i like the solution, but i see the problem he tried to solve |
| 09:00 |
| 09:00:33 | | Join kurzhaarrocker [0] (~knoppix@p50877B3E.dip0.t-ipconnect.de) |
| 09:01:33 | * | kurzhaarrocker detects fake stop button events |
| 09:02:28 | kurzhaarrocker | They occur when the hd is accessed and when my batteries are half drained. |
| 09:03:37 | Zagor | kurzhaarrocker: are you using the latest version? |
| 09:03:49 | kurzhaarrocker | yesterdays daily build |
| 09:04:12 | kurzhaarrocker | (flashed but I doubt that that is important) |
| 09:04:17 | Zagor | interesting |
| 09:05:53 | kurzhaarrocker | My batteries aren't the best any more. While the debug screen tells me they deliver ~ 5.9 V I can see the backlight flicker when the hd is accessed. Maybe they have an unusual high inner resitance. When they are fully charged I don't get those fake stop button events. |
| 09:07:40 | LinusN | we could filter the keys even harder |
| 09:08:08 | LinusN | i have heard of other guys that still have problens with the keys |
| 09:08:14 | Zagor | but off is not on an adc |
| 09:08:29 | LinusN | it's not an adc reading problem |
| 09:08:46 | Zagor | so how would we filter then? |
| 09:09:12 | LinusN | my theory is that the increased adc reading rate accentuates the voltage dip problem |
| 09:09:24 | kurzhaarrocker | What surprised me too ist that when I'm in playback and these fake stop events occur I have the fade out - fade in - stop effect. It doesn't occur when I hit stop manually. |
| 09:09:30 | LinusN | filter == debounce |
| 09:10:06 | Zagor | how would debouncing help? it only eliminates repeat events. |
| 09:10:18 | LinusN | no |
| 09:10:44 | Zagor | ok you mean filtering out short presses? |
| 09:10:49 | LinusN | yes |
| 09:11:09 | Zagor | it's worth a try |
| 09:13:46 | LinusN | kurzhaarrocker: wanna try it yourself? |
| 09:14:16 | kurzhaarrocker | Send it to phil at carangg.de and I will. |
| 09:14:26 | LinusN | i meant changing the code |
| 09:14:53 | kurzhaarrocker | I wished I had the ressources for that. If I had I'd dig into triggered recording update. :( |
| 09:15:11 | LinusN | ok |
| 09:17:05 | LinusN | kurzhaarrocker: building... |
| 09:17:21 | LinusN | i'll try to halve the poll rate |
| 09:17:33 | kurzhaarrocker | .. and it seems that you're much quicker at things like that :D |
| 09:21:28 | | Join [IDC]Dragon [0] (~idc-drago@pD9FF8C69.dip.t-dialin.net) |
| 09:22:20 | [IDC]Dragon | amiconn: nice plugin frenzy |
| 09:23:14 | [IDC]Dragon | @all: just a quick question, will the startup I/O debug code be acceptable in cvs? |
| 09:23:54 | [IDC]Dragon | or should I send it to Jens in private? |
| 09:25:07 | Zagor | send it privately, i think. it's not much use in the everyday builds. |
| 09:25:58 | LinusN | kurzhaarrocker: sent |
| 09:26:13 | [IDC]Dragon | except for field surveys, but we may not need that |
| 09:29:59 | kurzhaarrocker | LinusN: it still stops :( |
| 09:31:03 | [IDC]Dragon | Zagor: about the button quirk in the FM screen: |
| 09:31:42 | [IDC]Dragon | why is FM_MENU and FM_PRESET defined with BUTTON_REL? |
| 09:32:01 | [IDC]Dragon | (maybe there's a good reason which I don't get) |
| 09:32:41 | [IDC]Dragon | the first is causing the menu "lock", because the menu exits on plain F1 |
| 09:32:47 | | Join einhirn [0] (Miranda@bsod.rz.tu-clausthal.de) |
| 09:33:06 | Zagor | no, there is no reason. i have not done the fm screen at all, since I can't test it. cvs annotate says you did that :) |
| 09:33:39 | [IDC]Dragon | I think the release was there before |
| 09:34:19 | Zagor | i never touched radio.c. but never mind, just change it. |
| 09:34:28 | Zagor | i don't like to make changes i can't test |
| 09:34:31 | [IDC]Dragon | oh, sorry then |
| 09:37:55 | * | [IDC]Dragon walks away in shame... |
| 09:38:00 | | Quit [IDC]Dragon () |
| 09:39:35 | LinusN | kurzhaarrocker: have you tried with the original firmware? |
| 09:39:48 | kurzhaarrocker | not yet |
| 09:39:48 | * | kurzhaarrocker tries |
| 09:44:19 | kurzhaarrocker | The original firmware continues playing. The battery status symbol displays ~ 60%, when the hd is accessed it temporarily drops down to one single pixel column. |
| 09:48:00 | | Quit kurzhaarrocker (Read error: 104 (Connection reset by peer)) |
| 09:49:41 | | Join kurzhaarrocker [0] (~knoppix@p50877B3E.dip0.t-ipconnect.de) |
| 09:52:57 | LinusN | you seem to have a battery issue |
| 09:53:17 | LinusN | but rockbox still shouldn't fail on the keys, not when the original doesn't |
| 09:53:38 | kurzhaarrocker | The 1/4 poll build seems to have succeded. But I should mention that I had the recorder connected to the power adapter during the transfer. (not during the test) |
| 09:53:40 | Bagder | atkbd.c: Keyboard on isa0060/serio0 reports too many keys pressed. |
| 09:53:57 | Bagder | (my kernel log after my daughter's last attack ;-) |
| 09:54:35 | dwihno | :) |
| 09:56:10 | kurzhaarrocker | LinusN about the batteries: I have a external charger that can measure the capacity. It says that the capacity has dropped down to ~ 1100 mAh. They are the original green 1500 mAh thingies that came with the jukebox. |
| 09:57:16 | LinusN | Bagder: wow, a kbd DOS attack |
| 09:57:48 | Bagder | yeah, she's almost like a script kiddie |
| 09:57:58 | LinusN | kurzhaarrocker: please run the 1/4 version for a while and let me know if it is ok |
| 09:58:20 | Zagor | did someone knowingly change the default sound settings away from flat? |
| 09:58:28 | kurzhaarrocker | it is running, has accessed the disk a couple of times and stil is running. |
| 09:58:33 | LinusN | they have never been flat by default |
| 09:58:40 | Zagor | on the recorder they have |
| 09:58:56 | LinusN | nope, bass:6 and treble:6 has been the default for ages |
| 09:59:03 | * | kurzhaarrocker nods |
| 09:59:28 | Zagor | my memory is playing tricks on me... |
| 10:00 |
| 10:01:28 | Bagder | the cvs table will be all green in just three more lines |
| 10:02:01 | | Join oxygen77 [0] (~Chris@pauguste-7-82-66-87-78.fbx.proxad.net) |
| 10:02:26 | kurzhaarrocker | how boring |
| 10:08:04 | kurzhaarrocker | Apropos batteries loosing capacity: What do you think about adding lowering the minimal capacity setting? |
| 10:08:18 | kurzhaarrocker | - adding |
| 10:08:31 | LinusN | why? |
| 10:08:58 | LinusN | you really should get new batteries instead |
| 10:09:23 | kurzhaarrocker | With batteries that still have > 1000 mAh? What a waste. |
| 10:10:10 | kurzhaarrocker | I don't need the extended runtime but I'd enjoy a more precise estimation on the remaining play time. |
| 10:10:21 | LinusN | do you really get 1100 from them, or is this just the estimate from your external charger? |
| 10:11:05 | kurzhaarrocker | The charger measures that by discharging the batteries at 600 mA. I think that makes it pretty realistic. |
| 10:11:06 | LinusN | i believe the discharge curve changes when the batteries wear out |
| 10:11:46 | LinusN | so i don't think the rockbox battery time estimation works that well on your batteries anyway |
| 10:12:28 | LinusN | but what the heck, it's no big deal |
| 10:13:09 | kurzhaarrocker | ... and there still are new 1000 mAh batteries availabe - somtimes even very cheap. |
| 10:15:18 | kurzhaarrocker | (I believe that you're right about the discharge curve) |
| 10:16:59 | kurzhaarrocker | I encountered the first fake stop event with the 1/4 poll build. |
| 10:17:10 | | Part oxygen77 ("Cho") |
| 10:17:39 | amiconn | kurzhaarrocker: NICd/NiMH batteries are considered worn out if they only reach ~2/3 of their original capacity |
| 10:17:54 | kurzhaarrocker | Then mine are worn out. |
| 10:19:05 | kurzhaarrocker | 2nd fake stop event |
| 10:19:06 | * | kurzhaarrocker tries the original firmware once more |
| 10:22:51 | LinusN | hmmm, we don't have to save the SR, MACH and MACL registers in load/store_context() |
| 10:23:28 | LinusN | in fact, saving SR does more harm than good, since we can't change context with interrupts disabled |
| 10:23:28 | amiconn | LinusN: Ooops! |
| 10:23:43 | amiconn | MACL and MACH should be saved... |
| 10:23:45 | kurzhaarrocker | original firmware doesn't seem to have any problems. |
| 10:23:54 | LinusN | amiconn: we don't use the DSP |
| 10:24:19 | LinusN | kurzhaarrocker: which probably means that they have a lower poll rate |
| 10:24:21 | amiconn | MACL and MACH are the hardware multiplier registers, and they are definitely used |
| 10:26:01 | LinusN | We use Multiply And Accumulate? where? |
| 10:26:47 | amiconn | MULU / MULS do also use MACL... |
| 10:27:39 | * | kurzhaarrocker forgot how ugly the peak meter in the original firmware was. |
| 10:27:50 | | Join [ [0] (~d90a3255@labb.contactor.se) |
| 10:28:11 | | Quit [ (Client Quit) |
| 10:28:20 | | Join [IDC]Dragon [0] (~d90a3255@labb.contactor.se) |
| 10:28:28 | LinusN | amiconn: ah, i see now |
| 10:28:44 | LinusN | but aren't they scratch registers? |
| 10:28:48 | Bagder | http://forums.rockbox.org/index.php?topic=40 |
| 10:28:52 | Bagder | funny lcd problem |
| 10:30:46 | kurzhaarrocker | With backlight off the 1/4 poll still works. With backlight on stop events occur. |
| 10:31:49 | LinusN | kurzhaarrocker: time for a battery change? :-) |
| 10:32:52 | kurzhaarrocker | But I liked that colour. :´( |
| 10:33:46 | amiconn | LinusN: Maybe the MAC* registers are considered scratch... |
| 10:33:48 | LinusN | amiconn: looks like we need to preserve the mac registers |
| 10:34:27 | LinusN | nah |
| 10:34:35 | LinusN | only if we compile with -mhitachi |
| 10:34:52 | amiconn | Iirc ordinary functions do save only r8..r14 |
| 10:35:10 | LinusN | unless you compile with -mhitachi |
| 10:35:27 | amiconn | r0..r7 and macl/mach are considered scratch, and only saved for interrupt handlers |
| 10:35:31 | LinusN | and if you compile with -mhitachi, you can use -mnomacsave to still not save the mac regs :-) |
| 10:36:16 | LinusN | i'll remove sr, macl and mach from the context |
| 10:36:16 | [IDC]Dragon | speaking of compile flags, how about -Os for the usual build? |
| 10:36:41 | amiconn | I'd rather vote for -O2 ... |
| 10:37:07 | [IDC]Dragon | I though that's the current |
| 10:37:44 | amiconn | current is -O |
| 10:37:49 | * | [IDC]Dragon is concerned about size, not speed |
| 10:38:44 | kurzhaarrocker | But if we had more speed we might be able to do ogg decoding |
| 10:38:44 | * | kurzhaarrocker runs away |
| 10:38:57 | amiconn | [IDC]Dragon: Iirc you reported that someone tried -Os for the fm, and it didn't fit either |
| 10:39:22 | [IDC]Dragon | maybe now it does |
| 10:39:25 | amiconn | [IDC]Dragon: Btw: The voice ui is really responsive on Ondio now :-) |
| 10:39:33 | [IDC]Dragon | :-) |
| 10:40:09 | [IDC]Dragon | yes, it's nicely masked, better than for recorders |
| 10:42:31 | [IDC]Dragon | it was a commit-and-run yesterday, I hope everyting still works |
| 10:42:51 | [IDC]Dragon | like purge after playback, etc. |
| 10:43:35 | amiconn | Seems to work nicely. It even works if a plugin calls the default_event_handler and an MMC is inserted... |
| 10:44:04 | [IDC]Dragon | the -Os flag does some substantial save, I forgot if it was 1.5 or 3 KB, but something in that range |
| 10:44:13 | LinusN | how does the poweroff work for you? |
| 10:44:34 | [IDC]Dragon | if you ask me, I haven't tested |
| 10:44:44 | [IDC]Dragon | see the "run" part |
| 10:44:49 | amiconn | Poweroff works fine on Ondio. |
| 10:44:56 | LinusN | nice |
| 10:45:37 | LinusN | removing macl/h and sr from the context worked nicely |
| 10:45:53 | amiconn | I still wonder if it would be even better to fake a real poweroff (the user may continue holding the button) |
| 10:46:12 | LinusN | how does the original firmware do? |
| 10:46:12 | [IDC]Dragon | I'm all for it |
| 10:46:41 | [IDC]Dragon | it displays a progress bar while shutting down |
| 10:46:42 | LinusN | why would the user keep holding the button? |
| 10:47:01 | kurzhaarrocker | Ask that user, LinusN |
| 10:47:18 | LinusN | i don't think i'll find one |
| 10:47:41 | [IDC]Dragon | because a too short press doesn't power it down |
| 10:47:52 | LinusN | a too short press will not say "shutting down" |
| 10:48:35 | [IDC]Dragon | so the to-be-found user may hold it until she sees the desired response |
| 10:48:43 | LinusN | yes |
| 10:48:59 | LinusN | or (if you have it in your pocket) for several seconds |
| 10:49:11 | [IDC]Dragon | to which the new splash is an improvement |
| 10:49:21 | LinusN | but it will power down when the user releases the button |
| 10:51:56 | Zagor | faking shutdown early is a good thing, imho. it gives the user a better impression. he is not really interested in our housekeeping, he just wants to turn off the player. |
| 10:52:26 | LinusN | i don't think it does any harm |
| 10:52:45 | LinusN | but he really should release the key |
| 10:53:05 | LinusN | if the housekeeping takes long, the hardware might shut down |
| 10:53:35 | Zagor | well people tend to stop pressing buttons as soon as the desired effect has occured |
| 10:53:44 | LinusN | yesm the "shutting down" message |
| 10:53:44 | [IDC]Dragon | I think the most natural is to write the shutdown message while we're doing something, then fake off |
| 10:54:05 | LinusN | in the ondio case, yes |
| 10:54:22 | Zagor | LinusN: seeing the machine shut down is a massively more convincing reason to stop pressing the button |
| 10:54:31 | LinusN | i agree |
| 10:54:43 | LinusN | and in the fm/v2 case, it doesn't matter |
| 10:55:13 | LinusN | lcd_clear_screen() right before power_off() |
| 10:55:31 | Zagor | and turn off backlight |
| 10:55:36 | LinusN | yeah |
| 10:56:05 | Zagor | also cranking contrast to lightest would be good (as suggested yesterday) |
| 10:56:13 | *** | Saving seen data "./dancer.seen" |
| 10:56:17 | LinusN | oh |
| 10:56:26 | kurzhaarrocker | Blind users won't notice. Maybe it should say "The unit is now off" :) |
| 10:56:33 | LinusN | lol |
| 10:56:36 | Zagor | hehe |
| 10:57:01 | [IDC]Dragon | kurzhaarrocker: I thought you went away, to implement ogg |
| 10:57:42 | kurzhaarrocker | <- must do weird things in java for money. |
| 10:58:16 | [IDC]Dragon | do it in java then |
| 10:59:02 | kurzhaarrocker | Maybe tomorrow afternoon, [IDC]Dragon. |
| 10:59:23 | [IDC]Dragon | ok, but no later, users are waiting |
| 11:00 |
| 11:02:20 | LinusN | amiconn: wanna try the poweroff now? |
| 11:03:01 | | Join webguest38 [0] (~d96ee3e8@labb.contactor.se) |
| 11:07:37 | | Quit webguest38 (Client Quit) |
| 11:08:33 | amiconn | LinusN: Can't do that atm, /me @ work, Ondio @ home... |
| 11:08:45 | LinusN | sure |
| 11:08:54 | LinusN | i have committed the fake poweroff code |
| 11:09:45 | [IDC]Dragon | I can try a bleeding edge, Ondio here, but compiler @ home |
| 11:10:41 | amiconn | [IDC]Dragon: I can compile, but not test |
| 11:11:33 | [IDC]Dragon | bleeding edge should compile for me |
| 11:15:29 | [IDC]Dragon | just have to wait ~5 more minutes |
| 11:16:00 | | Join GarBage [0] (~x@107.Red-217-127-93.pooles.rima-tde.net) |
| 11:16:16 | [IDC]Dragon | LinusN: you didn't clear the screen content? |
| 11:17:14 | LinusN | nope, the lcd contrast should do the trick |
| 11:19:22 | [IDC]Dragon | I'd still do that, dunno if it's that low in all circumstances |
| 11:20:42 | amiconn | [IDC]Dragon: (video.rock) (1) Did you notice my speed fix kludge? (2) I have an idea how to enable contrast setting on Ondio... |
| 11:20:47 | LinusN | maybe not, let's see |
| 11:21:10 | LinusN | it might even look "better", since the screen isn't really clear in a real poweroff situation |
| 11:21:19 | LinusN | cleared |
| 11:21:30 | [IDC]Dragon | (1) I have seen some ratio formula, but didn't have a 2nd look |
| 11:21:51 | [IDC]Dragon | (2) which is? |
| 11:21:53 | LinusN | oh, the ondio doesn't have a contrast setting? |
| 11:22:12 | [IDC]Dragon | just while playing video, out of keys |
| 11:22:21 | LinusN | aha...you scared me :-) |
| 11:24:01 | amiconn | [IDC]Dragon: (2) Using the menu key as shift, then Left or Right. Menu alone will still be the stop seek |
| 11:24:33 | LinusN | wow, this is good (from the misticriver board): |
| 11:24:34 | LinusN | hi maties; |
| 11:24:34 | LinusN | i'm a newb from aus |
| 11:24:34 | DBUG | Enqueued KICK LinusN |
| 11:24:34 | LinusN | gimme 10 reasons y iriver h340 is the best; better than ipod, i wanna yell it 2 mi mate. i might get da h340; is the screen good??? gimme all da good points about it and da bad 1's 2 |
| 11:24:34 | [IDC]Dragon | amiconn: did you notice the top pixel row looks odd, with video? |
| 11:25:10 | LinusN | totally unreadable for old people like me :-) |
| 11:25:25 | [IDC]Dragon | you'r no gangsta rapper? |
| 11:25:45 | LinusN | and he posted again, when nobody answered: |
| 11:25:55 | LinusN | "n e 1??? |
| 11:25:55 | LinusN | thanx " |
| 11:26:09 | Zagor | he haven't even seen it, yet is convinced it's "the best"? people are strange... |
| 11:26:45 | LinusN | "n e 1???" is 8 chars, "anyone?" is 7 :-) |
| 11:27:19 | GarBage | hi, people |
| 11:27:22 | LinusN | hi |
| 11:27:46 | GarBage | first i'd like to congratulate you on your excellent labour on the rockbox fw |
| 11:27:54 | LinusN | thanks |
| 11:27:54 | kurzhaarrocker | GarBagder - is that you, Bagder? :) |
| 11:28:01 | GarBage | it's pretty impressive |
| 11:28:11 | GarBage | kurzhaarrocker : nope |
| 11:28:16 | LinusN | kurzhaarrocker: lol |
| 11:28:21 | kurzhaarrocker | sorry, just kidding, GarBage |
| 11:28:39 | GarBage | i'm a developer for the open source neuros firwmare |
| 11:28:52 | amiconn | [IDC]Dragon: Didn't notice... Any idea why that is? |
| 11:29:02 | Zagor | GarBage: any luck with the compiler yet? |
| 11:29:05 | GarBage | and i agree on some points you reflected on your website |
| 11:29:24 | GarBage | it is no free development environment yet |
| 11:29:34 | [IDC]Dragon | amiconn: an LCD glitch? I see it on recorder, too, if in upside down mode like the Ondio |
| 11:29:47 | GarBage | which is bad, i know |
| 11:29:53 | | Join MisticJeff [0] (~0c68cc30@labb.contactor.se) |
| 11:30:04 | MisticJeff | howdy |
| 11:30:07 | LinusN | yo |
| 11:30:12 | GarBage | the Texas Instruments compiler evaluation period lasts 90 days |
| 11:30:20 | MisticJeff | H340 Intl. Version... |
| 11:30:26 | Zagor | GarBage: you have to code quickly then ;) |
| 11:30:35 | LinusN | GarBage: is the mp3 codec source code available? |
| 11:31:08 | MisticJeff | USBOTG, 2" Fantastic Color screen, FM Tuner, FM Record, Docking Cradle |
| 11:31:24 | GarBage | Zagor : i have it, but i'm afraid i cannot disclose it, for patent issues |
| 11:31:35 | GarBage | i mean, LinusN |
| 11:31:35 | LinusN | MisticJeff: want, want, want...! :-) |
| 11:31:45 | MisticJeff | Is it better than iPod, they both have their moments |
| 11:31:53 | Zagor | MisticJeff: does it have an RTC? |
| 11:32:09 | LinusN | GarBage: so nobody can build a neuros firmware but neuros themselves? |
| 11:32:09 | Zagor | GarBage: so the mp3 codec is not part of the project either? |
| 11:32:10 | MisticJeff | Real Time Clock? |
| 11:32:14 | Zagor | MisticJeff: yes |
| 11:32:37 | GarBage | nope, there are several unofficial builds on our CVS tree |
| 11:32:39 | MisticJeff | I believe so but never have checked |
| 11:32:44 | GarBage | anyone can compile it |
| 11:33:04 | Zagor | GarBage: but you have to link the mp3 codec as a binary? |
| 11:33:07 | MisticJeff | The US version of the player is one to stay away from however |
| 11:33:17 | GarBage | Zagor : not at this time, you can use it, but only on binary libs |
| 11:33:25 | LinusN | MisticJeff: yeah, saw that |
| 11:33:27 | Zagor | right |
| 11:33:33 | MisticJeff | Zagor: check your email |
| 11:34:28 | MisticJeff | If you were going to port Rockbox to the H300 platform you'd definitely want the Intl. version |
| 11:34:39 | GarBage | can you do Ogg, FLAC or any other codec on the archos? |
| 11:34:41 | LinusN | we will probably need both :-( |
| 11:34:49 | LinusN | GarBage: not on the archos |
| 11:35:17 | LinusN | the codec is a dedicated mp3 chip |
| 11:35:53 | GarBage | so... your're putting your efforts on the iriver platform, now? |
| 11:36:13 | LinusN | well, we are porting to it |
| 11:36:20 | LinusN | or rather, i am |
| 11:36:52 | Zagor | well it's not like you're alone, just because you are the only one with hardware... :) |
| 11:37:01 | LinusN | :-) |
| 11:37:24 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 11:37:24 | * | LinusN is porting the threading today |
| 11:37:53 | LinusN | looks like the context switch will be a single MOVEM instruction :-) |
| 11:38:30 | Zagor | ooh, nice |
| 11:38:46 | Zagor | GarBage: we are not abandoing archos, we are just expanding our hardware support |
| 11:38:59 | GarBage | i see |
| 11:39:11 | LinusN | i'm not saving the DSP registers, since the DSP stuff is likely to be done in a single thread |
| 11:39:52 | GarBage | you have achieved a lot, given that no help from the manufacturers itself was granted... i'm truly amazed |
| 11:40:03 | Zagor | thank you |
| 11:40:07 | LinusN | lots of hard work... |
| 11:40:14 | * | Zagor is hungry |
| 11:40:19 | * | LinusN too |
| 11:40:20 | Zagor | lunch time |
| 11:40:23 | LinusN | yup |
| 11:40:37 | kurzhaarrocker | http://www.dosis.uni-dortmund.de/Mensa/ |
| 11:40:48 | LinusN | GarBage: before we go, did you have a specific thing to discuss? |
| 11:41:25 | | Part MisticJeff |
| 11:41:27 | GarBage | well.. the remaks on your webpage about the neuros... they are kinda displicent |
| 11:41:45 | LinusN | GarBage: please join the wiki and change it yourself |
| 11:41:57 | GarBage | i was wondering why you have such a bad feeling about it |
| 11:42:40 | GarBage | nope, i don't want to change anything, just know if there was any reason i should know |
| 11:43:07 | LinusN | you mean the "big and bulky" remark? |
| 11:43:21 | GarBage | nope, it is bulky |
| 11:43:37 | GarBage | just the "adds very little" |
| 11:44:04 | LinusN | well, what does it add? |
| 11:44:10 | GarBage | it can do a lot more things, being honest |
| 11:44:52 | LinusN | such as? |
| 11:45:09 | LinusN | (hardware wise) |
| 11:45:32 | GarBage | like added codecs, DSP processing,tempo/pitch shifting, alarms, timed recordings.... since i don't know all the features on the archos i can't tell for sure |
| 11:46:17 | LinusN | i agree about the DSP stuff, but the alarms/timed recordings are just RTC features that can easily be implemented on the archos as well |
| 11:46:37 | [IDC]Dragon | GarBage: you're mor than welcome to enrich the wiki entry. It's public! |
| 11:47:00 | GarBage | well, and the whole radio broadcasting stuff, just to mention some |
| 11:47:38 | LinusN | that web page is discussing possible target platforms for Rockbox |
| 11:48:04 | LinusN | and we really didn't feel that the neuros hardware had that much "extra" to offer |
| 11:48:38 | GarBage | a GCC port for TI C54x/C55x is on its way, also... but i bet it will take a looong time |
| 11:48:47 | LinusN | and the TI DSP makes the discussion moot anyway |
| 11:49:19 | LinusN | is there any progress on the gcc port? |
| 11:49:42 | LinusN | i really have to go to lunch now, please stick around |
| 11:49:44 | [IDC]Dragon | hardware-wise, the Neuros and Iriver are probably in the same league |
| 11:49:50 | GarBage | i'd really love to see that ported to a GCC target, that will make development much fun |
| 11:49:56 | LinusN | cu later |
| 11:50:10 | GarBage | LinusN : see ya |
| 11:50:22 | [IDC]Dragon | but not with sexiness and openess |
| 11:51:44 | GarBage | i agree, but i like the added expandability given by the neuros |
| 11:53:39 | GarBage | and the iriver support or 'openness' itself will be quite poor, if it wasn't for you're future port |
| 11:54:32 | [IDC]Dragon | sure, the manufacturer is not opening it in any way |
| 11:54:58 | [IDC]Dragon | I meant the compiler, which is a key issue for open source development |
| 11:56:49 | [IDC]Dragon | your effort is appreciated a lot here, it's just that %&# "wrong" CPU |
| 11:57:00 | GarBage | the neuros makers do support us, and for me that's a point to support them back.. anyway, just my though, i'd beter support any company which hears and cares than any other which don't |
| 11:57:23 | GarBage | i agree they made some terribly decissions in the past |
| 11:57:42 | amiconn | [IDC]Dragon: The ratio formula is because of your .rvf design, as it stores the frame time *as no. of CPU clocks*, and the Ondio has a different clock... |
| 11:58:04 | [IDC]Dragon | the decision might be perfectly OK, from a professional and commercial standpoint |
| 11:58:54 | [IDC]Dragon | amiconn: yes, as this has to perfectly match the encoding, to maintain long-term A/V sync |
| 11:59:40 | [IDC]Dragon | I knwe that catch with the video player, should have warned you |
| 12:00 |
| 12:00:19 | [IDC]Dragon | away now, lunch |
| 12:26:37 | | Join AciD [0] (~gni@longchamp44-1-82-67-133-87.fbx.proxad.net) |
| 12:50:16 | | Part kurzhaarrocker |
| 12:56:17 | *** | Saving seen data "./dancer.seen" |
| 12:56:57 | [IDC]Dragon | back again |
| 13:00 |
| 13:07:16 | amiconn | [IDC]Dragon: (1) Perfect-match sync can be done a different way (2) The round-off error with Rec->Ondio is around 1/50000, less than 1/10 sec per hour |
| 13:10:46 | Zagor | GarBage: we do not dislike neuros, we just can't support the player since there is no free compiler available. we have very good relations with joe born. |
| 13:12:59 | LinusN | i think i have a good idea regarding the voice mode |
| 13:13:29 | LinusN | the idea is to implement an "emergency" mode for the blind: |
| 13:14:04 | Zagor | Bagder: do you feel like hacking up some perl to create id3 indices like we discussed on the list? |
| 13:14:07 | LinusN | hold Play when you start the player, and rockbox adjusts the settings for voice |
| 13:14:19 | Zagor | i'll start banging up some browser code in the sim |
| 13:14:37 | LinusN | resets the buffer sizes, enables voice, resets the language etc |
| 13:15:08 | Zagor | LinusN: what if there is no .voice file on the disk? |
| 13:15:27 | LinusN | also, i think we could add a tiny .voice file to the distribution, with one entry: "no voice file" |
| 13:16:13 | Zagor | ah, neato |
| 13:16:32 | LinusN | also, the emergency mode could accept any voice file, regardless of language |
| 13:16:49 | Zagor | first match? |
| 13:17:04 | LinusN | maybe |
| 13:17:05 | Zagor | such as novoice.voice ;) |
| 13:17:33 | LinusN | is it likely that a blind person has two voice files? |
| 13:17:50 | Zagor | if we ship a minimal default, then yes |
| 13:17:58 | LinusN | no, i mean two languages |
| 13:18:36 | Zagor | i guess people could be experimenting with different voice files (at&t vs ms etc) but any of them will do I guess |
| 13:18:44 | LinusN | if he has, he probably understand both languages |
| 13:18:55 | LinusN | there can be only one voice per language |
| 13:18:57 | Zagor | agreed |
| 13:19:44 | LinusN | but you can fake it by putting Mary in deutsch.voice |
| 13:19:47 | LinusN | etc |
| 13:19:56 | LinusN | then you select the voice by changing language :-) |
| 13:20:12 | Zagor | :) |
| 13:20:48 | LinusN | you can even have pseudo languages, english_mary.lang/voice |
| 13:20:59 | LinusN | as long as there is a .lang file |
| 13:21:22 | LinusN | .lng of cource |
| 13:21:27 | LinusN | course |
| 13:21:28 | LinusN | bla |
| 13:27:15 | | Join iriver_srn [0] (root@lada.kom.auc.dk) |
| 13:29:41 | LinusN | so it searches for english.voice first (which is the default language) |
| 13:30:09 | LinusN | if it isn't present, it takes the first match that isn't "no.voice" |
| 13:30:19 | LinusN | else it takes "no.voice" |
| 13:45:02 | | Join webguest29 [0] (~8446db96@labb.contactor.se) |
| 13:51:38 | Zagor | sounds good |
| 13:58:11 | | Quit webguest29 ("CGI:IRC") |
| 14:00 |
| 14:26:44 | | Quit einhirn (Read error: 54 (Connection reset by peer)) |
| 14:45:42 | Bagder | Zagor: you know/have/use any id3 stuff for perl? |
| 14:45:54 | Zagor | yeah, hang on |
| 14:46:20 | Zagor | aw crap, my home box is off. hmm... |
| 14:47:29 | Zagor | I think it was MP3::Info that I used |
| 14:47:54 | LinusN | Zagor: what do you think about dave's idea? |
| 14:48:05 | Zagor | it will take lots of ram |
| 14:48:09 | LinusN | (single-file database) |
| 14:48:11 | LinusN | why? |
| 14:48:20 | Zagor | oh that, well that will "just" be slower |
| 14:48:50 | LinusN | you mean a lot of seeking? |
| 14:49:20 | Zagor | yes |
| 14:49:37 | LinusN | we can open the file twice |
| 14:49:47 | LinusN | and seek in it with two file handles |
| 14:49:51 | Zagor | true |
| 14:51:03 | dwihno | that is possible? |
| 14:51:12 | LinusN | yes, as long as it's read-only |
| 14:53:55 | Zagor | i'm not sure using such huge chunks of data as he suggests is good though |
| 14:54:18 | LinusN | reading a line in the database will take time, since we have to parse it, looking for separators |
| 14:54:40 | | Join webguest37 [0] (~c7e73280@labb.contactor.se) |
| 14:55:53 | Bagder | btw 'libmp3-info-perl' is the name of the debian package |
| 14:56:00 | webguest37 | http://www.mp3newswire.net/stories/2004/irivercar.html iRiver Turns Focus on In-Dash MP3 Players |
| 14:56:18 | *** | Saving seen data "./dancer.seen" |
| 14:56:43 | webguest37 | Marilyn Chen, iRiver's CEO, made the announcement today that her company will develop in-dash players for the car. According to Chen, the units will "integrate an MP3 player, satellite radio and email functionalities on a single-chip solution". |
| 14:57:00 | webguest37 | just thought ypu'd like to know... |
| 14:57:05 | webguest37 | you'd |
| 14:57:05 | LinusN | email in a car...wow... |
| 14:57:10 | Zagor | lol email |
| 14:57:17 | webguest37 | rockbox? |
| 14:57:30 | webguest37 | :) |
| 14:57:32 | Zagor | sure, go ahead ;) |
| 14:57:34 | Bagder | we lack an email client! |
| 14:57:44 | Bagder | gee, how have we managed? |
| 14:58:00 | LinusN | iEmail |
| 14:58:03 | webguest37 | isn't there an old saying about all projects evolving to read mail? |
| 14:58:21 | LinusN | yup, that will be the end of iRiver :-) |
| 14:58:22 | Bagder | yeps |
| 14:59:01 | Bagder | "Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can." |
| 14:59:16 | LinusN | mp3, satellite radio and email in a single chip? |
| 14:59:28 | LinusN | sounds like an april fools joke |
| 14:59:57 | webguest37 | probably said "device" and got misquoted. |
| 15:00 |
| 15:00:03 | Bagder | LinusN: and a bad one! |
| 15:00:10 | Bagder | wouldn't fool me! ;-) |
| 15:00:34 | * | webguest37 imagines sat radio -> mp3 ripper |
| 15:00:47 | webguest37 | like xmpcr |
| 15:00:57 | LinusN | Zagor: the database could still be one file, pretty much your original idea with all files concatenated |
| 15:01:11 | LinusN | beats me why, though |
| 15:01:16 | webguest37 | off to work, bye |
| 15:01:20 | | Quit webguest37 ("CGI:IRC 0.5.4 (2004/01/29)") |
| 15:01:20 | LinusN | easier to transfer, maybe |
| 15:01:33 | LinusN | and no opening and reopening of files... |
| 15:01:35 | Zagor | he cited a worry about only some files being copied |
| 15:01:51 | Zagor | ...and judging from the problems we've had with people only installing half of rockbox I think he has a point |
| 15:02:10 | LinusN | indeed |
| 15:02:37 | LinusN | time for a wiki page, maybe? |
| 15:02:43 | Bagder | indeed |
| 15:02:52 | * | Bagder installed mp3::info |
| 15:03:01 | LinusN | i'm worried about the parsing of field separators |
| 15:03:10 | Zagor | tab? |
| 15:03:12 | LinusN | can take time on large lines |
| 15:03:47 | Zagor | well we don't want binary data, so there's no other way |
| 15:03:56 | LinusN | fixed field sizes? |
| 15:04:17 | Zagor | how many tracks can an album have, then? |
| 15:04:23 | Zagor | how many songs per year? |
| 15:04:51 | Zagor | fixed size invites trouble |
| 15:05:07 | LinusN | i know, then we have to introduce even more offset pointers |
| 15:05:23 | LinusN | every line can point to the next |
| 15:05:24 | Zagor | dave has a point though about mixed-artist albums. we need them to show up once for each artist |
| 15:05:36 | Bagder | we do |
| 15:06:02 | Zagor | yeah but when we browse into the album, we only want to show the artist's songs. we don't do that. |
| 15:06:02 | LinusN | we do what? |
| 15:06:15 | Bagder | need to support multi-artists per single album |
| 15:06:22 | LinusN | yes |
| 15:06:26 | Zagor | at least I think we want that... don't we? ;) |
| 15:06:31 | LinusN | i want it |
| 15:06:39 | LinusN | i have lots of compilations |
| 15:06:40 | Bagder | I'll demand it! ;-) |
| 15:07:00 | Zagor | i was referring to only showing one artist's tracks |
| 15:07:14 | LinusN | so, we want a database format with as painless parsing as possible |
| 15:07:26 | LinusN | (short rows) |
| 15:07:35 | Zagor | short rows does not mean painless parsing |
| 15:07:57 | LinusN | no, but it could mean less items to parse |
| 15:08:11 | Zagor | quite the opposite if you have to skip a lot of lines to get to the next logical item |
| 15:08:21 | LinusN | like, for instance, his idea of combining albums and song in one line |
| 15:08:43 | amiconn | [IDC]Dragon: r u there? |
| 15:08:48 | Zagor | well my objection for that is not so much that the lines becomes long, as that it mixes data used on two different occations |
| 15:09:43 | Zagor | thus having to fill the cache with unused data |
| 15:09:44 | LinusN | yup |
| 15:09:51 | LinusN | read his new post |
| 15:10:21 | Zagor | still bad, he mixes filename with song title |
| 15:10:46 | LinusN | i want a raw filename table first |
| 15:10:47 | * | Zagor calls for dave over the subetheral channel |
| 15:11:32 | LinusN | daaaaaave! |
| 15:11:32 | Zagor | also quotes are no good separators, lots of song names contain quotes. tabs are probably best |
| 15:11:47 | LinusN | ack |
| 15:12:02 | Bagder | or slashes or newlines |
| 15:12:10 | Bagder | seldomly used in filenames |
| 15:12:31 | Bagder | hm, no slashes are often used in tracks/artists |
| 15:12:34 | Zagor | filenames no, but song titles are pretty random in what they use. slashes are probably well used. |
| 15:12:47 | Zagor | i've never seen a song name with tab though :) |
| 15:12:57 | Zagor | ..or another <32 char |
| 15:13:07 | Bagder | or > 240 |
| 15:13:09 | Bagder | ;-) |
| 15:13:36 | Zagor | >240 is dangerous since some people are using utf-8 in their tags |
| 15:13:37 | LinusN | tab is nice, it's still editable in a text editor |
| 15:13:49 | Bagder | I can now parse a song for id3 |
| 15:13:56 | | Join stripwax [0] (~stripwax@83-245-18-74.dsl.prodigynet.co.uk) |
| 15:13:57 | Bagder | veeeery tricky perl ;-) |
| 15:14:02 | LinusN | welcome dave |
| 15:14:03 | Zagor | welcome dave! |
| 15:14:07 | stripwax | howdy |
| 15:14:08 | Bagder | welcome dave! |
| 15:14:12 | LinusN | :-) |
| 15:14:14 | * | Bagder joins in |
| 15:14:25 | Zagor | we don't want to mix filenames and song names. filename is technical data which is not needed for browsing. |
| 15:14:49 | LinusN | we still need a "raw" filename table |
| 15:14:52 | stripwax | separate index mapping Song Name to filename. Cannot do vice-versa since not all tracks will have valid tags |
| 15:15:27 | Zagor | exactly, which is what my song-index does. we just don't want to load the filename to get the song name |
| 15:15:48 | Zagor | i think we basically agree, we just need to solve the mixed-artist album thing |
| 15:15:57 | stripwax | did you read my latest email |
| 15:15:58 | LinusN | the file name is only interesting when we want to load the actial file |
| 15:15:59 | Zagor | yes |
| 15:16:14 | stripwax | (i haven't received a copy from the server yet) |
| 15:16:32 | Bagder | 600 outgoing mails take a while at times ;-) |
| 15:16:36 | stripwax | :-) |
| 15:16:41 | Zagor | i'm not happy about mixing albums and songs either. we only use one of them during browsing, and we're very concious about saving ram |
| 15:17:58 | stripwax | maybe map artists to individual songs then. or separate the "album names" from the "album name->songs" mappings? |
| 15:18:29 | LinusN | the general idea is to have lots of single mappings |
| 15:18:52 | LinusN | that's why we opted for several fils in the first place |
| 15:19:02 | stripwax | iRiver maps artists to individual songs |
| 15:19:31 | stripwax | i agree totally, but we could put it all in one self-contained file. we dont' need to load the entire file (hence the offsets, just read the parts we need) |
| 15:19:39 | LinusN | agreed |
| 15:19:40 | Zagor | could you describe briefly how irivers browser works, from the user perspective? |
| 15:19:47 | | Join einhirn [0] (Miranda@bsod.rz.tu-clausthal.de) |
| 15:19:56 | Zagor | (anyone with an ipod here?) |
| 15:20:07 | * | LinusN shivers |
| 15:20:09 | stripwax | browse screens shows a selection of "Artist","Album","Genre","Song Title" or 'Directory Structure'. |
| 15:20:51 | Zagor | when you browse into an artist, do you get a list of albums or songs? |
| 15:21:07 | stripwax | Selecting any of the first four brings a new window showing alphabetical list of the chosen tag. Selecting Artist brings up a list of songs. So does Album. |
| 15:21:13 | stripwax | two seconds.. .let me just turn on my iriver... |
| 15:21:41 | Zagor | my idea was to show a list of albums when you select an artist, including a pseudo album called <all songs> |
| 15:22:14 | LinusN | and in this list we would also include compilations |
| 15:22:15 | stripwax | iriver takes ages to boot because it loads the entire db on startup ... yawn ...zzzz |
| 15:22:24 | LinusN | how silly |
| 15:22:37 | Zagor | we won't do that. we'll be very fast since we want it to work on our 12MHz archoses too... |
| 15:22:55 | stripwax | linusn- no because compilation is not by a single artist |
| 15:22:57 | stripwax | ok i'm wrong |
| 15:22:58 | LinusN | with 2Mb RAM |
| 15:23:13 | stripwax | selecting artist shows albums |
| 15:23:21 | Zagor | stripwax: right, but it could list all the album the artist is featured on |
| 15:23:39 | LinusN | maybe with an (F) prepended or something |
| 15:23:44 | Zagor | F? |
| 15:23:48 | LinusN | Featured |
| 15:23:53 | stripwax | yep, looks like that's exactly what iriver does in fact! but then when you select the album it only shows the songs by that artist |
| 15:24:04 | Zagor | right, that's what I expected |
| 15:24:18 | Zagor | it means we need to add a filter in the browser right away |
| 15:24:36 | stripwax | selecting album shows a list of all artists featured on that album... |
| 15:24:42 | Zagor | but we'll want that anyway (for year and genre), so it's not a problem |
| 15:24:48 | stripwax | (followed by tracks on that album) |
| 15:25:13 | Zagor | stripwax: so an album shows both all artists and all tracks? |
| 15:25:18 | stripwax | genre->artist->album->track |
| 15:25:51 | stripwax | album shows all artists first. selecting an artist from the new menu shows all tracks, by that artist, on that album |
| 15:26:26 | stripwax | i.e. album->artists->tracks on album by that artist |
| 15:26:30 | Zagor | but can't you browse into a mixed-artist album and play all tracks from start to finish? |
| 15:26:45 | stripwax | every menu also has a 'select all' so you can |
| 15:26:59 | [IDC]Dragon | back from meeting |
| 15:27:15 | * | [IDC]Dragon is overwhelmed by the traffic meanwhile |
| 15:27:16 | Zagor | aha, "clear filter" |
| 15:27:27 | LinusN | re the parsing: each field could have a size field, to make the parsing/reading easier |
| 15:28:10 | LinusN | so you won't have to search for the delimiter |
| 15:28:11 | Zagor | LinusN: yeah, that'd work. then we could use binary data to avoid all the atoi()s |
| 15:28:22 | LinusN | probably |
| 15:28:24 | stripwax | i.e. ie browser album->shows all artists and also "select all". selecting "select all" shows all tracks by all artists on the album. you can then pick a track or 'select all' to play all tracks |
| 15:28:37 | stripwax | definitely make the db file binary!! |
| 15:29:00 | LinusN | why is it that important? |
| 15:29:17 | LinusN | i'd say the opposite |
| 15:29:39 | LinusN | binary data is often evil |
| 15:29:53 | stripwax | really? you'd keep indices (stored in the file) in a text format? so the file could be about 4 times bigger than it needs to be, and takes longer to parse because of the atois? |
| 15:29:58 | Zagor | hellishly difficult to debug user problems |
| 15:30:08 | Bagder | I think I favour binary here |
| 15:30:12 | stripwax | i agree binary data is often evil. the obvious format to use if of course xml. |
| 15:30:22 | stripwax | but for embedded devices binary is often best |
| 15:30:26 | LinusN | xml obvious? |
| 15:30:33 | amiconn | [IDC]Dragon: Got my remarks concerning video sync? |
| 15:30:41 | Zagor | we're obviously from different cultures. :-) |
| 15:30:47 | LinusN | i think we can't avoid binary data here |
| 15:30:59 | stripwax | of couse xml is obvious - we're representing structured data in textual format |
| 15:30:59 | Zagor | no, I agree binary is best for this |
| 15:31:14 | Zagor | well let's not go into the xml issue more than "i don't agree" |
| 15:31:15 | stripwax | i agree |
| 15:31:29 | | Join dittohead2004 [0] (~alechaney@195.44.197.114) |
| 15:31:37 | [IDC]Dragon | amiconn: if you mean 13:07, yes |
| 15:31:48 | LinusN | ok, so the file could contain this: |
| 15:32:05 | LinusN | 1) an index table for all the sub-tables |
| 15:32:07 | amiconn | [IDC]Dragon: yes. |
| 15:32:19 | LinusN | 2) a "raw" file name table |
| 15:32:31 | LinusN | 3) the rest of the single-map tables |
| 15:33:11 | amiconn | LinusN: Why not use 2 files? The main database, as text, and an index file (that is automatically rebuilt in case it's date is older than the database's) as binary? |
| 15:33:13 | LinusN | and references are made using file offsets |
| 15:33:29 | LinusN | amiconn: that was the original idea |
| 15:33:44 | [IDC]Dragon | a dumb question: do you guys here are familiar with how ralational databases work? |
| 15:33:44 | Zagor | amiconn: remember those people who only copy rockbox.ucl/ajbrec.ajz and then come asking why they get errors? |
| 15:34:13 | [IDC]Dragon | s/ralational/relational |
| 15:34:26 | Zagor | [IDC]Dragon: well on what level do you mean? I know some sql... |
| 15:34:31 | stripwax | dragon - yes. are you suggesting we use a relational database within rockbox just to store tag info? |
| 15:34:39 | stripwax | ps - dragon? buzz-users? |
| 15:34:50 | [IDC]Dragon | from the few things I remember, there are tables mapping from info n to info m |
| 15:35:14 | stripwax | dragon - see above for my xml comment (and subsequent beating :-) |
| 15:35:22 | [IDC]Dragon | by using the tables in the correct order, you can map from anything to anything |
| 15:35:50 | Zagor | [IDC]Dragon: yes, but it's very cpu intensive since you have to search for everything. we want to avoid that as much as we can. |
| 15:35:53 | amiconn | Zagor: Yes I remember. But for those it doesn't matter whether you use 1 or 2 files either |
| 15:36:04 | stripwax | dragon - rdbs work mostly by storing as much as possible in ram. we want to store as little as possible in ram :-) |
| 15:36:17 | Zagor | amiconn: yes it does. if the database is just one file, they can't forget to copy half of it |
| 15:36:42 | [IDC]Dragon | stripwax: but we can quickly seek on the HD |
| 15:37:08 | stripwax | dragon - that would eat battery |
| 15:37:17 | Zagor | basically the system we propose is like that, with sorted indices for each data table |
| 15:37:23 | LinusN | exactly |
| 15:37:35 | LinusN | lots of sorted tables |
| 15:37:38 | stripwax | yes |
| 15:37:57 | [IDC]Dragon | stripwax: only during the lookup, how often are you doing that? |
| 15:38:12 | LinusN | and we can reduce the seeking by opening the database with several file handles |
| 15:38:21 | Bagder | ok, recursive id3 scanner in perl works |
| 15:38:31 | LinusN | Bagder: goodie |
| 15:38:59 | amiconn | Zagor: Hence I suggested the index is *automatically* rebuilt if it is older (or not present, of course) |
| 15:39:00 | stripwax | would the tag db on rockbox allow us to playlist say, everything by this artists, everything from 1995, etc ? |
| 15:39:23 | Bagder | tools/songdb.pl committed |
| 15:39:57 | Zagor | stripwax: yes |
| 15:40:00 | LinusN | stripwax: absolutely |
| 15:40:03 | stripwax | amiconn if it's all in one file, there's nothing to rebuild |
| 15:40:27 | Zagor | building it on the player will be painful, at least on archos players |
| 15:40:36 | Zagor | better to do it on the pc |
| 15:40:52 | LinusN | full ack |
| 15:41:01 | [IDC]Dragon | for die-hard users, it could be a plugin |
| 15:41:19 | LinusN | for die-batteries users you mean? :-) |
| 15:41:25 | Zagor | :) |
| 15:41:25 | stripwax | :-D |
| 15:41:31 | [IDC]Dragon | the query will hopefully be a plugin, too? |
| 15:41:45 | Zagor | no, it will be core code |
| 15:41:48 | LinusN | the browser should be integrated |
| 15:41:58 | Zagor | just as the directory browser is |
| 15:42:01 | stripwax | definitely |
| 15:42:01 | [IDC]Dragon | bye, bye Rombox |
| 15:42:08 | stripwax | ? |
| 15:42:10 | LinusN | maybe the playlist-from-query could be a plugin |
| 15:42:12 | Zagor | rombox is not a goal in itself |
| 15:42:18 | [IDC]Dragon | I know |
| 15:42:39 | Zagor | if we fix the charge-at-boot issue, we don't need the dual-boot feature and rombox will have lots more space |
| 15:43:09 | [IDC]Dragon | I won't give up dual boot |
| 15:43:11 | LinusN | stripwax: we have both the original firmware and rockbox in the flash |
| 15:43:33 | [IDC]Dragon | but the first image may be an emergency loader, not the Archos f/w |
| 15:43:39 | LinusN | exactly |
| 15:43:51 | Zagor | yes |
| 15:43:52 | [IDC]Dragon | carry on please |
| 15:44:10 | LinusN | so, each field has a size |
| 15:44:19 | LinusN | for easy searching/reading |
| 15:44:25 | LinusN | binary |
| 15:44:26 | Zagor | ok so we need reverse lookup tables too, song->artist, song->album and album->artist |
| 15:44:35 | LinusN | keep'em'coming |
| 15:44:41 | LinusN | loadza tables |
| 15:44:46 | stripwax | zagor do we? that's just in the tag, right? |
| 15:45:07 | LinusN | then we would have to *search* in the database |
| 15:45:11 | Zagor | yes but we don't have the full tag when we browse. that's why we need indices |
| 15:45:28 | stripwax | album->artist doesn't really work, it would be album to artistS. |
| 15:45:55 | Zagor | we need those reverse lookups to for example filter out a single artist in a mixed-artist album |
| 15:45:56 | Zagor | right |
| 15:46:15 | stripwax | are we now suggesting a table mapping the cross-product of all tags? genre->years; artist->genres .. .? |
| 15:46:22 | Zagor | I don't think we need album->artist anyway, not sure what we'd use it for |
| 15:46:38 | Zagor | no, all tags are not filters |
| 15:47:03 | * | LinusN gets some more coffee |
| 15:47:05 | Zagor | basically, we have three "base" tags: artist, album, song. then we have filters: year, genre |
| 15:47:24 | stripwax | why is genre a filter, not a "base" tag? |
| 15:47:30 | Zagor | browsing into year 2003 will get you a list of artists with songs from that year |
| 15:47:48 | stripwax | why not a list of albums? |
| 15:47:52 | Zagor | because genre is unfortunately so abused it's mostly worthless |
| 15:48:17 | stripwax | zagor i tag my own music, so i would use this |
| 15:48:18 | Zagor | you get a list of albums by selecting <all artists> |
| 15:48:43 | Zagor | yes, so you can use genre. it's just that we cannot build the system on the assumption that genre is good. |
| 15:48:59 | stripwax | but if genre is bad, the user just wouldn't use it, right? |
| 15:49:25 | Zagor | exactly. thus it's a filter and not a "hierarchy" tag |
| 15:49:33 | Zagor | am I making any sense? :) |
| 15:49:41 | stripwax | you were... "hierarchy tag"???? |
| 15:50:02 | LinusN | think of the tags as a tree |
| 15:50:18 | Zagor | well my idea is that artist, album and song are "hierarchy" tags. those are the three levels of the browsing hierarchy |
| 15:50:41 | LinusN | year and genre are more like attributes |
| 15:50:43 | Zagor | browsing for example year 2003 will browse artists, but with a "year 2003" filter added |
| 15:50:43 | stripwax | why not the starting points for browsing? album->artist(s), artist->album(s), ... |
| 15:50:57 | LinusN | it will be, in the user interface |
| 15:51:24 | Zagor | the top level user interface will have Artist, Album, Song, Year, Genre etc. |
| 15:51:24 | | Quit [IDC]Dragon ("CGI:IRC (EOF)") |
| 15:51:52 | stripwax | so i'm not sure where the hiearchy thing comes from, if the user interface is effectively flat |
| 15:52:07 | stripwax | ok, so in one direction, yes, artist->album->song makes sense |
| 15:52:11 | Zagor | well it's not really flat, you just enter it at different points |
| 15:52:15 | stripwax | ok |
| 15:53:24 | Zagor | entering at "Albums" gives you all the albums in the database, while going through "Artists->Abba" will show only abbas albums |
| 15:53:39 | stripwax | what i'm saying is, browsing "year 2003" need not browse all artists, it could browse all albums instead. Is the extra step of "all artists" necessary |
| 15:54:06 | Zagor | I believe it will make browsing more friendly. there are a *lot* of albums released in a year |
| 15:54:35 | stripwax | my music collection has more artists than albums ..... |
| 15:55:06 | Bagder | ? |
| 15:55:09 | Zagor | anyway, having the option of selecting artist or <all artists> is a nice feature i think. i'd want it. |
| 15:55:09 | LinusN | even if you count the compilations? how? |
| 15:55:46 | LinusN | let's focus on the database format |
| 15:56:01 | Bagder | I need to go, but my embryo tool can already work for some test shots for db format |
| 15:56:08 | Zagor | Bagder: thanks |
| 15:56:21 | stripwax | ? ok so i'm really confused now. didn't zagor say "browsing year->artists will make browsing more friendly" ? i don't see how, because (including compilations) the number of distinct artists outnumbers the number of individual albums, and suppose I want to quickly find one album released in that year. |
| 15:56:23 | LinusN | Bagder: u r00l |
| 15:56:28 | stripwax | badger, thx!! |
| 15:57:12 | Zagor | stripwax: then don't look at the list of artists, just select <all artists> |
| 15:57:36 | stripwax | zagor exactly, it's an extra step... how does that make browsing more friendly? |
| 15:57:38 | Zagor | but I think your collection is perhaps not the normal case. I think many people have >1 album/artist |
| 15:57:58 | stripwax | it's just an example... (i'm sure my collection isn't really like that) |
| 15:58:26 | LinusN | what would be the typical use case for year browsing? |
| 15:58:37 | Zagor | browsing by year->artist is a feature. just because you don't want it in this case doesn't mean it shouldn't be there. |
| 15:59:11 | Zagor | if we make it simple to skip past it, it will not be a nuisance |
| 15:59:18 | stripwax | linusn - i'm still trying to figure that out. i was originally thinking genre->album, but clearly genre->artist is important. but genre really is a song-specific tag which doesn't necessarily apply to artists or even whole albums |
| 15:59:42 | LinusN | yeah, an attribute |
| 15:59:53 | Zagor | stripwax: that's why I want it as a filter and not part of the "tree" |
| 15:59:56 | stripwax | zagor i never suggested removing year->artist... i suggested adding year->album directly! :-) but i agree that if it's really simple to skip past it, then it makes sense |
| 16:00 |
| 16:00:13 | | Join elinenbe [0] (~elinenbe_@65.115.46.225) |
| 16:00:19 | stripwax | ok cool. |
| 16:00:37 | LinusN | so, back to the database |
| 16:00:56 | LinusN | i like the idea of having a "main index" |
| 16:01:17 | LinusN | so we can add "top entries" without changing the code |
| 16:01:38 | stripwax | yes |
| 16:02:12 | Zagor | top entries? |
| 16:02:17 | LinusN | we need to store as little as possible in ram |
| 16:02:39 | LinusN | top entries == the browser starting points |
| 16:02:41 | stripwax | "TITLE"->offset; "ARTISTS"->offset etc |
| 16:02:45 | Zagor | ah |
| 16:02:48 | LinusN | "artist", "album" etc |
| 16:04:25 | LinusN | we might want several versions of each table, sorted in different ways |
| 16:04:51 | Zagor | i don't think many people want different sorting actually |
| 16:05:17 | stripwax | linusn- for example? |
| 16:05:23 | LinusN | album-by-year, album-by-artist |
| 16:05:58 | Zagor | ok. i consider those different tables, not different sorting |
| 16:06:02 | stripwax | ah ok. me too |
| 16:06:07 | LinusN | ok |
| 16:06:32 | LinusN | the mapping is the same, just sorted differently |
| 16:07:44 | stripwax | oh, i see, album->song table, but sorted by year of release instead of sorted by album name? the table must then include the year so it's a different table |
| 16:07:49 | LinusN | but i guess a list of random album names, invisibly sorted by artis would be quite confusing :-) |
| 16:08:01 | Zagor | quite :) |
| 16:08:30 | LinusN | let's drop the sorting for now |
| 16:09:24 | LinusN | so, the browser loads a table by filling a buffer with the tag strings, and a table with the offsets |
| 16:10:09 | stripwax | it must also load the text table of whatever the offsets point to... |
| 16:10:22 | Zagor | not until you select an entry |
| 16:10:29 | stripwax | yes |
| 16:11:52 | Zagor | but we'll need to load the filter tables too, song->year etc. |
| 16:11:53 | elinenbe | this all sounds really cool... keep up the shizzyness! |
| 16:13:06 | LinusN | you don't need the filter tables too, do you? |
| 16:13:26 | LinusN | you either use an unfiltered table, or you use a filtered one |
| 16:13:36 | LinusN | loadza tables... |
| 16:13:39 | stripwax | linusn - ok, suppose the user browses by clicking on 'Genres'. What actually gets loaded? |
| 16:14:19 | LinusN | the artist-filtered-by-genre table? |
| 16:14:35 | stripwax | you mean filtered or sorted? |
| 16:14:43 | Zagor | LinusN: uh, we can't really created pre-filtered tables can we? 1993->abba, 1994->abba, 1993->aha, 1994->aha.... |
| 16:14:56 | LinusN | hmmm, maybe not |
| 16:16:18 | stripwax | a table of genres; a table of years; and each entry in the artist table ("sorted by artist name")-sorted-by-genre has a pointer to the genre entry. multiple entries for multiple genres by same artist. and another table for artists("sorted by artist name")-sorted by year. |
| 16:17:52 | Zagor | yes, actually we can make prefiltered tables. at least we should calculate how big it would be. after all, there is only a finite number of years in the id3 data mass |
| 16:19:39 | stripwax | each song can only be one year (or genre, etc). so sum of sizes of prefiltered tables of artist by year can be no bigger than size of song table. |
| 16:20:09 | LinusN | example: if we sort by year, we can just use a specific range of the table |
| 16:20:37 | LinusN | that way we can use the sorting as a filter |
| 16:21:52 | stripwax | that's what i said; |
| 16:22:44 | stripwax | although we'd need another table to find that range ! :-) |
| 16:23:26 | stripwax | (i.e. pick genre 'index' from Genres table, look in "artist-by-genre-offsets" table using index, to find the range of the "artist-by-genre" table to use for the given genre) |
| 16:25:18 | stripwax | the artist-by-genre table is just one big table, sorted first by genre (really, grouped rather than sorted), then sorted alphabetically by artist name. the Genres table gives us an ID for a given Genre name. The artists-by-genre-offsets table converts that ID to a range of the artists-by-genre table corresponding to that genre. Correct? |
| 16:26:39 | stripwax | One thought - it won't allow us to filter by year AND genre :-) |
| 16:26:53 | stripwax | (by the way, that was a joke. would anyone use such a feature?) |
| 16:27:22 | LinusN | all the Folk songs released in 1968, yeah, why not? :-) |
| 16:30:16 | stripwax | ok, in that case we'd just load the entire song table and filter it while we load it! I guess we could have a second "all songs" table that maps from song to genre and year of that song ... ;-) |
| 16:31:18 | stripwax | (actually maybe one such table per tag isn't a bad idea, so that we CAN go song->artist; song->year, and do filtering that way for anything that isn't already in a prefiltered table...) |
| 16:32:09 | LinusN | we need to break this down into manageable parts, so we can implement it in steps |
| 16:32:22 | LinusN | a wiki page for the database format is a good start |
| 16:34:47 | Zagor | 5 tags used means 25 cross-reference tables :) |
| 16:36:31 | stripwax | zagor - no i meant ONLY song->tag ... and then add in artist->album ; album->song ; and then any of these prefiltered tables . oh , plus separate tables containing all distinct values of 'tag' i.e. all years, all genres. |
| 16:39:28 | | Part ashridah |
| 16:41:43 | amiconn | LinusN: A completely different topic - we need to find a way to implement multi-volume and changeable media support in rockbox, in a way that does not include too much code on platforms where it is not needed. |
| 16:42:18 | LinusN | for the ondio flash volumes? |
| 16:43:14 | stripwax | so 10 tables (song->genre, song->year, artist->album, album->song, album-grouped-by-genre, album-grouped-by-year, artist-grouped-by-genre, artist-grouped-by-year,Year-to-YearID, Genre-to-GenreID) |
| 16:43:23 | amiconn | yup. For MMC, changeable media support is necessary (otherwise rockbox might get very confused) |
| 16:43:54 | LinusN | i imagine a unix-style virtual file system |
| 16:44:03 | Zagor | amiconn: do we need multi volume? can we access both cards at once? |
| 16:44:06 | amiconn | LinusN: Multi-volume support is required to actually perform better than the archos fw (which disables access to the internal flash as soon as a card is inserted |
| 16:44:37 | amiconn | Zagor: Yes, technically it is possible, and prepared in my driver. The debug info screen already uses that |
| 16:44:45 | LinusN | we could even support multiple partitions |
| 16:45:43 | Zagor | well then we just need to add drive/partition info to struct fat_file |
| 16:45:44 | amiconn | Multi-volume/ multi-disk support would have to be added to both the driver (already prepared for MMC) and the file system. |
| 16:46:51 | Zagor | duplicate fat:fat_bpb and fat_cache |
| 16:46:57 | amiconn | The file system itself has to know about cheangeable media too. It has to invalidate all open file descriptors if the medium they reside on is removed |
| 16:47:09 | amiconn | *changeable |
| 16:47:34 | LinusN | do we really need true hotplugging? |
| 16:47:49 | LinusN | i'd go for a "safe eject" approach |
| 16:48:24 | LinusN | but it would probably be similar to USB mode |
| 16:48:33 | LinusN | which is pretty "hot" today |
| 16:48:34 | amiconn | I'd go for true hotplugging. You can't stop a user from removing the card at any time |
| 16:48:59 | Zagor | how do we discover the card is removed? |
| 16:49:06 | LinusN | an event |
| 16:49:23 | LinusN | just like USB_INSERTED |
| 16:49:27 | amiconn | I would like to integrate multi-volume in a single fs tree. For Ondio the internal would be root ( / ) and the MMC mounted under /MMC (fixed) |
| 16:49:30 | Zagor | well it's a simple thing to go through all open files and close those on that disk |
| 16:49:45 | LinusN | amiconn: that's what i mean with "unix-like" |
| 16:50:08 | Zagor | can you do that without making tree.c ugly? |
| 16:50:28 | LinusN | tree.c wouldn't have to know |
| 16:50:31 | amiconn | This way, the .rockbox installation would always be on the internal, so no additional rockbox install necessary on MMCs. Config sector always on internal as well |
| 16:50:42 | Zagor | LinusN: who adds /mmc to root dir then? |
| 16:50:47 | LinusN | the file system code |
| 16:50:51 | Zagor | bleach, no way |
| 16:50:58 | amiconn | tree.c must be informed about disk changes, to re-read dirs |
| 16:51:05 | Zagor | file system does not now about partitions, and should not |
| 16:51:21 | LinusN | Zagor: i mean file.c and disk.c |
| 16:51:39 | Zagor | I know, and still disagree. they don't need to be changed at all for this. keep them pure. |
| 16:52:15 | LinusN | if we don't implement it there, we would have to duplicate the volume awareness everywhere |
| 16:52:34 | LinusN | in the playlist code, the plugins, etc |
| 16:53:20 | LinusN | a virtual file system makes it transparent |
| 16:53:34 | amiconn | Iiuc, the fat driver has to be duplicated. Or do I miss the point here? |
| 16:53:38 | Zagor | LinusN: you're right |
| 16:53:48 | Zagor | amiconn: no, just two variables in it |
| 16:54:37 | amiconn | Doesn't it have to handle 2 fats? How does it distinguish them? The FATs are cached (partially), aren't they? |
| 16:54:54 | amiconn | It may well be one fs is FAT16 and the other FAT32 |
| 16:55:04 | Zagor | amiconn: the fat cache is one of the two variables to duplicate. the bpb is the other. |
| 16:55:31 | amiconn | (I admit that I don't completely understand the FAT driver) |
| 16:56:19 | *** | Saving seen data "./dancer.seen" |
| 16:56:57 | | Join [IDC]Dragon [0] (~d90a3255@labb.contactor.se) |
| 16:56:57 | amiconn | Does the file system need a thread and a queue to capture the insert/ remove events? |
| 16:57:07 | LinusN | Zagor, stripwax: i have to go, will one of you create a wiki page about the database? |
| 16:57:09 | [IDC]Dragon | I got disconnected |
| 16:57:34 | LinusN | amiconn: i think it can be handled like the USB mode |
| 16:57:51 | Zagor | stripwax: go ahead if you feel like it. i'll be away tonight. |
| 16:57:58 | LinusN | me too |
| 16:58:16 | Zagor | LinusN: agreed, no special thread needed |
| 16:58:20 | amiconn | The USB mode is captured by all threads that have to act on it. The file system doesn't have one |
| 16:58:44 | stripwax | i'll try if i have time, studying for an important exam for tomorrow :-( laters |
| 16:58:47 | LinusN | amiconn: no, i mean handled by the default_handler() |
| 16:59:35 | LinusN | each thread handles the event, but the main thread takes care of the file system remounting |
| 16:59:44 | LinusN | just like usb mode |
| 17:00 |
| 17:00:14 | Zagor | stripwax: ok, it can wait. good luck with your exam. |
| 17:00:22 | stripwax | :-) thx |
| 17:01:22 | Zagor | gotta go. see you all. |
| 17:01:23 | | Part Zagor |
| 17:06:19 | LinusN | gotta go too, cu |
| 17:06:29 | stripwax | yeah me too, bye! |
| 17:06:31 | | Part stripwax |
| 17:06:34 | | Part LinusN |
| 17:08:14 | [IDC]Dragon | amiconn: now that the database dust has settled, about the video speed |
| 17:08:51 | [IDC]Dragon | as of now, the encoder has to know what timing the player can achieve |
| 17:09:36 | [IDC]Dragon | that's why I've put the 11.x MHz in the encoding app, too |
| 17:09:39 | amiconn | The player could achieve about just any timing, with a little trick that came to mind |
| 17:09:55 | [IDC]Dragon | changing the timer on the fly? |
| 17:10:23 | [IDC]Dragon | but first: |
| 17:10:43 | [IDC]Dragon | the cpu cycles have to be an integer multiple of 4 |
| 17:11:03 | [IDC]Dragon | because the prescaler is 4 for the usual framerates |
| 17:11:11 | amiconn | The timer has 2 interrupt sources, GRA and GRB. They could be set to the next-to-lower and next-to-higher integer cycle count of a probably fractional value. |
| 17:11:13 | [IDC]Dragon | the encoder knows that, too |
| 17:11:56 | amiconn | Then the code decides by a ratio count up/down variable which one triggers the next frame |
| 17:12:22 | [IDC]Dragon | GRA and GRB are both available to 1 timer? |
| 17:12:27 | amiconn | yup |
| 17:12:30 | [IDC]Dragon | nice |
| 17:12:44 | [IDC]Dragon | dataseet reading pays off once more |
| 17:12:47 | amiconn | I did use both in my experimental backlight dimming code |
| 17:13:11 | amiconn | (to do software pwm with interrupts - works nicely) |
| 17:13:32 | amiconn | Actually, each timerhas its own GRA and GRB registers |
| 17:13:40 | [IDC]Dragon | then I suggest to expand the video header with one more member: the clock rate this was encoded for |
| 17:13:48 | amiconn | And there are even BRA and BRB registers |
| 17:14:09 | [IDC]Dragon | if zero, we assume 11 MHz |
| 17:14:17 | amiconn | If you expand the header, the format will become incompatible anyway |
| 17:14:46 | [IDC]Dragon | no, there's plenty of unused space, which is guaranteed to be zero |
| 17:15:13 | amiconn | Ah, then it should be possible. Didn't know about that |
| 17:15:40 | [IDC]Dragon | look at tFileHeader.video_reserved[7] |
| 17:15:55 | amiconn | We would not even need GRA and GRB - just set GRA for the next cycle accordingly |
| 17:17:08 | [IDC]Dragon | the math which to use might be tricky |
| 17:17:39 | amiconn | It's actually not very tricky, it's much like the code I use to calculate the grayscale patterns from the brightness |
| 17:18:18 | * | [IDC]Dragon thinks about numerical limits in 32 bit |
| 17:19:26 | | Join mecraw__ [0] (~lmarlow@69.2.235.2) |
| 17:19:38 | amiconn | For converting 11.0592 <-> 12 MHz, this shouldn't be a problem. The ratio is 576 : 625, not too high values |
| 17:20:20 | amiconn | And since the precalculation only has to be done once for the playback, we could even resort to 64 bit maths (gcc does allow this) |
| 17:23:22 | [IDC]Dragon | in addition, don't forget the /4 granularity |
| 17:23:37 | [IDC]Dragon | 64 bit is plenty, agreed |
| 17:24:04 | [IDC]Dragon | I meant th toggle code, that has to run in each frame interrupt |
| 17:24:35 | amiconn | Yes. For the toggle code, 2 values have to be precalculated (a binary fraction) |
| 17:26:04 | amiconn | Then everytime the isr is called, it looks at the ratio counter. If it is >0, it takes the shorter cycle count and subtracts value1, otherwise it takes the longer cycle count and adds value2 |
| 17:26:42 | amiconn | This works much like dual-slope a/d-converters do, and should give plenty of precision |
| 17:27:19 | amiconn | We would need 64-bit maths (if at all) only for precalculating these 2 values |
| 17:27:28 | [IDC]Dragon | ok, fine |
| 17:29:55 | [IDC]Dragon | except, a plugin doen't have these capabilities from the "legal" api |
| 17:29:56 | amiconn | Apart from all that high-end synchronization stuff, the cycle count for typical 67 Hz is around 50000, so simply rounding to integer (+/- .5) gives an error margin of 1E-5, that is around 0.1 s in 3 hours |
| 17:30:45 | [IDC]Dragon | hmm, I started one music clip this morning and had the impression it quickly went out of sync |
| 17:31:25 | [IDC]Dragon | I tried to start it on bot recorder and ondio simultaneously |
| 17:31:30 | amiconn | The legal api would need an additional function to set the cycle count of a registered timer |
| 17:31:34 | [IDC]Dragon | s/bot/both |
| 17:32:34 | [IDC]Dragon | or plugin_register_timer() re-adjusts it, if the callback is the same |
| 17:32:41 | amiconn | Maybe there are other reasons for getting out of sync. Yesterday when I tried a ~4 min music video, it played in sync from start to end. However, later I tried seeking, and then it was *way* out of sync afterwards... |
| 17:33:28 | [IDC]Dragon | seeking should re-sync it |
| 17:33:57 | amiconn | Yes, that's strange |
| 17:34:12 | [IDC]Dragon | but perhaps we should focus on other things first |
| 17:34:31 | [IDC]Dragon | the Ondio won't be a killer video player |
| 17:34:49 | amiconn | Maybe it's the smallest video player... |
| 17:34:55 | [IDC]Dragon | but it's nice to know the MMC keeps up |
| 17:35:20 | [IDC]Dragon | mobilephones qualify for that |
| 17:35:53 | amiconn | Yes, but the mobile phones that play video are heavier. |
| 17:36:20 | amiconn | My mobile phone is the same weight as the Ondio (60 g), but it doesn't play video |
| 17:38:36 | | Join marc77 [0] (~marc@pub212004076150.hfc.datazug.ch) |
| 17:40:46 | [IDC]Dragon | amiconn: did you get my email with the startup dump/restore code? |
| 17:41:03 | * | amiconn looks. |
| 17:41:45 | amiconn | yup, got it |
| 17:42:00 | | Quit dittohead2004 (Read error: 60 (Operation timed out)) |
| 17:42:51 | amiconn | [IDC]Dragon: Strange thing: The latest cvs doesn't seem to cause that flakey MMC access for me any more, even as rombox |
| 17:43:41 | amiconn | (latest == yesterday for that matter) |
| 17:43:45 | [IDC]Dragon | flakey? |
| 17:44:32 | amiconn | Yes, meaning it ceases to work after some (unpredictable) time, usually a couple of minutes, as I described |
| 17:45:17 | [IDC]Dragon | ah, that kind |
| 17:45:43 | [IDC]Dragon | I should *use* the Ondio, for a change |
| 17:46:00 | [IDC]Dragon | on the weekend, I tried for a while |
| 17:46:52 | [IDC]Dragon | after a few minutes, it crashed, with wild characters scrolling in the remains of the wps |
| 17:47:21 | [IDC]Dragon | then it paniced with a stack overflow in the scroll thread |
| 17:47:38 | amiconn | Yes, that's one symptom of what I got. I never got crashes when using the .ajz |
| 17:48:16 | amiconn | Maybe there is a stack overflow somewhere, which is simply not noticed with the other units? |
| 17:48:36 | [IDC]Dragon | we have a debug screen for stack useage |
| 17:49:08 | [IDC]Dragon | while still alife, you can look how far they went, worst case |
| 17:49:18 | [IDC]Dragon | alive |
| 17:49:22 | amiconn | yup. The usb thread often shows 99%, in spite of being the only thread with a larger-than-default stack |
| 17:49:36 | [IDC]Dragon | uh |
| 17:49:54 | amiconn | (This goes for jbr as well) |
| 17:49:59 | [IDC]Dragon | usb sounds like it should have little to do |
| 17:50:29 | amiconn | usb indirectly calls fat_recalc_free() after usb disconnect |
| 17:51:13 | amiconn | That's why it has an increased stack (at least the comment in usb.c says so) |
| 17:52:05 | [IDC]Dragon | ah, I remember |
| 17:52:26 | [IDC]Dragon | still, 99% souds very scary |
| 17:52:33 | [IDC]Dragon | sounds |
| 17:53:33 | [IDC]Dragon | if it doesn't happen with .ajz boot, this rather suggests missing hardware inits |
| 17:59:42 | GarBage | hiya guys, i've done as you suggested and minor-changed the Neuros topic on the NonArchos Wiki |
| 17:59:53 | GarBage | let's see if it please you |
| 18:00 |
| 18:00:30 | [IDC]Dragon | amiconn: OT: my OndioFM build dropped out of the RomBox space today |
| 18:01:13 | amiconn | Uh? Is Ondio FM so much larger than SP? The SP binary is ~154 KB |
| 18:01:25 | [IDC]Dragon | GarBage: nice, thanks for the updated links |
| 18:01:59 | [IDC]Dragon | mainly, the Achos f/w is so much larger |
| 18:02:06 | amiconn | [IDC]Dragon: Did you implement philips tuner handling, or what? |
| 18:02:24 | [IDC]Dragon | haha, no |
| 18:02:54 | [IDC]Dragon | the startup saver pushed it over the ledge, although being small |
| 18:04:35 | [IDC]Dragon | remember it has the same size limit as the FM, and contains code for 1 tuner, too |
| 18:05:44 | amiconn | [IDC]Dragon: Perhaps you can patch archos firmware for SP with the changed MAS mem addresses, and then build an image from that. Should give more room for the 2nd image, but no tuner/ recording support in archos |
| 18:06:07 | [IDC]Dragon | urgh |
| 18:06:37 | [IDC]Dragon | the ugly brother of the FM downflash |
| 18:06:46 | amiconn | Yup |
| 18:06:58 | amiconn | Shouldn't be that hard, actually |
| 18:07:18 | [IDC]Dragon | I'd rather start with mini-emergency-rockbox on the Ondio |
| 18:07:22 | amiconn | Of course only try this if you have uart boot, but then you do... |
| 18:07:37 | [IDC]Dragon | it has definitely no charging issue |
| 18:07:43 | | Join zonk [0] (zazz@dh051-117.chem.sunysb.edu) |
| 18:07:45 | amiconn | Haha, no |
| 18:08:51 | amiconn | But we should solve the RoLo issue with archos fw before (do you experience this too)? |
| 18:09:13 | [IDC]Dragon | I haven't tested enough |
| 18:10:20 | amiconn | It happened for me every time I tried: It loads and shows the selection screen, selecting setting or browser does work. But the contrast is too low, and it freezes when I attempt to play music |
| 18:10:35 | amiconn | (away now) |
| 18:12:05 | [IDC]Dragon | leaving |
| 18:12:08 | | Quit [IDC]Dragon ("CGI:IRC") |
| 18:14:44 | | Join [1]marc77 [0] (~marc@pub212004076150.hfc.datazug.ch) |
| 18:14:45 | | Quit marc77 (Read error: 104 (Connection reset by peer)) |
| 18:14:48 | | Nick [1]marc77 is now known as marc77 (~marc@pub212004076150.hfc.datazug.ch) |
| 18:22:40 | | Join Schoki [0] (minuth@DSL01.212.114.228.23.NEFkom.net) |
| 18:48:26 | | Quit Schoki ("Client Exiting") |
| 18:50:28 | | Quit einhirn (Read error: 54 (Connection reset by peer)) |
| 18:56:21 | *** | Saving seen data "./dancer.seen" |
| 18:59:12 | | Part marc77 ("Cycling Channel") |
| 18:59:13 | | Join marc77 [0] (~marc@pub212004076150.hfc.datazug.ch) |
| 19:00 |
| 19:19:18 | | Join _aLF [0] (~Alexandre@mutualite-3-82-67-66-128.fbx.proxad.net) |
| 19:19:20 | _aLF | hi |
| 19:19:39 | | Join [IDC]Dragon [0] (~idc-drago@pD9FF8C69.dip.t-dialin.net) |
| 19:20:12 | [IDC]Dragon | hi again |
| 19:20:37 | [IDC]Dragon | amiconn: did you perhaps try the startup I/O? |
| 19:50:42 | | Join bagawk [0] (~a78001db@labb.contactor.se) |
| 19:52:33 | | Quit bagawk (Client Quit) |
| 20:00 |
| 20:12:26 | | Part marc77 ("Cycling Channel") |
| 20:12:26 | | Join marc77 [0] (~marc@pub212004076150.hfc.datazug.ch) |
| 20:24:23 | amiconn | (back again) |
| 20:24:43 | amiconn | [IDC]Dragon: No, not yet. As you tried it, did you find something? |
| 20:25:18 | | Part iriver_srn |
| 20:33:44 | [IDC]Dragon | it started "well" in all cases |
| 20:33:52 | [IDC]Dragon | no long term test yes |
| 20:33:55 | [IDC]Dragon | yet |
| 20:34:06 | [IDC]Dragon | gotta leave |
| 20:34:11 | amiconn | Hmm. I tried RoLo into archos fw again |
| 20:34:16 | | Quit [IDC]Dragon () |
| 20:38:06 | | Part GarBage |
| 20:51:17 | | Quit marc77 (" HydraIRC -> http://www.hydrairc.com <- :P") |
| 20:54:14 | | Quit elinenbe (" The IRC Client of the Gods! -> http://www.hydrairc.com <- HydraIRC") |
| 20:56:25 | *** | Saving seen data "./dancer.seen" |
| 21:00 |
| 21:42:11 | | Join scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) |
| 22:00 |
| 22:10:09 | | Quit methangas (" HydraIRC -> http://www.hydrairc.com <- s0 d4Mn l33t |t'z 5c4rY!") |
| 22:23:11 | | Quit _aLF ("Leaving") |
| 22:56:27 | *** | Saving seen data "./dancer.seen" |
| 23:00 |
| 23:22:58 | | Join _Lucretia [0] (~munkee@abyss2.demon.co.uk) |
| 23:24:26 | _Lucretia | Anyone know anything about CalmRisc? |
| 23:24:53 | _Lucretia | it's the CPU inside the MT-500, by the looks of it |
| 23:47:06 | _Lucretia | any idea where to get a hex2bin prog? |
| 23:55:32 | | Join nip_ [0] (~pin@ERR.COS.CS.CMU.EDU) |
| 23:56:05 | | Part nip_ |
| 23:56:13 | | Join nip_ [0] (~pin@ERR.COS.CS.CMU.EDU) |
| 23:56:25 | | Quit nip_ (Client Quit) |
| 23:56:45 | _Lucretia | ? |
icon identifies that the person is a core developer (has commit access).