--- Log for 09.08.107 Server: niven.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 6 days and 12 hours ago 00.00.30 # DerPapst: BoS 00.00.56 # heh.. to get Microsoft sam say "Plugins" i have to enter "Plugkins" :D 00.01.02 # does anyone want an extra setting that says "voice time as?" or just use the one that is called "time format" 00.01.20 # markun: isn't that because rockbox already sounds like a bos? 00.01.21 # ddalton: I think you should go with the existing setting 00.01.48 # markun: how is the GSoC tts thing coming along? 00.01.56 # n1s: pretty bad 00.02.00 # ddalton: I think it should just follow the regular time format. Even though I'd probably set it to 24 for display and 12 hour for speech if I had the option, I don't think it's necessary to add an option. 00.02.07 Quit matsl (Remote closed the connection) 00.02.13 # what is TTSbox using btw? flite or espeak? 00.02.14 # n1s: today I got an email that he has even less time 00.02.17 # flite 00.02.29 # Does anyone else find that if they set a background by browsing a file that it doesn't remain after rockbox is rebooted? 00.02.42 Join My_Sic [0] (n=MySic@mur31-1-82-237-204-133.fbx.proxad.net) 00.02.42 # I wanted to use espeak, but I figured it was his choice 00.02.46 # markun: ah, too bad, it would have been a very nice feature 00.03.00 # n1s: maybe I'll do a espeak por 00.03.02 # t 00.03.11 # what does that text to speech project actually involve? 00.03.14 # but it requires quite some changes 00.03.22 # integerizing the engine or mostly porting it to rockbox? 00.03.28 # markun: how does espeak compare to flite in quality? 00.03.40 # saratoga: so far it was just turning flite into a rockbox plugin 00.03.59 # so what is better then when espeak sounds like a BoS how does flite sound compared to this... even worse? 00.04.16 # n1s: flite uses real voice samples, espeak is synthesized form formants mixed with samples 00.04.43 # jhMikeS: think i've got something now 00.04.44 # s/form/from/ 00.04.48 # ok I can add that later then but when I put this one up it will just use the setting there now. 00.04.51 # jhMikeS: will be sure to report success tomorrow :P 00.05.36 # Bagder: committed, yell at me if things catch fire 00.05.37 # preglow: what does a "vinyl amp" do? 00.05.42 # DerPapst: I think it's a taste thing. I prefer espeak, but other people prefer flite 00.05.43 # ddalton: I think you should actually avoid adding another setting, too many settings is not good 00.05.52 Quit sneakums (Remote closed the connection) 00.06.06 # jhMikeS: just do the inverse of the vinyl cutting process, apply an inverse riaa eq filter and gain 00.06.19 Join sneakums [0] (n=sneakums@jenny.ondioline.org) 00.07.11 # jhMikeS: i've got an amp here that only has line ins, so i'd need a vinyl amp to connect my vinyl deck to it 00.07.12 # preglow: what are you working on? turning rockox into a phono amp? 00.07.14 # to play phonograph records through the DAP? *l* 00.07.16 # markun: yeap 00.07.27 # :) 00.07.28 Quit robin0800 (Read error: 110 (Connection timed out)) 00.07.28 Nick robin_0800 is now known as robin0800 (n=robin080@cpc3-brig8-0-0-cust132.brig.cable.ntl.com) 00.07.29 # jhMikeS: vinyl deck -> h120 -> line in 00.07.56 Join dup [0] (i=d9b95459@gateway/web/cgi-irc/labb.contactor.se/x-a85fbaf1ff42d505) 00.08.04 # work on something for wax cylinders too...I'm really into that ;) 00.09.29 # haha 00.09.52 # wow... at&t sounds really awesome copared to everything else i've heared so far 00.10.04 # *compared 00.10.13 # Hello. I observe the following on my H120 with r14246: when I activate the option "directory cache" (it was disabled before) I get "Please reboot to enable". After rebooting, the disc is spinning and but the end, the message "Filetype buffer full" is shortly displayed. Any ideas? 00.10.36 # dup: Ignore it, for now. 00.10.56 # Llorean: so there is no error and it's harmless? 00.11.36 # It depends. It affects viewers.config, the last file type (or last few) will not work in it. 00.12.53 # Ok. Also, the shortcuts pluging doesn't work for me, But it's the last entry in the viewers.config, so it's probably related to your last post 00.13.20 # hrm 00.13.25 # what's the max gain of the line in port? 00.14.07 # When I select a dir and choose "Add to shortcuts" from the context menu, nothing happens. The .link file doesn't get cretated. 00.14.43 # It should be created in the root folder, right? 00.14.59 # preglow: 24dB? 00.15.15 # that is before using the decimator 00.15.27 # total is 48dB iirc 00.15.48 # Bagder: Could the voice creation be done in mingw32 with some changes? (I'm not familiar with its limitations at all) 00.15.53 # wow.. at&t german is even better than the english version o.O 00.16.16 # petur: should do nicely for me, then 00.16.19 # Llorean: it probably can, I'm not that familiar with that setup either 00.17.29 Part brent0n 00.17.47 # * petur gets another file type array full splash and wonders what got added 00.18.26 # petur: I have "link" at the end 00.19.31 # let's increase the array then... 00.20.16 # * n1s votes for most useless comment of the day, http://www.rockbox.org/tracker/task/7562 00.20.24 Join robin_0800 [0] (n=robin080@cpc3-brig8-0-0-cust132.brig.cable.ntl.com) 00.20.31 # petur: can't it be increased automatically? E.g. by defining some "end marker" constant and using it as the array size? 00.20.33 Quit sneakums (Remote closed the connection) 00.20.53 Quit saratoga ("CGI:IRC (Ping timeout)") 00.20.55 # dup: it's not that the list grows every day 00.21.13 # but every 2 it seems :P 00.21.21 # Bagder: I imagine that'd be a more flexible solution for users of screen readers, though I don't really know. 00.21.40 Join haemmy [0] (n=stefan@194.208.162.140) 00.21.43 Part n1s 00.21.47 # petur: "petur gets _another_ file type..." (c) petur ;-) 00.21.49 # yeah, since the biggest hurdle for them with cygwin is their terrible install thing 00.22.30 # would anyone think a vinyl amp plugin worth commiting? :> 00.23.02 # preglow: I think a lot of people would love to see *any* DSP plugin, just as a sample of how it can be done 00.23.03 # * DerPapst wonders what that could be... 00.23.34 # Bagder: Was it pondlife working on getting it working in cygwin? 00.23.42 # yes 00.24.02 # does the "filetype array full" also come on non sw-codec players? 00.24.03 # I wonder if he'd be willing to give it a shot. I neither speak shell nor know how to talk to TTS in Windows at all. :) 00.24.19 # In settings.h there is a variable called timeformat can I do this in main_menu.c? if (timeformat ==1) 00.24.34 # Llorean: then jhMikeS should definitely commit his ringmod code 00.24.35 # petur: I'm kinda surprised we even get that. I rather imagined it could be allocated at boot. 00.25.11 Join sneakums [0] (n=sneakums@jenny.ondioline.org) 00.25.37 # not worth it. Whoever adds something should check this 00.25.56 Quit Soul-Slaye1 ("Leaving.") 00.25.57 # Has anybody (successfuly) used the shortcuts plugin? 00.26.28 # petur: put this as a comment into the viewers.config? 00.26.31 # dup: Many people have. It was tested after all 00.26.56 # be patient I'll commit after testing 00.27.10 Join maffe [0] (n=maffe@barmen.interhost.no) 00.27.12 # * Llorean definitely prefers espeak of the three options 00.27.14 # Llorean: yes, that I also have assumed. But somehow I fail to create the shortcuts file :-/ 00.27.57 # ddalton: if ( global_settings.timeformat ) 00.28.39 # Llorean: do you know if flite is compiled to use the 8kHz or the 16kHz voice? 00.28.42 # Llorean: what file should I look for? 00.28.43 # ddalton: if that's true, then you have 12-hour clock. Alternatively, global_settings.timeformat can be either 0 or 1 for 24 or 12-hour clock respectively 00.29.49 Quit Rick ("I… don't need to be here.") 00.29.51 # good n ight everyone :) 00.29.51 # markun: How can I check? Though it's partially how words are pronounced too. 00.29.55 Quit DerPapst ("So Long And Thanks For All The Fish!") 00.30.02 # markun: "* Link flite(1) with 16bit voice by default"? 00.30.16 # thanks I will give that a go. 00.30.17 # (in debian.changelog.gz) 00.30.51 Quit wippeout ("leaving") 00.30.56 # ok test voice built fine with script 00.31.07 # updated daily build script for tomorrow's build 00.31.38 # And I didn't even need to use my complimentary "oops" commit. 00.31.43 # hehe 00.32.01 # don't let me spoil the fun! 00.32.14 Join iamben [0] (n=ben@67.142.179.38) 00.34.46 # dup: new build to test in 3 minutes.... 00.35.08 # shortcuts creation and usage works fine here now 00.35.38 # petur: Now? So the fix also fixes this and not only the message? 00.36.28 # the message was an indication that ther was a problem 00.36.36 # +e 00.37.21 Quit miepchen^schlaf (Read error: 104 (Connection reset by peer)) 00.37.25 # Wow! Cool countdown on the build page! 00.37.38 Join aowzone [0] (i=aowzone@c-68-51-107-246.hsd1.in.comcast.net) 00.37.43 Quit robin0800 (Read error: 110 (Connection timed out)) 00.37.43 Nick robin_0800 is now known as robin0800 (n=robin080@cpc3-brig8-0-0-cust132.brig.cable.ntl.com) 00.37.47 # dup: try now 00.37.49 Quit sneakums (Remote closed the connection) 00.37.53 Join sneakums [0] (i=sneakums@jenny.ondioline.org) 00.38.14 # hey guys...im looking for some help...last weekend i taped a show, and ran out of battery about 3/4 of the way through the set...i have a partial wav file, but i cant seem to open it...i thought i read something about reparing this sort of thing once or was i imagining it? 00.38.30 # rasher: I maybe I was confusing bit with hz :) 00.38.45 # anyway, time for some sleep 00.38.59 # aowzone: somebody at taperssection.com has written a tool to repair them 00.39.17 # let me find the thread 00.39.20 # damn...tahts where it saw it! it wasnt at rockbox! 00.39.31 # haha i was tearing apart the wiki...i shoulda know it was TS 00.39.33 # 00.39.45 # thanks petur...perhaps yuo know better what to look for, could you link me? 00.40.04 Quit ompaul ("Leaving") 00.41.52 Quit ctaylorr (Read error: 110 (Connection timed out)) 00.44.08 Quit obo ("bye") 00.44.45 # aowzone: http://taperssection.com/index.php/topic,72936.0i.html 00.45.14 # I always see that link, and when you search for it you can't find it :) 00.45.42 # thank you! 00.46.13 Join ctaylorr [0] (n=ctaylorr@CPE001839ae25b4-CM0011aea4a276.cpe.net.cable.rogers.com) 00.48.49 # damn...failed to read header from wav file 00.49.42 # aowzone: you can always import it as raw data in an audio editor 00.49.43 Join pixelma_ [0] (i=pixelma@rockbox/staff/pixelma) 00.49.52 # i think i tried that too...let me try again 00.50.54 # yeah, soundforge 9 wont open it either 00.51.25 # you managed to copy the file to pc? 00.51.39 # nope 00.51.41 # shouldn't have rockbox shutdown properly the device before shutting down from low battery? 00.51.41 Quit pixelma (Nick collision from services.) 00.51.41 Nick pixelma_ is now known as pixelma (i=pixelma@rockbox/staff/pixelma) 00.51.49 # it should have Xavier...but apparently didnt 00.52.00 # interesting... 00.52.03 # its a 400 something mb file...so it recorded something and tried to save it 00.52.09 # aowzone: then run a chkdsk /f on the drive first 00.52.16 # ok petur i will do that! 00.52.53 # convert lost chains to files? 00.52.59 # XavierGr: there are obviously still issues when recording and encountering low batt or disk full 00.53.00 Quit haemmy () 00.53.17 # aowzone: yes 00.53.28 # ok, done 00.53.30 # let me try now 00.53.30 # pitty that we can't say that it's completely secure 00.53.35 # petur: Well, there's always a point where the battery is too low to spin up the disk again. 00.53.48 Join saratoga [0] (i=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-9213dde2b9867323) 00.54.03 Join BigMac [0] (n=BigMac@c-71-234-95-131.hsd1.ct.comcast.net) 00.54.12 # Llorean: I thought that Rockbox was programmed to shut down before that happens 00.54.30 # though with worse batteries it can come quickly 00.54.37 # Existing header data. Look for the words 'RIFF', 'WAVE', 'fmt', 00.54.37 # or 'data' to see if this is even a somewhat valid WAVE header: 00.54.37 # 00000000: 52 49 46 46 00 00 00 00 57 41 56 45 66 6D 74 20 RIFF....WAVEfmt 00.54.37 DBUG Enqueued KICK aowzone 00.54.37 # 00000010: 10 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................ 00.54.37 # 00000020: 00 00 10 00 64 61 74 61 00 00 00 00 ....data.... 00.54.41 # thats what i get after a fixwav 00.55.00 # XavierGr: And you can have a significant amount of time during playback left, even if the battery is too low for a future upcoming spinup. 00.55.12 # aowzone: Please don't make large pastes to the channel 00.55.17 # sorry 00.55.30 # aowzone: that's ok, it is just that the length isn't filled in 00.55.36 # Llorean: yes it can be another 30 minutes on some occasions 00.55.38 # ok, how do i fill that? 00.55.46 # the repair tool can't handle that? 00.55.52 # ah, i shouldnt have exited 00.55.54 # i think i see now 00.56.00 # petur: thanks. Everything works now. Except one thing: my link file contains only one entry but when I select ("play") the file this one entry is displayed. But maybe the pluging works this way now. I've read that in this case it should directly go to the dir. 00.56.03 Quit sneakums (Nick collision from services.) 00.56.14 # XavierGr: Perhaps recording, though, should be more conservative on when it chooses to shut down (if this is possible) 00.56.31 # dup: with only one link it also shows the link here 00.56.40 # maybe a bug? 00.56.42 # petur, dup: Is this the main link file, or an arbitrary other one? 00.56.48 # wow! it worked!!! 00.56.50 # thanks petur!!!! 00.56.50 # yeah but then again voltage drop on worse batteries can be very quick... 00.57.06 # ah right, maybe only for link files != main 00.57.14 # so even if it will be changed to be more conservative problems might still occur with very bad batteris 00.57.15 # aowzone: np 00.57.23 # petur: It is specifically only for link files != main. :) 00.57.27 # yes, this was the main (default) link file 00.57.34 # right 00.57.39 # case closed then! :-) 00.57.41 # For the main one, he wanted to preserve the option to delete the last link within it, etc. 00.57.44 # If I recall 00.57.51 # someone should put that info in the wiki! 00.57.53 # sounds reasonable 00.58.22 # is it possible to somehow call this link file if the file filter is set to "music"? 00.58.33 # thanks guys, goodnight! 00.58.41 Quit aowzone () 00.59.00 # dup: Try "supported" 00.59.10 # Obviously a link file is not "music" 00.59.17 # ;) 00.59.57 # Llorean: yes, I see :-) I thought about a menu entry (please don't shoot) 01.00.44 # so that the shortcuts are always at hand 01.01.06 # Just put them in a folder in the root of your player. 01.02.22 # There are people who want all kinds of things added to the main menu (podcasts, videos, ebooks, text, pictures, now favourites, etc, etc) if they were all added it'd pretty much remove the point of having them there for the purpose of getting to them quickly 01.02.39 # Meanwhile your root folder is rather a flexible place in regard to what you put in it, and what you don't mark as hidden. 01.03.16 # I'll do this. BTW: wouldn't it be nice to be able to have a "readable names" for the folders? Folders names can be very long, and it will be a pain to read such list 01.03.41 # I have no idea what you mean by "readable names" 01.04.49 # We could e.g. add an optional tab separated "short name" for an entry. E.g. the folder is "/blah/hgfjhgf/jhgjhg/jkjhk/sfdsgf/" (long), but it would apper as "tralala" (short) in the list 01.05.38 # The line in the file would then contain that long folder pathtralala 01.05.59 # If there is no TAB then the folder is shown as is 01.06.16 # Ah, for the favourites plugin 01.06.28 # Ehm, shortcuts you mean? 01.06.30 Join basscade1 [0] (i=sneakums@jenny.ondioline.org) 01.06.36 # Sorry, I'm used to the original name of it. :-P 01.06.55 # It took me ages to stop referring to them as "CVS builds" 01.07.10 # Anyway, that sounds reasonable. If you write it, post it to the tracker. 01.07.13 # Another option could be to show folders as is but just the last segment (or the last N segments) 01.08.06 Quit FOAD ("I'll be back") 01.08.35 # Llorean: I'll think about this. But not today anymore. 01.08.54 Quit dup ("CGI:IRC 0.5.7 (2005/06/19)") 01.10.25 Join JdGordon [0] (n=jonno@c220-237-57-32.smelb1.vic.optusnet.com.au) 01.10.38 Quit Ishi`` () 01.12.06 Nick basscade1 is now known as sneakums (i=sneakums@jenny.ondioline.org) 01.12.52 Quit Febs (Read error: 110 (Connection timed out)) 01.13.13 Join FOAD [0] (n=dok@dinah.blub.net) 01.20.05 Quit My_Sic ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 01.20.50 # Domonoky: for the logs, I started looking into it and was wondering if it's better to extend the ZipInstaller class or to create a new one. 01.21.21 # but I just got home today, was quite busy -- so no time to work on that today. Hopefully it will be better tomorrow. 01.21.30 Quit bluebrother ("nite") 01.22.05 Join hannesd_ [0] (n=light@gate-hannes-tdsl.imos.net) 01.23.37 # hey Llorean i'll pick on you since you're here often. do you know if i can safely repartition my ipod? i'd like to break the large part into 50% fat32 for ipod use and 50% ext3 so i can store files larger than 4 GB 01.28.33 Quit bdgraue (Remote closed the connection) 01.30.13 Join perrikwp [0] (n=chatzill@74.167.148.160) 01.31.34 Quit robin0800 (" HydraIRC -> http://www.hydrairc.com <-") 01.33.22 # do we have a location to report flyspray errors? 01.33.58 Join chrisjs169_ [0] (n=chrisjs@pool-71-254-214-208.hrbgpa.east.verizon.net) 01.34.18 Quit chrisjs169 (Nick collision from services.) 01.34.22 Nick chrisjs169_ is now known as chrisjs169 (n=chrisjs@pool-71-254-214-208.hrbgpa.east.verizon.net) 01.37.47 Quit hannesd (Read error: 110 (Connection timed out)) 01.37.48 Nick hannesd_ is now known as hannesd (n=light@gate-hannes-tdsl.imos.net) 01.38.46 # JdGordon: around? 01.40.00 Join Rick [0] (i=rick@pool-96-229-91-46.lsanca.dsl-w.verizon.net) 01.41.47 Join perrikwp_ [0] (n=chatzill@74.167.148.160) 01.43.56 # petur: not really, about to head off... 01.44.00 # if its quick..... 01.44.16 # nm, I think I found it myself 01.44.30 # sorry to bother 01.44.33 # ok cool, no worries 01.44.35 # ttyl 01.44.39 Quit JdGordon ("Konversation terminated!") 01.48.01 # ToHellWithGA: that should be fine as long as you do that to the end of the partitions...also, there is no need to direct a question to a particular person 01.48.33 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 01.48.33 # * petur wonders who GA is 01.50.04 # bah I hate this menu macro stuff.... *heads over to wiki and hopes JdGordon explained it well* 01.53.15 Join safetydan [0] (i=cbca159f@rockbox/developer/safetydan) 01.54.42 Quit perrikwp (Read error: 110 (Connection timed out)) 01.56.22 *** Saving seen data "./dancer.seen" 01.56.43 Join chrisjs169_ [0] (n=chrisjs@pool-71-254-214-208.hrbgpa.east.verizon.net) 01.57.01 Quit chrisjs169 (Nick collision from services.) 01.57.06 Nick chrisjs169_ is now known as chrisjs169 (n=chrisjs@pool-71-254-214-208.hrbgpa.east.verizon.net) 01.58.49 Join Febs [0] (n=chatzill@207-172-204-33.c3-0.rdl-ubr4.trpr-rdl.pa.cable.rcn.com) 02.00.39 Part pixelma 02.01.16 Join aliask_uni [0] (i=82c20d6a@gateway/web/cgi-irc/labb.contactor.se/x-348c84d5ea342141) 02.06.14 Join tihoc4n [0] (n=Compaq_A@206-163-245-208.swcr.hsdb.sasknet.sk.ca) 02.07.04 # Hi, I have a question about vorbis, well .ogg to be specific will this ever be implemented? http://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions 02.07.35 # scorche: thanks man. i just figured some of yall were around more than others 02.07.37 # cheers 02.08.09 # yes, but highlighting a specific person isnt considered "nice" when you dont need them specifically 02.08.22 # as well, if you screw up, there are MBRs in the wiki 02.09.25 Quit BHSPitMonkey (Remote closed the connection) 02.09.58 Join BHSPitMonkey [0] (n=stephen@adsl-64-217-216-219.dsl.rcsntx.swbell.net) 02.12.19 Join spiorf [0] (n=spiorf@host189-215-dynamic.9-87-r.retail.telecomitalia.it) 02.12.20 Join JoeBorn [0] (n=jborn@208.78.234.186) 02.15.31 # tihoc4n: what specifically on that page? 02.16.00 Quit jhulst (Remote closed the connection) 02.19.57 Part maffe 02.20.17 Join maffe [0] (n=maffe@barmen.interhost.no) 02.20.42 # * petur gives the menu code an angry look 02.26.58 # saratoga: The .oga extension for vorbis audio, sorry I should have been more specific. 02.30.38 Quit krazykit ("bbiam") 02.32.37 # tihoc4n: its pretty trivial to add that extension, but it can only be for one format I think 02.33.09 # do you think it would make sense to enable it for Vorbis only? 02.33.32 # does rockbox decide on a decoder based on extension? 02.35.41 # iamben, pretty much. Though there's some byte sniffing done for ogg streams to check for Vorbis/Speex/FLAC (maybe FLAC... not sure about that one) 02.37.58 Join miepchen^schlaf [0] (n=hihi@p54BF7A7A.dip.t-dialin.net) 02.38.25 # I think it would make sense just to enable it for vorbis only, flac users normally use the .flac extension anyway. and Ghost isn't released yet. 02.38.41 Join chrisjs169_ [0] (n=chrisjs@pool-71-254-214-208.hrbgpa.east.verizon.net) 02.39.12 # tihoc4n: theres also speex 02.39.20 # do people actually use oga ? 02.40.34 # * Rondom has never seen a single oga-file 02.40.44 # I don't think anyone does, because there isn't much support for it yet. Anyway about speex according to that wiki page "Although they share the same MIME type, Vorbis and Speex use different file extensions." 02.40.48 # if its just something Xiph suggests but few people actually use, it might be a better idea to wait until we can actually demux the things Xiph says we should 02.43.02 # well, supporting oga as file extension with the things rockbox is already capable to handle is a step into the right direction, imo 02.43.26 Quit petur ("Zzzzzz") 02.43.36 # I mean this could make more people start to use oga (I still doubt it, though) 02.44.23 # i don't have a problem with it, but get one of the europeans to say its ok and then I'll commit it 02.45.28 # or better yet, if you're a programmer, change line 73 of id3.c and submit a patch to the tracker 02.45.46 # Just as an added extension? 02.46.15 # yeah, just add oga to the list of vorbis extensions 02.46.52 # Does xiph.org specify what .oga gets to be? 02.47.01 # http://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions 02.47.10 Quit Rondom ("Ex-Chat") 02.47.16 # yeah it can be any of their codecs but speex 02.47.34 # saratoga: Actually, it doesn't mention Vorbis there 02.47.48 # In fact it clearly states it's *not* for Vorbis 02.47.51 Join krazykit [0] (n=krazykit@gct09-56.gctel.net) 02.48.17 # i'm not sure 02.48.19 # "using any of the Xiph audio codecs" 02.49.01 # Well look at the Rationale bit 02.49.07 # ask tihoc4n about it 02.49.10 # Though I'm not certain what "Vorbis-II" is relative to what we support 02.49.15 # hes apparently familar with this 02.49.19 # Do we support Vorbis I, Vorbis II, or both? 02.49.25 # just I 02.49.29 # Not that familiar, but I've come across it 02.49.29 # i don't think II exists yet 02.49.46 # Vorbis II doesn't exist, no 02.49.49 # Well, the page explicitly says it's to differentiate Vorbis I files (.ogg) from all other xiph audio files (.oga) 02.49.55 # See the RATIONALE bit 02.49.59 # i wonder why they want to do that 02.50.13 # God, my tolerance for stupid lazy whiny demanding people is just about exhausted today. 02.50.14 # Vorbis I can only have one logical bitstream, according to that. 02.50.28 # Febs: More at ours, or elsewhere? I just got back from dinner and haven't refreshed yet. 02.50.59 # Ours. Want to take a wild guess at the subject matter of the thread? I'll give a hint. It's in the plugins forum. 02.51.02 # saratoga: Either way, according to Xiph.org, we very definitely should not use .oga for Vorbis-I, should for flac, and *maybe* should for Speex if it falls under that "any of the Xiph audio codecs" umbrella 02.51.15 # Febs: Ah. Doom. 02.51.21 # that page is kinda confusing 02.51.26 # ok that sounds reasonable 02.51.36 # "ok thank you can you tell me if that subdirectory is a folder " 02.51.38 # haha... 02.52.10 # reading the whole thing, it sounds like they want Vorbis to have its own file extension specifically to help out hardware players, so i guess we're doing it right :) 02.52.11 Join chrisjs169__ [0] (n=chrisjs@pool-71-254-214-208.hrbgpa.east.verizon.net) 02.52.32 # saratoga: Someone should tell xiph.org they need to write clearer standards. :-P 02.52.41 # Yeah, what you guys can't see is the posted all in capital letters about "WHY IS NOBODY HELPING ME." 02.53.01 # I can't respond any more, because my next response is to tell him that he needs to change his signature because it's wrong. 02.53.15 # haha 02.53.20 # Febs: It was very, very hard for me to resist saying something similar. 02.53.43 # Such as "this should be considered basic computer knowledge and is something one should learn while becoming good on a computer" 02.53.48 # oh, fine...i wil be the bad guiy and say what has to be said 02.53.53 # we should just word filter "DOOM" to "GET OUT NOW" 02.54.23 # About .oga, I see the flaws in that page now, We should wait for more definitive information from them. 02.55.59 # seems to me like they want ogg speex as .spx, ogg vorbis (I) as .ogg, and all other ogg audio as .oga 02.56.26 Quit JoeBorn ("Leaving") 02.56.28 # but their justifications for .spx & .ogg are "for compatibility with hardware players" 02.56.28 # hrm...perhaps not...my version is a little ridiculing 02.56.44 # iamben: I think .oga will be allowed to include speex. It mentions .spx simply being preserved for compatibility. 02.56.56 Quit aliask_uni ("CGI:IRC") 02.57.00 # But I'm a little uncertain about that 02.57.32 # * Llorean wonders how many hardware players besides those running Rockbox support Speex anyway. 02.57.32 # same w/ vorbis really 02.57.45 Quit chrisjs169 (Read error: 110 (Connection timed out)) 02.58.01 # so .oga is ANY ogg audio, .ogg = vorbis only, .spx = speex only? 02.58.15 # iamben: Well it mentions excluding Vorbis-I from .oga, I think 02.58.28 # its all very unclear =) 02.58.31 # Though it may mean "excluding everything else from .ogg", I'm not wholly sure 03.01.08 # it says the same thing about .ogg = vorbis being kept for back-compatibility 03.01.34 # im used to mplayer where i can name my files clownpenis.fart and it'll figure it out, whether its ogg vorbis or avi/xvid 03.01.42 # why can't stuff that cares just look in it and see whats there 03.02.07 # nobody tries to make avi files .avd or somejunk to indicate that its divx in thre 03.02.32 # ze: Yes, but how many audio-only avi files do you have? 03.02.54 # They're trying to set up a naming scheme for a more universal container, so that users can glance at a filename and have a reasonable idea what to accept 03.03.00 # why do filesystems have to still be operating on increasingly antiquated paradigms necessitating this silly old "file extension" concept thats getting broken all over the place now 03.03.18 # Or so that Rockbox can populate a playlist with *just* music files, and not 5000 oggs containing text and videos that need to be opened and rejected before the next song is buffered 03.03.33 # Llorean: generally i have a pretty good idea what to expect from the file Name 03.03.40 # ze: Any metadata can be wrong. What makes a file extension any better or worse than *any* value a human is allowed to edit? 03.03.40 # and yeah that last thing i guess is a problem 03.04.07 # but a problem with data access schemes that nobody's getting past :/ 03.04.16 # Llorean: ok, so? 03.04.28 # ze: Well, what *exactly* is your complaint against extensions? 03.04.35 # The file "bob" tells me a lot less than "bob.ogm" 03.04.56 Join jurrie [0] (n=jurrie@adsl-068-209-041-021.sip.asm.bellsouth.net) 03.05.02 # that they're effectively a metadata field that's rather hacky and no longer adequete 03.05.18 # but persisting because there's nothing but filesystems still that don't provide for anything else 03.05.37 # How is it "inadequate"? 03.05.43 # it blew my mind the first time i saw a file extension with more than 3 letters... "can they do that?" i thought 03.06.07 # Llorean: i thought ogg was handily demonstrating how, thus this discussion :p 03.06.26 # ze: I don't think extensions are inadequate. 03.06.43 # They provide an easy, user-visible way of tagging a file type through any interface that allows renaming the file, essentially 03.06.53 # Llorean: i think at this point he is just expressing his disgust for the file extension trend in modern computing, not anything that can/should be handled differently in rb =) 03.07.02 # iamben: And I'm talking about in general to. 03.07.11 # What makes *any* sort of metadata more adequate than "a file extension"? 03.07.34 # well just look at the id3db style stuff on mp3 players 03.07.37 # including rockbox 03.07.43 # i kinda thought it was lame at first 03.07.46 # but after getting used to it 03.07.55 # i like having multiple ways of accessing data like that 03.08.13 # and things being innately capable of being tagged arbitrarily 03.08.18 # and accessed via such 03.08.42 # You're talking about a semantic filesystem 03.08.47 # and now it starts to look like directories, filenames, and file extensions are just kludgly little stop-gaps on the way to that 03.08.51 # Llorean: one problem is that we tend to limit file extensions to 3 letters, rather than goodsong.oggvorbis and coolvid.oggtheora, we are stuck w/ .oga & .ogv 03.08.57 # Llorean: is that what its called? 03.09.02 # But even in such a case, there would be a "type" and it would describe what "type" of file it is, and it would be exactly the same concept as an extension. 03.09.24 # ze: It's what *I'd* call it, and a quick google provides that there's some people who agree with me. 03.09.32 # Llorean: it'd be silly to put such an arbitrary restriction on it as that 03.09.36 # the fact that we have to cram many different filetypes into one extension is a problem 03.09.44 # ze: I'm not saying it would be a restriction. 03.10.04 # it could be an "av" type and "divx" type and "ogg" type all the same time 03.10.13 # and maybe thats not what you mean by "type" but does that matter? 03.10.14 # ze: I'm saying that there can assumed to be "a text string describing the file type" and that it will be analogous to "file extension" in what it describes, because it does serve a purpose 03.10.25 Quit spiorf ("Read error: 110 (Connection timed out)") 03.10.35 Part maffe 03.10.39 # ze: Is there something that prevents you from naming a file blah.av.divx.ogg? 03.10.53 # just that nothing really understands that 03.10.56 Quit chrisjs169_ (Connection timed out) 03.10.58 # except a human 03.11.02 Join chrisjs169_ [0] (n=chrisjs@pool-71-254-214-208.hrbgpa.east.verizon.net) 03.11.07 # tar.gz is a real world example :p 03.11.14 # tar.gz is a very good real world example 03.11.15 # and the fact that you can't filter out those needless parts when you just wanna see "blah" 03.11.16 # tihoc4n: good call 03.11.32 # ze: Your complaint is that "file extensions are an outdated concept" 03.11.40 # Llorean: no 03.11.41 # My point is that they contain exactly as much information as we choose to give them. 03.12.03 # Llorean: not so much an oudated concept per se i guess 03.12.12 # ze: You called it an "antiquated paradigm" and described them as "inadequate" 03.12.22 # right 03.12.27 # My point is that they're merely metadata, just as any other metadata we could store in any other way would be. 03.12.28 # but we can only fit so much info in them, and you can't sort it out 03.12.32 # in so far as the directory/filename/file-extension structure 03.12.32 # They are 1s and 0s on an HD. 03.12.44 # The problem then is not with what they are, but how programs choose to handle them 03.12.58 # i'm calling that structure an antiqueated and inadequate metadata system 03.12.59 # :p 03.13.35 # ze, it's a non-trivial problem to solve 03.13.39 # * safetydan points to the delays on WinFS 03.13.45 # ze: It may be, for human use. But it's also simple if you're actually aware of your own organizational structure, and efficient to access. 03.13.46 # indeed 03.13.58 # A semantic file system is much closer to how humans thing. 03.14.09 # "What was that green, round thing? Computer, get me all the green, round things I've got." 03.14.16 # think, not thing 03.15.02 # seems also nicer for programs not to have to traverse a hierarchy seeking something too 03.15.13 # but yeah 03.15.31 Quit jgarvey ("Leaving") 03.15.31 # i don't see how you're going to avoid traversing a hieracrhy short of only having one file type 03.15.38 # sooner or later you have to make a decision 03.15.49 # er well 03.15.49 # ze: How on earth would you seek without traversing a hierarchy, without specific information in advance? And if you have that specific information, why do you need to traverse? 03.16.03 # um 03.16.10 # If you say "Find me all balls", somewhere a list of balls has to be kept 03.16.25 # Analogous to a folder named "balls", with either files, or links to files, in it. 03.16.44 # yeah 03.17.05 # and i could have a directory named balls that's full of symlinks to all the ball files on my system 03.17.31 # and a directory called heavy objects thats full of symlinks to all the heavy object files on the system 03.17.41 # which would have overlap, with heavy balls 03.17.46 # And something just checks for heavy balls by checking for files present in both, yes. 03.17.49 # and tons and tons of such directories 03.17.51 # and symlinks 03.18.04 # What do you think a symantic filesystem would look like under the hood? 03.18.10 # It'd be a database with attributes. 03.18.13 # and redundancy to make a filesystem into flexible a metadata type deal 03.18.15 # and a huge mess 03.18.25 # Someone has to label all balls as "balls", one way or another. 03.19.14 # off this topic, but on topic, rockbox only handles vfat filesystems right? 03.19.15 # i could have all that or a db type deal instead 03.19.20 # does rockbox support speex? 03.19.25 # iamben: Yes. 03.19.36 # qwm! 03.19.41 # scorche! 03.19.41 # qwm, yes but not stereo 03.19.42 # ze: Yes, but assuming properly written software, you wouldn't be able to tell the difference anyway 03.19.48 # stereo speex files that is 03.19.54 # you speak! 03.20.01 # safetydan: gonna use it for an audiobook, so i'm fine without stereo. heh 03.20.05 # scorche: you mean he speex 03.20.11 # Llorean: *shrug* i'm not sure about that 03.20.14 # * scorche shudders 03.20.27 # scorche: yeah, i came here to complain about how rockbox is not playing music as well on the nano as it used to. 03.20.31 # but i probably shouldn't be throwing the chan OT anymore 03.20.38 # lots of glitches and speed variations since i upgraded. 03.20.50 # qwm: i havent noticed any difference 03.21.03 # qwm: You probably have one of the mysteriously problematic Nanos 03.21.15 # but why has it worked fine before! 03.21.22 # qwm: There seems to be a subset of Nanos (ie: those not owned by me or Scorche) that have IDE timing issues since some clock changes 03.21.37 # how frustrating. 03.21.49 # Llorean: wanna trade nanos? 03.21.51 # :p 03.22.00 # qwm: don't update until someone figures out what the problem is 03.22.07 # especially that none of the devs/helpers experience the issue 03.22.10 # or better yet, figure out what the problem is 03.22.12 # that's too late now.. 03.22.15 # qwm: Check the bug tracker, there's a related task (mentions firmware 1.3.1, but this is wrong) 03.22.26 # ah. 03.22.35 # qwm: If you want it fixed, convince amiconn to let you mail it to him. :-P 03.22.56 # qwm: actually, i wouldnt mind trading nanos to fix this...but as he said, amiconn is the person to go to 03.22.59 Quit Thundercloud (Remote closed the connection) 03.23.10 # hehe 03.23.54 # where can i find old builds? 03.24.10 # check them out from avn and build 03.24.17 # although there are other ways... 03.24.36 # like the archived daily builds 03.24.47 # http://www.rockbox.org/dl.cgi?bin=ipodnano 03.25.04 # if you want older than that, you will ahve to go to svn 03.25.08 # thanks. 03.25.48 # anyone know how i seek in the gigabeat sim? 03.25.50 # i'll give the oldest one there a shot. 03.26.22 # qwm: I think someone said the cutoff for the nano issue was around the 26th of last month 03.26.41 # ah, cool. 03.26.50 # found the first build i ever tried on my machine: rockbox-ipodnano-20060519.zip 03.26.51 # hehe 03.28.15 # actually, does anyone know how to seek in any of the sims? 03.28.27 # i don't really care what the target is, so long as it can run wma 03.28.54 Quit donutman25 ("ChatZilla 0.9.78.1 [Firefox 2.0.0.6/2007072518]") 03.29.03 Quit chrisjs169__ (Connection timed out) 03.29.15 Join chrisjs169__ [0] (n=chrisjs@pool-71-254-214-208.hrbgpa.east.verizon.net) 03.30.28 # saratoga, i thought you just held "right" on the keyboard, but that may be wrong 03.31.47 Part tihoc4n 03.32.58 # thanks, didn't realize it needed to be held 03.33.44 Join maffe [0] (n=maffe@barmen.interhost.no) 03.39.13 # saratoga: tried the july 24th build, seems to be working fine, thanks. :) 03.42.36 Quit chrisjs169_ (Read error: 110 (Connection timed out)) 03.42.46 Join chrisjs169_ [0] (n=chrisjs@pool-71-254-214-208.hrbgpa.east.verizon.net) 03.56.24 *** Saving seen data "./dancer.seen" 03.59.30 Quit chrisjs169__ (Read error: 110 (Connection timed out)) 03.59.41 Join chrisjs169__ [0] (n=chrisjs@pool-71-254-214-208.hrbgpa.east.verizon.net) 04.03.25 Quit XavierGr ("One firmware to rule them all!") 04.05.24 Quit miepchen^schlaf (Read error: 104 (Connection reset by peer)) 04.06.00 Join miepchen^schlaf [0] (n=hihi@p54BF7A7A.dip.t-dialin.net) 04.07.40 Quit scorche (Read error: 110 (Connection timed out)) 04.10.11 Quit chrisjs169_ (Read error: 110 (Connection timed out)) 04.10.11 Join annulus_ [0] (n=ap@h29n1fls33o286.telia.com) 04.14.22 Join elinenbe [0] (n=elinenbe@user-12hdtp2.cable.mindspring.com) 04.15.40 Quit dandin1 () 04.16.33 Join Soul-Slayer [0] (n=Administ@89.240.234.25) 04.25.59 Quit atsea- (Remote closed the connection) 04.30.40 Join atsea- [0] (i=ariel@gateway/tor/x-c76393063279a79c) 04.31.08 Quit saratoga ("CGI:IRC (Ping timeout)") 04.35.26 Join perrikwp__ [0] (n=chatzill@74.167.148.160) 04.35.28 Nick perrikwp__ is now known as perrikwp (n=chatzill@74.167.148.160) 04.50.12 # * Llorean is somewhat irritated at all the blind users' protestations regarding the voice change. 04.50.24 # I mean, I understand being upset by it, but they seem awfully demanding all of a sudden. 04.53.58 Join toffe82 [0] (n=chatzill@65.198.26.227) 04.54.05 Quit perrikwp_ (Read error: 110 (Connection timed out)) 04.55.48 # * jhMikeS finds it irritating as well and a poor descision when a much simpler design could be done and save even more memory...but oh well, I guess it's entrenched now. :\ 04.56.34 # jhMikeS: Simpler design? 04.56.55 # I don't think anyone would really object to more improvements. 04.57.22 # yes. I talked about it with Bagder. No target-specific voice files which I think are going to be a major headache. 04.57.32 # Why? 04.57.58 # After my first generation of the voice files, it takes me less than 2 minutes to generate them for 5 targets. 04.58.16 # you either have to make them or wait for them instead of just having one voice/lang file you load the wanted bits from. 04.58.16 # And that was, "after my first generation of one voice file", now that the pool is seeded for all of them, it's probably even quicker. 04.58.33 # jhMikeS: How do you handle the "voice file is way too big for Archoses" issue then? 04.58.48 # Just keep the big file, and only store the appropriate bits in RAM? 04.58.49 # seems like more trouble than what writing just a few lines of code could make unnescessary 04.59.56 # only load what's used and there would be no usused index entries nor order dependence and strings could be deleted arbitrarily when no longer needed by using ids that never change 05.00.22 # Hi, this might be a really retarded question but how does one go about getting the firmware for something like an Xclef MT-500 so that I can reverse it? Is hardware used to take it from the eprom? Or is it just a matter of unpacking a firmware update? 05.01.38 Quit weoh (Read error: 110 (Connection timed out)) 05.01.55 # jhMikeS: Seems pretty reasonable, though with the amount of space I have free on my flash players, I'd really prefer "slightly more complicated to make, but smaller" considering that it can be automated. 05.02.17 # when adding a new string: id = next_id, next_id = id + 1. id will never be used for another string again. 05.04.42 # A compromise solution could be to still use the ids in order to save more array space. I think archos still has some 300 NULL entries in the table. 05.06.47 # heck it could even load a master or stripped-down voice file the same way, leaving it up to the user 05.07.09 # That would be a good compromise. 05.07.38 # Wouldn't that result in a lot of ifdeffing in the code for different talk ids though? 05.07.49 # none 05.09.35 # Do current voice files *have* to be target specific? I don't know how it worked, but I assumed the voiced bit was determined by the language string loaded. 05.09.36 # each table entry would be char * str[index] = { "string",... }. parallel to str: short[index] = { ID }. strings would be sorted by ID. 05.10.02 # * Llorean doesn't have any clue how it works, clearly 05.10.19 # My understanding is that they do. 05.10.34 # Then could a voice file containing all strings work for all targets (that can load it)? 05.10.42 Quit miepchen^schlaf (Read error: 110 (Connection timed out)) 05.10.57 # in SVN or my idea? 05.11.02 # In SVN. 05.11.03 Join miepchen^schlaf [0] (n=hihi@p54BF6D99.dip.t-dialin.net) 05.11.13 # Since my understanding is your idea is supposed to explicitly allow that. 05.12.47 # My understanding is no, but I don't see why there'd be gaps in the table then. 05.13.54 # they seem to be gone so I guess that forces them as target-specific 05.14.06 # Gotcha 05.14.34 # don't know why Bagder implied the NULLs were still there or I misunderstood something 05.15.24 # Maybe he meant they were there during the generation, but didn't end up in the final file? 05.16.00 # no idea now...hehe 05.17.01 # Heh 05.18.34 # Is there some special difficulty that prevents someone from updating the windows script for the new voice format, or is it merely a case of "nobody's around to do it"? 05.18.34 Part maffe 05.18.41 Join maffe [0] (n=maffe@barmen.interhost.no) 05.18.43 # * jhMikeS too preoccupied with the cache problem that gives the C0EDBABEs to try to tackle that problem too 05.18.48 # Hahaha 05.19.47 # Interestingly enough, C0EDBABE doesn't show up in Wikipedia's article on magic numbers 05.20.06 # Though there's a C0DEDBAD, which I rather like. 05.20.13 # nor does 0xba90f5417 or 0xcacad0d0 05.20.58 # * jhMikeS forgot the BOS majic number :( 05.21.29 # jhMikeS: Did you write the SPC patch to use the COP? 05.21.33 # yes 05.21.43 # Is that the plan for other codecs too, just leave it entirely up to them how to use the COP? 05.23.00 # I think they should be able to determine how they make threads even if normally on COP. I'm still waiting for PP5020 test for the better dual-core kernel patch I just made. 05.24.44 # And what's this about a new dual-core kernel? 05.24.55 # It's far better than the whole core lock thing since the processors remain almost completely independent. 05.25.01 # Oooh 05.25.26 # Is it functioning so far on any targets? 05.25.30 # I can send messages core-to-core just fine with my test plugin. Locking is very localized for specific purposes. 05.25.44 # e200, 5g it's been checked 05.26.05 # Well, that covers what I can offer testing on. 05.26.14 # Well, Nano, but that ought to be covered by 5G. 05.27.06 # There was a problem using backlight fading after using mpegplayer on 5g but I'm not sure it's the patch. There's yet another place that needs a cache flush there. 05.27.46 # The backlight always seems to be problematic in one place or another. 05.28.37 # I don't think I'd not commit for that since turning off fading had no problems after mpegplayer. 05.29.39 # Just claim it's a bug with backlight code and beyond the scope of the patch. :-P 05.31.02 # I believe it's just a cache issue or that call to mpeg2_close on the main thread without an invalidate first messing things up. 05.31.11 # Ah 05.37.01 Join scorche [0] (i=Blah@rockbox/administrator/scorche) 05.37.51 # the patch is basically a non-change from how things are now. the way threads are woken by IRQs is just generalized to doing it accross cores. it does make mutexes recursive and adds semaphores and events. the last two are used to make codec swaps perfectly atomic. 05.40.04 # events might come in handy for the USB driver as well 05.42.14 # So it's just PP5020 testing that's really holding it back? 05.46.07 # pp5020 testing is holding a bunch of stuff back 05.47.07 # weren't H10's around for < $90? 05.47.12 # Yeah 05.47.33 # I have an H10 if you need me to do anything? 05.47.46 # i can test h10 05.47.56 # Sould-Slayer: if you could test a patch...like you up? 05.48.25 # Sure could. Give me a moment to reboot and I shall 05.48.33 Quit Soul-Slayer (Read error: 104 (Connection reset by peer)) 05.49.42 # practically everything I looked at on ebay went for like $120 05.50.05 # they were on a wootoff a while ago for like $25 or less i think 05.50.08 # I think they were $90 on Woot, which then ends up with a bunch of them being resold for 120 on ebay 05.50.23 # oh were they really 90? 05.50.26 # heh 05.50.30 # Well, they've been on Woot a few times 05.51.00 Join Soul-Slayer [0] (n=jonno@89.240.234.25) 05.51.25 # Returned. 05.52.16 # http://www.rockbox.org/twiki/bin/viewfile/Main/MichaelSevakis?rev=1;filename=dual-core-compat.diff 05.52.48 # Just put it through general use? 05.53.10 # 1) Should boot 2) should play, even with voice 3) mpegplayer if possible ... mostly I'm concerned about the core of course not minor post-mpegplayer glitches 05.53.36 # It will need a full update of everything 05.54.09 # Bootloader too? 05.54.14 # oh, no 05.54.24 # jhMikeS: Are codecs put one the second core, or is that outside the scope of this? 05.54.29 # Am making from scratch so should be fine. 05.55.05 # Llorean: this only enables that to be done. one step at a time :) 05.55.42 # Soul-Slayer: thanks for the tests 05.55.59 # jhMikeS: I assumed that would be the case, but I wasn't sure what you mean by "should play, even with voice" 05.56.28 *** Saving seen data "./dancer.seen" 05.57.01 # it uses new kernel objects for the syncronizing of swapping but I've had no problems and they've never panicf'ed (there's code enabled to check them right now). 05.57.07 # Ah 05.58.47 Quit scorche (Connection reset by peer) 05.58.55 Join scorche` [0] (i=Blah@rockbox/administrator/scorche) 05.59.27 # mutexes being recursive is incompatible with SVN playback.c use 06.01.42 # Right lets see. 06.01.46 # the 5020 tests are the most harrowing 06.01.47 # Booted fine 06.02.01 # score 1? 06.02.28 # Hmmm 06.02.37 # However, trying to open a file I'm just getting 'Loading...' 06.02.50 # Disk is spinning but no clicking sound 06.02.58 # jhMikeS: In theory is there any way your changes could cause the wrong voice clips to playback, or should I assume this voicefile is broken, and simply check for that later? 06.03.09 # * Llorean would like to assume the voice file is simply bad 06.03.24 # * Soul-Slayer reboots and tries again 06.03.28 # Llorean: I've checked with a new voice file and had no difficulties 06.03.36 # Alright 06.03.43 # I'll assume my ipod-nano specific voice aint quite right 06.04.13 # though a voice-free check should be done 06.04.20 # voice-free check? 06.04.35 # voice off and then no voice file at all just to compare 06.04.56 # What am I comparing in that situation? 06.05.15 # voice off = no codec swap. no voice file = no codec loaded at all 06.05.39 # window 5 06.05.45 # oops sorry 06.05.59 # jhMikeS: Playback seems to fail. I've tried three times, twice it freezes up on the 'Loading...' splash, once it played, I paused it and it refused to resume. 06.06.01 # What I'm saying is happening is that when I highlight the top line in the system menu, it says "Warn when deleting dynamic playlist" 06.06.36 # Soul-Slayer: voice present or not? 06.06.40 # Not 06.06.59 # eek 06.07.27 # My settings are reset to default by the way. 06.07.28 # Llorean: sounds like a wrong clip 06.07.45 # Yeah, there's something wrong with the voice file 06.07.54 # :( 06.07.55 # Hmmmm 06.08.03 # Now it's playing the song, 5th attempt 06.08.09 # I'll see if skipping and so on works 06.08.10 # Soul-Slayer: so there's no voice file at all 06.08.16 # Not a trace 06.08.30 # Right, IF I can play a song, it functions as expected 06.08.44 # But it seems to freeze up on the 'Loading...' splash most of the time 06.09.10 # Although, now it's letting me choose songs freely.. 06.09.24 # playback.c is so loaded with timing issues that the problem probably isn't the patch itself 06.10.12 # Well, the player is now responding as expected... 06.10.20 # Until I restart it I presume 06.10.21 # well, this is farther than any dual core patch has ever gotten 06.10.47 # Right, it just randomly froze up on me 06.11.10 # after restart? 06.11.20 Quit scorche` (Read error: 104 (Connection reset by peer)) 06.11.22 # Just during playback 06.12.06 Join scorche [0] (i=Blah@rockbox/administrator/scorche) 06.12.17 # Restarted, playback is working again 06.15.58 # Bagder: There seems to be something wrong with at least the Nano-specific voice file, several clips are wrong 06.16.38 # jhMikeS: Hasn't crashed yet... But this is the 6th time I've restarted it 06.17.17 # Soul-Slayer: well, that actually holds alot of promise. were you able to try mpegplayer? 06.17.47 # What would I be looking for? 06.17.52 # Whether it actually works? 06.17.55 # yes 06.18.16 # Let me find a test file, bear with me :p 06.18.39 # all the experience ever was before was "freezes at boot screen" 06.18.57 # It definitely boots okay :p 06.19.14 # hrm...my copy of the site that i was working on is gone... 06.19.30 # * scorche sends off a mail to redbreva 06.20.36 # Just downloading Elephants Dream... 5 mins or so and I'll be with you. 06.20.44 # Do the other targets you tested on crash? 06.24.30 # Soul-Slayer: there was a backlight glitch after mpegplayer on 5g. e200 has no problems at all. 06.25.24 # the backlight glitch was only when fading was enabled 06.26.24 # jhMikeS: Just about to test mpegplayer 06.27.03 # Plays fine 06.27.04 # * jhMikeS puts claw marks in the armrests 06.27.28 # let it go a couple for a bit 06.27.29 # Opens the file fine, quits fine, backlight seems fine afterwards 06.27.35 # Ok 06.28.00 # the best test before was "plays a few seconds then crashes" 06.28.30 # I wish this movie made sense... :p 06.29.11 Join chrisjs169_ [0] (n=chrisjs@pool-71-254-214-208.hrbgpa.east.verizon.net) 06.29.30 # it's about new ideas vs. old, entrenched ones I think 06.30.19 # Shall have to get the proper version some time that isn't on a 128x128 screen and work it all out :p. But the fact remains it's still playing 3 mins or so later... 06.31.30 # I think I'll have to chalk the playback stuff up to timing changes introduced. mpegplayer is quite atomic thread wise. 06.32.24 # Soul-Slayer: But playback is consistently playing now, or do you still have to try a bunch of times like you did right after starting the build? 06.32.46 # Llorean: Let me see, still in the video at the moment. No crash yet though. 06.32.50 # * Soul-Slayer quits 06.33.04 # Playback froze it. 06.33.12 # Stuck on the loading splash again 06.33.14 # Unfortunate. 06.34.03 # Restarted and worked on playback first time 06.34.19 # Can you play a movie, stop, then play another movie? 06.34.20 # Llorean: not as much as before actually ... it's localized and perhaps traceable 06.34.41 Quit toffe82 (Read error: 110 (Connection timed out)) 06.34.44 # Currently playing a song, shall go straight into mpegplayer, try playing another song, then mpeg again. 06.34.46 # * jhMikeS also wonders about frequency scaling 06.35.11 # Hmmm 06.35.13 # What about frequency scaling? 06.35.24 # Playback -> Mpeg = Data abort at 0006C092 06.35.28 # But the sound is still playing 06.35.36 # (Sound of the video, not playback) 06.35.53 # that one's a rather unrelated caching difficulty 06.36.02 # Ok 06.36.20 # Restarted, again, playback was fine 06.36.20 # happens in SVN but usually at C0EDBABE 06.36.32 # Seems aslong as I'm quick going into playback it will work 06.36.53 # Playback -> Mpeg worked this time 06.36.54 # try setting some extra boost counts in the debug menu and try 06.37.10 # Try what? 06.37.19 # Soul-Slayer: out of curiosity, can you feel the disk spin down/up fairly well? 06.37.34 # I can't feel, but I can put my ear to it and hear it 06.37.55 # Makes quite an audible high pitch when spinning, and clicks when accessing 06.37.59 # And it just froze on me 06.38.27 # I was just wondering if the point where music won't start might align with the point where the disk spins down. 06.39.04 # Llorean: When accessing a song, I'll hear the disk spin up, the splash stays on 'Loading' and the disk continues spinning until I remove the battery 06.39.22 # jhMikeS: What boost count shall I try and what do you want me to try? Playback? 06.39.50 # Soul-Slayer: just add a whole bunch so it can't unboost 06.39.59 # and yeah, playback 06.40.02 # Soul-Slayer: I meant, during boot the disk spins. Then it spins down shortly after. I was curious if the freeze happens if you let it get to that spindown, or if it's unrelated. 06.40.26 # could increase the spindown time so it can't for awhile 06.40.30 # Llorean: Ooh, understood, I'll check momentarily 06.40.37 # Trying playback boosted now 06.40.59 # jhMikeS: It seems unlikely that it's related to spindown, but I'm a curious person. 06.41.08 # I'll wait for disk spindown and do something else 06.41.31 # Llorean: me too but the craziest things can be related sometimes. 06.41.36 # Yup 06.41.52 # Or at least provide random clues 06.42.07 # * Llorean still wants to know what makes the crashing Nanos different. 06.42.16 # Skipping tracks is working ... But like I said, the freeze was very intermittent before, I am not sure how to provoke it 06.43.39 # Llorean: you ran the patch I take it? you just had a bum voice file? 06.44.02 # jhMikeS: Yeah, just a bum voice file 06.44.10 # I'm listening to music on a patched Nano right now. 06.44.27 # * jhMikeS wonders why sansa is such a stable pp target compared to others 06.44.31 # I built the voice under the same conditions, even using pooled mp3s, for my Gigabeat and the voice file was good. 06.44.43 # jhMikeS: Does sansa support frequency scaling? 06.44.44 # The Nano's been darn stable until the 80mhz change. 06.45.25 # Soul-Slayer: yes, but it was never a problem for it except for the FIFO refills during cache flushes causing click when not boosted 06.45.39 # Hmm 06.45.46 Quit chrisjs169__ (Read error: 110 (Connection timed out)) 06.45.50 # Well now I've got my H10 boosted it doesn't appear to be crashing 06.46.05 # I'll restart, boost it and see if it crashes, and try it a few times 06.46.06 # * jhMikeS sees amiconn has more work to do :) 06.46.24 # hello 06.47.03 # 2nd attempt, boosted it up, went into a song, no problems... Rebooting again and trying 06.47.04 # i was following the current conversation and decide to help test the dualcore patch 06.47.14 # jhMikeS: It's in theory an IDE timing issue, and may affect iPod Videos as well 06.47.26 Join chrisjs169__ [0] (n=chrisjs@pool-71-254-214-208.hrbgpa.east.verizon.net) 06.47.29 # i have a ipod mini 1gen by the way 06.47.34 # Llorean: lots of things in RB are not mutexed btw 06.47.49 # jhMikeS: Really seems to be boost related then... 3rd attempt no problem... 06.47.52 # perrikwp: the more the merrier. did you see the link? 06.48.24 # jhMikeS: Was that a "we need more mutexes"? 06.48.29 # i already compiled the build and audio playback works perfect 06.48.38 # Llorean: quite a few more 06.48.44 # Heh 06.48.45 # 4th no problem... I think we can rest assured it's related to the boosting 06.49.04 # perrikwp: cool. thanks for checking it. 06.49.28 # Yep... 5th... Now I'll try again without the boosting 06.50.09 # I'll test the spindown theory too 06.50.19 # there is a problem with mpegplayer though, but i don't know if it matters because it is a grayscale target 06.50.31 # there is audio but no video 06.50.42 # Llorean: Good assumption. I allowed the disk to stop spinning, and yep, it's crashed. 06.50.55 # perrikwp: hmmm...might be graylib related 06.51.00 # ok 06.51.01 # Does it unboost once it spins down the disk or something? 06.51.41 # Soul-Slayer: it will be unboosted, then playback will boost and spin the disk pretty much at once 06.52.17 # Well, I just allowed it to spin down, then put up the boost_counter and tried playback, worked first time 06.52.24 Quit safetydan ("CGI:IRC (Ping timeout)") 06.52.40 # so they combine in an evil conspiracy ... hrm 06.53.14 # If I don't boost it before trying to open a file, it freezes 06.53.21 # Unless the disk hasn't spun down yet 06.53.28 # but only if the disk stops spinning, right? 06.53.32 # heh 06.54.45 # yeah, with sansa, none of that is an issue of course 06.54.55 # Yeah, no disk to spin up :P 06.55.23 Quit chrisjs169_ (Read error: 110 (Connection timed out)) 06.55.42 # Do we attempt disk power down on the H10s? 06.56.35 # I don't know but something in my some obscure memory says there were issues with ATA and scaling there 06.56.50 # amiconn should know for sure 06.56.51 # You aren't kidding :p 06.58.20 # jhMikeS: A backlight issue seems pretty random... 06.58.37 # Soul-Slayer: you're having one? 06.58.50 # jhMikeS: No no, I was just thinking over the problems 06.58.59 # ok 06.59.00 # I can't see how the backlight got involved 06.59.59 # it shouldn't with nothing changing. the only difference really is that every kernel object has a core lock on every instance. 07.01.21 Join chrisjs169_ [0] (n=chrisjs@pool-71-254-214-208.hrbgpa.east.verizon.net) 07.01.58 Join toffe82 [0] (n=chatzill@65.198.26.227) 07.02.42 # Anyhow, I must sleep. Good job jhMikeS :P Hopefully amiconn will have all the answers ;) 07.04.08 # Soul-Slayer: thanks and goodnight :) 07.04.37 Quit Soul-Slayer ("Leaving.") 07.05.52 # This patch gonna affect PP5002 targets? 07.07.44 # Llorean: they don't have dual core enabled at all yet so it'll just have the new kernel objects 07.09.21 # I don't expect any green deltas from this one either :P 07.09.39 # Hahaha 07.10.08 # Man, I'm so glad I don't have an iPod Video. I just realized I'm listening at -66 07.10.34 # what's with the Video? 07.10.44 # Only goes to -54 if I recall. 07.10.54 # I think it has the least range of our targets. 07.12.06 # sansa once had that beat 07.13.08 # must be quiet over there though 07.13.16 # Oh, yeah. 07.13.20 # I'm wearing open phones. 07.16.24 Join Dylan_ [0] (n=chatzill@CPE-124-186-195-67.qld.bigpond.net.au) 07.16.34 Nick Dylan_ is now known as Adikdid (n=chatzill@CPE-124-186-195-67.qld.bigpond.net.au) 07.16.43 # Hello, all 07.16.53 # can someone please help me to oput rockbox on my iPod? 07.17.09 # what problem are you encountering? 07.17.20 # how to put it on my iPod 07.17.27 # have you checked the manual? 07.17.30 # i have downloaded it to desktop, now what do i do? 07.17.39 # read the manual 07.17.57 # u have read the rockbox.info and it just says 07.18.10 # did i say to read rockbox.info? 07.19.16 Part Adikdid 07.21.28 # Llorean: after this there's a pcm rework that cleans up the whole API and puts a start to make it play from whatever core initiates it. that's needed so COP codecs and CPU plugins can both use it efficiently. 07.22.37 # * Llorean wonders once more why an embedded device was designed dual-core like this. 07.22.39 # of course pp5020 is holding that up from just going in SVN now 07.23.46 # same sort of freeze issues but the tester wasn't as willing to follow through thoroughly so I never really narrowed it down 07.24.43 # two really cheap cores instead of one expensive 200MHz one? 07.27.01 # But wouldn't that then lead to like... the arm/dsp setups instead? 07.27.05 # * jhMikeS wonders when the day will come when there's 4,8 or 16 cores in a device ... probably not far off 07.27.08 # Something less symmetrical. 07.27.38 Quit chrisjs169__ (Read error: 110 (Connection timed out)) 07.27.48 # I think those exist already ... isn't the TMS320 one of those? 07.27.53 # Yeah 07.28.00 # Those make more sense to me. 07.28.12 # One core for the UI, and another core more or less designed for the A/V jobs. 07.28.27 # coldfire with an emac unit beats the pants off 160MHz of ARM7 07.28.47 # Hehehe 07.29.29 # And then you've got the ridiculous Gigabeat. 07.29.38 Join Adikdid [0] (n=chatzill@CPE-124-186-195-67.qld.bigpond.net.au) 07.30.16 # Unfortunately I doubt I'll ever meet someone who actually knows why any of those interesting decisions was made 07.30.19 # yeah, and one core that plays video 07.31.03 # * jhMikeS puts his money on the bean counters 07.31.06 # jhMikeS: So, there's a patch in existence for the playback cleanup too, or is that more of a plan? 07.32.03 # The MoB work to get buffering separated. It would be nice for that to be done and then getting playback.c in order would be much easier. 07.32.28 # Yeah, I haven't seen Nico_P since I got back. 07.32.59 # * scorche wonders why the GSoC students seem to disappear 07.33.01 # Everything looked like it was progressing, though. I just don't know if there's 'recent' work 07.33.30 # I think there's a want for a free lunch in that. there is none. that sort of buffer is complex and any design decision just has conseques in the logic. 07.33.48 Quit Adikdid (Client Quit) 07.34.01 # One "weak" cpu core + dsp isn't such an uncommon design 07.34.23 # amiconn: That's what I was saying though, I'm curious why the choice of identical cores rather than that. 07.34.25 # archos is the primest example 07.34.27 # TMS320 is just one example (arm+dsp) 07.34.54 # coldfire even 07.34.55 # I'm curious if Apple had a plan for the dual cores, or if they make use of them in some interesting way under the hood or anything. 07.35.17 # There's also TCC720 (calmrisc16 + calmmac24) (the failed Gmini port attempt) 07.35.31 # I think Toshiba had to have more plans for the Gigabeat and just bailed out to get it to market. It's way overkill for the audio only. 07.35.31 # ..and the ATJ2085 as an extreme example 07.36.04 # jhMikeS: the 2nd gen nano is pretty beefy as well 07.36.26 Quit toffe82 (Read error: 110 (Connection timed out)) 07.36.39 # The archos is somewhat different, as the 2 cores are two separate chips 07.36.49 # amiconn: did you follow any of that patch testing on H10? no problems unless the disk spins down while not boosted. 07.37.03 # * amiconn just got up 07.37.16 # as well, i dont think the OF on those nanos even does video 07.37.30 # what's so beefy about the 2nd gen nano? 07.38.34 # I thought the second gen was supposed to be a little slower than the 1st. But I'll admit I haven't researched. 07.39.41 # i think it is a 200 MHz ish arm 9 07.39.48 # PortalPlayer OF takes a big hit in responsiveness when music is playing. It's kinda odd given it has two cores. 07.40.05 Join ctaylorr_ [0] (n=ctaylorr@CPE001839ae25b4-CM0011aea4a276.cpe.net.cable.rogers.com) 07.41.27 # jhMikeS: So the crash Soul-Slayer was observing was with your patch? 07.41.30 # jhMikeS: Which player? 07.42.00 # amiconn: H10, but in just the specific way I mentioned. otherwise no problems booting or running mpegplayer. 07.42.10 # If it works boosted but not unboosted, it's certainly not ATA timing 07.42.26 # Llorean: I've seen it on iPod video and e200 07.42.48 Join Adikdid [0] (i=7cbac343@gateway/web/cgi-irc/labb.contactor.se/x-d3aea436828fc55d) 07.42.58 # It worked unboosted as long as the disk didn't need to spin when starting playback 07.44.12 # OK i installed rockbox but it says it has a red error, it says IPOD: File Is Missing 07.44.20 Quit ctaylorr (Read error: 110 (Connection timed out)) 07.44.39 # the only real difference from SVN is a test_and_set guarding the kernel objects 07.45.08 # can soneone please help me? 07.45.43 # yeah... 200MHz ARM949T and if i am reading this right, it has 256MB of SDRAM 07.46.05 # sorry...($)T 07.46.08 # bah 07.46.13 # ARM940T 07.46.23 # scorche: It's probably the same mistake the ipl people made with some other target 07.46.49 # http://72.14.253.104/search?q=cache:87gJLy35ZksJ:home.gna.org/linux4nano/download/hardware_synth-1.0.pdf+samsung+arm9+nano+ipod&hl=en&ct=clnk&cd=16&gl=us&client=firefox-a#8 07.46.50 # The RAM is very likely 256M_bit_ == 32Mbyte 07.47.09 # sounds likely 07.47.36 # How do i find out what gen my iPod is? 07.48.30 # scorche: yep. 2 Mistakes in one section (1.1.2) 07.49.01 # Googling quickly tells that K4M56163PG is a 4M * 16bit * 4 banks SDRAM, i.e. 32Mbyte 07.49.05 # amiconn: wouldnt surprise me...tis why i said it with a bit of caution above 07.49.54 # do i install rockbox to iPod_Control folder or a sub folder in iPoD_control 07.50.01 # it doesnt say in the mahual 07.50.05 # yes it does 07.50.34 # jhMikeS: Your "only load what's needed" idea has one rather obvious problem - how does rockbox know which IDs _are_ needed? 07.50.49 # It needs a list, and that increases its size 07.50.53 # no scorche it just says extract rockbox to the root folder 07.51.02 # yes... 07.51.03 # It doesn't say "root folder" 07.51.08 # It says to the root of the device. 07.51.09 # which tells you exactly where 07.51.22 # There's no mention of putting it in *any* folder. 07.51.47 # root of your player’s drive 07.51.47 Quit Adikdid ("CGI:IRC (EOF)") 07.52.03 # that's true though the list is parallel to the index array and each ID item could be 16bits. There might be a way to group things so an ID isn't needed for everything. 07.52.22 Join Adikdid [0] (i=7cbac343@gateway/web/cgi-irc/labb.contactor.se/x-ea4647e6e96aeea2) 07.52.38 Join ackbahr [0] (n=ackbahr@248-46.2-85.cust.bluewin.ch) 07.52.40 # Adikdid: http://en.wikipedia.org/wiki/Root_directory 07.52.46 # The index array is generated at runtime. The saving when introducing that was several KB 07.52.47 # amiconn: Why not include some metadata in the voice file then? Headers for each string that are stripped during loading? 07.53.14 # so i install it to K:\iPod_Control\Device 07.53.22 # no 07.53.32 # did you read what i just linked you? 07.53.37 # Llorean: If there's a single .voice (and .lng) file, the core must know which are to be used, and that _is_ target specific, hence it needs to be built into the voice file 07.53.41 # at least the first sentence? 07.53.52 Join My_Sic [0] (n=MySic@mur31-1-82-237-204-133.fbx.proxad.net) 07.53.52 # Erm, into the core 07.54.02 # yes scorche 07.54.16 # On many Unices, there is also a directory which is named /root. Confusingly, it is not a root directory in the sense of this article, but rather the home directory of the Superuser (conventionally known as "root"). 07.54.20 # that bit? 07.54.24 # "first or top-most directory" 07.54.28 Quit ackbahr (Read error: 104 (Connection reset by peer)) 07.54.56 # I also just became aware that the tables in the core are gap-free which is different than what I thought I knew. 07.54.58 # so i just instal it to iPod_control then? 07.55.09 # that is not the top-most directory 07.55.09 # amiconn: If there's a single voice file, couldn't it determine while loading from metadata in the voice file which lang strings not to load, though? 07.55.14 # Er, voice clips 07.55.23 # jhMikeS: I explained this multiple times... 07.55.26 # Adikdid: It doesn't go in *any* directory 07.55.29 # ...yesterday 07.55.46 # Oh, where do i install it too then? 07.55.47 # im confused now 07.55.59 # Adikdid: The root of your iPod. Not in any directories. 07.56.23 # Llorean: hmm.... 07.56.32 *** Saving seen data "./dancer.seen" 07.56.36 # so do i just install it to /k? 07.56.55 # so has anyone had a look at p7561? any suggestions on what needs to be added? 07.57.02 # amiconn: I suppose I was just hearing it all wrong at the time then. 07.57.03 # In fact we could play cheap and just concatenate all voice files, making each core only load the chunk it needs 07.57.21 # amiconn: That'd be a fairly large file, no? 07.57.27 # That's in fact a modification of the idea how to support voice in plugins 07.57.54 # Llorean: Large for RAM? yes. Large for a disk? no 07.58.12 # But I admit this might be a bit too cheap 07.58.17 # I dunno, a 15mb file on a 1gb player isn't ideal. 07.58.27 # Still less than one song 07.58.36 # Erm, no 07.58.43 # * amiconn isn't 100% awake yet 07.58.43 # though in talking this out some other ideas are congealing and no ID may be nescessary and full order independence preserved. 07.58.56 # i got it! 07.59.21 Join pondlife [0] (n=Miranda@cpc1-rdng11-0-0-cust362.winn.cable.ntl.com) 07.59.51 # Llorean: But at least better than trying to load it into 2MB ram ;) 08.00.02 # amiconn: Very true, indeed. :) 08.00.20 # why cant i get out of a photo when i look at one on my iPod 08.01.57 # man this building database shit is gonna take ages 08.02.06 # Well, each clip/string could have associated flags which tell what targets it is used on 08.02.39 # But that puts a limit on the number of supportable targets depending on how many bits we reserve 08.02.52 # This is true. 08.03.35 # But you can add more bits when necessary, anyway, since it's unlikely the file will never need to be rebuilt? 08.04.20 # hey can soemone please tell me how to install themes into rockbox? 08.04.33 # 32bit would be sufficient atm (we have 27 targets in configure atm, 3 of them are more or less dead) 08.05.35 # This idea would require giving strings which how have different per-target content a separate ID 08.05.44 # s/how/now/ 08.06.06 # * jhMikeS was thinking something similar. just an index array for the target in the header. 08.06.17 # Hmm, but it leaves one important problem - the built-in language 08.07.38 # There's another problem - even if the core then knows _which_ clips/strings to load, it still needs to know _where_ in memory to load them 08.08.15 # That doesn't pose problems on any of the disk based targets, but it does on Ondio 08.08.40 # On Ondio we don't load the whole voice file at once, because that'd be too slow 08.08.41 # on the old idea, the IDs would be sorted and a matching ID put into the slot at that matching key 08.08.41 Join webguest52 [0] (i=c023110a@gateway/web/cgi-irc/labb.contactor.se/x-037a555d99e3ae3a) 08.08.57 # Instead we just load the index array, and clips are then loaded on demand 08.09.36 # Hmm, that could still work if there's also a table of the clip sizes 08.10.05 # you'd need that. I'd want most of the file to be able to be skipped and never loaded. 08.10.51 # hi all, quick question: just wondering if is anyone aside of Linus working on avoiding the source tree appreading 3 times inside the archived daily builds ? 08.10.56 # If we think about that, we should also keep in mind that plugins might also want to use voice 08.11.31 Quit My_Sic ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 08.11.50 # In fact that's not much different from the target selectivity 08.13.31 # Also keep in mind that the file should be loadable without skipping back. Seeking is costly 08.13.48 Join chrisjs169__ [0] (n=chrisjs@pool-71-254-214-208.hrbgpa.east.verizon.net) 08.14.09 # Skipping forward is okay; should be faster than plain reading 08.14.48 Quit Adikdid ("CGI:IRC (EOF)") 08.15.38 # The built-in language problem could be solved like it is now - by actually leaving out the strings which don't apply to the target 08.15.55 # On disk they wouldn't be left out 08.16.22 # * jhMikeS just wants this little H10 disk glitch figured out before trying more big projects (oh, pcm rework :))) important those get in SVN soon. 08.16.40 # Of course another solution is just to have working TTS. ;) 08.16.55 # * amiconn wants to get the 1st/2nd gen support out the door 08.17.01 # Llorean: On archos? 08.17.04 # Ah, true 08.17.10 # I was just kidding anyway 08.17.26 # Voice files should pretty much be kept on no matter what, as prerendered should always be able to sound better, right? 08.17.31 # And given how festival sounds compared to the voice files I used before, I would still like to have a choice 08.17.53 # Have you tried espeak or flite yet? 08.18.11 # *chant* death to codec swapping 08.18.16 # Though they still aren't near the class of AT&T 08.18.17 # flite is just dreadful 08.18.17 # I just used the downloaded voice file; no time to fiddle with voice generation on linux 08.18.39 # GodEater: flite was better than festival I thought. But I prefer espeak right now 08.19.10 Join My_Sic [0] (n=MySic@mur31-1-82-237-204-133.fbx.proxad.net) 08.19.13 # Llorean: didn't you think flite sounded like someone in slow motion ? 08.19.15 # * amiconn used a quite outdated at&t voice before. 08.19.29 # GodEater: The pitching was a bit funky 08.19.46 # The festival voices are quire slow, even for me as a non-native english speaker 08.19.49 # I much prefer espeak of the three 08.19.52 # * jhMikeS wonders when 1st/2nd gen support will be out the door enough so real dual core support can be realized _finally_. 08.19.53 # s/quire/quite/ 08.20.21 # jhMikeS: I need to get my head around the backlight thread. I need a way to suspend backlight 08.20.26 # Llorean: I prefer to listen to espeak with -s 200 -p 20 (faster + lower pitch) 08.20.42 # markun: 200wpm? 08.20.43 # but maye that doesn't make sense for voice files 08.20.44 # I think I can simplify some things, but I didn't try it yet 08.20.51 # the dual core support adds an object to make that possible 08.20.55 # One of the voice files hosted in the wiki was 440wpm 08.21.15 # wow 08.21.16 # As soon as I have suspend working, I want to publish a bootloader 08.21.47 # markun: Perhaps we should poll the blind users and ask what they consider a reasonable average speed 08.21.48 # jhMikeS: I don't want to suspend the thread. It should still process messages in order to avoid queueing them up 08.21.57 # the event object would be just the thing since it can be set to unsignalled and keep the thread waiting until it's signaled again 08.22.12 # Llorean: but also non blind people use it (like amiconn) 08.22.42 # markun: Yes, we should probably pick on the lower end of whatever range they give. 08.22.43 # well, then it can test the object and just discard messages 08.22.46 # But it would help 08.22.51 # And if that bootloader is out, I need to research cache handling on PP5002. After that I want to bring dual core support on PP5002 on par with PP502x 08.23.34 # That will probably the most tricky part 08.27.33 # I suppse a while (1) { do { queue_wait(...) } while (flag); switch(ev) {} } 08.28.38 # The par should be real dual support PP502x though. 08.29.06 Quit w0rd54 (Read error: 104 (Connection reset by peer)) 08.30.45 Quit chrisjs169_ (Read error: 110 (Connection timed out)) 08.30.52 Join Rob2222 [0] (n=Miranda@p54B14EE6.dip.t-dialin.net) 08.31.06 Join TinoM [0] (n=Tino@i5387C514.versanet.de) 08.32.29 # amiconn: there is an odd problem with caching. it shows as those prefetch aborts using mpegplayer and they happen at the call to mpeg2_init. I can splash a message just before the call but a splash as the first thing in mpeg2_init is not seen. 08.32.56 # Llorean: are the daily voice files made with espeak? 08.34.58 Join aliask [0] (n=chatzill@c58-109-97-210.eburwd4.vic.optusnet.com.au) 08.35.06 # markun: With festival afaik 08.35.22 # yeah festival 08.35.38 # jhMikeS: I think dualcore support on PP5002 won't be different from PP502x once cache handling is figured out 08.36.27 # We don't know yet how to flush or invalidate properly. But I already found a cache setup function (while looking for something completely different, as usual) 08.38.30 # jhMikeS: Do you think a SYS_SUSPEND message would make sense? I now think it does... 08.38.53 # And that message should be acknowledged, like USB 08.38.55 # why not? it could be handling much like SYS_USB_CONNECT 08.39.00 # yup 08.39.11 # *handled even 08.39.40 # AT least 2 threads must do something on suspend. Backlight must switch off backlight regardless of settings, and pcm playback must shut down the codec 08.39.47 # (audio codec I mean) 08.39.54 # the sansa's cache setup values are not what are set in rb. i know that much. 08.40.17 # Perhaps some more cache RE is due also for PP502x? 08.41.01 # I think so. this error is too odd and no amount of flushing seems to solve it. maybe it does have some separate instruction lines. 08.41.55 # I doubt that, but perhaps flushing while running from cache doesn't flush everything? 08.42.16 # Did you try flushing from an iram function? 08.42.29 # never but could try it 08.42.54 # I had a similar problem in my suspend hack - the suspend function sends the dram controller to sleep, but it won't go to sleep while running from dram 08.43.14 # Now that I understand how it works, I put the function into iram and it works 08.43.20 Join MySic [0] (n=MySic@mur31-1-82-237-204-133.fbx.proxad.net) 08.43.28 # (it's just the OF's asm function hacked to pieces atm) 08.45.37 # If it weren't for the little H10 disk glitch I'd clean up and commit this core thing ASAP. I'll do the IRAM tester now though. 08.46.27 Join datasleep [0] (n=datachil@217-208-144-87-no75.tbcn.telia.com) 08.46.28 Quit BobShield (Read error: 104 (Connection reset by peer)) 08.46.53 Quit datachild (Nick collision from services.) 08.47.22 Join w0rd54 [0] (i=blackdev@66.252.10.185) 08.47.45 # jhMikeS: I would like to see it tested on other PP5020 targets. Unfortunately I also could test on H10 only 08.47.54 # linuxstb could test on ipod color 08.48.58 Quit Rob222241 (Read error: 110 (Connection timed out)) 08.48.59 # amiconn: well, maybe you'd notice something important and narrow it down. 08.50.44 # amiconn: do you still have LinusN's 5.5G ? 08.50.49 # yes 08.50.55 # do you use it at all ? 08.51.05 # No, only for testing 08.51.24 # hmm, then you've not likley noticed the issue I have 08.51.38 # which is that when "off" it seems to randomly turn itself on again all by itself 08.51.46 # I've noticed this a few times in the last couple of weeks 08.51.53 Join ender` [0] (i=krneki@84-255-206-8.static.dsl.t-2.net) 08.51.57 Quit webguest52 ("CGI:IRC (Ping timeout)") 08.52.02 # which certainly doesn't help the battery life issue 08.52.06 # GodEater: with the hold button on? 08.52.13 # even with the hold button on yes 08.52.21 # only then of course it starts into Apple OS mode 08.52.31 # argh ... why am I getting "relocation truncated to fit" ? isn't that foced long? 08.52.59 # Does the function have 'static' in front of it? 08.53.21 # yeah, just tried removing that 08.53.47 # Use STATICIRAM instead (which evaluates to nothing if the function must be called far) 08.53.52 # This is a gcc bug 08.53.55 # GodEater: A friend of mine with a 5G mentioned similar behaviour 08.54.14 # at first I though I'd not been shutting it down 08.54.16 # GodEater: Alarm setting? 08.54.22 # amiconn: I don't use it 08.54.29 # I never enabled that, and I also never saw that behaviour 08.54.57 # * GodEater goes to check to make doubly sure, but is pretty certain he's never even been into that menu 08.55.45 # yeah - definitely disabled 08.56.02 # jhMikeS: If you look at tata.c, you'll see several occurences of STATICIRAM. That's where I needed it for getting rid of sectioned compilation 08.56.23 # *ata.c 08.56.58 # I saw those in the encoder codecs too 08.58.22 # Ah, yes 08.58.35 # But ata.c is the only place in the core so far 08.59.07 Join B4gder [0] (n=daniel@static-213-115-255-230.sme.bredbandsbolaget.se) 09.00.05 # This problem occurs after using one cop using plugin and then mpegplayer but not the other way around 09.00.53 # What other plugin uses the cop? 09.01.45 # a tester for this. it makes it happen. my patch itself does not cause this problem but running it first can make it happen every time. 09.01.47 Join enyc_ [0] (n=enyc@router.1.whitehorse.co.uk) 09.01.52 # aha 09.01.59 # Well, the cop has its own cache 09.02.19 # all thread creation invalidates before running the thread 09.03.41 # When loading a plugin, both cores need to flush caches before loading the file into ram. While loading, the cop must not touch the plugin ram area 09.03.51 # like I said, I can run anything I want in video_thread up to the call to mpeg2_init which sends it off on some address past the plugin buffer or does the C0EDBABE thing...or sometimes DEADBEEE 09.04.32 # It doesn't. Threads on dual core are treated like entrypoints always. 09.04.35 # If the cop's cache is flushed when the plugin is already loaded, it will overwrite the plugin if it had some plugin data cached before 09.04.58 # I'm flushing just before the thread is removed. 09.05.25 # Then it still runs in plugin ram, doesn't it? 09.05.34 # There is a stall in the CPU thread to allow more than enough time for the thread to be gone into oblivion 09.06.13 # Yes, but the COP's cache will still have some data cached 09.06.17 Quit My_Sic ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 09.06.24 # it does and the caches are being invalidated 09.07.03 # ummm, from where? it's flushed _after_ it reenters core code. 09.07.19 Quit enyc (Connection timed out) 09.08.29 Join Jon-Kha_ [0] (n=Jon-Kha@80-248-243-10.cust.suomicom.fi) 09.09.22 # the plugin will not have exited before this is complete. it waits for 1/10 second before exiting plugin_start after getting the signal from the COP thread that it is terminating. the next thing the COP thread does after setting the flag is to call remove_thread 09.09.36 Join enyc [0] (n=enyc@1337.whitehorse.co.uk) 09.10.34 Join LinusN [0] (i=linus@rockbox/developer/LinusN) 09.10.38 Quit Jon-Kha_ (Client Quit) 09.11.43 # * Llorean wonders how long rockboxdev.sh will take under Msys and whether it will succeed. 09.12.06 # wth is Msys ? 09.12.14 # mingw32's shell. 09.12.20 # ah 09.12.21 # Or mingw rather 09.12.37 # I'm trying to see if it's possible, without too much insanity, to make voices with it. 09.12.40 Join petur [0] (n=petur@rockbox/developer/petur) 09.13.04 Join JajaComp [0] (i=d521d7aa@gateway/web/cgi-irc/labb.contactor.se/x-f7361cac4ba3e35f) 09.13.10 # Hello!!! 09.13.11 Quit aliask (Remote closed the connection) 09.13.22 # It's very slow. So very, very slow. 09.13.31 # How I can make rockmox sources? 09.13.38 # Llorean: Try sfu perhaps? 09.13.44 # RockBox 09.13.55 # amiconn: Oooh, forgot all about that 09.13.56 # * GodEater wonders if it's possible to run it under Microsoft's Services For Unix 09.14.01 # JajaComp: do you mean build them? 09.14.01 # amiconn: I'll finish this test, then give that a shot. 09.14.08 # GodEater: That's what amiconn just suggested. :) 09.14.09 # yes 09.14.13 # amiconn: odd thing is that the small test_queue plugin has no trouble running after mpegplayer and mpegplayer would certainly have overwritten the test. 09.14.27 # * GodEater didn't recognise the abbreviation as such 09.14.37 # JajaComp: http://www.rockbox.org/twiki/bin/view/Main/DocsIndex#For_Developers 09.14.58 # GodEater: I had to google it before it clicked. 09.15.11 Join aliask [0] (n=chatzill@c58-109-97-210.eburwd4.vic.optusnet.com.au) 09.15.30 # Of course, a part of the slow is probably the whole "msys in winxp in a VM" 09.15.47 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 09.15.53 Join nick89 [0] (i=nick89@c220-237-70-197.kelvn1.qld.optusnet.com.au) 09.16.03 # hey all 09.16.10 # * Llorean doesn't expect this to be done until after he sleeps. 09.19.13 Quit nick89 (Client Quit) 09.20.39 # JdGordon: did you notice we're still getting reports of "Filetype Array is full" even after your fixes yesterday ? 09.21.09 # GodEater: I'm pretty sure that's been patched now, for the time being 09.21.39 Quit enyc_ (Read error: 110 (Connection timed out)) 09.21.41 # should someone mention that in the thread then ? 09.21.56 # GodEater: yeah, I was expecting that, im half way through removing the array for good so didnt worry about it 09.22.04 # petur upped the size though so we should be good now 09.22.44 # hrm...IRAM doesn't make any differece 09.22.46 Quit w0rd54 (Read error: 104 (Connection reset by peer)) 09.22.50 # ah ok 09.23.26 Quit ldarby (Read error: 104 (Connection reset by peer)) 09.23.59 Quit markun (Remote closed the connection) 09.25.34 # How does a 55fps->68fps speedup sound? :) 09.25.48 # not worth the effort.... 09.25.55 # 09.26.02 # thank god 09.26.06 # I nearly spat my coffee out then 09.26.07 # like 13 more fps 09.26.17 # That's on 2nd gen 09.26.26 # I also sped up things on mini g2 09.26.31 # (but not as much) 09.27.08 # 3 changes: (1) Don't have the timeout in lcd_wait_write. Provided the controller isn't buggy, this will always work 09.27.36 # (2) For mini g2, the register setup doesn't need to be performed for every access. It's sufficient to do it on init 09.27.48 # (3) For PP5002, put lcd_write_data in iram 09.30.52 # * jhMikeS is clueless about this cache thing but ran into similar oddness when experimenting with the dual-core spc codec. 09.34.09 Join davina [0] (n=dave@cpc1-sout6-0-0-cust616.sotn.cable.ntl.com) 09.34.15 Join markun [0] (n=markun@rockbox/developer/markun) 09.38.49 Join webguest52 [0] (i=c023110a@gateway/web/cgi-irc/labb.contactor.se/x-6504a3dbba1c9532) 09.41.54 Quit Llorean (Read error: 104 (Connection reset by peer)) 09.41.55 Join Llorea1 [0] (n=llorean@cpe-70-113-103-34.austin.res.rr.com) 09.42.11 Nick Llorea1 is now known as Llorean (n=llorean@cpe-70-113-103-34.austin.res.rr.com) 09.42.19 Join w0rd54 [0] (i=blackdev@100mbit.top-site.us) 09.42.35 Quit perrikwp ("ChatZilla 0.9.78.1 [Firefox 2.0.0.6/2007072518]") 09.47.21 Quit webguest52 ("CGI:IRC") 09.49.28 Quit JdGordon ("Konversation terminated!") 09.51.01 Join JdGordon [0] (n=Miranda@c220-237-57-32.smelb1.vic.optusnet.com.au) 09.51.14 Quit JdGordon (Read error: 104 (Connection reset by peer)) 09.53.53 # * Llorean attempts the SFU route since his computer crashed anyway 09.54.25 # sfu is a huge download iirc 09.54.45 Join tvg [0] (n=Me@89-178-9-76.broadband.corbina.ru) 09.54.49 # Hi 09.55.24 # GodEater: 217mb looks like 09.55.31 # So far, assuming it doesn't go out and grab other bits 09.55.42 # Couldn't you integrate my language patch? 09.56.19 Join perrikwp [0] (n=chatzill@74.167.148.160) 09.56.35 *** Saving seen data "./dancer.seen" 09.56.57 # Llorean: sfu core is pretty much that 217MB, but you probably need some other packages for building rockbox 09.57.01 # (at least gmake) 09.57.45 # And package installation is commandline based, i.e. more difficult than cygwin 09.57.59 # tvg: which patch? 09.58.01 # * amiconn thinks the cygwin installer is quite nice for its job 09.58.25 # markun: this one: http://www.rockbox.org/tracker/task/7558 09.59.30 # amiconn: Is interix make not compatible? It sounds like it comes with its own version? 09.59.56 # Llorean: I would guess not, rockbox relies on gnu make extensions 10.00.03 # Well, last time I tried the provided 'make' didn't manage to build rockbox 10.00.15 # It doesn't know -C, for instance 10.00.18 # Ah 10.00.48 # tvg: I'll commit it later today 10.00.51 # nerochiaro: i believe daniel fixed it several days aago 10.01.00 # It wasn't significantly faster than cygwin so I didn't follow this route further 10.01.28 # markun: thank you, if there's something wrong, I'll correct soon. Bye. 10.01.36 # But the speed difference might be system dependent 10.01.50 # amiconn: It's going to be slow here anyway, I'm running in a VM 10.01.56 # B4gder: did you chose festival over espeak for the daily voice files because it sounds better? 10.02.07 # no, I just picked one 10.02.23 # my plan is to build multiple versions soon 10.02.33 Quit ctaylorr_ (Read error: 110 (Connection timed out)) 10.02.33 # ok, even better 10.03.21 # LinusN: ah, let me check 10.04.30 # B4gder: There was some talk earlier regarding a possibility to return to a single voice file 10.04.51 # (and perhaps also .lng file) 10.05.41 # sure, if it is done without too much pain in the targets sure 10.05.57 Join safetydan [0] (n=dan@rockbox/developer/safetydan) 10.06.55 Quit tvg ("Leaving") 10.07.11 # LinusN: it's indeed fixed. sorry for the noise and thanks 10.08.07 # amiconn: concatenating files doesn't sound like a good idea to me, since the file would be ridiculously big 10.08.17 # jhMikeS: The table method might be the way to go, and would open up some further possibilities 10.08.39 # LinusN: Yes, that was just the most basic example 10.10.09 # voice file header: a struct array with a target id and a pointer to the table for that target further into the file 10.10.24 # the voice file format would be rather complex 10.10.32 # The last entry in that array would be an end marker 10.10.57 Join rvvs89 [0] (n=rvvs89@unaffiliated/rvvs89) 10.11.04 # After that the tables for the targets are placed, and finally the individual clips 10.11.32 # the file would still be rather big, since each target can have different output for the same lang id 10.11.58 # Nope 10.12.16 # If there is different output for the same id right now, these ids must be split 10.12.39 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 10.12.44 # but that was the whole point with langv2, wasn't it? 10.12.46 Quit perrikwp ("ChatZilla 0.9.78.1 [Firefox 2.0.0.6/2007072518]") 10.12.53 # Not necessarily 10.13.21 # for example the button definitions 10.13.41 # one target says "SELECT" and another says "ON" etc 10.13.51 # The 2 points of langv2 were (1) to adjust texts per device and (2) save ram and binary size 10.14.12 # not only, but those were 2 of them 10.14.21 # But per-target voice files have a disadvantage that now shows up on the ml 10.14.33 # yes, and (1) means that the same lang id can have several voice clip representations 10.14.45 # Not everyone can build voice files, and the central build server can't provide all voice files either 10.14.55 # (there are dozens of supported languages) 10.15.09 # the central server could indeed collect all voices 10.15.16 Quit Llorean (Read error: 104 (Connection reset by peer)) 10.15.18 # it wouldn't have to build them all itself 10.15.23 # No it can't 10.15.29 # it _could_ 10.15.44 # Only for freely distributable voices 10.16.04 # LinusN: Yes, but taking this further, nothing speaks against splitting these into several IDs, provided that each target only loads the IDs it needs 10.16.06 # yeah, but all these ones we talk about are what people distribute 10.16.12 # error - "Invalid option 'long-calls'" ??? 10.16.13 # do they must be distributable 10.16.24 # whot is? 10.16.38 # amiconn: take LANG_CONFIRM_WITH_BUTTON as an example 10.16.43 # JajaComp: you have a bad compiler version, go back and read CrossCompiler 10.16.57 # (which isn't voiced at the moment) 10.17.26 # LinusN: Yes, and? SPlit these into LANG_CONFIRM_WITH_PLAY, LANG_CONFIRM_WITH_SELECT etc 10.17.27 # but when it is, it will have several versions depending on the target 10.17.44 # but yeah, by making a huge voice file with a more complex header and sections the target separation can be done load-time instead of build-time 10.17.48 # amiconn: but we just merged them!!! 10.17.57 Quit gtkspert (Remote closed the connection) 10.18.04 Join obo [0] (n=obo@rockbox/developer/obo) 10.18.10 # The point is that the implementation should only load those which are needed on the specific target 10.18.28 # I would say that they should not be split in different IDs in the lang file nor in the code 10.18.33 Join gtkspert [0] (n=gtkspert@gateless.info) 10.18.41 # They key is that an empty id has to be cheap, otherwise it won't work out nicely 10.18.41 # but it would somehow get done behind the schene 10.18.49 # B4gder: i agree 10.19.00 # Hmm, even that is possible 10.19.32 Quit kubiix ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 10.19.37 # otherwise we would have tons of #ifdefs in the code 10.19.42 Join pixelma [0] (i=pixelma@rockbox/staff/pixelma) 10.19.50 # Nothing stops the per-target tables to point to a different clip for the same id 10.20.01 # nope 10.20.29 # And it would be better because there are less empty IDs 10.20.35 # then again, what is the problem with target specific voice files? 10.21.21 # it certainly is more kiss like this 10.21.32 # in the target 10.21.54 # exactly 10.22.21 # LinusN: The problem is that they're target specific. (1) One needs to download or make the correct version for your target, otherwise some options won't be voiced, or worse, would be voiced wrong 10.23.02 Join Llorean [0] (n=llorean@cpe-70-113-103-34.austin.res.rr.com) 10.23.03 # not much different from how it would be with a unified file, is it? 10.23.09 # (2) Imagine someone making a voice file with a not freely distributable voice for several of his blind frieds, which have different rockboxable devices 10.23.15 # My windows VM keeps crashing me. :( 10.23.38 # amiconn: this person would have to build several files 10.23.42 # Making one file and giving it to all of them would certainly be better 10.24.02 # and he wouldn't be allowed to distribute them in the first place so he only needs to build for his own target ,*) 10.24.09 # :-) 10.24.23 # Assuming he was able to build them under Windows :) 10.24.36 # :-) 10.24.39 # B4gder: That's not quite correct. Giving away the file to persons you know doesn't count as distribution 10.24.42 # I like the idea of self-built via RBUtil best. 10.24.44 # yeah, but I guess in the end someone using Windows will step forwards 10.24.54 # amiconn: it depends on where you are 10.25.04 # pondlife: RBUtil building them will probably be the best plan 10.25.05 # i.e. don't concentrate effort on distributables, more on enabling. 10.26.02 # yeah 10.26.16 # but the problem is, as often in this project, when there's windows stuff involved 10.26.26 # as we quickly provide linux solutions 10.26.26 # B4gder: The at&t license states that iirc (that you can give the output to others, as long as you don't make it publicly available) 10.27.09 # I still don't care much about the people using those voices 10.27.14 # they are evil 10.27.44 # but that's beside the point here anyway 10.27.59 # People should be able to use whatever voice they have available, for both .voice and .talk files. That's the basic point. 10.28.22 # yes 10.28.25 # The voices sound way better than festival 10.28.39 # amiconn: that is entirelly besides the point for all this 10.28.48 # That implies self-built is the way to go. 10.29.46 Join wippeout [0] (n=wippeout@jma42-1-88-169-39-211.fbx.proxad.net) 10.29.48 # hello 10.29.55 # LinusN, B4gder: Regarding the amount of KISS, I tend to think that it won't change much. Certainly less than some other, recent changes & additions 10.30.08 # The Ondio already has some kind of chunked loading 10.30.48 # The more I think about it, the more I like the idea. Especially since it also provides an easy path towards voice in plugins 10.31.17 # (another goal of langv2 we didn't achieve yet) 10.31.29 # as I said, U 10.31.33 # I'm not against the idea 10.32.00 # I am against letting the whiners on the users list set the agenda though 10.32.23 # being blind is not an excuse for being ignorant 10.33.02 # I'll volunteer to adapt the language scripts for a modified system towards unified voice file 10.33.23 # hi wippeout 10.33.24 # I don't see a unified voice file as desirable 10.33.45 # pondlife: why not? 10.33.50 # Not if it's bigger than a dedicated one (i.e. less audio buffer) 10.33.50 # too much wasted space? 10.33.59 # space where? 10.34.19 # Why not just have a policy of build-it-yourself ? 10.34.19 Join bluebrother [0] (i=0g1aBuri@rockbox/staff/bluebrother) 10.34.39 # markun: it would only load the clips for the target in question 10.34.49 # Ah, ok 10.34.58 # but it would still be a megabyte or two wasted in storage 10.34.59 # so the buffer usage would be the same as the current files 10.35.08 # B4gder: yes 10.35.16 # And bandwidth 10.35.53 # Particularly for home users with limited upstream 10.36.07 # i.e. those complaining on the ML 10.36.22 # now you lost me 10.36.29 # yeah, but supplying 22 voice files is more data than one unified 10.36.47 # Yes, but I would only download the H300 file, not them all. 10.36.48 # what does the upstream have to do with it? 10.37.21 # upstream, the ones uploading files, would benefit from a unified 10.37.21 # pondlife: The idea is that each target only loads the clips it needs into ram 10.37.30 # could someone please have a look at http://members.iinet.net.au/~ddalton/time.diff and tell me where I have done the indentation wrong? 10.37.39 # I know, but how much bigger would the .voice file be? Say 20%? 10.37.50 # rasher: text2wav textfile -o wavfile.wav for festival without using it as a server. 10.37.51 # I'd guess at more than 20% 10.37.58 # pondlife: something along those lines 10.38.07 # The per-target tables in the beginning won't be big, just an offset and a length per clip used 10.38.21 # So if a target uses 500 clips, that's 4KB 10.38.28 # So if I download Andre's voice file for my H300, I'm using 20% more of his limited upstream bandwidth. 10.38.37 # yeah, its the clips that'll do the size diff not really the tables 10.38.50 # pondlife: ah, yes 10.38.54 # For 30 targets, that's 120KB 10.39.21 # hey, I can check the total size of all clips... 10.39.26 # as a comparison 10.39.27 # It's not a biggie, but I just think any coding effort should be aimed at making self-build easy for all users. 10.39.51 # i.e. spend our time on MakeVoices.vbs and RBUtil. 10.39.57 # ddalton: Too much indentation. 10.39.58 # The clips would then include all alternatives, but I think the whole file will be <50% larger than one of the swcodec files today 10.40.10 # While Rockbox itself is KISSed. 10.40.19 # we have 655 different phrases 10.40.31 # the total voice pool is ~2.5MB 10.40.36 # ids 10.40.59 # LinusN: And how much of that is included in an average voice file? 10.41.01 # which then is >50% 10.41.13 # Btw, it depends on the voice used how large the pool is 10.41.27 # amiconn: between 800K and 1.3MB 10.41.27 # let's do these ones now for comparison 10.41.32 # I can use gcc 4.1.2 to compile RockBox? 10.41.40 # JajaComp: read CrossCompiler again 10.42.11 # i don't now how uninstall gcc 4.1.2 10.42.22 # Well, let it be twice as large 10.42.36 # JajaComp: why uninstall it? 10.42.53 # it's default compiller in my system 10.43.01 # BTW has anyone tested that my configure patch (for Cygwin voice building) doesn't break Linux voice building (or indeed program building). I'd like to commit it. 10.43.02 # then it's not a cross compiler 10.43.28 # you can use gcc 4.1.2 to build the crosscompiler to build rockbox 10.43.29 # i'm beginning to like the idea of a unified voice file 10.44.10 # consisting of the entire voice pool and a table per target 10.44.45 # I like how it can also fix the plugin voice problem 10.44.51 # It has advantages for our distribution (less overall file size), for users (less confusion of which files to use), and especially for users with different targets, or users downloading voices for other users as well 10.44.51 # but the loading will be complex, involving plenty of seeking 10.44.57 # what plugin voice problem? 10.45.06 # ddalton: plugins aren't voiced today 10.45.16 # LinusN: Only forward seeking if done right (except on Ondio) 10.45.40 # seeking like mad, yes 10.45.48 Join PaulJam [0] (n=pauljam@p54BCCC91.dip.t-dialin.net) 10.46.01 # The only disadvantage is that users which only need voice on one single target need to download a larger file 10.46.11 # amiconn: true, it could optimize for only forward seeking by sorting the clip indexes 10.46.18 # which is 99% of the users :-) 10.46.21 # how? --enable-libssp=no??? 10.46.50 # B4gder: They would still profit from less confusion, and from the ability to use other user's voice files 10.46.57 # sure 10.47.09 # but 10.47.14 # i think ease of use outweighs the file size 10.47.16 # they will not get an easier build system 10.47.20 # I see error "cc1: Invalid option 'long-calls'" 10.47.30 # B4gder: that is true 10.47.43 # 97% of users only want files for a single target... another made-up statistic. 10.47.43 # amiconn: Under that system, couldn't users still generate a target-specific file if they wanted? 10.47.51 # Llorean: yes 10.47.54 # JajaComp: which instructions are you following? 10.47.55 # If file size was a concern. 10.48.04 # For us people with tiny amounts free, and all. 10.48.13 # A target specific file would only include the table for one target and the needed clips 10.48.23 # Llorean: ah yes they could 10.48.34 # B4gder: It's more or less a best of both worlds deal. ;) 10.48.34 # amiconn: it could even include empty tables for the other targets 10.48.52 # LinusN: Yes, but that's not needed 10.49.08 # If a target can't find its matching table, it simply won't load the voice file 10.49.23 # exactly 10.49.34 # it would need to scan for its own target section 10.49.34 # i like this 10.49.45 # Yes, that makes sense. 10.49.57 # But ALSO work on the self-build stuff... :) 10.49.59 # now over to how to build the voices without a compiler 10.50.31 # i guess a rudimentary c preprocessor implementation is needed 10.50.38 # yes 10.50.48 # I happen to have one 10.50.55 # in perl? 10.51.09 # no in C, but I'm quite sure it builds fine on windows too 10.51.31 # or could be made to without too much pain 10.51.44 # http://daniel.haxx.se/projects/fcpp/ 10.52.16 # If we're using a non-standard C program, why not make it do the whole thing? 10.52.37 # Or we could hunt down a C preprocessor in perl. I'll bet one or five exist. 10.52.38 # ugh 10.52.52 # pondlife: because I don't wanna do the whole voice process in C 10.53.06 # Llorean: indeed 10.53.46 # like http://www.cabaret.demon.co.uk/filepp/ 10.53.49 # Hmm, I suppose RBUtil will hide any complexity and make it accessible. 10.54.03 # B4gder: Exactly what I found 10.54.07 # Was looking for a license. 10.54.21 # There's a debian package for it, it seems, so I have to assume it's in the clear. 10.54.31 # GPLv2, okay 10.55.04 # seems like a fine candidate for this then 10.56.10 # I seem to recall there being other situations where configure demanded a compiler and I didn't think it reasonable to expect one. Manual maybe? Could it clear these up to? 10.56.10 # Hmm, does this not mean that Windows users will need perl? 10.56.37 # * pondlife is not much experienced with scripting. 10.57.02 # Or can it be bundled into the RBUtil distribution... 10.57.02 # I really don't think building voices without perl is a worthwhile effort 10.57.25 # genlang is perl to start with 10.57.29 # Ah, ok 10.58.04 # so we've required perl for voices for a long time already 10.58.51 # Yes, but is it required for MakeVoices.vbs? I'm fairly sure I've not installed it (aside from inside Cygwin). 10.59.52 # if they do it without perl they either re-implemented lots of genlang stuff or built the voices wrong 11.00.25 # I've never looked at that script 11.00.26 # Wasn't it [IDC]Dragon who wrote it? 11.00.37 # yes 11.00.38 # Or amiconn? Will look.... 11.00.41 # but 11.00.44 # B4gder: Oh, btw, iPod Nano voice files are broken. 11.00.54 # back when we only had a single voice for all 11.01.06 # so I added an "old format" support for genlang 11.01.09 # to feed that script with 11.01.09 # Or at least, the one I built was, but the Gigabeat one was fine. 11.01.20 # MakeVoices.vbs was written by me 11.01.48 # still, it needs its input as given by genlang -o 11.01.51 # if I download an old revision and add a old patch. then I run svn up and then make a diff will this work? 11.02.01 # ddalton: perhaps, and perhaps not 11.03.31 # Yes, it does, since langv2 (first step) went in 11.04.17 # So this has been a prereq for a while now... 11.04.20 # ? 11.04.22 # But pretty much everything that can be done in perl can also be done in vbscript, so once things stabilize, there is nothing that would stop a vbscript version for folks without cygwin 11.04.52 # right, everyone is free to do what they want of course 11.04.52 # Folks with Cygwin should just make voice same as Linux users anyway. 11.04.59 # (yes, vbscript does have a regex engine, just that not many people use it. MakeVoices.vbs does) 11.05.26 # its just that as usual, I expect the linux/cygwin perl method to stay up-to-date and accurate 11.05.30 # One problem atm is the need of a C preprocessor 11.05.31 # and all other efforts will lag 11.05.53 # That won't go away with unified voice files either 11.06.16 # no, and I prefer the unified voice build way anyway 11.06.19 Quit PaulJam (".") 11.06.30 Join n1s [0] (n=nils@h218n1fls35o293.telia.com) 11.07.00 # But there's also perl for windows (activestate perl), so that shouldn't stop us 11.07.20 # And activestate perl integrates with activescripting, so it should even be able to use sapi objects etc 11.07.36 # since people have build voices for a while, clearly perl has not been a major hurdle to them 11.08.48 # What is the best way to voice a gui_syncsplash screen? 11.12.25 # ddalton: maybe you can have a look at how it's done in other places 11.16.22 # OK, one more try.. Please can someone who's got Linux (or VMWare) running try http://www.rockbox.org/tracker/task/7560 out and check it doesn't break the Linux build processes. 11.16.42 # I want to commit, but not break the daily voice build! That would not be popular at this point... 11.17.47 Quit desowin (Read error: 110 (Connection timed out)) 11.19.46 Quit courtc (Read error: 113 (No route to host)) 11.20.29 Join PaulJam [0] (n=pauljam@p54BCFFB0.dip.t-dialin.net) 11.23.49 # pondlife: ok, I'll try it 11.25.26 # B4gder: Iiuc you already implemented one part of building unified voice files (the clip cache) 11.26.01 # rasher made that really, I just used his work 11.26.14 # n1s: Thanks 11.26.14 # but yes the foundation is there 11.26.36 Join haemmy [0] (n=stefan@194.208.162.140) 11.26.39 # Ok, whoever did it, it's there :) 11.26.49 # Dontcha just love OSS :) 11.27.42 # hmm, voice crashes seem related to resuming playback on startup 11.28.20 # * pondlife does the "no voice codec swap" chant too 11.28.33 # n1s: If so, I suspect a race in the voce & playback init, combined with the voiced splashes 11.29.35 # pondlife: Yeah, just that there is a problem: no voice codec swap means (almost) no iram for the voice codec 11.29.57 # I'm still not convinced that MP3 mono 22kHz playback needs IRAM. 11.30.09 # Some targets probably can't cope 11.30.28 # No, pure voice maybe doesn't need it, but what about voice during playback? 11.30.28 # Ipod 1G would suffer most, right? 11.30.44 # 1/2G 11.31.19 # It should be easy to experiment with - disable IRAM for the MP3 codec and play some AAC (or WMA) with voice. 11.31.21 # 1/2/3G, and perhaps all coldfire targets 11.31.34 # Compare with and without. 11.31.39 # Remember that coldfire has no data cache 11.32.38 # Buit we're only needing one quarter of the data rate than for normal MP3 playback. 11.33.05 # I did an experiment a while ago - running with caches disabled on PP5022 11.33.22 # It was ~7x as slow... 11.33.40 # Ouch 11.33.48 # pondlife: working voice file built with patch, no problem :-9 11.33.50 # :-) 11.33.51 # Ouch indeed, but expectable 11.34.04 # n1s: You mean using festival? 11.34.15 # pondlife: I used flite 11.34.19 # OK 11.34.45 # * n1s goes to eat pie, bbiab 11.34.47 # How about building Rockbox itself. I don't think I broke anything but rasher's configure mod also happens. 11.34.53 # Oops, too late 11.35.15 # * pondlife may finish that sentence later. 11.35.35 # I didn't check what samplerate the new voice files use. Before per-target voice, it was common to use 12kHz 11.37.09 # We must avoid using 11kHz for archos player. Other than that, all standard mp3 sample rates are possible, with only one further constraint for all archoses: For mpeg2.5 sample rates, we must use lame -B 64 11.37.41 # (limit maximum bitrate to 64kbps - voice files are vbr) 11.40.53 Quit maffe (Remote closed the connection) 11.41.42 Join My_Sic [0] (n=MySic@mur31-1-82-237-204-133.fbx.proxad.net) 11.42.51 # hi, i have a little question about the custom icons: with some recent svn change the items in the open_with menu now have an icon, and i was wondering if there is a way to specify which icon will be used for which viewer. i guess the viewers.config specifies the icon, but that file gets overwritten on every update. is there another way to do this? 11.45.19 # Hmm, a unified voice file would have to deal with bitswapping... 11.45.26 # PaulJam: the icon the plugin is listed with first is the icon shown 11.45.46 # PaulJam: using the .icons file will also work 11.47.44 # JdGordon: how? if i want for example to use icon 0 for the text_editor in the open with menu, what line would i have to put in the .icons file? 11.48.27 # hmm... yeah, you cant.. 11.48.30 # * JdGordon forgot 11.48.40 # the .icons is for extensions 11.48.56 # you have to use viewers.config.. for now... im working on fixing this 11.49.25 # ok, thanks. then i guess the best solution is to use the same order of the icons like in svn. 11.52.03 Quit obo ("bye") 11.54.26 Quit MySic ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 11.56.40 *** Saving seen data "./dancer.seen" 12.05.58 Quit nerochiaro ("leaving") 12.12.44 Quit PaulJam (".") 12.17.00 Join maffe [0] (n=maffe@barmen.interhost.no) 12.17.06 Join Febs_ [0] (n=chatzill@207-172-204-33.c3-0.rdl-ubr4.trpr-rdl.pa.cable.rcn.com) 12.17.21 Quit bluebrother (Read error: 113 (No route to host)) 12.18.29 Join spiorf [0] (n=spiorf@host189-215-dynamic.9-87-r.retail.telecomitalia.it) 12.23.14 Join bluebrother [0] (i=ixe9kVet@nat-wh-1.rz.uni-karlsruhe.de) 12.25.06 Quit rvvs89 ("bai") 12.25.34 # pondlife: rockbox builds fine, both normal h300 build and sim 12.26.54 # OK, I'll commit it now... 2 questions: 1) Are there some special property changes required when adding a file to SVN? 2) Anyone mind me commit .VBS files for the SAPI interface? 12.27.08 # s/commit/committing in that last bit. 12.27.18 Quit BigMac (Read error: 110 (Connection timed out)) 12.28.15 # The vbscript will probably need an svn:eol-style property 12.28.53 # OK, I'm about to lose power here so will commit a bit later 12.28.53 # pondlife: UsingSVN says you should set the keywords property 12.29.12 # Ah, I was looking for that in the wiki, but missed it. 12.29.19 Quit pondlife ("power down") 12.33.16 Join adam2 [0] (n=get@220-245-250-49.free.tpgi.com.au) 12.33.54 # is there anybody out there? 12.34.05 # I'm in, not out! 12.34.15 # cool 12.35.57 Quit JajaComp ("CGI:IRC (EOF)") 12.37.26 Quit Febs (Read error: 110 (Connection timed out)) 12.38.53 # i've got a gigabeat s60 guts only (no hdd or battery and lcd cracked) any use to rockbox developers for tracing cuicuits on the main board or not really? 12.39.41 # aliask is one of the gigabeast S dudes, he might have an answer 12.40.19 # toffe82 as well...he builds up stockpiles of gigabeat parts 12.40.29 # For hardware things I'd refer to toffe82 12.41.32 # But if someone accidentally flashes their player it could be a saviour 12.41.46 # Flashes garbage, that is. 12.42.49 # you recon i should try puting it on ebay with the battery and hdd? see if i can get some $'s back for the new 1 i got....>? 12.44.25 Part Llorean 12.47.43 Join ctaylorr [0] (n=ctaylorr@CPE001839ae25b4-CM0011aea4a276.cpe.net.cable.rogers.com) 12.47.56 Join adam3 [0] (n=get@220-245-250-49.free.tpgi.com.au) 12.48.48 Quit adam3 (Client Quit) 12.52.20 # * preglow finds out about plugin categories 12.52.27 # is this just a directory thing, or something more fancy? 12.52.43 # Hmmm 12.53.07 # JdGordon: Why is mandelbrot sorted into games, btw? 12.53.14 # It's surely not a game 12.53.27 # preglow: dirs with localizable menu to enter them 12.53.39 Join DerPapst [0] (n=DerPapst@tux.isd-internet.de) 12.53.46 # good day 12.54.01 # amiconn: a mistake? 12.55.11 # at least my vinyl preamp plug seems to work somewhat 12.55.42 # * amiconn wonders what that plugin does 12.55.56 # riaa deemphasis? 12.56.18 # * DerPapst wondered that too yesterday. 12.57.26 # amiconn: aye 12.57.58 # seems i'm doing something wrong, though, there's quite a bit of treble missing 12.59.10 Join amiconn_ [0] (n=jens@rockbox/developer/amiconn) 12.59.19 Join XavierGr [0] (n=xavier@ppp158-53.adsl.forthnet.gr) 12.59.20 Quit amiconn (Nick collision from services.) 12.59.22 Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) 12.59.29 # adam2: if the hdd is working you could try to sell it separately 12.59.32 # same for the LCD 12.59.40 # there's a bloody paper on this somewhere, but it's published by ieee, which loves taking cash for them 12.59.44 # arghgh 12.59.56 # preglow: I can download it for you 13.00.05 # do you have a link? 13.00.16 # lcd is cracked, hdd and battery is on ebay for auction 13.00.31 # preglow: Now if this could be selected for recording... 13.00.34 # preglow: at least I hope I can.. 13.00.51 # markun: that would rock, i'll dig up the url 13.01.00 # markun: i used to be able to too, but not anymore, apparently... 13.01.05 # adam2: Actually, I think I could use it for serial debugging 13.01.30 # amiconn: i probably need to compensate for the pickup as well, i think 13.01.34 # adam2: Do you mind if I PM you? 13.01.40 # aliask: np 13.01.47 # most vinyl preamps have an mm/mc switch 13.02.45 # Yes, as MM output voltage is roughly one order of magnitude higher than MC output voltage 13.03.17 # so it's just an amplitude thing? 13.03.32 # i quite obviously need some kind of extra filtering here, the treble sucks 13.05.22 # DerPapst: Do you still have the patch I gave you? 13.08.59 # amiconn: any idea on how many db gain you'd typically have to apply to gain a turntable signal to line in levels? 13.09.08 # i'm using 48 db right now, and that works just peachy 13.09.10 # but feels like i can do more 13.09.22 # amiconn: yes 13.09.29 # think i'll just add a control for that 13.09.39 # preglow: using 48dB on the iriver will be quite noisy 13.09.48 # petur: sounds okish 13.09.54 # remember we're talking vinyl here :) 13.09.59 # heh 13.10.01 # DerPapst: Iirc you said the 3rd gen also suffers from blacklevel varying with display content? 13.10.22 # You could try a small modification of my patch 13.10.56 # Find the void lcd_init_device(void) line, and within that function, the #elif defined IPOD_3G part 13.11.11 # (can't tell a line number 'case my lcd driver contains further patches) 13.11.39 # amiconn: i'm at work currently. so i can do that test at 19:00 when i'm at home again. 13.11.55 # Then change the power_reg_h = 0x1500; in the if... branch to power_reg_h = 0x1520; 13.12.10 # ok. i'll do that then. 13.12.31 # After installing this build, the lcd should behave like before, until you call 'View HW Info' once. Afterwards the blacklevel should vary less 13.12.40 # (until reboot) 13.13.24 # Those bits increase the frequency the voltage multiplier is running at, making the voltage more stable (and needing a tiny bit more power) 13.13.41 # amiconn: sounds good :) 13.14.12 # petur: is the adc gaining done purely in the digital domain, or? 13.14.17 Part adam2 13.14.35 # That wouldn't make sense imo 13.14.51 # 24dB analog, the rest digital (but on the internal 24(?)bit, not our 16bit 13.15.42 # preglow: http://www.euronet.nl/~mgw/background/riaa/uk_riaa_background_1.html 13.17.21 # a gem: made rockbox is easy.. developers even have no ipods, just writing easy code and its work. 13.17.45 # yay 13.17.48 # * scorche goes about adding that to GoldenQuotes with other Colombo stuff 13.17.54 # haha 13.17.56 # he is in #ipodlinux if you want to chat 13.18.03 # *g* 13.18.46 # * DerPapst enjoys Colombo as well 13.19.01 # B4gder: btw thanks for cURL :D 13.19.04 # DerPapst: isnt this entertaining? =P 13.19.11 # indeed it is ;) 13.19.13 # DerPapst: you're welcome! 13.20.26 Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) 13.21.02 # hmm, we actually call talk_init() 3 times during a regular boot, feels kind of hackish... 13.22.18 # hehe...colombo is up to 3 in GoldenQuotes now.. 13.22.45 Join Llorean [0] (n=llorean@cpe-70-113-103-34.austin.res.rr.com) 13.24.02 # n1s: amen 13.24.22 # How do I build a voice file using p7560? 13.24.26 # n1s: On all targets? 13.26.47 # amiconn: on sw-codec at least in init() in main.c, first we call settings_apply() which calls talk_init() then we call talk_init() and then audio_init() which also calls talk_init() hwcodec may only call it twice, havent looked at audio_init() for those 13.27.22 Quit ToHellWithGA (Nick collision from services.) 13.27.30 Join ToHellWithGA [0] (n=ryan@d17-137.rt2-bras.clm.centurytel.net) 13.27.36 # the good news is that removing the call in settings_apply() seems to fix the crashing (this is not a solution however) 13.28.16 # gtg 13.28.25 # settings_apply() needs to call talk_init() in case changing the language changes availability of voice 13.28.36 # (afaik) 13.30.27 # note to self: disable idle timeout in dsp plugs :> 13.31.53 # after about ten minutes of music i got what i assumed was my speakers blowing :D 13.32.16 # lol 13.32.41 # B4gder: he seems to be mute for now, but perhaps he shall come back and enlighten us... 13.33.17 # :-) 13.34.25 Quit safetydan ("Ex-Chat") 13.36.59 Quit spiorf (Read error: 110 (Connection timed out)) 13.37.37 Join spiorf [0] (n=spiorf@host191-206-dynamic.8-87-r.retail.telecomitalia.it) 13.43.31 # amiconn: yes, but should I kill the other call or thell settings_apply to not call the init when we start up? 13.43.51 # I mean kill the other call and rely on the one in settings apply? 13.44.36 # Good question... 13.48.09 # I still don't know why this causes the hangs though... 13.49.21 # jhMikeS: What is the value of DEV_EN on Sansa? 13.49.43 # ...and how good is battery runtime compared with OF? 13.50.05 # I *think* on the Sansa we get about 3/4 of the OF 13.50.31 # The performance gap isn't as big as it is on other portalplayers as far as people seem to say, I haven't done an explicit test 13.50.52 # How is the ratio on Nano? 13.51.24 # I think I get about 8, Apple claims 14. 13.51.28 # But that 8 is from a long time ago. 13.51.35 # And my battery's now a year and a half old 13.52.40 # I wish the IpodRuntime page include AppleOS ones 13.52.50 # Reboot 13.52.58 Quit DerPapst (Read error: 104 (Connection reset by peer)) 13.53.17 Nick chrisjs169__ is now known as chrisjs169 (n=chrisjs@pool-71-254-214-208.hrbgpa.east.verizon.net) 13.53.21 # Hmm, I would really like to see the DEV_EN value from Sansa 13.53.31 # Anyone with a Sansa who could check? 13.53.49 # Well, I've got one 13.53.59 Quit haemmy () 13.54.03 # What do I need to do? 13.54.05 Join webguest64 [0] (i=57b5e70f@gateway/web/cgi-irc/labb.contactor.se/x-e18d24a7ef8a8dff) 13.54.13 # View I/O Port 13.54.14 # s 13.54.17 # Alright 13.55.02 # I don't see anything named DEV_EN on that screen? Do I need a newer build, or is it the DEV_0x34? 13.55.43 # You need a newer build then 13.55.53 Join DerPapst [0] (n=DerPapst@tux.isd-internet.de) 13.56.08 # Alright, gimme a minute. 13.56.09 # I committed DEV_EN display on Aug 3, so an Aug 4 daily should do 13.56.31 # Yeah, mine's from before my trip, so July 27 or so 13.56.41 *** Saving seen data "./dancer.seen" 13.57.22 # DEV_0x34 is DEV_TIMING1 13.57.26 # Hi - jemand aus deutschland hier , der mir sagen kann, ob rockbox auf meinen zen xtra 30gb drauf geht? 13.57.49 # webguest64: this is an english channel 13.57.52 # (but I do not yet understand what it actually does) 13.58.50 Quit ddalton ("I was using BOFHNet IRC version 1.2 by fmillion - get your copy today from http://www.the-bofh.com/bofhnet/irc !") 13.59.39 # * amiconn suspects there's a secondary DEV_EN on PP502x, like there is on PP5002 13.59.42 # ok thx - so anyone kann tell me if rockbox works on my zen xtra 30 gb ? 13.59.58 # amiconn: C440597F 14.00.01 # webguest64: No. 14.00.09 # webguest64: It only runs on the players listed on the site. 14.01.48 # Llorean: thx. 14.01.50 Join pondlife [0] (n=Miranda@cpc1-rdng11-0-0-cust362.winn.cable.ntl.com) 14.02.14 # C... and ...97f seems to be common on all PP502x targets 14.02.22 # what a pity 14.02.30 # thx 14.02.34 # But the inbetween bits differ 14.03.02 # C2C1197F here 14.03.02 Quit webguest64 ("CGI:IRC (EOF)") 14.03.09 # which is 5.5G of course 14.05.07 # I know the G5.5 value... 14.05.09 # And magically today my Nano can dump its ROM. 14.05.12 # Weird 14.05.22 # Ah, that reminds me 14.05.34 # sorry amiconn, was just letting Llorean know in case he was curious 14.05.45 # GodEater: Same value as my Nano, anyway 14.06.05 # * GodEater looks at the two values... 14.06.19 # Mini G2 sets the same as G5.5, and H10/6GB sets 0xC240197F 14.06.49 # Llorean: your nano is wired. ;) 14.06.55 # DerPapst: Very 14.06.57 # Some of the bits are documented in the ipl wiki, but at least 2 of them must be wrong 14.07.11 # Now when I say "Dump Rom" there's no UI delay at all. Not even the slight delay it had before while writing. 14.07.30 # *gasp* - ipl be wrong?!?! 14.07.32 # surely not 14.08.13 # i doubt that too. 14.08.14 # Well, they say bit 29 is IDE0 and bit 14 is ATA. Apart from that it is rather unlikely, both bits aren't set on any ipod 14.08.38 # But then bit 14 is set on Sansa which has no ATA 14.10.40 # * preglow tries to figure out the menu macro system 14.10.53 # Ehm, seems I can't read 14.11.07 # ...and that _is_ set on ipods and H10, but not on Sansa 14.12.19 # That still leaves several set bits unexplained 14.13.53 # win 16 14.13.57 # Bits 0, 1, 3, 4, 5, 8, 30, 31 14.14.16 # what's up with declaring menu variables with a macro? 14.14.22 # (and, not set on ipods, bit 14, 21 and 26) 14.16.16 # sometimes rockbox goes unresponsive after starting when i insert usb during startup, anyone had this before? 14.17.23 # Yes, that's a known problem 14.17.27 # hrmph :/ 14.17.29 Quit B4gder ("It is time to say MOOO") 14.17.34 # Happens since active usb detection was introduced 14.17.43 # who introduced that? 14.17.43 Part LinusN 14.18.18 # ...but it doesn't happen every time. It's more likely to happen when USB is already plugged at boot though 14.18.19 # * Llorean sighs. 14.18.32 # * elinenbe sighs too. 14.18.36 # I really don't think "expecting users to read the development list if they want to know what's going on with development" alienates users. 14.19.27 # USB detection on iPods is funky anyway. The "hold menu to prevent reboot" hardly works right now 14.19.43 # It works. YOu just need to hold Menu long enough 14.19.44 # you have to hold it for a few seconds 14.19.49 # >10 seconds 14.19.49 # well it does - but you have to hold it a LOOOONg time 14.19.51 # Llorean: nah, i'd say that is fair 14.20.11 # preglow: There are a lot of upset blind people on the list regarding the voice file changes. 14.20.20 # * elinenbe thinks 10 seconds is just too long. Maybe it should be changed to 3 seconds. 14.20.26 # And I'm kinda of the opinion "it's been in the works for a year and a half, and nobody kept it a secret" 14.20.38 # amiconn: I tried twenty seconds on my Nano 14.20.41 # It's just not reliable. 14.20.49 Join Ishi`` [0] (i=Ishi__@cro34-3-82-236-92-216.fbx.proxad.net) 14.21.00 # elinenbe: it's not intended to be 10 seconds 14.21.00 Quit miepchen^schlaf (Read error: 104 (Connection reset by peer)) 14.21.20 # Llorean: so i see 14.21.23 # It works for firewire. I still think we need to change state of the USB controller if we want to stop it 14.21.23 # GodEater: ah... so that's the problem! 14.21.35 # elinenbe: yes! 14.21.46 # i don't really think we had to bring out the big banners for that 14.21.53 # we're in development anyway 14.21.53 # GodEater: Do you REALLY eat god? 14.21.58 # (and that probably would solve the undetected usb device problem, and also be a bit linux friendlier with its sensitive usb stack) 14.22.19 # elinenbe: off topic.... 14.22.39 # preglow: That's my opinion. "If you download development builds, expect things to change. If you want to know what's going to change, pay attention to development. If you don't want things to change, don't change builds." 14.22.59 # preglow, Llorean: It would probably be less of an issue if Rockbox did releases more than every couple of years 14.23.03 # But we want users to try new builds... 14.23.11 # GodEater: not THAT off... 14.23.13 # amiconn: I'm all for users to try new builds. 14.23.28 Quit TinoM (Read error: 113 (No route to host)) 14.23.30 # But I think the blind users are overreacting about the voice change. 14.23.35 Quit Febs_ (Read error: 110 (Connection timed out)) 14.23.51 # Voice has been *broken* for longer than this. 14.24.14 # And now we're providing voice files (though they need some fixing still) 14.24.45 # rasher: I'm still in favour of attempting a 3.0 release as soon as humanly possible. My vote is for "after MoB and Coprocessor support" 14.24.55 # Llorean: people are afraid of change. Once things settle down, everyone will be happier 14.25.00 # what is MoB support? 14.25.05 # Metadata on Buffer 14.25.06 # MetdataOnBuffer 14.25.14 # curse your faster fingers Llorean 14.25.18 # you even got spaces in 14.25.23 # rasher: of course it would, but we're not there 14.25.26 # MoB should lead to supporting embedded art? 14.25.32 # Not necessarily embedded 14.25.55 # That might depend on how the discussion on 'jpeg in core' goes. 14.26.06 # some time now we really need to start thinking about 3.0, though 14.26.17 # if only to try 14.26.23 # preglow: Well, there is one thing we can do now. 14.26.25 # preglow: I don't know. Simply releasing the current state (once voice has been sorted) as 2.6 would be preferable to the current situation, in my opinion 14.26.39 # * amiconn refines the unified voice file suggestion, and now suggests 2 voice files 14.26.40 # We can set up a "road to 3.0" 14.26.51 # A list of things that, when they're all done, we can enter 3.0 feature freeze. 14.26.54 # Llorean: Ovrereacting maybe a little, but it's very unpleasant when voice doesn't work reliably. I'd suggest we advise all blind users to stick to builds before the change (on the front page). 14.27.04 # Llorean: or clean up the old wiki page 14.27.05 # Llorean: would as always be helpful 14.27.07 # * pondlife visits the typo class 14.27.14 # amiconn: 2? 14.27.17 # The mechanism allows a voice file to support an arbitrary subset of targets, as long as the clip format is the same 14.27.25 # but i think 3.0 might be viable now that ipods are starting to shape up a bit 14.27.32 # * preglow has high hopes for amiconns work ;) 14.27.36 # preglow: I think with a list of things out there saying "We should get these done so we can freeze for 3.0", people might look in those directions a wee bit more 14.27.44 # Llorean: and i agree 14.27.53 # For archos we want the clips preswapped, for swcodec they should be in normal bit order 14.28.10 # OK, so MASCODEC and SWCODEC 14.28.18 # So one voice file for archos, another for swcodec 14.28.48 # Actually it's not a hwcodec vs. swcodec issue, but due to the SH1 SPI and the MAS hookup 14.28.56 # Ah, ok 14.29.08 # AV300, while being hwcodec, will also use non-swapped clips 14.29.24 # (if that port ever gets done) 14.30.02 # * preglow has doubts :P 14.30.14 # What's the Rockbox 3.0 wiki page? 14.30.30 # Of course we could bitswap the clips on load and just use a single file, depending on how much perceived delay that produces 14.30.33 # Llorean: ReleaseTodo? 14.30.47 # Ah, right 14.30.58 # So, should pre-freeze qualifiers go there to? 14.31.01 # On Ondio that wouldn't be a problem at all, but maybe on the disk based archoses 14.31.49 # Swapping 1MB takes ~1 second with my optimised bitswap 14.32.09 # what would the nicest current non-iriver target be for recording? 14.32.27 # iAudio? 14.32.27 # There is no current target that can record afaik 14.32.51 # I mean, the Sansa can record, and some iPods have a line in. 14.32.56 # Hmm, wrong. The G5.5. can record 14.33.08 # The Sansa's rather limited in quality though, iiuc. 14.33.09 # Llorean: Yeah, but sansa recording is a joke imo 14.33.21 # Maximum sample rate of 24kHz 14.33.45 # hrmph 14.33.48 # so i'm stuck with irivers 14.33.51 # Well, it's designed for voice really. 14.33.53 # i'll need to get another h1x0 14.34.00 # Memos 'n such 14.34.01 # this one is getting really, really scruffy looking 14.34.11 # preglow: Or start a new port. ;) 14.34.22 # The iAudios can record too, but for line you need the subpack, and gain range is way lower 14.34.26 # laters... 14.34.27 Quit DerPapst ("So Long And Thanks For All The Fish!") 14.34.48 # Llorean: for what? :/ 14.34.56 # On the other hand, they are able to record with up to 96kHz 14.35.02 # preglow: Something that can record? 14.35.05 # heh 14.35.06 # the H10 can record too, no? 14.35.07 # Get the iFP running! 14.35.19 # i don't think i can maintain interest if i have to work on a port alone 14.35.22 # I doubt that the iFP can record 14.35.22 # the ipod port was more than enough 14.35.30 # amiconn: It certainly can 14.35.33 # Line in and inbuilt mic. 14.35.40 # now, really 14.35.57 # I meant that the player is physically capable, I doubt it can in Rockbox. 14.36.03 # yeah 14.36.05 # I was suggesting Preglow finish it up for us. ;) 14.36.10 # preglow: there are some (3) iHP120 on ebay atm 14.36.36 # petur: i want an h140 this time around 14.36.47 # and i'm strapped for cash now anyway 14.38.19 # Llorean: perhaps it's time for a round of release-talk on the -dev list? It's really awful that there hasn't been a release for any swcodec target yet. 14.38.28 # yeah 14.38.32 # it's very high time now 14.38.34 # like it or not 14.39.06 # i certainly don't like it, but it IS a shame we don't have a release 14.39.22 # I'm more or less of the opinion that a rushed and buggy release is better than none, at this point. 14.39.33 # just getting a wiki page up with stuff we (and other people) think we have to do might help organize a release very much 14.39.47 # it's not like a release have to be bug-free 14.39.51 # but the bugs should be documented 14.39.55 # exactly 14.40.20 # * amiconn thinks that we're currently further away from a release than a year ago 14.40.35 # amiconn: and i agree, but that doesn't change the fact that we now need one more than we did a year ago 14.41.04 # * GodEater goes to read up on voxin 14.42.35 # amiconn: I'm not sure if we're further than we were pre-freeze though 14.42.48 # We entered that freeze with some unnecessarily large things on the table 14.42.48 Join Adikdid [0] (n=chatzill@CPE-124-186-184-48.qld.bigpond.net.au) 14.43.36 Quit Adikdid (Client Quit) 14.43.50 Join barrywardell [0] (n=barry@wardell.ucd.ie) 14.45.41 Quit My_Sic ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 14.46.10 # i'm not convinced we'll fare much better this freeze either, but we pretty much have to try 14.46.20 # not even _trying_ for a release around once a year or so is a shame 14.46.36 # Well this time the freeze should really be bugs-only 14.46.41 # Not "get these features done" 14.46.42 # indeed 14.47.05 # And at the end, release whatever you've got. 14.47.07 # but why does my vinyl amp have so little treble :/ 14.47.28 # rasher: i might agree with that 14.47.41 # as long as nothing truly embarassing/disastrous is left 14.47.52 # Yeah, last time we had some considerable playback issues. 14.47.53 # and at least now we have excellent installer tools 14.48.30 # It's pretty much the only way a release will happen. And yes, disastrous will need to get fixed. But "high battery-consumption" or "sometimes freezes during playback" isn't disastrous. 14.48.39 # rasher: agreed 14.49.16 # I don't think we need to release for iPods. 14.49.19 # As long as it works most of the time, for most people and isn't actively dangerous for the rest, I'd say it's ready for release (not an optimal situation, of course). 14.49.29 # Llorean: i don't think we _need_ to either, but i think we should 14.49.33 # Llorean: I really don't see why not. 14.49.51 # rasher: Skippy playback when you use the equalizer, relatively terrible battery life? 14.49.57 # I'd like at least "features" to all work. 14.50.08 Quit XavierGr (Nick collision from services.) 14.50.09 # "skippy playback on eq" is hard to solve 14.50.10 Join XavierGr_ [0] (n=xavier@ppp134-59.adsl.forthnet.gr) 14.50.11 # Maybe if coprocessor playback is done in time. 14.50.13 # would put a release months back 14.50.21 # but cop support is also going to put us months back 14.50.23 # Llorean: Personally I don't think those things are important enough if documented. 14.50.27 # it'll introduce tons of bugs, i can guarantee you that 14.50.32 # preglow: My understanding is actually that Cop support is fairly nearby right now 14.50.40 # i can still guarantee you tons of bugs 14.50.44 # i'll eat something nasty if that doesn't happen 14.50.51 # and even take pictures 14.50.58 # rasher: But why "release" on the iPods that have poor battery life? 14.51.03 Join Febs_ [0] (n=chatzill@38.98.196.75) 14.51.04 Nick Febs_ is now known as Febs (n=chatzill@38.98.196.75) 14.51.09 # hey, give amiconn some credit :P 14.51.12 # that'll be solved in weeks now :P 14.51.14 # We have the H100, H300, X5, M5, and Gigabeat. 14.51.36 # I don't see why we "should" release on those targets. 14.51.42 # Llorean: Because the ipods need a release as badly as the rest, if not more (considering it's the largest userbase by far) 14.51.56 # I don't understand what you mean by "need" a release. 14.51.56 # but we should be a bit careful, though 14.52.01 # a bad ipod release won't help us much 14.52.07 # Imo we could also release for 3rd gen, and perhaps 1st/2nd gen - if we want to release 14.52.15 # What you could do is issue a "Stable development build" for the iPod 14.52.18 # What is a "release" going to give the end user 14.52.19 # amiconn: how is codec performance on those guys now? 14.52.27 # Paralleling the release, but making it absolutely clear it's not release-ready yet 14.52.33 # But that's also a bit tricky - even treble/bass can make medium bitrate oggs skip 14.53.02 # We can increase CPUFREQ_MAX to 90MHz - I think that's safe now that the extra power drain is solved 14.53.11 # urgh 14.53.13 # we need cop support :/ 14.53.19 # yes 14.53.30 # GodEater: nothing tangible, and we know that. But users like releases. It gives them peace. 14.53.44 # The difference between playing mp3 at line level and playing mp3 with some treble/bass is clearly noticeable 14.53.47 # amiconn: Is it not the 75 -> 80 MHz increase that's upsetting Nano's (timing or heat, or whatever)? 14.54.03 # The latter increases buffering time _a lot_ 14.54.07 # might be, the nano is pretty tightly packed 14.54.10 # Besides, many users are pretty much expecting release-quality from the dev-builds right now anyway. Which is not acceptable either. 14.54.12 # * GodEater wonders how many end users will see the difference between a release and current build 14.54.18 # (but it doesn't skip with preset standard mp3) 14.54.20 # rasher: and that is a good point, i think 14.54.28 # a release will make it clear that dev builds are dev builds 14.54.31 # rasher: why not realease now then? 14.54.40 # pondlife: I doubt that. Then it wouldn't be a problem at boot 14.54.41 # Has anyone given a positive reason for a "release"? 14.54.49 Join JajaComp [0] (i=d521d7aa@gateway/web/cgi-irc/labb.contactor.se/x-b9d69323807707ec) 14.54.57 # As opoosed to "we should have one" 14.55.03 # markun: personally I don't think it's such a stupid idea (except for the current voice issues which are fairly important) 14.55.06 # Hello!!! 14.55.18 # Maybe before COP or MOB are integrated. 14.55.29 # pondlife: I guess its either ata timing, or something completely different on nano that I overlooked so far 14.55.30 # Those will both cause major bugginess I expect. 14.55.35 # JajaComp: managed to install the crosscompiler? 14.55.53 # rasher: Why not release for the good targets (the ones I listed) and a "Stable development snapshot" for the iPods, so it's clear it's not at the same level, but offers users a stationary version? 14.55.53 # pondlife: Sounds likely. Is anything big on the table besides those two? 14.55.57 # * petur wonders why the hurry... 14.56.03 # I don't have a nano ROM dump 14.56.07 # i compile RockBox, but when i reboot ipod see error message "bad chacksum"... whot is? 14.56.16 # amiconn: Want one? 14.56.36 # petur: because we've been developing swcodec for years now with no release? 14.56.38 # Well, now that you can make one... yes 14.56.39 # Llorean: Maybe we need to make clear some way that Ipods are second-class citizens right now. Naming the "release" something else might do it, I guess. 14.56.49 # preglow: Another year won't hurt, then ;p 14.56.52 # haha 14.56.59 # rasher: It's not only ipods, also H10 14.57.08 # and sansa 14.57.09 Join TinoM [0] (n=Tino@i5387C514.versanet.de) 14.57.24 # amiconn: of course, yes. 14.57.28 # Sansa doesn't suffer that much regarding battery runtime 14.57.37 # Seriously, we are making decent progress at the moment, why stop for a freeze? Either immediately before or a while after MOB would be my choice. 14.57.38 # preglow: indeed, so what's the bit extra time going to make? And anyway, who is waiting for a release? I'd rather have some of current bugs fixed first... 14.57.39 # rasher: I think it's pretty important that you make it clear that they're second class. People don't read release notes, and might thing that the shortened battery life is "regular" 14.57.51 # rasher: I frequently see people explain it as 'Of course you get worse battery life... Rockbox does more' 14.58.12 # what is error "BAD CHECHSUM"???? 14.58.21 # Llorean: well it cleans my fridge for me :) 14.58.22 # It would be better if the standard was "Rockbox extends your battery life". 14.58.32 # JajaComp: something wrong with your rockbox.ipod file 14.58.37 # amiconn: http://llorean.dyndns.org/rockbox/nano.bin 14.58.46 # petur: me too, but with no release talk, there'll always be tons of new stuff thrown in that will forever make bugs 14.58.46 # JajaComp: possibly you built for the wrong target ? 14.58.47 # pondlife: It does that... just not on PP502x yet 14.58.48 # Llorean: Fair enough, a differently-named release for the ipods+h10 is a good solution I think. 14.58.56 # amiconn: My point exactly. 14.59.02 # Llorean: 403 14.59.13 # On PP5002 it does :P 14.59.20 # rasher: Or no release. 14.59.21 # preglow: feature freeze didn't help last time... 14.59.22 # pondlife: Which is why I suggest we only mark the Coldfires, Archoses, and Gigabeat as "Release", and the PortalPlayer as something second class, but "available" for use 14.59.27 # amiconn: Silly me 14.59.45 # I always forget that if I copy the file from this computer, I need to redo permissions 14.59.59 # "Bata" for second class (most people would understand what that means) 15.00.03 # Beta 15.00.03 # amiconn: Try again? 15.00.13 Join Nico_P [0] (n=nicolas@rockbox/developer/NicoP) 15.00.13 # dionoea: I like "Bata" it's more original ;) 15.00.18 # I've still not heard a decent reason for any kind of release. "We're about to break music playback" is probably a good one, but would that need a branch too? 15.00.19 # :p 15.00.43 # Llorean: thx 15.00.50 # pondlife: I think a "release" will help people understand the current build should be considered "in-development" 15.00.59 # pondlife: I really don't think the current situation is good. It makes users expect things of the svn builds that they shouldn't. An analogy would be firefox. People know not to expect release-quality from nightly builds, and most stick with the releases 15.01.01 # Specifically, that if they're updating constantly, they should expect things to change and possible break 15.01.10 # pondlife: maybe test a bit more before committing, then? 15.01.16 # lol 15.01.18 Join XavierGr [0] (n=xavier@194.219.214.119) 15.01.22 Join My_Sic [0] (n=MySic@mur31-1-82-237-204-133.fbx.proxad.net) 15.01.36 # amiconn: I make no promises that it's any good. I can't assure my Nano's sanity. 15.01.36 # petur: didn't help, no, but it might now, who knows 15.01.43 # if we are to keep in pretending we do releases, we have to try doing some 15.02.07 # Many users would continue to update daily (or regularly) anyway, there's always new goodies. 15.02.11 # petur: I don't think the mission now should be a bug-free release (as it was last time), but a release that doesn't kill anyone. 15.02.19 # preglow: Instead of "Releases" we could just have "Stability-enhanced Rockbox" with a 1-month feature freeze once a year for bug-focus. :-P 15.02.30 # "Rockbox - no longer fatal!" 15.02.37 # hahaha 15.02.43 # heheh 15.02.57 # Llorean: At least it looks like a typical ipod rom dump 15.02.58 # * Llorean wants to know who to talk to about voice files having the wrong clips in them. 15.03.02 # pondlife: do you know of a case where rockbox has killed someone then ? :) 15.03.02 # pondlife: but then they'd a) have a release to fall back to once they hit a bug. and b) know not to expect much 15.03.04 # Rockbox - no broken ears in the default install for 1 year 15.03.14 # amiconn: Alright, good to hear. 15.03.19 # GodEater: Ask rasher ^^ 15.03.49 # "Rockbox - bricking iPods since 1995" 15.04.05 # Llorean: I'm considering blaming genlang or perhaps voicefont 15.04.36 # * Nico_P is reading the logs but just wants to mention that a stable branch is far better than a feature freeze 15.04.36 # rasher: All I know is that if I build a Gigabeat voice, it seems fine, and if I build a Nano voice, it's got the wrong clips in several of the menus 15.04.37 # JajaComp: the compilation went fine and then you did "make zip" ? 15.04.43 # Maybe we just need to be able to mark particular daily builds as "good ones" ? 15.04.58 # no 15.05.00 # pondlife: just thinking the same 15.05.10 # JajaComp: no to what? 15.05.10 # Not sure how we'd decide. Most are pretty good. 15.05.18 # pondlife, petur: why not a stable branch ? 15.05.33 # More overhead. 15.05.48 # When time is limited, I'd rather not be administrating multiple branches. 15.05.49 # main brabnch should be stable 15.05.52 Join leftright [0] (i=d9e1f7cd@gateway/web/cgi-irc/labb.contactor.se/x-8d11f03b2b4f1e3a) 15.05.59 # * petur joins typo class too 15.06.01 # A lot more, and it'd quite likely be neglected as devs work on the dev branch 15.06.13 # JajaComp: maybe you should read the wiki again: http://www.rockbox.org/twiki/bin/view/Main/HowToCompile 15.06.21 # I think a stable branch would just stagnate. 15.06.32 # Same 15.06.33 # rasher: I don't see how it could be wrose than the feature freeze 15.06.33 # We do need more bug fixing, but the main problem is that our current audio engine is not well structured and over delicate. 15.06.59 # Nico_P: because it'll be lower priority as a branch, because you can keep working on the dev branch 15.07.08 # Currently only a few people can really fix the bugs (and I don't count myself in that group). 15.07.24 # rasher: at least it's stable, so users who don't like change can rely on that 15.07.27 # honestly, here at work the checked in code should be well tested, because a snapshot can be taken at any time for testing+release. So why can't we keep up quality commits at Rockbox? 15.07.28 # What kind of files do you play to make it hang/crash? I play oggs all day long on my iPod video and i've never had any of those. 15.07.30 # "SWCODEC - kills developers, dead!" 15.07.33 # * GodEater suspects playback.c is pondlife's personal bugbear 15.07.38 # Llorean: I still think that the nano problems might have to do with ata timing, but the fact that just going back to 75MHz with the new code doesn't seem to help doesn't fit in well 15.07.50 # It is. Looks at the bugs in it. Race conditions all over the place! 15.07.56 # fix it 15.07.59 # However, the facf that the nano ata flash doesn't like going to sleep would support this theory 15.08.02 # No, it'll kill me. 15.08.06 # wuss 15.08.11 # :p 15.08.12 # Like it did to poor lostlogic. 15.08.18 # I value my mind. 15.08.21 # re-write it 15.08.25 # pondlife: btw, seen my latest work ? 15.08.29 # amiconn: What's interesting is that sometimes the music plays, but corrupted, and sometimes there's a crash, suggesting to me that the loaded data is being corrupted. Which would line with the ata issue, right? 15.08.38 # (after sleep it might come up in a slow pio mode, not being able to properly communicate with the ata controller) 15.08.54 # Nico_P: Not yet, no. As long as it's got structure and comments, I'm happy :) 15.08.57 # because there is no current stable release everyone gets the latest because the assumption is that its better, then when theres a majpr issue you guys just say, "use a previous that works", as long as you dont have a stable release folks will always think that the recent current is the best and most stable 15.09.13 # leftright: Generally the most recent is best. 15.09.15 # We had a similar effect on archos with some old HDD models iirc 15.09.15 # leftright: The vast, vast majority of the time it is the most stable. 15.09.21 # LinusN should know 15.09.24 # pondlife: http://repo.or.cz/w/Rockbox-MoB.git?a=shortlog;h=no_rb_in_rb ... heopfully you'll be happy 15.09.24 # The recent voice stuff is an exception. 15.09.56 # leftright: The most recent is almost always the best choice 15.09.58 # The recent voice stuff isn't really a case of stability. It's a case of "it took a few days to finish working on it" 15.10.03 # leftright: would you prefer to use an older version of rockbox? 15.10.04 # Exactly 15.10.18 # if it works well why not 15.10.20 # Even 2.5 for archos has some major bugs which are fixed in svn 15.10.23 # Sometimes things just simply don't become apparent until you go live. 15.10.39 # Maybe we need a system where users can rate a particular daily build out of 10..? 15.10.55 # leftright: then you could also just not update rockbox if it runs well 15.10.59 # then you need a different policy/method for dealing with major changes 15.11.10 # ah ok 15.11.26 # just release if there are major changes and it's stable 15.11.28 # makes sense 15.11.34 # leftright: Anyone updating their daily build regularly instead of picking one and sticking with it should consider themselves a tester. 15.11.44 Quit XavierGr_ (Read error: 110 (Connection timed out)) 15.11.59 Part pixelma 15.12.02 # Llorean: But they don't, unless they know that there are "releases" or something like it. 15.12.24 # rasher: Partially because they don't read the manual, and partially yes because we don't have a clear release version 15.13.33 # markun: exactly, when instituting a major change only release it when its stable 15.13.41 # You shouldn't expect users to read the manual. It's a given that the mast maority of users won't read more than what's needed to get running. 15.13.44 # petur: even a 60 dB gain sounds perfectly ok :P 15.14.21 # leftright: We haven't released it. 15.14.29 Quit XavierGr (Nick collision from services.) 15.14.31 Join XavierGr_ [0] (n=xavier@ppp207-143.adsl.forthnet.gr) 15.15.00 # rasher: If we have a release version, it'll just mean we get a new type of confused-user question. 15.15.06 # release is perhaps incorrect with your current method, perhaps not make it available to the public is better 15.15.13 # rasher: Such as "I heard Rockbox could play NES games, I downloaded the latest release but it doesn't" or whatnot 15.15.56 # leftright: So, password-protect the build page any time there's a major change so that only people we consider "testers" can get to it, thus decreasing the likelihood of people finding bugs? 15.15.56 # Llorean: I think it's more manageble "It's under development and will be availble in the next release, or right now, if you install a *development build*" 15.16.04 # * amiconn leaves for a while 15.16.21 # making buggy builds availbe to the public is not a good idea 15.16.42 # * dionoea agrees with rasher. That's what most other software projects do anyway. 15.16.50 # or rather super bugy builds 15.16.56 # leftright: Making buggy builds available is not the problem. The problem is that it's not apparent that they may be buggy 15.17.09 # leftright: How the hell are people supposed to test development versions if they're not made available? 15.17.20 # The problem isn't that the build's there. The problem is that people don't clearly know it's in-development 15.17.21 # leftright: At least to the casual user who doesn't understand how development works 15.17.40 # not all folks want to debug your software, they just want something that works 15.17.53 # but we DO want them to debug it :) 15.17.54 # Then they should use the retail firmware, or wait for release versions. 15.18.05 # Or find a version that works and stick with it. 15.18.10 # If they're unwilling to accept the terms upon which the software is currently offered, they don't have to accept them. 15.18.19 # Febs: which could be called a stable release 15.18.28 # Ideally, yes. 15.18.44 # I think at least a semi-stable release should be tried for soon (before the end of the year) 15.18.47 Quit aliask ("ChatZilla 0.9.78.1 [Firefox 2.0.0.6/2007073113]") 15.18.55 # maybe we should rename the "current build" to "development build"? 15.19.02 # or tag the currents as unstable somehow 15.19.11 # bluebrother: that's a very good idea 15.19.12 # and "archived build" to "archived development build"? 15.19.21 # leftright: but it's usually not that unstable 15.19.22 # But when it's the only thing available, people won't have anything else to pick from 15.19.34 # markun: but right now, a build may work perfectly for someone and yet still have bugs affecting features that person doesn't use. 15.19.50 # display a splash message when no user cfg is present: this is a development version, use at your own risk 15.19.52 # leftright: "The current build is built at each source code change to the Rockbox SVN repository, and represent the current state of Rockbox development. This means that the build could contain bugs, but is most of the time safe to use." 15.19.53 # but every now and then the wheels fall off, so you need to advise the foks about that somehow 15.20.15 # The problem is that the current build is *all* we offer to most users 15.20.16 # or something similar ... the only problem is that this will increase binary size for no functional benefit. 15.20.39 # flag the table somehow 15.20.54 # So they see it as the regular build in spite of the warnings 15.21.10 # add a big red blinking "warning, you are looking at unreleased stuff" at the page? ;-) 15.21.20 # rasher: Well, if more users contributed proper bug reports and tested them, we might advance toward a stable version more quickly 15.21.28 # I mean, it's a two-way street, 'n all. 15.21.33 # I think that it is a reasonable suggestion to send announcements to the user list when major changes are implemented. 15.21.48 # And also post in the "Announcements" forum. 15.21.58 # bluebrother: but having to wait for years for a stable release while many 'unstable' builds have worked fine for many users is also a bit unfair 15.22.00 # Febs: true. This should happen whenever something major happens 15.22.22 # we could also add information about which player has a release on the front page. 15.22.48 # I don't see why major changes need to be replicated in several places. 15.22.49 # as the current list somewhat implies that all players are "done", and "additional models are in development" 15.23.02 # Invariably someone will forget one, or multiple, of the places. 15.23.22 Join XavierGr [0] (n=xavier@ppp199-200.adsl.forthnet.gr) 15.23.27 # Llorean: then have a few people responsible for putting out such warnings 15.23.29 # markun: I never said users should wait for years for a stable release -- they just should be aware about the not-yet-released state 15.23.38 # rasher: Why can't people read the MajorChanges page? 15.23.39 # some targets are more mature than others, right now the assumption by joe soap is that build table is green so all is good 15.24.17 # Soap knows the score! 15.24.19 Join pondlife1 [0] (n=Miranda@cpc1-rdng11-0-0-cust362.winn.cable.ntl.com) 15.24.42 # Llorean: that page is very brief, and don't really explain in detail what happened. Besides, it doesn't give a warning in advance. 15.24.43 # hmm, is there a way to export the MajorChanges page to simply html / txt? We could display that information in rbutil 15.25.36 # have anyone seen the german rockbox article someone posted about? 15.25.59 # bluebrother: Certainly a page on rockbox.org could parse majorchanges and output it in a "clean" way 15.25.59 # Llorean, people will only read docs if they abosolutely have to, its a very frustrating humsn trait, folks want to click and everything must just work, they dont understand development work 15.26.17 # leftright: Then tell them to stop updating. 15.26.18 # bluebrother: the wiki markup is there for the server to parse afterall 15.26.48 # preglow: which one? 15.26.52 # rasher: Well there's also always the changelog. I just don't see why people should be expected to write explanations of everything they do. 15.26.54 # I would, but to what build do i point them to 15.27.09 # rasher: I think it's the user's responsibility to know what they're downloading, otherwise people will get even more upset the one time someone forgets to do so. 15.27.14 # Llorean: or simply advise them when there is a major change so that they don't update then if they don't want to . "We have made a major change today. You may experience instability with current builds, or feature X may not work as it has in the past." Then people can decide for themselves whether to update. 15.27.24 # leftright: Tell them to find one that works for themselves, and stick with it? 15.27.46 # But at least they're put on notice that there has been a major change. 15.27.48 # markun: pc magazin 15.27.54 Quit pondlife (Nick collision from services.) 15.27.56 # Febs: Again the problem with people then growing to expect that if they haven't been told "expect instability" then there will be none. 15.28.00 # Llorean: you're expecting too much of the users. In the end, we want to make it easier for them. If not because we're nice, then because it makes our lives easier as well. 15.28.15 # Febs: I think it's better to nurture a knowledge that *all* development builds can be expected to be unstable. 15.28.27 Quit My_Sic (Connection timed out) 15.28.32 Nick pondlife1 is now known as pondlife (n=Miranda@cpc1-rdng11-0-0-cust362.winn.cable.ntl.com) 15.28.56 # rasher: Then why not get a release put up, and tell people who want stability to stick with it until the next release, rather than creating a false sense of security by randomly warning about instability sometimes, and completely missing it other times? 15.29.01 # Llorean: of course. But that doesn't mean that we can't advise of major changes when we *know* that there will be a higher likelihood of instability, or at the very least a change from what they've become accustomed to. 15.29.16 # Febs: Changes from what they become accustomed to, sure. 15.29.32 # you will be saving yourselves major headaches by having a stable build somewhere that you can point to 15.29.34 # And "there is a near certainty X will be broken for at least the next few builds" makes sense to. 15.29.47 # Llorean: I'm saying we should do both. Once the releases are there, missing a "new feature" announcement isn't as big a problem, because people will know they are dev builds. 15.29.49 # leftright: Feel free to start fixing bugs for a release then. I look forward to seeing them start vanishing from the tracker. 15.30.02 # not a release, a stable build 15.30.04 # * GodEater thinks no-one will use a stable build, and everyone will still keep using the current one 15.30.13 # leftright: Okay, either way, bugs need to be fixed 15.30.33 # Febs: I think people using the development version can subscribe to the developer list. 15.30.35 # GodEater: but it'd make things a lot simpler. "Use the stable build if you just want something that works" 15.30.46 # Febs: I see no problem with sending out a message on the dev-list warning of upcoming large patches, we do that anyway most times. 15.31.04 # GodEater: depends on how ofter we release I think 15.31.08 # often 15.31.16 # There's no reason such an announcement couldn't be sent to the user list. 15.31.43 # or have an announcement list just for err, announcements :) 15.32.13 # The user ML is a bit underused, aside from the blind community. 15.32.14 # Febs: I think it is better if it's just for the dev list, though, to keep it clear that what you're doing is participating in development 15.32.23 # Febs: It's part of the whole "testers" vs "users" concept. 15.32.23 # I disagree. 15.32.36 # All users are testers, no? 15.32.39 # By that logic, there should be no user list right now except for v2.5. 15.32.41 # Llorean: depends how you're wording the mail, in my opinion 15.32.41 Quit JajaComp ("CGI:IRC (EOF)") 15.32.54 # * GodEater agrees with Febs 15.32.56 # some people dont want to be testers, they want smething that works 15.33.01 # pondlife: as things stand now, yes. But some users don't know it, or dont want to be testers. 15.33.04 # Well, OF normally works. 15.33.06 # :) 15.33.10 # Febs: I'm basing my statements on the assumption that we're going to try to have a release. 15.33.17 # Or regular releases even. 15.33.27 # rasher: OK we need more warnings before they download maybe? 15.33.39 # We don't need to be suggesting to people that these are "Updates", but rather "Patches being rolled out for testing" 15.33.47 # And I think that's very definitely a "Development" topic. 15.33.52 # pondlife: Won't work as long as they have to download that build anyway. 15.34.17 # leftright: People who don't want to be testers need to wait to download Rockbox until a release happens. 15.34.34 # yes but when 15.34.38 # I don't see the point in having releases unless we also branch and fix them - and I'm not in favour of doing that at all. 15.34.44 # leftright: How long will it take you to make Rockbox stable? 15.34.56 # pondlife: with freezes prior to release, that's effectively the same 15.35.06 # leftright: Saying "Rockbox needs to have a release" is all well and good, but you and others need to work on it. 15.35.13 # rasher: no it's not - what about fixes post release? 15.35.14 # rasher: No, because the more serious bugs never get fixed. 15.35.27 # * GodEater high fives pondlife 15.35.31 # pondlife: That's why you need a pre-freeze checklist. 15.35.47 # pondlife: Things that need to be done before a freeze can be entered, so it's hanging over everyone's head. 15.35.53 Quit daurnimator (Read error: 104 (Connection reset by peer)) 15.35.55 # that still doesn't help 15.35.56 # GodEater: the assumption is that any bugs left in the release is not serious enough that people can't wait for the next release 15.36.07 Join daurnimator [0] (n=fake@unaffiliated/daurnimator) 15.36.10 # Llorean: I'm not saying a release, to help the user and make your life easier you should always have a "Stable Build" that you can refer people to 15.36.13 # that's an awfully big assumption 15.36.25 # leftright: that's the same thing with a different name 15.36.33 # leftright: Alright, so either tell me which build is that stable build, or get to work eliminating bugs until there's a stable enough one 15.36.36 # s/bugs/known bugs/ ? 15.36.36 # Llorean: I would love a stable release, but do we have people who are interested in that and have the time needed to understand the problems and fix them, within a reasonable period? 15.36.42 # leftright: Producing a stable build is the same problem as producing a release. 15.36.48 Join DataGhost [0] (i=dataghos@ip3e832ea5.speed.planet.nl) 15.36.50 # and then you'd have a stable branch where you only fix bugs (and not add features) 15.36.52 # GodEater: I don't think so. Any bugs so major that it absolutely needs a fix can't hide for weeks without being hit. 15.37.10 # with software there is only more stable and less stable 15.37.12 # so what about the bugs still in 2.5 ? 15.37.20 # pondlife: Depends both on the level of stability you define as a release, and on whether you decide you want "A release by X date" or "A feature freeze of X days *after* these key bugs and features are resolved" 15.37.26 # GodEater: That's a different situation, since it's so old now. 15.37.39 # anyone know what the impedance of the h120 input is? :> 15.37.41 # rasher: but we'd still end up in the same situation with any release we made now 15.37.43 # Llorean: It would have to be the latter IMHO 15.37.48 Quit XavierGr_ (Connection timed out) 15.37.57 # pondlife: That's what I've been advocating since about the day the 3.0 feature freeze was cancelled. 15.38.05 # IMO to do a release properly you MUST branch 15.38.07 Quit XavierGr (Nick collision from services.) 15.38.08 # Stability level - doesn't need the pin to reset it once a week. 15.38.09 Join XavierGr_ [0] (n=xavier@ppp50-185.adsl.forthnet.gr) 15.38.21 # Once a month is ok :) 15.38.22 # leftright: Yes, so someone needs to work on making Rockbox more stable. 15.38.48 # uhuh, but you wont get that if you add new feautres all the time 15.39.07 # GodEater: the 2.5 situation is entirely different, and can't be compared to a new release, because the new release should come with a promise of a next release as well. 15.39.13 # hmm. How about a bugfixing month? 15.39.17 # just like 2.5 did.... 15.39.35 # bluebrother: Major new features need to be either finished, or put on hold before first commit, before that can happen 15.39.48 # I think we need to work on spreading the knowledge about how lower-level stuff works. Rockbox cross-training.... 15.40.11 # sure ... but such a period could be used to stabilize and fix bugs in the current state 15.40.18 # leftright: Just because features are being added doesn't mean you can't fix bugs. 15.40.24 # you need to have some kind of feature freeze of course 15.40.29 # leftright: But yes, a feature freeze will be necessary at some point. 15.40.31 # branching at each release doesn't lose us anything, and it saves us headaches if we don't / can't stick to some intended release schedule 15.41.06 # branching after the release has finished or before it? 15.41.09 # GodEater: if you mean branching and then working on in the dev branch, I think that's a very bad idea. If you mean "feature freeze, release, then branch" 15.41.16 # bluebrother: at the point of release 15.41.21 # GodEater: then I'm all for it, to give the possibility of backporting fixes. 15.41.23 # you usually branch before the release hits final 15.41.28 # GodEater: then I think we agree anyway 15.41.32 # else people can't work on new features anymore 15.41.38 Join miepchen^schlaf [0] (n=hihi@p54BF6D99.dip.t-dialin.net) 15.41.41 # and that just slows down the dev process 15.41.42 # rasher: your second example, not the first 15.41.46 # the first would be silly 15.41.53 # you can't force people to only do bugfixing 15.41.58 # so you will have a branch wich will only get used for fixes after the release has made? Maybe. 15.42.03 # GodEater: it's not unheard of to let development continue during a freeze 15.42.04 # correct 15.42.12 # GodEater: but I don't think it'd work well for Rockbox 15.42.16 # rasher: then have multiple branches 15.42.18 # Freeze, then release/branch. 15.42.28 # dionoea: But you can force people not to commit any new features in the hopes that they'll do bugfixing. 15.42.30 # one at feature freeze start, and one at release, and keep a dev branch 15.42.32 # pondlife: sounds reasonable. Release and branch happens at the same time 15.42.41 # GodEater: No, only one current and one stable branch. 15.42.47 # features and improvements will always happen with software, but you need to develop a system where, a stable release will only be released to the public after a new feature which has been incorporated is stable 15.42.47 # pondlife: why ? 15.43.03 # GodEater: I don't think you should keep a dev branch open during the freeze. It takes a lot away from the point of the freeze 15.43.09 # leftright: Yes, that's called "release versions" or "stable versions" and we've covered that. 15.43.12 # Llorean: and then you end up freezing most work on trunk for months at a time. (at least that's what happened for VLC before we decided to have a stable branch) 15.43.18 # a typical pattern is to have a stable branch from which releases come from 15.43.22 # Will anyone fix bugs at all? The more branches, the more dilution of our Rockbox time. 15.43.24 # I don't see why we couldn't do that 15.43.47 # dionoea: If the dev branch is kept open during the freeze, a large majority of people will just continue working on it. 15.43.50 # If you branch at the point of the release, you lose nothing, but gain the possibility to backport fixes (easily) 15.43.51 # rasher: well that's the only way I can see to be tidy about allowing dev to continue during a freeze 15.44.02 # * pondlife assumes that the stable branch will only be worked on while there's no fun elsewhere. 15.44.11 # dionoea: Even when we didn't have a dev-branch, and froze for bugfixes last time, we never reached 'stable' because everyone kept working on their own thing, and asking us to end the freeze so they could commit 15.44.25 # GodEater: Dev does continue, fixing bugs! 15.44.26 # Pondlife: will anyone fix bugs at all...... does anyone have pride in their work, 15.44.26 # which is exactly why you need a stable branch 15.44.33 # Llorean: that was because of the lack of branches 15.44.41 # so fixes can get commited on that branch but not the new features 15.44.43 # Nico_P: How can we have a stable branch until we *get* stable? 15.44.52 # we need another tracker cleaning week, and focus on the bugreports... 15.44.57 # Llorean: with branches people have a choice: fix bugs or work on new features... hopefully they'll do a bit of both 15.45.05 # GodEater: I don't want to allow dev to continue during a freeze. I'm expecting devs to fix bugs and work on features locally, and as a secondary thing. Of course this doesn't work if the freeze is several months. It needs to be no more than a month I think. 15.45.14 # Llorean: we branch and then stabilize 15.45.22 # by not adding too much new features 15.45.25 # Llorean: stable branch basically means "don't commit new features(aka bugs) here" 15.45.32 # No, stabilize first, so both branches benefit. 15.45.35 # rasher: so let the devs manage their own local branches 15.45.50 # GodEater: exactly. No official dev branch during the freeze. 15.45.51 # Fix/freeze for a month, then branch/release. 15.45.57 # pondlife: you usually fix bugs in trunk and backport to the stable branch 15.46.01 # * GodEater has got too used to the git mindset already 15.46.07 # (unless the stable branch and trunk are too far appart) 15.46.08 # dionoea: If that happens, very little work will ever focus on the stable branch. 15.46.18 # Llorean: I'm not sure about that 15.46.20 # How about: please test better before committing? 15.46.22 # very little is better than none IMO 15.46.22 # dionoea: I suspect the "too far apart" will happen, and then most people "won't have the time" 15.46.29 # GodEater: I'm getting used to it myself :) But don't actually use git yet 15.46.32 # during all feature freezes, its a tiny handfull of dev's that rool their sleeves up and fix others bugs 15.46.44 # Llorean: but NOT doing it means you can't make any fixes at all to the "stable" code 15.46.47 Join BigMac [0] (n=BigMac@c-71-234-95-131.hsd1.ct.comcast.net) 15.46.49 # petur: it's a nice thought, but in practice you can't beat the testing of all users. 15.46.54 # petur: The main problems are more fundamental, and in old code... 15.47.01 # Llorean: and the few times i've experienced that method it worked really well 15.47.10 # markun: I used it properly all the way through developing my shortcuts plugin 15.47.12 # it was great! 15.47.15 # better than just freezing the main dev tree 15.47.19 # Llorean: dionoea's right, it works for many projetcs 15.47.21 # GodEater: I'd much rather a stability-only (no features at all) push for a period (1month? 2months?) *then* a branch, whether we release or not 15.47.39 # A kick-start as it were. 15.47.44 # Llorean: that would be nice - but it's not gonna happen ;) 15.47.46 # * Nico_P has been reading Karl Fogel's "Producing OSS" :) 15.48.04 # Nico_P: The only thing that really ruined our feature freeze last time was that it wasn't a feature freeze. 15.48.15 # It involved the addition of "Database" and the attempted playback engine rewrite. 15.48.15 # there seems to be a fundamental problem where programmers push products "over the wall" which aren't ready and expect others to do the dirty works of debugging xyz 15.48.19 # Nico_P: don't give away the ending yet, it's too much fun to figure it out on our own 15.48.28 # Without either of those, there's a decent chance we'd have a 3.0 out for a year now 15.48.50 # leftright: 1) This is open source. 2) No "product" has been "pushed" 15.48.52 # leftright: until you become a dev, you don't get to complain 15.48.56 # leftright: I don't think there's too much of that here. 15.49.07 # Llorean: the playback rewrite was necessary for the release 15.49.13 # Nico_P: No, it really wasn't. 15.49.19 # It was wanted for the release, which is different. 15.49.29 # Which release? Last year's non-release? 15.49.31 # Yeah 15.49.43 # Yep, playback suffered through that a bit. 15.49.46 # only 1 year ago? Looks like much longer 15.49.48 # There were problems with the old playback engine, but they were mostly known, and could be released with known bugs. 15.50.02 # s/with/as/ 15.50.05 # markun: Actually it's nearly two, I think 15.50.17 # Time flies when you're debugging playback.c... 15.50.20 # rasher: Or just those bugs could've been mitigated or worked around for the release 15.50.54 # Even if it was a dirty hack just to make it seem to work right, from a user perspective it would've worked. 15.51.00 # http://www.rockbox.org/twiki/bin/view/Main/ReleaseTodo... it was planned for 1st May 2006 15.51.55 # anyway I think we desperately need branches 15.52.24 # at least a stable one from which users can expect minimum reliability 15.52.29 # Currently there are 39 music playback bugs... some of which are not really playback bugs, but most of which are non-trivial to fix properly. 15.52.56 # Nico_P: As I said, I've nothing against a stable branch, but I think a hard freeze should happen first in an effort to get as much fixed for that branch as possible. 15.53.07 # There's no one saying a release has to have 0 bugs, or even close. 15.53.17 # Even known bugs. 15.53.18 # that be insanely unrealistic 15.53.28 # Nico_P: maximum reliability from stable branhc you mean.... 15.53.46 # JdGordon: I meant "a minimum level of reliability" 15.53.55 # JdGordon: I think he means "there's a certain minimum level that reliability never dips under" 15.54.07 # * JdGordon tired and confused 15.54.12 # No, but known issues such as "Starting playback directly after a recording ends in a data abort." are a bit off. 15.54.26 # pondlife: fix it!!! 15.54.33 # I don't have an iPod... 15.54.41 # we also need to use flyspray's release management features better 15.54.50 # jhMiksS knows the cause though... 15.54.54 # pondlife: but if it's not easily fixed, I don't think it should hold up a release 15.55.08 # That was just one (maybe not great) example... 15.55.21 # rasher: agreeed, but a workaround should be implemented 15.55.46 Part leftright 15.55.49 # workarounds are bad 15.55.54 # "Bug fixing fortnight" should happen, certainly. 15.55.56 # JdGordon: Not for "release versions" 15.55.56 # ...better than nothing 15.56.08 # If it's a release version, the key is *working* not elegance in code. 15.56.15 # You can revert all the nasty hacks right out immediately after if you must. 15.56.19 # not really.. it means that the bug appears fixed and is ussually forgotten about 15.56.28 # JdGordon: That's why you revert the hacks 15.56.34 # Hacks upon hacks.... 15.56.43 # _if_ you can be bothered and remember about them 15.56.45 # Actually, that's why you put the hacks in the stable branch, and fix it properly in the dev branch 15.56.47 # s/you/someone 15.56.48 *** Saving seen data "./dancer.seen" 15.56.54 # rasher: Same thing. 15.56.57 # Llorean: actually you don't revert the workarounds, you commit them in the release branch :) 15.57.08 # Hah, hacks leading to stabliity...whatever next. 15.57.08 # Nico_P: Yes, yes. I was simplifying the situation. :-P 15.57.19 # Hacks can lead to stability. 15.57.25 # Maybe at a loss of performance, or maintainability though 15.57.27 # hmm.... this starts to sound ok 15.57.50 # loss of maintainability? 15.57.55 # But as far as I'm concerned, with a "release" or "stable" version, you concern yourself with what the user sees, not what coders see. 15.58.02 # who decides when to update the stable branch? 15.58.03 # I don't think that would be a reasonable price. 15.58.04 # bluebrother: Harder to fix the code later if something new goes wrong. 15.58.10 # bluebrother: not as important if it's in the stable branch 15.58.21 # bluebrother: The whole point is that they aren't left in the "real" code. They're only there for the user-version. 15.58.29 # JdGordon: maybe a kind of approval would be needed for makor changes to go in the stable branch 15.58.37 # and thourough testing 15.58.49 # so /me would never commit to that branch :p 15.58.53 # Would users use the stable branch? It seems there are plenty who choose a custom build rather than SVN as it is. 15.58.56 # Nico_P: I'm still of the opinion that the stable branch should be branched from the dev branch once in a while 15.59.10 # wouldn't a freeze period which is only used to fix bugs help development as well? 15.59.15 Join Jon-Kha_ [0] (n=Jon-Kha@80-248-243-10.cust.suomicom.fi) 15.59.15 # Yes 15.59.16 # rasher: multiple stable brnaches? 15.59.25 # JdGordon: well, then you close the old stable branch 15.59.34 # Only the most recent would get any fixes, I suspect. 15.59.40 # rasher: I don't hink so, but the stable branch would need to stay in sync 15.59.41 # rasher: whats to say the new stable is actually more stable than the old one? 15.59.47 # afterwards there could be a (of the nearly-release state) branch and include only workarounds for known bugs 16.00.27 # if we had branches, we should have a fair few... how about an AA branch? and a custom list position/scroll/width branch? 16.00.27 # JdGordon: there's no guarantee, but you freeze and branch to attempt to avoid it 16.01.08 Join low_light [0] (i=c730180b@gateway/web/cgi-irc/labb.contactor.se/x-b7b25452b235be84) 16.01.12 # * Febs runs screaming from the support morass that so many branches would become. 16.01.18 # JdGordon: Why not just have that code be finished in a commitable manner? 16.01.23 # I think three branches is good. 16.01.31 # Old-stable, New-stable, and Dev 16.01.57 # New-stable only existing if for some reason Old-stable becomes unmaintainable, and then old-stable is closed once the new-stable is deemed "good enough) 16.02.12 # unmaintainable == some change is too difficult to sync 16.02.16 Join Dylan7262 [0] (i=7cbaf29e@gateway/web/cgi-irc/labb.contactor.se/x-c880eac559b47284) 16.02.29 # Hey people 16.02.49 # Llorean: Dev == trunk, and stable branches could actually be release branches 16.02.50 # just wondering if someone can help me please? i have a 5th gen iPod video 16.03.02 # Nico_P: Yes, dev == trunk. 16.03.16 # Nico_P: I guess in my head, trunk is arguably still a branch in a manner of speaking. 16.03.17 # well, branches are cheap arnt they? why not allow everyone to create branches for their vairous WIP's? (everyone is obviously the current commiters.. not literally everyone) 16.03.28 # We only need to maintain one stable release, right? 16.03.52 # everyonce can setup his personal branch at home ... 16.03.53 # pondlife: Yes, but if you can't sync it for some reason, then you need a place that's not trunk, but also not that, to work on getting a new stable release rolling along. 16.03.53 # the stable branch I was mentioning should be somthing like "release_3.0.x" 16.03.57 # just think of git-svn 16.04.03 # Llorean: Sync it? 16.04.14 # branches are cheap, but merges? 16.04.20 # JdGordon: us git fot that 16.04.27 # pondlife: If some significant bug-fix or stability enhancement in trunk can't be backported effectively, and it's decided that it's better to re-branch. 16.04.31 # bluebrother: merges are not so cheap in SVN 16.04.33 # I assumed that it would be feature-frozen. 16.04.43 # Nico_P: that was what I wanted to say ;-) 16.04.48 # pondlife: You freeze the features, but backport bug-fixes. 16.05.06 # bluebrother: yeah, I think we agree :) 16.05.07 # Serious bug fixes that can't be back-transported would be a reason for a new release from the trunk. 16.05.10 # and while having a feature freeze development of new features can go on the same way: in local trees. 16.05.12 # pondlife: You can also backport features if they're considered really bug-free, in preparation for the next release. 16.05.18 # Nooo 16.05.39 # Stable = bug fixes only, and careful ones at that. 16.05.45 Quit Toki (Read error: 104 (Connection reset by peer)) 16.05.48 # Dev = all else 16.05.54 # pondlife: Then how do you put together "next release"? 16.06.01 # Llorean: branch from trunk? 16.06.05 # after a freeze 16.06.09 # with a new release branch 16.06.20 # rasher: But couldn't you also have "stable", "next release" and "trunk"? 16.06.29 # I say the freeze should affect the release branch after it's created 16.06.38 # Stable gets only bug fixes, next release gets bug fixes and "non-buggy" features. 16.06.42 # Trunk is everything else 16.06.42 # why a "next release"? That would require merging all the time 16.06.44 # yeah, freeze never happens on trunk 16.06.44 # Llorean: I think you should only create "next release" at the point stable gets unmaintainable or a new release is wanted 16.07.08 Join BobShield [0] (i=rshield@c-24-15-123-57.hsd1.il.comcast.net) 16.07.16 Join DerPapst [0] (n=DerPapst@tux.isd-internet.de) 16.07.35 # Dylan7262: you should just ask your question 16.07.42 # rasher: If you have an in-sync next release, you can publish it every 3 months as the new current-release, and simply apologize that few features have made their way into it rather than having to do hard freezes or anything 16.07.48 # I think it would be better to just branch upon a release, and only bugfixes for the released version should get there 16.07.50 # Or even publish it monthly 16.07.53 # rasher: with releases close enough from one-another, the stable branch wouldn't be necessary... it would just be the current release branch 16.08.07 # Nico_P: that's my thinking as well 16.08.15 # Llorean: but that'd require keeping "next release" in sync 16.08.17 # I just think that there's no reason that once a feature has been "tested" it can't be backported to some "stable-ish" version. 16.08.17 Quit Dylan7262 ("CGI:IRC (Ping timeout)") 16.08.36 # Rather than keeping it mixed in with all the unstable features 16.08.37 Quit Jon-Kha_ (Read error: 131 (Connection reset by peer)) 16.08.38 # but backporting can be quite painful ... 16.08.59 # so how realistic ist that someone will do it? 16.09.10 # depends on the bug 16.09.15 # JdGordon: not bug, feature 16.09.18 # both 16.09.28 # Well, someone has to either backport "good" features, or fix/remove all "bad" features before a release. 16.09.31 # hang on, features dont get backported 16.09.44 # JdGordon: in Llorean's world they do! 16.09.46 # JdGordon: Depends on how you look at it. 16.10.07 # new features should mean a new stable 16.10.28 # then we would need to release much more often. 16.10.36 # so? 16.11.21 Part wippeout 16.11.44 # My proposal: Once a release is wanted/needed (old release is no longer maintainable), a new branch is created from trunk, and work focuses on bugfixing that branch. At some point it's released, and after that, work continues on trunk, and bug-fixes (and only bugfixes) are backported to the release-branch and the release is updated with a point-release. 16.11.46 # well, I wouldn't object in releasing more often 16.12.36 # And yes, releases should happen more often, possibly a couple of times per year 16.12.39 # but that would need to not add multiple features at once, and possibly add a much shorter fixing freeze after a new feature comes in 16.12.39 # if not more 16.12.44 # followed by a release. 16.13.02 # rasher: I think I agree with your proposal 16.13.08 # well.. how often does a major new feature go in? not very... 16.13.19 # branhcing to a new stable on each big one would be fine 16.13.32 # I'm not sure. 16.13.33 # JdGordon: it would go in the trunk, then in the new major release 16.13.54 # Nico_P: yeah, i skipped a step,... 16.13.57 # at least we would need to feature freeze trunk after a new feature goes in for, say 2 weeks and concentrate on fixing 16.14.09 # once the branch happens no moer bug fixes should need to be put in 16.14.34 # then rebuild all the stable builds on each enw commit to than branch instead of the dailies 16.14.54 # bluebrother: why ? the feature goes in the trunk, then gets tested/fixed until the next release branch 16.15.05 # then in the release branch it gets fixed even more 16.15.20 # no, it sholdnt go into release untill its bug free 16.15.28 # thats the whole point of the release branch 16.15.32 # petur: ping 16.15.34 # JdGordon: this is a utopian ideal 16.16.02 # JdGordon: the release branch would be only for fixes to the features it contains 16.16.06 # rasher: obviously... but if no fixes get commited for a few days or a week it can be considered bug free and branched 16.16.21 # Nico_P: yes, but not to the feature that caused the branch 16.16.25 # JdGordon: obvioulsy, we'd need to agree on what changes to include in a release 16.16.58 # I don't think having multiple branches will help much 16.17.11 # JdGordon: the way I see it, a feature doesn't cause a branch. It's a release decision that causes a branch 16.17.12 # it rather looks to me as it would create more hassle ... 16.17.20 # I really believe very strongly that the model I proposed would work well. Using "a huge feature went in" as a reason to branch also works in my model. 16.17.33 # say we decide to release 3.0 soon, then we create a 3.0 branch and nothing goes into it but fixes 16.17.38 # "a huge feature that we want to release", that is. 16.19.51 # austriancoder: bad timing... work stkov... what's up? 16.21.13 # rasher: maybe it would be good to post a proposal on the ML 16.21.42 Quit idnar (Nick collision from services.) 16.21.45 Join idnar_ [0] (i=mithrand@unaffiliated/idnar) 16.21.47 # Nico_P: I'll put something together. Basically re-stating what I just said. 16.22.04 # cool :) 16.22.05 # petur: I am working in integrating the current stack. I need to call usb_stack_start() and usb_stack_stop() to start and stop it, but usb_enable seems to be never called with argument true. So at the moment I am doing the start call in usb_detect, which leads that start() is called very very often. 16.22.21 # petur: but its not that important and we can talk about it later the day 16.23.33 # austriancoder: I'm having real life obligations tonight, it could be quite late when I pop in again... 16.23.50 # lies!!!! 16.24.02 # petur: no problem 16.24.09 # austriancoder: who calls usb_enable? 16.24.56 # petur: usb_slave_mode() in firmware/usb.c and the bootloader 16.25.21 # so whenever a connection is detected? 16.27.17 # nope - usb_tick checks for the connection and notifys others: queue_post(&usb_queue, USB_INSERTED, 0); 16.28.14 # petur: cant find a place where usb_slave_mode(..) is called in the source 16.28.31 # that would explain it, no? 16.28.52 # amiconn: you wouldn't happen to know anything about the effects of not properly matching the impedance of the cartridge at the amp input stage? 16.29.04 # I would expect to start the queue on USB_INSERTED 16.29.13 # s/queue/stack 16.29.20 Join Adikdid [0] (n=chatzill@CPE-58-168-167-56.vic.bigpond.net.au) 16.30.12 # hi can someone help me? 16.30.48 # how do i get album art to shoy up on my 5th gen iPod 16.31.08 # petur: so for the moment I will enable and disable the stack in usb_detect - later we can cleanup the usb stuff 16.31.24 # Adikdid: not supported officially, go see the forum 16.31.43 # Ah, damn 16.31.59 # Adikdid: here's some info http://www.rockbox.org/twiki/bin/view/Main/AlbumArt 16.32.07 # austriancoder: why are you getting multiple usb_detect? 16.32.45 # petur: i dont get multiple detects... i have the problem that after a connect usb_enable is _not_ called, where i enable/disable the stack 16.33.24 # hmmm, you said above "So at the moment I am doing the start call in usb_detect, which leads that start() is called very very often." 16.33.40 Join nerochiaro [0] (n=nerochia@adsl203-164-174.mclink.it) 16.34.15 # petur: correct... in usb detect i have something like: 16.34.35 # if (connected == false) { usb_stack_stop(); return false; } /* do we want autodetection? */ if (usbcore.mode == AUTOMATIC) { logf("automatic mode"); UDC_OTGSC |= 0x5F000000; if ((UDC_OTGSC & 0x100) == 0) { usb_controller_select(HOST); } else { usb_controller_select(DEVICE); } } /* TODO correct place? */ usb_stack_start(); return true; 16.34.35 Quit low_light ("CGI:IRC (EOF)") 16.34.38 # anyway, I don't know the relation between usb_enable and usb_detect. Do you want to start the stack at boot or at connection? 16.34.49 # austriancoder: use pastebin please 16.35.30 # petur: so if i do the enabling in usb_detect, I dont know for what usb_enable exists!! 16.35.57 # petur: I want to start it under a running rockbox, when i insert the usb cable 16.36.10 # austriancoder: don't assume the current code is correct... check it... 16.36.23 # petur: okay.. 16.36.38 # starting at connection would be best 16.36.45 # (imo) 16.37.29 Join Domonoky [0] (n=Domonoky@85.179.50.213) 16.37.36 # you probably will need to stop playback and stuff to claim the iram 16.38.04 Quit JdGordon (Remote closed the connection) 16.38.10 # * austriancoder will spend some hours later the day to understand fully rockbox code 16.38.51 # don't forget to check the tx problem too ;) 16.39.12 # work always piles up after holiday :p 16.40.42 # austriancoder: It looks like we're at about the same point... I'm starting to try integrating my MoB work in playback.c :) 16.40.52 # petur: jep... I only need to write selection of usb device driver and then I want to do the first commit. WIll have only two dummy drivers, but for testing its okay. 16.41.42 Join Adikdid_ [0] (n=chatzill@CPE-58-168-149-30.vic.bigpond.net.au) 16.42.21 # hey where do i actually download the album art patch? 16.42.57 # petur: and maybe i get this also working: idea: all drivers should be something like rockbox plugins... rockbox usb drivers.the app code scans for usb drivers and register them automaticly in the stack.We only need one *.c file for a driver and we dont need any *.h files with onemethod in it: usb__init(void); 16.43.12 # Adikdid_: are you able to build rockbox from source ? 16.43.22 # what do you mean? 16.43.25 # Adikdid_: from the patch tracker (flyspray) but you have to compile.. or use an inofficial build (see forums) 16.43.53 # i cant domonoky, it wont let me sign upto the forums 16.44.01 # can someone please send it too me over here? 16.44.07 # austriancoder, Nico_P: I don't think it is important that commits are done soon enough, make sure the code is well tested and has no bad effects for users... 16.44.28 # Adikdid_: you dont need to signup for the forum, to just see some thread.. 16.44.32 # Yes, and make patches available in the meantime. 16.44.38 # yup 16.44.39 # petur: I have a git repo on which I plan to do my work 16.44.56 # * austriancoder has only online patches 16.45.06 # Nico_P: good... nobody presses for commits atm 16.45.07 # ... I've already started the rest of the work on another repo 16.45.16 # Nico_P: I'd like to see a Flyspray entry with patches against SVN too... git can do that quite easily, right? 16.45.23 # austriancoder: I can give you push access to my public repo if you want 16.45.47 # http://www.rockbox.org/tracker/task/3045?histring=album%20art 16.45.52 # is this thread right? 16.45.53 # don't mix the developments please 16.45.58 # pondlife: currently I have only one commit in my mob branch for rockbox git repo... 16.45.58 # Nico_P: I am not very familiar with git.. at the moment I dont see a need for it 16.46.18 # Nico_P: do you need a linked list in your project? 16.46.33 # austriancoder: believe me, it's great ;)... I loved it for offline work 16.46.40 # yes I have one 16.46.50 # Adikdid: thats the patch tracker.. so if you want to use a patch from there, you have to be able to compile rockbox yourself.. 16.47.06 # hi Domonoky 16.47.10 # Adikdid_: seen http://www.rockbox.org/twiki/bin/view/Main/AlbumArt ? 16.47.11 # Nico_P: I will set one up at home too when I get the time :( 16.47.17 # hi bluebrother :-) 16.47.36 # I was wondering if it's a good solution to extend ZipInstaller to also be able copying files instead of extracting them. 16.47.41 # austriancoder: are you going to need a linked list ? 16.47.45 Join My_Sic [0] (n=MySic@mur31-1-82-237-204-133.fbx.proxad.net) 16.47.49 # that way we could reuse it for the voice files. What do you think? 16.48.17 # Nico_P: yep.. and I am using this one: http://www.christian-gmeiner.info/soc/linked_list.patch 16.48.24 # petur: http://www.rockbox.org/twiki/bin/view/Main/GitVersionControl is good start in case you don't know about it 16.48.28 # Nico_P - i cant find where to downoad it? 16.48.34 # bluebrother: sounds good, just make a parameter to skip the unzipping.. 16.48.36 # * petur knows 16.48.51 # Adikdid_: a patch is a tect file you apply to the source code 16.49.01 # s/tect/text 16.49.10 # yeah -- I thought about a setUnzip() which is true per default -- if it's false just copy the downloaded file to the target location 16.49.25 # ok, so how do i do this, then? 16.49.26 # please 16.49.27 # thats good.. 16.49.31 # only "ZipInstaller" might be a bit ... off after that ;-) 16.49.36 # but I can live with it 16.49.50 # ah, and what do you think about adding doxygen comments to the sources? 16.50.13 # Adikdid_: one of the first lines of http://www.rockbox.org/twiki/bin/view/Main/AlbumArt says this : "If you don't know what a patch is or how to apply one, you should have a look at the SimpleGuideToCompiling." 16.50.25 # with a link to http://www.rockbox.org/twiki/bin/view/Main/SimpleGuideToCompiling 16.50.57 # bluebrother: we could rename the ZipInstaller class :-) doxygen comments would be nice.. but not too much comments.. doxygen comments tends to comment usesless things :-) 16.51.01 # austriancoder: looks nice... I wrote quite a simple one 16.51.19 # yes, but i dont get it 16.51.27 # Nico_P: I was lazy and tooked the liked list impl from linux kernel 16.51.41 # Adikdid_: then you should head to the forum and download an unofficial build 16.51.45 # useless comments? I'm usually quite brief in doxygen comments, what could be useless there? 16.51.57 # It just makes browsing the code nicer imo :) 16.52.03 # well thats what i have been talking about fro the start 16.52.13 # a link to a unoficcial build. haha 16.52.35 # bluebrother: often the comment just tells the same as what the function name implies.. but we can do better :-) 16.52.53 # use cryptic function names? *g* 16.52.57 # hehe 16.52.58 # lol 16.53.01 Quit Adikdid (Read error: 110 (Connection timed out)) 16.53.04 # Nico_P: we need to choose one linked list impl, which we both uses 16.53.13 # hi? 16.53.14 # Adikdid_: sorry, I didn't know that... I can't do much for you but point you to the forums 16.53.21 # * bluebrother read something about "ugly variables" once 16.53.26 # austriancoder: that sounds like a good idea 16.53.34 # can you give me the link please? 16.53.39 # ... a reasonable one too 16.54.01 # Adikdid_: go to the forum, and choose an unofficial build, its not that hard.. 16.54.01 # Adikdid_: is the website *that* unuseabe ? http://forums.rockbox.org/ 16.54.21 Join low_light [0] (i=c730180b@gateway/web/cgi-irc/labb.contactor.se/x-b16af5288b2d17f3) 16.54.39 # no i can use that one 16.55.06 # if the website is that unusable, how unusable Rockbox must be? :o 16.55.13 # austriancoder: I'm quite happy with my implementation... it's quite short and simple and it suits my context well 16.55.30 # austriancoder: but maybe it wouldn't be appropriate for yours 16.55.40 # what? 16.55.53 # if only the small one is needed, go for that... 16.56.03 # Nico_P: I only need it to have all usb drivers in list. 16.56.07 # petur: mine is also small 16.56.32 # so it would be fine, when we commit one linked list soon 16.56.42 # austriancoder: a possile problem with mine is that it's not separate from the rest of the code and it acts directly on my data struct 16.56.43 # then get an agreement between you too ;) 16.56.51 # Nico_P: can I see your impl 16.57.16 # austriancoder: sure :) http://repo.or.cz/w/Rockbox-MoB.git?a=blob;f=testplugin.c;h=41a248ab7b4722f92e2acb510ab13fedf8d13453;hb=no_rb_in_rb#l130 16.57.46 # it would need to be made more generic though... and it's quite basic 16.58.50 # does anyone here download with torrents? 16.59.16 # Nico_P: mine is generic 16.59.18 # Adikdid_: please stay on topic.. only rockbox talk allowed here.. 16.59.45 # surely your allowed to talk about other stuff? 17.00.09 # Adikdid_: please see http://www.rockbox.org/twiki/bin/view/Main/IrcGuidelines 17.00.29 # Nico_P: http://isis.poly.edu/kulesh/stuff/src/klist/ 17.00.38 # Adikdid_: try #rockbox-community 17.00.42 # no 17.01.31 # there is knowone there 17.01.47 # austriancoder: I agree it's pretty appealing 17.02.11 # nice sarcastic quote from slashdot: "Remember: you should be able to do whatever you want with information, except if its the GPL! Then you have to follow the GPL!" :) 17.02.37 # hmm, can't I do git diff ? Doesn't seem to work :( 17.02.45 Part Adikdid_ 17.04.41 # bluebrother: you want to diff only some particular files ? 17.04.42 Join ian_hawdon [0] (n=ian@86.154.187.94) 17.05.02 # yes. Is that possible? 17.05.06 Part ian_hawdon 17.05.33 Join dandin1 [0] (n=dandin1@bas7-ottawa23-1088824222.dsl.bell.ca) 17.05.59 # bluebrother: it seems to work for me 17.07.19 # bluebrother: "git diff file1 file2" shows the diff between the working copy and the repo for file1 and file2 17.08.00 # hmm. Strange, that didn't work for me. 17.08.41 # what version are you using ? are the files in the repo ? 17.09.04 # ah ... seems I was in the wrong folder. 17.09.36 # but it's somewhat strange that I didn't get an error message (and git diff showed me the diff) 17.11.00 # Nico_P: so shall be both use the linux linked list? 17.11.48 # austriancoder: I'm all for it 17.12.19 # austriancoder: though I'll probably focus on other things and port my code to that list when I get thet time 17.12.19 Quit BobShield (Read error: 104 (Connection reset by peer)) 17.12.33 # Nico_P: okay 17.12.34 # but it seems to be a good and reliable choice 17.13.06 # have you made sure it compiles and works nicely in rockbox ? 17.13.41 Join Adikdid [0] (n=chatzill@CPE-58-168-149-30.vic.bigpond.net.au) 17.13.49 # hi me, again 17.14.45 # Nico_P: I will do some extreme testing tonight and/or tomrrow 17.15.24 # cool :) let me know if you need help 17.15.42 # maybe there are other linked lists in rockbox we could port too... 17.15.49 Join BobShield [0] (i=rshield@c-24-15-123-57.hsd1.il.comcast.net) 17.16.37 # I believe database uses linked lists, but I'm not sure. 17.17.39 # i downloaded a theme called Purpbox 17.17.56 # how come the actual images in the background dont show up? 17.18.08 # and why doesnt it look like it does in the preview on the rockbox website? 17.18.17 # bluebrother: is the tracker cleanup "week" still on ? and what results did it yield ? 17.19.30 # Adikdid: Have you installed the fonts package? Also, purpbox requires an unsupported build. Any problems you have with it, you should take up with the author of the WPS or the maintainer of the build you're using. 17.20.38 # Nico_P: it ended last sunday. We got down to less than 800 open tasks (over 1000 before it) 17.20.56 # nice :) 17.21.06 # ok rasher, does anyone know of any themes that actually look like what they do on the rockbox site? 17.21.25 # IMO we should repeat it in a couple of month ;-) 17.21.48 # Adikdid: They should all look like the screenshot, assuming you use the build they recommend, and have the required font installed. 17.23.46 # rasher, i'm on the rock-themes.org page and i have a 5gen 30gig vid iPod 17.24.16 # so should i choose iPod Video from the "identify your player" page? 17.24.45 # Adikdid: Yes. What else would you chose? 17.25.53 # ok so what do i do now? 17.26.05 # like i mean i have installed the purpbox theme too my iPod 17.26.37 # Adikdid: Then you read that the purpbox theme needs "Senab's build" (an unofficial rockbox version) and install that. 17.26.47 # Adikdid: you still haven't said whether you've installed the fonts either 17.26.56 # yes i have 17.27.21 # Adikdid: Again, this is an unofficial version of Rockbox, and we will not help you if it has bugs or other problems. 17.27.42 # i installed the fonts package fronm the "fonts page" 17.27.59 # so if you've done that, and you've installed senab's build 17.28.04 # then we can't help you any further 17.28.06 # go ask senab 17.28.17 # Adikdid: you should read the forum thread dedicated to Senab's build: http://forums.rockbox.org/index.php?topic=7942.0 17.28.46 # on the senab d/l page it says there is two versions "normal" & "cop" 17.29.01 # would it be best to go with normal? 17.29.13 # Adikdid: we don't know - ask senab 17.29.24 # we've no idea if there are any other differences between them 17.29.29 # only senab knows 17.31.36 # OK, so i installed that Senab build 17.31.40 # and the fonts pack 17.31.43 # anything else? 17.32.14 # No. 17.32.27 # If the theme still looks wrong, it's a problem with the theme. 17.32.34 # Or with Senab's build. 17.32.46 # Not really something we can help you with. 17.33.44 # no i meant is there anything else i need to install before i dosconnect my iPod and see if it has all worked ok 17.34.21 # Same answer. 17.34.26 Quit DerPapst ("So Long And Thanks For All The Fish!") 17.34.35 # 42 17.35.45 # We apologise for the inconvenience 17.35.52 # :) 17.36.14 # sall good but damn it sasy it has to rebuild my database 17.38.08 # petur: it's amazing, that actually appears to work as D. Adams said it would ;) 17.38.09 Join Soul-Slayer [0] (n=Administ@89.241.171.92) 17.39.00 # is it easy to make a theme? 17.39.20 # read the wiki page on the subject and decide for yourself 17.39.45 # http://www.rockbox.org/twiki/bin/view/Main/CustomWPS 17.40.16 # * petur looks at GodEater with his left head 17.40.40 # (my computer has dual head) 17.40.41 # while the right one shovels pan galatic gargle blasters down its throat no doubt 17.43.59 Quit Adikdid ("ChatZilla 0.9.78.1 [Firefox 2.0.0.6/2007072518]") 17.44.05 Quit My_Sic ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 17.44.27 # I found a program that is charging people to use it, and it's core element is ffmpeg... And it isn't being distributed with it's source code, and not even acknowledgement of the license... Surely thats breaching the GPL? 17.45.00 Join XavierGr [0] (n=xavier@ppp221-52.adsl.forthnet.gr) 17.45.19 # Soul-Slayer: If they're distributing ffmpeg without an offer of source or acknowledgement that it's GPL, yes. 17.47.17 # * Soul-Slayer wonders what he should do about it 17.47.27 # report it to the EFF 17.47.36 # EFF? 17.47.38 # or mail ffmpeg guys 17.47.54 # I'd say contacting ffmpeg is at the top of the list. Let them handle it however they want. 17.48.01 # Ok. 17.49.11 # I'll see what they have to say in IRC 17.54.29 # Soul-Slayer: what's the program ? 17.54.42 # http://stinkbot.com/Tubesock/index.html 17.55.14 # Converts youtube videos into other formats, but it doesn't even mention it's using ffmpeg 17.55.38 # Even in their FAQ, the legal aspect only covers whether it's legal to download from Youtube, nothing about ffmpeg 17.55.49 Quit XavierGr_ (Read error: 110 (Connection timed out)) 17.55.53 # how do you know it uses ffmpeg ? 17.56.15 Join polluxx2006 [0] (n=polluxx@xdsl-81-173-237-185.netcologne.de) 17.56.25 # The windows version uses ffmpeg.exe 17.56.31 # And the mac version is using ffmpeg 17.56.41 # with no extension, but no license bundled with it 17.56.50 *** Saving seen data "./dancer.seen" 17.57.11 Quit pondlife ("disconnected has pondlife") 17.58.15 # if they're using ffmpeg like that (i.e. calling it externally), then isn't that a valid use of the LGPL ? 17.58.41 # * GodEater notices the time and has to run 17.58.49 # I'm not sure, that's why I'm wondering 17.58.50 # * petur too 17.58.55 # Well, they need to bundle the license and a written offer for source-code, at the very least. 17.58.57 # Surely they need to mention the license somewhere though? 17.59.03 Quit petur ("work->home->real life") 17.59.38 # * bluebrother has voice file installing in rbutil 18.02.15 Quit polluxx2006 () 18.05.13 # nice :-) 18.13.45 Nick idnar_ is now known as idnar (i=mithrand@unaffiliated/idnar) 18.23.30 # bluebrother: is the voice file really named english.lang ? i thought it should be english.voice 18.24.04 Join Siku [0] (i=Siku@dsl-kpogw4-fe55df00-86.dhcp.inet.fi) 18.24.46 # d'oh! 18.24.47 # Domonoky: You're right 18.25.11 # :-) 18.25.58 # and I just updated my windows binary :'-( 18.27.15 # * bluebrother wonders who did the most oops commits 18.27.47 # * Domonoky thinks about changing the talkfile dialog, to move the configuration of tts and codec to the config dialog... it gets more and more to configure :-) 18.28.07 # hehe ;) 18.28.25 Join PaulJam [0] (n=pauljam@p54BCE1F0.dip.t-dialin.net) 18.28.50 # ok, windows binary updated once more. For those who dare to test ;-) 18.29.03 # now with accessibility plugin compiled in. 18.29.48 # hi, i have a little question: with the plungins in subfolders, where do i have to put the autostart.rock? still directly in .rockbox/rocks/ ? 18.29.51 # nice, we should get some blind users to try it.. so we get response how good/bad it is to use for them.. 18.30.01 # /.rockbox/apps 18.30.06 Join DerPapst [0] (n=DerPapst@pD9EB373F.dip0.t-ipconnect.de) 18.30.13 # thank you. 18.30.26 # err, /.rockbox/rocks/apps 18.30.32 # ok 18.30.42 # damn, I'm error-prone today :( 18.30.56 # :-) 18.32.06 # hmm, looks like RBInstaller doesn't use the ZipInstaller class 18.32.58 Join pixelma [0] (i=pixelma@rockbox/staff/pixelma) 18.32.59 # bluebrother: install.cpp (which does install rockbox) uses ZipInstaller 18.33.25 # hmm -- and what is installrb.cpp doing? 18.33.46 # looks like it isn't used anymore. 18.33.48 # bluebrother: you are in rbutil and not in rbutilqt :-) 18.34.20 # no, i dont have this file 18.34.34 # so its not in svn 18.34.53 # there is installbl.cpp which installs the bootloader 18.34.54 # ah. I have this file but it isn't in svn 18.35.42 # installbl should be renamed to installbootloaderwindow.. :-) 18.37.43 # well, I won't object :) 18.44.37 # * Domonoky renamed it.. :-) 18.47.04 Join My_Sic [0] (n=MySic@mur31-1-82-237-204-133.fbx.proxad.net) 18.48.04 # * bluebrother added some plugin ideas to the RockboxUtility page 18.48.08 # bluebrother: should i make a combined TTS Engine and Encoder configuration Tab (with title like Talkfile) or seperate Tabs for encoder and tts ? 18.49.22 # hmm, a combined tab would get quite crowded, wouldn't it? 18.49.39 # yes, thats likely.. 18.50.48 # I think I'd use two tabs 18.52.01 Join haemmy [0] (n=stefan@194.208.162.140) 18.54.38 # hmm, my h300 just turned off during operation and i wasn't able to power ot on again until i connected the charger. the time and date was then reset. does this mean my battery is faulty or could there be another reason for this behaviour? 18.55.02 # (the battery was at least half full) 18.56.59 # * alienbiker99 needs a new h300 battery 18.57.36 # * PaulJam propably too :( 18.58.07 # actually i think i need to just solder the wire back on, it ripped out 19.00.17 # * Nico_P wonders why FS#821 hasn't been rejected 19.00.30 Quit BigMac (Remote closed the connection) 19.04.51 Quit TinoM (Read error: 110 (Connection timed out)) 19.09.40 # preglow: Input impedance for MC or MM systems shouldn't matter, as long as it is high enough (a few dozen kOhm). Only piezo pickups (?) want a really high impedance (>=500kOhm) (and they need no riaa deemphasis) 19.09.56 Join dan_a [0] (n=dan_a@217.23.173.156) 19.12.57 Join Jon-Kha_ [0] (n=Jon-Kha@80-248-243-10.cust.suomicom.fi) 19.17.08 Quit PaulJam (".") 19.22.17 Join sergey [0] (n=sergey@ppp91-76-107-155.pppoe.mtu-net.ru) 19.28.37 Join chrisjs169_ [0] (n=chrisjs@pool-71-254-214-208.hrbgpa.east.verizon.net) 19.28.45 # amiconn: yeah, i tried soldering on a resistor of 47kohm and a 100 pf cap, and it didn't do anything 19.28.55 # amiconn: so the problem with too much bass/too little treble persist :/ 19.29.07 Quit chrisjs169 (Nick collision from services.) 19.29.08 Nick chrisjs169_ is now known as chrisjs169 (n=chrisjs@pool-71-254-214-208.hrbgpa.east.verizon.net) 19.31.53 Join jgarvey [0] (n=jgarvey@cpe-024-162-254-070.nc.res.rr.com) 19.35.35 Join Quelsaruk [0] (n=kvirc@233.pool85-61-15.dynamic.orange.es) 19.35.37 # hi 19.36.30 # preglow: Sounds like you're applying too much un-riaa'ing 19.36.48 # * amiconn prefers to stay away from vinyl and other analog relics if possible 19.40.30 # amiconn: Would you be interested in the value of DEV_EN on a G4 greyscale? If so, C2C3197F 19.41.43 # amiconn: i wonder... don't you have the nano flash rom dumps i gave you anymore? 19.41.48 # is sansapatcher the only way to get the rockbox bootloader on a sansa? 19.42.17 # DerPapst: Flash update file != flash rom content 19.42.20 Join desowin [0] (n=desowin@79.187.93.186) 19.42.42 # i thought they were the same 19.42.47 Quit Nico_P (Remote closed the connection) 19.42.52 # dan_a: So we have another unknown bit, bit 17 19.43.19 Quit sergey (Read error: 110 (Connection timed out)) 19.43.32 # dan_a: Would be nice if you could give my other patch a go on G4 grayscale 19.43.43 # * DerPapst just remeberd to do the test... 19.43.55 # (the one that shows 2 LCD registers and tries LCD suspend/reenabling 19.44.37 # amiconn: Where can I get it / how far back through the logs do I need to look 19.44.47 # http://amiconn.dyndns.org/lcd_test.diff 19.45.32 # amiconn: I'm just trying to get USB detection on the G3, then I'll do that on the G4 19.45.56 # With that build, first enter "View I/O Ports" and note the 2 LCD register values. Then enter "View HW Info". That should put the LCD into suspend for 2 seconds, then wakeup 19.46.41 # Re-check the LCD registers afterwards (they might be different if I made a mistake in my RE research) 19.47.11 # It's already tested on G3 by DerPapst 19.47.23 # dan_a: Did you find something regarding USB on G3? 19.48.02 # Afaiu, apple does *not* use the built-in USB controller of the PP5002 (which is USB1.1 only) 19.48.28 # amiconn: Only which GPIO pin lights up when it's plugged in, but IIUC that should be enough to put it into disk mode - the same as the behaviour on the other iPods 19.48.41 # Nope 19.48.46 # amiconn: correct. 19.48.54 Join sergey [0] (n=sergey@ppp85-140-150-52.pppoe.mtu-net.ru) 19.48.55 # The GPIO pin isn't enough to distinguish USB from pure USB power 19.49.43 # On PP502x we initialize the built-in USB controller "a bit", enough to make it tell us whether it's a real USB connection 19.49.46 Quit haemmy () 19.50.02 # Ah. I'll skip that test then! 19.50.35 # And in fact you could also test that LCD patch on G3, in case yours has a different LCD panel (there seem to be 3 versions according the the OF's tables) 19.51.09 # Well, you could make it reboot into USB mode when detecting USB power. Maybe that's better than not rebooting at all 19.52.00 # It will take some disassembling to do it properly 19.52.06 # i think you only connect a 3G to usb when you want to transfer files. otherwise there is really no reason to connect it to usb 19.52.10 # (i.e. initialising the USB controller) 19.55.06 # If your G3's LCD panel is different *and* you also observe unstable blacklevel (black becomes "less black" when large black areas are displayed) you could also test another idea that DerPapst will test soon 19.55.33 # i'm installing the build already 19.55.34 # I tested it on 2nd gen and it makes the display significantly more stable (although not perfect) 19.56.05 # I do have the unstable blacklevel issue. OF isn't perfect either. I'll tell you about the panel once I've done the G4 19.56.51 *** Saving seen data "./dancer.seen" 19.58.23 Join TinoM [0] (n=Tino@i5387C514.versanet.de) 19.58.31 # I know that OF isn't perfect, but I found a controller setting that improves things (and the OF doesn't use) 19.59.44 # woo... the contrast increased a huge bit... 20.00.31 # from contrast setting 52 to 42 20.00.38 # they look similar 20.00.52 # What about the changing blacklevel? 20.01.14 # dosn't change that much anymore 20.01.30 # Yeah, that's what I observe on 2nd gen as well :) 20.01.43 # So I'll add that setting to our LCD init 20.02.40 # ok. but make sure to lower the default contrast too. 20.02.57 # 40 to 42 is ok then 20.03.01 # The default is 42 for 3rd gen iirc 20.03.05 # amiconn: yeah, i know, but the filter is completely within specs :/ 20.03.27 # amiconn: ok then nvm ;) 20.04.34 # amiconn: G4 R2=0075, R3=120C. LCD goes blank with the backlight on when I go into View HW Info, and the registers are unchanged afterwards 20.06.27 # i got R2: 0055; R3: 150C on my 3G yesterday 20.07.38 # amiconn: USB detection is part of the AS3514 on e200 complete with debouncing and seems to actually function (via AS3514 IRQ). The USB-controller GPIO is not a detection line for sure. 20.09.51 Quit Soul-Slayer (Read error: 104 (Connection reset by peer)) 20.10.39 # dan_a: Goodie, so suspend also works 20.10.50 # The register values are those expected for a G4 20.11.39 # Glad to hear that... I'll check whether my G3 values match DerPapst's now 20.11.46 # On G3 you should either get 0055 and 150C, or 004A and 110C 20.11.59 Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust132.brig.cable.ntl.com) 20.12.00 # (the latter would be a type 8 LCD) 20.12.02 Quit My_Sic (Connection reset by peer) 20.12.47 # the other is either type 7 or 9 20.13.04 # Domonoky: how do i compile Dominik Wenger rbutilqt? I have found no makefile/CMakeLIst.txt 20.13.32 # austriancoder: run qmake 20.13.39 # DerPapst: correct 20.13.42 # that will create a makefile 20.13.49 # ah okay 20.15.10 # Type 7 and type 9 should be distinguishable by the contrast you need to set to make it look right (without my blacklevel improvement patch) 20.15.19 # DerPapst: which version of qt do I need? 20.15.24 # If it's around 52, it's type 7, if it's around 42, it's type 9 20.16.34 Join Soul-Slayer [0] (n=jonno@89.241.171.92) 20.16.46 # austriancoder: qt 4.03 20.16.55 # It might be that the difference is fixed by my blacklevel patch 20.17.17 # if you have it installed just type "qmake && make" when you are in the rbutilqt folder 20.17.20 # * amiconn is curious whether the OF just uses whatever its loader (or our bootloader) sets 20.17.54 # In that case a rockbox bootloader with the blacklevel patch should also fix it in the OF (as long as the OF doesn't send the LCD to sleep) 20.18.02 # Domonoky: I have 4.3.0 and compile failed 20.18.29 # 55 and 150C on my G3 - and it suspended correctly 20.19.10 # austriancoder: it should work with 4.3 ( there was a 0 to much ) :-) 20.19.21 # waht error do you get ? 20.19.40 # Domonoky: nope 4.3.0 - updateing to 4.3.1 20.19.44 # austriancoder: and linux or windows ? 20.19.49 # linux 20.20.15 # dan_a: Thanks for testing :) 20.20.16 # would ther be a ways to test that? i would like to have a lowered contrast for the OF 20.20.33 # i am running 4.3.0 on windows and it is working.. bluebrother compiles with linux.. dont know which version he uses.. 20.20.33 # Now a test on a mini G1 would complete the test 20.20.44 # amiconn: You're welcome. Thanks for your brilliant PP5002 work! 20.20.45 # Domonoky: http://rafb.net/p/F7fVuW63.html 20.20.48 # you have a mini G2? 20.20.58 # dan_a: A runtime test on G3 is still missing.... 20.21.01 # DerPapst: Yes 20.21.13 # And mini G2 can't read back LCD registers 20.21.21 # But suspend is tested and works 20.21.38 # ah.. thats because your Qt version has no accessibility support.. 20.22.13 Join My_Sic [0] (n=MySic@mur31-1-82-237-204-133.fbx.proxad.net) 20.22.31 # Domonoky: can you do some #ifdef magic to get it compile without accessibility support? 20.22.38 Quit barrywardell (Remote closed the connection) 20.23.18 # i will take a look.. *starts googling* 20.23.29 # * amiconn should also repeat his test now that DEV_EN2 setup is in place 20.24.30 # that is because of a few accessibility properties are set in rbuiltqtfrm.ui 20.24.40 # you can safely remove thos properties. 20.24.51 Join RockingD [0] (n=sergey@ppp91-76-105-64.pppoe.mtu-net.ru) 20.24.58 Join BigMac [0] (n=BigMac@c-71-234-95-131.hsd1.ct.comcast.net) 20.25.17 # dan_a: Around half of the gain is due to implementing disk poweroff on 1st..3rd gen - and that could have been done months ago. The port pin was known and documented in the ipl wiki 20.25.22 # and for the question earlier, I use qt 4.3.0 on linux and the same version (statically built) on windows 20.25.49 # amiconn: Hint taken about the runtime test ;) Do we have a list of what the bits in DEV_EN and DEV_EN2 represent? The IPL wiki isn't always accurate 20.26.07 # The other half is due to switching off clock for unused components within the PP5002. Found that by coincidence due to a slight flaw in the 1st/2nd gen firmware 20.26.42 # I know that the ipl wiki isn't always accurate 20.27.08 # sadly... and no one fixes it :-/ 20.27.15 # Unfortunately we don't have a list of DEV_EN(2) bits - and we can only try to figure out those bits which remain set by now 20.27.24 Quit ender` (" Cynics regarded everybody as equally corrupt... Idealists regarded everybody as equally corrupt, except themselves. -- Rober) 20.27.49 # 2 bits I know for sure (and one of these is not set, and wasn't set before) 20.27.57 Join son1 [0] (n=megsona@80.187.214.101) 20.28.25 Part son1 20.28.31 # ...the bits that enable the built-in LCD controller (not used) and the LCD bridge controller (used in all grayscale ipods) 20.31.53 Quit RockingD (Read error: 104 (Connection reset by peer)) 20.32.57 Join WGC [0] (n=chatzill@198.232.70.10) 20.33.12 Join ender` [0] (i=krneki@84-255-206-8.static.dsl.t-2.net) 20.37.39 Quit sergey (Read error: 110 (Connection timed out)) 20.40.31 Quit tchan (Read error: 110 (Connection timed out)) 20.40.32 Join datachild [0] (n=datachil@217-208-144-87-no75.tbcn.telia.com) 20.40.52 Nick alien___ is now known as majeru (n=cris@panzer.utcluj.ro) 20.43.13 # I just installed Rockbox 20.43.44 # congratulations! 20.43.51 Join RockingD [0] (n=sergey@ppp91-76-104-125.pppoe.mtu-net.ru) 20.44.11 # I can't access the MP3 player via windows now 20.44.16 # Says Unknown Device 20.44.29 # It runs ok otherwise 20.44.36 # Haha 20.44.37 # Version of windows? 20.44.47 Quit robin0800 (Read error: 110 (Connection timed out)) 20.44.47 # xp 20.44.54 # Shouldn't happen 20.44.59 # XP ships with UMS drivers. 20.45.01 # I guess you have a Sansa? 20.45.01 # WGC: At a guess you'll need to boot into the original firmware to transfer files 20.45.14 # How do I do that? 20.45.25 # Which device do you have? 20.45.31 Quit My_Sic ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 20.45.31 # sansa e250 20.45.36 Join tchan [0] (n=tchan@lunar-linux/developer/tchan) 20.45.52 # Hold |<< as you boot (this is in the manual) 20.45.58 # k 20.46.06 # I hope they can work the kinks out eventually 20.46.23 # I was so eager to install Rockbox that I'm a hospital waiting room. 20.46.34 # My mother has an operation today 20.46.35 # Not me.:P 20.50.46 Quit datasleep (Connection timed out) 20.51.08 # I generally think that the Rockbox firmware uses up less battery than the default one, it doesn't have that glossy colorful look 20.52.51 Join kubiix [0] (n=Miranda@adsl-pha21-156-158-212.bluetone.cz) 20.53.45 Join My_Sic [0] (n=MySic@mur31-1-82-237-204-133.fbx.proxad.net) 20.54.13 Part maffe 20.54.28 Join maffe [0] (n=maffe@barmen.interhost.no) 20.56.14 Part maffe 20.56.26 Join maffe [0] (n=maffe@barmen.interhost.no) 20.56.54 Join WGC_ [0] (n=chatzill@198.232.70.10) 20.59.05 Part maffe 20.59.20 Join maffe [0] (n=maffe@barmen.interhost.no) 21.01.11 Quit My_Sic ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 21.01.50 Quit spiorf (Read error: 110 (Connection timed out)) 21.03.24 # I should eventually organize my MP3 collection into genres 21.03.38 # 20 gigs of just mp3s in one folder is a tad much 21.04.36 Join spiorf [0] (n=spiorf@host151-202-dynamic.14-87-r.retail.telecomitalia.it) 21.05.54 # sporf? 21.13.05 Quit WGC_ ("ChatZilla 0.9.78.1-2007080401 [Firefox 2.0.0.6/2007080106]") 21.13.44 Join perrikwp [0] (n=chatzill@74.167.148.160) 21.14.42 Join |desowin| [0] (n=desowin@79.187.93.186) 21.14.43 Quit WGC (Read error: 110 (Connection timed out)) 21.15.38 Quit desowin (Read error: 113 (No route to host)) 21.16.28 Quit low_light ("CGI:IRC (EOF)") 21.19.46 Join My_Sic [0] (n=MySic@mur31-1-82-237-204-133.fbx.proxad.net) 21.19.57 # can we have some marcos like __init and __exit (linux kernel modules) in rockbox? __init is defined as __attribute__ ((__section__ (".init.text"))) - I have the following wish: in the usb stack i have host drivers and device drivers and everybody has a function like usb__init and need to be called. First i thought I could make something equalent to plugins -> e.g. serial.usbd and put them in a dir and load of them at stack init. But I d 21.19.57 # r loaded at the same time. And this is needed, when I connect e.g. second soundcard and keyboard. Has anybody an idea? 21.22.00 # hm.. but you will have to limit the amout of drivers which can be loaded, because of no dynamic memory.. 21.23.18 # Domonoky: only one device driver can active and host drivers will clean out when they not needed 21.24.16 # * preglow listens to his wma file 21.24.53 # but you want more then one host driver ? 21.24.58 Join Buschel [0] (n=AndreeBu@p54A3F288.dip.t-dialin.net) 21.26.13 # * Domonoky would just limit this for either one host or one device driver aktiv, atleast for now.. we can extend this later, when its fully working :-) 21.27.06 # If I connect rockbox device to usb hub I could have more then 1 host driver active. The design of the stack allows this. If I have all drivers in a dir e.g. .rockbox/drivers/usb/ and a new device connects to host, I load every driver, ask him: can you handle new device, if not go to the next, if yes use the driver 21.27.10 # Buschel: hiya, still hanging in there? :) 21.27.29 Join saratoga [0] (i=98039a34@gateway/web/cgi-irc/labb.contactor.se/x-e43ea44e2ea6fb50) 21.28.07 # austriancoder: thats nice.. but it will not be easy to have multiple "usb plugins" running.. 21.28.47 # Domonoky: if I compile them in e.g. rockbox.mi4 then it is no problem 21.29.26 # if you compile it in, then its not a problem.. its only a problem if you load them dynamically 21.29.29 Quit |desowin| ("use linux") 21.30.02 Join desowin [0] (n=desowin@79.187.93.186) 21.30.13 # I know... hmmm 21.30.44 # so i would compile them in for now.. we can change this, when the stack is working.. 21.38.03 Quit RockingD ("using sirc version 2.211+KSIRC/1.3.12") 21.39.53 # Bagder: had any chance to look at the repeated LANG_BOOL_SETTINGS_YES from genlang? 21.50.54 # saratoga: hi, do you have a minute ? i'm working at porting WMA decoder and having some issues 21.51.05 # perrikwp: I think I read you have a Mini 1st gen? 21.54.32 # nerochiaro: sure whats up 21.54.38 # yes 21.55.34 # amiconn: pixelma fund a volunteer :) 21.55.39 # *found 21.55.56 # perrikwp: sounded like amiconn wanted to test something on a 1st gen mini 21.56.14 # ok i would be glad to help 21.56.38 # or let someone test... hope that gets his attention now ;) 21.56.38 # perrikwp: can you compile rockbox? 21.56.53 *** Saving seen data "./dancer.seen" 21.56.53 # yes 21.57.05 # great... wait a sec... 21.57.09 # saratoga: well,since i'm using a different ASF parser, i need to make sure setup the data for the WMA decoder correctly. does the decoder need all the payloads from ASF packets to be lined up in a single continuous buffer ? 21.57.36 # perrikwp: ally this patch http://amiconn.dyndns.org/lcd_test.diff 21.57.43 # ok 21.58.12 # saratoga: that's what the rockbox codec seems to be doing, however i'm not sure i'm doing it properly since the decoding of the first block is failing 21.58.29 # perrikwp: With that build, first enter "View I/O Ports" and note the 2 LCD register values. Then enter "View HW Info". That should put the LCD into suspend for 2 seconds, then wakeup 21.58.36 # saratoga: does it need only the payload data, or also the payload header ? or some other info ? 21.59.00 # perrikwp: Re-check the LCD registers afterwards (they might be different if I made a mistake in my RE research) 21.59.33 # nerochiaro: yes, i believe linuxstb's parser does that 21.59.50 # at least his comments imply that hes memcpying each packet into a continuous buffer 21.59.51 # nerochiaro: you need to init the codec with the extradata 21.59.52 # i don't have time to compile it right now as i have to leave for an hour or two but i can test after i'm back. is that ok if i come back with results later? 22.00.15 # merbanan: you're the guy in the ffmpeg channel? 22.00.35 # last time I checked 22.00.40 # which wiki 22.00.51 Join chrisjs169_ [0] (n=chrisjs@pool-71-254-214-208.hrbgpa.east.verizon.net) 22.00.59 # merbanan: what extra data ? i'm not sure how am i expected to pass it to the wma codec. the init function requires only a context struct point. should i fill anything in that context ? 22.01.01 # i don't follow ffmpeg i only modify their code 22.01.44 Quit chrisjs169 (Nick collision from services.) 22.01.48 Nick chrisjs169_ is now known as chrisjs169 (n=chrisjs@pool-71-254-214-208.hrbgpa.east.verizon.net) 22.01.54 # http://wiki.multimedia.cx/index.php?title=Asf 22.02.01 # saratoga: i have seen these comments, but i can't understand what parts of the packet he's actually copying 22.02.05 # nerochiaro: as i recall, linuxstb's parser loads a few things into a struct, stuff like bitrate, length, etc thats needed by wma_init 22.02.40 # saratoga: that would be the waveformatext structure. i fill that too 22.03.03 # nerochiaro: read the beginning of the wma decoder source in ffmpeg, there you will understand what I'm talking about 22.03.22 # perrikwp: sure 22.03.24 # albeit yours has two extra fields in respect to mine, but you never use them anywhere. but i need to double check that structure 22.03.33 # merbanan: ok, i'll look 22.03.48 # nerochiaro: which asf parser are you using anyway? 22.04.01 # ok i'll be back in a hour or two hopefully 22.04.07 # nerochiaro: and what are you porting too ? 22.04.14 # saratoga: one made by one of the xmms2 folks. http://code.google.com/p/libasf/source 22.04.22 # oh ok 22.04.29 # ours is based on libasf very losely 22.04.44 # i've been meaning to ask about that one, do you know if it supports seeking correctly? 22.05.05 # saratoga: appearently it does, but i have not yet double checked with the author 22.05.43 # merbanan: i'm trying to port the rockbox WMA codec to an xmms2 plugin that will be used on a Neuros OSD 22.09.05 Quit XavierGr (Nick collision from services.) 22.09.05 Join XavierGr_ [0] (n=xavier@ppp221-52.adsl.forthnet.gr) 22.10.10 Join chrisjs169_ [0] (n=chrisjs@pool-71-254-214-208.hrbgpa.east.verizon.net) 22.10.13 # saratoga: i'm also trying to use the freestanding decoder you have pointed me from your homepage, but i am not sure what asf libary should i use with it 22.10.23 # nerochiaro: i don't think libasf can seek correctly in VBR files FYI 22.10.31 # at least the code doesn't look like it can 22.10.52 # nerochiaro: the zip has the asf parser built in 22.10.56 # saratoga: and the one in rockbox can ? 22.11.02 # not yet 22.11.08 # i'm working on it now 22.11.24 # we currently parse the time stamp info, but our seeks are inaccurate for some reason 22.11.43 # as far as i can tell, i'm doing the same thing as ffmpeg, but it doesn't work for me 22.11.51 # saratoga: the one in rockbox seems pretty mixed up with the rest of the plugin code though, it doesn't look very weel separated 22.11.52 Join MySic [0] (n=MySic@mur31-1-82-237-204-133.fbx.proxad.net) 22.12.03 # its not quite the same as in rockbox 22.12.08 # originally it was a seperate app 22.12.10 # saratoga: and i don't see any asf source in that zip file 22.12.18 # which zip are you looking at? 22.12.27 # http://www.duke.edu/~mgg6/rockbox/wmadeci.zip 22.12.55 # opps 22.12.58 # let me make a new zip 22.13.46 # saratoga: thanks 22.14.15 # saratoga: that would help a lot in finding out what the wma expects 22.14.45 # saratoga: also, how old is that source ? it seems pretty easy to retrofit from the rockbox one, at a quick glance 22.15.03 # er, with the rockbox on 22.15.24 # nerochiaro: i resynced it to rockbox last week 22.15.45 # though the functions are closer to ffmpeg then rockbox (it stilld ecodes one superframe at a time) 22.15.51 # try the link again 22.15.55 # should include the parser now 22.16.14 # sorry the code is a mess, i use that one specifically for dumping decoder state data to disk 22.16.23 # its the only reason i keep it synced with rockbox 22.16.59 # it makes sense, i will use it for that purpose too 22.18.09 # saratoga: it seems still to not contain asf sources 22.19.40 Quit MySic (Read error: 104 (Connection reset by peer)) 22.20.00 Join MySic [0] (n=MySic@mur31-1-82-237-204-133.fbx.proxad.net) 22.20.21 # http://www.duke.edu/~mgg6/rockbox/wmadeci2.zip 22.20.32 # stupid caching 22.21.11 # ok, looks good now 22.22.00 # sorry i'm evasive about what the decoder expects, to be honest i didn't really look to carefully at that 22.22.29 # that stuff didn't need much effort to make it fixed point so i didn't pay much attention to how it worked 22.22.57 # saratoga: no problem, maybe i can find out a way to factor out your current asf parser and use that 22.23.16 # it shouldn't be hard 22.23.16 # saratoga: or find out from the freestanding decoder what it really needds 22.23.25 # did anyone look at the codec relink problem yet? 22.23.35 Join ender [0] (i=krneki@84-255-206-8.static.dsl.t-2.net) 22.23.41 # when i switched from ffmpeg to our asf parser a while back it took me about 30 minutes of trial and error to do it 22.23.46 # saratoga: no offense but the libasf seems much cleaner thought 22.23.46 # theres only minor differences 22.24.10 # talk to linuxstb about that 22.24.16 # hehe, will do 22.24.21 # our parser continues to have issues, but it also uses massively less memory 22.24.32 # which i think was the reason linuxstb wrote it 22.24.42 # preglow: what issue is that 22.24.50 # how massively less ? i mean, roughly speaking 22.25.25 # i think libasf buffers someting like 128k worth of data or something equally ridiculous 22.25.29 # maybe more 22.25.32 Join Juice^ [0] (n=Juice@213.167.96.196) 22.25.56 Join low_light [0] (i=c730190b@gateway/web/cgi-irc/labb.contactor.se/x-55f514695e21f18e) 22.26.20 # saratoga: ah well, that's probably not going to be a problem for me, but i understand 22.26.27 # saratoga: that you need to "make" twice for codec to fully build after changes 22.26.33 Quit MySic (Success) 22.26.33 Quit My_Sic (Read error: 104 (Connection reset by peer)) 22.28.02 Quit chrisjs169 (Read error: 110 (Connection timed out)) 22.32.43 Join stripwax [0] (n=Miranda@i-83-67-214-206.freedom2surf.net) 22.33.23 Join Nico_P [0] (n=nicolas@rockbox/developer/NicoP) 22.34.39 Quit Siku () 22.36.36 Quit Buschel () 22.37.13 Quit Nico_P (Remote closed the connection) 22.38.05 Quit dandin1 () 22.38.30 # saratoga: still around ? 22.40.16 Quit ender` (Read error: 110 (Connection timed out)) 22.40.59 Join webguest49 [0] (i=50d81efc@gateway/web/cgi-irc/labb.contactor.se/x-23f192974c9dd47b) 22.41.09 Join ompaul [0] (n=ompaul@freenode/staff/gnewsense.ompaul) 22.42.33 Join salty-horse [0] (n=ori@pdpc/supporter/active/salty-horse) 22.42.38 Join haemmy [0] (n=stefan@194.208.162.140) 22.44.18 # nerochiaro: yeah i'm here 22.45.28 # saratoga: do i understand right that the rockbox decoder basically splits the superframe decoding in several steps, while the freestanding one does it all in one go ? 22.45.47 # but using the same code 22.45.49 # shouldn't the mandelbrot plugin be classified as "demo" instead of "game"? 22.46.00 Join ender` [0] (i=krneki@84-255-206-8.static.dsl.t-2.net) 22.46.18 # nerochiaro: thats correct 22.46.25 # superframes can potientially be very large 22.46.45 # i think 10s of thousands of samples 22.46.55 # so we do one frame at a time 22.47.15 # one frame can still be lots of samples though ? 22.47.26 # one frame is usally 4096 samples 22.47.34 # though i'm pretty sure that can vary 22.48.09 # the unit the decoder itself deals with is the block 22.48.10 # ok 22.49.24 Join n00b [0] (i=c00c4efa@gateway/web/cgi-irc/labb.contactor.se/x-d31fa8777ee3865a) 22.50.05 # this question has probably been answered a million times, but can someone explain to me how to configure shuffle so that it randomly chooses a directory and file each time you skip a song? 22.50.50 # i tried shuffle=yes and autochangedirectory=random and repeat=off but it doesn't seem to work...it descends the directories in order 22.51.21 # make a single big playlist, enable shuffle. smile 22.52.05 # so you have to build a playlist each time you add new files? 22.52.31 # you don't have to do anything 22.52.36 # it was a suggestion 22.52.53 # so there's another way? 22.53.59 # That's how I'd do it as well. 22.54.24 # how do you build a recursive playlist from a certain root directory? 22.54.50 # There's a setting for recursively adding files from subdirectories 22.55.04 # (Either always or ask each time) 22.56.07 # * bluebrother points to the manual at http://www.rockbox.org/manual.shtml and smiles :) 22.56.41 # i tried the manual...it isn't perfectly clear what combination of flags you need to do what I'm trying to do. 22.57.00 # in fact, no combination of flags will do what I want...I have to build a playlist and shuffle the playlist 22.57.03 # well, it's part of the concept: as Rockbox is playlist based you'll always shuffle a playlist. 22.57.18 # thanks..thats clear now 22.57.29 # if you play a folder it's a playlist too (this dynamic playlist thingy) 22.57.52 # yeah, that is common to cause confusion. 22.58.52 # Domonoky: around? 22.58.59 # rockbox is sweet ...I donated to show my love...but that is one feature of the original firmware I'll miss...being able to just shuffle the whole disk sans playlist 22.59.01 # austriancoder: I'm looking a disassembly of sansa e250 firmware (v1.00.12 EU).. I don't see any references to 0xc5000600 (USB_CONTROL) 22.59.52 # webguest49: thanks for this info :) Can you figure out the init of the usb controller? 0xc5000xxx 23.00.10 # n00b: that's easy in rockbox. if the file browser is in the root, go to the main menu -> playlists -> create playlist, then turn on shuffle, done 23.00.25 # n00b - you can play all music (with shuffle) from the database.. 23.00.36 # don't need a playlist 23.01.10 # thanks stripwax...is the database update automatically when I move files on and off the drive? 23.01.26 # n00b: you can enable auto-update. 23.01.27 # webguest49: can you tell me what tools I need to search myselfe? 23.01.33 # wow this voice crash bug thingy is really odd, I could reproduce it reliably this morning by just starting up with resume playback and entering the menu and it would hang, now it's entirely reliable... 23.01.46 Quit ender (Read error: 110 (Connection timed out)) 23.01.56 # you'll need to put these files to play again -- resuming the old playlist won't find new files (as the resume info is the dynamic playlist) 23.01.58 # austriancoder: the adresses that have references (directly) are: C5000140,C5000148,C5000154,C500015C,C5000184,C50001A4,C50001A8,C50001AC,C50001B0,C50001BC,C50001C0 23.02.29 # austriancoder: I'm using IDA 23.02.34 # does anyone know why or where we stop playback when we change language? 23.02.35 # Bagder: is sansapatcher the only way load a rockbox bootloader onto a sansa? I'm trying to figure out how to get a bootloader on the c200. 23.02.41 # * DerPapst wonders who webguest49 is.... 23.03.12 # thanks for tips folks 23.03.13 # over and out 23.03.15 # low_light: that's the only way we offer these days, but you can just put the mi4 to the unit in recovery mode 23.03.15 Quit n00b ("CGI:IRC 0.5.7 (2005/06/19)") 23.03.19 # webguest49: okay.. I own IDA, but ever failed to find references to 0xc500xxx 23.03.40 # low_light: bootloader mi4 I mean 23.05.20 Join homielowe [0] (n=chatzill@66.183.75.253) 23.06.01 # austriancoder: I use some IDC scripts to 1) make a "usb" segment 2) "make code" and find functions.. I can post on pastebin, hold on 23.06.31 # low_light: an interesting approach for you could be to add flash writing abilities to the bootloader so that you can make it run and scan things or whatever and then write the results to the "disk" (since the LCD hasn't been figured out), assuming that works similar to the e200 of course 23.07.10 Join My_Sic [0] (n=MySic@mur31-1-82-237-204-133.fbx.proxad.net) 23.07.34 # webguest49: that would be cool... because I need every input I can get to successfully get usb working 23.07.55 # Bagder: I ran the c200 bootloader throught the sansa emulator. It got far enough to show the lcd init and write sequences :) 23.08.09 # wow, that's cool 23.08.21 # I'm hoping the buttons are just gpio since there's no scroll/touch pad 23.08.45 # austriancoder: http://pastebin.com/d69a764b7 23.09.51 # austriancoder: here's some usb stuff m:robe bootloader (PP5020)...http://rafb.net/p/IicR3G61.html 23.10.39 # austriancoder: http://pastebin.com/d4e197967 23.12.00 # wow 23.12.03 # austriancoder: Just load up the SKU_E-PP5022.bin using the ARM processor type, then apply first IDC script and then the second IDC script 23.12.26 Quit Febs (Read error: 110 (Connection timed out)) 23.13.22 # webguest49: thanks very very much - you and low_light made my night 23.14.11 # austriancoder: when it is finished you can go down to the USB segment and see references (place the cursor on one address and use ctrl-x to list the X-refs) 23.14.41 # * austriancoder starts IDA 23.16.47 # webguest49: do I need to change something in the "dissasembly memory organisation" dialog? 23.17.03 # austriancoder: no, you can leave the defaults 23.17.32 Join sergey [0] (n=sergey@ppp85-141-132-143.pppoe.mtu-net.ru) 23.17.49 Join wippeout [0] (n=wippeout@unaffiliated/wippeout) 23.17.52 # hello 23.18.42 # The PP code looks like C++ to me. I've found that there are few direct references writing/reading from the hardware. There's a lot of structs & pointers that are hard follow. 23.19.32 # If you can run the sansa emulator it makes following the disassembly much easier 23.20.11 Join Terinjokes [0] (n=spader@wikinews/Terinjokes) 23.20.15 # longtime, no talk 23.20.26 # low_light: i'm fairly certain it is 23.20.37 # low_light: i dont get the emulator running on linux nor on windows :( 23.20.47 # webguest49: second idc runs 23.21.08 # saratoga: do you know why the waveformatext structure in rockbox decoder have 2 extra fields at the start and a fixed length of for the "data" member ? 23.22.33 # austriancoder: for example... here's the setup for the usb struct (offset value in the first column) http://rafb.net/p/BBq0OE60.html 23.23.37 # nerochiaro: the fixed length is because rockbox doens't use malloc 23.23.46 # austriancoder: the first value (0x11da8) is an offset to where you can get what I guess are "class functions" 23.23.48 # what are the two extra fields 23.24.02 # packet_size and audiostream, at the stat 23.24.04 # start 23.24.45 # gotta go...later 23.24.47 Part low_light 23.24.50 # low_light: see ya 23.26.20 # * austriancoder has now a good feeling in getting usb device part of stack working 23.26.28 # nerochiaro: not sure why those were added 23.26.38 # they don't seem to be used 23.26.50 # wma.c uses them 23.26.56 # at least audiostream 23.27.06 Quit ompaul ("reboot") 23.27.53 # saratoga: ah, to read asf packets 23.28.12 # saratoga: well, the decoder doesn't though, that's what i wanted to say 23.28.14 # saratoga: the wma decoder is pretty robust 23.28.26 # saratoga: it handles my file tons better than the vlc that comes bundled with ubuntu 23.28.32 # preglow: thanks 23.28.33 # skips like a bitch in vlc 23.28.38 # haha 23.28.44 # perhaps my file is corrupt or something 23.28.46 # does wma have crc fields? 23.28.55 # i think asf handles that 23.28.58 Part Terinjokes 23.29.03 # yeah, sounds logical 23.29.04 # we just ignore the fields label error correction 23.29.10 # hmm, somethings' fishy... my build splashes a different version number than what's in rockbox-info.txt... 23.29.42 Join XavierGr [0] (n=xavier@ppp152-243.adsl.forthnet.gr) 23.29.43 # webguest49: maybe it would be fine if we can exchange mail addresses or skype names ? 23.29.50 # rm -rf time :-) 23.31.30 Join ompaul [0] (n=ompaul@freenode/staff/gnewsense.ompaul) 23.32.08 Quit Domonoky ("Trillian (http://www.ceruleanstudios.com") 23.33.00 # oha.. need to fetch my girlfirnd in 8 minutes, but i need about 15 with car *g* 23.33.24 Quit desowin ("use linux") 23.34.21 # see ya all 23.34.28 # webguest49: thanks for your help 23.36.54 Nick austriancoder is now known as ac_away (n=austrian@rockbox/developer/austriancoder) 23.37.31 Quit sergey (Read error: 113 (No route to host)) 23.37.57 Join sergey [0] (n=sergey@ppp85-141-133-234.pppoe.mtu-net.ru) 23.38.32 # austriancoder: no problem :) 23.40.59 Join bdgraue [0] (n=bdgraue@host-091-096-224-107.ewe-ip-backbone.de) 23.41.07 Quit XavierGr_ (Read error: 110 (Connection timed out)) 23.41.27 Quit haemmy () 23.42.27 Join massinissa [0] (n=dnanar@mar06-1-88-167-174-249.fbx.proxad.net) 23.42.30 # hi all ! 23.43.25 Quit krazykit (Remote closed the connection) 23.43.31 Join SliMM [0] (n=chatzill@89.137.226.12) 23.43.59 # does anyone here who use a 4g (photo) ipod with rockbox may tell me how long is the battery life please ? on rockbox website it says "~8h/12h" for ipod video (5g/5.5g), but for color ? the same please ? 23.44.34 # try it :) 23.45.01 # yes but i didn't buy it for the moment 23.45.02 Quit jgarvey ("Leaving") 23.45.21 # gah, this voice buisness is driving me crazy... 23.45.35 # and i'm hesitating between 4g/5.5g ipod, saying that 4g is 200€ and 5.5g 260€ :s 23.45.40 # expect less than the OF. that might chage some time though 23.45.59 # the OF ? what is this please ? 23.46.03 # what capacity are they? 23.46.10 Quit webguest49 ("CGI:IRC") 23.46.11 # OriginalFirmware 23.46.15 # OF = original firmware 23.46.16 # 60 for 4g and 80 5.5g 23.46.24 # ah ok for OF 23.46.27 # * n1s slow 23.46.27 # then i would choose the 5.5G 23.46.34 # yes i did understood that for OF 23.46.57 Quit nerochiaro (Read error: 104 (Connection reset by peer)) 23.46.58 Join nerochia1o [0] (n=nerochia@adsl203-164-174.mclink.it) 23.47.39 # snif rockbox for ipod nano :( 23.47.45 # 1.3.1 grrrrrrrr :'( 23.47.47 # saratoga: i noticed that the in the decode_frame routine the code to "convert frame to integer" is different 23.47.51 Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) 23.48.02 # DerPapst: well in fact me too i would did the same thing, but : http://www.newertech.com/products/ipod4g_batt.php sounds to imrpove 114% for 4g battery life. it does not exist for 5.5g. and i don't need of a "wide" screen, and 60/80 is the same for me. do you think that this trick would work ? 23.48.16 # Ishi - mmm ? 23.48.47 # unstable rockbox for ipod nano for : 25/07/07 ( because : apple firmware 1.3.1 ) :( 23.48.59 # curious 23.49.05 # :/ 23.49.13 # i'am waiting :( 23.49.15 # massinissa i would say the better battery of the the 4G is compareable then the the 5.5G with the stock battery 23.49.20 # nerochia1o: we just removed that this week 23.49.37 # saratoga: ah, ok, i'm arriving there anyway 23.49.46 # rockbox doesn't need the sames scaled to int32, so we don't bother doing that anymore 23.49.52 # Ishi - I've been a bit out of touch recently - has anyone reported it to one of the devs? 23.49.59 # maybe it's been discussed already 23.50.11 # stripwax: yeah its a known issue 23.50.12 # oh it has 23.50.15 # stripwax: it's a known issue 23.50.24 # doesn't happen to most people though, so its not clear how to fix it at the moment 23.50.34 # has been decussed today too. 23.50.40 # DerPapst: Ah ok. thanks for the tips 23.50.41 Part midgey 23.50.43 # *discussed 23.51.01 # * stripwax just found the forum 23.51.13 # Ishi - please post your help here: http://forums.rockbox.org/index.php?topic=11504.75 23.51.34 # after downgrading to something prior to 1.3.1 of course 23.51.39 # Ishi``: when you can compile set the maximum clockrate back to 75MHz and then it sould work again 23.52.03 # prior 1.3 in fact according to that 23.52.16 # ok 23.52.24 # i do'nt think its the clock speed 23.52.33 # at least i remember someone saying that didn't help 23.52.41 # hmmmm... 23.52.48 Join n00b [0] (i=c00c4efa@gateway/web/cgi-irc/labb.contactor.se/x-3c3ecae762bd5baf) 23.53.32 # hi again. is there a way to boot the original (non-rockbox) firmware for the iriver h340....is there some key sequence on boot or some menu item to toggle? 23.53.58 # press rec while booting 23.54.00 # how downgrade firmware 23.54.01 # ? 23.54.20 # can you run an old apple updater 23.54.20 # you need a firmware image of the 1.2 firmware 23.54.35 # inclusing all 3 images and the "Flash me" bit set 23.54.45 # udapte apple not function 23.54.51 Quit davina ("xchat on Ubuntu 7.04") 23.55.00 # stripwax: it will refuse to restore the ipod because the frimware is newer 23.55.35 # APPLE udapte and blocked by itunes 23.55.37 # not possible :( 23.55.39 # but you can extract this firmware image form such an appe updater and use ipodpatcher to intall it 23.55.47 # DerPapst - wow, that's sucky. 23.56.25 # with ipodwizard or resource hacker on windows. 23.56.32 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 23.56.33 Quit sergey (Read error: 113 (No route to host)) 23.56.46 # morning JdGordon ;) 23.56.57 *** Saving seen data "./dancer.seen" 23.57.02 Join sergey [0] (n=sergey@ppp85-141-135-196.pppoe.mtu-net.ru) 23.57.09 # stripwax: yepp.. but at least there is a way arround that ;) 23.57.22 # hey DerPapst 23.57.37 # thanks 23.57.39 Quit n00b (Client Quit)