--- Log for 30.07.119 Server: hitchcock.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 1 month and 8 days ago 00.16.35 Quit ZincAlloy (Quit: Leaving.) 00.19.17 Quit paulk-leonov (Ping timeout: 250 seconds) 00.20.08 Join dys [0] (~dys@tmo-102-95.customers.d1-online.com) 00.21.45 Join paulk-leonov [0] (~paulk-leo@leonov.paulk.fr) 00.28.23 Quit pR0Ps (Ping timeout: 268 seconds) 00.30.07 Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) 00.30.11 Join amiconn_ [0] (jens@rockbox/developer/amiconn) 00.30.11 Nick amiconn is now known as Guest49930 (~jens@rockbox/developer/amiconn) 00.30.11 Nick amiconn_ is now known as amiconn (jens@rockbox/developer/amiconn) 00.30.40 Join pixelma_ [0] (marianne@rockbox/staff/pixelma) 00.30.40 Nick pixelma is now known as Guest95349 (~marianne@rockbox/staff/pixelma) 00.30.40 Nick pixelma_ is now known as pixelma (marianne@rockbox/staff/pixelma) 00.31.50 Quit Guest49930 (Ping timeout: 264 seconds) 00.31.50 Quit Guest95349 (Ping timeout: 264 seconds) 00.38.07 # does anyone know why ROLO would give me a bad checksum error? 00.38.23 # assuming that I am attempting to use the correct binary. 00.38.55 Quit lebellium (Quit: Leaving) 00.41.37 *** Saving seen data "./dancer.seen" 00.48.01 Quit Jinx (Ping timeout: 248 seconds) 00.49.59 # whats the main function in a puzzles plugin? 00.52.08 # <_Bilgus> on ROLO you mean you ARE loading the right binary? 00.55.58 # <__builtin> mendelmunkis: plugin_start() 00.57.19 # <__builtin> each puzzle is built from a set of common sources (see rockbox.c) and the puzzle code itself in src/ 00.57.52 Join Jinx [0] (~Jinx@unaffiliated/jinx) 01.06.58 Quit vmx (Remote host closed the connection) 01.08.55 # what target for the ROLO error? 01.08.59 # _builtin thanks 01.09.46 # _bilgus: speachy: on my fuze+ my tests builds will occasionaly fail with a rolo bad checksum error then work next time I try them. 01.10.23 # can't comment on that one. just fixed up some incorrect IDs causing ROLO failures on a few less-stable targets.. 01.10.35 # <_Bilgus> so like are you copying the file to the device and then ROLO picks up the new file or are you calling rolo? 01.11.21 # <_Bilgus> like going thru the menus and manually selecting the firmware 01.11.34 # I have a separate RBDIR for test builds. I'm running it from there. 01.11.50 # In other words calling ROLO 01.13.03 # <_Bilgus> hmm thats odd I could see copying it failing but if it's already on disk... thats worse 01.13.53 # <_Bilgus> could you try putting your file on the sdcard and running it from there 01.14.39 # It's intermittent a file will error and then run the next time I try with the same file. 01.15.02 # Why would an sd card change anything? 01.15.46 # It's unlikely to be hardware given as I think it followed me across devices. 01.18.27 # <_Bilgus> its a pretty simple set of prerequisites for ROLO to load the file so if bad checksum then the checksum it calculated doesn't match 01.18.44 # <_Bilgus> what causes that? bad data 01.19.23 # <_Bilgus> if its intermittent then its bad data from the file or something corrupting it 01.20.19 # <_Bilgus> I've never seen bad checksum during rolo on fuze+ clipzip i've seen it on the clip+ but that was genuine 01.20.28 # Thats what I thought. but how does bad data get uncorrupted? 01.21.24 # <_Bilgus> the read succeeds, if its at least slightly reproducible I'd put a splashf in the disk handler on re-read 01.21.44 # <_Bilgus> i'd say logf build but that is probably a bad idea 01.22.04 # why? 01.24.41 # <_Bilgus> yeah nm if it fails then you can still dump it 01.24.53 # <_Bilgus> and if not then who cares 01.29.37 Quit mendelmunkis (Ping timeout: 248 seconds) 01.29.49 Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) 01.34.57 Quit mendelmunkis (Ping timeout: 258 seconds) 01.55.01 Join pR0Ps [0] (~pR0Ps@orlnon0608w-lp130-01-70-53-103-78.dsl.bell.ca) 02.27.12 # <__builtin> hmm... looks like I may have a race condition between the sound and model code 02.27.42 # <__builtin> that would explain why the crash only occurs at high sample rates 02.29.53 # * __builtin thinks two threads might be allocating the same chunk of memory simultaneously 02.37.12 # * __builtin confirms that... disabling one of the conflicting threads eliminates the issue 02.37.55 # <__builtin> yep... the alloc function isn't reentrant 02.41.40 *** Saving seen data "./dancer.seen" 02.59.38 # malloc/free are usually prime candidates for locking 03.00.57 # <__builtin> thing is, quake rolls its own allocator 03.01.06 # <__builtin> so anything in tlsf is rendered useless 03.02.34 # <__builtin> but adding a couple of locks to zone.c isn't a bad idea, yes 03.03.32 # <__builtin> well, it looks like we have tlsf's locks disabled 03.06.22 Quit pR0Ps (Quit: Quitting) 03.06.34 # <_Bilgus> leave them that way lol 03.09.53 Join pR0Ps [0] (~pR0Ps@orlnon0608w-lp130-01-70-53-103-78.dsl.bell.ca) 03.16.10 # owdoooown 03.17.27 # <_Bilgus> sh? 03.17.35 # * speachy grumbles at his feline helper. 03.26.44 # Build Server message: New build round started. Revision 4f469e9, 280 builds, 11 clients. 03.27.25 # minor fix for the debug menu's partition dumper 03.32.53 # * __builtin is curious how the original SDLQuake managed without synchronization 03.33.05 # <_Bilgus> luck? 03.33.28 Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) 03.33.53 # <_Bilgus> or segregation... 03.34.04 # <__builtin> probably the former 03.34.21 # <__builtin> the x86 version had a bunch of weird crashes, I bet they're related 03.49.04 # Build Server message: Build round completed after 1340 seconds. 03.49.09 # Build Server message: Revision 4f469e9 result: All green 03.49.10 # Build Server message: New build round started. Revision 94109a9, 280 builds, 11 clients. 03.49.52 Quit mendelmunkis (Ping timeout: 258 seconds) 03.57.41 # <_Bilgus> well I think I got G#2167 figured out 03.57.43 # Gerrit review #2167 at http://gerrit.rockbox.org/r/2167 : tagtree add %tagtree_reload to allow hot reloading of tagnavi config by William Wilgus 03.58.31 # <_Bilgus> hopefully someone that knows more about the tagcache can tell me if its just a BAD IDEA (tm) but it seems to work pretty well 03.58.52 # <__builtin> speachy, _Bilgus: stickers should arrive at my place by this Friday. Will let you know when I ship. 03.59.33 # <_Bilgus> being able to unload the tagcache could also be used for freeing ram for emergency or in times of need but its static for now 03.59.40 # <_Bilgus> __builtin, thanks 04.00.34 # * __builtin might not be able to ship until next week, though 04.07.49 # Build Server message: Build round completed after 1120 seconds. 04.07.51 # Build Server message: Revision 94109a9 result: All green 04.32.23 # Build Server message: New build round started. Revision a89bf68, 280 builds, 11 clients. 04.33.23 # Okay, I think g#2151 is finally ready. Sanely handles HAVE_MULTIDRIVE and !HAVE_MULTIDRIVE including hotplug. 04.33.24 # Gerrit review #2151 at http://gerrit.rockbox.org/r/2151 : Make info screen properly multi-volume aware. by Solomon Peachy 04.33.50 # interestingly there are no HAVE_MULTIVOLUME targets that lack HAVE_MULTIDRIVE. 04.38.38 # at worst it's no more broken than the old code. 04.41.43 *** Saving seen data "./dancer.seen" 04.48.57 # Build Server message: Build round completed after 993 seconds. 04.49.01 # Build Server message: Revision a89bf68 result: All green 04.59.05 # <_Bilgus> speachynot even the soinys? 04.59.12 # <_Bilgus> wow 04.59.30 # <_Bilgus> speachy, not even the sonys? 05.00.19 # <_Bilgus> or the creative whatever the brick is called 05.36.37 # yeah, only the four creative bricks had MULTIVOLUME defined at all, and they all defined MULTIDRIVE too. 05.39.32 Quit TheSeven (Ping timeout: 250 seconds) 05.40.04 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 06.41.47 *** Saving seen data "./dancer.seen" 07.01.16 Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) 07.15.51 Quit mendelmunkis (Ping timeout: 245 seconds) 07.34.55 Join ZincAlloy [0] (~Adium@2a02:8108:9440:dfc:a87b:17cb:6e21:3ffb) 07.40.09 Quit ZincAlloy (Ping timeout: 276 seconds) 08.00.30 Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) 08.07.06 Quit mendelmunkis (Ping timeout: 258 seconds) 08.07.24 Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) 08.17.02 Quit mendelmunkis (Remote host closed the connection) 08.34.15 Quit TheSeven (Ping timeout: 264 seconds) 08.37.06 Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) 08.41.08 Quit mendelmunkis (Read error: Connection reset by peer) 08.41.22 Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) 08.41.51 *** Saving seen data "./dancer.seen" 08.47.21 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 08.47.56 Join petur [0] (~petur@91.183.48.77) 08.47.56 Quit petur (Changing host) 08.47.56 Join petur [0] (~petur@rockbox/developer/petur) 08.48.45 Quit mendelmunkis (Ping timeout: 272 seconds) 09.24.17 Quit dys (Ping timeout: 248 seconds) 09.53.48 Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) 09.54.46 Join ZincAlloy [0] (~Adium@2a02:8108:9440:dfc:ac3a:d114:725b:ffee) 09.59.00 Quit ZincAlloy (Ping timeout: 252 seconds) 10.04.50 Quit yosafbridge (Quit: Leaving) 10.09.23 Quit mendelmunkis (Ping timeout: 258 seconds) 10.10.26 Join yosafbridge [0] (~yosafbrid@static.38.6.217.95.clients.your-server.de) 10.13.58 Join cereal_eater [0] (b945f46a@185.69.244.106) 10.15.04 # I use a partitioned SD card in my Cowon D2 to hide files from the OF. Do the latest code changes relatet to HAVE_MULTIDRIVE etc. afffect this? 10.35.55 Join mendelmunkis [0] (~mendelmun@cpe-67-245-191-31.nyc.res.rr.com) 10.36.12 Join dys [0] (~dys@2003:5b:203b:100:a64c:c8ff:fef4:13a6) 10.40.18 # is pamaury around anymore? 10.41.52 *** Saving seen data "./dancer.seen" 10.46.33 Quit mendelmunkis (Ping timeout: 272 seconds) 10.47.35 Join TheSphinX_ [0] (~briehl@srv001.nosupamu.de) 10.48.39 Quit TheSphinX^ (Ping timeout: 276 seconds) 10.48.39 Nick TheSphinX_ is now known as TheSphinX^ (~briehl@srv001.nosupamu.de) 10.51.27 # * user890104 successfully built __builtin's sdl apps for win32 and win64 simulator 11.17.50 Quit cereal_eater (Ping timeout: 260 seconds) 11.52.36 Quit flabrus (Remote host closed the connection) 11.52.52 Join flabrus [0] (~beard@flab.tech) 11.52.52 Quit flabrus (Changing host) 11.52.52 Join flabrus [0] (~beard@unaffiliated/flabrus) 12.01.06 Join ZincAlloy [0] (~Adium@ip5f5acea4.dynamic.kabel-deutschland.de) 12.05.15 Quit ZincAlloy (Ping timeout: 244 seconds) 12.17.44 Join vmx [0] (~vmx@ip5f5ac62a.dynamic.kabel-deutschland.de) 12.34.43 Quit speachy (Remote host closed the connection) 12.41.53 *** Saving seen data "./dancer.seen" 13.02.57 Quit Jinx (Ping timeout: 248 seconds) 13.13.28 Join Jinx [0] (~Jinx@unaffiliated/jinx) 13.19.49 Quit rasher (Ping timeout: 272 seconds) 13.19.58 Join rasher [0] (~rasher@rockbox/developer/rasher) 13.28.23 Join speachy [0] (d102414d@209.2.65.77) 13.43.36 # so, it looks like an explicit HAVE_MULTIVOLUME in the presence of HAVE_MULTIDRIVE has a meaning after all -- it enables support for up to 4 volumes per disk. 13.45.31 # so I have two choices -- revert the changes to the Creative Zen configurations to re-enable that quirk, OR make it so that all targets with MULTIDRIVE get that 4-per-disk thing too. 13.46.40 # I good argument can be made either way. Personally I think that anything with removable storage should support the full 4 partitions/volumes per drive. 13.48.56 # code size in the main binary goes up by ~100 bytes on the handful of ARM targets I rebuilt, and ~250 bytes on the MIPS. (Interestingly, the zen x-fi saw a 64 byte bump, vs the 6.5KB bump on the build page..) 13.50.37 # oh, I see that number incldes RAM. nm. 14.08.51 Join massiveH [0] (~massiveH@ool-18e4e27c.dyn.optonline.net) 14.26.56 Quit speachy (Remote host closed the connection) 14.41.56 *** Saving seen data "./dancer.seen" 14.49.45 Join derp [0] (5454617c@ip5454617c.speed.planet.nl) 14.50.45 Quit derp (Client Quit) 15.11.42 Quit massiveH (Quit: Leaving) 15.17.48 Join speachy [0] (40eebded@64.238.189.237) 16.09.37 Quit michaelni (Ping timeout: 248 seconds) 16.21.52 Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at) 16.41.57 *** Saving seen data "./dancer.seen" 17.16.55 Quit petur (Quit: Connection reset by beer) 17.19.04 # <__builtin> user890104: nice! 17.37.47 Quit IncognitoMan (Ping timeout: 246 seconds) 17.38.03 # <_Bilgus> I'm still not sure why cereal_eater thinks code changes in rb would affect his OF or am I missing something about the cowond2? 17.41.01 # I think what's going on is that he's relying on rockbox only picking up one partition, so the partition with his OF is completely ignored. 17.42.06 # meanwhile I need to decide what to do about my patch changing the configs on the Creative Zens 17.42.46 # ie restore their old behavior (so only they see all partitions on all drives) or enable full multivolume for all multidrive targets. 17.43.44 # IMO the latter is the better choice. 17.43.47 # <_Bilgus> IIRC the zen has an incompatible partition I don't remember the specifics 17.44.40 # <_Bilgus> its like the OF is something funky that rb doesn't like or the otherway around 17.45.29 # <_Bilgus> https://www.rockbox.org/wiki/CreativeZENMozaicPort#Formatting_the_device_for_Rockbox 17.45.32 Join IncognitoMan [0] (~Incognito@unaffiliated/incognitoman) 17.45.44 # Well, the way it was before I committed, rockbox would see all the partitions. That is a unique setup for the Zen, and the X-Fis. 17.45.55 # <_Bilgus> Rockbox and Creative OS do not use the same file system so one cannot use both at the same time. In order to run Rockbox, you will need to reformat the internal storage as FAT. If you want to restore the Creative OS, you will need to reformat it using the recovery mode. It is strongly advised to put music on the SD card since the internal storage handling might change in the future and require formatting once again 17.46.10 # <_Bilgus> so I'd say it doesn't really matter 17.47.12 # <_Bilgus> honestly how important is multi partitions to the normal user? 17.47.50 # <_Bilgus> Fat32 supports what like ~2Tb 17.48.25 # probably not very. 17.48.59 # since one would have to go out of their way to format an SD card with multiple partitions 17.49.04 # <_Bilgus> personally I'd say chuck the multi partition in favor of code savings and make it easy enough to enable 17.50.00 # <_Bilgus> anyone savy enough to make multi partitions is savy enough to make a multi part build too 17.51.06 # <_Bilgus> though it could be argued that you might want to see multiple partitions say from an android card or raspi card but again how likely? 17.51.24 # most of the random SD cards I have lying around are multi-partitioned due to Linux boots 17.51.40 # that's how I discovered this um, quirk. :) 17.51.46 # <_Bilgus> but others might feel otherwise thats what sucks about making decisions (in a vacuum too) 17.52.23 # <_Bilgus> still do you want to be mucking with that partition in your DAP? 17.52.25 # personally I think it's worth enabling across the board, as the only real argument against it is code/ram. 17.53.10 # it concerns me that the MULTIDRIVE && !MULTIVOLUME code has somewhat bitrotted too. 17.53.25 # <_Bilgus> It doesn't really matter from the code side ram OTOH 17.54.04 # RAM is more concerning. code size is under 100 bytes. 17.54.36 # <_Bilgus> now 5k of ram from 8-64 mb is nothing but 5k from 1mb might be 17.55.00 # <_Bilgus> how many targets are multi volume and 1mb ram? 17.55.11 # <_Bilgus> I'd say 1 17.55.38 # <_Bilgus> and its probably HWcodec which we want to end support for anyways 17.56.43 # There are no MULTIVOLUME targets other than the Creative bricks. 17.57.38 # <_Bilgus> maybe if __builtin gets github access he can branch off the HWCodecs ;) 17.57.57 # <_Bilgus> sorry I meany multidrive 17.58.02 # <_Bilgus> meant* 18.00.33 Quit vmx (Ping timeout: 248 seconds) 18.28.45 Join cereal_eater [0] (b945f425@185.69.244.37) 18.31.19 Join ZincAlloy [0] (~Adium@2a02:8108:9440:dfc:910a:bca4:b792:12f6) 18.31.41 # _Bilgus: I use mainly Rockbox and sometimes the OF on my D2. All my files would exceed the file limit that the OF has. So I have all my music on the second partition of a SD card, which Rockbox can see, but the OF not. 18.36.30 Quit cereal_eater (Ping timeout: 260 seconds) 18.41.59 *** Saving seen data "./dancer.seen" 18.45.41 Join cereal_eater [0] (b945f471@185.69.244.113) 18.47.13 # Some music is on the internal storage fpr toying with flash skins, that the OF supports and on the first very small partition of the SD card is only the .rockbox folder.. 18.47.42 # So I was curious if my usecase is still possible with future builds. 18.49.13 Part cereal_eater 19.01.32 # I don't see why it wouldn't work. 19.02.08 # all of my bellyaching here is because I'm trying to fix some bugs and stumbling down rabbit holes in the process. 19.09.10 Join krabador [0] (~krabador@unaffiliated/krabador) 19.09.40 Quit krabador (Remote host closed the connection) 19.19.41 Join lebellium [0] (~lebellium@89-92-69-110.hfc.dyn.abo.bbox.fr) 19.31.01 Join krabador [0] (~krabador@unaffiliated/krabador) 20.02.16 Join MrZeus [0] (~MrZeus@2a02:c7f:70d4:cd00:6cd0:882b:9574:e719) 20.10.50 Quit dys (Ping timeout: 264 seconds) 20.42.03 *** Saving seen data "./dancer.seen" 20.57.09 Join dys [0] (~dys@tmo-108-22.customers.d1-online.com) 21.37.17 Quit krabador (Remote host closed the connection) 22.15.09 # <__builtin> user890104: push your changes and I'll review 22.15.34 # ah right, i forgot... too much $dayjob today 22.21.42 # __builtin: g#2169 22.21.44 # Gerrit review #2169 at http://gerrit.rockbox.org/r/2169 : sdl: Fixes for the SDL apps, so they support building simulator on Windows by Vencislav Atanasov 22.30.20 # <__builtin> I'll take a look later 22.35.46 Join MrZeus_ [0] (~MrZeus@2a02:c7f:70d4:cd00:6cd0:882b:9574:e719) 22.39.05 Quit MrZeus (Ping timeout: 276 seconds) 22.42.06 *** Saving seen data "./dancer.seen" 22.55.09 # <__builtin> user890104: one question. Why did you add #undef WIN32 in SDL_video.c? 23.40.17 Quit speachy (Ping timeout: 260 seconds) 23.45.11 Join reductum [0] (~weechat@cpe-104-32-77-28.socal.res.rr.com)