--- Log for 13.10.104 Server: burroughs.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 8 days and 23 hours ago 00.14.52 # 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 # I have a question for whoever admins the website... 00.22.23 # ok, i'll rephrase :) is there anybody here who can make changes on the website 00.22.27 # ? 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.04.18 Join frsyj [0] (s336156@student.uq.edu.au) 01.05.23 # Does anyone know what causes the message 'Playlist buffer full' to appear whenever I try and play a song in rockbox? 01.10.02 # Your playlist size is too small? 01.15.26 # Can't I just turn it on and press play on a song? 01.15.40 # 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 # 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 # 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 # ok, I'll give it a whirl 01.20.58 # Rockbox 2.2 is way old... 01.24.37 # Can I delete .DS_Store? 01.26.25 # I don't know. .DS_Store is not a rockbox part 01.27.01 # seems like there's a few weird files/directories.. windows must make them? System Volume Information sounds windowsy 01.27.50 # Yes, SVI is windows' system restore folder for that drive 01.28.12 Quit mecraw_ (Read error: 110 (Connection timed out)) 01.29.18 # .DS_Store is MacOS X "folder information" 01.29.59 # Aah.. .Trashes might be from there too.. I deleted it anyway.. 01.30.15 # 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 # Bagder: are you there? 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.19.53 Quit AciD (Read error: 104 (Connection reset by peer)) 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.09.01 Part scott666_ 05.54.35 Quit plok ("I'm outta here!") 06.48.47 Join LinusN [0] (~linus@labb.contactor.se) 06.56.10 *** Saving seen data "./dancer.seen" 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 # Greetings everyone! 07.52.22 # hola 07.53.07 # Okay, tell me how crazy you find this idea: 07.53.55 # Using a stock stereo handsfree and replacing the headphones with a pair from my "old" MDR-70 07.54.21 # 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 # So with MDR70 phones, music will be more enjoyable 07.55.14 # Crazy of brilliant? :) 07.56.13 # silly! :-) 07.59.49 # How come? :) 08.00.37 # I thihk the idea is crazy and cool :) 08.06.53 # maybe i don't get it 08.07.21 # why have MDR70 phones for your cell phone? 08.08.17 # My phone is mp3-capable 08.09.54 # yes, but why not use your archos? 08.10.21 # 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 # Morning 08.35.02 # hi 08.43.53 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 08.56.08 # amiconn: why did you rename default_event_handler? 08.56.12 *** Saving seen data "./dancer.seen" 08.57.03 # oh, my mistake. 08.57.33 # jörg did it 08.57.39 # and he didn't rename it 08.57.59 # amiconn committed it anyway 08.58.10 # oh, my mistake then 08.58.12 # :-) 08.58.56 # i'm not sure i like the solution, but i see the problem he tried to solve 09.00.33 Join kurzhaarrocker [0] (~knoppix@p50877B3E.dip0.t-ipconnect.de) 09.01.33 # * kurzhaarrocker detects fake stop button events 09.02.28 # They occur when the hd is accessed and when my batteries are half drained. 09.03.37 # kurzhaarrocker: are you using the latest version? 09.03.49 # yesterdays daily build 09.04.12 # (flashed but I doubt that that is important) 09.04.17 # interesting 09.05.53 # 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 # we could filter the keys even harder 09.08.08 # i have heard of other guys that still have problens with the keys 09.08.14 # but off is not on an adc 09.08.29 # it's not an adc reading problem 09.08.46 # so how would we filter then? 09.09.12 # my theory is that the increased adc reading rate accentuates the voltage dip problem 09.09.24 # 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 # filter == debounce 09.10.06 # how would debouncing help? it only eliminates repeat events. 09.10.18 # no 09.10.44 # ok you mean filtering out short presses? 09.10.49 # yes 09.11.09 # it's worth a try 09.13.46 # kurzhaarrocker: wanna try it yourself? 09.14.16 # Send it to phil at carangg.de and I will. 09.14.26 # i meant changing the code 09.14.53 # I wished I had the ressources for that. If I had I'd dig into triggered recording update. :( 09.15.11 # ok 09.17.05 # kurzhaarrocker: building... 09.17.21 # i'll try to halve the poll rate 09.17.33 # .. 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 # send it privately, i think. it's not much use in the everyday builds. 09.25.58 # kurzhaarrocker: sent 09.26.13 # <[IDC]Dragon> except for field surveys, but we may not need that 09.29.59 # 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 # 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 # i never touched radio.c. but never mind, just change it. 09.34.28 # 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 # kurzhaarrocker: have you tried with the original firmware? 09.39.48 # not yet 09.39.48 # * kurzhaarrocker tries 09.44.19 # 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 # you seem to have a battery issue 09.53.17 # but rockbox still shouldn't fail on the keys, not when the original doesn't 09.53.38 # 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 # atkbd.c: Keyboard on isa0060/serio0 reports too many keys pressed. 09.53.57 # (my kernel log after my daughter's last attack ;-) 09.54.35 # :) 09.56.10 # 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 # Bagder: wow, a kbd DOS attack 09.57.48 # yeah, she's almost like a script kiddie 09.57.58 # kurzhaarrocker: please run the 1/4 version for a while and let me know if it is ok 09.58.20 # did someone knowingly change the default sound settings away from flat? 09.58.28 # it is running, has accessed the disk a couple of times and stil is running. 09.58.33 # they have never been flat by default 09.58.40 # on the recorder they have 09.58.56 # nope, bass:6 and treble:6 has been the default for ages 09.59.03 # * kurzhaarrocker nods 09.59.28 # my memory is playing tricks on me... 10.01.28 # 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 # how boring 10.08.04 # Apropos batteries loosing capacity: What do you think about adding lowering the minimal capacity setting? 10.08.18 # - adding 10.08.31 # why? 10.08.58 # you really should get new batteries instead 10.09.23 # With batteries that still have > 1000 mAh? What a waste. 10.10.10 # I don't need the extended runtime but I'd enjoy a more precise estimation on the remaining play time. 10.10.21 # do you really get 1100 from them, or is this just the estimate from your external charger? 10.11.05 # The charger measures that by discharging the batteries at 600 mA. I think that makes it pretty realistic. 10.11.06 # i believe the discharge curve changes when the batteries wear out 10.11.46 # so i don't think the rockbox battery time estimation works that well on your batteries anyway 10.12.28 # but what the heck, it's no big deal 10.13.09 # ... and there still are new 1000 mAh batteries availabe - somtimes even very cheap. 10.15.18 # (I believe that you're right about the discharge curve) 10.16.59 # I encountered the first fake stop event with the 1/4 poll build. 10.17.10 Part oxygen77 ("Cho") 10.17.39 # kurzhaarrocker: NICd/NiMH batteries are considered worn out if they only reach ~2/3 of their original capacity 10.17.54 # Then mine are worn out. 10.19.05 # 2nd fake stop event 10.19.06 # * kurzhaarrocker tries the original firmware once more 10.22.51 # hmmm, we don't have to save the SR, MACH and MACL registers in load/store_context() 10.23.28 # in fact, saving SR does more harm than good, since we can't change context with interrupts disabled 10.23.28 # LinusN: Ooops! 10.23.43 # MACL and MACH should be saved... 10.23.45 # original firmware doesn't seem to have any problems. 10.23.54 # amiconn: we don't use the DSP 10.24.19 # kurzhaarrocker: which probably means that they have a lower poll rate 10.24.21 # MACL and MACH are the hardware multiplier registers, and they are definitely used 10.26.01 # We use Multiply And Accumulate? where? 10.26.47 # 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 # amiconn: ah, i see now 10.28.44 # but aren't they scratch registers? 10.28.48 # http://forums.rockbox.org/index.php?topic=40 10.28.52 # funny lcd problem 10.30.46 # With backlight off the 1/4 poll still works. With backlight on stop events occur. 10.31.49 # kurzhaarrocker: time for a battery change? :-) 10.32.52 # But I liked that colour. :´( 10.33.46 # LinusN: Maybe the MAC* registers are considered scratch... 10.33.48 # amiconn: looks like we need to preserve the mac registers 10.34.27 # nah 10.34.35 # only if we compile with -mhitachi 10.34.52 # Iirc ordinary functions do save only r8..r14 10.35.10 # unless you compile with -mhitachi 10.35.27 # r0..r7 and macl/mach are considered scratch, and only saved for interrupt handlers 10.35.31 # and if you compile with -mhitachi, you can use -mnomacsave to still not save the mac regs :-) 10.36.16 # 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 # I'd rather vote for -O2 ... 10.37.07 # <[IDC]Dragon> I though that's the current 10.37.44 # current is -O 10.37.49 # * [IDC]Dragon is concerned about size, not speed 10.38.44 # But if we had more speed we might be able to do ogg decoding 10.38.44 # * kurzhaarrocker runs away 10.38.57 # [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 # [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 # 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 # 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 # Poweroff works fine on Ondio. 10.44.56 # nice 10.45.37 # removing macl/h and sr from the context worked nicely 10.45.53 # I still wonder if it would be even better to fake a real poweroff (the user may continue holding the button) 10.46.12 # 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 # why would the user keep holding the button? 10.47.01 # Ask that user, LinusN 10.47.18 # 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 # 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 # yes 10.48.59 # 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 # but it will power down when the user releases the button 10.51.56 # 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 # i don't think it does any harm 10.52.45 # but he really should release the key 10.53.05 # if the housekeeping takes long, the hardware might shut down 10.53.35 # well people tend to stop pressing buttons as soon as the desired effect has occured 10.53.44 # 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 # in the ondio case, yes 10.54.22 # LinusN: seeing the machine shut down is a massively more convincing reason to stop pressing the button 10.54.31 # i agree 10.54.43 # and in the fm/v2 case, it doesn't matter 10.55.13 # lcd_clear_screen() right before power_off() 10.55.31 # and turn off backlight 10.55.36 # yeah 10.56.05 # also cranking contrast to lightest would be good (as suggested yesterday) 10.56.13 *** Saving seen data "./dancer.seen" 10.56.17 # oh 10.56.26 # Blind users won't notice. Maybe it should say "The unit is now off" :) 10.56.33 # lol 10.56.36 # hehe 10.57.01 # <[IDC]Dragon> kurzhaarrocker: I thought you went away, to implement ogg 10.57.42 # <- must do weird things in java for money. 10.58.16 # <[IDC]Dragon> do it in java then 10.59.02 # Maybe tomorrow afternoon, [IDC]Dragon. 10.59.23 # <[IDC]Dragon> ok, but no later, users are waiting 11.02.20 # 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 # LinusN: Can't do that atm, /me @ work, Ondio @ home... 11.08.45 # sure 11.08.54 # 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 # [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 # 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 # [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 # maybe not, let's see 11.21.10 # it might even look "better", since the screen isn't really clear in a real poweroff situation 11.21.19 # 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 # oh, the ondio doesn't have a contrast setting? 11.22.12 # <[IDC]Dragon> just while playing video, out of keys 11.22.21 # aha...you scared me :-) 11.24.01 # [IDC]Dragon: (2) Using the menu key as shift, then Left or Right. Menu alone will still be the stop seek 11.24.33 # wow, this is good (from the misticriver board): 11.24.34 # hi maties; 11.24.34 # i'm a newb from aus 11.24.34 DBUG Enqueued KICK LinusN 11.24.34 # 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 # totally unreadable for old people like me :-) 11.25.25 # <[IDC]Dragon> you'r no gangsta rapper? 11.25.45 # and he posted again, when nobody answered: 11.25.55 # "n e 1??? 11.25.55 # thanx " 11.26.09 # he haven't even seen it, yet is convinced it's "the best"? people are strange... 11.26.45 # "n e 1???" is 8 chars, "anyone?" is 7 :-) 11.27.19 # hi, people 11.27.22 # hi 11.27.46 # first i'd like to congratulate you on your excellent labour on the rockbox fw 11.27.54 # thanks 11.27.54 # GarBagder - is that you, Bagder? :) 11.28.01 # it's pretty impressive 11.28.11 # kurzhaarrocker : nope 11.28.16 # kurzhaarrocker: lol 11.28.21 # sorry, just kidding, GarBage 11.28.39 # i'm a developer for the open source neuros firwmare 11.28.52 # [IDC]Dragon: Didn't notice... Any idea why that is? 11.29.02 # GarBage: any luck with the compiler yet? 11.29.05 # and i agree on some points you reflected on your website 11.29.24 # 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 # which is bad, i know 11.29.53 Join MisticJeff [0] (~0c68cc30@labb.contactor.se) 11.30.04 # howdy 11.30.07 # yo 11.30.12 # the Texas Instruments compiler evaluation period lasts 90 days 11.30.20 # H340 Intl. Version... 11.30.26 # GarBage: you have to code quickly then ;) 11.30.35 # GarBage: is the mp3 codec source code available? 11.31.08 # USBOTG, 2" Fantastic Color screen, FM Tuner, FM Record, Docking Cradle 11.31.24 # Zagor : i have it, but i'm afraid i cannot disclose it, for patent issues 11.31.35 # i mean, LinusN 11.31.35 # MisticJeff: want, want, want...! :-) 11.31.45 # Is it better than iPod, they both have their moments 11.31.53 # MisticJeff: does it have an RTC? 11.32.09 # GarBage: so nobody can build a neuros firmware but neuros themselves? 11.32.09 # GarBage: so the mp3 codec is not part of the project either? 11.32.10 # Real Time Clock? 11.32.14 # MisticJeff: yes 11.32.37 # nope, there are several unofficial builds on our CVS tree 11.32.39 # I believe so but never have checked 11.32.44 # anyone can compile it 11.33.04 # GarBage: but you have to link the mp3 codec as a binary? 11.33.07 # The US version of the player is one to stay away from however 11.33.17 # Zagor : not at this time, you can use it, but only on binary libs 11.33.25 # MisticJeff: yeah, saw that 11.33.27 # right 11.33.33 # Zagor: check your email 11.34.28 # If you were going to port Rockbox to the H300 platform you'd definitely want the Intl. version 11.34.39 # can you do Ogg, FLAC or any other codec on the archos? 11.34.41 # we will probably need both :-( 11.34.49 # GarBage: not on the archos 11.35.17 # the codec is a dedicated mp3 chip 11.35.53 # so... your're putting your efforts on the iriver platform, now? 11.36.13 # well, we are porting to it 11.36.20 # or rather, i am 11.36.52 # well it's not like you're alone, just because you are the only one with hardware... :) 11.37.01 # :-) 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 # looks like the context switch will be a single MOVEM instruction :-) 11.38.30 # ooh, nice 11.38.46 # GarBage: we are not abandoing archos, we are just expanding our hardware support 11.38.59 # i see 11.39.11 # i'm not saving the DSP registers, since the DSP stuff is likely to be done in a single thread 11.39.52 # you have achieved a lot, given that no help from the manufacturers itself was granted... i'm truly amazed 11.40.03 # thank you 11.40.07 # lots of hard work... 11.40.14 # * Zagor is hungry 11.40.19 # * LinusN too 11.40.20 # lunch time 11.40.23 # yup 11.40.37 # http://www.dosis.uni-dortmund.de/Mensa/ 11.40.48 # GarBage: before we go, did you have a specific thing to discuss? 11.41.25 Part MisticJeff 11.41.27 # well.. the remaks on your webpage about the neuros... they are kinda displicent 11.41.45 # GarBage: please join the wiki and change it yourself 11.41.57 # i was wondering why you have such a bad feeling about it 11.42.40 # nope, i don't want to change anything, just know if there was any reason i should know 11.43.07 # you mean the "big and bulky" remark? 11.43.21 # nope, it is bulky 11.43.37 # just the "adds very little" 11.44.04 # well, what does it add? 11.44.10 # it can do a lot more things, being honest 11.44.52 # such as? 11.45.09 # (hardware wise) 11.45.32 # 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 # 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 # well, and the whole radio broadcasting stuff, just to mention some 11.47.38 # that web page is discussing possible target platforms for Rockbox 11.48.04 # and we really didn't feel that the neuros hardware had that much "extra" to offer 11.48.38 # a GCC port for TI C54x/C55x is on its way, also... but i bet it will take a looong time 11.48.47 # and the TI DSP makes the discussion moot anyway 11.49.19 # is there any progress on the gcc port? 11.49.42 # 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 # i'd really love to see that ported to a GCC target, that will make development much fun 11.49.56 # cu later 11.50.10 # LinusN : see ya 11.50.22 # <[IDC]Dragon> but not with sexiness and openess 11.51.44 # i agree, but i like the added expandability given by the neuros 11.53.39 # 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 # 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 # i agree they made some terribly decissions in the past 11.57.42 # [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.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.07.16 # [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 # 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 # i think i have a good idea regarding the voice mode 13.13.29 # the idea is to implement an "emergency" mode for the blind: 13.14.04 # Bagder: do you feel like hacking up some perl to create id3 indices like we discussed on the list? 13.14.07 # hold Play when you start the player, and rockbox adjusts the settings for voice 13.14.19 # i'll start banging up some browser code in the sim 13.14.37 # resets the buffer sizes, enables voice, resets the language etc 13.15.08 # LinusN: what if there is no .voice file on the disk? 13.15.27 # also, i think we could add a tiny .voice file to the distribution, with one entry: "no voice file" 13.16.13 # ah, neato 13.16.32 # also, the emergency mode could accept any voice file, regardless of language 13.16.49 # first match? 13.17.04 # maybe 13.17.05 # such as novoice.voice ;) 13.17.33 # is it likely that a blind person has two voice files? 13.17.50 # if we ship a minimal default, then yes 13.17.58 # no, i mean two languages 13.18.36 # 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 # if he has, he probably understand both languages 13.18.55 # there can be only one voice per language 13.18.57 # agreed 13.19.44 # but you can fake it by putting Mary in deutsch.voice 13.19.47 # etc 13.19.56 # then you select the voice by changing language :-) 13.20.12 # :) 13.20.48 # you can even have pseudo languages, english_mary.lang/voice 13.20.59 # as long as there is a .lang file 13.21.22 # .lng of cource 13.21.27 # course 13.21.28 # bla 13.27.15 Join iriver_srn [0] (root@lada.kom.auc.dk) 13.29.41 # so it searches for english.voice first (which is the default language) 13.30.09 # if it isn't present, it takes the first match that isn't "no.voice" 13.30.19 # else it takes "no.voice" 13.45.02 Join webguest29 [0] (~8446db96@labb.contactor.se) 13.51.38 # sounds good 13.58.11 Quit webguest29 ("CGI:IRC") 14.26.44 Quit einhirn (Read error: 54 (Connection reset by peer)) 14.45.42 # Zagor: you know/have/use any id3 stuff for perl? 14.45.54 # yeah, hang on 14.46.20 # aw crap, my home box is off. hmm... 14.47.29 # I think it was MP3::Info that I used 14.47.54 # Zagor: what do you think about dave's idea? 14.48.05 # it will take lots of ram 14.48.09 # (single-file database) 14.48.11 # why? 14.48.20 # oh that, well that will "just" be slower 14.48.50 # you mean a lot of seeking? 14.49.20 # yes 14.49.37 # we can open the file twice 14.49.47 # and seek in it with two file handles 14.49.51 # true 14.51.03 # that is possible? 14.51.12 # yes, as long as it's read-only 14.53.55 # i'm not sure using such huge chunks of data as he suggests is good though 14.54.18 # 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 # btw 'libmp3-info-perl' is the name of the debian package 14.56.00 # 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 # 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 # just thought ypu'd like to know... 14.57.05 # you'd 14.57.05 # email in a car...wow... 14.57.10 # lol email 14.57.17 # rockbox? 14.57.30 # :) 14.57.32 # sure, go ahead ;) 14.57.34 # we lack an email client! 14.57.44 # gee, how have we managed? 14.58.00 # iEmail 14.58.03 # isn't there an old saying about all projects evolving to read mail? 14.58.21 # yup, that will be the end of iRiver :-) 14.58.22 # yeps 14.59.01 # "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 # mp3, satellite radio and email in a single chip? 14.59.28 # sounds like an april fools joke 14.59.57 # probably said "device" and got misquoted. 15.00.03 # LinusN: and a bad one! 15.00.10 # wouldn't fool me! ;-) 15.00.34 # * webguest37 imagines sat radio -> mp3 ripper 15.00.47 # like xmpcr 15.00.57 # Zagor: the database could still be one file, pretty much your original idea with all files concatenated 15.01.11 # beats me why, though 15.01.16 # off to work, bye 15.01.20 Quit webguest37 ("CGI:IRC 0.5.4 (2004/01/29)") 15.01.20 # easier to transfer, maybe 15.01.33 # and no opening and reopening of files... 15.01.35 # he cited a worry about only some files being copied 15.01.51 # ...and judging from the problems we've had with people only installing half of rockbox I think he has a point 15.02.10 # indeed 15.02.37 # time for a wiki page, maybe? 15.02.43 # indeed 15.02.52 # * Bagder installed mp3::info 15.03.01 # i'm worried about the parsing of field separators 15.03.10 # tab? 15.03.12 # can take time on large lines 15.03.47 # well we don't want binary data, so there's no other way 15.03.56 # fixed field sizes? 15.04.17 # how many tracks can an album have, then? 15.04.23 # how many songs per year? 15.04.51 # fixed size invites trouble 15.05.07 # i know, then we have to introduce even more offset pointers 15.05.23 # every line can point to the next 15.05.24 # dave has a point though about mixed-artist albums. we need them to show up once for each artist 15.05.36 # we do 15.06.02 # 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 # we do what? 15.06.15 # need to support multi-artists per single album 15.06.22 # yes 15.06.26 # at least I think we want that... don't we? ;) 15.06.31 # i want it 15.06.39 # i have lots of compilations 15.06.40 # I'll demand it! ;-) 15.07.00 # i was referring to only showing one artist's tracks 15.07.14 # so, we want a database format with as painless parsing as possible 15.07.26 # (short rows) 15.07.35 # short rows does not mean painless parsing 15.07.57 # no, but it could mean less items to parse 15.08.11 # quite the opposite if you have to skip a lot of lines to get to the next logical item 15.08.21 # like, for instance, his idea of combining albums and song in one line 15.08.43 # [IDC]Dragon: r u there? 15.08.48 # 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 # thus having to fill the cache with unused data 15.09.44 # yup 15.09.51 # read his new post 15.10.21 # still bad, he mixes filename with song title 15.10.46 # i want a raw filename table first 15.10.47 # * Zagor calls for dave over the subetheral channel 15.11.32 # daaaaaave! 15.11.32 # also quotes are no good separators, lots of song names contain quotes. tabs are probably best 15.11.47 # ack 15.12.02 # or slashes or newlines 15.12.10 # seldomly used in filenames 15.12.31 # hm, no slashes are often used in tracks/artists 15.12.34 # filenames no, but song titles are pretty random in what they use. slashes are probably well used. 15.12.47 # i've never seen a song name with tab though :) 15.12.57 # ..or another <32 char 15.13.07 # or > 240 15.13.09 # ;-) 15.13.36 # >240 is dangerous since some people are using utf-8 in their tags 15.13.37 # tab is nice, it's still editable in a text editor 15.13.49 # 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 # veeeery tricky perl ;-) 15.14.02 # welcome dave 15.14.03 # welcome dave! 15.14.07 # howdy 15.14.08 # welcome dave! 15.14.12 # :-) 15.14.14 # * Bagder joins in 15.14.25 # we don't want to mix filenames and song names. filename is technical data which is not needed for browsing. 15.14.49 # we still need a "raw" filename table 15.14.52 # separate index mapping Song Name to filename. Cannot do vice-versa since not all tracks will have valid tags 15.15.27 # 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 # i think we basically agree, we just need to solve the mixed-artist album thing 15.15.57 # did you read my latest email 15.15.58 # the file name is only interesting when we want to load the actial file 15.15.59 # yes 15.16.14 # (i haven't received a copy from the server yet) 15.16.32 # 600 outgoing mails take a while at times ;-) 15.16.36 # :-) 15.16.41 # 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 # maybe map artists to individual songs then. or separate the "album names" from the "album name->songs" mappings? 15.18.29 # the general idea is to have lots of single mappings 15.18.52 # that's why we opted for several fils in the first place 15.19.02 # iRiver maps artists to individual songs 15.19.31 # 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 # agreed 15.19.40 # 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 # (anyone with an ipod here?) 15.20.07 # * LinusN shivers 15.20.09 # browse screens shows a selection of "Artist","Album","Genre","Song Title" or 'Directory Structure'. 15.20.51 # when you browse into an artist, do you get a list of albums or songs? 15.21.07 # 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 # two seconds.. .let me just turn on my iriver... 15.21.41 # my idea was to show a list of albums when you select an artist, including a pseudo album called 15.22.14 # and in this list we would also include compilations 15.22.15 # iriver takes ages to boot because it loads the entire db on startup ... yawn ...zzzz 15.22.24 # how silly 15.22.37 # we won't do that. we'll be very fast since we want it to work on our 12MHz archoses too... 15.22.55 # linusn- no because compilation is not by a single artist 15.22.57 # ok i'm wrong 15.22.58 # with 2Mb RAM 15.23.13 # selecting artist shows albums 15.23.21 # stripwax: right, but it could list all the album the artist is featured on 15.23.39 # maybe with an (F) prepended or something 15.23.44 # F? 15.23.48 # Featured 15.23.53 # 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 # right, that's what I expected 15.24.18 # it means we need to add a filter in the browser right away 15.24.36 # selecting album shows a list of all artists featured on that album... 15.24.42 # but we'll want that anyway (for year and genre), so it's not a problem 15.24.48 # (followed by tracks on that album) 15.25.13 # stripwax: so an album shows both all artists and all tracks? 15.25.18 # genre->artist->album->track 15.25.51 # album shows all artists first. selecting an artist from the new menu shows all tracks, by that artist, on that album 15.26.26 # i.e. album->artists->tracks on album by that artist 15.26.30 # but can't you browse into a mixed-artist album and play all tracks from start to finish? 15.26.45 # 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 # aha, "clear filter" 15.27.27 # re the parsing: each field could have a size field, to make the parsing/reading easier 15.28.10 # so you won't have to search for the delimiter 15.28.11 # LinusN: yeah, that'd work. then we could use binary data to avoid all the atoi()s 15.28.22 # probably 15.28.24 # 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 # definitely make the db file binary!! 15.29.00 # why is it that important? 15.29.17 # i'd say the opposite 15.29.39 # binary data is often evil 15.29.53 # 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 # hellishly difficult to debug user problems 15.30.08 # I think I favour binary here 15.30.12 # i agree binary data is often evil. the obvious format to use if of course xml. 15.30.22 # but for embedded devices binary is often best 15.30.26 # xml obvious? 15.30.33 # [IDC]Dragon: Got my remarks concerning video sync? 15.30.41 # we're obviously from different cultures. :-) 15.30.47 # i think we can't avoid binary data here 15.30.59 # of couse xml is obvious - we're representing structured data in textual format 15.30.59 # no, I agree binary is best for this 15.31.14 # well let's not go into the xml issue more than "i don't agree" 15.31.15 # 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 # ok, so the file could contain this: 15.32.05 # 1) an index table for all the sub-tables 15.32.07 # [IDC]Dragon: yes. 15.32.19 # 2) a "raw" file name table 15.32.31 # 3) the rest of the single-map tables 15.33.11 # 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 # and references are made using file offsets 15.33.29 # 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 # 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 # [IDC]Dragon: well on what level do you mean? I know some sql... 15.34.31 # dragon - yes. are you suggesting we use a relational database within rockbox just to store tag info? 15.34.39 # 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 # 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 # [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 # Zagor: Yes I remember. But for those it doesn't matter whether you use 1 or 2 files either 15.36.04 # 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 # 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 # dragon - that would eat battery 15.37.17 # basically the system we propose is like that, with sorted indices for each data table 15.37.23 # exactly 15.37.35 # lots of sorted tables 15.37.38 # yes 15.37.57 # <[IDC]Dragon> stripwax: only during the lookup, how often are you doing that? 15.38.12 # and we can reduce the seeking by opening the database with several file handles 15.38.21 # ok, recursive id3 scanner in perl works 15.38.31 # Bagder: goodie 15.38.59 # Zagor: Hence I suggested the index is *automatically* rebuilt if it is older (or not present, of course) 15.39.00 # would the tag db on rockbox allow us to playlist say, everything by this artists, everything from 1995, etc ? 15.39.23 # tools/songdb.pl committed 15.39.57 # stripwax: yes 15.40.00 # stripwax: absolutely 15.40.03 # amiconn if it's all in one file, there's nothing to rebuild 15.40.27 # building it on the player will be painful, at least on archos players 15.40.36 # better to do it on the pc 15.40.52 # full ack 15.41.01 # <[IDC]Dragon> for die-hard users, it could be a plugin 15.41.19 # for die-batteries users you mean? :-) 15.41.25 # :) 15.41.25 # :-D 15.41.31 # <[IDC]Dragon> the query will hopefully be a plugin, too? 15.41.45 # no, it will be core code 15.41.48 # the browser should be integrated 15.41.58 # just as the directory browser is 15.42.01 # definitely 15.42.01 # <[IDC]Dragon> bye, bye Rombox 15.42.08 # ? 15.42.10 # maybe the playlist-from-query could be a plugin 15.42.12 # rombox is not a goal in itself 15.42.18 # <[IDC]Dragon> I know 15.42.39 # 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 # 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 # exactly 15.43.51 # yes 15.43.52 # <[IDC]Dragon> carry on please 15.44.10 # so, each field has a size 15.44.19 # for easy searching/reading 15.44.25 # binary 15.44.26 # ok so we need reverse lookup tables too, song->artist, song->album and album->artist 15.44.35 # keep'em'coming 15.44.41 # loadza tables 15.44.46 # zagor do we? that's just in the tag, right? 15.45.07 # then we would have to *search* in the database 15.45.11 # yes but we don't have the full tag when we browse. that's why we need indices 15.45.28 # album->artist doesn't really work, it would be album to artistS. 15.45.55 # we need those reverse lookups to for example filter out a single artist in a mixed-artist album 15.45.56 # right 15.46.15 # are we now suggesting a table mapping the cross-product of all tags? genre->years; artist->genres .. .? 15.46.22 # I don't think we need album->artist anyway, not sure what we'd use it for 15.46.38 # no, all tags are not filters 15.47.03 # * LinusN gets some more coffee 15.47.05 # basically, we have three "base" tags: artist, album, song. then we have filters: year, genre 15.47.24 # why is genre a filter, not a "base" tag? 15.47.30 # browsing into year 2003 will get you a list of artists with songs from that year 15.47.48 # why not a list of albums? 15.47.52 # because genre is unfortunately so abused it's mostly worthless 15.48.17 # zagor i tag my own music, so i would use this 15.48.18 # you get a list of albums by selecting 15.48.43 # 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 # but if genre is bad, the user just wouldn't use it, right? 15.49.25 # exactly. thus it's a filter and not a "hierarchy" tag 15.49.33 # am I making any sense? :) 15.49.41 # you were... "hierarchy tag"???? 15.50.02 # think of the tags as a tree 15.50.18 # well my idea is that artist, album and song are "hierarchy" tags. those are the three levels of the browsing hierarchy 15.50.41 # year and genre are more like attributes 15.50.43 # browsing for example year 2003 will browse artists, but with a "year 2003" filter added 15.50.43 # why not the starting points for browsing? album->artist(s), artist->album(s), ... 15.50.57 # it will be, in the user interface 15.51.24 # 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 # so i'm not sure where the hiearchy thing comes from, if the user interface is effectively flat 15.52.07 # ok, so in one direction, yes, artist->album->song makes sense 15.52.11 # well it's not really flat, you just enter it at different points 15.52.15 # ok 15.53.24 # entering at "Albums" gives you all the albums in the database, while going through "Artists->Abba" will show only abbas albums 15.53.39 # 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 # I believe it will make browsing more friendly. there are a *lot* of albums released in a year 15.54.35 # my music collection has more artists than albums ..... 15.55.06 # ? 15.55.09 # anyway, having the option of selecting artist or is a nice feature i think. i'd want it. 15.55.09 # even if you count the compilations? how? 15.55.46 # let's focus on the database format 15.56.01 # I need to go, but my embryo tool can already work for some test shots for db format 15.56.08 # Bagder: thanks 15.56.21 # ? 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 # Bagder: u r00l 15.56.28 # badger, thx!! 15.57.12 # stripwax: then don't look at the list of artists, just select 15.57.36 # zagor exactly, it's an extra step... how does that make browsing more friendly? 15.57.38 # but I think your collection is perhaps not the normal case. I think many people have >1 album/artist 15.57.58 # it's just an example... (i'm sure my collection isn't really like that) 15.58.26 # what would be the typical use case for year browsing? 15.58.37 # 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 # if we make it simple to skip past it, it will not be a nuisance 15.59.18 # 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 # yeah, an attribute 15.59.53 # stripwax: that's why I want it as a filter and not part of the "tree" 15.59.56 # 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.13 Join elinenbe [0] (~elinenbe_@65.115.46.225) 16.00.19 # ok cool. 16.00.37 # so, back to the database 16.00.56 # i like the idea of having a "main index" 16.01.17 # so we can add "top entries" without changing the code 16.01.38 # yes 16.02.12 # top entries? 16.02.17 # we need to store as little as possible in ram 16.02.39 # top entries == the browser starting points 16.02.41 # "TITLE"->offset; "ARTISTS"->offset etc 16.02.45 # ah 16.02.48 # "artist", "album" etc 16.04.25 # we might want several versions of each table, sorted in different ways 16.04.51 # i don't think many people want different sorting actually 16.05.17 # linusn- for example? 16.05.23 # album-by-year, album-by-artist 16.05.58 # ok. i consider those different tables, not different sorting 16.06.02 # ah ok. me too 16.06.07 # ok 16.06.32 # the mapping is the same, just sorted differently 16.07.44 # 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 # but i guess a list of random album names, invisibly sorted by artis would be quite confusing :-) 16.08.01 # quite :) 16.08.30 # let's drop the sorting for now 16.09.24 # so, the browser loads a table by filling a buffer with the tag strings, and a table with the offsets 16.10.09 # it must also load the text table of whatever the offsets point to... 16.10.22 # not until you select an entry 16.10.29 # yes 16.11.52 # but we'll need to load the filter tables too, song->year etc. 16.11.53 # this all sounds really cool... keep up the shizzyness! 16.13.06 # you don't need the filter tables too, do you? 16.13.26 # you either use an unfiltered table, or you use a filtered one 16.13.36 # loadza tables... 16.13.39 # linusn - ok, suppose the user browses by clicking on 'Genres'. What actually gets loaded? 16.14.19 # the artist-filtered-by-genre table? 16.14.35 # you mean filtered or sorted? 16.14.43 # LinusN: uh, we can't really created pre-filtered tables can we? 1993->abba, 1994->abba, 1993->aha, 1994->aha.... 16.14.56 # hmmm, maybe not 16.16.18 # 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 # 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 # 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 # example: if we sort by year, we can just use a specific range of the table 16.20.37 # that way we can use the sorting as a filter 16.21.52 # that's what i said; 16.22.44 # although we'd need another table to find that range ! :-) 16.23.26 # (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 # 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 # One thought - it won't allow us to filter by year AND genre :-) 16.26.53 # (by the way, that was a joke. would anyone use such a feature?) 16.27.22 # all the Folk songs released in 1968, yeah, why not? :-) 16.30.16 # 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 # (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 # we need to break this down into manageable parts, so we can implement it in steps 16.32.22 # a wiki page for the database format is a good start 16.34.47 # 5 tags used means 25 cross-reference tables :) 16.36.31 # 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 # 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 # for the ondio flash volumes? 16.43.14 # 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 # yup. For MMC, changeable media support is necessary (otherwise rockbox might get very confused) 16.43.54 # i imagine a unix-style virtual file system 16.44.03 # amiconn: do we need multi volume? can we access both cards at once? 16.44.06 # 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 # Zagor: Yes, technically it is possible, and prepared in my driver. The debug info screen already uses that 16.44.45 # we could even support multiple partitions 16.45.43 # well then we just need to add drive/partition info to struct fat_file 16.45.44 # 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 # duplicate fat:fat_bpb and fat_cache 16.46.57 # 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 # *changeable 16.47.34 # do we really need true hotplugging? 16.47.49 # i'd go for a "safe eject" approach 16.48.24 # but it would probably be similar to USB mode 16.48.33 # which is pretty "hot" today 16.48.34 # I'd go for true hotplugging. You can't stop a user from removing the card at any time 16.48.59 # how do we discover the card is removed? 16.49.06 # an event 16.49.23 # just like USB_INSERTED 16.49.27 # 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 # well it's a simple thing to go through all open files and close those on that disk 16.49.45 # amiconn: that's what i mean with "unix-like" 16.50.08 # can you do that without making tree.c ugly? 16.50.28 # tree.c wouldn't have to know 16.50.31 # 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 # LinusN: who adds /mmc to root dir then? 16.50.47 # the file system code 16.50.51 # bleach, no way 16.50.58 # tree.c must be informed about disk changes, to re-read dirs 16.51.05 # file system does not now about partitions, and should not 16.51.21 # Zagor: i mean file.c and disk.c 16.51.39 # I know, and still disagree. they don't need to be changed at all for this. keep them pure. 16.52.15 # if we don't implement it there, we would have to duplicate the volume awareness everywhere 16.52.34 # in the playlist code, the plugins, etc 16.53.20 # a virtual file system makes it transparent 16.53.34 # Iiuc, the fat driver has to be duplicated. Or do I miss the point here? 16.53.38 # LinusN: you're right 16.53.48 # amiconn: no, just two variables in it 16.54.37 # Doesn't it have to handle 2 fats? How does it distinguish them? The FATs are cached (partially), aren't they? 16.54.54 # It may well be one fs is FAT16 and the other FAT32 16.55.04 # amiconn: the fat cache is one of the two variables to duplicate. the bpb is the other. 16.55.31 # (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 # Does the file system need a thread and a queue to capture the insert/ remove events? 16.57.07 # 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 # amiconn: i think it can be handled like the USB mode 16.57.51 # stripwax: go ahead if you feel like it. i'll be away tonight. 16.57.58 # me too 16.58.16 # LinusN: agreed, no special thread needed 16.58.20 # The USB mode is captured by all threads that have to act on it. The file system doesn't have one 16.58.44 # i'll try if i have time, studying for an important exam for tomorrow :-( laters 16.58.47 # amiconn: no, i mean handled by the default_handler() 16.59.35 # each thread handles the event, but the main thread takes care of the file system remounting 16.59.44 # just like usb mode 17.00.14 # stripwax: ok, it can wait. good luck with your exam. 17.00.22 # :-) thx 17.01.22 # gotta go. see you all. 17.01.23 Part Zagor 17.06.19 # gotta go too, cu 17.06.29 # 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 # 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 # 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 # 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 # yup 17.12.30 # <[IDC]Dragon> nice 17.12.44 # <[IDC]Dragon> dataseet reading pays off once more 17.12.47 # I did use both in my experimental backlight dimming code 17.13.11 # (to do software pwm with interrupts - works nicely) 17.13.32 # 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 # And there are even BRA and BRB registers 17.14.09 # <[IDC]Dragon> if zero, we assume 11 MHz 17.14.17 # 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 # 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 # 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 # 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 # For converting 11.0592 <-> 12 MHz, this shouldn't be a problem. The ratio is 576 : 625, not too high values 17.20.20 # 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 # Yes. For the toggle code, 2 values have to be precalculated (a binary fraction) 17.26.04 # 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 # This works much like dual-slope a/d-converters do, and should give plenty of precision 17.27.19 # 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 # 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 # 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 # 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 # 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 # 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 # Yes, but the mobile phones that play video are heavier. 17.36.20 # 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 # yup, got it 17.42.00 Quit dittohead2004 (Read error: 60 (Operation timed out)) 17.42.51 # [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 # (latest == yesterday for that matter) 17.43.45 # <[IDC]Dragon> flakey? 17.44.32 # 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 # Yes, that's one symptom of what I got. I never got crashes when using the .ajz 17.48.16 # 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 # 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 # (This goes for jbr as well) 17.49.59 # <[IDC]Dragon> usb sounds like it should have little to do 17.50.29 # usb indirectly calls fat_recalc_free() after usb disconnect 17.51.13 # 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 # hiya guys, i've done as you suggested and minor-changed the Neuros topic on the NonArchos Wiki 17.59.53 # let's see if it please you 18.00.30 # <[IDC]Dragon> amiconn: OT: my OndioFM build dropped out of the RomBox space today 18.01.13 # 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 # [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 # [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 # Yup 18.06.58 # 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 # 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 # Haha, no 18.08.51 # 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 # 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 # (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.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.12.26 Part marc77 ("Cycling Channel") 20.12.26 Join marc77 [0] (~marc@pub212004076150.hfc.datazug.ch) 20.24.23 # (back again) 20.24.43 # [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 # 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.42.11 Join scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com) 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.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> ?