--- Log for 20.09.120  Server: card.freenode.net  Channel: #rockbox
--- Nick: logbot_  Version: Dancer V4.16  Started: 22 days and 9 hours ago

00.09.23 Quit    JanC (Remote host closed the connection)
00.09.45 Join    JanC [0] (~janc@lugwv/member/JanC)
00.16.29 Quit    massiveH (Quit: Leaving)
00.22.55 #       <braewoods> _bilgus_: memory exhaustion?
00.23.06 #       <braewoods> then again i don't know the rockbox allocation model
00.24.54 #       <braewoods> i assume though it has the 3 basic allocation methods
00.25.07 #       <braewoods> static fixed size ones
00.25.14 #       <braewoods> the stack
00.25.16 #       <braewoods> the heap
00.43.24 #       <_bilgus_> no it handled 64 k alloc fine mine is like 3k
00.43.49 #       <_bilgus_> I figured alignment but no dice
00.47.12 #       <_bilgus_> duh buflib requires a buffer to handle
00.48.05 #       <_bilgus_> core is already init'd so you need to create a core alloc a little bigger than the buf you require
00.48.59 ***     Saving seen data "./dancer.seen"
01.02.43 #       <_bilgus_> its alive, about damn time
02.45.50 Join    johnb5 [0] (~johnb2@p5b3afa63.dip0.t-ipconnect.de)
02.49.03 ***     No seen item changed, no save performed.
02.59.18 Quit    johnb5 (Ping timeout: 256 seconds)
04.01.47 Join    ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de)
04.09.39 Join    johnb5 [0] (~johnb2@p5b3afa63.dip0.t-ipconnect.de)
04.10.08 Join    lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr)
04.25.23 Quit    prof_wolfff_ (Ping timeout: 260 seconds)
04.30.06 Join    petur [0] (~petur@rockbox/developer/petur)
04.48.27 Join    pamaury [0] (~pamaury@rockbox/developer/pamaury)
04.49.05 ***     Saving seen data "./dancer.seen"
04.56.18 Quit    johnb5 (Ping timeout: 260 seconds)
06.13.46 #       <braewoods> _bilgus_: how hard is it to develop for rockbox if you've never done embedded work before? (since rockbox is an embedded thing for most of its ports)
06.14.23 Quit    St3ak (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net)
06.14.32 #       <braewoods> I'm used to writing code for targets that use ASLR or otherwise use system assigned memory locations...
06.14.48 #       <braewoods> i've never had to use hard-coded pointer addresses
06.14.48 Join    St3ak [0] (~st3ak@st3ak3000.powered.by.lunarbnc.net)
06.15.00 #       <braewoods> i know it's a thing but i never needed to
06.15.34 #       <braewoods> i guess virtual memory is what i'm used to working with and i'm assuming rockbox uses physical addresses
06.16.04 #       <braewoods> but i would be surprised if rockbox doesn't have some kind of libc to ease integration of third party libraries
06.16.24 Join    ac_laptop [0] (~ac_laptop@186.2.247.129)
06.17.11 #       <braewoods> oh, i take that back. i have used NULL which is technically a hard-coded pointer address.
06.17.18 #       <braewoods> but for everything else, not at all.
06.49.07 ***     Saving seen data "./dancer.seen"
07.49.47 Join    prof_wolfff [0] (~prof_wolf@26.red-83-54-195.dynamicip.rima-tde.net)
08.44.04 #       <speachy> braewoods: it's like bowling without gutter rails.
08.49.11 ***     No seen item changed, no save performed.
09.22.32 #       <speachy> Hmm.  I think we should pull pcm_play_data() from the plugin API, and make everything go through the mixer.
09.43.07 Join    johnb2 [0] (~johnb2@p5b3afa63.dip0.t-ipconnect.de)
09.44.13 #       <johnb2> speachy : I also did the screen replacement.
09.44.24 #       <speachy> johnb2: night and day, eh?
09.45.22 #       <johnb2> Yers. I opened the back. For re-assembly I used adhesive tape to keep volume and lock keys in place, then it was easy.
09.46.31 #       <johnb2> I did two stupid things though: 1. using glue below the screen looks ugly and I caused a glue stain on the outside of the screen. too.
09.48.47 #       <johnb2> 2. I used some black cloth to create a "mask"for the screen. That doesn't look too bad, but the hole is not wide enough (misses a few pixels to the left and right). I had never turned on the screen, before I assembled everything. Stupid me :-(
09.49.22 #       <johnb2> Right now I am not inclined to rip the screen off again...
09.50.02 #       <johnb2> Shall I add a few notes on the screen exchange to the wiki?
09.50.18 #       <johnb2> like the caveat for the buttons.
09.51.43 #       <_bilgus_> speachy I like removing the pcm_play
09.51.46 #       <speachy> sure
09.52.15 #       <speachy> do you ahve access to calipers to measure the exact dimensions of the old screen?
09.53.50 #       <johnb2> not right now, would need to find somebody to borrow me one.
09.55.16 #       <_bilgus_> braewoods I actually much prefer working on this side but embedded typically doesn't use bloated libraries so you get a bit more intimate with your hardware and implementations than you like at times
09.55.17 #       <speachy> doom, metronome, pacbox, pdbox, rockboy, sdk, test_sampr, xworld, and zxbox
09.55.18 #       <johnb2> Do you still have the old screen? Mine is intact.
09.55.42 #       <johnb2> Was useful for  cutting the replacement.
09.55.53 #       <speachy> yeah, I have mine, and calipers.  I'll measure it and put it on the wiki
09.56.08 #       <speachy> the thickness is probably the most important dimension to record
09.56.26 #       <speachy> DS screen replacements are a bit too thin
09.57.24 #       <_bilgus_> but really rather than asking for subjective opinions start messing with some code find a place jump in, start on plugins if you like they are slightly more 'managed' as far as the programming goes
09.57.40 #       <johnb2> If you put cloth underneath it's not that bad. Actually, my sceen is slightly bulging out, as the fit is very tight.
09.57.52 #       <_bilgus_> plus it'll get you familar with whats already in the core
09.58.50 #       <speachy> braewoods: if you want a nice self-contained task to get your feet wet, how about converting the plugins that use the direct pcm api to using the mixer instead?
10.00.56 #       <_bilgus_> oh and I used to search for stuff using github but beware it is a flaky regexless terrible interface much better to search locally then use github to see the history etc.
10.01.16 #       <speachy> git grep is awesome.  :)
10.06.31 Quit    rogeliodh (Quit: The Lounge - https://thelounge.chat)
10.06.41 #       <_bilgus_>     bool (*pcm_is_playing)(void); bool (*pcm_is_paused)(void); will probably need to be implemented as a mixer function I don't see the corresponding func and it might touch some lua stuff too bet I can help you there its my baby atm
10.07.00 #       <_bilgus_> s/bet/but*
10.07.22 Join    rogeliodh [0] (~rogeliodh@rogeliodh.dev)
10.07.33 #       <speachy> I don't see a reason to remove the entire  public pcm_* api, just pcm_play()
10.08.27 #       <speachy> so there's only one API for audio playback
10.09.46 Quit    johnb2 (Quit: Nettalk6 - www.ntalk.de)
10.12.19 #       <_bilgus_> oh I figured we could dump the whole thing they both have a play data function
10.12.50 #       <_bilgus_> you'd have the recording stuff left though
10.17.25 #       <speachy> well, we could rename the other pcm_* stuff to mixer_*
10.17.49 #       <speachy> recording is an entirely separate beast, and more importantly there's only one recording path
10.18.32 #       <speachy> in the core, the only user of pcm_play_data() is the mixer code.  :)
10.18.55 #       <_bilgus_> only play_lock\play_unlock and pcm_is_playing look to be missing a mixer version
10.19.52 #       <speachy> pcm_play_*lock is a lowlevel hw API though
10.20.21 #       <speachy> and almost nothing outside the core uses it.
10.21.32 #       <_bilgus_> so leaves is_playing that probably is littered everywhere
10.27.56 #       <speachy> ...not a lot of users for is_playing.  hmm.  mp3_is_playing vs pcm_is_playing
10.28.56 #       <speachy> used only by imageviewer.  and it should really be called voice_is_playing()
10.30.02 #       <speachy> okay, that user is wrong.
10.44.11 #       <speachy> g#2752
10.49.14 ***     Saving seen data "./dancer.seen"
10.52.42 #       <fs-bluebot_> Build Server message: New build round started. Revision 5d40d97, 280 builds, 7 clients.
11.21.10 #       <fs-bluebot_> Build Server message: Build round completed after 1707 seconds.
11.21.11 #       <fs-bluebot_> Build Server message: Revision 5d40d97 result: 0 errors 9421 warnings
11.21.20 #       <speachy> wtf?
11.22.26 #       <speachy> oh ffs.  what I built wasn't committed.
11.23.38 Quit    ac_laptop (Ping timeout: 260 seconds)
11.24.31 Join    johnb5 [0] (~johnb2@p5b3afa63.dip0.t-ipconnect.de)
11.25.16 #       <fs-bluebot_> Build Server message: New build round started. Revision c528c01, 280 builds, 7 clients.
11.34.28 #       <speachy> core's doing the triplebuf thing properly now.  phew. back to the jz code.
11.40.34 Quit    johnb5 (Ping timeout: 256 seconds)
11.41.13 #       <fs-bluebot_> Build Server message: Build round completed after 956 seconds.
11.41.15 #       <fs-bluebot_> Build Server message: Revision c528c01 result: All green
11.50.00 Join    johnb5 [0] (~johnb2@p5b3afa63.dip0.t-ipconnect.de)
12.49.15 ***     Saving seen data "./dancer.seen"
12.52.48 Join    ac_laptop [0] (~ac_laptop@186.2.247.129)
13.00.21 #       <speachy> $#@%^#@$^  -- the hardware doesn't support sending irqs after each descriptor, just when the complete transfer has occurred
13.01.15 #       <speachy> and for cyclic descriptor chains.. it never "finishes".
13.04.08 #       * __builtin never understood the difference between pcm_ and mixer_
13.05.02 #       <__builtin> I assume that mixer_ uses pcm_ and allows superimposing multiple voices?
13.05.12 #       <speachy> essentially, yes.
13.05.57 #       <speachy> most notably voice and things like fake keyclicks
13.06.07 #       <__builtin> oh, right
13.06.27 #       <__builtin> so using pcm_ prevents those from working
13.06.44 #       <speachy> yeah.  I think it also bypasses the dsp core too
13.08.11 #       <__builtin> the overhead with mixer should be minimal, right?
13.08.24 #       <speachy> when you only have one stream, yeah.
13.08.36 #       <speachy> the core playback stuff all goes throught he mixer
13.08.52 #       <__builtin> something like the sdl plugins will probably never need voice or keyclick
13.08.55 #       <speachy> only a handful of plugins directly hit the pcm_ stuff
13.09.10 #       <__builtin> but if it leads to a cleaner API I'm all for it
13.53.34 Quit    johnb5 (Ping timeout: 260 seconds)
13.55.43 #       <_bilgus_> g#2754
13.56.23 #       <_bilgus_> bluebutt> Add Invalid Voice Announcement to the voice system FS#13216 https://gerrit.rockbox.org/r/#/c/2754/
13.56.24 #       <fs-bluebot_> http://www.rockbox.org/tracker/task/13216 Add a failsafe voice prompt for "voice file failed to load" (feature requests, new)
13.56.36 #       <_bilgus_> #g2754
13.56.43 #       <_bilgus_> huh
13.56.55 #       <_bilgus_> g# 2754
13.57.39 #       <_bilgus_> anyways that took so much long than I expected
13.58.27 #       <_bilgus_> main issue was the fact you need buflib overhead and I just didn't have enough room left for the clip after
13.58.35 #       <_bilgus_> amongst other annoying things
13.59.05 Join    johnb5 [0] (~johnb2@p5b3afa63.dip0.t-ipconnect.de)
13.59.22 #       <_bilgus_> ah crap forgot to add the voice file to the commit
14.17.23 Quit    johnb5 (Ping timeout: 240 seconds)
14.19.14 Quit    pamaury (Ping timeout: 260 seconds)
14.33.41 #       <speachy> _bilgus_: so it looks like my multi-buffer audio fantasies are not to be
14.34.18 #       <_bilgus_> no?
14.34.59 #       <speachy> the jz DMA engine doesn't support interrupt-on-descriptor-complete, just completion of the entire chain.
14.35.10 #       <speachy> which for circular chains, never happens.
14.35.31 #       <speachy> which is just brain-numbingly WTF.
14.39.24 #       <_bilgus_> no i'd say typical AFAICS
14.39.43 Join    pamaury [0] (~pamaury@rockbox/developer/pamaury)
14.40.01 #       <speachy> well, only in the sense that every  dma engine is broken in some way
14.40.34 #       <speachy> there's a per-descriptor INT flag but it only triggers if LINK is 0 when the descriptor is completed.
14.40.52 #       <speachy> they went 95% of the way there
14.41.02 #       <speachy> (LINK is the chain flag)
14.41.19 #       <_bilgus_> no low watermark then?
14.41.39 #       <speachy> nope.
14.42.56 #       <_bilgus_> could you overlap the samples and just swap or does that make it too slow?
14.43.50 #       <speachy> the problem is knowing when we need to do that.  by the time we get the interrupt it might already be too late.
14.45.02 #       <speachy> now we could play games with a HW timer triggering an interrupt instead but the bookkeeping for that would get... interesting.
14.45.43 #       <_bilgus_> it might be worth doing that like a multimedia timer
14.48.33 #       <speachy> I think bang-for-the-buck we're better off rewriting the irq servicing stuff to reduce its latency.
14.48.54 #       <speachy> and/or some sort of preemption.
14.49.12 #       <_bilgus_> eh I was thinking the same but I wasn't sure where you were on that
14.49.19 ***     Saving seen data "./dancer.seen"
14.52.51 #       <speachy> a few false starts.  HAsn't been easy to find out what's actually needed.  There aren't too many folks well-versed in MIPS32r1
14.54.08 #       <speachy> the way Linux does it is to push most of the ISRs into their own thread(s) and just schedule them as part of the regular OS stuff.
14.54.45 #       <speachy> I don't think our scheduler lets us trigger a task switch coming out of an interrupt.
14.58.26 #       <_bilgus_> JhMikeS would probably be the most up to date on that but I haven't seen him in at least a year
15.05.25 #       <speachy> if I can force a task change in the interrupt handler then that approach should work.
15.12.13 Join    advcomp2019 [0] (~advcomp20@65-131-146-105.sxct.qwest.net)
15.12.13 Quit    advcomp2019 (Changing host)
15.12.13 Join    advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019)
15.15.14 Quit    advcomp2019_ (Ping timeout: 260 seconds)
15.21.51 Join    jerwin [0] (~flippy-fl@unaffiliated/flippy)
15.21.59 #       <jerwin> i have finally rejoined the rockbox club
15.22.06 #       <jerwin> bought an ipod classic 6g
15.22.07 #       <jerwin> this is great
15.24.10 #       <Lonoxmont> i like it on my 5.5g video
15.32.30 #       <jerwin> yeah, it's much better than the sansa players i used to use
16.00.03 Join    johnb5 [0] (~johnb2@p5b3afa63.dip0.t-ipconnect.de)
16.12.34 Quit    johnb5 (Quit: Nettalk6 - www.ntalk.de)
16.13.06 #       <fs-bluebot_> Build Server message: New build round started. Revision 2ffe879, 280 builds, 7 clients.
16.42.14 #       <fs-bluebot_> Build Server message: Build round completed after 1748 seconds.
16.42.15 #       <fs-bluebot_> Build Server message: Revision 2ffe879 result: 135 errors 27 warnings
16.42.51 #       <_bilgus_> hold_button i bet
16.42.54 #       <speachy> yeah
16.43.40 #       <_bilgus_> I realized it when I stareted wondering what was taking so long
16.46.28 #       <fs-bluebot_> Build Server message: New build round started. Revision 1f9e16e, 280 builds, 7 clients.
16.49.23 ***     Saving seen data "./dancer.seen"
16.55.35 #       <_bilgus_> as for that 1.2 k mips stack I almost want to make it dynamic
16.58.36 #       <speachy> the irq stack you mean?  We can shrink it down to maybe 0.75K now
16.59.11 #       <speachy> the highest high watermark I've seen is about half that.
17.00.37 #       <_bilgus_> in talk.c the thread has 0x500 added
17.00.50 #       <_bilgus_> for 'stack hungry mips'
17.00.52 #       <speachy> oh that, yeah
17.01.12 #       <_bilgus_> since its static non voice users pay for that
17.01.45 #       <speachy> trade the code complexity to save 1K on targets taht have at least 32K?
17.01.55 #       <speachy> ..32M?
17.02.03 #       <_bilgus_> but meh probably plenty of ram on here so why bother
17.02.12 #       <_bilgus_> lol
17.02.24 #       <_bilgus_> thats why I said almost lol
17.02.44 #       <jerwin> do you guys know if they discontinued the agptek rocker? can't find them anywhere now
17.02.48 #       <speachy> I'm definitely in favor of simpler (and possibly more RAM-hungry) code.
17.03.22 #       <_bilgus_> jerwin no clue but I imagine supply line disruptions have a hand
17.03.31 #       <jerwin> ah, forgot we have a pandemic
17.03.40 #       <speachy> $74 on ebay.
17.04.00 #       <_bilgus_> thats not even eye wateringly price gougy yet
17.04.17 #       <speachy> but the stocks are definitely depleted
17.04.46 #       <_bilgus_> speachy did you take that clipzip out of the package yet?
17.04.53 #       <speachy> $54 on amazon prime
17.04.54 #       <fs-bluebot_> Build Server message: Build round completed after 1105 seconds.
17.04.55 #       <fs-bluebot_> Build Server message: Revision 1f9e16e result: All green
17.05.18 Quit    lebellium (Quit: Leaving)
17.05.19 #       <speachy> _bilgus_: nope
17.05.28 #       <_bilgus_> bound to raise the prices if you can't get new ones
17.06.20 #       <_bilgus_> well new other ones I should say
17.06.22 #       <jerwin> oh, i didn't see that 74 dollar listing. a week or two ago there were no listings for it at all on ebay
17.06.54 #       <speachy> can still get X3s on ebay for $81.  (3 left)
17.07.11 #       <_bilgus_> you might try FB marketplace I saw a bunch on there
17.07.22 #       <jerwin> i'm not looking for one right now, i was just curious
17.07.26 #       <_bilgus_> ie. rockboxable targets
17.07.47 #       <jerwin> the best value rockbox player i've found is the ipod classic 5th gen which goes for like $50 on ebay
17.07.56 #       <jerwin> since the rocker is getting harder to find
17.08.19 #       <_bilgus_> well with speachys awesome work on the iflash issues yes
17.08.20 #       <speachy> 50, and budget for an iflash adapter, sd card, and a new battery   :)
17.08.47 #       <jerwin> o
17.08.48 #       <speachy> speaking of iflash issues I have a bunch of dumps to look at
17.09.36 #       <_bilgus_> oh is it ongoing I thought it was 100% damn we need two speachys and a pamaury here
17.10.38 #       <speachy> I suspect the more recent dumps I have are due to partition wonkiness
17.11.18 #       <_bilgus_> That would not surprise me TBH there is a funky program out there on linux
17.11.35 #       <_bilgus_> at least thats what I surmise
17.12.01 #       <speachy> all of the wonkiness that I've seen are from windows users
17.12.27 #       <_bilgus_> they can't do it natively can they?
17.12.48 #       <_bilgus_> I guess once its inserted into the device they could
17.14.06 #       <_bilgus_> I think for windows I told them to use 3rd party LOWLEVELFORMAT i'll have to look in the forums
17.16.26 #       <speachy> oh, that's lovely.
17.16.48 #       <speachy> 2K sectors on the problematic one.
17.17.36 #       <_bilgus_> https://forums.rockbox.org/index.php/topic,51941.msg240386.html#msg240386
17.18.40 #       <speachy> 2K sectors and 16K clusters
17.19.12 #       <_bilgus_> huh maybe dos commands gone awry
17.20.59 #       <speachy> IIRC one model of ipods used 2K sectors (80GB 5.5?).  Caused a lot of interop issues
17.23.27 #       <speachy> ok, I think this is why; the partition type reported is '0' for the firmware and data partitions.
17.24.47 #       <speachy> 500GB data partition
17.25.06 #       <speachy> which we skip because we skip type 1.
17.28.24 #       <speachy> partition is set up for 512 byte sectors, but the partition itself uses 2K sectors.
17.34.17 #       <speachy> nope.
17.34.21 #       <speachy> sigh.
17.35.37 #       <speachy> partition table is 2K sectors, FAT is 2K sectors.
17.45.45 Join    cockroach [0] (~blattodea@pdpc/supporter/active/cockroach)
17.55.53 #       <braewoods> speachy: weird. i thought only optical discs used 2k sectors
17.56.18 #       <braewoods> i tend to see 4k more often userd
17.56.23 #       <braewoods> e.g., page size
17.57.04 #       <speachy> they did that because of the 5.5th gen's large disk sizes
17.57.26 #       <speachy> basically did it to save RAM on their bursting-at-the-seams PP platform..
17.57.54 #       <braewoods> how does larger sectors reduce RAM usage?
17.58.18 #       <braewoods> i guess it means potentially smaller tables to index
17.58.39 #       <braewoods> but not everything is cached to RAM
17.59.09 #       <speachy> probably had some fixed buffer space allocated for FS metadata.
17.59.40 #       <speachy> their disk mode firmware faked out 2K sectors
17.59.51 #       <speachy> to the host OS
18.00.04 #       <Lonoxmont> yeah my 5.5 80gb has the funky sectors too
18.00.42 #       <speachy> you're still on the original spinning rust?
18.01.12 #       * braewoods spins the rusty cylinder.
18.01.15 #       <speachy> can you dump the partition table and first two sectors of the data partition for me so I can try and see if anything obvious is amiss?
18.01.19 #       <Lonoxmont> no, i have iflash quad adapter
18.01.37 #       <Lonoxmont> still have the original drive somewhere
18.01.55 #       <speachy> nah, doesn't matter what the drive is, as long as rockbox is happy to boot up with it
18.02.24 #       <Lonoxmont> rockbox boots fine, the problem i was having was files getting corrupted when transferred under rockbox in usb mode
18.02.42 #       <Lonoxmont> worked aorund by booting to native firmware disk mode to do file transfers
18.02.48 #       <speachy> I'm trying to figure out this issue:  https://forums.rockbox.org/index.php/topic,53533.15.html
18.05.03 #       <speachy> has an iflash sata adapter.  lord only knows what's going on under the hood; that one's presumably using different guts from the SD adapters.
18.06.45 #       <Lonoxmont> yeah i can get you the dumps from mine, though since tis the sd adapter idk how useful it will be
18.06.48 #       <Lonoxmont> lemme look for my cable
18.07.08 #       <speachy> I can at least compare the partitioning to see if it's done the same way
18.08.35 #       <speachy> I don't know if it's a bug relating to 2K sectors, some ATA feature [not] being twiddled, or maybe even a combination of the two.
18.09.00 #       <speachy> heh, debugging this proprerly might require a this adapter, the SSD, and a IDE->ZIF cable.  :)
18.11.19 #       <Lonoxmont> how do you want the ipod booted, disk mode? rockbox? original firmware?
18.24.56 #       <speachy> disk mode I guess
18.30.40 Quit    ZincAlloy (Quit: Leaving.)
18.49.27 ***     Saving seen data "./dancer.seen"
19.03.13 Quit    pamaury (Ping timeout: 246 seconds)
19.31.38 Quit    petur (Quit: Leaving)
19.53.41 Join    bluebrother [0] (~dom@rockbox/developer/bluebrother)
19.55.15 Join    fs-bluebot [0] (~fs-bluebo@55d47a17.access.ecotel.net)
19.57.06 Quit    bluebrother^ (Ping timeout: 272 seconds)
19.57.23 Quit    fs-bluebot_ (Ping timeout: 240 seconds)
20.06.35 Quit    Moarc (Read error: Connection reset by peer)
20.06.59 Join    Moarc [0] (~chujko@a105.net128.okay.pl)
20.31.03 Join    josh24cor [0] (8ea27b49@142.162.123.73)
20.31.35 #       <josh24cor> hey guys i need some help bringing a file from my windows 10 computer over to my ubuntu so i can mess with it
20.31.56 #       <josh24cor> last command i had was to take my compiled zip and transfer it to my desktop using
20.32.03 #       <josh24cor> cp rockbox-full.zip /mnt/c/Documents\ and\ Settings/JoshuaDesktop
20.32.30 #       <josh24cor> but now i wanna take C:\Users\JoshuaDesktop\Desktop\rockbox-master to my ~ directory in ubuntu
20.32.44 #       <josh24cor> rockbox-master folder that is
20.37.35 #       <Strife89> Are these separate machines?
20.39.42 #       <josh24cor> yes but nevermind i think il just download the official build and mod it that way, all good!
20.44.08 Quit    josh24cor (Remote host closed the connection)
20.49.30 ***     Saving seen data "./dancer.seen"
21.15.46 #       <speachy> ouch; iflash's (4-yr-old) benchmarks show the mSata being worse for battery life than the original hard drive
21.33.38 #       <_bilgus_> just picked up a fuzev2 on fb marketplace $40
21.39.44 #       <jerwin> nice
21.44.10 Quit    cockroach (Quit: leaving)
22.22.21 Quit    beencubed (Quit: Leaving)
22.40.38 Join    captainkewl [0] (60ffd643@pool-96-255-214-67.washdc.fios.verizon.net)
22.49.33 ***     Saving seen data "./dancer.seen"
22.57.11 Part    captainkewl
23.02.11 #       <_bilgus_> this thing is nice few scratches on the back front is like new
23.46.22 Quit    ac_laptop (Ping timeout: 272 seconds)
23.52.02 Quit    TheSeven (Ping timeout: 260 seconds)
23.52.34 Join    TheSeven [0] (~quassel@rockbox/developer/TheSeven)