00:00:55 | | Quit ender` (Quit: Who is this General Failure and why is he reading my hard drive?) |
00:11:13 | bluebrother | is there a generic macro that indicates if the target is big endian or little? |
00:11:19 | | Quit Llorean (Quit: Leaving.) |
00:12:42 | * | bluebrother might be able to use __i386__ and __powerpc__ |
00:12:43 | AlexP | JdGordon_: Ta for the fix |
00:13:54 | | Join perfectdrug_ [0] (~marko@p5B0EE4F4.dip.t-dialin.net) |
00:14:18 | saratoga | i'm too lazy to build the exact svn versions right now, but on PP the new mdct is something like 40% faster then the stock one |
00:16:48 | | Join moos [0] (moos@rockbox/staff/moos) |
00:17:27 | | Quit perfectdrug (Ping timeout: 265 seconds) |
00:19:23 | | Quit Zagor (Quit: Clint excited) |
00:24:13 | | Join tmzt_ [0] (~ircuser@99-157-224-139.lightspeed.bcvloh.sbcglobal.net) |
00:26:31 | *** | Saving seen data "./dancer.seen" |
00:34:21 | CIA-5 | New commit by bluebrother (r25160): Make voicefont produce proper files on big endian machines. ... |
00:37:03 | | Quit kugel (Remote host closed the connection) |
00:38:05 | bluebrother | pixelma: my last commit hopefully fixes archos voicefiles on ppc. I'm uploading new rbutil binaries the next couple of minutes. Hope you can confirm it working the next time you get a chance to test :) |
00:46:24 | | Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
00:49:30 | | Quit planetbeing (Ping timeout: 240 seconds) |
00:49:31 | | Nick planetbeing_ is now known as planetbeing (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
00:50:06 | | Quit DataGhost (Ping timeout: 258 seconds) |
00:50:08 | | Quit Casainho (Remote host closed the connection) |
01:00 |
01:05:55 | | Quit CGL (Quit: Saliendo) |
01:10:30 | | Quit Farthen (Ping timeout: 240 seconds) |
01:10:35 | | Quit Schmogel (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
01:11:28 | | Join robin0800 [0] (~quassel@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
01:18:57 | | Quit bertrik (Quit: De groeten) |
01:31:51 | | Part froggyman |
01:31:52 | arbingordon | I kinda missed what the talk about USB audio was about - so in short, is it something like hooking in your PMP, and being able to push the all sound from the OS running on the computer out through USB to the PMP, and have rockbox play it in realtime? |
01:32:35 | arbingordon | (sorry if this is "offtopic") |
01:33:12 | gevaerts | that's more or less it, yes, although more is probably possible |
01:33:37 | saratoga | emailed the tremor mailing list asking what xiph wants for us to upgrade their decoder |
01:34:56 | arbingordon | that's great. would that mean that the computer would still use the internal SPU? it'd be neat to get rid of the low hum that my integrated sound card adds to everything I play. |
01:35:32 | gevaerts | that would depend on the OS you use I guess |
01:35:43 | * | gevaerts doesn't know the details there |
01:35:50 | saratoga | depends what you mean by "SPU" |
01:36:08 | saratoga | but hum is an analog effect, which does not occur in digital interfaces like USB |
01:43:07 | | Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) |
01:46:30 | | Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
01:48:30 | | Quit planetbeing (Ping timeout: 240 seconds) |
01:48:30 | | Nick planetbeing_ is now known as planetbeing (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
01:49:35 | | Quit robin0800 (Remote host closed the connection) |
01:59:19 | pamaury | Hum, either iso transfers are resulting in garbage, either the audio format is not the one I guess ... |
02:00 |
02:06:49 | pamaury | Does there exist different variant of PCM ? |
02:07:38 | arbingordon | you mean like ADPCM? |
02:08:48 | pamaury | I don't know, it's just that if I take the PCM data that usb audio is streaming and put it in a WAV file, then the output is weird |
02:09:09 | pamaury | So it's not exactly PCM data, there is a trick somewhere |
02:12:37 | | Quit karashata (Quit: The fluffy dragon has left completely!) |
02:13:18 | saratoga | pamaury: theres dozens of combinations of plain PCM |
02:13:49 | saratoga | like 8 bit, 16 bit, 24 bit, big endian, little endian, stereo, mono, etc |
02:13:52 | pamaury | Then could someone help understand the one used by usb audio ? The spec says: |
02:13:53 | pamaury | The PCM (Pulse Coded Modulation) format is the most commonly used audio format to represent audio data streams. The audio data is not compressed and uses a signed two’s-complement fixed point format. It is left-justified (the sign bit is the Msb) and data is padded with trailing zeros to fill the remaining unused bits of the subframe. The binary point is located to the right of the sign bit so that all values lie within the range [-1,+1). |
02:14:38 | saratoga | dump it to a file and try playing with sox |
02:14:50 | saratoga | should only take a few guesses if you know its stereo with a given sampling rate |
02:15:26 | pamaury | what is sox ? |
02:15:39 | saratoga | standard tool for converting raw pcm to wav |
02:15:44 | saratoga | runs on windows/linux |
02:15:52 | saratoga | i use it for debugging codecs |
02:16:33 | | Join ArmandiuxGS [0] (~Armando@200.79.236.202.cable.dyn.cableonline.com.mx) |
02:16:38 | pamaury | ok, thanks |
02:17:21 | ArmandiuxGS | oh, excuse me guys, I have a little problem with my iPod Nano 2G... |
02:21:22 | ArmandiuxGS | When I play music and I start the fft plugin (or another plugin, maybe), I see a "Noise Like" video distortion in the screen, and a Error Message appear: Prefetch abort ... at 080002FC ... FSR 0x3FF ... (domain 15, fault 15). |
02:22:00 | saratoga | which plugins exactly? |
02:22:01 | | Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
02:22:29 | ArmandiuxGS | FFT |
02:23:40 | saratoga | i would file a bug report if theres not already one for that plugin |
02:25:28 | | Join FlynDice [0] (~FlynDice@74.10.105.233) |
02:25:33 | ArmandiuxGS | I was playing a '.ogg' file with loudest volume |
02:26:34 | *** | Saving seen data "./dancer.seen" |
02:28:43 | ArmandiuxGS | forget it, I'll try to install the current build (r25160) |
02:29:08 | saratoga | generally if you're not running a current build we don't want to hear about problems :) |
02:30:49 | pamaury | saratoga: on which things can I play to try to find the right format ? I know it's stereo (normally !) at 44100Hz (normally !) |
02:31:08 | saratoga | endianness and number of bits probably |
02:32:03 | saratoga | check out the sox switches, but −−bits and −−encoding are likely to be worth looking at |
02:32:12 | pamaury | I also now it's 16-bit per sample (well that's what I specified) |
02:32:30 | saratoga | something like sox −−rate 44100 -c 2 −−bits 16 -s in.raw out.wav |
02:34:14 | saratoga | i think that should be right for 16 bit signed integer at 44100 Hz with stereo |
02:34:44 | pamaury | That's what I tried and that's not great ! |
02:35:04 | saratoga | whats it sound like? |
02:40:39 | pamaury | I can recognize the sound (partially) but it's noisy and saturated |
02:41:27 | saratoga | endianess might be wrong |
02:41:30 | ArmandiuxGS | Why when I play music, some plugins (demos), which use much rendering, are constantly slow or fast? |
02:41:38 | saratoga | or it may actually be a padded 24 or 32 bit sample format |
02:42:13 | saratoga | ArmandiuxGS: probably because the CPU clock on your nano keeps changing and those plugins haven't been fixed to work with it yet |
02:42:38 | ArmandiuxGS | OMG!, a Message Error: Undefined instruction at 09F8029C |
02:42:40 | pamaury | saratoga: I requested 16-bit per sample so normally this is right but perhaps it's padded and it's less 16-bit in reality. |
02:42:51 | linuxstb | pamaury: So are you playing audio from a PC, and recording it in Rockbox? |
02:43:24 | pamaury | I'm playing with a PC and my usb code write raw data to a file because the output is not good, or the format is wrong |
02:44:04 | linuxstb | That's what I mean. So can't you compare the dumped data with the original PCM data from the PC? |
02:44:59 | saratoga | i suppose plotting a couple hundred samples would immediately make it clear if the format is wrong |
02:45:02 | linuxstb | Or create a test file with easy to spot values - e.g. 0x1234 for the left channel, 0x5678 for the right |
02:45:32 | pamaury | Hum, I think I will try this |
02:45:43 | pamaury | Easy way to generate this or by hand (program) ? |
02:46:00 | saratoga | matlab makes it pretty easy if you've got that |
02:46:05 | pamaury | no |
02:46:06 | linuxstb | I would write a little C program to create the raw PCM file, then sox to convert to wav. |
02:46:16 | ArmandiuxGS | Where I can get help for this issue? |
02:46:21 | saratoga | or just play a mono file |
02:46:47 | saratoga | ArmandiuxGS: if you want help you should document the problem and file a bug report |
02:47:25 | ArmandiuxGS | I dont know how I can make it. |
02:47:27 | | Join planetbeing__ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
02:47:39 | saratoga | theres a bug link on the left side of the front page |
02:48:01 | saratoga | i wonder if the xiph people will be receptive of my proposal to drop the stupid low accuracy mode in tremor |
02:48:54 | | Quit planetbeing (Ping timeout: 252 seconds) |
02:48:54 | | Nick planetbeing__ is now known as planetbeing (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
02:48:54 | | Nick planetbeing is now known as 30BAACDCE (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
02:48:54 | | Nick planetbeing_ is now known as planetbeing (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
02:49:30 | | Join Lss [0] (~Lss@cm48.omega219.maxonline.com.sg) |
02:50:58 | ArmandiuxGS | I do not know what kind of bug is. |
02:51:23 | saratoga | i think you said it was a problem with plugins |
02:51:54 | saratoga | if not pick the one that looks closest to whatever it was that didn't work, someone will fix it if you're completely wrong |
02:56:34 | ArmandiuxGS | Thank you saratoga |
02:56:52 | ArmandiuxGS | I will try to make a task. |
02:57:03 | | Quit planetbeing (Ping timeout: 276 seconds) |
02:57:57 | ArmandiuxGS | What would be the appropriate title? |
02:59:29 | ArmandiuxGS | "Undefined instruction"? |
03:00 |
03:00:09 | pamaury | saratoga: hum, with 0x1234 one channel and 0x5678 I get the same thing on output except that there are a few glitches here and there and that I can hear them... |
03:01:29 | pamaury | So perhaps the problem is due to n |
03:01:44 | pamaury | unreliable iso code, I will invistage further tomorrow |
03:03:31 | | Quit pamaury (Quit: Page closed) |
03:03:51 | ArmandiuxGS | wtf... |
03:03:52 | | Part ArmandiuxGS ("Saliendo") |
03:09:37 | | Quit Barahir (Ping timeout: 258 seconds) |
03:10:26 | | Join Barahir [0] (~jonathan@gssn-5f755d16.pool.mediaWays.net) |
03:10:49 | | Join planetbeing [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
03:29:34 | | Quit 30BAACDCE (Quit: 30BAACDCE) |
03:35:13 | S_a_i_n_t | Just for the record, Nano2g bootloader (r25139) is broken in some way...hangs on the "Apple" scrren indefinitely. |
03:35:43 | S_a_i_n_t | Though crypt_firmware works again. Yay! which gave me a false sense of security. |
03:36:51 | S_a_i_n_t | Its still good to be able to pass a broken bootloader through a working encryptor :P |
03:39:49 | | Quit Adubb (Read error: Connection reset by peer) |
03:39:59 | | Join Adubb [0] (~aldubuc@xplr-ts-t11-208-114-159-122.barrettxplore.com) |
03:47:14 | | Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
03:57:08 | | Quit planetbeing_ (Quit: planetbeing_) |
04:00 |
04:06:41 | | Quit perfectdrug_ (Read error: Connection reset by peer) |
04:16:30 | | Quit Barahir (Ping timeout: 318 seconds) |
04:17:00 | | Quit Adubb (Read error: Connection reset by peer) |
04:18:48 | | Join Adubb [0] (~aldubuc@xplr-ts-t11-208-114-159-122.barrettxplore.com) |
04:19:46 | | Quit YPSY (Ping timeout: 316 seconds) |
04:20:02 | | Join Ypsy [0] (~ypsy@geekpadawan.de) |
04:20:17 | | Nick Ypsy is now known as YPSY (~ypsy@geekpadawan.de) |
04:21:56 | | Quit Adubb (Read error: Connection reset by peer) |
04:26:37 | *** | Saving seen data "./dancer.seen" |
04:30:06 | | Join Adubb [0] (~aldubuc@xplr-ts-t11-208-114-159-122.barrettxplore.com) |
04:34:20 | | Quit Adubb (Read error: Connection reset by peer) |
04:37:23 | | Quit TheSeven (Disconnected by services) |
04:37:37 | | Join The_Seven [0] (~theseven@rockbox/developer/TheSeven) |
04:37:50 | | Nick The_Seven is now known as TheSeven (~theseven@rockbox/developer/TheSeven) |
04:40:36 | | Join Adubb [0] (~aldubuc@xplr-ts-t11-208-114-159-122.barrettxplore.com) |
04:45:23 | | Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
05:00 |
05:22:12 | | Quit Llorean (Quit: Leaving.) |
05:26:54 | | Join Zarggg [0] (~zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) |
05:34:17 | | Quit Zarggg (Quit: Zarggg) |
05:36:56 | | Join Zarggg [0] (~zarggg@2001:0:4137:9e74:0:fbe6:beb1:ba3d) |
05:39:59 | | Quit saratoga (Quit: Page closed) |
05:40:28 | | Quit anewuser () |
05:42:53 | | Quit Zarggg (Quit: Zarggg) |
05:45:32 | | Join Zarggg [0] (~zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) |
05:46:57 | | Quit planetbeing (Read error: Connection reset by peer) |
05:46:58 | | Join planetbeing__ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
05:46:58 | | Nick planetbeing__ is now known as planetbeing (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
05:47:03 | | Join planetbeing__ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
05:48:24 | | Quit JdGordon_ (Ping timeout: 265 seconds) |
05:48:37 | | Quit JdGordon (Ping timeout: 268 seconds) |
05:50:09 | | Quit planetbeing_ (Ping timeout: 264 seconds) |
05:52:57 | | Join Rob2223 [0] (~Miranda@p4FDC922F.dip.t-dialin.net) |
05:53:15 | | Join froggyman [0] (~sopgenort@pool-72-69-76-103.chi01.dsl-w.verizon.net) |
05:56:22 | | Quit Rob2222 (Ping timeout: 265 seconds) |
06:00 |
06:02:49 | | Join Llorean [0] (~DarkkOne@adsl-99-158-46-229.dsl.hstntx.sbcglobal.net) |
06:02:49 | | Quit Llorean (Changing host) |
06:02:49 | | Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) |
06:10:33 | | Join Barahir [0] (~jonathan@gssn-5f7541e0.pool.mediaWays.net) |
06:15:34 | | Quit GeekShadow (Ping timeout: 240 seconds) |
06:25:28 | | Part froggyman |
06:26:05 | | Join froggyman [0] (~sopgenort@pool-72-69-76-103.chi01.dsl-w.verizon.net) |
06:26:39 | *** | Saving seen data "./dancer.seen" |
06:26:59 | S_a_i_n_t | Anyone around with an accurate understanding of the %Sx tag? |
06:27:15 | S_a_i_n_t | *(it's "translate X string) |
06:38:52 | | Join JdGordon [0] (~jonno@110.22.141.16) |
06:41:05 | CIA-5 | New commit by uchida (r25161): wave metadata parser reduces binsize. |
06:41:32 | S_a_i_n_t | I'm wondering if two strings can be translated in the same conditional, ie. would %?ia<%ia|%Sx|Artist|: |%Sx|Unknown> display "Artist: Unknown" (assuming there are no id3 tags) in the appropriate language if the strings Artist and Unknown are both present? |
06:42:39 | S_a_i_n_t | errr... %?ia<%ia|%Sx|Artist|: |%Sx|Unknown|> rather. |
06:45:55 | | Join karashata [0] (~karashata@74-220-162-11.wightman.ca) |
06:47:01 | | Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
06:47:01 | | Quit planetbeing (Read error: Connection reset by peer) |
06:47:01 | | Nick planetbeing_ is now known as planetbeing (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
06:47:07 | | Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
06:51:40 | S_a_i_n_t | Or would it be: %?ia<%ia|%Sx|Artist|: %Sx|Unknown|> ? I *think* the syntax is correct, assuming both Album and Unknown are translated strings...but I'd really like to talk to someone who has used the tag before, or preferably the author of it ( JdGordon? ). |
06:51:40 | S_a_i_n_t | I've yet to see an example that translates two strings at once...so I wonder if it's even possible. |
06:51:40 | | Quit planetbeing__ (Ping timeout: 264 seconds) |
06:51:40 | JdGordon | Why wouldn't that work? |
06:51:40 | S_a_i_n_t | I'm not sure...so I guess that means "it *should* work?". I've only ever seen one string translated per conditional...so I thought there may have been a reason for that. |
06:53:24 | JdGordon | Sx is an ordinary tag. |
06:54:33 | S_a_i_n_t | sweet, it's just that the added |'s make the syntax look really crazy. |
06:55:26 | JdGordon | Yes |
07:00 |
07:02:30 | | Join JdGordon1 [0] (~jonno@123-243-140-31.static.tpgi.com.au) |
07:03:09 | | Quit karashata (Quit: The fluffy dragon has left completely!) |
07:05:12 | | Join karashata [0] (~karashata@74-220-162-11.wightman.ca) |
07:15:48 | | Join Horschti [0] (~Horscht2@xbmc/user/horscht) |
07:17:19 | | Quit Horscht (Ping timeout: 265 seconds) |
07:20:18 | | Join Farthen [0] (~chatzilla@e179232024.adsl.alicedsl.de) |
07:47:27 | | Join planetbeing__ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
07:50:39 | | Quit planetbeing (Ping timeout: 260 seconds) |
07:50:39 | | Nick planetbeing__ is now known as planetbeing (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
07:51:35 | | Join HatchlingByHeart [0] (~Hatchling@203.122.224.63) |
07:51:46 | HatchlingByHeart | hello? |
07:53:35 | HatchlingByHeart | can anyone tell me if there's any plans for supporting the 6th gen iPod? |
07:53:47 | HatchlingByHeart | I couldn't find anything in the FAQs |
07:53:51 | JdGordon1 | we dont make plans for future targets |
07:53:55 | S_a_i_n_t | plans...yes, probaly. |
07:54:01 | JdGordon1 | if it happens, it happens |
07:54:02 | S_a_i_n_t | will it happen any time soon? |
07:54:04 | S_a_i_n_t | no. |
07:54:35 | HatchlingByHeart | damn. I just bought a 6th gen 160GB iPod and I like the look of Rockbox |
07:54:52 | HatchlingByHeart | the utility told me mine is unsupported T_T |
07:55:28 | S_a_i_n_t | the main page would have told you that also. |
07:56:06 | HatchlingByHeart | oh... 5.5g - 1g... how'd I miss that? o.o |
07:57:01 | HatchlingByHeart | well, thanks for your help guys |
07:57:03 | HatchlingByHeart | cya |
07:57:11 | | Part HatchlingByHeart |
07:57:24 | | Quit karashata (Quit: The fluffy dragon has left completely!) |
07:58:12 | | Join CGL [0] (~CGL@190.79.151.231) |
08:00 |
08:10:58 | | Quit arbingordon (Quit: `) |
08:13:55 | | Join arbingordon [0] (~w@c-71-226-248-30.hsd1.pa.comcast.net) |
08:15:33 | | Join r0b- [0] (~nnscript@adsl-69-208-80-81.dsl.klmzmi.ameritech.net) |
08:15:44 | r0b- | are the e200v2's now FULLY supported? |
08:15:59 | | Quit froggyman (Quit: froggyman) |
08:17:12 | | Quit JdGordon (Quit: Bye) |
08:19:10 | | Quit panni_ (Read error: Connection reset by peer) |
08:26:40 | *** | Saving seen data "./dancer.seen" |
08:45:27 | | Quit JdGordon1 (Read error: Connection reset by peer) |
08:45:57 | S_a_i_n_t | r0b-: the main page lists them as stable...if that's what you mean. |
08:46:56 | * | S_a_i_n_t has forgotten how to build the fontpack again... make "insertwhatnow?" |
08:47:37 | | Quit planetbeing (Quit: planetbeing) |
08:47:37 | | Nick planetbeing_ is now known as planetbeing (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
09:00 |
09:00:29 | | Join stoffel [0] (~quassel@p57B4C645.dip.t-dialin.net) |
09:07:59 | | Quit CGL (Quit: Saliendo) |
09:08:04 | | Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) |
09:33:01 | | Join Highlander [0] (~Highlande@mek33-4-82-236-45-205.fbx.proxad.net) |
09:41:39 | | Join JdGordon_ [0] (~user@123-243-140-31.static.tpgi.com.au) |
09:41:45 | | Quit JdGordon_ (Changing host) |
09:41:45 | | Join JdGordon_ [0] (~user@rockbox/developer/JdGordon) |
09:50:30 | | Quit CaptainKewl (Remote host closed the connection) |
09:55:19 | | Quit JdGordon_ (Quit: JdGordon_) |
09:57:38 | | Quit kaniini (Ping timeout: 245 seconds) |
10:00 |
10:03:00 | | Join flyasky [0] (~anton@79-223-113-92.pool.ukrtel.net) |
10:03:12 | flyasky | hi! |
10:04:02 | flyasky | I have VoiceRecorder Samsung YV-150 - will rockbox work on it? |
10:05:37 | S_a_i_n_t | flyasky: Is it on the Roclbox main page? |
10:06:44 | flyasky | no ( |
10:07:31 | S_a_i_n_t | right, sorry that was a bit blunt. But it answers your question. |
10:08:04 | S_a_i_n_t | There's a "New Ports" page on the Wiki however used to get a new project started. |
10:08:20 | S_a_i_n_t | Or to try to gain interest in starting a new port rather. |
10:08:25 | | Join ender` [0] (krneki@foo.eternallybored.org) |
10:08:41 | flyasky | are they compatible in core? I want try to port to YV-150 |
10:11:20 | pixelma | you need to find out a lot about your device (hardware components, how to upload your own firmware etc.) if you want to port Rockbox and it's impossible without all this info to say how easy a port would be |
10:11:36 | S_a_i_n_t | I know *nothing* about the target in question...but I can offer you this: |
10:11:38 | S_a_i_n_t | http://www.rockbox.org/wiki/NewPort |
10:12:37 | pixelma | it's always a lot of work, but a few ports were easier because code to use certain components was already around |
10:18:28 | | Quit r0b- (Ping timeout: 245 seconds) |
10:19:26 | | Join r0b- [0] (~nnscript@adsl-69-208-80-81.dsl.klmzmi.ameritech.net) |
10:19:45 | | Quit moos (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158]) |
10:22:32 | | Quit JdGordon (Read error: Connection timed out) |
10:23:18 | | Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) |
10:26:16 | | Join kaniini [0] (~quassel@dyn75-70.yok.fi) |
10:26:42 | *** | Saving seen data "./dancer.seen" |
10:32:49 | | Join bmbl [0] (~Miranda@unaffiliated/bmbl) |
10:33:01 | | Quit tmzt_ (Read error: Connection reset by peer) |
10:33:05 | | Join tmzt_ [0] (~ircuser@99-157-224-139.lightspeed.bcvloh.sbcglobal.net) |
10:35:33 | | Quit S_a_i_n_t () |
10:35:50 | | Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.127) |
10:49:49 | | Join yuanxu [0] (yuanxu@210.76.197.24) |
10:52:14 | | Quit S_a_i_n_t () |
10:52:36 | | Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.127) |
10:52:48 | | Quit yuanxu () |
11:00 |
11:05:40 | | Join Casainho [0] (~chatzilla@bl15-104-228.dsl.telepac.pt) |
11:12:41 | | Quit S_a_i_n_t () |
11:14:02 | | Join JdGordon_ [0] (~user@123-243-140-31.static.tpgi.com.au) |
11:14:02 | | Quit JdGordon_ (Changing host) |
11:14:02 | | Join JdGordon_ [0] (~user@rockbox/developer/JdGordon) |
11:14:34 | JdGordon | pixelma: with the fm patch, does the buttons in the wps all work fine? |
11:15:58 | | Quit flyasky (Ping timeout: 245 seconds) |
11:16:23 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
11:16:51 | | Quit planetbeing (Quit: Poof.) |
11:19:23 | | Join JdGordon1 [0] (~jonno@123-243-140-31.static.tpgi.com.au) |
11:20:14 | pixelma | well, the buttons work fine. Everything still hangs though when I want to exit the radio screen, with yesterday's patch (which I think is the "latest" :\ ). AlexP was able to reproduce a hanging sim when entering the radio screen with a simple test.fms (containing %Tn or %Tf), set through the menu |
11:20:54 | pixelma | my test was on my M5 |
11:22:35 | | Quit JdGordon (Ping timeout: 265 seconds) |
11:25:54 | | Quit JdGordon_ (Read error: Connection reset by peer) |
11:29:58 | | Join Lear [0] (chatzilla@rockbox/developer/lear) |
11:33:08 | | Join Barahir_ [0] (~jonathan@gssn-5f755f1b.pool.mediaWays.net) |
11:36:30 | | Quit Barahir (Ping timeout: 258 seconds) |
11:36:44 | JdGordon1 | pixelma: was it you that asked why cabbiv2.fms was being loaded? |
11:38:19 | pixelma | no, AlexP was |
11:38:43 | JdGordon1 | or whoever asked... its because thats the default one |
11:40:11 | | Join stooo [0] (~sto@e179207097.adsl.alicedsl.de) |
11:41:06 | | Part stooo |
11:47:42 | JdGordon1 | haha, I found the hang AlexP hit |
11:49:28 | | Quit JdGordon1 (Read error: Connection timed out) |
11:50:01 | | Join stooo [0] (~sto@e179207097.adsl.alicedsl.de) |
11:50:23 | | Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) |
11:53:09 | | Join flyasky [0] (~anton@88-238-113-92.pool.ukrtel.net) |
11:54:25 | pixelma | I'm running out of ideas what to test for and which could help finding out what happens, but I get the effect on all my three targets |
11:56:17 | flyasky | thank you! I'll read first - when ask again ) |
12:00 |
12:02:33 | | Quit stooo (Quit: Leaving.) |
12:04:36 | | Quit bzed (Remote host closed the connection) |
12:04:53 | | Join bzed [0] (~bzed@devel.recluse.de) |
12:06:39 | | Quit chaos (Ping timeout: 248 seconds) |
12:06:39 | | Quit ps-auxw (Ping timeout: 248 seconds) |
12:07:44 | | Join chaos [0] (~chaos@gentoo/user/ch4os) |
12:09:02 | | Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) |
12:12:08 | | Join S_a_i_n_t [0] (S_a_i_n_t@203.184.1.125) |
12:23:10 | pixelma | JdGordon: looks like it has something to do with th %Tn tag alone in the test fms (not using the "latest" patch though). I now put it in a %?tt<%Tn|> and it doesn't hang anymore |
12:24:41 | pixelma | but %Tn shows up very seldom, even though it sounds like the station is tuned (I'm currently in preset mode and the fmr is correct) |
12:25:26 | pixelma | still testing with the M5 |
12:25:51 | AlexP | pixelma: I thought about that, but also got the m5 sim hang with %Tf alone, which really should be possible - people might just want a big frequency and nothing else |
12:26:33 | pixelma | AlexP: JdGordon put a new patch u which supposedly fixes that |
12:26:41 | AlexP | Ah, OK |
12:26:42 | pixelma | up too |
12:26:46 | *** | Saving seen data "./dancer.seen" |
12:28:15 | pixelma | Tf also has to do with a preset, tf is the current frequency, or did that change? |
12:29:24 | pixelma | I think you can use it for a "next/previous station list" IIUC |
12:29:36 | pixelma | Tf that is |
12:30:05 | AlexP | Ah right |
12:30:15 | AlexP | I can't rememeber off the top of my head |
12:30:40 | | Quit JdGordon (Read error: Connection timed out) |
12:32:05 | CIA-5 | New commit by jdgordon (r25162): fiddle with the skin debug output so the load lines arnt shown unless debugwps is enabled |
12:32:17 | | Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) |
12:33:31 | | Join CFP [0] (~Create@ip-247.net-81-220-136.rev.numericable.fr) |
12:34:23 | | Quit CFP (Client Quit) |
12:35:10 | pixelma | I'm sure the station name shows up more often with SVN (and goes away when not tuned, e.g. in scan mode) |
12:36:21 | pixelma | I'll need an SVN build for comparison |
12:39:05 | pixelma | and I'd really appreciate version numbers for the radio skin patches, more accuracy when you talk about it and easier to keep old versions around |
12:39:24 | AlexP | The station name shows up when it should in the patch for H100/S |
12:39:35 | AlexP | actually, make that I think |
12:39:44 | pixelma | inside an %?tt ? |
12:39:47 | AlexP | In fact, forget that, I'd need to check :) |
12:41:56 | pixelma | well, it shows up fine without the %tt bit but then I get the freezed |
12:42:07 | pixelma | or freezes |
12:42:18 | | Quit ps-auxw (Quit: leaving) |
12:42:23 | AlexP | So what is the remaining issue? A fms with %Tn \n %tf seems to work fine in the m5 sim |
12:43:02 | | Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) |
12:44:04 | JdGordon | it needs a bigger buffer first, so probably the resigin patch, and the hwcodec issues |
12:44:11 | pixelma | even if it works now, my gripe would still be that it can't show the recording info on hwcodec targets which record radio from the radio screen as SVN does |
12:44:26 | JdGordon | it has the tags to do it |
12:44:45 | JdGordon | its even setup forr the hard coded to do it |
12:44:49 | AlexP | JdGordon: What is the status of the resizing patch? |
12:45:05 | JdGordon | kugel said he is having some wierdness with it |
12:45:09 | pixelma | JdGordon: no, you can't show the peakmeter conditionally |
12:45:59 | JdGordon | I'd be happy to just increase the buffer size to get this in untill the resize patch is finished |
12:46:27 | pixelma | and I'm not sure - does the prerecording time count up as the buffer fills? I imagine with the patch it would just show the set value (I could be wrong though) |
12:46:27 | JdGordon | pixelma: that is a seperate issue |
12:46:50 | JdGordon | it should display everythign exactly as svn apaprt from the bars |
12:46:53 | pixelma | not, if you say "it's the same as SVN" |
12:47:08 | pixelma | minus the comma |
12:47:47 | JdGordon | making the peak meters work conditionally is not a small change |
12:48:17 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
12:48:17 | JdGordon | it would pretty much involve rewriting the pm handling, which isnt necessarily a bad thing |
12:48:46 | AlexP | JdGordon: I'd be fine with resizing the buffer a bit for now - on greyscale it is currently tiny |
12:50:54 | pixelma | you'll not see the prerecording time info with the hardcoded fms now anyway due to the pm issue - it does not look the same as SVN currently anyways (and I remember finding one difference annoying, but have to look at the hardcoded one once more) |
12:51:04 | | Join JdGordon1 [0] (~jonno@123-243-140-31.static.tpgi.com.au) |
12:51:15 | | Quit JdGordon (Read error: No route to host) |
12:52:54 | JdGordon1 | anyway, I think that should happen, and it sholdnt be required for fm skin once the rest is working fine |
12:55:00 | soap | scorche, is there a plugin or module for SMF which prevents user editing of forum posts after it as been replied to? |
12:55:35 | soap | It's only an occasional problem on the forums, but HA.org introduced said feature a few months ago and it has been nothing but good there. |
12:56:39 | JdGordon1 | there are legit reasons to edit a replied to post thoguh |
12:57:01 | JdGordon1 | like "this whole post was wrong, removing to not make more people stupid" |
12:57:02 | | Join pamaury [0] (~c2c7a50a@rockbox/developer/pamaury) |
12:57:09 | S_a_i_n_t | I agree, but not really after its been replied to. |
12:57:18 | S_a_i_n_t | couldn't you just remove it in that case? |
12:57:20 | linuxstb | How do you know a post was replied to? All you know is that there was another post in the same thread. |
12:57:22 | AlexP | I often edit my own after it has been replied to to correct spelling :) |
12:57:37 | S_a_i_n_t | AlexP: Spellcheck :P |
12:57:38 | pixelma | JdGordon1: like editing the original bug report after a part has been fixed? :\ |
12:57:50 | AlexP | S_a_i_n_t: Doesn't get everything |
12:57:56 | pixelma | when it actually wasnt |
12:58:09 | soap | Removal of replied-to posts seems like a perfect action for the staff to take care of. Retractment of statements seems to be a bad idea unless you're trashing the whole thread. |
12:58:25 | JdGordon1 | if your being subtle about a not fixed bug then either out with it or dont bother... because i have no idea what your talking about |
12:58:55 | AlexP | I don't actually mind either way, but it isn't really a problem on our problems at the moment I don't think |
12:58:57 | soap | bug reports go in the tracker, regardless, so that point is moot. |
12:59:58 | soap | AlexP, I agree it is not a large problem by any sense of the imagination - but the "fix" appeared to have no negative side effects on HA, so why not do it if it is just as seamless on SMF? |
12:59:59 | pixelma | JdGordon1: no, it's fixed now and some time ago. But I remember you editing the original report and removing unfixed things |
13:00 |
13:00:24 | pixelma | I could never understand why you edited the original post |
13:00:26 | AlexP | soap: Sure - I'm not objecting at all - I just can't be bothered to investigate it myself :) |
13:00:55 | AlexP | As long as it only affects the users and I can still edit mine afterwards :) |
13:10:01 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
13:22:19 | JdGordon1 | pixelma: have you tried putting %pm inside a conditional viewport? |
13:23:48 | pixelma | that would probably work but then you get font size "dependencies" |
13:24:10 | JdGordon1 | yes |
13:25:51 | pixelma | maybe the most flexible you could do there is putting these viewports at the bottom and work with negative positions (never tried yet) |
13:27:15 | JdGordon1 | I have no idea how to put %pb inside a conditional in a way that makes sense |
13:27:43 | pixelma | huh? |
13:28:11 | JdGordon1 | from the code POV... i can see plenty of reasons why being able to do that would be cool |
13:30:41 | TheSeven | liar: did you have a chance to test my latest commit? |
13:31:27 | pixelma | JdGordon1: I thought we were talking about the peakmeters (%pm), but IIRC %pb needs to be on its own line too. But then - how does the current radio screen do it? |
13:32:11 | JdGordon1 | yes, sorry, pm |
13:33:50 | liar | TheSeven: r25162 works fine |
13:34:12 | liar | oh sorry |
13:34:13 | liar | it doesnt |
13:34:29 | liar | TheSeven: FTL: scheduling bank ... |
13:35:34 | TheSeven | and the version before (r25156) is fine? |
13:36:29 | liar | iirc r25154 is the last good one, ill try r25156 |
13:41:54 | liar | TheSeven: r25156 works fine |
13:43:28 | CIA-5 | New commit by theseven (r25163): More detailed panic message for Nano2G VFL fast read problems |
13:48:18 | | Quit Adubb (Read error: Connection reset by peer) |
13:48:30 | | Join Adubb [0] (~aldubuc@xplr-ts-t11-208-114-159-122.barrettxplore.com) |
13:50:05 | | Join Buschel [0] (~ab@p54A3CAAC.dip.t-dialin.net) |
13:50:18 | Buschel | Lear: you there? |
13:50:26 | Lear | Yep. |
13:50:36 | Buschel | perfect :o) |
13:50:57 | liar | TheSeven: VFL fast read failed, RC 0000, bank 1, RET 100, base 903180 |
13:51:22 | Buschel | Saw your bug report reagrding mpc resume. The nug eas not introduced with the sv8 library... |
13:51:37 | Lear | Nope. |
13:51:44 | Buschel | And it seems aac and alac use it the same way... |
13:52:04 | Lear | They do? |
13:52:31 | Lear | I'm pretty sure AAC doesn't... |
13:52:55 | liar | TheSeven: VFL fast read failed, RC 0000, bank 2, RET 100, base 1600520 for a different trak |
13:53:16 | Buschel | Sorry, it saves the position via set_offset(elapsed_time) |
13:53:25 | Lear | Hm, elapsed time for set_offset looks wrong... |
13:53:25 | Buschel | which is not correct either |
13:53:51 | Lear | It seemed to work fine when I implemented the raw seek though. |
13:54:21 | | Join m3dlg [0] (~m3dlg@bb-87-81-252-83.ukonline.co.uk) |
13:55:07 | Lear | And the use of "sound_samples_done" in the initial seek is just a question of re-using another variable. Probably not worth the confusion it can cause. :) |
13:56:13 | Buschel | Lear: can you review / test this mpc patch? -> http://www.pastebin.org/112486 |
13:56:18 | Buschel | works for me |
14:00 |
14:01:04 | Lear | Looks reasonable... But file offset is known, so that would be better to save, wouldn't it? |
14:07:11 | S_a_i_n_t | JdGordon1: Is there a way the "playlist viewer" can have the offset set as "current track +1"? or *could* there be? |
14:07:32 | S_a_i_n_t | I figure then you could have "next AA" displayed consistently...no? |
14:09:03 | JdGordon1 | the offset is the offset |
14:09:10 | JdGordon1 | 1 will always be the next track |
14:09:18 | JdGordon1 | 2 is always the track after next |
14:09:29 | JdGordon1 | you cant display the next AA currently |
14:09:51 | S_a_i_n_t | ah..shit..there's that plan. |
14:10:01 | Buschel | Lear: just saving ci->curpos? |
14:10:03 | S_a_i_n_t | Oh well :D |
14:11:40 | S_a_i_n_t | Next AA is pretty big on my list, as well as a few other peoples I imagine. You ticked off number 1 on that list for me (multifont), so I guess I should be more patient :P |
14:12:48 | * | JdGordon1 is good at ticking people off :p |
14:13:09 | S_a_i_n_t | Number 2 would probably be userfont splashes...or bitmap scrollbars. |
14:13:38 | | Quit m3dlg (Ping timeout: 268 seconds) |
14:13:43 | * | S_a_i_n_t can't decide between those two...err, whichever's easier to implement :P |
14:13:49 | | Quit Tomis (Quit: Tomis) |
14:14:41 | Lear | Buschel: I don't think you really need to save that. E.g., the mp3 codec doesn't do that, since it doesn't do any internal buffering (that I know of). |
14:14:59 | Lear | Vorbis probably does, so it calls raw_tell. |
14:15:26 | Buschel | Lear: If I remove the call of set_offset it does not resume at all... |
14:15:51 | pamaury | gevaerts: I will soon create FS task for my usbaudio work. Do you think I should also put the test code I use for iso transfers or should I only put the usb audio one ? Or both put in different patches (I don't like this option because I'll do the manual splitting). The test drivers allows to send lots of OUT transfers and check for CRC, do some debug and statistics (there is rockbox code+linux code that uses libusb) |
14:17:03 | gevaerts | pamaury: test code is useful I guess |
14:18:43 | | Join Tomis [0] (~Tomis@70.134.64.117) |
14:18:53 | Buschel | Lear: seems like this is because mpc does not use/call ci->advance_buffer as all this low level stuff is done within the decoder itself... |
14:19:08 | pamaury | what upset me is that I can send 256K/s of OUT transfers without any errors with my test code (I do manual CRC check even though the hardware should do it also) but yesterday I record the usb audio output and it was good except there were some samples zeroed here and there and they sound weird. I don't know where is the problem |
14:19:26 | Buschel | Lear: calling ci->set_offset(ci->curpos) seems just right |
14:19:42 | | Quit jd (Ping timeout: 265 seconds) |
14:19:53 | Lear | Buschel: Ah, yes, that's why. |
14:20:41 | gevaerts | pamaury: did you test the test code while playing audio (the usual way)? |
14:21:23 | Buschel | Lear: so, for aac ci->set_offset(elapsed_time) should just be removed. aac uses ->advance_buffer() |
14:23:23 | pamaury | gevaerts: I can't, my test code is a special usb interface with special requests do to some iso transfers. But this afternoon, I'll do some more test witht the usb audio code, using usbmon to see if there is a usb transfer error or if I'm messing up things somewhere |
14:23:24 | Lear | Seems like it, yes. Still seems to work as it is... :) |
14:24:09 | gevaerts | pamaury: I mean, try just playing some audio files in rockbox while using the test interface |
14:26:33 | pamaury | gevaerts: ah ok. but the problem I encountered yesterday (well today at 3am) is that if I play a file with left channel=0x1234 (say) and right=0x5678, if the usb audio record it's output to a file. Then the file contains the expected audio but with some errors. So the problem is not (only) playing audio. |
14:26:47 | *** | Saving seen data "./dancer.seen" |
14:28:59 | | Quit anti[v4] (Remote host closed the connection) |
14:32:18 | CIA-5 | New commit by Buschel (r25164): Fix FS #11103. Resuming musepack files was handled wrong since ages. This change converts the decoders exact sample position to an estimated byte ... |
14:35:36 | | Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) |
14:37:43 | CIA-5 | New commit by learman (r25165): Make resume handling in the AAC codec less confusing. No functional change. |
14:39:26 | | Join tvelocity [0] (~tony@weg38-1-82-237-37-150.fbx.proxad.net) |
14:39:50 | Buschel | Lear: Saving ci->curpos keeps the exact file position. But in combination with mpc's variable bitrate the calculated sample index is just an estimation. When saving a (virtual) file position that is calculated by the reversed formula of the resuming formula, the calculated sample index will be precise. |
14:41:49 | Lear | Buschel: But if you check set_offset, you'll see that it subtracts the pcmbuf latency. So it won't be an exact reverse, I think... |
14:42:10 | | Quit JdGordon1 (Ping timeout: 265 seconds) |
14:42:17 | Buschel | Lear: yes. But that's the same for all the other codecs as well. |
14:43:50 | Buschel | Lear: what I wanted to state -> the committed solution is more precise for variable bitrate files |
14:47:55 | | Join robin0800 [0] (~quassel@general-ld-216.t-mobile.co.uk) |
14:56:27 | pixelma | JdGordon (for the logs) - your latest patch also fixes the freezes I get with a simple %Tn fms (even though presets were loaded and displayed before it hung on exit) |
14:56:35 | | Quit S_a_i_n_t (Ping timeout: 240 seconds) |
14:56:36 | | Join S_a_i_n_t_ [0] (S_a_i_n_t@203.184.0.253) |
14:56:54 | pixelma | maybe they were invalidated on exit? |
15:00 |
15:01:30 | | Quit S_a_i_n_t_ (Ping timeout: 264 seconds) |
15:07:01 | | Join flydutch [0] (~flydutch@host83-164-dynamic.15-87-r.retail.telecomitalia.it) |
15:11:29 | | Quit Casainho (Ping timeout: 240 seconds) |
15:22:51 | | Join Kitr88 [0] (~Kitr88@BSN-182-10-245.dial-up.dsl.siol.net) |
15:26:08 | | Quit Kitar|st (Ping timeout: 264 seconds) |
15:26:54 | | Quit robin0800 (Quit: No Ping reply in 180 seconds.) |
15:27:11 | | Quit Kitr88 (Ping timeout: 245 seconds) |
15:27:19 | | Join robin0800 [0] (~quassel@general-ld-216.t-mobile.co.uk) |
15:28:08 | Buschel | hmm, why ci->id3->offset has strange results for alac format when entering the codec? e.g. the correct byte position seems to be saved (e.g. 1.500.000), but when re-entering the codec it is 2.020 |
15:29:16 | | Quit kaniini (Ping timeout: 245 seconds) |
15:29:45 | | Join S_a_i_n_t [0] (S_a_i_n_t@203.184.0.24) |
15:32:03 | linuxstb | Buschel: What do you mean by "re-entering the codec" ? |
15:32:19 | S_a_i_n_t | TheSeven: you there? |
15:33:00 | | Join Kitar|st [0] (Kitr88@89.142.233.192) |
15:33:50 | Buschel | linuxstb: entering codec_main of atrac.c |
15:34:24 | linuxstb | atrac.c? |
15:34:37 | linuxstb | Are you talking about alac or atrac? |
15:34:45 | * | Buschel needs to slow down a bit... |
15:34:48 | S_a_i_n_t | TheSeven: your latest commits seem to make CygWin compile "dirty" (not sure how else to put it...) |
15:34:50 | S_a_i_n_t | http://pastebin.com/Ux022ZNc |
15:35:03 | Buschel | sorry, my mistake. of course I am talking of alac.c |
15:35:08 | S_a_i_n_t | It seems to compile...but isn't happy about something. |
15:38:15 | | Join Casainho [0] (~chatzilla@bl15-104-228.dsl.telepac.pt) |
15:41:15 | Lear | Buschel: ALAC doesn't support resuming at all, at the moment, it seems. Copying the aac.c code ought to work though. |
15:42:34 | Buschel | Lear: I know, I wanted to implemement it right now. But id3->offset's value seems odd (printf debugging in pcsim). |
15:43:07 | | Join findus [0] (~user@a88-115-175-129.elisa-laajakaista.fi) |
15:45:02 | findus | hi folks, just had a quick question about future developement....(please don't hate me) |
15:45:20 | Lear | Buschel: Added a case for it in audio_finish_load_track (playback.c). Shouldn't make any difference, but my overlap patch expects it at the moment. :) |
15:45:38 | findus | I just purchased a sansa clip plus player, is there a rockbox port in the works now, or coming in the foreseeable future. Thanks for any replies |
15:46:30 | robin0800 | findus: is it on the front page? |
15:47:07 | findus | yes, but it does not mention if something is in the work :) |
15:47:52 | findus | *no |
15:48:01 | TheSeven | S_a_i_n_t: that's just some annoying warning triggered by some code i added to help debugging. this will be gone again soon. |
15:48:58 | | Quit Highlander (Quit: Quitte) |
15:50:47 | S_a_i_n_t | Ah...right, I was just testing out the build. So, it doesn't actually *mean* anything, errrr...not to me at least? |
15:52:07 | | Join kaniini [0] (~quassel@dyn75-70.yok.fi) |
15:55:14 | AlexP | findus: The clip v1 works more or less |
15:55:26 | AlexP | the clip plus + v2 may or may not |
15:55:34 | | Join DerPapst [0] (~DerPapst@dslb-084-059-106-058.pools.arcor-ip.net) |
15:55:35 | AlexP | Depends on when someone does the work |
15:55:42 | AlexP | There are never any plans as such |
15:56:20 | findus | thank you AlexP and robin0800 |
15:58:01 | AlexP | I think some people are looking at the clip+, but there are never any ETAs. Spare time volunteer project, and you never know whether something is going to be done/possible until it is |
15:59:04 | liar | TheSeven: have you seen my messages above? (vfl fast read panic) |
15:59:10 | FlynDice | findus: take a look here: http://www.rockbox.org/wiki/SansaAMS |
16:00 |
16:01:29 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
16:02:07 | TheSeven | liar: yes, but that only confused my even more ;-) |
16:02:41 | S_a_i_n_t | liar: It *Panic*'s when you...? |
16:02:48 | TheSeven | there is a fast read failure somewhere, so it resets the bank and tries a slow read, which also fails, because of a spare ecc error... |
16:02:52 | S_a_i_n_t | I can't seem to get that build to fail. |
16:02:54 | TheSeven | this *might* actually be a failing page |
16:03:01 | findus | Yeah, I know the deal with opensoftware and appreciate that it's all based on volunteer work."Release date? - Thursday" |
16:03:03 | TheSeven | (because it was not properly written?) |
16:03:18 | TheSeven | S_a_i_n_t: which flash type do you have? |
16:03:24 | TheSeven | see debug => display hw info |
16:03:25 | liar | TheSeven: but it works with the previous revision? |
16:03:51 | TheSeven | the previous revision wasn't using fast reads at all, so it actually tried slow reads twice |
16:04:02 | TheSeven | maybe that was a little more fault-tolerant |
16:04:23 | liar | diskmode does not remap i either |
16:04:40 | findus | thanks FlynDice, bookmarked and will check back on that one later! |
16:05:56 | S_a_i_n_t | 2585d3ad |
16:06:11 | S_a_i_n_t | ^ TheSeven |
16:06:56 | | Join CGL [0] (~CGL@190.207.203.1) |
16:07:13 | Buschel | Lear: I do not understand what is happending here :/ will do a rebuild now |
16:07:17 | S_a_i_n_t | Also...(sorry, I know it'll probably be the *least* of your worries), the Nano2g SVN bootloader is hanging on the "Apple" |
16:07:58 | S_a_i_n_t | ...but at least crypt_firmware works again :D |
16:08:46 | TheSeven | oh? who fixed it? |
16:08:50 | TheSeven | it fixed itself by magic? |
16:09:16 | S_a_i_n_t | Funny thing, I used to have that HW info patch for the 2g nano in my "essential patches" folder, glad you committed it :D |
16:09:32 | S_a_i_n_t | magic I guess...if you didn't touch it. |
16:10:08 | S_a_i_n_t | as I had the stack at 4000 myself anyway, and it failed there...so that can't of been it. |
16:10:17 | S_a_i_n_t | (which was my first guess) |
16:10:29 | S_a_i_n_t | *0x4000 |
16:12:10 | CIA-5 | New commit by theseven (r25166): Nano 2G VFL: try slow read twice if fast read failed |
16:12:33 | TheSeven | S_a_i_n_t: aha, so the cached flash type also supports interleaved reads, that's nice to know |
16:12:54 | liar | TheSeven: i just wanted to suggest that :-) (slow read 2 times) |
16:13:23 | S_a_i_n_t | you're ( TheSeven ) the only one that touches the nano2g code practically...so I suspect you fixed crypt_firmware by accident. |
16:13:28 | * | bluebrother found a problem with rbspeex.c |
16:13:37 | S_a_i_n_t | I didn't see a commit from anyone else regarding it. |
16:13:58 | bluebrother | now lets see if that is the cause for rbspeex not working correctly on ppc |
16:14:13 | TheSeven | liar: i doubt that this fixes your problems though |
16:16:46 | | Join jd [0] (~jd@modemcable207.134-202-24.mc.videotron.ca) |
16:16:47 | | Quit jd (Changing host) |
16:16:47 | | Join jd [0] (~jd@Wikipedia/HellDragon) |
16:18:34 | S_a_i_n_t | the "screendump causes *panic*" issue with nano2g is interesting...the first time I tried, it worked fine, but every time since I've had a "iTunes white screen of death" fom it. |
16:18:35 | S_a_i_n_t | :/ |
16:18:54 | S_a_i_n_t | *from also. |
16:19:29 | S_a_i_n_t | I'm too scared to try it a fifth time. |
16:19:55 | S_a_i_n_t | s/scared/can't be assed restoring the thing/ |
16:21:42 | liar | TheSeven: yep that fails too |
16:24:23 | * | S_a_i_n_t congratulates Apple for getting to OFW to run on each of the different NAND's properly, but suspects if TheSeven had their doccumentation things would be different for RB |
16:25:42 | | Quit r0b- (Ping timeout: 256 seconds) |
16:26:05 | | Join r0b- [0] (~nnscript@adsl-76-235-176-100.dsl.klmzmi.sbcglobal.net) |
16:26:51 | *** | Saving seen data "./dancer.seen" |
16:27:01 | CIA-5 | New commit by theseven (r25167): Nano2G VFL: reset the bank again before the second slow read try |
16:28:03 | TheSeven | liar: I don't think this will help either, but it is resembling the old behavior even closer now when the fast try fails |
16:29:19 | TheSeven | your chip was an xx55xxEC type? this is interesting, as mine is also one of those... (samsung interleaved) |
16:31:19 | | Quit robin0800 (Quit: No Ping reply in 180 seconds.) |
16:31:44 | | Join robin0800 [0] (~quassel@general-ld-216.t-mobile.co.uk) |
16:31:50 | pixelma | bluebrother: sounds nice and thanks for looking into this. I'll try as soon as possible (tomorrow evening, I guess) :) |
16:32:27 | Buschel | Lear: found it. Calling qtmovie_read changes ci->id3->offset :/ |
16:34:55 | Lear | Yep, that's why aac.c copies the value... :) |
16:35:51 | Buschel | An application note would have been helpful... Well, found at least |
16:36:31 | | Quit Lear (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158]) |
16:36:49 | liar | TheSeven: 2555D3EC yes |
16:37:53 | TheSeven | liar: does the current build seem to work? |
16:39:15 | liar | TheSeven: different panic message |
16:39:30 | liar | (RC 0080 instead of RC 0000) |
16:39:31 | TheSeven | oh? which one? |
16:39:38 | TheSeven | oh damn |
16:39:44 | TheSeven | so 2 banks failed at the same time now |
16:40:22 | TheSeven | damn, that's almost the same chip that i'm using! |
16:40:39 | TheSeven | i just read back 3.2 GB of data using that build without a single problem |
16:41:28 | | Join adnyxo [0] (~aaron@adsl-065-013-002-216.sip.asm.bellsouth.net) |
16:41:42 | CIA-5 | New commit by theseven (r25168): Don't parallelize Nano2G NAND reads, just do pipelined ECC. (10% performance loss :-/ ) |
16:41:54 | TheSeven | liar: ok, now does this one fix it? |
16:42:17 | TheSeven | this should behave *exactly* the same, besides maybe different timings and an additional retry, from the nand point of view |
16:42:34 | TheSeven | it's just doing the ECC operations after starting the next page read, not before |
16:43:50 | | Join korlen [0] (~4436d135@gateway/web/freenode/x-iumuilofryvknqub) |
16:43:56 | korlen | Hello? |
16:44:06 | korlen | is anyone here? |
16:44:14 | TheSeven | there are 129 people here. |
16:44:19 | korlen | lol |
16:44:46 | korlen | well im wonder if anyone can answer my question |
16:45:12 | korlen | can i use rockbox on sansa fuze v02 yet? |
16:45:41 | TheSeven | it it listed on the front page? |
16:46:19 | korlen | it says sansa fuze only v01, im just wonder.. idk how offen rockbox updates their website |
16:46:22 | * | bluebrother points to the front page |
16:46:53 | * | findus can answer! |
16:46:55 | findus | http://www.rockbox.org/wiki/SansaAMS |
16:46:59 | bluebrother | korlen: to figure that I'd suggest checking if that "Subversion" stuff is recent ... |
16:47:09 | | Join dfkt_ [0] (dfkt@unaffiliated/dfkt) |
16:48:00 | bluebrother | oh, and check the _last_ line of the front page :) |
16:49:51 | liar | TheSeven: *panic* |
16:50:43 | | Quit dfkt (Ping timeout: 265 seconds) |
16:52:50 | TheSeven | liar: same oneß |
16:53:02 | * | TheSeven is confused |
16:53:07 | liar | TheSeven: same one |
16:53:14 | liar | (with RC 0080 |
16:53:37 | korlen | oh ok thanks |
16:55:14 | TheSeven | liar: sorry, I'm out of ideas. |
16:55:41 | | Quit korlen (Quit: Page closed) |
16:56:58 | | Quit adnyxo (Quit: Ex-Chat) |
17:00 |
17:05:14 | CIA-5 | New commit by Buschel (r25169): Implement resume for alac codec. |
17:05:38 | | Join Darkknight512 [0] (~Darkknigh@CPE00212968356c-CM00186845dd46.cpe.net.cable.rogers.com) |
17:06:56 | CIA-5 | New commit by theseven (r25170): Revert Nano2G fast VFL reads for now. They just won't work on some hardware. |
17:10:54 | CIA-5 | New commit by theseven (r25171): Nano2G NAND: Detect if the chip supports interleaved and/or cached writes. |
17:12:31 | CIA-5 | New commit by theseven (r25172): Nano2G VFL/FTL: Use fast writes |
17:13:17 | CIA-5 | New commit by theseven (r25173): Nano2G FTL: Enlarge FTL buffers for faster write operations |
17:13:48 | TheSeven | liar: can you check the latest one again? |
17:14:14 | TheSeven | this time, there should be trouble when writing, if anything. |
17:14:34 | Darkknight512 | I can test if you need |
17:14:44 | liar | TheSeven: i dont want to reformat my partition again :-( |
17:15:13 | TheSeven | Darkknight512: which chip type do you have? |
17:15:17 | Darkknight512 | i havent even put my music back on since yesterdays iloader prob, so reformatting wont be a prob |
17:15:24 | Darkknight512 | umm, can i check from within RB? |
17:15:32 | TheSeven | yes, system => debug => view hw info |
17:15:42 | Buschel | Any thoughts about FS #10016 (reading id3v1, if id3v2 contains few data)? |
17:16:59 | Darkknight512 | NAND: Banks4 ID: 2555D3EC |
17:17:37 | TheSeven | ok, so the same chip type as liar |
17:17:53 | TheSeven | you could also do the test then |
17:18:13 | | Join saratoga [0] (~463f90ed@gateway/web/freenode/x-vavuyirumqlajxuv) |
17:18:40 | Darkknight512 | alright what u need? |
17:18:50 | kugel | Buschel: I'm not a fan |
17:20:09 | liar | TheSeven: remember, it did not happen with every track being played, so it might not happen with every write access |
17:20:16 | TheSeven | Darkknight512: just download r25173 when it finishes building and try copying some data to/from your ipod, and check if it works |
17:20:28 | Darkknight512 | k |
17:20:30 | Buschel | kugel: can you please explain? |
17:21:13 | TheSeven | liar: the writes did fail very consistently on some chips, but i know the cause of that, and circumvented it. this fix seemed to work the last time i committed it, so i'm confident that it will also work now. i just want to make sure. |
17:22:18 | pixelma | doesn't reading ID3v1 need an additional seek to the end of the file (which possibly won't help if the ID3v1 doesn't contain more data than the v2.x tag) |
17:23:27 | pixelma | I'd rather encourage people to tag their files correctly (and consistently) |
17:23:31 | liar | ah so thats not the same bug/problem? |
17:23:38 | Buschel | yes, id3v1 needs an additional seek. But if the id3v2 tag does not contain artis/title/album I am of the opinion that such a seek is valuable. |
17:23:58 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
17:24:21 | Buschel | pixelma: The "learning factor" is best reason so far :o) |
17:24:27 | liar | *as the vfl fast read problems? |
17:24:35 | Darkknight512 | TheSeve: You need me to test writes correct? |
17:24:48 | pixelma | Buschel: such a seek could be useless (as I said, you don't know whether you'll get more data out of the ID3v1 beforehand) |
17:24:54 | TheSeven | liar: no, your chips supports interleaved writes, while some others don't, which caused problems on those of course. i'm detecting this now, and only enable interleaved writes if they are supported, so this should be sage. |
17:24:57 | TheSeven | safe* |
17:25:05 | TheSeven | Darkknight512: yes |
17:25:53 | kugel | Buschel: I don't think we should support mixed tags |
17:26:38 | kugel | and I agree with pixelma |
17:26:45 | Darkknight512 | dosent appear to be a problem |
17:26:58 | | Quit dfkt_ (Ping timeout: 265 seconds) |
17:27:41 | pixelma | I remember there was a discussion with rasher when he filed the bug report last year |
17:28:05 | | Quit DerPapst (Quit: Leaving.) |
17:29:26 | Buschel | pixelma: a pitty it wasn't added to the fs entry. I will ad some remakr to the fs entry |
17:29:30 | Buschel | *remark |
17:29:43 | rasher | I just think requiring people to have perfect tags is a losing battle |
17:30:22 | Darkknight512 | TheSeven:Writes and reads appear to be ok |
17:30:24 | rasher | It's *easy* for us to check the v1 tag if the v2 tag is missing one or more of (artist, title, album) |
17:30:40 | rasher | It's hard for the user to track down which of his songs have this problem |
17:30:55 | | Join polobric1lo [0] (~polobrico@AGrenoble-257-1-36-116.w86-206.abo.wanadoo.fr) |
17:30:56 | rasher | And for the user with perfect tags, such a seek would never happen |
17:31:16 | rasher | So I don't see exactly who we're inconveniencing terribly |
17:32:30 | CIA-5 | New commit by theseven (r25174): Implement Nano2G fast NAND read API as a wrapper around the slow one. |
17:33:19 | | Join panni_ [0] (hannes@ip-95-222-52-93.unitymediagroup.de) |
17:33:43 | saratoga | I agree with rasher here |
17:33:47 | pixelma | http://www.rockbox.org/irc/log-20090313 started the 12th it seems |
17:33:58 | CIA-5 | New commit by theseven (r25175): Re-enable fast reads in the Nano2G VFL/FTL. (Using the wrapper API in the NAND driver) |
17:35:13 | TheSeven | liar, Darkknight512: can you check reads again? |
17:35:24 | Darkknight512 | sure |
17:35:34 | liar | yes |
17:36:09 | | Quit polobric1lo (Ping timeout: 265 seconds) |
17:38:22 | | Quit FlynDice (Remote host closed the connection) |
17:40:04 | liar | TheSeven: FTL: Scheduling bank ... |
17:40:15 | liar | (the same bank & block as before) |
17:40:25 | TheSeven | ah-ha. a highlevel bug? that only happens with some chips? weird. |
17:40:27 | rasher | So it's (so far) Buschel, saratoga, gevaerts, bluebrother and me on one side and pixelma, kugel, JdGordon and iirc amiconn on the other. I'm not sure how we're going to reach any conclusion here |
17:40:48 | TheSeven | so we were digging around the wrong place all the time :-P |
17:41:06 | saratoga | whats the argument against? that it might cause people to inadvertantly reduce their battery life if they have screwy tags? |
17:41:18 | rasher | saratoga: That seems to be it, yes |
17:41:40 | saratoga | meh if you have screwed up tags, and a player where the disk actually matters, you get what you deserve |
17:42:04 | Darkknight512 | TheSeven: I just copied half a gb of stuff from the Nano to my computer, no errors |
17:42:05 | TheSeven | how likely is it to even cause additional power consumption? it won't if the whole file is being buffered at a time, right? |
17:42:22 | TheSeven | Darkknight512: did you *ever* get FTL panics before? |
17:42:27 | saratoga | probably only matters for really big files that can't be all in the buffer at the same time |
17:42:33 | kugel | the metadata is fetched before the file is buffered |
17:42:42 | Darkknight512 | wait, nvm, i tried copy again, now it died |
17:42:42 | saratoga | oh yeah |
17:42:59 | liar | TheSeven: the panic screen looks very strange :-) |
17:43:07 | Darkknight512 | FTL: Scheduling bank 2 block 492 remap! |
17:43:16 | TheSeven | when reading or writing? |
17:43:21 | Darkknight512 | red |
17:43:24 | TheSeven | liar: in terms of what? |
17:43:32 | Darkknight512 | read* |
17:43:47 | liar | should i have mentioned that before? wait ill make a photo |
17:44:13 | pixelma | not that I've seen many complaints of users who say why doesn't XYZ show in the WPS even though my files are correctly tagged (except rasher) |
17:44:43 | * | kugel hasn't seen a single complaint |
17:44:57 | rasher | So because no one has complained, we don't fix things? |
17:45:22 | pixelma | I wouldn't call it a fix |
17:45:27 | rasher | I would. |
17:45:37 | kugel | I wouldn't |
17:45:48 | pixelma | yay, kindergarten |
17:46:51 | kugel | in my eyes it's trying to fix a problem which doesn't exist |
17:47:03 | saratoga | if it doesn't exist theres no harm in it |
17:47:11 | saratoga | since it will never effect anyone |
17:47:15 | pixelma | reading last year's coversation again... where do you draw the line after which Rockbox will not try to read the ID3v1 after getting some info from ID3v2? |
17:47:59 | rasher | If artist and title is present |
17:48:00 | pixelma | saratoga: if it adds code complication it'll affect everyone |
17:48:18 | rasher | pixelma: that's so miniscule it's not worth considering. Honestly |
17:48:31 | rasher | "Oh no, it'll shave off 2ms of battery life" |
17:48:31 | saratoga | i don't think an if() parse_id3() block really adds much complication |
17:48:47 | saratoga | why not just battery bench this |
17:49:05 | pixelma | rasher: ah, and what do you tell someone who asks about "and my album/year/whatever tag"? |
17:49:09 | saratoga | i really doubt the difference is measurable even in the worst case, but its easy enough to test if you've got a hard disk placer |
17:49:11 | saratoga | player |
17:49:42 | rasher | pixelma: I tell them that we have to draw the line somewhere, and an id3v2 tag that has artist and title is "good enough" |
17:50:10 | pixelma | and what about songs where you deliberately leave the tag empty (because you don't know it or else)? |
17:50:18 | rasher | What about them? |
17:50:38 | pixelma | then Rockbox will seek and won't even find something in the ID3v1 |
17:50:42 | rasher | So? |
17:50:52 | pixelma | wasted |
17:50:58 | rasher | I thought the answer to anything bad happens is "fix your tags"? |
17:51:11 | saratoga | a sequential seek 10MB forward is maybe a 20 ms operation at most |
17:51:18 | rasher | Also, if that happens enough that your battery life is significantly affected, I'll buy you a beer |
17:51:29 | rasher | That goes for all Rockbox users. |
17:52:01 | Buschel | rasher: I would only slightly move the line to "good enough = has album, title, artist". The added code will only perform the seek/id3-reading, if this is not fulfilled. I cannot imagine a battery bench would show any effect. |
17:52:04 | rasher | I'd rather have an occasional seek in vain than an occasional missing info |
17:52:15 | | Join froggyman [0] (~sopgenort@pool-72-69-76-103.chi01.dsl-w.verizon.net) |
17:52:23 | pixelma | there it starts |
17:52:42 | kugel | rasher: fix your tags then :) |
17:52:50 | * | pixelma doesn't have a HD target anymore |
17:53:27 | rasher | kugel: You can't expect 100% of users to have 100% perfect tags |
17:53:28 | kugel | I'm not seeing the whole point in id3v1 tags anyway, id3v2 is clearly superior |
17:53:31 | rasher | It's just not reasonable |
17:53:43 | Buschel | This discussion is less technical and more about notion. |
17:53:57 | kugel | I don't expect, I just don't care about people with bad tags |
17:54:08 | rasher | That's not really a great attitude to have at your users |
17:54:16 | pixelma | rasher: then you should also start supporting APE tags in MP3 files or in ogg vorbis etc. ... :/ |
17:54:18 | kugel | so what |
17:54:20 | TheSeven | what about just someone actually *doing* a battery bench with that fix applied, and checking if there is a difference of more than a minute? |
17:54:35 | rasher | kugel: please never talk to our users again. |
17:54:42 | rasher | Your attitude is terrible |
17:54:43 | Buschel | Can't we just make a voting? ;o) |
17:54:43 | AlexP | TheSeven: Don't be silly, that'd end a good argument :) |
17:55:06 | kugel | stop with that. we make rockbox for us, not "my users" |
17:55:26 | liar | TheSeven: http://img67.imageshack.us/img67/5227/14032010294.jpg |
17:55:32 | TheSeven | you could still argue while the bench is running... |
17:55:38 | rasher | Ah, the nice old cop-out |
17:55:49 | TheSeven | erm, WTF? |
17:55:55 | saratoga | if you need 300mA to keep the disk spinning, and each id3v1 check takes 30ms, and you listen to 15 songs an hour, then I get that you would increase current consumption by 40 microamps |
17:55:59 | kugel | TheSeven: a bench will show nothing, I don't think it'll have any impact on battery life |
17:56:04 | Darkknight512 | liar: Lol |
17:56:14 | rasher | kugel: so what's the harm? |
17:56:29 | rasher | kugel: do you just want to be able to point and laugh at users with slightly weird tags? |
17:56:47 | TheSeven | shouldn't panicf() disable interrupts rather early? at least *before* writing to the LCD? |
17:57:10 | saratoga | you'd probably have to strech each id3v1 access out to a couple hundred milliseconds before we could even measure it, maybe more |
17:57:17 | Darkknight512 | TheSeven: should i give it a try and see if it heppens to mine? |
17:57:27 | kugel | there's no harm, but I rather teach people to have good tags instead of messing with mixing them with an old and obsolete standard |
17:57:42 | liar | TheSeven: once i even saw the title bar |
17:57:43 | soap | How common, really, is incomplete v2 tags AND well-formed v1 tags? I've seen plenty of truncated v1 tags paired with proper v2 tags (most common scenario most likely), I've seen v2 OR v1 only. But incomplete v2 and complete v1? I can't imagine the situation outside intention which would create that. |
17:57:44 | rasher | Oh ffs. So you're arguing this because you want people to suffer? |
17:57:46 | kugel | yes, I want to laugh at them... |
17:57:47 | saratoga | the problem is theres little feedback that the tag format is the problem . . . |
17:57:52 | TheSeven | kugel: then just drop id3v1 support completely. |
17:58:03 | kugel | TheSeven: I can live with that :) |
17:58:07 | rasher | kugel: please stay out of this actual rational discussion then |
17:58:10 | rasher | christing fuck |
17:58:11 | AlexP | If it makes no battery difference, then why not just help people out? |
17:58:16 | pixelma | rasher: APE tags? |
17:58:23 | rasher | AlexP: Because we hate users, apparently |
17:58:26 | saratoga | i still want ape tags |
17:58:40 | rasher | I'm not opposed to reading ape tags |
17:59:03 | Darkknight512 | rasher: developersdevelopersdevelopers |
17:59:08 | rasher | Obviously after v1 and v2 |
17:59:21 | saratoga | i've actually found a few albums with better apev2 tags then id3v2 tags in my collection |
17:59:24 | pixelma | oh cool, more complication |
17:59:29 | kugel | rasher: please keep the discussion at a reasonable level |
17:59:36 | AlexP | Do ape tags come in the middle and require another seek? :) |
17:59:36 | saratoga | probably some old foobar version did that |
17:59:40 | rasher | kugel: which is why I want you to stop being in it |
17:59:48 | saratoga | apev2 is next to id3v1 |
17:59:52 | saratoga | so its the same case as we have now |
17:59:57 | * | Buschel was distracted when first using rockbox, which forced him to use APE tags on mpc files (which is non sense, as each audio format might use each tag format) |
18:00 |
18:00:11 | TheSeven | liar: you just have a weird ipod ;-) |
18:00:16 | saratoga | i thought ape was the standard for mpc? |
18:00:18 | rasher | kugel: Sorry, I just have a low tolerance for being actively hostile towards other users of the software |
18:00:23 | Buschel | nevertheless I searched for a tool and replaced the tags on _all_ of my files... |
18:00:28 | liar | Darkknight512: is that happening for you too? |
18:00:34 | Darkknight512 | im trying |
18:00:34 | AlexP | I really really fail to see the issue here - if there are no measurable negative side effects, then why not support the widest range we can? |
18:00:39 | Darkknight512 | it hasent died yet |
18:01:02 | soap | and IF APE is supported, shouldn't the priority go v2 -> APE -> v1, rasher? |
18:01:20 | kugel | and I have a low tolerance for your attitude towards me, right now |
18:01:23 | Darkknight512 | liar: were you in WPS or just diskmode screen when it did that? |
18:01:26 | * | TheSeven votes for ID3v2 and nothing else |
18:01:37 | rasher | soap: I'd say v2 > v1 > ape, but shrug |
18:01:42 | TheSeven | Darkknight512: apparently wps |
18:02:04 | Darkknight512 | nope, mine is normal, well as normal as a crash is =D |
18:02:06 | soap | rasher, except for the fact if there was APE you'd expect them to be more complete than v1. |
18:02:12 | * | TheSeven has never seen ape tags being used by anything but mp3gain |
18:02:27 | saratoga | ape and id3v1 could be done configurably since they're always sequential laid out back to back! |
18:02:37 | liar | Darkknight512: it does not happen always |
18:02:44 | saratoga | TheSeven: foobar used them for a long time |
18:02:45 | soap | kugel, except for the fact there are plenty of good reasons to use v1 tags. And since v1 tags are universally supported, yet limited there is plenty of reason for a file to carry two sets of tags. |
18:02:51 | TheSeven | haha, read both and compare the id3v1 strings to ape, and use ape if they were truncated, but v1 if they are just different :-D |
18:02:57 | saratoga | they were very popular with HA's crowd |
18:03:12 | Darkknight512 | liar: ok then, try #4 |
18:03:24 | | Part rasher |
18:04:12 | soap | yea, the foobar defaulting to APE for "higher complexity" MP3 tags really created the mess. |
18:04:47 | Darkknight512 | No my crashes are normal |
18:04:47 | kugel | soap: can you name anything that doesn't read id3v2? it's around for many many many years now |
18:05:00 | soap | kugel, my DVD player, my car radio. |
18:05:34 | soap | and even the hardware which DOES do v2 likely wants v2.3 or 2.2, not 2.4, and VERY likely doesn't want UTF-8. |
18:05:38 | saratoga | well the idea made sense circa 2003 when half the hardware out there couldn't read id3v2 properly but id3v1 still worked fine |
18:06:10 | saratoga | so you had id3v1 for hardware devices, and apev2 for software/archiving |
18:06:12 | soap | v1 tags are next to free, and give you near universal hardware support. Not much of a downside. |
18:06:33 | | Quit r0b- (Ping timeout: 256 seconds) |
18:06:44 | saratoga | do we still lock threads asking about unusable builds like we did when there were supported and unsupported builds? |
18:06:55 | | Join r0b- [0] (~nnscript@adsl-76-253-126-178.dsl.klmzmi.sbcglobal.net) |
18:07:32 | soap | I don't. I've laxed up on locking those since the signal-to-noise ratio on the forums is well under control. |
18:07:35 | pixelma | soap: and if it doesn't like UTF, how does ID3v1 help there? |
18:07:47 | soap | pixelma, it reads the v1 tags just fine. |
18:07:52 | pixelma | UTF-8 |
18:08:16 | pixelma | those won't be UTF-8 either, no? |
18:08:17 | | Quit r0b- (Client Quit) |
18:08:36 | soap | nope, but some tags > no tags. |
18:08:52 | TheSeven | saratoga: such threads (depending on the kind of question) *might* even help the developers of that port sometimes |
18:09:41 | kugel | we have the development threads for the helpful stuff :p |
18:12:47 | | Quit Topy44 (Ping timeout: 256 seconds) |
18:13:00 | saratoga | huh we don't even build the HDD63x0 |
18:13:33 | saratoga | maybe that should be added to the build system, lowlight actually favored marking it as unstable |
18:14:15 | | Join r0b- [0] (~nnscript@adsl-76-253-126-178.dsl.klmzmi.sbcglobal.net) |
18:15:26 | saratoga | oh wait that was the hd16x0 |
18:16:00 | saratoga | haha chrome thinks download.rockbox.org is in "irish" and offers to translate to english for me |
18:16:52 | | Join u42p [0] (~u42p@c174175.adsl.hansenet.de) |
18:17:07 | u42p | i installed rockbox on my cowon d2 some weeks ago. how to i completely remove it again? |
18:17:38 | saratoga | u42p: http://download.rockbox.org/daily/manual/rockbox-cowond2/rockbox-buildch2.html#x4-180002.5 |
18:17:57 | u42p | cheers |
18:19:06 | saratoga | hmm though the manual instructions sound a bit weird |
18:20:15 | | Join dfkt_ [0] (dfkt@unaffiliated/dfkt) |
18:22:42 | | Join mt [0] (~mtee@rockbox/developer/mt) |
18:23:00 | | Join Topy44 [0] (~topy@my.fastsh.it) |
18:23:46 | | Quit dfkt (Ping timeout: 265 seconds) |
18:24:13 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
18:24:41 | | Quit r0b- (Ping timeout: 256 seconds) |
18:25:19 | | Quit dfkt_ (Ping timeout: 260 seconds) |
18:26:08 | CIA-5 | New commit by theseven (r25176): Nano2G: switch over to slow writes at VFL level |
18:26:25 | TheSeven | liar, Darkknight512: this build should be fine again |
18:26:43 | TheSeven | erm, it should say reads, not writes -.- |
18:26:52 | *** | Saving seen data "./dancer.seen" |
18:27:58 | u42p | saratoga: yeah, it seems incomplete. i still have the bootloader on it now |
18:28:08 | | Join Conformist [0] (~chatzilla@c-71-59-19-167.hsd1.ga.comcast.net) |
18:28:56 | | Join perfectdrug [0] (~marko@p5B0ECC08.dip.t-dialin.net) |
18:31:35 | | Join r0b- [0] (~nnscript@adsl-76-235-208-30.dsl.klmzmi.sbcglobal.net) |
18:32:05 | saratoga | i think the manual uninstall is actually a different section with the wrong header |
18:33:40 | | Quit saratoga (Quit: Page closed) |
18:34:25 | Darkknight512 | umm i gtg TheSeven, cant test the read for you |
18:34:27 | Darkknight512 | sry |
18:36:01 | u42p | i simply reinstalled cowon firmware, seems to have worked |
18:38:51 | | Quit Topy44 (Ping timeout: 256 seconds) |
18:41:27 | | Join Lear [0] (chatzilla@rockbox/developer/lear) |
18:48:41 | liar | TheSeven: works fine |
18:49:42 | TheSeven | liar: can you have a look at the diffs between the last 3 revisions? do you spot anything suspicious? the only change that i can see is that it will retry failed reads immediately with the working builds, and only after the other ones are completed with the failing builds |
18:50:01 | | Join CaptainKewl [0] (~jason@207.237.107.203) |
18:51:46 | | Join Topy44 [0] (~topy@my.fastsh.it) |
18:51:50 | | Join polobric1lo [0] (~polobrico@AGrenoble-257-1-36-116.w86-206.abo.wanadoo.fr) |
18:51:57 | | Join planetbeing [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
18:53:34 | | Quit Casainho (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115133306]) |
18:56:25 | | Quit Topy44 (Ping timeout: 256 seconds) |
19:00 |
19:01:45 | | Quit robin0800 (Quit: No Ping reply in 180 seconds.) |
19:02:09 | | Join robin0800 [0] (~quassel@general-ld-216.t-mobile.co.uk) |
19:03:42 | | Join m3dlg [0] (~m3dlg@bb-87-81-252-83.ukonline.co.uk) |
19:05:44 | | Quit robin0800 (Client Quit) |
19:06:02 | | Join robin0800 [0] (~quassel@general-ld-216.t-mobile.co.uk) |
19:07:13 | | Join DerPapst [0] (~DerPapst@p4FE8FA9C.dip.t-dialin.net) |
19:10:51 | | Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
19:20:22 | CIA-5 | New commit by bluebrother (r25177): Fix rbspeex on big endian hosts. ... |
19:20:47 | | Quit Curtman (Ping timeout: 240 seconds) |
19:22:27 | | Join Curtman [0] (~curt@S010600248c269238.wp.shawcable.net) |
19:22:32 | | Quit robin0800 (Quit: No Ping reply in 180 seconds.) |
19:22:58 | | Join robin0800 [0] (~quassel@general-ld-216.t-mobile.co.uk) |
19:25:45 | CIA-5 | New commit by Buschel (r25178): Minor clean up in playback.c |
19:26:03 | | Join Highlander [0] (~Highlande@mek33-4-82-236-45-205.fbx.proxad.net) |
19:27:48 | | Join T44 [0] (~Topy44@f048012155.adsl.alicedsl.de) |
19:28:35 | flyasky | hi again! ) i want make wiki-page for Samsung YV-150/ how can I? |
19:28:49 | | Join Topy [0] (~Topy44@f049023077.adsl.alicedsl.de) |
19:29:34 | pixelma | bluebrother: are you up for a LaTeX question? |
19:30:03 | pixelma | flyasky: are you registered at our wiki yet? |
19:31:55 | pamaury | gevaerts: I have a possible explaination for the usb audio problem. I just read the spec once again and to my disappointement, I noticed that the spec wants the bInterval value of the iso endpoint to be 1. It seems that the linux usb audio driver allows other values but only honors them if there are not to high (might be 1,2,3 and even 4). This might definitely be the problem. I need to do more tests before I can confirm this though |
19:32:33 | | Quit T44 (Ping timeout: 240 seconds) |
19:32:34 | flyasky | pixelma: no |
19:32:54 | flyasky | flyasky: i will |
19:33:49 | | Join Topy44 [0] (~topy@my.fastsh.it) |
19:34:09 | | Quit Rob2223 (Quit: Rob2223) |
19:37:08 | flyasky | pixelma: now I registered in wiki |
19:37:31 | flyasky | pixelma: http://www.rockbox.org/wiki/AntonBurkun |
19:38:25 | | Quit bmbl (Ping timeout: 245 seconds) |
19:42:00 | | Join bmbl [0] (~Miranda@unaffiliated/bmbl) |
19:43:08 | | Quit stoffel (Remote host closed the connection) |
19:47:20 | pixelma | flyasky: you should be able to edit the wiki now and create new pages |
19:47:38 | flyasky | pixelma: thank you |
19:52:13 | | Quit tmzt (Ping timeout: 276 seconds) |
19:53:35 | | Join tmzt [0] (~tmzt@adsl-76-244-157-52.dsl.akrnoh.sbcglobal.net) |
19:54:02 | | Quit tvelocity (Quit: Αποχώρησε) |
19:58:03 | | Quit robin0800 (Read error: Connection reset by peer) |
19:58:30 | | Join Omlet [0] (omlet05@4.123-244-81.adsl-dyn.isp.belgacom.be) |
20:00 |
20:00:30 | | Quit crazed (Read error: Operation timed out) |
20:03:10 | | Quit pamaury (Ping timeout: 252 seconds) |
20:08:13 | | Join Rob2222 [0] (~Miranda@p4FDC922F.dip.t-dialin.net) |
20:12:54 | ranmachan | If I want to test recording on my C200v2, do I need to change anything esides HAVE_RECORDING in firmware/export/config/sansav200v2.h? |
20:13:31 | ranmachan | I tried that and got a broken main menu (texts don't match the menu items anymore) |
20:13:51 | ranmachan | make clean didn't help, only undefining HAVE_RECORDING... |
20:23:14 | kugel | are you sure you unzipped the complete rockbox.zip? |
20:23:35 | kugel | ranmachan: what you're experiencing sounds like you loaded an outdated lang file |
20:24:02 | ranmachan | Ah, I only updated rockbox.sansa |
20:24:10 | ranmachan | That would explain it :) |
20:26:55 | *** | Saving seen data "./dancer.seen" |
20:28:14 | | Quit flydutch (Quit: /* empty */) |
20:42:02 | CIA-5 | New commit by alle (r25179): Polish character set for 08-Atadore font (FS #11082 by Tomasz Kowalczyk), part 1 |
20:45:13 | CIA-5 | New commit by alle (r25180): Rename some glyphs in 08-Atadore font to standard unicode names (part 2 of FS #11082) |
20:49:14 | | Part u42p ("Leaving") |
20:49:39 | | Quit findus (Ping timeout: 245 seconds) |
20:53:01 | | Join planetbeing__ [0] (~planetbei@32.154.12.102) |
20:56:33 | | Quit planetbeing (Ping timeout: 276 seconds) |
20:56:33 | | Nick planetbeing__ is now known as planetbeing (~planetbei@32.154.12.102) |
20:56:34 | | Nick planetbeing is now known as 17SAALP2R (~planetbei@32.154.12.102) |
20:56:34 | | Nick planetbeing_ is now known as 77CAAC9VV (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
20:57:25 | | Quit Curtman (Quit: Leaving) |
21:00 |
21:10:18 | | Quit amiconn (Disconnected by services) |
21:10:19 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
21:10:20 | | Join pixelma_ [0] (quassel@rockbox/staff/pixelma) |
21:10:20 | | Quit pixelma (Disconnected by services) |
21:10:37 | | Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) |
21:10:46 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
21:14:04 | | Quit GeekShadow (Read error: Connection reset by peer) |
21:17:08 | | Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) |
21:22:43 | bluebrother | pixelma: sorry, had a phone call. |
21:25:59 | CIA-5 | New commit by theseven (r25181): Finally fast Nano2G NAND reading, also works on remapped blocks this time. |
21:26:36 | tmzt_ | onenand? |
21:26:42 | TheSeven | liar, Darkknight512: please test :-) |
21:26:48 | tmzt_ | TheSeven: sorry, is that for onenand devices? |
21:26:58 | TheSeven | no, plain old nand |
21:27:03 | tmzt_ | okay, thanks |
21:27:08 | | Quit dfkt (Read error: Connection reset by peer) |
21:27:10 | TheSeven | why? |
21:27:24 | tmzt_ | issues with linux mtd |
21:27:51 | liar | TheSeven: so it was a problem with remapped blocks? |
21:28:06 | tmzt_ | just wanted to see what your solution was, but I don't think it's applicable |
21:29:05 | TheSeven | yes, it always used the VFL data for bank 0 |
21:29:29 | pixelma | bluebrother: I can \opt the last line in a table, so that for some targets the last line is atually above that. If I use \nopt for this, I'll get the following error when compiling a manual for the excluded targets: http://rockbox.pastebin.ca/1839948 . Is this unavoidable due to \nopt being a hack, or is it fixable? |
21:29:35 | TheSeven | and your flash seems to be one of the few around that has enough bad blocks that you actually hit one during testing |
21:31:50 | bluebrother | pixelma: have you ended the \nopt line with a % so the input line continues? |
21:34:21 | liar | TheSeven: it has pretty much bad blocks yes... |
21:35:25 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
21:35:25 | pixelma | bluebrother: the nopt list fits on one line (which is why I prefer it (opt takes two lines) and I saw it before. Last time I rearranged stuff so that the last line in the table wasn't (n)opted but didn't draw the connection to \nopt - only now I saw it working with \opt |
21:35:47 | liar | TheSeven: works |
21:37:35 | TheSeven | anybody with some knowledge about the build client around? |
21:38:05 | gevaerts | a bit |
21:38:54 | bluebrother | pixelma: can you post the code somewhere? |
21:42:04 | pixelma | I'm unsure which part - this is from a fully reworked button table in goban tex for better readability. I have the non-working \nopt still in there but commented out, below is the working \opt |
21:42:18 | gevaerts | TheSeven: do you have curl, zip and perl available? |
21:42:26 | TheSeven | yes |
21:42:59 | gevaerts | hm, those are checked explicitely, they won't be the problem anyway |
21:43:04 | TheSeven | i installed curl, zip was already there, and as the client is running, perl just must be. |
21:43:11 | gevaerts | svn and make? |
21:43:15 | TheSeven | also |
21:43:37 | TheSeven | and the toolchain is in the path |
21:43:42 | TheSeven | (only arm for now) |
21:43:48 | pixelma | bluebrother: what would you need - the new goban.tex, a diff, the new button table? |
21:44:28 | TheSeven | btw, do we already know which archlist name eabi will use? |
21:46:02 | | Join Schmogel [0] (~Miranda@p3EE211CF.dip0.t-ipconnect.de) |
21:46:10 | gevaerts | "Command not found" is apparently sent if the build log has "not found" anywhere in it |
21:46:25 | gevaerts | Have you tried building in that tree? |
21:47:04 | TheSeven | not yet |
21:47:10 | TheSeven | i'm installing the other toolchains right now |
21:47:25 | TheSeven | this is going to take ages on that machine |
21:48:30 | | Join bluebroth3r [0] (~dom@f053155120.adsl.alicedsl.de) |
21:48:30 | | Quit bluebroth3r (Changing host) |
21:48:30 | | Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) |
21:48:30 | | Quit bluebrother (Disconnected by services) |
21:51:45 | | Join Curtman [0] (~curt@S010600248c269238.wp.shawcable.net) |
21:51:48 | | Nick 77CAAC9VV is now known as planetbeing (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
21:55:44 | CIA-5 | New commit by theseven (r25182): Nano2G NAND: Don't continue reading on that bank if starting the read failed. |
21:57:39 | | Quit dfkt (Quit: -= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.) |
22:00 |
22:12:47 | bluebroth3r | pixelma: played around with it a bit but without success. I can reproduce the issue though. Sorry :( |
22:13:04 | bluebroth3r | replacing all this opt stuff with a real preprocessor would be a really good thing. |
22:16:31 | | Join perfectdrug_ [0] (~marko@p5B0EC9DF.dip.t-dialin.net) |
22:17:32 | | Quit Llorean (Quit: Leaving.) |
22:18:37 | | Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) |
22:18:37 | | Quit perfectdrug (Ping timeout: 265 seconds) |
22:22:44 | | Quit CGL (Ping timeout: 258 seconds) |
22:23:42 | | Quit m3dlg (Ping timeout: 265 seconds) |
22:24:10 | | Join m3dlg [0] (~m3dlg@bb-87-81-252-83.ukonline.co.uk) |
22:26:58 | *** | Saving seen data "./dancer.seen" |
22:28:11 | | Join RadicalR [0] (~RadicalR@c-69-255-49-110.hsd1.va.comcast.net) |
22:38:32 | CIA-5 | New commit by funman (r25183): sd-as3525v2: delay a bit before reading the command response ... |
22:38:38 | CIA-5 | New commit by funman (r25184): sd-as3525v2: do not reverse 2 times long responses, read them directly in the needed order |
22:44:07 | | Quit Schmogel (Ping timeout: 245 seconds) |
22:46:26 | CIA-5 | New commit by funman (r25185): sd-as3525: do not reverse 2 times long responses, read them directly in the needed order |
22:48:43 | | Join planetbeing_ [0] (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
22:50:32 | | Quit planetbeing (Ping timeout: 240 seconds) |
22:50:32 | | Nick planetbeing_ is now known as planetbeing (~planetbei@c-71-236-164-204.hsd1.or.comcast.net) |
22:51:08 | | Join funman [0] (~fun@rockbox/developer/funman) |
22:51:19 | funman | hi |
22:56:07 | kugel | hi |
22:57:19 | funman | hum i shouted victory too early on the forum : reading from Clip+ works fine but not write |
23:00 |
23:00:33 | | Join rasher [0] (~rasher@rockbox/developer/rasher) |
23:04:20 | funman | deleting a directory is stuck on "deleting..." |
23:05:28 | | Join saratoga [0] (~9803c6dd@gateway/web/freenode/x-jbawgofqaczrqwsh) |
23:06:33 | saratoga | the xiph people seem interested in our new mdct |
23:11:14 | funman | saratoga: 58.36MHz needed for mp3@192kbps on clip+ |
23:11:28 | funman | sounds a lot |
23:11:53 | funman | but then i'm not sure of fclk & pclk |
23:12:30 | saratoga | i'm guessing pretty slow :) |
23:12:37 | saratoga | how much IRAM does the clip+ have? |
23:13:22 | pixelma | I'm not sure if deleting from Rockbox is working correctly even on stable port targets. I had some file system errors on my M5 - a chkdsk /F seemed to fix everything but left a FOUND000 folder on the device which I deleted from within Rockbox - repeating chkdsk showed an error in this folder which shouldn't exist anymore (but was fixable again) |
23:13:44 | | Quit kugel (Ping timeout: 265 seconds) |
23:13:59 | pixelma | but I didn't try to reproduce yet |
23:14:08 | funman | saratoga: same than clip afaik (didn't try to see if it was larger) |
23:15:00 | gevaerts | Zagor: I had another one of those "Fatal build error: Missing log file" things, which seems related to the weirdness at http://rasher.dk/rockbox/buildgraphs/graph.php?r=25184&debug#rb.hostname.be-gevaerts . The database results for "select * from log where revision=25184 and value like '%zenvisionm30sim%';" also look strange to me |
23:15:06 | funman | pixelma: seems to work on clipv1 |
23:15:56 | gevaerts | I got the error at 22:44:23 |
23:16:24 | pixelma | funman: well, deleting seemed to work too according to Rockbox on the device |
23:17:10 | amiconn | rasher, saratoga: It's not only "screwed up" tags. Sometimes tags deliberately don't contain some information (I often leave out the album tag for single songs) |
23:17:31 | | Quit Farthen (Read error: Connection reset by peer) |
23:17:47 | rasher | amiconn: And the response to that seems to be "fix your tags" |
23:17:48 | amiconn | I would hate it if rockbox does a useless seek in that case (completely useless, since my tracks don't have id3v1 tags at all) |
23:18:06 | amiconn | rasher: Since it isn't broken there is nothing to fix |
23:18:16 | saratoga | the seek won't have a measurable impact on battery life so i don't see why anyone should care |
23:18:37 | rasher | amiconn: Most songs come from an album. |
23:18:48 | gevaerts | not all audio is songs |
23:18:58 | gevaerts | Isn't the current proposal to try v1 if *none* of album, artist or title are there? |
23:18:59 | rasher | Anyway, mostly what saratoga said |
23:19:08 | amiconn | Then take the year as another example. There are albums where the year simply isn't given |
23:19:36 | rasher | I'd say if none of artist or title is set |
23:19:54 | | Quit Highlander (Quit: Quitte) |
23:19:57 | saratoga | i'm not really seeing an argument against always checking all tags to be honest |
23:19:58 | amiconn | (e.g. Machinae Supremacy has no years given for their downloadable albums) |
23:19:58 | rasher | I still don't understand why we're even having this discussion, since no one will ever notice |
23:20:09 | saratoga | we're talking a few milliseconds her per song |
23:20:29 | amiconn | The seek is useless, and id3v1 is inferior |
23:20:43 | saratoga | its also irrelevent |
23:20:51 | * | gevaerts isn't against trying v1 if none of the important tags is there for v2 |
23:20:52 | amiconn | It isn't irrelevanrt |
23:21:30 | rasher | We do lots of "useless" things to check if various conditions are true |
23:21:36 | saratoga | we could parse the id3v1 tag 3 times over on every song load and no one would ever be able to measure the difference |
23:21:55 | amiconn | We used to have a setting which id3 version to use, and that was okay |
23:21:56 | gevaerts | I don't care too much if the important things are "title and artist" or "title, artist and album" or some other combination |
23:22:10 | | Join karashata [0] (~karashata@74-220-162-11.wightman.ca) |
23:22:39 | amiconn | saratoga: I would expect to get a measurable difference |
23:22:41 | rasher | amiconn: it still wouldn't solve this problem |
23:22:48 | CIA-5 | New commit by theseven (r25186): ftl-nano2g.c: s/\(\*([^)]+)\)\./\1->/ |
23:22:57 | rasher | amiconn: it still wouldn't solve this problem (if we brought back that setting) |
23:23:09 | saratoga | amiconn: how long do you think it takes to read an id3v1 tag then? |
23:23:27 | | Join CGL [0] (~CGL@190.207.203.1) |
23:23:27 | amiconn | I would guess around 100ms. Perhaps even more for very long tracks |
23:23:33 | saratoga | i would expect much less |
23:23:50 | saratoga | the latency here would just be the rotational latency since the tag is some number of MB later |
23:24:00 | amiconn | On flash targets, yes. But there are those hdd targets |
23:24:12 | saratoga | sure but the disk is already spinning and you don't have to seek the head |
23:24:23 | | Join Farthen [0] (~chatzilla@e179232024.adsl.alicedsl.de) |
23:24:23 | saratoga | just wait for the current track to advance 5-10MB |
23:24:35 | amiconn | Nope. For a seek, you have to walk the fat chain, then access the data area |
23:24:45 | amiconn | It's way more than just rotational latency |
23:25:01 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
23:25:11 | saratoga | the chain for the file isn't already in memory? |
23:25:21 | amiconn | nope |
23:25:28 | saratoga | bah thats annoying |
23:25:42 | amiconn | That is, one (or a few) fat sectors are in memory |
23:25:44 | TheSeven | no fat buffering? |
23:25:48 | | Quit Lss (Read error: Connection reset by peer) |
23:25:53 | amiconn | But that doesn't help if the file is fragmented |
23:26:26 | rasher | Anyway, this extra talk won't happen for every song, or even most songs. Just very occasionally. |
23:26:40 | saratoga | so 100ms @ say 300mA and 4 minutes a song means 160 uA extra current |
23:26:47 | TheSeven | aha. fragmented files with incomplete id3v2, complete id3v1 on a hard disk target. now *that's* what i call a corner case. |
23:27:00 | saratoga | assuming we do an id3 look up every song |
23:27:13 | amiconn | Fragmented files aren't a corner case. FAT fragments quite a lot |
23:28:03 | rasher | TheSeven: the "complete id3v1" part isn't part of the corner case to be fair |
23:28:40 | * | gevaerts would say that if none of the "standard-v1" set of tags is there in v2, reading v1 isn't a bad idea |
23:28:50 | saratoga | my sansa is at 4% fragmentation after 3 years and probably a billion rockbox updates, so I think assuming fragmentation is common isn't so good |
23:28:57 | | Quit Farthen (Ping timeout: 256 seconds) |
23:29:24 | saratoga | just 31 fragmented songs! |
23:29:53 | amiconn | One fat sector (512 bytes, i.e. 128 entries on fat32), references 4MB of data (at the maximum cluster size of 32KB). That means even a completely unfragmented, typical song at 192kbps (or similar vbr) spans more than one fat sector |
23:30:17 | amiconn | Your sansa doesn't hold as much data as a typical hdd target |
23:30:29 | saratoga | meaning I swap out music more often? |
23:31:04 | * | amiconn checks his recorder |
23:31:39 | saratoga | USB transfers tend not to fragment since UMS performance goes off a cliff if you try to copy two files at the same time |
23:31:45 | saratoga | at least on evcery device ive tried |
23:32:26 | saratoga | and if you only ever copy one file at a time onto a blank disk it'll rarely if ever fragment |
23:32:54 | saratoga | my fragmented files seem to be ones where i went through and edited the id3v2 tags |
23:34:04 | | Quit Rob2222 (Quit: Rob2222) |
23:34:06 | rasher | amiconn: Okay, so even if we allow half a second to check the id3v1 tag. That'll be what, 10 seconds of extra work during a day? At most? |
23:34:11 | CIA-5 | New commit by Buschel (r25187): Correction of musepack SV8 replaygain. The album/title peak is saved in a logarithmic representation and needs to be converted to linear fixed point ... |
23:34:23 | rasher | Considering few files will fall into this trap |
23:34:46 | saratoga | lets just do a battery bench and find out |
23:34:56 | saratoga | one of you must still have a hard disk target |
23:35:26 | rasher | If we're going to have a "no feature must ever affect me negatively no matter how little", I could use the same argument against supporting multiple codecs, since I only use vorbis. |
23:36:04 | saratoga | speaking of codecs, I think aac is the only one that still needs a gigantic 1MB codec buffer, we should really see about shrinking that |
23:36:25 | | Quit m3dlg (Ping timeout: 246 seconds) |
23:37:22 | | Join m3dlg [0] (~m3dlg@bb-87-81-252-83.ukonline.co.uk) |
23:39:09 | amiconn | rasher: Features which can have negative effects should be disableable |
23:39:52 | | Join Rob2222 [0] (~Miranda@p4FDC922F.dip.t-dialin.net) |
23:40:04 | amiconn | Features implemented that way are e.g. last.fm logging, database in ram, variable speed, ... |
23:40:07 | rasher | amiconn: Then it never ends |
23:40:18 | | Quit m3dlg (Client Quit) |
23:40:45 | rasher | We have to draw the line somewhere. We really can't have every damn feature be disablable because someone might not use it |
23:40:47 | amiconn | Oh, voice too, of course |
23:41:04 | rasher | No one would get anything done like that |
23:41:43 | | Quit liar (Ping timeout: 245 seconds) |
23:41:47 | saratoga | i don't really think it makes sense to have an option to disable a feature whose worse case cost is a hundred microamps |
23:42:19 | saratoga | there comes a point where small numbers become indistinguishable from 0 |
23:43:11 | Buschel | Why is this issue discussed that much? It is all about being more tolerant to imperfect tagging. When files are perfectly tagged, there is no additional seek/load or whatever. |
23:44:22 | S_a_i_n_t | how often are files perfectly tagged though? |
23:44:44 | S_a_i_n_t | mine are, your may be...but I've seen some libraries in some *right* states. |
23:44:45 | Buschel | Furthermore the v1 tag is only read, if the the v2 tag did not contain main data like artist/title/album (f which album could be dropped as well) |
23:44:53 | | Quit Battousai (Read error: Operation timed out) |
23:45:58 | Buschel | We are losing nothing (except the learning factor for users with baldy tagged files), and winning better usability. Just my 2 cents. |
23:46:47 | | Join Battousai [0] (~bryan@gentoo/developer/battousai) |
23:47:33 | | Quit Buschel () |
23:52:43 | kugel | please, no setting for this one |
23:53:31 | | Quit domonoky (Read error: Connection reset by peer) |
23:54:11 | | Quit Lear (Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158]) |
23:55:28 | rasher | It just confuses me that people who would quite literally never ever notice this if someone had just done it (and they didn't happen to see the commit) |
23:55:34 | rasher | ... are opposing this. |
23:55:35 | funman | +1, or at least add a setting to show/hide this setting |
23:58:05 | | Quit Omlet (Quit: ( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )) |
23:58:11 | amiconn | I mean, it's okay to try id3v1 if id3v2 isn't there, or completely emtpy (because that's very likely an invalid tag) |
23:58:45 | amiconn | But if id3v2 contains only partial information, how likely is it that the id3v1 tag contains the missing pieces? |
23:58:46 | rasher | amiconn: But why not if artist+title are missing? What do we lose by doing this? |
23:59:00 | rasher | Why *not* do it? |
23:59:00 | gevaerts | amiconn: in Buschel's current patch, v1 would be tried if *all* of artist, title and album are missing |