--- Log for 18.11.121 Server: strontium.libera.chat Channel: #rockbox --- Nick: rb-logbot Version: Dancer V4.16 Started: 5 days and 6 hours ago 00.10.57 *** No seen item changed, no save performed. 01.21.10 Quit rb-bluebot (Ping timeout: 256 seconds) 01.21.18 Join rb-bluebot [0] (~rb-bluebo@rockbox/bot/utility) 01.30.51 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:6ca0:4ab:b2e9:a1f) 01.35.29 Quit ZincAlloy (Ping timeout: 265 seconds) 01.54.05 Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) 01.58.41 Quit ZincAlloy (Ping timeout: 265 seconds) 02.11.01 *** Saving seen data "./dancer.seen" 04.00.18 # _bilgus Thank you so much so much for your suggestion. This is very useful. It time for me to learn Lua script. 04.00.27 # Thanks again. 04.00.56 # BTW, I have post to the forum as well. I think I will post your suggest there. 04.01.25 # https://forums.rockbox.org/index.php/topic,54047.0.html 04.01.33 # It can be useful for others. 04.02.15 # @braewoods I agree with you that is not convenient. It just my personal hobby. 04.02.53 # Here is my website, most contents are in Thai, some are English but Google translator should be okay. 04.03.03 # https://onlyminidisc.com/ 04.05.15 # Using Net MD is a good way to transfer music. However, there are some people who believe transfer 1:1 is the best sound quality. This is my a little resource what if I can make auto tracking 1:1 correctly. 04.06.11 # In fact, I usually use Net MD and here is my manual for Web MiniDisc. 04.06.27 # https://onlyminidisc.com/net-md/web-mini-disc-manual 04.11.02 *** No seen item changed, no save performed. 04.55.33 Quit aaronamm (Quit: Connection closed) 06.11.04 *** Saving seen data "./dancer.seen" 07.37.40 Quit munkis (Ping timeout: 265 seconds) 07.55.09 Join munkis [0] (~mendel_mu@ool-ae2cb218.dyn.optonline.net) 08.11.06 Quit munkis (Remote host closed the connection) 08.11.08 *** Saving seen data "./dancer.seen" 08.11.30 Join munkis [0] (~mendel_mu@ool-ae2cb218.dyn.optonline.net) 08.17.13 # well it took a year but someone complained about g#2960 08.17.16 # 3Gerrit review #2960 at https://gerrit.rockbox.org/r/c/rockbox/+/2960 : 3Quickscreen: don't apply glabal settings by Moshe Piekarski 08.18.32 # aaalthough I think the bug in fs#13319 is the inverse of the report. 08.18.33 # https://www.rockbox.org/tracker/task/13319 3Default Sleep Timer Duration shows different behavior when changed from a shortcut (bugs, unconfirmed) 08.18.56 # oh wait nvm different par tof the code 08.19.21 # (although I still think the expected behavior is strange) 08.46.10 Join massiveH [0] (~massiveH@ool-4a5862ee.dyn.optonline.net) 09.48.00 # <_bilgus> munkis not setting till later seems odd is it just missing the setting_save() 09.48.01 # <_bilgus> ? 09.49.21 Join chris_s [0] (~chris_s@ip-95-223-74-199.hsi16.unitymediagroup.de) 09.49.40 # I think the Settings menu does additional work in the callback method to actually change the running timer duration 09.55.22 Quit chris_s (Quit: Connection closed) 09.56.25 # <_bilgus> I was thinking the current way where we emulate the menu item isn't so great but I don't know that pulling you to the menu is possible (currently not) 09.58.24 # <_bilgus> the problem being that no one ever set a way to expand the menus without the user clicking them 10.03.11 # _bilgus: i fell like changing the default timer length shouldn't suddenly affect a running timer. 10.05.11 # <_bilgus> IDK probably it should ask I think both might be desired depending on the user 10.07.47 Join chris_s [0] (~chris_s@ip-95-223-74-199.hsi16.unitymediagroup.de) 10.08.42 Join aaronamm [0] (~aaronamm@146.88.46.49) 10.09.43 # Would probably make sense to change the name to "Sleep Timer Duration" (i.e. remove the "default") 10.10.07 Quit chris_s (Client Quit) 10.11.11 *** Saving seen data "./dancer.seen" 10.13.34 Join chris_s [0] (~chris_s@ip-95-223-74-199.hsi16.unitymediagroup.de) 10.13.59 # <_bilgus> yeah default makes it sound like it should have the behaviour munkis is saying 10.14.00 Quit chris_s (Client Quit) 10.17.05 Quit massiveH (Quit: Leaving) 11.24.06 Quit paulcarroty (K-Lined) 11.24.08 Quit kadoban (K-Lined) 11.24.10 Quit blbro[m] (K-Lined) 11.24.11 Quit MayeulC (K-Lined) 11.35.03 Join kadoban [0] (~kadoban@user/kadoban) 11.38.29 Quit zizzy (Ping timeout: 264 seconds) 11.39.45 Quit asaba (Quit: Relay server offline) 11.40.03 Quit hook54321 (Read error: Connection reset by peer) 11.41.49 Join zizzy [0] (sid385519@lymington.irccloud.com) 11.42.44 Join asaba [0] (~asabas@103.113.159.250) 11.43.28 Join paulcarroty [0] (~paulcarro@2001:470:69fc:105::216) 11.43.28 Join MayeulC [0] (~mayeulc@2001:470:69fc:105::35e) 11.43.40 Join blbro[m] [0] (~blbrostra@2001:470:69fc:105::8f7) 11.45.37 Join hook54321 [0] (sid149355@user/hook54321) 11.59.31 Quit kadoban (Quit: Client limit exceeded: 20000) 12.00.04 Quit paulcarroty (Quit: Client limit exceeded: 20000) 12.00.06 Quit MayeulC (Quit: Client limit exceeded: 20000) 12.11.14 *** Saving seen data "./dancer.seen" 13.07.15 Join ZincAlloy [0] (~Adium@ip5f5abcae.dynamic.kabel-deutschland.de) 13.11.47 Quit ZincAlloy (Ping timeout: 264 seconds) 13.12.29 Quit munkis (Remote host closed the connection) 13.12.54 Join munkis [0] (~mendel_mu@ool-ae2cb218.dyn.optonline.net) 13.29.33 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:dc45:d26:4c5d:c799) 13.29.55 Quit j-r (Remote host closed the connection) 13.31.23 Join lebellium [0] (~lebellium@2a01cb04012c09005939187678873d1a.ipv6.abo.wanadoo.fr) 13.49.14 Join amachronic [0] (~amachroni@user/amachronic) 13.55.00 Join j-r [0] (~j-r@p2003000623cebf71404207fffefd0a65.dip0.t-ipconnect.de) 13.58.23 # speachy: so the x3 is still panicking on USB insert and you got a log of that? 13.58.32 Join kadoban [0] (~kadoban@user/kadoban) 13.58.32 Join paulcarroty [0] (~paulcarro@2001:470:69fc:105::216) 13.58.32 Join MayeulC [0] (~mayeulc@2001:470:69fc:105::35e) 13.59.55 # i made a test build anyway which might give more useful logs if you'd like to try it 14.00.03 # https://drive.google.com/file/d/1bs6lMfekT9KF25AAWJCOix7T-x6FA46D/view?usp=sharing 14.03.44 # Build Server message: 3New build round started. Revision 6e61e6f0c8, 303 builds, 10 clients. 14.11.16 *** Saving seen data "./dancer.seen" 14.12.27 Join jschwart [0] (~quassel@2001:985:2c6e:0:b00b:32ff:fe28:5567) 14.13.56 # Build Server message: 3Build round completed after 612 seconds. 14.13.58 # Build Server message: 3Revision 6e61e6f0c8 result: All green 14.14.55 # Build Server message: 3New build round started. Revision 701d4ba77e, 303 builds, 10 clients. 14.20.23 Quit aaronamm (Quit: Connection closed) 14.23.01 # amachronic: yeah, I've been trying to wade into it. the screen's so tiny that there's only a handful of logged lines 14.23.17 # so I've been trying to get hardware sniffs but my sniffer is being churlish. 14.23.42 # well, the build I made hopefully won't panic so you can do a normal log file dump from the debug menu. 14.24.02 # debugging via panic is a PITA. 14.24.19 # Build Server message: 3Build round completed after 563 seconds. 14.24.20 # Build Server message: 3Revision 701d4ba77e result: All green 14.24.53 # I've been adding additonal instrumentation to try and sort out the flow 14.25.33 # amachronic: https://www.shaftnet.org/~pizza/x3.txt 14.25.39 # that's my WIP notes from this 14.27.06 # that's one of two panic sequences (by far the most common) 14.27.55 # most likely its all some tiny deviation from the old behavior which I unintentionally created 14.28.20 # ... and the driver is doing something "special" 14.28.32 # my test build has all requests logged, i used it on fs13315/fs13316 to sort out the mess on ipod. 14.28.56 # which turned out to be the ARC driver submitting endpoint completes for EP0 for every control packet 14.29.09 # or rather, setup packet 14.36.20 # doing nothing on a zero-length send/recv sounds a bit odd though. 14.37.53 # but I guess it must've worked before 14.44.52 # ok, I have a full logf if you want 14.45.02 # sure 14.46.17 # https://www.shaftnet.org/~pizza/logf-1.txt 14.48.27 # we get what appears to be a spurious interrupt, then one with OUTPKTRDY, which feeds into the ctrl received 751 14.49.13 # drv_recv, drv_send, ctrl handled 751, then the null ctrl req (twice) with the same arguments 14.53.12 # huh. it's hard to see what's wrong since we're missing most of the usb_core API side of things. 14.53.33 # hmm, a GET_DESCRIPTOR seems comes in before the GET_INTERFACE is apparently handled/responded to 14.54.01 # i am only guessing but maybe a new packet is getting submitted before the last one has been properly acked? 14.54.58 # that'd explain why zero-length send/recv being a no-op works -- the driver is acking the packet before the core has handled it 14.55.33 # yeah... the driver/hardware would appear to be handling it. 15.00.24 # am I right that this is the jz47xx's USB controller? 15.00.28 # https://dl.linux-sunxi.org/users/tom/musbmhdrc_pspgUSB.pdf 15.00.30 # ... 4760, yes 15.01.04 # (I'm trying to figure out how they think setup transactions should be handled) 15.01.26 # yeah. I did a lot of work on this thing but I didn't change the control stuff at all 15.02.12 # ok. i also noticed the 4740 seems to be the same controller, yet we have two drivers. :/ 15.02.42 # no ability to test the newer driver on the -40 hardware. : 15.03.06 # ok, just disabled the "if control ep and null packet, skip" test. 15.05.04 # it seems setting DataEnd is how you tell the controller the request is handled so I guess it's being set too early by the driver 15.09.59 # https://www.shaftnet.org/~pizza/logf-2.txt 15.10.08 # yeah any non-data request won't wait until the usb stack acks so the driver will just proceed ahead with a new packet. 15.10.33 # still see the two null reqs but now there's something sent over between 'em. 15.21.56 # the order of things should always be "ctrl received" - "ctrl handled" - "ctrl response" and it looks like that isn't happening. 15.25.38 # making sense of this mess seems to be a necessary prereq for reworking it to use the new API natively 15.25.40 # ctrl received 765, req=0x6 shouldn't happen until *after* the recv/send pair right below it 15.26.13 # yeah, this is why I want to see traffic sniffs 15.27.10 # I'm pretty sure it's just an "obvious" driver bug. there's nothing too crazy going on. 15.27.43 # one look at that EP0_handler ... I'm not surprised you're afraid to touch it :D 15.27.43 # the control endpoints have a ton of special casing 15.28.04 # yep, and every controller has some special snowflake way of doing it. 15.44.51 # I don't see a SETUPEND ever triggered, and that's what triggers teh transfer_complete() call for blockning EP0 writes (which I think is all of them) 15.46.36 # and we nver check solely for DATAEND for EP0.... 15.47.10 # the comment in SETUPEND explains it's only for retried packets 15.47.30 # ie. only if from the controller perspective, the request is being handled and a new one from the host interrupts it. 15.47.47 # DATAEND is something the CPU sets, not the controller 15.48.22 # eg. L317 and L330 15.48.34 # also L246 15.48.50 # ok. 15.49.18 # REG_USB_INTRUSB has bit 3 set (ie 0x08) in some of the interrupts, that's not handled (or even documented) in the jz headers. 15.49.50 # seems to happen after the drv_send()s 15.50.31 # according to the MUSB doc that's SOF = Set when a new frame starts. 15.54.18 # this controller seems to provide a packet-at-a-time interface for EP0 much like the dwc2 controller. 15.55.01 # question is how do you figure out a setup packet arrived vs. a normal data packet or do you need to guess. 16.02.56 # ... and it sounds like the driver needs to track that state itself. 16.03.05 # yep 16.03.12 # and I suppose that's where things are going wonky 16.08.37 Join johnb5 [0] (~johnb2@p5b3aff7b.dip0.t-ipconnect.de) 16.09.24 # that MUSBMHDRC manual is reasonably clear about how to handle things. 16.09.40 # should be easy to map onto the new API 16.11.17 *** Saving seen data "./dancer.seen" 16.12.31 # I'd just rip out all the EP0 handler bits and rewrite 'em. not worth the effort to refactor IMHO. 16.12.38 # yeah 16.12.58 # I was hoping to get it back to "working" first so it would be useful as a reference 16.13.01 # but eh 16.13.02 Quit johnb5 (Ping timeout: 260 seconds) 16.15.16 # just removing the panic should put it back to "working" 16.16.01 # i figure the OS would retry if it got bogus data so bugs were silently papered over by retrying the request 16.17.37 # without the panic it comes up with HID but mass storage isn't working. 16.18.00 # oh. 16.18.19 # (it enumerates but doesn't find an actual drive) 16.19.28 # I did put in intentional deviations from the old behavior for control writes, which HID happens to exercise. 16.19.57 # turning off HID could make the drive appear 16.30.13 Join wsa [0] (~wsa@p5486cca9.dip0.t-ipconnect.de) 16.30.14 # nope 16.33.08 # oh well 16.34.22 # hi, I just pushed an updated patch of RDS support for the Sansa Clip+ 16.34.58 # I'll be around a little more in case somebody wants to discuss it 16.38.52 # and as the RDS polling is now generic, if someone could test the conversion of the Samsung YPR0/1 which I also pushed... that would be awesome 16.40.20 # thank you! 16.43.44 Quit amachronic (Quit: amachronic) 16.43.47 # let's change the ypr0|1 rds polling to the same as the clip 16.44.00 # donig it on every tick seems excessive. 16.44.22 # Build Server message: 3New build round started. Revision de0346065b, 303 builds, 10 clients. 16.46.32 # wsa: can you do that with #3972 and resubmit? 16.46.47 # is one tick the same on every target? 16.46.54 # speachy: sure thing 16.52.01 # done 16.53.40 # speachy: oh wow, you merged it already, thanks! 16.54.17 # it was a much cleaner approach than the original IMO 16.54.34 # with no obvious issues, so.. why let it sit? 16.54.58 # (the original patch all of this was based on has been in gerrit since 2012...) 16.55.33 # Yes, the improvements from one version to the next were always good, I think 16.55.49 # just a pity it was always 5 years between the versions :/ 16.56.15 # Build Server message: 3Build round completed after 713 seconds. 16.56.16 # Build Server message: 3Revision de0346065b result: All green 16.56.20 # Build Server message: 3New build round started. Revision 336ea51af6, 303 builds, 9 clients. 16.56.22 # I've been distrated by other stuff lately but what really got me involved with rockbox was not wanting to see a large pile of third-party contributions/patches/etc continue to languish 16.56.41 # I wasn't sure if RDS_CFG_POLL was acceptable, I am glad it is... 16.57.13 # it was that or add HAVE_RDS_POLL 16.57.20 # speachy: I am with you there 16.57.44 # since we already had CONFIG_RDS as a bitmask, it was the right call IMO 16.58.01 # I am definately not short of tasks, but having this device and seeing these RDS patches was an itch I just had to scratch 17.08.38 # Build Server message: 3Build round completed after 739 seconds. 17.08.39 # Build Server message: 3Revision 336ea51af6 result: All green 17.10.59 # for the record, I also checked the GPIO ports when receiving RDS data for some other pin toggling indicating an RDS interrupt 17.11.05 # no surprise, there was none 17.19.24 Join cockroach [0] (~blattodea@user/cockroach) 17.30.06 # amachronic: btw the 4740 vs 4760 share the same licensed core, but the -40 only has 5 endpoints and the -60 seems to have the full set of 16. 17.30.49 # (another difference is that the -40 can't do an INTERRUPT OUT endpoint..) 17.32.49 Quit ZincAlloy (Quit: Leaving.) 17.34.23 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:c52c:f3a1:3b3b:ea2b) 18.11.19 *** Saving seen data "./dancer.seen" 18.12.11 Quit wsa (Quit: ...) 18.15.32 Quit lebellium (Ping timeout: 240 seconds) 18.19.00 Join lebellium [0] (~lebellium@2a01cb04012c09005939187678873d1a.ipv6.abo.wanadoo.fr) 18.26.13 Quit ZincAlloy (Quit: Leaving.) 18.38.32 Quit lebellium (Quit: Leaving) 18.44.01 Quit tchan (Ping timeout: 265 seconds) 18.50.53 Join Solanacean [0] (solanacean@176.214.16.178) 18.52.27 Quit Solanacean_ (Ping timeout: 250 seconds) 19.02.14 Join tchan [0] (~tchan@c-98-206-141-238.hsd1.il.comcast.net) 20.11.20 *** Saving seen data "./dancer.seen" 21.13.38 Quit cockroach (Quit: leaving) 21.34.02 Quit j-r (Ping timeout: 240 seconds) 21.34.33 Join j-r [0] (~j-r@p2003000623cebf96404207fffefd0a65.dip0.t-ipconnect.de) 22.11.23 *** Saving seen data "./dancer.seen"