| 00:01:02 | | Join Guest11127 [0] (~Slayer@c-69-143-178-62.hsd1.va.comcast.net) |
| 00:18:35 | *** | Saving seen data "./dancer.seen" |
| 00:18:48 | | Quit Rower (Quit: soer) |
| 00:19:52 | | Quit olspookishmagus (Quit: All for nothing) |
| 00:27:22 | | Quit pamaury (Ping timeout: 240 seconds) |
| 00:35:18 | | Nick SuperBrainAK is now known as DormantBrain (~andy@shared02.balt01.cd.2g2u.net) |
| 00:52:13 | | Quit liar (Ping timeout: 240 seconds) |
| 01:00 |
| 01:07:43 | | Quit theunleet (Quit: CGI:IRC) |
| 01:14:20 | | Join syscrash [0] (~syscrash@poipu/developer/syscrash) |
| 01:15:23 | | Quit jlbiasini (Remote host closed the connection) |
| 01:31:31 | | Quit mirak (Quit: Ex-Chat) |
| 01:42:32 | | Join mirak [0] (~mirak@static-176-182-46-92.ncc.abo.bbox.fr) |
| 02:00 |
| 02:09:22 | | Quit bertrik (Ping timeout: 240 seconds) |
| 02:18:39 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:15:35 | | Quit ender` (Quit: It's not worth doing something unless someone, somewhere, would much rather you weren't doing it. -- Terry Pratchett) |
| 03:40:56 | | Join Beta2K [0] (~Beta2K@d24-36-136-246.home1.cgocable.net) |
| 03:43:50 | | Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 23.0/20130722172257]) |
| 03:59:53 | | Join mrtux_ [0] (~colin@75-167-98-77.desm.qwest.net) |
| 04:00 |
| 04:01:59 | | Quit mrtux (Ping timeout: 264 seconds) |
| 04:01:59 | | Nick mrtux_ is now known as mrtux (~colin@75-167-98-77.desm.qwest.net) |
| 04:18:42 | *** | Saving seen data "./dancer.seen" |
| 04:29:46 | | Quit amiconn (Disconnected by services) |
| 04:29:48 | | Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) |
| 04:29:52 | | Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) |
| 04:30:41 | | Quit pixelma (Disconnected by services) |
| 04:30:42 | | Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) |
| 04:30:44 | | Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) |
| 04:41:33 | | Quit mrtux (Quit: ZNC - http://znc.in) |
| 04:42:16 | | Join mrtux [0] (~colin@2001:388:f000::26cd) |
| 04:43:14 | | Quit mrtux (Changing host) |
| 04:43:14 | | Join mrtux [0] (~colin@unaffiliated/mrtux) |
| 04:48:34 | | Join Strife89 [0] (~Strife89@adsl-98-80-231-240.mcn.bellsouth.net) |
| 05:00 |
| 05:13:29 | | Join shamus [0] (~shmaus@ip-206-192-195-49.marylandheights.ip.cablemo.net) |
| 05:46:37 | | Quit [7] (Disconnected by services) |
| 05:46:50 | | Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) |
| 06:00 |
| 06:18:44 | *** | Saving seen data "./dancer.seen" |
| 07:00 |
| 07:06:37 | | Quit CaptainKewl (Read error: Connection reset by peer) |
| 07:09:36 | | Join kevku [0] (~kevku@2001:0:c38c:c38c:3c54:79ba:3d69:bedb) |
| 08:00 |
| 08:03:25 | * | [Saint] notes that the sample rate selector is basically unusable. |
| 08:05:02 | [Saint] | I assume there isn't *supposed* to be an audible difference here? |
| 08:07:13 | [Saint] | ...that magically fixes itself. |
| 08:07:16 | [Saint] | Hummm. |
| 08:10:35 | | Quit Strife89 (Ping timeout: 256 seconds) |
| 08:18:48 | *** | Saving seen data "./dancer.seen" |
| 08:20:56 | | Join Rower [0] (husvagn@v-413-alfarv-177.bitnet.nu) |
| 08:27:45 | | Nick syscrash is now known as jvd (~syscrash@poipu/developer/syscrash) |
| 09:00 |
| 09:36:43 | | Quit bluebrother (Disconnected by services) |
| 09:36:48 | | Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) |
| 09:58:57 | | Quit shamus (Read error: Connection reset by peer) |
| 10:00 |
| 10:00:02 | | Join shamus [0] (~shmaus@ip-206-192-195-49.marylandheights.ip.cablemo.net) |
| 10:15:01 | | Join bertrik [0] (~quassel@rockbox/developer/bertrik) |
| 10:18:51 | *** | Saving seen data "./dancer.seen" |
| 10:36:39 | | Quit rdn (Remote host closed the connection) |
| 10:41:00 | copper | saratoga: well shit, the log is empty |
| 10:42:38 | copper | and the battery is full |
| 10:42:50 | copper | I saw it running though |
| 10:42:53 | copper | dunno what happened |
| 10:43:18 | [Saint] | I have seen this happen before now. |
| 10:43:30 | [Saint] | It also REALLY chokes on the insane APE. |
| 10:43:47 | [Saint] | if you listen to it, its just nasty schreeching and noise. |
| 10:43:52 | copper | I removed all ape above c1000, lets see if that fixes it |
| 10:48:45 | copper | [Saint]: test_codec decodes as fast as possible, right? |
| 10:49:06 | [Saint] | there's no way to do otherwise. |
| 10:49:19 | [Saint] | so "yes". |
| 10:50:34 | [Saint] | what is the ultimate question behind that one? |
| 10:50:55 | copper | I was wondering if instead, it would decode at real time, and measure the CPU frequency or something |
| 10:51:02 | copper | in real time* |
| 10:51:39 | [Saint] | No. There's no need. As it is trivial to ascertain realtime requirements from the decoding speed. |
| 10:52:06 | [Saint] | that would just be a slower, less efficient way of doing what it already does. |
| 10:52:12 | copper | last night when I launched it, it put the Fuze+ face down, maybe the abord key was triggered, or something |
| 10:52:22 | copper | abort |
| 10:52:48 | [Saint] | If so, there should still be logs for everything it completed. |
| 10:53:05 | [Saint] | unless it cancelled before a single test finished. |
| 10:53:07 | copper | dunno what happened then |
| 10:53:29 | copper | right now it's running, and the display is turning on every time it tests a new file, I think |
| 10:58:30 | copper | meh |
| 10:58:36 | copper | no opus files in the test corpus |
| 11:00 |
| 11:13:54 | | Join jlbiasini [0] (~metaphysi@89.136.132.239) |
| 11:16:23 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 11:18:08 | copper | saratoga: http://pastebin.com/4knGqLKU |
| 11:18:19 | | Quit JdGordon (Ping timeout: 246 seconds) |
| 11:23:52 | [Saint] | fuck me that's a beast... |
| 11:24:08 | [Saint] | that thing is foolishly overpowered. |
| 11:26:20 | copper | ah? |
| 11:28:26 | copper | oy |
| 11:28:32 | copper | MPC is nearly twice as fast as Vorbis |
| 11:32:50 | copper | Opus 128kbps: 171.61% real time :-/ |
| 11:33:15 | [Saint] | 101% is essentially irrelevant. |
| 11:33:30 | [Saint] | everything higher than 100% is just a bonus :) |
| 11:36:27 | copper | doesn't it mean lower battery life? |
| 11:36:32 | | Join JdGordon [0] (~jonno@CPE-121-217-135-158.lnse2.cht.bigpond.net.au) |
| 11:36:32 | | Quit JdGordon (Changing host) |
| 11:36:32 | | Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) |
| 11:36:52 | [Saint] | It does, sure. But I happen to think that anything past 8H is irrelevant. |
| 11:37:02 | copper | 8 hours? |
| 11:37:12 | copper | because you charge your DAP every night? |
| 11:37:25 | [Saint] | Does anyone really *need* 50H+ for a DAP when we can chare basically anywhere these days? :) |
| 11:37:35 | copper | chare? |
| 11:37:39 | copper | ah |
| 11:37:41 | [Saint] | *charge |
| 11:37:51 | copper | too much stuff to charge |
| 11:38:07 | copper | I appreciate the fact that I only need to charge my DAP like once a week |
| 11:38:13 | pamaury | This charging every day habit is killing me |
| 11:38:45 | copper | [Saint]: also, fewer battery cycles |
| 11:39:01 | [Saint] | I just make sure there's a charger at home, one at work, and one in the car. |
| 11:39:13 | pamaury | I appreciate that my daps have longer battery life so that I don't have to bring a charger for example |
| 11:39:17 | [Saint] | Haven't had a low battery inyears. |
| 11:40:06 | pamaury | And when you phone will last 1 hour on battery will you say "that's ok I have a charger in my pocket" ? ;) |
| 11:40:53 | [Saint] | The hilarious thing about that example is that I have been known to charge my DAP from my phone on occasions. :) |
| 11:41:13 | [Saint] | And both from my laptop. |
| 11:42:11 | [Saint] | Fwiw, I'm not saying that battery life isn't a good thing. I'm just saying that there's no real need to eek out every last cycle for performances sake, really. |
| 11:42:25 | [Saint] | There's a point where performance is "Good Enough (TM)" |
| 11:42:57 | | Quit JdGordon (Ping timeout: 276 seconds) |
| 11:43:31 | pamaury | So one day on battery for your mostly idle phone is good enough ? |
| 11:43:54 | [Saint] | How do you come to that conclusion? |
| 11:44:12 | [Saint] | I use my phone a LOT, and it does over a full day - so...yes. |
| 11:44:20 | | Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) |
| 11:45:09 | [Saint] | As long as it lasts me a "working day", I couldn't care less. |
| 11:45:18 | copper | [Saint]: double the performance is quite significant IMO |
| 11:45:28 | [Saint] | Perhaps I'm a minority. But I see no need for many days worth of battery for devices we use daily. |
| 11:46:02 | [Saint] | More to the point, for devices we use for a few hours at a time. |
| 11:46:37 | [Saint] | A few years ago, possibly this bothered me...now, charging is so absurdly easy, pretty much anywhere, I couldn;t care. |
| 11:46:50 | copper | [Saint]: more charging = less battery life over months or years |
| 11:47:05 | bertrik | this doesn't seem right: http://en.wikipedia.org/wiki/Opus_%28audio_format%29#Hardware_support |
| 11:47:29 | copper | bertrik: the "hardware" qualification? |
| 11:47:32 | bertrik | yes |
| 11:47:40 | [Saint] | copper: realistically, honestly, how many batteries have you killed or lessened the lifespan of in a NOTICEABLE fashion? |
| 11:47:42 | copper | obviously they mean DAP support |
| 11:48:01 | copper | [Saint]: all of my really old gear |
| 11:48:19 | [Saint] | If you value said gear. Replace the battery. |
| 11:48:21 | copper | especially phones |
| 11:48:26 | [Saint] | You'd need to do so eventually anyway. |
| 11:48:34 | copper | yes but the later the better |
| 11:48:35 | copper | :) |
| 11:48:57 | [Saint] | I don't really buy into the "more charging == less lifespan" shit, even if it is true. You'd need to be really anal to notice this. |
| 11:49:22 | copper | then let's just say that better performance doesn't hurt? :) |
| 11:49:40 | [Saint] | No, I never said it did hurt. I just said it wan't necessarily relevant :) |
| 11:50:07 | [Saint] | There is a very clear "Good Enough" line. |
| 11:50:24 | copper | running test_codec on opus again, this time with the sampling frequency set to 48kHz |
| 11:50:49 | copper | what did you say about that option earlier? |
| 11:51:12 | [Saint] | I switched to 48K and everything sounded *reaaaaaaaallly* nasty. |
| 11:51:14 | copper | 06:03:26 UTC * [Saint] notes that the sample rate selector is basically unusable. |
| 11:51:19 | [Saint] | Rebooted, and it magically fixed itself. |
| 11:51:23 | copper | hmm |
| 11:52:15 | copper | bertrik: I think that in that context, "hardware support" usually means anything that doesn't run on a computer |
| 11:52:39 | copper | DAPs, hi-fi units, car stereos, etc… |
| 11:53:07 | copper | though, I'm not sure how smartphones and tablets should be qualified |
| 11:53:14 | copper | those are basically computers |
| 11:53:17 | | Quit dv_ (Read error: Operation timed out) |
| 11:54:16 | copper | I guess the distinction is whether the hardware platform has a software platform that allows people to write software for it |
| 11:54:28 | | Join dv_ [0] (~quassel@chello080108009040.14.11.vie.surfer.at) |
| 11:54:54 | copper | explicitely |
| 11:54:57 | bertrik | copper: hm, yes, maybe if you twist the meaning of "hardware" enough, you could call it hardware support |
| 11:55:14 | copper | that's what people mean by it anyway |
| 11:55:24 | copper | it's a shortcut |
| 11:55:56 | copper | and that's how people understand it |
| 11:56:22 | copper | is there any hardware left with actual hardware support for codecs? |
| 11:56:36 | copper | does anyone optimize MP3 playback using a specialized chip anymore? |
| 11:56:48 | | Quit JdGordon (Read error: Connection reset by peer) |
| 11:56:54 | [Saint] | outside of here? |
| 11:56:57 | [Saint] | I doubt it. |
| 11:57:00 | copper | even in here |
| 11:57:10 | bertrik | I think you still have these gumstick type of very cheap mp3/wma players with some kind of hw accelleration |
| 11:57:14 | [Saint] | In here - likely not for many many moons. |
| 11:58:33 | bertrik | the gumstick types are too limited to run rockbox |
| 12:00 |
| 12:00:17 | | Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) |
| 12:05:39 | copper | the difference in performance between FLAC and everything else is huge |
| 12:06:19 | [Saint] | 0.01MHz realtime :) |
| 12:08:28 | copper | ok, sampling freq makes no difference in performance for Opus |
| 12:08:35 | copper | which was to be expected |
| 12:09:03 | bertrik | some nasty re-resampling may be going on for opus though |
| 12:09:27 | | Join DuperMan [0] (~Duper@46-116-90-92.bb.netvision.net.il) |
| 12:09:55 | bertrik | opus is 48 kHz natively, so it might be that it went from 44.1 kHz source to 48 kHz opus to 44.1 kHz rockbox native to 48 kHz resampled |
| 12:10:09 | copper | I know |
| 12:10:30 | copper | ah, no, I misread you |
| 12:10:48 | copper | is sampling freq is set to 48kHz, why would there be some re-resampling |
| 12:10:49 | copper | ? |
| 12:12:17 | bertrik | because someone has to make sure and write code that unnecessary resampling is skipped |
| 12:12:43 | copper | ah, that's not done yet? |
| 12:13:04 | bertrik | it's not clear what the exact status is |
| 12:13:57 | bertrik | so, assume the worst :) |
| 12:15:09 | copper | the worst would be the DAP exploding in my pocket against my junk |
| 12:15:27 | | Quit JdGordon (Ping timeout: 264 seconds) |
| 12:18:55 | *** | Saving seen data "./dancer.seen" |
| 12:21:14 | [Saint] | Nahhh...nothing there of interest. ;) |
| 12:21:49 | | Join y4n [0] (~y4n@unaffiliated/y4ndexx) |
| 12:22:19 | | Join JdGordon [0] (~jonno@CPE-121-218-128-223.lnse3.cht.bigpond.net.au) |
| 12:22:25 | | Quit JdGordon (Changing host) |
| 12:22:25 | | Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) |
| 12:28:31 | copper | cpu frequency of the Fuze+: 64000 |
| 12:28:42 | copper | cpu frequency of the iPod Classic: 54000000 |
| 12:28:45 | copper | what does it mean? |
| 12:30:05 | [Saint] | different units of measure? |
| 12:30:51 | copper | so is it really 64MHz and 54MHz? |
| 12:30:58 | pamaury | frequencies in the debug screen of the fuze+ are in kHz |
| 12:31:10 | [Saint] | copper: yep. |
| 12:31:13 | copper | 64 vs 54 doesn't seem much higher |
| 12:31:27 | pamaury | 64MHz is the lowest frequency of the fuze+ though |
| 12:31:28 | [Saint] | that's the *minimum* clock. |
| 12:31:39 | [Saint] | ie. unboosted. |
| 12:31:47 | copper | hmmm |
| 12:31:59 | copper | I want to test the Clip+ |
| 12:32:27 | pamaury | why are you interested in cou frequencies ? |
| 12:33:01 | copper | 09:24:09 UTC <[Saint]> that thing is foolishly overpowered. |
| 12:34:10 | [Saint] | Wow...and you really thought 64MHz was the max clock? |
| 12:34:21 | [Saint] | Its MUCh higher :) |
| 12:35:07 | copper | I don't know anything! |
| 12:37:14 | copper | [Saint]: can you put the Fuze+ into perspective for me? |
| 12:37:26 | copper | compared to, say, an iPod Classic and a Clip+ |
| 12:37:47 | [Saint] | It _should_ eat both for breakfast. |
| 12:38:19 | [Saint] | i.mx233 doesn't mess around. |
| 12:39:05 | [Saint] | its mac clock is somewhere in the range of 700MHz. |
| 12:39:09 | [Saint] | *max |
| 12:39:11 | | Quit JdGordon (Ping timeout: 256 seconds) |
| 12:39:17 | [Saint] | 680 or so, iirc. |
| 12:39:56 | [Saint] | couple that with solid state storage, and the Classic becomes a bit of a dinosaur. |
| 12:41:48 | [Saint] | bah...silly memory. I may be thinking of something else. I want to say ~450MHz this time. |
| 12:41:55 | DuperMan | iPod mini with a Compact Flash |
| 12:42:01 | DuperMan | good balance imo |
| 12:42:17 | DuperMan | an opinion grealy prejudiced towarsd what I own |
| 12:42:39 | [Saint] | DuperMan: Its a nice, quite underpowered, target. |
| 12:42:51 | DuperMan | true. plays very nice with flac |
| 12:43:02 | DuperMan | but db things make it insane |
| 12:43:25 | DuperMan | that's more to do with it expecting an hdd though, and controlling a cf in actuality |
| 12:43:34 | copper | testing both the Classic and the Clip+ |
| 12:43:36 | DuperMan | wanna buy the original 4gb microdrive though?:D |
| 12:43:49 | [Saint] | Nup. I have a small army of them. |
| 12:44:05 | [Saint] | copper: turns out I "whoops"ed. |
| 12:44:12 | copper | hmm? |
| 12:44:14 | DuperMan | hehe. ever buffed the apple logo on the back of the mini? it so shiny |
| 12:44:14 | [Saint] | its 454MHz max clock for the F= |
| 12:44:23 | [Saint] | *+ |
| 12:44:46 | [Saint] | which is still pretty nuts. |
| 12:45:02 | DuperMan | y b gr... oh. that's the native clock? |
| 12:45:05 | DuperMan | oO |
| 12:45:30 | DuperMan | fuze plus or clip plus? |
| 12:45:31 | [Saint] | Makes your Mini's 80 look a little dated, huh? |
| 12:45:55 | DuperMan | nah. I upgraded from my 30mhz palm IIIx a month ago ;) |
| 12:46:40 | DuperMan | 454... ain't that best gutted for a cheaper still r-pi? |
| 12:46:45 | [Saint] | fUZE+, BTW. |
| 12:46:53 | [Saint] | eeeks, kitten-caps. |
| 12:47:07 | copper | I guess they needed a speedy CPU for the OF interface |
| 12:47:19 | DuperMan | OF? |
| 12:47:27 | [Saint] | Original Firmware |
| 12:49:08 | DuperMan | wasn't it like 128 by 160? |
| 12:49:21 | DuperMan | mustv'e had mad effects for such a low res to be demanding:D |
| 12:49:27 | copper | 240x320 |
| 12:49:52 | DuperMan | reminds me of my hx4700 behemoth |
| 12:50:11 | DuperMan | 600mhz 600x480 iirc intel armstrong hehe |
| 12:50:17 | DuperMan | (ppc) |
| 12:50:59 | DuperMan | both cf and sd though... also got an hx2700 I should find a new batt for, then tcpmp |
| 12:51:26 | | Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) |
| 12:52:00 | DuperMan | THE POCKET PC / WINDOWS MOBILE >=6.5 LIVES |
| 12:52:24 | copper | Fuze+ performance spreadsheet of codecs that are of interest to me: http://outpost.fr/url/28s7 |
| 12:52:24 | | Join JdGordon [0] (~jonno@CPE-121-218-128-145.lnse3.cht.bigpond.net.au) |
| 12:52:26 | | Quit JdGordon (Changing host) |
| 12:52:26 | | Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) |
| 12:53:15 | DuperMan | what's coloumn b standing for? |
| 12:53:39 | DuperMan | time to decode a frame or frame per x time? |
| 12:54:03 | copper | % realtime |
| 12:54:51 | DuperMan | so it could transcode otf had you cared for that |
| 12:55:14 | copper | ? |
| 12:55:14 | DuperMan | big stinky feature request: for targets with wifi, dlna servor? |
| 12:55:16 | DuperMan | ^^ |
| 12:55:32 | copper | transcoding performance is unrelated to Rockbox decoding performance |
| 12:55:45 | copper | transcoding performance depends on your computer |
| 12:56:01 | DuperMan | too dependant on io perf and other bottlenecks? |
| 12:56:10 | [Saint] | The targets we support with wifi all have MUCh better implementations in their own firmware - so...probably not gonna happen. |
| 12:56:11 | copper | and "% real time" means nothing to transcoding "on the fly" |
| 12:56:16 | DuperMan | I was thinking more along the lines of making the player be a server |
| 12:56:46 | DuperMan | copper: I fail to see how the two are seperate |
| 12:56:48 | copper | just because encoding is faster than real time, doesn't mean it's fast enough |
| 12:57:03 | copper | DuperMan: you don't transcode with Rockbox |
| 12:57:08 | copper | you transcode with your computer |
| 12:57:12 | DuperMan | but... it... does... all other things being equal |
| 12:57:18 | copper | how is Rockbox performance related to your computer's performance? |
| 12:57:21 | copper | what? |
| 12:57:29 | copper | rockbox doesn't transcode anything |
| 12:57:35 | DuperMan | copper, I was being madddddd and suggesting adding a dlna or upnp server in rockbox |
| 12:57:50 | DuperMan | not speaking of actual existing features |
| 12:58:10 | [Saint] | [22:57:31] <copper> rockbox doesn't transcode anything <−−- well...technically... |
| 12:58:18 | [Saint] | re: Recording |
| 12:58:20 | DuperMan | a dac is a dac |
| 12:58:29 | DuperMan | eh [Saint]? |
| 12:58:38 | copper | [Saint]: recording means encoding not transcoding |
| 12:58:45 | copper | also, doesn't the recorder use WAV? |
| 12:58:48 | DuperMan | it transcodes a pcm stream |
| 12:58:50 | DuperMan | >< |
| 12:58:58 | DuperMan | or repackages for wav |
| 12:59:27 | [Saint] | I'm pretty sure we capture everything as raw PCM and then convert if the target file is anything other than that. |
| 12:59:31 | copper | it doesn't even encoding anything per se |
| 12:59:32 | [Saint] | Not entirely sure, though. |
| 12:59:38 | copper | encode* |
| 12:59:53 | DuperMan | ^^^ repackage |
| 13:00 |
| 13:00:05 | DuperMan | a wav is a container for a raw pcm stream |
| 13:00:09 | copper | I know |
| 13:00:16 | DuperMan | Imma clarifies |
| 13:00:19 | copper | I don't consider converting raw PCM to WAV "encoding" |
| 13:00:32 | [Saint] | options for recording are PCM, Wav, and Mp3...pretty sure there's no magic involved, so it must be doing *something* to get to mp3 in the end :) |
| 13:00:34 | DuperMan | I don't consider it converting :P |
| 13:00:49 | copper | MP3, really? |
| 13:00:54 | DuperMan | lol real time selective octet handling |
| 13:00:55 | DuperMan | :D |
| 13:01:07 | DuperMan | it only HEARS the bits relevant to cbr mp3 |
| 13:01:10 | DuperMan | ;P |
| 13:01:22 | DuperMan | also, magic |
| 13:01:27 | [Saint] | copper: really really. |
| 13:01:42 | copper | hmmm |
| 13:01:43 | [Saint] | In which case, we *muct* encode. |
| 13:01:49 | [Saint] | but, this is pure pedantism. |
| 13:01:50 | DuperMan | anybody wants a screenless iriver h340? |
| 13:01:51 | copper | I think the Classic results are going to be somewhat surprising |
| 13:02:02 | DuperMan | show 'em |
| 13:02:10 | copper | not done yet |
| 13:02:27 | DuperMan | I have battery dead x5l and lcd dead h340 |
| 13:02:28 | DuperMan | :( |
| 13:02:42 | DuperMan | srsly, anybody awesome enough to have use for those? |
| 13:02:52 | [Saint] | So, yeah, sorry for that - it was really assholeish - but, yeah, Rockbox can technically transcode. |
| 13:03:05 | DuperMan | it wasn't! it DOES |
| 13:03:07 | DuperMan | arrrgh |
| 13:03:49 | DuperMan | it wasn't even pedantic, seeing as you did not point out an irellevent to the topic lingual mistake |
| 13:04:12 | copper | I stand corrected about MP3 recording |
| 13:04:20 | DuperMan | but pointed out that the action in question is done under a certain scenario |
| 13:04:51 | [Saint] | I _think_ there's also a WAV-to-MP3 plugin. |
| 13:05:00 | DuperMan | but my original comment wasn't about the actual, but about a trollish feature request |
| 13:05:01 | DuperMan | :P |
| 13:05:15 | DuperMan | meh. it probably isn't hardware accelerated |
| 13:05:23 | DuperMan | so must be sluggish mad |
| 13:05:38 | DuperMan | too many possible cpu and dac archs |
| 13:05:54 | DuperMan | or kernel has api/hal? |
| 13:06:21 | [Saint] | Its not /sooo/ trollish, but realistically, the targets (presently) that have wifi are all "Application" targets, meaning we run as an app hosted in the targets OS, rather than replacing said OS, and the OS almost certainly has a better solution for this than we could implement. |
| 13:06:29 | DuperMan | like, for accessing the hw encoding machinary |
| 13:06:55 | DuperMan | hmmm... gotta praise the voodoo you do (we do?:D) on making android sound divine though |
| 13:07:14 | [Saint] | do what? |
| 13:07:19 | [Saint] | ...remind me of the babe! |
| 13:07:24 | DuperMan | btw, are my ears better served by the WM1811 DAC in my phone or whatever's in the ipod mini? |
| 13:07:26 | * | [Saint] skulks away |
| 13:07:35 | * | DuperMan is confused |
| 13:07:54 | DuperMan | "do what?" guess I placeboed myself |
| 13:08:13 | [Saint] | I thought you were quoting from David Bowie's "Dance the Magic Dance" :) |
| 13:08:48 | copper | hmmm, how do I quit the test_codec once it's done, on the Classic? |
| 13:08:59 | DuperMan | rofl :) no sorry |
| 13:09:42 | [Saint] | copper: insane iPod keymap tells me it'll probably be "select+<something>" |
| 13:09:51 | [Saint] | menu+select, probably. |
| 13:16:12 | copper | iPod Classic codec performance: http://pastebin.com/KfP5Za26 |
| 13:16:31 | DuperMan | thanks! |
| 13:16:44 | copper | http://outpost.fr/url/2lC0 |
| 13:17:10 | DuperMan | it raped your fuse |
| 13:17:28 | [Saint] | errrr... |
| 13:17:29 | copper | not really |
| 13:17:37 | [Saint] | Are you sure you know what you're looking at? |
| 13:17:38 | copper | performance figures are very different though |
| 13:17:57 | copper | on the classic, Vorbis is faster than Musepack!! |
| 13:18:06 | copper | marginally |
| 13:18:25 | DuperMan | me? no |
| 13:18:25 | [Saint] | DuperMan: if its not obvious, there's a clear winner here. |
| 13:18:30 | [Saint] | ...and it isn;t the Classic. |
| 13:18:35 | copper | and the differences between most codecs are much less pronounced |
| 13:18:56 | copper | [Saint]: er, not really |
| 13:19:09 | copper | LAME and VOrbis are faster on the Classic |
| 13:19:20 | [Saint] | ...but, everything else? |
| 13:19:22 | DuperMan | whoops. yeah |
| 13:19:23 | [Saint] | :) |
| 13:19:34 | copper | ALAC too |
| 13:19:35 | DuperMan | I assumed the codecs would be stacked samely in both tables |
| 13:19:39 | DuperMan | xD |
| 13:19:56 | copper | WavPack too |
| 13:20:09 | | Join Nephiel [0] (~5332f9b8@www.haxx.se) |
| 13:20:11 | DuperMan | MY BAD |
| 13:20:43 | copper | APE too! |
| 13:21:00 | DuperMan | I have a clip+ around, but need to do the fake jtag thing to revive it's flash |
| 13:21:02 | | Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 23.0/20130725195523]) |
| 13:21:06 | DuperMan | nand* |
| 13:21:22 | | Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) |
| 13:22:12 | [Saint] | copper: well..hmmm...I would say the winner is clear, even though the Classic is (marginally) faster for a few codecs, look at the CPU usage. |
| 13:22:32 | copper | ? |
| 13:22:36 | [Saint] | The Classic spends a LOT more CPU doing essentially the same thing. |
| 13:23:03 | copper | aw snap, the log on the Clip+ is empty |
| 13:23:03 | [Saint] | Fuze+ a52@192 |
| 13:23:05 | [Saint] | 0.06MHz needed for realtime |
| 13:23:15 | [Saint] | Classic? |
| 13:23:16 | [Saint] | 18.48MHz needed for realtime |
| 13:23:36 | [Saint] | just a bit of a difference ;) |
| 13:23:39 | DuperMan | 0.06. must haz teh hawt dac |
| 13:24:00 | copper | ah |
| 13:24:27 | [Saint] | while the realtime numbers are similar, the CPU usage is by far in favor of the F+ |
| 13:24:42 | DuperMan | a dac is a discrete cpu though |
| 13:25:52 | copper | [Saint]: does that mean the Fuze+ CPU is faster, or the Fuze+ target is more optimized? |
| 13:26:13 | TheSeven | damn, I'm *almost* there |
| 13:26:13 | DuperMan | copper: probably means the dac unit does most of the work |
| 13:26:21 | copper | what |
| 13:26:23 | DuperMan | which should count as 'target be optimized' |
| 13:26:25 | [Saint] | I believe it to be a combination of a much faster CPU, and much faster storage. |
| 13:26:25 | copper | a DAC doesn't decode |
| 13:26:28 | DuperMan | and 'target is gooder' |
| 13:26:51 | DuperMan | doesn't it? only pure streams? tell that to my denon |
| 13:26:53 | copper | a DAC converts PCM to analog |
| 13:27:00 | bertrik | The CPU plays a large part in playback performance, but other stuff like memory access speed/latency can have a lot of impact |
| 13:27:23 | DuperMan | yeah, caches too |
| 13:27:36 | DuperMan | needs to be as much like realtime systems as possible really |
| 13:28:24 | copper | re-running the Clip+ test |
| 13:28:35 | TheSeven | umsboot v0.2 *almost* connects... but something chews up the CSW of the SCSI INQUIRY transaction... |
| 13:28:52 | DuperMan | bloated linux kernel |
| 13:28:57 | pamaury | on the fuze+ the memory latency is huge, the ddr clock has a huge impact |
| 13:28:58 | TheSeven | fun fact: the very same code and driver works perfectly on a different device (STM32 SoC) |
| 13:30:15 | pamaury | TheSeven: is the amsv2 driver rewrite making some progress ? |
| 13:30:40 | TheSeven | no idea, I'm doing it in the other direction right now |
| 13:31:02 | TheSeven | porting the UMSboot userspace/application layer to the other framework which the USB driver comes from |
| 13:31:30 | TheSeven | just to get that part out of the way and to have an actually tested code base for porting to rockbox |
| 13:32:16 | TheSeven | but right now it looks like something breaks the second non-EP0 IN transfer for some reason |
| 13:32:26 | TheSeven | no matter what I try to send, the host always receives 2 bytes: 00 01 |
| 13:32:56 | TheSeven | that's kinda suspicious because those bytes might make sense as a GET STATUS EP0 response. but how do they end up on EP1? |
| 13:34:15 | pamaury | bad buffer configuration ? I think on this chip you can choose the buffer offsets and possibly overlap them or something like that ? |
| 13:34:25 | copper | I added "needed CPU MHz" to the spreadsheets |
| 13:36:07 | pamaury | TheSeven: so if I understand correctly, the same code on two different devices, one works while the other doesn't ? |
| 13:37:01 | TheSeven | yes, mostly the same code |
| 13:37:07 | TheSeven | completely different SoC, but same USB core |
| 13:37:14 | TheSeven | different core config though |
| 13:37:22 | TheSeven | the ipod is DMA-only, the other one PIO-only |
| 13:37:43 | TheSeven | I just checked: even if I don't even attempt to send a CSW, that garbage CSW arrives at the host |
| 13:37:54 | TheSeven | I also don't ever send a GET STATUS response or any other 2 byte EP0 packet |
| 13:38:03 | TheSeven | so where one earth does that garbage come from? |
| 13:38:23 | pamaury | DMA only ? I thought the chip was always capable for PIO |
| 13:39:41 | TheSeven | I thought that as well... but PIO seems to be broken on the nano2g as well |
| 13:40:07 | TheSeven | I can receive packets using PIO, but I will never ever get a TX fifo empty IRQ, so I can't send |
| 13:40:19 | pamaury | On the clip+ I tried PIO but it didn't work much better either, it wasn't fully broken but not better dma |
| 13:43:03 | pamaury | at least that means that all the people who tried to write the driver aren't completely dumb, there really is something we don't understand :-/ |
| 13:43:45 | pamaury | what about reverse engineering the whole nano2g or clip+ driver ? could that help or maybe you already did ? |
| 13:53:54 | DuperMan | WHAT ABOUT U DO IT IF IT SEEMS TRIVIAL |
| 13:54:14 | DuperMan | sorry reflex |
| 13:55:14 | [Saint] | ...are you just here to troll, or...? |
| 14:00 |
| 14:01:16 | DuperMan | to troll and educate myself, as well as lurk for the off chance somebody with a penchant for the mini comes along wanting to become my mentor |
| 14:02:28 | [Saint] | You need to stick around for ~1Y+ before you start trolling our active developers ;) |
| 14:03:35 | | Join ender` [0] (krneki@foo.eternallybored.org) |
| 14:03:50 | pamaury | DuperMan: I'm very aware of what reverse engineering work is if you want to know :) |
| 14:04:09 | DuperMan | oh lol well I troll codeworkx on the cyanogen places, even cotulla on xda-devs |
| 14:04:12 | DuperMan | no cred? xD |
| 14:04:36 | copper | Clip+ codec performance: http://pastebin.com/6mx8Lcdv and http://outpost.fr/url/2odq |
| 14:05:22 | DuperMan | pretty equivalent to the classic |
| 14:05:35 | copper | not really |
| 14:05:41 | copper | Vorbis is twice slower on the Clip+ |
| 14:05:47 | DuperMan | oO oh |
| 14:05:58 | copper | it's actually the slowest codec among those that I'm interested in |
| 14:06:09 | DuperMan | flac is more throughput = drains batt but easy to actually play right? |
| 14:06:16 | DuperMan | unparses to pcm |
| 14:06:41 | DuperMan | vorbis is famously complex, but better than mp3 at similar bitrates derp |
| 14:08:34 | copper | the Fuze+ kills the Classic and the Clip+ in FLAC performance |
| 14:09:29 | copper | pamaury: given the very low demand for CPU processing on the Fuze+, maybe you could put it in a low power state or something? |
| 14:09:37 | copper | is battery usage on the Fuze+ optimized already? |
| 14:10:33 | copper | [Saint]: the difference in "needed CPU MHz" between the Fuze+ and the other too is insane |
| 14:10:37 | copper | two* |
| 14:10:48 | pamaury | it's already super optimised: we run at 64MHz most of the time and sleep the cpu whenever there is nothing to do |
| 14:10:53 | copper | ok cool |
| 14:11:06 | * | DuperMan eyes his Palm IIIx |
| 14:11:18 | DuperMan | alas, no headphone jack |
| 14:11:20 | pamaury | with the upcoming patches for the touchpad we might reach ~40h of battery life |
| 14:11:33 | copper | nice |
| 14:12:18 | DuperMan | sorry for such obscene trolling, but shame the old creative njb3 series didn't see more love |
| 14:12:21 | copper | usually I feel like the Fuze+ takes a long time to charge, do you see the same thing? |
| 14:12:27 | | Quit tchan (Quit: WeeChat 0.4.1) |
| 14:14:06 | pamaury | honestly I didn't benchmark charging, I think we are already charging at the same current level as the OF, we don't have the battery spec so that's the safest we can go imo |
| 14:15:09 | pamaury | if you want to benchmark OF vs RB on this matter, maybe we could have figures |
| 14:17:52 | copper | meh, I can't really be bothered to do that |
| 14:18:59 | *** | Saving seen data "./dancer.seen" |
| 14:19:05 | copper | great job on the Fuze+ anyway, can't thank you enough for that :) |
| 14:19:18 | copper | I love that thing (with Rockbox). |
| 14:22:10 | jlbiasini | pamaury: ping |
| 14:22:16 | pamaury | thanks :) we have made a long way since the beginning ! |
| 14:22:19 | pamaury | jlbiasini: pong |
| 14:22:19 | TheSeven | pamaury: looks like the version of the OTG used in the ipods is a bit older and doesn't have some of the features that my driver relies on for PIO mode |
| 14:22:29 | TheSeven | especially it doesn't seem to have an IRQ for that fifo empty condition |
| 14:22:46 | TheSeven | how did you deal with that in PIO mode? |
| 14:22:55 | TheSeven | were you polling it? |
| 14:23:44 | jlbiasini | pamaury: do I have to declare the do_interupt function in the button_target.h? The compiler seems to want that and I don't know how to turn it around otherwise |
| 14:23:50 | pamaury | I don't remember honestly, I think I relied on IRQ |
| 14:24:01 | TheSeven | the nano2g driver was initially implemented by reverse engineering it btw, but it nevertheless didn't work properly :) |
| 14:24:17 | TheSeven | well, there doesn't seem to be an IRQ for this on that core version... maybe there is one on AMS? |
| 14:24:30 | pamaury | jlbiasini: no, the do_interrupt() function is already in button-fuzeplus.c, maybe I made a typo like interrupt vs interupt |
| 14:24:45 | TheSeven | the core version used in the nano2g seems to be fairly close to the one in the s3c6400x datasheet, which completely lacks the registers and IRQ bits for FIFO management |
| 14:25:14 | pamaury | TheSeven: at some point I implemented PIO, maybe you can look at the history of the the driver file or on flyspray to find the code |
| 14:29:42 | pamaury | TheSeven: FS #11664 |
| 14:30:13 | pamaury | search for PIO |
| 14:38:22 | copper | maybe it should be recommended somewhere, to unplug all unnecessary USB devices, before connecting a Rockboxed DAP |
| 14:38:27 | copper | wrt USB problems |
| 14:38:43 | copper | I'm almost certain my USB DAC was the one causing my problems, directly or indirectly |
| 14:40:11 | DuperMan | which dac? fiio one? |
| 14:40:17 | copper | ODAC |
| 14:40:18 | jlbiasini | pamaury: no it wasn't (at least with the actual head, so I added a static void do_interrupt(void); at the beginnig of the button-fuzeplus.c file. Is that the correct way to do? |
| 14:40:22 | DuperMan | my e17 bsods often |
| 14:40:35 | DuperMan | but fidelity's worth it :P |
| 14:41:27 | pamaury | jlbiasini: should be unnecessary: do_interrupt() is in the same file as the caller and before, why do you need to do this ? compile error ? |
| 14:41:39 | jlbiasini | yes |
| 14:41:51 | pamaury | did you modify my code ? |
| 14:42:37 | jlbiasini | not that much only adding the report rate modification |
| 14:43:16 | jlbiasini | is that place where appears the do interrupt function important (I means top/end of the fil for instance?) |
| 14:43:55 | pamaury | can you pastebin the code ? I don't think the report rate modification is needed by the way. Yes if you call it before it is defined, you need to declare it before: "static void do_interrupt();" |
| 14:45:19 | jlbiasini | the report rate has to be lower when in very_low_power |
| 14:45:26 | jlbiasini | at least |
| 14:46:32 | jlbiasini | well *has* not but I would like to test it to see if it's improving battery life without being anoying |
| 14:46:52 | pamaury | ok, but I doubt it, if you don't touch the device, there will be no report sent |
| 14:47:57 | jlbiasini | pamaury: ok here http://pastebin.com/MVL4uDgQ |
| 14:48:29 | TheSeven | pamaury: looks like you used one TX fifo for all EPs? |
| 14:48:52 | pamaury | I don't remember, that was a long time ago and I probably didn't know what I was doing ^^ |
| 14:49:46 | pamaury | jlbiasini: why put do_interrupt at the end ? it should stay within the #ifdef #endif because it's not needed in the bootloader |
| 14:49:58 | | Quit kevku (Ping timeout: 260 seconds) |
| 14:50:17 | TheSeven | hm... I have two datasheets that are explicitly contradicting each other |
| 14:50:31 | TheSeven | s3c6400x says that everything nonperiodic shall be pointed at fifo 0 |
| 14:50:33 | jlbiasini | yeah i just moved it to see if it was changing something to my compilation problem |
| 14:50:51 | TheSeven | stm32f4 says that each EP shall have its own fifo or things might get messed up |
| 14:50:52 | pamaury | TheSeven: I based on the s3c6400x datasheet iirc |
| 14:51:56 | TheSeven | mixing the data in a fifo in device mode just sounds like a very bad idea |
| 14:52:01 | jlbiasini | pamaury; I thing I deleted the touchpad sensitivity by error |
| 14:52:07 | TheSeven | and IIRC is responsible for a whole bunch of USB lockup problems on the classic |
| 14:52:07 | jlbiasini | *think |
| 14:52:20 | TheSeven | so I tend to not trust the s3c6400x datasheet there |
| 14:52:52 | pamaury | ok, seems safer to have each EP have its own fifo |
| 14:53:07 | pamaury | if the FIFO large enough to do this, always ? |
| 14:53:27 | TheSeven | yes |
| 14:54:30 | TheSeven | otherwise you may run into situations where the data that the host is waiting for can't be pushed into the fifo because it is full with data for another EP |
| 14:54:32 | pamaury | that fifo config param has been mysterious to me, it's not very well explained |
| 14:54:47 | TheSeven | it's much better explained in the stm32f4 datasheet |
| 14:55:09 | pamaury | I should read this one ^^ |
| 14:55:37 | TheSeven | it seems to be for a newer core revision though that handles PIO differently (and more efficiently) |
| 14:55:57 | TheSeven | I figure that this PIO change might be one of the reasons why things need to be in the same FIFO on the 6400x |
| 14:56:05 | TheSeven | but for DMA it doesn't make any sense |
| 14:57:07 | pamaury | I found another chip which uses a very similar core: Rockchip Nano-B uses the same as stm32f2 |
| 14:57:24 | TheSeven | should be the same one then, f2/f4 are identical |
| 14:57:27 | jlbiasini | pamaury: this is the error I get http://pastebin.com/NYU01SAQ (after redoing the touchpad_set_sensitivity() |
| 14:58:21 | pamaury | jlbiasini: you need to "static void do_interrupt(void);" at the top of the file if you implement do_interrupt after it is called |
| 14:58:53 | jlbiasini | ahah so should I put it above unstead of declaring it? |
| 14:59:09 | pamaury | yes, like it was done in the original patch |
| 14:59:20 | jlbiasini | ooops sorry |
| 15:00 |
| 15:10:52 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
| 15:20:54 | jlbiasini | pamaury: how long is 60 * HZ? 1 minutes? |
| 15:21:10 | jlbiasini | or is it device dependend? |
| 15:21:34 | gevaerts | 1 minute, yes |
| 15:22:20 | gevaerts | I don't believe HZ is different on different devices right now, but it could be, and if everything uses HZ properly, it doesn't matter |
| 15:22:38 | gevaerts | HZ is "ticks per second" |
| 15:22:55 | gevaerts | So 60 * HZ is "ticks per minute" |
| 15:23:28 | jlbiasini | yeah that is what I though thanks for confirmation |
| 15:23:42 | [Saint] | copper: Rockboxed devices can do some "Weird Shit (TM)" if left connected to some things. |
| 15:23:45 | [Saint] | ...no idea why. |
| 15:23:58 | [Saint] | I don't think anyone knows. |
| 15:24:15 | TheSeven | pamaury: as far as I can tell the s3c6400x variant of the core can only have in flight transfers on one endpoint at a time in PIO mode |
| 15:24:22 | copper | I think it would be a cheap and potentially effective recommendation to make |
| 15:24:28 | gevaerts | Normally (i.e. outside of some very specific low-level drivers) you don't need to know that HZ=100 :) |
| 15:24:31 | [Saint] | Some BIOS freak the fuck out and just hang, some machines refuse to shut down or hibernate. |
| 15:24:34 | [Saint] | Lots of fun things. |
| 15:25:14 | * | gevaerts doesn't like recommendations that are based on vague annecdotes and that can prevent people doing useful things |
| 15:26:27 | [Saint] | Where's the recommendation? |
| 15:26:54 | copper | [Saint]: recommending to unplug all unnecessary USB devices |
| 15:27:04 | copper | prior to connecting a Rockbox device |
| 15:27:23 | [Saint] | Ah. I thought that was directed at me. WHoops. |
| 15:28:15 | TheSeven | indeed. there's no way for the core to identify which endpoint a packet belongs to if multiple are enabled |
| 15:28:18 | pamaury | copper: what ? I've never heard of other usb devices interfering with a rockbox device, actually that seems pretty impossible given how usb works, except for a hub possibly |
| 15:28:37 | copper | pamaury: my devices almost always crash when my ODAC is connected |
| 15:28:42 | copper | and NEVER crash when it's not |
| 15:28:53 | TheSeven | sounds like a buggy driver |
| 15:29:09 | copper | doesn't matter what the problem is, until it's fixed |
| 15:29:13 | pamaury | yeah, buggy OS, nothing related to rockbox |
| 15:29:30 | pamaury | we can't warm against all possibly buggy code in the world |
| 15:29:34 | pamaury | *warn |
| 15:29:37 | copper | sigh |
| 15:29:51 | copper | so you'd rather have people's DAPs crash? |
| 15:30:03 | [Saint] | than do weird broken shit? yep. |
| 15:30:12 | copper | I mean, you guys already recommend changing skins |
| 15:30:24 | copper | isn't that anecdotal evidence? |
| 15:30:44 | copper | no-one even knows why skins could be a problem |
| 15:30:55 | copper | exactly* |
| 15:31:20 | pamaury | which device are you talking about which crashes with this ODAC thing ? |
| 15:31:28 | jlbiasini | gevaerts: now that I have you here, did you saw the comment of Lorenzo about that touchdev disable on keylock? he was suggesting to let that function and on devices that don't handle touchdev sleep, to have it just filtering the button reporting output... |
| 15:31:29 | copper | Classic, Fuze+, Clip+ |
| 15:31:56 | copper | thing is, Rockbox crashes, and no-one knows why |
| 15:32:10 | [Saint] | as I understand it if Rb works fine without this thing plugged, but doesn't when it is, the other thing is at fault - or the host. |
| 15:32:12 | copper | so I mean to do anything that can prevent it from happening |
| 15:32:21 | copper | [Saint]: I'm not pointing fingers |
| 15:32:28 | copper | that's not the point |
| 15:32:56 | copper | rather than tell users, "yeah, sorry, Rockbox crashes", I'd rather tell them "try to unplug everything else" |
| 15:33:20 | [Saint] | so, you're asking to Rockbox workaround some unknown fault to "fix" a problem that probably isn't theirs? |
| 15:33:26 | jlbiasini | or use the OF usb bootloader |
| 15:33:36 | copper | what? |
| 15:34:11 | copper | if, for instance, it's a USB driver bug |
| 15:34:32 | copper | well, lots of people happen to be using linux with the exact same driver, since it's completely generic |
| 15:34:32 | gevaerts | copper: the theme problem has been seen on several devices, by several people. No, we don't know the exact cause, but in my mind it's gone beyone anecdotal |
| 15:35:22 | copper | I mean to recommend anything that can help prevent a Rockbox device from crashing, that's all |
| 15:35:37 | gevaerts | jlbiasini: no, I haven't. When? |
| 15:35:42 | DuperMan | hmmm... db generation creating 4gb files that are just artifacts of the fs malfunctioning |
| 15:35:43 | * | [Saint] recommends not using the device |
| 15:35:53 | DuperMan | is it a normal fat32 on 64gb cf ipod thing? |
| 15:35:54 | [Saint] | ..it'll definitely not crash then. |
| 15:35:57 | copper | [Saint]: ok cool, I'll stop using Rockbox on all my three DAPs! |
| 15:35:59 | [Saint] | problem solved. |
| 15:36:07 | copper | or did you mean the ODAC? |
| 15:36:31 | jlbiasini | gevaerts: it was here http://www.rockbox.org/mail/archive//rockbox-dev-archive-2013-07/0008.shtml on the mailing list |
| 15:36:36 | DuperMan | copper: to prevent it from crashing don't use it |
| 15:36:49 | copper | that's just silly |
| 15:36:56 | | Quit mirak (Quit: Ex-Chat) |
| 15:37:01 | DuperMan | that's the only true solution, for any os |
| 15:37:06 | DuperMan | even jets |
| 15:37:22 | [Saint] | It was my remarkably awesome attempt at absurdium ad reducto. |
| 15:37:46 | [Saint] | reductio ad absurdum, even. |
| 15:37:57 | DuperMan | you have no idea how absurdium ad reducto really is fitting |
| 15:37:58 | DuperMan | ah |
| 15:38:00 | DuperMan | hehe |
| 15:38:07 | gevaerts | copper: if you qualify the recommendation enough, e.g. "Some people have observed issues when certain specific USB devices are also connected, so if you see USB instability or crashes, you might try disconnecting non-essential devices (and if this makes a difference, tell us about this)", I think it might be a good idea |
| 15:38:14 | | Join Epicanis [0] (~kvirc@sdsl-68-238-63-20.static.ngn.east.myfairpoint.net) |
| 15:38:30 | DuperMan | so you weren't silly to the point of vanishing |
| 15:38:46 | * | [Saint] vanishes |
| 15:38:48 | copper | what |
| 15:38:51 | copper | I don't speak latin |
| 15:39:03 | gevaerts | DuperMan: what do you mean by "db generation creating 4gb files that are just artifacts of the fs malfunctioning"? |
| 15:39:03 | DuperMan | gevaerts: that's oldddddd hat |
| 15:39:31 | DuperMan | it was mostly a recommendation for the n00b/moms out there that stick usb things in unpowered ports |
| 15:39:37 | gevaerts | DuperMan: you mean I should encourage the discussion going off-topic? No, sorry. |
| 15:39:47 | DuperMan | gevaerts: my ipod mini 1st gen does just that |
| 15:40:17 | DuperMan | it lists in the fat a 4gb file that doesn't effect real available space |
| 15:40:24 | gevaerts | Right |
| 15:41:01 | DuperMan | so... is that common, insofar as you're aware? |
| 15:41:23 | gevaerts | I've never seen anyone report that specifically, but yes, check the filesystem |
| 15:41:33 | DuperMan | I assume I need to compile my own builds and have the build not assume it's talking to an hdd |
| 15:41:39 | gevaerts | No |
| 15:41:48 | gevaerts | Rockbox should work fine with CF cards |
| 15:41:54 | [Saint] | I have only personally seen db generation *really* thrash an already trashed fs. |
| 15:42:23 | DuperMan | hmmm... it's been factory reset a few times, but I don't remember formatting it low level |
| 15:42:28 | [Saint] | I have not personally seen it actually cause issues in stable devices. |
| 15:42:29 | gevaerts | If you're sure you start with a clean filesystem and you end up with a corrupted filesystem, and you didn't have a crash or an unsafe unplug in between, there's a bug |
| 15:42:36 | DuperMan | so... "no" to letting itunes format for me? |
| 15:42:46 | gevaerts | You don't do low-level formats on non-floppy devices typically :) |
| 15:42:57 | DuperMan | hehe yeah but it sure is fun |
| 15:42:58 | DuperMan | :) |
| 15:43:07 | gevaerts | Well, you typically *can't* |
| 15:43:32 | DuperMan | ehrm... disk part is kinda cool like that, but no reconfiguring the controller hhe |
| 15:43:49 | DuperMan | I meant a full rather than quick format |
| 15:44:24 | gevaerts | That shouldn't make any difference at all |
| 15:44:58 | DuperMan | so to be sure I'm working with a workable thingy, I should put the cf in a card reader and manually build the partitions etc.? or my pletorous normal formattings shouldv'e sufficed? |
| 15:45:06 | TheSeven | (besides taking longer and wearing out the media) |
| 15:45:11 | DuperMan | ^ |
| 15:45:33 | DuperMan | it's a thing you do when frustrated. I can't be the only one who did... |
| 15:45:36 | DuperMan | :P |
| 15:45:42 | TheSeven | IF things work right, you should be able to format it through rockbox's USB interface, but then again that isn't exactly the most robust thing |
| 15:45:42 | * | [Saint] giggles |
| 15:45:48 | [Saint] | "workable thingy" |
| 15:46:15 | DuperMan | well "ipod" isn't a more respectable term |
| 15:46:17 | DuperMan | :) |
| 15:46:23 | gevaerts | DuperMan: doesn't make *any* difference. If whatever formats the device makes sure the FAT is clean and the root directory is empty, and the partition tables make sense, you're fine |
| 15:47:19 | DuperMan | hmmm... wouldn't that make an ipod panic and sadface? not sure if the handover from the bootloader is timed for such a case |
| 15:47:30 | DuperMan | like, I won't have the magic apple folder of ipodstuffs |
| 15:48:06 | gevaerts | Well, I'm assuming you don't let the tools touch the firmware partition |
| 15:48:12 | DuperMan | I'll save us all the trouble. the cf card I use is a dolgix:D |
| 15:48:36 | DuperMan | I haven't so far, but that keeps on happening. best results are when I set spindown to 0 to disable it |
| 15:49:32 | DuperMan | but it always seem to happen after a while. also; battery use reports are whimsical |
| 15:50:31 | DuperMan | if anybody knows, will compiling a build that supports exfat work or will the ipod bootloader won't be able to handoff to the kernel? |
| 15:51:01 | DuperMan | (I mean, format it to exfat after I made sure my rockbox will be able to read it. I know it won't be OF compatible) |
| 15:51:23 | gevaerts | The ipod bootloader doesn't care about the data partition |
| 15:51:44 | gevaerts | Of course, "compiling a build that supports exfat" implies implementing exfat support first, so good luck :) |
| 15:52:03 | DuperMan | another idea I had is working with the ipodlinux bootloader, but that's such an old fad I'm unable to find data on it |
| 15:52:10 | DuperMan | ah! xD |
| 15:52:16 | DuperMan | hehehe thanks, wish I could |
| 16:00 |
| 16:05:18 | | Join kevku [0] (~kevku@2001:0:c38c:c38c:e6:4b86:3d69:bedb) |
| 16:07:03 | | Quit akaWolf (Ping timeout: 264 seconds) |
| 16:07:17 | | Join akaWolf [0] (~akaWolf@188.134.9.161) |
| 16:07:25 | | Quit akaWolf (Changing host) |
| 16:07:25 | | Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) |
| 16:07:47 | | Quit Guest11127 (Read error: Connection reset by peer) |
| 16:19:02 | *** | Saving seen data "./dancer.seen" |
| 16:19:55 | soap | !seen linuxstb |
| 16:19:59 | soap | .seen linuxstb |
| 16:20:01 | soap | gah |
| 16:20:21 | bertrik | /msg logbot seen linuxstb |
| 16:20:30 | soap | ty |
| 16:20:39 | jlbiasini | gevaerts: so any idea about http://www.rockbox.org/mail/archive//rockbox-dev-archive-2013-07/0008.shtml |
| 16:29:45 | gevaerts | jlbiasini: I suspect he knows that part of the code better than I do, so I'll believe him :) |
| 16:30:04 | jlbiasini | ok |
| 16:30:15 | | Part jvd |
| 16:31:12 | jlbiasini | so I will start implementing it then... |
| 16:31:36 | | Quit pamaury (Read error: Operation timed out) |
| 16:51:29 | | Quit jlbiasini (Quit: jlbiasini) |
| 17:00 |
| 17:02:29 | | Quit [Saint] (Remote host closed the connection) |
| 17:02:48 | TheSeven | what the hell... |
| 17:03:08 | TheSeven | this OTG decrements the "packets to be sent" counter below zero, wrapping to 1023 |
| 17:04:40 | | Join [Saint] [0] (~saint@rockbox/user/saint) |
| 17:06:36 | | Join webguest53 [0] (~3c1182e6@www.haxx.se) |
| 17:07:17 | | Quit webguest53 (Client Quit) |
| 17:17:19 | TheSeven | hm |
| 17:17:31 | TheSeven | apparently these ipods indeed have a buggy old version of this core |
| 17:29:49 | | Quit thegeek (Read error: Connection reset by peer) |
| 17:31:33 | | Join thegeek [0] (~thegeek@40.200.16.62.customer.cdi.no) |
| 17:33:43 | | Quit kevku (Ping timeout: 245 seconds) |
| 17:42:54 | Nephiel | Hi there |
| 17:43:52 | Nephiel | I was looking at FS #11376 http://www.rockbox.org/tracker/task/11376 |
| 17:47:11 | Nephiel | doesn't seem so hard to fix. Am I right in assuming track indexes aren't always in order on playlists? |
| 17:48:06 | gevaerts | Well, it's probably easy for someone who knows that subsystem :) |
| 17:48:20 | gevaerts | Which could be you, after a few days' work! |
| 17:49:22 | Nephiel | well, that's what I am trying to do ;) |
| 17:50:51 | [Saint] | I'm not actually sure this is anything that "broke" as the tracker suggests. |
| 17:51:09 | [Saint] | I recall seeing this behavior years and years and years ago. |
| 17:51:26 | gevaerts | Well yes, it's clearly old |
| 17:51:45 | gevaerts | But if I read the report correctly, it's also quite clearly a bug |
| 17:52:01 | [Saint] | Oh, yes, no denying that. |
| 17:52:26 | Nephiel | well, I've been seeing it for quite a while and I found it quite annoying, that's why I wanted to fix it |
| 17:53:03 | [Saint] | that's a good reason. :) |
| 17:53:05 | Nephiel | just built from git, bug still there |
| 17:53:38 | * | gevaerts never actually moved a track to before the current track in his playlist |
| 17:53:38 | [Saint] | The code that handles this probably hasn;t changed for some time. |
| 17:54:01 | gevaerts | It sounds like something only very few playlist powerusers would do |
| 17:54:13 | gevaerts | Which is why nobody fixed it yet, probably |
| 17:55:13 | Nephiel | Actually it happens whenever you move any track to any position before the currently playing track |
| 17:55:49 | Nephiel | except to the first one (that looks like a prepend and works as intended) |
| 17:57:18 | [Saint] | Moving a track to before the currently playing track likely occurs rarely, as gevaerts suggested. |
| 17:57:27 | [Saint] | I can't think of any use case for it personally. |
| 17:57:52 | [Saint] | I want to listen to my tracks, so moving them before the current one seems counterproductive to their playback. |
| 17:58:39 | gevaerts | I can imagine some use cases, but none of them is something I'd personally need |
| 17:58:50 | gevaerts | e.g. preparing a playlist for later use |
| 17:59:01 | gevaerts | (while listening, so you get a proper feel) |
| 17:59:27 | [Saint] | I do that on a PC, as its so damn painful on-device. |
| 17:59:41 | gevaerts | Well yes, due to this bug :) |
| 17:59:50 | Nephiel | I do use it. Suppose I have a track coming up that I don't want to listen to right now, but don't want to remove it from the list as I might want to listen to it later |
| 18:00 |
| 18:00:06 | Nephiel | so I move it above the currently playing one |
| 18:00:15 | [Saint] | >>| |
| 18:00:22 | [Saint] | that's my solution for that :) |
| 18:00:31 | gevaerts | [Saint]: you can only do that when you reach the track |
| 18:01:10 | gevaerts | i.e. not three tracks in advance |
| 18:01:44 | gevaerts | Hmmm |
| 18:01:53 | Nephiel | >>| works but not if you're listening while having a nap |
| 18:02:13 | gevaerts | What happens if you move a track the other way, i.e. from before the current track to after? Do things get confused then? |
| 18:02:28 | [Saint] | I imagine so? |
| 18:02:55 | Nephiel | no, that works. In fact I think I have it figured out, patch incoming |
| 18:03:49 | | Join krabador [0] (~krabador_@unaffiliated/krabador) |
| 18:05:50 | Nephiel | but I'd like to know if I can simply look at playlist indexes to check if a track comes before another in the playlist |
| 18:06:45 | Nephiel | if not, I'll have to look at display_index for each track I want to check |
| 18:09:56 | * | gevaerts has no idea |
| 18:10:18 | gevaerts | I'd suggest putting a patch on gerrit using your first assumptions, and waiting for a review by someone who knows |
| 18:11:33 | * | [Saint] suggests looking at http://www.rockbox.org/wiki/UsingGit#Preparing_to_make_changes |
| 18:12:25 | [Saint] | (thought it doesn't actually state it there, there's also a Real Name policy) |
| 18:13:42 | [Saint] | the git config username should be your realname, and the git config email address the same as the address used in gerrit. |
| 18:14:04 | Nephiel | I was about to post it to Flyspray |
| 18:14:31 | gevaerts | We do prefer gerrit, but if it's a simple patch I suspect it can go on flyspray |
| 18:14:57 | gevaerts | Well, I do prefer bugfixes on flyspray over no bugfixes at all, anyway :) |
| 18:15:57 | [Saint] | Shhhhuuuuuush! |
| 18:16:01 | [Saint] | He's fixing bugs. |
| 18:16:07 | [Saint] | We want him to come back! :P |
| 18:18:53 | | Quit krabador (Quit: Sto andando via) |
| 18:19:04 | *** | Saving seen data "./dancer.seen" |
| 18:29:05 | Nephiel | Submitted http://www.rockbox.org/tracker/task/12887 |
| 18:30:23 | Nephiel | It doesn't allow me to add FS #11376 as related task but it's linked in the description |
| 18:30:39 | gevaerts | Why didn't you just add it to FS #11376? |
| 18:31:41 | gevaerts | And especially, why does flyspray want to add lots of empty lines to everything it outputs? While it doesn't *really* break patches, it does break rss feeds... |
| 18:31:58 | gevaerts | It didn't use to do that until quite recently |
| 18:32:04 | [Saint] | this seems like a new thing. |
| 18:32:06 | * | gevaerts looks for a Swede to look at this |
| 18:32:14 | [Saint] | aha, glad I'm not the only that noticed. |
| 18:32:15 | Nephiel | oops, you're right, I should have added it to 11376 |
| 18:33:06 | [Saint] | twice now I've clicked a flyspray patch link and sat there "waiting for the page to load" |
| 18:33:14 | [Saint] | ...before realizing I needed to scroll. |
| 18:33:43 | gevaerts | [Saint]: well, for me it mainly breaks my new tasks and edited tasks "smart bookmarks" |
| 18:34:43 | Nephiel | I had the blank space issue too with patches, but screenshots are worse, they don't load at all |
| 18:38:08 | gevaerts | Bagder: do you have any idea why just about anything in php on the server (flyspray, your blog, ...) adds loads of empty lines at the start of all output? |
| 18:38:27 | gevaerts | That's fine for html, but it breaks anything els |
| 18:38:28 | gevaerts | e |
| 18:59:10 | | Join SovonHalder [0] (~RED@115.187.62.29) |
| 18:59:11 | Bagder | gevaerts: hm, no I don't but I figure I should look into it |
| 18:59:51 | gevaerts | Bagder: you could also try to find Zagor of course :) |
| 19:00 |
| 19:04:56 | Bagder | that's also a good idea! =) |
| 19:06:00 | SovonHalder | I posted a thread around 2 hours ago on the forum under 'Support and General Use>Hareware'....haven't received any replies yet..PLEASE help me..I am desperate.. The thread is this : Support and General Use |
| 19:06:06 | SovonHalder | http://forums.rockbox.org/index.php/topic,43310.0.html |
| 19:06:25 | [Saint] | 2 hours is a VERY short time. |
| 19:06:32 | copper | SovonHalder: if all else fails, I suggest reformatting the iPod's drive with emCORE, and then refrain from renaming the drive |
| 19:07:38 | copper | does anyone know how Rockbox would react after changing the drive label on the PC? |
| 19:07:56 | SovonHalder | really? all this is happening just because RENAME'd my drive name ? |
| 19:08:32 | copper | I don't know, but you yourself said that's when the problems started happening |
| 19:08:45 | SovonHalder | Apparently yes.. |
| 19:08:55 | SovonHalder | but I hate to believe such thing |
| 19:09:00 | [Saint] | Rockbox shouldn't give a flying fudge about the volume label. |
| 19:10:31 | copper | any chance that Windows would be doing something else during that operation, that would explain it? |
| 19:10:47 | copper | or maybe it's really a Windows problem altogether? |
| 19:10:58 | TheSeven | SovonHalder: looks like there's file system corruption, possibly caused by not properly ejecting the ipod or by hardware malfunction |
| 19:11:24 | TheSeven | the battery behavior that you reported is somewhat normal. rockbox only has a crude estimate of the battery state |
| 19:11:25 | SovonHalder | I have itunes installed..should I uninstall it ? |
| 19:11:35 | SovonHalder | Normal ? |
| 19:11:40 | SovonHalder | Holy jeez |
| 19:11:57 | TheSeven | so it can happen that it says 95% while it's actually 100% |
| 19:12:06 | TheSeven | and it won't even start charging before it drops below 85-90%-ish |
| 19:12:08 | [Saint] | Depends how you want to manage your music. |
| 19:12:11 | SovonHalder | first two days it worked fine...then suddenly it just like that!!!?? |
| 19:12:15 | [Saint] | iTune sis no longer required. |
| 19:12:38 | TheSeven | the charging is hardware controlled, so it will behave the same as it did with the apple firmware. it's just that our battery meter might be a bit off at times |
| 19:12:46 | [Saint] | I rather suspect that at some point you didn't properly eject the device. |
| 19:12:59 | [Saint] | This can, and often will, trash the filesystem. |
| 19:13:21 | TheSeven | especially in combination with the rather flaky USB support of the classic |
| 19:13:37 | SovonHalder | Saint: I think I might have done that |
| 19:14:15 | SovonHalder | when the Drive disappeared, i couldn't find an option for safe removal...so I just ejected.. |
| 19:14:32 | copper | SovonHalder: do you have a copy of your files on your PC? |
| 19:14:38 | SovonHalder | :) |
| 19:14:40 | SovonHalder | of course |
| 19:15:11 | copper | then long press Menu + Select until you get to the emcore menu |
| 19:15:22 | copper | downscroll until "Tools" |
| 19:15:32 | copper | "reformat data partition" |
| 19:15:41 | copper | that should clean up the mess |
| 19:15:42 | [Saint] | Argh! No! |
| 19:15:47 | copper | why not? |
| 19:15:50 | [Saint] | menu+select == bad! |
| 19:15:54 | copper | what? |
| 19:16:12 | TheSeven | copper: shut it down properly if you can still do so (i.e. if it isn't completely locked up) |
| 19:16:19 | [Saint] | You should only do this if you can't avoid it. |
| 19:16:33 | TheSeven | menu+select resets physically stress the hard disk drive |
| 19:16:34 | copper | sorry, I meant while off |
| 19:16:34 | [Saint] | Encouraging it as a shutdown/reset is bad behavior. |
| 19:16:53 | [Saint] | ...reset the player, while off? |
| 19:16:55 | copper | how do you avoid emcore going directly to rockbox? |
| 19:16:58 | [Saint] | why would that be needed? |
| 19:17:01 | copper | long press play? |
| 19:17:05 | [Saint] | any button. |
| 19:17:08 | TheSeven | if you have fastboot enabled? just press and hold any button during boot |
| 19:17:13 | copper | ok, sorry |
| 19:17:27 | SovonHalder | formatting data partition would recover system files? if they are corrupted? |
| 19:17:35 | [Saint] | Hell no. :) |
| 19:17:47 | TheSeven | SovonHalder: it will basically revert your ipod to the state that it was in immediately after installing emcore |
| 19:17:52 | copper | just unpack the rockbox build zip onto the formatted drive |
| 19:18:00 | [Saint] | copper is possibly unwisely skipping that route. |
| 19:18:11 | [Saint] | You can of course attempt recovery of the filesystem. |
| 19:18:26 | TheSeven | can be tricky if USB is too flaky |
| 19:18:36 | [Saint] | see: attempt :) |
| 19:19:12 | [Saint] | I always like to try first, beets a format and shifting many GB of data around. |
| 19:19:17 | SovonHalder | Saint: so you were telling about system files corruption due to improper unsafe removal of my drive.. then I don't need to reformat data partition right ? |
| 19:19:20 | [Saint] | *beats too |
| 19:20:10 | SovonHalder | Just tell em what should I do now.. |
| 19:20:55 | TheSeven | you can try to repair the file system, but these reconnects might be preventing you from doing that |
| 19:20:56 | [Saint] | No. You don't *need* to - but, recovery may not work, if you do have your files backed up and the time isn't an issue, then by all means, just format it. |
| 19:21:27 | [Saint] | Its not something you need to do, necessarily, but it may be faster to do so in the end. |
| 19:21:58 | [Saint] | It just happens to be a pet peeve of mine when recovery of the filesystem isn;t even a first suggested option. :) |
| 19:22:29 | SovonHalder | Do I need need iTunes uninstalled ? |
| 19:22:44 | SovonHalder | some apple services caused issues last time |
| 19:22:52 | SovonHalder | when I was installing |
| 19:23:01 | [Saint] | With installation. We're past that now. |
| 19:23:01 | SovonHalder | rockbox for the first time |
| 19:23:25 | [Saint] | If iTunes is how you manage your music, feel free to leave it there. |
| 19:23:35 | SovonHalder | I hate iTunes... |
| 19:23:47 | SovonHalder | that's why i installed rockbox.. |
| 19:24:09 | SovonHalder | I haven't played a single track in last 3 years in iTunes..so I'll uninstall it.. next ? |
| 19:24:18 | SovonHalder | how do I format ? |
| 19:24:47 | | Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) |
| 19:25:01 | TheSeven | SovonHalder: within the emcore boot menu, scroll to the right, there's a "tools" icon |
| 19:25:13 | TheSeven | in the tools menu, there's a "reformat data partition" option |
| 19:25:39 | [Saint] | it'll give some form of "are you sure?" message - tell it yes. |
| 19:26:14 | SovonHalder | reformatting dara parttion.. |
| 19:26:25 | SovonHalder | It's done..next ? |
| 19:26:47 | TheSeven | now just plug it in and check if it works again |
| 19:27:07 | TheSeven | (boot rockbox if you haven't done that already) |
| 19:27:14 | TheSeven | then extract the rockbox zip file to reinstall that |
| 19:27:16 | [Saint] | TheSeven: no new build? |
| 19:27:32 | [Saint] | ah - yes: here - http://build.rockbox.org/data/rockbox-ipod6g.zip |
| 19:27:42 | SovonHalder | no rockbox directory−−−−installation complete |
| 19:28:00 | TheSeven | well, be aware that new (as in younger than a year) builds are likely to show more USB trouble than older ones for some reason |
| 19:28:00 | [Saint] | this is expected, you just wiped it out :) |
| 19:28:08 | [Saint] | extract the above linked .zip to the root of the device. |
| 19:28:30 | SovonHalder | w8 |
| 19:28:35 | TheSeven | and then just shut it down and boot it back up, then you're running a current rockbox version |
| 19:28:54 | [Saint] | RbUtil could also take over at this point if you wanted. |
| 19:29:29 | [Saint] | RoLo should fire, no need for shutdown. |
| 19:30:00 | SovonHalder | it took 12 seconds to show the drive |
| 19:30:02 | SovonHalder | is this normal ? |
| 19:32:15 | SovonHalder | how do I shut it down? |
| 19:32:22 | SovonHalder | long press the play button ? |
| 19:32:23 | [Saint] | hold play. |
| 19:32:27 | SovonHalder | okay |
| 19:33:51 | SovonHalder | Version: 49bcf35-130724 |
| 19:34:57 | SovonHalder | Can I use this theme? |
| 19:34:58 | SovonHalder | http://themes.rockbox.org/index.php?themeid=1883&target=ipodvideo |
| 19:35:06 | [Saint] | yes. |
| 19:35:15 | SovonHalder | I mean do themes create problems ? |
| 19:35:18 | [Saint] | you can use any of the themes from the iPod Video section. |
| 19:35:26 | [Saint] | they can, yes. |
| 19:36:12 | SovonHalder | really? I mean are those problems often? If so, I can hang on to the default theme.. |
| 19:36:23 | SovonHalder | Iy's just the theme is simple |
| 19:36:55 | [Saint] | Themes are user submitted - there is no expectation of quality with them. |
| 19:37:27 | SovonHalder | By quality did you mean 'stabily' or 'compatibility' ? |
| 19:38:19 | [Saint] | We can only guarantee the code parses, not that it is correct, or functions as intended. |
| 19:39:21 | SovonHalder | I'm sorry for bothering you all.. my bad.. but I have to transfer over 60GBs of music to my drive now. That's not something one can do whenever he wants..so any words on how do I prevent happening such issues in furute ? |
| 19:39:42 | SovonHalder | *future |
| 19:39:52 | [Saint] | Always safely remove. |
| 19:39:53 | lebellium | [Saint]: although what you say is correct, it seems that you are frightening him :) I would simply say "they may create problems but most of them don't and if there is any problem with a theme you can always switch back to the default cabbiev2" |
| 19:40:14 | copper | SovonHalder: I haven't had problems with that theme |
| 19:40:44 | SovonHalder | Cooper: then I'll stick with you.. |
| 19:40:54 | [Saint] | lebellium: I'm just trying very hard not to say "Yes, it will work as advertised", because I can't make that claim :) |
| 19:41:38 | [Saint] | I never said *don't* try it... |
| 19:41:38 | SovonHalder | please tell me do I prevent happening such issues in future ? |
| 19:42:03 | copper | 17:39:53 UTC <[Saint]> Always safely remove. |
| 19:42:05 | [Saint] | The only thing you can do, really, is always safely remove the device. |
| 19:42:06 | SovonHalder | rather than safe removal |
| 19:42:11 | [Saint] | that's it. |
| 19:42:12 | SovonHalder | okay.. |
| 19:42:29 | SovonHalder | can I rename the drive label / |
| 19:42:31 | SovonHalder | ? |
| 19:42:48 | [Saint] | In theory, yes. |
| 19:45:12 | SovonHalder | I just connected it to my PC & it took 30 seconds to sho me drive.. is this also normal ? |
| 19:45:52 | TheSeven | that can be normal |
| 19:45:52 | copper | Windows can be sucky that way |
| 19:46:00 | TheSeven | windows sometimes reads the whole FAT while mounting |
| 19:46:25 | TheSeven | which is ~320MB on a 160GB ipod |
| 19:46:35 | TheSeven | so 30 seconds sounds about right |
| 19:49:02 | SovonHalder | I just renamed. ..nothing wrong happened.. went A OK.. |
| 19:49:31 | * | Nephiel just commited a fix for FS #11376 to gerrit: http://gerrit.rockbox.org/r/#/c/530/ |
| 19:54:46 | copper | well fuck. |
| 19:55:06 | copper | my Fuze+ just crashed while connected to my laptop, after hours of copying files |
| 19:55:13 | copper | nothing else connected |
| 19:55:32 | SovonHalder | :( |
| 19:55:36 | | Join Strife89 [0] (~Strife89@adsl-98-80-224-47.mcn.bellsouth.net) |
| 19:56:25 | SovonHalder | I am not a jinx..am i? :P |
| 19:56:46 | copper | now fsck.vfat is "Reclaiming unconnected clusters." and it's taking 100% of one CPU core and I have no idea when it will complete |
| 19:56:48 | [Saint] | No. It just blew a prior assumption away, that's all. |
| 19:57:00 | copper | [Saint]: it doesn't |
| 19:57:15 | copper | the ODAC being connected is certainly a trigger |
| 19:57:25 | copper | that doesn't mean it is the only cause of Rockbox crashing |
| 19:57:29 | [Saint] | you said your devices *never* crashed without the ODAC |
| 19:57:45 | copper | yeah |
| 19:58:14 | [Saint] | [01:28:40] <copper> pamaury: my devices almost always crash when my ODAC is connected |
| 19:58:14 | [Saint] | [01:28:44] <copper> and NEVER crash when it's not |
| 19:58:17 | copper | still doesn't erase the fact that they almost always crash with the ODAC connected |
| 19:59:05 | SovonHalder | umm...what is the full form of ODAC ? |
| 19:59:13 | copper | geez, what's the point of running fsck with -v when there's no progress |
| 19:59:20 | copper | SovonHalder: what? |
| 19:59:33 | SovonHalder | nevermind..sorry |
| 20:00 |
| 20:03:23 | Nephiel | SovonHalder: I think it's a mix of Objective Desktop Amplifier and Digital-Analog Converter |
| 20:05:56 | SovonHalder | when I click on safely remove 'Apple iPo...' in system tray..it shows 'Safe to Romove Hardware' but the USB logo on iPod classic screen doesn't disappear.. then awhen I remove the cable there showed a tiny warning for 12 seconds that somewhat says 'Error Accessing Playlist control file' or something like that...what is this issue ? I haven't copied a single track yet |
| 20:07:15 | [Saint] | The USB image is still there. because its still connected. :) |
| 20:07:39 | copper | ugh, copying to my 64 GB microSDXC card through the adapter and my laptop's card reader is twice as fast as copying via the Fuze+ |
| 20:07:44 | [Saint] | It doesn't mean "I'm connected, and mounted", it merely means "I see I'm connected via USB" |
| 20:12:55 | | Join Guest11127 [0] (Slayer@c-69-143-178-62.hsd1.va.comcast.net) |
| 20:16:16 | | Join krabador [0] (~krabador_@unaffiliated/krabador) |
| 20:19:07 | *** | No seen item changed, no save performed. |
| 20:28:23 | TheSeven | is there anybody here for whom UMSboot fails to mount properly on nano2g? |
| 20:28:35 | TheSeven | I need testers for the new one |
| 20:29:29 | SovonHalder | Well, how long the USB Image stays? It's about 3 minutes+ since I saw 'Safe to Remove' banner. |
| 20:30:20 | [Saint] | Is it still connected via USB? |
| 20:30:45 | SovonHalder | yes |
| 20:30:52 | SovonHalder | I haven't unplugged it yet |
| 20:30:57 | [Saint] | ...did you read what I wrote above? |
| 20:31:03 | [Saint] | It doesn't mean "I'm connected, and mounted", it merely means "I see I'm connected via USB" |
| 20:31:15 | SovonHalder | Oo..sorry.. |
| 20:31:20 | SovonHalder | I missed tat line |
| 20:31:23 | [Saint] | the device will give no visual indicator it is safe to eject. |
| 20:31:46 | SovonHalder | what about that 'Error Accessing Playlist control file' then ? |
| 20:32:16 | [Saint] | I believe that is expected for a first boot. |
| 20:34:50 | | Quit krabador (Ping timeout: 260 seconds) |
| 20:39:10 | SovonHalder | I disconnected.. turned of my ipod..turned on my ipod..connected via usb−−-again shows 'Error Accessing Playlist control file' |
| 20:39:31 | SovonHalder | I safely removed..connected again... still shows 'Error Accessing Playlist control file' |
| 20:40:09 | TheSeven | SovonHalder: how old is that ipod? |
| 20:40:47 | SovonHalder | it's iPod Classic 7G 160G.. I bought it around 4 months ago Brand Newq |
| 20:40:51 | SovonHalder | *New |
| 20:44:31 | TheSeven | fully working (on my device and ubuntu precise) new umsboot source: https://mega.co.nz/#!4Iw3USyD!EK2O-Q-jdumd6xYPeb1FVwfyh0x-tR0ljUvA2AfGU7M |
| 20:44:38 | TheSeven | no lcd driver yet, but the rest works just fine |
| 20:44:59 | TheSeven | SovonHalder: OK, so I hope we can rule out HW damage |
| 20:45:14 | TheSeven | I've seen numerous hard drives fail on the 80GB and 120GB series |
| 20:46:17 | SovonHalder | there are about Eight threads on this particular isue on rock box forum saying "" 'Error Accessing Playlist control file' on my bla bla bla"" |
| 20:46:52 | SovonHalder | everyone says it's not that important |
| 20:47:00 | SovonHalder | is that right ? |
| 20:47:42 | | Join krabador [0] (~krabador_@unaffiliated/krabador) |
| 20:49:46 | | Join lorenzo92 [0] (~chatzilla@host171-106-dynamic.17-79-r.retail.telecomitalia.it) |
| 20:54:05 | | Join fs-bluebot [0] (~fs-bluebo@g225252157.adsl.alicedsl.de) |
| 20:57:10 | lorenzo92 | kugel: did you read about usb suppport on hosted platforms? |
| 20:57:24 | lorenzo92 | (if you had time :) ) |
| 21:00 |
| 21:05:06 | | Join thegeek_ [0] (~thegeek@40.200.16.62.customer.cdi.no) |
| 21:05:41 | | Quit thegeek (Read error: Connection reset by peer) |
| 21:05:42 | | Join rdn [0] (~oop@cpe-69-204-124-212.buffalo.res.rr.com) |
| 21:06:18 | | Quit Nephiel (Ping timeout: 246 seconds) |
| 21:10:57 | saratoga | copper: i guess the clockspeed is reported wrong in plugins? |
| 21:13:28 | saratoga | what is the boosted clock speed on the Fuze+? |
| 21:14:37 | [Saint] | ~450MHz |
| 21:15:14 | [Saint] | maybe plugins expect the clockspeed in Hz? |
| 21:15:30 | [Saint] | the F+ (weirdly) reports in KHz |
| 21:18:03 | copper | no clue |
| 21:18:20 | * | [Saint] thinks he may have solved that riddle. |
| 21:18:39 | [Saint] | That would account for the really low realtime requirement |
| 21:18:48 | saratoga | the fuze+ memory is really slow |
| 21:19:02 | saratoga | copper: feel like doing one more benchmark? |
| 21:19:11 | saratoga | Bagder: around? |
| 21:19:18 | [Saint] | saratoga: you think its KHz vs Hz? |
| 21:19:23 | saratoga | yeah looks like it |
| 21:19:29 | saratoga | the numbers are off by a factor of 1000 |
| 21:19:34 | [Saint] | the debug screen in the F+ reports in KHz |
| 21:19:43 | [Saint] | ..no idea why. |
| 21:19:45 | saratoga | the define is probably wrong on the fuze+ |
| 21:19:54 | TheSeven | SovonHalder: it is in most cases an indicator of rockbox not being able to access the file system at all (or write it), which typically IS rather important |
| 21:20:06 | kugel | lorenzo92: no, where? |
| 21:20:24 | copper | what? |
| 21:20:36 | copper | what numbers are wrong? |
| 21:20:43 | saratoga | can you run the benchmark one more time with the boost option disabled? |
| 21:20:48 | [Saint] | CPU realtime |
| 21:21:01 | copper | uh? |
| 21:21:04 | saratoga | this will mean that the CPU clock is much lower relative to the memory (or equivalently that the memory seems much faster) |
| 21:21:12 | saratoga | i believe there is an option in test_codec to do this |
| 21:21:16 | [Saint] | No idea why such foolishly low numbers didn;t arouse suspicion in me earlier. |
| 21:21:29 | [Saint] | now I look at it, its so improbable I should've caught it. |
| 21:21:30 | copper | cpu real time is within range of the other targets |
| 21:21:48 | [Saint] | 0.01MHz? |
| 21:21:57 | copper | ah |
| 21:21:59 | TheSeven | less than one clock per sample, funny :) |
| 21:22:04 | copper | ithought you meant % |
| 21:22:22 | [Saint] | I *really* should've caught that earlier. |
| 21:22:26 | copper | yes |
| 21:22:29 | copper | I blame you |
| 21:22:36 | [Saint] | that's fair. :) |
| 21:23:13 | copper | saratoga: I'll ping you in about 40 minutes |
| 21:23:27 | saratoga | yeah the numbers are fine, but they're just in units of GHz not MHz :) |
| 21:23:33 | saratoga | ok |
| 21:23:38 | saratoga | also i have Opus files |
| 21:23:48 | saratoga | http://web.mit.edu/mgg6/www/opus/ |
| 21:23:55 | copper | so, * 1000? |
| 21:24:00 | saratoga | i've been trying to get Bagder to upload these for months |
| 21:24:16 | saratoga | yeah, but just do 454/realtime*100 |
| 21:24:27 | copper | wait, what? |
| 21:24:42 | saratoga | MHz = 454/%realtime*100 |
| 21:25:10 | copper | mmmkay? |
| 21:25:20 | saratoga | i can fix that later |
| 21:25:32 | saratoga | i have a script which formats them for the wiki |
| 21:25:35 | saratoga | i can have it do the math itself |
| 21:25:59 | saratoga | anyway since the fuze+ never boosts, the boosted test results are probably misleading |
| 21:26:14 | saratoga | most likely when the CPU is unboosted the memory latency is far lower, and therefore much less cycles are needed |
| 21:26:40 | [Saint] | you can force an unboosted test_codec run, no? |
| 21:26:53 | saratoga | yeah i think its in the test_codec plugin |
| 21:27:00 | saratoga | IIRC i added it years ago |
| 21:27:10 | saratoga | or at least i think i committed that |
| 21:27:14 | saratoga | if its not there then my bad :) |
| 21:27:28 | | Join Nephiel [0] (~5332f9b8@www.haxx.se) |
| 21:28:08 | saratoga | looking at these results though our MDCT lib does really, really badly on modern targets |
| 21:28:15 | saratoga | we definitely over-optimized it for PP |
| 21:29:11 | saratoga | stripwax came up with all these neat math that makes the trig tables small enough to fit into IRAM, but they end up having really irregular access patterns which probably ruins caching on devices without IRAM |
| 21:29:13 | | Quit SovonHalder () |
| 21:29:13 | copper | did you see my Classic and Clip+ results? |
| 21:29:18 | saratoga | yeah i saw them above |
| 21:29:29 | copper | ok |
| 21:29:49 | saratoga | do you have the build numbers? |
| 21:29:54 | saratoga | for the wiki |
| 21:31:23 | copper | 49bcf35 |
| 21:31:53 | saratoga | thanks |
| 21:32:16 | saratoga | damn it forgot that my perl script was converted to ruby at some point |
| 21:32:20 | saratoga | have to figure out how to run that |
| 21:34:06 | | Quit krabador (Ping timeout: 260 seconds) |
| 21:34:10 | | Nick DormantBrain is now known as SuperBrainAK (~andy@shared02.balt01.cd.2g2u.net) |
| 21:37:08 | lorenzo92 | kugel: well there is something bad happening when connecting the usb cable |
| 21:37:37 | lorenzo92 | kugel: i.e. app crashes, for example when doing a screendump or something else that is not a stub in usb_enable |
| 21:38:07 | lorenzo92 | now I have setup the serial, I suspect a concurrency issue or something related (memory issue) |
| 21:40:26 | saratoga | copper: http://www.rockbox.org/wiki/CodecPerformanceComparison#Freescale_i.MX21_40454MHz_ARM926EJ_45S_44_Fuze_43_41 |
| 21:41:41 | copper | nice |
| 21:43:19 | | Join krabador [0] (~krabador_@unaffiliated/krabador) |
| 21:44:00 | lorenzo92 | kugel, pamaury: I confirm, segmentation fault when inserting usb cable and right after doing screendump |
| 21:44:12 | lorenzo92 | on hosted target ypr0 at least... |
| 21:51:05 | saratoga | hmm our ruby script cannot handle comparing some of the old test codec logs to the newer ones |
| 22:00 |
| 22:00:01 | saratoga | according to these tests, vorbis has gotten slower in recent years |
| 22:00:03 | saratoga | i wonder why |
| 22:00:08 | saratoga | on AMSv2 at least |
| 22:00:22 | lorenzo92 | kugel: funny, with debug symbols + logf usb screendump doesn't crash when inserting cable, but when removing it \o/ |
| 22:02:21 | lorenzo92 | also funny that gdb doesn't work now pff |
| 22:06:32 | | Quit Nephiel (Quit: CGI:IRC) |
| 22:07:29 | copper | saratoga: what do you want me to benchmark? |
| 22:07:53 | saratoga | can you grab those Opus files and add them to your folder? |
| 22:08:07 | saratoga | and then repeat the test, but this time set the boost to off so it tests at 64 MHz? |
| 22:08:16 | saratoga | i think there should be an option in test_codec itself to do this |
| 22:10:18 | copper | saratoga: I think you forgot wavpack x4 on the wiki |
| 22:12:22 | saratoga | the ruby scirpt ignores it for some reason |
| 22:14:37 | kugel | lorenzo92: probably too small stack |
| 22:15:04 | lorenzo92 | kugel: hum and what value do you suggest? |
| 22:15:29 | kugel | which thread does the screendump run on? |
| 22:16:00 | lorenzo92 | "usb" |
| 22:16:33 | lorenzo92 | but i'm not sure it's due to small stack |
| 22:16:35 | kugel | try 1MB or so |
| 22:16:39 | lorenzo92 | ok |
| 22:17:13 | saratoga | kugel: did you write the test codec ruby script? |
| 22:17:36 | kugel | yea |
| 22:19:01 | | Quit Raptors (Read error: Connection reset by peer) |
| 22:19:09 | *** | Saving seen data "./dancer.seen" |
| 22:19:12 | saratoga | any idea why it can't parse "wv_normx4.wv" but works with "wv_fastx3.wv" |
| 22:20:24 | lorenzo92 | kugel: interesting, with exactly 1 mb it quits with "Killed"...seems like out of memory |
| 22:21:28 | | Quit y4n (Quit: Assumption is the mother of all fuckups) |
| 22:23:01 | lorenzo92 | kugel: 512k, doesn't get killed at startup, but also crashes |
| 22:24:54 | kugel | hm. can you get the backtrace from gdb? |
| 22:28:17 | copper | saratoga: running new tests now with opus files included, on the Fuze+, Clip+ and iPod Classic |
| 22:28:28 | saratoga | thanks |
| 22:28:30 | copper | I selected boosting=no on the FUze+ and the Classic |
| 22:28:34 | saratoga | nice |
| 22:28:36 | copper | I don't see that option on the Clip+ |
| 22:28:37 | saratoga | those will be interesting |
| 22:28:42 | saratoga | yeah the clip+ has boosting disabled |
| 22:28:53 | saratoga | it was a bit unstable and we never figured out why |
| 22:29:17 | lorenzo92 | kugel: i have gdb running atm, what should i do? |
| 22:29:26 | kugel | lorenzo92: I dont think concurrency is it, thats generally not a problem with out cooperative thread architecture |
| 22:29:30 | copper | ugh, it's a lot slower |
| 22:29:36 | copper | this is going to take ages |
| 22:29:57 | kugel | lorenzo92: get a backtrace when it crashes |
| 22:31:13 | lorenzo92 | kugel: http://pastie.org/private/6fk6heneazyjqcb1511bg |
| 22:31:38 | kugel | that's without debug symbols right? |
| 22:31:51 | kugel | you can look up the addresses in the .map file |
| 22:32:27 | lorenzo92 | yep no symbols |
| 22:33:08 | kugel | you can also try to use arm-*-addr2line to map the addresses to source file lines, but that needs a non-stripped .elf (there should be one in the build dir) |
| 22:34:13 | lorenzo92 | yes there is the elf, i'll give a try, previous addresses don't tell anything interesting |
| 22:34:59 | | Join stripwax [0] (~Miranda@rockbox/developer/stripwax) |
| 22:35:49 | lorenzo92 | kugel: crtstuff.c ? |
| 22:36:43 | kugel | what command did you run? |
| 22:36:59 | lorenzo92 | arm-ypr0-linux-gnueabi-addr2line -e rockbox.elf -a 0x00050624 |
| 22:37:32 | lorenzo92 | ahh |
| 22:37:34 | lorenzo92 | wait |
| 22:37:42 | lorenzo92 | with -f i also get usb_thread |
| 22:37:43 | lorenzo92 | ;) |
| 22:38:30 | kugel | where is crtstuff.c? |
| 22:38:31 | lorenzo92 | kugel: and also queue_wait |
| 22:38:57 | lorenzo92 | kugel: http://pastie.org/private/sjzhpkl8dhnaog77aujlw |
| 22:39:57 | kugel | ah it seems addr2line can't properly map to the source files |
| 22:40:18 | kugel | perhaps it gives a more useful file if run from the top-level folder? |
| 22:42:35 | lorenzo92 | nope, but it might be fine, no? actually queue_wait is used in usb_thread |
| 22:43:43 | kugel | yea but you have to look up the disassembly to find the actual line |
| 22:44:11 | kugel | I dont know how queue_wait can possibly crash. |
| 22:44:36 | | Join Zarggg [0] (~zarggg@24.229.140.62.res-cmts.sm.ptd.net) |
| 22:46:26 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 22:48:44 | | Join tertu [0] (~tertu@65-128-181-81.mpls.qwest.net) |
| 22:55:22 | lorenzo92 | kugel: okay, so it seems that the crash happens right in the first lines, address points to a load instruction |
| 22:58:40 | copper | saratoga: if the Clip+ isn't "boosted", why is it so much faster than the other two? |
| 22:59:05 | copper | or is it boosted and what didn't work was, erm, "unboosting" it? |
| 23:00 |
| 23:00:02 | kugel | lorenzo92: perhaps called with a NULL pointer? |
| 23:00:22 | lorenzo92 | i was thinking the safe, i'll place a temporary panic in case, let's see |
| 23:00:26 | lorenzo92 | *same |
| 23:04:29 | copper | saratoga: Clip+ codec performance log: http://pastebin.com/yHV8c2Gy |
| 23:05:14 | | Quit Strife89 (Ping timeout: 264 seconds) |
| 23:05:18 | copper | the other two are maybe halfway through |
| 23:14:17 | lorenzo92 | kugel: now stops at switch_thread() |
| 23:19:45 | copper | saratoga: opus 128k on the Classic, unboosted: 99.55% real time :-/ |
| 23:24:46 | lorenzo92 | kugel: unfortunately i can't really figure out what's going on atm :( |
| 23:25:27 | lorenzo92 | i only hope it's not a fault that gets undiscovered in native ports.... |
| 23:28:28 | ender` | are there any known problems with USB on Clip Zip in current git version? Windows either reports an error, or doesn't detect the player at all when running rockbox for me |
| 23:32:42 | saratoga | yeah it doesn't seem to be all that stable |
| 23:32:54 | saratoga | copper: that means it'll very rarely boost, which is not too bad |
| 23:33:24 | saratoga | copper: are you doing this tests with or without the DSP effects (hopefully without) |
| 23:33:26 | ender` | ok. is this only a problem in git, or is it the same in stable, too? |
| 23:33:37 | copper | without |
| 23:33:47 | copper | well |
| 23:34:08 | kugel | lorenzo92: can you show how you increased the stack to 512k? |
| 23:34:20 | copper | all DSPs are disabled in the normal Rockbox menus, and I didn't select anything else |
| 23:34:38 | kugel | if it crashes in different places it really looks like a stack overflow |
| 23:34:43 | lorenzo92 | kugel: well now I was running on default stack size...anyway just 512*1024 |
| 23:34:52 | copper | hmm |
| 23:35:20 | lorenzo92 | kugel: wops is a long |
| 23:35:23 | lorenzo92 | ^^ |
| 23:35:40 | kugel | so it was 2MB? |
| 23:35:44 | saratoga | copper: isn't there an option test_codec that asks if you want to benchmark with DSP too? |
| 23:35:45 | lorenzo92 | yep |
| 23:36:04 | lorenzo92 | i forgot the /sizeof(long) |
| 23:36:05 | copper | yes but I didn't select that |
| 23:36:27 | copper | I ran test_codec folder |
| 23:37:14 | lorenzo92 | kugel: but then the question remains the same (not only the song), why the hell if i place a sleep or printf around i may be lucky and it don't get a crash?! |
| 23:38:02 | kugel | dont know |
| 23:38:43 | kugel | lorenzo92: are you sure screendump is called from the ui thread? |
| 23:38:47 | kugel | usb thread* |
| 23:39:17 | kugel | hosted doesn't have screendump so far, for native it's on the usb thread but for sims it's on a separate one |
| 23:39:31 | kugel | now I don't know how you implemented it |
| 23:39:48 | lorenzo92 | yeah, i've just double checked...it's an inline function that calls screen_dump |
| 23:40:06 | lorenzo92 | well actually screen dump works perfectly, there was just a path problem i solved in another patch |
| 23:40:50 | | Join Raptors [0] (~whoneedsa@216-58-33-203.cpe.distributel.net) |
| 23:43:10 | lorenzo92 | kugel: the point is that even if I fill something in usb_enable (to say a system() call or similar), it crashes ... |
| 23:43:54 | kugel | might be OOM, if rockbox claims all memory there's little left for system() |
| 23:44:08 | kugel | remember that systems spawns several processes (at least 2) |
| 23:44:45 | lorenzo92 | pretty sure (i tested it long time ago) that issuing a system() through a menu button perfectly works |
| 23:45:50 | lorenzo92 | or it may be that usb thread is heavy and memory badly managed, who knows... |
| 23:46:44 | kugel | can you do without system()? what are you trying to execute? |
| 23:47:14 | | Quit Raptors (Read error: Connection reset by peer) |
| 23:47:30 | | Join Raptors [0] (~whoneedsa@216-58-33-203.cpe.distributel.net) |
| 23:47:45 | lorenzo92 | forgetting about system(), there is still screendump...anyways I have to call a safe-mode-like script for usb mode |
| 23:49:05 | lorenzo92 | kugel: idea! what if trying to lower memsize a little? |
| 23:49:27 | kugel | try it, you can adjust it in configure |
| 23:49:52 | lorenzo92 | indeed, compiling |
| 23:53:16 | lorenzo92 | kugel: nope, nothing |
| 23:55:25 | | Join jrw_ [0] (~601cd28a@www.haxx.se) |
| 23:57:51 | | Quit jrw_ (Client Quit) |
icon identifies that the person is a core developer (has commit access).