00:02:34 | gevaerts | 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 | kugel | 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 | jhMikeS | gevaerts: that was what I had in mind earlier |
00:16:45 | jhMikeS | turn off scrolling then? |
00:17:02 | gevaerts | kugel: looks good I think |
00:17:17 | gevaerts | kugel: do you know if the sbs code always redraws text? |
00:17:48 | kugel | I think it does but I don't know exactly |
00:18:06 | gevaerts | If it does, just disabling scrolling won't help much |
00:18:37 | gevaerts | I think the font code should use some locking |
00:19:34 | linuxstb | kugel: For a *summer* of code, isn't your timezone GMT+2? |
00:20:23 | kugel | should that info contain the summer time? |
00:20:30 | jhMikeS | kugel: there's grammatical errors in case you're worried about that |
00:20:42 | kugel | sure |
00:20:51 | kugel | I bet there's a lot of them :p |
00:20:58 | pixelma | 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 | jhMikeS | pixelma: there are errors of the grammatical nature, indeed. :) what are you saying? " there *is* grammatical errors?" |
00:22:29 | jhMikeS | never mind, lol. |
00:22:37 | | Quit jordan` (Read error: Connection reset by peer) |
00:22:55 | jhMikeS | 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 | pixelma | 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 | AlexP | subdirectories looks funny to me |
00:35:43 | AlexP | linuxstb: ? |
00:36:31 | linuxstb | Yes, sub-directories would probably be how I would write it. I wouldn't be surprised if both are "correct" though. |
00:36:37 | pixelma | hmm... makes me wonder if the vice versa case woulf be needed too. |
00:36:47 | pixelma | *would |
00:38:43 | pixelma | 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 | AlexP | 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 | Blue_Dude | 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 | AlexP | You should discuss it first |
00:52:02 | AlexP | Otherwise we get into a commit war |
00:52:09 | AlexP | fml did IIRC |
00:52:21 | AlexP | And the reasons should be in the IRC logs |
00:52:39 | gevaerts | well, they should be in the commit message too... |
00:52:55 | AlexP | should be, don't know if they are |
00:53:13 | Blue_Dude | Actually, it was part of another patch. The comment didn't address the change at all. |
00:53:14 | pixelma | AlexP: I haven't checked but I *guess* there are currently both ways of spelling |
00:53:31 | AlexP | 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 | gevaerts | Blue_Dude: r25457? |
00:53:46 | Blue_Dude | That's the one. He also took out the splash screen. |
00:54:04 | AlexP | He did talk about it here first - I'd have a look at that, then mail the dev list |
00:54:12 | Blue_Dude | Woops, brb... |
00:54:13 | AlexP | I have a feeling it was discussed here |
00:54:34 | | Join jordan` [0] (~jordan@78.235.252.137) |
00:55:20 | gevaerts | 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 | gevaerts | hm, or maybe not |
00:55:57 | kugel | 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 | kugel | 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 | saratoga | Blue_Dude: http://forums.rockbox.org/index.php?topic=24377.msg164670;topicseen#msg164670 |
00:57:18 | saratoga | maybe you can help out that guy |
01:00 |
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 | niekie | Heh, I just killed my iPod. |
01:09:03 | niekie | I wanted to see what the shiny "Delete bootloader" option did in ipodpatcher. |
01:09:10 | niekie | Apparently, it deletes the bootloader :) |
01:09:14 | Llorean | You can reinstall the bootloader, though |
01:09:16 | niekie | Don't worry, I got it running again. |
01:09:40 | niekie | Llorean: nope, ipodpatcher didn't recognize it as an iPod anymore and refused to install the bootloader :( |
01:10:15 | Llorean | Were you booted into disk mode? |
01:10:19 | niekie | Yup. |
01:11:04 | Llorean | 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 | niekie | iPod Nano 2G. |
01:12:18 | | Quit JohannesSM64 (Ping timeout: 260 seconds) |
01:12:55 | linuxstb | 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 | jeffp | whoever runs the website: the sansa fuze (and others) manual has been offline for a few days |
01:14:18 | jacekowski | not a big loss if he killed ipood |
01:14:22 | jacekowski | 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 | niekie | 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 | niekie | Also, I tried to install a bootloader created from source.. so that might have helped in messing it up :) |
01:22:31 | niekie | Anyway, it's all up and working again. |
01:24:02 | Blue_Dude | Whew, sorry about that. I had reading duty. Bedtime for my 6 yr old. :) |
01:25:31 | Blue_Dude | 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 | kugel | 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 | kugel | 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 | Blue_Dude | 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 | pixelma | 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 | pamaury | user choose to reboot when he/she is sure of his/her choice :) |
01:45:38 | CIA-5 | New commit by mc2739 (r25472): Fix Clip keymap (manual) so that Clipv2 and Clip+ manuals build properly |
01:46:18 | kugel | 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 | kugel | I generally dont like splashes too much because they are so different to the rest of the ui |
01:46:52 | Blue_Dude | 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 | Blue_Dude | Oh garn, it's going to be a few minutes... |
01:50:55 | | Quit piotrekm (Quit: piotrekm) |
01:53:08 | kugel | 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 | Blue_Dude | So you're saying... *both* would be preferable. :) |
01:54:32 | kugel | no, I'm just trying to invalidate your argument that splashes are better visible :p |
01:54:44 | Llorean | Does the "yes no" disappear on its own, or only when a choice is made? |
01:54:56 | Llorean | I don't see why you need a splash *after* the confirmation request if it requires user input to confirm. |
01:54:57 | Blue_Dude | It only goes away after a keypress. |
01:55:03 | Llorean | So why have a splash? |
01:55:11 | Llorean | If the user wants to read it before they confirm, they will. |
01:55:24 | Blue_Dude | Well... I liked it. |
01:55:25 | Llorean | 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 | Llorean | What purpose does it serve, though? |
01:55:42 | Blue_Dude | I liked it. |
01:55:51 | * | Blue_Dude is starting to pout by now. |
01:56:37 | Blue_Dude | I don't know exactly why it's there, except that the code I stole from also had it. |
01:57:29 | Blue_Dude | And it seemed like a nice clean dialog. Pretty. |
01:57:48 | Blue_Dude | Other than that, no reason I guess. |
02:00 |
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 | Blue_Dude | So realistically, what are we up against? Is the splash a bad idea? Useless idea? |
02:15:53 | | Part froggyman |
02:17:31 | kugel | 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 | kugel | does anyone know how much applications we've got already? |
02:24:27 | saratoga | 4 as of a couple hours ago |
02:24:38 | saratoga | last year though we got a lot on the last day or two |
02:25:32 | saratoga | oh 6 now |
02:27:39 | kugel | saratoga: are you going to be the raaa mentor? I saw you on the list of possible mentors and nobody else |
02:27:59 | saratoga | kugel: i'll probably do one of the codec projects |
02:28:12 | saratoga | one of the people whos done more with the core would make sense for RAAA |
02:29:16 | saratoga | 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 | Blue_Dude | 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 | Blue_Dude | 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 | kugel | we had this topic before |
02:41:22 | kugel | while it's currently buggy, stopping the playback (or skipping to the next song) is not the prefered solution |
02:42:03 | Blue_Dude | The current situation is better? |
02:42:29 | Blue_Dude | In that case, why have delete in the WPS context menu at all? |
02:42:36 | kugel | it's buggy as I said |
02:42:47 | Blue_Dude | So what is the desired behavior? |
02:43:05 | Llorean | Blue_Dude: If the song is buffered, you can delete it while still finishing playback |
02:43:09 | kugel | delete, and play out what's left in the buffer |
02:43:26 | Llorean | 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 | Blue_Dude | Yeesh, that's a mess. Why do that? |
02:43:36 | Llorean | The bug comes in what happens if you delete it before all of it's in the buffer. |
02:44:01 | kugel | 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 | Blue_Dude | OK, I can see that. But if it's not completely buffered, why not go with the ebehavior I described? |
02:44:38 | Blue_Dude | ah |
02:44:45 | Blue_Dude | Where were the glitched/ |
02:44:50 | Blue_Dude | glitches? |
02:45:02 | kugel | at the end of a file |
02:45:07 | Llorean | Blue_Dude: Well the behaviour definitely shouldn't change depending on when you delete it. |
02:45:35 | kugel | I experienced it on my fuze where it's rather likely that not even a single song fits into the buffer |
02:45:42 | Blue_Dude | So then, play out already buffered material, then track change? |
02:45:52 | kugel | it looked like closing the handle and reopening on rebuffer inserts the glitch |
02:45:53 | Llorean | 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 | Llorean | In my opinion, at least. |
02:46:37 | Blue_Dude | Ow, that hurts my head. Why not just kill playback immediately, track change and rebuffer with the new track? |
02:46:58 | Blue_Dude | I mean, delete means delete, right? |
02:47:20 | Llorean | There are already people who make use of the fact that "delete" doesn't also mean "unbuffer" |
02:47:22 | Blue_Dude | BTW, splash! −−> http://pastie.org/903229 |
02:47:22 | kugel | 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 | Llorean | You'd be removing existing functionality. |
02:47:57 | Blue_Dude | Llorean: I'd make the argument that it's not a function, just the exploitation of a bug. |
02:48:36 | Blue_Dude | kugel: treat it internally as a track change, but with a file operation thrown in. |
02:48:44 | Llorean | I'm pretty sure it's been said to be intended behaviour, so calling it a "bug" is untrue. |
02:48:46 | Blue_Dude | And a playlist update. |
02:48:51 | kugel | there's no argument, playing out is the intentional behavior |
02:49:06 | Llorean | You can say it's intended behaviour that needs changed, but at the moment it's definitely a feature. |
02:49:28 | Blue_Dude | Sorry, I just don't see the virtue of that. Trust the user to know what he's doing. |
02:49:42 | kugel | (but I do think it should not delete until the end of the file has been buffered) |
02:49:53 | Llorean | 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 | kugel | and not before the next disk spinup |
02:50:24 | Llorean | 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 | Blue_Dude | kugel: the disk will need to spinup anyway to start buffering the next track. What difference does it make? |
02:50:34 | kugel | Blue_Dude: achiving what you want manually is trivial, while the opposite is impossible |
02:50:39 | kugel | achieving* |
02:50:53 | saratoga | i think the best option would be to advance the track and then immediately delete the file |
02:50:56 | kugel | Blue_Dude: huh? |
02:51:13 | kugel | the next track might be buffered as well |
02:51:14 | Blue_Dude | kugel: it's trivial with extra keypresses and unexpected behavior. |
02:51:18 | kugel | or the next 5 tracks |
02:51:22 | Llorean | saratoga: Why can't the user choose whether or not to advance the track? |
02:51:22 | Blue_Dude | Maybe... |
02:51:41 | saratoga | well first because I dislike having options that aren't overwhelming important |
02:51:48 | Llorean | As it stands, there's an existing feature that you're advocating removing without really gaining anything from removing it. |
02:51:53 | saratoga | but also because thats not going to work well on low mem targets |
02:51:53 | kugel | saratoga: what option? |
02:52:13 | Llorean | 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 | saratoga | on something like the Clip the current track can basically never be buffered entirely |
02:52:17 | Blue_Dude | 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 | Llorean | Ideally it'd be an actual "mark for deletion" rather than our current method, but that's just an improvement. |
02:52:28 | kugel | it's considered as a feature, if at all it lacks documentation |
02:52:49 | kugel | and as long as skipping the track is easy to do manually I wouldn't want it to change |
02:53:19 | Blue_Dude | If marked for deletion, when would the deletion take place? After stopping playback? |
02:53:23 | Llorean | 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 | saratoga | on something like the clipv1 i imagine its basically impossible to delete the currently playing track? |
02:53:42 | kugel | Blue_Dude: probably at the next disk spinup, via ata_idle_notify |
02:53:45 | saratoga | and probably for flac files on lots of players |
02:53:57 | Blue_Dude | Llorean: I meant dynamic playlists, but that's what I mean. |
02:53:59 | Llorean | 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 | kugel | immediate deletion isn't very important is it? |
02:54:12 | saratoga | well its less complicated |
02:54:18 | Llorean | Blue_Dude: Dynamic playlists should behave as much like static playlists as possible though. |
02:54:21 | saratoga | do we have a system for queuing file operations? |
02:54:36 | Blue_Dude | saratoga: I don't think so. |
02:54:47 | kugel | saratoga: what do you want to queue? |
02:54:54 | saratoga | the track delete |
02:55:02 | saratoga | lets add another 10 special cases to buffering.c to handle this! |
02:55:11 | Blue_Dude | God I need to look into the buffering code now. "Abandon all hope, ye who enter here." Drat. |
02:55:28 | saratoga | if you're really bored you could write that test driver i always wanted |
02:55:37 | kugel | saratoga: why special case? a delete after buffering flag could be quite generic |
02:55:42 | saratoga | so we can test buffering with the build system |
02:56:08 | saratoga | everything in the buffering system ends up being really complicated, i'm skeptical this will be different |
02:56:14 | saratoga | but i am only guessing |
02:56:29 | kugel | I'm expecting this to be a relatively simple change actually |
02:56:32 | Blue_Dude | Buffering rewrite! |
02:58:40 | Blue_Dude | 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 | kugel | why add something? |
02:59:09 | Blue_Dude | Also, before I lose track: http://pastie.org/903229 OK, or not OK? |
02:59:37 | kugel | Blue_Dude: Why do you want to push the splash just because you like it? |
02:59:40 | Blue_Dude | kugel: not everyone wants to keep going. Why not make it easy for him if he wants ti? |
03:00 |
03:00:05 | Blue_Dude | I guess I can take it out of bookmark.c too... |
03:00:10 | kugel | Blue_Dude: this is too minor to increase bloat imo |
03:00:37 | Blue_Dude | kugel: what's too minor, the mark for deletion or the splash? |
03:00:48 | kugel | the former |
03:01:04 | Llorean | 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 | kugel | 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 | Blue_Dude | 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 | kugel | we could simply fix the bug instead of overengineering this |
03:02:29 | kugel | Blue_Dude: intended behavior *is* defined |
03:02:31 | *** | Saving seen data "./dancer.seen" |
03:02:48 | kugel | play out what's in the buffer |
03:02:54 | saratoga | 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 | Blue_Dude | 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 | kugel | playing out the track (with possibly buffering the rest of it), i.e. mark for deletion, would be an improvement imo |
03:03:27 | Llorean | Blue_Dude: Yes, but your assumption is actually wrong. |
03:03:41 | Blue_Dude | Llorean: ok, ok. I'll take out the one in bookmark.c too when I have the chance. |
03:03:44 | Llorean | Well, it will always be deleted, yes, but deletion != "skip forward in playback" |
03:03:54 | Llorean | Blue_Dude: What's the one in bookmark.c for? Another yes/no? |
03:04:33 | Blue_Dude | 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 | Llorean | But that's simply a bug. |
03:04:54 | kugel | Blue_Dude: I already told you twice that this is a bug |
03:04:55 | Blue_Dude | Llorean: yes, another yes/no. The bookmark delete function. |
03:05:15 | Llorean | I don't remember bookmark deletion having a confirmation, though I haven't done it in a while. |
03:05:19 | kugel | your proposed fix isn't a fix though because it changes the intended behavior |
03:05:20 | Llorean | Didn't it used to be a single button press? |
03:05:21 | Blue_Dude | I know, but what's buggy, the fact that it won't delete? |
03:05:32 | kugel | ...yes |
03:05:46 | Llorean | The file should *always* be removed. |
03:05:47 | kugel | I actually explained where the bug is too |
03:05:51 | Blue_Dude | Llorean: no, I don't think so. I didn't change its behavior. |
03:06:09 | Llorean | Anyway, if there's always a yes/no dialogue, then there should be no splash. |
03:07:32 | Blue_Dude | kugel: To sum up: close the file handle, delete the file, keep playing whatever is buffered... is that it? |
03:07:47 | kugel | 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 | kugel | Blue_Dude: basically, but as I mentioned there's a glitch when closing the handle early |
03:08:31 | kugel | which is why I didn't fix it yet |
03:09:14 | Blue_Dude | It sure would make it easier if you just invalidated the buffering handle at the same time. |
03:09:42 | Blue_Dude | I know that's not going to happen. |
03:10:21 | kugel | 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 | kugel | so, until the next rebuffer the file is basically blocked |
03:11:17 | saratoga | FWIW i really dislike the idea of continuing to play after you attempt a delete because its so target specific |
03:11:32 | saratoga | or at least the way we do it now |
03:12:13 | saratoga | hmm i take that back |
03:12:13 | kugel | which is why I consider mark for deletion as an improvement |
03:12:37 | saratoga | yeah i see what you're getting at now |
03:13:47 | Blue_Dude | I know next to nothing about the buffering system. Is there a way to set flags on buffered items? |
03:19:08 | Blue_Dude | Anyway, I'll look into it. Eventually. I'd like to fix the bookmark stuff first. |
03:20:58 | CIA-5 | New commit by Blue_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 | kugel | linuxstb: yes you should ;) |
03:35:28 | kugel | 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 | flyback | so all the versions of sansa clip are supported? |
03:45:30 | Llorean | 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:00 |
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 |
05:00:33 | | Quit Barahir_ (Ping timeout: 260 seconds) |
05:00:34 | | Join RandomInsano2 [0] (~4ad84807@giant.haxx.se) |
05:01:51 | RandomInsano2 | 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 | RandomInsano2 | I needs Wiki edit priviledges for username RandomInsano |
05:02:45 | saratoga | RandomInsano2: sure, whats your name |
05:03:01 | RandomInsano2 | Edwin Amsler, but I chose a different handle. |
05:03:11 | saratoga | oh, well fix that then i'll give you access |
05:03:19 | RandomInsano2 | Alrighty |
05:03:50 | | Quit n17ikh (Ping timeout: 245 seconds) |
05:03:58 | RandomInsano2 | Is that possible, or should I just create a new user? |
05:04:43 | saratoga | i think you need to make a new account |
05:05:02 | RandomInsano2 | I'll go do that then. Delete the current then please |
05:06:59 | RandomInsano2 | How... do I log out? |
05:08:36 | | Join n17ikh [0] (~n17ikh@host-69-59-126-212.nctv.com) |
05:08:42 | RandomInsano2 | Registration complete for 'EdwinAmsler' |
05:10:58 | | Join funman [0] (~fun@rockbox/developer/funman) |
05:13:47 | saratoga | RandomInsano2: ok added |
05:14:27 | RandomInsano2 | Much thanks! I'm still a little unclear how I logout of the wiki so I can log back in |
05:14:52 | funman | I have another theory for CGU_PROC / CGU_PERI on as3525v2 |
05:15:08 | funman | CGU_PROC divides PLLA to give fclk |
05:15:15 | funman | 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 | S_a_i_n_t_ | 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 | S_a_i_n_t_ | ...May have been a contributing factor. |
05:32:10 | * | funman slaps buschel for not testing r25464 |
05:33:56 | S_a_i_n_t_ | 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:00 |
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 | notlistening | 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 | funman | fuzev2 works fine at 24MHz but the display is noticeably slower |
06:15:21 | S_a_i_n_t_ | Do you have a runtime for 24MHz yet? |
06:15:33 | funman | nope i just got it right in my build |
06:15:53 | S_a_i_n_t_ | Aha...so, bench tonight? ;) |
06:16:11 | funman | previous bench for Clip+ (16h30) was with CPU at 24MHz / peripheral clock at 6MHz, and 10 times faster when boosted |
06:16:14 | funman | not sure |
06:20:28 | | Join TillW [0] (~Till@h74-net09.simres.netcampus.ca) |
06:26:47 | notlistening | funman do you sleep :D |
06:27:17 | notlistening | Is it normal for the Clip+ to have a yellow/orange bar at the top of the screen? |
06:27:23 | S_a_i_n_t_ | "can't sleep... must. fix. red." :P |
06:28:00 | notlistening | lol now as someone is talking about red I see it all the time on commits what is red etc etc? |
06:28:25 | S_a_i_n_t_ | Red = Bad, broken. etc. |
06:28:42 | funman | notlistening: yes the top quarter of the screen is yellow on all clips and the rest blue |
06:30:28 | notlistening | 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 | notlistening | thanks funman |
06:31:49 | S_a_i_n_t_ | notlistening: yes, it is...but it seems to be a habit now. |
06:31:54 | S_a_i_n_t_ | Or, for some time rather. |
06:32:50 | notlistening | 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 | funman | someone with an e200v1 could give me the results of test_fps with both boosted & unboosted CPU ? |
06:35:59 | notlistening | only got a V2 sorry |
06:38:37 | saratoga | funman: beyond the ones on the wiki: http://www.rockbox.org/wiki/LcdFrameRate |
06:38:45 | saratoga | if so I can compile that plugin |
06:40:29 | funman | ah nope, it's enough, thanks |
06:41:53 | funman | pixels swapping for fuzev2 display slows down things a bit |
06:43:30 | funman | without swapping, and pclk==60MHz, performance is a small bit under fuzev1 (pclk==62MHz) |
06:44:59 | funman | 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 | CIA-5 | New commit by funman (r25474): test_mem: fix r25464: button_get() can't be used with actions |
06:48:45 | CIA-5 | New commit by funman (r25475): as3525v2: set PCLK correctly ... |
06:51:20 | funman | I wonder if it's possible to change pixel format with the Fuzev2 LCD |
06:55:50 | saratoga | funman: what was pclk at before when unboosted? |
06:56:44 | funman | 6MHz on Clipv2/+ and 15MHz on Fuzev2 |
06:57:11 | funman | no changes in playback because mclk is based on PLLA which didn't change |
06:57:17 | funman | and timers are based on the 24MHz crystal |
06:57:47 | saratoga | mclk is the DRAM? |
06:58:06 | funman | not it's the i2s clock |
06:58:10 | funman | for pcm/recording |
07:00 |
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 | CIA-5 | New commit by funman (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:00 |
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 | amiconn | 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 | funman | oh didn't know it existed |
08:29:01 | funman | (also i don't know the armv5 isntructions) |
08:30:02 | amiconn | It uses plain armv4/v5 instruction, nothing special |
08:30:25 | funman | ah i was looking at v6 then |
08:30:34 | amiconn | On armv6 it's a single instruction, but that's irrelevant on the ams sansa |
08:30:36 | amiconn | +s |
08:33:14 | | Quit r2k000 (Ping timeout: 258 seconds) |
08:35:25 | CIA-5 | New commit by funman (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 | funman | amiconn: do you want to modify the fuzev1 write_yuv() functions to add this swapping ? |
08:49:23 | funman | green part needs to be split in 2 |
08:50:02 | funman | 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 | funman | 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 | amiconn | It would save the swapping in the update (not for yuv of course) |
08:55:26 | * | funman discovers new things everyday |
08:58:20 | funman | in fact i had looked at lcd-16bit.c but didn't see anything |
09:00 |
09:02:07 | amiconn | Of course not, since lcd-16bit.c doesn't have to care about the actual bit order within the 16 bits |
09:02:36 | funman | ok i'm just testing it |
09:02:40 | *** | Saving seen data "./dancer.seen" |
09:02:48 | funman | what about yuv assembly, are you interested? |
09:02:56 | amiconn | All colour PP ipods (Color/PHoto, Nano G1, Video) use RGB565SWAPPED |
09:03:12 | funman | yep I see bmp2rb -f 5 option is documented as being "Ipod" |
09:09:20 | | Quit notlistening (Quit: Leaving) |
09:10:03 | CIA-5 | New commit by funman (r25478): Fuzev2: use RGB565SWAPPED (pointed out by amiconn) => 91fps |
09:11:05 | funman | amiconn: ? |
09:12:50 | saratoga | is 100 fps still the limit like on the v1? |
09:18:05 | | Part Boldfilter |
09:18:13 | funman | I don't remember how the limit was calculated |
09:18:30 | funman | supposing the DBOP hardware didn't change it should be the same afaiu |
09:21:11 | funman | amiconn: reading lcd-as-video.S i don't see where the 16 bits rgb value is swapped? |
09:21:44 | saratoga | aren't they computed in swapped order? |
09:21:51 | funman | ah ipodvideo lcd isn't swapped |
09:22:07 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
09:22:13 | funman | only color & nano1g |
09:23:51 | funman | and they just use swap16() |
09:25:31 | funman | 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 | amiconn | funman: Eh, sorry, the video does not need swapping |
09:30:20 | | Quit JanDo (Ping timeout: 276 seconds) |
09:30:29 | amiconn | 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 | CIA-5 | New commit by funman (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:00 |
10:03:08 | * | funman starts benching Clipv2 |
10:06:14 | saratoga | i guess the fixed pclk should mean less boosting? |
10:08:14 | funman | since memory is faster yep |
10:08:25 | funman | i have no previous bench for clipv2 though |
10:08:50 | funman | and it crashed earlier so i hope it'll work for the whole 15 hours or so |
10:09:14 | saratoga | from what i understand the clock changes made the sd driver fairly unstable |
10:09:35 | funman | yep especially µSD |
10:09:45 | funman | it could be better now |
10:10:41 | | Join stoffel [0] (~quassel@p57B4D0F1.dip.t-dialin.net) |
10:12:16 | saratoga | the low clock on the amsv2 is nice, finally gives me a reason to look into making mp3 faster again |
10:13:00 | saratoga | bet we could shave 1 or 2 MHz off the filterbank on arm9e |
10:15:08 | funman | (clipv2 crashed) |
10:26:31 | | Join flydutch [0] (~flydutch@host225-165-dynamic.15-87-r.retail.telecomitalia.it) |
10:29:41 | funman | I started the Clip+ with the same album I had used previously, let's if i have better luck |
10:30:10 | funman | i also have put backlight always on on the clipv2 to see if it panics |
10:32:57 | funman | 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 | S_a_i_n_t | Is the "lamp" plugin supposed to time out at all, after "X" period, or after a completely random "Y" period? |
10:46:52 | S_a_i_n_t | Using it, its kinda hard to tell. |
10:46:56 | | Quit Kitr88 (Ping timeout: 276 seconds) |
10:47:37 | funman | it doesn't timeout |
10:47:51 | S_a_i_n_t | Somtimes it appears to "time out" (the period is random), and others it just crashes the player. |
10:48:05 | funman | which player. |
10:48:06 | funman | ?* |
10:48:16 | S_a_i_n_t | Nano1/2g I get the results I've just mentioned. |
10:48:48 | S_a_i_n_t | It looks as though the battery dies, but when I start it back up the battery is always fine. |
10:49:22 | S_a_i_n_t | but when it appaers to "time out" (ie. not crashing the player) it always seems to be a different time limit. |
10:49:42 | S_a_i_n_t | But now you've said it *doesn't* time out, its even weirder still. |
10:50:01 | funman | according to lamp.c it will exit if you press any button other than left/right and scrollwheel |
10:50:24 | S_a_i_n_t | Yes, this is just starting it up and leaving it though. |
10:50:33 | S_a_i_n_t | (I tried to use it to read last night) |
10:50:40 | S_a_i_n_t | ...much to my dismay. |
10:50:58 | funman | how much time approximately? i just started it on fuze |
10:51:20 | S_a_i_n_t | 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 | S_a_i_n_t | Ahem.."anywhere from 1 to 5 minutes." |
10:54:21 | S_a_i_n_t | failed after 2 minutes an Nano1g just now. |
10:54:33 | S_a_i_n_t | Nano2g still going. |
10:54:43 | | Join Lynx_ [0] (~Lynx@86.51.114.197) |
10:54:49 | S_a_i_n_t | Batter on the 1g reads 92% |
10:55:19 | S_a_i_n_t | Nano2g failed, batter 44% (lamp.rock on for 3mins approx) |
10:57:36 | funman | no crash on fuzev2 |
10:57:49 | | Quit Rob2223 (Ping timeout: 265 seconds) |
10:58:05 | funman | something happen if you just leave the backlight always on and sit in a plugin ? |
10:58:18 | S_a_i_n_t | Hmmm, well. The Nanos don't seem to be able to handle it for some reason. |
10:58:37 | S_a_i_n_t | and no, it can sit in a plugin with the backlight on indefinitely. |
10:58:42 | S_a_i_n_t | (as far as I know) |
10:58:44 | ThomasAH | 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 |
11:00:00 | | Quit bluebrother (Disconnected by services) |
11:00:01 | | Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) |
11:00:50 | S_a_i_n_t | 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 | ThomasAH | 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 | S_a_i_n_t | Funman, wow..actually, you were right. |
11:02:12 | funman | 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 | S_a_i_n_t | Plasma.rock with backlight on kills it even faster than lamp does. |
11:02:40 | S_a_i_n_t | 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 | ThomasAH | funman: hmm, with svn from today I just had random crashes, too ... |
11:03:48 | S_a_i_n_t | Wait, if a plugin is running..."idle timeout" shouldn;t matter, should it? |
11:04:00 | ThomasAH | (internal memory) |
11:04:05 | saratoga | ThomasAH: if you can put it online, you might as well file a bug report |
11:04:24 | saratoga | assuming it crashes repeatedly in rockbox |
11:04:41 | ThomasAH | saratoga: repeatedly in roxbox and OF at the same second |
11:04:51 | ThomasAH | family interrupt ... |
11:05:05 | saratoga | 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 | S_a_i_n_t | 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 | S_a_i_n_t | IMO lamp.rock shouldn;t timeout at all.Even if there is a timeout period set, But that's just me. |
11:21:21 | saratoga | 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 | saratoga | 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:00 |
12:01:43 | | Join merbanan [0] (~banan@c-62-220-165-110.cust.bredband2.com) |
12:08:02 | CIA-5 | New commit by Buschel (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:00 |
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 | AlexP | who? |
13:16:12 | AlexP | Or do you mean should have? |
13:16:12 | kugel | whoever wants |
13:16:38 | kugel | last year we were 2 more |
13:18:02 | kugel | hm, I see Zagor in the participants list but B4gder in the bed room list |
13:18:15 | kugel | I guess both come? |
13:18:16 | AlexP | yeah, they are both coming though |
13:18:37 | AlexP | It is just one isn't sleeping and the other isn't participating :) |
13:19:23 | kugel | :p |
13:20:08 | pixelma | 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 | kugel | that was me ;) |
13:23:08 | * | gevaerts thinks they're both sleeping |
13:23:26 | gevaerts | 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 | gevaerts | 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:00 |
14:01:46 | CIA-5 | New commit by kugel (r25481): Fuzev2: Reduce code duplication by reusing Fuzev1 code. |
14:02:21 | kugel | hm, git tricked me |
14:02:26 | | Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) |
14:02:58 | CIA-5 | New commit by kugel (r25482): Add forgotten file (git was supposed to rename!). |
14:04:50 | kugel | interesting, bootloader reds. I don't think we need yuv blitting in the bootloaders |
14:08:31 | pixelma | there's a Packard Bell Vibe500 build in the 8MB-Recorder build download - hence the delta |
14:09:50 | pixelma | stuff like this happens from time to time in the last month(s), I wonder what's going on there |
14:12:45 | mc2739 | 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 | gevaerts | It's perl though, so I might not find much |
14:17:13 | CIA-5 | New commit by kugel (r25483): as2525(v2): We don't need yuv blitting/greylib support in the bootloader so don't compile it. |
14:17:16 | pixelma | 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 | gevaerts | 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 | CIA-5 | New commit by kugel (r25484): Fix yellow. Another function unneeded in the bootloader. |
14:25:10 | | Quit Highlander (Quit: Quitte) |
14:26:34 | gevaerts | 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 | yorick | hmm...my player is consistently refusing to play my music in the database order |
14:57:17 | S_a_i_n_t | is "shuffle" on? |
14:57:27 | yorick | I think not |
14:57:32 | S_a_i_n_t | sorry...I know it sounds stupid, but you'd be surprised. |
14:57:53 | yorick | but would that show the behavior of "select file" -> "play entirely different one" |
14:58:08 | S_a_i_n_t | Ah, no. It wouldn't. |
15:00 |
15:00:30 | yorick | "play track 1" "screw it, I'm playing track 3 and then continuing randomly, entirely skipping track 2" |
15:00:56 | gevaerts | that does sound like shuffle to me... |
15:01:09 | bertrik | maybe it's skipping those tracks because of a codec error |
15:01:15 | gevaerts | that's possible too |
15:01:29 | S_a_i_n_t | bodgy FS? |
15:01:43 | | Join jgarvey [0] (~jgarvey@cpe-065-190-066-089.nc.res.rr.com) |
15:01:52 | bertrik | what player is this anyway? and what rockbox version? |
15:01:59 | yorick | I can rewind back to track 1 |
15:02:03 | linuxstb | yorick: Have you checked that shuffle isn't enabled? |
15:02:10 | yorick | it's an apple ipod video 30GB |
15:02:35 | yorick | with rockbox 3.5.1 |
15:02:40 | S_a_i_n_t | Shuffle can be switched on pretty easily by mistake with the quickscreen... |
15:02:47 | *** | Saving seen data "./dancer.seen" |
15:02:47 | S_a_i_n_t | ?me has done this *many* times. |
15:03:02 | yorick | ah great now it's stuck on "Scanning disk..." |
15:03:32 | | Quit geertvdijk (Ping timeout: 264 seconds) |
15:03:55 | yorick | "Shuffle No" |
15:03:58 | yorick | "Repeat Off" |
15:04:03 | yorick | "Show Files Supported" |
15:04:39 | yorick | hmm, it played the same track 3 times now |
15:04:58 | yorick | basically, I took my ipod video, with 25 GB of music on it |
15:05:03 | yorick | and then installed rockbox on it |
15:05:07 | yorick | and initialized the database |
15:05:20 | yorick | the original firmware still works fine |
15:05:30 | pixelma | 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 | yorick | one album is even entirely doubled |
15:05:44 | S_a_i_n_t | I'm ussuming that the original (Apple) firmware plays tracks free from error? |
15:05:50 | S_a_i_n_t | *assuming |
15:06:11 | linuxstb | yorick: After Rockbox initialised the database, how did you restart Rockbox? i.e. what buttons did you press? |
15:06:30 | yorick | I did menu+select |
15:06:38 | yorick | because it wasn't shutting down with long play |
15:06:42 | gevaerts | yorick: maybe try checking the filesystem. Filesystem corruption has been known to cause all sorts of weird issues |
15:06:54 | yorick | how am I supposed to check the filesystem |
15:07:04 | S_a_i_n_t | depends on your OS |
15:07:11 | yorick | ubuntu 9.10 |
15:07:32 | mt | 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 | gevaerts | fsck.vfat then |
15:07:55 | yorick | mt: all the same format |
15:08:01 | yorick | CBR 320kpbs mp3 |
15:08:06 | yorick | it happens on every album |
15:08:22 | gevaerts | pixelma: at least one of today's wrong builds came from GodEater's system |
15:08:39 | linuxstb | yorick: Do you normally eject/unmount your ipod before unplugging it, or do you somethings just pull the cable out? |
15:08:56 | yorick | I do safely remove :) |
15:08:56 | pixelma | gevaerts: I meant the build that was actually put in the wrong zip |
15:09:23 | gevaerts | pixelma: yes, that's what I mean too :) |
15:09:45 | yorick | hmm I think I fixed it |
15:09:59 | pixelma | gevaerts: was that the round with the wrong 3G Ipod build? |
15:10:15 | gevaerts | pixelma: no, the one after, with the wrong yh920 |
15:10:19 | yorick | it was the centerart theme |
15:10:21 | gevaerts | oh, wait, no |
15:10:28 | yorick | switching to the rockboxed theme fixed all my problems |
15:10:32 | gevaerts | The one before, with the wrong recorder |
15:11:13 | gevaerts | yorick: that really shouldn't change anything... |
15:11:14 | | Quit antil33t (Read error: Connection reset by peer) |
15:11:17 | S_a_i_n_t | 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 | yorick | well it did |
15:11:37 | pixelma | 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 | gevaerts | pixelma: hm, maybe I wasn't looking right... |
15:11:58 | linuxstb | yorick: I would still check the filesystem for errors. And probably re-initialise the database. |
15:12:17 | pixelma | gevaerts: in the Samsung zip |
15:12:36 | yorick | ok...switching back to CenterArt -> broken again |
15:12:45 | gevaerts | 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 | linuxstb | 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 | S_a_i_n_t | 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 | yorick | linuxstb: every part of rockbox worked otherwise |
15:14:06 | yorick | except the database, which told me to reboot |
15:14:19 | yorick | could the charger being plugged in have anything to do with it? |
15:14:33 | linuxstb | Yes, Rockbox won't shut down if the charger is plugged in. |
15:14:40 | yorick | S_a_i_n_t: I know it's strange, but it's true... |
15:15:02 | S_a_i_n_t | there is probably something deeper going on here...*probably* |
15:15:16 | | Join kugel_ [0] (~kugel@e178098254.adsl.alicedsl.de) |
15:15:18 | S_a_i_n_t | I can't reproduce it in the sim, the theme works fine for me. |
15:15:24 | gevaerts | 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 | yorick | 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 | linuxstb | yorick: As we've all been saying for 10 minutes, check the filesystem... |
15:16:24 | yorick | hmm it switched back to some kind of other screen after connecting |
15:16:42 | S_a_i_n_t | define "other screen" |
15:16:44 | linuxstb | Probably Apple's disk mode screen. |
15:17:22 | yorick | empty screen showing battery symbol, flashing forbidden sign, and "Do not disconnect." |
15:17:37 | S_a_i_n_t | Apple disk mode, this is fine. |
15:17:40 | S_a_i_n_t | And normal. |
15:17:59 | yorick | hmm lets see: fsck.vfat /media/ipodmountpoint |
15:18:00 | yorick | right |
15:18:11 | gevaerts | no, the device, not the mountpoint |
15:18:34 | gevaerts | after unmounting first |
15:19:22 | yorick | 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 | gevaerts | I know umount doesn't do that. Maybe ubuntu's gui tools do, but I don't know those... |
15:22:54 | gevaerts | Does that affect the ipod though? |
15:23:22 | yorick | ipod says "OK to disconnect" |
15:23:23 | linuxstb | yorick: Type "mount" at the command-line, and that should tell you the device - e.g. "/dev/sdb2" |
15:24:03 | gevaerts | OK, as soon as it says that you can run fsck on it |
15:24:10 | yorick | /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 | linuxstb | OK, so first do "sudo umount /dev/sdb2" |
15:24:33 | * | linuxstb doesn't know the fsck syntax... |
15:24:58 | yorick | I did umount /media/ipodname |
15:25:06 | gevaerts | fsck.vfat -a /dev/sdb2 |
15:25:10 | yorick | it said "it's now safe to remove ipod" |
15:25:23 | yorick | and ipod is still on "Do not disconnect" |
15:25:44 | linuxstb | What said "it's now safe to remove ipod" ? The umount command should just say nothing. |
15:25:54 | yorick | the umount command |
15:26:31 | | Join lpereira [0] (~lucien@142.12.92-79.rev.gaoland.net) |
15:26:49 | yorick | http://pastebin.com/CYUgq3Jr |
15:27:24 | gevaerts | ok, so it's not filesystem corruption |
15:27:42 | yorick | hmm now how do I disconnect it |
15:27:47 | | Quit mikroflops_ (Ping timeout: 268 seconds) |
15:27:55 | yorick | it did it in 5 seconds? |
15:28:05 | gevaerts | hm, good point |
15:28:32 | gevaerts | well, it might |
15:28:39 | gevaerts | Anyway, just disconnect it. It's not mounted, so it's safe |
15:29:05 | yorick | it says "Do not disconnect" |
15:29:30 | gevaerts | if you really want to, run "eject /dev/sdb" first then, but it's not needed in this case |
15:29:41 | gevaerts | fsck time usually depends on the number of files, not on the size of the disk |
15:29:55 | gevaerts | and 3000 files isn't *that* many |
15:30:16 | S_a_i_n_t | depends on the size of said files though...no? |
15:30:25 | yorick | 20 GB |
15:30:29 | | Join mikroflops [0] (~yogurt@90-224-30-68-no112.tbcn.telia.com) |
15:30:53 | yorick | I'll reinitialize the database |
15:31:03 | gevaerts | 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 | S_a_i_n_t | Ahhh...good point. Still, damn fast, impressive. |
15:32:03 | yorick | 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 | yorick | 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 | yorick | hmm...centerart is the only theme I installed using rockboxutility |
15:50:28 | yorick | could it be it's broken somehow |
15:50:37 | yorick | and breaks playback somehow |
15:50:50 | yorick | because every other(preinstalled) theme works |
15:51:26 | gevaerts | still sounds unlikely |
15:52:02 | yorick | then what |
15:52:21 | gevaerts | Did the problem stay after rebooting? |
15:52:28 | yorick | yes |
15:52:29 | | Quit froggymana (Quit: CGI:IRC) |
15:52:33 | yorick | and after reinitializing the database |
15:53:48 | S_a_i_n_t | 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 | yorick | maybe it's a 3.5.1 bug? |
15:54:25 | S_a_i_n_t | *unlikely*, but possible. |
15:54:34 | gevaerts | S_a_i_n_t: for this sort of weird issues, it's not that unlikely that the sim behaves differently |
15:54:39 | S_a_i_n_t | I'm sure it would have been mentioned by now though. |
15:54:56 | yorick | centerart uses custom menu, it says |
15:55:24 | S_a_i_n_t | 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 | yorick | centerart doesn't seem widely used, maybe only the database is bugged? |
15:56:42 | yorick | downloaded 1886 times |
15:56:57 | S_a_i_n_t | thats fairly *widely used* |
15:57:00 | gevaerts | yorick: just to clarify, this is CenterArt and not CenterArt v2.0? |
15:57:49 | yorick | this is v2.0 |
15:58:02 | yorick | (hehe) |
15:58:21 | S_a_i_n_t | Well, *that* would have been nice to know from the start lol... |
15:58:35 | yorick | I guess so |
15:59:10 | gevaerts | 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 | S_a_i_n_t | v2.0 behaves as it should in the sim |
16:00 |
16:00:01 | | Quit n17ikh (Ping timeout: 245 seconds) |
16:00:05 | S_a_i_n_t | (or seems to at least) |
16:00:07 | yorick | I'll install another theme and see if that also fails |
16:00:10 | | Quit fejfighter (Ping timeout: 258 seconds) |
16:01:04 | GodEater | gevaerts: "wrong" builds? |
16:01:09 | GodEater | do I need to mend something? |
16:01:45 | gevaerts | 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 | yorick | ok...I installed another theme...that worked |
16:03:12 | yorick | then switched back to centerart |
16:03:18 | yorick | the center art thing is gone |
16:03:21 | yorick | but the rest works fine |
16:03:38 | S_a_i_n_t | "center art thing is gone"? |
16:03:44 | S_a_i_n_t | as in, no album art/ |
16:03:47 | yorick | yes |
16:03:56 | yorick | and also no playlist |
16:03:59 | S_a_i_n_t | does the track *have* album art? |
16:04:04 | yorick | no |
16:04:08 | yorick | but it didn't before |
16:04:12 | S_a_i_n_t | well, there ya go ;) |
16:04:19 | yorick | and it displayed some nice playlist instead of album art |
16:04:23 | yorick | 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 | kugel | it's 25%-35% faster throughout all testable files |
16:14:17 | TabalugaFX | hi @ all |
16:14:29 | | Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) |
16:15:17 | TabalugaFX | I have a question about the themes submitting process which I can't find in the wiki / docs sections |
16:15:31 | S_a_i_n_t | ...ask away. |
16:15:53 | TabalugaFX | 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 | AlexP | Use the dame details as before and it'll be replaced |
16:16:10 | AlexP | *same |
16:16:22 | AlexP | your name, your e-mail and theme name that is |
16:16:28 | S_a_i_n_t | "re"submit it using the same author details and email address, it will ask for confirmation about replacing it. |
16:16:57 | TabalugaFX | great thanks. this information would be useful inside the wiki / docs |
16:17:08 | kugel | leave the fields for the .zip and screens empty, you'll need to refill them when you're asked for updating |
16:17:16 | kugel | s/screens/screenshots/ |
16:17:17 | AlexP | TabalugaFX: The wiki is a wiki :) |
16:18:37 | TabalugaFX | yes i know, so if i have more time i'll edit and add some informations |
16:19:40 | TabalugaFX | and i have another question with an error or perhaps an unwanted bug |
16:19:56 | gevaerts | Most of our bugs are unwanted |
16:20:05 | | Join jordan` [0] (~jordan@78.235.252.137) |
16:20:28 | TabalugaFX | yesterday i copied the full HVSC archive (SID) onto my player |
16:20:50 | AlexP | We can't fix that bug :) |
16:21:15 | S_a_i_n_t | gevaerts: *most*? |
16:21:24 | S_a_i_n_t | ;P |
16:21:45 | gevaerts | 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 | S_a_i_n_t | Ahhhh, right. Gotcha. |
16:22:51 | TabalugaFX | 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 | gevaerts | yorick: do you have the font pack installed? |
16:23:38 | TabalugaFX | yes |
16:24:00 | TabalugaFX | or sorry i wasnt mean |
16:24:39 | AlexP | TabalugaFX: Does this happen if playing through the file browser? |
16:25:03 | TabalugaFX | no, while i'm using the wps |
16:25:16 | TabalugaFX | but I created the playlist inside the file browser |
16:26:10 | TabalugaFX | and i already turned off the repeat feature to sbypass the subsongs of every sid file |
16:26:45 | AlexP | I meant if you select the song through the filebrowser |
16:26:55 | AlexP | as opposed to the database |
16:27:11 | | Quit stripwax (Quit: http://miranda-im.org) |
16:27:14 | TabalugaFX | yes indeed i selected the folder i want to listend and add them to the playlist |
16:27:19 | AlexP | OK |
16:27:39 | AlexP | Sounds like a bug then |
16:27:40 | yorick | gevaerts: dunno |
16:27:59 | yorick | gevaerts: I did standard installation |
16:28:10 | AlexP | Could you add it to flyspray, including all the details (player, Rockbox version, settings etc.) and say how to reproduce it? |
16:28:19 | gevaerts | yorick: does the CenterArt theme look correct, i.e. does it have proper line drawing? |
16:28:39 | TabalugaFX | ok i'll |
16:28:45 | yorick | gevaerts: yes |
16:28:49 | AlexP | TabalugaFX: Thanks |
16:28:51 | TabalugaFX | btw thanks for your help |
16:28:58 | AlexP | no problem :) |
16:29:03 | TabalugaFX | ah btw |
16:29:12 | | Join paulk_ [0] (~paulk@lib33-1-82-233-88-171.fbx.proxad.net) |
16:29:20 | TabalugaFX | is it possible to install rockbox on my dingoo a-320? |
16:29:24 | AlexP | nope |
16:29:31 | TabalugaFX | :-( |
16:29:32 | AlexP | Only the players listed on www.rockbox.org |
16:29:55 | TabalugaFX | yes i know, but dingux (dingoo linux) uses the rockbox bootloader |
16:30:01 | AlexP | really? |
16:30:06 | AlexP | Do you have a link? |
16:30:11 | TabalugaFX | hmm wait |
16:30:16 | AlexP | Either way, full Rockbox would have to be ported |
16:30:27 | gevaerts | yorick: can you check the font settings to see if the 14-Terminus-Bold font is there? |
16:30:38 | AlexP | It sounds like it should be possible, but it is a lot of work |
16:32:12 | TabalugaFX | http://dingoowiki.com/index.php/Dingux:About#Installing_the_firmware (named "Rockbox mode") |
16:33:40 | yorick | gevaerts: it is |
16:34:55 | yorick | ooh it's broken again |
16:34:57 | yorick | after rebooting |
16:35:04 | AlexP | TabalugaFX: I don't see any mention of Rockbox though, just something called Rockbox mode |
16:35:31 | yorick | gevaerts: it just asked me if it was OK to remove dynamic playlist |
16:35:40 | S_a_i_n_t | RockBox == Dualboot?!? (apparently) |
16:36:35 | S_a_i_n_t | 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 | yorick | S_a_i_n_t: yes but I don't remember making one |
16:36:50 | gevaerts | yorick: can you put the contents of .rockbox/config.cfg on a pastebin? |
16:36:51 | yorick | it asked me this after a reboot |
16:38:12 | yorick | gevaerts: http://pastebin.com/HQf9xMQd |
16:38:26 | | Join TabalugaFX [0] (~5b264366@giant.haxx.se) |
16:38:59 | TabalugaFX | re. sorry my connection is very slow and hangs from time to time :-/ |
16:39:40 | AlexP | 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 | TabalugaFX | thanks. yes they only mentioned the dual boot feature |
16:42:35 | gevaerts | This is getting weirder and weirder... |
16:43:23 | S_a_i_n_t | gevaerts: You can reproduce? |
16:44:02 | gevaerts | 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 | yorick | told ya |
16:46:40 | TabalugaFX | @ 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 | yorick | TabalugaFX: this happens on every track I play |
16:47:40 | yorick | 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 | TabalugaFX | @ gevarts or try an "updated" rockbox version |
16:47:53 | TabalugaFX | and update database again |
16:47:57 | | Part Eugenpaul |
16:48:00 | AlexP | TabalugaFX: gevaerts is a core developer :) |
16:48:01 | gevaerts | TabalugaFX: I'm trying to isolate a bug here... |
16:48:10 | AlexP | And he is trying to help yorick with a bug |
16:48:12 | TabalugaFX | or sorry, i don't know |
16:48:13 | gevaerts | gah, battery dead again... |
16:48:24 | yorick | gevaerts: connect charger? |
16:48:34 | gevaerts | yorick: it's connected... |
16:48:42 | yorick | :/ |
16:48:57 | yorick | open it up and short out some diodes :P |
16:49:09 | S_a_i_n_t | yeah, that'll help. |
16:49:13 | S_a_i_n_t | ;P |
16:50:20 | | Join toffe82 [0] (~chatzilla@12.169.218.14) |
16:50:32 | gevaerts | Anyway, since I can reproduce it with 3.5.1, let's try a current build next |
16:51:25 | yorick | 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 | paulk_ | hello! |
16:52:16 | TabalugaFX | hello |
16:52:52 | paulk_ | I've made some personnal modifications to rockbox : |
16:52:52 | paulk_ | * I've set-up the BUTTON_REC of my sansa's keymap to ACTION_FM_RECORD |
16:52:52 | paulk_ | * 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 | paulk_ | * I've made some minor modifications to francais.lang |
16:52:52 | paulk_ | I think that someone could be interested by those changes, so can I upload them to svn ? |
16:53:17 | AlexP | no, as you don't have access |
16:53:25 | gevaerts | paulk_: no, but you can upload patches to our tracker |
16:53:25 | AlexP | You could put a patch on flyspray though |
16:53:40 | S_a_i_n_t | And since there is now HOTKEY which can already do this...I doubt it even further. |
16:53:44 | kugel | paulk_: I don't think we're interested in the 2nd one |
16:54:16 | AlexP | paulk_: Maybe you should e-mail the dev mailing list and see what people think |
16:54:32 | yorick | gevaerts: FS #8802 works here |
16:54:40 | TabalugaFX | next question: what does the battery time (menu settings > rockbox info) behind the precentage means |
16:55:09 | TabalugaFX | is this the "remaning" battery time? |
16:55:25 | paulk_ | not with mic as input source but with radio as input source : |
16:55:38 | paulk_ | Ok, I'll probably do a patch :) |
16:55:48 | AlexP | TabalugaFX: yes |
16:56:10 | gevaerts | paulk_: don't make one patch for all of those, unless you want to make sure it's rejected... |
16:56:51 | TabalugaFX | @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 | AlexP | That means it hasn't been calibrated |
16:57:15 | AlexP | A stupidly high value is shown to make it clear that it is wrong |
16:57:30 | paulk_ | No : one patch for francais.lang and one for radio.c/keymap |
16:57:57 | AlexP | In recent builds I *think* it shows 0 or something like that if it hasn't been calibrated |
16:58:02 | TabalugaFX | ah, now i understand. and how can i calibrate it |
16:58:12 | AlexP | What player? |
16:58:26 | TabalugaFX | iriver h10 6gb ums |
16:58:40 | AlexP | 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 | TabalugaFX | i can submit mine if you want |
16:59:42 | AlexP | TabalugaFX: See http://www.rockbox.org/wiki/BatteryRuntime |
17:00 |
17:00:09 | AlexP | for the conditions to do one, and then yes if you could submit one that would be helpful :) |
17:00:56 | gevaerts | 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 | AlexP | It should be with reset settings too, to make sure things like the EQ are off |
17:02:13 | TabalugaFX | 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 | AlexP | cool |
17:02:29 | AlexP | That'd be useful then |
17:02:49 | *** | Saving seen data "./dancer.seen" |
17:02:51 | AlexP | Could you attach it to http://www.rockbox.org/wiki/IriverRuntime |
17:03:00 | TabalugaFX | 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 | gevaerts | 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 | TabalugaFX | @alexp: sorry i can't sttach my battery bench cause "access denied" |
17:10:16 | kugel | funman: ping |
17:10:20 | funman | pong |
17:10:25 | TabalugaFX | pung |
17:10:26 | kugel | we have 1MB iram right? |
17:10:52 | funman | right, i only tested on Clip+ though |
17:10:54 | kugel | (on as3525v2) |
17:10:56 | AlexP | TabalugaFX: You need to ask in here for write access after registering |
17:11:19 | AlexP | What is your wiki name? |
17:11:27 | TabalugaFX | SvenManfredKuhne |
17:11:43 | funman | 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 | yorick | gevaerts: no |
17:12:27 | funman | 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 | AlexP | 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 | TabalugaFX | ok, thanks, i'll try again |
17:13:00 | FlynDice | funman: We're running PCLK at 24 MHz for clip+/v2 and 60 MHz for fuzev2 <−−−−is this correct? |
17:13:11 | funman | yep |
17:13:12 | | Join Eugenpaul [0] (~ugnpaul@215.193.32.95.dsl-dynamic.vsi.ru) |
17:13:26 | funman | although it's not exactly 24MHz when we switch frequency |
17:13:38 | yorick | gevaerts: nope, untrue |
17:13:50 | kugel | btw, my fuzev2 shows 240MHz after boot even if unboosted |
17:13:54 | | Part Eugenpaul |
17:13:56 | gevaerts | yorick: ok |
17:13:58 | funman | yeah i didn't modify debug menu |
17:14:14 | kugel | test_fps also assumes 240MHz |
17:14:30 | FlynDice | I just modified debug page and will commit it soon |
17:14:48 | kugel | funman: I think I verified 1MB on my fuzev2 (by modifying test_mem a tad bit) |
17:15:06 | yorick | gevaerts: hmm...it just switched mid-track after switching theme |
17:15:19 | gevaerts | yorick: yes, I've seen that too |
17:15:22 | kugel | at least (512k-65k)*2 fits into the plugin iram. 0x20000 bytes is for the core |
17:15:35 | kugel | both together is pretty much 1MB |
17:15:48 | funman | which is faster: iram or dram? |
17:15:49 | kugel | and i don't get a crash or something |
17:15:59 | TabalugaFX | @ alexp: ok, ive attached it |
17:16:06 | kugel | iram is a bit faster, not so much when unboosted but about 50% when boosted |
17:16:37 | kugel | 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 | AlexP | TabalugaFX: Thanks, hopefully someone will have a look |
17:17:10 | kugel | maybe saratoga shares his test_mem changes for more accurate numbers |
17:17:25 | TabalugaFX | yes this would be great |
17:17:51 | kugel | we could probably still reserve 128kB or so for the core, 1MB is hardly needed for codecs |
17:18:08 | TabalugaFX | btw is there a way i can calibrate it mysel to show the right remaining time |
17:18:18 | funman | kugel: i think the core+plugins don't even need 128kb |
17:18:41 | kugel | plugins share codec iram |
17:19:16 | kugel | 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 | TabalugaFX | and when my rockbox voice tell me "battery level 50%" is this the right time / value instead) |
17:19:50 | kugel | (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 | AlexP | TabalugaFX: You would have to edit one of the source files then recompile |
17:20:40 | funman | FlynDice: nothing in the SD driver depends on pclk ? |
17:21:14 | TabalugaFX | phew. this would be my 1st rockbox cimpiling steps. but i'll try it |
17:21:34 | AlexP | It isn't too bad really :) |
17:21:41 | TabalugaFX | btw you need to update your doom wad file archive, cause a new freedoom version is out there |
17:22:00 | TabalugaFX | and if i have time i want tu update your icons archive |
17:22:02 | AlexP | Does it work properly on Rockbox? |
17:22:14 | AlexP | Which icons archive? |
17:22:16 | TabalugaFX | cause some of them won't work right |
17:22:19 | kugel | 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 | CIA-5 | New commit by funman (r25485): as3525v2: show the correct freqs in debug menu, CGU_PERI uses fclk as source |
17:22:40 | TabalugaFX | extras > icon setgallery |
17:22:40 | kugel | the most common codecs (mp3, ogg, wma) nee about 20-25MHz |
17:22:43 | AlexP | The gallery? |
17:22:50 | AlexP | Yeah, that is user contributed anyway |
17:22:51 | TabalugaFX | yes |
17:23:10 | funman | kugel: check if display is fast enough, I didn't tested after switching to RGB565SWAPPED pixel format |
17:23:21 | FlynDice | 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 | S_a_i_n_t | TabalugaFX: the icons thing is a known bug. |
17:23:44 | funman | perhaps there's 1 clock for the controller and 1 clock for the card ? |
17:23:44 | S_a_i_n_t | I found it a while ago. |
17:23:48 | kugel | funman: I actually meant that the CPU frequency debug menu shows 240MHz |
17:23:49 | funman | 1 for each card rather |
17:23:54 | AlexP | S_a_i_n_t: Is it on flyspray? |
17:23:58 | TabalugaFX | no, you only need to adjust the cfg files right |
17:23:59 | S_a_i_n_t | yep |
17:24:09 | AlexP | goody :) |
17:24:27 | S_a_i_n_t | Viewer icons apply incorrectly (or similar) |
17:24:28 | funman | kugel: ah i've seen that too |
17:24:41 | TabalugaFX | cause afer that i can use all of them (expect the larger ones look very large for my small display) |
17:24:43 | S_a_i_n_t | dont remember the FS# offhand sorry |
17:24:45 | funman | if i press right it shows a good value |
17:24:46 | kugel | sansafuze.h still defines CPU_FREQ to 240MHz if that matters |
17:24:56 | funman | sometimes |
17:25:05 | TabalugaFX | yes you need to crate *.icons file |
17:25:13 | TabalugaFX | and all goes right |
17:25:24 | S_a_i_n_t | TabalugaFX: even then, some just *don't* show |
17:25:32 | TabalugaFX | really? |
17:25:40 | S_a_i_n_t | trust me...my icons file has ~250 filetypes ;) |
17:25:44 | TabalugaFX | whoa |
17:25:50 | TabalugaFX | please share with us |
17:25:51 | S_a_i_n_t | hehe |
17:25:58 | TabalugaFX | but why so many |
17:26:03 | TabalugaFX | or much |
17:26:34 | S_a_i_n_t | 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 | S_a_i_n_t | (goes with the theme) |
17:27:00 | TabalugaFX | ok i'l take a look inside |
17:27:23 | TabalugaFX | nxt theme i want to "remake" is the pen&paper for h10 |
17:27:26 | S_a_i_n_t | you could easlily edit it to point to whichever icon you want though. |
17:27:43 | S_a_i_n_t | *icon(s) |
17:28:35 | TabalugaFX | ok thanks for the details. btw why the transparency vaule won't work for some icons |
17:29:01 | S_a_i_n_t | just displays a black square? |
17:29:15 | kugel | 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 | funman | 36 or 48? |
17:29:38 | TabalugaFX | 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_a_i_n_t | s/w? |
17:30:03 | funman | hm no |
17:30:12 | | Join efgpinto [0] (~ei07061@aulas-i-p2.fe.up.pt) |
17:30:21 | funman | 30, 34.29, 40 |
17:30:22 | | Nick YPSY is now known as Ypsy (~ypsy@geekpadawan.de) |
17:30:24 | kugel | funman: 36 would work nice I think. the fps should at least be above 50 imo |
17:30:28 | TabalugaFX | sorry i mean black & white for (s/w) )and not the background. so I reated my own tago greyscae icons |
17:30:58 | S_a_i_n_t | black & white has no transparency IIRC |
17:31:27 | bertrik | 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 | funman | kugel: it must be a fraction of 240 (down to 240/16 == 15MHz) |
17:31:48 | funman | bertrik: we don't know how to change the PLL freq |
17:32:25 | TabalugaFX | but the rockbox default icons are black&white and transparency works here |
17:32:45 | kugel | funman: does clock target handle fractional frequencies? |
17:33:05 | | Quit pamaury (Quit: Page closed) |
17:33:08 | funman | 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 | kugel | how can I double check the divider that's calulated? |
17:33:49 | funman | disasm |
17:34:12 | kugel | there's no #define for it? |
17:34:33 | FlynDice | you can look on the debug page if you can boot it ok |
17:34:36 | S_a_i_n_t | 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 | TabalugaFX | ok, so i need to change the mono icons to color and set the transparency value by myself |
17:35:45 | S_a_i_n_t | that seems sane, so yes, probably. |
17:35:45 | | Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) |
17:36:25 | funman | hm 24MHz is just not enough for mp3 :) |
17:36:27 | | Join efgpinto [0] (~ei07061@aulas-i-p2.fe.up.pt) |
17:36:32 | TabalugaFX | ok, than i have done this already inside my "simple theme grey" which includes my created tango greyscaled icons |
17:37:05 | S_a_i_n_t | 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 | S_a_i_n_t | so, doesn't show as transparent on colour targets. |
17:37:34 | pixelma | 1-bit mono bitmaps use foreground and background colours on colour targets too |
17:37:39 | kugel | 34285715 seems to work |
17:38:33 | yorick | hmm the matrix effect is a bit silly here |
17:38:41 | yorick | it's moving on the beat of the music |
17:39:01 | pixelma | this works on greyscale too (in the WPS where you can have different foreground and background shades with viewports |
17:39:12 | pixelma | ) |
17:39:23 | kugel | funman: I think I could live ok with 34.3MHz, let me try 40 too |
17:39:42 | S_a_i_n_t | I knew a non-colour target themer would chime in eventually ;) |
17:39:55 | funman | kugel: the e200v1 framerate is awfully fast at 24MHz :( |
17:40:08 | TabalugaFX | 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 | kugel | that's because the e200v1 cheats |
17:40:17 | funman | oh? |
17:40:30 | pixelma | S_a_i_n_t: what? I use this in my c200 WPS too |
17:40:41 | kugel | it memcpy's the framebuffer to another one where the lcd driver auto-reloads from automagically |
17:41:07 | S_a_i_n_t | pixelma: yes, but you also understand how the mono targets work better than I ;) |
17:41:30 | AlexP | TabalugaFX: Not yet |
17:41:39 | | Join Kitr88 [0] (~Kitr88@BSN-142-95-35.dial-up.dsl.siol.net) |
17:42:56 | TabalugaFX | 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 | AlexP | 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 | gevaerts | 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 | kugel | 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 | TabalugaFX | 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 | funman | nice |
17:46:14 | kugel | while the clock speed is only increased by 16.6% |
17:46:36 | yorick | gevaerts: low? |
17:46:39 | funman | disabling switching doesn't crash (at least less quickly), but i'm not sure how to switch nicely |
17:46:52 | yorick | gevaerts: that makes my favourite theme unusable :p |
17:47:04 | kugel | maybe you checkout the frequencies too, I'd almost vote for 40MHz, but I wouldn't die with 34.3 |
17:47:08 | funman | the OF crudely iterates over dividers to keep pclk very approximately close to the desired value as fclk changes |
17:47:14 | CIA-5 | New commit by amiconn (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 | gevaerts | yorick: well, I left those at the default values. People tend to ignore them anyway |
17:47:54 | yorick | gevaerts: tend :p |
17:47:59 | bertrik | funman, I suppose they first reduce the pclk, then increase fclk, right? |
17:48:11 | kugel | I'd say 34.3 feels about the same as unboosted on a e200v1 ui-wise |
17:49:42 | funman | bertrik: http://forums.rockbox.org/index.php?topic=14064.msg163547#msg163547 < they modify both in a loop |
17:50:00 | gevaerts | 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 | funman | in this function they are boosting |
17:51:01 | | Quit jd (Ping timeout: 265 seconds) |
17:51:18 | AlexP | 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 | TabalugaFX | 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 | AlexP | Heh, you are welcome :) |
17:51:55 | TabalugaFX | and sure, I'll help where can |
17:51:56 | S_a_i_n_t | cya TabalugaFX |
17:52:09 | yorick | AlexP: it's probably some feature the theme uses |
17:52:13 | TabalugaFX | to support and promote |
17:52:20 | TabalugaFX | bye |
17:52:26 | TabalugaFX | ...logging off.. |
17:52:38 | | Quit TabalugaFX (Quit: CGI:IRC) |
17:52:45 | kugel | funman: what do you think about my codec buffer idea? |
17:52:46 | AlexP | yorick: Yeah, but it still isn't critical or high, like playback not working |
17:53:13 | funman | 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 | kugel | it's faster :p |
17:53:37 | S_a_i_n_t | As long as rockbox_defalut loads, music plays, and plugins work...all is well with the world ;D |
17:53:37 | kugel | but really only when boosted it seems |
17:53:50 | | Quit Xerion (Read error: Connection reset by peer) |
17:54:03 | gevaerts | AlexP: I consider the fact that this bug is even possible to be a bit frightening though |
17:54:23 | kugel | 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 | funman | kugel: try with ape first |
17:54:39 | S_a_i_n_t | gevaerts: very true...looking at the code its VERy hard to pick what the heck is going on there. |
17:54:41 | AlexP | It is all academic anyway as we don't use the rating thing |
17:55:24 | S_a_i_n_t | (code for the theme that is) |
17:55:42 | kugel | funman: nobody uses ape... |
17:55:49 | FlynDice | clip+ is getting random freezup for everyone and not just me correct? |
17:56:14 | funman | FlynDice: yep, keeping it boosted (or unboosted but you need to patch) should work around it |
17:56:24 | funman | kugel: perhaps but we still support it |
17:56:37 | kugel | funman: smaller pcm buffer doesn't mean ape will not work |
17:57:00 | FlynDice | 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 | kugel | just that it *maybe* boosts more often which is the case with ape anyway |
17:57:14 | * | FlynDice keeps fingers crossed |
17:57:21 | funman | depends if filling it takes more time than what's available in the buffer |
17:57:58 | kugel | ape data aborts apparently |
17:58:17 | funman | 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 | FlynDice | 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 |
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 | kugel | 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 | funman | 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 | yorick | battery 95% 195h 0m |
18:03:43 | yorick | hmm |
18:03:55 | yorick | I think it's supposed to be charging |
18:04:01 | yorick | it was 96% just then |
18:04:09 | | Part lImbus |
18:04:10 | yorick | and the charger icon is showing |
18:04:57 | | Join komputes [0] (~komputes@ubuntu/member/komputes) |
18:05:10 | FlynDice | crap, just froze :( Seems to be an SD access issue as the LED icon is illuminated |
18:05:19 | S_a_i_n_t | yorick: Is there a question in there? |
18:05:21 | funman | grmbl |
18:05:37 | yorick | S_a_i_n_t: how do I fix the 195h |
18:05:51 | S_a_i_n_t | its nothing you can "fix" |
18:06:03 | S_a_i_n_t | submit a battery bench using the criteria on the wiki |
18:06:03 | funman | with 24/240MHz we can switch while staying between 13.3MHz and 30MHz |
18:06:20 | kugel | any reason we use the DRAM_FREQ for defining the cpu freq? |
18:06:22 | S_a_i_n_t | it will help toward calibrating the battery for your player. |
18:06:56 | funman | kugel: we use PCLK (which is equal to DRAM_FREQ, unless you set bit 6 of CGU_PERI on amsv1) |
18:07:41 | CIA-5 | New commit by amiconn (r25487): Set options so that the sim actually builds on Opensolaris. The build still throws hundreds of warnings. |
18:07:46 | FlynDice | back later.. |
18:09:41 | yorick | at best it's only 10 times too much |
18:09:49 | CIA-5 | New commit by kugel (r25488): Add T for plugins to the advanced build options to build all test_* plugins. |
18:09:53 | CIA-5 | New commit by kugel (r25489): Fuzev2: Use 40MHz as unboosted frequency. The lcd speed and ui responsiveness is good at this freq. |
18:11:51 | CIA-5 | New commit by kugel (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 | funman | FlynDice: i'm testing http://pastie.org/903960 on Clip+ |
18:21:55 | linuxstb | 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 | kugel | hrm, probably |
18:22:43 | kugel | I didn't go through all possible combinations and I may have forgotten something |
18:23:05 | funman | i suppose the peripherals running off pclk are DMA and i2c |
18:23:24 | funman | dbop |
18:23:45 | funman | ssp |
18:24:02 | funman | but for dbop & ssp it shouldn't matter |
18:25:20 | funman | i don't see clock requirements for dma |
18:25:44 | bertrik | I often thought it would be nice to have multiple boost levels |
18:26:26 | linuxstb | 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 | funman | 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 | funman | bertrik: saratoga suggested the same thing |
18:27:47 | amiconn | 400kHz is already i2c "fast mode" |
18:27:57 | funman | amiconn: yes so we shouldn't go faster |
18:28:01 | amiconn | Standard mode is <= 100kHz. Afaik there is no lower limit |
18:28:07 | funman | ah |
18:28:24 | amiconn | But basically all i2c devices support fast mode nowadays |
18:28:50 | funman | as3525 datasheet quotes "supports standard (100 kbps) and fast speed (400kbps)" |
18:28:55 | amiconn | There's one notable exception among the rockbox targets: The m3's button controller (a pic) doesn't |
18:29:05 | amiconn | 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 | ThomasAH | funman: do you expect the crashes to go away with http://pastie.org/903960? |
18:33:49 | funman | nope it's buggy (see above) |
18:33:58 | funman | 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 | Antibuddha | how hard would it be to rockbox an mp3 player like cowon q5w? |
18:41:18 | Antibuddha | i just got one off ebay but im afraid it will be crap without rockbox |
18:42:19 | yorick | not easy |
18:42:21 | S_a_i_n_t | Well...its either a LOT of work, or you could hold your breath. Possibly indefinitely. |
18:42:29 | Antibuddha | ok |
18:42:29 | stripwax | 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 | Antibuddha | hmm forget that then, anyone know how to test if an spdif is resampled to 48khz? |
18:43:15 | stripwax | Antibuddha - (wiki link by the way is http://www.rockbox.org/wiki/NewPort) |
18:43:27 | Antibuddha | 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 | stripwax | 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 | yorick | :o @ gapless playback in practice |
18:55:15 | funman | 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 | funman | we might even calculate the intermediate value with awful macros :) |
18:59:49 | funman | PANIC read multiple blocks failed (Clip+ µSD) |
19:00 |
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 | funman | 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 | gevaerts | moos: is boot speed back to normal for you now? |
19:09:20 | moos | 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 | funman | 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 | funman | as3525 datasheet says "Clock gating takes effect immediately!" (for CGU_PERI though) |
19:25:03 | funman | 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 | funman | linux for as3525(v1) doesn't show any delay after modifying either CGU_PROC either CGU_PERI |
19:35:11 | freddyb | funman: is there a different datasheet for Sansa v2's? |
19:35:21 | funman | no |
19:35:56 | funman | hum well there is a datasheet for the Sansa *AMS* v1, not for the Sansa *AMS* v2 |
19:36:33 | funman | AMS v1 were previously called "Sansa v2" so just to confirm, you're speaking about Clip+/Clipv2/Fuzev2 ? |
19:37:32 | freddyb | 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 | funman | FlynDice: ThomasAH http://pastie.org/904095 |
19:41:32 | funman | 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 | funman | 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 | funman | you're already familiar with that :P |
19:43:17 | freddyb | Did you break it by loafing in the higher interrupts? :p |
19:43:59 | freddyb | I'll take a look. |
19:44:36 | funman | nope i'm not sure what happened |
19:45:05 | funman | i just looked on my fuzev2 and it seems to work.. (not using latest rev though) |
19:45:39 | funman | 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 | funman | 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 |
20:00:37 | kugel | 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 | kugel | something wrong with it? |
20:03:52 | | Quit Horscht (Quit: Verlassend) |
20:05:01 | funman | hm ok |
20:05:13 | funman | yeah we initialize CPU to boosted |
20:05:28 | funman | 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 | funman | well it's the first thing after system_init()/kernel_init() |
20:06:59 | kugel | it can be reverted if it's wrong, I thought that causes the wrong freq to be displayed |
20:07:47 | funman | whatever you prefer, if it's in sync with system_init() and with other targets for consistency and |
20:08:29 | funman | btw AMSv1 still say 250MHz in their config file but debug menu is fine |
20:09:30 | funman | so mind = blown |
20:09:35 | kugel | hehe |
20:09:57 | kugel | I think it worked before your today's fix actually |
20:10:39 | funman | i had seen it yesterday iirc |
20:10:48 | funman | you meant r25475 ? |
20:11:59 | | Join kadoban [0] (~mud@cpe-67-247-80-129.rochester.res.rr.com) |
20:12:11 | kugel | yes |
20:12:16 | kugel | but I don't know for sure |
20:14:46 | funman | 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 | funman | 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 | funman | kugel: ok for http://pastie.org/904153 ? it shows 40MHz in the debug screen after boot |
20:18:58 | kugel | that's simply reverting...why does it work for 40 but not for 60? |
20:19:38 | kugel | s/unbearable/unbearably/ as linuxstb while you're at it :P |
20:19:44 | funman | already done :D |
20:20:14 | | Quit n1s (Quit: Lämnar) |
20:20:20 | funman | 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 | funman | 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 | funman | 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 | funman | mind = ultra blown. 60MHz freq is showed in the debug menu if i enable boost logging |
20:42:49 | kugel | :p |
20:42:59 | kugel | your mind is clearly suffering lately :) |
20:43:12 | funman | :P |
20:43:24 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
20:43:59 | | Quit pamaury (Quit: Page closed) |
20:45:46 | mandred | 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 | kugel | funman: codec buffer to iram patch: 1MB more audiobuffer |
20:47:56 | funman | mandred: you should just follow the steps on SansaAMS wiki page |
20:47:57 | kugel | mandred: have you installe a bootloaer? |
20:48:38 | mandred | I followed those in the clip+ manual, thye seemed to be the same. |
20:49:33 | mandred | bootloader being the clippa.bin renamed from patched.bin? |
20:49:55 | funman | clppa, not clIppa |
20:50:31 | mandred | Aha, my mistake. Thank you. |
20:51:15 | mandred | Ah actually doing the firmware upgrade now. Thanks. |
20:53:03 | funman | if I remove set_cpu_frequency() call from init() -> correct value again |
20:53:59 | kugel | 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 | saratoga | 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 | funman | head asplode => bed |
20:57:55 | | Quit christoffer (Client Quit) |
20:57:57 | | Quit funman (Quit: free(random());) |
20:58:42 | kugel | 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 | saratoga | in practice 300KB on the clipv1 seems to play almost everything |
20:59:43 | saratoga | its just AAC and Vorbis that can use more then that, and very few files do |
21:00 |
21:00:05 | kugel | are all codecs enabled on the clip? |
21:00:19 | saratoga | very old vorbis files can use more, but few exist, and very long AAC files due to our crummy MP4 parser |
21:00:37 | saratoga | yes they're all enabled, except maybe AAC-HE (can't remember if I disabled it) |
21:01:18 | kugel | ah, all mem related #ifdefs from codecs/SOURCES are removed, I didn't notice |
21:01:56 | kugel | we have plenty iram (1MB) on as3525v2, and I'm going move the entire codec buffer into it |
21:02:08 | saratoga | SBR and PS support are disabled on targets <= 2MB of RAM |
21:02:17 | kugel | but it might be desirable to move some cores stuff into it as well |
21:02:51 | saratoga | 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 | saratoga | MP4 parser I mean |
21:03:01 | kugel | 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 | saratoga | playing with test_mem the results were inconsistent with my changes, so I'm not really sure what was going on |
21:03:40 | saratoga | it might have been a side effect of how pclk was set at the time (IIRC just 6 MHz unboosted) |
21:03:57 | kugel | how inconsistent? |
21:04:12 | ThomasAH | funman: (in case you'll read the log:) I'll try http://pastie.org/904095 and report tomorrow |
21:04:16 | saratoga | i sometimes got a speed up with LDM and sometimes not, which didn't make sense to me |
21:04:26 | saratoga | since LDM shouldn't really be faster on ARM9 |
21:04:42 | saratoga | FWIW unrolling the load loop gave a 4% speedup |
21:04:51 | saratoga | mostly just due to reduced loop overhead, gcc nonsense |
21:04:58 | kugel | I thought ldm is 2+n cycles on arm9 (and ldr always 2)? |
21:05:12 | saratoga | ldr is a single cycle if its not used on the next clock IIRC |
21:05:33 | saratoga | and LDM is a single cycle per address for N>1 and N not used on the next cycle |
21:05:52 | saratoga | LDR 1 1S 1N Normal case, not loading PC. |
21:05:59 | saratoga | so 1 cycle for the normal case |
21:06:13 | saratoga | LDM n 1S+(n-1)I 1N+(n-1)S Loading n registers, n > 1, not loading the PC. |
21:06:56 | kugel | well, the cycle numbers are really only meaningful if the ram isn't too slow aren't they? |
21:07:04 | saratoga | yeah |
21:07:05 | kugel | otherwise, test_mem would be pretty useless |
21:07:13 | saratoga | but test_mem mostly just tests the cache |
21:07:18 | saratoga | which should be 0 cycle |
21:07:26 | kugel | well, that's intended |
21:07:41 | saratoga | 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 | kugel | 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 | saratoga | it tests some combination of pipelining and how quickly the memory can handle cache line refills |
21:08:31 | kugel | I thought about disabling the caches but then the numbers aren't helpful anyway |
21:08:43 | saratoga | a random stride would give you memory access performance |
21:09:03 | saratoga | cache lines are 32 bytes, so if you step 32 bytes at a time you'll get memory everytime |
21:09:13 | saratoga | (on almost all our arm tagets) |
21:09:22 | | Quit stripwax (Ping timeout: 248 seconds) |
21:10:20 | kugel | I was inspecting why lcd update was so slow, and there sequential reads cound |
21:10:40 | kugel | but I'm sure we could improve it further |
21:12:01 | kugel | saratoga: we never had a report that a file can't be played on the clip did we? |
21:13:05 | saratoga | not that I know of |
21:13:21 | saratoga | but I think clip owners probably don't use many exotic files verses some other players |
21:13:34 | saratoga | there are certainly ones that do not play |
21:13:46 | saratoga | any AAC file over about 5-10 minutes should fail |
21:13:56 | saratoga | but i guess no one uses AAC anyway |
21:14:11 | linuxstb | saratoga: The SoC page doesn't mention improviing the MP4 parser (but it's a good idea). |
21:14:18 | saratoga | yes we can add that later |
21:14:23 | saratoga | it should be quite simple I think |
21:14:24 | | Quit merbanan (Read error: Operation timed out) |
21:14:41 | saratoga | 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 | saratoga | basically i just downsampled the seek table and assumed that chunks were stored sequentially in the mp4 stream |
21:15:27 | saratoga | 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 | saratoga | and I've never managed to get a copy of the spec |
21:16:28 | saratoga | i have like every mpeg document ever but not the mp4 one |
21:16:36 | saratoga | because that is the only one the mpeg people decided to hold secret |
21:16:53 | saratoga | because I guess making sure that no software supports MP4 correctly is in their best interest? |
21:18:18 | CIA-5 | New commit by kugel (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 | saratoga | 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 | CIA-5 | New commit by kugel (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 | ThomasAH | funman: r25490 + pastie/904095 + voice menus enabled freezes somewhere between using it for one second and one minute |
21:23:25 | freddyb | Recording on Fuzev2 is much improved by shortening the delays in button-fuzev2.c |
21:23:57 | freddyb | It's gone a few minutes at 44100 now. (I also used gcc -O2, tho.) |
21:24:37 | saratoga | you used what? |
21:24:48 | kugel | freddyb: but the delays probably need to be increased, the lcd is glitchy when boosted atm |
21:25:52 | freddyb | Should the delays be based on the CPU HZ? |
21:27:00 | kugel | they should be independant of the cpu ideally |
21:27:58 | freddyb | Saratoga: Me? |
21:28:32 | saratoga | yeah what did you compile with O2? |
21:28:52 | freddyb | The whole thing except the boot loader. |
21:29:35 | freddyb | 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 | freddyb | Kugel: Sorry if this is a dumb question but can button reading be made interruptible by the audio? |
21:44:55 | kugel | what do you mean? |
21:45:25 | freddyb | 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 | kugel | freddyb: no |
21:47:59 | kugel | 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 | saratoga | 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 | perfectdrug | 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 | CIA-5 | New commit by mcuelenaere (r25493): Add simple bootchart -> gnuplot shell script |
22:00 |
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 | S_a_i_n_t | 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 | S_a_i_n_t | (the bootloader seems to work fine) |
22:07:30 | S_a_i_n_t | Oh, when building a bootloader of course...*duh* |
22:07:35 | gevaerts | 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 | S_a_i_n_t | does it mean anything *bad*? |
22:09:12 | S_a_i_n_t | 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 | gevaerts | this is what #ifdef is for |
22:09:57 | S_a_i_n_t | So, its just shit code? |
22:10:26 | gevaerts | ? |
22:11:01 | S_a_i_n_t | Misinterpreted you there I think...basically, *why* is it complaining? |
22:11:26 | S_a_i_n_t | It still seems to work, but has a cry about building the bootloader. |
22:13:09 | gevaerts | 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 | S_a_i_n_t | 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 | gevaerts | It's *not* used by the bootloader |
22:16:37 | | Join sierra2kilo [0] (~4cab2b3f@giant.haxx.se) |
22:16:44 | gevaerts | (on systems without bootloader usb) |
22:17:00 | gevaerts | Well, probably even on those |
22:17:18 | sierra2kilo | Hey all. Got a quick question about the unstable firmware for the clipv2. |
22:19:19 | sierra2kilo | 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 | gevaerts | domonoky: you know about the theme site, right? The admin bit seems to have some issues |
22:21:21 | gevaerts | sierra2kilo: which checksum precisely? |
22:21:52 | domonoky | gevaerts: yes, i know a bit about the themesite. what is the problem with the admin thing ? |
22:22:15 | gevaerts | 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 | sierra2kilo | gevaerts: On this last install it wants 2A54079 and I got 2A5408D |
22:22:42 | gevaerts | sierra2kilo: "it" being what? |
22:23:38 | sierra2kilo | When it's loading the firmware and it says "Checksum" and then "Sum". |
22:24:33 | | Quit xiainx (Quit: Leaving) |
22:25:10 | gevaerts | 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 | domonoky | 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 | domonoky | you can hide the theme if you search for it first (so it only displays a small amout of themes) |
22:27:50 | gevaerts | Thanks. That works |
22:28:11 | sierra2kilo | gevaerts: I did, the clipv2 file. |
22:29:29 | gevaerts | sierra2kilo: you have a clipv2 and not a clip+? |
22:31:54 | sierra2kilo | Correct |
22:34:11 | gevaerts | What does the bootloader print after "Model name:"? |
22:40:14 | sierra2kilo | Weird. Copied over the .rockbox folder manually and it worked. Crisis averted! |
22:41:59 | sierra2kilo | 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 | CIA-5 | New commit by Blue_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 | stripwax_ | 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 |
23:00:08 | kugel | 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 | shai | 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 | AlexP | 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 | shai | AlexP, how do I do this and check that? |
23:16:11 | AlexP | Try them out? |
23:16:19 | AlexP | The size is in the name |
23:16:24 | shai | When I apply the theme, I can't read the menues... |
23:16:33 | AlexP | But not all fonts have all glyphs |
23:17:08 | | Quit Chronon (Read error: Operation timed out) |
23:17:37 | shai | AlexP, so if I can't read the menues, how can I change them? |
23:17:45 | AlexP | I think there is something about what fonts have what glyphs at rasher.dk/rockbox">http://rasher.dk/rockbox |
23:18:03 | AlexP | Enable voicing, and/or note down how many clicks it takes |
23:18:36 | AlexP | For non-English voicing you'll need to create your own voice files though |
23:18:46 | linuxstb | Or use English, and only switch to hebrew after changing the font. |
23:19:14 | S_a_i_n_t | Isn't the only font for hebrew Unifont? |
23:19:25 | AlexP | I doubt it is the only, no |
23:19:28 | linuxstb | Or you can edit the font name manually in the iPodUbuntu_Plus.cfg file. |
23:19:34 | linuxstb | (from your PC) |
23:19:46 | shai | Worked like a charm :) linuxstb |
23:20:15 | | Quit liar (Remote host closed the connection) |
23:20:28 | shai | 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 | AlexP | S_a_i_n_t: As a note, please don't guess if you don't know, it only confuses things |
23:21:43 | shai | 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 | linuxstb | 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 | AlexP | 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 | linuxstb | I guess the initial problem is that the resume is in nvram.bin (or real NVRAM) |
23:30:41 | AlexP | yeah |
23:31:09 | linuxstb | Let's just stop people deleting files - it causes all sorts of problems.... |
23:31:36 | AlexP | You can only delete files if all resume info and playlists are wiped at the same time :) |
23:31:51 | linuxstb | So let's only support MTP, where we can control that... |
23:33:10 | * | AlexP slaps linuxstb |
23:33:25 | AlexP | never! |
23:34:36 | linuxstb | 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 | AlexP | Indeed, which I think is why nobody has done this yet - it needs a little thinking about |
23:36:20 | pixelma | it's also that not storing filenames is what makes resume real quick |
23:36:45 | AlexP | 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 | linuxstb | 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 | AlexP | 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 | AlexP | shameless plagerism :) |
23:38:49 | linuxstb | s/plagerism/collaboration/ |
23:39:10 | AlexP | 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 | kugel | 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 | linuxstb | kugel: I would say either duplicate it, or remove it from our template. |
23:49:18 | kugel | I'll duplicate then because we're asked to follow the template closly |
23:49:25 | kwbr | would it be possible to synchronise the time of my rockbox device with my desktop computer? |
23:49:39 | linuxstb | kwbr: That depends on your device. What is it? |
23:50:10 | kwbr | ipod, video |
23:51:13 | kwbr | linuxstb: I use rockbox-ipodvideo64mb.zip |
23:51:17 | linuxstb | Then yes. |
23:51:55 | kwbr | linuxstb: cool. How would I do that? |
23:52:17 | linuxstb | What OS do you use? |
23:52:24 | kwbr | linuxstb: I am on linux |
23:53:57 | gevaerts | 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 | kwbr | thanks. I'll try that |
23:56:23 | Strife89 | Is there a comparable tool for Windows? |
23:56:25 | amiconn | 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 | amiconn | Oh, also if it'S non-cacheable |
23:57:46 | kugel | shall I make it public? |
23:57:49 | gevaerts | Strife89: no idea. Maybe rbutil could be taught to to it, it already does raw scsi commands... |
23:57:55 | kugel | it = the application |
23:58:29 | Strife89 | gevaerts: Definitely a nifty project to try. |