00:00:44 | CIA-61 | New commit by jdgordon (r22364): remove the rockbox info line saying the AA size and replace it with skin RAM usage |
00:01:18 | pixelma | I don't know how to use bloat-o-meter, don't know if I still need to set something up to make it work here, don't know what output I'll get and how to deal with it |
00:01:58 | JdGordon | haha damn... the front page has "1 more file" instead of showing the actual .c file with the relevant changes :p |
00:03:03 | moos | http://svn.rockbox.org/viewvc.cgi?view=rev;revision=22364 |
00:03:45 | kugel | pixelma: "./bload-o-meter rockbox-old.elf rockbox-new.elf" |
00:04:09 | pixelma | can you really just delete the complete line? |
00:05:03 | pixelma | kugel: even if I don't know if it would work at all, I doubt your line would, it's spelled bloat I think |
00:05:20 | kugel | right |
00:05:22 | kugel | sorry |
00:06:09 | pixelma | that still doesn't tell me where to execute this from and what type of script support I need |
00:06:16 | kugel | rockbox.elf is created after compiling (after stripping it's rockbox.bin, after scramble it's rockbox.<target>) |
00:06:33 | kugel | both tools are in utils/analysis, as I said |
00:07:22 | kugel | moos: I think you referred to the wrong rev in r22362 |
00:08:20 | * | pixelma is confused - where does it know which target I want to use it for? |
00:08:26 | moos | kugel: http://www.rockbox.org/irc/log-20090816#23:33:19 |
00:08:33 | pixelma | s/where/how |
00:09:06 | kugel | pixelma: it doesn't know it, it just compares both files, telling you which symbols changed (a symbol is a function or a global variable, for example) |
00:09:13 | kugel | <kugel> pixelma: it doesn't know it, it just compares both files, telling you which symbols changed (a symbol is a function or a global variable, for example) |
00:09:19 | kugel | oops, damn xchat! |
00:10:34 | kugel | pixelma: compile rockbox with the rev before JdGordon's commit and with the rev after, each time copy the created rockbox.elf into utils/analysis (make sure you rename them, else the 2nd copy will override the first one), then run bload-o-meter passing both files as parameter |
00:10:52 | JdGordon | hehe same typo :) |
00:10:55 | pixelma | ok, reading helps a bit... what type of script is this? I'm asking to find out if I need to install some more components |
00:10:56 | kugel | bloat! |
00:10:59 | JdGordon | have you swapped the t and d keys? |
00:11:24 | kugel | uhm...yea :P |
00:11:32 | | Quit bertrik ("De groeten") |
00:11:41 | kugel | but I'm not looking at the keys anyway |
00:12:25 | kugel | pixelma: both are written in python, that's all you need (think the toolchain too, for *-elf-objdump) |
00:14:29 | pixelma | yes, got that |
00:15:15 | pixelma | (I mean that it's installed) |
00:16:18 | bluebrother | ok, played around with ccache a bit. Changing the output folder name breaks it, creating the output folder with the same name as used in the first build produces cache hits. |
00:16:32 | | Quit petur (Remote closed the connection) |
00:16:57 | bluebrother | so I'd say using build-<targetname> instead of build-<pid> should make it work as expected. The current state unfortunately breaks ccache. |
00:17:14 | * | JdGordon wonders if thats enough to drive someone to start our own ccache that actually works :) |
00:17:40 | bluebrother | well, ccache itself works. I assume it takes the output folder into account when caching. |
00:17:47 | kugel | JdGordon: going for customlist now |
00:17:53 | JdGordon | uh oh! |
00:18:07 | kugel | bluebrother: yea, we found that our yesterday |
00:19:17 | pixelma | many changes in the same area and the blame game begins tomorrow if somehting is broken... |
00:19:25 | | Quit evilnick_home (Read error: 113 (No route to host)) |
00:19:40 | kugel | :? |
00:19:57 | kugel | I touch a totally different area if you mean that |
00:20:16 | CIA-61 | New commit by kugel (r22365): User definable UI viewport, to be able to restrict the UI into a viewport for all bitmap displays. ... |
00:20:17 | | Quit bluebrother ("sleep") |
00:20:36 | JdGordon | someone didnt fix the manual! :) |
00:20:53 | kugel | grml, I forgot to added that themes need "ui viewport: " to restore from a theme using one properly :/ |
00:21:12 | kugel | add* |
00:21:58 | JdGordon | skinned statusbar shouldnt be too far off now |
00:23:03 | kugel | w.r.t. to the manual, I was wondering were to add it. It doesn't have a settings entry (available via .cfg only) |
00:23:22 | JdGordon | I thought we were against those settings! |
00:23:27 | JdGordon | :) |
00:23:48 | | Join evilnick_home [0] (n=evilnick@pool-173-52-149-141.nycmny.east.verizon.net) |
00:23:51 | kugel | 12.1 seems good |
00:23:58 | kugel | "12.1. Customising the User Interface" :) |
00:24:28 | pixelma | it's not 12.1 everywhere |
00:24:46 | kugel | JdGordon: I actually had a setting for it, basically unusable |
00:25:02 | pixelma | e.g. in manuals for targets that don't have a radio or recording - the numbers are generated |
00:25:18 | | Quit bmbl ("Bye!") |
00:27:49 | | Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) |
00:28:04 | gevaerts | kugel: looks like r22365 is what you need on the fuze to work around this top-line-not-visible thing |
00:28:28 | CIA-61 | New commit by kugel (r22366): Fix ret for buttonbar targets. |
00:28:30 | | Quit thegeek (Read error: 131 (Connection reset by peer)) |
00:28:52 | * | JdGordon slaps kugel around |
00:28:57 | JdGordon | there goes my lovely greens |
00:29:31 | kugel | gevaerts: yea, that made me pushing it in! :P |
00:29:42 | pixelma | kugel: did you add something about the playlist viewer shortcut to the manual yet? |
00:29:55 | kugel | no, but I haven't forgotten |
00:30:37 | kugel | I don't have tex stuff on my laptop (and I really don't want to install it here), and my desktop was unfunctional until a week or so |
00:30:44 | kugel | +ago |
00:40:43 | | Quit pamaury ("exit(*(int *)0 / 0);") |
00:42:05 | | Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) |
00:42:38 | moos | JdGordon: What is the *skin* RAM usage please? Does it count for all the theme or for the WPS only... |
00:42:43 | | Quit domonoky (Read error: 54 (Connection reset by peer)) |
00:43:07 | JdGordon | skin is the new name for the wps stuff... |
00:43:13 | JdGordon | for now its the rwps and wps |
00:43:47 | pixelma | _buffer_start +2688 causes the biggest plus, a lot is reduced again by _wps_datas again but not all (then there are some minor + and - but negligable compared to those two) |
00:44:22 | pixelma | this is with my baklight modded OndioFM build |
00:45:20 | moos | JdGordon: Thanks, I'm trying to update the french translation since I'm around |
00:47:10 | pixelma | what does that tell? |
00:47:42 | JdGordon | that you're SOL... |
00:48:00 | pixelma | huh? |
00:48:37 | JdGordon | nothing you can do about it... unless oyu manually shrink buffer_start (which is easy) |
00:48:51 | JdGordon | unless we allow that buffer to be user sizeable |
00:49:01 | pixelma | where does it come from? |
00:49:29 | JdGordon | skin_engine/skin_buffer.c at the very top |
00:49:39 | | Join mcuelenaere_ [0] (n=mcuelena@78-21-191-122.access.telenet.be) |
00:49:44 | | Quit mcuelenaere (Read error: 104 (Connection reset by peer)) |
00:49:47 | JdGordon | actually.. can you paste the bloatodiff? |
00:49:48 | pixelma | I also mean why is it different to before? |
00:49:56 | JdGordon | it shounldt be |
00:50:17 | kugel | sounds a bit strange indeed |
00:50:29 | | Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") |
00:50:36 | | Quit ender` (" The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a p") |
00:51:30 | | Nick mcuelenaere_ is now known as mcuelenaere (n=mcuelena@rockbox/developer/mcuelenaere) |
00:51:45 | pixelma | http://rockbox.pastebin.ca/1531928 |
00:52:22 | kugel | skin_redraw is huge function :o |
00:52:49 | JdGordon | 300 lines |
00:52:52 | | Quit robin0800 (Remote closed the connection) |
00:53:30 | JdGordon | crappy pastebin.... still connecting |
00:54:32 | pixelma | I could also paste it to somewhere else if you have a preference and a link |
00:54:58 | JdGordon | yeah, please |
00:55:10 | JdGordon | ah neva mind |
00:55:13 | JdGordon | just worked |
00:56:27 | kugel | JdGordon: it's probably because wps_data has new members now due to the (many skin_token_list), and maybe alignement, while the buffer is still the same |
00:56:31 | kugel | pixelma: ^ |
00:57:27 | JdGordon | i dont see how that makes sense... |
00:57:31 | kugel | hm, on the other hand, they're all just pointer |
00:57:47 | JdGordon | I do want to do something about those though... not sure what |
00:57:54 | kugel | no, that can't be right |
00:58:19 | kugel | JdGordon: the problem is that it's difficult to see a diff because you didn't do the rename seperately |
00:58:23 | | Join CeruleanC [0] (n=Cerulean@unaffiliated/ceruleanc) |
00:59:50 | kugel | pixelma: what target is that? |
01:00 |
01:00:19 | pixelma | as I said, backlight modded OndioFM |
01:01:15 | pixelma | but you can see the same effect in the build table for "stock" OndioFMs |
01:03:15 | | Join BdN3504 [0] (n=4e3435ff@gateway/web/cgi-irc/labb.contactor.se/x-wbilguccyhsjkcaz) |
01:05:00 | BdN3504 | kugel: could you post the cfg file to your example in the thread on the forums? i am not getting any schlau out of "ui viewport: X, Y, [width], [height], [font], [foreground pattern], [background pattern]" esp. the last three params |
01:05:16 | CIA-61 | New commit by moos (r22367): Update the french translation. ... |
01:05:17 | BdN3504 | do we now have a custom font in the menu? |
01:05:37 | kugel | BdN3504: it's just like wps viewport, just with the comma as seperator (and without the | at the very end) |
01:05:44 | pixelma | no |
01:07:59 | BdN3504 | kugel: ok so font is either user defined "1" or system "0" what do the patterns stand for? are they colours in hex code? |
01:08:01 | kugel | exactly (if you're on a colour display) |
01:08:32 | BdN3504 | ok, why do you call them patterns then? shall i write a manual entry for this? |
01:10:08 | kugel | pixelma: I can't explain it, wps_datas should be more than 2,7k smaller |
01:10:53 | kugel | you may do that! |
01:11:37 | BdN3504 | ok. bebacktomorrow. |
01:13:53 | BdN3504 | wait, one last thing. have i understood correctly that this feature only works in the main menu as of now (i.e. not the submenus or the context menus) or does only not work with plugins which show the bg.bmp? |
01:14:24 | pixelma | kugel: might be helpful to find out why it's not, maybe there's a flaw somewhere |
01:14:47 | kugel | definitely, maybe someone else knows more |
01:15:48 | *** | Saving seen data "./dancer.seen" |
01:17:59 | | Quit BdN3504 ("CGI:IRC (EOF)") |
01:18:39 | kugel | JdGordon: are you going to break the other limits also? |
01:19:02 | kugel | viewports, and stuff. |
01:21:58 | | Join sinthetek [0] (n=sinthete@cpe-075-183-051-184.triad.res.rr.com) |
01:24:23 | sinthetek | hey, is there some sort of big compelling technical reason why rockbox doesn't support sony walkman daps (ie hardware drm mechanisms, etc) or is it simply a matter of finding someone who has one and is willing/able to port it? |
01:27:20 | | Join HBK [0] (n=hbk@rrcs-97-77-53-84.sw.biz.rr.com) |
01:27:28 | CIA-61 | New commit by kugel (r22368): Remove obsolete IMG_BUFSIZE #define. |
01:28:04 | JdGordon | kugel: remove... not break |
01:28:08 | JdGordon | and yes.. all of them hoperfully |
01:28:12 | JdGordon | viewporets is next i tinhk |
01:29:29 | kugel | I'd really like to know why wps_datas only shrinked by 1.7k |
01:30:57 | JdGordon | it makes sense... |
01:31:19 | JdGordon | umm.. maybe not |
01:32:48 | kugel | it doesn't, the skin buffer is ~2.7k (and so was the old image buffer) |
01:33:03 | kugel | (on the ondio) |
01:33:49 | JdGordon | the other chunky structs |
01:34:00 | JdGordon | its still nearly 10K which suck |
01:34:00 | JdGordon | s |
01:35:21 | | Quit HBK (Read error: 104 (Connection reset by peer)) |
01:35:38 | kugel | what's about the other structs? |
01:37:30 | JdGordon | thats where it dropped |
01:37:41 | kugel | it doesn't change the fact that removing img_buf[] alone should've free'd 2.7k |
01:39:14 | kugel | good thing the commit wasn't with buffer_alloc already, that revealed a massive ram waste |
01:40:18 | kugel | JdGordon: "that's where it dropped"? |
01:40:34 | | Quit Thundercloud (Remote closed the connection) |
01:41:37 | | Join HBK [0] (i=hbk@rrcs-97-77-53-84.sw.biz.rr.com) |
01:42:38 | | Quit GeekShadow (Read error: 104 (Connection reset by peer)) |
01:46:22 | kugel | pixelma: ah I found it |
01:47:54 | pixelma | kugel: yes? |
01:48:01 | | Join ehntoo [0] (n=ehntoo@adsl-99-156-192-57.dsl.applwi.sbcglobal.net) |
01:48:03 | kugel | a wps_token struct is quite a bit bigger now, and there's an array of 1024 of them in wps_data |
01:48:53 | JdGordon | +4 bytes isnt *quite*! |
01:49:12 | JdGordon | mind yo.. that is 4k though |
01:49:13 | gevaerts | JdGordon: if there's an array of 1024 of this, it is |
01:49:23 | kugel | JdGordon: it was only 8 before, that's a 50% increase |
01:49:55 | JdGordon | oh wait.. no shouldnt it only be 2 bytes bigger? |
01:50:02 | | Join hd [0] (n=jd@modemcable178.248-201-24.mc.videotron.ca) |
01:50:06 | | Quit hd (Read error: 104 (Connection reset by peer)) |
01:50:08 | pixelma | also - reading the forums a bit, is your list viewport seperated from the statusbar? So is the statusbar still on top of the screen or inside you ui viewport area? |
01:50:18 | | Quit HellDragon (Read error: 54 (Connection reset by peer)) |
01:50:23 | pixelma | kugel: ^ |
01:50:33 | | Join HellDragon [0] (i=jd@modemcable178.248-201-24.mc.videotron.ca) |
01:50:44 | JdGordon | its probably being bloated for alignment... |
01:50:58 | | Join thegeek_ [0] (n=nnscript@s243b.studby.ntnu.no) |
01:51:00 | JdGordon | it used to be 4, its now 6 but probably 8 |
01:51:11 | kugel | JdGordon: 7bytes +1byte alignment before, 9+3 bytes alignmenet now IIUC |
01:51:29 | JdGordon | how does it get to 9? |
01:51:33 | JdGordon | 1+1+4? |
01:51:39 | kugel | a bool is 4 byte IIUC |
01:51:47 | JdGordon | WTF? |
01:51:51 | JdGordon | isnt it a char? |
01:53:25 | kugel | I'm not entirely sure, and it may be platform specific, but I think it's 4 |
01:54:15 | JdGordon | I would be very surprised if it is |
01:54:17 | kugel | pixelma: if you use the ui viewport, you need to make sure yourself that it doesn't bite with the statusbar |
01:55:02 | pixelma | so statusbar is still at the same place not inside that viewport, that's what I wanted to know |
01:56:08 | kugel | no, the statusbar is seperate |
01:56:16 | kugel | as is the buttonbar |
01:56:43 | JdGordon | I thought the buttonbar was going to be forced inside the uservp? |
01:56:57 | kugel | why should it? |
01:57:33 | kugel | it needs to be aligned with the buttons below, doesn't it? |
01:58:44 | JdGordon | yes, but the argument was its easiesr and noone actually uses the bb |
01:58:51 | JdGordon | but ok, if oyu got it working... |
01:59:00 | kugel | pixelma: that ram will be free'd if/when the 1024'ish array is "converted" to use the skin_buffer |
02:00 |
02:00:12 | kugel | JdGordon: the easiest is to let the user take care of positioning so that the button bar is visible |
02:00:51 | | Quit daurn (Read error: 113 (No route to host)) |
02:01:10 | | Quit Rondom (Nick collision from services.) |
02:01:21 | | Join Rondom [0] (n=Rondom@dslb-084-057-145-095.pools.arcor-ip.net) |
02:01:28 | kugel | rasher: ping |
02:01:38 | rasher | kugel: yes? |
02:01:55 | kugel | I need admini access to the theme site if I want to update themes? |
02:02:43 | kugel | admin access too |
02:03:12 | rasher | Pretty much :\ |
02:03:20 | kugel | update as in delete and re-upload, I guess |
02:03:28 | rasher | It's not very ideal |
02:03:57 | | Quit Lss__ (Read error: 104 (Connection reset by peer)) |
02:04:56 | pixelma | kugel: I see, thanks for looking into this |
02:05:19 | kugel | no problem |
02:06:07 | kugel | it would've been more obvious if JdGordon svn mv'd beforehand (I can't stress this enough! :) ) |
02:06:56 | * | kugel wonders if kkurbjun checked that the shortname really matches checkwps usage before adding the mr500 |
02:13:17 | | Join froggyman [0] (n=chatzill@pool-72-69-82-35.chi01.dsl-w.verizon.net) |
02:15:05 | CIA-61 | New commit by kugel (r22369): Add the ui viewport to the theme settings, so that it will be in the theme.cfg created by "Save Theme Settings". |
02:25:00 | JdGordon | anyone feel like quickly testing another ram saving patch? |
02:26:16 | kugel | Do you mean another malloc patch? yea sure :p |
02:26:52 | JdGordon | moving viewports into the new buffer |
02:27:50 | JdGordon | http://pastebin.com/m6cfbe654 |
02:28:31 | | Join Strife89 [0] (n=michael@adsl-220-96-32.mcn.bellsouth.net) |
02:28:50 | CIA-61 | New commit by kugel (r22370): Change the default value for the ui viewport to "-" (which will give a fullscreen vp since parsing fails). |
02:32:58 | | Quit ehntoo (Read error: 60 (Operation timed out)) |
02:33:39 | kugel | JdGordon: doesn't work. freezes upon entering the wps |
02:33:51 | JdGordon | which target/wps? |
02:33:51 | kugel | buttonlight doesn't turn off, so I guess it's a real freeze |
02:33:55 | JdGordon | theme i mean |
02:33:55 | kugel | fuze/cabbiev2 |
02:34:08 | JdGordon | does it use viewports? |
02:34:14 | kugel | it has a conditional one, ye |
02:34:37 | JdGordon | ok |
02:35:07 | kugel | no normal one. the conditional is whether album art is shown or not |
02:35:55 | kugel | JdGordon: another themes which has dozens of normal viewports seems to work fine |
02:35:58 | JdGordon | so only the default viewpoerr? |
02:36:31 | kugel | I guess so |
02:37:31 | sinthetek | does anyone know why sony walkman mp3 players are not at all supported? |
02:37:32 | JdGordon | ok ta.. time to make dinner, this wont be commited tonight |
02:37:46 | JdGordon | sinthetek: noone has done anything to try to make it work |
02:38:39 | sinthetek | oki, just wondering if anyone had looked into it or if there was a solid reason why not |
02:53:53 | kugel | rasher: the author has to verify the theme? :( |
02:54:15 | rasher | kugel: Yes? |
02:54:19 | kugel | or his email rather? |
02:54:31 | kugel | grml, I kept the other guy as author |
02:55:18 | kugel | updating the screenshots at least without needing to do the whole delete 'n' re-upload thing would also be nice |
03:00 |
03:02:45 | | Quit froggyman (Remote closed the connection) |
03:11:48 | | Join dmb [0] (n=Dmb@unaffiliated/dmb) |
03:12:59 | kkurbjun | kugel, I assumed that it matched the modelname from the configure script |
03:15:51 | *** | Saving seen data "./dancer.seen" |
03:18:34 | | Quit mcuelenaere () |
03:21:12 | | Join aaron424 [0] (n=chatzill@adsl-065-013-002-216.sip.asm.bellsouth.net) |
03:22:31 | | Quit SUSaiyan` (Read error: 104 (Connection reset by peer)) |
03:22:53 | | Join SUSaiyan [0] (n=SUSaiyan@cc84863-b.zwoll1.ov.home.nl) |
03:23:34 | | Join SUSaiyan` [0] (n=SUSaiyan@cc84863-b.zwoll1.ov.home.nl) |
03:24:55 | | Quit SUSaiyan` (Read error: 104 (Connection reset by peer)) |
03:25:15 | | Join SUSaiyan` [0] (n=SUSaiyan@cc84863-b.zwoll1.ov.home.nl) |
03:25:43 | Unhelpful | JdGordon: it, um, would, i suppose, be possible? i had considered also multiple sizes for multi-screen WPS, one of the few beast OF bits i miss - you can go from playlist to huge AA to smaller AA and more track details, etc. |
03:26:25 | | Quit SUSaiyan (Read error: 104 (Connection reset by peer)) |
03:28:10 | Unhelpful | we'd need to add code to handle multiple covers in the buffer associated with one track, and obviously code to do something useful with that, but there's no reason we couldn't do it... you load an image for display just by doing a bufopen of an image file as TYPE_BITMAP |
03:28:15 | CIA-61 | New commit by kkurbjun (r22371): M:Robe 500: Add Rockbox logo to small image |
03:28:40 | Unhelpful | if we want to support multiple sizes, we'd need to add a way to pass a size argument. right now, it just looks at the WPS size |
03:29:43 | | Quit Strife89 (Read error: 113 (No route to host)) |
03:30:43 | Unhelpful | as far as making the buffer more malloc-y, i was thinking that perhaps a somewhat-heavy compaction mechanism could be OK if 1) it's cheap when compaction is not needed 2) compaction is rare |
03:31:46 | | Quit aaron424 ("ChatZilla 0.9.85 [Firefox 3.0.13/2009080315]") |
03:31:55 | Unhelpful | the easiest way would be to compact only when we can't otherwise find enough buffer, or when something that *must* move the buffer start happens - we could use the same method to move buffer start during playback |
03:35:20 | | Quit HBK (Read error: 104 (Connection reset by peer)) |
03:35:24 | | Join KBH [0] (n=hbk@rrcs-97-77-53-84.sw.biz.rr.com) |
03:39:34 | | Quit efyx ("Quitte") |
03:40:51 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
03:41:06 | | Quit HellDragon (Client Quit) |
03:42:37 | Unhelpful | maybe just a "i need to compact" flag that the buffer code sets. the running codec can periodically check it, continue if not set, send an event and then wait for one if set, and reload any pointers to buffer data |
03:43:16 | | Join HellDragon [0] (i=jd@modemcable178.248-201-24.mc.videotron.ca) |
03:43:56 | Unhelpful | the same mechanism could also be used for something amiconn and i threw around a while ago, moving the audio buffer end dynamically to allocate plugin buffer on-demand |
03:52:47 | JdGordon | Unhelpful: currently, images are resized on load yeah? |
03:54:28 | CIA-61 | New commit by kkurbjun (r22372): M:Robe 500: Correct UI simulator. |
03:57:26 | | Quit martian67 (Remote closed the connection) |
04:00 |
04:03:08 | | Join martian67 [0] (n=martian6@about/linux/regular/martian67) |
04:05:39 | | Quit martian67 (SendQ exceeded) |
04:07:32 | | Join martian67 [0] (n=martian6@about/linux/regular/martian67) |
04:11:15 | | Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) |
04:13:06 | | Join CaptainKwel [0] (n=jason@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) |
04:21:07 | kugel | ehh |
04:21:20 | kugel | checkwps is really horribly broken |
04:25:58 | * | kugel stops trying |
04:26:05 | kugel | a rewrite would be appropriate |
04:30:18 | | Quit dmb (Read error: 54 (Connection reset by peer)) |
04:30:44 | | Join ehntoo [0] (n=ehntoo@adsl-99-156-192-57.dsl.applwi.sbcglobal.net) |
04:38:06 | | Join Topy44 [0] (i=Topy44@f049011112.adsl.alicedsl.de) |
04:38:30 | Topy44 | hm, before i start looking for it for ages: where in the source are possible filenames for album art defined? |
04:38:46 | Topy44 | (and why doesnt it just take any file that ends on .jpg or any other compatible format?) |
04:39:34 | gevaerts | why should it do that? |
04:39:40 | | Quit alexja ("leaving") |
04:39:50 | Topy44 | because my albums often have random filenames or something like bandname.jpg |
04:39:51 | | Join elcan [0] (i=user36@massdeop.us) |
04:40:08 | Topy44 | of course i can rename them all - but it would be a lot less effort if it would do so automatically |
04:40:40 | gevaerts | what if you have more than one .jpg file? |
04:41:08 | Topy44 | either just pick one, or better yet, search for something like "front" or "cover" in the filename |
04:41:11 | Topy44 | one example: |
04:41:47 | Topy44 | i have many scene releases, in those the album art is generally called something like 00-bandname-albumname-edition-year-front.jpg |
04:42:06 | Topy44 | and i like to keep the original filenames of scene releases |
04:43:03 | Topy44 | it could also switch through different available files slideshow-style every couple seconds, but that might be overkill :) |
04:43:18 | gevaerts | I can see why you'd want it, but I also think it's a bad idea with lots of complicated edge cases |
04:43:50 | Topy44 | i think a simple search for something like "front" or "cover" would be right a lot more often then not |
04:44:20 | Topy44 | another good example, i dont know which software produces those files but i have MANY that have files formatted like this: |
04:44:21 | Topy44 | AlbumArt_{6A3E6F24-C0D9-4BA6-B870-1961B30FFE12}_Large |
04:44:50 | gevaerts | it would have to go through the entire directory list, which isn't needed now, it has to deal with deciding which to pick if there are multiple matches, and I'm not at all clear how to handle cover art in parent directories with that scheme |
04:45:29 | Topy44 | parent directories? you mean, like, parent of the directory the media files are in? why would it ever have to handle that? |
04:45:41 | kugel | Topy44: laziness is not going to get you very far here :) |
04:45:42 | gevaerts | it does handle that now, and people use it |
04:45:46 | Topy44 | kugel heh |
04:46:18 | Topy44 | hm, i cant see why i would ever have the album art in a parent dir. only case i have some times is that its in a subdir, like "album art" |
04:46:31 | gevaerts | I have most of my cover art in the parent directory |
04:47:12 | kugel | Topy44: in the parent dir is useful for multi disc albums, so you just need 1 cover for all discs |
04:47:24 | Topy44 | actually yes, that does make sense |
04:47:47 | kugel | and for <artist>.bmp/jpeg which is also supported IIRC |
04:48:09 | kugel | jpg rather I guess |
04:48:13 | * | gevaerts uses the "album" concept to model "work", and he uses composer portraits as "cover art" |
04:48:29 | Topy44 | i get the argument that you need to process the entire directory, but then again, it does that already when queueing the files, it could search for mathing album art at that point and cache it somewhere |
04:48:56 | Topy44 | gevaerts: for classical music you mean? that makes sense, yes |
04:49:03 | gevaerts | it doesn't have to do that when queueing the files. You could be using a playlist or the database |
04:49:29 | Topy44 | still, i think the search should be a bit more flexible... at least make the file names flexible, like in a config file |
04:49:39 | kugel | Topy44: the point is, we don't want to complicate our firmware if more powerful pc apps can do it more easily and faster for us |
04:49:45 | Topy44 | yeah |
04:50:11 | Topy44 | well, can you recommend a good program that instead of downloading new art can find randomly named jpegs and rename them properly? in a fairly automatic way? |
04:50:40 | Topy44 | i have an enormous music collection and it would be a lot more effort then its worth to do it manually album by album |
04:50:56 | kugel | I use mediamonkey, it can drop folder.jpg, or you can do funny things with the filenames based on the tags |
04:51:06 | * | gevaerts would probably just write a quick shell script for this |
04:51:11 | kugel | (while syncing) |
04:51:38 | Topy44 | i have 2k+ artists alone, each with sorted album subdirs |
04:52:18 | Topy44 | sorting it all when i started getting serious took me around 2 months :) |
04:52:50 | kugel | well, this is getting off-topic actually, but mediamonkey will handle that easily and automatically |
04:52:58 | Topy44 | i'll check it |
04:53:01 | Topy44 | +out |
04:53:10 | Topy44 | thanks anyway |
04:53:21 | kugel | you're welcome |
04:53:22 | Topy44 | back to the subject: where does rockbox store the filenames? |
04:53:38 | Topy44 | so i can make a custom build that supports the format at least most of my album art has |
04:54:45 | kugel | checkout albumart.c |
04:54:55 | Unhelpful | JdGordon: yes... the resizer is passed a callback to the image reader that it uses to get chunks of image data |
04:54:56 | kugel | in apps/recorder |
04:56:58 | Unhelpful | this is not ideal if you want the same image in different sizes, there is no rewinding. at *some* point i mean to reorder that part, and have the scaler's state entirely encapsulated in a struct, with the image loader calling a scaler function for each chunk of data. this could easily expand to multiple-size output by passing intiliazing more than one struct scaler_state and making more than one call per image chunk loaded. |
04:58:38 | Unhelpful | i suspect this will see a slight performance gain (no check-if-more-data-is-needed in scaler loop, just loop until the passed data chunk is finished, then return), and will make it easier to use the scaler also. |
04:59:09 | kkurbjun | kugel, JdGordon, I have a wps that segfaults the simulator with the latest changes |
04:59:27 | JdGordon | sweet... email it to me :) |
04:59:47 | Unhelpful | right now, you have to encapsulate enough of your image reader's state into a struct for the callback to be able to read in the next chunk |
05:00 |
05:00:16 | kkurbjun | JdGordon: sure, it's not exactly a complete or proper wps - it was just something that a member of the m:robe forms put together |
05:00:22 | kkurbjun | I'll send it to your gmail |
05:00:25 | JdGordon | ta |
05:00:37 | * | JdGordon is off for some L4D |
05:01:02 | | Quit JdGordon ("Leaving.") |
05:02:57 | | Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
05:03:06 | kugel | kkurbjun: which target? |
05:03:15 | kkurbjun | on the m:robe 500 |
05:03:56 | kkurbjun | the test wps I put together works fine, but this one kills the simulator |
05:04:06 | kugel | probably jdgordons bug then :p |
05:04:36 | kkurbjun | :) |
05:11:13 | | Join JdGordon [0] (i=1816d253@gateway/web/freenode/x-dncjdjnqlxpmfvph) |
05:15:53 | *** | Saving seen data "./dancer.seen" |
05:16:03 | kkurbjun | would it be appropriate to delete the dabo theme on the ipod videos? |
05:16:45 | | Quit JdGordon (Ping timeout: 180 seconds) |
05:17:36 | kkurbjun | it just has the example wps and the image that is shown I'm sure is not CC-BY-SA |
05:17:48 | kugel | not sure |
05:24:27 | | Join FOAD_ [0] (n=dok@dinah.blub.net) |
05:33:14 | | Quit kugel (Remote closed the connection) |
05:35:26 | | Quit KBH (Read error: 104 (Connection reset by peer)) |
05:35:30 | | Join HBK- [0] (n=hbk@rrcs-97-77-53-84.sw.biz.rr.com) |
05:41:30 | | Quit FOAD (Read error: 110 (Connection timed out)) |
05:41:30 | | Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) |
05:51:17 | | Quit Horscht ("Verlassend") |
05:59:54 | | Quit Topy44 () |
06:00 |
06:08:21 | | Quit ehntoo (Read error: 110 (Connection timed out)) |
06:31:47 | | Quit toffe82 ("ChatZilla 0.9.85 [Firefox 3.5.2/20090729225027]") |
06:36:05 | | Join JdGordon [0] (i=1816d253@gateway/web/freenode/x-fhjdfyypvukddwxf) |
06:40:35 | | Join martian67_ [0] (n=martian6@about/linux/regular/martian67) |
06:47:54 | | Quit martian67 (Connection timed out) |
07:00 |
07:11:54 | | Quit sharp (Read error: 104 (Connection reset by peer)) |
07:14:17 | | Quit courtc (Read error: 113 (No route to host)) |
07:15:54 | *** | Saving seen data "./dancer.seen" |
07:26:48 | | Quit CaptainKwel (Remote closed the connection) |
07:35:28 | | Quit HBK- (Read error: 104 (Connection reset by peer)) |
07:35:32 | | Join KBH [0] (n=hbk@rrcs-97-77-53-84.sw.biz.rr.com) |
07:38:10 | | Quit Trista901 (Remote closed the connection) |
07:39:35 | | Join LinusN [0] (n=linus@gateway/web/cgi-irc/labb.contactor.se/x-xeeytglifzrgoglv) |
07:39:47 | | Part LinusN |
07:39:53 | | Join LinusN [0] (n=linus@rockbox/developer/LinusN) |
07:52:43 | | Join Llorean [0] (n=DarkkOne@adsl-99-182-52-92.dsl.hstntx.sbcglobal.net) |
08:00 |
08:01:41 | | Join n1s [0] (n=n1s@rockbox/developer/n1s) |
08:07:26 | | Quit mylogic (Client Quit) |
08:11:17 | | Join Rob2223 [0] (n=Miranda@p4FDCEC65.dip.t-dialin.net) |
08:17:15 | | Join ender` [0] (i=krneki@foo.eternallybored.org) |
08:18:36 | | Quit Rob2222 (Read error: 60 (Operation timed out)) |
08:29:25 | | Join flydutch [0] (n=flydutch@host214-146-dynamic.15-87-r.retail.telecomitalia.it) |
08:41:06 | | Join JdGordon1 [0] (n=jonno@c-24-22-210-83.hsd1.wa.comcast.net) |
08:41:32 | | Join Grahack [0] (n=chri@ip-222.net-82-216-222.rev.numericable.fr) |
08:42:58 | | Quit JdGordon (Ping timeout: 180 seconds) |
08:43:14 | | Nick JdGordon1 is now known as JdGordon (n=jonno@c-24-22-210-83.hsd1.wa.comcast.net) |
08:47:38 | | Quit thegeek_ (Read error: 104 (Connection reset by peer)) |
08:47:51 | | Join thegeek_ [0] (n=nnscript@s243b.studby.ntnu.no) |
08:58:56 | * | n1s wonders how one would use this user definable viewport thingy |
09:00 |
09:02:24 | | Join petur [50] (n=petur@rockbox/developer/petur) |
09:08:09 | | Join daurn [0] (i=daurn@freenode/staff/daurnimator) |
09:10:26 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
09:15:54 | | Quit faemir ("Leaving") |
09:15:55 | *** | Saving seen data "./dancer.seen" |
09:17:00 | CIA-61 | New commit by jdgordon (r22373): fix the %xd<id> tag parser to complain if you try to display an image it hasnt loaded yet |
09:18:20 | JdGordon | n1s: its pretty pointless as it is... but the plan is to put the list *somewhere* in the screen and then have the rest of the display skinned... |
09:19:11 | | Join courtc [0] (n=court@unaffiliated/courtc) |
09:22:30 | n1s | JdGordon: so you can specify an arbitrary box and the list will draw inside that? |
09:22:39 | JdGordon | yes |
09:23:18 | n1s | aha, so if it's pointless now, what is the future plan? ;) |
09:24:44 | JdGordon | what I just said :) |
09:24:56 | JdGordon | thing the current status bar on steroids |
09:25:35 | | Join Thundercloud [0] (i=thunderc@persistence.flat.devzero.co.uk) |
09:26:06 | n1s | skinned == wps-style stuff? |
09:26:55 | JdGordon | yes |
09:27:25 | n1s | ah, i read skinned as "showing a pretty picture" :) |
09:27:35 | | Join Saline [0] (i=Saline@bzq-79-176-137-164.red.bezeqint.net) |
09:27:51 | JdGordon | I'm sure there will be themes which do that soon |
09:28:08 | JdGordon | AA + track info in the menu |
09:28:14 | n1s | anyway, a nicer statusbar will be nice |
09:30:04 | Saline | Hi all |
09:30:23 | Saline | I'm trying to add a feature to rockbox. |
09:30:58 | Saline | I want to show a clock instead of the "do no disconnect", "charging", etc screens |
09:31:11 | | Quit SUSaiyan` (Read error: 104 (Connection reset by peer)) |
09:31:19 | | Join SUSaiyan [0] (n=SUSaiyan@cc84863-b.zwoll1.ov.home.nl) |
09:31:35 | Saline | currently, i'm looking at the screens.c and usb.c |
09:32:07 | | Join pamaury [0] (n=pamaury@sal63-1-82-243-96-220.fbx.proxad.net) |
09:32:10 | Saline | the problem - i think that the "do not disconnect" screen is the default ipod screen |
09:32:35 | Saline | can you give me some pointer? (other than *, and ** ..) |
09:32:48 | JdGordon | 0x8765ff0 :) |
09:33:05 | Saline | 0xdeadbeef |
09:33:18 | Saline | thanks for the pointer.. |
09:33:21 | Saline | :) |
09:33:35 | JdGordon | http://xkcd.com/138/ |
09:33:54 | JdGordon | umm... what clock do you want to show? |
09:33:54 | Saline | nice |
09:34:03 | * | JdGordon is half asleep |
09:34:05 | Saline | lets start with an "hello world" |
09:34:13 | n1s | yeah, the "do not disconnect" screen is in apple fw |
09:34:26 | Saline | i'm thinking about using the the clock plugin, later |
09:34:42 | Saline | is there a way to bypass the apple firmware? |
09:34:46 | JdGordon | that should be doable |
09:34:56 | n1s | Saline: do you still get that screen with a current rockbox build, i thought we used our own usb now? |
09:34:57 | JdGordon | use rockbox usb and you wont get that |
09:35:01 | * | JdGordon goes to bed |
09:35:13 | Saline | ok, i'll give it a whirl, thanks! |
09:35:29 | Saline | (i'm using the stable build, via the installer, btw) |
09:35:30 | | Quit KBH (Read error: 54 (Connection reset by peer)) |
09:35:36 | Saline | good night! |
09:35:38 | | Join KBH [0] (n=hbk@rrcs-97-77-53-84.sw.biz.rr.com) |
09:38:40 | | Quit SUSaiyan (Read error: 104 (Connection reset by peer)) |
09:38:47 | | Join SUSaiyan [0] (n=SUSaiyan@cc84863-b.zwoll1.ov.home.nl) |
09:39:10 | n1s | once you use rockbox's own usb mode, usb_screen in screens.c is what is drawing the usb graphics in rockbox while connected so you probably want to modify that |
09:45:01 | Saline | thanks! |
09:45:12 | | Quit Thundercloud (Read error: 54 (Connection reset by peer)) |
09:52:21 | | Quit SUSaiyan (Read error: 104 (Connection reset by peer)) |
09:54:36 | | Join SUSaiyan [0] (n=SUSaiyan@cc84863-b.zwoll1.ov.home.nl) |
10:00 |
10:02:57 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
10:05:58 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
10:11:03 | | Join zhxk [0] (i=zhxk_@125.109.218.14) |
10:11:03 | | Quit fyrestorm ("lamers envy me like they envy bill g -- main boot xp, just the way it should be!") |
10:11:13 | | Join mt [0] (n=MTee@196.221.62.195) |
10:11:28 | | Join fyrestorm [0] (n=nnscript@cpe-68-173-235-106.nyc.res.rr.com) |
10:11:32 | zhxk | whats rockbox |
10:11:57 | | Part zhxk |
10:14:06 | | Quit CeruleanC (Remote closed the connection) |
10:18:40 | robin0800 | zhxk try http://www.rockbox.org/ |
10:26:32 | | Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) |
10:29:11 | Saline | after i build (using make), where does the binaries go? |
10:29:16 | Saline | (using cygwin) |
10:35:38 | Saline | make zip |
10:35:45 | Saline | i should rtfm mroe |
10:55:53 | robin0800 | Saline: if you followed instructions you will have created a "build directory" the files will be in there |
11:00 |
11:13:26 | | Join Topy44 [0] (i=Topy44@f048180215.adsl.alicedsl.de) |
11:15:47 | | Join bertrik [0] (n=5a809af7@91.191.140.131) |
11:16:00 | *** | Saving seen data "./dancer.seen" |
11:17:42 | bertrik | Unhelpful: regarding the ams sansa RTC: the rtc driver was re-used from the older sansas |
11:18:04 | bertrik | those older sansas used 1980/1/1 as the reference date, while the ams sansas use 1970/1/1 as reference date |
11:18:41 | | Join antil33t [0] (n=Mudkips@119.224.12.185) |
11:18:47 | bertrik | This caused the RTC to be reset by the OF (or possibly even rockbox) and I think this reset was the reason that DRM stopped working |
11:19:22 | bertrik | The RTC driver used for the ams sansa is now updated to use 1970/1/1 as the reference date, just like the OF |
11:22:29 | | Quit J-23 ("wszedłem") |
11:29:47 | | Join Isolinear [0] (n=isolinea@c-67-170-180-104.hsd1.or.comcast.net) |
11:30:23 | | Quit Isolinear (Client Quit) |
11:30:45 | | Join Rudy4Pez [0] (n=rudy4pez@c-67-170-180-104.hsd1.or.comcast.net) |
11:31:08 | Rudy4Pez | Anyone awake? |
11:31:28 | Rudy4Pez | I have a question about albumart filenames. |
11:32:35 | Rudy4Pez | Rockbox searches for certain formats such as "folder.jpg" or "cover.jpg" |
11:32:48 | Rudy4Pez | I would like to know if there's a way to add one to that list. |
11:33:25 | Rudy4Pez | Because all of my albumart files are named "album.jpg", which of course, Rockbox doesn't recognize. |
11:33:31 | | Quit Saline (Read error: 54 (Connection reset by peer)) |
11:33:47 | | Quit bertrik ("CGI:IRC (Ping timeout)") |
11:35:42 | | Quit KBH (Read error: 104 (Connection reset by peer)) |
11:35:46 | | Join HBK- [0] (n=hbk@rrcs-97-77-53-84.sw.biz.rr.com) |
11:37:00 | Topy44 | Rudy4Pez: actually i asked that exact question a couple hours ago |
11:37:30 | Topy44 | answer is: yeah, check out apps/recorder/albumart.c line 124 onwards |
11:38:22 | Topy44 | in essence, duplicate lines 199-205 and replace "cover" through "folder" or whatever |
11:38:37 | Topy44 | compile, run, have fun :) |
11:39:42 | | Join Saline [0] (i=Saline@bzq-79-178-112-142.red.bezeqint.net) |
11:41:44 | | Join BdN3504 [0] (n=4e3435ff@gateway/web/cgi-irc/labb.contactor.se/x-tjcclqrvkcespdno) |
11:43:23 | | Join J-23 [0] (n=zelazko@unix.net.pl) |
11:43:23 | markun | if it's a very common naming scheme I guess we should add it |
11:43:23 | robin0800 | Rudy4Pez: you could always do a find and replace outside of rockbox unless you need album.jpg for something else |
11:43:53 | Topy44 | it is, some (unknown to me) software produces "Folder.jpg" files, i have tons of those |
11:44:41 | Topy44 | nearly as common is front.jpg |
11:44:45 | BdN3504 | which section of the manual would you deem appropriate for the new ui viewport: Theme Settings, Advanced Topics, WPS Tags or Config file options? i'd go with Advanced Topics and the latter |
11:44:54 | robin0800 | Topy44: windows media player does that |
11:44:59 | Topy44 | aaah! |
11:45:52 | Rudy4Pez | Gah, "compile"! |
11:45:56 | Rudy4Pez | Such a dirty word! :P |
11:46:10 | Topy44 | ?? |
11:46:33 | * | Rudy4Pez was hoping for an easy-to-edit xml file or something. |
11:46:57 | robin0800 | Rudy4Pez: I gave you an alternative to compiling |
11:47:22 | Rudy4Pez | Ah, sorry. It's 3am here. I'm a bit loopy. :) |
11:49:52 | robin0800 | Rudy4Pez: think I used infranview a couple of years ago |
11:50:20 | Topy44 | hm yeah, some hexeditor-hacking might actually do the trick... %scover%s. %sfolder.jpg /.rockbox/albumart/%s-%s%s. /.rockbox/albumart/ <== shows up in my rockbox.iriver |
11:50:58 | Topy44 | (or non-destructive texteditor) |
11:51:18 | Topy44 | but keep the size the same |
11:51:49 | robin0800 | Topy44: bulk renamer can change filenames |
11:51:58 | Rudy4Pez | I'm sorry, what exactly are you renaming? |
11:52:06 | Rudy4Pez | Err.. Editing? |
11:52:06 | Rudy4Pez | lol |
11:52:11 | Rudy4Pez | Sorry.. Brain is fried. |
11:52:38 | Topy44 | i just realized you were talking about a search/replace on the music dir, not inside the binary :) my brain is fried already too, though my version MIGHT actually work aswell |
11:53:09 | Rudy4Pez | (And yes, I'd rather not rename the .jpg files.) |
11:53:23 | robin0800 | Rudy4Pez: album.jpg to cover.jpg |
11:54:03 | n1s | Rudy4Pez: then your last option is to convince a dev to make the change for you ;) |
11:54:20 | Topy44 | Rudy4Pez: just download the vmware development envoirement, edit the albumart.c file i mentioned before and compile it, its really not hard and there is a good guide in the wiki |
11:54:43 | Topy44 | its a big download, but the actual editing and compiling bit is a matter of a few lines |
11:54:45 | robin0800 | Rudy4Pez: or keep two copies album and cover |
11:55:02 | Rudy4Pez | Hmm.. |
11:55:26 | Rudy4Pez | What about an XBMC type solution.. Anyone familiar with their "advanced.xml" file? |
11:56:20 | Rudy4Pez | It's been a long time since I've played with it, but the way I remember it, there was an option to add a line.. |
11:56:24 | Topy44 | Rudy4Pez: i suggested more intelligent albumart filename handling this morning - i got some good arguments against it, some bad ones, and a lot of general disinterest :) |
11:56:47 | robin0800 | Rudy4Pez: If you do compile it please make a patch and post it to the tracker |
11:57:21 | Topy44 | robin0800: actually i will do that, though i am still making a list of what to add |
11:58:15 | robin0800 | Topy44: Not too much if you want to see it committed |
11:58:51 | Llorean | What program creates the name album.jpeg? |
11:59:00 | Llorean | Or album.jpg rather |
11:59:20 | Rudy4Pez | For example, the system recognizes many extensions as playable audio files.. .mp3, .wav, .flac... |
12:00 |
12:00:28 | Rudy4Pez | And if you want to add a new extension to the list of extensions that get recognized as music, you would add the tag <musicextensions> .new </musicextensions> to the xml file. |
12:00:47 | n1s | we *could* add a setting for user specified filenames to look for |
12:01:02 | Rudy4Pez | nls: Exactly. |
12:01:13 | Llorean | n1s: Why add that complexity? |
12:01:17 | n1s | Rudy4Pez: although you can probably forget xml files :) |
12:01:19 | Llorean | There can't be that many "common" ones. |
12:02:04 | n1s | Llorean: it wouldn't be much complication, just a setting string allowing the user to specify a name they want and add that in the search |
12:02:38 | robin0800 | perhaps just album.jpg but to aswer your question iv'e never seen this |
12:02:57 | Llorean | n1s: I asked why though. There's not really much need to support it. |
12:02:59 | Rudy4Pez | nls: Yeah they had a lot of other stuff in their to warrant setting up that xml system. http://www.xbmc.org/wiki/?title=AdvancedSettings.xml |
12:03:03 | Llorean | We're still going to have to support all the common names anyway. |
12:03:06 | n1s | but sure, if there are only very few common ones i guess the setting would be kind of pointless |
12:03:10 | Llorean | Once all the common ones are supported, why do you need a user value? |
12:03:14 | Topy44 | i dont think its needed either - what would make a lot more sense IMHO is having some intelligent code searching for the file even if it has a random filename |
12:03:19 | | Join bertrik [0] (n=5a809af7@gateway/web/cgi-irc/labb.contactor.se/x-lbumpowqzgkljnny) |
12:03:19 | Topy44 | but that adds complexity of course |
12:03:23 | n1s | Llorean: IMO there is no need for AA at all :) |
12:03:45 | Topy44 | hehe, you could argue about that alright i guess :) |
12:03:51 | Llorean | n1s: Basically, once you support all the common names, a "custom" value really only exists if a user wants to use a unique filename incompatible with any other program, which would be a bit odd right there. |
12:04:11 | Llorean | Topy44: How on Earth do you identify which jpeg in the folder belongs as album art? |
12:04:27 | Llorean | There's no such thing as an "intelligent" algorithm, and we already match things such as album and track name. |
12:04:58 | Rudy4Pez | Hmm.. I recall a program that created a ridiculously long string of random characters as the jpg filename.. |
12:05:04 | Topy44 | Llorean: first of all, if there is just one jpeg, use that, no matter what its called. second, if there are several, and one contains "cover", "front", the albumtitle, etc, anywhere in the filename, use that. and if nothing works, just use the first one. |
12:05:06 | n1s | Llorean: sure, i have no idea how these files are named usually |
12:05:10 | Rudy4Pez | I wanna say Windows Media Player but I'm not sure. |
12:05:12 | | Join einhirn [0] (n=Miranda@bsod.rz.tu-clausthal.de) |
12:05:18 | Llorean | Topy44: And what do you do if that jpeg *isn't* supposed to be album art? |
12:05:39 | Llorean | Why include a system that can get it wrong, when humans are capable of simply getting it right in the first place? |
12:05:44 | Topy44 | then you get a wrong jpeg displayed. doh. :) why would you have anything else then album art or a bandphoto in a music dir? |
12:06:04 | Llorean | You're making an assumption that users don't do silly things. |
12:06:05 | Topy44 | because i have 10k or so albums, and will not start sorting them by hand |
12:06:06 | Rudy4Pez | Topy44: That makes sense, if none of the .jpg files match the format, then just pick the first .jpg available. |
12:06:21 | Topy44 | it could all be optional of course |
12:06:26 | Llorean | Topy44: A simple mass rename will do, it's not hard. If you have a single jpeg in each folder, just mass rename or copy all to cover.jpg |
12:06:29 | Rudy4Pez | Options are good. |
12:06:30 | Topy44 | in general, what i suggest isnt much effort, but requires parsing the directory, and thats where the actual problem lies |
12:06:57 | Llorean | You're suggesting introducing a system that can introduce errors, and requires the player to do more work, because you're willing to do a simple file rename? |
12:07:12 | Topy44 | yes :) |
12:07:28 | Topy44 | well, the errors are not catastrophic - worst case you get a wrong image displayed |
12:07:48 | Llorean | And the current problem is not catastrophic either |
12:07:54 | Llorean | Worst case, you actually need to organize your files slightly. |
12:08:06 | Rudy4Pez | 10k albums is a lot of organization legwork. |
12:08:11 | Llorean | No, it's not. |
12:08:15 | Llorean | It's a single mass operation. |
12:08:26 | robin0800 | Llorean: On the AA page are programs that find album art and can rename it to cover.jpg |
12:08:35 | Llorean | If an algorithm in Rockbox can identify the right jpeg, a rename algorithm can too |
12:08:42 | Topy44 | not true actually - it simply means finding a program that does what i just said on the pc instead of putting it into rockbox |
12:08:44 | Llorean | If it *can't* then the problem can't be solved in Rockbox either. |
12:08:50 | Topy44 | yeah |
12:08:56 | Llorean | So it's not "a lot of legwork" |
12:09:22 | Llorean | robin0800: Exactly. |
12:10:01 | Llorean | I'm all for improving the hardcoded list of filenames to match those used by common PC-side applications, but once you try to develop a method to "detect" album art by guessing things you get problems like the database had trying to deduce track names from filenames. |
12:10:13 | Rudy4Pez | Well I think in this case the easiest solution is to add more formats. |
12:10:20 | Rudy4Pez | Llorean: Agreed. |
12:10:24 | Llorean | Adding formats is pretty difficult. |
12:10:24 | Topy44 | i think the clean solution if you were to integrate it into rockbox would be to find the coverart file when creating the dynamic playlist (as the directory already gets parsed at that step), or possibly when creating the database if you use it, and save it in the playlist/database |
12:10:28 | Llorean | Do you mean adding more filenames? |
12:10:32 | Rudy4Pez | Err, yes. |
12:10:33 | Rudy4Pez | Sorry. |
12:10:41 | Rudy4Pez | Fried brain, remember? :) |
12:10:53 | Llorean | Topy44: The clean solution is to have your files properly named. |
12:11:04 | Topy44 | i said "if you were to integrate it" |
12:11:07 | Llorean | If your file is properly named, Rockbox already finds it just fine. |
12:11:17 | Rudy4Pez | Haha, my files are all properly named. Rockbox just doesn't recognize that particular name.. :P |
12:11:29 | Llorean | If there were going to be some funny algorithm, it'd just take place when the current finding takes place. |
12:11:52 | Topy44 | yeah, and if all your music files have perfect tags and meaby even are all the same format and bitrate, hey, you could eliminate half of rockbox! |
12:11:57 | Llorean | Rudy4Pez: You never did mention what program names them that way, did you? |
12:12:29 | Rudy4Pez | Hmm.. No, I don't remember.. |
12:12:44 | Llorean | Topy44: Just rename your files and quit complaining. Seriously. There's not a good reason to have Rockbox try guessing things. |
12:12:55 | Llorean | "I want it to" isn't a good one, by the way. |
12:12:59 | Topy44 | really what it comes down to is the compromise between putting effort into maintaining your local collection and having rockbox do more |
12:13:01 | Rudy4Pez | I'm trying to figure out if Winamp had something to do with it.. I've been using that filename for a long time. |
12:13:13 | Topy44 | its like "retagging all local files" vs "have player guess tags" |
12:13:18 | Topy44 | its all an ancient discussion |
12:13:22 | Llorean | And we don't have the player guess tags, either. |
12:14:12 | Rudy4Pez | But yes, I think simply adding "album.jpg" as well as whatever other somewhat common filenames are out there as they pop up, is probably the simplest solition, and adds to the flexibility of Rockbox, and this is a run-on sentence. :) |
12:14:58 | Topy44 | album.jpg, front.jpg and folder.jpg will be in a patch i'll create shortly then |
12:15:08 | Llorean | What programs use those? |
12:15:27 | Topy44 | folder.jpg <== windows media player? |
12:15:40 | Llorean | folder.jpg is already supported |
12:15:41 | robin0800 | Llorean: wmp uses folder.jpg |
12:15:45 | Topy44 | front.jpg <== common manual naming scheme (about 50% of my coverart) |
12:15:52 | Topy44 | Llorean: ah, ok |
12:15:59 | Llorean | "common manual naming scheme" doesn't say what programs use it. |
12:15:59 | Topy44 | album.jpg no idea |
12:16:03 | Llorean | It's not common just because you do. |
12:16:08 | Topy44 | i dont |
12:16:32 | BdN3504 | this is settled. go get yourself The rename http://www.herve-thouzard.com/the-rename. search for files called *.jpeg. drag and drop into rename. modify prefix. end of discussion. |
12:17:02 | Topy44 | i download stuff. the files are called front.jpg, and i dont usually care as my pc music player doesnt display it anyway |
12:17:03 | CIA-61 | New commit by mt (r22374): Put ATRAC3Context in IRAM, 2.5% speedup on PP502x, 20% on ColdFire. |
12:17:21 | Llorean | Topy44: So you basically want an arbitrary filename supported. |
12:17:46 | Rudy4Pez | Just because it's arbitrary doesn't mean it's not insanely common. |
12:17:57 | Topy44 | Llorean: all i know is that its common, i coulndt care less why it is |
12:18:03 | Topy44 | couldnt |
12:18:07 | Llorean | Except you don't even have a program that uses it either. |
12:18:12 | Topy44 | no |
12:18:24 | Topy44 | because i dont use album art on my pc |
12:18:39 | BdN3504 | do as i say. here, i even have the download link for you: http://www.herve-thouzard.com/therename.zip |
12:18:47 | Llorean | BdN3504: You're missing the point of the discussion. |
12:19:12 | Llorean | Rudy4Pez: But if it were insanely common, you'd think PC software would support it too. Or that we'd have actual other people with such a thing. |
12:19:27 | Topy44 | i said "i dont know as i dont use any", not "there isnt any" |
12:19:28 | Llorean | It may be just the music store he gets his music from, or the band, or whatever. |
12:19:48 | Llorean | Topy44: I didn't say "there isn't any." I said "tell me some." |
12:20:18 | BdN3504 | Llorean: no. there is no discussion. rockbox displays albumart files if they are named http://www.rockbox.org/twiki/bin/view/Main/AlbumArt#Where_To_Put_The_Images |
12:20:19 | | Join bertrik_ [0] (n=bertrik@d90-128-154-247.cust.tele2.nl) |
12:20:48 | Llorean | BdN3504: And when we put in jpeg album art, we decided we wanted to try to make the list contain common filenames, expanding it if there were other common names used by PC apps |
12:20:53 | Llorean | Which is exactly why I'm asking these questions. |
12:21:05 | Topy44 | so because pc software might not explicitely search for that filename (most pc software will parse the dir for jpegs anyway) that is a killer argument not to use it in rockbox? |
12:21:06 | Llorean | That list is definitive of what it does - it does not limit future expansion of the list. |
12:21:23 | Llorean | Topy44: No, most pc software won't parse a folder for random jpegs. |
12:21:27 | Topy44 | also, i cannot tell you any pc software that supports it because - again - i dont use a single pc software that supports album art at all |
12:21:46 | Topy44 | (except for album art downloader of course) |
12:21:55 | Llorean | So *find* some |
12:22:01 | Llorean | You're the one claiming its common, you should be able to. |
12:22:17 | Llorean | I'm not making a huge demand. |
12:22:29 | BdN3504 | Llorean: that's seven options. if users are to lazy to pick one of them and conform it's their problem, imo |
12:22:32 | | Quit bertrik ("CGI:IRC (Ping timeout)") |
12:22:36 | Llorean | Just show that we'd be making Rockbox compatible with a documented layout of some sort. |
12:22:37 | Topy44 | i can give you proof that its common by giving you a grep on my music dir... and i have not created any of these front.jpg files myself nor do they all come from the same source |
12:22:51 | BdN3504 | doensn't it slow down the process of loading aa if we expand that list? |
12:22:53 | Llorean | BdN3504: Yes, but your opinion doesn't matter to what was decided when the feature was added. |
12:23:04 | Llorean | Topy44: That's proof of nothing at all. |
12:23:15 | Llorean | Topy44: If it's common, why are you unwilling to even try? |
12:23:24 | Llorean | Or is this another "I'm lazy and just demand it my way" situation? |
12:23:26 | BdN3504 | if it does not do that, then i think it |
12:23:33 | robin0800 | http://www.rockbox.org/twiki/bin/view/Main/AlbumArt#Where_To_Put_The_Images this needs to be updated to reflect use of jpg conversiom to bmp not needed now |
12:23:45 | Topy44 | i dont demand anything, i think thats a point you are somewhat missing :) |
12:24:03 | Llorean | robin0800: "where to put the images" doesn't say anything about conversion. |
12:24:34 | Llorean | Topy44: You're being rather insistent that a filename should be supported that has nothing speaking for its commonality except that you've downloaded a bunch of music from a source you won't even specify that has that file in it. |
12:24:38 | Topy44 | i dont demand anything, as i can fix it myself with a 2-minute patch, and if you dont want to commit it on the grounds that i cant "prove" to your satisfaction that i am not the only person using that filename then thats not really my problem :) |
12:24:56 | robin0800 | Llorean: further down the page it does |
12:25:05 | Llorean | robin0800: Ah, I just read the anchor you linked. |
12:25:35 | Llorean | Topy44: What have you got against renaming them anyway, if none of your PC software supports it? |
12:25:54 | Llorean | The idea is for Rockbox to support album art that is already being used with PC software, not "every filename someone thinks is common enough" anyway |
12:26:13 | Llorean | If the files aren't named to be compatible with something, there's no reason they can't be renamed at that point. |
12:26:15 | Rudy4Pez | I've lost count of how many times I've come across "front.jpg"... Usually accompanied by "back.jpg". |
12:26:23 | Topy44 | some sources: soulseek, rockbox (the bittorrent music tracker :), private music archives of friends - but no specific source as in software or online shop |
12:26:30 | Topy44 | correct, and cd.jpg etc |
12:27:07 | Topy44 | correct, they can be renamed - but it might save a lot of users some effort if its supported directly |
12:27:10 | Llorean | So it's not a compatibility issue, it's just a personal preference issue? |
12:27:25 | Llorean | Or rather, it's not a software compatibility issue. |
12:28:17 | Llorean | I mean you have to understand, there's going to be plenty of people with favorite naming schemes. |
12:28:56 | Torne | the names we support already are designed to accomodate people who have *already* renamed everything to match the convention of some *other* piece of software; i.e. to prevent them from having to break compatibility with the software they already use. |
12:29:27 | Topy44 | i could get all my mp3s copied to cassettes to make them compatible with my walkman - instead i bought an mp3 player - get my point? understand, this is not my personal favourite naming scheme, it is one that both i and others (rudy4pez) have seen many times, and its source seems to be pretty obvious: common sense (front as in the opposite of back) |
12:29:57 | Llorean | Except your comparison to a walkman is silly |
12:29:59 | Topy44 | i am not saying "change this because it will make it compatible to software X" |
12:30:03 | Topy44 | it is really :) |
12:30:05 | Llorean | Renaming the files doesn't reduce their quality, or usability. |
12:30:18 | Llorean | You're basically just trying to make something up to justify your statement now. |
12:30:27 | Topy44 | let me try: |
12:30:36 | Llorean | "I don't want to rename them." |
12:30:37 | | Join josh___ [0] (n=5312dd93@gateway/web/cgi-irc/labb.contactor.se/x-odgcivyrewpwihkw) |
12:30:40 | Llorean | that's basically your whole argument. |
12:30:51 | Topy44 | doh, let me at least try (and no, it is not.) |
12:30:56 | Llorean | Yeah, it is. |
12:31:09 | Llorean | You're going to give reasons why it's good that you shouldn't have to - ease of use, simplicity for users, commonness of the naming |
12:31:11 | Llorean | But in the end, that's the reason. |
12:31:45 | Llorean | Meanwhile you're going to willfully ignore that we don't want the list infinitely long, and that a very practical line to draw is "making it compatible with existing software" so that we *don't* have to make value judgments on "how common" a naming scheme is |
12:32:02 | Llorean | But, feel free to prove me wrong. |
12:32:06 | Llorean | Offer your reasons. |
12:32:13 | josh___ | hi! anyone tried playing pokemon red/blue on rockboy and noticed game crashing when you get killed or when trying to heal? |
12:32:27 | Llorean | josh___: Turn sound on. |
12:32:35 | Llorean | Or possibly off. I can't remember. It's a gnuboy bug. |
12:32:46 | Topy44 | renaming them is effort (just a little, but still) for every user that has files with that naming scheme. adding the filename to rockbox instead is a little effort for one person. and...yeah, it is the reason really :) but not because i'm "lazy" (i have already offered to create the patch), but because i think rb should facilitate things for the users/make using their player to the full extent as little effort as possibly |
12:32:57 | josh___ | w8 i can check this out... |
12:33:18 | Topy44 | therefore i have 2 possible solutions: |
12:33:23 | Llorean | Topy44: You can't facilitate *all* things. Having lines you can draw that don't require value judgments is very handy. |
12:34:17 | Llorean | The vast majority of users who use cover art will have renamed it to an existing scheme. You're probably quit uncommon in a desire to use cover art in the mobile case, but not the PC. |
12:34:26 | Topy44 | 1. collect actually common naming schemes (some that are already supported i have never seen for example), see how common they are among a certain selected usergroup with large collections, add ones that are obviously common |
12:34:52 | Topy44 | 2. make it configurable, allowing everybody to add their own personal favourite naming scheme, though that increases complexity a fair amount |
12:35:04 | Llorean | Topy44: You going to be around ad infinitum to update the list, and field complaints about a favorite scheme not making the list? |
12:35:08 | Topy44 | of course there is also 3. which is "call me an idiot and ignore me" :) |
12:35:15 | Llorean | Option 3) Make it compatible with software, rather than people. |
12:35:16 | josh___ | Llorean: TX a lot! it helped! |
12:35:19 | Llorean | Nobody called you an idiot. |
12:35:38 | Topy44 | its software for people, no? an entertainment product, not a scientific tool for example |
12:35:58 | Torne | Topy44: Code is not free |
12:36:10 | Torne | putting more choices in, or making it configurable, takes memory |
12:36:15 | Topy44 | Llorean: we really are going around in circles - both you and me, i believe to have valid points |
12:36:17 | Torne | puttin gmore choices in takes execution time |
12:36:29 | Torne | we have a pretty sensible criteria to keep the list down to a manageable size |
12:36:58 | | Quit josh___ ("CGI:IRC 0.5.9 (2006/06/06)") |
12:36:59 | Topy44 | torne: agreed, which is why personally i would reevaluate the ones already in the list (also, the current method of checking which files exist looks horribly inefficiant to me) |
12:37:15 | Llorean | Which ones already in the list seem wrong or bad to you? |
12:37:25 | Torne | Topy44: what's wrong with the ones in the list? "named after the file" "named after the album" folder.jpg and cover.* |
12:37:30 | Torne | that all seems very logical :) |
12:38:24 | Topy44 | personally, i find "compatible with common naming schemes" more important then "compatible with existing software" (and the first largely includes the second) |
12:38:51 | Torne | The second is what technically *prevents people from using the feature* though |
12:38:59 | Torne | if, say, our list was just front.jpg |
12:39:01 | Topy44 | well for example i dont have any "filename.ext" ones (files named the same as the current music file) |
12:39:13 | Torne | then there would be no way to rename the art such that it worked in rockbox *and* windows |
12:39:17 | Llorean | So because *you* don't have any it should be reconsidered? |
12:39:20 | Llorean | They're all either known to be used by other software, or necessary to offer the feature set we do (song-specific images, and album-specific images from a pool folder) |
12:39:31 | Llorean | We can't offer song-specific album art without filename.jpg/bmp |
12:39:36 | Torne | thus, supporting windows' scheme (folder.jpg) is *vital* so that people aren't stuck in an impossible situation |
12:39:40 | Topy44 | Llorean: so because *you* dont have the front.jpg one it should NOT be considered? |
12:39:49 | Llorean | Topy44: No, because nobody can name software that uses it. |
12:39:55 | Torne | Topy44: When I have files called front.jpg I rename them to folder.jpg |
12:39:57 | Llorean | See, established criteria here, personal opinion over there. |
12:40:02 | Torne | so that windows displays them, and so they work with rockbox :) |
12:40:29 | Llorean | So why don't you try again, maybe explain why filename.ext is bad? |
12:40:57 | Llorean | It meets an actual need, rather than a simple preference. |
12:40:59 | Topy44 | i wont because i agree that if someone can name reasonably common software that uses that it should stay in. |
12:41:30 | Llorean | So you objected to it a moment ago, but don't now? |
12:42:02 | | Join alexbobp_ [0] (n=alex@adsl-75-34-100-218.dsl.austtx.sbcglobal.net) |
12:42:57 | Topy44 | all i said is i dont know any software that uses it nor do i have any files that match it - of course someone else might |
12:43:29 | Llorean | As I said, that filename exists because a Rockbox feature requires it for the feature to work. |
12:44:07 | Topy44 | ok, software that uses front.jpg: foobar2000 supports it apparently |
12:44:17 | Rudy4Pez | BAM! |
12:44:35 | Llorean | See, not too hard, was it? |
12:44:36 | Llorean | That's all I asked |
12:44:51 | Rudy4Pez | Llorean is stubborn. :P |
12:44:56 | Topy44 | he is isnt he :) |
12:45:04 | Torne | Llorean's stubbornness is a feature, not a bug |
12:45:05 | Torne | :) |
12:45:08 | Llorean | Though I'd like to see your source |
12:45:10 | Rudy4Pez | I haven't been on Rockbox IRC in about 2 years. |
12:45:16 | Llorean | Mine says foobar2000 is simply configurable and you can *add* front.jpg |
12:45:21 | Rudy4Pez | Still stubborn. |
12:45:22 | Rudy4Pez | :P |
12:45:29 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
12:45:46 | | Quit Rudy4Pez ("Java user signed off") |
12:45:52 | Topy44 | let me check, this forum post i found suggest its default but a forum post is of course not a reliable source |
12:45:56 | Llorean | Yeah |
12:45:58 | | Join Rudy4Pez [0] (n=rudy4pez@c-67-170-180-104.hsd1.or.comcast.net) |
12:46:05 | Llorean | I mean, if it's there by default, that's great. |
12:46:06 | Llorean | Go for it. |
12:46:20 | kugel | n1s: http://forums.rockbox.org/index.php?topic=22495.0 |
12:46:21 | Llorean | But if it's configurable, and just something someone added to their personal configuration, different story entirley. |
12:46:41 | Rudy4Pez | Well there must be more to it than that, because it's very very common. |
12:46:54 | Llorean | Rudy4Pez: Commonness isn't really a factor though. |
12:47:13 | * | kugel thinks it would be fine to support front.<ext> |
12:47:25 | kugel | I've also seen it often |
12:47:26 | | Nick bertrik_ is now known as bertrik (n=bertrik@d90-128-154-247.cust.tele2.nl) |
12:47:26 | Rudy4Pez | Llorean: Shouldn't it be? |
12:47:52 | Rudy4Pez | The idea is to make Rockbox work for you, not to make you work for Rockbox. |
12:47:56 | kugel | Rudy4Pez: it is, commonness is the only reason we support folder.jpg |
12:48:09 | Llorean | kugel: No, we support folder.jpg to maintain compatibility with other software. |
12:48:13 | kugel | and we don't support folder.jpeg because it's uncommon |
12:48:47 | Llorean | Collections that show album art in other players should show it in ours, it's more or less that simple. |
12:49:18 | Llorean | "commonness" doesn't really factor into that - just what works elsewhere. |
12:49:45 | Llorean | Besides, if it's so *very* common, I'm amazed at least a moderate amount of FLOSS doesn't support it natively |
12:49:52 | BdN3504 | who has access to the themes site? you better remove this theme. it contains a copyrighted graphic, the wps is simply copied off the wps creating guide. http://themes.rockbox.org/themes/320x240/example_wps_ipod5g_v1.1/example_wps_ipod5g_V1.1.zip |
12:50:20 | | Quit Rudy4Pez (Client Quit) |
12:50:49 | Topy44 | Llorean: confirmed, foobar2000 loads front.jpg by default |
12:50:57 | Topy44 | i just installed and tested it |
12:51:07 | Llorean | Topy44: There you go. |
12:51:46 | kugel | BdN3504: the theme itself doesn't contain any graphic |
12:52:48 | | Quit n1s ("Lämnar") |
12:54:06 | Llorean | An option for custom filenames for AA might be to do it in the WPS instead. |
12:54:24 | Llorean | Or rather specifically, allow images in the WPS to be relative to the played file path, rather than the WPS path (through some alternate tag) |
12:55:01 | * | linuxstb thinks front.jpg/back.jpg is a sensible convention, but also that we don't want to expand the search for album art any more than it already is, and simply renaming front,jpg to cover.jpg would solve it. |
12:55:30 | Llorean | linuxstb: Well, if foobar2000 already supports it, we probably should. I think if collections work with a PC player, we shouldn't really ask for renames. |
12:55:31 | bertrik | so the conclusion of this is that since foobar2000 loads front.jpg, rockbox could do it too? or is this not enough? |
12:55:42 | Topy44 | my personal preference would still be not having to rename anything at all and have rb parse the dir for any jpeg it can find - seems to me like a perfect patch project to keep uncommited |
12:56:18 | Topy44 | and i am sure i can find some pc software that will parse the dir and guess the right cover :) |
12:56:23 | | Quit alexbobp (Connection timed out) |
12:56:31 | linuxstb | Llorean: I don't think changing the wps is the solution - it would be better as a global option. |
12:56:34 | Llorean | Topy44: And you're sure I can't create a folder that stumps it? |
12:56:48 | Llorean | linuxstb: I was thinking it'd offer some other interesting flexibility too though |
12:56:55 | linuxstb | Llorean: foobar2000 does lots of things Rockbox doesn't, such as supporting odd tag/container-format combinations... |
12:57:12 | Llorean | linuxstb: Like, if image and backdrop tags were allowed to be relative to the song, you could actually have artist-specific variants of a WPS. |
12:57:14 | Topy44 | Llorean: well you can of course make it pick the wrong image, but that doesnt really matter much. other then that, i dont see a risk |
12:57:33 | Llorean | Topy44: What's the "risk" in not showing an image, then? |
12:57:44 | Llorean | I'd say not showing it is better than showing the wrong one. |
12:57:58 | Llorean | At least the former just looks like a lack of a feature, rather than a bug. |
12:58:04 | Topy44 | i dont agree, as the correct hit percentage would be very high |
12:58:22 | Llorean | linuxstb: Well, as I said, the discussion when we added folder.jpg basically went "if we find other filenames programs support that we don't, we should probably add them" |
12:58:24 | BdN3504 | Topy44: the winamp toaster plugin parses the folder for specific filenames you throw at it, you can also use *.jpeg |
12:58:33 | Topy44 | i think having 99.5% correct and .5% wrong is better then having 100% not there at all |
12:58:34 | BdN3504 | http://www.winamp.com/plugins/details/138586 |
12:58:36 | Llorean | Topy44: Ah, "good enough is good enough" |
12:58:46 | linuxstb | Topy44: I partially agree with you, but it could cause problems for people that store their music in a single directory, rather than neatly split by album. |
12:58:54 | Llorean | Topy44: You think 100% of album art isn't shown right now? |
12:59:59 | Topy44 | Llorean: no, it depends on the test group of course - 100% of incorrectly named album art :) |
13:00 |
13:00:36 | linuxstb | Llorean: I just think the code already offers enough flexibility. But I'm not strongly against adding front.jpg - it's a sensible convention. |
13:00:46 | Topy44 | which in the case of my imho rather representable (because large and sourced through many different ways) collection would be roughly 50% of all albums containing album art |
13:01:05 | Llorean | linuxstb: I do too. I was just saying that if custom filenames were going to be added, maybe it could be made more interesting than that by making it "bigger" as it were. |
13:01:20 | Llorean | Topy44: Which, if there's a reliable algorithm, could be mass renamed rather quickly anyway |
13:01:32 | kugel | linuxstb: looking up filenames isn't really a wasteful operation, is it? it doesn't even require a disk spinnup with dircache, and the buffering is way more demanding |
13:01:56 | Topy44 | correct - again, a "sort your collection" vs "let the player guess" discussion, and as we agreed, the difference is "effort for one person" vs "effort for the users" |
13:01:58 | Llorean | linuxstb: I think though it's good enough to add front.jpg and... was it album.jpg? |
13:02:11 | Llorean | Topy44: I didn't agree to that. |
13:02:48 | Torne | Topy44: you are, again, asusming that adding features to rockbox only costs developer time |
13:02:54 | Topy44 | Llorean: you wouldnt agree if i argued that the sky was blue :) |
13:02:56 | Llorean | Topy44: And you forget the "hidden cost to users who don't make use of the feature" aspect of it. |
13:03:04 | BdN3504 | kugel: i think people shouldn't be able to post the example wps to the themes gallery. it's merely a copy of the theme on the wiki site. posting multiple instances of it is a waste of space. |
13:03:21 | Llorean | Topy44: You may not be aware of it, but Rockbox is already running up against some pretty strict size limitations. |
13:03:25 | Topy44 | i dont forget that at all, no |
13:03:35 | kugel | BdN3504: ideally we aren't going to need the wiki sites anymore |
13:04:17 | Llorean | Topy44: If you didn't forget it, I assume you chose it ignore it when simplifying it down to "effort for one" vs "effort for many"? |
13:04:37 | Topy44 | correct. |
13:04:54 | BdN3504 | kugel: i don't mean the wps gallery wiki. i mean http://www.rockbox.org/twiki/bin/view/Main/SimpleGuideToWPSMaking |
13:05:00 | Topy44 | there are of course always many more things to consider. one of them being how much actual ressources would be used |
13:05:15 | Topy44 | as in "is it worth it" |
13:05:21 | Llorean | Topy44: So if those are actually worth considering, why are you factoring them out of the discussion? |
13:05:22 | Torne | the runtime cost in cycles/memory/disk access is *far* more important than developer time, mostly :) |
13:05:51 | Topy44 | ok, lets talk about runtime cost: |
13:06:02 | bertrik | My guess is that the impact of adding another filename is very limited |
13:06:06 | Llorean | Simplicity has significant benefits, and the simplest method is a set list of possible filenames. |
13:06:17 | Llorean | Unless the list grows to rather large size. |
13:07:03 | Topy44 | well, the list would still be needed to the most part |
13:07:11 | Topy44 | *for |
13:07:37 | Llorean | So, it would be added complexity on top of the list to benefit users who have album art that they're not actually already using? |
13:07:51 | Topy44 | umh...yes :) |
13:08:41 | kugel | BdN3504: alright, removed |
13:09:21 | BdN3504 | ^^ thanks finally some consent :) |
13:09:28 | | Join intrados_ [0] (n=intrados@cpe-71-67-138-190.woh.res.rr.com) |
13:09:39 | BdN3504 | kugel: you read my earlier post? |
13:10:27 | BdN3504 | http://www.rockbox.org/irc/log-20090817#11:44:45 |
13:10:53 | BdN3504 | kugel: quote: "the ? remainz" |
13:10:53 | Topy44 | as i see it, it is a feature that would actually benefit a significant usergroup (i wouldnt want to guess percentages), by lessening their effort pre-sorting their collection, while "costing" relatively little in the way of cpu cycles and memory, and nothing in the way of disk access (no extra spin up) |
13:11:03 | Topy44 | also, no cpu cycles at all if made optional |
13:11:24 | Topy44 | (well ok, some for the "is it on" check :) |
13:11:30 | kugel | BdN3504: ?? |
13:11:34 | Llorean | Topy44: The "significant usergroup" who wants to use album art on their DAP, already has it on their PC, but doesn't already use it on their PC? |
13:12:01 | kugel | BdN3504: Advanced Topics -> Customising the User Interface is appropriate I think |
13:12:02 | Topy44 | or uses software that parses the dir (allowing wildcards) |
13:12:04 | Topy44 | but yes |
13:12:20 | Topy44 | go ahead and make a poll :) i am sure that i am not the only one |
13:12:29 | kugel | arguing about cpu cycles is useless imo |
13:12:42 | Topy44 | (i do btw use my album art, i just dont let my media player display it, i actually look at it with an image viewer sometimes) |
13:12:56 | Topy44 | (therefore the filenames are completely irrelevant as i click on them manually) |
13:13:24 | Llorean | Topy44: You're also looking at diminishing returns. To use your own approach, the vast majority of users are already served by what we have. |
13:13:35 | Llorean | What you propose adding would cost significantly more than what we have, and yet serve a significantly smaller number of users. |
13:14:02 | bertrik | Llorean, I'm not so sure about that |
13:14:07 | linuxstb | bertrik: Are any of your S5L8700 ports close to running a real Rockbox build? I've been trying to get it working on my Nano2G, but it's failing with odd problems, and I would be curious to know if it's just on the Nano. |
13:14:07 | Topy44 | are you so sure about that vast majority? |
13:14:14 | Llorean | bertrik: About which part? |
13:14:23 | kugel | I wasn't away that gevaerts has put up samsung yh binaries in the test builds forum |
13:14:50 | bertrik | Llorean, that it would cost significantly more and server a significantly smaller numbers of users |
13:14:59 | kugel | Llorean: are you sure it's "significant"? |
13:15:07 | Galois | I find these discussions a bit wrong-footed. "Vast majority" arguments can and are often used to justify supporting only mp3, or only windows, or any number of support decisions that in other contexts we would dismiss. |
13:15:27 | Llorean | bertrik: You think it would serve even relatively similar numbers of users? |
13:15:35 | Llorean | kugel: In what sense? |
13:15:46 | kugel | "What you propose adding would cost significantly more than what we have" |
13:15:53 | Llorean | Galois: But this isn't whether or not to add support for something or leave it out entirely |
13:15:54 | Topy44 | you need to do that assession about every single feature in rockbox really - cost in ressources vs amount of users actually benefiting from it |
13:16:03 | *** | Saving seen data "./dancer.seen" |
13:16:04 | Llorean | Galois: This discussion is whether to allow people an extended degree of disorganization. |
13:16:13 | bertrik | Llorean, no, I just doubt your statement about the significance |
13:16:38 | Llorean | bertrik: I'm reasonably confident that we would gain very few new users of album art relative to the number we already have. |
13:17:03 | kugel | looking for another filename is rather really insignificant |
13:17:05 | Topy44 | i am not, but of course thats all open to discussion |
13:17:18 | Llorean | kugel: If it needs to check every filename in the folder before attempting to decide which one to use, then yes in many circumstances it will cost a lot more time than the current method |
13:17:32 | | Quit intrados (Connection timed out) |
13:17:32 | Llorean | We're not talking about looking for *one* other filename now |
13:17:42 | bertrik | linuxstb, the meizu m3 can almost build to a real rockbox image, I haven't really tried for the samsung yp-s3. Overall I haven't put effort in it yet. |
13:17:48 | Topy44 | no, we are talking about the "parsing the directory" variant |
13:17:49 | Llorean | We're talking about going through the whole folder and trying to *guess* which file from any present jpegs is the album art. |
13:18:10 | kugel | it's still insignificant |
13:18:28 | Llorean | Relative to the existing method? |
13:18:38 | Topy44 | yeah, if the directory structure is already in the dircache it would be a rather quick search |
13:19:12 | kugel | Topy44: oh, I'm still at "looking for front.jpg additionally" |
13:19:14 | bertrik | so, what exactly has been decided on now? or haven't we decided about anything yet? |
13:19:23 | Topy44 | kugel: ah, ic |
13:19:25 | Llorean | bertrik: Add front.jpg and album.jpg I think |
13:19:44 | Llorean | kugel: I'd say a full directory scan and decision making process is hardly insignificant *relative* to what we already do. |
13:19:50 | bertrik | Llorean, ok |
13:20:10 | Llorean | It may take a very short time, but it's still a lot longer than just checking for a short list of filenames if the folder it's going through is big. |
13:20:37 | kugel | Llorean: it is. a directly scan is relatively cheap, especially with dircache. It's just a FAT operation, and has nothing to do with looking at the real folder |
13:20:48 | kugel | directory scan* |
13:20:48 | Topy44 | Llorean: btw, did that rudy4pez guy mention any software that uses album.jpg? (none in my music collection btw) |
13:20:49 | bertrik | I am in favour of adding front.jpg but have doubts about adding a more elaborate heuristic scan |
13:21:01 | Llorean | kugel: Do you know what "relative to" means? |
13:21:07 | kugel | yes |
13:21:08 | Topy44 | (correction: found ONE :) |
13:21:49 | Llorean | kugel: So you don't think it could take two or even three times as much time if this were added as it does now? |
13:22:16 | Topy44 | Llorean: the question is: is "much longer" any significant amount of time/cycles? |
13:22:31 | kugel | if we're just talking about looking adding 1 or 2 fixed filenames to the list, then yes |
13:22:31 | Topy44 | or is it still "so quick it doesnt matter" |
13:22:46 | Topy44 | kugel: we are not, already decided on that :) |
13:22:46 | Llorean | kugel: We're talking about the search |
13:22:52 | Llorean | kugel: I already told you that once. |
13:23:09 | Llorean | It needs to find all .jpg, .jpeg, and .bmp files, then decide which one is most likely the cover via some algorithm. |
13:23:10 | linuxstb | bertrik: OK, I'll try and clean up what I've got so far, and commit it anyway. It's mostly just adding stubs, plus implementing app.lds and some changes to crt0.S |
13:23:35 | kugel | Llorean: I don't think we want that |
13:23:58 | bertrik | linuxstb, fine with me. If something breaks, I'll yell :) |
13:24:05 | linuxstb | bertrik: I'm sure you will!e |
13:24:07 | Llorean | kugel: Yes, as I said, it would take much more time (relative to the amount we already spend) and serve a relatively small additional group of users (people who don't already use their album art in some PC program) |
13:24:11 | Topy44 | kugel: and thats what the whole discussion is about really: does anyone want that :) |
13:24:15 | * | linuxstb didn't mean to type that extra e... ;) |
13:24:32 | Llorean | Topy44: I *thought* I knew a program that used album.jpg but on second look it doesn't, so maybe not. |
13:24:41 | BdN3504 | quick question: is the manual compeiled with files that are only found in the manual directory of the source tree? can i copy that folder onto another machine and then still be able to build the manual? |
13:24:54 | BdN3504 | compeiled -e =compiled |
13:25:32 | | Join ehntoo [0] (n=ehntoo@adsl-99-156-192-57.dsl.applwi.sbcglobal.net) |
13:26:01 | Topy44 | completely irrelevant if you follow Llorean's argumentation, but still interesting: http://www.googlefight.com/index.php?lang=en_GB&word1=%22front.jpg%22&word2=%22album.jpg%22 |
13:26:54 | GeekShadow | bertrik, can rockbox meizu access to files yet ? |
13:27:26 | bertrik | GeekShadow, no, that's still quite far off in my opinion |
13:27:52 | kugel | not sure I have ever seen album.jpg |
13:28:07 | kugel | +if |
13:28:17 | markun | bertrik: and the code in openiboot is not compatible with our FTLs? |
13:28:23 | linuxstb | bertrik: Is the keymap going to be straightforward on your Samsung target? |
13:29:26 | | Quit GeekShadow ("The cake is a lie !") |
13:29:52 | bertrik | markun, for the samsung yp-s3 I looked a bit closer and it didn't seem to be compatible with the openiboot FTL, I haven't looked that close at it for the meizus yet |
13:30:41 | linuxstb | bertrik: Was it the samsung where you wrote some initial NAND code to read the ID? |
13:30:42 | bertrik | linuxstb, yes, I think so, it has pretty normal up/down/left/right/select buttons, a "menu" button and a "back" button |
13:31:08 | bertrik | (I meant the samsung yp-s3) |
13:31:28 | markun | bertrik: do you think we should use some other FTL and forget about the OF? |
13:31:50 | bertrik | linuxstb, yes that code is somewhat specific for the samsung yp-s3, the specific thing is the way the NAND chip select is controlled |
13:32:32 | linuxstb | bertrik: Ah, OK. But presumably, now that's working, reading/writing NAND pages should be relatively straightforward? |
13:33:44 | bertrik | linuxstb, yes I think so, I got the read id routine from the OF, but it's very similar to the one in the data sheet, the data sheet also has sequences for reading the NAND |
13:33:59 | bertrik | I wouldn't dare to erase/write NAND pages yet |
13:34:46 | bertrik | markun, for the short term I hope have least read-only access to the FTL of the OF |
13:35:44 | | Quit HBK- (Read error: 104 (Connection reset by peer)) |
13:35:47 | | Join KBH [0] (n=hbk@rrcs-97-77-53-84.sw.biz.rr.com) |
13:36:48 | bertrik | maybe in the long term we could have our own rockbox flash file system (and access it over MTP for example) |
13:37:02 | bertrik | I'm still not sure what would be best / easiest / possible at all |
13:43:31 | linuxstb | Well, I've always seen Rockbox as a _replacement_ firmware... |
13:45:50 | linuxstb | And speaking personally, I never use OFs, so our own FTL would fully meet my needs. But of course, it would make Rockbox far less interesting for casual users. |
13:46:23 | | Quit gevaerts (Nick collision from services.) |
13:46:35 | | Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) |
13:46:59 | | Join AndyIL [0] (i=AndyI@212.14.205.32) |
13:59:08 | | Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) |
14:00 |
14:01:00 | | Quit AndyI (Read error: 110 (Connection timed out)) |
14:10:18 | bertrik | linuxstb, what do you think about implementing an FTL vs. using a flash file system without any FTL at all? |
14:10:52 | bertrik | with an FTL we could still be using fat and access it over USB MSC |
14:11:08 | Torne | it's *probably* less effort to implement an FTL, also |
14:11:18 | Torne | especially if you nick the algorithm from linux |
14:11:21 | Torne | (or similar) |
14:11:24 | bertrik | a direct flash file system leaves out the FTL layer, but probably requires MTP support over USB to access the file system |
14:11:37 | Torne | (versus trying to port jffs/ubifs/etc or *shudder* actually design one) |
14:11:58 | bertrik | I don't have any ambition to design my own :) |
14:12:24 | bertrik | maybe adapt an existing one |
14:12:27 | | Quit ehntoo (Read error: 110 (Connection timed out)) |
14:14:34 | Torne | i think using an actual flash fs would be a long way off |
14:14:46 | Torne | the advantages are not so big probably when you're tlaking about a DAP |
14:15:11 | Torne | an FTL is not so bad for a filesystem you mostly read, and when you do write you tend to create/delete entire files. |
14:17:32 | BdN3504 | have i done something wrong, or is a description of viewports really missing in the manual? |
14:18:07 | bertrik | Torne, indeed I think a typical disk access scheme is to write several large files on it over USB (e.g. copy mp3s to it), read those files from within rockbox (playing music) and write smallish files to it from within rockbox itself (e.g. updating settings) |
14:18:25 | BdN3504 | do i really have to write it myself? |
14:18:49 | BdN3504 | or can i just point a reference to the wiki? |
14:18:55 | Torne | Yah, writing large files to a minimally fragmented disk works pretty well in an FTL |
14:19:04 | BdN3504 | i think i'll go that route |
14:19:10 | Torne | you tend to get the case where you are in fact writing a whole erase block sequentially quite often. |
14:19:17 | Torne | as long as the FTL has enough buffering |
14:19:29 | Torne | updating settings and so on is probably little enough that we can ignore it |
14:19:40 | Torne | if you were really concerned, actually.. |
14:19:41 | bertrik | Torne, do you have any suggestion for an FTL we could port? |
14:19:47 | Torne | you could reserve some flash blocks to be the nvram |
14:19:55 | Torne | and write that to flash as raw sectors without the ftl |
14:20:02 | Torne | (you'd need a versioning mechanism or something but that'd be fine) |
14:20:30 | Torne | I'd suggest you just look in linux-mtd and nick whatever seems to be suitable for the flash type you are working with, if you really didn't care about OF compatibility |
14:20:41 | Torne | I'm not sure what the state of the art is there, though |
14:20:49 | Torne | I have onlt really worked with patented proprietary FTLs |
14:20:51 | Torne | :) |
14:21:10 | Torne | and with flash filesystems directly. Never actually used the linux ftls. |
14:22:24 | | Join LambdaCalculus37 [0] (i=44a0430d@rockbox/staff/LambdaCalculus37) |
14:24:26 | bertrik | I read about ONFI, open-nand-flash-interface. It looks like this is the route future flash-based DAPs will take for their NAND memories (and probably some current ones already do) |
14:25:17 | bertrik | it would be nice if we could find some FTL that offers a block interface on top and uses an ONFI interface at the bottom |
14:26:30 | Torne | The actual details of how you talk to the nand are kinda boring and a minor porting detail, tbh :) |
14:27:04 | Torne | it's minor effort to change the actual calls you make to the storage driver slightly, at most |
14:27:29 | Torne | the important logic in the ftl only depends on what the subpage/page/eraseblock sizes are, and whether there are page write order restrictions |
14:29:22 | bertrik | oh, I read some things about copyback for example that is a bit more advanced than just read/write/erase |
14:30:42 | BdN3504 | where do i find the names of the targets in the manual? for example RECORDER_PAD, to which models does this apply? |
14:30:55 | Torne | bertrik: copyback is just a smarter way of doing read-modify-write. |
14:30:58 | Torne | the cycle is the same |
14:31:39 | bertrik | ok |
14:31:43 | Torne | you erase the target block, then use copyback for an internal data move of the pages that haven't changed |
14:31:50 | Torne | and you only issue actual writes for the pages that you are changing |
14:32:06 | Torne | s'just quicker and a little safer |
14:39:40 | bertrik | *someone* should put this info (where applicable to rockbox) in a more organised form on the wiki ... :) |
14:40:38 | Torne | ..you have the logs :) |
14:46:24 | CIA-61 | New commit by mcuelenaere (r22375): Skin engine: add "pitch" action to touch regions |
14:47:46 | BdN3504 | how can i differentiate in the manual between the different ipod models? are they not defined? |
14:48:39 | BdN3504 | i am looking for the \opt{ command for 1g 2g 3g 4g 5g and 5.5g |
14:48:50 | CIA-61 | New commit by mcuelenaere (r22376): Enable the pitch action in the M:Robe 500 Cabbiev2 WPS |
14:49:09 | | Part LinusN |
14:51:39 | bertrik | Torne, on http://www.linux-mtd.infradead.org/faq/general.html I found this statement "Unfortunately it is a rather difficult task to create a good FTL layer and nobody still managed to implement one for Linux. But now when we have UBI (see here) it is much easier to do it on top of UBI." |
14:52:09 | bertrik | I guess that means we can't that easily nick something from linux |
14:52:42 | Torne | er.. |
14:52:54 | Torne | there are at least two FTLs in linux |
14:52:55 | Torne | three? |
14:54:29 | Torne | http://lxr.linux.no/#linux+v2.6.30.5/drivers/mtd/Kconfig |
14:54:33 | Torne | "several" |
14:54:47 | Torne | they may not count as *good* |
14:54:53 | Torne | and i dunno that any of them run on MLC NAND |
14:54:57 | Torne | but they're there :) |
14:55:32 | CIA-61 | New commit by mcuelenaere (r22377): Onda VX747: don't enable software volume control in sims |
14:57:41 | bertrik | meh, easier said than done, I see warnings about not being allowed to use the FTLs on anything other than PCMCIA hardware ("FTL)" or on diskonchip hardware ("NFTL") for example |
14:57:58 | Torne | That would be patents |
14:58:03 | Torne | as we have previously discussed |
14:58:25 | Torne | it is very likely that any FTL you port or implement is covered by someone's patent somewhere |
14:58:25 | BdN3504 | is there a way to \opt different screensizes in the manual? |
15:00 |
15:01:43 | bertrik | well, *I* didnt make up that statement from 14:51, I just quoted it and it seems fairly recent and from the linux mtd people |
15:02:53 | Torne | bertrik: Yah, i know |
15:02:59 | Torne | I don't know what they mean, anyway. |
15:03:08 | linuxstb | BdN3504: I don't believe so. It's been discussed, but I don't think anyone has implemented it. |
15:03:10 | Torne | There are some FTLs but they are possibly crappy and probably patent-encumbered. |
15:03:24 | Torne | however any other ftl someone might implement is probably patent infringing as well |
15:03:43 | Torne | but of course they aren't going to look into that, because of the whole thing with knowing infringement in the US :) |
15:05:04 | bertrik | ok, I appreciate your knowledge on this subject |
15:05:22 | Torne | you are rapidly exhausting my knowledge on this subject :) |
15:05:28 | Torne | a broad introduction is about the best i can do |
15:06:46 | bertrik | at least to me, this whole FTL thing makes the rest of the samsung-based players porting effort pale in comparison ... |
15:07:03 | Torne | it's not something that's come up before i guess |
15:08:17 | CIA-61 | New commit by mcuelenaere (r22378): * Onda VX747: add browse screen, pitchscreen, context menu, quickscreen, rewind, fast forward, previous song & next song actions to cabbiev2 ... |
15:10:15 | | Join Ubuntuxer [0] (n=johannes@dslb-094-221-089-068.pools.arcor-ip.net) |
15:15:17 | * | kugel has a updating progressbar in the main menu :D |
15:16:06 | *** | Saving seen data "./dancer.seen" |
15:16:58 | bertrik | don't we have the WPS for that? |
15:17:29 | bertrik | what kind of progress does this bar show? |
15:17:56 | kugel | playback progres |
15:18:18 | kugel | bertrik: I'm playing around a bit with a skin'ified statusbar |
15:19:26 | kugel | that can use all wps tags |
15:22:18 | | Join muesli [0] (n=sdf@77-21-250-67-dynip.superkabel.de) |
15:22:35 | muesli | G'mornin |
15:22:41 | muesli | a h120 user arround? |
15:22:46 | muesli | or 140 |
15:22:50 | muesli | iriver |
15:23:21 | linuxstb | muesli: Best to just ask the question. |
15:24:34 | muesli | just plugged in the charger (using pre-bootloader 7pre4) and the green light is on. does it turn off when its done? (havent had a h120 for ages and cant remember) |
15:26:31 | linuxstb | I seem to recall it does, but haven't used my h120 for ages either. Best to wait for someone with more recent experience... |
15:26:38 | | Join evilnick [0] (i=0c140464@gateway/web/freenode/x-chelptnnsjieyteb) |
15:27:29 | | Quit kugel (Read error: 60 (Operation timed out)) |
15:27:32 | muesli | ok...but was it normal that the screen remains empty? can remember that there was a charging sign? |
15:29:11 | moos | IIRC yes that's normal, the only indication is the green light |
15:29:51 | moos | btw /me remenbers an old muesli user :) |
15:30:22 | muesli | yepp, thats me ;) |
15:30:46 | moos | hola then, and welcome back to rockbox usage ;) |
15:31:08 | muesli | hola moos :-) |
15:31:26 | muesli | never gave up using rockbox...was just happy with it and no question left ;) |
15:33:10 | moos | when you use rockbox for years, hard to use any OF after ;) |
15:34:14 | muesli | exactly :) |
15:34:38 | muesli | thats why i didnt consider any other player than the old good irivers |
15:35:22 | moos | :) |
15:35:44 | | Quit KBH (Read error: 104 (Connection reset by peer)) |
15:35:53 | | Join KBH [0] (n=hbk@rrcs-97-77-53-84.sw.biz.rr.com) |
15:37:07 | | Nick martian67_ is now known as martian67 (n=martian6@about/linux/regular/martian67) |
15:37:34 | muesli | im only desperatly waiting for audible seeking :o |
15:38:22 | moos | muesli: imho, don't count on it ;) |
15:39:14 | muesli | booh ;( |
15:40:56 | muesli | i remember some pre-recording setting. was is it that way, that you could set up ie 2minutes until it records? |
15:42:09 | moos | yes you can |
15:42:31 | moos | an you can even check the fine manual we have now :) |
15:42:42 | muesli | i hate manuals ;) |
15:42:55 | CIA-61 | New commit by mcuelenaere (r22379): Utils/Analysis/Find_Addr.pl: fix wrongly recognizing addresses as being in codec or plugin space when their addresses were invalid |
15:52:38 | | Join jgarvey [0] (n=jgarvey@cpe-098-026-065-013.nc.res.rr.com) |
16:00 |
16:03:52 | | Part Ubuntuxer |
16:06:40 | | Quit moos ("Rockbox rules the DAP world") |
16:06:54 | | Join z35 [0] (n=z35@ool-45701ce5.dyn.optonline.net) |
16:10:01 | | Join froggyman [0] (n=chatzill@pool-72-69-79-22.chi01.dsl-w.verizon.net) |
16:11:30 | | Nick alexbobp_ is now known as alexbobp (n=alex@adsl-75-34-100-218.dsl.austtx.sbcglobal.net) |
16:18:16 | | Join fml [0] (n=4fd3c7d3@gateway/web/cgi-irc/labb.contactor.se/x-tcjypfihoqnvszxc) |
16:19:03 | muesli | for all who care: yes, the green light turns off when its done |
16:19:15 | fml | muesli: IIRC the green LED is just an indication that the player is connected to the charger. It's not an indication that the battery is really being charged, i.e. not full yet. |
16:19:50 | fml | muesli: Ah, I read your question and just responded, but wrongly! |
16:20:24 | fml | I didn't know that the greed LED is that "intelligent"! |
16:22:12 | | Join polobricolo [0] (n=polobric@201.204.143.42) |
16:23:20 | muesli | lets c if it is ;) |
16:24:21 | amiconn | The green led *is* a charging indicator (actually *the* charging indicator - you cannot read charging status from the CPU, only voltage) |
16:25:41 | fml | kugel: does this mean that in order to always see e.g. the current song's title (i.e. even when in menu etc.) we'd have to stuff all the information into the status bar? |
16:26:21 | fml | amiconn: but it's not the "not full" indicator, right? Just the "connected" one. |
16:34:05 | | Quit Kopfgeldjaeger (Read error: 60 (Operation timed out)) |
16:37:03 | | Quit mt (Read error: 113 (No route to host)) |
16:39:05 | | Quit AndyIL () |
16:40:12 | | Join Polo [0] (n=polobric@201.204.143.42) |
16:41:05 | | Quit polobricolo (Read error: 113 (No route to host)) |
16:41:38 | | Nick Polo is now known as polobricolo (n=polobric@201.204.143.42) |
16:43:21 | | Join toffe82 [0] (n=chatzill@74.0.180.178) |
16:47:02 | | Join AndyI [0] (i=AndyI@212.14.205.32) |
16:56:43 | | Quit polobricolo (Read error: 104 (Connection reset by peer)) |
17:00 |
17:00:40 | | Quit muesli () |
17:01:14 | | Quit thegeek ("( www.nnscript.com :: NoNameScript 4.2 :: www.regroup-esports.com )") |
17:04:15 | | Join Lss [0] (n=Lss@cm61.delta93.maxonline.com.sg) |
17:06:05 | | Join mt [0] (n=MTee@rockbox/developer/mt) |
17:09:00 | amiconn | fml: It *is* the "not full" indicator |
17:14:46 | | Join polobricolo [0] (n=polobric@201.204.143.42) |
17:16:07 | *** | Saving seen data "./dancer.seen" |
17:17:24 | | Quit polobricolo (Read error: 104 (Connection reset by peer)) |
17:17:42 | | Join froggyman_ [0] (n=chatzill@pool-71-186-9-224.chi01.dsl-w.verizon.net) |
17:18:08 | | Quit froggyman_ (Client Quit) |
17:18:28 | | Join webguest83 [0] (n=47ba09e0@gateway/web/cgi-irc/labb.contactor.se/x-rmuklseimtabiced) |
17:19:10 | | Quit webguest83 (Client Quit) |
17:19:26 | | Join froggyman_ [0] (n=chatzill@pool-71-186-9-224.chi01.dsl-w.verizon.net) |
17:20:34 | | Quit froggyman_ (Client Quit) |
17:20:53 | | Join froggyman_ [0] (n=chatzill@pool-71-186-9-224.chi01.dsl-w.verizon.net) |
17:21:46 | | Quit froggyman (Nick collision from services.) |
17:21:49 | | Nick froggyman_ is now known as froggyman (n=chatzill@pool-71-186-9-224.chi01.dsl-w.verizon.net) |
17:28:01 | | Quit Grahack (Read error: 104 (Connection reset by peer)) |
17:30:01 | | Join Grahack [0] (n=chri@ip-222.net-82-216-222.rev.numericable.fr) |
17:30:06 | CIA-61 | New commit by wincent (r22380): PDBox: Made GUI use default back- and foreground colors. |
17:36:02 | | Quit KBH (Read error: 104 (Connection reset by peer)) |
17:36:06 | | Join HBK- [0] (n=hbk@rrcs-97-77-53-84.sw.biz.rr.com) |
17:39:11 | CIA-61 | New commit by wincent (r22381): PDBox: Simplified some float math functions. |
17:45:14 | | Quit ch4os (Read error: 104 (Connection reset by peer)) |
18:00 |
18:00:30 | | Quit bertrik (Remote closed the connection) |
18:05:17 | | Join jyu [0] (i=2669ecc2@gateway/web/freenode/x-bqizykhzhtxifbjt) |
18:05:36 | | Join FOAD_ [0] (n=dok@82.93.10.238) |
18:06:57 | fml | amiconn: nice to know! |
18:07:58 | | Quit petur ("work->home") |
18:09:03 | | Join faemir [0] (n=faemir@78.33.109.163) |
18:09:37 | | Quit avacore^ (Read error: 110 (Connection timed out)) |
18:10:28 | | Join bertrik [0] (n=bertrik@d90-128-154-247.cust.tele2.nl) |
18:10:50 | | Quit Xerion (" ") |
18:14:44 | | Join polobricolo [0] (n=polobric@201.204.143.42) |
18:18:47 | mt | amiconn: This has ~0.5% speedup on PP502x, Could you test for CF ? |
18:18:55 | mt | Sorry, This : http://www.pastie.org/586029 |
18:19:33 | | Nick jyu is now known as CaptainKwel (i=2669ecc2@gateway/web/freenode/x-bqizykhzhtxifbjt) |
18:22:09 | | Quit FOAD (Read error: 110 (Connection timed out)) |
18:22:09 | | Nick FOAD_ is now known as FOAD (n=dok@82.93.10.238) |
18:22:37 | | Quit polobricolo ("Good bye") |
18:29:44 | | Quit bertrik (Read error: 104 (Connection reset by peer)) |
18:30:28 | | Quit Marvin_ ("CGI:IRC (EOF)") |
18:30:37 | | Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) |
18:31:44 | | Quit robin0800 (Remote closed the connection) |
18:33:02 | | Join Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) |
18:45:03 | | Quit fml ("CGI:IRC (EOF)") |
18:57:59 | BdN3504 | commit this please. http://www.rockbox.org/tracker/task/10536?getfile=20299 |
18:58:06 | BdN3504 | http://www.rockbox.org/tracker/task/10536 |
18:59:20 | linuxstb | BdN3504: Why not simply link to http://themes.rockbox.org ? |
18:59:46 | | Join ch4os [0] (n=ch4os@gentoo/user/ch4os) |
18:59:54 | linuxstb | a) it won't need updating with new targets; b) it won't need updating if the theme site changes structure |
19:00 |
19:04:24 | BdN3504 | linuxstb: wtf. it was like that in the old manual, i simply updated it and took an awful lot of time because a) no one helped when i literally yelled, and b) because i kept the order the manual download page lists the targets. |
19:04:35 | BdN3504 | don't tell me this is no improvement!!! |
19:05:31 | BdN3504 | and as the new targets won't get comitted all at the same time, i don't think it's much of a fuzz to add a line which i have prepared and replace the names. |
19:05:40 | BdN3504 | links repectively |
19:07:28 | | Quit froggyman ("ChatZilla 0.9.85 [Firefox 3.5.2/20090729225027]") |
19:08:18 | | Quit AndyI () |
19:09:58 | linuxstb | BdN3504: I think the fact that that list was so out of date (e.g. no links to the Sansa e200 or Gigabeat wps galleries) shows that things like this get forgotten. Hence my suggestion to just have a generic link that will never get out of date. |
19:13:17 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
19:14:31 | | Join Horscht [0] (n=Horscht2@xbmc/user/horscht) |
19:14:58 | BdN3504 | me worked much on this. find suggestion less convenient because must click each target respectively while my solution tak to gallery respictve target directly. |
19:15:56 | BdN3504 | say sentence befroe last sentence, if you read: target adding not much happening, so list no much get update |
19:16:11 | *** | Saving seen data "./dancer.seen" |
19:17:54 | kugel | fml: yes |
19:20:23 | kugel | BdN3504: I also think linuxstb's suggestion is more useful |
19:21:53 | BdN3504 | aaaah whole rb dev against me. can assign task to me. will keep up to date until end of time. |
19:22:26 | markun | :) |
19:24:42 | linuxstb | BdN3504: Please don't take it personally - I'm not against you, I'm just in favour of simple solutions. |
19:24:50 | | Join JdGordon| [0] (n=Miranda@131.107.0.69) |
19:25:52 | kugel | JdGordon|: hey, I hacked a skin'ified statusbar together. Works well, except that images aren't loaded (find_image fails) |
19:26:15 | JdGordon| | ok |
19:26:21 | JdGordon| | why dont the images load? |
19:26:29 | JdGordon| | probably because the folder is wrong |
19:26:49 | JdGordon| | the bmp folder i mean |
19:27:08 | kugel | JdGordon|: no they are parsed fine |
19:27:10 | | Quit BdN3504 ("CGI:IRC (Ping timeout)") |
19:27:21 | JdGordon| | loadeding happens after parsing |
19:27:28 | | Join kachna [0] (n=kachna@r4ax178.net.upc.cz) |
19:27:30 | kugel | I didn't change the folder, my .sb is in .rockbox/wps |
19:27:41 | JdGordon| | did you fix token_value() or whatver than damn funciotn is called so it doesnt return if id3==NULL? |
19:28:06 | kugel | no, the statusbar doesn't show up before music was played as of now :) |
19:28:28 | linuxstb | BdN3504: What are you referring to when you say " no one helped when i literally yelled" ? |
19:29:05 | kugel | but it really can't manage to find a single image (it seems the id is off by one actually), which is frustrating because it works so properly besides that (and the id3 == NULL thing) |
19:29:29 | JdGordon| | kugel: yeah, thats something which needs to be fixed... not being able to work if no music is playing is just bad :) |
19:30:01 | JdGordon| | I assume its a pretty big ram hit adding another set of gui_wps sturcts? |
19:30:08 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
19:30:27 | kugel | yea, probably, that's why you're supposed to convert the arrays into the skin_buffer quickly ;) |
19:30:48 | JdGordon| | I'll go at the same pace as custom ui :) |
19:30:54 | JdGordon| | except no, i want to get this done |
19:31:00 | JdGordon| | viewports tonight hopefully |
19:31:00 | kugel | ahh no, don't |
19:32:03 | JdGordon| | the viewport one is the last "easy" one I think... the lines, sublines and tokens will need some thinking about |
19:32:45 | JdGordon| | I'm tihnking that for tokens at least they will be allocated on init to some value, large for wps, small(er) for sb |
19:32:58 | JdGordon| | like, 200 tokens for sb sounds reasonable |
19:34:03 | kugel | very, but why the limiting? |
19:35:13 | pixelma | linuxstb: are you sure the database's track guessing was removed? |
19:35:20 | kugel | so, you don't have any idea why images work fine from the .wps, and not for the .sb (the .wps and .sb are exactly the same, except no backdrop for the .sb) |
19:35:45 | JdGordon| | kugel: because making a linked list of tokens is probably going to be more wasteful than just doing a boring array allocation |
19:36:03 | | Quit HBK- (Read error: 104 (Connection reset by peer)) |
19:36:07 | | Join KBH [0] (i=hbk@rrcs-97-77-53-84.sw.biz.rr.com) |
19:36:08 | JdGordon| | kugel: they are named the same also exept the extension? |
19:36:16 | kugel | yea |
19:36:27 | JdGordon| | whip out gdb :) |
19:38:03 | JdGordon| | anyone have any thoughts about allocating tokens/lines/sublines in blocks of 15 or so and have them in linked lists? |
19:38:25 | linuxstb | pixelma: Err, no... Are you saying it still does it? |
19:38:31 | kugel | the id seems off by 1, for the wps e.g. n=26 manages to match, but for the .sb it doesn't because max id is 25. For the next image all numbers are +1 |
19:40:34 | JdGordon| | the image id thing is very confusing..... feel like changing it to store the char instead of an int in svn? |
19:40:50 | | Join Omlet [0] (n=Omlet05@225.120-240-81.adsl-dyn.isp.belgacom.be) |
19:40:53 | | Join moos [0] (i=mustapha@rockbox/staff/moos) |
19:41:04 | kugel | how's that useful? |
19:41:43 | JdGordon| | figuring out why image 41 didnt load is harder than 'E' |
19:42:01 | JdGordon| | also, longer term.. I want to change the image id's to strings and subimage numbers... |
19:42:05 | pixelma | linuxstb: I just can't remember a "remove track number guessing" commit since the time I'm aware of it but could have missed something. In case it is still in, I'm in favour of removing it |
19:42:13 | JdGordon| | completly remove the limits |
19:42:32 | pixelma | linuxstb: need to find something I could test with |
19:43:01 | kugel | I don't think chars for the *internal* representation are going to make it easier |
19:43:33 | JdGordon| | in gdb it will :) |
19:43:41 | | Join bertrik [0] (n=bertrik@d90-128-154-247.cust.tele2.nl) |
19:44:31 | * | JdGordon| wonders if Jeff Goode would be interested in doing the software mixer idea from ages ago to fix the no-talking-while-paused problem |
19:45:21 | kugel | JdGordon|: certainly if you take his eyes out |
19:45:29 | JdGordon| | haha |
19:45:38 | linuxstb | pixelma: Hmm, looking at the changelog for tagcache.c, it looks like you're right. Unless it was done elsewhere. |
19:46:22 | * | linuxstb edits his post |
19:46:30 | * | pixelma pings Slasheri maybe he can tell (and is around somewhat) |
19:47:18 | | Join Blue_Dude [0] (n=chatzill@adsl-235-222-153.mco.bellsouth.net) |
19:47:35 | linuxstb | pixelma: Yes, looking at the code, it still does tracknumber guessing... |
19:48:01 | pixelma | might give weird results on Ipods :\ |
19:48:06 | Blue_Dude | JdGordon|: you rang? |
19:48:11 | JdGordon| | oh hey |
19:48:15 | pixelma | and somwhere else too |
19:48:45 | bertrik | JdGordon, wasn't this also the difference between the paused and stopped state (one allows talking, the other does not)? |
19:48:50 | Blue_Dude | JdGordon|: What's broke again? Voice won't play while paused? |
19:49:03 | JdGordon| | bertrik: yes |
19:49:26 | kugel | Blue_Dude: that was always broken |
19:49:28 | JdGordon| | Blue_Dude: yeah, because voice + audio is mixed far too early |
19:49:56 | JdGordon| | there has been an idea for ages to keep them seperate and only mix them right ebfore thye get sent to the DAC |
19:50:27 | | Nick Omlet is now known as Omlet_Away (n=Omlet05@225.120-240-81.adsl-dyn.isp.belgacom.be) |
19:50:36 | JdGordon| | I tinhk jhmikes has a better idea of what was needed... he's not around thoguh :/ |
19:50:39 | Blue_Dude | JdGordon|: sounds promising, but it means pcmbuf and playback would need major rewrites. |
19:50:52 | JdGordon| | doesnt that sound like fun? :) |
19:51:01 | JdGordon| | why playback? |
19:51:10 | Blue_Dude | Sure, I'll knock it out this weekend. :) |
19:51:38 | JdGordon| | if its not too much trouble :) |
19:51:41 | Blue_Dude | Playback controls the low level pcm state. If it pauses, then nothing gets out. |
19:51:41 | linuxstb | pixelma: Unless I'm misunderstanding, the code seems strange. IIUC, it searches backwards from the "." part of the filename, and looks for two consecutive digits. If it finds them, they're used for the track number. |
19:51:57 | linuxstb | (exactly two digits) |
19:52:10 | JdGordon| | Blue_Dude: ok, although I would think that would be the easy bit of the whole thing to fix :) |
19:52:21 | kugel | Blue_Dude: playback wouldn't be involved if voice is seperate |
19:53:14 | kugel | I was thinking the voice wouldn't even reach the pcm buffer, but get a seperate one, voice and pcmbuffer then get mixed and sent to the hw |
19:53:17 | Blue_Dude | kugel: problem is that if playback forces the pcm state to pause, then nothing will get out. |
19:53:27 | | Quit bertrik (Read error: 104 (Connection reset by peer)) |
19:54:02 | Blue_Dude | In which case playback will need a rewrite to only control the playback buffer and not the PCM output buffer. |
19:54:23 | JdGordon| | the very high level idea was to have a seperate channel for each audio source (voice, crossfeed, audio) which could be individually pasued or played, and mixed at the last moment |
19:54:33 | pixelma | linuxstb: I remember reading a similar description in the forums where the track number guessing was discussed (someone wondered where a weird track number was coming from) |
19:54:38 | | Join efyx_ [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) |
19:54:44 | Blue_Dude | If you want to mix that late in the signal chain then a lot of assumptions on hardware state get thrown out the window. |
19:55:07 | kugel | ...is that good or bad? |
19:55:20 | Blue_Dude | It's good, but it means more than tweaking pcmbuf. |
19:55:39 | martian67 | bad if you dislike bug squishing ;) |
19:56:02 | kugel | moos: it works when you load it in the settings menu? |
19:56:41 | moos | negative, it doesn't. It fails. Let me share a zip |
19:57:09 | | Join bertrik [0] (n=bertrik@d90-128-154-247.cust.tele2.nl) |
19:58:00 | linuxstb | pixelma: From 4th April 2006 - "22.01.34 # <Slasheri> amiconn: hmm, true. that might work better. I will consider dropping that code" (I guess he never did...) |
19:58:22 | JdGordon| | damn irc logs wins again! |
19:58:42 | | Join avacore [0] (i=nobody@1008ds1-rdo.0.fullrate.dk) |
19:58:56 | pixelma | linuxstb: he just "considered" it ;) |
19:59:29 | | Quit bertrik (Remote closed the connection) |
20:00 |
20:01:08 | | Quit efyx_ (Remote closed the connection) |
20:01:23 | moos | here it is: http://www.mediafire.com/?4akgzgm3oiy |
20:02:14 | Blue_Dude | We'd need another layer of abstraction, one that is interposed between playback/pcmbuf and pcm.c. It could be called mixer.c and it would have sole authority over hardware states. It would also need to take over the PCM buffer, getting its input from the playback buffer (what is now called the PCM buffer) and the voice buffer. |
20:02:24 | kugel | mediafire is crap :( |
20:02:59 | JdGordon| | Blue_Dude: yay! more abstraction! |
20:03:02 | JdGordon| | sounds like fun |
20:03:43 | Blue_Dude | It could actually be simpler this way. pcmbuf and playback are hybrids. Maybe they could act more like APIs. |
20:03:59 | moos | kugel: where do you ant it? |
20:04:06 | moos | *want |
20:04:08 | JdGordon| | Blue_Dude: have a tihnk about it :) I just figured it would be good to get that idea into your head... I dont tinhk anyone else is interested in dsp-ish sort of stuff which i guess this is close to |
20:04:14 | kugel | moos: nevermind, worked now |
20:04:24 | moos | sorry :) |
20:04:34 | | Join efyx_ [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) |
20:04:53 | JdGordon| | moos: unless kugel finds the issue, can you email that to me? I'm at work so cant really do anything about it for a few hours |
20:05:09 | amiconn | I'd just mix voice in the isr that handles pcm, just a few samples at a time |
20:05:36 | moos | JdGordon: sure. Just 2sec... (the .gmail one, right?) |
20:05:50 | JdGordon| | yep |
20:06:06 | linuxstb | amiconn: On targets using audio DMA, isn't that about 32KB? Or could/would that size be reduced? |
20:07:22 | JdGordon| | although would doing late mixing make it harder to shrink the PCM buffer on low ram targets like the clip? |
20:07:29 | JdGordon| | and flash targets |
20:08:21 | moos | JdGordon: done |
20:08:40 | JdGordon| | rcvd |
20:09:32 | moos | JdGordon: Thanks to look at it |
20:09:49 | Blue_Dude | JdGordon|: well, really what's the benefit of having a huge output buffer? Why not whittle it down on all targets to something small, and keep the rest for music playback? |
20:10:37 | * | JdGordon| tihnks he is getting confused |
20:11:05 | kugel | Blue_Dude: it saves boosting |
20:11:56 | linuxstb | crossfade? |
20:11:59 | Blue_Dude | kugel: yes, but do you need to boost to keep the buffer from underrunning, or to process input? |
20:12:00 | kugel | not on avarage, but the process of boosting alone isn't free on many so few long boosts are better than lots of short ones |
20:12:21 | moos | Blue_Dude: on the DSP, no-do list, with have "low latency" too. It seems to not be easy task /me hides :) |
20:12:48 | kugel | the pcmbuffer would underrun on the majority of targets and codecs without boosting at refilling yes |
20:13:09 | | Quit efyx_ (Remote closed the connection) |
20:13:37 | | Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) |
20:14:52 | Blue_Dude | kugel: what I mean is, you can have two buffers here. One is a small one that is read by the hardware for output. Another one, much larger, is kept full with occasional boosting and represents playback content. |
20:15:07 | Blue_Dude | Still involves an extra memcpy though... |
20:15:11 | | Join bertrik [0] (n=bertrik@d90-128-154-247.cust.tele2.nl) |
20:16:07 | Blue_Dude | moos: low latency would be handled no differently than it is now. |
20:16:42 | | Join saratoga [0] (n=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-yhdjqmslnqzlrqam) |
20:17:06 | pixelma | Blue_Dude: would your suggestion affect buffering the voice file? |
20:17:09 | | Join Strife89 [0] (n=michael@168.16.237.214) |
20:17:47 | Blue_Dude | pixelma: it already is. I think it could just be mixed in later than it is now. |
20:17:51 | saratoga | i've emailed Buschel asking him how the heck you do an inverse quadrature mirror filter in less then a 100 MHz |
20:18:19 | saratoga | since he wrote one subband codec and once helped me optimize another, he will hopefully know this |
20:19:11 | Blue_Dude | The memory structure now is something like |−−−−−−−−−−−−−−−−PCM−−−−−−−−−−−−−−−−−−|CF|Vc|everything else| |
20:19:43 | pixelma | Blue_Dude: I mean, would you have to spin up to load other voice clips? (not sure how it is handled on swcodec currently though) |
20:19:49 | Blue_Dude | Why not |−−output−−|−−−−−−−−−−−−−−−−−−playback−−−−−−−−−−−−−−-|CF|Vc|everything| |
20:20:02 | kugel | yea, why not? |
20:20:16 | JdGordon| | because codecs arent all >100% realtime without boost |
20:20:21 | Blue_Dude | pixelma: dunno. |
20:20:23 | JdGordon| | so you have to have some PCM buffer |
20:20:50 | Blue_Dude | JdGordon|: yeah, but they'd boost to fill the playback buffer, not the hardware one. |
20:21:16 | kugel | man, just do it! :p |
20:21:18 | JdGordon| | playback is compressed audio or pcm? |
20:21:23 | Blue_Dude | PCM |
20:21:36 | Saline | Hi all. I'm doing my best to rape the plugin api. I'm calling a plugin (i've made reentrant) from screens.c, and get the following error message when compiling: ".text_0xfoo): undefined reference to |
20:21:39 | Saline | `rb` |
20:21:41 | | Quit elcan (Read error: 110 (Connection timed out)) |
20:21:45 | JdGordon| | ah ok, that would work on flash, but disk targets would be spinning up too often |
20:21:54 | Blue_Dude | Same as now, but instead of going right out, it's waiting to be mixed. |
20:22:14 | JdGordon| | alot more compressed sits in the buffer than pcm (obviously :) ) |
20:22:29 | kugel | what else? |
20:22:38 | Saline | my guess is that the structure isn't initialized somewhere, but i'd better ask for your help.. |
20:23:07 | kugel | Many stuff is packed into the audio buffer, I thought the pcm is for pcm (>decoded audio) only? |
20:23:29 | Blue_Dude | Well, codecs get their own input buffer. That wouldn't be affected. I had in mind splitting the current PCM buffer instead of taking from somewhere else. |
20:24:07 | kugel | I think that sounds good |
20:24:16 | amiconn | linuxstb: DMA chunks would need to be made smaller if that's the case |
20:24:48 | Blue_Dude | No idea how it would work in practive though. There's some overhead involved in mixing, but maybe that would wash out since filling the playback PCM buffer would be simpler. |
20:24:56 | Blue_Dude | -practice- |
20:25:13 | amiconn | With DMA, the DMA end isr could do the mixing, directly into a small DMA buffer, e.g. the equivalent of 10ms (1 tick), i.e. 441 samples when playing at standard frequency |
20:25:33 | amiconn | On ARM, the FIQ routine could do the mixing on the fly |
20:26:14 | Blue_Dude | amiconn: that's kind of what I was thinking. Something really small that would be easy to keep filled without a lot of overhead. |
20:26:52 | Blue_Dude | If all you need to do is mix two samples, and then copy the result to a memory location, that's about as easy as it gets. |
20:27:22 | JdGordon| | it could be more than 2 samples... |
20:27:43 | Blue_Dude | What else would you like? |
20:27:51 | Blue_Dude | Playback, voice... |
20:27:54 | JdGordon| | crossfade? |
20:28:09 | amiconn | Crossfade is done way earlier |
20:28:28 | Blue_Dude | Crossfade would be handled in playback. |
20:28:32 | amiconn | It doesn't need to be realtime, unlike voice |
20:28:40 | Blue_Dude | Bingo. |
20:29:02 | amiconn | The two streams need to be decoded sequentially anyway, because only a single codec can be active at a time |
20:29:22 | JdGordon| | oh.. another thing which would be nice is DSP controlled volume fading instead of using the output volume the way its done now |
20:29:37 | amiconn | More ifdefs? |
20:30:08 | Blue_Dude | Output volume is handled in hardware, yes? What needs to be fixed there? |
20:30:52 | JdGordon| | fading currently doesnt work with line out |
20:30:57 | amiconn | Fade on stop/pause is done using master volume. This has the advantage that it works for both hwcodec and swcodec |
20:31:14 | amiconn | JdGordon|: That's target dependent; you can't say that in general |
20:31:25 | JdGordon| | ok |
20:31:33 | Blue_Dude | That's so late in the signal chain that it would affect voice, too, no matter where you mixed it in. |
20:32:23 | | Join RyoS [0] (n=ryo@cl-1804.ham-01.de.sixxs.net) |
20:32:31 | RyoS | hi all :) |
20:32:55 | amiconn | That's true, but then this fade isn't very long |
20:33:07 | RyoS | im in search for an collection (zip/tar) of anti aliased fonts |
20:33:34 | RyoS | if there is something like that? i use (test) the patch kugel posted on flyspray :) |
20:33:36 | JdGordon| | you're apparently lost then |
20:34:03 | Blue_Dude | amiconn: maybe fade could be inhibited if voice is currently being mixed in. That seems reasonable. |
20:34:33 | amiconn | There are some advantages for doing the fading in pcm, but that at least requires splitting hwcodec and swcodec here |
20:34:48 | JdGordon| | with really late mixing you could do fun stuff like makign the audio quieter if voice is happenign at the same time yeah? |
20:35:20 | amiconn | Also, this fade needs to be kinda realtime, like voice, and unlike crossfade. |
20:35:23 | JdGordon| | or is that done already? |
20:35:31 | Blue_Dude | JdGordon|: in fact, that would be required unless you wanted to clip the output. |
20:35:36 | amiconn | Rockbox cannot know in advancce when the user presses pause or stop |
20:37:22 | Blue_Dude | amiconn: please refresh my memory. All this affects only swcodec targets, correct? hwcodec targets already do their own thing? |
20:37:49 | amiconn | Hwcodec cannot mix music and voice, since there's only one decoder |
20:38:23 | amiconn | So voice is simply muted while music is playing. No crossfade as well, for the same reason |
20:38:31 | Blue_Dude | amiconn: I have to experience with hwcodec targets, so I don't know how they're implemented. |
20:38:39 | amiconn | Fade on stop/pause works on them, because it uses master volume |
20:38:39 | | Quit bertrik (Read error: 104 (Connection reset by peer)) |
20:38:53 | Blue_Dude | So Rockbox is pretty much a front end on those targets? |
20:39:01 | amiconn | Hmm? |
20:39:14 | Blue_Dude | −− I have *no* experience −− |
20:39:46 | | Join Tristan53 [0] (i=tristan@66.252.24.153) |
20:39:54 | Blue_Dude | A front end, meaning mostly a new interface. |
20:40:14 | amiconn | Rockbox is a complete replacement firmware on all targets it supports. On hwcodec just the actual audio decoding doesn't happen on the main cpu, but on a preprogrammed dsp |
20:40:36 | pixelma | Rockbox is a replacement firmware as it is on other targets too, just playback works differently due to different hardware systems |
20:40:43 | * | pixelma too slow |
20:40:49 | Blue_Dude | :) |
20:41:49 | pixelma | Blue_Dude: and Rockbox was first developed on (for) these targets |
20:42:07 | Blue_Dude | Sure, Rockbox is a complete firmware replacement, but it can't do any signal manipulation because it doesn't have custody of the signal chain? |
20:42:23 | * | Blue_Dude needs to read up on his history. |
20:42:38 | amiconn | While the dsp is preprogrammed to decode mp2/mp3 (and on some of these targets, also encode mp3), it can also be reprogrammed |
20:43:28 | amiconn | That's rather difficult because it's a custom dsp core with no public docs |
20:43:58 | amiconn | But after several years, we got the pcm pass-through codec for it from archos+micronas with official permission to use it in rockbox |
20:44:31 | amiconn | This is currently only implemented in plugins and not integrated into the main playback engine on hwcodec |
20:44:43 | kugel | moos: the original free state works |
20:44:45 | * | amiconn has some ideas how this could be done |
20:45:17 | Blue_Dude | Ah, that's where I'm going with it. Does the pcmbuf code need to address hwcodec targets? |
20:46:04 | amiconn | No, that code is swcodec only, and will stay that way |
20:46:26 | moos | kugel: I slightly modified it, to fit my needs. |
20:46:36 | kugel | what did you change? |
20:46:39 | amiconn | Hwcodec will get a different low-level module, but I'll try to reuse buffering (app level) |
20:47:08 | | Quit flydutch ("/* empty */") |
20:48:24 | moos | kugel: I don't remenber well, but I think I just riped infos that I don't need |
20:48:51 | Blue_Dude | amiconn: I guess that's the real question: should hwcodec targets be addressed in a pcm code rewrite to allow them to receive processed audio? |
20:48:54 | | Quit Strife89 ("Goin' home momentarily.") |
20:49:01 | amiconn | no |
20:49:07 | Blue_Dude | ok then |
20:49:21 | kugel | moos: I think it lacks a 's' image |
20:49:56 | kugel | I see %xds, but no corresponding image |
20:50:08 | Blue_Dude | So we're talking swcodec only. Which mean that files in apps/ are fair game, but not firmware/ |
20:50:19 | amiconn | The pcm code isn't used on hwcodec atm, and it won't be used in the future either. The MAS has several special needs which need to be catered for in the new low-level module (e.g. switching between pcm mode for waw/aiff playback and mpeg mode for mp2/mp3 playback) |
20:50:59 | | Join bertrik [0] (n=bertrik@d90-128-154-247.cust.tele2.nl) |
20:51:12 | amiconn | Due to the CPU all data fed to the MAS needs to be bitswapped, that's another thing that will be handled there (and no longer in buffering) |
20:51:41 | Blue_Dude | Just trying to get an idea of the scope involved here. |
20:51:55 | kugel | moos: it seems you've mostly taken out some images. You need to remove their references as well |
20:54:42 | Blue_Dude | Mixer.c would have to do all the memory management too... Just thinking aloud... |
20:55:29 | Blue_Dude | Or maybe it would just be assigned a memory pool and it would divvy it up as it needs to. |
20:55:33 | Blue_Dude | Yeah... |
20:55:59 | moos | kugel: but why all was good before? I will anyway thanks |
20:56:20 | kugel | maybe JdGordon| accidently fixed a bug :) |
20:56:24 | JdGordon| | moos: its been made slightly stricter apparently |
20:56:30 | * | JdGordon| slaps kugel |
20:57:03 | moos | aie :( then that will break a lot of wps then |
20:57:33 | JdGordon| | it will? |
20:57:37 | pixelma | why that? |
20:58:10 | JdGordon| | I do find it slightly humerous that the only people to complain about not working .wps are devs :) |
20:58:22 | moos | I think to people like me (not a wps author) that used a wps since a while and all worked and now no, then yes :) |
20:59:21 | pixelma | I also didn't get all the "my WPS is broken" when the parser was made stricter wrt to escaping <|> |
20:59:35 | pixelma | the rules were laid down before |
20:59:36 | JdGordon| | moos: would you prefer a hard crash (null pointer) or not loading wps? |
21:00 |
21:00:20 | pixelma | moos: I don't think it will be many people who just delete the %xl tags |
21:00:28 | pixelma | or some of them |
21:00:51 | moos | surely not. I don't complain, I just warn, that we could have few users encountering the same |
21:01:11 | JdGordon| | I wonder how hard a .wps verifier plugin would be on target |
21:01:51 | moos | But sure that a more strict parser is nice at end... |
21:07:33 | | Join elcan [0] (i=user36@massdeop.us) |
21:08:54 | | Nick Omlet_Away is now known as Omlet (n=Omlet05@225.120-240-81.adsl-dyn.isp.belgacom.be) |
21:09:50 | | Quit Omlet () |
21:09:55 | | Join TruthTaco [0] (n=truthtac@adsl-67-33-118.aby.bellsouth.net) |
21:10:12 | kugel | JdGordon|: you better think harder why the images don't work on my sb |
21:10:28 | JdGordon| | or else? |
21:11:06 | JdGordon| | get it going in gdb and find out where exactly its failing.. |
21:11:15 | JdGordon| | is it the bmp_read_file()? |
21:11:18 | JdGordon| | or before that |
21:11:38 | kugel | after |
21:11:48 | kugel | I'm in skin_display already |
21:12:24 | kugel | evaluate_conditional() -> find_image |
21:12:37 | RyoS | kugel: do you have a collection of aff fonts? i am trying your patch on iaudio x5 :) |
21:13:24 | kugel | RyoS: nope. converting fonts is easy |
21:13:29 | | Join merbanan [0] (n=banan@c-83-233-172-245.cust.bredband2.com) |
21:13:37 | RyoS | mh, ok ;) |
21:13:56 | RyoS | for; do; done, got it ;) |
21:13:59 | kugel | Blue_Dude: ...use the build system |
21:14:54 | Blue_Dude | Thanks, Obi-Wan! |
21:16:13 | *** | Saving seen data "./dancer.seen" |
21:16:17 | Llorean | kugel: Are you seriously encouraging someone not to bother testing, but just go ahead and break user builds? |
21:16:23 | kugel | yes |
21:16:34 | Llorean | Why? |
21:16:37 | JdGordon| | kugel: being at work i cant really help... have a look and make sure wps_data->images is getting populated correctly |
21:16:48 | JdGordon| | and yes, building all tagrtes locally is a huge waste of time |
21:16:54 | JdGordon| | the build system works well for that |
21:17:09 | Llorean | JdGordon|: Not all targets, but he *knows* it's likely to break targets with different size IRAM, so he should check a few of those at least |
21:17:16 | Blue_Dude | Llorean: I wasn't gonna commit without being reasonably sure it wasn't going to break something. |
21:17:19 | Llorean | Like the Gigabeat F |
21:17:21 | kugel | What's the point of doing it locally if there's 60 monsters just waiting for doing the job? |
21:17:43 | pixelma | I don't like that attitude if you expect problems, do at least some test builds of a selection of different targets (like coldfire or arm here) |
21:17:43 | JdGordon| | moster is a bad word :) isnt that the 2nd slowest client :D |
21:17:44 | kugel | producing a red build isn't a problem at all |
21:17:47 | Llorean | kugel: The point is if you know it's going to break something, you shouldn't push it out to users. The build system's other job is to make sure users have access to the latest binariers. |
21:18:08 | JdGordon| | if the build breaks the users cant get it.. |
21:18:21 | kugel | Llorean: We're talking about red builds, not broken code (as in semantically broken), aren't we? |
21:18:23 | Llorean | JdGordon|: That's the point, it means we're distributing different versions to different users. |
21:18:28 | kugel | users won't even get to download a red build |
21:18:42 | Llorean | kugel: Obviously not all the builds will be red, since it works in his local case. |
21:19:09 | kugel | "distributing different versions" that argument is just stupid |
21:19:18 | Llorean | Ah yes, back to "discussion by insult" |
21:20:20 | pixelma | kugel: yours isn't even an argument as it doesn't give explanations just an opinion out of thin air |
21:20:24 | kugel | the red is most likely fixed within 10 mins, what's the problem with that? That's so insignificant, why even bother with doing multiple builds |
21:20:36 | Llorean | kugel: Most likely based on what? |
21:20:52 | * | JdGordon| kicks kugel and Llorean to pm |
21:20:52 | Blue_Dude | Llorean: I will try a representative sample first. I just didn't want to sit on the patch forever for fear that one out of 60 builds would go red. |
21:21:24 | JdGordon| | the sample in the ml thread is a good one |
21:21:27 | Llorean | Blue_Dude: The obvious solution is to go to the -dev list with "On targets with small IRAM it probably won't build. Could someone help me with what these are?" or similar |
21:21:41 | pixelma | JdGordon|: why that? Apparently you had to say something about it too |
21:21:43 | Llorean | Blue_Dude: You can ask for help in identifying where it might have problems. |
21:21:56 | Blue_Dude | Llorean: done that. Working on it ever as we speak. |
21:21:58 | JdGordon| | pixelma: because its a boring argument |
21:22:00 | Blue_Dude | even |
21:22:20 | | Join Kopfgeldjaeger [0] (n=nicolai@monitor-mode-enabled-on-mon0.phy0.de) |
21:22:45 | | Join funman [0] (n=fun@rockbox/developer/funman) |
21:23:06 | Llorean | Blue_Dude: But the build system makes builds immediately available to users, and if there are red builds that means a disparity between what some users download and other users download. We've gotten bug reports because a download didn't match what was supposed to be the current version before. |
21:23:36 | | Join FOAD_ [0] (n=dok@dinah.blub.net) |
21:24:12 | funman | there is also a contest for the developer who'll make the most red points, but beating the high score isn't necessarily a good thing ;) |
21:24:19 | Blue_Dude | Llorean: No way I'm going to build 60 versions. I'll pick the ones most likely to have problems and build those. After that, I'll fix reds if they happen. |
21:24:46 | JdGordon| | Llorean: that arguemnt isnt really valid anymore... we except most users to use the releases |
21:24:51 | pixelma | Blue_Dude: no-one expected you to test build everything |
21:24:56 | Llorean | Blue_Dude: I didn't say build 60 versions. But kugel's apparently been advocating "don't worry about it and let the build system show you" |
21:24:57 | Blue_Dude | Oh good. |
21:25:01 | Llorean | Which is very irresponsible toward the users. |
21:25:04 | | Join Stephen__ [0] (n=S@86-40-186-162-dynamic.b-ras2.srl.dublin.eircom.net) |
21:25:25 | kugel | so what |
21:25:29 | Blue_Dude | Well, yes, but if you've been following the -dev list, I have been requesting input. And I got it, so don't worry about it. |
21:25:37 | funman | building 4 or 5 targets different enough is enough to see anything obvious |
21:25:48 | kugel | I really don't care if a user or two download a SVN-1 build |
21:25:48 | Llorean | Blue_Dude: Yeah, but nobody suggested low-IRAM targets |
21:25:58 | Llorean | The list you got was the standard "each CPU and most disk types" |
21:26:16 | kugel | but I do care on not wasting time on doing something that a whole farm of computers does in 3-4 minutes |
21:26:57 | Llorean | kugel: You could always get to work on a test build system that doesn't affect users, then. |
21:27:01 | Blue_Dude | Llorean: I already test built on the h140. It worked great. What else should I try? |
21:27:22 | Llorean | Blue_Dude: If I recall the Gigabeat F has no IRAM (or so little as we don't use it) |
21:27:30 | Llorean | So you're almost certainly going to need an alternative solution there. |
21:27:40 | Llorean | Or maybe it's the other Gigabeat. |
21:27:50 | funman | the gigabeat F 'iram' sections are put into dram if they use the correct attribute (IBSS_ATTR and similar) |
21:27:52 | Blue_Dude | Llorean: then it will likely ignore the IRAM attributes and run slowly. |
21:28:15 | Blue_Dude | funman: that too. :) |
21:28:28 | markun | not that slowly I think |
21:28:38 | markun | the cache makes up for the lack of iram |
21:28:40 | funman | there is no noticeable speed difference between iram and dram on sansa ams |
21:28:49 | Llorean | Blue_Dude: But my point is, why don't you check which ones have the least iram and try those? |
21:28:58 | Llorean | Isn't the amount defined somewhere anyway? |
21:28:58 | funman | iram is perhaps 25% faster without caching |
21:29:13 | funman | in the linker scripts |
21:29:37 | kugel | funman: I only had 7% speed up from putting the lcd framebuffer into iram |
21:29:44 | Blue_Dude | OK, great, which are those targets and I'll do it. Really. |
21:30:08 | funman | kugel: it was before we enabled the caches, right? |
21:30:22 | linuxstb | Blue_Dude: Just write a little script and build them all. It would be quicker than arguing about it... |
21:30:42 | Llorean | linuxstb: All targets would take forever, he's right. |
21:30:51 | Blue_Dude | linuxstb: it would take all day. |
21:30:53 | kugel | funman: yea |
21:30:56 | Blue_Dude | What he said. |
21:30:56 | * | JdGordon| agrees with chopper read.. "harden the fuck up" and commit :D |
21:31:04 | | Quit pamaury ("exit(*(int *)0 / 0);") |
21:31:20 | linuxstb | Blue_Dude: Or all night... You don't have to be there when they're running. |
21:31:22 | Llorean | But he knows the circumstances problems are likely under. Low-IRAM targets. |
21:32:01 | | Join AndyI [0] (i=AndyI@212.14.205.32) |
21:32:36 | | Quit FOAD (Read error: 145 (Connection timed out)) |
21:32:37 | | Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) |
21:32:42 | Blue_Dude | Anybody know which targets are low-IRAM? |
21:32:53 | Llorean | Blue_Dude: I think funman said it's in the linker script |
21:33:23 | | Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
21:33:29 | kugel | buggers, just let him commit and fix any problems afterwards. I really fail to see the problem with *possibly* producing read (if he's having a plan for fixing that is) |
21:34:33 | kugel | demanding him to not only do multiple builds, but also scan through the source, is absurt, IMO |
21:34:35 | pixelma | shows some maturity |
21:34:56 | Blue_Dude | OK, I can't commit this minute. I'll try a few test builds first. My lawn needs mowing anyway so it'll have to wait. |
21:35:20 | Llorean | kugel: Yes, but you've seen what happens when a red *doesn't* take a short time to fix, and then the person who can fix it has to run off for some reason |
21:35:32 | Llorean | If you know where a problem is *likely* you should try to fix it in advance. It's just sound to do so. |
21:35:34 | rasher | I don't think using the build system as a test build is a terrible offence, as long as you're alert to it and planning to either fix or revert within say, an hour |
21:36:11 | | Quit KBH (Read error: 54 (Connection reset by peer)) |
21:36:15 | | Join HBK- [0] (i=hbk@rrcs-97-77-53-84.sw.biz.rr.com) |
21:36:24 | kugel | indeed |
21:36:24 | * | Blue_Dude fires up the mower. |
21:36:46 | Blue_Dude | I'll check back this evening and go from there. Thanks, guys. |
21:37:21 | Llorean | rasher: There's a difference between "using it to check for unknown problems" and "I think I know what will be a problem already but haven't tested it for some reason" though |
21:38:16 | linuxstb | rasher: But that just creates a mess in the svn history... There's no excuse for not doing multiple builds yourself as a test - that's NOT the job of the build system IMO. |
21:38:25 | | Quit pixelma (Nick collision from services.) |
21:38:26 | | Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) |
21:38:29 | | Quit amiconn (Nick collision from services.) |
21:38:31 | | Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) |
21:38:43 | | Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) |
21:38:47 | * | markun agrees with linuxstb and Llorean on this one |
21:38:51 | | Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) |
21:39:04 | Llorean | If the build system is supposed to be used for "now let's see what breaks so I can continue working" we should create an alternate one just for that |
21:39:08 | RyoS | kugel: cant compile convttf.. -> http://nopaste.com/p/aeG6hGzYcb |
21:39:15 | Llorean | It's idle often enough that the current network could probably deal with the cases where that's needed. |
21:39:21 | RyoS | using the latest posted source file |
21:39:27 | rasher | Meh, if it's reverted it won't show up in the history unless you're looking for it. |
21:39:50 | markun | rasher: it will in my git history :) |
21:40:02 | kugel | RyoS: seems you need to link some lib, try to add -lm |
21:40:35 | * | JdGordon| points out that really.. its more liely to cause issues on low IRAM targets than just build breaks :) |
21:40:38 | RyoS | kugel: works ;-) |
21:40:46 | linuxstb | rasher: It also means non-atomic commits - main commit, then "fix red", then "fix red", then "oops, forgot something, fix more red"... I just think SVN needs to be treated with respect, and not as someone's personal workspace. |
21:41:26 | JdGordon| | maybe we shold be using git then! |
21:41:32 | Llorean | JdGordon| used to have a build system up somewhere that you could upload a patch to, then compile, right? |
21:41:33 | kugel | nice idea |
21:41:47 | JdGordon| | kugel: make sure you send me a patch or put it on FS before you give up for the night.... |
21:42:08 | JdGordon| | Llorean: yes, but only on a chosen target |
21:42:55 | Llorean | JdGordon|: But it's the basic idea we need. Upload a diff of your changes, and the build system builds and discards a build from it and clean SVN without an SVN update, and gives you breakage stats. |
21:42:57 | kugel | JdGordon|: of course.. |
21:43:09 | kugel | I don't think I'm heading to bed before you're going home anyway :p |
21:43:23 | pixelma | I find the discussion a bit weird, my reason for testcompiling is that I want it to look as perfect as possible... |
21:43:25 | JdGordon| | Llorean: yeah, that would be nice |
21:43:57 | JdGordon| | what is the saying "perfection is the enemy of <something?>" |
21:44:23 | Llorean | "getting enough sleep" I imagine. |
21:45:07 | pixelma | JdGordon|: if you have something against striving for perfection... it would explain things ;P |
21:45:18 | RyoS | kugel: sorry to bother you.. i either get an error ("Could not reset device") or segfault |
21:45:30 | JdGordon| | pixelma: perfection is going backwards for me :D |
21:45:42 | kugel | RyoS: no idea, I'm not really into that patch anymore |
21:45:52 | RyoS | oh, i see |
21:48:42 | | Join Zagor [242] (n=bjst@46.35.227.87.static.tab.siw.siwnet.net) |
21:49:39 | saratoga | a way to use the build system without doing an SVN commit would be nice |
21:49:47 | | Quit funman ("free(random());") |
21:50:01 | Unhelpful | JdGordon: "perfect is the enemy of good" iirc |
21:50:19 | * | Unhelpful agrees with saratoga on that |
21:50:55 | Zagor | saratoga: rebuilding an old revision? |
21:50:59 | saratoga | one way to do it would be to have a branch of the main tree thats updated concurrently with the main tree but doesn't update the download serer |
21:51:17 | Unhelpful | i try to test a sim for each of mono/greyscale/color, plus my two devices, and a build for a target of each processor family, but that's about where i stop, generally. |
21:51:22 | JdGordon| | it will have problems where a patch adds a file |
21:51:26 | saratoga | just someone way to test builds on all targets without doing a commit or waiting hours for all of them to run |
21:51:32 | saratoga | "some way" |
21:52:02 | Unhelpful | JdGordon: i think that problem i had with your patch was only because the "add" was a "move and edit" |
21:52:14 | Zagor | saratoga: testing uncommitted changes? |
21:52:37 | saratoga | Zagor: yes, above in the logs it was commented that we too often test builds by commiting them, making a mess of teh SVN tree |
21:52:38 | JdGordon| | Unhelpful: no, adds (unless they are deleted after) will cause problems when you try to apply the patch again |
21:53:00 | saratoga | the obvious solution to this is to have a way to use the build system without making a build |
21:53:05 | Unhelpful | JdGordon: trying to apply *any* patch twice is a fail |
21:53:19 | saratoga | since most of us are not easily able to run a hundred test builds on our local machines in a reasonable amount of time |
21:53:20 | JdGordon| | well yes |
21:53:22 | Zagor | saratoga: I'm not sure I agree we have a problem |
21:53:47 | JdGordon| | I also think its not an issue... this isnt something which comes up very often |
21:53:58 | JdGordon| | and the red builds are when we dont expect them anyway |
21:54:42 | Unhelpful | if we had the ability to remove commits from the history entirely we could do the build first and then delete the revision if it's red ;) |
21:54:43 | saratoga | Zagor: well I don't really mind adding major changes in two commits, but it was suggested that its bad |
21:55:49 | pixelma | hmm? Who suggested that? |
21:56:02 | Zagor | I don't think "fix red" commits happen nearly often enough to consider it a problem |
21:56:25 | pixelma | the disussion was about "just commit it and see what happens" if someone already expects problems |
21:56:33 | JdGordon| | Zagor: except in short bursts :) |
21:56:36 | saratoga | Blue_Dude: regarding IRAM, coldfire device all have it [H100, h300, iaudio X/M], all PP [too many to name], all AMS [newer Sansas] and some of the other new targets [TCC] |
21:57:15 | pixelma | saratoga: the question was for low IRAM targets |
21:57:23 | JdGordon| | kugel: fixed it yet?! i'm cursios to see screenshots |
21:57:24 | Zagor | pixelma: I agree that's a too lazy approach. but that is fixed by yelling at the lazy bum, not by me spending 50 more hours on the build system ;) |
21:57:31 | kugel | no |
21:57:36 | JdGordon| | SLACKER! |
21:58:00 | saratoga | pixelma: I don't think theres really a distinction |
21:58:18 | saratoga | all low IRAM targets don't have the IRAM defines enabled |
21:59:07 | | Quit LambdaCalculus37 () |
21:59:31 | saratoga | unless you count 96KB as low, since those are the smallest that have the IBSS defines enabled AFAIK |
21:59:55 | | Join raphi [0] (n=raphi@pub082136118205.dh-hfc.datazug.ch) |
22:00 |
22:00:17 | pixelma | saratoga: is there a place you can look this up? |
22:00:25 | kugel | JdGordon|: I'm having weird problems with a debug field I added to wps_data, I set it to true in init, but it's false while parsing |
22:00:40 | saratoga | pixelma: probably just the source code |
22:01:04 | Unhelpful | what kind of threading tools do we have for targets with COP? i understand that we do rather a lot of the multi-core stuff just by using cacheline-sized-and-aligned data that is unique to each core, or uncached data, but we obviously have some things for communicating between them? |
22:01:25 | saratoga | actually archos should also have IRAM enabled, but its not SWCODEC so that shouldn't matter |
22:01:43 | pixelma | yes, but is there (a) certain file(s) where you can find which target has what? |
22:01:59 | * | Unhelpful is still stuck on making buffer compactible :) |
22:02:05 | saratoga | Unhelpful: theres a bunch of functions for synchronisation, stuff like queues, semiphores, etc |
22:02:05 | pixelma | or maybe which arch |
22:02:28 | | Join efyx_ [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) |
22:02:42 | saratoga | i think you'd have to look at the config-xxx.h files for your target and see what they define, or else look at the linker script section pertaining to your player |
22:02:57 | saratoga | but i am not an expert on that part of firmware so I could be wrong |
22:03:01 | Unhelpful | saratoga: and all of those work just as well between cores as they do between processes on one core? certain assumptions can obviously only be made in the latter case. |
22:03:21 | saratoga | Unhelpful: at least on PP they are meant to be used for multicore stuff |
22:03:35 | saratoga | i wrote versions of the mp3 on cop patch that used a few different structures for IPC |
22:04:12 | saratoga | http://www.rockbox.org/tracker/task/9318 |
22:04:30 | kugel | "data in init: 0x817cc00, .debug: 1" vs "data in parser: 0x817cc00, .debug: 0" −− I don't understand this :( |
22:05:40 | saratoga | Unhelpful: see the v6 patch and onward |
22:06:07 | JdGordon| | kugel: the data struct is zerod in init... |
22:06:38 | kugel | where? I set it to true at the end of the init function |
22:07:09 | Unhelpful | the basic plan i think *might* work is to have the buffering thread set a flag (via some thread-safe method) that indicates a compaction is needed, and to have the codec check the flag, stop everything including its COP threads, and wait for an event signalling compaction has completed |
22:09:04 | Unhelpful | telling buffering that it's OK to start compaction, and telling codec that compaction is complete, is probably easy to do via an event queue... i'm not sure about signalling need for compaction, that needs to be very close to free when the flag is unset |
22:09:46 | | Part Grahack |
22:09:48 | JdGordon| | kugel: you'll have to search yourself... skin_data_load maybe |
22:10:18 | kugel | ahh |
22:10:21 | kugel | alright |
22:11:01 | Unhelpful | kugel: did you figure out whatever the trouble was in font antialiasing? |
22:11:20 | bertrik | markun, the m6 seems to use a different magic FTL signature than both the openiboot code and the samsung yp-s3 |
22:11:47 | bertrik | strings indicate it's Whimory v2.1.2, the Samsung yp-s3 uses Whimory v2.2.0 |
22:11:49 | kugel | Unhelpful: I just know that mpegplayer doesn't do it on LCD_PORTRAIT, and adapting is non-trivial (for me...) |
22:12:20 | saratoga | Unhelpful: which codecs need this? |
22:12:24 | Unhelpful | kugel: ah, mpegplayer wants rotated text drawing on LCD_PORTRAIT |
22:12:28 | saratoga | it seems like it'd be very complicated to make work |
22:12:44 | pixelma | Unhelpful: that everything looks blurry ;) |
22:13:42 | Unhelpful | saratoga: it's not for codecs themselves, but as a solution for several other things... the main goal is to be able to move any items in the buffer during playback. |
22:14:07 | kugel | s/is to be able to move any items in the buffer during playback./add malloc()/ |
22:14:17 | kugel | ;) |
22:14:37 | Unhelpful | kugel: hey, now. also to be able to move the buffer ends during playback |
22:15:08 | Unhelpful | but a more malloc-y buffer would stop us having to rebuffer if the AA size changes |
22:15:24 | JdGordon| | I'm pretty sure moving buffers around is not part of the malloc spec.. |
22:15:35 | JdGordon| | realloc is different |
22:16:54 | markun | bertrik: and are these all completely different? |
22:17:29 | bertrik | the names of the Whimory functions and even parts of code look very similar |
22:19:23 | bertrik | the openiboot code seemed to refer to some strings that should be present in the flash (e.g. "BBT" for the bad block table), I can't find those in the meizu or samsung firmwares, but otherwise the meizu and samsung FTLs look quite similar |
22:19:34 | | Join _lifeless [0] (n=lifeless@90.151.217.179) |
22:19:46 | Unhelpful | JdGordon: the virtual addresses that the caller sees in an OS with VM can't change, since malloc gives a direct pointer to the allocated space. but moving the physical address and changing the mapping is something that can happen. |
22:20:50 | linuxstb | bertrik: The Nano2G code contains strings such as "c:\bwa\N36Firmware-38\srcroot\Firmware\Shared\Services\hwapi\soc\samsung\nand\Whimory2_1\core\VFL\VFLBuffer.c" which would suggest 2.1 |
22:21:56 | Unhelpful | VM is not always an option for us... and is probably more than we really need most of the time |
22:24:08 | | Quit bertrik ("boot to linux") |
22:24:17 | Unhelpful | actually... is the position saved when we stop/resume playback sample-accurate? |
22:24:38 | kugel | JdGordon|: ok, parse_image_load() is fine (the image gets his id). But later in displaying, it can't find that id in find_image() |
22:24:42 | | Join FOAD_ [0] (n=dok@dinah.blub.net) |
22:25:40 | kugel | as soon as I start playback it seems to be lost (and I can't show the statusbar before) |
22:25:48 | Unhelpful | it may be that we could simply add a "don't-really-stop" operation that works just like a stop, but doesn't do a fadeout or flush buffers |
22:26:00 | | Join bertrik [0] (n=bertrik@d90-128-154-247.cust.tele2.nl) |
22:26:19 | | Quit merbanan (Read error: 110 (Connection timed out)) |
22:26:23 | Stephen__ | babe ? |
22:26:27 | Stephen__ | ooops |
22:26:37 | kugel | I'm wondering if the wps is overwriting our stuff |
22:27:26 | kugel | wps_data seems to be healthy, but the linked list not |
22:28:57 | Unhelpful | kugel: add some canary data before/after the LL so that you can see when it gets trashed? |
22:29:25 | bertrik | "canary data"? :) |
22:29:45 | bertrik | Is that the same as "cookies"? |
22:30:17 | kugel | it's data made in canada I think ;) |
22:31:14 | Unhelpful | bertrik: maybe? unimportant memory segments filled with known values that you can use to detect overwrites. like taking a canary in a cage into a mine with you, in the hope that if you get into anything unsafe to breath, it will die while you still have time to get out? |
22:31:45 | bertrik | I'd love to see something like that in rockbox |
22:32:04 | bertrik | we do that for the stacks already I think |
22:33:07 | Unhelpful | we can actually do better on our MMU targets, by putting no-write mappings on either end instead of padding and testing |
22:34:27 | saratoga | Unhelpful: how hard would that be to try? |
22:34:43 | bertrik | the AMS targets currently have a rather simple MMU setup, with properties defined with a granularity of 1 MB |
22:34:46 | saratoga | i'd love to know if buffers get overwritten on AMS |
22:34:50 | Unhelpful | saratoga: i really have no idea, i don't know how exactly the MMUs we have work |
22:35:26 | bertrik | the MMU is very well documented (although I don't know exactly which document) |
22:35:59 | kugel | they're all the same, basically. only the beast's one uses different code |
22:36:23 | Unhelpful | as i understand things on x86 you can only set these flags with page granularity. if we can do mapping with smaller sizes and alignments, and one-to-many mappings, we could potentially reuse one non-writable, non-readable page to trap buffer overruns anywhere we want... |
22:37:00 | Unhelpful | hrm, if you're not allowed to read or write, does the mapping need to be to a valid physical address? |
22:37:14 | bertrik | I'd start with simpler non-MMU protection canaries/cookies first |
22:37:24 | | Join efyx__ [0] (n=efyx@lap34-1-82-224-140-171.fbx.proxad.net) |
22:38:22 | | Quit FOAD (Read error: 110 (Connection timed out)) |
22:38:23 | | Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) |
22:39:28 | Unhelpful | bertrik: those aren't necessarily easier, you have to test them often for them to be useful, and to know what's happened since the last test, or else you only know *that* the data has been trashed... which you know anyway, when important data was being corrupted before you added the canary |
22:40:10 | bertrik | and I'd like to add checks on uninitialised structs (e.g. mutex and wakeup) and checks on the proper context (e.g. detect when a kernel function is called in interrupt context when not allowed) |
22:40:24 | | Quit efyx__ (Client Quit) |
22:40:52 | bertrik | *I* think it's easier: no integration with an MMU needed |
22:41:45 | JdGordon| | kugel: you *are* giving the statusbar gui_wps->datas new wps_data structs riught? |
22:41:49 | bertrik | Not all targets have an MMU anyway (although I don't know exactly which ones do and which ones don't) |
22:41:53 | saratoga | we could probably just align the buffer to the edge of a couple dozen MMU pages and then just wait to see if it goes out of them though |
22:42:00 | kugel | JdGordon|: yea, I only share wps_state |
22:42:37 | Unhelpful | bertrik: easier to implement the canary itself, but not very easy to get useful debugging data from. you'll need to be able to get a trace of all threads executed since the last time the canary data was checked... or else you still don't know what went wrong. |
22:42:58 | Unhelpful | doing it with a mapping that forbids access means that you get a fault when the bad code executes |
22:43:04 | bertrik | Unhelpful, we can check the canaries on thread switch, this should give a pretty good idea of the offender |
22:43:22 | bertrik | Unhelpful, but what about targets without MMU? |
22:44:03 | Unhelpful | bertrik: that's pretty good, actually, and i assume we can tell where the yield or sleep that caused the switch happened? |
22:44:51 | kugel | hrm, I don't even need to start playback. |
22:44:55 | Horscht | hm... |
22:45:02 | Horscht | I am slightly confused... |
22:45:36 | Horscht | I installed the latest current build on my ipod video 80GB, but I noticed it buffers every 5 - 6 songs instead of 10 - 12 how it used to be |
22:45:37 | saratoga | what about just doing it on x86? most of the code we'd want to debug is run on the sim as well |
22:45:49 | saratoga | i doubt anyone is going to want to debug something like a driver anyway |
22:46:04 | Horscht | checking the "rockbox info" in the debug menu shows only 28Mb of buffer, i do have 64Mb, though |
22:46:21 | JdGordon| | you installed the 32MB build then |
22:46:41 | bertrik | Unhelpful, I guess we can figure that out (not 100% sure) |
22:47:03 | Horscht | jDGordon no |
22:47:12 | JdGordon| | yes! |
22:47:28 | Horscht | rockbox-ipodvideo64mb |
22:47:39 | Zagor | Horscht: which revision was it? |
22:47:51 | Horscht | r22381 |
22:48:05 | kugel | skin_data_load for wps seems to destory the linked list for the sb |
22:48:36 | JdGordon| | dodgey pointers somewhere? |
22:48:37 | Zagor | Horscht: that is built for 32MB. fixing... |
22:49:09 | JdGordon| | kugel: is this all a copy+paste error? :D |
22:49:22 | Horscht | ah. I was just firing up my ubuntu VM to try to compile myself |
22:49:29 | kugel | I don't think so |
22:50:16 | Zagor | rasher: can the log entries be checked for updates in your graph.php? sometimes I re-run rounds and I want to see the new result. |
22:51:07 | Horscht | btw, Zagor. I noticed this this morning. I installed the latest build (i have removed it now), went to work and noticed this. Back then i thought it was my fault, that I accidentaly downloaded the 32 MB build. Now i just redownloaded the most current version and it's 32 MB as well. Is there an issue with this in general? something wrong with the build system perhaps? |
22:51:36 | Zagor | Horscht: yes, the new build system erroneously built ipodvideo64mb for 32MB |
22:51:59 | kugel | JdGordon|: data->images is good at the beginning, but NULL after the wps is loaded |
22:52:05 | * | Horscht shakes fist at buildsystem:p |
22:52:12 | JdGordon| | only that one? |
22:52:13 | CIA-61 | New commit by zagor (r22382): Build ipodvideo64mb for 64 MB. |
22:52:17 | JdGordon| | or all of the lists? |
22:52:25 | kugel | JdGordon|: progressbar and strings work |
22:52:35 | JdGordon| | whiskey tango fuck! |
22:52:58 | kugel | Zagor: can you also update the source 7z? (or remove it) someone repeatedly comes and yells for it ;) |
22:53:18 | rasher | Zagor: &update should do it |
22:53:26 | Zagor | rasher: ah, excellent |
22:53:52 | rasher | I figure it's rare enough that I shouldn't bother adding a link anywhere? |
22:54:03 | amiconn | kugel, Unhelpful: I'm not sure what needs to be tested for accesses going wrong, but both SH1 and coldfire have a memory access monitoring facility which can be used for this |
22:54:14 | Zagor | rasher: no, this is fine |
22:54:25 | rasher | Zagor: Does it actually work? :) |
22:54:28 | Zagor | yes :) |
22:54:58 | Unhelpful | amiconn: i was thinking along the lines of a general method that we could apply to many buffers, and which could be enabled as a debug feature |
22:55:03 | stripwax | Zagor - hm, as of since when did the 64mb build get built with 32mb settings? |
22:55:04 | amiconn | It is used for the "Catch mem accesses" debugging aid in the debug menu, but can be reprogrammed to monitore almost arbitrary memory areas |
22:55:23 | * | stripwax noticed reduced battery life on recent builds and couldn't see when/why, so could be that |
22:55:32 | Zagor | stripwax: since the new system went live |
22:55:44 | Zagor | I assume, anyway |
22:55:58 | Unhelpful | amiconn: so it wouldn't be hard on CF/SH1 targets to drop a "no-access" region at either end of the audio buffer, or the plugin buffer, or pretty much anywhere else? |
22:56:34 | kugel | JdGordon: how does that look? (that's debug output, not code so SFW I guess ) http://pastie.org/586348 |
22:56:38 | amiconn | Yes. The CPU will throw an exception if that area is accesed. You can monitor read and write accesses separately |
22:56:51 | Zagor | stripwax: yeah, it's been 32MB all the time |
22:57:32 | stripwax | Horscht - good find!! |
22:57:38 | amiconn | A problem on coldfire is that this exception puts the core into "emulator mode", from which there seems to be no reliable way out apart from a reset (which the debugging aid triggers by enabling the watchdog and then deliberately not servicing it) |
22:57:59 | Horscht | when did it go live? |
22:58:27 | Unhelpful | amiconn: watchdog resets are actually a bit of a problem on beast... i don't always manage to get the fault address down before it restarts |
22:59:25 | amiconn | This just means that such a capture is essentially dead end, only reset possible afterwards. It displays the faulting address just fine |
22:59:32 | bertrik | maybe you can save it somewhere else and detect the watchdog reset on the next startup |
22:59:54 | JdGordon| | kugel: that wps_data_load is when the .wps is loaded? |
22:59:54 | | Quit Blue_Dude ("ChatZilla 0.9.85 [Firefox 3.5.2/20090729225027]") |
22:59:59 | Zagor | Horscht: july 15 |
23:00 |
23:00:06 | kugel | JdGordon: yes |
23:00:20 | amiconn | The watchdog is usually disabled; uie() enables it on purpose to trigger a reset |
23:00:30 | Horscht | so... basicaly it has been built for a month now as 32Mb? funny |
23:00:51 | Zagor | Horscht: yes... |
23:00:52 | amiconn | Later I refitted this method to sh1 because it's a simple and reliable way to reset |
23:01:49 | bertrik | yeah, a watchdog reset is usually way better than jumping to the reset vector or something similar |
23:02:07 | stripwax | that's about when I noticed lower battery life too (but could still be a coincidence) |
23:02:15 | amiconn | (easier than taking care to reset all those hardware regs to default and calling the correct function) |
23:03:01 | Unhelpful | amiconn: it being a dead end isn't a problem, i think... if it's 1) only in debug builds and 2) happens in a condition which probably has, or will, lead to corruption and crash |
23:03:20 | Unhelpful | the *sooner* you know a buffer has been overrun, the better for debugging it |
23:03:53 | | Join GeekShado_ [0] (n=Antoine@136.230.192-77.rev.gaoland.net) |
23:03:57 | amiconn | The feature is already there, just the setup function needs to be extended to allow monitoring arbitrary memory areas |
23:04:02 | JdGordon| | kugel: how are you loading the .wps |
23:04:15 | JdGordon| | I'm going to laugh so hard if this is your "fix" commit from yesterday |
23:04:15 | kugel | uhm, it's working now |
23:04:33 | JdGordon| | it is isnt it?! |
23:04:39 | Horscht | stripwax, no. That's actualy the first thing i noticed. I assume this has several reasons: less buffer = more disk spinup = shortened runtime. Also, the 30GB models might have a battery with a lower capacity |
23:05:07 | kugel | JdGordon|: ah nevermind, just band-aided by putting sb loading after wps loading :/ |
23:05:07 | stripwax | they do |
23:05:12 | amiconn | Right now it has just two settings: monitoring NULL pointer accesses (anything around address 0x0, so accesses involving offsets are caught as well), and monitoring write accesses to the rom area |
23:05:17 | | Part RyoS |
23:05:21 | kugel | settings_apply() all the time |
23:05:28 | | Quit bertrik (Remote closed the connection) |
23:05:32 | saratoga | Zagor: have the PP bootloaders been moved? |
23:05:42 | JdGordon| | kugel: close enough then... order matters... |
23:05:59 | JdGordon| | which is why the whole reset/buffering thing needs to be handled bettererer |
23:06:04 | Unhelpful | it would not be hard to do on sim either, at least on platforms with working memprotect... |
23:06:18 | stripwax | but the battery capacity in the build shouldn't affect the actual runtime (but the smaller buffer will) |
23:06:19 | kugel | the order matters? uhhh |
23:06:41 | Zagor | saratoga: no. can you or someone else who knows them make a new zip with them in the right directories? |
23:06:51 | JdGordon| | it looks like you did load sb, reset buffer, load wps |
23:06:56 | JdGordon| | spot the booboo! :D |
23:07:11 | | Quit GeekShadow (Read error: 145 (Connection timed out)) |
23:07:17 | saratoga | Zagor: c an't they just be copied? |
23:07:23 | saratoga | or even symlinked? |
23:07:24 | | Join kkurbjunW [0] (n=karlk@12.41.166.9) |
23:07:39 | Horscht | stripwax, but it would affect the displayd estimated runtime, correct? |
23:08:05 | stripwax | true |
23:08:31 | | Join bertrik [0] (n=bertrik@d90-128-154-247.cust.tele2.nl) |
23:08:48 | | Quit _lifeless (Remote closed the connection) |
23:09:06 | | Join _lifeless [0] (n=lifeless@90.151.217.179) |
23:10:22 | kugel | JdGordon|: no, reset buffer, load sb, load wps is what I did |
23:10:24 | kugel | http://imagebin.org/60008 |
23:10:45 | JdGordon| | pretty :p |
23:10:56 | JdGordon| | needs sometghing though... cant put my finger on what! |
23:11:09 | Zagor | saratoga: sure they can. but that's 15 files I have to manually move around, and they're not even all called the same thing as before. I don't know what is correct, and hence would prefer someone who knows does it. |
23:11:29 | kugel | it's the wps backdrop, I think with another backdrop it would look more like a "widget" |
23:11:43 | saratoga | Zagor: ah ok, I'm not actually sure either |
23:11:45 | JdGordon| | damn subtletly.... USE CUSTOMVP |
23:11:51 | kugel | I did |
23:11:53 | | Join Horschti [0] (n=Horscht2@xbmc/user/horscht) |
23:12:01 | JdGordon| | you did? its brokn then |
23:12:03 | saratoga | i suppose we should ask one of the rbutil people what they need to be called |
23:12:22 | kkurbjunW | Zagor: Are you able to update the playerpics from SVN? |
23:12:24 | kugel | http://imagebin.org/60009 ;) |
23:12:31 | Horschti | oh well...good night guys and girls |
23:12:38 | JdGordon| | AH |
23:12:40 | Zagor | kkurbjunW: done |
23:12:53 | bertrik | I think funman once gave me a little tool called clipsplit to split an AMS firmware into smaller modules, does anyone have this? |
23:13:23 | kkurbjunW | Zagor: great, thanks! |
23:13:24 | kugel | works pretty well, updates itself pretty much every second |
23:14:00 | JdGordon| | we probably want it to update more often... so progress indicators work |
23:14:07 | | Quit kkurbjunW (Remote closed the connection) |
23:14:13 | kugel | that should be possible |
23:14:19 | bluebrother | Zagor: have you thought about using the build target name for the build folder for the build client? I.e. something like build-h120 instead of build-1234? |
23:14:24 | | Join kkurbjunW [0] (n=karlk@12.41.166.8) |
23:14:28 | JdGordon| | its goig to be a decent batt hit though |
23:14:39 | | Quit _lifeless (Remote closed the connection) |
23:14:54 | | Quit Horschti (Client Quit) |
23:14:55 | | Join _lifeless [0] (n=lifeless@90.151.217.179) |
23:14:59 | kugel | JdGordon|: it's free if unused on the other hand, just the code and ramsize is questionable yet ;) |
23:15:09 | JdGordon| | yep |
23:15:32 | | Quit kkurbjunW (Remote closed the connection) |
23:15:35 | JdGordon| | this is now the 3rd proof of concept wps/skined statusbar :) |
23:15:49 | | Join kkurbjunW [0] (n=karlk@12.41.166.9) |
23:15:52 | Zagor | bluebrother: hah, no I haven't! I was about to remove the build dirs altogether, but that is a much better solution. |
23:16:16 | *** | Saving seen data "./dancer.seen" |
23:16:18 | JdGordon| | I think skinfm will be a nicer addition than statusbar |
23:16:18 | kugel | JdGordon|: yea, but the first one that isn't a baaaad hack :) |
23:16:40 | JdGordon| | I imaine yours is almost he same as mine against customvp no? |
23:16:59 | kugel | what do you mean? |
23:17:01 | | Quit Zarggg () |
23:17:18 | JdGordon| | mine was customvp + hack |
23:17:19 | | Quit _lifeless (Remote closed the connection) |
23:17:38 | kugel | well, I just call skin_update() instead gui_syncstatusbar_draw() in that event, that's all. |
23:17:50 | JdGordon| | yep |
23:18:09 | kkurbjunW | Zagor: what determines what players are shown on the download page? |
23:18:21 | | Join Zarggg [0] (n=zarggg@65-78-69-194.c3-0.eas-ubr6.atw-eas.pa.cable.rcn.com) |
23:18:33 | | Quit Saline () |
23:18:37 | kugel | but my version is much cleaner! (beginning to take the credit) ... because of your skin engine rework (this time you also get some :D ) |
23:18:52 | | Quit bertrik (Success) |
23:19:01 | kkurbjunW | For example this page exists, but it is not linked when you click on the Current build link: http://www.rockbox.org/dl.cgi?bin=mrobe500 |
23:19:02 | Zagor | kkurbjunW: the script that creates that page. it's not connected to the actual builds list yet. |
23:19:39 | JdGordon| | kugel: a few things though... we cant kill the old statusbar.. and umm... |
23:19:49 | kugel | I think we can |
23:20:02 | JdGordon| | rec statusbar is giong to cause problems probably |
23:20:31 | kugel | we can hardcode a skin-version of the current statusbar and use that as fallback |
23:20:34 | JdGordon| | we cant quite do everything in the current sb if its skinned |
23:21:10 | domonoky | saratoga: rbutilqt.ini lists all bootloader names and folders for the different targets :-) |
23:21:15 | Zagor | kkurbjunW: the daily builds are still done with Bagders' scripts. I don't know all the details of them. |
23:22:48 | kkurbjunW | ok thanks, I'll talk to him about what needs to be done to get a target listed on the current builds page... I'm looking through the www and there are these t files that seem to be related to the builds shown, but they don't list all the targets |
23:22:49 | | Join ehntoo [0] (n=ehntoo@adsl-99-156-192-57.dsl.applwi.sbcglobal.net) |
23:23:25 | | Join bertrik [0] (n=bertrik@d90-128-154-247.cust.tele2.nl) |
23:23:36 | | Join dmb [0] (n=Dmb@unaffiliated/dmb) |
23:23:55 | | Quit ender` (" “That’s right, babe,” Cochrane chortled. “We’re not possessors, we’re just like dimensionally disadvantaged.” -- Peter F. H") |
23:24:11 | JdGordon| | kugel: actually... hmm... no, everything can be done in a skin |
23:24:16 | | Quit bmbl ("Bye!") |
23:24:30 | JdGordon| | we should remove the option to have graphical or number displays though to make t easier |
23:24:40 | JdGordon| | actually... haha no need |
23:24:51 | JdGordon| | it can all be done in the skin code |
23:24:56 | kugel | yea |
23:25:18 | JdGordon| | rec sb is going to be the problem |
23:25:56 | kugel | man, this statusbar thing came into my mind last night when I went bed, I imagined so great themes, using tiny cover arts next to the list <3 |
23:26:10 | * | kugel couldn't sleep for a while then |
23:26:31 | JdGordon| | I already asked Unhelpful about different sized AA for this... |
23:26:49 | JdGordon| | bassically... its going to be rediculously sweet when its all finished :D |
23:26:55 | kugel | exactly |
23:27:58 | * | domonoky wants 8x6 AA in the status bar... on a greyscale target :-) |
23:28:03 | JdGordon| | haha |
23:28:34 | JdGordon| | hmm... I wonder if we could disable all prettyness in the rec screen and use the old statusbar code (shrunk abit though) just for that |
23:28:43 | bertrik | anti-aliased fonts too of course |
23:29:15 | JdGordon| | hopefully all this motivates someone to do multifont properly :) |
23:29:23 | Bagder | alphablending! |
23:29:30 | * | Bagder runs |
23:29:55 | | Quit Horscht (Read error: 110 (Connection timed out)) |
23:30:00 | * | stripwax is still a little sad that the main menu isn't in 3D |
23:30:06 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
23:30:20 | pixelma | multifont would be very nice for remote targets at least |
23:30:24 | JdGordon| | sif 3d... didnt you know 5D is the bestest |
23:30:40 | JdGordon| | pixelma: have you seen the mr500 and its remote? |
23:31:13 | | Quit moos ("reboot") |
23:31:15 | domonoky | multifont also would be nice to have a differnt font (size) in the wps then in the lists. |
23:31:17 | pixelma | no, but H300 and its remote is already quite "nice" |
23:31:21 | kugel | I think they make the remotes out of mr500's where a corner of the display broke away, and then sell both in a package :) |
23:31:55 | kugel | you wouldn't notice the missing corner |
23:32:01 | JdGordon| | except one is mono and one is colour :) |
23:32:12 | JdGordon| | but yeah... |
23:33:46 | Zagor | Bagder: can you look at why the source 7z isn't updated right by the daily build? |
23:34:38 | | Quit robin0800 (Remote closed the connection) |
23:34:41 | Bagder | it isn't? |
23:34:43 | | Quit raphi ("leaving...") |
23:35:21 | saratoga | should we even have a daily source? encouraging people to use SVN would be better |
23:35:41 | Bagder | yeah, but some people can't reach svn due to silly politics |
23:35:44 | | Quit HBK- () |
23:35:45 | | Join moos [0] (i=mustapha@rockbox/staff/moos) |
23:36:17 | Zagor | Bagder: no. download.rockbox.org/daily/source has 30 copies of the same file (since july 18) |
23:36:23 | Bagder | yeah I see |
23:36:39 | Bagder | although I thought I already fixed this... :-) |
23:37:52 | kkurbjunW | Bagder: Could you point me in the direction of what needs to be changed so that he M:Robe 500 starts showing on the current builds page? |
23:38:31 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
23:38:41 | Bagder | you can't, that particular file isn't in svn... :-/ |
23:39:15 | Bagder | I added it now |
23:42:31 | Zagor | whoa, ccache is a bit faster than non-ccache :-) |
23:42:47 | Zagor | Completed: build fuze client lillebror1-zagor seconds 26.0 uplink 97 speed 792 |
23:43:05 | | Quit robin0800 (Read error: 60 (Operation timed out)) |
23:43:26 | JdGordon| | Zagor: you mean it actually works if used properly?! |
23:43:29 | JdGordon| | crikey! |
23:43:38 | Zagor | JdGordon|: amazing, isn't it? |
23:44:51 | kkurbjunW | Bagder: thanks for that - I have a small player picture in playerpics for the M:Robe 500 |
23:45:16 | Bagder | that needs to be added in rockbox.pm |
23:45:42 | | Join petur [0] (n=peter@rockbox/developer/petur) |
23:45:48 | Bagder | it has a lookup table for build => small pic name |
23:45:57 | kkurbjunW | gotcha, I'm looking at that now |
23:46:04 | domonoky | Zagor: what do you think of my updated genlang.cgi patch ? :-) |
23:47:46 | CIA-61 | New commit by kkurbjun (r22383): Add smallpic to table for M:Robe 500 |
23:48:02 | bertrik | domonoky, I found some of the m200v4 ascodec init sequences again |
23:48:14 | domonoky | :-) |
23:48:36 | bertrik | register 0x21 is written with value 0x16 through mask 0x3F |
23:48:49 | kkurbjunW | Bagder: could you also add the MR500 to the daily.shtml page? |
23:48:53 | bluebrother | Zagor: is that with target-specific builddirs? |
23:48:58 | bertrik | register 0x15 is written with value 0x3F through mask 0x3F |
23:49:01 | Zagor | bluebrother: yes |
23:49:09 | bluebrother | nice :) |
23:49:15 | bertrik | register 0x16 is written with value 0x07 through mask 0x07 |
23:49:39 | bertrik | register 0x20 is written with value 0x08 through mask 0x08 |
23:49:43 | CIA-61 | New commit by zagor (r22384): More ccache-friendly directory names. |
23:50:06 | Bagder | kkurbjun: that's the dailymod.pl script in the www root, it has a table at the top for all players it shows |
23:50:16 | Bagder | mrobe500 already gets built daily |
23:50:37 | kkurbjunW | yep, I saw that there's a daily page, but it's not linked in the daily table |
23:51:03 | Bagder | exactly, because it's not added in that table |
23:51:05 | domonoky | bertrik: thanks. i will note it and try todo something with that info tomorrow :-) |
23:51:14 | bertrik | domonoky, those 4 settings are done quite early in the boot process, there's lot of other settings but I suspect these may be the most important |
23:51:15 | | Quit moos ("Rockbox rules the DAP world") |
23:51:18 | gevaerts | Zagor: so now build times will geteven less predictable :) |
23:51:31 | Zagor | yess! |
23:51:43 | bluebrother | who needs predictable build times? I want _fast_ build times. That's predictable enough! ;-) |
23:52:02 | saratoga | when are GSOC evaluations due? |
23:52:37 | linuxstb | Next monday (24th) |
23:53:10 | CIA-61 | New commit by kkurbjun (r22385): M:Robe 500: Add to dailymod table |
23:53:12 | gevaerts | bluebrother: we may just want fast builds, but Zagor is on the record as saying that he only cares about *efficient* builds :) |
23:53:27 | kkurbjunW | Bagder: I see, thanks - I think I added what was needed |
23:53:34 | JdGordon| | ccache doesnt increase efficiency |
23:53:47 | saratoga | linuxstb: when can we fill them out? |
23:53:49 | kugel | Zagor: did that also fix the parallel builds? |
23:53:56 | JdGordon| | efficient builds means no killed builds, ccache doesnt change anything there |
23:54:01 | domonoky | bertrik: at least reg21 is interessting. they not only lower the charge pump to 3.1V but also lower CVDD to 1.1V so that may help.. |
23:54:04 | Bagder | Zagor: care to update the web dir from svn so that kkurbjun's update appears? |
23:54:17 | Zagor | kugel: no, I don't know what causes that yet. I've added some more logging though to help me find out. |
23:54:18 | linuxstb | saratoga: Starting now I think. |
23:54:36 | kugel | Zagor: I thought because you removed a GIMMEMORE message |
23:54:38 | | Quit petur (Read error: 104 (Connection reset by peer)) |
23:54:47 | Zagor | Bagder: done |
23:54:50 | | Quit dmb (Read error: 113 (No route to host)) |
23:55:05 | kkurbjunW | Thank you |
23:55:11 | Bagder | fancy mrobe500 pics! |
23:55:22 | Zagor | kugel: yeah it was unnecessary, but I don't see it causing that bug. |
23:55:42 | kkurbjunW | :) |
23:55:56 | JdGordon| | so the mr500 is now supported? :) |
23:56:03 | Bagder | does the mrobe500 manual build? |
23:56:46 | kkurbjunW | I've never tried a manual build |
23:57:03 | Bagder | hehe, then I bet it doesn't ;-) |
23:57:23 | domonoky | bertrik: reg20 lowers IOVDD to 2.9V still searching what reg15 and reg16 is.. |
23:57:38 | kugel | either the mr500 is supported, or we also add the beast on the current build table |
23:57:39 | kugel | IMO |
23:57:52 | JdGordon| | snap |
23:58:01 | JdGordon| | just to make Zagor's best fitting more painful :) |
23:58:16 | bluebrother | the beast still has major installation issues. Plus this some-devices-don't-accept-single-boot. |
23:58:26 | kkurbjunW | What do I need to do to build a manual? |
23:58:34 | JdGordon| | mr500 has a out right terrible install experince |
23:58:39 | Zagor | rasher: &update doesn't seem to work now |
23:58:46 | rasher | Zagor: Hm |
23:58:56 | kkurbjunW | JdGordon: I don't think the mr500 install is that bad |