--- Log for 15.10.107 Server: calvino.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 13 days and 18 hours ago 00.00.27 Quit ompaul (Client Quit) 00.00.31 Quit petur ("Zzzz") 00.04.30 # Just to make sure I'm doing this right: I've done "svn revert -R ." then I updated my SVN, then added 7331, and then 5241. Then I removed my "build" directory. I'm about to "make" a new Build. Is this correct? 00.04.38 # Or should I do "make clean" ? 00.05.27 # run "make clean" first. 00.05.45 # Will that begin the build process? 00.07.18 # Doesn't appear so. 00.07.18 Join kugel|afk [0] (i=kugel@unaffiliated/kugel) 00.07.31 # no, it will just remove old intermediate files 00.08.01 # Mouser_X: I had a problem with the mod patch and just doing an svn revert because of the new files which were added - those couldn't be reversed, svn doesn't know about them 00.08.29 # SVN compiled just fine with Rockbox + 5241 00.08.43 Quit BigBambi_ ("Please insert girder") 00.09.01 # It also compiled just fine with Rockbox + 7331. However, when I did Rockbox + 7331 + 5241, I got problems. 00.09.19 # ok, just wanted to share my experience :) 00.09.55 Quit kugel (Nick collision from services.) 00.10.03 Nick kugel|afk is now known as kugel (i=kugel@unaffiliated/kugel) 00.10.06 # (I've been doing all kinds of builds for the last 2-3 days. So far, the only one that doesn't compile is when I do *both* 7331 and 5241.) 00.11.34 # (Just to clarify: I've been using 7331, 5241, and 2911. However, 2911 would just be "icing on the cake." While nice, I would be just as happy without it, as I would be with it.) 00.12.26 Quit Rob2222 (Read error: 104 (Connection reset by peer)) 00.14.01 Quit ptw419 (Read error: 110 (Connection timed out)) 00.14.18 Join linuxstb_ [0] (n=linuxstb@rockbox/developer/linuxstb) 00.15.16 Quit Robin0800 (" Try HydraIRC -> http://www.hydrairc.com <-") 00.15.31 Quit linuxstb (Nick collision from services.) 00.15.33 Nick linuxstb_ is now known as linuxstb (n=linuxstb@rockbox/developer/linuxstb) 00.18.52 Quit hannesd ("Client suicide") 00.19.39 Quit Llorean (Read error: 110 (Connection timed out)) 00.21.23 Quit bertrik ("bye") 00.21.32 # uhm 00.21.44 Join Llorean [0] (n=llorean@cpe-70-113-103-34.austin.res.rr.com) 00.22.04 # is rockbox supposed to support utf8 characters in tag info, with ogg (or flac) 00.22.20 # my characters are being displayed badly 00.22.26 # not file names 00.22.37 # also 00.22.56 # ashes: are you using a font that has the characters in question? 00.23.04 # vorbis comments are always utf-8. 00.23.14 # would i get better performance if i compile rockbox myself specifically for my cpu model? 00.23.20 # bluebrother: maybe not 00.23.33 # ashes: it _is_ compiled for your cpu 00.23.33 # Rockbox _is_ build for the specific cpu. 00.23.37 Quit iamben (Read error: 104 (Connection reset by peer)) 00.24.04 # and you might want to try unifont. It's the most complete font in terms of characters present afaik. 00.24.14 Quit Zagor ("Client exiting") 00.24.55 # well, it's technically not compiled for the correct coldfire model but gcc doesn't support the one we have before 4.3 00.24.58 # If the tags are being displayed poorly, but not the filenames, and they contain the same text, isn't that usually a codepage issue? 00.25.30 # my theme font is utf8, i changed it to something else which isn't utf8. it's okay now 00.26.19 Join linuxstb_ [0] (n=linuxstb@rockbox/developer/linuxstb) 00.26.21 Quit linuxstb (Nick collision from services.) 00.26.25 Nick linuxstb_ is now known as linuxstb (n=linuxstb@rockbox/developer/linuxstb) 00.26.27 # building a snapshot version of rockbox with a snapshot version of gcc probably isn't a great idea 00.27.46 # Llorean: yes, usually. But AFAIK vorbis comments are always utf-8 per definition. 00.28.09 # it's an issue with id3 tags as those don't hold information about the used codepage 00.28.15 # Aaah 00.28.50 Join iamben [0] (n=ben@dpc67142179038.direcpc.com) 00.29.22 Join Rob2222 [0] (n=Miranda@p54B15D8F.dip.t-dialin.net) 00.29.29 Quit barrywardell_ () 00.30.28 # ID3 does but only since version 2.4 00.30.52 # (IIRC) 00.30.58 # What was it about 2.4 that tends to cause people to prefer 2.3? 00.31.43 # I think it's just less widely supported 00.32.30 # Interesting... HD66773R and HD66789R have a very similar command set, but there are some details where they behave different 00.32.55 # E.g. on HD66789R, setting the update window resets the address pointer. On HD66773R it does not. 00.33.27 # bluebrother: Should I paste the entire log to pastebin, or just the "interesting" stuff? 00.33.39 # ah, id3v2 also allows utf-16, even earlier than 2.4 00.33.52 # (Specifically, though I doubt it, there might be some stuff that I didn't think was important that I might leave out.) 00.34.15 # Mouser_X: if you're sure you know what's the relevant parts you can trim it down. Otherwise just use the complete output 00.35.05 # http://www.pastebin.ca/736907 00.35.06 Join karashata [0] (n=Kimi@pool1-169.adsl.user.start.ca) 00.35.21 Quit Rob2222 (Read error: 104 (Connection reset by peer)) 00.35.30 Join webguest23 [0] (i=4a469ecd@gateway/web/cgi-irc/labb.contactor.se/x-61aba3aca2751bcf) 00.35.44 # n1s: ^ If you can, that might be useful to you (if you're willing to help of course) 00.36.19 # (I patched in 7331 followed by 5241, otherwise there would have been more stuff there.) 00.37.05 # I'm building for the Gigabeat, if that's of importance. 00.37.27 # i installed rockbox on my sansa e200r with the e200rsansapatcher but i tried to update it. After it was done updating, i tried to install it back on. When the writing on the screen comes up, it say "unknown bootloader" then i have to shut it down. Anyone know what this means? 00.37.51 # when i updates the sansa, rockbox didn't boot 00.37.56 # Mouser_X: same error that I got, take a look at the metadata/mod.c file - mine was 3 times as long as it should be, because after the svn revert without the file being removed every try to patch added the file "inside" the one that was still there again 00.38.05 Join BHSPitLappy [0] (n=steve-o@unaffiliated/bhspitmonkey) 00.38.08 # webguest23: that your bootloader isn't supported 00.38.20 # what does that mean 00.38.39 # that e200rpatcher doesn't know how to patch it 00.38.58 # do i have to find another bootloader 00.39.06 # pixelma: Hmmm. Possible. Though I know it *does* compile just fine. I guess I could delete my SVN and checkout again. 00.39.18 # I would suggest using an earlier version of the firmware 00.39.23 # okay 00.40.02 # Mouser_X: What she said means "the patch may compile just fine, but what you've done combined with how the patch is made could cause this error by having applied, removed, then re-applied the patch" 00.40.08 # Mouser_X: no need to check out again just revert and delete any files added by the patches 00.40.15 # Mouser_X: you could just rm mod.c 00.40.27 Join Rob2222 [0] (n=Miranda@p54B15D8F.dip.t-dialin.net) 00.40.38 # ah, no, I just overlooked sth 00.41.27 # Where would I find "mod.c" to remove it? 00.41.46 # apps/metadata/mod.c 00.41.54 # * bluebrother is too slow 00.42.05 # There are 2 different mod.c 00.42.39 # amiconn: did you ever find out what license that modplayer is under? 00.42.43 # yes - probably the other one in apps/codecs is affected too 00.43.38 # n1s: No. *someone* should drop 'myth' a mail... 00.44.30 # well apparently that tumu person is working on porting dumb so I guess we can see how that turns out... 00.44.33 # do you know where i can download earlier firmware for my e200r 00.45.51 # amiconn: which is more imporant on SH? icode or idata? 00.46.23 # Depends on what the code does. What do you want to do? 00.46.54 # keep iram use to only what's nescessary. I don't think switch_thread need to be icode for anything. 00.47.13 # I'd think so too 00.47.51 # There isn't much iram, and switch_thread() does neither contain excessive loops, nor is it called extremely often 00.48.04 Quit Mouser_X (Read error: 104 (Connection reset by peer)) 00.48.43 # the thread data gets far more use than the code in general 00.48.44 # On SH1, dram is as fast as iram for data _within a fast page access sequence_, i.e. no wait state 00.48.58 # Opening the page costs 2 cycles 00.49.28 # Putting code in iram helps to avoid contention of instruction fetches with external memory accesses, _if coded carefully_ 00.49.39 Join Mouser_X [0] (n=Mouser_X@67.110.120.36.ptr.us.xo.net) 00.50.00 # Sorry, my laptop locked up. 00.50.14 # so having data in iram and code in ram should help avoid contention? 00.50.30 # It's not that simple 00.50.57 # SH instructions are 16 bit. DRAM is 16 bit too, IRAM is 32 bit 00.51.13 # When code is running from IRAM, the SH fetches them in pairs 00.51.28 # aha 00.52.12 # That means if you put memory access instruction in the correct slot, the memory access doesn't contend with instruction fetch, no matter whether the data is in iram or dram 00.53.07 # If either code or data is in iram and the other in dram, it is slower than having both in iram, but not much, as the cpu can make efficient use of fast page mode 00.53.39 # Both code and data in dram still hass that advantage, as long as the data is located close enough (within the same page) 00.53.39 Quit webguest23 ("CGI:IRC (EOF)") 00.54.13 # If they're further apart, that's the worst situation, as each and every fetch (code and data) switches pages 00.54.55 Quit obo ("bye") 00.55.02 # I should get the datasheet out here but what's the page size then? 00.55.22 Quit Nico_P (Remote closed the connection) 00.56.11 # so keeping blocking functions that call switch_thread near switch_thread itself could help 00.56.29 # http://www.linuxfromscratch.org/~robert/new/m68k-compiler.txt in case any of you want 00.56.35 # 1KB iirc 00.56.50 # That's a ram feature, not cpu 00.56.56 # (fast page mode) 00.58.10 Quit ender` (" I think computer viruses should count as life. I think it says something about human nature that the only form of life we ha) 00.58.37 # ashes: why not install the cross compiler to /usr/local? That will get rid of possible conflicts with the host cc 00.59.50 # lfs doesn't install anything to /usr/local, and i've fixed any conflicts. installing libiberty.a to /usr/local/lib isn't a good idea either 01.00.11 # it's up to you 01.00.47 # sure. But I also don't use LFS ;-) 01.00.59 # anyway, time for sleep for now. 01.01.10 # that hint should work with any linux 01.01.44 # or bsd 01.01.46 # of course. 01.01.57 Quit bluebrother ("sleep!") 01.03.09 # ashes: Is there some great flaw in the instructions and methods on our site for setting up a rockbox dev environment? 01.03.13 # gcc is playing size tricks on /me again...this time with SH and there's hardly any additional code for that 01.03.41 Join webguest68 [0] (i=4a469ecd@gateway/web/cgi-irc/labb.contactor.se/x-503609b54022d2b6) 01.03.45 # Llorean: i found it overly complicated 01.03.59 # "Run rockboxdev.sh and add the appropriate line to your path"? 01.04.14 # Llorean: maybe we're not talking about the same wiki/doc 01.04.42 # if i deleted my bootloader on my e200r, how do i get it back? 01.04.47 # Very possibly. 01.05.08 # ashes: http://www.rockbox.org/twiki/bin/view/Main/CrossCompiler ? 01.05.52 # it has much more information than i need 01.06.13 # Did you see the "automatic build" section of it? 01.06.42 Quit mirak (Remote closed the connection) 01.06.57 # except for that 01.07.00 # i was testing out some themes on my e260 and the latest one i've selected doesn' 01.07.01 # :-) 01.07.10 # doesn't show text in the menus 01.07.19 # how do i reset the theme when i can't see what i'm doing? 01.07.21 # webguest68: Which bootloader? What exactly did you do? 01.07.46 # ashes: Not only that, but following our processes insures you're using both the right versions of binutils and gcc, and have installed any necessary patches so that compiling doesn't fail 01.08.24 # We don't really accept bug-reports on versions of Rockbox not compiled with the expected environment, because of how picky some of these processors can be (and how strangely buggy gcc has shown itself to be cross-compiling in some cases) 01.08.35 # well, i deleted the file OF.mi4 01.08.42 # that was in the system menu 01.09.08 # superkaybee: Connect to your computer and delete config.cfg in the .rockbox folder 01.09.20 # Llorean: thanks! 01.09.37 # That's the Sansa original firmware. You'll need to enter recovery mode and reinstall the Sansa firmware to get USB mode again, then install Rockbox again. 01.10.07 Join JdGordon [0] (n=jonno@c210-49-113-143.smelb1.vic.optusnet.com.au) 01.10.33 # my computer doesn't detect it in recovery mode 01.10.51 *** Saving seen data "./dancer.seen" 01.17.08 Quit n1s () 01.19.45 # hmm. 01.20.19 # amiconn: according to the instruction reference, loading memory byte=>register or storing reg=>memory byte should be efficient on SH, right? 01.20.43 # If you want sign extension, then yes 01.21.32 # linuxstb: hey, still around? 01.21.46 # hmmm...it doesn't really matter if it is extended or not. I only care about bits 0-7 anyway. 01.21.50 # On H300 and X5 it might in fact pay off to write the data in lcd_write_yuv420_lines() into an IRAM buffer instead of the LCD controller, and then set up a DMA transfer and calculate the next line pair in the background... 01.22.19 # oh, so you will try that trick :) 01.22.48 # Drawback is that it needs 2 additional buffers in iram, each sized 2*LCD_WIDTH 01.22.49 # JdGordon: Just about 01.23.17 # do i use bootloader/bootloader.bin with sansapatcher to update the ppbl? or something else? 01.23.20 # That is 880 iram bytes on H300, and still 640 bytes on X5 01.23.23 # that's my misgiving about it too 01.23.52 # unless bursts are used then it's not much slower 01.23.54 # JdGordon: According to barrywardell's commit message, it needs a raw binary, so yes, bootloader/bootloader.bin should be it. 01.24.44 Quit Toxicity999 (Read error: 104 (Connection reset by peer)) 01.24.46 # The intermediate Y, Cb and Cr buffers are already on stack, that's 660 bytes (H300) resp. 480 bytes (X5) 01.25.21 # Putting the extra buffers on stack too might overflow the stack... 01.26.36 # Erm, and the 2 additional buffers on X5 would be 1280 bytes, not 640 (32 bits per pixel in order to use dma) 01.28.34 Quit Thundercloud (Remote closed the connection) 01.28.45 # * jhMikeS curses freescale for no data cache on cf 01.28.48 # * amiconn wonders whether an intermediate iram buffer + dma would even speed up lcd_update() on X5 01.29.58 Quit webguest68 ("CGI:IRC (EOF)") 01.30.05 Quit animeloe ("This computer has gone to sleep") 01.30.06 # well this sucks... 01.30.07 # It's just having the LCD controller waitstates handled asynchronously (by the dma controller) instead of synchronously 01.30.20 # my sansa wont connect to usb, so i cant tst this out :( 01.30.23 Quit BHSPitLappy (Read error: 110 (Connection timed out)) 01.31.31 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 01.32.07 Quit jhulst ("Konversation terminated!") 01.34.15 # thanks for all the help getting me started today -- things are working great 01.36.15 Quit lee-qid ("aufwiederbyebientotsayonara") 01.38.48 Quit spiorf (Remote closed the connection) 01.39.16 Quit moos ("Time to sleep a bit !") 01.39.50 Join Toxicity999 [0] (n=bryan@unaffiliated/Toxicity999) 01.42.41 # jhMikeS: Oh, plus letting the dma controller do the longword split (on X5) 01.44.03 # longword split? 01.44.32 # splits into 2x16-bits? 01.46.13 # yes 01.46.21 Quit bb (Nick collision from services.) 01.46.28 Join bb_ [0] (n=bb@unaffiliated/bb) 01.48.07 # how do i access sleep timer? 01.48.39 # the manual should say if it is supported by your device 01.49.11 # i know it is, but how do i access it? 01.49.32 # what does the manual say? 01.50.53 Join Logomachist [0] (n=Rob@24.115.80.11.res-cmts.eph.ptd.net) 01.50.58 # Hi 01.51.13 # scorche: the sleep timer is there on non rtc targets too 01.51.20 # found it. 01.51.52 # Q: What's the best video player that's Rockbox compatible? 01.52.11 # Logomachist: Do you mean "What's the best Rockbox target for playing video?" 01.54.45 Join bb [0] (n=bb@unaffiliated/bb) 01.54.46 Part pixelma 01.54.54 # Sort of... let me rephrase... 01.55.42 Join Asteriskk_ [0] (n=herb@adsl-75-42-72-190.dsl.scrm01.sbcglobal.net) 01.55.49 # What video player best supports Rockbox? If there are multiple video players that are all equally compatible with Rockbox, is there one that clearly gives you the best value, taking into account things like battery life and price? 01.56.08 # gigabeat? 01.56.08 # Rockbox runs on music players 01.56.34 # can somebody send me the lame3.97 source code? I can't seem to get sourceforge to respond and I need it for cygwin 01.56.37 # Logomachist: rockbox doesnt run on any "video players"...it runs on digital audio players, which can play video with rockbox 01.56.39 # Most of the devices weren't designed for video, and have it as a more or less "added feature" to the music playback 01.56.49 # Logomachist: As for which player runs video best in Rockbox, it's the Gigabeat. 01.57.22 # I'm confused. Rockbox plays video on devices that aren't made to play video, but on devices that do play video, it doesn't work? 01.57.24 # Video is hardly an addon to a 300 or 500MHz chip (when the latter is ready) 01.57.48 # Logomachist: There are no devices that Rockbox runs on that were designed as "video players" 01.58.01 # With the possible exception of the iPod Video, which is an odd case. 01.58.08 Join webguest72 [0] (i=4a469ecd@gateway/web/cgi-irc/labb.contactor.se/x-164332463b60ea9e) 01.58.24 # if you want video whynot get one of those little portable dvd players? 01.58.30 # But if you want to watch video on Rockbox, hands down your best choice is the Gigabeat. 01.58.47 # Indeed. 01.58.49 # when i am in recovery mode with the usb plugged in, it son't connect to the computer. Why is it doing this. 01.59.12 # At anywhere from US $90 to $130 depending on luck and persistence for a 40gb device, and a 320x240 screen that's quite nice, and a fast enough processor to run fullscreen at 30fps, it's a no brainer. 01.59.41 # rockbox is booting but the original firmware is not. I'm using a sansa e200r 01.59.48 # I want the ability to watch video, but I don't want to buy a seperate video player, and I don't want dvd player because it would not be convinient at the gym.. 01.59.57 # ah 02.00.25 # Logomachist: Rockbox can play MPEG-1 and MPEG-2 vidoes. 02.00.28 # *videos 02.00.48 # Logomachist: Well, there's really only one choice with Rockbox. Well, two if you count the Gigabeat F and Gigabeat X as separate players, but they're more or less separate looks for the same player. 02.00.58 # In other words, buy a Gigabeat, and convert your videos to MPEG-2, and play them in Rockbox. 02.01.21 # webguest72, did you add OF.mi4 when doing the step 02.01.24 # to add to that, you can use virtualdub to do that 02.01.37 # incase you didnt know 02.02.03 # I watched video on a Archos 605 today, looked pretty good 02.02.05 # Maybe I will. 02.02.12 # yes 02.02.18 # Is there anything like Rockbox designed for video players? 02.02.18 # markun: back home yet? 02.02.26 # Check out MpegPlayerPlugin in the Wiki (I think that's the name.) 02.02.29 # scorche: yes, arrived today 02.02.38 # It will tell you how to convert videos for use in Rockbox. 02.02.41 # Mouser_X: PluginMpegplayer 02.02.42 # Mouser_X: PluginMpegplayer 02.02.49 # Mouser_X: All plugin pages start with Plugin, or should 02.02.51 # if i could get into recovery mode thn i could fix it but i don't know how to get it to connect 02.02.56 # Sorry. 02.03.24 # scorche: I should go to sleep now to get back into a normal rithm.. 02.03.41 # Logomachist, no, not really. 02.03.43 # markun: good luck with that...let me know when you get the pictures up ;) 02.03.54 # ...not like many were taken, but meh 02.04.12 # scorche: I don't have the pictures with the 3 of us 02.04.20 # was karl's camera used for that? 02.04.23 # Logomachist: If you're wondering if there's any devices that *natively* support video playback, and run Rockbox, then your only option is the iPod video. 02.04.24 # oh...was that karl? 02.05.13 # I hope so 02.05.34 # Logomachist: However, I would strongly suggest that you look at the Gigabeat first. It's a great player, and video works great on it as well. 02.05.45 # Yeah... If Gigabeat plays video better than the iPod running Rockbox, there's no reason for me to prefer the iPod. 02.06.10 # `it says that the usb cable is onnected on the screen but i still get no results on the computer 02.06.27 # * amiconn wonders why we don't use buffered writes by default 02.06.39 # But is the Gigabeat really going to compare, in its video playback, with a device designed from the ground up to play video? For example, the Zune? 02.07.02 # Logomachist: depends how you want to compare them 02.07.05 Quit bb_ (Read error: 110 (Connection timed out)) 02.07.06 # Logomachist: Rockbox doesn't run on the Zune anyway 02.07.12 # The Zune uses hardware that is very similar to the Gigabeat S (though, the Gigabeat S doesn't yet run Rockkbox). 02.07.18 # webguest72, you do not see 16m-format in my computer 02.07.29 # no 02.07.40 # Logomachist, there are other things to consider, of course. The Zune is crippled to Windows, Rockbox players are not, among other things. 02.08.11 # I just used the Zune as an example, I wasn't seriously considering getting it. 02.08.43 # Logomachist: The only real advantages other players might have, is that if some of them have fast enough processors, filesizes at a given quality may be a little bit smaller. 02.08.44 # Logomachist: The Gigabeat F (which runs Rockbox, and Rockbox can play videos) has a 300 mhz CPU. The Gigabeat S (which has nearly identical hardware to the Zune, if I'm told correctly) has a 533 mhz CPU. 02.09.17 # do i have to install a certain driver 02.09.33 # There's a port for the Gigabeat S in the making, but it hasn't gotten very far yet. 02.09.34 # Mouser_X: I also believe the i.mx31 has some logic used for video playback (maybe decoding or just scaling, I don't know) 02.09.42 # any chance of getting rockbox to play audible.com content? 02.09.54 # Asteriskk_: No. It's DRM restricted. 02.11.07 Quit bb (Nick collision from services.) 02.11.14 Join bb_ [0] (n=bb@unaffiliated/bb) 02.11.15 # whoa 02.11.35 # amiconn: what's not using buffered writes? 02.11.46 # Coldfire (except for dram) 02.12.23 # I enabled buffered writes as default in crt0.S and system-target.h, testing on H300 - and guess what? 02.12.35 # it's drm restricted but they have players that will work with their content listed on their site 02.12.37 # 38% speedup in lcd_yuv_blit() when boosted! 02.12.44 # wow 02.12.45 # not bad :) 02.13.11 # I'll test this for a few days, whether something unusual happens 02.14.07 # I might have to recalibrate the remote lcd timing, as it may become too fast with buffered writes 02.14.14 # Perhaps some other timings too 02.14.22 # what's the mod? 02.14.41 # Logomachist: I am not the one to ask (since I've never used the Zune), but I would think that the Zune would have the advantage in 2 areas, over the Gigabeat. The Zune has a larger screen (I think. I don't know this), and a faster CPU. Because it has a faster CPU, the Zune might support seeking while watching a video (something that Rockbox can't do. There's not enough extra CPU available to watch the video, and fast forward/rewind). 02.14.59 # firmware/target/coldfire/crt0.S, line 222: change 0x80000000 to 0x80000100 02.15.08 # webguest72, there is no drivers needed for recovery mode 02.15.22 Quit Toxicity999 (Read error: 113 (No route to host)) 02.15.24 # Same in firmware/target/coldfire/system-target.h, line 158 02.15.45 # (the value loaded into %cacr in the next instruction) 02.16.01 # webguest72, what operating system are you running 02.16.11 # don't laugh 02.16.13 # ME 02.16.21 # * Asteriskk_ laffs 02.16.24 # sorry can't help it 02.16.39 # Yea, X5 needs a few more LCD waitstates when boosted 02.16.40 # j/k;-) 02.16.48 # i was kind of expecting it 02.17.16 # But that has to wait... bed time 02.17.28 # Blast! Thus far, it appears that pixlma was right. My MOD.c file was corrupted (I'm compiling Rockbox + 7331 + 5241, and it's gotten past the point that normally causes problems) 02.17.39 # webguest72, i do not know if ME has the drivers to see recovery mode 02.18.09 # Oh, but is there any way i can find those drivers 02.18.20 # upgrade;-) 02.18.30 Join bb [0] (n=bb@unaffiliated/bb) 02.18.44 # any other way... 02.19.05 # what player is it again? 02.19.10 # Looks like the coldfire video capabilities will improve soon :) 02.19.22 # sansa 02.19.22 # Asteriskk_, e200 IIRC 02.19.33 # have you looked on the sansa site itself? 02.19.37 # I think it's the "r: 02.19.41 # they have legacy drivers tehre 02.19.47 # there* 02.19.54 # i'll check it out now 02.21.34 # * keanu confused... 02.21.47 # does calendar on the e200 data abort for anyone else? 02.22.03 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 02.22.38 # amiconn: It even helps the SPC codec a bit even though it's mostly IRAM there 02.22.38 Join Toxicity999 [0] (n=bryan@unaffiliated/Toxicity999) 02.23.31 # jhMikeS: Nice! 02.23.36 # * Mouser_X likes SPCs. 02.23.55 Join bb__ [0] (n=bb@dslb-088-074-150-137.pools.arcor-ip.net) 02.24.14 Quit webguest72 ("CGI:IRC (EOF)") 02.24.18 # not too much since cf is already fast as hell with all the emac DSP stuff in there (1%-2% boost reduction) 02.24.44 # jhMikeS: Well, that's probably due to the offload in other parts of rockbox 02.25.31 # Buffered writes don't apply to iram, as it's internal. For sdram, buffered writes were already enable (via %acr0) 02.26.08 # But all the register writes (MBAR +MBAR2 area), as well as lcd, were not 02.26.45 # But now, really sleep 02.27.41 # cya amiconn 02.29.14 Quit Rob2222 (Read error: 110 (Connection timed out)) 02.29.48 Quit bb_ (Read error: 110 (Connection timed out)) 02.30.33 Join NIHIL [0] (n=NIHIL@75.117.132.204) 02.30.41 # I need some help 02.31.03 # I think I bricked my Gigabeat f40 when I reinstalled rockbox 02.31.20 # when I reinstalled it I got codec failure 02.31.37 # plug in usb, then turn it on. you can install a different build like that 02.31.43 # So I deleted the extra rockbox.gigabeat file in my root 02.31.45 Quit jhMikeS (Nick collision from services.) 02.31.48 Join Rob2222 [0] (n=Miranda@p54B16798.dip.t-dialin.net) 02.31.51 Join jhMikeS [0] (n=jethead7@rockbox/developer/jhMikeS) 02.31.52 # now I get rockbox error: -2 02.32.28 # I tried using the usb, but it doesnt contact the pc 02.32.53 # in bootloader usb mode? 02.33.07 Quit superkaybee () 02.34.00 # if you can't access the gigabeat via Rockbox or the bootloader USB mode, you'll have to go through the recovery procedure: http://www.rockbox.org/twiki/bin/view/Main/GigabeatFXPort#Gigabeat_Recovery_Procedures 02.34.26 # wait I got it via bootloader 02.34.52 # great might be system errors 02.34.52 Quit ramon8 (Read error: 104 (Connection reset by peer)) 02.34.55 # thanks anyway 02.34.58 # the fact that you had rockbox.gigabeat in the root of your drive suggests that your bootloader is out of date too, nihil 02.34.59 # Guys, I'm looking up portable video players... do you know anything about the Archos 705? 02.35.07 # ok 02.35.13 # I'll reinstall then 02.35.13 # Logomachist, please stay on topic 02.35.23 # Logomachist: this is #rockbox...a channel for discussion...rockbox 02.35.25 # Sorry. 02.35.35 # s/ion/ing 02.36.25 Quit bb (Connection timed out) 02.36.28 # what is rockbox error: -2? 02.39.05 # means there's a problem with the checksum. try updating the bootloader with the one in the wiki (from april) and install the latest build of rockbox while you're at it 02.39.14 # ok 02.40.11 Quit Logomachist ("ChatZilla 0.9.61 [Mozilla rv:1.7.12/20050915]") 02.45.56 Join animeloe [0] (n=animeloe@unaffiliated/animeloe) 02.56.28 Quit kfazz ("Leaving") 03.06.07 Quit Asteriskk_ ("I ran out of quit messages.") 03.10.53 *** Saving seen data "./dancer.seen" 03.11.00 Join Davide-NYC [0] (n=chatzill@user-12hdtj8.cable.mindspring.com) 03.16.35 Join psycho_maniac [0] (i=psycho_m@ppp156.hk.centurytel.net) 03.25.52 Join Aevum [0] (i=Aevum@108.42.217.87.dynamic.jazztel.es) 03.26.27 # hello 03.27.23 # just wanted to know if since the toshiba players and the kenwood players share plataform, could i use to toshiba rockbox build on a kenwood HD20GA7 03.27.28 # thank you in advnace 03.27.49 # Aevum: I'd recommend against just trying it 03.28.07 # Aevum: I'm no export on those targets though, perhaps someone else can give a better answer 03.28.40 # i do understand that using a firmware that isnt costum for that player can lean to bricking, thats why im asking first 03.29.22 # Aevum: I'm just saying :) 03.29.49 # i know, and sorry if my response has been hostile, you're just reminding me not to do stuff that might brick my player 03.30.32 # Aevum: I have experience in bricking players :) 03.32.21 Quit Toxicity999 (Remote closed the connection) 03.33.51 # Aevum: Unless all the hardware is exactly identical, it will need at least some modification to work. 03.34.00 Quit NIHIL (""Help! I've been g:lined from my mIRC!!" Bersirc 2.2: less n00bs [ http://www.bersirc.org/ - Open Source IRC ]") 03.34.01 Quit miepchen^schlaf ("Verlassend") 03.34.23 # the hardware isnt identical, thats why the toshiba sounds ok and the kenwood sounds like it does 03.34.42 # if the hardware was identical and it was a rebadge, i wouldnt ask 03.35.42 # im also thinking about replacing the hardrive, but thats not rockbox related 03.36.00 # need to know if its 5mm or 9mm toshiba first 03.36.02 Join Toxicity999 [0] (n=bryan@unaffiliated/Toxicity999) 03.36.07 Join webguest62 [0] (i=456afa47@gateway/web/cgi-irc/labb.contactor.se/x-1704fc098e213045) 03.43.33 Join ToHellWithGA [0] (n=ryan@d8-18.rb2.clm.centurytel.net) 03.47.30 # is there objective tests somewhere showing the Kenwood is a more accurate audio reproducer? 03.48.13 # perhaps the mp3 codec in the OF just sucks? :) 03.48.16 # * scorche pushes Soap off to somewhere else like #anythingbutipod, where those people are... 03.48.19 # You know what? I take that question back. That question and the response are not Rockbox related. 03.54.27 # I'm writing a paper for my college Operating Systems class on Rockbox. I've found a lot of great resources on rockbox.org, but there's a nice architecture summary on Wikipedia I want to use that I can't find on Rockbox.org. It's here: http://en.wikipedia.org/wiki/Rockbox#Architecture. Would you say it is an acurate summary? 04.03.46 Quit kugel ("ChatZilla 0.9.78.1 [Firefox 2.0.0.7/2007091417]") 04.08.49 Join Brian10161 [0] (n=blah@CPE004005521e1d-CM0014e8869324.cpe.net.cable.rogers.com) 04.09.54 # grettings comrads 04.10.05 Quit TNTales ("—I-n-v-i-s-i-o-n— 2.0 Build 3515") 04.13.46 Quit Brian10161 (Client Quit) 04.15.12 Quit ashes (Remote closed the connection) 04.15.17 Join ashes [0] (n=ashes@2001:5c0:8fff:ffff:0:0:0:4d) 04.17.20 Join Rob222241 [0] (n=Miranda@p54B15726.dip.t-dialin.net) 04.18.26 Quit Davide-NYC ("ChatZilla 0.9.78.1 [Firefox 2.0.0.7/2007091417]") 04.19.01 Quit Rob2222 (Read error: 110 (Connection timed out)) 04.23.29 Quit Soap () 04.44.05 Join JdGordon|uni [0] (i=82c20d6a@gateway/web/cgi-irc/labb.contactor.se/x-bd3aa0ba7c2fec05) 04.44.20 # anyone with a sansa or ipod around? 04.44.46 # keanu: fell like testing a patch quickly? 04.45.00 # JdGordon|uni: nano work? 04.45.04 # JdGordon: what sort of patch? 04.45.14 # nano should work 04.45.21 # 7952 and 7956 04.45.26 # ui fixes 04.45.39 # i forgot my microsd adaptor so i cant test till i get home :( 04.46.14 # microSD adaptor on a sansa? 04.46.35 # http://jonno.jdgordon.info/rockbox/fixes.patch if you can be bothered checking 04.46.49 # jhMikeS: i need the adaptor coz these comps dont have a microsd slot 04.47.58 # first I have to see if the bug happens for me 04.48.49 # JdGordon: you mean a microsd to usb adapter? 04.49.01 # yeah 04.49.11 # jhMikeS: you on it, then? 04.49.23 # usually trhrough a msd -> sd -> usb adaptor though 04.50.50 # hmm.. actually 7956 is confusing me 04.50.56 Quit jhMikeS (Nick collision from services.) 04.51.02 Join jhMikeS [0] (n=jethead7@rockbox/developer/jhMikeS) 04.52.10 # ugh, had to reboot the router 04.52.25 # dont worry about it, ill be home in 90 min, ill fiddle then 04.52.29 # cya 04.52.40 # oh, I was gonna be on it but ok 04.52.40 Quit JdGordon|uni ("CGI:IRC (EOF)") 04.54.44 Join hidden212 [0] (i=d15ed6ca@gateway/web/cgi-irc/labb.contactor.se/x-a78ad25b84d3f759) 04.55.23 # is there a new version to the sansapatcher 04.56.37 # good day to all 04.58.13 # i really dislike the fact that sundisk abandoned mini USB in favor of a propietary connector 04.59.56 # that should be a nice project 05.00.10 # the mini usb port soldering guide for different players 05.00.49 Quit Mouser_X (Read error: 104 (Connection reset by peer)) 05.01.43 Join Mouser_X [0] (n=Mouser_X@67.110.120.36.ptr.us.xo.net) 05.01.53 Quit hidden212 ("CGI:IRC (Ping timeout)") 05.10.54 *** Saving seen data "./dancer.seen" 05.13.20 Join Bam2550 [0] (i=Bam2550@c-69-249-243-110.hsd1.pa.comcast.net) 05.14.16 # When i install Cygwin it allways stops at 98 percent... (stays like that for 30 minutes) Also my computer is going very slow after installing Cygwin, is this normal? 05.15.16 # Probably not. 05.15.33 Quit Aevum ("Saliendo") 05.15.38 # I'm running cygwin (right now even) on my 200 mhz laptop, and overall usage is about normal. 05.15.49 Join bb [0] (n=bb@unaffiliated/bb) 05.16.27 # Bam2550: When installing, maybe try a different server? 05.17.06 # Mouser_X why don't you just throw linux on that haha 05.17.18 # alienbiker99: I probably should. 05.17.27 # I'm low on disk space though. 05.17.42 # (Meaning, I'm not sure if I have enough to re-partition it.) 05.17.48 # ah ok. 05.20.05 # it gets stuck at /ect/postinstall/post-texmf.sh 05.22.17 # alienbiker99: Here's a thought. The answer is probably yes, but I'm not sure (I've never done a dual-boot system before). I'm running Win98 (therefore, it's a FAT32 drive). Can I install Linux on the same drive as Windows? If yes, how much space, roughly, would you say it would take (with a minimalistic install)? 05.23.19 Join stevenm [0] (n=stevenm@129.2.201.58) 05.23.39 # hm, i'm pretty sure you can repartition it for linux, but i don't know how much space you would need, although i think it depends on the distro. 05.26.06 Quit Bam2550 () 05.26.29 # Hello. 05.28.00 Quit bb__ (Read error: 110 (Connection timed out)) 05.37.32 # Anyone seen n1s lately ? 05.40.23 Quit Mouser_X (Read error: 104 (Connection reset by peer)) 05.42.25 Join Mouser_X [0] (n=Mouser_X@67.110.120.36.ptr.us.xo.net) 05.46.21 Quit BHSPitMonkey (Read error: 104 (Connection reset by peer)) 05.46.54 # Yay! Rockbox + 7331 + 5241 has successfully compiled. It's now chugging through the plugins. 05.47.21 # (I've been trying to get that to work all weekend. At least now I know what the problem was.) 05.51.19 Quit stevenm ("Connection reset by beer") 06.01.19 # what patches are those? sound codecs? 06.03.19 # Yes. 06.03.22 # GBS and MOD 06.05.05 Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) 06.17.57 Quit webguest62 ("CGI:IRC") 06.25.53 # When I update Rockbox, how will that effect the database? Should I export it first? 06.26.12 # Not normally, unless the database format changes. 06.26.15 # (It's not important, as I don't use it much, but it'd be nice to be able to keep the info it has in it right now.) 06.31.02 Quit atsea-34 (Remote closed the connection) 06.34.02 Quit Mouser_X (Nick collision from services.) 06.34.19 Join Mouser_X [0] (n=Mouser_X@67.110.120.36.ptr.us.xo.net) 06.38.21 Quit kubiix ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 06.38.59 Join reverendnathan [0] (n=nathan@cpe-66-75-69-163.socal.res.rr.com) 06.39.16 # Hay guyz, need some halp here 06.39.43 # please read the guidelines linked in the topic first ;) 06.39.51 # So I moved .rockbox and all it's contents to the "/" directory of my iPod Video 30GB with the correct firmware 06.40.06 # And then ./ipodpatcher said it did everything OK 06.40.16 # So I Menu+Select to restart, and... 06.40.27 # ...nothing? Just goes back to the iPod firmware 06.41.07 # are you holding the menu button or have the hold switch on while booting? 06.41.21 # Nope, it reboots 06.41.34 # Apple logo shows up and comes back to the original firmware 06.41.48 # where did you get ipodpatcher from? 06.42.28 # did you install the bootloader? 06.43.15 # scorche: I got it from http://download.rockbox.org/bootloader/ipod/ipodpatcher/linux32x86/ipodpatcher 06.43.19 Join nave7693 [0] (n=evan@71-37-12-162.tukw.qwest.net) 06.43.42 # is the sansa's cpu theortically good enough to decode divx and friends? 06.44.09 # nave7693: Probably not, but I'm not the one to ask. 06.44.28 # (I don't have a Sansa, nor do I know that much about them.) 06.44.35 # i'm trying to patch with http://www.rockbox.org/tracker/task/7538?getfile=14548, it only has 1 failed hunk in firmware/target/arm/ipod/button-clickwheel.c, can someone please tell me where i'm suppose to paste the second hunk? 06.44.52 # reverendnathan: did you properly eject/umount the device before unplugging it? 06.45.17 # scorche: No, I don't know how to umount an iPod without umounting everything 06.45.20 # Which is annoyin' 06.45.32 # So I just pull the plug out 06.45.35 # No dice? 06.45.49 # spky: there are clues in the patch file and rejects file 06.45.57 # reverendnathan: yeah...that isnt a good thing 06.47.02 # reverendnathan: do the whole process over again, but dont pull the plug out till you can correctly umount it (umount /dev/) 06.47.06 # i'm lookin at the patch and the source, i'm not sure where it's suppose to be adding the hunk, the data above and below isnt in the source 06.47.24 # k 06.48.00 # spky: well, this is just part of syncing patches to current svn...you have to figure out where things go and fix them 06.48.26 # shoot 06.48.32 # scorche: Should I redo dragon dropping the .rockbox folder to /ipod/? Or just redo ./ipodpatcher 06.48.34 # i'm sorry i pasted the wrong link 06.48.50 # dragon dropping? 06.48.52 # http://www.rockbox.org/tracker/task/5111?pagenum=1 06.48.59 # and you likely have to redo everything 06.49.17 # Drag 'n' drop 06.49.21 # Dragon drop 06.49.28 # k redoin' 06.50.02 # pieso patch not custom splash 06.50.38 # well, whichever patch it is, my answer is the same :) 06.51.13 # =[ 06.51.18 # umount: /mnt/ipod: device is busy -- Gah, what do I do here? 06.51.37 # make sure everything accessing the device is closed 06.52.42 # oh 06.52.54 # whoops, had a konqueror window open 06.52.58 # =] 06.53.23 # iPod is still saying "Do not Disconnect", terminal says it disconnected... 06.53.43 # computer doesn't recognize it 06.53.49 # Should I pull the plug? 06.54.09 # did you successfully umount it? 06.54.43 # I'm pretty sure 06.54.59 # then go for it 06.55.00 # Not showing up in /dev/ 06.55.14 # for some reason my ipod wont unmount when ever i transfer a video file to it. 06.55.15 # A ha! 06.55.17 # Awesome 06.55.25 # Didn't even have to reboot 06.56.13 # Now... I have to redo my music due to the way amaroK organized them? 06.56.23 # Most likely. 06.56.32 # you can do whatever you want.. 06.57.22 Quit DataGhost ("NTOSKRNL.EXE caused a buffer overflow in System Idle Proce²¦©§ÜæîôØþ°") 06.59.26 Join stevenm [0] (n=stevenm@infranelson.student.umd.edu) 06.59.36 # Hey, MIDI now sort of has pitch bend depth.. I think 06.59.54 # Still need to listen to all the test files and all.. 07.00.26 # Cool, I've wanted rockbox for a long time, but I've been a lil' b' about getting it 07.00.39 # I loved my iAudio UI, and I always found the iPod's really lacking 07.01.29 # But there's this inexplicable clicking every 0.25 sec. I wonder if it's just my sim being dumb. target tiem 07.02.29 Part nave7693 07.10.54 Quit JdGordon ("Konversation terminated!") 07.10.55 *** Saving seen data "./dancer.seen" 07.12.55 Join JdGordon [0] (n=jonno@c210-49-113-143.smelb1.vic.optusnet.com.au) 07.15.22 Join atsea-34 [0] (i=atsea-@gateway/tor/x-1edb7fe9060a6a1f) 07.17.18 Join DataGhost [0] (i=dataghos@ip3e832ea5.speed.planet.nl) 07.19.24 # linuxstb: (in case you care)... i didnt see barry mention the load speed diference with the ppbl trick.. its less than 1 second (timed it with a stop watch from power to the rockbox logo), so really i dont think it should be available in sansapatcher incase people stuff it up 07.21.16 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 07.25.05 Quit stevenm ("Connection reset by beer") 07.27.02 Quit jhulst (Remote closed the connection) 07.27.12 # Llorean: scorche: you guys around? 07.27.19 # yar 07.27.27 # Semi 07.27.30 # did you end up testing those patches i mentioned eariler? 07.27.47 # JdGordon: ah...i thought jhMikeS was on it, so i didnt go through with it 07.27.51 # I don't remember any patches, so probably not. Been a bit hectic. 07.28.03 Quit karashata ("Leaving.") 07.28.17 # it flips the volume setting so going clockwise increases the volume like in the wps, but im just trying it out now and not sure if its more intuitive than svn... 07.29.05 # JdGordon: do you mean it would do this in the rockbox menu? 07.29.20 # no.. the volume setting 07.29.57 # under sound settings>volume? 07.30.01 # yeah 07.30.19 # I assume it flips the list, not the direction the highlighter bar moves, right? 07.30.25 # yeah 07.30.32 # so mute is at the top 07.30.42 # ok that makes sense because they already flipped this before i believe. 07.30.57 # the scrolling not the menu 07.31.15 # I wouldn't mind it. 07.31.30 # what is the patch number? 07.31.48 # www.jdgordon.info/rockbox/fixes.patch 07.32.02 # its 956 but that depends on another patch 07.32.13 # bah 07.32.15 # wrong url 07.32.47 # http://jonno.jdgordon.info/rockbox/fixes.patch 07.33.09 # Llorean: you tihnk that sounds good? 07.33.13 # then ill commit it 07.33.31 # I like the idea of clockwise rotation always increasing the volume. 07.44.26 # y yo tambien 07.44.49 # que' ? 07.45.22 # No entiendes lo que yo dije? 07.45.36 # que' ? 07.45.49 # bah, conyo 07.45.55 # JdGordon: is it in svn already? 07.46.28 # yep 07.46.36 # how long ago? 07.46.54 # 2 commits? 07.47.58 Join kubiix [0] (n=Miranda@mos-81-27-201-28.karneval.cz) 07.48.35 # thought i wasnt quick enough. i tried patching my source but it said it was alredy in there. 07.50.31 # JdGordon: will the list go up now when I move cw or is the order reversed too? 07.51.05 # jhMikeS: debria continuar en espanol ;) 07.51.43 # jhMikeS: the order is reversed.. so you move down the list 07.52.34 # toffe82: ay, porque? no esta apropiado en una canal ingles! 07.52.37 Quit Mouser_X (Nick collision from services.) 07.52.53 # jhMikeS: para molestar los otros :) 07.52.54 Join Mouser_X [0] (n=Mouser_X@67.110.120.36.ptr.us.xo.net) 07.52.57 Join flak [0] (n=randomga@124-169-73-167.dyn.iinet.net.au) 07.53.26 # toffe82: :) yo disfruto haciendo eso! 07.53.36 # jhMikeS: any luck with the info on the lcd driver ? 07.54.06 # toffe82: It does partially match. Some regs are referenced that don't seem to be in that datasheet. 07.54.09 # jhMikeS: where did you learn spanish ? 07.54.53 # toffe82: Mi novia es puertoriquena ! 07.55.17 # jhMikeS: mine is chilena :) 07.55.28 # aha! :) 07.55.36 # jhMikeS: I think the datasheet is not exactluy the one of the lcd, it is a close reference, I couldn't find the one on the dtasheet of the lcd 07.55.51 # Hey guys thinking about putting RB on my H10, would you advise backing up all data on it? 07.56.02 # no, not exactly, but it gives a clue. I wonder if something is closer though. 07.56.08 # I went on the nec site and there is no datasheet available 07.56.34 # flak: you shouls always have a back up, but rockbox wont wipe your device 07.57.22 # toffe82: I'd at least like to know a few more regs. Did you check all of them? 07.57.28 # scorche: Thanks mate, once rockbox is uploaded its just standard drag and drop to upload files? 07.57.43 # or syncing program, or however you like 07.58.08 # Thanks heaps mate ill go for a backup now :) 07.59.29 # toffe82: I'm willing to go looking around when I'm done with the heap of stuff I'm doing now. 07.59.30 # jhMikeS: I don't have time and perhaps not the knowledge :( 08.11.46 # mo0ning 08.12.02 # howdy 08.12.11 # JdGordon: Speaking about non working things - I think I discovered another ui bug, but I have to verify 08.12.21 # oh? 08.12.45 # apparently the list buttons in the player are backwards or something also? 08.13.33 # amiconn: can you confirm http://forums.rockbox.org/index.php?topic=5829.msg100009#msg100009 ? 08.14.00 # If you have icons enabled (just using default), and start something that uses a viewer from the browser, after exiting the viewer, the icon of the current file disappears. 08.14.16 # Moving one line down or up makes it reappear 08.14.41 # Observed on H300 with mpegplayer 08.14.47 # * JdGordon checks 08.14.50 Join Rob2222 [0] (n=Miranda@p54B14E96.dip.t-dialin.net) 08.15.23 # It's the first time I noticed this, so it might very well be related to my driver work 08.15.40 # its fine here... is that witht he default fonts? 08.16.24 # Using Nibus-12 08.16.30 # *Nimbus-12 08.16.31 Join daurnimator [0] (i=daurn@unaffiliated/daurnimator) 08.16.34 Quit jhMikeS (Read error: 104 (Connection reset by peer)) 08.16.37 # bah, sorry, i meant icons 08.16.41 Join jhMikeS [0] (n=jethead7@rockbox/developer/jhMikeS) 08.16.51 # yes 08.17.11 # i cant reproduce it with svn 08.17.24 Join RaRe [0] (n=Laffin_B@202-89-187-101.static.dsl.amnet.net.au) 08.17.35 # Ah, it is due to the line selector 08.17.43 Join miepchen^schlaf [0] (n=hihi@p54BF7352.dip.t-dialin.net) 08.18.00 # Lemme check sth 08.18.23 # works fine with cursor and full line 08.18.34 # I use solid color 08.18.37 Join cendres [0] (n=ashes@2001:5c0:8fff:ffff:0:0:0:4d) 08.18.52 # The icon already disappears immediately when starting the file 08.18.59 Quit ashes (Read error: 104 (Connection reset by peer)) 08.19.22 # You'll notice if the hdd is sleeping and has to spin up when clicking the file 08.19.22 # deja vu.. im sure i remember having this prblem AGES ago... but i cant reproduce it 08.19.26 # and im off for 30min or so 08.20.35 # It *only* affects solid colour 08.20.45 # Not pointer, not inverse, and not gradient 08.20.48 Join GodEater_ [0] (n=bryan@rockbox/staff/GodEater) 08.21.17 # Eh? 08.21.30 # Now it's gone... so something inconsistent... 08.21.55 # Looks like some variable doesn't get initialised properly 08.25.05 Join ender` [0] (i=krneki@84-255-206-8.static.dsl.t-2.net) 08.28.58 Join lee-qid [0] (n=liqid@p5496500B.dip.t-dialin.net) 08.29.09 Join sheppard [0] (n=sheppard@209.89.51.41) 08.29.24 # I recently updated rockbox, updated the bootloader, etc. 08.29.56 # but it seems sometimes when I power my ipod on, I get the stock ipod interface, and other times I get rockbox 08.30.14 # and the past few times turning it on it seems to be hooked on booting the default ipod interface 08.30.35 # Ah, found the conditions... 08.31.26 # JdGordon: It only happens when (1) using the solid color or gradient selector _and_ (2) the current file line needs to scroll 08.32.06 Quit Rob222241 (Read error: 110 (Connection timed out)) 08.32.13 # lol 08.32.18 # I just put it down 08.32.23 # and rockbox just loaded 08.32.54 # When clicking the file, the selector extends to the left margin of the screen, probably due to altering the drawing margins, overwriting the icon that way 08.32.56 # still noone's converted the last PP502x to packed samples? 08.33.14 # jhMikeS: We're waiting for kkurbjun. Iirc he has a mini G1 08.33.27 # well the only way that the OF should load is when you have the hold button on. so i would think maybe your hold button is loose? 08.33.38 # ok, last time I asked about who owned one noone said anything 08.34.04 Quit flak () 08.34.09 # join the club 08.34.21 Quit RaRe` (Read error: 110 (Connection timed out)) 08.34.49 # I had one for testing earlier this year, from a colleague. But unfortunately that one is broken now (hardware wise, unrelated to rockbox) 08.35.21 # ..and not by me 08.35.33 # :) 08.35.44 # methinks amiconn doth protest too much.... 08.36.01 # 08.36.02 # /me thinks the clocking setup 08.36.15 # ? 08.36.16 # :P 08.36.47 # jhMikeS: He broke the clickwheel wiring while changing the battery 08.37.04 # * GodEater_ thinks that the humour there was lost... 08.37.40 # haha wow 08.37.45 # haahaa 08.38.15 # JdGordon: Re the forum post, I know that a number of settings is "backwards" on the player, but so are some on other targets 08.38.28 # So at one point I stopped complaining... 08.39.09 # Darn, I shoulda recharged before taking a crack at rockbox 08.39.26 # I keep wanting to do stuff, but through-charging doesn't provide sufficient power 08.39.44 # rockbox is all about cracks or crack or whatever you like :p 08.41.02 # InfoNES plugin patch = very full of warnings... 08.41.26 # this is on the daily page......, These are automated daily builds of the current code. They contain all the latest features. They may also contain bugs and/or undocumented changes... identify your model,.... shouldnt it be on the current build page also? 08.41.32 # (I'm probably wrong, but I wouldn't be surprised if every line gives off some sort of warning.) 08.42.16 # psycho_maniac: it shouldn't ALSO be on the current build page, it shouldn't be on the daily page AT ALL :) 08.43.02 # maybe on the front page? 08.43.23 # I think you missed his meaning. 08.43.24 # * jhMikeS is including the definition of NULL from stddef.h and many plugins using struct struct opt_items and complaining since NULL is ((void*)0) not 0. 08.43.43 # *are complaining 08.45.07 # what the proper value for no ID anway? 08.47.12 # psycho_maniac: what about the front page ? 08.47.47 # maybe that link should be on the front page? 08.48.03 # * jhMikeS can't believe he hasn't earned a few "lazy points" so he can ask a stupid question here instead of finding out by searching. ;) 08.48.41 # psycho_maniac: what link ? 08.49.06 # jhMikeS: The voice id is *not* a pointer!! 08.49.21 # amiconn: some plugins are using NULL for it though 08.49.23 # * amiconn wonders why so many devs get that voice id wrong 08.49.38 # oops. the device chart page. 08.49.45 # That's a bug and needs to be fixed. No id is -1, ___not___ NULL 08.49.48 # when I included a proper definition of NULL as ((void*)0) they complain 08.49.56 # psycho_maniac: the device chart in the wiki ? 08.50.06 Quit reverendnathan (Remote closed the connection) 08.50.16 # apps/settings.h, lines 42ff 08.50.17 # correct. 08.50.18 # one is reversi 08.50.33 # I fixed that in several plugins already, but didn't check all 08.50.34 # psycho_maniac: it's a little out of date already though 08.51.28 # anything defining NULL as merely 0 should be fixed as well 08.52.05 Quit psycho_maniac (" HydraIRC -> http://www.hydrairc.com <- *I* use it, so it must be good!") 08.52.16 # Accesses to the MBAR area (e.g. GPIO) do profit from buffered writes - but that means all delay loops need to be checked and recalibrated 08.52.19 Join psycho_maniac [0] (i=psycho_m@ppp156.hk.centurytel.net) 08.52.55 # GodEater_: what player do you have? 08.53.18 # And the greyscale coldfire target's lcd writes too - sigh 08.53.54 # amiconn: bah ok, sounds like a jobb for nico then :p 08.54.00 # * JdGordon qiuck to pass the buck :D 08.54.08 # psycho_maniac: I have four 08.55.04 # amiconn: what buffers writes anyway re: ports? I'd think that would delay some hardware aspect being set when you expect it. 08.55.23 # ?? 08.55.45 # The bus controller has a store buffer. Accesses are still serialized 08.55.57 # JdGordon: I think I already found the bug 08.56.27 # great 08.57.07 # AH, no 08.57.29 Join RaZorbacK_ [0] (n=BOFHIRC@gar31-1-82-66-75-34.fbx.proxad.net) 08.58.46 Part RaZorbacK_ 09.00.12 # amiconn: If a GPIO write is buffered, when is it actually changed? that's what I'm talking about. 09.00.33 # It's changed a few cycles after the instruction finishes 09.01.20 # But a read following immediately won't yield the old value 09.04.26 # JdGordon: Looks like I really found it now 09.04.46 # :) 09.05.57 # Yup, verified. A 2-line fix in lcd-16bit.c 09.08.22 Join petur [0] (n=petur@rockbox/developer/petur) 09.08.46 Part toffe82 09.10.59 *** Saving seen data "./dancer.seen" 09.13.20 # anyone have a problem with me uploading an e200rpatcher binary to the wiki ? 09.13.21 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 09.13.30 # for which? 09.13.35 # linux 09.13.45 # someone complained in the forums that we don't have one 09.13.55 # i would think that linux users should be able to compile it themselves.. 09.14.00 # but if you want 09.14.11 # they should - but this new generation of ubuntu users..... 09.14.12 # :) 09.14.17 # haha yeah 09.14.27 # and OY! im a ubuntu user ! evil glare* 09.14.39 Join Zagor [0] (n=bjorn@rockbox/developer/Zagor) 09.14.45 # hey Zagor 09.14.55 # He did say "new generation." Perhaps you're old enough. 09.15.02 # hi 09.15.05 # can you stick some files on download.rockbox.org for the e200r? 09.15.09 # sure 09.15.41 # http://www.davechapman.f2s.com/rockbox/e200rpatcher.zip and the 3 attached to http://www.rockbox.org/twiki/bin/view/Main/SansaE200RInstallation 09.16.28 # JdGordon: that would now be FOUR files :) 09.16.35 # that was quick :) 09.16.43 # I already had it built 09.16.47 # cheat 09.16.50 # :P 09.17.13 # in a new bootloader/sandisk-sansa/e200r-patcher dir then? 09.17.24 # sounds good 09.18.45 # anyone want to volanteer on updating the e200 manual instrausiont? 09.18.49 # instructions even 09.19.33 # I would - but not being a e200r owner I'd be nervous of missing something out... 09.19.56 # yeah, seems i stuffed up the instructions in the forums :( 09.20.07 # e200rpatcher, install the vanialla of, sansapatcher 09.20.37 # yeah I saw that 09.20.40 # =/ 09.21.35 # done 09.21.47 # thanks 09.22.22 Join ddalton [0] (n=daniel@203-214-50-20.dyn.iinet.net.au) 09.22.47 # whats the url of the master mirror? 09.22.47 # JdGordon: why don't you like my patch? 09.22.57 # I even got a comment from sdoyon :-) 09.23.09 # ddalton: i told you why when you first brought it up 09.23.56 # well you don't use voice and 3 blind users like it. 09.24.21 # And I don't think LinusN and pondlife disagree with it completely. 09.24.36 # JdGordon: haxx.rockbox.org 09.24.40 # cheers 09.24.44 # hows usb going? 09.24.56 Part ddalton 09.24.59 # I was just going to ask that :) 09.25.19 Join pixelma [0] (i=pixelma@rockbox/staff/pixelma) 09.25.37 # slow, currently. I've hit a snag where I fail to activate interrupt on incoming bulk transfers. 09.25.44 # pixelma: You were right. Rockbox+GBS+MOD+NES emu is done. Thanks for you help. 09.26.01 # *for your help. 09.26.22 # nice to hear, you're welcome :) 09.26.49 # or, I activate it but I don't get any 09.26.58 # very frustrating 09.27.07 Join hcs [0] (n=agashlin@rockbox/contributor/hcs) 09.27.16 # coffee 09.28.17 Quit hcs (Client Quit) 09.28.55 Join hcs [0] (n=agashlin@rockbox/contributor/hcs) 09.29.33 # GodEater_: you didnt link libusb statiaclly? 09.29.51 # JdGordon: On the Player, all numeric settings are backwards. That includes all sound settings now, e.g. "+" decreases volume, "-" increases :( 09.30.17 # that shouldnt have flipped for player :( 09.30.31 # ok, ill fix that in a sec 09.30.37 # JdGordon: no I didn't 09.31.17 # ok, wiki fixed with new linjks 09.31.36 # eurgh 09.31.51 # petur: Didn't you commit the navigatable credits plugin? 09.32.15 # Now 'credits' can't be stopped anymore on Player... 09.32.27 # kill the port.. :D 09.33.52 # amiconn: it can't? 09.35.01 # nope 09.35.18 # CONTEXT_KEYBOARD isn't defined for player, so it's mapped to the standard context 09.35.36 # And the standard context will *never* fire ACTION_KBD_ABORT 09.35.36 # woops 09.35.46 # wait.. why are you using CONTEXT_KEYBOARD anyway? 09.35.55 # Ask petur, not me... 09.36.54 # we need some general navigation context, I reused the keyboard one out of laziness 09.37.29 # It used to be breakable with any button... 09.37.29 # CONTEXT_STANDARD should be used, 09.37.48 # ...and I don't see why that should change 09.37.51 # the credits plugin doesnt need anything more advanced han std_next std_prev and std_ok 09.38.34 # Hmm, that was already gone before petur added navigation... 09.38.37 # amiconn: all int settings are backwards? 09.38.45 # JdGordon: Looks like it 09.38.53 Join rvvs89 [0] (n=rvvs89@unaffiliated/rvvs89) 09.38.57 # * amiconn mentions the simulators 09.39.12 # They're called *UI*simulators for a reason... 09.39.20 # ok, it looks like the charcell hack/fix wasnt put in when i reaarnged the code a while ago 09.39.29 # yeah yeah... 09.39.50 # * petur has a new pc at work and installed ubuntu in a virtualbox - now for the compilers :) 09.40.19 # Imho the sims are more useful for their original purpose (simulating the UI) than anything else 09.41.03 # Low level stuff needs to be checked on target anyway, and higher level non-ui stuff is usually the same for the whole class of targets (hwcodec or swcodec) 09.41.07 # wait... they are usefull for something else? 09.41.22 # anybody ever see this page? http://beastnetworks.ath.cx/index.php?page=gbeat-rbox.....shows how to install rockbox on the gigabeat f/x 09.41.26 # But no developer has *all* targets available, so UI stuff can be checked in sims 09.42.30 # JdGordon: Some devs seem to use them for debugging things like codecs, dsp stuff etc. 09.42.37 # sorry ment http://beastnetworks.ath.cx/index.php?page=gbeat-rbox 09.42.39 Join CaptainSquid [0] (n=Miranda@proxy13.netz.sbs.de) 09.43.26 # * amiconn wonders whether we could simulate the wheel for wheel targets using the touchpad (on laptops) ;) 09.43.51 # mouse gestures-ish? 09.43.52 # I thought we didnt want the mouse patch built for the sim? 09.44.19 Join Crash91 [0] (n=evil91@196.218.80.108) 09.44.32 Part Crash91 09.44.33 Quit Mouser_X (Read error: 110 (Connection timed out)) 09.48.12 # amiconn: with svn, is the battery capaciy setting backwards also? 09.49.11 # JdGordon: Barry said that boot time was now 5-6 seconds and thought that was about 50% of what it was previously. I don't think it does any harm in sansapatcher - ipodpatcher has similar advanced options which are not documented in the manual. 09.49.35 # JdGordon: yes 09.49.35 # i tried it with a stopwatch and yeah, about a 1 sec speed up 09.49.52 # it takes nearyl 2s to start loading anything which is annoying 09.50.15 # ok, so at least i'v fixed some of it 09.50.38 Join spiorf [0] (n=spiorf@host222-205-dynamic.14-87-r.retail.telecomitalia.it) 09.51.06 # It doesn't bypass the Sandisk logo? 09.51.14 # bah, it looks like SVN uses a port that isn't opened by our firewall at work :( 09.51.48 # Llorean: it does, it jus displays nothing for the first secod or so 09.52.10 # In that case, I think how much time you save might depend on which OF you're coming from. 09.52.25 # I'd been led to believe "newer" OF has this annoying, long "Lil' Monsta'" animation that the older OF didn't have. 09.52.27 # no, the of shouldnt be run at all now 09.52.43 # except when you want it to boot the of 09.52.48 # which stil takes age 09.52.48 # s 09.52.56 # That's what I meant though, the newer original bootloader might be longer than the older original bootloader 09.53.30 # amiconn: all fixed, commit, or you want to test first? 09.53.45 # * jhMikeS thinks SanDisk threw that in there just to annoy _us_. :) 09.54.22 # the new OF has the stupid monsta thing from the c200's? wow /me not upgrading! 09.54.50 # petur: svn can also use https iirc, but I don't know whether that needs to be enabled on the server.. 09.55.02 # JdGordon: So I've heard, I haven't tried it. 09.55.07 # let's kindly ask them to throw in a database update bypass too 09.55.28 # or better, if they throw docs our way :p 09.55.48 # while they're at it ... schematics 09.56.09 # maybe some cash 09.57.44 # amiconn: looks like it. https doesn't respond and http gives me a 'Method Not Allowed' 09.58.11 # JdGordon: with a bit of help from linuxstb I now have a statically linked e200rpatcher 09.58.20 # I'll have a chat with out network admin, just need to figure out a reason to get that port open 09.58.20 # petur: do you want me to fix credits? 09.58.39 # GodEater_: stick it somewhere so Zagor can replace it 09.58.42 # JdGordon: if it's urgent, yes ;) 09.58.51 # its not, but im bored :) 09.59.33 Quit linuxstb ("Leaving") 09.59.40 Join pondlife [0] (n=Steve@rockbox/developer/pondlife) 09.59.44 Join davina [0] (n=davina@cpc1-sout6-0-0-cust616.sotn.cable.ntl.com) 09.59.55 # petur: it's costing the company lots of cash not to? ;) 10.00.36 # JdGordon: I've stuck it on the end of the same wiki page 10.00.48 # we only have customers with cvs, none with svn it seems :( 10.01.11 # convince one of them they should switch 10.01.31 # GodEater, JdGordon: should I replace the linux version with this static? 10.01.36 # please 10.02.07 # done 10.02.13 # thanks :) 10.02.26 Join barrywardell [0] (n=barry@jklabp.ucd.ie) 10.02.58 # * GodEater_ hides the attachment 10.03.11 # petur: is the scrolling your code? 10.03.12 # you going to edit the wiki JdGordon ? 10.03.17 # you can :_) 10.03.29 # JdGordon: about half of it 10.03.44 # it was a patch in the tracker that I modified 10.04.25 # errr wait, the scrolling or the navigation? 10.04.46 # navigaition, i tinhk 10.04.46 # JdGordon: I'm getting 404s for all the links - how long does it take to get to all the download mirrors ? 10.04.56 # some time? 10.05.30 # ok 10.05.59 Quit kubiix ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 10.10.23 Quit qweru ("moo") 10.11.44 Quit Chronon ("ZZZZZzzzzz") 10.12.23 # Anyone else testing Nico_P's work? 10.13.38 # moi 10.13.43 # c'est magnifique 10.13.45 # :) 10.13.50 # Yep, seems good in the main 10.14.13 # Sunday's commit seems to have got rid of the "randomly stop producing sound" issue I had on Friday 10.14.27 # or more accurately - a commit in between probably did 10.14.43 # I'm getting an occasional hard hang today though 10.14.53 # not had that yet 10.14.57 # Seems to be related to codec change 10.15.04 # CONTEXT_STD may not have been the best one to use :p 10.15.10 # I'm testing with alternating MP3/WMA tracks 10.15.13 # pondlife: I only have two codecs on my player 10.15.21 # and I didn't get a problem with switching 10.15.28 # let me try again 10.15.42 # It's not a reproducible crash (at least, not yet) 10.16.18 # nope - just switched fine 10.16.20 # The only other problem is that selecting an unbuffered track stops playback for longer than SVN 10.16.26 # MP3 -> SPX here 10.16.36 # that's true 10.16.41 # I said that to Nico too 10.16.58 # It's very noticeable with crossfade on 10.17.17 # Under SVN I can make pretty much any transition smoothly 10.17.19 # ah - I don't use that either 10.17.29 Join Benoitb [0] (n=Benoitb@public1.alcasat.net) 10.17.32 # With MoB, it almost always gaps 10.18.19 # * GodEater_ turns it on 10.18.20 # Getting close though 10.18.30 # I can't apply the latest version of the mpeg_resume patch fs#7487 10.18.38 Join ddalton [0] (n=daniel@203-214-50-20.dyn.iinet.net.au) 10.18.39 # Oops, just locked again 10.18.53 # even if I try to apply it before any other patch on a fresh svn 10.18.55 # Is it ok if I close p7705? 10.19.01 # does anyone still want it? 10.19.03 # Benoitb: probably because it was committed? 10.19.15 # sorry... 10.19.24 # well this sucks... autoscroll will only stop after 1 full screen is finished being displayed 10.19.32 # it just came into my mind after I wrote it on the chan 10.19.42 # ok im closing it... 10.20.51 Quit Siku () 10.20.59 # pondlife: has Nico's work changed much in playback.c yet ? 10.22.03 # Yes 10.22.06 # Lots 10.22.18 # hmmm how do I close it?... 10.22.29 # pondlife: shame it hasn't quashed that bug stripwax showed us :) 10.22.48 # True, but it should now be possible to fix bugs more easily 10.23.02 # so I'll be expecting your fix to it any minute then 10.23.13 # More easily than impossible 10.23.57 # credits on the player is a bit scray :D 10.24.02 # scary! 10.24.15 Join Peter15 [0] (n=peter151@dslb-084-058-182-195.pools.arcor-ip.net) 10.24.37 # JdGordon: why do you say that? 10.24.38 # If it's not too cheeky, I'd like to (a) wait until MoB is stable and committed, then (b) review the playback.c code and see if we can put some more comments in... then it'll be fixy-time 10.25.10 # Ah, yes and move the voice thread out of playback.c perhaps. 10.25.18 # psycho_maniac: 2 scrolling lines going pretty quickly, for 300 lines or something 10.25.19 # hmm 10.25.30 # petur: all fixed 10.26.24 # Putting almost correct lcd waitstates for X5 makes it work when boosted, and speeds up almost everything, but slows down standard lcd updates when boosted a little bit 10.26.42 # Using less waitstates works, but I don't like exceeding specs that much 10.26.58 Join [1]psycho_maniac [0] (i=psycho_m@ppp566.hk.centurytel.net) 10.27.25 # The HD66773R manual states a minimum cycle time of 200ns. It works down to 100ns 10.28.22 # My first test used 5 waitstates as on H300 (which has HD66789R with a minimum cycle time of 150ns), resulting in already out-of-specs 130ns... 10.28.58 Join reverendnathan [0] (n=nathan@cpe-66-75-69-163.socal.res.rr.com) 10.31.23 # OK, so I just got rockbox, trying new themes for my iPod Video. Using themes with Album Art, but the art won't show! 10.31.36 # Using fusion build 10.31.50 # we dont support custom builds in here 10.32.27 # JdGordon: thanks 10.33.34 # Oh OK 10.34.25 # Ah, on H300 even 3 waitstates don't work... then it's due to dma vs. cpu transfer 10.35.01 # I thinkl I'll settle with 4 waitstates for X5. Normal lcd update when boosted stays almost the same speed then 10.37.00 Quit reverendnathan (Remote closed the connection) 10.37.09 Quit spiorf (Remote closed the connection) 10.41.25 Quit psycho_maniac (Nick collision from services.) 10.41.25 Nick [1]psycho_maniac is now known as psycho_maniac (i=psycho_m@ppp566.hk.centurytel.net) 10.47.58 Quit homielowe (Read error: 110 (Connection timed out)) 10.48.12 # * amiconn goes hunting delay loops 10.50.31 # pondlife: cross fading is working ok here too 10.51.42 # I doubt that's related to my crashing, but it does make the slower rebuffer more noticable. 10.51.57 # Or maybe there's a lack of yielding during rebuffers now? 10.52.24 # Does your file browsing go slower during buffering, or was that more obvious with SVN ? 10.52.58 # I wonder if that's more noticeable with a scrollwheel... 10.53.13 # pondlife: that's hard to say 10.53.17 # where do i get his latest source? 10.53.28 # the file browser feedback has always sucked during buffering 10.53.34 # http://repo.or.cz/w/Rockbox.git?a=shortlog;h=mob 10.53.52 # Go for the latest snapshot 10.53.57 # Or use git? 10.54.01 # git 10.54.25 # I'm using the code from the last commit Nico made 10.54.43 # "git checkout master; git branch -D mob; git checkout -b mob origin/mob" works for me. You may only need the last bit.. 10.55.01 # So browse-during-buffer still sucks? 10.55.08 # as far as I can tell 10.55.09 # :) 10.56.41 # Hhard crash again... :/ 10.56.52 # still working fine here :) 10.56.59 # Caused by skipping backwards during buffering I think 10.57.01 # jhMikeS: I found a few delay loops (in fact less than I expected, just in 6 places). And it looks like they need fixing, e.g. pcf i2c is a bit unreliable on my X5 right now 10.57.13 # (time occasionally disappearing in wps status bar) 10.57.26 # * pondlife hopes his reset switch survives the day 10.57.48 # pondlife: I wouldn't say the performance of the file browser is any better / worse than svn during buffering 10.57.50 Quit miepchen^schlaf (Read error: 110 (Connection timed out)) 11.00.16 # OK, I can crash it every time now, I think 11.00.21 # no problem with voice which is nice :) 11.01.15 # 1) Set up a decent-sized playlist (mine's about 9000 tracks, although I doubt you need that many). 11.01.35 # 2) Go via the WPS context menu into playlist viewer 11.02.01 # 3) Repeatedly go up/SELECT 11.02.19 # i.e. alternate so you're skipping backwards 11.02.19 # JdGordon: Umm, now + increases the value and - decreases it, but the list is still backwards 11.02.23 Join Thundercloud [0] (n=thunderc@resnet01.nat.lancs.ac.uk) 11.02.38 # in which? 11.02.42 # I always expect + to move down. Now it moves up, where the higher values are 11.02.43 # amiconn: I guess that's to be expected if the i2c is oversped :) 11.02.49 # jhMikeS: yup 11.02.50 Join reverendnathan [0] (n=nathan@cpe-66-75-69-163.socal.res.rr.com) 11.03.08 Join miepchen^schlaf [0] (n=hihi@p54BF7352.dip.t-dialin.net) 11.03.18 # Need to make a tiny measing loop and then fix the delays 11.03.26 # + shuold move down the list? 11.03.31 # now im really confused 11.03.34 # Question, whenever I connect my iPod to the computer, it charges, but doesn't mount... how can I get it to? 11.03.47 # As in, the computer ain't recognizing it as a drive 11.03.50 # + always moves down the list 11.03.56 # pondlife: track change to an unbuffered track is at least as fast as svn on my sansa 11.03.57 # reverendnathan: do you have a default build ? 11.04.04 # (or should, and does, e.g. in menus and the browser) 11.04.05 # amiconn: how about the serial number chip too? 11.04.17 # Gah, darn it I don't 11.04.24 # JdGordon: Definitely slower here, can take about 5 seconds 11.04.28 # On H340 11.04.30 # pondlife: and data abort doing the up+select thing 11.04.31 # In sound settings it moves up. That gives correct behaviour for the values, as those are also reversed 11.04.34 # Aha! 11.04.35 # ah well that would xplain it 11.04.47 # But it's backwards logic... 11.05.18 # wait a sec.. opening the player sim 11.05.18 # Imho it should move down, and the higher values should be further down the list 11.05.32 # Battery capacity is now correct 11.05.40 Part ddalton 11.05.59 # so volume is now wrong? 11.06.13 # + makes it louder.. isnt that correct? 11.06.16 Join obo [0] (n=obo@rockbox/developer/obo) 11.06.26 # Hmm, the list in numeric settings is backwards on all targets. Why is that?? 11.06.29 Quit lee-qid (Read error: 110 (Connection timed out)) 11.06.42 # JdGordon: + = louder = move down list 11.06.47 Join webguest23 [0] (i=4b498002@gateway/web/cgi-irc/labb.contactor.se/x-302c18db11f751ed) 11.06.47 # Should be, I mean 11.07.01 # well when its only 2 lines up/down doesnt really exist 11.07.26 # pondlife: creating an enormous playlist now 11.07.43 # JdGordon: it does... 11.07.46 # I can crash the sim using this recipe too, but maybe a different reason 11.08.00 # I get a segfault in tagtree_unbuffer_event 11.08.06 # jhMikeS: Serial number seems to work correct, but I have that file on my list too 11.08.59 # JdGordon: Why are numeric settings backwards on all targets? 11.09.02 Quit hcs ("Leaving.") 11.09.05 # backwards how? 11.09.22 # lower at the top? 11.09.26 # this seems really confusing :S 11.09.34 # i mean, higher at the top 11.09.35 # No, lowering when going down the list... 11.09.39 # yes 11.09.56 # umm... thats what was decided? 11.10.03 # but yeah, that really doesnt make sense anymore 11.10.33 # It used to be the other way 'round, and I can't remember voting about that 11.11.00 *** Saving seen data "./dancer.seen" 11.11.26 Quit webguest23 (Client Quit) 11.11.36 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 11.11.40 # note to nico: poweroff while buffering data aborts 11.12.27 # amiconn: no, it makes sense... higher values at the top of the list 11.12.27 Quit Jon-Kha (Read error: 131 (Connection reset by peer)) 11.12.57 # Not really... 11.13.13 # it just doesnt feel right with wheel targets, and the player 11.13.22 # why volume should be a list is beyond /me 11.13.26 # Or rather, it depends on how you look at that list 11.13.39 # pressing up on the iriver makes sense to be going up in values 11.13.44 # If you see it as a list of values (as I do) , they should increase downwards 11.13.59 # ...like it was, and wouldn't cause inconsistencies between targets 11.14.03 # and to everyone else.. thats backwards :) 11.14.06 # * linuxstb agrees with amiconn 11.14.28 # dinner.. we'll pick this up in 30 11.14.58 # If you see numeric settings as some kind of slider, it makes sense to have higher values at the top, but then we get inconsistencies between directional moving targets and wheel targets+the player 11.15.01 Quit Peter15 () 11.15.13 Join CaptainSquid83 [0] (n=Miranda@proxy13.netz.sbs.de) 11.15.47 # a vertical slider would make sense there though and with lots of room to display min/max + actual value 11.16.17 # There already was a slider experiment. It looked way ugly 11.16.25 # * amiconn likes the list with its fine control 11.16.27 # Instead of showing a list for volume, could we just show the "current" value, much like it is in the status bar? 11.16.45 # Then up/down makes sense, since it's not a list. 11.16.45 # ah, but that's the art part and it _can_ look good 11.17.00 # maybe this is the time to use the (forgot the name) but the setting name and actual setting were on the same line. 11.17.17 # GodEater_: brb, time for a cuppa 11.17.42 Quit CaptainSquid (Remote closed the connection) 11.17.56 # * jhMikeS hopes his player's disk isn't biting the dust...don't need that now 11.20.09 Quit idnar (Nick collision from services.) 11.20.11 Join idnar_ [0] (i=mithrand@unaffiliated/idnar) 11.22.04 # pondlife: how many times do you do this till it crashes ? 11.22.33 # About 3 11.22.36 # 3-5 11.22.44 # and do you wait for it to start playback 11.22.47 # No 11.22.51 # Fast as you can 11.22.52 # nor me 11.22.58 # I've gone back about 30 11.23.00 # no crash so far 11.23.06 # Might be database related 11.23.18 # I don't use it 11.23.27 # Specifically, my playlist is Database > Tracks 11.23.46 # right 11.23.46 # Sim segfault is database related 11.24.01 # I'll try a file instead.. 11.24.42 Join Jon-Kha [0] (i=jon-kha@80-248-247-190.cust.suomicom.fi) 11.25.32 # Wooh, a crash with a splash! "No codec for ./Pulp/Different Class/03 Common People.mp3" 11.25.40 # * GodEater_ tries a database load 11.25.41 # Pin time 11.27.35 # Hmm, a file browse crashes too here 11.27.47 # Couldn't repro that splash though 11.29.07 Join bluebrother [0] (i=PnYDE8b9@rockbox/staff/bluebrother) 11.31.03 # pondlife: can't reproduce in the DB either 11.31.42 Quit psycho_maniac (" HydraIRC -> http://www.hydrairc.com <- *I* use it, so it must be good!") 11.31.55 # jhMikeS: The pcf i2c is probably why you saw better performance with the spc codec 11.32.03 # GodEater_: Must be timing critical. 11.32.07 # pcf i2c is running all the time for reading buttons 11.32.25 # amiconn: I was using H120 for that so I doubt it :) 11.32.40 # Hmm, not all the time, due to the detection interrupt 11.32.50 # H100 has a bitbanging adc driver too... 11.34.34 # * JdGordon back 11.34.53 # the slider looked terrible 11.35.07 # I tink higher values at the top makes sense for all but the wheel targets 11.35.10 # pondlife: you're clearly faster than me :) 11.35.12 # That reminds me - I wanted to make that one adapt to cpu clock like the pcf driver does 11.35.27 # Could save a percent or so when not boosted 11.36.08 # There's other fw and software where a slider doesn't look terrible so that makes no sense to me that it's the slider at fault. 11.36.19 # * amiconn needs to measure clock cycles for GPIO access with vs. without buffered writes 11.36.36 # jhMikeS: A slider has some fundamental problems 11.36.43 # there was an idea for a triangle slider (like the volume display in the statusbar), but using up/down for it feels wierd 11.37.03 # amiconn: i disagree... a list is just as fine-grained as a slider 11.37.08 # If it's horizontal, its operation is inconsistent with the other settings, confusing blind users, or blind operation 11.37.39 # If it's vertical, giving the extra information for precision looks horrible and takes a lot of screen estate 11.38.17 # mmmm....perhaps. 11.38.27 # JdGordon: A list may be as fine grained, but without also printing the numeric values, it's not as precise to operate 11.38.53 # oh, anything we do would have to display at least the current value 11.38.57 # That was btw one motivation of the rockbox port to the archos recorder v1 (!) 11.38.58 # and shhould show min and max 11.39.06 # I still don't see why it needs to display a full list. 11.39.08 # which was? 11.39.13 # why does a horizontal slider need left / right to change values? It's just a graphical representation of a value 11.39.17 # Or a slider. 11.39.24 # man, the archos is just going "cha-chunk, cha-chunk" trying to unzip a build to it. :( 11.39.38 # The archos OF uses sliders, which are sort-of fine grained, but never reproducible, since they didn't show the numeric value 11.39.53 # Llorean: I like that we have as few UI types as possible. Would prefer a list to a bespoke UI.. 11.39.55 # bluebrother: having a horizontal slider but pressing up/down feels very wierd 11.40.08 # pondlife: When the user clicks on "Volume" it could just display "Volume: -27db" and scrolling or up/down could change the value. 11.40.13 # JdGordon: I disagree completely. It's just a graphical representation. 11.40.19 # So you e.g. had to remember a bass setting like: "Between 3rd and 4th notch, a little right from the middle" 11.40.20 # pondlife: Essentially mirroring volume operation in the WPS, except it's a volume-specific screen. 11.40.23 # its also counter-intuitve 11.40.28 # (hope that's understandable) 11.40.34 # if you see a horizontal slider, you instinctivly press left right 11.41.16 # is there a fill triangle lcd function? 11.41.18 # Llorean: I'd still prefer a single structure for all settings. Makes code simpler, makes blind naviagation simpler. Although your proposal would be identical blind I guess. 11.41.26 # JdGordon: In the plugin lib there is 11.41.37 # small enough to put in the core? 11.41.44 # Why would we want that? 11.41.46 # easy to get a HD for a player? 11.41.51 # pondlife: It would be identical blind to the current implementation, and I thought numeric lists were already declared differently in the code (and this would pretty much be useful for any numerical list), though I could be wrong. 11.42.01 # jhMikeS: Just standard 2.5" notebook hdd 11.42.14 Quit reverendnathan (Remote closed the connection) 11.42.37 Join spiorf [0] (n=spiorf@host222-205-dynamic.14-87-r.retail.telecomitalia.it) 11.42.41 # this one's 2.5" standard scraping noises 11.42.47 # * bluebrother remembers having done some work on FS#5990 a year back or so ... http://www.stud.uni-karlsruhe.de/~uhcn/rockbox/dump_0001.bmp 11.42.51 # Llorean: Yep, probably. I quite like the scroll bar though. 11.42.58 # jhMikeS: Checked the batteries and battery contacts? 11.43.12 # it is plugged. will that still affect it? 11.43.17 # yes 11.43.20 # pondlife: Not quite sure which use of "scroll bar" you're using here. :) 11.43.20 # JdGordon: What was the original problem? Scrollwheel was anticlockwise to increase? 11.43.22 # hmmm....ok. 11.43.33 # Llorean: haha... on screen! 11.43.39 # pondlife: Do you mean "like the sliders in the EQ" or "on the left side of long lists"? 11.43.42 # The archos charger is *just* a charger, it doesn't provide enough juice to run the player directly 11.43.45 # * bluebrother pasted the wrong link ... http://www.stud.uni-karlsruhe.de/~uhcn/rockbox/dump_0001.png :o 11.43.48 # The left side of lists 11.43.59 # pondlife: yes 11.44.13 # hmm 11.44.19 # The archos never draws more than ~350mA from the charger, but the hdd needs almost 1A when spinning up 11.44.23 Quit Thundercloud (Remote closed the connection) 11.44.38 # bluebrother: yeah, but that wont look good on small displays, i.e the nano 11.44.43 # JdGordon: Why not revert your changes for non-scrollwheel targets? 11.44.53 # which change? 11.45.06 # The numeric list direction... 11.45.11 # bluebrother: Now imagine that with a larger font... 11.45.11 # I don't think this one's archos issue...and dammit, I thought it was plugged-in and it wasn't. lol 11.45.21 # pondlife: nothing changed in that commit for non wheel targets 11.45.22 # JdGordon: the Nano's display has a higher resolution than the H100's... 11.45.29 # it does? 11.45.35 # JdGordon: iirc I extended that patch to auto-swap to a horizontal view once the space gets too less 11.45.41 # jhMikeS: Also, if you didn't use the player for a while, the batteries might be discharged 11.45.44 # pondlife: I think some of us don't like the idea of the list being different ordered on different targets 11.45.52 # Ah, ok 11.45.53 # bluebrother: I also don't like that you can't see the possible "steps" 11.45.55 # oh, bloody hell...plugged it and it just wrote fine. omfg. 11.45.56 # Those NiMHs are nasty, unless you get som enew-generation one 11.45.57 # s 11.46.03 # JdGordon: 176x132 for Nano, 160x128 for H120 if I recall 11.46.14 # I would rather it was the best UI for the input device 11.46.28 # Llorean: I disagree with that.. lists shuold be highr at the top for button targets, and lower at the top for wheel and player 11.46.29 # On a joystick, up = vol up makes sense. 11.46.42 # pondlife: Well, if the list is actually displayed, scrolling clockwise to go "down" the list makes sense, and if lower values are down, no problem. 11.46.48 # Or rather, if higher values are down, no problem 11.46.54 # Exactly 11.47.07 # JdGordon: Sort of... depends on how you think of the volume setting 11.47.28 # But with a directional cross, it does at least make some sense to have higher values at the top 11.47.31 # pixelma: that's indeed a drawback. 11.47.36 # On wheel targets and player, it does not 11.47.51 # thats what im saying 11.48.05 # I guess it doesn't kindly do hw shutdown when low eh? 11.48.15 # I think we all agree... no? 11.48.25 # yes we dont agree 11.48.27 # jhMikeS: No, because that would either be too unreliable, or waste a lot of juice 11.48.29 # or no we do kinda 11.48.30 # maybe 11.48.41 # Maybe not 11.48.52 # "That's not an argument.." 11.48.55 # no, we agree that yes we don't 11.49.04 # I disagree 11.49.17 # I agree with that 11.49.19 # NiMH cells have a very flat discharge curve, and differences between brands exist, plus differences in adc calibration between individual targets 11.49.28 # * pondlife heads back to work and testing MoB 11.49.44 # amiconn: are they just AA NiMh or some custom thing? 11.49.47 Quit Rob2222 (Read error: 104 (Connection reset by peer)) 11.49.48 # ANd since deep discharge doesn't destroy NiMHs, we decided that only LiIon+LiPo targets get low-bat shutdown 11.49.53 # Just AA 11.49.57 Join Rob2222 [0] (n=Miranda@p54B14E96.dip.t-dialin.net) 11.50.06 # * JdGordon works on getting rid of the need for the fliplist bandaid 11.50.08 # I'd try to get some new generation ones if you want to replace them 11.50.31 # sure, easy to get that I think 11.50.39 # JdGordon: Am I right in thinking that it's just your last change in option_select.c that should be reverted? 11.50.58 # Would anyone apart from me like a WPS virtual LED for CPU boost? 11.51.18 # jhMikeS: Avoid those top-capacity ones. They have higher capacity than the new generation, but still the high self discharge rate problem 11.51.27 # (ofetn even worse than old ones) 11.51.42 # pondlife: Doesn't serve much purpose in the WPS, does it? 11.51.48 # amiconn: no, this has been a problem for ages... its just that commit brought it to light again 11.52.02 # Nah, I'd just like to keep an eye on buffering and boost.. 11.52.20 # * jhMikeS sees 14, 15, 14 in the Bass setting on player ?? 11.52.20 # aha 11.52.21 # pondlife: I like the idea. 11.52.39 # jhMikeS: Range problem... ask JdGordon ;) 11.52.43 # wtf, the menu's all out of order 11.53.00 # 10, 9, 10, 11, 11.53.38 # whisky tasngo foxtrot 11.56.41 # foxtrot uniform charlie kilo delta uniform papa! 11.57.49 # delta alpha papa? 11.58.35 # tango hotel echo mike echo november uniform sierra 11.59.09 # so, have we agreed that up == increase on button targets, and clockwise == increase on wheel, and right == increase on player? 11.59.21 # for all int settings 12.00.00 # * jhMikeS thought we agreed to disagree but finds that agreeable. 12.00.40 # JdGordon: I think I can live with that, if the list increases downwards on player and wheel targets 12.01.06 # * JdGordon 's current desktop if anyone craes :) http://jonno.jdgordon.info/snapshot1.png 12.01.59 # just to prove i do use the player sim :) 12.02.40 # JdGordon: cleanup your desk! 12.02.40 Join jonashn [0] (i=573e6a35@gateway/web/cgi-irc/labb.contactor.se/x-e0bb2c7f65b48384) 12.02.51 # JdGordon: What? Just 10 open app windows? ;) 12.02.58 # use virtual desktops! 12.03.02 # * amiconn has 21 windows atm 12.03.05 # * JdGordon hates virtual windows 12.03.23 # ...and 29 tabs in ff 12.03.34 # thats a bit... excessive 12.03.44 # Nah, it used to be more... 12.03.48 Join Thundercloud [0] (n=thunderc@resnet01.nat.lancs.ac.uk) 12.03.54 # * jhMikeS has 6 tb tabs...doesn't want more 12.04.43 # * JdGordon curses bloody negative Db values 12.05.08 # do only windows sims come with the neato player bitmaps? why don't I see those? 12.05.23 # jhMikeS: rockboxui --background, if I recall 12.05.25 # Use --background 12.05.36 # jhMikeS: ,y desktop looks like windows? 12.05.39 # nifty 12.06.33 # JdGordon: I thought it was :p...perhaps Vista or something which I refuse to get 12.06.49 # hehe silly bugger... its kde 12.07.42 # looks like kubuntu 12.08.27 # got it in one 12.10.31 # * jhMikeS never thinks about desktop comp stuff and so stays ignorant 12.10.45 Quit jonashn ("CGI:IRC (EOF)") 12.13.18 Join agm3nt [0] (n=opera@bartek.tu.kielce.pl) 12.13.34 # That slider looks pretty good 12.16.55 Join kubiix [0] (n=Miranda@mos-81-27-201-28.karneval.cz) 12.17.10 Join RockBox [0] (i=Boogie@cm146.delta19.maxonline.com.sg) 12.18.11 # ok, anyone want to test the patch? 12.18.30 # what patch? 12.18.31 # slider patch? 12.18.50 # to make the int settings consistant on each target 12.19.33 # http://jonno.jdgordon.info/rockbox/intsettings.patch 12.20.23 # amiconn: so you dont get cross after i commit it? ^ :D 12.21.41 Join Nico_P [0] (n=nicolas@rockbox/developer/NicoP) 12.21.58 # * bluebrother curses this stupid frame thingy 12.22.18 # yeah, my bloody isp doesnt allow incoming on port 80 12.22.35 # hey Nico_P 12.22.41 # hi 12.22.43 # i finally got to try your mob code 12.22.53 # a[art from the 2 data aborts, it works nicely 12.23.12 # I just saw a mail from pondlife about a data abort 12.23.34 # shutting down while buffering got one 12.23.47 # i assume pondlife tolkd you abuot the skiping in the playlist viewer 12.23.55 # no 12.23.58 # euh 12.24.03 # Yes, that's the same one 12.24.07 # A whole typo collection ;) 12.24.10 # ah yes 12.24.26 # didn't read closely enough ;) 12.24.34 # shouldn't abs() be in there somewhere? 12.24.35 # pondlife: thanks, it should be easy to track down 12.24.48 # Hope so 12.25.13 # Do you still support the scrobbler callbacks, by the way? 12.25.32 # pondlife: I'm not sure but there's a chance 12.25.39 # Ah, one more thing - the buffering is a lot more relaxed now compared to SVN 12.25.51 # [20:23:58] euh <- was that to the typos or the patch? 12.25.54 # (it's very obvious in the sim) 12.25.56 # pondlife: which means ? 12.25.57 # the typos 12.26.02 # ok :) 12.26.47 # Nico_P: It means that playing an unbuffered track is rarely seamless with a 2 second crossfade on 12.26.57 # SVN buffers faster 12.27.10 # I suspect you've just got to play with sleeps a bit 12.27.36 # What's crossfade? :P 12.27.54 # It's something on those new-fangled SWCODEC targets :p 12.27.55 # if any issues exist with kernel object speed those will be resolved in not too long 12.27.59 # I didnt check with crossfade on, but had no noticable gap (no bigger than svn anyway) skipping to an unbuffered track on my sansa 12.28.05 # pondlife: what case is that in ? skipping to an unbuffered track with corssfade on ? 12.28.28 # Yes, but crossfade isn't needed ... it just makes it obvious as I'm used to it being seamless. 12.28.48 # You may need a slow-ish target to see the difference. 12.29.43 # I was using the database (same as the back-select crash) if that's relevant 12.30.44 # Wooh, sim segfaults immediately I resume playback too 12.31.08 # lots of bugs :p 12.31.18 # Possibly the same one 12.31.32 Join jba [0] (n=jba@c211-30-160-138.blktn3.nsw.optusnet.com.au) 12.31.36 # other playback bugs are going to swarm like locusts because of the timing changes 12.32.04 # amiconn: thanks for the bufix btw 12.32.10 # Nico_P: http://www.pastebin.ca/737328 12.32.17 # If you're interested.. 12.32.23 # pondlife: I sure am ! 12.32.42 # jhMikeS: what timing changes ? 12.33.11 # this should give a small green delta as a nice side effect :) 12.34.43 # changing stuff around in playback is like whacking a hornets nest with a stick :) 12.34.43 Join stewball`ghost [0] (n=WTFOMGBB@91.104.250.94) 12.34.59 # if its a big enough stick, it will work though 12.35.56 # That's the only hope, really :/ 12.35.57 # Nico_P: just things with threading that relied on yields in certain places instead of actual sync 12.36.10 # JdGordon: "min = sound_max(setting_id);" isn't obvious... ! 12.36.19 Part agm3nt 12.36.23 # I'm sure it works, but... 12.36.29 # jhMikeS: I'm trying to do better... not sure it actually is better though 12.36.32 # big enough stick = fusion nuke 12.37.08 # jhMikeS: what do you think of audio_yield_codecs ? I have a similar one for the buffering code 12.37.09 # Nico_P: It looked better to me quite a bit but there's all the other code too 12.37.39 # I've always wondered why that's nescessary 12.39.13 # it interrupts the buffering loop if there are new messages in the queue 12.39.28 # and if the pcm buffer is low on data too 12.39.50 # heh.. my friends whacked a hornet's nest with a stick :) 12.40.05 # in my code it allows not having to buffer all of a track before being able to treat the nex queued message 12.41.05 # Nico_P: queue_wait will yield completely and process a message if needed 12.42.20 # jhMikeS: yes but I can't call queue_wait in the buffering loop, can I ? 12.42.40 # queue_wait_w_tmo you can 12.43.01 # hello 12.43.14 # since it's both a sleep and message grabber 12.43.31 # can any1 help me out with rockbox here? 12.44.27 # under database, all tracks, how come all my songs are untagged? 12.45.15 # because all your songs are untagged ? 12.45.30 # jhMikeS: but then how do I get the event in the main buffering thread loop ? it will have been consumed already, won't it ? 12.46.04 # how do i tag it? 12.46.43 # RockBox: with a good tagging program 12.47.12 # RockBox: Good name, btw.. 12.47.29 # it's kinda strange talking to Rockbox ... 12.47.32 # lol 12.47.35 # i change my nick 12.47.53 # like talking to the Compiler (who was in once ...) 12.48.01 # erm 12.48.01 # RockBox: http://www.rockbox.org/twiki/bin/view/Main/UsefulTools names some 12.48.03 # pondlife: I couldn't repro the bug you mailed me about with a non-dataase playlist 12.48.07 # what program? 12.48.30 # cf timing is weird.... 12.48.59 # Nico_P: return it to the main loop by passing the event struct pointer? 12.49.12 # but i transfer like 2000 songs to my ipod, its possible thats its all untagged? 12.50.16 # which tagging program u guys recommend? 12.50.20 # Nico_P: you can stay in the function if EV_TIMEOUT is received but return an actual event if one comes up. 12.50.31 Quit rjg (Remote closed the connection) 12.50.38 # jhMikeS: makes sense 12.51.35 # Nico_P: I get another crash with file-based browsing, but not reproducible yet 12.51.46 # * amiconn hopes his H1^80's USB socket will survive all this testing :/ 12.52.07 Join ddalton [0] (n=daniel@203-214-50-20.dyn.iinet.net.au) 12.52.12 # pondlife: even with a database playlist, I haven't had a crash by doing UP and SELECT repeatedly (gigabeat) 12.52.14 Part ddalton 12.52.19 # but audio didn't start 12.52.53 # * Nico_P feels a little overwhelmed... 12.53.01 # I should note things down 12.53.06 # * pondlife knows that feeling 12.53.26 # We need to have a little reserved bit of Flyspray for MoB... 12.53.41 # maybe it's time to open a task 12.54.11 # how do people feel about displaying the rockbox logo in the bootloader (mainly sansa for now) 12.54.26 # badly usually 12.54.33 # why? 12.54.34 # it was removed from the Gigabeat bootloader for example 12.54.47 # the feeling is the bootloader should do nothing more than is necessary to boot 12.54.57 # at least, that was how it was explained to me 12.54.59 # I think that was different, it loaded the logo from a file, didn't it? 12.55.09 # I'm talking about a compiled in logo 12.55.10 # yes 12.55.12 # it did yes 12.55.31 # I now think that a compiled in logo makes sense, but then it should apply to all targets 12.55.56 # However, there's a problem for colour targets where the bootloader resides in flash: the logo is quite big 12.56.05 # I have made the changes necessary for e200 and it works fine, no noticable slowdown 12.56.14 # On H300 the bootloader probably won't fit with the logo built in 12.56.40 # amiconn: ah, how much space is available? 12.56.45 # My idea was to introduce compressed bitmaps for colour targets, and decompress 12.56.58 # Iirc it's 64KB, and the bootloader already uses 40-ish 12.57.08 # The logo is ~29KB for H300 12.57.23 # amiconn: maybe a full screen logo isn't necessary 12.57.35 # Nico_P: A jumping logo would look very odd 12.57.46 # hmm that's true 12.57.49 # that's not full screen, it's just the same one shown already on normal boot 12.57.49 # Either the same as what rockbox shows, or none 12.58.09 # barrywardell: Yes, but that's already 29KB for a screen width of 220 pixels 12.58.32 # yeah, gigabeat is ~94KB 12.58.37 # Fullscreen would be 76KB 12.59.04 # how quick is the compression you were thinking about? 12.59.04 # I tried ucl compression on the logo (just using the .o), and got it down to ~8.5KB 12.59.17 Join rjg [0] (n=robert@proxima.lp0.eu) 12.59.30 # The cut-down ucl decompressor needs ~1KB of code 13.00.37 # Decompression is quite fast. I didn't measure on cf or arm yet, but on 11MHz SH1, decompressing ~200KB takes less than a second 13.01.14 # And since ucl decompression uses bitshifts, it should be faster on cf and arm... 13.01.23 # there's also a problem on PP that the bootloader currently needs to fit inside IRAM 13.01.56 # I would expect the logo decompression to take around 50ms 13.02.06 # (on H300) 13.02.17 # Very coarse estimation of course 13.02.19 # the ucl code is already in svn? 13.02.27 # 50ms is very acceptable 13.02.33 # yes 13.02.55 # The ucl compressor is also in svn, built for all archos targets 13.03.15 Quit RockBox () 13.03.19 # The stripped-down decompressor only supports compression method 2e, and only a single block 13.03.19 # http://pastebin.ca/737347 <-that's my patch without compression 13.03.49 Join safetydan [0] (n=safetyda@rockbox/developer/safetydan) 13.03.51 # So the compressed data must be made using uclpack --2e --best, and must not exceed 256KB 13.04.03 # (the --best is optional) 13.04.19 # the stripped down one is in firmware/decompressor? 13.04.45 # barrywardell: why do we need to fit it into IRAM? If we don't load RB, any DRAM can be discarded. Of course some things might need setting and resetting to load retailos. 13.05.10 # the first thing the bootloader does is copy itself to IRAM 13.05.19 # Yes, and in flash/bootloader/bootloader.c 13.05.39 # It's the very same function 13.05.52 # sure, but nothing says that _has_ to be the case. I can't see any reason to stick to that. 13.06.31 # amiconn: thanks, I'll look into that 13.06.56 # jhMikeS: but then loading the code to dram will overwrite the currently executing bootloader 13.07.27 # barrywardell: Maybe it's a bit too early to do that now. It would be easier after introducing bitmap headers 13.07.39 # hasn't it loaded rockbox already and then it jumps to whatever fw is picked? 13.07.52 # the rockbox bl more accurately 13.08.30 # jhMikeS: no, it copies itself to IRAM, then loads either rockbox or of the DRAM_START 13.08.38 # amiconn: are they planned? 13.08.41 # yes 13.09.30 # barrywardell: ah, so we're first and then we run OF bl or rockbox fw? 13.10.06 # no 13.10.37 # currently it runs OF bl first, then Rockbox bl, which then either loads OF or Rockbox to DRAM_START and jumps there 13.11.02 *** Saving seen data "./dancer.seen" 13.11.09 # barrywardell: In fact compressed bitmaps would make sense on colour targets in main rockbox too, for large, infrequently used logos 13.11.12 # right, so then we only put parts of the rb bl that can be overwritten when no longer needed. A bitmap image should only be needed once. 13.11.16 # Rockbox logo, and usb logo atm 13.11.54 # jhMikeS: yes, true. the bootloader could me modified to work like that 13.11.59 # barrywardell: We could run from dram, load OF or rockbox into a buffer, and then only have a tiny copy-and-run routine in iram 13.13.22 # That's what RoLo does, on SH1 and coldfire at least. 13.13.56 # Load the new firmware into dram, and then call a small iram function that copies the new fw into place (overwriting the old one), and runs it 13.13.58 # If we want we could try to lock it in the cache. Gigabeat can do that and perhaps PP. Needs poking sessions. 13.14.24 # Coldfire can also lock cache lines 13.14.32 # (icache only of course) 13.14.52 # yes, all good options. but the current bl works and if aint' broke... 13.15.04 # But why fiddle with that if we can use iram? 13.15.06 # I think gigabeat may require that for a RoLo 13.15.30 # Gigabeat also has iram. Even if it's tiny, it should suffice for things like rolo code 13.15.34 # ...if it ain't broke...make it less broke :) 13.15.37 # if the bootloader grows bigger, then it will be necessary 13.17.22 # Okay, buffered writes shorten the execution time of instructions writing to gpio by 6 cpu cycles 13.17.27 # amiconn: I'm aware of that. I'm under the impression there was some trouble with it. 13.17.54 # Hmm, but pcf i2c still seems to glitch... 13.18.04 # amiconn: as opposed to what? 13.18.16 # ? 13.18.33 # how many cycles was it before? 13.18.41 # Depends on the instruction 13.19.38 # The atomic bit manipulation (and.l / or.l) needs 21 cycles with unbuffered writes, and 15 cycles with buffered writes 13.19.54 Quit FOAD ("I'll be back") 13.21.16 # could buffered writes cause changes in the GPIO level to have bursts of fast activity? 13.21.58 # why is an .o file ~1/3 the size of the corresponding .bmp? 13.22.29 # it's the native format? 13.22.45 # ah, yeah 13.23.24 # Should be 2/3 for 16 bit targets 13.23.42 # (assuming 24 bit bmp) 13.24.35 # well starting with a small-sized 32-bit .bmp with a big BITMAPINFOHEADER to a native 16-bit color format with no header could easily go to 1/3 13.24.39 # yeah, two thirds, I read wrong 13.24.50 # 19677 vs 28566 13.25.11 # The bmp header is fixed size, and rather small 13.25.12 # I was looking at the wrong .o file 13.27.49 Part Llorean 13.33.38 # Nico_P: Shall I just create a MoB testing wiki? 13.33.46 # pondlife: please do :) 13.34.00 # * pondlife does 13.34.23 # I'm implementing jhMikeS's suggestion and then I'll try to investigate your bug reports 13.36.07 # anyone want to lend a few moments to look at my usb code? I'm doing something wrong with the bulk transfer setup, but I can't for the life of me figure out what. 13.36.23 # some extra eyes might help 13.37.04 # and even just the teddybear effect might 13.40.28 # Nico_P: Do you need to wait differently if it's the same file, or another? I'd think that if lots of buffering is needed, it's not th end-of-file that should determine breaks... 13.40.36 Join teddybear [0] (i=c27f0812@gateway/web/cgi-irc/labb.contactor.se/x-9fd1e73e6cf38cd4) 13.40.51 # Zagor: now I'm here. Shoot. 13.40.58 # Zagor: yeah 13.41.01 # pondlife: are you talking about the commit I just pushed ? 13.41.03 # Nico_P: Or maybe I've misunderstood "/* Don't stop buffering if the request is to buffer the same file */" 13.41.37 # I'll throw up a patch in the tracker 13.41.41 # Zagor: teddybear effect? you mean attention? 13.41.47 # teddybear: :-) 13.42.01 # teddybeer? 13.42.02 # Warm fuzzy feeling, from sharing, I'd guess. 13.42.11 # jhMikeS: nah, I mean explaining the code to anyone (anything) sometimes help you understand the issue 13.42.12 # Mmm, midnightbeerfeast 13.42.14 # pondlife: prior to this commit, the buffering loop would stop everytime an event was recevied. if the event was Q_BUFFER_HANDLE for the same handle, it's a waste of time to break the loop, only to call buffer_handle again for the same handle 13.42.26 # Ah, ok 13.42.41 # that's why this check is here 13.42.41 # I assumed it would carry on buffering while there was buffering to be done 13.42.46 # * jhMikeS petur just came up with a nice marketing scheme for an aging population while saving the teddybear industry from extinction 13.43.01 # Hmm. Too bad our i2c expert won't be around this week 13.43.04 # there's a legend an IT support center somewhere had a big teddybear outside their office with a sign "explain your problem to me first", which solved half their issues... 13.43.26 # Scary stuff 13.43.40 # hmmm...usually a smoke does it for me 13.43.57 # pondlife: do you think the comment is unclear ? 13.43.57 # Maybe the bear had a packet of cigarettes? 13.44.11 # Nico_P: Maybe you could explain it a little more.... 13.44.17 # ok 13.44.41 Quit safetydan ("Leaving") 13.44.44 # there is a mention of this in the comment on top of the function though (inc ase you hadn't seen it) 13.44.45 # As soon as I talk about threading code in the kernel IRC usally becomes a teddybear :p 13.44.58 # * amiconn guesses there's a delay missing somewhere, already out of specs in svn but only showing up with buffered writes 13.45.17 # Nico_P: If you don't mind, at some point I'd like to go through playback.c (and buffering.c, although I don't think that'll need so much work) and make sure there are plenty of comments. I'd like you to be involved before you suffer terminal playback.c fatigue. 13.45.21 # Could be in start, stop, or acknowledge, have to read up on i2c :/ 13.45.31 # Nico_P: Which is a very real problem round here :) 13.45.31 # pondlife: no problem 13.45.40 # amiconn: I thought we usually pushed it to the limit SVN 13.45.42 # Zagor: so I'm all ear 13.45.44 # *in 13.46.20 # teddybear: and the other? or did a dog chew that one off? 13.46.46 # teddybear: GodEater_ keeps beating me at arm wrestling, do you know any way I could cheat 13.47.59 # pondlife: drink more beer is the answer! 13.48.07 # Good answer 13.48.28 # pondlife: you mean, good teddybear? 13.48.34 # Of course 13.49.04 # But mainly good beer, bear. 13.49.10 # teddybear: I didn't teddybears talked back. Am I going insane? 13.49.20 # *think 13.50.00 Quit iamben (Read error: 104 (Connection reset by peer)) 13.50.02 # see #7962 13.50.06 # * pondlife went insane way back when, but is better now thanks to his friend, teddybear. 13.50.25 Join teddybeer [0] (i=54bd45af@gateway/web/cgi-irc/labb.contactor.se/x-c1c5127d0c50ee03) 13.51.33 # teddybear: can you write me a prescription for a good phychoactive pharmaceutical? 13.51.37 # * pondlife imagines that the office at Contactor is full of soft toys, all working hard 13.51.47 # Zagor: only for c200? 13.51.57 # skÃ¥l! 13.51.58 # suspects: firmware/target/arm/usb-drv-pp502x.c, prime_transfer() and/or init_queu_heads() 13.52.02 Quit teddybeer (Client Quit) 13.52.17 # barrywardell: only tested on c200 at least. may work for e200 too 13.52.49 # teddybeer...hmmm...yes 13.53.12 # Zagor: what should it do up to this point? 13.53.38 # * jhMikeS supposed he'll just look at FS 13.54.04 # it registers with the host and sends all its' descriptors. so you get the device in lsusb. but it doesn't receive the mass-storage commands (no interrupt triggers) so I'm not getting any further right now 13.54.50 # basically it's about the same stage as the svn usbstack, but I'd like it working a little better before committing 13.55.53 # That patch seems to consist almost completely of removals ;) 13.55.54 # * jhMikeS sees the patch is almost 100% "-" lines 13.55.56 # firmware/usb_core.c does all the top-level stuff (answer config requests), firmware/target/arm/usb-drv-pp502x.c does the chip-level stuff. firmware/usb_storage.c does (will do) the storage stuff 13.56.09 # amiconn: yeah it's quite a lot of - ... 13.57.10 # jhMikeS: would you mind taking a quick look at http://repo.or.cz/w/Rockbox.git?a=commitdiff;h=253f0e81c936f42d1472b0cfa2efe661532242df ? 13.58.54 # the patch file is probably quite messy to read due to all the removals. I recommend setting up and applying it to a svn repo 13.59.52 # * Zagor ponders adding automatic 'diffstat' to flyspray 14.00.05 # Nico_P: yeah, looks good but isn't 10 ticks a long time to pause? 14.00.25 # bbl 14.00.25 Quit qwm (Remote closed the connection) 14.00.36 Join qwm [0] (n=qwm@h38n2fls32o1010.telia.com) 14.00.49 # jhMikeS: He's just reduced it to 1, no? 14.01.22 # I have 14.01.24 # * jhMikeS sees 10 in there 14.01.34 # it's in another commit 14.03.04 Join Mouser_X [0] (n=Mouser_X@67.110.120.36.ptr.us.xo.net) 14.03.29 # * Nico_P now has over 100 commits on the mob branch 14.04.17 Join Llorean [0] (n=llorean@cpe-70-113-103-34.austin.res.rr.com) 14.05.19 Join rogelio [0] (n=rogelio@189.146.222.125) 14.05.59 # Zagor: so usb_drv_int() doesn't get called when it should? 14.07.06 Part rogelio ("Kopete 0.12.4 : http://kopete.kde.org") 14.07.36 # pondlife: have you seen my wiki page edit about how to pull from a rebased branch ? 14.07.59 # No 14.08.05 # JdGordon: Now the sound settings are correct on Player, but battery capacity is backwards... 14.08.07 # I'm just editing a testing page... 14.09.14 # * JdGordon cant win a trick 14.09.24 # (- goes up and + goes down as it should, but the values are in the wrong order) 14.09.59 # pondlife: http://www.rockbox.org/twiki/bin/view/Main/MetadataOnBuffer#Code_from_the_merging 14.10.09 # it seems i may have a genetic desease that means i cant test properly :p 14.10.49 # amiconn: pressing right increases the value... 14.11.04 # weather it goes "up" or "down" is irrelevant when its only 2 rows 14.11.15 # * JdGordon didnt stuff up 14.11.17 # Not here... 14.11.32 # * jhMikeS wonders if some tick tasks polling a USB register could be flubbing things up 14.11.37 # + decreases the battery capacity here 14.12.01 # ..since the list is flipped, which higher values at the top 14.12.16 # unless 2450 is lower than 2400 its working corrrectly 14.12.40 # No, 1950 is lower than 2000 14.12.57 # And other int settings are also reversed, e.g. scroll speed 14.13.16 # one at a time... this makes no sense... 14.13.33 # im pressing right and the cursor is changing to the higher values in the battery capacity setting 14.13.36 Join kugel [0] (i=kugel@unaffiliated/kugel) 14.13.43 # Again - not here 14.13.48 # And I am at svn head... 14.14.10 # ditto 14.14.11 # Or not..lemme check again 14.14.13 # thats fucked! 14.14.26 # I just svn upped, compiled and put it on 14.14.52 # definalty running r15120? 14.15.16 # Nico_P: http://www.rockbox.org/twiki/bin/view/Main/MetadataOnBufferTesting 14.15.39 # Zagor: was your usb code tested on a e200? or just c? 14.15.41 # * amiconn fully rebuilds 14.16.11 Quit jba (Read error: 110 (Connection timed out)) 14.16.48 # JdGordon: barrywardell: only tested on c200 at least. may work for e200 too 14.17.59 # pondlife: nice, thanks :) 14.18.26 # I'm just adding a commit time/date too 14.19.18 # his patch doesnt apply cleanly 14.19.58 # JdGordon: same problem for me here 14.20.03 # pondlife: in case you want to refer to a specific git commit, the date-time or SHA1 hash won't do (because of the rebasing), use the title instead 14.20.20 # OK 14.21.25 # How's that? 14.21.25 # Nico_P: It's possible to download a full diff of MoB from SVN? 14.22.10 # jhMikeS: http://repo.or.cz/w/Rockbox.git?a=treediff;h=mob;hp=master;hb=mob;hpb=master 14.22.20 # Nico_P: How do I access your buffering debug screen? 14.22.25 # I can provide test diffs 14.22.33 # pondlife: system > debug 14.22.46 # Is it only in a debug build? 14.22.59 # I see the usual View audio thread.. 14.23.04 # But nothing new 14.23.15 # shouldn't be, I have it on my gigabeat 14.23.48 Join jba [0] (n=jba@c211-30-160-138.blktn3.nsw.optusnet.com.au) 14.23.57 # Maybe the debug menu has limited capacity? It's not using the Menu API... 14.24.02 # Nico_P: that would be a slick setup to have a "download repository as patch to SVN" link :) 14.25.03 # jhMikeS: actually, http://repo.or.cz/w/Rockbox.git?a=treediff_plain;h=mob;hp=master;hb=mob;hpb=master 14.25.05 # pondlife: are you going to make a forum posting referencing that page too ? 14.25.14 # Not yet 14.25.21 # I think it's more one for devs, not users. 14.25.33 # fair enough 14.26.07 Join FOAD [0] (n=dok@dinah.blub.net) 14.26.12 # amiconn: ? 14.26.23 # Not that I normally want to subdivide, but I don't think Nico will want lots of iPodn00bs reporting intermittent problems at this point...and complaining that rockbox sux0r 14.26.38 # Hmm, I just found a nice bug too 14.26.55 # Will update my build and retest 14.27.09 # JdGordon: you can ignore the failed bits - they're all just removed files 14.27.42 # except the e200 config needs fixing 14.28.08 # ... or not 14.28.12 # GodEater_: have you seen that I found how to pull from a rebased branch ? 14.28.34 # yeah, it does 14.28.45 # just the same as the c200 one 14.28.48 # JdGordon: Now the order is correct, and I'm definitely at r15120 - *But*: 14.29.06 # Now the start position in the list is wrong, i.e. it's not the current value (!) 14.29.45 # Looks like the start position is counted from the bottom, while it needs to be counted from the top 14.30.51 Join tictoc [0] (i=tabac@gateway/gpg-tor/key-0xB9002659) 14.30.59 # k 14.34.18 # and fixed 14.35.24 Quit jba ("Leaving") 14.37.27 # well stuff happened 14.38.20 # is there a way to clear the dmesg log? 14.38.36 # * teddybear was distracted by another talk and lost the course of discussion 14.39.32 # * Nico_P wants to know who teddybear is 14.40.13 # Nico_P: I'm the one you should explain your problem to in order to solve it 14.40.55 # how thoughtful 14.41.21 # 2002-05-03: SOUND! Linus' experimental MAS code has played our first 4 seconds of music. 14.42.12 # Hmm. Our bit-banged i2c seems to bee indeed somewhat qirky regarding timing 14.44.00 Quit teddybear ("CGI:IRC") 14.44.04 # pondlife: you're depressing me 14.44.07 # :) 14.44.14 # Why? 14.44.28 # too many bugs ;) 14.44.34 # I suspect you've already fixed one of them 14.44.42 # which ? 14.44.52 # The hard-lock with long tracks 14.45.02 # Can't repro in the sim 14.45.12 # I was just about to say I didn't have it on my gigabeat 14.45.13 # About to update my H300 14.46.19 # Might be dircache related? 14.46.36 # possibly 14.46.47 # I have that enabled 14.46.54 # me too 14.46.57 # Ah, ok 14.47.19 # No, still locks up on H340 14.47.55 # I'm using "Slow Riot For New Zero Kanada" for my test tracks there if that helps.. 14.48.24 # But any two MP3s that total >= buffer size should do 14.48.49 # I'm trying to repro with exactly that setup 14.49.14 # well not the same test tracks but two bit MP3s 14.49.50 # pondlife: how long in the second track do you skip backwards ? and do you have playlist repeat enabled ? 14.49.51 # barrywardell: sorry for running away. yes usb_drv_int() does get called, for ep0 and reset and everything. it just doesn't get called for ep1 (the bulk endpoint). 14.50.48 # hence I suspect an error in the transfer descriptor setup. but i've gone over them dozens of times, and I'm not seeing the error. 14.51.03 # Nico_P: About 8 seconds into each track. 14.51.10 # ok 14.51.11 # Repeat: All 14.51.44 # I think the playlist reshuffle issue's been fixed... 14.51.51 # But I keep getting hard locks... 14.51.54 Join nicktastic [0] (n=nick@unaffiliated/nicktastic) 14.53.03 # Also the new build has a slient moment shortly after playback starts... 14.53.18 # i.e. it plays the first 3 seconds, then pauses while buffering 14.53.43 # Maybe I should put my config/WPS up somewhere? 14.54.08 # I don't think it's needed 14.54.21 # Well, just in case you can't repro 14.54.31 # Crossfade might be required 14.54.38 # ah I'll try that 14.54.44 # It's locking up on every skip now 14.54.54 # Even when there should be no buffering 14.55.22 # :( 14.55.25 # i.e. Start playback of an album, wait for HD to spin down, then skip forward one track :( 14.56.10 # ouch I just experienced the audio cur after three secs, but only with whit enoise 14.56.31 # it only happends with crossfade enabled 14.57.24 # we use dma for audio on x5 too, yeah? 14.59.19 # Looking a lot better now :) 14.59.30 # Hmm, not heard whitenoise yet.. 14.59.32 # * amiconn wonders how that timing mess had worked 14.59.33 # pondlife: have you rebooted your player ? 14.59.35 # Zagor: just looking over lsusb now... 14.59.48 Quit Thundercloud (Remote closed the connection) 15.00.01 # Nico_P: Well, I updated it in USB Bootloader Mode.. 15.00.08 # ok 15.00.13 # And I've hit reset many times ;p 15.00.18 # And again! 15.00.32 # jhMikeS: I some cases we did flipped SCL twice in succession, without any delay besides the instructions itself 15.00.32 # It locks up just playing now 15.00.39 # *did flip 15.00.54 # Nico_P: Last night's code played pretty well for hours this morning. 15.01.40 # pondlife: you seem to attract bugs 15.01.49 # Indeed. 15.01.56 # That's a skill of mine, I feaer 15.01.59 # fear, even 15.02.12 # I can repro a crash in the sim now, just gdb-ing 15.02.13 # crossfade is working quite well here, apart from the whitenoise issue 15.02.16 # Zagor: those descriptors look fine to me 15.02.18 # cool 15.03.04 # pondlife: the whitenoise seems to occur only when crossfading to a track that wasn't buffered 15.03.11 # ooh, crash 15.03.35 # Sim message : failed to allocate space for metadata Postbuffer:2/5 15.03.47 # It refuses to play long track 2 15.03.50 # barrywardell: I mean the internal transfer descriptors used by the chip to handle transfers. the ones set up with prime_transfer() in usb-drv-pp502x.c 15.04.11 # "failed to allocate space for metadata" is normal, that's what tells us the buffer is full 15.04.20 # ah 15.04.25 # Yes, but it should still allow me to skip to the track, no? 15.04.46 # indeed it should 15.04.50 # Skip back gives the same tagtree_unbuffer_event segfault 15.04.58 # So, maybe these are all the same problem. 15.05.19 # Basically tagtree_unbuffer_event expects the metadata to be around, but id3 = NULL. 15.05.28 # do you use database on sim ? 15.05.45 # I have it enabled, but I was doing a file browse this time. 15.05.47 # pondlife: and could you pastebin the backtrace ? 15.05.55 # Yup, looks the same again though 15.06.08 # I have http://www.pastebin.ca/737328 but the lines seem strange 15.06.25 # http://www.pastebin.ca/737437 15.06.59 # Zagor: but they're working fine for transferring the device descriptors 15.07.29 # Seems like you're unbuffering the metadata before the callback... audio_clear_track_entries() maybe? 15.07.30 # pondlife: yeah, that's just a missing check 15.07.43 # Hmm, shouldn't need a check 15.07.53 # the point of the unbuffer is to wave bye-bye 15.07.58 # yes. but those are transfered on endpoint0, which is of type control. mass-storage goes on endpoint1, of type bulk 15.08.02 # i.e. it shouldn't pass id3=NULL 15.08.15 # This is needed for the database run-time stats 15.08.25 # everything works fine with ep0, but not ep1 15.08.39 # pondlife: on line 2335, tracks[last_idx].id3_hid can be == 0 15.08.47 # in that case bufgetid3 will return NULL 15.08.53 # Which file? 15.08.58 # playback.c 15.10.17 # This happens when the track has already been unbuffered? 15.10.31 # pondlife: it probably never has been buffered 15.10.36 # Ah 15.10.39 # not even the metadata 15.11.05 # Well, that's fair enough then... I suspect that SVN rebuffers at that point 15.11.06 *** Saving seen data "./dancer.seen" 15.11.18 # that's lousy code translation on my part. in the original code the check wasn't needed because metadata could almost always be assumed to be there 15.11.39 # Hmm, need to check all callbacks maybe? 15.11.54 # probably. 15.11.57 # Is there any point in doing a callback with id3=NULL ? 15.12.10 # I doubt it 15.12.31 # Ah, 15.12.46 # I think the fact it crashes kinda proves it :) 15.12.54 # If the metadata's not around, shouldn't it still have the pathname set up? 15.13.04 # i.e. an id3 structure should still exist. 15.13.29 # I think that's how SVN works (from memory) 15.13.42 # the metadata not being there means the buffer was so full there was no room for a struct mp3entry 15.14.01 # in SVN the struct mp3entries were static 15.14.13 # Think of the initial display of next track info - often a WPS will display the next track filename if the actual title wasn't available... 15.14.26 # that's handles by audio_current_track 15.14.30 # handled 15.15.10 # I think we need to have an artificial struct for this purpose too. :( 15.15.22 # Not sure how it can be achieved though. 15.16.09 # I've pushed a preliminary fix 15.18.49 Join desowin [0] (n=desowin@hdp186.internetdsl.tpnet.pl) 15.20.10 # It does seem odd that we're calling an unbuffer callback for a track that has either never been buffered, or already unbuffered... 15.21.20 # Zagor: it does receive on ep1 according to the logf. have you checked what it receives? 15.21.47 # I get nothing. what does the logf line say for you? 15.21.57 # Nico_P: Will test after lunch 15.22.00 # pondlife: I agree it's strange. I'm looking 15.22.03 # ok 15.22.13 # uprime 1(2)rx 10117040 15.22.45 # barrywardell: that's the priming, i.e. assigning of receive buffer. that doesn't not mean it received. 15.22.47 # just after usb_recv 1 512 14V8V8 15.23.12 # 14B8B8 15.23.34 # what you want is "usb comp 2" 15.23.40 # ah, ok 15.23.42 # or what I want, anyway :) 15.24.25 # so it sets up to start receiving, then doesn't actually receive anything 15.24.29 # Nico_P: Sorry, but that still crashes on H340.. :( Now I really must eat. 15.24.32 # barrywardell: are you running this on e200? 15.24.38 # yes 15.24.44 # barrywardell: exactly. no receive interrupt for ep1 15.24.47 # nice 15.24.55 # pondlife: I've pished another similar commit for after your lunch ;) 15.25.30 # Zagor: I'm slowly starting to understand how the code works 15.25.34 Join iamben [0] (n=ben@dpc67142179038.direcpc.com) 15.25.35 # I wonder whether the quirky i2c timing for pcf might even explain the button glitches on X5, M5 and H300 15.25.59 Join Siku [0] (n=Siku@f303b.w3.tontut.fi) 15.26.55 # amiconn: and the (very sporadic) eeprom corruption on h300? 15.27.12 # Zagor: do you know if the interrupt never happens, or does REG_ENDPTCOMPLETED just not get set? 15.27.15 # petur: Is the eeprom hooked to the same i2c bus as the pcf? 15.27.28 # amiconn: I think so, yes 15.27.32 # (i.e. is it using the same bitbanging driver?) 15.27.36 # barrywardell: good point, haven't verified that 15.28.01 # * Zagor adds yet more logf 15.28.17 # The interesting thing is that these quirks weren't introduced with the asm; the C version has them too 15.30.59 # amiconn: I did however close FS#5412 because it was no longer reported 15.31.59 # I'll referify the timing (drawing diagrams), then check the pcf specs again. Perhaps the timing has to be done even more different 15.32.05 # *reverify 15.34.02 # Zagor: gtg now. I'll let you know if I spot anything 15.34.19 # ok 15.34.51 # I found we get a crapload of "start of frame" and "suspend" interrupts I didn't know about. could be to something 15.35.44 # s/be/lead 15.36.11 # you also don't check for bus reset when priming, dunno if that's important 15.36.56 # we should do that, but it's not the problem here. 15.36.58 Nick Tanuva|Zzz is now known as Tanuva (n=tanuva@83.220.128.10) 15.39.13 # wow! 15.39.24 # * amiconn _really_ wonders how this could have worked 15.41.59 Join Rincewind [0] (n=rince@vpnwww01.rz.uni-karlsruhe.de) 15.42.16 # Nico_P: are you here? 15.42.20 # yes 15.42.38 # The pcf driver in svn has several ill-timed spots. When sending, the GETACK SCL high pulse is too short. And when receiving, there are 3 problems in a transfer. (1) The SCL low pulse between START and INB is short. (2) ACK sends the SCL->high transition directly after setting the data line. (3) the SCL low pulse between ACK and STOP is short 15.43.18 # I tried to use your mob branch and I got a few conflicts. Your tree isn't up to date with current svn, right? 15.43.30 # Rincewind: no, not quite 15.43.53 # Rincewind: it's based on r buffer_callback 15.44.00 # oops, I meant r15095 15.44.12 # hm ok 15.44.34 # Rincewind: the raw text diff is here:http://repo.or.cz/w/Rockbox.git?a=treediff_plain;h=mob;hp=master;hb=mob;hpb=master 15.44.36 # then I have to make a branch based on this revision, and pull your remote branch in there 15.44.51 # Rincewind: are you using git ? 15.44.55 # Nico_P: yes 15.45.07 # have you cloned my repo ? 15.45.33 # I cloned your repo, and used git svn rebase from then on 15.45.54 # Zagor: you could also maybe check ENDPTSTAT to see if the priming succeeded 15.45.57 # well even though you've rebased, a simple git checkout -b my-mob origin/mob should do 15.46.38 # barrywardell: good idea 15.48.27 # * barrywardell is really going this time 15.48.33 # jhMikeS: here ? 15.48.41 Quit barrywardell ("using sirc version 2.211+KSIRC/1.3.12") 15.51.01 # Nico_P: I used 'git branch my-mob origin/mob' && git checkout my-mob && git pull. Then I got the conflicts. I tried your method now and it seems to be working 15.51.43 # no need to pull after checking out (which is what you did with your first git branch call) 15.51.53 # though it's strange you got conflicts 15.52.17 # Rincewind: was there some time before you did git pull ? 15.52.36 # but a pull shouldn't do any harm, either 15.52.52 # No, only the time needed to type it in 15.53.20 # now a pull says 'already up to date'. It seems to be ok now 15.53.53 # I have no idea why you got conflicts 15.54.47 # Rincewind: to be on the safe side in case I rebase, you should probably pull with git pull origin +mob:my-mob and then do git remote update 15.55.12 # Zagor: do you know how I can setup a category for the wiki? 15.55.46 # I set --track on the checkout, it should pull from your repo automatically. 15.56.40 # if you rebase it gets messy, you're right. 15.56.46 # markun: it's only search patterns. for example CategoryFrontpage is %SEARCH{"^CategoryFrontpage:.*\[.*Documentation.*]" regex="on" type="regex" nototal="on" nosearch="on" format=" * [[$topic]] - $pattern(.*?CategoryFrontpage:([^\[]*).*)" }% 15.57.00 # heh, "only". but you get the idea? 15.57.03 # ;) 15.57.18 # Well, I did "view raw" and didn't see any of this 15.57.19 # Rincewind: I need to rebase from time to time... if you have tracking set up you might need to ass a plus sign somewhere 15.57.27 # http://www.rockbox.org/twiki/bin/view/Main/CategoryPlugin?raw=on 15.57.35 # s/ass/add... my typos are getting worse 15.57.53 # Zagor: or is it not defined in the wiki itself? 15.58.10 # markun: it's in the page you want to add the category items in 15.58.13 # markun: CategoryPlugin is just an explanation. look at PluginIndex instead. 15.58.53 # Nico_P: If this happens, I am sure that git knows a way to solve it. It is really amazing 15.58.57 # Zagor: ah, ok 15.59.59 # Rincewind: it won't know what to do if I rebase, it'll only know if you tell it the branch may be rebase, and that's with the plus sign 16.00.31 # Rincewind: http://www.kernel.org/pub/software/scm/git/docs/v1.5.3/git-pull.html, the first note 16.00.37 # what I meant was, there is always a way to solve these issues with git 16.00.51 # that's true 16.02.18 Join n1s [0] (n=nils@nl104-209-90.student.uu.se) 16.02.20 Join webguest55 [0] (i=5620ba17@gateway/web/cgi-irc/labb.contactor.se/x-71f5a130c60dfd2a) 16.02.24 # hi 16.02.30 # gotta go 16.02.31 Quit Zagor ("Client exiting") 16.02.31 # petur: The eeprom does indeed share the pcf i2c bus on h300. Go figure... 16.02.40 # does anybody know if there is something for ipod nano 2nd gen? 16.03.01 # i only found 1st gen 16.03.18 # webguest55: No there isn't. It's completely new hardware and no-one is working on porting Rockbox to it. 16.03.20 Quit webguest55 (Client Quit) 16.03.28 # amiconn: I remember guessing it had something to do with the eeprom corruption 16.03.31 # petur: Do you have a way to test eeprom access reliably? 16.03.39 # no 16.03.43 # hmm 16.03.57 # there's the eeprom dump 16.08.10 Quit CaptainSquid83 (Remote closed the connection) 16.08.20 # Looks like the pcf i2c timing is rather forgiving. The minimum clock half-period is 1.25 us (400kHz "high speed") as per specs. The svn driver sometimes generates pulses as short as 0.4 us 16.08.24 Part Benoitb ("Kopete 0.12.5 : http://kopete.kde.org") 16.09.09 # Only going further down (by enabling buffered writes) made it start glitching with a rate high enough to become visible 16.10.14 # Hmm, the start->inb transition was even shorter 16.10.16 Join scorche|w [0] (n=8dc5049d@rockbox/administrator/scorche) 16.13.19 # * amiconn thinks that fix is worth a separate commit 16.14.28 # * amiconn also wonders whether we could even remove the special filtering from those button drivers 16.15.28 Join karashata [0] (n=Kimi@pool1-169.adsl.user.start.ca) 16.20.45 Join daurn [0] (i=daurn@unaffiliated/daurnimator) 16.21.12 Quit atsea-34 (Remote closed the connection) 16.23.12 # was adding files to the wiki disabled? 16.23.29 # I can't seem to find it anymore 16.23.49 # markun: "attach", down the page 16.24.06 # Nico_P: how could I have missed that :) 16.27.02 Join Gursikh [0] (i=khalsa@tremulous/officialdevannoyer/khalsa) 16.27.13 Quit desowin ("use linux") 16.27.15 # picture from the New York meeting: http://www.rockbox.org/twiki/bin/viewfile/Main/RockboxNYC?rev=1;filename=nyc-20071011.jpg 16.27.29 # HI, Just popped in to say "ZOMG Rockbox I love you guys! Keep it up!" 16.27.33 Part Gursikh ("woot rockbox") 16.28.26 # markun: Who is who? 16.28.35 # LTR: Nick, Davide, Melba, Rob, Marcoen 16.28.40 Join atsea-34 [0] (i=atsea-@gateway/tor/x-ee5f4b6122e93a3f) 16.29.17 # Who are Nick, Melba and Rob? 16.29.22 # * linuxstb is bad with names... 16.30.04 # EvilNick, LambdaCalculus379's gf, LambdaCalculus379 16.30.24 # OK ;) 16.31.02 # Are you planning on writing a report from the SoC conference, or did I miss it? 16.31.03 # Origins LTR: UK, Italo american, philipino american, cuban american, german dutchman 16.31.25 # linuxstb: I think it's in the forums. I'll copy paste it in the wiki 16.31.37 # also, I want to make Tower of Rockbox wiki 16.31.47 # we made 2 while I was in the US 16.33.01 # markun: nice choice of beer ;) 16.33.06 # :) 16.33.12 # stella and chimay 16.33.26 # markun: in the forums? 16.34.06 # linuxstb, scorche|w: oops, the SoC doesn't have a report yet 16.34.12 # linuxstb: i was planning on writing a wiki page about it and what we could do better for next year in the next few days 16.34.29 # although petur posted something to the mentor mailing list (right?) 16.34.43 # there is a report in the wiki 16.34.59 # in our wiki? 16.35.03 Quit daurnimator (Connection timed out) 16.35.11 Join PaulJam [0] (i=Paul@vpn-3042.gwdg.de) 16.35.30 # http://www.rockbox.org/twiki/bin/view/Main/GsocRoundup2007 16.36.01 # oh...i was referring to a report on the GSoC mentor summit 16.36.10 # ah... 16.36.12 # and i think the others were as well 16.36.16 # I was. 16.36.26 # * petur walks to the corner 16.36.31 # * markun joins 16.36.35 # * petur bumps GodEater away 16.36.41 # * markun is still too tired. Slept till 14:30 today 16.36.45 # I'm mainly interested in the things we should do better/different next time. 16.36.52 # monday mornings.... 16.37.02 # scorche|w: +jetlag 16.37.08 # * linuxstb feels lonely in the middle of the room and joins everyone else in the corner 16.37.10 # well, since markun and i are here, i suppose we could have an irc chat about it 16.37.33 Join fed [0] (i=63e82710@gateway/web/cgi-irc/labb.contactor.se/x-b4dd3aa335d56b46) 16.37.35 # * Tanuva sits in the opposite corner 16.37.42 # scorche|w: So what things should we do better/different next time? ;) 16.37.47 # some of the tips were related to strictness towards our students 16.38.08 # if they are not making progress after 2 weeks, just tell them it was nice working with them and that they failed 16.38.12 # well, if we are going to talk about it, i think we should move in chronological order 16.38.27 # scorche|w: ok, I'll leave you to it :) 16.38.27 # markun: But then what happens - we lose a project? 16.38.32 # linuxstb: yes 16.38.59 # linuxstb: they also mentioned that if a student isnt up to snuff in the first few weeks, they will try and replace it for another 16.39.01 # I am trying to get the simulator compile, but I keep on getting an error: /usr/bin/ld: warning multiple definitions of symbol 16.39.02 # but they found out from experience that most of the people which don't do anything in the beginning don't do anything the rest of the time as well 16.39.23 # scorche|w: we should also have some kind of selection for our students 16.39.30 # the general theme is that they should follow the typical phrase "commit early, commit often" 16.39.35 # give them a simple task so we know they can do something 16.39.39 # I get this for many symbols. Any idea what I did wrong? 16.39.42 # fed: 1) Did you apply any patches? 2) Try deleting your build directory, and building again from scratch. 16.40.13 # one group had an online php test for their prospective students...many people quite liked that 16.40.18 # markun: Basically what ffmpeg did? Speaking of which, do you have any idea how ffmpeg's SoC went? 16.40.28 Join lazka [0] (n=lazka@83-65-239-109.dynamic.xdsl-line.inode.at) 16.40.37 # I did apply patches. I did try to rebuild and no luck. I try again without the patches. 16.40.58 # i think at the very least, have a dev environment set up...other tests we cna figure out later if we wish for more 16.40.58 # linuxstb: yes, what they did. We were thinking about having them modify a hello world plugin, compile it for a target and send us the .rock file 16.41.38 # I think all of their projects were a success 16.41.42 # as well, one thing that was highly beneficial was, one group emphasized having an intake interview with all students...either on IRC or skype 16.41.45 Quit cendres (Read error: 104 (Connection reset by peer)) 16.41.45 Join ashes [0] (n=ashes@2001:5c0:8fff:ffff:0:0:0:4d) 16.42.02 # also, we think it would be good to have more than 1 mentor per student next year 16.42.23 # a get-to-know-the-community thing and it also serves to see if the student tryly knows what they are talking about 16.42.53 # Same errors with the rebuild. I'll now to start from scratch withtout the patches. 16.42.56 # they are looking at having more than one mentor able to be selected per student int he web app next year, but at least 2 mentors per student was nice as well 16.43.00 # there were some projects which had a interview with the student using VoIP, but I'm not so sure I like that 16.43.19 # markun: yeah...as i said, i think IRC would be fine 16.44.03 Join toffe82 [0] (n=chatzill@h-74-0-180-178.snvacaid.covad.net) 16.44.07 # linuxstb: they also said that if you are very very excited about a project you shouldn't mentor it 16.44.20 # conflict of interest 16.44.24 # so that would have excluded me from text to speech 16.44.32 # I don't understand that logic... 16.44.44 # I also didn't completely get it 16.44.50 # Isn't open source all about scratching your own itches? 16.45.14 # because then you cant objectively mentor the student...you want them to succeed so much, you make too many breaks and give them too many chances when they may not be doing anything 16.45.19 # linuxstb: yes, but GSoC isn't exactly open source 16.45.26 # linuxstb: maybe you'd be tempted do do the work yourself instead of letting the student do it ? 16.45.33 # I mean, people get payed and have deadlines 16.45.39 # Yes, but we don't... 16.45.41 # however, i think it would be fine to ignore that if we paired 2 mentors up woth a student 16.45.52 # scorche|w: true 16.46.04 # Nico_P: what i said above was their logic 16.46.12 # ok 16.46.25 # I think most projects had some problems with people with poor comunication skills. I still don't know what to do with those. 16.46.46 # it is more of a case-by-case basis 16.47.02 Quit JdGordon (Remote closed the connection) 16.47.39 # overall...the big thing was, the whole purpose of GSoC is to get more long-term developers for your open-source project...i think that is a very handy thing to know, especially as we were wondering about their intent 16.47.44 # there was also a lot of talk about svn vs git at the summit (and even the night before in the hotel) 16.47.51 # well, at least their stated intent ;) 16.48.08 # markun: I think that's simply handled by having some strict rules stated at the start - e.g. to be available on IRC for at least X hours per day Monday-Friday. 16.48.21 # linuxstb: yes, good idea 16.48.45 # linuxstb: yes...a thing about "our expectations for the summer of you" at the front was another thing that would be good 16.48.46 # and maybe a fixed time every week 16.49.22 # linuxstb: overall I think we will be much better prepared next year, don't you think? 16.49.22 # a weekly status report can be done by mail IMO 16.49.40 # Nico_P: of in the wiki 16.49.44 # s/of/or/ 16.49.48 # yes 16.49.54 # Would you want to mentor again? 16.50.01 # I think it would be ideal (where possible) to ensure at least one of the mentors for each project is in a similar timezone to the student too 16.50.10 # otherwise keeping up to date on IRC is very hard 16.50.23 # markun: i definitely think so, and am planning on watching over it more closely next year 16.50.58 # GodEater_: that may help, but there is always the 2 mentors per student thing for that...there will always be some overlap 16.50.59 # GodEater_: we could also have a #rockbox-soc wih separate logs 16.51.12 # but maybe not :) 16.51.13 # markun: i dont knwo about that 16.51.17 # yeah - perhaps not 16.51.24 # we want them to be entrenched int he community 16.51.35 # only two from last year are 16.51.44 # and both of them were already here :) 16.51.57 Join Thundercloud [0] (n=thunderc@resnet01.nat.lancs.ac.uk) 16.51.58 # lol! 16.52.05 # after all, as they said, the main purpose is to get us new devs, so we should act that way :) 16.52.09 # tellingly perhaps - they're the projects which did best 16.52.47 # I think the test idea is a good one 16.52.59 # although I think a hello_world plugin is a little trivial... 16.53.08 # linuxstb: also, I think it's better to have non rockbox devs as students 16.53.15 # what would you suggest? 16.53.32 # scorche|w: off the top of my head I have no idea - it bears thinking about 16.53.52 # GodEater_: it's just to make sure they have a dev environment setup and can start working on their code 16.54.00 # i think that would be a decent test 16.54.06 # we dont want to go overboard 16.54.15 # ah well 16.54.18 # perhaps 16.54.22 Nick idnar_ is now known as idnar (i=mithrand@unaffiliated/idnar) 16.54.31 # also, if they are not selected by us they shouldn't have wasted too much time 16.55.03 # that test demonstrates that they can compile, can write code, etc 16.55.17 # although the howto of the hello_world.rock ought to be pulled from the wiki in that case ;) 16.55.25 # too easy to cut'n'paste otherwise 16.55.40 # GodEater_: a modification of it to do something would work 16.55.50 # not necessarily just writing hello world 16.55.58 # 10 Print "markun is cool" ; 16.56.00 # 20 goto 10 16.56.03 # :) 16.56.07 # :) 16.56.53 # perhaps we could just give them the hello world plugin as an example and ask them to use their imagination to make a nice plugin 16.56.59 # you would have to take the helloworld example offline for the time the studend should build that proof of dev-environment :D 16.57.15 # isn't that what I just said ? 16.57.15 # i dont see why we would.. 16.57.37 # me neither 16.58.01 # GodEater_: sure, I just continued that... argh, whats the word in english.. "the path of thinking"... 16.58.02 # Being able to find things in the wiki is a test in itself. 16.58.04 # if I would make a plugin I would also look at the code of existing ones 16.58.07 # wouldn't help much... with the google cache (if they are clever enough) 16.58.43 # linuxstb: true enough :) 16.58.51 # Tanuva: "train of thought" ? 16.59.11 # this isnt about making hello world...this is just about seeing if they can modify code and compile....they can make the text green, or make it scroll around...anything, really 17.00.16 # linuxstb: yes, sounds good :) 17.01.00 # I get the same errors even now that I have done a new svn download into a new directory. This time, it didn't stop at the errors, it is still continuing to compile. 17.01.18 # IIRC, ffmpeg had a few "qualification projects" for their SoC. For example, for someone developing a new codec, we could suggest they implement a codec that plays back raw PCM files (with a hard-coded samplerate, channels etc). 17.01.36 # now that's a proper test 17.01.52 # * GodEater_ would need to do some serious googling to pass it 17.01.54 # For someone starting a new port, maybe get the simulator compiling... 17.01.58 # linuxstb: we could start a wiki for next year and port our ideas there 17.02.03 # post 17.02.17 # linuxstb: which is _really_ easy 17.02.30 # Tanuva: I mean the sim compiling for their new target. 17.02.39 # ah. okay. :D 17.03.48 # markun: I think there already is an SoC 2008 page. 17.03.54 # good 17.03.58 Join Crash91 [0] (n=evil91@196.218.80.108) 17.04.26 # http://www.rockbox.org/twiki/bin/view/Main/SummerOfCode2008 17.04.41 # i dont think that the test should be that hard, but you never know...i think the simple test (which would have helped for one student this year..) and an IRC interview to see if they know what they are talking about/will mesh well with people would be decent before accepting them...i could see a more strenuous test after they are accepted and during the introductory period where we can still ask for a replacement 17.05.49 # it looks like the errors I noted previously weren't responsible for the compiling to stop. The last error was /usr/bin/ld: Undefined symbols: _lcd_enable 17.06.09 # Any I dea how I can fix this? 17.07.05 # I suppose the duplicate multiple definitions isn't a problem. Is it? 17.07.32 # fed: are you building a clean svn source now? 17.07.39 # fed: what platform are you on? 17.07.41 # Done. 17.07.48 Join mf0102 [0] (n=michi@85.127.182.13) 17.07.52 # mac osx 17.08.14 # I don't know anything about that :( 17.08.22 # The clean svn gets the same multiple definitions, but not the missing one. 17.08.39 # can anyone reproduce this? (I can't) http://forums.rockbox.org/index.php?topic=13207.msg100157#msg100157 17.08.53 # fed: have you ran make clean first? 17.09.02 # I did. 17.11.07 *** Saving seen data "./dancer.seen" 17.11.11 # markun: that sounds really weird 17.11.40 # maybe there are old files left from a patch you applied earlier? 17.11.54 # What. The multiple defs or the missing one? 17.12.06 # multiple definitions. 17.12.19 # (what is wierd, that is) 17.12.19 # you could remove the checkout tree and do a fresh svn co 17.12.50 # What is the checkout tree? 17.12.53 # <|Rain|> n1s: by the time I got a chance to try your midi player patch, it no longer applied cleanly 17.13.02 # how did you obtain the sources? From svn? 17.13.14 # Yes. SVN 17.13.35 # |Rain|: it seems like stevenm comitted it to svn so you could test with an up to date svn source 17.14.00 # <|Rain|> aha 17.14.05 # I tried to use fink to install the sdl. It didn't work, so I installed it manually. 17.14.11 # <|Rain|> n1s: wait -- are you sure? only one hunk failed 17.14.12 # well, remove the whole tree and fetch a new one from svn. Maybe there are old files left -- svn revert can't remove added files 17.14.42 # |Rain|: he did it today 17.14.53 # <|Rain|> aha, okay 17.15.01 # <|Rain|> did you get an e200 benchmark yet? 17.15.04 # what do you mean by the whole tree? 17.15.13 # nope, no pp benchmarks at all 17.15.25 # that's why I held off on committing myself 17.15.42 # <|Rain|> looking for the right revision so I can get a good before/after 17.15.45 # the whole sources you checked out from svn 17.15.55 Quit atsea-34 (Remote closed the connection) 17.17.31 # markun: Any update on your SoC student? Is that project officially dead now? 17.21.15 # When I did the clean svn, I still got the multiple def error, but it compiled fine, and the simulator worked. I then applied my patch of all the extras I was using, and the same error that stopped the compiling occured. 17.21.44 # Is there a problem with the multiple def errors if it still compiles? 17.23.08 # linuxstb: I guess it's dead. I didn't even ask about it anymore. 17.23.50 # markun: Oh well... And we still haven't solved the GPLv3 issue? 17.23.57 # nope 17.24.34 Quit Rincewind ("Verlassend") 17.24.58 # karl suggested using a LGPL api file to link the plugins against, but at least amiconn was against it 17.25.14 # s/karl/kkurbjun/ 17.25.57 # But wouldn't that open the door to closed-source plugins? 17.26.17 # Yeah, that's what I'm afraid of 17.26.33 Quit Crash91 ("Bye Bye!") 17.28.14 # I removed lcd_enable from my patch, and now I still get the multiple def errors, but it compiles fine. 17.28.34 # I guess there is a problem with lcd_enable in the sim. 17.28.48 # Should I make a bug reprt about this? 17.29.00 # linuxstb, amiconn: but what's preventing anyone from adding a LGPL api file now and adding some closed source plugings now anyway? 17.29.17 # fed: since the problem is caused by a patch you should report it to the patch authort 17.29.20 # -t 17.30.09 # I personally don't care much about people using rockbox together with closed source plugins/codecs, but I'm a BSD person anyway. 17.31.15 # markun: I'm the opposite... A GPLv3 person... 17.31.20 # One last thing, whould I be trying to fix this multiple def thing, or not worry about it since it seems to work in the end? 17.32.06 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 17.33.51 # fed: if there is a problem with svn code the build table would show it. 17.34.13 # bluebrother: not in the sim builds 17.34.15 # bluebrother: Maybe not if it's an OS X specific Sim issue... 17.34.31 # hmm, ok. Missed the os x part ;-) 17.35.56 # * linuxstb goes home 17.35.59 Quit linuxstb ("Client Exiting") 17.36.53 # where is the build table? 17.37.19 # http://build.rockbox.org/dev.cgi 17.41.16 # I cannot seem to get onto that link. 17.41.31 # works fine here 17.41.36 Quit kugel (Read error: 104 (Connection reset by peer)) 17.42.33 Quit Thundercloud (Remote closed the connection) 17.44.08 Join lee-qid [0] (n=liqid@p54964D74.dip.t-dialin.net) 17.45.45 # Well, thanks. I'll work on this for a bit more. 17.47.08 Quit TMM ("Ex-Chat") 17.49.05 Quit fed ("CGI:IRC (EOF)") 17.49.38 # could any people knowledgable about coldfire dma and audio chime in here: http://forums.rockbox.org/index.php?topic=13254.0 17.49.46 Join Davide-NYC [0] (n=chatzill@user-12hdtj8.cable.mindspring.com) 17.49.52 Quit Davide-NYC (Client Quit) 17.53.35 Join atsea-34 [0] (i=atsea-@gateway/tor/x-eed9c07106e9dcd4) 17.57.01 Join TMM [0] (n=hp@ip565b35da.direct-adsl.nl) 17.57.42 # Urgh, the fm radio driver has a similar problem... 18.04.57 Quit stewball`ghost (Read error: 104 (Connection reset by peer)) 18.09.08 Join Lear [0] (i=chatzill@rockbox/developer/lear) 18.10.57 Quit petur ("work->home") 18.17.54 Join haemmy [0] (n=stefan@194.208.162.140) 18.19.43 Quit obo ("bye") 18.21.05 Join Thundercloud [0] (n=thunderc@resnet02.nat.lancs.ac.uk) 18.22.02 Join bertrik [0] (n=Bertrik_@031-020-045-062.dynamic.caiway.nl) 18.22.11 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 18.26.27 # Wee, fixed. Now radio control works reliably even at 124MHz on H300 :) 18.26.39 # That is, with buffered writes of course 18.27.12 # Hmm, it seems all the arm builds that are slightly bigger than the rest comes from rbclient@deepthought.ena.si which uses gcc 4.0.4 and ld 2.17 18.27.37 # yup 18.27.45 # and the bigger sh builds seems to come from rbclient@ihme.org but that uses the same gcc and ld as the others 18.27.52 # yup 18.28.09 # ah, you already knew that? 18.28.24 # How clever is the buildserver? could it just be set to not send those types of builds to those specific hosts? 18.28.37 # The arm "problem" is obvious. deepthought needs to be brought to the official recommended versions 18.28.49 # However, the SH "problem" is strange... 18.29.09 Join pondlif1 [0] (n=Steve@cpc1-rdng11-0-0-cust362.winn.cable.ntl.com) 18.29.10 # amiconn: why do we recommend 4.0.3 and not .4 ? 18.29.19 Part pondlif1 ("disconnected has pondlife") 18.29.36 # Because that's what was available when switching to 4.0.x 18.29.45 # rasher: I'm pretty sure it's possible 18.30.06 # I guess 4.0.4 isn't well tested for arm rockbox. 4.1.x is known to cause problems 18.30.55 # amiconn: it seems like all the servers will need to rebuild arm-efl-gcc to properly support mrobe and gigabeat s builds so it might be an opportunity to update if that's wanted 18.31.21 # I am running a build compiled under cygwin with arm-elf-gcc 4.1.1 (from gnuarm.com) for sansa e200 and I haven't seen problems yet 18.31.23 Quit jhulst ("Konversation terminated!") 18.31.33 Join linuxstb [0] (n=chatzill@i-83-67-212-170.freedom2surf.net) 18.32.10 # only did about 10 builds until now though 18.32.38 # I don't remember if there were stability problems, or if it was just speed 18.32.46 # I didn't perform the tests myself 18.33.09 # Contrary to what the gcc team promises, newer gcc versions do not always produce faster code 18.33.28 # amiconn very true 18.33.42 # so who owns the deepthought server? 18.33.43 # ok, haven't done any benchmarks 18.34.01 # bertrik: that would actually be quite interesting to see 18.34.16 Join WalterEgo [0] (n=noneofye@modemcable228.133-82-70.mc.videotron.ca) 18.34.30 # please tell me how and i'll run one 18.34.35 Join styleism [0] (n=etm101@87-194-104-214.bethere.co.uk) 18.34.40 # <|Rain|> I had minor stability problems with rockbox compiled with gcc 4.1.x, and I couldn't compile a working bootloader at all due to gcc bugs messing up the FAT code 18.34.41 # n1s: it's ender`s and I stated the same findings here in the channel maybe 2...3 weeks ago 18.35.00 # what's the problem? 18.35.38 # pixelma: ah, ok, maybe we should just ask Bagder to not hand out arm builds to it then... 18.36.07 # Hmmkay.. While I know this is a 'patch' question and thus not supported, I still believe there might be someone on who knows the answer, so.. : Does the album_art patch scans the folder for a .bmp file everytime a new song is played, or everytime the WPS requires it to? 18.36.47 # n1s: what's the problem with my server? 18.37.04 # ender`: your build server is running a different arm-elf-gcc (not recommended version) producing slightly bigger binaries 18.37.18 # hmm, let me check 18.37.23 # ender`: you also use a different ld version 18.37.51 # which versions should be used? 18.38.12 # 4.0.3 and 2.16.1 are recommended 18.38.37 # ok, i'll install that. are any patches needed? 18.38.59 # the thumb-interwork patch for gcc 18.39.22 # http://www.rockbox.org/twiki/bin/viewfile/Main/CrossCompiler?rev=1;filename=thumb-interwork-4.0.3.diff 18.40.10 Quit pondlife (Read error: 110 (Connection timed out)) 18.40.46 # H1x0 radio works too, as does X5 radio :) 18.41.09 Join petur [0] (n=petur@rockbox/developer/petur) 18.41.10 # is the ihme.org sever Slasheri's ? 18.41.15 # yes 18.41.23 # Slasheri: ping? 18.42.07 Quit PaulJam (".") 18.46.51 # ok, binutils installed, gcc is compiling 18.47.23 Join ilgufo [0] (n=matteo@host61-179-dynamic.4-87-r.retail.telecomitalia.it) 18.49.28 # * amiconn still wonders how this i2c could have worked... 18.49.41 Join pondlif1 [0] (n=Steve@cpc1-rdng11-0-0-cust362.winn.cable.ntl.com) 18.49.44 Part pondlif1 ("disconnected has pondlife") 18.50.00 # amiconn: what was the problem with it? 18.50.15 # Wrong timing in several places 18.50.31 # (PCF driver for H300, X5 and M5, and FM radio driver for H1x0 and H300) 18.51.06 # The buggy pcf driver might have been the reason for the occasional button glitches, as well as the occasional eeprom corruption on H300 18.51.50 # button glitch == strange lockups when pressing buttons with backlight off and high load on cpu? 18.51.58 # no 18.52.13 # ok, arm-elf-gcc 4.0.3 installed, too 18.52.21 # ender`: great 18.52.29 # button glitch == wrong button event triggered 18.52.46 # never happened to me 18.53.12 # It depends on the individual units 18.53.15 Join homielowe [0] (n=chatzill@d207-81-67-190.bchsia.telus.net) 18.53.21 # Some are more susceptible than others 18.54.17 Quit homielowe (Client Quit) 18.57.10 Join BigBambi [0] (n=Alex@rockbox/staff/BigBambi) 19.03.51 Quit karashata ("Leaving.") 19.04.00 Join PaulJam [0] (i=Paul@vpn-3042.gwdg.de) 19.05.50 Nick tictoc is now known as imred (i=tabac@gateway/gpg-tor/key-0xB9002659) 19.05.59 Part imred ("Leaving") 19.06.02 # amiconn: i think the button glitches are ( at least on H300) a hardware issue. see also here: http://forums.rockbox.org/index.php?topic=5054.0 19.06.24 # Yes, partially, but most probably not only 19.07.49 # pixelma tried my fix on her M5 (which used glitch a lot) before I committed it, and it improved things 19.09.31 # <|Rain|> n1s: 72 misses (r15111) -> 69 misses (r15112) 19.10.36 # |Rain|: thanks, that is a much smaller improvement than for coldfire but at least it didn't get worse 19.10.53 # PaulJam: I think especially with the X5/M5 joysticks people reported this effect as being stronger than in the original firmware (can't compare personally as I didn't use the OF long enough and there is no dual boot and not much motivation to put the OF back just for comparing this) 19.11.07 Join desowin [0] (n=desowin@hdp186.internetdsl.tpnet.pl) 19.11.08 *** Saving seen data "./dancer.seen" 19.11.33 # but this fix really helped :) 19.11.52 # <|Rain|> n1s: it's possible the pitchbending changes decreased performance as well, my test midi has a lot of them 19.12.33 # |Rain|: ah, I only got a very slight decrease in speed on mine but maybe they don't use it too much 19.13.19 Join Bagder_ [0] (n=daniel@1-1-5-26a.hud.sth.bostream.se) 19.17.36 Quit Nico_P (Remote closed the connection) 19.18.13 Join Nico_P [0] (n=nicolas@rockbox/developer/NicoP) 19.18.18 Join lazka_ [0] (n=lazka@83-65-238-174.dynamic.xdsl-line.inode.at) 19.20.08 Join Limer [0] (i=5ae5c0e4@gateway/web/cgi-irc/labb.contactor.se/x-c2e3d0fe14a2167f) 19.20.09 Quit lazka (Read error: 113 (No route to host)) 19.22.44 Join _Bagder_ [0] (n=daniel@1-1-5-26a.hud.sth.bostream.se) 19.23.08 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 19.23.58 Nick Limer is now known as Limerr (i=5ae5c0e4@gateway/web/cgi-irc/labb.contactor.se/x-c2e3d0fe14a2167f) 19.24.04 # hey 19.24.36 # Anyone up to date on which player is the best for rockbox today if i want good support and lots of storage? 19.26.14 # depends on what you want to do with it 19.26.46 Join obo [0] (n=obo@rockbox/developer/obo) 19.26.59 # I want to listen to music, and need much space(60GB+) 19.28.54 # I have used rockbox for a couple of years on my ipod photo now, but its batterytime is getting really low now :( 19.29.28 # there are replacement batteries available, you know. 19.29.33 # The only 80GB device Rockbox supports is the old ipod video (NOT the new classic). If 60GB is enough, then you'll probably be happy with any of them. 19.30.06 Quit Bagder (Read error: 110 (Connection timed out)) 19.30.27 # iaudio x5, gigabeat f/x are available in 60 GB 19.31.19 # i would also like the player to be quite new, cause it is really hard to find those old players :) 19.31.51 # the iaudio one seems quite ice 19.32.01 # nice* 19.33.25 Quit PaulJam (".") 19.34.17 Join ompaul [0] (n=ompaul@freenode/staff/gnewsense.ompaul) 19.35.20 # unfortunetly i cant find any iaudio x5, they do not appear to be produced anymore :( 19.35.21 Quit DataGhost (Read error: 110 (Connection timed out)) 19.37.16 # apart from the sansa e200 (and possibly c200) range, no rockbox targets are in production any more AFAIK 19.39.21 # :S 19.39.27 # that sucks 19.39.36 # it's the way of the world sadly 19.40.10 Quit Bagder_ (Read error: 110 (Connection timed out)) 19.40.32 # Is there any other opensource project with support for newer players? 19.41.26 Join DataGhost [0] (i=dataghos@ip3e832ea5.speed.planet.nl) 19.41.55 # Or are all manufactors encrypting their firmwares? 19.42.17 # the only other firmware(s) we know of (OSS wise) are iPL, and archopen 19.42.28 # neither of which are supporting "current" models 19.43.55 # That is quite sad tbh :( 19.44.07 # blame the manufacturers 19.44.13 # they don't want people running homebrew 19.44.21 # so they make it harder and harder to do so 19.44.49 # playermodels are only available new for about a year and porting to a new platform often takes at least that long 19.44.55 # Whats up next, do we have to chip our mp3 players like we did with our xboxes? 19.45.54 # even that doesn't help these days Limerr - look at the XBox360 19.45.55 # maybe an open source friendly dap manufacturer turns up one day 19.46.14 # well, those can be "chipped" because they are very similar to, say, a regular computer...on an embedded device such as a DAP, it is a bit different.. 19.46.17 Nick parafin|away is now known as parafin (i=parafin@paraf.in) 19.46.21 # neuros has taken the first step but they didn't get all the way 19.46.51 # GodEater: and openneo 19.47.06 # (a Rockbox fork) 19.47.17 # rasher: isn't that long since dead ? 19.47.43 # GodEater: Not really.. last update in May 19.47.58 # Eh, February.. damn US dates 19.48.11 # that's pretty dead if you ask me :) 19.48.26 # I think their users would disagree 19.48.33 # haha 19.48.50 # lots of people disagree with me sadly 19.49.57 # It looks like i wont be able to find any swedish retailers having the iaudio, any idea wich model to try next? :) 19.50.32 # I'd go with the ipod 5.5G if I were you 19.50.39 # I think it'll be the easiest to find 19.51.14 # I've seen iPod videos available recently, at least on the web. 19.51.29 # how do i tell the differens between the 5.5 and the 6? 19.52.02 # the 6 is made from metal all over I believe 19.52.08 # Video vs Classic should be safe. 19.52.14 # the 5.5G is plastic on front, and metal on the rear 19.52.15 # Limerr: also, the 6G is called "Ipod Classic" 19.52.24 # The 5.5 is "Ipod Video" 19.52.38 # so this should be safe https://www.datorbutiken.com/se/default.aspx?vat=true&Product=IPODVID80WH 19.53.06 # Limerr: yes 19.53.09 # that's a 5.5G 19.53.44 # great :) 19.54.13 # hopefully it has better batterytime than the photo :D 19.54.56 # * GodEater couldn't comment, not owning a photo 19.55.12 # but I find the battery life on my 5.5G more than adequate 19.55.50 # the batterytime is around 40 minutes while in iPL on my photo 19.56.14 # but in rockbox it is better not sure how much better though 19.56.40 # I get 10 hours on a typical day with mine... 19.56.41 # id bet on around 3 hours in rockbox 19.57.00 # nice 19.59.55 # rockbox estimates 4 hours on my fully loaded photo 20.00.01 Join Arathis [0] (n=doerk@p508A6411.dip.t-dialin.net) 20.00.42 # the estimate is not accurate 20.02.26 # since i am using r12 i guess the estimate isnt any good in any way :P 20.02.38 Quit desowin ("use linux") 20.02.43 # r12? 20.03.17 # * GodEater thinks r12 didn't run on ipods 20.03.30 # r12451 20.03.42 # * bluebrother wonders if r12 even run on archos 20.03.47 # doubt it :) 20.03.48 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 20.03.49 # haha 20.03.56 # what a massive rollback it would be if nano build uses 75 MHz, whole 2 lines against head svn 20.03.58 # bluebrother: helloworld maybe ? 20.04.01 # regarding the fs#7510 20.04.05 # I wonder why we make up such nice version strings :( 20.04.19 # haha 20.05.11 # Ave: That isn't a fix though - it's a work around 20.05.35 # yeah I'm aware 20.05.36 # but it works 20.05.54 # currently some percentage of nano users are stuck with a very borked software 20.05.57 # oh, r12 is even only a cvs keyword fix :) 20.06.24 # Ave: but if that workaround is left in the code, no-one will have any incentive to do the fix properly 20.06.36 # last night I built svn head with the said 75 MHz alteration and I'm spiff so far 20.06.42 # yeah ok thats true 20.07.07 # I would certainly do something if I knew what, this is too deep or some such 20.07.28 # I tried the clock skip stuff but that didnt help, atleast not for me 20.07.31 # mail your nano to a dev 20.07.52 # there was atleast one parson on the tracker offering his already 20.08.04 # suppose I could if he bails out 20.08.21 # who was it ? 20.08.26 # and did anyone accept the offer ? 20.08.43 Join fm2 [0] (n=chatzill@83.242.60.178) 20.08.50 # Hello. Which daps are affected by the FM driver fix? All irivers Hxxx? 20.09.36 # the h100 also uses fmradio_i2c.c, so yes. 20.10.08 # * bluebrother wonders what "iriver radio" means :o 20.10.20 # [comment] Comment by Florin Popescu (florinp3) - Thursday, 27 September 2007, 11:24 GMT+2 20.10.28 # I live in the EU and I'm willing to lend my iPod if transport fees can be arranged. I tried contacting amiconn and received no answer, I'll try the IRC tonight. 20.11.17 # thats about it 20.11.19 # ah 20.11.35 # amiconn very rarely reads the forums if that's how he tried to contact him 20.11.52 # I don't recall seeing florin come in here either 20.12.17 # GodEater: tracker ;) 20.12.31 # scorche|w: does he read that? :) 20.12.37 Part fm2 20.13.08 # * scorche|w shrugs 20.13.44 Join Domonoky [0] (n=Domonoky@e180233045.adsl.alicedsl.de) 20.13.44 Quit Limerr ("CGI:IRC (EOF)") 20.14.23 # yeah my lastlog shows nothing 20.14.34 # and I've been here quite some time 20.14.47 Join [Tm]Limer [0] (n=wazzzah@90-229-192-228-no124.tbcn.telia.com) 20.14.59 Nick [Tm]Limer is now known as Limerr (n=wazzzah@90-229-192-228-no124.tbcn.telia.com) 20.15.15 # finally a real irc client 20.16.20 # you mean you don't like telnet for IRC ? :) 20.16.47 # i used the webclient before :P 20.17.16 # i use mirc now, not sure if id call it a real client but anyway ;) 20.17.32 # i wouldnt... 20.17.40 # hehe 20.17.57 # i like xchat, but since it isnt free for windows i use mirc 20.18.13 # ah - you've missed the freebie windows port... 20.18.14 # there are free binaries for windows around 20.18.17 # search for "silverex" 20.18.23 # but this is getting offtopic... 20.18.29 # heh 20.18.35 Join Rincewind [0] (i=u8MIOYeI@nat-wh-1.rz.uni-karlsruhe.de) 20.18.37 # http://www.silverex.org/news/ 20.18.45 # free binaries, woho! 20.19.21 Join BigBambi_ [0] (n=Alex@rockbox/staff/BigBambi) 20.21.23 # oh shit, remember i told you i had full battery on my ipod photo? 20.21.32 # well, it is out now :P 20.21.45 # and i didnt even use it 20.21.50 # just put it on :S 20.22.51 Quit qwm (Remote closed the connection) 20.23.02 Join qwm [0] (n=qwm@h38n2fls32o1010.telia.com) 20.24.37 Join kubiixaka [0] (n=Miranda@mos-81-27-201-28.karneval.cz) 20.25.05 Quit kubiix (Read error: 104 (Connection reset by peer)) 20.25.44 Quit petur ("switching") 20.25.53 Join petur [0] (n=petur@rockbox/developer/petur) 20.26.47 Quit Nico_P (Remote closed the connection) 20.29.07 # Does rockbox support compressed video playback? 20.29.12 # yes 20.29.15 # mpeg2 20.32.22 # wow, real mpeg2. I would still have to scale it down to the the ipods screensize, but i suppose it would be allot faster converting to mpeg2 then the iPL mvpd. 20.34.34 # Do i have to limit frames or can the ipods cpu handle the frameskipping by itself? 20.35.01 # video playback on the ipod video sucks unde rockbox sadly 20.35.09 # the ipod cpu is very poor at keeping up 20.35.19 # Limerr: http://www.rockbox.org/twiki/bin/view/Main/WebHome?topic=PluginMpegplayer 20.35.21 # we recommend the OF for video watching 20.35.25 # GodEater: Photo isn't Video 20.35.40 # amiconn: he's thinking of purchasing a video to replace his dying photo 20.35.47 # ah 20.35.53 # well my photo is quite dead, so i was talking bout the video ;) 20.36.18 # i think the battery is completely dead now :( 20.36.20 # And the Photo already has half-decent video playback, and will become even better in a couple of days, hopefully 20.36.22 # amiconn: did you see the mention earlier of someone sending you one of these buggy nanos ? 20.37.03 # The G5 will also become better, but not as much as the Color, and starting from a lower level 20.37.42 Quit BigBambi (Read error: 113 (No route to host)) 20.39.09 Quit Rob2222 (Read error: 104 (Connection reset by peer)) 20.40.15 # The video only have 1 year warranty, that is quite crappy. 20.44.08 # * GodEater 's video is over a year old now and still going strong 20.44.58 # hehe, but you never know 20.45.27 # I've also abused it chronically 20.45.32 # it's rock solid 20.46.10 Join merbanan [0] (n=banan@83.233.242.209) 20.46.11 Join Limer [0] (n=Limer@90-229-192-228-no124.tbcn.telia.com) 20.46.25 Quit Limerr () 20.46.31 Nick Limer is now known as Limerr (n=Limer@90-229-192-228-no124.tbcn.telia.com) 20.46.42 # Finally i got a real client ;) 20.48.53 Join Nico_P [0] (n=nicolas@rockbox/developer/NicoP) 20.48.54 # you said that already 20.49.04 # hey Nico_P 20.49.16 # hi again 20.49.35 # MoB build has behaved ok today 20.49.38 # no random silences 20.49.45 # but rebuffering has got even slower =/ 20.50.11 # switching from one album to another took nearly 8 seconds 20.50.45 # :/ what commit is it based on ? "Rebuffer after playlist changes" ? and I forgot which target it is 20.52.08 # er - the last one you made on sunday 20.52.55 # probably that one then 20.53.14 # on the other hand 20.53.22 # I can't get the ipod to crash like pondlife can :) 20.53.33 # and I tried REALLY hard :) 20.53.36 # hehe :) 20.54.10 # what was it slow for ? loading an unbuffered track to play immediately ? 20.54.20 # yes 20.54.32 # I was playing one album (all buffered already), and then switched to another 20.54.32 Quit jhulst (No route to host) 20.54.39 # it's one of the things I'm thinking about ATM 20.55.02 # it needed a codec switch too 20.55.05 # I need to be off for a short while, bbs 20.55.10 # ok 20.55.58 Nick BigBambi_ is now known as BigBambi (n=Alex@rockbox/staff/BigBambi) 20.59.51 Join qweru [0] (n=kvirc@bb-87-80-66-156.ukonline.co.uk) 21.03.27 # Hmm... 21.03.50 # * amiconn is tempted to revert the mpegplayer menu + resume commit ... :| 21.04.57 # Would be better if someone with enough mpegplayer clues would fix it though 21.05.44 # There is one more bug in addition to the already known ones: When loading a video, and immediately quitting again via the (annoying) menu, backlight stays on forever 21.07.40 # and boost stays on it seems 21.07.58 Quit kubiixaka ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 21.09.23 # load elephants dream, exit mpegplayer, then check CPU frequency in debug menu: F=80MHz, boost_counter=1 21.09.57 # at least on my sansa e200, tested after a fresh reboot, current build from rockbox.org 21.10.44 # I'll submit a bug report 21.11.10 *** Saving seen data "./dancer.seen" 21.16.17 # GodEater: I'm back with a question 21.16.38 # bertrik: probably valid for all players with mpegplayer (found the bug on M5, has been confirmed on X5, c200 and yours...) 21.16.48 # meaning: swcodec 21.17.09 # GodEater: how do you find the first buffering compared to earlier mob and compared to svn ? 21.20.48 # if nobody is fixing that mpegplayer issue, I found it... 21.22.21 # 1 out of 3, 2 to go... ;) 21.22.30 # ? 21.22.38 # * amiconn is busy checking lcd timings 21.22.48 # both the backlight and the boost issue are the same 21.22.49 # The mpegplayer menu has at least 3 bugs 21.23.01 # Ah, so 2 out of 3, 1 to go 21.23.20 # the funny thing is, the comment above it says not to exit like that beyond that point ;) 21.23.25 # mpegplayer loads the video, then displays the menu, and when starting, buffers a second time 21.25.08 # always distrust code/comments that tells you to do something without explaining why 21.25.36 # it clearly explains why, the person implementing the menu just ignored it 21.25.50 # ah ok 21.28.40 Join Rob2222 [0] (n=Miranda@p54B14E96.dip.t-dialin.net) 21.30.04 Quit Limerr (Read error: 104 (Connection reset by peer)) 21.32.04 # heh, that's quite a quick response, petur! 21.32.43 # my rockbox time was just starting and I thought it was a nice one to warm up ;) 21.33.10 # but now for that file system corruption bug :/ 21.33.59 # I also didn't fix the issue amiconn mentioned although I saw it happen 21.34.19 # * amiconn thinks the menu shouldn't be there :/ 21.35.21 # Imho there should only be a resume request if the file was played before. If not, it should start playing right away 21.35.28 # continuity would be nice. 21.35.36 # and the introduced "Loading..." splash brings back the problem with using mpegplayer and voice 21.36.27 # (at least I saw it on the c200 again) 21.36.30 # I guess that's not due to the splash, but due to the voice disabling now being either in the wrong place, or even being reverted by roolku's commit 21.37.05 # that was discussed on friday (IIRC) 21.37.47 # * petur has no use for mpegplayer anyway 21.38.34 # Well, it's only an add-on for a dap, but if it's there, it should work properly 21.40.14 Join Buschel [0] (n=AndreeBu@p54A3D9FC.dip.t-dialin.net) 21.47.14 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 21.47.48 # ~10 fps is actually quite fine for watching cartoons 21.48.03 Quit w0rd54 (Read error: 113 (No route to host)) 21.49.57 # I think we'll soon have 24fps without skipping on all targets but the Video 21.50.12 Join Jelemonde [0] (i=4a0dd5e8@gateway/web/cgi-irc/labb.contactor.se/x-09d99e3971553bc7) 21.50.17 # hi? 21.50.34 Join w0rd54 [0] (i=blackdev@100mbit.top-site.us) 21.50.56 # amiconn: h300 too? 21.51.03 # Hopefully, yes 21.51.17 # I get 75fps in lcd_yuv_blit() with buffered writes 21.51.18 # that would be a _major_ improvement 21.51.21 # huh... I have a question: Is there a way to open .bmp image with Rockbox (or i need to always convert to .jpg) 21.51.41 # In combination with the asm optimised idct, this should be enough... 21.51.59 # Buffered writes still have some quirks to be ironed out 21.52.02 # Jelemonde: you can open it with rockpaint but i don't think it supports images with larger res than the display 21.52.22 # (like pixel columns vanishing/duplicating on H1x0 and M5 when boosted) 21.52.22 # amiconn: impressive 21.52.30 # i tried but it dont work so i cant open online with rockpaint? 21.52.35 # only 21.52.50 Join Lambuntu [0] (n=bleh@wbr-2310.student.iastate.edu) 21.52.51 # buffered writes? 21.53.14 # I saw some TODOs in the sansa LCD driver about possibly speeding things up by swapping buffers instead of copying 21.53.55 Quit Jelemonde (Client Quit) 21.54.23 Quit n1s () 21.54.51 # That's something else... I'm talking about coldfire targets here 21.55.01 # amiconn: did you port the asm-routines from sansa/gigabeat for this? 21.55.04 # (iriver H1x0, H300, iAudio X5 and M5) 21.55.15 # Buschel: Not yet, but I will 21.55.30 # amiconn: this will supersede my work then ;o) 21.55.43 # OK, i won't mind experimenting a bit with that 21.55.57 # Although, for Video and Color they won't be usable as-is, as the update order can't be switched to dual-line zig-zag 21.56.23 # So the chroma needs to be buffered for the second line 21.56.33 # amiconn: nevertheless, just wrote a comment to #FS 7951 about further potential in the asm-routines. maybe you could also take this into account 21.56.38 # Perhaps it can be switched, but we don't know how 21.56.45 Quit ToHellWithGA ("You know you'll miss me a lot.") 21.57.14 # On Color with type 1 lcd, Nano, and the H10s we do know how, and I will port the routines 21.57.20 # I already used them for c200 21.58.09 # amiconn: the video's LCD-driver has kind of lag as it will need to wait for 14ms before accepting the next screen update 21.58.48 # I know 21.59.09 # I have a Video here for testing (still) 21.59.26 Part styleism 21.59.42 # i searched the web for compatible lcd-controllers 2 evenings... didn't find anything :/ 22.00.02 # You won't find the docs for the Broadcom chip 22.00.31 # Broadcom is very closed regarding docs for their chips 22.00.39 # as PP... 22.00.44 # yep 22.01.14 # What would be also nice to find (and perhaps a bit easier) would be the type 0 controller of the iPod Color 22.01.29 # well, the broadcom headquarters is a few min away... 22.01.31 # Unless they used the PP's internal controller, that is 22.01.32 # ;) 22.02.11 Join Bagder [0] (n=daniel@rockbox/developer/bagder) 22.03.01 # scorche|w: If you go to the broadcom headquarters, give them a kick from me because of the bcm43 wlan chips ^^ 22.03.08 # scorche: You need arguments... ;) 22.03.30 # amiconn, yes, 9mm of argument ;) 22.03.47 # Bagder: I thought you were in China? 22.03.59 # Rincewind: Even their ethernet controller chips are secret... afaik the Linux driver for their gigabit chips is based on pure RE 22.04.15 Nick Tanuva is now known as Tanuva|Zzz (n=tanuva@83.220.128.10) 22.04.43 Quit Lear ("ChatZilla 0.9.78.1 [Firefox 2.0.0.7/2007091417]") 22.04.44 # amiconn: I know, I spent a few days getting my wlan working in my laptop :( 22.04.51 # linuxstb: is he there for work? 22.05.05 # I assume so - he went with LinusN 22.05.06 # in fact, we (fluor) traded them a few buildings, so i was right across the street from the huge broadcom sign a week or so ago 22.05.08 # (the Tigon3 driver - saw that one quite often lately) 22.05.10 # ah, found the blog 22.05.13 Join ]RowaN[ [0] (i=a2b0y@82.43.210.209) 22.05.15 # http://linus.haxx.se/pekingblog/ 22.05.55 # amiconn: you know why we can't do more than 16 bits with coldfire and dma for audio? 22.06.17 # What do you mean? 22.06.28 # markun: That doesn't explain much to me... 22.06.29 # bah...linus's blog is all in swedish...no fun 22.06.34 # The reading side of things, or writing to the i2s buffers? 22.06.50 # amiconn: i don't really know exactly where, that's why i'm wondering 22.07.16 # Well, these are 2 different things 22.07.31 # With DMA, coldfire only allows 16 bit samples. That's unavoidable 22.07.46 # <]RowaN[> Guys I saw this commit of sansapatcher that mentioned overwriting the bootloader in the PPBL section of the firmware. Does this now mean that running the latest PP5022.mi4 rockbox bootloader will now rid me of the "Sansa" splash at boot time? Or have I missed something? 22.08.06 # Meh, and for reading audio, we use AA 22.11.03 # aa? 22.14.21 Quit amiconn (Nick collision from services.) 22.14.27 Join amiconn [0] (n=jens@rockbox/developer/amiconn) 22.17.02 Quit nicktastic (Read error: 104 (Connection reset by peer)) 22.17.08 Join steiner44 [0] (n=steiner4@p54BDE14E.dip.t-dialin.net) 22.17.18 Part steiner44 22.18.09 Quit _Bagder_ (Read error: 110 (Connection timed out)) 22.19.46 Join Alonea [0] (n=chatzill@24-119-114-203.cpe.cableone.net) 22.21.33 # hey guys. my dad wants a new player for Christmas and I was thinking of getting him a Sansa. Is the e280 compatible since the page says e200 series for rockbox? 22.21.41 # Alonea: yes 22.21.58 # yea I use one 22.22.14 # GodEater: sweet. yeah, he seems to like the looks of it so far. 22.22.40 # only difference in e200 series is memory size AFAIK 22.23.01 Quit Xerion (Read error: 104 (Connection reset by peer)) 22.23.07 # How does everyone else like the sansa e280? He doesn't need a monster 20-60 gig player, but needs enough space to put a bunch of music on. 22.23.10 Quit ilgufo ("So Long, and Thanks For All the Fish - http://gufo.wordpress.com") 22.23.24 # Hello. Anyone have comments about http://www.rockbox.org/tracker/task/7958 before i commit it ? 22.23.28 Join Xerion [0] (i=xerion@cp198589-d.landg1.lb.home.nl) 22.24.11 # Alonea: me personally, I don't own one. But I've seen one, and I don't like the buttons. 22.24.48 # hmm, for people who have them, does anyone have any trouble with the buttons? My dad has huge fingers. 22.24.48 # Alonea, i didn't like the buttons at first, but i got used to it 22.25.00 # me either 22.25.12 # I got big fingers but it's manageable 22.25.18 # and I got used to it 22.25.19 # Alonea: I've had mine for 4 days, it's my first mp3 player and so far i like it 22.25.22 # heh. I hated the gigabeat cross until I figured it was more touch and not press. 22.25.33 # indeed buttons are a bit hard to press because of the scrollwheel 22.26.13 # but you get used to it 22.26.15 # the other thing i don't like is the USB/charge plug. I prefer a simpler more standard USB plug 22.26.18 # I did anyway 22.26.21 # hmm. well, he shouldn't have too much trouble. He generally just listens to music and thats about it. 22.26.28 # preglow: DMA Auto-Align 22.26.39 # bertrik: oh? no ac power charger? 22.27.23 # Alonea: no ac charger indeed, mine came with just the USB charger plug 22.27.33 # Alonea: you can get a 3rd party ac-usb charger 22.27.46 # Rincewind: about how much? 22.28.21 # I got one from amazon for 12€ (in germany) 22.28.26 # amiconn: right, yes 22.28.26 # dionoea: didn't look at the code, but sounds ok to me 22.29.03 Quit mf0102 ("dormire maintenant, desolee") 22.29.03 # ok 22.29.07 # dionoea: if it works as advertised I'd like it, because I found with the current implementation that there is a difference if the track to be moved will be placed before or after the hovered track (new placement) depending on if you move up or down 22.29.17 # It works as advertised :) 22.29.54 # (at least it does when i test with my dummy alphabet playlist) 22.30.52 # * preglow reads the last line of mrh's dma doc with puzzlement... 22.31.03 # Rincewind: ok, thanks. I might look one up for him. 22.31.14 # * dionoea commits it then 22.32.03 # it's an anagram for reverse engineering! 22.32.06 # * preglow solved it! \o/ 22.32.18 # I posted my first bug fix, #FS7831, I'd be interested in any comments or suggestions on it 22.32.49 # ]RowaN[, it appears to not be the case. the sansa splash still comes up, and i just compiled the bootloader from svn. 22.33.09 # <]RowaN[> hmm thanks. mysterious times 22.33.28 Join stevenm [0] (n=stevenm@129.2.201.58) 22.33.39 Join Xerion_ [0] (i=xerion@cp198589-d.landg1.lb.home.nl) 22.34.08 # hello, people 22.34.12 Quit Xerion (Read error: 104 (Connection reset by peer)) 22.34.13 # dionoea: Did you test in a player sim (just curious how it feels compared to the old method - I rarely use the playlist viewer, and even more rarely for editing the list) 22.34.53 # * amiconn is pondering to commit buffered writes for coldfire 22.34.55 # Well too late for testing :) it's commited 22.35.05 # amiconn: what's keeping you from doing so? 22.35.12 # Seems to work nicely now, with all sorts of I/O seeing considerable speedups 22.35.32 # amiconn: ata? 22.35.40 # markun: I don't wnat to break something or cause instability 22.35.48 # jhMikeS: could the gigabeat benefit from write buffering? 22.35.48 # how odd, you can't get an extended warranty if you get the combo with a free case... 22.36.06 # preglow: Works, verified with my 300MB test file method at 124MHz on H180, H340 and X5 22.36.44 # amiconn: any noted performance gains? 22.37.06 # I didn't compare ata performance, but there should be some 22.37.27 # I probably should... 22.37.29 # * amiconn is curious 22.37.38 # well, i think so... :) 22.37.59 # anyway, if it's not too complictad and has no other side effects, i'd just say commit 22.38.01 # LCD profits considerably. lcd_yuv_blit() on H300 goes from 54fps to 75fps 22.38.04 # but sure would be nice to have some performnac efigures 22.38.20 # wow! 22.38.34 # what I wanted to say ;) 22.38.42 # H300 lcd_update() doesn't profit, as that uses DMA. On X5, lcd_update() profits too 22.38.48 # oh, that reminds me, i should check out bushel's newest lcd_yuv_blit patch 22.39.02 # Isn't that just C? 22.39.13 # preglow: Buschel is around at the moment... 22.39.55 # just added some comments on the yuv-sutff 22.39.57 # *stuff 22.40.23 # I'll do an ata perf comparison on coldfire, then commit buffered writes 22.40.39 # he is indeed! 22.40.45 # After that, I'll take a look at asm idct for mpegplayer on coldfire 22.41.15 # Next will be lcd_yuv_blit() in asm for H10 22.41.27 # Buschel: did you ever hear anything more from moos? 22.41.43 # Then color/video. After that, I'll play with the color lcd bridge. 22.41.48 # preglow: he tried to contact me yesterday. but i missed him 22.42.19 # That second colour should be colour ;) 22.42.58 # blah 22.42.59 # amiconn: be sure to make the asm easily portable to nano :P 22.43.11 # preglow: color and nano share a driver 22.43.49 # But if we can't determine what the type 0 color lcd controller is, it might be useful to split them, and make the Nano driver more similar to H10 22.44.16 # (Nano is always type1, i.e. HD66789R, which is known) 22.44.22 # really, now 22.44.38 Quit ompaul (Read error: 104 (Connection reset by peer)) 22.45.55 Join ompaul [0] (n=ompaul@freenode/staff/gnewsense.ompaul) 22.46.50 # dionoea: nice commit. I wanted to test the patch but you were quicker :) 22.47.36 # bertrik: about how long does it take to charge? 2 hours? 22.48.08 # Alonea: don't know, haven't allowed it to completely run down or charge fully yet 22.48.10 # GodEater: how do you find the first buffering compared to later ones, earlier mob code, and svn ? 22.48.25 # first buffering is good 22.48.30 # better than svn I'd say 22.48.39 # ok so it's in the rebuffering somewhere 22.48.41 # bertrik: ^__^. My gigabeat only takes a couple hours to charge most of the time. probably about the same. 22.50.12 # Woohoo! mega green delta 22.50.35 # (except for the player ... but it's not like anyone cares) 22.51.06 # nice... better usability with less code :) 22.51.35 # preglow: do you have any news from moos? 22.51.36 # markun: didn't you swap the gigabeat buttons so that usually "Power" is used to quit plugins (not "A"? 22.51.42 # dionoea: You forgot to bump the plugin min api version... 22.51.45 # Alonea: battery is 750 mAh and max charge current is 500 mA, so yeah something like a few hours sounds reasonable 22.51.50 # amiconn: did that 1 second ago :à) 22.51.53 # :-) 22.52.20 # bertrik: alrighty. methinks daddy is getting one for christmas then. 22.52.51 # * amiconn wonders what a selected lune is and guesses that the removed code was written by JdGordon ;) 22.53.09 # pixelma: I forgot at least a few 22.53.13 Quit Rincewind (Remote closed the connection) 22.54.40 # markun: yes, e.g. demystify (uses plugin button actions...) - found that while filling out button tables in the manual(s) and seeing that a lot are empty for the gigabeat too 22.55.18 # I try to solve that too where I see it's missing 22.57.41 # markun: so, should I already state that it is "Power" in advance - or use "A" as it currently is? 22.57.48 Quit merbanan (Remote closed the connection) 22.57.51 # Nico_P : I know you've moved on to other, more important things, but may I ask you for a quick answer to a very easy question (I guess) about the album_art patch..? 22.58.07 # Buschel: nope 22.58.14 # pixelma: power and fixing code would ideal :) 22.58.20 # +be 22.58.26 # WalterEgo: ask away, but I'm not sure I'll be able to answer 22.58.35 # ..namely, if a WPS doesn't use album_art tags at all, does it still access disk, preload image, and such..? 22.59.06 # WalterEgo: I'm really not sure anymore, but there's a chance 22.59.39 # best thing to do is look at the patch and right now I really don't have time 22.59.54 # hmmmkay.. Thanks a lot anyway. 23.00.20 # I'm just looking at saving battery energy wherever I can. :p 23.00.23 # WalterEgo: you're welcome ;) hopefully the AA patch doesn't have long left to live anyway 23.00.40 # WalterEgo: to save power don't use AA ;) 23.00.43 # preglow: Around 14% speedup for ata writes. Reads are unaffected 23.01.33 # markun: I have no target to test on :P 23.01.53 # (measured on H340) 23.01.57 # Nico - That's understood. I guess I'll have to compile my own build to get most wps goodies *without* AA.. Off to reinstall that virtual machine thing.. 23.02.06 # Nico - Merci. :) 23.02.43 # pixelma: simulator? :) 23.02.52 # WalterEgo: de rien :) 23.03.17 # would be nice if there was a current sense resistor somewhere to help predict current power usage and remaining battery life 23.03.56 # markun: and I can't do too much at once. Also I don't want to do much with plugin button actions (and still wait for a discussion/solution/decision about them)... 23.04.24 Join EnterUserName [0] (n=dave@pdpc/supporter/student/GeekZoid) 23.05.13 # pixelma: I'll try to fix it later then 23.05.15 # dionoea: A better solution would be to nor start at 0 with the rectangles. This makes no sense anyway 23.05.35 # I have that locally, but didn't have enough time to check it on my various targets :/ 23.05.44 # arf :/ 23.05.50 # well i'll let you commit the correct fix then 23.06.03 # I mean not start at 0 with the loop 23.06.08 # can anyone with a sansa test my suggestions about yuv-blit speed-up for the arm-based code (#FS 7951)? 23.06.09 # Saves the 2 if()'s 23.06.34 # Buschel: The sansa arm lcd_yuv_blit() is jhMikeS's work 23.06.38 # i'm sure that the time spent in the if()s can be neglected compared to lcd updates :) 23.06.41 # jhMikeS: ping... 23.06.41 # ahem, asm-based 23.06.48 # dionoea: true 23.07.26 # amiconn: gnip 23.08.10 # icmp redirect to Buschel @ fs #7951 23.08.58 # jhMikeS: didn't your X5 also had the famous joystick problem? 23.09.00 # markun: perhaps if it has that sort of write buffering. 23.09.24 Quit haemmy () 23.09.33 # pixelma: yes. that's the first problem I had. 23.09.59 # amiconn's fix today really made things better 23.10.03 # Try the latest svn... it should significantly reduce the glitching, if not fix it completely 23.10.26 # * jhMikeS thought pixelma was talking about the fact that they break. 23.10.57 # I didn't know it was broken... 23.11.12 *** Saving seen data "./dancer.seen" 23.11.39 # it's not now. 23.13.02 # amiconn: my glitching was never very bad actually but I'd get an occasional hop up when pushing down 23.13.26 Quit Alonea ("ChatZilla 0.9.78.1 [Firefox 2.0.0.7/2007091417]") 23.13.53 Join [IDC]Dragon [0] (i=0c182f0a@gateway/web/cgi-irc/labb.contactor.se/x-2192a77c926ef9ec) 23.14.00 # * jhMikeS tests an SVN build 23.14.19 # jhMikeS: If you check the logs, you'll see that I wondered (and still wonder) how these bit-banged i2c drivers could have worked... with several wrong timings... 23.14.26 # Buschel: can i help testing? i have a sansa e200 23.14.40 # But now I'm about to commit buffered writes :D 23.14.52 # jhMikeS: on my M5 "right" was often interpreted as "select", making bubbles very hard... 23.14.54 # amiconn: should I wait? 23.15.16 # <[IDC]Dragon> hello rockbox world! 23.15.19 # pixelma: that would be very annoying. mine was a bit liveable at least. 23.15.48 # * [IDC]Dragon went over to the dark side 23.15.53 Join kkurbjun [0] (n=kkurbjun@alamode.Mines.EDU) 23.16.02 # <[IDC]Dragon> ...and got an iPhone 23.16.09 # amiconn: are you around? 23.16.15 # yes 23.16.24 # kkurbjun: Iirc you have a Mini G1? 23.16.42 Part Domonoky 23.17.00 # amiconn: yes I do 23.17.07 # yay! 23.17.14 # what were you looking for on it? 23.17.17 # [IDC]Dragon: first you neglect to tell us you were in silicon valley, now you are getting an iphone?....what next?!? 23.17.25 # jhMikeS: can explain better, I think :) 23.17.59 # <[IDC]Dragon> scorche: calm down, next I buy a Sansa 23.18.00 # kkurbjun: one more player with a PP502x has to be converted to packed samples ... and that's what you have. 23.18.31 # Ok, so you just want me to change that set of defines? What's the benefit of packed samples? 23.18.47 # 1/2 the interrupts. immunity from channel swapping. 23.18.47 # and what am I looking for when I change the define? 23.19.16 # dionoea: seen FS#7967 ? 23.19.22 # in pcm-pp.c and i2s-pp.c add your player to those lists. hopefully FIFO_FORMAT_LE16_2 will work for it too. 23.20.02 # bertrik: in fs #7951 i mentioned a possible speed-up of yuv-blit for sansa. maybe you can change and test it? 23.20.13 # I suppose it should play fine and record fine if it has that. One good test of each should be enough. 23.20.30 # I mean, what behavior on the player am I checking for? Is it a situation where itwill or it won't work, or is there some stability testing that needs to be done? 23.20.31 # Only play... Mini has no recording 23.20.51 # Buschel: ok, you mean the change in lcd-as-c200.S? Is that asm also used for the e200? 23.20.52 # kkurbjun: yes, it just plain will or won't work. 23.21.26 # great, I'll do that when I get a chance, I'm not by my player at the moment - possibly later today. 23.21.26 # I don't know how to benchmark it, but I can tell you if it works or not 23.21.55 # Buschel: c200 *very* probably won't see any further speedup in lcd_yuv_blit() 23.22.01 # [IDC]Dragon: what are you doing in silicon valley? Or was that only for getting an iphone? ;-) 23.22.13 # kkurbjun: ok, thanks. Then all that can be collapsed down to #ifdef PP502x 23.22.21 Quit petur ("reboot: ubuntu stopped using my mouse :( *kicks linux*") 23.22.23 # The calculation is already significantly faster than the wait for the bridge to become ready 23.23.00 # Note that this applies to the c200 *only*, not any other arm target 23.23.30 # s/arm/colour pp/ 23.23.34 # bertrik: as far as i understood, yes. maybe i should just post a untested patch there? 23.25.09 # Nico_P: nope. Should i check if it still happens? 23.25.19 # <[IDC]Dragon> bluebrother: I'm working, our headquarters are in Sunnyvale 23.25.29 # Buschel: I think i can fix it myself without a patch. Amiconn: do you think it's useful to test it? 23.25.30 # Nico_P: I think that the list display refresh i added might have fixed it 23.25.46 # (Else the displayed list was always one keypress late) 23.25.50 # <[IDC]Dragon> that company bought us in the beginning of 2007 23.25.56 # dionoea: well maybe tell that to the reporter and ask him to update 23.26.05 Quit stevenm ("Connection reset by beer") 23.26.09 # ah, I knew I read something ... 23.26.20 # <[IDC]Dragon> you did? 23.26.20 # so the iphone is not the reason ;) 23.26.28 # <[IDC]Dragon> nope 23.26.44 # <[IDC]Dragon> I was never up to one, actually 23.27.09 # <[IDC]Dragon> but I learned it has WLAN and is good for a couch browser 23.27.31 # Buschel: just pointing out that amiconn is talking about the c200 Sansa and maybe you mean the e200? 23.27.32 # <[IDC]Dragon> (I almost got an iPod Touch instead) 23.27.36 # Nico_P: done. 23.27.51 # so ... when do you start porting Rockbox to it? ;-) 23.28.14 # <[IDC]Dragon> when that guy comes back with the datasheets ;-) 23.28.28 # hasn't an exploit been found to run homebrew on the iPhone and iPod Touch ? 23.28.37 # <[IDC]Dragon> yes 23.29.20 # <[IDC]Dragon> it would be nice to go without iTunes 23.29.31 # <[IDC]Dragon> this software sucks 23.29.41 # is there any chance of it being remotely applicable to the nano 2G and later ? 23.29.49 # (it == the exploit) 23.30.06 # <[IDC]Dragon> I have everything neatly sorted in folders (even with covers), but it ignores it all 23.30.12 Join ddalton [0] (n=daniel@203-214-50-20.dyn.iinet.net.au) 23.30.13 # not from what i can tell, nico_p 23.30.20 # pity 23.30.26 Part ddalton 23.30.39 # Buschel: I think the new .S did not even get assembled 23.30.41 # <[IDC]Dragon> and relies on my medicrce ID3 tags only 23.30.54 # <[IDC]Dragon> mediocre 23.31.17 # <[IDC]Dragon> resulting in a real mess 23.31.38 # GodEater: do you remember of a time when buffering wasn't as slow ? I'm thinking of bisecting 23.31.51 # <[IDC]Dragon> maybe there are better 3rd party iTunes import tools 23.34.19 # ah I see, I should modify lcd-as-memframe.S, right? It has the exact same code sequences 23.35.25 # bertrik: just added the patch... 23.35.55 # amiconn: I just looked, in an SVN sim, sizeof(struct track_info) == 1268. 32 times that is 40576. Divide that by 24 (which is sizeof(struct track_info) in the MoB code) and you get 1690. 23.35.57 # Buschel: i have a e200, not a c200 .... 23.36.37 # * bluebrother gets quite tired all of a sudden and wonders why 23.37.11 # amiconn: so I'm thinking maybe I could set MAX_TRACKS to 256 or maybe even 512 but that already seems way overkill to me 23.38.12 # betrik: hmm, i think the patch could be ported... but not today. gotta got to bed now, will be a long day tomorrow :/ 23.39.06 # bertrik: the code sequences seem to be the same at a first glance 23.39.33 # indeed, the dithered version seems different though 23.39.35 # Nico_P: I think it should depend on the amount of target memory then. And of course the buffering code needs to handle the case that the IDs are used up before the whole buffer is filled 23.40.28 # amiconn: it does, I checked today. It stops buffering nicely and rebuffers when needed 23.40.30 # I'll try just the undithered version then. Mpegplayer should show it if works, right? 23.40.38 # ok 23.41.01 # bertrik: yes. but it's easier to test with the test_fps plugin 23.41.07 # amiconn: and yes, for now MAX_TRACKS is 32 on lowmem targets and 128 on others. We'll just need to find good comprimises 23.41.18 Join Bagder_ [0] (n=daniel@1-1-5-26a.hud.sth.bostream.se) 23.41.30 # Buschel: sorry, not familiar with that plugin, is it in the standard set of plugins? 23.41.54 # I'd use 4 per MB RAM, with a lower limit of 16 tracks 23.42.19 # That'd be 64 for X5 and M5, 128 for most other targets, and 256 for the 64MB ipod video 23.42.53 # Archos will get 16 when switching playback engines later 23.42.53 # bertrik: you will have to enable it in apps/plugins/sources via adding the line "test_fps.c" 23.43.03 # (due to the set lower limit) 23.43.07 # never mind, i get assembler errors 23.43.31 # bertrik: :/ 23.43.40 # amiconn: SPCs are always 64kb, if I understand correctly, so it'll be known that if someone shuffles a collection of them you can fit four times as many as the limit you just suggested. 23.43.48 # http://pastebin.ca/737957 23.44.03 # Buschel: Note that the c200 and e200 code don't use the same asm routines yet; c200 only has the non-dithering variant atm 23.44.19 # amiconn: I was thinking maybe we could use them as a lower limit for software codec targets. 23.44.30 Quit ompaul (Client Quit) 23.44.59 # KB rather 23.45.17 # amiconn: things seem much better with the joystick. no glitch yet 23.45.23 # The advantage on c200 will be that dithering will come for free, fps wise 23.45.31 # jhMikeS: yay! ;) 23.45.42 # Did you see my update to LcdFrameRate? 23.45.59 Join _Bagder_ [0] (n=daniel@1-1-5-26a.hud.sth.bostream.se) 23.45.59 # 114.5 fps for YUV on X5 at 124MHz :) 23.46.08 # say what? 23.46.56 # so the load now is basically just decoding 23.47.34 # yup 23.48.10 # too many bits in constant i think 23.48.43 # The framerate there on ED is much better. I didn't measure. Too obvious. 23.49.10 # Now we need that asm idct... 23.50.11 Join Davide-NYC [0] (n=chatzill@user-12hdtj8.cable.mindspring.com) 23.50.17 # I think it could play that one full speed. 23.50.27 # bertrik: don't know :/ maybe someone with bettere knowledge of asm can pick the idea at least... 23.50.53 # I am hoping for full speed on H300 as well... 23.51.39 Nick parafin is now known as parafin|away (i=parafin@paraf.in) 23.52.10 # bertrik: sorry to waste your time. and thanks for your testing :) 23.52.25 # np :P 23.52.35 # bye 23.52.39 Quit Buschel () 23.53.39 # bertrik: what's that build? 23.54.14 # Does the (very) recent coldfire commit affect recording in any way? 23.54.15 # build? you mean the pastebin text? 23.54.16 Quit BHSPitMonkey (Connection timed out) 23.54.36 # bertrik: yes 23.54.45 Join webguest98 [0] (i=4a469ecd@gateway/web/cgi-irc/labb.contactor.se/x-e30ec66017ec2e40) 23.54.53 Quit lee-qid ("aufwiederbyebientotsayonara") 23.55.05 # Davide-NYC: it's a system-wide change. It should speed things up if anything. 23.55.07 # an attempt to patch lcd-as-memframe.S with the changes from FS#7951 23.55.09 # i read somewhere that sansapatcher works on e200r now. Is that true? 23.55.24 # * Davide-NYC dons his testing helmet 23.55.38 # Davide-NYC: hi! 23.55.44 # he 23.55.49 # ho 23.55.54 # jhMikeS: right now we only use buffered writes for the framebuffer 23.56.24 # markun: very nice meeting you face2face the other day 23.56.26 # why is the Y-16 removed? that's incorrect 23.56.27 Quit webguest98 (Client Quit) 23.56.34 # markun: Nope, for anything 23.56.43 # amiconn: for the Gigabeat I mean 23.56.47 # ah 23.57.28 # Davide-NYC: Did you observe problems? I wouldn't expect any... 23.57.32 # amiconn: can I just turn it on for everything without any penalty? 23.57.44 # jhMikeS: I don't know, I haven't studied the patch yet, just tried to see if it would apply 23.57.44 # Davide-NYC: yes, I enjoyed it too 23.57.57 # * jhMikeS doesn't know why the YUV formulas are being altered in that patch. they are correct now. 23.57.58 Quit Bagder (Read error: 110 (Connection timed out)) 23.58.02 # markun: Depends. I don't know the gigabeat architecture. Some delay loops might need recalibration 23.58.02 # Davide-NYC: http://www.rockbox.org/twiki/bin/viewfile/Main/RockboxNYC?rev=1;filename=nyc-20071011.jpg 23.58.12 # amiconn: I'm still at compiling 23.58.18 # (damn games!) 23.58.34 # pfft 23.58.35 # * markun waves good night 23.58.35 # Cheers! 23.58.49 Join Bagder [0] (n=daniel@rockbox/developer/bagder)