--- Log for 23.12.109 Server: niven.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 21 days and 14 hours ago 00.02.02 # the tea5767 code that mcuelenaere just updated makes it seem as if there are two i2c addresses that the radio chip can be on, but it's really a difference in the i2c drivers rather than in the radio chip 00.04.06 # ideally all i2c drivers would use the same convention for i2c slave addresses 00.08.56 # * flyback bbl, family dinner 00.09.03 *** Saving seen data "./dancer.seen" 00.10.46 Quit Kitar|st (Connection timed out) 00.19.35 Quit casainho (Remote closed the connection) 00.23.23 Quit stephen__ ("Leaving") 00.35.45 Join slashroot [0] (n=morpheus@87.243.142.75) 00.39.38 Quit slashroot (Client Quit) 00.41.06 Quit Hillshum (Read error: 113 (No route to host)) 00.41.51 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 00.49.41 Quit petur ("Zzzzz") 00.54.51 Join n1s [0] (n=n1s@rockbox/developer/n1s) 00.56.00 Quit JdGordon| ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 00.57.27 Join Tomis [0] (n=Tomis@70.134.74.0) 00.58.16 Join togetic [0] (n=togetic@unaffiliated/ibuffy) 01.03.05 Join Tomis2 [0] (n=Tomis@70.134.96.143) 01.03.10 Join fdinel [0] (n=Miranda@modemcable235.127-131-66.mc.videotron.ca) 01.17.39 Quit toffe82 (Read error: 54 (Connection reset by peer)) 01.19.22 Quit Tomis (Read error: 110 (Connection timed out)) 01.19.23 Nick Tomis2 is now known as Tomis (n=Tomis@70.134.96.143) 01.36.38 Join NoGare [0] (n=chatzill@dyn216-8-128-56.ADSL.mnsi.net) 01.37.11 Join Tomis2 [0] (n=Tomis@70.134.85.22) 01.40.41 Quit Horscht ("Verlassend") 01.42.46 Quit JdGordon ("Leaving.") 01.43.39 Quit Tomis (Read error: 60 (Operation timed out)) 01.43.39 Nick Tomis2 is now known as Tomis (n=Tomis@70.134.85.22) 01.54.38 Join Horscht [0] (n=Horscht2@xbmc/user/horscht) 02.03.50 Join sagemfreak_ [0] (n=sven@p5492223A.dip0.t-ipconnect.de) 02.04.31 # amiconn: i'm trying to figure out your log in grey_core.c... it normalizes the input value to put the highest set bit at 1<<30, and then it tries a series of multipliers... if a multiplier leaves the result less than 1<<32, then the result replaces the value and the log of the multiplier is subtracted from the result? 02.07.10 Quit sagemfreak (Read error: 60 (Operation timed out)) 02.09.07 *** Saving seen data "./dancer.seen" 02.13.40 Quit darkham (Client Quit) 02.16.33 Quit n1s (Read error: 113 (No route to host)) 02.17.24 Quit Phyber0ptik (Read error: 104 (Connection reset by peer)) 02.40.26 Quit GeekShado_ (Read error: 54 (Connection reset by peer)) 02.43.30 Quit jordan`` (Remote closed the connection) 02.45.28 Join StealthyXIIGer [0] (n=stealthy@69.216.113.160) 02.58.47 Join jordan` [0] (n=jordan@78.235.252.137) 03.50.31 Join Strife89 [0] (n=michael@adsl-154-13-96.mcn.bellsouth.net) 03.56.58 Quit NoGare ("ChatZilla 0.9.85 [Firefox 3.6b5/20091204143806]") 04.06.43 Part froggyman 04.09.07 Join JdGordon [0] (n=jonno@rockbox/developer/JdGordon) 04.09.09 *** Saving seen data "./dancer.seen" 04.33.33 Quit StealthyXIIGer (Read error: 60 (Operation timed out)) 04.33.38 Join JdGordon1 [0] (n=jonno@c-24-22-210-83.hsd1.wa.comcast.net) 04.42.02 Quit JdGordon1 (Read error: 60 (Operation timed out)) 04.49.46 Quit kkurbjun ("Leaving.") 04.51.30 Join kkurbjun2 [0] (n=kkurbjun@204.183.33.50) 04.51.41 Nick kkurbjun2 is now known as kkurbjun (n=kkurbjun@204.183.33.50) 04.52.52 # New commit by 03kkurbjun (r24100): Brickmania: Improve screen collision detection. 04.56.14 Quit sbhsu (Remote closed the connection) 04.56.26 Join sbhsu [0] (n=a6530466@Zion.dorm.au.edu.tw) 05.08.54 Part kkurbjun 05.27.48 Quit panni_ ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") 05.42.06 Quit togetic (Read error: 110 (Connection timed out)) 05.47.59 # * flyback be back later 06.09.10 *** Saving seen data "./dancer.seen" 06.16.19 Join StealthyXIIGer [0] (n=stealthy@69.216.113.160) 06.20.34 Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") 06.36.17 Quit Tomis (Read error: 113 (No route to host)) 06.54.32 Quit FlynDice (Remote closed the connection) 06.59.25 Quit StealthyXIIGer (Read error: 110 (Connection timed out)) 07.00.06 Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) 07.03.23 Quit Strife89 ("Bed.") 07.04.55 Join Horschti [0] (n=Horscht2@xbmc/user/horscht) 07.13.46 Join Tomis [0] (n=Tomis@70.134.64.112) 07.14.55 Nick AaronM is now known as AaronMcD (n=Aaron@adsl-250-8-242.bhm.bellsouth.net) 07.15.04 Nick AaronMcD is now known as AaronM (n=Aaron@adsl-250-8-242.bhm.bellsouth.net) 07.19.25 # so why the heck do we allow the delete option in the WPS context menu? 07.21.29 # it really makes no sense that we allow the delete there... especially with its current undefined behaviour 07.23.09 Quit Horscht (Read error: 110 (Connection timed out)) 07.23.46 Quit AaronM (Client Quit) 07.26.29 Join AaronM [0] (n=Aaron@adsl-250-8-242.bhm.bellsouth.net) 07.29.50 # does "#define LCD_BACKDROP_BYTES (LCD_FBHEIGHT*LCD_FBWIDTH*sizeof(fb_data))" look correct? 07.43.58 Quit CaptainKewl ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") 07.46.29 # * JdGordon doesnt like it when its quiet in here.... 07.46.44 # can anyone tihnk of a reason to want to disable the theme but still show the users backdrop? 07.48.02 Join Hillshum [0] (n=hillshum@75-165-229-121.slkc.qwest.net) 07.53.26 # anyone know if its currently possible for a theme to set a backdrop but have no backdrop displayed in the WPS? 08.01.34 Quit mikroflops (Remote closed the connection) 08.01.48 Join mikroflops [0] (n=yogurt@217-208-157-242-no112.tbcn.telia.com) 08.06.19 # JdGordon: The delete option makes very much sense in the wps, for when you're test-listening a folder with new music 08.06.38 # sure, but it should skip to the next track then 08.06.49 # why? 08.07.02 # because otherwise you are in an undefined state 08.07.13 # the whole track might not be buffered 08.07.26 # Yes, but what's the problem with that? 08.07.43 # Btw, that's much more likely on lowmem targets 08.07.53 # you get a crappy track jump 08.08.12 # A possible solution to all this is queuing the delete to only happen at the end of the track 08.08.22 # Well, it would just switch to the next track like if the track was shorter 08.08.37 # I think thats very ugly 08.08.52 # The delete action should be well defined 08.08.53 # I think that's 100% acceptable (and iirc it's documented) 08.09.13 *** Saving seen data "./dancer.seen" 08.09.21 # its acceptable, but having it guarentee that the track will play to the end, but the track will be deleted once its played its much cleaner 08.09.21 # Most of the time you will skip after the delete anyway 08.09.41 # yes, so it shoud either auto-skip, or delete once the skip happens 08.09.42 # Imo that would be superfluous 08.10.20 # Either keep it as it is, or skip right after delete 08.10.51 # But I think the former is better. 08.11.04 # FS#9929 is what brought this up 08.11.22 # I prefer the latter 08.13.39 # Too much hassle for something that isn't really ann everyday feature, imo 08.13.47 # s/ann/an/ 08.13.53 # before I start pulling my hair out... was the backdrop define before correct? 08.14.12 # and I agree... but I'd like to close the bug one way or another 08.14.31 Quit AaronM ("sleepin with my black ipod playing death cab...... naked") 08.15.07 # The question is whether it behaves as described 08.16.17 # If rockbox gets confused by deleting *while* buffering, it would need to be fixed. Afaik it doesn't, but then I used this feature maybe once or twice during all the years, and only on hwcodec 08.16.43 # "Delete the currently playing file." is the sum total of the manual text for this feature 08.17.30 # there very possibly is a potential bug if the delete happened at exactly the right time while buffering, but hugley unlikely 08.19.32 # Well, a manual fix would also be a fix, wouldn't it? 08.19.59 # yes 08.20.00 # "Rockbox will continue playing what's already in the buffer." 08.20.28 # from a users POV that sounds unexpected though 08.20.41 # "the file is deleted, why is it still playing?" which is exactly that bug 08.20.53 # To answer your other question - that #define looks correct 08.20.59 # thanks 08.24.53 # That's the question, is it a bug or a feature? How intuitive should "intuitive" be? 08.25.37 # yes 08.25.43 # You can see it as a feature - rockbox deletes the file as soon as possible, yet continues playing as long as possible, or until you skip - you decide 08.29.52 # Btw, deleting at end-of-track wouldn't fix the "bug", it would even make it worse 08.31.15 # how do you mean? 08.31.41 # "I hit 'delete', but nothing happens. The file is still there, and is still playing" 08.32.01 # well yeah, that was just a quick and obviously bad idea 08.32.28 # * flyback http://www.youtube.com/user/Aussie50 <=== learn cool stuff 08.33.02 Join kugel [0] (i=kugel@rockbox/developer/kugel) 08.34.04 # Skip after delete would solve it - more intuitiveness at the cost of losing an admittedly tiny feature 08.34.21 # And more code (probably also tiny). 08.34.23 # doesnt that tiny feature trigger an error in the playback engine? 08.34.37 # i.e its expecting to load more from the file but gets a read error instead 08.34.59 # That I don't know. Back then I didn't observe any on hwcodec 08.35.02 # adding the skip is 1 function call 08.35.38 # hmm, maybe a bit more than that 08.35.52 # * JdGordon closes 08.36.21 # Sure it will see a read error. It should be able to handle it though, otherwise the error handling is broken and needs fixing 08.38.30 # moving the backdrop buffers into the skin buffer isnt as trvial as I was hoping :( 08.40.58 # * amiconn wonders what would be the advantage 08.41.18 # right now... none... 08.41.18 # well, little 08.41.32 # but when more than one skinnable screen can have its own backdrop, heaps 08.41.51 # especially if you dont use themes 08.43.20 # unless we decide to give up on keeping all the backdrops in memory 08.43.46 # which means reloading from disk when changing between screens, which sucks 08.44.12 Join n1s [0] (n=n1s@rockbox/developer/n1s) 08.44.36 # Different backdrops per screen? 08.45.42 # yes 08.46.01 # screen being wps, fm, rec, main 08.46.06 # * amiconn wonders where this will lead 08.47.39 # * JdGordon thinks its actually in amiconn's interest if this goes ahead... considering its probable RAM savings. 08.49.02 # n1s: Is this bitreverse function really used often enough to give a measurable speedup? 08.49.22 # If so, there's more potential in it, also for ARMv4/v5 and coldfire 08.51.53 # * kugel recommends amiconn to read the ml sometimes 08.52.14 Join tomers [0] (n=86bfe845@giant.haxx.se) 08.52.45 # jdgordon: Have you reach any sort of concensus with other developers before closing "FS#9929 - context menu delete does not work as expected 08.52.46 # "? 08.53.02 # red the last 30min of the logs 08.53.47 # read* 08.53.48 # if it's documented it's not a bug anyway, even though one could argue that it's strange behavior 08.53.50 # amiconn: i measured a speedup, but on pp and coldfire it was in the 0.3-0.5% range (so possibly caused by some side effect like cache alignment) on the beast it sped up decoding of some files as much as 2% 08.55.10 # it isn't called *that* often it was just a simple optimization i wanted to do for the beast since gcc doesn't use the rev instruction to do the byteswap 08.56.35 # Well, there's more to it because the 4-bit, 2-bit and 1-bit stages can be optimised further 08.58.11 # This very much reminds me of my geek bitswap for SH1 :) 08.58.24 # amiconn: i tried doing half the masks before shifting to use half as many constants and that gave slightly better code on arm but only gave a speedup when *not* using the swap32()... 08.59.18 # You only need the mask once - the other half can be done using xor 09.00.46 Join stoffel [0] (n=quassel@p57B4D2FE.dip.t-dialin.net) 09.01.37 Join einhirn [0] (i=Miranda@vpn10.rz.tu-clausthal.de) 09.04.08 # This should even improve things when written in C 09.04.39 # amiconn: ah, yeah, the coldfire swap32 does that 09.08.21 Quit gevaerts (Nick collision from services.) 09.08.32 Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) 09.09.06 Join petur [50] (n=petur@rockbox/developer/petur) 09.09.22 Join flydutch [0] (n=flydutch@host1-166-dynamic.8-87-r.retail.telecomitalia.it) 09.11.13 # * JdGordon has a cunning plan! 09.15.28 # aaah! 09.16.08 # setting a viewports colour to TRANSPARENT_COLOR wont work :p 09.16.57 # no surprise 09.17.46 # * JdGordon is *trying* to find a workable solution to having these settings outside of the sbs 09.20.19 Quit tomers ("CGI:IRC") 09.20.59 # that could work if the lcd driver stored its default colours from a setting callback... but frankly, that seems like more effort than its actually worth 09.28.23 Join webguest94 [0] (n=48ebd536@giant.haxx.se) 09.30.44 # when i uninstalled rockbox from my ipod, it went crazy and now it won't even work properly 09.31.17 # webguest94: first: How did you do the uninstall. second: how do you define "went crazy" and "won't even work properly". 09.31.46 # amiconn: the xor version is 4 instructions shorter on coldfire (when compiling with O3) but also uses only 4 large immediates instead of 8 09.33.09 # well from the rockbox that i installed menu, theres the uninstall and so i did that, after the process my ipod started saying some stuff like loading rockbox-error!can't load rockbox on ipod 09.33.20 # and now its stock like that 09.33.35 # webguest94: do you mean you used rbutil? 09.33.40 # no matter what i do my comp can't even recognize the ipod 09.34.01 # webguest94: have you reset it and restarted it in disk mode? 09.34.04 # yes, thats what was installed 09.34.41 # yes i have reset it and started it back to disk mode, but it takes me back to the same place with the error screen thing 09.34.49 # in that case you're not in disk mode 09.35.02 # you may find this page helpful : http://support.apple.com/kb/HT1363 09.35.52 # pay attention to the bit where it says "immediately". I means it. 09.35.56 # *It means it. 09.36.38 Join Grahack [0] (n=chri@ip-222.net-82-216-222.rev.numericable.fr) 09.36.53 # amiconn: scrap that, it's only one instruction shorter, but also gcc is braindead 09.37.26 # yes thats what i have done...immediately pressed and hold the select and play and it did the check and what not but no more than a minute it went back to the same screen with the rockbox can't be loaded 09.38.08 # n1s: The latter isn't exactly breaking news ;\ 09.38.23 # webguest94: if you keep seeing that message you are NOT going into disk mode, it's as simple as that. 09.38.27 # how so not breaking news? 09.39.32 # ok..how do i fix it...well it goes through the whole process of disk mode with the check screen then back to the can't load screen after a minte 09.39.36 # or less 09.40.04 # if you're seeing a "check screen" then you're putting it into diagnostics mode, not disk mode 09.40.09 # i.e. you're doing the wrong thing 09.40.33 # amiconn: so the only gain is less immediates and one instr less 09.41.19 # how so..i followed the instructions? 09.42.05 # webguest94: search me, you're the one doing it - not me. But if you follow those instructions properly, your ipod will enter disk mode, and your computer will be able to see it again. 09.42.33 # ok..thanks 09.45.44 # n1s: Less immediates is good for speed too 09.46.40 # amiconn: ok, it's actually a few instructions shorter on arm too so i'll have to benchmark this again 09.46.41 # One thing is that smaller code means better cache efficiency (although the effect might be covered by cache aliasing) 09.47.11 # Another is that too many instructions with more than one extension word starve the instruction fetch pipeline 09.47.21 # +in sequence 09.47.31 Quit Grahack ("Leaving.") 09.49.24 # * amiconn can also think about some arm asm trickery that should be even better than what gcc comes up with 09.53.41 Join JdGordon1 [0] (n=jonno@c-24-22-210-83.hsd1.wa.comcast.net) 09.54.16 Quit JdGordon1 (Client Quit) 09.57.39 Quit webguest94 ("CGI:IRC (EOF)") 10.02.16 # * n1s curses inline asm 10.09.16 *** Saving seen data "./dancer.seen" 10.17.40 Quit zMastaa (Read error: 110 (Connection timed out)) 10.34.15 Join elcan [0] (i=user36@pr0.us) 10.38.24 Quit stoffel (Read error: 60 (Operation timed out)) 10.43.23 Join pamaury [0] (n=pamaury@sal63-1-82-243-96-220.fbx.proxad.net) 10.59.41 Quit jds2001 (Remote closed the connection) 10.59.54 Join jds2001 [0] (n=jds2001@fedora/jds2001) 11.23.18 Quit kugel (Read error: 60 (Operation timed out)) 11.29.15 Join Horscht [0] (n=Horscht2@xbmc/user/horscht) 11.35.46 Join bmbl [0] (n=Miranda@unaffiliated/bmbl) 11.42.35 Join bianca [0] (n=0cec7962@giant.haxx.se) 11.45.52 # hey guys, I'm having a bit of an issue. I rockboxed my sansa over a year ago on an old laptop. I'm now using a different computer and want to add some media to the blasted thing, but I seem unable to add it as a device in the rockbox utility, despite looking over the faq and manual. any suggestions? 11.46.24 Join bertrik_ [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 11.49.25 # bianca, you want to add music to your rockbox player? 11.50.46 # if so, just connect it to your PC using USB and use your computers filemanager to copy the mp3 files to the player. The Player should appear as a Mass Storage Device 11.51.01 Quit Horschti (Read error: 110 (Connection timed out)) 11.53.35 # Hello, could someone here try to reproduce a bug related to "open" and "dircache_get_entry_ptr" ? I strongly suspect that dircache_get_entry_ptr is buggy and this bug makes open buggy. It requires to add code and compile 11.54.32 Quit bertrik_ ("mandatory reboot") 11.57.57 Quit bertrik (Read error: 113 (No route to host)) 11.58.44 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 11.59.20 Join stoffel [0] (n=quassel@p57B4D2FE.dip.t-dialin.net) 12.06.36 Join kugel [0] (i=kugel@rockbox/developer/kugel) 12.09.19 *** Saving seen data "./dancer.seen" 12.10.37 Quit shaggy-h () 12.10.49 Join shaggy-h [0] (n=kiwi@host-87-74-127-193.dslgb.com) 12.16.25 Join Jaykay [0] (n=chatzill@p5DDC6C5D.dip.t-dialin.net) 12.18.59 Quit n1s (Read error: 113 (No route to host)) 12.20.32 Quit bertrik (Read error: 104 (Connection reset by peer)) 12.20.51 # JdGordon: cleaning up the bug tracker is fine, but you are overdoing it. you closed FS#9929 with the reson "it might seem odd, but this is the expected behaviour", which is just plain wrong. a user never expects odd behaviour. 12.21.03 # * Jaykay suggests reopening it 12.22.18 # Jaykay: users expect a lot of odd behaviour 12.24.18 # gevaerts: in this case we expect normal behaviour and rockbox does something odd 12.24.39 # Jaykay: "normal" and "odd" are both subjective. I'd expect it to keep playing... 12.25.27 # so I think that while some people might think it's odd, it's not a bug, and if you want different behaviour that's a feature request 12.25.32 Quit mikroflops (Read error: 54 (Connection reset by peer)) 12.25.40 Join mikroflops_ [0] (n=yogurt@217-208-157-242-no112.tbcn.telia.com) 12.25.44 # gevaerts: i guess because you know how the buffering works. a user doesn't know this, and thinks the file doesn't exist anymore, and wonders how rockbox is still able to play the non-existent file 12.26.47 # Jaykay: for lots of people, the way our playlist system works is odd. Shall we drop playlists and expect people to manually select the new track to play every time? 12.26.55 # Again, "odd" is not a bug 12.26.56 Quit Lss__ (Read error: 104 (Connection reset by peer)) 12.27.10 # how is our playlist system odd? 12.27.30 Join Lss [0] (n=Lss@cm17.delta75.maxonline.com.sg) 12.27.35 # gevaerts: but expected behaviour != shown behaviour is a bug 12.27.41 # Jaykay: expected by who? 12.27.50 # by users 12.28.07 # Jaykay: I think that is *documented* behavior, hence it's not a bug 12.28.08 # technicaly inexperienced users 12.28.14 # Users also expect avi files to work. Is that a bug? 12.28.44 # kugel: make rockbox freeze on boot, document it, and call it "expected behaviour" 12.29.03 # Jaykay, i don't realy see your point here 12.29.26 # gevaerts: then they expect too much. but this just a different behaviour 12.29.30 # what you just proposed would "break" rockbox, therefore it would be a bug, not a documented feature ;) 12.29.40 # Jaykay: it wouldn't be a bug then indeed. In that case we officially declared rockbox unusable. that's nothing you can file a bug for 12.30.19 # unless you didn't do it on purpose 12.30.28 # the chain goes like documented -> intended -> not a bug 12.31.56 # kugel: then document every bug and close the reports.... for me that doesn't make sense 12.32.23 # this is not a bug 12.32.28 # it's intended 12.32.59 # i just thought that, if just a small change is needed to make rockbox show the behaviour the user expects, why not make this small change? 12.33.13 # kugel: then explain why this is intended 12.33.17 # we are the users, and it is the behaviour we expcet 12.33.24 # just because *you* expect it, doesn't mean everyone does 12.33.49 # for me it's perfectly reasonable the file continues playing 12.34.04 # Horscht: even if it shouldn't exist anymore? 12.34.04 Join mikroflops [0] (n=yogurt@217-208-157-242-no112.tbcn.telia.com) 12.34.12 # it doesn't 12.34.22 # the user just deleted it... 12.34.33 # I may have deleted the file, but I didn't clear my buffer, did I? 12.34.40 Quit mikroflops_ (Read error: 104 (Connection reset by peer)) 12.34.46 # does the user know anything about buffering? 12.34.48 Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) 12.34.52 # well, yes 12.34.59 # Jaykay: yes - we're the users, and we know about it 12.35.19 # ok, do most users know much about buffering? 12.35.35 # you're not asking the right question - the question is "do we care?" 12.35.37 # yes 12.35.57 # i'd say the majority of users knows about buffering 12.37.07 # Horscht: wow. imo thats just plain wrong. how should a user know this? 12.37.21 Quit bianca ("CGI:IRC") 12.37.27 # common sense? 12.37.47 # looking at the buffering screen for example. I think most people have had a short look at it at least 12.37.51 # note: I *am* a plain user. Not a developer! 12.39.12 Join watto [0] (n=watto@193.203.81.165) 12.39.25 # Jaykay: this is intended behavior. that's a fact, not an opinion 12.41.15 # kugel: shouldn't rockbox be intuitive to use? 12.41.46 # "intuitive" is subjective again 12.42.01 # Horscht: so you really think the majority of usrs know how buffering works...? 12.42.10 # yes 12.42.53 # I do think too that it is a bit odd, but also perfectly explainable and harmless and I don't consider it a real bug 12.45.04 # kugel: this behaviour is not documented btw 12.46.35 # it should be then. I admittedly haven't looked, but someone said it was (hence "I think it is documented...") 12.47.57 Quit pamaury ("exit(*(int *)0 / 0);") 12.49.59 # ok, maybe i'll open a new task for the missing documentation in a few minutes, if everyone here agrees that this is the behaviour a user expects. 12.50.35 # is it possible that rockbox buffers a 5mb-file in about 2 seconds? 12.51.05 # I would imagine so 12.51.35 # * Jaykay does a test with a bigger file 12.51.47 # If I unlink a file on UNIX, I can expect that any open file descriptors to that file will remain unaffected by the file being deleted. 12.51.52 # " if everyone here agrees that this is the behaviour a user expects." <- Again, that is not the question 12.52.00 # In my opinion this is expected behaviour. 12.52.24 # It is both expected and unexpected, depending on who you are 12.52.27 # rvvs89: how many % do use unix...? 12.52.30 # and on windows you'd simply be unable to delete it 12.52.36 # Either way, it is intended and therefore not a bug 12.52.46 # And in this case it is the correct behaviour 12.53.24 # Jaykay: You were asking for a consensus on what is expected behaviour, I am providing my opinion. 12.53.38 # And I'm not sure where you would document it 12.54.12 # If we stick every little thing in the manual that some people may or may not expect or know, it is going to get even more huge than it already is 12.54.17 # the point is it doesn't really matter what the consensus is. Rockbox is developed by and for it's developers. We always reserve the right to say "this is the way it works, and if you don't like it - well, sucks to be you" 12.55.26 # AlexP: imo the manual is for documenting rockbox' behaviour, and this belongs to it 12.55.37 # I disagree in this case 12.55.40 # Jaykay: feel free to submit a patch for the manual then 12.55.57 # And the how many % use unix is completely irrelevent 12.55.58 # I suspect that the majority of users do not consider deleting music they are currently playing. 12.56.13 # rvvs89: it's a very edge case indeed 12.56.14 # GodEater: i'll report a bug instead, ok? :) 12.56.16 # Should we make Rockbox behave exactly like Windows by that reasoning? 12.56.20 # AlexP: I think it's fine to document behavior if it's not clear to everyone 12.56.22 # Jaykay: It isn't a bug 12.56.30 # kugel: I agree to an extent 12.56.30 # Jaykay: no, if you want the manual change, then write the change. 12.56.48 # kugel: I'm just saying that we can't go down that road ad infinitum 12.57.10 # GodEater: if i find a bug, i'll report a bug. if it's not a bug, i won't 12.57.11 # that would require questionable behavior everywhere 12.57.22 # kugel: There are always things that aren't clear to everyone, and it is a trade off between listing them and having something readable 12.57.31 # kugel: Yes, which there is (to someone) 12.57.45 # I don't think so 12.57.51 # jesus 12.58.03 # Try and follow the logical argument 12.58.09 # anyway, I think this specific bit should be documented 12.58.51 # We can cover it pretty easily : Rockbox tries to be POSIX compliant. For what this means, please refer to the POSIX standards. 12.59.05 # * kugel didn't know that 12.59.06 Join zMastaa [0] (n=windows7@host86-147-92-59.range86-147.btcentralplus.com) 12.59.29 # (caveat: where it makes sense for a DAP OS to be POSIX compliant at all) 12.59.30 # :D 12.59.37 # Jaykay: Incidently, a patch here would be a piece of piss 12.59.53 # AlexP: assuming you can think of a good way to write it. 13.00.22 # AlexP: i don't understand what you mean 13.01.05 # Jaykay: Find where delete in the context menu is described then have \note{If the file that you have just deleted is currently buffered in the dap memmory, then it will not be removed and will still play. It has however been deleted from disk.} 13.01.15 # Jaykay: piece of piss = trivially easy 13.01.31 # ah, ok 13.01.39 # * kugel would word it differently 13.01.39 # s/memmory/memory 13.01.47 # kugel: well, whatever 13.01.52 # :) 13.02.09 # kugel: That was an example off the top of my head. Feel free to do it - you are the one that thinks it should be documented, not me 13.02.44 # may i report it as a bug with a patch? because bugs get closed faster than patches :) 13.03.12 # no 13.03.20 # If you have a patch, it is a patch :) 13.11.37 # AlexP: but it's also a bug with a fix :D well, ok, i'll maybe do it later 13.12.08 Join Horschti [0] (n=Horscht2@xbmc/user/horscht) 13.14.35 Quit Xerion (Read error: 54 (Connection reset by peer)) 13.16.26 # Jaykay: It is just the wording that is a bit tricky - you need to find something concise 13.16.55 # so, as the devs expect different things as the users, is it expected that a deleted file plays up to a certain point, then stops (i think at the point where it stopped buffering) and that it's not possible to start any track after this? 13.17.17 # First bit yes, second bit no 13.17.23 # * Jaykay thinks that just skipping a track which gut deleted would be much easier :D 13.17.34 # What do you mean by not possible to start a track? 13.17.43 # You click on it and nothing happens? 13.17.48 # If so, then that is a bug 13.17.49 # the wps shows, but the track doesn't play 13.17.58 # That does sound like a bug to me 13.18.09 # Does the deleted file have to be semi-buffered? 13.18.28 # i.e. if it is all buffered and it completes, then everything is fine 13.18.30 # ? 13.18.31 # AlexP: what would be the alternative? 13.18.42 # erm, wait 13.18.42 Quit Horscht (Read error: 60 (Operation timed out)) 13.19.29 # ...that would be normal playback... why should this happen? but i'll test it 13.19.43 # and shutting down needs ~15s after this 13.20.00 # No, I mean that if you deleted a file that was fully buffered then you can start new tracks as normal 13.20.19 # aaah, ok, wait 13.20.20 # i.e. the bug only appears when the system tries to buffer the remaining part of a file that is no longer there 13.21.15 # how big is the buffer on a e200? 13.21.41 # v1 is 32 MB, so ~£) MB ish I'd guess 13.21.46 # er, ~30 13.22.06 # ok, thanks 13.23.24 # is the already played part of a track immidiately deleted from the buffer? 13.24.03 # no 13.24.22 # when is it deleted? on rebuffering? 13.24.42 # it's overwritten by the next rebuffer. and in some cases the old buffer is used when skipping backwards 13.26.53 Join arohtar [0] (n=faemir@78.33.109.163) 13.28.01 Quit arohtar (Client Quit) 13.28.21 Join arohtar [0] (n=faemir@78.33.109.163) 13.29.11 Quit faemir (Nick collision from services.) 13.29.14 Nick arohtar is now known as faemir (n=faemir@78.33.109.163) 13.30.06 Join sampattuzzi [0] (n=sam@88-106-164-225.dynamic.dsl.as9105.com) 13.30.36 # I'm getting compile errors with rockbox. It's the first time I try compiling and I'm not sure what is wrong, 13.31.36 # http://pastebin.org/68118 13.32.00 # Could anybody please tell me what dependencies I'm missing (if any)? 13.32.57 # AlexP: if the deleted file was fully buffered, playback continues as normal. 13.51.45 Join FlynDice [0] (n=FlynDice@65.74.4.35) 13.53.30 Quit BHSPitLappy (Read error: 60 (Operation timed out)) 14.09.22 *** Saving seen data "./dancer.seen" 14.09.28 Join Grahack [0] (n=Grahack@ip-222.net-82-216-222.rev.numericable.fr) 14.09.44 Quit zMastaa (Read error: 60 (Operation timed out)) 14.09.59 Join zMastaa [0] (n=windows7@host81-155-77-229.range81-155.btcentralplus.com) 14.22.55 Quit pixelma (niven.freenode.net irc.freenode.net) 14.22.55 NSplit niven.freenode.net irc.freenode.net 14.22.55 Quit ps-auxw (niven.freenode.net irc.freenode.net) 14.22.55 Quit parafin (niven.freenode.net irc.freenode.net) 14.22.55 Quit bzed (niven.freenode.net irc.freenode.net) 14.24.18 NHeal niven.freenode.net irc.freenode.net 14.24.18 NJoin parafin [0] (i=parafin@paraf.in) 14.24.18 NJoin ps-auxw [0] (n=arneb@dyn37.ps-auxw.de) 14.24.18 NJoin bzed [0] (n=bzed@devel.recluse.de) 14.24.18 NJoin pixelma [0] (i=quassel@rockbox/staff/pixelma) 14.30.24 Join n1s [0] (n=n1s@rockbox/developer/n1s) 14.38.14 Quit zMastaa (Remote closed the connection) 14.38.27 Join zMastaa [0] (n=windows7@host81-155-77-229.range81-155.btcentralplus.com) 14.40.33 Quit einhirn (Read error: 54 (Connection reset by peer)) 14.52.22 Quit n1s (Read error: 60 (Operation timed out)) 14.53.17 Join ZincAlloy [0] (n=d9eeee2b@giant.haxx.se) 14.56.28 Quit stoffel (Read error: 60 (Operation timed out)) 14.59.21 Nick dys` is now known as dys (n=andreas@krlh-5f735889.pool.mediaWays.net) 15.00.02 # hi everybody. somebody put my Slick-Bushfire theme onto the h300 theme site, although its license is not compatible with CC-BY-SA. could somebody take it off, please? 15.03.04 # ZincAlloy: don't you want to relicense it? 15.04.03 # I can't. The background image is licensed cc-by-nc 15.07.49 Join n1s [0] (n=n1s@rockbox/developer/n1s) 15.09.12 # ZincAlloy: Will do 15.09.31 # AlexP: thanks a lot! 15.10.46 # ZincAlloy: Could you PM me your e-mail address? Just to double check it with the submission one :) 15.16.04 Quit zMastaa (Remote closed the connection) 15.16.18 Join zMastaa [0] (n=windows7@host81-155-77-229.range81-155.btcentralplus.com) 15.16.29 Quit kugel (Read error: 60 (Operation timed out)) 15.17.36 # ZincAlloy: Sorry, I misunderstood - I see now he has taken your -NC theme and put it on there 15.18.00 # exactly. 15.18.19 # arbox widgets and hazzard have the same issue 15.18.36 # OK, Slick-Bushfire has gone, I'll remove those others too 15.18.56 Join DerPapst [0] (n=DerPapst@91-64-221-175-dynip.superkabel.de) 15.18.57 # and free state as well 15.20.45 # OK, they are all gone 15.20.52 # thanks a lot 15.21.03 # No worries, we want to respect licences :) 15.21.24 # He has submitted loads though, I bet there are similar issues for other targets 15.22.33 # there are some far worse issues on the theme gallery.. 15.23.16 # like itunes 0.1 for e200 15.24.10 # can you arbitrarily relicence gpl to CC-SA-BY ? 15.24.55 # sampattuzzi: can you post the output of running configure as well? 15.30.20 Quit ZincAlloy ("CGI:IRC") 15.30.24 Join ZincAlloy [0] (n=d9eeee2b@giant.haxx.se) 15.33.03 Quit Sajber^ (Read error: 54 (Connection reset by peer)) 15.39.09 Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) 15.45.14 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 15.53.51 # amiconn: that xor variant of bitrev is indeed ~0.5% faster on pp 15.54.12 # eh vorbis decoding is 0.5% faster 15.56.34 # ... for medium bitrates, and about 1% on higher bitrates so worth it imo 15.57.40 Join StealthyXIIGer [0] (n=stealthy@69.216.113.160) 16.01.37 # http://pastebin.org/68147 16.01.47 # GodEater: ^^ 16.02.05 Quit ZincAlloy ("CGI:IRC") 16.04.09 # AlexP: depends on if you hold the copyright 16.04.19 # in which case you do whatever you like 16.05.36 # sampattuzzi: Clearly, but in this case they don't 16.06.37 # Should we not just close FS#10872 and be done with it? It scraps anything other than latin alphabet left to right text so is never going to go in 16.07.15 # AlexP: Does it _actually_ scrap their ability to be used, or does he just think it does? 16.07.30 # Llorean: I'm just going on what he said 16.07.32 # I haven't tried it, but I'm having a hard time understanding from his descriptions what exactly he's doing that would make RTL impossible. 16.08.15 # Is it that it would make other font use impossible as a whole? 16.08.27 # sampattuzzi: that's very odd output you're getting there from your compile attempt 16.08.31 # configure looks like it worked fine 16.08.36 Join kugel [0] (n=kugel@rockbox/developer/kugel) 16.08.43 # GodEater, seemed that way to me too 16.08.55 # sampattuzzi: which platform are you building on? 16.09.25 *** Saving seen data "./dancer.seen" 16.11.32 # GodEater, Ubuntu 16.11.55 # and you say this is the first time you've ever tried building rockbox? 16.13.06 # yes but I built the UI testing build 16.13.21 # * GodEater has no idea what that means 16.13.35 # the simulator 16.13.40 # ah right 16.13.43 # in the same directory 16.13.44 # ? 16.14.30 # GodEater, nope, don't think so 16.15.00 # and rockboxdev.sh ran ok? 16.15.16 # I might try running that again 16.15.43 # I'm pretty sure it worked first time though 16.16.11 # this doesn't look like a rockboxdev.sh failure 16.16.32 # which files do you have in build-dir? 16.17.05 # ls 16.17.05 # apps autoconf.h firmware make.dep Makefile 16.17.37 # try removing them all and then start again 16.19.08 # It's getting further now 16.19.19 # thanks GodEater and gevaerts 16.19.31 # you're welcome 16.21.37 # n1s: C or asm? 16.25.56 # * amiconn thinks that asm allows some further shifter trickery that gcc certainly won't do 16.26.13 # amiconn: pure C for armv4 i did two lines on inline asm, one for coldfire, and one for armv6 16.26.43 # since gcc messes up badly for coldfire and just misses the rev instruction on armv6 16.28.39 # amiconn: oh? 16.32.10 Quit StealthyXIIGer (Connection timed out) 16.38.43 Join jon-kha [0] (i=jon-kha@kahvi.eu.org) 16.43.55 Quit elcan (SendQ exceeded) 16.45.45 Quit rphillips ("reboot") 16.53.43 Quit n1s ("Lämnar") 16.53.57 Join n1s [0] (n=n1s@rockbox/developer/n1s) 16.54.51 # amiconn: this is wat i came up with http://pastebin.ca/1724927 a small speedup on coldfire too, no real difference on the beast 16.55.37 Join liar [0] (n=liar@83.175.83.185) 17.01.06 # * amiconn wonders what that compiles to on arm 17.02.08 Quit kugel (Read error: 60 (Operation timed out)) 17.10.02 Join rphillips [0] (n=rphillip@66-90-184-91.dyn.grandenetworks.net) 17.15.45 Join Sajber^ [0] (n=Sajber@211.142.216.81.static.tab.siw.siwnet.net) 17.17.02 Join ifonefox [0] (n=irchon@mobile-166-137-136-159.mycingular.net) 17.18.46 Quit ifonefox (Remote closed the connection) 17.20.28 # amiconn: this when compiling with O2 for arm7tdmi http://pastebin.ca/1724963 17.22.03 # interesting thing is that m68k-gcc only goes mad when specifying a coldfire target, when compiling for a regular m68k it just generates the swap directly 17.25.21 Join Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) 17.27.39 Join pamaury [0] (n=pamaury@sal63-1-82-243-96-220.fbx.proxad.net) 17.30.48 # i guess i should test a new gcc and report a bug if this is still done 17.35.34 Quit Jaykay (Read error: 110 (Connection timed out)) 17.47.46 Join Jaykay [0] (n=chatzill@p5DDC6C5D.dip.t-dialin.net) 17.58.48 Join stoffel [0] (n=quassel@p57B4D2FE.dip.t-dialin.net) 18.00.37 Join b1uebrother [0] (n=dom@92.117.112.218) 18.02.08 Quit Xerion (" ") 18.08.26 Join jae [0] (n=jae@HSI-KBW-091-089-249-155.hsi2.kabel-badenwuerttemberg.de) 18.09.28 *** Saving seen data "./dancer.seen" 18.12.56 # Hmmm... I'm on Win7 and, trying to update my Fuze, get "Target mismatch detected. Installed target: sansafuze, selected target: Sansa Fuze (Unstable)" 18.13.59 # Is that due to a more recent change, or due to using autodetection (which didn't work back on WinXP, but that was pre-24000 ;-)? 18.15.36 # jae, there have been some target renames recently indeed, this could explain your problem, but I'm not completely sure 18.15.45 # Installed version is r23894 :D 18.16.03 # * jae goes and checks SVN logs 18.16.47 Join AaronM [0] (n=Aaron@adsl-250-8-242.bhm.bellsouth.net) 18.17.39 # Anyone got an idea why I can't switch machines with synergy when rbutilqt is up (Win7)? 18.19.02 Quit petur ("work->home") 18.19.08 # New commit by 03bluebrother (r24101): Rename player sections to match the platform section. ... 18.20.13 Join toffe82 [0] (n=chatzill@ppp-71-142-15-73.dsl.frs2ca.pacbell.net) 18.20.32 # jae: yes, that's caused by target renames. The next version of Rockbox Utility will be adjusted to that 18.20.58 Join merbanan [0] (n=banan@c-94-255-209-233.cust.bredband2.com) 18.21.10 # synergy as in synergy2.sf.net? 18.21.55 # Yes, as in that 18.23.57 # no idea what's the problem, but I might give it a try some time later. 18.24.27 # * b1uebrother wonders if it would be possible to try that using a vm 18.25.25 # rbutilqt doesn't have to be visible, just has to have input focus 18.26.18 # does that issue also appear on wxp? 18.26.44 # Haven't noticed it there (so probably didn't), but not sure, will check later 18.26.57 Quit Hillshum (Read error: 60 (Operation timed out)) 18.38.55 # * jae is really weird... 18.39.21 # Apparently, since setting a different cache directory doesn't work... 18.40.29 # I get a "Mountpoint does not exist"... even though I did create the directory (okay, externally, since the selection dialog doesn't (for some reason) have "Create directory" option) 18.41.24 # what would be the point of creating a mount point from within rbutil? 18.42.03 # I'm trying to pinpoint which revision a bug occurs in for better debugging. Is there a faster way of compiling or some tips for doing this? 18.42.09 # Hmm, news to me that Win7 has mount points... 18.43.56 # gevaerts: so how *do* you change the cache path? Or: what do I miss? 18.44.27 # sampattuzzi: ccache can help a lot. Also, if you're looking for a bug in the core (i.e. not a codec or plugin thing), just "make bin" will be enough (codecs or plugins might then not work properly though). Also, are you doing a binary search over revisions? Going back one by one is slow 18.45.12 # jae: hm, sorry. I probably misunderstood what you were seeing. The cache selecting dialog could indeed use a create option 18.45.38 # gevaerts, I'm trying some revisions I think might have caused it first then I will do binary search. 18.45.50 Join bluebroth3r [0] (n=dom@92.117.43.76) 18.46.00 Join Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) 18.46.10 # that seems sensible enough 18.47.17 # jae: you have problems with mountpoint or cache path? 18.48.44 # gevaerts, how do I know which revision was the official release? 18.49.13 # bluebroth3r: Cache path... trying to set it gets me the mountpoint message (OS is Win7 x64) 18.49.49 # sampattuzzi: the official releases are on a different branch, so if you're just looking at trunk you won't get those anyway 18.49.49 # Hunting a daily build of rbutil to check, my installed version is 1.2.3 (r22749) 18.49.58 # hmm. Maybe there's something up with 64bit? There have also been reports in the proxy settings not working correctly on 64bit linux 18.50.07 # gevaerts, ok thanks 18.50.15 # jae: there are no daily builds of Rockbox Utility 18.50.30 # sampattuzzi: apart from that, 3.4 branched at r22748 18.50.39 # bluebroth3r: I feared as much ;) 18.50.56 # there's an svn build from some days back here: http://www.alice-dsl.net/dominik.riebeling/rockbox/ 18.51.49 Quit b1uebrother (Read error: 60 (Operation timed out)) 18.53.29 # Thanks... oops, gone 18.53.44 # he's not :) 18.53.58 # Interesting message "Your configuration is invalid. This is most likely due to a change device path." 18.54.15 # Sounds to me like it really doesn't like that path to change at all ;) 18.54.44 Quit sampattuzzi ("Ex-Chat") 18.54.48 # Oh, yeah, that was another brother :D 18.55.28 # yeah, I'm split personality ;-) 18.55.40 Quit HBK (Read error: 110 (Connection timed out)) 18.56.36 # Okay, reporting bug... as it doesn't even let me set the *previous* default. 18.57.16 # (Which was "Users\jae\AppData\Local\Temp"... it complains with that mountpoint nonsense) 18.58.02 # I guessed you checked the mountpoint? It also needs to be writeable. 18.58.49 # can you post the system trace (from About / Troubleshoot / System Trace) somewhere? 18.59.45 # Oh, and despite the error message, it seems to actually take the value anyway 18.59.57 # Lemme try to download a theme or five 19.02.50 # Gets weirder... I *do* have data in the previously empty directory... (AppData\Local\Rockbox, new dir rbutil-cache, some hex-named file that could be the compressed theme I "tried" to d/l) 19.03.21 # But it *did* complain with "Mount point is wrong!" 19.03.47 # Ooops. 19.05.06 # Good thing I haven't yet logged a PR 19.05.26 # New commit by 03nls (r24102): Improved bitrev with approach suggested by Jens Arnold, gives 0.5%-1% speedup for tremor decoding on sansa c200 (PP) and a tiny speedup on coldfire as ... 19.05.32 # Problem was... the messages 19.06.12 # I didn't expect the config to not work when the player isn't connected. Which it wasn't. 19.06.42 # And the theme installer error... well, "Mount point is wrong" is just wrong if the player isn't connected at all 19.07.02 # It should better say "Mount point is wrong or player isn't connected" 19.07.14 # well, if the player is not connected then the drive letter assigned to the player doesn't exist. Which makes the mountpoint invalid :) 19.07.37 # Or reversed order if the player *had* been connected in the past 19.08.04 # bluebroth3r: are you, by any chance, a mathematician? (CS student works just as well... ;) 19.08.47 # the main problem is that the user can enter anything into the mountpoint input box. I'd really like to move that to some "experts" view, but for that to work the autodetection has to get more reliable. Which it currently isn't ... 19.09.24 # jae: no, I've studied electrical engineering 19.09.44 Join StealthyXIIGer [0] (n=stealthy@69.216.113.160) 19.10.24 # jae: How can there be a right mount point if the player isn't connected? 19.10.47 # Or rather, how can "mount point is wrong" be incorrect if the mount point *is* wrong? 19.11.24 # But it wasn't... 19.11.30 # It was. 19.11.47 # Well, we can split hairs over that bit of semantics all night long. Not that it would have any beneficial effect... 19.11.51 # How can you have the correct mount point for a player that's not mounted? 19.12.42 # jae: well, I agree that the error message could be better, but as soon as you disconnect a removeable drive it doesn't have a drive letter assigned anymore, and there is no guarantee that reconnecting it again will yield it getting the same drive letter 19.13.00 # the same is true for mountpoints on linux and OS X. 19.13.19 # so in this case we need to consider the mountpoint as wrong. We simply can't rely on the OS here. 19.13.31 # bluebroth3r: that bit with that changing path/driveletter is true 19.13.37 Join Casainho [0] (n=chatzill@87.196.10.255) 19.14.05 # I'm confused though. Why were you pointing it at a device that wasn't connected and expecting it to work? 19.14.08 # I fought (successfully) with udev this last week to get it assign a persistent /dev to the fuze 19.14.31 # (complicated a bit by the external microSD being an additional drive...) 19.14.46 # Llorean: I wasn't at any one time 19.14.59 # so, displaying something like "Mountpoint wrong. Check if the player is connected and is mounted / assigned a drive letter" might be an idea. 19.15.06 # jae: "(12:06:08 PM) jae: I didn't expect the config to not work when the player isn't connected. Which it wasn't." 19.15.24 # "the config" == "the configuration dialog" 19.15.41 # Doesn't that include pointing it to the player? 19.15.45 # completely detecting the player upon startup would be really nice and completely "fix" such issues, but autodetection still isn't good enough. 19.15.53 # I was changing the cache path, and got a weird error that had (apparently) nothing to do with what I changed 19.16.28 # It does include it, yes... and since it's one dialog with one OK button, it has to check the whole config when this is clicked 19.16.42 # I've realized that by now 19.16.49 Join Hillshum [0] (n=hillshum@75-165-229-121.slkc.qwest.net) 19.16.50 # no, it does not. The problem is that when clicking "ok" all values are checked, and apparently some other value became invalid ;-) 19.17.10 # bluebroth3r: That is a problem. The rbutil settings shouldn't be impossible to change without a device attached 19.17.22 # * bluebroth3r really needs to find time to work on autodetection ... and the GUI ... and the configuration ... :o 19.17.42 # They aren't... it did accept the cache path change, it just threw a (seemingly) weird error 19.17.47 # Llorean: well, when should those values get checked instead? 19.18.14 # bluebroth3r: Only when values on that tab are changed, or when you attempt to start an install? 19.18.17 # If it could/can detect which values were *changed*... and only check those? 19.19.14 # Llorean: well, that only defers the error. I'd prefer to give it as soon as possible. I've already thought about something like done for the TTS configuration -- display a hint inline if the value is incorrect. 19.20.03 # bluebroth3r: The problem is that it interferes with other configuration. Maybe give the error as soon as RBUtil is launched? Something like "rbutil requires an attached player to use. The previous player configuration appears to no longer be valid."? 19.20.11 # so the values that are still the defaults (like on first startup no player selection) won't get checked ever. 19.20.18 # That way people don't try to use it without a player attached. 19.20.50 # Llorean: we already give such an error on startup, it just doesn't tell anything about a connected player. 19.21.03 # Maybe change the message then. 19.22.05 # "Your configuration is invalid. This is most likely due to a changed device path. The configuration dialog will now open to allow you to correct the problem." 19.22.13 # I don't see anything that could be unclear here. 19.22.21 # Is there someone here that has free time to test a plugin I wrote to check that open is buggy due to a dircache bug ? 19.22.32 # this message also appears if the configuration is missing 19.22.38 # Dang. Thought those cache files would be usable, but it appears they aren't 19.22.54 # jae: they are :) 19.23.16 # the cache files are the files as downloaded, with the md5sum of the URL as filename. 19.24.18 # But since they 19.24.31 # svn creates a file cache.txt with the mappings 19.24.56 # but that feature isn't included in the latest release. 19.25.20 # But since they're w/o endings, they're just binary blobs to Windows. 19.25.27 # Where's that cache.txt? 19.26.09 # Or do you mean the svn version of rbutil? 19.26.21 # yes, the svn version of rbutil. 19.27.16 # it was added after the last rbutil release. 19.29.15 # hmm, rbutilqt.php returning links to download.php instead of the files makes the rbutil download dialog show up a very weird filename :/ 19.30.58 # And another one: your SVN build gives me "No themes available for the selected target" 19.31.23 # While 1.2.3 does give me themes. 19.32.18 # yes, that's a known issue. Also caused by the target renames. 19.35.48 # Would be nice if the themes dialog didn't quit after every install... yes, multi-select is possible, but not that simple to use 19.35.52 Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) 19.35.52 Quit pixelma (Nick collision from services.) 19.35.59 Quit amiconn (Nick collision from services.) 19.36.02 Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) 19.36.07 Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) 19.36.21 Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) 19.36.22 Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") 19.38.40 Join Strife89 [0] (n=Strife89@adsl-154-13-96.mcn.bellsouth.net) 19.38.50 # I just built a clip-build from svn but with compiler option -Os and the resulting build works but menu items miss their first character 19.39.04 # Ideally, the optimisation level should only affect the speed, right? 19.39.45 # Ideally, yes ;) 19.43.32 # * bluebroth3r bbl 19.43.34 Quit bluebroth3r ("leaving") 19.55.34 # Up: Is there someone here that has free time to test a plugin I wrote to check that open is buggy due to a dircache bug ? 20.00.33 # Can someone point me to how to disable that stupid Sansa-side database refresh? I know I've seen it before, but for the life of me, I can't find the info anymore. 20.01.59 # I think it's in the SansaFAQ wiki page or something like that 20.04.02 Quit toffe82 (Read error: 104 (Connection reset by peer)) 20.06.01 # Ouch. Thanks, yes, that's it... and I'm stupid. 20.06.44 # bertrik: speed and size but yeah ;P 20.06.51 # Or maybe it isn't? Doesn one of these work for the Fuze? 20.08.00 # n1s: speed and/or size 20.08.41 # jae: it will *very* rarely only affect one of them 20.09.30 # Not *another* hair-splitting session please! ;-) 20.09.33 *** Saving seen data "./dancer.seen" 20.10.15 # i though that's what we're here for :) 20.10.20 # * jae does nitpick, but he doesn't split hairs ;) 20.10.43 Join kugel [0] (n=kugel@rockbox/developer/kugel) 20.10.45 # Actually it seems that the icon overwrites the first character. if I disable icons, it looks OK. If I enable a pointer-selector, the text does shift 1 icon-position to the right 20.12.26 Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) 20.16.06 # liar: is there any new progress on the ipod nano 2g flash problem? 20.17.01 # (ive used your patch successfully yesterday - but ive noticed that it is under strong discussion) 20.19.23 Join toffe82 [0] (n=chatzill@ppp-71-142-15-73.dsl.frs2ca.pacbell.net) 20.22.26 # n1s: How inefficient... 20.22.36 # sagemfreak_: TheSeven said he is going to commit it, but he wants to see some test results 20.23.53 Part watto 20.27.55 Join HBK [0] (n=hbk@rrcs-97-77-49-215.sw.biz.rr.com) 20.29.52 # liar: do you have some testbenches to prove the reliability of the patch (which i can run)? 20.30.17 Join Martin9988 [0] (n=xojolito@72.168.49.74) 20.31.59 Part Martin9988 20.40.33 Quit flydutch ("/* empty */") 20.43.25 # n1s: That's 27 instructions (excluding the bx lr) if I counted correctly. I can shorten this to 18 instructions. 20.43.45 Quit GeekShadow (Read error: 104 (Connection reset by peer)) 20.44.02 # (15 for ARMv6) 20.44.13 Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) 20.45.27 # n1s: What do you think: http://pastebin.ca/1725178 (untested, but should work)? 20.47.44 Quit stoffel (Remote closed the connection) 20.48.40 # sagemfreak_: if one of the patches in FS#10775(especially the last one) fails for you then it is unreliable 20.49.18 # liar: :-) then i will watch for any errors 20.49.58 # btw - who has experience with the usb subsystem? 20.50.07 # which bits? 20.50.37 # sagemfreak_: usb isnt working for you too? 20.50.45 # no 20.51.10 # nand writing / reading is working since ive applied the patch 20.51.39 # the ipod is detected (when i disable hid) 20.51.44 # and i can write onto the ipod but 20.52.03 # what OS are you using? 20.52.07 # after restart, the ipod is broken and itunes is needed (everything is wiped) 20.52.14 # ubuntu 9.10 and 8.10 20.52.36 # havent tested windows yet 20.53.38 # but before restart everything looks fine (i can browse files and so on) - maybe the partiton information is wiped? 20.54.19 # OK. That means that hid not working is not because of an OS bug (some OSX versions can't handle it, as well as windows 2000 apparently) 20.54.21 # sagemfreak_: i have seen that too but that should be fixed with my patch 20.54.31 # no 20.54.40 # sagemfreak_: hid isnt working for me too 20.55.34 Quit dys (Remote closed the connection) 20.55.47 # without my patch the first sector of the flash gets zeroed 20.56.07 # ive applied this patch: http://www.rockbox.org/tracker/task/10775 20.56.25 # sagemfreak_: and usb with hid disabled still fails? 20.56.39 # after patching it was possible to run plugins and browse files (was not possible before) 20.57.33 Join dfkt [0] (i=dfkt@unaffiliated/dfkt) 20.57.54 # yes still fails (patch from Sunday, 20 December 2009, 22:25 GMT+1 ) 20.58.43 # is Tuesday, 22 December 2009, 00:19 GMT+1 signifficant different? 20.59.03 # sagemfreak_: no 20.59.12 # bad 20.59.32 # yesterday i had 3 devices here 21.00.12 # 2 of them can browse/start plugins without the patch and the third is needing the patch 21.00.25 # but all devices crash after usb write 21.05.32 # New commit by 03alle (r24103): Improve typesetting and fix a typo 21.08.33 # sagemfreak_: does not happen on mine 21.08.39 # sagemfreak_: could you try Friday, 13 November 2009, 00:00 GMT+1 21.09.17 # liar: which type do you use? ive used 2 8gb models. 21.09.52 # sagemfreak_: 8gb 21.10.01 # sagemfreak_: it seems like only 8GB models have this problems 21.10.39 # liar: i think so too - yesterday ive only tested 8gb models. 21.11.12 # liar: but i own a 4gb model too. first of all i will test the 4gb model with the current patch 21.12.44 # liar: how much bytes have to be saved for backup purposes (with dd)? 21.14.44 # sagemfreak_: i think only the first sector needs to be backed up, but i am not sure if it delets other sectors too 21.16.56 # liar: ok - i will copy all contents using the apple file tranfer mode. the 8gb is prepared for christmas :-) 21.17.23 # liar: so this night is the last night i will have my hands on it :-) 21.20.01 # sagemfreak_, liar, I think theseven was also quite interested in being able to distinguish between players that have different NAND behaviour 21.21.17 # sagemfreak_: can you check the return value of nand_get_chip_type? 21.21.55 # (on the nano where NAND reading/writing fails) 21.22.01 # liar: how? 21.22.37 # sagemfreak_: you have a build system installed? 21.25.04 # gevaerts: have you got a player and time to check something ? 21.25.25 # pamaury: yes. Does it matter which player? 21.27.05 # n1s: Better order (avoiding all unnecessary duplication): http://pastebin.ca/1725218 21.27.22 # liar: yes 21.27.32 # I don't think so, it has to do with dircache. I suspect open is buggy when it uses dircache. In fact, I suspect (from the code) that dircache_get_entry is buggy or too weird. I have coded a plugin which does some tests and print the results in the log. See http://pastebin.com/d5857feba 21.28.45 # gevaerts: I think that with dircache, opening a directory opens the first file within the directory instead of failing. If you can, try it with and without dirache. 21.30.57 # * gevaerts compiles 21.31.06 # sagemfreak_: put a splashf(200,"%8x",result); before the return in firmware/target/arm/s5l8700/ipodnano2g/nand-nano2g.c in nand_get_chip_type 21.31.44 # amiconn: looks very nice and should be faster on arm7tdmi i am sure, iiuc there are quite a few stalls in that for arm 11 so it would be interesting to benchmark, have you done so? 21.31.55 # no 21.32.15 # i'll do that then 21.32.39 # i guess the gain from inlining would be very small 21.32.40 # There are essentially two tricks vs. what gcc does 21.33.12 # (1) The constants are derived from their predecessors, that takes just *one* eor per stage 21.33.49 # (2) The and/eor/orr sequence pre-shifts (and corrects that for eor), saving an extra mov just for shifting 21.34.09 # very clever indeed :) 21.34.54 # The byte-swap constant isn't necessary for byte swapping on armv6, but it is used to compute the nibble-swap constant. That's 3 instructions in total - same as if I would construct the nibble constant directly 21.36.01 # amiconn: i noticed that gcc doesn't construct these constants when compiling for arm11, it just ldr's them 21.36.33 # Then it might make sense to do the same here 21.37.22 Join dys [0] (n=andreas@krlh-5f735889.pool.mediaWays.net) 21.38.09 # how many cycles is LDR on older arm? arm11 has a *lot* of one-cycle instructions (but with >1cycle result latencies) 21.38.27 # 3 cycles on ARM7TDMI iirc 21.38.43 # amiconn: would reordering help pipelining a bit on that paste? 21.40.01 # probably not 21.40.03 # amiconn: and that's throughput? it makes more sense to construct constants in that case, if they can be formed from 3 valid immediates with add/subtract etc... 21.41.23 Quit bmbl ("Bye!") 21.41.41 # n1s: a constructed constant on arm11 takes as many cycles as it takes instructions... ldr takes only one cycle, *provided* there are other instructions that can be scheduled during the result delay. that would be why the behavior changes on arm11 :) 21.42.02 # makes sense :) 21.43.14 # gevaerts: still alive or did my plugin successfully blow up you dap ;) 21.43.16 # it can make arm11 much faster, but also a bit more difficult to work on as you must be careful about not just execution times, but also result latencies, and early and late operands 21.45.20 Quit Jaykay (Read error: 110 (Connection timed out)) 21.46.27 Join froggyman [0] (n=sopgenor@pool-72-69-220-194.chi01.dsl-w.verizon.net) 21.48.43 # pamaury: still alive, doing three things at the same time :) 21.49.24 # weird 21.49.50 # ARM11 will need 6 cycles for each 4-insn sequence in this code whereas ARM7 will only need 4 21.50.25 Join relentless [0] (n=piprg@cpe-173-88-137-100.neo.res.rr.com) 21.50.32 # That is because Rm is an early reg when using fixed shifts 21.50.40 # amiconn: yeah, it needs an register that is shifted in one instr as an "early reg" 21.50.51 # Is there a way in the config file that I can make it auto maticly go to shuffle? 21.51.01 # I broke my screen, so I cant see what I am picking.. 21.51.20 # There is no useful reordering possible. Perhaps the more "classic" sequence is better on ARMv6 then 21.51.35 # (can still profit from constant deriving) 21.51.41 # relentless, you could put a set of voice files on the player so hear what you're doing 21.51.58 # Ok, but I cant turn it on 21.52.20 # IIRC, voice is on by default, you just need to put the voice files on it 21.52.26 # ok 21.52.30 # I will try that 21.53.34 # amiconn: you're referring to this? http://pastebin.ca/1725218 21.55.17 # pamaury: without dircache, "something is wrong", with dircache "open is buggy" 21.55.34 # Ok, I get the same. So open is buggy 21.55.37 # amiconn: your code seems correct as it gives the same crc as the c code but it's a little slower than when using the inlined c function so i guess i'll try to convert this to inline asm... 21.55.52 # on c200 that is 21.56.31 # gevaerts: is there a dircache expert or nobody has touched this piece of code for ages ? 21.57.37 # pamaury: you are ;) 21.57.43 # ok, I went to download the voice files and it 404'd 21.58.30 # pamaury: Slasheri is the *cache guru. i think you may already know more than anybody save him :P 21.58.53 # gevaerts: crap, I'll have to modify dircahe to fix this, but this is all due to the weird behaviour of dircache_get_entry. 21.59.21 # * gevaerts is trying to understand the test code 21.59.29 # * bertrik fixed the problem with list text being overwritten by list icons with -O3 but doesn't really understand the fix yet 21.59.37 # -Os I mean 21.59.43 Quit topik ("Changing server") 21.59.56 # gevaerts: the only interested part is the test_open. The rest is administration 21.59.59 # bertrik: can I see the diff? 22.00.01 # *interesting 22.00.36 # pamaury: didn't you swap the "This is normal" and "Hum, something is wrong (2)" strings? 22.00.45 # n1s: Optimised for ARMv6 (no stall in the logic sequence, and ldr'd first constant): http://pastebin.ca/1725261 22.01.14 # Apart from that I think it looks like you're right 22.01.42 # amiconn: cool, seems we'll have to do inline asm to beat the c function unfortunately :/ 22.01.54 # kugel, see http://pastebin.ca/1725263 , moving the const int icon_width seems to fixs the problem 22.02.23 Join Sajber^1 [0] (n=Sajber@211.142.216.81.static.tab.siw.siwnet.net) 22.02.25 # pamaury: a (possibly very) related question, how does dircache handle opening files which don't exist? 22.02.43 # gevaerts: no, This is normal if open fails to open a directory (iirc) but if it manages to open it (due to dircache bug) then it should read the text in the file !! 22.02.48 Join topik [0] (i=awesome@wtf.grmpf.org) 22.03.00 # i.e. is it possible that the file is still cached even if it has been removed? and what happens in that case? 22.03.13 # pamaury: ah, right. So the normal open is also wrong... 22.03.19 # kugel: as far as i have read the code, not very well. 22.04.06 Nick topik is now known as sark (i=awesome@wtf.grmpf.org) 22.04.09 Nick sark is now known as topik (i=awesome@wtf.grmpf.org) 22.04.25 # there's this bug that deleting a file while playing it confuses buffering. I haven't looked at the buffering code, but assuming it checks the return of open() properly, I suspect dircache on fault 22.04.49 # kugel: I have tried to break the code this afternoon and there are several cases where I think I could manage to delete/rename a file and make the cache inconsistent 22.04.56 # There's a simple solution for testing that theory - run with dircache disabled 22.07.02 # The bug I showed here is due to the fact that opening a directory with dircache will return a handle to the first file in the directory and not to the directory itself but there also are some weird behaviours when a file doesn't exist 22.09.32 # * Unhelpful glares at kugel and says something that might actually be rockbox-related :P 22.09.34 *** Saving seen data "./dancer.seen" 22.09.53 # * gevaerts doesn't understand why open() without dircache doesn't fail on a directory 22.10.10 # oh, wait 22.10.48 # Why is open() allowed on directories if it's read-only? 22.10.56 # Perhaps open manages to open the directory but can't read anything 22.11.24 # amiconn: you can get error on the order of 2^-7 on log2 with two 32x16->[47:16] and one 32x32->top32 multiply. this is fairly efficient on armv6 but i thought might be possible to to quickly on coldfire as well 22.11.44 # exactly. What's opening a directory supposed to achieve anyway? 22.12.30 # Nothing but it is allowed. But in linux there's a O_DIRECTORY option to fail if the path is not to a directory ! 22.12.44 # Perhaps to do some fcntl on it ? 22.12.54 # maybe on POSIX, but on rockbox? 22.13.01 # Ah, nothing :) 22.13.18 # It shouldn't be allowed I guess, or only to check existence 22.13.35 # But there's opendir to do it 22.13.41 # The commit message says "You can't open() a directory as a file (at least not for writing)" 22.13.49 # (r4359, LinusN) 22.13.56 # That's old 22.14.22 # Wow, that's ages ago ! What did he changed ? 22.15.02 # he added the protection against opening directories in write mode 22.15.13 # I want to know why... 22.16.15 # or at least why he allowed it for readonly 22.16.41 # perhaps it would result in undefined breakage with our drivers? 22.16.53 # I really think it's to allow open to check the existence of a directory. It could be strange if you can't open something but then opendir it. 22.17.50 # probably. But what's reading supposed to do in that case? 22.18.59 # gevaerts: i propose that reads return "you shouldn't do that." 22.19.05 # Nothing, but you have to have a mode to open it 22.21.16 # kugel: can you help me get rockbox on my mini2440? 22.21.31 # pamaury: if I change your test to RDWR, it works properly both with and without dircache. 22.21.49 # JdGordon: not sure. bob_c guided me but that's a while back 22.22.02 # did you do it in linux or windows? 22.22.07 # linux 22.22.08 # I agree that not reading anything would be cleaner, but is returning the contents of a file really a bug? 22.22.23 # the windows tools on the cd didn't work for me 22.22.44 Quit Sajber^ (Connection timed out) 22.23.36 # Well yes if you didn't open that file. 22.23.56 # What would happend if you delete that file ? No open is opened on it so it would be valid. 22.24.38 # JdGordon: I've used latest openocd (git checkout); it has some syntax changes so the files in the hg repo need a bit of changing 22.25.00 # have you got the config file that worked? 22.25.12 # Anyway, there is something unclear with dircache_get_entry which is the reason of the "bug". And there should be no different behaviour between dircahe and without dircache modes 22.25.19 # I don't know. Either read() should return EISDIR, or the results are undefined I'd say 22.25.23 # yea, I should have those 22.25.55 # can you email them please? 22.25.55 # * gevaerts notices that the test code doesn't check the return value of read() 22.26.04 # yep 22.26.05 # * JdGordon needs to figure out how to build openocd 22.26.34 # gevaerts: yes, indeed because the code is bulletprof 22.27.03 # * n1s fails at converting that asm function to inline asm 22.27.17 # JdGordon: the packages of your distros might be sufficiently up-to-date 22.27.45 # although I needed to pass 2 options to configure so that jtag-via-parport works 22.29.08 Join Jaykay [0] (n=chatzill@p5DDC6C5D.dip.t-dialin.net) 22.29.48 # Open On-Chip Debugger 0.2.0-in-development (2009-06-30-01:49) svn:r2403 22.30.26 # wait a few minutes, I'll have a look what version I used 22.30.47 # they switched to git at some point though, the svn should be out of date 22.31.48 # uh, can't you access errno from plugins? 22.32.09 # or sprintf? 22.32.28 # does rockbox implement errno? 22.32.31 # yes 22.32.34 # gevaerts: I don't think errno is accessible from a plugin which is a shame 22.32.46 # it's not a shame, it's a serious bug 22.32.59 # hm, then I wonder why some (IIRC for example lua) fake errno 22.33.06 # There should be a get_errno function in rb. 22.33.36 # or a pointer to errno as with current tick, but it doesn't really matter 22.33.58 # (although I would prefer the getter function way) 22.34.00 Join Jethro85 [0] (n=Jethro85@68-186-223-118.dhcp.cdtw.ga.charter.com) 22.38.33 Quit Grahack ("Tu m'as vu ?") 22.39.37 # kugel: people will be used to errno as a global 22.40.14 # it could be added as a #define then 22.40.41 # so #define errno *rb->errno (or rb->get_errno()) 22.41.14 Quit Jethro85 (" HydraIRC -> http://www.hydrairc.com <- Now with extra fish!") 22.41.18 # I also prefer this way, errno is a variable in people mind. 22.42.14 # on the other hand, via rb-> we can't do better than a pointer anyway 22.42.23 # errno always seemed a hack to me in C 22.42.46 # to me too 22.42.53 # does anyone want my clip+ to try getting code running on it? 22.42.57 # its already open 22.43.00 # and not very thread safe 22.44.29 # errno is clearly a hack but it's better than nothing. The greatest problem is that it's not thread safe 22.45.17 # (but it could be made thread safe with some ugly #define) 22.45.58 # I think each thread needs its own errno, at least what I remember seeing VxWorks do 22.46.18 # VxWorks ? 22.47.47 # New commit by 03alle (r24104): Describe how 'delete current file' works 22.48.06 # pamaury, it's a real-time OS, probably off-topic for #rockbox 22.48.37 # ok 22.49.14 # So do we add a errno getter in rb ? 22.49.52 Join syrou [0] (n=aramon@87.216.165.32) 22.49.52 # I think we should 22.50.03 # hi all 22.50.04 # n1s: You mean like this: http://pastebin.ca/1725322 22.50.06 # ? 22.50.07 # ah, more bugs! 22.50.46 # Why more bugs ? 22.50.51 # amiconn: yes! 22.51.00 # i'm experiencing some weird problem trying to upgrade the drive in my ihp-120 unit. can anybody please help me? 22.51.13 # obviously my failed attempt is't identical :) 22.51.31 # New commit by 03gevaerts (r24105): only get the file pointer if fd is actually valid. 22.51.35 # syrou: if you describe the problem, maybe we can :) 22.51.47 # ok thanks n1s 22.52.32 # i'm trying to use an mk1231gal drive. have recompiled with the 24105 release and upgraded the boot loader with it 22.53.04 # have tried both with or with out the MAX_PHYS_SECTOR_SIZE set to 4096 in the h120 headers 22.53.26 # but i only get a "no partition found" 22.53.31 # gevaerts: I'll add some code about errno tomorrow. I will think about this dircache issue, there is something to be fixed clearly. Did you say that there is no sprintf in rb ? 22.53.57 # gevaerts: because there is actually a snprintf 22.54.01 # iirc 22.54.08 # pamaury: exactly. I didn't look properly the first time 22.54.24 # There's no sprintf, but you don't need it if you have snprintf... 22.54.34 # indeed 22.54.55 # being a 120gb drive i suppose i don't have to activate the LBA48 support 22.55.48 # GeekShadow: we have sprintf 22.55.50 Join b1uebrother [0] (n=dom@92.116.93.154) 22.55.53 # The mk1231 doesn't need MAX_PHYS_SECTOR_SIZE afaik 22.55.53 # gevaerts: ^ 22.56.16 # While using it should work, rockbox will be slower than without it 22.56.16 # kugel: not in plugins anyway 22.56.19 # oh, that was only a test file apparently 22.56.26 # amiconn: yes, for what i've read it's firmware it's capable of mapping 4096 blocks into 512 ones 22.56.34 # * kugel didn't know firmware/test/ exists! 22.56.43 # Does anyone think that http://pastie.org/755037.txt will lead to problems? it makes read() and write() fail on directories 22.57.12 # syrou: obvious question, is there a regular primary partition on it? 22.57.34 # n1s: yes, there is a 0c FAT32L primary one 22.57.44 # It should be safe, and things still work, but you never know if there's some weird code that depends on this... 22.58.03 # and i'm using a very small ZIF to CE-ATA adapter which makes the drive spin 22.58.13 # gevaerts: the real question is: what do it returns without this ? Nothing ? 22.58.52 # syrou: did you test if the Original Firmware can read it? 22.58.54 Part toffe82 22.59.14 # hmm. Are the result codes of ipodpatcher meaningful in any way? 22.59.14 # gevaerts, existing code that fails with this, was probably already incorrect, so you're basically just making any possible bugs more visible (which is a good thing IMO) 22.59.25 # n1s: the original firm loads but it shows a single directory with garbled chars. i cannot cd into it 22.59.59 # that sounds bad... 23.00.31 # but with the zif>usb bridge, everything seems to be ok 23.04.14 # pamaury: in that case the existing code just reads, but since file->size is 0, it reads zero bytes. 23.04.39 # pamaury: so it seems that it's really dircache_get_entry_ptr() that returns the wrong file 23.04.47 # Ok. Yes 23.05.05 # In reality I traced the bug starting from dircache 23.05.30 # what i'm going to try is to zeroize the whole drive 23.05.36 # and the repartition it 23.06.08 # the drive comes from a transcend mini case, and curiously, it has the apple logo on the hard drive label 23.06.22 # maybe the apple logo means trouble? 23.08.20 # pamaury: I think I see what's wrong 23.08.42 # * gevaerts isn't sure though 23.09.08 # gevaerts: with dircache you mean ? 23.09.13 # yes 23.09.19 # gevaerts: I know what is wrong 23.09.21 # :) 23.09.25 # ah, ok :) 23.09.58 # gevaerts: It's because its goes through ->down at each iteation whereas it should not at the last one if it's a directory. That's what I believe is the bug 23.10.07 # But's perhaps there's more ;) 23.10.20 # that's what I think too, but yes, it could be more difficult 23.10.25 # * bertrik still doesn't know what is wrong with the menu text alignment when compiling with non-standard optimisation level 23.10.59 # pamaury: do you object to my EISDIR patch? It would make your test plugin meaningless 23.11.14 # amiconn: gives a speedup of 0.1% for 96kbps going up for higher bitrates to 0.7% for 500kbps on c200 over the version i committed earlier today 23.12.08 # gevaerts: I don't object, it's a partial fix but it won't fix the dircache problem. Anyway EISDIR is better than 0 size read 23.12.44 # gevaerts: the difficult part with dircache is that this ->down behaviour could be expected in other parts of dircache :( 23.12.50 # It's not a fix for the dircache issue, true. It's more of a general fix 23.13.08 # and yes, changing dircache without fully understanding it sounds risky... 23.13.26 # amiconn: on the beast it gives "Error: invalid literal constant: pool needs to be closer" though 23.13.39 # New commit by 03gevaerts (r24106): Make read() and write() return -1/EISDIR on directories 23.14.18 # gevaerts: but my test plugin will still fail with dircache: it will read the buggy.txt file 23.14.29 # ah, yes 23.15.37 # pamaury: regarding your (much?) earlier comment that using sector offsets for file ids breaking on defragmenting : do we care? 23.16.35 # I mean, using dircache indexes will break if the wrong file gets deleted, and so on. There will always be some sort of edge case where whatever scheme you use breaks 23.17.10 # Yes, the question is: what is best solution ? I think the sector way is quite good 23.18.18 # I think so too. It's simple, it doesn't require much RAM, and it's not as if people defragment every day 23.18.49 # yep 23.19.00 # this is about the MTP id? 23.19.03 # n1s: Then let gcc do that part: http://rockbox.pastebin.ca/1725354 23.19.38 Quit syrou () 23.20.16 # bertrik: MTP persistent unique object id, a stupid object property that is needed by windows 23.20.22 # pamaury: actually, the cluster offset is probably better. It allows bigger disks 23.20.52 # It's a 128-bit offset, so sector is not a problem :) 23.21.05 # ah, ok 23.21.17 # is this just some number that just needs to be unique for each file during one session, or does this also need to be persistent in the life time of the DAP? 23.21.28 # * gevaerts was assuming 32 bit 23.21.37 # and does MTP use it as a key to retrieve files? 23.22.28 # bertrik: persistent for object life time 23.22.43 # MTP doesn't use it AT ALL, it's getter only, totally useless 23.23.15 # but windows breaks if you don't have it? 23.23.41 # Yes. That's was my big problem this last days 23.23.58 Join matsl [0] (n=matsl@host-90-233-163-151.mobileonline.telia.com) 23.25.16 # pamaury, ok, sector number sounds good to me too in that case, but you're the expert now :) 23.25.54 Quit matsl (Read error: 104 (Connection reset by peer)) 23.26.08 Join matsl [0] (n=matsl@host-90-233-163-151.mobileonline.telia.com) 23.27.03 # amiconn: yeah, that works nicely, no speed diff on the beast so i'd say go ahead and commit :) 23.27.28 # Any speedup on PP? 23.27.46 # amiconn: gives a speedup of 0.1% for 96kbps going up for higher bitrates to 0.7% for 500kbps on c200 over the version i committed earlier today 23.28.05 # Also, did you check whether the armv4 sequence is indeed slower on armv6? 23.28.30 # no, can do that now 23.28.53 Join evilnick [0] (i=5752157c@rockbox/staff/evilnick) 23.33.09 # hrm... potentially useful for things that divide repeatedly by a fixed constant? http://en.wikipedia.org/wiki/Modular_multiplicative_inverse 23.33.42 Join Omlet [0] (i=omlet05@112.146-241-81.adsl-dyn.isp.belgacom.be) 23.33.51 # the scaler does this, but right now calculates either 1<<24 or 1<<32 / N during setup 23.34.41 # amiconn: doesn't seem to make any difference larger than measuring uncertainty 23.34.45 # the coprime-to-modulus part could be handled by factoring out powers of two from the divisor and storing an amount to shift... 23.36.24 # kugel, what it means ? 23.37.08 # GeekShadow: nevermind, bad nick completition 23.37.19 # oh ok :p 23.37.46 # it was for gevaerts so ;) 23.37.56 # you can ping me to test anything on meizu m3 23.40.38 # n1s: Did you check what gcc produces for PP from your C version? 23.42.06 # amiconn: this when compiling with O2 for arm7tdmi http://pastebin.ca/1724963 23.42.33 # That's not svn... 23.42.48 # * flyback wants his own death for xmas, too much bullshit everywhere 23.42.59 Join fdinel [0] (n=Miranda@modemcable235.127-131-66.mc.videotron.ca) 23.44.52 # n1s: An svn build produces this (inlined fragment): http://pastebin.ca/1725380 23.46.24 # ah, i just compiled the bitreverse function stand alone, which gives what i pastebinned 23.46.37 # that is a bit different 23.47.55 # it sure spends a lot of instructions to construct the masks 23.48.41 Quit b1uebrother ("leaving") 23.49.14 # It doesn't construct - it directly applies the partial masks 23.50.23 # right, i'm too tired for this, anyway what is it you want to say by showing this? 23.50.24 # :) 23.52.05 # and what it generated for the original c must have been horrid since that is a lot faster... 23.52.24 # s/that/this/ 23.52.30 # writing C that explicitly constructs masks from the previous mask would probably force it to construct or load the first mask... 23.53.08 # true that 23.53.24 # It might make things slower on coldfire though 23.53.28 Quit matsl (Read error: 104 (Connection reset by peer)) 23.53.32 # Or mips (which I cannot test) 23.53.43 Join matsl [0] (n=matsl@host-90-233-163-151.mobileonline.telia.com) 23.54.11 Join Kitar|st [0] (n=Kitarist@BSN-143-75-63.dial-up.dsl.siol.net) 23.54.13 Join saratoga [0] (i=5f4b4473@gateway/web/freenode/x-dkwvdxxfrbjhjzut) 23.54.52 # The construction is fast on arm because of the shifter operand 23.55.17 # stripwax: (for the logs) I didn't use any code to estimate the mul count in the fft, I just traced it on paper and counted by hand 23.55.25 # assuming that message before was meant for me