--- Log for 19.11.120  Server: barjavel.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 12 days and 13 hours ago

00.02.44 #       <karinka> im currently on bl version 5
00.08.43 #       <karinka> and i dont know if i have the eu or the us version'
00.09.51 ***     Saving seen data "./dancer.seen"
00.10.36 #       <karinka> okay v5 is the current version?
00.12.49 #       <karinka> just gonna leave it plugged in for a bit
00.13.10 Quit    karinka (Quit: karinka)
00.13.34 Join    karinka [0] (~karinka@n114-75-91-109.bla3.nsw.optusnet.com.au)
00.26.46 #       <karinka> updating to 3.15 stable with rockbox utility
00.26.51 #       <karinka> cause lazy
00.28.32 #       <karinka> battery is reporting above 4v
00.33.20 #       <karinka> ill keep an eye out for issues with the H2
00.33.27 #       <karinka> just gonna take a bit
00.33.42 #       <karinka> its taken days for me to understand rockbox
00.33.46 #       <karinka> in general
00.59.59 Join    Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com)
01.28.05 #       <Strife89> Yeah v5 is the last known stable bootloader for the H3x0, sorry
01.32.48 #       <karinka> ah okay, good to know its stable at least
01.34.48 Quit    Stanley00 (Remote host closed the connection)
01.37.17 Join    Stanley00 [0] (~stanley00@unaffiliated/stanley00)
01.45.35 Join    Stanley|00 [0] (~stanley00@unaffiliated/stanley00)
01.48.56 Quit    Stanley00 (Ping timeout: 240 seconds)
01.50.15 Quit    Stanley|00 (Remote host closed the connection)
01.50.50 Join    Stanley00 [0] (~stanley00@unaffiliated/stanley00)
01.59.44 Quit    Stanley00 (Remote host closed the connection)
02.02.10 Join    Stanley00 [0] (~stanley00@unaffiliated/stanley00)
02.09.52 ***     Saving seen data "./dancer.seen"
02.25.24 Join    petur [0] (~petur@199.59.5.11)
02.25.24 Quit    petur (Changing host)
02.25.24 Join    petur [0] (~petur@rockbox/developer/petur)
02.27.13 Quit    dys (Ping timeout: 264 seconds)
02.33.04 Join    dys [0] (~dys@aurora.ydns.eu)
02.54.20 Part    karinka ("Good Bye")
02.54.33 Join    karinka [0] (~karinka@n114-75-91-109.bla3.nsw.optusnet.com.au)
02.54.42 Nick    karinka is now known as borkitall (~karinka@n114-75-91-109.bla3.nsw.optusnet.com.au)
02.55.30 #       <borkitall> just changed my nick, just letting yall know
02.55.34 #       <borkitall> from karinka
02.55.48 #       <borkitall> ah its there lul im not used to irc
04.05.12 Join    prof_wolfff [0] (~prof_wolf@148.red-83-49-157.dynamicip.rima-tde.net)
04.09.54 ***     Saving seen data "./dancer.seen"
06.09.56 ***     No seen item changed, no save performed.
06.35.10 Quit    Misanthropos (Read error: Connection reset by peer)
06.36.17 #       <braewoods> borkitall: Strife89 is right and wrong. it's still the one rbutil will be using for first installs but a newer one is being prepared. you can install it now if you want via iriver_flash from a development build.
06.36.31 #       <braewoods> main problem is rbutil hasn't been updated yet so we can't fully release it yet.
06.39.03 #       <braewoods> speachy: something up with RB website? everything times out.
06.39.57 #       <braewoods> yet gerrit still works over git
06.40.07 #       * braewoods boggles.
06.45.27 Join    Misanthropos [0] (~Misanthro@91.240.65.140)
06.48.26 Quit    Stanley00 ()
06.51.08 Quit    ac_laptop (Ping timeout: 260 seconds)
06.52.06 #       <speachy> braewoods: wokik engine wedged the web server.  thanks for letting me know.
06.52.09 #       <speachy> wiki
06.53.52 #       <braewoods> speachy: i assume we'll be releasing the new bootloaders whenever rbutil is ready for an update?
06.54.29 #       <braewoods> since it has checksums that are compiled in
06.54.46 #       <speachy> yeah... though I'd really prefer that this stuff get un-compiled-in so this doesn't happen in the future
06.55.07 #       <speachy> that shouldn't be hardcoded
06.55.17 #       <braewoods> possible but rbutil would need to be expanded to take them from the website then.
06.55.30 #       <braewoods> the only part that can be hard-coded is the checksum for the OF
06.55.44 #       <braewoods> that's pretty much static
06.56.17 #       <braewoods> hm
06.56.32 #       <braewoods> bluebrother^: any ideas how this could be done?
06.56.57 #       <braewoods> bluebrother^: i think we want to move the iriver h100/h300 patching to use checksums from a file instead of a hard-coded table
06.57.39 #       <braewoods> the existing one was taken from fwpatcher
06.57.45 #       <braewoods> that should probably stay but
06.57.54 #       <braewoods> rbutil needs to be more flexible
06.58.36 #       <braewoods> speachy: i think one of my projects after MTP is going to be seeing if i can add support for some missing chips
06.59.02 #       <braewoods> it would be interesting if we could have composite output on a few targets that support it
06.59.19 #       <braewoods> the chip in the hdd6330 is documented so
06.59.31 #       <braewoods> should be possible to write a driver for NTSC/PAL output
07.10.20 #       <speachy> looks like it went down about ~0130.  so everything www was offline for ~5h
07.28.52 Quit    ArsenArsen (Quit: bye)
07.29.13 Join    ArsenArsen [0] (~Arsen@fsf/member/ArsenArsen)
07.31.30 #       <braewoods> speachy: what defines the largest amount of data that can be sent to a usb core driver at once? the hardware chip's buffer size?
07.32.22 #       <braewoods> just trying to a see if it's possible for length to ever be too large to process all at once before returning
07.36.08 #       <gevaerts> What do you mean by "sent to a usb core driver at once"?
07.36.31 #       <braewoods> the transfer_complete callback
07.36.52 #       <braewoods> how large can length be at one time?
07.38.01 #       * gevaerts used to know this without having to check...
07.38.28 #       <braewoods> mostly curious so i can see how to structure MTP support
07.38.55 #       <braewoods> whether i need to do multiple passes through the buffer processing stuff
07.39.02 #       <braewoods> or whether one sufficiently large one will do
07.42.36 #       <gevaerts> The transfer_complete will have the length (or maximally that, not sure if shorter is possible) set with usb_drv_recv() or usb_drv_send_nonblocking(). You'll have to have that size buffer available of course. That doesn't mean that that's the same size advertised as the block size to the host (speaking in mass storage terms now...), you can do one block in several transfers
07.43.35 #       <braewoods> gevaerts: or i can just make multiple passes until all the data has been received
07.43.42 #       <gevaerts> Yes
07.43.56 #       <braewoods> well that helps i guess
07.44.06 #       <braewoods> i'm wanting to layer MTP into multiple layers
07.44.18 #       <braewoods> the IO layer (usb code)
07.44.25 #       <braewoods> the MTP parsing layer
07.44.41 #       <braewoods> and the MTP higher level stuff for RB to hook into to expose stuff over MTP
07.44.49 #       <gevaerts> Unless I'm seriously misremembering, that's what mass storage does (at least for some chips)
07.45.47 #       <braewoods> gevaerts: ok.
07.45.53 #       <braewoods> gevaerts: thanks.
07.46.16 #       <braewoods> i'm just trying to separate MTP from our usb stack so we can still use the code even on other targets where we use a different usb stack
07.46.23 #       <braewoods> it seemed to be the best ROI
07.47.35 #       <gevaerts> The ARC USB core (PP502x, imx31, maybe more?) can handle more than 64K at a time (not sure how much exactly) so that one is easy for mass storage (all OSes do 64K), but the AMS driver can only do 63K (the chip can do more, but that's more complex to set up and we could get away with not doing that). Other chips I have no idea
07.47.51 #       <braewoods> ok. sure.
07.48.02 #       <braewoods> i'll do multiple passes since the buffer may be smaller.
07.48.09 #       <braewoods> seems to be no way around it
07.48.28 #       <speachy> yeah, generally for bulk transfers you set up a DMA transfer across the entire buffer, and the controller will send out chunks and only tell the system when it's all done.
07.49.29 #       <speachy> braewoods: don't go overboard with abstraction layers.  our USB stack and driver interface is bespoke.
07.50.10 #       <speachy> and there is little room for reuse at anything other than the highest layers.
07.50.20 #       <speachy> even our Filesystem/etc interface is unique.
07.51.07 #       <speachy> abstracting all of those "external" APIs is all well and good, but without a second non-rockbox user, it's just going to be tied to how our stack/etc works anyway.
07.52.05 #       <speachy> there's arguably some advantage for hosted targets to re-use the MTP stuff, but on those there are already mature native solutions.
07.52.13 #       <braewoods> speachy: ok...
07.52.24 #       <speachy> this is one of those "premature optimization" things.
07.52.42 #       <braewoods> speachy: i was wanting to allow for apps to provide MTP services too
07.52.44 #       <braewoods> maye
07.52.46 #       <braewoods> maybe
07.53.01 #       <braewoods> either way, some abstraction for "storage" providers seemed prudent
07.53.19 #       <speachy> rockbox already provides an abstraction at that layer.  code to that API.
07.53.45 #       <speachy> and if this ever gets reused outside of rockbox, then at that point a proper storage API can be provided.
07.53.51 #       <braewoods> yea but i still need to write code to allow external code to interface with it?
07.54.27 #       <braewoods> i was thinking of separating the fulfillment of services to other codes so i could manage it and extend it later
07.54.55 #       <braewoods> e.g., the core handles processing of MTP requests and dispatches them to the appropriate provider
07.55.00 #       <speachy> my naive understanding is that MTP's external storage needs are pretty straightforward, essentially "enumerate contents of path X", "read file [ +offset/len]", "write file [+offset/len]" ?
07.55.18 #       <braewoods> oh i'm just speaking internally
07.55.28 #       <braewoods> like one provider might be based on...
07.55.35 #       <braewoods> that cache for files?
07.56.32 #       <braewoods> i just thought it'd be interesting if external stuff could provide their own implementations of MTP storage providers
07.56.45 #       <speachy> "External stuff"?
07.56.46 #       <braewoods> one would use dircache and serve real files
07.56.52 #       <speachy> ah, I see.
07.56.59 #       <braewoods> external modules
07.57.07 #       <braewoods> within RB
07.57.13 #       <braewoods> external to the MTP core code
07.57.21 #       <gevaerts> You mean like the debug thing you mentioned?
07.57.22 #       <braewoods> so it isn't limited to just using the filesystem resources
07.57.22 #       <speachy> no.. the right place for that is within the FS layer.  it already exports "fake" directories, for example
07.57.39 #       <braewoods> speachy: example?
07.57.51 #       <braewoods> gevaerts: yea, possibly.
07.57.59 #       <braewoods> it just sounded cool at first
07.58.21 #       <braewoods> i just trying to think of how to handle the MTP implementation
07.58.23 #       <braewoods> i am*
07.58.31 #       <speachy> eg when there's more htan one storage device, at the top level there are "symlinks" exposed that map to the different storage devices, but the result appears to be a single contiguous filesystem.
07.58.45 #       <braewoods> so like unix
07.59.15 #       <braewoods> speachy: does that show up in dircache?
07.59.20 #       <braewoods> i assume no?
07.59.34 #       <braewoods> though i guess mtp should stick to just serving real file resourcs
07.59.50 #       <speachy> they're returned as directory entries, so yeah, they'll end up exposed to whatever that walks teh filesystem
08.00.16 #       <braewoods> oh, i see.
08.00.25 #       <braewoods> so i could add that by extending the FS module.
08.00.29 #       <speachy> yep.
08.00.29 #       <braewoods> ok, ok.
08.01.00 #       <braewoods> just if we're going to have MTP i need to know how best to implement it
08.01.10 #       <braewoods> there's a lot i don't know about RB
08.01.26 #       <speachy> (and since RB's "special filenames" stuff is in the VFS layer, it applies no matter what the underlying storage backend is -- including native POSIX)
08.01.28 #       <braewoods> i thought i needed abstractions like this but i guess i don't
08.01.53 #       <braewoods> speachy: we may be able to use umtp-responder for the hosted targets
08.02.05 #       <braewoods> but it's not suitable for RB native targets. it's too tied to POSIX.
08.02.07 #       <braewoods> and Linux
08.03.09 #       <braewoods> it's a daemon that uses usb-gadget API to provide an MTP responder process.
08.03.23 #       <braewoods> C code
08.03.35 #       <braewoods> and also GPLv3
08.03.47 #       <speachy> my advice would be to ignore the external APIs entirely for now.  Write the pure MTP code that uses stubs.  usb_receive(), usb_send() on one side, and the basic filesytem actions on the other.  model the FS stuff on posix: opendir/readdir/open/read/write/close/unlink/etc
08.04.25 #       <speachy> that can be easily tested on a PC to get the basic kinks out, and from there it can be shoehorned into rockbox's native APIs.
08.04.56 #       <speachy> external API needs shouldn't require much more than that, actually.
08.06.00 #       <speachy> I saw umtp-responder; my worry about it is that if it needs something that isn't present on our sourceless vendor kernels.
08.07.19 #       <speachy> (And honestly it might make more sense to start with umtp-responder, and port that to rockbox's API instead)
08.07.39 #       <speachy> (but it would be nice to be able to use it for both native and hosted targets!)
08.09.23 #       <speachy> compiled on x86_64 the binary is just shy of 100K.
08.09.46 #       <speachy> no external libraries other than pthread.
08.10.00 ***     Saving seen data "./dancer.seen"
08.15.50 #       <speachy> scrap everyting that interfaces with the OS, keep only files starting with mtp_
08.22.03 #       <braewoods> speachy: maybe... just felt i would need to do a lot of gutting and refactoring for that to really work.
08.22.09 #       <braewoods> i looked through the source already.
08.22.31 #       <speachy> perhaps.. but is it more work than starting from scratch and having to re-implement 85% of what's there?
08.22.36 Quit    Moarc (Ping timeout: 265 seconds)
08.23.07 #       <braewoods> no idea.
08.23.21 #       <braewoods> i was planning to use it as a reference if nothing else.
08.23.28 #       <braewoods> it's easier to follow than the C++ stuff.
08.25.23 #       <braewoods> just i've noticed people usually end up reinventing the wheel for MTP responders because of how much they are tied to their host implementation.
08.25.37 #       <braewoods> i've not seen any generic libraries so to speak except for the client side
08.25.38 #       <speachy> would also be useful to take umtp-responder and profile its memory use.  should give us a ballpark estimation of the real-world memory usage requirements.
08.26.27 #       <speachy> on the client side it's a lot simpler, yeah.
08.26.44 #       <speachy> (or rather the OS-interface layer is a lot smaller)
08.27.08 #       <braewoods> e.g., every smart phone OS has their own solution
08.27.11 #       <braewoods> among other things
08.27.16 #       <braewoods> so
08.27.23 #       <braewoods> it wouldn't be unusual for RB to do the same
08.27.29 #       <braewoods> in this situation
08.27.36 #       <speachy> most of those things were written around the same time.
08.27.45 #       <speachy> ie when there wasn't an option for reuse
08.27.51 #       <speachy> and started out quasi-proprietary
08.27.56 #       <braewoods> I see.
08.28.29 #       <speachy> and once you had something that worked, why invest the effort into switching to something else?
08.29.31 #       <speachy> (also, incompatible licensing is another typical reason for reinventing the wheel.  see: android everything)
08.30.44 #       <speachy> I mean, we can't use the otherwise-awesome bluekitchen/btstack for that reason
08.46.02 Join    Moarc [0] (~chujko@a105.net128.okay.pl)
09.18.16 #       <speachy> huh, appears that my patch to de-mangle the ATA timing for SSDs on the iPods seems to work.
09.22.26 #       <braewoods> speachy: IOW, the iflash issue?
09.22.44 #       <speachy> more specifically, the iFlash mSATA issue
09.22.55 #       <speachy> the iFlash SD stuff has long since been solved, I think.
09.26.19 #       <_bilgus> oh?
09.26.52 #       <speachy> the power management fix I did some point over the summer.
09.28.01 #       <_bilgus> nice I'll update that stickied post
09.29.28 #       <speachy> yeah, they _must_ use a recent nightly or dev build.
09.30.28 #       <speachy> ok, anyone have a relatively trivial commit ready?
09.31.11 #       <speachy> I've updated the build hooks/etc to use 10-char commit IDs instead of truncating to 7, and I need to make sure nothing breaks..
09.35.45 Join    massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
09.54.14 #       <speachy> _bilgus: you should also edit the  first post in the topic too..
09.55.23 #       <fs-bluebot> Build Server message: New build round started. Revision 6d62a7a1bd, 293 builds, 9 clients.
09.55.40 #       <speachy> ok, let's see what breaks on the www side when this is done.
10.10.02 ***     Saving seen data "./dancer.seen"
10.10.42 Quit    mutax (Read error: Connection reset by peer)
10.11.56 Join    mutax [0] (~mutax@ip5f590aa6.dynamic.kabel-deutschland.de)
10.13.27 #       <fs-bluebot> Build Server message: Build round completed after 1083 seconds.
10.13.29 #       <fs-bluebot> Build Server message: Revision 6d62a7a1bd result: All green
10.14.03 #       <speachy> sweeet, it's sane.
10.14.56 Quit    prof_wolfff (Ping timeout: 240 seconds)
10.15.15 Quit    Rower (Read error: No route to host)
10.16.04 #       <fs-bluebot> Build Server message: New build round started. Revision b7b0c7c648, 293 builds, 9 clients.
10.16.17 Join    Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com)
10.29.19 #       <fs-bluebot> Build Server message: Build round completed after 794 seconds.
10.29.21 #       <fs-bluebot> Build Server message: Revision b7b0c7c648 result: All green
10.36.08 Join    wodz [0] (~wodz@iwl138.internetdsl.tpnet.pl)
10.36.38 #       <wodz> any progress with BT ui mockup?
10.42.41 #       <wodz> will read response if any later
10.42.45 Quit    wodz (Quit: Leaving)
10.45.48 Quit    massiveH (Quit: Leaving)
10.47.55 #       <mendelmunkis> why does the gigabeat have two button-target.h? (plus one for the gigabeat-s)
10.48.24 #       <braewoods> speachy: kinda weird. the players that used the f-flex interface have 0 adapters available that i can tell.
10.48.39 #       <braewoods> but since the pin-out is documented
10.48.47 #       <braewoods> i guess someone could design one.
10.48.53 #       <braewoods> but how would you get it produced?
10.50.41 #       <braewoods> the ribbon cable is soldered to the original drive so you can't just reuse that
10.51.18 #       <braewoods> guess i'll ask some hardware guys that have designed stuff before
11.08.10 #       <braewoods> hm
11.08.23 #       <braewoods> one idea is if it's possible to find a generic ribbon cable that fits
11.08.35 #       <braewoods> then try to connect it to an adapter of sorts
11.08.41 #       <braewoods> but would take up too much space i'm sure
11.27.09 #       <_bilgus> s peachy done.
11.28.16 #       <_bilgus> wodz no I'll try to have it done by this weekend I have my multiline stuff worked out I still need to set up the dynamic part I'll try to do that tonight and get it up on gerrit
11.29.33 #       <speachy> I still need to figure out WTF is causing that bluetooth code to segfault on the other Hiby-based players.
11.55.27 Join    Skyrider [0] (~Skyrider@v220200567215119438.goodsrv.de)
12.05.47 Join    Rower- [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com)
12.08.19 Quit    Rower (Ping timeout: 265 seconds)
12.10.03 ***     Saving seen data "./dancer.seen"
12.10.17 Quit    petur (Quit: Connection reset by beer)
12.27.44 #       <speachy> huh. now it's working.
12.28.11 #       <braewoods> heisenbugs!
12.30.59 #       <speachy> wodz: can you write up what's needed to set things up on the ALSA side of things?  sample config device strings?
12.33.33 #       <fs-bluebot> Build Server message: New build round started. Revision 497618e51e, 293 builds, 9 clients.
12.44.09 Join    Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com)
12.45.48 Quit    Rower- (Ping timeout: 260 seconds)
12.55.53 #       <fs-bluebot> Build Server message: Build round completed after 1340 seconds.
12.55.55 #       <fs-bluebot> Build Server message: Revision 497618e51e result: All green
13.00.51 #       <_bilgus> wodz g#3044
13.00.54 #       <fs-bluebot> Gerrit review #3044 at https://gerrit.rockbox.org/r/c/rockbox/+/3044 : Bluetooth Menu WIP by William Wilgus
13.01.41 #       <_bilgus> basically the menus are laid out they are all dummies atm the trusted menu isn't built yet but its similar to the scan menu
13.02.03 #       <_bilgus> I think I want drop down menus and context menus but its just context menu atm
13.03.30 #       <_bilgus> there are still a few quirks to work out and some code cleanup in order but i'll get to it soon enough critiques welcome or ideas
13.09.43 #       <braewoods> _bilgus: serious question. you know the RB system that manages to output to 2 screens? right now that's just remote LCD and regular LCD.
13.10.00 #       <braewoods> _bilgus: how hard would it be to extend that concept with another type of second video output?
13.10.49 #       <braewoods> _bilgus: some of the players i've noticed have a composite video output.
13.11.09 #       <braewoods> so i was pondering the possibility of adding support as a secondary video output of the main rockbox screen
13.14.08 #       <_bilgus> it really wouldn't be hard to add it as another screen but there is nothing that uses it in the code
13.14.37 #       <_bilgus> better option would be a screen mirror but that incurs a speed penalty
13.15.29 #       <_bilgus> now a days I don't see it being high on a wish list for anyone but its your time do as you wish :)
13.15.37 #       <braewoods> _bilgus: ok. noted. i'll look into it later. i think i could write a driver for it.
13.16.04 #       <_bilgus> be easier as an either or make it main use remote
13.16.28 #       <braewoods> honestly adding the OTG for h300 is a higher priority to me
13.16.34 #       <braewoods> MTP even higher
13.16.54 #       <braewoods> right now i'm trying to fix my H10 so i have something to test MTP on
13.17.31 #       <braewoods> decisions, decisions, though.
13.18.04 #       <braewoods> i am going to try something first though :)
13.18.24 #       <braewoods> i want to see if increasing the buffer size for UMS mode will help with the slow write speeds at all
13.18.45 #       <braewoods> i doubt it but it can't hurt to try increasing it for a special test build
13.18.47 #       <bluebrother^> braewoods: I have an idea how we could approach this. Need to give it some thought though.
13.19.01 #       <bluebrother^> wasn't an issue the last 10+ years. Nobody released new bootloaders :)
13.19.02 #       <braewoods> bluebrother^: sure. take your time. i just updated the existing method.
13.19.09 #       <braewoods> in git
13.19.26 #       <braewoods> but it needs a new build to propagate.
13.19.35 #       <braewoods> in either case that will be true
13.19.50 #       <braewoods> bluebrother^: here's what i know. the only part you can hard-code is the hashes for the OF.
13.19.51 #       <bluebrother^> btw, I've been wondering if we should retire fwpatcher.
13.20.04 #       <braewoods> i'm not a fan of it but i patched it up to work.
13.20.06 Join    prof_wolfff [0] (~prof_wolf@148.red-83-49-157.dynamicip.rima-tde.net)
13.20.23 #       <braewoods> though i can't see why it would be useful in this day and age.
13.20.25 #       <bluebrother^> well, usually you shouldn't use fwpatcher anymore since Rockbox Utility can do the work :)
13.20.29 #       <braewoods> rbutil does the same thing.
13.21.07 #       <bluebrother^> exactly
13.21.15 #       <braewoods> bluebrother^: so ideally we'd have hashes for the firmware images be hard-coded and the final checksums will be on the bootloader site.
13.21.41 #       <braewoods> or
13.21.47 #       <braewoods> they can both be pairs in a file
13.21.50 #       <braewoods> hash:hash or so
13.21.54 #       <bluebrother^> we already have bootloaders/bootloader-info
13.21.56 #       <braewoods> before:after
13.22.22 #       <bluebrother^> but I'd prefer to merge that with build-info, so we don't end up with that much different files. For the bootloader hashes they could simply come from a file in git.
13.22.32 #       <bluebrother^> and the scripting creating build-info would simply append that.
13.23.16 #       <bluebrother^> I'd also like to have hashes for all other bootloader as well, so we can check if the download was successful. Not terribly important, but since the bootloader is usually the critical part an additional check won't hurt.
13.23.18 #       <braewoods> this is mainly an issue due to how we install the bootloaders on these units
13.23.29 #       <speachy> there's already a 'bootloaders-info' file on d.r.o
13.23.47 #       <bluebrother^> speachy: right, but I'd prefer that to be part of build-info
13.24.00 #       <braewoods> i don't care how we do it, just want to get these out to people.
13.24.00 #       <bluebrother^> is that file generated dynamically? We could have those hashes in git.
13.24.08 #       <bluebrother^> and simply cat them together
13.24.19 #       <speachy> no idea how it's supposed to be auto-generated, and that file doesn't match the build-info syntax
13.25.04 #       <bluebrother^> braewoods: I'll think about what needs to get finished for a new Rockbox Utility release the weekend. I still have quite some stuff on my todo, but we could now create a 1.5.0, and once I did that bump to 1.6.0.
13.25.09 #       <bluebrother^> I'd change the format a bit.
13.25.25 #       <braewoods> bluebrother^: do what you need to do. let me know if you need anything from me.
13.25.35 #       <braewoods> just needs to be easier to release bootloaders.
13.26.04 #       <braewoods> i mean, cutting the release will work fine this time i guess, but should we update the approach?
13.26.37 #       <bluebrother^> well, the question is how long Rockbox will continue to live :P
13.26.48 #       <braewoods> it's lasted this long.
13.27.05 #       <braewoods> may as well plan for it to last for another 10 years at least.
13.27.26 #       <bluebrother^> given that the bootloader haven't been changed in 10 years we could simply ignore the fact and keep things as-is. But since I'm trying to get more info from the download server we could as well tackle it.
13.27.38 #       <speachy> rockbox will live as long as folks like us are crazy enough to keep it going.
13.28.01 #       <braewoods> i've already got people clamoring for the updated bootloader.
13.28.03 #       <braewoods> lol
13.28.10 #       <bluebrother^> true. But where will the world be in 10 years? And will there still be hardware?
13.28.22 #       <bluebrother^> anyway, just asking. I'm not against updating things.
13.28.24 #       <braewoods> who really knows?
13.28.38 #       <bluebrother^> let's guess ... nobody? ;-)
13.28.41 #       <braewoods> it may not matter but we'll be glad if it does end up helping us in the future.
13.28.58 #       <bluebrother^> indeed. And it could be a nice programming exercise ;-)
13.29.47 #       <bluebrother^> so right now Rockbox Utility has been updated for Qt5, new players have been added, and we can now build it again for all platforms. That's good enough for 1.5.0.
13.29.53 #       <speachy> well, assuming we don't descent into a post-apolcalyptic wasteland, there will be hardware.  heck, even if the world goes to hell and folks have to duel mask-wielding fanatics with tricked-out Pursuit Specials, they'll still want to have rockin' tunes over bluetooth.
13.30.30 #       <bluebrother^> not too much work to finish that up I've been working on. And the further improvement (especially when it comes to bootloader installation, so we finally get rid of that sudo problem) would justify 1.6.0.
13.30.53 #       <bluebrother^> speachy: true to that :)
13.31.08 #       <braewoods> i'm also working on MTP support... it should be available for anything with functional OTG when i'm done.
13.31.47 #       * bluebrother^ would really like to see USB Audio. Just because it would be kinda cool.
13.32.12 #       <braewoods> as it stands RB would mainly be limited to being on the output end of it
13.32.24 #       <speachy> a better question is if there will ever be any new native targets.
13.32.25 #       <braewoods> probably doable though
13.32.40 #       <braewoods> quite possible but we may have to design it ourselves
13.33.01 #       <braewoods> that would probably make a good kickstarter project though
13.33.13 #       <speachy> we barely have the resources to maintain the status-quo, new hardware is going to take a lot of work.
13.33.20 #       <braewoods> indeed
13.33.55 #       <braewoods> if we had kernel sources to one that ran Linux we could probably find a way to replace the kernel
13.34.18 #       <braewoods> as an alternative
13.34.29 #       <speachy> we kinda do on the fiio m3k, at least.  I'd be willng to bet the Sony players have full kernel sources too.
13.34.58 #       <braewoods> i may eventually feel up to doing porting work but i feel more inclined to fix up the loose ends someone else left behind
13.35.15 #       <_bilgus> plenty of those
13.35.21 #       <braewoods> indeed
13.35.37 #       <braewoods> some are unlikely to be solved due to missing datasheets
13.35.49 #       <braewoods> the ones i intend to focus on are the ones that are actually realistically possible
13.35.58 #       <braewoods> usually due to documentation
13.36.20 #       <braewoods> the OTG for the h300 is probably possible to implement
13.36.21 #       <speachy> I'm content to see how the Pine64 thing comes along.  I have one of their PineCubes now, and a couple other boards (same basic hw platform) on the way too.
13.36.46 #       <braewoods> ultimately we'd need a some kind of casing to put it all in
13.36.50 #       <speachy> including schematics and full source code for everything including the bootloader.
13.37.05 #       <braewoods> is that something pine could also provide?
13.37.40 #       <speachy> that's what they're looking into now; if they can re-use an exisitng case design that drastically cuts the NRE required since tooling is _expensive_.
13.37.49 #       <braewoods> indeed
13.38.19 #       <braewoods> speachy: i guess my suggestion was a good one?
13.38.29 #       <braewoods> they were the only ones i could think of that have practical experience in this area
13.38.39 #       <speachy> they like rockbox, but they don't know if the economics would be worthwhile.
13.39.03 #       <braewoods> maybe it goes nowhere but i kinda noticed that we're running out of hardware targets for new stuff
13.39.17 #       <braewoods> so maybe the only viable option left for native is DIY
13.39.24 #       <speachy> the newer chinese DAPs are touchscreen monstrosities built mostly on android now.
13.40.09 #       <speachy> with a few exceptions, but we're not likely to see something new in the price point of the AGPTek Rocker.
13.40.30 #       <braewoods> it would probably be fine if we had kernel source
13.42.22 #       <speachy> I've passed on a ton of info to the SFC about various makers' blatant GPL violations, but enforcing anyting against a chinese company is not likely to ever bear fruit.
13.42.25 #       <_bilgus> ok moved to hilbylinux re compiling now
13.43.39 #       <braewoods> think i'm going to use 4K buffers for MTP for now
13.43.45 #       <braewoods> i just need to choose something.
13.44.01 #       <braewoods> it can be adjusted later
13.45.04 #       <braewoods> speachy: as we add more USB drivers we may need to make it configurable which ones activate and such. if we have too many endpoints we may exhaust the hardware's supply.
13.45.40 #       <braewoods> the datasheets imply a limit on that.
13.45.40 #       <braewoods> no idea honestly though
13.45.40 #       <speachy> braewoods: generally speaking, yes, it's only one "advanced" function at a time.
13.46.08 #       <gevaerts> Not just that. I suspect too many at a time would also confuse everyone
13.46.25 #       <braewoods> indeed. we'll probably want to make MTP and UMS mutually exclusive so as to conserve the resources.
13.46.38 #       <braewoods> UMS uses 2 endpoints, MTP uses 3.
13.47.07 #       <speachy> no, they need to be mutually exclusive.
13.47.33 #       <braewoods> ok. i thought i was agreeing though for different reasons.
13.52.24 #       <borkitall> okay i left the h320 charging overnight
13.52.32 #       <borkitall> its in bootloader usb mode
13.55.22 #       <gevaerts> You do have USB_NUM_ENDPOINTS to look at. Looks like nothing has fewer than 3
14.02.05 #       <bluebrother^> any thoughts on moving Rockbox Utility from qmake to cmake? That would also simplify all those tools, since we could simply use cmake for them as well.
14.02.35 #       <bluebrother^> so tools like ipodpatcher, mks5lboot etc.
14.03.59 #       <speachy> not a fan of cmake, and I thought the choice of qmake was driven by rbutil being qt-based?
14.04.13 #       <bluebrother^> yes, but Qt also moves to cmake.
14.04.28 #       <bluebrother^> and to be honest, cmake is a lot more advanced than qmake these days.
14.04.45 #       <speachy> sure, mirror what upstream uses
14.05.00 #       <bluebrother^> having qmake generate a Makefile that calls other hand written Makefiles is ... well, fragile.
14.05.20 #       <borkitall> the new battery is reporting 4.12v, is this normal for a new battery? its 3.7v 1700mAh
14.05.29 #       <braewoods> borkitall: yes
14.05.30 #       <bluebrother^> but since we're using a Makefile generator I figure it doesn't matter too much if it's qmake or cmake.
14.05.46 #       <braewoods> borkitall: voltage is used to estimate how full the battery is
14.06.26 #       <borkitall> awesome
14.06.33 #       <borkitall> still getting used to irc
14.08.24 #       <speachy> bluebrother^: I just don't want to have to rely on cmake to build anyting used by the main rb builds.
14.08.37 #       <speachy> but if it makes sense to ditch qmake, so be it.
14.09.02 #       <bluebrother^> yeah, would be only stuff in rbutil/ and utils/
14.09.12 #       <bluebrother^> plus, I'm planning to merge those two folders.
14.09.31 #       <bluebrother^> since having a separate rbutil/ doesn't make too much sense anymore these days.
14.10.05 ***     Saving seen data "./dancer.seen"
14.10.07 #       <bluebrother^> so tools/ would be the stuff required to build Rockbox itself (and not use cmake), utils/ would (at least partially) use cmake and only be additional tools.
14.10.36 #       <braewoods> speachy: we may have a problem. i just tried to run a development build on my H10 and it freezes.
14.10.50 #       <braewoods> and now it's getting system files stuff. i'll need to wipe it again.
14.11.14 #       <braewoods> i wonder if PP devices are bugged?
14.11.16 #       <speachy> braewoods: assmuming the 3.15 release worked, I'd try the oldest daily build as a sanity check first.
14.11.39 #       <speachy> the ipods work, at least...
14.11.45 #       <braewoods> also oddly there's a weird different from RB UMS and the proprietary UMS mode
14.11.59 #       <braewoods> the total sector count is one less in RB mode
14.12.26 #       <braewoods> sdc: p1 size 62453633 extends beyond EOD, enabling native capacity
14.12.30 #       <borkitall> so if i understand this, 1.7A is the max i should use with a 1700mAh battery
14.12.32 #       <borkitall> at 5v
14.12.33 #       <braewoods> is the error resulting from it
14.12.48 #       <braewoods> borkitall: eh? you mean for charging?
14.13.06 #       <braewoods> discharge rate is heavily defined by the battery
14.14.10 #       <borkitall> yes
14.14.28 #       <borkitall> i dont care about the discarge rate
14.14.51 #       <borkitall> just would like to know what charging to use, as i dont know where the stock charger is
14.15.13 #       <borkitall> sorry if im unclear
14.15.29 #       <braewoods> borkitall: well
14.15.39 #       <braewoods> you can get by with usb barrel jack adapter
14.15.43 #       <braewoods> or just charge over usb
14.16.30 #       <braewoods> i know the H320 and H340 use the 4mm barrel jack
14.16.48 #       <braewoods> https://www.ebay.com/itm/100cm-USB-4-0mm-x-1-7mm-DC-Barrel-Jack-5V-1A-Charger-Power-Cable-Adapter-4mm/383567985013
14.16.51 #       <speachy> so rb reports an odd drive sector size?
14.16.52 #       <braewoods> one example
14.17.10 #       <braewoods> speachy: yes. it's one less than the max size reported when i'm in the iriver UMS
14.17.32 #       <braewoods> speachy: i worked around it before by making my partition slightly smaller
14.17.52 #       <braewoods> not sure what the issue really is, if any
14.17.52 #       <speachy> this is h10? h1xx?
14.17.58 #       <braewoods> speachy: H10
14.18.09 #       <braewoods> it happened before I performed the CF mod
14.18.19 #       <braewoods> as well
14.18.26 #       <braewoods> maybe this unit is just iffy
14.18.41 #       <borkitall> braewoods: thanks yeah i got one of those
14.18.41 #       <braewoods> brb
14.18.50 #       <speachy> I'd be curious to see what the actual drive reports.
14.19.03 #       <braewoods> i can't open it to find out. one of the screws got stripped
14.19.12 #       <speachy> dump the identify info
14.19.15 #       <speachy> it'll be in there.
14.19.19 #       <braewoods> ok.
14.19.29 #       <braewoods> i'll check it out after i repair it
14.19.31 #       <braewoods> ugh
14.19.56 #       <braewoods> i'll check my other H10 to see if it has the same inconsistency
14.20.05 #       <braewoods> i forgot about it until recently
14.24.28 #       <speachy> braewoods: it _appears_ that total sector reported is lifted straight from the drive.
14.24.47 #       <braewoods> could it be iriver is reporting it wrong?
14.25.00 #       <speachy> could be.
14.25.02 #       <braewoods> anyway i'll check what i find out.
14.25.20 #       <speachy> the identfy info will be authatorative.
14.28.48 #       <braewoods> no issue on H320
14.28.50 #       <braewoods> hm
14.29.12 #       <braewoods> seems to be an H10 bug
14.42.19 #       <_bilgus> 3044 has a few bug fixes I'll try to get it fleshed out a bit more this evening and incorporate any new suggestions
15.02.59 Join    Rower- [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com)
15.04.36 Quit    Rower (Ping timeout: 240 seconds)
15.42.54 #       <Strife89> speachy: I've been mulling over giving my iRiver flash storage, but I don't think I want to get another iFlash. Know any good alternatives?
15.43.25 #       <Strife89> (Other than the Kingspec 1.8" line, which gets expensive for the 128 GB model. https://smile.amazon.com/KingSpec-128GB-1-8-5mm-KSD-ZF18-6-128MS/dp/B008NAI0YC)
15.43.43 #       <speachy> nope.  AFAIK all of the others are all based on the same chipset anyway.  even the kingspec, which IIRC is just an eMMC with the same controller
15.44.02 Join    Bilgus_ph [0] (~irc@65.186.35.190)
15.44.17 #       <Strife89> Well shoot
15.45.08 #       <Strife89> And that means the Kingspec probably gets the same workaround as the iFlash, doesn't it (disabling putting the disk to sleep)
15.48.16 Quit    Bilgus_ph (Remote host closed the connection)
15.52.28 Join    Bilgus_ph [0] (~irc@65.186.35.190)
15.52.44 Quit    Bilgus_ph (Client Quit)
16.01.38 Join    ac_laptop [0] (~ac_laptop@186.2.247.129)
16.09.43 #       <braewoods> Strife89: you have an H320?
16.09.51 #       <braewoods> Strife89: how'd the new bootloader work for you?
16.09.53 Quit    Rower- ()
16.10.09 ***     Saving seen data "./dancer.seen"
16.11.07 #       <Strife89> Yep
16.11.13 #       <Strife89> Flashing it and rebooting went well!
16.12.00 Quit    Acou_Bass (Quit: ZNC 1.8.1 - https://znc.in)
16.12.27 #       <braewoods> Strife89: great. so you want flash storage?
16.12.32 #       <Strife89> https://usercontent.irccloud-cdn.com/file/yig03Emd/IMG_20201119_161144.jpg
16.12.41 #       <Strife89> I do
16.13.03 #       <braewoods> Hm.
16.13.11 #       <Strife89> TBH I'm just window shopping right now, though. Money's tight.
16.13.21 #       <braewoods> I used those CF card adapters when I modded my H120.
16.13.38 #       <braewoods> they need a bit of work as the jumper is too tall.
16.13.48 #       <braewoods> but it's probably your best option
16.13.56 #       <braewoods> some kind of CF card or an adapter
16.14.14 #       <braewoods> in either case speed isn't going to incredible
16.14.25 #       <braewoods> i saw my CF card max out at 13 MB/s when doing block operations
16.14.33 #       <braewoods> but it's better than many RB targets
16.15.00 #       <braewoods> Strife89: how much storage you wanting?
16.15.13 #       <braewoods> the most economical is probaly SD cards
16.15.17 #       <Strife89> 60-100 GB would be best
16.15.23 #       <braewoods> ah.
16.15.33 #       <braewoods> you can find 64GB CF cards for around $30 used lately
16.15.38 #       <Strife89> (so a 64 or 128 GB SD/CF card, probably)
16.15.44 #       <braewoods> that and the adapter is around $40
16.16.36 #       <braewoods> i've seen kingston cf cards for around $60-80 for 128GB or more
16.16.48 #       <braewoods> but at that point SD cards start to sound better
16.16.54 #       <Strife89> I bought an iFlash Solo for an iPod Color a while back, and while it works pretty well now, it was rough at first
16.17.13 #       <braewoods> the SD card adapters are also hit or miss
16.17.16 #       <Strife89> I have speachy to thank for getting it to behave in Rockbox
16.17.38 #       <braewoods> the best option is true CF cards with a passive adapter if you want any guarantees about stability
16.17.39 Join    Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net)
16.18.10 #       <braewoods> what continent you on?
16.18.13 #       <braewoods> i'll see what i can find
16.18.36 #       <Strife89> North America (southeastern United States)
16.18.57 #       <braewoods> ah
16.19.38 #       <braewoods> ok, kingston canvas focus is the cheapest CF card for 128GB
16.19.46 #       <braewoods> $40ish
16.19.49 #       <braewoods> ebay
16.20.17 #       <braewoods> https://www.amazon.com/Kingston-128GB-Performance-Professional-CFF/dp/B07M5M5KYZ
16.20.21 #       <braewoods> or here
16.20.33 #       <braewoods> or 256GB for $60
16.20.43 #       <Strife89> That's pretty good
16.21.13 #       <Strife89> Any known-good CF adapters still out there?
16.21.28 #       <braewoods> yea.
16.21.32 #       <braewoods> for your h320
16.21.41 #       <braewoods> the easiest is the 50 pin one that's entirely passive
16.22.11 #       <braewoods> https://www.amazon.com/SinLoon-AdapterCompact-Converter-Adapter-Toshiba/dp/B07YSJ12T3
16.22.14 #       <braewoods> this for example
16.22.22 #       <braewoods> but you'll need to modify it slightly to use it in H320
16.22.41 #       <braewoods> the jumper is too tall
16.22.49 #       <braewoods> you have to find a way to solve that
16.23.09 #       <braewoods> jumper needs to be closed/bridged to avoid issues with the adapter
16.23.13 #       <braewoods> you can bend it over
16.23.20 #       <braewoods> and somehow bridge it
16.23.32 #       <braewoods> cut it and solder the pins
16.23.34 #       <braewoods> etc
16.23.38 #       <braewoods> anything to reduce the overall height
16.23.54 #       <braewoods> since it's purely passive there's very little that can go wrong.
16.24.01 #       <braewoods> main reason i prefer it
16.25.15 #       <Strife89> I'll keep that for later, thanks!
16.25.48 #       <braewoods> you may also need to clip off the plastic tabs
16.25.55 #       <braewoods> on the unit
16.25.58 #       <braewoods> adapter
16.26.00 #       <braewoods> i mean
16.26.19 #       <braewoods> it got in the way when i installed the one in my h120
16.26.35 #       <speachy> is that an LED on the pcb?
16.26.49 #       <braewoods> maybe but it's not populated
16.27.16 #       <braewoods> oh, you mean the ZIF adapters?
16.27.40 #       <braewoods> Strife89: i prefer the 64gb cards. i don't need more storage.
16.29.53 #       <Strife89> I'm a data hoarder :P
16.30.13 #       <Strife89> And I, uh, acquire lots and lots of video game soundtracks
16.30.18 #       <braewoods> I see.
16.30.43 #       <braewoods> either way the CF cards should give a modest speed boost over the original hard drive
16.31.03 #       <braewoods> 13 MB/s is the fastest i've ever gotten over UMS on any RB target
16.31.16 #       <braewoods> i got that on a gogear HDD1630 after upgrading to a CF card
16.31.34 #       <Strife89> Sounds pretty good, overall
16.31.53 #       <braewoods> and also on the H120
16.32.00 #       <braewoods> i assume the H320 will also achieve similar speeds
16.32.06 #       <braewoods> since it uses the same ATA/USB stuff
16.32.45 #       <braewoods> i'm going to try some experiments, see if increasing the UMS write buffer helps IO at all
16.32.48 #       <braewoods> increase it to 64k
16.32.51 #       <braewoods> :-)
16.33.10 #       <Strife89> I'm more worried about power saving and shake/impact resistance anyway :)
16.33.18 #       <braewoods> you got that in spades
16.33.23 #       <braewoods> CF cards also tend to be faster
16.33.28 #       <Strife89> But faster r/w speeds will definitely be nice, too
16.33.34 #       <braewoods> means faster syncing
16.33.46 #       <braewoods> but it seems to me that the real world speeds differ heavily
16.33.54 #       <braewoods> the iriver H10 has terrible write speeds
16.33.59 #       <braewoods> but i've seen 20+ MB/s read speeds
16.34.10 #       <Strife89> and faster seek times, of course
16.34.14 #       <braewoods> but it caps around 4-5 MB/s write
16.34.28 #       <braewoods> kinda weird considering it was a CF mod
16.34.38 #       <braewoods> the card it has can do 10 mb/s in a regular usb adapter
16.34.44 #       <braewoods> so
16.34.48 #       <braewoods> the card isn't the bottleneck
16.34.50 #       <braewoods> something else is
16.35.56 #       <braewoods> Strife89: it's entirely optional but you may want to replace the OF before doing the CF mod
16.36.11 #       <braewoods> the OF is worthless in a CF modded H320 anyway since it doesn't like them
16.36.12 #       <Strife89> As in flashing Rockbox
16.36.17 #       <braewoods> yea
16.36.18 #       <Strife89> ?
16.36.23 #       <braewoods> that's a new feature of the V8 bootloader
16.36.34 #       <Strife89> Oh good, I was hoping so
16.36.46 #       <braewoods> it works, i tested it during my trial runs before release
16.36.57 #       <braewoods> i ported over the code used in the H100
16.37.44 #       <braewoods> but that was one reason I did my development on a non-modded H320
16.37.50 #       <braewoods> i needed the OF to recover from bad flashes
16.38.16 #       <braewoods> it was broken for a long time, the bootloader
16.38.57 #       <braewoods> turned out someone added code to switch the H300 LCD code to using DMA but that broke the bootloader
16.39.15 #       <braewoods> so i had to port the old method of updating it so the bootloader would work again
16.40.44 #       <braewoods> incidently the new BL has a fallback that if the OF has been replaced, it will attempt to boot the ROM RB image if the reset cookie was tripped
16.40.55 Quit    Acou_Bass (Ping timeout: 246 seconds)
16.41.12 #       <braewoods> good if the main bootloader payload is somehow unable to boot
16.46.06 Join    Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net)
16.58.43 Join    S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156)
17.29.31 #       <braewoods> speachy: can you read schematics?
17.37.07 #       <speachy> yeah?
17.37.46 #       <braewoods> i was trying to find a new battery for my hdd1630 but the existing ones are too tall.
17.37.58 #       <braewoods> even though they claim to be compatible they don't fit the case
17.38.15 #       <braewoods> so i'm trying to find one that fits the case and terminal and has the same pin out
17.38.26 #       <braewoods> so how do i determine my existing pin out?
17.38.30 #       <braewoods> or is that standardized?
17.38.32 #       <speachy> for the battery?
17.38.37 #       <braewoods> and the terminal
17.38.49 #       <braewoods> i have the board schematics for the header
17.38.54 #       <speachy> there's no inherent standard, although I have yet to see one of those batteries where red wasn't + and black -.
17.38.54 #       <braewoods> https://www.rockbox.org/wiki/pub/Main/GoGearHDD6330/PHILIPS_HDD1420_ServiceManual.pdf
17.39.04 #       <speachy> sometimes there's a sense line too, typically white or yellow
17.39.14 #       <braewoods> the HDD1630 is 3 pin
17.39.37 Nick    mendelmunkis is now known as mendel_munkis (~mendelmun@ool-435680b7.dyn.optonline.net)
17.39.41 #       <braewoods> U502 is the battery part
17.39.47 #       <braewoods> i think it's saying...
17.40.03 #       <braewoods> pin 1 is connected to ground?
17.40.16 #       <braewoods> pin 2 goes to BAT_P
17.40.19 #       <braewoods> err
17.40.21 #       <braewoods> BAT_T
17.40.24 #       <braewoods> pin 3 is BAT_P
17.40.42 #       <braewoods> sorry, i suck at reading these.
17.41.34 #       <braewoods> i can use a multimeter to figure out which battery terminals are what
17.41.45 #       <braewoods> fbut
17.41.47 #       <braewoods> but
17.41.49 #       <braewoods> eh
17.41.49 #       <speachy> okay, pin 1 is ground, pin 2 is positive, pin 3 is sense
17.42.00 #       <braewoods> ok. thank you.
17.42.24 #       <braewoods> that's what i thought
17.43.03 #       <speachy> yep, in the photo it's clearly blk-red-wht
17.44.11 #       <speachy> you may or may not be able to find a battery with the right size/type connector.
17.44.48 #       <braewoods> it is what it is but i figured the ipod mini would be a good place to check
17.44.53 #       <speachy> (IIRC back in the day the H1xx series used an ipod battery, but with the + and - swapped.  easy enough to swap pins on the connector)
17.45.21 #       <braewoods> it's closest to the ipod mini in terms of size
17.45.32 #       <braewoods> also uses microdrive
17.51.02 #       <braewoods> yea it matches the known viable replacement
17.51.11 #       <braewoods> only flaw is it doesn't fit the case too well
17.51.30 #       <braewoods> i guess there's always plan B
17.51.45 #       <braewoods> find an alternative that fits and just reterminate the battery connector
17.51.57 #       <braewoods> though not what i'd prefer to do. lol
17.54.12 #       <braewoods> ipod mini battery would probably fit but the pins don't look right
17.54.29 #       <braewoods> different layout
18.10.13 ***     Saving seen data "./dancer.seen"
18.19.46 Part    borkitall
18.45.23 #       <braewoods> speachy: you said the pins were easy to swap. how would you do so? what tools?
18.45.48 #       <braewoods> i'm guessing these batteries are 1.25mm jst but i can't even find what tools you'd use to terminate these
19.03.21 #       <braewoods> oh.
19.03.56 #       <braewoods> found it i guess
19.04.13 #       <braewoods> guess my best bet is to find a battery and swap the pins
19.04.17 #       <braewoods> didn't realize you could do that
19.06.22 Join    borkitall [0] (~borkitall@n114-75-91-109.bla3.nsw.optusnet.com.au)
19.06.41 #       <speachy> if it's the same _connector_ the pins are easy to swap.  if the connector differs (and the actual pins themselves don't have the same size/profile) then you're SOL.
19.07.16 #       <speachy> there's a tiny plastic flap that you need to lift out of the way so you can pull the pin out.
19.14.04 Quit    Acou_Bass (Quit: ZNC 1.8.1 - https://znc.in)
19.19.44 Join    Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net)
19.19.44 #       <braewoods> speachy: i saw that in a video
19.52.43 Join    bluebrother [0] (~dom@rockbox/developer/bluebrother)
19.52.59 Join    fs-bluebot_ [0] (~fs-bluebo@55d4017f.access.ecotel.net)
19.55.36 Quit    fs-bluebot (Ping timeout: 260 seconds)
19.56.36 Quit    bluebrother^ (Ping timeout: 272 seconds)
20.00.10 Join    thanevim [0] (4989016d@c-73-137-1-109.hsd1.ga.comcast.net)
20.03.31 #       <thanevim> Hi everyone. Glad to see this still around. I just bought a Fuze v2 off of ebay, and it boots, plays music, even took a firmware upgrade for the rockbox install. Bootloader starts, but it presents a partition error. Not finding anything online about this, any help?
20.06.41 #       <thanevim> For the record, it does still play music in the original firmware after Rockbox install.
20.08.21 Join    livvy [0] (~livvy@gateway/tor-sasl/livvy)
20.09.43 Quit    prof_wolfff (Ping timeout: 265 seconds)
20.10.15 ***     Saving seen data "./dancer.seen"
20.29.33 Quit    thanevim (Remote host closed the connection)
20.30.43 Join    thanevim [0] (4989016d@c-73-137-1-109.hsd1.ga.comcast.net)
20.41.55 #       <braewoods> thanevim: can you be more specific about the message?
20.43.01 #       <thanevim> The message itself reads "No partition found. Insert USB cable and fix it."
20.43.23 #       <thanevim> This is a Fuze v2 2GB model for the record
20.43.55 #       <braewoods> it means it can't find the partition rockbox is on
20.44.03 #       <braewoods> all the bootloaders say something similar if that happens
20.44.54 #       <thanevim> That makes sense. I did find something mentioning format in the original fw if this error occurs, however that plus reinstall from the rbutil still resulted in the same error
20.46.19 #       <thanevim> It seems there's a workaround by dropping .rocknox onto a microSD, but that's resulting in all of the applets showing Incompatible Version (potentially because the version on /wiki/SansaAMS isn't the same that the util uses?)
20.47.02 #       <thanevim> Regardless, it would at least be nice if there's a fix that doesn't require loading from microSD if possible
20.47.16 #       <braewoods> _bilgus: may know more as i believe he was working on sansa bootloaders
20.47.35 #       <braewoods> i'm not really familiar with those targets too well
20.47.54 #       <braewoods> i mostly focus on HDD units
20.48.04 #       <braewoods> like the iriver h100 and h300
20.48.18 #       <thanevim> Understandable. I'll wait for bilgus to speak, and post in here if I find anything
20.49.54 #       <_bilgus> thanevim, that message just means rb folder is missing
20.51.11 #       <_bilgus> when you plug usb does it mount the internal drive?
20.51.43 #       <thanevim> Not inside that bootloader, but once you said that, I rebooted the original, and it does show internal memory that contains .rockbox/
20.51.48 #       <_bilgus> if so download the dev version for your device and copy the .rockbox folder from the zip to the device drive
20.51.50 #       <braewoods> thanevim: small tip. try to use sd card for most of your writes. a common failure with these players is wearing out the internal flash.
20.52.23 #       <thanevim> That makes sense, given these things are ~10 years old
20.52.37 #       <braewoods> the sd card can be replaced
20.52.43 #       <braewoods> your internal storage, not so easily if at all
20.53.09 #       <thanevim> Yeah.. I remember trying to no avail in my first sansa...
20.53.20 #       <braewoods> part of why i don't bother with RB targets that only have intenrla storage you can't replace
20.53.20 #       <_bilgus> again use a dev version same idea just copy .rockbox to the root of the sd car formatted to FAT32
20.53.34 #       <thanevim> Ok, I'll try that now
20.55.54 #       <braewoods> from appaearances the fuze v2's battery is soldered
20.56.02 #       <braewoods> those can still be replaced but you need the right tools
20.56.23 #       <braewoods> if you need help hunting for a replacement battery let us know
20.56.33 #       <thanevim> Appreciate it
20.57.08 #       <braewoods> though if there was room i'd want to solder a battery header. lol
20.57.29 #       <thanevim> That'd makes sense, to prolong life
20.57.44 #       <braewoods> yea. desoldering can damage the PCB and such.
20.57.54 #       <braewoods> so if you can, it's best to resolder a socket or header.
20.59.55 #       <thanevim> Booted the dev version, still seeing Incompatible version for the applets/games/etc
21.00.55 #       <braewoods> did you copy it to both the internal and SD card?
21.01.34 #       <_bilgus> no just one or the other but you can do both
21.01.52 #       <braewoods> well if it works it would tell us something
21.02.10 #       <_bilgus> if you ar egetting incompatible version message the you need to rename the folder and try again
21.02.23 #       <braewoods> or that
21.02.32 #       <_bilgus> don't delete rename it and copy again
21.02.40 #       <thanevim> It was just the sd. Did so out of fear that the internal flash is dying, since it has been causing Explorer to hang
21.02.52 #       <_bilgus> that makes sure it gets coppied to a new location
21.03.14 #       <thanevim> And the original firmware is currently hanging on Refreshing your media
21.03.30 #       <_bilgus> the internal flah dying is entirely possible thats why I made the boot from sd option
21.06.26 #       <mendel_munkis> is  there a list of which targets support which key combos?
21.07.04 #       <mendel_munkis> (if any)
21.08.54 #       <thanevim> Thanks for the help. I'll be afk for a bit, then resume hacking this poor piece of tech.
21.16.43 Quit    livvy (Ping timeout: 240 seconds)
21.26.17 #       <braewoods> looks like 602040 battery is my best option
21.30.36 #       <braewoods> speachy: i'm finding it hard to find batteries with the third wire for the sensor. is it essential?
21.55.54 #       <speachy> I would assume so.
21.57.19 #       <speachy> that's how the battery level is checked.  leave it off and you could end up (eg) the system force-shutting down because it thinks the battery is below the critical voltage level.
21.57.36 #       <speachy> or charging might not work.  or it might overcharge.  or..
22.01.04 #       <speachy> depends on how the BQ4032 (ie the battery charger IC) works.
22.01.22 #       <speachy> er. BQ24032
22.04.58 #       <speachy> d'oh, that's the temperature sense.   looking at the datasheet, without the TS connected, it won't charge the battery.
22.05.52 #       <speachy> (to use it with a 2-wire battery you'd need to modify the circuit slightly.
22.08.18 #       <speachy> that pin needs to be in the 0.5->2.5 range.  (+-3%)
22.08.29 #       <speachy> 2.5v, that is
22.09.01 #       <_bilgus> braewoods, the third wire can be bypassed with a sutible resistor
22.09.32 Quit    ac_laptop (Ping timeout: 260 seconds)
22.09.47 #       <_bilgus> you'll need an old battery to figure it out value and if its connected to ground or vcc
22.10.18 ***     Saving seen data "./dancer.seen"
22.11.29 #       <speachy> it's connected to vcc.
23.03.38 Join    ac_laptop [0] (~ac_laptop@186.2.247.129)
23.31.08 Quit    Xeha (Ping timeout: 256 seconds)