--- Log for 17.04.122 Server: tungsten.libera.chat Channel: #rockbox --- Nick: rb-logbot Version: Dancer V4.16 Started: 2 days and 22 hours ago 01.15.08 *** Saving seen data "./dancer.seen" 01.19.23 Quit massiveH (Quit: Leaving) 01.46.30 # <_bilgus> chris_s yeah sure enough 'SOMETHING' is setting tht flag 03.15.09 *** Saving seen data "./dancer.seen" 04.51.01 Quit Bobathan (Ping timeout: 246 seconds) 05.06.51 Join Bobathan [0] (~admin@cpe-65-29-248-157.wi.res.rr.com) 05.15.13 *** Saving seen data "./dancer.seen" 05.20.44 Join lebellium [0] (~lebellium@2a01cb04012c0900540209f176c0b0aa.ipv6.abo.wanadoo.fr) 05.26.44 Quit Natch (Remote host closed the connection) 05.37.12 Quit Bobathan (Ping timeout: 250 seconds) 05.39.01 Join Bobathan [0] (~admin@cpe-65-29-248-157.wi.res.rr.com) 06.05.11 Join MyFairJulie [0] (~MyFairJul@p579cd0f6.dip0.t-ipconnect.de) 06.21.23 # Quix: the actual "iPod Classic" are 6G and 7G, not the older ones. Later the term "Classic" was mixed up ... 06.21.59 # all Ipods up to 5.5G have a diagnostic menu. Reset the Ipod, then Select+Left. No idea about one of those real "Classic" ones, never had one. 06.22.52 # since the Ipod loads its software from disk Rockbox does the same thing: replace the stuff on disk. As such it's almost impossible to brick it with Rockbox, since you'll always have the original disk mode. 06.23.17 # no idea what you want with ripping the rom though. 06.39.01 # I want to rip it since it has extra stuff not found in a normal diagnostics mode 06.39.36 # This is an RMA unit which never had its original diagnostics mode removed. It has a bunch of expanded features, and I just want to make sure it gets preserved 06.41.05 # I just am unsure on whether or not rockbox overwrites anything with the rom, I've installed rockbox countless times and I've always assumed it wouldn't do anything to the rom 06.41.46 # I got a board a while back which was the 2nd known one to exist but right as I plugged in a hd with rockbox the iPod kept whitescreening and would never boot no matter what I did 06.41.58 # Either it died on the way to me, or rockbox did something funny 06.42.56 # Here is the iPod in question: https://www.youtube.com/watch?v=fnOIMkYJjqA 06.44.17 # Its not that I'm unfamiliar with how iPods work, I just don't know if rockbox will do anything the ROM data, since I'm going to be dumping it and using iPodFlasher to put it on another iPod 06.48.22 # I've edited roms before (compiled rockbox on my own using someone's rom flashing tool to do some sn swapping for clickwheel games, but thats another mess of a story) 07.15.15 *** Saving seen data "./dancer.seen" 07.53.47 Quit Romster (Ping timeout: 240 seconds) 07.56.17 Join Romster [0] (~romster@user/romster) 07.58.16 Quit Quix (Ping timeout: 246 seconds) 08.40.49 # rockbox would affect the bootloader 08.41.22 # which is probably part of what you call ROM 08.54.54 Join dconrad [0] (~dconrad@152.117.104.208) 09.15.16 *** Saving seen data "./dancer.seen" 10.11.31 Quit MyFairJulie (Quit: Connection closed) 10.58.29 Join amachronic [0] (~amachroni@user/amachronic) 10.58.45 # Build Server message: 3New build round started. Revision 6703f43f5c, 303 builds, 7 clients. 11.01.22 # <_bilgus> chris_s it was un-initialized memory in the viewport flags, the other existing flags set or unset explicitly my new flag did not 11.02.04 # <_bilgus> now there is a VP_DEFAULT_FLAGS define 11.09.40 # i triggered the bug last night and today tried compiling the sim with ubsan to catch it 11.09.59 # unfortunately we're so full of UB the sim won't even compile :( 11.15.18 *** Saving seen data "./dancer.seen" 11.18.51 # <_bilgus> that fits right in with it being a reasonable facsimile of targets :p 11.23.50 # Build Server message: 3Build round completed after 1505 seconds. 11.24.18 # Build Server message: 3Revision 6703f43f5c result: All green 11.37.36 # Build Server message: 3New build round started. Revision fca7b8e2ff, 303 builds, 7 clients. 11.37.55 # <_bilgus> amachronic you spent quite a while on that write up I got the high level idea I think, you want to make it a mmap compatible software layer for the native targets and hand off the inbuild one on hosted 11.40.47 # yeah, and mmap is the critical bit of glue between memory management and I/O that's needed to implement buffering. 11.41.03 # <_bilgus> it will be a file backed page cache ? does that mean it could then be snapshotted and allow faster startups?> 11.41.49 # that is a neat idea but is reading many tiny files at boot really a bottleneck for rockbox? 11.42.37 # <_bilgus> true vs a big one 11.42.44 # we'd still have to check timestamps etc. to ensure the cache wasn't out of date 11.43.10 # we could cache the FAT table in an mmap as well which'd surely help 11.43.33 # <_bilgus> I guess my only concern would be the overhead introduced by being the new middleman 11.44.57 # <_bilgus> but I imagine it would NOT be noticeable to the end user except stuff very close to not playing as-is 11.46.01 # for the buffering case it would probably be very slightly more overhead but not a lot, I imagine 11.46.25 # <_bilgus> there is already a lot so it might just shift the dynamic 11.50.02 # i/o speed is probably not a problem for playback except maybe high bitrate WAV files 11.50.20 Quit speachy (Ping timeout: 272 seconds) 11.50.30 # it's locking that concerns me 11.51.53 # <_bilgus> https://github.com/cckev/xv6-mmap 11.55.08 # that seems to be MMU based? 11.57.06 # <_bilgus> likely I think its x86 but the mmap gives a god overview of the interface 11.57.36 # Build Server message: 3Build round completed after 1199 seconds. 11.57.38 # <_bilgus> https://github.com/cckev/xv6-mmap/blob/master/mmap.c 11.57.41 # Build Server message: 3Revision fca7b8e2ff result: 304 errors 0 warnings 11.58.29 # ack, that should've been obvious. 12.01.32 # <_bilgus> tf? 12.03.08 # um, it's one of those conditional lang strings 12.08.37 # <_bilgus> I'll have to study this a bit more before I get any deeper insights 12.21.07 # Build Server message: 3New build round started. Revision 1af92e5ff8, 303 builds, 7 clients. 12.22.32 Quit amachronic (Quit: amachronic) 12.47.52 # Build Server message: 3Build round completed after 1606 seconds. 12.48.24 # Build Server message: 3Revision 1af92e5ff8 result: All green 13.15.19 *** Saving seen data "./dancer.seen" 13.27.58 Join chris_s [0] (~chris_s@ip-095-223-074-090.um35.pools.vodafone-ip.de) 13.28.55 # _bilgus: (regarding the viewports) interesting :) 13.29.14 # amachronic: *sigh* sorry about that, I thought about renaming the string, too, but totally missed the fact that it was conditional 13.30.04 # With regard to snapshots: Would that make it possible to quickly reload the state of the dircache and tagcache (in RAM)? Having both enabled (with a lot of tracks), it can take well over a minute for scanning to finish (even though scanning for each, individually, only takes a few seconds), at least, on older devices like iPods. 13.30.39 # Which is why I actually have dircache_search() always return 0 on my own players. I feel like that gives you most of the benefits of both features, but with a significantly shorter scanning time if the database's "Load to RAM" is enabled. 13.36.18 Quit chris_s (Quit: Connection closed) 14.03.38 Join speachy [0] (~speachy@40.142.4.5) 14.03.38 Quit speachy (Changing host) 14.03.38 Join speachy [0] (~speachy@rockbox/developer/speachy) 14.03.38 Mode "#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat) 14.12.25 Quit Romster (Ping timeout: 246 seconds) 14.13.50 Join Romster [0] (~romster@user/romster) 14.23.03 Join advcomp2019__ [0] (~advcomp20@user/advcomp2019) 14.26.07 Quit advcomp2019_ (Ping timeout: 256 seconds) 15.12.12 Join tchan1 [0] (~tchan@c-98-206-141-238.hsd1.il.comcast.net) 15.14.16 Quit tchan1 (Client Quit) 15.14.25 Quit tchan (Ping timeout: 250 seconds) 15.15.22 *** Saving seen data "./dancer.seen" 15.31.00 Join tchan [0] (~tchan@c-98-206-141-238.hsd1.il.comcast.net) 15.32.47 Quit tomato (Ping timeout: 240 seconds) 15.50.58 Join tomato [0] (~tomato@user/tomato) 16.33.39 Quit tchan (Quit: WeeChat 3.4) 16.46.36 Join tchan [0] (~tchan@c-98-206-141-238.hsd1.il.comcast.net) 17.15.23 *** Saving seen data "./dancer.seen" 17.31.23 # Build Server message: 3New build round started. Revision fc38cd8215, 303 builds, 8 clients. 17.32.48 Join Quix [0] (~Quix@129.210.115.225) 17.45.19 # Build Server message: 3Build round completed after 836 seconds. 17.45.23 # Build Server message: 3Revision fc38cd8215 result: All green 18.24.12 Quit lebellium (Quit: Leaving) 18.41.54 Join Retr0id8 [0] (~Retr0id@user/retr0id) 18.44.05 Quit Retr0id (Ping timeout: 256 seconds) 18.44.05 Nick Retr0id8 is now known as Retr0id (~Retr0id@user/retr0id) 18.54.10 Quit Quix (Ping timeout: 246 seconds) 19.15.27 *** Saving seen data "./dancer.seen" 19.29.54 Quit dconrad (Remote host closed the connection) 19.39.58 Join massiveH [0] (~massiveH@ool-4a5862ee.dyn.optonline.net) 20.06.15 Quit MarcAndersen (Read error: Connection reset by peer) 20.32.32 # is there a reason the database menu can't be translated? 20.34.11 Join dconrad [0] (~dconrad@152.117.104.208) 20.34.45 Join Quix [0] (~Quix@129.210.115.228) 20.38.41 Quit dconrad (Remote host closed the connection) 21.14.41 Quit speachy (Ping timeout: 256 seconds) 21.15.31 *** Saving seen data "./dancer.seen" 21.17.29 Join speachy [0] (~speachy@rockbox/developer/speachy) 21.17.29 Mode "#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat) 22.06.37 Quit Bobathan (Quit: ZNC 1.8.2+deb2+b1 - https://znc.in) 22.09.00 Join Bobathan [0] (~admin@cpe-65-29-248-157.wi.res.rr.com) 22.10.01 Quit jackie (Ping timeout: 248 seconds) 22.12.39 Join jackie [0] (~jackie@banana-new.kilobyte22.de) 22.33.07 Quit Romster (Ping timeout: 240 seconds) 22.35.00 Join Romster [0] (~romster@user/romster) 23.15.01 Quit massiveH (Quit: Leaving) 23.15.35 *** Saving seen data "./dancer.seen"