--- Log for 18.04.120  Server: livingstone.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 16 days and 18 hours ago

00.02.49 ***     Saving seen data "./dancer.seen"
00.18.34 Join    sakax [0] (~r0b0t@unaffiliated/r0b0t)
00.19.52 Join    prof_wolfff [0] (~prof_wolf@195.206.107.25)
00.30.14 Join    PimpiN8 [0] (~PimpiN8@178.239.173.228)
01.06.22 Quit    lebellium (Quit: Leaving)
01.20.16 Join    ZincAlloy1 [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de)
01.21.11 Quit    ZincAlloy (Ping timeout: 256 seconds)
01.28.24 Quit    pamaury (Ping timeout: 256 seconds)
01.48.10 Quit    ZincAlloy1 (Quit: Leaving.)
01.58.45 Quit    petur (Quit: Leaving)
02.02.52 ***     Saving seen data "./dancer.seen"
02.21.27 Quit    MrZeus (Ping timeout: 258 seconds)
02.49.47 Quit    sakax (Remote host closed the connection)
03.17.43 Join    MrZeus [0] (~MrZeus@79-65-237-109.host.pobb.as13285.net)
03.24.04 Join    massiveH [0] (~massiveH@ool-18e4eaeb.dyn.optonline.net)
03.25.00 Quit    MrZeus (Ping timeout: 250 seconds)
03.26.17 #       <speachy> offhand, anyone know what happened to the gerrit commit hook that announced commits to twitter, the mailing list, and presumably IRC too?
03.26.46 #       <speachy> or is it one of those thigns that fell into disrepair as the gerrit instance became mostly unmaintained?
03.27.34 #       <speachy> (I suppose it could have been switched off intentionally...)
03.28.03 Quit    blackyus17 (Ping timeout: 265 seconds)
03.33.47 Quit    prof_wolfff (Ping timeout: 256 seconds)
03.38.35 Join    blackyus17 [0] (~blackyus1@ip189.ip-144-217-213.net)
04.02.56 ***     Saving seen data "./dancer.seen"
04.20.23 Quit    PimpiN8 (Quit: My MacBook has gone to sleep. ZZZzzz…)
04.29.45 Join    fenugrec [0] (~fenugrec@97.107.220.18)
04.31.25 #       <fenugrec> Hi, I'm having issues with Rockbox (hold on, I forgot the version #) on a Sansa Fuze : copying files to the external SD causes the device to shutdown pretty much instantly
04.31.52 #       <fenugrec> the Fuze is old now, is there still any point in filing a proper bug report / getting debug info ?
04.35.32 #       <fenugrec> it crashes / shutdowns when copying to the internal memory too, for that matter...\
04.51.25 Quit    chrisb (Quit: leaving)
04.54.13 #       <fenugrec> I can write to that uSD card just fine in another reader, so I'm inclined to believe the card itself is not (totally) the problem
05.13.33 Quit    fenugrec (Ping timeout: 256 seconds)
05.37.09 Part    Aldem ("Leaving")
05.54.02 Quit    massiveH (Quit: Leaving)
05.58.02 Quit    [7] (Ping timeout: 246 seconds)
05.58.46 Join    TheSeven [0] (~quassel@rockbox/developer/TheSeven)
06.02.59 ***     Saving seen data "./dancer.seen"
06.38.30 Join    advcomp2019 [0] (~advcomp20@65-131-163-116.sxct.qwest.net)
06.38.30 Quit    advcomp2019 (Changing host)
06.38.30 Join    advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019)
06.40.13 Quit    advcomp2019_ (Ping timeout: 240 seconds)
07.48.27 Join    sakax [0] (~r0b0t@unaffiliated/r0b0t)
08.03.03 ***     Saving seen data "./dancer.seen"
09.17.17 Join    lebellium [0] (~lebellium@89-92-253-148.hfc.dyn.abo.bbox.fr)
10.03.04 ***     No seen item changed, no save performed.
10.22.55 Join    prof_wolfff [0] (~prof_wolf@195.206.107.25)
10.47.57 Join    MrZeus [0] (~MrZeus@79-65-237-109.host.pobb.as13285.net)
10.56.51 Join    ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de)
11.01.29 Quit    ZincAlloy (Ping timeout: 256 seconds)
11.04.09 Join    pamaury [0] (~pamaury@rockbox/developer/pamaury)
11.09.11 Quit    ac_laptop (Ping timeout: 265 seconds)
11.20.16 Join    ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de)
11.20.45 Quit    advcomp2019 (Ping timeout: 256 seconds)
11.38.36 Join    dys [0] (~dys@tmo-100-92.customers.d1-online.com)
11.42.25 Quit    S|h|a|w|n (Read error: Connection reset by peer)
11.42.49 #       <Bilgus> fenugrec should have upgraded to the latest Dev version before trying to diagnose bugs, My guess would be a weak battery or funny voltagr settings on the cpu
11.43.10 #       <gevaerts> My guess would be a dead battery
11.51.55 Quit    pamaury (Ping timeout: 256 seconds)
12.03.07 ***     Saving seen data "./dancer.seen"
12.23.40 Join    TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan)
12.46.44 Quit    prof_wolfff (Ping timeout: 256 seconds)
12.57.05 Join    pamaury [0] (~pamaury@rockbox/developer/pamaury)
13.29.57 Quit    sakax (Ping timeout: 256 seconds)
14.01.44 Join    sakax [0] (~r0b0t@unaffiliated/r0b0t)
14.03.09 ***     Saving seen data "./dancer.seen"
14.21.04 Join    prof_wolfff [0] (~prof_wolf@195.206.107.25)
14.29.17 Quit    prof_wolfff (Ping timeout: 265 seconds)
14.50.53 Quit    sakax (Ping timeout: 258 seconds)
14.52.00 Join    sakax [0] (~r0b0t@unaffiliated/r0b0t)
14.52.04 Quit    sakax (Client Quit)
15.08.21 Join    fenugrec [0] (~fenugrec@97.107.220.18)
15.10.22 Quit    koniu (Ping timeout: 240 seconds)
15.10.36 #       <speachy> yay, nighty voice and manual builds went off without a hitch this time.  Fixed another bug in the logbot rottion code, but I do believe all of the moving pieces are good.
15.11.18 #       <speachy> just need to schedule a suitable window for the final transition.
15.21.59 Quit    Rower (Ping timeout: 256 seconds)
15.22.27 Join    Rower [0] (~husvagn@d83-183-134-99.cust.tele2.se)
15.23.53 Join    koniu [0] (~koniu@gateway/tor-sasl/koniu)
15.24.28 Join    sakax [0] (~r0b0t@unaffiliated/r0b0t)
15.35.38 #       <Bilgus> Looks like we really need to put in a wipe Config file option
15.36.33 #       <Bilgus> I know there must be something funky about the version checking code in the cfg file
15.37.31 #       <speachy> hmm, wasn't it just a config version ID?  Or do we actually try to read the whole thing regardless?
15.37.46 #       <Bilgus> or I suppose it could be an option that has bad input
15.38.13 #       <speachy> do we have a copy of the offending cfg file?
15.42.28 #       <Bilgus> I think I asked for it last few times but generally we never get them bc deleting it fixes the issue
15.43.56 #       <Bilgus> I don't actually see any version checking in the cfg load code
15.44.20 #       <Bilgus> https://github.com/Rockbox/rockbox/blob/master/apps/settings.c
15.45.16 Join    krabador [0] (~krabador@unaffiliated/krabador)
15.45.32 #       <fenugrec> Hi, is there any debug logging related to USB MSC mode ? I'm getting crashes when writing to the uSD card over USB on a Fuze
15.46.14 #       <fenugrec> (v 3.14)
15.46.45 #       <speachy> fenugrec, update to 3.15 first, and see if it's still a problem.
15.46.55 #       <fenugrec> speachy, will do. brb
15.48.05 #       <speachy> Bilgus, it's a little inefficient, it effectively ignores keys that aren't recognized..  but there's no protection against (eg) a bad enum setting.
15.50.01 #       <speachy> as there's no range checks baked into the settings parser..
15.50.02 #       <Bilgus> maybe we could put a version Id 'setting'
15.50.27 #       <Bilgus> then if it doesn't match either ignore the config or ask the user
15.51.04 #       <speachy> ie a (ignore once, import, restore defaults) choice?
15.51.33 #       <speachy> and it would be incumbent upon us to bump that version string every time the setings list changes?
15.52.09 #       <speachy> heh, maybe we could get clever and do a checksum of the compiled settings_list table.
15.52.26 #       <speachy> so any change in the table means the old config is potentially invalid.
15.52.27 #       <Bilgus> we already have a version number baked into the fw
15.52.53 #       <Bilgus> we just write that as the version string each time the settings getsaved
15.52.58 #       <speachy> I don't want it to use the compiled fw version, folks that use daily builds will potentially have to reset their config every time they update, which seems unnecessary
15.53.15 #       <Bilgus> they just say import
15.53.44 #       <Bilgus> tada when it writes again the new version string is saved
15.54.09 #       <Bilgus> new build new prompt
15.54.19 #       <speachy> config loading happens pretty early on though, is it feasible to prompt the user that early (before potentially loading in a config that trashes things?)
15.54.30 #       <Bilgus> you could also IGNORE ALWAYS
15.55.12 #       <Bilgus> even if it loads and trashes things they can always restart after
15.55.56 #       <Bilgus> we don't actually HAVE to have a prompt it could just be a WARNING in the settings
15.56.15 #       <Bilgus> WARNING CONFIG VER MISMATCH
15.56.39 #       <Bilgus> pretty sure we have a config reset option
15.57.24 #       <speachy> yeah, "reset settings" in the manage settings menu
15.57.34 #       <Bilgus> yeah I just had to look too
15.58.18 #       <Bilgus> so we already have the means just bring user to that menu after they answer
15.59.15 #       <Bilgus> I'll think something up< I don't think its feasible to sanatize the settings
15.59.36 #       <speachy> no, sanitizing the settings is effectively impossible (especially across the swath of tergets)
15.59.38 #       <Bilgus> although there already is a mechinism for checking their values
15.59.57 #       <Bilgus> they all get checked when the setting is input
16.00.30 #       <Bilgus> but I veered away from that due to the fact those Ranges don't always match what people want
16.00.43 #       <Bilgus> 32000 files in the browser for instance
16.01.25 #       <Bilgus> atm they can bump that in the cfg if I check inputs they get what they get (and throw a fit?)
16.02.17 #       <speachy> we really should check be checking enum ranges where they're known.
16.03.13 ***     Saving seen data "./dancer.seen"
16.03.15 #       <Bilgus> then you have to go through and specify what shouldn't be checked
16.03.18 #       <speachy> because no version check will catch a file deliberately modified..
16.03.31 #       <fenugrec> speachy, ok, can't reproduce with 3.15, but I also fsck'd the uSD so that might have helped too...
16.04.21 #       <Bilgus> I feel like if you screw it up deliberatly then you kno why its screwed up
16.04.24 #       <fenugrec> but I do get a strange dmesg entry " sdd: detected capacity change from 7948206080 to 0 " after unmounting the uSD
16.04.52 #       <speachy> fenugrec, the card was logically "ejected" from the slot.
16.05.02 #       <Bilgus> that sounds like a entirely logical message
16.05.09 #       <Bilgus> lol
16.05.15 #       <Bilgus> that^
16.06.15 #       <Bilgus> Idk i'll mull it over if we are going to check enums then
16.06.25 #       <Bilgus> I might crc the whole file
16.06.54 #       <Bilgus> get rid of manual editing and give them a script
16.08.09 #       <Bilgus> or just get rid of manual editing and se some better limits
16.08.14 #       <speachy> well, for now we know checking to see if the settings list has changed from when the file was saved is a good thing.
16.08.36 #       <speachy> dealing with user stupidity/maliciousness is a step beyond that.
16.08.47 #       <Bilgus> crc is pretty cheap too
16.09.12 Join    prof_wolfff [0] (~prof_wolf@195.206.107.25)
16.09.35 #       <speachy> especially as it's already present in the firwmare images.  :P
16.10.59 #       <Bilgus> as far as checking ranges I can just use the macros already there in the settings code
16.11.08 #       <speachy> IMO it needs to be a runtime checksum rather than compile-time, or we should checksum the preprocessed version, as the HAVE_XXX definitions can change (thereby changing the settings table) without the actual file changing
16.12.19 #       <speachy> pretty trivial to implement the actual checksum and verification.  UI about what to do is the more complex bit
16.12.29 #       <Bilgus> it'll just be a runtime checksum only I think
16.13.05 #       <fenugrec> well, I'll be back if it acts up again. Thanks
16.13.15 #       <Bilgus> between that and checking enums compared to the settings
16.13.44 #       <Bilgus> I think we will leave the user config file alone though
16.14.13 #       <Bilgus> the overide file I can never remember the name
16.15.04 #       <Bilgus> FIXEDSETTINGSFILE
16.15.23 #       <Bilgus> the nvram already crc checks its settings
16.16.38 #       <Bilgus> so no user prompt just strong checking inputs a crc and a fixed settings cfg file that allows freedom
16.17.18 #       <Bilgus> then you can still break it if you want to but normal users get a better experience
16.18.47 #       <speachy> weyeah
16.20.42 Quit    prof_wolfff (Ping timeout: 260 seconds)
16.22.37 #       <pixelma> like it's called "fixed" + settingsfile file extension (I believe ".cfg" but am not sure)
16.22.54 Part    fenugrec ("Leaving")
16.24.47 #       <speachy> well, g#2361 is what I just pulled from my posterior
16.24.48 #       <fs-bluebot_> Gerrit review #2361 at http://gerrit.rockbox.org/r/2361 : WIP:  Checksum settings table, and detect if it changes. by Solomon Peachy
16.25.11 #       <speachy> it compiles therefore it must be okay.  :D
16.27.25 #       <speachy> now it doesn't actually _do_ anything when it detects the checksum has changed.  but, eh, have to start somewhere
16.27.51 #       <speachy> (did this as an exercise/refresher in my own edumication; feel free to ignore it)
16.34.15 #       <Bilgus> lol you are the overachiever
16.48.14 #       <speachy> story of my life.. misguided overachievement
16.48.27 #       <speachy> it's how I fill the endless void in my soul
16.49.16 #       <speachy> but now the rest of the natives are stirring, and I'm on breakfast duty.
17.41.58 Join    chrisb [0] (~chrisb@unaffiliated/chrisb)
18.03.18 ***     Saving seen data "./dancer.seen"
18.47.45 Join    ac_laptop [0] (~ac_laptop@37.166.82.250)
18.55.24 Quit    Frans-Willem (Ping timeout: 264 seconds)
19.09.39 Quit    krabador (Quit: Leaving)
19.14.12 Join    PimpiN8 [0] (~PimpiN8@178.239.173.228)
19.17.35 Join    PimpiN8_ [0] (~PimpiN8@178.239.173.228)
19.18.51 Quit    PimpiN8 (Ping timeout: 256 seconds)
19.22.24 Quit    fs-bluebot_ (Ping timeout: 264 seconds)
19.24.31 Join    fs-bluebot [0] (~fs-bluebo@port-92-193-93-3.dynamic.as20676.net)
19.25.02 Join    Frans-Willem [0] (~quassel@94-210-82-195.cable.dynamic.v4.ziggo.nl)
19.27.10 Quit    fs-bluebot (Remote host closed the connection)
19.29.24 Join    bluebrother [0] (~dom@rockbox/developer/bluebrother)
19.29.29 #       <speachy> okay, updated the patch, now it actually works.
19.30.11 #       <speachy> all it does is splash "cfgver changed" on startup.
19.31.33 Join    fs-bluebot [0] (~fs-bluebo@port-92-193-93-3.dynamic.as20676.net)
19.43.10 Quit    bluebrother (Read error: Connection reset by peer)
19.43.10 Quit    fs-bluebot (Read error: Connection reset by peer)
19.43.21 Join    bluebrother [0] (~dom@rockbox/developer/bluebrother)
19.43.34 Join    fs-bluebot [0] (~fs-bluebo@port-92-193-93-3.dynamic.as20676.net)
20.03.19 ***     Saving seen data "./dancer.seen"
20.10.25 Quit    ac_laptop (Ping timeout: 256 seconds)
20.30.26 Join    S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156)
20.35.29 Join    advcomp2019 [0] (~advcomp20@65-131-163-116.sxct.qwest.net)
20.35.29 Quit    advcomp2019 (Changing host)
20.35.29 Join    advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019)
20.59.38 Quit    sakax (Quit: Leaving)
21.00.01 Join    sakax [0] (~r0b0t@unaffiliated/r0b0t)
21.07.41 Quit    GeekShadow (Ping timeout: 260 seconds)
21.08.04 Join    ac_laptop [0] (~ac_laptop@37.166.42.10)
21.13.41 Quit    ac_laptop (Read error: Connection reset by peer)
21.13.56 Quit    bertrik (Read error: Connection reset by peer)
21.31.43 Join    prof_wolfff [0] (~prof_wolf@195.206.107.25)
21.41.25 Join    GeekShadow [0] (~antoine@nzf.turmel.info)
21.41.26 Quit    GeekShadow (Changing host)
21.41.26 Join    GeekShadow [0] (~antoine@reactos/tester/GeekShadow)
22.03.21 ***     Saving seen data "./dancer.seen"
22.49.05 Quit    prof_wolfff (Ping timeout: 256 seconds)
23.04.23 Join    prof_wolfff [0] (~prof_wolf@195.206.107.25)
23.18.21 Quit    lebellium (Quit: Leaving)
23.19.56 Quit    sakax (Quit: Leaving)
23.44.10 Quit    TheLemonMan (Quit: "It's now safe to turn off your computer.")