--- Log for 25.11.108 Server: zelazny.freenode.net Channel: #rockbox --- Nick: @logbot Version: Dancer V4.16 Started: 23 days and 8 hours ago 00.00.56 # well I don't really agree 00.01.08 # I know :) 00.01.11 Quit ender` (" Microsoft is like a case of herpes. You can't kill it off entirely, just force it to go into a dormant stage for a while.") 00.02.50 # * Unhelpful is inclined to think that the gain is zero... so, even if we assume the cost to be zero, what's the point? 00.02.55 # unless rbutil downloads custom bootloader no ipod user ever is gonna install one configured in that way (the risk he gets such a build is higher imho, going by the loads of custom builds compared to (is there even any) "un"loads of custom bootloaders) 00.03.28 # and the complexity is very controllable. This should be a 3-liner and no-brainer 00.04.10 # was it ever determined if the fuze can be unbricked? 00.04.19 # saratoga: not that I know of 00.05.01 # kugel: you still haven't told me what good this would do anyone. do you also want a config parameter for the 'viewers' directory? how about 'codepages'? they are even less complex to change. 00.05.28 # Zagor: I tell you what my personal gain is: while the fuze port I'm always here and there trying to boot from the microsd (which is indeed doable) in order to test sd code. And I'd rather pass a configure option instead of changing the tree 00.05.33 # kugel: then I better be careful, are there instructions for the fuze install somewhere? 00.05.39 Quit bmbl ("Woah!") 00.06.00 # saratoga: svn bootloader works. I've build it today 00.06.49 # saratoga: mkamsboot has a small help text on how to pass file. The patched firmware it creates is to be put on the fuze's root dir 00.07.29 # Zagor: especially since the microsd is correctly recognized, unlike the internal memory 00.09.02 # "See comments in mkamsboot.c and dualboot.S for more information." quite the help file 00.09.31 # saratoga: did you type make in the mkamsboot dir? 00.10.09 # kugel: I think your case is a typical one-off and the proper solution is to change the tree. so, I won't do it. but I won't revert either it if you manage to convince someone else... 00.10.12 # if you then execute mkamsboot it should say "./mkamsboot " or something like that 00.10.22 # gevaerts: I just tried it again on XP, which got as far as recognizing a UMS device, but then nothing. On linux the USB ids didn't even show up in lsusb. Unfortunately I haven't the faintest idea where to look for clues.. 00.11.22 # kugel: I saw that, but the name of the firmware file to patch isn't mentioned 00.12.13 # saratoga: the name is unimportant. You can rename firmware files if you like before passing it to mkamsboot 00.12.25 # (afaik) 00.12.48 # I always use the latest fuzef.bin from the sansa forums if that helps 00.12.57 # so I can't remove it from my player? 00.13.26 # remove the firmware from your player? 00.13.46 # well, you shouldn't execute mkamsboot directly on the fuze 00.14.26 # just patch the firmware in mkamsboot/ and cp the patched firmware onto the fuze with a proper filename (like fuzef.bin or fuzet.bin) 00.14.58 Join tyfoo2 [0] (n=tyfoo@dyndsl-095-033-067-206.ewe-ip-backbone.de) 00.15.33 # I'm trying to get the copy to patch, not patch the version already on the player 00.15.44 # i don't care where its patched, but I would like a copy 00.16.44 # you want to dump it from the fuze? I don't know if that's possible. You can get a firmware file here: http://forums.sandisk.com/sansa/board/message?board.id=sansafuse&thread.id=4880 00.16.58 # ok grabbing that and putting it in the wiki 00.17.12 Quit Zagor ("Client exiting") 00.17.17 # they are all the same. the filename decides about features 00.17.28 Join skipper [0] (n=skipper@93-136-0-47.adsl.net.t-com.hr) 00.17.57 # there's also an older version on Bagder's site 00.18.52 # dualboot is dualboot_fuze.arm-o then? 00.20.06 Quit tyfoo (Read error: 145 (Connection timed out)) 00.20.20 # yea, but you don't need to care about that 00.20.52 # you just pass the OF file, and the bootloader you build using tools/configure to mkamsboot and will get a complete patched firmware 00.21.08 # (including dualboot and rockbox loading that is) 00.21.21 # so just leave it blank? 00.23.02 # leave what blank? 00.23.42 # the bootloader 00.24.14 # no 00.24.20 # you need to files 00.24.24 # the of file 00.24.30 # and the bootloader you built yourself 00.24.58 # then do "./mkamsboot of_file.bin bootloader-fuze.sansa patched_of.bin" 00.25.08 # so its the rockbox bootloader then? 00.25.13 # yes 00.25.31 # Did I say something different? 00.26.51 # no i misunderstood 00.31.09 # saratoga: I don't there's detailed information. 00.31.29 # so maybe someone should put that into the wiki 00.31.57 # I'll type them up later 00.32.30 # add a think somewhere in t 00.32.36 # that sentence, btw 00.34.58 Quit mcuelenaere () 00.36.14 Quit n1s () 00.39.02 Join sbhsu [0] (n=a6530466@Zion.dorm.au.edu.tw) 00.40.47 Join shot0fadds [0] (n=rob@rockbox/developer/shotofadds) 00.41.02 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 00.41.11 Join LambdaCalculus37 [0] (i=4453b1b5@gateway/web/ajax/mibbit.com/x-6930b02bd24d5957) 00.42.16 Quit jhMikeS (Read error: 110 (Connection timed out)) 00.43.33 Quit kugel ("ChatZilla 0.9.84 [Firefox 3.0.4/2008111318]") 00.45.10 Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) 00.46.21 Nick tyfoo2 is now known as tyfoo (n=tyfoo@dyndsl-095-033-067-206.ewe-ip-backbone.de) 00.46.28 Quit tyfoo ("Carpe diem") 00.47.01 Quit herrwaldo ("Konversation terminated!") 00.48.27 # if we have a doc, besides the src, that describes the greyscale LCD layouts, that'd be a help. the HORIZONTAL_PACKING case seems simple enough, the rest i'm not so sure about. 00.50.07 Quit Nico_P (Remote closed the connection) 00.50.49 Quit shot0fadds ("Leaving") 00.53.07 Quit SUSaiyan () 00.54.33 Quit sbhsu_ (Read error: 113 (No route to host)) 00.56.23 Quit tessarakt ("Client exiting") 00.58.23 Quit shotofadds (Read error: 110 (Connection timed out)) 01.08.41 Join SUSaiyan [0] (n=SUSaiyan@cc84863-b.zwoll1.ov.home.nl) 01.18.29 Join CaptainKewl [0] (i=jds@207-237-173-165.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) 01.22.40 Part toffe82_ 01.23.16 Quit culture (Read error: 110 (Connection timed out)) 01.24.08 Part pixelma 01.24.35 Join pixelma2 [0] (n=marianne@rockbox/staff/pixelma) 01.26.27 Quit miepchen^schlaf () 01.27.25 # Unhelpful: No, I don't think there's a doc. Just ask... 01.29.30 Quit MethoS-- (Remote closed the connection) 01.29.42 Quit Thundercloud (Remote closed the connection) 01.30.39 Quit Lynx_ ("Konversation terminated!") 01.33.37 Join miepchen^schlaf [0] (n=miepchen@p579ECB53.dip.t-dialin.net) 01.35.22 Nick Bensawsome is now known as NinJew (n=Bensawso@unaffiliated/bensawsome) 01.38.41 Quit saratoga ("CGI:IRC (EOF)") 01.42.47 Nick NinJew is now known as Bensawsome (n=Bensawso@unaffiliated/bensawsome) 01.46.59 Quit MegafEee ("KVIrc 4.0.0 Insomnia http://www.kvirc.net/") 01.51.05 *** Saving seen data "./dancer.seen" 02.02.08 Join Darksair [0] (n=user@125.33.198.70) 02.08.20 Quit Darksair ("People who are zhuangbility want to show their niubility but only reflect their shability.") 02.08.44 Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) 02.08.48 # vertical packing seems... inconvenient for me, but at least not hard to understand. ;) 02.09.10 Quit jeffdameth (Read error: 60 (Operation timed out)) 02.10.11 Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) 02.13.01 Join Darksair [0] (n=user@125.33.198.70) 02.13.35 Quit kkurbjun ("Leaving.") 02.15.52 Quit LambdaCalculus37 ("http://www.mibbit.com ajax IRC Client") 02.17.38 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 02.18.58 Nick Darksair is now known as Awaysair (n=user@125.33.198.70) 02.29.44 Join massiveH [0] (n=massiveH@ool-44c48a1e.dyn.optonline.net) 02.36.18 Nick Awaysair is now known as Darksair (n=user@125.33.198.70) 02.36.53 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 02.39.19 Quit massiveH ("Leaving") 02.41.18 Join massiveH [0] (n=massiveH@ool-44c48a1e.dyn.optonline.net) 02.46.48 Quit Xerion (Read error: 60 (Operation timed out)) 02.55.11 Quit jhMikeS (Nick collision from services.) 02.55.17 Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) 02.56.24 Join toffe82 [0] (n=chatzill@adsl-71-132-86-239.dsl.sntc01.pacbell.net) 03.47.57 Join reacocard [0] (n=reacocar@WL-135.CINE.HMC.Edu) 03.51.06 *** Saving seen data "./dancer.seen" 04.07.02 Quit CaptainKewl ("( www.nnscript.de :: NoNameScript 4.02 :: www.XLhost.de )") 04.09.30 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 04.14.19 Join blkhawk- [0] (n=blkhawk@e179051093.adsl.alicedsl.de) 04.21.33 Quit notplus_M (SendQ exceeded) 04.24.05 Quit Bensawsome ("The awsome is gone :(") 04.28.27 Nick Darksair is now known as Awaysair (n=user@125.33.198.70) 04.30.47 Quit blkhawk (Read error: 110 (Connection timed out)) 04.31.17 Nick blkhawk- is now known as blkhawk (n=blkhawk@e179051093.adsl.alicedsl.de) 04.46.27 Join aarcane [0] (n=aarcane@c-67-187-242-146.hsd1.ca.comcast.net) 04.47.01 Join igorr [0] (n=igorr@padme.ifi.uio.no) 04.50.17 # A quick question -- how does one know if a specific rockbox font supports unicode? 04.56.09 Quit reacocard (".") 04.56.51 Join reacocard [0] (n=reacocar@134.173.63.19) 04.57.10 # igorr: I think rasher.dk/rockbox has a listing of which glyphs are in which font 04.57.42 Quit aarcane (Client Quit) 04.57.46 # http://rasher.dk/rockbox/fontstats/ 04.58.02 # Aha 04.58.07 Join miepchen^schlaf_ [0] (n=miepchen@p579ECAE6.dip.t-dialin.net) 04.58.27 Join webguest94 [0] (n=3aac9a01@gateway/web/cgi-irc/labb.contactor.se/x-53aecf9ad03e641b) 04.58.39 # JdGordon: this looks really nice, thank you (basically, I was wondering why my cyrillic and utf-8 encoded file names looked like garbage on my iRiver) 04.59.21 Quit webguest94 (Client Quit) 05.02.07 Nick Awaysair is now known as Darksair (n=user@125.33.198.70) 05.09.35 # ooh. that's good to have. 05.12.59 Quit miepchen^schlaf (Read error: 110 (Connection timed out)) 05.23.36 Part igorr 05.33.20 # Do iPod 1G/2G, Mini and Mini 2G _actually_ have a WM8721 codec? 05.37.28 Nick Darksair is now known as Awaysair (n=user@125.33.198.70) 05.43.23 Quit Horscht ("electromagnetic radiation from satellite debris") 05.51.09 *** Saving seen data "./dancer.seen" 05.53.11 Quit Seed ("cu, Andre") 05.56.45 Quit massiveH ("Leaving") 05.57.18 Quit JdGordon (Remote closed the connection) 05.58.48 Join JdGordon [0] (n=Miranda@c211-28-145-137.smelb2.vic.optusnet.com.au) 06.26.57 Quit DataGhost (Read error: 110 (Connection timed out)) 06.37.03 Join kharo [0] (n=teemu@a88-114-255-186.elisa-laajakaista.fi) 06.44.30 Join DataGhost [0] (i=dataghos@unaffiliated/dataghost) 07.07.46 Part toffe82 07.17.27 Join einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de) 07.30.22 Quit skipper (Read error: 110 (Connection timed out)) 07.37.33 Quit einhirn (Read error: 60 (Operation timed out)) 07.38.04 Nick Awaysair is now known as Darksair (n=user@125.33.198.70) 07.38.29 Join skipper [0] (n=skipper@93-139-63-33.adsl.net.t-com.hr) 07.40.18 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 07.41.54 Join ap0 [0] (n=kvirc@mer90-1-88-166-249-88.fbx.proxad.net) 07.42.00 Quit ap0 (Client Quit) 07.45.02 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 07.51.11 *** Saving seen data "./dancer.seen" 07.55.07 Join Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) 08.04.48 Quit miepchen^schlaf_ () 08.08.04 Join omgun [0] (n=79b45a2d@gateway/web/cgi-irc/labb.contactor.se/x-b8c4514f06920e44) 08.11.02 Quit omgun (Client Quit) 08.13.20 Quit skipper (Read error: 60 (Operation timed out)) 08.14.02 Quit BigBambi_ (Read error: 104 (Connection reset by peer)) 08.18.28 Join n1s [0] (n=nils@rockbox/developer/n1s) 08.18.54 Join Rob2222 [0] (n=Miranda@p4FDCDC28.dip.t-dialin.net) 08.21.00 Quit pixelma2 ("-") 08.21.13 Join pixelma [50] (i=pixelma@rockbox/staff/pixelma) 08.25.01 Join lasser [0] (n=chatzill@Wb8b1.w.pppool.de) 08.27.12 Join kugel [0] (n=chatzill@unaffiliated/kugel) 08.28.05 # jhMikeS: ping 08.28.18 Join stoffel_ [0] (n=sfr@p57B4CB2D.dip.t-dialin.net) 08.33.19 Join Bagderr [241] (n=daniel@rockbox/developer/bagder) 08.33.46 Nick Bagderr is now known as B4gder (n=daniel@rockbox/developer/bagder) 08.35.10 Part XavierGr 08.35.21 Quit BHSPitMonkey ("Ex-Chat") 08.36.08 Quit Rob2223 (Read error: 110 (Connection timed out)) 08.37.52 Quit lasser (Remote closed the connection) 08.38.38 Join ender` [0] (i=krneki@foo.eternallybored.org) 08.38.52 Quit ender` (Read error: 104 (Connection reset by peer)) 08.39.02 Join ender` [0] (i=krneki@foo.eternallybored.org) 08.39.42 Quit ender` (Client Quit) 08.40.26 Join ender` [0] (i=krneki@foo.eternallybored.org) 08.46.37 Join lasser [0] (n=chatzill@Wb8b1.w.pppool.de) 08.53.21 Quit n17ikh|Lappy () 09.01.02 Join petur [50] (n=petur@rockbox/developer/petur) 09.03.39 # kugel: pong 09.04.09 # jhMikeS: have you seen my backlight fade commit candidate? 09.04.36 # seems to work fine on all affected targets. 09.04.48 Join nuonguy [0] (n=john@c-71-198-1-139.hsd1.ca.comcast.net) 09.06.45 # jhMikeS: but I'm still wondering about MartinR's comment 09.08.50 # kugel: I'll go look. 09.13.29 # kugel: did you solve the issue of when the brightness is 1, the bl fails to work correctly? 09.13.44 # yes 09.14.47 Quit GodEater ("http://www.mibbit.com ajax IRC Client") 09.14.58 # MartinR's comment makes no sense to me. Posting messages will not improve accuracy since thread scheduling will be done the same way. 09.16.05 # The way to improve accuracy and give fading an advantage is to increase the thread priority when fading so it runs before lower priority threads. 09.18.20 Join GodEater [0] (i=c2cbc962@gateway/web/ajax/mibbit.com/x-bd26a06db8dc30a0) 09.19.37 # jhMikeS: yea, makes sense 09.21.39 # I just thought that backlight_tick might already start incrementing the counter while backlight_thread is doing the fade step 09.22.46 # which would make sure the interval is always the same, and with timeout the interval is the timeout + the time the fading step takes 09.26.37 # doesn't it just reverse the fade from wherever it is if the timeout happens? 09.28.14 Join jfc^3 [0] (n=john@dpc691978010.direcpc.com) 09.32.13 # jhMikeS: I don't understand. I'm back in 20minutes 09.32.17 Quit kugel (Remote closed the connection) 09.34.21 Quit n1s (Remote closed the connection) 09.37.31 Join Guest_ [0] (n=chatzill@dslb-088-072-193-157.pools.arcor-ip.net) 09.37.53 Quit Guest_ (Client Quit) 09.38.40 Join n1s [0] (n=nils@rockbox/developer/n1s) 09.39.02 Quit n1s (Remote closed the connection) 09.39.33 Join LinusN [0] (n=linus@rockbox/developer/LinusN) 09.39.38 Join n1s [0] (n=nils@rockbox/developer/n1s) 09.42.40 Join Thundercloud [0] (n=thunderc@cpc1-hem18-0-0-cust660.lutn.cable.ntl.com) 09.43.08 Quit jfc (Read error: 110 (Connection timed out)) 09.49.21 # Llorean: how about this? ;-) http://www.rockbox.org/tracker/task/8314 09.50.06 Join Guest_ [0] (n=chatzill@dslb-088-072-193-157.pools.arcor-ip.net) 09.50.16 Nick Guest_ is now known as MartinR (n=chatzill@dslb-088-072-193-157.pools.arcor-ip.net) 09.50.17 Join kugel [0] (n=chatzill@unaffiliated/kugel) 09.50.31 # jhMikeS: I'm back 09.50.59 # * MartinR saw his name popping up... 09.51.15 *** Saving seen data "./dancer.seen" 09.51.18 # jhMikeS: My point was just that the execution time of the _backlight_fade_* functions will add to the FADE_DELAY. 09.52.23 # jhMikeS: As these functions may be mutexed, fading may become irregular. 09.52.52 Quit Dhraakellian ("Reconnecting") 09.53.16 # jhMikeS: But it's merely visible, even at high CPU load, so... 09.54.37 # MartinR: http://www.rockbox.org/irc/log-20081125#09:14:58 (in case you didn't read his answer) 09.55.34 # MartinR: mutexed? uncontended mutexes are almost a noop and I'd expect any mutexes to be so most of the time. 09.56.25 Join beast__ [0] (n=jude@a82-95-176-205.adsl.xs4all.nl) 09.57.09 # most delay will come from threads executing ahead of the backlight thread. scheduling and i2c communication is microsecond level stuff. 09.58.02 Join The3_14ed|r [0] (n=ntryon@cpe-72-226-197-191.rochester.res.rr.com) 09.58.07 Quit The3_14ed|r (Client Quit) 10.03.36 Quit beast_ (Read error: 145 (Connection timed out)) 10.05.31 # jhMikeS: Damn Phone. Ok, then let's stay with it, I was just kind of concerned. :) 10.06.42 # kugel: Good work on this! 10.07.27 # MartinR: thanks :) But hardly possible without your work before :) 10.08.31 # kugel: ...and all the others before me. :) 10.08.46 # nah, they just failed :P 10.08.58 # * kugel was joking 10.09.34 # jhMikeS: so, if there's no further objections, I think it can be committed 10.11.55 # kugel: I have none 10.16.22 # LinusN: Well, yeah, but it's still not a bug. We don't have a Feature Request tracker any more. :) 10.17.04 Join omgun [0] (n=79b45a2d@gateway/web/cgi-irc/labb.contactor.se/x-42070ce135f0a6a8) 10.19.35 # :-) 10.19.36 # Llorean: are you opposed to having this feature? Afaics Nico_P's patch implements it with minimal costs 10.19.46 # i would surely like it 10.20.06 # i'd like to double-check the license though 10.20.56 # looks like it is gpl compatible 10.21.18 # it is 10.21.44 # then i think we should commit it 10.22.05 # sure! I'd love it 10.22.21 # some people are opposed I think, haven't thought about it myself 10.24.04 # which patch are we talking about? 10.24.18 # jhMikeS: logf showed the fading steps don't even need 1 tick each, except for the last one (which calls _backlight_off) which needs 13 10.24.25 # so I think we're fine 10.24.40 # markun: http://www.rockbox.org/tracker/task/8314 10.26.53 # looks interesting, although I don't see why we wouldn't have this as an option 10.26.54 # The patch says it doesn't require the setting 10.27.02 # I'd really hate for it to do it transparently (or by default) 10.27.06 # kugel: i noticed one interesting thing with the backlight fading patch, the backlight stays on when playing SID tunes 10.27.57 # hmmm, maybe i should check without the patch as well... 10.28.25 # Llorean: I would suggest we rework it a bit a add another setting 10.28.36 # adding more settings? 10.28.40 # yes 10.28.42 # for natural file sorting?! 10.28.45 # yes 10.28.50 # * B4gder agrees 10.28.58 # markun: Yeah, I wouldn't mind it as a setting but I think enforcing filetree sorting to *not* respect the actual strings is a bad idea. 10.29.12 # Llorean: I don't understand your last statement (the transparently) 10.29.15 # LinusN: really? I can't really imagine that it's caused by my patch 10.29.17 # Llorean: that's what I tink as well 10.29.28 # pixelma: Without any prior notification to the user. 10.29.35 Quit Thundercloud (Remote closed the connection) 10.30.21 # * kugel doesn't see a need for a setting 10.30.33 # kugel: that's why you don't have commit rights :) 10.30.37 # then imagine file names with hex numbers in them 10.30.44 # and what that sort will do to them 10.30.57 Join ap0 [0] (n=kvirc@mer90-1-88-166-249-88.fbx.proxad.net) 10.31.32 # There've been a plenty of "bug reports" which said "bug no natural sorting of numbers". I'd be very surprised if there was a bug report like "bug it sorts naturally" 10.31.33 # B4gder: You have files with hex numbers in (on s DAP)? ;) 10.31.51 # * JdGordon names his files in octal... 10.31.55 # I can just think of situations where the "natural" sort may be a bit surprising 10.32.17 # markun: I think that's not the only reason 10.32.24 # indeed :) 10.32.37 # kugel: I'm quite sure we'll see them too if we don't have it as a setting 10.32.38 # * markun goes to work 10.33.22 # markun: but I don't contribute to get commit rights, but to make rockbox better, so I still state my opinion about stuff 10.33.24 # the only way I see people wanting pure string-based comparison would be that natural sorting doesn't work 10.33.38 # but I do wonder if it can work always, given the bizarre naming schemes people can have :) 10.33.52 # flux: which is when the names don't feature "natural numbers" I guess 10.34.02 # kugel: and I think that's a good thing 10.34.31 # but I'm not feeling strongly about this topic really 10.34.34 # yeah, perhaps someone has a directory with tunes like 59113.mp3 and 99.mp3 and really wants 9 to be after 5 10.34.44 Join pondlife [50] (n=Steve@rockbox/developer/pondlife) 10.34.44 # sometimes I see commits and wonder why it hasn't been discussed before (or if I missed the discussion) 10.34.53 # kugel: How's it "better" to cause files to unexpectedly sort in ways that don't reflect their filenames? 10.34.55 # * rasher can't imagine any non-contrived example where natural sorting would be wrong/unexpected 10.35.08 # At least with "literal" sorting you can justify it. "Natural" sorting has to be incredibly intelligent to never make errors. 10.35.40 # And it's pretty trivial to have filenames that will always work with literal sorting anyway. If there's not an option, it more or less should just stay literal. 10.35.57 # maybe we can make it the default after we've had it as a setting and everyone agrees it's better? 10.36.01 # Llorean: and how's it better when files are unexpectedly sorted by purley their first digit when they have the track number leading? 10.36.25 # kugel: It's better because at least there's a 100% consistent sorting method that people can plan for. 10.36.28 # If you want to sort by track number, use tags, IMHO. Filenames might, or might not, start with a track number. 10.36.39 # anyway, the settings submenu for sorting stuff is already there, another setting wouldn't hurt too much 10.39.18 # * linuxstb wonders if people will understand the term "natural sorting" though... 10.39.52 # "naturally I want them sorted" ;-) 10.40.02 # with literal sorting you will know a way how to get the names sorted as you like it - with this natural sorting it might not be that obvious how to get them there if some files are not in the place you want it 10.40.43 # pixelma: could you give me an example? 10.40.51 # It's similar to the "The" prefix issue... tags can solve it anyway 10.40.58 Quit n1s (Remote closed the connection) 10.41.24 Quit jhulst (Read error: 113 (No route to host)) 10.41.29 # linuxstb: if they don't they should rtfm ;p 10.41.30 # we don't want to read the tags to sort file names 10.41.38 # LinusN: no, it also depends on the "cleverness" of the algorithm 10.42.00 # LinusN: I mean - if you don't want to rename your files, use the database 10.42.09 # LinusN: I think his point was more "the database exists for sorting based on other attributes than the actual filename string" 10.42.18 # Yes 10.42.30 # pixelma: You might know how to get the names sorted, but Joe User won't. He'll just see "it's sorting my files wrong! 10 is larger than 4!" and moan a bit. 10.42.45 # Joe the User ;) 10.42.47 # rasher: most users like that use the database anyway. 10.42.51 # as i see it, only engineers think that ascii sorting makes sense 10.43.13 # * kugel agrees 10.43.18 # "banana22" and "c10k" , sorts in what order? 10.43.20 # +1 10.43.31 # Unsurprisingly, I agree with LinusN on this as well 10.43.40 # B4gder: b before c 10.43.51 # ok, so it needs the same prefix? 10.43.57 # Huh? 10.44.05 # z10 an zz9 ? 10.44.18 # which comes first? 10.44.27 Join culture [0] (n=none@cpc1-bele3-0-0-cust658.belf.cable.ntl.com) 10.44.32 # "54 Cymru Beats.mp3" and "50%.mp3"... 10.44.32 # ? 10.44.42 # does this sorting only affect numerical values or characters as well? 10.44.47 Join n1s [0] (n=nils@rockbox/developer/n1s) 10.45.05 # ok, should have read the title better :P 10.45.13 # B4gder: z10. Numbers sort before letters afaik. So you're comparing "10" and "z9" 10.45.35 # kugel: that backlight stays on with plain svn too 10.45.46 # The change is to assume that leading numerics are a track number, no? 10.45.51 # What comes first, 007 - James Bond, or "01 - Pilot" 10.46.04 # Sometimes leading zeros are intentional 10.46.26 # Llorean: he is not named 007 to be sorted in a specific order 10.46.37 # it's because he has a license to kill 10.46.43 # LinusN: now idea why. I haven't any of this rare audio formats, but I'd guess it's limited to sid 10.47.11 # LinusN: Yes, but if I had folders named after various things, I'd REALLY liked 007 to show up at the top, instead of between "4 Rooms" and "9 and 1/2 Weeks" 10.47.20 # only chuck norris would sorted before 007 10.47.28 # LinusN: I would not want Rockbox to assume that "59 Lyndhurst Grove.mp3" referred to track 59, or "2 + 2 = 5.mp3" was track 2.. 10.47.33 # Llorean: that's because you are used to ascii sorting 10.48.04 # pondlife: then turn off natural sorting in the settings 10.48.20 Quit omgun ("CGI:IRC (Ping timeout)") 10.48.28 # LinusN: I think we're more trying to justify why it _must_ be a setting, which I think is agreed anyway. 10.48.33 # pondlife: It's not making any guesses that they are track numbers. It's simply sorting using more human-friendly comparisons 10.48.45 # Just clarifying to some people who think it's not necessary for it to be a setting why it'd interfere with normal use for some of us 10.48.48 # comparisons or assumptions... 10.48.48 # the ONLY way to do it properly is to have a .direcottyr file which could cancel natural sorting 10.48.58 # pondlife: the patch adds nothing to the interpretation of a leading number as a track number 10.49.08 Join omgun [0] (n=79b45a2d@gateway/web/cgi-irc/labb.contactor.se/x-a98bbaa6e037ff19) 10.49.26 # I'll dare you to find any non-engineer type that thinks ascii sorting makes sense 10.49.35 # rasher: +1 10.50.00 # pondlife, you would expect to find the 2 + 2 after 59, right? 10.50.03 # rasher: You'll just classify anyone I find as either "an engineer type" or "someone who's gotten used to it" 10.50.05 # It's a pointless challenge. 10.50.16 # pondlife, would you expect 2 + 2 before or after 100 + 100 ? 10.50.17 # Besides, why the prejudice against engineer types? 10.50.24 # They're the most likely people to be installing our software anyway 10.51.02 # Joe is also likely to use rockbox 10.51.04 # exactly our point 10.51.05 # flux: I'd use the tracknumber ;) 10.51.17 # once he heard of it 10.51.25 # and then he files a bug report about sorting 10.51.26 # people that want natural sorting should be using the database anyway 10.51.35 # track number is the only reason to want it 10.51.36 # As long as there's a setting, I have no objections 10.51.43 # So, what else do we add to sorting 10.51.52 # Do we interpret words like "nine" as a numerical "9"? 10.52.00 # I mean, how far do we support "parsing" strings in filenames? 10.52.06 # Llorean: that's a silly argument 10.52.15 # Llorean: No, just treat leading numerics as numbers. 10.52.19 # LinusN: I guarantee we get a feature request for something in that line eventually 10.52.36 # Well, we'd respond that it was a silly request 10.52.36 # Llorean: sure, but that doesn't make sense. this does. 10.52.50 # pondlife: This isn't just about leading numericals. At least the article mentioned in the other channel covers sorting z1 z2 z10 rather than z1 z10 z2 10.52.51 # kugel: I would open such a bug report at the same instant natural sorting (without an option to disable it) would go in 10.53.05 # LinusN: It might make just as much sense to "Joe Average" 10.53.05 # Llorean: Other channel? 10.53.10 # pondlife: Community 10.53.28 # If the article is relevant, post a link here? 10.53.31 # It's exactly not about leading numbers. It's about treating numbers as a unit when sorting, and comparing them numerically 10.53.38 # pondlife: http://www.codinghorror.com/blog/archives/001018.html 10.53.38 # Sortof. 10.53.55 # LinusN: Do you have backlight on track change enabled? (re the SID problem) 10.54.12 # We could start with just leading numerics though. 10.54.15 # LinusN: Do we evaluate fractions? 10.54.22 # That would catch most cases of track number 10.54.25 # LinusN: Is 1/2 between 0 and 1, or 1 and 2? 10.54.33 # If we're going by what "Joe Average" expects...\ 10.54.40 # amiconn: aha, yes i do 10.54.48 # afaik / ain't allowed in filenames 10.55.03 # Llorean: now you are being unnecessarily argumentative 10.55.05 # 1/2 probably means 1 of 2 10.55.09 # ah, the "caption backlight" doesn't work correctly with .mod too because it doesn't/can't report playback times 10.55.21 # correctly 10.55.28 # LinusN: My point is more that it's not wholly predictable unless you publish a detailed description of its decision making process. 10.55.40 # What about accented characters - while we're at it.. 10.55.41 # ? 10.55.59 # Llorean: it might not be, but in the typical case (leading track numbers), it is 10.56.11 # Llorean: no one ever claimed it would match everyone's assumptions, but it sure is closer than asciisort 10.56.20 # exactly 10.56.33 # Ascii sorting is at least predictably by anyone simply. 10.56.34 # pondlife: now that's a different matter 10.56.46 # You don't need to try to "guess" since you just compare characters one column at a time. 10.57.00 # Llorean: Where "anyone" means "someone who knows these details" 10.57.13 # LinusN: Yes, I guess that needs rather more .lang-style support :/ 10.57.16 # rasher: We have how many thousands of users, and we've had maybe 3 bug reports on it? 10.57.29 # Llorean: to anyone who knows the ascii table well 10.57.35 # It's not like it's arcane knowledge hidden in a tome at the bottom of a crypt. 10.57.42 # I'd go for a simple, leading-numerics-only, version to start with. 10.57.44 # which doesn't apply for most of the people 10.57.55 # * amiconn would rather want proper unicode collation than this so called "natural" sortin 10.58.07 # Llorean: Doesn't mean people haven't been annoyed, and it further doesn't mean it's right, just because we've shoved something poor down the throat of the users 10.58.07 # kugel: That's only applicable in cases where "natural" sorting wouldn't change things anyway. Invalid point. 10.58.13 # amiconn: that won't help in this case (track numbers) 10.58.35 Quit omgun ("CGI:IRC (Ping timeout)") 10.58.37 Join omgun [0] (n=79b45a2d@gateway/web/cgi-irc/labb.contactor.se/x-3d7b643713c9942f) 10.58.51 # Obscure characters in the ascii table would still sort in their obscure order, "natural" sorting or not. 10.59.12 # LinusN: Of course not 10.59.30 # amiconn: I don't see how we could ever hope to implement proper sorting though. It's a huge task 10.59.34 # We might as well just give up 10.59.58 # so, I think the consensus is clear: It can go with a setting, so that engineers can stick to their logical and always predictable asciisort 11.00.38 # and sorting is language dependant 11.01.03 # remember the turkish! ;-) 11.01.54 # but the flamewar is not over, now we have to decide what should be the default! :-) 11.01.57 # and German and some Scandinavian language(s) have different sorting for some characters if I remember correctly 11.02.13 # yes, umlauts are sorted differently 11.02.24 # yes 11.02.28 # Hence my lang comment.. 11.02.45 # markun: Indeed, and I expect this to crop up for tons of languages. I don't think it's in the scope of a DAP firmware to get this right 11.03.13 # pixelma: and ascii sort will handle umlauts better than natural sort? 11.03.45 # LinusN: While I agree "natural" is intuitive for a lot of users, when it sorts 1, 10, 100, 2 you can *see* what's wrong and look for a setting. When 007 is stuck between 4 and 9, I think it's actually more confusing about what "went wrong" with where it shows up. 11.04.03 # I don't see how this contributes to the discussion. Language specific issues will always be a problem with asciisort as well as natural sort 11.04.07 # As can be evidenced by bug reports so far, they at least know what's going on when it happens. 11.04.48 # kugel: huh? It's not related because that natural sorting applies to numbers - at least following the patch's description. And I didn't want to state it as related... 11.06.30 # Llorean: Only the ones who file bug reports 11.06.43 # kugel: hence *I* didn't mention it, just confirmed the fact markun stated ;) 11.07.35 # Ok, it should've been directed to markun as well 11.07.50 # rasher: If they don't file a bug report, they probably don't think it's a bug, and so *also* understand what's going on (at least to the degree that they'll look for sort options) 11.08.01 # Llorean: That's quite an assumption 11.08.07 Quit linuxstb (Read error: 60 (Operation timed out)) 11.08.22 # My point, more or less, is that I think unexpected natural sorting will look like an actual "bug" to the unexpected, while unexpected ascii sorting will just look like "stupidity" and be something they'll look for a setting about 11.08.33 # I think the more likely scenario is "it's sorting my files weird... oh well" 11.08.42 # The average user doesn't file bugs. It simply doesn't happen 11.09.13 Quit culture (Read error: 110 (Connection timed out)) 11.09.26 # So do we want to inspire bug reports, or "ah wells"? 11.09.37 # I don't see how this does either 11.10.00 # I think for someone expecting ascii sorting, natural sorting can look very buggy in edge cases. 11.10.23 # Someone expecting ascii sorting should know better 11.10.29 # and who is ever expecting ascii sort when he's new to something? 11.10.46 # kugel: People who install third party firmwares on their MP3 players because they're FOSS geeks? 11.11.05 # so 1% of the human population, ok 11.11.06 # Our primary audience here is the "enginerd", guys. 11.11.30 # Llorean: Those people are far more likely to understand what's going on than the reverse situation 11.11.34 Quit ap0 ("Baļ") 11.11.55 # "Oh it's doing natural sorting" is far more likely to happen than "Oh, it's doing asciisorting" 11.11.56 Quit omgun ("CGI:IRC (EOF)") 11.12.20 Join omgun [0] (n=79b45a2d@gateway/web/cgi-irc/labb.contactor.se/x-4ac342c810011072) 11.12.23 # also, natural sorting is kind of common these days 11.12.24 # rasher: Only if you have evidence to show you it's "natural sorting" 11.12.29 # I would suggest we just implement it as a setting and then worry about the default later 11.12.38 # If your files are numbered safely for asciisort, and then you get ridiculous single out of place files, you don't have a clue. 11.12.54 # so if I have my filenames already in a way "ascii sorting" sorts them correctly, the "natural sorting" would drop the leading zeros and then start sorting? Sounds complicated 11.13.28 # pixelma: it'd reach the same conclusion though, assuming you've set up your files to sort logically 11.13.30 # pixelma: and that would give the exact same result, wouldn't it? 11.13.42 # rasher: Not necessarily 11.14.28 # yes, but with an overhead in the firmware (I just remember other occasions where it was argued that "this is what you have your PC for") 11.15.23 # pixelma: I sincerely doubt any significant amount of time is spent sorting 11.15.47 # rasher: If i have "002 - Filename" and "01 - Filename" their sort order would change depending on natural or ascii. 11.15.56 # Besides, you can always set ASCII sorting... 11.16.07 # "natural" to me says "the DAP knows better than you do, what order to sort your files in" 11.16.12 # Llorean: yes, but would you name them like this and claim it is the "correct" sort order? 11.16.14 # Which is irritating if you've already picked your own sort order. 11.16.28 # LinusN: In the 007 and 4 Rooms situation, yes. 11.16.44 # and if it comes across differently, these are only thoughts for developing my own opinion... rasher: but bin size ;) - sorry to overstress this argument 11.16.59 # pixelma: It's rather tiny without a setting, less than 1k. 11.17.02 # sigh 11.17.17 # discussions like these make me tired 11.17.35 # Is there anywhere else in the firmware where we assume we know better than users about their own data? 11.18.19 # gevaerts: I was just talking to omgun and it looks like he managed to enter DFU mode of his Samsung T9 11.18.37 # Llorean: this is not a case of "knowing better", it's about helping out when the user doesn't have leading zeroes in the track numbers 11.19.09 # it's a nice feature 11.19.23 # LinusN: Except we're on the point of default enabling now. 11.19.37 # Nobody's denied it's a nice feature, just whether it's nice to override their file naming by default. 11.19.53 # Well, at least *I* haven't denied it's nice for some. 11.20.11 # my point is that the "clueless" user should have the least resistance from the firmware 11.20.46 # LinusN: We've never worked on that policy before. We've always more or less exposed the core, gritty details of what's going on, and then let them do with it what they will. 11.20.47 # * rasher agrees 11.21.12 # I mean, "lease resistance" would be hiding all the advanced options until someone enabled viewing them, so they don't feel overwhelmed, etc. 11.21.24 # did i say that? 11.21.32 # Sorry, you said "least resistance" 11.21.34 # I typoed it. 11.21.47 # no, i mean about hiding options 11.22.08 # No, my point is that it's the same situation, in a way 11.22.24 # "lease resistance" for casual users, or "technical for advanced users" 11.22.24 # i disagree 11.23.14 # if we enable natural sorting by default, i bet most users won't even notice 11.23.51 # Llorean: even less than 1k could mean my voice file(s) won't work anymore on my Ondio and that number was retrieved from a Gigabeat build, there could be differences depending on architecture, but I actually didn't want to go into that argument :( 11.24.09 # LinusN: Do we think "most users" notice it's not available now? I'd hazard the majority of people who expect it use the database anyway. 11.24.23 # LinusN: It's really surprising how often people don't realize you can even get to your music through the filetree these days. 11.25.29 # typ :_) 11.25.32 # oops 11.25.33 # * n1s has nothing against the feature, even if enabled by default but *please* don't call it "natural" sorting in a setting, the term does not mean _anything_ and is AFAIK not commonly used (in user interfaces) either 11.25.59 # n1s: that's probably because it isn't an option in other softwares ;-) 11.26.06 # Anyway, I'm just saying, I think it's *more* likely to inspire bug reports over time if enabled by default. 11.26.14 # like Windows Explorer or XBMC 11.26.41 # Does "natural" sorting apply only to numbers, or will it include things such as "the" ignoring, etc? 11.26.48 # only numbers 11.27.14 # I agree - call it "numeric sorting" or similar.. 11.27.14 # LinusN: probably, so if we go with a setting i'd like us to use a descriptive name 11.27.27 # Or just "Ignore leading zeros" 11.27.32 # ignoring "the" is a different matter (and something i have no objection to) 11.27.33 # Under the sorting options somewhere. 11.27.37 # llorean, what would not be accurate 11.27.52 # flux: "Assume infinite leading zeros for all numbers"? 11.28.02 # llorean, well that's just awkward don't you think?-) 11.28.11 # LinusN: Ignoring "the" is vastly more problematical than this, I think. 11.28.25 # Llorean: not at all, if you stick to english :-) 11.28.29 # atomic number sorting maybe? :) 11.28.40 # heh, nuclear digits 11.28.42 # LinusN: Only if you want ALL "The"s ignore. 11.28.51 # Llorean: of course 11.30.33 # * LinusN goes to lunch 11.31.45 # LinusN: Another (more radical) idea (in general). If Rockbox is booted without a config.cfg present (first boot), take them through several options they may wish to disable/enable and ask them what to set them at. 11.32.03 # This way options like fade on stop-pause, where people may just think it's annoying but not optional, get shown to the user and set. 11.32.20 # This would also well suit the numeric sorting question 11.33.04 # Llorean: i like that idea, many newer phones etc do it on first start up. As long as it's easy to escape the guide 11.33.39 # n1s: I imagine it could also be done as a plugin that's run when config.cfg isn't found, so that there's very minimal bin cost, and if the plugin's missing, we just behave like we do currently and assume defaults. 11.34.19 # I think that's a good idea 11.34.22 # Llorean: my thought exactly, but as always this would then depend on that plugin localization patch... 11.34.37 # B4gder: any news on that? 11.34.48 # nope 11.35.12 Join IanS [0] (n=ian@nbrackheath.plus.com) 11.35.33 # n1s: Well, we'd be using the localization strings from the core binary anyway. 11.35.57 # Maybe that could be made available in a simpler way? 11.36.51 # Llorean: i was thinking of displaying a breif explanation for each setting in the guide, which could easily add up to a lot of kB 11.37.17 # We have a manual for that anyway. 11.37.37 # We could add a summary of the "wizard" plugin's options to the getting started section of the manual 11.37.53 # And maybe make it available as its own PDF if we ever get that quickstart guide idea going. 11.38.05 Nick Darksair is now known as Awaysair (n=user@125.33.198.70) 11.38.09 # hello there 11.38.25 # then i don't see the point, if they need to read the manual anyway the could just use the regular menu 11.38.43 # I just wanted to say how excellent Rockbox was on my Sansa - finally I can play some decent audio formats! 11.38.48 # n1s: The point is to throw the most significant UI settings at them in advance. 11.38.55 Quit kugel (Remote closed the connection) 11.39.02 # unfortunately, that infamous mainboard-breaking code caused me to drop my player and smash the screen 11.39.05 Join kugel [0] (n=chatzill@unaffiliated/kugel) 11.39.17 # i just wondered what you think is the best hardware to run rockbox on, as i am considering purchasing another device 11.39.18 # n1s: Fade on stop-pause is a major one, we get bug reports on it from time to time. Sorting would be a major one, because bad assumptions there could also inspire bug reports. 11.39.44 # Basically, any time we would normally make an assumption about user preference by turning something on by default instead of defaulting to off and letting them enable it, instead prompt them for it. 11.39.58 # IanS: Depends on your needs. There's a page in the wiki called BuyersGuide that can help some 11.40.06 # Llorean: i think it would be way more helpful to display a brief explanation in the plugin for this handful of UI settings 11.40.24 # n1s: Possibly *more* helpful, but I don't think it's necessary before the plugin can be useful. 11.40.41 # I wouldn't say "what's the point" if we can't add localized descriptions yet. 11.40.45 # great i'll have a look, thanks 11.48.30 Join JdGordon_ [0] (n=jonno@rockbox/developer/JdGordon) 11.51.19 *** Saving seen data "./dancer.seen" 11.57.24 Quit JdGordon_ ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 12.04.41 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 12.10.08 Quit omgun ("CGI:IRC") 12.10.27 Join omgun [0] (n=79b45a2d@gateway/web/cgi-irc/labb.contactor.se/x-82e781de69ae9894) 12.11.12 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 12.14.20 Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) 12.14.29 Nick Awaysair is now known as Darksair (n=user@125.33.198.70) 12.15.02 Join thegeek_ [0] (n=nnscript@s243b.studby.ntnu.no) 12.15.38 Quit nuonguy ("This computer has gone to sleep") 12.16.28 Quit MartinR ("ChatZilla 0.9.84 [Firefox 3.0.4/2008102920]") 12.18.32 Quit thegeek (zelazny.freenode.net irc.freenode.net) 12.18.32 NSplit zelazny.freenode.net irc.freenode.net 12.18.32 Quit Kopfgeldjaeger (zelazny.freenode.net irc.freenode.net) 12.18.32 Quit J-23 (zelazny.freenode.net irc.freenode.net) 12.18.32 Quit neddy (zelazny.freenode.net irc.freenode.net) 12.18.32 Quit Unhelpful (zelazny.freenode.net irc.freenode.net) 12.18.52 NHeal zelazny.freenode.net irc.freenode.net 12.18.52 NJoin thegeek [0] (n=nnscript@s243b.studby.ntnu.no) 12.18.52 NJoin Kopfgeldjaeger [0] (n=nicolai@monitor-mode-enabled-on-mon0.phy0.de) 12.18.52 NJoin J-23 [0] (n=zelazko@unix.net.pl) 12.18.52 NJoin neddy [0] (n=john@nat/sun/x-214d213f74b4d691) 12.18.52 NJoin Unhelpful [0] (n=Militant@pool-98-117-9-134.hrbgpa.fios.verizon.net) 12.20.52 Join skipper [0] (n=skipper@213.147.115.74) 12.27.02 Part pondlife 12.29.22 Quit robin0800 (Read error: 104 (Connection reset by peer)) 12.30.16 Join Llorean1 [0] (n=DarkkOne@adsl-65-68-75-55.dsl.hstntx.swbell.net) 12.30.46 Quit Llorean (Nick collision from services.) 12.30.51 Nick Llorean1 is now known as Llorean (n=DarkkOne@adsl-65-68-75-55.dsl.hstntx.swbell.net) 12.34.24 # gevaerts: I download the T9 firmware and it's *not* encrypted 12.35.31 Quit thegeek (Connection timed out) 12.41.27 Join Nico_P [50] (n=nicolas@rockbox/developer/NicoP) 12.42.41 Join moos [0] (i=moos@81-66-158-133.rev.numericable.fr) 12.44.01 Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) 12.45.54 # does anyone have some info about Samsung's Whimory FTL? 12.46.55 # denes_: I found out that the Samsung T9 (also S5L8700 based) uses the Whimory FTL as well 12.48.56 # Nico_P: hi. there was a discussion about your (rotting) natural sorting patch 12.49.12 # kugel: oh, interesting. I'll read the logs 12.50.08 Quit omgun ("CGI:IRC (Ping timeout)") 12.58.25 Quit japc (Read error: 110 (Connection timed out)) 12.58.41 Quit kugel (Remote closed the connection) 12.59.37 # IMHO very few "normal users" would prefer ASCII sorting over natural sorting 13.00.25 # to me, the correct question is whether rockbox attracts (or should attract) these "normal users" 13.04.18 # i believe i would prefer natural sorting 13.05.09 # most of the time i wouldn't notice a difference, and when i do find tracks without leading zeroes in the filename, i woudl appreciate it when it sorted them numerically 13.05.32 # it's pretty much the same for me 13.09.40 # besides, i think some features may be unnecessary because there exists a workaround, but it is imho much nicer when it "just works" 13.09.56 # this is one of those cases 13.10.03 # embedded album art is another 13.12.07 # as a non "normal user" I think EAA is the biggest waste of disk space ever :( 13.13.15 # Yeah, but supporting it wouldn't waste your disk space at least. 13.13.43 # I imagine the issue is more "jpeg in the core" than EAA anyway. I can't imagine reading the metadata out of one more tag is huge overhead compared to jpeg decoding. 13.15.23 # No I suspect not 13.15.35 # I'm just not in a hurry to go embedding the same jpeg into 18 files 13.15.52 # so long as we keep our existing AA solution (add jpeg support to that would be nice), I'll be happy 13.16.32 # I can't imagine removing our existing AA solution, since it also beautifully allows fallback images for Artists if an album image isn't there, and further fallback for genre, etc, right? 13.16.40 # Since it looks in parent folders? 13.16.44 # yep 13.17.05 # I just don't want the bin-size crowd asking for one solution or the other - I'll cry :) 13.17.57 # Being occasionally part of the "binsize" crowd, my view on binsize is "if you'd be willing to remove it for something else later, don't add it in the first place" 13.18.07 # I agree EAA is a waste of space for albums, but it seems to have become quite a de-facto standard and it's quite practical for single tracks 13.18.07 Quit jhMikeS (Read error: 104 (Connection reset by peer)) 13.18.24 # So, we shouldn't be removing functionality (which this would) for the sake of binsize, and we shouldn't add something we'd be willing to sacrifice for something else later (assuming that sacrifice wasn't transparent to the users) 13.18.39 # and it's a thing that would make rockbox shine 13.18.50 # Nico_P: if people are going to use it, it's the best argument for single MP3s and cuesheets imo. 13.20.06 # true 13.20.19 Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) 13.20.34 # chaptered MP4 files are rather close to that 13.21.26 # I would really like to have nice support for that. with pics and all 13.22.37 # this type of debate makes me realize that we don't know much about our typical users 13.22.54 # * GodEater doesn't think we have "typical" users 13.23.09 # do we have to? 13.23.33 # I think we should 13.23.43 # * gevaerts grabs his lamp and goes searching for a typical user 13.24.07 # lamp.rock ? 13.24.13 # i.e. we could perhaps think about running a survey to get an idea of what people value the most 13.24.35 # * GodEater thinks this qualifies as "a can of worms", or "pandora's box" 13.24.50 # How? How many forum users do we have compared to total downloads? 13.24.57 # B4gder: of course :) 13.25.17 Join Bensawsome [0] (n=Bensawso@unaffiliated/bensawsome) 13.25.32 Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) 13.25.35 # GodEater: we wouldn't have to let it define the future directions. it would just give us a clearer view of things 13.25.59 Quit robin0800 (Remote closed the connection) 13.26.03 # * gevaerts thinks that assuming that forum users are typical users is probably just as unfounded as assuming that developers are 13.26.06 # Nico_P: and what would you do with the outcome? Code something else, even if it is something you are not interested in? 13.26.18 Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) 13.26.53 Quit robin0800 (Remote closed the connection) 13.27.11 # pixelma: seem my statement above. I would probably use the outcome to weigh and order my priorities 13.27.18 # s/seem/see 13.27.59 Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) 13.28.30 Quit robin0800 (Remote closed the connection) 13.31.47 # now that we have a freeze coming up in a couple of weeks (we do, right?) would it not be a good time for a "tracker cleanup" or at least a focused look at open bugs and patches? 13.31.58 # Nico_P: You could hide some spyware in Rockbox that reports the user's behaviour to rbutil... 13.32.35 # n1s: you're right, it would be a good time... 13.32.46 # btw, i like the wizard plugin idea 13.32.52 # * linuxstb wasn't sure if a freeze-date had been agreed 13.33.29 # linuxstb: haha, awesome idea :) 13.33.58 # some projects actually do that btw 13.34.34 # Yes, I can imagine... In fact, rbutil could report some info without any changes to Rockbox - e.g. the config.cfg and statistics on the types of audio files on the user's device. 13.35.13 # "would you like rbutil to anonymously report about your config to the rockbox developers?" 13.35.37 # Or rather, would you like rbutil to uplaod the following file to the Rockbox develoeprs? (showing the actual data being sent) 13.35.48 # that might be even better, yes 13.36.09 # How much would that really tell us? 13.36.14 # Or rather, how much could that information affect? 13.36.32 # I don't know until we have that info... 13.36.45 # But, I mean, what question are we trying to answer? 13.37.07 # Isn't it features we *don't* have that are more interesting? 13.37.12 # ok, so i'll send a mail to the list urging people to look at the tracker, confirm, fix, close, commit, set "due in version" on important ones etc. next week ok? 13.37.35 # n1s: sounds fine to me! 13.37.52 # btw, _did_ we decide on a freeze date? 13.37.59 Join tyfoo [0] (n=tyfoo@dyndsl-095-033-101-182.ewe-ip-backbone.de) 13.38.31 # Llorean: I'm just curious about how Rockbox is used. It won't necessarily change anything. 13.38.40 Quit shodanX (Read error: 110 (Connection timed out)) 13.39.09 Join funman [0] (n=fun@AToulouse-158-1-34-203.w90-50.abo.wanadoo.fr) 13.39.13 # Ah, well that's okay then. 13.39.33 # n1s: I don't know, I think the discussion was split between 3 months (i.e. just before Christmas) and 4 months (end of January) for the release date. 13.40.24 # linuxstb: oh, so when christmas comes up we'll just say "oh, we never froze, lets release in january" :/ 13.40.28 # hi, I found a bit more details about how the SD driver fails in the sansa ams bootlaoder 13.40.40 # having information about what settings are used *could* help us set good defaults 13.41.36 # Nico_P: Yes, but it's hard to say if someone uses the current default because he/she prefers it, or simply because he/she didn't know it could be changed. 13.41.40 # the first sector is well read, the 2nd and 3rd sectors are read (2*127 sectors) too far in the file; the 4th to 9th sectors are read (1*127) sectors too far away in the file 13.42.01 # I think most of the defaults are "okay" in terms of "they're features that should be left off unless someone wants that specific feature" like equalizer, etc. 13.42.16 # it could (well, must) be related to the fact that we want to read maximum 127 sectors at a time 13.42.21 # There's a few that are matters of taste/desire (like sorting would be) that would be better served by the wizard than trying to guess whether to turn something on or not. 13.42.46 # Especially given that people will often assume there's *not* a setting if software appears to do something they don't think is a sane default. 13.43.18 # could the wizard idea be extended for RBUtil? I.e. during the first install RBUtil could already ask the user about some settings and write the config.cfg accordingly 13.44.20 # If it didn't execute unless config.cfg was present, it could be in either or both without real problems. 13.50.07 Join kugel [0] (n=chatzill@unaffiliated/kugel) 13.51.23 *** Saving seen data "./dancer.seen" 13.52.07 Join kushal_12_27_200 [0] (n=kushal@72.47.189.130) 13.55.34 Join shodanX [0] (n=shodanX@jazz.informatik.uni-erlangen.de) 13.56.19 Join Lynx_ [0] (n=till@xdsl-87-78-186-7.netcologne.de) 13.58.29 # funman: the button driver isn't quite reliable. I sometimes get just a black screen (i.e. the clear of the lcd worked) without text (i.e. the printfs after the clear did not work) 13.58.56 # in the bootloader that is. As for the main, going by e200v2 testers, buttons do not work at all 13.59.09 # kugel: i'm not sure what that means; how do you know this problem is caused by buttons ? 13.59.36 # funman: because I only get the black screen when I press a button 13.59.48 # also, buttons and lcd are connected in someway on the e200v2/fuze 14.00.17 # remember the afsel has to reset after to make the lcd work again 14.00.21 # kugel: perhaps try to disable irq before modifing gpio*_afsel, and enable them when you restored the registers ? 14.00.42 # I could try that, yea. 14.01.47 # "going by e200v2 testers" : does that mean you didn't try to use buttons in the main build ? 14.01.59 # Also, I'm not entirely sure, but I think the black screen issue appears a bit more often when I remove the gpio*dir stuff. Maybe be randomly happen as well though 14.02.23 # funman: no not yet, since I yesterday only tried to find some more buttons 14.02.44 Join nplus [0] (n=nplus@141.25.Globcom.Net) 14.03.08 # i bet if they didn't find them on e200 you won't find them either; perhaps the other buttons & wheel are read through DBOP like fdinel suggested 14.03.09 # and I used the bootloader which doesn't work so I never came to the main build (which wasn't bad for that purpose) 14.03.32 # possibly 14.04.03 # can one see that by the traces on the pcb? the scrollwheel and the buttons both go in the zif connector 14.04.29 # that's why I wouldn't think they're read totally different, but who knows 14.05.18 # I fixed the bootloader \o/ 14.05.36 # funman: I tested some GPIOA, but got a white screen only by reading them, can you explain that? 14.05.58 # kugel: no i can't. perhaps those pins you tested have a special meaning ? 14.06.30 # the A is mostly for that other i2c bus, not sure how that's related to the white screen 14.06.59 # great job, are you going to commit the dma stuff soon'ish now? 14.07.52 # yes of course ! :) the problem was that i was not incrementing the destination (SDRAM) pointer, so the data was overwritten if we were transfering more than 127 sectors; which only the bootloader appears to do 14.08.52 # the bootloader appears to some other stuff different as well, given that the buttons don't work in the main build but in the bootloader 14.09.26 # kugel: gpio_*dir should be set in button_init_device() and not touched I think 14.09.37 # well, the buttons could be due to quite frequent lcd operations (e.g. updating the statusbar) 14.09.45 # for example 14.11.45 # haven't you said gpio*dir isn't not needed at all? 14.12.19 # you need to set the proper direction once; you don't need to change it if the pins do not have another usage 14.12.36 # ok 14.12.54 # If the *gpio* pins have no other usage. gpio*_afsel selects if the *physical* pin is bound to be a gpio pin or a dbop pin 14.13.05 Quit reacocard (".") 14.13.30 # ah I understand 14.13.55 # at least that is my understanding .. :) 14.14.13 Join reacocard [0] (n=reacocar@WL-135.CINE.HMC.Edu) 14.15.03 Join beast [0] (n=jude@a82-95-176-205.adsl.xs4all.nl) 14.15.05 # funman: why do we even save the afsel? Wouldn't it be enough to set them up for buttons, and after the reading, set them up for lcd again? 14.15.35 Join massiveH [0] (n=massiveH@pool-71-187-243-194.nwrknj.fios.verizon.net) 14.15.48 # sure, but imo this method is cleaner; because you don't have to know the LCD settings in the button code 14.15.59 # well 14.16.38 # uh 14.16.43 # gogogo sansa ams supported in rockbox 3.1 ! 14.16.58 # assuming we leave them for lcd after button_int should be safe imho 14.17.56 # we only need to have them set up for the buttons in button_int, otherwise it's basically always need to set up for lcd 14.18.15 Quit gevaerts (Nick collision from services.) 14.18.24 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 14.18.57 # meh, I'm gonna dig into the data sheet for that once more 14.19.47 # gtg, will see you later with hopefully committed dma code 14.19.53 Quit kugel ("ChatZilla 0.9.84 [Firefox 3.0.4/2008111318]") 14.28.44 Quit tvelocity (Read error: 110 (Connection timed out)) 14.29.15 Join tvelocity [0] (n=tony@adsl15-236.her.forthnet.gr) 14.30.39 Quit beast__ (Read error: 110 (Connection timed out)) 14.33.31 Part B4gder 14.36.42 Quit kharo ("Leaving.") 14.37.17 # make zip shows ":1:20: error : config.h: No such file or directory" 14.46.11 Join LambdaCalculus37 [0] (i=44a04303@gateway/web/ajax/mibbit.com/x-94a676afb80b4956) 14.47.15 # kugel: (for the logs) I committed the SD/DMA code. Don't forget that you could need to set some pins to DBOP if the other buttons are to be read on this port. 14.47.24 Join {phoenix} [0] (n=dirk@p54B47A76.dip.t-dialin.net) 14.51.16 Quit amiconn (Nick collision from services.) 14.51.22 Join amiconn_ [50] (n=jens@rockbox/developer/amiconn) 14.53.04 # I'm not sure what's the bottom right icon in WPS : if it's PLAY, does it mean it's PLAYing, or it is going to be PLAYing if I press the play button ? 14.53.22 Quit massiveH ("Leaving") 14.57.34 # if it shows play it should be playing 14.58.14 # thanks 14.59.42 # LambdaCalculus37: you can update your Clip to last firmware to have flac support also 15.00.12 # since you have a 2GB model, can you check which size is reported by the internal SD ? 15.00.16 Nick jfc^3 is now known as jfc (n=john@dpc691978010.direcpc.com) 15.00.23 # funman: Can I still mess around with custom code even with 01.01.30? 15.00.35 # LambdaCalculus37: of course, all versions are supported 15.00.47 # funman: Cool. 15.01.16 # which means 1.01.{17,18,20,29,30} for the Clip 15.01.55 # I have pretty advanced reverse engineering of the SD code in the Clip firmware, if your 2GB is reported as 1GB you could be the one that fix the SD driver for >1GB access on the internal storage! 15.01.56 # funman: Memory is reported as 1949MB. 15.02.03 # LambdaCalculus37: by rockbox? 15.02.10 # funman: By the OF. 15.02.18 # funman: you got dma working properly? 15.02.29 # I can't do anything Rockbox related while my Mac is on the blink. 15.02.39 # JdGordon: yes, I was overwriting the transferred data ^^ 15.02.46 # :) well done 15.02.53 # LambdaCalculus37: no hurry, I can code fine with my 1GB Clip ^^ 15.04.59 # * funman checks his list: sound, fm, recording, usb 15.04.59 # funman: Not unless you want to send me a build zip and a bootloader so I can mess around with Rockbox on it for the time being. 15.06.22 # LambdaCalculus37: sure, just give me your email in private 15.07.38 Join japc [0] (n=japc@194.65.5.235) 15.07.58 Quit shodanX (Remote closed the connection) 15.08.56 Join shodanX [0] (n=shodanX@jazz.informatik.uni-erlangen.de) 15.10.43 Join saratoga [0] (n=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-09a25d65f71a1734) 15.12.22 Join Schmogel [0] (n=Miranda@p3EE21B41.dip0.t-ipconnect.de) 15.13.06 # Is rockbox freezing in recording mode for Sansa c250? I used to have the latest builds on my sansa and I thought it was rockbox, but I downgraded to Rockbox stable and the issue remains. The player just plain freezes whenever I go to recording mode via the rec button on the right of hold button. Do you know what's happening? Thanks. 15.13.09 Quit funman ("leaving") 15.13.18 Join jeffdameth [0] (n=jeff@dyndsl-095-033-105-252.ewe-ip-backbone.de) 15.13.32 Join blahrus [0] (n=blahrus@75.150.209.185) 15.18.15 # kushal_12_27_200: do you have the "keyclick" feature enabled? 15.34.25 Join lasser_ [0] (n=chatzill@Wbf06.w.pppool.de) 15.39.08 # * LambdaCalculus37 has Rockbox running on his Sansa Clip 15.40.19 Quit Llorean ("Leaving.") 15.45.36 # n1s: marking all the tasks as "due in 3.1" is probably silly ebcause alot of them wont happen which means more work next time... cant they be marked "next release" instead? 15.45.54 Quit Lynx_ (Remote closed the connection) 15.46.24 # JdGordon: i meant that you should mark the ones you feel are important for 3.1 not everything :) 15.46.58 # I was talking more about the ones you changed from 3.0 -> 3.1 becuase they wern't closed 15.47.08 Join Lynx_ [0] (n=till@xdsl-87-78-186-7.netcologne.de) 15.48.24 Join Llorean [0] (n=DarkkOne@adsl-65-68-75-55.dsl.hstntx.swbell.net) 15.48.27 # JdGordon: ah, well, sure they can be changed to something else it's allready done though and someone felt they were important for 3.0 15.49.09 # also a generic "Next release" is basically the same as the unmarked bugs as that would just be a "would be nice to get fixed" 15.49.59 # But if you feel like you want to change them, feel free :) 15.50.40 # well "next release" means that someone feels strongly enough that it needs some sort of priority... but really the whole thing is useless because its obvious "we" dont really care about the bug count 15.51.02 # nls, keyclick is set to moderate. 15.51.09 Quit lasser (Read error: 113 (No route to host)) 15.51.22 # kushal_12_27_200: it needs to be disabled when recording 15.51.28 *** Saving seen data "./dancer.seen" 15.51.41 # thanks, got it 15.53.57 # JdGordon: there is a priority field too 15.59.40 # is there a bug report on that keyclick issue? 16.02.09 Join pondlife [50] (n=Steve@rockbox/developer/pondlife) 16.04.24 Join kugel [0] (n=chatzill@unaffiliated/kugel) 16.07.50 Join Strife89 [0] (i=a810ebc0@gateway/web/ajax/mibbit.com/x-b8d2768d9e038f27) 16.09.41 # denes_: did you take a look at http://github.com/planetbeing/iphonelinux/tree/master/openiboot%2Fftl.c ? 16.10.47 Join robin0800 [0] (n=robin080@cpc2-brig8-0-0-cust394.brig.cable.ntl.com) 16.11.34 # LambdaCalculus37: did you receive a build from funman already? 16.12.12 # well, i guess you'd also need a svn bootloader 16.12.47 # kugel: Got a build and a bootloader. 16.13.09 # I'm interesting in the result, i.e. will rockbox detect 2 gb 16.17.09 # kugel: Rockbox says the Clip's storage is 1.90GB and 1.86GB free. 16.18.45 # Ha! I have 0KB of buffer! :P 16.19.06 Join funman [0] (n=fun@AToulouse-158-1-52-196.w90-50.abo.wanadoo.fr) 16.19.20 Quit kushal_12_27_200 ("Leaving") 16.21.08 Quit JdGordon (Success) 16.22.42 # LambdaCalculus37: then we will probably need a 4GB Clip to reproduce this problem, I doubt it's specific to Fuze and e200v2 16.24.22 # LambdaCalculus37: so it at least detects full memory 16.24.51 # funman: There is one thing, though... in the debug menu, viewing the partition info shows me four partitions of 0MB each. 16.25.03 # funman: yea, the 2GB probably don't tell much, since non-SDHC goes upto 2GB 16.25.25 # kugel: Now I have 288KB of buffer free after a restart. 16.25.38 # LambdaCalculus37: well, fdisk will look similar. The partition layout is pretty messed up and hacky 16.26.21 # LambdaCalculus37: perhaps you have a superfloppy and no partitin table ? 16.26.45 Quit kugel (Remote closed the connection) 16.26.48 # funman: Perhaps, but right now I have no Unix or Linux near me to work with to find out. 16.27.02 # by default my Clip had no partition table 16.27.16 # and windows xp at least has a volume manager in "admin tools" iirfc 16.28.48 Quit Strife89 ("http://www.mibbit.com ajax IRC Client") 16.33.02 Join kugel [0] (n=chatzill@unaffiliated/kugel) 16.33.21 Quit Schmogel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 16.33.34 Join Schmogel [0] (n=Miranda@p3EE21B41.dip0.t-ipconnect.de) 16.34.35 # funman: time to implement a proper shut down. holding power 10s is still annoying ;) 16.35.22 # but first fix the buttons in the main ofc (indeed, they neither work on the fuze) 16.36.04 # kugel: it's done already. 16.37.32 # funman: haha buttons can't work 16.38.01 # button_int call is within #ifdef BOOTLOADER 16.38.07 # :) 16.38.33 # by the way is button_int() a representative name ? it makes me think of _int_errupts 16.39.05 # in my opinion all the copy pasted code from e200v1 should go away. It's still in e200v1 code if we need to look at it. 16.39.06 Join toffe82 [0] (n=chatzill@h-74-0-180-178.snvacaid.covad.net) 16.39.48 # funman: is the whole asm code only irq enable/disable? 16.39.55 # that one in the bootloader 16.40.01 # yes 16.40.17 # if yes, it should be in a function so that other parts and the core can use the asm verison 16.40.58 # it's already a (generic to all ARM targets) function. I changed it in my tree but didn't commit yet. I guess I am waiting to include it in the next bootloader diff ;) 16.41.40 # I think the bootloader is finished now 16.42.23 # funman: eh, yea, in the pastebin'd patch it was en-/disable_irq() 16.43.45 # committed 16.47.43 # funman: finished bootloader sounds good 16.48.27 # indeed, good progress has been made 16.50.28 # in fact, finished alone sounds already good :p 16.51.27 Join webguest44 [0] (n=407c962a@gateway/web/cgi-irc/labb.contactor.se/x-c1e01c6f744c4c0d) 16.53.09 Quit webguest44 (Client Quit) 16.55.05 Quit Schmogel (Read error: 110 (Connection timed out)) 16.56.25 # funman: disabling irq in button_int ain't good 16.57.42 # kugel: you're confused. A lot of code has been copied from e200v1, and doesn't work on e200v2. The e200v2 doesn't use interrupts at all to read the buttons 16.59.22 Quit jhMikeS (Read error: 54 (Connection reset by peer)) 16.59.29 # funman: you suggested to disable interupts while button reading to make it more reliable 17.00.15 # Oh right, I suggested to disable interrupts when the gpio*_afsel registers are being modified 17.00.55 Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) 17.00.57 # ok. I now just put disable at the very beginning and enable at the very end 17.00.58 # "ain't good" = still leaves you with blank screens ? 17.01.07 # it entirely messes everything up 17.01.31 # the display flickers horribly for a few seconds, then the screen turns white 17.01.51 # eventually I see the rockbox menu for a split second, sometimes it's even mirrored 17.02.00 # anyway, gonna be back in a few minutes 17.02.05 Quit kugel (Remote closed the connection) 17.03.00 # funman: The LCD display on the Clip is rather shaky when scrolling through menus. 17.03.44 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 17.04.49 # LambdaCalculus37: I didn't meet any problem, perhaps we need to insert some delays in the lcd code? 17.11.03 Join mib_v2yq05 [0] (i=2669ecc2@gateway/web/ajax/mibbit.com/x-f07be5ad87131ae3) 17.11.20 Nick mib_v2yq05 is now known as CaptainKewl (i=2669ecc2@gateway/web/ajax/mibbit.com/x-f07be5ad87131ae3) 17.16.52 Quit reacocard (".") 17.19.31 Part pondlife 17.23.41 Quit linuxstb (Read error: 110 (Connection timed out)) 17.24.41 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 17.24.54 Join nibbler [0] (n=sven@e181106203.adsl.alicedsl.de) 17.25.25 # all right, scaling works in greyscale ipod sim. :D 17.26.24 # little ot, can the harddisk of archos 5 be easily replaced? 17.32.41 # nibbler: Please, respect the fact that this channel is for Rockbox discussion. Off-topic things can be asked elsewhere, and should. Thanks. 17.33.06 Join herrwaldo [0] (n=waldo@ip-81-11-222-4.dsl.scarlet.be) 17.33.44 Join kugel [0] (n=chatzill@unaffiliated/kugel) 17.33.50 Quit robin0800 (Connection timed out) 17.34.08 Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) 17.35.10 Quit saratoga ("CGI:IRC (EOF)") 17.38.52 # funman: hmm..disabling irq in bootloader doesn't seem to hurt 17.39.37 # kugel: they are enabled in system-xx as well I think 17.39.43 Quit nibbler ("Ex-Chat") 17.39.52 # ipod4g bin/ram/total sizes: vanilla: 521484/918304/1439788, "old" resize-on-load: 524220/931088/1455308, "new" resize-on-load: 523788/920624/1444412 17.40.06 # funman: I mean the disabling in button int 17.40.20 # kugel: does it do any good ? 17.40.27 # not sure why the same code doesn't work in main 17.41.20 # well no, I still get the black screen 17.41.28 # so just forget about that 17.42.23 # * funman will do 17.44.01 # Unhelpful: what is the second number? difference between bin and ram? 17.44.07 # total. 17.44.13 # oh, wait. 17.44.21 # second is ram, third is total. 17.44.49 # so, up ~5KiB vs vanilla, but down ~10KiB vs old-resize 17.46.55 # ehh, the whole button_int doesn't work even without irq disabling 17.47.59 # funman: LCD line updates are a little weird looking. The lines seem to shift about 2 pixels to the right, and a random pixel appears to the very left. 17.48.16 # Also, the runtime clock is a bit fast. 17.49.34 # ok, yesterday fml asked for runtime comparison on e200 between r19494 and before. Yesterday r19195 ran 7:13h with remaining 62% battery level. Today r19173 drained the battery under the same conditions to 55% after 7:13h - or the other way r19173 ran 6:09 to reach 62% batt level. Conclusion: There is an improvement about 15%. 17.49.35 Quit DataGhost (Nick collision from services.) 17.49.43 Join DataGhost [0] (i=dataghos@unaffiliated/dataghost) 17.50.05 # LambdaCalculus37: which runtime clock? the kernel ticks ? 17.50.15 # funman: No, the "Running time" clock. 17.50.22 # In System > Running Time. 17.50.26 Join pondlife [50] (n=Steve@rockbox/developer/pondlife) 17.50.30 Quit pondlife ("Leaving.") 17.51.21 # if it's derived from kernel tick, yes it's too fast. One need to read the timer doc and fix kernel-as3525.c tick_start() accordingly 17.51.24 # and the newest patch is on FS#9458. testers appreciated, should work on color targets, and greyscale ipods 17.51.31 *** Saving seen data "./dancer.seen" 17.51.56 # no other greyscale targets? 17.55.51 # pixelma: not yet, but they'll come more quickly now that the framework of the nearest-neighbor scaler is done 17.56.27 # I see 17.57.41 # the only thing that should need to change is the innermost loop where pixels are stored to the destination bitmap. the rest is just stepping over input and output rows and columns by the correct increments 17.58.59 # can I block lcd operations while reading buttons? 17.58.59 # "ipods" is gleaned from the old-scaler comments. if there are other 2bpp greyscale targets using horizontal packing, they should work, too. 17.59.43 Join pondlife [50] (n=Steve@rockbox/developer/pondlife) 17.59.55 Join faemir [0] (n=faemir@88-106-186-147.dynamic.dsl.as9105.com) 18.01.58 Quit Lynx_ ("Konversation terminated!") 18.03.48 # pondlife: hey. I think my backlight fade patch is ready to go in 18.04.01 # Yes 18.04.33 # jhMikeS has no objections. 18.08.20 # kugel: At long last? :) 18.08.27 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 18.08.34 # LambdaCalculus37: huh? 18.09.02 # kugel: That your patch is finally ready to go in. 18.09.06 # linuxstb: hi. I've got a problem with the fuze's lcd and buttons 18.09.21 # * kugel didn't know that phrase 18.10.14 # I'd rather not call it officially "my" patch (if I did, only because it's shorter). Some more people contributed to it 18.11.08 # linuxstb: the lcd goes crazy when I enable it for the main (i.e. remove the #ifdef BOOTLOADER around the button_int call) 18.12.25 Quit funman ("leaving") 18.12.26 # I assume there's lcd operations so frequently, that the the safe and reset of afsel isn't quick enough 18.14.04 Quit stoffel_ ("Lost terminal") 18.15.46 Join MethoS- [0] (n=clemens@host-091-097-243-129.ewe-ip-backbone.de) 18.15.52 Quit petur ("*plop*") 18.17.04 Quit skipper ("Leaving") 18.23.10 # kugel: Do you have commit access? Or are you looking for a volunteer? ;) 18.24.32 Join dany_21a_ [0] (n=dan@84-119-1-87.dynamic.xdsl-line.inode.at) 18.25.27 Quit IanS ("Ex-Chat") 18.26.38 Quit ender` (" I spilled Spot Remover on my dog... Now he's gone.") 18.26.56 # pondlife: I don't have commit access 18.27.20 # I'd be happy to commit it, but probably not until the morning 18.27.29 # linuxstb: hm, pressing up inverts the lcd colors 18.27.35 # Maybe someone else would like to pop it in first though 18.28.00 # pondlife: No worries, I can wait until tomorrow :) 18.28.15 # linuxstb: and does not what it's supposed to be 18.28.46 # right button seems to initiate lcd_enable :S 18.29.02 # weird stuff 18.31.08 Quit Darksair ("Zzz...") 18.31.11 Join nuonguy [0] (n=john@c-71-198-1-139.hsd1.ca.comcast.net) 18.40.29 Part dany_21a_ 18.41.26 # what are all these errors? 18.41.48 # I just #included system-target.h 18.43.09 # probably missing implementations.. 18.43.22 # I am talking about http://pastebin.com/m24ecd4e3 btw 18.46.40 # Unhelpful: There are 3 different pixel packings for 2bpp 18.47.44 Join Schmogel [0] (n=Miranda@p3EE21B41.dip0.t-ipconnect.de) 18.48.29 # iPods use horizontal packing (4 pixels per byte), iriver H1x0 and iAudio M5 use vertical packing (4 pixels per byte), and the iAudio remote (which is the main display for iAudio M3) uses a different vertical packing (8 pixels in 2 bytes, with the corresponding bits in the byte pair belonging to the same pixel) 18.48.36 Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) 18.48.56 Join ender` [0] (i=krneki@foo.eternallybored.org) 18.49.12 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 18.49.53 # kugel: Try including system.h, not system-target.h 18.51.17 # linuxstb: thanks that worked 18.51.37 # linuxstb: do you have an idea regarding what I wrote you? 18.53.55 Quit ender` (" The Web is a procrastination apparatus: It can absorb as much time as is required to ensure that you won't get any real wor") 18.54.16 Quit {phoenix} (Read error: 104 (Connection reset by peer)) 18.54.25 Part LinusN 18.56.31 Join hannesd [0] (n=light@p5B160B78.dip0.t-ipconnect.de) 18.57.18 Join miepchen^schlaf [0] (n=miepchen@p579ECAE6.dip.t-dialin.net) 18.57.24 Join Rondom [0] (n=Rondom@dslb-084-057-148-139.pools.arcor-ip.net) 18.58.35 Join el_sneako [0] (n=54bd4f5e@gateway/web/cgi-irc/labb.contactor.se/x-70e92008755ecdba) 19.00.19 Quit el_sneako (Client Quit) 19.00.51 Part hannesd 19.02.55 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 19.05.23 Join {phoenix} [0] (n=dirk@p54B47A76.dip.t-dialin.net) 19.05.26 Join Thundercloud [0] (n=thunderc@cpc1-hem18-0-0-cust660.lutn.cable.ntl.com) 19.05.26 Quit moos ("Rockbox rules the DAP world") 19.05.52 Quit LambdaCalculus37 ("http://www.mibbit.com ajax IRC Client") 19.07.02 Join ender` [0] (i=krneki@foo.eternallybored.org) 19.08.18 Join massiveH [0] (n=massiveH@pool-71-187-243-194.nwrknj.fios.verizon.net) 19.11.20 Join culture [0] (n=none@cpc1-bele3-0-0-cust658.belf.cable.ntl.com) 19.15.27 Join MegafEee [0] (n=Linux@unaffiliated/megaf) 19.19.27 Quit miepchen^schlaf () 19.20.14 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 19.25.12 Join Horscht [0] (n=Horscht@xbmc/user/horscht) 19.26.48 Join LambdaCalculus37 [0] (i=44a04303@gateway/web/ajax/mibbit.com/x-f5f72433e7bcd424) 19.29.45 # kugel: No, I don't. 19.30.11 # linuxstb: it seems the afsel stuff isn't working properly, since I "control" the display with the buttons 19.31.05 Join BigBambi [0] (n=Alex@rockbox/staff/BigBambi) 19.31.35 Join Horschti [0] (n=Horscht@p4FD4BF7C.dip.t-dialin.net) 19.32.21 Quit Horscht (Nick collision from services.) 19.34.16 Join miepchen^schlaf [0] (n=miepchen@p579ECAE6.dip.t-dialin.net) 19.36.00 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) 19.37.53 # but why is it working in the bootloader, and not in the main :S 19.50.11 # kugel, are you able yet to browse the menus on your fuze? 19.50.13 Join XavierGr [0] (n=xavier@rockbox/staff/XavierGr) 19.50.48 Join aarcane [0] (n=aarcane@c-67-187-242-146.hsd1.ca.comcast.net) 19.50.52 # bertrik: no, if I enable buttons for main, the display goes crazy 19.51.08 # how reliable is the new sd dma code for as3525? I see write support was enabled, so I'm a little scared of the risk of bricking my clip 19.51.16 # and I rather control the display (i.e. up button inverts the display colors) 19.51.34 *** Saving seen data "./dancer.seen" 19.51.49 # bertrik: working so far. I obviously haven't done significant write operations yet 19.52.28 # bertrik: seems its pretty reliable.. havent seen it doing something wrong yet, but of course its not much tested... 19.53.47 # I guess we need proper interrupt handling for e200v2 and fuze buttons 19.53.55 # and bricking risk should be minimal, sd-code doesnt allow access to the firmware space. so it can only mess up the fat partition, which should be fixable.. 19.55.18 # on the fuze the firmware even booted with a partition table destroyed by gparted 19.55.41 # domonoky, ok 19.56.02 # kugel, why would we need interrupt handling? 19.56.30 # because lcd and buttons are sharing some gpio pins. 19.57.15 # the buttons aren't gonna work if the lcd is constantly changing the gpios used for the buttons 19.58.15 Quit japc (Read error: 145 (Connection timed out)) 19.58.59 Join funman [0] (n=fun@AToulouse-158-1-52-196.w90-50.abo.wanadoo.fr) 20.00.07 # * gevaerts wonders if his d2 problems are due to NAND issues or to something else entirely 20.00.49 # kugel, ok I understand but I don't understand what interrupts have to do with this 20.01.57 # the button driver shouldn't be interrupted between setting up the gpio for reading, reading itself and resetting the gpios again 20.02.17 # perhaps interrupts on gpio pins changing can't happen when the physical pins are mapped to DBOP 20.02.24 # simply disable_irq doesn't work though 20.02.58 # kugel: the button driver can only be interrupted with interrups, (cooperative multitasking) so you could just disable the ints, while reading the buttons.. 20.03.22 # domonoky: as i just said, I tried that. Result is that rockbox doesn't load 20.03.38 # domonoky: yet the kernel tick interrupts does "things", I don't know if these "things" include lcd access 20.03.39 # as of now, I somehow control the display with the buttons instead of browsing or something 20.03.56 # kugel: you disabled at the start of button_read, and enabled at the end again ? 20.04.33 # this, and only dis/enabling when setting the afsel 20.04.38 # both didn't work 20.05.07 # shortly disabling the interrupts should not prevent booting, so i think you did something wrong... 20.05.18 # shouldn't the dependencies file make.dep depend on the SOURCES files ? 20.05.59 # domonoky: what can i do wrong when just typing disable_irq(); at the beginning and enable_irq(); and the end of the function? 20.06.26 # I also tried some_int = disable_irq_save(); and restoring later. no success 20.06.47 # kugel: i dont reall know. Wild guess: the interrupt enable was never called.. 20.07.43 # well, pressing the buttons works in the bootloader. after *only* adding *_irq rockbox didn't boot 20.07.57 # where did it stop ? 20.08.05 # at the bootlogo 20.10.00 # kugel: maybe pastebin your modifications, so we can see if you missed something :-) 20.10.39 # and if you get complete hangups, panicf() is very helpfull to findout where it hangs.. :-) 20.11.25 # well, I'm almost entirely sure the hang happens at either enable_ or disable_irq 20.11.36 Join jhulst_ [0] (n=jhulst@unaffiliated/jhulst) 20.12.03 # do you have the button led on the fuze ? you could use it for debugging purposes 20.12.21 # yep 20.17.22 Join shotofadds [0] (n=rob@rockbox/developer/shotofadds) 20.17.58 # hi gevaerts. what d2 problems are you having? freezing during ape playback, by any chance? 20.18.39 # shotofadds: freezing in test_codec for ape to be precise 20.18.53 # yes, same here. I get the same freeze in the WPS too, though 20.19.00 # FLAC and MP3 seem fine 20.19.27 # I've never tested APE before, so don't know if this is a new problem 20.20.15 # The weird thing is that the freeze seems to be always at the same point in the file, until I overwrite it (with the same original). Then it moves to a new freeze spot 20.20.16 # ape is just too cpu intensive. It overheats the cpu 20.20.19 # just a guess ;) 20.20.35 # That's why I still somewhat suspect nand 20.20.58 # * gevaerts will try the md5sum plugin next 20.21.06 # gevaerts: That sounds weird. You obviously did a successful ape test before... 20.21.13 Quit MethoS- (Remote closed the connection) 20.21.32 # sounds like it's filesystem realted. does the md5sum plugin display the sum on screen or just write to a file? 20.21.48 # * amiconn wonders about the status of the other telechips ports 20.21.49 # I didn't claim the new NAND driver was perfect ;) 20.22.06 # funman: it just read " at 00000000" on the display 20.22.27 # kugel: weird 20.22.30 # ah, now the full version: undefined instruction at 00000000" 20.23.07 # shotofadds: it looks like it writes to a file, but there does seem to be md5sum checking functionality as well 20.23.20 # indeed weird 20.23.35 # sounds like someone should put it to use ;) 20.24.18 Quit jhulst (Read error: 110 (Connection timed out)) 20.24.21 Join Zagor [242] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) 20.24.54 # checking still writes.. 20.25.00 # it's so randomly what the display shows after boot without disabling irq 20.25.19 # kugel: forget about it and do something else ;) 20.25.32 # funman: what should I do? Buttons are essential 20.25.39 # just like sound 20.25.51 # you're not going to play any file without buttons 20.26.01 # even if you had sound 20.26.09 # you're not going to debug that if it drives you crazy either ;) 20.27.20 # it doesn't drive me crazy 20.27.53 # well, if anything, than these epilepsy inducting flickering 20.32.33 # funman: for a split second I see a "divide by zero" error 20.33.50 # note the address, and use gdb on the bootloader.elf 20.34.01 # or objdump rather 20.34.39 # funman: it's in the firmware 20.34.51 # use it on rockbox.elf then 20.35.02 # not in the bootloader. Also, I can't note the address if I only see it for a split second 20.35.19 # weird since the player should freeze on this message 20.35.59 # I get that undefined instruction at 00000000 like instantly after 20.37.41 Join perrikwp [0] (i=18ac0c41@gateway/web/ajax/mibbit.com/x-71ddee384e5ed3c7) 20.38.19 # * gevaerts wonders how long this md5sum should take 20.38.38 Quit Schmogel (Read error: 110 (Connection timed out)) 20.41.02 # funman: There's no proper keymap defined for the Clip virtual keyboard, is there? 20.41.34 # LambdaCalculus37: if proper means something else than 'compilable'; then yes. bertrik did some work to refine it 20.41.51 # .. then yes, there is no proper keymap 20.41.59 # I get no message at all when switching the buttonlight on before irq_disable 20.42.22 # That explains why I can't move up and down in the character selection, then. :) 20.42.52 # I also have trouble jumping in the time/date settings: I always jump 2 settings 20.43.54 Join bluebrother [0] (n=dom@rockbox/staff/bluebrother) 20.44.21 # Also the Vol Up/Down buttons don't seem to do anything; I figure they're not defined, correct? 20.45.05 # they work in the WPS at least 20.45.11 # funman: did you do already some attempts at sound on ams-sansas ? i am still struggeling to understand how the dma should work in this case... 20.45.14 # and in the Solitaire plugin :-) 20.45.27 # domonoky: yes i'm trying to do that, but I have the same problem than you.. 20.45.44 # * gevaerts can't get md5sum to work 20.45.50 # I understand that it's the i2sout peripheral role to request a DMA transfer 20.46.19 # shotofadds: these are 20MB files, so I guess that if there are issues, the chance to get one is pretty big 20.46.22 # md5sum freezes on the Clip when I run it. 20.46.23 # and the fact that "DMAC is the data flow controller" means that we set a size of data to be transferred, and stop after that. 20.46.45 # ah, the DMAC is the flowcontroller in this case ? 20.46.54 # funman, jumping two places in the date/time settings should be fixed 20.47.07 # yes, because the i2sout peri can't tell "ok we don't want data anymore" 20.47.13 # amiconn: http://pastebin.ca/1266872 20.47.48 # (not the standard test_codec format, as there is no write support yet) 20.47.49 # bertrik: ah right, thank you ! 20.47.51 # I'm only familiar with a few buttons actually, no idea how the virtual keyboard works for example 20.48.47 # funman: so the lenght in the DMAC should be one fifo full of the i2s interface ? 20.49.53 # domonoky: no, the size/width should match the size of the FIFO (or half of it like in SD) 20.50.12 # ah. so one burst per fifo (or half of it)... 20.50.17 # and the transfer size should be the number of times we can transfer a (half of) FIFO size to the i2sout 20.50.25 Join Lear [0] (i=chatzill@rockbox/developer/lear) 20.50.31 # so it should reflect the available data in pcm buffer 20.51.35 # so its the requested size in pcm_play_dma_start divided to burst size, correct ? 20.51.43 Join AndyIL [0] (i=AndyI@212.14.205.32) 20.51.54 # I thinkyes 20.52.06 # do you want my draft code? 20.52.18 # would be nice, to make some tries... :-) 20.53.11 # * bertrik 's RTC on his clip still runs without getting reset 20.53.40 # interesting. With disable_irq only it boots 20.54.20 # kugel: perhaps the function is entered with irq disabled 20.54.29 # domonoky: http://paste.ubuntu.com/76895/ 20.54.47 # kugel: maybe at this time, interrrupts are already disabled, then you would enable them at a bad time... :-) 20.54.48 # gevaerts: and they're probably recently-written files too, which will make a difference. However, the size issue should also apply to FLAC... 20.55.34 Join dabujo [0] (i=xx@p4FDB24C2.dip0.t-ipconnect.de) 20.57.09 # gevaerts: Thanks. Very interesting results.... 20.57.15 # shotofadds: I got it to work after a few more tries (copying again and again...) 20.57.34 # amiconn: have fun with then :) 20.57.42 # The (higher level) filters are significantly faster than on ARMv4. They're almost on par with codfire, which is expected 20.58.00 # gevaerts: bah. back to the drawing board on the flash driver, then :/ 20.58.17 # But for some reason -c1000 is (a bit) less efficient than on gigabeat F (ARM9, v4) 20.58.35 # shotofadds: you're on the right track though. It always boots :) 20.58.43 # domonoky, funman: unless some other *_init() function doesn't propery enable irq, that shouldn't be the case. button_init() does not disable irq 20.58.50 # properly* 20.59.08 # You didn't do the entroypy-only and entropy+prediction tests, I presume? 20.59.39 # gevaerts: unfortunately I don't really have any more ideas at this point. back to the disassembly methinks... 20.59.46 # amiconn: No. I can still do them though 21.00.16 # * Zagor can't decide if today is just the right time for a flyspray upgrade, or a very bad time. 21.00.19 # Does the D2 have IRAM? If so, how much, and do we use it? 21.00.57 # Zagor: the right time is just before you leave for a week :) 21.01.29 # amiconn: there's 96k IRAM but we don't currently use it as performance was significantly worse (ie. about 30% slower) when using IRAM. Needs more investigation... 21.01.38 # no, the right time would be if he leaves for a week AND the tracker cleanup week begins 21.01.47 # Oh? That sounds odd... 21.02.15 # It'd be nice to figure out what the problem was.. 21.02.38 # what's the reason we don't use IRAM on the Gigabeat F? does it have any? 21.02.59 Join frinkazoid [0] (n=waldo@ip-81-11-222-4.dsl.scarlet.be) 21.03.05 Quit AndyI (Read error: 110 (Connection timed out)) 21.04.44 # It's a bad time because with the tracker cleanup just announced, people are working in the tracker. And the upgrade is a big one, where I'll have to rewrite many of the rockbox customizations we have. 21.05.05 # we have a tracker cleanup? 21.05.16 # Zagor: what is the benefit of the upgrade? 21.05.39 # shotofadds: markun would know. 21.06.19 # gcc is weird... 21.06.25 # * bluebrother guesses for less bugs 21.06.29 # It's a good time because otherwise I'll have to wait a long time with it, possibly after the release, for activity to cool down. And the new version brings some nice new features such as custom task fields (svn revision for example). 21.06.44 Nick jhulst_ is now known as jhulst (n=jhulst@unaffiliated/jhulst) 21.07.51 # Zagor: how much work is the upgrade? 21.08.19 # bluebrother: I honestly don't know... 21.08.30 # I'd say go for it, but I'm one of those people that upgrade because something is newer and not necessarily better :) 21.08.36 # LambdaCalculus37, the Clip probably looks very much like other plays w.r.t. buttons, so probably we could re-use parts of other keymaps (keeping an eye on what makes sense of course) 21.08.50 # the flyspray team is about as keen on writing development docs as we are :-) 21.09.08 # interesting. The crazyness of the display reduces when I insert udelays between GPIO*AFSEL and *DIR stuff 21.09.10 # hehe ;-) 21.09.36 # can't you just do the upgrade "offline" on a copy and then move the new FS to the current location? 21.09.44 # or does it require database changes? 21.09.45 # Zagor: you mean they have a nice manual that nobody reads? ;) 21.10.30 # amiconn: http://pastebin.ca/1266896 21.10.31 # bluebrother: yes, it requires database changes. I intend to try an upgrade on a copy of the database first though. 21.11.01 # but running everything offline/duplicated takes extra work 21.11.27 # bertrik: If I can get my Mac back to working order again, I'll take a look at the keymap. 21.11.33 # true, especially in that case :/ 21.12.04 # bertrik: LambdaCalculus37 I'm looking at keymaps in plugins and I'm using the C200 case 21.13.19 # funman: That makes sense on the Clip. 21.13.46 # * bertrik agrees 21.14.30 # funman: pcm_play_dma_start get never called for me on m200v2.. 21.14.41 # I wouldn't mind a someone playing the role of "keymap police" or something like that, to keep keymaps sensible and compatible between players where possible 21.16.26 # How many people apart from me would like to have Mr Someone write a disk formatter plugin? 21.16.37 # domonoky: oops, I should have checked that .. 21.16.52 Quit herrwaldo (Read error: 110 (Connection timed out)) 21.17.00 # bertrik: someone or Someone ? 21.17.09 # gevaerts: There's some code in ipodpatcher for formatting (512-byte sectors only)... But yes, it's been mentioned before as a useful idea. 21.17.27 # I mainly want it for formatting ramdisks 21.17.40 # gevaerts: how many "are you sure" would be in there? :) 21.18.40 # Zagor: I'm not sure :) 21.19.42 # gevaerts: if you do that don't forget to set a common define for targets which have the OF in the first sectors (especially the ones which can't be unbricked like most sansa ams) 21.19.47 # gevaerts: A formatting plugin would be useful for a few users, e.g. when dealing with an lba48 enabled rockbox on old archos. It should also be able to handle partitioning 21.20.33 # I wonder how rockbox would behave if it's partition was suddenly deleted 21.21.05 # funman: Would it panic? :) 21.21.08 # funman: it wouldn't know. iirc the partition is only looked at when mounting the disk. 21.21.28 # aren't some files loaded from /.rockbox after the firmware itself? 21.21.32 # funman: if you keep hiding those first sectors in the driver, that's not a problem 21.21.37 # funman, someone. Pixelma has been working on the c200 keymap. Maybe the clip keymap should be more like that patch than the current c200 keymap. 21.22.00 # funman: sure but deleting the partition information doesn't remove the data from the disk. so reading files is still possible. 21.22.11 # bertrik: if the plugin doesn't use BUTTON_REC, I simply add elif(SANSA_CLIP_PAD) 21.22.36 # Zagor: ok, I was thinking of bzero(), not only deleting the partition table 21.22.38 # amiconn: right. Those can indeed use it as well 21.22.46 # funman: If you're going to follow the c200 keymap on the Clip, then the keymap for the WPS has to be fixed a bit. 21.22.48 # * gevaerts adds fdisk to the list 21.22.53 # funman: ah. yeah that will annoy the fat driver pretty quick. 21.22.58 Join raky [0] (i=r4kz@odnb-4db7723e.pool.einsundeins.de) 21.23.27 # LambdaCalculus37: how can I fix it if I never used the WPS? :) 21.23.30 # is there any kind of keymap guideline? 21.24.07 Quit raky (Client Quit) 21.24.29 # My next issue is of course that I need FAT16 (for 4MB or 8MB ramdisks. FAT16 is already a stretch), and ipodpatcher doesn't do that 21.25.00 # gevaerts: That's in fact a quite old idea. Have a plugin that (1) checks the partition table, to make sure the active fat32 partitions ends before the lba28 barrier, (2) creates a second, hidden fat32 partition after the first one and (3) formats it 21.25.34 # amiconn: presumably the use of -mlong-calls in ARM builds is to cater for calling functions in IRAM? though it seems to always generate long calls, regardless of the target section.. 21.26.48 Quit shotofadds (Read error: 54 (Connection reset by peer)) 21.26.51 Join raky [0] (i=r4kz@odnb-4db7723e.pool.einsundeins.de) 21.26.55 Join shotofadds [0] (n=rob@rockbox/developer/shotofadds) 21.27.27 Quit raky (Client Quit) 21.27.54 # Another item on this wish list would be a faster file copy in rockbox, maybe as a plugin, that uses the audio buffer for buffering data 21.29.12 # amiconn, last time I looked at the file copy, there was already an option to use a big buffer IIRC 21.29.26 # also I wondered if the progress bar might be slowing down the copy 21.30.18 # * bertrik tries to remember the source file 21.31.01 # shotofadds: Yes and yes 21.31.47 # so it might be worth diabling that while not using IRAM..? 21.31.50 # gcc is pretty limited when it comes to handling arm long calls. -mlong-calls will cause all calls to non-static functions to be long calls, and calls to static functions to be short calls 21.32.18 # amiconn: thanks for the summary! the first one is implemented, the second one doesn't look hard, the third sounds positively nasty :/ 21.32.41 # This is the reason for the STATICIRAM macro. It's a workaround for a gcc bug 21.33.09 # It causes all ICODE_ATTR functions to lose their 'static' attribute on arm 21.33.23 # (if ICODE_ATTR is non-empty, of course) 21.33.44 # ah, that explains it. I'm just wondering if that is causing a performance penalty when not using IRAM 21.34.04 # Unhelpful: The 3rd isn't much different from the 2nd. Just somewhat different bit shuffling, and a twice as big pixel block 21.34.15 # although performance should really be the least of my worries.. 21.34.31 # the clipboard_pastefile in onplay.c tries to use the plugin buffer, if not available it uses a 512 byte buffer on the stack 21.34.54 # the first is at least easily optimized for line-at-a-time writing. the others pretty much can't be, and i'll end up having to write each byte four times :/ 21.35.10 # If you're not using IRAM, or otherwise all code sections can be reached from each other using short calls (that's what tomal did on the iFP - mapping DRAM and IRAM close enough), -mlong-calls isn't needed 21.35.29 Join puzzles [0] (n=dan@xmms2/developer/puzzles) 21.35.48 # Unhelpful: That's unavoidable. The current BMP loader also has to do that 21.36.17 # amiconn: i could buffer 4 or 8 lines of pixels values, but that's almost certainly worse :/ 21.36.46 # the horizontal-packed case will get just as bad if we ever need to load a column-first format 21.37.53 # Of course. 21.39.31 # * amiconn knows those pixel formats pretty well, as he wrote large parts of the optimised lcd drawing functions for the various pixel formats, and developed the greylib, which has to handle those pixel formats too 21.41.00 # i'll pester you if i have more trouble - as it turned out, none of the troubles with the H-packed case had anything to do with my understanding of the format, though. all stupid-programmer bugs. 21.41.10 # I wonder why so many arm targets specify -mlong-calls. On PP it is necessary, but afaik we don't use IRAM on gigabeat F, so why -mlong-calls? 21.41.50 # amiconn: Speaking of the iFP... what is the ultimate fate of the port? We haven't seen any activity on it for a long time, and while sound does work, IIRC it was WAV only. 21.42.03 # nope 21.42.21 # It played vorbis and mp3 as well, afaik 21.42.25 # LambdaCalculus37: it's just another one of the stalled ports.. 21.42.50 # amiconn: Hmmm... 21.43.04 # Bagder: Wonder if Mr. Someone would ever pick it back up. ;) 21.43.24 # for such an outdated and tiny storage device, I find that very unlikely 21.44.00 # tomal did some good optimizations though that we all benefit from 21.45.23 # eh, I think rockbox is looping 21.45.46 # what could cause rockbox to reboot? 21.45.50 # sheesh.. removing -mlong-calls from the D2 build saves 27KB (~5%), I wonder if it has a similar effect on performance... 21.46.28 # Does that include codecs? 21.47.27 # well, that figure was binsize, but I assume codecs are also built with that flag too 21.48.04 # Yes, they have to (on targets where we use IRAM) 21.48.15 Quit jhulst (Read error: 60 (Operation timed out)) 21.48.26 # * gevaerts could test ape right away 21.48.44 # Usually the gain from using IRAM is greater than the loss due to long calls 21.49.10 # gevaerts: I would be surprised if you get a measurable difference 21.49.37 # Most performance critical code in libdemac uses static inline functions 21.50.28 # shotofadds: Btw, this is one more reason to make all private functions static - it saves them from being long-called on arm 21.51.07 # amiconn: iafaik we don't use iram on the beast either, i think it has only 16kB though 21.51.27 Join notplus_M [0] (i=plus@li26-205.members.linode.com) 21.51.39 *** Saving seen data "./dancer.seen" 21.52.26 # does somebody have an idea why pcmbuf_play_start could be called with pcmbuf_unplayed_bytes==0 and pcmbuf_read == 0 ?? 21.53.20 # decoder doesn't work correctly ? 21.54.16 Join japc [0] (n=japc@bl6-69-208.dsl.telepac.pt) 21.54.38 # it looks more like problems with memory (the left-over buffer is very small).. maybe not all needed things fit, and error handling is non-existant (like always with mem-alloc :-) ) 21.55.42 # linuxstb: ping 21.55.44 # amiconn: the difference _is_ measurable. I got 390.19% for -c1000 (was 384.81% for a -mlong-calls build) 21.55.59 # wow 21.56.01 Quit nuonguy ("This computer has gone to sleep") 21.56.50 # Interesting.... 21.57.10 # Perhaps the code size reduction improves caching 21.57.18 # gevaerts: I also see about a 1% difference in MP3 21.57.44 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 21.58.52 # * gevaerts continues testing 22.00.15 # btw. I deliberately haven't added any d2 codec performance figures to the wiki yet, since I can't be sure the dodgy flash driver isn't skewing the results :/ 22.00.52 # Interestingly, c3000 is slower without -mlong-calls 22.03.10 # Does storage performance actually influence test_codec? I'd assume that if it gets loaded correctly, the numbers will be ok 22.04.34 # first one that compiles works. i'm not interested in installing a coldfire toolchain just to get binsizes, though. i'll have the patch up in a minute, if somebody w/ an iriver h1x0 or iaudio m5 wants to try it. 22.05.32 # gevaerts: I meant bad data being read, rather than performance 22.06.00 # shotofadds: for ape it seems to freeze in those cases anyway :) 22.06.45 # it's weird, I haven't managed to complete a single APE test run yet. but every other file I try seems file. very strange 22.06.52 Quit martian67 (Remote closed the connection) 22.06.57 # But yes, those numbers need to be treated as possibly suspicious 22.07.24 # amiconn: pong 22.07.39 # I think if you can play the file without glitches the numbers should be fine. But I wasn't about to play the whole test set through ;-) 22.07.59 # I haven't actually listened to this test track at all yet :) 22.08.12 Join martian67 [0] (i=lol3izer@about/linux/regular/martian67) 22.08.36 # gevaerts: do you have any idea where to start looking at USB on 78x? is that something you intend to look at one day or should I get reading? 22.09.31 # funman, I see that one the clip there currently is an option to put the display upside down, but it only puts the buttons upside down. 22.09.33 # shotofadds: I have no real idea right now. I know I've had issues with endpoint allocation 22.09.52 # also I think the OLED brightness/contrast can be changed in the OF, but not in rockbox yet 22.10.00 # But I don't remember if that was on the D2 with UMS or only on the DAX with serial 22.10.15 # I know it's not really important yet, but how about I have a look at that? 22.10.53 # Also, while USB would no doubt be interesting for development, without write support there isn't that much you can actally do with it 22.10.56 Join funman_ [0] (n=fun@AToulouse-158-1-120-116.w90-55.abo.wanadoo.fr) 22.11.15 Quit funman (Nick collision from services.) 22.11.20 Nick funman_ is now known as funman (n=fun@AToulouse-158-1-120-116.w90-55.abo.wanadoo.fr) 22.12.24 # bertrik: true lcd_set_flip() is still marked as TODO 22.12.38 # contrast can be changed, not brightness 22.12.49 # rockbox lowers the contrast when shutting down, but i couldn't find a setting for it 22.12.58 # I don't actually know very much about this controller either to make it even more fun 22.13.10 # gevaerts: debugging read support is my first concern. Being able to dump data from the d2 would make things a tad easier 22.13.27 # I know 22.14.05 # I had hoped the data from the m200 would help, but it turns out the FTL scheme is slightly different between the two 22.14.09 # I need to find some time for it and work out what goes wrong. Does it actually compile with usb enabled in svn? 22.14.12 # funman: you probably need to #define HAVE_LCD_CONTRAST in config-clip.h 22.14.41 # kugel: correction, bertrik probably needs to do so ;) 22.14.49 # gevaerts: you need to include usb-tcc77x.c in SOURCES, but apart from that it does compile, yes 22.14.59 # kugel: thanks for the hint 22.15.06 # ok. I'll try to have a look at it soon 22.15.25 # In XP I can get it to recognise a generic UMS device, and then freeze. In linux it just freezes.. 22.15.40 # * gevaerts also wants to get it to work on the meizus. Would be fun, usb before lcd... 22.15.52 # Does dmesg say anything? 22.16.16 # nothing - the last messages were from inserting in usb-boot mode 22.16.36 Join m0f0x [0] (n=m0f0x@189-47-44-35.dsl.telesp.net.br) 22.17.28 # What did you use instead of charger_inserted()? Just always USB_INSERTED? 22.18.14 # I used charger_inserted() ;) 22.19.00 # OK. That makes it easy :) 22.21.03 # how many steps would be sensible for contrast? the controller appears to offer 256 steps, which seems a bit much IMO? how about 16 steps? 22.21.28 # gevaerts: the logic isn't quite correct, since that will also be true when the AC adapter is plugged in (regardless of USB). but for testing it should be fine 22.22.19 Join EspeonEefi [0] (i=eefi@STRATTON-TWO-EIGHTY.MIT.EDU) 22.22.23 # * shotofadds gets back into some more disassembly 22.22.47 # * bertrik experiments 22.23.40 # bertrik: the c200's controller is also _supposed_ to do 256 steps too and Rockbox supports that (altough in real, I only have 128 steps which and it repeats itself...) 22.24.10 # broken sentence 22.24.16 # the clip doesn't have a wheel, so scrolling through 256 steps might take a while 22.24.35 # the c200 has no wheel either 22.25.57 # c200 and clip seems to have the exact same buttons. Safe for REC, and HOME (Clip only ?) 22.26.49 # c200 has a Rec button - and Power button (instead of the Home one?) 22.26.50 # ehh 22.27.06 # it just gets weirder 22.27.26 # pixelma: the keys are not at the same places though 22.27.43 # amiconn, shotofadds: the ape numbers without -mlong-calls are at http://pastebin.ca/1266967 22.27.55 # funman: I imagine 22.27.57 # power (clip) is on the side like rec (c200), and home (clip) is on the front like power (c200) 22.28.04 Quit {phoenix} (Remote closed the connection) 22.28.21 # I made most plugins build, now I have to look at plugins which depend on screen dimensions 22.28.26 Quit LambdaCalculus37 ("http://www.mibbit.com ajax IRC Client") 22.28.27 # funman: I inserted a splash now in the root menu which splashes when power is pressed. And I only read power in a seperate function. That splash comes without pressing something and doesn't go away 22.28.33 # full brightness on clip doesn't look very healthy 22.28.33 # is the M3 the *only* thing that uses the vertical-interleaved format? 22.29.03 # funman: ah, so it has a Power and a Home button and also Volume Up/Down? 22.29.03 # kugel: then perhaps your reading of power button is wrong 22.29.43 # it's mostly copied from svn, which works for the bootloader 22.29.44 # pixelma: yep, look at sdl/UI-clip.bmp : volume +/- is on the right side and power/hold on the left side (invisible on the bmp) 22.30.18 # upside down works now, but looks a bit weird because of the yellow top part of the screen which becomes the bottom part of the screen in upside down mode 22.30.33 # unless that changed recently, I couldn't recognise any side buttons in the sim bmp 22.30.35 # that screen will look bad everywhere .. :/ 22.31.05 # funman: where's "Rec" then? 22.31.07 # pixelma: the side buttons aren't on the BMP, perhaps we should mark all the buttons with overlaid text on the picture 22.31.10 # pixelma: there's no rec 22.31.18 # do we really want upside down mode for the clip? 22.31.27 # bertrik: why not ? 22.31.49 # funman: aha, misunderstood earlier 22.34.04 # funman, because it looks weird and I don't see much use for it (personally) 22.34.32 # do you use lcd flip on other targets? 22.34.50 # funman: I think the point is more that we can't do anything about the yellow patch being at the bottom of the screen, and offset by two pixels. 22.34.51 # no 22.35.05 # It does have a blank line separating, right? 22.35.07 # Llorean: i understand, but that's a problem in a lot of other areas 22.35.13 # 2 black lines 22.35.33 # But it's more of a problem if it's "part of the list" rather than "the status bar or title" 22.36.16 # I'd almost say it needs an option to display the status bar in the yellow area even when flipped to really not be too weird. 22.36.18 # i meant it's a problem in most plugins (except solitaire), wasn't thinking of the screens with status bar specifically 22.38.56 # make: *** No rule to make target `/home/fun/clip-fw/pluginbitmaps/bubbles_bubble.h', needed by `/home/fun/clip-fw/apps/plugins/bubbles.o'. 22.40.44 Quit bmbl ("Woah!") 22.41.16 # if you take the Archos graphics for the Clip as a start - remember that some of them will look stretched (where it was possible, to compensate for the rectangular pixels on the Archos display 22.41.25 # ) 22.41.55 # if plugins can be built and fixed later that's not a problem 22.43.06 # oh I found the SOURCES file 22.43.12 # funman: bingo :) 22.43.16 Quit neddy (Connection timed out) 22.44.06 # I'm a bit confusedthat some bitmaps use the target screen size in the name, and some other the bitmap size 22.45.27 # yes, they are named inconsistently... 22.45.56 # which inconsistency should I be consistent with ? ;) 22.46.24 # shotofadds: if I build a logf build and watch the logf output live, it gets a lot further 22.47.27 # I guess it gets as far as you got it in windows then 22.47.31 Quit massiveH ("Leaving") 22.49.21 Quit perrikwp ("http://www.mibbit.com ajax IRC Client") 22.57.28 Join Acikers [0] (n=acikers@82.114.226.16) 22.57.43 Quit shotofadds ("Leaving") 22.57.43 # hi, i'm need to help 22.58.23 # hello Acikers, what happens? 22.58.29 # Acikers: it's a lot easier to help you if we know what the problem is 22.58.35 Quit Lear ("ChatZilla 0.9.84 [Firefox 3.1b2pre/20081125035317]") 23.00.16 # what needed for playing avi in rockbox 23.00.52 # Sorry my bad English... 23.01.09 # Acikers: Rockbox doesn't play any avi formats - you need to convert videos to the format Rockbox supports - http://www.rockbox.org/wiki/PluginMpegplayer 23.01.27 # I'll know that... 23.02.43 # Thanks 23.03.52 # And, how i can open files *.rock? Or where i can find source? 23.04.31 # Acikers: i think you can find all that infromation on rockbox site 23.04.36 # on the FAQ 23.05.05 # Acikers: or the manual 23.05.12 Join neddy [0] (n=john@nat/sun/x-896b804bd2843ed6) 23.05.34 # Acikers: the source is in our SVN repository see this page http://www.rockbox.org/twiki/bin/view/Main/WebHome?topic=UsingSVN 23.05.59 # if i'm reading this right, there's at least one player that uses one grayscale format on the display, and a different one on the remote? 23.06.06 # what's the difference between bitmaps/mono and bitmaps/native for a mono target? 23.06.17 # .rock files are rockbox plugins which are compiled from c code, we have documentation in the wiki for setting up compilers etc 23.06.52 # Unhelpful: that would be the iaudio m5 i think, same remote as m3 and x5 23.06.59 # Unhelpful: yes, the h100 has 2bit greys on the main and 1bit on the remote 23.07.36 # thanks 23.07.51 # bye 23.07.55 Part Acikers 23.09.06 # i'm starting to think that the inside of the nearest-neigbhor scaler should have a case statement for the different formats, and build whichever cases apply for a particular target or its remote 23.09.22 # it seems the only way not to copy-paste the entire outer loop 23.10.53 # aside from that, there are already several tests inside the inner loop for things like dithering, done on a per-pixel basis - so case'ing the formats that might be encountered wouldn't make things much worse, i'd think. 23.10.53 Quit pondlife ("Leaving.") 23.11.14 Quit martian67 ("gone") 23.13.47 # Unhelpful: the M5 which itself is greyscale can use the Iadio remote which is the M3 display 23.13.48 Quit jhulst (Read error: 110 (Connection timed out)) 23.14.00 # the remote is greyscale too 23.14.15 Quit domonoky (Read error: 104 (Connection reset by peer)) 23.14.40 # what n1s said... /me too slow 23.16.12 Join fml [0] (n=4fd3c72c@gateway/web/cgi-irc/labb.contactor.se/x-e8c1136ca5cc61d0) 23.16.36 # jhMikeS: ping 23.17.53 # pixelma: the M5 is v-packed, and the M3 remote is v-interleaved, i believe? 23.18.38 # jhMikeS: (for the log) I have an impression that after r19214 there are more noises at startup. But less on shutdown (Sansa e200 v1). 23.18.42 Quit dabujo ("( www.nnscript.com :: NoNameScript 4.2 :: www.regroup-esports.com )") 23.18.56 # Unhelpful: that's what amiconn said earlier 23.19.22 Join jhulst [0] (n=jhulst@unaffiliated/jhulst) 23.20.56 Quit nplus (Remote closed the connection) 23.21.03 # and some of the greyscale targets have mono remotes. i think there should be exactly one resize_nearest, to save duplicating the outer-loop code... probably the whole lot could go with the color scaler into a resize.c, instead of this resize-common, resize-gray, and resize-color 23.22.29 # I think I found the datasheet for the as3525 USB sub-system but it's behind some kind of registration form 23.22.58 # bertrik: free registration? 23.23.16 # have a look: http://www.synopsys.com/dw/docs/ds/c/dwc_usb_2_0_hs_otg_subsystem-ahb.html 23.25.07 Quit aarcane (Read error: 104 (Connection reset by peer)) 23.25.47 # bertrik: just put anything you want including wrong email, and you'll get the (2 pages) download 23.26.26 Quit fml ("CGI:IRC 0.5.9 (2006/06/06)") 23.26.43 # oh the "full product doc" is protected by a real login 23.29.28 Join shotofadds [0] (n=rob@rockbox/developer/shotofadds) 23.36.25 Join MethoS- [0] (n=clemens@host-091-097-243-129.ewe-ip-backbone.de) 23.36.33 Join skipper [0] (n=skipper@78-0-207-85.adsl.net.t-com.hr) 23.41.50 Quit Rondom ("Ex-Chat") 23.42.49 Join aarcane [0] (n=aarcane@c-24-7-184-14.hsd1.ca.comcast.net) 23.51.41 *** Saving seen data "./dancer.seen" 23.52.27 # linuxstb: I have the strong feeling the lcd driver isn't as working as initially thought 23.53.08 # besides that it makes it hardly possible to use buttons, I also have problems with lcd_update(), which just crashes