--- Log for 18.04.107 Server: kornbluth.freenode.net Channel: #rockbox --- Nick: logbot- Version: Dancer V4.16 Started: 6 days and 22 hours ago 00.01.43 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 00.03.18 Quit davina (Remote closed the connection) 00.03.31 # hum 00.03.37 # roolku: a bricked Gigabeat could be fixed with a jtag interface 00.03.43 # i don't find the link to login into the wiki 00.04.13 # just click an edit link or whatnot and it will ask for credencials 00.04.33 # markun: from his description the (rom-) bootloader still seems to work 00.04.39 # ok 00.04.51 Quit amiconn (Read error: 110 (Connection timed out)) 00.04.51 Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) 00.05.49 Nick jhulst_ is now known as jhulst (n=jhulst@adsl-69-208-79-209.dsl.klmzmi.ameritech.net) 00.06.13 # I just don't understand what he has done and why he would want to run fw.exe 00.07.44 # anyone know where i can get the system files for a gigabeat f40? 00.08.50 # gigapete: in the wiki you will find a zip with a fake gbsystem folder 00.09.02 # if you just use rockbox you can use that one 00.09.11 # it will speed up booting too 00.09.58 Join daniel2023 [0] (i=d0b4e09e@gateway/web/cgi-irc/labb.contactor.se/x-665e9af9fc57fb66) 00.11.51 # yay! it's rendering text from the srt file 00.11.55 Join lids [0] (i=lds@gateway/tor/x-3858bab56c244c1b) 00.16.27 Join Hammer89 [0] (n=soc_inte@host-24-149-166-187.patmedia.net) 00.18.23 Quit lids (Remote closed the connection) 00.18.50 Quit obo ("bye") 00.20.09 Join lini [0] (i=pugsley@62.204.144.237) 00.21.39 # dionoea: watching anime with subs? :) 00.22.29 # no ... finished writing a logo erase video filter for VLC so i though i'd have fun on rockbox a bit :) 00.22.56 Quit idnar (Connection timed out) 00.23.32 # how weird, I just received SPAM with a subject in esperanto! 00.24.12 # the rest of the email is computer generated english, and a picture is attached with the actual spam 00.25.45 Join lids [0] (i=lds@gateway/tor/x-787fe189b9d06ce5) 00.27.26 Quit bluebrother ("leaving") 00.31.15 Join brenda [0] (n=brenda@leibniz.catalyst.net.nz) 00.33.24 Join haTem [0] (n=hatem@ip72-209-67-250.ga.at.cox.net) 00.33.57 Nick _pill is now known as pill (i=pill@sloth.shellfx.net) 00.34.28 # linuxstb: is curr_time the time i should use to position the subs ? or eta_video ? (or something else?) 00.34.31 Quit brenda (Remote closed the connection) 00.37.37 # hum, curr_pts would be better in fact 00.37.44 # dionoea: I don't know any more - best to ask jhMikeS 00.38.01 # what unit is that using btw ? 00.38.29 Join webguest02 [0] (i=c874c1b8@gateway/web/cgi-irc/labb.contactor.se/x-0aab8b60c749394a) 00.38.32 Quit JdGordon ("Konversation terminated!") 00.38.47 # I think the PTS values are divided by 2 - so they are 45KHz. But the main clock is the DAC - 44.1KHz. 00.39.08 # I have a big trouble!! 00.39.09 # So I think all times are converted into audio samples. 00.39.19 Quit funky ("leaving") 00.39.41 # so 44.1 kHz ? 00.40.58 # i change battery type of my ipod nano and every i try to turn on the ipod its appear very low battery! 00.41.05 # please help me! 00.42.01 # webguest02: Charge it? 00.42.21 Quit entheh ("^~") 00.42.52 # i try but wen i disconnect it appear again @very low battery@ 00.43.23 # Have you reset it (hold MENU+SELECT) ? 00.43.37 # yes 00.43.59 # i try restoring with itunes but dont work 00.44.05 # linuxstb: any idea if the time starts at 0 ? or is it some internal clock used by the stream with a random offset ? 00.44.23 # dionoea: It will most likely start at the first PTS of the first audio frame. 00.44.40 # Which can be anything... 00.44.40 # is that value stored somewhere ? 00.45.09 # I used to store it, but I think jhMikeS deleted it. Search for "first" in mpegplayer.c 00.45.42 # looks like it's gone :( 00.45.42 Quit daniel2023 ("CGI:IRC (EOF)") 00.45.43 Quit mirak (Remote closed the connection) 00.45.46 # webguest02: What do you mean by "change battery type" ? 00.45.48 Quit moos ("Glory to Rockbox") 00.45.52 # I'll store one my self (on the first call to the function) 00.46.42 Quit billytwowilly (Remote closed the connection) 00.47.26 Join billytwowilly [0] (n=chris@S01060016b649355d.ed.shawcable.net) 00.47.41 Quit lee-qid ("aufwiederbyebientotsayonara") 00.48.28 # in rockbox 00.48.35 # hey, my iriver h320 only powers on when plugged into a power supply, and I believe this started after I upgraded rockbox to one of the recent daily builds (I had been using a build from sometime in october)... has anyone experienced something like this? 00.48.41 # oops, Prefetch abort. That sounds bad 00.48.43 Join stripwax [0] (n=Miranda@i-83-67-214-206.freedom2surf.net) 00.49.06 # I've tried multiple firmware versions, and I've tried installing the oldest daily build I could find on the website (3/16) 00.49.29 # haTem: there's a config option for usb charging 00.49.32 # i accidentaly turn the battery type in to another 00.49.45 # Does the new customizable icons code mean that icons on 16-bit targets are always displayed in black regardless of the foreground color (=> custom wps with black backgrounds are need required to now have custom icons) ? 00.49.55 # ^need^now 00.50.47 # no one can help me_ 00.51.21 Quit inversions (Read error: 113 (No route to host)) 00.52.19 # webguest77: "Charge During USB Connection" is set to "No", could that be causing it? 00.52.56 # i dont know 00.52.57 # that will stop it charging via usb... is that what you meant to start with? 00.53.04 # i cant restore my ipod now 00.53.37 # i cant start with rockbox 00.53.49 # webguest77: no, what I mean is that if it's not connected to a power supply, it refuses to turn on (even though it appears to be fully charged) 00.54.58 # haTem: ah, sorry I misunderstood - I don't know why that should be the case 00.55.02 # it turn on but i have to connect and reboot about 6 times 00.55.41 # webguest02: Do you mean the Battery Capacity setting? 00.56.11 # yes battery capacity setting 00.56.15 # webguest77: heh, I'd think it was just some freak coincidence and that the battery is just dead (unrelated to the rockbox upgrade), but my friend is having the same issue with his recently purchased h320 00.56.36 # webguest02: That setting does nothing at all to your ipod - it's just used to help Rockbox estimate the remaining runtime to display. 00.57.15 # haTem: sure - for what it's worth my h320's fine... 00.57.24 # webguest02: It simply sounds like your battery is low - charge it, wait, and reboot with MENU+SELECT. 00.57.59 # i charge it for 6 hours and it dont charge 00.58.20 # if i email my sister an ogg vorbis file, will she have any trouble playing it in windows? 00.58.28 # So (I would have thought) the default icons should be 1bpp on 16bit targets, so that they DO show up in foreground color. but that doesn't seem to be the casse 00.58.30 # case 00.58.32 Join idnar [0] (n=mithrand@unaffiliated/idnar) 00.58.51 # ashes - is that a Rockbox question? 00.59.14 # webguest77: are you using a recent build of rockbox? 00.59.22 # I suppose I should try fiddling with the battery 00.59.35 # stripwax: I agree... 00.59.39 # haTem: today's or maybe yesterday's now 00.59.40 # also, what firmware are you using :P 00.59.53 # if i email my sister an ogg vorbis, from my iriver which runs rockbox, will she have any trouble playing it in windows? 01.00.04 # last firmware 01.00.22 # ashes: She can copy it to her DAP running Rockbox and play it... 01.00.23 # linuxstb: looks like get_playback_time() was what i was looking for (it changes at about 44kHz and starts at 0) 01.01.08 # so sad... 01.01.19 # but tks a lot 01.01.52 # ashes: sounds like a Windows question. maybe, the answer will be on www.vorbis.org? 01.02.06 # i go to put my ipod into a micowave 01.02.25 Join smolyn [0] (n=smolyn@blk-138-57-29.eastlink.ca) 01.02.26 # vorbis.org says she'll need additional software 01.02.33 # bye 01.02.41 # ashes - well it depends what software she already has .... 01.02.53 # webguest02 - what is the issue? 01.03.18 # stripwax: ipod nano refusing to charge 01.03.27 # webguest02: make sure that you make a movie of the ipod in the microwave 01.04.17 # and ipod cant run nomore linux and rockbox 01.04.55 # webguest have you tried leaving it to fully charge via a mains adapter (not usb)? 01.05.18 # yes but the problem im the same 01.05.38 # is* 01.05.57 Part Rift 01.06.31 # please help me 01.09.00 # webguest02 - so it doesn't even turn on? no icons on the screen saying charging? you've tried resetting it? 01.11.05 # yes it turn on 01.11.58 # but in the apple os dont show the battery and wen i disconnet it it turn of 01.12.23 *** Saving seen data "./dancer.seen" 01.12.30 # wath i do_ 01.13.04 # i even restoe my ipod with itunes i i have the same problem 01.14.02 # ? 01.14.53 # Cool. I've got srt subs working :) 01.14.58 # any of you have any idea? 01.15.05 # I'll clean it up, add some error checking and post a patch here tomorrow 01.17.01 # dionoea: What's the cost? i.e. how much slower is it? 01.17.50 # i've lost 1 or 2 fps here (but i'm rendering debug output at the time) 01.17.56 # So i'll see once it's cleaned up 01.18.02 # On which target? 01.18.06 # ipod video 01.18.13 # (worst of all :) ) 01.18.29 # So down from 10fps to 8 or 9 (with sync enabled) ? 01.18.30 # and i'm rendering debug output at 4HZ instead of 1HZ like in the normal plugin 01.18.40 # linuxstb: i guess so... let me try 01.19.43 # please help me 01.19.50 # 8.5 to 9.5 fps during the first 20 secs of elephant dreams 01.20.01 # webguest02 - sorry, I can't help, I'm not sure what you mean when you say "in the apple os dont show the battery". It turns on but the Apple OS doesn't work? It doesn't sound like a rockbox issue, perhaps your ipod is faulty 01.20.02 # so performance stays about the same 01.20.14 # I've really got to get some sleep now. I'll post a patch tomorrow 01.20.16 # good night 01.20.17 # Well, the first 20 secs is the easiest to decode... 01.20.28 Quit stripwax ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 01.20.32 # I'm at 8.9 now 01.20.41 # seems to be pretty stable arround 9 fps 01.21.08 # (my timing looks a bit screwed ... based on real time and not stream time it seems) 01.21.15 # wen i go to te apple os the batery icon dissapears 01.21.25 # webguest02: there were a lot of reports that ipods, especially nanos, behave weird on low battery. Most of what I read says: try charging it for a longer time, do the reset and it'll get back to normal. See http://forums.rockbox.org/index.php?topic=9938.msg76488#msg76488 as a good example (given that there is no other hardware issue of course) 01.22.29 # ah no, listening to the audio at the same time shows that it's synced 01.22.33 # awesome :) 01.22.36 Quit ompaul ("there is no fancy quit message - just this") 01.22.39 # * dionoea 's off to bed 01.25.40 Quit PaulJam (".") 01.28.49 # i have the problem of pianofreq 01.29.10 # and seems like he dont fix hes ipod 01.30.20 Quit roolku () 01.31.31 Quit Thundercloud (Remote closed the connection) 01.33.21 # ?? 01.33.31 Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) 01.39.58 Quit haTem ("i quit.") 01.45.26 Join barrywardell [0] (n=barrywar@194.46.191.98) 01.54.02 Join elinenbe__ [0] (n=elinenbe@207-237-224-214.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 01.56.56 Quit elinenbe (Read error: 110 (Connection timed out)) 01.56.57 Nick elinenbe__ is now known as elinenbe (n=elinenbe@207-237-224-214.c3-0.nyr-ubr1.nyr.ny.cable.rcn.com) 01.57.46 Join pearldiver [0] (n=say@cpe-72-225-231-80.nyc.res.rr.com) 01.59.46 Join Yono [0] (n=Yono@cpe-24-59-36-12.twcny.res.rr.com) 02.05.50 # is anybody using the new dict patch? 02.05.52 Quit webguest02 ("CGI:IRC (Ping timeout)") 02.09.11 Quit barrywardell () 02.10.44 Join ceaser_ [0] (n=ceaser@cpe-71-72-73-134.columbus.res.rr.com) 02.11.23 Part Domonoky_ 02.13.31 Quit perldiver (Read error: 110 (Connection timed out)) 02.39.24 Quit midgey () 02.50.29 Join Nico_P [0] (n=nicolas@jau31-3-82-239-20-145.fbx.proxad.net) 02.54.54 Quit jhMikeS (Read error: 60 (Operation timed out)) 02.55.44 Join jhMikeS [0] (n=jethead7@rockbox/developer/jhMikeS) 02.59.59 Join webguest87 [0] (i=cf60f3c3@gateway/web/cgi-irc/labb.contactor.se/x-6e69600e1a42a8f0) 03.00.04 # hi everybody 03.00.26 # i have got one question - is rockbox gonna work on my ipod (80GB 5.5G) ?? 03.03.32 # unless it's listed here I don't think so... http://www.rockbox.org/twiki/bin/view/Main/DeviceChart 03.04.56 Quit webguest87 (Client Quit) 03.05.19 Part pixelma 03.05.54 Join webguest80 [0] (i=89a5f07d@gateway/web/cgi-irc/labb.contactor.se/x-003c9a1a81a6faab) 03.12.26 *** Saving seen data "./dancer.seen" 03.12.30 Quit webguest80 ("CGI:IRC (EOF)") 03.19.23 Join N4z3r_0f_sun [0] (n=nazerofs@71-210-117-152.tcsn.qwest.net) 03.19.29 # hey 03.19.46 # hello? is this the rock box channel? 03.20.33 # yes, it is. 03.21.06 # ok can you help me i want to use my ipod mini with it ok? 03.21.27 # but im totally lost and i have no clue where to start 03.21.39 # follow the manual instructions. if you have a specific problem or question then you can ask. 03.21.46 # kk ty 03.21.46 # you don't need permission to ask questions in this channel. 03.21.55 # ty 03.21.58 # bye 03.22.05 Part N4z3r_0f_sun 03.27.43 Quit spiorf ("Read error: 110 (Connection timed out)") 03.31.09 Quit miepchen^schlaf (Read error: 110 (Connection timed out)) 03.31.14 Join miepchen^schlaf [0] (n=hihi@p54BF61CB.dip.t-dialin.net) 03.34.33 Quit Nico_P (Remote closed the connection) 03.40.18 Quit Thundercloud (Remote closed the connection) 03.41.21 Join TrueJournals [0] (n=aimjourn@c-24-12-147-61.hsd1.il.comcast.net) 03.42.05 Quit webguest77 ("CGI:IRC (EOF)") 03.43.20 Join GRaTT [0] (i=gratty@d216-232-96-212.bchsia.telus.net) 03.45.09 # Hi need some help reading files for a playlist converter on sansa 03.46.35 # already have rockbox playlist to sansa Original firware palylist 03.46.54 # trying to do a sansa OF playlist to rockbox m3u 03.47.16 # having trouble due to null bytes in .pla playlist files 03.48.57 Quit Guile (Read error: 104 (Connection reset by peer)) 03.50.59 Quit lids (Remote closed the connection) 03.52.26 Quit miepchen^schlaf (kornbluth.freenode.net irc.freenode.net) 03.52.26 NSplit kornbluth.freenode.net irc.freenode.net 03.52.26 Quit smolyn (kornbluth.freenode.net irc.freenode.net) 03.52.26 Quit billytwowilly (kornbluth.freenode.net irc.freenode.net) 03.52.26 Quit jhulst (kornbluth.freenode.net irc.freenode.net) 03.52.26 Quit desowin (kornbluth.freenode.net irc.freenode.net) 03.52.26 Quit alberink (kornbluth.freenode.net irc.freenode.net) 03.52.26 Quit GodEater (kornbluth.freenode.net irc.freenode.net) 03.52.26 Quit jaebird (kornbluth.freenode.net irc.freenode.net) 03.52.26 Quit hcs (kornbluth.freenode.net irc.freenode.net) 03.52.26 Quit sando (kornbluth.freenode.net irc.freenode.net) 03.52.26 Quit gtkspert (kornbluth.freenode.net irc.freenode.net) 03.52.26 Quit GodEater__ (kornbluth.freenode.net irc.freenode.net) 03.52.26 Quit z0de (kornbluth.freenode.net irc.freenode.net) 03.52.26 Quit secleinteer (kornbluth.freenode.net irc.freenode.net) 03.52.26 Quit dan_a (kornbluth.freenode.net irc.freenode.net) 03.52.35 NHeal kornbluth.freenode.net irc.freenode.net 03.52.35 NJoin miepchen^schlaf [0] (n=hihi@p54BF61CB.dip.t-dialin.net) 03.52.38 Join lids [0] (i=lds@gateway/tor/x-2230d8740e9e2f6b) 03.53.09 NJoin sando [0] (i=lolsteam@124-254-76-41-static-dsl.ispone.net.au) 03.53.19 Join johnnyoc3 [0] (n=chatzill@adsl-71-143-19-189.dsl.scrm01.pacbell.net) 03.53.47 Join Llorean [0] (n=Llorean@rockbox/administrator/Llorean) 03.55.23 NJoin gtkspert [0] (n=gtkspert@gateless.info) 03.57.02 Join borisyeltsin [0] (n=chris@S01060016b649355d.ed.shawcable.net) 03.57.21 Join alberink_ [0] (n=alberink@cc516682-b.ensch1.ov.home.nl) 03.59.13 # anyone know some good deals on sansa players? im looking to get one 04.00.08 NJoin secleinteer [0] (n=secleint@adsl-70-237-141-92.dsl.stlsmo.sbcglobal.net) 04.01.34 NJoin smolyn [0] (n=smolyn@blk-138-57-29.eastlink.ca) 04.01.34 NJoin billytwowilly [0] (n=chris@S01060016b649355d.ed.shawcable.net) 04.01.34 NJoin jhulst [0] (n=jhulst@adsl-69-208-79-209.dsl.klmzmi.ameritech.net) 04.01.34 Join desowin [0] (n=desowin@unaffiliated/desowin) 04.01.34 NJoin alberink [0] (n=alberink@82.75.146.79) 04.01.34 NJoin GodEater [0] (n=bryan@host-83-146-13-117.bulldogdsl.com) 04.01.34 NJoin jaebird [0] (n=jae@69.41.89.53) 04.01.34 NJoin hcs [0] (n=agashlin@rockbox/contributor/hcs) 04.01.34 NJoin GodEater__ [0] (n=bryan@host-83-146-13-117.bulldogdsl.com) 04.01.34 NJoin z0de [0] (i=z0de@80-194-233-59.cable.ubr01.enfi.blueyonder.co.uk) 04.01.34 NJoin dan_a [0] (n=dan_a@217.23.173.156) 04.01.35 *** Server message 505: 'logbot- :Private messages from unregistered users are currently blocked due to spam problems, but you can always message a staffer. Please register! ( http://freenode.net/faq.shtml#privmsg )' 04.02.14 Quit z0de (Connection reset by peer) 04.03.04 # anybody good with text file reading in rockbox 04.03.15 Quit desowin (Excess Flood) 04.04.36 Join jhulst_ [0] (n=josh@adsl-69-208-79-209.dsl.klmzmi.ameritech.net) 04.04.50 # GRaTT: What do you mean? 04.04.54 # what do you mean "good with" 04.05.17 Quit alberink (Read error: 110 (Connection timed out)) 04.06.20 Quit jhulst (No route to host) 04.06.38 Nick jhulst_ is now known as jhulst (n=josh@adsl-69-208-79-209.dsl.klmzmi.ameritech.net) 04.09.56 # Truejournals: I am working on a playlist converter for sansa 04.10.30 # TrueJournals: I need to read in the OF playlist file and it has null bytes between each char 04.11.07 # ah, so you're saying coding a plugin for rockbox? 04.11.37 # TrueJournals: yes, I already have rockbox playlist to OF playlist 04.12.08 # Ah, OK, not me then :-p 04.12.10 # Sorry 04.12.11 # johnnyoc3: anybody that can helpo me read these sansa OF playlist files (.pla) 04.12.32 # *help 04.12.37 # Good luck though 04.12.37 # sorry i cant help with that :( 04.14.11 # anybody here work with sansa playlists at all 04.16.16 # There's usually not much care for the original firmware. 04.19.01 Quit gtkspert (Remote closed the connection) 04.19.03 Quit mbr (Read error: 60 (Operation timed out)) 04.19.29 Join gtkspert [0] (n=gtkspert@gateless.info) 04.19.38 # null bytes between each character? it sounds like it's some unicode encoding with >8 bits per symbol 04.22.24 Join webguest22 [0] (i=d360b527@gateway/web/cgi-irc/labb.contactor.se/x-c2f7044611b0e8c5) 04.24.30 Part TrueJournals 04.24.52 Quit Soap2 (Read error: 110 (Connection timed out)) 04.25.07 Quit billytwowilly (Connection timed out) 04.27.15 # anyone had issues with the cap WPS freezing up on them on a 30gb ipod? 04.27.22 # car* 04.27.49 Quit webguest22 ("CGI:IRC (Ping timeout)") 04.28.06 # Llorean: I know , I started this before sound, alway some reason to use OF though. 04.29.35 Quit ceaser_ (Read error: 104 (Connection reset by peer)) 04.34.43 # rotator: yes something like that. Just having trouble reading the file due to the null bytes 04.35.15 # Llorean ha, too bad it wasnt a champaign after all! 04.35.15 # rotator: using the text editor in RB just the first char displays 04.35.31 # rotator: using the text viewer in RB displays the whole file 04.35.52 Join saratoga [0] (i=98039b62@gateway/web/cgi-irc/labb.contactor.se/x-a6593c4bc00fa22c) 04.36.00 # pearldiver: I got it in better light, it is. 04.36.07 # It's apparently just a very subtle color 04.36.16 # it is 04.36.17 Join ozgur [0] (i=a46b7415@gateway/web/cgi-irc/labb.contactor.se/x-3d07b420b95ee25f) 04.36.52 # also the outer rim is completely different to the touch to F20 and F60 04.37.13 # On F40s? 04.37.14 Quit saratoga (Client Quit) 04.37.39 Join saratoga4 [0] (i=98039b62@gateway/web/cgi-irc/labb.contactor.se/x-f67a122d3308c120) 04.37.49 # Llorean yes 04.38.03 # Well, I've never touched an F20 or F60. :) 04.38.25 # my black F20 is extremely polished 04.38.28 # GRaTT: checked unicode.c? 04.38.36 Join webguest89 [0] (i=89a5f07d@gateway/web/cgi-irc/labb.contactor.se/x-2af80bc75e274e11) 04.38.45 # i'd guess theres a function in there 04.39.20 # F40 almost feels like it has a texture to it 04.39.20 Quit ozgur (Client Quit) 04.40.10 Join Topy44 [0] (n=Topy44@xdsl-81-173-151-103.netcologne.de) 04.42.16 Join aliask [0] (n=chatzill@c210-49-190-113.eburwd8.vic.optusnet.com.au) 04.43.44 # wow amazon added 20 dollars to the 8GB Sansa price 04.43.54 # but I think the actually lowered the price on the 6GB 04.44.03 # Sandisk pricing makes no sense at all to me 04.44.24 Quit johnnyoc3 ("ChatZilla 0.9.78.1 [Firefox 2.0.0.3/2007030919]") 04.45.30 # saratoga4: I will look now thanks 04.46.58 Join JdGordon [0] (i=82c20d66@gateway/web/cgi-irc/labb.contactor.se/x-deb0f1c363529b6d) 04.47.56 # JdGordon: did you ask about the Sansa emulator the other day on IRC? 04.49.19 # I did 04.49.32 # I was actually planning on chatting with you this arvo about it :) 04.49.53 # do you know if toni has got anywhere with the cop yet? 04.50.26 # last i heard he'd given up in order to work on the sansa itself 04.50.43 # i don't know what the final status of the emulator was, i haven't had a chance to try his latest version 04.51.01 # plus you need a complete sansa disk image to do so, and I don't have such an image handy 04.51.39 Quit JdGordon (Client Quit) 04.51.43 # the version i tried could navigate on pre-cop builds of rockbox and fill the PCM buffer if you tried decoding mp3s 04.52.53 # saratoga4: I am looking at the ut8decode function in unicode.c. can I even call these from a plugin? 04.55.01 # should be able to 04.55.09 # GRaTT: all the functions in the struct plugin_api in \apps\plugin.h can be used in plugins 04.55.37 # utf8decode is included among them 04.56.26 Join JdGordon [0] (i=82c20d66@gateway/web/cgi-irc/labb.contactor.se/x-7e4ae4c7da57bacf) 04.56.34 # saratoga4: sorry, comp problems 04.56.41 # did you miss my reply? 04.56.48 # yeah 04.56.50 # "the version i tried could navigate on pre-cop builds of rockbox and fill the PCM buffer if you tried decoding mp3s" 04.57.15 # hmm... im more interesetd in the OF.. 04.57.16 # i thought it would be useful for profiling code on ARM 04.57.26 # since you can intercept all the memory accesses and log them 04.57.28 Quit Topy (Read error: 110 (Connection timed out)) 04.57.41 Quit JdGordon (Client Quit) 04.57.42 # it worked on the bootloader, but crashed in teh OF due to lack of good COP support 04.59.15 Join JdGordon [0] (i=82c20d66@gateway/web/cgi-irc/labb.contactor.se/x-a7af8da7ca9c864a) 04.59.22 # 3rd time lucky :p 04.59.26 # hopefully.... 04.59.50 # saratoga4: rotator : thanks. It looks like viewer.c uses the utf8decode function to read the pla files. I will try. 05.00.49 # saratoga4: do you know how to compile the emu? i want to fiddle with it and try to see what the OF does differently if a sd card is presenty 05.01.05 # JdGordon: Hello, you left a reply on my m3u2pla converter at flyspry 05.01.12 # you need VS6 05.01.13 # gratt: hey, yeah, the pla is unicode which is why the nulls are there.. 05.01.30 # JdGordon: I made some of the changes you suggested 05.01.33 # I tried in vain to get the free VS package to compile it, but even with teh SDK installed, it claimed it couldn't find stuff 05.01.52 # though theres almost no Windows specific code at all. so if you have any c++ background, you could port it pretty easily 05.01.55 # JdGordon: unsure of mutlti-screen api for display 05.01.58 # GRaTT: I saw the comment, havnt looked at the code yet though 05.02.28 # JdGordon: trying now for pla->m3u 05.02.31 # I can make it looks nice for you if you need (I dont tihnk it needs a display anyway...) 05.03.02 # the annoying thing was figuring out what files it actually needed, and the required files had a habbit of changing between releases, so I usually used the "find" tool to look for file paths in the source code :) 05.03.08 # saratoga4: I installed vs6 yesterday so ill see how I go... does it need the updated windows sdk? 05.03.24 # I don't think so 05.03.44 # I had the SDK installed, but i don't think it needed it 05.03.55 # ok, great 05.03.58 # though i know nothing about win32 05.03.59 # makes things easier 05.04.06 Quit Hammer89 (Read error: 54 (Connection reset by peer)) 05.04.15 # JdGordon: have not coded C in 7 years, I am very rusty. Is there better (faster) way for display 05.04.19 # GRaTT: what was the FS #? 05.05.06 # but yeah, if you want to work on it, that'd be great, I really think we could use a good arm emulator since it seems nearly all the rockbox targets from here on will be arm 05.05.17 # JdGordon: JdGordon FS# 6884 05.05.51 # why the text editor has empty menu items? 05.06.14 Quit linuxstb (Read error: 113 (No route to host)) 05.06.20 # pearldiver: Spacing (I'm not fond of it) 05.06.36 # any reason for that? 05.06.38 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 05.06.43 # JdGordon: if display is on, each line is displayed it takes 15 min for 500 line playlist if off 1 second 05.07.59 # JdGordon: display was really for debug during developement 05.08.03 # GRaTT: you can do a splash with 0 timeout so it doesnt halt the proccess.... 05.08.45 # what you want is something like FOR_NB_SCREENS(i) { rb->screens[i]->lcd_puts(0,0,"some text"); } 05.09.18 # FOR_NB_SCREENS(i) { rb->screens[i]->lcd_puts(0,0,"some text"); rb->screens[0]->update(); } 05.09.19 # even 05.09.50 # JdGordon: doing this multiple times would be faster? 05.09.59 # dont we have a ascii->utf8 function? 05.10.19 # JdGordon: there is an utf8decode 05.10.23 # well, the way you have the splsh is it stops the proccess for 1 sec 05.11.07 # JdGordon: I will try with 0 time out first for simplicity 05.11.54 # JdGordon: I am looking at implementing the utf8decode as in viewer.c to read in the pla file 05.12.30 *** Saving seen data "./dancer.seen" 05.12.54 # if its there already you can add it to the plugin api (plugin.[ch]) so you can use it without recoding it 05.13.30 Quit saratoga4 ("CGI:IRC") 05.15.46 # JdGordon: can I call it directly? 05.16.33 # no, ou have to add it to the api 05.16.40 # then you call it like rb->utf8decode() 05.17.55 # JdGordon: it is called like that in viewer.c. Must be in the plugin api already? 05.18.44 # oh, then yes 05.20.47 # JdGordon: I just looked and do not see any info in PLUGIN_API 05.21.14 # if viewer.c is calling it like rb->utf8decode then your fine to do the same 05.21.44 Quit borisyeltsin (Remote closed the connection) 05.22.23 Join billytwowilly [0] (n=chris@S01060016b649355d.ed.shawcable.net) 05.22.27 # JdGordon: OK, thanks Thats more than enough to keep me busy for a while 05.32.39 Join toffe82 [0] (n=chatzill@ppp-69-238-94-116.dsl.frs2ca.pacbell.net) 05.34.04 # bye 05.34.18 Quit GRaTT ("using sirc version 2.211+KSIRC/1.3.12") 05.38.59 Join hachi [0] (i=hachi@shego.kuiki.net) 05.41.13 # so... uh... the 5.5g thread has been locked for 2 months now... does anyone even remember about that? 05.42.02 # Yes 05.42.03 # I do. 05.42.05 # And it's STILL TRUE 05.42.36 # Do you think we're going to finish it, and then forget to tell you? 05.42.55 # no, I think it's just fallen to the wayside and will never get done 05.43.05 # And what if it has? 05.43.26 # Nobody else is volunteering to rewrite the Rockbox FAT32 code. 05.43.58 # There is basically one person interested in working on it. And it's a job that doesn't split well. Either he'll get it done, if/when he has time, or he won't. 05.44.09 # Unless someone else comes along and volunteers, that's all you've got. 05.45.35 # So, facing that knowledge, what did you want? 05.45.56 # * joshin suggests that hachi find out who the dev is and bribes them 05.45.57 Quit JdGordon ("CGI:IRC (EOF)") 05.46.13 # nothing in particular... do you want people to just shut up and never say that they still would love to have support for the device? 05.46.18 # joshin: Money doesn't make the real world and family go away. 05.46.44 # hachi: I want them to stop opening new threads asking for status updates. I want them not to PM me asking for status updates. I want them to respect the 'Please don't bother asking about this' post in the forum. 05.46.48 # Llorean: Tell me about it... Wife + 2 kids + work == not so much project time 05.47.31 # hachi: I want them to not ask "does anyone even remember about that?" as if they think we've forgotten them. 05.51.07 # well, I'm sure that all us people are just wrong and assholes for ever asking, or being curious, or much of anything huh? 05.51.34 # I think that the phrasing asking if we've forgotten about you is very impolite. 05.51.42 # I think ignoring forum rules and starting a new thread on it is impolite. 05.52.01 # Just because someone's curious doesn't make the forum rules ignorable. 05.52.30 # Did you honestly think we'd forgotten about it, despite my editing the last post in the thread 3 weeks ago to further clarify? 05.53.00 # I have no clue how to ask kindly though. the forum doesn't show for me that you edit it 3 weeks ago... last update I see is like 2 Feb 05.53.19 # If you look at the last post, it says when it was last edited. 05.53.44 # I even explained why I locked the thread: Developers can post when there are updates, but we don't need people constantly asking the status. 05.54.29 # And you can ask kindly by saying "Hey guys, is there any progress on the 5.5G 80gb?" rather than phrasing it in a way where you've suggested that we've forgotten about it. 05.56.15 # My problem isn't that you're asking. 05.56.21 # sorry 05.56.28 # My problem is how everyone seems to ask, choosing both impolite phrasing or ignoring posting rules. 05.56.58 # There's nothing saying don't ask in here, just don't ask in the forums because it clutters the search, but you asked in a somewhat offensive way I thought. 05.57.13 # sorry bout that 05.57.23 # Anyway, status is this: Rockbox's FAT32 driver requires a lot more modification than the iPL one did because ours is very much trimmed down, and someone has to rewrite it. 05.57.49 # LinusN has suggested that he would do it, if/when he has time. Unless he finds time, or someone else volunteers to do it, that's where it'll stand. 05.58.58 # I was ticked about the ipl fixes... I wanted to watch the progress on that as the patches and attempts were made... but the developers only made a monolithic patch and there was nothing to be learned about 'thought process' from it 05.59.29 # Well, we know what needs to be done. 05.59.40 # Is there a key to the colors of the different patches in the tracker? I scanned the site and didn't see anything. 06.00.34 # joshin: Gray: Not yet modified/rated by a developer. Shades of Red reflect the severity from Low to Critical. 06.01.27 # Llorean: I'm looking at it from this perspective, I'm an engineer... mostly perl, but I play in C too... I don't really have a clue about embedded system or driver programming... I wish I did because I'd love to poke at it to see if I can get anywhere with it... that's why I wanted to see thought process in a similar project 06.01.30 # hachi: And sorry for jumping on you. People constantly PM me on the forums asking about that, or open new threads that I have to delete, so it's become a bit of a personal thorn in the side. 06.01.55 # Ok, thanks. Figured it was something along those lines. Now on to the documentation of how to build Rockbox from source and then to see if my brain can still think in C. 06.02.06 # oh, hey, there's something I've been meaning to ask about 06.02.30 # I've got a few-days-old build on my iriver h10 20gb 06.02.50 # and when playing wavpack and being in the WPS screen, it pauses the music for a second or two about once every minute 06.02.55 # if you exit out of the WPS, it's fine 06.03.02 # n17ikh|Lappy: Does your WPS have peakmeters? 06.03.09 # er, one sec, I never looked 06.03.15 # or can't remember. 06.03.43 # n17ikh|Lappy: Peakmeters, Crossfeed, Equalizer, Replaygain, Dithering, all of these use CPU. wavpack is not the most CPU-efficient codec. 06.03.53 # nope 06.03.55 # The WPS is more difficult to update (more CPU) than just filetree. 06.03.57 # I am using the EQ 06.04.02 # EQ is one of the worst 06.04.12 # I see. 06.04.22 # each band adds to it...if you can get away with less bands, the better it is 06.04.49 # actually, I'm not using the EQ proper 06.04.56 # I'm using the bass/treble adjustment though 06.05.28 # I thought it might have been running out of buffer while spinning the hard drive up so I increased buffer time a little and it seemed to help 06.05.52 # like a combination of a slow to spin up disk and CPU troubles 06.05.53 # no, right? because there is no cpu scaling for the gigabeat 06.06.03 # hey i have a question... does the EQ, crossfeed, etc. impact the battery life of the gigabeat? 06.06.15 # webguest89: Yes. 06.06.20 # my two previous posts are inverted... 06.06.39 # n17ikh|Lappy: The anti-skip buffer can help a little, but it's really not meant for that. 06.06.46 # yeah, I know it's not 06.07.09 # webguest89: even though there's no cpu scaling the cpu at idle will use less power than a cpu under heavy load 06.07.12 # webguest89: The Gigabeat CPU draws less power if you use it less, so more CPU intensive actions do drain more battery 06.07.42 # then what's the purpose for cpu scaling? 06.08.01 # because clocking down a very idle cpu will use much less power than leaving it at full speed 06.08.02 # On the Gigabeat, not as much as elsewhere. 06.08.16 # (I'm thinking in normal computing terms here) 06.08.18 # It doesn't seem to save power on the Gigabeat (and may even be worse) 06.08.36 # I have no idea how the gigabeat's hardware actually handles idling and such 06.08.45 # so maybe I shouldn't answer questions I know nothing about >_> 06.09.05 # it seems like an inherent feature of any cpu so why is there a need to scale? 06.09.25 # ohhhh 06.09.48 # thanks a bunch. 06.10.23 # n17ikh|Lappy: i wish more people understood your last statement around here ;) 06.13.09 # * Llorean wonders how long the initial charge of a Gigabeat takes. 06.13.17 # Soap: SYN 06.14.33 # ack 06.17.20 Quit Yono ("Leaving") 06.17.22 # Who's the best person to ping about wiki write accesses? I'm about to start the process of building RockBox for the Gigabeat and Sansa and figure that I can update the wiki as I go. 06.17.32 # I did register my account. 06.18.21 # there isnt anything to update about the process of building 06.18.38 # n17ikh|Lappy: you arent soap =/ 06.19.20 # How about in "Find your target CPU" a listing of what CPU the Gigabeat needs. I'm not expecting to find anything major. Just nitpicky stuff that would get asked over and over here. 06.19.51 # * joshin needs to get to bed to reset his grammar processor... 06.20.18 # "... a listing of what CPU target one should set for the Gigabeat F series" 06.20.24 # scorche: nope :/ 06.20.41 # joshin: You don't set a CPU target. 06.20.50 # joshin: While compiling it asks what target player you're compiling for, and you answer. 06.21.20 # the only questions that get asked over and over are about not having the path set up and questions about patching...no updated to the wiki are really needed 06.21.36 # scorche: Well, clarifications wouldn't be bad, really 06.21.46 # Llorean: such as? 06.21.49 # As long as they aren't of the sort that show up in the SimpleGuideToCompiling. 06.22.06 # scorche: I'm not sure, I'm just not willing to assume improvements can't be made. 06.22.48 # true....i guess we will have to wait till after he is done then =) 06.23.49 # The SimpleGuideToCompiling is anything but "simple" though, I think. It seems to talk in circles 06.24.25 # i forgot who pointed it out, but the un-simple-version we have in the wiki is quite a bit shorter 06.25.01 # Yeah 06.25.13 # The problem is ours assumes people can be told "you need to do this" rather than "type this" in a lot of cases. 06.25.18 # Llorean: fine. I'm just at the reading of the wiki stage and looking to see if I can get a toolchain building as I sleep. 06.25.37 # joshin: You shouldn't need to do anything special to build it. 06.25.51 # joshin: have you looked at rockboxdev.sh? 06.25.58 # joshin: In Windows, you download one of our kits. Cygwin or VMWare or Colinux. On linux / OSX, you just run Rockboxdevel.sh 06.26.03 # Or rockboxdev.sh 06.26.09 # Whatever its name is. :-P 06.26.17 # Llorean: you had it down before! 06.26.30 # I've never been able to remember it. 06.26.33 # I just get lucky sometimes. 06.27.12 # Nice. I very much like how simple the OpenSlug folks made builds for the NSLU2. Then again, OpenEmbedded isn't that tough to deal with either. I'll grab and read rockboxdev.sh. 06.29.32 Quit jhulst () 06.35.02 Join jhulst [0] (n=jhulst@adsl-69-208-79-209.dsl.klmzmi.ameritech.net) 06.36.19 Join ptw419 [0] (i=ptw419@216-188-249-122.dyn.grandenetworks.net) 06.37.49 Quit rotator () 06.47.57 Join Br3nda [0] (n=brenda@leibniz.catalyst.net.nz) 06.52.08 Join illriginal [0] (n=illrigin@c-66-229-128-235.hsd1.fl.comcast.net) 06.54.06 Quit webguest89 ("CGI:IRC (EOF)") 06.59.10 Quit illriginal ("Leaving") 07.02.43 Quit RaRe ("The Evolution of Medicine - 2000 BC - Here, eat this root. 1000 AD - That root is heathen. Here, say this prayer. 1850 AD - T) 07.12.33 *** Saving seen data "./dancer.seen" 07.15.35 Quit markun (kornbluth.freenode.net irc.freenode.net) 07.15.35 NSplit kornbluth.freenode.net irc.freenode.net 07.15.35 Quit HEx (kornbluth.freenode.net irc.freenode.net) 07.15.35 Quit furiousD_ (kornbluth.freenode.net irc.freenode.net) 07.15.35 Quit dionoea (kornbluth.freenode.net irc.freenode.net) 07.15.35 Quit hachi (kornbluth.freenode.net irc.freenode.net) 07.16.02 NHeal kornbluth.freenode.net irc.freenode.net 07.16.02 NJoin hachi [0] (i=hachi@shego.kuiki.net) 07.16.02 NJoin markun [0] (n=markun@rockbox/developer/markun) 07.16.02 NJoin HEx [0] (i=HEx@213-228-241-143.dsl.prodigynet.co.uk) 07.16.02 NJoin furiousD_ [0] (n=david@cpc1-blfs5-0-0-cust675.belf.cable.ntl.com) 07.16.02 NJoin dionoea [0] (n=dionoea@poy.chewa.net) 07.16.44 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 07.31.39 Join davina [0] (n=davina@cpc1-sout6-0-0-cust616.sotn.cable.ntl.com) 07.38.03 # * amiconn wonders about jhMikeS' commit msg 07.38.36 Join damaged_good [0] (n=bob@adsl-074-237-154-154.sip.bna.bellsouth.net) 07.44.14 # Llorean here? 07.44.20 # Yes 07.44.44 # did you have a chance what version of the OF your F40 has? 07.44.52 # to check* 07.45.28 # pearldiver: Where do I check? 07.45.48 # if i remember correctly its in the settings 07.46.00 # version info or something like that 07.46.35 # pearldiver: 2.020US 07.47.25 # me and toffe82 just agreed that all of his and mine gigabeats have serial numbers starting with a digit except for his rare'ish F10 which starts with X 07.47.59 # so i thought theres something different on this Y 07.48.15 # but 2.02 is the common case with local ones 07.48.24 # But the Champagne isn't supposed to be US release, is it? 07.48.48 # well you just confirmed that it was 07.49.10 # Apparently 07.49.22 # With a weird serial number. 07.51.56 # The system menu also says 4 played. 07.52.58 # you played 4 song with the original firmware :) 07.53.05 # Except I didn't 07.53.17 # even if you upgrade, this number stays 07.53.23 # I went through the set time/date/timezone stuff, and went straight to the system menu 07.56.00 # Llorean http://gigabeatwiki.matritic.net/index.php?gigabeatF 07.56.21 # see the 1st one from the pictures? 07.56.34 # thats the champaign i was hoping for 07.56.40 # Yeah, that's what I got 07.56.55 # Under some light it looks just like a shinier silver, under other light you can see the difference 07.57.05 # and even though it says champaign on the box it looks like the one towards the bottom 07.57.07 Part damaged_good 07.57.39 # The 60? 07.57.50 # gigabeat F40(????(XS)) 07.57.57 # Ah 07.58.04 # before the crazy colors start 07.58.09 # Try taking the champagne one out in direct sunlight and holding it at a slight angle 07.58.20 # Its tinting becomes much, much more apparent like that. 07.58.33 # hmm i should try tomorrow 07.58.48 # I thought mine was silver for a while too, but finally got it under some very white lights. 07.58.51 # but i havent noticed that "champaign" tint under electric light that much 07.59.13 # I can't see it at all under any of the incandescents in my apartment 07.59.19 # But in my kitchen, under flourescents, I can. 07.59.29 # ha 07.59.56 # Llorean: well, if you go outside, there is something called the sun.....almost makes going outside worth it ;) 08.00.16 # scorche: I did suggest outside 08.00.23 # But right now it's night here. :- 08.00.26 # :-P 08.00.34 # Llorean: yeah, but would you deny me the chance to make a sub-par joke? 08.00.47 # s/joke/attempt at a joke 08.00.51 Join Jon-Kha [0] (n=Jon-Kha@a91-152-69-9.elisa-laajakaista.fi) 08.01.12 # pearldiver: Oddly enough, through the lense of my digicam the coloring is MUCH more apparent. 08.01.30 # I was gonna take a comparison shot to show how subtle the difference is, but I don't think it'll work 08.01.40 # interesting 08.04.20 # How common are dead pixels on Gigabeats? 08.04.30 # never been reported 08.05.05 # Okay 08.05.18 # I have one 08.06.17 # I don't, on either, but I was wondering how lucky I am. 08.06.35 Join Rob2222 [0] (n=Miranda@p54b16da7.dip.t-dialin.net) 08.07.03 # 1st time i see anyone mentions a dead pixel on gigabeat 08.07.28 # it is light green 08.08.13 # Also, lightly shaking my gigabeat, there is a rattle. Common or no? 08.08.15 # is it common among ipods? 08.08.19 # * amiconn didn't see dead pixels on lcds for a looong time 08.08.30 # Llorean rattling is common 08.08.31 # pearldiver: None of my MP3 players has one. 08.09.05 Join ender` [0] (i=krneki@84.255.206.8) 08.09.28 # But every portable game system I've bought since the GBA has had one. 08.09.29 # on the 20 I worked on, I have only one with dead pixel 08.10.18 Join RaRe [0] (n=Laffin_B@202-89-187-101.static.dsl.amnet.net.au) 08.10.47 Quit davina ("byeeeeee!") 08.12.14 # i noticed for the last 5 days or so the battery life on my F20 is lower than usual 08.12.25 # i need to do a bench 08.17.37 # good night 08.17.41 Part toffe82 08.21.48 Quit Br3nda (Remote closed the connection) 08.23.26 Quit Rob222241 (Read error: 110 (Connection timed out)) 08.31.38 Join webguest69 [0] (i=c023110b@gateway/web/cgi-irc/labb.contactor.se/x-574e61ce76af6bd0) 08.33.50 Join himitsu [0] (n=himitsu@61.213.185.37) 08.42.30 Join rift [0] (n=rift@242.56.70-86.rev.gaoland.net) 08.44.44 Join RoC_MM [0] (n=Samus0@c-24-129-94-172.hsd1.fl.comcast.net) 08.59.07 Quit RoC_MM ("Leaving") 09.01.29 Join spiorf [0] (n=spiorf@host142-223-dynamic.1-79-r.retail.telecomitalia.it) 09.01.40 Quit JdGordon ("Konversation terminated!") 09.01.57 Quit webguest69 ("CGI:IRC") 09.09.59 Join petur [0] (i=d4efd6a6@gateway/web/cgi-irc/labb.contactor.se/x-c73ef8e9eb761461) 09.10.20 Quit RaRe ("The Evolution of Medicine - 2000 BC - Here, eat this root. 1000 AD - That root is heathen. Here, say this prayer. 1850 AD - T) 09.12.34 *** Saving seen data "./dancer.seen" 09.13.51 Quit miepchen^schlaf (Read error: 60 (Operation timed out)) 09.13.53 Join Zagor [0] (n=bjorn@rockbox/developer/Zagor) 09.16.50 Join crop [0] (i=c27f0812@gateway/web/cgi-irc/labb.contactor.se/x-1c95bcc719a355c4) 09.17.20 # Hello. Assumed I have the lyrics id3 tag filled, how can I display the contents of the tag in a readable way? 09.19.20 Join JdGordon [0] (i=dced3920@gateway/web/cgi-irc/labb.contactor.se/x-5de772c4dc43c3d0) 09.21.20 # crop: from a coding standpoint, or..? 09.21.36 # there's no way to do it in rockbox currently, you'd have to code such an ability. 09.22.32 # there is a plugin to display lyrics somewhere, you could take a look at that 09.22.58 # crop: thats another job for metadata on buffer... 09.23.33 Quit JdGordon (Client Quit) 09.23.55 Quit himitsu (Remote closed the connection) 09.24.06 Join Br3nda [0] (n=brenda@leibniz.catalyst.net.nz) 09.27.42 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 09.27.50 # amiconn: Am I right in thinking jhMikeS's SPDIF commit didn't actually change any code? 09.28.31 # It certainly doesn't look like it did. 09.28.47 # midkay: no, as a user. 09.28.53 Join himitsu [0] (n=himitsu@61.213.185.37) 09.29.01 # crop: no such way currently, then. 09.29.44 # midkay: :-( It's possible to show all mp3 tags of the song but I doubt that the lyrics will be readable then 09.30.10 # linuxstb: He did say he committed a bugfix in the forums, but that looks like it's just a clarification. 09.30.22 # I've searched the forums, there is a SNC plugin but it's not what I mean. My lyrics are in the tag, not as a separate file 09.30.32 # crop: not sure what you mean, "all mp3 tags". 09.30.38 # crop: Well, lyrics aren't supported, as you were told. 09.30.53 # But I'm pretty sure "View ID3 info" is still limited to the tags Rockbox supports. 09.30.58 # crop: well, as i said, there is no current way to do it. that's that. maybe at the end of the summer when metadata-on-buffer is (hopefully) done there will be a way. 09.31.29 Quit himitsu (Client Quit) 09.31.31 # Llorean: i'm pretty sure of that as well. i can't see it magically supporting tags we haven't added support for.. 09.31.37 # Llorean: Oh! I thought all id3 tags are displayed, i.e. all that are in the file 09.31.55 # midkay: ok, I'll ive with that. Thanks for the info 09.32.21 # crop: no problem. 09.32.45 # crop: No, only the ones parsed and stored by Rockbox - there are many different id3v2 frames and Rockbox only handles some of them. 09.33.11 # I thought that the tags are also stored somewhere in a generic form, i.e. "key=value" and that only some tags are assigned to data structure fields and thus can be treated in a "special" way 09.33.34 # id3v2 doesn't use key=value afaik. 09.33.36 # linuxstb: yes, now I see I was wrong 09.34.02 Join inversions [0] (n=none@cpc3-bele3-0-0-cust660.belf.cable.ntl.com) 09.37.07 # Bah, icons make me want to use non-tiny fonts. 09.37.09 # * Llorean mutters. 09.37.19 # hehe 09.38.04 # I think I'm using a 9 or 10 tall font right now on my Gigabeat. 09.38.37 # so it shows about 80 lines on the screen? 09.38.50 # you mean 32? :) 09.39.02 # hello 09.39.19 # It shows "lots" 09.39.23 # Which is good enough for me. :) 09.39.37 # linuxstb: is it expected that the dap (ipod video here) shuts down automatically when runing mpegplayer ? 09.39.49 # I'm slowly in the process of creating my own very, very tiny icon set. 09.39.58 # dionoea: It should not idle power off. 09.40.00 # (btw, looks like the 44.1kHz right, subs stayed synced for about 5 minutes ... before it shut down) 09.40.07 # hum ... weird 09.40.22 # Llorean: Others have reported mpegplayer ignoring the idle poweroff. 09.40.30 # linuxstb: It never has for me. 09.40.36 # Even on the Nano? 09.40.45 # I've watched a 22 minute video on the Nano 09.40.52 # I can't remember it doing so either, but maybe I've disabled the idle poweroff.... 09.40.59 # It's enabled on my GB at least 09.41.15 # I'll try disabling it in the code to see if it still shuts down 09.41.26 # It'll idle power off if pause or in the menu 09.41.32 # But not in videos, for me at least 09.41.40 # Though I've not tested much on my Nano. 09.42.37 # It's set for 10 minutes on my Nano, and I got a full 22 last time I tried, but it was weeks ago 09.42.45 # my gigabeat also never shutdown during video playback 09.43.41 # i guess that a bug in the code is highly unlikely to trigger a shutdown right? (It'd print some debug output on screen and freeze) 09.43.58 # Does it just power-off, or do a clean shutdown? 09.44.07 # i.e. display the "Shutting down" splash? 09.44.23 # it displays a splash for like 1/2 a second 09.44.43 # i don't know what that was about ... but it did look like a power off 09.45.44 # low power maybe? 09.45.49 # Very possible 09.46.09 Join barrywardell [0] (n=barrywar@host-194-46-226-229.dsl-ie.utvinternet.net) 09.46.14 # 22 minutes of playback with backlight sapped a lot of battery on my Nano 09.46.46 # markun: well i could playback a full audio album afterwards (and battery level displayed 75%) 09.47.12 # so low power would be kind of unexpected 09.47.52 # unless the battery somehow freaks out if you draw too much power rapidly and then comes back to normal behavior when you restart 09.47.57 # dionoea: But you said it played for 5 minutes. Is your idle shutdown time reduced to 5 (the default is 10, I think)? 09.48.24 Quit Br3nda ("Konversation terminated!") 09.48.30 # well maybe it was 10 :) (It was before the end of elephant dreams ... so less than 9 minutes right?) 09.49.20 # I'll try to time it exactly next time 09.49.22 # You could load elephants dream on a PC and find out how many minutes it was. 09.49.28 # Just fast forward to roughly where you were 09.49.33 # hehe :) 09.49.39 # If it's some number like 7:30, then it's less likely that it was idle 09.50.06 # "Less" being the operative bit, since I don't know whether you adjusted volume 'n whatnot. 09.50.56 # But that's weird if iPods are doing that. 09.55.09 # Looking at the code, it looks like mpegplayer should idle-off... 09.55.48 Join norbusan [0] (n=norbusan@chello213047086216.5.14.tuwien.teleweb.at) 09.56.00 Part norbusan 09.59.19 Join himitsu [0] (n=himitsu@61.213.185.37) 10.02.12 # amiconn: is the bitmap format variable always set to FORMAT_NATIVE when read with read_bmp_file()? 10.02.51 # Re displaying the lyrics: could we change the id3 parsing code so that not all known tags are stored in mp3_entry? Then a plugin could read them all in a generic way. And some (those supported by RB) would be stored in mp3_entry 10.04.24 # As of now (iiuc), all registered tags are copied to mp3_struct and, possibly, postprocessed 10.04.24 # crop: There is very little room in an mp3_entry. We don't want to enlarge it. 10.05.10 # But that's what the "metadata-on-buffer" feature is intended to allow. 10.05.19 # linuxstb: I don't propose this. Just allow to register tags that won't be copied to mp3_struct. But allow to register a processing func for them. 10.05.55 # Then a plugin could read all of them as key-value pairs. 10.06.19 # And RB would only care about the supported tags. 10.06.41 # Where would the processing function live? And where would it store the data it's reading from the tags? 10.08.10 # linuxstb: the processing function could live anywhere. Some would in id3.c (as they are now), but others could be provided by the plugin. A flag should be added to the struct tag_resolver whether the tag is supported. 10.09.12 # Or we could have two funcs there: "main processing" and "postprocessing". "Main processing func" for the supported tags would just copy the tag to mp3_info. 10.09.35 Join roolku [0] (n=roolku@82-41-2-141.cable.ubr01.edin.blueyonder.co.uk) 10.09.42 Quit ptw419 () 10.09.44 # And do nothing for unsupported tags 10.12.44 Quit inversions (Read error: 60 (Operation timed out)) 10.12.48 # I.e. the parser could/should be given the array of tag_resolver. Internal RB parser would have its array (very similar to the current) but a plugin could provide other processing 10.13.24 Quit Llorean (Read error: 110 (Connection timed out)) 10.15.31 # linuxstb: does this sound reasonable? Or do I misunderstand the RB way of parsing files? 10.15.33 # crop: If the parsing functions are living in core Rockbox, then why do we need a registration system? If they are in a plugin, then what happens when a user is running a different plugin when the playback engine is parsing the metadata for a new track? 10.15.43 Join bluebrother [0] (i=ZXmshA2l@rockbox/staff/bluebrother) 10.16.48 # linuxstb: the parsing func are passed as a parameter (fields in tag_resolver). So everyone can do with the tags what's needed. 10.17.09 # No, not parsing func, but processing funcs. 10.17.30 # And also the set of the known tags. 10.17.54 # I.e. all that's in tag_resolver 10.18.39 Join brun0_ [0] (n=brun0_@che78-2-82-227-240-106.fbx.proxad.net) 10.20.16 Quit heanol_ (Remote closed the connection) 10.20.35 # A plugin would just reuse the available parsing code but would provide its own set of callbacks. The signature of the callbacks would need to change. It could be something like process_tag(char *tag_name, char *tag_value, struct mp3entry *entry) 10.21.39 # The funcs provided by the plugin would e.g. just ignore the entry but rather collect the tags in a list of key-value pairs. 10.22.16 # And the funcs provided by the core RB would copy the supported tags to the entry 10.24.06 Join heanol [0] (n=henrik@karantan.org) 10.24.32 Join obo [0] (n=obo@host217-41-62-170.in-addr.btopenworld.com) 10.25.39 # My sim keeps crashing with *** glibc detected *** ./rockboxui: double free or corruption (fasttop): 0x0a26f688 *** when running a .rock I'm working on, would appreciate any help in the matter. 10.25.48 # linuxstb: no comments? 10.25.49 # So how big would the mp3_entry struct be? 10.27.10 # linuxstb: it wouldn't change at all 10.27.43 # So where would this extra data be stored? 10.27.44 Quit kkurbjun (Read error: 113 (No route to host)) 10.27.57 # aliask: gdb rockboxui 10.28.18 # linuxstb: in some buffer somewhere in the plugin. 10.28.26 # aliask: your not trying to use threads or TSR plugin? 10.28.40 # crop: But what if the user is running a different plugin when the file needs to be parsed and buffered? 10.28.45 # JdGordon: Nope, just calling a plain ol' function. 10.28.55 # Seems to be where it crashes. 10.29.16 # gdb is your freind :p 10.29.28 # * aliask has never used it 10.29.45 # run gdb rockbox ui, then type r 10.30.01 # when it crashes type bt and it will show you the callstack 10.30.09 # linuxstb: I think we are in different dimensions and you don't quite understand me. My proposal is that we decouple the parsing logic from the processing logic. 10.30.11 # so you can see where it crashed and hopefully why 10.30.24 Quit rift (Read error: 104 (Connection reset by peer)) 10.30.42 Quit atsea-87 (Remote closed the connection) 10.30.59 # crop: You're right, I don't understand... How can your plugin process something that isn't stored anywhere? 10.31.12 # linuxstb: the parser just finds the tag and calls the callback. Core RB provides its set of callbacks that store the supported tags in mp3_struct. 10.31.37 # crop: But you're saying the callback is in a plugin? 10.32.11 # But a plugin (for example the (non existing) one for displaying lyrics) could provide another callback 10.32.42 # linuxstb: yes, the callback is in the caller of the parser. This can be core RB or a plugin 10.34.11 # OK, so if the user wasn't running the plugin, the data would just be ignored? 10.34.34 # linuxstb: As of now, it's impossible to pass the set of the tags we're interested in and funcs for their processing from the outside. Everything is in id3.c. I'd like this to be changed. 10.35.17 # linuxstb: if the user wasn't running THAT plugin then yes, the data is ignored since the core RB doesn't care about it 10.36.03 # linuxstb: You're right, jhMikeS' commit didn't change the actual code. It's just a more complicated way to write it 10.36.23 # * amiconn doesn't understand JdGordon's question 10.37.09 # amiconn: the bmp loader, will it always set the format variable in the bitmap struct to native unless its a full colour bitmap? 10.37.20 # crop: OK, so you're proposing a mechanism for plugins to gain access to the track metadata? 10.37.59 # * amiconn still doesn't understand 10.38.12 # linuxstb: yes. And not necessarily the currently playing one. 10.38.20 # amiconn: or... if you read a mono bitmap on a colour target, can you use that to be able to draw it with the mono funciton? 10.38.22 # The bmp loader can be instructed to load a bmp either in native or mono format, or to auto-detect 10.38.44 # In th elatter case, it will load 1-bit BMPs as mono, all others as native 10.38.45 Join atsea- [0] (i=ariel@gateway/tor/x-499c2aa9d59a23cf) 10.38.46 # crop: Go ahead and write a patch. Don't forget all the other tag formats Rockbox supports though. 10.38.54 # JdGordon: Thanks for pointing out gdb... pretty sure i've got it now 10.39.24 # linuxstb: you could select a file and "open with..." it with this plugin. And see all the tags in the file (and not only the supported) 10.39.38 Join RaRe [0] (n=Laffin_B@202-89-187-101.static.dsl.amnet.net.au) 10.40.10 # amiconn: int bmpformat = (FORMAT_NATIVE|FORMAT_DITHER); <- does that set it to only load it as native and not auto-detect? 10.40.23 # linuxstb: where does the parsing code reside? Only in id3.c? 10.41.06 # crop: For historical reasons (the hwcodec playback engine lives in firmware/) id3.c contains the id3 parsing code, and the rest (used by swcodec only) is in apps/metadata.c 10.41.32 # the wps code uses FORMAT_ANY|FORMAT_TRANSPARENT.. shoudl icons use that instead so we can load mono on colour targets? 10.41.49 # ... so they can be displayed with mono_bitmap_part 10.42.23 # linuxstb: ok. And we could onyl change this for id3 as a start. Hence the plugin would only work with mp3 files. And if that works good then this can be expanded to other formats as well. 10.43.14 # linuxstb: but I dont' have much time now so the plugin will not come very soon. 10.43.17 # FORMAT_ANY is for auto-detection, but then you need to check what you got from bmp_load 10.44.04 Quit barrywardell () 10.44.06 # That's why I said a few days ago you want to do the second step before the first. All this will become really simple when there will be only one bitmap drawing function instead of 3 10.45.14 # how far down the todo list is that? 10.47.06 Join Llorean [0] (n=Llorean@166.205.76.176) 10.50.55 # JdGordon: Can you explain how the icon numbers in the .icons file and the viewers.config file are processed? There are still different icons listed in viewers.config for WAV files for example - so which icon is actually used? 10.51.20 # I thought I changed the wav icons so they were both the same? 10.51.41 # There are 4 entries for WAV, two with "-" and two with "10". 10.51.53 # ok, i'm going to try explainig it on the wiki better, Ive explaired it 3 times in irc already :p 10.52.19 # Also, txt and jpg have the same icon... 10.52.23 # which part dont you get? the numbers? or which icon is used? 10.52.47 # How the various files are processed to decide what icon is used for a particular extension. 10.53.02 # ok, 5 min 10.53.45 Join Siltaar [0] (n=Siltaar@reverse-52.fdn.fr) 10.54.11 # In fact, txt is listed three times in viewers.config, with three different icon numbers... 10.55.05 # viewers.config isn't mentioned at all on the CustomIcons wiki page. 10.55.42 # viewers.config shouldn't be modified. 10.55.50 # The .icons file is basically an override for it. 10.56.19 # Why bother with that? Why not just always have a .icons file and leave icons out of viewers.config? 10.56.21 # That way people aren't including replacement viewers.config files with themes that overwrite the one in the .rockbox folder and remove any custom lines. 10.56.32 # linuxstb: That's what I suggested, I'm not sure why it wasn't done that way. 10.56.59 Join Entasis [0] (n=Jarred@ppp48-102.lns11.adl2.internode.on.net) 10.59.36 # possibly one less file to parse if it stays in the .config 10.59.49 # 1 less to make sure gets into the build.. 11.02.21 # linuxstb: http://www.rockbox.org/twiki/bin/view/Main/CustomIcons#How_does_it_decide_which_icon_to 11.02.27 # hopefully that clears it up a bit 11.04.05 Join LinusN [0] (i=linus@rockbox/developer/LinusN) 11.04.17 # So you could just remove the icon field from viewers.config for all already-supported filetypes? 11.04.51 # yes 11.05.03 # except, aparently wav needs an icon for archos? 11.05.04 Join miepchen^schlaf [0] (n=hihi@p54BF61CB.dip.t-dialin.net) 11.06.10 # linuxstb: Without .icons, viewers.config decides which icon number is used for viewer-supporte3d formats 11.06.34 # I don't think that should be removed, unless we aways want to ship an .icons file 11.06.46 # well... its more the other way around... .icons overrides .config.. 11.06.48 # s/aways/always/ 11.07.23 # * amiconn wonders how this is the other way round 11.07.47 # umm... hmm.... 11.07.49 # * JdGordon shuts up 11.08.18 # your way sounds like the .icons is checked for before viewers.config... 11.08.40 Join rift_ [0] (n=rift@242.56.70-86.rev.gaoland.net) 11.08.45 Quit pearldiver (Read error: 110 (Connection timed out)) 11.08.54 Quit crop ("CGI:IRC") 11.10.16 Join barrywardell [0] (n=barry@dhcp-892b9a54.ucd.ie) 11.12.36 Join Br3nda [0] (n=brenda@121-73-1-165.cable.telstraclear.net) 11.12.39 *** Saving seen data "./dancer.seen" 11.13.43 # So what's involved in a user adding a new file extension to viewers.config? They'll need to refer to an icon in the viewers icon file, which may be in a different order depending on the iconset author? 11.13.49 Join PaulJam [0] (n=pauljam@vpn-3124.gwdg.de) 11.14.27 # minimum they do is add the extension and a plugin 11.14.49 # But if they want an icon to appear? 11.14.49 # which has always been the case 11.15.27 # then they would add the icon to the default viewers.bmp for all targets 11.16.22 # * JdGordon see's about getting some tucker, back later 11.20.35 # JdGordon: i noticed, that Icon_Cursor and Icon_Reverse_Cursor are used in the virtual keyboard, which uses the systemfont (unless you use a custom layout) and this looks a little bit weird with icons that are larger than the default ones. 11.22.58 Quit juxtap (Read error: 60 (Operation timed out)) 11.26.58 # i think i haven't understood this thing: it's viewers.config or theme.icons that decides the icons to use? 11.27.18 # spiorf: viewers.config unless there's a theme.icons 11.27.43 # theme.icons is an override file if they want to put their viewer icons in a different order, or have more than the standard viewer bitmap. 11.32.24 # btw, are the icons 8 (magnifying glass) and 9 (double note) in the viewers.bmp actually used somewhere in rockbox? 11.35.06 Join pondlife [0] (n=Miranda@cpc3-rdng11-0-0-cust229.winn.cable.ntl.com) 11.37.53 # amiconn: I'm talking about removing any numbers from viewers.config which aren't actually used. IIUC, if when a viewers.config is processed, if there is already a built-in icon for that extension, then the icon number in viewers.config is ignored. 11.38.15 # Is it? 11.38.22 # amiconn: So for WAV, we would need to keep the icon for the wavplay entry, but not the others. 11.38.45 # Afaik, before themable icons, no viewers-supported extension used a built-in icon 11.38.49 # That's what JdGordon just wrote on the wiki - "this means that icons for already known filetypes are ignored from this file." (regarding viewers.config) 11.39.20 # amiconn: mp3encode and a few others did, at times, I believe. 11.39.24 # amiconn: The wav viewer... 11.39.45 # hmm 11.40.04 # But then, the icon in viewers.config was ignored before (set to 00 00 00 00 00 00) 11.40.06 Join Llorea1 [0] (n=Llorean@cpe-66-69-210-194.austin.res.rr.com) 11.40.21 Quit Llorean (Nick collision from services.) 11.40.25 Nick Llorea1 is now known as Llorean (n=Llorean@cpe-66-69-210-194.austin.res.rr.com) 11.40.26 # Same if multiple viewers are associated with the same extension 11.41.58 # So why not remove any duplicates, and any that have builtin icons? 11.44.17 # Remove from where? 11.44.58 # I'm talking about removing any icon entries from viewers.config which aren't actually being processed. 11.45.14 # Just to make it clearer what's going on. 11.45.26 Quit atsea- (Read error: 104 (Connection reset by peer)) 11.45.47 # amiconn: In viewers.config, remove the icon numbers. 11.45.54 # For the ones that aren't actually used. 11.46.54 # Llorean: i could imagine that removing duplicates from the viewes.config could confuse themers, because if one line for txt files has a "1" at the end and one a "-" it would be unclear if the icon is inbuilt or taken from the viewers.bmp 11.47.43 # PaulJam: Make the first one the numbered one, all latter ones -, then I think the assumption will be "It's already set, up above, no need to re-set" 11.48.16 # PaulJam: That's my point - why does viewers.config contain 3 different icons for .txt ? 11.48.46 # and extensions that use inbuilt icons already have "-" at the end of the line (except wav and bmp, but i guess these are special cases) 11.50.18 # linuxstb: It doesn't. I can only see 2 (the second one most likely being a mistake). The third is '-', meaning "already set" 11.50.41 # amiconn: For which extension? 11.51.32 # txt 11.51.33 Quit Br3nda ("Konversation terminated!") 11.52.50 # The three entries I see are "1", "2" (meaning take the icon from the viewers icon.bmp) and "-" meaning "no icon". 11.53.29 # The wiki page defines "-" as meaning "no icon". 11.53.35 # At least in the "icons" file... 11.55.08 # The 2 is a mistake, should also be - 11.55.41 # Obviously the same extension cannot have multiple icons 11.56.09 # in my opinion it would be clearer if they were all set to "1" 12.01.16 # But it would be wrong - the entry isn't used 12.01.36 # I'm thinking it could simplify things if all extensions listed in the default viewers.config had icons in the main iconset. That would leave the second icon file purely for user-added extensions (so wouldn't be needed for most users) and icon information could be removed from viewers.config completely. 12.02.37 # viewers.config exists because we do not want the list of viewer-supported files built in 12.03.01 # Making the icons for them built-in would break that concept 12.03.09 # Out of curiosity, why don't we want that list built in? 12.03.35 # At least, the default list that is. 12.03.49 # I think of the viewers the same as the codecs - they're only external to cut down on binary size. 12.04.25 # linuxstb: The problem with viewers is that you may want to associate them with many more filetypes 12.04.25 # Because they are dynamic. E.g. if someone doesn't need support for jpeg, he could take out the appropriate line from viewers.config and delete the viewer 12.04.25 # third-party viewers and codecs just haven't happened... 12.04.25 # For example, .1st, .nfo, .html, etc could all validly be associated with viewer 12.04.55 # With the viewers.config system, jpg files will then no longer be displayed as supported 12.04.59 # I still think the best solution is to just include a default .icons file to go with the default viewer icons. 12.05.05 # And strip icons from viewers.config entirely 12.05.24 # amiconn: Yes, and they could still do that. If no viewers are mapped to an extension (and that extension isn't used by the core), then they wouldn't be shown as supported. 12.05.32 # linuxstb: Following your binary size argument, making the viewers supported icons bult-in doesn't make sense... 12.05.58 # I thought the icons were now loaded from an external .bmp? 12.06.24 # But yes, there's still the increase in size from hard-coding the supported extension. 12.06.44 # The default icons for core-supported formats are bult-in as before 12.07.13 Join mots [0] (n=mots@193.170.44.2) 12.07.20 # The default viewer icons are external as before, just not defined directly in viewers.config but as a .bmp referenced by viewers.config 12.07.53 # is it normal that the rockboxpatcher for ipods takes years for "scanning disk devices"? 12.08.06 # amiconn: OK, I didn't realise that... 12.08.07 # And the viewers-supported extensions weren't hardcoded before and aren't now either. 12.08.07 # mots: what's rockboxpatcher ? 12.08.16 # *ipodpatcher 12.08.47 # mots: It was only released a few months ago... 12.09.08 # linuxstb: hehe - good answer 12.09.34 # amiconn: why do icons need to be related to viewers (or even core support) anyway? they could be completely disassociated, just have a built in extension->icon mapping which can be overridden by a theme set 12.09.50 # mots: It should only take as long as any disks in your system which may be sleeping take to wake up. So if it's more than about a minute, something is wrong... 12.09.53 # seems the least complex and most flexible approach 12.10.36 # roolku: If they were removed from the viewers.config file, and always used a .icons file, that would essentially be the case. 12.15.34 Quit scorche (Read error: 104 (Connection reset by peer)) 12.18.55 # hmm 12.19.07 # i tried to create my own icon theme 12.19.19 # with 11x12icones 12.19.38 Join scorche` [0] (i=scorche@rockbox/administrator/scorche) 12.19.49 # but rockbox doesn't "cut" perfectly the icone from de toolbar 12.19.53 Nick scorche` is now known as scorche (i=scorche@rockbox/administrator/scorche) 12.20.04 Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) 12.20.44 # maybe i have to specify hte size of my icones ? 12.21.02 # rift_: i'm not sure what you mean 12.21.54 # rift_: I believe Rockbox determines your icon size by your main icon bitmap. 12.22.07 # How many pixels tall, total, is it? 12.22.15 # 372 12.22.34 # That's not the right number 12.22.44 # That would give an icon height of 11.625 12.23.02 # it should be 12x32 = 384 12.23.05 # There are supposed to be 32 main icons, so if your icons are N tall, the image should be N*32 12.23.06 # shit 12.23.10 # i have forgotten one icon 12.23.11 # :D 12.27.32 Quit miepchen^schlaf ("Verlassend") 12.27.57 # pondlife: Oops. I read the post yesterday, and then responded to it today without re-reading it. =/ 12.29.41 Quit mots (Read error: 104 (Connection reset by peer)) 12.31.34 Join miepchen^schlaf [0] (n=hihi@p54BF61CB.dip.t-dialin.net) 12.31.52 Join Br3nda [0] (n=brenda@121-73-1-165.cable.telstraclear.net) 12.31.53 # Llorean: We do have too many options 12.32.27 # Perhaps, but those ones are actually useful. 12.32.50 Quit Siltaar (Remote closed the connection) 12.32.51 # I guess you might want to use the hold switch to force the backlight on? 12.32.52 # hmm, there seems to be something wrong with the setting for the line selector. if i set it to pointer it doesn't write anything to the config.cfg and when i set it to Bar (inverse) it writes "invert cursor: off" to the config.cfg 12.33.00 # pondlife: I force it off, rather than on 12.33.05 # Ah, ok. 12.33.37 # pondlife: I have backlight set to a long timeout (20 second) with hold turning it off. That way it rarely fades on me while I play Bejeweled or something similar (anything I stop to think in), but it will fade if I leave it without remembering to turn on hold 12.33.41 # I'm using the hold switch to torn off the backlight too. 12.33.42 # Meanwhile hold lets me force it off quickly 12.34.27 Join Siltaar [0] (n=Siltaar@reverse-52.fdn.fr) 12.35.18 # Wow, amazon are doing a cheap-ish Sansa too.. 12.35.27 # http://www.amazon.co.uk/Sandisk-Sansa-e280-Video-Player/dp/B000IT62UK/ 12.35.37 Quit lini (Read error: 110 (Connection timed out)) 12.37.21 # pondlife: I think I can get it for $20 US less if I just go down the street to best buy 12.37.49 # But that's cheap for the UK 80GB model. 12.37.57 # Ah, perhaps in the UK, yes. 12.38.03 # 8gb, by the way 12.38.34 # Ah I saw e280.... my mistake 12.38.42 # Not so good then! 12.38.53 # The sansas only come in 2, 4, 6, and 8 12.39.07 # And that price is pretty much standard for the 8 here in the US. Or at least in the standard range. 12.39.16 # I wish they'd used sensible numbers 12.39.17 # Guess I'll wait for those 80GB Toshiba drives to get cheaper. 12.39.37 # Why the 250 = 2, 260 = 4, 270 = 6, I'll never guess 12.39.48 # The 280 = 8 was just luck on their part when they decided to release a new model later 12.39.49 # To confuse me I guess 12.40.37 # Supply still seems very restricted on those 80GB drives - maybe I didn't look well enough, but I could only find one seller selling them. 12.40.49 # Indeed, and that's not helping prices 12.41.02 # roolku: The point is that the extension->icon mapping for extensions supported by viewers should *not* be built in 12.41.50 # Right now viewers.config defines both the icon and the viewer associated with an extension, which is the right way imho 12.42.06 # amiconn: I agree it shouldn't be built in, but why not split the extension->viewer mapping from the extension->icon mapping? 12.42.07 # The only deviation is that only the first icon mapping matters 12.42.14 # Why is the right way to define both the icon and the viewer in the same file? 12.42.20 # The icon represents the extension, not the viewer. 12.42.37 # That's true, but then we need to load 2 files instead of one 12.42.42 # i tried to compile rockbox simulator for ipod nano on freebsd, but y have an error, 12.42.45 # gmake[1]: *** No rule to make target `SDL.h', needed by `/usr/home/rift/src/rockbox/sim/sim/button.o'. Stop. 12.43.41 # amiconn: Is that really so bad, to load 2 files instead of 1, if it provides a clearer separation of concepts? 12.44.21 # Llorean: I'm amazed you don't get tired of moving forum posts; it seems rare that anyone actually starts a topic in the right place :( 12.45.09 # pondlife: Yeah, I need to figure out how to make the naming clearer I think. I blame myself. I have an intent, but I've not communicated it as clearly as I'd like, I guess. 12.45.15 # The installation/removal sections are much abused. 12.45.33 # It's mostly the player-specific areas, because people think of them as everything player-specific rather than "Installation/Removal questions" 12.45.45 # Maybe they should all be merged? People see their player type and go straight in. 12.45.57 # i.e. have a Getting Started section instead? 12.46.38 # "ooh ooh, I've got one of those!" 12.50.51 # Well, the installation process is the only really... unique-by-player stuff. Or at least, it's 90% of the the uniqueness of any given player 12.51.00 # PaulJam: that was part of my sinister plan to get someone to completly redo the vkeyboard! 12.51.03 # I was tempted to break it up by install process instead. 12.51.45 # Like, have a section named "FWPatcher related installs" with the subtitle "H100, H300 installation help" and "Ipodpatcher Installs" subtitled "Help for installing on all iPods" and so on. 12.55.09 # If RBUtil gets finished, they can all be replaced with an "Installation Help" forum, probably. 12.56.51 # now that the UI stasrts to become very beautifull I would like to see a modified status bar, at least the font size seems to be critical for targets with big screens 12.57.20 # petur, pondlife: One of you wanted proper unicode support in the windows sim. Wanna try a patch? 12.57.28 # thats pretty much the last thing that needs prety-ifiyng/// 12.57.32 # Yes please 12.57.47 # The only characters the status bar ever uses are 0-9, :, and %, right? 12.58.17 # Llorean: the rec screen does some funny stukk with it 12.58.19 # and the volume and battery graph, but yeah these are not characters 12.58.20 # but usually, yes 12.58.29 # JdGordon: Then the status bar could be represented by a single bitmap. 12.58.38 # I think the status bar should go the wps route 12.59.34 # JdGordon: what about the status bar on the menu? or you mean to have parsing for the status bar like wps? 13.00.16 # pondlife, petur: http://amiconn.dyndns.org/win32unicode.diff 13.00.19 # The status bar could have its own limited font buffer, for just those 12 characters, so that it could use any font regardless of UI font? 13.00.55 # XavierGr: I think we wait till viewports, then make the statusbar a seperate vieport which can be customised like the wps 13.01.00 # Then the other symbols it used could be defined in a .bmp, and the status bar definition file could just let you pick the order each status bar widget is displayed from left to right, and spacing between 'em 13.01.11 # I don't think it needs strong customiziation. 13.01.38 # Just, using pseudotags, [battery meter][13 pixels][volume meter][12 pixels][clock] 13.01.38 # Llorean: The battery and volume graph are calculated 13.01.42 # it would be nice to have the list title in the status bar if font/lcd allowed it 13.01.52 # amiconn: They can be with .bmps too 13.02.05 # Especially battery can't easily be composed with bitmaps 13.02.09 # amiconn: Battery frame, always drawn in full, battery filler, drawn horizontally L->R based on % 13.02.18 # Much like progress bars in WPS 13.02.22 # There are 2 fillers: black and grey 13.02.28 # (execpt on mono lcds) 13.02.28 # Llorean: What about the charging animation? 13.02.33 # amiconn: Then two bitmaps 13.02.43 # linuxstb: So two filler images instead of one. 13.04.14 # amiconn: Your argument is only valid if you assume an association between viewers and icons. I want to remove that association. Icons should be mappable to extension whether there is one, more or now viewer available for a particular association (and also available viewers don't mean there has to be an icon) 13.04.45 # roolku: You can currently cover all of those situations, it's just not apparent that you can 13.04.49 # for simplicity icons are associated with extensions, not plugins 13.04.50 # but I can see people might be insistent on the viewer to icon association 13.06.15 # currently the viewers to extension relationship is a many-to-many which causes all these problems 13.06.41 # a 1-to-1 relationship between extensions and icons would be a lot more KISS 13.06.55 # roolku: My argument wasn't about the exact association. Even if you make icon association independent of viewer association, we still don't want the extension->icon association to be built-in except for core-supported formats 13.08.08 Quit darkless ("Leaving") 13.09.42 Join Nico_P [0] (n=nicolas@jau31-3-82-239-20-145.fbx.proxad.net) 13.10.09 # hey Nico_P 13.10.16 # hi 13.10.16 # so whats the story with the text height patch? 13.10.36 # Nico_P: And how's MoB? :) 13.10.37 # it's still on th tracker and I intend on finishing and committing it 13.10.59 # linuxstb: MoB will soon become my main interest :) 13.11.11 # Nico_P: It had better! :-P 13.11.22 # JdGordon: it's almost finished but I need to add the tag to a bunch of WPSs 13.11.31 # ok :) 13.11.54 # JdGordon: but I don't have much time for rockbox this week, my gf is with me in toulouse 13.12.04 # Llorean: :) 13.12.18 # I wonder why the gigabeat wants you to press the power button ages to start up 13.12.26 # Nico_P: you dont have to make up excuses for us :D 13.12.43 *** Saving seen data "./dancer.seen" 13.12.45 # XavierGr: A great, great fear of accidental power on? 13.13.11 # Llorean: heh, it isn't a self destruct button anyway :P 13.13.17 Join matsl [0] (n=matsl@dhcp101.contactor.se) 13.13.29 # XavierGr: Haven't you been reading about those exploding batteries in the news? 13.13.37 # battery bench for F40 with 128-320 mp3s = 16 hours and 40 minutes 13.13.52 # amiconn: I need Unifont for this, right? 13.13.53 # is that good? 13.14.04 # XavierGr: A little above average, I think 13.14.16 # pondlife: Well, if you want to test exotic scripts, then yes 13.14.31 # But even german umlauts or accented letters didn't work before 13.14.45 # Llorean: I thought that the average was about 20 hours 13.14.51 # OK, just checking with the umlauts in Bjork.. 13.15.07 # XavierGr: http://www.rockbox.org/twiki/bin/view/Main/GigabeatRuntime 13.15.24 # Llorean: Yeah I am just going to upload my score there 13.15.30 # Nico_P: BTW, why do you need to add the line-height tag to WPSs? Is it a compulsory tag? 13.15.36 # There is one 19h one, but most of them are slightly under 16 13.16.09 # indeed 13.16.09 # linuxstb: Some of the built-in WPSes are compatible with it though (rockboxed, icatcher) 13.16.35 # amiconn: sorry no time now 13.17.20 # amiconn: Well, it passes the Bjork test. 13.17.28 # Will carry on playing with it! 13.18.19 # Llorean: OK, then I misunderstood Nico_P's use of the phrase "need to"... Adding the line-height tag to WPSs isn't needed... 13.19.55 # Yeah, his personal desire makes him need to, they don't require it. :) 13.20.03 # At least, I don't think they do... 13.21.28 # btw, can a wps then contain multiple line height tags or just one? 13.21.58 # pondlife: I'm not fully satisfied with how the patch works, but at least it doesn't add a ton of ifdefs 13.22.23 # amiconn: I can crash using the patch and JPG viewer. 13.22.45 # Just checking I did a make install properly.... 13.22.54 # PaulJam: It's just a global line height for the WPS. 13.23.05 # It adds quite a number of macros though, and those utf8<->ucs2 conversion functions with static buffers 13.23.07 # ok, thanks 13.23.17 # PaulJam: The screen is still divided into a number of equal height lines, it just removes the link between the height of the lines and the height of the font. 13.23.56 # * amiconn also wants to make the console show unicode chars properly 13.24.10 # I recently learned that the windows console *does* support utf-8 13.24.20 # It's code page 65001 13.24.58 # sorry, work interfered 13.25.30 # amiconn: what is the issue with built-in ? It can be very minimalistic 13.26.09 # I see it the same as the default wps 13.26.28 # (1) It takes binary space. (2) It's static. Currently you can make a file type unsupported by removing it from viewers.config 13.26.28 # amiconn: good to know! 13.27.02 # markun: Yeah, just I need to find out how to set this code page for a console application 13.27.16 # amiconn: Have a built-in set of icons doesn't affect 2) - that can still be based on viewers.config. 13.27.18 # amiconn: 1) more than currently? why? 13.27.19 # amiconn: Try playing a track with an umlaut in the pathname, then go back to the file viewer and select a JPG 13.27.20 # amiconn: well, in that case the whole table from tree.c should be removed 13.27.47 # ... which it could be btw... fairly easily 13.28.02 # roolku: The built-in filetypes have default icons in the binary. 13.28.02 # amiconn: 2) what do you mean by "unsupported" I suggested to dissassocuate icons from viewers 13.29.15 # amiconn: gdb only gives a little info - Segmentation fault at SDL_sysmutex.c:90 13.29.34 # And no useful backtrace 13.29.35 # Well, true. But unsupported extensions shouldn't have an icon either. Or at least it should be possible to choose whether I want one 13.29.57 # the file type table from tree.c uses about 640bytes of bin space which could be loaded into RAM on boot from a txt file 13.29.59 # linuxstb: yes? I can't follow the conclusion. 13.30.14 # amiconn: unsupported files always get no icon 13.30.14 Quit miepchen^schlaf (Read error: 113 (No route to host)) 13.30.29 # JdGordon: I thought only filetypes.c was meant to have extension-specific code... 13.30.32 # JdGordon: I thought you could define an icon for *any* filetype in the .icons file 13.30.35 # JdGordon: Not if the list is built-in as roolku suggested 13.30.42 # the default could be no icons for any files that have a viewer associated with them 13.31.19 # pondlife: thats what i was complainig about yestersday... filetype icons are handled in 3 files... 13.31.23 # Llorean: no, only supported files 13.31.30 Join atsea- [0] (i=ariel@gateway/tor/x-a7aae23b6f50b757) 13.31.42 # amiconn: no, i;m agreeing with you, that it could (should?) be completly moved out of the bin 13.31.56 # JdGordon: In my mind the .icons file should allow you to set associations between any filetype and icon, whether there's a viewer for them or not. 13.32.01 # if we ship an default mapping file (including bmp) as a starting point this can be used for the theme builders 13.32.23 # JdGordon: It should neither be completely built-in nor completely moved out 13.32.33 # completely moved out :) 13.32.51 # Llorean: tough :) its impossible to do atm... it does string comparisons on the extensions which are stored in the audio buffer, so adding after boot is painful 13.33.08 # The point is, core supported formats should work and have their icon without needing any extzernal files 13.33.36 # (of course it might be desirable to ovverride built-in icons for those who care that much about lloks) 13.33.39 # *looks 13.34.00 # the built-in I only suggested as we also have a default wps built-in 13.34.16 # wasnt it decided though, that without a full zip install rockbox was useless anyway? so really no files would be supproted? 13.34.37 # so it would be ok to move even the inbuilt filetypes out of the bin into a txt file 13.34.57 # would get my vote 13.35.28 # * JdGordon not even sure why that table is in tree.c, a quick search doesnt show any reason for it to be there and not filetypes.c 13.35.49 # Why exactly is moving the inbuilt filetypes out a good idea again? 13.35.52 # What benefit does it gain? 13.35.54 # one single list that covers all extensions 13.36.12 # small binary decrease also 13.36.22 # roolku: Yes, as wps is a core-supported format 13.36.28 # for paranoid people a fall-back could be compiled in (but I see this as optional) 13.36.28 # assuming the text parsing functino would use less space than the table 13.37.12 # Llorean: You can't simply rely on an external file, you need a fallback in case this file doesn't exists, is unreadable, garbled etc 13.37.25 # * JdGordon disagrees 13.37.27 # amiconn: I'm for keeping them inbuilt. 13.37.30 # amiconn: Did you see my patch bug report? 13.37.32 # amiconn: I didn't mean a wps icon - I mean a fall back if no external wps is loaded 13.38.14 # amiconn: so we could have a fall back for if no external extension-icon file is loaded 13.38.20 # JdGordon: Rockbox might be unusable with no accompanying files on swcodec because you simply need the codecs for playing music. This isn't true on hwcodec 13.38.29 # which could be very minimalistic (to save space in binary) 13.38.34 Quit Br3nda ("Konversation terminated!") 13.38.51 # amiconn: ah, yes, forgot about hwcodec... 13.38.51 # and for example only include core-supported extensions 13.39.46 # * roolku doesn't consider icons important functionality 13.39.56 # considering they can be turned off 13.40.17 # It can fall back to no or blank icons easily enough 13.40.25 # so the HWCODEC would still work without an external icon file 13.41.08 # roolku: the icons are only coincidental to the discussion... the inbuilt icons use the same number for their icon as the tree uses for its attributes 13.41.56 # JdGordon: I thought the discussion was about icons... 13.42.04 # btw, am i the only one not quite seeing the point with icons in menus? 13.42.10 # JdGordon: I don't know what you mean? 13.42.23 # like one for every menu entry 13.42.39 # preglow: eye-candy 13.42.53 # preglow: it looks nice on targets with high resolution, but I turn them off on lowres screens like h140 13.42.56 # cluttering eye-candy :/ 13.43.02 # oh woops.... no ignore me 13.43.17 # i'll agree they work better on hires screens, yes 13.43.19 # 4 bytes per built in is used for the icon 13.43.27 Quit elinenbe_ (Read error: 104 (Connection reset by peer)) 13.43.30 # but i still think they're just cluttering the screen instead of making it prettier 13.44.41 # anybody against moving all the mi4 based portalplayer devices to firmware/arm/target/portalplayer ? 13.44.43 # So, Markun mentioned something to me, and now I'm curious. Is there a reason that under architecture (say, /arm/) in target tree, we have it split only by manufacturer rather than categories like /mi4/ or /portalplayer/ since those share more similarities based on their standard design than their manufacturer description? 13.45.26 # dunno, i think linusn was the one who did the initial directory layout 13.45.47 Join webguest06 [0] (i=c023110b@gateway/web/cgi-irc/labb.contactor.se/x-dc18158f242468ee) 13.45.58 # also, the Gigabeat F, X and Kenwood HD20GA7, HD30GA9 are built on a platform codenamed "Legna" by Toshiba 13.46.01 # when i did that layout, there was only one portalplayer target 13.46.06 # the Gigabeat S, V and Zune are called "Ottoman" 13.46.14 # do you think we could use those names in the target tree? 13.46.18 # LinusN: Well the real question is: Any objections to changing it, as it seems to make sense to? 13.46.21 # firmware/target/arm/legna/gigabeat-fx/ 13.46.26 # firmware/target/arm/ottoman/zune 13.46.28 # for example 13.46.30 # Add "platforms" rather than manufacturers? 13.46.34 # doesnt the path use those dirs for #include search? 13.46.46 # JdGordon: yes 13.46.47 # so we can only go 3 deep without changing more scripts? 13.46.52 # exactly 13.46.59 # JdGordon: In those cases it would be replacing the manufacturer level 13.47.03 # It's not adding a new level. 13.47.18 # but yes, we could call it "platform" instead 13.47.22 # We still have say /iRiver/ for the iFP, since it doesn't have an abstract platform it falls into. 13.47.34 # Llorean: agreed 13.47.54 # That could be the CPU in the iFP. ARM is a special case because of all these variants... 13.47.58 # But the Gigabeat F and X go on /Legna/ since that's the reference design / platform / whatever we call it. 13.48.15 # markun: did you mean firmware/target/arm/pp ? not firmware/arm/target/pp? 13.48.29 # JdGordon: of course :) 13.48.37 # ok, then it makes sense 13.49.02 # and shouldnt /ipod be /apple? 13.49.33 # JdGordon: I think /iPod/ might be more descriptive as a platform 13.49.56 # But, shrug. 13.50.22 # The real fix is for the million potential MI4 targets that could end up showing up, plus the Toshiba families. 13.50.40 # and move all those .c's out of /arm ? 13.50.49 # *-pp.c 13.50.52 # JdGordon: yes, I would say so 13.51.09 # go for it then :) 13.52.04 # so, will it be "pp", "portalplayer" or "mi4"? 13.52.24 # or something else :) 13.52.31 # A good thing we have svn now.. 13.53.02 # JdGordon: these player probably share quite some code as well: http://www.rockbox.org/twiki/bin/view/Main/SamsungSA58 13.53.17 # if we ever support them 13.53.26 # markun: I think I'm missing something - the ipods will also be under the new portalplayer directory? 13.53.44 # linuxstb: I don't know 13.54.39 # or do we have to think about a non hyrarchical way to organize the code? 13.54.48 # We could just have arm/cputype/device/ 13.55.02 # yes 13.55.22 # maybe better even 13.55.29 # And get rid of manufacturer completely for the arm devices, as they seem to be mostly SoCs 13.55.37 # s3c2440, portalplayer, pnx0101 13.55.53 # maybe soon imx31 13.56.18 # LinusN: what do you think? 13.56.30 # linuxstb: so cputype would be pp50** or? 13.58.03 # I don't think we need to split the portalplayers. Looking at ata-pp5002.c and ata-pp5020.c, they could be unified by using #defines - not even any #ifdef are needed. 13.58.44 # They seem the only files split by PP chip. 13.59.30 # So a folder for the PP 50 series? 14.00.43 # Are there any other series? 14.00.55 # Not that we've encountered yet, at least 14.01.02 # /arm/pp/{ipod{-3g,-video}, sansa-e200, iriver-h10} ? wont that be more messy than what we have already? 14.01.04 # And as the company is dead... 14.01.10 # unless im completly mistaken 14.01.23 # linuxstb: yet. What about iram size? 14.01.26 Join juxtap [0] (n=juxtap@wbs-196-2-109-237.wbs.co.za) 14.01.40 # amiconn: What do you mean? 14.01.54 # Differences between pp50* chips... 14.02.57 # Isn't that just a #define? That should require different directories in target-tree. 14.06.49 # s/should/shouldn't/ 14.10.03 Join B4gder [0] (n=daniel@static-213-115-255-230.sme.bredbandsbolaget.se) 14.13.44 # I'll just do the Gigabeat for now then 14.15.52 # did anyone have any problems with me moving the filetypes array out of tree.c? 14.16.36 # To where? 14.17.03 # filetypes.c 14.17.13 # it fits in there more than tree.c imo 14.18.01 # bbl 14.18.50 # http://rafb.net/p/cu6OFX77.html 14.20.16 # i have no objections 14.20.43 # Wouldn't it also make sense to rename the TREE_ATTR_* #defines to something else, and move them to filetypes.h ? 14.21.06 # possibly... but that means fiddling with more than just 4 files :p 14.21.10 # i.e. filetypes should be depending on code in tree... 14.21.19 # s/should/shouldn't/... 14.21.37 # I can move the #defines across also, but I dont want to rename them 14.21.47 # although... 14.22.41 # haha, /me wonders who defined TREE_ATTR_RWPS and up 14.23.08 # out for luch, my commit shouldn't break anything.. 14.23.34 # JdGordon: It just seems the intention of your commit is to abstract the filetype handling away from the tree code, but you've only gone half way... 14.23.42 # amiconn: ? 14.24.14 # linuxstb: ok, your right... FILE_ATTR_? 14.24.36 # amiconn: svn annote blames someone called dave.... 14.24.42 # 0x0900 -> 0x1000: 6 IDs wasted... 14.25.16 # haha 14.25.31 # someone forgot which base they were in :D 14.25.32 # svn blame is a great alias for annotate ;-) 14.25.45 Join pearldiver [0] (n=say@cpe-72-225-231-80.nyc.res.rr.com) 14.25.46 # JdGordon: Maybe just FILETYPE_MPA etc ? 14.26.44 # no, I think it should keep the ATTR, to remind you its |'d with a real value 14.27.02 # FILE_TYPE_? 14.27.09 # bah i dunno 14.30.18 # does anyone know if the values for FILE_ATTR_* is checked without the define? may as well fix the missing values unless they are checked wrongly... 14.30.35 # "svn blame" lies - all I did was change some whitespace in the incorrect line, this is the original commit that added it - http://svn.rockbox.org/viewvc.cgi?view=rev&revision=7934 14.30.36 # The TREE_ATTRs are used in the tree. So why rename/move them? 14.30.48 # * linuxstb can go back to work now 14.30.54 # And then there's the thumbnail attribute which isn't really related to a type 14.31.16 Quit brun0_ (Read error: 104 (Connection reset by peer)) 14.32.07 # amiconn: they are used by onplay.c, filetree.c and tree.c, 14.33.03 Quit rift_ (Read error: 54 (Connection reset by peer)) 14.35.41 # tree.c uses them 4 times.. filetree.c uses them 4x that 14.36.08 # tree.[ch] is one of my current pet hates :p 14.37.06 # 43 times in filetree.c 14.37.54 Quit pill (Nick collision from services.) 14.38.54 Join _pill [0] (i=pill@sloth.shellfx.net) 14.40.45 Join BigBambi [0] (n=Alex@cpc2-nfds9-0-0-cust419.lei3.cable.ntl.com) 14.41.53 Join Soap2 [0] (n=Soap@65.23.15.14.nw.nuvox.net) 14.46.27 # new patch http://rafb.net/p/CICoL569.html 14.46.28 # pondlife: Hmm, can't make it crash here... 14.47.40 Join rift [0] (n=rift@242.56.70-86.rev.gaoland.net) 14.48.13 # JdGordon: Seems you have an unrelated change in gui/icon.c 14.48.46 # ta, missed 1 file cleaning it then 14.54.01 # linuxstb: look ok? 14.54.14 # JdGordon: Patch seems logical to me. Maybe FILETYPE_MPA should be renamed to something generic (e.g. FILETYPE_AUDIO) if it is in fact used for all supported audiotypes. But that can be done some other time... 14.54.49 # may as well do it now... easier now anyway seen its only the patch which needs fixing 14.57.04 # anything else? 14.57.44 Join Arathis [0] (n=doerk@p54849BC9.dip0.t-ipconnect.de) 14.58.05 # JdGordon: No more comments from me... 15.04.10 # * JdGordon hates to think how slow rockboy would run if you have music decodnig in the background :p 15.04.27 Quit BigBambi (Read error: 110 (Connection timed out)) 15.10.48 # yay, no nasty surprises from the commit :) 15.11.05 Join Hammer89 [0] (n=soc_inte@host-24-149-166-187.patmedia.net) 15.11.24 # how does Slasheri get away with all the yellow? 15.11.33 # he keeps away from here ;-) 15.11.56 Quit Jon-Kha (Remote closed the connection) 15.12.45 *** Saving seen data "./dancer.seen" 15.14.59 # * linuxstb is quite impressed with tak, a new lossless format 15.16.04 # Seems to compress to similar levels as the high Monkey's Audio settings, but decodes in a reasonable time... 15.16.32 # similar to FLAC, from what I'm reading, cool 15.16.53 # (for decode speed) 15.16.53 Join Jon-Kha [0] (n=Jon-Kha@a91-152-69-9.elisa-laajakaista.fi) 15.17.12 # My tests show it's about half the decoding speed of flac. 15.17.23 # I mean double the time - half the speed... 15.17.44 # Is it open source? 15.17.58 # Not yet... 15.18.15 # Ah 15.18.22 # IIUC, the author has written it in Delphi and won't release that source, but is planning an open source implementation in C. 15.22.23 Quit Jon-Kha (Remote closed the connection) 15.23.15 # "TAK will be open-source, as soon as the code is ported to C or C++ and documented." 15.23.27 # let's hope he does the right choice there then... 15.23.38 # heh 15.24.04 # Maybe a polite email suggesting C would be beneficial? ;) 15.24.07 # makes you wonder what "gems" are hidden in the delphi code 15.24.37 # here's a fun comparison chart: http://synthetic-soul.co.uk/comparison/lossless/ 15.25.27 # amiconn: Hmm, I can make it crash without the patch, so false alarm. 15.26.02 # Extra, Extra Extra, Extra Max... you'd think the natural measure a codec developer would use would be numeric 15.26.29 # Tak does look really good from that chart. 15.26.37 # hcs: remember this is a delphi guy ;-) 15.27.36 Quit himitsu (Read error: 60 (Operation timed out)) 15.28.10 # Llorean: does it? 2% better compression than flac at same speed 15.28.19 # amiconn: It doesn't crash every time, but repeatedly going into JPG viewer with music playing will kill the sim. 15.28.28 # Zagor: For Lossless, that's pretty good. 15.29.00 Join Jon-Kha [0] (n=Jon-Kha@a91-152-69-9.elisa-laajakaista.fi) 15.29.08 # well sure, but not nearly good enough to stray from the "standard" imho 15.29.23 # I mean OptimFrog only gets 1% better, at 1/22nd of the speed. 15.29.38 # Yeah, FLAC is good enough for me, I'll agree. 15.29.51 # I agree, it's going to take more than a couple of % to make me move away from flac. 15.32.27 Quit aliask ("ChatZilla 0.9.78.1 [Firefox 2.0.0.3/0000000000]") 15.36.45 Join miepchen^schlaf [0] (n=hihi@p54BF61CB.dip.t-dialin.net) 15.37.11 Quit Jon-Kha (Remote closed the connection) 15.39.40 Join Jon-Kha [0] (n=Jon-Kha@a91-152-69-9.elisa-laajakaista.fi) 15.41.53 # http://rapidshare.com/files/26530878/virtualhaircut.mp3.html have a listen to that with headphones on... 15.42.04 # virtual haircut... very well done 15.43.46 Join docwhat [0] (n=holtje@office.vivisimo.com) 15.43.54 # Hello! 15.44.13 Quit Entasis (Read error: 104 (Connection reset by peer)) 15.44.16 # How do I change the color of the icons and the 'cursor' in the theme? I can't see black on dark.... 15.44.44 # docwhat: You'll have to use a custom icon set. 15.44.55 # Oh! there are icon sets? 15.45.07 # JdGordon: rapidshare my a**, endless clicking to get the damn file :-/ 15.45.14 # Where can I get them? 15.45.23 # docwhat: The IconSets wiki page, or create your own 15.45.54 # Ah,h hah. Under extras....thanks Llorean. :-) 15.46.06 # http://jdgordon.mine.nu:8080/jonno/virtualhaircut.mp3 15.47.38 Quit juxtap (Read error: 110 (Connection timed out)) 15.47.38 # Imho "rapid"share doesn't deserve its name 15.49.11 # it used to... before they sold out :p 15.50.04 Part LinusN 15.50.52 Join Febs [0] (n=chatzill@38.98.196.75) 15.52.54 # * amiconn wonders why JdGordon's commit increased binary size for arm targets - only 15.53.05 # because arm is special 15.53.50 # hmm... aparently i forgot to refresh the build page.. I thought there was 0 delta 15.54.08 Join kkurbjun [0] (n=kkurbjun@c-71-56-227-141.hsd1.co.comcast.net) 15.54.20 # the only thing that could have done that was the addition of config.h to tagtree.c (which I did because it should always be included shoudnt it?) 15.54.28 # * B4gder likes when there are 5 Haxx servers in the top of the build server stats ;-) 15.54.30 Quit pondlife ("disconnected has pondlife") 15.55.54 Quit miepchen^schlaf (Read error: 104 (Connection reset by peer)) 15.56.13 Join miepchen^schlaf [0] (n=hihi@p54BF61CB.dip.t-dialin.net) 15.58.30 Join funky [0] (n=repulse@unaffiliated/funky) 15.58.33 # * JdGordon wonders why none of the file*.c's include config.h 15.59.02 Quit webguest06 ("CGI:IRC") 15.59.35 Quit Nibbier (Remote closed the connection) 16.02.59 Join Nibbier [0] (n=sven@port-212-202-177-141.dynamic.qsc.de) 16.04.45 Quit B4gder ("Lämnar") 16.05.03 Join desowin [0] (n=desowin@avc146.internetdsl.tpnet.pl) 16.06.24 Quit JdGordon ("Konversation terminated!") 16.07.27 Join My_Sic [0] (n=MySic@mur31-1-82-237-204-133.fbx.proxad.net) 16.08.13 Join cybrhuman [0] (n=cybrhuma@211.84-234-183.customer.lyse.net) 16.10.07 Quit Topy44 (Read error: 104 (Connection reset by peer)) 16.10.25 Quit docwhat (Remote closed the connection) 16.12.42 Quit Jon-Kha ("leaving") 16.15.25 Part cybrhuman 16.15.35 Join ceaser_ [0] (n=ceaser@cpe-71-72-73-134.columbus.res.rr.com) 16.16.18 Join Jon-Kha [0] (n=Jon-Kha@a91-152-69-9.elisa-laajakaista.fi) 16.16.29 Join darkless [0] (n=darkless@62.79.44.48.adsl.vby.tiscali.dk) 16.16.53 Quit Haarg () 16.17.39 # Hi, I was wondering if it is possible in any way to display the battery voltage on the WPS 16.22.16 # sure, %bv 16.22.32 # parasite_: http://www.rockbox.org/twiki/bin/view/Main/CustomWPS#Power_related_information 16.22.45 Join Topy44 [0] (n=Topy44@xdsl-81-173-151-103.netcologne.de) 16.23.12 # thank you very much 16.23.25 # * parasite_ blushes about asking a question with an answer on the wiki 16.29.04 # well, you just have to know where to look 16.30.43 # a silly idea, but since there is a "simulator" it should probably be very easy to do: has anyone ever attempted to make a x86-based standalone DAP based on rockbox? 16.31.17 Quit Siltaar (Read error: 60 (Operation timed out)) 16.31.35 # Topy44: not really, but there has been talk about it from time to time 16.31.36 # x86 isn't an ideal embedded platform 16.31.42 # GodEater: so? 16.31.56 # nope, but just about everyone has some old hardware standing around anyway 16.32.05 # markun: so based on that I don't believe anyone's tried it ? 16.32.26 # ah, I misread the question :) 16.32.57 # display output over a small 7" tft or a parallel port LCD, controlls over a hacked keyboard and/or an infrared remote, ... 16.33.00 # for DAP I think in terms of something portable too 16.33.16 # you could make a kind of hifi unit from it I suppose 16.33.21 # thats what i meant 16.33.29 # right - sorry I misunderstood 16.33.37 # I thought you meant something portable 16.34.09 # would be great for a car unit aswell... for example using an epia board 16.34.25 # * GodEater wishes empeg were still going 16.34.30 # I always wanted one of their head units 16.34.42 # curse Rio!!! 16.34.53 # i might actually attempt this... i always wanted a standalone hifi mp3 player 16.35.18 # i already built hardware for it once (fitting a pc into the case of an old cd player) 16.35.34 # but i never properly set up any software for it 16.35.57 # does the simulator output sound? 16.36.06 # (i havent used the simulator yet) 16.36.36 # Topy44: Lots of people have talked about using the simulator in various situations (i.e. other than debugging Rockbox), but I don't think anyone has done it. 16.36.48 # i really might try this 16.39.26 Quit Jon-Kha (Remote closed the connection) 16.39.57 Join Siltaar [0] (n=Siltaar@reverse-52.fdn.fr) 16.40.27 Join x1jmp [0] (n=x1jmp@p57B0A88F.dip0.t-ipconnect.de) 16.40.28 # of course, the nicest way of doing it would be to run rockbox without having a full linux behind it 16.40.51 # fast bootup and low resource needs 16.41.08 # but just a stripped down custom linux distro should do for a start 16.41.50 Join Jon-Kha [0] (n=Jon-Kha@a91-152-69-9.elisa-laajakaista.fi) 16.43.02 # Topy44: The sim uses SDL for keyboard input, display and sound (yes, sound works in the sim). 16.43.46 # does SDL run on (free)dos? 16.44.07 # s/run on/exist for/ 16.44.19 # amiconn: my commit msg? yeah, guess you're right :P stupid allergy medication again ... every time I need to take it I end up doing one like that. :D 16.44.29 # input and display output to a custom lcd could be easily handled by a custom driver i guess... didnt look at sound programming yet, but should be easy if used with a specific sound card 16.44.32 # markun: I don't believe so 16.45.02 # i havent done much low level code yet 16.45.12 # but theres always a first time :) 16.47.34 # a bunch of scripts could handle mounting external media like cdrom and usb sticks 16.47.56 # i think the changes to rockbox itself would be minimal 16.48.20 # jhMikeS: Your commit doesn't change the actual code at all, but the commit msg suggests it does 16.48.59 # Can svn log messages be changed? I think I read somewhere that they can't. 16.49.01 # amiconn: Yeah, I know. I woke up, checked the logs and looked again and realized what I'd done. oy 16.49.23 # If Bagder installs the hook for it, yes 16.49.40 # btw, where are you guys from? is there any regional concentration of rockbox developers or are you spread all over the world? :) 16.50.38 # Topy44: a lot are from europe 16.50.44 # let me try to find a map 16.50.52 # i'm from germany 16.51.19 # http://rasher.dk/rockbox/people/gmap.php?onlydevs=yes 16.52.01 # * GodEater doesn't show up on that map so points vaguely at London, UK 16.52.42 # and there are quite some devs on that map I've never heard of.. 16.55.01 # hm, i just tried setting up the simulator... everything seems to have worked, no errors, but the /sim/archos directory is empty 16.56.35 # If we're going to do subs in mpegplayer, then I think we need to parse out the program stream time. What's it? PTC or something? hrm 16.56.39 # Topy44: "make install" 16.56.51 # markun, did that of course 16.57.11 # Topy44: There should be a ".rockbox" directory - which may not be shown depending on how you're looking... 16.57.21 # ls 16.57.27 # -a 16.57.37 Quit Zagor ("Client exiting") 16.57.59 # me idiot. yes, of course 16.58.00 # jhMikeS: PCR? 16.58.36 Join BigBambi [0] (n=Alex@cpc2-nfds9-0-0-cust419.lei3.cable.ntl.com) 16.58.46 # linuxstb: I guess that's it. They're suppose to be there for that purpose. 16.58.47 # Ah, no PCR is in transport streams, SCR is in program streams 16.58.55 # System Clock Reference 16.59.00 Join toffe82 [0] (n=chatzill@h-74-0-180-178.snvacaid.covad.net) 16.59.19 Quit BigBambi (Read error: 104 (Connection reset by peer)) 16.59.20 # "A timestamp in the Program Stream from which decoder timing is derived" 16.59.33 # Are you planning on doing subs? 17.00.03 # It seems like that would be an encoding step, for portable use. 17.00.11 # That would also keep audio synced properly if audio frames are dropped instead of rushing the video ahead to keep up. 17.00.55 Join midgey [0] (n=tjross@markely-164-75.reshall.umich.edu) 17.01.16 # Why would you drop audio frames? 17.01.31 # if you have errors 17.03.35 # well, personally, i would like having softsubs 17.03.37 # right now the whole clock will just jump ahead but actually silence should be played where an audio frame is bad 17.04.02 # since subtitles use up a lot of video bandwidth because of their sharp contours and high contrast 17.04.10 Quit sando (Read error: 54 (Connection reset by peer)) 17.04.41 # they would be more compact and better readable as softsubs 17.05.23 # anime episodes are predestined for portable viewing, as they are short, dont suffer to much by the lower framerate and dont need very high bitrates 17.05.37 Join vcardenas [0] (i=c8767629@gateway/web/cgi-irc/labb.contactor.se/x-81994bb42aac479a) 17.05.47 # with softsubs, that would be a real feature 17.06.26 # (i am regularly using the X5's original firmware to watch cartoons on the go already) 17.06.29 # right now, I don't really know the technical difference. One is another MPEG video stream and softsubs are what exactly? 17.06.38 # text with timestamps 17.06.39 # jhMikeS: text 17.06.42 # ok 17.07.05 # Softsubs look better, but need some sort of overlay. 17.07.05 # (or overlay images in the case of dvds, but thats impractical for portable use) 17.07.24 # * dionoea has subs working in mpeg player 17.07.30 # see yesterday's log for more info 17.07.38 # jhMikeS: were you working on subs support ? 17.07.51 # dionoea: I was trying to remember your nick to mention it :) 17.07.56 # :D 17.07.56 # If I get the framedropping tuned up I can hit about 16-17fps regulated on x5 with elephants dream 17.08.22 # (using srt txt subs) 17.08.27 # * Llorean thinks 15fps is usually "good enough" for video, for him. 17.08.27 # dionoea: no, but saw your questions in the logs 17.08.32 # screen size could really be an issue with subs though, longer sentences might just clutter up the whole screen with text...) 17.08.46 # I'll post a patch when i get back from work 17.08.56 # still, it would be a nice feature imho 17.09.00 # Topy44: and the X5 in particular of course 17.09.05 # yes 17.09.12 Join linuxstb_ [0] (n=linuxstb@rockbox/developer/linuxstb) 17.09.20 # Topy44: With some cleverness one could possible look at the next sub's timestamp, and scroll the sub across the screen ending 1 second before the next one, or something similar. 17.09.34 # jhMikeS: Is that with miark's code? 17.09.34 # * jhMikeS needs to get dropping really optimized but it doesn't take well to simple math equations 17.09.47 # *mirak's 17.09.51 # no 17.10.20 # what was the original framerate of the video file? (as in, how much did you have to drop at decoding time?) 17.10.28 # just with more optimal choice of dropping frames in the decoder 17.10.57 # 24 fps 17.11.19 # mostly b frame drops which really benefit it 17.11.23 # simulator is working for me now btw, but you should change the tutorial, since the file is not called rockboxui.exe but just rockboxui 17.11.31 # jhMikeS: Why is frame-dropping so important to you? Wouldn't it be better to simply encode files at a framerate the target device can actually decode? 17.11.48 # Topy44: It's rockboxui.exe in windows. 17.11.55 # Topy44: Which tutorial are you referring to? 17.12.20 # Llorean, aah, didnt think about that :) 17.12.28 # linuxstb_: There's a range between 15 and 24 that doesn't have a good framerate choice though, right? 17.12.30 # because it should be tuned to the hilt really 17.12.31 # http://www.rockbox.org/twiki/bin/view/Main/SimpleGuideToCompiling <== setting up the simulator 17.12.36 # Say a target can do ~21fps 17.12.49 *** Saving seen data "./dancer.seen" 17.12.56 # Topy44: Ah, yes, that's a user created guide, that some of us aren't entirely fond of. ;) 17.13.05 # ok :) 17.13.10 # Or at least I'm not. It seems a little much to be called "simple" 17.13.15 # It might even be possible to acheive higher framerates by dropping selectively than what it can do with no regulation 17.13.32 # personally i find the tutorial quite good 17.13.51 # and if it must drop, it should look as even as possible 17.14.06 # Topy44: if you create a wiki account and ask for write permission you can fix the mistakes you find 17.14.15 # ok, i will 17.15.00 # Topy44: It's got a lot more text than is necessary, or did last time I checked, and seems to be a bit patched together. But that's just my personal opinion 17.15.32 # but it contains everything needed in a understandable way 17.15.53 Join Juice- [0] (n=Juice@213.167.96.196) 17.15.54 # i will clean it up a little 17.16.28 # jhMikeS: btw, was there any need for other on screen display (that is, not subs) 17.16.40 # like time / volume info or stuff like that 17.16.43 # so, i'm registred.. wikiname ThorinHopkins 17.16.46 # overlayed on the video 17.16.49 # could i have write permission 17.16.53 # Topy44: There's a lot of unnecessary stuff to. For example, there's never really a good reason to use the Daily or Bleeding Edge source code. Anyone *should* use the SVN source. 17.17.08 # dionoea: a seek bar I would say 17.17.13 # dionoea: Volume might be nice as well 17.17.43 # a FPS display for debugging/finding out what the specific target is capable of might be nice 17.17.49 # the only issue is that i'm currently rendering in the vieo buffer, which means that black bars can't be drawn into 17.18.02 # Topy44: Already is one 17.18.10 # Topy44: that already exists (but it's not rendered optimaly) 17.18.22 Join Topy [0] (n=Topy44@xdsl-81-173-159-68.netcologne.de) 17.18.28 # argh, 12h disconnect by my ISP... 17.18.33 # /vieo/video/ 17.18.35 # dionoea: and your code will probably look wrong on the rotated Gigabeat screen 17.18.48 # Topy: there already is an FPS display 17.18.54 # Very debuggy looking, and everything 17.18.55 # markun: And Sansa... 17.18.56 # markun: i doubt it. It's rendering in the video buffer before it gets displayed 17.19.04 # not on the lcd 17.19.08 # ah, ok 17.19.13 Quit vcardenas ("CGI:IRC (Ping timeout)") 17.19.19 # rotation is done when copying the buffer to the lcd right ? 17.19.29 # well, you mean the yuv buffer? 17.19.30 # dionoea: OSD will commence 17.19.41 # The rvf videoplayer does display volume when changed, and a seeking bar 17.19.46 # as a quick hack, couldnt you just pad out the video buffer to screen resolution before output? 17.19.55 # markun: yep (well, in the y buffer in fact. Nobody cares about u or v for b&w subs) 17.19.58 # dionoea: Well, then why not just put a check for 4:3 vs 16:9(ish) ratio, and only activate your code for the 4:3, and come up with a simpler method for 16:9 17.20.11 # It doesn't display an overlay, but rather cuts away the bottom 8 pixels from the video display for that 17.20.13 # Topy: Blitting the whole screen slows down things 17.20.36 # Llorean: simpler means longer memory access times (since you'll need to draw in the lcd buffer instead of in some buffer in the RAM ... unless that assumption is wrong) 17.20.38 # Llorean, there are other aspects around, since videos found on the net might have weird aspect ratios 17.20.47 # of course, one could pad it during encode 17.20.52 Quit linuxstb (Read error: 113 (No route to host)) 17.20.58 # This should be really simple with lcd_yuv_blit too: just don't blit the whole frame 17.21.07 # and i'm currently rending in the y buffer (which is 1byte per pixel) instead of 2bytes for the lcd 17.21.13 # Topy: Yes, so you just check if screen height - video height is greater than the needed overlay height 17.21.14 # which might make it even faster 17.21.20 # Err, non-overlay height 17.21.33 # s/rendin/redering/ 17.21.35 # Topy: The ratio isn't really important, just how big of a black bar you can have. 17.21.40 # kiss... 17.22.05 # amiconn: I like that, but the problem still remains for letterboxed videos. 17.22.15 # Llorean: why? 17.22.25 # subs in a video overlay should be outlined aswell, white-on-white isnt very readable :) 17.22.27 Quit My_Sic ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 17.22.31 # Drawing the volume or subtitles in the video area when you have a letterbox you can write it in instead isn't really preferable. 17.22.44 # but it's faster :) 17.22.52 # (in terms of CPU on the DAP) 17.23.05 # Llorean: amiconn was talking about drawing at the bottom of the screen 17.23.24 # Since you'll still be rendering the same yuv rectangle as when you have no OSD 17.23.30 # markun: Yeah, it didn't click wholly in my mind. 17.23.45 # markun: Draw at the bottom of the screen, and for full-frame video, reduce the blit area when text needs to be there, right? 17.23.53 # jhMikeS: so, what's it going to be? :) 17.24.53 # [17:20] Topy: Blitting the whole screen slows down things <== would that make so much of a difference? isnt decoding what limits the framerate most? 17.25.29 # Topy: yuv2rgb was consuming 60% of the time on the Gigabeat iirc :) 17.25.34 # oh, ok :) 17.25.52 # I don't know how much it is now (after some optimisations) 17.26.16 # Still enough that we don't want to blit more than we need to. :) 17.26.17 # markun: I suppose it can vary in terms using alpha vs. 1bit transparency 17.26.35 # I mean cutting away a little from lcd_yuv_blit() at the bottom if necessary, and just output the text with the normal lcd drawing followed by an lcd_update_rect() 17.26.42 Quit Topy44 (Read error: 60 (Operation timed out)) 17.26.51 # amiconn: The only problem being the 3:4 screen targets. 17.27.07 # * dionoea still thinks that rendering the OSD in the LCD buffer is a mistake in terms of performance 17.27.16 # dionoea: I like amiconn's method 17.27.18 # amiconn: yes, that's probably the best approach for slow targets. 17.28.07 # dionoea: we can do some benchmarks 17.28.26 # I think YUV code in a plugin lib would be better since I might needs several different ones 17.28.41 # Well it'd mean that: 1/ you have to render in another yuv buffer and 2/ you have to render that on screen 17.28.53 # or that you have to render pixel by pixel on screen 17.29.06 # compared to rendering in the same yuv buffer and that's it 17.29.35 # if this were a normal computer, i'd agree that the other solution is awesome :) But this is a slow dap :( 17.29.56 # dionoea: which one are we talking about? ipod? 17.29.59 # * linuxstb_ gives dionoea a gigabeat... 17.30.05 # i have the ipod video :) 17.30.10 # no, just render the overlay into the lcd_framebuffer and combine the two on the fly into the driver framebuffer 17.30.36 # and the overlay can stay the same for several frames 17.30.47 # markun: agreed 17.30.56 # but that's for a gigabeat or sansa...for others just use lcd framebuffer and combine when writing to lcd 17.32.44 # I'll make it possible to choose the rendering method 17.35.43 Quit heanol (Remote closed the connection) 17.35.54 Join heanol [0] (n=henrik@karantan.org) 17.38.23 Join Rincewind [0] (i=AX7QrvIt@nat-wh-1.rz.uni-karlsruhe.de) 17.40.07 Quit Arathis (Remote closed the connection) 17.41.38 Join PaulJam_ [0] (n=pauljam@vpn-3043.gwdg.de) 17.51.07 Join bluey- [0] (n=bluey@dslb-088-073-125-091.pools.arcor-ip.net) 17.53.10 Join davina [0] (n=davina@cpc1-sout6-0-0-cust616.sotn.cable.ntl.com) 17.55.03 Quit petur ("urgh") 17.55.26 # Speaking of lcd... The ipl kernel and ipodloader2 have photo type 0 lcd windowing incorrect... 17.55.39 # Dunno if you guys used that code... 17.56.38 # linuxstb_: do you know that? 17.57.30 Quit PaulJam (Read error: 113 (No route to host)) 18.00.10 # It's not a fatal error. In fact, it'll never be noticed if you use a full draw window every frame. 18.02.02 Quit ceaser_ (Remote closed the connection) 18.06.28 # dionoea: Why would you render pixel by pixel? 18.07.55 # It's the 3rd solution only :) (because it would require rendering the white pixels only, and not the black ones ... and there are more black pixels than white pixels) 18.08.18 # (I currenty render text in white in the yuv buffer) 18.09.42 # amiconn: and it also wouldn't require rendering in another yuv buffer (since you could write directly to the lcd pix by pix). But that still sounds suboptimial compared to rendering directly in the video yuv buffer 18.10.00 # especially since rendering white in yuv is simple 18.10.09 Quit lids (Remote closed the connection) 18.10.39 # (you only have two colors which can be rendered simply in yuv: white and black) 18.11.06 # if you try rendering colors you have to handle the 4:2:0 y to u/v ratio ... and that's kind of complicated (well, more complicated) 18.11.28 # so you'd be better off rendering in rgb if you're rendering out of the video frame in fact 18.11.38 # (and yuv if you're in the video frame of course) 18.12.59 # So i'll provide an option to either: 1/ render in y(uv) on the video buffer or 2/ render in rgb on the lcd buffer 18.13.12 Quit miepchen^schlaf (Read error: 110 (Connection timed out)) 18.13.20 Quit PaulJam_ (Read error: 113 (No route to host)) 18.13.29 Join miepchen^schlaf [0] (n=hihi@p54BF4DD7.dip.t-dialin.net) 18.13.37 # (rendering in rgb, for subs, is simple since it's only a call to putsxy or something like that) 18.14.25 Join pixelma [0] (i=pixelma@rockbox/staff/pixelma) 18.16.18 Join linuxstb__ [0] (n=linuxstb@i-83-67-212-170.freedom2surf.net) 18.16.52 Quit linuxstb_ (Read error: 113 (No route to host)) 18.22.53 # * Llorean almost wants to declare anyone using Loader2.anything as running an "unsupported build" in general. 18.22.58 Join Lear [0] (i=chatzill@rockbox/developer/lear) 18.23.02 # I didn't even make the connection that it can cause codec errors. 18.23.34 # Because it doesn't look in .rockbox first (or at all without customization) 18.24.53 Join lids [0] (i=lds@gateway/tor/x-bad012307b4e57e8) 18.25.46 # Llorean: actually.... 18.25.52 # courtc: Actually what? 18.25.59 # dionoea: I can't see how rendering to yuv should be more efficient than cutting the yuv a little during text display and using the normal lcd rendering for the text 18.26.27 # courtc: Is there a newer version of loader2 that gives preference to /.rockbox/rockbox.ipod and only loads /rockbox.ipod if it's not found, as our bootloader does? 18.26.37 # Without a custom config file, that is. 18.26.40 # lcd_yuv_blit() does the conversion from yuv to rgb. Rendering to the exisiting lcd framebuffer renders directly to native format, saving the conversion 18.26.55 # And the amount of data actually transferred to the lcd is the same 18.27.02 # It loads .rockbox/rockbox.ipod in rev1427 18.27.11 # courtc: And falls back if it's not found? 18.27.25 # Nah, I was too lazy to implement that. 18.27.57 # (comparing full-screen yuv vs. reduced yuv + small rectangle from normal framebuffer) 18.27.57 # If it's not found, you can use a config file because that's not the default amymore. 18.28.27 Quit obo ("KVIrc 3.2.6 Anomalies http://www.kvirc.net/") 18.28.27 # Either way, use of Loader2 has caused too many strange problems over the history. =/ 18.28.55 # If you have rev1427 of loader2, you will probably have a rockbox version at least newer than that. 18.29.02 # Probably, yes. 18.29.18 # Is 1427 available as binary in an official capacity? 18.29.32 # nope. I commit code, I don't make releases. 18.29.55 # So, basically, any normal user won't have it. 18.29.57 # * Llorean sighs 18.30.15 # * Llorean wishes people would use the official install instructions, or at least try an official install if they get strange behaviour. 18.30.23 # Which as far as I care, isn't my problem. ;) 18.30.36 # courtc: Yes, you've made it my problem instead, thans. 18.30.39 # thanks even. 18.30.47 # NOt really. 18.31.05 # I get the support load from your installer not loading Rockbox properly. 18.31.11 # Err, your loader 18.31.18 # I don't condone newbie use of ipodlinux, and I wouldn't think that you would for rockbox either. 18.31.27 # Because they think it's our job to support your loader if they're trying to load Rockbox with it. 18.32.56 # Llorean: too bad not everyone wants to get rid of the runtime-estimation as it is 18.33.00 # People can't make the connection that if the loader is causing the problem, it's not our problem. We didn't write it. 18.33.09 # markun: I think it's as useless as % volume. 18.33.15 # me too 18.34.10 # The say a wrong estimation is better than no estimation, I disagree with that 18.34.10 # Same here. 18.34.10 # "it tells me 15 hours left so I have about 1 hour left" 18.34.13 # Llorean: I didn't build the ipod... 18.34.37 # markun: the runtime prediction is very accurate on my h120 I would miss it badly 18.34.44 # courtc: but you wish you had of course, then you had all the portalplayer docs :) 18.34.47 # courtc: Yes, so if the flash-loader fails (as it often does when the battery is low), it's not your problem or ours. :) 18.35.01 # Rincewind: Can you do 80% of 15 hours in your head? 18.35.26 # Llorean: I don't want to do it if I don't have to 18.35.34 # you will have to :) 18.35.35 # Right, but people still ask for support... 18.35.42 # and the runtime display is more impressive 18.36.18 # Rincewind: It's also horribly misleading for many cases. 18.36.18 # I would like runtime estimation, but just by keeping track of the time and the percentage changes 18.36.18 # markun: what about my suggestion about letting the user set the max runtime to make it work better? 18.36.18 # Rincewind: It's never been right on my H120, because it has an old battery. 18.36.44 # markun: If 1 hour has passed, and % has gone down 10%, you have 9 hours remainig? 18.36.55 # Llorean: like that 18.37.07 # * amiconn thinks the runtime estimation is a useful feature 18.37.21 # amiconn: I think it's misleading for many users. 18.37.30 # I don't mind if the current algorithm is simplified a bit, but please don't remove it 18.37.43 # It's just misleading because it isn't calibrated properly for a number of targets 18.37.54 # amiconn: It doesn't work well with old batteries, at least not for me. 18.38.01 # Rincewind: and I think the other way around. Remove it if it doesn't get fixed :) 18.38.12 # Llorean: I don't care about the runtime estimation much - but the percentage is percentage of volts and not runtime - as far as I could see it's not linear 18.38.16 Join adiamas [0] (n=chatzill@12.193.211.18) 18.38.23 # add runtim calibration... 18.38.33 # pixelma: The battery % should be based on the discharge curve, I thought. 18.38.42 # pixelma: Percentage is percentage of charge, i.e. proportional to runtime as long as conditions stay the same 18.38.42 Join PaulJam [0] (i=Paul@vpn-3143.gwdg.de) 18.38.51 # pixelma: it should be linear 18.39.34 # but that's not always so easy with the values we get from the ADC 18.39.34 # I am thinking for quite a while about making runtime estimation (and percentage display) auto-calibrating 18.39.39 # amiconn: I would be happy with that. 18.39.43 # amiconn: yes, I was thinking about that as well 18.39.48 # http://ibam.sourceforge.net/ 18.40.28 # amiconn: I want it either gone or adaptive somehow or based on a time that a user sets rather than capacity (so people don't say "Why does my X say I only have 9 hours left when I should have 16?" and "Why does it say I have 16 when I only get 10") 18.40.34 # hmm... maybe I'm misunderstanding but from what I can see when I follow percentage display it doesn't develop "even" (can't find a better eplanation at the moment) 18.41.48 # It does, or at least should 18.42.36 # On targets with NiMH batteries it won't always do, because voltage isn't a reliable indicator for the remaining charge 18.43.24 # The only way to do it prroperly for NiMH would be tracking the actual charge, which would require a means to measure actual discharge current, but the hardware doesn't allow that 18.43.32 # pixelma: the percentage is calibrated linear amount of charge left on the battery 18.43.49 # at least it should be, not on ipods necessary and so on 18.43.50 # For LiIon, voltage can be mapped reliably to the remaining charge 18.44.05 # sorry, but i throw my idea in the middle. couldn't rockbox read the battery_bench output and calibrate voltage/percentage/time left based on those infos? 18.44.06 # (and LiPo of course) 18.44.36 # spiorf: It would need to know the conditions of the battery_bench run 18.45.02 # Runtime estimation isn't just remaining percentage multiplied by a fixed value 18.45.37 # It tries to take the (varying) discharge current into account 18.45.39 # amiconn, it's always an "estimation" 18.45.46 # so I see... it's also only based on my personal impression, I would have to note it down... (and yes I'm using NiMH most of the time) 18.46.11 # (but it almost it, it's not quite smart to take account the average discharge current) 18.46.44 # imho it would be the best general method. if my player can run for 12 hours it will never tell me 20h left. 18.47.11 # obviously i should run baterybench at least one time 18.47.38 # by the way: what is the graph in the battery entry in the debug menu telling me? 18.48.08 # voltage i think 18.48.47 # spiorf: I think it is more than that, because it is a block diagram, not a single value 18.49.12 # Rincewind, the graph ov the voltage vs time 18.51.16 Join Everybody [0] (n=everybod@harpo.demon.co.uk) 18.51.27 # hey everybody. 18.51.33 # had to. sorry. 18.51.44 # because it's so quiet? 18.51.57 # ... no. 18.52.43 Join Guile [0] (n=Guile@84.7.94.192) 18.53.04 # the end of the internet radio : http://capwiz.com/saveinternetradio/issues/alert/?alertid=9631541 18.55.34 # anyway, it would be very simple, at least for non nimh. it looks in the batterybench log the voltage range in which the current voltage fits, then estimate time left and percentage based on how long the player lasted when it hat that particular voltage. 18.56.22 # spiorf: That assumes that you're doing the same thing as when the battery bench happens. 18.56.28 # Even music format can change things 18.56.53 # if i use mp3s, batterybench will run with mp3s 18.57.04 # same thing for other formats or even mixed formats 18.57.18 # Llorean: we can never predict a good estimate for every kind of music 18.57.23 # yeah, video and games will use more battery, but everyone knows that 18.57.25 # Ouch. Got an icon-drawing segfault in the sim... 18.57.30 Quit Everybody ("( www.nnscript.de :: NoNameScript 4.02 :: www.XLhost.de )") 18.57.56 # Rincewind: Yes, which is why I'm not a fan of giving people an estimate of "Time" remaining, rather than just using a percentage, which is valid under any conditions. 18.58.08 # determine the voltage loss in a particular span of time. 18.58.13 # If you show people a time, for some strange reason they expect it to be right. 18.58.15 # it would be something like "if you stop playing and watching videos right now, you can listen at 3hours and 20minutes of music 18.58.15 # a percentage is not valid under every condition 18.58.30 # Rincewind: Assuming the percentage is calibrated, under what condition isn't it valid. 18.58.52 # if the percentage is calibrated, then runtime is exact, too 18.58.56 # No, it's not. 18.59.02 # Llorean, the problem is that there is no absolute method to know the battery left. 18.59.27 # my player can't know if in the next hour i will play a video or a mp3 18.59.29 # Rincewind: If your battery is old, if you're using FLAC, or under a variety of other conditions, it's not very correct at all 18.59.47 # If people complain that the estimate is not exact to the hour and minute, then we can only tell them not to be utopic 19.00.19 # Llorean: in that case I can run the battery bench in this conditions and get an exact result the next time 19.00.23 # the voltage loss over a span of time... used in collaberation with a calibrated voltage estimate / time left. 19.00.33 # (if we do what spiorf suggests) 19.00.46 # Rincewind: And it's still only valid if they don't change anything about their usage habits. 19.00.48 Join kahn [0] (n=kahn@CPE-124-177-198-211.sa.bigpond.net.au) 19.00.57 # Rincewind: For example, I listen to NSF, Audiobooks, or encoded music in FLAC and MP3 19.01.02 # each of those has different lifetimes. 19.01.17 # Are you seriously still going over this? 19.01.28 # hi guys, quick question is it possible to patch using the.patch files on the tracker? 19.01.31 # Llorean, another solution would be to log the battery every time 19.01.45 # so that the next time it have updated values. 19.01.59 # a user who uses a variety of formats should know that runtimes change with format and an estimate is an estimate, after all 19.02.00 # if i change listening habits, it will know very soon 19.02.06 # spiorf: That then gives you an average. Underestimating for NSF, and overestimating for FLAC 19.02.07 Quit matsl (Remote closed the connection) 19.02.21 # Rincewind: Then why does an estimate even matter? 19.02.31 # Why not just use a percentage, if you're saying "it's okay for it to be meaningless" 19.02.49 # Llorean, an estimation based on the last 5 logs? 19.03.02 # spiorf: Then it's an average of them. 19.03.03 # * courtc makes a battery time calculation for ipodlinux. 19.03.07 # this thing is becoming more complicated than it should be 19.03.07 # It's still not that useful 19.03.21 # Llorean: because it gives you a figure how much is left under your usual playing habits. If I listen to flac, and my runtime is calibrated for mp3s, then the estimate will go down slower (because the battery lasts longer) 19.03.28 # it's still better than an estimation based on nothing 19.03.28 # All I'm saying is that runtime is inherently inaccurate, and it doesn't really serve a practical purpose 19.03.44 # Rincewind: The battery lasts shorter with FLAC 19.03.54 # Just for fun. Then I'll make one for ccOS; then I'll shred them both and laugh evilly. 19.03.55 Join petur [0] (n=petur@rockbox/developer/petur) 19.04.01 # Rincewind: But if it goes down faster, that makes the VALUE meaningless, only the rate is important: Again, % is better for judging rate 19.04.04 # then turn my case around, it is still valid 19.04.33 # even an inaccurate value is meaninful for humans 19.04.46 Quit lids (Remote closed the connection) 19.05.13 # If I tell you "I meet you in about an hour" that's ok for you, isn't it? 19.05.31 # ... arguing for the sake of being right. 19.05.33 Quit kahn ("Statistics show only 3% of imigrants are australians") 19.05.41 # courtc: Arguing because I want the feature removed or fixed. 19.05.54 # Rincewind: And if you say "about an hour" and show up in two, I'll be irritated. 19.06.13 # I just mentioned a way to 'fix' it. 19.06.15 # My H120 player says, at 75% capacity, 12hrs 30min left. Its battery only ever lasts 10 19.06.24 # That's a significant percentage wrong 19.07.06 # Llorean: again, this can be fixed with a variable max runtime. No need to remove the whole thing 19.07.25 # I said I was okay with letting the user input their expected max runtime. 19.07.31 # As I KEEP SAYING, I want it fixed or gone 19.07.34 # But I don't like the current one at all 19.07.40 # As it's not useless in a practical sense 19.07.45 # Very much like % volume was not useful in a practical sense 19.07.50 # I dunno, in OSS ususally the person who want something fixed is the one who needs to do the work. 19.08.14 # courtc: And I can do the work, if it comes to that. 19.08.21 # I can even commit it, and have people yell at me, if I wanted to be spiteful 19.08.22 # in fact, at the moment I have my editor open and grep the source to find out where the calculation is done 19.08.29 # But for me, "doing the work" would be removing it. 19.08.35 # If someone has a better way, they should do it. 19.08.35 # Llorean: it's not useless? ;P 19.08.47 # pixelma: What's not useless? 19.08.48 # That's not a solution though. 19.08.58 # Oh, it's not USEFUL 19.08.59 # I can't type 19.09.07 # :) 19.09.07 # courtc: What's not a solution? 19.09.23 # courtc: Removing an impractical feature to recover binary size isn't a solution? 19.09.41 # deleteing the somewhat buggy software. 19.09.54 # It's not somewhat buggy. 19.10.06 # Damn, firefox doesn't open X page correctly, delete. 19.10.10 # It does what it's supposed to do, just what it's supposed to do is not useful in a practical sense. 19.10.11 # It's fluff 19.10.11 # Llorean: impractial is a subjective view in this case 19.10.39 # Rincewind: It only gives useful information under a very limited set of circumstances. 19.10.50 # Rincewind: While % gives useful information for any usage habit. 19.11.30 # then we should improve it, not remove it. If we remove every feature that works only in limited circumstances then we have not much left in rockbox 19.12.23 Join lids [0] (i=lds@gateway/tor/x-bb5c9491aab4b0af) 19.12.29 # Rincewind: Are you saying we should never, ever reconsider the worth of a feature? 19.12.50 *** Saving seen data "./dancer.seen" 19.13.47 # I didn't want to generalize that much, besides, this discussion is pointless, both of us said our opinions and nothings gonna change them... 19.14.07 # My opinion can be changed 19.14.17 # You just haven't said anything that I hadn't already considered before stating mine. 19.14.29 # If yours can't be changed, that's rather narrow-minded. 19.15.21 # my opinion can be changed, it is just that in this case I like the runtime thing very much and use it as the only battery meter on my player 19.15.55 # Arg, smells like memory corruption... 19.15.57 # Then feel free to code a solution that makes it work properly. 19.16.12 # But if nobody's going to bother to fix it, I will continue to attempt to get it removed. 19.16.17 # Because right now it does more harm than good. 19.16.42 # Llorean: I try to implement my little solution I posted to the mailing list 19.19.47 # We'll see how well that can work then. As I said, I wouldn't object to a fix. 19.20.33 # at first I have to find it in the source... 19.21.49 Join chelli [0] (n=chelli@p54b84e87.dip.t-dialin.net) 19.23.31 Quit jhulst (Remote closed the connection) 19.25.18 # Rincewind: The battery graph is telling the voltage over the last 2 hours, measured once per minute 19.25.58 # ok, that explains why there is sometimes something to see and sometimes not (after a fresh start) 19.26.01 # thanks 19.26.24 # Llorean: Btw, runtime will vary less with format than you might think. (video being an exception, also because of my next point) 19.26.34 # yay, I just won an ipod nano 19.26.38 # boo, it is 2nd gen 19.26.44 # A very big sucker especially on colour targets is the lcd backlight 19.27.00 Quit lids (Remote closed the connection) 19.27.01 # amiconn: On my H120 the runtime has never been accurate, and it's gotten worse as my battery has gotten bad. 19.27.17 # Well, it can't be correct if the battery is bad. 19.27.19 # amiconn: I had attributed this mostly to my use of FLAC, but it could just be my battery's medium-condition to start with. 19.27.24 # That's not the algorithm's fault 19.27.38 # Well the battery was getting about the right time in Rockbox initially, until I put my FLACs on. 19.27.52 # * Llorean shrugs 19.27.56 # amiconn: the algorithm is in powermgmt.c right? 19.27.58 # That's why I am pondering auto-calibration, but that's far from trivial 19.28.28 # (1) The user might plug or unplug the charger mid-session 19.28.29 # I just don't like an estimate that tells people a number of hours remaining, when it can only be right under "ideal" conditions. 19.28.59 # (2) In usb mode we can neither predict runcurrent, nor the charge current we get from usb 19.29.08 Join Arathis [0] (n=doerk@p54849BC9.dip0.t-ipconnect.de) 19.29.14 # If I look at it and see 12 hours remaining, that information might or might not be useful. If I looked at it 1 hour ago and saw 14 remaining, then that 12 is more useful. =/ 19.29.31 Quit barrywardell (Remote closed the connection) 19.29.53 # (3) The targets where the batteries *can* be changed (archos player, recorder v1) or even *have to be* changed regularly (Ondio, iFP 7xx) create another problem: 19.30.05 Join oKtosiTe [0] (n=oKtosiTe@ip5450f737.speed.planet.nl) 19.30.44 # We can't simply take averages because the new batteries can be a different brand/capacity/whatever, and to further complicate the matter, can be either alkalines or NiMH cells 19.31.22 # I think the minutes from the estimate can be dropped, because when it says "16h 15min" this implies an accuracy that is simply not possible 19.32.14 # But otoh I do want an adaptive algorithm *especially* for recorder v1, i.e. software charging 19.32.41 # amiconn: maybe have it just for the fixed battery targets then? 19.32.44 # With newer cells the algorithm tends to stop charging prematurely, giving sub-optimal runtime 19.33.16 # ...and it even looks like that doesn't do any good for the cells 19.34.40 Join ross [0] (n=ross@rhav-164-107-255-142.resnet.ohio-state.edu) 19.35.58 Quit PaulJam (".") 19.36.33 # Hey all. Can anyone update me on the status of support for the 5.5 generation 80 gig Video iPod? I came here over a month ago and someone told me that it was a short matter of time until there would be support because the issue had been figured out. If there are issues, is there anything I can do to help? 19.37.35 Join ompaul [0] (n=ompaul@freenode/staff/gnewsense.ompaul) 19.38.23 Join SirFunk [0] (n=Sir@cpe-74-71-205-222.twcny.res.rr.com) 19.39.30 # Gah, yet another case of enablind logf causing problems for devices that supports remotes... :/ 19.41.00 Quit ross ("Leaving") 19.41.57 # markun: I think tracking the current runtime together with current approximation (including charger connection etc) and runtime-derived percentage would work best 19.42.31 # On the LiIon targets looking at the voltage could be used as an additional hint, on the NiMH targets this would simply be left out 19.47.35 # Runtime tracking will require to see a full discharge at least from time to time - and because battery usage instructions for laptops usually say that a full discharge is required from time to time I think that's what's used there too 19.54.59 Join amiconn_ [0] (n=jens@rockbox/developer/amiconn) 19.55.08 Quit amiconn (Nick collision from services.) 19.55.09 Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) 19.56.27 Join juxtap [0] (n=juxtap@wbs-41-208-193-233.wbs.co.za) 19.58.13 Join elinenbe_ [0] (n=elinenbe@209.196.192.7) 20.07.17 Quit Juice- ("Leaving") 20.07.25 Join PaulJam [0] (i=Paul@vpn-3051.gwdg.de) 20.08.00 Join jhulst [0] (n=jhulst@148.61.94.202) 20.12.31 Join petit-lama-tout- [0] (n=opera@242.56.70-86.rev.gaoland.net) 20.18.57 Nick linuxstb__ is now known as linuxstb (n=linuxstb@i-83-67-212-170.freedom2surf.net) 20.19.39 # courtc: What was the ipod lcd bug you found? Have you committed any fixes? 20.20.06 Join mirak [0] (n=mirak@m145.net195-132-203.noos.fr) 20.22.52 Join bawb2 [0] (n=bawb2@ip49252.estcmp.ku.edu) 20.25.08 # has anyone ever attempted a rio carbon port? 20.25.20 Join entheh [0] (n=purr@88-106-193-244.dynamic.dsl.as9105.com) 20.25.25 Join moos [0] (i=moos@m135.net81-66-158.noos.fr) 20.26.08 Join Alonea [0] (n=chatzill@24-117-195-16.cpe.cableone.net) 20.26.12 # lostlogic: I can't remember anyone mentioning it, at least not recently. 20.27.02 # my boss has one and was wondering -- seems ot have a general purpose cpu and a microdrive. 20.29.35 Quit rift (Read error: 110 (Connection timed out)) 20.30.21 # lostlogic: rio carbon = crud! 20.30.34 # that company self-destructed... 20.34.56 Join raphi [0] (n=Raphi@pub082136121134.dh-hfc.datazug.ch) 20.36.01 Join kaaloo [0] (n=luis@cblmdm72-240-248-25.buckeyecom.net) 20.36.20 Part kaaloo 20.36.44 # In case anyone has missed: Rockbox on dl.tv. About to download it myself... 20.37.48 # dl.tv? 20.38.17 Quit Alonea ("ChatZilla 0.9.78.1 [Firefox 2.0.0.3/0000000000]") 20.38.21 # Vidcast. 20.38.42 # About computer/tech stuff. 20.39.43 # http://dl.tv/2007/04/episode_156_the_best_inputs_an.php 20.40.50 Join Alonea [0] (n=chatzill@24-117-195-16.cpe.cableone.net) 20.41.23 # ok, I updated my rockbox (its been a week or two) and now all of my videos say "Incompatible Version" 20.42.21 # Alonea: That means your plugin version is different from your binary 20.42.49 # Did you install by simply extracting to the device? 20.42.52 # Llorean: ok. I get plugin version, but binary? 20.43.15 # Alonea: Rockbox.whatever (ipod, mi4, iriver...) 20.43.22 # What player do you have? 20.43.35 # Llorean: I compiled, made zip, extracted zip and copied it over to my drive. (have gigabeat) and overwrited what was there 20.44.16 # Is your bootoader up to date? 20.44.28 # Llorean: should be. Unless there is a new one again 20.44.47 # And is there a rockbox.gigabeat in your device root, in the /.rockbox folder, or both? 20.44.47 # Has it been updated last couple weeks? 20.45.06 # rockbox.gigabeat is just in /.rockbox 20.45.45 # This suggests somehow mpegplayer.rock didn't get overwritten. 20.45.49 # Do any other plugins work? 20.45.58 # let me check 20.47.06 # ^^;;;; 20.47.13 Quit miepchen^schlaf (Read error: 113 (No route to host)) 20.47.13 # Nevermind...I fixed it 20.47.27 # Forgot to shut down and reboot after copying over the new version? 20.47.39 # It MIGHT help if I reset my player. I am sick today so brain is slow 20.47.40 Join miepchen^schlaf [0] (n=hihi@p54BF4DD7.dip.t-dialin.net) 20.47.53 # No worries I've done it a few times too. :) 20.47.59 # It'd help if RoLo worked 20.48.11 # * Llorean goes away. 20.48.26 # oh! one of the screens is messed up a bit now 20.49.01 # when you hold down the menu button that one where it controls shuffle, repeat and show Files? The Shuffle on the left side is higher than the repeat on the opposite side. 20.49.24 # It's always been this way 20.49.35 # Or more specifically, it's been this way since long before the Gigabeat port existed 20.49.42 # Llorean: its always been perfectly centered though 20.50.13 # Repeat has always been lower than Shuffle 20.50.17 Quit bluebrother ("leaving") 20.50.27 # It's often not noticed with smaller fonts. 20.50.38 # Or just not noticed. 20.50.45 # Llorean: ah, ok. maybe thats it..its quite noticable at the moment 20.51.00 # Trust me, it's been this way for quite some long time. 20.51.28 # If I recall it was the change that allowed the quickmenu to be in other languages, but I'm not 100% certain that was the change that did it. 20.51.44 # If I recall some of the lines were too long when they were even. 20.52.24 # Llorean: ah. ok. Well, it just seems at more of an extreme than it used to. 20.52.59 # well, I should goto class...bah. 20.53.05 Quit Alonea ("ChatZilla 0.9.78.1 [Firefox 2.0.0.3/0000000000]") 20.58.17 Quit x1jmp (Read error: 113 (No route to host)) 20.59.37 Join Llorea1 [0] (n=Llorean@cpe-66-69-210-194.austin.res.rr.com) 21.01.07 Part raphi 21.02.58 # re 21.07.19 Quit linuxstb (Read error: 110 (Connection timed out)) 21.07.45 Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) 21.09.58 Quit RaRe (Read error: 113 (No route to host)) 21.12.45 # anybody here know bidi_l2v well ? 21.12.53 *** Saving seen data "./dancer.seen" 21.13.58 # nevermind 21.16.23 Quit Llorean (Read error: 110 (Connection timed out)) 21.16.39 Part pixelma 21.18.55 Join lee-qid [0] (n=liqid@p54964F21.dip.t-dialin.net) 21.19.48 Nick dionoea is now known as bork_bork_bork (n=dionoea@poy.chewa.net) 21.20.18 Nick bork_bork_bork is now known as dionoea (n=dionoea@poy.chewa.net) 21.23.42 # does anyone have the pinout of the X5 subpack connector? 21.27.23 # http://www.rockbox.org/twiki/bin/view/Main/PortPinAssignments#Subpack_Connector 21.28.56 Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) 21.30.34 Quit desowin ("use linux") 21.35.23 Join pit_ [0] (n=pit@BAA2e87.baa.pppool.de) 21.36.08 # help! my iriver 320 doesn't boot into rockbox, it just shows a white screen 21.36.24 # i can't reset and i can't switch it off 21.36.29 # white? 21.36.36 # forgot to release the usb-cable 21.36.51 # petur: kind of bright grey 21.36.55 # ah battery flat? 21.37.17 # petur: maybe. i tried to recharge it but the behaviour doesn't change 21.37.37 # with th AC adapter I hope 21.37.57 # yes. whith the original adapter. 21.38.21 # how long did you keep it plugged in? 21.38.34 # over night and again a whole day long 21.39.02 # that's long 21.39.10 # and reset doesn't do anything? 21.39.15 # exactly 21.40.33 # LinusN is your man regarding H3x0 hardware 21.40.54 # maybe you can let the battery run flat, then try charging again 21.41.08 # looks like he isn't here at the moment ... 21.41.16 # no he isn't 21.41.49 # is it possible to open the hardware to charge the battery externaly? 21.41.59 # you can open up your h320 and disconnect the battery, but it's not so easy 21.42.11 # front and back need to be removed 21.42.15 # Does that mean that even reset doesn't power off? 21.42.28 # Note that it won't power off if the charger is connected 21.42.31 # i couldn't figure out how to open it - it has got 5 screws but after removing it i wasn't able go open the iriver. 21.42.37 # someone broke tagcache disabled build on ipod 5g 21.43.13 # amiconn: that's right. i released the charger and also the usb-cable but it wasn't still possible to reset it. 21.43.38 # pit_: here's how you open it: http://www.misticriver.net/showpost.php?p=363259&postcount=118 21.44.10 Quit Febs (Read error: 104 (Connection reset by peer)) 21.44.28 # petur: ah great! i knew i saw it before but i couldn't find it again ... 21.44.57 # pit_: are you sure the screen is still on? maybe the battery ran flat and you hit a bug in the bootloader: try holding REC while pressing ON 21.45.53 # petur: i tried this very often ... 21.46.57 # i noticed that the harddisk never runs but the screen shows some lights 21.49.01 Join nls [0] (n=nils@nl104-202-175.student.uu.se) 21.49.40 # pit_: sorry, no idea... maybe try to disconnect the battery 21.51.24 # petur: thx anyway. maybe i first try to discharge the battery by waiting one or twow days. 21.54.19 # Doesn't look like logf is used much these days 21.54.37 # * amiconn only used it 1 or 2 times back when it was relatively new 21.57.17 # I used logf quite a bit when I was working on buffering bugs in playback. but that was a long time ago now. 21.58.11 # = a year ;) 21.58.19 # I rather place my debug output on demand (e.g. using splashes) rather than enabling logf and getting a ton of output from modules interfering with what I want to debug 21.58.28 # thx a lot. see you! 21.58.31 # bye 21.58.43 # pit_: all the best 21.58.59 Quit pit_ ("Verlassend") 22.04.14 # I always enable logf in the simulator (more out of habit, but it can be handy sometimes), since I use it for debugging. 22.04.52 # hmm. 22.05.12 Join lini [0] (i=pugsley@62.204.144.237) 22.05.15 # Imho the simulator doesn't need logf at all, since there is debugf, which is always enabled anyway 22.06.03 # For the target it probably depends on what you're doing 22.06.23 # E.g. I didn't need any logf/debugf at all for my charcell lcd driver rework 22.06.51 # If the lcd driver doesn't do what it should, it's quite obvious (and logf would probably not help either) 22.07.07 Join jonezi [0] (i=Lemmy@85-210-189-108.dsl.pipex.com) 22.07.28 # * amiconn fails to remember when he last used logf or debugf 22.07.47 # Btw, the "it" in "use it for debugging" refers to the simulator, not logf, in case that wasn't clear. :) 22.08.12 # Anyone here know anything about the devolpment of RB for iriver h10? 22.08.56 Quit nls (Remote closed the connection) 22.11.26 # jonezi: barrywardell is the main H10 person, but he isn't here. However, if you ask a question maybe someone will know. 22.11.35 Join nls [0] (n=nils@nl104-202-175.student.uu.se) 22.11.53 # Just got a quick question about battery life and its optimization. 22.11.54 Quit matsl (Remote closed the connection) 22.12.43 # jonezi: That's probably not specific to the H10, but all devices with the same CPU (ipods, Sansa) 22.13.46 # So as I understand it the battery has not yet been fully optimized for these devices, Coorrect? 22.13.47 Quit Thundercloud (Remote closed the connection) 22.13.48 Join hannesd_ [0] (n=light@gate-hannes-tdsl.imos.net) 22.14.13 Join TrueJournals [0] (n=aimjourn@c-24-12-147-61.hsd1.il.comcast.net) 22.14.16 Join Thundercloud [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) 22.14.16 # Well, Rockbox is draining much more power than we would expect it to. 22.14.23 Quit adiamas ("ChatZilla 0.9.78.1 [Firefox 2.0.0.3/2007030919]") 22.14.32 # Well, the battery isn't really something you can optimize... :p 22.14.49 # well, the CPU then maybe 22.14.53 # The general concensus is that we're not configuring the portalplayer chip optimally. But that's hard to fix as there is no documentation. 22.15.02 # right 22.16.34 # hum crap, i broke my subs code ... (shouldn't have changed everything at once i guess :p) 22.17.02 Quit bluey- (Read error: 110 (Connection timed out)) 22.19.40 Quit nls (Remote closed the connection) 22.20.03 Join nls [0] (n=nils@nl104-202-175.student.uu.se) 22.20.04 Join Mmmm [0] (n=martin@cpc2-hem13-0-0-cust689.lutn.cable.ntl.com) 22.20.29 Quit nls (Remote closed the connection) 22.20.54 # thanks for all the work you guys put in anyway, muchly appreciated, hope you solve this problem soon!!!! Cheers 22.22.53 Part jonezi 22.26.13 # dionoea: you got subs almost working ? 22.26.49 Quit Lear ("Chatzilla 0.9.77 [Firefox 2.0.0.3/2007030919]") 22.27.36 # Nico_P: i had them working, i cleaned the code and now it's working (except that timing is a bit screwed now ... i'll find the error and fix it) 22.27.52 # dionoea: that's awesome ! 22.27.53 # Cleaning code is always a risk :) 22.28.05 # mpegplayer is progressing very fast 22.29.43 Join pixelma [0] (i=pixelma@rockbox/staff/pixelma) 22.33.00 # is there a gbs player in rb? 22.34.50 # gameboy music? 22.35.23 # yeah 22.35.52 # start porting one? 22.36.40 # google points me to http://nezplug.sourceforge.net/ 22.37.22 # I guess that's a no? 22.37.47 # well not that I know of... 22.40.01 # nezplug is "free for non-commercial use" IIUC. 22.40.36 # game_music_emu is GPL, but C++, and it has a fair amount of funny band-limited synthesis 22.48.32 Join inversions [0] (n=none@cpc3-bele3-0-0-cust660.belf.cable.ntl.com) 22.49.02 Quit Arathis ("Bye, bye") 22.49.59 # * petur kicks buildserver 22.50.56 # * pixelma wonders when "buildserver" is going to show up here ;) 22.51.09 Quit miepchen^schlaf (Read error: 104 (Connection reset by peer)) 22.51.29 Join miepchen^schlaf [0] (n=hihi@p54BF4DD7.dip.t-dialin.net) 22.51.42 Quit billytwowilly (Read error: 104 (Connection reset by peer)) 22.51.48 # * petur hasn't seen forehead for a while - the irc user, that is ;) 22.51.56 Quit chelli ("Client exiting") 22.52.16 Join billytwowilly [0] (n=chris@S01060016b649355d.ed.shawcable.net) 22.52.34 Join buildserver [0] (i=52b61a05@gateway/web/cgi-irc/labb.contactor.se/x-daf2da838793343d) 22.52.46 # :-P 22.52.50 Quit buildserver (Client Quit) 22.52.53 # ;) 22.53.11 Join forehead [0] (i=4ca871a9@gateway/web/cgi-irc/labb.contactor.se/x-40c40b636de334bc) 22.53.16 # you rang? 22.53.39 # you wrong 22.53.48 # =( 22.53.53 # * petur slaps forehead 22.54.04 # in soviet russia.... 22.54.11 # * forehead slaps petur 22.54.20 # Nico_P: i think that i found my bug's cause. I'll be able to commit soon 22.55.13 Quit forehead (Client Quit) 22.55.37 Join SliMM [0] (n=chatzill@89.136.181.105) 23.01.25 # hum 23.01.29 # i have shutdown my ipod 23.01.38 # and now it doesn't start 23.02.29 Join hannesd__ [0] (n=light@gate-hannes-tdsl.imos.net) 23.04.32 Quit midgey () 23.05.00 Quit Soap2 (Read error: 110 (Connection timed out)) 23.09.33 Join midgey [0] (n=tjross@markely-164-75.reshall.umich.edu) 23.10.11 # turn off hold and/or charge it 23.10.14 # petit-lama-tout: is it charged 23.10.40 # linuxstb, jhMikeS : is it ok if i commit the subtitles code right away? or would you like to see a diff first? 23.11.35 # hum 23.11.38 # now it start 23.11.41 # very strange 23.12.45 Quit miepchen^schlaf (Read error: 104 (Connection reset by peer)) 23.12.50 # dionoea: I'm curious to see a diff... 23.12.51 # dionoea: does it get into the frame rendering? I've got a change on that coming. 23.12.52 # dionoea: subtitles code... ? 23.12.55 *** Saving seen data "./dancer.seen" 23.13.05 Join miepchen^schlaf [0] (n=hihi@p54BF4DD7.dip.t-dialin.net) 23.13.11 # jhMikeS: it adds a function call in the frame rendering thing 23.13.14 # the frame dropping is pretty smooth overall now 23.13.18 # i'll post a diff online 23.13.18 # hmmm 23.13.20 # ok 23.15.34 # http://people.videolan.org/~dionoea/mpegplayer.subtitles.patch 23.15.54 Join Thundercloud_ [0] (n=thunderc@84-51-130-71.judith186.adsl.metronet.co.uk) 23.16.28 # This code supposes that 1/ the subs file is valid and 2/ it all fits into the buffer (the second supposition is stupid...) 23.17.01 # But it's a poc (kind of) 23.17.02 Join rift [0] (n=opera@242.56.70-86.rev.gaoland.net) 23.17.06 # the first one too imho 23.17.24 # well validating everything would take way too much time 23.17.33 # that's true yes 23.17.46 # as long as it doesn't crash... 23.17.53 # I never said that :) 23.18.28 # ED hovers from 14-16 fps on X5 now regulated...still a bit rough due to lack of B frames in the clip 23.18.36 Quit hannesd_ (Read error: 110 (Connection timed out)) 23.18.40 # dionoea: Why not simply allocate the buffer based on the filesize of the .srt file? 23.19.05 # btw, you can get the subs here: http://members.chello.nl/j.kassenaar/elephantsdream/subtitles.html 23.19.22 # linuxstb: i could do that too ... would be easier 23.19.41 # subs file never take more that 200 kB right ? (and that'd be for a full movie) 23.20.08 # I've just created an srt file from a 1-hour video and it's 39KB... 23.20.24 # k 23.20.28 # We'll i'll do that then 23.20.49 # If you can have a look at the general aspects of the patch (like where i call the different functions and stuff) it'd be great 23.21.28 # Bagder: something is wrong with the updating of the frontpage. The build of 20:56 did something strange it seems 23.21.46 # I poked on it manually to trigger it 23.21.56 # something strange happened before that 23.22.21 # the front page should show the dates and times correct of the actual commits 23.22.23 # now you can see all commits when you look at the diffs 23.22.30 # rb->filesize( ) returns the full file size ? 23.22.54 # dionoea: I'm just commenting on things as I see them.... You call subs_render() even if there are no subtitles? 23.23.05 # does anyone know if anyone ever worked on or even suggested a realtime spectrum analysis on the recording screen? i am just listening to a few recordings i made and i think that would REALLY help setting up the mics in a noisy envoirement (where listening into the signal with headphones is impossible) 23.23.21 # yeah. I could move the check out of the function 23.23.24 # very low resolution, lets say 5 bars or so, would be enough 23.23.27 Quit Rob2222 () 23.24.39 Quit funky ("leaving") 23.24.46 # because even with well isolating headphones (as my modded koss plugs) the outside influence is just to high to properly set up the mics, its always been a lot of guesswork aiming them towards the tops... 23.25.08 Quit miepchen^schlaf (Read error: 104 (Connection reset by peer)) 23.25.14 Quit petur ("here today, gone tomorrow") 23.25.28 Join miepchen^schlaf [0] (n=hihi@p54BF4DD7.dip.t-dialin.net) 23.25.54 # dionoea: Why "#define atoi(a) rb->atoi(a)" ? 23.26.03 # for my eyes 23.26.16 # bagawk: hmm... that came out strange- when you want to look at the last build (to see the details) from the builds page you will see all the commits from rev1 up to today (huge and interesting list btw) 23.26.19 Quit Thundercloud (Read error: 110 (Connection timed out)) 23.26.23 # linuxstb: I can remove it if it's a problem 23.26.34 # that was to Bagder... sorry 23.26.35 Quit davina ("byeeeeee!") 23.26.49 # I really think a general overlay solution should be in place 23.27.13 # and 44100 is also assumed I notice... 23.27.13 Part TrueJournals 23.27.26 # pixelma: oh, hehe 23.27.26 # Yep. Is that defined somewhere ? 23.27.33 # my silly script... 23.27.59 # yes...but the video decoder decodes the HH:MM:SS on the frames too :) 23.28.42 # dionoea: I think it's a general principle not to #define when it's not needed... Also I think "typedef struct" is frowned upon as well (but others will correct me) 23.28.43 # jhMikeS: well we could have a full overlay system. With a bunch of sub pictures to render at every time. But that would need more memory (i'm not sure about CPU time) 23.29.02 # linuxstb: ok. I'll change that. 23.29.17 # would it be ok if I inline instead ? 23.29.49 # We don't need anything but a mask 23.30.37 # dionoea: inline what? 23.31.00 # inline int atoi( const char *s ){ return rb->atoi( s ); } 23.31.17 # Why not just use rb->atoi() directly? 23.31.18 # I'd really like to have YUV stuff not in the core since I plan on multiple blit functions to always use an optimized one. 23.31.23 # jhMikeS: you'd still need to render to the mask and then blend the mask on the video 23.32.05 # while I'm rendering directly to the video buffer 23.32.15 # The mask only tells me which to use: lcd_framebuffer or yuv buffer ... in another sense, a _selectable_ chroma key may work too 23.32.23 # On targets with extra CPU it's a good idea to do it your way. I'm not sure for others 23.32.33 Join webguest35jaime [0] (i=522368cd@gateway/web/cgi-irc/labb.contactor.se/x-39ee67e788bccc82) 23.32.43 # hi 23.33.32 # wondered if anyone new if rockbox will likely become available for samsung models 23.33.39 # Yeah, for the really slow stuff, yeah, just cut the video away. I'd like this stuff handled automatically in the video out though 23.33.48 Quit petit-lama-tout- (Read error: 110 (Connection timed out)) 23.34.00 Join MrStaticVoid [0] (n=jlee@wireless-168-115.umbc.edu) 23.34.11 # dionoea: Is your code rendering the text repeatedly each frame? 23.34.26 # yes. (since each video frame changes) 23.34.39 # if you're rendering on the black bands it only updates on changes 23.34.57 Quit Mmmm (Remote closed the connection) 23.35.00 # Yes, but the text doesn't... You could render the text into a buffer (cache), and then just blit that buffer into the video frame. 23.35.02 # (but i don't remove the old text in that scenario ...) 23.35.51 # hum ... ok :) jhMikeS and linuxstb win :D I'll have an overlay cache which i'll blend onto the video 23.35.51 Quit webguest35jaime (Client Quit) 23.36.02 # (well, on the video y plane at least) 23.36.28 # let us remind ourselves...what is "slow" not may not be for very long 23.36.40 # s/not/now/ 23.37.40 # Anyone wanting to check out my newest win32 simulator unicode patch? 23.38.17 # Now it also prints unicode text correctly for debug messages, provided the console is set to use a truetype font 23.38.43 Quit billytwowilly (Read error: 110 (Connection timed out)) 23.42.53 Quit Juice^ ("Leaving") 23.45.29 # amiconn: i'll do it, but tommorow 23.46.35 Join SliMM_ [0] (n=chatzill@89.136.181.105) 23.47.17 Quit SliMM_ (Client Quit) 23.47.56 Join drumr [0] (n=user@ool-44c2019c.dyn.optonline.net) 23.47.59 # hi 23.48.10 # im having some trouble with my ipod 5g 23.48.35 # i installed a new build on top of an old one, and when i try to play music (i tested mp3 and flac) it gives a codec error. 23.48.45 # im going to completely replace the build now 23.48.50 # but, will that fix it? 23.48.59 # and also, how do i clear the ram? 23.49.19 # i remember on the h3xx you hit the hold switch after it started up but before rockbox booted 23.49.27 # now that boots into the stock apple f/w 23.50.10 Join amiconn_ [0] (n=jens@rockbox/developer/amiconn) 23.50.11 # Do you have a rockbox.ipod file in both the root of your ipod and inside the .rockbox directory? 23.50.22 Quit amiconn (Nick collision from services.) 23.50.22 Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) 23.51.38 Join x-spec-t [0] (n=nwheeler@ubuntu/member/spec) 23.51.42 Quit Spec (Read error: 54 (Connection reset by peer)) 23.51.45 Join ctaf [0] (n=ctaf@ram94-6-82-242-23-70.fbx.proxad.net) 23.51.51 # what's the fuss about removing the battery estimation feature? 23.51.57 Part ctaf 23.52.12 # for some works like a charm and in most cases it doesn't work right for non calibrated targets 23.52.51 # anyway I don't think that by removing it rockbox will gain much in binary size, so for the people that are annoyed by it, just don't use it :P 23.53.13 # * linuxstb doesn't see any point in removing it 23.53.19 # exactly 23.53.31 # it is a hate it or love it feature 23.56.57 Join Rob2222 [0] (n=Miranda@p54B16DA7.dip.t-dialin.net) 23.58.22 # on the other hand I can understand Llorean's frustration at always having to explain that this one won't work reliably for many targets, but IMHO I don't see a reason to remove it cause it will confuse some new users. 23.58.25 Join Spec[x] [0] (n=nwheeler@charon.devis.com)