| 00:00:02 | saratoga_ | i was going to try and work on the MDCT stuff for it, but no time until feb due to work and research |
| 00:00:56 | preglow | yeah, work and trying to be a studio engineer will be taking my time for some months to come |
| 00:01:14 | preglow | arm is always nice :> |
| 00:01:29 | saratoga_ | they want a NEON version of the FFT |
| 00:02:58 | preglow | never even touched neon, so that would be cool :) |
| 00:03:17 | preglow | i wonder what arm device would be nicest for dev work |
| 00:03:51 | saratoga_ | i bought a raspberry pi last year |
| 00:03:57 | preglow | got a couple lying around at work |
| 00:04:11 | saratoga_ | its nice because i can compile on it, but i'd probably try to get something with NEON too |
| 00:04:19 | preglow | but tool wise an apple device would probably be nicer |
| 00:04:32 | saratoga_ | will probably try setting up debian on my old nexus since it has an A9 |
| 00:05:05 | preglow | i'd very much like to cross compile and upload code instead of working on target |
| 00:05:45 | saratoga_ | the pi takes forever to do a make clean, but otherwise its quite fast because i don't have to copy anything on subsequent builds |
| 00:06:07 | saratoga_ | not bad for 700MHz ARM11 really |
| 00:06:53 | saratoga_ | but i guess the best option would be somethign with cross compiling and some kind of remote debug, but i don't know anything about that |
| 00:07:14 | preglow | done some ipad app development, and that's like that |
| 00:07:56 | preglow | i assume android has it too |
| 00:10:04 | | Quit bertrik (Ping timeout: 252 seconds) |
| 00:12:29 | | Quit wodz (Quit: Leaving) |
| 00:36:01 | | Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 27.0/20140116125114]) |
| 00:36:28 | | Quit uwe_ (Ping timeout: 252 seconds) |
| 00:41:14 | | Quit W00fer () |
| 00:42:14 | | Join uwe_ [0] (~uwe_@dslb-088-066-160-105.pools.arcor-ip.net) |
| 00:56:27 | | Quit ender` (Quit: I know a joke about UDP, but you might not get it.) |
| 00:56:54 | *** | Saving seen data "./dancer.seen" |
| 00:56:55 | [Saint] | saratoga_: factory OC to 1GHz makes quite an improvement in compile time |
| 00:57:28 | [Saint] | 300MHz doesn;t seem like heaps, but its essentially adding 1/3 more CPU to the wee thing. |
| 00:58:11 | * | [Saint] can't math |
| 00:58:19 | [Saint] | ~50% more CPU |
| 00:58:31 | saratoga | is that easy to do? |
| 00:59:29 | [Saint] | Sure. running rpi-config (gui), or hand editing /boot/config.txt |
| 00:59:44 | [Saint] | (the config is well commented) |
| 00:59:48 | saratoga | oh cool, will look into it |
| 01:00 |
| 01:00:02 | [Saint] | You can also adjust the CPU/GPU memory split there. |
| 01:00:28 | [Saint] | By default, 64MB is reserved for the GPU, but if you're not using it...you can carve it right back to 8MB iirc. |
| 01:01:21 | [Saint] | saratoga_: http://elinux.org/RPiconfig |
| 01:02:19 | * | [Saint] also really recommends using USB storage for / |
| 01:02:41 | [Saint] | Get everything except /boot off the sdcard |
| 01:03:55 | [Saint] | You can go as high as 1.2GHz, but stability varies greatly between devices and this will set the warranty bit (if you care about that). |
| 01:05:38 | [Saint] | There's also a "force_turbo" mode that disables dynamic clocking and allows for uninhibited overvolting. |
| 01:06:07 | [Saint] | The power usage hit from forcing the maximum CPU/GPU clocks is actually really trivial too. |
| 01:08:00 | [Saint] | My setup is arm_freg=1200, core_freq=500, sdram_freq=600, over_voltage=8 |
| 01:09:00 | [Saint] | (200MHz shy of running 200% OC stable) |
| 01:09:02 | fs-bluebot | Gerrit review #200 at http://gerrit.rockbox.org/r/200 : Fundamentally rewrite much of the audio DSP. by Michael Sevakis (changes/00/200/17) |
| 01:09:37 | [Saint] | bluebrother: I just found another fs-bluebot quirk :) |
| 01:09:42 | * | [Saint] kicks fs-bluebot |
| 01:10:01 | [Saint] | (123 |
| 01:10:14 | [Saint] | 123% |
| 01:10:25 | [Saint] | Hmmm. |
| 01:10:42 | [Saint] | (123 123%) |
| 01:11:01 | [Saint] | (200MHz shy of running 200% OC stable) |
| 01:11:02 | fs-bluebot | Gerrit review #200 at http://gerrit.rockbox.org/r/200 : by Michael Sevakis (changes/00/200/17) |
| 01:11:09 | [Saint] | what the? |
| 01:11:17 | Soukyuu | you have to kick it more |
| 01:11:51 | [Saint] | test (123MHz) |
| 01:12:06 | [Saint] | test (123MHz 123%) |
| 01:12:28 | [Saint] | What is it matching on? Gah! |
| 01:12:50 | Soukyuu | stable) ? |
| 01:13:03 | Soukyuu | hmm doesn't seem so |
| 01:13:13 | gevaerts | g 200 |
| 01:13:14 | fs-bluebot | Gerrit review #200 at http://gerrit.rockbox.org/r/200 : Fundamentally rewrite much of the audio DSP. by Michael Sevakis (changes/00/200/17) |
| 01:13:22 | gevaerts | easy :) |
| 01:13:22 | [Saint] | Hmmm, maybe the task "123" doesn't exist |
| 01:13:42 | [Saint] | (412 |
| 01:13:51 | | Quit fs-bluebot (Remote host closed the connection) |
| 01:13:52 | [Saint] | 412% |
| 01:14:04 | Soukyuu | lol |
| 01:14:06 | [Saint] | Hehe...I think I broke him. |
| 01:14:08 | | Join fs-bluebot [0] (~fs-bluebo@g224236191.adsl.alicedsl.de) |
| 01:14:52 | [Saint] | (412Mhz |
| 01:15:01 | [Saint] | bah. |
| 01:15:10 | Soukyuu | curious, do bug reports on the flyspray take a while to appear on the overview page or does an admin have to approve it first for new users? |
| 01:15:33 | Soukyuu | *tasklist, not overview |
| 01:15:42 | gevaerts | [Saint]: what are you trying to do? |
| 01:16:09 | [Saint] | gevaerts: Oh, derp. Neverming. |
| 01:16:16 | [Saint] | I just figured it out. Whoops. |
| 01:16:22 | [Saint] | I didn;t see your post. |
| 01:16:34 | gevaerts | :) |
| 01:16:35 | [Saint] | It picked out the g from "running" |
| 01:17:03 | [Saint] | So, "running 412" should do it. |
| 01:17:04 | fs-bluebot | Gerrit review #412 at http://gerrit.rockbox.org/r/412 : Option to use the lighter hinting algorithm (FT_LOAD_TARGET_LIGHT). by Nick Peskett (changes/12/412/1) |
| 01:17:07 | gevaerts | It should check for a word boundary there, really |
| 01:17:07 | [Saint] | Aha. |
| 01:17:12 | * | [Saint] nods |
| 01:17:43 | [Saint] | I've asked to be nosey at the source a few times, but bluebrother sems content maintaining it himself. |
| 01:17:47 | [Saint] | Which is fine. |
| 01:18:42 | [Saint] | Soukyuu: Are you sure you don;t just have the list ordered incorrectly? |
| 01:18:49 | [Saint] | I can see your task fine. |
| 01:18:58 | [Saint] | *after* I order the list by recent addition. |
| 01:19:04 | Soukyuu | [Saint]: silly me, just noticed |
| 01:19:46 | Soukyuu | I expected it to be ordered by date by default i guess |
| 01:20:45 | * | [Saint] isn;t terribly sure if that is a bug or not. |
| 01:21:16 | Soukyuu | my report or the list ordering |
| 01:21:23 | [Saint] | Your report. |
| 01:21:24 | gevaerts | It's not |
| 01:21:28 | gevaerts | oh |
| 01:21:33 | * | gevaerts shuts up |
| 01:22:17 | Soukyuu | [Saint]: I just don't see why it would need the peak tag to simply apply the gain |
| 01:22:46 | Soukyuu | and foobar2000 does get it to work somehow, unless it calculates peak on the fly or something |
| 01:22:49 | [Saint] | Assumedly because we follow spec. |
| 01:23:23 | [Saint] | replaygain spec requires peak gain and amplitude to be in the metadata. |
| 01:24:33 | [Saint] | So this probably falls into the category of "not necessarily a bug, but definitely not immediately obvious to Jow User" |
| 01:24:40 | [Saint] | *Joe |
| 01:25:15 | Soukyuu | hmm, well let's say it's not a bug, but does it have to fail to apply the gain if clipping according to peak is off? |
| 01:25:43 | Soukyuu | personally I don't see a reason to simply not apply clipping protection if peak not present |
| 01:26:21 | Soukyuu | i think there is a "not" missing there somewhere |
| 01:27:26 | Soukyuu | or not, my English skills reduce late at night... |
| 01:27:58 | [Saint] | I have no idea how foobar handles this, but, its definitely not within spec. |
| 01:28:12 | saratoga | probably the parser looks for the peak tag or something |
| 01:28:51 | [Saint] | ...huh? |
| 01:29:18 | saratoga | probably our tag parser expects the peak tag to be there and gives up if its not |
| 01:29:33 | [Saint] | Oh, right. Yes. Which is perfectly sane. |
| 01:29:43 | [Saint] | (I thought you were referring to foobar) |
| 01:29:52 | Soukyuu | shouldn't it be checking for the _gain_ tag instead though? |
| 01:30:04 | Soukyuu | and peak in case of clipping prevention? |
| 01:30:28 | | Quit uwe_ (Ping timeout: 248 seconds) |
| 01:31:04 | | Join uwe_ [0] (~uwe_@dslb-088-066-160-105.pools.arcor-ip.net) |
| 01:31:16 | saratoga | yeah, looks like if its id3v2.4 it requires both to be there |
| 01:31:45 | * | [Saint] nods |
| 01:31:45 | Soukyuu | it happens with ape and vobist comments as well |
| 01:32:05 | Soukyuu | i might be wrong but isn't applying gain done by simply adjusting each ... sample i guess?, by the value specified in the gain tag? from my view, I dont see the peak tag being involved in this at all |
| 01:32:39 | [Saint] | In this specific case, it isn't, no - but that's not the point. |
| 01:33:00 | [Saint] | The point is that we follow the specification, which these files break. |
| 01:33:09 | [Saint] | (and foobar apparently does too) |
| 01:33:33 | saratoga | hmm actually i'm not sure now that i look at this more |
| 01:34:29 | Soukyuu | [Saint], just for reference, where do i find the spec? i seem to only get wiki/HA links which don't go into detail |
| 01:34:44 | Soukyuu | ah |
| 01:34:54 | Soukyuu | nvm, found it |
| 01:35:03 | [Saint] | As far as I'm aware, the replaygain specification requires 4 tags - REPLAYGAIN_TRACK_GAIN, REPLAYGAIN_TRACK_PEAK, REPLAYGAIN_ALBUM_GAIN, and REPLAYGAIN_ALBUM_PEAK |
| 01:35:37 | [Saint] | Any one of those missing /should/ make replaygain fall over. |
| 01:35:58 | Soukyuu | yes, reading it at the moment |
| 01:36:02 | [Saint] | ...but, I am far from absolutely certain on this. |
| 01:36:19 | Soukyuu | if this is up to date, then it does: http://wiki.hydrogenaudio.org/index.php?title=ReplayGain_specification#Metadata |
| 01:36:37 | Soukyuu | "For ReplayGain to do its work during playback, four values must be stored" |
| 01:37:11 | [Saint] | As for ape/vorbis comments, ...they're just insane in general. |
| 01:37:21 | [Saint] | I'm not sure there's a "right" way to do anything with them. :) |
| 01:41:04 | saratoga | actually i think its not the tag parsers, i think instead the dsp core is passed a peak value of 0, which is rejected as out of range |
| 01:41:44 | Soukyuu | does that mean there is a chance it's an undesired behavior and might get fixed? :D |
| 01:41:58 | saratoga | hmm no that also seems wrong |
| 01:42:01 | | Join Strife89 [0] (~Strife89@adsl-98-80-237-249.mcn.bellsouth.net) |
| 01:42:15 | saratoga | it should probably be fixed |
| 01:42:44 | [Saint] | By my understand this behavious is "correct". |
| 01:42:50 | [Saint] | *behavior |
| 01:43:24 | Soukyuu | by my understanding it's non-intuitive, but i'm just a user :x |
| 01:44:18 | [Saint] | I think we should probably just expect users to tag their files sanely, and retag after transcoding/whatever. |
| 01:44:34 | [Saint] | Then, it'll work as expected across the board. |
| 01:44:47 | saratoga | i think you'd have to put some debug statements in the sim and print out the value at a couple points to see if its the parser or the dsp engine that complains, but if it happens to a couple different formats, its probably the dsp |
| 01:45:14 | Soukyuu | so far it happened with mp3, flac and mpc |
| 01:45:39 | [Saint] | That would be expected. |
| 01:45:44 | Soukyuu | so, id3v2.3 (utf-8), apev2 and vorbis comments |
| 01:46:21 | Soukyuu | but peak is not involved in gain calculation, at least as the spec states it |
| 01:46:51 | [Saint] | Instead of working around this, it seems much saner to me that you should just re-scan for replaygain. |
| 01:47:25 | saratoga | the gain is potentially scaled by the peak value, so its reasonable to make sure the peak value isn't zero |
| 01:47:38 | saratoga | probably somewhere the code just rejects the whole thing if any of the values are out of range |
| 01:47:48 | saratoga | you'd have to grep |
| 01:48:00 | [Saint] | ...I can't really fault the logic. |
| 01:48:12 | Soukyuu | but that's only in case clipping prevention is on, right? |
| 01:48:16 | [Saint] | "Have propper tags, it'll work" |
| 01:48:37 | Soukyuu | problem is, applying those tags takes as long as copying the files over |
| 01:48:38 | [Saint] | remove half of them? well...here we are. |
| 01:48:45 | Soukyuu | i do understand the point that there have to be 4 tags in total (or rather, a pair of gain+peak), but that's to "ensure full functionality" of RG. So partial functionality should still be preserved imho *shrug* |
| 01:48:51 | chrisjj | [Saint]: re "the replaygain specification requires 4 tags". It is self-contradictory. Yes according to section "Metadata", No according to "Loudness normalization". |
| 01:49:41 | chrisjj | Soukyuu: "If the file only contains one of the replay gain adjustments (e.g. Album) but the user has requested the other (Track), then the player should use the one that is available (in this case, Album)." |
| 01:50:58 | Soukyuu | chrisjj: yes, but what i'm asking is not about track vs album gain when one missing |
| 01:51:11 | Soukyuu | instead what is gain is present, but _peak_ isn't |
| 01:51:22 | Soukyuu | loudness normalization only requires the gain tag... peak is only mentioned in clipping prevention section of the spec |
| 01:54:36 | Soukyuu | saratoga: i have a linux vm, but i haven't worked with rockbox code before, do I have to set it up as mentioned in the wiki to run the debug output or is it done on device? |
| 01:57:42 | saratoga | Soukyuu: if you want to open up this mess, the /lib/rbcodec folder has /metadata and /dsp which is where all this happens |
| 01:57:54 | saratoga | i would build a simulator (doesn't matter which device) |
| 01:58:09 | saratoga | then you can use DEBUGF to print values to the console |
| 01:58:55 | saratoga | might be interesting to see if the gain values are correct here: http://git.rockbox.org/?p=rockbox.git;a=blob;f=lib/rbcodec/dsp/dsp_misc.c;h=ad6f5b5b3107d1c3bb0028db73fce1aea6498a73;hb=HEAD#l40 |
| 01:59:05 | saratoga | anyway i have to get back to work |
| 01:59:28 | Soukyuu | thanks, will take a look |
| 02:00 |
| 02:00:48 | saratoga | oh and we don't have floating point, so those values will probably be in the form of scaled integers (e.g. some big power of 2 times the actual value) |
| 02:15:14 | Soukyuu | ha, funny. if i delete only the album peak or only the track peak, then RG still works - and it applies track gain even though there is no track peak apparently. (tested by listening) |
| 02:21:06 | chrisjj | Soukyuu: "[when] gain is present, but _peak_ isn't" That's outside what's specified by the spec. |
| 02:24:24 | Soukyuu | chrisjj: I guess it is. |
| 02:25:13 | Soukyuu | thanks for the answers, I will try to persuade the fb2k devs to conform with the specs, as having only gain tags is pretty much useless |
| 02:25:42 | | Quit Soukyuu (Quit: goodnight) |
| 02:33:14 | [Saint] | Bah. He's gone. |
| 02:33:31 | [Saint] | The other situation he describes is expected also, but also non-obvious. |
| 02:34:06 | [Saint] | I seem to recall album/track gain will fall back to each other if the other one isn't present and the user tries to set it. |
| 02:46:27 | | Quit saratoga_ (Quit: Page closed) |
| 02:56:56 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:18:00 | | Quit babylonlurker (Read error: Operation timed out) |
| 03:32:20 | | Join babylonlurker [0] (~quassel@veda.xs4all.nl) |
| 03:43:32 | | Join Cultist [0] (~CultOfThe@c-67-186-111-33.hsd1.il.comcast.net) |
| 03:45:05 | | Quit krabador (Quit: Sto andando via) |
| 04:00 |
| 04:01:46 | | Quit [Saint] (Remote host closed the connection) |
| 04:04:17 | | Join [Saint] [0] (~saint@rockbox/staff/saint) |
| 04:41:45 | | Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) |
| 04:41:45 | | Quit pixelma (Disconnected by services) |
| 04:41:46 | | Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) |
| 04:41:46 | | Quit amiconn (Disconnected by services) |
| 04:41:46 | | Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) |
| 04:41:48 | | Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) |
| 04:45:21 | | Join popole [0] (~popole@193.104.110.37) |
| 04:57:00 | *** | Saving seen data "./dancer.seen" |
| 05:00 |
| 05:14:04 | | Quit popole (Remote host closed the connection) |
| 05:50:08 | | Quit [7] (Disconnected by services) |
| 05:50:21 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 06:00 |
| 06:25:43 | | Quit [Saint] (Remote host closed the connection) |
| 06:26:45 | | Join [Saint] [0] (~saint@rockbox/staff/saint) |
| 06:27:09 | | Join mortalis [0] (~kvirc@213.33.220.118) |
| 06:57:01 | *** | Saving seen data "./dancer.seen" |
| 07:00 |
| 07:53:56 | | Join LinusN [0] (linus@giant.haxx.se) |
| 07:55:57 | | Join fragilematter [0] (~fragilema@unaffiliated/fragilematter) |
| 08:00 |
| 08:19:54 | copper | "having only gain tags is pretty much useless" |
| 08:20:45 | copper | "I just don't see why it would need the peak tag to simply apply the gain" |
| 08:21:10 | copper | I don't get it |
| 08:21:33 | copper | indeed peak information is only useful when using the "prevent clipping according to peak" functionality |
| 08:22:30 | copper | and if the peak value is missing, I'd just assume it's 1.0 FS |
| 08:23:10 | copper | and if the result clips, users can only blame themselves |
| 08:26:33 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 08:26:45 | copper | it's all about sensible defaults and failing gracefully, IMO |
| 08:27:25 | copper | "doesn't work at all when less than 100% of expected data is there" is a lazy approach |
| 08:36:02 | | Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) |
| 08:38:03 | | Join tertu [0] (~tertu@143.44.70.199) |
| 08:38:31 | | Join Zagor [242] (~bjst@rockbox/developer/Zagor) |
| 08:40:12 | | Quit sakax (Quit: Leaving) |
| 08:44:40 | | Join bertrik [0] (~quassel@ip117-49-211-87.adsl2.static.versatel.nl) |
| 08:44:40 | | Quit bertrik (Changing host) |
| 08:44:40 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
| 08:46:02 | copper | actually know, it would make more sense to disable clipping prevention |
| 08:46:07 | copper | no* |
| 08:46:39 | copper | so as to not alter the gain based on an arbitrary value |
| 08:47:00 | | Join leftright [0] (c5e0116e@gateway/web/freenode/ip.197.224.17.110) |
| 08:52:59 | leftright | Slasheri : nls ; LinusN ; H140. rockbox hangs during boot with any version after v3.8 with boot set to either Rom or Ram, from disk it will freeze on first boot and load after reset. it seems that it's related to this http://www.rockbox.org/tracker/task/12769 |
| 08:55:08 | leftright | If unable to fix please make a note somewhere that roxkbox won't boot from flash with latest versions of roxkbox, |
| 08:56:42 | Slasheri | leftright: that should be fixable, i havent used upgraded rockbox on my h140 for quite some time. And i don't know how to do commits to the new git system |
| 08:57:02 | *** | Saving seen data "./dancer.seen" |
| 08:58:07 | leftright | hello Slasheri:, long time no see. thanks for your prompt response. perhaps some other guru can be pointed in the right direction ? |
| 09:00 |
| 09:02:11 | leftright | int var1; {bootfreeze} > {fix pronto} :-) |
| 09:02:20 | Slasheri | hello :) most likely something has changed in the rockbox boot sequence, system initialization, memory layout or something like that. So bootloader still works as it always has worked but changes in the rockbox are incompatible with the old bootloader and the boot process crashes at the second stage when bootloader gives control to the rockbox application |
| 09:06:31 | leftright | thanks for your input. later |
| 09:06:36 | | Part leftright |
| 09:14:49 | | Quit bertrik (Remote host closed the connection) |
| 09:52:14 | | Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) |
| 09:55:56 | wodz | hmm it seems rolo is affected as well on h1xx so this should make testing simpler |
| 09:56:57 | | Quit nosa-j (Ping timeout: 265 seconds) |
| 09:57:15 | | Join nosa-j [0] (~m00k@66.233.224.206) |
| 10:00 |
| 10:04:43 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 10:15:09 | wodz | hmm, my fix to rom.lds is braindead (although it should work) |
| 10:17:47 | | Quit nosa-j (Ping timeout: 260 seconds) |
| 10:20:26 | | Join nosa-j [0] (~m00k@66.233.224.206) |
| 10:30:18 | | Quit nosa-j (Ping timeout: 265 seconds) |
| 10:53:40 | | Part LinusN |
| 10:56:13 | | Quit ParkerR (Ping timeout: 240 seconds) |
| 10:57:04 | *** | Saving seen data "./dancer.seen" |
| 10:57:04 | | Join ParkerR [0] (~ParkerR@unaffiliated/parkerr) |
| 11:00 |
| 11:08:12 | | Quit dfkt (Ping timeout: 252 seconds) |
| 11:20:21 | | Quit mc2739 (Ping timeout: 248 seconds) |
| 11:22:27 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
| 11:46:06 | | Join leftright [0] (c5e015a4@gateway/web/freenode/ip.197.224.21.164) |
| 11:49:58 | | Nick SuperBrainAK is now known as DormantBrain (~andy@2001:470:8:a61::5f92:59a1) |
| 11:53:20 | leftright | hi wodz. I tried the latest build but my h1xx still exhibits the same boot-freeze as before. |
| 11:54:04 | | Join dfkt [0] (OxO29A@unaffiliated/dfkt) |
| 11:54:16 | wodz | leftright: that is expected. Something else is broken. BTW. does rolo() exhibit the same problem for you? |
| 11:54:37 | leftright | RoLo works ok |
| 11:54:50 | wodz | that is super weird then |
| 11:55:36 | wodz | In which way it crashes then? Do you see anything on the screen? |
| 11:55:52 | leftright | to calirfy, Rolo executes every time from within rockbox and after a new version of rockbox |
| 11:56:42 | leftright | it freezes on the boot screen which has rockbox's logo and v number |
| 11:57:08 | wodz | which number? bootloader's number or build number? |
| 11:57:27 | leftright | build number |
| 11:58:18 | wodz | ok and then you hard reset and the very same build boots ok, right? |
| 11:58:24 | leftright | yes |
| 11:58:38 | leftright | boot set to disk |
| 11:58:50 | wodz | right |
| 11:59:58 | wodz | would it be possible for you to bisect and find out which commit introduced this? |
| 12:00 |
| 12:00:34 | leftright | v3.8 works fine. everything after freezes |
| 12:02:03 | wodz | that is a bit too broad for me to conclude anything |
| 12:03:25 | leftright | wodz, sorry but I'm not into zero's and one's, but I'll be glad to give moral support :-) |
| 12:05:06 | wodz | leftright: by bisect I meant http://www.rockbox.org/wiki/UsingGit#How_do_I_bisect_using_git_63 and test the build to pinpoint offending commit |
| 12:06:46 | leftright | *runs for the hills* :-) |
| 12:07:42 | leftright | I'll have a look at the link and see if I can deduce somethiing of value, might take a few days though |
| 12:11:24 | leftright | thanks for having a look at it, much appreciated. Later |
| 12:11:28 | | Part leftright |
| 12:44:25 | chrisjj | Anyone got a simulator to run recently? I get just fails: http://forums.rockbox.org/index.php/topic,47099.0.html |
| 12:57:08 | *** | Saving seen data "./dancer.seen" |
| 13:00 |
| 13:01:18 | | Quit alucryd (Quit: Alucryd out.) |
| 13:08:36 | | Join alucryd [0] (~alucryd@archlinux/trusteduser/alucryd) |
| 13:09:36 | | Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) |
| 13:19:24 | | Quit ikeboy (Quit: ikeboy) |
| 13:55:48 | | Quit Scall (Ping timeout: 252 seconds) |
| 14:00 |
| 14:04:19 | | Join Scall [0] (~chat@unaffiliated/scall) |
| 14:16:32 | | Join ibhan [0] (~yaaic@94.191.189.75.bredband.3.dk) |
| 14:31:00 | | Part ibhan |
| 14:47:54 | | Join amayer [0] (~amayer@mail.weberadvertising.com) |
| 14:57:10 | *** | Saving seen data "./dancer.seen" |
| 15:00 |
| 15:00:05 | | Join [Saint_] [0] (~saint@rockbox/staff/saint) |
| 15:00:55 | | Quit [Saint] (Ping timeout: 252 seconds) |
| 15:16:23 | | Quit wodz (Quit: Leaving) |
| 15:32:56 | | Join [Saint] [0] (~saint@rockbox/staff/saint) |
| 15:34:16 | | Quit [Saint_] (Ping timeout: 272 seconds) |
| 15:37:20 | | Quit Strife89 (Ping timeout: 272 seconds) |
| 16:00 |
| 16:13:40 | | Quit mortalis (Ping timeout: 248 seconds) |
| 16:16:26 | | Join Rower [0] (husvagn@90-230-142-55-no41.tbcn.telia.com) |
| 16:20:02 | | Join ikeboy [0] (~ikeboy@ool-435622d3.dyn.optonline.net) |
| 16:37:11 | | Join fragilematter1 [0] (~fragilema@193.226.142.214) |
| 16:39:31 | | Quit fragilematter (Ping timeout: 260 seconds) |
| 16:39:52 | ikeboy | does rockbox have any Easter eggs? |
| 16:45:31 | | Join Strife89 [0] (~Strife89@2602:306:250d:18b9:29c7:db30:247e:f805) |
| 16:46:58 | dfkt | i found the "rockbox ata error -2" easter egg once :p |
| 16:57:14 | *** | Saving seen data "./dancer.seen" |
| 17:00 |
| 17:00:12 | | Quit fragilematter1 (Quit: Leaving.) |
| 17:00:40 | | Quit Zagor (Quit: Clint excited) |
| 17:01:14 | | Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 17:10:06 | toehser | Ref FS12942 in skin_backdrops.c in skin_backdrop_unload - working case comes in with ref_count−− going from 1 to 0 and unloads, failing case old theme comes in with ref_count−− going from 2 to 1 and doesn't unload. At that point, I'm confused. What are the multiple contexts that need references to backdrops, what are the places incrementing, what is the intention when a new theme loads - I'm guessing that point A and point B of the old theme used the b |
| 17:10:57 | | Quit Raptors (Read error: Connection reset by peer) |
| 17:11:49 | | Join Raptors [0] (~whoneedsa@198-200-68-213.cpe.distributel.net) |
| 17:40:56 | | Quit Strife89 (Ping timeout: 272 seconds) |
| 17:44:01 | | Quit Raptors (Read error: Connection reset by peer) |
| 17:44:24 | | Join Raptors [0] (~whoneedsa@198-200-68-213.cpe.distributel.net) |
| 17:44:28 | ikeboy | I'm having a theme bug with 91ef65306bf4e459f430d6dc44e5923d6b9f8399 |
| 17:53:36 | | Quit petur (Quit: *plop*) |
| 17:54:44 | | Join kostyat [0] (~kostyat@91.210.101.68) |
| 17:56:06 | copper | ikeboy: there have been some important theme fixes since that revision |
| 17:56:19 | copper | you should get HEAD |
| 17:57:14 | copper | those fixes mean that some themes are no longer compatible with HEAD |
| 17:57:28 | copper | I had to update my own themes, but now they work a lot better |
| 17:58:56 | | Join Strife89 [0] (~Strife89@2602:306:250d:18b9:114:708:b733:508) |
| 17:59:06 | copper | in other words, it's worth it |
| 18:00 |
| 18:02:29 | ikeboy | The bug is still on HEAD for me |
| 18:02:47 | copper | can you post a screenshot from the sim? |
| 18:02:49 | ikeboy | and I didn't make these themes, I'd have no idea what to do |
| 18:02:55 | copper | also, which theme / target? |
| 18:03:50 | ikeboy | Hang on, I'll try to get a sim screenshot. Fuze+, Googley-FuzePlus-Blue |
| 18:03:57 | copper | that's mine |
| 18:04:54 | copper | ikeboy: to take a screenshot in the sim, press 0 on the keypad |
| 18:05:01 | copper | and your keyboard keypad |
| 18:05:14 | copper | also, did you get the latest version of the theme? |
| 18:05:30 | ikeboy | no to latest version |
| 18:05:46 | ikeboy | is HEAD b3abcb8? |
| 18:06:09 | copper | yes |
| 18:06:30 | copper | the updated theme is available here: http://themes.rockbox.org/index.php?themeid=2029&target=sansafuzeplus |
| 18:07:21 | copper | let me know if you still have issues with the updated theme |
| 18:08:01 | | Join y4n [0] (~y4n@unaffiliated/y4ndexx) |
| 18:08:42 | | Quit kostyat (Ping timeout: 260 seconds) |
| 18:14:08 | amayer | copper: I was just going to mention your theme was broken on head... the fonts didnt show up under wps. but your most recent version fixes it |
| 18:14:16 | amayer | you get a 5 star from me |
| 18:14:29 | copper | :) |
| 18:14:46 | copper | I updated the themes as kugel was fixing a gazillion bugs |
| 18:15:20 | amayer | when I get time I should go back and check my themes... one more thing on my loooong list of things to do |
| 18:15:45 | copper | the previous version of my themes had fragile workarounds for the theme bugs that kugel fixed |
| 18:15:55 | copper | now both Rockbox and my themes are fixed |
| 18:16:26 | copper | but there's a chance that other themes need to be fixed too |
| 18:16:51 | amayer | I checked epilogue and it seems to be working. I would have to say that is the most popular of my themes. |
| 18:19:36 | | Join pretty_function [0] (~sigBART@123.252.214.18) |
| 18:21:43 | ikeboy | The new theme works. Thank you! |
| 18:22:49 | copper | great! |
| 18:22:49 | | Join bertrik [0] (~quassel@ip117-49-211-87.adsl2.static.versatel.nl) |
| 18:22:49 | | Quit bertrik (Changing host) |
| 18:22:49 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
| 18:25:06 | amayer | copper: your theme has survived on my iPod longer then any other theme, even my own. |
| 18:25:18 | amayer | all tho I do modify your theme slightly |
| 18:25:47 | amayer | I make the title of the menus blue and eliminate the icon beside the title |
| 18:29:01 | ikeboy | I use the Googley theme with create.bmp background and elisherer iconset |
| 18:30:03 | amayer | does anyone else get a half a second hiss when pausing and resuming ogg files? |
| 18:32:16 | amayer | I dont get it when playing mp3s. Ive tried it with multiple ogg files and multiple mp3s. |
| 18:57:18 | *** | Saving seen data "./dancer.seen" |
| 19:00 |
| 19:00:10 | | Join Icedman [0] (~Icey@unaffiliated/icedman) |
| 19:00:11 | Icedman | hi |
| 19:00:55 | Icedman | I just installed rockbox on my sansa clip zip and since then the sansa won't get mounted as an usb device on linux. windows and mac |
| 19:01:08 | Icedman | :( |
| 19:01:32 | bertrik | does it boot to either the original firmware or rockbox at all? |
| 19:01:41 | Icedman | I can mount it on linux via the mount command (but that's ugly with root and everything) |
| 19:01:50 | Icedman | it boots to both perfectly fine |
| 19:01:56 | | Join n1s [0] (~n1s@nl118-168-30.student.uu.se) |
| 19:01:56 | | Quit n1s (Changing host) |
| 19:01:56 | | Join n1s [0] (~n1s@rockbox/developer/n1s) |
| 19:02:32 | bertrik | did you try a release build or a development build? |
| 19:02:43 | Icedman | the 3.13 stable build |
| 19:02:59 | Icedman | via the rbutil installer |
| 19:03:34 | bertrik | A lot of fixes were done recently, which may have improved USB behaviour |
| 19:04:09 | bertrik | I recommend booting to the original firmware, then updating to a recent build. AFAIK RockboxUtility can install those too |
| 19:05:27 | Icedman | k |
| 19:05:41 | Icedman | the original firmware is not being automatically mounted either |
| 19:05:47 | Icedman | so I will do that via root then |
| 19:06:20 | copper | <Icedman> I can mount it on linux via the mount command (but that's ugly with root and everything) |
| 19:06:27 | copper | that doesn't sound like a problem |
| 19:06:40 | copper | if it mounts fine with "mount", then it's fine |
| 19:06:48 | Icedman | :/ |
| 19:06:55 | copper | you're just having some configuration problem on your PC |
| 19:07:04 | Icedman | err no? |
| 19:07:16 | Icedman | my mac and windows PC do not even recognize it |
| 19:07:44 | Icedman | which they did before |
| 19:07:50 | Icedman | the update to rockbox |
| 19:08:03 | copper | can you mount it on your Linux PC, and then pastebin the output of "/usr/bin/mount" on its own? |
| 19:08:39 | dfkt | Icedman, i found that my clip+ mouints 'magically' every time on windows when i attach it to the usb cable while it's playing |
| 19:08:59 | dfkt | it rarely ever mounts while the player is off, or playback in rockbox is stopped |
| 19:09:23 | Icedman | copper, like mount/dev/blub > blat.txt? |
| 19:09:28 | copper | no |
| 19:09:30 | copper | just "mount" |
| 19:09:34 | copper | without any arguments |
| 19:09:37 | Icedman | k |
| 19:10:04 | copper | copy paste the output on pastebin.com and link to your pastebin here |
| 19:12:06 | Icedman | https://paste.xinu.at/CtW/ |
| 19:12:39 | Icedman | dfkt, interestin O_o |
| 19:13:41 | copper | Icedman: can you also pastebin the contents of your /etc/fstab? |
| 19:13:59 | copper | I have this in there: UUID=0123-4567 /media/clip vfat defaults,noatime,user,noauto,iocharset=utf8 0 0 |
| 19:14:11 | copper | which allows normal users (non root) to mount my Clip+ |
| 19:14:25 | copper | the ",user," part |
| 19:14:59 | copper | UUID= identifies my clip+, as listed in /dev/disk/by-uuid/ |
| 19:15:31 | Icedman | https://paste.xinu.at/gIWDK/ |
| 19:15:34 | Icedman | my fstab |
| 19:16:30 | copper | hmm |
| 19:16:44 | copper | well, I never use automount, and I don't know what your distro is doing for automount |
| 19:16:56 | copper | but I don't see anything wrong |
| 19:17:07 | Icedman | ._. well I use archlinux with systemd |
| 19:17:15 | copper | uh, me too |
| 19:17:21 | Icedman | uh |
| 19:17:24 | Icedman | x'D |
| 19:17:34 | Karrde | X"d |
| 19:17:38 | copper | I do use automount for one thing actually |
| 19:17:53 | copper | but I have an fstab entry for it, with the "x-systemd.automount" parameter |
| 19:18:28 | | Nick DormantBrain is now known as SuperBrainAK (~andy@2001:470:8:a61::5f92:59a1) |
| 19:18:31 | Icedman | hm |
| 19:18:44 | Icedman | I use udiskie |
| 19:19:53 | copper | what's the name of your Clip device? |
| 19:19:58 | copper | as listed in /dev/disk/by-label/ |
| 19:21:05 | Icedman | SANSA\\x20CLIPZ@ |
| 19:21:26 | copper | do you know if that's the same name as before you installed Rockbox? |
| 19:21:58 | Icedman | Yes, before it got mounted automatically to /media/Sansa\ CLIPZ/ |
| 19:22:06 | Icedman | err |
| 19:22:09 | Icedman | SANSA CLIPZ |
| 19:23:14 | copper | can you post the relevant portion of "dmesg" that includes the part when you connect the Clip Zip via USB? |
| 19:23:33 | Icedman | aye |
| 19:25:17 | copper | better yet, just pastebin the entire output |
| 19:28:20 | Icedman | x'D |
| 19:29:24 | Icedman | https://paste.xinu.at/Du4Yb/ <−− most recent reconnect. Full dmesg https://paste.xinu.at/4xP/ |
| 19:33:18 | copper | clearly you've been having USB problems |
| 19:33:27 | Icedman | O_O |
| 19:33:32 | Icedman | ;_; |
| 19:33:33 | copper | maybe udiskie crapped out because of it |
| 19:33:56 | copper | "usb 1-6: reset high-speed USB device number 32 using ehci-pci" |
| 19:34:00 | copper | "sd 26:0:0:1: Device offlined - not ready after error recovery" |
| 19:34:04 | copper | "end_request: I/O error, dev sdd, sector 4096" |
| 19:34:06 | Icedman | >_> |
| 19:34:11 | copper | etc etc |
| 19:34:34 | Icedman | reminds me |
| 19:35:48 | copper | you can try booting the original firmware by pressing and holding "Left" while turning it on |
| 19:35:51 | copper | http://download.rockbox.org/daily/manual/rockbox-sansaclipzip/rockbox-buildch3.html#x5-280003.1.3 |
| 19:36:05 | Icedman | after installing and connecting it again I had this: https://paste.xinu.at/Ujj/ |
| 19:36:17 | copper | that's rockbox crashing |
| 19:36:24 | copper | USB problems again |
| 19:36:29 | Icedman | ._. |
| 19:36:38 | copper | the Clip Zip port is known to have such problems |
| 19:36:43 | Icedman | ouch |
| 19:36:53 | copper | other targets have similar problems too |
| 19:37:10 | Icedman | bertrik mentioned the dev build |
| 19:37:21 | Icedman | guess it won't hurt to try |
| 19:37:30 | copper | http://build.rockbox.org/data/rockbox-sansaclipzip.zip |
| 19:37:48 | bertrik | yeah, I suspect the most recent development build is actually more stable than 3.13 |
| 19:38:08 | bertrik | because of all the recent memory fixes, which may also have improved USB |
| 19:38:30 | Icedman | hm I will try then |
| 19:39:32 | copper | eh |
| 19:39:43 | copper | I wonder how many USB crashes are actually USB bugs |
| 19:43:53 | Icedman | x'D |
| 19:43:57 | Icedman | didn't do shit |
| 19:44:02 | Icedman | meh x'D |
| 19:54:02 | | Quit saratoga (Quit: Page closed) |
| 19:57:08 | bertrik | I plan to actually work on trying interrupts for fm tuners soonish |
| 19:57:33 | bertrik | I hope it will speedup tuning a bit, especially autotune |
| 19:57:53 | bertrik | actually looks easy to implement so far :) |
| 20:00 |
| 20:00:27 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 20:08:36 | | Quit pretty_function (Remote host closed the connection) |
| 20:12:56 | | Join cordyceps [0] (~cordyceps@207.216.194.194) |
| 20:14:06 | | Quit Icedman (Remote host closed the connection) |
| 20:16:46 | | Quit Rower (Ping timeout: 252 seconds) |
| 20:17:32 | | Join Rower [0] (husvagn@90-230-142-55-no41.tbcn.telia.com) |
| 20:19:46 | pamaury | BobJonkman1: here ? |
| 20:23:11 | | Join krabador [0] (~krabador@87.18.225.146) |
| 20:23:24 | | Quit krabador (Changing host) |
| 20:23:24 | | Join krabador [0] (~krabador@unaffiliated/krabador) |
| 20:38:53 | | Quit Raptors (Quit: Leaving) |
| 20:50:06 | | Join Raptors [0] (~whoneedsa@216-58-33-234.cpe.distributel.net) |
| 20:53:08 | | Join faustlod [0] (~faustlod@193.105.154.74) |
| 20:56:43 | | Join einhirn [0] (~Miranda@p4FC74FE0.dip0.t-ipconnect.de) |
| 20:57:19 | *** | Saving seen data "./dancer.seen" |
| 20:59:59 | | Quit GodEater (Quit: Coyote finally caught me) |
| 21:00 |
| 21:01:21 | | Join GodEater [0] (~whoknows@cl-711.lon-02.gb.sixxs.net) |
| 21:01:22 | | Quit GodEater (Changing host) |
| 21:01:22 | | Join GodEater [0] (~whoknows@rockbox/staff/GodEater) |
| 21:03:44 | | Join panach [0] (~panach@91.210.101.56) |
| 21:07:32 | | Quit [Saint] (Remote host closed the connection) |
| 21:09:38 | | Join [Saint] [0] (~saint@rockbox/staff/saint) |
| 21:13:26 | | Join Icedman [0] (~Icey@unaffiliated/icedman) |
| 21:13:31 | Icedman | copper, bertrik |
| 21:13:34 | Icedman | you know what |
| 21:13:57 | Icedman | Golden Rule of IT Stuff No.1 Reinstalling fixes shit, yo! |
| 21:13:58 | | Quit ikeboy (Ping timeout: 252 seconds) |
| 21:15:02 | | Quit panach (Ping timeout: 252 seconds) |
| 21:18:49 | | Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 21:19:45 | BobJonkman1 | pamaury: Hi: I'm back now |
| 21:21:44 | | Quit y4n (Quit: HOLY SHIT! WE'RE ALL JUST LIVING ON A GINORMOUS FUCKING SPINNING ROCK FLOATING THROUGH SPACE CIRCLING A BIG FUCKING BALL OF FIRE!!!) |
| 21:45:13 | n1s | hmm, trying to profile the opus codec just gives me lovely undefined instr panics... |
| 21:45:31 | pamaury | BobJonkman1: we can try something else to recover your Fuze+. Download https://www.dropbox.com/s/x65ogs4jgta211p/hwstub.sb |
| 21:45:49 | BobJonkman1 | pamaury: OK, downloading now |
| 21:46:40 | pamaury | BobJonkman1: hum, wait I will update another file to make it easier for you |
| 21:46:52 | BobJonkman1 | pamaury: :) OK |
| 21:56:26 | | Join aevin [0] (eivindsy@unaffiliated/aevin) |
| 21:58:48 | | Quit Icedman (Quit: Everyone quits one day. You just wasted 3 seconds reading this.) |
| 22:00 |
| 22:02:22 | pamaury | BobJonkman1: I have a prototype, let me try it on mine first |
| 22:02:36 | BobJonkman1 | pamaury: OK, thanx! |
| 22:11:20 | | Quit Mir (Remote host closed the connection) |
| 22:15:28 | BobJonkman1 | pamaury: I need to go AFK for about a while. Probably be back in an hour or two |
| 22:15:48 | | Quit Strife89 (Ping timeout: 272 seconds) |
| 22:20:52 | | Quit Rower (Quit: Hmmm...) |
| 22:22:41 | [Saint] | [05:57:15] <copper> those fixes mean that some themes are no longer compatible with HEAD <−−- no recent changes have changed the syntax at all |
| 22:22:59 | [Saint] | It was only in your case where you had specifically worked around an issue. |
| 22:25:19 | | Quit cordyceps (Quit: leaving) |
| 22:30:10 | | Join Mir [0] (~Mir@pool-71-109-219-225.lsanca.dsl-w.verizon.net) |
| 22:36:27 | copper | issues* (plural) |
| 22:37:00 | copper | there were so many random bugs (or effects of one or two bugs), there's no telling what will still work and what won't |
| 22:37:43 | copper | and maybe I'm more present and more vocal here than other theme authors |
| 22:37:43 | | Quit bluebrother (Read error: Operation timed out) |
| 22:38:26 | copper | I have reported several bugs here but also on flyspray, that no-one else reported before |
| 22:38:37 | [Saint] | The recent fixes would only break a theme that was broken to begin with. |
| 22:38:39 | copper | but that just means I took the time that others may not have |
| 22:38:57 | [Saint] | ie. yours. |
| 22:39:05 | copper | ... |
| 22:39:18 | copper | and why do you think they were "broken"? |
| 22:39:27 | [Saint] | They should never have parsed. |
| 22:39:53 | copper | I did it right while I was making my themes |
| 22:40:03 | copper | but that caused Rockbox bugs to occur |
| 22:40:18 | | Quit fs-bluebot (Ping timeout: 260 seconds) |
| 22:40:20 | copper | my themes weren't initially "broken": Rockbox was |
| 22:40:38 | copper | who's to say I was the first and only theme maker to resort to such hacks? |
| 22:41:27 | copper | I ran into so many problems, I would be very surprised if I was the only one |
| 22:41:29 | [Saint] | Who is saying that? All I'm saying is that the recent changes would only cause an issue if the theme has issues to begin with. |
| 22:41:45 | copper | that's a backwards way of looking at it |
| 22:41:46 | | Join fs-bluebot [0] (~fs-bluebo@g231123242.adsl.alicedsl.de) |
| 22:41:57 | | Join bluebrother [0] (~dom@rockbox/developer/bluebrother) |
| 22:42:02 | [Saint] | Working around theme bugs with illegal syntax is also backwards. |
| 22:42:17 | copper | what, should I have given up? |
| 22:42:24 | copper | should I not have published my themes? |
| 22:42:59 | copper | I took the more productive approach: I reported the bugs, properly, officially, and I worked around it while there was no fix. |
| 22:43:15 | [Saint] | I'm not saying that at all. But you should be avoiding blanket statements like the one you made, stating that HEAD will break theme compatibility. |
| 22:43:27 | [Saint] | Because it won't. |
| 22:43:29 | copper | I said it was a possibility |
| 22:43:46 | copper | 17:16:27 UTC <copper> but there's a chance that other themes need to be fixed too |
| 22:44:12 | copper | that's quite a caucious statement, I think |
| 22:44:19 | copper | cautious |
| 22:45:00 | copper | certainly not a blanket statement |
| 22:45:00 | [Saint] | Its a misleading statement, I think. But, whatever. |
| 22:45:26 | [Saint] | Its not making it clear that the issues would be caused by the authors workarounds. |
| 22:45:45 | [Saint] | (which shouldn;t have worked in the first place) |
| 22:45:55 | copper | 17:15:46 UTC <copper> the previous version of my themes had fragile workarounds for the theme bugs that kugel fixed |
| 22:45:58 | copper | 17:15:56 UTC <copper> now both Rockbox and my themes are fixed |
| 22:46:01 | copper | 17:16:27 UTC <copper> but there's a chance that other themes need to be fixed too |
| 22:46:05 | copper | I think I stated that fact very clearly |
| 22:46:23 | copper | it's written… right. There. |
| 22:49:29 | [Saint] | I apologize, that section isn't present in my logs at all. |
| 22:49:30 | [Saint] | Odd. |
| 22:49:52 | copper | Ok. |
| 22:49:54 | gevaerts | [Saint]: fix your logs! |
| 22:50:01 | gevaerts | That seems to happen at least twice a year! |
| 22:50:47 | copper | that's happened to me once before I think |
| 22:50:54 | [Saint] | It does indeed. And I have seen it reported a few times by other quassel users, but it is hard to pinpoint. And very hard to notice. |
| 22:50:56 | copper | someone missing what I said from the logs, too |
| 22:51:10 | copper | in #rockbox |
| 22:51:16 | copper | can't remember who it was |
| 22:51:19 | [Saint] | Well...it just made me look like a giant dick. |
| 22:51:30 | [Saint] | Gah. |
| 22:51:30 | copper | just a misunderstanding, that's ok |
| 22:52:18 | copper | http://www.rockbox.org/irc/log-20140120 |
| 22:52:52 | copper | in case you're missing other parts of the initial conversation |
| 22:53:11 | | Quit faustlod (K-Lined) |
| 22:53:25 | [Saint] | Man. That's really weird. |
| 22:53:36 | [Saint] | All I have from you around that time is the one line I quoted. |
| 22:55:55 | copper | still |
| 22:56:15 | copper | nm |
| 22:56:32 | | Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) |
| 22:57:20 | *** | Saving seen data "./dancer.seen" |
| 23:00 |
| 23:01:31 | | Quit n1s (Quit: Ex-Chat) |
| 23:01:54 | | Join stripwax [0] (~Miranda@rockbox/developer/stripwax) |
| 23:24:04 | | Quit stripwax (Read error: Connection reset by peer) |
| 23:25:09 | | Quit amayer (Quit: Leaving) |
| 23:36:44 | BobJonkman1 | pamaury: Back again. For at least an hour... |
| 23:54:02 | | Quit pamaury (Quit: this->disconnect()) |
| 23:54:21 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 23:54:57 | pamaury | BobJonkman1: download this: https://www.dropbox.com/s/bwq3w8tmehu5vss/charge-fuzeplus.sb |
| 23:58:12 | | Quit dunpeal (Quit: leaving) |
icon identifies that the person is a core developer (has commit access).