| 00:00:04 | | Quit Nico_P (Remote closed the connection) |
| 00:00:10 | AlexP | I think my massive €29 travelling expenses can be considered a "donation" (in that I won't be claiming) :) |
| 00:00:21 | | Join perrikwp1 [0] (n=Keith@rrcs-96-10-92-226.se.biz.rr.com) |
| 00:00:39 | redriot02 | damn it!! i pull the cable, it then shows a message "file not found", then reboots with the gigabeat screen, and then i get a message saying "3 blah blah firmware restoration.." then it goest to screen "1 connect portable media center to a pc" |
| 00:01:01 | * | domonoky also "donates" his flight costs... may someone else who needs it get more.. |
| 00:01:26 | | Quit Lss (Read error: 54 (Connection reset by peer)) |
| 00:02:11 | AlexP | redriot02: Welcome to the gigabeat S :( |
| 00:02:47 | redriot02 | :O |
| 00:03:00 | ej0rge | redriot02: Yeah. sounds like you're one of the people who can't use the single-boot bootloader |
| 00:03:03 | | Quit domonoky (Read error: 104 (Connection reset by peer)) |
| 00:03:05 | ej0rge | you have to use the dual boot |
| 00:03:45 | | Join perrikwp2 [0] (n=Keith@rrcs-96-10-92-226.se.biz.rr.com) |
| 00:04:09 | redriot02 | i couldnt find instructions on how to use dualboot |
| 00:04:51 | | Join redriot [0] (n=18820f1b@gateway/web/cgi-irc/labb.contactor.se/x-62769e632cf2b524) |
| 00:04:51 | | Quit redriot02 ("CGI:IRC (EOF)") |
| 00:05:08 | ej0rge | http://www.rockbox.org/twiki/bin/view/Main/GigabeatSInstallation#Step_1b_Bootloader_installation |
| 00:05:18 | ej0rge | oh, heh, sorry |
| 00:05:21 | ej0rge | that section is blank. |
| 00:05:56 | redriot | yeah |
| 00:06:29 | AlexP | redriot: http://www.rockbox.org/twiki/bin/view/Main/GigabeatSInfo#Loading_code_from_Linux |
| 00:07:26 | stripwax | does cook.codec build on sim for others? I seem to be missing some definition of __assert on cygwin build (although I will try a make clean and see if that fixes) |
| 00:07:38 | ej0rge | though someone should edit that so that it doesn't refer to the patched gigabeat V firmware loader |
| 00:07:42 | redriot | wait is this what the contents of partition #2 is supposed to look like ? |
| 00:07:46 | redriot | http://files.getdropbox.com/u/66962/Screenshot%20-%207_7_2009%20%2C%203_07_11%20PM.png |
| 00:08:18 | | Join perrikwp3 [0] (n=Keith@rrcs-96-10-92-226.se.biz.rr.com) |
| 00:08:18 | *** | Alert Mode level 1 |
| 00:08:18 | DBUG | Sent KICK perrikwp to server |
| 00:08:18 | DBUG | Sent KICK perrikwp1 to server |
| 00:08:18 | *** | Alert Mode level 2 |
| 00:08:18 | DBUG | sent MODE #rockbox +b *!*n=Keith@*.se.biz.rr.com |
| 00:08:18 | DBUG | Sent KICK perrikwp2 to server |
| 00:08:18 | DBUG | Enqueued KICK perrikwp3 |
| 00:08:18 | *** | Alert Mode level 3 |
| 00:08:18 | Torne | yes. |
| 00:08:18 | Torne | what's on partition 2 doesn't matter a lot |
| 00:08:19 | DBUG | Q-Sent KICK perrikwp3 to server |
| 00:08:19 | ej0rge | redriot: looks normal to me |
| 00:08:20 | Kick | (#rockbox perrikwp :*bang* too many joined users) by logbot!n=bjst@rockbox/bot/logbot |
| 00:08:20 | *** | Alert Mode level 4 |
| 00:08:20 | Kick | (#rockbox perrikwp1 :*bang* too many joined users) by logbot!n=bjst@rockbox/bot/logbot |
| 00:08:20 | *** | Alert Mode level 5 |
| 00:08:20 | Mode | "#rockbox +b *!*n=Keith@*.se.biz.rr.com " by logbot (n=bjst@rockbox/bot/logbot) |
| 00:08:20 | Kick | (#rockbox perrikwp2 :*bang* too many joined users) by logbot!n=bjst@rockbox/bot/logbot |
| 00:08:20 | *** | Alert Mode level 6 |
| 00:08:20 | Kick | (#rockbox perrikwp3 :*bang* too many joined users) by logbot!n=bjst@rockbox/bot/logbot |
| 00:08:20 | *** | Alert Mode level 7 |
| 00:08:42 | redriot | dang.. i was hoping thats what the problem was |
| 00:08:48 | gevaerts | logbot getting aggressive again... |
| 00:08:57 | Torne | you'll have to find the dual boot instructions, or wait until i work out why the later bootroms don't allow the single boot |
| 00:09:00 | Torne | :) |
| 00:09:11 | ej0rge | redriot: no, the flash bootloader doesn't like something about the single-boot bootloader |
| 00:09:16 | AlexP | I already linked the dual boot instructions |
| 00:09:21 | redriot | TYorne are you the lead developer for gigabeat s ? |
| 00:09:30 | ej0rge | redriot: it's pretty much because you have an OF later than 1.1 |
| 00:09:39 | AlexP | Most of rockbox applies to most targets |
| 00:10:00 | AlexP | Of the hardware on the S, jhMikeS has done a lot (and Nico_P before him) |
| 00:10:52 | Torne | no, i'm not a developer |
| 00:10:53 | redriot | damn well now my gigabeat is unusable ? |
| 00:10:59 | Torne | but i am reverse engineering the gigabeat s bootrom |
| 00:11:09 | Torne | it's not unusable |
| 00:11:13 | AlexP | redriot: Try the dualboot bootloader |
| 00:11:32 | Torne | make a dualboot bootloader, or just send it the original firmware again |
| 00:12:07 | | Part captainkwel |
| 00:12:12 | ej0rge | redriot: it's usable with the dualboot bootloader. It might still jump into recovery mode on bootup once or twice, but you can just toggle the battery switch and try again |
| 00:13:49 | redriot | so complicated :/ |
| 00:14:06 | AlexP | That'd be why it isn't either supported or released |
| 00:16:03 | | Quit robin0800 ("Leaving") |
| 00:18:21 | *** | Alert Mode OFF |
| 00:36:04 | | Join Hillshum [0] (n=chatzill@unaffiliated/hillshum) |
| 00:39:20 | | Quit tessarakt ("Client exiting") |
| 00:39:59 | | Quit petur ("Zzzzzz") |
| 00:40:09 | | Quit shotofadds ("Leaving") |
| 00:40:50 | CIA-71 | New commit by stripwax (r21704): Fix bug introduced in r21616 (my bad)- playlist moving array could show in playlist viewer even when track not being moved |
| 00:41:14 | stripwax | sigh. ^array^arrow |
| 00:42:14 | | Quit bluebrother ("leaving") |
| 00:44:13 | | Quit redriot ("CGI:IRC (EOF)") |
| 00:45:37 | | Quit efyx_ (Remote closed the connection) |
| 00:45:58 | | Quit DarkDefender ("Leaving") |
| 00:49:10 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
| 00:49:35 | | Quit robin0800 (Client Quit) |
| 00:50:57 | | Quit ender (" Generations have been working in jobs they hate, just so they can buy what they don't really need. -- Chuck Palahniuk") |
| 00:53:59 | *** | Saving seen data "./dancer.seen" |
| 00:54:09 | Zagor | per-client stats for new build: http://build.rockbox.org/data/21700-clients.html |
| 00:54:48 | Zagor | the values don't quite add up though... |
| 00:55:15 | JdGordon| | sweet |
| 00:55:19 | Zagor | this particular build took 664 seconds wallclock time |
| 00:55:25 | Zagor | *build round |
| 00:57:08 | Bagder | weird |
| 00:58:11 | JdGordon| | just going by the total time numbers... shouldnt saratoga's client have been killed and mc2739's picked up more? |
| 00:58:33 | JdGordon| | I'm assuming that only completed builds are in that list? |
| 00:58:34 | Bagder | it's impossible to tell that based on the numbers alone |
| 00:58:59 | Zagor | JdGordon|: yes, only completed builds |
| 01:00 |
| 01:00:06 | Bagder | clearly some time measurements in the server are arong |
| 01:00:08 | Bagder | wrong |
| 01:04:13 | Zagor | it seems the sockets can go down without either the server or client noticing. both my machines at home just sat there when the last round started, and didn't get any builds. |
| 01:04:49 | Bagder | then the ping logic needs to be improved |
| 01:05:01 | Zagor | exactly, shouldn't the server complain about lack of _PING then? |
| 01:05:20 | Zagor | maybe it was something else |
| 01:05:26 | Bagder | perhaps we need something in the client that makes it give up and restart if it gets nothing within a certain time |
| 01:05:33 | JdGordon| | :O you're using _PING instead of PONG?! |
| 01:05:48 | Bagder | we do, the response messages are all _[message] |
| 01:06:01 | JdGordon| | but.. but.... :p |
| 01:12:31 | | Join FOAD_ [0] (n=dok@dinah.blub.net) |
| 01:19:10 | Zagor | more fun numbers: http://build.rockbox.org/data/21704-clients.html |
| 01:20:42 | | Join lee321987 [0] (n=chatzill@76.250.186.194) |
| 01:21:15 | JdGordon| | my client fell off somewhere? |
| 01:21:27 | JdGordon| | at least gevaerts didnt get top spot again :) |
| 01:21:48 | lee321987 | Ever heard of a player not being recognized by the computer when in RB, but OF works fine? (Sansa c200) |
| 01:22:27 | Zagor | JdGordon|: unfortunately all your builds got cancelled... |
| 01:22:38 | JdGordon| | lame :p |
| 01:23:54 | Zagor | JdGordon|: what machine are you running? it seems odd that you don't even manage your first build |
| 01:24:30 | | Quit FOAD (Read error: 110 (Connection timed out)) |
| 01:24:30 | | Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) |
| 01:24:31 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
| 01:24:37 | JdGordon| | q6600 with 6gb ram and -j4 |
| 01:26:11 | Zagor | JdGordon|: then something is wrong. you got assigned build creativezvm60 at 23:01:05 but at 23:12:05 you still hadn't finished, so got cancelled due to another server already having done it |
| 01:26:38 | | Quit wincent (Read error: 60 (Operation timed out)) |
| 01:27:50 | JdGordon| | I apparently finished the yh820 build... |
| 01:28:23 | JdGordon| | back in 10 |
| 01:28:35 | | Quit JdGordon| ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 01:28:44 | | Quit lee321987 ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") |
| 01:29:26 | Zagor | Bagder: the time is counted from when the build was handed out... |
| 01:29:46 | Zagor | we need the client to report how long it took |
| 01:35:51 | | Join JdGordon| [0] (i=460030b3@gateway/web/freenode/x-0400246b87e75526) |
| 01:40:58 | CIA-71 | New commit by zagor (r21705): Report how much time a build took. |
| 01:43:40 | | Join wincent [0] (n=wincent@host-091-097-067-213.ewe-ip-backbone.de) |
| 01:46:12 | CIA-71 | New commit by zagor (r21706): Get build time from client. |
| 01:46:44 | | Quit Thundercloud (Remote closed the connection) |
| 01:47:32 | CIA-71 | New commit by zagor (r21707): Fix typo... :-| |
| 01:49:37 | | Quit Hillshum ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]") |
| 01:57:26 | | Quit Zagor ("Clint excited") |
| 02:00 |
| 02:04:42 | | Join notlistening [0] (n=tom@94-195-105-95.zone9.bethere.co.uk) |
| 02:13:59 | | Quit JdGordon| (Ping timeout: 180 seconds) |
| 02:17:43 | | Quit Torne (Read error: 110 (Connection timed out)) |
| 02:20:33 | stripwax | Anyone around for a quick review of a patch? The last one in FS #7967. |
| 02:20:59 | stripwax | Fixes a bug in playlist.c - playlist_move . Would move the track to the wrong location if it crosses the playlist index boundary at the end |
| 02:22:09 | stripwax | Afaik playlist_move is only used from playlist_viewer.c , where the bug is easy to see/reproduce when moving tracks around in a *shuffled* playlist |
| 02:27:57 | JdGordon | just commit it :) |
| 02:29:19 | stripwax | Yeah - works for me, must be good enough :) Anyway, grep doesn't lie, so −− done. |
| 02:29:46 | JdGordon | grep doesnt lie... but it will give you the output you wernt hoping for if you use it wrong :) |
| 02:30:27 | CIA-71 | New commit by stripwax (r21708): Fix bug in playlist_move where the track would end up one place too early / too late if the move wrapped from one end of the playlist indices to the ... |
| 02:36:21 | Ctcp | Ignored 1 channel CTCP requests in 0 seconds at the last flood |
| 02:36:21 | * | JdGordon is pretty sure the statusbar handling in the wps is fundamentally broken :( |
| 02:38:34 | JdGordon | or kkurbjun has sent me on a wild goose hunt :p |
| 02:40:45 | stripwax | JdGordon - who has powers to close a flyspray bug report? I think fs#7967 is done with now. |
| 02:40:53 | JdGordon | you dont? |
| 02:41:29 | JdGordon | i'll close it, but you should annoy Zagor or Bagder to fix it for you |
| 02:42:35 | stripwax | I don't know, I might have - if I do have, should it be obvious how? |
| 02:42:55 | stripwax | (Couldn't see any obvious way to close the bug so assumed I just didn't have the special power) |
| 02:42:56 | JdGordon | yes, your in the wrong group |
| 02:43:00 | stripwax | ah |
| 02:43:09 | * | Mikachu can also close bugs, for some reason :) |
| 02:43:42 | JdGordon | it would be nice if we had a single group management system for the whole project |
| 02:44:31 | Mikachu | that wouldn't be very unixy |
| 02:46:45 | krazykit | good thing rockbox isn't unix :) |
| 02:47:38 | stripwax | darn, I should have put the FS in my svn comment. I'll try to remember to do so if I need to fix my fix :) |
| 02:47:56 | * | stripwax sleeps |
| 02:48:25 | | Quit stripwax ("http://miranda-im.org") |
| 02:51:07 | CIA-71 | New commit by jdgordon (r21709): cleanup the remote+main statusbar handling a bit, and fix the bug where the remote wps might reserve the space for the statusbar even if its disabled |
| 02:54:03 | *** | Saving seen data "./dancer.seen" |
| 02:57:17 | | Join lee321987 [0] (n=chatzill@76.250.186.194) |
| 02:58:47 | lee321987 | I have an e200R, but when I try to configure I get: "Do not use the e200R target for regular builds. Use e200 instead" |
| 02:59:10 | | Quit patmulchrone (Remote closed the connection) |
| 03:00 |
| 03:00:06 | lee321987 | What would be a "non-regular" build? |
| 03:00:40 | JdGordon | the bootloader i guess |
| 03:01:19 | | Join Blue_Dude [0] (n=chatzill@adsl-235-206-197.mco.bellsouth.net) |
| 03:01:59 | lee321987 | I think I get it. So it should be ok to choose "e200" after configure, and install it onto an e200R? |
| 03:03:00 | Blue_Dude | I'm having a hard time compiling. I keep getting an error: undefined reference to '___assert' in /libcook/bitstream.h |
| 03:06:59 | Blue_Dude | I checked out a brand new unaltered trunk and it fails to compile. Any ideas? |
| 03:08:41 | | Join mc2739 [0] (n=mc2739@cpe-67-10-234-29.satx.res.rr.com) |
| 03:11:08 | mc2739 | Zagor: for the logs −− 0-length pipe msg from 4! and Server refused connection: error duplicate name! |
| 03:11:36 | | Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") |
| 03:11:55 | | Quit lee321987 ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") |
| 03:12:39 | kkurbjun | JdGordon: I did some more testing on that bug and it looks like if you have a rwps that has a %wd tag it does not show the problem. The default wps seems to show it though |
| 03:12:58 | JdGordon | svn up.. fixed |
| 03:13:19 | kkurbjun | oh nice |
| 03:13:22 | kkurbjun | I missed that |
| 03:13:23 | kkurbjun | :-D |
| 03:14:40 | kkurbjun | nice, I just tested it and it looks like it works fine |
| 03:15:36 | kkurbjun | I did find one other bug though which does not effect usability much, but when you plug the USB coord in it shows the statusbar on the remote regardless of the setting |
| 03:15:53 | kkurbjun | I'm not sure if it does that on the main unit too or if it is intended to do that |
| 03:21:48 | JdGordon | yeah, saw there might be a issue there |
| 03:32:35 | | Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) |
| 03:38:10 | JdGordon | s/might be/is |
| 03:38:25 | JdGordon | im not too woried about them though.. might fix this evening if i get around to it |
| 03:43:13 | | Quit Blue_Dude ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") |
| 03:47:57 | | Join BdN3504 [0] (n=5ce53b4e@gateway/web/cgi-irc/labb.contactor.se/x-afe40eb37987471d) |
| 03:49:39 | BdN3504 | kkurbjun hey karl are you still online? |
| 03:53:41 | | Quit notlistening ("Leaving") |
| 03:54:36 | | Quit dmb (Read error: 54 (Connection reset by peer)) |
| 03:55:19 | | Join dmb [0] (n=Dmb@unaffiliated/dmb) |
| 03:57:58 | | Part n00b81 ("Leaving") |
| 04:00 |
| 04:04:40 | | Quit BdN3504 ("CGI:IRC (EOF)") |
| 04:11:02 | | Quit safetydan ("Leaving.") |
| 04:11:36 | | Join safetydan [0] (n=deverton@rockbox/developer/safetydan) |
| 04:13:22 | | Quit mc2739 ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") |
| 04:16:00 | | Join evilnick_home [0] (n=evilnick@pool-173-52-144-203.nycmny.east.verizon.net) |
| 04:24:06 | | Join FlynDice [0] (n=FlynDice@c-24-19-225-90.hsd1.wa.comcast.net) |
| 04:31:47 | | Join ReKleSS [0] (n=ReKleSS@d58-110-100-89.mas6.nsw.optusnet.com.au) |
| 04:33:45 | | Quit evilnick_home1 (Read error: 110 (Connection timed out)) |
| 04:46:58 | | Join patmulchrone [0] (n=pat@99-13-70-2.lightspeed.cicril.sbcglobal.net) |
| 04:54:07 | *** | Saving seen data "./dancer.seen" |
| 04:54:40 | | Quit Sajber^ (Read error: 54 (Connection reset by peer)) |
| 05:00 |
| 05:03:15 | | Join eido [0] (n=pc@user-160uvlr.cable.mindspring.com) |
| 05:04:18 | eido | can someone help me, i cant figure out what to view pictures with on a sansa e240 i got videos working after encoding them with winFF but i cannot seem to open pictures |
| 05:05:02 | safetydan | eido, only JPEG is supported. you should just be able to "play" them to view them |
| 05:07:00 | eido | ahh my bad they were bitmap |
| 05:08:51 | | Join flyback [0] (n=osmosis@c-24-3-13-158.hsd1.pa.comcast.net) |
| 05:09:28 | | Quit AndyI (Read error: 60 (Operation timed out)) |
| 05:10:56 | eido | safetydan, ty for the help |
| 05:10:57 | | Join AndyI [0] (i=AndyI@212.14.205.32) |
| 05:11:42 | flyback | haha |
| 05:11:51 | flyback | you guys are even looking at cheap samsung soc ports |
| 05:11:52 | flyback | awesome |
| 05:12:03 | * | flyback still has a j1mp3 player |
| 05:14:20 | | Join rob [0] (n=rob@adsl-76-235-168-174.dsl.klmzmi.sbcglobal.net) |
| 05:14:30 | | Join civpro [0] (n=shawnmst@c-76-125-194-217.hsd1.wv.comcast.net) |
| 05:14:36 | | Nick rob is now known as r0b- (n=rob@adsl-76-235-168-174.dsl.klmzmi.sbcglobal.net) |
| 05:14:36 | | Join _lifeless [0] (n=lifeless@188.16.119.4) |
| 05:27:08 | | Quit eido ("Leaving") |
| 05:31:50 | | Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 05:34:33 | | Quit civpro () |
| 05:51:14 | | Quit Horscht ("Verlassend") |
| 05:58:44 | | Join will_ [0] (n=will@unaffiliated/will) |
| 05:58:48 | will_ | helloooooooooo |
| 06:00 |
| 06:00:52 | CIA-71 | New commit by kkurbjun (r21710): M:robe 500 - Set the mask on the remote so that it indicates the battery status |
| 06:09:56 | will_ | So read through all the docs, having a little issue with OSX -> Sansa e260. It says it cannot open the Sansa. On the installation tab, I can install the software, but not the bootloader. |
| 06:09:59 | will_ | Thoughts? |
| 06:11:58 | JdGordon | is it a v2? |
| 06:12:08 | JdGordon | whats the sansa firmware version? |
| 06:16:28 | will_ | v1... 1 sec(it's rebuilding the db :) |
| 06:17:08 | will_ | 01.02.18A |
| 06:19:37 | | Join JdGordon| [0] (i=43a02c5a@gateway/web/freenode/x-612f42e9a7d74f9d) |
| 06:21:14 | JdGordon| | ok, doesok, you need to run rbutil as an admin |
| 06:21:21 | JdGordon| | I'm not sure how osx handles that |
| 06:21:40 | will_ | ah |
| 06:21:49 | will_ | sudo maybe hehe |
| 06:22:23 | will_ | In the .dmg, it's "rbutilqt". Is that the same thing you're talking about (didn't want to assume) |
| 06:22:44 | JdGordon| | umm... maybe |
| 06:22:47 | JdGordon| | probably |
| 06:24:49 | | Quit FOAD (Remote closed the connection) |
| 06:26:57 | will_ | Hmm... Well, I get "[INFO] Scanning disk devices...\n[INFO] e200 found - /dev/disk2\n No such file or directory" |
| 06:27:47 | JdGordon| | i think youve come at a bad time... you might want to have a look on the forums for help... |
| 06:27:58 | JdGordon| | or try doing the manual install if you're game |
| 06:28:54 | will_ | Hmm... I wonder if my Sansa is busted. When I tried to plug it into Linux (fedora11), it can't mount it. It can mount in OSX though |
| 06:28:59 | will_ | Ok, I might give that a shot. |
| 06:30:23 | JdGordon| | the linux probl;em could be a knon issue with lipgphoto |
| 06:30:26 | JdGordon| | lib* |
| 06:30:55 | will_ | ah |
| 06:33:41 | | Join bluefoxx [0] (i=bluefoxx@S0106005004792985.vs.shawcable.net) |
| 06:35:20 | bluefoxx | So, I have a Sansa e200 once again, and of course, it /has/ to have rockbox on it. Now the last time i did the bootloader I wanted the version that does away with the OF, but when I tried it the player came out bricked(had to repatch it). Also, I want to save a copy of the origional FW and bootloader somehow, If thats at all possible... |
| 06:37:19 | JdGordon| | 404.. question not found? |
| 06:38:08 | will_ | JdGordon: Do you know a guy named Mark Pulver? |
| 06:38:23 | JdGordon| | doesnt ring a bell |
| 06:38:27 | will_ | darn ok |
| 06:43:32 | will_ | JdGordon|: Ah nice, manual install worked. Thanks a bunch! |
| 06:44:19 | JdGordon| | :) |
| 06:50:59 | bluefoxx | So nobody can assist me in ripping the firmware from a v1 e200? |
| 06:53:52 | will_ | This is my first day with Rockbox :) |
| 06:54:08 | *** | Saving seen data "./dancer.seen" |
| 06:54:08 | JdGordon| | you havnt actually asked a question... |
| 06:55:04 | bluefoxx | JdGordon|: You mean me? |
| 06:55:25 | | Join __lifeless [0] (n=lifeless@188.16.119.4) |
| 06:55:37 | JdGordon| | yes |
| 06:57:00 | bluefoxx | I'm asking how I make a .mi4 file of the current firmware of the sansa e200 I have, since every other .mi4 that restores the origional FW I've found has done things like crash the player while it's trying to connect to USB or just randomly green-screens |
| 07:00 |
| 07:10:48 | | Quit _lifeless (Read error: 113 (No route to host)) |
| 07:14:10 | | Join n1s [0] (n=n1s@rockbox/developer/n1s) |
| 07:22:52 | | Join Grahack [0] (n=chri@stc92-1-82-227-106-100.fbx.proxad.net) |
| 07:26:07 | | Quit bluefoxx ("Help not found.") |
| 07:32:59 | | Quit pixelma (Nick collision from services.) |
| 07:33:00 | | Quit amiconn (Nick collision from services.) |
| 07:33:00 | | Join pixelma_ [50] (n=pixelma@rockbox/staff/pixelma) |
| 07:33:02 | | Join amiconn_ [50] (n=jens@rockbox/developer/amiconn) |
| 07:33:18 | | Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) |
| 07:33:22 | | Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) |
| 07:42:29 | | Join DarkSpectrum [0] (n=ZX@c-67-167-179-42.hsd1.mi.comcast.net) |
| 07:49:34 | | Join gartral [0] (n=Gartral@adsl-75-33-64-21.dsl.bcvloh.sbcglobal.net) |
| 07:49:59 | gartral | heya guys, I have a sansa e250 here that sansapatcher *refuses* to belive is a sansa... |
| 07:50:48 | Llorean | gartral: What firmware version? |
| 07:51:18 | gartral | Llorean: I cant tell.. the scree is smashed in |
| 07:51:36 | gartral | but I know it's in msc mode |
| 07:51:46 | will_ | lol |
| 07:51:49 | | Quit JdGordon| (Ping timeout: 180 seconds) |
| 07:51:51 | will_ | (sorry) |
| 07:51:52 | Llorean | gartral: So how do you know it's a V1? |
| 07:52:03 | gartral | its also running an old Rockbox version |
| 07:52:24 | Llorean | How was Rockbox installed without Sansapatcher recognizing it? |
| 07:52:38 | gartral | Windows + rbutil |
| 07:53:23 | Llorean | rbutil uses the exact same code as sansapatcher. Literally. |
| 07:54:04 | Llorean | Why aren't you using rbutil, anyway? |
| 07:54:05 | gartral | I know.. that's whats wierd |
| 07:54:22 | gartral | trying to install 7pre4 bootloader |
| 07:55:03 | rasher | Err, there's no 7pre4 for sansas |
| 07:55:58 | gartral | ermm.. ok, which ever one is the bootloader that makes it boot too RB on USB insert |
| 07:56:20 | Llorean | You mean the one from the flyspray task? Why didn't you just refer to it as such? |
| 07:56:42 | gartral | I honestly thought it was a varient of 7pre4.. >.> |
| 07:57:41 | gartral | http://gar.pastebin.com/f29c75381 heres the error |
| 07:58:19 | Llorean | You're not supposed to point it at the mount point. |
| 07:58:48 | gartral | ohh.. |
| 08:00 |
| 08:04:56 | rasher | In fact, it's not supposed to be mounted at all |
| 08:08:54 | flyback | http://www.sparkfun.com/commerce/product_info.php?products_id=9237 |
| 08:10:11 | | Part will_ ("Leaving") |
| 08:12:59 | gartral | how do i determine the device node? [dev/sdX structure was thrown out the window for Jaunty >.<] |
| 08:18:33 | | Quit DarkSpectrum (Read error: 104 (Connection reset by peer)) |
| 08:20:19 | gartral | im just haveing one of thos re-re days >.> |
| 08:20:59 | flyback | lsusb |
| 08:21:01 | flyback | :P |
| 08:21:06 | flyback | dmesg and grep it for the same thing etc |
| 08:21:54 | Llorean | Have you tried simply running sansapatcher without parameters so it can autodetect? |
| 08:22:12 | gartral | that's what I just did, reports dev/sdc |
| 08:24:48 | gartral | ok, all done.. thank you much Llorean |
| 08:29:13 | | Join ender` [0] (i=krneki@foo.eternallybored.org) |
| 08:31:46 | GodEater | /dev/sdX was NOT thrown out of the window in jaunty - that's complete tosh |
| 08:33:35 | gartral | yes, I discovered that... but it isnt "visable" from command line.. and was annoying |
| 08:34:31 | GodEater | what isn't visible ? |
| 08:34:38 | | Part safetydan ("Leaving.") |
| 08:35:20 | | Join Grahack1 [0] (n=chri@stc92-1-82-227-106-100.fbx.proxad.net) |
| 08:37:28 | gartral | any /dev/sdXX device nodes |
| 08:39:18 | GodEater | that's also rubbish |
| 08:39:50 | gartral | do you want a screenshot? I swear i cant see them |
| 08:40:32 | JdGordon | you wont see any if nothing is attached |
| 08:40:40 | | Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) |
| 08:41:04 | gartral | JdGordon: I have 3 flashdrives, and a dap plugged in almost 24/7 |
| 08:42:38 | GodEater | gartral: so "ls /dev/sd*" lists nothing at all is what you're saying |
| 08:45:00 | gartral | that works... but cd /dev/ && ls doesn't show them |
| 08:45:28 | gartral | which makes no sense what so ever.. |
| 08:46:07 | Unhelpful | it makes so little sense that i don't believe it's happening. |
| 08:46:21 | Llorean | This is pretty off-topic in here at this point anyway. Basic computer use stuff. |
| 08:46:57 | gartral | ;opens mouth and insert foot |
| 08:48:47 | Llorean | gartral: And in the future, try to actually read the documentation on how to use a tool before claiming it doesn't work. This isn't the first time you've claimed something is broken or isn't working right, and it's turned out you just weren't careful. |
| 08:49:31 | | Quit Grahack (Read error: 110 (Connection timed out)) |
| 08:50:35 | gartral | yea.. i know.. im a bit jumpy... |
| 08:50:42 | gartral | sorry |
| 08:54:10 | *** | Saving seen data "./dancer.seen" |
| 08:55:46 | | Join Rob2222 [0] (n=Miranda@p4FDCF7A5.dip.t-dialin.net) |
| 08:56:34 | amiconn | Bagder: It looks like the new buildclient doesn't reconnect if it was running during a network disconnect, at least if it was a longer one |
| 08:57:13 | Bagder | yeah, we discussed that last night |
| 08:57:22 | Bagder | the client doesn't seem to notice the disconnect |
| 08:58:20 | | Quit Telazorn (Read error: 110 (Connection timed out)) |
| 09:00 |
| 09:02:08 | * | amiconn also wonders what's up with the locked svn working copy on one of the new buildclients |
| 09:03:11 | GodEater | amiconn: can you tell which one ? |
| 09:05:06 | Bagder | hm, I guess we risk that with killed builds... |
| 09:08:04 | GodEater | my client is being told "duplicate name" at the moment |
| 09:11:24 | | Join petur [50] (n=petur@rockbox/developer/petur) |
| 09:12:29 | rasher | It seems the server doesn't cope with disappearing-then-reappearing clients very well |
| 09:13:04 | | Quit Rob2223 (Read error: 110 (Connection timed out)) |
| 09:15:02 | rasher | Bagder: svn cleanup seems to be rather cheap, so maybe just run that always before building? |
| 09:15:18 | Bagder | yes, I believe so too |
| 09:15:31 | Bagder | or even before svn update |
| 09:15:57 | amiconn | Why does killing builds risk a locked working copy? |
| 09:16:12 | Bagder | if the svn operation gets killed |
| 09:16:51 | amiconn | Hmm. Couldn't we ensure that 'svn update' never gets killed? |
| 09:17:16 | amiconn | If a build is killed while svn updates, just let svn update finish and then stop |
| 09:17:44 | Bagder | well, that's potentially a very long and slow operation |
| 09:17:59 | Bagder | so it'd be wasted cpu time |
| 09:20:29 | | Join jfc^2 [0] (n=john@dpc691978010.direcpc.com) |
| 09:22:07 | | Join AndyIL [0] (i=AndyI@212.14.205.32) |
| 09:22:48 | amiconn | The client needs to update svn anyway if it wants to participate at all |
| 09:23:08 | Bagder | yes, but next build might be to another rev |
| 09:25:02 | GodEater | my client has been booted again with another duplicate name error |
| 09:25:24 | Bagder | mine too |
| 09:25:44 | Bagder | clearly it "leaks" client names |
| 09:28:36 | | Join Thundercloud [0] (i=thunderc@81.187.69.84) |
| 09:33:09 | | Quit AndyI (Read error: 110 (Connection timed out)) |
| 09:36:21 | | Quit jfc (Read error: 110 (Connection timed out)) |
| 09:48:58 | ReKleSS | does the H120 have a hardware watchdog or something? |
| 09:49:08 | ReKleSS | I think I've gotten the cpu to halt, but it still powers down after a second or so |
| 09:49:20 | Bagder | it doesn't |
| 09:49:22 | | Quit n1s (Read error: 110 (Connection timed out)) |
| 09:49:30 | ReKleSS | ok |
| 09:49:48 | ReKleSS | any idea why it's powering down? |
| 09:50:55 | | Quit Thundercloud (Remote closed the connection) |
| 09:56:01 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
| 10:00 |
| 10:08:42 | | Quit gartral ("Lost terminal") |
| 10:10:41 | | Join efyx_ [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) |
| 10:16:50 | gevaerts | Bagder: rasher's binsize build client also tends to get stuck connections on network changes, using plain netcat. Not sure if this is useful information |
| 10:17:43 | Bagder | I think we can just timeout the clients if nothing was "heard" from the server in say 60 seconds |
| 10:17:59 | Bagder | the server sends a ping much more frequently than so |
| 10:18:06 | | Quit Zarggg () |
| 10:19:33 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
| 10:22:51 | | Join bluefoxx [0] (i=bluefoxx@S0106005004792985.vs.shawcable.net) |
| 10:23:07 | gevaerts | it could be the client's read() or write() itself that's stuck. |
| 10:23:16 | Bagder | they're non-blocking |
| 10:23:30 | Bagder | or should be |
| 10:23:30 | bluefoxx | So I managed to rip the firmware from my mp3 player, if anyone wants a copy of some old firmware for the e200 series that isn't buggy... |
| 10:24:58 | Bagder | http://daniel.haxx.se/sansa/fw/ ... |
| 10:25:54 | bluefoxx | I've in the past tried .mi4 files from places like his site and links on the rockbox site and found myself with a shiny brick whenever the stock firmware tried to do a database refresh... |
| 10:26:08 | gevaerts | I only know that I've seen netcat stay stuck for weeks. I have no idea how these things actually work :) |
| 10:26:17 | Bagder | bluefoxx: those are all official versions |
| 10:26:20 | bluefoxx | it happens to sansas that my friends have after they update to newer firmware too i've found... |
| 10:26:26 | Bagder | and I bet your version is one of them |
| 10:27:04 | | Join mt [0] (n=MTee@41.206.134.249) |
| 10:27:11 | gevaerts | bluefoxx: you do know that you need to update the bootloader and main firmware together, right? |
| 10:27:25 | bluefoxx | hmn? |
| 10:27:58 | bluefoxx | Bagder: My version is about as early as i can find |
| 10:28:06 | | Join Zarggg [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) |
| 10:28:12 | bluefoxx | came from a barely used sansa that was bought when they just came out |
| 10:28:16 | | Quit BHSPitMonkey ("Ex-Chat") |
| 10:29:05 | Bagder | without version number? :-) |
| 10:29:13 | Llorean | I don't understand what this fixation on "early" is. Plenty of people use later versions without any trouble. Is your Sansa broken, and this one just shows the fewest bugs? |
| 10:29:37 | bluefoxx | Llorean: stock firmware borks on database refresh after updates on my |
| 10:29:39 | bluefoxx | me* |
| 10:29:50 | bluefoxx | let me dig out a picture of what it did... |
| 10:29:52 | Bagder | that's usually due to fs problems |
| 10:30:50 | | Join n1s [0] (n=n1s@rockbox/developer/n1s) |
| 10:31:34 | | Join FOAD [0] (n=dok@dinah.blub.net) |
| 10:32:03 | gevaerts | bluefoxx: did you install the corresponding BL file at the same time? |
| 10:32:18 | | Quit kachna|lappy (Read error: 113 (No route to host)) |
| 10:32:20 | bluefoxx | gevaerts: i'm not sure what your talking about here... |
| 10:32:34 | gevaerts | bluefoxx: have another look at http://daniel.haxx.se/sansa/fw/ then |
| 10:33:13 | gevaerts | There's PP5022.mi4 and BL_SD_boardSupportSD.rom. Did you update both of them? |
| 10:33:41 | * | gevaerts knows that at least on c200, if you don |
| 10:33:46 | gevaerts | 't do this, you get problems |
| 10:34:12 | Bagder | on the e200 you can mostly just update the fw part |
| 10:34:18 | bluefoxx | This usually happens after following the unbrick FAQ, which caused me to seek out http://www.rockbox.org/twiki/bin/view/Main/SansaFAQ#Can_I_disable_the_Sansa_c200_fir |
| 10:34:55 | gevaerts | Bagder: even if the bootloader is very early? |
| 10:35:18 | bluefoxx | both of which caused the thing to freak out under stock FW when it tried to do database refreshes |
| 10:35:26 | Bagder | I'm not sure, but during my experimentations I rarely replaced the BL one |
| 10:35:30 | bluefoxx | http://i31.tinypic.com/2r6mamh.jpg |
| 10:35:35 | bluefoxx | is what would tend to happen |
| 10:35:46 | bluefoxx | or similar things but with green or blue lines |
| 10:36:26 | bluefoxx | that time was rockbox freaking out at me after an update was suggested, but thats the general idea of what happens... |
| 10:37:27 | Llorean | That seems like a hardware problem, especially if it's also happening in Rockbox. |
| 10:37:31 | | Quit martian67 (Read error: 60 (Operation timed out)) |
| 10:37:39 | gevaerts | Anyway, I'd say that either your filesystem is corrupted, or the bootloader and main firmware don't match. If it's the filesystem and chkdsk/fsck.vfat don't help, try sansa.fmt first |
| 10:37:41 | bluefoxx | i've seen it on at least 6 sansas now |
| 10:38:12 | * | gevaerts thinks that if one person sees this on all sansas he touches, and nobody else sees it, there seems to be a clear correlation |
| 10:38:17 | bluefoxx | http://i26.tinypic.com/10ie2vm.jpg is what the firmware update causes on database refreshes |
| 10:38:23 | bluefoxx | and no, its not on any that i touch |
| 10:38:37 | Llorean | bluefoxx: Seriously, nobody else has ever reported this problem to us with Rockbox. |
| 10:38:46 | bluefoxx | i've several friends who have sansas. they update the firmware, that happens. |
| 10:39:08 | bluefoxx | anyways, thats what the .mi4 files i got off the website did to me |
| 10:39:09 | Bagder | maybe you're cursed? B) |
| 10:39:13 | gevaerts | bluefoxx: you still haven't said if you actually updated the bootloader as well |
| 10:39:15 | bluefoxx | my friends don't use rockbox |
| 10:39:34 | bluefoxx | i used the latest sansapatcher.exe file i found if thats what you mean |
| 10:39:35 | | Join martian67 [0] (n=martian6@about/linux/regular/martian67) |
| 10:39:42 | bluefoxx | i don't bother with the OF myself if i can't help it |
| 10:40:02 | gevaerts | that's *not* what I mean |
| 10:40:11 | bluefoxx | then what *do* you mean? |
| 10:40:17 | gevaerts | BL_SD_boardSupportSD.rom |
| 10:40:37 | bluefoxx | ? |
| 10:40:38 | | Quit martian67 (SendQ exceeded) |
| 10:40:43 | * | gevaerts gives up |
| 10:40:49 | * | GodEater doesn't blame gevaerts |
| 10:41:25 | bluefoxx | bah, whatever. rockbox works on the thing again, i have my firmware file to use. i'm going to bed before i start passing out when i stand up again. |
| 10:41:29 | | Quit bluefoxx ("bye") |
| 10:41:49 | amiconn | Bagder: I wonder whether this non-awareness of disconnects is a linux problem. I've seen XChat on linux need more than 15 minutes to detect a broken connection, whereas on windows it usually needs less than a minute |
| 10:42:01 | | Quit Unhelpful (Read error: 113 (No route to host)) |
| 10:42:19 | amiconn | Using some sort of heartbeat packets would probably help |
| 10:42:47 | Bagder | it's TCP |
| 10:42:57 | Bagder | it's designed to not notice idleness |
| 10:44:08 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
| 10:54:12 | *** | Saving seen data "./dancer.seen" |
| 10:55:54 | | Join martian67 [0] (n=martian6@about/linux/regular/martian67) |
| 10:58:46 | gevaerts | Bagder: do you use SO_KEEPALIVE? |
| 11:00 |
| 11:09:54 | | Join martian67_ [0] (n=martian6@ip-216-194-109-30.wildroseinternet.ca) |
| 11:10:48 | | Quit martian67_ (SendQ exceeded) |
| 11:11:21 | | Join martian67_ [0] (n=martian6@ip-216-194-109-30.wildroseinternet.ca) |
| 11:18:34 | | Quit martian67 (Read error: 110 (Connection timed out)) |
| 11:21:04 | | Quit martian67_ (Read error: 60 (Operation timed out)) |
| 11:25:01 | | Join martian67_ [0] (n=martian6@ip-216-194-109-30.wildroseinternet.ca) |
| 11:26:56 | | Join kachna|lappy [0] (n=kachna@r3g248.net.upc.cz) |
| 11:32:43 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
| 11:35:58 | | Join Sylvai1 [0] (n=sylvain@ABordeaux-256-1-38-18.w90-11.abo.wanadoo.fr) |
| 11:36:08 | Sylvai1 | Hi |
| 11:36:26 | Sylvai1 | someone may help me ? I have a question about rockbox |
| 11:36:59 | Sylvai1 | I have some files I don't want to register in database |
| 11:37:21 | Mikachu | are they all in the same directory? |
| 11:37:33 | Sylvai1 | I remember that it's possible to put a file name ".unregister" or something like this, but I don't remember the exact correct name |
| 11:37:35 | Sylvai1 | yes |
| 11:37:39 | Mikachu | database.ignore |
| 11:37:45 | Sylvai1 | thank you |
| 11:37:50 | Mikachu | there is one in your .rockbox dir |
| 11:37:53 | Sylvai1 | so, on my iPod |
| 11:38:47 | Sylvai1 | I can put a file "database.ignore" in root folder, and a "database.unignore" file in Music/ folder, if I want to analyse only files from this Music/ folder ? |
| 11:39:03 | | Join Torne [0] (i=torne@lowell.wolfpuppy.org.uk) |
| 11:39:08 | | Quit daurn (Read error: 104 (Connection reset by peer)) |
| 11:39:14 | | Join daurn [0] (n=daurnima@unaffiliated/daurnimator) |
| 11:39:24 | Mikachu | i think so, yes |
| 11:39:42 | Sylvai1 | I think so also, I did it ago |
| 11:39:46 | Sylvai1 | thank you |
| 11:39:47 | Sylvai1 | bye |
| 11:39:57 | Mikachu | :) |
| 11:40:02 | | Part Sylvai1 |
| 11:45:28 | kugel | Mikachu: grml |
| 11:45:33 | kugel | we were about to remove that possiblity for speeding things up :/ |
| 11:45:39 | kugel | or we at least thought about it |
| 11:45:57 | gevaerts | well it *is* still there |
| 11:46:35 | * | gevaerts proposes a setting for it ;) |
| 11:49:16 | * | GodEater still thinks it was a dumb idea in the first place :( |
| 11:49:36 | | Join mcuelenaere [0] (n=mcuelena@78-21-191-122.access.telenet.be) |
| 11:49:46 | * | kugel agrees with GodEater |
| 11:50:19 | | Quit n1s (Read error: 110 (Connection timed out)) |
| 11:53:09 | Grahack1 | mcuelenaere: hi, great you are here, I was trying to work on the Lua plugin myself (C newbie though), and I have several things to say. You seem to appear each time at the good moment |
| 11:53:17 | Grahack1 | 1) what is the difference between 'const unsigned char* str' and 'const char* str' ? |
| 11:53:30 | mcuelenaere | that's a C question in general ;) |
| 11:53:54 | Mikachu | the first is unsigned, the other is signed or unsigned depending on the compiler |
| 11:54:03 | mcuelenaere | a char is on all our targets 8 bits, and when it's unsigned, it uses all those 8 bits for data storage |
| 11:54:20 | Torne | it uses all 8 bits when it's signed as well |
| 11:54:21 | gevaerts | mcuelenaere: it always does that... |
| 11:54:21 | mcuelenaere | when signed, it only uses 7 bits and the 8 bit to store whether it's a negative or positive number |
| 11:54:47 | mcuelenaere | gevaerts: not when it's signed, doesn't it? |
| 11:54:48 | Torne | whether char is signed or not makes absolutely no difference to anything other than "what happens when you cast it to a wider type" |
| 11:54:49 | Mikachu | that's not exactly true |
| 11:55:01 | gevaerts | mcuelenaere: that sign bit is also data... |
| 11:55:01 | daurn | mcuelenaere, Grahack1 wants bindings to the funcs in unicode.c, you able to bind them for him? |
| 11:55:22 | Mikachu | mcuelenaere: -0 isn't encoded, that is used for -128, so there is 1/256th data in the sign bit :) |
| 11:55:44 | mcuelenaere | ok, I was wrong then :) |
| 11:55:47 | Torne | mcuelenaere: char represents one of 256 values, whether it's signed or not |
| 11:56:07 | Grahack1 | daurn: I was making progress this way, maybe I won't need him to make it who knows... just some help |
| 11:56:12 | dz | with unsigned char, the high bit is valued 128, with signed it's -128 |
| 11:56:18 | mcuelenaere | daurn: are they exposed over the plugin struct? |
| 11:56:52 | mcuelenaere | Torne: sure, but they have a different meaning |
| 11:56:54 | Mikachu | but yeah, saying it isn't used for data in signed is like saying it's used for saying if the value is higher or lower than 127 in unsigned |
| 11:57:10 | * | mcuelenaere decides to read the logs |
| 11:57:15 | Torne | mcuelenaere: not until you cast to something else |
| 11:57:39 | Grahack1 | so this seems to bea good question, on which the team has different ideas :) |
| 11:57:42 | dz | Torne: or try to compare them |
| 11:58:00 | Torne | dz: see under casting to something else :) |
| 11:58:06 | Torne | comparing unlike types is coercion |
| 11:58:15 | gevaerts | Torne: not really. 0xff > 0x01 ? |
| 11:58:49 | Grahack1 | is there anyone here interested/involved in the dev of the Lua plugin apart from mcuelenaere? |
| 11:58:52 | Torne | gevaerts: always, yes, there is no 0xff from C's pov if it's signed :) |
| 11:59:07 | gevaerts | Torne: 0xfe > 0x01? :) |
| 11:59:07 | dz | Torne: example, does a character fall within the range of ASCII? > 127 or < 0, depending on if it's signed or unsigned |
| 11:59:09 | mcuelenaere | Grahack1: safetydan did the initial Lua porting |
| 11:59:12 | | Quit Rob2222 () |
| 11:59:18 | gevaerts | Even if they're both the same type, that depends on whether they are signed. No casting involved |
| 11:59:38 | Torne | gevaerts: but there's no such thing as a signed char with value 0xfe, is my point there :) |
| 11:59:43 | Grahack1 | mcuelenaere: 2) I noticed a weird difference of behaviour on the sim and on my DAP. In some Lua code, the sim does 3%2 = 1 and 2^3 = 1 and the DAP 3%2 = 3 and 2^3 = 0 |
| 11:59:50 | Torne | there's one with in-memory representation of 0xfe but C doesn't care |
| 12:00 |
| 12:00:06 | gevaerts | Torne: true, but sometimes that matters |
| 12:00:16 | mcuelenaere | Grahack1: hmm, will look into it; what is the ^ operator supposed to do in Lua? |
| 12:00:32 | gevaerts | i.e. if you write them to disk and read them back on another arch where default signedness is different |
| 12:00:54 | Grahack1 | ^ is the power operator |
| 12:01:49 | Grahack1 | it needs the math lib, which I'm trying to code in pure Lua (well, basic functions) |
| 12:02:18 | mcuelenaere | hmm pow() is currently an empty function currently (returning 0 |
| 12:02:20 | mcuelenaere | ) |
| 12:02:39 | mcuelenaere | so the sim is using a different one than the DAP is |
| 12:03:12 | Grahack1 | BTW do you have plans for the math lib ? not putting pressure at all because I sorted my problems with my libmath, but just to know |
| 12:03:19 | daurn | mcuelenaere, could you instead just floor the exponent, and multiply it out? |
| 12:03:33 | | Join Sajber^ [0] (n=Sajber@h-142-185.A213.priv.bahnhof.se) |
| 12:04:19 | mcuelenaere | daurn: why floor the exponent? it isn't a float value |
| 12:04:22 | mcuelenaere | (not in Rockbox) |
| 12:04:34 | daurn | mcuelenaere, ok then, don't :P |
| 12:05:17 | mcuelenaere | well ideally, at some point some of my integer hacks in Lua should get removed and that patch that separates float and integer usage should get applied |
| 12:10:48 | | Quit linuxstb (Remote closed the connection) |
| 12:10:52 | Grahack1 | So there is hope. My libmath is in this zip, with test_libmath.lua that shows % and ^ issues if libmath not used: http://fezzik.free.fr/tmp/grualibs.zip |
| 12:11:53 | mcuelenaere | Grahack1: well, 'at some point' doesn't mean in the near future ;) |
| 12:14:38 | Grahack1 | I'll be patient, it will be nice even in 10 years. |
| 12:14:40 | mcuelenaere | Grahack1: if the utf8 functions you need are exported through the plugin struct, they should get wrapped to Lua automatically |
| 12:16:15 | Grahack1 | you mean if it's in this page ? mcuelenaere.alwaysdata.net/rockbox_api_example_3/list.html">http://mcuelenaere.alwaysdata.net/rockbox_api_example_3/list.html |
| 12:16:53 | Grahack1 | (the relevant text file in my source tree should be up to date) |
| 12:17:05 | mcuelenaere | ehm yes, but that's an old one; try http://svn.rockbox.org/viewvc.cgi/trunk/apps/plugin.h?view=markup (starting at struct plugin_api { |
| 12:17:21 | Grahack1 | or docs/PLUGIN_API |
| 12:17:25 | mcuelenaere | (and I'm 'planning' to rework the API documentator thingy) |
| 12:17:32 | mcuelenaere | that's also outdated I think |
| 12:17:53 | Grahack1 | arf, I'll look into plugin.h then |
| 12:18:41 | mcuelenaere | actually, rockbox_api_example_3 is based on docs/PLUGIN_API |
| 12:19:40 | Grahack1 | generated from the head of the svn repo ? |
| 12:20:52 | | Quit mt (Read error: 110 (Connection timed out)) |
| 12:20:57 | mcuelenaere | yes, but at that time though |
| 12:21:24 | mcuelenaere | (it isn't updated since then probably though) |
| 12:23:43 | daurn | Grahack1, seems you already have the funcs then :D |
| 12:23:50 | Grahack1 | it seems that some are: utf8decode iso_decode utf16LEdecode utf16BEdecode utf8encode |
| 12:24:06 | mcuelenaere | yeah I looked into utf8decode, and that probably requires manual porting |
| 12:24:11 | mcuelenaere | because of the unsigned short* ucs part |
| 12:24:27 | mcuelenaere | (which rocklib_aux.pl can't handle) |
| 12:25:12 | CIA-71 | New commit by zagor (r21711): Fail more gracefully on svn error. |
| 12:26:40 | Grahack1 | mcuelenaere: this is the only three conversion functions I need to implement: http://code.google.com/p/lomp/source/browse/trunk/general.lua#68 |
| 12:26:51 | wincent | Hello all! How can I change the sampling rate on UI simulator? |
| 12:27:55 | mcuelenaere | hmm that'll probably require some new Lua type as Lua won't be able to handle UTF-16 |
| 12:29:18 | | Join BdN3504 [0] (n=5ce53b4e@gateway/web/cgi-irc/labb.contactor.se/x-4f565c59e6d1025a) |
| 12:29:20 | AlexP | Bagder / zagor: What does e.g. Failed build iaudiom5sim: Status 256 |
| 12:29:21 | * | mcuelenaere wonders why Grahack1 wants to port a music player app through Lua on a music playing firmware |
| 12:29:26 | AlexP | ...mean |
| 12:29:34 | daurn | mcuelenaere, its just strings |
| 12:29:53 | BdN3504 | is it normal, that i get the error: "first allocation unit is not valid" when i run chkdsk on my sansa e270? |
| 12:30:00 | BdN3504 | v1 that is |
| 12:30:35 | mcuelenaere | daurn: yes, but UTF-16 strings contains lots of 0 and Lua can only handle null-terminated strings |
| 12:30:41 | | Join Rob2222 [0] (n=Miranda@p4FDCF7A5.dip.t-dialin.net) |
| 12:30:46 | daurn | Grahack1, you need utf16BE, ascii , utf8 and utf16 conversion for id3v2 |
| 12:30:48 | Grahack1 | I don't want to port the whole app, only the read/write tag things. Through Lua because I don't want to learn C. |
| 12:31:08 | daurn | mcuelenaere, lua doesn't have null terminated strings at all, strings are 8bit safe |
| 12:31:21 | Grahack1 | daurn: I was indeed looking where those functions were needed |
| 12:31:28 | mcuelenaere | daurn: ah it does? |
| 12:31:37 | daurn | mcuelenaere, of course |
| 12:35:42 | mcuelenaere | Grahack1: see firmware/common/unicode.c for a description of what those functions do |
| 12:42:26 | daurn | Grahack1, typo fixed in newest commit :) |
| 12:42:58 | | Quit kugel (Read error: 104 (Connection reset by peer)) |
| 12:46:08 | | Quit __lifeless (Remote closed the connection) |
| 12:49:12 | BdN3504 | scandisk seemingly repaired tha FAT, but now the volume is shown as a removable disk as opposed to local on "my computer" (i'm using winxp pro). |
| 12:50:09 | daurn | Grahack1, you seem to have every function you need already... |
| 12:51:03 | daurn | oh, cept the BOM reading function is #if 0'd out |
| 12:51:25 | BdN3504 | rockbox woN't have any difficulties dealing with this, will it? |
| 12:54:17 | *** | Saving seen data "./dancer.seen" |
| 12:59:02 | Grahack1 | daurn: I'm trying to figure out what parameters to give them to make them mimic your functions |
| 13:00 |
| 13:00:15 | daurn | Grahack1, shouldn't be too hard if the functions are bound reasonably.... |
| 13:10:45 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
| 13:12:34 | kugel | gevaerts: what's the dual boot button? |
| 13:18:37 | | Join Unhelpful [0] (n=Militant@rockbox/developer/Unhelpful) |
| 13:20:20 | | Quit BdN3504 ("CGI:IRC (EOF)") |
| 13:27:08 | | Join rodpod [0] (n=rod@74-133-38-196.dhcp.insightbb.com) |
| 13:27:57 | | Join desowin [0] (n=desowin@atheme/member/desowin) |
| 13:28:29 | * | gevaerts doesn't know |
| 13:30:16 | kugel | gevaerts: found it by looking at the code... |
| 13:32:49 | | Join boobaloo [0] (n=boobaloo@84.42.45.44) |
| 13:33:04 | | Quit gevaerts (Nick collision from services.) |
| 13:33:14 | | Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) |
| 13:33:29 | gevaerts | we do have a manual you know ;) |
| 13:41:23 | | Join DarkDefender [0] (n=rob@78-69-30-229-no36.tbcn.telia.com) |
| 13:45:39 | | Join Universal [0] (n=Unvrsal@user-54479ea3.wfd85b.dsl.pol.co.uk) |
| 13:48:50 | | Quit kugel (Read error: 110 (Connection timed out)) |
| 13:56:25 | | Join petur2 [50] (n=petur@rockbox/developer/petur) |
| 13:56:45 | | Quit petur (Nick collision from services.) |
| 13:56:48 | | Nick petur2 is now known as petur (n=petur@rockbox/developer/petur) |
| 13:59:07 | CIA-71 | New commit by mcuelenaere (r21712): Lua: expose SCREEN_MAIN & SCREEN_REMOTE (for rb.lcd_*() functions) |
| 14:00 |
| 14:09:50 | | Quit lilltiger (Remote closed the connection) |
| 14:10:29 | dionoea | mcuelenaere: hi. You could even do something like: rb.lcd:putsxy() and rb.remote:putsxy() (no need to add an extra argument to specify the screen) |
| 14:11:30 | mcuelenaere | hmm and then rb.lcd & rb.remote is a metatable containing the constant? |
| 14:12:27 | | Quit Universal ("Leaving") |
| 14:12:56 | dionoea | mcuelenaere: rb.lcd/remote would be tables containing that constant and they would share the same meta table to define the methods |
| 14:13:21 | dionoea | kind of like 2 instances of the same class (in OOP speak) |
| 14:13:48 | dionoea | it's just an idea I had when reading your commit message :) |
| 14:14:17 | mcuelenaere | yes, a bit like rockbox images are currently handled |
| 14:14:21 | mcuelenaere | I'll put it on my TODO list :) |
| 14:14:23 | daurn | dionoea, it would be bettter if it was the screen/contents that could be operated on |
| 14:14:50 | daurn | eg, mybmp:putlcd ( x ,y ) and mybmp:putremote( x , y ) |
| 14:14:55 | daurn | s/mybmp/mytext/ |
| 14:16:01 | dionoea | mcuelenaere: ok :) I can have a look too if you want |
| 14:16:40 | mcuelenaere | dionoea: sure |
| 14:17:24 | mcuelenaere | daurn: and what's mytext? (an instance of .. ?) |
| 14:17:28 | dionoea | I have a 5 day week-end coming up ... so that should leave me some time to code |
| 14:17:36 | daurn | mcuelenaere, could be a string, or anything really |
| 14:17:55 | dionoea | daurn: the action is really lcd specific, not string specific |
| 14:18:03 | dionoea | so it belongs in an lcd class IMO |
| 14:18:06 | mcuelenaere | oh, are putlcd and putremote global methods here? |
| 14:18:15 | mcuelenaere | and I agree with dionoea |
| 14:18:20 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
| 14:18:25 | daurn | no, they are in the string's __index metatable |
| 14:18:33 | | Quit kugel (Read error: 104 (Connection reset by peer)) |
| 14:18:34 | mcuelenaere | that sounds a bit hacky |
| 14:18:44 | | Join kugel_ [0] (n=kugel@e178108120.adsl.alicedsl.de) |
| 14:18:47 | dionoea | bbl |
| 14:18:50 | | Nick kugel_ is now known as kugel (n=kugel@e178108120.adsl.alicedsl.de) |
| 14:19:00 | daurn | so you rather lcd:putstring ( mystring , x , y ) ? |
| 14:19:08 | kugel | gevaerts: it's not mentioned there, hence I needed to look at the code |
| 14:20:44 | dionoea | daurn: no, lcd:putstring(x, y, mystring) looks better :D |
| 14:20:59 | | Quit boobaloo ("ChatZilla 0.9.85 [Firefox 3.5/20090624025744]") |
| 14:21:01 | mcuelenaere | daurn: there's no putstring method |
| 14:21:06 | kugel | someone give the clip sim button descriptions :S |
| 14:21:24 | mcuelenaere | and yes, it looks better to me IMO (and fits the original Rockbox API) |
| 14:21:30 | * | daurn made up putstring, but whatever you use to print a string on the screen, or w/e |
| 14:23:08 | dionoea | mcuelenaere: does lua run on all the targets? |
| 14:23:15 | | Quit robin0800 ("Leaving") |
| 14:23:22 | mcuelenaere | dionoea: all those with PLUGIN_RAM_SIZE > some value |
| 14:23:25 | dionoea | (if yes I'll see if I can port some of the games to lua, like solitaire) |
| 14:23:27 | dionoea | ah ok |
| 14:23:33 | | Join robin0800 [0] (n=robin080@81.98.157.181) |
| 14:23:48 | mcuelenaere | dionoea: #if (PLUGIN_BUFFER_SIZE >= 0x80000) |
| 14:24:08 | mcuelenaere | so most of them |
| 14:24:38 | dionoea | I'll do it as a poc then :D |
| 14:25:01 | daurn | Grahack1, you there? |
| 14:25:07 | daurn | dionoea, poc? |
| 14:25:50 | dionoea | proof of concept |
| 14:25:56 | gevaerts | kugel: http://download.rockbox.org/manual/rockbox-h100/rockbox-buildch3.html#x5-260003.1.3 |
| 14:26:18 | kugel | gevaerts: eh |
| 14:26:34 | kugel | I searched for "dual boot" and "dualboot", but not "dual-boot" :/ |
| 14:26:47 | kugel | and it's wrong anyway. |
| 14:26:51 | kugel | You need REC only |
| 14:29:16 | kugel | but my lecturer was very enthusiastic and impressed by rockbox |
| 14:31:06 | gevaerts | did you show doom? |
| 14:31:34 | kugel | no, he saw , but didn't start it |
| 14:39:24 | | Quit robin0800 ("Leaving") |
| 14:39:39 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
| 14:39:49 | | Join petur2 [50] (n=petur@rockbox/developer/petur) |
| 14:40:06 | | Quit petur (Nick collision from services.) |
| 14:40:11 | | Nick petur2 is now known as petur (n=petur@rockbox/developer/petur) |
| 14:42:21 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
| 14:45:18 | CIA-71 | New commit by kugel (r21713): Make the Sansa Clip and Fuze sim keymapping more like other Sansas with regard to the use of the numpad |
| 14:47:08 | rasher | Erp, lots and lots of failed builds from my buildclient |
| 14:48:17 | rasher | Ah, "svn: No such revision 22000" |
| 14:48:20 | rasher | Naughty |
| 14:48:41 | | Join LambdaCalculus37 [0] (i=44a0430d@gateway/web/freenode/x-90639414ff8171f0) |
| 14:49:08 | | Quit Far^Side ("Leaving") |
| 14:54:21 | *** | Saving seen data "./dancer.seen" |
| 14:54:52 | | Join petur2 [50] (n=petur@rockbox/developer/petur) |
| 14:55:05 | | Quit petur (Nick collision from services.) |
| 14:55:09 | | Nick petur2 is now known as petur (n=petur@rockbox/developer/petur) |
| 14:55:39 | | Quit Bombe (Remote closed the connection) |
| 14:57:24 | | Join MxxCon [0] (i=donuts@ool-18b9baa8.dyn.optonline.net) |
| 14:58:25 | MxxCon | hey folks. changelog for 3.3 says some targets don't update the screen w/ backlight off. for sansa e200, so i have to do anything or it's enabled by default? |
| 14:59:13 | MxxCon | (sorry for grammar, didn't have my coffee yet) |
| 14:59:21 | rasher | I |
| 14:59:29 | rasher | I'm pretty sure it's enabled by default |
| 15:00 |
| 15:03:32 | kugel | MxxCon: you can't even disable it |
| 15:05:08 | mcuelenaere | kugel: is there a define to enable this behaviour? |
| 15:06:41 | kugel | mcuelenaere: yes, HAVE_LCD_ENABLE || HAVE_LCD_SLEE |
| 15:06:44 | kugel | P |
| 15:06:58 | MxxCon | i didn't want to disable it, just want to make sure that it was on |
| 15:07:06 | mcuelenaere | kugel: ok, thanks |
| 15:07:12 | kugel | MxxCon: I meant to say it is always on |
| 15:07:43 | MxxCon | cool, thanx |
| 15:11:02 | GodEater | I can't help wondering how valid Torne's comments are on FS #9708, given he's running a build with other patches in it too... |
| 15:11:19 | | Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) |
| 15:16:31 | | Part MxxCon |
| 15:18:20 | mcuelenaere | gevaerts: do I need to do anything special to get USB mass storage to work when defining HAVE_HOTSWAP? |
| 15:19:08 | | Join teru [0] (n=teru@KD059133112132.ppp.dion.ne.jp) |
| 15:31:14 | | Join mt [0] (n=MTee@41.206.137.199) |
| 15:33:06 | ReKleSS | is there a description of the rockbox.iriver format somewhere? |
| 15:35:12 | mcuelenaere | ReKleSS: look in tools/scramble.c |
| 15:35:45 | ReKleSS | ok |
| 15:35:57 | mcuelenaere | mt: did you read my comment regarding closing FS #10182 ? |
| 15:36:15 | | Quit CaptainKewl (Remote closed the connection) |
| 15:36:21 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 15:36:27 | kugel | teru: hey. welcome \0/ |
| 15:36:49 | mcuelenaere | ReKleSS: the iriver format seems to be in tools/iriver.c |
| 15:37:51 | mt | mcuelenaere: No, where ? |
| 15:37:59 | kugel | mcuelenaere: I think that's only about patching the OF file |
| 15:38:21 | mcuelenaere | mt: in the logs somewhere :) I was wondering whether the flyspray entry shouldn't get closed now that you've committed it? |
| 15:38:51 | kugel | or maybe not |
| 15:38:53 | mcuelenaere | kugel: uh, isn't that how Rockbox generates the rockbox.iriver files? (iriver_encode) |
| 15:39:02 | ReKleSS | iriver.c seems to be for the original firmware, not for the rockbox.iriver |
| 15:39:21 | mcuelenaere | scramble.c calls iriver_encode(), which is in iriver.c |
| 15:39:30 | linuxstb | mcuelenaere: Isn't that the ".hex" format for the original firmware? The Rockbox binaries are created with the "$tool" command set in configure - probably "scramble -add" which just adds a simple 8-byte header. |
| 15:39:45 | ReKleSS | rockbox.iriver is made with scramble -add |
| 15:39:47 | mcuelenaere | ah ok, sorry |
| 15:39:58 | * | mcuelenaere didn't look in tools/configure |
| 15:40:33 | kugel | mcuelenaere: re: your last comment in the task, it depends if the variables are on the stack for the caller |
| 15:40:49 | kugel | but stack is also memory, so it doesn't really matter. |
| 15:40:58 | mcuelenaere | yeah but it's more dynamic |
| 15:41:05 | mcuelenaere | but anyway, that's unrelated to mt's work |
| 15:41:19 | mt | mcuelenaere: Ah just seen it :) - I suppose it could be closed and a new task could be opened for seeking, but I wanted to keep all the code in one task. Or create separate dependent tasks ? |
| 15:41:32 | mcuelenaere | mt: ah ok, forgot about the seeking part :) |
| 15:41:41 | * | mcuelenaere just thought your forgot to close it :) |
| 15:42:33 | linuxstb | mt: You should at least add a comment to say that parts have been committed - I hadn't noticed... |
| 15:43:12 | | Quit timc (Read error: 110 (Connection timed out)) |
| 15:44:50 | | Quit kugel (Remote closed the connection) |
| 15:46:15 | mt | linuxstb: ok sure. I hadn't added a comment because I thought I'd just say that in the next weekly update and on the wiki. |
| 15:47:13 | linuxstb | mt: The task should be self-contained. People won't know to look in other places for info about it. |
| 15:48:00 | mt | Yes. I'll just wait till I'm home to upload the relevant patch and then comment on it. |
| 15:48:37 | | Join timc [0] (n=aoeu@c-68-45-191-214.hsd1.pa.comcast.net) |
| 15:50:27 | linuxstb | What patch? |
| 15:52:21 | mt | linuxstb: The last patch in the task wasn't the one committed, there were some modifications after that .. |
| 15:52:38 | mcuelenaere | mt: hmm seems my target starts crashing whenever I put a .rm file on it |
| 15:52:45 | mcuelenaere | probably metadata parser choking on it |
| 15:53:13 | mt | mcuelenaere: What target do you have ? |
| 15:53:21 | mcuelenaere | mt: Onda VX747 (MIPS) |
| 15:53:46 | mt | hmm .. I'll check it when I get back home. |
| 15:53:48 | linuxstb | mt: That's OK - just post a comment saying "a modified version of the above patch was committed as r21695" |
| 15:54:11 | mt | linuxstb: okay, will do :) |
| 15:56:36 | mcuelenaere | mt: error is in metadata_common.o -> read_uint32be |
| 15:57:05 | mcuelenaere | 18:8e040000 lwa0,0(s0) -> probably an unaligned access |
| 15:57:12 | mt | mcuelenaere: Could I reproduce that in the sim ? |
| 15:57:24 | mt | Oh, I think no :) |
| 15:57:27 | mcuelenaere | don't think so |
| 15:57:36 | Grahack1 | I just read this in the forums: "Editing ID3 tags with more than one line visible would be really cool too." (http://forums.rockbox.org/index.php?topic=3030.msg21460#msg21460) Is there a tag editor in Rockbox already ? |
| 15:58:46 | mcuelenaere | the code tries to acces 0x80151BE2 |
| 15:58:48 | | Quit kachna|lappy (Read error: 110 (Connection timed out)) |
| 16:00 |
| 16:01:32 | | Part sakuramboo |
| 16:03:10 | | Part wincent ("Kopete 0.12.7 : http://kopete.kde.org") |
| 16:07:11 | | Quit linuxstb (Remote closed the connection) |
| 16:09:30 | mt | mcuelenaere: Do you have other targets to test on ? |
| 16:09:35 | ReKleSS | this seems odd... iriver_flash uses the 1st 8 words from the flash image as the reset vector, an address well into the program space |
| 16:09:46 | mcuelenaere | mt: nope |
| 16:09:50 | ReKleSS | the IriverFlashing page says the original reset vector is 0x8, which is in the flash space |
| 16:09:55 | ReKleSS | how does this work? |
| 16:10:03 | mcuelenaere | mt: I inlined read_uint32be() and the unaligned access is in get_rm_metadata |
| 16:10:56 | Slasheri | ReKleSS: the OF runs directly from flash, and so does rockbox ROM image too |
| 16:11:39 | ReKleSS | but at init, isn't the address it points to unconfigured? |
| 16:11:39 | mt | mcuelenaere: I think the problem could be in rm_parse_header (it's in get_rm_metadata) |
| 16:11:45 | mcuelenaere | it's right after the rm_parse_header() call |
| 16:11:48 | | Join wincent [0] (n=wincent@host-091-097-067-213.ewe-ip-backbone.de) |
| 16:12:34 | mcuelenaere | mt: if you understand MIPS assembly: http://pastie.org/538573 |
| 16:12:52 | mcuelenaere | (line 93) |
| 16:13:05 | ReKleSS | the way I read the MCF5249 datasheet the only accessible memory is whatever's connected to CS0, the flash |
| 16:13:46 | mcuelenaere | hum, that looks weird |
| 16:13:52 | Slasheri | ReKleSS: what do you mean with that? on hardware init, the CPU reads the reset vector stored in flash at 0x0 (including the reset vector and stack address). And the iriver firmware has a fixed entry point at 0x8 that's where the default reset vector points to |
| 16:14:50 | ReKleSS | yes, but the reset vector in bootloader.iriver is 0x10003EA0, which isn't in the flash |
| 16:20:12 | | Join mt__ [0] (n=MTee@41.206.137.151) |
| 16:20:58 | kkurbjun | ReKleSS: are you sure that the flash does not loop there? On the gigabeat the flash is normally at 0x0, but you can access it at 0x01000000, 0x02000000 |
| 16:21:04 | mt__ | bbl |
| 16:21:11 | | Quit mt__ (Client Quit) |
| 16:21:12 | ReKleSS | I'm guessing it's something like that, I'm not sure |
| 16:21:27 | ReKleSS | I'm also guessing if I just write it like that it should work, but I'm curious |
| 16:23:09 | | Quit rasher (Read error: 54 (Connection reset by peer)) |
| 16:23:11 | | Join gregzx [0] (n=chatzill@drp22.neoplus.adsl.tpnet.pl) |
| 16:23:14 | Slasheri | ReKleSS: the bootloader reset vector should be in the flash |
| 16:23:26 | Slasheri | or otherwise it would be incorrect |
| 16:24:03 | | Quit mt (Read error: 104 (Connection reset by peer)) |
| 16:24:25 | Slasheri | be sure not to confuse between the stack location and the execution entry point |
| 16:24:39 | Slasheri | stack should be in iram, and execution entry in flash |
| 16:25:16 | ReKleSS | ohhhhh, that's it, I'm looking at the stack pointer |
| 16:25:20 | ReKleSS | ok, that works now |
| 16:25:39 | Slasheri | hehe, nice :) |
| 16:26:11 | ReKleSS | btw, last may I was the idiot who used a bootloader.iriver file with mkboot and completely messed up the bootloader... hacked together a bdm rig, should be able to finish reflashing it tomorrow |
| 16:27:04 | Slasheri | ouch, you were the one. but you have build a bdm? that's great! |
| 16:27:20 | gevaerts | good :) We need more people with bdm tools! |
| 16:27:44 | ReKleSS | err, I'd rather be able to close up my H120 and just use it, but if anything needs testing in the next little while I can do it |
| 16:28:00 | | Join rasher [0] (n=rasher@0x5550f5a3.adsl.cybercity.dk) |
| 16:28:08 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
| 16:28:29 | Slasheri | with bdm available, i would of course recommend flashing the current svn bootloader and hacking plenty with it =) |
| 16:28:38 | ReKleSS | does it add anything? |
| 16:29:17 | Slasheri | it might fix some disk access issues with CF storage. But no other changes are known, except that it may not work at all :) |
| 16:29:29 | ReKleSS | heh, ok, I'll try that |
| 16:29:44 | Slasheri | great :) |
| 16:30:05 | CIA-71 | New commit by kkurbjun (r21714): M:Robe 500: fix a bug where the remote LCD was not properly sleeping |
| 16:30:15 | ReKleSS | I have a CF adaptor here too, and a somewhat dodge 32gb CF card |
| 16:31:16 | Slasheri | oh, that's great. If possible, you should really give it a try with CF to see if that works. Then it would be a good point for a new bootloader release |
| 16:31:31 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
| 16:32:14 | mcuelenaere | mt: it crashes at read_uint32be(fd, &rmctx->bit_rate); /*avg bitrate*/ in case FOURCC('P','R','O','P'): |
| 16:34:30 | mcuelenaere | mt: replacing line 422 with RMContext *rmctx = (RMContext*) ((int)id3->id3v2buf &~ 3); seems to work |
| 16:37:16 | mcuelenaere | hmm getting codec failure's though |
| 16:37:24 | linuxstb | mcuelenaere: Doesn't that round the address down? |
| 16:37:35 | mcuelenaere | yes I know, it's not good |
| 16:37:46 | mcuelenaere | but at least it makes the unaligned access go away :) |
| 16:38:01 | linuxstb | ;) |
| 16:38:11 | linuxstb | Just add 3 first should be OK |
| 16:40:22 | wincent | Gentlemen and ladies, PDBox makes sound on-target! |
| 16:40:42 | gevaerts | \☺/ |
| 16:40:44 | | Quit patmulchrone (Read error: 60 (Operation timed out)) |
| 16:40:52 | gevaerts | is it the expected sound? ;) |
| 16:40:59 | wincent | :-D Yes! |
| 16:41:05 | | Join patmulchrone [0] (n=pat@99.13.70.2) |
| 16:41:19 | wincent | Pure and simple sine of 220 Hz. |
| 16:41:31 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
| 16:41:46 | rasher | Good news |
| 16:42:38 | wincent | I'll do a clean (without debugging info) patch later in the evening. |
| 16:47:29 | Grahack1 | mcuelenaere: in file_get_contents() in helloworld.lua, io.open(filename, "r") returns a userdata that is not nil even if the file doesn't exist. (1) this shouldn't according to http://www.lua.org/pil/21.2.html (2) How can we know io.open didn't find the file at the moment ? |
| 16:48:17 | mcuelenaere | 1) will fix 2) look in the source ;) |
| 16:48:58 | mcuelenaere | Grahack1: currently it does if(!rb->file_exists(filename)) flags |= O_CREAT; |
| 16:49:05 | mcuelenaere | so if the file doesn't exist, it makes it |
| 16:51:31 | Grahack1 | even in "read" mode ? |
| 16:51:53 | Torne | GodEater: my ipod goes wrong witn 9702 in basically exactly the same way as horscht's does |
| 16:52:25 | Torne | GodEater: so i'm inclined to believe it's relevant despite the large number of patches i have. i also like to think i'm qualified to judge whether they're relevant :) |
| 16:52:36 | Torne | er, 9708 |
| 16:52:45 | Torne | i was going to do a build with just 9708 but I've not gotten around to it yet |
| 16:52:51 | Torne | it's too much effort to narrow it down :) |
| 16:53:44 | AlexP | It is always good to check however |
| 16:53:45 | mcuelenaere | Grahack1: yes, but fixed now |
| 16:53:51 | Torne | AlexP: yah, i am intending to do so |
| 16:53:56 | AlexP | Things can have unexpected consequences :) |
| 16:54:00 | | Nick AlexP is now known as AlexP_ (n=alex@rockbox/staff/AlexP) |
| 16:54:01 | Torne | i just haven't found the time yet, i've not changed the build on my ipod for a while |
| 16:54:02 | | Nick AlexP_ is now known as AlexP (n=alex@rockbox/staff/AlexP) |
| 16:54:14 | Torne | i am fairly careful about how i do it though |
| 16:54:24 | Torne | i use it for many hours between adding patches :) |
| 16:54:26 | *** | Saving seen data "./dancer.seen" |
| 16:54:37 | Torne | and have playlists saved for testing with many different codecs interleaved etc :) |
| 16:54:43 | CIA-71 | New commit by mcuelenaere (r21715): Lua IOlib: don't create files when they don't exist |
| 16:55:34 | linuxstb | mcuelenaere: What does that mean? |
| 16:56:14 | mcuelenaere | linuxstb: when opening files in Lua, if they didn't exist, they got created |
| 16:56:23 | Torne | if i wrote a proper patch for tools/version.sh that lets it work with bzr-svn repos as well as git-svn, would anyone care? :) |
| 16:56:32 | linuxstb | mcuelenaere: That's not what the commit message said ;) |
| 16:56:49 | mcuelenaere | heh, /me expects people to read the the diff ;) |
| 16:58:17 | linuxstb | The diff doesn't help much either (without more context)... |
| 17:00 |
| 17:00:03 | CIA-71 | New commit by mcuelenaere (r21716): RM metadata parser: fix unaligned access |
| 17:00:54 | linuxstb | Torne: What do you think? ;) |
| 17:01:15 | Torne | ? |
| 17:01:45 | linuxstb | Torne: About whether anyone would care about supporting bzr-svn in tools/version.sh... |
| 17:02:35 | * | linuxstb is probably being too cynical about his fellow rockbox devs |
| 17:02:43 | Torne | heh |
| 17:02:57 | * | Torne just doesn't like git. :) |
| 17:04:06 | | Quit jfc^2 (Read error: 54 (Connection reset by peer)) |
| 17:04:29 | | Join jfc^2 [0] (n=john@dpc691978010.direcpc.com) |
| 17:11:51 | | Join mt [0] (n=MTee@41.233.150.185) |
| 17:13:16 | | Quit patmulchrone (Read error: 110 (Connection timed out)) |
| 17:13:17 | saratoga | mt: about what you mentioned earlier today, would it be possible to have the .rm parser descramble AC3 files in .RM ? |
| 17:14:12 | mt | mcuelenaere: Thanks for the fix. :) |
| 17:14:23 | mcuelenaere | np |
| 17:14:32 | mcuelenaere | mt: I didn't get the codec working though |
| 17:16:03 | | Quit Sajber^ (Read error: 104 (Connection reset by peer)) |
| 17:16:52 | saratoga | is MIPS big endian then? |
| 17:17:09 | mcuelenaere | little endian |
| 17:17:12 | mcuelenaere | at least this one is |
| 17:17:37 | | Join n1s [0] (n=n1s@rockbox/developer/n1s) |
| 17:17:43 | mt | saratoga : Maybe, but AC3 will still have to go through a different path. |
| 17:18:20 | saratoga | mt: how do you want to do handle it? |
| 17:18:44 | | Join patmulchrone [0] (n=pat@99-13-70-2.lightspeed.cicril.sbcglobal.net) |
| 17:19:54 | mt | I'll need to add a flag_rm for ac3context (or whatever its struct is) , that whenever asserted the codec will go through a different code path .. That's one solution. |
| 17:20:34 | mt | mcuelenaere: Let me test on my dap .. |
| 17:21:20 | mcuelenaere | mt: I only tried http://samples.mplayerhq.hu/real/AC-cook/FUN_RM_96.rm , I'll try some others too |
| 17:22:14 | mt | mcuelenaere: It's crashing in cook.codec ? i.e get_rm_metadata finishes properly then the codec fails ? |
| 17:22:30 | mcuelenaere | mt: yes, but it doesn't crash; it gives a codec failure |
| 17:23:43 | | Join Strife89 [0] (n=Michael@adsl-154-19-202.mcn.bellsouth.net) |
| 17:24:45 | mt | RMContext is memcpy'd back from id3v2buf in cook.c ( init_rm() ), so my first guess would be that values aren't loaded correctly into rmctx since memcpy'ing didn't account for the change you did in the parser .. |
| 17:26:25 | mcuelenaere | ah |
| 17:29:02 | mcuelenaere | mt: right, that does make it work :) |
| 17:29:22 | mt | \o/ |
| 17:29:29 | mcuelenaere | shall I commit or will you? |
| 17:29:47 | | Quit flydutch ("/* empty */") |
| 17:30:04 | mt | It would be faster if you committed. :) |
| 17:31:38 | CIA-71 | New commit by mcuelenaere (r21717): Cook codec: make sure the RMContext get aligned correctly, or we won't be able to find it |
| 17:32:40 | linuxstb | saratoga: What do you mean by "having the rm parser descramble AC3 files"? Won't it just work the same as other multi-format containers (vorbis/speex in Ogg, aac/alac in MP4, etc)? |
| 17:33:42 | | Quit lucent (Read error: 110 (Connection timed out)) |
| 17:33:54 | GodEater | Torne: I expect no-one to care in a good way, i.e. so long as your patch extends the functionality without breaking it, no-one will mind if you want to add bzr-svn support. |
| 17:34:03 | | Quit ReKleSS ("Leaving") |
| 17:34:45 | GodEater | Torne: and while I respect your ability to tell if a patch is okay to comment on with other patches involved in your build too - it does set rather a double standard, since we ask most contributors to only test with one patch applied at a time =/ |
| 17:38:34 | saratoga | linuxstb: isn't it a little different though since you can have a both different containers for AC3 and different codecs for RM [for example]? |
| 17:38:34 | | Quit patmulchrone (Read error: 110 (Connection timed out)) |
| 17:38:43 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 17:40:03 | saratoga | i was hoping we could preprocess the file enough during parsing that liba52 doesn't need to be changed |
| 17:40:09 | linuxstb | saratoga: No - we just have "a52.codec" and "a52_in_rm.codec", which both link to liba52. |
| 17:40:09 | linuxstb | Or at least, that's how I imagined it working. Similarly for "mp3_in_rm" |
| 17:40:49 | linuxstb | liba52 shouldn't need changing. |
| 17:41:32 | mt | linuxstb: I thought of something like a52_in_rm.codec but never thought it would be acceptable. :) (This should be easier than what I suggested first) |
| 17:42:12 | linuxstb | mt: As I said, that's how other codecs work. I don't see the fact that we have an "a52_in_nothing" codec as affecting that - disk space is cheap... |
| 17:45:18 | mt | Fine. I'll work on seeking first though. |
| 17:48:51 | Torne | GodEater: yah, I was intending to do so, I was just reporting my findings while I had found them, since I didn't have time at the time to retest with just the one :) |
| 17:50:02 | Torne | i have since not been bothered enough to actually do it, but i did intend to at the time. :) |
| 17:50:51 | | Join BryanJacobs [0] (n=bryanjac@e33.cs.rochester.edu) |
| 17:52:46 | linuxstb | BryanJacobs: Hi. How are things going? |
| 17:54:00 | Torne | grr, kbd_input() changes font and doesn't set it back :( |
| 17:56:05 | linuxstb | BryanJacobs: Would you be able to start posting patches to flyspray, rather than your own site? That way they'll get more exposure and can be commented on properly. I remember pondlife already suggesting this a while ago... |
| 17:57:25 | * | AlexP wasn't aware that there had been patches posted |
| 17:57:26 | | Quit jordan` (Read error: 110 (Connection timed out)) |
| 17:57:50 | | Join jgarvey [0] (n=jgarvey@cpe-098-026-065-013.nc.res.rr.com) |
| 18:00 |
| 18:05:52 | | Join JdGordon| [0] (i=ae913eb6@gateway/web/freenode/x-57377b5ef9200ff3) |
| 18:13:59 | | Quit gregzx ("ChatZilla 0.9.85 [Firefox 3.5/20090624025744]") |
| 18:25:23 | * | linuxstb wonders why a bootloader branch was created... |
| 18:27:44 | | Quit mt (Read error: 104 (Connection reset by peer)) |
| 18:28:08 | | Join captainkwel [0] (i=2669ecc2@gateway/web/freenode/x-d132cc35df23863d) |
| 18:28:43 | Torne | does the git branch of rockbox have some kind of .gitignore file in it? |
| 18:28:59 | Torne | (also why must every bloody vcs have ignores in a different format and location) |
| 18:30:26 | JdGordon| | to keep everyone on their toes |
| 18:31:01 | * | linuxstb is also not following the "portalplayer bootloader versions" thread - just do "make VERSION=xxx"... |
| 18:31:10 | | Quit Grahack1 ("Leaving.") |
| 18:31:38 | | Quit r0b- (Read error: 60 (Operation timed out)) |
| 18:31:44 | | Join r0b- [0] (n=rob@adsl-76-235-168-174.dsl.klmzmi.sbcglobal.net) |
| 18:32:02 | | Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) |
| 18:32:40 | | Quit desowin (Read error: 113 (No route to host)) |
| 18:36:28 | | Quit JdGordon| (Ping timeout: 180 seconds) |
| 18:39:47 | | Join mt [0] (n=mt@41.233.150.185) |
| 18:45:35 | | Join JdGordon| [0] (n=Miranda@nat/microsoft/x-720ad27aae6f5e10) |
| 18:48:43 | | Join Hillshum [0] (n=chatzill@unaffiliated/hillshum) |
| 18:48:58 | | Join courtc_ [0] (n=court@unaffiliated/courtc) |
| 18:49:49 | | Quit courtc (Nick collision from services.) |
| 18:49:51 | Hillshum | Does FS #10210 need anything more? |
| 18:50:01 | | Nick courtc_ is now known as courtc (n=court@unaffiliated/courtc) |
| 18:53:26 | | Join flydutch [0] (n=flydutch@host87-202-dynamic.15-87-r.retail.telecomitalia.it) |
| 18:53:38 | linuxstb | Hillshum: Looks non-controversial to me - I'm surprised no e200 owner has complained before... (I don't own one) |
| 18:54:07 | * | Hillshum hopes they don't complain after it gets committed |
| 18:54:29 | Hillshum | the gigabeat does it already right? |
| 18:54:30 | *** | Saving seen data "./dancer.seen" |
| 18:54:56 | linuxstb | Yes, I just looked at the keymaps now. |
| 18:55:23 | linuxstb | Do we have any other rotated targets? |
| 18:55:48 | Hillshum | Wait, the Fuze doesn't need to be rotated |
| 18:56:23 | linuxstb | Correct... |
| 18:57:07 | * | mcuelenaere wonders why nobody yelled about the yellow.. |
| 18:57:18 | linuxstb | Yellow! |
| 18:58:22 | | Join patmulchrone [0] (n=pat@99-13-70-2.lightspeed.cicril.sbcglobal.net) |
| 18:58:49 | AlexP | I've never played a film on my e200, but that change seems a no-discussion one to me |
| 18:58:53 | AlexP | Should go in :) |
| 18:59:08 | AlexP | FS #10210 that is |
| 18:59:12 | mcuelenaere | anyone with a 64-bit pc willing to test this patch for me? http://pastie.org/538780 |
| 18:59:22 | bertrik | So we just need a committer ... |
| 18:59:27 | ej0rge | I've never tried to watch any video on the e200 |
| 18:59:41 | AlexP | bertrik: Hmmm, I don't see any around :) |
| 19:00 |
| 19:00:20 | ej0rge | philips sa9200 would benefit too, off the top of my head |
| 19:00:30 | ej0rge | dunno that mpegplayer is even working on that yet |
| 19:01:28 | bertrik | ok, I will test and commit FS #10210 |
| 19:01:49 | AlexP | cool |
| 19:02:19 | | Quit amiconn (Remote closed the connection) |
| 19:02:19 | | Quit pixelma (Remote closed the connection) |
| 19:04:01 | | Join pixelma [50] (n=pixelma@rockbox/staff/pixelma) |
| 19:04:03 | | Join amiconn [50] (n=jens@rockbox/developer/amiconn) |
| 19:05:16 | BryanJacobs | linxstb: ok, I'll post this week's work on Flyspray - I just felt that something that wasn't ready for widespread consumption shouldn't have gone there |
| 19:05:51 | BryanJacobs | 'm almost done with multifile buffering |
| 19:09:56 | BryanJacobs | I don't really understand why the buffering was implemented as a ring anyhow... there's a lot of code in here just handling the case for "ok, my stuff crosses over the end of the buffer, what do I do now?" |
| 19:10:40 | | Join Lear [0] (i=chatzill@rockbox/developer/lear) |
| 19:11:45 | bertrik | I should add the patch creator to docs/CREDITS, right? |
| 19:12:05 | mcuelenaere | yes, if it isn't already in there |
| 19:14:33 | | Join Ubuntuxer [0] (n=johannes@dslb-094-221-081-051.pools.arcor-ip.net) |
| 19:15:45 | CIA-71 | New commit by bertrik (r21718): Accept FS #10210: "Mpegplayer playback controls on portrait oriented players" by Matthew Bonnett. |
| 19:15:55 | pixelma | how would I find my c250 in the terminal on a Mac (currently in OF USB since it wouldn't connect using Rockbox USB)? |
| 19:16:22 | Hillshum | pixelma: is it in /Volumes ? |
| 19:16:37 | Hillshum | also try disk utility |
| 19:16:41 | pixelma | I'd like to help finding out a bit more but I have no idea about Macs... |
| 19:17:15 | pixelma | Hillshum: sorry, no idea... you have to be very patient with me |
| 19:17:36 | | Quit petur ("work->home") |
| 19:17:49 | BryanJacobs | Torne: I've been using your USB-charging patch and my 5.5G works with everything I've plugged it into |
| 19:18:06 | Hillshum | pixelma: It should be mounted in /Volumes/ |
| 19:18:31 | pixelma | which means for me? |
| 19:19:02 | CIA-71 | New commit by mcuelenaere (r21719): Try at fixing 'cast to/from pointer to/from integer of different size' warnings |
| 19:19:19 | * | pixelma isn't sure this is going anywhere :/ |
| 19:19:25 | Hillshum | pixelma: run "ls -l /Volumes/" in a terminal |
| 19:20:50 | pixelma | yes, I see a SANSA_C250 there, where do I go from here? |
| 19:21:58 | Hillshum | cd /Volumes/SANSA_C50 |
| 19:39:16 | Hillshum | What happened to the Tester badges? |
| 19:39:47 | LambdaCalculus37 | Hillshum: You'll have to bother scorche about that. |
| 19:40:25 | JdGordon| | BryanJacobs: ring buffer is logical for buffering because... umm.. it just is :p |
| 19:40:29 | AlexP | What tester badges? |
| 19:40:39 | JdGordon| | who else would you want to do it? |
| 19:41:11 | BryanJacobs | JdGordon: was that supposed to be "how"? |
| 19:41:15 | Hillshum | AlexP: Wasn't the idea thrown around at devcon? |
| 19:41:18 | | Join Horscht [0] (n=Horscht2@xbmc/user/horscht) |
| 19:41:22 | JdGordon| | BryanJacobs: yes :p |
| 19:41:30 | AlexP | Hillshum: Perhaps, I can't remember |
| 19:41:39 | | Join Blue_Dude [0] (n=chatzill@64.25.25.6) |
| 19:41:41 | AlexP | Hillshum: I have no idea how you would set down criteria for that |
| 19:41:44 | BryanJacobs | the way I'm implementing it is as a set of allocated spaces which may be contiguous but sometimes aren't |
| 19:42:03 | JdGordon| | sized how? |
| 19:42:21 | BryanJacobs | starting with constant size and chained together |
| 19:42:40 | CIA-71 | New commit by Ubuntuxer (r21720): new game plugin for colored players named clix (by Rene Peinthor) |
| 19:42:40 | BryanJacobs | as in, you can have a 128k allocation be four 32k chunks |
| 19:43:14 | BryanJacobs | if space is available and things aren't freed immediately we can expand a chunk |
| 19:44:09 | bertrik | Ubuntuxer, is this patch the one from FS #8925? |
| 19:44:14 | BryanJacobs | this lets multiple files play nicely together :-) |
| 19:44:17 | linuxstb | BryanJacobs: Isn't that going to just result in fragmentation, ending up with every request for 32KB of data by a codec needing the buffering code to do some copying? (remember the 32KB can be anywhere within the file) |
| 19:44:19 | Ubuntuxer | yes |
| 19:44:31 | BryanJacobs | linuxstb: fragmentation, yes, copying, no |
| 19:44:54 | linuxstb | BryanJacobs: So what happens if the file is fragmented, and the codec wants 32KB of data, split across fragments? |
| 19:45:28 | BryanJacobs | linuxstb: ok, in that case you either need copying or duplication |
| 19:45:35 | bertrik | Ubuntuxer, please put the FS# in the commit message next time |
| 19:45:42 | BryanJacobs | but the current codecs don't seem to do that much... |
| 19:45:51 | linuxstb | BryanJacobs: They do... |
| 19:45:52 | BryanJacobs | if you only use advance_buffer that doesn't happen at all in fact |
| 19:45:54 | Ubuntuxer | I forgot it, sorry |
| 19:46:00 | BryanJacobs | I'm not considering seeking yet |
| 19:46:05 | LambdaCalculus37 | Ubuntuxer: New game? :) |
| 19:46:12 | linuxstb | BryanJacobs: Nor am I.... |
| 19:46:29 | Ubuntuxer | yes, but just for colored players |
| 19:46:34 | * | BryanJacobs has been using the wavpack codec as a reference |
| 19:46:43 | BryanJacobs | it only makes use of two or three buffering calls |
| 19:46:52 | BryanJacobs | and only reads forward in the file unless you seek |
| 19:47:06 | linuxstb | BryanJacobs: That's probably a bad example, as it's not using the buffering API as efficiently as other codecs... |
| 19:47:12 | BryanJacobs | hm. |
| 19:47:12 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 19:47:13 | linuxstb | IIRC, it's using read() ? |
| 19:47:41 | BryanJacobs | it was using read in the PC version; in Rockbox it uses codec_advance_buffer |
| 19:47:54 | linuxstb | OK, let me have a quick look at it... |
| 19:48:36 | BryanJacobs | besides, we should only really have to copy occasionally |
| 19:48:41 | linuxstb | BryanJacobs: It seems to be using read_filebuf() |
| 19:48:52 | BryanJacobs | into its own local buffers |
| 19:48:53 | BryanJacobs | one sec... |
| 19:48:54 | | Quit Hillshum ("ChatZilla 0.9.83 [Firefox 3.0.3/2008092417]") |
| 19:49:03 | * | BryanJacobs goes to fetch original source code |
| 19:50:08 | BryanJacobs | actually, look at it like this |
| 19:50:14 | BryanJacobs | if there's only one file in the buffer |
| 19:50:23 | | Join Grahack [0] (n=chri@stc92-1-82-227-106-100.fbx.proxad.net) |
| 19:50:24 | BryanJacobs | then there'll always be space after the current handle to expand it |
| 19:50:27 | BryanJacobs | right? |
| 19:50:49 | linuxstb | Not if that file was loaded whilst there was other data in the buffer. |
| 19:50:54 | | Join Hillshum [0] (n=chatzill@unaffiliated/hillshum) |
| 19:51:07 | BryanJacobs | its handle will be added after that other data |
| 19:51:10 | linuxstb | Sorry, ignore that, I don't think I understood your question... |
| 19:51:22 | BryanJacobs | so, the buffer will look like: |
| 19:51:25 | linuxstb | I'm talking about things getting fragmented... |
| 19:51:29 | BryanJacobs | OTHERDATA -> mydata |
| 19:51:36 | | Join Zagor [242] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) |
| 19:51:48 | Blue_Dude | All right. I'm losing my mind here. I can't get a E200 sim to compile. I've tried a fresh checkout. I've tried reinstalling cygwin. It breaks on apps/codecs/libcook/bitstream.h every time. |
| 19:51:55 | BryanJacobs | now, in the case we're only buffering one file, it will go to -> mydata -> OTHERDATA -> mydata and then to just mydata |
| 19:52:07 | linuxstb | Blue_Dude: That's very possible - it's a new commit... |
| 19:52:23 | BryanJacobs | so, there won't be any fragmentation in the single-file case |
| 19:52:39 | BryanJacobs | in the multi-file case it can arise, yes |
| 19:52:42 | Blue_Dude | But it's a few days old. Why isn't it breaking in the daily build? |
| 19:52:45 | | Join tessarakt [0] (n=jens@e180079183.adsl.alicedsl.de) |
| 19:52:52 | linuxstb | Blue_Dude: Because the daily builds don't use cygwin... |
| 19:52:55 | mcuelenaere | Blue_Dude: those aren't build with cygwin |
| 19:53:09 | Blue_Dude | Um. Hm. now what? Revert? |
| 19:53:19 | Ubuntuxer | Ups, I forgot the keymap for the h300 in clix, I'll fix this... |
| 19:53:22 | linuxstb | BryanJacobs: But the multi-file case is the most common - Rockbox almost always has more than one file buffered. |
| 19:53:38 | BryanJacobs | no, I don't mean two files buffered serially |
| 19:53:51 | BryanJacobs | in the original buffering code it "finishes" the old file before starting the new one |
| 19:53:58 | BryanJacobs | here, let me get you a source line |
| 19:54:02 | mcuelenaere | Blue_Dude: how exactly does it breaks? |
| 19:54:07 | Hillshum | Blue_Dude: try the next to latest commit (svn update rockbox -r <number>) |
| 19:54:08 | Blue_Dude | linuxstb: I'm gonna post a bug report in FS. Then I guess roll it back. |
| 19:54:33 | | Quit Hillshum (Client Quit) |
| 19:54:36 | Blue_Dude | Hillshum: it's been breaking since yesterday. It's not just the latest. |
| 19:55:49 | pixelma | ok, updated to r21718 to make sure it's not an old bug that's already fixed but using RockboxUSB on that Mac here doesn't automatically show me the volume - in OF USB it does. The USB screen itself is shown but nothing happens, sometimes Rockbox even hangs on that screen if I pull the cable again |
| 19:55:51 | bertrik | Blue_Dude, I'll try to build an e200 sim and see what happens |
| 19:56:01 | Blue_Dude | mcuelenaere: It says, and I quote: [....]/apps/codecs/libcook.a(bitstream.o): in function 'put_bits': |
| 19:56:07 | pixelma | any idea what I could try and check? |
| 19:56:25 | linuxstb | BryanJacobs: So you're saying that your patch doesn't modify the existing buffering behaviour (for "normal" codecs)? |
| 19:56:29 | mcuelenaere | Blue_Dude: only that line? |
| 19:56:42 | BryanJacobs | linuxstb: buffering.c line 236 |
| 19:56:43 | pixelma | as I said though - I don't know a lot about Macs... |
| 19:57:05 | Blue_Dude | mcuelenaere: [....]/apps/codecs/libcook/bitstream.h:196: undefined reference to '___assert' |
| 19:57:15 | BryanJacobs | linuxstb: no, it does modify the behavior, I was just trying to say that no more copying should occur with my patch in the "normal" case than did before |
| 19:57:34 | Blue_Dude | Yes there are *three* underscores, not two like you'd think. |
| 19:57:53 | linuxstb | BryanJacobs: So it's still treated as a single ringbuffer for normal files? |
| 19:57:56 | mcuelenaere | Blue_Dude: try #ifndef CYGWIN |
| 19:58:05 | Blue_Dude | In that file? |
| 19:58:12 | mcuelenaere | eh, __CYGWIN__ |
| 19:58:13 | BryanJacobs | linuxstb: yes, the only difference is that it won't ACTUALLY allow overwriting other people's data |
| 19:58:18 | mcuelenaere | no, around the assert() calls |
| 19:58:19 | | Join saratogalab [0] (n=9803c264@gateway/web/cgi-irc/labb.contactor.se/x-7d1a5c883081427c) |
| 19:58:36 | linuxstb | BryanJacobs: What do you mean? |
| 19:58:38 | BryanJacobs | see buffering.c line 619 |
| 19:58:43 | BryanJacobs | where the allocation is cut short |
| 19:58:44 | saratogalab | you could just comment out the assert calls |
| 19:58:56 | BryanJacobs | in my code it would cause fragmentation instead |
| 19:58:57 | mcuelenaere | Blue_Dude: or better, do #ifdef __CYGWIN__ #define assert #endif |
| 19:58:58 | saratogalab | they shouldn't do anything |
| 19:59:10 | linuxstb | BryanJacobs: Hmm, that's an odd comment... " /* This would read into the next handle, this is broken */" |
| 19:59:19 | | Join shotofadds [0] (n=rob@rockbox/developer/shotofadds) |
| 19:59:21 | BryanJacobs | it's a correct comment... |
| 19:59:24 | Blue_Dude | mcuelenaere: I have an idea. The current include in that file is #include <assert.h>. Would #include "assert.h" work better? |
| 19:59:44 | BryanJacobs | this means someone has requested more data than can be immediately buffered contiguously into the current handle |
| 19:59:45 | mcuelenaere | I don't know, does Rockbox has its own assert.h file? |
| 19:59:56 | mcuelenaere | havE* |
| 20:00 |
| 20:00:00 | Blue_Dude | mcuelenaere: There one in firmware/include |
| 20:00:00 | BryanJacobs | so it doesn't buffer as much as they asked for |
| 20:00:02 | Torne | BryanJacobs: it's not *my* charging patch, but i am nonetheless glad that it works for you :) |
| 20:00:22 | * | shotofadds is listening to music from an SD card on his D2... :o) |
| 20:00:38 | gevaerts | Yay! |
| 20:00:38 | pixelma | :) |
| 20:00:38 | BryanJacobs | in my code, it instead tries to find space between some of the handles in the list |
| 20:00:40 | AlexP | congrats :) |
| 20:00:51 | linuxstb | BryanJacobs: Hmm, well that shouldn't happen in practice. Or does it? |
| 20:00:52 | shotofadds | gevaerts: and I'm not even using the OF... |
| 20:01:09 | BryanJacobs | linuxstb: no, that code on line 619 shouldn't happen in practice, that would be bad |
| 20:01:21 | gevaerts | shotofadds: I know. You wouldn't do something horrible like talking about using the OF in #rockbox :) |
| 20:01:29 | BryanJacobs | "Try to recover by truncating this file" x_x |
| 20:01:48 | shotofadds | gevaerts: what's the status of your storage rework? |
| 20:01:51 | BryanJacobs | if that line ever happens you won't ever get the rest of the file into the buffer without reopening it |
| 20:02:15 | pixelma | Rockbox USB, MacOS anyone? If not... I'd also rather leave now (it's a working place)... |
| 20:02:16 | * | shotofadds compiles a build with tagcache and pictureflow, just to have a look.... |
| 20:02:23 | * | mcuelenaere is interested in gevaerts' storage rework too |
| 20:02:30 | Blue_Dude | mcuelenaere: Aha. The cygwin assert.h has a condition that _cplusplus be defined before it'll work. The firmware/include doesn't have that. |
| 20:02:39 | linuxstb | BryanJacobs: That looks like a corner case that shouldn't need handling - i.e. the request should return a "TOO LARGE REQUEST" error message, and nothing should be buffered as a result of it. |
| 20:03:04 | BryanJacobs | linuxstb: but it'll happen occasionally and expectedly in the new code... |
| 20:03:15 | mcuelenaere | Blue_Dude: so changing it to "assert.h" works? |
| 20:03:24 | BryanJacobs | example buffer layout: FILE1 FILE1 FILE1 FILE2 EMPTY EMPTY EMPTY |
| 20:03:26 | Blue_Dude | mcuelenaere: Dunno yet. I'm trying it now. |
| 20:03:31 | bertrik | shotofadds, that's a new feature for the D2? |
| 20:03:38 | BryanJacobs | that'll cause it to happen if the user requests more FILE1 to be buffered |
| 20:03:54 | saratogalab | that same file is included in wma, i'm pretty sure we just commented out the asserts |
| 20:04:03 | shotofadds | bertrik: yeah, since we had a read-only filesystem until now... |
| 20:04:12 | BryanJacobs | what I want the result to look like: FILE1 FILE1 FILE1 FILE2 FILE1 EMPTY EMPTY |
| 20:04:40 | pixelma | so the D2 port is getting closer to be usable? |
| 20:04:47 | linuxstb | BryanJacobs: So have you rejected the idea of having a wavpack-specific file loader that interleaves the data at buffering time? |
| 20:04:50 | Blue_Dude | mcuelenaere: Rock and roll. There it goes. |
| 20:04:57 | Blue_Dude | mcuelenaere: Works. |
| 20:05:11 | BryanJacobs | linuxstb: I can still do that. Would you prefer that I abandon this and do that instead? |
| 20:05:16 | mcuelenaere | ok, I'll commit that then |
| 20:05:23 | BryanJacobs | it's just so... domain-specific |
| 20:05:47 | BryanJacobs | actually, I might even be able to finish an interleaved loader this week |
| 20:05:47 | * | JdGordon| doesnt care what happens as long as buffering/playback gets simpler instead of more complicated :p |
| 20:05:56 | Blue_Dude | mcuelenaere: It's the #include in the libcook/bitstream.h file. |
| 20:05:58 | BryanJacobs | JdGordon: but it will get simpler! |
| 20:06:05 | shotofadds | pixelma: there are still usability issues with the touchscreen in certain situations, but it's getting there now |
| 20:06:06 | CIA-71 | New commit by zagor (r21721): Mother now runs svn instead of the children, to avoid killing it. Svn update is only ran wheen needed. Remove build tree centrally. |
| 20:06:07 | mcuelenaere | Blue_Dude: I know |
| 20:06:22 | Blue_Dude | mcuelenaere: OK, just so we're on the same page. :) |
| 20:06:27 | BryanJacobs | linuxstb: the interleaved loader is much easier to do |
| 20:06:34 | pixelma | shotofadds: congrats! :) |
| 20:06:35 | linuxstb | BryanJacobs: For once I agree with JdGordon| - a simpler buffering system would be nice... |
| 20:06:41 | CIA-71 | New commit by mcuelenaere (r21722): Fix compiling on Cygwin hosts. |
| 20:06:56 | * | BryanJacobs thought the current buffering system was complicated, it took him nearly a week to learn it properly |
| 20:07:12 | shotofadds | pixelma: One big caveat though, the only way users will be save settings etc is if the SD drive becomes the primary drive - ie. you need a card inserted to boot Rockbox :/ |
| 20:07:21 | shotofadds | *be able to |
| 20:07:36 | JdGordon| | I'm sure the idea of a more statically allocated buffering thingy was brought up before... isnt it harder to keep track of the blocks than a ring? |
| 20:07:42 | Blue_Dude | mcuelenaere: Hang on. Hung up again later. I'm restarting a clean build to fix dependencies. |
| 20:08:05 | BryanJacobs | JdGordon: for simplicity I currently use a sorted linked list |
| 20:08:10 | BryanJacobs | and insert-in-order to keep it going |
| 20:08:15 | Blue_Dude | mcuelenaere: It went past the previous section and stopped later. Same error. |
| 20:08:30 | mcuelenaere | Blue_Dude: you sure? did make clean? |
| 20:08:30 | linuxstb | BryanJacobs: If it's easy to do the interleaved loader, it might be worthwhile doing it as an experiment, so you have something to compare with your current approach. |
| 20:08:43 | Blue_Dude | mcuelenaere: Making clean now. |
| 20:08:46 | BryanJacobs | linuxstb: OK, I'll start on that right away then, it's much easier to finish |
| 20:08:53 | mcuelenaere | Ubuntuxer: yellow! |
| 20:09:10 | * | mcuelenaere thinks we need a yellow-shouting bot |
| 20:09:18 | BryanJacobs | the only issue is getting the right code into the buffering thread |
| 20:09:27 | linuxstb | BryanJacobs: But I also don't want to discourage you from improving the more general Rockbox buffering code... ;) |
| 20:09:29 | Ubuntuxer | I'm in. |
| 20:09:29 | amiconn | shotofadds: You could make rockbox save settings etc on the sd card even if rockbox itself is installed on the internal flash. But of course it would be much better to have write access to the internal storage |
| 20:09:58 | shotofadds | amiconn: how would you see that working? |
| 20:10:17 | JdGordon| | change the .rockbox folder path... |
| 20:10:17 | CIA-71 | New commit by Ubuntuxer (r21723): add keymap for m300 and fix warnings of previous patch |
| 20:10:17 | Blue_Dude | mcuelenaere: Is NDEBUG defined for sim builds anywhere? |
| 20:10:22 | amiconn | Just use different default paths for this... |
| 20:10:32 | mcuelenaere | Blue_Dude: I don't know what NDEBUG does.. |
| 20:10:58 | Blue_Dude | mcuelenaere: Me either. But it voids the assert declaration if it's defined. |
| 20:11:01 | linuxstb | BryanJacobs: I was thinking that you could do something like add a function pointer in the id3 struct which would by default be the current buffering code. The wavpack metadata parser would change this to the wavpack-hybrid loader if it found a correction file. |
| 20:11:23 | linuxstb | BryanJacobs: But I've no knowledge of the internals of the buffering code - just how it works from a codec's point of view. |
| 20:11:29 | * | mcuelenaere thinks we should go with saratoga's advice and comment the asserts() out |
| 20:11:47 | BryanJacobs | linuxstb: the issue is that the previous/next files could be buffering too... |
| 20:11:53 | Blue_Dude | mcuelenaere: Right there with you. Let's see if the clean build works forst. |
| 20:11:55 | Blue_Dude | first |
| 20:12:12 | linuxstb | BryanJacobs: How? I thought there was just a single buffering thread, buffering files sequentially. |
| 20:12:23 | linuxstb | mcuelenaere: Or just delete them? |
| 20:12:34 | BryanJacobs | it allocates the SPACE sequentially |
| 20:12:40 | mcuelenaere | linuxstb: perhaps they're usefull for debugging purposes? |
| 20:12:42 | JdGordon| | BryanJacobs: one thing you may have overlooked... I tihnk its only the actual file that can be broken up in the buffer.. other stuff like its AA or metadata needs to be sequential |
| 20:13:05 | BryanJacobs | JdGordon: easy to do by making a handle whose size is the whole needed size |
| 20:13:22 | BryanJacobs | I've only been fragmenting audio data so far |
| 20:13:37 | BryanJacobs | linuxstb: there are two threads working |
| 20:13:47 | BryanJacobs | there's the actual buffering thread, which loads the data |
| 20:14:02 | BryanJacobs | and then the other one which does things like allocating handles and requesting buffering stuff |
| 20:14:34 | BryanJacobs | the issue is when the wavpack-specific code would be invoked - it would have to be from the buffering thread |
| 20:14:45 | linuxstb | Yes, so why is that a problem? |
| 20:14:46 | BryanJacobs | and ONLY when inside a wavpack-type handle |
| 20:15:06 | BryanJacobs | so, that means buffering needs to know about the file type, which means that it can't just be a modification to struct mp3info |
| 20:15:20 | linuxstb | Is a handle a struct? |
| 20:15:33 | BryanJacobs | yes, that's where I'd put the callback |
| 20:15:42 | BryanJacobs | struct memory_handle |
| 20:15:51 | | Join jordan` [0] (i=gromit@78.235.252.137) |
| 20:17:09 | Blue_Dude | mcuelenaere: frak. Broke again. |
| 20:17:21 | * | amiconn doesn't really understand how multi-file buffering could work at all |
| 20:17:23 | mcuelenaere | Blue_Dude: huh, with the asserts commented out? |
| 20:17:44 | Blue_Dude | mcuelenaere: No. Clean build with "assert.h" |
| 20:17:50 | BryanJacobs | amiconn: take a look at my preliminary patch... |
| 20:18:26 | amiconn | Afaiu the buffering thread would need to know the relation between the two files. Both might be larger than the total available ram |
| 20:18:27 | JdGordon| | BryanJacobs: are you thinking of a max and min size blocks? or when a handle is requested if its smaller than the space free, that space just gets split into two new blocks? |
| 20:18:50 | BryanJacobs | JdGordon: I was thinking of a max size, no real min |
| 20:19:02 | BryanJacobs | so that when someone asks for 128k they get 4x32k |
| 20:19:37 | BryanJacobs | I wasn't worried about little bitty bits going to waste if people ask for 31k at a time |
| 20:20:01 | JdGordon| | and if someone keeps requesting 4k? |
| 20:20:06 | JdGordon| | or less |
| 20:20:13 | BryanJacobs | then they'll get a chain of 4k -> 4k -> 4k |
| 20:20:26 | BryanJacobs | or actually |
| 20:20:36 | BryanJacobs | if there's room it can be their first handle gets grown |
| 20:20:54 | BryanJacobs | so they get a 4k handle, then it becomes 8k, then 16k, and so on |
| 20:20:59 | BryanJacobs | err 12 |
| 20:21:01 | BryanJacobs | I can add really |
| 20:21:23 | JdGordon| | see, it doesnt sound any less complicated, and sounds more prone to fragmentation and wasted ram? |
| 20:21:28 | * | BryanJacobs thinks perhaps he should make a diagram |
| 20:21:35 | JdGordon| | probably :) |
| 20:21:45 | BryanJacobs | no, there's no fragmentation at all in the current use cases |
| 20:22:10 | BryanJacobs | the ONLY time there'd be fragmentation is if you interleave buffering calls AND you don't free things promptly |
| 20:22:30 | JdGordon| | there almost has to be after a while of buffering and freeing... |
| 20:22:34 | JdGordon| | bbs |
| 20:22:37 | linuxstb | BryanJacobs: With the typical (I think) example of a 4MB .wv, 30MB correction file and 28MB audio buffer, how would the buffering work? |
| 20:22:47 | BryanJacobs | linuxstb: interleaved or multifile? |
| 20:23:09 | BryanJacobs | I mean, which buffering system are we talking about here? |
| 20:23:17 | linuxstb | BryanJacobs: With your patch - which is that? |
| 20:23:27 | BryanJacobs | multifile |
| 20:24:05 | Blue_Dude | mcuelenaere: Assert is just a DEBUGF type message, I guess? Well, it compiled with out them. Total of 5 lines commented out. |
| 20:24:06 | BryanJacobs | with my patch, the 4MB .wv is buffered sequentially and the 30MB correction file makes space around it |
| 20:24:20 | linuxstb | So what if the .wv is larger than the buffer? |
| 20:24:30 | BryanJacobs | only one chunk of the .wv is used at a time |
| 20:24:39 | BryanJacobs | unless a CHUNK is larger than the buffer we're OK |
| 20:24:59 | BryanJacobs | and only 4k of the chunk is used in one go in the optimized code |
| 20:25:12 | amiconn | What about a 20MB .wv and a 160MB correction file on a 16MB target (12MB audio buffer)? |
| 20:25:27 | * | linuxstb thinks we need pictures, with colours indicating different things in the buffer... |
| 20:25:50 | * | BryanJacobs agrees with linuxstb - the picture is clear in BryanJacobs' head but difficult to explain without a whiteboard |
| 20:25:56 | mcuelenaere | Blue_Dude: so with http://pastie.org/538923 it compiled correctly? |
| 20:26:10 | * | Torne also thinks you need to specifically cover the case where the current playing file is an mp3 and thus the wavpack codec is not running yet, i.e. the buffering code is just getting it buffered up in advance :) |
| 20:26:21 | wincent | Anyone knowledgeable about cpu_boost() here? |
| 20:26:32 | BryanJacobs | how about I do the codec-specific buffering quickly this week and then start illustrating what my buffering modification would do so people can understand it |
| 20:26:52 | linuxstb | BryanJacobs: I guess my main questions are simply whether your proposal a) changes anything for existing codecs; b) cleanly deals with files larger than the audio buffer. |
| 20:26:58 | Blue_Dude | mcuelenaere: Yeah. Except I commented out the #include also. |
| 20:27:11 | BryanJacobs | linuxstb: the answers are yes and yes, but for a) they won't notice :-) |
| 20:27:17 | mcuelenaere | yeah, I hesitated about that; seems like bad code style to me :) |
| 20:27:30 | BryanJacobs | the API is still compatible and there should be no major performance losses for existing codecs |
| 20:28:02 | CIA-71 | New commit by mcuelenaere (r21724): Previous commit didn't fix compiling on Cygwin, this one should. |
| 20:28:03 | amiconn | linuxstb: And also, how does it handle seeking? |
| 20:28:06 | linuxstb | BryanJacobs: So a codec that reads a variable amount of data at a time (between 0 and 32KB) won't be adversely affected? |
| 20:28:24 | BryanJacobs | linuxstb: as long as it's the only file actively being buffered, no |
| 20:28:41 | linuxstb | What do you mean by "actively being buffered"? |
| 20:28:44 | Torne | but the usual case is that the playing file is *not* being actively buffered |
| 20:28:54 | Torne | normally the file being played has been entirely buffered, on large mem targets |
| 20:28:58 | | Quit DarkDefender (Remote closed the connection) |
| 20:29:13 | BryanJacobs | I mean that when you call bufopen(), you're not going to call it again until you change files |
| 20:29:14 | Torne | and if it's been buffered into non-contiguous bits of ram, what happenes if the codec then reads in variable size chunks |
| 20:29:19 | domonoky | there are so many different cases, we need pictures :-) |
| 20:29:20 | mcuelenaere | wincent: what do you want to know? |
| 20:29:26 | BryanJacobs | Torne: that doesn't happen! |
| 20:29:40 | linuxstb | BryanJacobs: Is "bufopen()" the function called when a codec starts decoding a file? |
| 20:29:47 | Torne | BryanJacobs: er, i'm pretty sure it does... |
| 20:29:47 | BryanJacobs | linuxstb: yes |
| 20:30:01 | BryanJacobs | Torne: not in the case where you have one file playing, then you open a second one |
| 20:30:18 | BryanJacobs | and then you move on to a third after finishing with the first one |
| 20:30:26 | BryanJacobs | they move together so there's never any interleaving |
| 20:30:27 | Torne | BryanJacobs: i'm talking about the case where i have a playlist full of mostly mp3 or whatever, with one of your hybrid things in the middle somewhere |
| 20:30:40 | gevaerts | shotofadds: multidriver will be a lot easier once I have a real target to test it :) |
| 20:30:41 | wincent | mcuelenaere: How fast is the switching of frequency? |
| 20:30:43 | Torne | and what the resulting change in behaviour is for the mp3 codec |
| 20:30:49 | linuxstb | gevaerts: Elio! |
| 20:30:57 | mcuelenaere | wincent: depends on the target, if it changes PLL or just a divider.. |
| 20:31:00 | Torne | wincent: varies on different platforms |
| 20:31:05 | BryanJacobs | Torne: oh, yeah, you'll get fragmentation there, but the mp3s will still WORK, there'll just be an occasional memcpy |
| 20:31:11 | gevaerts | linuxstb: that's your drawer, not mine! |
| 20:31:19 | linuxstb | gevaerts: That can be fixed ;) |
| 20:31:24 | mcuelenaere | wincent: how fast do you want it to be? |
| 20:31:25 | Torne | BryanJacobs: yes. that's the poitn i'm getting at: how occasional do you think occasional is? :) |
| 20:31:37 | domonoky | wincent: so you shoudnt boost/unboost too often.. |
| 20:31:38 | gevaerts | linuxstb: I still think that pondlife is a better victim :) |
| 20:31:48 | BryanJacobs | Torne: it's a function of the amount of RAM available and how much data the codec needs at once |
| 20:31:59 | BryanJacobs | if the codec prompty frees everything it uses, that should NEVER happen |
| 20:32:19 | Torne | hm? how does the codec freeing anything have anything to do with it? |
| 20:32:20 | BryanJacobs | if the codec hangs on to old portions of the file, it will eventually happen unless the buffer is very large relative to the file |
| 20:32:29 | | Join Blue_Dude_ [0] (n=chatzill@64.25.25.6) |
| 20:32:33 | Torne | i'm talking about the case where teh mp3 has been completely buffered into ram before playback of it even starts |
| 20:32:46 | Torne | but it was buffered into several noncontiguous reginos, because of the previous effect of your codec |
| 20:32:58 | BryanJacobs | if the codec frees old space, the hybrid stuff will go in there instead of in "front" of the mp3 |
| 20:33:25 | BryanJacobs | if the hybrid codec frees its space efficiently, the mp3 won't need to be buffered noncontiguously in the first place |
| 20:33:27 | wincent | In PDBox I make the calculations in the main loop, so I thought it could need some additional processing power. |
| 20:33:40 | linuxstb | BryanJacobs: How does the buffering code know how to share the RAM between files 1 and 2 (i.e. .wv and .wvc? |
| 20:34:02 | mcuelenaere | wincent: what target do you have? |
| 20:34:12 | Torne | BryanJacobs: so your assumption is that the malloc/free behaviour of the multifile-using codec is going to usually be nice and sequential and thus ram will be unlikely to get fragmented in the first place, yes? |
| 20:34:24 | wincent | mcuelenaere: iriver H320 |
| 20:34:36 | BryanJacobs | linuxstb: in the case of a codec-specific interleaving loader it can just load a certain both block headers and then the ratio can be arbitrary |
| 20:34:48 | BryanJacobs | Torne: yes |
| 20:34:49 | wincent | But now, as PDBox works with the most simple test, we will see whether CPU boost is needed. |
| 20:35:02 | linuxstb | BryanJacobs: Sorry, I'm still talking about your "generic" multifile buffering. |
| 20:35:28 | Torne | BryanJacobs: then why not use the scheme i proposed before and just revert to the normal buffering behaviour after the multifile track finishes buffering? |
| 20:35:47 | Torne | just assume that the last place in the buffer with data from taht file in is the beginning of a normal circular buffer again? :) |
| 20:35:48 | BryanJacobs | linuxstb: in the case of multifile buffering, it doesn't "know" - it just buffers a certain readahead of both and then requests more be buffered as the codec consumes it |
| 20:35:58 | mcuelenaere | wincent: I would say, test it on-target and see whether cpu_boost()'ing really speeds up things (which they will I suspect) |
| 20:36:08 | BryanJacobs | Torne: but it's the same thing! |
| 20:36:21 | amiconn | linuxstb: What I don't understand wrt multifile buffering is how buffering handles this ratio. The ratio will most certainly vary across the file, so buffering needs to know what timestamp a certain file position belongs to |
| 20:36:33 | Torne | BryanJacobs: not if you're saying it changes behaviour for existing codecs it's not |
| 20:36:40 | wincent | mcuelenaere: That is what I intend to do. |
| 20:36:52 | BryanJacobs | Torne: when the multifile bits are no longer resident the behavior of the existing codecs will be identical to before |
| 20:37:19 | BryanJacobs | when the multifile bits ARE resident, it'll be different only in that occasionally they'll have to get memmoved |
| 20:37:27 | Torne | BryanJacobs: identical in effect, or in performance? |
| 20:37:31 | amiconn | Otherwise it may happen (for very large files and/or very small buffers) that the file positions drift further apart than the available ram size |
| 20:37:32 | linuxstb | amiconn: Yes, that's why I've always thought the loader would need to be very codec-specific - interleaving bits of the two files that are decoded together. |
| 20:37:33 | Torne | i.e. is there still overhead involved in having your code there |
| 20:38:11 | BryanJacobs | Torne: there's some overhead but it's only because the struct memory_handle is now marginally larger and the add_handle code a bit slower |
| 20:38:17 | BryanJacobs | there's no SIGNIFICANT overhead |
| 20:39:06 | BryanJacobs | it does the same thing as before but in a different way |
| 20:39:18 | BryanJacobs | different *but equivalent* way |
| 20:39:57 | BryanJacobs | linuxstb: the loader benefits greatly from codec-specific knowledge |
| 20:40:08 | BryanJacobs | but it's not absolutely required |
| 20:40:49 | BryanJacobs | what I'm getting from this discussion is that I need to create a very thorough illustrated guide to how I see this working before proceeding with it |
| 20:41:01 | BryanJacobs | is that around right? |
| 20:41:03 | Torne | yes :) |
| 20:41:07 | domonoky | yes :-) |
| 20:41:09 | BryanJacobs | I'd be more than glad to do that |
| 20:41:12 | Torne | any scheme to make this work is going to be complicated |
| 20:41:24 | BryanJacobs | I wouldn't say that... |
| 20:41:32 | | Join petur [0] (n=peter@rockbox/developer/petur) |
| 20:41:37 | BryanJacobs | the scheme itself can be simple, analyzing its behavior can be hard |
| 20:41:38 | domonoky | buffering is complicated. there are so many use-cases... so pictures surely will help. |
| 20:41:57 | | Quit Ubuntuxer ("Leaving.") |
| 20:42:10 | BryanJacobs | but before I do that I'll go with linuxstb's idea and make a Wavpack-specific buffer...er |
| 20:42:20 | BryanJacobs | that should be quick and dirty |
| 20:42:44 | amiconn | I wonder whether it would be helpful to divide the *whole* buffer into equally sized chunks (e.g. 32KB). Iiuc mpegplayer does this. |
| 20:43:24 | BryanJacobs | amiconn: the only thing that helps with is avoiding very small free areas, right? |
| 20:43:30 | BryanJacobs | oh and simplifying management |
| 20:44:00 | pixelma | it avoids simplifying? ;) |
| 20:44:07 | amiconn | A chunk would never contain data from more than one file. It will waste a bit of RAM (16KB slack on average per file buffered), but it would probably simplify management a lot |
| 20:44:13 | BryanJacobs | pixelma: :-P |
| 20:44:15 | Torne | actually dividing it all the way doesn't have a lto of advantage, but aligning the start and end of allocated regions to some big multiple might help |
| 20:44:44 | BryanJacobs | Torne: I was using a next* in the struct memory_handle so we didn't need alignment |
| 20:44:48 | * | amiconn is thinking about this dynamic plugin ram idea as well, which would need flexible free'ing of buffered audio data |
| 20:44:50 | linuxstb | amiconn: Do you mean that files can be scattered anywhere in the audio buffer, in 32KB chunks? |
| 20:45:04 | amiconn | Yes, basically |
| 20:45:40 | BryanJacobs | mpegplayer doesn't have to worry about the behavior of "other" codecs ;-( |
| 20:45:46 | | Join webguest81 [0] (n=562d61f0@gateway/web/cgi-irc/labb.contactor.se/x-d547ae5dcb95926c) |
| 20:45:51 | Torne | you would want the chunk size to be quite a bit bigger if you were going to do that, much larger than the maximum amount of data codecs can ask for at once |
| 20:46:00 | Torne | to minimise the frequency with which you have to memcpy() |
| 20:46:12 | * | BryanJacobs agrees with Torne |
| 20:46:18 | Torne | (which then means you waste more ram with slack space) |
| 20:46:25 | linuxstb | That breaks (or at least, introduces memcpy's for almost every request) a lot of codecs, which request a pointer to the next 32KB of the input file, and then process N bytes of it, before advancing the file pointer N bytes and then requesting another 32KB |
| 20:46:29 | amiconn | The maximum amount of data a codec is guaranteed to get *is* 32KB (iirc) |
| 20:46:33 | BryanJacobs | you could also just place each new file as far away from the others as possible |
| 20:46:44 | | Nick J-23 is now known as J-23|away (n=zelazko@unix.net.pl) |
| 20:46:47 | Blue_Dude_ | mcuelenaere: We're good. It compiles from a clean make with your update. Thanks! |
| 20:46:51 | | Nick J-23|away is now known as J-23 (n=zelazko@unix.net.pl) |
| 20:46:54 | mcuelenaere | :) |
| 20:47:04 | Torne | amiconn: yes, the problem is when it asks for 31kb then asks for another 31kb |
| 20:47:07 | | Quit Blue_Dude_ ("ChatZilla 0.9.85 [Firefox 3.0.11/2009060215]") |
| 20:47:08 | BryanJacobs | linuxstb: if you don't have a chunk header/footer it's OK... |
| 20:47:11 | Torne | amiconn: when you have it in noncontiguous 32kb blocks |
| 20:47:40 | BryanJacobs | I mean, if you know two consecutive 32k chunks have data from the same file then no memcpy is needed for a codec asking for N bytes at a time until N reaches 32k |
| 20:47:47 | | Part teru ("Leaving...") |
| 20:47:56 | BryanJacobs | I mean until sum(N)=32k |
| 20:47:57 | amiconn | The blocks shouldn't be noncontiguous by default, but optionally |
| 20:48:05 | linuxstb | BryanJacobs: What about Torne's example of requesting two 31KB chunks? |
| 20:48:17 | | Quit Blue_Dude (Read error: 110 (Connection timed out)) |
| 20:48:18 | Torne | amiconn: yes, it will try its best to make them noncontiguous |
| 20:48:26 | Torne | but it won't always be able to succeed :) |
| 20:48:29 | BryanJacobs | linuxstb: that would require three 32k chunks in a row to pass |
| 20:48:53 | Torne | er, to make them contiguous |
| 20:49:13 | * | BryanJacobs thinks people are catching on to what he was proposing |
| 20:49:16 | amiconn | No, and for those cases it would need to memcpy |
| 20:49:36 | BryanJacobs | there's no way to get around having to copy *sometimes* if people require contiguous space |
| 20:49:39 | amiconn | But that shouldn't happen often. It doesn't solve the questions related to multifile buffering |
| 20:49:40 | BryanJacobs | malloc() does that too |
| 20:49:49 | Torne | amiconn: yes, at which point the larger the block size is, the less memcpys there are, even if the fragmentation pattern is identical |
| 20:50:10 | amiconn | Torne: Less memcpy()s perhaps, but not less data to copy |
| 20:50:35 | BryanJacobs | amiconn: no because you know how much of a block is used |
| 20:50:46 | BryanJacobs | at most the same amount of data is copied |
| 20:50:50 | BryanJacobs | *are copied |
| 20:50:58 | BryanJacobs | **number of data are copied |
| 20:51:02 | BryanJacobs | ***sigh |
| 20:51:08 | GodEater | hahaha |
| 20:51:13 | amiconn | The default block is all-data, of course. Only slack blocks (end of file) aren't full |
| 20:51:16 | * | GodEater pats BryanJacobs gently on the shoulder |
| 20:51:29 | amiconn | The larger the blocks, the more memory is wasted |
| 20:51:31 | Torne | (also technically small memcpys are more expensive) |
| 20:52:41 | amiconn | 32KB blocks are already quite large considering out lowmem targets |
| 20:53:15 | BryanJacobs | who says this can't be target-specific? |
| 20:53:27 | Torne | amiconn: sorry, i'm being too socratic. i meant that my conclusion is that keeping blocks fixed like that is probably not optimal |
| 20:53:33 | amiconn | On the swcodec lowmem targets, the audio buffer is <1MB iirc. 1MB would be just 32 32KB blocks |
| 20:53:43 | BryanJacobs | BUFFERING_DEFAULT_FILECHUNK can be defined based on target |
| 20:53:45 | Torne | because you want the blocks to be big really but that wastes more ram :) |
| 20:54:21 | Torne | not having fixed blocks means you can waste very little, *if* you hav ea good enough allocationpolicy for it |
| 20:54:32 | | Join Hillshum [0] (n=chatzill@unaffiliated/hillshum) |
| 20:54:33 | *** | Saving seen data "./dancer.seen" |
| 20:54:56 | BryanJacobs | why don't we just take someone else's malloc implementation and change all codecs to use malloc/realloc? |
| 20:55:16 | BryanJacobs | then it'd be pluggable |
| 20:55:30 | domonoky | wincent: congratulations for first pdbox sound :-) |
| 20:55:30 | amiconn | malloc() is not wanted in rockbox, because it doesn't make sense |
| 20:56:00 | BryanJacobs | amiconn: ? seems to make sense to me... we're talking about allocation policies and fragmentation levels here |
| 20:56:00 | Torne | BryanJacobs: malloc()'s allocation strategy is not optimal for normal codec, is why :) |
| 20:56:18 | amiconn | http://www.rockbox.org/twiki/bin/view/Main/WhyNoMalloc |
| 20:56:20 | Torne | you want an allocatino strategy which under our "normal" use case behaves as close to ring buffering as possible ;) |
| 20:56:34 | Torne | and ideally with overhead as close to ring buffering's as well :) |
| 20:56:45 | BryanJacobs | amiconn: that does not apply |
| 20:56:56 | Torne | normal mallocs tend to consider total heap size to be one of the parameters to minimise |
| 20:57:10 | Torne | we have a fixed 'heap' size and thus that criteria is irrelevant |
| 20:57:15 | BryanJacobs | amiconn: that's why there's no malloc() for things like codec memory, not why the audio buffer is not allocated using a malloc()-like |
| 20:57:55 | BryanJacobs | Torne: why would malloc not behave like ring buffering under our normal use case? |
| 20:58:04 | Zagor | BryanJacobs: because malloc is per definition sub-optimal for a ring buffer |
| 20:58:08 | linuxstb | BryanJacobs: The audio buffer is essentially a FIFO - hence the use of a ring-buffer. That's not malloc... |
| 20:58:16 | amiconn | It also applies here. malloc() is not made for the kind of allocation needed here |
| 20:59:07 | amiconn | In our own allocation scheme, blocks can be moved around if necessary. malloc pointers are fixed unless you're calling realloc() |
| 20:59:37 | BryanJacobs | but you can't move audio blocks anyway in the current scheme |
| 21:00 |
| 21:00:00 | * | amiconn wonders whether some techniques from buflib.[ch] might be useful in the core |
| 21:01:10 | * | BryanJacobs stares in wonder at the header comment of buflib.c - can this be manna from heaven? |
| 21:01:27 | bertrik | shotofadds, do you think you'll ever be able to write the internal NAND? |
| 21:02:19 | bertrik | I'm looking into the meizus which have the 'whimory' flash translation layer and I'm starting to lose hope for it |
| 21:02:29 | shotofadds | bertirk: i could physically write to the NAND now, but that wouldn't be very clever ;-) |
| 21:02:53 | shotofadds | with a bit more reverse engineering, I think it's possible for the TCC FTL |
| 21:03:15 | bertrik | does the TCC FTL also do wear leveling? |
| 21:03:30 | shotofadds | yes, everything's done in software |
| 21:04:05 | shotofadds | I don't currently know what algorithm they are using |
| 21:04:22 | JdGordon| | BryanJacobs: IIRC handles can (and do) move around currently |
| 21:05:08 | amiconn | shotofadds: Do we need to use the same algorithm, or is there some kind of mapping table? |
| 21:05:12 | bertrik | If it didn't do wear leveling but just relied on error correction I could imagine that it's easier to reverse engineer |
| 21:05:40 | shotofadds | we could use a different algorithm, but wouldn't that affect the wear-levelling ability overall? |
| 21:06:03 | BryanJacobs | JdGordon: a handle is only moved when more data are requested, not when something else is growing |
| 21:06:19 | BryanJacobs | as in, we can't grow handle B when handle A enlarges |
| 21:06:40 | saratoga | IMO the biggest problem with malloc for us is that we can't really implement free without leaking away memory to fragmentation since we have no VM in rockbox |
| 21:07:16 | bertrik | shotofadds, amiconn : have you ever seen an open-source FTL? |
| 21:07:20 | shotofadds | amiconn: there is no lookup table, but it scans all physical blocks on startup, so we could potentially arrange them however we choose. |
| 21:07:25 | BryanJacobs | saratoga: if we only used the audio buffer as the "heap" how would that be a problem? |
| 21:07:45 | shotofadds | bertrik: I've never looked at one, if such a thing exists |
| 21:07:46 | saratoga | i'm not sure what you're thinking here, but without free I'm not sure how useful malloc really is |
| 21:08:10 | BryanJacobs | saratoga: I meant that if we only store audio data using a malloc()like interface I don't see how we'd leak memory |
| 21:08:40 | saratoga | you won't provided you only ever allocate blocks of exactly one size and do not care about having memory continuous between blocks |
| 21:08:41 | JdGordon| | as soon as its made avialable to buffering, there will be calls to make it usable elsewhere |
| 21:09:03 | gevaerts | bertrik: there are some wear-leveling filesystems, but I don't know of any translation layer |
| 21:09:46 | bertrik | for some targets we could do a complete firmware replacement (i.e. lose the OF filesystem), but that's quite a big step |
| 21:10:20 | gevaerts | bertrik: that would require mtp or something similar as well |
| 21:10:21 | bertrik | for MSC we need a block device, but for MTP we could use any FS I think |
| 21:10:47 | | Join Hillshum_ [0] (n=chatzill@unaffiliated/hillshum) |
| 21:10:58 | bertrik | that's also a big step, since rockbox is now exclusively FAT AFAIK |
| 21:11:02 | | Quit Hillshum (Read error: 104 (Connection reset by peer)) |
| 21:11:14 | | Nick Hillshum_ is now known as Hillshum (n=chatzill@unaffiliated/hillshum) |
| 21:11:20 | BryanJacobs | JdGordon: so it shouldn't be implemented because people would want it? |
| 21:11:45 | JdGordon| | we *dont* want it though... you were linked the reasons |
| 21:12:28 | BryanJacobs | I read them and, frankly, agree with them. But I think it's kind of funny to say something shouldn't be implemented because there are people who would want to (ab)use it |
| 21:13:10 | Torne | there are FTLs in linux |
| 21:13:16 | GodEater | I think mostly these days we don't want it because it would be a massive about face, and we'd have to delete things from GoldenQuotes that used to be funny ;) |
| 21:13:38 | JdGordon| | I'm not completly against the idea of splitting up the entire audio buffer into 32KB blocks without the option of getting any smaller ones |
| 21:14:00 | JdGordon| | keeping track of them wouldnt be fun though |
| 21:14:23 | BryanJacobs | JdGordon: like I said before, I've got an ordered linked list already |
| 21:14:51 | BryanJacobs | they couldn't be EXACTLY 32k though unless you want to waste 32k per handle for the struct |
| 21:15:03 | JdGordon| | yeah |
| 21:15:10 | Torne | Linux has FTL and NFTL and one or two others |
| 21:15:18 | Torne | I don't think any of them are directly usable on modern MLC NAND |
| 21:15:28 | Torne | FTL is for NOR, NFTL is for SLC NAND |
| 21:16:31 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
| 21:16:39 | bertrik | Torne, what's the problem with modern MLC NAND? |
| 21:16:44 | bertrik | too many bad blocks? |
| 21:17:20 | Torne | MLC NAND has additional write restrictions and usually uses the entire OOB space for a very strong ECC |
| 21:17:27 | Torne | leaving no OOB space for any wear levelling or mapping data |
| 21:17:39 | Torne | MLC generally requires that the pages of each erase block be written in order |
| 21:17:59 | Torne | i.e. you can't erase 0-3 and then write to page 2 then 1 |
| 21:18:47 | shotofadds | yes, the problem main understanding the TCC FTL was understanding how it "collects" out-of-order writes |
| 21:18:52 | shotofadds | *main problem |
| 21:18:54 | bertrik | Torne, interesting |
| 21:19:38 | Torne | bertrik: this is one of the areas where i'd love to help but would rather not to avoid legal issues :) |
| 21:20:31 | Torne | argh. my bzr-aware version.sh always says the tree is modified, but if i paste the same command into an interactive shell it works :) |
| 21:21:18 | bertrik | I don't know exactly what kind of NAND is used in rockbox targets |
| 21:21:35 | shotofadds | bertrik: pretty much all modern stuff is MLC |
| 21:21:51 | | Join paulk_ [0] (n=paulk@lib33-1-82-233-88-171.fbx.proxad.net) |
| 21:21:53 | Torne | aha, i'm an idiot |
| 21:22:00 | Torne | of course my tree is modified, i've modified tools/version.sh |
| 21:22:04 | Torne | :) |
| 21:22:12 | shotofadds | though I think the DAX / m200v3 etc use an older SLC chip |
| 21:22:18 | paulk_ | Hello ! Do you know where I can found a free pacman room for Rockbox ? |
| 21:22:24 | bertrik | hm, I see most meizus uses MLC indeed |
| 21:22:42 | Torne | If you have an FTL that works on MLC NAND it should also work on SLC NAND. |
| 21:22:57 | Torne | but that's only useful if you are going to repplace the OF entirely :) |
| 21:23:09 | scorche | paulk_: due to copyright bits, you are left on your own with that task...use google |
| 21:23:23 | paulk_ | ok... |
| 21:23:26 | Torne | 1) get a pacman machine |
| 21:23:26 | Torne | :) |
| 21:23:42 | scorche | Torne: a free one! |
| 21:24:03 | paulk_ | I don't know if free pacman rooms are existing... |
| 21:24:03 | Torne | if you have a pacman machine, then a pacman rom is free :) |
| 21:24:16 | paulk_ | I know |
| 21:24:26 | bertrik | Torne, yeah it's a serious dilemma whether to try to be compatible with the OF or completely abandon it |
| 21:24:44 | paulk_ | well, thank-you ! |
| 21:24:45 | Torne | bertrik: if you were just going to abandon it then just nick ubi and ubifs from linux. :) |
| 21:24:54 | * | shotofadds does not want to abandon the D2 OF. it's too useful for things like DAB (spit!) |
| 21:25:10 | | Quit paulk_ (Client Quit) |
| 21:25:40 | linuxstb | shotofadds: Then implement DAB instead ;) |
| 21:25:59 | shotofadds | linuxstb: hmm. DAB is rubbish anyway ;) |
| 21:26:14 | linuxstb | shotofadds: Then you can safely abandon the D2 OF ;) |
| 21:26:20 | shotofadds | problem solved! |
| 21:26:48 | * | shotofadds thinks TCC FTL is probably easier than DAB... |
| 21:26:54 | bertrik | implementing DAB sounds easier than FTL |
| 21:27:07 | * | shotofadds thinks we have a volunteer ;-) |
| 21:27:13 | linuxstb | DAB is pretty well documented AFAIK. |
| 21:27:29 | shotofadds | and the DAB chip in the D2 too....? |
| 21:28:01 | bertrik | I just happened to have borrowed a DAB capable ATMT from AlexP |
| 21:28:02 | linuxstb | I mean you "just" need to tune it and get the transport stream packets... After that, you follow the DAB specs. |
| 21:28:20 | AlexP | bertrik: What a coincidence :) |
| 21:28:37 | shotofadds | well, I wish you the best of luck! |
| 21:28:55 | bertrik | linuxstb, do you have a link to specs or datasheets? |
| 21:29:01 | | Quit Lear ("ChatZilla 0.9.85 [Firefox 3.5/20090624025744]") |
| 21:29:03 | shotofadds | actually, working out this FTL should be a whole lot easier now I've got a writable filesystem for debug logs..... |
| 21:29:03 | linuxstb | bertrik: For DAB? |
| 21:29:23 | bertrik | linuxstb, yes |
| 21:29:28 | CIA-71 | New commit by zagor (r21725): Fixed build time bug and build list zombie bug. |
| 21:29:31 | | Quit captainkwel ("Page closed") |
| 21:30:07 | linuxstb | bertrik: I guess this is a place to start - http://www.etsi.org/WebSite/Technologies/DAB.aspx |
| 21:33:50 | amiconn | shotofadds: UBI sounds somewhat interesting as a starting point |
| 21:35:53 | | Quit Hillshum (Read error: 110 (Connection timed out)) |
| 21:37:13 | | Quit J-23 ("wszed³em") |
| 21:37:21 | bertrik | amiconn, indeed, reading about it now |
| 21:38:49 | CIA-71 | New commit by mcuelenaere (r21726): utils/analysis/find_addr.pl: fix detection of codec start address |
| 21:39:36 | bertrik | I like the idea of an open-source FTL implementation that can be improved over time rather than try to reverse engineer something vendor-specific and never really knowing if you did everything just right |
| 21:40:11 | | Nick AlexP is now known as BigBambi (n=alex@rockbox/staff/AlexP) |
| 21:40:21 | | Nick BigBambi is now known as AlexP (n=alex@rockbox/staff/AlexP) |
| 21:40:27 | gevaerts | I like that too, but that requires dropping OF support, which some people don't want to even think about |
| 21:40:44 | mcuelenaere | don't you need to 'convert' the vendor-specific bad-block format to the open source one at the first run? |
| 21:41:21 | | Join J-23_ [0] (n=zelazko@unix.net.pl) |
| 21:42:05 | | Nick J-23_ is now known as J-23 (n=zelazko@unix.net.pl) |
| 21:42:06 | | Quit webguest81 ("CGI:IRC") |
| 21:43:05 | JdGordon| | cant we say if you want the OF you dont get write support in rockbox? |
| 21:43:10 | JdGordon| | give users the option? |
| 21:44:40 | gevaerts | well, right now there is no open source FTL, and we don't do MTP (yet) so we can't use special flash filesystems, so there's not much option to give... |
| 21:45:23 | amiconn | mcuelenaere: There could be a mix. Vendor-specific header format but open source algorithm |
| 21:47:20 | | Join kachna|lappy [0] (n=kachna@r4ax178.net.upc.cz) |
| 21:48:23 | shotofadds | gevaerts: have a play with fs#10415. see if it breaks anything ;-) |
| 21:48:24 | | Join Xerion_ [0] (i=xerion@82-170-197-160.ip.telfort.nl) |
| 21:48:29 | * | amiconn sees build client activity and fires up the other vm |
| 21:51:48 | Torne | UBI is not able to hist FAT |
| 21:51:59 | Torne | UBI is not an FTL in the traditional sense |
| 21:52:21 | Torne | also, just for reference, it's incredibly difficult to write an FTL that doesn't infringe on a gazillion patents. Best not to look. :) |
| 21:52:52 | bertrik | Torne, can you explain why it can't host FAT? |
| 21:53:02 | Torne | because it doesn't implement a block device interface |
| 21:53:55 | Torne | You can implement a simple block device FTL on *top* of UBI though |
| 21:54:04 | Torne | which takes care of many of the details for you and makes the FTL much simpler. |
| 21:54:09 | Torne | but nobody has actually done so yet afaik |
| 21:54:45 | Torne | UBI takes care of partitioning, wear levelling, and bad block relocatio for you |
| 21:55:01 | Torne | but it still leaves you to deal with erase block restrictions and write block restrictions. |
| 21:55:27 | pixelma | meh, Ubuntuxer makes me commit my half baked jackpot.tex and related patch just to correct the wrong edit to manual/plugins/main.tex if that part should only appear in manuals for targets with colour screens |
| 21:55:57 | Torne | UBIFS is the part which deals with how to thread a filesystem through restricted-write pages |
| 21:57:16 | | Quit BryanJacobs ("Java user signed off") |
| 21:59:02 | | Quit LambdaCalculus37 () |
| 22:00 |
| 22:01:38 | bertrik | Torne, so the FTL on top of UBI would have to take care of mapping (for example) 512-byte sectors into larger erase blocks? |
| 22:01:53 | bertrik | and not worry so much about wear leveling? |
| 22:02:50 | Torne | it would have to think abotu subpage/page/block size, yes, and any ordering retriction within a block (pages in order for MLC) |
| 22:02:53 | Torne | but that's it |
| 22:03:21 | Torne | it can basically assume that all the UBI-exposed logical erase blocks are actually 100% reliable and never fail :) |
| 22:03:38 | wincent | How can I remove pdbox from applications? I would like it to be associated with .pd files and not to appear anywhere else. |
| 22:04:00 | Torne | wincent: just move it to rocks/viewers and update viewers.config to point there |
| 22:04:09 | Torne | the plugin menus are just the file hierarchy under 'rocks' |
| 22:05:11 | JdGordon| | also modify apps/plugins/CATEGORIES |
| 22:05:24 | | Quit Xerion (Success) |
| 22:05:24 | | Nick Xerion_ is now known as Xerion (i=xerion@82-170-197-160.ip.telfort.nl) |
| 22:05:47 | domonoky | wincent: edit CATEGORIES and viewers.config |
| 22:05:49 | bertrik | sounds like a nice GSOC project to implement something with UBI :P |
| 22:06:06 | wincent | JdGordon|: Did so, but the point with file hierarchy was the one I missed. |
| 22:06:13 | wincent | Torne: Thanks! |
| 22:06:29 | amiconn | Torne: That's why I said UBI is interesting as a starting point |
| 22:06:31 | Torne | wincent: if you're building then changing CATEGORIES is enough, that's what determines where the build puts everything |
| 22:06:44 | Torne | you only need to actually move the file around if you're working with bianries ;) |
| 22:07:02 | Torne | amiconn: there are probably other people at least *considering* doing a regular block device ftl for ubi |
| 22:07:29 | amiconn | I was thinking on the line of taking ubi code to implement an entire ftl |
| 22:07:32 | wincent | Torne: Also, one needs to remove the old .rock if a new one was installed with make install. |
| 22:07:53 | Torne | wincent: well yes, new builds aren't going to remove files from old builds |
| 22:07:56 | amiconn | We can't use ubi as-is anyway, as it's made for linux, and rockbox is quite different |
| 22:08:10 | Zagor | finally, a proper post-commit triggered build round |
| 22:08:18 | Torne | bertrik: depends how google feel about patents there thoguh L:) |
| 22:08:47 | Torne | amiconn: yah, but it would be better to have someone from linux mtd implement the ftl and then we rip it off, tbh :) |
| 22:09:00 | Torne | well, potentially better |
| 22:09:09 | Torne | as they are more likely to know the optimal way to do it :) |
| 22:09:42 | | Join Hillshum [0] (n=chatzill@unaffiliated/hillshum) |
| 22:10:24 | bertrik | well, the linux mtd people probably also have a "Mr. Someone" to do stuff like that |
| 22:10:33 | Torne | this is also true. |
| 22:11:01 | Torne | i am completely serious when i say that basically anything we or they come up with probably infringes a bunch of patents though |
| 22:11:17 | Torne | the storage companies have *tons* of patents in this area :) |
| 22:12:13 | | Join n00b81 [0] (n=taylor@unaffiliated/n00b81) |
| 22:12:16 | * | gevaerts now also runs rockbox from SD on a D2 :) |
| 22:12:30 | bertrik | so you're saying that UBI may already infringe? |
| 22:12:31 | mt | question : I've made a change in a file that would require changing indentation of code already in svn (apps/codecs/cook.c), should the changes be committed on two steps - one for the change in functionality and the other for 'cosmetics', or is it ok to commit it all in one step ? |
| 22:12:32 | CIA-71 | New commit by zagor (r21727): Clients build stats page. |
| 22:12:36 | * | shotofadds is glad to see gevaerts heeded the warnings ;) |
| 22:12:46 | Torne | bertrik: it's very likely |
| 22:12:55 | Torne | bertrik: anyone involved in developing it will have Carefully Never Looked |
| 22:13:04 | Torne | since many countries penalise *knowing* infringement more |
| 22:13:12 | AlexP | Of course, it also depends where you are in the world |
| 22:13:17 | Torne | oh of course. |
| 22:13:42 | | Quit martian67_ (Read error: 60 (Operation timed out)) |
| 22:13:45 | mt | Here's the diff to clarify what I'm talking about : http://www.pastie.org/539138 |
| 22:13:52 | JdGordon| | doesnt ignorance mean nothing with patents anyway? |
| 22:14:14 | Torne | JdGordon|: ignorance doesn't mean you are innocent, but in some places knowing infringement is automatic triple damages or similar |
| 22:14:26 | shotofadds | gevaerts: pictureflow is nifty on the touchscreen, don't you think? |
| 22:15:02 | saratogalab | we're already infringing on hundreds if not thousands of patents in the codecs, I'm not sure a few more matter |
| 22:15:18 | Torne | yah. i'm not saying it's any more of a problem than code we already have |
| 22:15:21 | gevaerts | shotofadds: I'll have to try that |
| 22:15:26 | JdGordon| | but... doesnt not searching mean that you assume there is one already anyway? so your up shit creek anyway? :) |
| 22:15:32 | mt | hmm .. the diff went a little bad in shape when copying from the terminal. |
| 22:15:51 | JdGordon| | or.. being able t do it without searching means that it was obvious so the patent shuold be invalid :) |
| 22:15:55 | Torne | JdGordon|: maybe you were just too busy L) |
| 22:18:50 | linuxstb | mt: Do you mean that you are adding an extra outer-loop, so all the code inside the loop is indented, but without changing? |
| 22:18:51 | mt | Here's a nicer diff : http://www.pastie.org/539150 |
| 22:19:18 | mt | linuxstb: Actually, I'm removing an outer-loop. |
| 22:19:29 | linuxstb | mt: Yes, I just figured that out ;) |
| 22:19:33 | mt | :) |
| 22:19:45 | Torne | tiny cosmetic question: is there any reason why the icon for the System menu shouldn't be the same as the system settings menu? currently the system menu uses Icon_Questionmark which is a lightbulb in cabbie and a question mark in lots of other themes, whicih makes no sense. the system menu icon is usually a cog, which seems better :) |
| 22:19:59 | Torne | (er, the system *settings* menu icon is usually a cog) |
| 22:20:23 | linuxstb | mt: I don't think it's worth committing separately |
| 22:20:29 | Torne | i posted a oneliner patch for this on FS #9727 but amazingly nobody has cared to comment :) |
| 22:22:16 | JdGordon| | Torne: that is entirely arbitrary... |
| 22:22:24 | JdGordon| | I saw your patch and couldnt be bothered chaning it :p |
| 22:22:40 | Torne | it is arbitrary, yah, but it looks weird on most themes other than cabbie |
| 22:22:50 | Torne | which tend to implement Icon_Questionmark as a question mark :) |
| 22:22:58 | JdGordon| | silly them! |
| 22:23:02 | JdGordon| | what does cabbie show? |
| 22:23:02 | Torne | which means my main menu has a big question mark on it |
| 22:23:05 | linuxstb | Torne: That sounds more like a bug in cabbie... |
| 22:23:05 | Torne | a lightbulb |
| 22:23:27 | CIA-71 | New commit by mt (r21728): Add the ability to seek to the start of the track. |
| 22:23:28 | linuxstb | questonmark != lightbulb... |
| 22:23:38 | linuxstb | Or am I missing something? ;) |
| 22:23:42 | Torne | but srsly, i can't see why "System" and "System Settings" should have totally different icons |
| 22:23:59 | bertrik | my clip shows a question mark, my e200 shows a light bulb |
| 22:24:02 | Torne | linuxstb: you migth well consider it a bug in cabbie *as well* |
| 22:24:13 | linuxstb | Torne: Yes |
| 22:24:38 | Grahack | mcuelenaere: in helloworld.lua, `if not file` looks more luaistic than `if(file == nil)` (even if I'm no expert) and it seems that file:write(str) doesn't return anything so can't be relied on to check if write was done correctly. |
| 22:24:55 | Torne | but i don't use cabbie, so hey. it just looks weird on every other theme i've tried :) |
| 22:25:20 | JdGordon| | so the actual fix here is to implement customizable icon placement! |
| 22:25:30 | Torne | haha |
| 22:26:22 | JdGordon| | serisouly... it could be easily done |
| 22:26:35 | JdGordon| | every menu has a uniuqe identifier of sorts... |
| 22:26:51 | linuxstb | Torne: Have you noticed where else Icon_Questionmark is used? |
| 22:26:59 | Torne | linuxstb: very very few places |
| 22:27:02 | Torne | the "rate song" menu |
| 22:27:02 | * | linuxstb hands himself grep |
| 22:27:27 | CIA-71 | New commit by pixelma (r21729): Jackpot is now available on all targets, so enable it for all manuals as well. The button table needs to be filled out still though. Also move the opt ... |
| 22:27:37 | Torne | the title for option screens |
| 22:28:04 | Torne | and it's used if something tries to ask for an icon that's out of range, also |
| 22:29:40 | Torne | JdGordon|: i'm sre it could, but i've used a number of themes and the system menu is the only one that was consistently "out of place" to my eye :) |
| 22:30:41 | Torne | so i'd judge our selection of builtin icon constants is not too bad and themers seem to manage ok :) |
| 22:31:11 | wincent | petur,domonoky: I just updated the wiki page and the patch for pdbox: http://www.rockbox.org/tracker/task/10416 |
| 22:31:24 | wincent | Feel free to review. |
| 22:31:27 | petur | wincent: already saw it ;) |
| 22:31:35 | petur | nice work |
| 22:31:37 | Grahack | mcuelenaere: in fact file:write(str) returns a boolean, that you tried to compare to the number 1 (maybe you thought C code) |
| 22:31:42 | | Quit efyx_ (Remote closed the connection) |
| 22:39:11 | | Join efyx_ [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) |
| 22:42:50 | pixelma | from its description, it doesn't sound like the new plugin Clix would need to be colour only (thinking about symbols for greyscale/mono), but it doesn't look like it's using the external bitmap system so every change there is a bit more complex |
| 22:43:54 | mcuelenaere | Grahack: corrected |
| 22:44:40 | mcuelenaere | Grahack: what's your real name? (so I can mention it in the commit message) |
| 22:45:49 | linuxstb | pixelma: Clix? /me looks... |
| 22:46:26 | pixelma | copyrighted name issue? |
| 22:46:43 | mcuelenaere | Grahack: I suppose 'if(rb.lcd_rgbpack ~= nil) then' could be simplified to 'if rb.lcd_rgbpack then' too? |
| 22:48:17 | linuxstb | pixelma: I was just wondering where it came from... Was it on flyspray? (the commit message doesn't refer to it). |
| 22:50:24 | bertrik | linuxstb, yes, FS #8925 |
| 22:52:09 | | Join luke_dozen [0] (n=luke_doz@p54AB62E1.dip.t-dialin.net) |
| 22:52:24 | pixelma | linuxstb: I thought it was but can't seem to find it now |
| 22:52:52 | * | pixelma should also follow the channel |
| 22:54:37 | *** | Saving seen data "./dancer.seen" |
| 22:55:55 | CIA-71 | New commit by pixelma (r21730): Use the correct (feature) option to only include the new clix.tex in manuals of targets with colour screens. |
| 22:56:17 | Grahack | mcuelenaere: Christophe Gragnic |
| 22:56:34 | | Quit Hillshum (Read error: 104 (Connection reset by peer)) |
| 22:58:06 | Grahack | mcuelenaere: `false~=nil` is true so it depends if false is accepted |
| 23:00 |
| 23:01:06 | | Join blackdeagle [0] (n=blackdea@dslb-092-074-204-070.pools.arcor-ip.net) |
| 23:01:14 | | Join martian67 [0] (n=martian6@about/linux/regular/martian67) |
| 23:02:16 | Grahack | good night/day everyone |
| 23:02:20 | | Quit Grahack ("Leaving.") |
| 23:02:35 | | Quit martian67 (SendQ exceeded) |
| 23:03:58 | | Join martian67 [0] (n=martian6@about/linux/regular/martian67) |
| 23:05:58 | CIA-71 | New commit by mcuelenaere (r21731): Helloworld.lua: fix file_put_contents depending on a wrong return value of io.write + use a cleaner version of if(file == nil) (thanks to Christophe ... |
| 23:06:12 | | Join balug_ [0] (n=dvg@HSI-KBW-078-042-132-156.hsi3.kabel-badenwuerttemberg.de) |
| 23:06:44 | | Quit Strife89 ("Dinner is almost ready.") |
| 23:07:03 | pixelma | AlexP: (or others) what would you think about the following indentation style for button tables? http://rockbox.pastebin.ca/1488842 (as an example) |
| 23:07:43 | | Quit bmbl ("Bye!") |
| 23:08:16 | pixelma | the goban button table almost made me go crazy, which is why I thought about one - documented - style and then changing them bit by bit |
| 23:09:08 | AlexP | pixelma: I'd add another line of whitespace between each table line like: http://rockbox.pastebin.ca/1488847 |
| 23:09:15 | AlexP | but yes, I agree |
| 23:09:27 | pixelma | just need to settle on one style (also one for the "directional key" mess |
| 23:09:32 | AlexP | Current button tables are often a nightmare |
| 23:09:44 | pixelma | or settle for? |
| 23:10:25 | AlexP | Depends on context, here I would say settle on :) |
| 23:11:08 | pixelma | AlexP: yes, could live with that too, most important to me was to easily see the start of new columns and rows |
| 23:11:52 | AlexP | Yes, I agree |
| 23:14:25 | pixelma | there might be corner cases which don't fit into that scheme (which I don't know about yet, guess you'll only see when actuall trying to fit them |
| 23:15:23 | | Quit n1s ("Lämnar") |
| 23:15:41 | AlexP | Yeah, but as a general guide it can only be a good thing |
| 23:16:07 | pixelma | the second column could be a problem with the remotes... maybe then an \opt{REMOTEKEYMAP} around them which includes the & and then opting the exact pad seperately? |
| 23:16:26 | pixelma | nested, I mean |
| 23:16:39 | | Quit blackdeagle (Remote closed the connection) |
| 23:17:27 | AlexP | pixelma: Yes, that could be good - then tables automatically work with remotes, and people can add in the buttons later |
| 23:17:35 | | Quit petur ("Zzzzzz") |
| 23:18:03 | AlexP | Someone adding a remote wouldn't have to add \opt{whatever}{&} to every single sodding table :) |
| 23:19:09 | pixelma | hrrmm.. should have done that then. Although - since it's only one pad currently, that could be a search and replace thing |
| 23:20:13 | pixelma | but as it looks like we have to go through all tables anyways, it's not a big thing |
| 23:20:22 | * | domonoky hears a sinus with pdbox ! :-) |
| 23:20:56 | AlexP | pixelma: yep |
| 23:21:13 | wincent | Hello all, I have a problem: PDBox uses original code from Pure Data which causes warnings about strict aliasing. Does it have to be corrected or can it be left as it is? |
| 23:21:36 | pixelma | AlexP: any preference for the "directional keys"? Some tables list left/right/up/down on their own line, some combine left/right, some put them all together, some just mention "directional keys"... |
| 23:22:11 | AlexP | I think that depends on bit on the player unfortunately |
| 23:22:40 | AlexP | Those with a clear up/down/left/right (e.g. H100, beast, ...) could just say directional keys |
| 23:23:01 | AlexP | Others such as c200 where they are also used for other things are a little more tricky |
| 23:23:50 | AlexP | I think directional keys when it is clear, and specify the keys when it is less so |
| 23:24:10 | pixelma | *I* wouldn't think the c200 is special there in plugins (but maybe I'm already a bit blind for things newbies can struggle with), Ipods on the other hand... |
| 23:24:21 | AlexP | yeah |
| 23:24:52 | AlexP | But for those where it is clear I think directional keys is my preference |
| 23:26:24 | pixelma | hard to make a guideline out of this then. I just think that the current situation could be better there and I mostly dislike those longish lists in some tables. I'm trying to put the indentation part on the LatexGuideline wiki page tomorrow |
| 23:26:40 | saratoga | wincent: you could probably disable that warning in the pd make file, but fixing it would be the best option if its possible |
| 23:27:25 | pixelma | and give it a little time for people who have objections to speak up, if there aren't any - start changing the tables |
| 23:27:32 | AlexP | yep |
| 23:27:46 | AlexP | I won't be until next week, out tomorrow and away this weekend |
| 23:28:23 | wincent | saratogalab: For example, in d_soundfile.c the strange casting construction that causes a warning converts a float to long, to write it out to a sound file byte-wise later. |
| 23:29:26 | pixelma | AlexP: alright, I already know your opinion (and will take your suggestion) :) |
| 23:29:47 | * | amiconn wonders whether he should fix the bogomips offset, and whether such a fix would warrant a client version bump |
| 23:29:48 | wincent | saratogalab: So fixing it would be interesting, involving some float/int32_t unions. |
| 23:31:05 | | Join stephen_ [0] (n=stephen@86-45-97-240-dynamic.b-ras2.srl.dublin.eircom.net) |
| 23:32:04 | amiconn | Zagor? ^^ |
| 23:32:23 | rasher | amiconn: the bogomips offset? You mean the +1? |
| 23:32:27 | Zagor | offset? |
| 23:32:29 | rasher | What would the point be? |
| 23:32:37 | amiconn | yes |
| 23:32:40 | rasher | It's not like bogomips means anything useful anyway |
| 23:32:42 | amiconn | Just cosmetic... |
| 23:32:51 | linuxstb | wincent: Why would you need to convert to an int to write byte-wise? Couldn't you just treat it as an array of chars? And what are floats doing in Rockbox? ;) |
| 23:33:48 | Zagor | the bogomips value is very unimportant. it is just a coarse sorting tool for the server. |
| 23:34:26 | wincent | linuxstb: It's not me :-) As I said, it is the original code. |
| 23:35:18 | wincent | linuxstb: And about floats... Well, only sound-data is fixed-point in PDBox; control-data is not. |
| 23:36:41 | saratoga | wincent: is that function used for reading in fp data? |
| 23:37:05 | | Quit stephen_ ("Leaving") |
| 23:37:14 | wincent | saratogalab: Yes, and for writing it out too. |
| 23:37:43 | saratoga | do you anticipate needing to read in fp data ? |
| 23:38:02 | saratoga | requiring integer input would seem to be more efficient, unelss this is for compatibility |
| 23:38:05 | linuxstb | "fp" = floating point or fixed point? |
| 23:38:34 | flyback | I love you guys |
| 23:39:04 | flyback | I haven't had a mp3 player yet to play with rockbox on, m200 sansa bit the dust and the display was broken and it wasn't supported yet anyways |
| 23:39:15 | flyback | but I do plan to get one since I don't like using my palm t5 to do music |
| 23:39:34 | flyback | but it looks like the $8 mp3 player I bought like 3-4 yrs ago will have support in the future also :P |
| 23:39:37 | flyback | samsung soc |
| 23:39:51 | | Join safetydan [0] (n=deverton@rockbox/developer/safetydan) |
| 23:41:08 | saratoga | flyback: i don't think theres any ports to really old mp3 players in progress using a samsung SOC |
| 23:41:34 | flyback | well I saw some info on the page and there is support for some of the newer samsung soc's |
| 23:41:42 | flyback | it's not a big deal it's half dead anyways, missing case and lcd |
| 23:41:48 | flyback | just kinda neat that people actually try |
| 23:41:57 | flyback | I will just end up buying a cheap mp3 or refurb mp3 that is supported |
| 23:42:08 | saratoga | flyback: ports are to MP3 players, not SOCs |
| 23:42:17 | flyback | uh I know that |
| 23:42:22 | flyback | but you have to support the SOC also :P |
| 23:42:25 | saratoga | linuxstb: yes its float if I am grepping correctly |
| 23:42:44 | | Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) |
| 23:45:46 | wincent | saratogalab: It's really for compatibility's sake only. |
| 23:46:34 | | Join Stephen_ [0] (n=S@86-45-97-240-dynamic.b-ras2.srl.dublin.eircom.net) |
| 23:47:04 | wincent | linuxstb: If you'll look into the floating-point hell called pdbox-func.c , you won't have any such question anymore :-> |
| 23:47:28 | | Join calaco [0] (n=46462073@gateway/web/cgi-irc/labb.contactor.se/x-ce548f28ede97ff0) |
| 23:47:34 | saratoga | wincent: with all that floating point how is performance? |
| 23:48:07 | calaco | SanDisk Sansa e280 rockboxable. yes/no?? |
| 23:48:19 | flyback | saratoga, I understand completely that soc support !=rockbox/device support |
| 23:48:21 | saratoga | calaco: check front page |
| 23:48:22 | bertrik | gevaerts, has it ever been tried to replace the RAR in the meizu upgrade image with another RAR (containing rockbox code for example)? |
| 23:48:26 | flyback | all I saying is you have to start with soc support |
| 23:48:27 | AlexP | calaco: v1, yes |
| 23:48:35 | gevaerts | bertrik: pronably not |
| 23:48:35 | flyback | if you don't have that there's 0 chance they will move to device support |
| 23:48:38 | domonoky | calaco: yes, but only v1 are "stable" v2 is in development. |
| 23:48:41 | wincent | saratogalab: Well, a lone sine oscillator is working. |
| 23:48:55 | calaco | k thx |
| 23:49:01 | linuxstb | wincent: My question was simply what did saratoga mean with the abbreviation "fp" - we're talking about a program with both fixed and floating point, and I would use that abbreviation for either.... |
| 23:49:03 | saratoga | wincent: but if this is to be useful it has to run much more then that in real time right? |
| 23:49:26 | pixelma | hmm... it looks like RbUtil needs a connected player to change unrelated settings? At least now when I tried changing its language to english I got a "Mount point not found" when pressing OK until I connected one of my players |
| 23:49:38 | | Quit mt (Read error: 113 (No route to host)) |
| 23:49:40 | wincent | saratogalab: If not, I'll have to do a CPU boost. |
| 23:49:40 | | Quit calaco (Client Quit) |
| 23:51:07 | wincent | linuxstb: It's all right, it's just about the fact that about 90% of pdbox-func.c is a reimplementation of the needed floating point functions. I plan to simplify most of them, though. |
| 23:51:10 | domonoky | pixelma: rbutil checks the important settings like player and mountpoint on closing of the config window.. what do you want todo with rbutil without a player connected ? |
| 23:51:34 | linuxstb | domonoky: Read a manual? |
| 23:51:44 | pixelma | look how the tabs, buttons etc. are called to give support |
| 23:52:20 | | Quit flydutch ("/* empty */") |
| 23:52:31 | domonoky | linuxstb: you cant read it in rbutil, it only provides the link and a download button... :-) |
| 23:52:35 | pixelma | and for that I wanted to know how they are called in English and had to switch languages ;) |
| 23:52:54 | gevaerts | domonoky: download a manual? |
| 23:52:56 | linuxstb | domonoky: Then "Download a manual?" |
| 23:53:04 | domonoky | you can also point it to some random directory, it wont care :-) |
| 23:53:21 | domonoky | it just has to exist and be writeable. |
| 23:53:26 | gevaerts | domonoky: "checks the important settings"? ;) |
| 23:53:29 | wincent | saratogalab: Of course, the (fixed-point) DSP itself is much less complicated than control processing, which resorts to floating-point. |
| 23:53:37 | AlexP | So if the check doesn't actually matter, why force chosing a meaningless directory? |
| 23:53:46 | pixelma | I, as an illiterate for those things would never have though of that |
| 23:53:54 | AlexP | me neither |
| 23:53:59 | domonoky | to force the stupid people todo it :-) |
| 23:54:11 | domonoky | but thats a thing for improvement... |
| 23:54:28 | AlexP | Trouble is, if people don't guess they need to do that (and I wouldn't have), then you can't force them too :) |
| 23:54:33 | linuxstb | Maybe split "settings" and "player configuration" ? |
| 23:54:53 | pixelma | could imagine that very well |
| 23:55:02 | | Nick J-23 is now known as J-23|away (n=zelazko@unix.net.pl) |
| 23:55:08 | domonoky | AlexP: we want them to connect the dap. nearly all functions need it. |
| 23:55:17 | AlexP | but not all |
| 23:55:48 | AlexP | This is maybe a thing more for us - I too have been annoyed by this when trying to look something up for support, but I guess this isn't a standard use case |
| 23:56:57 | domonoky | "we" also know how to trick rbutil :-) |
| 23:57:12 | pixelma | only now |
| 23:57:13 | AlexP | apparently not though, as neither pixelma nor I did :) |
| 23:57:14 | | Quit balug_ ("Ex-Chat") |
| 23:57:36 | domonoky | but autodetection and presentation of current device is a long standing issue i want to improve.. |
| 23:58:07 | pixelma | also "mount point not found" (or the like) doesn't tell me much |
| 23:58:31 | domonoky | pixelma: feel free to improve the user texts in rbutil :-) |
icon identifies that the person is a core developer (has commit access).