--- Log for 23.10.120 Server: wilhelm.freenode.net Channel: #rockbox --- Nick: logbot_ Version: Dancer V4.16 Started: 25 days and 19 hours ago 00.00.26 # <_bilgus__> hey look I have an abandoned patch from last time 00.08.58 # <_bilgus__> wow that was 500 bytes 00.09.12 # <_bilgus__> wonder if I can squeeze it a bit further 00.14.53 # <_bilgus__> speach no boot loaders use %z or %p think they are important enough to leave? 00.15.49 # <_bilgus__> I feel like size_t can be cast to lomg and %p can be worked around with %x 00.15.55 # <_bilgus__> oops speachy 00.26.07 Quit pixelma (Quit: .) 00.26.07 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 00.28.42 Join amiconn [0] (jens@rockbox/developer/amiconn) 00.28.43 Join pixelma [0] (marianne@rockbox/staff/pixelma) 00.38.17 # 20:12:45, 72765, 000%, 00:-1, 3411 00.38.30 # oh wow this thing really did manage 20hrs 00.42.23 *** Saving seen data "./dancer.seen" 00.44.43 # <_bilgus__> g#2884 00.44.45 # Gerrit review #2884 at http://gerrit.rockbox.org/r/2884 : ClipPlus BOOTLOADER DONT FIT! by William Wilgus 01.28.24 Quit Oksana (Ping timeout: 272 seconds) 01.42.28 Join Oksana [0] (~Wikiwide@Maemo/community/ex-council/Wikiwide) 02.13.58 # <_bilgus__> Beat it by 400 bytes 02.14.16 # <_bilgus__> assuming removing diacritics don't mess up the bootloaders... 02.42.24 *** Saving seen data "./dancer.seen" 02.46.12 Join Stanley00 [0] (~Stanley00@unaffiliated/stanley00) 02.50.12 # efqw: hmm, isn't 3.4V consider dangerous for lipo battery? 02.53.18 Quit toruvinn (Ping timeout: 260 seconds) 02.54.21 Quit Stanley00 () 02.54.42 Join Stanley00 [0] (~Stanley00@unaffiliated/stanley00) 02.57.32 # That's why last time I stop the benchmark when my m5 report at 5% and voltage goes slightly below 3.5V 03.01.44 # I think 3v4 is fine. 03.05.35 # People run batteries to 3v0 all the time 03.06.09 # You'll only get cell damage at 2.xV afaik 03.09.30 # 3v4 is actually quite conservative imo and it's a good thing 03.15.39 # I was just paranoid a little, 'cause most digram show a drop down significant when come to below 3.5v 03.15.53 # But yeah, readinh the wiki state it fine though 03.17.15 # these batteries are not linear devices, so you get diminishing returns after you go below 3v5 03.18.32 # but getting lower energy per 0.1v isn't indicative of potential cell damage :P 03.33.32 Quit ender| (Ping timeout: 260 seconds) 03.36.26 Join ender| [0] (~ender1@2a01:260:4094:1:6045:6fff:fedd:cbf3) 03.36.50 Join prof_wolfff [0] (~prof_wolf@26.red-83-54-195.dynamicip.rima-tde.net) 03.37.39 Join toruvinn [0] (~toruvinn@87-205-132-1.adsl.inetia.pl) 03.39.11 Join edhelas [0] (9d94237298@2a01:7c8:aab8:6b9:5054:ff:fec9:fd84) 03.40.25 # hi everyone o/ 03.47.48 # as I know a bit more how to handle C by now I would like to dive back in https://gerrit.rockbox.org/r/#/c/rockbox/+/1009/ 03.59.54 Quit fauweh (Quit: ) 04.00.21 Join fauweh [0] (~root@ithaqua.unzane.com) 04.06.44 Quit prof_wolfff (Ping timeout: 272 seconds) 04.18.29 Join prof_wolfff [0] (~prof_wolf@26.red-83-54-195.dynamicip.rima-tde.net) 04.20.54 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 04.35.39 Part efqw 04.35.41 Join efqw [0] (uid412670@gateway/web/irccloud.com/x-cjmgdgoswnanyjsg) 04.42.26 *** Saving seen data "./dancer.seen" 04.44.12 # speachy: Good news. 1) I figured out why my battery looked like flat dead. Usb cable generated HUGE voltage drop (3.8V at the player end). This was enough to fool player to think it is charging but way too low for charging circuit to operate. 2) bluetoothd dying was probably related to the low battery level. 3) parametrized config in asound.conf is working fine. At least aplay started to understand bluetooth device string 04.47.37 Quit pamaury (Ping timeout: 264 seconds) 04.51.32 # speachy: The bad news is that current version of agptek firmware does not ship libbluetooth shared objects 04.56.47 # oh wow, that's some *horrible* usb cables you've got there 05.00.11 # I have some issues to setup my toolchain, if someone could assist me 05.00.19 # I'm on Debian testing 05.00.27 # $ ./rockboxdev.sh 05.00.27 # ROCKBOXDEV: "makeinfo" is required for this script to work. 05.00.27 # ROCKBOXDEV: "libtool" is required for this script to work. 05.00.27 DBUG Enqueued KICK edhelas 05.00.27 # ROCKBOXDEV: "flex" is required for this script to work. 05.00.27 # ROCKBOXDEV: Please install the missing tools and re-run the script. 05.01.15 # i've installed all the packages listed on that page 05.01.18 # https://www.rockbox.org/wiki/LinuxSimpleGuideToCompiling 05.03.40 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 05.07.48 # (ok my bad, missed a few more packages) 05.29.03 Quit pamaury (Ping timeout: 260 seconds) 05.30.18 Join vmx [0] (~vmx@ip5f5ac60f.dynamic.kabel-deutschland.de) 06.11.16 # got that 06.11.17 # ROCKBOXDEV: applying patch rockbox-multilibs-noexceptions-arm-elf-eabi-gcc-4.9.4.diff 06.11.17 # patching file gcc/config/arm/t-arm-elf 06.11.17 # Hunk #1 succeeded at 64 with fuzz 2 (offset 20 lines). 06.11.17 # Hunk #2 FAILED at 61. 06.11.17 *** Alert Mode level 1 06.11.17 # 1 out of 2 hunks FAILED -- saving rejects to file gcc/config/arm/t-arm-elf.rej 06.11.18 *** Alert Mode level 2 06.11.18 # patching file libgcc/config/arm/t-bpabi 06.11.18 *** Alert Mode level 3 06.11.18 # patching file libgcc/Makefile.in 06.14.47 # speachy it seems that this patch was introduced by you recently ? ^ 06.17.50 Join Rower [0] (~Rower@78-73-72-39-no2340.tbcn.telia.com) 06.21.19 *** Alert Mode OFF 06.24.27 Quit danielp3344 (Quit: killed) 06.24.28 Quit kadoban (Quit: killed) 06.24.44 Quit blbro[m] (Quit: killed) 06.33.06 # speachy: magic sits in bt-connect utility. Running it makes bt audio work 06.33.55 Join blbro[m] [0] (blbrostrat@gateway/shell/matrix.org/x-tpncpihvtlasucfq) 06.42.27 *** Saving seen data "./dancer.seen" 06.45.38 # Ok. Missing link is calling org.bluez.AudioSink.Connect method on connected device. 06.52.02 Join danielp3344 [0] (danielp334@gateway/shell/matrix.org/x-aggpelywdczulgkq) 06.52.03 Join kadoban [0] (kadobanmat@gateway/shell/matrix.org/x-uczqikstpaepzgvu) 07.04.18 Join pamaury [0] (~pamaury@maths.r-prg.net.univ-paris7.fr) 07.04.19 Quit pamaury (Changing host) 07.04.19 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 07.13.35 # edhelas: I'm not sure why that patch failed; quite a few of us have built those toolchains fine with what's committed. 07.13.40 # ok i found the issue, i'll propose a patch soon 07.14.04 # -@@ -56,8 +61,8 @@ 07.14.04 # +@@ -61,8 +61,8 @@ 07.27.17 # wodz: glad the magic pieces are falling into place. do you know if BT audio is fixed @44KHz? 07.30.01 # _bilgus__: IIRC none of the strings in the bootloaders go through the translation layer, and even if they did, there's no way to load non-english languages anyway. 07.32.42 # so yeah, no text scrolling, no non-engrish, and the only text output should be errors anyway. 07.32.56 # granted the "bootloaders" in the hosted ports are fancier 07.45.10 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 07.49.54 # Build Server message: New build round started. Revision 7c06a9e, 293 builds, 9 clients. 08.00.49 # _bilgus__: We should add some sort of mkamsboot/fw patching pass somewhere. 08.01.16 # and if we don't already have some sort of mirror of all (eg) sandisk firmware updates, it's only a matter of time before they're taken offline due to sheer obsolescence. 08.05.09 # Build Server message: Build round completed after 916 seconds. 08.05.14 # Build Server message: Revision 7c06a9e result: All green 08.18.10 # speachy: I don't know. 08.38.21 Quit massiveH (Quit: Leaving) 08.42.28 *** Saving seen data "./dancer.seen" 08.43.00 # wodz: basiclly we'd have to disable or override playback rate selection to match what the BT device can consume 09.27.46 # speachy: arguably also true for iriver H100 and H300 09.28.03 # they're still available from their website, but for how long? 09.28.34 # i'm also looking into ways to update the H10 offline but no luck so far. 09.28.57 # the only way i found involved using their tool that downloads it from the network 09.29.22 # mirroring firmware updaters that can be used offline isn't a bad idea 09.42.20 # Build Server message: New build round started. Revision 186dbb4, 293 builds, 9 clients. 09.47.50 # <_bilgus__> speachy so add the mkamsboot part?, I think its fine to create them but I feel we should send it to devnull 09.48.19 # _bilgus__: yeah, though we need an OF image to go with it? 09.49.01 # <_bilgus__> yep 09.55.17 # Build Server message: Build round completed after 778 seconds. 09.55.19 # Build Server message: Revision 186dbb4 result: All green 09.59.02 # <_bilgus__> wodz wb, I plan to start making the UI side on the rocker sometime this week I'll probably mock it up using lua first 09.59.45 # <_bilgus__> oh yeah I need to see why lua actions don't work on the rocker 10.07.50 # ok, the SDUC adds/extends CMD22 to include the extra 6 bits of addressing, and CMD41 is tweaked to add explicit flags for >2TB reporting. 10.08.53 # so other than teh disklabel/filesystem issues, the changes needed to enable >2TB cards are pretty minor. 10.09.53 # <_bilgus__> are there any yet or just looking forward? 10.11.26 # largest uSDs I'm seeing are 1TB. 10.13.36 # hmm, I wonder what the upper limit of those iFlash duo/quad adapters is? 10.14.27 # <_bilgus__> oh yaeh so thje quad could potentially give you 4TN then nice, but wozer 10.14.34 # <_bilgus__> 4TB* 10.14.50 # can't imagine they can handle SDUC cards, but they could easily export a 4TB drive today, in theory. 10.14.53 # it will also take days to fill it using the USB2.0 10.15.31 # <_bilgus__> at $75-100 a card that'd be an $$$ investment atm 10.16.17 # <_bilgus__> not that I haven't spent several hundred for less :P 10.16.24 # 75-100? cheapest I see is $250 for 1TB. :) 10.17.21 # <_bilgus__> oh I figured they had gone down a tier already $100 next year then :p 10.25.44 Join johnb7 [0] (~johnb2@p5b3afabb.dip0.t-ipconnect.de) 10.32.22 # speachy I got me a used Walker. I turned out it had no usb socket :-( Assuming the back is similar to the F20 that lebellium pointed to, how would you attempt to open the case? Heat the glass and metal frame and then try to pry the glass? 10.34.55 # heat the glass to soften the adhesive, and pull/pry it off, expsing the screws underneat 10.36.06 # yep, that's what I thought I should do 10.36.56 # shouldn't take much heat, and use plastic tools, etc etc.. 10.37.41 # <_bilgus__> re the rocker, lua action failure because it can't get a timer 10.38.16 # <_bilgus__> what got added to the hosted targets that used up the timers? 10.38.40 # nothing that I can recall.. did this ever work? 10.39.55 # <_bilgus__> yes 10.42.26 # <_bilgus__> I upped the priority on it and it still didn't succeed so I'll check taht the MACROS are intact that calculates cycles 10.42.32 *** No seen item changed, no save performed. 10.44.15 # <_bilgus__> HAHA thats it 10.44.19 # last change to the timer code was something you did in 2019. 10.46.10 Quit pamaury (Quit: Konversation terminated!) 10.46.33 # <_bilgus__> TIMER_FREQ macro 10.50.00 # so it gets fixed at 1MHZ on hosted platforms 10.55.45 Quit Moarc (Ping timeout: 240 seconds) 10.57.31 Quit johnb7 (Ping timeout: 265 seconds) 10.59.05 # <_bilgus__> yeah they are intact weird it shows 50000 for period and TIMER FREQ = 100000 10.59.48 # <_bilgus__> yet when its supplied to timer register it fails but if I set it to 10000 it works 11.02.57 Join Moarc [0] (~chujko@a105.net128.okay.pl) 11.11.00 # <_bilgus__> hmm are ints 32 bits on your hosted platforms? 11.11.43 # yep 11.11.57 # standard 32-bit linux 11.12.06 # <_bilgus__> looks like overflow in the cycles calculation 11.12.09 # so int = long = int32_t 11.12.34 # cpufreq is 1GHz 11.12.48 # so it wouldn't take much to overflow 11.13.25 # <_bilgus__> #define cycles_to_microseconds(cycles) \ ((int)((1000000*cycles)/TIMER_FREQ)) 11.15.27 # <_bilgus__> knock off 2 zereos and divide by 100 11.20.58 # <_bilgus__> yay that did it 11.21.16 # <_bilgus__> weird that I just up and stopped maybe clocking changes? 11.26.15 Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be) 11.28.23 Quit jdarnley (Ping timeout: 260 seconds) 11.29.04 # probably something I did 11.33.16 # <_bilgus__> being that we don't check for timers failing much through the code I wonder what else wasn't ticking 11.33.46 # well, this might fix a bunch of issues. 11.33.54 # might do nothing. :D 11.35.12 # Build Server message: New build round started. Revision 3a7a46d, 293 builds, 9 clients. 11.35.22 # <_bilgus__> gonna find out :p 11.36.19 # <_bilgus__> I have to go find a micro usb cable or drive home to get one before I can test the Clip+ bootloader 11.37.27 # <_bilgus__> once I've done that I'll rework the lcd_fb patch to account for the new parent 11.38.00 # <_bilgus__> oh and i'll fix those comments you mentioned thanks btw helps to have someone else look 11.38.37 Quit bzed (Ping timeout: 264 seconds) 11.45.37 # <_bilgus__> mini usb cable* 11.46.35 # was about to say.. :D 11.46.55 # I have an entire assortment of cables permanently hanging off my desk hub 11.49.05 Join bzed [0] (~bzed@shell.bzed.at) 11.50.10 # <_bilgus__> yeah I forgot to grab it the last time when I grabbed the Clip+ 11.50.21 # Build Server message: Build round completed after 909 seconds. 11.50.23 # Build Server message: Revision 3a7a46d result: All green 11.52.05 # <_bilgus__> so I was looking at my pared version of putsofs from the bootloader and I started thinking oh no I wonder if font_lock actually unlocks thje bits of the font for reading so I went and found it in the source 11.52.26 # what triggered this was probably my fixing a bunch of incorrect CPU_FREQ definitions 11.52.27 # <_bilgus__> void font_lock(int font_id, bool lock) 11.52.27 # <_bilgus__> { 11.52.27 # <_bilgus__> (void)font_id; 11.52.27 DBUG Enqueued KICK _bilgus__ 11.52.27 # <_bilgus__> (void)lock; 11.52.27 # <_bilgus__> } 11.52.36 # <_bilgus__> nope no issue there! 11.54.04 # <_bilgus__> speachy no worries there I'm actually surprised it wasn't caught by that lint run you did 11.55.56 # so the math "worked" but the delays were all jacked 11.55.59 # <_bilgus__> the linting -- sounds like a stephen king novel 11.56.26 # "the linting of rockbox place" 11.56.39 # <_bilgus__> I'd read it 11.57.14 # (coming soon to hulu plus) 11.57.29 # (because not even netflix would touch it...) 12.00.59 # <_bilgus__> what were the plugins crashing on hosted? I bet those all have timers :) 12.01.42 # I know a couple of 'em were probably the viewport issues you've been fixing 12.02.59 # <_bilgus__> huh fire doesn't exit on the rocker 12.03.16 # <_bilgus__> was always the case or did I break it? 12.03.22 # might be a display resolution thing 12.03.31 # rocker's only 160x128 IIRC. 12.03.59 # it's there on the eros.. 12.04.04 # <_bilgus__> and oscope segfaults 12.04.22 # it's definitley being built on the rocker btw, I have it in my working tree 12.04.36 # <_bilgus__> oh I should pply 2811 and see if it fixes it 12.04.48 # <_bilgus__> its there I just can't exit it 12.05.03 # <_bilgus__> like the button isn't mapped 12.05.27 # it's a PLA target 12.05.33 # s/target/plugin 12.05.40 # <_bilgus__> could be a yield issue too 12.05.49 # <_bilgus__> I'll check it out tonight 12.05.50 # no, I'm ble to quit fine on the H2 12.06.23 # <_bilgus__> i'll try a dev version from a few days ago 12.06.40 # try vol up 12.07.14 # wtf fire uses PLA_CANCEL but not PLA_EXIT 12.07.48 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 12.07.53 # <_bilgus__> ah so map issue 12.08.03 # more like the plugin is stupid. :D 12.08.15 # <_bilgus__> there are lots of little things like that through the plugins 12.08.41 # <_bilgus__> part of the reason I want to make it more dynamic everyone could share 12.09.12 # <_bilgus__> that and its like the most requested thing changing keymaps.. 12.09.23 # Build Server message: New build round started. Revision 2cf75bf, 293 builds, 9 clients. 12.10.31 # so far my alsa rejiggering is holding up, yay. 12.11.13 # <_bilgus__> so that kind of tickles me a bit that oscope crashes on scroll when I was doing the patch it just kept crashing no matter what I did 12.11.32 # <_bilgus__> that was like a 2 day adventure 12.12.20 Join johnb7 [0] (~johnb2@p5b3afabb.dip0.t-ipconnect.de) 12.12.37 # <_bilgus__> not that knowing that woulkd have helped me then.. 12.22.40 # Build Server message: Build round completed after 796 seconds. 12.22.43 # Build Server message: Revision 2cf75bf result: All green 12.24.02 Quit pamaury (Ping timeout: 265 seconds) 12.42.35 *** Saving seen data "./dancer.seen" 12.45.29 # <_bilgus__> last thought before I go I think I'd like to start making some simple-ish tests as lua scripts to test the underlying target like printf formatting for example :P 12.46.26 # <_bilgus__> I already have the capability to read and write memory addresses from lua its locked down ATM but can be expanded to probe any accessible address 12.48.56 # <_bilgus__> its how I get around having to pull the entirety of rockbox into the lua interpreter, tables of interface info generated at BUILD time 12.50.13 Join SammysHP_ [0] (~SammysHP@faol.sammyshp.de) 12.50.28 Join Tsesarevich_ [0] (Tsesarevic@fluxbuntu/founder/joejaxx) 12.52.58 # ok, the alsa driver's init code has been reworked again, and it now has recording support, in theory. 12.53.02 Quit johnb7 (Ping timeout: 265 seconds) 12.56.02 Join heredoc [0] (heredoc@2a01:7e01::f03c:91ff:fec1:de1d) 12.57.33 Quit kadoban (*.net *.split) 12.57.33 Quit edhelas (*.net *.split) 12.57.33 Quit ender| (*.net *.split) 12.57.33 Quit Stanley00 (*.net *.split) 12.57.33 Quit Tsesarevich (*.net *.split) 12.57.33 Quit heredoc_ (*.net *.split) 12.57.33 Quit SammysHP (*.net *.split) 12.57.34 Quit koniu (*.net *.split) 12.57.45 Nick Tsesarevich_ is now known as Tsesarevich (Tsesarevic@fluxbuntu/founder/joejaxx) 13.03.02 Join MrZeus_ [0] (~MrZeus@185.195.232.139) 13.05.24 Join ender| [0] (~ender1@2a01:260:4094:1:6045:6fff:fedd:cbf3) 13.05.33 Quit fs-bluebot_ (Read error: Connection reset by peer) 13.05.33 Quit bluebrother (Read error: Connection reset by peer) 13.05.58 Join fs-bluebot [0] (~fs-bluebo@55d44bc9.access.ecotel.net) 13.06.03 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 13.07.57 Join kadoban [0] (kadobanmat@gateway/shell/matrix.org/x-ibzwjrmlfzihcpnq) 13.08.44 Quit Rower (Ping timeout: 260 seconds) 13.15.17 Quit vmx (Quit: Leaving) 13.15.26 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) 13.24.33 Join edhelas [0] (9d94237298@149-210-220-39.colo.transip.net) 13.31.53 # sripped out the non-async mode due to the tick-based mode being completely irrecovably broken 13.35.39 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 13.36.23 # the GIT repository is quite slow to answer, it's normal ? 13.55.29 # speachy this fixes the issue for me https://gerrit.rockbox.org/r/#/c/rockbox/+/2891/ :) 14.13.35 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 14.42.39 *** Saving seen data "./dancer.seen" 14.48.19 # I should mirror it 15.11.20 Join johnb7 [0] (~johnb2@p5b3afabb.dip0.t-ipconnect.de) 15.15.02 Join fs-bluebot_ [0] (~fs-bluebo@55d44697.access.ecotel.net) 15.15.07 Quit bluebrother (Disconnected by services) 15.15.12 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 15.16.30 Quit fs-bluebot (Ping timeout: 258 seconds) 15.20.33 Quit johnb7 (Ping timeout: 260 seconds) 16.03.09 Join johnb7 [0] (~johnb2@p5b3afabb.dip0.t-ipconnect.de) 16.05.32 Quit pamaury (Ping timeout: 256 seconds) 16.12.28 Quit johnb7 (Ping timeout: 260 seconds) 16.25.05 Quit SammysHP_ (Quit: *wuff*) 16.26.43 Join SammysHP [0] (~SammysHP@faol.sammyshp.de) 16.28.19 Join johnb7 [0] (~johnb2@p5b3afabb.dip0.t-ipconnect.de) 16.37.34 Quit lebellium (Read error: Connection reset by peer) 16.37.55 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) 16.38.30 Quit johnb7 (Ping timeout: 272 seconds) 16.41.44 # okay, I think the audio garbage on the hosted targets is actually some sort of core bug 16.41.51 # (on track skip) 16.41.59 Join kugel_ [0] (~kugel@rockbox/developer/kugel) 16.42.08 # edhelas: I'll have a look at it later tonight or this weekend 16.42.43 *** Saving seen data "./dancer.seen" 16.44.12 Join pookie [0] (~pookie@snf-137798.vm.okeanos.grnet.gr) 16.45.41 # _bilgus__: I'm able to recreate that oddidty on the X3 nearly at will now. skip to a new track, display updates, but nothing seems to happen until another key is pressed. any key. 16.46.03 # (I mean, no audio playback starts) 16.47.32 # I wonder if it's an interrupt delivery thing. 16.48.57 # and that audio garbage thing sounds like it's basically due to the pcm playback buffer not getting cleared/filled properly before it's being handed over. 16.50.04 Quit Acou_Bass (*.net *.split) 16.50.04 Quit _3dsv (*.net *.split) 16.50.04 Quit ps-auxw (*.net *.split) 16.50.04 Quit rogeliodh (*.net *.split) 16.50.04 Quit beencubed (*.net *.split) 16.50.04 Quit kugel (*.net *.split) 16.50.04 Quit mixfix41 (*.net *.split) 16.50.04 Quit Slasherii (*.net *.split) 16.50.04 Quit galaxy_knuckles (*.net *.split) 16.50.04 Quit olspookishmagus (*.net *.split) 16.50.10 Join Acou_Bass [0] (~eddie@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) 16.50.10 Join _3dsv [0] (~3dsv@068-184-255-059.res.spectrum.com) 16.50.10 Join ps-auxw [0] (~arneb@p548c6f52.dip0.t-ipconnect.de) 16.50.10 Join rogeliodh [0] (~rogeliodh@rogeliodh.dev) 16.50.10 Join beencubed [0] (~beencubed@209.131.238.248) 16.50.10 Join mixfix41 [0] (~popebook2@unaffiliated/mixfix41) 16.50.10 Join galaxy_knuckles [0] (~gknux@unaffiliated/galaxy-knuckles/x-1756549) 16.56.52 Join Slasherii [0] (~miipekk@itu.ihme.org) 17.50.14 # Build Server message: New build round started. Revision 46e357f, 293 builds, 9 clients. 17.51.29 # speachy: g#2892 is more or less the same as g#634, isn't it? 17.51.33 # Gerrit review #2892 at http://gerrit.rockbox.org/r/2892 : samsungyp: Enable recording feature. No idea if it works. :D by Solomon Peachy 17.51.33 # Gerrit review #634 at http://gerrit.rockbox.org/r/634 : Samsung YP-R0: record FM radio by Lorenzo Miori 17.51.42 # I talked to Lorenzo tonight 17.51.53 # no, it's a rewrite of 634 plus a lot more 17.52.01 # he told me 17.52.03 # "yeah, my work on R0 was a brief attempt to mock around with recording but I see we are limited to 8khz or 22khz (don't even remember right now) -> quality sucks -> not worth the time investment to close the feature" 17.52.36 # or rather, 2891 was the rewrite, and 2892 just enables recording on the R0/R1. 17.55.11 # you mean g#2888? 17.55.13 # Gerrit review #2888 at http://gerrit.rockbox.org/r/2888 : ALSA: Further rework: by Solomon Peachy 17.55.22 # yeah, that. :D 17.56.18 # I marked 633 as abandoned (as it's completely obsoleted by 2888) but 634 may be worth incorporating. 17.57.05 # if nothing else, 2892 will be the only user of the pcm recording code, so we can at least know if something causes it to stop compiling. 17.58.12 # lebellium: since you have a YP-R0, if you'd care to try out the build that's going to spit out in a few and tell me if audio playback still works.. 17.58.42 # shouldn't we test that before commiting a patch? :D 17.58.46 # it's definitely improved on the hiby-based targets 17.59.37 # I don't pretend being able to tell if it sounds better or not but at least I can tell if playback still works indeed 17.59.49 # that's all I can ask 18.01.20 # regarding recording, without proper keymaps I assume I won't be able to test 18.01.20 # slowly undoing more layered hacks, basically 18.01.34 # I'd be surprised if recording worked, honestly 18.03.04 # Build Server message: Build round completed after 770 seconds. 18.03.08 # Build Server message: Revision 46e357f result: All green 18.03.09 # Build Server message: New build round started. Revision a8aa840, 293 builds, 8 clients. 18.16.35 Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156) 18.17.23 # Build Server message: Build round completed after 854 seconds. 18.17.24 # Build Server message: Revision a8aa840 result: All green 18.27.12 # speachy: playback still working on YP-R0 18.29.28 # starting FM recording: crash 18.30.50 # in the recording settings I see only "44.1kHz" frequency while lorenzo meant in the patch that only 8 and 16kHz are supported 18.30.59 # this could explain the crash 18.33.04 # there is no microphone so I'm not sure what the main "recording" menu is supposed to do. 18.33.24 # Does "#define HAVE_RECORDING" automatically add both voice recording and FM recording ? 18.34.25 # or maybe line in. But there is no line in either 18.42.46 *** Saving seen data "./dancer.seen" 18.48.02 Quit S|h|a|w|n (Read error: Connection reset by peer) 18.50.07 Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156) 19.06.27 Quit lebellium (Quit: Leaving) 19.10.35 # well, it's clearly something that needs further work. 19.11.14 # there are REC_CAPS that let one select the source, but obviously the code has to be there on the target-specific code to do the actual switching 19.14.50 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 19.15.05 Join fs-bluebot [0] (~fs-bluebo@55d446af.access.ecotel.net) 19.17.24 Quit fs-bluebot_ (Ping timeout: 260 seconds) 19.18.02 Quit bluebrother^ (Ping timeout: 256 seconds) 19.23.40 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach) 19.31.06 # <_bilgus__> well the sansa clip+ bootloader works but only displays the first letter of each word lol 19.31.26 # lovely, commit 2e708c48c5 is what's leading to that hang. (where I pusuedo-dynamically adjust the mixbuf size based on teh active samplerate) 19.43.26 Quit cockroach (Ping timeout: 272 seconds) 19.47.17 # <_bilgus__> speachy can you fill me in on the issue at hand here? was it the one you posited might be the button code? 19.48.22 # it's not the button code, but something wonky in the mixer. one of the callbacks is failing and explcitly telling the DMA to stop without any sort of real error recovery 19.57.02 # <_bilgus__> Clip+ ok so at least its not my printf code failing its the putsxofy function 19.58.53 # <_bilgus__> hmm it doesn't appear that the rb logo displays unless the device actually boots I should remove the logo from the boot loader 20.01.17 # <_bilgus__> meh save that for next time 20.16.25 Quit MrZeus_ (Ping timeout: 264 seconds) 20.19.08 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach) 20.35.38 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 20.39.54 # <_bilgus__> ok bootloader is good 20.40.46 # Build Server message: New build round started. Revision d78a376, 293 builds, 9 clients. 20.42.50 *** Saving seen data "./dancer.seen" 20.54.58 # Build Server message: Build round completed after 853 seconds. 20.55.00 # Build Server message: Revision d78a376 result: All green 20.58.44 # <_bilgus__> I think maybe a vector based graphic might work better for our logo 21.19.14 # <_bilgus__> the thought just occurred to me for the framebuffer and viewports: I store elems with the intention of using the calculated FB address % elems but I disabled that since I figured it was clipped by LCD_W/H 21.20.21 # <_bilgus__> It will protect the buffer along with an ABS fn so that gets rid of all those ifs 21.20.50 # <_bilgus__> then clipping can be a pointer to a default vp xy wh clip function or NULL and only one check gets made 21.35.02 Quit massiveH (Read error: Connection reset by peer) 21.36.53 # <_bilgus__> and shot down already all those plugins could wreak havoc on core if I do that 21.37.01 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 21.57.42 # GAH! found it. 21.59.35 # g#2983 21.59.52 # or rather, g#2893 21.59.53 # Gerrit review #2893 at http://gerrit.rockbox.org/r/2893 : pcm_mixer: Fix an idle frame calculation bug introduced in 2e708c48c5 by Solomon Peachy 22.00.50 # Build Server message: New build round started. Revision ec2a34b, 293 builds, 9 clients. 22.01.07 # this is one of those bugs that make me wonder how things actually mostly worked 22.03.00 # _bilgus__: heh, I kinda wish you'd updated the commit message for your bootloader hacking to mention that you did indeed confirm it worked. 22.04.09 Quit cockroach (Quit: leaving) 22.12.14 # <_bilgus__> for the record? 22.14.27 # Build Server message: Build round completed after 816 seconds. 22.14.29 # Build Server message: Revision ec2a34b result: All green 22.22.08 # <_bilgus__> speachy that bug is subtle AF too 22.22.40 # <_bilgus__> its why people over paren. 22.26.48 # yeah. Blame it on a brain fart thinking it was equivalent. 22.28.18 # edhelas: I'm not able to recreate any failure with the gcc patch that's currently committed; indeed, using the changed one you put in gerrit actually results in patch having to offset things. 22.30.58 # _bilgus__: the reason hitting a key worked to un-stick things is because I had keyclicks on. 22.31.08 # <_bilgus__> nice 22.32.02 # <_bilgus__> thats one of those the car works right when i'm barefoot bugs 22.40.08 # <_bilgus__> just realized the samsung y targets have a scrolling line to 'test scrolling'? 22.40.52 # <_bilgus__> I think disabling the thread won't hurt anyone it will just not scroll so should be removed from them 22.42.53 *** Saving seen data "./dancer.seen" 22.45.20 # and if you have more infinite free time, I tore up the pcm-alsa driver more, should have much-reduced intra-track clicking now. 22.45.52 # I had to move the auto-mute point that the rocker uses, but that might not even be necessary any more. 22.52.29 # this mute bug might have actually been the underling cause of the pcm-alsa track skip artifact, but the rework needed doing regardless. 22.52.54 # s/mute/idle frame/ 22.57.35 # <_bilgus__> TBH I didn't really notice it but the hang one I did 22.57.53 Quit prof_wolfff (Ping timeout: 260 seconds) 23.13.28 Join Huntereb [0] (~Huntereb@174.226.0.71) 23.43.28 Join massive_H [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 23.43.55 Quit TheSeven (Disconnected by services) 23.44.05 Join [7] [0] (~quassel@rockbox/developer/TheSeven) 23.46.38 Quit massiveH (Ping timeout: 272 seconds) 23.47.06 Quit Oksana (Ping timeout: 258 seconds)