--- Log for 14.03.121 Server: beckett.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 8 days and 9 hours ago 00.20.26 Join eevan [0] (~eevan@telesto.hot-chilli.net) 00.20.50 Nick eevan is now known as Guest70559 (~eevan@telesto.hot-chilli.net) 00.29.08 Quit koniu (Remote host closed the connection) 00.29.37 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 00.31.05 Quit ufdm_ (Quit: Leaving) 00.40.46 Nick Guest70559 is now known as eevan (~eevan@telesto.hot-chilli.net) 00.43.27 Quit massiveH (Quit: Leaving) 00.49.59 Quit eevan (Remote host closed the connection) 00.50.20 Join eevan [0] (~eevan@telesto.hot-chilli.net) 00.54.07 # <__builtin> hmm... a python port would be interesting 00.54.18 # <__builtin> what do you think, _bilgus_? 00.58.21 # fmlatghor: if i had to guess, spectrum internet hurt him. ;p 01.21.48 *** Saving seen data "./dancer.seen" 01.22.33 Quit jdarnley (Ping timeout: 256 seconds) 01.25.47 Join J_Darnley [0] (~J_Darnley@d51a44418.access.telenet.be) 03.01.49 Part eevan 03.29.09 Join eevan [0] (~eevan@telesto.hot-chilli.net) 03.29.32 Nick eevan is now known as Guest77754 (~eevan@telesto.hot-chilli.net) 03.30.08 Nick Guest77754 is now known as eevan (~eevan@telesto.hot-chilli.net) 03.34.50 Part eevan 03.40.47 # speachy: huh so mtp supports functional modes so it can change at the protocol level 03.43.53 # ok, i think i see a solution 03.44.10 # mtp doesn't require exclusive disk access 03.44.32 # but it should have a form of pseudo exclusive disk access when the initiator wants to perform operations 03.44.56 # so we need to lock the UI mode in this situation 03.45.15 # we don't need exclusive access like the MSC driver does 03.45.20 Join eevan [0] (~eevan@telesto.hot-chilli.net) 03.47.22 # we can let the initiator switch functional modes if the situation allows 03.47.25 # or user can do so 03.47.54 # but we would have to start in exclusive mode since that's what MTP requires 04.04.58 Quit J_Darnley (Ping timeout: 260 seconds) 04.09.24 # speachy: does rockbox have anything builtin for time formatting? 04.09.53 # i need something to support formatting and parsing for MTP 04.09.57 # if it already exists then great 04.10.01 Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be) 04.10.02 # if not i'll have to improvise 04.21.52 *** Saving seen data "./dancer.seen" 04.49.31 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) 05.09.08 Quit eevan (Remote host closed the connection) 05.23.38 # speachy: i noticed usb is a little endian bus yet RB does not appear to do anything to ensure the multibyte units it sends over USB are in this same byte order... 05.23.56 # i assume this means the usb software stack is unusable if the host cpu is big endian 05.42.55 # interesting 05.43.07 # only one port that might be impacted, if the OTG chip was supported 05.43.15 # the rest are all unfinished ports 05.43.34 # or have either no OTG chips or ones with no datasheet 05.43.41 # the iriver H300 is the only one that might be impacted 05.44.01 # so i'd need support for big endian as well 05.44.08 # not just the dual port problem 05.44.36 # from researching it appears this dual USB port problem is mostly a coldfire problem 05.44.54 # plus a few gigabeat F/X series 05.57.14 Join eevan [0] (~eevan@telesto.hot-chilli.net) 06.21.55 *** Saving seen data "./dancer.seen" 06.22.44 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 07.09.50 Quit J_Darnley (Ping timeout: 256 seconds) 07.11.07 Part eevan 07.12.10 Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be) 07.18.25 Quit Barlow (Quit: leaving) 08.00.16 Quit pamaury (Ping timeout: 256 seconds) 08.01.33 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 08.01.34 # speachy: one question about usb driver buffers. MTP specifies only one party can be sending on either data line at a time 08.02.02 # so conceivably i could use a single buffer to read the IO stream into since the protocol doesn't allow flows to be fixed 08.02.45 # but would this cause problems? i don't know if the usb send/recv functions would read/write to the buffer when i didn't expect them to 08.02.49 # let alone finish using them 08.22.00 *** Saving seen data "./dancer.seen" 09.00.42 Join Barlow [0] (~barlow@unaffiliated/barlow) 09.16.11 # braewoods: remember that all USB stuff is host-initiated. so if there are multiple operations in flight, it's because the host did it. 09.16.56 # speachy: so my data will sit in a buffer until the host requests it? 09.17.29 # given that you'll only have data in your buffer because the host asked for it, yes. 09.18.10 # and yes, it will sit there staged until the host sends the "Read from the BULK OUT" endpoint. 09.19.29 # speachy: next question, if i call the send/recv function with a buffer larger than packet size, will the driver callback be called multiple times or what? 09.20.18 # the low-level driver is supposed to handle that internally, only calling the upper level's callback once the transfer is completed (or failed) 09.21.12 # so 09.21.31 # once all the data has been sent or the read buffer partially filled? 09.22.01 # depends how much traffic is being generated on one end 09.46.11 Quit koniu (Ping timeout: 268 seconds) 09.50.02 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 09.56.34 # when the logical operation is "complete" 09.56.55 # each transfer has a defined size, known in advance by the sender. 09.57.40 # speachy: ok 10.00.51 # speachy: i also noticed usb_storage allocates a relatively large buffer, 64k on many targets, usually in the IRAM 10.01.05 # how much does that leave for something like MTP? 10.01.57 # i'm assuming i will need to allocate my io buffers in IRAM as well 10.06.45 Quit Xeha (Ping timeout: 246 seconds) 10.07.04 # you could always just re-use the usb_storage buffer. 10.07.11 # it's not like both will be using it simultaneously 10.07.29 Join Xeha [0] (~Xeha@unaffiliated/xeha) 10.16.58 Join MrZeus_ [0] (~MrZeus@89.238.130.71) 10.22.03 *** Saving seen data "./dancer.seen" 10.27.48 Quit GeekShadow (Changing host) 10.27.48 Join GeekShadow [0] (~antoine@82-64-164-139.subs.proxad.net) 10.27.57 Quit GeekShadow (Changing host) 10.27.57 Join GeekShadow [0] (~antoine@unaffiliated/geekshadow) 10.36.53 # speachy: that'll require refactoring 10.36.59 # speachy: it's currently private 10.37.15 # doesn't matter right now anyway. IRAM is purely optimization (or for targets that need to DMA out of IRAM) 10.38.04 # in any case i'm planning to try to use MTP for other things than just file transfers 10.38.24 # i discovered you can do a lot with it 10.38.45 # it has some device properties i could tie to RB internals like the RTC 10.39.00 # in theory allowing the host to set the RTC 10.39.17 # that could be useful for synchronizing the RTC 10.39.54 # given the lack of networking that seems like a useful feature 10.40.48 # braewoods do you think that some optimizations can be done afterward regarding the rockbox db reindex and MTP ? 10.41.08 # basically if I transfer only a few new songs, to directly add them to the internal DB 10.41.17 # edhelas: possibly, i'm not sure. 10.41.26 # MTP does mean we can know exactly what was changed 10.41.56 # right now i'm just planning out how to roll it out 10.42.04 # okay :) 10.42.11 # the most promising reference implementation so far is one that was written for microcontrollers 10.42.29 # closest target to rockbox 10.42.39 # the rest run in Linux userspace 10.43.20 # in any case i'll worry about file IO performance later 10.43.29 # i don't know how slow it will be but 10.43.43 # i'll compare it to how slow UMS is at file copying 10.43.54 # best benchmark i can think of 10.44.44 # my main concern is integrating with dircache and all 10.44.55 # otherwise enumerating the files is going to be slow 10.48.13 # edhelas: i'm also exploring the possibility of having a secondary mode to MTP, some basic remote control possibilities for playback 10.48.36 # may as well make the most of this work 10.48.56 # it's easier to use MTP to add that extra stuff than implement something else 11.04.09 Quit pamaury (Ping timeout: 246 seconds) 11.21.56 # <_bilgus_> __builtin, I think micro python could be done given initiative, assuming enough ram 11.24.47 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach) 11.53.40 Quit Saijin_Naib (Disconnected by services) 11.53.50 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-855f-b256-ad1a-e2c8.res6.spectrum.com) 12.20.26 Quit Saijin_Naib (Ping timeout: 264 seconds) 12.22.06 *** Saving seen data "./dancer.seen" 12.27.22 Join jdarnley [0] (~J_Darnley@d51A44418.access.telenet.be) 12.28.23 Quit J_Darnley (Ping timeout: 245 seconds) 12.33.52 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-855f-b256-ad1a-e2c8.res6.spectrum.com) 12.37.39 # oh, here's a thorny bug just reported. fs#13272 12.37.40 # https://www.rockbox.org/tracker/task/13272 xDuoo X3ii: sound setting for max-vol-limit is ignored (bugs, unconfirmed) 12.38.23 # it's because the max-vol-limit expecte dB, but the hardware uses db/10. and major mismatch. 12.38.38 # normal settings don't have a notion of decimalization. 12.41.26 Quit Saijin_Naib (Disconnected by services) 12.41.30 Join Saijin-Naib [0] (~Saijin_Na@2603-7081-1d05-7230-855f-b256-ad1a-e2c8.res6.spectrum.com) 12.57.16 # Build Server message: New build round started. Revision 92a0ab8789, 293 builds, 9 clients. 13.15.43 # Build Server message: Build round completed after 1107 seconds. 13.15.52 # Build Server message: Revision 92a0ab8789 result: All green 13.15.53 # Build Server message: New build round started. Revision 6b39e23074, 293 builds, 9 clients. 13.19.10 Join johnb3 [0] (~johnb2@p4fd10236.dip0.t-ipconnect.de) 13.26.26 Quit Saijin-Naib (Ping timeout: 264 seconds) 13.28.06 Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be) 13.28.56 Quit jdarnley (Ping timeout: 256 seconds) 13.30.21 # Build Server message: Build round completed after 870 seconds. 13.30.23 # Build Server message: Revision 6b39e23074 result: All green 13.30.24 # Build Server message: New build round started. Revision 99383a0f9b, 293 builds, 9 clients. 13.46.46 # Build Server message: Build round completed after 981 seconds. 13.46.48 # Build Server message: Revision 99383a0f9b result: All green 13.57.42 Quit KalBot (Remote host closed the connection) 13.57.47 Quit johnb3 (Ping timeout: 256 seconds) 13.58.00 Join KalBot [0] (~matrixirc@connolly.tech) 14.22.10 *** Saving seen data "./dancer.seen" 14.31.28 Join Acou_Bass [0] (~Acou_Bass@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) 15.09.55 Join jdarnley [0] (~J_Darnley@d51A44418.access.telenet.be) 15.12.01 Quit J_Darnley (Ping timeout: 256 seconds) 16.05.57 # <__builtin> we definitely have enough ram on most, if not all targets 16.06.11 # <__builtin> minus the tiny 2 or 8MB targets 16.11.21 Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be) 16.12.23 Quit jdarnley (Ping timeout: 260 seconds) 16.12.39 Join chrisb [0] (~chrisb@unaffiliated/chrisb) 16.22.12 *** Saving seen data "./dancer.seen" 17.15.51 Quit cockroach (Quit: leaving) 17.24.00 # any way to repair the selector wheel on a sansa e200 ? 17.24.49 Join chris_s [0] (5fdf48e9@ip-95-223-72-233.hsi16.unitymediagroup.de) 17.28.39 # I wanted to create a repo on Github to use the current version of Rockbox as a starting point for a few more opinionated changes I'd like to keep track of and potentially offer to others, like remove boot logo/shutdown message, simplify a lot of menu entries, turn off wrap around in menus, turn off reset when Hold function is activated, change the 17.28.40 # iPod keymap to more closely resemble the OF etc. Little details like that. 17.28.40 # So, mainly things that I'm guessing aren't fit for inclusion in the main Rockbox repo (although I intend to put anything up on Gerrit that I think has potential to be included). 17.28.41 DBUG Enqueued KICK chris_s 17.28.41 # What's the proper etiquette here? Is it fine to clone --bare the current version and upload to a new Github repo from that. I would leave pretty much everything intact, expect put a new name in the Readme and mention that it's a (barely) modified version of Rockbox, licensed under the same terms. I'm assuming it's fine that all of the contributors 17.28.41 # and git history would still appear in the new repo? 17.28.42 *** Alert Mode level 1 17.28.42 # I first thought about forking, but that doesn't seem to make much sense when the original repository is read-only and thus doesn't accept pull requests? 17.38.13 # chris_s: So do you want your changes to be accepted, or do you just want to make a fork? 17.38.43 *** Alert Mode OFF 17.40.02 # It's licensed under gplv2, so it's fine if you fork it, you just have to keep it free software and keep credits/copyright of the original project. I don't see anything wrong doing that. If it's just for your own personal preferences, you don't _have_ to share it, but I get it if you want to. 17.40.06 Join calebccff [0] (~calebconn@connolly.tech) 17.40.06 # chris_s: forking the readonly github mirror seems like the most sensible approach. If you want to propose patches you can just add the gerrit as a new remote and push them there. 17.40.20 # I think a lot of these changes are unlikely to be accepted but would still be useful to a subset of users (like myself) 17.40.36 # I see. 17.40.47 # I'd argue that if you're planning on making changes that you think improve the UX for you and potentially others, upstream would probably want those changes 17.40.55 # Yes, I've proposed patches in Gerrit and will continue to do so for things that have potential to be accepted 17.41.52 # There's some disconnect between "I'd like to make this changes to improve the experience" <-> "I don't think these changes will be accepted upstream so I won't bother preparing / submitting patches" 17.44.53 # Certainly stuff like disabling scroll wrapping and modifying the iPod key maps would be nice additions. I've noticed certainly some of the nuance of navigation on the iPod classic is lost because all iPods use the same bindings (it's just, CLICKWHEEL). 17.45.04 Quit lebellium (Quit: Leaving) 17.45.30 #  I guess there's no reason to not *also* upload my changes to Gerrit. It just seems like decisions like the iPod keymap have been made based on having a shared experience across different players which is not something I would want to focus on in my own build 17.46.27 # So I'd rather have the Menu button go up a level and return to the browser from the WPS when it'S pressed instead of going to the root menu 17.49.18 # chris_s: most of these things sound like they could just be added to the settings menu, you could add an API to support keymap profiles and then build in an OF vs Rockbox iPod profile and give the user an option to switch between them. Or not even go that far, and just add the option to make the menu button behave like it does in OF 17.49.42 # The former sounds like it would actually be a net-gain for RB, customisable controls would be awesome to have 17.51.39 # I guess, although I don't know how much work that would be, plus documenting the resulting behavior could become a hassle 17.54.39 # Forking and making hard-coded changes requires that setup your own releases and maintain them, or force users to build RB themselves, it also means if you stop maintaining it then everyone using your custom build suddenly stops being able to update and keep your customisations. In the long run making changing that can land upstream and benefit everyone is the much better approach imho, once it's done it's done and you aren't duplicating infrastructure 17.54.39 # that already exists 17.55.35 # Of note, if you wanted to work on making those changes in a configurable way I'd totally be down to contribute, being able to customise the controls and a few of the other bits you mentioned would be really nice. But, it wouldn't be worth switching to a fork for 18.03.23 # I tried both diska and diskb 18.03.40 # Boosted MSX2 EN 18.05.26 # the command I sued was `diskmanipulator create 0.dsk 720` 18.05.35 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-855f-b256-ad1a-e2c8.res6.spectrum.com) 18.07.55 Quit Saijin_Naib (Disconnected by services) 18.07.59 Join Saijin-Naib [0] (~Saijin_Na@2603-7081-1d05-7230-855f-b256-ad1a-e2c8.res6.spectrum.com) 18.20.27 # calebccff: Good points. I may have been unclear before. I'm *already* using a modified build with these (and a few more) changes, so it isn't any additional work for me to publish and offer them to others. I then may or may not add to them in the future. So it's basically just a question of whether I keep that to myself or at least provide the 18.20.27 # option for others to see the code changes. Probably wouldn't even bother with releases but require people to build their own version, which still seems better than nothing. But maybe it's easy enough for anyone who is able to compile their own build to make these minor adjustments (or adjustments that fit their preferences) themselves. 18.22.15 *** Saving seen data "./dancer.seen" 18.22.19 Quit Saijin-Naib (Read error: Connection reset by peer) 18.23.25 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-9806-e0a6-26b3-5304.res6.spectrum.com) 18.24.42 # Sorry I sent this to the wrong channel 18.25.04 # chris_s: well, it is of course your choice. I don't really see the point in forking just to make customisations that should just be included as user configurable settings 18.37.00 # The problem is that you end up adding tons of options. How do you reconcile an attempt to simplify the UI with the requirement to add more settings? There's always a tradeoff here. The advantage of an "opionated" version is that you can throw out lots of stuff. 18.59.06 # chris_s: If you want to make an opinionated version, then good. If you want to make it so others can use your changes without using a fully different version than what they're already using -- you'll also have to maintain a new version of rb. I don't know, sorry, it just seems to me like it would be better if the majority of it was available for main users of rb, and if someone wanted to, they 18.59.08 # could use your version. 19.04.43 # yeah 19.08.36 Quit chris_s (Quit: Connection closed) 19.08.51 Join christian [0] (~christian@2a02:908:1e5:43c0:7c8c:cdb7:195e:8fcc) 19.09.05 Quit christian (Client Quit) 19.18.27 Join chris_s [0] (5fdf48e9@ip-95-223-72-233.hsi16.unitymediagroup.de) 19.18.33 # thanks for your feedback! 19.18.48 Quit chris_s (Client Quit) 19.32.26 # chris_s: have a look at Igor Poretsky's fork, he's already done some of the changes you're talking about (or at least similar changes) 19.33.45 # all else being equal I'd prefer to have stuff in the mainline than not, but as calebccff said, it's Free Software. As long as you don't claim to be "The One True RockBox(tm)" then it's all good. 19.33.57 # I think he letf speachy 19.33.59 # *left 19.34.11 # he'll be back, and he checks the logs too. :) 19.34.18 # oh I didn't know that 19.36.04 # Build Server message: New build round started. Revision 2d8e0f7c90, 293 builds, 9 clients. 19.37.10 Join chris_s [0] (5fdf48e9@ip-95-223-72-233.hsi16.unitymediagroup.de) 19.37.28 # speachy: ok, thanks. Indeed, I should use a proper IRC client (instead of the web version) one of these days so I don't have to check the logs incessantly... :D 19.38.06 # Weechat best client :) 19.38.55 # at the end of the day, the more folks hacking on Rockbox the better. We have very few contributiors as it is, and I'd greatly prefer to keep everyone under the same roof. 19.40.22 # (y) 19.41.08 # chris_s: your changes thus far have all been pretty sane, and reasonable in intent. 19.41.13 # I would like to contribute to rockbox, but I have no idea which dap to buy. 19.41.24 # bbiaf 19.43.13 # hmm? 19.46.20 Join jleightcap [0] (~jleightca@c-174-60-161-106.hsd1.pa.comcast.net) 19.54.32 # One of the later iPods seems like a safe choice (Mini, 4g, 5g, or classic – I'm actually a fan of the monchrome displays), but I think everybody probably has their own preference and I have zero experience with any other players. The classic is supposedly a pain to get into if you want to upgrade the battery or storage. 19.54.57 # Build Server message: Build round completed after 1132 seconds. 19.54.59 # Build Server message: Revision 2d8e0f7c90 result: All green 19.58.06 # can confirm, spent 5 hours cracking open my classic. once you get the technique down it's ok though. well worth it, fantastic device 20.02.22 # fmlatghor: the list of supported and unstable targets on the main page is a good place to start 20.03.19 # chris_s: one thing I should point out -- have a look at https://build.rockbox.org/dev.cgi 20.04.09 # we get a good running indication of the size impact of each addition 20.04.59 # it's not as critical as it once was but on targets with less RAM it matters. 20.06.13 # ok, makes sense :/ 20.10.14 # speachy: yea I was trying to filter stuff out of that, but I ended up just starting over because the ones I was left with were hard to find at good prices 20.12.31 # why would the binary size change after a manual update (043e8a0c) or am I reading this incorrectly? 20.17.05 # (and RAM as well) 20.17.11 Quit jleightcap (Ping timeout: 265 seconds) 20.17.34 Join jleightcap [0] (~jleightca@2601:98a:300:49c:e5dd:6237:21b5:94af) 20.19.25 # fmlatghor: and what are you looking for? 20.19.52 # i rebuild old RB compatible players from time to time 20.20.29 # waiting on a yh-925 and its parts right now since it might be better than my current players for USB development due to the hardware reset button it has 20.21.57 # i still own some units i have finished my development work for 20.22.10 # or just keep around to test that RB is still working 20.22.17 *** Saving seen data "./dancer.seen" 20.22.35 # there's a risk some ports break from changes we do 20.29.01 # braewoods: I'm looking for a cheap player. I just want to be able to play flacs and mp3s, being able to display album art would be nice, but not required. 20.29.16 # fmlatghor: define cheap 20.29.24 # I don't know, what's cheap for you? 20.29.42 # less than $100 with all included parts to repair to proper working order again 20.29.42 # Just not $200? 20.29.56 # braewoods: basically 20.30.14 # album art... you'd want a color screen if you want that 20.30.17 # well something like that 20.30.35 # braewoods: Well I don't need that. If it's cheaper without it, then I'd be fine with that. 20.30.55 # there's a lot of models. do you want USB OTG? 20.31.01 # not all RB targets support it 20.31.21 # it enables access to the software driven stack, like the HID driver 20.31.44 # I'm still not sure why I'd want usb otg 20.31.59 # there's not much use for it right now but in time there will be 20.32.05 # For example, I don't even know what the HID driver is 20.32.09 # i'm working on extending the available driver set with things like MTP 20.32.35 # HID, it lets rockbox pretend to be an input device so you can send input events to your host 20.32.37 # PC 20.32.39 # w/e 20.32.42 # mouse, etc 20.32.52 # I think I understand somewhat. 20.32.58 # and why would you want to do this? 20.33.25 # no reason really, it's not all that useful. i extended it recently to add battery reporting on Linux. 20.33.46 # w/e is whatever? 20.33.48 # i plan to add some kind of remote control over USB later for supported targets 20.33.50 # yea 20.34.08 # if you don't care then not worth going into 20.34.12 # had to look that one up 😅 20.34.20 # No I don't think that's worth it for me 20.34.37 # It sounds cool, but I don't need cool 20.34.44 # the iriver h100 series is pretty easy to service for the most part 20.34.51 # has lots of outputs 20.34.55 # grayscale screen though 20.35.01 # the internal storage can be CF modded 20.35.14 # it has USB UMS 20.35.20 # hardware usb basically 20.35.26 # uses standard ports for everything 20.35.32 # no proprietary dock connector 20.35.50 # sounds great 20.36.00 # I am looking for it on ebay at the moment 20.36.37 # the H120 and H140 are the common models 20.36.46 # though i've seen H120 more often 20.37.17 # it has fm radio i believe 20.37.19 # no RTC chip 20.37.27 # what about AM? 20.37.35 # no rockbox ports have AM radio support 20.37.51 # Well unfortunately there aren't many good radio stations I know of, only a handful good ones 20.38.21 # just need to be careful, there's overpriced units on ebay 20.38.31 # braewoods: That would be the steal though 🤣 20.38.40 # lol 20.38.49 # AM is pretty wacky though 20.39.05 # i bought the yh-925 for usb development 20.39.10 # whenever I have a radio in front of me I just browse AM 20.39.14 # no radio chip in it 20.39.22 # no idea why 20.39.24 # but w/e 20.39.32 # don't need it for my intended use 20.39.37 # Wish I could use my calculator for music, but that would be inconvenient, even though it would be possible to make it possibel. 20.39.41 # *possible 20.42.00 # fmlatghor: would you prefer to buy one of my old units that I already repaired? 20.42.10 # braewoods: SUre 20.42.16 # *Sure 20.42.27 # How should we do this? 20.42.38 # well i'll start with what i still have 20.42.44 # Alright 20.43.09 # i have 2 iriver h120s that i replaced the battery and upgraded the storage on 20.43.18 # i used them for testing my new bootloader work 20.43.29 # the OF is no longer compatible with them, not that it matters 20.43.34 # they have 64GB CF cards installed 20.43.44 # you can upgrade it by replacing the card 20.43.53 # but you need special screw driver to open these 20.44.17 # some torx screwdriver 20.44.39 # yea I'll just put in my microsd card if that's possible 20.44.42 # oh, i guess you could buy a sansa fuze+ from amazon... they still have some new old stuck 20.44.53 # you might be able to with a CF adapter 20.45.10 # just these older players have more expandability 20.45.28 # I see (Discontinued by Manufacturer) 20.45.35 # https://www.amazon.com/SanDisk-Sansa-Player-Discontinued-Manufacturer/dp/B0041G62RY 20.45.43 # It looks sorta like a phone 20.45.47 # you can upgrade via SD card 20.45.48 # chris_s: when stuff gets submitted together in gerrit, it only does a single build that can cover more than one individual commit 20.46.18 # fmlatghor: it kinda is but you can boot from the SD card to prevent wearing out the internal flash 20.46.41 # the battery is soldered so it won't be easy to replace if it wears out 20.46.53 # ah so it does support flac without rockbox, but I intend to use free software not the proprietary garbage it comes with 20.47.09 # fmlatghor: depends on your budget ultimately, but if you want something that's available new now, you're basically limited to the xduoo x3ii, eros q/k (and clones), and (eventually) the fiio m3k too. 20.48.17 # fmlatghor: i use a barrel jack to usb adapter to charge my iriver h120, same voltage just no need for the original bulky ac adapter 20.48.36 # i have a fuze+ 20.48.45 # it's good for testing OTG 20.48.56 # but i ran into problems where i couldn't reset it once 20.49.08 # my code broke it and i couldn't even reset it 20.49.13 # had to let the battery die to salvage things 20.49.50 # i do not recommend the philips gogear ports 20.49.57 # royal pain to service and very cramped inside 20.50.02 # compared to the iriver h120 for example 20.50.25 # the simpler battery also helps 20.50.40 # fmlatghor: so ultimately it comes down to your budget and what you want to do with it. it really should be something you want to use, or you won't be inclined to try to hack it and make it better. 20.50.56 # fmlatghor: the iriver H120 can replace the proprietary OF entirely even the bootloader 20.51.08 # it's one of the few port where we can do that 20.51.19 # speachy: true, I tend to hack on the hardware I own that I like the most 20.51.36 # I find it very hard to recommand the fuze+ due to it's awful controls. 20.51.39 # the fuze+ isn't too hackable 20.51.58 # speachy is right, it's awkward to use but doable 20.52.08 # the iriver h120 is pretty nice even though it lacks RTC and USB OTG 20.52.08 # hmmm 20.52.22 # the YH-925 has some good things too, just no FM radio 20.52.26 # my main criteria are native line out and controls that are easily operable without looking. 20.52.46 # and a battery that lasts at least four hours. 20.52.52 # ah, not many have line out 20.52.54 # the h120 does 20.53.10 # unless you consider headphones to be line out 20.53.17 # well I use my phone now, but I really don't like my phone, so that's why I am here now 20.53.36 # the H120 is a good port, even if it lacks some features 20.53.52 # Ok I will consider that one 20.54.02 # just not much to develop on it at this point 20.54.05 # only drawack lol 20.54.06 # h1xx and h3xx are really mature, stable platforms. Just limited by the inevitable march of time. 20.54.29 # I see, so not much hacking on them, but good players 20.54.31 # i largely solved the main issue those ports had 20.54.40 # their bootloaders hadn't been updated with modern fixes 20.54.59 # the only thing the H300 is missing is OTG support 20.55.08 # but it's a weird player that makes it unlikely to be implemented 20.55.23 # the OTG chip is documented but 20.55.33 # it has 2 micro usb ports 20.55.43 # so integrating that with the RB stack won't be easy 20.55.47 # RB assumes at most one usb port 20.55.56 # so that's one issue 20.56.13 # the other issues is it would mean a split hardware/software usb stack 20.56.41 # not to mention the iriver h300 is big endian whch probably means fixes to the usb stack we have 20.56.53 # to ensure the byte we write over usb are little endian 20.58.40 # braewoods: all this assumes fmlatghor is interested in hacking the USB stack. 20.58.59 # Yes, the question is do I want to do that 20.59.09 # fmlatghor: was there something specific of interest that led you to this? 20.59.18 # led me to what? 20.59.23 # the h120? 20.59.26 # to rockbox, that is. 20.59.34 # and/or the desire to hack on it 21.00.42 # What lead me to rockbox is because a while a go I found a link to rb in a subreddit thread. My desire to hack rb is just because I like to hack the devices I own, mainly calculators and limited hardware. 21.01.10 # I actually forgot how I found it until recently when I read the backlog (in my client). 21.01.44 # pick a player that appeals to you (price +interface-wise) and as you use it, I'm sure you'll find yourself wanting to poke at or otherwise tweak things. 21.02.15 # and if you want to undertake somethign ambitious, patches welcome. :D 21.03.07 # speachy: That is good advice; I will have to look more at the devices you and braewoods recommended. 21.03.27 # speachy: heh I would love to submit patches, but I don't think my code is ready to see the world. 21.05.08 # fmlatghor: no prior C experience 21.05.09 # remember you don't _have_ to contribute anything 21.05.10 # ? 21.05.30 # as long as you find rockbox useful 21.08.29 Quit chris_s (Quit: Ping timeout (120 seconds)) 21.24.08 # braewoods: you didn't have prior, or I don't? 21.25.36 # speachy: well, yes, I don't have to contribute anything -- I probably won't unless something's broken and I want to fix it, or some optimising. I doubt I'll really want much new features. 21.41.46 Quit MrZeus_ (Ping timeout: 260 seconds) 21.53.50 # fmlatghor: i was asking if you'd ever used C before basically. 21.53.58 # fmlatghor: since most of RB is C... 21.53.58 # braewoods: I have 21.54.25 # I just don't think I'm very good at it and need to gather more experience. 21.54.54 # i've used it for years in user space just not too familiar with embedded C 21.58.16 # i have to say though it was kinda weird working on the bootloader 21.58.37 # writes to special memory locations triggers hardware side effects is an odd experience 21.59.03 # in userspace writes to memory don't do things like that 21.59.17 # you have to perform system calls to cause things to happen external to your program 22.22.20 *** Saving seen data "./dancer.seen" 22.34.29 # fmlatghor: just look through the old targets that are stable, just note some are much rarer than others 22.34.29 # me 22.34.32 # oops 22.34.57 # i managed to arrange to buy a gigabeat S series off another developer. they're super rare. 22.35.13 # there's only 2 on ebay, $120+ 22.35.20 # assuming that's even a reasonable price 22.35.41 # it's a very featureful player though for its age. 22.35.49 # 64MB of RAM 22.36.04 # FM radio with RDS (few rockbox targets support it) 22.36.16 # I've considered getting one of the monochrome ones because of how it looks, but yea hard to find 22.36.16 # etc 22.36.36 # you want monochrome? 22.36.38 # Reminded me of the z80 series monochrome ticalcs 22.36.47 # I mean, kinda, but I don't need it 22.36.50 # you might like the YH-920, it's grayscale 22.36.51 # just how I don't need album art 22.36.56 # but I like it 22.36.59 # but has fm radio 22.37.18 # there's still plenty to innovate on the general USB stack 22.37.40 # i'm currently working on MTP 22.37.49 # eventually i would like to see if we can add USB Audio 22.38.01 # the use for it is somewhat obvious 22.45.14 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 22.58.06 Quit calebccff (Quit: Idle timeout reached: 10800s) 23.00.57 Quit ac_laptop (Ping timeout: 246 seconds) 23.18.55 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00) 23.28.46 Join f1reflyylmao [0] (~f1refly@dynamic-077-003-195-217.77.3.pool.telefonica.de) 23.29.19 Quit f1refly (Ping timeout: 272 seconds) 23.29.19 Nick f1reflyylmao is now known as f1refly (~f1refly@dynamic-077-003-195-217.77.3.pool.telefonica.de)