Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2009-07-08

00:00:04 Quit Nico_P (Remote closed the connection)
00:00:10AlexPI 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:39redriot02damn 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:11AlexPredriot02: Welcome to the gigabeat S :(
00:02:47redriot02:O
00:03:00ej0rgeredriot02: 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:05ej0rgeyou 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:09redriot02i 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:08ej0rgehttp://www.rockbox.org/twiki/bin/view/Main/GigabeatSInstallation#Step_1b_Bootloader_installation
00:05:18ej0rgeoh, heh, sorry
00:05:21ej0rgethat section is blank.
00:05:56redriotyeah
00:06:29AlexPredriot: http://www.rockbox.org/twiki/bin/view/Main/GigabeatSInfo#Loading_code_from_Linux
00:07:26stripwaxdoes 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:38ej0rgethough someone should edit that so that it doesn't refer to the patched gigabeat V firmware loader
00:07:42redriotwait is this what the contents of partition #2 is supposed to look like ?
00:07:46redriothttp://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:18DBUGSent KICK perrikwp to server
00:08:18DBUGSent KICK perrikwp1 to server
00:08:18***Alert Mode level 2
00:08:18DBUGsent MODE #rockbox +b *!*n=Keith@*.se.biz.rr.com
00:08:18DBUGSent KICK perrikwp2 to server
00:08:18DBUGEnqueued KICK perrikwp3
00:08:18***Alert Mode level 3
00:08:18Torneyes.
00:08:18Tornewhat's on partition 2 doesn't matter a lot
00:08:19DBUGQ-Sent KICK perrikwp3 to server
00:08:19ej0rgeredriot: looks normal to me
00:08:20Kick(#rockbox perrikwp :*bang* too many joined users) by logbot!n=bjst@rockbox/bot/logbot
00:08:20***Alert Mode level 4
00:08:20Kick(#rockbox perrikwp1 :*bang* too many joined users) by logbot!n=bjst@rockbox/bot/logbot
00:08:20***Alert Mode level 5
00:08:20Mode"#rockbox +b *!*n=Keith@*.se.biz.rr.com " by logbot (n=bjst@rockbox/bot/logbot)
00:08:20Kick(#rockbox perrikwp2 :*bang* too many joined users) by logbot!n=bjst@rockbox/bot/logbot
00:08:20***Alert Mode level 6
00:08:20Kick(#rockbox perrikwp3 :*bang* too many joined users) by logbot!n=bjst@rockbox/bot/logbot
00:08:20***Alert Mode level 7
00:08:42redriotdang.. i was hoping thats what the problem was
00:08:48gevaertslogbot getting aggressive again...
00:08:57Torneyou'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:00Torne:)
00:09:11ej0rgeredriot: no, the flash bootloader doesn't like something about the single-boot bootloader
00:09:16AlexPI already linked the dual boot instructions
00:09:21redriotTYorne are you the lead developer for gigabeat s ?
00:09:30ej0rgeredriot: it's pretty much because you have an OF later than 1.1
00:09:39AlexPMost of rockbox applies to most targets
00:10:00AlexPOf the hardware on the S, jhMikeS has done a lot (and Nico_P before him)
00:10:52Torneno, i'm not a developer
00:10:53redriotdamn well now my gigabeat is unusable ?
00:10:59Tornebut i am reverse engineering the gigabeat s bootrom
00:11:09Torneit's not unusable
00:11:13AlexPredriot: Try the dualboot bootloader
00:11:32Tornemake a dualboot bootloader, or just send it the original firmware again
00:12:07 Part captainkwel
00:12:12ej0rgeredriot: 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:49redriotso complicated :/
00:14:06AlexPThat'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:50CIA-71New commit by 03stripwax (r21704): Fix bug introduced in r21616 (my bad)- playlist moving array could show in playlist viewer even when track not being moved
00:41:14stripwaxsigh. ^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:09Zagorper-client stats for new build: http://build.rockbox.org/data/21700-clients.html
00:54:48Zagorthe values don't quite add up though...
00:55:15JdGordon|sweet
00:55:19Zagorthis particular build took 664 seconds wallclock time
00:55:25Zagor*build round
00:57:08Bagderweird
00:58:11JdGordon|just going by the total time numbers... shouldnt saratoga's client have been killed and mc2739's picked up more?
00:58:33JdGordon|I'm assuming that only completed builds are in that list?
00:58:34Bagderit's impossible to tell that based on the numbers alone
00:58:59ZagorJdGordon|: yes, only completed builds
01:00
01:00:06Bagderclearly some time measurements in the server are arong
01:00:08Bagderwrong
01:04:13Zagorit 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:49Bagderthen the ping logic needs to be improved
01:05:01Zagorexactly, shouldn't the server complain about lack of _PING then?
01:05:20Zagormaybe it was something else
01:05:26Bagderperhaps we need something in the client that makes it give up and restart if it gets nothing within a certain time
01:05:33JdGordon|:O you're using _PING instead of PONG?!
01:05:48Bagderwe do, the response messages are all _[message]
01:06:01JdGordon|but.. but.... :p
01:12:31 Join FOAD_ [0] (n=dok@dinah.blub.net)
01:19:10Zagormore fun numbers: http://build.rockbox.org/data/21704-clients.html
01:20:42 Join lee321987 [0] (n=chatzill@76.250.186.194)
01:21:15JdGordon|my client fell off somewhere?
01:21:27JdGordon|at least gevaerts didnt get top spot again :)
01:21:48lee321987Ever heard of a player not being recognized by the computer when in RB, but OF works fine? (Sansa c200)
01:22:27ZagorJdGordon|: unfortunately all your builds got cancelled...
01:22:38JdGordon|lame :p
01:23:54ZagorJdGordon|: 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:37JdGordon|q6600 with 6gb ram and -j4
01:26:11ZagorJdGordon|: 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:50JdGordon|I apparently finished the yh820 build...
01:28:23JdGordon|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:26ZagorBagder: the time is counted from when the build was handed out...
01:29:46Zagorwe need the client to report how long it took
01:35:51 Join JdGordon| [0] (i=460030b3@gateway/web/freenode/x-0400246b87e75526)
01:40:58CIA-71New commit by 03zagor (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:12CIA-71New commit by 03zagor (r21706): Get build time from client.
01:46:44 Quit Thundercloud (Remote closed the connection)
01:47:32CIA-71New commit by 03zagor (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:33stripwaxAnyone around for a quick review of a patch? The last one in FS #7967.
02:20:59stripwaxFixes 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:09stripwaxAfaik 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:57JdGordonjust commit it :)
02:29:19stripwaxYeah - works for me, must be good enough :) Anyway, grep doesn't lie, so −− done.
02:29:46JdGordongrep doesnt lie... but it will give you the output you wernt hoping for if you use it wrong :)
02:30:27CIA-71New commit by 03stripwax (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:21CtcpIgnored 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:34JdGordonor kkurbjun has sent me on a wild goose hunt :p
02:40:45stripwaxJdGordon - who has powers to close a flyspray bug report? I think fs#7967 is done with now.
02:40:53JdGordonyou dont?
02:41:29JdGordoni'll close it, but you should annoy Zagor or Bagder to fix it for you
02:42:35stripwaxI don't know, I might have - if I do have, should it be obvious how?
02:42:55stripwax(Couldn't see any obvious way to close the bug so assumed I just didn't have the special power)
02:42:56JdGordonyes, your in the wrong group
02:43:00stripwaxah
02:43:09*Mikachu can also close bugs, for some reason :)
02:43:42JdGordonit would be nice if we had a single group management system for the whole project
02:44:31Mikachuthat wouldn't be very unixy
02:46:45krazykitgood thing rockbox isn't unix :)
02:47:38stripwaxdarn, 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:07CIA-71New commit by 03jdgordon (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:47lee321987I 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:06lee321987What would be a "non-regular" build?
03:00:40JdGordonthe bootloader i guess
03:01:19 Join Blue_Dude [0] (n=chatzill@adsl-235-206-197.mco.bellsouth.net)
03:01:59lee321987I think I get it. So it should be ok to choose "e200" after configure, and install it onto an e200R?
03:03:00Blue_DudeI'm having a hard time compiling. I keep getting an error: undefined reference to '___assert' in /libcook/bitstream.h
03:06:59Blue_DudeI 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:08mc2739Zagor: 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:39kkurbjunJdGordon: 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:58JdGordonsvn up.. fixed
03:13:19kkurbjunoh nice
03:13:22kkurbjunI missed that
03:13:23kkurbjun:-D
03:14:40kkurbjunnice, I just tested it and it looks like it works fine
03:15:36kkurbjunI 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:53kkurbjunI'm not sure if it does that on the main unit too or if it is intended to do that
03:21:48JdGordonyeah, saw there might be a issue there
03:32:35 Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey)
03:38:10JdGordons/might be/is
03:38:25JdGordonim 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:39BdN3504kkurbjun 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:18eidocan 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:02safetydaneido, only JPEG is supported. you should just be able to "play" them to view them
05:07:00eidoahh 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:56eidosafetydan, ty for the help
05:10:57 Join AndyI [0] (i=AndyI@212.14.205.32)
05:11:42flybackhaha
05:11:51flybackyou guys are even looking at cheap samsung soc ports
05:11:52flybackawesome
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:48will_helloooooooooo
06:00
06:00:52CIA-71New commit by 03kkurbjun (r21710): M:robe 500 - Set the mask on the remote so that it indicates the battery status
06:09:56will_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:59will_Thoughts?
06:11:58JdGordonis it a v2?
06:12:08JdGordonwhats the sansa firmware version?
06:16:28will_v1... 1 sec(it's rebuilding the db :)
06:17:08will_01.02.18A
06:19:37 Join JdGordon| [0] (i=43a02c5a@gateway/web/freenode/x-612f42e9a7d74f9d)
06:21:14JdGordon|ok, doesok, you need to run rbutil as an admin
06:21:21JdGordon|I'm not sure how osx handles that
06:21:40will_ah
06:21:49will_sudo maybe hehe
06:22:23will_In the .dmg, it's "rbutilqt". Is that the same thing you're talking about (didn't want to assume)
06:22:44JdGordon|umm... maybe
06:22:47JdGordon|probably
06:24:49 Quit FOAD (Remote closed the connection)
06:26:57will_Hmm... Well, I get "[INFO] Scanning disk devices...\n[INFO] e200 found - /dev/disk2\n No such file or directory"
06:27:47JdGordon|i think youve come at a bad time... you might want to have a look on the forums for help...
06:27:58JdGordon|or try doing the manual install if you're game
06:28:54will_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:59will_Ok, I might give that a shot.
06:30:23JdGordon|the linux probl;em could be a knon issue with lipgphoto
06:30:26JdGordon|lib*
06:30:55will_ah
06:33:41 Join bluefoxx [0] (i=bluefoxx@S0106005004792985.vs.shawcable.net)
06:35:20bluefoxxSo, 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:19JdGordon|404.. question not found?
06:38:08will_JdGordon: Do you know a guy named Mark Pulver?
06:38:23JdGordon|doesnt ring a bell
06:38:27will_darn ok
06:43:32will_JdGordon|: Ah nice, manual install worked. Thanks a bunch!
06:44:19JdGordon|:)
06:50:59bluefoxxSo nobody can assist me in ripping the firmware from a v1 e200?
06:53:52will_This is my first day with Rockbox :)
06:54:08***Saving seen data "./dancer.seen"
06:54:08JdGordon|you havnt actually asked a question...
06:55:04bluefoxxJdGordon|: You mean me?
06:55:25 Join __lifeless [0] (n=lifeless@188.16.119.4)
06:55:37JdGordon|yes
06:57:00bluefoxxI'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:59gartralheya guys, I have a sansa e250 here that sansapatcher *refuses* to belive is a sansa...
07:50:48Lloreangartral: What firmware version?
07:51:18gartralLlorean: I cant tell.. the scree is smashed in
07:51:36gartralbut I know it's in msc mode
07:51:46will_lol
07:51:49 Quit JdGordon| (Ping timeout: 180 seconds)
07:51:51will_(sorry)
07:51:52Lloreangartral: So how do you know it's a V1?
07:52:03gartralits also running an old Rockbox version
07:52:24LloreanHow was Rockbox installed without Sansapatcher recognizing it?
07:52:38gartralWindows + rbutil
07:53:23Lloreanrbutil uses the exact same code as sansapatcher. Literally.
07:54:04LloreanWhy aren't you using rbutil, anyway?
07:54:05gartralI know.. that's whats wierd
07:54:22gartraltrying to install 7pre4 bootloader
07:55:03rasherErr, there's no 7pre4 for sansas
07:55:58gartralermm.. ok, which ever one is the bootloader that makes it boot too RB on USB insert
07:56:20LloreanYou mean the one from the flyspray task? Why didn't you just refer to it as such?
07:56:42gartralI honestly thought it was a varient of 7pre4.. >.>
07:57:41gartralhttp://gar.pastebin.com/f29c75381 heres the error
07:58:19LloreanYou're not supposed to point it at the mount point.
07:58:48gartralohh..
08:00
08:04:56rasherIn fact, it's not supposed to be mounted at all
08:08:54flybackhttp://www.sparkfun.com/commerce/product_info.php?products_id=9237
08:10:11 Part will_ ("Leaving")
08:12:59gartralhow 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:19gartralim just haveing one of thos re-re days >.>
08:20:59flybacklsusb
08:21:01flyback:P
08:21:06flybackdmesg and grep it for the same thing etc
08:21:54LloreanHave you tried simply running sansapatcher without parameters so it can autodetect?
08:22:12gartralthat's what I just did, reports dev/sdc
08:24:48gartralok, all done.. thank you much Llorean
08:29:13 Join ender` [0] (i=krneki@foo.eternallybored.org)
08:31:46GodEater/dev/sdX was NOT thrown out of the window in jaunty - that's complete tosh
08:33:35gartralyes, I discovered that... but it isnt "visable" from command line.. and was annoying
08:34:31GodEaterwhat 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:28gartralany /dev/sdXX device nodes
08:39:18GodEaterthat's also rubbish
08:39:50gartraldo you want a screenshot? I swear i cant see them
08:40:32JdGordonyou 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:04gartralJdGordon: I have 3 flashdrives, and a dap plugged in almost 24/7
08:42:38GodEatergartral: so "ls /dev/sd*" lists nothing at all is what you're saying
08:45:00gartralthat works... but cd /dev/ && ls doesn't show them
08:45:28gartralwhich makes no sense what so ever..
08:46:07Unhelpfulit makes so little sense that i don't believe it's happening.
08:46:21LloreanThis is pretty off-topic in here at this point anyway. Basic computer use stuff.
08:46:57gartral;opens mouth and insert foot
08:48:47Lloreangartral: 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:35gartralyea.. i know.. im a bit jumpy...
08:50:42gartralsorry
08:54:10***Saving seen data "./dancer.seen"
08:55:46 Join Rob2222 [0] (n=Miranda@p4FDCF7A5.dip.t-dialin.net)
08:56:34amiconnBagder: 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:13Bagderyeah, we discussed that last night
08:57:22Bagderthe 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:11GodEateramiconn: can you tell which one ?
09:05:06Bagderhm, I guess we risk that with killed builds...
09:08:04GodEatermy client is being told "duplicate name" at the moment
09:11:24 Join petur [50] (n=petur@rockbox/developer/petur)
09:12:29rasherIt 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:02rasherBagder: svn cleanup seems to be rather cheap, so maybe just run that always before building?
09:15:18Bagderyes, I believe so too
09:15:31Bagderor even before svn update
09:15:57amiconnWhy does killing builds risk a locked working copy?
09:16:12Bagderif the svn operation gets killed
09:16:51amiconnHmm. Couldn't we ensure that 'svn update' never gets killed?
09:17:16amiconnIf a build is killed while svn updates, just let svn update finish and then stop
09:17:44Bagderwell, that's potentially a very long and slow operation
09:17:59Bagderso 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:48amiconnThe client needs to update svn anyway if it wants to participate at all
09:23:08Bagderyes, but next build might be to another rev
09:25:02GodEatermy client has been booted again with another duplicate name error
09:25:24Bagdermine too
09:25:44Bagderclearly 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:58ReKleSSdoes the H120 have a hardware watchdog or something?
09:49:08ReKleSSI think I've gotten the cpu to halt, but it still powers down after a second or so
09:49:20Bagderit doesn't
09:49:22 Quit n1s (Read error: 110 (Connection timed out))
09:49:30ReKleSSok
09:49:48ReKleSSany 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:50gevaertsBagder: 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:43BagderI think we can just timeout the clients if nothing was "heard" from the server in say 60 seconds
10:17:59Bagderthe 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:07gevaertsit could be the client's read() or write() itself that's stuck.
10:23:16Bagderthey're non-blocking
10:23:30Bagderor should be
10:23:30bluefoxxSo 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:58Bagderhttp://daniel.haxx.se/sansa/fw/ ...
10:25:54bluefoxxI'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:08gevaertsI only know that I've seen netcat stay stuck for weeks. I have no idea how these things actually work :)
10:26:17Bagderbluefoxx: those are all official versions
10:26:20bluefoxxit happens to sansas that my friends have after they update to newer firmware too i've found...
10:26:26Bagderand I bet your version is one of them
10:27:04 Join mt [0] (n=MTee@41.206.134.249)
10:27:11gevaertsbluefoxx: you do know that you need to update the bootloader and main firmware together, right?
10:27:25bluefoxxhmn?
10:27:58bluefoxxBagder: 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:12bluefoxxcame from a barely used sansa that was bought when they just came out
10:28:16 Quit BHSPitMonkey ("Ex-Chat")
10:29:05Bagderwithout version number? :-)
10:29:13LloreanI 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:37bluefoxxLlorean: stock firmware borks on database refresh after updates on my
10:29:39bluefoxxme*
10:29:50bluefoxxlet me dig out a picture of what it did...
10:29:52Bagderthat'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:03gevaertsbluefoxx: 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:20bluefoxxgevaerts: i'm not sure what your talking about here...
10:32:34gevaertsbluefoxx: have another look at http://daniel.haxx.se/sansa/fw/ then
10:33:13gevaertsThere'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:46gevaerts't do this, you get problems
10:34:12Bagderon the e200 you can mostly just update the fw part
10:34:18bluefoxxThis 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:55gevaertsBagder: even if the bootloader is very early?
10:35:18bluefoxxboth of which caused the thing to freak out under stock FW when it tried to do database refreshes
10:35:26BagderI'm not sure, but during my experimentations I rarely replaced the BL one
10:35:30bluefoxxhttp://i31.tinypic.com/2r6mamh.jpg
10:35:35bluefoxxis what would tend to happen
10:35:46bluefoxxor similar things but with green or blue lines
10:36:26bluefoxxthat time was rockbox freaking out at me after an update was suggested, but thats the general idea of what happens...
10:37:27LloreanThat 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:39gevaertsAnyway, 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:41bluefoxxi'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:17bluefoxxhttp://i26.tinypic.com/10ie2vm.jpg is what the firmware update causes on database refreshes
10:38:23bluefoxxand no, its not on any that i touch
10:38:37Lloreanbluefoxx: Seriously, nobody else has ever reported this problem to us with Rockbox.
10:38:46bluefoxxi've several friends who have sansas. they update the firmware, that happens.
10:39:08bluefoxxanyways, thats what the .mi4 files i got off the website did to me
10:39:09Bagdermaybe you're cursed? B)
10:39:13gevaertsbluefoxx: you still haven't said if you actually updated the bootloader as well
10:39:15bluefoxxmy friends don't use rockbox
10:39:34bluefoxxi 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:42bluefoxxi don't bother with the OF myself if i can't help it
10:40:02gevaertsthat's *not* what I mean
10:40:11bluefoxxthen what *do* you mean?
10:40:17gevaertsBL_SD_boardSupportSD.rom
10:40:37bluefoxx?
10:40:38 Quit martian67 (SendQ exceeded)
10:40:43*gevaerts gives up
10:40:49*GodEater doesn't blame gevaerts
10:41:25bluefoxxbah, 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:49amiconnBagder: 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:19amiconnUsing some sort of heartbeat packets would probably help
10:42:47Bagderit's TCP
10:42:57Bagderit'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:46gevaertsBagder: 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:08Sylvai1Hi
11:36:26Sylvai1someone may help me ? I have a question about rockbox
11:36:59Sylvai1I have some files I don't want to register in database
11:37:21Mikachuare they all in the same directory?
11:37:33Sylvai1I 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:35Sylvai1yes
11:37:39Mikachudatabase.ignore
11:37:45Sylvai1thank you
11:37:50Mikachuthere is one in your .rockbox dir
11:37:53Sylvai1so, on my iPod
11:38:47Sylvai1I 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:24Mikachui think so, yes
11:39:42Sylvai1I think so also, I did it ago
11:39:46Sylvai1thank you
11:39:47Sylvai1bye
11:39:57Mikachu:)
11:40:02 Part Sylvai1
11:45:28kugelMikachu: grml
11:45:33kugelwe were about to remove that possiblity for speeding things up :/
11:45:39kugelor we at least thought about it
11:45:57gevaertswell 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:09Grahack1mcuelenaere: 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:17Grahack11) what is the difference between 'const unsigned char* str' and 'const char* str' ?
11:53:30mcuelenaerethat's a C question in general ;)
11:53:54Mikachuthe first is unsigned, the other is signed or unsigned depending on the compiler
11:54:03mcuelenaerea char is on all our targets 8 bits, and when it's unsigned, it uses all those 8 bits for data storage
11:54:20Torneit uses all 8 bits when it's signed as well
11:54:21gevaertsmcuelenaere: it always does that...
11:54:21mcuelenaerewhen signed, it only uses 7 bits and the 8 bit to store whether it's a negative or positive number
11:54:47mcuelenaeregevaerts: not when it's signed, doesn't it?
11:54:48Tornewhether 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:49Mikachuthat's not exactly true
11:55:01gevaertsmcuelenaere: that sign bit is also data...
11:55:01daurnmcuelenaere, Grahack1 wants bindings to the funcs in unicode.c, you able to bind them for him?
11:55:22Mikachumcuelenaere: -0 isn't encoded, that is used for -128, so there is 1/256th data in the sign bit :)
11:55:44mcuelenaereok, I was wrong then :)
11:55:47Tornemcuelenaere: char represents one of 256 values, whether it's signed or not
11:56:07Grahack1daurn: I was making progress this way, maybe I won't need him to make it who knows... just some help
11:56:12dzwith unsigned char, the high bit is valued 128, with signed it's -128
11:56:18mcuelenaeredaurn: are they exposed over the plugin struct?
11:56:52mcuelenaereTorne: sure, but they have a different meaning
11:56:54Mikachubut 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:15Tornemcuelenaere: not until you cast to something else
11:57:39Grahack1so this seems to bea good question, on which the team has different ideas :)
11:57:42dzTorne: or try to compare them
11:58:00Tornedz: see under casting to something else :)
11:58:06Tornecomparing unlike types is coercion
11:58:15gevaertsTorne: not really. 0xff > 0x01 ?
11:58:49Grahack1is there anyone here interested/involved in the dev of the Lua plugin apart from mcuelenaere?
11:58:52Tornegevaerts: always, yes, there is no 0xff from C's pov if it's signed :)
11:59:07gevaertsTorne: 0xfe > 0x01? :)
11:59:07dzTorne: example, does a character fall within the range of ASCII? > 127 or < 0, depending on if it's signed or unsigned
11:59:09mcuelenaereGrahack1: safetydan did the initial Lua porting
11:59:12 Quit Rob2222 ()
11:59:18gevaertsEven if they're both the same type, that depends on whether they are signed. No casting involved
11:59:38Tornegevaerts: but there's no such thing as a signed char with value 0xfe, is my point there :)
11:59:43Grahack1mcuelenaere: 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:50Tornethere's one with in-memory representation of 0xfe but C doesn't care
12:00
12:00:06gevaertsTorne: true, but sometimes that matters
12:00:16mcuelenaereGrahack1: hmm, will look into it; what is the ^ operator supposed to do in Lua?
12:00:32gevaertsi.e. if you write them to disk and read them back on another arch where default signedness is different
12:00:54Grahack1^ is the power operator
12:01:49Grahack1it needs the math lib, which I'm trying to code in pure Lua (well, basic functions)
12:02:18mcuelenaerehmm pow() is currently an empty function currently (returning 0
12:02:20mcuelenaere)
12:02:39mcuelenaereso the sim is using a different one than the DAP is
12:03:12Grahack1BTW 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:19daurnmcuelenaere, 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:19mcuelenaeredaurn: why floor the exponent? it isn't a float value
12:04:22mcuelenaere(not in Rockbox)
12:04:34daurnmcuelenaere, ok then, don't :P
12:05:17mcuelenaerewell 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:52Grahack1So 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:53mcuelenaereGrahack1: well, 'at some point' doesn't mean in the near future ;)
12:14:38Grahack1I'll be patient, it will be nice even in 10 years.
12:14:40mcuelenaereGrahack1: if the utf8 functions you need are exported through the plugin struct, they should get wrapped to Lua automatically
12:16:15Grahack1you 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:53Grahack1(the relevant text file in my source tree should be up to date)
12:17:05mcuelenaereehm 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:21Grahack1or docs/PLUGIN_API
12:17:25mcuelenaere(and I'm 'planning' to rework the API documentator thingy)
12:17:32mcuelenaerethat's also outdated I think
12:17:53Grahack1arf, I'll look into plugin.h then
12:18:41mcuelenaereactually, rockbox_api_example_3 is based on docs/PLUGIN_API
12:19:40Grahack1generated from the head of the svn repo ?
12:20:52 Quit mt (Read error: 110 (Connection timed out))
12:20:57mcuelenaereyes, but at that time though
12:21:24mcuelenaere(it isn't updated since then probably though)
12:23:43daurnGrahack1, seems you already have the funcs then :D
12:23:50Grahack1it seems that some are: utf8decode iso_decode utf16LEdecode utf16BEdecode utf8encode
12:24:06mcuelenaereyeah I looked into utf8decode, and that probably requires manual porting
12:24:11mcuelenaerebecause of the unsigned short* ucs part
12:24:27mcuelenaere(which rocklib_aux.pl can't handle)
12:25:12CIA-71New commit by 03zagor (r21711): Fail more gracefully on svn error.
12:26:40Grahack1mcuelenaere: 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:51wincentHello all! How can I change the sampling rate on UI simulator?
12:27:55mcuelenaerehmm 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:20AlexPBagder / 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:26AlexP...mean
12:29:34daurnmcuelenaere, its just strings
12:29:53BdN3504is it normal, that i get the error: "first allocation unit is not valid" when i run chkdsk on my sansa e270?
12:30:00BdN3504v1 that is
12:30:35mcuelenaeredaurn: 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:46daurnGrahack1, you need utf16BE, ascii , utf8 and utf16 conversion for id3v2
12:30:48Grahack1I 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:08daurnmcuelenaere, lua doesn't have null terminated strings at all, strings are 8bit safe
12:31:21Grahack1daurn: I was indeed looking where those functions were needed
12:31:28mcuelenaeredaurn: ah it does?
12:31:37daurnmcuelenaere, of course
12:35:42mcuelenaereGrahack1: see firmware/common/unicode.c for a description of what those functions do
12:42:26daurnGrahack1, 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:12BdN3504scandisk 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:09daurnGrahack1, you seem to have every function you need already...
12:51:03daurnoh, cept the BOM reading function is #if 0'd out
12:51:25BdN3504rockbox woN't have any difficulties dealing with this, will it?
12:54:17***Saving seen data "./dancer.seen"
12:59:02Grahack1daurn: I'm trying to figure out what parameters to give them to make them mimic your functions
13:00
13:00:15daurnGrahack1, shouldn't be too hard if the functions are bound reasonably....
13:10:45 Join kugel [0] (n=kugel@rockbox/developer/kugel)
13:12:34kugelgevaerts: 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:16kugelgevaerts: 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:29gevaertswe 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:07CIA-71New commit by 03mcuelenaere (r21712): Lua: expose SCREEN_MAIN & SCREEN_REMOTE (for rb.lcd_*() functions)
14:00
14:09:50 Quit lilltiger (Remote closed the connection)
14:10:29dionoeamcuelenaere: 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:30mcuelenaerehmm and then rb.lcd & rb.remote is a metatable containing the constant?
14:12:27 Quit Universal ("Leaving")
14:12:56dionoeamcuelenaere: rb.lcd/remote would be tables containing that constant and they would share the same meta table to define the methods
14:13:21dionoeakind of like 2 instances of the same class (in OOP speak)
14:13:48dionoeait's just an idea I had when reading your commit message :)
14:14:17mcuelenaereyes, a bit like rockbox images are currently handled
14:14:21mcuelenaereI'll put it on my TODO list :)
14:14:23daurndionoea, it would be bettter if it was the screen/contents that could be operated on
14:14:50daurneg, mybmp:putlcd ( x ,y ) and mybmp:putremote( x , y )
14:14:55daurns/mybmp/mytext/
14:16:01dionoeamcuelenaere: ok :) I can have a look too if you want
14:16:40mcuelenaeredionoea: sure
14:17:24mcuelenaeredaurn: and what's mytext? (an instance of .. ?)
14:17:28dionoeaI have a 5 day week-end coming up ... so that should leave me some time to code
14:17:36daurnmcuelenaere, could be a string, or anything really
14:17:55dionoeadaurn: the action is really lcd specific, not string specific
14:18:03dionoeaso it belongs in an lcd class IMO
14:18:06mcuelenaereoh, are putlcd and putremote global methods here?
14:18:15mcuelenaereand I agree with dionoea
14:18:20 Join kugel [0] (n=kugel@rockbox/developer/kugel)
14:18:25daurnno, they are in the string's __index metatable
14:18:33 Quit kugel (Read error: 104 (Connection reset by peer))
14:18:34mcuelenaerethat sounds a bit hacky
14:18:44 Join kugel_ [0] (n=kugel@e178108120.adsl.alicedsl.de)
14:18:47dionoeabbl
14:18:50 Nick kugel_ is now known as kugel (n=kugel@e178108120.adsl.alicedsl.de)
14:19:00daurnso you rather lcd:putstring ( mystring , x , y ) ?
14:19:08kugelgevaerts: it's not mentioned there, hence I needed to look at the code
14:20:44dionoeadaurn: no, lcd:putstring(x, y, mystring) looks better :D
14:20:59 Quit boobaloo ("ChatZilla 0.9.85 [Firefox 3.5/20090624025744]")
14:21:01mcuelenaeredaurn: there's no putstring method
14:21:06kugelsomeone give the clip sim button descriptions :S
14:21:24mcuelenaereand 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:08dionoeamcuelenaere: does lua run on all the targets?
14:23:15 Quit robin0800 ("Leaving")
14:23:22mcuelenaeredionoea: all those with PLUGIN_RAM_SIZE > some value
14:23:25dionoea(if yes I'll see if I can port some of the games to lua, like solitaire)
14:23:27dionoeaah ok
14:23:33 Join robin0800 [0] (n=robin080@81.98.157.181)
14:23:48mcuelenaeredionoea: #if (PLUGIN_BUFFER_SIZE >= 0x80000)
14:24:08mcuelenaereso most of them
14:24:38dionoeaI'll do it as a poc then :D
14:25:01daurnGrahack1, you there?
14:25:07daurndionoea, poc?
14:25:50dionoeaproof of concept
14:25:56gevaertskugel: http://download.rockbox.org/manual/rockbox-h100/rockbox-buildch3.html#x5-260003.1.3
14:26:18kugelgevaerts: eh
14:26:34kugelI searched for "dual boot" and "dualboot", but not "dual-boot" :/
14:26:47kugeland it's wrong anyway.
14:26:51kugelYou need REC only
14:29:16kugelbut my lecturer was very enthusiastic and impressed by rockbox
14:31:06gevaertsdid you show doom?
14:31:34kugelno, 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:18CIA-71New commit by 03kugel (r21713): Make the Sansa Clip and Fuze sim keymapping more like other Sansas with regard to the use of the numpad
14:47:08rasherErp, lots and lots of failed builds from my buildclient
14:48:17rasherAh, "svn: No such revision 22000"
14:48:20rasherNaughty
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:25MxxConhey 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:13MxxCon(sorry for grammar, didn't have my coffee yet)
14:59:21rasherI
14:59:29rasherI'm pretty sure it's enabled by default
15:00
15:03:32kugelMxxCon: you can't even disable it
15:05:08mcuelenaerekugel: is there a define to enable this behaviour?
15:06:41kugelmcuelenaere: yes, HAVE_LCD_ENABLE || HAVE_LCD_SLEE
15:06:44kugelP
15:06:58MxxConi didn't want to disable it, just want to make sure that it was on
15:07:06mcuelenaerekugel: ok, thanks
15:07:12kugelMxxCon: I meant to say it is always on
15:07:43MxxConcool, thanx
15:11:02GodEaterI 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:20mcuelenaeregevaerts: 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:06ReKleSSis there a description of the rockbox.iriver format somewhere?
15:35:12mcuelenaereReKleSS: look in tools/scramble.c
15:35:45ReKleSSok
15:35:57mcuelenaeremt: 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:27kugelteru: hey. welcome \0/
15:36:49mcuelenaereReKleSS: the iriver format seems to be in tools/iriver.c
15:37:51mtmcuelenaere: No, where ?
15:37:59kugelmcuelenaere: I think that's only about patching the OF file
15:38:21mcuelenaeremt: in the logs somewhere :) I was wondering whether the flyspray entry shouldn't get closed now that you've committed it?
15:38:51kugelor maybe not
15:38:53mcuelenaerekugel: uh, isn't that how Rockbox generates the rockbox.iriver files? (iriver_encode)
15:39:02ReKleSSiriver.c seems to be for the original firmware, not for the rockbox.iriver
15:39:21mcuelenaerescramble.c calls iriver_encode(), which is in iriver.c
15:39:30linuxstbmcuelenaere: 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:45ReKleSSrockbox.iriver is made with scramble -add
15:39:47mcuelenaereah ok, sorry
15:39:58*mcuelenaere didn't look in tools/configure
15:40:33kugelmcuelenaere: re: your last comment in the task, it depends if the variables are on the stack for the caller
15:40:49kugelbut stack is also memory, so it doesn't really matter.
15:40:58mcuelenaereyeah but it's more dynamic
15:41:05mcuelenaerebut anyway, that's unrelated to mt's work
15:41:19mtmcuelenaere: 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:32mcuelenaeremt: ah ok, forgot about the seeking part :)
15:41:41*mcuelenaere just thought your forgot to close it :)
15:42:33linuxstbmt: 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:15mtlinuxstb: 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:13linuxstbmt: The task should be self-contained. People won't know to look in other places for info about it.
15:48:00mtYes. 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:27linuxstbWhat patch?
15:52:21mtlinuxstb: The last patch in the task wasn't the one committed, there were some modifications after that ..
15:52:38mcuelenaeremt: hmm seems my target starts crashing whenever I put a .rm file on it
15:52:45mcuelenaereprobably metadata parser choking on it
15:53:13mtmcuelenaere: What target do you have ?
15:53:21mcuelenaeremt: Onda VX747 (MIPS)
15:53:46mthmm .. I'll check it when I get back home.
15:53:48linuxstbmt: That's OK - just post a comment saying "a modified version of the above patch was committed as r21695"
15:54:11mtlinuxstb: okay, will do :)
15:56:36mcuelenaeremt: error is in metadata_common.o -> read_uint32be
15:57:05mcuelenaere18:8e040000 lwa0,0(s0) -> probably an unaligned access
15:57:12mtmcuelenaere: Could I reproduce that in the sim ?
15:57:24mtOh, I think no :)
15:57:27mcuelenaeredon't think so
15:57:36Grahack1I 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:46mcuelenaerethe 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:30mtmcuelenaere: Do you have other targets to test on ?
16:09:35ReKleSSthis 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:46mcuelenaeremt: nope
16:09:50ReKleSSthe IriverFlashing page says the original reset vector is 0x8, which is in the flash space
16:09:55ReKleSShow does this work?
16:10:03mcuelenaeremt: I inlined read_uint32be() and the unaligned access is in get_rm_metadata
16:10:56SlasheriReKleSS: the OF runs directly from flash, and so does rockbox ROM image too
16:11:39ReKleSSbut at init, isn't the address it points to unconfigured?
16:11:39mtmcuelenaere: I think the problem could be in rm_parse_header (it's in get_rm_metadata)
16:11:45mcuelenaereit'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:34mcuelenaeremt: if you understand MIPS assembly: http://pastie.org/538573
16:12:52mcuelenaere(line 93)
16:13:05ReKleSSthe way I read the MCF5249 datasheet the only accessible memory is whatever's connected to CS0, the flash
16:13:46mcuelenaerehum, that looks weird
16:13:52SlasheriReKleSS: 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:50ReKleSSyes, 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:58kkurbjunReKleSS: 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:04mt__bbl
16:21:11 Quit mt__ (Client Quit)
16:21:12ReKleSSI'm guessing it's something like that, I'm not sure
16:21:27ReKleSSI'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:14SlasheriReKleSS: the bootloader reset vector should be in the flash
16:23:26Slasherior otherwise it would be incorrect
16:24:03 Quit mt (Read error: 104 (Connection reset by peer))
16:24:25Slasheribe sure not to confuse between the stack location and the execution entry point
16:24:39Slasheristack should be in iram, and execution entry in flash
16:25:16ReKleSSohhhhh, that's it, I'm looking at the stack pointer
16:25:20ReKleSSok, that works now
16:25:39Slasherihehe, nice :)
16:26:11ReKleSSbtw, 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:04Slasheriouch, you were the one. but you have build a bdm? that's great!
16:27:20gevaertsgood :) We need more people with bdm tools!
16:27:44ReKleSSerr, 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:29Slasheriwith bdm available, i would of course recommend flashing the current svn bootloader and hacking plenty with it =)
16:28:38ReKleSSdoes it add anything?
16:29:17Slasheriit 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:29ReKleSSheh, ok, I'll try that
16:29:44Slasherigreat :)
16:30:05CIA-71New commit by 03kkurbjun (r21714): M:Robe 500: fix a bug where the remote LCD was not properly sleeping
16:30:15ReKleSSI have a CF adaptor here too, and a somewhat dodge 32gb CF card
16:31:16Slasherioh, 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:14mcuelenaeremt: it crashes at read_uint32be(fd, &rmctx->bit_rate); /*avg bitrate*/ in case FOURCC('P','R','O','P'):
16:34:30mcuelenaeremt: replacing line 422 with RMContext *rmctx = (RMContext*) ((int)id3->id3v2buf &~ 3); seems to work
16:37:16mcuelenaerehmm getting codec failure's though
16:37:24linuxstbmcuelenaere: Doesn't that round the address down?
16:37:35mcuelenaereyes I know, it's not good
16:37:46mcuelenaerebut at least it makes the unaligned access go away :)
16:38:01linuxstb;)
16:38:11linuxstbJust add 3 first should be OK
16:40:22wincentGentlemen and ladies, PDBox makes sound on-target!
16:40:42gevaerts\☺/
16:40:44 Quit patmulchrone (Read error: 60 (Operation timed out))
16:40:52gevaertsis it the expected sound? ;)
16:40:59wincent:-D Yes!
16:41:05 Join patmulchrone [0] (n=pat@99.13.70.2)
16:41:19wincentPure and simple sine of 220 Hz.
16:41:31 Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net)
16:41:46rasherGood news
16:42:38wincentI'll do a clean (without debugging info) patch later in the evening.
16:47:29Grahack1mcuelenaere: 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:17mcuelenaere1) will fix 2) look in the source ;)
16:48:58mcuelenaereGrahack1: currently it does if(!rb->file_exists(filename)) flags |= O_CREAT;
16:49:05mcuelenaereso if the file doesn't exist, it makes it
16:51:31Grahack1even in "read" mode ?
16:51:53TorneGodEater: my ipod goes wrong witn 9702 in basically exactly the same way as horscht's does
16:52:25TorneGodEater: 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:36Torneer, 9708
16:52:45Tornei was going to do a build with just 9708 but I've not gotten around to it yet
16:52:51Torneit's too much effort to narrow it down :)
16:53:44AlexPIt is always good to check however
16:53:45mcuelenaereGrahack1: yes, but fixed now
16:53:51TorneAlexP: yah, i am intending to do so
16:53:56AlexPThings can have unexpected consequences :)
16:54:00 Nick AlexP is now known as AlexP_ (n=alex@rockbox/staff/AlexP)
16:54:01Tornei 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:14Tornei am fairly careful about how i do it though
16:54:24Tornei use it for many hours between adding patches :)
16:54:26***Saving seen data "./dancer.seen"
16:54:37Torneand have playlists saved for testing with many different codecs interleaved etc :)
16:54:43CIA-71New commit by 03mcuelenaere (r21715): Lua IOlib: don't create files when they don't exist
16:55:34linuxstbmcuelenaere: What does that mean?
16:56:14mcuelenaerelinuxstb: when opening files in Lua, if they didn't exist, they got created
16:56:23Torneif 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:32linuxstbmcuelenaere: That's not what the commit message said ;)
16:56:49mcuelenaereheh, /me expects people to read the the diff ;)
16:58:17linuxstbThe diff doesn't help much either (without more context)...
17:00
17:00:03CIA-71New commit by 03mcuelenaere (r21716): RM metadata parser: fix unaligned access
17:00:54linuxstbTorne: What do you think? ;)
17:01:15Torne?
17:01:45linuxstbTorne: 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:43Torneheh
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:17saratogamt: about what you mentioned earlier today, would it be possible to have the .rm parser descramble AC3 files in .RM ?
17:14:12mtmcuelenaere: Thanks for the fix. :)
17:14:23mcuelenaerenp
17:14:32mcuelenaeremt: I didn't get the codec working though
17:16:03 Quit Sajber^ (Read error: 104 (Connection reset by peer))
17:16:52saratogais MIPS big endian then?
17:17:09mcuelenaerelittle endian
17:17:12mcuelenaereat least this one is
17:17:37 Join n1s [0] (n=n1s@rockbox/developer/n1s)
17:17:43mtsaratoga : Maybe, but AC3 will still have to go through a different path.
17:18:20saratogamt: 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:54mtI'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:34mtmcuelenaere: Let me test on my dap ..
17:21:20mcuelenaeremt: I only tried http://samples.mplayerhq.hu/real/AC-cook/FUN_RM_96.rm , I'll try some others too
17:22:14mtmcuelenaere: It's crashing in cook.codec ? i.e get_rm_metadata finishes properly then the codec fails ?
17:22:30mcuelenaeremt: 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:45mtRMContext 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:25mcuelenaereah
17:29:02mcuelenaeremt: right, that does make it work :)
17:29:22mt\o/
17:29:29mcuelenaereshall I commit or will you?
17:29:47 Quit flydutch ("/* empty */")
17:30:04mtIt would be faster if you committed. :)
17:31:38CIA-71New commit by 03mcuelenaere (r21717): Cook codec: make sure the RMContext get aligned correctly, or we won't be able to find it
17:32:40linuxstbsaratoga: 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:54GodEaterTorne: 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:45GodEaterTorne: 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:34saratogalinuxstb: 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:03saratogai was hoping we could preprocess the file enough during parsing that liba52 doesn't need to be changed
17:40:09linuxstbsaratoga: No - we just have "a52.codec" and "a52_in_rm.codec", which both link to liba52.
17:40:09linuxstbOr at least, that's how I imagined it working. Similarly for "mp3_in_rm"
17:40:49linuxstbliba52 shouldn't need changing.
17:41:32mtlinuxstb: 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:12linuxstbmt: 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:18mtFine. I'll work on seeking first though.
17:48:51TorneGodEater: 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:02Tornei 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:46linuxstbBryanJacobs: Hi. How are things going?
17:54:00Tornegrr, kbd_input() changes font and doesn't set it back :(
17:56:05linuxstbBryanJacobs: 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:43Tornedoes the git branch of rockbox have some kind of .gitignore file in it?
18:28:59Torne(also why must every bloody vcs have ignores in a different format and location)
18:30:26JdGordon|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:51HillshumDoes 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:38linuxstbHillshum: 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:29Hillshumthe gigabeat does it already right?
18:54:30***Saving seen data "./dancer.seen"
18:54:56linuxstbYes, I just looked at the keymaps now.
18:55:23linuxstbDo we have any other rotated targets?
18:55:48HillshumWait, the Fuze doesn't need to be rotated
18:56:23linuxstbCorrect...
18:57:07*mcuelenaere wonders why nobody yelled about the yellow..
18:57:18linuxstbYellow!
18:58:22 Join patmulchrone [0] (n=pat@99-13-70-2.lightspeed.cicril.sbcglobal.net)
18:58:49AlexPI've never played a film on my e200, but that change seems a no-discussion one to me
18:58:53AlexPShould go in :)
18:59:08AlexPFS #10210 that is
18:59:12mcuelenaereanyone with a 64-bit pc willing to test this patch for me? http://pastie.org/538780
18:59:22bertrikSo we just need a committer ...
18:59:27ej0rgeI've never tried to watch any video on the e200
18:59:41AlexPbertrik: Hmmm, I don't see any around :)
19:00
19:00:20ej0rgephilips sa9200 would benefit too, off the top of my head
19:00:30ej0rgedunno that mpegplayer is even working on that yet
19:01:28bertrikok, I will test and commit FS #10210
19:01:49AlexPcool
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:16BryanJacobslinxstb: 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:51BryanJacobs'm almost done with multifile buffering
19:09:56BryanJacobsI 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:45bertrikI should add the patch creator to docs/CREDITS, right?
19:12:05mcuelenaereyes, 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:45CIA-71New commit by 03bertrik (r21718): Accept FS #10210: "Mpegplayer playback controls on portrait oriented players" by Matthew Bonnett.
19:15:55pixelmahow 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:22Hillshumpixelma: is it in /Volumes ?
19:16:37Hillshumalso try disk utility
19:16:41pixelmaI'd like to help finding out a bit more but I have no idea about Macs...
19:17:15pixelmaHillshum: sorry, no idea... you have to be very patient with me
19:17:36 Quit petur ("work->home")
19:17:49BryanJacobsTorne: I've been using your USB-charging patch and my 5.5G works with everything I've plugged it into
19:18:06Hillshumpixelma: It should be mounted in /Volumes/
19:18:31pixelmawhich means for me?
19:19:02CIA-71New commit by 03mcuelenaere (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:25Hillshumpixelma: run "ls -l /Volumes/" in a terminal
19:20:50pixelmayes, I see a SANSA_C250 there, where do I go from here?
19:21:58Hillshumcd /Volumes/SANSA_C50
19:39:16HillshumWhat happened to the Tester badges?
19:39:47LambdaCalculus37Hillshum: You'll have to bother scorche about that.
19:40:25JdGordon|BryanJacobs: ring buffer is logical for buffering because... umm.. it just is :p
19:40:29AlexPWhat tester badges?
19:40:39JdGordon|who else would you want to do it?
19:41:11BryanJacobsJdGordon: was that supposed to be "how"?
19:41:15HillshumAlexP: Wasn't the idea thrown around at devcon?
19:41:18 Join Horscht [0] (n=Horscht2@xbmc/user/horscht)
19:41:22JdGordon|BryanJacobs: yes :p
19:41:30AlexPHillshum: Perhaps, I can't remember
19:41:39 Join Blue_Dude [0] (n=chatzill@64.25.25.6)
19:41:41AlexPHillshum: I have no idea how you would set down criteria for that
19:41:44BryanJacobsthe way I'm implementing it is as a set of allocated spaces which may be contiguous but sometimes aren't
19:42:03JdGordon|sized how?
19:42:21BryanJacobsstarting with constant size and chained together
19:42:40CIA-71New commit by 03Ubuntuxer (r21720): new game plugin for colored players named clix (by Rene Peinthor)
19:42:40BryanJacobsas in, you can have a 128k allocation be four 32k chunks
19:43:14BryanJacobsif space is available and things aren't freed immediately we can expand a chunk
19:44:09bertrikUbuntuxer, is this patch the one from FS #8925?
19:44:14BryanJacobsthis lets multiple files play nicely together :-)
19:44:17linuxstbBryanJacobs: 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:19Ubuntuxeryes
19:44:31BryanJacobslinuxstb: fragmentation, yes, copying, no
19:44:54linuxstbBryanJacobs: So what happens if the file is fragmented, and the codec wants 32KB of data, split across fragments?
19:45:28BryanJacobslinuxstb: ok, in that case you either need copying or duplication
19:45:35bertrikUbuntuxer, please put the FS# in the commit message next time
19:45:42BryanJacobsbut the current codecs don't seem to do that much...
19:45:51linuxstbBryanJacobs: They do...
19:45:52BryanJacobsif you only use advance_buffer that doesn't happen at all in fact
19:45:54UbuntuxerI forgot it, sorry
19:46:00BryanJacobsI'm not considering seeking yet
19:46:05LambdaCalculus37Ubuntuxer: New game? :)
19:46:12linuxstbBryanJacobs: Nor am I....
19:46:29Ubuntuxeryes, but just for colored players
19:46:34*BryanJacobs has been using the wavpack codec as a reference
19:46:43BryanJacobsit only makes use of two or three buffering calls
19:46:52BryanJacobsand only reads forward in the file unless you seek
19:47:06linuxstbBryanJacobs: That's probably a bad example, as it's not using the buffering API as efficiently as other codecs...
19:47:12BryanJacobshm.
19:47:12 Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org")
19:47:13linuxstbIIRC, it's using read() ?
19:47:41BryanJacobsit was using read in the PC version; in Rockbox it uses codec_advance_buffer
19:47:54linuxstbOK, let me have a quick look at it...
19:48:36BryanJacobsbesides, we should only really have to copy occasionally
19:48:41linuxstbBryanJacobs: It seems to be using read_filebuf()
19:48:52BryanJacobsinto its own local buffers
19:48:53BryanJacobsone 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:08BryanJacobsactually, look at it like this
19:50:14BryanJacobsif 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:24BryanJacobsthen there'll always be space after the current handle to expand it
19:50:27BryanJacobsright?
19:50:49linuxstbNot 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:07BryanJacobsits handle will be added after that other data
19:51:10linuxstbSorry, ignore that, I don't think I understood your question...
19:51:22BryanJacobsso, the buffer will look like:
19:51:25linuxstbI'm talking about things getting fragmented...
19:51:29BryanJacobsOTHERDATA -> mydata
19:51:36 Join Zagor [242] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net)
19:51:48Blue_DudeAll 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:55BryanJacobsnow, in the case we're only buffering one file, it will go to -> mydata -> OTHERDATA -> mydata and then to just mydata
19:52:07linuxstbBlue_Dude: That's very possible - it's a new commit...
19:52:23BryanJacobsso, there won't be any fragmentation in the single-file case
19:52:39BryanJacobsin the multi-file case it can arise, yes
19:52:42Blue_DudeBut 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:52linuxstbBlue_Dude: Because the daily builds don't use cygwin...
19:52:55mcuelenaereBlue_Dude: those aren't build with cygwin
19:53:09Blue_DudeUm. Hm. now what? Revert?
19:53:19UbuntuxerUps, I forgot the keymap for the h300 in clix, I'll fix this...
19:53:22linuxstbBryanJacobs: But the multi-file case is the most common - Rockbox almost always has more than one file buffered.
19:53:38BryanJacobsno, I don't mean two files buffered serially
19:53:51BryanJacobsin the original buffering code it "finishes" the old file before starting the new one
19:53:58BryanJacobshere, let me get you a source line
19:54:02mcuelenaereBlue_Dude: how exactly does it breaks?
19:54:07HillshumBlue_Dude: try the next to latest commit (svn update rockbox -r <number>)
19:54:08Blue_Dudelinuxstb: I'm gonna post a bug report in FS. Then I guess roll it back.
19:54:33 Quit Hillshum (Client Quit)
19:54:36Blue_DudeHillshum: it's been breaking since yesterday. It's not just the latest.
19:55:49pixelmaok, 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:51bertrikBlue_Dude, I'll try to build an e200 sim and see what happens
19:56:01Blue_Dudemcuelenaere: It says, and I quote: [....]/apps/codecs/libcook.a(bitstream.o): in function 'put_bits':
19:56:07pixelmaany idea what I could try and check?
19:56:25linuxstbBryanJacobs: So you're saying that your patch doesn't modify the existing buffering behaviour (for "normal" codecs)?
19:56:29mcuelenaereBlue_Dude: only that line?
19:56:42BryanJacobslinuxstb: buffering.c line 236
19:56:43pixelmaas I said though - I don't know a lot about Macs...
19:57:05Blue_Dudemcuelenaere: [....]/apps/codecs/libcook/bitstream.h:196: undefined reference to '___assert'
19:57:15BryanJacobslinuxstb: 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:34Blue_DudeYes there are *three* underscores, not two like you'd think.
19:57:53linuxstbBryanJacobs: So it's still treated as a single ringbuffer for normal files?
19:57:56mcuelenaereBlue_Dude: try #ifndef CYGWIN
19:58:05Blue_DudeIn that file?
19:58:12mcuelenaereeh, __CYGWIN__
19:58:13BryanJacobslinuxstb: yes, the only difference is that it won't ACTUALLY allow overwriting other people's data
19:58:18mcuelenaereno, around the assert() calls
19:58:19 Join saratogalab [0] (n=9803c264@gateway/web/cgi-irc/labb.contactor.se/x-7d1a5c883081427c)
19:58:36linuxstbBryanJacobs: What do you mean?
19:58:38BryanJacobssee buffering.c line 619
19:58:43BryanJacobswhere the allocation is cut short
19:58:44saratogalabyou could just comment out the assert calls
19:58:56BryanJacobsin my code it would cause fragmentation instead
19:58:57mcuelenaereBlue_Dude: or better, do #ifdef __CYGWIN__ #define assert #endif
19:58:58saratogalabthey shouldn't do anything
19:59:10linuxstbBryanJacobs: 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:21BryanJacobsit's a correct comment...
19:59:24Blue_Dudemcuelenaere: I have an idea. The current include in that file is #include <assert.h>. Would #include "assert.h" work better?
19:59:44BryanJacobsthis means someone has requested more data than can be immediately buffered contiguously into the current handle
19:59:45mcuelenaereI don't know, does Rockbox has its own assert.h file?
19:59:56mcuelenaerehavE*
20:00
20:00:00Blue_Dudemcuelenaere: There one in firmware/include
20:00:00BryanJacobsso it doesn't buffer as much as they asked for
20:00:02TorneBryanJacobs: 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:38gevaertsYay!
20:00:38pixelma:)
20:00:38BryanJacobsin my code, it instead tries to find space between some of the handles in the list
20:00:40AlexPcongrats :)
20:00:51linuxstbBryanJacobs: Hmm, well that shouldn't happen in practice. Or does it?
20:00:52shotofaddsgevaerts: and I'm not even using the OF...
20:01:09BryanJacobslinuxstb: no, that code on line 619 shouldn't happen in practice, that would be bad
20:01:21gevaertsshotofadds: I know. You wouldn't do something horrible like talking about using the OF in #rockbox :)
20:01:29BryanJacobs"Try to recover by truncating this file" x_x
20:01:48shotofaddsgevaerts: what's the status of your storage rework?
20:01:51BryanJacobsif that line ever happens you won't ever get the rest of the file into the buffer without reopening it
20:02:15pixelmaRockbox 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:30Blue_Dudemcuelenaere: 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:39linuxstbBryanJacobs: 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:04BryanJacobslinuxstb: but it'll happen occasionally and expectedly in the new code...
20:03:15mcuelenaereBlue_Dude: so changing it to "assert.h" works?
20:03:24BryanJacobsexample buffer layout: FILE1 FILE1 FILE1 FILE2 EMPTY EMPTY EMPTY
20:03:26Blue_Dudemcuelenaere: Dunno yet. I'm trying it now.
20:03:31bertrikshotofadds, that's a new feature for the D2?
20:03:38BryanJacobsthat'll cause it to happen if the user requests more FILE1 to be buffered
20:03:54saratogalabthat same file is included in wma, i'm pretty sure we just commented out the asserts
20:04:03shotofaddsbertrik: yeah, since we had a read-only filesystem until now...
20:04:12BryanJacobswhat I want the result to look like: FILE1 FILE1 FILE1 FILE2 FILE1 EMPTY EMPTY
20:04:40pixelmaso the D2 port is getting closer to be usable?
20:04:47linuxstbBryanJacobs: So have you rejected the idea of having a wavpack-specific file loader that interleaves the data at buffering time?
20:04:50Blue_Dudemcuelenaere: Rock and roll. There it goes.
20:04:57Blue_Dudemcuelenaere: Works.
20:05:11BryanJacobslinuxstb: I can still do that. Would you prefer that I abandon this and do that instead?
20:05:16mcuelenaereok, I'll commit that then
20:05:23BryanJacobsit's just so... domain-specific
20:05:47BryanJacobsactually, 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:56Blue_Dudemcuelenaere: It's the #include in the libcook/bitstream.h file.
20:05:58BryanJacobsJdGordon: but it will get simpler!
20:06:05shotofaddspixelma: there are still usability issues with the touchscreen in certain situations, but it's getting there now
20:06:06CIA-71New commit by 03zagor (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:07mcuelenaereBlue_Dude: I know
20:06:22Blue_Dudemcuelenaere: OK, just so we're on the same page. :)
20:06:27BryanJacobslinuxstb: the interleaved loader is much easier to do
20:06:34pixelmashotofadds: congrats! :)
20:06:35linuxstbBryanJacobs: For once I agree with JdGordon| - a simpler buffering system would be nice...
20:06:41CIA-71New commit by 03mcuelenaere (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:12shotofaddspixelma: 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:21shotofadds*be able to
20:07:36JdGordon|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:42Blue_Dudemcuelenaere: Hang on. Hung up again later. I'm restarting a clean build to fix dependencies.
20:08:05BryanJacobsJdGordon: for simplicity I currently use a sorted linked list
20:08:10BryanJacobsand insert-in-order to keep it going
20:08:15Blue_Dudemcuelenaere: It went past the previous section and stopped later. Same error.
20:08:30mcuelenaereBlue_Dude: you sure? did make clean?
20:08:30linuxstbBryanJacobs: 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:43Blue_Dudemcuelenaere: Making clean now.
20:08:46BryanJacobslinuxstb: OK, I'll start on that right away then, it's much easier to finish
20:08:53mcuelenaereUbuntuxer: yellow!
20:09:10*mcuelenaere thinks we need a yellow-shouting bot
20:09:18BryanJacobsthe only issue is getting the right code into the buffering thread
20:09:27linuxstbBryanJacobs: But I also don't want to discourage you from improving the more general Rockbox buffering code... ;)
20:09:29UbuntuxerI'm in.
20:09:29amiconnshotofadds: 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:58shotofaddsamiconn: how would you see that working?
20:10:17JdGordon|change the .rockbox folder path...
20:10:17CIA-71New commit by 03Ubuntuxer (r21723): add keymap for m300 and fix warnings of previous patch
20:10:17Blue_Dudemcuelenaere: Is NDEBUG defined for sim builds anywhere?
20:10:22amiconnJust use different default paths for this...
20:10:32mcuelenaereBlue_Dude: I don't know what NDEBUG does..
20:10:58Blue_Dudemcuelenaere: Me either. But it voids the assert declaration if it's defined.
20:11:01linuxstbBryanJacobs: 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:23linuxstbBryanJacobs: 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:47BryanJacobslinuxstb: the issue is that the previous/next files could be buffering too...
20:11:53Blue_Dudemcuelenaere: Right there with you. Let's see if the clean build works forst.
20:11:55Blue_Dudefirst
20:12:12linuxstbBryanJacobs: How? I thought there was just a single buffering thread, buffering files sequentially.
20:12:23linuxstbmcuelenaere: Or just delete them?
20:12:34BryanJacobsit allocates the SPACE sequentially
20:12:40mcuelenaerelinuxstb: perhaps they're usefull for debugging purposes?
20:12:42JdGordon|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:05BryanJacobsJdGordon: easy to do by making a handle whose size is the whole needed size
20:13:22BryanJacobsI've only been fragmenting audio data so far
20:13:37BryanJacobslinuxstb: there are two threads working
20:13:47BryanJacobsthere's the actual buffering thread, which loads the data
20:14:02BryanJacobsand then the other one which does things like allocating handles and requesting buffering stuff
20:14:34BryanJacobsthe issue is when the wavpack-specific code would be invoked - it would have to be from the buffering thread
20:14:45linuxstbYes, so why is that a problem?
20:14:46BryanJacobsand ONLY when inside a wavpack-type handle
20:15:06BryanJacobsso, 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:20linuxstbIs a handle a struct?
20:15:33BryanJacobsyes, that's where I'd put the callback
20:15:42BryanJacobsstruct memory_handle
20:15:51 Join jordan` [0] (i=gromit@78.235.252.137)
20:17:09Blue_Dudemcuelenaere: frak. Broke again.
20:17:21*amiconn doesn't really understand how multi-file buffering could work at all
20:17:23mcuelenaereBlue_Dude: huh, with the asserts commented out?
20:17:44Blue_Dudemcuelenaere: No. Clean build with "assert.h"
20:17:50BryanJacobsamiconn: take a look at my preliminary patch...
20:18:26amiconnAfaiu the buffering thread would need to know the relation between the two files. Both might be larger than the total available ram
20:18:27JdGordon|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:50BryanJacobsJdGordon: I was thinking of a max size, no real min
20:19:02BryanJacobsso that when someone asks for 128k they get 4x32k
20:19:37BryanJacobsI wasn't worried about little bitty bits going to waste if people ask for 31k at a time
20:20:01JdGordon|and if someone keeps requesting 4k?
20:20:06JdGordon|or less
20:20:13BryanJacobsthen they'll get a chain of 4k -> 4k -> 4k
20:20:26BryanJacobsor actually
20:20:36BryanJacobsif there's room it can be their first handle gets grown
20:20:54BryanJacobsso they get a 4k handle, then it becomes 8k, then 16k, and so on
20:20:59BryanJacobserr 12
20:21:01BryanJacobsI can add really
20:21:23JdGordon|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:35JdGordon|probably :)
20:21:45BryanJacobsno, there's no fragmentation at all in the current use cases
20:22:10BryanJacobsthe ONLY time there'd be fragmentation is if you interleave buffering calls AND you don't free things promptly
20:22:30JdGordon|there almost has to be after a while of buffering and freeing...
20:22:34JdGordon|bbs
20:22:37linuxstbBryanJacobs: With the typical (I think) example of a 4MB .wv, 30MB correction file and 28MB audio buffer, how would the buffering work?
20:22:47BryanJacobslinuxstb: interleaved or multifile?
20:23:09BryanJacobsI mean, which buffering system are we talking about here?
20:23:17linuxstbBryanJacobs: With your patch - which is that?
20:23:27BryanJacobsmultifile
20:24:05Blue_Dudemcuelenaere: Assert is just a DEBUGF type message, I guess? Well, it compiled with out them. Total of 5 lines commented out.
20:24:06BryanJacobswith my patch, the 4MB .wv is buffered sequentially and the 30MB correction file makes space around it
20:24:20linuxstbSo what if the .wv is larger than the buffer?
20:24:30BryanJacobsonly one chunk of the .wv is used at a time
20:24:39BryanJacobsunless a CHUNK is larger than the buffer we're OK
20:24:59BryanJacobsand only 4k of the chunk is used in one go in the optimized code
20:25:12amiconnWhat 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:56mcuelenaereBlue_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:21wincentAnyone knowledgeable about cpu_boost() here?
20:26:32BryanJacobshow 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:52linuxstbBryanJacobs: 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:58Blue_Dudemcuelenaere: Yeah. Except I commented out the #include also.
20:27:11BryanJacobslinuxstb: the answers are yes and yes, but for a) they won't notice :-)
20:27:17mcuelenaereyeah, I hesitated about that; seems like bad code style to me :)
20:27:30BryanJacobsthe API is still compatible and there should be no major performance losses for existing codecs
20:28:02CIA-71New commit by 03mcuelenaere (r21724): Previous commit didn't fix compiling on Cygwin, this one should.
20:28:03amiconnlinuxstb: And also, how does it handle seeking?
20:28:06linuxstbBryanJacobs: So a codec that reads a variable amount of data at a time (between 0 and 32KB) won't be adversely affected?
20:28:24BryanJacobslinuxstb: as long as it's the only file actively being buffered, no
20:28:41linuxstbWhat do you mean by "actively being buffered"?
20:28:44Tornebut the usual case is that the playing file is *not* being actively buffered
20:28:54Tornenormally the file being played has been entirely buffered, on large mem targets
20:28:58 Quit DarkDefender (Remote closed the connection)
20:29:13BryanJacobsI mean that when you call bufopen(), you're not going to call it again until you change files
20:29:14Torneand if it's been buffered into non-contiguous bits of ram, what happenes if the codec then reads in variable size chunks
20:29:19domonokythere are so many different cases, we need pictures :-)
20:29:20mcuelenaerewincent: what do you want to know?
20:29:26BryanJacobsTorne: that doesn't happen!
20:29:40linuxstbBryanJacobs: Is "bufopen()" the function called when a codec starts decoding a file?
20:29:47TorneBryanJacobs: er, i'm pretty sure it does...
20:29:47BryanJacobslinuxstb: yes
20:30:01BryanJacobsTorne: not in the case where you have one file playing, then you open a second one
20:30:18BryanJacobsand then you move on to a third after finishing with the first one
20:30:26BryanJacobsthey move together so there's never any interleaving
20:30:27TorneBryanJacobs: 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:40gevaertsshotofadds: multidriver will be a lot easier once I have a real target to test it :)
20:30:41wincentmcuelenaere: How fast is the switching of frequency?
20:30:43Torneand what the resulting change in behaviour is for the mp3 codec
20:30:49linuxstbgevaerts: Elio!
20:30:57mcuelenaerewincent: depends on the target, if it changes PLL or just a divider..
20:31:00Tornewincent: varies on different platforms
20:31:05BryanJacobsTorne: oh, yeah, you'll get fragmentation there, but the mp3s will still WORK, there'll just be an occasional memcpy
20:31:11gevaertslinuxstb: that's your drawer, not mine!
20:31:19linuxstbgevaerts: That can be fixed ;)
20:31:24mcuelenaerewincent: how fast do you want it to be?
20:31:25TorneBryanJacobs: yes. that's the poitn i'm getting at: how occasional do you think occasional is? :)
20:31:37domonokywincent: so you shoudnt boost/unboost too often..
20:31:38gevaertslinuxstb: I still think that pondlife is a better victim :)
20:31:48BryanJacobsTorne: it's a function of the amount of RAM available and how much data the codec needs at once
20:31:59BryanJacobsif the codec prompty frees everything it uses, that should NEVER happen
20:32:19Tornehm? how does the codec freeing anything have anything to do with it?
20:32:20BryanJacobsif 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:33Tornei'm talking about the case where teh mp3 has been completely buffered into ram before playback of it even starts
20:32:46Tornebut it was buffered into several noncontiguous reginos, because of the previous effect of your codec
20:32:58BryanJacobsif the codec frees old space, the hybrid stuff will go in there instead of in "front" of the mp3
20:33:25BryanJacobsif the hybrid codec frees its space efficiently, the mp3 won't need to be buffered noncontiguously in the first place
20:33:27wincentIn PDBox I make the calculations in the main loop, so I thought it could need some additional processing power.
20:33:40linuxstbBryanJacobs: How does the buffering code know how to share the RAM between files 1 and 2 (i.e. .wv and .wvc?
20:34:02mcuelenaerewincent: what target do you have?
20:34:12TorneBryanJacobs: 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:24wincentmcuelenaere: iriver H320
20:34:36BryanJacobslinuxstb: 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:48BryanJacobsTorne: yes
20:34:49wincentBut now, as PDBox works with the most simple test, we will see whether CPU boost is needed.
20:35:02linuxstbBryanJacobs: Sorry, I'm still talking about your "generic" multifile buffering.
20:35:28TorneBryanJacobs: 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:47Tornejust 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:48BryanJacobslinuxstb: 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:58mcuelenaerewincent: I would say, test it on-target and see whether cpu_boost()'ing really speeds up things (which they will I suspect)
20:36:08BryanJacobsTorne: but it's the same thing!
20:36:21amiconnlinuxstb: 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:33TorneBryanJacobs: not if you're saying it changes behaviour for existing codecs it's not
20:36:40wincentmcuelenaere: That is what I intend to do.
20:36:52BryanJacobsTorne: when the multifile bits are no longer resident the behavior of the existing codecs will be identical to before
20:37:19BryanJacobswhen the multifile bits ARE resident, it'll be different only in that occasionally they'll have to get memmoved
20:37:27TorneBryanJacobs: identical in effect, or in performance?
20:37:31amiconnOtherwise 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:32linuxstbamiconn: 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:33Tornei.e. is there still overhead involved in having your code there
20:38:11BryanJacobsTorne: 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:17BryanJacobsthere's no SIGNIFICANT overhead
20:39:06BryanJacobsit does the same thing as before but in a different way
20:39:18BryanJacobsdifferent *but equivalent* way
20:39:57BryanJacobslinuxstb: the loader benefits greatly from codec-specific knowledge
20:40:08BryanJacobsbut it's not absolutely required
20:40:49BryanJacobswhat 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:01BryanJacobsis that around right?
20:41:03Torneyes :)
20:41:07domonokyyes :-)
20:41:09BryanJacobsI'd be more than glad to do that
20:41:12Torneany scheme to make this work is going to be complicated
20:41:24BryanJacobsI wouldn't say that...
20:41:32 Join petur [0] (n=peter@rockbox/developer/petur)
20:41:37BryanJacobsthe scheme itself can be simple, analyzing its behavior can be hard
20:41:38domonokybuffering is complicated. there are so many use-cases... so pictures surely will help.
20:41:57 Quit Ubuntuxer ("Leaving.")
20:42:10BryanJacobsbut before I do that I'll go with linuxstb's idea and make a Wavpack-specific buffer...er
20:42:20BryanJacobsthat should be quick and dirty
20:42:44amiconnI wonder whether it would be helpful to divide the *whole* buffer into equally sized chunks (e.g. 32KB). Iiuc mpegplayer does this.
20:43:24BryanJacobsamiconn: the only thing that helps with is avoiding very small free areas, right?
20:43:30BryanJacobsoh and simplifying management
20:44:00pixelmait avoids simplifying? ;)
20:44:07amiconnA 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:13BryanJacobspixelma: :-P
20:44:15Torneactually 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:44BryanJacobsTorne: 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:50linuxstbamiconn: Do you mean that files can be scattered anywhere in the audio buffer, in 32KB chunks?
20:45:04amiconnYes, basically
20:45:40BryanJacobsmpegplayer 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:51Torneyou 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:00Torneto minimise the frequency with which you have to memcpy()
20:46:12*BryanJacobs agrees with Torne
20:46:18Torne(which then means you waste more ram with slack space)
20:46:25linuxstbThat 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:29amiconnThe maximum amount of data a codec is guaranteed to get *is* 32KB (iirc)
20:46:33BryanJacobsyou 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:47Blue_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:54mcuelenaere:)
20:47:04Torneamiconn: 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:08BryanJacobslinuxstb: if you don't have a chunk header/footer it's OK...
20:47:11Torneamiconn: when you have it in noncontiguous 32kb blocks
20:47:40BryanJacobsI 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:56BryanJacobsI mean until sum(N)=32k
20:47:57amiconnThe blocks shouldn't be noncontiguous by default, but optionally
20:48:05linuxstbBryanJacobs: What about Torne's example of requesting two 31KB chunks?
20:48:17 Quit Blue_Dude (Read error: 110 (Connection timed out))
20:48:18Torneamiconn: yes, it will try its best to make them noncontiguous
20:48:26Tornebut it won't always be able to succeed :)
20:48:29BryanJacobslinuxstb: that would require three 32k chunks in a row to pass
20:48:53Torneer, to make them contiguous
20:49:13*BryanJacobs thinks people are catching on to what he was proposing
20:49:16amiconnNo, and for those cases it would need to memcpy
20:49:36BryanJacobsthere's no way to get around having to copy *sometimes* if people require contiguous space
20:49:39amiconnBut that shouldn't happen often. It doesn't solve the questions related to multifile buffering
20:49:40BryanJacobsmalloc() does that too
20:49:49Torneamiconn: yes, at which point the larger the block size is, the less memcpys there are, even if the fragmentation pattern is identical
20:50:10amiconnTorne: Less memcpy()s perhaps, but not less data to copy
20:50:35BryanJacobsamiconn: no because you know how much of a block is used
20:50:46BryanJacobsat most the same amount of data is copied
20:50:50BryanJacobs*are copied
20:50:58BryanJacobs**number of data are copied
20:51:02BryanJacobs***sigh
20:51:08GodEater hahaha
20:51:13amiconnThe 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:29amiconnThe larger the blocks, the more memory is wasted
20:51:31Torne(also technically small memcpys are more expensive)
20:52:41amiconn32KB blocks are already quite large considering out lowmem targets
20:53:15BryanJacobswho says this can't be target-specific?
20:53:27Torneamiconn: sorry, i'm being too socratic. i meant that my conclusion is that keeping blocks fixed like that is probably not optimal
20:53:33amiconnOn the swcodec lowmem targets, the audio buffer is <1MB iirc. 1MB would be just 32 32KB blocks
20:53:43BryanJacobsBUFFERING_DEFAULT_FILECHUNK can be defined based on target
20:53:45Tornebecause you want the blocks to be big really but that wastes more ram :)
20:54:21Tornenot 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:56BryanJacobswhy don't we just take someone else's malloc implementation and change all codecs to use malloc/realloc?
20:55:16BryanJacobsthen it'd be pluggable
20:55:30domonokywincent: congratulations for first pdbox sound :-)
20:55:30amiconnmalloc() is not wanted in rockbox, because it doesn't make sense
20:56:00BryanJacobsamiconn: ? seems to make sense to me... we're talking about allocation policies and fragmentation levels here
20:56:00TorneBryanJacobs: malloc()'s allocation strategy is not optimal for normal codec, is why :)
20:56:18amiconnhttp://www.rockbox.org/twiki/bin/view/Main/WhyNoMalloc
20:56:20Torneyou want an allocatino strategy which under our "normal" use case behaves as close to ring buffering as possible ;)
20:56:34Torneand ideally with overhead as close to ring buffering's as well :)
20:56:45BryanJacobsamiconn: that does not apply
20:56:56Tornenormal mallocs tend to consider total heap size to be one of the parameters to minimise
20:57:10Tornewe have a fixed 'heap' size and thus that criteria is irrelevant
20:57:15BryanJacobsamiconn: 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:55BryanJacobsTorne: why would malloc not behave like ring buffering under our normal use case?
20:58:04ZagorBryanJacobs: because malloc is per definition sub-optimal for a ring buffer
20:58:08linuxstbBryanJacobs: The audio buffer is essentially a FIFO - hence the use of a ring-buffer. That's not malloc...
20:58:16amiconnIt also applies here. malloc() is not made for the kind of allocation needed here
20:59:07amiconnIn our own allocation scheme, blocks can be moved around if necessary. malloc pointers are fixed unless you're calling realloc()
20:59:37BryanJacobsbut 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:27bertrikshotofadds, do you think you'll ever be able to write the internal NAND?
21:02:19bertrikI'm looking into the meizus which have the 'whimory' flash translation layer and I'm starting to lose hope for it
21:02:29shotofaddsbertirk: i could physically write to the NAND now, but that wouldn't be very clever ;-)
21:02:53shotofaddswith a bit more reverse engineering, I think it's possible for the TCC FTL
21:03:15bertrikdoes the TCC FTL also do wear leveling?
21:03:30shotofaddsyes, everything's done in software
21:04:05shotofaddsI don't currently know what algorithm they are using
21:04:22JdGordon|BryanJacobs: IIRC handles can (and do) move around currently
21:05:08amiconnshotofadds: Do we need to use the same algorithm, or is there some kind of mapping table?
21:05:12bertrikIf it didn't do wear leveling but just relied on error correction I could imagine that it's easier to reverse engineer
21:05:40shotofaddswe could use a different algorithm, but wouldn't that affect the wear-levelling ability overall?
21:06:03BryanJacobsJdGordon: a handle is only moved when more data are requested, not when something else is growing
21:06:19BryanJacobsas in, we can't grow handle B when handle A enlarges
21:06:40saratogaIMO 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:16bertrikshotofadds, amiconn : have you ever seen an open-source FTL?
21:07:20shotofaddsamiconn: there is no lookup table, but it scans all physical blocks on startup, so we could potentially arrange them however we choose.
21:07:25BryanJacobssaratoga: if we only used the audio buffer as the "heap" how would that be a problem?
21:07:45shotofaddsbertrik: I've never looked at one, if such a thing exists
21:07:46saratogai'm not sure what you're thinking here, but without free I'm not sure how useful malloc really is
21:08:10BryanJacobssaratoga: 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:40saratogayou won't provided you only ever allocate blocks of exactly one size and do not care about having memory continuous between blocks
21:08:41JdGordon|as soon as its made avialable to buffering, there will be calls to make it usable elsewhere
21:09:03gevaertsbertrik: there are some wear-leveling filesystems, but I don't know of any translation layer
21:09:46bertrikfor some targets we could do a complete firmware replacement (i.e. lose the OF filesystem), but that's quite a big step
21:10:20gevaertsbertrik: that would require mtp or something similar as well
21:10:21bertrikfor 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:58bertrikthat'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:20BryanJacobsJdGordon: so it shouldn't be implemented because people would want it?
21:11:45JdGordon|we *dont* want it though... you were linked the reasons
21:12:28BryanJacobsI 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:10Tornethere are FTLs in linux
21:13:16GodEaterI 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:38JdGordon|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:00JdGordon|keeping track of them wouldnt be fun though
21:14:23BryanJacobsJdGordon: like I said before, I've got an ordered linked list already
21:14:51BryanJacobsthey couldn't be EXACTLY 32k though unless you want to waste 32k per handle for the struct
21:15:03JdGordon|yeah
21:15:10TorneLinux has FTL and NFTL and one or two others
21:15:18TorneI don't think any of them are directly usable on modern MLC NAND
21:15:28TorneFTL 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:39bertrikTorne, what's the problem with modern MLC NAND?
21:16:44bertriktoo many bad blocks?
21:17:20TorneMLC NAND has additional write restrictions and usually uses the entire OOB space for a very strong ECC
21:17:27Torneleaving no OOB space for any wear levelling or mapping data
21:17:39TorneMLC generally requires that the pages of each erase block be written in order
21:17:59Tornei.e. you can't erase 0-3 and then write to page 2 then 1
21:18:47shotofaddsyes, the problem main understanding the TCC FTL was understanding how it "collects" out-of-order writes
21:18:52shotofadds*main problem
21:18:54bertrikTorne, interesting
21:19:38Tornebertrik: this is one of the areas where i'd love to help but would rather not to avoid legal issues :)
21:20:31Torneargh. 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:18bertrikI don't know exactly what kind of NAND is used in rockbox targets
21:21:35shotofaddsbertrik: 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:53Torneaha, i'm an idiot
21:22:00Torneof course my tree is modified, i've modified tools/version.sh
21:22:04Torne:)
21:22:12shotofaddsthough I think the DAX / m200v3 etc use an older SLC chip
21:22:18paulk_Hello ! Do you know where I can found a free pacman room for Rockbox ?
21:22:24bertrikhm, I see most meizus uses MLC indeed
21:22:42TorneIf you have an FTL that works on MLC NAND it should also work on SLC NAND.
21:22:57Tornebut that's only useful if you are going to repplace the OF entirely :)
21:23:09scorchepaulk_: due to copyright bits, you are left on your own with that task...use google
21:23:23paulk_ok...
21:23:26Torne1) get a pacman machine
21:23:26Torne:)
21:23:42scorcheTorne: a free one!
21:24:03paulk_I don't know if free pacman rooms are existing...
21:24:03Torneif you have a pacman machine, then a pacman rom is free :)
21:24:16paulk_I know
21:24:26bertrikTorne, yeah it's a serious dilemma whether to try to be compatible with the OF or completely abandon it
21:24:44paulk_well, thank-you !
21:24:45Tornebertrik: 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:40linuxstbshotofadds: Then implement DAB instead ;)
21:25:59shotofaddslinuxstb: hmm. DAB is rubbish anyway ;)
21:26:14linuxstbshotofadds: Then you can safely abandon the D2 OF ;)
21:26:20shotofaddsproblem solved!
21:26:48*shotofadds thinks TCC FTL is probably easier than DAB...
21:26:54bertrikimplementing DAB sounds easier than FTL
21:27:07*shotofadds thinks we have a volunteer ;-)
21:27:13linuxstbDAB is pretty well documented AFAIK.
21:27:29shotofaddsand the DAB chip in the D2 too....?
21:28:01bertrikI just happened to have borrowed a DAB capable ATMT from AlexP
21:28:02linuxstbI mean you "just" need to tune it and get the transport stream packets... After that, you follow the DAB specs.
21:28:20AlexPbertrik: What a coincidence :)
21:28:37shotofaddswell, I wish you the best of luck!
21:28:55bertriklinuxstb, do you have a link to specs or datasheets?
21:29:01 Quit Lear ("ChatZilla 0.9.85 [Firefox 3.5/20090624025744]")
21:29:03shotofaddsactually, working out this FTL should be a whole lot easier now I've got a writable filesystem for debug logs.....
21:29:03linuxstbbertrik: For DAB?
21:29:23bertriklinuxstb, yes
21:29:28CIA-71New commit by 03zagor (r21725): Fixed build time bug and build list zombie bug.
21:29:31 Quit captainkwel ("Page closed")
21:30:07linuxstbbertrik: I guess this is a place to start - http://www.etsi.org/WebSite/Technologies/DAB.aspx
21:33:50amiconnshotofadds: 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 ("wszedem")
21:37:21bertrikamiconn, indeed, reading about it now
21:38:49CIA-71New commit by 03mcuelenaere (r21726): utils/analysis/find_addr.pl: fix detection of codec start address
21:39:36bertrikI 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:27gevaertsI like that too, but that requires dropping OF support, which some people don't want to even think about
21:40:44mcuelenaeredon'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:05JdGordon|cant we say if you want the OF you dont get write support in rockbox?
21:43:10JdGordon|give users the option?
21:44:40gevaertswell, 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:23amiconnmcuelenaere: 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:23shotofaddsgevaerts: 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:48TorneUBI is not able to hist FAT
21:51:59TorneUBI is not an FTL in the traditional sense
21:52:21Tornealso, 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:52bertrikTorne, can you explain why it can't host FAT?
21:53:02Tornebecause it doesn't implement a block device interface
21:53:55TorneYou can implement a simple block device FTL on *top* of UBI though
21:54:04Tornewhich takes care of many of the details for you and makes the FTL much simpler.
21:54:09Tornebut nobody has actually done so yet afaik
21:54:45TorneUBI takes care of partitioning, wear levelling, and bad block relocatio for you
21:55:01Tornebut it still leaves you to deal with erase block restrictions and write block restrictions.
21:55:27pixelmameh, 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:57TorneUBIFS 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:38bertrikTorne, 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:53bertrikand not worry so much about wear leveling?
22:02:50Torneit would have to think abotu subpage/page/block size, yes, and any ordering retriction within a block (pages in order for MLC)
22:02:53Tornebut that's it
22:03:21Torneit can basically assume that all the UBI-exposed logical erase blocks are actually 100% reliable and never fail :)
22:03:38wincentHow can I remove pdbox from applications? I would like it to be associated with .pd files and not to appear anywhere else.
22:04:00Tornewincent: just move it to rocks/viewers and update viewers.config to point there
22:04:09Tornethe plugin menus are just the file hierarchy under 'rocks'
22:05:11JdGordon|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:47domonokywincent: edit CATEGORIES and viewers.config
22:05:49bertriksounds like a nice GSOC project to implement something with UBI :P
22:06:06wincentJdGordon|: Did so, but the point with file hierarchy was the one I missed.
22:06:13wincentTorne: Thanks!
22:06:29amiconnTorne: That's why I said UBI is interesting as a starting point
22:06:31Tornewincent: if you're building then changing CATEGORIES is enough, that's what determines where the build puts everything
22:06:44Torneyou only need to actually move the file around if you're working with bianries ;)
22:07:02Torneamiconn: there are probably other people at least *considering* doing a regular block device ftl for ubi
22:07:29amiconnI was thinking on the line of taking ubi code to implement an entire ftl
22:07:32wincentTorne: Also, one needs to remove the old .rock if a new one was installed with make install.
22:07:53Tornewincent: well yes, new builds aren't going to remove files from old builds
22:07:56amiconnWe can't use ubi as-is anyway, as it's made for linux, and rockbox is quite different
22:08:10Zagorfinally, a proper post-commit triggered build round
22:08:18Tornebertrik: depends how google feel about patents there thoguh L:)
22:08:47Torneamiconn: yah, but it would be better to have someone from linux mtd implement the ftl and then we rip it off, tbh :)
22:09:00Tornewell, potentially better
22:09:09Torneas they are more likely to know the optimal way to do it :)
22:09:42 Join Hillshum [0] (n=chatzill@unaffiliated/hillshum)
22:10:24bertrikwell, the linux mtd people probably also have a "Mr. Someone" to do stuff like that
22:10:33Tornethis is also true.
22:11:01Tornei am completely serious when i say that basically anything we or they come up with probably infringes a bunch of patents though
22:11:17Tornethe 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:30bertrikso you're saying that UBI may already infringe?
22:12:31mtquestion : 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:32CIA-71New commit by 03zagor (r21727): Clients build stats page.
22:12:36*shotofadds is glad to see gevaerts heeded the warnings ;)
22:12:46Tornebertrik: it's very likely
22:12:55Tornebertrik: anyone involved in developing it will have Carefully Never Looked
22:13:04Tornesince many countries penalise *knowing* infringement more
22:13:12AlexPOf course, it also depends where you are in the world
22:13:17Torneoh of course.
22:13:42 Quit martian67_ (Read error: 60 (Operation timed out))
22:13:45mtHere's the diff to clarify what I'm talking about : http://www.pastie.org/539138
22:13:52JdGordon|doesnt ignorance mean nothing with patents anyway?
22:14:14TorneJdGordon|: ignorance doesn't mean you are innocent, but in some places knowing infringement is automatic triple damages or similar
22:14:26shotofaddsgevaerts: pictureflow is nifty on the touchscreen, don't you think?
22:15:02saratogalabwe're already infringing on hundreds if not thousands of patents in the codecs, I'm not sure a few more matter
22:15:18Torneyah. i'm not saying it's any more of a problem than code we already have
22:15:21gevaertsshotofadds: I'll have to try that
22:15:26JdGordon|but... doesnt not searching mean that you assume there is one already anyway? so your up shit creek anyway? :)
22:15:32mthmm .. the diff went a little bad in shape when copying from the terminal.
22:15:51JdGordon|or.. being able t do it without searching means that it was obvious so the patent shuold be invalid :)
22:15:55TorneJdGordon|: maybe you were just too busy L)
22:18:50linuxstbmt: 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:51mtHere's a nicer diff : http://www.pastie.org/539150
22:19:18mtlinuxstb: Actually, I'm removing an outer-loop.
22:19:29linuxstbmt: Yes, I just figured that out ;)
22:19:33mt:)
22:19:45Tornetiny 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:59Torne(er, the system *settings* menu icon is usually a cog)
22:20:23linuxstbmt: I don't think it's worth committing separately
22:20:29Tornei posted a oneliner patch for this on FS #9727 but amazingly nobody has cared to comment :)
22:22:16JdGordon|Torne: that is entirely arbitrary...
22:22:24JdGordon|I saw your patch and couldnt be bothered chaning it :p
22:22:40Torneit is arbitrary, yah, but it looks weird on most themes other than cabbie
22:22:50Tornewhich tend to implement Icon_Questionmark as a question mark :)
22:22:58JdGordon|silly them!
22:23:02JdGordon|what does cabbie show?
22:23:02Tornewhich means my main menu has a big question mark on it
22:23:05linuxstbTorne: That sounds more like a bug in cabbie...
22:23:05Tornea lightbulb
22:23:27CIA-71New commit by 03mt (r21728): Add the ability to seek to the start of the track.
22:23:28linuxstbquestonmark != lightbulb...
22:23:38linuxstbOr am I missing something? ;)
22:23:42Tornebut srsly, i can't see why "System" and "System Settings" should have totally different icons
22:23:59bertrikmy clip shows a question mark, my e200 shows a light bulb
22:24:02Tornelinuxstb: you migth well consider it a bug in cabbie *as well*
22:24:13linuxstbTorne: Yes
22:24:38Grahackmcuelenaere: 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:55Tornebut i don't use cabbie, so hey. it just looks weird on every other theme i've tried :)
22:25:20JdGordon|so the actual fix here is to implement customizable icon placement!
22:25:30Tornehaha
22:26:22JdGordon|serisouly... it could be easily done
22:26:35JdGordon|every menu has a uniuqe identifier of sorts...
22:26:51linuxstbTorne: Have you noticed where else Icon_Questionmark is used?
22:26:59Tornelinuxstb: very very few places
22:27:02Tornethe "rate song" menu
22:27:02*linuxstb hands himself grep
22:27:27CIA-71New commit by 03pixelma (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:37Tornethe title for option screens
22:28:04Torneand it's used if something tries to ask for an icon that's out of range, also
22:29:40TorneJdGordon|: 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:41Torneso i'd judge our selection of builtin icon constants is not too bad and themers seem to manage ok :)
22:31:11wincentpetur,domonoky: I just updated the wiki page and the patch for pdbox: http://www.rockbox.org/tracker/task/10416
22:31:24wincentFeel free to review.
22:31:27peturwincent: already saw it ;)
22:31:35peturnice work
22:31:37Grahackmcuelenaere: 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:50pixelmafrom 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:54mcuelenaereGrahack: corrected
22:44:40mcuelenaereGrahack: what's your real name? (so I can mention it in the commit message)
22:45:49linuxstbpixelma: Clix? /me looks...
22:46:26pixelmacopyrighted name issue?
22:46:43mcuelenaereGrahack: I suppose 'if(rb.lcd_rgbpack ~= nil) then' could be simplified to 'if rb.lcd_rgbpack then' too?
22:48:17linuxstbpixelma: I was just wondering where it came from... Was it on flyspray? (the commit message doesn't refer to it).
22:50:24bertriklinuxstb, yes, FS #8925
22:52:09 Join luke_dozen [0] (n=luke_doz@p54AB62E1.dip.t-dialin.net)
22:52:24pixelmalinuxstb: 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:55CIA-71New commit by 03pixelma (r21730): Use the correct (feature) option to only include the new clix.tex in manuals of targets with colour screens.
22:56:17Grahackmcuelenaere: Christophe Gragnic
22:56:34 Quit Hillshum (Read error: 104 (Connection reset by peer))
22:58:06Grahackmcuelenaere: `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:16Grahackgood 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:58CIA-71New commit by 03mcuelenaere (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:03pixelmaAlexP: (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:16pixelmathe 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:08AlexPpixelma: I'd add another line of whitespace between each table line like: http://rockbox.pastebin.ca/1488847
23:09:15AlexPbut yes, I agree
23:09:27pixelmajust need to settle on one style (also one for the "directional key" mess
23:09:32AlexPCurrent button tables are often a nightmare
23:09:44pixelmaor settle for?
23:10:25AlexPDepends on context, here I would say settle on :)
23:11:08pixelmaAlexP: yes, could live with that too, most important to me was to easily see the start of new columns and rows
23:11:52AlexPYes, I agree
23:14:25pixelmathere 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 ("Lmnar")
23:15:41AlexPYeah, but as a general guide it can only be a good thing
23:16:07pixelmathe 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:26pixelmanested, I mean
23:16:39 Quit blackdeagle (Remote closed the connection)
23:17:27AlexPpixelma: 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:03AlexPSomeone adding a remote wouldn't have to add \opt{whatever}{&} to every single sodding table :)
23:19:09pixelmahrrmm.. should have done that then. Although - since it's only one pad currently, that could be a search and replace thing
23:20:13pixelmabut 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:56AlexPpixelma: yep
23:21:13wincentHello 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:36pixelmaAlexP: 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:11AlexPI think that depends on bit on the player unfortunately
23:22:40AlexPThose with a clear up/down/left/right (e.g. H100, beast, ...) could just say directional keys
23:23:01AlexPOthers such as c200 where they are also used for other things are a little more tricky
23:23:50AlexPI think directional keys when it is clear, and specify the keys when it is less so
23:24:10pixelma*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:21AlexPyeah
23:24:52AlexPBut for those where it is clear I think directional keys is my preference
23:26:24pixelmahard 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:40saratogawincent: you could probably disable that warning in the pd make file, but fixing it would be the best option if its possible
23:27:25pixelmaand give it a little time for people who have objections to speak up, if there aren't any - start changing the tables
23:27:32AlexPyep
23:27:46AlexPI won't be until next week, out tomorrow and away this weekend
23:28:23wincentsaratogalab: 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:26pixelmaAlexP: 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:48wincentsaratogalab: 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:04amiconnZagor? ^^
23:32:23rasheramiconn: the bogomips offset? You mean the +1?
23:32:27Zagoroffset?
23:32:29rasherWhat would the point be?
23:32:37amiconnyes
23:32:40rasherIt's not like bogomips means anything useful anyway
23:32:42amiconnJust cosmetic...
23:32:51linuxstbwincent: 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:48Zagorthe bogomips value is very unimportant. it is just a coarse sorting tool for the server.
23:34:26wincentlinuxstb: It's not me :-) As I said, it is the original code.
23:35:18wincentlinuxstb: And about floats... Well, only sound-data is fixed-point in PDBox; control-data is not.
23:36:41saratogawincent: is that function used for reading in fp data?
23:37:05 Quit stephen_ ("Leaving")
23:37:14wincentsaratogalab: Yes, and for writing it out too.
23:37:43saratogado you anticipate needing to read in fp data ?
23:38:02saratogarequiring integer input would seem to be more efficient, unelss this is for compatibility
23:38:05linuxstb"fp" = floating point or fixed point?
23:38:34flybackI love you guys
23:39:04flybackI 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:15flybackbut I do plan to get one since I don't like using my palm t5 to do music
23:39:34flybackbut it looks like the $8 mp3 player I bought like 3-4 yrs ago will have support in the future also :P
23:39:37flybacksamsung soc
23:39:51 Join safetydan [0] (n=deverton@rockbox/developer/safetydan)
23:41:08saratogaflyback: i don't think theres any ports to really old mp3 players in progress using a samsung SOC
23:41:34flybackwell I saw some info on the page and there is support for some of the newer samsung soc's
23:41:42flybackit's not a big deal it's half dead anyways, missing case and lcd
23:41:48flybackjust kinda neat that people actually try
23:41:57flybackI will just end up buying a cheap mp3 or refurb mp3 that is supported
23:42:08saratogaflyback: ports are to MP3 players, not SOCs
23:42:17flybackuh I know that
23:42:22flybackbut you have to support the SOC also :P
23:42:25saratogalinuxstb: yes its float if I am grepping correctly
23:42:44 Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37)
23:45:46wincentsaratogalab: 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:04wincentlinuxstb: 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:34saratogawincent: with all that floating point how is performance?
23:48:07calacoSanDisk Sansa e280 rockboxable. yes/no??
23:48:19flybacksaratoga, I understand completely that soc support !=rockbox/device support
23:48:21saratogacalaco: check front page
23:48:22bertrikgevaerts, has it ever been tried to replace the RAR in the meizu upgrade image with another RAR (containing rockbox code for example)?
23:48:26flybackall I saying is you have to start with soc support
23:48:27AlexPcalaco: v1, yes
23:48:35gevaertsbertrik: pronably not
23:48:35flybackif you don't have that there's 0 chance they will move to device support
23:48:38domonokycalaco: yes, but only v1 are "stable" v2 is in development.
23:48:41wincentsaratogalab: Well, a lone sine oscillator is working.
23:48:55calacok thx
23:49:01linuxstbwincent: 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:03saratogawincent: but if this is to be useful it has to run much more then that in real time right?
23:49:26pixelmahmm... 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:40wincentsaratogalab: If not, I'll have to do a CPU boost.
23:49:40 Quit calaco (Client Quit)
23:51:07wincentlinuxstb: 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:10domonokypixelma: 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:34linuxstbdomonoky: Read a manual?
23:51:44pixelmalook how the tabs, buttons etc. are called to give support
23:52:20 Quit flydutch ("/* empty */")
23:52:31domonokylinuxstb: you cant read it in rbutil, it only provides the link and a download button... :-)
23:52:35pixelmaand for that I wanted to know how they are called in English and had to switch languages ;)
23:52:54gevaertsdomonoky: download a manual?
23:52:56linuxstbdomonoky: Then "Download a manual?"
23:53:04domonokyyou can also point it to some random directory, it wont care :-)
23:53:21domonokyit just has to exist and be writeable.
23:53:26gevaertsdomonoky: "checks the important settings"? ;)
23:53:29wincentsaratogalab: Of course, the (fixed-point) DSP itself is much less complicated than control processing, which resorts to floating-point.
23:53:37AlexPSo if the check doesn't actually matter, why force chosing a meaningless directory?
23:53:46pixelmaI, as an illiterate for those things would never have though of that
23:53:54AlexPme neither
23:53:59domonokyto force the stupid people todo it :-)
23:54:11domonokybut thats a thing for improvement...
23:54:28AlexPTrouble 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:33linuxstbMaybe split "settings" and "player configuration" ?
23:54:53pixelmacould imagine that very well
23:55:02 Nick J-23 is now known as J-23|away (n=zelazko@unix.net.pl)
23:55:08domonokyAlexP: we want them to connect the dap. nearly all functions need it.
23:55:17AlexPbut not all
23:55:48AlexPThis 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:57domonoky"we" also know how to trick rbutil :-)
23:57:12pixelmaonly now
23:57:13AlexPapparently not though, as neither pixelma nor I did :)
23:57:14 Quit balug_ ("Ex-Chat")
23:57:36domonokybut autodetection and presentation of current device is a long standing issue i want to improve..
23:58:07pixelmaalso "mount point not found" (or the like) doesn't tell me much
23:58:31domonokypixelma: feel free to improve the user texts in rbutil :-)

Previous day | Next day