--- Log for 22.12.111 Server: wolfe.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 10 days and 0 hours ago 00.00.00 # kugel: okay, if needed we can rework them a bit hehe 00.00.05 # sourcing has the other advantage that you can set env variables in the scripts. they'll be visible in the caller script 00.00.45 # uhm yeah we can clean them up in this way... 00.02.02 # lorenzo92: i go to bed now, thanks for your time 00.02.07 Quit T44 (Ping timeout: 240 seconds) 00.02.17 # yeah me too, thanks you too ;) 00.02.26 # I will start the bench now :D 00.02.29 # bye! 00.04.38 Quit lorenzo92 (Quit: ChatZilla 0.9.87 [Firefox 8.0/20111115183813]) 00.04.59 Quit bertrik (Quit: And That, My Liege, Is How We Know the Earth to Be Banana Shaped) 00.06.23 Quit Misan (Remote host closed the connection) 00.12.11 Quit Thra11 (Ping timeout: 244 seconds) 00.15.17 Join Scromple [0] (~Simon@119.225.209.134) 00.15.59 Quit lebellium (Quit: ChatZilla 0.9.87 [Firefox 9.0/20111212185108]) 00.18.50 Quit domonoky (Read error: Connection reset by peer) 00.23.39 Quit ender` (Quit: Kiss a pair of boobs and the movie's rated R. Chop them off and it's PG-13. -- Jack Nicholson (?)) 00.30.53 Quit pamaury (Remote host closed the connection) 00.37.08 Join Yollean [0] (~chatzilla@pool-108-50-15-245.sctnpa.east.verizon.net) 00.38.32 Quit Yollean (Client Quit) 00.38.47 Join Yollean [0] (~chatzilla@pool-108-50-15-245.sctnpa.east.verizon.net) 00.38.48 Quit Yollean (Client Quit) 00.39.02 Join rasher_ [0] (~chatzilla@pool-108-50-15-245.sctnpa.east.verizon.net) 00.40.29 # Hmm anyone experienced any problems with aac being slow 00.40.56 Quit rasher_ (Client Quit) 00.41.10 Join finis [0] (~chatzilla@pool-108-50-15-245.sctnpa.east.verizon.net) 00.41.39 Part jefffp 00.41.43 Quit finis (Client Quit) 00.47.49 # stereo 44.1 khz AAC? 00.59.40 Quit bluefoxx (Quit: 5a 65 75 73 73 2d 73 6f 64 64 69 74 2d 66 75 63 6b 2c 20 49 27 6c 6c 20 62 65 20 62 61 63 6b 2e 2e 2e) 01.00.59 Join nosa [0] (~m00k@adsl-74-235-42-181.clt.bellsouth.net) 01.02.58 Join JdGord [0] (~AndChat@106.71.96.192) 01.03.20 Quit nosa-j (Ping timeout: 244 seconds) 01.03.20 Nick nosa is now known as nosa-j (~m00k@adsl-74-235-42-181.clt.bellsouth.net) 01.04.33 Quit anewuser_ () 01.06.05 Join anewuser [0] (~anewuser@186.93.204.116) 01.06.05 Quit anewuser (Changing host) 01.06.05 Join anewuser [0] (~anewuser@unaffiliated/anewuser) 01.15.07 Join bluefoxx [0] (fuzzylomba@S0106e0cb4e0a6d8a.vs.shawcable.net) 01.16.30 Join nick-p [0] (~nick@82-69-105-120.dsl.in-addr.zen.co.uk) 01.18.44 # JdGord: ping 01.19.00 # Pong 01.19.08 # Is a new General Settings > Startup/ Shutdown menu something you could live with? 01.20.03 # Yeah, its a bit excessive but meh 01.20.59 # I thought so too, I'm just trying to put forward something that <= one person will object to ;) 01.22.01 # Don't even bother trying 01.22.13 # Too many people for everyone to stay happy 01.23.18 # At least this way is not such an upheaval to move things around under General Settings at a later date 01.24.10 # Your good work campaigning for moving T&D into Settings paved the way! 01.25.56 Quit toffe82 (Quit: ChatZilla 0.9.87 [Firefox 9.0/20111216140209]) 01.30.16 *** Saving seen data "./dancer.seen" 01.30.43 Join Keripo [0] (~Keripo@dhcp0751.kin.resnet.group.upenn.edu) 01.31.40 # Nick: wasn't I against it? :) 01.33.19 Quit factor (Quit: Leaving) 01.34.45 # Oops, didn't realise you were in the the opposing camp :) 01.35.17 # I thought you were in favour of ultimatly getting rid of the root level System menu 01.36.56 # That I am 01.37.09 # But t&d isn't settings :) 01.37.40 # Its also possible I just swapped sides (as I'm prone to being contrarian) 01.38.20 # Once it's ben asset stripped it could even go back, ha ha 01.40.22 # I agree about the not a setting arguement btw, but I also agree with the "that's how everone else does it" position 01.42.28 # Anyway, I'll put together a patch in the (uk) morning, bye for now 01.43.24 Quit nick-p (Quit: Leaving) 02.01.00 Quit ehntoo_ (Ping timeout: 252 seconds) 02.23.12 Join factor [0] (~factor@74.197.205.204) 02.29.47 Join jdgord_ [0] (~AndChat@123-243-140-31.static.tpgi.com.au) 02.33.06 Quit JdGord (Ping timeout: 240 seconds) 02.42.08 Join JdGord [0] (~AndChat@123-243-140-31.static.tpgi.com.au) 02.43.05 Quit jdgord_ (Ping timeout: 252 seconds) 02.45.35 Join jdgord_ [0] (~AndChat@58.108.53.55) 02.46.23 Quit JdGord (Ping timeout: 252 seconds) 03.30.18 *** Saving seen data "./dancer.seen" 03.37.30 Join webguest32 [0] (~027f078f@www.haxx.se) 03.37.52 # Hi everybody just have a quick question 03.38.01 # I installed rockbox on my sansa fuze 03.38.19 # then wanted to remove it, so I deleted all rockbox related files on the player 03.38.35 # check the uninstall directions in the manual 03.39.11 # But now when I turn it on normally, the rockbox start screen shows up followed by a black screen saying firmware not found 03.39.22 # the manual wont tell me how to return it to normal 03.39.29 # <[Saint]> Uninstallation is "updating" the original firmware with a clean firmware file. 03.39.36 # all rockbox files are gone yet why is tht screen still cming 03.39.50 # so how do i return it to normal 03.39.57 # <[Saint]> You didn't remove the bootloader. 03.40.07 # follow the uninstall directions 03.40.15 # <[Saint]> Its patched into the firmware. Read the manual. 03.40.28 # ok will do cheers 03.41.51 # <[Saint]> Out of curiosity, for what reason did you decide to remove rockbox? 03.43.17 # basically this is a sub-issue pertaining to a main issue im having 03.43.35 # when I put songs on the sansa some fail to appear 03.43.46 # Iv tried both msc and mtc mode 03.43.57 # as well as dragging nd dropping and wmp 03.44.11 # a folder will appear in the directory 03.44.20 # but the mp3 files themselves will be missing 03.44.31 # whats wrong does any one know? 03.46.23 # <[Saint]> Incorrect "show files" setting? 03.46.42 # <[Saint]> Are they able to be viewed from a PC? 03.48.56 # no, the folder will appear on both the PC and player however the mp3 files themselves wont 03.49.54 # <[Saint]> Does this happen only with rockbox? 03.50.14 # <[Saint]> Or with the sansa firmware also? 03.50.24 # no with both firmwares 03.52.12 # <[Saint]> Then it sounds like a problem with your operating system, or some very weird hardware bug with the player. 03.53.13 # shit 03.53.26 # well iv tried it on many PCs 03.53.38 # so the player is probably screwed right 03.53.58 # <[Saint]> The first thing to do would be to check the filesystem. 03.54.12 # how? 03.54.12 # <[Saint]> Google can help here. 03.54.23 # Im a retard with technology btw sorry 03.54.43 # i shall google it, what should I check for? 03.55.09 Join JdGord [0] (~AndChat@58.108.53.55) 03.55.20 Quit jdgord_ (Read error: Connection reset by peer) 03.59.02 # on second thoughts never mind that 04.00.24 # Im trying to remove the bootloader with rockbox utility. It is unable to do so, its coming up with the message "rockbox utility cannot uninstall the bootloader on this target. Try a normal firmware update to remove bootloader" 04.00.30 # what does this mean 04.00.44 # should I reinstall the sansa firmware 04.00.51 # evern though its already present 04.01.40 # <[Saint]> Its telling you "update the firmware with a clean firmware file, using the method you would normally use to do so" 04.02.20 # which firmware, sansa or rockbox 04.03.07 # <[Saint]> Well...you're trying to remove rockbox right? The sansa firmware. 04.03.19 # <[Saint]> The manual covers this. 04.07.01 # lol. thanks. 04.11.59 Join [Saint_] [0] (~Saint]@unaffiliated/saint/x-8516940) 04.13.00 Quit [Saint] (Ping timeout: 252 seconds) 04.19.45 Quit TheSeven (Disconnected by services) 04.20.06 Join [7] [0] (~TheSeven@rockbox/developer/TheSeven) 04.28.05 Join Mad_Max [0] (~chatzilla@c-71-193-88-25.hsd1.mn.comcast.net) 04.29.17 # Hi I have an iPod classic (the newest model) and when I plug it into my computer (windows 7) I get a "usb not recognized" message. Do you guys know of any fixes? 04.29.26 Quit factor (Ping timeout: 248 seconds) 04.31.58 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 04.32.04 Quit [Saint_] (Ping timeout: 252 seconds) 04.34.34 Quit amiconn (Disconnected by services) 04.34.35 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.34.57 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 04.35.18 Quit pixelma (Disconnected by services) 04.35.20 Join pixelma_ [0] (quassel@rockbox/staff/pixelma) 04.35.22 Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) 04.37.00 Quit froggyman (Quit: People who think they know everything are really annoying to those of us who actually do.) 04.38.01 Join froggyman [0] (~froggyman@unaffiliated/froggyman) 04.38.19 Quit dys` (Ping timeout: 252 seconds) 04.39.02 Join dys` [0] (~andreas@krlh-5f713315.pool.mediaWays.net) 04.40.27 Quit JdGord (Ping timeout: 252 seconds) 04.41.03 Quit webguest32 (Quit: CGI:IRC) 04.46.30 # Hello? 04.47.06 # Mad_Max: which revision of rockbox you running ? 04.47.07 # <[Saint]> Hi...plenty of people around. Just ask your question if you have one. 04.48.15 # I am running one of the nightly builds, I believe from the 6th or 7th 04.48.37 # revision number? you can find it in debug info i think 04.48.55 # also always try the latest revision before reporting a bug 04.49.27 # <[Saint]> Version is in rockboxinfo iirc. 04.50.25 Quit froggyman (Quit: People who think they know everything are really annoying to those of us who actually do.) 04.50.54 Join froggyman [0] (~froggyman@unaffiliated/froggyman) 04.54.07 # Sorry, it took me so long to reply r31237-11214 04.54.32 # I am somewhat of a newbie at this so forgive me if it takes a while 04.55.40 # funman: I can't try the newest verson, as windows won't let me access the drive 04.56.42 # ah you can't boot the ipod OF ? 04.57.40 # No, I don't have it dual booted 04.58.29 # I can access the emcore boot menu though 04.59.13 # reinstall everything from scratch i would say 05.00.03 # Yikes, does that mean format through emcore? 05.03.22 # funman: one more thing, should I select the option to clear the rockbox configuration, clear the rockbox database, or reformat data partion? 05.04.12 # i have absolutely no clue, emcore is [7]'s work 05.04.48 # Oh okay, thanks I'll look around 05.16.21 # Hi, I just wanted to let everyone know (also this may be useful for the log) That I got it working successfully by reformatting, reinstalling the .ubi then reinstalling rockbox 05.16.31 # Thanks for your help everyone. 05.20.07 # New commit by 03funman (r31399): usb-drv-as3525v2: use all endpoints 05.22.04 # r31399 build result: All green 05.27.48 Quit Mad_Max (Quit: ChatZilla 0.9.88 [Firefox 12.0a1/20111221031226]) 05.30.23 *** Saving seen data "./dancer.seen" 05.41.35 Quit Horscht (Quit: Verlassend) 05.43.01 # oops he left without telling if usb worked in latest build 05.45.09 Join Rob2222 [0] (~Miranda@p4FFF3548.dip.t-dialin.net) 05.49.10 Quit Rob2223 (Ping timeout: 252 seconds) 05.54.33 Join factor [0] (~factor@74.197.205.204) 06.03.36 # when I set an alarm how can I go back to playing music? 06.03.41 Join dhrasmus [0] (~dhrasmus@173-26-133-131.client.mchsi.com) 06.05.27 Quit [Saint] (Read error: Connection reset by peer) 06.06.00 # trying to enable HID on clip zip: [ 4293.002670] generic-usb: probe of 0003:0781:74E5.0006 failed with error -22 06.06.08 # errno 22 = EINVAL (invalid argument) ? 06.06.31 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 06.11.11 # http://pastie.org/3055774 : lsusb -v (hid is there) 06.11.31 # linux s3c-hsotg.c has some special code for interrupt endpoints but it seems only needed for PIO and we use DMA 06.12.32 Quit dhrasmus (Quit: Leaving) 07.30.25 *** Saving seen data "./dancer.seen" 07.55.17 Join TheLemonMan [0] (~LemonBoy@ppp-85-43.26-151.libero.it) 08.01.47 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 08.08.36 Join antil33t| [0] (~Ahurhurr@101.98.150.103) 08.09.50 Join nick-p [0] (~nick@82-69-105-120.dsl.in-addr.zen.co.uk) 08.11.00 Quit antil33t (Ping timeout: 255 seconds) 08.16.00 Join antil33t [0] (~Ahurhurr@101.98.150.103) 08.18.40 Quit antil33t| (Ping timeout: 252 seconds) 08.24.11 Join antil33t| [0] (~Ahurhurr@101.98.150.103) 08.26.45 Quit antil33t (Ping timeout: 255 seconds) 08.28.56 Join antil33t [0] (~Ahurhurr@101.98.150.103) 08.31.08 Quit antil33t| (Ping timeout: 240 seconds) 08.34.18 Join antil33t| [0] (~Ahurhurr@101.98.150.103) 08.35.58 Join evilwombat [0] (~evilwomba@ppp-71-128-200-85.dsl.sndg02.pacbell.net) 08.36.00 Quit Scromple (Read error: Connection reset by peer) 08.36.02 # Hello 08.36.23 # Has anyone here attempted to replace the HDD inside an Archos Jukebox Recorder with an IDE/CF adapter and a compactflash card? 08.36.52 Quit antil33t (Ping timeout: 240 seconds) 08.40.58 # evilwombat: yes, and with the right card it works. however the hdd is an integral part of the recorder structure, so you'll have to build something to replace it 08.41.43 # Zagor, thanks. I am looking at http://www.newegg.com/Product/Product.aspx?Item=N82E16812186050&nm_mc=OTC-Froogle&cm_mmc=OTC-Froogle-_-Adapters+and+gender+changers-_-Syba-_-12186050 08.41.48 # which seems to be the right form factor 08.42.13 # I've seen the inside of my unit and understand that the mechanics of it may be troublesome 08.42.26 # Do you know of any limitations on the allowed card size? 08.42.27 # http://forums.rockbox.org/index.php?topic=15786.0#msg173442 08.42.38 # not more than 128 GB :-) 08.42.44 # yup, reading that 08.42.58 # 128GB is plenty. Is there a known lower limit, or should I pretty much be good to go? 08.43.29 # any size should work 08.43.46 Quit Zarggg (Quit: Rebooting client...) 08.44.05 # Would you say spending ~$100 on such a project is worth it, or should I just buy a more modern device? 08.44.22 # the latter :-) 08.44.28 Quit funman (Ping timeout: 240 seconds) 08.44.34 # <[Saint]> For "badass" factor, I think its totally worth it... 08.44.42 # I imagine that with the battery capacity of the older devices, and the power requirements of the CF card, I would get rather respectable battery life 08.45.02 # that battery isn't new... 08.45.13 # unfortunately I only have the 10GB model (with a blown charging fet, no less) and am considering picking up a 20GB model for the USB2.0 feature 08.45.16 # desowin: it uses AA batteries 08.45.24 # ah 08.45.26 Join funman [0] (~fun@rockbox/developer/funman) 08.45.51 # <[Saint]> But then, I have a 64GB compact flash iPod Color with a Bluetooth dongle and micro USB access...so, I like modding aging devices. 08.46.02 # so the old devices actually were sane when it came to batteries 08.46.02 # evilwombat: if you really like your recorder, go for it. but a lot has happened in the last 10 years. new devices are smaller, more efficient and support much more file formats 08.46.28 # <[Saint]> I personally think a CF'd Recorder would be awesome, but there's cheaper alternatives, sure. 08.46.48 # Zagor: ...and have worse sound quality (to a varying degree) 08.46.58 # not all of them 08.47.05 # Zagor, I also absolutely love the Rockbox playlist system, so I am restricted to devices supporting RB. What would be your recommendation for a well-supported device? 08.47.54 # <[Saint]> "Pretty much any of the ipods or sansas", IMO 08.48.01 # (preferably something where the key-mapping isn't too insane) 08.48.38 # <[Saint]> IPod photo/Video are cheap, expandable hdd based players. 08.49.20 # <[Saint]> Sansa Fuse is a nice, available, flash based player with a microsd slot and colour screen. 08.49.27 # <[Saint]> *Fuze 08.50.53 # <[Saint]> The major decision is flash or hdd, then go from there. 08.51.07 Quit funman (Read error: Operation timed out) 08.51.29 # the sansa buttons are probably more to your liking than the ipods 08.53.07 # * amiconn doesn't know a single swcodec target with better sound quality than the old archoses, and the few ones which come close (undistinguishable for most cases) are also pretty old 08.54.17 Join funman [0] (~fun@rockbox/developer/funman) 08.55.03 # they can play FLAC at least, not that lossy mp3 08.55.53 # That doesn't make a crappy dac sound better... and the archoses can play wav (not comfortably atm though) 08.57.47 # <[Saint]> SQ of the older ipods is very nice IMO, Color/Photo,Mini,Nano1G 08.58.39 # I can imagine the DAC is a bit better in those, you can make them bigger in such bricks after all :) 09.00.25 # <[Saint]> Nano1g is hardly a "brick" lol :) 09.00.43 # <[Saint]> Color/Photo...well, yeah. 09.01.08 # [Saint]: I was talking about the recorder 09.13.04 # the recorder actually has an integrated dac in the mp3 decoder chip 09.15.22 # The Ondio is smaller (and lighter?) than all the 1.8" hdd based ipods. So much for "hwcodec == brick" 09.15.54 # who said "hwcodec == brick" ? 09.15.59 # recorder == brick 09.16.30 # or, more accurately, "2.5" hdd players == brick" :-) 09.16.38 # the main difference in quality between players is just if they have HD noise or not IMO 09.16.47 # the rest usually doesn't matter unless they're really bad 09.16.48 # * Zagor wants a 5.25" hdd player 09.17.26 # full-height 09.18.32 # Zagor: That was in regard to [Saint] talking about the available space for the dac 09.19.26 # that was kugel, and he was talking about the recorder 09.19.39 # er 09.19.43 Quit barul (Remote host closed the connection) 09.20.24 # Zagor: (re 5.25") Can't you make one from this neo thing? ;) 09.20.49 # good idea. it's certainly big enough. I'll strap it to a car battery. 09.21.30 # now I just need trousers with really big pockets 09.21.42 # <[7]> funman: I've seen weird behavior with iPod Classic USB on windows, while it seems to work perfectly fine on linux... trying to look into that tomorrow 09.22.13 # <[7]> also, he could have just launched "Rockbox fallback image" from the emCORE menu and updated rockbox from there - no need to reformat 09.22.32 # <[7]> (this is a flashed, known-good rockbox version) 09.23.17 # <[7]> and if everything else fails, there are some more complex tools... you just can't brick a classic :) 09.24.02 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 09.24.59 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 09.25.33 # miniaturization has its drawbacks - them most notable is the restriction on the output caps size. 09.26.40 # It's not just output cap size (and there are headphone amp designs which don't need those) 09.27.32 # D class without caps sounds shit 09.28.20 # I'm not talking d class 09.28.25 # most output stages are still AB class if quality matters 09.28.26 # There are bridge designs 09.28.34 # ah yes, you are right 09.29.19 # Or "virtual ground" for that matter, since headphones have one common pin for l and r 09.29.47 # amiconn: Are you going to express your opinion in HWCODEC ML thread? 09.30.28 # er, yes I will 09.30.29 *** Saving seen data "./dancer.seen" 09.32.26 # sooner or later :) 09.32.41 # meh 09.33.16 # amiconn: the thread is a week old now, it doesnt seem very important to you 09.37.08 Join Thra11 [0] (~thrall@87.112.173.79) 09.39.59 Join petur [0] (~petur@rockbox/developer/petur) 09.45.11 # New commit by 03desowin (r31400): Sansa Connect: Significantly decrease MIN_YIELD_PERIOD in sdmmc driver. 09.45.42 # I can see no point in blocking for 10 seconds waiting for dma transfer completion 09.47.00 # r31400 build result: All green 09.47.01 # desowin: your commit seems to have an unrelated change 09.47.22 # this one reverts an earlier one IIRC 09.48.53 # oh, but hopefully the in-progress interrupt change didn't got there 09.49.15 # some of your other commits also had unrelated changes IIRC 09.49.25 # perhaps double check 09.55.33 # hmm, usage of nops for dalays seems wrong 10.10.53 # desowin: did you look at the unrelated change? 10.11.26 # I'm not sure since you said "hopefully" and didn't revert or so 10.12.55 # yes, I did, there're strange things in that sd driver 10.13.25 # I have to track them down, and having the clock lower doesn't trigger those 10.13.27 # Zagor: can you add 3.10 to flyspray? 10.13.37 # no idea where it comes from though 10.14.09 Join ender` [0] (~ender@foo.eternallybored.org) 10.14.37 # and well, in OF it works... but it might be some other modules clock restrictions I don't know of 10.15.31 # too bad the problem only trigers after long playback 10.27.53 # gevaerts: done 10.28.19 # thanks 10.29.26 # gevaerts: any news on mrobe 500 battery_bench? did it drain the battery? 10.33.04 Quit evilwombat (Ping timeout: 252 seconds) 10.33.36 Join swilde [0] (~wilde@aktaia.intevation.org) 10.33.45 # desowin: it looks better. I haven't been able to look at the results yet 10.36.01 # gevaerts: have you used the patches or just plain svn? 10.36.10 # this was plain svn 10.36.33 # good 10.37.05 # Hi, recently self compiled rockbox builds started to crash on me when I connect USB, using the current prebuild release does not show this misbehavior. I used to use self compiled builds for years without major problems but suddenly this problem exists with every build I do... My DAP is an Sansa e200v2. Any Ideas where to look at? 10.38.24 # according to the data manual the clkout is not used *at all* in dm320 10.38.49 # gevaerts: so if the battery_bench was fine, the bug report is invalid 10.39.16 # desowin: let's wait until I've had a chance to actually look at the log :) 10.39.18 # What I did (didn't): I completely deleted and rebuild my build directory, I did not update the build tools (still the same I'm using since March). 10.39.50 # gevaerts: I've observed same problem and it was due to locking in udelay() which was fixed since then ;-) 10.39.51 # All I really know at this point is that it was still playing when I went to sleep last night, which was a lot longer than my previous attempts 10.40.33 # * gevaerts promises lots of interesting numbers in a few days. Battery bench results aren't fast to get 10.41.37 # nick-p: your r31362 commit is wrong 10.42.18 # gevaerts: how so? 10.42.22 # swilde: the toolchain hasn't been updated in the last year, so that shouldn't be the problem 10.42.47 Quit Keripo (Quit: Leaving.) 10.43.10 # hm 10.43.18 # oh 10.43.34 # gevaerts: kugel removed the old arm toolchain 10.43.42 # nick-p: sorry, I apparently missed the commit before that :\ 10.44.06 # gevaerts: yes, thats what I thought, too -- but question is: what might be the problem? 10.44.26 # gevaerts: you had me worried there 10.45.14 # gevaerts: I'm using Debian Squeeze amd64 as build host, which used to work fine and as the build tools did not I think the host system should not cause such problems, right? 10.45.15 # gevaerts: get a smaller battery then! 10.45.39 # or cheap ebay one ;-) 10.47.18 # swilde: you're definitely not the only one using that. Is your svn checkout unmodified? 10.48.14 # gevaerts: 'svn st' is quiet... 10.48.37 Quit mc2739 (Ping timeout: 240 seconds) 10.49.01 # gevaerts: maybe I should try an completely fresh checkout anyway... 10.50.29 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 11.30.30 *** Saving seen data "./dancer.seen" 11.30.40 Join LinusN [0] (~linus@giant.haxx.se) 11.39.21 Quit [Saint] (Ping timeout: 244 seconds) 11.41.57 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 11.55.13 Join pamaury [0] (~quassel@cez63-2-88-164-98-172.fbx.proxad.net) 11.55.13 Quit pamaury (Changing host) 11.55.13 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 12.01.51 # gevaerts: strange (but pleasant): using a complete fresh svn checkout the problem seems to have gone ... (I still wonder why svn st hadn't shown any differences then) 12.11.50 Join rarog [0] (~chatzilla@p4FF5D0C8.dip.t-dialin.net) 12.11.55 Join n1s [0] (~n1s@rockbox/developer/n1s) 12.13.58 # pamaury: : Either I have found the source of error or I just don't understand, how it works... FS#12468 12.13.58 # http://www.rockbox.org/tracker/task/12468 3Hotswap fails to recognize the card after it was removed in USB mode (bugs, unconfirmed) 12.32.14 Join lorenzo92 [0] (~chatzilla@95.232.110.145) 12.33.03 # kugel: :O more than 12 hrs, still 3,635 volts :) 12.33.16 # kugel: pretty nice 12.33.29 Quit n1s (Read error: Connection timed out) 12.34.03 Join n1s [0] (~n1s@rockbox/developer/n1s) 12.34.51 # kugel: last readouts/time -> 3.670v @ 10:40; 3.660v @ 11:20; 3.650v @ 11.40; 3.635 @ 12:30 12.47.11 Join dfkt [0] (dfkt@unaffiliated/dfkt) 12.49.55 # rarog: I don't understand your comment about MCI_ACMD 12.54.15 Quit nick-p (Quit: Leaving) 12.57.06 # lorenzo92: nice indeed 12.57.26 # lorenzo92: are you here this evening? I want to try to make a rom 12.57.35 # pamaury: ok. sd_wait_for_tran_state sends SSP_SHORT_RESP as 3rd parameter to send_cmd and send_cmd SSP_SHORT_RESP equals to 1. then send_cmd ANDs this 1 to the value of MCI_ACMD which equals to 4, so the result is 0. 0 equals false so the if returns false. 12.57.58 # oops, that's a typo, send_cmd should use the MCI_* 12.58.40 # hm... so I did find the faulty place? :D 12.58.56 # rarog: no, by chance it works because SSP_SHORT_RESP=1=MCI_RESP 12.59.30 # the if in send_cmd returns false only if flags contains MCI_ACMD and the send_cmd was successful 13.00.13 # hm, i get #12050 ... it was useful to read the report, as leaving the radio screen is an ok workaround 13.00.52 # Ah, I read it wrong... 13.01.12 # How embarassing. :D 13.01.25 # anyway, there are a few SSP_ instead of MCI_ 13.01.28 # so thanks 13.01.29 # any way i can provide more info on this? i see nothing new on this in over a month 13.01.31 # Simple logic failure. 13.01.32 # kugel: nope :( I won't be there the whole afternoon and evening... 13.01.46 # I was quite tired :D 13.02.23 # but at least now that you'll fix it, I'll retest the bug if it will disappear. 13.02.30 # the chance is still there. 13.02.37 # lorenzo92: that's unfortunate 13.04.08 # rarog: what is your real name ? 13.08.57 Quit [Saint] (Read error: Connection reset by peer) 13.09.37 # pamaury: Andrej Sinicyn 13.10.50 # New commit by 03pamaury (r31401): sd-imx233: fix a few parameters when calling send_cmd, thanks to Andrej Sinicyn for spotting this 13.11.19 # New commit by 03pamaury (r31402): Add Andrej Sinicyn to credits 13.11.20 # that might explain some bug, I'm not sure since the function was called with SSP_NO_RESP instead of MCI_NO_RESP which is wrong 13.12.20 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 13.12.44 # r31401 build result: All green 13.14.07 # rarog: if you can, please test it, I won't have much time in the next days 13.14.22 # r31402 build result: All green 13.16.11 # sure, I'm compiling now and will test for my bug and perhaps several other which might be because of this. all those fuze+ related music bugs... 13.24.32 Join jlbiasini [0] (~56206037@www.haxx.se) 13.25.01 # rarog: pamaury: it seems I arrive quite on time for the party! :) 13.25.39 # rarog found something suspicious, I've fixed it, we'll see if it fixes the problem 13.26.01 Join lovasoa [0] (~olojkine@78.251.3.63) 13.27.14 # I still have little problem with sd... Sometimes it seems to block or doesn't read anymore. But rarely and nothing consistent - pehraps this will improve it... 13.29.08 # does this need a bootloader recompiling? 13.29.56 # imho no. 13.30.26 # well, it doesn't fix my usb sd card bug, everything other only happens in the main rockbox build I think. 13.30.34 *** Saving seen data "./dancer.seen" 13.30.52 Quit petur (Ping timeout: 240 seconds) 13.32.05 # but it seems to have fixed another bug I didn't submit yet. 13.32.24 # at least with mp3 I had problem with smacking sound on resuming playing after a shutdown. 13.32.38 # this now seems to be gone. 13.34.45 # I have a problem since sd with huge (>9000 files) playlist not resuming correctly on resume... I'm curious to se if it gets solved 13.34.52 # I can't be sure but this commit only fixes potential read/write errors 13.35.41 # on transferring files I had often read write error and the sd suddenly going read only 13.35.48 # if this fixes small ugly and hard to reproduce strange bugs, then life is yet more happy with fuze+ 13.36.19 # yeah good job rarog keep on scratching 13.37.19 # rbutil is ready already I just want to had a liittle improvement to make some test between device and firmware passed to mkimxboot 13.37.50 # so as soon we have bootloader on servers, we can have automatic instalation 13.38.35 # * to had -> to add :) 13.39.24 Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) 13.40.01 Quit factor (Read error: Connection reset by peer) 13.44.01 # <[Saint]> jlbiasini: that sounds like a filesystem error, rather than a rockbox bug. 13.44.56 # gha -- after one successful usb session my problem reappeared -- so the fresh svn seems not to be the fix either... :( 13.45.11 # [Saint]: yeah I wasn'tt sure myself of the sources of that this is why I didn't report it 13.45.46 # <[Saint]> It would be wise to check the filesystem of the sdcard. 13.46.54 # I did it and it solve it but the problem came again just after so I thought that maybe rb was messing with but actually I don't really know... 13.48.32 # and on direct copy with sd card reader from my laptop this doesn't happen. Any way it was also while copying huge quantity (> 20 gb) so I wasn't very surprise of an error... 13.51.05 # jlbiasini: ok, if it SHOULD solve these problems, a new bootloader would be better though. 13.51.45 # and tonight I'll retest my usb problem, if I still have the fail with -1 or if it is on some other corner of the code 13.51.50 Join mortalis [0] (~mortalis@77.108.98.177) 13.51.56 # well the question is to know if the mofication is in the bootloader part or not... pamaury? 13.52.22 Join petur [0] (~petur@rockbox/developer/petur) 13.52.35 # mortalis: ping 13.52.47 # wodz: pong 13.53.09 # wodz: I made nand dump 13.53.30 # cool, what about part number/READ ID response? 13.53.46 # jlbiasini: I think every change inside the folder firmware affects the bootloader code. at least inside our path firmware/targets/arm/imx233 13.54.09 # so anything directly in these folders should more or less effect it. 13.54.23 # other subfolders of course aren't interesting for fuze+ compiling. 13.54.26 # mortalis:^ 13.54.52 Quit n1s (Quit: Ex-Chat) 13.57.43 Join factor [0] (~factor@74.197.205.204) 13.58.29 # and now that I think about it - I should retest with renewed bootloader as well. what if the problem is solved but the older bootloader still sets some strange bits here and there so the fixes wouldn't apply. :D 14.00.22 # wodz: http://www.box.com/s/ikbayoi1sxdrl4s2mcdj, Part number: K9GAG08U0M 14.02.29 # mortalis: thanks - I'll download it when get home 14.06.52 Quit lorenzo92 (Quit: ChatZilla 0.9.87 [Firefox 8.0/20111115183813]) 14.06.53 # we add bug reports to CREDITs now? 14.07.45 # <[Saint]> The file, or the plugin? 14.07.57 # that's the same 14.08.39 # <[Saint]> Not really...no. 14.08.47 # it is.. 14.09.01 # the plugin reads CREDITS 14.09.30 # <[Saint]> For instance "foo isn't in credits", not a bug "credits plugin doesn't cascade credits list", bug. 14.10.03 # * gevaerts claims that [Saint] is confused about what kugel was saying 14.10.14 # probably 14.10.28 # I meant "we add people that reported bugs to CREDITS now?" 14.10.43 # I wasnt very clear 14.10.52 # <[Saint]> Oh...wow, why the... 14.11.22 # <[Saint]> I *suppose* its contribution, but, when did this start? 14.11.50 # I think it should take a substantial patch to be included. otherwise we inflate the list and degrade the real contributors. 14.12.28 # in this case no patch was provided 14.13.24 # <[Saint]> I'd remove it, then. Who added it? 14.13.35 # <[Saint]> I agree with Zagor . 14.13.49 # I disagree with removing 14.13.53 # pamaury an hour ago 14.14.45 # I wouldn't have added him, but removing someone from CREDITS is not really the same thing as reverting a commit that introduces a bug I think 14.14.56 # <[Saint]> gevaerts: then, to be fair, all flyspray account users with a report should be added? 14.15.12 # no 14.15.58 # <[Saint]> If not, I'd say remove it then. I don't see a reason to keep the name. I say that not even knowing who it is. 14.16.40 # I think that at least psychologically removing someone from CREDITS is *not* the inverse operation of adding someone to CREDITS 14.17.07 # <[Saint]> As long as I've known it, credits was for "substantial contribution". 14.17.32 # <[Saint]> Adding one guy for a reason others weren't seems...wrong. 14.17.43 # <[Saint]> A mistake to be rectified. 14.17.48 # <[Saint]> (IMO) 14.18.02 # Sure, by getting him to contribute a patch :) 14.18.17 # <[Saint]> That I can dig :) 14.18.24 # <[Saint]> ...but until then.... 14.19.33 # Suppose this HWCODEC fork happens, should we remove everyone from trunk/CREDITS who only contributed to bits that are now removed? 14.20.38 # <[Saint]> To be blunt, I feel kinda warm and fuzzy about having my few dozen LOC in there. I wouldn't feel so warm and fuzzy if to get the same recognition all I did was point out something broke. 14.20.51 # <[Saint]> And, no, certainly not. 14.24.30 # well, it was me who was added, I wondered why. so i don't mind. :D 14.25.34 # pamaury, jlbiasini: ok, now I can't use the sd anymore temporarily, I always get the panic that it couldn't be initialized with error -6 14.25.50 Quit wodz (Quit: Leaving) 14.27.36 # New commit by 03zagor (r31403): Thank you for the bug hunting help, Andrej Sinicyn. However CREDITS is reserved for people who contribute substantial amounts of code or data. 14.29.21 # r31403 build result: All green 14.29.21 Quit jlbiasini (Quit: CGI:IRC (EOF)) 14.29.53 # :D 14.31.22 # pamaury: ok, so this build reveals some problems with sd initialization, previous version worked wrong but managed to init the card. without updated rb build the sd was initialized by bootloader and could be used by rb until it was removed and reinserted again. 14.32.35 Join nick-p [0] (~nick@82-69-105-120.dsl.in-addr.zen.co.uk) 14.38.34 Join jlbiasinii [0] (~56206037@www.haxx.se) 14.39.15 # pamaury: I cannot test it for now... but if it is so, this is rather funny! 14.39.50 # fix a but a get new probelm! rarog do you also have the same kind of problem? 14.40.09 Join audio-i [0] (~be190fca@www.haxx.se) 14.41.31 # jlbiasinii: what problem do you have? 14.42.21 # nothing i cannot test for now (repartitionnig in progress...) but pamaury seems to have problem with the new build 14.42.25 # should the iPod video overlook bad/outdated touchscreen commands in a theme? 14.43.10 Join jlbiasini [0] (~56206037@www.haxx.se) 14.43.14 Quit jlbiasinii (Client Quit) 14.44.39 # if a theme for the Cowon D2 - also 320x240 - has outdated tocuhscreen commands, should it still work on the iPod video? 14.45.40 # I ask because it seems to me it used to be like that, the iPod video would accept it 14.47.36 Quit jlbiasini (Client Quit) 14.50.09 # jlbiasinii: now I have the problem, that i have two fat tables and dosfsck can't fix it... 14.52.27 # ok, managed to repair it now... >.> 14.53.54 # and I can't reproduce the non-initialization now anymore. 14.54.00 # * rarog sighs 14.56.28 # now I can again. 14.58.49 # now again not anymore... 14.59.19 # looks like a more apparent timing problem. 14.59.48 # I give up for now. I'm off to work. 14.59.53 # bye. :) 14.59.58 Quit rarog (Quit: ChatZilla 0.9.87 [SeaMonkey 2.4.1/20111011102430]) 15.00.02 Join jlbiasini [0] (~56206037@www.haxx.se) 15.00.28 # well the problem is that sd work good but usb with sd is data abord! 15.05.23 Part LinusN 15.07.55 Quit jlbiasini (Quit: CGI:IRC (EOF)) 15.09.58 Join WalkGood [0] (~4@unaffiliated/walkgood) 15.10.02 Quit nick-p (Quit: Leaving) 15.22.10 Quit kadoban_ (Ping timeout: 252 seconds) 15.25.52 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 15.28.36 # rarog and jlbiasini have done more than bug reporting for the fuze+, unfortunately we are still not done with the sd problems 15.29.58 Join markun [0] (~markun@rockbox/developer/markun) 15.30.36 *** Saving seen data "./dancer.seen" 15.35.28 # jlbiasini (for the logs): yes, the modification also impacts the bootloader 15.36.03 # but I don't get any data abort or any usb problem, it still works flawlessly on my fuze+ 15.58.10 # is it possible to skin the list scroll bar, or at least give it another color than the text? i'm not sure i understand the %LB tag, never got it working 15.59.23 # <[Saint]> No, you can only skin a scrollbar with skinned lists, not the "built in" scrollbar iiuc 16.01.23 Join jlbiasini [0] (~metaphys@d86-32-96-55.cust.tele2.at) 16.01.36 # this means, declaring lists in their own viewport, and a graphical scrollbar in the same viewport? 16.01.40 Join rarog [0] (~chatzilla@p5DE93D51.dip.t-dialin.net) 16.03.11 # pamaury: btw, I think the place for sd failure has changed. if I have the init failure, it is because sd_wait_for_trans returns 0 and not -1. and I haven't tested it yet, but I think that in usb mode the reinserting should fail because of the function returning 0. 16.05.14 # <[Saint]> Unless I'm mistaken, you can draw a scrollbar with skinned lists. 16.05.44 # rarog: iirc, sd_wait_for_trans returns 0 on success ! 16.05.52 # <[Saint]> The tag(s) and syntax are unknown to me offhand though. 16.06.21 # [Saint], the documentation on those tags is rather sparse, but i assume a scrollbar uses what passes as "slider" for progress bars? 16.06.39 # afaik, you didn't skin the scroll bar in cabbiev2? 16.06.56 # <[Saint]> No, that's a progressbar, not a scrollbar. 16.07.06 # oh, then let me look into the other line, that seems suspicious then. 16.07.14 # i actually was looking through hundred themes on the site, but none with custom scrollbar 16.07.44 # it's the only thing missing for perfection ;) 16.07.47 # <[Saint]> I may be entirely wrong about it, but I thought skinned lists allowed for arbitrary placement and themeing of scrollbars. 16.08.18 # guess i'll start with an empty sbs, checking out what can be done, thanks [Saint] 16.09.43 # <[Saint]> No worries, I can't be of too much help as I'm in bed on my phone, my netbook has a hiccup :) 16.10.50 Quit mortalis (Ping timeout: 276 seconds) 16.11.36 # tell your netbook to get well soon ;) 16.12.29 Join mortalis [0] (~mortalis@77.108.98.177) 16.12.46 # pamaury: which is probably the reason why sd is still working on my device. Anyway the usb data error only happen once 16.12.59 # pamaury: in sd_init_card you have "if(sd_wait_for_tran_state()) return -6", whicht enforces the panic in sd_thread. 16.13.00 # I'm upgrating bl now 16.13.28 # rarog: this will return -6 only if sd_wait_for_trans_state returns something != 0 16.16.35 # then I have strange timing problems, every time I managed to try, it returned me 0 from sd_wait_for_tran_state. 16.17.34 # though if I remember correctly, I didn't get the returned value and called the function again, which then returned 0. 16.18.27 # why is that a problem ? If it returns 0 it means success, that's a good sign 16.18.36 # this would be another hint to some timing problems. else I don#t know, why sd init should fail several times I try. und 5 minutes later everything works and I can't provoke any error. 16.19.10 # what I meant is, that i checked it's state, by calling it again right before i get th e-6 and panicf is called. 16.19.43 # so I didn't have the nonzero of the call which provoked the -6, but a new one, which indeed goes through. 16.20.17 Quit jlbiasini (Ping timeout: 268 seconds) 16.20.31 Join jlbiasini [0] (~metaphys@d86-32-96-55.cust.tele2.at) 16.21.21 # pamaury: rarog: on my device the new update (bl and rb) doesn't bring any obvious change.... My problem with huge playlist seems to be gone but on usb it doesn't reconnect if the sd is taken away once (like it was) on playing, taking the card away and back in does mount it back. Is it also what you have? 16.21.49 # but it didn't panic because of -1 either, which I put into place in sd_wait_for_trans. so it wasn't -1 or 0, which was returned to provoke the -6, but something outher in the line "return -10 * ((response >> 9) & 0xf);" which I didn't manage to catch yet. 16.22.13 # yes, the non-mounting-back was the other bug I opened. 16.22.21 # it was also in the previous builds. 16.22.27 # before the fix with signals. 16.22.59 # I'm hunting this error since several days. and hopefully it's almost tracked down. 16.23.09 # ok 16.23.21 # so this what I understood 16.23.41 Join y4n [0] (y4n@unaffiliated/y4ndexx) 16.25.23 # this bug is yet there, but now not because of the parts which are fixed, but because of some other failure which ist to be identified soon. 16.28.15 # anyway I thinks that this FS#12457 should be closed isn't it? 16.28.15 # http://www.rockbox.org/tracker/task/12457 3[Fuze+] CRT-like effect on the second type of screen (bugs, new) 16.37.27 # hm... isn't this something alienkid reported in the forums? though I couldn't reproduce it so far. 16.46.35 Quit audio-i (Quit: CGI:IRC) 16.47.41 # for what I know it is solved since bootloader-v2 pamaury? 16.47.42 # "it (soft?) rebooted and I had no lines. I let backlight fade out then made it come in and still nothing" from December 7th 16.47.53 # it should be solved, I think. 16.48.06 # that's old, the fix is much more recent 16.48.11 # but he reported that the lines were cone but back after backlight went on. 16.48.26 # ok, then I think the bug can be closed. 16.48.53 # pamaury: any plan on implementing gpmi for any of the devices you're working on ? 16.49.04 # TheLemonMan: yes, creative zen x-fi2 16.49.05 # I can't do it, no right on that :/ 16.49.41 # i need to check hows the wiring on different player 16.50.04 # as there are some incongruencies in this code samsung sent me 16.50.38 # and the gpmi stays busy in DMAACK state 16.50.48 # I've not yet try or reverse engineer any nand related code, but I'll try and let you know 16.51.41 # should be just a matter of gpio pins 16.52.52 # yes, the tricky part seems to have all the gpmi and ecc blocks interact 16.54.41 # with chained dmas its not that hard 16.55.21 # can the dma wait for the ecc to finish ? I've not had a close look 16.56.24 # it should, otherwise you need to use some irq magic 16.59.22 Part Zagor 17.04.54 Quit jhMikeS (Ping timeout: 240 seconds) 17.09.11 Quit lovasoa (Ping timeout: 252 seconds) 17.11.36 # jlbiasini: did you ever had smacking sound when resuming a playlist after a reboot before today? like semi-broken decoding, if you know how that sounds. 17.13.40 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 17.30.37 *** Saving seen data "./dancer.seen" 17.38.32 Join domonoky [0] (~Domonoky@rockbox/developer/domonoky) 17.44.13 Quit factor (Read error: Operation timed out) 17.56.28 Quit rarog (Quit: ChatZilla 0.9.87 [SeaMonkey 2.5/20111121045514]) 17.59.16 # rarog: no never on what file format? isn't it related to file? 18.00.14 Join factor [0] (~factor@74.197.205.204) 18.06.52 Quit petur (Quit: *plop*) 18.09.31 Join kadoban_ [0] (~kadoban@ip98-165-177-158.ph.ph.cox.net) 18.15.02 # changing the clock divider made the pin state change to stall and a fifo empty error to pop out 18.17.15 Quit jlbiasini (Ping timeout: 240 seconds) 18.34.58 Quit mortalis (Quit: KVIrc 4.1.1 Equilibrium http://www.kvirc.net/) 18.35.18 Join cet30048 [0] (cet30048@c-71-206-235-41.hsd1.pa.comcast.net) 18.35.22 Part cet30048 18.46.06 # desowin: I now have a battery bench for r31378 18.46.20 # Any special requests on what to run next? 18.47.21 # * gevaerts assumes something pre-r31357 18.50.14 # you assume correctly 18.50.26 # but before you run that, I'll have small patch to test 18.52.12 # gevaerts: http://desowin.org/rockbox/dsp_clkoff.patch 18.52.21 # against current svn? 18.52.30 # just test if it still plays (really it should, but who knows) 18.52.32 # yes 18.53.07 # don't do battery bench as I suspect just a marginal increase 18.53.13 # ok, building now 18.55.11 Quit swilde (Remote host closed the connection) 18.58.10 # desowin: that seems to still play 19.00.32 # okay, so this clock signal really isn't used anywhere 19.01.24 Join jlbiasini [0] (~metaphys@d86-32-96-55.cust.tele2.at) 19.02.05 # I'll start a battery bench for r31356 now. That will (finally!) tell us what r31358 did 19.03.13 # oh, damn. That's before my battery_bench fix :\ 19.03.24 # pamaury: would it be possible to have the rb bootloader writing some file on the fuze+ storage in order to have a way to detect its version? (only if it's easy to implement) 19.03.46 # New commit by 03desowin (r31404): TMS320DM320: Disable CLOCKOUT signal to save some power. 19.04.30 # we're less than 52 minutes worse on runtime than Connect's OF 19.04.51 # not bad 19.04.57 # was three hour difference at beginning 19.05.05 # for such an early state anyway 19.05.28 # some targets only reach half of the OF runtime after maturing .) 19.05.55 # r31404 build result: All green 19.11.19 # jlbiasini: there already is such a file 19.11.24 Join lebellium [0] (~chatzilla@91-65-137-216-dynip.superkabel.de) 19.11.42 # I wonder what clocking DSP at lower rate would do 19.12.01 # currently it is clocked at maximum 19.13.50 # pamaury: euh? which one? 19.14.08 # rockbox-info.txt 19.14.40 # iirc 19.15.22 # yes but this give the version of rockbox not of the bootloader... 19.16.26 # ah, sorry, I misread 19.16.29 # doesn't the bootloader version show up on start? other targets do that 19.16.37 # only for a split second, though 19.17.41 # yes but i would like to implement the detect bootloader method in rockbox utility so I need a file... 19.19.31 Join perrikwp_ [0] (~quassel@cpe-024-163-024-033.triad.res.rr.com) 19.20.09 # the simplest way would be that rockbox utility put a file with this information at the same time as firmware.sb 19.21.08 # pamaury: except if we asume that we wait till the bootloader is really ready before to put it on the server.... If we do so then there no need to implement such a think but it would means that we are going to wait for a while! 19.21.37 # before to have rbutil with fuze+ 19.22.23 Quit perrikwp (Ping timeout: 255 seconds) 19.22.28 # does anybody know what it take to have abootloader on a rb server and if it is a pain to update a new one regulary? 19.22.56 # * kugel booted his first self-hacked OF on the ypr0 19.23.26 # kugel: congrat \o/ 19.23.59 # kugel: congrats :p 19.24.14 # as beautiful as modded fw 2.30? :D 19.24.39 # of course not :) 19.24.50 # pamaury: anyway you are right the best way would be to have it from rbutil installing the file... except that rbutil has no way to know where the file is coming from... 19.25.29 # kugel : what modifications did you do? 19.25.46 # echo "Hello World" > /mnt/media0/hello.txt 19.25.47 # :P 19.25.59 # ^^ 19.26.14 # also start /mnt/media0/r0 if exists 19.28.13 Quit WalkGood (Quit: asta) 19.28.22 # pamaury: or could we have the bootloader make adding some kind of header to the bootloader-fuzeplus.sansa? 19.28.31 # ffs, this mtp is super annoying 19.28.58 # mtp? 19.29.04 # jlbiasini: I prefer not to, and even then it would not change anything 19.29.22 # lebellium: the OF defaults to mtp, after flashing 19.29.39 # pamaury: ... which drive me to the conclusion that there is no simple way to handle that and that it's better to drop this 19.30.00 # yes, that's not worth the trouble I would say 19.30.12 # kugel; ah... yes of course! But thanks to me newer models are UMS by default now hehe 19.30.40 *** Saving seen data "./dancer.seen" 19.30.53 # lebellium: do you work at samsung or something? 19.31.36 # kugel : no, I work for an online advertising company in Berlin :p I'm a Samsung insider since 2005 19.32.00 # I guess you can't be more specific than "insider"? :) 19.32.07 # " it would not change anything" once patched yes, but before patching rbutil could have it... well it would have add some mess with future other player necessity to follow also... forget it! :D 19.32.17 Quit Thra11 (Ping timeout: 255 seconds) 19.32.25 # lebellium: btw, if that meetup in berlin happens I might attend 19.33.11 # kugel: I have good contacts at Samsung France and Korea and if firmwares are released on any model, that's only thanks to me, no other guy seems to report bugs to the R&D ll 19.33.16 # it looks like you can't boot from media0, perhaps mooted noexec? 19.33.59 Join Horscht [0] (~Horscht@p57B5708A.dip.t-dialin.net) 19.33.59 Quit Horscht (Changing host) 19.33.59 Join Horscht [0] (~Horscht@xbmc/user/horscht) 19.34.04 # media0 is microSd right? 19.34.27 Quit fs-bluebot (Ping timeout: 240 seconds) 19.35.43 Quit bluebrother^ (Ping timeout: 244 seconds) 19.36.03 Join fs-bluebot [0] (~fs-bluebo@f053152020.adsl.alicedsl.de) 19.37.22 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 19.37.27 # lebellium: nope, internal mem 19.38.07 # so I don't understand what you mean since RB currently boots from media0 no? 19.38.27 # hm right 19.38.34 # then I don't know why it didnt start 19.39.03 # wait, perhaps it did 19.41.16 Join fml [0] (~chatzilla@manz-590f35ff.pool.mediaWays.net) 19.42.07 # * fml prepares to commit FS#12470 and FS#12473 (now I have time and won't have it in the next few days) 19.42.08 # http://www.rockbox.org/tracker/task/12470 3Rename "mp3entry.embed_albumart" to "mp3entry.has_embedded_albumart" (patches, new) 19.42.09 # http://www.rockbox.org/tracker/task/12473 3Rename "mp3entry.embed_cuesheet" to "mp3entry.embedded_cuesheet" and pull out a field (patches, new) 19.43.20 # So objecters: speak now or it will be too late :-) 19.44.22 Join Thra11 [0] (~thrall@87.115.6.19) 19.46.17 Join joshin [0] (~josh@unaffiliated/joshin) 19.47.32 Quit markun (Remote host closed the connection) 19.47.57 # lebellium: okay, apprently it did start r0 from media0 19.48.03 # because USB doesn't work anymore :) 19.48.45 # New commit by 03alle (r31405): Rename 'mp3entry.embed_albumart' to 'mp3entry.has_embedded_albumart' (FS#12470). No functional changes. 19.49.01 # kugel: okay cool :) I hope USB still works with the OF or in Safe mode? 19.49.26 # this rom has no safe mode, and USB in the OF doesnt work anymore 19.50.18 # luckily I can delete files using the OF 19.50.30 # hum 19.50.39 # you should not take so many risks :p 19.51.24 # if you brick it, you can always search for JTAG ;-) 19.51.33 # r31405 build result: All green 19.51.53 # Unbricking methods are hard to find without proper motivation :) 19.53.19 # if you brick it, I can save you of course, but the best is to avoid that solution ;) 19.53.25 # situation* 19.56.12 # New commit by 03alle (r31406): Rename 'mp3entry.embed_cuesheet' to 'mp3entry.embedded_cuesheet' and pull out a field (FS#12473) 19.59.06 # r31406 build result: All green 20.02.04 # Is the negative bin size impact because of struct fields alignment? 20.07.44 Quit fml (Quit: ChatZilla 0.9.87 [Firefox 3.6.24/20111107173218]) 20.19.20 Join Buschel [0] (~chatzilla@p54A3A046.dip.t-dialin.net) 20.23.39 Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 20.23.39 Quit bertrik (Changing host) 20.23.39 Join bertrik [0] (~bertrik@rockbox/developer/bertrik) 20.29.55 Join stoffel [0] (~quassel@pD9E412E7.dip.t-dialin.net) 20.32.05 # JdGordon: did you see http://forums.rockbox.org/index.php/topic,29622.msg187418/topicseen.html#msg187418 ? 20.39.17 Quit y4n (Quit: HOLY SHIT! WE'RE ALL JUST LIVING ON A GINORMOUS FUCKING SPINNING ROCK FLOATING THROUGH SPACE CIRCLING A BIG FUCKING BALL OF FIRE!!!) 20.43.52 # gevaerts: i wonder if hid transfers are handled differently by the amsv2 hw 20.44.46 # i read that the host polls the device for transfers, does it do so by transferring some data to us to which the hid driver answers? 20.45.56 # not really 20.46.24 # The hid driver prepares some data and passes it on to the controller, and at the next poll the controller will send it to the host 20.46.39 # the linux driver sets up the interrupt IN endpoints for periodic tranfser (with pio IIUC) 20.47.08 # gevaerts: using non blocking transfer? 20.47.08 # * gevaerts nods 20.47.20 # I was wondering if 2 transfers could step on each other 20.47.34 # If they do, the hid driver is buggy 20.47.37 # e.g. transferring some data while the previous packets have not been sent 20.48.00 # It should wait for the previous data to be sent before doing new stuff 20.48.06 # ok 20.48.26 # No promises though :) 20.48.31 # i posted some dmesg yesterday (early morning for you) 20.48.41 # apparently hid device detection fails with -22 = EINVAL 21.16.55 Join Stummi [0] (~Stummi@rockbox/developer/Stummi) 21.17.09 Join Stummi|afk [0] (~Stummi@77-64-128-168.dynamic.primacom.net) 21.17.10 Quit Stummi (Read error: Connection reset by peer) 21.17.31 Quit Stummi|afk (Read error: Connection reset by peer) 21.19.27 Join Stummi [0] (~Stummi@rockbox/developer/Stummi) 21.27.55 # kugel: do u think it's possible to get the R0 into the SVN in the following days? 21.30.43 *** Saving seen data "./dancer.seen" 21.37.45 Quit Buschel (Quit: ChatZilla 0.9.87 [Firefox 8.0/20111104165243]) 21.42.13 # funman, My bug report grew a bit. 21.42.28 # what is FS# again? 21.42.48 # !bug 12475 21.42.51 # :( 21.42.55 # FS#12475 21.42.56 # http://www.rockbox.org/tracker/task/12475 3Crash while playing audio (bugs, unconfirmed) 21.44.57 # pamaury: got the nand id :D gpmi is working 21.45.01 # bug2000: no reliable way to reproduce it yet? 21.45.14 # funman, Just play mp3. 21.45.17 # TheLemonMan: what was the problem ? 21.45.34 # funman, I've reprocuded it that way so many times on the bus. 21.46.15 # i was shifting the data lenght over the ctrl0 config in the dma pio words 21.47.40 # bug2000: let me dig out my clipv1 and see if i can reproduce 21.49.06 # funman, You can guess how annoying it can get when trying to hear a podcast and it dies on you every five minutes XD 21.52.59 # lebellium: ping 21.55.16 # lebellium: yea 21.56.28 # bluebrother: the initial installation for the ypr0 can likely only be done on linux/unix. can rbutil cope with that? 21.56.43 # bug2000: started playback 21.58.14 # kugel: how does that look like? 21.58.18 # pamaury: mkimxboot is already checking that the rb bootloader and of firmware are for the same device so I think that there is no need for a further check 21.58.32 # and no, Rockbox Utility can't cope with Linux installation on Windows :) 21.58.48 # we can make it require some preinstallation 21.59.10 # like you would need for e200r (though no work has been made for that) or the beast (still disabled) 21.59.18 # bluebrother: do you have any idea how bootloader get on the rb server? 21.59.25 # TheLemonMan : yes? 21.59.34 # jlbiasini: the only necessary check would be that the firmware correspond to the device (you can't put a fuze+ firmware on a xxx device where xxx!=fuze+) 21.59.46 # but I guess the OF already does that check more or less 21.59.52 # bluebrother: shell scripts and precompiled binaries :'( 21.59.53 # jlbiasini: have someone build them, then upload them somewhere and ping the server admins (i.e. Bagder or Zagor) 22.00.06 # kugel: urgh. And no sources I presume? 22.00.11 # do you happen to have written somewhere the nand model of the q2 ? 22.00.21 # bluebrother: you are right 22.00.42 # you can't read it on my pics? 22.00.45 # also the binary should be simple to reverse engineer for someone more skilled with x86 asm than me 22.00.55 # that's really ugly. 22.01.19 # does that affect bootloader installation only? 22.01.26 # yes 22.01.28 # bluebrother: would it be possible to generate a .o with Visual Studio for beast patcher? instead of a dll 22.01.54 # TheLemonMan: cowon? 22.02.11 # ok, in that case we can simply disable bootloader installation in Rockbox Utility and require the user to do that by other means 22.02.24 # funman: not sure. Maybe a lib file. 22.02.37 # pamaury: yes this is the return 4 from mkimxboot. The user can fool rbutil giving a wrong file but rbutil will get the bootloader of the right device. mkimxboot will then refuse to patch then. So I guess this is safe enough 22.02.55 # funman: samsung yp-q2 22.02.59 # I haven't looked into that back when I was doing stuff on beastpatcher, and haven't done that recently when looking into building dlls for VS. 22.03.22 # mixing compilers is usually a tricky thing 22.03.37 # jlbiasini: right, that only works if rbutil has a reliable of determining the device 22.03.56 # but creating a .lib (which, afaiu is pretty much the same as an .a) should be possible 22.04.35 # .a is basically a bunch of .o zipped together, isnt it? 22.04.40 # yes. 22.04.55 # * bluebrother should give reworking the autodetection code a go 22.05.09 # though I'm more interested in .tar.xz support in Rockbox Utility right now :) 22.06.36 # actually fuze+ get autodetected through usb 22.07.30 # yeah, the usb vid:pid is reliable 22.08.30 # the only problem is that we don't have a way to resolve vid/pid -> mountpoint 22.09.33 # hm, how is this done currently ? 22.09.37 # does rockbox not support real 24bit colors on raaa? a screenshot of a gradient - original on bottom, rockbox sim (same as on real android) above: http://i.imgur.com/5uLZk.png 22.10.08 # pamaury: so the only way the user could pass through if he doesn't use autodetection would be to give of of the wrong device and bootloader of the same wrong device. In such a case I assume the player will not recognize the patched file as valid, isn't it? 22.10.26 # depends on the OF checks 22.10.42 # I know the fuze+ OF is really picky so it will reject any invalid firmware 22.11.30 # ok so if you think it's necessary i can add it to mkimxboot. It was just to be sure 22.11.40 Quit [Saint] (Remote host closed the connection) 22.11.56 # no that's ok, even they the device is recoverable, so even stupid users are safe :D 22.12.01 # *then 22.12.30 # bluebrother: on linux the mount point get also correctly detected 22.13.07 # pamaury: it would be rather being perverse as idiot! :D 22.15.29 Quit Stummi (Quit: Bye!) 22.17.49 # bluebrother: pamaury: anyway I think that to have rbutil fully handling the installation (i. e. quick start menu availlable) fuze+ has to be pushed up to unstable. Rbutiil is checking a lot of stuff on the server to determine the status of every device. So everything works, the bootloader install is avallaible but still no quick start (full) installation 22.18.34 # I think we can safely promote the fuze+ to unstable 22.19.35 Quit stoffel (Read error: Operation timed out) 22.19.36 # \o/ I will then prepare all the file that has to be uploaded or patched. and ring some admin 22.20.01 Quit kadoban_ (Ping timeout: 244 seconds) 22.20.08 Quit joshin (Read error: Operation timed out) 22.20.53 # what has to be done to move a target to unstable ? 22.22.29 # I could be missing things, but IIRC release a bootloader, adjust tools/builds.pm, and update the home page and possibly bits of wiki 22.22.33 # jlbiasini: the main problem with autodetection is that there are cases we simply cannot detect reliably. If we have a specific file that is always on the player we're good. If we can find some magic things on the drive (like firmware partition on ipods) we're good as well. But some cases are simply not possible, and the current code has some problems as well 22.23.08 # in either case, we have to live with the fact that autodetection isn't perfect. A user should _always_ know where his device shows up. If not he shouldn't install :) 22.27.23 # New commit by 03bluebrother (r31407): Rockbox Utility: add description and helper code for VS. ... 22.29.19 # bluebrother: a solution could be to ask the user to unplug the device before starting rbutil and to plug it in while some autodetection is running. watching the usb would allow to target the device?? 22.29.59 # r31407 build result: All green 22.30.05 # i.e not even pid but new entrie 22.30.15 Join joshin [0] (~josh@ip72-201-88-235.ph.ph.cox.net) 22.30.15 Quit joshin (Changing host) 22.30.15 Join joshin [0] (~josh@unaffiliated/joshin) 22.31.23 # jlbiasini: the vid/pid detection works fine, that's not the problem. There are only a few players that don't have unique vid/pid pairs, and those are older ones 22.32.18 # see http://www.rockbox.org/wiki/DeviceDetection -- on the Archos devices we can check the (already present) firmware file, and on Ipods we use ipodpatcher 22.33.13 # hmm, why is the Fuze+ recovery mode marked as duplicate? 22.33.56 # the main problem is reliably figuring the correct mountpoint. But if the user uses a wrong mountpoint we place the files on the wrong disk, which is not really much of a problem anywa. 22.34.24 # at least it doesn't cause any harm. Except for ipodpatcher / sansapatcher, and those have checks against this 22.34.53 # bluebrother: because it's not specific to the fuze+ 22.35.07 # it's the same for all imx233 devices 22.35.10 # pamaury: ah, ok. It's unique in that list though :) 22.35.29 # right but since I plan to port other devices, it will hopefully have duplicates 22.35.33 # :) 22.35.52 # hopefully? :o 22.36.26 # but since it's recovery mode it's not much of a problem -- Rockbox Utility isn't designed to recover players :) 22.39.03 # http://www.rockbox.org/tracker/task/12402 22.39.35 # could someone check my patch? feel free to tell me if I should improve something... 22.40.29 Join dreamlayers [0] (~dreamlaye@rockbox/developer/dreamlayers) 22.40.44 # I know already that I forget something: add usb error to rbutil.ini which is the usb pid of the fuze+ when in mtp mode 22.41.18 # jlbiasini: nice. I'll try to get around checking it 22.41.38 # thx 22.41.38 # the wiki URL is wrong: the wiki pages don't end in .html :) 22.42.03 # I'm a bit busy right now though 22.42.12 # funman, Any luck? 22.42.49 # no hurry anyway as long as the files are not on the server...;-) 22.43.23 # arf yes I have to change that 22.48.11 # bug2000: how long do you have to play MP3 before encountering FS#12475? 22.48.12 # http://www.rockbox.org/tracker/task/12475 3Crash while playing audio (bugs, unconfirmed) 22.48.25 # dreamlayers, From 5 minutes to 20 minutes. 22.48.39 # dreamlayers, Depends on how un/lucky I am. 22.49.02 # Does it seem to happen at a track change or just randomly? 22.50.37 # is it normal that only the backdrop image looks like proper 24 bit, while additional images get ugly 16bit dithering? 22.51.04 # lebellium: trying a firmware with safe mode and rockbox support 22.51.22 # kugel: cool :) 22.51.23 # though, I changed the way the rockbox support works 22.52.07 # dreamlayers, Randomally. Try listen to podcast when it crash like that and lose your position as well. 22.52.16 # listenning* 22.52.41 # * bug2000 is trying to play with a different theme. 22.52.54 # lebellium: in the fw I made it tries to load rockbox.sh (from .rockbox so it can be in the rockbox.zip), and a rc.user after that 22.53.24 # rockbox.sh sets the environment up to start rockbox. through rc.user it can be costimized even more 22.55.12 # by loading I mean sourcing. that means rc.user can even change the binary to be loaded 22.58.49 Join _dreamlayers [0] (~dreamlaye@bas4-windsor12-1279287444.dsl.bell.ca) 22.59.41 Quit dreamlayers (Read error: Operation timed out) 23.01.10 Nick _dreamlayers is now known as dreamlayers (~dreamlaye@bas4-windsor12-1279287444.dsl.bell.ca) 23.01.22 Quit dreamlayers (Changing host) 23.01.22 Join dreamlayers [0] (~dreamlaye@rockbox/developer/dreamlayers) 23.01.46 # kugel; sounds good but you know, I don't really understand those technical things, only lorenzo does^^ 23.02.57 Part jlbiasini 23.08.28 # dfkt, I think it might be your theme. Pacman theme didn't crash yet and I need to go to sleep. 23.09.21 # That would be useful to confirm, but the bug still isn't in the theme. Themes shouldn't be able to crash rockbox 23.11.39 Quit bluefoxx (Ping timeout: 240 seconds) 23.13.14 # bug2000: my clipv1 stil running ok 23.13.18 # i have no issues with the theme? 23.13.45 # r31403, but i m not sure which theme im using 23.16.50 Join keyb_gr_ [0] (~chatzilla@p4FF0587A.dip.t-dialin.net) 23.16.57 Quit keyb_gr (Ping timeout: 252 seconds) 23.16.58 Nick keyb_gr_ is now known as keyb_gr (~chatzilla@p4FF0587A.dip.t-dialin.net) 23.20.32 Quit benedikt93 (Quit: Bye ;)) 23.23.59 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 23.24.31 Join Scromple [0] (~Simon@119.225.209.134) 23.27.39 Join [Saint_] [0] (~Saint]@unaffiliated/saint/x-8516940) 23.30.46 *** Saving seen data "./dancer.seen" 23.30.47 Quit [Saint] (Ping timeout: 255 seconds) 23.33.30 Quit liar (Ping timeout: 252 seconds) 23.38.24 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 23.39.54 Quit dreamlayers (Quit: bye) 23.48.51 # kugel: I go to bed now, I have my plane to Paris early tomorrow. Hope to see the R0 in the SVN very soon and if I don't come back to the IRC by then, I wish you and the whole RB team a merry xmas :) 23.49.22 Join [Saint] [0] (~Saint]@unaffiliated/saint/x-8516940) 23.51.51 # lebellium: thanks! :) Signs look good for R0 to svn 23.52.23 Quit [Saint_] (Ping timeout: 255 seconds) 23.53.13 Quit domonoky (Read error: Connection reset by peer) 23.56.24 # * kugel wonders if there's more YP-R0 like targets, where RaaA can be ported to with moderate effort 23.57.03 # the nice thing about this port is that you can hardly tell the difference to a native port 23.57.24 # speed? memory usage? 23.57.48 # there's no apparent speed difference 23.57.50 Quit lebellium (Quit: ChatZilla 0.9.87 [Firefox 9.0/20111212185108]) 23.58.35 Join T44 [0] (~Topy44@f048197124.adsl.alicedsl.de)