--- Log for 11.06.114 Server: leguin.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 29 days and 19 hours ago 00.00.13 # Actually 00.00.16 # Well 00.00.19 # Yes then :) 00.00.44 Quit Provel (Ping timeout: 276 seconds) 00.00.57 # could also have been an attempt to redo it after bus resets, with quirky drivers that clear their internal endpoint drivers AFTER calling usb_core_bus_reset 00.01.50 # I don't remember if usb_core_init() is called before or after we know we're going to be doing charging or msc 00.01.56 # what we're currently doing, while probably harmless, might not be fully spec compliant 00.02.08 # we're basically enabling EP >0 before we have an address or configuration 00.02.12 # Well 00.02.23 # Does the spec actually care about that? 00.02.37 # not sure if it's a SHALL or SHOULD ;) 00.02.39 # But yes, I have this very vague memory about bus resets being involved here 00.02.54 # a spec-compliant host SHALL probably not rely on it though ;) 00.03.14 # I can promise you that the bit about the host doing things where this makes a difference is a MUST NOT :) 00.03.38 # I'm currently running into problems which look like there's an unexpected STALL condition on EP1, right on the first bulk request 00.03.52 # which I partially blame on the confusing semantics of usb_drv_request_endpoint ;) 00.06.32 # What's the confusion? 00.06.43 # Sure, there is a slight lack of documentation... :) 00.06.57 # well, I wrote the driver assuming that this actually enables the hardware EP 00.07.04 # and it somehow doesn't work, although I don't see why 00.07.22 # could be that the hardware is doing some funny things when setting an address 00.08.28 # I know it doesn't set anything up on ARC 00.08.29 # * TheSeven takes a look how the old driver handles this 00.08.46 # Well 00.08.48 # I think :) 00.09.07 # Ah, yes 00.09.16 # on usb-s3c6400x it seems to activate the endpoint 00.09.41 # The ARC driver (which is the only one I know!) actually sets up the hardware endpoints from set_address() 00.11.09 # ...which is called AFTER finishing sending the ACK for that request 00.11.18 # The reason usb_drv_request_endpoint() is in the hardware driver and not in usb_core is really only that different hardware has different rules about which endpoints can do what 00.11.50 # Is that a problem? We haven't had a SET_CONFIGURATION yet 00.12.12 # it's just something to remember when looking at the code ;) 00.12.37 # well, is there another way for the driver to know how to actually configure the EPs besides tracking the usb_drv_request_endpoint calls? 00.12.50 # No 00.13.31 # That could be redone to have the core remember it all, but refactoring USB is no fun 00.13.42 # You'll *never* get testers for all hardware 00.13.59 # hm, on the old one, cancel_all_transfers actually takes down the endpoints. i.e. if that would be called after set_address, it would probably kill it 00.14.35 # That's called for USB_REQ_SET_CONFIGURATION 00.14.53 # And SET_ADDRESS 00.15.06 # DEPCTL(ep, dir) = (DEPCTL(ep, dir) & ~DEPCTL_usbactep); 00.15.13 # for ever endpoint besides 0 00.15.47 # usbactep is set in usb_drv_request_endpoint 00.16.04 # and in reset_endpoints 00.16.55 # which in turn is done in usb_drv_init and usb_reset, and in the bus reset handler 00.17.19 # I see neither of those happening after set_configuration 00.17.56 *** Saving seen data "./dancer.seen" 00.18.45 # It's in request_handler_device() 00.19.36 # what exactly is there? 00.19.54 # usb_drv_cancel_all_transfers() 00.19.58 # yes 00.20.17 # I'm wondering what recovers the damage done by that in the old driver 00.24.45 Join audiomodder [0] (ac0215fb@gateway/web/freenode/ip.172.2.21.251) 00.24.50 # #rockbox 00.25.14 # hello, anyone in here? 00.25.48 --> "yo" received from Schizoid (~schizoid@unaffiliated/surtri) 00.25.59 # yes, 103 people, some of which might actually be awake :) 00.26.04 # if you have a question, just ask it 00.27.07 # great. Im a first-timer here (IRC n00b as well) but long term hardware hacker. I have some Sansa Clip+s that are bricked that I am trying to fix 00.27.18 # using the instructions from here: http://www.rockbox.org/wiki/SansaAMSUnbrick 00.27.27 # how are they behaving? 00.28.55 # blank screens, flash seems corrupt / wont format 00.29.10 # do they connect as a usb storage device? 00.29.14 # if so, what capacity? 00.29.26 # 4GB but they wont format 00.31.22 # i tried using a partitioning program 00.31.44 # and got one to partition a 100MB primary FAT16 00.32.05 # was it actually able to write that to the player? 00.32.06 # (this is a different one that actually has a working display) 00.32.19 # after many attempts, yes 00.32.32 # after shorting those pins? 00.32.39 # the player turned on after that, and then kept saying it needed 90MB for the database 00.32.49 # so i gave up, shorted those pins for NAND 00.33.02 # and it saw the full 4GB after that, doing a long format for FAT32 now... 00.33.05 # if it came up AT ALL, this is the wrong way to go 00.33.18 # ah OK 00.33.21 # and with that format you have probably actually bricked it 00.33.21 # good to know 00.33.34 # really? even thought its the 4GB? 00.33.58 # this is why the wiki page says to confirm things here *before* trying out anything 00.34.05 # cause I figured I wasnt actually in NAND, since it didnt say "979.75MB" 00.34.12 # yeah, i know.... 00.34.14 # anyway, I'm having trouble following your steps 00.34.23 # yeah let me start over. 00.34.33 # I have 3 bricked players 00.34.36 # you seem to be talking about multiple players, please number them and describe the state of each one, so we don't confuse things 00.34.44 # yeah, sorry about that 00.35.12 # * TheSeven pings bertrik, funman, and whoever else has experiences with AMS bricks 00.35.25 # These are all Clip+ btw 00.35.43 # player 1 had the working LCD but said "FAT corrupted please plug into a computer and format" 00.36.08 # ok, that one definitely doesn't need any shorting of pins then 00.36.44 # Im using Win 7 and I tried formatting it many times, and using "EaseUS Partition Master" 00.37.13 # It seems to me like the SSD memory is dead, no? 00.38.22 # or you're doing something that the player doesn't support 00.38.52 # I'm not very experienced with these sandisk devices, so I can't properly guide you through this 00.38.52 # I have used clip+ for quite a while, bought these players as a broken lot as a hope of fixing them 00.39.02 # what's up with the second one? 00.39.08 # thats ok, i appreciate you talking with me 00.39.30 # the second one plugs in, sees something but 1) no display whatsoever and 2) wont format either 00.40.09 # so it shows as a drive as well, which capacity? 00.41.34 # it shows 2 drive, one is 4.03MB and one is 3.69GB 00.42.30 # (I had to use the partition program to find that info, Win 7 doesnt like the drives) 00.43.40 # if you have a microsd card in those players, remove it, just to rule that out 00.43.49 # this could otherwise get a bit confusing ;) 00.44.20 # run diskmgmt.msc 00.44.23 # no microsd in them 00.44.28 # that will tell you where those drives are coming from 00.44.41 Quit alexbobp (Ping timeout: 240 seconds) 00.46.04 Nick DormantBrain is now known as SuperBrainAK (~andy@74.112.200.73) 00.46.22 Join alexbobp [0] (~alex@capitalthree.pwnz.org) 00.46.33 # ah my mistake it just shows 4MB for Player 2 00.46.41 # 4MB RAW 00.47.53 # as far as I can tell this one is dead. you could try shorting the pins there, but that looks like a dead internal SD 00.48.23 # my clip+ has acted funky once, I thought I fixed it by dd'ing the original firmware to it, but other people have not been able to reproduce that 00.48.41 # bertrik: in which state? full capacity or 4MB? 00.48.55 # I have a 4MB dead one here, JTAGging it showed a completely unresponsive internal SD 00.49.01 # it's very rare for people to successfully recover a bricked AMS player 00.49.12 # i.e. a JTAG-booted rockbox was able to work from microSD, but couldn't access the internal one 00.49.22 # TheSeven: I don't remember 00.49.22 # I think you did the builds for me for these tests back then ;) 00.49.53 # so i have a Q for u all then 00.50.00 # since these SDs appear pretty dead 00.50.14 # can you hardware swap the internal SD from another player? 00.50.17 Quit bluebrother (Disconnected by services) 00.50.23 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 00.50.29 # Im very good at soldering and can do it, but dont know if the software supports that 00.50.31 # the first one seems recoverable by software means, the second one probably not. 00.50.53 # if they're otherwise identical devices, it swapping the flash chip might work 00.51.11 Quit ender` (Quit: I spilled Spot Remover on my dog... Now he's gone.) 00.51.17 # it's quite possible that it's actually some data structure on that flash that's corrupted, causing the SD controller do not boot up anymore 00.51.25 # there are slight hardware revisions 00.51.35 # and the chip part #s never are exactly the same 00.51.37 # so even cloning an image of the flash chip might possibly work 00.51.52 # (assuming the chips have exactly the same capacity and layout) 00.52.08 # yeah they do seem to 00.52.12 # sorry 2 convos here now 00.52.15 Quit fs-bluebot (Ping timeout: 245 seconds) 00.52.20 # Ill stick with the first Q 00.52.37 # if the SD controller doesnt boot, thats when you go to NAND, right> 00.52.39 # look up the datasheets for those particular chips, if the bank, block, page and spare sizes are identical 00.52.53 # what is the proper way to use the NAND? (in windows) 00.53.03 # you never access the raw nand 00.53.11 # there's an SD card controller in between 00.53.12 # ok 00.53.29 # by connecting these unbricking pins you just make the player unhide its firmware partition 00.53.39 # ahhh i see 00.54.13 # so as long as the firmware boots, or the SD controller doesn't respond at all (4MB/32MB mode), there's little point in doing so 00.54.16 # IIRC, it has 2 copies of the firmware image in the first 30 or 32 MB 00.54.27 # so by doing my format I deleted my own firmware and bricked it? 00.54.39 # interesting 00.54.44 # if you did that after unhiding the firmware, quite possibly 00.54.52 # in that case i'd expect it to always boot into this mode now 00.55.03 # so it might be recoverable if you have an image 00.55.18 # which player is the one that you formatted this way? 00.55.18 # i do have an image 00.55.31 # and yes it boots into this mode now, with 3.69GB memory 00.55.37 # this is Player 1 00.55.50 # how to I flash the image in this mode? 00.56.21 # oh, so there is a 4 MB, 32 MB and now a ~4 GB bricked mode? 00.56.26 Join fs-bluebot [0] (~fs-bluebo@g224239084.adsl.alicedsl.de) 00.56.27 # yes 00.56.56 # Player 1 is a 4GB bricked on (I reformatted in recovery mode before talked to you) 00.57.13 Quit the-kyle (Remote host closed the connection) 00.57.27 # Player 2 is a 4MB mode, havent shorted pins yet 00.58.36 # I also have a player 3 in 32MB mode (I tried swapping the internal SD chip, apparently unsuccessfully) 00.58.40 # audiomodder: it's all very vague. The people who managed to unbrick it, if any, didn't really document it 00.59.00 # that sucks 00.59.07 # I saw this: http://forums.rockbox.org/index.php?topic=29097.0 00.59.09 # I'd try dd'ing a clppa.bin image to the 4GB one 00.59.18 # user "Darko" said they would document it 00.59.36 # the 4 MB mode may just expose the (D)RAM and not access the flash at all 00.59.56 Join the-kyle [0] (~kyle@kyle.tk) 01.00.11 # unfortunately the 4GB wont format 01.00.33 # I can get it to format sometimes by creating partitions on it, and making a small partition that seems to work 01.00.46 # but the full 4GB wont complete a format :/ 01.01.48 # I think trying to format is no use at this stage 01.02.23 # yeah, so how do I put clppa.bin on it then> 01.02.44 # audiomodder: if player 1 still shows something on the display after rebooting, you haven't actually managed to corrupt the firmware 01.02.56 # with dd, it's like writing raw sectors to it 01.03.19 # careful, dd to the wrong device can screw up your HDD contents 01.03.30 # lol Im such a n00b, I thought you meant :download" 01.03.47 # TheSeven: there is no display now :'( I should have come here first 01.03.57 # <<< face palm for not following inst. 01.04.17 # in that case, you'll probably have to write the raw firmware image to it 01.04.25 # HOWEVER, Player 1 did format!! 01.04.35 # if that works, it should be back to where it was before 01.04.37 # to FAT16 successfully 01.04.52 # how do I write raw firmware image to it? 01.04.57 # what is "dd"? 01.05.18 # that's nonsense. it won't expect any partitioning/formatting in this mode. you only need to format the data partition of the flash, and that needs to be FAT32 01.05.24 # dd is a linux "disk dump" tool 01.05.34 # you can probably use something like rawwrite for windows instead 01.05.54 # So the clip+ does not work with FAT16? 01.06.07 # OK Ill try FAT32 01.06.08 # rockbox doesn't work with fat16 as far as I know 01.06.12 # not sure about the original firmware 01.06.29 # but if it has no display at all, formatting won't help at this point (only after recovering the corrupted firmware) 01.06.47 # bertrik: does clppa.bin just need to be written to the first sectors of the internal SD? 01.07.22 # yes I think so, but that's just an educated guess 01.07.28 # bed time for me 01.07.53 # thanks for your help bertrik 01.07.57 # well, you guess is at least more educated than mine :) 01.08.08 # I just downloaded RawWrite for WIndows. 01.08.16 # on startup is says "no floppy found: 01.08.47 # and it wont let me select the Sansa drive 01.08.50 # hm, yes, seems like that one can only do floppys 01.08.51 # just be careful you don't accidentally write to your harddisk 01.08.56 # they did also make a dd tool though 01.08.57 # do you know another program for windows that does this? 01.09.25 # http://www.chrysocome.net/dd (from the same developer), but it's a command line tool 01.09.35 # ah found it 01.09.41 # http://sourceforge.net/projects/win32diskimager/ might be easier to use 01.09.47 # nice just clicked on that link 01.10.11 # ok ill try that one 01.11.48 # OK I installed it and have it read to write 01.11.57 # do I select MD5 Hash? 01.13.07 # no 01.13.19 # just select clppa.bin and the correct drive, then click write 01.13.35 # ok 01.14.05 # then safely eject the USB drive if possible, then power down the player 01.14.13 # (10 second press on the power button) 01.14.36 # if everything worked, it should boot back up normally (and possibly complain about formatting problems) after powering it back on 01.16.16 # sweeeet!! 01.16.22 # yeah it says FAT is corrupted again now 01.16.33 # wow, we should probably document that this does indeed work ;) 01.16.52 Quit bertrik (Remote host closed the connection) 01.17.13 # yeah that would be good 01.17.30 # so what do I do now? 01.18.06 # diskmgmnt shows 3.69GB RAW again 01.18.24 # display works and shows as connected 01.26.14 Quit audiomodder (Quit: Page closed) 01.26.33 Join audiomodder [0] (ac0215fb@gateway/web/freenode/ip.172.2.21.251) 01.26.37 # hello? 01.30.35 # TheSeven you are my only hope heh 01.31.50 # audiomodder: try formatting that as fat32 01.31.57 Quit K1773R (Ping timeout: 260 seconds) 01.32.15 # or, if that doesn't work for some reason, delete the partition in diskmgmt.msc, recreate it, and format it again 01.33.47 # wow, it worked this time 01.33.58 # I guess recovery mode was the right way to go 01.34.30 # I put clppa.bin on it but when I uplug from PC it still says "FAT corrupted" :/ 01.35.59 # any ideas how to get it to write the firmware now? the internal SD appears good now 01.36.07 # * TheSeven is confused 01.36.26 # what exactly did you do now? 01.37.07 # formatted FAT 32 01.37.14 # safely disconnect 01.37.21 # and it reboots and says FAT corrupted 01.37.38 # oh I put clppa.bin in the root before disconnect 01.37.59 # ok, so not using win32diskimager or anything? good. 01.38.07 # hm, not sure why it doesn't like the FAT 01.38.17 # try completely deleting and recreating the partition 01.38.32 # still fat32? 01.38.48 # if that also doesn't help, check with sandisk support if there's anything special you need to do to format these (maybe they have a tool for that on their site?) 01.38.49 Join K1773R [0] (~K1773R@unaffiliated/k1773r) 01.38.50 # yes 01.40.06 # maybe it needs a long format? 01.40.17 # a quick format should be sufficient 01.40.49 # oh holy crap batman! 01.40.53 # it worked now!! 01.41.00 # who'd have thought ;) 01.41.03 Quit RiD (Quit: A good plan today is better than a perfect plan tomorrow.) 01.41.03 # << oh man youre my hero 01.41.30 # well, this last step is probably everything that was needed to be done in the first place 01.41.55 # so basically recover mode > reformat > diskwrite firmware > format FAT32 > install firmare 01.41.59 # no it wasnt at all 01.42.11 # formats didnt work before I did the long format in recovery mode 01.42.23 # windows *hated* that internal SD 01.42.32 # the "delete and recreate partition, format fat32" was probably everything that was necessary 01.42.36 # how exactly did the formats fail? 01.43.01 # it just kept saying "windows unable to complete the format" 01.43.20 # Im pretty sure I tried deleting the partition too 01.43.22 # maybe not 01.43.36 # *shrug* Im glad I learned how the recovery mode works though! 01.43.38 # weird, but I'm happy that it works again :) 01.43.57 # hopefully I can get another one working with the new things Ive learned today too :) 01.44.09 # I have 3 dead ones still lol 01.44.27 # Im gonna swap the internal SD chip back onto Player 3 and do recovery 01.44.32 # er, what we just did 01.44.50 # the other 2 say 32MB and 4MB, so they are totally dead, no>? 01.44.51 # that's only going to work if it appears with its full capacity 01.44.58 # gotcha 01.45.02 # quite likely, yes 01.45.08 # ah thats a shame 01.45.10 # we don't know what exactly is dead though 01.45.10 # parts bin 01.45.15 # either the flash chip, or the data on it 01.45.30 # interesting 01.45.44 # is there a way I can write this up 01.45.44 # there are some internal data structures for the wear leveling and bad block management, if those get screwed up, it could be possible for it to fail that way 01.45.57 # or someone else to do that? I think this info could help ppl 01.46.12 # interesting 01.46.23 # yeah I tried recover mode on player 2, still 4MB :/ 01.46.30 # but Im so happy this one is working 01.46.41 # that means spendign the $$$ on broken players was worth it after all! :) 01.47.03 # so if you have a flash chip from a player that works (or at least ends up in the full capacity recovery mode), and one from a 4/32MB one with identical internal geometry, cloning an image from one to the other might possibly help 01.47.13 # but you need a raw nand programmer to do that 01.47.26 # and you'll probably have to quite some research on these things 01.47.32 # oic 01.47.37 # that sounds complex 01.47.46 # i dont even know what a raw nand programmer is 01.48.03 # then you can probably consider those devices dead 01.48.40 # (for the record, I once had a sandisk microsd card which showed similar behavior: 32MB capacity after being flaky for a while) 01.49.09 # (sandisk said that's clearly an RMA case, not fixable by the end user, so I got a replacement card) 01.49.21 # oh interesting 01.49.23 # thats good to know 01.49.27 # i can still use the parts 01.49.32 # headphone port, battery and all that 01.49.43 # plus the buttons break with water damage and all that 01.49.51 # (they also said that this was a rather common issue with that generation of cards, and wouldn't happen again with the replacement card) 01.49.56 # ive fixed these before swapping that kinda stuff 01.50.02 # interesting 01.50.10 # i learned the hard way to not buy SD cards on ebay 01.50.13 # they all did crap like that 01.50.22 # so this kinda reminds me of Samsung's eMMC "SuperBrick" bug 01.50.42 # so it might after all be a firmware bug of SanDisk SD cards 01.51.11 # which in turn means it's quite likely that the SD controller in these devices could have similar bugs 01.51.43 # interesting 01.51.46 # i love these things tho 01.51.51 # when I show them to people 01.51.54 # their eyes go wide 01.52.13 # they dont understand how it can have a built in radio and voice recorder in addition to the player 01.52.20 # so many people stuck on the apple stuff 01.55.56 Join adnap [0] (~adnap@cpe-24-28-68-235.austin.res.rr.com) 01.56.55 # Can Rockbox for Android play from a URL? If not, does anyone know a good app that does this? 01.57.25 # I use MX Player for handling video files and streams. (warning, free version is ad supported) 01.57.27 # rockbox does not - any other app would be off-topic for this channel... 01.57.47 # scorche|sh: wait so are you saying if someone knows a useful thing to recommend it's not ok to say it? 01.58.02 # adnap: and a free app just for streams is servestream 01.58.12 # alexbobp: this channel is for the discussion of rockbox - not for other items 01.58.30 # alexbobp: feel free to join another channel to talk about other subjects or even send a PM... 01.58.36 # well hopefully this info gets written up somewhere 01.58.52 # it was just a short answer to one question and the question did involve rockbox. it's over now, don't worry 01.58.57 # for the recovery mode sansa stuff i mean 02.03.22 Quit ZincAlloy (Quit: Leaving.) 02.18.00 *** Saving seen data "./dancer.seen" 02.21.31 # TheSeven, are you there? 02.22.03 # Just wanted to let you know that the recovery mode format really seems to be what saved it 02.22.22 # I swaped the internal SD back into player 3 and it wont format or delete the partition (its 8GB) 02.22.44 # so I think the recovery mode format is key to saving some of these bricked players (if you do a write-up) 02.27.29 # soap: re your forum thread about random foder advance 02.31.18 Join ygrek [0] (~user@108.59.6.97) 02.38.05 # OK I posted the info from earlier today here: http://forums.rockbox.org/index.php/topic,29097.0.html 02.38.59 Quit babylonlurker (Ping timeout: 252 seconds) 02.52.03 Quit audiomodder (Quit: Page closed) 02.54.15 # JdGordon, yea, what's up 02.54.45 # oh, was just saying you should have asked in here, could have had it done over the weekend :) 02.55.09 # lol. 02.55.31 # What you mention in the thread sounds fine. This would be a plugin modification? 02.56.14 # and taking the weight from the parent folder is one of those important little things which makes it so much easier to manage in a large collection I didn't think of. 02.57.35 # my plan is to fix it all so the code handles the current style and the new style so you'd only need to regen if you want to add the weights 02.57.48 # should be pretty simple 02.59.59 Quit AlexP (Remote host closed the connection) 03.09.50 # cool 03.10.25 Quit ygrek (Ping timeout: 260 seconds) 03.29.42 Join toehser [0] (~tom@Connqueror.Toms.NET) 03.53.12 Join ygrek [0] (~user@108.59.6.97) 04.03.25 Part toehser 04.06.17 Join Strife89 [0] (~Strife89@adsl-98-80-200-248.mcn.bellsouth.net) 04.15.27 Quit K1773R (Ping timeout: 252 seconds) 04.18.02 *** Saving seen data "./dancer.seen" 04.20.22 Join K1773R [0] (~K1773R@unaffiliated/k1773r) 04.28.15 Quit amiconn (Disconnected by services) 04.28.15 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.28.18 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 04.29.05 Quit pixelma (Disconnected by services) 04.29.06 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.29.08 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.40.16 # <[Saint]> JdGordon: regarding the multi-AA patch, tested and working fine, however...I think we can get away with this change without breaking any existing themes, or creating any new tags. 04.41.02 # <[Saint]> The way I see it happening is that %Cl "Just Works", if the theme only contains a single declaration - nothing changes. But the author should also have the option of using %Cl with an ident. 04.41.20 # <[Saint]> (this makes the code a lot more sonsistent with the way image and viewport preloads work) 04.41.24 # <[Saint]> *consistent 04.43.34 # <[Saint]> %Cl(ident, x,y,w,h,x-align,y-align) + %Cd(ident) 04.43.54 # 2 reasons I don't want to do that 04.44.25 # 1) Using the new tag alows me to change when the image is drawn (i.e imeeditably instead of at the end of the viewport, allows you to better control overlapping images) 04.44.41 # 2) adding the extra optinoal ident is seriously messy in the parsing code 04.44.42 # <[Saint]> *inconsistent control ;) 04.45.22 # I've always hated how the images are batch drawn at the end of each viewport 04.45.24 # <[Saint]> Ideally, I would like this to work the same as any other preloaded item. 04.45.45 # <[Saint]> And, to be perfectly honest, I think adding a new tag for this is confusing and overkill. 04.45.52 # <[Saint]> but, meh. 04.46.45 # the issue is (like I keep saying but havnt looked into coding yet) next track images, and alternate images... *front*, *back*, etc 04.46.48 # <[Saint]> If it was done this way the theme code could be a _lot_ cleaner. 04.47.03 # 2 tags is cleaner than 1? 04.47.07 # <[Saint]> AA could be preloaded just the same as images or condiditional viewports. 04.47.14 # <[Saint]> And wouldn;t be ties to a particular viewport. 04.47.44 # <[Saint]> And, 2 tags isn't necessary cleaner...no, but it is *consistent*. 04.47.54 # it doesnt make a difference, each dimension is only loaded once 04.48.27 # the new tag doesnt care about the viewport also 04.48.50 # <[Saint]> Oh - joy ;) 04.49.06 # ? 04.49.12 # <[Saint]> So, it could be contained in a viewport, but, not give a fuck about it...? Yay consuistency! :) 04.49.40 # it is drawn in the viewport as usual, and rendered with the viewport 04.50.02 # %Cl/%Cd is really not required 04.50.21 # it may end up being required once I fix %C for this though 04.50.31 # err, idents might be required 04.50.59 # I would have thought you prefer knowing for sure in what order images are drawn? 04.51.11 # in relatio to the rest of the viewport, all text and images in it? 04.52.18 # im going for lunch, back in 20 04.52.30 # <[Saint]> Perhaps I misparsed your statement, I would find it very confusing if the AA call came after a viewport declaration, but was still able to draw in the fullscreen viewport. 04.52.57 # <[Saint]> ANd, ultimately, I'm easy - but I do think that having it use idents would be a lot nicer for a few ways. 04.54.35 # <[Saint]> Knowing when the image will be drawn isn't ultimately that important IMO as you can already send things to the backdrop buffer anyway. 05.05.56 Quit steffengy (Disconnected by services) 05.05.57 Join steffengy1 [0] (~quassel@p57B498F8.dip0.t-ipconnect.de) 05.10.38 # [Saint]: no, x,y are viewport relative (just as they are now) 05.11.18 # <[Saint]> Theh I guess I have NFI what " the new tag doesnt care about the viewport also" meant. 05.12.06 # That was in reply to you saying "<[Saint]> And wouldn;t be ties to a particular viewport." ... they arent 05.12.54 # maybe its a misunderstanding somewhere 05.13.37 # if you have %Xd(anything, anything, 100, 100, anything, anything) 45 times in your wps it will still only load the image on the buffer once 05.13.43 # so it doesnt matter about idents 05.14.49 # <[Saint]> Hmmm...so I guess my bef simply boils down to consistency then. 05.14.51 # also, imo your ideal situation is broken (with images also). the image size should be linked with the preload but he image position should be on the display tag, %xd(ident) really is wierd 05.14.54 # <[Saint]> *beef 05.16.12 # this works with images because they are almost always only displayed in one place 05.17.00 # <[Saint]> I don't think the display tag has any business in governing the position, personally. 05.17.09 # <[Saint]> That's (historically) for the preload call. 05.17.22 # indeed.. an accident of history imo 05.18.07 # that last commit about reusing image buffers owuldnt be neseccary if this wasnt the case 05.18.18 # <[Saint]> Well, changing that is a massive, skin breaking change, and doing AA any other way adds yet another confusing aspect where elements need to be handled completely differently to their entirely similar counterpart tags. 05.18.33 # <[Saint]> %Cd shouldn't, in theory, be any different to %xd 05.18.47 # which is why I've gone a new tag 05.18.55 # but this isnt final yet so dont worry :) 05.19.08 # <[Saint]> that's just putting lipstick on a pig, though. ;) 05.30.00 Join Noctem [0] (~mel@ool-457ad527.dyn.optonline.net) 05.43.28 Quit TheSeven (Ping timeout: 264 seconds) 05.45.09 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 05.59.54 Join steffengy [0] (~quassel@p5088FF6A.dip0.t-ipconnect.de) 06.03.07 Quit steffengy1 (Ping timeout: 260 seconds) 06.03.42 Quit Noctem (Quit: Konversation terminated!) 06.03.57 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 06.05.49 Join us`0gb [0] (~0gb.us@c-71-237-219-28.hsd1.or.comcast.net) 06.18.04 *** Saving seen data "./dancer.seen" 06.18.54 Quit Unhelpful (Ping timeout: 240 seconds) 06.29.31 Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) 06.31.36 Join ungali [0] (~ungali@184.64.50.234) 06.31.36 Quit ungali (Changing host) 06.31.36 Join ungali [0] (~ungali@unaffiliated/ungali) 06.39.08 Join tertu [0] (~tertu@184-97-163-186.mpls.qwest.net) 06.48.57 Quit pamaury (Ping timeout: 276 seconds) 07.00.31 Quit tertu (Ping timeout: 260 seconds) 07.11.40 Join GodEater [0] (~whoknows@94.3.60.123) 07.11.40 Quit GodEater (Changing host) 07.11.40 Join GodEater [0] (~whoknows@rockbox/staff/GodEater) 07.12.11 Join Provel [0] (~Provel@75-132-32-77.dhcp.stls.mo.charter.com) 07.19.46 Quit jhMikeS (Ping timeout: 245 seconds) 07.29.46 Quit ungali (Ping timeout: 245 seconds) 07.29.55 Join JdGordon_ [0] (~jonno@rockbox/developer/JdGordon) 07.30.57 Quit JdGordon (Ping timeout: 240 seconds) 07.31.28 Join tertu [0] (~tertu@184-97-163-186.mpls.qwest.net) 07.32.50 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 07.40.52 Join kugel [0] (~kugel@rockbox/developer/kugel) 07.42.23 Join mortalis [0] (~kvirc@213.33.220.118) 07.44.26 Quit ygrek (Ping timeout: 252 seconds) 08.18.05 *** Saving seen data "./dancer.seen" 08.20.45 Join ygrek [0] (~user@108.59.6.97) 08.21.54 Quit JdGordon_ (Ping timeout: 276 seconds) 08.22.26 Join ygrek_ [0] (~user@108.59.6.97) 08.25.17 Quit ygrek (Ping timeout: 240 seconds) 08.30.00 Nick SuperBrainAK is now known as DormantBrain (~andy@74.112.200.73) 08.40.31 Join ender` [0] (krneki@foo.eternallybored.org) 08.47.57 Quit fragilematter (Quit: Leaving.) 09.00.16 Quit tertu (Quit: Leaving) 09.04.00 Quit Geoff_ (Ping timeout: 252 seconds) 09.04.06 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 09.08.47 Join Geoff_ [0] (~qua@192.3.27.126) 09.10.15 Join fragilematter [0] (~fragilema@unaffiliated/fragilematter) 09.12.57 Quit Geoff_ (Ping timeout: 240 seconds) 09.17.35 Join petur [0] (~petur@rockbox/developer/petur) 09.22.19 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 09.22.31 Quit user890104 (Quit: .) 09.23.40 Join user890104 [0] (Venci@unaffiliated/user890104) 09.25.02 Quit user890104 (Client Quit) 09.26.10 Join user890104 [0] (Venci@unaffiliated/user890104) 09.43.50 Quit adnap (Read error: Connection reset by peer) 09.44.26 Join adnap [0] (~adnap@cpe-24-28-68-235.austin.res.rr.com) 09.50.39 Join wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl) 10.07.18 # what should we do about this? http://forums.rockbox.org/index.php/topic,29097.msg228611.html#msg228611 10.07.30 # I think these instructions are potentially dangerous and mostly pointless 10.08.07 # it's mostly a "how I managed to fuck it up even more, and then recover it" story 10.09.37 # imo we should delete this as potentially harmful 10.09.52 # this will rise criticism though 10.10.30 # I think that it needs some more disclaimers and warnings at the very least, and should probably be moved to the wiki 10.10.43 # i.e. extend the AMS unbrick page 10.11.20 # the important information is: "yes, writing clppa.bin to sector 0 of a non-booting player showing the full capacity does work, at least sometimes" 10.11.46 # and I'm a bit puzzled why he had trouble formatting the player before doing that recovery mode mess 10.14.04 # this "zero out the whole device in recovery mode" is something that could go into the back of our minds as a very last resort measure for otherwise non-recoverable devices 10.14.06 Join edhelas [0] (~edhelas@2001:981:e7ba:1:863a:4bff:fe85:8a3c) 10.14.08 # hi everyone :) 10.14.15 # but I wouldn't like to have that on the wiki 10.14.57 # if all of you die it might be nice if it were written down somewhere 10.15.48 # the truth is that without proper understanding how *exactly* amsv2 boots this is pure trial and fail aproach 10.15.49 # I'll put a compactflash card in my iPod Mini soon, any known issues with rockbox ? 10.16.47 # actually I think that everything relevant is contained already in http://forums.rockbox.org/index.php/topic,29115 10.16.53 # edhelas: not that I know of. General advice is to use good cards from established brands rather then nonames 10.16.56 # so that other post should probably just go away 10.18.08 *** Saving seen data "./dancer.seen" 10.18.22 # wodz, I'll buy this http://www.delock.com/produkte/F_277_Adapter_61795/merkmale.html?setLanguage=en with a Kingston SDHC card 10.18.49 # I've seen that it support IDE stuffs 10.20.00 # while they typically should (and it might be fixable in software if they don't), these things are by no means guaranteed to work with ipods and rockbox 10.20.07 # eee, wait you are talking about cf<->sd converter. That is not the same as CF itself. 10.20.11 # we've had some cases, especially on ipod classics though, where they didn't 10.20.26 # wodz, yeah I know 10.20.58 # http://forums.rockbox.org/index.php?topic=48240.0 someone already tried this brand here 10.20.59 # edhelas: we had reports of failing diferent something<->sd converters in the past 10.21.56 # edhelas: so basically no guarantee while I can say based on my personal experience that regular CF just works 10.22.21 # ok :) I'll try and give you a feedback 10.25.42 Quit mc2739 (Ping timeout: 265 seconds) 10.27.07 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 10.30.40 Join JdGordon| [0] (~jonno@rockbox/developer/JdGordon) 10.35.28 # wodz, http://www.tarkan.info/20121226/tutorials/ipod-and-sdhc-sdxc-cards some guys have successfully used this brand adapter in their iPod :) 10.41.38 # edhelas: I am not saying it doesn't work. I just say that while regular CFs have been tested by many, various adapters not 10.42.38 Quit einhirn (Ping timeout: 252 seconds) 10.43.35 # ok :) 10.43.50 # edhelas: with those tarkan adapters in particular we have some trouble on ipod classics 10.43.56 # only with SD cards from some brands though 10.44.29 # the good news is that tarkan himself appeared in #freemyipod-support and tried to help debug these issues 10.44.49 # (I hope he'll come back one day with bus traces of what's happening) 10.44.54 # TheSeven: really? Thats unusual 10.45.19 # yeah he said he has equipment to actually capture what's going on on the ata pins to see who's at fault here 10.46.15 # Lexar cards work for some reason, SanDisk cards don't 10.46.20 # I think one of his customers pulled him into our channel ;) 10.46.47 # :) 10.46.51 # it's nice 10.47.06 # edhelas: also, battery life with my adapter from Tarkan was abysmal, but I couldn't be arsed to debug it either 10.47.30 # I think there are several people with tarkan adapters without battery issues though 10.47.33 # TheSeven: my adapter is on its way to your mailbox 10.47.37 # on your ipod mini ? 10.47.51 # so I guess that there was something wrong with this particular adapter or even adapter-card combination 10.47.54 # I posted it yesterday 10.47.55 # copper: thanks :) 10.48.12 # edhelas: that was on a classic 10.48.29 # ok :) 10.49.00 # TheSeven: btw, amazon refunded me before my Lexar card even left the post office 10.49.02 # it's quite likely that the pre-classic ipods are a bit less picky 10.49.07 # wow 10.49.25 # the full 110 euros 10.49.29 # copper: As I said earlier - the power to hdd is hw cut when not in use so it would need to consume HUGE amount when active to see the difference 10.49.52 # well it will be in the hands of TheSeven 10.50.17 # wodz: is it really cut? 10.50.38 # * gevaerts is surprised by that 10.50.56 # gevaerts: how does ARC handle enabling of ep>0? I'm having trouble finding a suitable spot in my new driver 10.51.04 # gevaerts: ask TheSeven but judging from code we mess with PMU for that 10.51.05 # TheSeven: keep the adapter whether you "fix" it or not, I'm done with my iPod 10.52.02 # gevaerts: anyway what is so surprising? On older hardware (irivers, mpios) the power line for hdd goes through mos just for that 10.52.03 # though it'd be nice for future customers of Tarkan's if you guys could figure it out 10.52.07 # yes, there's a boost-buck converter in the PMU that provides 3.3V for the HDD, which we're shutting off (apple as well) while the disk isn't "spinning" 10.52.59 Nick JdGordon| is now known as JdGordon (~jonno@rockbox/developer/JdGordon) 10.53.30 # gevaerts: the only place that I could set is in usb_drv_recv 10.53.40 # that's a bit nasty though 10.54.01 # or in usb_drv_cancel_all_transfers, which is even more counter-intuitive 10.54.48 # TheSeven: usb_drv_request_endpoint() ? 10.55.02 # TheSeven: it keeps an array of endpoint allocations (called "endpoints") which is filled by usb_drv_request_endpoint(). This array is then used by init_queue_heads() and init_endpoints() to set up the hardware. Those are called by usb_drv_set_address() 10.55.08 # wodz: that happens *before* usb_cancel_all_transfers, which will take them down again 10.55.52 # gevaerts: that implies that your cancel_all_transfers implementation doesn't actually disable the endpoints 10.56.03 # well, maybe I should just leave all of them activated all the time 10.56.15 # Does it have to? 10.56.25 # It needs to stop transfers in progress 10.56.47 # TheSeven: cancel_all_transfers should kill the ongoing transfers not deactivate endpoints imo 10.57.39 # well, as long as we don't have to deal with multiple configurations, we can probably get away without ever disabling endpoints 10.58.25 # * gevaerts isn't sure if anyone actually ever implemented support for multiple configurations in a host stack 10.58.41 # linux definitely supports that 10.59.11 # How does it decide which one to pick? 11.00.34 # it picks the first available, unless something higher level instructs it to pick another one 11.00.47 # * gevaerts nods 11.00.54 # from e.g. libusb you can just do a set_configuration(index) to switch to a different one on the fly 11.01.13 # The thing is that "something higher level" has to know about the specific device 11.01.27 # Which won't be true for MSC I strongly suspect! 11.01.56 # I'm just saying that the host stack can do it ;) 11.02.25 # Yes, I'll admit I was wrong :) 11.15.21 # * TheSeven crosses fingers :) 11.17.47 Quit us`0gb (Quit: http://0gb.us/) 11.18.17 # hm, something keeps stalling EP1 IN for some reason 11.23.09 # race condition :/ 11.31.00 Join ZincAlloy [0] (~Adium@pD9EEA44E.dip0.t-ipconnect.de) 11.34.19 # steffengy: around? 11.43.05 # hm... we're getting close :) 11.54.00 Join einhirn [0] (~Miranda@bsod.rz.tu-clausthal.de) 11.54.25 # ok, the current situation is this: 11.54.36 # mass storage alone seems to work on linux at the first glance 11.54.50 # haven't tested it extensively yet 11.54.58 # hid however fails 11.55.30 # the ipod stops responding to anything on EP0 after sending the first GET DESCRIPTOR RPIPE response 11.55.56 # on EP1 it sends an ACK for the first CBW, but never returns a CSW 11.56.16 # the kernel itself seems to be still alive at this point, it dies a few seconds later when the host issues a bus reset 11.58.02 # if I disconnect it before that bus reset, we run into what looks like a lockup of the USB thread 11.58.21 # which is a bit odd as disconnecting should cause a bus reset IRQ as well 11.58.30 # so whatever locks up the kernel must be happening a bit later 12.18.09 *** Saving seen data "./dancer.seen" 12.40.37 Quit ygrek_ (Ping timeout: 240 seconds) 12.53.59 # does anyone use the random folder advance thing? 12.55.54 Join Misanthropos [0] (~Misanthro@frnk-4d010aae.pool.mediaWays.net) 13.05.17 Quit pamaury (Remote host closed the connection) 13.06.39 Quit shamus (Ping timeout: 265 seconds) 13.07.20 Join shamus [0] (~shmaus@ip-206-192-193-180.marylandheights.ip.cablemo.net) 13.14.28 Quit Guest81512 (Ping timeout: 265 seconds) 13.14.28 Join Guest70275 [0] (~Slayer@c-69-143-187-144.hsd1.va.comcast.net) 13.14.28 Quit ender| (Ping timeout: 265 seconds) 13.14.45 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 13.15.34 Join ender| [0] (krneki@2a01:260:4094:1:42:42:42:42) 13.17.18 Quit Zagor (Ping timeout: 265 seconds) 13.18.47 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 13.19.45 Quit kugel (Remote host closed the connection) 13.19.52 Join kugel [0] (~kugel@rockbox/developer/kugel) 13.19.59 Join Rower [0] (husvagn@78.70.32.176) 13.20.11 Quit knittl (Ping timeout: 265 seconds) 13.20.53 Join knittl [0] (~knittl@unaffiliated/knittl) 13.24.32 Quit Rower (Ping timeout: 265 seconds) 13.24.46 Join Rower [0] (husvagn@h176n2-aeg-a11.ias.bredband.telia.com) 13.27.07 Join Xerion [0] (~xerion@5419F5F4.cm-5-2d.dynamic.ziggo.nl) 13.27.42 Join Geoff_ [0] (~qua@192.3.27.126) 13.32.04 Quit Xerion_ (Ping timeout: 265 seconds) 13.32.04 Quit Guest70275 (Ping timeout: 265 seconds) 13.33.29 Join Guest70275 [0] (~Slayer@c-69-143-187-144.hsd1.va.comcast.net) 13.55.16 Quit mortalis (Ping timeout: 265 seconds) 13.57.54 Quit Guest70275 (Ping timeout: 265 seconds) 13.59.36 Join Guest70275 [0] (Slayer@c-69-143-187-144.hsd1.va.comcast.net) 14.00.26 Quit kugel (Quit: Lost terminal) 14.04.01 Join kugel [0] (~kugel@rockbox/developer/kugel) 14.12.23 Quit Guest70275 (Read error: Connection reset by peer) 14.12.38 Join Guest70275 [0] (~Slayer@c-69-143-187-144.hsd1.va.comcast.net) 14.18.12 *** Saving seen data "./dancer.seen" 14.22.40 Quit Guest70275 (Ping timeout: 265 seconds) 14.23.13 Join Guest70275 [0] (Slayer@c-69-143-187-144.hsd1.va.comcast.net) 14.24.53 Quit Geoff_ (Remote host closed the connection) 14.48.21 Quit Misanthropos (Ping timeout: 265 seconds) 14.49.09 Quit Guest70275 (Ping timeout: 265 seconds) 14.52.30 Quit ender| (Ping timeout: 265 seconds) 14.53.16 Join amayer [0] (~amayer@mail.weberadvertising.com) 14.54.06 Join ender| [0] (~ender1@2a01:260:4094:1:42:42:42:42) 15.01.38 # WTF 15.01.59 # pamaury, gevaerts: seems like this USB core can only send up to 127 bytes at once on EP0 15.02.10 # the HID REPORT descriptor is 133 bytes 15.02.17 # that causes a lockup during enumeration 15.02.25 # that's super weird 15.02.33 # I'll probably have to split that thing in the driver code 15.02.53 # the transfer size field is just 7 bits on EP0 15.03.13 # oh 15.03.15 # nice 15.04.32 Join Guest70275 [0] (~Slayer@c-69-143-187-144.hsd1.va.comcast.net) 15.04.33 # TheSeven: does the core automatically splits into packets or you have to do that ? because it the latter, you already have to cut in pieces 15.04.49 # it seems like the core does that for all but ep0 15.05.11 Quit Jack87 (Ping timeout: 245 seconds) 15.05.17 Quit Rower (Quit: Hmmm...) 15.05.22 # I alwayw knew that it was rotten to the core ;) 15.06.35 # haha, what a creativity of hw designers :P 15.07.04 # the contest of least expected quirk or what? 15.07.47 # "Who ever needs more than 127 byte descriptors?" 15.08.16 # gevaerts: I'd expect 640 bytes to meet everybody needs :P 15.08.28 # "software can always compensate for hardware quirks he said" 15.08.38 # wodz: now that *would* be a reasonable size! :) 15.08.57 Quit Zagor (Ping timeout: 265 seconds) 15.09.27 # how random is sram state on power up? 15.09.59 Join Jack87 [0] (Jack87@nasadmin/admin/jack87) 15.11.05 Join Rower [0] (husvagn@h176n2-aeg-a11.ias.bredband.telia.com) 15.11.32 Join Zagor [242] (~bjst@rockbox/developer/Zagor) 15.12.55 Quit wodz (Quit: Leaving) 15.23.16 Join model [0] (~model@cscluster.minotstateu.edu) 15.40.45 Join Misanthropos [0] (~Misanthro@frnk-4d010aae.pool.mediaWays.net) 15.41.07 # actually I guess this field is 7 bits in order to be able to express "64 bytes", not "127 bytes" 15.42.56 Quit mc2739 (Ping timeout: 252 seconds) 15.44.51 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 15.47.17 Join ygrek_ [0] (~user@108.59.6.97) 15.57.50 Join Guest81512 [0] (Slayer@c-69-143-187-144.hsd1.va.comcast.net) 15.58.43 Quit Guest70275 (Ping timeout: 265 seconds) 16.04.05 Quit Zagor (Quit: Clint excited) 16.14.01 Quit kugel (Quit: Lost terminal) 16.18.13 *** Saving seen data "./dancer.seen" 16.24.49 # ok, looks like I fixed hid to not mess with storage at least 16.25.05 # hid itself still doesn't seem to actually do anything though 16.33.06 Quit Strife89 (Ping timeout: 245 seconds) 16.33.29 Quit edhelas (Remote host closed the connection) 16.33.32 Quit TheSeven (Ping timeout: 252 seconds) 16.40.45 Quit Misanthropos (Remote host closed the connection) 16.43.25 Join Misanthropos [0] (~Misanthro@frnk-4d010aae.pool.mediaWays.net) 16.46.36 Join Strife89 [0] (~Strife89@2602:306:bce1:8c20:dcde:1e23:608c:9b1e) 17.04.25 Quit petur (Quit: *plop*) 17.04.29 Quit prof_wolfff (Ping timeout: 240 seconds) 17.17.30 Join prof_wolfff [0] (~prof_wolf@89.141.50.204.dyn.user.ono.com) 17.36.03 Join baudams [0] (57db6f2e@gateway/web/freenode/ip.87.219.111.46) 17.40.08 # hello, is there anyone here to assist me trying to unbrick a sansa clip+? 17.40.31 # shorted the pads and it is now exposing a 30.6MiB disk which I suppose is the bootloader flash 17.40.53 # the device refused to boot after 3 days left disconnected and a full day left charging 17.41.11 # I tried to restart it by keeping the power button >1min, by keeping power and left, and by keeping power and home 17.45.05 Join babylonlurker [0] (~quassel@veda.xs4all.nl) 17.46.02 Join AlexP [0] (~alex@rockbox/staff/AlexP) 17.57.54 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 17.58.31 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 18.17.13 Join rela [0] (~x@pdpc/supporter/active/rela) 18.18.16 *** Saving seen data "./dancer.seen" 18.23.47 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 18.31.38 Join bertrik [0] (~quassel@cl-1037.haa-01.nl.sixxs.net) 18.31.38 Quit bertrik (Changing host) 18.31.38 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 18.32.40 Quit Beta2K (Ping timeout: 245 seconds) 18.32.58 Join Beta2K [0] (~Beta2K@2607:f1c0:841:4eff::120) 18.44.40 Quit bertrik (Ping timeout: 272 seconds) 18.50.27 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 19.00.42 Quit rela (Read error: Connection reset by peer) 19.25.54 Quit ygrek_ (Ping timeout: 240 seconds) 19.28.06 Quit mc2739 (Ping timeout: 240 seconds) 19.30.01 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 19.36.16 Quit baudams (Quit: Page closed) 19.50.03 Join lebellium [0] (~chatzilla@89-93-178-161.hfc.dyn.abo.bbox.fr) 19.54.28 Quit pamaury (Ping timeout: 252 seconds) 20.18.18 *** Saving seen data "./dancer.seen" 20.36.45 Quit preglow (Ping timeout: 246 seconds) 20.45.56 Quit the-kyle (Remote host closed the connection) 20.46.30 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 21.00.41 Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) 21.02.05 Quit advcomp2019 (Ping timeout: 240 seconds) 21.14.05 Join preglow [0] (~thomj@2001:840:4243:3::100) 21.19.04 Join Blabla [0] (1f137872@gateway/web/freenode/ip.31.19.120.114) 21.19.25 Quit Blabla (Client Quit) 21.20.02 Join rookie [0] (1f137872@gateway/web/freenode/ip.31.19.120.114) 21.22.01 Quit rookie (Client Quit) 21.22.23 Join Tortelloni [0] (~chatzilla@31-19-120-114-dynip.superkabel.de) 21.22.51 # hi, is any developer right now online here? 21.43.31 Quit bertrik (Ping timeout: 245 seconds) 21.43.32 Join the-kyle [0] (~kyle@cpe-075-177-188-248.nc.res.rr.com) 21.43.44 Quit the-kyle (Remote host closed the connection) 21.43.58 Join bertrik [0] (~quassel@cl-1037.haa-01.nl.sixxs.net) 21.43.58 Quit bertrik (Changing host) 21.43.58 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 21.46.11 Join the-kyle [0] (~kyle@kyle.tk) 21.57.07 Join kugel [0] (~kugel@91-64-116-253-dynip.superkabel.de) 21.57.07 Quit kugel (Changing host) 21.57.07 Join kugel [0] (~kugel@rockbox/developer/kugel) 22.07.34 Quit y4n (Disconnected by services) 22.07.41 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 22.10.58 Quit tchan (Ping timeout: 260 seconds) 22.14.32 Quit y4n (Quit: Today is the perfect day for a perfect day.) 22.18.22 *** Saving seen data "./dancer.seen" 22.33.04 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 22.33.58 Quit bertrik (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 22.34.27 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 22.36.49 # Tortelloni: if you have a question just ask. If someone can help you they will answer as soon as they are active 22.39.31 Quit lebellium (Quit: ChatZilla 0.9.90.1 [Firefox 30.0/20140605174243]) 22.39.52 Quit ruskie (*.net *.split) 22.39.52 Quit TBCOOL (*.net *.split) 22.39.52 Quit Elfish (*.net *.split) 22.39.52 Quit uwe_mobile__ (*.net *.split) 22.39.53 Quit GeekShadow (*.net *.split) 22.39.53 Quit derf (*.net *.split) 22.39.54 Quit KotH (*.net *.split) 22.39.54 Quit DormantBrain (*.net *.split) 22.40.01 Join GeekShadow [0] (~antoine@reactos/tester/GeekShadow) 22.40.01 Join Elfish [0] (amba@2001:1608:12:1:13:3:3:7) 22.40.02 Join KotH [0] (~attila@lou-outside.kinali.ch) 22.40.05 Join derf [0] (~derf@static-108-18-126-14.washdc.fios.verizon.net) 22.40.06 Join uwe_mobile [0] (~uwe@static.88-198-8-117.clients.your-server.de) 22.40.08 Join TBCOOL [0] (~tb@c-2a91e555.09-273-73746f44.cust.bredbandsbolaget.se) 22.41.02 Join DormantBrain [0] (~andy@2001:470:8:a61::5f92:59a1) 22.41.26 Nick DormantBrain is now known as SuperBrainAK (~andy@2001:470:8:a61::5f92:59a1) 22.47.53 Join Prodicus [0] (~chatzilla@2605:a601:561:7701:c13:43f9:c0cd:849) 22.48.41 # Ok, i got a sansa clip plus. with default firrmware it isn't possible to prevent charging the battery if the sansa is conncted to the pc. is there a hidden option in rockbox with which it's possible? if not, will it integrated anyday? -given that there is an interface for it... 22.56.14 # it just suck the the battery is charging everytime i put some files on my sansa. and it's not possible to prohibit charging the battery by a usb-cable-mod. the only way is to do that by the firmware. therefore it would be nice if there is a possibility to do that with rockbox 23.03.35 Quit Tortelloni (Remote host closed the connection) 23.05.30 Quit Strife89 (Ping timeout: 240 seconds) 23.07.45 Join Tortelloni [0] (~chatzilla@31-19-120-114-dynip.superkabel.de) 23.08.49 Join ruskie [0] (ruskie@sourcemage/mage/ruskie) 23.09.00 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 23.10.52 Quit Galois (Ping timeout: 1825 seconds) 23.13.48 Quit pamaury (Remote host closed the connection) 23.18.25 Quit Cultist (*.net *.split) 23.18.46 Join Cultist [0] (~CultOfThe@c-98-223-211-32.hsd1.il.comcast.net) 23.20.10 Quit amayer (Quit: Leaving) 23.31.20 Join Galois [0] (djao@efnet.math.uwaterloo.ca) 23.32.04 Join Strife89 [0] (~Strife89@adsl-98-80-200-248.mcn.bellsouth.net) 23.32.27 Join RiD [0] (RiD@bl22-226-139.dsl.telepac.pt) 23.33.29 Quit Tortelloni (Quit: ChatZilla 0.9.90.1 [Firefox 30.0/20140605174243]) 23.36.54 Quit the-kyle (Remote host closed the connection)