--- Log for 06.01.117 Server: nylund.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 1 day and 3 hours ago 00.00.09 # chrisjj: I did not mean direct push, I was talking about etiquette to not put two not directly connected changes into one patch 00.00.16 # jhMikeS: Yup, I can see the problem. And at the root of it is that testing is meaningless when there's no spec. against which to test compliance. A case in point being relative references in playlists. There's no mention of this feature in the manual AFAICS and no standard outside Rockbox except the behaviours of specific apps e.g. WinAmp in the case of M3U. 00.00.34 Quit parchd (Ping timeout: 245 seconds) 00.00.58 # Saratoga: I think the difference is that if the playlist is on an external card, it messed with the path whether it was absolute or not. Now, it only prepends a directory on relative paths and absolute are simply left alone 00.00.59 # which was agreed on amongst committers 00.02.58 # <[Saint]> chrisjj: you can go to your kitchen right now, and take out a big kitchen knife, and stab yourself in the face. That is 'permitted' by the knife. It doesn't make it a non-shit idea though. 00.03.21 # pixelma: which changes weren't directly connected? crossfade needed a good scrubdown and the fixes weren't that simple. 00.03.23 # <[Saint]> I'm really starting to think you're just arguing for the sake of it and it is getting very tedious. 00.03.46 # changing the fader granularity was pretty incidental 00.04.10 # <[Saint]> it would've been nice if the new fader was kept as a separate commit to the fixes for track length. 00.04.13 # <[Saint]> I believe that's the view. 00.04.16 # <[Saint]> One I share. 00.04.49 # <[Saint]> If for no other reason than it being easier to manage if either ever needed to be reverted. 00.05.15 # pixelma: Thanks for the clarification. Did I miss the open statement of this ettiquette? 'Cos if there's none, it's hardly surprising that different people have different ideas of what it is. 00.06.27 # [Saint]: the old one would have made fixing the stuff harder and harder to verify correctness since it was all over the place 00.07.01 # jhMikeS: what [Saint] said 00.07.03 Join saratoga_ [0] (40864c01@gateway/web/freenode/ip.64.134.76.1) 00.07.22 # chrisjj: just stop annoying everyone or you'll eventually be kicked 00.07.38 # chrisjj: yes, since you're not a committer 00.08.16 # pixelma: he may have said it, but the fader would have been changed anyway 00.08.39 # <[Saint]> waaaaaaaaaaaaay back when, we discussed - and I thought had in place - the idea of a minimum period for cooling off commits. 00.08.57 # <[Saint]> And everything except fixes for breaking changes was supposed to go through gerrit. 00.09.05 # <[Saint]> this never happened, obviously. 00.09.17 # there's no way I was going to mess with the issues at hand without revising it to a way I can make better sense out of it 00.09.30 # <[Saint]> the intention of the cooldown period was to give everyone at least ~48h for review or objection. 00.09.51 # yeah but for playback no one is going to have an opinion 00.10.06 # i usually just ask whoever else is working on a thing before i commit, and if i'm the only one, i just do it 00.10.15 # then fix if theres a problem 00.10.44 # <[Saint]> the fs rework sat on gerrit for a while in a completely different state. 00.11.02 # <[Saint]> and then suddenly was committed out of the blue with an additional 10k changes. 00.11.09 # so, yes, I did troll a bit by mentioning an incedental change to something that would have been radically revised anyway in order to make the problems tractable 00.11.12 # <[Saint]> I sure as shit had an opinion on it... 00.11.26 # <[Saint]> I wanted to see testbuilds go out, ideally. 00.11.32 # <[Saint]> but it just kinda happened. 00.11.33 # [Saint]: I had that one up for months 00.11.53 # <[Saint]> jhMikeS: I'm fairly positive not the final committed iteration you didn't. 00.12.07 # [Saint]: And you're not going to revise that with petty 100 line patches. Get daring or go home! 00.12.38 # the fs rework was up forever 00.12.44 # i was the only one testing it 00.13.02 # [Saint]: I don't think it was radically different. I think I removed some call recusion and switched it to iteration with stacks. 00.14.38 # saratoga_: you and I were. I built for every hardware device I had and every sim and tool. Not like it was "works good on clip", guess I should push it! Heh. 00.16.29 # yeah i mean aside from you 00.23.16 # <[Saint]> you weren't the only one testing it. 00.24.46 Quit cc___ (Ping timeout: 255 seconds) 00.25.28 Join naleo [0] (~naleo@unaffiliated/naleo) 00.28.08 Quit ZincAlloy (Quit: Leaving.) 00.30.04 Quit Acou_Bass (Quit: ZNC - http://znc.in) 00.36.23 # saratoga_: it seems weird to force files in a playlist to be search on external storage if the paths in it are absolute (what the old code did) 00.36.37 *** Saving seen data "./dancer.seen" 00.37.18 # i don't see a problem if the absolute paths don't mean anything 00.38.16 # <[Saint]> it might seem weird when you think about it too hard, but it becomes apparent in end user discussion that this is the behavior people expect. 00.38.26 Quit ender` (Quit: drug, n: A substance that, injected into a rat, produces a scientific paper) 00.38.56 # <[Saint]> this is more noticeable whenever you happen to catch someone who has just recently come from the 3.13 release for whatever reason. 00.40.03 # the problem is the way we mount the external storage as a folder within the main storage, while most users expect each volume to be fully independent because windows does that 00.40.31 # so it takes forever to explain why C:\music.mp3 isn't a valid sd card path in rockbox 00.40.54 # saratoga_: is that the only purpose of it? 00.40.55 # well that and that MSC doesn't give you any coherent way to handle multivolume paths 00.40.59 Quit rela_ (Ping timeout: 245 seconds) 00.41.08 # and mtp appears to be useless 00.41.31 # saratoga_: thing is, it would have messed with native paths too like "/Music/file.mp3" 00.43.02 # I can see the sense in stripping a drive as meaningless 00.43.20 # but it wasn't quite doing that 00.43.40 # didn't it ignore any absolute paths? 00.43.51 Join Acou_Bass [0] (~Acou_Bass@host-78-148-16-72.as13285.net) 00.44.48 # no, it would have added the //dir even if it were absolute because the playlist was not on volume 0 00.45.13 # its possible that wasn't intended, i can't remember 00.45.30 # i thought anything beginning with '/' was left alone 00.45.46 # now it ignores absolute paths and won't alter them 00.46.16 # not what I'm seeing here in the diff of format_track_path 00.48.32 # the difference now absolute paths are left alone but it still has the logic of not stripping the separators after the drive spec 00.50.57 # another difference is that if the m3u path had a volume, only the matching volume was added to the path, not the whole directory 00.53.26 # I guess that implies: m3u in /<1>/Playlists, mp3 path as /Music/A/B/file.mp3, the path would have become "/<1>/Music/A/B/file.mp3" 00.57.18 Quit saratoga_ (Ping timeout: 260 seconds) 01.02.49 # It sounds like "c:/Music/A/B/file.mp3", "c:Music/A/B/file.mp3" or "Music/A/B/file.mp3" should become "/<1>/Music/A/B/file.mp3", while "/Music/A/B/file.mp3" or "/<1>/Music/A/B/file.mp3" should be left alone. "<1>/Music/A/B/file.mp3" doesn't have a valid volume and is relative. 01.05.28 Quit Saratoga (Ping timeout: 260 seconds) 01.12.41 Quit girafe (Read error: Connection reset by peer) 01.20.20 Quit skapazzo (Quit: leaving) 01.44.27 Join mutnai [0] (6db91733@gateway/web/freenode/ip.109.185.23.51) 01.50.54 Quit Acou_Bass (Remote host closed the connection) 01.53.54 Join Acou_Bass [0] (~Acou_Bass@host-78-148-16-72.as13285.net) 02.09.27 # jhMikeS: "the difference now absolute paths are left alone" Please define 'absolute paths'. Esp. since generally "\folder\file.mp3" is considered a relative path - relative to the current drive. 02.10.13 Quit mutnai (Ping timeout: 260 seconds) 02.13.50 Quit diox (*.net *.split) 02.13.50 Quit StaticAmbience (*.net *.split) 02.13.50 Quit idonob (*.net *.split) 02.13.50 Quit igitoor (*.net *.split) 02.13.50 Quit x56 (*.net *.split) 02.13.50 Quit Topy44 (*.net *.split) 02.13.50 Quit derf (*.net *.split) 02.13.50 Quit fIorz (*.net *.split) 02.13.51 Quit zu (*.net *.split) 02.13.51 Quit fulon (*.net *.split) 02.13.51 Quit APLU (*.net *.split) 02.13.51 Quit snow_bckspc (*.net *.split) 02.13.51 Quit maraz_ (*.net *.split) 02.13.52 Quit dongs (*.net *.split) 02.13.52 Quit vflyson (*.net *.split) 02.13.56 Join dongs_ [0] (~dongs@bcas.tv) 02.13.56 Nick dongs_ is now known as dongs (~dongs@bcas.tv) 02.13.57 Quit __builtin (*.net *.split) 02.13.58 Quit thum (*.net *.split) 02.13.58 Quit tomflint (*.net *.split) 02.13.58 Quit alexbobp (*.net *.split) 02.13.58 Quit evilnick_ (*.net *.split) 02.13.58 Quit tchan (*.net *.split) 02.13.58 Quit olspookishmagus (*.net *.split) 02.13.58 Quit bzed (*.net *.split) 02.13.59 Quit knittl (*.net *.split) 02.13.59 Quit funman (*.net *.split) 02.14.01 Join maraz [0] (maraz@kapsi.fi) 02.14.04 Join Topy [0] (topy@ns3.kurz.pw) 02.14.04 Join funman_ [0] (~fun@chui-pas.net) 02.14.06 Join idonob [0] (~Owner@S010610c37b922980.vs.shawcable.net) 02.14.06 Join zu [0] (~zu@ks387228.kimsufi.com) 02.14.07 Join evilnick__ [0] (~evilnick@d54C3417E.access.telenet.be) 02.14.07 Join StaticAmbience [0] (~Quassel@host217-42-102-24.range217-42.btcentralplus.com) 02.14.09 Join alexbobp [0] (~alex@testificate.xen.prgmr.com) 02.14.09 Join knittl [0] (~knittl@fucktheforce.de) 02.14.13 Join olspookishmagus [0] (~pookie@snf-137798.vm.okeanos.grnet.gr) 02.14.15 Join derf [0] (~derf@static-108-18-126-14.washdc.fios.verizon.net) 02.14.15 Join bzed [0] (~bzed@shell.bzed.at) 02.14.35 Quit knittl (Changing host) 02.14.35 Join knittl [0] (~knittl@unaffiliated/knittl) 02.14.44 Join tchan [0] (~tchan@c-50-129-174-2.hsd1.il.comcast.net) 02.14.48 Join igitoor [0] (igitur@2a00:d880:3:1::c1ca:a648) 02.14.56 Join fulon [0] (~vshyba@178.62.192.54) 02.15.13 Join x56 [0] (0x56@2600:3c03::f03c:91ff:fe33:d587) 02.15.39 Nick alexbobp is now known as Guest11195 (~alex@testificate.xen.prgmr.com) 02.15.43 Join snow_bckspc [0] (~snow_bcks@ganon.dot-server.net) 02.16.02 Nick olspookishmagus is now known as Guest51131 (~pookie@snf-137798.vm.okeanos.grnet.gr) 02.16.04 Quit tchan (Changing host) 02.16.04 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 02.16.13 Nick x56 is now known as Guest69833 (0x56@2600:3c03::f03c:91ff:fe33:d587) 02.16.24 Quit igitoor (Changing host) 02.16.24 Join igitoor [0] (igitur@unaffiliated/contempt) 02.16.37 Join __builtin [0] (~xray@rockbox/developer/builtin) 02.17.00 Join tomflint [0] (~tomflint@unaffiliated/tomflint) 02.19.02 Join APLU [0] (~mulx@eva.aplu.fr) 02.19.48 # <[Saint]> quote like that one more time, I dare 'ya. 02.21.06 Nick Ruhan is now known as Ruhanada (uid76353@gateway/web/irccloud.com/x-cqvhuxodwqlqhmzi) 02.21.07 # jhMikeS: re " 'c:/Music/A/B/file.mp3'... should become", this is just a fix-up for inappropriate absolute references, and not needed for references created properly as relative by RB itself and well-behaved apps. 02.21.28 Mode "#rockbox +o __builtin" by ChanServ (ChanServ@services.) 02.21.44 # So perhaps it should be relegated to a config option. 02.26.20 Mode "#rockbox +o __builtin" by __builtin (~xray@rockbox/developer/builtin) 02.28.45 # The cross-volume playlist requirement I think is not generally solvable. Because RB's \ is rather a kluge. ISTM RB makes it a requirement for unambiguous references, but doesn't expose it to the PC. A solution is for RB config to allow e.g. H:\ as an alias. 02.31.35 # no it's not generally solveable and you can't readily tell a RB relative path from one from linux or windows unless it has the funny notation in it 02.31.44 Mode "#rockbox -o __builtin" by __builtin (~xray@rockbox/developer/builtin) 02.32.33 # jhMikeS: "Now, it only prepends a directory on relative paths and absolute are simply left alone" is exactly the way it should work IMO. But since this change breaks compatibility with usage relying on the previous behaviour, I can see why there are complaints about the change. 02.33.17 # I'm under the impression that it's not only reliance on the behavior, it's got a mandate 02.33.47 Mode "#rockbox +o __builtin" by ChanServ (ChanServ@services.) 02.33.55 # <[Saint]> wanna do the honors? ;) 02.34.19 # I'm under the impression some people would like to think it has got a mandate. But any such mandate is imaginary, esp. while its a secret kept from the manual. :) 02.35.01 Kick (#rockbox chrisjj :Kindergarten is elsewhere!) by __builtin!~xray@rockbox/developer/builtin 02.35.04 # but, stripping a drive letter to a relative path seems a sound and predicatable thing to do and effectively just replaces a windows volume with the rb volume 02.35.31 Mode "#rockbox -o __builtin" by __builtin (~xray@rockbox/developer/builtin) 02.35.58 # <[Saint]> nothing really changes the fact that if we ever do get around to a formal release that this would be a regression of expected behavior. 02.36.19 # <[Saint]> there's still a large body of people using releases and you can't really just say fuck them because the use case seems weird comradekingu 02.36.25 Join chrisjj [0] (5001d87b@gateway/web/freenode/ip.80.1.216.123) 02.36.34 # __builtin: Care to say why you just kicked me? 02.36.38 *** Saving seen data "./dancer.seen" 02.36.45 # jhMikeS: Why would anyone want to distinguish relative refs of RB from those of Linux/Windows? 02.36.52 # <__builtin> chrisjj: you were warned multiple times to stop the offending behavior 02.37.21 # <[Saint]> that quoting style of yours is giving us all eye cancer. 02.37.22 # What are you claiming has caused offence? 02.38.24 # <[Saint]> when you're talking to people with a matter of minutes in between you really don't need to feed them back everything they just said to you. 02.40.19 # <[Saint]> it would probably be easier to stomach if it didn't seem like you have an oppositional stance to literally anything anyone says. 02.43.29 Quit Senji (Ping timeout: 245 seconds) 02.44.23 # <[Saint]> comradekingu: sorry for the errant highlight 02.44.30 # chrisjj: because perhaps you want real relative paths in the playlist that are playlist relative when they're native? Treating paths as volume-relative makes sense so long as it's consistent. I mean, there's no wrong prefix on a relative path; it's literally unspecified. 02.44.50 # A lot of software treats relative paths as playlist-relative though 02.46.54 # and in noticing that pattern, perhaps it is I that was simply accustomed 02.49.19 # jhMikeS: Yes of course we want paths relative to playlist but what's that got to do with RB V Linux/Windows? Such paths start without drive letter or separator. 02.54.47 # sure, then if we parse paths that have a drive letter as the only ones qualifying for volume replacement, then it's not the behavior that existed 02.56.05 # Agreed, but still I'd like to understand what is this RB v Linux/Windows difference of which you speak. 02.57.38 # there's no indication of the source OS from a relative path alone, so if some kind of different behavior were desired depending on who created it, well, no way to do that 02.58.34 # so, since it's objectively unsolveable, the remaining unknown is "what do does the user want?" 02.59.27 # I agree there's no indication of the source OS from a relative path alone, but why would anyone desire some kind of different behavior for references from RB v Linux/Windows? 03.13.48 # No idea really. It's just my "job" to consider weird expectations I wouldn't normally care about. 03.18.17 # <[Saint]> with things like this I think the most valuable consideration is: 03.18.17 # <[Saint]> 'even if it's weird, it was like that for the better part of a decade and even if the 'broken' behavior might arguably make more sense it can be seen as a regression' 03.18.24 # If I base it off what I gleaned from intent of the code: If windows, strip drive and replace with playlist's volume; if absolute, leave it be; if relative, make it relative to the playlist file's location. Maybe I'll try that, even though it's different from before, and see how it goes. 03.19.22 # What can be seen as a regression? The fix to the broken behaviour? 03.20.59 # <[Saint]> breaking the existing behavior. 03.21.08 # <[Saint]> what of this is difficult to understand? 03.23.51 # true relative paths were playlist-relative before as they are now 03.24.13 # No problem there. 03.24.29 # That's as they should be. 03.25.00 # But your 'if windows, strip drive and replace with playlist's volume' is going to break that. 03.25.42 # however, absolute paths in the root could still be altered rather than left be 03.26.54 # Any drive-lettered absolute path needs to be converted for RB. 03.28.27 # that's the one that's not happening now 03.28.30 # What's needed instead of your replace is 'Replace drive letter and colon and any slash with slash, RB volume ID and slash'. 03.29.52 # The problem is that currently no drive letter -> RB volume mapping is available. Hence my suggestion for a config setting. 03.30.49 # what's happening now is: "c:\foo" -> "/foo" -> "/foo", "c:foo" -> "foo" -> "/my_playlist_dir/foo" 03.31.09 # no drive letter = relative path 03.32.56 # I know no app that generates "c:foo". 03.34.03 # "c:\foo" -> "/foo" is the one that needs to be fixed for cross-volume playlists to work. 03.35.13 # <[Saint]> *:foo is entirely valid. 03.35.19 # <[Saint]> deprecated, but, valid. 03.35.47 # Clarification: host-generated cross-volume playlists. 03.37.10 # RB-generated cross-volume playlists work. 03.37.42 # <[Saint]> well, as far as rb is concerned - it isn't cross-volume. 03.37.42 # <[Saint]> as discussed earlier. 03.38.13 # <[Saint]> is a directory under /, not a separate volume. 03.40.10 Nick Bray90820_ is now known as bray (~bray90820@173-25-204-30.client.mchsi.com) 03.40.36 # jhMikeS: And "c:foo" -> "foo" is faulty with respect to Windows. See https://msdn.microsoft.com/en-gb/library/windows/desktop/aa365247(v=vs.85).aspx 03.42.07 # Correct is "c:foo" -> "c:/my_playlist_dir/foo" 03.42.50 # (Regardless of the drive of /my_playlist_dir/.) 03.43.24 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 03.49.12 # it seems to treat it like it's not even there 03.50.39 # ah, guess it means "current directory on drive C". 03.51.39 # I guess "c:foo" should be treated as relative to approximate windows handling 03.56.19 # That would indeed raise c:foo handling to the Windows-approximate level of c:\foo, but I can't see it being worth the effort, since as I said I know no app that generates such a form, and I can't see why any app would. 04.01.04 # jhMikeS: Wanna talk Crossfade? :-) Here's another anomaly for you: http://i.imgur.com/PeILat4.png The burst at 2.7 is the Track Skip Beep. 04.04.46 # problem? 04.04.57 # delays aren't observed on manual skips 04.07.52 # you might have some of what's left of fade-in delay once you've removed the fade out delay. if fade-out delay is longer than fade-in delay, they should both become 0 on man. skip 04.08.00 # Yup, that's the problem. :-) 04.08.25 # it's by design and little like to be changed 04.08.55 # Some design not documented in the manual :-) 04.09.35 # Would you have an objection to the program operating as it is supposed to according to the manual? 04.10.07 # <__builtin> The manual doesn't dictate what rockbox does. The source does. 04.10.29 # <__builtin> If there's a contradiction the source code takes precedence. 04.11.32 # <__builtin> So in this case it's not rockbox that needs correction, but the manual 04.11.55 # Yup, the source dictates all the bugs too :-) 04.13.02 # I note the the crossfade short track skip didn't get 'fixed' by adjusting the manual to match the source:-) 04.13.22 Quit bluebrother (Disconnected by services) 04.13.27 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 04.13.36 # <__builtin> That was a clearly a bug, this is not. 04.13.51 # <[Saint]> jhMikeS: you should probably add 'by default'. 04.13.56 # Why is this clearly not a bug? 04.14.14 # <[Saint]> crossfade can be active never, on manual skip, or on automatic skip, or both. 04.16.06 # <[Saint]> chrisjj: you seem to think that 'everything rockbox does that the manual doesn't say it does' is a bug. 04.16.33 Join Strife1989 [0] (~quassel@adsl-98-67-58-2.mcn.bellsouth.net) 04.16.36 Quit fs-bluebot (Ping timeout: 248 seconds) 04.17.19 # <[Saint]> the manual is not the be all and end all of functionality and absolutes. 04.18.13 # <[Saint]> I mean, shit, by your metric - damn near everything in the release build is a bug since the manual tracks mainline and not the release. 04.18.13 # <[Saint]> people shouldn't have to point out what that's retarded. 04.19.20 # <[Saint]> *why that 04.19.39 Quit Strife89 (Ping timeout: 258 seconds) 04.23.58 # Saint, you are looking at the wrong manual for release. The right one is e.g. here http://download.rockbox.org/release/3.13/rockbox-sansafuze-3.13.pdf 04.25.14 # <[Saint]> I am aware of that. 04.25.43 # The fact RButil links to the wrong manual is a known bug: "Rockbox Utility manual version and installed program version can fail to accord" https://www.rockbox.org/tracker/task/12947 04.26.26 # <[Saint]> it was part of a reductio ad absurdum so hopefully you'd figure out that there was absolutely zero correlation between what the manual says and what expected functionality is. 04.26.55 # <[Saint]> but I guess that failed too... 04.27.34 # <[Saint]> source dictates the manual, not vice versa. 04.28.12 # <[Saint]> and if the manual's wrong about something, fix it to match, not the reverse. 04.30.03 # I've figured out that there is absolutely zero correlation between what the manual says and what some people's expected functionality is. Meanwhile there's a lot of correlation between what the manual says and what those who read the manual (rather than the source) expected the functionality to be. 04.30.04 # Meanwhile there's a lot of correlation between what the manual says and what those who read the manual (rather than the source) expected the functionality to be. 04.30.15 # Those are people we cal "users". 04.31.10 Join fs-bluebot [0] (~fs-bluebo@xd9beffbc.dyn.telefonica.de) 04.36.40 *** Saving seen data "./dancer.seen" 04.36.58 # <[Saint]> Good thing Rockbox is for developers and not users then, huh? 04.37.05 # <[Saint]> Users can go fuck themselves. 04.37.57 # <[Saint]> This has always been the case. It has never been a 'product', it has always been 'by developers, for developers'. 04.37.58 # <[Saint]> This isn't new, or spooky, or changed in any way. 04.39.47 # <[Saint]> I also have very sincere doubts as to your deep seated knowledge of what the entirety of the userbase expects or doesn't expect. 04.40.49 # Saint, you must be talking about a different Rockbox. I'm talking about this one: "Rockbox is written by users, for users." https://archive.is/JkYRT 04.41.07 # jhMikeS: Would you have an objection to Crossfade operating as it is supposed to according to the manual? 04.44.32 # <[Saint]> the wording of that could be better, I agree - but if you're writing it, you're not a user, you're a developer. 04.44.45 # <[Saint]> joe user doesn't really get a say. 04.45.40 # I can't imagine a better wording than "Rockbox is written by users, for users." 04.46.17 # <[Saint]> I guess that depends on whether or not you want it to be accurate. 04.47.31 # <[Saint]> This is one of the reasons why there's no longer a 'feature requests' forum entry, and it got turned into feature ideas. 04.47.57 # Feel free to correct that line in the manual. Or try to... 04.48.05 # <[Saint]> users don't get to request shit. 04.48.33 # <[Saint]> Why do you say 'or try to'? that sounds like a threat. 04.49.07 # <[Saint]> I'm not a fan of threats. especially not from people who've been trying their best to be contrarian and argumentative for the past ~12h straight 04.49.24 # <[Saint]> I have a habit of removing those people from the platform. 04.49.34 Join fIorz [0] (nobody@rain.florz.de) 04.50.27 # <[Saint]> And if /that/ sounds like a threat...good. It is. 04.51.54 # pauamry: re ZEN dual boot and your request for post of the forum to gather user input, I first polled some ZEN users (not (yet) Rockboxers) and came up with this solution that I think would please all. 04.52.15 # pamaury: re ZEN dual boot and your request for post of the forum to gather user input, I first polled some ZEN users (not (yet) Rockboxers) and came up with this solution that I think would please all. 04.52.26 # Upon power-on with Left key down, the original firmware launches. Upon power-on without Left key down, if .rockbox is on external memory, that launches, else if .rockbox is on internal memory, that launches, else execution reports error and halts. When Rockbox launches, if the other memory is FAT, the other memory is mounted. 04.53.38 # What are your thoughts on the utility and implementability? 04.59.03 # <[Saint]> I'm pretty confident that request was in the context of those experiencing a very specific hardware bug. 05.00.51 # <[Saint]> as far as I'm aware the bootloader doesn't even have dualboot enabled and dualboot isn't even really possible and might not ever readily be. 05.00.51 # A nice-to-have refinement is instead of "[if no rockbox found] execution reports error and halts." do "original firmware launches". This would let the dual user switch to RB by inserting the RBed card, and back to OF by removing the card. 05.01.13 # <[Saint]> Aha, I was right: 05.01.16 # <[Saint]> "NOTE: for size reasons, the bootloader is singleboot (ie you can't boot the OF), this should not be a problem since you can't really dualboot unless you reformat anyway. " 05.01.54 # <[Saint]> So I'm gonna go out on a limb and suggest that the request for feedback was indeed very specific to LCD. 05.08.07 # __builtin: Adding the behavior of every dark corner of the code to the manual could get very tedious and probably would distract from actually conveying a message. 05.11.42 # Oh, and fade-in delay is eliminated, not fade-out. starting at pcmbuf.c: 1133 for the details 05.12.51 # <[Saint]> Man, I really should not have read chrisjj's forum posts. 05.13.01 # <[Saint]> So. Much. Angst. 05.13.14 # <[Saint]> Y'know man, instead of crying about the manual you could make submissions against it. 05.13.15 # It sure would detract from conveying the message that RB is as dark-corner-free as the manual suggests. And that's a good thing for progress in eliminating such corners. 05.13.32 # <[Saint]> So fucking do it. 05.13.42 # <[Saint]> Or don't. Or shut up. 05.13.46 # <[Saint]> ...just pick one. 05.13.58 # shine a light for us all! 05.15.32 # <[Saint]> "For the current release build, many of the target versions listed as "having a complete manual" have no manual at all." 05.15.44 # <[Saint]> ...what in the everloving fuck? 05.17.47 # is that real? how can our devices be real if our manuals aren't real? 05.17.59 # <[Saint]> Generally speaking there's a lot I'm willing to take, but outright lies are very difficult to stomach. 05.18.00 # jhMikeS: Is this auto-reduction of the delay your design? If so, I'd be interested in hearing the reason for you removing the user's choice. 05.19.02 # <[Saint]> jhMikeS: unfortunately it is real. I honestly can't tell if it is outright trolling, some form of mental deficiency, a deliberate lie, something else, or some combination of all of the above. 05.19.02 # This is the bit that removes his choice: http://i.imgur.com/Vu7byzb.png 05.19.43 # <[Saint]> Unless chrisjj thinks that every unique variant of a device should have its own manual even though they don't even have their own unique build. 05.19.44 # Without that but, the user could choose to keep the gap, or himself reduce the delay to eliminate (or reduce) the gap. 05.20.01 # chrisjj: 1) should absolutely everything under the sun be a setting? I think we have too many; I dislike them in general. 2) It wasn't my design 3) it makes sense not to have to wait many seconds for the track you deliberately skipped to to start to play. 05.20.32 # It makes sense to wait for the number of second you asked for. 05.20.46 # If you don't want to wait that long, then don't ask for that length of delay. 05.22.30 # PS It isn't the track that you skipped that you're waiting for. It is the gap that you programmed after it, to give a separated start to next track. 05.23.08 # Those delays really represent a relationship between where the two fades start and the delays actually don't mean dick. The fade out ends at the end of the track. What would make sense is one setting that just sets a negative or positive offset for the fade in compared to the fade out and nothing would sound different. 05.23.52 # jhMikeS: I have a patch on gerrit affecting the fade delay is what you are doing affecting what I just did? 05.24.13 # Bilgus: no idea 05.24.15 # <[Saint]> Bilgus: bigtime 05.24.22 # what'd he do? 05.24.28 # Bilgus: what'd you do? 05.24.40 # #g1451 05.24.41 # 3Gerrit review #1451 at http://gerrit.rockbox.org/r/1451 : 3Fade on Play/Pause with 1-30 second delay (NO ARCHOS PLAYERS) by William Wilgus 05.24.50 # <[Saint]> jhMikeS: just checking, you are aware that there's a crossfade variation for 'manual track skip', right? 05.25.01 # <[Saint]> or was your wording really fucky? 05.25.14 # <[Saint]> it's got nothing, per se, to do with the end of the track - or...it didn't. 05.25.19 # Bilgus: I'm not so hot about that patch. 05.25.26 # <[Saint]> If it does now, I'm probably gonna have some issues with that. 05.25.37 # jhMikeS, that ratehr assumes what the design was. Given it wasn't your design, I think your assumption the program is working as designed, as opposed to just working as coded, is rather brave! :) 05.25.43 # <[Saint]> and, yeah - neither am I to be fair. 05.25.46 # [Saint]: yeah, I know the settings and what they do. 05.26.00 # <[Saint]> jhMikeS: then how can you say it has no relation? 05.26.10 # do tell.. 05.26.32 # <[Saint]> Bilgus: was that directed at me? 05.26.50 # chrisjj: It was explicitly coded and commented. It's inclusion was no accident. 05.26.52 # <[Saint]> If so I was under the impression I made myself clear at the time but I could restate it. 05.26.55 # both of you I suppose 05.27.22 # <[Saint]> In short, I see it as needlessly granular and I really dislike the ui for it. 05.27.57 # <[Saint]> I would've added a time picker for 0~N seconds for the entire setting, not split it up, and called it a day. 05.27.58 # The behaviour described in the manual here looks fine to me https://archive.is/9isgQ#selection-547.0-613.70 and I think it unsafe to assume that not as per design. The only problem is that the code does not accord. 05.29.06 # That surely isn't difficult, working on a time picker currently similar to the date/time picker and you jhMikeS ? 05.29.08 # chrisjj: does the code Jeep, because I don't have an accord 05.29.58 # <[Saint]> jhMikeS: to be clear, do you have any intention of bringing the manual back up to parity? 05.30.12 # <[Saint]> Because one of them has to move, and presently it seems like the revert is the easiest. 05.30.23 # revert of which? 05.30.42 # <[Saint]> fucking with crossfade. 05.30.45 # jhMikeS: Can you help me out with the location of that comment? 05.31.30 Nick Ruhanada is now known as Ruhan (uid76353@gateway/web/irccloud.com/x-cqvhuxodwqlqhmzi) 05.31.34 # [Saint]: I didn't change the crossfade general behavior at all, just the degenerate stuff that used to just break 05.32.05 # <[Saint]> jhMikeS: well, to be fair, I was taking chrisjj at face value on this and for the life of me I have no idea why. 05.32.15 # <[Saint]> It just occurred to me how fucking stupid that is given context. 05.32.16 # chrisjj: which comment? the "note:" is wrong. fade in isn't shortened in any way to eliminate a gap 05.33.11 # <[Saint]> it was also kinda based on your wording but now I'm just willing to believe that was ambiguous. 05.33.14 # The comment you referred to at [04:26] chrisjj: It was explicitly coded and commented. 05.33.19 # chrisjj: if that disappeared at one time, who the hell knows when. maybe it disappeared deliberately and never got updated 05.34.15 # chrisjj: in pcmbuf.c, indeed. sometimes manual follows the code, sometimes it's just behavior that has to cover real cases. 05.34.35 # Thanks. Looking... 05.35.14 # <[Saint]> jhMikeS: I think he's referring to the prior behavior, not the current? 05.35.26 # [Saint]: just about eliminated the fade-in delay. I'd hate to wait 8 seconds or something after just clicking over to a new track 05.36.01 # Meanwhile re your 'fade-in isn't shortened in any way', see this counter-evidence: http://i.imgur.com/6nS2SAk.png 05.36.07 # [Saint]: the code always killed the fade-in delay. the code now does not shorten the fade in to make it not extend past the fade out 05.36.30 # <[Saint]> jhMikeS: yeah, to be honest, I have no idea what the fade in delay is even useful for. I always set it to zero. 05.37.08 # <[Saint]> I sincerely doubt anyone would miss it if it just vanished one day, as long as the manual reflects this. 05.37.09 # [Saint]: it should be: in duration, out duration, offset (and that sets up all up fine) 05.37.32 # and AFAICT fade out on stop doesn't even work on any device with SW_CODEC anywyas 05.37.54 # jhMikeS: Clarification please. Are you saying your recent short track Crossfade bug fix changed the Crossfade function for long tracks too? 05.38.05 # <[Saint]> what is 'offset' in that context? 05.38.06 # not that it has anything to do with crossfade 05.38.09 # <[Saint]> Bilgus: are you actually testing against swcodec, or simulation? 05.38.16 # chrisjj: nothing changed, just degenerate trouble cases 05.39.28 Join JanC_ [0] (~janc@lugwv/member/JanC) 05.39.37 # chrisjj: normal stuff that has enough data to complete fades should behave the same as it was 05.39.49 # I take that to mean nothing changed /except/ your degenerate trouble cases ... which might be my and others' useful functionality cases such as gapped! :-) 05.39.57 # right 05.39.59 # Ah, great. 05.40.13 # <[Saint]> I told you users don't mean shit... 05.40.20 # ... depending on what you mean by "normal". 05.40.22 # [Saint]: good point, it hadn't occured to me to test on an actual device 05.40.44 Nick JanC is now known as Guest89953 (~janc@lugwv/member/JanC) 05.40.44 Quit Guest89953 (Killed (rajaniemi.freenode.net (Nickname regained by services))) 05.40.44 Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) 05.41.07 # Would you say stuff that has enough data to complete fades should behave the same as it was? (<< No 'normal' in there.) 05.41.09 # <[Saint]> Bilgus: yeah, the sim is just that, a sim. it's really a best effort approximation of the UI. 05.41.37 # [Saint]: maybe I'll just destroy the current setting a make a setting that just setting the relative offset :) 05.41.57 # [Saint]: then I'll forget to update the manual because I like coding, not writing documentation 05.42.09 # ^ 05.42.28 # * jhMikeS word saladed a second ago 05.42.33 # and good design kinda negates the need for the manual too 05.43.18 # <[Saint]> jhMikeS: well, poke me, and I'll do it - just make sure I'm clear on what it is you're doing if there's room for ambiguity with 'elegant' code. 05.43.18 # <[Saint]> I have a rare moment where Ms. [Saint] is away for another week or so and I can slip into bachelor frog mode. 05.43.20 # <[Saint]> So I can pick up the latex for you guys if I must. 05.43.49 # <[Saint]> It would be worth it at this stage just to point at chrisjj and say 'in your face, fucker - now they both match, and your use case is still gone - eat it" 05.44.06 # [Saint]: but I have to run it by chrisjj first! :) 05.44.33 # <[Saint]> If "by users, for users" was every true...it sure as shit isn;t now. 05.44.41 # <[Saint]> And it hasn;t been for the better part of a decade. 05.44.48 # <[Saint]> *ever 05.47.04 # haha 05.47.05 # <[Saint]> jhMikeS: the more I think about it, the more it makes sense to nuke the fade in and out delay. 05.47.40 Quit Riku (Quit: WeeChat 1.4) 05.47.41 # agreed 05.47.47 # What about an offset to say which starts first? Make sense? It allows exactly the same behavior in effect. 05.47.58 # <[Saint]> Hell, it might even make sense to scrap fade in and out duration too and just have a single parameter that just does a 50/50 bleed merge over the scope of 05.48.18 # <[Saint]> jhMikeS: wouldn;t most people always want them to start at the same time? 05.48.30 # [Saint]: as a programmer, such invariants please me. 05.48.37 # better yet would be a minimum percentage on output 05.48.50 # [Saint]: I don't know. If they did, why do we need two delays? 05.49.10 # Or did Slasheri just do it that way and it's a legacy thing? 05.49.11 # <[Saint]> jhMikeS: that's the thing, I've never seen any idication that we ever did. 05.49.38 # <[Saint]> the only thing it seems to have served the purpose of achieving is breaking the use case of small tracks and confusing the shit out of people. 05.49.46 # how about a single value say 6 seconds and then a percentage 05.49.47 # Slasheri: was here before me and had begun the nascent SWCODEC implementations at the time 05.50.14 # jhMikeS: Found that comment: /* Forego fade-in delay on manual skip - do the best to preserve auto skip relationship */ 05.50.16 # so you could say gave a 50/50 60/40 30/70 etc 05.50.18 # Bilgus: I actually like a 1 second crossfade on manual skip only 05.50.38 # <[Saint]> Bilgus: Oh, so you're saying...for people who might not want it to actually face to -72dB? 05.50.53 # <[Saint]> but some arbitrary percentile of non-zero volume? 05.50.59 # I remobe the crossfade on all but auto track changes bc it lags the damn player on fast track skips 05.51.00 # <[Saint]> *fade 05.51.19 # remove* 05.51.34 # <[Saint]> Bilgus: interesting - what target is that? 05.51.44 # clip+ 05.51.45 # <[Saint]> and do you also set the delay to zero? 05.52.03 # <[Saint]> I have fade in and out delay set to zero, and in and out duration set to 2 seconds. 05.52.11 # <[Saint]> I can skip all the live long day as fast as I want. 05.52.18 # <[Saint]> No observable difference. 05.53.06 # <[Saint]> I think you might be bouncing off the delay. 05.53.06 # <[Saint]> I see no such behavior. 05.53.09 # delay in/out is 0 in/out duration = 5 sec 05.53.39 # <[Saint]> that is interesting. Clip+ is both powerful enough and has fast enough ram and storage that that stumps me. 05.53.48 # Got to wonder how people here who never use the Crossfade delay feature think that they know enough about its use to decide that the feature is OK to remove... 05.53.55 # <[Saint]> I can skip tracks on my iPods as fast as my thumb allows me to. 05.54.20 # basically what happens is it lags behind on the track that is playing I'm on like the 5th and its playing a piece of the first 05.54.37 # <[Saint]> chrisjj: you're abusing something that shouldn;t work to provide behavior no one ever thought of. 05.54.39 # <[Saint]> cry me a river. 05.54.54 # Sure they thought of it. Read the manual. 05.54.55 # <[Saint]> if you want track gaps don;t encode gapless. 05.55.53 # <[Saint]> what are you talking about? 05.56.06 # <[Saint]> "Note: The rules above apply except in the instance where Fade Out Delay plus Fade Out Duration is less then Fade In Delay (which would create a gap in the audio). In this case, the Fade In Delay is reduced to eliminate the gap." 05.56.28 # <[Saint]> If you're getting a gap between tracks out of this it seems to be absolutely unintended behavior. 05.57.00 # jhMikeS, can you see any design sense in "/* Forego fade-in delay on manual skip" ... yet not auto-skip?? 05.57.00 # <[Saint]> both the code (pre and post recent commit) and the manual appear to be consistent in this regard in terms of intention. 05.58.59 # That /*...*/ in context: https://github.com/Rockbox/rockbox/blob/master/apps/pcmbuf.c#L1135 06.00.31 # <[Saint]> chrisjj: lets turn it around - what is your sense in desire for the opposite? 06.00.49 # chrisjj: yes i do. i want what I explicitly select to start right away 06.00.56 # <[Saint]> why would you ever want a track to wait for $DURATION after you specifically elected to _skip it right now_. 06.01.12 # <[Saint]> hah - snap, in a rare moment jhMikeS and I have parity in agreement. 06.01.22 # jhMikeS: have you committed your changes yet? once you are done I'll update 06.01.32 # [Saint]: ha! 06.01.34 # <[Saint]> Bilgus: yes, this is in. 06.02.12 # Bilgus: crossfade broken/weird edge case stuff fix-er up is there since last night 06.03.14 # jhMikeS: Interesting... because I see track skip doing no 'explicit select'. Track skip does an explicit /skip/! 06.03.18 # [Saint]: you don't want to wait ten seconds for the track you just selected to start playing which the WPS sits on 0:00 for it to kick in? 06.03.40 # <[Saint]> jhMikeS: call me old fashioned I guess. 06.04.28 # <[Saint]> I find this particularly amusing as this seems to me as though chrisjj is debating the need or want of the change, but is the one who called attention to the behavior. 06.04.35 # <[Saint]> ...suck lemons. 06.04.37 # chrisjj: what? by moving off something, you move to something else 06.05.02 # jhMikeS: You want the next track to start right away, but why do you want the current track not to stop right away? 06.05.15 # [Saint]: I think we're too old to understand the kids these days and their strange crossfading habit 06.05.28 # <[Saint]> chrisjj: seriously man, it is very hard to beleive you're not trolling at this point. 06.05.53 # <[Saint]> you really want to argue that the user specifically electing to skip a track isn;t a specific selection of that track? 06.06.13 # <[Saint]> even if it's set to random, you specifically elected for that to happen. 06.06.16 # chrisjj: I actually do but right now the control thread can be a bit busy before it gets your input. 06.06.19 # yes, yes he does. refer to logs 06.06.24 # <[Saint]> you're just grasping straws at this point. 06.07.15 # jhMikeS, then why not use Automatic Track Change Only? 06.08.09 # <[Saint]> because maybe he wants the fade without the duration? 06.08.12 # <[Saint]> shit man... 06.08.53 # chrisjj: oh we are still talking fade. it starts going away right away anways. think about what happens if delay the incoming track on a manual skip. 06.08.57 # <[Saint]> s/duration/delay/ 06.09.40 # <[Saint]> jhMikeS: he seems to have done so and has elected to consider the behavior deliberate and desirable. 06.10.11 # <[Saint]> when both the code and the manual both heavily imply it wasn;t ever intended to function like that. 06.10.34 # Mike, I thought already. I know exactly what I expect. I expect if I set a delay, I get a delay, If I don't want a delay I DON'T SET IT. I don't want the program overriding it so I can NEVER get the delay that is supposed to be available. 06.10.34 # once you skip, you're at the new track. you'd be watching the new tracks WPS for whatever the setting specifies while you are just listening to the old track with no progress on the et. 06.11.05 # "et"? 06.11.25 # <[Saint]> I sincerely doubt anyone laid out this function and thought "yeah, I'm going to set it up so that this can make people wait for the entire length of their fade in delay before the playback actually starts even though the track time counter has no clue what the hell to make of it and sits churning on 0. 06.11.35 # <[Saint]> " 06.11.51 Join Guest4557 [0] (765d7dea@gateway/web/freenode/ip.118.93.125.234) 06.11.59 # chrisjj: come up with a concrete and detailed proposal for exacly what one should observe with a manual delayed fade-in 06.12.10 # <[Saint]> I not only think that dropping the delay on manual skip is entirely fair I would argue it was always intended. 06.12.10 # "et"? 06.12.18 # chrisjj: "elapsed time" 06.12.26 # <[Saint]> alapsed timer 06.12.31 # <[Saint]> bah - spelling 06.12.49 # No progress on ET is correct. 06.13.11 # <[Saint]> also, wow, jhMikeS beat me outright there - lol 06.13.49 # <[Saint]> No, no it is not. 06.14.12 # My proposal is for what one should observe with the manual delayed fade-in is exactly "the rules above" in the manual: https://archive.is/9isgQ#selection-547.0-613.70 06.14.32 # as things are now, the track transistion happens when the incoming tracks fade-in begins 06.14.59 # Sure. No problem there. 06.15.06 # observing a fade-in delay would actually be inconsistent in the UI with automatic transistions 06.15.16 # How so? 06.15.50 # There would be a "dead" state because the manual skip never gets put off into the future, ever 06.16.36 # automatic transistion do not have a dead state with no progress, the wps switches at the fade-in. the delays happen when still on the outgoing wps 06.17.10 # If you are referring to the gap between fade-out end and fade-in start, then I see no inconsistency. 06.17.23 # That should how on manual and auto skip alike. 06.17.40 # Oops. That should show on manual and auto skip alike. 06.17.53 # there's nothing in the design of 10000+ lines of code that says "lets not do right now what someone told us to do right now" 06.18.05 # <[Saint]> jhMikeS: AFAIK the WPS switches when the fade out diration ends. 06.18.28 # <[Saint]> But honestly, either way, something is going to be inconsistent with total time vs. track duration. 06.18.49 # [Saint]: I know that it doesn't :) The transistion signal is sent just at the first frame of the incoming track. 06.18.59 # Mike, what you told was Track Skip. That is NOT "Start the next track immediately, regardless of Crossfade setting." 06.19.45 # chrisjj: the two are tighly linked in reality 06.20.15 # You could make a good case for Track Skip skipping the fade of the current track. But I see no good case for it messing with the fade of the NEXT track. 06.20.37 # The two should be as linked as they need to be. 06.20.47 # <[Saint]> jhMikeS: I need a target in front of me it seems, I can't recall closely observing this happen. Since one of them has to give - what gets clipped? the prior track's time remaining, or the current track's duration? 06.21.00 # chrisjj: so you propose that track 2's WPS shows with no progress all the while we wait for a delay of many seconds and the old track keeps playing alone? 06.21.03 Quit Guest4557 (Ping timeout: 260 seconds) 06.21.12 # <[Saint]> because track duration is actually going to be duration minus fade delay. 06.21.36 # They are linked as specified by the Crossfade settings. There's no need or justification for this arbitrary code logic that overrides that linkage. 06.22.24 # [Saint]: auto or manual skip? 06.23.02 # No I don't propose that. But you ought to take that up with the guy who thought it a smart idea to move the WPS off the current track that's playing only a next track that's NOT playing. 06.23.02 # [Saint]: fade delay doesn't affect incoming tracks duration. the first sample of the fade-in is the first sample of the new track 06.23.15 # <[Saint]> jhMikeS: either, because manual skip still fades - it just doesn't have the delay. 06.23.31 # Correction: ... the guy who thought it a smart idea to move the WPS off the current track that's playing on to a next track that's NOT playing. 06.24.05 # <[Saint]> I mean, lets say I have two tracks of 60 seconds, and I have a fade in and out duration of 2 seconds and no crossfade delay. does the first track, or the last track, show 58 seconds for the time remaining? Or the track duration? 06.24.12 # chrisjj: so we hit a button and show no change for x seconds? 06.24.14 # <[Saint]> Or do they show 60s for both? 06.24.20 # <[Saint]> I mean...one of them has to be wrong. 06.24.32 # <[Saint]> You can't blend N seconds of two tracks without decrasing the track time. 06.25.35 # * [Saint] knows he's going to basically run home and stare at this a lot with git head and git head~2. 06.25.48 # [Saint]: first track gets "clipped" by the amount that the incoming track is mixed into the outgoing one 06.26.11 # Er, why no change?? The current track is changing timepoint until it stops. 06.26.16 # <[Saint]> jhMikeS: does the time remaining reflect that? Or does it end seemingly prematurely? 06.27.11 # <[Saint]> seems to me like it shouldn't be too hard to adjust the track duration to reflect reality if that wasn't the case. 06.27.12 # [Saint]: it changes to the new screen when the incoming track starts to fade in. how do you not have it switch with time remaining? 06.27.58 # jhMikeS, the WPS issue is just a matter of what to show while two or zero tracks are playing. The solution shouldn't push back on to the playback itself. I.e. the playback should not be compromised just to help the WPS display what's playing. The playback should follow the playback settings, period. 06.28.21 # [Saint]: if I "clip" the expected track time, then I can't FF into that portion. 06.28.23 # <[Saint]> jhMikeS: well, that wasn't really my question - I know there needs to be N seconds of the actual track remaining in the pcmbuf - my question is if the track duration is adjusted to reflect this. 06.28.57 # <[Saint]> seems to me like it wouldn't be difficult to make the track time == track time-fade duration. 06.29.05 # [Saint]: nope, because we can't predict the future 06.29.55 # <[Saint]> jhMikeS: what do you mean, sure you can - if you skip prematurely, it doesn;t matter...and if you let it run out for an automatic change, it'll be right and you won;t have to worry. 06.29.55 # chrisjj: really, playback shouldn't reflect playback is what I hear you saying 06.30.19 # chrisjj: what the WPS displays is a consequence of what playback does 06.30.40 # <[Saint]> if track duration == track duration-fade duration, every time the timer hits 0:00 in an automatic skip will be right in the middle of the fade. 06.30.57 # <[Saint]> or "right", even though it's technically wrong. 06.31.13 # <[Saint]> because we /are/ actually decreasing the total runtime of the track with the fade duration. 06.31.29 # [Saint]: but if I don't present that last, say 10 seconds, because it will be part of a fade, the WPS cannot seek to that portion 06.32.12 # [Saint]: if we did do that, it should somehow seek to a negative time remaining? 06.32.20 # <[Saint]> jhMikeS: the upper bound is 15s. 06.32.37 # <[Saint]> how likely do we think it is a user will try to seek in or to the last 15 sec of a track? 06.32.44 # <[Saint]> I mean...I guess it is non-zero. 06.32.50 # <[Saint]> But to me that seems like the edge case. 06.33.19 # [Saint]: whether likely or not, they shouldn't be prohibited. Certain if the track is 15s long. 06.33.53 # <[Saint]> I'm more concerned about the track timers being accurate in the likely use case, as opposed to being inaccurate all the time, every time. 06.33.58 # <[Saint]> ...but I see the point. 06.34.11 # <[Saint]> The logic needed to drop that selectively would be non-trivial. 06.34.24 # <[Saint]> Hmmm. 06.34.35 Quit TheSeven (Ping timeout: 258 seconds) 06.34.39 # [Saint]: the track really is the duration specified in the wps though and that whole duration can be seeked or played 06.35.08 # [Saint]: now you want the WPS to lie about how long the tracks are? 06.35.17 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 06.35.21 Join JanC_ [0] (~janc@lugwv/member/JanC) 06.35.53 # I guess it's an ETA, not a duration though. Full duration should be reachable by seeking 06.35.56 # <[Saint]> jhMikeS: it wouldn't by lying, it doesn't have to adjust the track duration, I guess I misspoke - it should adjust the time remaining. 06.36.23 # <[Saint]> because it is guaranteed to be incorrect if a fade is applied. 06.36.28 # <[Saint]> bah - see what this cuck has done to us? we're arguing about weird meta issues. 06.36.31 # Have ETA go to 0, at which point it switches to the new track 06.36.32 Quit JanC (Killed (jackson.freenode.net (Nickname regained by services))) 06.36.32 Nick JanC_ is now known as JanC (~janc@lugwv/member/JanC) 06.36.36 # jhMikeS, last time I designed a crossfading player with display (albeit 30 years ago), here's where I switched the display: http://i.imgur.com/8xmSiMn.png 06.36.42 *** Saving seen data "./dancer.seen" 06.36.48 # Time for bed. Bye for now. 06.37.17 # 30 years ago? 06.37.22 # <[Saint]> fuck off...you designed a crossfading player 30 years ago? 06.37.28 # <[Saint]> Fuck right off. 06.37.55 # what hardware was around then? let's see, it was 1987, so like a Commodore 64 or Apple II 06.38.09 # excuse me "Apple ][" 06.38.17 # <[Saint]> jesus christ, this bastard has had a hel of a time pointing us at each other all day. 06.38.20 # <[Saint]> ...smooth, real smooth. 06.38.20 # <[Saint]> Good luck doing it again. 06.38.45 # I think he's probably going to law school or something. 06.39.47 # <[Saint]> The "I Am Very Smart" School Of Trolling and General Social Media Fuckery. 06.39.50 # The lawyers just pick a side and argue things, then switch sides and immediately and passionately continue, just for the practise 06.40.56 # <[Saint]> what crossfade capable media players were even around at that stage? 86, 87. 06.40.59 # <[Saint]> like, non? 06.41.13 # tape players 06.41.20 # <[Saint]> I mean, it would've had to be a dual tape-deck kinda affair, right? 06.41.27 # <[Saint]> yeah... 06.41.30 # I had one of those 06.41.36 # <[Saint]> in 86? 06.41.40 # [Saint]: I don't mind considering issue in ways I hadn't before. It's not _that_ bad. If I didn't feel like doing it, I just tell him to fuck off and simply leave the conversation 06.41.44 # <[Saint]> with an active display? 06.41.53 # more like 89 06.42.51 # [Saint]: It's was called mixing board 06.42.53 # well more like vfd not active persay 06.43.27 # <[Saint]> jhMikeS: I can understand where you're coming from as well, but I think it would be preferable for the time remaining counter to be right some of the time when crossfade is enabled, as opposed to wrong all of the time. 06.43.27 # <[Saint]> it's never actually really going to be time remaining. 06.43.27 # <[Saint]> it'll always be time remaining minus fade duration. 06.43.28 # [Saint]: The pathetic thing is I think 30 years ago was like 10 years ago. fuck. get me some diapers already. 06.43.49 # *old 06.44.00 # <[Saint]> jhMikeS: you're not that old are you? 06.44.13 # [Saint]: I guess the WPS could simply compensate it. It's more of a UI decision really. 06.44.21 # <[Saint]> I'm 'only' 35, going on 36 soon. 06.44.26 # <[Saint]> ...I feel goddamn ancient. 06.45.23 # [Saint]: you young padawan 06.45.39 # <[Saint]> jhMikeS: I wouldn't like this to be handled in UI/UX personally, we need the 'right' value to be passed to WPS in several places. 06.45.43 # [Saint]: 46 next month 06.46.10 # <[Saint]> I think if this is adjusted for duration it belongs in the playback engine entirely separate from UX. 06.46.58 # mmmm...the playback engine doesn't deal with duration, just position 06.47.44 # reasons include things that don't actually have a duration, like a lot of videogame music 06.48.26 # it's quite dumb in regard to time and just passes along whatever the codec tells it 06.48.40 # <[Saint]> so what reports duration/elapsed/remaining? I thought that was playback engine, so we could do things like timeshift easier? 06.48.56 # <[Saint]> is the skin engine doing this and I've menaged to overlook it for...ever? 06.49.15 # <[Saint]> *managed 06.49.27 Join Senji [0] (~Senji@85.187.103.250) 06.51.16 Join Guest4755 [0] (765d7dea@gateway/web/freenode/ip.118.93.125.234) 06.52.00 Quit naleo (Ping timeout: 246 seconds) 06.52.23 Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) 06.55.41 # <[Saint]> Man, will you just look at the quality of work that went in to that crossfade diagram? 06.56.01 # <[Saint]> muhfugger's got a lil' dropshadow 'n everything. 06.57.09 Quit cc___ (Ping timeout: 255 seconds) 07.05.16 # [Saint]: the metadata parser puts the duration info into the id3. playlist code puts the resume time and offset into the id3. the codec puts the current time and offset for the pcm it just generated into the pcm buffer. the pcm buffer puts the currently playing PCMs time and offset into the id3. the wps reads the id3 to get the current time. at the end of playback, the playback engine tells 07.05.16 # the playlist what the current time was when it was stopped. 07.05.35 Quit Senji (Ping timeout: 245 seconds) 07.06.17 # [Saint]: when it resumes, the cycle begins again 07.06.46 # <[Saint]> makes me wonder what the UX is fucking up with the skin engine tag that asks for a raw percentile of elapsed time then. 07.07.01 # <[Saint]> seems like that should be unambiguous all of the time under that system. 07.08.14 # <[Saint]> perhaps that's where I got the idea that skin engine had no part in this and just got passed info direct from playback engine. 07.08.25 # [Saint]: I don't know what the skin engine does. I've spent all of minutes at most with that code. 07.09.03 # playback engine just keeps the time and offset up to date for someone to read 07.09.29 Quit Guest4755 (Quit: Page closed) 07.09.32 # not everything has an offset associate with it though 07.09.55 # A VGM file has ET but no offset since it's an emulator and progress through the file doesn't happen 07.10.32 # [Saint]: which files don't show % elapsed correctly? 07.10.53 Quit funman_ (Ping timeout: 246 seconds) 07.11.48 Join funman [0] (~fun@chui-pas.net) 07.11.50 # <[Saint]> it's not elapsed time but total time. skin engine will occasionally screw that up for partially buffered tracks in the playlist viewer. 07.13.07 # [Saint]: It shouldn't know those unless metadata was parsed for them. Metadata is parsed before any buffering happens. 07.14.50 # <[Saint]> hmmm, that's interesting. perhaps I'm looking at an overflow somewhere then. I just assumed, which I guess was dangerous, that the skin engine had no part in this arrangement and was just getting what it was handed. 07.15.29 # [Saint]: where does the playlist viewer show durations? Is that something you skin? 07.15.30 # <[Saint]> drawing a playlist viewer in the wps or sbs is hardly a common use case or a well tested one so I guess that is probable. 07.16.52 # <[Saint]> jhMikeS: yes. it's a skin draw object. I thought it pertained to partially buffered tracks before it was always the last track displayed that was showing a screwy total time. 07.17.05 # * jhMikeS wonders where the code that comes up with that figure is 07.17.33 # <[Saint]> well, so do I now. 07.18.07 # <[Saint]> I thought it was just asking the playback engine for it. 07.18.36 # <[Saint]> I didn't realize it needed to be derived from a complicated wee dance of a million variables. 07.18.47 # playback only has metadata for the buffered tracks or the partially buffered last track + next track info in a special place if the next track can't be buffered at all yet 07.20.56 # <[Saint]> I'll poke at it again when I'm over home unless I get distracted. It was such a reliable thing that I ended up abusing draw order every time I used the embedded playlist viewer so that I could draw overtop of the last list item so that it never displayed the batshit value. 07.21.01 # unless the elements cause extraction of metadata to be done on the side, playback has nothing beyond the window of what fits in memory 07.22.54 Join parchd [0] (~parchd@unaffiliated/parchd) 07.23.06 # [Saint]: what's the name of the element? 07.24.39 # <[Saint]> https://scontent.fxds1-1.fna.fbcdn.net/v/t1.0-9/15894736_10154256853231527_8021909253646482129_n.jpg?oh=8363eacaa4c15a33ef51ea5521f3661c&oe=59188BE2 07.24.42 # <[Saint]> shit. 07.25.04 # cat tag 07.25.07 # <[Saint]> https://www.rockbox.org/wiki/CustomWPS#Playlist_viewer 07.25.52 # <[Saint]> for the last entry in 'skin code to render' if I asked it for track time it would almost reliably be completely and utter nonsense. 07.26.23 # <[Saint]> anywhere from 0:00 to several hundred minutes. 07.26.50 # <[Saint]> though in hindsight I'm not certain I've touched this since your dramatic rework of all things playback. 07.27.12 # <[Saint]> knowing my luck it magically fixed itself which would be both good and troubling. 07.27.48 # [Saint]: you mean %pt? 07.34.18 # <[Saint]> yeah - but I was also using some pretty screwy magic to derive the percentage of those tracks displayed as a whole in terms of the length of the current playlist if the playlist length was greater than 1. 07.35.04 # <[Saint]> kinda hard to say what was going on in my mind at the time. there was a while there where I think gevaerts and I were trying to out-crazy each other with weird shit we could get the skin engine to do. 07.36.17 Join Senji [0] (~Senji@85.187.103.250) 07.36.37 # I can see it needs an id3 structure passed to it to use SKIN_TOKEN_TRACK_LENGTH. 07.36.49 # bah it has some weird quirks to this day, bar tags comes to mind 07.44.50 # <[Saint]> Bilgus: what's wrong with bar tag? 07.45.09 # <[Saint]> despite the hilariously fucked up variant which draws a positional pointer. 07.45.22 # <[Saint]> I know /that/ is plain screwed. 07.45.29 # <[Saint]> the rest of the bars should be fine. 07.46.26 # <[Saint]> (fun fact - you can turn almost any tag into a bar tag) 07.46.39 # <[Saint]> like, you can make shuffle into a bar tag if you want. 07.46.50 # [Saint]: in the case of an id3 not being available, it appears the switch doesn't cover every tag that would need default value filled 07.47.31 # <[Saint]> jhMikeS: should that just reports 0:00 then or so? 07.47.54 # oh its been a while but IIRC the image tags and background, alongs with a few other things I can't recall atm 07.47.55 # <[Saint]> not the occasional several hundred minutes I would see? 07.48.00 # it should but it doesn't seem to actually write anything to the variable pointed to in its parameter 07.48.10 # <[Saint]> I'll see if I can get it to do it again, but remembering the exact sequence of voodoo used might be tricky. 07.49.43 # <[Saint]> Bilgus: oh, yeah - right, I think I know what you're talking about - I never met you years ago, I don't think, but there is some very specific requirements for draw ordering and viewport setup to get the bars to behave as expected depending on what else you've got going on onscreen. 07.50.40 # <[Saint]> a complex mix of drawing into the befault viewport and the backdrop buffer and forcing a blank fullscreen viewport overtop with a 1ms update to keep the screen refreshed on update of dynamic content. 07.50.48 # <[Saint]> *default 07.51.00 # * [Saint] should really go home but it is raining 07.51.43 # its funky but once you figure it out it works I just ran into a variant of it again putting a vol bar in cabbie for chrisjj; 07.52.12 Join Guest4788 [0] (765d7dea@gateway/web/freenode/ip.118.93.125.234) 07.55.49 # [Saint]: yeah, I can see probably why it's returning weird stuff 07.57.21 Quit JdGordon (Ping timeout: 248 seconds) 07.58.46 Join ender` [0] (krneki@foo.eternallybored.org) 08.34.19 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 08.36.45 *** Saving seen data "./dancer.seen" 08.36.50 Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) 08.48.17 Nick [Saint] is now known as TyrellWellick (~sinner@rockbox/staff/saint) 08.49.09 Nick TyrellWellick is now known as JoannaWellick (~sinner@rockbox/staff/saint) 08.49.43 Join mxyzptlk [0] (~joe@va-184-5-255-226.dhcp.embarqhsd.net) 08.49.46 Nick mxyzptlk is now known as mxyzplx (~joe@va-184-5-255-226.dhcp.embarqhsd.net) 08.52.43 Quit Guest4788 (Ping timeout: 260 seconds) 08.53.03 Nick JoannaWellick is now known as PhillipPrice (~sinner@rockbox/staff/saint) 08.53.41 Nick PhillipPrice is now known as ElliotAlderson (~sinner@rockbox/staff/saint) 08.54.50 Quit cohokiller673 (Remote host closed the connection) 08.54.53 Nick ElliotAlderson is now known as [Saint] (~sinner@rockbox/staff/saint) 08.55.14 Part mxyzplx ("Good Bye") 08.56.16 # chrisjj: regarding dual-boot, I will look into it 08.57.55 # [Saint]: chrisjj: the "size" reason is simply to avoid uploading a 50MB firmware when dual-boot is impossible (also licencing). It's completely feasible to dual-boot, in theory 08.58.04 Join cohokiller673 [0] (cohokiller@c-24-22-103-176.hsd1.wa.comcast.net) 08.58.21 # <[Saint]> can the zens really 'dualboot' per se, pamaury? 08.58.22 # <[Saint]> My understanding was thatthey couldn't do so on-the-fly without some manual intervention. 08.59.05 # <[Saint]> and, yeah - I knew it was possible in theory, but in practice it isn't really trivially possible is it? 09.00.07 # <[Saint]> since switching back and forth involves purging internal it's more than a little bit fucky IIUC. 09.00.57 # [Saint]: that's why we are discussing with chrisjj to make rockbox be able to boot from microSD, if internal storage is not format as FAT 09.01.10 # <[Saint]> I didn't mean to say that it wasn't possible at all, but short of adding a secondary filesystem into Rb core it definitely isn't possible trivially or on-the-fly, is it? 09.01.17 # booting the OF requires so code, one has to parse the OF executable format and load it 09.01.31 # <[Saint]> right 09.01.43 # I don't plan to add a second file system to Rockbox, that's way too much work 09.01.51 # <[Saint]> yeah, indeed. 09.02.08 # <[Saint]> though realistically exfat would be nice I can sympathize. 09.02.34 # <[Saint]> large file support isn't something that's needed that badly. 09.03.24 # <[Saint]> ext* or some other deep permission based filesystem would also be nice but...yeah. 09.04.11 # are there many things using exfat these days ? 09.23.30 Quit Moarc (Ping timeout: 245 seconds) 09.25.22 Quit __builtin (Remote host closed the connection) 09.25.35 Quit Acou_Bass (Ping timeout: 245 seconds) 09.25.55 Quit krnlyng (Ping timeout: 248 seconds) 09.25.56 Quit kugel (Ping timeout: 248 seconds) 09.26.00 Quit derf (Ping timeout: 245 seconds) 09.26.25 Quit GeekShadow (Ping timeout: 245 seconds) 09.26.25 Join kugel [0] (~kugel@ip5b42c25b.dynamic.kabel-deutschland.de) 09.27.08 Join GeekShadow [0] (~antoine@nzf.turmel.info) 09.28.33 Join Moarc [0] (~chujko@a105.net128.okay.pl) 09.29.41 Join yosafbridge [0] (~yosafbrid@68.ip-149-56-14.net) 09.30.33 Join froggymana [0] (~frogs@main.cluster.pulham.info) 09.31.27 Quit munch (*.net *.split) 09.31.27 Quit scorche (*.net *.split) 09.31.27 Quit mc2739 (*.net *.split) 09.31.28 Quit K1773R (*.net *.split) 09.31.28 Quit ChanServ (*.net *.split) 09.31.28 Quit chrisjj (*.net *.split) 09.31.28 Quit Bilgus (*.net *.split) 09.31.28 Quit tomflint (*.net *.split) 09.31.28 Quit sparetire (*.net *.split) 09.31.28 Quit puckipedia (*.net *.split) 09.31.29 Quit shrizza (*.net *.split) 09.31.29 Quit bittin (*.net *.split) 09.31.29 Quit Tristitia (*.net *.split) 09.31.30 Quit benedikt93 (*.net *.split) 09.31.30 Quit CommunistWitchDr (*.net *.split) 09.31.31 Quit Rondom (*.net *.split) 09.31.31 Quit aevin_ (*.net *.split) 09.31.31 Quit preglow (*.net *.split) 09.31.31 Quit akaWolf (*.net *.split) 09.31.31 Quit Marex (*.net *.split) 09.31.31 Quit olejorgenb (*.net *.split) 09.31.31 Quit Cu5tosLimen (*.net *.split) 09.31.31 Quit froggyman (*.net *.split) 09.31.31 Quit comradekingu (*.net *.split) 09.31.32 Quit cttttt (*.net *.split) 09.31.32 Quit ParkerR (*.net *.split) 09.31.33 Quit APLU (*.net *.split) 09.31.33 Quit atsampson (*.net *.split) 09.31.33 Quit The_Prospector (*.net *.split) 09.31.34 Quit gevaerts (*.net *.split) 09.31.34 Quit yosafbridge` (*.net *.split) 09.31.34 Quit Kohlrabi (*.net *.split) 09.31.34 Quit uwe_android (*.net *.split) 09.31.35 Quit Jack87 (*.net *.split) 09.31.35 Quit prg318 (*.net *.split) 09.31.35 Quit GodEater (*.net *.split) 09.31.36 Quit Fa1th (*.net *.split) 09.31.37 Quit rogeliodh (*.net *.split) 09.34.16 Join derf [0] (~derf@static-108-18-126-14.washdc.fios.verizon.net) 09.37.17 Join munch [0] (pls@gateway/shell/elitebnc/session) 09.37.34 Join chrisjj [0] (5001d87b@gateway/web/freenode/ip.80.1.216.123) 09.37.34 Join APLU [0] (~mulx@eva.aplu.fr) 09.37.34 Join tomflint [0] (~tomflint@unaffiliated/tomflint) 09.37.34 Join bittin [0] (~luna@unaffiliated/bittin) 09.37.34 Join prg318 [0] (~prg318@deadcodersociety/prg318) 09.37.34 Join CommunistWitchDr [0] (quasselcor@97-87-177-85.dhcp.stls.mo.charter.com) 09.37.34 Join sparetire [0] (~sparetire@unaffiliated/sparetire) 09.37.34 Join atsampson [0] (~ats@cartman.offog.org) 09.37.34 Join Cu5tosLimen [0] (~CustosLim@unaffiliated/cust0slim3n) 09.37.34 Join scorche [0] (~scorche@rockbox/administrator/scorche) 09.37.34 Join The_Prospector [0] (~The_Prosp@unaffiliated/cornman) 09.37.34 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 09.37.34 Join Bilgus [0] (ae6611d9@gateway/web/freenode/ip.174.102.17.217) 09.37.34 Join Rondom [0] (~rondom@modo.nonmodosedetiam.net) 09.37.34 Join GodEater [0] (~whoknows@rockbox/staff/GodEater) 09.37.34 Join shrizza [0] (~shrizza@210.154.134.187) 09.37.34 Join gevaerts [0] (~fg@rockbox/developer/gevaerts) 09.37.34 Join aevin_ [0] (eivindsy@microbel.pvv.ntnu.no) 09.37.34 Join preglow [0] (~thomj@2001:840:4243:3::101) 09.37.34 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) 09.37.34 Join Marex [0] (~Marex@195.140.253.167) 09.37.34 Join olejorgenb [0] (~olejorgen@cm-84.215.214.223.getinternet.no) 09.37.34 Join Fa1th [0] (~Fa1th@46.101.133.147) 09.37.34 Join Kohlrabi [0] (~kohlrabi@kohlio.de) 09.37.34 Join uwe_android [0] (~uwe_andro@static.173.76.9.176.clients.your-server.de) 09.37.34 Join comradekingu [0] (~comradeki@ti0005a400-4108.bb.online.no) 09.37.34 Join Tristitia [0] (~tristitia@static-ip-69-64-50-196.inaddr.ip-pool.com) 09.37.34 Join benedikt93 [0] (~quassel@unaffiliated/benedikt93) 09.37.34 Join Jack87 [0] (Jack87@nasadmin/admin/jack87) 09.37.34 Join K1773R [0] (~K1773R@unaffiliated/k1773r) 09.37.34 Join ParkerR [0] (~ParkerR@unaffiliated/parkerr) 09.37.34 Join rogeliodh [0] (~rogeliodh@ec2-52-90-241-120.compute-1.amazonaws.com) 09.37.34 Join ChanServ [0] (ChanServ@services.) 09.37.34 Mode "#rockbox +o ChanServ " by nylund.freenode.net 09.37.46 Quit sparetire (Max SendQ exceeded) 09.38.43 Quit munch (Changing host) 09.38.43 Join munch [0] (pls@gateway/shell/elitebnc/x-tnbqbvvxsnukfsue) 09.39.09 Join krnlyng [0] (~liar@77.116.51.233.wireless.dyn.drei.com) 09.39.16 Nick kugel is now known as Guest20998 (~kugel@ip5b42c25b.dynamic.kabel-deutschland.de) 09.39.16 Quit froggymana (Changing host) 09.39.16 Join froggymana [0] (~frogs@unaffiliated/froggyman) 09.39.20 Quit munch (Changing host) 09.39.20 Join munch [0] (pls@unaffiliated/munch) 09.39.26 Nick froggymana is now known as froggyman (~frogs@unaffiliated/froggyman) 09.39.29 Quit munch (Changing host) 09.39.29 Join munch [0] (pls@gateway/shell/elitebnc/x-tnbqbvvxsnukfsue) 09.39.40 Join sparetire [0] (~sparetire@unaffiliated/sparetire) 09.39.41 Join __builtin [0] (~xray@rockbox/developer/builtin) 09.40.05 Join Acou_Bass [0] (~Acou_Bass@host-78-148-16-72.as13285.net) 09.40.08 Quit marex-cloud (Ping timeout: 240 seconds) 09.41.29 Join puckipedia [0] (puck@puckipedia.com) 09.45.44 Join cttttt [0] (sid135570@gateway/web/irccloud.com/x-qlspmwxyaibewacg) 09.53.28 Join marex-cloud [0] (sid137234@gateway/web/irccloud.com/x-jphenavmmglwbojf) 10.02.51 # pamaury: On Exfat, large memory cards (large=>32GB) do by default - or at least *SD. Not sure about CF these days. I suspect not much else does. I've wished for RB to support an ext* FS because I've had reason to want to symlink files. 10.03.28 # Unless there's a way to create a shortcut file such that RB will act as if the shortcut is a real audio file in place of the shortcut. 10.03.49 Quit jhMikeS () 10.03.51 Quit funman (Changing host) 10.03.51 Join funman [0] (~fun@rockbox/developer/funman) 10.04.05 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 10.04.35 Quit jhMikeS (Client Quit) 10.04.51 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 10.05.10 # <[Saint]> There is not. 10.05.28 # <[Saint]> shortcuts are only navigated to with the shortcut item in focus. 10.05.46 # <[Saint]> they aren't ever run automatically. 10.06.15 # [Saint]: jhMikeS: On the question of RB trying to fix up dead paths, I'd think about a simple test: Run through all mountpoints and see if any of them are valid. If all fail, then skip. 10.06.18 # *in playlists 10.06.26 # Thought not on the shortcut. 10.06.58 # The usecase would be getting auto-change directory to allow a file to appear in two directories without duplicating it on disk. 10.07.14 # Ah, well. Storage is cheap enough these days. 10.10.34 # <[Saint]> what is the function behind that use case TorC? 10.10.51 # * [Saint] has had a shit day gone worse and cares to distract himself 10.12.05 # Because I like single tracks mostly, and to have them come up entirely randomly, but still have some things like musicals and classical multi-movement works play in order. 10.12.28 # Still, sometimes it is nice to just play an album in order. 10.12.58 # Or, sometimes I put the album to both play complete as a dir, and play the single tracks in separate dirs. 10.13.10 # Symlinks would save the duplication on disk. 10.14.05 # Before the FS rework, adding another file system was really hard because of the tight integration with FAT. With the new code, I don't know if it's better. But in any case, adding a new file system is a lot of work, takes a lot of binary space, for little gain. Exfat would be justifiable to me (kinda of) but ext* much less so 10.14.11 # <[Saint]> y'know you can nest playlists, right? 10.14.48 # Seemed like I tried that and it didn't work. Of course that might have been back in the days I still had 3.13 on my player 10.16.08 # pamaury: the biggest argument for exfat is that Windows format utility (so I've heard) either refuses or makes it difficult to format *SD cards >32GB to fat32. 10.16.18 # A lame reason, in my book. 10.16.28 # But then I never run into the issue. 10.16.45 Quit jhMikeS () 10.17.01 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 10.17.11 # [Saint]: It might have been that the playlists would play shuffled, not true random. Been a while since I tried. 10.17.54 # <[Saint]> we don't have and haven't ever had true random. 10.17.54 # <[Saint]> and won't have. 10.17.58 Quit jhMikeS (Client Quit) 10.18.17 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 10.18.25 # <[Saint]> the broad consensus is users don't actually want true randomness. 10.18.59 # <[Saint]> Rockbox shuffle has always been psuedorandom. For all media types. 10.19.11 Quit krnlyng (Ping timeout: 240 seconds) 10.19.18 # <[Saint]> Each track will be played precisely once and precisely once only. 10.19.23 # Random folder advance is true random - or at least true random to the limits of the PRNG 10.19.30 Nick jhMikeS is now known as _jhMikeS_ (~jethead71@d192-24-173-177.try.wideopenwest.com) 10.19.34 # Which is why I use that, not playlists. 10.19.34 Nick _jhMikeS_ is now known as jhMikeS (~jethead71@d192-24-173-177.try.wideopenwest.com) 10.20.09 # I despise shuffled rather than random, because with shuffle I know when I hear a track I like it won't come up again for a long time. 10.20.13 # <[Saint]> ...are you positive of this? I'm not so confident. 10.20.26 # <[Saint]> I believe it just re-uses the same prng sequence. 10.20.50 # <[Saint]> play everything precisely once, then repeat. 10.20.59 # With RFA, I've gotten the same song twice in a row - on occasion, or much more frequently. 10.21.10 # *than cycling through. 10.21.39 # <[Saint]> how on earth does that even happen? 10.21.49 # <[Saint]> you have singular tracks per directory? 10.21.54 # The songs in a dir containing multiple songs always play in order 10.22.03 Quit jhMikeS (Client Quit) 10.22.04 # Yes, I place singular songs in a dir. 10.22.13 # Just to get that behaviour. 10.22.39 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 10.22.42 # And keep songs in a dir that I want to always play in album order when the dir comes up. 10.23.24 # <[Saint]> I'm very curious, when you did get the same track twice in a row or more...how did you handle it? 10.23.34 # <[Saint]> you skipped it immediately, right? pretty much validating that Joe User wants psuedorandom? 10.24.19 # <[Saint]> that kind of behavior is pretty much the crux of why the playlist random implementation is psuedorandomness. 10.24.53 # <[Saint]> curiously, when people have true randomness, they tend to accuse it of not being random because they believe they see patterns in it. 10.25.21 # <[Saint]> even though, albeit slim, the odds of playing the same track 100 times in a row is perfectly valid and a user would claim that to be broken. 10.25.21 # Depends on the track. Sometimes I listen to it (because it's one I like) or sometimes I skip it. If it's a few songs later, I'm much more likely to listen to it. Every once in a while I will set to repeat one to keep a song I like and haven't heard much for an extra round. 10.25.31 # <[Saint]> so it's easier to just do psuedorandom. 10.25.46 # Actually, I don't think I've had the same song three times in a row. 10.26.08 # Even the same thing twice in a row is pretty rare these days as my collection grows. 10.26.19 # <[Saint]> wouldn't it be easier to just stick it on repeat or insert the track into the playlist again if it is one you liked? 10.26.30 # <[Saint]> you can even insert randomized. 10.27.37 # The issue I have is there's enough of my collection I don't like so much that I rarely listen to a noticeable portion of it - ever. Just skip those tracks. Other tracks I almost never skip. 10.28.33 # <[Saint]> seems to me like you should be using the database and the rating system and inserting tracks weighted from your rating. 10.28.39 # Things I pick up a library booksales and such that I keep thinking about purging from my device. 10.28.55 # <[Saint]> there's actually a flyspray or gerrit task floating around for weighted random shuffle. 10.29.01 # Maybe I should do so. 10.29.16 # <[Saint]> that increases or decreases the odds of hearing any one given track by N% 10.29.45 # <[Saint]> like, you can select a track or group of track and weight it by N=10 and you're 10% more likely to hear one of those tracks than any other. 10.29.48 # I recall seeing one that would derate some dirs for RFA, but I'm not sure that's the one you mentioned. 10.30.13 # <[Saint]> it does this by inserting the track N times into the playlist to artificially weight it in the desired favor. 10.31.00 # <[Saint]> fs#1042 10.31.01 # http://www.rockbox.org/tracker/task/1042 3Weighted Playlists / Smart Weighted Playlists (feature, closed) 10.31.13 # <[Saint]> should still apply with minimal fuzzing. 10.32.37 Join krnlyng [0] (~liar@77.116.88.74.wireless.dyn.drei.com) 10.32.48 # <[Saint]> shit, sorry - dammit. 10.32.49 # <[Saint]> that's not the one. 10.33.26 # <[Saint]> I swear JdGordon actually implemented this... 10.34.14 # <[Saint]> Oh, that's the weighted RFA you were talking about. 10.34.22 # <[Saint]> Hmmm...where's the one I'm thinking of. 10.34.42 # I was just writing that I thought he might have been the author of the one I remembered. 10.36.41 Quit vifino (Ping timeout: 246 seconds) 10.36.46 *** Saving seen data "./dancer.seen" 10.38.11 Join vifino [0] (~vifino@tty.sh) 10.42.23 Quit bittin (Ping timeout: 265 seconds) 10.49.21 Join bittin [0] (~luna@vps154124.loopiavps.com) 10.51.02 Quit bittin (Changing host) 10.51.02 Join bittin [0] (~luna@unaffiliated/bittin) 10.51.37 Quit advcomp2019 (Read error: Connection reset by peer) 10.51.40 Join johnb2 [0] (~johnb2@p5B29683A.dip0.t-ipconnect.de) 10.53.34 # On the Sony NWZ-585, how good is the device in the OF? Is the noise cancellation working well? 10.55.52 Join Boltermor [0] (~Boltermor@subscr-46-148-169-2.dhcp-docsis.net.tomkow.pl) 10.58.49 Quit johnb2 (Ping timeout: 272 seconds) 11.04.12 # johnb2: OF is quite good imo, someone tried NC and said it was ok but not as good as good isolated headphones 11.06.47 # Does it try to do noise cancellation using a microphone away from the speakers? 11.09.57 Join johnb2 [0] (~johnb2@p5B29683A.dip0.t-ipconnect.de) 11.16.24 Join paulk-blaze [0] (~paulk@no3.u-bordeaux.fr) 11.18.30 Join mutnai [0] (6db91733@gateway/web/freenode/ip.109.185.23.51) 11.18.55 Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) 11.18.55 Quit mutnai (Client Quit) 11.20.46 # For a manual entry for #1417, what are the /opt{} tags for softlock and scrollwheel? Respectively where do I need to look for all available conditions? 11.22.05 # johnb2: typically you need to create an option. There are three ways: either each target specific option file (.tex) defines it. OR you \opt{target1,target2,...} OR you use apps/features.txt 11.24.49 # Ok, I will look into what sits there already. 11.27.31 Join MrZeus [0] (~MrZeus@81.144.218.162) 11.29.14 # johnb2: if you need more help on that, I can have a look at it this afternoon to give you some advise 11.31.08 # Thanks, I would ping you again later. I will start with the plain text part first then ;-) 11.36.11 Quit johnb2 (Ping timeout: 272 seconds) 11.37.14 Quit pamaury (Ping timeout: 246 seconds) 11.39.30 Join MrZeus_ [0] (~MrZeus@81.144.218.162) 11.42.50 Quit MrZeus (Ping timeout: 246 seconds) 11.47.44 Quit paulk-blaze (Remote host closed the connection) 11.53.09 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:b504:5d71:7934:f127) 12.15.21 Join pamaury [0] (~quassel@wks-50-63.mpi-sws.org) 12.15.21 Quit pamaury (Changing host) 12.15.21 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 12.23.29 Quit jhMikeS (Ping timeout: 248 seconds) 12.24.45 Join skapazzo [0] (~skapazzo@151.9.205.1) 12.31.06 Quit Boltermor (Quit: Leaving) 12.36.43 Join johnb2 [0] (~johnb2@p5B29683A.dip0.t-ipconnect.de) 12.36.47 *** Saving seen data "./dancer.seen" 12.44.45 Join paulk-blaze [0] (~paulk@no3.u-bordeaux.fr) 13.12.19 Join aptzero [0] (~Adium@96-95-20-86-static.hfc.comcastbusiness.net) 13.16.29 Join robertd1 [0] (~root@201.242.214.237) 13.40.51 Quit johnb2 (Ping timeout: 248 seconds) 13.43.31 Nick MrZeus_ is now known as MrZeus (~MrZeus@81.144.218.162) 13.52.18 # pamaury: [Re ZEN dual boot] OK, I'll keep that forum post back until I hear from you. 13.59.57 Quit paulk-blaze (Quit: Leaving) 14.01.13 Join johnb2 [0] (~johnb2@p5B29683A.dip0.t-ipconnect.de) 14.07.30 Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) 14.14.32 Quit aptzero (Quit: Leaving.) 14.15.44 # jhMikeS: Since you're interested :) here's a pic http://i.imgur.com/8xmSiMn.png 14.16.32 # Oops, corrected: jhMikeS: Since you're interested :) here's a pic http://i.imgur.com/73VW0jA.png 14.30.52 Join mutnai [0] (6db91733@gateway/web/freenode/ip.109.185.23.51) 14.33.03 Quit johnb2 (Ping timeout: 256 seconds) 14.36.49 *** Saving seen data "./dancer.seen" 14.38.34 # lebellium: Sony announced the A35, you need another christmas ;) 14.53.34 Join johnb2 [0] (~johnb2@p5B29683A.dip0.t-ipconnect.de) 14.56.40 Join idonob_ [0] (~Owner@S010610c37b922980.vs.shawcable.net) 15.08.13 Join n3m9 [0] (~n3m9@ANantes-652-1-183-36.w2-1.abo.wanadoo.fr) 15.15.13 Quit johnb2 (Ping timeout: 248 seconds) 15.20.06 Part robertd1 15.21.54 Quit mutnai (Quit: Page closed) 15.27.47 Join vflyson [0] (~vflyson@cupcake.uberspace.net) 15.34.35 Join johnb2 [0] (~johnb2@p5B29683A.dip0.t-ipconnect.de) 15.35.40 # pamaury: lcd_fix ZEN boot fails to recognise SD card. Workaround: remove and reinsert card. 15.38.41 # TorC: Re your two kinds of random, you might find handy the terms that computer games designers use. Random order; random selection. 15.39.12 # True random / pseudo random is orthogonal to this. 15.40.26 # pamaury: a bit more context would help, you mean that current bootloader does not boot from SD card ? 15.40.37 # chrisjj: ^ 16.01.51 Join xorly [0] (~xorly@ip-89-176-102-19.net.upcbroadband.cz) 16.21.07 # pamaury, no, I mean that on boot, RB launches from internal memory but Files fails to show the SD card. 16.27.23 # hum ok, I'll have a look 16.29.00 # Thanks. BTW, I thought there was no support for bootloader booting (i.e. launching .rockbox) from SD card. Is that correct? 16.36.53 *** Saving seen data "./dancer.seen" 16.40.35 # I don't remember. Booting from SD card is not special in itself, rockbox boots from the first available volume iirc, but SD are a bit special in that they are usually not probed unless accessed, which I am not sure bootloaders do. I need to check that tonight 16.42.18 Join Senji_ [0] (~Senji@85.187.103.250) 16.44.48 Quit Senji (Ping timeout: 248 seconds) 16.53.52 Quit johnb2 (Ping timeout: 248 seconds) 16.53.58 Quit Bilgus (Ping timeout: 260 seconds) 16.54.33 Quit chrisjj (Ping timeout: 260 seconds) 17.01.59 Quit Strife1989 (Read error: Connection reset by peer) 17.05.45 Join Strife89 [0] (~quassel@adsl-98-67-58-2.mcn.bellsouth.net) 17.18.29 Join ulmutul [0] (~chatzilla@dslb-094-221-072-088.094.221.pools.vodafone-ip.de) 17.27.55 Join johnb2 [0] (~johnb2@p5B29683A.dip0.t-ipconnect.de) 17.39.08 Quit pamaury_ (Ping timeout: 246 seconds) 17.41.56 Join mutnai [0] (6db91733@gateway/web/freenode/ip.109.185.23.51) 17.42.13 Quit mutnai (Client Quit) 17.44.46 Quit johnb2 (Ping timeout: 272 seconds) 17.46.31 Quit skapazzo (Quit: leaving) 17.48.30 Join rela [0] (~x@pdpc/supporter/active/rela) 17.52.56 Quit ulmutul (Quit: ChatZilla 0.9.93 [Firefox 50.1.0/20161208153507]) 17.53.13 Join cc___ [0] (~ac@2001:910:113f:1:6a05:caff:fe1c:1627) 17.54.19 Join paulk-blaze [0] (~paulk@no3.u-bordeaux.fr) 17.57.17 Join johnb2 [0] (~johnb2@p5B29683A.dip0.t-ipconnect.de) 18.01.38 Quit johnb2 (Ping timeout: 248 seconds) 18.08.35 Join johnb2 [0] (~johnb2@p5B29683A.dip0.t-ipconnect.de) 18.14.03 Join saratoga [0] (123e11e0@gateway/web/freenode/ip.18.62.17.224) 18.14.32 # johnb2: usually to do noise cancellation you must be < so usually the microphone is put very close to the speakers, otherwise only very low frequencies can be canceled 18.17.36 Quit Senji_ (Ping timeout: 248 seconds) 18.17.44 # saratoga: the included NC headphones do have mics in the phone case AFAIK. I Will learn it soon, I have ordered a used one on A..zon. 18.22.10 Quit johnb2 (Ping timeout: 258 seconds) 18.36.57 *** Saving seen data "./dancer.seen" 18.49.04 Join lebellium_z3c [0] (~AndChat73@80.215.100.13) 18.50.23 # pamaury: hehe. Considering the price I would need 3 Christmas! And I prefer real buttons over touchscreens :) 18.53.46 Join pamaury_ [0] (~pamaury@rockbox/developer/pamaury) 18.54.15 # lebellium_z3c: did I send you the new instructions to try to NW-WM1 ? 18.54.30 # The microphone is on the MDR-NC31. But they don't fit my ears well and don't sound very good. In the end I've used the NC for 2 days on my E580 and now use my usual IEm 18.54.47 # pamaury_: nope you didn't 18.55.59 Quit lebellium_z3c (Quit: Bye) 18.56.12 Join lebellium_z3c [0] (~AndChat73@80.215.100.13) 18.56.42 # lebellium_z3c: get g#1466, cd nwztools/scsitools/; make; sudo ./scsitools -r /dev/sdX get_dnk_nvp kas 18.56.43 # 3Gerrit review #1466 at http://gerrit.rockbox.org/r/1466 : 3nwztools/scsitool: add relaxed mode for nvp by Amaury Pouly 18.58.34 # pamaury_: thanks. You're not going to commit it shortly this time? I can give the patch link? :P 19.01.18 # no I'll wait this time :-p 19.03.03 Quit lebellium_z3c (Quit: Bye) 19.03.53 Join lebellium_z3c [0] (~AndChat73@80.215.100.13) 19.12.44 Quit paulk-blaze (Remote host closed the connection) 19.13.09 Join paulk-blaze [0] (~paulk@no3.u-bordeaux.fr) 19.15.26 Quit Moarc (Ping timeout: 258 seconds) 19.15.50 Join AndChat|736049 [0] (~AndChat73@80.215.100.13) 19.15.55 Quit AndChat|736049 (Read error: Connection reset by peer) 19.15.55 Quit lebellium_z3c (Read error: Connection reset by peer) 19.16.03 Join Moarc [0] (~chujko@a105.net128.okay.pl) 19.17.17 Join lebellium_z3c [0] (~AndChat73@80.215.100.13) 19.18.00 Join lebellium [0] (~chatzilla@89-93-179-5.hfc.dyn.abo.bbox.fr) 19.18.43 Join johnb2 [0] (~johnb2@p5B29683A.dip0.t-ipconnect.de) 19.19.33 Quit lebellium_z3c (Client Quit) 19.20.22 Join ulmutul [0] (~chatzilla@dslb-094-221-072-088.094.221.pools.vodafone-ip.de) 19.20.24 Quit paulk-blaze (Ping timeout: 272 seconds) 19.27.56 # Push time! I guess nobody objects against g#489, g#1404, g#1405, g#1406 and g#1407 (I warned you some days ago ;)) 19.28.02 # 3Gerrit review #489 at http://gerrit.rockbox.org/r/489 : 3midi: Recalculate (and rename) the note frequency table. by Frank Gevaerts 19.28.02 # 3Gerrit review #1404 at http://gerrit.rockbox.org/r/1404 : 3Midi Player: give button actions meaningful names by Sebastian Leonhardt 19.28.03 # 3Gerrit review #1405 at http://gerrit.rockbox.org/r/1405 : 3Midi Player: fix playback of buffer remains when seeking by Sebastian Leonhardt 19.28.04 DBUG Enqueued KICK fs-bluebot 19.28.04 # 3Gerrit review #1406 at http://gerrit.rockbox.org/r/1406 : 3Midi Player: fix premature stopping of audio buffer playback by Sebastian Leonhardt 19.28.05 # 3Gerrit review #1407 at http://gerrit.rockbox.org/r/1407 : 3Midiplay: only boost cpu in sensible code parts by Sebastian Leonhardt 19.29.03 # Build Server message: 3New build round started. Revision afd482f, 255 builds, 16 clients. 19.35.07 # pamaury_: I assume you wanted to write ./scsitool 19.39.04 # and what does -r mean? 19.39.15 # Build Server message: 3Build round completed after 612 seconds. 19.39.16 # Build Server message: 3Revision afd482f result: All green 19.44.00 # Build Server message: 3New build round started. Revision e05545b, 255 builds, 16 clients. 19.44.15 # nevermind, I should have read the code 19.44.33 # "-r/--relaxed" :) 19.53.37 # Build Server message: 3Build round completed after 576 seconds. 19.53.38 # Build Server message: 3Revision e05545b result: 14 errors 0 warnings 19.56.22 # Regarding the Virtualbox dev image, is 'make manual' supposed to work out of the box? For me it complains about pdflatex missing. When I launch the download of additional packages (as suggested), I get various http errors. 19.56.53 # probably not, pdflatex is quite big, not sure it's included in the virtual image 20.02.26 # Build Server message: 3New build round started. Revision e813c3f, 255 builds, 16 clients. 20.06.11 # johnb2: no, it's not, and I too didn't manage to install it (ubuntu version being too old). I eventually ended up creating my own VM image using a recent ubuntu version. 20.07.01 # you can update Ubuntu from the old VM image to download 20.07.31 # I will give it a try. 20.07.40 # the update manager tells me "14.04.5 LTS available" 20.07.52 # but as I only use it for Rockbox, I never updated itr 20.11.46 # Would the update of ubuntu be compatible with the compilers used in RB? 20.12.31 # Not being sure, I had declined the pop-up to update ubuntu just this morning ... 20.12.31 # Build Server message: 3Build round completed after 605 seconds. 20.12.32 # Build Server message: 3Revision e813c3f result: All green 20.13.12 # johnb2: I declined for the same reason. I didn't want to take any risk. I just don't know Ubuntu enough, I just want a working RB environment 20.14.23 Join paulk-blaze [0] (~paulk@no3.u-bordeaux.fr) 20.16.32 # i didn't test the midi stuff but it looks sensible to me and is easy to fix if some problem is found 20.16.49 Quit parchd (Ping timeout: 245 seconds) 20.18.44 # Build Server message: 3New build round started. Revision 69e9738, 255 builds, 16 clients. 20.19.03 # pamaury_: ""Your device is not supported. Please contact developers. "" 20.19.33 # lebellium: ah sorry, you need to add -s nw-wm1 20.19.36 # like before 20.20.07 # sudo ./scsitool -r -s nw-wm1 /dev/sdX get_dnk_nvp kas 20.20.08 # ? 20.22.11 Join shrizza_ [0] (~shrizza@oki-dc-urasoe01-187.glbb.ne.jp) 20.22.25 Quit tomflint (*.net *.split) 20.22.25 Quit shrizza (*.net *.split) 20.22.44 Join naleo [0] (~naleo@unaffiliated/naleo) 20.23.59 Join tomflint [0] (~tomflint@unaffiliated/tomflint) 20.24.21 # pamaury_: I'm not sure how I'm supposed to put 2 arguments together 20.24.39 # yes 20.27.04 # Build Server message: 3Build round completed after 501 seconds. 20.27.05 # Build Server message: 3Revision 69e9738 result: All green 20.37.01 *** Saving seen data "./dancer.seen" 20.44.26 # Build Server message: 3New build round started. Revision 5279d60, 255 builds, 16 clients. 20.46.10 Quit Strife89 (Ping timeout: 240 seconds) 20.48.09 Join Strife89 [0] (~quassel@adsl-98-80-197-191.mcn.bellsouth.net) 20.49.28 Quit johnb2 (Quit: Nettalk6 - www.ntalk.de) 20.49.48 Join thum [0] (~thum@www.vikings.net) 20.55.45 # Build Server message: 3Build round completed after 679 seconds. 20.55.46 # Build Server message: 3Revision 5279d60 result: All green 20.59.17 Join thum_ [0] (~thum@www.vikings.net) 21.01.15 Nick thum is now known as Guest54788 (~thum@www.vikings.net) 21.02.55 # bluebrother^: when you compile for windows, do you use mingw32 always or do you compile using msvc ? 21.03.42 Quit thum_ (Client Quit) 21.03.50 Join thum_ [0] (~thum@www.vikings.net) 21.03.54 Quit thum_ (Client Quit) 21.04.36 Join girafe [0] (~girafe@LFbn-1-11729-221.w2-7.abo.wanadoo.fr) 21.05.12 Quit paulk-blaze (Quit: Leaving) 21.05.38 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 21.05.43 Quit jhMikeS (Client Quit) 21.06.06 Join jhMikeS [0] (~jethead71@d192-24-173-177.try.wideopenwest.com) 21.07.00 # pamaury_: 21.07.02 # Model: Unknown 21.07.04 # Series: NW-WM1 Series 21.07.05 # 65 38 64 31 37 31 61 35 64 39 32 66 33 35 65 65 e8d171a5d92f35ee 21.07.07 # 64 39 36 35 38 63 30 33 66 62 39 66 38 36 61 31 d9658c03fb9f86a1 21.07.08 # 36 39 35 39 31 36 35 39 38 35 31 66 64 37 63 34 69591659851fd7c4 21.07.10 # 39 35 32 35 66 35 38 37 61 37 30 62 9525f587a70b 21.08.30 Join Jinx [0] (Dojo@unaffiliated/jinx) 21.09.04 # ouch, this is completely different 21.09.52 # either this is not the kas or Sony is using a completely different encryption or even format 21.10.34 # also this is weird, 60 bytes for a key is unusual 21.15.41 # ah 21.15.45 # was hoping for better news 21.16.37 # well the problem is that assuming this the "key", I have no clue as to what the cipher is 21.17.21 # and already in the devices (except WM1 it seems), this is seriously nonobvious 21.18.19 # Sony still seems to use the same format: MD5 hash at the beginning but then different cipher 21.20.59 # Can I solve rebase/merge conflicts from within gerrit? 21.22.15 # ulmutul: I don't think so but not sure 21.22.42 # lebellium: I guess we need someone to physical remove the flash and dump it :-/ 21.22.54 # or rather do it on a A30 21.23.25 # I can't reasonably ask a user to dump the flash from a €1000 device 21.23.36 # and there is the problem of skills to do it anyway 21.23.37 # did you find the service manual for A30 ? This is much cheaper, 21.24.26 # I didn't find the A30 service manual yet. Don't know if Sony published it and I missed it or if they didn't publish it yet 21.24.30 # ok, rebasing from git :) 21.25.43 # I agree that touching a 1000€ device is not really reasonable, better ask for a 200€ one ;) 21.26.02 # pamaury_: if you're very clean, you can buy it from Amazon (still in preorder though), dump the flash, and return it within 30 days `\o/ 21.26.25 # assuming it uses a similar board as before, they could open the device, remove the flash board, send it to me and I send it back 21.26.32 # well I'm not sure I'm *that* clean 21.27.10 # depends on how easy it is to open 21.27.21 # probably easier with the service manual for sure 21.27.37 # I'll try to find it again this weekend 21.27.41 Ctcp Ignored 1 channel CTCP requests in 0 seconds at the last flood 21.27.41 # * pamaury_ is probably sure that it's surely probably 21.28.18 # but actually how does it help you? It's written some useful numbers on the back? 21.28.23 # <[Saint]> ulmutul: no. 21.28.45 # to see if the flash is on a separate board 21.28.52 # if t's not, I don't have the tools to dump it 21.29.22 # no, I mean, how does it help you to actually remove the flash! 21.29.36 # what do you do then? 21.29.46 # I access it directly and dump its content 21.30.12 # which gives me access to the decryption tool and (hopefully) I can RE it 21.30.38 # ok, clear to me now 21.30.48 # the alternative is to find an exploit in Sony's code and manage to run some code with it 21.31.46 # or more likely, an exploit in an open source component used by Sony 21.31.56 # when upgrading the firmware, the device is automatically set to a special mode. May that help you? 21.31.57 # (since we don't have any code otherwise) 21.32.35 # not really because afaik, it does nothing if there is no valid firmware upgrade 21.33.22 # what would be helpful is the uboot mode and recovery modes that I suspect exists but I don't know how to interact with them, I think it needs a special cable 21.33.36 # ok 21.34.01 # pamaury_: the user told me he gets that when making a "get" 21.34.04 # Model: Unknown 21.34.05 # Series: NW-WM1 Series 21.34.07 # Destination: CEW2 (103) 21.34.08 # Sound pressure: 0 (off) 21.34.23 # is that reliable? 21.34.28 # that sounds plausible 21.35.04 # CEW2 with sound pressure off sounds strange to me 21.35.53 # apparently recently NW don't have sound pressure limitation anymore 21.36.05 # they only have a warning the first time you cross the threshold 21.36.10 # don't remember who told me that 21.36.14 # me 21.36.40 # but E580 and A10 are shipped with CEW2 SPS ON in Europe 21.37.04 # <[Saint]> In what world is the A30 a €1000? 21.37.18 # <[Saint]> Or has the ass fallen out of your economy again? 21.37.36 # WM1A and WMA1 are €1000 21.37.48 # minimum 21.37.58 # WM1Z* 21.38.07 # A30 is cheaper as pamaury said 21.38.18 # <[Saint]> Oh, right - I thought you were talking about A30. Which is only ~$900 NZD 21.38.20 # <[Saint]> Which is only about €650 21.38.46 # yes, but you know, usually $1000 = €1000 = £1000 21.39.03 # brands don't have the same exchange rate as the real economy 21.39.36 # <[Saint]> That is pretty much never a thing, at least in most of Australasia. 21.39.52 # <[Saint]> currency units don't scale like that for us. 21.40.02 # https://www.amazon.fr/s/ref=nb_sb_noss/254-6900800-7526163?__mk_fr_FR=%C3%85M%C3%85%C5%BD%C3%95%C3%91&url=search-alias%3Daps&field-keywords=sony+nwa35 €220 21.40.18 # the WM1 is super horrible to disassemble :-o and full of adhesive tape 21.40.38 # if the A30 is anywhere close to that, disassembling it will not be funny. Also the WM1 doesn't have a separate flash board 21.40.40 # <[Saint]> If you guys are getting fucked that hard on pricing it seems like you would have better luck shipping through Australasia or the Americas. 21.41.45 # I'm not even sure if the A30 and WM1 are based on the same soc as the older ones 21.41.46 # pamaury_: so probably the A30 is designed more or less the same way :S 21.41.51 # <[Saint]> Uuuuuuugh. Holy shit the WM1Z is a godawful looking device. 21.42.22 # <[Saint]> You'd think for $2.5K it would be a little less eye-bleedy. 21.43.34 # Build Server message: 3New build round started. Revision 1728565, 255 builds, 15 clients. 21.43.52 # pamaury_: there is a big jump in the linux kernel for the 1st time (v3.X.X). Looks like Sony changed everything from now on 21.44.27 # <[Saint]> wow...that's unexpected. 21.44.31 # urg, apparently Sony sold themselves to MediaTek 21.44.33 # <[Saint]> sony with a vaguely modern kernel. 21.44.46 # <[Saint]> unexpected indeed. 21.44.52 # WM1 seems to be using the infamously-horrible androidy kernel for MT8590 21.45.07 # lebellium: it's not the firsy 3.x kernel, far from it 21.45.42 # really? The A10 is based on v2.6 21.46.58 # hum actually you are right, they used to use 2.6.35 21.47.21 # anyway, WM1 and A30 are not based on the Emma Mobile soc anymore, they used MT8590 21.48.30 # <[Saint]> MT8590 throws a pretty massive spanner in the works. I know this from third party Android experience. But I guess things might be easier for you as you don't actually have to rebuild the kernel (which is practically impossible) for your purposes, do you? 21.49.05 # we don't rebuild the kernel on Sony's device anyway 21.49.33 # <[Saint]> Right. OK. That's what I was asking. If you did need to, that would be problematic. 21.49.40 # however it might make it easier if the MT8590 has an easily accessible hardware recovery mode that we can use 21.50.00 # I don't think anyone is insane enough to even try rebuilding a kernel provided by Sony 21.51.14 # <[Saint]> Well, I know of a couple of MT8590 kernel trees but I sincerely doubt any of them could be introduced into Rb with any good conscience. 21.51.15 # I know from experience that Sony's SCSI implemenation is pure crap and is easily crashed, this could potentially be used to run code 21.51.31 # Build Server message: 3Build round completed after 476 seconds. 21.51.32 # Build Server message: 3Revision 1728565 result: 5 errors 0 warnings 21.51.41 # [Saint]: Sony provides the code for the kernel \o/ Good luck building it though 21.52.24 # <[Saint]> The only ones I've seen personally, in terms of AOSP, are riddled with NDA references and references to proprietary assets. 21.53.00 # oh I'm sure this is one is very similar 21.53.27 # <[Saint]> grepping for NDA and proprietary in MTK sources you find in the wild is always amusing. 21.54.07 # * [Saint] is certain he doesn't need to relate this to pamaury_ 21.54.15 # but this is not super useful anyway because most Sony's stuff is not included in the code provided by Sony 21.54.25 # <[Saint]> right. 21.54.26 # oh I'm sure it's funny to read 21.54.34 # and very depressing 21.54.38 # <[Saint]> very. 21.54.45 # we leave in the dark age of information 21.55.23 # More user information, less information for user 21.57.13 # pamaury_: I definitely can't find the A30 service manual. Either they didn't publish it yet or use another URL pattern and then it's getting pratically impossible to guess which one 21.57.32 # I wonder if http://androidurdu.net/download-mediatek-sp-flash-tool-v5-1548-pc-windows/ 21.57.40 # can be used to dump the flash from WM1 21.58.04 # it's a MediaTek tool for flash stuff, but it could also read the flash maybe ? 21.58.57 # <[Saint]> if it is the one I'm thinking of, it is write only. 21.59.27 # <[Saint]> barring reading off some rudimentary boardinfo. 22.02.57 Quit jhMikeS (Ping timeout: 258 seconds) 22.11.31 # pamaury_: do you think it's safe to try a "set" with another destination code? 22.17.09 # Next thing to push: g#1291, g#1292 22.17.11 # 3Gerrit review #1291 at http://gerrit.rockbox.org/r/1291 : 3pacbox: clean-up screen size code by Sebastian Leonhardt 22.17.11 # 3Gerrit review #1292 at http://gerrit.rockbox.org/r/1292 : 3pacbox for small screens, up to 75x96 by Sebastian Leonhardt 22.17.24 # I'll give you some more days to review ;) 22.18.11 # Maybe someone can test it on an actual device in the meantime :) 22.19.58 # lebellium: I think 22.20.04 Quit Strife89 (Ping timeout: 255 seconds) 22.20.15 # in the worst case, one can set it to its original value 22.20.35 # also make sure to reset all the settings after a destination change 22.20.45 # but I cannot guarantee anything of course 22.20.50 # ok 22.20.57 Join Strife89 [0] (~quassel@adsl-98-80-196-198.mcn.bellsouth.net) 22.22.43 Join Strife1989 [0] (~quassel@adsl-98-80-181-144.mcn.bellsouth.net) 22.25.36 Quit Strife89 (Ping timeout: 248 seconds) 22.26.03 # pamaury_: so IIRC if the A30 is designed the same way as the WM1 (no separate chip for flash), there is no way to crack the key ? 22.26.35 # well we have the "key", apparently, but we don't know the cipher so yeah unlikely to crack this way 22.26.45 # we need a software exploit I would say, to run code on the device 22.27.32 Join Strife89 [0] (~quassel@adsl-98-80-190-246.mcn.bellsouth.net) 22.27.47 # This won't happen overnight and this can only be done with the device at hand 22.27.55 # <[Saint]> do they run their own operating system - or is it another of their android-y kludges? 22.28.00 # maybe when the port is finished we can have a more close look at the A30 22.28.04 # [Saint]: it's linux 22.28.44 # <[Saint]> Ah. Should be no lack of available exploits therein then one would posit. 22.28.50 Quit Strife1989 (Ping timeout: 248 seconds) 22.28.55 # well an android kernel for the A30 but still, busybox and all 22.30.00 # <[Saint]> then metasploit should make it its little bitch. 22.30.11 # [Saint]: sure there are exploits BUT 1) we have no code, like no binary at all. 2) we cannot run any code. However, this thing may have wireless connection 22.30.14 # metasploit ? 22.30.23 # <[Saint]> there's a bunch of busybox injection vulnerabilities I doubt they cater for. 22.32.07 # <[Saint]> but that assumes that you can get some degree of non-privelged access first. 22.32.58 # I don't have the device, but my guess is we need to first have some kind of access. Most likely are music/video format exploits, or browser exploits if there is wifi 22.33.15 Join Strife1989 [0] (~quassel@adsl-98-80-182-237.mcn.bellsouth.net) 22.34.47 # <[Saint]> if you can get a local shell, it's yours. 22.35.21 # <[Saint]> it's a pain in the tits about the kernel because if they're using an android-y kernel then the obvious thing to do would be repack the ramdisk. 22.35.50 # sony usually runs everything as root 22.36.24 Quit Strife89 (Ping timeout: 245 seconds) 22.36.33 # we just need to extract the few relevant bits that contain the encryption code and dump them 22.37.03 *** Saving seen data "./dancer.seen" 22.37.08 # <[Saint]> :-S 22.41.12 Join Strife89 [0] (~quassel@adsl-98-67-61-107.mcn.bellsouth.net) 22.41.50 # apparently they use http://oss.sony.net/Products/Linux/Audio/Download/NW-WM1A/FraunhoferAAC-2.5.7.tar.gz to decode AAC 22.41.58 # could be a source of bug ;) 22.42.10 Quit Strife1989 (Ping timeout: 248 seconds) 22.45.30 Quit Strife89 (Ping timeout: 240 seconds) 22.46.00 Join mutnai [0] (6db91733@gateway/web/freenode/ip.109.185.23.51) 22.46.09 Join Strife89 [0] (~quassel@adsl-98-80-182-189.mcn.bellsouth.net) 22.46.25 Quit mutnai (Client Quit) 22.47.44 Join paulk-collins [0] (~paulk@gagarine.paulk.fr) 22.51.14 Quit atsampson (Quit: time for a new irssi!) 22.51.32 Join atsampson [0] (~ats@cartman.offog.org) 22.58.21 Join Strife1989 [0] (~quassel@adsl-98-80-192-50.mcn.bellsouth.net) 23.00.47 Quit Strife89 (Ping timeout: 272 seconds) 23.02.31 # <__builtin> gevaerts: I haven't heard back from bagder or zagor regarding https for the buildmaster 23.03.16 # <__builtin> is there any reason not to just revert the offending lines and try to increment the revision whenever possible? 23.03.25 # <__builtin> *line, actually 23.03.56 # __builtin: if we haven't heard from them, we can't increase revision anyway, because we need to ask them to do that 23.04.27 # <[Saint]> __builtin: I think the problem was the assumption that someone or someones other than pamaury_ set up a build client in that time. 23.04.46 # <__builtin> yeah, but we can revert the line that causes it to fail and increment the revision later, right? 23.04.52 # <[Saint]> personally I think that is hilariously unlikely...but, hey. 23.04.58 # <__builtin> that fixes the problem in the meantime, doesn't it? 23.05.29 # <[Saint]> I suspect pamaury_ is the one and only person involved in this. 23.06.33 # <[Saint]> But the consensus, AFAIK, is that while that is a non-zero chance things are kinda fucky. 23.06.34 Quit Strife1989 (Ping timeout: 258 seconds) 23.07.25 # <[Saint]> I would personally opt for just doing the revert seeing as how it is almost an assured thing that the only person this actually affected was pamaury_ 23.07.25 # <[Saint]> but evidently people disagree. 23.07.51 Join Strife89 [0] (~quassel@adsl-98-67-58-18.mcn.bellsouth.net) 23.11.29 # I think reverting is a solution *in the mean time* 23.11.45 # it's just dumb if we revert and then re-apply a few days later 23.12.58 # <__builtin> we /could/ keep it as plain HTTP, but TLS does bring some added benefits (namely file integrity) 23.14.58 # I say we wait a little bit more, maybe ping them another time by email 23.15.04 # and if we get no answer, revert 23.15.19 # <[Saint]> __builtin: which isn't particularly relevant. 23.15.19 # <[Saint]> We don't publish hashes and we don't have a reproducible build system. 23.16.15 # <[Saint]> if one or either of those things were true I might be tempted to agree. 23.16.19 # <[Saint]> *one or both, sorry 23.24.14 Quit n3m9 (Read error: Connection reset by peer) 23.33.40 Quit [Saint] (Ping timeout: 246 seconds) 23.39.27 # pamaury_: the user reports he set to CN (China) ON and he now got the "High gain" option, making the volume much louder 23.40.12 # interesting... 23.41.47 # Sony is full of surprises 23.42.02 # lebellium: could you ask the user one last thing ? 23.43.07 # I honestly don't get exactly what SPS if for. I noticed the warning "check the volume level" at volume 14/30 only comes with CEW2 destination but I don't hear a volume difference between SPS ON and OFF 23.43.19 Join Mihail [0] (252d6881@gateway/web/cgi-irc/kiwiirc.com/ip.37.45.104.129) 23.44.03 # lebellium: I think SPS is unused on newer Sony's 23.44.15 # could you ask him to run 23.44.15 # sudo ./scsitool -r -s nwz-wm1 /dev/sdc get_dnk_nvp mid 23.44.27 Join alexweissman [0] (~alexweiss@c-68-51-123-75.hsd1.in.comcast.net) 23.44.39 # honestly the volume is even a bit higher on my E580 than on my Japanese A850 23.45.07 # I think it made a difference for him on WM1 only because of the high gain option which is not on lower range devices 23.45.43 # pamaury_: what does the added "mid" stand for? 23.46.16 # model id 23.46.35 # so I can added the model id to the list 23.46.43 # at least one of them 23.50.56 # ok 23.51.38 Join Strife1989 [0] (~quassel@adsl-98-67-61-87.mcn.bellsouth.net) 23.51.48 # saratoga: are you have datasheet for as3534? 23.54.33 Quit Strife89 (Ping timeout: 255 seconds) 23.55.12 # Mihail: no i don't think so 23.55.38 # just as3543 23.56.50 # which is on google anyway