| 00:09:18 | | Join LambdaCalculus37 [0] (~robert@37.19.197.135) |
| 00:11:20 | LambdaCalculus37 | Anyone considering removing some other stillborn/dead code bits from the master branch? |
| 00:12:05 | LambdaCalculus37 | There's a stub of a port for the Tatung Elio TPJ-1022 in the codebase, but that port hasn't been worked on in ages and doesn't do very much at all. |
| 00:12:15 | LambdaCalculus37 | Perhaps it can be removed? |
| 00:15:08 | braewoods | LambdaCalculus37: you fixed the H300? |
| 00:19:24 | LambdaCalculus37 | Yup, it's working now. |
| 00:19:46 | braewoods | i've moved onto the gigabeats, another port that needs some polishing so it can move to stable |
| 00:20:21 | braewoods | mostly support in rbutil, it has unique requirements this port |
| 00:20:43 | LambdaCalculus37 | Way back when, I was attempting to get the Gigabeat T into the Rockbox family, since it's the same chipset as the Gigabeat S. |
| 00:20:49 | braewoods | it's odd how the port is nearly complete but no one finished the last few bits |
| 00:21:10 | braewoods | i saw that. but the gigabeat T is pretty obsolete now. not much point trying to finish that now. |
| 00:21:18 | braewoods | and rarer than the gigabeat S. |
| 00:21:34 | braewoods | i found exactly one for sale. |
| 00:21:40 | LambdaCalculus37 | True. I do have one, but its battery is completely done for. |
| 00:21:49 | braewoods | you might be able to replace the battery. |
| 00:22:00 | LambdaCalculus37 | Yeah, it's the same battery as the other Gigabeats. |
| 00:22:01 | braewoods | i found a supplier of gigabeat S batteries. |
| 00:22:19 | braewoods | not quite, the gigabeat F and S have slightly different batteries |
| 00:22:23 | braewoods | the S requires thinner battery |
| 00:22:23 | LambdaCalculus37 | Ahh. |
| 00:22:33 | braewoods | i learned that from trying to mess around with it |
| 00:23:08 | braewoods | the S is also limited in terms of storage capacity but it's still a solid all around port |
| 00:23:08 | LambdaCalculus37 | I haven't had a working Gigabeat in ages. |
| 00:23:22 | braewoods | I do, i bought one from bluebrother and some others off ebay |
| 00:23:30 | LambdaCalculus37 | I only have the iPod Video and the H320, and even there, those weren't my originals. |
| 00:24:00 | braewoods | there's several gigabeat S on ebay right now but all way overpriced |
| 00:24:04 | braewoods | $100+ |
| 00:24:23 | LambdaCalculus37 | Even common players like the iPod Classic are stupid priced! |
| 00:24:25 | braewoods | i got a few white ones at a lower price by waiting |
| 00:24:42 | braewoods | i think i can use the two i got to get a better fixed up unit |
| 00:24:57 | LambdaCalculus37 | And I would like to see how far along the iPod Classic port has come in the last 10 years! |
| 00:24:59 | braewoods | one major problem with the gigabeat S |
| 00:25:18 | braewoods | it is weird how the ribbon cable works so it's incompatible with CF adapters |
| 00:25:22 | braewoods | the common ones anyway |
| 00:25:35 | braewoods | you need an actual drive replacement |
| 00:25:40 | braewoods | adapters don't work |
| 00:25:50 | braewoods | i installed an 128GB SSD in one |
| 00:25:52 | braewoods | that does work well |
| 00:26:37 | braewoods | bilgus was able to fix some old reliability bugs with the iriver H10 i sent him |
| 00:26:39 | braewoods | briefly |
| 00:26:51 | braewoods | it was causing boot hangs on my H10 |
| 00:27:08 | braewoods | apparently it was some kind of race condition from ages past that may have impacted other PP ports |
| 00:27:13 | braewoods | but mainly appeared on the H10 |
| 00:27:15 | braewoods | for some reason |
| 00:27:19 | LambdaCalculus37 | I think I have an H10 20GB here that has a dead battery. |
| 00:27:32 | braewoods | i know what battery you can use for that one |
| 00:27:40 | braewoods | it's the same one used in the H300 and H100 series |
| 00:27:51 | braewoods | $10-20 |
| 00:27:53 | braewoods | t oreplace |
| 00:28:16 | braewoods | but the first time you do it you have to pry off the battery cover |
| 00:28:27 | braewoods | it's held in by strong adhesive |
| 00:28:41 | LambdaCalculus37 | Got tools for adhesive removal. |
| 00:28:53 | braewoods | i used some electrical tape to help keep the battery in place after that |
| 00:29:02 | braewoods | make-shift double sided tape |
| 00:29:46 | LambdaCalculus37 | I don't know if I would keep the H10 though. |
| 00:29:49 | braewoods | it works but the cable is a bit long so you need to find out a way to make it sit well when you reassemble it |
| 00:29:56 | braewoods | why? |
| 00:30:26 | braewoods | i do know the H10 works with CF mods but it doesn't run as fast as other ports do |
| 00:30:57 | braewoods | the write speed is pretty slow with the mod; like 5-6 MB/s |
| 00:31:00 | LambdaCalculus37 | Been trying to lighten the load a little bit, plus I'm not an active developer anymore. |
| 00:31:14 | braewoods | ah. |
| 00:31:21 | LambdaCalculus37 | I only really had all the players to help do testing and such. |
| 00:32:32 | LambdaCalculus37 | I still use Rockbox, and I might help out here and there still, but I don't think I'll be doing coding for the project again. |
| 00:32:50 | LambdaCalculus37 | Nothing against the project... just kinda moved on, ya know? |
| 00:33:46 | braewoods | i could always use more hardware; once i finish with this port i'm probably going to move onto USB drivers to expand the feature set available to USB software stacks |
| 00:34:21 | braewoods | one thing i'd like to do is create a remote control thing over USB |
| 00:34:24 | LambdaCalculus37 | Hey, if you'd like some of the players I have here, next time I do cleaning, I'll pull them out and set them aside for you. |
| 00:34:26 | braewoods | not quite sure how yet |
| 00:34:37 | braewoods | LambdaCalculus37: let me know what you find |
| 00:34:51 | braewoods | it would help with testing new drivers |
| 00:35:04 | braewoods | i think the main area we can still innovate is USB |
| 00:35:08 | braewoods | for older ports anyway |
| 00:35:25 | braewoods | we lack true networking so this is the next best thing |
| 00:35:39 | LambdaCalculus37 | I can tell you what I do have right now: an H10 20GB that needs a battery and cables, a GoGear SA9200, a GoGear HDD1630, an iriver H140 that has no battery or HDD. |
| 00:36:07 | braewoods | SA9200... those are pretty rare to find today. |
| 00:36:20 | LambdaCalculus37 | I don't know where the GoGear cable is, though. |
| 00:36:30 | braewoods | i have some already |
| 00:36:38 | braewoods | plus i can buy gomadic if i have to |
| 00:36:51 | LambdaCalculus37 | I also have a Sansa c240 that unfortunately had a swollen battery so I had to remove it. Can't find a replacement anywhere. |
| 00:37:28 | braewoods | is that the one with a battery cover? |
| 00:38:38 | braewoods | https://www.newpower99.com/Battery_for_SanDisk_Sansa_C200_p/sandisk%20sansa%20c200.htm |
| 00:38:41 | braewoods | found one |
| 00:38:48 | LambdaCalculus37 | Ahh! Perfect! |
| 00:38:52 | LambdaCalculus37 | Thanks! |
| 00:39:06 | braewoods | iirc, the C200 series all use the same battery |
| 00:39:39 | LambdaCalculus37 | They do. |
| 00:40:00 | braewoods | despite their limitations it does have one major advantage over the others |
| 00:40:05 | braewoods | easily removeable battery |
| 00:40:08 | braewoods | the others are all soldered |
| 00:40:34 | braewoods | i have to say the gigabeat S impressed me |
| 00:40:46 | braewoods | it was designed with ease of repair in mind |
| 00:40:56 | braewoods | no weird crap that is prone to cause damage during disassembly |
| 00:43:25 | LambdaCalculus37 | That, and also the power it had under the hood. IIRC the Gigabeat S was the first device we supported that could just about do realtime playback of -c5000 APE files. |
| 00:43:58 | LambdaCalculus37 | Plus good video frame rates in mpegplayre. |
| 00:44:10 | braewoods | kinda moot now with how codecs have advanced |
| 00:44:29 | braewoods | basically need hardware accelerations for playback to be possible on mobile |
| 00:46:11 | LambdaCalculus37 | I take that back... just about do realtime playback? Nah, it *did* realtime playback! https://www.rockbox.org/wiki/SoundCodecMonkeysAudio#Performance |
| 00:46:27 | braewoods | ah |
| 00:47:23 | braewoods | desowin has been working on finishing the Sansa Connect port. they finally found a way to inject a bootloader consistently. |
| 00:48:02 | LambdaCalculus37 | Neat! |
| 00:48:07 | braewoods | if nothing else having a new port would help with options. |
| 00:49:04 | braewoods | considering how long it's been since the gigabeat S was worked on... i'm surpised how little was broken by recent uphevel since 3.15 |
| 00:49:17 | braewoods | the only show stopper was a stack overflow in a thread stack. |
| 00:49:52 | LambdaCalculus37 | At least there's no more headache of HWCODEC targets breaking stuff. |
| 00:50:19 | braewoods | not even any LCD regressions |
| 00:50:43 | braewoods | bilgus reworked the LCD code |
| 00:51:07 | braewoods | caused a fair number of issues for awhile; thought it might be an issue here as well |
| 00:51:33 | braewoods | right now just trying to work out how to integrate with rbutil |
| 00:52:03 | braewoods | if i do implement a USB debugging driver... |
| 00:52:18 | braewoods | i'll probably need to write a library for accessing it from hosts. |
| 00:52:43 | braewoods | so it can be used by more than just a GUI application |
| 00:53:05 | LambdaCalculus37 | One last before I do, since you mentioned rbutil and I was curious about something. |
| 00:53:09 | LambdaCalculus37 | s/do/go |
| 00:53:38 | LambdaCalculus37 | What's going to happen with the macOS and 32-bit Linux builds of rbutil? I noticed that there's no build for either of 1.4.1. |
| 00:55:23 | braewoods | the 32 bit build will probably be dropped... that's the trend for Linux lately. 64 bit is the most common variant of x86 now. |
| 00:55:34 | braewoods | i can't speak for MacOS. |
| 00:56:03 | braewoods | i've been considering opening a repository for rbutil packages |
| 00:56:26 | braewoods | building rbutil isn't that difficult, at least for Linux |
| 00:57:09 | braewoods | OBS would even allow us to build for other architectures of Linux |
| 00:57:38 | braewoods | imagine being able to use rbutil from an ARM64 port |
| 00:57:43 | braewoods | like raspberry pi |
| 00:57:48 | LambdaCalculus37 | That would be pretty cool. |
| 01:00 |
| 01:00:23 | LambdaCalculus37 | But as for macOS, my only guess is unless all the necessary libraries are available on Apple Silicon, and considering Apple's development tools are getting more and more convoluted... |
| 01:00:56 | braewoods | i can't justify spending $1k+ for something just to have a testing platform |
| 01:01:03 | braewoods | windows is cheap and easily available |
| 01:01:07 | braewoods | MacOS hardware not so much |
| 01:01:08 | LambdaCalculus37 | Might end up being a case of "if you can build it, great... if not, ehh" |
| 01:01:28 | LambdaCalculus37 | Anyway, time to bounce... later! |
| 01:01:31 | braewoods | ok |
| 01:01:33 | | Quit LambdaCalculus37 (Quit: Leaving) |
| 01:29:36 | *** | Saving seen data "./dancer.seen" |
| 02:00 |
| 02:27:46 | desowin | braewoods: no need for the capture more, found my e280 |
| 02:28:12 | desowin | the difference between the two is that Sansa Connect sends the ZLP twice, and the second ZLP results in Windows resetting the device |
| 02:28:20 | | Quit TorC (Quit: Vanishing into the mist) |
| 02:29:08 | desowin | I just have to figure out what's going on with this ZLP, but considering Linux kernel had the bit define as CB_ZLP_GARBAGE, I guess there's some shenanigans with it |
| 02:29:09 | | Join TorC [0] (~Tor@user/torc) |
| 02:30:45 | braewoods | desowin: huh. |
| 02:37:12 | braewoods | g#3476 |
| 02:37:14 | rb-bluebot | Gerrit review #3476 at https://gerrit.rockbox.org/r/c/rockbox/+/3476 : mknkboot/beastpatcher: implement basic firmware validation by James Buren |
| 02:37:40 | braewoods | whoever cares to review please do so. first major improvement; validating the firmware for dual boot operation. |
| 03:00 |
| 03:26:16 | | Join p9 [0] (~p9@83.31.194.45) |
| 03:29:38 | *** | Saving seen data "./dancer.seen" |
| 04:00 |
| 04:26:42 | | Quit TorC (Ping timeout: 264 seconds) |
| 04:56:47 | | Join TorC [0] (~Tor@user/torc) |
| 05:00 |
| 05:26:46 | | Quit p9 (Ping timeout: 244 seconds) |
| 05:29:42 | *** | Saving seen data "./dancer.seen" |
| 06:00 |
| 06:01:51 | | Join Guest58 [0] (~Guest58@43.224.159.59) |
| 06:46:49 | | Quit Guest58 (Quit: Client closed) |
| 06:53:32 | rb-bluebot | Build Server message: New build round started. Revision a90ef8195b, 297 builds, 9 clients. |
| 06:56:38 | | Join p9 [0] (~p9@83.31.194.45) |
| 07:00 |
| 07:02:59 | rb-bluebot | Build Server message: Build round completed after 567 seconds. |
| 07:03:02 | rb-bluebot | Build Server message: Revision a90ef8195b result: All green |
| 07:29:46 | *** | Saving seen data "./dancer.seen" |
| 08:00 |
| 08:25:08 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 08:28:38 | | Quit p9 (Ping timeout: 244 seconds) |
| 09:00 |
| 09:18:14 | | Quit TorC (*.net *.split) |
| 09:29:50 | *** | Saving seen data "./dancer.seen" |
| 09:36:56 | | Join TorC [0] (~Tor@user/torc) |
| 09:54:56 | rb-bluebot | Build Server message: New build round started. Revision 663d846cf3, 297 builds, 9 clients. |
| 09:55:39 | desowin | hopefully this solves it, I tried messing around with the CPPI but well, without datasheet it is just a guesswork |
| 10:00 |
| 10:04:11 | rb-bluebot | Build Server message: Build round completed after 555 seconds. |
| 10:04:15 | rb-bluebot | Build Server message: Revision 663d846cf3 result: All green |
| 10:10:26 | | Quit dconrad (Remote host closed the connection) |
| 10:20:36 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 10:24:53 | | Quit dconrad (Ping timeout: 244 seconds) |
| 10:32:36 | | Join p9 [0] (~p9@83.31.194.45) |
| 10:36:34 | | Quit p9 (Client Quit) |
| 10:47:17 | rb-bluebot | Build Server message: New build round started. Revision f3f9d1fb95, 297 builds, 9 clients. |
| 10:56:22 | rb-bluebot | Build Server message: Build round completed after 545 seconds. |
| 10:56:25 | rb-bluebot | Build Server message: Revision f3f9d1fb95 result: All green |
| 11:00 |
| 11:29:54 | *** | Saving seen data "./dancer.seen" |
| 11:48:04 | | Quit pablocastellanos (Ping timeout: 244 seconds) |
| 11:54:31 | | Join pablocastellanos [0] (~pidgin@user/pablocastellanos) |
| 12:00 |
| 12:03:51 | | Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) |
| 13:00 |
| 13:29:56 | *** | Saving seen data "./dancer.seen" |
| 14:00 |
| 14:50:07 | | Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") |
| 15:00 |
| 15:17:12 | | Quit ddevault (Quit: taking a break) |
| 15:26:00 | | Join amachronic [0] (~amachroni@user/amachronic) |
| 15:30:00 | *** | Saving seen data "./dancer.seen" |
| 15:31:45 | | Quit skipwich (Ping timeout: 252 seconds) |
| 15:33:42 | braewoods | desowin: what chip is it? |
| 15:34:19 | braewoods | i sometimes can find stuff other people don't |
| 15:54:18 | | Quit amachronic (Ping timeout: 252 seconds) |
| 16:00 |
| 16:06:26 | | Join amachronic [0] (~amachroni@user/amachronic) |
| 16:46:46 | amachronic | so, is anyone opposed to g#3474? |
| 16:46:48 | rb-bluebot | Gerrit review #3474 at https://gerrit.rockbox.org/r/c/rockbox/+/3474 : Enable float formatting in printf by Aidan MacDonald |
| 16:48:03 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 16:56:42 | braewoods | amachronic: is it disabled for bootloaders? |
| 16:57:15 | braewoods | that extra space is a luxury we can't afford for bootloaders. |
| 16:57:37 | braewoods | that would probably overload the printf used in the H120 bootloader |
| 16:57:48 | braewoods | it only has 64k to work with |
| 16:57:56 | braewoods | and was like 58k when i cut the last release |
| 16:58:29 | braewoods | that's all i can say about it |
| 16:58:42 | braewoods | these extra luxuries should not be included in bootloader builds |
| 16:58:49 | braewoods | they don't need floating point |
| 16:59:23 | amachronic | good thinking |
| 17:00 |
| 17:04:10 | amachronic | it seems that block was already #ifndef BOOTLOADER so it's fine. |
| 17:05:48 | dconrad | amachronic, I got g#3461 updated if you want to peek at it |
| 17:05:49 | rb-bluebot | Gerrit review #3461 at https://gerrit.rockbox.org/r/c/rockbox/+/3461 : FS #13297: M3K Autolock allows one action before disabling touchpad by Dana Conrad |
| 17:06:46 | dconrad | I didn't even think about using the local action instead of cur, just automatically used it since I was already doing cur->button haha |
| 17:07:52 | dconrad | I tested it here, seems to work great |
| 17:09:05 | amachronic | seems good |
| 17:09:46 | dconrad | sweet |
| 17:09:47 | amachronic | just to clarify is the manual change just something forgotten from the last softlock thing you did? |
| 17:09:52 | dconrad | yeah |
| 17:09:55 | | Join rockboxman [0] (~rockboxma@170.9.6.51.dyn.plus.net) |
| 17:10:14 | dconrad | in g#3436 |
| 17:10:16 | rb-bluebot | Gerrit review #3436 at https://gerrit.rockbox.org/r/c/rockbox/+/3436 : Softlock Improvements by Dana Conrad |
| 17:11:05 | dconrad | it was added in g#3285 |
| 17:11:07 | rb-bluebot | Gerrit review #3285 at https://gerrit.rockbox.org/r/c/rockbox/+/3285 : Add ability to always have autolock on by Dana Conrad |
| 17:11:10 | amachronic | oh yeah it's in the commit message, didn't look |
| 17:11:12 | rockboxman | Didn't know you could still get a Sansa connect brand new. https://www.ebay.com/itm/333978374197?hash=item4dc2a99035:g:-jcAAOSw7WBgiK7l |
| 17:11:30 | rb-bluebot | Build Server message: New build round started. Revision c067b344e8, 297 builds, 9 clients. |
| 17:11:47 | | Part rockboxman |
| 17:20:08 | rb-bluebot | Build Server message: Build round completed after 517 seconds. |
| 17:20:10 | rb-bluebot | Build Server message: Revision c067b344e8 result: All green |
| 17:30:01 | *** | Saving seen data "./dancer.seen" |
| 18:00 |
| 18:37:08 | | Quit dconrad (Remote host closed the connection) |
| 18:48:22 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 18:50:12 | | Join speachy [0] (~speachy@209.2.65.77) |
| 18:50:12 | Mode | "#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat) |
| 18:53:23 | | Quit amachronic (Read error: Connection reset by peer) |
| 18:53:25 | | Quit dconrad (Ping timeout: 272 seconds) |
| 19:00 |
| 19:08:10 | speachy | been digging into FS #13299 −− it's a bit of a head scratcher. |
| 19:08:11 | rb-bluebot | https://www.rockbox.org/tracker/task/13299 Cannot play some music file. Ipod classic 120gb Rockbox. One of the music attached. (bugs, unconfirmed) |
| 19:09:16 | speachy | the interesting thing about this file is that it's not only variable bitrate but also variable sample rate |
| 19:17:10 | speachy | basically the "two consecutive headers with similar enough headers" test is failing, so we're never considering it a valid file. |
| 19:30:04 | *** | Saving seen data "./dancer.seen" |
| 19:49:20 | braewoods | speachy: variable sample rate? i thought audio files had a fixed sample rate that was used to determine how long it is. |
| 20:00 |
| 20:20:02 | speachy | pretty sure that's not what's causing the file to fail, but it is a curiousity |
| 20:20:29 | speachy | sample rate is a property of a given chunk/frame, not the file as a whole. |
| 20:20:49 | speachy | (ie just like the bitrate, which can and does routniely vary from chunk to chunk) |
| 20:25:26 | speachy | I've never seen a variable sample rate file but it is technically legal. and handled just fine by $random_pc_software |
| 20:26:16 | speachy | there's something about this file that's breaking the header parsing; what happens is that we find the second header, then back up to find the previous one. |
| 20:26:31 | speachy | it's the backing-up that's going wrong |
| 20:30:15 | speachy | ...because the frames have different sampling rates, they have different sizes. |
| 20:34:22 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 20:48:32 | | Join Saratoga [0] (~Saratoga@cpe-98-10-205-66.rochester.res.rr.com) |
| 20:48:48 | Saratoga | I don't think libmad even supports vbr for later 1 files |
| 20:49:17 | Saratoga | Layer |
| 20:50:01 | Saratoga | Layer 1 is usually cbr only |
| 20:50:39 | Saratoga | You can change the frame sizes but decoders tend not to allow that |
| 20:50:51 | | Quit Saratoga (Client Quit) |
| 20:51:49 | speachy | whatever encoded this added padding between the frames. |
| 20:52:10 | speachy | our metadata parser expects none. |
| 20:54:32 | speachy | our "find frame start" code seeks byte by byte, so we find each frame properly, but the "read the next frame to see if it's similar" code is expects no padding. |
| 21:00 |
| 21:11:55 | speachy | I'd appreciate a sanity check on g#3478 |
| 21:11:56 | rb-bluebot | Gerrit review #3478 at https://gerrit.rockbox.org/r/c/rockbox/+/3478 : mp3: Greatly simplify VBR frame parsing in the metadata decoder. by Solomon Peachy |
| 21:12:25 | speachy | handles every file I've thrown at it so far, including that iffy one |
| 21:12:37 | speachy | (which won't play back, but at least we can parse out its metadata now) |
| 21:14:03 | speachy | because it seems to be win-win, removed code and run-time complexity, and fixes a bug in the process. |
| 21:30:08 | *** | Saving seen data "./dancer.seen" |
| 21:45:55 | speachy | desowin: have you been updating wiki's port status pages to reflect your Connect work? And is it something we can promote to "Unstable" status, generating nightly builds etc? |
| 21:54:37 | mendel_munkis | I just discovered that new gerrit needs JS :( |
| 21:57:09 | speachy | (I thought the old one did too?) |
| 21:58:38 | mendel_munkis | I think it just needed js for all the features, but I don't remember for sure |
| 22:00 |
| 22:00:52 | mendel_munkis | 3478 looks sane to me |
| 22:13:30 | | Join ufdm_ [0] (~ufdm@c-73-164-63-214.hsd1.mn.comcast.net) |
| 22:13:30 | | Quit ufdm (Read error: Connection reset by peer) |
| 22:14:52 | speachy | just made another couple of tweaks, stripped out a little more dead code |
| 23:00 |
| 23:18:15 | | Quit dconrad (Remote host closed the connection) |
| 23:27:51 | Bilgus | so it looks like to me it originally went H0H1H2H3 H0:H1 H0:H2 H0:H3 and now it goes H0:H1 H1:H2? |
| 23:28:05 | Bilgus | re 3478 |
| 23:28:24 | | Join dconrad [0] (~dconrad@208.38.228.17) |
| 23:28:26 | Bilgus | sorry H2:H3 was the last iter |
| 23:30:09 | *** | Saving seen data "./dancer.seen" |
| 23:33:00 | | Quit dconrad (Ping timeout: 252 seconds) |
| 23:34:41 | speachy | Bilgus: No, it did Hn:Hn+1 |
| 23:35:21 | speachy | (ie it would seek forward from the current position to try and peek at the next header, before seeking back) |
| 23:35:46 | speachy | the new code does Hn:Hn-1 |
| 23:36:34 | speachy | ...which... is wrong now that I explained it in that way. It should return Hn-1, not Hn. |
| 23:38:48 | Bilgus | but it used to seek back to the last header? |
| 23:39:06 | Bilgus | maybe i'm misreading it quite possible |
| 23:39:09 | speachy | it would seek "back" to the current header |
| 23:39:48 | speachy | old code returned the first of a valid pair, new code retursn the second of the pair. |
| 23:40:14 | speachy | I need to change it to return the first, and seek back to where that header lived. |
| 23:42:49 | Bilgus | but the old code how did it keep track of position as it seeked back to the last known header |
| 23:43:13 | speachy | it knew how forward it seeked, so it just reversed it. |
| 23:44:08 | speachy | ok, that's fixed. |
| 23:45:09 | Bilgus | no i'm saying in the case of invalid header wouldn't it get stuck looking at the same two bad headers till pos maxed out the loop |
| 23:53:11 | speachy | old or new? |
| 23:53:39 | speachy | I mean, if it doesn't find anything it considers valid it'll eventually max out pos and exit the loop, sure. |
| 23:54:15 | speachy | but the old code didn't rewind to the *start* of the header, it rewinded to just after the header. |
icon identifies that the person is a core developer (has commit access).