--- Log for 05.04.110 Server: zelazny.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 7 days and 5 hours ago 00.02.34 # hm, one possibility is that things go wrong if you change a font used by scrolling text 00.07.42 Quit Bagder (Quit: It is time to say moo) 00.10.16 # http://pastie.org/903078 is my supposed to be final application for GSoC. I would welcome if some people would have a look, I plan to submit tomorrow 00.11.18 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 00.16.19 # gevaerts: that was what I had in mind earlier 00.16.45 # turn off scrolling then? 00.17.02 # kugel: looks good I think 00.17.17 # kugel: do you know if the sbs code always redraws text? 00.17.48 # I think it does but I don't know exactly 00.18.06 # If it does, just disabling scrolling won't help much 00.18.37 # I think the font code should use some locking 00.19.34 # kugel: For a *summer* of code, isn't your timezone GMT+2? 00.20.23 # should that info contain the summer time? 00.20.30 # kugel: there's grammatical errors in case you're worried about that 00.20.42 # sure 00.20.51 # I bet there's a lot of them :p 00.20.58 # jhMikeS: there *are*? ;) 00.21.03 Quit adnyxo (Read error: Operation timed out) 00.21.30 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 00.22.04 # pixelma: there are errors of the grammatical nature, indeed. :) what are you saying? " there *is* grammatical errors?" 00.22.29 # never mind, lol. 00.22.37 Quit jordan` (Read error: Connection reset by peer) 00.22.55 # there's coloquialisms and all sorts of junk 00.28.00 Quit stripwax (Quit: http://miranda-im.org) 00.28.25 Quit flydutch (Quit: /* empty */) 00.32.39 Quit togetic (Quit: WeeChat 0.3.0) 00.34.32 # speaking of which... AlexP: I just discovered an old patch again that changes sub-diretories to subdirectories in the manual. What do you think? 00.35.12 Quit ender` (Quit: All great truths begin as blasphemies. –– George Bernard Shaw) 00.35.39 # subdirectories looks funny to me 00.35.43 # linuxstb: ? 00.36.31 # Yes, sub-directories would probably be how I would write it. I wouldn't be surprised if both are "correct" though. 00.36.37 # hmm... makes me wonder if the vice versa case woulf be needed too. 00.36.47 # *would 00.38.43 # if I remember correctly, the patch was provided by bascule (more active in the forums back then) who was from Scotland I think 00.39.49 Quit moos (Ping timeout: 264 seconds) 00.42.34 Join phanboy_iv [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 00.45.55 Quit phanboy4 (Ping timeout: 252 seconds) 00.46.14 # pixelma: I wouldn't actively argue too hard either way, but I prefer with the - 00.46.37 Quit merbanan (Ping timeout: 245 seconds) 00.48.14 Join Blue_Dude [0] (~chatzilla@adsl-235-206-131.mco.bellsouth.net) 00.51.26 # Hey, quick question. A couple of days ago a dev made a change in the hotkey code I disagree with. Any problem with changing it back? There used to be a confirmation splash when setting a key but he took it out. I miss it. 00.51.51 # You should discuss it first 00.52.02 # Otherwise we get into a commit war 00.52.09 # fml did IIRC 00.52.21 # And the reasons should be in the IRC logs 00.52.39 # well, they should be in the commit message too... 00.52.55 # should be, don't know if they are 00.53.13 # Actually, it was part of another patch. The comment didn't address the change at all. 00.53.14 # AlexP: I haven't checked but I *guess* there are currently both ways of spelling 00.53.31 # I know he changed the lang files as they way it was constructed initially (add ? to the question) doesn't work for some languages 00.53.43 # Blue_Dude: r25457? 00.53.46 # That's the one. He also took out the splash screen. 00.54.04 # He did talk about it here first - I'd have a look at that, then mail the dev list 00.54.12 # Woops, brb... 00.54.13 # I have a feeling it was discussed here 00.54.34 Join jordan` [0] (~jordan@78.235.252.137) 00.55.20 # Blue_Dude: maybe ask him. The way he did it leaves line1 unused I think, so I suspect the removal of the splash was a mistake 00.55.35 # hm, or maybe not 00.55.57 # Blue_Dude: the yesno screen has a confirm message itself 00.56.23 Join mirak [0] (~mirak@85-170-147-126.rev.numericable.fr) 00.56.44 # if we add a confirmation splash after each yesno we can just as well remove the ability of the yesno screen to do it itself 00.56.51 Join saratoga [0] (~9803c20d@gateway/web/freenode/x-jxkcvhosvnuovdsj) 00.57.12 # Blue_Dude: http://forums.rockbox.org/index.php?topic=24377.msg164670;topicseen#msg164670 00.57.18 # maybe you can help out that guy 01.01.33 Join Darkknight512 [0] (~Darkknigh@CPE00212968356c-CM00186845dd46.cpe.net.cable.rogers.com) 01.02.11 Quit Darkknight512 (Client Quit) 01.02.30 *** Saving seen data "./dancer.seen" 01.08.51 # Heh, I just killed my iPod. 01.09.03 # I wanted to see what the shiny "Delete bootloader" option did in ipodpatcher. 01.09.10 # Apparently, it deletes the bootloader :) 01.09.14 # You can reinstall the bootloader, though 01.09.16 # Don't worry, I got it running again. 01.09.40 # Llorean: nope, ipodpatcher didn't recognize it as an iPod anymore and refused to install the bootloader :( 01.10.15 # Were you booted into disk mode? 01.10.19 # Yup. 01.11.04 # Which iPod. It should be able to detect it just fine if all you've done is remove the bootloader (which also shouldn't kill an iPod, just cause it to be OF only) 01.11.17 # iPod Nano 2G. 01.12.18 Quit JohannesSM64 (Ping timeout: 260 seconds) 01.12.55 # niekie: What's the problem exactly? You first said you killed your ipod, then you said it's running again.... 01.13.40 Join jeffp [0] (~jeffp@barmen.interhost.no) 01.14.08 # whoever runs the website: the sansa fuze (and others) manual has been offline for a few days 01.14.18 # not a big loss if he killed ipood 01.14.22 # get n900 01.14.39 Join Adubbb [0] (~aldubuc@67.201.160.144) 01.16.10 Quit GeekShadow (Quit: The cake is a lie !) 01.16.40 Quit Adubb (Read error: Connection reset by peer) 01.17.17 Quit mirak (Quit: Ex-Chat) 01.17.30 # linuxstb: yes, used iTunes on someone else's PC to restore it. 01.17.59 Quit anewuser () 01.19.53 Part jeffp 01.21.09 Quit Adubbb (Read error: Connection reset by peer) 01.21.36 Quit bertrik (Ping timeout: 265 seconds) 01.22.19 # Also, I tried to install a bootloader created from source.. so that might have helped in messing it up :) 01.22.31 # Anyway, it's all up and working again. 01.24.02 # Whew, sorry about that. I had reading duty. Bedtime for my 6 yr old. :) 01.25.31 # kugel: Yes, the yesno screen has a confirmation, but it goes fast and it's hard to see. Maybe I could get rid of the yesno message and go with a splash instead. It gets the point across more quickly. Besides, I stole the code from bookmark.c and *it* has both confirmation and splash. 01.25.57 # I'd welcome if that's fixed instead of double confirmation 01.26.04 Join Adubb [0] (~aldubuc@67.201.160.144) 01.27.06 # IMO it's not worse or better visible than the question. and the visibility probably depends on the theme 01.27.37 Join Strife89 [0] (~michael@adsl-154-2-63.mcn.bellsouth.net) 01.32.06 Join JohannesSM64 [0] (~johannes@cm-84.215.75.42.getinternet.no) 01.32.45 # Hm, well the yesno dialog is regular text on a normal background, placed in the upper left of the screen and it goes away quickly. By the time you register that there's information there, it's gone. Splash is reverse video in the center of screen and lasts two seconds, long enough to read it. 01.33.13 Quit Adubb (Ping timeout: 264 seconds) 01.37.15 Join Adubb [0] (~aldubuc@67.201.160.144) 01.42.07 Join Chronon [0] (~chronon@c-67-171-217-43.hsd1.or.comcast.net) 01.42.52 Quit Schmogel (Ping timeout: 265 seconds) 01.43.32 # shouldn't the yesno only go away on a button press? Not sure at the moment, just my first thought 01.44.25 # * pamaury proposes a yesno to confirm a yesno choice 01.44.57 # user choose to reboot when he/she is sure of his/her choice :) 01.45.38 # New commit by 03mc2739 (r25472): Fix Clip keymap (manual) so that Clipv2 and Clip+ manuals build properly 01.46.18 # Blue_Dude: we could increase the timeout of the confirmation 01.46.19 Quit geertvdijk (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 01.46.35 # I generally dont like splashes too much because they are so different to the rest of the ui 01.46.52 # I'm fooling with a patch right now. I'll see what the results are and brb. 01.48.27 Quit xiainx (Ping timeout: 276 seconds) 01.50.36 # Oh garn, it's going to be a few minutes... 01.50.55 Quit piotrekm (Quit: piotrekm) 01.53.08 # Blue_Dude: also you need to consider that splashes are only clearly visible on color targets, which is not always the case on greyscale/mono targets (where plain text draw is just as, or even better, visible) 01.53.43 # So you're saying... *both* would be preferable. :) 01.54.32 # no, I'm just trying to invalidate your argument that splashes are better visible :p 01.54.44 # Does the "yes no" disappear on its own, or only when a choice is made? 01.54.56 # I don't see why you need a splash *after* the confirmation request if it requires user input to confirm. 01.54.57 # It only goes away after a keypress. 01.55.03 # So why have a splash? 01.55.11 # If the user wants to read it before they confirm, they will. 01.55.24 # Well... I liked it. 01.55.25 # If they're going to ignore the yes/no, they'll ignore the splash too anyway. 01.55.28 Quit pamaury (Quit: Page closed) 01.55.36 # What purpose does it serve, though? 01.55.42 # I liked it. 01.55.51 # * Blue_Dude is starting to pout by now. 01.56.37 # I don't know exactly why it's there, except that the code I stole from also had it. 01.57.29 # And it seemed like a nice clean dialog. Pretty. 01.57.48 # Other than that, no reason I guess. 02.01.01 Join kramer3d [0] (~kramer@unaffiliated/kramer3d) 02.03.52 Quit kramer3d (Client Quit) 02.03.59 Join xiainx [0] (~xiainx@modemcable091.119-201-24.mc.videotron.ca) 02.07.52 Quit grndslm (Ping timeout: 252 seconds) 02.10.32 # So realistically, what are we up against? Is the splash a bad idea? Useless idea? 02.15.53 Part froggyman 02.17.31 # alright, final version of the application: http://pastie.org/903211 I'll submit that unless there are any comments (which are still welcome of course) 02.23.17 # does anyone know how much applications we've got already? 02.24.27 # 4 as of a couple hours ago 02.24.38 # last year though we got a lot on the last day or two 02.25.32 # oh 6 now 02.27.39 # saratoga: are you going to be the raaa mentor? I saw you on the list of possible mentors and nobody else 02.27.59 # kugel: i'll probably do one of the codec projects 02.28.12 # one of the people whos done more with the core would make sense for RAAA 02.29.16 # although I suppose if you're going to do it you can probably just talk to the rest of us directly and your mentor becomes more of a formality 02.33.42 Part r2k000 02.37.49 # I was just trying out something for a forum user. I tried deleting a file within Rockbox while it was playing. You would expect that the file would stop playing, the file would delete, the playlist would update (without the deleted file) and playback would resume with the next file. This isn't what happens. 02.38.39 # Instead, the file may or may not delete, it never stops playing (even if deleted!) and the playlist doesn't update. Seems very odd. 02.41.01 # we had this topic before 02.41.22 # while it's currently buggy, stopping the playback (or skipping to the next song) is not the prefered solution 02.42.03 # The current situation is better? 02.42.29 # In that case, why have delete in the WPS context menu at all? 02.42.36 # it's buggy as I said 02.42.47 # So what is the desired behavior? 02.43.05 # Blue_Dude: If the song is buffered, you can delete it while still finishing playback 02.43.09 # delete, and play out what's left in the buffer 02.43.26 # This means that if you want to, for example, remove a podcast after listening, once the last buffer occurs you can delete it, then continue listening to the next one with no further worries. 02.43.27 # Yeesh, that's a mess. Why do that? 02.43.36 # The bug comes in what happens if you delete it before all of it's in the buffer. 02.44.01 # not deleting only happens if the song is not fully buffered because the file handle isn't closed; I identified that problem once but fixing it introduced audio glitches for some reason 02.44.14 # OK, I can see that. But if it's not completely buffered, why not go with the ebehavior I described? 02.44.38 # ah 02.44.45 # Where were the glitched/ 02.44.50 # glitches? 02.45.02 # at the end of a file 02.45.07 # Blue_Dude: Well the behaviour definitely shouldn't change depending on when you delete it. 02.45.35 # I experienced it on my fuze where it's rather likely that not even a single song fits into the buffer 02.45.42 # So then, play out already buffered material, then track change? 02.45.52 # it looked like closing the handle and reopening on rebuffer inserts the glitch 02.45.53 # Ideally it should either delay the delete until the next time the file can "safely" be removed, or refuse to delete with a notification. 02.46.19 Quit cjcopi (Read error: Operation timed out) 02.46.27 # In my opinion, at least. 02.46.37 # Ow, that hurts my head. Why not just kill playback immediately, track change and rebuffer with the new track? 02.46.58 # I mean, delete means delete, right? 02.47.20 # There are already people who make use of the fact that "delete" doesn't also mean "unbuffer" 02.47.22 # BTW, splash! --> http://pastie.org/903229 02.47.22 # it probably shouldn't delete before the next rebuffer anyway, or do you want a disk spinup only for an immediate deletion? 02.47.26 # You'd be removing existing functionality. 02.47.57 # Llorean: I'd make the argument that it's not a function, just the exploitation of a bug. 02.48.36 # kugel: treat it internally as a track change, but with a file operation thrown in. 02.48.44 # I'm pretty sure it's been said to be intended behaviour, so calling it a "bug" is untrue. 02.48.46 # And a playlist update. 02.48.51 # there's no argument, playing out is the intentional behavior 02.49.06 # You can say it's intended behaviour that needs changed, but at the moment it's definitely a feature. 02.49.28 # Sorry, I just don't see the virtue of that. Trust the user to know what he's doing. 02.49.42 # (but I do think it should not delete until the end of the file has been buffered) 02.49.53 # Blue_Dude: Can't we trust the user to delete *and* skip if they don't want to allow it to finish? 02.49.55 # and not before the next disk spinup 02.50.24 # kugel: I more or less agree there. Delay the delete until it's "safe" if the file is in the current buffer and not wholly buffered. Or maybe even until it leaves the buffer / playback is stopped 02.50.31 # kugel: the disk will need to spinup anyway to start buffering the next track. What difference does it make? 02.50.34 # Blue_Dude: achiving what you want manually is trivial, while the opposite is impossible 02.50.39 # achieving* 02.50.53 # i think the best option would be to advance the track and then immediately delete the file 02.50.56 # Blue_Dude: huh? 02.51.13 # the next track might be buffered as well 02.51.14 # kugel: it's trivial with extra keypresses and unexpected behavior. 02.51.18 # or the next 5 tracks 02.51.22 # saratoga: Why can't the user choose whether or not to advance the track? 02.51.22 # Maybe... 02.51.41 # well first because I dislike having options that aren't overwhelming important 02.51.48 # As it stands, there's an existing feature that you're advocating removing without really gaining anything from removing it. 02.51.53 # but also because thats not going to work well on low mem targets 02.51.53 # saratoga: what option? 02.52.13 # saratoga: Several people (including non-devs) have explicitly stated they like the ability to mark a podcast for deletion before they're entirely finished listening to it. 02.52.13 # on something like the Clip the current track can basically never be buffered entirely 02.52.17 # Llorean: even so, the current behavior should update the playlist once the track is advanced. At present, you can back up to play the "deleted" track out of the buffer. 02.52.27 # Ideally it'd be an actual "mark for deletion" rather than our current method, but that's just an improvement. 02.52.28 # it's considered as a feature, if at all it lacks documentation 02.52.49 # and as long as skipping the track is easy to do manually I wouldn't want it to change 02.53.19 # If marked for deletion, when would the deletion take place? After stopping playback? 02.53.23 # Blue_Dude: It shouldn't necessarily update the playlist (there's no reason to ever write to a user's playlist unless they modify it themselves) but it should prevent seeking back into it if the file's gone, just like any other skip to an invalid playlist entry 02.53.31 # on something like the clipv1 i imagine its basically impossible to delete the currently playing track? 02.53.42 # Blue_Dude: probably at the next disk spinup, via ata_idle_notify 02.53.45 # and probably for flac files on lots of players 02.53.57 # Llorean: I meant dynamic playlists, but that's what I mean. 02.53.59 # I'd say deletion should occur either on stopping playback or on when none of the file remains in the buffer, whichever happens first. 02.53.59 # immediate deletion isn't very important is it? 02.54.12 # well its less complicated 02.54.18 # Blue_Dude: Dynamic playlists should behave as much like static playlists as possible though. 02.54.21 # do we have a system for queuing file operations? 02.54.36 # saratoga: I don't think so. 02.54.47 # saratoga: what do you want to queue? 02.54.54 # the track delete 02.55.02 # lets add another 10 special cases to buffering.c to handle this! 02.55.11 # God I need to look into the buffering code now. "Abandon all hope, ye who enter here." Drat. 02.55.28 # if you're really bored you could write that test driver i always wanted 02.55.37 # saratoga: why special case? a delete after buffering flag could be quite generic 02.55.42 # so we can test buffering with the build system 02.56.08 # everything in the buffering system ends up being really complicated, i'm skeptical this will be different 02.56.14 # but i am only guessing 02.56.29 # I'm expecting this to be a relatively simple change actually 02.56.32 # Buffering rewrite! 02.58.40 # OK, a "Mark For Deletion" context menu item, which flags the file for deletion upon stopping playback, or end of file, whichever happens first. Possibly with an optional automatic track change? 02.59.08 # why add something? 02.59.09 # Also, before I lose track: http://pastie.org/903229 OK, or not OK? 02.59.37 # Blue_Dude: Why do you want to push the splash just because you like it? 02.59.40 # kugel: not everyone wants to keep going. Why not make it easy for him if he wants ti? 03.00.05 # I guess I can take it out of bookmark.c too... 03.00.10 # Blue_Dude: this is too minor to increase bloat imo 03.00.37 # kugel: what's too minor, the mark for deletion or the splash? 03.00.48 # the former 03.01.04 # The mark for deletion just needs to have the existing bugs worked out. It doesn't need a setting to automate a single additional button press. 03.01.42 # the current item can be changed to mark for deletion if you want, it doesn't make sense to me if you add another one parallel to that with an extra option for something as minor (really really really minor IMO) as an automatic track skip 03.01.51 # Working out the bugs is possible only if you define the correct behavior. I can't even get the file to delete consistently. 03.02.06 # we could simply fix the bug instead of overengineering this 03.02.29 # Blue_Dude: intended behavior *is* defined 03.02.31 *** Saving seen data "./dancer.seen" 03.02.48 # play out what's in the buffer 03.02.54 # its defined you just can't predict it without looking at the buffering debug screen 03.03.02 Join grndslm [0] (~grndslm@174-126-14-4.cpe.cableone.net) 03.03.03 # I assume that the correct behavior is to always delete the file though. 03.03.07 # * Llorean really thinks splashes are only needed to tell users things they might not already know, and shouldn't follow a choice they explicitly made. 03.03.26 # playing out the track (with possibly buffering the rest of it), i.e. mark for deletion, would be an improvement imo 03.03.27 # Blue_Dude: Yes, but your assumption is actually wrong. 03.03.41 # Llorean: ok, ok. I'll take out the one in bookmark.c too when I have the chance. 03.03.44 # Well, it will always be deleted, yes, but deletion != "skip forward in playback" 03.03.54 # Blue_Dude: What's the one in bookmark.c for? Another yes/no? 03.04.33 # Llorean: No, I mean I tried the behavior in the sim, and I couldn't get the file to delete all the time. Sometimes it would and sometimes it wouldn't/ 03.04.44 # But that's simply a bug. 03.04.54 # Blue_Dude: I already told you twice that this is a bug 03.04.55 # Llorean: yes, another yes/no. The bookmark delete function. 03.05.15 # I don't remember bookmark deletion having a confirmation, though I haven't done it in a while. 03.05.19 # your proposed fix isn't a fix though because it changes the intended behavior 03.05.20 # Didn't it used to be a single button press? 03.05.21 # I know, but what's buggy, the fact that it won't delete? 03.05.32 # ...yes 03.05.46 # The file should *always* be removed. 03.05.47 # I actually explained where the bug is too 03.05.51 # Llorean: no, I don't think so. I didn't change its behavior. 03.06.09 # Anyway, if there's always a yes/no dialogue, then there should be no splash. 03.07.32 # kugel: To sum up: close the file handle, delete the file, keep playing whatever is buffered... is that it? 03.07.47 # splashes should only used for important things (because they're so different to the rest of the ui), confirming a decision just made is not imporant 03.08.21 # Blue_Dude: basically, but as I mentioned there's a glitch when closing the handle early 03.08.31 # which is why I didn't fix it yet 03.09.14 # It sure would make it easier if you just invalidated the buffering handle at the same time. 03.09.42 # I know that's not going to happen. 03.10.21 # the bug is that buffering doesn't close the file handle when it notices that the file to buffer doesn't fit into the remaining buffer space 03.10.49 # so, until the next rebuffer the file is basically blocked 03.11.17 # FWIW i really dislike the idea of continuing to play after you attempt a delete because its so target specific 03.11.32 # or at least the way we do it now 03.12.13 # hmm i take that back 03.12.13 # which is why I consider mark for deletion as an improvement 03.12.37 # yeah i see what you're getting at now 03.13.47 # I know next to nothing about the buffering system. Is there a way to set flags on buffered items? 03.19.08 # Anyway, I'll look into it. Eventually. I'd like to fix the bookmark stuff first. 03.20.58 # New commit by 03Blue_Dude (r25473): Fix capitalization in hotkey dialog 03.24.49 Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 03.32.24 # * linuxstb should really dig out his patch to remove gratuitous use of Title Case 03.35.00 # linuxstb: yes you should ;) 03.35.28 # time's working against you 03.39.43 Quit linuxstb (Ping timeout: 248 seconds) 03.40.20 # * flyback thinks the caps on this mb might finally be going, firefox keeps seg faulting 03.42.39 Mode "#rockbox +o Llorean" by ChanServ (ChanServ@services.) 03.42.46 Join froggyman [0] (~me@unaffiliated/froggyman) 03.43.02 Kick (#rockbox flyback :You've been warned about this being an on-topic channel.) by Llorean!~DarkkOne@rockbox/user/Llorean 03.43.10 Mode "#rockbox -o Llorean" by ChanServ (ChanServ@services.) 03.43.48 Join flyback [0] (~unsure@c-98-219-129-239.hsd1.pa.comcast.net) 03.45.00 # so all the versions of sansa clip are supported? 03.45.30 # Targets are listed on the front page of the site. 03.46.06 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 03.53.27 Quit Strife89 (Quit: Bed.) 04.03.30 Quit adnyxo (Ping timeout: 252 seconds) 04.05.15 Quit TheSeven (Disconnected by services) 04.05.30 Join The_Seven [0] (~theseven@rockbox/developer/TheSeven) 04.05.40 Nick The_Seven is now known as TheSeven (~theseven@rockbox/developer/TheSeven) 04.08.05 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 04.15.36 Quit kugel (Remote host closed the connection) 04.16.08 Quit adnyxo (Ping timeout: 276 seconds) 04.16.55 Quit CaptainKewl (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) 04.22.16 Part froggyman 04.29.00 Join Rob2223 [0] (~Miranda@p4FDCB465.dip.t-dialin.net) 04.32.39 Quit Rob2222 (Ping timeout: 265 seconds) 05.00.33 Quit Barahir_ (Ping timeout: 260 seconds) 05.00.34 Join RandomInsano2 [0] (~4ad84807@giant.haxx.se) 05.01.51 # Hiya. I'd like to add some scans I've done of the internals of an Insignia NS-DV2G to the Telechips Info page. 05.02.17 Join Barahir [0] (~jonathan@gssn-5f7547e9.pool.mediaWays.net) 05.02.33 *** Saving seen data "./dancer.seen" 05.02.43 # I needs Wiki edit priviledges for username RandomInsano 05.02.45 # RandomInsano2: sure, whats your name 05.03.01 # Edwin Amsler, but I chose a different handle. 05.03.11 # oh, well fix that then i'll give you access 05.03.19 # Alrighty 05.03.50 Quit n17ikh (Ping timeout: 245 seconds) 05.03.58 # Is that possible, or should I just create a new user? 05.04.43 # i think you need to make a new account 05.05.02 # I'll go do that then. Delete the current then please 05.06.59 # How... do I log out? 05.08.36 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 05.08.42 # Registration complete for 'EdwinAmsler' 05.10.58 Join funman [0] (~fun@rockbox/developer/funman) 05.13.47 # RandomInsano2: ok added 05.14.27 # Much thanks! I'm still a little unclear how I logout of the wiki so I can log back in 05.14.52 # I have another theory for CGU_PROC / CGU_PERI on as3525v2 05.15.08 # CGU_PROC divides PLLA to give fclk 05.15.15 # CGU_PERI divides fclk and not PLLA to give pclk 05.19.04 Join CaptainKewl [0] (~jason@207-237-106-60.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 05.19.11 Join arbingordon [0] (~w@unaffiliated/arbingordon) 05.19.23 Join mikroflops [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) 05.19.23 Quit RandomInsano2 (Quit: CGI:IRC (EOF)) 05.23.09 Quit mikroflops_ (Ping timeout: 264 seconds) 05.26.38 Quit TillW (Quit: This now concludes our broatcast day.) 05.26.55 Join fejfighter [0] (~fejfighte@C-61-68-102-68.hay.connect.net.au) 05.29.46 # Reading through the logs, Re: the guy that "killed" his iPod, he mentioned he installed an SVN bootloader (though I have no idea why ipodpatcher refused to detect his iPod, *unless* he was messing with advanced-iPodpatcher install options and fucked it up...I' guilty of doing this myself). I haven't checked in the last week or so, but the SVN bootloader for Nano2g just blackscreens the player. 05.29.57 # ...May have been a contributing factor. 05.32.10 # * funman slaps buschel for not testing r25464 05.33.56 # Errrr, perhaps slightly unclear. "Blackscreen" being: turn on, Apple logo, indefinite black screen needing a hard reboot. 05.34.58 Join kramer3d [0] (~kramer@unaffiliated/kramer3d) 05.41.29 Quit scorche (Disconnected by services) 05.41.39 Join scorche` [0] (~scorche@rockbox/administrator/scorche) 05.42.17 Quit stavrob (Ping timeout: 258 seconds) 05.42.58 Join stavrob [0] (~sam@78-105-125-218.zone3.bethere.co.uk) 05.43.31 Quit Minataku (Ping timeout: 276 seconds) 05.50.35 Join Minataku [0] (~Ed@unaffiliated/payphoneed) 06.03.07 Quit jd (Quit: Ω) 06.03.44 Join jd [0] (~jd@modemcable207.134-202-24.mc.videotron.ca) 06.03.44 Quit jd (Changing host) 06.03.44 Join jd [0] (~jd@Wikipedia/HellDragon) 06.05.58 Join notlistening [0] (~tom@94-195-105-95.zone9.bethere.co.uk) 06.08.02 # Hey bluebrother just saw that your trying to do some wine detection when people are running under linux etc. Domonoky did some some silimar work when we put open-sapi in rbutil if you have done it no worries but there was a solution that worked quite well when we did that 06.14.57 # fuzev2 works fine at 24MHz but the display is noticeably slower 06.15.21 # Do you have a runtime for 24MHz yet? 06.15.33 # nope i just got it right in my build 06.15.53 # Aha...so, bench tonight? ;) 06.16.11 # previous bench for Clip+ (16h30) was with CPU at 24MHz / peripheral clock at 6MHz, and 10 times faster when boosted 06.16.14 # not sure 06.20.28 Join TillW [0] (~Till@h74-net09.simres.netcampus.ca) 06.26.47 # funman do you sleep :D 06.27.17 # Is it normal for the Clip+ to have a yellow/orange bar at the top of the screen? 06.27.23 # "can't sleep... must. fix. red." :P 06.28.00 # lol now as someone is talking about red I see it all the time on commits what is red etc etc? 06.28.25 # Red = Bad, broken. etc. 06.28.42 # notlistening: yes the top quarter of the screen is yellow on all clips and the rest blue 06.30.28 # ahh but S_a_i_n_t_ to put a commit as fix red and thats all is a bit non descriptive? 06.30.36 # thanks funman 06.31.49 # notlistening: yes, it is...but it seems to be a habit now. 06.31.54 # Or, for some time rather. 06.32.50 # fair enough, they guys here at rockbox are mega good at not breaking things on commits so it is not the biggest issue 06.33.10 # * S_a_i_n_t_ isn;t so sure about that sometimes ;) 06.33.35 Nick S_a_i_n_t_ is now known as S_a_i_n_t (S_a_i_n_t@203.184.0.160) 06.34.07 # someone with an e200v1 could give me the results of test_fps with both boosted & unboosted CPU ? 06.35.59 # only got a V2 sorry 06.38.37 # funman: beyond the ones on the wiki: http://www.rockbox.org/wiki/LcdFrameRate 06.38.45 # if so I can compile that plugin 06.40.29 # ah nope, it's enough, thanks 06.41.53 # pixels swapping for fuzev2 display slows down things a bit 06.43.30 # without swapping, and pclk==60MHz, performance is a small bit under fuzev1 (pclk==62MHz) 06.44.59 # with swapping (and thus correct display) I get 73fps for 1:1 updates unboosted 06.45.06 Join Eugenpaul [0] (~ugnpaul@cache.vsu.ru) 06.45.17 Part Eugenpaul 06.47.57 Join n1s [0] (~n1s@rockbox/developer/n1s) 06.48.40 # New commit by 03funman (r25474): test_mem: fix r25464: button_get() can't be used with actions 06.48.45 # New commit by 03funman (r25475): as3525v2: set PCLK correctly ... 06.51.20 # I wonder if it's possible to change pixel format with the Fuzev2 LCD 06.55.50 # funman: what was pclk at before when unboosted? 06.56.44 # 6MHz on Clipv2/+ and 15MHz on Fuzev2 06.57.11 # no changes in playback because mclk is based on PLLA which didn't change 06.57.17 # and timers are based on the 24MHz crystal 06.57.47 # mclk is the DRAM? 06.58.06 # not it's the i2s clock 06.58.10 # for pcm/recording 07.01.00 Quit CaptainKewl (Remote host closed the connection) 07.02.35 *** Saving seen data "./dancer.seen" 07.13.30 Quit panni_ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )) 07.26.01 Quit drostie (Remote host closed the connection) 07.26.45 Join kramer3d_ [0] (~kramer@unaffiliated/kramer3d) 07.29.59 Quit kramer3d (Ping timeout: 264 seconds) 07.30.31 Quit mc2739 (Ping timeout: 268 seconds) 07.30.45 Nick kramer3d_ is now known as kramer3d (~kramer@unaffiliated/kramer3d) 07.36.11 Part veeloc 07.41.54 # New commit by 03funman (r25476): Fuzev2: write pixel swapping in assembly for a some speed up ... 07.44.35 Join Horscht [0] (~Horscht2@xbmc/user/horscht) 07.45.59 Quit Horschti (Ping timeout: 246 seconds) 08.01.05 Join r2k000 [0] (~r2000@130.166.243.19) 08.23.01 Quit JohannesSM64 (Quit: WeeChat 0.3.2-dev) 08.27.12 Quit CGL (Remote host closed the connection) 08.28.10 # funman: Why don't you just use swap_odd_even32() from system-arm.h? It doesn't need a separate mask and also just 4 cycles on arm <= v5 08.28.47 # oh didn't know it existed 08.29.01 # (also i don't know the armv5 isntructions) 08.30.02 # It uses plain armv4/v5 instruction, nothing special 08.30.25 # ah i was looking at v6 then 08.30.34 # On armv6 it's a single instruction, but that's irrelevant on the ams sansa 08.30.36 # +s 08.33.14 Quit r2k000 (Ping timeout: 258 seconds) 08.35.25 # New commit by 03funman (r25477): Fuzev2: don't reinvent the wheel: swap pixels with existing swap_odd_even32 ... 08.37.21 Quit pixelma (Disconnected by services) 08.37.22 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 08.37.42 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 08.37.55 Quit amiconn (Disconnected by services) 08.37.57 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 08.38.19 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 08.41.26 Join JanDo [0] (~JanDo@212.44.150.75) 08.41.40 Quit n17ikh (Read error: Connection reset by peer) 08.42.00 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 08.44.24 Join bmbl [0] (~Miranda@unaffiliated/bmbl) 08.45.08 Join Boldfilter [0] (~Boldfilte@adsl-82-103-24.jax.bellsouth.net) 08.48.01 # amiconn: do you want to modify the fuzev1 write_yuv() functions to add this swapping ? 08.49.23 # green part needs to be split in 2 08.50.02 # r(5)g(6)b(5) = r(5)g1(3)g0(3)b(5), needs to be g0(3)b(5)r(5)g1(3) 08.52.20 Quit kramer3d (Quit: Leaving) 08.53.43 Quit n1s (Ping timeout: 264 seconds) 08.55.08 # * amiconn wonders why the fuze doesn't use RGB565SWAPPED as the pixel format if the lcd controller needs it swapped 08.55.15 # if i go the stupid way there is 3 more instructions per pixel (2 to extract g1 & g0, and 1 shift for each componnent) 08.55.26 # It would save the swapping in the update (not for yuv of course) 08.55.26 # * funman discovers new things everyday 08.58.20 # in fact i had looked at lcd-16bit.c but didn't see anything 09.02.07 # Of course not, since lcd-16bit.c doesn't have to care about the actual bit order within the 16 bits 09.02.36 # ok i'm just testing it 09.02.40 *** Saving seen data "./dancer.seen" 09.02.48 # what about yuv assembly, are you interested? 09.02.56 # All colour PP ipods (Color/PHoto, Nano G1, Video) use RGB565SWAPPED 09.03.12 # yep I see bmp2rb -f 5 option is documented as being "Ipod" 09.09.20 Quit notlistening (Quit: Leaving) 09.10.03 # New commit by 03funman (r25478): Fuzev2: use RGB565SWAPPED (pointed out by amiconn) => 91fps 09.11.05 # amiconn: ? 09.12.50 # is 100 fps still the limit like on the v1? 09.18.05 Part Boldfilter 09.18.13 # I don't remember how the limit was calculated 09.18.30 # supposing the DBOP hardware didn't change it should be the same afaiu 09.21.11 # amiconn: reading lcd-as-video.S i don't see where the 16 bits rgb value is swapped? 09.21.44 # aren't they computed in swapped order? 09.21.51 # ah ipodvideo lcd isn't swapped 09.22.07 Join n1s [0] (~n1s@rockbox/developer/n1s) 09.22.13 # only color & nano1g 09.23.51 # and they just use swap16() 09.25.31 # the vibe500 has asm but the LCD register is 8 bits so it just swaps the order of writing 09.28.18 Quit n1s (Ping timeout: 268 seconds) 09.29.46 # funman: Eh, sorry, the video does not need swapping 09.30.20 Quit JanDo (Ping timeout: 276 seconds) 09.30.29 # Color and Nano still use the old C mess 09.30.55 # * amiconn needs to finish his PP colour lcd bridge work :\\ 09.33.09 Quit phanboy_iv (Read error: Connection reset by peer) 09.36.33 Join JanDo [0] (~JanDo@212.44.150.75) 09.47.33 # New commit by 03funman (r25479): Fuzev2: YUV output adapted from Fuzev1 09.49.01 Join ender` [0] (krneki@foo.eternallybored.org) 09.51.47 # * funman "fixed" the bmp2rb yellow 09.56.46 Nick scorche` is now known as scorche (~scorche@rockbox/administrator/scorche) 10.03.08 # * funman starts benching Clipv2 10.06.14 # i guess the fixed pclk should mean less boosting? 10.08.14 # since memory is faster yep 10.08.25 # i have no previous bench for clipv2 though 10.08.50 # and it crashed earlier so i hope it'll work for the whole 15 hours or so 10.09.14 # from what i understand the clock changes made the sd driver fairly unstable 10.09.35 # yep especially µSD 10.09.45 # it could be better now 10.10.41 Join stoffel [0] (~quassel@p57B4D0F1.dip.t-dialin.net) 10.12.16 # the low clock on the amsv2 is nice, finally gives me a reason to look into making mp3 faster again 10.13.00 # bet we could shave 1 or 2 MHz off the filterbank on arm9e 10.15.08 # (clipv2 crashed) 10.26.31 Join flydutch [0] (~flydutch@host225-165-dynamic.15-87-r.retail.telecomitalia.it) 10.29.41 # I started the Clip+ with the same album I had used previously, let's if i have better luck 10.30.10 # i also have put backlight always on on the clipv2 to see if it panics 10.32.57 # clip+ crashed too :( 10.41.52 Join Kitr88 [0] (~Kitr88@BSN-142-95-35.dial-up.dsl.siol.net) 10.41.57 Quit Kitar|st (Read error: Connection reset by peer) 10.46.44 # Is the "lamp" plugin supposed to time out at all, after "X" period, or after a completely random "Y" period? 10.46.52 # Using it, its kinda hard to tell. 10.46.56 Quit Kitr88 (Ping timeout: 276 seconds) 10.47.37 # it doesn't timeout 10.47.51 # Somtimes it appears to "time out" (the period is random), and others it just crashes the player. 10.48.05 # which player. 10.48.06 # ?* 10.48.16 # Nano1/2g I get the results I've just mentioned. 10.48.48 # It looks as though the battery dies, but when I start it back up the battery is always fine. 10.49.22 # but when it appaers to "time out" (ie. not crashing the player) it always seems to be a different time limit. 10.49.42 # But now you've said it *doesn't* time out, its even weirder still. 10.50.01 # according to lamp.c it will exit if you press any button other than left/right and scrollwheel 10.50.24 # Yes, this is just starting it up and leaving it though. 10.50.33 # (I tried to use it to read last night) 10.50.40 # ...much to my dismay. 10.50.58 # how much time approximately? i just started it on fuze 10.51.20 # It seems to be anwhere from 1~5minutes on my Nanos 10.51.42 Join Kitar|st [0] (Kitr88@89.142.228.42) 10.51.55 # Ahem.."anywhere from 1 to 5 minutes." 10.54.21 # failed after 2 minutes an Nano1g just now. 10.54.33 # Nano2g still going. 10.54.43 Join Lynx_ [0] (~Lynx@86.51.114.197) 10.54.49 # Batter on the 1g reads 92% 10.55.19 # Nano2g failed, batter 44% (lamp.rock on for 3mins approx) 10.57.36 # no crash on fuzev2 10.57.49 Quit Rob2223 (Ping timeout: 265 seconds) 10.58.05 # something happen if you just leave the backlight always on and sit in a plugin ? 10.58.18 # Hmmm, well. The Nanos don't seem to be able to handle it for some reason. 10.58.37 # and no, it can sit in a plugin with the backlight on indefinitely. 10.58.42 # (as far as I know) 10.58.44 # funman: I had a damaged .ogg that crashed the clip+ on Rockbox. Then I tried OF and it froze completely -> 10sec power was the only way out. So RB was much better :) 11.00.00 Quit bluebrother (Disconnected by services) 11.00.01 Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) 11.00.50 # funman: I'm letting it run "plasma.rock" with backlight set to "on" to see if it fails there too. (I figure plasma will be a bigger battery eater than lamp, but I may be wrong) 11.01.08 # funman: I still have the file if you think it is worth fixing the code to make it cope with this type of damage 11.01.24 Join Rob2222 [0] (~Miranda@p4FDCB465.dip.t-dialin.net) 11.02.05 # Funman, wow..actually, you were right. 11.02.12 # ThomasAH: Clip+ crashes randomly for me so unless you can reproduce the crash on another target i won't have any use for your file 11.02.24 # Plasma.rock with backlight on kills it even faster than lamp does. 11.02.40 # but when it starts back up, the battery still reads the same. 11.02.41 *** Saving seen data "./dancer.seen" 11.03.00 # * S_a_i_n_t is slightly confused. 11.03.48 # funman: hmm, with svn from today I just had random crashes, too ... 11.03.48 # Wait, if a plugin is running..."idle timeout" shouldn;t matter, should it? 11.04.00 # (internal memory) 11.04.05 # ThomasAH: if you can put it online, you might as well file a bug report 11.04.24 # assuming it crashes repeatedly in rockbox 11.04.41 # saratoga: repeatedly in roxbox and OF at the same second 11.04.51 # family interrupt ... 11.05.05 # thats probably a bug the vorbis decoder, the OF and rockbox use the same one 11.12.03 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 11.16.31 Join Highlander [0] (~Highlande@mek33-4-82-236-45-205.fbx.proxad.net) 11.19.11 # Hmmm, a little testing points to the idle timeout not being applied correctly. With idle timeout set to off, all is well in lamp.rock-land, but when its set to timeout at 1min lamp.rock continues running anywhere from 1~5mins. 11.20.07 # IMO lamp.rock shouldn;t timeout at all.Even if there is a timeout period set, But that's just me. 11.21.21 # as long as you're screwing around with that, maybe add an option to leave the backlight on in in test_codec too 11.21.41 # or just leave it on all the time, the time out is annoying and seems to cause problems on the clipv2 11.22.01 Quit saratoga (Quit: Page closed) 11.34.43 Quit funman (Quit: free(random());) 11.46.42 Part JanDo (" www.qip.im ") 11.48.59 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 11.54.50 Quit flydutch (Quit: /* empty */) 11.58.04 Nick YPSY is now known as Ypsy (~ypsy@geekpadawan.de) 12.01.43 Join merbanan [0] (~banan@c-62-220-165-110.cust.bredband2.com) 12.08.02 # New commit by 03Buschel (r25480): test_boost: fix r25464: button_get() can't be used with actions 12.13.00 Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) 12.18.43 Join kugel [0] (~kugel@rockbox/developer/kugel) 12.50.04 Join geertvdijk [0] (~chatzilla@cc412026-a.zwoll1.ov.home.nl) 12.56.57 Quit kugel (Ping timeout: 264 seconds) 12.59.39 Join kugel [0] (~kugel@rockbox/developer/kugel) 13.01.55 Join Xerion [0] (~xerion@82-170-197-160.ip.telfort.nl) 13.02.44 *** Saving seen data "./dancer.seen" 13.03.13 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 13.13.52 # * kugel thinks the devcon could well have a few more participants 13.15.53 # who? 13.16.12 # Or do you mean should have? 13.16.12 # whoever wants 13.16.38 # last year we were 2 more 13.18.02 # hm, I see Zagor in the participants list but B4gder in the bed room list 13.18.15 # I guess both come? 13.18.16 # yeah, they are both coming though 13.18.37 # It is just one isn't sleeping and the other isn't participating :) 13.19.23 # :p 13.20.08 # I'll try to but don't know yet... and there were a few who decided quite late the last years too 13.20.34 # that was me ;) 13.23.08 # * gevaerts thinks they're both sleeping 13.23.26 # Only one of them is participating though 13.33.11 Nick Ypsy is now known as YPSY (~ypsy@geekpadawan.de) 13.48.01 Join JanDo [0] (~JanDo@212.44.150.75) 13.51.57 # Is there something wrong with the theme site? The admin page seems to insist on showing me all themes 13.56.46 Join froggyman [0] (~me@unaffiliated/froggyman) 13.59.30 Part froggyman 14.01.46 # New commit by 03kugel (r25481): Fuzev2: Reduce code duplication by reusing Fuzev1 code. 14.02.21 # hm, git tricked me 14.02.26 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 14.02.58 # New commit by 03kugel (r25482): Add forgotten file (git was supposed to rename!). 14.04.50 # interesting, bootloader reds. I don't think we need yuv blitting in the bootloaders 14.08.31 # there's a Packard Bell Vibe500 build in the 8MB-Recorder build download - hence the delta 14.09.50 # stuff like this happens from time to time in the last month(s), I wonder what's going on there 14.12.45 # pixelma: Zagor says this is a build server bug that he has not been able to track down 14.13.09 # * gevaerts has a look at the code 14.13.20 # It's perl though, so I might not find much 14.17.13 # New commit by 03kugel (r25483): as2525(v2): We don't need yuv blitting/greylib support in the bootloader so don't compile it. 14.17.16 # if it's only happening sometimes, I can only imagine a timing problem (maybe if two builds are received at the same time or so) 14.17.33 Quit stoffel (Ping timeout: 246 seconds) 14.17.53 Join kugel_ [0] (~kugel@e178098254.adsl.alicedsl.de) 14.17.54 Quit kugel (Ping timeout: 265 seconds) 14.17.59 Nick kugel_ is now known as kugel (~kugel@e178098254.adsl.alicedsl.de) 14.18.11 Quit kugel (Changing host) 14.18.11 Join kugel [0] (~kugel@rockbox/developer/kugel) 14.18.35 # they should have unique names by then 14.19.42 Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) 14.20.36 Quit Adubb (Read error: Connection reset by peer) 14.23.31 Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.brig.cable.ntl.com) 14.23.32 # New commit by 03kugel (r25484): Fix yellow. Another function unneeded in the bootloader. 14.25.10 Quit Highlander (Quit: Quitte) 14.26.34 # now it's some other builds that go wrong... 14.32.09 Join froggymana [0] (~187b533e@giant.haxx.se) 14.35.58 Quit stripwax (Quit: http://miranda-im.org) 14.37.54 Join mt [0] (~chatzilla@41.233.151.87) 14.42.46 Join mikroflops_ [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) 14.45.15 Join dfkt [0] (dfkt@unaffiliated/dfkt) 14.46.09 Quit mikroflops (Ping timeout: 240 seconds) 14.47.22 Quit mt (Remote host closed the connection) 14.51.04 Join mt [0] (~chatzilla@41.233.151.87) 14.55.20 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 14.55.32 Join yorick [0] (~yorick@s55924da0.adsl.wanadoo.nl) 14.56.55 # hmm...my player is consistently refusing to play my music in the database order 14.57.17 # is "shuffle" on? 14.57.27 # I think not 14.57.32 # sorry...I know it sounds stupid, but you'd be surprised. 14.57.53 # but would that show the behavior of "select file" -> "play entirely different one" 14.58.08 # Ah, no. It wouldn't. 15.00.30 # "play track 1" "screw it, I'm playing track 3 and then continuing randomly, entirely skipping track 2" 15.00.56 # that does sound like shuffle to me... 15.01.09 # maybe it's skipping those tracks because of a codec error 15.01.15 # that's possible too 15.01.29 # bodgy FS? 15.01.43 Join jgarvey [0] (~jgarvey@cpe-065-190-066-089.nc.res.rr.com) 15.01.52 # what player is this anyway? and what rockbox version? 15.01.59 # I can rewind back to track 1 15.02.03 # yorick: Have you checked that shuffle isn't enabled? 15.02.10 # it's an apple ipod video 30GB 15.02.35 # with rockbox 3.5.1 15.02.40 # Shuffle can be switched on pretty easily by mistake with the quickscreen... 15.02.47 *** Saving seen data "./dancer.seen" 15.02.47 # ?me has done this *many* times. 15.03.02 # ah great now it's stuck on "Scanning disk..." 15.03.32 Quit geertvdijk (Ping timeout: 264 seconds) 15.03.55 # "Shuffle No" 15.03.58 # "Repeat Off" 15.04.03 # "Show Files Supported" 15.04.39 # hmm, it played the same track 3 times now 15.04.58 # basically, I took my ipod video, with 25 GB of music on it 15.05.03 # and then installed rockbox on it 15.05.07 # and initialized the database 15.05.20 # the original firmware still works fine 15.05.30 # gevaerts: haven't looked inside the wrong Ipod3G one but the other two which went wrong had builds in them that were done by n17-roolku (the build table listed some different clients for the actual builds so I looked at the builds that were actually included). Two results isn't a very safe bet yet though 15.05.31 # one album is even entirely doubled 15.05.44 # I'm ussuming that the original (Apple) firmware plays tracks free from error? 15.05.50 # *assuming 15.06.11 # yorick: After Rockbox initialised the database, how did you restart Rockbox? i.e. what buttons did you press? 15.06.30 # I did menu+select 15.06.38 # because it wasn't shutting down with long play 15.06.42 # yorick: maybe try checking the filesystem. Filesystem corruption has been known to cause all sorts of weird issues 15.06.54 # how am I supposed to check the filesystem 15.07.04 # depends on your OS 15.07.11 # ubuntu 9.10 15.07.32 # yorick: Are all the tracks the same format ? Or are the ones being skipped of different format than the ones being played correctly ? 15.07.36 # fsck.vfat then 15.07.55 # mt: all the same format 15.08.01 # CBR 320kpbs mp3 15.08.06 # it happens on every album 15.08.22 # pixelma: at least one of today's wrong builds came from GodEater's system 15.08.39 # yorick: Do you normally eject/unmount your ipod before unplugging it, or do you somethings just pull the cable out? 15.08.56 # I do safely remove :) 15.08.56 # gevaerts: I meant the build that was actually put in the wrong zip 15.09.23 # pixelma: yes, that's what I mean too :) 15.09.45 # hmm I think I fixed it 15.09.59 # gevaerts: was that the round with the wrong 3G Ipod build? 15.10.15 # pixelma: no, the one after, with the wrong yh920 15.10.19 # it was the centerart theme 15.10.21 # oh, wait, no 15.10.28 # switching to the rockboxed theme fixed all my problems 15.10.32 # The one before, with the wrong recorder 15.11.13 # yorick: that really shouldn't change anything... 15.11.14 Quit antil33t (Read error: Connection reset by peer) 15.11.17 # yorick: Generally speaking, a theme *shouldn't* affect playback. 15.11.19 Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) 15.11.22 # well it did 15.11.37 # gevaerts: then we are talking about different things. I mean - the recorder build had a Vibe500 in it (which was build by n17-roolku). The last round has an Onda v777 in it (which was build by n17-roolku) 15.11.54 # pixelma: hm, maybe I wasn't looking right... 15.11.58 # yorick: I would still check the filesystem for errors. And probably re-initialise the database. 15.12.17 # gevaerts: in the Samsung zip 15.12.36 # ok...switching back to CenterArt -> broken again 15.12.45 # Yes, I know. I mean, maybe I didn't look at the r25482 case properly 15.12.46 Join evilnick_B [0] (~0c140464@rockbox/staff/evilnick) 15.13.10 # yorick: The fact that long-play didn't work isn't a good sign. Was Rockbox itself working fine (i.e. you could move around in the menus), or had it frozen? How long were you holding play for? 15.13.31 # yorick: Many people use that theme..I'm sure there would be more people complaining if it was the theme alone that "broke" playback. 15.13.59 # linuxstb: every part of rockbox worked otherwise 15.14.06 # except the database, which told me to reboot 15.14.19 # could the charger being plugged in have anything to do with it? 15.14.33 # Yes, Rockbox won't shut down if the charger is plugged in. 15.14.40 # S_a_i_n_t: I know it's strange, but it's true... 15.15.02 # there is probably something deeper going on here...*probably* 15.15.16 Join kugel_ [0] (~kugel@e178098254.adsl.alicedsl.de) 15.15.18 # I can't reproduce it in the sim, the theme works fine for me. 15.15.24 # well yes, the filesystem is still a reasonably likely candidate... 15.15.25 # * yorick will reinitialize the database 15.15.30 Quit kugel (Disconnected by services) 15.15.33 # or check the filesystem first? 15.15.36 Nick kugel_ is now known as kugel (~kugel@e178098254.adsl.alicedsl.de) 15.15.40 Quit kugel (Changing host) 15.15.40 Join kugel [0] (~kugel@rockbox/developer/kugel) 15.15.47 # yorick: As we've all been saying for 10 minutes, check the filesystem... 15.16.24 # hmm it switched back to some kind of other screen after connecting 15.16.42 # define "other screen" 15.16.44 # Probably Apple's disk mode screen. 15.17.22 # empty screen showing battery symbol, flashing forbidden sign, and "Do not disconnect." 15.17.37 # Apple disk mode, this is fine. 15.17.40 # And normal. 15.17.59 # hmm lets see: fsck.vfat /media/ipodmountpoint 15.18.00 # right 15.18.11 # no, the device, not the mountpoint 15.18.34 # after unmounting first 15.19.22 # unmounting automatically ejects it 15.20.04 Quit froggymana (Quit: CGI:IRC) 15.20.38 Join froggymana [0] (~187b533e@giant.haxx.se) 15.20.42 Join n1s [0] (~n1s@rockbox/developer/n1s) 15.22.37 # I know umount doesn't do that. Maybe ubuntu's gui tools do, but I don't know those... 15.22.54 # Does that affect the ipod though? 15.23.22 # ipod says "OK to disconnect" 15.23.23 # yorick: Type "mount" at the command-line, and that should tell you the device - e.g. "/dev/sdb2" 15.24.03 # OK, as soon as it says that you can run fsck on it 15.24.10 # /dev/sdb2 on /media/myipodname type vfat (rw,nosuid,nodev,uhelper=devkit,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,flush) 15.24.24 # OK, so first do "sudo umount /dev/sdb2" 15.24.33 # * linuxstb doesn't know the fsck syntax... 15.24.58 # I did umount /media/ipodname 15.25.06 # fsck.vfat -a /dev/sdb2 15.25.10 # it said "it's now safe to remove ipod" 15.25.23 # and ipod is still on "Do not disconnect" 15.25.44 # What said "it's now safe to remove ipod" ? The umount command should just say nothing. 15.25.54 # the umount command 15.26.31 Join lpereira [0] (~lucien@142.12.92-79.rev.gaoland.net) 15.26.49 # http://pastebin.com/CYUgq3Jr 15.27.24 # ok, so it's not filesystem corruption 15.27.42 # hmm now how do I disconnect it 15.27.47 Quit mikroflops_ (Ping timeout: 268 seconds) 15.27.55 # it did it in 5 seconds? 15.28.05 # hm, good point 15.28.32 # well, it might 15.28.39 # Anyway, just disconnect it. It's not mounted, so it's safe 15.29.05 # it says "Do not disconnect" 15.29.30 # if you really want to, run "eject /dev/sdb" first then, but it's not needed in this case 15.29.41 # fsck time usually depends on the number of files, not on the size of the disk 15.29.55 # and 3000 files isn't *that* many 15.30.16 # depends on the size of said files though...no? 15.30.25 # 20 GB 15.30.29 Join mikroflops [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) 15.30.53 # I'll reinitialize the database 15.31.03 # S_a_i_n_t: a bit, but that's all in the FAT, so it's one block of consecutive data, which is fast 15.31.29 Quit ender` (Ping timeout: 252 seconds) 15.31.30 # Ahhh...good point. Still, damn fast, impressive. 15.32.03 # how do I reinitialize the database then 15.32.24 Join ender` [0] (krneki@foo.eternallybored.org) 15.32.55 Quit JanDo (Quit: goes home) 15.33.05 # when I do "Initialize Now" it says "Updating in Background" 15.36.26 Quit mikroflops (Ping timeout: 252 seconds) 15.37.28 Join mikroflops [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) 15.43.38 Join geertvdijk [0] (~chatzilla@cc412026-a.zwoll1.ov.home.nl) 15.45.48 Join Schmogel [0] (~Miranda@p3EE21F3A.dip0.t-ipconnect.de) 15.49.31 Join CGL [0] (~CGL@190.207.232.170) 15.50.22 # hmm...centerart is the only theme I installed using rockboxutility 15.50.28 # could it be it's broken somehow 15.50.37 # and breaks playback somehow 15.50.50 # because every other(preinstalled) theme works 15.51.26 # still sounds unlikely 15.52.02 # then what 15.52.21 # Did the problem stay after rebooting? 15.52.28 # yes 15.52.29 Quit froggymana (Quit: CGI:IRC) 15.52.33 # and after reinitializing the database 15.53.48 # perhaps the sim is doing something different (though, I am using an SVN sim, and not 3.5.1), but the theme works fine for me. 15.54.08 # maybe it's a 3.5.1 bug? 15.54.25 # *unlikely*, but possible. 15.54.34 # S_a_i_n_t: for this sort of weird issues, it's not that unlikely that the sim behaves differently 15.54.39 # I'm sure it would have been mentioned by now though. 15.54.56 # centerart uses custom menu, it says 15.55.24 # A theme can't alter the menu setup. 15.56.12 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 15.56.20 # centerart doesn't seem widely used, maybe only the database is bugged? 15.56.42 # downloaded 1886 times 15.56.57 # thats fairly *widely used* 15.57.00 # yorick: just to clarify, this is CenterArt and not CenterArt v2.0? 15.57.49 # this is v2.0 15.58.02 # (hehe) 15.58.21 # Well, *that* would have been nice to know from the start lol... 15.58.35 # I guess so 15.59.10 # Well, neither of them look very suspicious to me 15.59.43 # * gevaerts will try to reproduce this as soon as his ipod doesn't complain about a very low battery anymore 15.59.56 # v2.0 behaves as it should in the sim 16.00.01 Quit n17ikh (Ping timeout: 245 seconds) 16.00.05 # (or seems to at least) 16.00.07 # I'll install another theme and see if that also fails 16.00.10 Quit fejfighter (Ping timeout: 258 seconds) 16.01.04 # gevaerts: "wrong" builds? 16.01.09 # do I need to mend something? 16.01.45 # GodEater: no. There's a bug somewhere, probably in the server-side scripts, that sometimes puts an uploaded build in the wrong place 16.03.07 # ok...I installed another theme...that worked 16.03.12 # then switched back to centerart 16.03.18 # the center art thing is gone 16.03.21 # but the rest works fine 16.03.38 # "center art thing is gone"? 16.03.44 # as in, no album art/ 16.03.47 # yes 16.03.56 # and also no playlist 16.03.59 # does the track *have* album art? 16.04.04 # no 16.04.08 # but it didn't before 16.04.12 # well, there ya go ;) 16.04.19 # and it displayed some nice playlist instead of album art 16.04.23 # and now it doesn't do that aswell 16.05.38 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 16.06.07 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 16.09.25 Join Adubb [0] (~aldubuc@67.201.160.144) 16.11.28 # * kugel runs test_codec on fuzev2 16.12.02 Join TabalugaFX [0] (~d950faf5@giant.haxx.se) 16.13.00 # it's 25%-35% faster throughout all testable files 16.14.17 # hi @ all 16.14.29 Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 16.15.17 # I have a question about the themes submitting process which I can't find in the wiki / docs sections 16.15.31 # ...ask away. 16.15.53 # so I want to ask how and if it's possible to submitt my thmes which i have "updated" 16.16.00 Quit jordan` (Read error: No route to host) 16.16.07 # Use the dame details as before and it'll be replaced 16.16.10 # *same 16.16.22 # your name, your e-mail and theme name that is 16.16.28 # "re"submit it using the same author details and email address, it will ask for confirmation about replacing it. 16.16.57 # great thanks. this information would be useful inside the wiki / docs 16.17.08 # leave the fields for the .zip and screens empty, you'll need to refill them when you're asked for updating 16.17.16 # s/screens/screenshots/ 16.17.17 # TabalugaFX: The wiki is a wiki :) 16.18.37 # yes i know, so if i have more time i'll edit and add some informations 16.19.40 # and i have another question with an error or perhaps an unwanted bug 16.19.56 # Most of our bugs are unwanted 16.20.05 Join jordan` [0] (~jordan@78.235.252.137) 16.20.28 # yesterday i copied the full HVSC archive (SID) onto my player 16.20.50 # We can't fix that bug :) 16.21.15 # gevaerts: *most*? 16.21.24 # ;P 16.21.45 # S_a_i_n_t: well, we do have some debate about whether some things are bugs or features 16.21.52 Join stoffel [0] (~quassel@p57B4D0F1.dip.t-dialin.net) 16.22.03 # Ahhhh, right. Gotcha. 16.22.51 # and after a long waiting time of the database update process I want to listen to my SID music but after i switch from one track to another rockbox hangs up (occurs after the 6th or 7th switch) 16.23.18 # yorick: do you have the font pack installed? 16.23.38 # yes 16.24.00 # or sorry i wasnt mean 16.24.39 # TabalugaFX: Does this happen if playing through the file browser? 16.25.03 # no, while i'm using the wps 16.25.16 # but I created the playlist inside the file browser 16.26.10 # and i already turned off the repeat feature to sbypass the subsongs of every sid file 16.26.45 # I meant if you select the song through the filebrowser 16.26.55 # as opposed to the database 16.27.11 Quit stripwax (Quit: http://miranda-im.org) 16.27.14 # yes indeed i selected the folder i want to listend and add them to the playlist 16.27.19 # OK 16.27.39 # Sounds like a bug then 16.27.40 # gevaerts: dunno 16.27.59 # gevaerts: I did standard installation 16.28.10 # Could you add it to flyspray, including all the details (player, Rockbox version, settings etc.) and say how to reproduce it? 16.28.19 # yorick: does the CenterArt theme look correct, i.e. does it have proper line drawing? 16.28.39 # ok i'll 16.28.45 # gevaerts: yes 16.28.49 # TabalugaFX: Thanks 16.28.51 # btw thanks for your help 16.28.58 # no problem :) 16.29.03 # ah btw 16.29.12 Join paulk_ [0] (~paulk@lib33-1-82-233-88-171.fbx.proxad.net) 16.29.20 # is it possible to install rockbox on my dingoo a-320? 16.29.24 # nope 16.29.31 # :-( 16.29.32 # Only the players listed on www.rockbox.org 16.29.55 # yes i know, but dingux (dingoo linux) uses the rockbox bootloader 16.30.01 # really? 16.30.06 # Do you have a link? 16.30.11 # hmm wait 16.30.16 # Either way, full Rockbox would have to be ported 16.30.27 # yorick: can you check the font settings to see if the 14-Terminus-Bold font is there? 16.30.38 # It sounds like it should be possible, but it is a lot of work 16.32.12 # http://dingoowiki.com/index.php/Dingux:About#Installing_the_firmware (named "Rockbox mode") 16.33.40 # gevaerts: it is 16.34.55 # ooh it's broken again 16.34.57 # after rebooting 16.35.04 # TabalugaFX: I don't see any mention of Rockbox though, just something called Rockbox mode 16.35.31 # gevaerts: it just asked me if it was OK to remove dynamic playlist 16.35.40 # RockBox == Dualboot?!? (apparently) 16.36.35 # yorick: confirming deletion of a dynamic playlist is a system setting, this can be turned off. 16.36.43 Quit TabalugaFX (Quit: CGI:IRC) 16.36.47 # S_a_i_n_t: yes but I don't remember making one 16.36.50 # yorick: can you put the contents of .rockbox/config.cfg on a pastebin? 16.36.51 # it asked me this after a reboot 16.38.12 # gevaerts: http://pastebin.com/HQf9xMQd 16.38.26 Join TabalugaFX [0] (~5b264366@giant.haxx.se) 16.38.59 # re. sorry my connection is very slow and hangs from time to time :-/ 16.39.40 # TabalugaFX: Don't worry - see www.rockbox.org/irc for logs to see if you missed anything 16.39.51 # * S_a_i_n_t wonders why there is a blank line between each setting. 16.40.11 # thanks. yes they only mentioned the dual boot feature 16.42.35 # This is getting weirder and weirder... 16.43.23 # gevaerts: You can reproduce? 16.44.02 # I installed CenterArt2 on a fresh 3.5.1 install, and started playing an album from the database. The WPS shows that it's playing track 4 in that album. I then switch to cabbiev2, and suddenly the WPS shows track 1 16.44.16 # * gevaerts decides to go and get some earbuds 16.45.19 # told ya 16.46.40 # @ gevaerts. ckeck (id3) tags, perhaps an *corrupted* vaule inside, or id3v1 = tack numb 4, id3v2 = track numb 1 ? or something inside the wps cfg 16.47.27 # TabalugaFX: this happens on every track I play 16.47.40 # I think it's more like the difference between the database entry and the file list entry 16.47.43 Join Eugenpaul [0] (~ugnpaul@215.193.32.95.dsl-dynamic.vsi.ru) 16.47.50 # @ gevarts or try an "updated" rockbox version 16.47.53 # and update database again 16.47.57 Part Eugenpaul 16.48.00 # TabalugaFX: gevaerts is a core developer :) 16.48.01 # TabalugaFX: I'm trying to isolate a bug here... 16.48.10 # And he is trying to help yorick with a bug 16.48.12 # or sorry, i don't know 16.48.13 # gah, battery dead again... 16.48.24 # gevaerts: connect charger? 16.48.34 # yorick: it's connected... 16.48.42 # :/ 16.48.57 # open it up and short out some diodes :P 16.49.09 # yeah, that'll help. 16.49.13 # ;P 16.50.20 Join toffe82 [0] (~chatzilla@12.169.218.14) 16.50.32 # Anyway, since I can reproduce it with 3.5.1, let's try a current build next 16.51.25 # but how come there are no bug reports on it 16.51.52 # * gevaerts decides to apply FS#8802 for this build 16.52.11 # hello! 16.52.16 # hello 16.52.52 # I've made some personnal modifications to rockbox : 16.52.52 # * I've set-up the BUTTON_REC of my sansa's keymap to ACTION_FM_RECORD 16.52.52 # * I've set radio.c to launch recording screen with mic as input source when ACTION_FM_RECORD is pressed 16.52.52 DBUG Enqueued KICK paulk_ 16.52.52 # * I've made some minor modifications to francais.lang 16.52.52 # I think that someone could be interested by those changes, so can I upload them to svn ? 16.53.17 # no, as you don't have access 16.53.25 # paulk_: no, but you can upload patches to our tracker 16.53.25 # You could put a patch on flyspray though 16.53.40 # And since there is now HOTKEY which can already do this...I doubt it even further. 16.53.44 # paulk_: I don't think we're interested in the 2nd one 16.54.16 # paulk_: Maybe you should e-mail the dev mailing list and see what people think 16.54.32 # gevaerts: FS#8802 works here 16.54.40 # next question: what does the battery time (menu settings > rockbox info) behind the precentage means 16.55.09 # is this the "remaning" battery time? 16.55.25 # not with mic as input source but with radio as input source : 16.55.38 # Ok, I'll probably do a patch :) 16.55.48 # TabalugaFX: yes 16.56.10 # paulk_: don't make one patch for all of those, unless you want to make sure it's rejected... 16.56.51 # @alexP: but my battery only have a limit of 8 hours (already make an battery bench and read out the txt file) and a value of 104h 57m is shown here 16.57.02 # That means it hasn't been calibrated 16.57.15 # A stupidly high value is shown to make it clear that it is wrong 16.57.30 # No : one patch for francais.lang and one for radio.c/keymap 16.57.57 # In recent builds I *think* it shows 0 or something like that if it hasn't been calibrated 16.58.02 # ah, now i understand. and how can i calibrate it 16.58.12 # What player? 16.58.26 # iriver h10 6gb ums 16.58.40 # We need a series of battery bench marks to get an idea of the discharge curve, then a developer can apply it and newer builds will use it 16.59.00 # i can submit mine if you want 16.59.42 # TabalugaFX: See http://www.rockbox.org/wiki/BatteryRuntime 17.00.09 # for the conditions to do one, and then yes if you could submit one that would be helpful :) 17.00.56 # Ok, the bug is still there in trunk, and it doesn't depend on the database (and CenterArt is half-broken on the current build, *and* I hate touchwheels...) 17.00.59 # It should be with reset settings too, to make sure things like the EQ are off 17.02.13 # i already have done this bench with the listed conditions (charging up, repeating playback, don't touch it while playing, writing down end time) 17.02.20 # cool 17.02.29 # That'd be useful then 17.02.49 *** Saving seen data "./dancer.seen" 17.02.51 # Could you attach it to http://www.rockbox.org/wiki/IriverRuntime 17.03.00 # ok 17.05.12 Quit grndslm (Ping timeout: 276 seconds) 17.06.42 Join grndslm [0] (~grndslm@174-126-14-4.cpe.cableone.net) 17.08.43 Join funman [0] (~fun@rockbox/developer/funman) 17.09.21 # yorick: my impression is that it only goes wrong if you switch to CenterArt after booting, i.e. if it was already loaded on boot it's fine. Does that match what you're seeing? 17.10.08 # @alexp: sorry i can't sttach my battery bench cause "access denied" 17.10.16 # funman: ping 17.10.20 # pong 17.10.25 # pung 17.10.26 # we have 1MB iram right? 17.10.52 # right, i only tested on Clip+ though 17.10.54 # (on as3525v2) 17.10.56 # TabalugaFX: You need to ask in here for write access after registering 17.11.19 # What is your wiki name? 17.11.27 # SvenManfredKuhne 17.11.43 # Clipv2/Clip+ are quite unstable now, we should try changing pclk/fclk by small steps so pclk doesn't go too low 17.11.48 # gevaerts: no 17.12.27 # i'm running a bit with boost forced (so there's no switching) to see if it improves (I only saw a stkov ata/sd on Clip+ with this) 17.12.43 # TabalugaFX: You should be able to now 17.12.45 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 17.12.45 # * yorick reboots 17.12.55 # ok, thanks, i'll try again 17.13.00 # funman: We're running PCLK at 24 MHz for clip+/v2 and 60 MHz for fuzev2 <----is this correct? 17.13.11 # yep 17.13.12 Join Eugenpaul [0] (~ugnpaul@215.193.32.95.dsl-dynamic.vsi.ru) 17.13.26 # although it's not exactly 24MHz when we switch frequency 17.13.38 # gevaerts: nope, untrue 17.13.50 # btw, my fuzev2 shows 240MHz after boot even if unboosted 17.13.54 Part Eugenpaul 17.13.56 # yorick: ok 17.13.58 # yeah i didn't modify debug menu 17.14.14 # test_fps also assumes 240MHz 17.14.30 # I just modified debug page and will commit it soon 17.14.48 # funman: I think I verified 1MB on my fuzev2 (by modifying test_mem a tad bit) 17.15.06 # gevaerts: hmm...it just switched mid-track after switching theme 17.15.19 # yorick: yes, I've seen that too 17.15.22 # at least (512k-65k)*2 fits into the plugin iram. 0x20000 bytes is for the core 17.15.35 # both together is pretty much 1MB 17.15.48 # which is faster: iram or dram? 17.15.49 # and i don't get a crash or something 17.15.59 # @ alexp: ok, ive attached it 17.16.06 # iram is a bit faster, not so much when unboosted but about 50% when boosted 17.16.37 # funman: my idea was to move the entire codec buffer into iram. the current one is 1MB but it's in dram 17.17.00 # TabalugaFX: Thanks, hopefully someone will have a look 17.17.10 # maybe saratoga shares his test_mem changes for more accurate numbers 17.17.25 # yes this would be great 17.17.51 # we could probably still reserve 128kB or so for the core, 1MB is hardly needed for codecs 17.18.08 # btw is there a way i can calibrate it mysel to show the right remaining time 17.18.18 # kugel: i think the core+plugins don't even need 128kb 17.18.41 # plugins share codec iram 17.19.16 # the core iram is hardly used on fuzev1 indeed the biggest blob is the framebuffer, but then there only like 6k used additionally 17.19.33 Join Eugenpaul [0] (~ugnpaul@215.193.32.95.dsl-dynamic.vsi.ru) 17.19.44 # and when my rockbox voice tell me "battery level 50%" is this the right time / value instead) 17.19.50 # (I always meant to fill the rest with the dma buffer of the sd driver to free some dram and speed up) 17.20.29 # TabalugaFX: You would have to edit one of the source files then recompile 17.20.40 # FlynDice: nothing in the SD driver depends on pclk ? 17.21.14 # phew. this would be my 1st rockbox cimpiling steps. but i'll try it 17.21.34 # It isn't too bad really :) 17.21.41 # btw you need to update your doom wad file archive, cause a new freedoom version is out there 17.22.00 # and if i have time i want tu update your icons archive 17.22.02 # Does it work properly on Rockbox? 17.22.14 # Which icons archive? 17.22.16 # cause some of them won't work right 17.22.19 # funman: I also did a test_codec run, 60MHz looks like a big waste. do we have a choice for something between 24 and 60 (although 24 seems ideal) 17.22.38 # New commit by 03funman (r25485): as3525v2: show the correct freqs in debug menu, CGU_PERI uses fclk as source 17.22.40 # extras > icon setgallery 17.22.40 # the most common codecs (mp3, ogg, wma) nee about 20-25MHz 17.22.43 # The gallery? 17.22.50 # Yeah, that is user contributed anyway 17.22.51 # yes 17.23.10 # kugel: check if display is fast enough, I didn't tested after switching to RGB565SWAPPED pixel format 17.23.21 # funman: It seems to be so, I think that CGU_MS goes to the sd controller bus interface and CGU_SDSLOT goes to the controller card interface and we need CGU_IDE but I'm not sure exactly why.. 17.23.39 # TabalugaFX: the icons thing is a known bug. 17.23.44 # perhaps there's 1 clock for the controller and 1 clock for the card ? 17.23.44 # I found it a while ago. 17.23.48 # funman: I actually meant that the CPU frequency debug menu shows 240MHz 17.23.49 # 1 for each card rather 17.23.54 # S_a_i_n_t: Is it on flyspray? 17.23.58 # no, you only need to adjust the cfg files right 17.23.59 # yep 17.24.09 # goody :) 17.24.27 # Viewer icons apply incorrectly (or similar) 17.24.28 # kugel: ah i've seen that too 17.24.41 # cause afer that i can use all of them (expect the larger ones look very large for my small display) 17.24.43 # dont remember the FS# offhand sorry 17.24.45 # if i press right it shows a good value 17.24.46 # sansafuze.h still defines CPU_FREQ to 240MHz if that matters 17.24.56 # sometimes 17.25.05 # yes you need to crate *.icons file 17.25.13 # and all goes right 17.25.24 # TabalugaFX: even then, some just *don't* show 17.25.32 # really? 17.25.40 # trust me...my icons file has ~250 filetypes ;) 17.25.44 # whoa 17.25.50 # please share with us 17.25.51 # hehe 17.25.58 # but why so many 17.26.03 # or much 17.26.34 # its inside the "Symmetry" theme for iPod Nano 1/2g...but you probably won't like it as it only points to 1 icon 17.26.39 # (goes with the theme) 17.27.00 # ok i'l take a look inside 17.27.23 # nxt theme i want to "remake" is the pen&paper for h10 17.27.26 # you could easlily edit it to point to whichever icon you want though. 17.27.43 # *icon(s) 17.28.35 # ok thanks for the details. btw why the transparency vaule won't work for some icons 17.29.01 # just displays a black square? 17.29.15 # funman: hm, not unbearable slow anymore but still noticeably slower (and no fun). it would be great if we could go for something between 30 and 40 MHz I think 17.29.31 # 36 or 48? 17.29.38 # had some troubles with the tango s/w icons which shows the icons but not the transparency background so i saw the icon inside a white box 17.30.01 # s/w? 17.30.03 # hm no 17.30.12 Join efgpinto [0] (~ei07061@aulas-i-p2.fe.up.pt) 17.30.21 # 30, 34.29, 40 17.30.22 Nick YPSY is now known as Ypsy (~ypsy@geekpadawan.de) 17.30.24 # funman: 36 would work nice I think. the fps should at least be above 50 imo 17.30.28 # sorry i mean black & white for (s/w) )and not the background. so I reated my own tago greyscae icons 17.30.58 # black & white has no transparency IIRC 17.31.27 # you might reconsider the highest frequency used in ams v2 players too, the audio playback rate is now more than 1% off 17.31.36 # kugel: it must be a fraction of 240 (down to 240/16 == 15MHz) 17.31.48 # bertrik: we don't know how to change the PLL freq 17.32.25 # but the rockbox default icons are black&white and transparency works here 17.32.45 # funman: does clock target handle fractional frequencies? 17.33.05 Quit pamaury (Quit: Page closed) 17.33.08 # yes but they're reduced to integer 17.33.36 Join fabioalmeida [0] (~ei07081@aulas-i-p2.fe.up.pt) 17.33.36 Quit efgpinto (Read error: Connection reset by peer) 17.33.40 # how can I double check the divider that's calulated? 17.33.49 # disasm 17.34.12 # there's no #define for it? 17.34.33 # you can look on the debug page if you can boot it ok 17.34.36 # TabalugaFX: the "mono" icons are for non-colour targets, which (AFAIK) don;t support transparency...but I haven't played around much as I only have colour targets. 17.35.21 Quit fabioalmeida (Quit: Ex-Chat) 17.35.25 # ok, so i need to change the mono icons to color and set the transparency value by myself 17.35.45 # that seems sane, so yes, probably. 17.35.45 Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) 17.36.25 # hm 24MHz is just not enough for mp3 :) 17.36.27 Join efgpinto [0] (~ei07061@aulas-i-p2.fe.up.pt) 17.36.32 # ok, than i have done this already inside my "simple theme grey" which includes my created tango greyscaled icons 17.37.05 # Well, I think the mono targets *do* have transparency, but the "magic" colour (the transparent colour, magenta in the colour targets) is a different value 17.37.19 # so, doesn't show as transparent on colour targets. 17.37.34 # 1-bit mono bitmaps use foreground and background colours on colour targets too 17.37.39 # 34285715 seems to work 17.38.33 # hmm the matrix effect is a bit silly here 17.38.41 # it's moving on the beat of the music 17.39.01 # this works on greyscale too (in the WPS where you can have different foreground and background shades with viewports 17.39.12 # ) 17.39.23 # funman: I think I could live ok with 34.3MHz, let me try 40 too 17.39.42 # I knew a non-colour target themer would chime in eventually ;) 17.39.55 # kugel: the e200v1 framerate is awfully fast at 24MHz :( 17.40.08 # so is it possilbe to make a theme with wto ore more colors (e.g. red, green, blue and so on) and package all into one "theme" 17.40.09 # that's because the e200v1 cheats 17.40.17 # oh? 17.40.30 # S_a_i_n_t: what? I use this in my c200 WPS too 17.40.41 # it memcpy's the framebuffer to another one where the lcd driver auto-reloads from automagically 17.41.07 # pixelma: yes, but you also understand how the mono targets work better than I ;) 17.41.30 # TabalugaFX: Not yet 17.41.39 Join Kitr88 [0] (~Kitr88@BSN-142-95-35.dial-up.dsl.siol.net) 17.42.56 # this would be great 1st: select your theme; 2nd: select your color; 3rd: select / edit your custom color 17.43.13 Join lImbus [0] (~lImbus@port-92-204-9-62.dynamic.qsc.de) 17.43.22 Join fabioalmeida [0] (~ei07081@aulas-i-p2.fe.up.pt) 17.43.43 # TabalugaFX: It is in the vague "It'd be nice to have multi-colour packs when someone gets round to doing it" area 17.44.04 Quit Kitar|st (Ping timeout: 264 seconds) 17.44.23 Join Kitar|st [0] (Kitr88@BSN-182-22-143.dial-up.dsl.siol.net) 17.44.33 # yorick: I've submitted bug FS#11175 (http://www.rockbox.org/tracker/task/11175) about this. If you find out more, feel free to add notes 17.45.20 # funman: ok, with 40MHz I cannot really tell the difference between boosted and unboosted (UI-responsiveness wise). fps is improved by 20% over 34.MHz (51 vs 60) 17.45.35 # oh great, than I'll see what the future brings. curently i've created the "iamp h10 remakes" both in normal and inverted colors, cause my friends say the night mode look great too and i can't devide which one i sould submit, so i submitted both 17.45.54 Quit Kitr88 (Ping timeout: 240 seconds) 17.45.55 # nice 17.46.14 # while the clock speed is only increased by 16.6% 17.46.36 # gevaerts: low? 17.46.39 # disabling switching doesn't crash (at least less quickly), but i'm not sure how to switch nicely 17.46.52 # gevaerts: that makes my favourite theme unusable :p 17.47.04 # maybe you checkout the frequencies too, I'd almost vote for 40MHz, but I wouldn't die with 34.3 17.47.08 # the OF crudely iterates over dividers to keep pclk very approximately close to the desired value as fclk changes 17.47.14 # New commit by 03amiconn (r25486): Improve SDL detection, so that path order doesn't matter if both native SDL and cross-mingw32 SDL are present. Reduce code duplication as well. 17.47.21 # yorick: well, I left those at the default values. People tend to ignore them anyway 17.47.54 # gevaerts: tend :p 17.47.59 # funman, I suppose they first reduce the pclk, then increase fclk, right? 17.48.11 # I'd say 34.3 feels about the same as unboosted on a e200v1 ui-wise 17.49.42 # bertrik: http://forums.rockbox.org/index.php?topic=14064.msg163547#msg163547 < they modify both in a loop 17.50.00 # yorick: well, have a look at the tracker and you'll notice that we only have two bugs that are not severity: low 17.50.01 # in this function they are boosting 17.51.01 Quit jd (Ping timeout: 265 seconds) 17.51.18 # yorick: Even if they were used, a particular theme not working is low anyway in my book :) 17.51.18 Part lImbus 17.51.21 # ok, now i need to say goodbye. thanks again for the great support, technical help and the answer of my questions and ideas. and thanks for your vision and your development of my beloved opensource firmware which rocks through my ears every day (and during some sleepless nights) 17.51.32 # Heh, you are welcome :) 17.51.55 # and sure, I'll help where can 17.51.56 # cya TabalugaFX 17.52.09 # AlexP: it's probably some feature the theme uses 17.52.13 # to support and promote 17.52.20 # bye 17.52.26 # ...logging off.. 17.52.38 Quit TabalugaFX (Quit: CGI:IRC) 17.52.45 # funman: what do you think about my codec buffer idea? 17.52.46 # yorick: Yeah, but it still isn't critical or high, like playback not working 17.53.13 # kugel: sounds good if the iram is not too much slower, we'd use memory effeciently that way 17.53.13 Join jd [0] (~jd@modemcable207.134-202-24.mc.videotron.ca) 17.53.13 Quit jd (Changing host) 17.53.13 Join jd [0] (~jd@Wikipedia/HellDragon) 17.53.25 # it's faster :p 17.53.37 # As long as rockbox_defalut loads, music plays, and plugins work...all is well with the world ;D 17.53.37 # but really only when boosted it seems 17.53.50 Quit Xerion (Read error: Connection reset by peer) 17.54.03 # AlexP: I consider the fact that this bug is even possible to be a bit frightening though 17.54.23 # we should also decrease the pcm buf size, 90% of it unused 17.54.29 Quit jd (Read error: Connection reset by peer) 17.54.38 # kugel: try with ape first 17.54.39 # gevaerts: very true...looking at the code its VERy hard to pick what the heck is going on there. 17.54.41 # It is all academic anyway as we don't use the rating thing 17.55.24 # (code for the theme that is) 17.55.42 # funman: nobody uses ape... 17.55.49 # clip+ is getting random freezup for everyone and not just me correct? 17.56.14 # FlynDice: yep, keeping it boosted (or unboosted but you need to patch) should work around it 17.56.24 # kugel: perhaps but we still support it 17.56.37 # funman: smaller pcm buffer doesn't mean ape will not work 17.57.00 # I'm testing some delays after changing the divs and so far so good but I'm only at 10 mins or s 17.57.08 # just that it *maybe* boosts more often which is the case with ape anyway 17.57.14 # * FlynDice keeps fingers crossed 17.57.21 # depends if filling it takes more time than what's available in the buffer 17.57.58 # ape data aborts apparently 17.58.17 # FlynDice: i think either we need to add a delay, either pclk goes too low for some peripheral even if we're not using it at the moment we switch (pclk goes to 2.4MHz) 17.58.28 Join jd [0] (~jd@modemcable207.134-202-24.mc.videotron.ca) 17.58.28 Quit jd (Changing host) 17.58.28 Join jd [0] (~jd@Wikipedia/HellDragon) 17.59.25 # I'm going to let it play for awhile here but it's doing well so far with an i=40 delay similar to OF 17.59.59 Quit yorick (Quit: Poef!...) 18.00.13 Join lImbus_ [0] (~lImbus@port-92-204-119-1.dynamic.qsc.de) 18.00.51 Nick lImbus_ is now known as lImbus (~lImbus@port-92-204-119-1.dynamic.qsc.de) 18.01.22 # funman: should I commit the 40MHz or do you want to wait and see yourself? 18.01.37 Quit xiainx (Ping timeout: 252 seconds) 18.01.58 # just commit 18.03.13 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 18.03.22 Join yorick [0] (~yorick@s55924da0.adsl.wanadoo.nl) 18.03.32 # battery 95% 195h 0m 18.03.43 # hmm 18.03.55 # I think it's supposed to be charging 18.04.01 # it was 96% just then 18.04.09 Part lImbus 18.04.10 # and the charger icon is showing 18.04.57 Join komputes [0] (~komputes@ubuntu/member/komputes) 18.05.10 # crap, just froze :( Seems to be an SD access issue as the LED icon is illuminated 18.05.19 # yorick: Is there a question in there? 18.05.21 # grmbl 18.05.37 # S_a_i_n_t: how do I fix the 195h 18.05.51 # its nothing you can "fix" 18.06.03 # submit a battery bench using the criteria on the wiki 18.06.03 # with 24/240MHz we can switch while staying between 13.3MHz and 30MHz 18.06.20 # any reason we use the DRAM_FREQ for defining the cpu freq? 18.06.22 # it will help toward calibrating the battery for your player. 18.06.56 # kugel: we use PCLK (which is equal to DRAM_FREQ, unless you set bit 6 of CGU_PERI on amsv1) 18.07.41 # New commit by 03amiconn (r25487): Set options so that the sim actually builds on Opensolaris. The build still throws hundreds of warnings. 18.07.46 # back later.. 18.09.41 # at best it's only 10 times too much 18.09.49 # New commit by 03kugel (r25488): Add T for plugins to the advanced build options to build all test_* plugins. 18.09.53 # New commit by 03kugel (r25489): Fuzev2: Use 40MHz as unboosted frequency. The lcd speed and ui responsiveness is good at this freq. 18.11.51 # New commit by 03kugel (r25490): Correct comment. 18.12.40 Join xiainx [0] (~iain@socs-7.CS.McGill.CA) 18.19.29 Join lImbus [0] (~lImbus@port-92-204-119-1.dynamic.qsc.de) 18.20.07 Part lImbus 18.20.39 # FlynDice: i'm testing http://pastie.org/903960 on Clip+ 18.21.55 # kugel: Shouldn't more of those test plugins have #ifdefs around them in SOURCES? e.g. SWCODEC for test_codec, HAVE_ADJUSTABLE_CPU_FREQ for test_boost. 18.22.22 # hrm, probably 18.22.43 # I didn't go through all possible combinations and I may have forgotten something 18.23.05 # i suppose the peripherals running off pclk are DMA and i2c 18.23.24 # dbop 18.23.45 # ssp 18.24.02 # but for dbop & ssp it shouldn't matter 18.25.20 # i don't see clock requirements for dma 18.25.44 # I often thought it would be nice to have multiple boost levels 18.26.26 # kugel: Also, s/unbearable/unbearably/ (but I wouldn't use subjective words like that in comments - what is unbearable to one person may be bearable to others.) 18.26.34 # i2c runs at 400kHz and iirc the requirements is "between 100 & 400" so we should let pclk only go lower (up to 4 times lower), not higher 18.26.47 Join flydutch [0] (~flydutch@host225-165-dynamic.15-87-r.retail.telecomitalia.it) 18.27.41 # * S_a_i_n_t thinks multiple screen refresh rates for different targets that don't mess with the scrolling speed in lists would be nice also... 18.27.42 # bertrik: saratoga suggested the same thing 18.27.47 # 400kHz is already i2c "fast mode" 18.27.57 # amiconn: yes so we shouldn't go faster 18.28.01 # Standard mode is <= 100kHz. Afaik there is no lower limit 18.28.07 # ah 18.28.24 # But basically all i2c devices support fast mode nowadays 18.28.50 # as3525 datasheet quotes "supports standard (100 kbps) and fast speed (400kbps)" 18.28.55 # There's one notable exception among the rockbox targets: The m3's button controller (a pic) doesn't 18.29.05 # It also has a rather buggy i2c implementation 18.30.39 Quit TheSeven (Ping timeout: 265 seconds) 18.30.56 Join tomers [0] (~chatzilla@bzq-84-109-85-100.red.bezeqint.net) 18.32.35 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 18.33.20 # funman: do you expect the crashes to go away with http://pastie.org/903960? 18.33.49 # nope it's buggy (see above) 18.33.58 # pclk must not go higher than 24MHz 18.40.44 Join Antibuddha [0] (~chatzilla@c-71-59-19-167.hsd1.ga.comcast.net) 18.40.57 # how hard would it be to rockbox an mp3 player like cowon q5w? 18.41.18 # i just got one off ebay but im afraid it will be crap without rockbox 18.42.19 # not easy 18.42.21 # Well...its either a LOT of work, or you could hold your breath. Possibly indefinitely. 18.42.29 # ok 18.42.29 # Antibuddha - working from the assumption that all mp3 players are different, the answer would be 'as hard as all the other ports'. see the NewPorts page on the wiki if you are able to help! 18.42.59 # hmm forget that then, anyone know how to test if an spdif is resampled to 48khz? 18.43.15 # Antibuddha - (wiki link by the way is http://www.rockbox.org/wiki/NewPort) 18.43.27 # if my new cowon q5w can spdif rca output unresampled 44.1khz, i will be happy 18.44.07 Quit tomers (Quit: ChatZilla 0.9.86 [Firefox 3.5.8/20100214235838]) 18.50.25 Join phanboy4 [0] (~benji@c-174-49-112-244.hsd1.ga.comcast.net) 18.50.29 # Antibuddha - I personally don't know, but this is #rockbox, so it's possible you won't find your answer here .. 18.50.36 Join captainkewllllll [0] (~2669ecc2@gateway/web/freenode/x-wavbesbpygsqmcfc) 18.52.35 Quit paulk_ (Quit: Ciao) 18.52.54 Join Strife89 [0] (~michael@168.16.232.173) 18.55.01 # :o @ gapless playback in practice 18.55.15 # FlynDice: ThomasAH: http://pastie.org/904019 only 1 intermediate step and fixed the numerous bugs 18.56.00 Join TheSeven [0] (~theseven@rockbox/developer/TheSeven) 18.57.23 # we might even calculate the intermediate value with awful macros :) 18.59.49 # PANIC read multiple blocks failed (Clip+ µSD) 19.00.20 Quit stripwax (Quit: http://miranda-im.org) 19.00.50 Quit antil33t (Read error: Connection reset by peer) 19.00.55 Join antil33t [0] (~Mudkips@203-184-54-232.callplus.net.nz) 19.01.59 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 19.02.46 Quit geertvdijk (Ping timeout: 246 seconds) 19.02.53 *** Saving seen data "./dancer.seen" 19.06.15 # not sure why µSD is affected :( 19.07.22 Quit stoffel (Remote host closed the connection) 19.07.24 Join moos [0] (moos@rockbox/staff/moos) 19.08.23 Join Strife89|PalmTX [0] (~cstrife89@168.16.232.173) 19.08.28 # moos: is boot speed back to normal for you now? 19.09.20 # gevaerts: hi, didn't had the chance to test yet. I still have to fix my beast to do various set of tests :( 19.09.38 Quit scorche (Ping timeout: 240 seconds) 19.14.21 Join scorche [0] (~scorche@rockbox/administrator/scorche) 19.16.04 Quit Strife89|PalmTX (Quit: Leaving) 19.16.44 Join freddyb [0] (~44ee088d@giant.haxx.se) 19.20.16 Join freddyb_ [0] (~chatzilla@pool-68-238-8-141.chi.dsl-w.verizon.net) 19.21.46 Quit freddyb (Quit: CGI:IRC (Ping timeout)) 19.21.57 Nick freddyb_ is now known as freddyb (~chatzilla@pool-68-238-8-141.chi.dsl-w.verizon.net) 19.23.27 # Clipv2 still plays though 19.23.44 Quit Strife89 (Quit: Changing buildings.) 19.24.25 Join geertvdijk [0] (~chatzilla@cc412026-a.zwoll1.ov.home.nl) 19.24.46 # as3525 datasheet says "Clock gating takes effect immediately!" (for CGU_PERI though) 19.25.03 # hm but it refers to enabling/disabling individual peripherals 19.28.09 Part fabioalmeida 19.31.26 Join Strife89 [0] (~michael@168.16.237.214) 19.31.27 Quit grndslm (Ping timeout: 264 seconds) 19.32.56 # linux for as3525(v1) doesn't show any delay after modifying either CGU_PROC either CGU_PERI 19.35.11 # funman: is there a different datasheet for Sansa v2's? 19.35.21 # no 19.35.56 # hum well there is a datasheet for the Sansa *AMS* v1, not for the Sansa *AMS* v2 19.36.33 # AMS v1 were previously called "Sansa v2" so just to confirm, you're speaking about Clip+/Clipv2/Fuzev2 ? 19.37.32 # Yes, I have a Fuze v2 also and I was thinking about digging in to see if there's anything I could help finish up. 19.38.17 Quit phanboy4 (Read error: Connection reset by peer) 19.39.46 # FlynDice: ThomasAH http://pastie.org/904095 19.41.32 # freddyb: afaik they have an as3525 with modified CPU/peripheral clocks (i'm looking at it now), and the CPU, SD controller, USB controller, i2c (audio/PMU) registers; of an as353x; also a bit more IRAM (320kB -> 1MB) 19.42.33 # you could look at recording, it used to work (although there is not write support so you can store the records on disk) but I broke it with dynamic CPU freq switches 19.42.46 # you're already familiar with that :P 19.43.17 # Did you break it by loafing in the higher interrupts? :p 19.43.59 # I'll take a look. 19.44.36 # nope i'm not sure what happened 19.45.05 # i just looked on my fuzev2 and it seems to work.. (not using latest rev though) 19.45.39 # usually i would just stand in the menu and a push error come after 1 second 19.49.16 Quit CGL (Remote host closed the connection) 19.51.26 Quit TillW (Quit: This now concludes our broatcast day.) 19.56.44 # kugel: re r25489, if you want to change CPU_FREQ in config/*.h, fine, but do it for all targets and start CPU unboosted in system_init(). IMO you should rather revert it (did you grep for CPU_FREQ ?) 20.00.37 # funman: cpu_frequency is initialized to CPU_FREQ, that was the reason the debug menu showed the wrong frequency 20.00.49 Quit Antibuddha (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 20.01.10 Join hebz0rl [0] (~hebz0rl@dslb-088-065-209-116.pools.arcor-ip.net) 20.01.24 # something wrong with it? 20.03.52 Quit Horscht (Quit: Verlassend) 20.05.01 # hm ok 20.05.13 # yeah we initialize CPU to boosted 20.05.28 # iirc I had seen a call to set_cpu_frequency(CPUFREQ_NORMAL) in init() 20.06.05 Join Horscht [0] (~Horscht2@xbmc/user/horscht) 20.06.11 # well it's the first thing after system_init()/kernel_init() 20.06.59 # it can be reverted if it's wrong, I thought that causes the wrong freq to be displayed 20.07.47 # whatever you prefer, if it's in sync with system_init() and with other targets for consistency and 20.08.29 # btw AMSv1 still say 250MHz in their config file but debug menu is fine 20.09.30 # so mind = blown 20.09.35 # hehe 20.09.57 # I think it worked before your today's fix actually 20.10.39 # i had seen it yesterday iirc 20.10.48 # you meant r25475 ? 20.11.59 Join kadoban [0] (~mud@cpe-67-247-80-129.rochester.res.rr.com) 20.12.11 # yes 20.12.16 # but I don't know for sure 20.14.46 # works fine if I set CPU_FREQ to 240M and DRAM_FREQ to 40M (I have the last diff I pasted here applied though) 20.15.15 # ah .. but this diff uses freqs for Clips :o 20.15.17 Join wolfsmond [0] (~Miranda@ip-109-40-196-225.web.vodafone.de) 20.16.50 Join TillW [0] (~Till@nat028.dc-uoit.net) 20.18.19 # kugel: ok for http://pastie.org/904153 ? it shows 40MHz in the debug screen after boot 20.18.58 # that's simply reverting...why does it work for 40 but not for 60? 20.19.38 # s/unbearable/unbearably/ as linuxstb while you're at it :P 20.19.44 # already done :D 20.20.14 Quit n1s (Quit: Lämnar) 20.20.20 # hm indeed with 60 it doesn't work 20.20.33 Join hebz0rl_ [0] (~hebz0rl@dslb-088-067-205-067.pools.arcor-ip.net) 20.21.56 Quit hebz0rl (Ping timeout: 276 seconds) 20.22.55 Quit robin0800 (Remote host closed the connection) 20.28.53 Quit wolfsmond (Ping timeout: 240 seconds) 20.30.42 Quit TillW (Quit: This now concludes our broatcast day.) 20.30.44 Quit hebz0rl_ (Read error: Connection reset by peer) 20.34.15 # if i comment 1 or 2 cpu_boost() in main.c i see correct values 20.37.04 Part efgpinto 20.37.59 Quit flydutch (Quit: /* empty */) 20.38.50 Quit linuxstb (Ping timeout: 276 seconds) 20.40.05 # btw last patch looks fine, played 1 full album from µSD on Clip+ 20.42.00 Join mandred [0] (~mandred@cpc3-nmal16-2-0-cust408.croy.cable.virginmedia.com) 20.42.26 # mind = ultra blown. 60MHz freq is showed in the debug menu if i enable boost logging 20.42.49 # :p 20.42.59 # your mind is clearly suffering lately :) 20.43.12 # :P 20.43.24 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 20.43.59 Quit pamaury (Quit: Page closed) 20.45.46 # I'm confused, should I have to do anything special to get rockbox to boot on my clip+ just installed and it just boots to the OF. 20.46.14 # funman: codec buffer to iram patch: 1MB more audiobuffer 20.47.56 # mandred: you should just follow the steps on SansaAMS wiki page 20.47.57 # mandred: have you installe a bootloaer? 20.48.38 # I followed those in the clip+ manual, thye seemed to be the same. 20.49.33 # bootloader being the clippa.bin renamed from patched.bin? 20.49.55 # clppa, not clIppa 20.50.31 # Aha, my mistake. Thank you. 20.51.15 # Ah actually doing the firmware upgrade now. Thanks. 20.53.03 # if I remove set_cpu_frequency() call from init() -> correct value again 20.53.59 # mind totally blown 20.54.27 Join saratoga [0] (~9803c6dd@gateway/web/freenode/x-bngjvwnqvufqbmxn) 20.55.48 Quit saratoga (Changing host) 20.55.48 Join saratoga [0] (~9803c6dd@rockbox/developer/saratoga) 20.56.59 # does anyone know why the D2 doesn't seem to use IRAM? 20.57.31 Join christoffer [0] (~christoff@0x5da46d23.ojnqu1.dynamic.dsl.tele.dk) 20.57.55 # head asplode => bed 20.57.55 Quit christoffer (Client Quit) 20.57.57 Quit funman (Quit: free(random());) 20.58.42 # saratoga: what do you think is the approximate maximum codec buffer needed? the standard seems to be 1MB 20.59.32 Join stripwax__ [0] (~Miranda@87-194-34-169.bethere.co.uk) 20.59.33 # in practice 300KB on the clipv1 seems to play almost everything 20.59.43 # its just AAC and Vorbis that can use more then that, and very few files do 21.00.05 # are all codecs enabled on the clip? 21.00.19 # very old vorbis files can use more, but few exist, and very long AAC files due to our crummy MP4 parser 21.00.37 # yes they're all enabled, except maybe AAC-HE (can't remember if I disabled it) 21.01.18 # ah, all mem related #ifdefs from codecs/SOURCES are removed, I didn't notice 21.01.56 # we have plenty iram (1MB) on as3525v2, and I'm going move the entire codec buffer into it 21.02.08 # SBR and PS support are disabled on targets <= 2MB of RAM 21.02.17 # but it might be desirable to move some cores stuff into it as well 21.02.51 # once the AAC parser is fixed (cross fingers for GSOC 2010), they can be reenabled and the codec buffer shrunk to 512KB on all targetrs 21.02.57 *** Saving seen data "./dancer.seen" 21.02.58 # MP4 parser I mean 21.03.01 # the iram seems to be 50% faster when boosted, but the numbers come from the svn version of test_mem without your improvements 21.03.24 # playing with test_mem the results were inconsistent with my changes, so I'm not really sure what was going on 21.03.40 # it might have been a side effect of how pclk was set at the time (IIRC just 6 MHz unboosted) 21.03.57 # how inconsistent? 21.04.12 # funman: (in case you'll read the log:) I'll try http://pastie.org/904095 and report tomorrow 21.04.16 # i sometimes got a speed up with LDM and sometimes not, which didn't make sense to me 21.04.26 # since LDM shouldn't really be faster on ARM9 21.04.42 # FWIW unrolling the load loop gave a 4% speedup 21.04.51 # mostly just due to reduced loop overhead, gcc nonsense 21.04.58 # I thought ldm is 2+n cycles on arm9 (and ldr always 2)? 21.05.12 # ldr is a single cycle if its not used on the next clock IIRC 21.05.33 # and LDM is a single cycle per address for N>1 and N not used on the next cycle 21.05.52 # LDR 1 1S 1N Normal case, not loading PC. 21.05.59 # so 1 cycle for the normal case 21.06.13 # LDM n 1S+(n-1)I 1N+(n-1)S Loading n registers, n > 1, not loading the PC. 21.06.56 # well, the cycle numbers are really only meaningful if the ram isn't too slow aren't they? 21.07.04 # yeah 21.07.05 # otherwise, test_mem would be pretty useless 21.07.13 # but test_mem mostly just tests the cache 21.07.18 # which should be 0 cycle 21.07.26 # well, that's intended 21.07.41 # so mostly what you see is how well pipelined the loads are 21.07.42 Quit dfkt (Read error: Connection reset by peer) 21.07.46 # it shouldn't give the raw speed but what you can expect in the normal usecase 21.07.55 Join stripwax_ [0] (~Miranda@87-194-34-169.bethere.co.uk) 21.08.02 Join dfkt [0] (dfkt@unaffiliated/dfkt) 21.08.24 # it tests some combination of pipelining and how quickly the memory can handle cache line refills 21.08.31 # I thought about disabling the caches but then the numbers aren't helpful anyway 21.08.43 # a random stride would give you memory access performance 21.09.03 # cache lines are 32 bytes, so if you step 32 bytes at a time you'll get memory everytime 21.09.13 # (on almost all our arm tagets) 21.09.22 Quit stripwax (Ping timeout: 248 seconds) 21.10.20 # I was inspecting why lcd update was so slow, and there sequential reads cound 21.10.40 # but I'm sure we could improve it further 21.12.01 # saratoga: we never had a report that a file can't be played on the clip did we? 21.13.05 # not that I know of 21.13.21 # but I think clip owners probably don't use many exotic files verses some other players 21.13.34 # there are certainly ones that do not play 21.13.46 # any AAC file over about 5-10 minutes should fail 21.13.56 # but i guess no one uses AAC anyway 21.14.11 # saratoga: The SoC page doesn't mention improviing the MP4 parser (but it's a good idea). 21.14.18 # yes we can add that later 21.14.23 # it should be quite simple I think 21.14.24 Quit merbanan (Read error: Operation timed out) 21.14.41 # i had a hack that did it for all my files ages ago, but lear was skeptical it would work for weirder files 21.15.08 # basically i just downsampled the seek table and assumed that chunks were stored sequentially in the mp4 stream 21.15.27 # it seemed to work but Mp4 is so needlessly complicated I have no idea if that was a valid assumption for all files 21.16.18 # and I've never managed to get a copy of the spec 21.16.28 # i have like every mpeg document ever but not the mp4 one 21.16.36 # because that is the only one the mpeg people decided to hold secret 21.16.53 # because I guess making sure that no software supports MP4 correctly is in their best interest? 21.18.18 # New commit by 03kugel (r25491): as3525v2: Move codec into iram freeing 1MB for the audio buffer and also a small decoding speedup (iram seems to be 50% faster than dram when boosted ... 21.20.38 # i wonder if the IRAM speed up on amsv2 is due to actual changes in the IRAM, or just that the ARM9E has a low latency higher bandwidth tightly coupled memory interface built right into the CPU 21.21.01 # New commit by 03kugel (r25492): Revert part of r25489 as it didn't fix the problem, that the CPU frequency debug screen shows the wrong frequency after boot, properly. 21.21.15 # funman: r25490 + pastie/904095 + voice menus enabled freezes somewhere between using it for one second and one minute 21.23.25 # Recording on Fuzev2 is much improved by shortening the delays in button-fuzev2.c 21.23.57 # It's gone a few minutes at 44100 now. (I also used gcc -O2, tho.) 21.24.37 # you used what? 21.24.48 # freddyb: but the delays probably need to be increased, the lcd is glitchy when boosted atm 21.25.52 # Should the delays be based on the CPU HZ? 21.27.00 # they should be independant of the cpu ideally 21.27.58 # Saratoga: Me? 21.28.32 # yeah what did you compile with O2? 21.28.52 # The whole thing except the boot loader. 21.29.35 # Well, I change GCC_OPTS in the builddir Makefile 21.32.40 Quit Eugenpaul (Quit: Eugenpaul) 21.38.03 Quit mandred (Quit: leaving) 21.41.49 Join kugel_ [0] (~kugel@e178113056.adsl.alicedsl.de) 21.42.05 Quit kugel (Disconnected by services) 21.42.09 Nick kugel_ is now known as kugel (~kugel@e178113056.adsl.alicedsl.de) 21.42.13 Quit kugel (Changing host) 21.42.13 Join kugel [0] (~kugel@rockbox/developer/kugel) 21.44.38 # Kugel: Sorry if this is a dumb question but can button reading be made interruptible by the audio? 21.44.55 # what do you mean? 21.45.25 # Buttons are read in an interrupt that is higher than the audio stuff, right? 21.46.49 Quit TheSeven (Disconnected by services) 21.47.02 Join The_Seven [0] (~theseven@rockbox/developer/TheSeven) 21.47.12 Nick The_Seven is now known as TheSeven (~theseven@rockbox/developer/TheSeven) 21.47.26 # freddyb: no 21.47.59 # all interrupts have the same priority; except the pcm callback which is an fiq and has higher prio. I don't know if that's used by recording 21.48.40 # freddyb: the individual makefiles specify the gcc level, i don't know if you should change those 21.49.08 Join JohannesSM64 [0] (~johannes@cm-84.215.116.196.getinternet.no) 21.50.12 Join perfectdrug [0] (~marko@80.187.149.62) 21.51.35 # wodz: (logs) I finally added the SVG for the MPIO HD200 for the manual, the rest follows: http://www.rockbox.org/tracker/task/11177 21.52.33 Join mitk [0] (~mitk@chello089078013146.chello.pl) 21.58.53 # New commit by 03mcuelenaere (r25493): Add simple bootchart -> gnuplot shell script 22.00.44 Quit Strife89 (Quit: Going home.) 22.00.52 Join froggyman [0] (~me@unaffiliated/froggyman) 22.01.38 Quit n17ikh (Ping timeout: 245 seconds) 22.05.10 Quit perfectdrug (Quit: Leaving.) 22.06.48 # with FS#11101 installed I get "/cygdrive/c/Cygwin/Rockbox_Source/patched/firmware/usb.c:60: warning: ‘reverse_usb_handling’ defined but not used" does this actually *mean* anything? 22.06.56 # (the bootloader seems to work fine) 22.07.30 # Oh, when building a bootloader of course...*duh* 22.07.35 # well of course. It means that reverse_usb_handling is defined but not used 22.07.55 Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) 22.07.57 # does it mean anything *bad*? 22.09.12 # I mean, I assume there are more than just this one option that are defined, but not implemented as default...but none of the other complain about the fact. 22.09.44 Quit stripwax__ (Read error: Connection reset by peer) 22.09.44 # this is what #ifdef is for 22.09.57 # So, its just shit code? 22.10.26 # ? 22.11.01 # Misinterpreted you there I think...basically, *why* is it complaining? 22.11.26 # It still seems to work, but has a cry about building the bootloader. 22.13.09 # It's complaining because reverse_usb_handling is defined but not used. Seems clear enough to me... 22.13.38 Quit bmbl (Quit: Bye!) 22.16.18 # gevaerts: but it *is* used, it just isn't enabled by default. As are a few other things I'd imagine, that don;t complain about it. 22.16.33 # It's *not* used by the bootloader 22.16.37 Join sierra2kilo [0] (~4cab2b3f@giant.haxx.se) 22.16.44 # (on systems without bootloader usb) 22.17.00 # Well, probably even on those 22.17.18 # Hey all. Got a quick question about the unstable firmware for the clipv2. 22.19.19 # I've tried both the archive and current versions, and every time I get a checksum that's just slightly off. No idea why. 22.19.32 Quit yorick (Quit: Poef!) 22.19.49 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 22.20.41 Quit mikroflops (Ping timeout: 265 seconds) 22.21.04 Join mikroflops [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) 22.21.07 # domonoky: you know about the theme site, right? The admin bit seems to have some issues 22.21.21 # sierra2kilo: which checksum precisely? 22.21.52 # gevaerts: yes, i know a bit about the themesite. what is the problem with the admin thing ? 22.22.15 # domonoky: I always seem to get all themes instead of only those for the player I want, and I can't hide a theme 22.22.32 # gevaerts: On this last install it wants 2A54079 and I got 2A5408D 22.22.42 # sierra2kilo: "it" being what? 22.23.38 # When it's loading the firmware and it says "Checksum" and then "Sum". 22.24.33 Quit xiainx (Quit: Leaving) 22.25.10 # sierra2kilo: did you install the right firmware? I think this might be something you get if you e.g. install a clip firmware on a clipv2 22.25.19 # uh, something broke, it shouldnt show all themes. the "not able to change theme status" is known, if there are too many themes displayed, i suspect we just have too much data for the POST 22.25.53 Quit geertvdijk (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 22.25.55 # you can hide the theme if you search for it first (so it only displays a small amout of themes) 22.27.50 # Thanks. That works 22.28.11 # gevaerts: I did, the clipv2 file. 22.29.29 # sierra2kilo: you have a clipv2 and not a clip+? 22.31.54 # Correct 22.34.11 # What does the bootloader print after "Model name:"? 22.40.14 # Weird. Copied over the .rockbox folder manually and it worked. Crisis averted! 22.41.59 # Thanks for the help. Not sure why the rbutilqt method didn't work, but I'm just glad my FLAC is now lusciously gapless. 22.42.31 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 22.42.36 Nick Ypsy is now known as YPSY (~ypsy@geekpadawan.de) 22.45.20 Quit sierra2kilo (Quit: CGI:IRC (EOF)) 22.46.57 Join Blue_Dude [0] (~chatzilla@adsl-235-206-131.mco.bellsouth.net) 22.50.58 Quit lpereira (Quit: Leaving.) 22.53.07 # New commit by 03Blue_Dude (r25494): Restructure some bookmarking code, preparatory to adding version info to bookmarks. Saves some bin size as a bonus. No functional changes yet. 22.53.23 # saratoga - my timings of the old rockbox mdct_arm.S versus stock tremor versus mdctexp-patched tremor was a bit bogus. I had said that old mdct_arm.S versus stock tremor had no improvement, but I'm pretty certain I had a broken build. rerunning now. 22.55.08 Join drostie [0] (~marathon@5ED17066.cable.ziggo.nl) 22.55.27 Quit mitk (Quit: Leaving) 22.57.46 Join b1uebrother [0] (~dom@92.116.214.236) 22.58.20 Quit b1uebrother (Changing host) 22.58.20 Join b1uebrother [0] (~dom@rockbox/developer/bluebrother) 23.00.08 # freddyb: maybe you can find out which delays are too long? 23.02.58 *** Saving seen data "./dancer.seen" 23.03.00 Quit Status () 23.04.40 Quit S_a_i_n_t (Ping timeout: 265 seconds) 23.05.08 Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.195) 23.05.39 Quit b1uebrother (Quit: leaving) 23.05.54 Quit xiainx (Ping timeout: 276 seconds) 23.09.32 Quit Blue_Dude (Quit: ChatZilla 0.9.86 [Firefox 3.6.3/20100401080539]) 23.11.21 Join xiainx [0] (~xiainx@modemcable195.238-202-24.mc.videotron.ca) 23.13.31 Quit mt (Ping timeout: 240 seconds) 23.14.36 # Hi :) When I downloaded the iPodUbuntu_Plus theme, and since I use Hebrew, all the menues are unreadable. I'm assuming that cuase of the coding. How can I fix this so I can actually use this theme? 23.15.46 # You need to chose a font that has the glyphs you need and is the same size as that used by the theme 23.16.05 # AlexP, how do I do this and check that? 23.16.11 # Try them out? 23.16.19 # The size is in the name 23.16.24 # When I apply the theme, I can't read the menues... 23.16.33 # But not all fonts have all glyphs 23.17.08 Quit Chronon (Read error: Operation timed out) 23.17.37 # AlexP, so if I can't read the menues, how can I change them? 23.17.45 # I think there is something about what fonts have what glyphs at http://rasher.dk/rockbox 23.18.03 # Enable voicing, and/or note down how many clicks it takes 23.18.36 # For non-English voicing you'll need to create your own voice files though 23.18.46 # Or use English, and only switch to hebrew after changing the font. 23.19.14 # Isn't the only font for hebrew Unifont? 23.19.25 # I doubt it is the only, no 23.19.28 # Or you can edit the font name manually in the iPodUbuntu_Plus.cfg file. 23.19.34 # (from your PC) 23.19.46 # Worked like a charm :) linuxstb 23.20.15 Quit liar (Remote host closed the connection) 23.20.28 # I changed to English, then set the font 15-Adobe-Helvetica and then change the lang. back to Hebrew and I can see all the menues. 23.20.52 # S_a_i_n_t: As a note, please don't guess if you don't know, it only confuses things 23.21.43 # Thanks, guys... this is great now :) 23.21.54 Join dockimble [0] (~dockimble@77.227.1.24) 23.22.19 Nick fxb is now known as fxb__ (~felixbrun@h1252615.stratoserver.net) 23.26.46 # Anyone know the answer to http://forums.rockbox.org/index.php?topic=24410.0 ? 23.26.56 Join panni__ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) 23.28.37 # linuxstb: It has come up before - isn't it something to do with the current format for storing resume info would need to be rewritten to do that and nobody has? 23.29.53 Quit panni_ (Ping timeout: 264 seconds) 23.30.27 # I guess the initial problem is that the resume is in nvram.bin (or real NVRAM) 23.30.41 # yeah 23.31.09 # Let's just stop people deleting files - it causes all sorts of problems.... 23.31.36 # You can only delete files if all resume info and playlists are wiped at the same time :) 23.31.51 # So let's only support MTP, where we can control that... 23.33.10 # * AlexP slaps linuxstb 23.33.25 # never! 23.34.36 # But just storing the filename would have other problems - e.g. if the playlist contained that file multiple times, or if the user deleted that file due to be resumed. 23.34.36 Quit evilnick_B (Quit: Page closed) 23.34.55 Nick fxb__ is now known as fxb (~felixbrun@h1252615.stratoserver.net) 23.35.29 # Indeed, which I think is why nobody has done this yet - it needs a little thinking about 23.36.20 # it's also that not storing filenames is what makes resume real quick 23.36.45 # I guess the playlist needs to be stored too, and if the file to be resumed has gone then it tries the next in the playlist etc 23.36.48 Quit jd (Read error: Connection reset by peer) 23.36.56 # But I think it's a valid bug - Rockbox _should_ resume to the track it was last playing, regardless of whether the fix is easy or not. 23.37.04 # oh yes, I agree there 23.37.05 Join jd [0] (~jd@modemcable207.134-202-24.mc.videotron.ca) 23.37.05 Quit jd (Changing host) 23.37.05 Join jd [0] (~jd@Wikipedia/HellDragon) 23.38.22 # * AlexP adds some of that to his reply 23.38.31 # shameless plagerism :) 23.38.49 # s/plagerism/collaboration/ 23.39.10 # heh, cheers :) 23.41.51 Join Chronon [0] (~chronon@c-67-171-217-43.hsd1.or.comcast.net) 23.45.22 Join kwbr [0] (~kai@brln-4db9f86f.pool.mediaWays.net) 23.46.50 Join webguest36 [0] (~4db9f86f@giant.haxx.se) 23.47.07 # the google page has a separate field for the abstract, but in our template it comes after the information about me. should I cut out the abstract (with or without a reference at the point where the abstract is in our template?), or just copy it over and have it duplicated? 23.47.36 Part kwbr 23.47.36 Quit webguest36 (Client Quit) 23.47.37 Join Strife89 [0] (~michael@adsl-154-2-63.mcn.bellsouth.net) 23.48.00 Join kwbr [0] (~kai@brln-4db9f86f.pool.mediaWays.net) 23.48.51 Quit jgarvey (Quit: Leaving) 23.48.55 # kugel: I would say either duplicate it, or remove it from our template. 23.49.18 # I'll duplicate then because we're asked to follow the template closly 23.49.25 # would it be possible to synchronise the time of my rockbox device with my desktop computer? 23.49.39 # kwbr: That depends on your device. What is it? 23.50.10 # ipod, video 23.51.13 # linuxstb: I use rockbox-ipodvideo64mb.zip 23.51.17 # Then yes. 23.51.55 # linuxstb: cool. How would I do that? 23.52.17 # What OS do you use? 23.52.24 # linuxstb: I am on linux 23.53.57 # kwbr: if you're on a semi-recent debian-like system, install libgpod-common, and you'll have the ipod-time-sync tool 23.56.19 # thanks. I'll try that 23.56.23 # Is there a comparable tool for Windows? 23.56.25 # saratoga: It's not really surprising that ldm sometimes makes things faster on arm9, at least if the code in question resides in non-single-cycle, cacheable ram 23.57.46 # Oh, also if it'S non-cacheable 23.57.46 # shall I make it public? 23.57.49 # Strife89: no idea. Maybe rbutil could be taught to to it, it already does raw scsi commands... 23.57.55 # it = the application 23.58.29 # gevaerts: Definitely a nifty project to try.