--- Log for 09.05.109 Server: lindbohm.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 1 month and 22 days ago 00.00.08 Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) 00.04.44 Quit DeeboiFresh (Read error: 110 (Connection timed out)) 00.05.13 Join SirFunk_ [0] (n=Sir@208.15.25.145) 00.06.49 # linuxstb : both bswap.h are needed (one is included in bitstream.h, the other in intreadwrite.h) 00.07.53 # but I think both could use one just one file 00.09.27 Join SirFunk [0] (n=Sir@208-15-25-145.netsync.net) 00.11.58 # linuxstb : both files are needed just for now, later libavutil will all be dropped. 00.12.45 # OK. 00.13.32 Quit bertrik (Read error: 113 (No route to host)) 00.16.31 Join atrus [0] (n=atrus@S0106001ee57a9819.ed.shawcable.net) 00.18.39 Quit jgarvey ("Leaving") 00.19.50 Quit SirFunk__ (Read error: 110 (Connection timed out)) 00.21.32 # linuxstb : patch sent 00.24.30 Quit SirFunk_ (Connection timed out) 00.35.36 # mt: Did you send me the right file? It includes "Makefile", not "Makefile.test". 00.36.18 # mt: Sorry, ignore that, I think it was me confusing the files... 00.37.04 # linuxstb : OK , (pheww .. !) 00.42.42 *** Saving seen data "./dancer.seen" 00.42.54 Join CaptainKewl [0] (i=jds@207.237.172.77) 00.43.49 Quit midijunkie ("?(???~•~)?") 00.47.26 Join Thundercloud_ [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) 00.49.43 Quit Thundercloud (Read error: 104 (Connection reset by peer)) 00.49.52 Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) 00.58.26 Part atrus ("Ex-Chat") 00.59.28 Quit _synergis (Remote closed the connection) 01.02.35 Join _synergis [0] (n=christof@cant.be-arsed.co.uk) 01.04.30 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 01.04.55 Quit Thundercloud_ (Read error: 54 (Connection reset by peer)) 01.05.17 Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) 01.06.45 Quit fyrestorm (Read error: 54 (Connection reset by peer)) 01.09.48 Join fyrestorm [0] (n=nnscript@cpe-24-90-84-236.nyc.res.rr.com) 01.10.58 Join wincent_balin [0] (n=wincent@dyndsl-091-096-000-117.ewe-ip-backbone.de) 01.14.58 Quit kachna|lappy (Remote closed the connection) 01.15.17 Join kachna|lappy [0] (n=kachna@r4ax178.net.upc.cz) 01.17.51 # mt: I've cleaned up avcodec.h - it simply needed most of the file surrounding by a single #if 0, rather than all those commented-out lines. http://linuxstb.cream.org/rockbox/avcodec.h 01.19.49 # mt: There are still two unused vars in main() - I think they need to be surrounded by #ifdef DUMP_RAW_FRAMES (filename and fd_out) 01.24.53 # those vars are already used and surrounded by dumo 01.25.04 # *dump_raw_frames 01.25.37 # I guess the warning is due to dump_raw_frames being not defined. 01.26.22 Quit blithe (Read error: 131 (Connection reset by peer)) 01.27.16 # Why are you using the bitstream.c from libwma, and not the original? 01.28.01 # because it was already modified for use with rockbox and compiling outside ffmpeg 01.29.45 Join Makuseru [0] (n=max@163.106.40.24.aeneasdsl.com) 01.30.44 Quit Makuseru (Read error: 104 (Connection reset by peer)) 01.32.21 Quit robin0800 (Read error: 54 (Connection reset by peer)) 01.33.09 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 01.35.23 Join Darren415 [0] (n=DarrenMR@cpe-74-78-172-134.buffalo.res.rr.com) 01.36.00 # hi 01.37.00 # mt: I'm probably going to commit your code soon, but with less changes than your patch compared to ffmpeg. But we can work on it some more tomorrow, and hopefully commit the rest of your work. 01.37.36 # Im having a problem, I installed Rockbox and it says to restart with menu/select then select/play but when I do select/play it says OK to disconnect. 01.38.25 Quit z35 (Read error: 131 (Connection reset by peer)) 01.38.34 # Darren415: That's an Apple message, and it also means "OK to connect". 01.38.50 # linuxstb : okay .. good night 01.38.50 # so I should connect it back to my computer? 01.39.14 # Yes, and fix the problem described - I'm guessing it couldn't find rockbox.ipod ? 01.39.17 # mt: Goodnight. 01.39.47 # I couldnt get it to install the bootloader. 01.39.55 Join z35 [0] (n=z35@h250.118.131.174.dynamic.ip.windstream.net) 01.40.02 # Until I dled ipodpatcher.exe 01.40.11 Join Makuseru [0] (n=max@163.106.40.24.aeneasdsl.com) 01.42.19 # So what am I doing wrong? 01.43.53 # What was the error message? 01.44.22 # exactly as you said, it couldnt find rockbox.ipod 01.44.43 # Did you install Rockbox, or just run ipodpatcher? 01.44.58 # I thought I had installed Rockbox. 01.45.44 # So you just ran ipodpatcher? 01.46.40 # I ran ipodpatcher, and I installed rockbox and the the bootloader 01.46.57 # How did you install Rockbox? 01.47.26 # Im doing it again, its going alot slower then I remember. 01.47.33 # Its the second tab, bottom button. 01.47.51 # So you're using Rockbox Utility? 01.47.59 # yeah 01.48.30 # Are you on OS X? 01.48.37 # XP 01.49.03 # OK, there are some known issues with ipod installs on OS X, that's why I asked. It should be fine on XP though. 01.50.46 # do they need to be installed in a specific order? 01.52.27 # No, but if you install the bootloader without Rockbox itself, then you'll get the error you saw. So it's suggested to install Rockbox itself first, then the bootloader. 01.53.39 # so should I reinstall the bootloader? 01.55.07 # No, the bootloader is working fine. 01.56.16 # Ok I did the install for rockbox and I get that error still. Im sorry Im so hopeless at this 01.56.19 Quit einhirn (Read error: 104 (Connection reset by peer)) 02.04.53 Quit amiconn (Nick collision from services.) 02.04.55 Join amiconn_ [50] (n=jens@rockbox/developer/amiconn) 02.04.56 Join pixelma_ [50] (n=pixelma@rockbox/staff/pixelma) 02.04.56 Quit pixelma (Nick collision from services.) 02.05.15 Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) 02.05.16 Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) 02.05.55 Quit froggyman ("CGI:IRC (EOF)") 02.06.00 Join froggyman [0] (n=47ba40e2@gateway/web/cgi-irc/labb.contactor.se/x-d30228cf316fc9cd) 02.06.31 Quit Seed ("cu, Andre") 02.08.01 Part domonoky 02.12.02 # I keep getting the same error. 02.16.19 Part toffe82 02.21.13 # what .zip program do you use on XP? The built-in one or something else like WinZip or WinRAR? 02.21.19 # rar 02.21.33 Quit Makuseru ("Konversation terminated!") 02.21.49 # The automatic installation fails ever time I try. 02.21.58 # just download the appropriate .zip file, and extract it to the root of your iPod. 02.23.45 Quit froggyman ("CGI:IRC") 02.24.57 Join Makuseru [0] (n=max@163.106.40.24.aeneasdsl.com) 02.26.56 # if I open the ipod folder there is a .rockbox folder and the rockboxutility.exe 02.27.53 # "the ipod folder" being the root directory of your iPod? 02.28.00 # e: 02.28.57 Quit Makuseru (Read error: 104 (Connection reset by peer)) 02.30.00 Join Makuseru [0] (n=max@163.106.40.24.aeneasdsl.com) 02.30.56 Quit Makuseru (Read error: 104 (Connection reset by peer)) 02.41.28 # no matter what I do I get the bad checksum error 02.42.34 Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-9dd72c3010645107) 02.42.43 *** Saving seen data "./dancer.seen" 03.02.38 # "the bad checksum error"? 03.03.04 # you say that as if you had mentioned said problem before. 03.04.24 # New commit by 03dave (r20882): Initial commit of the minimal set of ffmpeg (r18079) files required for Cook (realaudio) decoding. These are the unmodified versions from ffmpeg, ... 03.05.05 # yeah like linuxstb said before it cant find rockbox.ipod says bad checksum 03.05.51 # Darren415: No, it won't say that. Read what it says exactly - it's important! 03.08.19 # ok I uninstalled, and started over. now when I menu/select then select/play it still gives me Ok to connect 03.08.44 # but before if I only menu/select then it would give me that cant find rockboc.ipod 03.09.14 # What's the _exact_ error message the ipod displays? 03.10.27 # after the select/play it says "OK to disconnect" 03.12.37 # No, before that - when you press menu/select 03.12.38 # If it matters its a 1st gen nano 03.13.01 # Now it boots up like normal. 03.13.13 # When you press menu/select you're rebooting your ipod, and the Rockbox bootloader runs. This is what displays the message about rockbox.ipod 03.19.33 Join hasmind [0] (n=hasmind@reserved-62-103.grapevine.net.au) 03.21.53 # New commit by 03dave (r20883): The first part of Mohamed Tarek's Google Summer of Code work to implement RealAudio support in Rockbox. This is a self-contained Cook decoder using ... 03.22.58 # * linuxstb congratulates mt on getting code committed before SoC formally starts... 03.23.59 Quit hasmind (Client Quit) 03.25.05 # yes very impressive work 03.25.28 Quit Thundercloud (Remote closed the connection) 03.28.40 # got it 03.31.52 # do I put files on it the same way as before? 03.37.34 Nick JdGordon is now known as JdGordon|afk (n=jonno@rockbox/developer/JdGordon) 03.44.27 Join toffe82 [0] (n=chatzill@ppp-71-142-14-235.dsl.frs2ca.pacbell.net) 03.47.44 # how do I research the database? 03.54.08 # have you read the manual section on it yet? 03.54.29 # doing that now 03.55.36 # it only shows how to have it auto update. 03.57.08 Part wincent_balin ("Kopete 0.12.7 : http://kopete.kde.org") 03.58.08 # You must be reading a page I haven't seen. 03.59.04 # 4.2.3 Auto Update 03.59.05 # If Auto update is set to on, each time the player boots, the database will automatically be updated. 04.01.11 # Darren415> it _only_ shows... 04.01.32 # That is the page I've never seen. Just keep reading and _then_ feel free to ask questions. 04.07.55 Part Darren415 04.31.40 Quit Lss (Read error: 104 (Connection reset by peer)) 04.31.56 Join Lss [0] (n=Lss@cm7.delta91.maxonline.com.sg) 04.39.28 # scorche and/or Llorean and or (well, neither of the old world admins are around) - http://forums.rockbox.org/index.php?action=profile;u=22789 04.39.46 # cute 04.40.19 # did you just want his displayed name changed? 04.40.36 # I wanted to put it up for discussion, yes. 04.41.06 Quit miepchen^schlaf (Read error: 101 (Network is unreachable)) 04.41.19 # how about I change it to LilFurryBunbuns and send him a PM to change it to something decent? 04.42.44 *** Saving seen data "./dancer.seen" 04.44.17 # furries freak me out. 04.45.31 # same....but still... 04.46.10 # In all seriousness, I think that is the best course of action. 04.52.36 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 05.08.10 Quit intrados_ (Read error: 104 (Connection reset by peer)) 05.08.41 Quit _lifeless (Read error: 113 (No route to host)) 05.16.53 Quit gevaerts (Nick collision from services.) 05.17.04 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 05.20.27 Join intrados_ [0] (n=intrados@71.67.129.220) 05.28.56 Join Tristan [0] (i=tristan@i.dont.want.to.die.virgin.net.in) 05.35.48 Quit intrados_ (Connection reset by peer) 05.40.37 Join robin0800 [0] (n=quassel@general-kt-199.t-mobile.co.uk) 05.45.48 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 05.46.43 Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-0e9549d77f8c0f3c) 06.02.02 Join intrados [0] (n=intrados@cpe-71-67-129-220.woh.res.rr.com) 06.02.12 Quit KBH (Read error: 110 (Connection timed out)) 06.08.31 Quit z35 (Read error: 54 (Connection reset by peer)) 06.09.25 Join z35 [0] (n=z35@h250.118.131.174.dynamic.ip.windstream.net) 06.10.54 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 06.11.27 Join perrikwp [0] (i=4aa794a0@gateway/web/ajax/mibbit.com/x-1f6c0bb948c3b798) 06.22.07 Quit robin0800 (Connection reset by peer) 06.42.48 *** Saving seen data "./dancer.seen" 06.49.22 Join Sharn [0] (n=brandon@dsl-216-128-235-45.teton.id.tetontel.com) 06.49.28 # Is there anyone here who knows about compiling for a Cowon D2? I'd like to help out keeping patched original firmwares up to date 06.49.41 # (And yes, before anyone mentions, I know it's an unsupported platform) 06.58.35 Quit CaptainKewl (Read error: 110 (Connection timed out)) 07.04.03 Join AndyIL [0] (i=AndyI@212.14.205.32) 07.16.09 Quit BHSPitLappy (Remote closed the connection) 07.17.46 Quit AndyI (Read error: 110 (Connection timed out)) 07.21.31 Join blithe [0] (n=blithe@blakesmith.me) 07.25.15 Join Makuseru [0] (n=max@163.106.40.24.aeneasdsl.com) 07.26.26 Join _lifeless [0] (n=lifeless@188.16.105.180) 07.27.16 Join bertrik [0] (n=bertrik@87.211.49.117) 07.29.02 Quit z35 ("Leaving") 07.32.15 Quit Makuseru (Remote closed the connection) 07.40.31 Join __lifeless [0] (n=lifeless@188.16.102.184) 07.42.56 Quit _lifeless (Read error: 60 (Operation timed out)) 07.53.36 Join Horschti [0] (n=Horscht@xbmc/user/horscht) 07.54.09 Join Traveler6 [0] (n=traveler@CPE-69-23-137-242.wi.res.rr.com) 07.54.31 # unused variables are still instantiated in rockbox plugins, right? 07.56.09 # yes I think so 07.56.51 # alright, just making sure I don't have to worry about running out of memory down the line when I start using such variables 08.01.00 Part toffe82 08.08.25 Quit Traveler6 ("Java user signed off") 08.08.49 Quit dude187 ("Leaving") 08.10.30 Quit Horscht (Read error: 110 (Connection timed out)) 08.23.19 Join lucent [0] (i=lucent@unaffiliated/shadows) 08.37.19 Quit Lss (Read error: 110 (Connection timed out)) 08.42.50 *** Saving seen data "./dancer.seen" 08.57.20 Join Rob2222 [0] (n=Miranda@p4FDCD4D8.dip.t-dialin.net) 09.12.37 Join flydutch [0] (n=flydutch@host219-166-dynamic.15-87-r.retail.telecomitalia.it) 09.15.13 Quit Rob2223 (Read error: 110 (Connection timed out)) 09.27.37 Join daurn [0] (n=daurnima@unaffiliated/daurnimator) 09.31.30 # New commit by 03unhelpful (r20884): Split 8-bit-to-native conversion in bmp.c into a function, add support for plugging unscaled output in BMP and JPEG loaders, use output_row_8_native ... 09.33.27 Join moos [0] (i=mustapha@85.169.144.190) 09.36.28 Join homielowe [0] (n=ce748e82@gateway/web/cgi-irc/labb.contactor.se/x-e0b824c9d9c1980d) 09.41.27 Quit homielowe ("CGI:IRC (EOF)") 09.42.50 Quit daurn| (Read error: 110 (Connection timed out)) 09.52.50 Join tvelocity [0] (n=tony@adsl22-78.her.forthnet.gr) 10.22.49 Quit martian67 (Read error: 104 (Connection reset by peer)) 10.23.49 Join martian67 [0] (n=martian6@about/linux/regular/martian67) 10.33.20 # amiconn: hrm... i *tried* inlining output_row_8_native, and it reduces the delta to almost nothing if nothing else wants the function. i could try inlining it if neither HAVE_JPEG nor HAVE_BMP_SCALING are defined. 10.33.38 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 10.38.23 Quit Horschti ("Verlassend") 10.40.39 Join Grahack [0] (n=chri@ip-194.net-82-216-197.nantes.rev.numericable.fr) 10.42.53 *** Saving seen data "./dancer.seen" 10.45.48 # linuxstb , saratoga : Thanks :) (I was asleep when I received those messages) 10.47.04 Join firedix [0] (n=firedix@201.254.117.70) 11.03.55 Join schrottplatz [0] (n=max@f053226142.adsl.alicedsl.de) 11.09.02 # I vaguely remember talk about experiments being done on hacking the WPS to use it for the radio screen 11.09.35 # does this ring a bell to anyone, or does anyone have more info (or even an experimental patch) for this? 11.13.12 Quit intrados (Connection timed out) 11.15.52 Quit Tristan (Read error: 104 (Connection reset by peer)) 11.16.52 # bertrik: I'm not sure it ever got past theory 11.18.03 # Basically, there seem to be three proposals. 1) Try to automatically use existing WPSes (use things like the Album and Artist tag for station name and station frequency, etc), 2) use the existing wps, but have a FM conditional and fm-specific tags so it's still one file, but with unique tags for the radio, or 3) Have a completely separate WPS file for FM 11.18.23 # Of course, 2 and 1 could be combined as well 11.18.26 Join Tristan [0] (i=tristan@i.dont.want.to.die.virgin.net.in) 11.21.19 # Llorean, thanks, I found a thread about it on the forums 11.22.18 # my current opinion is to re-use the existing WPS (option 1 or 2) 11.22.47 # That's what I prefer too. 11.24.05 # and I see JdGordon| has been working on this, I'll ask him when he wakes up 11.33.10 # I'm not so familiar with the WPS code yet, I looked a bit at it last night. In a very basic form, we could just start the WPS upon entering the radio screen and use track change events with fake id3 data to display the currently tuned station 11.33.36 # we would also have to handle keys in a way appropriate for radio of course 11.35.38 Quit moos (Read error: 145 (Connection timed out)) 11.37.25 # on fuze 8gb, the wheel light flickers pretty crazy with m4a playback 11.38.00 # could be wrong about that 11.40.49 # Unhelpful, some jpeg album art looks way too big now on my e200 11.41.57 # lucent: Problems with the incomplete port should go in the thread. 11.42.56 # * lucent pokes to find the thread URL 11.43.49 # It's where it's been the entire time the port's been going on, and I'm sure I've told you to post problems in it before. It's in the new ports forum. 11.44.22 # bertrik: what do the keys have to do with what is displayed on the screen? IMO only reusing existing WPS code won't work completely - e.g. what would you use to let preset/scan mode display, or in case of the Archoses the current radio screen displays prerecording or recording time (because you can record directly from the radio screen and I still hope it will be on swcodec targets someday too) 11.44.37 # whoa, chill baby. I'm looking for it 11.45.23 # I'm pretty pleased with rockbox on the fuze, just noticed the quirky wheel light flickering 11.45.40 # pixelma: That's why a combination of 1&2 would be good. Un-adapted WPSes would work minimally, while adapted ones would simply be better 11.45.49 # pixelma, I'm not claiming to have thought out a fully functional impementation :P 11.47.08 # well, I also was only saying what came to mind after reading this - just things to consider 11.47.11 # As far as I understand, the wps code also handles keypresses that happen in the wps which cause a call to audio_next for the forward/back buttons for example 11.47.41 # bertrik: interesting. it *should* only be taking the "don't use scaler" branch after testing that the decoder will output exactly the desired size. :/ 11.48.46 # bertrik: really? Sounds somehow nasty - from a non-coder point of view 11.50.27 # the radio screen has a few unique buttons (like the mode switching, or mute, stuff like that) 11.50.38 # Llorean: what more does sansa fuze target need for inclusion in rockbox releases? 11.52.58 # pixelma, yes it looks like there are a couple of hard links to the playback code. Not sure yet how those special radio buttons would have to be handled. 11.53.35 # Also there are RDS targets to consider - so far only gigabeat S 11.54.08 # lucent: Not to freeze up during playback, an installer incorporated into rbutil, a finished manual. It basically needs to be working at the level of the other supported ports. 11.54.21 # my gut feeling is that radio using the WPS can be made to work in a basic form and that we can tackle the other problems as we go 11.54.25 # It'd be nice to link up station logos to presets as "album art" also 11.54.48 # lucent: Is Rockbox stable enough to replace the original firmware for day-to-day music playback? Plus we need safe, user-friendly installation procedures. 11.55.22 # I'm using it for day to day playback, since the fixes for mp3 playback went int 11.55.28 # it doesn't freeze on me 11.55.34 # what about other codecs? 11.55.39 # and all other apsects? 11.55.48 # FLAC, m4a, mp3, vorbis, ape, are all working 11.56.05 # no more funky weird pixels on the screen, 11.56.07 # lucent: So you would consider it as stable as, for example, the e200 port? 11.56.19 # lucent: look at the gigabeat S - that is far more advanced, yet still isn't quite finished as far as supported status goes 11.56.24 # yeah I haven't been able to make it crash 11.56.44 # * Llorean knows that as of shortly after the "mp3 fix" there were still playback problems on other AMS Sansas, at least 11.57.11 # that's not to say that all fuze models work 11.57.52 # there seemed to be subtle differences between 8gb and 4gb fuze, but I never confirmed beyond that the issues I had with 8gb fuze are resolved 11.58.36 # lucent: even if it is as stable as the other suported targets, there still remains easy, safe installation and a manual 11.58.57 # BigBambi, nice idea about using the station logo as album art 11.59.18 # bertrik: ... yes, that test is completely wrong, and it will basically always decode jpeg with at the next (2^N)/8 size up from the requested one :/ 11.59.23 # okay a manual, I could help with that... about the easy safe installation, what's the criteria for that? 11.59.43 Join moos [0] (i=mustapha@rockbox/staff/moos) 11.59.45 # lucent: Basically, rbutil integration is ideal. 11.59.50 # aye 12.00.07 # The only time it should ever be something other than that is if for some reason that's impossible. 12.01.09 # So who knows about editing english.lang? 12.01.46 # I want to correct a couple of spellings - do I change just the dest and voice - or do I change source too, which then means changing all the other language files to match? 12.02.42 # http://www.rockbox.org/tracker/task/10185 aha 12.02.55 # BigBambi: Rasher seems to be the best person to ask. 12.03.15 # if you change the source you don't have to change all other languages, but it's needed to show up as difference when running genlang, so translators will notice 12.03.21 # Llorean: Yeah, but he isn't about much - I was hoping someone else might know too :) 12.03.43 # pixelma: I'm only changing spelling - e.g. center to centre, so no meaning will change 12.03.46 # BigBambi: tools/langtool.pl should be able to fix source in lots of languages at once 12.03.52 # lucent, are you still seeing issues with the RTC on your sansa fuze? 12.03.56 # rasher: aha :) 12.04.04 # Check the diff before you commit though 12.04.19 # bertrik: not sure I had issues with RTC :/ did I? 12.04.25 # rasher: So it is best to change all in english.lang, then use langtool to change the source line in the other langs? 12.04.48 # BigBambi: Yes. As long as you're not changing the meaning of the string 12.05.08 # No, no meaning change - just a couple of US - UK spellings 12.05.15 # lucent, there was some weirdness regarding the date/time shown in the OF and the date/time shown in rockbox 12.05.17 # BigBambi: yes, I just meant that if you don't change source in the other languages with it - it will show up as difference and translators will notice that source changed and can adapt (one by one) 12.05.42 # bertrik: oh I can check for this 12.05.59 # pixelma: ah right - well in this case as there is no change in meaning I can do as rasher suggested and save them work 12.06.02 # bertrik: Wasn't that just because the e200v1 used a different offset, and we hadn't adjusted for the offset the AMS Sansas used? 12.06.08 # * Llorean seems to recall that being fixed some time back. 12.06.38 Join ender` [0] (i=krneki@foo.eternallybored.org) 12.07.42 # bertrik: 4am as seen by RB <=> 8am as seen by OF 12.07.56 # confirming the weirdness, I suppose? 12.08.29 # Llorean, yes a fix was committed, but there were somehow still problems with time set in the OF not correctly transferring to rockbox or the other way around 12.09.36 # bertrik: if I set from OF, it shows up in RB okay 12.09.52 # bertrik: with the wrong date, I think 12.10.22 # bertrik: what information can I provide to help? 12.10.30 # New commit by 03unhelpful (r20885): Fix test for direct JPEG output, bump plugin API as r20884 changed struct custom_format. 12.10.56 # lucent, can you add your finding to FS#9985? 12.10.59 # bertrik: that one fixes it for me. 12.11.17 # * lucent pokes internets 12.11.27 # Unhelpful, ok, thanks, I'll test it right away! 12.14.27 # bertrik, 12.15.22 # grr-enter-key. anyway, no hurry, it was a very, very obvious mistake, calculating a valued and forgetting to compare it to another, turning the test into a test for whether the jpeg output dimension was non-zero 12.15.58 # bertrik: method to dump RTC value read from rockbox side? so I can compare against what I see from OF side? 12.16.15 # the patches in SVN confuse me a bit now what to report 12.17.28 # Unhelpful, thanks, album art seems to work fine now (scaled properly) on my e200 12.19.35 # lucent, never mind the RTC dump, do you see the same behaviour as the comment by fragilematter from 12 april 2009, 20:23? 12.20.56 # bertrik: I think so, I cannot be certain because he doesn't provide a test procedure. I will add a comment with a test procedure to reproduce the symptom 12.23.04 # I'm beginning to think that the OF doesn't really change the RTC time when changing the date and time. Maybe it just assumes the RTC runs in UTC and stores only an offset to the RTC time. 12.23.15 # Set date "May 09 2009 04:18" from OF. Read date "Aug 09 2009 04:19" from RB. Set date "May 09 2009 04:18" from RB. Read date "Feb 06 2009 04:17" from OF. 12.23.26 # that's what I found now 12.31.08 Join intrados [0] (n=intrados@cpe-71-67-129-220.woh.res.rr.com) 12.32.09 # New commit by 03unhelpful (r20886): Inline output_row_8_native when building bmp.c in core without HAVE_JPEG or HAVE_BMP_SCALING. 12.32.15 # New commit by 03unhelpful (r20887): Don't build 16-point IDCT on greyscale targets, since it's only used for chroma components. 12.39.17 # bertrik: I think I agree with you 12.39.24 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 12.39.31 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 12.40.06 # bertrik: OF *must* be saving an offset, but not modifying the actual value 12.41.07 # bertrik: that may be by design - doesn't subscription-based DRM require a non-user-modifiable, so that it can know for sure if your license file is expired? 12.41.24 Quit firedix ("Ex-Chat") 12.41.43 # Unhelpful, yes, sounds plausible 12.42.55 *** Saving seen data "./dancer.seen" 12.43.59 # if you look at the motorola source for razr2v8 there is an implementation of the WM DRM clock 12.46.23 # so do we want to avoid setting the RTC? matching it with a procedure that updating the RTC from rockbox causes the OF to match? 12.46.41 # not sure where to go, presuming that it's an offset only in the OF 12.48.11 # We do have a policy of not making Rockbox dependent on the OF. 12.48.44 # Besides, once you set the time/date in Rockbox, and then adjust it in the OF, it should match from there on out, right? The offset should at that point be nearly 0. 12.49.19 # adjusting the date that way doesn't quite work, I think 12.49.44 # I wish it did 12.49.48 # yeah, I'm inclined to not make any further changes to the rockbox RTC code 12.50.17 Join mirak [0] (n=mirak@85-170-144-34.rev.numericable.fr) 12.50.23 # rockbox cannot know the OF time offset anyway 12.51.34 # FWIW when I "overflow" my fuze OF date, it resets to jan 1 1970 12.51.37 # not 1980 12.52.47 # beyond this it is just material for the manual, cannot set RTC using OF, big fat warning that setting date from RB might hose your DRM songs on OF 12.54.11 # New commit by 03alex (r20888): Correct a couple of spellings (US to UK). 12.56.55 # There is a similar offset in the H300 OF, which rockbox does account for 12.57.13 # lucent, I agree, and as Llorean said the time set by RB should now quite closely match the time that the OF expects 12.57.22 # If it wouldn't, the OF would see an out-of-range date in its sanity check, and reset the RTC 12.57.33 # amiconn: The offset changes when the time's updated in the OF, rather than the RTC time itself? 12.57.46 # ? 12.58.17 # amiconn, I think we did see some sanity-check reset too on the sansa ams targets, before we switched to using 1970 as start-of-time for ams 12.58.35 # We're not *exactly* matching that offset though, due to programmer silliness at iriver. They chose an offset of 35 years, making leap years not work 12.59.19 # We use an offset of 36 years, so that OF and rockbox will disagree by one year, but leap years will work 13.00.12 # uh, oh - not that -ise vs. -ize thing again 13.00.57 # why? 13.01.16 # It is quite clear - UK english uses ise, and Rockbox uses UK english 13.01.47 # "Initialize" doesn't exist in UK English 13.02.58 # See firmware/common/timefuncs.c 13.03.32 # because I remember quite long discussions , someone (linuxstb?) found a quite official source which said -ize was possible too. Would need to dig through the logs but that will be hard with those "keywords" 13.03.45 # I think the discussions were related to the manual 13.03.46 # It is "possible" but not standard 13.04.03 # Standard UK English uses -ise 13.04.19 # I'd brefer -ise too, but thought we settled for that one 13.04.24 # prefer too 13.04.49 # I don't see why we should be wrong for the vast majority of people just because -ize isn't strictly outlawed 13.04.52 # unfotunately I don't remember the details, quite a while ago 13.06.03 # BigBambi: http://svn.rockbox.org/viewvc.cgi?view=rev&revision=12778 13.06.18 # If "ize" is technically legal in some areas, and the only legal one in others, while "ise" is only legal in a subset of that total area, doesn't that mean "ize" is *right* for the majority? :-P 13.06.27 # In spite of that, don't really care about this one. 13.06.36 # If people really want -ize they can have a US english 13.06.38 Part Llorean 13.06.46 Join Llorean [0] (n=DarkkOne@rockbox/administrator/Llorean) 13.06.53 # Llorean: That doesn't matter at all, given that is it UK English :) 13.06.55 # and the previous revision - discussion must have taken place around that time 13.07.05 # pixelma: Yes, I didn't know about that 13.07.17 # BigBambi: Didn't we just establish, "ize" is also UK English? 13.07.24 # Still - to my eyes and I suspect the vast majority of British people, -ize looks wrong 13.07.27 # Llorean: see link 13.07.31 # Llorean: It is allowed, but not standard 13.07.48 # So saying it's "wrong" is incorrect, though. 13.07.58 # wrong in most people's eyes 13.08.02 # It looks wrong 13.08.32 # Looks wrong is different from being wrong. People spell things incorrectly all the time because the right way looks wrong. 13.08.42 # we can go on changing it back and forth and call that "people are still developing" when there are no other commits ;) 13.08.42 # I'm just saying, be careful with your reasoning for doing things. 13.08.45 # Yes, true - but not the same thing here 13.09.03 # If it's technically correct, you're changing it "to be the more common usage" rather than "to be right" 13.09.12 # * domonoky thinks that if we care about "most people" we should write chinese :-) 13.09.51 # domonoky: Most people in the language in question, which here is UK English :) 13.09.57 Quit mirak ("Ex-Chat") 13.10.17 # Llorean: It isn't technically incorrect apparently, but it is in modern usage 13.12.00 # Anyway, if people really want I can live with -ize (even though I don't like it) - center was what I really wanted to change :) 13.17.55 # lucent, now that we have an explanation for the weird time sync behaviour between OF and RB, I think I'll close the task 13.18.36 # maybe, just maybe we can figure out where the OF stores its time offset and clear it when setting the time in RB 13.19.00 Join Trista743 [0] (i=tristan@i.dont.want.to.die.virgin.net.in) 13.19.03 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 13.20.16 # * bertrik checks the .SYS and .BIN files on his sansa 13.21.03 Quit Tristan (Read error: 110 (Connection timed out)) 13.22.00 # argh, I forgot that the clip doesn't show time in the OF ... 13.27.30 Join hd [0] (i=jd@modemcable022.187-203-24.mc.videotron.ca) 13.28.00 Quit HellDragon (Read error: 54 (Connection reset by peer)) 13.29.17 Join Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) 13.30.20 # Hi all, I'd like to know how I can control the space between the characters in the Virtual Keybord. The default layout is displayed very tight, and my custom layout is spaced. Thanks. 13.33.15 # Grahack: If you look in the custom layout file, it's probably just using normal spaces. 13.35.11 Join pyro_maniac [0] (n=pyro@91-64-227-210-dynip.superkabel.de) 13.36.38 # Llorean: you mean between each and every column ? No, here is my layout: http://pastealacon.com/2853 13.37.40 # If you mean you're trying to design a layout with partial spacing, it's impossible. 13.38.52 # Character spacing is dependent on the font 13.49.56 # OK, this is explained here: http://www.rockbox.org/twiki/bin/view/Main/LoadableKeyboardLayouts#The_Concept but what if I prefer the system font? I never wanted to use a special font. I can I continue to use the system font for the Virtual Keyboard? 13.53.31 Quit flydutch ("/* empty */") 14.02.07 # I don't like the idea of re-using existing WPS tags for the radio screen at all. It depends on the assumption that everyone uses the same basic subset of tags in the same way, which isn't true 14.03.10 # gevaerts: I think the only tags it'd really be making assumptions about are artist/album/title. And a combination where it can use those, but has explicit tags (that are preferred) is probably more likely anyway. 14.03.24 # Llorean: my WPS usually doesn't show artist... 14.04.13 # I don't see how that's a real problem though. You can customize yours, and "good" WPSes should include the FM tags anyway 14.04.29 # It'd mainly be a way to ensure that at least a significant subset of WPSes are "usable", at least minimally 14.05.03 # * gevaerts thinks that they are too different 14.07.46 # Album and Station Name are basically the same thing anyway, at least. 14.08.33 # really? I'd see Artist as more like Station Name if you want to look for similarities... 14.08.41 # I dunno. 14.09.11 # Songs on CD come on albums. The same Artist and Song can be on many different albums, the album is just the name of that instance of that media. 14.09.16 # Which works the same with FM. 14.09.50 # But I really don't understand the objection to it being a possibility. 14.09.53 # Llorean: well, "songs" (another one of my pet peeves ;) come in programs, which come on stations... 14.10.20 # you could also see station as the title tag - and album the .fmr file or so 14.10.45 # I actually also think that two different files will turn out to be more practical in the end. If you use one file using conditionals, you increase the difficulty of a simple basic WPS, which will (I think) scare away some people. 14.10.51 # or maybe the latter is similar to the playlist info (which can be shown in the WPS too) 14.11.16 # That also avoids the need to "support" the FM tags on non-radio targets 14.11.38 # that's a different issue though 14.11.41 # with viewports you can easily get complicated WPS code even for a simple WPS 14.11.52 # you *can*, but you don't have to 14.12.21 # yeah, just adding to your thought about complicated WPSs 14.12.53 # Well, as it stands if they're separate file we'd need wfs and rwfs. 14.13.23 # It seems to me, at least, that FM is still just an audio listening screen, and it'd make sense if they mostly used the same code/images/etc. 14.13.52 # Why not make them separate files with auto rollback to the wps file if there is no fmps? 14.13.58 # I think the WPS code is intimidating enough that adding a few more conditionals won't really raise the bar of learning it at this point. 14.14.35 # Anyway, once there is a set of FM tags, converting an existing WPS to use them should be fairly easy (in both the one file and the two files case), so I don't really see a reason to support tag matching 14.15.20 # Maybe we need to experiment a bit to see how complex the thing becomes. 14.17.23 # Why not reuse existing tags as a first step and see where the requests come from? 14.19.01 # another argument for reusing album (if you want to do that) is the wish for "album/station" art, expressed earlier 14.19.16 # for current station that is 14.20.19 # * pixelma just throws in some random thoughts 14.25.16 # What I'm afraid of is that the bar gets raised so high for a WFMS that nothing ever gets implemented, and we remain stuck with the current ugly screen 14.25.54 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 14.32.20 Quit gromit` (Read error: 60 (Operation timed out)) 14.35.51 Join kugel [0] (n=kugel@rockbox/developer/kugel) 14.39.17 Quit Grahack ("Leaving.") 14.39.45 Join gromit` [0] (n=gromit@ALagny-154-1-64-196.w81-249.abo.wanadoo.fr) 14.42.59 *** Saving seen data "./dancer.seen" 14.53.46 Join Lss [0] (n=Lss@cm7.delta91.maxonline.com.sg) 15.11.27 Quit kugel (Read error: 110 (Connection timed out)) 15.18.50 # saratoga: Re your latest change to SoundCodecs - did you verify that 5.1 AC3 is now realtime on PP5002? 15.19.02 # Last time I tried it was not. 15.27.43 Join midijunkie [0] (n=Miranda@pD9544AAA.dip0.t-ipconnect.de) 15.33.27 Join miepchen^schlaf [0] (n=miepel@p579EC3CB.dip.t-dialin.net) 15.35.14 Join mirak [0] (n=mirak@85-170-144-34.rev.numericable.fr) 15.46.08 Join calman_ [0] (n=caleb@dhcp-064-247-086-012.eg1.ohiou.edu) 15.46.55 Join Ubuntuxer [0] (n=johannes@dslb-094-221-082-117.pools.arcor-ip.net) 15.47.41 Join KBH [0] (n=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 15.58.31 Join kugel [0] (n=kugel@rockbox/developer/kugel) 16.01.07 Join wpyh [0] (n=william@115.171.82.220) 16.02.19 # hi, I'm trying to remove the use of pluginlib actions in the bubbles plugin 16.03.30 # however, I get "undefined reference to `button_get'" when compiling 16.03.30 # what should I do? (I've re-ran "make dep" but it still errors out) 16.04.57 # Please paste the your current code. http://rafb.net/paste/ 16.05.36 # Does anyone know what processor to build for for a Cowon D2? 16.06.20 # Sharn: you mean the compiler? arm 16.13.27 # gevaerts: yes, thanks 16.13.39 # Ubuntuxer: false alarm -- I found out the reason: I didn't use rb-> 16.16.18 Join taylor_ [0] (n=taylor@c-24-91-82-205.hsd1.ma.comcast.net) 16.18.37 Join CaptainKewl [0] (i=jds@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) 16.18.56 # I think we should not use album/artist/song for FM station info 16.19.58 # the beast has RDS support, and thus the possibility of showing real song info in the radio screen 16.20.26 # Though, I don't think the .wps and .wfs should be seperate 16.22.11 # can you change the backdrop from a conditional? 16.22.59 # not yet, backdrops are rather hard coded. but that should be very doable if we want that 16.23.26 Join rabbity [0] (n=rabbitx8@pool-96-245-175-197.phlapa.fios.verizon.net) 16.23.37 Join firedix [0] (n=firedix@201.254.117.70) 16.24.00 # I think we do. I can easily imaging people wanting a different backdrop for FM. It's not the most urgent thing of course 16.24.31 # I can imagine people wanting different backdrops for a dozens of screens :> 16.25.11 # we could make backdrop like fonts and put it into the viewport struct (storing an id in it) 16.25.17 # * gevaerts also still wants string comparison conditionals :) 16.25.24 # A different backdrop with and without album art would also be rather nice. 16.25.28 # the problem is, backdrop images are rather huge. 16.25.51 # You'd need to reserve an awful lot of memory, or hit the disk every time the condition changes. 16.26.24 Quit midijunkie (Read error: 104 (Connection reset by peer)) 16.26.28 # The FM one would be doable without extra memory if we don't use standard conditionals for it 16.27.24 # I don't quite understand. 16.27.32 # is it desirable to remove "#ifdef HAVE_LCD_BITMAP" and "#ifdef HAVE_LCD_CHARCELLS" from plugin source files? those plugins are already compiled/not compiled based on those same switches in SOURCES 16.27.34 # into the viewport struct would actually mean backdrop for any viewport and not necessarily fullscreen 16.27.45 Join domonoky1 [0] (n=Domonoky@g230018027.adsl.alicedsl.de) 16.27.53 # gevaerts: Just a spinup when switching between FM / HD? 16.27.59 Part domonoky1 16.28.43 # or we revive JdGordon's wps memory overhaul 16.28.51 # * Llorean doesn't think it's a bad idea to reserve memory for backdrops for a few specific screens, but universal conditional backdrop swapping is something else. 16.29.00 # kugel: That won't solve the issue, though. 16.29.13 # I feel obligated to let you guys know that two idiots from another network have decided that spamming you will be fun 16.29.16 # *@c-24-91-82-205.hsd1.ma.comcast.net *@92.62.168.146 16.29.20 # good day 16.29.32 # Llorean: as a non-clean hack you could e.g. change %X to load -fm.bmp instead of .bmp. 16.29.47 Join sceners_n00b [0] (n=sceners_@92.62.168.146) 16.29.49 Part taylor_ ("Leaving") 16.30.09 # gevaerts: But the image is (usually) loaded when you select the WPS, rather than when you enter the screen that uses the WPS. 16.30.29 # So it'd still need both pre-loaded with the current WPS philosophy of having it all available immediately 16.30.43 # hm, true 16.31.47 # Again though, I don't think it'd be bad to have memory reserved for on normal backdrop, and one FM backdrop 16.31.51 # Hey] 16.32.04 # But making it able to swap backdrops within general conditionals on the other hand, is probably not a good idea 16.32.21 Quit rabbity ("Leaving") 16.34.41 # SHIT 16.34.50 # NOOO my favorite psp 16.34.51 # :( 16.35.11 # sceners_n00b: This is a technical channel. We ask that you keep discussion restricted to Rockbox development or support. 16.35.52 # Sorry 16.36.21 Join brrybnds [0] (n=cliff@69-196-158-146.dsl.teksavvy.com) 16.42.34 Part sceners_n00b 16.43.00 Join n1s [0] (n=n1s@rockbox/developer/n1s) 16.43.02 *** Saving seen data "./dancer.seen" 16.44.28 Quit domonoky (Read error: 110 (Connection timed out)) 16.47.58 Quit SirFunk (Read error: 110 (Connection timed out)) 16.53.04 Quit Ubuntuxer ("Leaving.") 16.53.52 Join John_coder [0] (n=john_cod@c-24-91-83-69.hsd1.ma.comcast.net) 16.55.23 Quit John_coder (Client Quit) 16.59.08 Join toffe82 [0] (n=chatzill@adsl-75-8-206-188.dsl.frs2ca.sbcglobal.net) 17.04.22 Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) 17.04.40 Quit Lss (Read error: 104 (Connection reset by peer)) 17.09.27 Quit mirak ("Ex-Chat") 17.11.25 Join webtaz [0] (n=chatzill@p4FD4D552.dip.t-dialin.net) 17.11.30 # hiho 17.11.42 # I just got a sansa fuze 17.12.06 # and i'm willing to try out rockbox with it ( i know it's not officially running) 17.12.13 # just before i try: 17.12.40 # the bootloader -> what combination would it be to geht to the OF? 17.13.07 # and if sth happens, is there really no known method to recover the sansa that works for all fuze? 17.16.46 # mhh anyone seeing this? 17.16.55 # yes, have patience 17.17.27 # sry, just wanted proof irc works ^^ 17.17.39 # And please use real words as per the guidelines 17.20.19 # webtaz: have you read through the forum thread and related wiki pages? 17.20.31 # well... 17.20.36 # http://www.rockbox.org/twiki/bin/view/Main/SansaAMS#Bootloader_Installation 17.20.54 # this, and in a german forum 17.21.53 # I thought the buttons are described in the manuel generally, but for an device that has no build there should'nt be a manual? 17.22.33 # I meant the forum thread in our forums. 17.22.44 # That's where the development status is discussed, including recovery methods etc. 17.22.50 # Not having seen the German forum (and not being able to read German) - it is best advised if you collect all your information regarding this work-in-progress from Rockbox.org, not third-party sources. 17.23.37 # well another guy managed to run rockbox, and the infos came from kugel (who works as dev i think) 17.23.57 # what infos? 17.24.20 # that rockbox is able to run quite stable in normal use 17.24.32 # i know that is not official 17.24.57 Quit thegeek (Read error: 60 (Operation timed out)) 17.24.57 Part calman_ 17.25.02 # so i'm going to search for recover methods in the rockbox forum 17.25.10 # that's gonna be some work 17.25.57 # there's no recovery method 17.26.17 # ah, that's an answer :) 17.26.39 # and to get from the Original Firmware? 17.26.55 Join calman_ [0] (n=caleb@dhcp-064-247-086-012.eg1.ohiou.edu) 17.27.11 # crap to get to the OF 17.27.17 # but so far, nobody has bricked a ams sansa by just installing rockbox after dual boot has been stabilized 17.27.36 # that's good to hear :) 17.31.07 Join Lss [0] (n=Lss@cm7.delta91.maxonline.com.sg) 17.38.11 Join RoC_MasterMind [0] (n=Free@c-76-122-43-188.hsd1.fl.comcast.net) 17.38.57 Join robin0800 [0] (n=quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) 17.40.37 Quit tessarakt (Read error: 104 (Connection reset by peer)) 17.40.58 Join tessarakt [0] (n=jens@e180074074.adsl.alicedsl.de) 17.45.12 Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) 17.47.12 # BigBambi: http://en.wikipedia.org/wiki/American_and_British_English_spelling_differences#-ise.2C_-ize 17.47.53 # Basically, "ize" is more "correct" in UK English, but people incorrectly associate it with US English, so use "ise"... 17.48.23 # Well, in the end I'm not bothered 17.48.31 # In the past, when arguing about language, we've decided to use the OED as the definitive source. 17.48.36 # That was a surprise for sure 17.49.02 Join stoffel [0] (n=sfr@p57B4FD18.dip.t-dialin.net) 17.49.13 # It surprised me as well - I only found that out recently (when discussing things in Rockbox). 17.49.25 # OK, I'll change initialise back - center/centre was what I actually went in to change - I just spotted inialize whilst there 17.54.50 # * webtaz is quite happy to have Rockbox running on his Sansa Fuze :) 18.02.20 Quit thegeek (Remote closed the connection) 18.03.07 Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) 18.03.12 Quit RoC_MasterMind ("Leaving") 18.04.58 Quit robin0800 (Read error: 110 (Connection timed out)) 18.06.04 Quit bmbl ("Woah!") 18.09.05 # New commit by 03alex (r20889): I defer to the OED -ise/-ize. 18.09.42 Quit thegeek (Read error: 60 (Operation timed out)) 18.09.47 Join domonoky1 [0] (n=Domonoky@g230018027.adsl.alicedsl.de) 18.11.07 Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) 18.12.40 # linuxstb: what about the sentence case patch? 18.16.04 Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) 18.20.42 Join flydutch [0] (n=flydutch@host219-166-dynamic.15-87-r.retail.telecomitalia.it) 18.26.12 Quit thegeek (Remote closed the connection) 18.26.57 Join saratogahome [0] (n=41becb3b@gateway/web/cgi-irc/labb.contactor.se/x-0b97bdd7bf408fb2) 18.27.45 # amiconn: I only tested a stereo file, I didn't realize 5.1 was much slower, I just assumed we dropped the extra channels but if you're commenting I guess we mix them 18.28.11 Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) 18.40.19 Quit calman_ (Connection timed out) 18.42.09 Quit saratogahome ("CGI:IRC (EOF)") 18.42.27 Quit thegeek (Remote closed the connection) 18.43.05 *** Saving seen data "./dancer.seen" 18.43.18 Join mirak [0] (n=mirak@85-170-144-34.rev.numericable.fr) 18.56.43 Quit flydutch ("/* empty */") 18.59.16 # New commit by 03Domonoky (r20890): rbutil: make RbSettings a static class. (FS#10183 with improvements) 19.00.03 # saratoga: Yes, the ac3 decoder downmixes. 19.02.22 Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) 19.06.04 Quit mt (Read error: 110 (Connection timed out)) 19.16.03 Quit faemir ("Leaving") 19.17.44 Quit Thundercloud (Remote closed the connection) 19.18.34 Quit webtaz ("ChatZilla 0.9.84 [Firefox 3.0.10/2009042316]") 19.20.57 Join saratogahome [0] (n=41becb3b@gateway/web/cgi-irc/labb.contactor.se/x-71a2cbeaf2879304) 19.29.23 Join faemir [0] (n=faemir@88-106-242-222.dynamic.dsl.as9105.com) 19.32.44 Join seancho [0] (n=seancho@rrcs-70-60-17-129.central.biz.rr.com) 19.33.46 Quit stoffel (Read error: 113 (No route to host)) 19.43.50 # newbie question: My player has 15k tracks in the main music dir. The largest playlist I can 'insert shuffled' is 10k tracks. Does this playlist select randomly from all sub-dirs, or are there 5k tracks that will never be selected? 19.44.52 # seancho: increase the "Max playlist size" 19.45.31 # ...in settings/general/system/limits 19.45.58 Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) 19.46.20 # ah, thanks.. 19.46.31 Join dmb [0] (n=dmb@unaffiliated/dmb) 19.53.27 Join stoffel [0] (n=sfr@p57B4FD18.dip.t-dialin.net) 20.07.27 Quit saratogahome ("CGI:IRC (EOF)") 20.09.17 # New commit by 03bertrik (r20891): Remove unneeded #include "backdrop.h" ... 20.14.39 Quit miepchen^schlaf () 20.17.08 # New commit by 03Domonoky (r20892): rbutil: enforce parents for bootloader install classes. and rework OF handling a bit. 20.18.21 Ctcp Ping from gevaerts!n=fg@rockbox/developer/gevaerts 20.18.21 Ctcp Ping from gevaerts!n=fg@rockbox/developer/gevaerts 20.18.22 Ctcp Ping from gevaerts!n=fg@rockbox/developer/gevaerts 20.20.52 Join Mastery [0] (n=Mastery@66.241.118.70.cfl.res.rr.com) 20.27.28 # New commit by 03bertrik (r20893): Remove unused function audio_has_changed_track from apps/mpeg.c 20.33.20 # follow up newbie question: if I have 15k tracks in a dir and then I set 'max playlist size' to, say, 500, and then 'insert shuffled' that dir, will those 500 tracks be randomly selected from all 15k? 20.34.10 # no idea, but I wouldn't count on it 20.34.55 # yeah, thats why Im asking... 20.35.13 # seems like it might not be random 20.35.35 # I doubt it, since it'll limit the buffer used for reading the dir 20.35.55 # it'll probably be the first 500 tracks it reads from disk 20.36.23 # I figured that may be the case 20.36.42 # Assuming you don't listen to even 500 tracks at one sitting, what is the difference between having a 500 track random playlist and having a 1500 track random playlist? 20.37.18 # ie - why would you set the max playlist size lower than the number of tracks you have on your player? 20.37.18 # exactly. I just want the 500 to be pulled from the whole collection 20.37.25 # ah. 20.37.48 # seancho: why not just make a playlist out of all 1500 instead? 20.37.50 # because it spins the disk for about 5 minutes loading them up 20.37.57 # It saves memory, a bit, but there are other ways to scrape up more RAM savings if your are on a low-mem target. 20.37.58 # what? 20.38.09 # Ive got 15000 tracks 20.38.15 # a playlist loads instantly 20.38.30 # and you won't notice any speed diff from a 500 vs 15000 playlist much 20.38.34 # yes, but it only buffers 16ish or 32ish or 64MBish at a time. 20.39.03 # Are you on an iPod video 80GB? 20.39.09 # If I insert shuffled the whole dir, it takes a few minutes 20.39.12 # yeah 20.39.16 # 80gb 20.39.21 # is dircache on? 20.39.22 # I said playlist, not insert shuffled though 20.39.37 # that's a much slower operation 20.39.41 # ok, I could make a playlist of the whole thing 20.40.00 # but then I have to re-make the playlist every time I add stuff 20.41.01 # Or just insert the new stuff into the playlist and re-save it. 20.41.02 # I was wondering if I decreased playlist max size if I could add shuffled and still get a selection from the whole dir 20.41.16 # the 5G 80GB is (was?) the slowest disk performer by far, but 5 minutes seems like a long time to insert that many tracks shuffled. 20.41.20 # save a bit of effort 20.41.28 # If you limit the playlist size to 500, I'm pretty sure it'll only use the first 500 songs in the folder. 20.41.39 # You can of course test this to find out, and probably could've by now. :-P 20.41.39 # yeah, its not a huge problem 20.41.56 # ha 20.42.10 # but its so much easier to bug you guys :) 20.42.36 # I appreciate the effort you all put in 20.42.39 # great player 20.43.09 *** Saving seen data "./dancer.seen" 20.43.14 Quit __lifeless (Remote closed the connection) 20.43.30 Join __lifeless [0] (n=lifeless@188.16.124.46) 20.46.02 Join _lifeless [0] (n=lifeless@188.16.69.157) 20.46.15 Join Bobthebuilder [0] (n=bob@122.168.45.50) 20.48.22 Quit Bobthebuilder (Client Quit) 20.49.52 # New commit by 03Domonoky (r20894): rbutil: show logger windows earlier in bootloader install, to catch all errors. 20.53.22 Quit KBH ("ZNC") 20.54.22 Quit firedix ("Ex-Chat") 20.55.16 Quit pyro_maniac ("Leaving.") 21.00.44 Quit __lifeless (Read error: 110 (Connection timed out)) 21.03.42 Join petur [50] (n=petur@rockbox/developer/petur) 21.03.42 Join motionman95 [0] (i=4597cd8a@gateway/web/ajax/mibbit.com/x-c9f5e527013abbd3) 21.04.44 # How does a viewer get the file name of the file it's sent? 21.07.04 # New commit by 03bertrik (r20895): rbutil: fix spelling, enginge -> engine 21.07.20 Join Blue_Dude [0] (n=chatzill@74.235.206.66) 21.09.34 Join KBH [0] (i=hbk@pool-71-96-74-73.dfw.dsl-w.verizon.net) 21.10.06 # A question about patches. Is it worthwhile to submit small patches of developing code as a new feature is being developed, or try to present it all at once? I'm concerned about the patch being developed on really old code. It's going to take awhile for the thing to be ready. 21.10.50 # Blue_Dude: It's a good idea to svn up fairly regularly so that when you do submit a patch it's in-sync 21.11.28 # When I do svn, do I do a normal checkout? I don't want to overwrite my changes. 21.11.53 # Are you working on an SVN checkout already 21.11.54 # ? 21.11.58 # Yes. 21.12.00 # I think you'd use "svn update 21.12.04 # An "svn update" will update without overwriting changes. 21.12.14 # As for submitting patches as you go, the first patch should probably be somewhere around "first draft" quality. Something that's at least somewhat usable (that allows people to see the idea in action and comment on further development, or problems that may prevent its inclusion) 21.13.29 # If I do update, will that update every file except the changed ones? Or will it update the files I'm working on also, but preserving my changes? 21.14.03 # * domonoky1 made new patches for FS#10185. now rbutil can install on my sansa e200 v2 :-) 21.14.03 Quit bagawk_ (Read error: 54 (Connection reset by peer)) 21.14.24 # it will update all files, trying to preserve changes. If the update changes bits in the file you also touched, you'll have to fix them, but all needed information should be there for that 21.15.12 # Blue_Dude, if you're afraid of svn update you can do a "svn diff >my_changes.patches" first to keep a snapshot of your current changes 21.15.39 # OK, I'll fool around with it for a minute... 21.16.40 # domonoky1: for the makefile thing, I'd say preprocess the makefile for __WIN32__ (and cygwin/mingw if needed) and use the pre-build one in that case 21.16.43 # domonoky1: Should it work on all "supported" AMS sansas now? 21.17.22 # Has anyone heard of Dev C++? 21.17.25 # ah wait 21.17.25 # Llorean: it could, if you add the other targets into rbutil.ini 21.17.37 # http://www.bloodshed.net/devcpp.html 21.17.54 # it wasn't about windows, it was about having arm toolchains, which applies to all OSes 21.17.57 # motionman95: please stay ontopic, thats not rockbox related. 21.18.23 Join firedix [0] (n=firedix@201.254.117.70) 21.18.27 Quit motionman95 ("http://www.mibbit.com ajax IRC Client") 21.18.53 # domonoky1: tools/configure has magic for finding whether arm toolchain is installed. maybe just c&p that magic? 21.18.54 Quit firedix (Read error: 104 (Connection reset by peer)) 21.19.37 Join bagawk [0] (n=lee@c-98-232-168-140.hsd1.or.comcast.net) 21.21.39 # kugel: first we need to decide if we want prebuild dualboot-xxx.o files in svn, or how we would like to handle that. if we have them in svn, its just a issue of not building them, if there are already there. 21.22.28 # well, isn't that the only possible way without requiring the arm toolchain? 21.22.34 # I tought we already agreed on doing that 21.23.01 # That was interesting. I just did a "svn up" and it did go out and update the source, with a "U" in front of most files. But one file I did changed had a "G" in front of it, and my changes were preserved. Thanks! 21.23.26 # another way could be to provide the dualboot files from the download server, but that needs changes in mkamsboot. 21.23.54 Quit petur ("installing linux...") 21.26.14 # that sounds too compilcated imo 21.26.33 # having the prebuilt in svn is just fine to me 21.27.19 # maybe for you, what do others think ? :-) 21.28.34 # another issue with libmkamsboot.a and libucl.a: mac os X. Both need a bit Makefile love to build as multiplatform libs (see rbspeex). Makefile gurus, please help out :-) 21.29.55 # A question about the system settings struct: I added an element to it in settings.h and put in a handler for reading that element in settings.c. Now, if I run this on an existing machine, will it screw up when it tries to pull the settings in the old format? 21.31.06 Join miepchen^schlaf [0] (n=miepel@p579EC3CB.dip.t-dialin.net) 21.33.38 Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) 21.34.19 # domonoky1: I've always planned to have "dualboot-xxx.bin" files in SVN (once they became stable, which I'm assuming they are by now). 21.34.44 # Perhaps moving the source to them to a subdir under mkamsboot. 21.35.01 # linuxstb: that sounds good. 21.37.09 # linuxstb: care to take a look at my mkamsboot rework ? (FS#10185) :-) 21.38.27 Join froggyman [0] (n=187b533e@gateway/web/cgi-irc/labb.contactor.se/x-aaa1bd3ae273e78e) 21.38.36 # Or is my only alternative to add my element to the end of the struct to avoid first time read errors? 21.42.59 # domonoky1: Will rbutil have md5 checking, similar to the h1x0/h3x0 bootloaders? 21.43.22 # at moment it doesnt, but it could be done. 21.47.45 # domonoky1: the dual boot file should basically never change so I think SVN will be fine 21.48.43 # kugel: do you have any idea if the MMU changes will require new bootloaders? last I heard the idea was to keep MMU disabled in the bootloader but I'm not sure if thats still the case or if other changes are needed 21.49.32 # it's not set in stone, but we (me, FlynDice and funman) agreed on not messing with it in the bootloader 21.50.00 # so we could begin testing official bootloaders now? or do you think its too soon for that 21.50.51 # domonoky1: just commented on that task. You use QtGui from base/. *urgh* 21.51.11 # bluebrother: please read :-) 21.51.19 # which is a bad thing ... 21.51.34 # its just temporary because no bootloader on server 21.51.51 # well, you could simply had code it for now 21.52.04 # i even wrote that in the comment 21.52.19 # that's at least better (IMO) than introducing a non-wanted dependency. Stuff like this tends to get forgotten about later ... 21.52.38 # s/had code/hardcode/ 21.52.54 # If you want to remap memory there might be an advantage to doing it in the bootloader at some point but for right now it's much simpler to leave the mmu out of the bootloader for ams sansa 21.53.20 # no other changes to the bootloader are expected once the MMU is enabled? 21.53.37 # last i heard there was some thought that changes might be needed to how things are clocked, would the old bootloader be ok with that? 21.54.03 # btw, I think it would be better to not #include something in the header and then rely in the cpp file on that include. If the file needs QtGui it should include QtGui by itself 21.54.16 # as that makes it clearer that it needs QtGui 21.54.47 # bluebrother: did you hear the word "temporary" ? 21.55.09 # it doesnt matter, if it surely will be changes before commit. 21.55.10 # FlynDice: which advantage to you imagine? 21.55.35 # the booting process is already insanely fast (compared to my e200v1) so that isn't worth complicating the bootloader imo 21.55.59 # bluebrother: and the ofHint() thing is already in svn. :-) i think this doesnt belong int rbutilqt.cpp, its install method specific. 21.56.26 # If we enable the mmu in the bootloader we could set up your no long calls memory map before we load the firmware 21.56.43 # eventually we might need MMU if we're going enable USB in the booloader 21.56.57 # but that can be delt with later 21.57.21 # also, we can always update the .bin/.o when they're in svn too 21.57.23 # I think the clocking issues are all outside the bootloader also 21.57.41 # long calls require no set up 21.58.27 Quit BHSPitLappy (Read error: 110 (Connection timed out)) 21.58.32 # has anyone ever seen a fast FFT for ARM or Coldfire? 21.58.35 # removing the file filter on searching for the OF file isn't a good thing either IMO -- then you need to make the bootloader class aware of the extension (or retrieve it from the settings) 21.58.48 # i'd really like to explore alternative transforms for our codecs, but without a good FFT I doubt I'll beat what we already use 21.59.06 # * bluebrother can't remember him agreeing with moving the ofHint() stuff 21.59.15 # bluebrother: or just relay on the user to find the right file :-) 21.59.21 # saratoga: Simply googling ARM FFT turns up some results, at least 22.00.22 # well, as the user will see possibly 100+ additional unrelated files it's not really nice 22.00.25 # bluebrother: it was already there in the earlier patch, you didnt complain about it. so i commited it :-) 22.00.43 # and if you think you can improve it, go for it. 22.00.57 # I complained about moving the post install hints. You really think I'd have a much different opinion about that then? 22.02.53 # yes, it was in rbutilqt.cpp where it surely doesnt belong. there is already too much logic there. so i think its better now. 22.03.25 # * bluebrother feels like this wasn't the answer to the question 22.04.11 # New commit by 03Domonoky (r20896): rbutil: make sure the voice creation window updates its display on startup. 22.04.57 # Llorean: yeah I've spent some time googling over the years but never found anything that looked better then what we use, though FFTs are often burried deep in more complicated programs so you never know 22.05.33 # * domonoky1 s brain reading device is broken. i think "yes" is a valid answer. 22.14.10 Quit stoffel ("leaving") 22.18.01 Join mt_ [0] (n=MTee@41.233.144.53) 22.18.40 Nick mt_ is now known as mt (n=MTee@41.233.144.53) 22.22.39 # I found ARM's FFT benchmarks, and they work out to doing all the FFTs + rotations needed for a WMA/AAC style MDCT codec in about 12 MHz on ARM7TDMI 22.22.56 # i can't find my notes but I think our MDCT library does it in about 16MHz, so we're actually not too far behind 22.28.32 Nick hd is now known as HellDragon (i=jd@Wikipedia/HellDragon) 22.33.54 Quit Blue_Dude (Read error: 145 (Connection timed out)) 22.34.01 Quit bluebrother (Read error: 104 (Connection reset by peer)) 22.34.09 Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) 22.39.25 # saratoga: just 33% slower ;) 22.42.15 # yeah but good luck catching up to what ARM can do 22.43.13 *** Saving seen data "./dancer.seen" 22.44.10 Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) 22.44.13 # no, it's 25% slower 22.44.33 # or 22.44.42 # * Bagder shut up and goes away 22.44.48 # well my numbers are +/- a lot anyway :) 22.45.23 # Bagder: :D 22.47.01 # saratoga: liba52 does the downmix, but even if we would drop the extra channels, decoding 5.1 would be slower than decoding 2.0, because of the higher total bitrate 22.47.41 # We need to decode everything at least partially (similar to how jpeg on greyscale targets at least needs to huffdecode chroma) 22.48.26 # i think most of the slow down is calling the IMDCT on all those extra channels 22.48.53 # that would consume a good 20-30MHz on PP5022, no idea how much that is on 5002 22.49.32 # I need to find my test files again. It should be possible to speed up things on PP5002 by proper iram usage 22.49.43 Quit froggyman ("CGI:IRC (EOF)") 22.49.52 # we could use the faster imdct library and probably get real time 22.50.08 # The interesting thing is that with proper use of iram, PP5002 can be as fast as PP5022, which is a few percent faster than PP5020 22.50.38 # but its weird because the spec says to use the ffmpeg style IMDCT, not the Tremor style one, so we'd have to deinterleave coefficients for short blocks 22.50.45 # If you look at the APE performance figures you see what I mean 22.50.53 # amiconn: actually does AC3 use a lot of IRAM already? 22.52.15 # if we don't mind wasting a couple KB of IRAM, we could just use the fast imdct library for long blocks and the built in one for short blocks, and not need to reorder anything 22.52.36 # I don't know, need to check 22.52.40 Join Blue_Dude [0] (n=chatzill@adsl-235-206-66.mco.bellsouth.net) 22.52.41 Nick Blue_Dude is now known as Blue (n=chatzill@adsl-235-206-66.mco.bellsouth.net) 22.53.07 # hmm the decoder does windowing during the transform, so we'd need to add that too . . . 22.53.21 # It might be a tiny thing that causes the slowdown. In libdemac it was one single array - a few dozen bytes - which wasn't in iram but was used a lot 22.53.34 # hard to be motivated for a format that no one uses :) 22.53.47 Quit Blue (Client Quit) 23.01.33 Join CaptainKwel [0] (n=jds@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) 23.10.48 Quit CaptainKewl (Read error: 110 (Connection timed out)) 23.14.07 Nick BigBambi is now known as AlexP (n=alex@rockbox/staff/BigBambi) 23.16.08 # saratoga: Supporting ac3 for video could be useful though, so people can keep original audio tracks. So a very fast ac3 decoder would be nice to have for that. 23.16.38 # * Llorean would personally love to have AC3 for video 23.17.49 # Llorean: It shouldn't be that hard to change mpegplayer to use ac3 instead of mpeg audio. I'm not sure how to support both... 23.18.18 # linuxstb: thats a good idea 23.18.46 # AC3 has zero arm optimizations right now and its about as fast as AAC (for stereo), so it could be made quite fast 23.19.05 # linuxstb: Well, supporting both is the first step in a direction mpegplayer's probably going to go *eventually* anyway. 23.21.37 # well if someone adds AC3 support, I'll make it really fast 23.21.51 # until then theres more interesting things to work on 23.22.26 Nick _synergis is now known as synergist (n=christof@cant.be-arsed.co.uk) 23.23.03 # * Llorean wonders if the Gigabeast @ full speed could handle DVD rips. 23.23.14 Nick AlexP is now known as BigBambi (n=alex@rockbox/staff/BigBambi) 23.23.56 # Llorean: I guess that depends on the resizing speed. I would expect it to handle the decoding. 23.24.23 Nick BigBambi is now known as AlexP (n=alex@rockbox/staff/BigBambi) 23.24.44 # its got a hardware resizer i think 23.25.46 # Ah, yeah, DVDs are always going to need aspect ratio correction too. 23.31.32 # in case anyone was wondering, MDCT for WMA 192k uses 16.6MHz on PP5024 23.32.23 # * linuxstb thinks a full dvd-player plugin for the beast (with menu support etc) would be fun... 23.32.57 # linuxstb: extra points for USB host support so you can actually play real dvds 23.33.28 # hah 23.33.52 # linuxstb: Just except valid DVD ISOs? 23.33.56 # *accept 23.34.40 # ISOs could be tricky on FAT, but VIDEO_TS folders would be fine. 23.34.50 # Ah, right. 23.35.13 Part seancho 23.38.48 # Video_TS files can have MPEG2 Video and MP2 audio, which I believe we already support in mpegplayer 23.39.03 # would be quite easy to get a few of them working as is, just need a TS parser 23.39.18 # Do we support non-square pixels? 23.40.10 # saratoga: "TS" in mpeg terms means "transport stream". DVDs use MPEG program streams, which Rockbox already supports - so you should be able to simply copy a .vob to Rockbox and play it. 23.40.19 # linuxstb : patch2 is in FS#10182 - I think the next patch would replace cook.c with the older revision, and apply the necessary modifications to cook.h and the rest of the files in preparation for applying ffmpeg's patch. 23.40.28 # linuxstb: I didn't realize that 23.41.22 # DVDs are basically a subset of the MPEG-2 standards, with extra features (navigation, menus etc) added. 23.46.10 Quit schrottplatz ("o.O") 23.46.21 # the assemblerized parts of the MDCT library only account for 50% of the total run time, perhaps we could save some more time in there 23.52.11 # mt: That patch looks good to me - I'll try and commit it later tonight. But in future, can you start giving your patches unique names - e.g. add a version number to them (something like libcook.patch2.v3) 23.52.52 # mt: How old is the revision of cook.c you plan to revert to? Is it very different to the version currently used? 23.53.55 # linuxstb : yes .. it's from 6 mar 2007 iirc (as opposed to 20 mar 2009 for the current one) 23.55.25 # mt: Hmm, it seems there were a lot of improvements to cook.c in that time... 23.56.01 # linuxstb: the changes are almost entirely for multichannel cook though 23.56.31 # saratoga: No, those are the changes after the 20 march 2009 version. 23.56.39 # I'm talking about the 2 years previous to that. 23.57.06 # i looked through them and most seemed irrelevent to us, aside from one or two by Michael 23.58.14 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 23.58.15 # Still, it seems bad to use such an old version of the decoder, and not work to update those patches.