--- Log for 06.10.121  Server: cadmium.libera.chat  Channel: #rockbox
--- Nick: rb-logbot  Version: Dancer V4.16  Started: 3 days and 0 hours ago

00.17.08 ***     Saving seen data "./dancer.seen"
01.40.32 Join    ZincAlloy [0] (~Adium@2a02:8108:943f:d824:c9cc:e847:1c24:93c2)
01.44.01 Quit    advcomp2019 (Read error: Connection reset by peer)
01.44.41 Quit    ZincAlloy (Ping timeout: 245 seconds)
01.58.35 Join    advcomp2019 [0] (~advcomp20@user/advcomp2019)
02.17.09 ***     Saving seen data "./dancer.seen"
02.39.30 #       <spork> the 'daily development builds' page lists all voice files for the agptek rocker, most for the aigo eros q/k but none for any of the other devices
02.41.07 #       <spork> on the linked 'older builds' page, they are all listed though
04.17.12 ***     No seen item changed, no save performed.
04.45.33 Quit    johnb2 (Quit: Nettalk6 - www.ntalk.de)
05.57.10 #       <MarcAndersen> spork, Right now I can see all the voices
06.00.02 Join    asaba [0] (~asabas@103.113.159.250)
06.01.04 Quit    asabas (Ping timeout: 252 seconds)
06.07.03 Quit    MarcAndersen (Remote host closed the connection)
06.15.28 #       <speachy> spork: "Please note that generating these new builds takes upwards of a couple of hours, and if you visit this page while builds are in progress you may see it only partially updated.
06.15.30 #       <speachy> Please check back later if what you want is missing, or use the 'older builds' links to grab something from a previous daily build.
06.17.14 ***     Saving seen data "./dancer.seen"
06.23.12 #       <speachy> ...so sayeth the daily build page
07.07.37 #       <spork> ok then
08.17.16 ***     No seen item changed, no save performed.
08.51.49 Join    massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
09.00.35 Join    greengameplayer [0] (~james@proxy18.d94.org)
09.40.06 Quit    greengameplayer (Ping timeout: 245 seconds)
09.40.52 Join    greengameplayer [0] (~james@2607:fb90:17ce:dc98:18d3:136:473e:f35c)
09.48.11 #       <_bilgus> speachy do we have the admin login on the wiki or could you admin me, I don't know that I have it fully grasped but it doesn't appear to be rocket surgery
09.48.53 #       <_bilgus> Or maybe thats more hassle if you already got ideas up to you..
09.50.06 Quit    greengameplayer (Ping timeout: 245 seconds)
09.53.42 #       <speachy> I'm not likely to get anything further done until next week.  tomorrow I'm off for a long weekend in the woods.
09.59.45 Join    greengameplayer [0] (~james@2607:fb90:17ce:dc98:18d3:136:473e:f35c)
10.17.18 ***     Saving seen data "./dancer.seen"
10.17.45 #       <speachy> bbiab
10.17.47 Quit    speachy (Quit: WeeChat 3.2)
10.21.33 Quit    greengameplayer (Quit: Konversation terminated!)
10.28.33 Quit    massiveH (Quit: Leaving)
10.40.42 #       <_bilgus> browser crashed I'll try again tonight I'm trying to get it working in the sandbox first
12.06.47 Join    ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de)
12.11.20 Quit    ZincAlloy (Ping timeout: 265 seconds)
12.17.20 ***     Saving seen data "./dancer.seen"
12.38.50 Join    ZincAlloy [0] (~Adium@2a02:8108:943f:d824:74b2:23df:945c:7532)
13.09.50 Quit    kirvesAxe (Ping timeout: 260 seconds)
13.09.59 Join    kirvesAxe [0] (kirvesaxe@user/kirvesaxe)
13.11.39 Join    lebellium [0] (~lebellium@2a01cb04012c09000d0085ffcb0230e5.ipv6.abo.wanadoo.fr)
13.35.40 Join    speachy [0] (~speachy@rockbox/developer/speachy)
13.35.40 Mode    "#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat)
14.17.23 ***     Saving seen data "./dancer.seen"
14.45.37 Quit    speachy (Quit: Connection closed)
14.46.34 #       <_bilgus> that x1000 prescaler amachronic nice catch
15.13.39 Quit    unmanbearpig (Ping timeout: 245 seconds)
15.32.43 #       <_bilgus> I realized with the way that I hash paths to open plugins will cause issues when later we let the .rockbox directory move around
15.34.09 #       <_bilgus> instead I think I will start hashing on everything after /.rockbox/
15.36.36 #       <_bilgus> Cureently I'm working on a perl script to generate the hashes at compile time that way I can use that at compile time to run things like the pitch plugin
15.37.32 #       <_bilgus> with relative path..
15.38.09 #       <_bilgus> '/rocks/apps/pitch_plugin.rock'
15.47.25 Join    unmanbearpig [0] (~unmanbear@user/unmanbearpig)
16.17.25 ***     Saving seen data "./dancer.seen"
16.29.04 Join    amachronic [0] (~amachroni@user/amachronic)
16.35.30 #       <amachronic> i've written a UASP mass storage driver, it's up on gerrit now if anyone wants to take a look.
16.38.09 #       <rb-bluebot> Build Server message: 3New build round started. Revision 465c216636, 303 builds, 12 clients.
16.46.49 #       <rb-bluebot> Build Server message: 3Build round completed after 520 seconds.
16.46.50 #       <rb-bluebot> Build Server message: 3Revision 465c216636 result: All green
16.49.53 #       <braewoods> amachronic: is that the newer usb driver?
16.50.04 #       <braewoods> vs BOT
16.50.07 #       <amachronic> yeah
16.50.26 #       <amachronic> it's improved read perf quite significantly on the m3k / q1. not so much for writes.
16.50.27 #       <braewoods> how'd you make that work? last i checked it requires more endpoints on USB 2.0
16.50.45 #       <amachronic> well, the x1000 SOC has 9 endpoints or something.
16.50.56 #       <braewoods> i see.
16.51.00 #       <amachronic> UAS only requires one extra in/out endpoint pair vs BOT though.
16.51.14 #       <braewoods> but a lot of our older targets can't use UAS
16.51.22 #       <braewoods> so we'll have to keep the BOT driver
16.51.41 #       <braewoods> mostly due to their endpoints being limited to 3
16.51.49 #       <amachronic> yep, I don't intend to replace it
16.52.13 #       <braewoods> if this works out though it should probably replace the old driver for supported targets
16.52.50 #       <braewoods> i'd suggest just making it a compile time decision myself
16.53.01 #       <braewoods> based on whether the target can even support it
16.53.19 #       <braewoods> and treat mass storage everywhere else the same
16.53.39 #       <amachronic> of course, I have a define to enable it
16.53.43 #       <braewoods> it behaves more or less the same as far as the host is concerned
16.53.56 #       <braewoods> and UAS is old enough that it's supported pretty much everywhere now
16.54.32 #       <amachronic> probably, but eventually I would like to set it up in the backward compatible mode with UAS on an alternate interface.
16.54.57 #       <braewoods> fallback to BOT if you can't allocate the extra endpoints needed for UAS?
16.55.26 #       <braewoods> that would probably work even better.
16.55.27 #       <amachronic> that, and support non-UAS hosts
16.55.47 #       <amachronic> it's a standard backwards compatibility thing in the spec but it's just not easy to do with RB's driver model.
16.55.56 #       <amachronic> it lets non-UASP hosts just use the BOT interface
16.56.10 #       <braewoods> i don't consider that essential myself
16.56.10 #       <amachronic> UASP hosts will see the alternate setting and switch
16.56.37 #       <braewoods> non-UASP hosts in the context of rockbox isn't likely
16.56.53 #       <braewoods> most people are connecting to a PC or similar that should already support UAS
16.57.08 #       <amachronic> yep. just me being paranoid :)
16.57.36 #       <amachronic> "i updated rockbox now it doesn't connect to computer"
16.57.37 #       <braewoods> the bigger question is whether the hardware supports it
16.58.24 #       <amachronic> USB-wise, you just need one extra IN and one extra OUT endpoint.
16.58.34 #       <amachronic> I figure most targets which can do USB HID will be able to use it
16.58.56 #       <amachronic> although those which are low on EPs might not be able to do HID+UAS at the same time
16.59.18 #       <braewoods> many targets would struggle to do MTP
16.59.45 #       <braewoods> i'm considering adding MTP at some point but it's going to require some more work...
16.59.52 #       <braewoods> are those usb driver API changes in yet?
17.00.23 #       <amachronic> no, speachy was going to review but i don't think he's gotten to it yet
17.00.44 #       <amachronic> bilgus tested it on a couple of sansas
17.01.12 #       <amachronic> so what does MTP need that the USB stack is lacking?
17.01.27 #       <braewoods> MTP requires 3 endpoints. no real issue there.
17.01.40 #       <braewoods> even our weakest targets can handle that.
17.01.58 #       <braewoods> the main issue i saw is MTP detection depends on something our drivers cannot interface with
17.02.15 #       <braewoods> the usb driver decides all the strings and such sent to the host
17.02.32 #       <braewoods> libmtp assumes "MTP" will be in one of these and they're hard-coded in rockbox.
17.02.44 #       <braewoods> ideally we'd only export this string if MTP is actually active
17.02.47 #       <braewoods> to avoid confusing the host
17.03.13 #       <amachronic> that shouldn't be too hard to add.
17.03.29 #       <braewoods> basically, the ability for active drivers to add their own strings to what the core sends to the host
17.04.02 #       <braewoods> most don't need this but some future drivers may
17.04.04 #       <amachronic> basically just adding new string descriptors
17.04.26 #       <braewoods> yea, let me dig and see where it currently resides
17.05.32 #       <braewoods> https://github.com/Rockbox/rockbox/blob/master/firmware/usbstack/usb_core.c#L144
17.05.42 #       <braewoods> MTP detectiong requires an extra string in this list, iirc.
17.06.32 #       <braewoods> heh. speachy loved the change i made to the code to handle the usb string literals differently
17.07.07 #       <braewoods> the new toolchain supported unicode string literals so we use those now. easier to read and edit.
17.08.21 #       <braewoods> amachronic: maybe we could add a few extra slots to the static array that drivers could append their own descriptors to
17.08.32 #       <braewoods> we just need a new way to mark the end
17.08.51 #       <braewoods> don't need to make this incredibly advanced
17.09.53 #       <amachronic> that'd work
17.10.42 #       <amachronic> although I think a callback would also work
17.11.14 #       <amachronic> just reserving slots in the array is probably far simpler. considering only MTP will need it, at first.
17.14.31 #       <braewoods> the code would need adjusting
17.14.52 #       <braewoods> my original solution was just to add it to the existing table but that has one flaw
17.15.08 #       <braewoods> it causes host issues if the MTP driver isn't actually active
17.15.39 #       <braewoods> ideally it won't be sent unless MTP is actually enabled
17.16.11 #       <amachronic> yeah so we'd need an enable/disable hook which is getting messy.
17.16.56 #       <braewoods> it may be simpler to just reserve a few slots and track the number in use instead of using a hard-coded length check
17.17.12 #       <braewoods> and add a function to handle insertion of new string descriptors
17.17.30 #       <braewoods> it just needs to be reset when the drivers are unloaded
17.17.37 #       <braewoods> or something
17.18.08 #       <braewoods> ideally the driver would deallocate its string descriptor and the core will shift the remaining pointers down to fill the empty space
17.18.13 #       <amachronic> I think the main difficulty is the need to know what string gets what index in order to refer to it from other descriptors.
17.18.53 #       <braewoods> maybe a hack will suffice for now.
17.19.19 #       <braewoods> just add an extra one for MTP that's only exposed if MTP is active
17.19.26 #       <amachronic> something similar to set_first_interface() may work
17.19.43 #       <braewoods> to date only MTP has proven to need this
17.19.51 #       <braewoods> so a hack for just MTP would suffice
17.20.07 #       <braewoods> still
17.20.27 #       <braewoods> though now that i think about it
17.20.43 #       <braewoods> do hosts check usb strings that aren't referenced?
17.21.02 #       <braewoods> if not we can just leave the extras as dormant or so.
17.21.27 #       <amachronic> i can't see _why_ they would look at them, unless there is a way to get the total number of string descriptors.
17.21.38 #       <amachronic> do they have to be contiguous?
17.22.08 #       <braewoods> probably not. from the response code it doesn't send them all at once.
17.22.21 #       <braewoods> it sends one descriptor at a time in response to an index value.
17.22.36 #       <braewoods> it's only used in one place
17.22.49 #       <amachronic> and the magic 0xee index for windows' benefit
17.22.51 #       <braewoods> once, to determine the # of entries for determing if the requested index is valid
17.23.05 #       <braewoods> and the rest to load data for sending over usb
17.23.12 #       <braewoods> it only sends one at a time
17.23.21 #       <braewoods> there's no way to request the actual index range
17.23.34 #       <braewoods> so maybe this isn't actually an issue
17.23.58 #       <braewoods> we can hard-code the extra strings and if they're only used when MTP is activ
17.24.02 #       <braewoods> there's no problem to solve
17.24.17 #       <amachronic> seems right to me
17.24.46 #       <braewoods> but for consistency MTP string would have to be present even if not used
17.25.01 #       <braewoods> so its index is the same
17.25.37 #       <amachronic> i know that's no problem
17.26.30 #       <amachronic> you just need to pass the index to the MTP driver
17.26.57 #       <braewoods> or just hard-code so it's always at the same position
17.27.28 #       <amachronic> an enum of all the strings would be ok
17.28.00 #       <amachronic> enum usb_string_index { MANUFACTURER, PRODUCT, MTP_MAGIC, ... }
17.28.17 #       <amachronic> keeps it nicely organized
17.28.46 #       <braewoods> wait that solves my problem
17.28.49 #       <braewoods> LOL
17.28.58 #       <braewoods> let me submit this to gerrit
17.31.31 #       <rb-bluebot> Build Server message: 3New build round started. Revision 67d4da5342, 303 builds, 12 clients.
17.34.05 Join    Syco54645_ [0] (~frank@76.125.141.118)
17.36.11 Join    speachy [0] (~speachy@taster.shaftnet.org)
17.36.11 Quit    speachy (Changing host)
17.36.11 Join    speachy [0] (~speachy@rockbox/developer/speachy)
17.36.11 Mode    "#rockbox +v speachy" by ChanServ (ChanServ@services.libera.chat)
17.36.53 #       <speachy> amachronic: fwiw I think the USB control patches are good.  I've gone through the first 2/3rds but won't be able to look at anythung else until next week (gonna be out in the woods for a few days)
17.38.31 #       <Syco54645_> way off topic but twitch was breached. probably a good idea to change twitch and amazon passwords as well as enable 2fa for them both. sorry for offtopic just want to keep people safe
17.39.09 #       <amachronic> speachy: thanks, take your time. i'm in no rush.
17.39.31 #       <rb-bluebot> Build Server message: 3Build round completed after 480 seconds.
17.39.32 #       <rb-bluebot> Build Server message: 3Revision 67d4da5342 result: All green
17.41.58 #       <rb-bluebot> Build Server message: 3New build round started. Revision 4be81c2385, 303 builds, 12 clients.
17.44.27 #       <braewoods> g#3892
17.44.30 #       <rb-bluebot> 3Gerrit review #3892 at https://gerrit.rockbox.org/r/c/rockbox/+/3892 : 3usbstack: Revise usb string descriptor table to use enum values for indices by James Buren
17.44.57 #       <braewoods> anyone care to review it? it should be simple to review.
17.45.58 #       <amachronic> will do.
17.46.38 Quit    ZincAlloy (Quit: Leaving.)
17.47.18 Join    ZincAlloy [0] (~Adium@2a02:8108:943f:d824:74b2:23df:945c:7532)
17.47.18 Quit    ZincAlloy (Client Quit)
17.48.48 #       <amachronic> braewoods: just one thing missing, update the hardcoded numbers in the descriptor to use the enum values.
17.49.24 #       <amachronic> and I'll merge it after this build round is done
17.49.50 #       <rb-bluebot> Build Server message: 3Build round completed after 473 seconds.
17.49.51 #       <rb-bluebot> Build Server message: 3Revision 4be81c2385 result: All green
17.51.37 #       <braewoods> amachronic: you do realize that's completely superfluous?
17.51.45 #       <braewoods> enums start at 0 and count up
17.52.24 #       <amachronic> haha yes, but I'll do it anyway if you won't :P
17.52.38 #       <braewoods> i was trying for the same approach the usb driver setup does
17.53.10 #       <amachronic> just for consistency, as we're using enums to avoid hardcoded numbers...
17.53.54 #       <braewoods> https://github.com/Rockbox/rockbox/blob/master/firmware/export/usb.h
17.54.16 #       <braewoods> speaking of which i see a refinement
17.54.18 #       <braewoods> sec
17.54.46 Quit    lebellium (Quit: Leaving)
17.55.17 #       <amachronic> sorry braewoods I just realized, I don't mean using explicit = 1, = 2, = 3.
17.55.30 #       <amachronic> I mean changing those hardcoded numbers in the descriptor to use the enum names.
17.56.11 #       <braewoods> amachronic: what do you mean?
17.56.28 #       <braewoods> oh
17.57.29 #       <amachronic> see the comment i added on the patch
17.58.00 #       <amachronic> https://github.com/Rockbox/rockbox/blob/master/firmware/usbstack/usb_core.c#L93
17.58.20 #       <braewoods> pushed
17.59.01 #       <amachronic> ok good, thanks. merging now...
17.59.18 #       <rb-bluebot> Build Server message: 3New build round started. Revision c0a59b9a6a, 303 builds, 12 clients.
18.00.45 #       <braewoods> i also got the idea to use the last entry as the length
18.00.55 #       <braewoods> that was one last minute thing i added
18.01.07 #       <braewoods> it replaced those annoying sizeof hacks
18.01.19 #       <braewoods> they work but less elegant than this
18.02.31 #       <braewoods> now it is more amenable to MTP
18.08.10 #       <rb-bluebot> Build Server message: 3Build round completed after 533 seconds.
18.08.11 #       <rb-bluebot> Build Server message: 3Revision c0a59b9a6a result: All green
18.17.22 #       <speachy> woo, board's finally green again.
18.17.29 ***     Saving seen data "./dancer.seen"
18.28.56 Join    dconrad [0] (~dconrad@208.38.228.17)
18.30.12 #       <dconrad> amachronic: I figured out why git kept marking that line as changed in the AIC FIFO patch...
18.30.28 #       <dconrad> my brain just short circuited and assumed both were in the same place, lol
18.30.35 #       <dconrad> oops
18.31.11 #       <amachronic> lol it's at least harmless & can be fixed later
18.31.45 #       <dconrad> yeah, I'll just put up a quick patch to fix it
18.34.51 #       <dconrad> btw, impressive work on the USB driver, I saw the patchsets, I'll try it out sometime soon
18.36.22 #       <amachronic> cool. although write speeds are still lacking, which is probably the main pain point for anybody using usb.
18.37.26 #       <amachronic> so i will still probably need to implement some kind of write caching layer, which i was hoping not to do
18.37.39 #       <dconrad> could it be an sd card driver limitation?
18.38.02 #       <amachronic> the big problem turned out to be the SD cards themselves need huge write sizes to perform very well.
18.38.31 #       <amachronic> the driver is able to write at 20 MB/sec if you write 512-1024k at a time.
18.38.53 #       <dconrad> that sounds familiar, something about needing to write an entire block at a time?
18.41.23 #       <dconrad> g#3893 if you want to make sure it's sane
18.41.25 #       <rb-bluebot> 3Gerrit review #3893 at https://gerrit.rockbox.org/r/c/rockbox/+/3893 : 3ErosQNative: Remove duplicate play_last_sample() call by Dana Conrad
18.41.30 #       <dconrad> not exactly much to it
18.41.31 #       <rb-bluebot> Build Server message: 3New build round started. Revision e0468074fe, 303 builds, 12 clients.
18.41.43 #       <amachronic> there ya go.
18.41.50 #       <dconrad> that was fast haha
18.41.58 #       <dconrad> thanks
18.41.59 #       <amachronic> was already looking at it :)
18.44.50 #       <amachronic> it's getting late here so... bye bye.
18.45.00 #       <dconrad> good night!
18.45.04 Quit    amachronic (Quit: amachronic)
18.49.10 #       <rb-bluebot> Build Server message: 3Build round completed after 458 seconds.
18.49.11 #       <rb-bluebot> Build Server message: 3Revision e0468074fe result: All green
18.58.14 #       <Syco54645_> _bilgus: i will have a new e200 soon that i can try flashing with rbutil if we still need to test that route. scared to do something and mess up the one i have currently. i am exhausted from the project at work moving to QA and when I am tired i make pretty bad mistakes. in theory i can grab the BL from the download on the daily page and just flash it on to the one i have in recovery mode. at least i think that would work.
19.01.08 Quit    dconrad (Remote host closed the connection)
19.23.39 Join    dconrad [0] (~dconrad@208.38.228.17)
19.24.07 #       <_bilgus> Syco54645_, No worries Johnb was able to verify it worked in rbutil but he says that you don't need the OF to put the bootloader on
19.24.57 #       <_bilgus> We are not sure whats up with yours but I figure you have recovery mode and USB so probably best to leave well enough alone
20.17.30 ***     Saving seen data "./dancer.seen"
20.33.02 #       <braewoods> speachy: i have an unmodified xduoo x3 if you want to release a new bootloader payload to test.
20.33.33 #       <speachy> right now I'm waiting on test results from the one person who reported a problem with the original bootloader.
20.33.43 #       <speachy> otherwise the new one seems to WorkFineForMe(tm)
20.33.54 #       <speachy> (and a couple others too, but none of them had issues before, so...)
20.45.31 Quit    dconrad (Remote host closed the connection)
21.13.13 Join    dconrad [0] (~dconrad@208.38.228.17)
21.14.01 Join    Kemper [0] (~Kemper@097-106-127-245.res.spectrum.com)
21.16.36 #       <Kemper> I've been repairing my Sansa(s) for years waiting to get a new MP3 player to use with Rockbox.  I see that there's lots of work being done to get more platforms.  Thanks to all the devs.
21.18.42 #       <braewoods> Kemper: are you soliciting advice?
21.19.43 #       <Kemper> Yes.  I was going to elaborate but my text just disappeared.
21.20.47 #       <braewoods> what are you looking for specifically
21.20.49 #       <Kemper> I looked at the FAQ and the list of latest devices but the list is pretty dated (2008?).  The timestamp at the bottom of the page is recent though.
21.21.52 #       <braewoods> it's been updated, at least the main one
21.22.51 #       <braewoods> xduoo x3 is probably the most recent stable one added
21.23.29 #       <braewoods> it's basically a more modern version of the basic features the sansas provided.
21.23.46 #       <braewoods> only problem is it is fairly hard to find on ebay
21.24.05 #       <Kemper> I would like suggestions on a currently available device that I can run Rockbox on.  I'll go back to the website and see if I can find the latest list.  The list I saw didn't include the recent xduoo x3.
21.24.38 #       <braewoods> it'
21.24.55 #       <braewoods> it's also a function of how much patience you have and how much you're willing to spend
21.25.58 #       <Kemper> I saw that the xduoo x3 is on the list of  supported devices but not on the list of currently available devices.  Is the xduoo the most recent device and there aren't any others currently available in production?
21.26.22 #       <braewoods> Kemper: to be frank the list of rockbox stuff still in production is a very short list.
21.26.36 #       <braewoods> it's mostly just the fiio m3k and maybe some other ones speachy would know.
21.27.08 #       <speachy> if you want something that's still in production the list is pretty much limited to the fiio m3k, xduoo x3ii & x20, and the eros q / k (& their clones)
21.27.49 #       <speachy> the m3k is a ~$60-70 player, the x20 is ~$200, the rest are ~$120.
21.28.47 #       <speachy> the original x3 is the next most recent; very solid device except for their choice of screen (functionally equivalent to a faster, more capable sansa clip+ in a far, far more robust case)
21.29.11 #       <speachy> those can be found occasionally on ebay etc still for varying prices.
21.29.45 #       <speachy> beyond that, your best bet is probably an older "classic" ipod as they can be modded with flash storage and parts are plentiful.
21.30.38 #       <braewoods> i bought an xduoo x3 just this month
21.30.48 #       <braewoods> they show up at least once a month that i've seen
21.30.49 #       <speachy> anything with non-replacable internal flash is aging out.
21.31.04 #       <Kemper> Ok.  That's good information.  It wasn't clear on the page I saw which units were obsolete and which were still current.  I'd prefer not to have to resort to ebay.  I'd like to buy something new for a change if that's an option.
21.31.05 #       <speachy> (that killed my last two sansas)
21.31.54 #       <speachy> so yeah, m3k (not the m3k pro!), shanling q1, xduoo x3ii & x20, eros q, eros k, agptek h3, hifiwalker h2, surfans f20 (also sold as irulu f20)
21.31.57 #       <braewoods> Kemper: i repair ebay units from time to time. i have a pretty good grasp of the used market. avoid the flash based units, at least the ones that lack external storage.
21.32.10 #       <speachy> I think that's it for stuff that's still readily available new.
21.32.50 #       <braewoods> sansa ones usually have sd cards and can last indefinitely if you find some with minimal wear.
21.33.07 #       <braewoods> thanks to multiboot
21.33.21 #       <braewoods> which puts all the stress on the sd card
21.33.38 #       <Kemper> I have a bag full of dead Sansas of varying age.  I'll check into the other models you guys mentioned.
21.33.54 #       <braewoods> Kemper: if it must be new, the other option is new old stock. those are rare but show up sometimes.
21.34.51 #       <speachy> heh, yeah, I have half a dozen busted fuze/fuzev2s too.  great devices, but physically... not so much.
21.35.11 #       <braewoods> i have several gigabeat S units that i repaired.
21.35.17 #       <braewoods> good condition for their age.
21.35.35 #       <speachy> a shame I didn't keep my fuze+, should have tried to replace the busted screen but the controls were so awful that I was just DONE with it.
21.35.46 #       <braewoods> speachy: you want my fuze+?
21.36.00 #       <braewoods> it's a red 4GB model.
21.36.02 #       <speachy> I'd just add it to the rockbox box o' rockbox
21.36.07 #       <Kemper> I got lucky a couple of times and found a couple of Sansa Clips in unopened packages but I don't think I'll ever get that lucky again.
21.36.34 #       <braewoods> i have some clip+ still. barely used 'em.
21.37.51 Quit    rb-bluebot (Ping timeout: 268 seconds)
21.38.06 Quit    bluebrother (Ping timeout: 250 seconds)
21.38.57 #       <Kemper> I'm unfamiliar with the Fuze+ but I've heard of it.  I assume it's fully supported by Rockbox?
21.39.09 #       <braewoods> afaik. it's touch based.
21.39.48 #       <speachy> it is, but other than power +volume the rest of the controls are using a (quite crappy) touchpad
21.39.52 Join    bluebrother [0] (~dom@user/bluebrother)
21.40.14 #       <speachy> even the OF was only borderline usable.
21.40.48 #       <speachy> it also didn't have a proper line out, unlike the older fuzes
21.40.48 #       <braewoods> most of the iriver ports are ok but coldfire is so slow
21.41.10 #       <Kemper> My daily driver for the last few years has been a Sansa Clip (maybe a plus?).  I've recently busted some switches off of it and fell back to an older Sansa.  I forget the model number at the moment.
21.41.24 #       <speachy> Kemper: you can buy pre-modded ipods that have varying sizes of SD card storage in 'em.
21.41.33 #       <speachy> Kemper: IIRC if it has the sd card, it's the clip+
21.42.20 #       <braewoods> speachy: i'm tempted to say we might have to shed some ports that have become totally unavailable
21.42.37 #       <speachy> if the maintaience cost becomes a problem, then sure
21.42.52 #       <braewoods> the packard bell vibe... i've *never* seen it available
21.42.58 #       <speachy> right now though.. it's mostly just the overhead of generating the extra builds.
21.43.20 #       <Kemper> Mine must be the clip+ then.  It has the sd card.  So are most of my dead ones
21.44.31 #       <speachy> the next most likely to be dropped will be the 2MB RAM targets (IIRC just a handful of _really_ old sansa models)
21.44.58 #       <speachy> (which IIRC also lack external storage so it's doubtful there are many that still work...)
21.45.33 #       <Kemper> By the way here's the webpage I was referring to with the "currently available" models: https://www.rockbox.org/wiki/BuyersGuide
21.46.21 #       <braewoods> outdated
21.46.37 #       <Kemper> Looks dated to me.  No mention of the xduoo, etc.
21.47.16 #       <braewoods> i would suggest the xduoo x3 myself. watch ebay or so.
21.50.01 #       <Kemper> Ok.  Thanks for the help.  Will check out these other models and see if I can find any.  In the meantime I'll have to bust out the soldering iron and reflow some cracked solder joints.  Again, many thanks for everyone who's kept Rockbox going over the years.
21.50.40 #       <braewoods> most xduoo x3s run the 50-100 USD gauntlet
21.50.44 #       <braewoods> when they do show up
21.52.13 Join    rb-bluebot [0] (~rb-bluebo@rockbox/bot/utility)
21.52.21 #       <Kemper> That's about what I saw Sansas going for at one point.  Not a bad price I guess.  Haven't checked lately.
21.52.55 #       <braewoods> the xduoo has 2 sd cards, internal storage is just used to boot.
21.54.15 #       <Kemper> It may be a FAQ but has anyone looked at the Adafruit Feather series of boards (or similar offerings from Sparkfun, etc.) as possible platforms?
21.54.52 #       <speachy> I don't think they've come up before but I suspect they're _far_ too RAM constrained to be viable.
21.55.41 #       <speachy> best options are the S2 with the 8MB of external spi-connected PSRAM
21.55.59 #       <speachy> but the performance of that will be atrocious.
21.56.37 #       <Kemper> I suspected that they might not be powerful enough.  It sure would be good to have some open hardware designs available as options for running Rockbox.
21.57.11 #       <speachy> some are quite underpowered but some should have more than enough raw ooomph for Rockbox
21.58.09 #       <speachy> microcontrollers with enough RAM to be viable are going to cost more than a higher-end SoC with far more resources+ram
21.58.20 #       <braewoods> it almost feels like we'd be better off writing a port to the pinephone and calling it a day.
21.58.34 #       <speachy> there already is one, effectively -- the basic SDL port.
21.59.03 #       <speachy> there's no advantage to doing a native port on that hardware, given its complexity.
22.00.07 #       <speachy> the pine64 folks have proposed an SoC to be the basis for a rockbox player but it still only has 1MB RAM.
22.00.15 #       <braewoods> would be funny if there was some esoteric tiny x86 system we could launch RB as the single application in X or so
22.02.00 #       <speachy> best bang-for-the-buck would be a custom hat for a RPi Zero, combining good audio, an appropraite display & button matrix, and a battery/charging controller.
22.02.06 #       <speachy> and a 3d printed case
22.03.08 #       <Kemper> Man. that would be great.  
22.03.20 #       <speachy> the RPi Zero can run circles around everything we have (except the x1000, maybe) and has what, 4-8x the RAM to boot.
22.03.21 #       <braewoods> probably bulky though
22.03.24 #       <speachy> yep.
22.03.43 #       <speachy> custom case tooling is the real cost for producing a player.
22.04.09 #       <Kemper> I'd be able to live with bulky for a while
22.04.24 #       <braewoods> it would be perfect for a stationary boombox or something lol
22.05.02 #       <speachy> it could easily be done in somehing that's roughtly the size of the original ipods.
22.05.29 #       <speachy> (I mean the based-on-rpi thing)
22.05.41 #       <braewoods> we might have to use a touchscreen
22.05.51 #       <speachy> but it would still probably end up costing more than just picking up a pre-modded ipod6g.  :)
22.05.54 #       <braewoods> just because of how common they've become and for cost reasons
22.06.09 #       <speachy> the thing is, if we have to use a touch screen, we might as well not bother.
22.06.25 #       <speachy> there are plenty of touchscreen-only players out there.
22.07.31 #       <speachy> what makes rockbox truly unique is its accessibility.
22.07.43 #       <Kemper> I prefer tactile switches and voice prompts to touch screens for eyes-off operation.
22.07.56 #       <speachy> (in practical terms: usable without looking at what you're doing)
22.08.16 #       <Kemper> Exactly
22.10.11 #       <speachy> if we're going to build our own device, what we need to aim at are audiobook readers for visually impaired users.
22.11.12 #       <speachy> (we're 95% of the way there already; the main thing we lack are support for the rich metadata for that market.  think stuff like voiced chapter lists, integrated navigation, etc)
22.12.53 #       <speachy> (And I'm personally all about completely undermining highly proprietary markets)
22.13.22 #       <Kemper> Amen
22.15.40 #       <speachy> and it so happens that what makes rockbox great for visually impaired folks also greatly benefits those of us that can see.
22.16.12 #       <speachy> Being able to control my player without taking my eyes off the road is a win for everyone.
22.17.31 ***     Saving seen data "./dancer.seen"
22.18.38 #       <Kemper> That's one of my favorite things about Rockbox.  I always load the talk files every time a put a new batch of podcasts or music on my device.
22.23.39 #       <Kemper> Another feature I really like is the scrobbler function.  I basically use it for my personal information rather than for upload to one of the music services.  I'm probably the only user who's using it that way though.
22.24.21 #       <Kemper> Once again, thanks for all you folks are doing and I'm looking forward to using Rockbox well into the future despite my current hardware situation.  Thanks also for the leads on possible alternate hardware too.  Will check in from time to time and see what's happening.
22.53.49 Quit    Kemper (Ping timeout: 265 seconds)
23.01.29 Quit    dconrad ()
23.44.32 #       <Syco54645_> _bilgus: fine by me. so long as i can update rockbox manually i dont mind. thanks again for fixing that