--- Log for 08.03.121 Server: beckett.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 2 days and 8 hours ago 00.07.14 Quit ender| (Ping timeout: 264 seconds) 00.10.00 Join ender| [0] (~ender1@2a01:260:4094:1:6045:6fff:fedd:cbf3) 00.46.13 Join kadobanana [0] (kadoban9he@gateway/shell/matrix.org/x-gliltzokamjplayu) 00.50.25 Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156) 01.19.07 *** Saving seen data "./dancer.seen" 03.19.09 *** No seen item changed, no save performed. 04.14.33 Join petur [0] (~petur@199.59.5.11) 04.14.33 Quit petur (Changing host) 04.14.33 Join petur [0] (~petur@rockbox/developer/petur) 04.41.54 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 05.19.13 *** Saving seen data "./dancer.seen" 05.28.05 Quit S|h|a|w|n (Read error: Connection reset by peer) 05.29.06 Join J_Darnley [0] (~J_Darnley@d51a44418.access.telenet.be) 05.29.39 Quit jschwart (Ping timeout: 245 seconds) 05.29.47 Join jschwart [0] (~quassel@2001:985:2c6e:0:b00b:32ff:fe28:5567) 05.30.58 Quit jdarnley (Ping timeout: 276 seconds) 05.54.38 Quit atsampson (Ping timeout: 258 seconds) 06.16.25 Join atsampson [0] (~ats@cartman.offog.org) 07.19.14 *** Saving seen data "./dancer.seen" 08.12.49 Join speachy [0] (~speachy@209.2.65.77) 08.41.03 Quit Saijin_Naib (Remote host closed the connection) 08.46.53 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net) 08.57.13 # braewoods: I just plugged in my X3, and Fedora popped up a "your wireless keyboard battery is low" notification. 08.58.11 # within 60 seconds it had climbed to 41%. 08.58.52 # (from 6%) 08.58.53 # your X3 is running on diesel ?! 08.59.50 # diesel? (I must be missing a connection here. and I'm usually the one making those giant leaps of consipiracy-level connections..) 09.00.16 # charging something with lots of energy, hard to do that with a Li-Ion battery :p 09.01.24 Part edhelas 09.01.36 Join edhelas [0] (9d94237298@2a03:4000:51:f44:4e1:2ff:fe00:4257) 09.01.57 Quit ender| (Ping timeout: 268 seconds) 09.03.19 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-8de9-aefd-000f-730e.res6.spectrum.com) 09.05.09 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) 09.15.33 Quit J_Darnley (Ping timeout: 264 seconds) 09.19.15 *** Saving seen data "./dancer.seen" 09.25.40 Join J_Darnley [0] (~J_Darnley@d51a44418.access.telenet.be) 09.33.41 # you can probalby get more energy out of burning 10ml of diesel than is contained in this battery. 09.36.01 # but I only have one thing that runs on diesel, and it blew a hydraulic line yesterday. :/ 09.53.42 Quit J_Darnley (Ping timeout: 256 seconds) 09.55.11 Join J_Darnley [0] (~J_Darnley@d51a44418.access.telenet.be) 10.10.01 Quit massiveH (Quit: Leaving) 11.19.16 *** Saving seen data "./dancer.seen" 12.22.36 Join jdarnley [0] (~J_Darnley@d51a44418.access.telenet.be) 12.24.33 Quit J_Darnley (Ping timeout: 264 seconds) 12.28.36 Quit jdarnley (Ping timeout: 246 seconds) 12.34.43 Quit ubervison (Remote host closed the connection) 12.36.57 Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be) 12.55.12 Quit koniu (Ping timeout: 268 seconds) 13.03.32 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 13.14.19 Quit koniu (Ping timeout: 268 seconds) 13.19.19 *** Saving seen data "./dancer.seen" 13.27.22 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 13.29.38 Quit koniu (Remote host closed the connection) 13.30.22 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 13.31.13 Quit koniu (Remote host closed the connection) 13.31.25 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr) 13.37.12 Join ender| [0] (~ender1@2a01:260:4094:1:6045:6fff:fedd:cbf3) 13.47.46 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 13.56.08 Quit koniu (Remote host closed the connection) 13.56.41 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 14.09.12 Quit koniu (Ping timeout: 268 seconds) 14.12.49 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 14.13.10 Join jdarnley [0] (~J_Darnley@d51A44418.access.telenet.be) 14.15.02 Quit J_Darnley (Ping timeout: 264 seconds) 14.15.16 Quit koniu (Remote host closed the connection) 14.16.29 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 14.16.40 Quit koniu (Remote host closed the connection) 14.17.16 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 14.17.21 Quit koniu (Remote host closed the connection) 14.17.52 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 14.17.58 Quit koniu (Remote host closed the connection) 14.18.27 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 14.19.30 Quit koniu (Remote host closed the connection) 14.20.02 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 14.22.21 Quit koniu (Remote host closed the connection) 14.22.51 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 14.23.02 Quit koniu (Remote host closed the connection) 14.23.36 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 14.23.51 Quit koniu (Remote host closed the connection) 14.24.22 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 14.34.02 Quit koniu (Remote host closed the connection) 14.34.38 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 14.37.29 Quit koniu (Remote host closed the connection) 14.38.07 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 14.38.16 Quit koniu (Remote host closed the connection) 14.39.16 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 14.39.51 Quit koniu (Remote host closed the connection) 14.40.18 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 14.40.40 Quit koniu (Remote host closed the connection) 14.41.08 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 14.41.32 Quit koniu (Remote host closed the connection) 14.42.40 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 14.45.22 Join p3tur [0] (~petur@rockbox/developer/petur) 14.45.33 Quit petur (Read error: Connection reset by peer) 14.45.42 Join ubervison [0] (~ubervison@2a02:aa12:b106:1b80:6257:18ff:fe9b:d6a1) 14.52.58 Quit ubervison (Quit: Leaving) 14.57.38 Quit Rower (Ping timeout: 264 seconds) 15.01.04 Quit ender| (Quit: …it's true that some of the most terrible things in the world are done by people who think, genuinely think, that they're doing it for the best, especially if there is some god involved. — Terry Pratchett: Snuff) 15.10.52 Join Rower [0] (~Rower@185.246.208.210) 15.14.39 Quit Acou_Bass (Quit: ZNC 1.8.2 - https://znc.in) 15.16.42 Join Acou_Bass [0] (~Acou_Bass@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net) 15.19.21 *** Saving seen data "./dancer.seen" 15.23.41 Join ender| [0] (krneki@2a01:260:4094:1:42:42:42:43) 15.23.58 Quit p3tur (Quit: Connection reset by beer) 15.33.33 Quit ufdm (Read error: Connection reset by peer) 15.36.21 Quit michaelni (Quit: Leaving) 15.37.51 Join michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at) 15.55.21 Quit TheLemonMan (Quit: "It's now safe to turn off your computer.") 15.56.12 Join dweeber [0] (~dweeber@c-73-52-129-219.hsd1.ut.comcast.net) 15.57.01 # speachy: it's just reporting what RB thinks your battery level is. 15.57.24 # speachy: i also noticed that, but i realized it's just reporting what RB is seeing 15.57.39 # the battery display didnt' match that nearly-dead report 15.58.05 # speachy: strange, but it's reading directly from the battery_percent or so 15.58.12 # I figure it's being affectecd by the hysteresis, but call it a datapoint 15.58.19 # hysterisi? 15.58.22 # hysterisis? 15.58.35 # never seen that word before 15.58.40 # isn't there a sort of weighted running average going on? (or am I misremembering) 15.59.06 # no idea, we can change how we send out the updates if need be 15.59.15 # i just thought the raw live updates was the best source initially 15.59.37 # also we need to try this out on windows and such at some point 15.59.38 # yeah, it's good to have the reports to the OS regardless. :) 15.59.58 # since I don't know if anyone other than the two of us has actually tried it... 16.00.02 # i wonder if it works with windows 16.00.17 # if it does it would be reported under the keyboard settings probably 16.00.27 # since that seems to be where periphereal battery reports go 16.00.50 # I can attach it to a win7 vm later today but I have no idea if it'll work... 16.00.51 # but yea, i had the same problem with fuze+ 16.01.04 # i'll setup a win10 vm soon 16.01.16 # attach my fuze+ to my server 16.01.35 # that reminds me, need to spin up an old XP instance too 16.01.55 # ah, win xp. i used a VM to repair an ancient mp3 player over usb. 16.02.01 # it was interesting. 16.02.14 # i made a copy of the files it installed so i could try to do it myself later 16.02.16 # via linux 16.03.04 # i somewhat wish we could archive the OF files for the sake of making it easier to repair these on RB website 16.03.07 # but 16.03.12 # copyrights and all 16.03.52 # though at this point is anyone going to care about some obsolete firmware for an mp3 player no one makes? 16.04.16 # especially if the company isn't around any longer. 16.04.30 # Philips is around but they no longer make mp3 players that I can tell. 16.04.49 # the early gogears were using their own chips or 16.04.52 # PP 16.04.59 # before they went to android 16.05.09 # I'm a little uncomfortable with the pre-patched hiby-based players sitting on the server, but.. the would-be complainers are all blatantly violating the GPL anyway, so they're not likely to complain. 16.06.20 # it's kinda weird how i see tons of the hdd1xxx series but almost none of the higher spec one 16.06.32 # i guess it reflects how well they sold 16.06.33 # Philips is out of that market entirely, though I'm pretty sure they're still licensing the brand to consumer electronics folks. 16.07.26 # which reminds me 16.07.32 # the gogear ports lack manuals 16.07.56 # what would it take to fix that? 16.08.42 # write the missing bits? :) 16.08.54 # a lot of it is general, isn't it? 16.09.02 # the main difference is usually controls 16.09.07 # bare minimum is the installation instructions and basic button diagram. 16.09.30 # look at rockbox/manual/getting_started 16.09.38 # ok, i'll look at it later 16.09.45 # i just thought some part of the manual were templated 16.09.51 # to reduce duplication 16.09.58 # yep, extensively. 16.10.19 # since the main difference between native ports is what keys do what 16.10.41 # screenshots and keymaps are scattered throughout the whole manual though. 16.11.00 # speachy: any word on that native RB device? 16.11.06 # pine and all 16.11.13 # if the player uses the same screen resolution as another model you can piggyback on the existing ones 16.11.18 # we may have to settle for using a TS for main controls 16.11.21 # no news. 16.11.26 # given their ubiquity today 16.11.32 # I haven't really followed up though 16.11.58 # we could probably handle that by using part of the screen to simulate a button pad 16.12.01 # or so 16.12.05 # haven't had the bandwidth to play with the pinecube and "cherrypi" boards behind me 16.12.30 # just seems like our best shot would be to use a rebadged smartphone 16.12.38 # perhaps part of it removed 16.20.50 Quit koniu (Remote host closed the connection) 16.21.20 Join koniu [0] (~koniu@gateway/tor-sasl/koniu) 16.32.12 Quit ender| (Quit: O(n²) is the sweet spot of badly scaling algorithms: fast enough to make it into production, but slow enough to make things fall down once it gets there. — Dawson’s first law of computing) 16.38.56 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 16.40.15 # <_bilgus> I think the x1000 is probably the most viable at this moment 16.40.51 # <_bilgus> and with that baremetal port it really starts to look promising 16.46.18 # _bilgus: x1000? 16.48.35 Join ender| [0] (~ender1@2a01:260:4094:1:6045:6fff:fedd:cbf3) 16.48.50 # <_bilgus> rocker mk3 16.49.05 # braewoods: ingenic x1000, the SoC in the agptek rocker, fiio m3, eros q/k etc.. 16.49.30 # (one of the most popular for DAPs, the next step up tends to be full android) 16.53.00 # <_bilgus> I'minterested to see the battery life 16.53.48 # <_bilgus> my gut tells me it'll be similar but hopefully its 10-20% better 16.54.43 # sounds like the PP of the current era 16.55.41 # so what's keeping us from making a native port? 16.55.48 # must we rebased on Linux? 16.57.09 Quit pamaury (Ping timeout: 265 seconds) 17.15.32 Quit lebellium (Quit: Leaving) 17.18.34 # <_bilgus> wo man hours? 17.19.22 *** Saving seen data "./dancer.seen" 17.36.14 # _bilgus: yeah, the same reason everything else isn't done... 18.43.45 Quit Huntereb (Ping timeout: 264 seconds) 18.53.04 # <_bilgus> chris_s logs? he been around ? 18.53.28 # <_bilgus> https://forums.rockbox.org/index.php/topic,53779.0.html 18.53.51 # <_bilgus> User says can no longer delete the dynamic playlist 18.54.07 # hmm, that is an unintented consequence. 18.54.22 Quit ac_laptop (Ping timeout: 276 seconds) 18.56.35 # seems like the "proper" solution is an explicit "delete dynamic playlist" context menu item 19.07.03 Join Huntereb [0] (~Huntereb@2603:9001:5a04:bbe7:6195:b89b:f6c1:6d57) 19.18.33 # speachy: if you can test windows 7 then great but i suspect it has no support 19.18.47 # i'll test windows 1 19.18.48 # 10 19.19.08 # the technical spec for what i implemented is 20 years old but doesn't appear it was used until fairly recently 19.19.23 *** Saving seen data "./dancer.seen" 19.21.58 # appears Linux received support for it back in 2011 19.22.23 # if we're lucky windows 8 might support it but unlikely 7 does 19.22.35 # i'll do a test install of window 10 first 19.23.03 # if it does work, it should show up as a wireless keyboard battery 19.23.14 # not 100% accurate but the least invasive method 19.23.20 # a more accurate method would be HID Power 19.23.33 # which i can still experiment with 19.23.41 # but this was far easier 19.25.22 # HID Power though is only more accurate on two fronts, assuming it works. 19.25.42 # it can accurately describe the relationship of the battery 19.25.46 # and the current status 19.25.51 # other than that not much to gain 19.26.20 # we're kinda misusing the API since we're not a wireless keyboard 19.26.28 # wireless periphereal 19.26.52 # but it doesn't require us to write a whole new driver either 19.27.18 # speachy: your thoughts? 19.27.41 # I can experiment with a separate driver to see how it differs in host implementation 19.27.44 # HID Power 19.27.44 # but we are, of a sorts. :D 19.29.13 # i'm thinking of writing a separate hid driver just to see how the host reacts to it 19.29.15 # compared to this 19.29.23 # a rough hack initially 19.29.46 # but first i want to see how windows 10 reacts to battery strength as is 19.30.26 # if they both work ok... 19.30.43 # maybe we can use HID Power if we can spare the endpoints but otherwise use battery strength 19.31.15 # what i've researched about standards only goes so far 19.31.17 # and all that 19.31.34 # what i care about is how the hosts react to it 19.31.39 # no point if they aren't going tou se it 19.32.16 # that's really funny 19.32.25 # you can't boot qemu anymore with the old chipset on windows 10 19.32.30 # you need to specify q35 19.32.40 Join S|h|a|w|n [0] (~shawn156@unaffiliated/shawn156) 20.00.57 # oh wow windows 10 has gotten worse to install 20.01.08 # they really want you to use a cloud account 20.01.10 # fat chance 20.15.09 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 20.17.54 # kinda ridiculious i have to resort to disable networking just to make a local account 20.20.42 # <_bilgus> no I think you just missed their well hidden local account option 20.54.14 Join dweeber_ [0] (~dweeber@c-73-52-129-219.hsd1.ut.comcast.net) 20.55.24 # _bilgus: lmao 20.56.22 Quit dweeber (Ping timeout: 260 seconds) 20.57.39 # <_bilgus> its there well as of 3 months ago or so 20.59.29 # _bilgus: so how does one access it then? 20.59.34 # it appears to force it 20.59.48 # i just tried with the iso from last october 21.03.12 # <_bilgus> it was just slightly off color from the background little hyperlink? 21.04.22 # <_bilgus> OH nm it appears we are both right you must be using Home 21.04.39 # <_bilgus> wow talk about a load of shit 21.05.00 # speachy: appears win10 doesn't support it for USB? 21.05.12 # there's no battery display, maybe it is bluetooth only 21.05.32 # option 2, HID Power 21.05.39 # i'll give that a try later 21.06.05 # though jsut to be sure it's not a fluke 21.06.09 # i'll try it on a linux guest too 21.07.15 # thank you live cds 21.08.26 Quit Saijin_Naib (Remote host closed the connection) 21.08.34 Join Saijin_Naib [0] (~Saijin_Na@2603-7081-1d05-7230-8de9-aefd-000f-730e.res6.spectrum.com) 21.09.24 # interestng 21.09.28 # not working quite right 21.09.57 # maybe it needs real hardware 21.10.52 # or... 21.10.54 # right 21.11.05 # it's not sent until an update occurs 21.11.07 # * braewoods facepalms 21.11.20 # i'll try again after letting the battery drain a bit 21.19.24 *** Saving seen data "./dancer.seen" 21.37.44 # ok. let's try this again with a custom build which always sends updates. 21.38.15 # maybe Linux and win10 have different behaviors before they've received their first update 21.38.33 # Linux defaults to 0% capacity until it knows otherwise 21.38.41 # win10 may display nothing until it has data 21.56.39 # ok so that's useless 22.04.55 Join chris_s [0] (5fdf48e9@ip-95-223-72-233.hsi16.unitymediagroup.de) 22.21.20 # Build Server message: New build round started. Revision 13178d23b8, 293 builds, 9 clients. 22.21.43 Quit ac_laptop (Ping timeout: 276 seconds) 22.24.08 # _bilgus: Re https://forums.rockbox.org/index.php/topic,53779.0.html . That's the second comment about this in a short while. I've pushed g#3198 to show the 'Play Next' option when playback is stopped. 22.24.08 # It actually uses PLAYLIST_INSERT (but creates a new playlist before) behind the scenes when playback is stopped, just like the Insert option used to do, so nothing about the former, expected behavior should have changed and there is very little new code to test. 22.24.09 # I was able to simplify the manual somewhat since this removes some special cases and imo 22.24.09 DBUG Enqueued KICK chris_s 22.24.09 # is more consistent in terms of naming. 22.24.10 # To make it less confusing, "Insert" and "Insert Shuffle" now aren't even offered as 22.24.10 # Gerrit review #3198 at https://gerrit.rockbox.org/r/c/rockbox/+/3198 : Show 'Play Next' option when playback is stopped by Christian Soffke 22.24.10 *** Alert Mode level 1 22.24.10 # options anymore if the playlist can't be resumed. All the user will see is "Play Next" 22.24.11 *** Alert Mode level 2 22.24.11 # The user would still have the additional step of manually reshuffling the playlist once 22.24.11 *** Alert Mode level 3 22.24.11 # they've selected "Play Next". Don't know if that's a big deal. 22.24.12 *** Alert Mode level 4 22.24.12 # I could imagine adding a "Play Next Shuffled" option, although there are arguably too many context menu optons as-is, so I'd prefer not adding another one. 22.27.30 # <_bilgus> TBH I'm not sure why the user needs to delete the dynamic playlist rather than just creating new you might wannat interact with hem to see why.. 22.27.40 # <_bilgus> them* 22.28.26 # <_bilgus> might just be a cse of RTFM or might be deeper reasons 22.29.44 Join f1reflyylmao [0] (~f1refly@dynamic-077-008-044-018.77.8.pool.telefonica.de) 22.30.43 Quit f1refly (Ping timeout: 260 seconds) 22.30.43 Nick f1reflyylmao is now known as f1refly (~f1refly@dynamic-077-008-044-018.77.8.pool.telefonica.de) 22.34.13 *** Alert Mode OFF 22.34.27 # Build Server message: Build round completed after 786 seconds. 22.34.30 # Build Server message: Revision 13178d23b8 result: All green 22.41.26 # I think I understand the need though. When you don't care about the (rest of the) dynamic playlist anymore, it's easy to just hit 'Play Next' on another item, (As I've said before, my suggestion would actually be to rename this to "Clear List & Play Next") without having to do any additional steps. 22.41.26 # The other user that posted feedback would choose to play an artist folder that way, which would add all of the albums from its subfolders. 22.41.27 # There isn't (I think) a good reason to only display this option when music is playing or paused, since the dynamic playlist still "exists" when playback is stopped. 22.41.27 # My former reservation with the Insert function deleting the current playlist (without waning) was based on the expectation that the function would work similarly across different playback states, which also makes it easier to document the behavior. 22.41.28 # As long as that is true for the Play Next function, I don't see an issue with displaying 22.41.28 *** Alert Mode level 1 22.41.28 # it, even when playback is stopped. 22.42.36 # <_bilgus> yeah deleting immediately without warnin would be not great 22.44.34 # <_bilgus> as long as no one else is using that lang ID sure feel free to rename it otherwise you'll have to create a new one 22.49.45 # The way I've implemented it now, I wouldn't have to add/rename anything in the language file. The behavior change is all in add_to_playlist which checks if playback is stopped and turns PLAYLIST_REPLACE into PLAYLIST_INSERT (but with a new playlist), if so. That seemed simpler to me than adjusting the function to add tracks to a playlist with 22.49.45 # PLAYLIST_REPLACE for the case when there is no current track (as it currently expects there to be one) 22.50.53 Join Soap [0] (~Soap@rockbox/staff/soap) 22.50.57 # The warning, btw, is unfortunately not something you can rely on currently, as it will never appear after rebooting (the modification state isn't saved) 22.51.30 *** Alert Mode OFF 22.52.42 # <_bilgus> not understanding that last sentence 22.53.42 Join yosafbridge` [0] (~yosafbrid@static.38.6.217.95.clients.your-server.de) 22.54.06 # <_bilgus> if I have a playlist inflight and try to wipe it out by inserting tracks then I should be warned 22.54.10 Join spectrum- [0] (~admin@198.46.152.45) 22.54.14 Join akaWolf1 [0] (~akaWolf@unaffiliated/akawolf) 22.54.19 # <_bilgus> or have you removed this path? 22.54.53 # <_bilgus> *Dynamic PL* 22.54.54 # warn_on_pl_erase() checks if playlist_modified() which is the case if playlist->shuffle_modified, playlist->deleted or playlist->num_inserted_tracks. None of these are true after a restart (nothing to do with any of my changes) 22.55.02 Quit ps-auxw (Disconnected by services) 22.55.10 Join ps-auxw [0] (~arneb@p548d56ce.dip0.t-ipconnect.de) 22.55.35 Join asabas [0] (~asaba@103.113.159.184) 22.55.41 Join vup2 [0] (~~~~@46.101.193.235) 22.55.55 # <_bilgus> ah ok I understand what you are saying 22.57.30 Join SovietShaman__ [0] (quassel@024-217-039-226.res.spectrum.com) 22.59.25 Quit asaba (*.net *.split) 22.59.25 Quit Soap_ (*.net *.split) 22.59.25 Quit spectrumanalyst (*.net *.split) 22.59.25 Quit toruvinn (*.net *.split) 22.59.25 Quit klock (*.net *.split) 22.59.26 Quit Xeha (*.net *.split) 22.59.27 Quit akaWolf (*.net *.split) 22.59.27 Quit olspookishmagus (*.net *.split) 22.59.27 Quit kirvesAxe (*.net *.split) 22.59.27 Quit vup (*.net *.split) 22.59.28 Quit yosafbridge (*.net *.split) 22.59.28 Quit CommunistWitchDr (*.net *.split) 23.01.35 Join olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr) 23.01.45 Join toruvinn [0] (~toruvinn@77-255-90-179.adsl.inetia.pl) 23.01.58 Nick olspookishmagus is now known as Guest48842 (~pookie@snf-137798.vm.okeanos.grnet.gr) 23.02.15 Join Xeha [0] (~Xeha@unaffiliated/xeha) 23.02.23 Join klock [0] (~freeklock@unaffiliated/klock) 23.04.38 # "as long as no one else is using that lang ID sure feel free to rename it otherwise you'll have to create a new one" -> I think I missed that were probably referring to renaming  "Play Next" to "Clear List & Play Next" there? Would love to do that, except I'm not sure if that would inconvenience users of other languages. Are translations updated 23.04.38 # asynchronously or are you supposed to wait until you have all of the necessary language files ready? 23.10.30 Join kirvesAxe [0] (kirvesaxe@aulis.sange.fi) 23.10.32 # <_bilgus> thats a good point but no typically we just do the changes to the english.lang and everyhting else updates off it 23.10.33 # <_bilgus> if you know other langs feel free to update them as well 23.11.07 # thanks 23.13.07 # <_bilgus> no other users of LANG_REPLACE AFAICT 23.19.26 *** Saving seen data "./dancer.seen" 23.36.45 Join p0x [0] (2d24b186@cpe-45-36-177-134.triad.res.rr.com) 23.42.12 # hello 23.49.56 # Hi? bilgus: (y)  Looks like the translations already aren't necessarily literal anyway. For 'Play Next' it says 'Replace current one' in German and the French translation includes 'Replace' in parentheses. 23.59.00 # <_bilgus> If they already have translations like that then it'd be best to mark them depreciated