| 00:02.42 | Vib3 | ok :) |
| 00:08.21 | *** join/#maemo Dibblah_ (~Dibblah@cpc2-dund11-2-0-cust798.sgyl.cable.virginmedia.com) |
| 00:13.05 | *** join/#maemo Hurrian (~yuki@121.54.2.104) |
| 00:15.57 | *** join/#maemo LaoLang_cool (~LaoLang_c@221.226.175.141) |
| 00:45.12 | *** join/#maemo Gh0sty (~ghosty@77.109.101.115) |
| 00:57.17 | *** join/#maemo Estel_ (~Estel@d35-11.icpnet.pl) |
| 00:57.30 | Estel_ | Happy easter and other bla-bla. |
| 00:58.01 | Estel_ | I'm sure no one is reading this for mentioned reason, yet in case of other pagans like me sitting here: |
| 00:58.07 | DocScrutinizer | wants some chocolate eggs! |
| 00:58.28 | Estel_ | does anyone know which gstreamer0.10-plugins one should install for, erm, best result. |
| 00:58.45 | Estel_ | handles some chocolate eggs to DocScrutinizer, sick of them already |
| 00:58.51 | DocScrutinizer | define "best results" ;-D |
| 00:59.00 | Estel_ | I was just to do so :D |
| 00:59.26 | Estel_ | by best result, I mean most widely working playback including strange format |
| 00:59.39 | Estel_ | + most effective decoding (for non-DSP accelerated) |
| 00:59.45 | DocScrutinizer | all? |
| 00:59.53 | DocScrutinizer | ;-) |
| 00:59.55 | Estel_ | not possible, they're exclusive |
| 01:00.00 | DocScrutinizer | aaah |
| 01:00.05 | Estel_ | amongst conflicting ones, we have: |
| 01:00.13 | Estel_ | gstreamer0.10-plugins-bad |
| 01:00.18 | Estel_ | gstreamer0.10-plugins-bad-multiverse |
| 01:00.28 | Estel_ | gstreamer0.10-plugins-ugly |
| 01:00.32 | Estel_ | gstreamer0.10-plugins-ugly-multiverse |
| 01:00.32 | DocScrutinizer | well, then you have to decide. I guess the tradeoff is between stability and wide support for strange formats |
| 01:00.45 | Estel_ | same thougths here... |
| 01:00.53 | Estel_ | I've used "bad" for ages... |
| 01:01.05 | Estel_ | Yet, thinking about it, I have NFC what ugly is exactly |
| 01:01.10 | DocScrutinizer | google might help |
| 01:01.15 | Estel_ | "plugins that could pose distribution problems" |
| 01:01.20 | Estel_ | tried that :P |
| 01:01.30 | DocScrutinizer | meh, who cares distri problems? |
| 01:01.30 | Estel_ | wtf is that, sounds like some cop,yright shit |
| 01:01.38 | Estel_ | yet, theyre distributed |
| 01:01.54 | Estel_ | wasn't able to figure which one is more bleeding-edge - ugly or bad |
| 01:01.58 | Estel_ | (sic!) |
| 01:02.01 | DocScrutinizer | well, they're not *installed* |
| 01:02.08 | Estel_ | also, wtf is multiverse variant. |
| 01:02.18 | DocScrutinizer | the good, the bad and the ugly |
| 01:02.22 | Estel_ | yea |
| 01:02.25 | LaoLang_cool | How to export conversations of N900? |
| 01:02.32 | Estel_ | fortunatelly, good isn't exlusive to bad here |
| 01:02.55 | DocScrutinizer | LaoLang_cool: dunno if there's any serious method |
| 01:03.07 | Estel_ | the problem is - multiverse, as it sounds ubuntu'ish, is "more" or less than non-multiverse variant (for Maemo) |
| 01:03.31 | DocScrutinizer | hmm, check content? |
| 01:03.40 | Estel_ | LaoLang_cool, search repos for "conversations", there is something that exports it from database |
| 01:04.01 | Estel_ | hm, why not, but how do I determine which one is "better" |
| 01:04.05 | Estel_ | number of plugins? |
| 01:04.11 | Estel_ | dates? ;P |
| 01:04.35 | Estel_ | I'm also afraid that multiverse wariants got same plugins compiled differently |
| 01:04.44 | Estel_ | or from diferrent code revisions |
| 01:04.46 | Estel_ | headache |
| 01:04.58 | LaoLang_cool | searched in http://maemo.org/packages/search/ but without lucky... |
| 01:05.44 | DocScrutinizer | dates, versions, number of plugins |
| 01:05.49 | *** join/#maemo uen| (~uen@p5DCB1650.dip.t-dialin.net) |
| 01:06.24 | DocScrutinizer | yeah, quite some headache |
| 01:06.44 | Estel_ | LaoLang_cool, check glogarchive |
| 01:06.48 | DocScrutinizer | anyway listen to LaoLang_cool - might be a starting point for your question |
| 01:07.42 | LaoLang_cool | Estel_: wow, will try it, thanks |
| 01:07.47 | LaoLang_cool | DocScrutinizer: what?... |
| 01:07.56 | Estel_ | "search, view, archive and export SMS/IM messages and call logs from eventlogger" |
| 01:09.11 | Estel_ | LaoLang_cool, I got quite unsaatisfying results when searching via packages/search, so I always use fapman for repo search (with devel enabled, usual warnings apply) |
| 01:09.30 | Estel_ | it search not only for package names, but crawls also through descriptions |
| 01:09.51 | Estel_ | DocScrutinizer, thanks, will try to determine that. Now I remember we was talking about it some months ago... |
| 01:10.09 | Estel_ | When I wanted to play .vob file with mpeg2 stream via stock media player :P |
| 01:10.42 | Estel_ | this is why I installed "bad" plugins set on first place. Well, .vob still plays only via mplayer... |
| 01:10.55 | DocScrutinizer | GStreamer Bad Plug-ins is a set of plug-ins that aren't up to par compared to the rest. They might be close to being good quality, but they're missing something - be it a good code review, some documentation, a set of tests, a real live maintainer, or some actual wide use |
| 01:11.10 | DocScrutinizer | vs |
| 01:11.13 | DocScrutinizer | This packages contains plugins from the "ugly" set, a set of |
| 01:11.15 | DocScrutinizer | <PROTECTED> |
| 01:11.35 | Estel_ | now I'm trying to find most efficient theora playback. It's really good already, but for some videos I can't play smoothly, despite encoding via same settings as working ones |
| 01:11.36 | Estel_ | yea |
| 01:11.54 | Estel_ | from common sense "bad" sounds more bleeding-edge = wider format support |
| 01:12.07 | Estel_ | yet, ugly description is enigmatic, to say at least |
| 01:12.23 | DocScrutinizer | not really |
| 01:12.36 | DocScrutinizer | I read that as plain "M$ codecs" |
| 01:12.43 | Estel_ | ? so it's just me who don't know what distribution problems mean |
| 01:12.49 | Estel_ | yes, same here, but |
| 01:12.57 | Estel_ | they're distributed anyways via repos |
| 01:13.06 | DocScrutinizer | not installed though |
| 01:13.08 | Estel_ | where illegal content is fought with fire, yep? |
| 01:13.15 | Estel_ | hm? |
| 01:13.25 | Estel_ | define "not installed" in this content |
| 01:13.34 | DocScrutinizer | Nokia neither supports nor ships them |
| 01:13.39 | Estel_ | context* |
| 01:13.39 | DocScrutinizer | ergo no problem |
| 01:13.57 | DocScrutinizer | extras repo is not nokia repo |
| 01:14.03 | Estel_ | yea, but this sucker conflicts with "bad" set |
| 01:14.16 | Estel_ | yes, but bad is also in extras, not nokia repos |
| 01:14.26 | Estel_ | eh, manual determining wtf is inside is a must :/ |
| 01:14.27 | DocScrutinizer | sure |
| 01:14.41 | Estel_ | why ugly can't coexist wikth "bad" though |
| 01:15.04 | Estel_ | I understand it as base < good < bad |
| 01:15.16 | Estel_ | base is everywhere, good (with extras) can be installed |
| 01:15.26 | Estel_ | bad (with extra variant) too |
| 01:15.35 | Estel_ | none conflict with eachother |
| 01:16.04 | Estel_ | with exception for bad replacing good, as it provides it already |
| 01:16.19 | Estel_ | yet, checking dependencies, ugly doesnt provide bad, yet conflicts with it and replaces |
| 01:16.24 | Estel_ | bad also replace ugly |
| 01:16.27 | DocScrutinizer | btw beware, I seem to recall this whole mess gave me more headache: after installing one, some codecs didn't work anymore |
| 01:16.56 | Estel_ | that's what I'm afraid of, and why I asked here instead of determining myself via experiments :P |
| 01:17.27 | Estel_ | add to this multiverse variants of bad and ugly (good also have multiverse variant, but that doesn't matter here...)) |
| 01:17.34 | DocScrutinizer | backupmenu is your friend ;-D |
| 01:17.39 | Estel_ | true :P |
| 01:18.07 | Estel_ | hah, worst case scenario is "no distinguishable difference between them", until You ran into problems 6 months later :P |
| 01:18.30 | DocScrutinizer | plus I'd forget about multiverse versions, I can't even seem to find them in package interface |
| 01:18.44 | DocScrutinizer | ooh there |
| 01:20.06 | Estel_ | at least multiverse variant wasn't uploaded by same person |
| 01:20.12 | LaoLang_cool | another question, any tools for replacing battery icon in status with battery level, so I can check how many batter existed when click the status bar |
| 01:20.15 | DocScrutinizer | anyway multiverse is 0.10.7 while non-muperverse is 0.10.14? |
| 01:20.24 | Estel_ | yet, dates for every gstreamer0.10 package is unavailable |
| 01:20.26 | Estel_ | hm |
| 01:20.34 | Estel_ | yyy, no? |
| 01:21.15 | Estel_ | 0.10.10.2-1maemo2 both variants for ugly |
| 01:21.37 | DocScrutinizer | oops 0.10.10 right |
| 01:22.24 | Estel_ | multiverse was uploaded by solme guy with @ubuntu.com |
| 01:22.33 | DocScrutinizer | Repository Latest version |
| 01:22.35 | DocScrutinizer | <PROTECTED> |
| 01:22.38 | Estel_ | hm, maybe only difference is that it provided LAME mp3 encoder? |
| 01:22.52 | Estel_ | woot? |
| 01:23.33 | Estel_ | oh god |
| 01:23.53 | Estel_ | multiverse variants haven't dependencies set to conflict with bad and good |
| 01:23.59 | Estel_ | i.e. normal ugly replaces them |
| 01:24.05 | Estel_ | yet, multiverse doesn't |
| 01:24.16 | Estel_ | it may be why You experienced codec breaking |
| 01:24.53 | Estel_ | also, multiverse ugly variant have set that it provided LAME, while ugly doesn't (which doesn't mean that it isn't providing it, may have just dependencies unset) |
| 01:25.17 | Estel_ | I pray for ressurection of some gstreamer/codec guru to clean this mess |
| 01:25.53 | Estel_ | who the fuck have now idea of what exactly is bundled there :P |
| 01:26.10 | DocScrutinizer | bad-extra, bad-faad, bad-vorbis ;-P |
| 01:27.03 | DocScrutinizer | I'd guess maybe the dependecies are a bit messed up |
| 01:27.08 | *** join/#maemo Arkenoi (~ark@81.200.13.90) |
| 01:27.18 | Estel_ | probably yes |
| 01:27.24 | Estel_ | BTW I was wrong it seems |
| 01:27.33 | Estel_ | only "ugly" have multiverse wariant |
| 01:27.37 | DocScrutinizer | maybe dpkg -install -force-install helps, when doen in right sequence? |
| 01:27.49 | Estel_ | quite possible |
| 01:28.24 | Estel_ | BTW there was once almost finished implementation for DSP decoding of Theora |
| 01:28.43 | DocScrutinizer | hmm |
| 01:28.44 | Estel_ | actual playback on N900 was achieved with great results, it needed only some code polishing |
| 01:28.54 | Estel_ | havent heard about it for ages, which is huge pity |
| 01:28.56 | DocScrutinizer | and now? |
| 01:29.10 | Estel_ | especially that it was actual working as it seems |
| 01:29.43 | Estel_ | http://talk.maemo.org/showthread.php?t=50270 |
| 01:29.50 | DocScrutinizer | no friggin maintainers |
| 01:29.52 | Estel_ | see article linked on first post |
| 01:30.10 | Estel_ | yea. Google distributed financial grant for theoraarm |
| 01:30.24 | Estel_ | =version just after grant was last one |
| 01:30.43 | Estel_ | ironically, before grant, work was fast and non-granted |
| 01:30.55 | Estel_ | (for theoraARM) |
| 01:31.06 | Estel_ | N900 implementation was based on that |
| 01:31.26 | Estel_ | it was sheduled for mainline inclusion in theora and then... |
| 01:31.34 | Estel_ | I have no idea what happened |
| 01:32.20 | Estel_ | yet, even using already existing implementation, article's author from link I've provided was able to decode 800x480 theora @ ~30 fps with 80% idle CPU |
| 01:32.44 | Estel_ | given pulseaudio eating things etc, 60% idle non-overclocked cpu seems real |
| 01:33.38 | Estel_ | now, @ 900 mhz I got 80-90%used CPU for fluent playback for most videos, yet, some of them - same resolution (720x480, dvd rips) and same quality use 100% CPU and stutter a little |
| 01:33.59 | Estel_ | no idea what's the difference, probably upper limit of kbps handled by CPU alone. |
| 01:34.22 | Estel_ | (more dynamic scenes or whatsnot = more kbps using same resolution and same quality setting) |
| 01:34.40 | *** join/#maemo lxp1 (~lxp@212-183-126-53.adsl.highway.telekom.at) |
| 01:34.50 | ShadowJK | wonders how ffmpeg/libav's theora decoder on arm does vs xiph and theoraARM |
| 01:35.28 | Estel_ | yea, quite interesting. Yet, in latest ffmepg releases I wasn't able to find theora decoder |
| 01:35.33 | Estel_ | either I'm just dumb |
| 01:35.41 | Estel_ | or it was removed after some version |
| 01:36.27 | Estel_ | BTW, I would be happy to have either one actually available for N900 :P now, I can probably go and compile one myself, if desperate... |
| 01:36.44 | ShadowJK | it's probably in the same files as the vp3 decoder |
| 01:36.53 | Estel_ | whichp given my miserably skills, is far from promising optimal results:P |
| 01:37.09 | Estel_ | w00t? |
| 01:37.15 | Estel_ | is running to check that |
| 01:38.03 | ShadowJK | yep, seems it's in vp3 |
| 01:38.08 | ShadowJK | same thing basically |
| 01:38.45 | DocScrutinizer | haha, so that's why it 'vanished'? :-D |
| 01:38.59 | Estel_ | it seems so. |
| 01:39.19 | Estel_ | yet, ffmep also provided encoder for it (not on topic about N900, of course) |
| 01:39.30 | Estel_ | now I can't find encoder for theora or vp3 either |
| 01:39.32 | DocScrutinizer | suckers forgot a "symlink" somewhere in the wiki |
| 01:39.37 | Estel_ | decoder is there, right |
| 01:39.42 | Estel_ | ya. |
| 01:40.19 | Estel_ | BTW I was forced to use ffmepg2theora standalone, instead of ffmpeg, when doing my re-encoding into theora |
| 01:40.29 | Estel_ | due to "vanished" encoder. |
| 01:40.39 | Estel_ | wasn't able to google "why" either. |
| 01:40.53 | ShadowJK | ffmpeg never had an encoder |
| 01:41.06 | Estel_ | it had, I have old version with it on hd |
| 01:41.13 | Estel_ | will check number |
| 01:41.23 | ShadowJK | At some point it was maybe able to use xiph's libtheora, but that wrapper was probably dropped as soon as the vp3 decoder could handle decoding the theora variant too |
| 01:41.26 | Estel_ | via libtheora, if I'm not mistaken |
| 01:41.41 | Estel_ | yea |
| 01:41.46 | Estel_ | exactly |
| 01:42.06 | Estel_ | now I understand... Dit I mention my miserabl.e knowledge on first place?:P |
| 01:42.13 | DocScrutinizer | who's going to ship me some chocolate eggs and a bottle of rum? |
| 01:42.46 | Estel_ | BTW, ShadowJK, so how one can now encode something to theora via ffmpeg? just can't? |
| 01:42.57 | ShadowJK | correct |
| 01:43.24 | ShadowJK | wonders if x264 ever made a vp8/webm version |
| 01:43.56 | ShadowJK | for the decoder in libav, the patch that added WebM support was 1000 lines of code (including comments) against h264. :P |
| 01:44.15 | Estel_ | strange, format is becoming more and more competetive in terms of video quality and file size, yet, to encode anything one must compile or use ffmpeg2theora |
| 01:44.18 | Estel_ | heh |
| 01:45.11 | ShadowJK | It's a dead-end |
| 01:45.12 | DocScrutinizer | ShadowJK: what's your favourite selection of codecs now, for fremantle? |
| 01:45.23 | Estel_ | BTW, any (averagely) easy way to check ffmpeg arm theora decoder and/or theoraARM on-device? |
| 01:45.31 | ShadowJK | uh?! h264 baseline profile, it's the only sensible choice |
| 01:45.41 | Estel_ | or one must re-do work and compile results? |
| 01:45.45 | Estel_ | hm |
| 01:46.11 | ShadowJK | oh, iirc, ffmpeg/libav's vorbis decoder had superior battery life in tkulve's tests too :) |
| 01:46.12 | DocScrutinizer | gstreamer-plugins |
| 01:46.25 | Estel_ | I'm not on-topic for codecs now - why it's dead-end? |
| 01:46.30 | Estel_ | yes |
| 01:46.56 | derf | ShadowJK: FFmpeg was certainly able to encode to Theora. |
| 01:46.57 | Estel_ | but I would like to be able to (quite boring-mainstream'ish) already use that :P |
| 01:47.04 | DocScrutinizer | i'm itchy about friggin mediathek at 3sat.de not working anymore |
| 01:47.07 | derf | (using libtheora) |
| 01:47.39 | Estel_ | ShadowJK, any way to practically use results of tkulve's tests? |
| 01:48.17 | Estel_ | having to choose between no implementation at all or unpolished implementation, I would preffer the latter |
| 01:48.20 | ShadowJK | Estel_, It's like a mpeg2 codec, that's been tweaked in the details to be different from mpeg2, and there's only so much gain you can get from tweaking the encoder for that. At some point if you want to keep up you want to get all the new stuff you can do in video coding now that CPUs are much more powerful than that of 15 years ago |
| 01:49.10 | ShadowJK | I don't think he released any debs to use/override/prefer libav vorbis decoder over other decoders. The libav vorbis decoder is quite mature anyways. |
| 01:49.11 | Estel_ | I see. |
| 01:49.35 | Estel_ | yea, I'm quite sure no debs exist now |
| 01:49.42 | DocScrutinizer | http://www.3sat.de/mediathek/index.php?display=1&mode=verpasst&type=1&red=nano >.-( |
| 01:49.49 | Estel_ | but, maybe something at least compiled for manual replace? :P |
| 01:50.17 | Estel_ | or one need to setup dev enviromnent and compile? |
| 01:50.43 | Estel_ | BTW, so, You think that Theora doesn't have chance in long run, despite all things about being patent-free? |
| 01:51.05 | ShadowJK | There doesn't exist any patent free software |
| 01:51.22 | luke-jr | all software is patent-free. |
| 01:51.35 | Estel_ | all after all, mp3 hegemony was also present (is?), yet ogg kick ass in terms of practical quality, which interest me most... |
| 01:51.59 | Estel_ | luke-jr, tell that to someone in USA (not me, fortunately) |
| 01:52.03 | derf | Estel_: Anyway, theoraarm and the DSP port were two different things. |
| 01:52.13 | Estel_ | hm? |
| 01:52.14 | luke-jr | Estel_: patenting algorithms isn't valid in the US either. |
| 01:52.31 | derf | The latter was called Leonora, and ran on the C64x DSP, not the ARM chip. |
| 01:52.53 | Estel_ | agree with You meritocraticelly, (luke-jr), yet, practice seems to be populistic'ish different :( |
| 01:52.57 | derf | theorarm was just providing ARM asm optimizations. |
| 01:53.18 | derf | Both projects were simply folded into mainline libtheora. |
| 01:53.25 | Estel_ | wait, they got 80% idle 600 mhz CPU due to small optimizations? |
| 01:53.41 | Estel_ | kulve was mentioning dsp for sure |
| 01:53.45 | *** join/#maemo Transformer (~Transform@ool-44c4bb0a.dyn.optonline.net) |
| 01:53.55 | Estel_ | TI DSP, exactly one we have here |
| 01:54.09 | DocScrutinizer | HAH, mediaplayer format works again :-D |
| 01:54.10 | derf | Yes. The DSP code was Leonora. |
| 01:54.16 | derf | I helped write most of this code. |
| 01:54.23 | Estel_ | also, I have 80% used cpu when playing back theora? why? |
| 01:54.29 | Estel_ | excuse my ignorance here. |
| 01:55.22 | Estel_ | ah, I get it |
| 01:55.29 | Estel_ | leonora = dsp |
| 01:55.39 | Estel_ | c64x dsp = our dsp |
| 01:55.44 | Estel_ | sorry, was lost for a while |
| 01:55.56 | derf | Well, welcome back, then :). |
| 01:56.02 | Estel_ | so, if boths projects are mainline now, why don't we benefit? |
| 01:56.54 | Estel_ | playing back thneora on N900 is using cpu only for sure (counting by CPU usage) |
| 01:57.15 | derf | Well, the DSP code still has some limitations that were never solved. |
| 01:57.25 | Estel_ | no idea about CPU optimizations, but dsp seems to sleep. |
| 01:57.39 | derf | You still need to run a special version of the library on the host CPU that passes things through to the version of the library running on the DSP. |
| 01:57.51 | Estel_ | I see. So, it wasn't implemented here, in our codec set? |
| 01:57.55 | derf | There are some issues with cache coherency that I think are just kernel bugs. |
| 01:58.12 | Estel_ | maybe kernel-power team would be able to fix that? |
| 01:58.15 | derf | (e.g., decoding videos at QCIF resolutions is just broken) |
| 01:58.17 | DocScrutinizer | derf: so fix them in powerkernel? |
| 01:59.07 | derf | DocScrutinizer: If I thought the N900 was still worth the time investment as a development platform, sure. |
| 01:59.15 | DocScrutinizer | "team" :-D. nice euphemism, Estel_ |
| 01:59.15 | Estel_ | also, http://blog.mjg.im/2010/04/16/theora-on-n900.html mention actual comparisions in performance, so bugs weren't critical? |
| 01:59.32 | Estel_ | DocScrutinizer, 2 people is a company already, no? :P |
| 02:00.11 | Estel_ | derf, ok, what You would recommend as way to go for people that think N900 is worth the time investment? |
| 02:00.22 | derf | Estel_: The kernel bugs? As I said, they were cache coherency things, and only affected decodes at small resolutions (i.e., when an entire frame fits in L2 cache). |
| 02:00.38 | Estel_ | 1. put what we have already to -devel 2. fix kernel bugs 3 code cleanup |
| 02:00.43 | Estel_ | 4. new version? |
| 02:00.58 | derf | Personally I'd use a libtheora build from current SVN. |
| 02:01.12 | derf | And forget the DSP stuff. |
| 02:01.25 | Estel_ | why? |
| 02:01.59 | Estel_ | Theora as is (without dsp) seems to be quite updated on N900 |
| 02:02.26 | Estel_ | I know that cpu is still able to decode more effectively than dsp (they can't cooperate 100%, yes?) |
| 02:02.31 | Estel_ | but battery savings? |
| 02:02.55 | DocScrutinizer | what makes you think there are battery savings? |
| 02:02.57 | Estel_ | using dsp-assisted decoding and ~20% CPU used I got ~210 mA current |
| 02:03.22 | DocScrutinizer | DSP needs power too |
| 02:03.25 | Estel_ | decoding theora @ 80-90% CPU, same other settings = ~410 mA |
| 02:03.39 | Estel_ | yea, but it's roughly 100% more |
| 02:03.44 | DocScrutinizer | hmm |
| 02:03.52 | DocScrutinizer | maybe, maybe not |
| 02:04.09 | Estel_ | with dsp thing CPU handles screen and some sound things (pulseaudio main eater) |
| 02:04.21 | DocScrutinizer | you'd need to compare same algo, same media, same backlight settings and all |
| 02:04.39 | Estel_ | same backlight settings were compared, ambient light etc. |
| 02:04.52 | Estel_ | of course I agree for algo etc |
| 02:04.52 | derf | It's actually a bunch of work to get the stuff from the DSP to the screen. |
| 02:05.05 | Estel_ | yep, xorg handles that, no? |
| 02:05.17 | ShadowJK | uh |
| 02:05.27 | derf | The stuff that was done for Leonora was based on bc-cat, because the ultimate goal was to use it in Firefox, which can't use the hardware overlays. |
| 02:05.30 | ShadowJK | I imagine it's a bunch of work to get stuff from the DSP out of the dsp |
| 02:05.40 | derf | Unfortunately, the TI bc-cat driver was bugged to hell. |
| 02:05.54 | derf | It would usually fail to work the first time you tried to play a video. |
| 02:06.06 | derf | And then it would randomly reboot your device other times. |
| 02:06.13 | Estel_ | Hm |
| 02:06.21 | ShadowJK | Not using overlay gobbles up lots of CPU and bandwidth :/ |
| 02:06.59 | derf | ShadowJK: Well, that was the point of using bc-cat, which was supposed to let you feed things to GPU as OpenGL textures directly. |
| 02:07.12 | derf | And indeed it did, when it worked. |
| 02:07.37 | derf | But since you're not Firefox, you'd probably want to use the hardware overlay instead. |
| 02:08.00 | Estel_ | overlay used 3-4x more CPU; yet allowed more frames per second |
| 02:08.14 | derf | 3-4x more CPU than what? |
| 02:08.19 | Estel_ | OpenGL/bccat was resulting in lower fps, yet almost idle CPU |
| 02:08.22 | ShadowJK | the idea kinda freaks me out, since this is only my second PC that has a GPU fast enough to render a video texture :-) |
| 02:08.24 | Estel_ | than the latter |
| 02:08.32 | Estel_ | accordsing to kulve's article |
| 02:09.19 | Estel_ | (video decode + paint, audio decode + not played) |
| 02:09.44 | Estel_ | SDL/overlay - 800x480 - fps 33 ṔU 80% usage |
| 02:09.49 | derf | Estel_: Which article is this? |
| 02:10.11 | Estel_ | OpenGL/bc-cat - 800x480 - fps 26 CPU 20%usage |
| 02:10.18 | Estel_ | PUwas meant to be CPU |
| 02:10.30 | derf | You mean http://blog.mjg.im/2010/04/16/theora-on-n900.html ? |
| 02:10.39 | derf | That was written by Matthew Gregan. |
| 02:10.44 | derf | Not kulve. |
| 02:10.54 | Estel_ | http://blog.mjg.im/2010/04/16/theora-on-n900.html |
| 02:10.59 | Estel_ | ah sorry |
| 02:11.04 | derf | (Matthew Gregan is a Firefox developer) |
| 02:11.06 | Estel_ | true. |
| 02:11.41 | Estel_ | ok, but if we screw firefox and normal video playback (most likely, via open media player = stock player replacement) interest us |
| 02:11.52 | Estel_ | no way to squeeze something useful from leonora? |
| 02:12.15 | Estel_ | considering possibility to fix kernel bugs |
| 02:12.29 | Estel_ | bc-cat is a dead-end? |
| 02:12.35 | Estel_ | it's that bad written? |
| 02:13.08 | derf | I mean, if you want to spend the time to track down kernel bugs and try to get bc-cat issues fixed, then things could probably be made to work okay. |
| 02:13.27 | DocScrutinizer | it's probably crowded with arcane workarounds for silicon bugs |
| 02:13.49 | Estel_ | kernel bugs can be probably traced down, we got brillant kernel developers now. I'm more worried about bc-cat |
| 02:13.57 | Estel_ | for reasons DocScrutinizer mentioned :P |
| 02:14.09 | Estel_ | and Your info about "buggy as hell" |
| 02:14.57 | Estel_ | BTW, on slightly different matter - DocScrutinizer, do You imagine a sensible way for - once for all - determining max bandwidth hostmode is giving us? |
| 02:15.05 | Estel_ | I'm still worried about sulu's result |
| 02:15.27 | Estel_ | would like to know if it's really that limited, and if yes, why? kernel hostmode implementation bugs? |
| 02:15.36 | DocScrutinizer | I'd not be surprised if hostmode was slow as geotectonics |
| 02:15.42 | Estel_ | more and more very interesting things to do with hostmode appear |
| 02:15.53 | derf | Estel_: Well, it looks like bc-cat has a much newer version than when we were trying this stuff two years ago. |
| 02:15.58 | derf | So some of those bugs may have been fixed. |
| 02:16.12 | Estel_ | I'm especially interested in already working multi-track sound recording via hostmode |
| 02:16.15 | Estel_ | hm |
| 02:16.22 | Estel_ | derf, interesting |
| 02:16.34 | derf | In any case it has _some_ source code. |
| 02:16.37 | DocScrutinizer | after all we've tweaked the kernel quite nasty to get it to do hostmode at all |
| 02:16.43 | derf | (links from http://processors.wiki.ti.com/index.php/OpenGLES_Texture_Streaming_-_bc-cat_User_Guide) |
| 02:16.59 | derf | So maybe some of those bugs are fixable. |
| 02:17.05 | DocScrutinizer | and nobody ever looked into all the clocks and powersavings mode settings for the different busses etc |
| 02:17.58 | Estel_ | derf, now I wait for RSA system-shock like skills learning, and I jump into coding right now ;) |
| 02:18.18 | Estel_ | seriously though, huge thanks for dropping in with such valuable info, I'll check what can be gained from that |
| 02:18.49 | Estel_ | and if we have manpower to do bc-cat thing, without that no much sense in bugging kp people |
| 02:19.14 | DocScrutinizer | I'd try to stream something via dd from /dev/zero to a sink in a gadget that takes unlimited bandwidth |
| 02:19.18 | Estel_ | DocScrutinizer, maybe it's good time to do tests and start tweaking,when we have active kernel-power people |
| 02:19.41 | Estel_ | I know usb-kernel is narrow specialization |
| 02:19.48 | DocScrutinizer | indeed |
| 02:20.09 | Estel_ | but, maybe middle-way we can make our supermans specialized :P |
| 02:20.12 | DocScrutinizer | dm8tbr might be able to look into it, maybe |
| 02:20.30 | DocScrutinizer | neither pali nor freemang have the knowhow |
| 02:20.43 | Estel_ | it would be pity to waste such potential, 5.1 playback from N900, and, more importantly, recording... |
| 02:21.01 | Estel_ | hm? |
| 02:21.13 | Estel_ | wtf is dm8tbr? I'm probably sleepy |
| 02:22.08 | Estel_ | and, for mortals - what type of gadget You have in mind |
| 02:22.25 | DocScrutinizer | nothing special yet, still pondering |
| 02:22.38 | DocScrutinizer | /whois is your friend |
| 02:22.43 | Estel_ | and how to measure speed of streaming this dd from dev/zero to sink in our gadget. with stopper? :P |
| 02:23.04 | DocScrutinizer | dd does that for you |
| 02:23.14 | Estel_ | right. I'm sleepy indeed |
| 02:23.29 | Estel_ | usb sound card doesn't seem to accept unlimited bandwidth, eh? |
| 02:23.36 | Estel_ | or does it? |
| 02:23.59 | DocScrutinizer | virtually unlimited, given you can set sampling rate and num of chan high enough |
| 02:24.46 | Estel_ | erm, but dd'ing something to sink there? |
| 02:24.53 | Estel_ | any noob friendly command example? |
| 02:24.55 | DocScrutinizer | err, yep |
| 02:25.00 | DocScrutinizer | right sound odd |
| 02:25.26 | DocScrutinizer | aplay might do |
| 02:25.26 | Estel_ | definitely, yet, very interesting at the same time. Haven't done wuch thing. |
| 02:26.00 | Estel_ | aplay on N900 side or dd to aplay? /noob mode |
| 02:26.01 | DocScrutinizer | aplay -r 512000 -c 6 -f s48le |
| 02:26.08 | Estel_ | oh, nice, thanks |
| 02:26.42 | DocScrutinizer | maybe there's actually s32le |
| 02:26.45 | DocScrutinizer | format |
| 02:27.04 | DocScrutinizer | and max sampling -rate is card dependant |
| 02:27.17 | DocScrutinizer | as is number of -chan |
| 02:27.33 | Estel_ | Recognized sample formats are: S8 U8 S16_LE S16_BE U16_LE U16_BE S24_LE S24_BE U24_LE U24_BE S32_LE S32_BE U32_LE U32_BE FLOAT_LE FLOAT_BE FLOAT64_LE FLOAT64_BE IEC958_SUBFRAME_LE IEC958_SUBFRAME_BE MU_LAW A_LAW IMA_ADPCM MPEG GSM SPECIAL S24_3LE S24_3BE U24_3LE U24_3BE S20_3LE S20_3BE U20_3LE U20_3BE S18_3LE S18_3BE U18_3LE |
| 02:28.35 | Estel_ | ok. so after that command, tweaked to my 24 bit 96khz card, to measure speed, I need to? |
| 02:29.02 | *** join/#maemo jluisn (~quassel@187.114.217.94) |
| 02:29.06 | DocScrutinizer | float64_be :-D |
| 02:30.17 | DocScrutinizer | aplay -f s24_le -r 96000 -c $NUM-OF-CHANNEL-CARD-SUPPORTS |
| 02:30.35 | *** join/#maemo Crooks_mobile (~Crooks@64-110-199-81.regn.hsdb.sasknet.sk.ca) |
| 02:30.41 | *** join/#maemo maybeHere (~cl@p5B164AAB.dip.t-dialin.net) |
| 02:30.54 | Estel_ | it seems im not that dumb, figured that :P (audio command) |
| 02:31.17 | derf | DocScrutinizer: For when you need 12,000 dB of dynamic range. |
| 02:31.23 | Estel_ | still don't get how to measure speed hostmode is providing |
| 02:31.38 | DocScrutinizer | derf: :-D |
| 02:31.45 | Estel_ | derf, hahaha, we check how much bandwidth does hostmode actually provide :P |
| 02:33.22 | Estel_ | so, for dumbie, alsay will play my 40khz 16bit file upsampled to 24bit 96khz via sound card. ok. how to check hostmode is allowing, again? |
| 02:33.29 | *** join/#maemo rcg (~rc@g230052231.adsl.alicedsl.de) |
| 02:33.39 | Estel_ | also, I suppose 24bit 96khz is enough to check our speed limit? :P |
| 02:33.56 | Estel_ | and wtf is float64_be |
| 02:34.42 | FIQ | le... be... the thing I'm thinking when I see those in combination is big/little endian... I suppose this is not really what it is about though |
| 02:35.40 | Estel_ | ok, screw float64, how to actually check this damn bandwidth? |
| 02:35.43 | DocScrutinizer | well, 24bit * 96k * 4chan = 2Mbit |
| 02:35.52 | derf | FIQ: Yes, that is exactly what it is. |
| 02:35.52 | Estel_ | *6 chann |
| 02:36.01 | FIQ | oh |
| 02:36.01 | DocScrutinizer | 3Mbit ;-P |
| 02:36.03 | FIQ | ok |
| 02:36.08 | Estel_ | well, card is able tp 7.1 actually, so I could use 8? |
| 02:36.17 | Estel_ | FIQ thanks anyway :) |
| 02:36.34 | Estel_ | float64_be is some sapling format alsa supports |
| 02:36.38 | DocScrutinizer | sure |
| 02:36.43 | Estel_ | big endian was right |
| 02:37.07 | Estel_ | I got 5.1 speakers connected, card should handle it anyway |
| 02:37.16 | Estel_ | still to small to check max bandwidth |
| 02:37.24 | Estel_ | 4Mbits |
| 02:37.38 | DocScrutinizer | well, it's sufficient bw for your usecase ;-P |
| 02:37.54 | Estel_ | true :P but would like to know limits of hostmode |
| 02:38.00 | Estel_ | You know, volounteering ;) |
| 02:38.13 | Estel_ | also important for handling hdmi output from N900 via raspberry pi |
| 02:38.14 | *** join/#maemo flux (flux@coffee.modeemi.fi) |
| 02:38.26 | DocScrutinizer | get a USB stick, check max continuous write on PC, check on N900 |
| 02:38.30 | Estel_ | it would be lame to notice that WiFi is our fastest connection to outside world |
| 02:38.57 | Estel_ | yea, but this could be limited by <whatever> limiting read on N900 |
| 02:39.07 | DocScrutinizer | eh? |
| 02:39.16 | Estel_ | I/O conflicts, whatever |
| 02:39.20 | DocScrutinizer | dev/zero has very few limits |
| 02:39.27 | Estel_ | ah, true |
| 02:39.42 | Estel_ | damn, sulu did that and he got poor results, You've already seen that |
| 02:40.07 | Estel_ | I though that there may be some absolutely 100%sure way to measure once for all |
| 02:40.30 | Estel_ | usb networking and streaming from /dev/zero to /dev/null in another devikce? :P |
| 02:40.41 | DocScrutinizer | get better data then! what speed got selected, did it actually run at that speed, was the stick able to get beter rates at PC under same test? |
| 02:40.43 | *** join/#maemo Zahra (~Zahra@unaffiliated/belendax) |
| 02:41.05 | Estel_ | ok... |
| 02:41.43 | DocScrutinizer | of course you as well could use a mere network connection via USB to a gadget, and flood it with socat or sth |
| 02:42.09 | DocScrutinizer | you still have tcp stack overhead then |
| 02:42.46 | DocScrutinizer | but the question is what you actually want to investigate and know |
| 02:43.10 | DocScrutinizer | mere raw USB bw helps nuttin if the overhead kills your app |
| 02:43.47 | Estel_ | of course how much bandwidth hostmode on N900 can actually provide, and, in longer run, if it can be tweaked to ressemble actual hi-speed standards more, via tweaking kernel implementation |
| 02:43.52 | DocScrutinizer | after all the bottleneck could be anywhere |
| 02:43.57 | Estel_ | of course |
| 02:44.17 | DocScrutinizer | Estel_: that's a moot definition |
| 02:44.20 | Estel_ | thats why I would like different method than writing to sd card from dd, to have same or different results |
| 02:44.48 | Estel_ | for example, most demanding thning I can now imagine - HDMI output from N900 via raspberry Pi on arbitrary high resolution |
| 02:45.14 | Estel_ | of course You dont need 30MB/s for that, yet |
| 02:45.15 | DocScrutinizer | you always are testing a full chain of systems, from origin to final sink |
| 02:45.26 | Estel_ | it would be good to know how good/bad our current implementation is |
| 02:45.38 | Estel_ | and to be able to tweak it if needed |
| 02:45.39 | Estel_ | yes |
| 02:45.51 | Estel_ | yesthats why I'm opting for testing with few very different methods |
| 02:46.12 | Estel_ | = less probability of every system involved in different test to be lame :P |
| 02:46.17 | DocScrutinizer | so if your HDMI driver is the bottleneck, your raw USB thruput figures are meaningless |
| 02:46.32 | DocScrutinizer | as they were done with a void driver |
| 02:46.49 | Estel_ | erm, hdmi done via raspberry pi, the latter got data via usb networking |
| 02:47.02 | DocScrutinizer | depending on what the driver does on USB API your results may vary vastly |
| 02:47.18 | Estel_ | generally, knowing hostmode current limits would also help determining why some things work as should and other don't |
| 02:47.38 | Estel_ | for example, DVB-T mpeg4 sticks |
| 02:47.55 | DocScrutinizer | meh, what's the problem with bw there? |
| 02:47.59 | Estel_ | more and more support for them in linux and people would start to test them with N900 |
| 02:48.24 | Estel_ | honestly, HDMI and raspberry Pi is my priority now. If sulu's results are valid... |
| 02:48.34 | Estel_ | WiFi is faster for us than USB networking |
| 02:48.44 | Estel_ | he got terrible results, as You remember |
| 02:48.45 | DocScrutinizer | sulu's results are meaningless for your usecase |
| 02:48.51 | DocScrutinizer | first approach |
| 02:50.29 | DocScrutinizer | honestly, don't ask "how much can it do?". better ask "can it do XY?" |
| 02:50.44 | Estel_ | somehow right |
| 02:50.45 | Estel_ | yet |
| 02:50.59 | Estel_ | Could You please look on that: |
| 02:52.33 | Estel_ | http://talk.maemo.org/showpost.php?p=1172479&postcount=58 |
| 02:52.56 | Estel_ | all after all You haven't answered him, and I would like to determine that even if just by curiosity |
| 02:53.13 | Estel_ | I agree that we need to determine if tasks a) b) could be done |
| 02:53.34 | DocScrutinizer | if you're unhappy with a cetain performance on a particular "XY", ask what's the bottleneck in this particular usecase. Don't nag me with "how fast can I drive?" without specifying road or car |
| 02:53.41 | Estel_ | yet, You stated there some interesting things to check, and conversation went dead after, would love to continue investigating |
| 02:55.47 | DocScrutinizer | first, investigate details of the test done. I already suggested ^^^^ |
| 02:56.03 | Estel_ | well, using 2.5'' hdd or writing files via optical dvd writer for someone, You can get hurt by bootlenect |
| 02:56.11 | Estel_ | hey, he answered about C state |
| 02:57.16 | Estel_ | and asked about how to check CPU<->musbcore and musbcore<-ULPI->PHY interface |
| 02:57.20 | *** join/#maemo pcfe (~pcfe@91-158-4-112.elisa-laajakaista.fi) |
| 02:57.20 | *** join/#maemo pcfe (~pcfe@redhat/pcfe) |
| 02:57.46 | Estel_ | C states for 10 minutes, CPU was in C0 |
| 02:57.57 | Estel_ | You havent checked his answer, have You? |
| 02:58.26 | Estel_ | dd if=/dev/sda of=/dev/null - CPU in C0 |
| 02:58.49 | Estel_ | would like to perform Your further suggestions, yet need to know how to check |
| 02:59.01 | Estel_ | CPU<->musbcore and musbcore<-ULPI->PHY interface |
| 02:59.22 | Estel_ | unless You now got better idea for debugging that |
| 03:00.01 | DocScrutinizer | I have, but to answer his questions how to check clocks for example I had to find out for myself about all that shit again. It's already inside guts of hostmode kernel to the ellbows |
| 03:00.15 | Estel_ | I see. |
| 03:00.29 | *** join/#maemo dockane_ (~dockane@dsdf-4d0a055b.pool.mediaWays.net) |
| 03:00.59 | DocScrutinizer | first of all, check the basic things: was it actually highspeed mode? |
| 03:01.11 | Estel_ | (check) yep. |
| 03:01.33 | DocScrutinizer | can the attached drive do better when running exactly same test on a linux PC |
| 03:01.42 | Estel_ | (valid) yep. |
| 03:01.52 | Estel_ | ~20 MB/s |
| 03:02.18 | Estel_ | 3 devices |
| 03:02.20 | DocScrutinizer | then I suggest you run a profile against the whole shit, to see where it dumps the time |
| 03:02.59 | Estel_ | ok... "run a profile" in bright noob friendly language? |
| 03:03.02 | DocScrutinizer | might be the sda driver, might be USB, might be CPU load at max, dunno |
| 03:03.21 | Estel_ | CPU load wasn't the case |
| 03:03.48 | Estel_ | s for sda driver I could connect dvd reader and dump something from it to /dev/null |
| 03:03.50 | DocScrutinizer | nfc, maybe you could use gdb for that. It's no simple task I just forgot to perform to validate USB h-e-n against highspeed |
| 03:03.57 | Estel_ | its isnt using sda, yep? |
| 03:04.45 | Estel_ | I see... at least in overall context ;) |
| 03:04.59 | DocScrutinizer | dumping sth fron /dev/sda to /dev/null should rule out quite a lot of drivers |
| 03:05.33 | Estel_ | aye. will perform |
| 03:06.06 | DocScrutinizer | check h-e-n raher kenel-MUSB syslog, to see what it actually does |
| 03:06.14 | Estel_ | erm, dd if=/dev/sda of=/dev/null isnt enough to rule out drivers, most of them? |
| 03:06.16 | DocScrutinizer | raher* |
| 03:07.01 | DocScrutinizer | well, most of them, yes. obviously |
| 03:07.12 | Estel_ | so it was actually done |
| 03:07.24 | Estel_ | same 4.x MB/s |
| 03:07.34 | DocScrutinizer | where's the syslog? |
| 03:07.43 | Estel_ | syslog part wasn't done |
| 03:07.49 | Estel_ | Want to do that |
| 03:08.04 | Estel_ | yet, how exacdtly filter it rfor H-E-N? I'm lost here |
| 03:08.12 | DocScrutinizer | meh. so it's absolutely worhless as you can't even guarantee the USB was at highspeed |
| 03:08.24 | Estel_ | in part "check h-e-n rather than kernel-MUSB syslog" |
| 03:08.40 | DocScrutinizer | -tahn |
| 03:08.47 | Estel_ | ok, so lest make it worhty and check that (dmesg said it was highspeed) |
| 03:09.10 | DocScrutinizer | duh, you've seen that? |
| 03:09.14 | Estel_ | yep. |
| 03:09.24 | DocScrutinizer | I doubt you have |
| 03:09.27 | Estel_ | high-speed device attached etc |
| 03:09.35 | DocScrutinizer | doesn't mean a thing |
| 03:09.36 | Estel_ | if we're talking about same thing |
| 03:09.40 | Estel_ | I see. |
| 03:09.50 | Estel_ | how to check it properly? |
| 03:09.52 | DocScrutinizer | attached != connection set up |
| 03:10.24 | DocScrutinizer | check each single log line, compare to kernel sources what it means |
| 03:10.30 | Estel_ | whole thing in dmesg from within hen told about high-speed, yet will re-check with pleasure |
| 03:10.31 | DocScrutinizer | basically |
| 03:11.13 | DocScrutinizer | also I, for unknown reasons, always thought dmesg is inferior to syslog |
| 03:11.26 | Estel_ | ok, You think it will allow to find bootleneck in usb kernel implementation? |
| 03:11.29 | Estel_ | I see |
| 03:11.41 | Estel_ | how You would check syslog for that particular case? |
| 03:11.53 | DocScrutinizer | I dunno |
| 03:12.23 | DocScrutinizer | how would you spot a bug in your app? |
| 03:13.03 | Estel_ | would check logs vs code under different condition ;) |
| 03:13.07 | Estel_ | I mean, rather |
| 03:13.14 | Estel_ | that I havent used syslog over dmesg |
| 03:13.24 | Estel_ | so it just that I run syslog after operation |
| 03:13.29 | Estel_ | and check every line? |
| 03:13.40 | Estel_ | like with dmesg? |
| 03:13.43 | DocScrutinizer | syslog creates logfile |
| 03:13.47 | DocScrutinizer | you read that |
| 03:14.01 | DocScrutinizer | /var/log/syslog |
| 03:14.28 | DocScrutinizer | the nice thing is: it has realtime timestamps |
| 03:14.35 | Estel_ | so basically start syslogd (daemon?), do thing, end it |
| 03:14.38 | Estel_ | check logs? |
| 03:14.46 | DocScrutinizer | so if you know system time of your actions, you spot them in there |
| 03:14.53 | Estel_ | nice thing |
| 03:15.29 | Estel_ | syslog = syslogd? |
| 03:15.42 | DocScrutinizer | plus I'm not sure if logger(1) will log to dmesg at all |
| 03:15.46 | DocScrutinizer | yep |
| 03:15.50 | Estel_ | mine outputs by default to /var/log/messages |
| 03:15.51 | Estel_ | ok |
| 03:16.01 | DocScrutinizer | depends |
| 03:16.18 | DocScrutinizer | on one system it's messages on other one syslog |
| 03:16.29 | DocScrutinizer | on third maybe kernel |
| 03:16.43 | DocScrutinizer | depends on syslog.conf |
| 03:16.49 | Estel_ | on maemo messages |
| 03:16.54 | Estel_ | ok, wtf is log rotation |
| 03:16.56 | DocScrutinizer | maybe |
| 03:16.57 | Estel_ | another file? |
| 03:17.21 | DocScrutinizer | logrotate tgz's your logfile and moves it outa the way |
| 03:17.26 | DocScrutinizer | every other week |
| 03:17.43 | Estel_ | I see. not rellevant here I suppose... |
| 03:17.49 | DocScrutinizer | not really |
| 03:18.13 | Estel_ | Ok, will do those tests (not today) and drop results on TMO, then drop here for a small talk... :P |
| 03:18.23 | DocScrutinizer | YW |
| 03:18.35 | Estel_ | Thnaks a lot for another hours of Your time |
| 03:18.43 | Estel_ | really appreciate Your patience :) |
| 03:18.55 | DocScrutinizer | thanks for helping on brushing out the bugs |
| 03:18.59 | DocScrutinizer | (if any) |
| 03:19.19 | Estel_ | will try my best... See ya! and happy chocolate egg |
| 03:19.25 | DocScrutinizer | haha |
| 03:19.41 | DocScrutinizer | no choko here, neither eggs nor other |
| 03:19.47 | DocScrutinizer | :-/ |
| 03:20.11 | DocScrutinizer | where's that friggin bunny? |
| 03:20.19 | DocScrutinizer | fetches gun |
| 03:31.54 | *** join/#maemo robbiethe1st (~robbiethe@71-221-208-52.spkn.qwest.net) |
| 04:00.37 | *** join/#maemo Sazpaimon_ (wat@80.67.13.29) |
| 04:01.14 | *** join/#maemo Sazpaimon_ (wat@80.67.13.29) |
| 04:01.53 | *** join/#maemo Sazpaimon_ (wat@80.67.13.29) |
| 04:01.54 | *** join/#maemo Crooks_mobile (~Crooks@64-110-199-81.regn.hsdb.sasknet.sk.ca) |
| 04:13.07 | *** join/#maemo infobot (~infobot@rikers.org) |
| 04:13.07 | *** topic/#maemo is Welcome to #maemo http://maemo.org/intro/ -- N9/harmattan related questions please in #harmattan ! | http://wiki.maemo.org/Community_Council | Source: http://wiki.maemo.org/Sources | Chanlog: http://mg.pov.lt/maemo-irclog | RECENT UPDATE: http://talk.maemo.org/showthread.php?t=79400 || CSSU-Stable available: get it via links in http://talk.maemo.org/showthread.php?p=1129261 *now*! |
| 04:13.08 | *** mode/#maemo [+v infobot] by ChanServ |
| 04:17.42 | Jade | hi |
| 04:18.48 | *** join/#maemo mitsutaka (~mitsutaka@123.112.102.11) |
| 04:26.24 | *** join/#maemo dangergrrl (~a@70.99.126.54) |
| 04:52.13 | *** join/#maemo MacDrunk (~marper@201.165.119.167) |
| 04:53.46 | *** part/#maemo MacDrunk (~marper@201.165.119.167) |
| 05:20.00 | *** join/#maemo CodenameStrike-N (~Codenames@203.82.87.123) |
| 05:40.23 | *** join/#maemo Sazpaimon (wat@80.67.13.29) |
| 06:00.21 | *** join/#maemo Sazpaimon (wat@80.67.13.29) |
| 06:00.43 | *** join/#maemo Sazpaimon (wat@80.67.13.29) |
| 06:04.18 | *** join/#maemo Pali (~pali@unaffiliated/pali) |
| 06:53.46 | *** join/#maemo Jade- (~jade@modemcable155.221-22-96.mc.videotron.ca) |
| 06:53.46 | *** join/#maemo Jade- (~jade@unaffiliated/jade) |
| 06:57.33 | *** join/#maemo lasher (~lasher@220-245-1-130.static.tpgi.com.au) |
| 07:06.55 | *** join/#maemo dhbiker (~dhbiker@APN-122-124-226-gprs.simobil.net) |
| 07:29.47 | *** join/#maemo sasquatch (~username@p57958863.dip.t-dialin.net) |
| 07:46.57 | *** join/#maemo Sazpaimon (wat@80.67.13.29) |
| 07:47.19 | *** join/#maemo Sazpaimon (wat@80.67.13.29) |
| 07:47.42 | *** join/#maemo Sazpaimon (wat@80.67.13.29) |
| 07:48.05 | *** join/#maemo Sazpaimon (wat@80.67.13.29) |
| 07:48.24 | *** join/#maemo Sazpaimon (wat@80.67.13.29) |
| 07:48.45 | *** join/#maemo Sazpaimon (wat@80.67.13.29) |
| 07:49.04 | *** join/#maemo Sazpaimon (wat@80.67.13.29) |
| 07:49.23 | *** join/#maemo Sazpaimon (wat@80.67.13.29) |
| 07:49.43 | *** join/#maemo Sazpaimon (wat@80.67.13.29) |
| 07:54.46 | *** join/#maemo LaoLang_cool (~LaoLang_c@221.226.175.141) |
| 07:59.34 | *** join/#maemo croppa (~stuart@CPE-120-146-137-99.static.nsw.bigpond.net.au) |
| 08:01.17 | Macer | uhm |
| 08:03.38 | *** join/#maemo onekenthomas (~kthomas@c-69-244-203-127.hsd1.tn.comcast.net) |
| 08:09.28 | *** join/#maemo valdyn (~valdyn@valdyn.org) |
| 08:32.43 | *** join/#maemo lasher (~lasher@220-245-1-130.static.tpgi.com.au) |
| 08:36.11 | *** join/#maemo NIN101 (~NIN@206.253.166.69) |
| 08:43.50 | *** join/#maemo CodenameStrike-N (~Codenames@203.82.92.35) |
| 08:44.55 | *** join/#maemo otep (~quassel@AP-203.167.31.157.sysads.com) |
| 08:59.43 | *** join/#maemo ieatlint_ (~ieatlint@tehinterweb.com) |
| 09:07.41 | *** join/#maemo OkropNick (kuba@host-n2-72-190.telpol.net.pl) |
| 09:39.22 | *** join/#maemo dos1 (~dos@unaffiliated/dos1) |
| 09:44.47 | *** join/#maemo SmilyOrg (Smily@89.142.240.159) |
| 09:49.02 | *** join/#maemo netkat (~sasha@tm.82.192.36.45.dc.telemach.net) |
| 09:51.27 | *** join/#maemo Muelli (~muelli@port-21287.pppoe.wtnet.de) |
| 09:57.31 | *** join/#maemo eijk (~eijk@e178205136.adsl.alicedsl.de) |
| 10:08.17 | *** join/#maemo vblazquez (~vic@35.41.15.37.dynamic.jazztel.es) |
| 10:26.18 | *** part/#maemo dsd31g (~dsd31g@22-235.107-92.cust.bluewin.ch) |
| 10:27.26 | *** join/#maemo eMHa (~mh@HSI-KBW-109-192-178-160.hsi6.kabel-badenwuerttemberg.de) |
| 10:27.43 | *** join/#maemo magog (~user@39.76.155.90.in-addr.arpa) |
| 10:29.52 | *** join/#maemo szopeen (~user@77-253-107-99.adsl.inetia.pl) |
| 10:30.40 | szopeen | wanting to try nitdroid, could anyone tldr tgnt for me? |
| 10:31.08 | szopeen | tl;dr The Great Nitdroid Thread |
| 10:31.20 | szopeen | * |
| 10:32.58 | dm8tbr | szopeen: wrong channel, they have their own IIRC |
| 10:33.20 | szopeen | thx |
| 10:34.17 | szopeen | hmm... ammyt doesn't seem to have it as his signature, care to link it or provide reference? |
| 10:34.18 | *** join/#maemo M4rtinK (~M4rtinK@mail.melf.eu) |
| 10:36.23 | szopeen | got it #nitdroid |
| 10:37.49 | *** join/#maemo flo_lap (~fuchs@sign-4db6a3aa.pool.mediaWays.net) |
| 10:37.58 | *** join/#maemo flo_lap (~fuchs@Maemo/community/contributor/florian) |
| 10:40.27 | *** join/#maemo dangergrrl (~a@70.99.126.54) |
| 11:04.22 | *** join/#maemo jhb (~joerg@adsl-226-108.dsl.uva.nl) |
| 11:19.48 | *** join/#maemo jonne (~jonne@91.182.40.54) |
| 11:22.00 | *** join/#maemo vizzy (~volker@p5B24EE25.dip.t-dialin.net) |
| 11:23.53 | *** join/#maemo axitk (b49531e7@gateway/web/freenode/ip.180.149.49.231) |
| 11:28.46 | DocScrutinizer | nitdroid topic is generally a bit of deprecated here |
| 11:29.57 | DocScrutinizer | not least because it needs multiboot which is a strongly deprecated topic |
| 11:31.36 | DocScrutinizer | and of course because in the end it's andridiot and we don't really like that either |
| 11:32.49 | DocScrutinizer | tough I start to respect andridiot since harmattan is ruining our day |
| 11:33.04 | *** join/#maemo LaoLang_cool (~LaoLang_c@221.226.175.141) |
| 11:33.07 | *** join/#maemo sq-one (~sq-one@p549AA3B6.dip.t-dialin.net) |
| 11:55.12 | *** join/#maemo DocScrutinizer (~halley@openmoko/engineers/joerg) |
| 12:16.16 | *** join/#maemo t_s_o (~tso@84.48.230.202) |
| 12:20.53 | *** join/#maemo Corsac (~yap@molly.corsac.net) |
| 12:21.29 | *** join/#maemo FIQ|n900 (~FIQ@unaffiliated/fiq) |
| 12:34.32 | *** join/#maemo piggz (~piggz@host-92-23-102-160.as13285.net) |
| 12:42.35 | *** part/#maemo Corsac (~yap@molly.corsac.net) |
| 12:47.27 | *** join/#maemo dhbiker (~dhbiker@APN-122-123-189-gprs.simobil.net) |
| 12:51.51 | *** join/#maemo Hurrian (~yuki@121.54.2.104) |
| 13:00.12 | FIQ|n900 | hm, what's up with there being a gcc-4.6 package in the repositories that is completly empty? |
| 13:00.22 | FIQ|n900 | and why is it even there |
| 13:01.14 | *** join/#maemo SD69 (ae64f0d8@gateway/web/freenode/ip.174.100.240.216) |
| 13:09.28 | DocScrutinizer | http://mynokiablog.com/2012/04/07/nokia-rm-714nokia-311-appears-at-fcc-full-touch-s40meltemi-with-swipe-and-multitouch/ |
| 13:09.31 | DocScrutinizer | FWIW |
| 13:10.00 | DocScrutinizer | the meltemi part is ... err... obscure |
| 13:10.58 | Hurrian | maybe it's a watered down harmattan |
| 13:11.13 | Hurrian | i really cant imagine nokia dumping another load on symbian |
| 13:11.34 | SpeedEvil | S40meltmi is clearly bogus |
| 13:12.01 | SpeedEvil | Unless... |
| 13:12.12 | DocScrutinizer | well, Nokia naming always been bogus, no? |
| 13:12.22 | SpeedEvil | Maybe the agreement with microsoft waid no linux phones, but diddn't ention symbian |
| 13:12.35 | SpeedEvil | so it's some sort of bastardised system. |
| 13:12.44 | SpeedEvil | Due to internal infighting. |
| 13:12.44 | DocScrutinizer | I'd bet it is |
| 13:13.38 | DocScrutinizer | after all, symbian been a maemo alike approach once before, according to that history tale? |
| 13:14.12 | DocScrutinizer | the "osso" times, I guess |
| 13:14.24 | SpeedEvil | yeah |
| 13:16.34 | *** join/#maemo realitygaps (~realityga@static.146.244.9.176.clients.your-server.de) |
| 13:16.34 | *** join/#maemo realitygaps (~realityga@unaffiliated/realitygaps) |
| 13:18.40 | DocScrutinizer | maybe Flop now faces some backlash from his evil masterplan to kill linux and Nokia even internally |
| 13:18.55 | *** join/#maemo dhbiker (~dhbiker@APN-122-123-173-gprs.simobil.net) |
| 13:18.57 | Hurrian | i wouldnt be surprised. |
| 13:19.03 | StyXman | n900 sometimes charging even from the wallwart means the usb socket is dead? |
| 13:19.18 | StyXman | only sometimes* |
| 13:19.28 | DocScrutinizer | yep, probably |
| 13:19.42 | StyXman | dang |
| 13:19.55 | DocScrutinizer | though it needs furhter investigation to tell for sure |
| 13:19.57 | StyXman | it's not even 5 monsths old |
| 13:20.02 | StyXman | DocScrutinizer: such as? |
| 13:20.04 | Hurrian | it's wobbly |
| 13:20.08 | Hurrian | deal with ti |
| 13:21.19 | DocScrutinizer | such as connecting it to PC and see if you can establish data connection. check mechanically, check optically all plugs. check syslog, /sys, and bq72k-detail |
| 13:22.00 | DocScrutinizer | could as well be powerkernel with modprobed bq24150.ko that kills bme, for example |
| 13:22.38 | DocScrutinizer | or a defect battery, defect cable, whatnot else |
| 13:22.43 | *** join/#maemo Free-MG (~test@p5DD7DF49.dip.t-dialin.net) |
| 13:23.03 | DocScrutinizer | also PEBKAC is widespread ;-D |
| 13:23.52 | StyXman | syslog, what should I see there? |
| 13:25.33 | DocScrutinizer | one thing you definitely should NOT try: bend the charger USB plug when plugged to see if it is rigid or starts charging |
| 13:25.42 | DocScrutinizer | I repeat: *NOT* |
| 13:26.12 | *** join/#maemo realityg1ps (~realityga@static.146.244.9.176.clients.your-server.de) |
| 13:26.59 | DocScrutinizer | well, in syslog you might see e.g. bme moaning about problems on start |
| 13:27.20 | DocScrutinizer | or you should see some notice about vbus attached or similar thing |
| 13:27.58 | StyXman | I will defenetely won't be touching it, knowing that it has problems |
| 13:28.12 | StyXman | I have no syslog |
| 13:28.25 | StyXman | /home/user # cat /var/log/syslog |
| 13:28.26 | StyXman | cat: can't open '/var/log/syslog': No such file or directory |
| 13:28.59 | DocScrutinizer | first of all: are you using powerkernel? |
| 13:29.04 | StyXman | no |
| 13:29.12 | DocScrutinizer | good, err bad |
| 13:29.21 | DocScrutinizer | then that's not the reason |
| 13:29.24 | StyXman | DocScrutinizer: should I, then? |
| 13:29.29 | DocScrutinizer | nope |
| 13:29.30 | StyXman | ah, ok |
| 13:30.11 | DocScrutinizer | does the device switch on from powerdown when you plug in charger or PC via USB? |
| 13:30.18 | StyXman | the phone it's mostly pristine, execpt for some soft (marble, a music player) and some fooling aroung with the partitions and the sd |
| 13:30.27 | StyXman | lemmesee |
| 13:30.49 | StyXman | sometimes it lights the screen (I set it up so, I think) |
| 13:30.55 | DocScrutinizer | switch on like in "LED shines up" or anything |
| 13:30.59 | StyXman | but it doesn't start charging |
| 13:31.23 | StyXman | ok, it's switched off |
| 13:31.48 | DocScrutinizer | watch the LED! |
| 13:32.09 | DocScrutinizer | does it shine up bright amber for a short moment when plugging in? |
| 13:32.30 | StyXman | I plugged in to the wllawart, it showed the faded nokia logo, it blinked once or twice red, and nothing else, black screen, seemingly not powered on |
| 13:32.46 | DocScrutinizer | blinked RED? |
| 13:32.52 | StyXman | s/itblinked/the led blinked/ |
| 13:32.56 | StyXman | yeap |
| 13:33.03 | StyXman | I can do it again |
| 13:33.05 | DocScrutinizer | dead battery most likely |
| 13:33.14 | StyXman | the battery's fine |
| 13:33.19 | StyXman | and I have 3 |
| 13:33.26 | DocScrutinizer | no, it's not when device blinks red |
| 13:33.52 | DocScrutinizer | or at very least device doesn't think battery is good |
| 13:34.04 | DocScrutinizer | that's why red blinking usually |
| 13:34.06 | StyXman | sonuva... |
| 13:34.11 | StyXman | ok |
| 13:34.35 | StyXman | it bribrated and showed the faded nokia logo |
| 13:34.46 | StyXman | it slow-blinked the led twice |
| 13:35.08 | StyXman | it showed the booting animation once (that's the 5 white dots) |
| 13:35.10 | StyXman | and nothing else |
| 13:35.12 | DocScrutinizer | red blinking means: either your batery is defect, or your device charger&battery-care circuit is defect, *or* the software is defect that manages all that |
| 13:35.38 | StyXman | I'm powering it on now |
| 13:35.39 | DocScrutinizer | it may take a quite long while after the 5 dots |
| 13:35.42 | DocScrutinizer | minutes |
| 13:35.50 | StyXman | it's booting |
| 13:35.59 | StyXman | pin code |
| 13:36.17 | DocScrutinizer | anyway, device isn't supposed to bot completely when just plugged in. Your description is absolutely fine |
| 13:36.19 | StyXman | normal boot |
| 13:36.29 | StyXman | ! |
| 13:36.34 | DocScrutinizer | err device behaviour as described by you is fine |
| 13:36.38 | StyXman | it think's it's connected to the pc |
| 13:36.53 | DocScrutinizer | :-/ |
| 13:37.01 | StyXman | it askme wether to put it in mass storage mode or pc suite mode |
| 13:37.09 | DocScrutinizer | I suspect you might have problem with datalines of USB |
| 13:37.17 | StyXman | dang |
| 13:37.29 | StyXman | good thing I have 3 batts and an external charger |
| 13:37.42 | *** join/#maemo _federico3 (~fede@86-44-192-163-dynamic.b-ras2.dbn.dublin.eircom.net) |
| 13:38.09 | StyXman | almos from the beginning it was a lottery wether it charged from the pc or not |
| 13:38.21 | StyXman | then I simply stopped trying |
| 13:38.47 | DocScrutinizer | connect to PC, see if you get a stable USB "data connection" (i.e. if mass storage mode works fine and without any problems for some 30 min or longer. you may *slightly* tap on the plug, to trigger possible hidden contact problems) |
| 13:39.10 | StyXman | ok |
| 13:39.22 | StyXman | I'll have to try later, I don't have the cable here |
| 13:39.38 | StyXman | thanks so far |
| 13:40.04 | DocScrutinizer | get bq27k-detail script, run it, once solo, once with parameter "10", pastebin the results |
| 13:41.44 | DocScrutinizer | StyXman: what makes you think your device doesn't charge? |
| 13:41.50 | DocScrutinizer | to begin with |
| 13:43.12 | DocScrutinizer | the LED blink patterns are changeable at your discretion |
| 13:43.32 | StyXman | DocScrutinizer: no batt animation, no charging notice, no slow-blinking red in the led and no actual charging |
| 13:43.40 | StyXman | I mean, the batt level doesn't go up |
| 13:43.50 | DocScrutinizer | red? amber! |
| 13:43.51 | StyXman | yes, I know, but I hadn't |
| 13:44.01 | StyXman | red, it was always red |
| 13:44.11 | StyXman | unless I'm color blind |
| 13:44.11 | DocScrutinizer | that's odd in itself |
| 13:44.53 | DocScrutinizer | well, you can test proper red |
| 13:45.00 | DocScrutinizer | lemme find the line for you |
| 13:45.01 | StyXman | and I know the RGB leds work because I get red for charging, blue for SMS and green for something else |
| 13:45.22 | DocScrutinizer | green for charging done |
| 13:45.27 | *** join/#maemo realitygaps (~realityga@unaffiliated/realitygaps) |
| 13:46.29 | *** join/#maemo kama (~kama@unaffiliated/kama) |
| 13:46.47 | *** join/#maemo CodenameStrike-N (~Codenames@210.195.243.98) |
| 13:48.07 | DocScrutinizer | please do:: dbus-send --system --type=method_call --dest=com.nokia.mce /com/nokia/mce/request com.nokia.mce.request.req_led_pattern_activate string:"PatternError" |
| 13:48.39 | DocScrutinizer | is this what you see for charging? is the color the same? |
| 13:49.17 | *** join/#maemo hardaker (~hardaker@mail.hardakers.net) |
| 13:49.32 | StyXman | yes, the same red, but the pattern it's different |
| 13:49.55 | DocScrutinizer | after checking, do:: dbus-send --system --type=method_call --dest=com.nokia.mce /com/nokia/mce/request com.nokia.mce.request.req_led_pattern_deactivate string:"PatternError" |
| 13:50.03 | *** join/#maemo NIN102 (~NIN@206.253.166.69) |
| 13:50.03 | StyXman | when chargin is more like fade in-fade out, in red |
| 13:50.40 | jacekowski | maybe yellow led is broken |
| 13:50.42 | DocScrutinizer | please do:: dbus-send --system --type=method_call --dest=com.nokia.mce /com/nokia/mce/request com.nokia.mce.request.req_led_pattern_activate string:"dbus-send --system --type=method_call --dest=com.nokia.mce /com/nokia/mce/request com.nokia.mce.request.req_led_pattern_activate string:"PatternBatteryCharging" |
| 13:50.57 | DocScrutinizer | there's no yellow LED |
| 13:51.00 | StyXman | jacekowski: yellow led? isnt it the red+green leds? |
| 13:51.09 | jacekowski | well, green then |
| 13:51.45 | DocScrutinizer | StyXman: what's the pattern you get with last one? |
| 13:52.38 | StyXman | DocScrutinizer: yeap, glowing/slow blinking/fade in-fade out red |
| 13:52.45 | DocScrutinizer | red? |
| 13:52.52 | StyXman | I don't know how to call it |
| 13:52.54 | StyXman | yes, red |
| 13:53.17 | StyXman | may be I changed, I don't remember |
| 13:53.22 | DocScrutinizer | please do:: grep "PatternBatteryCharging=50;5;0;rg;" /etc/mce/mce.ini |
| 13:54.02 | StyXman | there is no way to do it in the settings, only activate or not |
| 13:54.03 | DocScrutinizer | does it return a result? |
| 13:54.52 | StyXman | even better: http://pastebin.lugmen.org.ar/7380 |
| 13:55.08 | StyXman | it seems that I changed it after all |
| 13:56.33 | DocScrutinizer | no, looks good to me? |
| 13:56.53 | DocScrutinizer | aaah, FOUR |
| 13:57.23 | DocScrutinizer | well, that doesn't explain why yours doesn't work, just that I changed mine |
| 13:57.57 | DocScrutinizer | yours seems to be the original! |
| 13:58.04 | StyXman | hah! |
| 13:58.08 | DocScrutinizer | so you haven't changed anything |
| 13:58.19 | DocScrutinizer | this should cause amber blinking, not red |
| 13:59.09 | DocScrutinizer | what's the color of the LED when you push the powerbutton? is it fading in white when power up? |
| 13:59.58 | DocScrutinizer | are you connected via ssh & wlan? or typing on device? |
| 14:01.10 | StyXman | ssh+wlan |
| 14:01.33 | DocScrutinizer | well, anyway - please deactivate the amber/red charging pattern |
| 14:01.35 | StyXman | the led fades in in purple when I turn it on |
| 14:01.52 | DocScrutinizer | aaah, green LED defect |
| 14:01.55 | DocScrutinizer | please do |
| 14:02.03 | DocScrutinizer | <PROTECTED> |
| 14:02.55 | DocScrutinizer | <PROTECTED> |
| 14:04.48 | StyXman | hmm, yes, the green one seems out |
| 14:04.50 | StyXman | dang |
| 14:05.07 | StyXman | ok, I'll go for the data cables |
| 14:05.16 | DocScrutinizer | so whan your battery is full, you're definitely missing the green LED indicating that |
| 14:05.26 | DocScrutinizer | might this be root cause of your problem? |
| 14:06.33 | DocScrutinizer | ooh, and better scratch all my previous advice, the part that's been based on "red flashing LED" |
| 14:08.39 | StyXman | DocScrutinizer: everything? |
| 14:08.52 | *** join/#maemo sid__ (~sid@nrbg-4dbe0198.pool.mediaWays.net) |
| 14:08.57 | DocScrutinizer | well, we need to start from scratch |
| 14:09.07 | StyXman | «No charging, insufficient power» |
| 14:09.17 | DocScrutinizer | mhm |
| 14:09.46 | DocScrutinizer | that's an indication (though no proof) that your USB plug or receptacle is broken |
| 14:09.58 | StyXman | but it detects the connection ok, asks for mass storage or pc suite modes |
| 14:10.13 | DocScrutinizer | hmm yeah |
| 14:10.21 | StyXman | ... |
| 14:10.40 | DocScrutinizer | when does that notice show up? PC or wallwart? |
| 14:11.18 | StyXman | seems like all the time when I connect it to the PC |
| 14:11.34 | DocScrutinizer | and with wallwart? |
| 14:11.47 | StyXman | with the wallwart I don't get any message, excepts that sometimes it thinks it's connected to the pc |
| 14:11.57 | DocScrutinizer | (your PC might have a borked USB as well) |
| 14:12.04 | StyXman | or maybe just when I boot it connected to the wallwart |
| 14:12.31 | StyXman | I tried several pcs, mi NB, my desktop at wor, a coworker's, a coworker's NB... |
| 14:12.59 | StyXman | even several usb connectors in my NB |
| 14:13.38 | StyXman | ones i know they work with other stuff: usb keys, my mouse's wireless thinguie, external hard disks |
| 14:13.42 | DocScrutinizer | hmmm. I'd suggest following approach: 1. check your USB receptacle and plug for dirt, bent contacts and the like - use a mgn glass for that and good light. 2. full reflash, just to rule out any sw issues |
| 14:14.24 | DocScrutinizer | esp check USB cable, use another rcable |
| 14:14.41 | StyXman | I have two cables, and tried a third at work |
| 14:14.48 | DocScrutinizer | :nod: |
| 14:15.01 | DocScrutinizer | and I guess you're using genuine Nokia wallwart? |
| 14:15.06 | StyXman | yeap |
| 14:15.15 | DocScrutinizer | do as suggested |
| 14:15.27 | *** join/#maemo Sicelo (~Abe@41.211.32.82) |
| 14:16.08 | DocScrutinizer | odds are your USB receptacle is about to fail. On the bright side you may fix it easily in that stage, by simply resoldering and enforcing |
| 14:16.30 | StyXman | original cable: this time started charging, then said «not charging» |
| 14:16.30 | DocScrutinizer | unless it's a contact-bent issue |
| 14:19.34 | DocScrutinizer | StyXman: err, regarding reflashing - it might fail and render your system inoperable when your USB is actually borked |
| 14:19.46 | *** join/#maemo habmala (~sebb@h21n2-k-flo-a13.ias.bredband.telia.com) |
| 14:20.56 | *** join/#maemo Sicelo (~Abe@unaffiliated/sicelo) |
| 14:21.52 | DocScrutinizer | also testing with wallwart charger is way clearer setup than charging via PC |
| 14:22.29 | DocScrutinizer | there are 2 sysnodes you could check. Lemme pick them out for you |
| 14:23.19 | *** join/#maemo eijk_ (~eijk@e178225221.adsl.alicedsl.de) |
| 14:23.50 | DocScrutinizer | cat /sys/class/i2c-adapter/i2c-1/1-0048/twl4030_usb/vbus |
| 14:24.11 | DocScrutinizer | is one, shows "1" when *some* power is attached to USB |
| 14:26.05 | *** join/#maemo valerius (~user@95.153.167.133) |
| 14:26.24 | Sicelo | ~pebkac |
| 14:26.24 | infobot | PEBKAC: Problem Exists Between Keyboard And Chair. |
| 14:26.34 | Sicelo | ~fud |
| 14:26.34 | infobot | i guess fud is Fear, uncertainty, doubt. Originally invented by IBM, but now used by many others. or YAFA. or Fscking Useless Data or otherwise known as false information or mindless facts with no backup facts or http://www.winntmag.com/Articles/Index.cfm?ArticleID=7420 |
| 14:28.47 | StyXman | DocScrutinizer: it's 1 when I plug the wallwart |
| 14:29.01 | DocScrutinizer | yeah, should |
| 14:29.14 | DocScrutinizer | might actually be low though |
| 14:29.18 | StyXman | or the pc cable |
| 14:29.23 | StyXman | and 0 when it's not |
| 14:29.28 | DocScrutinizer | low on voltage |
| 14:29.39 | DocScrutinizer | it's 1 even at 3V iirc |
| 14:30.03 | DocScrutinizer | dang, can't find the other one, for D+/- short |
| 14:31.14 | DocScrutinizer | anyway, your problem is sufficiently triaged to go ahead check USB recepatcle closely with a magn glass |
| 14:33.09 | DocScrutinizer | and get (and run) http://enivax.net/jk/n900/bq27200.sh |
| 14:33.30 | DocScrutinizer | with parameter 5 |
| 14:33.40 | DocScrutinizer | for a new log every 5s |
| 14:33.58 | DocScrutinizer | you'll see "realtime" what's going on with battery charging |
| 14:34.25 | DocScrutinizer | run it *before* plugging in charger |
| 14:34.32 | DocScrutinizer | so you see the difference |
| 14:35.02 | DocScrutinizer | preferably have screen dim or locked |
| 14:35.22 | DocScrutinizer | as it needs quite a bit of power for backlight |
| 14:35.22 | StyXman | Need ./i2cget |
| 14:35.31 | DocScrutinizer | :nod: |
| 14:35.43 | RST38h | "...and mentioned his proclivity for ritual territory marking through urination, once relieving himself on a Winnie the Pooh figure at the Disneyland Hotel in Anaheim while saying "This one's for you, Walt."" |
| 14:35.56 | RST38h | Farewell. |
| 14:35.57 | DocScrutinizer | http://enivax.net/jk/n900/bq.tar |
| 14:37.32 | DocScrutinizer | StyXman: ooh, and you'll need root for that to run |
| 14:40.20 | StyXman | I am |
| 14:40.38 | StyXman | TTF never changes from 65535 and TTE changes |
| 14:40.50 | StyXman | so I guess those are time to full and tme to empty |
| 14:41.24 | DocScrutinizer | TTF/TTE are rather irrelevant, except that TTF=65535 indicates battery is DIScharging |
| 14:41.30 | DocScrutinizer | yes |
| 14:42.12 | *** join/#maemo javispedro (~javier@Maemo/community/contributor/javispedro) |
| 14:43.03 | DocScrutinizer | StyXman: 1. col (after time) is voltage at battery, 4. is current-in/out |
| 14:43.14 | StyXman | DocScrutinizer: http://pastebin.lugmen.org.ar/7381 |
| 14:43.39 | DocScrutinizer | negative current means discharge |
| 14:43.42 | StyXman | yeah, it keeps dischraging |
| 14:44.24 | DocScrutinizer | that's clearly not charging |
| 14:44.37 | DocScrutinizer | you attached charger? |
| 14:44.42 | StyXman | I plugged it after the few line feeds there |
| 14:44.50 | DocScrutinizer | mhm |
| 14:44.57 | DocScrutinizer | no visible change |
| 14:44.59 | StyXman | from line 47 |
| 14:45.07 | StyXman | no at all |
| 14:45.11 | StyXman | dang |
| 14:45.42 | StyXman | I'll test the data mode to see if it's stable enough to flash |
| 14:45.52 | DocScrutinizer | indeed |
| 14:45.57 | DocScrutinizer | ps bme |
| 14:46.00 | DocScrutinizer | please |
| 14:46.07 | StyXman | hmm |
| 14:46.15 | DocScrutinizer | ps aux|grep bme |
| 14:46.50 | StyXman | coming, I had turned it off to replace the batt, the one it has now is kinda empty |
| 14:47.45 | *** join/#maemo hurbu_ (~hurbanza@81-174-24-41.dynamic.ngi.it) |
| 14:49.27 | StyXman | <PROTECTED> |
| 14:49.28 | StyXman | <PROTECTED> |
| 14:50.13 | DocScrutinizer | hmm, loks ok |
| 14:50.51 | DocScrutinizer | I guess you actually have a hw problem |
| 14:51.00 | DocScrutinizer | check USB port optically |
| 14:51.38 | DocScrutinizer | gently try to wiggle the recepatcle with a toothpick or the like, while closely observing |
| 14:51.45 | StyXman | DocScrutinizer: looks good, but I don't have a MG |
| 14:51.55 | DocScrutinizer | MG? |
| 14:52.00 | DocScrutinizer | aah |
| 14:52.02 | StyXman | mag glass |
| 14:52.57 | DocScrutinizer | well, you're already down to the hells of hw fixing |
| 14:53.50 | MohammadAG | you rang? |
| 14:54.05 | DocScrutinizer | get a repair shop doing inspection for you and eventually fix (by resoldering), or first investigate further, e.g. by probing connection between USB and testpads under battery |
| 14:54.32 | DocScrutinizer | you find all 4 relevant signal traces there: D+/D-, vbus, and GND |
| 14:54.47 | DocScrutinizer | hi mag :-D |
| 14:55.27 | DocScrutinizer | StyXman: this one will help you no matter what you decide to do next: |
| 14:55.29 | DocScrutinizer | ~usbfix |
| 14:55.30 | infobot | hmm... usbfix is http://talk.maemo.org/showthread.php?t=75920 - and **NEVER** use epoxy (unless you want to seal your device for underwater) |
| 14:55.40 | MohammadAG | hi DocScrutinizer :D |
| 14:55.52 | RST38h | Heya Mohammad |
| 14:56.09 | RST38h | moo javispedro |
| 14:56.17 | StyXman | DocScrutinizer: nor the port shield nor the data 'film' seems to be loose |
| 14:56.20 | RST38h | notices we have got a quorum |
| 14:56.20 | javispedro | moo |
| 14:56.38 | StyXman | and finding a shop doing electronic things here... that would be interesting :| |
| 14:56.52 | DocScrutinizer | hi javispedro |
| 14:57.02 | StyXman | anyways, I don't have the tools to pry it open |
| 14:57.24 | StyXman | specially these six-point screws |
| 14:57.26 | DocScrutinizer | StyXman: if you're feeling comfortable with soldering iron, there's little to worry |
| 14:57.45 | DocScrutinizer | get a proper torx TX6 |
| 14:58.01 | StyXman | DocScrutinizer: not by any definition of confortable and/or confident :) |
| 14:58.22 | DocScrutinizer | and you should already have a proper soldering iron (no use in getting one and starting to practice) |
| 14:58.42 | StyXman | all my successful soldering was with an acid that I don't even know the name of |
| 14:58.47 | DocScrutinizer | well, then a repair shop or expert friend is your only option |
| 14:59.14 | StyXman | reapir shop I guess it's out of question |
| 14:59.18 | StyXman | there are none here |
| 14:59.26 | DocScrutinizer | please do NOT try to fix it yourself! |
| 14:59.36 | StyXman | this is the first world, they don't fix shit :-P |
| 14:59.51 | StyXman | DocScrutinizer: don't worry, at most I'll open it |
| 15:00.02 | StyXman | but again, I don't have the tools |
| 15:00.15 | DocScrutinizer | already might be a problem when you're not used to delicate electronics |
| 15:00.36 | DocScrutinizer | the flat ribbon connector from kbd to screen is sometimes quite unforgiving |
| 15:00.43 | StyXman | I'm used to delicate things, but electronics and/or soldering, no way |
| 15:01.22 | DocScrutinizer | then no use in opening the device anyway |
| 15:01.23 | StyXman | I was even about to dismantle a broken camera lens to get a MG |
| 15:02.01 | StyXman | ok, so I'll keed swapping batteries and using wifi to transfer data |
| 15:02.05 | DocScrutinizer | yeah, *closely* inspect the contacts in N900 USB receptacle |
| 15:03.29 | DocScrutinizer | sometimes debris or oxid afects the contacts |
| 15:03.41 | DocScrutinizer | sometimes one even is bent |
| 15:04.23 | DocScrutinizer | not that you could probably do much when the contact is bent, other than replacing whole recepacle |
| 15:04.27 | StyXman | DocScrutinizer: the contacts in the little piece of plastic in the port? |
| 15:04.35 | DocScrutinizer | yep |
| 15:04.38 | StyXman | wow |
| 15:04.41 | DocScrutinizer | 5 of them |
| 15:05.06 | DocScrutinizer | two are a bit longer than the other 3 |
| 15:05.08 | StyXman | ok, I'll let it pass for now |
| 15:05.25 | StyXman | DocScrutinizer: ah, in the plug |
| 15:05.26 | DocScrutinizer | the longer ones are GND and vbus |
| 15:05.31 | StyXman | in the cable |
| 15:05.37 | DocScrutinizer | both |
| 15:05.46 | DocScrutinizer | in receptacle and cable |
| 15:06.06 | DocScrutinizer | since you tested with several cables, you can excluse them from inspection I guess |
| 15:06.52 | StyXman | let me put up some photos |
| 15:07.16 | *** join/#maemo sasquatch (~username@46.115.19.116) |
| 15:08.40 | DocScrutinizer | I'm rather sure no photo can show sufficient detail to let me tell about status of your USB receptacle (unless thoroughly wrecked) |
| 15:08.55 | StyXman | DocScrutinizer: ok |
| 15:10.25 | DocScrutinizer | http://en.wikipedia.org/wiki/File:USB_Micro-B_receptacle.jpg |
| 15:11.04 | DocScrutinizer | actually the contacts in receptacle are not spring loaded |
| 15:12.06 | DocScrutinizer | so they must be comletely flat in their "trenches", and no debris in the trenches either |
| 15:12.13 | StyXman | DocScrutinizer: no, that's for the A type or something |
| 15:12.19 | StyXman | the mini usb? |
| 15:12.29 | DocScrutinizer | ?? |
| 15:12.44 | StyXman | nevermind |
| 15:14.00 | DocScrutinizer | if that's unclear: the contacts are the "golden" little things in that picture |
| 15:14.36 | DocScrutinizer | and it's exactly what you see when looking at your N900 USB recepatcle |
| 15:14.45 | DocScrutinizer | what you *should* see |
| 15:15.31 | *** join/#maemo Corsac (~yap@molly.corsac.net) |
| 15:16.44 | *** join/#maemo Kilroo (~Kilroo@cpe-098-026-200-222.triad.res.rr.com) |
| 15:17.20 | DocScrutinizer | but odds are you have to resolder the USB anyway |
| 15:17.36 | DocScrutinizer | and you better do that before you use it any further |
| 15:18.07 | DocScrutinizer | cya |
| 15:18.09 | DocScrutinizer | o/ |
| 15:22.08 | ShadowJK | "blinked once or twice red", heh, if it's more than one blink/flasg at approx 1 second interval, there's a problem |
| 15:23.16 | DocScrutinizer | nah, it's simply the amber flashing |
| 15:23.28 | DocScrutinizer | with broken green led |
| 15:24.11 | DocScrutinizer | (actually I guess it blinks like 4 to 5 times, before the bootphase-2 kicks in) |
| 15:25.11 | DocScrutinizer | unless it detects charging failure due to powersource-bad prior to that, and thus stops charging all together |
| 15:25.56 | DocScrutinizer | ShadowJK: I pondered to suggest running your charge.sh, but the additional info gathered from it is marginal I guess |
| 15:26.24 | DocScrutinizer | only relevant info wuld be errorcode of bq24150 |
| 15:26.39 | DocScrutinizer | which I bet is powersource-bad |
| 15:27.44 | DocScrutinizer | and since I wasn't aware if your script even checks and decodes the errorstate, I didn't suggest |
| 15:28.39 | ShadowJK | well with blink I mean 20ms long blink, not the glowing thing :) |
| 15:28.49 | DocScrutinizer | yeah I know |
| 15:28.56 | *** join/#maemo trumee (~parul@188-222-165-248.zone13.bethere.co.uk) |
| 15:28.58 | StyXman | FWIW: http://grulicueva.homelinux.net/~mdione/DSC_8733.JPG |
| 15:29.08 | ShadowJK | It decodes error state to /home/user/MyDocs/charger.log |
| 15:29.13 | ShadowJK | or charge.log, I forget |
| 15:29.36 | DocScrutinizer | oooh, nice photo |
| 15:29.51 | DocScrutinizer | looks OK'ish |
| 15:30.04 | DocScrutinizer | which isn't the best msg |
| 15:30.32 | StyXman | the golden tracks look either dirty or ... wared off? |
| 15:30.45 | StyXman | dang, my english is more broken than usual |
| 15:31.08 | DocScrutinizer | migth be just a bit of wear |
| 15:31.25 | StyXman | http://grulicueva.homelinux.net/~mdione/DSC_8734.JPG |
| 15:31.26 | DocScrutinizer | not really concerning in my book |
| 15:31.59 | ShadowJK | I'd sugges apt-get install i2c-tools (extras-devel), get my charge21.sh script, unplug charger, stop bme, plug in charger, start ./charge21.sh, paste console output as well as /home/user/MyDocs/charge.log |
| 15:32.08 | DocScrutinizer | you could try 'polishing' with a wooden toothpick |
| 15:32.55 | DocScrutinizer | ShadowJK: \o/ |
| 15:33.50 | *** join/#maemo ArGGu^^ (~arggu@91-157-140-34.elisa-laajakaista.fi) |
| 15:34.13 | DocScrutinizer | StyXman: now the guru of charging takes care of you. at the end of this day there's nothing left you could learn about your problem |
| 15:34.15 | StyXman | enables extras deve; |
| 15:34.24 | *** join/#maemo mase76 (~mase76@p5DD3928D.dip.t-dialin.net) |
| 15:34.25 | ShadowJK | Also the line you were looking for is: cat /sys/devices/platform/musb_hdrc/charger |
| 15:34.39 | DocScrutinizer | yeah |
| 15:35.00 | DocScrutinizer | why didn't friggin find not find it when -iname charg |
| 15:35.38 | DocScrutinizer | ShadowJK: thanks a lot :-) |
| 15:35.44 | *** join/#maemo machia (~shusso@dsl-hkibrasgw4-fe5fdc00-220.dhcp.inet.fi) |
| 15:36.40 | DocScrutinizer | StyXman: above line shall tell you about D+/- short which indicates fastcharger plugged in - unless datalines have a contact issue |
| 15:37.41 | DocScrutinizer | "1" means fastcharger aka shorted lines |
| 15:38.25 | DocScrutinizer | if that's 0 for you when wallwart plugged, it'd result in charging @ 100mA only |
| 15:38.55 | DocScrutinizer | and qould indicate any contact problem in USB |
| 15:39.00 | DocScrutinizer | would even |
| 15:40.39 | DocScrutinizer | anyway, now that ShadowJK is here, I'm dispensable and can finally take my shower :-) |
| 15:40.51 | DocScrutinizer | good luck! |
| 15:44.59 | *** join/#maemo trx (~ns-team@212.200.199.87) |
| 16:02.25 | *** join/#maemo _federico3 (~fede@86-44-192-163-dynamic.b-ras2.dbn.dublin.eircom.net) |
| 16:20.05 | *** join/#maemo psycho_oreos (~no@unaffiliated/tuxsavvy) |
| 16:20.27 | StyXman | ok, cleaning didn't help, last tests |
| 16:23.46 | *** join/#maemo MrPingu (~chatzilla@86.92.226.97) |
| 16:24.41 | *** join/#maemo geaaru (~geaaru@host215-22-dynamic.21-87-r.retail.telecomitalia.it) |
| 16:25.39 | *** join/#maemo sq-one (~sq-one@p54A1FE1F.dip.t-dialin.net) |
| 16:29.43 | *** join/#maemo freemangordon (freemangor@130-204-50-168.2074156771.ddns.cablebg.net) |
| 16:29.48 | *** join/#maemo valdyn (~valdyn@valdyn.org) |
| 16:29.57 | freemangordon | ~seen jonwil |
| 16:30.00 | infobot | jonwil <~jonwil@27-33-137-199.static.tpgi.com.au> was last seen on IRC in channel #maemo, 6d 28m 25s ago, saying: 'not'. |
| 16:33.49 | *** join/#maemo trbs (~trbs@2001:470:d2ad:1:4a5b:39ff:fe7d:1623) |
| 16:38.09 | *** join/#maemo Roomerlol (~Roomerlol@89-178-113-225.broadband.corbina.ru) |
| 16:39.10 | *** join/#maemo eMHa (~mh@HSI-KBW-078-042-037-221.hsi3.kabel-badenwuerttemberg.de) |
| 16:39.13 | *** join/#maemo ced117 (~ced117@AStrasbourg-552-1-81-118.w92-141.abo.wanadoo.fr) |
| 16:39.13 | *** join/#maemo ced117 (~ced117@opensuse/member/ced117) |
| 16:56.17 | *** join/#maemo NIN101 (~NIN@206.253.166.69) |
| 17:00.09 | *** join/#maemo vblazquez (~vic@35.41.15.37.dynamic.jazztel.es) |
| 17:05.09 | *** join/#maemo mase_76 (~mase76@p5DD3BF97.dip.t-dialin.net) |
| 17:07.49 | *** join/#maemo hurbu__ (~hurbanza@81-174-24-120.dynamic.ngi.it) |
| 17:09.41 | *** join/#maemo Zahra (~Zahra@unaffiliated/belendax) |
| 17:29.59 | *** join/#maemo auenf (David@171.72.233.220.static.exetel.com.au) |
| 17:31.44 | *** join/#maemo OkropNick (kuba@host-n2-72-190.telpol.net.pl) |
| 17:38.41 | *** join/#maemo OkropNick (kuba@host-n2-72-190.telpol.net.pl) |
| 17:46.55 | *** join/#maemo Muelli (~muelli@port-23070.pppoe.wtnet.de) |
| 17:52.07 | *** join/#maemo dos1 (~dos@unaffiliated/dos1) |
| 17:54.59 | *** join/#maemo ponyofdeath (~vladi@cpe-75-80-173-94.san.res.rr.com) |
| 18:04.05 | *** join/#maemo Dibblah_ (~Dibblah@cpc2-dund11-2-0-cust798.sgyl.cable.virginmedia.com) |
| 18:06.03 | *** join/#maemo mece (~mece@dsl-tkubrasgw1-fe2edc00-208.dhcp.inet.fi) |
| 18:06.03 | *** part/#maemo mece (~mece@dsl-tkubrasgw1-fe2edc00-208.dhcp.inet.fi) |
| 18:13.47 | *** join/#maemo Dibblah (~Dibblah@cpc2-dund11-2-0-cust798.sgyl.cable.virginmedia.com) |
| 18:15.18 | *** join/#maemo sid__ (~sid@p57AF26D3.dip.t-dialin.net) |
| 18:29.49 | *** join/#maemo sid__ (~sid@p57AF26D3.dip.t-dialin.net) |
| 18:34.37 | *** join/#maemo rcg (~rc@g230052231.adsl.alicedsl.de) |
| 18:35.08 | *** join/#maemo sicelo_ (~sicelo@unaffiliated/sicelo) |
| 18:55.08 | *** join/#maemo NIN101 (~NIN@206.253.166.69) |
| 18:56.36 | *** join/#maemo hurbu_ (~hurbanza@81-174-25-219.dynamic.ngi.it) |
| 18:57.58 | *** join/#maemo NishanthMenon (~nmenon@cpe-76-183-244-31.tx.res.rr.com) |
| 18:59.18 | *** join/#maemo Dibblah (~Dibblah@cpc2-dund11-2-0-cust798.sgyl.cable.virginmedia.com) |
| 19:04.19 | *** join/#maemo Dibblah (~Dibblah@cpc2-dund11-2-0-cust798.sgyl.cable.virginmedia.com) |
| 19:08.54 | *** join/#maemo piggz (~piggz@host-92-23-102-160.as13285.net) |
| 19:25.43 | *** join/#maemo nox- (noident@freebsd/developer/nox) |
| 19:30.13 | *** join/#maemo trumee (~parul@188-222-165-248.zone13.bethere.co.uk) |
| 19:40.01 | *** join/#maemo sid__ (~sid@nrbg-4dbe0198.pool.mediaWays.net) |
| 19:45.25 | *** join/#maemo retro|cz (~retro@ip-62-245-67-4.net.upcbroadband.cz) |
| 20:03.25 | *** join/#maemo swc|666 (~goldbond@Aircrack-NG/Friend) |
| 20:03.27 | *** join/#maemo mavhc (~mavhc@cpc3-basf10-2-0-cust617.12-3.cable.virginmedia.com) |
| 20:14.51 | *** part/#maemo Corsac (~yap@molly.corsac.net) |
| 20:35.08 | *** join/#maemo robink_ (~quassel@fatcat.creosotehill.org) |
| 20:37.34 | *** join/#maemo piggz (~piggz@host-92-23-102-160.as13285.net) |
| 20:39.30 | *** join/#maemo robink (~quassel@unaffilated/robink) |
| 20:45.52 | piggz | can N900 apps in the store use QML/QtQuick? (and does that extend to qt-components) |
| 20:48.07 | merlin1991 | you can use everything from the -ssu repo |
| 20:48.11 | merlin1991 | so qt-components yes |
| 20:48.17 | merlin1991 | the components from extras, no |
| 20:48.41 | merlin1991 | why would you want to go to the store with an n900 app anyway? |
| 20:48.48 | merlin1991 | isn't extras more appropriate? |
| 21:02.52 | *** join/#maemo Abissom (~Abe@unaffiliated/sicelo) |
| 21:04.26 | piggz | merlin1991: just wondered..last time i checked, qml was a no-go in the store, it must have been added to the -ssu repo at some point? |
| 21:04.44 | merlin1991 | hm I'm pretty sure it's ok |
| 21:04.50 | merlin1991 | though I'm not 100% sure |
| 21:04.51 | merlin1991 | :/ |
| 21:09.19 | DocScrutinizer | merlin1991: missing sleep? |
| 21:09.27 | merlin1991 | huh? |
| 21:09.54 | DocScrutinizer | I just thought you might need a break. Maybe it's me who does |
| 21:14.11 | merlin1991 | nah lately I'm active from 13 - 04 CET :D |
| 21:14.25 | merlin1991 | my sleeping time shifted into the day :) |
| 21:15.48 | DocScrutinizer | hmm, I know this from my rhythm, too well |
| 21:17.26 | merlin1991 | I'm currently trying to shift if back again |
| 21:17.55 | merlin1991 | but always around midnight I find something interesting and end up investing about 4 hours :D |
| 21:30.24 | *** join/#maemo Sazpaimon (wat@c-68-32-58-174.hsd1.nj.comcast.net) |
| 21:37.17 | *** join/#maemo ArGGu^^ (~arggu@91-157-140-34.elisa-laajakaista.fi) |
| 22:03.31 | *** join/#maemo javispedro (~javier@Maemo/community/contributor/javispedro) |
| 22:11.57 | MohammadAG | merlin1991, no qt-components in store |
| 22:12.15 | MohammadAG | you can workaround that by including them with your app |
| 22:12.16 | merlin1991 | okay |
| 22:14.47 | *** join/#maemo MrPingu (~MrPingu@86.92.226.97) |
| 22:51.04 | *** join/#maemo Jade (~jade@bas2-montreal33-2925045562.dsl.bell.ca) |
| 22:51.04 | *** join/#maemo Jade (~jade@unaffiliated/jade) |
| 22:54.10 | *** join/#maemo t_s_o (~tso@202.84-48-230.nextgentel.com) |
| 22:56.29 | *** join/#maemo ALoGeNo (~alogeno@unaffiliated/alogeno) |
| 23:05.25 | *** join/#maemo DrGrov (~C.J@a91-153-77-41.elisa-laajakaista.fi) |
| 23:07.20 | *** join/#maemo DrGrov (~C.J@a91-153-77-41.elisa-laajakaista.fi) |
| 23:11.15 | *** join/#maemo lbt_away (~david@78.32.229.233) |
| 23:11.15 | *** join/#maemo lbt_away (~david@Maemo/community/contributor/lbt) |
| 23:11.24 | *** join/#maemo lbt_ (~david@78.32.229.233) |
| 23:14.44 | *** join/#maemo croppa (~stuart@CPE-120-146-137-99.static.nsw.bigpond.net.au) |
| 23:16.08 | *** join/#maemo Hurrian (~yuki@121.54.2.104) |
| 23:20.50 | *** join/#maemo SmilybOrg (Smily@89.142.240.159) |
| 23:24.36 | ShadowJK | though that would increase runtime memory requirements i bet |
| 23:28.02 | *** part/#maemo DrGrov (~C.J@a91-153-77-41.elisa-laajakaista.fi) |
| 23:30.56 | *** join/#maemo xev (~xev@unaffiliated/xev) |
| 23:31.07 | *** join/#maemo Muelli (~muelli@port-23070.pppoe.wtnet.de) |
| 23:42.26 | *** join/#maemo dangergrrl (~a@70.99.126.54) |
| 23:45.26 | *** join/#maemo xev (~xev@unaffiliated/xev) |
| 23:54.05 | *** join/#maemo PeterWolf (~peter@114-44-231-173.dynamic.hinet.net) |
