--- Log for 18.09.124  Server: osmium.libera.chat  Channel: #rockbox
--- Nick: rb-logbot  Version: Dancer V4.16  Started: 24 days and 23 hours ago

00.42.04 Quit    othello7 (Ping timeout: 252 seconds)
00.43.47 Join    spork [0] (topic@126-232-20-31.ftth.glasoperator.nl)
00.51.55 Quit    dconrad (Remote host closed the connection)
01.13.35 Join    dconrad [0] (~dconrad@152.117.104.217)
01.14.16 Join    braewoods [0] (~braewoods@user/braewoods)
01.17.11 Quit    pixelma (Quit: .)
01.17.12 Quit    amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.)
01.18.00 Quit    dconrad (Ping timeout: 252 seconds)
01.18.12 Join    amiconn [0] (jens@p4fd7f6f5.dip0.t-ipconnect.de)
01.18.12 Join    pixelma [0] (marianne@p4fd7f6f5.dip0.t-ipconnect.de)
01.34.15 ***     Saving seen data "./dancer.seen"
02.05.30 #       <edhelas_> I think I might have a clue regarding my battery level issue. In powermgmt.c the faulty function is battery_level(void) that is returning percent_now that is actually a cached percentage. This value is updated in battery_status_update() that seems to relate to this case !storage_disk_is_active() || usb_inserted(), in my case I have a SD card adapter in my iPod.
02.06.25 #       <edhelas_> So I suspect that the storage_disk_is_active() is kind of always returning true which in the end never update the battery_level status.
02.09.58 #       <edhelas_> So this might be related to how the SD adapter ATA interface report its activity. 
02.13.53 #       <edhelas_> I think that this case was there because the Voltage is dropping when the disk is spinning, but it's not an issue with SD adapters, maybe a simple "if(SD) return true" might solve it ? Is there a way to know if Rockbox is running on a SD based iPod ?
02.14.12 #       <edhelas_> *return false
02.19.51 Quit    jacobk (Ping timeout: 276 seconds)
03.15.19 Join    dconrad [0] (~dconrad@152.117.104.217)
03.19.43 Quit    dconrad (Ping timeout: 252 seconds)
03.34.17 ***     Saving seen data "./dancer.seen"
05.02.56 Join    advcomp2019__ [0] (~advcomp20@user/advcomp2019)
05.06.19 Quit    advcomp2019_ (Ping timeout: 260 seconds)
05.34.18 ***     Saving seen data "./dancer.seen"
05.46.26 Join    advcomp2019_ [0] (~advcomp20@user/advcomp2019)
05.49.41 Quit    advcomp2019__ (Ping timeout: 248 seconds)
06.16.39 Join    dconrad [0] (~dconrad@152.117.104.217)
06.21.34 Quit    dconrad (Ping timeout: 260 seconds)
07.06.28 Join    akaWolf [0] (~akaWolf@akawolf.org)
07.13.44 Join    dconrad [0] (~dconrad@152.117.104.217)
07.34.20 ***     Saving seen data "./dancer.seen"
08.13.38 Quit    dconrad (Remote host closed the connection)
08.16.39 Join    dconrad [0] (~dconrad@152.117.104.217)
08.21.06 Quit    dconrad (Ping timeout: 248 seconds)
08.29.12 Quit    Bobathan_ (Ping timeout: 265 seconds)
09.17.02 #       <edhelas_> speachy thanks for the fix, can't wait to try it !
09.34.21 ***     Saving seen data "./dancer.seen"
09.47.17 Quit    Galois (Remote host closed the connection)
09.47.36 Join    Galois [0] (djao@efnet.math.uwaterloo.ca)
09.52.44 Quit    jj5 (Remote host closed the connection)
09.53.09 Join    jj5 [0] (~jj5@100.80.216.139.dynamic.dsl.dv.iprimus.net.au)
09.57.13 #       <speachy> edhelas_: Unfortunately I don't have any way of testing it (my ipod5g's zif connector broke)
10.02.02 #       <_bilgus> edhelas_, nice sleuthing..
10.04.10 #       <speachy> if that translatable-database thing works out as I hope, then extending it to full voicing of the DB is only a smidge more work.
10.04.26 #       <_bilgus> speachy pushing the virtual ptr through name should work nicely without carrying around langid and checking P2ID
10.05.11 #       <speachy> yeah, I was fairly confident that was the case, but I needed to double check before I weighed in.
10.08.38 #       <speachy> overlaying the db browser onto the database tree viewer gives us a lot of stuff for free but it also suffers a bit from a square-peg-round-hole at times.
10.11.40 #       <_bilgus> voicing the db is one of those long time TODOs
10.13.47 #       <speachy> there are some fundamental non-i18n-able aspects of the current design, unfortunately.
10.14.17 #       <speachy> (due to how the entire menu structure is defined in a user-modifiable configuration file)
10.15.39 #       <speachy> Hmm, one thing that would help is to have the DB itself generate the list of "first letters" instead of relying on the static menu list. That way we can pull that aspect out of the config file and into the core.
10.16.03 #       <speachy> (And I don't use the DB at all, heh..)
10.17.11 #       <_bilgus> TBH i don't use it a lot either I usually just generate huge playlists but I think the random selection makes that a better way now
10.19.26 #       <speachy> sweet, the mini2g came back to life.  I can now test my patch
10.19.54 #       <_bilgus> find a good ribbon cable I assume?
10.20.57 #       <speachy> no, the battery had apparently died on itand it wuoldn't power up
10.21.31 #       <speachy> the 5.5g I have with no audio out (and now, a broken drive zif connector) remains a basket case.
10.21.44 #       <speachy> will probably take another change on ebay for a replacement motherboard...
10.24.30 #       <rb-bluebot> Build Server message: 3New build round started. Revision e0df9952fd, 345 builds, 10 clients.
10.24.30 #       <rb-bluebot> 3ata:  Alter ata_is_active() when drive doesn't support power management by Solomon Peachy
10.24.56 #       <speachy> smoke test passed, granted that doesn't test the ipod6g code path but eh..
10.29.55 Join    dconrad [0] (~dconrad@152.117.104.217)
10.34.44 Quit    dconrad (Ping timeout: 260 seconds)
10.35.01 #       <rb-bluebot> Build Server message: 3Build round completed after 632 seconds.
10.35.03 #       <rb-bluebot> Build Server message: 3Revision e0df9952fd result: All green
10.37.03 Join    jacobk [0] (~quassel@47-186-105-237.dlls.tx.frontiernet.net)
10.39.48 #       <speachy> meanwhile.  I think perhaps we should flag all punctuation/symbols in voice strings other than ' , .
10.40.13 #       <speachy> still finding stuff (eg '|' plus paranthesis and other stuff that really doesn't voice properly)
10.43.40 #       <rb-bluebot> Build Server message: 3New build round started. Revision a056150d52, 345 builds, 10 clients.
10.43.41 #       <rb-bluebot> 3updatelang:  Flag '|' in voice strings too by Solomon Peachy
10.45.06 #       <speachy> I'm not a fan of the large number of additional strings added in that db i18n stuff, but it's pretty much a 1:1 map of what's already in tagnavi.config and I don't think it's reasonable/feasible to attempt to concjucat in a way that will work for everything
10.49.40 #       <_bilgus> add in multiple languages and that becomes an even harder task, I think our eventual path will probably be to separate out the lang files for plugins 
10.50.55 #       <_bilgus> basically load  second voice file when plugins load problem being that you still have stuff in core so thatd need duplication or a way to have both at the ready
10.52.01 #       <_bilgus> so probably a script to parse them (plugin lang strings) to go with it
10.52.59 #       <speachy> them there's the matter of a sane way to present all of that to translate.rockbox.org or whatnot
10.53.22 #       <speachy> it's not the "in core" aspect, it's the "sheer total number" 
10.53.57 #       <_bilgus> I think you'd just keep the whole scheme as is they are pretty well delineated and do the separation on the build side
10.54.16 #       <speachy> after this i18n-the-db eventually lands, I want to get rid of the static A-Z alphabetic entries and make that dynamically generated from the DB contents.
10.54.26 #       <rb-bluebot> Build Server message: 3Build round completed after 647 seconds.
10.54.27 #       <rb-bluebot> Build Server message: 3Revision a056150d52 result: All green
10.55.09 #       <_bilgus> I think thats a good idea anyway but need to make it backwards compatible in that a lot of people have custom ones and you don't want to break them
10.56.20 #       <speachy> the only customization I can conceive in the A-Z stuff is "adding $language's alphabet"
10.56.25 #       <_bilgus> probably just searching for the current headers and ignoring the ones that you'll be generating
10.57.30 #       <_bilgus> I wasn't really concerned with their customization in that menu just that if you loaded an older tagnav you'd get both maybe thats not too bad versus the work of checking
10.57.31 #       <speachy> if you'v ecustomized it, I don't expect anything to _break_ as we have to support the existing syntax anway.  This would be some sort of unspecified extension.
10.57.51 #       <speachy> (and a chagne to the default tagnavi.config)
10.58.46 #       <_bilgus> so in that case make it optin and have a placeholder tag?? (#ALPHABETICAL_LIST_HERE)
10.59.15 #       <_bilgus> pretty close to free then
10.59.25 #       <speachy> it would have to be some new token for the engine to parse/handle, yeah.
11.00.16 #       <speachy> the way it works now is that the user is not supposed to modify tagnavi.config in-place; they're supposed to copy it to a different name -- and if that different file exists, it will be used exclusively.
11.01.04 #       <speachy> my goal is that if the user is using the defuault tagnavi.config they'd see no difference, except for a potentially expanded list of "first letter" entries.
11.01.17 #       <edhelas_> Why is the percent_to_volt_discharge and percent_to_volt_charge different with the 6g and similar with the nano2g ? With the 1200mah battery that I have it gives weird behaviours (30% battery remaining => plug charger => charging from 6%)
11.01.39 Quit    jj5 (Remote host closed the connection)
11.02.01 #       <edhelas_> speachy your patch fixes the issue :) But the percentage is far from stable, it seems that the curves doesn't fit with the battery I have
11.02.04 Join    jj5 [0] (~jj5@100.80.216.139.dynamic.dsl.dv.iprimus.net.au)
11.03.07 #       <speachy> it's probably because nobody analyzed the nano2g's battery curves carefully, or it was "close enough" as to not matter.
11.03.10 #       <_bilgus> edhelas there should be a menu to change you capacity if the devices differ between models but otherwise its a compiled change if you have something odd
11.03.59 #       <speachy> if the new battery has the same chemistry as the original, the percentage tables will be accurate.  
11.04.08 #       <_bilgus> if you have a stock battery (or if you don't) you can do a battery bench to update the curves
11.04.47 #       <_bilgus> basically do 3 runs from full to empth average them and choose some points to be your new levels
11.05.04 #       <speachy> but that's a big _if_.  putting aside the questionable quality of "replacement" batteries, there have been plenty of legitimate changes in battery chemistry over the past couple of decades.
11.05.22 #       <edhelas_> I changed the capacity in the menu already, its more about the voltage. From what I see the 6G is the only one to have different values between percent_to_volt_discharge and percent_to_volt_charge tables. For IPOD_NANO, IPOD_VIDEO... and all the others the two tables are the same. 
11.06.03 #       <edhelas_> You can check powermgmt-ipod-pcf.c and powermgmt-6g.c
11.11.33 #       <speachy> only thing to realyl do is to run the battery benchmark with what's in there, and genrate a new set of tables.  
11.11.50 #       <_bilgus> well basically the bettery bench will help correlate that but likely its not going to be perfectly linear being that you are extrapolating that whole range in only 10 steps but it should be good enough 
11.13.05 Quit    jj5 (Read error: Connection reset by peer)
11.13.37 Join    jj5 [0] (~jj5@100.80.216.139.dynamic.dsl.dv.iprimus.net.au)
11.14.49 #       <_bilgus> and its likely to be different between users with even the same battery as that will change between manufacture runs it'll change depending on the battery remaining lifetime and might change if you have a heavier load (sd versus spinning disk)
11.16.19 #       <speachy> all that really matters is our upper and lower thresholds.  and even then uppper doesn't matter if SW isn't in control of battery management.
11.16.46 #       <_bilgus> but the idea is to get it close enough to give an indication (hopefully accurate)
11.17.47 #       <_bilgus> the real danger is for devices that use SW powermanagement for the lower bound but the battery will still cut you off 
11.18.10 #       <_bilgus> so then its atleast just a unexpected powerdowm
11.18.52 #       <_bilgus> suppose same with the upperbound but again the battery should save you
11.20.55 #       <_bilgus> I don't know if we still have any devices where we have to do all the charging stuff (we used to not sure if it went away with hwcodec players)
11.21.49 #       <speachy> I don't think any of our targets require SW management of charging.  beyond plugging parameters into a PMIC/BMIC anyway.
11.22.26 #       <_bilgus> hopefully they went away :)
11.34.25 ***     Saving seen data "./dancer.seen"
11.34.42 Join    Trzyzet_ [0] (~Trzyzet@live-34-b2-v4wan-169259-cust832.vm29.cable.virginm.net)
11.35.05 Join    gevaerts_ [0] (~fg@user/gevaerts)
11.39.31 #       <speachy> ugh, the LiIon archos devices required SW to manage charging?  
11.41.25 Quit    Trzyzet (*.net *.split)
11.41.25 Quit    baltazar (*.net *.split)
11.41.26 Quit    gevaerts (*.net *.split)
11.41.26 Quit    toruvinn (*.net *.split)
11.41.26 Quit    q3k (*.net *.split)
11.41.30 Nick    Trzyzet_ is now known as Trzyzet (~Trzyzet@live-34-b2-v4wan-169259-cust832.vm29.cable.virginm.net)
11.43.06 Join    baltazar [0] (~baltazar@user/baltazar)
11.43.06 Join    q3k [0] (q3k@hswaw/infra/q3k)
11.47.09 Join    toruvinn [0] (~toruvinn@KD119106027116.ppp-bb.dion.ne.jp)
11.58.40 Join    OlsroFR [0] (~OlsroFR@user/OlsroFR)
12.00.13 Quit    jj5 (Remote host closed the connection)
12.01.31 #       <OlsroFR> hello all; I add to read a lot of messages today in IRC haha. I just finished processing all reviews on my merge request and pushing patches.
12.01.46 #       <OlsroFR> But I don't know how to use "name" as a pointer to also store the integer in it
12.02.09 #       <OlsroFR> feel free to amend my merge request with your own solution for this
12.02.22 Join    othello7 [0] (~Thunderbi@pool-100-36-176-164.washdc.fios.verizon.net)
12.04.30 #       <_bilgus> do your check english to id then convert to P2STR and place in name on the other end you use P2ID to see if its a lang entry
12.05.10 #       <_bilgus> speachy might get to it if not i'll try to look tonight
12.05.42 #       <speachy> won't be able to have another look at it until tonight
12.44.22 Quit    TheEater1 (Quit: WeeChat 3.8)
13.24.46 #       <OlsroFR> Ah you want me to directly put the correct name in the "name" field. The issue by doing so is that we need to retrieve the ID again later for voice speech...
13.25.11 #       <speachy> name = ID2P(LANG_WHATEVER)
13.25.39 #       <speachy> later when you need the string you'll do whatever = P2STR(name)
13.26.32 #       <OlsroFR> P2STR will tell if it is a localized string and will fail otherwise ? But what is an entry (like an album name) has a name that is localized ?
13.26.40 #       <speachy> (and we'll use P2ID(...) to retrieve the ID for voice purposes)
13.26.41 #       <OlsroFR> We don't want to localize real album names
13.26.56 #       <OlsroFR> or dynamic things like that
13.26.57 #       <speachy> look up the definition of that
13.27.11 #       <speachy> if it's a non-localized string it just returns the parameter.
13.27.19 #       <OlsroFR> OK
13.27.42 #       <OlsroFR> I am going to work on a patch to try to do this
13.28.25 Quit    OlsroFR (Quit: Client closed)
13.34.26 ***     Saving seen data "./dancer.seen"
13.36.43 Quit    cnx (Remote host closed the connection)
13.37.33 Join    cnx [0] (~cnx@tem.loang.net)
14.26.00 Join    Bobathan [0] (~admin@syn-065-029-248-157.res.spectrum.com)
15.22.26 Quit    jacobk (Ping timeout: 248 seconds)
15.23.03 Join    jacobk [0] (~quassel@47-186-105-237.dlls.tx.frontiernet.net)
15.34.30 ***     Saving seen data "./dancer.seen"
15.35.35 Join    OlsroFR [0] (~OlsroFR@user/OlsroFR)
15.35.38 #       <OlsroFR> Patch pushed ! :)
15.35.43 #       <OlsroFR> I now use the name pointer
15.36.15 #       <OlsroFR> Adding voice control in top of that should still be trivial after this patch
15.56.55 Quit    OlsroFR (Ping timeout: 256 seconds)
15.58.48 #       <_bilgus> OlsroFR I've got a different patch for you to look at
16.06.21 #       <_bilgus> g#5934
16.06.24 #       <rb-bluebot> 3Gerrit review #5934 at https://gerrit.rockbox.org/r/c/rockbox/+/5934 : 3Database Voicing by William Wilgus
16.07.46 #       <_bilgus> that still needs work but it does work I hadn't gotten to the actual voicing part but I think you see the idea
16.07.53 #       <speachy> _bilgus: that patch won't compile...?
16.08.10 #       <speachy> since it requires a variable that you nuked
16.08.20 #       <speachy> oh wait nvm
16.08.32 #       <_bilgus> I was like it compiles for me??
16.11.28 #       <_bilgus> what might be better is to carry the translation through a pointer rather than doing the translation in that buffer copy
16.12.22 Quit    Bobathan (Quit: ZNC 1.8.2+deb2+b1 - https://znc.in)
16.12.41 Join    Bobathan_ [0] (~admin@syn-065-029-248-157.res.spectrum.com)
16.12.51 #       <_bilgus> ln 1808 
16.13.42 #       <_bilgus> sorry ln 809
16.16.45 #       <_bilgus> no it is 1808, 809 OTOH needs some guards to limit its scope
16.23.37 #       <_bilgus> well I guess parse_search() is already limited to the loaded tagnav file so no issue there
16.25.32 Join    OlsroFR [0] (~OlsroFR@user/OlsroFR)
16.30.13 #       <OlsroFR> look like your patch was based on a former version of mine _bilgus. Since then, I now use fully name pointers, I do not even store lang_id anymore :) I put placeholders to add easily voice speech in my last patch
16.32.04 #       <OlsroFR> your solution probably works too though
16.33.05 #       <_bilgus> you still store them static char* current_title_refs[MAX_TAGS];
16.34.04 #       <OlsroFR> Yes it seems like it is needed for retrieval to store refs in this case
16.34.05 #       <_bilgus> the other thing is the overhead yours has to do that logic every refresh i believe
16.34.26 #       <_bilgus> where as what I pushed does it once at load
16.34.32 #       <OlsroFR> yes. That's why my very first proposal was to cache everything at boot and refresh it only on language change
16.34.43 #       <_bilgus> mine needs no caching
16.35.30 #       <OlsroFR> I guess we should use your solution, it is less confusing that my last patch
16.35.35 #       <OlsroFR> than*
16.35.47 #       <OlsroFR> I am going to compile it to test it
16.38.31 #       <_bilgus> the idea is for you to take it from there and finish it up should be enough to get you going but hold off a bit speachy might have some ideas
16.38.50 #       <_bilgus> better implementation in mind
16.40.29 Quit    jacobk (Ping timeout: 260 seconds)
16.40.52 #       <OlsroFR> OK. I will wait. I tested your implementation. Entries are fine. All titles are not translated (all root titles), like "Database".
16.41.58 #       <speachy> I want to see what the latest rev looks like.  I expect I'll want to incorporate some of #5934 but some of it feels like a step backwards (in part because it carried over some things I wanted to see changed)
16.42.29 #       <speachy> and yes, we want titles translated too.  :D
16.43.14 #       <_bilgus> I'm not sure I follow everything looks translated to me
16.43.57 #       <OlsroFR> Feel free to look what I pushed to use 1 hour ago to use the name pointer speachy
16.44.40 #       <OlsroFR> _bilgus Set your player in french, enter the db, then you will see that the title will be "Database" with your patch. It should be "Base de données tags" when things are properly translated
16.44.59 #       <_bilgus> oh the top level item
16.45.57 #       <_bilgus> just didn't make it that far
16.46.39 #       <speachy> turns out that the top level item has historically been not translated
16.46.56 #       <speachy> (overlooked, not intentionally)
16.46.58 #       <OlsroFR> Aside of dev things, today I received the Bose sounddock II I was waiting for. It's sounding damn good and I could get one for very cheap (just around 30 dollars). Now that I use docking features, I can understand why certain options exists like enabling auto backlight on each track change ;) .
16.47.34 #       <speachy> every feature is there because _someone_ found it useful and convinced at least one other person.  :)
16.48.20 #       <OlsroFR> speachy The whole database entries were not translated, including titles. I had to fill up the static files with all the texts to allow translation. Top titles are translated in all other context (if I enter the "Settings", it's correctly translated)
16.49.29 #       <OlsroFR> It seems like the whole database context was coded without any kind of translation in mind at all
16.49.31 #       <speachy> Over the past year I've fixed a bunch of titles in other contexts.
16.50.05 #       <OlsroFR> Ah OK. The rest of the Rockbox experience feels translated everywhere (especially in french thanks to the recent work of edhelas)
16.50.53 #       <OlsroFR> Also, increasing the contrast is another useful option to better see the screen when the iPod is docket. It is helping a lot to read the text especially when it is scrolling
16.50.57 #       <speachy> the FR translation could still use attention; the voice strings with flagged problems and the large pile of "same as english" stuff that needs to be audited and either translated or annotated as intentional.
16.52.04 #       <speachy> speaking of FR, if you or edhelas wants to volunteer to maintain the FR translation, let me know and I'll add you to the notify-on-updates list.
16.52.35 Join    COMPL_EXE [0] (~compl.exe@aosc/dev/origincode)
16.53.11 #       <speachy> (all of the languages that are at 100% have mainatiners that similarly volunteered)
16.54.10 Quit    sam_d (Quit: Bye)
16.54.22 #       <speachy> but yeah, the DB stuff stood out quite dramatically, not just a lack of translation but also the lack of voicing.  very surprising given how much attention has been paid to this in the rest of rockbox.
16.54.47 Join    sam_d [0] (~sam@user/sam-d/x-8933526)
16.57.34 #       <speachy> putting aside my "maintainer of last resort" on everything else, improving the localization and voicing stuff has been my main interest in rockbox.  which is hilarous given how uni-lingual I am.
17.02.13 #       <COMPL_EXE> Hi, I sometimes get usb_dw_gonak_effective failed panic on my FiiO M3K with the latest nightly build when unplugging my usb cable, is there any solution or is that a known issue?
17.05.09 #       <_bilgus> I get a similar panic sometimes haven't seen it in quite a while
17.05.20 #       <speachy> _bilgus: where I want to go wrt the voicing of the db stuff is to create a hierarchy of talkclips, one per indexed field, for each file in teh database.  ".rockbox/talkclips/artists/GeriatricRockers.talk" or "genre/AngryWhiteChickMusic.talk" or whatever.
17.05.33 #       <_bilgus> COMPL_EXE, are you using the latest dev versions?
17.05.59 #       <speachy> yeah there were some USB fixes merged within the last month-ish IIRC?
17.07.14 Quit    OlsroFR (Quit: Client closed)
17.08.17 #       <_bilgus> believe it was g#5825 _lists_uiviewport_update_callback() was getting called with bad data
17.08.21 #       <rb-bluebot> 3Gerrit review #5825 at https://gerrit.rockbox.org/r/c/rockbox/+/5825 : 3[Bugfix] crashes on usb unplug, extra text on USB screen, viewportmgr ovfl on sim by William Wilgus
17.09.02 #       <_bilgus> might be something newer too but I haven't seen it crash since then
17.14.37 #       <_bilgus> speachy so you want to just call the talk files for each header then what switch them out per language isn't that going to be a ton of files to carry around?
17.15.23 #       <speachy> it is, but.. there's no other way to voice the tags.  one clip per unique string
17.15.50 #       <_bilgus> well they are indexed so could you do db_engilish.talk
17.15.59 #       <speachy> the headers etc will prefer the master lang file if possible
17.16.00 #       <_bilgus> db_francisis.talk
17.16.24 #       <speachy> but if the user customizes them they can provide .talk files for those headers.
17.16.32 #       <_bilgus> ah
17.16.57 #       <speachy> eg .rockbox/talkclips/database/headers/SomeCustomizedHeader.talk
17.16.57 #       <_bilgus> but you could also just give them a plugin to smush and index them into a single file
17.17.28 #       <speachy> I see that as a future optmization that may not make sense
17.17.35 #       <speachy> consider that files (and db entries) come and go.
17.17.41 #       <_bilgus> idk I guess its not terrible till you go adding more languages
17.17.55 #       <_bilgus> good directory structure would help
17.18.05 #       <speachy> eh, there's no need for multiple languages in this context
17.18.08 #       <_bilgus> the calling side is simpler here
17.18.44 #       <speachy> the user customizes their stuff?  they generate the talk clips in their preferred language and that's that.  as far as we're concerend, it's just a UTF-8 sequence to look up.
17.19.25 #       <_bilgus> OH ok so you want to add a way for them to do talk clips like we do for folders
17.19.38 #       <speachy> yep.
17.19.47 #       <_bilgus> I was reading that as you wanted us to do that always
17.19.53 #       <_bilgus> gotcha
17.20.33 Join    davisr [0] (~davisr@fsf/emeritus/davisr)
17.21.04 #       <speachy> so we'll need a tool that parses the dbfile on disk and generates a list of all the necessary strings, which it can then pass into the voice generation tooling.
17.21.37 #       <speachy> heck this could even be done entirely in a plugin if we manage to integrate espeak, but I really want to support offline systems due to vastly higher quality options.
17.22.50 #       <_bilgus> I think as long as it will fit I can get that espeak with static allocation running I have the make file about half way there after that I'll see if I can get it closer to upstream
17.22.51 #       <speachy> what I expect to do is build out the code tha tlooks for these talkclips and get that tested, commit that then phase 2 will be the enhanced dbtool/voice.pl generation stuff.
17.23.24 #       <speachy> once I have an end-to-end working implementation, rbutil can probably be extended to do this as well.
17.23.59 #       <speachy> (or maybe the string extraction will be done in a plugin unconditionally, and that file can be passed into whatever.  that's all TBD)
17.24.04 #       <_bilgus> my fear after looking at their (espeak) commits the addition of malloc adds a lot of 'features' that just serve to make it slower for us
17.26.36 #       <_bilgus> I'd assume a perl script should suffice to pull the names out of tagnav but a plugin/native command line driven version might work out better
17.27.55 #       <_bilgus> then you could have the same-ish code in the same module for the plugin and the build side
17.29.32 #       <speachy> we have a per-device dbtool build; I need to investigate if that's still necessary or we can get away with a universal binary.
17.32.03 #       <speachy> it _looks_ like the actual on-disk metadata is the same regardless?
17.34.32 ***     Saving seen data "./dancer.seen"
17.35.20 #       <speachy> it does appear that in the swcodec-only world, all builds should work with the same dbtool binary.
17.37.35 #       <_bilgus> it has handling for endianess in our bin I think and do we have any devices with opposing endian ????
17.39.33 #       <speachy> I think m68k and the native ARM targets are all BE, mips is LE?
17.40.02 #       <speachy> hosted ARMs could go either way I think
17.40.28 #       <speachy> ugh, forgot about the endianness.
17.40.34 #       <COMPL_EXE> _bilgus: I was using 20240915 I believe
17.41.09 #       <_bilgus> COMPL_EXE, then thats new enough then
17.41.17 #       <speachy> so creation of the dbfile probably has to remain at least somewhat target-aware but the data extraction can be universal since the DB files have a header with a magic value that will tell us the endianness.
17.42.25 #       <speachy> I can't imagine the overhead of making the on-disk format to be a fixed endianness would be all that bad.
17.43.41 #       <_bilgus> unless you are on the wrong side of it lol
17.44.19 Join    Moriar [0] (~moriar@107-200-193-159.lightspeed.stlsmo.sbcglobal.net)
17.50.55 #       <speachy> I mean there's not that much numeric data.  we don't use the on-disk structures in RAM.
18.20.04 Nick    Bubblegumdrop_ is now known as Bubblegumdrop (~znc@user/Bubblegumdrop)
18.59.10 Join    dconrad [0] (~dconrad@152.117.104.217)
19.00.52 Quit    davisr (Quit: yeehaw)
19.04.48 Join    davisr [0] (~davisr@fsf/emeritus/davisr)
19.28.54 Quit    Bubblegumdrop (Quit: ZNC 1.9.1+deb1 - https://znc.in)
19.29.25 Join    Bubblegumdrop [0] (~znc@user/Bubblegumdrop)
19.31.33 Quit    Bubblegumdrop (Client Quit)
19.32.33 Join    Bubblegumdrop [0] (~znc@user/Bubblegumdrop)
19.34.36 ***     Saving seen data "./dancer.seen"
19.34.42 Quit    Bubblegumdrop (Client Quit)
19.35.28 Join    Bubblegumdrop [0] (~znc@user/Bubblegumdrop)
19.39.30 Join    massiveH [0] (~massiveH@2600:4040:a982:dc00:6510:df5c:44b6:6738)
19.49.58 Quit    davisr (Quit: yeehaw)
19.50.04 Join    jacobk [0] (~quassel@2603:8080:b200:7b02:77cb:6304:f9db:dda1)
20.06.24 Quit    jacobk (Ping timeout: 260 seconds)
21.05.43 Join    jacobk [0] (~quassel@47-186-105-237.dlls.tx.frontiernet.net)
21.09.41 Join    PheralSparky [0] (~S|h|a|w|n@user/shawn/x-4432647)
21.34.39 ***     Saving seen data "./dancer.seen"
22.16.51 Quit    Moriar (Ping timeout: 246 seconds)
22.57.23 Quit    dconrad ()
23.06.40 Quit    othello7 (Ping timeout: 272 seconds)
23.08.28 Quit    massiveH (Quit: Leaving)
23.34.42 ***     Saving seen data "./dancer.seen"