--- Log for 09.02.111 Server: holmes.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 19 hours and 46 minutes ago 00.00.04 # I just feel if there were objections before, at least a *strong* attempt should've been made to contact the objectors. 00.00.13 # thomasjfox: done 00.00.15 # thomasjfox: is sunday a special date? 00.00.16 # I objected to the initial commit of autoresume too. 00.00.29 # kugel: See the ML :o) 00.00.47 # ah, the freeze? 00.00.51 # yes :) 00.01.31 Quit mlt- (Quit: CGI:IRC) 00.01.58 # gevaerts: thanks 00.03.36 # BORING.... Llorean, you arnet here 24/7 anymore, you arnt in -community much anymore either.... how is anyone supposed to know the difference between activly leaving and just just being silent 00.03.57 # you shouldnt have disspapeared while an arguent was happening which you were involved in 00.04.11 # JdGordon1: I'm sorry I had oral surgery 00.04.21 # Llorean: Several objections of various people have been addressed, including complexity of configuration, wording of the config options, and lang-related stuff. Here's part of the IRC discussion I mentioned: http://www.rockbox.org/irc/log-20110128#14:41:57 00.04.22 # In the future I'll schedule my two cubic centimeter cysts around our discussions. 00.04.46 # thank you 00.04.50 # that would be appreciated 00.05.24 # Llorean: we couldn't know that, for us you were just silent/gone inactive 00.06.15 # kugel: Yes, but the fact that there wasn't *any* further discussion on the ML (the initial venue of discussion) doesn't help at all. 00.07.31 # * Llorean learns from the linked discussion that the comma separated list will match "pod" to the podcasts folder, and thinks it's terribly easy to get false positives. 00.07.50 # Llorean: /pod/ won't 00.08.54 # gevaerts: My concern is genre tags, which don't typically contain characters that make it easy to exclude folders. 00.09.10 Quit bertrik (Read error: Operation timed out) 00.09.16 # Ah, right. That trick won't work there, true 00.09.22 # * gevaerts is too tired to think straight 00.09.26 # gevaerts: For example, the genre "voice" isn't uncommon for things I might want to resume, but "voice" is a word that could easily show up in album names, and thus folders 00.09.47 # In fact I wouldn't be surprised if my player already has content that would be fouled up by this. 00.10.06 # are *you* going to use the feature at all? 00.10.43 # JdGordon1: No, clearly not, that's why I spent so long trying to discuss how we could meet both his needs and my needs with it. The fact that I have desires and needs for the features doesn't in any way indicate I would use it, of course. 00.11.44 # If I weren't going to use it, I'd have either said "I object to the bloat of it" if I thought nobody would use it, or "as long as there's an off switch, I don't care." 00.13.30 # Llorean: There's no reason we cannot add support for your use case as well. I just wasn't willing to give up my major use case for yours. Sorry. 00.13.52 *** Saving seen data "./dancer.seen" 00.14.18 # sideral: The majority of your use case was addressed just fine, it was just manual instead of automated... 00.14.24 # That's not giving up your use case. 00.14.46 # Llorean: I didn't say majority of use case, but major (as in most important) use case 00.15.17 # Llorean: we are not stopping you from implementing the context menu item and deactivating autoresume 00.15.24 # sideral: And the most important thing to me is that it's not automatic. 00.15.53 # kugel: You know I cannot realistically remove an existing feature days or weeks down the line. 00.15.54 # Llorean: Fine, turn it off then. Then let's add a context menu for manual resume operation 00.16.11 # Llorean: by deactivating I meant in the settings, not in the code 00.16.13 # sideral: Then you've got overlapping features. 00.16.42 # sideral: I didn't see any sort of significant evidence of changed opinions in that link. Mostly you talking with gevaerts and kugel. 00.16.43 # Llorean: I disagree. You get two ways (manual+automatic) to get at the same feature 00.16.58 Quit thomasjfox (Remote host closed the connection) 00.17.21 # sideral: And most of Rockbox is not automated. 00.17.34 # thats nonesense 00.17.51 # just about everything IS atomated 00.18.00 # JdGordon1: Rockbox doesn't have any automated system for turning on or off *any* other setting I think 00.18.22 # JdGordon1: How do I automate whether or not a folder is shuffled when I play it? Or whether or not to use EQ? Or...? 00.18.23 # that's not what you said, and thats incorrect anyway 00.18.46 # JdGordon1: If "use autoresume automatically" is automation, then *not* toggling settings automatically qualifies as parts of the system that aren't automated. 00.19.57 # Or, rather than saying "toggling settings automatically" we could say "automatically selecting whether to use settings during playback of specific files" 00.20.13 # Since, strictly speaking, the setting isn't actually *changed* just applied or not 00.20.18 # I actually thought a shuffle. file would be nice to automatically shuffle folders 00.20.27 Quit GeekSh4dow (Quit: The cake is a lie !) 00.20.48 Quit Jerom (Quit: Leaving.) 00.20.59 # * JdGordon1 points out that any sane argument would remind everyone that having folder/playlist based .cfg files is a strict nodo 00.21.00 # kugel: If we were to do that, wouldn't a .canresume file make sense for marking folders (and thus all their subfolders) resumable, rather than a comma separated list? 00.21.05 # It'd be very similar to database.ignore 00.21.07 # well, folder anyway 00.21.27 # JdGordon1: Yes, so there's a strict nodo for folder based application of *most* settings, but not this one. 00.21.27 # Llorean: I do not agree that you have sufficiently demonstrated that the feature "does not fit" into Rockbox. 00.21.34 # JdGordon1: shuffling without toggling the setting 00.21.50 # no setting should be toggled by something else then the user IMO 00.21.53 # sideral: So express for me some similar features, since JdGordon1 very nicely expressed a nodo that's very similar to this feature you've just committed. 00.22.27 # "just" being a week ago? 00.22.28 # You said any setting was being toggled automatically, which is clearly not the case. 00.23.19 # JdGordon1: I have it as 20:31 today 00.23.33 # sideral: No, I clarified that the setting is being *applied* automatically. 00.23.44 # * JdGordon1 has absolutly no idea what those commits acheive 00.23.57 Quit liar (Read error: No route to host) 00.24.02 # sideral: I hope you created a task to add it to the manual? :D 00.24.05 # JdGordon1: Not the auto-resume, but the ones that add settings for using a comma separated list of search terms to determine which files to auto-resume on and which not to. 00.24.22 # JdGordon: that's on my todo list 00.24.42 # Llorean: No, that's not what the setting does. 00.24.57 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 00.25.15 # Llorean: well, the nodo i mentinoed was because of the file check, not necessarily for the autosetting changing 00.25.17 # sideral: "Tracks can be selected based on their their file location or genre tag (comma-separated list of filename / genre substrings)" 00.25.33 # JdGordon1: Really? Most objections I'd heard to it was because of the setting changing. 00.25.44 Quit evilnick_B (Quit: Page closed) 00.25.45 # JdGordon1: It's not like playlists and playback don't regularly open files... 00.25.58 # it toggles whether automatic track change triggers resume for the next track depending on a user-defined set of tracks 00.26.11 # JdGordon1: why is that a nodo? 00.26.11 # Yes, whether the setting applies based on automation. 00.26.14 # the settings are all static. 00.26.28 # This is nitpicking 00.26.42 # sideral: So it's not automation? 00.27.19 Quit LambdaCalculus37 (Quit: Clunk) 00.27.40 # Sure it is automation. But it's not the settings that are dynamic. It's the behavior, as configured by a (static) user setting. 00.28.11 # Yes, exactly as would be by static files that determined which settings are applied to a given folder (which as JdGordon1 just pointed out, is more or less a NoDo) 00.29.12 # It has even been proposed that these files not be able to permanently change settings, but only change them until that folder is left, or playback is stopped, being a similar "only for this session/selection" thing as yours, and still rejected 00.29.24 # So I'd ask why this kind of automation is okay for autoresume, but not for any other setting. 00.30.33 # I don't care about that nodo, and see no significant overlap with autoresume. Nothing of this is risking the integrity of the software or user experience. 00.30.55 # sideral: So you're choosing to ignore an existing nodo, or do you mean you think you can explain how it's not parallel? 00.31.07 # Llorean: I honestly can't see your point 00.31.31 # kugel: You think there's no parallel between "use automation to determine whether or not to apply autoresume" and "use automation to determine whether or not to apply other settings"? 00.31.34 # I didn't understand the similarity in the first place. 00.31.36 # Or you don't see why that's valid? 00.31.57 # both 00.32.06 # sideral: Your feature uses automation to determine whether or not to apply a feature (autoresume), but the option to use automation to determine whether or not to apply *any* setting has been rejected. 00.32.10 # well the 2nd is a given if the first is true 00.32.15 # The principle you state has no benefit as is. 00.32.19 # kugel: How can you think you can judge if it's valid or not, if you don't understand it? 00.32.39 # who said I don't understand it? 00.32.44 # sideral: What principal. 00.33.06 # the user clearly made a decission on what to apply automation on. what's wrong with that? 00.33.20 # kugel: Well if you don't see it the way I do, in terms of existing as a parallel, your judgment is on something I'm not saying, so it doesn't bear any meaning in rejecting my claim. 00.33.31 # kugel: The user clearly makes a decision what to apply automation on in the NoDo case too... 00.33.37 # It's just as explicit 00.33.39 # Moreso actually 00.33.41 # what nodo? 00.33.47 # kugel: The one JdGordon1 referenced. 00.33.57 # it's a nodo for him 00.34.09 # we only have one official nodo list 00.34.27 Join Keripo [0] (~Keripo@eng442.wireless-resnet.upenn.edu) 00.34.48 # as I said, I actually would like a feature that shuffled the selected folder if it has a shuffle. file in it 00.34.52 # Llorean: It doesn't make sense to state that filtering settings by some definition of a subset of files is bad per se. There has to be a case-by-case analysis. 00.35.04 # Clearly podcasts != audiobooks != music albums 00.35.07 # (for the folder only, without changing the setting that is) 00.35.17 # kugel: It's also been rejected many, MANY times in the past, though. It may not be a nodo, but the same reasoning for rejecting it applies to this. 00.35.36 # if it's not on the nodo list, it's not a nodo. period 00.35.44 # we discussed that on the devcon 00.35.48 # sideral: Or you could not automate it, so that the filtering isn't necessary. You haven't addressed how yours doesnt parallel an often rejected feature idea. 00.36.17 # database.ignore has been in for years now 00.36.18 # kugel: Yes, so it's not a nodo. That doesn't change that the reasoning for rejecting it also applies to this. 00.36.24 Quit elcan (Read error: Operation timed out) 00.36.39 # Llorean: I frankly don't care whether my feature _does not_ parallel another often rejected feature idea. Sorry. 00.37.10 # sideral: Well, if the other feature was rejected, and yours parallels, why shouldn't yours be rejected? 00.37.17 # also prevent clipping, track gain if album gain isn't available too 00.37.43 # there's a number of setting/files that toggle some automation. I don't see anything wrong with this 00.37.52 Join elcan [0] (user36@pr0.us) 00.37.55 # kugel: That's part of the replaygain feature standard though. 00.37.59 # I contend there's no parallel. And my personal opinion is that you cannot generalize from negative examples and create principles out of them. 00.38.08 # That's like saying "bass boost is automation because it automatically determines which frequencies to boost" 00.38.21 # sideral: Explain how there's not a parallel then? 00.38.47 # loud users dont get to dictate feature inclusions 00.38.55 # Llorean: No I won't, because it doesn't serve any purpose as I just tried to explain 00.38.56 # sideral: If the same *reason* applies to both features, because of the parallel, you can generalize. 00.39.02 Join froggyman_ [0] (~seth@98.115.0.7) 00.39.14 # sideral: If we say "we don't want that because we shouldn't automate that sort of behaviour" and your patch *automates that sort of behaviour*... 00.39.21 Quit froggyman (Quit: Ex-Chat) 00.39.39 # Then it applies as a valid reason to reject yours, and you can explain how yours doesn't automate that sort of behaviour to counter it, rather than saying "it doesn't apply because I say it doesn't" 00.40.13 # Llorean: I don't buy the principle in the first place. You have to explain why you don't want something, and then we see whether or not that applies to the new feature. 00.40.23 # Llorean: are you too blind to see that we have loads of automation in rockbox? 00.40.37 # JdGordon1: But several people objecting to it can, which was previously the case, and no attempt was seriously made to determine if that situation had changed before it went in, despite past discussions about *exactly* such a situation and how it should be resolved. 00.41.07 # kugel: Explain to me a similar case of automation that chooses whether or not to apply a setting based on the location of a file? 00.41.34 # kugel: even ignoreing the whole file -> buffer-> codec -> output system, there is tons of user configurable automation going on! 00.41.39 # sideral: I don't want it because it automates the application of a setting based on an automated procedure, a reason that has been deemed valid for rejecting features in the past. 00.41.47 # Why should we reject something because it adds a setting that configures on what to apply automation? 00.42.11 # especially if we have implemented that scheme in a lot of places already? 00.42.18 # kugel: So tell me some, like I asked. 00.42.30 # database.ignore? 00.42.35 # Llorean: I think that both Saint and pixelma stopped their opposition. 00.42.57 # sideral: everyone did 00.43.08 # sideral: I didn't see that at what you linked me to, at least. 00.43.27 # Llorean: That may have happened in other conversations. 00.44.01 # pixelma and Saint helped me streamline the configuration. 00.44.05 # kugel: Database.ignore is completely unable to affect playback. I will give you that in the general case it's similar, but not to the degree that folder-based configs and folder-based autoresume is. 00.44.30 # I did too, on the understanding that I'm going to keep annoying sideral until he lets me add tracks as and when needed to an otherwise empty database :) 00.44.33 # sideral: I would have helped you streamline the configuration while still objecting, in the case that even if I didn't like it, if it went in despite my objections I'd still want it the best possible 00.44.38 # sideral: "helped me" doesn't mean 'agreed with me' 00.45.13 # Llorean: honestly, to me it looks like you want to aggrandise yourself because we didn't wait for you to recover from your surgery (keep in mind we didn't even know about). I seriously have a hard time to see your point, because your arguments are plain wrong. But I'm out of this stupid discussion for today 00.45.17 # I'm not saying they don't agree with you 00.45.24 # Just saying, that's an erroneous conclusion to jump to. 00.45.50 # kugel: Basically "I don't have any features other than database.ignore, which doesn't affect playback like the rejected ones did?" 00.45.52 # Llorean: Yes, I took some educated guesses :) 00.45.57 # sideral: Educated by what? 00.46.46 # sideral: In a situation like this, the effort should be made for explicit agreement. Not "I haven't heard from them in a while, so it's good enough" like apparently was done with me. We had a whole discussion in the past about contentions features where there was even talk about how many had to agree more than objectors. 00.46.48 # Simply by my conversations with folks here. 00.46.58 # "I assume" really isn't good enough for that. 00.47.13 # nothing short of signed letter is 00.47.48 # Well, for example, it should be assumed that I still object until I say otherwise. If the feature is good enough, even with that assumption it'd be possible to get enough explicit agreements. 00.48.06 # There should never be a case of implied change of opinion. 00.48.16 # Llorean: I'm afraid we all make assumptions all the time. Also, I accept the reality that there's no way everyone will always agree with me. 00.48.19 # and in that vein it should be assumed that sideral is going to keep ignoreing your nonesense objections 00.48.25 # Even if you can't get in contact with everyone, changes could easily change the opinion of enough people that can give an explicit response. 00.48.50 # JdGordon1: Just because you don't agree with them doesn't mean they're nonsense. Please, try to stay civil. No value-assertions are needed. 00.49.29 # sideral: Yes, assumptions are often made. That doesn't mean that you should use them for this sort of decision making, to the contrary of what was basically eventually agreed upon as the policy for this sort of conflict resolution. 00.49.38 # The fact that no real attempt was made to follow that is kind of a problem. 00.49.51 # That means anyone can say "I assume they agree with me, so I'll commit" 00.50.15 # How much would have hurt to wait a short period to actually ask the people who'd objected and give them a day or two to respond? 00.52.52 # Llorean: I'm sorry for the loss of communication. 00.52.53 # But I look at it this way: There's no way your objections can be cleared up -- they are based on invalid (in my view) principles. Yet, I was given commit access, meaning I was trusted with making the decision to commit at the right time. 00.53.15 # sideral: And I too have commit access. I could remove your commit if I felt it was appropriate, and then we'd be stuck again. 00.53.52 # and there would be a massive shitstorm if you did that, and you know it 00.53.58 # "Have commit access" doesn't mean "should override opinions before settling the issue" 00.54.08 # JdGordon1: Last time I reverted a change I didn't like, I believe it stuck. 00.54.23 # Llorean: Yes you could. I actually invite you to do that if you think it is right. That would mean our disagreement would have to worked out by others pretty quickly. 00.54.27 # what, 2 years ago? 00.54.39 # I can't remember what it was, but I seem to remember others agreed then 00.55.00 # JdGordon1: I'm not sure it'd be the exact one you think it would. 00.55.11 # It would at least bring discussion of this to the forefront. 00.55.35 # I know when I previously objected to this issue, I was told by some others that they agreed with my objections but didn't speak up because I'd already said them. 00.55.56 # Which is why I feel discussion should've been settled on the issue before the commit. 00.57.33 # sideral: My principals may be invalid in your view, but distinguishing autoresume from bookmarks is invalid in mine since, fundamentally, there's no reason they shouldn't be the same feature, and working to separate them like this just makes it a more significant change to users later if the separation is resolved. 00.57.55 # Not to mention if the automation *is* rejected, and later removed. 00.58.08 # Llorean: honestly its pretty difficult to care about discussions with people who really have no interest in actually working on things 00.58.19 # Or, if the fact that it's too easy for false positives (a question that wasn't even addressed) means that the behavior needs to change. 00.58.49 # so i think its maybe unrealistic for you to expect people to care so much about what you think in situations like this 00.58.58 # saratoga: And yet people were happy to criticize me all the time on the things *I* worked on in the past. So, you know what, I think their behaviour has validated that I'm allowed to voice my opinion on what gets worked on in the areas I contribute less to. 00.59.14 # My opinion doesn't have to be listened to, and nothing has to be done about it. 00.59.21 # Llorean: Yes, there's potential for false positives, but I think we arrived at a good compromise between more configurability (which is what I wanted) and simplicity (one of your goals) 00.59.22 # But never suggest I shouldn't voice it as I like. 00.59.44 # voice all you like 01.00.01 # sideral: I don't think it's a good compromise at all. It should only do explicit, full matches. So no file paths unless there's a leading /, no substrings. 01.00.23 # saratoga: Then what was your point? Obviously I know that I'm not guaranteed to have people do what I say or anything. 01.00.50 # saratoga: If I felt I could dictate, I wouldn't give reasons and attempt to explain the grounds upon which I object. 01.01.23 # sideral: This still gives as much configurability as you could want, but means almost no false positives (unless your genre happens to exactly match a file path) 01.02.37 # Llorean: I stand by my assessment that from a user perspective, autoresume has to be different from bookmarks because the point of autoresume is that _is has no UI_. From an implementation perspective, I'd be fine with sharing a common backend with bookmarks as JdGordon has proposed. 01.02.52 # kugel: Here's a first attempt at changing configure to split out the applications into separate targets - any comments before I post it to flyspray (so thomasjfox can test) ? http://linuxstb.cream.org/rockbox/configure-app-targets-v1.diff 01.03.11 # kugel: (or let me know if you don't have time/interest in looking now, and I'll just put it on flyspray) 01.03.14 # Llorean: ok, good, so you understand that not everyone has to care what you say, you've now said your peice so accept that it isnt being accepted and be quiet 01.03.17 # Llorean: Yes, we can work on making the configuration more precise. I'm open on that 01.03.26 # JdGordon1: See, there you are telling me not to voice my opinions. 01.03.37 # sideral: So why not change it to explicit matching? Why wasn't that used in the first place? 01.04.05 # Llorean: you've been stating your opinions for over an hour... this is circular, the rest of us are bored 01.04.08 # Llorean: Because no one suggested it despite extensive review? 01.04.53 # sideral: It seems pretty obvious too me. Too bad I was unconscious. That's exactly the sort of thing I'd have suggested while saying "it shouldn't go in, but if it does, it really should at least..." 01.04.55 # :) 01.05.32 # JdGordon1: Then don't pay attention, and/or don't respond. Any time you offer a counter-argument if I think that either part of my opinion has been misunderstood, or misrepresented, or just missed, I will continue to respond. That's how it works. 01.05.41 # linuxstb: good idea, you should make the menu alphabetical though (android then sdl) 01.05.43 Quit toffe82 (Read error: Connection reset by peer) 01.05.58 # sideral: Any chance it's relatively trivial to fix? the sooner the better on behaviour changes so users don't get used to it. 01.06.39 # JdGordon1: And when the next target is added? I'm just following the convention of listing them in the order they were added. 01.06.48 # Llorean: Glad you're being constructive! That could be enhance pretty quickly. Could you add a tracker comment outlining your idea? 01.07.10 # sideral: Does it really need outlining? Match only whole, exact values rather than substrings? 01.07.26 # linuxstb: sure, but because its a moderate change you may as well make it neat to begin with... 01.08.27 # we need to get GSOC project ideas on the wiki 01.08.33 # I may want to think about this some more, and logging it in the tracker makes sure it doesn't get lost. For example, I think we need some substring capability to capture both "podcast" and "PODCASTS" to make the default more useful. 01.08.40 # saratoga: Are we even possibly accepted this year? 01.08.42 # it would be great if people could copy their proposals from last year over to this year's page 01.09.02 # sideral: Well, I think it shouldn't be case sensitive. Exact matching of letters, not character values. 01.09.18 # Since FAT32 isn't a case sensitive filesystem, and I don't think that ID3 tags are generally considered to be. 01.09.37 # saratoga: I seem to remember last year there was significant thought we wouldn't be acceptable this year. 01.09.42 # linuxstb: while you're playing, can you add a set of common LCD sizes instead of having to do width/ehight manually? 01.09.42 # Llorean: that, but also mind the "s" in "podcast" vs "podcasts" 01.10.01 # sideral: I think it's not too hard to type "podcast, podcasts, /podcasts" 01.10.17 Quit dfkt (Quit: -= SysReset 2.53=- Sic gorgiamus allos subjectatos nunc.) 01.10.21 # Just make sure the default contains both. 01.11.04 # Llorean: You're probably right. But please do log a comment -- I'm too tired and probably won't recall this completely tomorrow :) 01.11.16 # There's no reason not to update the default to take into account new limitations. 01.11.19 # And I've posted to the tracker 01.11.30 # cool. 01.11.35 # And, just to be explicit - my being helpful doesn't mean I agree with the way the feature currently works. :-P 01.11.49 # i have no idea 01.11.57 # Llorean: I wanted to say one more thing publicly: 01.12.06 # *drumroll* 01.12.07 # saratoga: Do we still have contacts? 01.12.31 # maybe ask Bagder or AlexP? 01.12.32 # kugel: there was a time were I suddenly didn't get flyspray notification for no apparent reason (still subscribed to the same tasks and email address was correct, it suddenly fixed itself. I also heard that from someone else, I believe it was funman. I objeced (only here) to saratoga's initial commit btw. but got no-one to back it up. I'd just given up opposition though because I was tired discussing it and since I don't listen to podcasts 01.13.20 # pixelma: It looks like I legitimately was not subscribed, so in this case it's probably my fault. I thought I had, but I'm not willing to say that it chose to forget that I had entirely. 01.13.25 # it would still be nice if some issues were addressed and seeing about sorting this out before a feature inclusion would be nice 01.14.01 # as I stated about a week ago - we usually don't toss features once included 01.14.20 # Llorean: To make up for my first impression of you during our conversion, I've listened to that FLOSS podcast you did, and have to say: That was really cool, and I think you're quite a sympathetic person. :) 01.14.36 # Good night 01.14.43 # sideral: I don't come across nearly as well in text, unfortunately, as I do in person. Ask anyone who met me at DevCons past. 01.14.50 # Sorry we seem to be butting heads on things. 01.15.00 # linuxstb: looks ok 01.15.18 # JdGordon1: I'ld rather do that afterwards. Maybe it would be better as a sub-menu - i.e. choose the lcd size from a list instead of specifying width/height. There is also the question about whether a different lcd size means a different target_id (which IIUC is just used for voice/lang files identification) 01.15.58 # linuxstb: uh, yeah,, thats what I meant :) 01.24.35 Quit sideral (Ping timeout: 240 seconds) 01.31.01 Quit kugel (Remote host closed the connection) 01.44.39 Quit mudd1 (Ping timeout: 260 seconds) 01.47.25 Quit pamaury (Remote host closed the connection) 01.48.03 Quit factor (Read error: Operation timed out) 01.55.38 Quit linuxguy3 (Ping timeout: 272 seconds) 01.56.53 Join linuxguy3 [0] (~timj@adsl-75-57-194-123.dsl.emhril.sbcglobal.net) 02.05.23 Quit Dexpid (Remote host closed the connection) 02.11.28 Quit Stephen__ (Quit: Leaving) 02.13.53 *** Saving seen data "./dancer.seen" 02.18.52 # <[Saint]> [12:42] Llorean: I think that both Saint and pixelma stopped their opposition. <-- fwiw...I didn't stop my opposition, I simply decided my voice was too small. 02.19.22 # <[Saint]> and, weighed up how much it actually meant to me...I don't *have* to use it...right? 02.29.02 Join factor [0] (~factor@75.108.68.114) 02.35.49 Join milk [0] (~milk@94-193-93-226.zone7.bethere.co.uk) 02.56.32 Quit saratoga (Quit: Page closed) 03.23.49 Quit robin0800 (Quit: Leaving) 03.26.55 Quit qurvel (Ping timeout: 276 seconds) 03.27.00 Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.3-3.cable.virginmedia.com) 03.33.52 Quit robin0800 (Quit: Leaving) 03.34.07 Join robin0800 [0] (~robin0800@cpc2-brig8-0-0-cust964.3-3.cable.virginmedia.com) 03.37.17 Quit liar (Ping timeout: 255 seconds) 03.42.38 Quit robin0800 (Quit: Leaving) 03.44.34 Quit [Saint] (Ping timeout: 240 seconds) 03.45.11 Join [Saint] [0] (S_a_i_n_t@203.184.1.55) 03.46.52 Join enthdegree [0] (~enthdegre@cpe-024-211-171-023.nc.res.rr.com) 04.05.34 Quit Keripo (Ping timeout: 255 seconds) 04.07.17 Join godeater_ [0] (3a9337c7@rockbox/staff/GodEater) 04.08.15 Quit amiconn (Disconnected by services) 04.08.15 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.08.33 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.08.46 Join Keripo [0] (~Keripo@eng442.wireless-resnet.upenn.edu) 04.09.21 Quit pixelma (Disconnected by services) 04.09.23 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.09.25 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.10.41 Quit Barahir (Read error: Operation timed out) 04.10.52 Quit TheSeven (Ping timeout: 245 seconds) 04.13.56 *** Saving seen data "./dancer.seen" 04.14.28 Join Barahir [0] (~jonathan@frnk-590fc017.pool.mediaWays.net) 04.14.42 Quit Kitr88 (Read error: Connection reset by peer) 04.14.58 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 04.20.21 Quit godeater_ (Quit: Page closed) 04.22.57 Join Kitar|st [0] (~Kitarist@BSN-182-129-226.dial-up.dsl.siol.net) 04.25.29 Join DerPapst1 [0] (~Alexander@p4FE8F918.dip.t-dialin.net) 04.28.01 Quit DerPapst (Ping timeout: 250 seconds) 04.44.52 Nick froggyman_ is now known as froggyman (~seth@98.115.0.7) 04.45.08 Quit froggyman (Changing host) 04.45.08 Join froggyman [0] (~seth@unaffiliated/froggyman) 04.50.52 Join Dexpid [0] (~dexpid@cpe-69-133-107-162.woh.res.rr.com) 04.53.05 Quit DerPapst1 (Quit: Leaving.) 04.54.19 Quit Dexpid (Client Quit) 04.59.46 # <[Saint]> Hmmm...what information would one like to see present (when no next track is available) on a wps to fill a big gap, considering that track name, artist, album, genre, year, bitrate, codec, and samplerate are already displayed? 05.00.46 # <[Saint]> in the (reasonably infrequent) event there's no next track present, there's a bit of a hole in my WPS if there is no album art (another reasonably unlike occurence). 05.00.59 # <[Saint]> *unlikely 05.01.18 Quit Keripo (Quit: Leaving.) 05.02.47 # <[Saint]> ...peak-meters? 05.03.47 Join Rob2223 [0] (~Miranda@p4FFF314C.dip.t-dialin.net) 05.04.49 Join Keripo [0] (~Keripo@eng442.wireless-resnet.upenn.edu) 05.08.22 Quit Rob2222 (Ping timeout: 276 seconds) 05.20.16 Join Dexpid [0] (~dexpid@cpe-69-133-107-162.woh.res.rr.com) 05.24.24 Quit zu (Ping timeout: 276 seconds) 05.24.53 Quit Keripo (*.net *.split) 05.24.53 Quit [Saint] (*.net *.split) 05.24.53 Quit Galois (*.net *.split) 05.24.53 Quit Battousai (*.net *.split) 05.24.54 Quit CIA-7 (*.net *.split) 05.24.54 Quit yosafbridge (*.net *.split) 05.24.54 Quit logiclost (*.net *.split) 05.24.54 Quit cjcopi (*.net *.split) 05.24.54 Quit enthdegree (*.net *.split) 05.24.55 Quit factor (*.net *.split) 05.24.55 Quit froggyman (*.net *.split) 05.24.55 Quit JdGordon1 (*.net *.split) 05.24.55 Quit Horscht (*.net *.split) 05.24.55 Quit jae (*.net *.split) 05.24.55 Quit eGen_ (*.net *.split) 05.24.55 Quit Strife89 (*.net *.split) 05.24.55 Quit jfc (*.net *.split) 05.24.55 Quit DrDnar (*.net *.split) 05.24.55 Quit AlexP (*.net *.split) 05.24.55 Quit kkit|sh (*.net *.split) 05.24.55 Quit dionoea (*.net *.split) 05.24.55 Quit pikytcus (*.net *.split) 05.24.55 Quit scorche|sh (*.net *.split) 05.24.55 Quit MagusG (*.net *.split) 05.24.55 Quit ChanServ (*.net *.split) 05.24.56 Quit Quazgaa (*.net *.split) 05.24.56 Quit ehntoo (*.net *.split) 05.24.56 Quit guymann (*.net *.split) 05.24.56 Quit balintx (*.net *.split) 05.24.56 Quit feisar- (*.net *.split) 05.24.56 Quit Rob2223 (*.net *.split) 05.24.56 Quit amiconn (*.net *.split) 05.24.56 Quit bluebrother (*.net *.split) 05.24.57 Quit n17ikh (*.net *.split) 05.24.57 Quit Dhraakellian (*.net *.split) 05.24.57 Quit Farthen (*.net *.split) 05.24.57 Quit linuxguy3 (*.net *.split) 05.24.57 Quit plux (*.net *.split) 05.24.57 Quit Dreamxtreme (*.net *.split) 05.24.58 Quit panni_ (*.net *.split) 05.24.58 Quit jepler (*.net *.split) 05.24.58 Quit Kohlrabi (*.net *.split) 05.24.58 Quit amee2k (*.net *.split) 05.24.58 Quit ps-auxw (*.net *.split) 05.24.58 Quit bzed (*.net *.split) 05.24.59 Quit powell14ski_ (*.net *.split) 05.24.59 Quit ranmachan (*.net *.split) 05.24.59 Quit Elfish (*.net *.split) 05.24.59 Quit milk (*.net *.split) 05.24.59 Quit mystica555_ (*.net *.split) 05.24.59 Quit Sochiro (*.net *.split) 05.25.00 Quit preglow (*.net *.split) 05.25.00 Quit crwl (*.net *.split) 05.25.00 Quit Loto (*.net *.split) 05.25.00 Quit gevaerts (*.net *.split) 05.25.00 Quit TBCOOL (*.net *.split) 05.25.00 Quit YPSY (*.net *.split) 05.25.41 Join zu [0] (~zu@ks355000.kimsufi.com) 05.25.41 Join Keripo [0] (~Keripo@eng442.wireless-resnet.upenn.edu) 05.25.41 Join Rob2223 [0] (~Miranda@p4FFF314C.dip.t-dialin.net) 05.25.41 Join amiconn [0] (quassel@rockbox/developer/amiconn) 05.25.41 Join enthdegree [0] (~enthdegre@cpe-024-211-171-023.nc.res.rr.com) 05.25.41 Join [Saint] [0] (S_a_i_n_t@203.184.1.55) 05.25.41 Join milk [0] (~milk@94-193-93-226.zone7.bethere.co.uk) 05.25.41 Join factor [0] (~factor@75.108.68.114) 05.25.41 Join linuxguy3 [0] (~timj@adsl-75-57-194-123.dsl.emhril.sbcglobal.net) 05.25.41 Join froggyman [0] (~seth@unaffiliated/froggyman) 05.25.41 Join JdGordon1 [0] (~jonno@vl10.gw.ok-labs.com) 05.25.41 Join plux [0] (~yogurt@h-34-156.A238.priv.bahnhof.se) 05.25.41 Join Dreamxtreme [0] (~Dre@92.30.107.230) 05.25.41 Join Horscht [0] (~Horscht@xbmc/user/horscht) 05.25.41 Join jae [0] (~jae@dedicated.jaerhard.com) 05.25.41 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 05.25.41 Join panni_ [0] (hannes@ip-178-203-73-7.unitymediagroup.de) 05.25.41 Join eGen_ [0] (generat0r@gate.mmdecin.cz) 05.25.41 Join mystica555_ [0] (~mike@m312636d0.tmodns.net) 05.25.41 Join Strife89 [0] (~Strife89@168.16.226.187) 05.25.41 Join jfc [0] (~john@pool-72-73-80-12.ptldme.east.myfairpoint.net) 05.25.41 Join Quazgaa [0] (quaz@c-76-22-103-237.hsd1.wa.comcast.net) 05.25.41 Join Galois [0] (djao@efnet-math.org) 05.25.41 Join Battousai [0] (~bryan@gentoo/developer/battousai) 05.25.41 Join Sochiro [0] (~Sochiro@194.90.222.165) 05.25.41 Join cjcopi [0] (~craig@76.241.66.141) 05.25.41 Join n17ikh [0] (~n17ikh@c-68-59-25-51.hsd1.sc.comcast.net) 05.25.41 Join DrDnar [0] (~Ander@c-24-35-66-83.customer.broadstripe.net) 05.25.41 Join ehntoo [0] (~ehntoo@lug.mtu.edu) 05.25.41 Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) 05.25.41 Join guymann [0] (~charles@69.182.30.171) 05.25.41 Join AlexP [0] (~alex@rockbox/staff/AlexP) 05.25.41 Join kkit|sh [0] (~kkit@li135-248.members.linode.com) 05.25.41 Join Dhraakellian [0] (~ntryon@cpe-67-240-248-41.rochester.res.rr.com) 05.25.41 Join bzed [0] (~bzed@devel.recluse.de) 05.25.41 Join balintx [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu) 05.25.41 Join jepler [0] (~jepler@emc/developer/pdpc.professional.jepler) 05.25.41 Join dionoea [0] (~dionoea@videolan/developer/dionoea) 05.25.41 Join yosafbridge [0] (~yosafbrid@li125-242.members.linode.com) 05.25.41 Join preglow [0] (thomj@tvilling2.pvv.ntnu.no) 05.25.41 Join crwl [0] (~crwlll@dsl-jklbrasgw1-fe8edf00-29.dhcp.inet.fi) 05.25.41 Join Loto [0] (~nfs@xbmc/user/Loto) 05.25.41 Join CIA-7 [0] (~CIA@208.69.182.149) 05.25.41 Join feisar- [0] (jljhook@ihq.in) 05.25.41 Join Kohlrabi [0] (~kohlrabi@kohlio.de) 05.25.41 Join Elfish [0] (amba@2a01:4f8:100:90a1:abc:abc:abc:abc) 05.25.41 Join amee2k [0] (~thomas@ve504.cugnet.net) 05.25.41 Join pikytcus [0] (~bigd@failbox.co.cc) 05.25.41 Join scorche|sh [0] (~scorche@rockbox/administrator/scorche) 05.25.41 Join gevaerts [0] (~fg@rockbox/developer/gevaerts) 05.25.41 Join MagusG [0] (magusg@c-71-59-57-46.hsd1.ga.comcast.net) 05.25.41 Join ChanServ [0] (ChanServ@services.) 05.25.41 Join Farthen [0] (~Farthen@static.225.178.40.188.clients.your-server.de) 05.25.41 Join ranmachan [0] (ranma@yumi.tdiedrich.de) 05.25.41 Join powell14ski_ [0] (~powell14s@c-67-177-228-132.hsd1.co.comcast.net) 05.25.41 Join logiclost [0] (~lostlogic@erudite.lostlogicx.com) 05.25.41 Join TBCOOL [0] (~tb@c-3c3671d5.09-42-73746f22.cust.bredbandsbolaget.se) 05.25.41 Join YPSY [0] (~ypsy@geekpadawan.de) 05.25.41 Mode "#rockbox +o ChanServ " by holmes.freenode.net 05.25.44 Quit Barahir (*.net *.split) 05.25.44 Quit Llorean (*.net *.split) 05.25.44 Quit advcomp2019 (*.net *.split) 05.25.44 Quit ack` (*.net *.split) 05.25.44 Quit parafin (*.net *.split) 05.25.44 Quit ThomasAH (*.net *.split) 05.27.26 Quit MethoS- (Remote host closed the connection) 05.27.38 Quit markun (Ping timeout: 240 seconds) 05.27.51 Quit Dexpid (Read error: Connection reset by peer) 05.28.49 Join markun [0] (~markun@178.224.146.109) 05.28.49 Quit markun (Changing host) 05.28.49 Join markun [0] (~markun@rockbox/developer/markun) 05.29.25 Join Barahir [0] (~jonathan@frnk-590fc017.pool.mediaWays.net) 05.29.25 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 05.29.25 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) 05.29.25 Join ack` [0] (~ack@mingbai.org) 05.29.25 Join parafin [0] (parafin@paraf.in) 05.29.25 Join ThomasAH [0] (~thomas@aktaia.intevation.org) 05.29.29 Quit panni_ (Quit: ( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )) 05.33.28 Join DanielleKayser [0] (~181d3403@giant.haxx.se) 05.33.50 # requesting approval of wiki account DanielleKayser please 05.37.29 # <[Saint]> one sec. 05.38.50 Quit Horscht (Quit: Verlassend) 05.38.56 Quit DanielleKayser (Quit: CGI:IRC (Ping timeout)) 05.39.42 # <[Saint]> DanielleKayser: if you come back...done, don't break our wiki! ;) 06.03.37 Join Klevi [0] (~Levi@ool-45763ea1.dyn.optonline.net) 06.03.50 # Hey guys! Question for everyone 06.04.48 # I have an OpenPandora >> http://openpandora.org << if I were to build rockbox simply to be an Mp3/Video player for it, how should I go about doing that? 06.08.17 # The easiest way would be to set up the build environment on your pandora, and compile the simulator for the M-robe 500 as I'm pretty sure it uses the same screen size as the pandora 06.08.56 # Oh! Didnt see you were here as well, froggyman >.o 06.09.20 # Yep 06.10.00 # and alright, I should be more than capable of tackling this myself then now that I know the target build I need. Thanks. =) Will report back how it works out 06.11.23 # Well the M robe 500's screen resolution is actually 640x480... you might be able to change the screen size for the sim somewhere in one of the source files... not sure where though 06.13.59 *** Saving seen data "./dancer.seen" 06.16.17 # <[Saint]> why could it not run the SDL app? 06.16.28 # <[Saint]> then you could feed it whatever screen size you wanted. 06.17.28 # [Saint], Isn't the sim the same as the SDL app? 06.17.36 # <[Saint]> No. 06.17.41 # almost 06.17.50 # Whats different? 06.18.02 # if openpandora provides a nice posix api then just build the sdl app 06.22.22 # [Saint], JdGordon1, is there a wiki page for the SDL app? 06.22.53 # <[Saint]> not that I know of...it's fantastically poorly doccumented. 06.23.18 # haha... alright 06.40.24 Join ZhangNing [0] (~ZhangNing@182.35.210.166) 06.51.25 Quit Klevi (Quit: Leaving) 07.23.35 Join Choicefresh [0] (~Liam@unaffiliated/choicefresh) 07.23.48 Quit Barahir (Ping timeout: 245 seconds) 07.24.35 Join Barahir [0] (~jonathan@frnk-590fc017.pool.mediaWays.net) 07.25.00 # Hey, is there any work currently being done on accesory compatibility? (i.e. if i upgrade from the stable release to the current build, will it work with more dock speakers?) 07.25.05 # *accessory 07.30.19 Quit JdGordon1 (Quit: leaving) 07.32.43 # or, in other words, are there release notes for the "current build"? 07.32.53 # as in advantages/disadvantages 07.47.32 Quit Judas_PhD (Quit: This is a quitting message) 07.57.17 Join kugel [0] (~kugel@92.117.222.247) 07.57.19 Quit kugel (Changing host) 07.57.19 Join kugel [0] (~kugel@rockbox/developer/kugel) 08.07.26 Quit Choicefresh (Quit: Leaving.) 08.09.34 Join JdGordy [0] (~jonno@124-171-49-199.dyn.iinet.net.au) 08.14.03 *** Saving seen data "./dancer.seen" 08.19.54 Join sideral [0] (~sideral@213.165.85.248) 08.19.55 Quit sideral (Changing host) 08.19.55 Join sideral [0] (~sideral@rockbox/developer/sideral) 08.20.07 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 08.22.13 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 08.22.14 Quit bertrik (Changing host) 08.22.14 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 08.23.49 Quit Zambezi (Changing host) 08.23.49 Join Zambezi [0] (Zulu@unaffiliated/zambezi) 08.28.21 Join B4gder [0] (~danielx@rockbox/developer/bagder) 08.29.10 Quit rasher (Ping timeout: 240 seconds) 08.33.48 # pixelma, Saint: Thanks for clarifying your position re autoresume. I had not intended to misrepresent what you've said. Of course I'm sorry you still don't like the feature as it is now; no feature ever is for everyone, I guess. But I'm impressed that, despite this, you've helped to improve it. Thanks! :) 08.34.45 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 08.38.56 Quit JdGordy (Ping timeout: 255 seconds) 08.39.51 Quit mc2739 (Ping timeout: 240 seconds) 08.40.25 # <[Saint]> As much as I don't necessarily think it's the right way to go, if it's the way we're going I still want it to be the best it can be. 08.40.32 # <[Saint]> Even if I don't use it. 08.40.37 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 08.40.50 Quit bertrik (Ping timeout: 240 seconds) 08.42.41 # Much appreciated! 08.46.00 Quit mc2739 (Ping timeout: 246 seconds) 08.46.20 # FYI: the Rockbox Steering Board has been asked to look into this issue 08.48.15 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 08.50.34 Quit ZhangNing (Remote host closed the connection) 08.50.51 Join ZhangNing [0] (~ZhangNing@182.35.210.166) 08.51.19 Join ender` [0] (krneki@foo.eternallybored.org) 08.54.04 Join pamaury [0] (~quassel@dhcp-128-95.residence.ens-lyon.fr) 08.54.05 Quit pamaury (Changing host) 08.54.05 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 08.54.59 Join mudd1 [0] (~cmertes@ip-78-94-203-49.unitymediagroup.de) 08.57.00 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 08.57.46 Join tchan1 [0] (~tchan@c-69-243-144-187.hsd1.il.comcast.net) 08.59.05 Join petur [0] (d408b802@rockbox/developer/petur) 08.59.31 Join rasher [0] (~rasher@0x5550f5a3.adsl.cybercity.dk) 08.59.32 Quit rasher (Changing host) 08.59.32 Join rasher [0] (~rasher@rockbox/developer/rasher) 08.59.38 Quit tchan (Ping timeout: 240 seconds) 09.06.46 # Thanks for the heads up, Zagor. I welcome this move -- although I'm sorry to be the reason for its summoning. :( 09.07.16 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 09.10.34 Join LinusN [0] (~linus@rockbox/developer/LinusN) 09.15.38 # fwiw, I'm fine with autoresume as of now (in what it does/offers and the related settings; I would still welcome if it would be unified with bookmarks internally) 09.16.22 Join n1s [0] (~n1s@rockbox/developer/n1s) 09.18.12 Join jr [0] (~chatzilla@p5DCE2555.dip.t-dialin.net) 09.18.38 # Zagor: is there any procedure (publix or private) as to how it will be handled? 09.19.47 # JdGordon|: not many. the summoning is confidential, and the board is free to decide however it wants. including to decide not to decide. 09.19.50 Quit kugel (Ping timeout: 240 seconds) 09.21.42 Quit sideral (Ping timeout: 246 seconds) 09.24.55 # * JdGordon| is curious as to what the request wording was (by whom can probably be guessed and that is less interesting) 09.25.06 # but I understand that that is unlikely to happen 09.28.47 # yes, all mails sent to the rsb are strictly confidential 09.35.10 Join sideral [0] (~sideral@rockbox/developer/sideral) 09.37.00 Quit liar (Ping timeout: 255 seconds) 09.38.04 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 09.43.39 # Zagor: Is this the first time ever the board was summoned? 09.43.54 # yes 09.44.17 # wow 09.44.41 # New commit by 03jethead71 (r29257): buffering: Fix a case that could allow widx to fully wrap to ridx and overflow the ringbuffer. 09.46.32 Quit jr (Remote host closed the connection) 09.49.30 # r29257 build result: All green 09.49.50 Quit GeekShadow (Ping timeout: 276 seconds) 10.00.07 Quit DrDnar (Read error: Connection reset by peer) 10.05.27 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 10.14.06 *** Saving seen data "./dancer.seen" 10.19.43 Quit mc2739 (Read error: Connection reset by peer) 10.19.54 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 10.24.30 Join Highlander [0] (~Highlande@mek33-4-82-236-45-205.fbx.proxad.net) 10.30.13 # New commit by 03jethead71 (r29258): Buffering should align itself and not rely on buffering_reset parameters when storage alignment matters so that wrapped reads maintain alignment. 10.30.30 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 10.34.16 # r29258 build result: All green 10.41.19 Quit ZhangNing (Remote host closed the connection) 10.43.38 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 10.43.46 Quit Keripo (Quit: Leaving.) 10.45.00 Join DerPapst [0] (~Alexander@dslb-188-107-192-175.pools.arcor-ip.net) 10.45.35 Join Keripo [0] (~Keripo@eng442.wireless-resnet.upenn.edu) 10.54.06 Quit Keripo (Quit: Leaving.) 11.03.31 Quit GeekShadow (Ping timeout: 240 seconds) 11.04.18 Join vnl [0] (~slayer@cpc5-king10-2-0-cust73.perr.cable.virginmedia.com) 11.05.04 Quit vnl (Client Quit) 11.09.18 Join qurvel [0] (~qurvel@i220-109-51-195.s02.a007.ap.plala.or.jp) 11.09.52 Join mt [0] (~mt@41.233.155.237) 11.13.32 Quit mt (Changing host) 11.13.32 Join mt [0] (~mt@rockbox/developer/mt) 11.16.49 Quit Highlander (Quit: Quitte) 11.27.26 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 11.30.54 # <[Saint]> sideral: fwiw...it's not the first time it's been considered ;) 11.33.19 Join dfkt [0] (dfkt@unaffiliated/dfkt) 11.37.25 Quit GeekShadow (Quit: The cake is a lie !) 11.42.21 Join kevku [0] (~kevku@2001:7d0:0:f9af:215:c5ff:fe7e:794d) 11.51.15 Join Raptors [0] (~Raptors@dsl-67-212-28-189.acanac.net) 11.51.24 # is there a way to queue a song to be played nexT? 11.53.02 # <[Saint]> yes. 11.55.11 # How? 11.56.11 # <[Saint]> bring up the context menu on the track, choose Playlist, then Queue Next (or similar). 11.56.37 # <[Saint]> the manual describes it quite well ;) 11.57.07 # There is no queue next in manual 11.57.09 # err 11.57.13 # playlist 11.57.34 # <[Saint]> are you looking in the menu, or the context menu? 11.57.39 # Yes 11.58.08 # <[Saint]> there's two options there, "yes" doesn't vut it. 11.58.12 # <[Saint]> *cut 11.58.25 # I'm looking in the context menu 11.58.42 # <[Saint]> is a track playing? 11.58.46 # Yes 11.59.18 # <[Saint]> I have no idea where you're looking then, as I'm looking at it right now. 11.59.49 # Maybe the sanza fuse doesn't have it :/ 11.59.54 # <[Saint]> if a track is playing, bring up the context menu on another track, select Playlist, then Queue Next 12.00.07 # <[Saint]> and, yes...I'm pretty sure it does ;) 12.01.22 # It's not there... 12.01.53 # <[Saint]> It doesn't even matter if you launch playback from the database of the file browser...there just needs to be a track playing currently so there's a playlist for it to be added to. 12.02.11 # <[Saint]> afaik it should be available on all targets. 12.02.34 # If it's not there, you're not looking in the right place. 12.02.40 # It's not launched from database 12.02.45 # Where did you start the context menu from? 12.02.57 # From track playing screen 12.03.14 # <[Saint]> well, there you go. 12.03.28 # I tried from the playlist too :| 12.03.29 # <[Saint]> you need to bring up the context menu on the track you wish to add. 12.03.52 # <[Saint]> from either the database, or the file browser. 12.04.00 # I see it now 12.04.01 # :/ 12.04.11 # It can't be in the playlist 12.04.39 # thanks 12.05.10 # <[Saint]> if you're in the playlist, you can always use "move" 12.05.28 # <[Saint]> then you can just find the track you want and change its position manually. 12.05.38 # <[Saint]> *playlist-viewer 12.08.08 # Rockbox is so much better then the stock firmware 12.14.09 *** Saving seen data "./dancer.seen" 12.18.15 Quit n1s (Ping timeout: 255 seconds) 12.35.14 Quit Rob2223 (Quit: Rob2223) 12.46.15 Join Rob2222 [0] (~Miranda@p4FFF314C.dip.t-dialin.net) 12.48.29 Quit Rob2222 (Read error: Connection reset by peer) 12.48.39 Join Rob2222 [0] (~Miranda@p4FFF314C.dip.t-dialin.net) 13.10.43 Join user890104 [0] (Venci@venci-notebook-lan.ipv6.6bez10.info) 13.11.09 Join thomasjfox [0] (~tomj@fw.intra2net.com) 13.12.00 # * thomasjfox summons zagor 13.12.37 # * Zagor appears from the shadows 13.12.53 # hey 13.12.56 # you rang? 13.13.17 # yes. My wiki registration email got stuck somewhere. Could you check the logs? 13.13.43 # I was some days ago 13.13.56 # ok 13.13.59 Quit CIA-7 (Read error: Operation timed out) 13.14.12 # And elevated access rights in FS would be nice, too. Then I can close my own tickets :) 13.15.32 # what is your wiki name? 13.15.46 # thomasjfox 13.16.54 # there is no such wiki account. try registering again. 13.17.02 # ok, hang on a sec 13.17.14 Quit user890104 () 13.17.21 # Maybe it got deleted as it wasn't confirmed after XX hours 13.17.25 Join CIA-70 [0] (~CIA@208.69.182.149) 13.17.38 # thomasjfox: your wiki name should be your real name 13.18.02 # flyspray account upgraded 13.18.02 # then it was "Thomas Jarosch" - I'm a bit vague on the details 13.18.06 # thanks 13.18.40 # ok, that account is present 13.19.46 # though no page is created. the wiki sure seems flaky these days. 13.20.11 # Zagor: that seems to happen a lot these days 13.20.28 # yes 13.20.43 # Zagor: I can't seem to reset the password for this account 13.21.03 # "http://www.rockbox.org/wiki/System.ResetPassword?username=ThomasJarosch" -> Access denied / The "Main/System" web does not exist 13.21.10 # <[Saint]> Zagor: that ties in with what happened to MysteryKeeper 13.21.14 Join n1s [0] (~n1s@nl119-201-215.student.uu.se) 13.21.15 # thomasjfox: I think wiki is confused since you have no account page 13.21.15 Quit n1s (Changing host) 13.21.15 Join n1s [0] (~n1s@rockbox/developer/n1s) 13.21.25 # <[Saint]> making the page manually and adding the default form "just works" 13.21.31 # I guess the account is not confirmed yet 13.22.31 # I'm not sure if the account page is that critical. I've added people without one to WikiUsersGroup and they could edit things 13.23.12 # <[Saint]> i thought the page *was* the account 13.23.25 # <[Saint]> and only passes and acces rights were stored. 13.24.40 # thomasjfox: you should be getting a reset mail now 13.25.09 # <[Saint]> as soon as I made MysteryKeeper's (I forget the real name) page, his login automagically worked...I thought the page/account was quite tightly tied. 13.25.24 # <[Saint]> happy to be wrong though ;) 13.26.05 # [Saint]: iirc I had to manually fix his password 13.26.52 Join casainho [0] (~chatzilla@pal-213-228-181-14.netvisao.pt) 13.29.16 # Zagor: Could you add RaaA to flyspray as a player type? 13.29.35 # Zagor: Password has been reset. I tried to edit something like the AndroidPort page. Is it normal that I don't have access to that? 13.29.44 # perhaps even specific raaa versions? 13.29.55 # Zagor: Same for the main wiki page, though I guess I don't have access to that either 13.30.33 # thomasjfox: you haven't been given access yet. doing it now. 13.30.46 # Ah sorry, the error message cleary states that :) 13.31.35 # try now 13.32.54 # Zagor: I get the edit box now. Thanks 13.33.49 # I added Android and Maemo to the player types 13.35.26 # Zagor: An overall "RaaA" type would be useful as well though IMO - I think a lot of tasks will be generic (my first RaaA patch is...) 13.35.57 # yes, but most work is generic to a lot of players. 13.36.10 # linuxstb: Or "Generic RaaA" to make it more precise? 13.36.32 # we don't have "generic swcodec" or some such either 13.36.46 # actually we do ;*) 13.37.10 # * Zagor 's argument fails miserably 13.37.18 # hehe 13.37.29 # I'd say RaaA is swcodec :) 13.37.41 # <[Saint]> lol 13.39.22 Quit kevku (Ping timeout: 260 seconds) 13.39.37 Quit thomasjfox (Remote host closed the connection) 13.39.52 Join thomasjfox [0] (~tomj@fw.intra2net.com) 13.41.39 Join kevku [0] (~kevku@2001:7d0:0:f9af:215:c5ff:fe7e:794d) 13.42.03 Quit sasquatch (Ping timeout: 240 seconds) 13.43.09 # * Zagor restarts apache 13.46.15 # Zagor: While you are at it, could you help me setting up a Wiki account as well? I'm not sure in which state my registration / edit privs are. 13.46.35 # anyone can do that 13.46.43 # if you have an account and you can edit pages, that's it 13.46.49 # there are no speciak wiki privileges for developers 13.47.04 # everyone who's been granted edit permission at all can do anything 13.47.29 # (and if you haven't then just tell us your username and nayone can add you) 13.47.38 # Just tried reregistering / logging in, but it said "Access check on Main.MichaelHohmuth failed. Action "CHANGE": access not allowed on web" 13.48.09 # Also, didn't receive any registration email... 13.48.33 # apparently nobody does 13.48.46 # Your user page doesn't exist 13.48.49 # so I don't think you are registered 13.48.59 # he exists in the .htpasswd file 13.48.59 # Shall I try again? 13.49.08 # oh, maybe it gets created on first login? 13.49.18 # no, there's something wrong with the wiki 13.49.25 # ah :) 13.50.55 # Torne: the wiki home page actually says to ask for write permission here, so I thought I needed that in addition to the account 13.51.04 # sideral: yes, you do 13.51.11 # you do, but anyone who already has permission can do it 13.51.20 # ..assuming the wiki is working properly ;) 13.51.39 # the write permission includes permission to write to the list of people who have write permission ;) 13.51.48 # I see 13.52.23 # sideral: I sent you a new password mail and added you to the permission group 13.53.08 Join afk [0] (~Dre@92.30.204.183) 13.53.12 Quit thomasjfox (Quit: Back to day job) 13.55.21 # Thanks Zagor. The email message hasn't arrived yet. Standing by... 13.55.37 Quit Dreamxtreme (Ping timeout: 240 seconds) 13.57.34 Join TheLemonMan [0] (~lem0n@ppp-170-133.98-62.inwind.it) 14.01.50 Quit mystica555 (Read error: Connection reset by peer) 14.01.50 Quit mystica555_ (Read error: Connection reset by peer) 14.03.07 Quit Topy (Read error: Connection reset by peer) 14.03.07 Join T44 [0] (~Topy44@f049076202.adsl.alicedsl.de) 14.04.08 Join mystica555 [0] (~Mike@m312636d0.tmodns.net) 14.04.09 Quit antil33t (Read error: Connection reset by peer) 14.04.18 Join antil33t [0] (~antil33t@124-197-51-80.callplus.net.nz) 14.08.43 Join sasquatch [0] (~username@2.211.215.117) 14.13.00 Join mystica555_ [0] (~mike@m312636d0.tmodns.net) 14.13.17 Join Dexpid [0] (~dexpid@cpe-69-133-107-162.woh.res.rr.com) 14.13.57 # Zagor: I got the email, and could log in. Thanks! 14.14.06 # great 14.14.13 *** Saving seen data "./dancer.seen" 14.15.39 # I have no user page, is that a problem? 14.22.42 # no 14.23.04 # OK 14.23.16 # Well, it's not a *big* problem 14.23.40 # Your user page is where you store certain settings though, but I suspect most people don't use that 14.24.08 # you might want to create one, to avoid anyone else doing it :) 14.24.16 # Ah, that too :) 14.24.38 # gevaerts: there's one crucial setting, the one that turns off the broken editor 14.24.48 # n1s: yes, that's the main one 14.25.11 # Ah, OK. I guess I should copy n1s' user page then. :) 14.25.37 # just make sure you change the ALLOWTOPICCHANGE line! 14.25.48 # yep 14.26.10 # is the wysiwyg editor active? I thought I disabled it globally 14.26.29 # sideral: afair gevaerts is the one that added that setting to my page after i broke the UserGroup(?) page locking every non admin out from editing 14.26.30 # Zagor: not changing that one saved me when I was playing with disabling the wysiwyg editor back when it was new :) 14.26.31 # :) 14.26.49 # Someone else was able to fix my settings then 14.27.02 # hehe 14.27.17 # Zagor: maybe you did. Having my own settings makes that invisible :) 14.32.34 # Hmm, I told it to create a child of TWikiUsers, but the edit dialog says I'm ion Main 14.32.41 # s/ion/in/ 14.32.56 Join Topy [0] (~Topy44@f048047251.adsl.alicedsl.de) 14.33.01 # yes, the wiki structure is flat. the "child" notion is only a tag. 14.33.19 # ah, I see. 14.36.03 Quit T44 (Ping timeout: 240 seconds) 14.37.32 # Done. Thanks for your help! 14.39.06 Quit afk (Ping timeout: 276 seconds) 14.45.21 Join Dreamxtreme [0] (~Dre@92.30.213.148) 14.48.56 Join evilnick_B [0] (0c140464@rockbox/staff/evilnick) 14.50.48 Quit sideral (Quit: Leaving.) 14.59.11 Quit mudd1 (Ping timeout: 240 seconds) 15.01.14 Join panni_ [0] (hannes@ip-178-203-73-7.unitymediagroup.de) 15.04.59 Quit antil33t (Read error: Connection reset by peer) 15.05.08 Join antil33t [0] (antil33t@124-197-51-80.callplus.net.nz) 15.06.04 Join T44 [0] (~Topy44@f049141161.adsl.alicedsl.de) 15.07.24 # download.rockbox.org was accessed by 2245 unique IP addresses yesterday 15.08.32 # that seems like a lot 15.08.42 # B4gder: any idea of how many completed downloads? 15.09.02 # we also have manuals there 15.09.05 # etc 15.09.16 Quit Topy (Ping timeout: 240 seconds) 15.10.27 # 3335 HEAD requests 15.10.34 # which are rbutil 15.12.06 # 2556 requests for build-info 15.12.23 # also rbutil querying for info 15.13.16 # 6661 downloads, roughly 15.13.47 # <[Saint]> could we drop a file to check for a new install compared to an update? 15.13.54 # <[Saint]> (with rbutil) 15.14.06 # <[Saint]> statistics would be *great* 15.14.58 # 2125 of the downloads were rbutil 15.16.54 # 422 were rockdoom.zip =) 15.17.14 # <[Saint]> haha! 15.17.44 # RockboxUtility-v1.2.8.zip is the by far most downloaded file, 1697 downloads 15.18.04 Join manotroll [0] (~bd7141f2@giant.haxx.se) 15.18.24 # all this is only during 24 hours 15.19.25 Quit JdGordon| (Ping timeout: 246 seconds) 15.19.51 # rockbox-iriverh300-3.7.1.zip 560 downloads (!) 15.19.58 Join webguest20 [0] (~bd7141f2@giant.haxx.se) 15.20.06 # <[Saint]> what the!?! 15.20.11 # not possible to recognize the rockbox playlist from WMP12? 15.20.22 # * [Saint] expected the #1 to be an iTarget...surely 15.20.37 # rockbox-ipodvideo-3.7.1.zip 103 downloads 15.20.40 # B4gder: unique IPs? Plausible user agents? 15.21.17 # right now I just filter out GETs and remove most non-files, so I don't see 206 responses 15.21.26 # etc 15.21.41 # (206 being used for partial responses) 15.21.45 Quit webguest20 (Client Quit) 15.21.49 Quit antil33t () 15.21.58 # I mean, some of those might be spiders, which are not very interesting 15.22.05 # indeed 15.22.07 Join manotroll-brasil [0] (~bd7141f2@giant.haxx.se) 15.22.10 # not possible to recognize the rockbox playlist from WMP12? because it does not recognize the list and do not know how to solve this 15.22.28 # this is just some quick grepping and sorting because I'm curious 15.22.29 Join mudd1 [0] (~cmertes@ip-78-94-203-49.unitymediagroup.de) 15.22.39 # I'll get the proper stats later on using a better stats script 15.22.55 # <[Saint]> if it's not an .m3U playlist, then no...I doubt RB can read it. 15.23.04 Quit manotroll (Quit: CGI:IRC (Ping timeout)) 15.23.08 # <[Saint]> manotroll-brasil: ^ 15.23.43 # <[Saint]> if it *is* an .m3u, but has specific paths reffering to files on your PC, it will also fail. 15.23.48 # and how to create one. m3u or convert to this format? 15.24.19 # <[Saint]> it's a let less painful to just create the playlist on the diveice 15.24.32 # <[Saint]> since you'll be playing files present on it anyway. 15.24.39 # <[Saint]> s/let/lot/ 15.24.43 Quit cjcopi (Ping timeout: 264 seconds) 15.24.53 # * [Saint] tries again. 15.25.08 # <[Saint]> "it's a lot easier to just create your playlists with Rockbox" 15.25.54 # er, it's okay if the playlist refers to files on the PC as long as those files are in the same layout on the player somewhere 15.26.08 # It will strip drive letters/directory names off the front of the tracks until the path matches 15.26.32 # so if the playlist refers to e:\stuff\files\music\foo.mp3 then that will work if the file on the player is called \music\foo.mp3 15.27.03 # so as long as you have all your music under a single folder on both devices, and it makes m3u format playlists, it should work okay 15.27.09 # and separate it by artist and with the list I can choose which song to listen and not have to throw everything into a single folder that he does not accept the playlist from wmp12/11/10 since he and a program that open this support did not win 15.28.42 Join komputes [0] (~komputes@ubuntu/member/komputes) 15.29.33 # but it is not possible to convert? and where to put that differently than does the rockbox 15.29.50 # what format are the playlists in now? 15.29.57 # what is the file extension? 15.31.56 # the problem here in Brazil that have special characters like "~, ç,^,~, and others that rockbox does not recognize 15.32.33 # Rockbox does recognise all characters. 15.32.47 # your filenames or tags are probably encoded wrong :) 15.33.04 # <[Saint]> If your font doesn't support those characters, they won't be displayed. 15.33.21 # <[Saint]> or incorrect codepage. 15.35.35 # 8 Unicode (UTF-8) and widely used but has variables but this is not possible to read the list of WMP12? the important thing was to read this type of list 15.38.09 Join MethoS- [0] (~clemens@134.102.106.250) 15.38.34 # <[Saint]> it seems WMP12 uses it's own XML format, WPL...this is not supported. 15.39.15 # use from when the support was experimental sansa c200v2 thought it would be the solution to the problem of not getting the full 8gb card (only recognizes 4gb) but from the look and use it only 4gb 15.39.29 Nick tchan1 is now known as tchan (~tchan@c-69-243-144-187.hsd1.il.comcast.net) 15.39.34 Quit tchan (Changing host) 15.39.34 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 15.41.06 # but it also creates m3u but not recognized and 15.41.46 # <[Saint]> as explained earlier, if it creates an m3u playlist it will work if the paths match 15.41.53 # <[Saint]> (at least in part) 15.42.14 # <[Saint]> [03:26] It will strip drive letters/directory names off the front of the tracks until the path matches 15.42.16 # <[Saint]> [03:27] so if the playlist refers to e:\stuff\files\music\foo.mp3 then that will work if the file on the player is called \music\foo.mp3 15.42.16 # <[Saint]> [03:27] so as long as you have all your music under a single folder on both devices, and it makes m3u format playlists, it should work okay 15.43.07 # you're talking about several different problems and it's not clear what you mean with *any* of them really, i'm afraid your english is not very clear 15.46.34 Join sideral [0] (~sideral@213.165.85.248) 15.46.34 Quit sideral (Changing host) 15.46.34 Join sideral [0] (~sideral@rockbox/developer/sideral) 15.49.02 # I use a translator when I create a list for him but the songs are scattered sample in the System of a Down has the folders Mezmerize, Steal This Album, System Of A Down Toxicity and looks like this so I can choose which to listen or to use the playlist to play them all in an order defined by min the buffer error when I try to make a playlist with he or she does not touch anything even with the correct path can not make a video with the emulator 15.50.34 # manotroll-brasil: Try using short, simple sentences. Say one thing at a time. It often helps. 15.50.55 # Also, if you get errors, say what the exact error message is 15.52.46 # after the end of sync with wmp 12 I'll try to make another playlist and come back here to see which will give error and inform 15.57.40 # exit 15.57.44 Quit manotroll-brasil (Quit: CGI:IRC) 15.59.52 Quit sideral (Quit: Leaving.) 16.05.44 Quit B4gder (Read error: Operation timed out) 16.06.06 Part Zagor 16.06.10 Part LinusN 16.06.13 Join B4gder [0] (~danielx@2a00:1a28:1200:9::2) 16.06.13 Quit B4gder (Changing host) 16.06.13 Join B4gder [0] (~danielx@rockbox/developer/bagder) 16.06.14 Quit B4gder (Remote host closed the connection) 16.06.28 Quit Dexpid (Quit: Computer has gone to sleep.) 16.06.46 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 16.06.50 Join B4gder [0] (~danielx@rockbox/developer/bagder) 16.13.51 Quit mt (Ping timeout: 240 seconds) 16.14.14 *** Saving seen data "./dancer.seen" 16.15.02 Quit Dreamxtreme (Read error: Connection reset by peer) 16.16.47 Join LinusN [0] (~linus@rockbox/developer/LinusN) 16.18.11 Quit TheLemonMan (Quit: free(me)) 16.19.01 Quit eGen_ (Read error: Connection reset by peer) 16.20.20 Part LinusN 16.20.28 Join L-Strife89 [0] (~Strife89@207-144-19-39.cstel.net) 16.22.52 Join eGen_ [0] (generat0r@gate.mmdecin.cz) 16.22.52 Part Zagor 16.22.52 Join Zagor [0] (~bjst@rockbox/developer/Zagor) 16.26.01 Quit n1s (Quit: Lämnar) 16.39.50 Join LinusN [0] (~linus@rockbox/developer/LinusN) 16.45.38 # * TheSeven is running his ipod classic at 288MHz 16.46.25 # * [Saint] smells smoke. 16.47.19 Join toffe82 [0] (~chatzilla@maf.wirelesstcp.net) 16.48.30 Join Keripo [0] (~Keripo@SEAS220.wlan.seas.upenn.edu) 16.49.25 # [Saint]: 318MHz now, still running smoothly 16.49.53 # <[Saint]> "Do not release the genie" 16.50.05 Join Dexpid [0] (~dexpid@cpe-69-133-107-162.woh.res.rr.com) 16.50.31 # Why is FM recording so low quality? 16.51.06 # is it because you can't write to the disk fast enough? 16.52.22 # [Saint]: at 348MHz it started calculating garbage 16.52.42 # <[Saint]> reason that thought when compared to recording fron any other input... 16.52.48 # <[Saint]> enthdegree: ^ 16.52.48 # 342MHz seems to be stable 16.52.55 # Is rockbox written in just C? 16.53.22 # Dexpid: the core, yes 16.53.32 # there are a few LUA plugins as well 16.53.34 # enthdegree: What player? 16.53.43 # enthdegree: Some players have very limited recording capabilities in general. 16.53.48 # Clip plus 16.53.51 # and the PC-side tools are of course partially perl or shell scripts as well 16.54.21 # 158% factory clock... nice :) 16.54.31 # enthdegree: Now, what do you mean by "low quality"? What are your settings, recorded filetype, and what's wrong with the outputted file? 16.54.35 # (at factory Vcore) 16.54.48 # TheSeven: What is the slowest you can clock it? 16.55.05 # <[Saint]> 0Mhz idle? ;) 16.55.14 # enthdegree: that depends on the peripherals that need to work 16.55.28 # I think USB starts to cock up at <50MHz somewhere 16.55.39 Quit sasquatch (Quit: WeeChat 0.3.2) 16.55.48 # Llorean: The outputted file sounds more grainy than what I hear from the radio interface 16.56.02 # also the LCD interface speed scales linarly and is at ~25fps at 216MHz 16.56.03 # I will pull up my settings... 16.56.51 # <[Saint]> enthdegree: have you compared Fm recording to recording from line in? 16.57.03 # <[Saint]> your statement sounded to me as though it was worse. 16.57.45 # I have not, I will do that. 16.58.08 # enthdegree: is there some kind of buzzing or ticking involved? 16.58.10 Quit bluebrother (Ping timeout: 255 seconds) 16.58.46 # Does the ClipV2 record at full sample rate? 16.58.49 # Er Clip+ 16.59.04 # I seem to recall some of those players had restrictions in sample rate or bit rate (14 bit instead of 16?) 16.59.09 # Er bit depth 16.59.44 # By "those devices" though I just mean "sandisks that I can no longer keep straight" 16.59.59 Join bluebrother [0] (~dom@g226071161.adsl.alicedsl.de) 16.59.59 Quit bluebrother (Changing host) 16.59.59 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 17.01.14 # the UI is running at ~3fps @ 13.5Mhz 17.01.26 # USB works down to 27MHz apparently 17.01.49 # run mpegplayer 17.01.50 # <[Saint]> bet the UI feels nice and responsive ;) 17.03.34 Quit Keripo (Quit: Leaving.) 17.03.34 Join sideral [0] (~sideral@213.165.85.248) 17.03.34 Quit sideral (Changing host) 17.03.34 Join sideral [0] (~sideral@rockbox/developer/sideral) 17.03.34 Part LinusN 17.03.34 # hows the battery life on the classic now? 17.04.24 # the HDD is doing something, but failed to load rockbox.ipod @13.5MHz 17.04.24 Part Zagor 17.04.38 Quit B4gder (Remote host closed the connection) 17.05.24 # timccc: i have no idea 17.05.41 # but if i port undervolting and clock scaling, it should be better at least 17.06.11 Quit Judas_PhD (Quit: This is a quitting message) 17.06.12 Quit logbot (Ping timeout: 240 seconds) 17.06.12 *** ERROR: (Closing Link: giant.haxx.se (Ping timeout: 240 seconds)) from holmes.freenode.net 17.06.12 *** Cleanup 17.06.12 *** Cleanup 17.06.12 *** Saving seen data "./dancer.seen" 17.06.12 *** Exit 17.06.14 *** Started Dancer V4.16 17.06.14 *** Connected to irc.freenode.net on port 6667 17.06.14 *** Logfile for #rockbox started 17.06.14 Mode "logbot :+i" by logbot 17.06.18 *** Server message 501: 'logbot :Unknown MODE flag' 17.06.18 Join logbot [0] (~rockbox@giant.haxx.se) 17.06.18 Join sideral [0] (~sideral@rockbox/developer/sideral) 17.06.18 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 17.06.18 Join Dexpid [0] (~dexpid@cpe-69-133-107-162.woh.res.rr.com) 17.06.18 Join toffe82 [0] (~chatzilla@maf.wirelesstcp.net) 17.06.18 Join eGen_ [0] (generat0r@gate.mmdecin.cz) 17.06.18 Join L-Strife89 [0] (~Strife89@207-144-19-39.cstel.net) 17.06.18 Join MethoS- [0] (~clemens@134.102.106.250) 17.06.18 Join komputes [0] (~komputes@ubuntu/member/komputes) 17.06.18 Join mudd1 [0] (~cmertes@ip-78-94-203-49.unitymediagroup.de) 17.06.18 Join T44 [0] (~Topy44@f049141161.adsl.alicedsl.de) 17.06.18 Join panni_ [0] (hannes@ip-178-203-73-7.unitymediagroup.de) 17.06.18 Join evilnick_B [0] (0c140464@rockbox/staff/evilnick) 17.06.18 Join mystica555_ [0] (~mike@m312636d0.tmodns.net) 17.06.18 Join mystica555 [0] (~Mike@m312636d0.tmodns.net) 17.06.18 Join kevku [0] (~kevku@2001:7d0:0:f9af:215:c5ff:fe7e:794d) 17.06.18 Join casainho [0] (~chatzilla@pal-213-228-181-14.netvisao.pt) 17.06.18 Join CIA-70 [0] (~CIA@208.69.182.149) 17.06.18 Join Rob2222 [0] (~Miranda@p4FFF314C.dip.t-dialin.net) 17.06.18 Join Raptors [0] (~Raptors@dsl-67-212-28-189.acanac.net) 17.06.18 Join dfkt [0] (dfkt@unaffiliated/dfkt) 17.06.18 Join qurvel [0] (~qurvel@i220-109-51-195.s02.a007.ap.plala.or.jp) 17.06.18 Join DerPapst [0] (~Alexander@dslb-188-107-192-175.pools.arcor-ip.net) 17.06.18 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 17.06.18 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 17.06.18 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 17.06.18 Join rasher [0] (~rasher@rockbox/developer/rasher) 17.06.18 Join petur [0] (d408b802@rockbox/developer/petur) 17.06.18 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 17.06.18 Join efyx [0] (~efyx@lap34-1-82-225-185-146.fbx.proxad.net) 17.06.18 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 17.06.18 Join ender` [0] (krneki@foo.eternallybored.org) 17.06.18 Join Barahir [0] (~jonathan@frnk-590fc017.pool.mediaWays.net) 17.06.18 Join ThomasAH [0] (~thomas@aktaia.intevation.org) 17.06.18 Join parafin [0] (parafin@paraf.in) 17.06.18 Join ack` [0] (~ack@mingbai.org) 17.06.18 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) 17.06.18 Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) 17.06.18 Join markun [0] (~markun@rockbox/developer/markun) 17.06.18 Join YPSY [0] (~ypsy@geekpadawan.de) 17.06.18 Join TBCOOL [0] (~tb@c-3c3671d5.09-42-73746f22.cust.bredbandsbolaget.se) 17.06.18 Join logiclost [0] (~lostlogic@erudite.lostlogicx.com) 17.06.18 Join powell14ski_ [0] (~powell14s@c-67-177-228-132.hsd1.co.comcast.net) 17.06.18 Join ranmachan [0] (ranma@yumi.tdiedrich.de) 17.06.18 Join Farthen [0] (~Farthen@static.225.178.40.188.clients.your-server.de) 17.06.18 Join @ChanServ [0] (ChanServ@services.) 17.06.18 Join MagusG [0] (magusg@c-71-59-57-46.hsd1.ga.comcast.net) 17.06.18 Join gevaerts [0] (~fg@rockbox/developer/gevaerts) 17.06.18 Join scorche|sh [0] (~scorche@rockbox/administrator/scorche) 17.06.18 Join pikytcus [0] (~bigd@failbox.co.cc) 17.06.18 Join amee2k [0] (~thomas@ve504.cugnet.net) 17.06.18 Join Elfish [0] (amba@2a01:4f8:100:90a1:abc:abc:abc:abc) 17.06.18 Join Kohlrabi [0] (~kohlrabi@kohlio.de) 17.06.18 Join feisar- [0] (jljhook@ihq.in) 17.06.18 Join Loto [0] (~nfs@xbmc/user/Loto) 17.06.18 Join crwl [0] (~crwlll@dsl-jklbrasgw1-fe8edf00-29.dhcp.inet.fi) 17.06.18 Join preglow [0] (thomj@tvilling2.pvv.ntnu.no) 17.06.18 Join yosafbridge [0] (~yosafbrid@li125-242.members.linode.com) 17.06.18 Join dionoea [0] (~dionoea@videolan/developer/dionoea) 17.06.18 Join jepler [0] (~jepler@emc/developer/pdpc.professional.jepler) 17.06.18 Join balintx [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu) 17.06.18 Join bzed [0] (~bzed@devel.recluse.de) 17.06.18 Join Dhraakellian [0] (~ntryon@cpe-67-240-248-41.rochester.res.rr.com) 17.06.18 Join kkit|sh [0] (~kkit@li135-248.members.linode.com) 17.06.18 Join AlexP [0] (~alex@rockbox/staff/AlexP) 17.06.18 Join guymann [0] (~charles@69.182.30.171) 17.06.18 Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) 17.06.18 Join ehntoo [0] (~ehntoo@lug.mtu.edu) 17.06.18 Join n17ikh [0] (~n17ikh@c-68-59-25-51.hsd1.sc.comcast.net) 17.06.18 Join Sochiro [0] (~Sochiro@194.90.222.165) 17.06.18 Join Battousai [0] (~bryan@gentoo/developer/battousai) 17.06.18 Join Galois [0] (djao@efnet-math.org) 17.06.18 Join Quazgaa [0] (quaz@c-76-22-103-237.hsd1.wa.comcast.net) 17.06.18 Join jfc [0] (~john@pool-72-73-80-12.ptldme.east.myfairpoint.net) 17.06.18 Join Strife89 [0] (~Strife89@168.16.226.187) 17.06.18 Join jae [0] (~jae@dedicated.jaerhard.com) 17.06.18 Join plux [0] (~yogurt@h-34-156.A238.priv.bahnhof.se) 17.06.18 Join froggyman [0] (~seth@unaffiliated/froggyman) 17.06.18 Join linuxguy3 [0] (~timj@adsl-75-57-194-123.dsl.emhril.sbcglobal.net) 17.06.18 Join factor [0] (~factor@75.108.68.114) 17.06.18 Join milk [0] (~milk@94-193-93-226.zone7.bethere.co.uk) 17.06.18 Join [Saint] [0] (S_a_i_n_t@203.184.1.55) 17.06.18 Join enthdegree [0] (~enthdegre@cpe-024-211-171-023.nc.res.rr.com) 17.06.18 Join amiconn [0] (quassel@rockbox/developer/amiconn) 17.06.18 Join zu [0] (~zu@ks355000.kimsufi.com) 17.06.18 Join Kitar|st [0] (~Kitarist@BSN-182-129-226.dial-up.dsl.siol.net) 17.06.18 Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) 17.06.18 Join pixelma [0] (quassel@rockbox/staff/pixelma) 17.06.18 Join elcan [0] (user36@pr0.us) 17.06.18 Join mordocai_afk [0] (~mordocai@66.119.9.243) 17.06.18 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 17.06.18 Join krazykit [0] (~krazykit@99-126-205-52.lightspeed.cicril.sbcglobal.net) 17.06.18 Join timccc [0] (~timccc@112.166.15.141) 17.06.18 Join Guinness [0] (Slayer@c-68-55-111-159.hsd1.va.comcast.net) 17.06.18 Join Slasheri [0] (miipekk@rockbox/developer/Slasheri) 17.06.18 Join alexbobP [0] (~alex@ppp-70-253-65-89.dsl.austtx.swbell.net) 17.06.18 Join Xerion [0] (~xerion@5419A4D7.cm-5-2c.dynamic.ziggo.nl) 17.06.18 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 17.06.18 Join [fred] [0] (~fred@ircop.efnet.at) 17.06.18 Join literal [0] (~hinrik@w.nix.is) 17.06.18 Join simonrvn [0] (simon@197.230-ppp.3menatwork.com) 17.06.18 Join w0m [0] (~wom@199.19.225.128) 17.06.18 Join jordan` [0] (~jordan@jem75-13-78-235-252-137.fbx.proxad.net) 17.06.18 Join scorche [0] (~scorche@rockbox/administrator/scorche) 17.06.18 Join Zambezi [0] (Zulu@unaffiliated/zambezi) 17.06.18 Join iq [0] (~iq@unaffiliated/iq) 17.06.18 Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) 17.06.18 Join thegeek_ [0] (~nnscript@132.108.34.95.customer.cdi.no) 17.06.18 Join Bagder [0] (~daniel@rockbox/developer/bagder) 17.06.18 Join niekie [0] (quasselcor@CAcert/Assurer/niekie) 17.06.18 Join sinthetek [0] (~sinthetek@unaffiliated/sinthetek) 17.06.18 Join blast007 [0] (~blast007@bzflag/developer/Blast) 17.06.18 Join GodEater [0] (~bibble@rockbox/staff/GodEater) 17.06.18 Join sbhsu [0] (~a6530466@192.192.120.197) 17.06.18 Join vedos [0] (~draft@ihku.org) 17.06.18 Join soap [0] (~soap@rockbox/staff/soap) 17.06.18 Join aevin [0] (eivindsy@unaffiliated/aevin) 17.06.18 Join merbanan [0] (~banan@c-94-255-218-11.cust.bredband2.com) 17.06.18 Join FOAD [0] (~dok@83.161.135.61) 17.06.18 Join simabeis [0] (~simabeis@lobmenschen.de) 17.06.18 Join knittl [0] (~knittl@unaffiliated/knittl) 17.06.18 Join miceh [0] (~mtq@h1439481.stratoserver.net) 17.06.18 Join ved [0] (ved@ddsbox.co.cc) 17.06.18 Join maraz [0] (maraz@kapsi.fi) 17.06.18 Join pjm0616 [0] (~user@110.9.28.45) 17.06.18 Join Hadaka [0] (~naked@naked.iki.fi) 17.06.18 Join Rondom [0] (~rondom@lvps178-77-79-47.dedicated.hosteurope.de) 17.06.18 Join Utchy [0] (~Utchy@rps6752.ovh.net) 17.06.18 Join tmzt [0] (~tmzt@76.211.0.152) 17.06.18 Join Torne [0] (~torne@rockbox/developer/Torne) 17.06.18 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 17.09.56 Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) 17.11.11 Quit Judas_PhD (Client Quit) 17.12.35 Quit sideral (Remote host closed the connection) 17.12.49 Join sideral [0] (~sideral@213.165.85.248) 17.12.49 Quit sideral (Changing host) 17.12.49 Join sideral [0] (~sideral@rockbox/developer/sideral) 17.13.46 Quit liar (Ping timeout: 255 seconds) 17.14.40 Quit L-Strife89 (Quit: Returning to the other building.) 17.17.27 # was that gui boosting patch committed? 17.17.36 # <[Saint]> no 17.17.42 # i think it will be a prerequisite for ipod classic cpu clock scaling 17.17.49 # at <200MHz the LCD is lagging badly 17.18.13 # <[Saint]> It would be good to get it in, but it needs work. 17.18.20 Quit shai (Read error: Connection reset by peer) 17.18.22 # what's wrong with it? 17.18.27 # <[Saint]> it currently messes up keyclick spectacularly. 17.18.47 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 17.18.56 # <[Saint]> it uses key events to decide when to boost. 17.19.03 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 17.19.11 # <[Saint]> and...that is playing havoc with keyclick. 17.19.29 # <[Saint]> piezo and SW 17.19.58 Join Keripo [0] (~Keripo@SEAS235.wlan.seas.upenn.edu) 17.22.21 # hm, the PLLs don't like to lock at low frequencies 17.23.36 # is there a way to get the virtual address of the TTB on arm ? 17.23.58 Quit Dexpid (Remote host closed the connection) 17.24.47 # virtual address? 17.24.55 # it's wherever you mapped it :) 17.25.26 # pamaury: what are you planning to do? some kind of reverse page table lookup? 17.26.46 # I have no control over the virtual space, it's setuped by the WinCE bootloader, it seems the physical address I provide to the LCD controller doesn't match the virtual address I'm thinking about. So I would like to hva e alook at the translation table to understand :) 17.27.24 # Of course, there is the solution of setting up my own virtual space but... 17.27.48 # There's no way, anyway. 17.28.01 # You can get the physical address from TTBR in cp15 17.28.12 # yes but that's not really helpful 17.28.36 # no, I know. 17.28.37 # but that's it. 17.28.45 # pamaury: the first thing i'd do when playing with such a platform would be to kill the MMU :) 17.28.48 # you are expected to have mapped the pagetables yourself ;) 17.29.38 # damn, messed up some calculations above 17.29.47 # 96MHz seems to be the lowest speed that USB works at 17.29.56 # TheSeven: the difficult point is that each time I try to touch the MMU, I can't make the things work :) And I don't have JTAG or something similar 17.29.58 Join n1s [0] (~n1s@nl118-175-108.student.uu.se) 17.29.59 Quit n1s (Changing host) 17.29.59 Join n1s [0] (~n1s@rockbox/developer/n1s) 17.30.33 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 17.30.33 Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) 17.30.42 # Anyway, I'll continue to try until I suceed 17.30.43 Join LinusN [0] (~linus@rockbox/developer/LinusN) 17.32.06 # pamaury: are you relying on any bootloader services or something? 17.32.21 # if you fully take over control, fixing up the MMU shouldn't be hard 17.33.07 # There is bootloader, loading WinCE, but I don't fully understand how does it setup the virtual space. And currently, I can't get rid of WinCE code (it's using some weird format), so I overwrite parts of it 17.33.33 # It's just that I don't know much about ARM :) So I write buggy code ;) 17.33.44 # * TheSeven suggests to reverse the bootloader until you can get rid of all vendor code :) 17.33.50 # I can't 17.33.54 # I don't have access to it 17.34.01 # can't you dump it? 17.35.40 Quit [Saint] (Quit: I'm only going to Heaven if it feels like Hell, I'm only going to Heaven if it tastes like caramel...) 17.35.40 # what means of output do you currently have? 17.35.42 # Using some wince tools I found on the net, I dumped something which perhaps contains the bootloader, it's already a second stage bootloader. And the trick is the second seems to do calls to the first for all the hardware parts. And I don't have the first 17.35.59 # So I don't understand anything :) 17.36.07 Join sasquatch [0] (~username@2.210.55.230) 17.36.19 # then you can try to impersonate the second stage :) 17.40.36 # I can try to kill the MMU, setup a new stack and pray that gcc generated position independent code for the rest. Or else I'll have to copy it :-/ 17.41.17 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 17.41.59 Join [Saint] [0] (S_a_i_n_t@203.184.0.55) 17.43.59 # pamaury: PIC doesn't help you here 17.44.14 # in the worst case your code is scattered all around the memory 17.44.57 # yes but I'm optimistic and think it's contiguous :) 17.45.06 # so how do I disable the MMU ? 17.45.24 # so you basically need to allocate a contiguous region of pyhsical memory that doesn't contain any of your code, do a 1:1 mapping for that, copy the code there, jump there, and then kill the MMU 17.45.43 # woo, i managed to repair my tblcf! :-) 17.46.12 # * TheSeven 's ipod classic is idling at 23.6mA now 17.46.21 # nice 17.46.41 # TheSeven: which you can't do if you don't know where the pagetables are 17.46.44 # if I disable USB i can probably get way lower 17.46.50 # TheSeven: since you can't make mappings 17.46.56 # I can't, I must disable the mmu first 17.47.21 # There's no way to disable the MMU without the hardware basically immediately falling over, anyway. :) 17.47.22 # Torne: ah, right, the TTB base address is a physical address ./ 17.47.44 # Torne: yeah, at least if you don't know the current setup 17.47.47 # can you write to whatever's at physical address zero? 17.47.55 # i.e. is SDRAM there? 17.48.10 # if so you can probably do it by installing your own data/prefetch abort handlers 17.48.32 # then assuming that the machine will take an external abort after you disable the mmu 17.48.34 Quit [Saint] (Ping timeout: 250 seconds) 17.48.35 # Torne: I like that devious idea :) 17.48.45 # except quite possibly it won't, it depends where you are in the address space ;) 17.49.00 # you need to jump to a virtual address which you know doesn't map to anything as a physical address ;) 17.49.20 # what I know is that the running code is mapped at 0x8c000000. SRAM is normally at 0x30000000, registers seems to be identify mapped 17.49.37 # yeah you're probably screwed 17.49.46 # wait, I think there is a way to know the physical address 17.49.53 # Torne: how does icache behave if the MMU is being disabled? 17.49.57 # TheSeven: inconsistently 17.49.59 # let me dig into the wince nightmarish format 17.50.08 Join [Saint] [0] (S_a_i_n_t@203.184.0.84) 17.50.10 # so one can hope that it still executes a few "old" instructions? 17.50.15 # It will 17.50.21 # But you don't know how many 17.50.33 # but that will be enough to trigger an undefined instruction abort :) 17.50.46 # But that's only any use if the hardware has writable memory at 00000000 or FFFF0000 17.50.58 # since otherwise the undef abort will probably go to a rom vector 17.51.00 # if it doesn't you're screwed anyway 17.51.41 # I could do a conservative assumption: 0x8c000000 maps to 0x30000000 so I just disable the MMU and the link the code to 0x30000000 17.52.05 # dammit, USB is unstable in these conditions 17.52.07 # The problem ist hat disbaling the MMU is not atomic 17.52.17 # The next instruction is not guaranteed to execute witht he MMU disabled :) 17.52.25 # This is why you normally need an identity mapping 17.52.25 # but if you put nops ? 17.52.26 # if i switch it off i get down to 12.2mA drawn from the bus, so maybe like 10mA when running on battery 17.52.35 # pamaury: the problem is you have to put exactly the right number of instructions 17.52.37 # ah ok, I understand 17.52.42 # if you branch too early you die, if you branch too late you die 17.52.49 # and the right number may not be constant :) 17.52.53 # since it depends on the icache 17.53.15 # It's probably possibel to figure out a way to do this that's reasonably reliable but it won't be particularly easy. 17.53.28 # It's likely that the whole of SDRAM is mapped as a single block 17.53.35 # I'd suggest just dumping the whole of where it would logically be 17.53.45 # and looking for things that appear to be PDEs in there 17.53.54 # since it's probably not a complicated mapping 17.53.56 Quit Keripo (Quit: Leaving.) 17.53.58 # pamaury: can you write to virtual 0x30000000? 17.54.14 # didn't try 17.54.52 # what means of output do you have currently? 17.54.57 # can you download big amounts of data? 17.55.25 # I can write to the LCD 17.56.02 # I just let windows setup the memory and then take control 17.56.36 # there is another option: reverse engineer WinCE mmu code 17.58.28 # hm, 12.5-17mA depending on the cpu load @96MHz, Vcore=0.95V 17.59.29 # oops 17.59.33 Quit petur (Quit: Page closed) 17.59.47 # locking the hold switch increases the current by ~3.7mA 17.59.56 # what the hell 18.02.01 # er, that was 24MHz actually :P 18.03.20 # haha, I've come up with a nastu idea 18.03.25 # *nasty 18.03.43 # * TheSeven wonders if he should just commit the voltages that work for him and see if people complain 18.04.29 # I should have think about it earlier: I can ask WinCE to identify map the SDRAM ! 18.04.42 # *identity 18.07.01 # oh damn, there's another thing that's holding back clock scaling: 18.07.07 Quit t0rc (Quit: Give someone code, help them with one project. Teach someone to code, help them rule the world.) 18.07.10 # the timers seem to be derived from the cpu clock :/ 18.07.44 # haha, you can slow down the worl which such a device :) 18.07.48 # *world 18.07.52 # *with 18.10.06 # hm, i can actually change the PLL division factors without the device crashing, even if the CPU clock is coming from that PLL 18.11.04 # USB works at 51MHz, is unstable at 48MHz and unusable below that 18.11.22 # TheSeven: Out of interest: How are you measuring these currents -- with an on-chip meter + ADC or with an external meter hooked up to the battery? 18.11.34 # external meter on the USB bus 18.11.44 # i haven't figured out how to use the internal one yet 18.12.01 # and on the nano2g the internal one seems to have a ~7mA offset, so that isn't very usable either 18.12.55 Quit kevku (Ping timeout: 272 seconds) 18.13.15 # TheSeven: Wouldn't you only be able to measure the charge current on the USB bus? 18.13.39 # if the battery is fully charged i get reasonable values 18.13.58 # ah, interesting, thanks 18.13.58 # (the charger is only acting as an LDO regulator in that case, and eating like 1mA by itself) 18.14.13 # arrrrrrr 18.14.29 # seems like the ATA UDMA timings are derived from the CPU clock as well :/ 18.14.31 Part LinusN 18.17.42 Quit evilnick_B (Ping timeout: 245 seconds) 18.29.27 Join Keripo [0] (~Keripo@eng069.wireless-resnet.upenn.edu) 18.37.42 Quit DerPapst (Quit: Leaving.) 18.38.04 Join Dreamxtreme [0] (~Dre@92.30.213.148) 18.38.05 Join GeekShadow [0] (~Antoine@ree79-1-78-237-225-34.fbx.proxad.net) 18.38.06 Quit GeekShadow (Changing host) 18.38.06 Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) 18.38.18 Join Jerom [0] (~jerome@79.132.59.245) 18.43.00 Join dfkt|x [0] (~dfkt@unaffiliated/dfkt) 18.43.21 Quit Galois (Quit: Leaving) 18.47.35 Quit sideral (Quit: Leaving.) 18.54.44 Quit dfkt|x (Remote host closed the connection) 19.02.17 Join Galois [0] (djao@efnet-math.org) 19.06.16 *** Saving seen data "./dancer.seen" 19.07.53 Join datagutt [0] (~datagutt@unaffiliated/datagutt) 19.15.33 Join mlt- [0] (~8654d106@giant.haxx.se) 19.17.57 # Is anyone with an Android build environment able test http://www.rockbox.org/tracker/task/11924 ? 19.19.54 Join nieuwbie [0] (~user@ip4daa4a6f.direct-adsl.nl) 19.20.28 # Hello, I have a problem with rockbox toolchain. 19.21.38 Quit mlt- (Quit: CGI:IRC) 19.22.08 Quit shai (Read error: Connection reset by peer) 19.22.35 # I tried to compile hello world from freemyipod on emCore, but I've got a *PANIC*. 19.25.06 # linuxstb: Just see if it builds? 19.25.07 Join MaynardWaters [0] (~asdfjkl@cpe-098-026-093-093.nc.res.rr.com) 19.26.11 Join {phoenix} [0] (~dirk@p57AA5035.dip.t-dialin.net) 19.26.24 # AlexP: What would be useful is to create two new build directories - run the current configure (but nothing else) in one, and then apply my patch and run the patched configure in the other build directory. Then do a diff on the two directories and see if the generated autoconf.h and Makefiles are the same. 19.26.41 # linuxstb: OK, no problem 19.27.16 # I spoke about it with TheSeven, and he analysed the binary and suggested that relocs from .text to .data/.bss are apparently relative to the start of .data/.bss instead of .text so it seems like linking step problem or maybe some inportablility in the linker script. 19.27.42 # er, does this really belong here? 19.27.49 # the very same toolchain links it correctly for me 19.28.19 # hmm 19.28.29 # and it isn't really "the rockbox toolchain" but rather the gnu toolchain built by rockboxdev.sh with some rockbox-specific patches applied 19.28.37 # ... 19.28.54 # Well my mistake then. 19.28.57 # Is this relevent to Rockbox? 19.29.42 Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) 19.31.26 # linuxstb: http://pastebin.com/AGPS5Hfc 19.32.21 Join kugel [0] (~kugel@rockbox/developer/kugel) 19.33.43 # TheSeven: So the problem should be relative to Machine or compilation, right? 19.34.33 # I would like to commit FS#11216 before the freeze. is anyone opposed? 19.35.28 Join DerPapst [0] (~Alexander@p4FE8EE1C.dip.t-dialin.net) 19.36.28 # kugel: I can't comment on the patch itself, but I think that since we're not frozen yet, that should be OK 19.36.38 # kugel: No comment on the technical side obviously, and I think embedded album art is a bit silly, but sure, why not - it'll help people out 19.37.09 Quit powell14ski_ (Ping timeout: 272 seconds) 19.37.21 # I also find it silly, but a fellow student bugged me that rb doesn't show AA on his desire ;) 19.38.09 # * TheSeven wonders where that code grabs its memory from 19.38.31 # does this mean a 150KB ramsize hit, or is it doing something more clever? 19.38.39 # it reads the mp3 as jpeg, with an appropriate offset and max size; since for id3v2 the jpeg file is embedded as blob 19.38.57 # so directly from the MP3 file to the framebuffer? 19.39.00 Join powell14ski_ [0] (~powell14s@c-67-177-228-132.hsd1.co.comcast.net) 19.39.13 # to the audiobuffer, just like normal albumart 19.39.30 # ok, so no memory overhead (except binsize of course) involved? 19.39.58 Join TheLemonMan [0] (~lem0n@ppp-170-133.98-62.inwind.it) 19.39.59 # kugel: hm, wasn't there this issue with escaping some byte sequences? 19.40.15 # TheSeven: yes 19.40.51 # gevaerts: that's for desync'd pictures, which are simply unsupported yet 19.41.03 # I haven't seen one in reality so far 19.41.18 Join Horscht [0] (~Horscht@p5DD57965.dip.t-dialin.net) 19.41.18 Quit Horscht (Changing host) 19.41.18 Join Horscht [0] (~Horscht@xbmc/user/horscht) 19.41.23 # kugel: what's the impact if there is one? 19.41.38 # a desync one? 19.41.41 # yes 19.41.50 # none 19.41.53 # ok 19.42.00 Part nieuwbie ("ERC Version 5.3 (IRC client for Emacs)") 19.42.41 # the metadata rejects to parse this then (unsync'ing is supported in our parser, but more tricky for large data such as album art) 19.43.46 # If it doesn't crash and audio and other tags are still handled correctly (or as correctly as before), I think that's fine 19.44.41 # AlexP: Thanks. I forgot APP_TYPE... 19.45.05 # wasn't there some buffering guy who had objections about the patch in general (at some point), I didn't follow though 19.45.13 # kugel: ^ 19.45.48 # that was when the patch still needed some spare buffers which is not the case anymore 19.46.32 # I and several people had objections that the initial patch used the codec buffer for storing the decoded image 19.46.51 # kugel: Your patch is just for mp3/id3v2? 19.47.01 # yes 19.47.35 # do I mean to do something special after writing an entry of the TTB ? 19.48.09 # kugel: Any idea about other formats of album art in mp3s, e.g. could a PNG be there, and would your code try to parse it as a jpeg? 19.48.37 # it checks the mime type so png is rejected 19.49.42 # and IIRC the jpeg decoder checks for the presence of jpeg magic as well 19.51.07 Quit GeekShadow (Ping timeout: 276 seconds) 19.52.13 # kugel: Well, it obviously needs extending to other file formats, so IMO the question is whether we want to put an incomplete feature in 3.8, or commit it after 3.8 and hope other formats are implemented by 3.9... 19.53.56 # linuxstb: isn't that similar to not releasing 3.0 because we didn't have wma pro yet? 19.55.14 Quit qurvel (Ping timeout: 246 seconds) 19.58.40 Join saratoga [0] (9803c6dd@gateway/web/freenode/ip.152.3.198.221) 19.58.44 # linuxstb: I wouldn't say it's incomplete 19.59.08 # gevaerts: It'd be like not releasing 3.0 because the "artist" tag only works for Mp3 and not any other metadata... 19.59.40 # gevaerts: I'm not sure about that example, but I'm sure we've released incomplete features before... Another concern could be that this is dealing with core playback code, so bugs would be serious. 19.59.49 # I don't think it's particularly bad to commit it right after the release branch. 19.59.54 # where is the jpeg decoder currently located? in the main binary or plugin? 19.59.57 # id3v2 does advice against desync metadata, it's ok to not support it IMO 20.00.10 # Just in case there are unforseen bugs in it, too, as well as it being one of those features where it may not be easily clear to users when it will or won't work and why it's not working. 20.00.22 # It has a high "is this a bug?" "no it just doesn't do that yet" probability 20.00.26 # for other formats it's not as simple to implement (and I have little interest to do it currently) as they not always binary blobs 20.01.24 # we also don't support other types of jpeg in our decode, that hasn't been a problem so far 20.02.08 # kugel: I'm just playing devils advocate a little to see what others think - I'm not strongly against committing it, as it's a long-requested feature and mp3 is probably still the most-used format... I'm also not expecting you to implement other formats - commit mp3 and others will no doubt add others over time. 20.02.16 # this patch catches the vast majority of cases as I see it 20.03.09 # Isn't album-art-in-metadata incredibly common in AAC as well? 20.03.13 # Well, MP4 in general 20.03.25 # Llorean: right, that's a bit closer 20.03.32 # Llorean: no idea 20.03.54 # Also, to a lesser extent, FLAC I think, where a lot of whole-album CUE+FLAC seems to be not too uncommon. 20.03.58 # The one track I bought from itunes had embedded AA - I've no idea if they all do... 20.04.11 # But really MP4 is I think the one that needs to be addressed if the goal is "vast" majority 20.04.44 # I'd say MP3 is probably the majority, but not by as wide a margin as it could be now that iTunes is DRM-free in many cases. 20.04.47 # that's not the goal 20.04.59 # considering our MP4 parser is barely functional at this point, it may be premature to worry about album art in it 20.05.04 # kugel: You were claiming you felt it catches the vast majority of cases, I'm just saying I'm not certain that's true. 20.05.55 # I don't think I've ever acquired an MP3 with embedded album art, but I know that many MP4 files I've come across have had it. 20.06.00 # I think AAC more common among (new) ipod users, but not so much for all other people 20.06.10 # FLAC at least seems to be just a binary blob - http://flac.sourceforge.net/format.html#metadata_block_picture 20.06.44 # I'm just saying I'd like to suggest it wait for after 3.8, both so that it has a longer bug shakedown period, and in the hope that *someone* implements it for more of the major formats. 20.07.05 # I don't really see that as a majorly negative thing, to wait a short time. 20.07.56 # Checking my mp4 file - a hexdump shows that the jpeg data appears to just be a binary blob. 20.08.04 # If 3.9 comes along and the situation has improved, at least there's been time for a manual entry to have been written, us see if it caused confusion about what's supported, clarifications to be made, etc. 20.08.12 # Er *hasn't* improved 20.08.38 # I don't think it's very risky as the unsupported cases are pretty much catched. and there's still more than two weeks left 20.08.41 # * Llorean is okay with only jpeg being supported by the way, PNG or BMP in metadata seems somewhat insane. 20.08.59 # does png album art work as separate files right now? 20.09.06 # no 20.09.21 # I just saw PNG asked about above, so included it there, is all 20.09.44 Quit liar (Ping timeout: 255 seconds) 20.10.41 # I just don't think we'd say "only MP3 gets album art from files" is good enough for a release, so I'm not sure why it's a good idea to do it for embedded when we can wait a couple weeks, then hopefully some interest might grow before the next release and we can say "many common embedded album arts will be displayed" 20.10.58 # Is there some urgency to this going in I'm missing? 20.11.30 # Llorean: why wouldn't we accept only mp3 files for a release? 20.12.13 # I would like to see it in 3.8, it hopefully increases the chance for adoption to other formats sooner 20.12.16 # gevaerts: Is there a good reason it shouldn't work for the other formats, if the data is already available to us in a format we can recognize? 20.12.34 # kugel: How does having it in 3.8 make it more likely to be improved than having it in the daily build? 20.13.05 # many people are using releases and not current builds 20.13.08 # Llorean: no, but is there a good reason to deny it to mp3 users because there are other formats? 20.13.15 # Even though I first mentioned it, I don't really see a problem with "Support for embedded album art - currently only MP3 files" 20.13.23 # kugel: That doesn't explain how it increases the likelihood of new development. 20.13.35 # gevaerts: We're not. It'll be in the daily build at the time of 3.8 release. 20.13.53 # Llorean: we're trying to get regular users to use stable releases 20.13.56 # gevaerts: I'm not suggesting any delay to it beyond the release, and it'll be in 3.9 even if it doesn't improve. 20.14.06 Join petur [0] (~petur@rockbox/developer/petur) 20.14.11 # anyway, as nobody is strongly opposed I'll put it in 20.14.22 # * Llorean likes being "nobody" 20.14.25 # I think that the potential of (serious) bugs is the only possible issue, and I think it's up to the indiviual developer to estimate that 20.14.33 # Llorean: are you strongly opposed now? 20.14.38 # kugel: I'm opposed. 20.14.40 # I stated that. 20.14.42 # you weren't some minutes ago 20.14.42 # i don't really see the need to encourage regular users to use any particular build 20.14.56 # kugel: I've been saying I don't think it should go in until after 3.8 is branched this whole time. 20.15.24 # I just think there's no harm in delaying it until 3.8 20.15.26 # kugel: no, I meant your patch and a discussion from last week or so 20.15.27 Join markun_ [0] (~markun@rockbox/developer/markun) 20.15.50 # You can go ahead and commit it, I just don't appreciate the idea that nobody opposed it. 20.16.03 # Llorean: he said "strongly opposed" 20.16.08 # That's not the same as "opposed" 20.16.20 # gevaerts: "strongly" is so thoroughly subjective that it's not reasonably useful here. 20.16.44 # gevaerts: "strongly enough to object to it being committed", which I have. 20.16.51 # pixelma: then that was probably Unhelpful about desync files 20.17.11 # the patch as of now doesn't use additional buffers and leverages the existing album art system 20.17.24 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 20.17.25 # gevaerts: The alternative would be "weakly enough to say 'I don't like it, but I don't stand in the way of delaying it'" 20.17.33 Quit markun (Ping timeout: 240 seconds) 20.17.40 # kugel: How hard would it be to adapt it for use in other formats where the jpeg data is a binary blob? 20.17.52 Join sideral [0] (~sideral@213.165.85.248) 20.17.52 Quit sideral (Changing host) 20.17.52 Join sideral [0] (~sideral@rockbox/developer/sideral) 20.17.57 # I don't know, I haven't looked into other formats 20.18.20 # except ogg vorbis where I found *very little* information about it 20.18.29 # What I mean to ask is, is what you've put in place relatively flexible/expandable, or deeply ingrained into ID3 in some manner? 20.19.13 # it's expandable, but the parser needs to implement it 20.21.55 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 20.21.55 Quit bertrik (Changing host) 20.21.55 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 20.22.44 # I don't see the issue with just saying currently only MP3 files as linuxstb said 20.22.49 # I guess there's no strong reason not to include it now. I'm against it because I feel there's no harm in waiting, and I'd really like us to be able to advance it in the changelog for a release as "most common embedded album art" rather than just "ID3 embedded album art" 20.23.02 # announce it, rather 20.23.30 # I'd dislike just as much if we only supported the "title" tag in MP3 but not Ogg, MP4 or others. 20.23.35 Quit casainho (Remote host closed the connection) 20.24.32 Join mlt- [0] (~8654d106@giant.haxx.se) 20.24.50 # But I don't understand the metadata system, so I don't understand why we can decode the data from one format, but others might have it the same way and we can't extract it for decoding? 20.24.58 # * linuxstb spots that $cmdline is broken with his RaaA configure patch, as they all have the model name "application"... 20.25.09 # the patch is already 9 month old 20.25.35 # I'm still trying to build simulator under MS Windows. Can someone take a look what "tools/genlang" may not like among options? http://pastebin.com/UfkZtmY1 20.25.47 # * gevaerts doesn't really like the idea of always waiting until a feature is as perfect as it's likely to ever get before committing 20.26.11 # Llorean: I also don't know the metadata system very well, the id3v2 parser isn't my work actually. I only fixed the buffering side 20.26.23 # Llorean: It's not a matter of "can't", it's just that it hasn't been implemented in all metadata parsers. 20.26.25 # mlt "under Windows" how? 20.26.29 # gevaerts: As I said, I only suggest waiting until after the 3.8 branch, so it gets better shakedown before being in a release. 20.26.42 # gevaerts: I even said explicitly, if it still hasn't been expanded by 3.9, it goes in anyway 20.27.02 # gevaerts: Just a *small* delay in the hopes that having it in SVN will prompt the "rounding out" of the feature before it's in a release. 20.27.04 # pixelma: I mean if someone is familiar with that genlang tool 20.27.10 # mlt-: ah, that's where I stopped my last adventure about compiling under windows 20.27.13 # gevaerts: Since many things get less attention as patches. 20.27.29 # So I'm not proposing any prevention of the commit, at all 20.27.33 # Just timing of it. 20.27.45 # mlt-: and I meant to ask which build environment you use ;) 20.28.08 # kugel: last time we figured out that command line is too long for windows. So I used @response file for gcc to shorten it. But I'm stuck with this genlang now :( 20.28.12 # Llorean: waiting a bit is indeed an option, but my (rather strong) opinion is that unless we're in a freeze (and we're not) it's up to the committer to decide if the feature is likely to be stable in time for release 20.28.16 # I question the existence of the freeze (or it's length) if new features can't go in a couple of days before it 20.29.03 # I agree - otherwise we might as well start the freeze now 20.29.07 # pixelma: I'm using MinGW gcc 4.50 with make 3.81. I'm running Windows XP SP3 32 bit 20.29.11 # 4.5.0 20.30.16 # However, should anyone try and commit a new feature after Sunday I'll hit then with a sharpened stick :) 20.30.23 # gevaerts: It is up to the committer, and I don't dispute that. I'm just offering my opinion that in the case of a feature like this, were I the committer I'd certainly wait since I think it'll provide a better all around user experience that way. 20.31.38 # AlexP, kugel, gevaerts: I've never liked the idea of "squeeze a feature in shortly before the freeze." I think the feature freeze is a "no features period" but the more likely the feature is to have bugs, the further before the freeze someone should be thinking "do I really want to commit this now with a release coming up?" since we've seen releases delayed for a *long* time by new features too late before them (longer than our freeze period). 20.31.47 # But in the case of this one, I'm not saying it's buggy or even that I think there will be bugs. 20.31.53 # I just think it will be better over all if it waits. 20.32.05 # waiting even more is always an option 20.32.37 # I think it makes no difference when between freezes something gets added as long as the committer thinks it'll be OK by the next release. It is the same if it is three months before or three days before 20.32.56 # * mlt- was surprised that genlang turned to be a perl script... 20.33.11 # but commit early, commit often also and I prefer that (that shouldn't imply the embedded AA patch needs any post-commits, not that I'm aware of anyway) 20.33.35 # But of course, whould this turn out to be broken I'll beat kugel with a shoe :) 20.33.40 # Commit early is good. It's sad that it's been in the tracker for 9 months, and this conversation would've been completely different from my side if this was taking place even 2 or 3 weeks ago. 20.33.44 # s/whoud/should/ 20.33.57 # kugel: speaking of AA... Do you still have plans for the *other* AA? :) 20.34.04 # I just feel it's very close to the release now, and there's not significant harm in waiting, and multiple advantages (from my perspective) in doing so. 20.34.21 # gevaerts: I want to have a look in my semester break 20.34.23 # If the branch is Sunday, that's waiting 4 days for the commit 20.34.32 # freeze is sunday 20.34.38 # branch a week after that 20.34.47 # Ah, well slightly longer then. 20.34.53 # but I think it'd be nice for 3.8 20.34.59 # anyway, it is up to kugel 20.35.15 # It is up to Kugel. I just really would like to see it for at least MP4 when we announce it. 20.35.51 # I wouldn't be entirely certain that more of our users don't have that than MP3 embedded considering how many iPod users we seem to have. 20.36.16 Quit liar (Quit: Leaving) 20.38.22 # Does rockbox, allow you to do some type of 5 star rating which can be written to the id3 tags? during playback? 20.39.31 # There is rating, but it gets stored in the Rockbox database 20.39.57 Join leavittx [0] (~lev@89.221.199.187) 20.40.49 # I am no expert on id3 tags, but v1, v2 and v2.3.... at least one of those has data for some type of 5 star rating, I believe, ... 20.40.59 # We don't write to your music files at all 20.40.59 # I'd rather not have rockbox change the audio files it plays back 20.41.45 # Someone could write a plugin that would read ratings in the database and write them out to files or something, but it may be best left to that sort of manually triggered operation. 20.41.45 # I can understand that, avoids having to deal with the stock firmware issues, I am guessing 20.44.03 Join thomasjfox [0] (~thomasjfo@dslb-088-065-007-142.pools.arcor-ip.net) 20.49.07 Join p3tur [0] (~petur@rockbox/developer/petur) 20.50.48 # * mlt- found out that perl from MinGW badly treats -s option that causes troubles for tool/genlang 20.52.40 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 20.52.44 Quit Keripo (Quit: Leaving.) 20.53.29 # linuxstb: ping 20.54.52 # thomasjfox: Hi 20.54.57 # he 20.55.02 # Just gave your patch a test run 20.55.17 # Oh well, it doesn't compile anymore 20.55.33 # "No rule to make target `/home/maemo/MyProjects/rockbox/BUILD/sim_tasks.h', needed by `/home/maemo/MyProjects/rockbox/BUILD/apps/main.o'" 20.56.11 # also maemo4cc needs SDL, glib and libosso, too. 20.56.19 # Can you compare the autoconf.h and Makefile created by my patch with the current version of configure? 20.56.34 # make reconf dies with: "Please select a supported target platform!" 20.56.38 # I've made a few more changes this evening and am about to upload a new version of the patch. 20.56.46 # Yes - make reconf is something I've just fixed (I hope) 20.56.50 # ok 20.57.11 # I also noticed maemo4cc doesn't have -O2 20.57.54 # But its a bit of a hack at the moment because RaaA is using "application" for the modelname for all RaaA targets. 20.58.52 # regarding the autoconf.h compare, I think it's better to wait for the updated version of your patch 20.59.33 # OK, I've just fixed maemo4cc I think. 20.59.36 # linuxstb: IIRC modelname is only interesting for the target tree 20.59.59 # kugel: grep tells me it's also used in buildzip.pl 21.00.19 # for creating rockbox-info.txt? 21.00.55 # thomasjfox: I'm going to commit the codec buffer patch 21.01.12 # ucontext needs to wait a bit longer I'm afraid 21.01.12 # kugel: already christmas? 21.01.42 # that's fine 21.01.59 # I'll try to look into the shutdown() sequenze right now 21.02.21 Join Keripo [0] (~Keripo@law256.wlan.law.upenn.edu) 21.03.19 # thomasjfox: New version of patch added. 21.04.15 # ok 21.05.17 # linuxstb: Just an idea: Can't we have a unified maemocc like before and pass the desired version number as $1? 21.06.05 # thomasjfox: I was just thinking about that. Or maybe a "maemocc_common" function? 21.06.19 *** Saving seen data "./dancer.seen" 21.06.32 # maemocc would do ;) 21.06.50 # If the function ever would get too big, we could still split it later on 21.07.48 Quit datagutt (Quit: kthxbai) 21.10.33 # linuxstb: still fails at sim_tasks.h. I'll try to compare autoconf.h and Makefile 21.12.05 # * TheSeven starts to understand the s5l8702 clocking 21.12.20 # and there's bad news :/ 21.13.07 # seems like the AHB:APB ratio must be at least 2:1 21.13.10 # even at low base clocks 21.13.22 # New commit by 03kugel (r29259): Embedded album art support in MP3/ID3v2 tags. ... 21.13.39 # that's really nasty as it means that we can't go below 108MHz without affecting timers etc. 21.13.55 # (APB running at 54MHz) 21.14.15 Quit {phoenix} (Remote host closed the connection) 21.14.16 # linuxstb: autoconf.h is identical, Makefile diff is here: http://pastebin.com/cFuTr8DM 21.14.36 Quit mystica555_ (Read error: Connection reset by peer) 21.14.46 # TheSeven: how much difference does lower freq make? a lot of new chips seem to not be much affected by the freq but rather how much they sleep 21.15.08 # linuxstb: Wild guess: It's the missing APP_TYPE=sdl-app 21.15.15 # what does seem to matter is the AHB frequency 21.15.40 # thomasjfox: Hmm, but it's not _the_ sdl-app... 21.16.04 # annoying "suspicious change request" warning on the wiki... 21.16.05 # linuxstb: Still uses various parts from it (kernel, button stuff etc.) 21.16.24 # n1s: and i still have the suspicion that rockbox isn't sleeping very well 21.16.40 # thomasjfox: Yes, I'll add that. I'll also revert back to maemocc and add the version as a parameter. 21.16.40 # it reproducibly sucks more current when it's idle than when it's playing music, on multiple targets 21.17.00 # linuxstb: And install scratchbox ;) 21.17.10 # thomasjfox: app_type shouldn't be sdl-app for maemo I think 21.17.28 # nasty thing is that you don't have logical or in Makefiles 21.18.13 # TheSeven: ah, didn't know that but i meant more when the core sleeps for a tcik because it has nothing to do during playback doesn't cost much 21.18.19 # r29259 build result: 329 errors, 20 warnings (kugel committed) 21.18.28 # thomasjfox: Yes, I should do that... ;) Plus the Android stuff. 21.18.56 # kugel: Nice commit :o) 21.19.39 Quit leavittx (Ping timeout: 260 seconds) 21.20.24 # which one was it this time? charcell? greyscale? hwcodec? :P 21.20.29 # yes :) 21.20.31 # kugel: How does pictureflow deal with embedded? Still just ignores it I guess? 21.21.00 # good question 21.21.05 # I assume it does 21.22.56 # New commit by 03kugel (r29260): Fix red. Not all targets have album art support. 21.23.11 # kugel: so basically charcell? :P 21.23.20 # TheSeven: and monochrome 21.24.36 # kugel: Congrats on embedded album art support. I was really missing it! 21.25.05 # ah good, so we have at least one developer using it ;) 21.26.47 # the commit message is missing "in core" 21.27.01 # oh sorry 21.27.28 # New commit by 03kugel (r29261): Disable buffering codecs (and code generally) on RaaA. ... 21.27.40 # r29260 build result: 54 errors, 20 warnings (kugel committed) 21.32.38 # r29261 build result: 54 errors, 20 warnings (kugel committed) 21.32.54 # well, at least no *new* errors :P 21.34.14 Quit milk (Ping timeout: 260 seconds) 21.35.41 Quit factor (Ping timeout: 255 seconds) 21.37.51 Quit enthdegree (Quit: leaving) 21.37.51 Join milk [0] (~milk@94-193-93-226.zone7.bethere.co.uk) 21.38.37 # * mlt- has successfully built working rockboxui.exe under MS Windows 21.38.41 # New commit by 03kugel (r29262): Fix remaining reds. 21.38.52 # mlt-: great! 21.39.20 # can someone add me to wiki users group so I can add few words on my experience as out-of-the-box build is ultimately broken? 21.40.12 # mlt-: what's your username? 21.40.39 # I tried to register with wiki name MikhailTitov 21.41.02 # I'm not sure where to enter it though) 21.41.58 # mlt-: You'll need it once you click on "Edit" 21.42.49 # mlt-: done, promise not spam :) 21.43.34 # r29262 build result: 56 errors, 0 warnings (kugel committed) 21.44.13 # huh 21.46.50 # Thanks! I don't have time right now, but I'll explain probably later today what needs to be changed for UI simulator under MS Windows. 21.47.03 # bye! 21.47.23 Quit mlt- (Quit: CGI:IRC) 21.48.48 # kugel: are you color blind? you fixed yellows, not reds :P 21.49.26 # wrong. I fixed all reds and introduced other ones ;) 21.49.49 # the numbers are misleading :) 21.51.15 # New commit by 03kugel (r29263): Hopefully all green now 21.55.21 # r29263 build result: All green 21.55.41 # \o/ 21.55.43 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 21.56.13 # kugel: \m/ 21.57.37 Quit benedikt93 (Quit: Bye ;)) 21.57.41 # thomasjfox: did I forget anything to commit (except ucontext)? 22.03.32 # dammit 22.03.36 # stupid hold switch 22.04.00 # * TheSeven has never seen a player before whose hold switch has been that hard to read out 22.04.12 # it's still glitching even with a majority detect across 5 samples! 22.04.56 # kugel: All in :) 22.05.48 # * TheSeven wonders why plugins are data aborting 22.05.55 # did someone forget to bump the api? 22.12.02 # TheSeven: a full remake would fix it if that's the problem 22.13.07 # yeah, i'm running with an old set of plugins 22.13.13 # but that still shouldn't happen 22.13.49 # yes, true, i just meant that if that fixed it it would indicate that api breakage was indeed the problem 22.15.08 # sometimes things that don't directly touch the plugin api structs still break the binary compatibility though 22.15.33 # like changing a struct somewhere 22.16.52 Join factor [0] (~factor@75.108.68.114) 22.18.02 Quit efyx (Quit: Quitte) 22.19.12 Join wodz [0] (~wodz@87-206-240-131.dynamic.chello.pl) 22.20.20 # Leaked SDK for rockchip rk27xx is the most buggy piece of code I have ever seen! 22.20.36 # pixelma, AlexP: can you check this patch for the manual? http://pastie.org/1546611 22.23.30 # kugel: It was already there, but line 13 we should use \disk{} instead of disk I think 22.24.00 # And line 14 picture not pictures 22.24.21 # Actually, again already there, but I think image(s) is better than picture(s) here 22.24.43 # out of interest, what does unsynchronized mean in this context? 22.25.08 # but yeah, looks fine :) 22.25.32 # you can fix the bits you mentioned and commit if you like 22.25.43 # OK, will do 22.25.50 Quit factor (Ping timeout: 276 seconds) 22.26.36 # unsynchronized means that it has addtional zero bits to split up 11111111111 sequences which is some special mpeg marker 22.27.05 # And did you try pictureflow? We should mention here if embedded doesn't work in pictureflow 22.27.11 # http://hackage.haskell.org/packages/archive/idiii/0.1.2/doc/html/ID3-Parser-UnSync.html 22.27.29 # I'll have a look at pictureflow 22.28.12 Quit Keripo (Quit: Leaving.) 22.29.34 # cheers 22.30.39 # I find the embedded jpeg in \fname a bit odd, but I guess it only looks weird in code, not in the compiled manual 22.31.03 Join factor [0] (~factor@75.108.68.114) 22.32.40 # hmm, we have embedded album art support now? 22.33.21 # and why put the "embedded jpeg" in \fname? I don't see a reason for not putting it as plain text 22.33.37 # pixelma: I'm just looking, but I'm guessing it'll fit better 22.34.12 # yeah, no need 22.35.11 Quit n1s (Quit: Ex-Chat) 22.35.21 # Shouldn't it be JPEG? 22.36.09 # aye, 22.36.33 # true. 22.37.46 # n1s: updating fixed the plugins problem, so someone indeed didn't bump the API 22.37.50 Join stripwax [0] (~Miranda@87-194-34-169.bethere.co.uk) 22.38.11 # => we should maybe make sure bumped it will get bumped at least once before the release 22.39.36 # AlexP, linuxstb, kugel: isn't this the list of which type of files/pictures are supported and which take priority? 22.39.44 # New commit by 03theseven (r29264): iPod Classic: This time really fix the hold switch. Read it out through the power manager, and cache the result for 100 milliseconds because the power ... 22.39.52 # pixelma: yes 22.40.08 # well, it was filename and then priority 22.40.14 # and does an embedded file really take priority over external images? 22.40.17 # So we don't actually need the JPEG I think 22.40.19 # pixelma: yes 22.40.35 # hmm 22.40.37 # (see kugel's commit message) :) 22.41.15 # I think this makes sense - this way you can have e.g. an album folder.jpg but override t for a specific track 22.41.44 # Doesn't using "trackname.jpg" do that? 22.42.03 # yes 22.42.13 # that should also work 22.42.20 # hm, one can once again hard lock rockbox by plugging/unplugging usb too fast 22.42.24 # but I mean for people who use embedded albumart 22.42.24 # AlexP: pictureflow is tricky, as it prefers album art over track art 22.42.55 # kugel: Does it do anything with embedded at the moment? 22.43.32 # I guess for that look for an album art on disk then if you don't find it use the first track art you find for an album 22.43.38 # hm, rockbox playing at 55mA... 22.44.19 # r29264 build result: All green 22.44.22 # AlexP: that's how it works 22.44.39 # so for pictureflow I need to look for embedded at last 22.45.08 # yeah 22.45.32 # kugel: But are you going to now, or shall I just put a note in saying pictureflow doesn't support embedded yet? 22.45.43 # give me some minutes 22.45.45 # so about 10mA improvement... 22.45.56 # kugel: OK :) 22.46.04 # New commit by 03theseven (r29265): iPod Classic: Enable boosting by switching the CPU between 1x and 2x AHB clock 22.47.58 # there is definitely something wrong 22.48.34 # that kind of boosting barely saves anything within rockbox, but 6mA within emcore 22.49.20 # thomasjfox: New (and hopefully final) version of patch uploaded... 22.50.26 # r29265 build result: All green 22.50.40 # linuxstb: ok, checking 22.50.51 # playing/not playing doesn't make a huge difference, while in emcore i can even see if the clickwheel is being touched on the multimeter 22.51.24 # also, after starting and stopping playback, rockbox consumes more power than before 22.52.34 # linuxstb: I think the "-atleast-version=4" won't work with the version == 5 check, no? 22.54.45 # thomasjfox: I'm not sure what you mean. The intention is that if $1==5 and version 4 is detected, then it's an error. 22.55.44 # linuxstb: sorry, my fault: it's inside if / elseif. This will work 22.56.07 # linuxstb: I thought it just for version >=4 and then complains if version == 5 22.56.16 # checks 22.57.11 # compile output looks correct, let's diff the Makefile again 22.57.40 # playing flac or ape -c4000 doesn't make a difference power consumption-wise, that just *can't be right*! 22.59.54 Quit TheLemonMan (Quit: free(me)) 22.59.57 # is there a way to see how much time rockbox is sleeping? 23.00.18 # (this should maybe be added to the buffering debug screen) 23.00.27 Join JdGordon| [0] (~jonno@124-171-49-199.dyn.iinet.net.au) 23.00.27 Quit JdGordon| (Changing host) 23.00.27 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) 23.01.23 # linuxstb: Looking good. I think I found an unrelated issue (maybe with maemocc): If you run "make reconf", the LD_OPTS append themselves every time you run it 23.01.32 # linuxstb: Gonna check maemo 4 now 23.02.13 Join Keripo [0] (~Keripo@SEAS183.wlan.seas.upenn.edu) 23.03.10 # linuxstb: "make reconf" successfully complains "ERROR: Maemo 5 SDK required." on maemo 4 23.05.25 # linuxstb: argh, maemo4 doesn't have pkgconfig for SDL. I'm wondering how this worked before... 23.06.14 # wodz: I got the package on monday. Thanks! 23.06.22 *** Saving seen data "./dancer.seen" 23.07.54 # thomasjfox: Looking at simcc(), it just sets LDOPTS to "-lm" - I'm guessing maemocc should do the same (i.e. not include $LDOPTS) 23.08.11 # thomasjfox: But I'll leave you to fix that after I commit this patch. 23.08.17 # linuxstb: ok 23.08.43 # linuxstb: I think we need to hack sdl-config support back in for maemo 4 23.08.58 # AlexP: add a note, it's more tricky than I thought 23.09.06 # after you commit the patch. Guess this broke when I switched from simcc() to maemocc() 23.09.15 # kugel: OK, will do 23.09.39 # thomasjfox: OK, so you're happy for me to commit v3? 23.10.44 # linuxstb: Yes. Except for the part that it breaks the "debian/rules" stuff. Could you prepare a fix for that? 23.10.52 Quit p3tur (Quit: here today, gone tomorrow) 23.11.43 # linuxstb: We should be able to get the maemo version in there too as the maemo-version-dev package is a build requirement 23.12.29 # AlexP: it'd mean making the db and metadata subsystems album art aware (they are not now) for !HAVE_ALBUMART, just for pictureflow 23.12.39 # New commit by 03alex (r29266): Manual: We now support embedded JPEG album art in ID3v2 tags. 23.12.46 # kugel: Could you take a look at FS #11924 v3 if it's ok for android? (the paths etc.) 23.13.23 # ok 23.13.23 # kugel: I use neither embedded AA nor pictureflow so fine by me :) 23.15.08 Quit liar (Ping timeout: 255 seconds) 23.15.10 # thomasjfox: Hmm, I'm not sure what to do in debian/rules. We now have two different applications being built (--target=nokian8xx and --target=nokian900) - how should it know what the user is building? Checking for the maemo SDK version seems a bit of a hack... 23.15.15 # gevaerts: good - does it work? 23.15.22 # wodz: I haven't tried yet 23.15.56 # gevaerts: First simple test - connect it to usb and look if it gets detected 23.16.34 # linuxstb: As scratchbox sets up symlinks for everything (libraries, gcc) depending on the active target, detecting the maemo-version-dev version is fine 23.16.48 # r29266 build result: All green 23.17.01 # linuxstb: looks good for android (Makefile: target id is different, and platform=A is missing from the reconf line;autoconf.h: identical) 23.17.59 # kugel: OK, thanks for looking. 23.19.04 # thomasjfox: I am thinking more generally - how would we, for example, extend it to handle a Debian SDL app? 23.19.46 # linuxstb: Then we need distro specific code in the rules file anyway. The maemo distro version would still do auto detection. 23.19.57 Quit factor (Read error: Connection reset by peer) 23.20.10 # linuxstb: debian is actually easy. We could use the v3 source format, which implies being able to provide a new debian/ directory in a separate tar file 23.21.08 # thomasjfox: Would you be able/willing to fix it? 23.21.11 # It's if there are more systems that use older dpkg versions that we have problems 23.22.36 # linuxstb: This is way beyond my debian packaging skills... 23.23.09 # thomasjfox: And mine... I can't even test things at the moment. 23.23.24 # But debian/rules is just a Makefile IIUC... 23.23.44 # The rules file: ye 23.23.46 # s 23.24.30 # Look at the "control" file. It will be a bit tricky to get the dependencies right for multi distro 23.26.18 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 23.26.39 # Aren't the dependencies already wrong? i.e. before my changes to configure? 23.27.22 # linuxstb: They are correct for maemo 23.27.30 Quit wodz (Quit: Leaving) 23.28.22 # But doesn't it say you need "maemo <= 5" for both Meamo4 and Maemo5 builds? 23.30.18 Quit petur (Quit: Leaving) 23.32.22 # linuxstb: There was something about this. Can't remember the details right now. I could try with "maemo < 4" some other time 23.32.54 # thomasjfox: But I mean that the dependencies depend on what version of Maemo you want to build for... i.e. they are not fixed, even for maemo. 23.33.52 # linuxstb: Yes, that is true. I just said it will get more tricky to add normal debian systems or other debian based distros into that equation 23.34.55 # thomasjfox: do you still plan to work on pulseaudio backend? 23.35.34 # kugel: Yes, though with low priority. I want to get the usability right first 23.35.56 # kugel: proof of concept change to fix the shutdown stuff for SDL/maemo: http://pastebin.com/hXujnkqK 23.35.59 # usa-what? 23.36.01 # :P 23.36.26 Join factor [0] (~factor@75.108.68.114) 23.37.38 # cool 23.37.57 # kugel: Is there a master event loop on android? 23.38.09 # yea 23.38.25 # kugel: The event loop needs to keep running until shutdown_hw() is finally called 23.38.45 # kugel: Would that be easily doable? 23.39.12 # not sure about "easily" but yea 23.40.50 Quit komputes (Remote host closed the connection) 23.41.09 # hey 23.41.15 # i now have proof that rockbox never sleeps! 23.42.29 # thomasjfox: any idea what's the difference between shutdown_hw() and sys_poweroff()? 23.42.38 # kugel: Yes :) 23.43.03 # kugel: shutdown_hw() does the actual shutdown. On native platform it calls poweroff() at the end 23.43.07 # * TheSeven wants to see that fixed before 3.8! 23.43.26 # TheSeven: can you elaborate? 23.43.46 # kugel: sys_powerroff() sets a timeout and broadcasts the SYS_POWEROFF event 23.44.06 # TheSeven: are you saying core_sleep() (in thread-arm.c) doesn't work? 23.44.15 # i'm saying that it doesn't seem to be called 23.44.29 # i just added some statistics, and they show all-zero 23.44.31 # it's called by switch_thread() 23.44.42 # also the power consumption measurements don't show any traces of sleeping 23.44.51 # TheSeven: it has a bunch of #ifdef, is your target in that list? 23.44.55 # yes, it is 23.45.07 # and the #warning below doesn't come up (and did before i added it to the ifdef) 23.45.23 # JdGordon, n1s: Could you comment on the lang-related question in http://www.rockbox.org/tracker/task/11748#comment38639 ? 23.45.40 # I'm pretty sure rockbox is sleeping, I noticed a *huge* difference in CPU usage on the android port 23.45.58 # 100% load w/o proper core_sleep(), 0% with core_sleep() 23.47.06 # TheSeven: are you on armv6? 23.47.30 # armv4 and armv5e 23.47.57 # strange that core_sleep() isn't called. it definitely is on android 23.48.35 # i just made it panic, and well, sometimes it is called 23.48.41 # but there is something wrong somewhere 23.48.48 # it seems to be called 90 times per second 23.48.54 # (when idle) 23.48.54 Quit factor (Read error: Connection reset by peer) 23.49.10 # that sounds about right 23.49.33 # yeah, but the time inside is near-zero 23.49.55 # (or there is a huge bug in my measuring...) 23.50.13 # is some interrupt/tick task hogging the cpu? 23.51.06 # it goes like timer_int->all tick tasks->wakeup scheduler->run all runnable threads->core_sleep()->wait for interrupt->timer_int->... 23.52.18 Quit Keripo (Quit: Leaving.) 23.53.40 Join webguest95 [0] (~b8248832@giant.haxx.se) 23.53.41 Quit krazykit (Ping timeout: 240 seconds) 23.53.46 Join factor [0] (~factor@75.108.68.114) 23.54.30 # on idle it should be almost entirely be in core_sleep(). if it isn't one of the other parts of this chain is hogging 23.54.42 Join mlt- [0] (~8654d106@giant.haxx.se) 23.58.08 Quit JdGordon| (Ping timeout: 265 seconds)