--- Log for 07.07.113 Server: leguin.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 27 days and 14 hours ago 00.03.10 Quit y4n (Quit: Do you like hurting other people?) 00.09.33 Quit kevku (Ping timeout: 245 seconds) 00.27.26 Quit melmothX (Quit: #.#) 01.35.04 Quit n1s (Quit: Ex-Chat) 01.51.09 *** Saving seen data "./dancer.seen" 01.52.52 Quit pamaury_ (Ping timeout: 264 seconds) 01.54.57 Quit lebellium (Quit: ChatZilla 0.9.90 [Firefox 23.0/20130703181823]) 02.06.06 Quit shamus (Read error: Connection reset by peer) 02.06.19 Join shamus [0] (~shmaus@ip-206-192-195-49.marylandheights.ip.cablemo.net) 02.55.43 Quit ender` (Quit: It's amazing how the the human mind does not process the the fact I used the the word "the" twice each time.) 03.38.16 Quit Rower (Quit: Hmmm...) 03.51.12 *** Saving seen data "./dancer.seen" 04.02.15 # <[Saint]> Bwahahahaha....yeah, ...nah, that's not gonna happen. 04.03.09 # <[Saint]> buflib is *so* entrenched in the heart of Rockbox, it is basically impossible to cast the bugger out without a LOT of backbreaking. 04.04.00 # <[Saint]> I would be very curious to see if some of these strange issues just magically fix themselves if it were to no longer be present, as I suspect they might. 04.05.42 # <[Saint]> There's no "cut buflib out" its basically "go back in time to pre-buflib, and then massage back in a shit-tonne of commits, many of which rely on it" 04.05.49 # <[Saint]> ...so, nope! :) 04.07.41 # <[Saint]> I have a sneaking suspicion that if one were to core out either buflib, the theme engine, or both, many active flyspray tasks would become irrelevant. 04.08.22 # <[Saint]> I like these types of suspicion, though, I get to have an opinion whilst knowing that it would be a massive amount of work for anyone to prove me wrong ;) 04.54.31 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.54.32 Quit pixelma (Disconnected by services) 04.54.34 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.54.39 Join amiconn_ [0] (amiconn@rockbox/developer/amiconn) 04.54.40 Quit amiconn (Disconnected by services) 04.54.42 Nick amiconn_ is now known as amiconn (amiconn@rockbox/developer/amiconn) 05.14.06 Quit [7] (Disconnected by services) 05.14.11 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 05.23.32 Quit belak (Ping timeout: 264 seconds) 05.28.29 Join belak [0] (~belak@facebook/engineering/belak) 05.37.27 Quit prof_wolfff (Ping timeout: 268 seconds) 05.51.14 *** Saving seen data "./dancer.seen" 05.57.12 Quit Guest11127 (Ping timeout: 245 seconds) 06.18.35 Join Guest11127 [0] (Slayer@c-69-143-178-62.hsd1.va.comcast.net) 06.32.14 Nick yosafbridge` is now known as yosafbridge (~yosafbrid@li125-242.members.linode.com) 06.33.20 Quit Epicanis (Quit: to sleep, perchance to dream) 06.43.23 Nick SuperBrainAK is now known as DormantBrain (~andy@shared02.balt01.cd.2g2u.net) 06.52.01 Join Zarggg [0] (~zarggg@24.229.140.62.res-cmts.sm.ptd.net) 07.08.46 Join shai [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 07.10.38 Quit shai (Client Quit) 07.17.52 Join kevku [0] (~kevku@2001:0:c38c:c38c:1046:9510:3d69:bea5) 07.27.54 # [Saint]: I know what to do. No need to kill buflib. I just don't like stepping all over everything in sight, even if I want to., 07.28.46 # <[Saint]> So we can test "the old ways", by disconnecting buflib, and leaving it in place? 07.29.01 # <[Saint]> I didn't see that as being possible, or rather, more work than just gutting it out. 07.29.27 # <[Saint]> also, agreed, either way involves touching pretty much everything. 07.30.45 # I think tweaking the design is the way. Many problems were there before it that are still there but it does introduce its own difficulties. 07.51.16 *** Saving seen data "./dancer.seen" 08.17.05 Quit sakax (Read error: Connection reset by peer) 08.27.21 Quit bluebrother (Disconnected by services) 08.27.26 Join bluebrother [0] (~dom@rockbox/developer/bluebrother) 08.34.54 Join Guinness` [0] (Slayer@c-69-143-178-62.hsd1.va.comcast.net) 08.36.49 Join kiwicam [0] (~quassel@101.98.163.139) 08.39.12 Join derf_ [0] (~derf@fuzzyneural.net) 08.39.28 Join uwe_ [0] (~uwe_@dslb-088-064-051-171.pools.arcor-ip.net) 08.42.55 Join lahwran_ [0] (~lahwran@python/site-packages/lahwran) 08.43.44 Quit Guest11127 (*.net *.split) 08.43.44 Quit user890104 (*.net *.split) 08.43.44 Quit lahwran (*.net *.split) 08.43.45 Quit uwe__ (*.net *.split) 08.43.46 Quit derf (*.net *.split) 08.43.46 Quit Guest83379 (*.net *.split) 08.43.47 Nick derf_ is now known as derf (~derf@fuzzyneural.net) 08.44.44 Join sakax [0] (~sakax@d8D862C77.access.telenet.be) 08.44.46 Quit lahwran_ (Excess Flood) 08.48.46 Quit kiwicam (Remote host closed the connection) 08.56.16 Join kiwicam [0] (~quassel@101.98.163.139) 09.07.33 Quit copper (Quit: ZNC - http://znc.in) 09.12.52 Join user890104 [0] (Venci@login.6bez10.info) 09.41.56 Quit belak (Quit: belak) 09.51.18 *** Saving seen data "./dancer.seen" 10.02.25 Join belak [0] (~belak@facebook/engineering/belak) 10.04.21 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 10.13.58 Join copper [0] (~copper@unaffiliated/copper) 10.14.43 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) 10.41.35 # [Saint]: where did your buflib rant tonight come from? 10.42.40 # <[Saint]> I'm just sick of seeing all these random issues that came to light (perhaps, by chance) at approximately the same time. 10.42.56 # <[Saint]> Its hard to see this as what seems to be an accepted issue now. 10.43.37 # <[Saint]> Its nice to know it isn't /just/ me that noticed the timing. 10.44.08 # <[Saint]> The rant came from how insanely hard it would be to actually confirm this. 10.45.19 # the timing with regards to what? 10.45.30 # some recent change? 10.45.49 # <[Saint]> primarily the adoption of buflib by the theme engine. 10.45.54 # <[Saint]> this isn't a recent thing. 10.46.32 # [Saint]: which issue? 10.46.57 # <[Saint]> "themes cause " 10.47.23 # can you point to a specific fs task or forum post? 10.47.25 # is that over a year old? 10.48.32 # <[Saint]> lebellium seems to be the master of crafting themes that manage to break USB. 10.48.38 # <[Saint]> This seems to be the primary issue. 10.48.54 # lol 10.48.55 # I know about the radioart and rds text bugs (the first is related to, but not directly caused by, buflib) 10.49.07 # <[Saint]> Another user was in here a few days ago trying to help uys with the N2G USB stuff, and changing themes affected the behaviour there as well. 10.49.44 # <[Saint]> the primary issue is "themes somehow break USB" 10.49.51 # <[Saint]> and its been popping up more and more recently. 10.50.04 # would be worth trying if my fix for the radio art also helps for USB bugs 10.50.15 # <[Saint]> Oh, certainly. 10.50.39 # <[Saint]> FWIW, I'm not blaming you. So, don't read into that. I appreciate the work, immensely. 10.50.52 # <[Saint]> I just think, in hindsight, it may have gone a little too quickly. 10.51.40 # <[Saint]> The problem for those trying to look into it is that it is quite complicated, and touches basically everything. 10.51.49 # [Saint]: how much of that (themes break USB) is people repeating what they read here? 10.52.06 # i.e. a rampant rumor 10.52.39 # [Saint]: buflib itself is not the problem (it's pretty solid in my experience), but using it properly indeed adds complexity 10.52.53 # <[Saint]> copper: I couldn't say, really. But a lot of it is "confirmed" by the user with trial and error. Many users I have not seen here before, although, it may be under a different name. 10.53.19 # <[Saint]> ie. "USB works with theme A, but not with themes B, C, and D" 10.53.30 # the playback code is using it improperly which causes radioart problems (seemingly unrelated, but the code is connected through the global buffer management) 10.53.35 # <[Saint]> which, just should happen. It shouldn;t be possible. 10.54.06 # <[Saint]> *shouldn't 10.54.33 # well it seems that my Fuze+ theme download count increased dramatically after I rewored the theme files to potential fix USB breakage 10.54.39 # reworked* 10.54.47 # potentially 10.54.49 # geez 10.55.11 # <[Saint]> I wanted to attempt to go back in tiome to pre-buflib, and see if I could massage the work til now back into it...but that is an incredibly daunting task. 10.55.12 # I wish there were stats 10.55.25 # <[Saint]> So much so I looked at it for a few minutes and burst out laughing. 10.56.06 # thinking about it, yes my radio art fix could very well fix the usb problem as well 10.56.19 # what is radio art? 10.56.32 Join n1s [0] (~n1s@nl118-168-30.student.uu.se) 10.56.33 Quit n1s (Changing host) 10.56.33 Join n1s [0] (~n1s@rockbox/developer/n1s) 10.56.33 # <[Saint]> station art for FMS 10.56.49 # where does the art come from? 10.57.02 # <[Saint]> ie. "when tuner_freq == foo; display bar" 10.57.08 # <[Saint]> theme assets. 10.57.17 # [Saint]: the skin engine should be easy to disconnect from buflib 10.57.43 # <[Saint]> you and I have varying degrees of ease, apparently ;) 10.57.51 # it has the classic allocation mechanism still in, e.g. checkwps doesnt include buflib 10.57.57 # my theme went from 100+ over a few months, to 900+ in like a month 10.58.01 # downloads* 10.58.13 # <[Saint]> I thought about just the theme engine alone, but I couldn't discount it just being broken in general across the board. 10.58.28 # <[Saint]> so I wanted to cut it out completely. 10.58.53 # no, that's not easy, in the same way it wasn't easy to add it to the codebase :) 10.59.00 # <[Saint]> Indeed. 10.59.51 # [Saint]: please point people with theme/usb problems to http://gerrit.rockbox.org/r/#/c/483/ 10.59.59 # <[Saint]> I understand how my earlier rant may have seemed like "Gah! Bloody kugel...bloody breakin' things!", but that wasn't the case, sorry. I was just frustrated. 11.01.57 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 11.02.18 # <[Saint]> buflib seems to be the new tagcache. :) 11.02.31 # <[Saint]> "Errrr....I'm not touching that!" 11.03.08 Quit akaWolf (Quit: my exit) 11.05.21 Join polemon [0] (~polemon@g224099012.adsl.alicedsl.de) 11.05.28 # <[Saint]> jhMikeS seemed as though he may have an idea of what is going awry, but he is often quite secretive/vague about what he is working on until we see the WIP, so I dunno. 11.06.19 # <[Saint]> After many combined hours of staring at it, I have only a very basic understanding of it myself. 11.06.52 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) 11.07.00 Join melmothX [0] (~melmoth@unaffiliated/melmothx) 11.07.08 Join olspookishmagus [0] (~pookie@91.132.63.143) 11.08.41 # gah, stupid whitespace-only changes :/ 11.13.11 # [Saint]: can you reproduce the usb problems? 11.14.37 # <[Saint]> I have been unable to, sadly. I suspect *nix Vs. Windows may be at play here. 11.15.07 # <[Saint]> I attempted to the other day (this was N2G specific), but I couldn't reproduce what OP was seeing. 11.16.00 # <[Saint]> That is another difficulty. Assuming it *is* buflib related, it may not /just/ be specific to the theme, but also the exact revision of the build, and whatever else resides in the buffer at the time. 11.16.51 # <[Saint]> ...a way to dump the current device state and play with it in an emulator would be *awesome*. 11.18.05 # <[Saint]> It is quite a nasty cycle. Those that see the problem usually can't debug it, and those who can debug it can't see it. :-S 11.20.16 Quit akaWolf (Read error: Connection reset by peer) 11.21.38 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) 11.25.56 Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 11.26.36 # I read the logs :) 11.26.48 # so I should try your patch kugel? 11.26.57 # yea 11.28.01 # <[Saint]> Since you are a 5th Dan Blackbelt in creating themes that break USB, yes. :) 11.28.57 # Hehe ;) 11.30.08 # I'll try with Clip Zip after my breakfast. But I already see the same issue as usual: I just plugged my Clip Zip to the PC and this time it works while last times I tried it froze with my theme. Random random.... :( 11.32.09 Join Rower [0] (husvagn@v-413-alfarv-177.bitnet.nu) 11.33.06 # from the main menu with no music playback it just worked. But now I try again while playing music and from WPS and now it freezes as usual. Nice. I'll see if this patch helps 11.34.01 # <[Saint]> That seems to confirm my thinking that whatever is currently in the buffer has an effect on the behavior. 11.35.10 # haha, good news! I'm 99% sure i've identified the reason why the fuze+ locks up after bootloader USB mode :) 11.35.25 # <[Saint]> ...it is bufib? 11.35.29 # * [Saint] runs... 11.35.30 # <[Saint]> :P 11.35.50 # ;) not really :p 11.37.14 # it's related to power management, the init sequences changes the cpu speed before calling power management. But on imx233, changing the frequency requires power related changes, and something goes wrong apparently 11.40.02 # lebellium: does it freeze on connect or on disconnect 11.40.03 # ? 11.46.44 # kugel: both? I mean it won't connect (sometimes starting to get recognized in Windows Explorer then fails) and when I disconnect it, it's stuck, I have to reset the device 11.47.04 # ok 11.47.27 # I try your patch in a few minutes 11.50.23 # hey guys 11.50.44 # did you manage to work on the USB issue? 11.51.22 *** Saving seen data "./dancer.seen" 11.53.13 # lebellium: can I download the theme? 12.01.37 # rayboradio on the Classic is a known offender 12.02.14 # kugel: http://themes.rockbox.org/index.php?searchtheme&searchword=lebellium%20Samsung-like&searchtype=name 12.02.58 # lebellium: nice link 12.04.07 Quit onder` (Read error: Connection reset by peer) 12.04.20 # you've been busy! 12.05.11 # ^^ 12.05.17 # <[Saint]> Someone likes Rammstein *way* too much ;) 12.05.36 # <[Saint]> that, and VBR mp3... 12.05.39 # that's marketing. To identify any of my theme in one second :D 12.06.57 # but now a common joke on some forums is that I only have one album on my mp3 players ahaha 12.07.09 # <[Saint]> s/album/track/ 12.07.26 # <[Saint]> There's no proof you have the rest of the album ;) 12.12.52 Quit pamaury (Ping timeout: 248 seconds) 12.15.44 # lebellium: another question, since you maintain a theme for so many targets: What would help to reduce your workload and enable sharing a single code base for many/all themes? 12.15.59 Join onder` [0] (~onder@24.244.89.228) 12.17.12 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 12.17.29 # hm, the mouse navigation doesnt quite work in the clipzip sim 12.17.44 # I use more or less the same code for any of my themes. But I'm not sure it's really clean, easy to understand. It's not the cabbiev2 quality standard :) 12.18.01 # <[Saint]> kugel: nor does trying to reproduce USb errors in the SIM, I'm afriad. 12.18.15 # <[Saint]> I have *never* been able to get USb to behave anywhere near the real thing. 12.18.30 # * [Saint] wonders why he always manages to type USb 12.18.47 # <[Saint]> USB 12.22.25 # is the theme/buflib thing the ONLY known cause of USB problems? 12.22.42 # s/known/suspected/ 12.22.56 # <[Saint]> I'm not even sure anyone can say with absolute certainty it is the cause. 12.24.19 # in other words: have people reported USB problems with cabbiev2? 12.25.06 # kugel: the patch doesn't fix the issue, sorry 12.25.21 # lebellium: okay, that's unfortunate 12.25.26 # <[Saint]> copper: yes. 12.25.47 # I'm not aware of reports with cabbiev2 12.25.55 # <[Saint]> but I'm not sure what that has to do with your prior question, nor how it could be another wording thereof. 12.26.19 # <[Saint]> cabbie still uses the theme engine/buflib just as any other theme does. 12.26.25 # well I thought it was a given that cabbiev2 didn't exhibit any of the theme-related issues 12.26.37 # <[Saint]> why? 12.26.44 Quit melmothX (Read error: Connection reset by peer) 12.26.48 # past conversations 12.26.56 # I guess I got it wrong 12.27.19 # <[Saint]> It does happen. I guess it relates to the rather small footprint cabbie has. 12.27.43 # I assume it doesnt happen with cabbie until it's on FS 12.28.05 # I'm not hunting bugs based on rumors 12.28.51 # *PANIC* playlist_resume (); 00M when disconnecting it. That's a new one for me :D 12.29.06 Join melmothX [0] (~melmoth@unaffiliated/melmothx) 12.29.12 # <[Saint]> polemon was playing with this the other day. 12.29.34 # <[Saint]> He initially stated that cabbieV2 *didn't* display any issues, but then later discovered it in fact...did. 12.29.34 # lebellium: so it didn't connect but also didnt freeze? then this panic occured on disconnect? 12.30.16 # does it connect fine with other themes? 12.30.39 # [Saint]: I don't even know who polemon is 12.30.44 # kugel: this time it connected properly but when disconnecting, instead of getting stuck on the USB screen, it directly displayed this PANIC message 12.30.55 # <[Saint]> logged channel. 12.31.06 # lebellium: okay, that's an improvement :) 12.31.28 # it means the buffer is still owned by someone else when the playlist code tries to grab it 12.31.50 # without the patch two pieces of code would access the buffer at the same time 12.32.40 # <[Saint]> polemon actually discovered something that isn't so easy to see on many targets, that in many cases, USB behaved fine if USB was inserted *before* booting the device. 12.33.18 # yes there may be some improvements with this patch but unfortunately I cannot check that very well since it's totally random. Over the last 15 minutes I connected it to the computer 10-15x and sometimes it works, sometimes not, in the same conditions :( 12.33.55 # <[Saint]> Yes, that's about as far as we got the other day "Oh! Ohh! I think there's a pattern...oh, wait, nope...shit." 12.34.18 # lebellium: can you add that diff on top? http://pastie.org/8117758 12.34.58 # [Saint]: please log such observations on the relavant FS tasks (or open new ones) 12.35.26 # <[Saint]> Isn't that basically heresay? 12.35.35 # I'm not sure what I am supposed to do with that kugel, I'm still a git/linux/rockbox newbie 12.35.40 # <[Saint]> I can only direct those seeing the problem to do so. 12.36.01 # you can't expect people to read all backlogs when they (re-)visit such stuff later on 12.36.44 # [Saint]: yes, I meant to say that 12.36.51 # <[Saint]> I don't. But is it not trivial to grep logs when given the information to do so? 12.37.14 # no it isnt, it also isnt trivial to get a local copy of all logs 12.37.25 # <[Saint]> I certainly don't read all the backlog. No way I expect anyone else to. 12.38.08 # kugel: how do I add this diff? just "cd Rockbox" and paste that text in the terminal? 12.38.15 # just saying that these observations have to be logged where they're relevant and can be found easily 12.38.22 # irc logs aren't suitable for this 12.38.41 # lebellium: download as raw and use patch to apply 12.38.57 # or edit the file manually, it's a one-liner :) 12.39.08 # <[Saint]> lebellium: download as raw, save as "name_here>.patch; apply with patch 12.39.20 # <[Saint]> or, apply it by hand (more difficult) 12.39.40 # [Saint]: no need to repeat me :P 12.39.43 # funny, I would say changing a line in a file is easier for me than applying a patch in the terminal :p 12.40.01 # <[Saint]> I was just going to correct that, usually it isn't a single line ;) 12.40.10 # <[Saint]> apparently I'm also lagging. 12.48.23 # if what I suspect is true than this is a stone-age old bug (older than buflib) 12.50.49 # <[Saint]> Oh? 12.51.04 # lebellium: does that line help? 12.51.06 # <[Saint]> Do tell, now my connection seems to have sorted itself out. 12.51.51 # kugel; I'm trying to mount Clip Zip to install the new build, but somehow even with cabbiev2 it won't mount now :) 12.52.17 # <[Saint]> OF, rolo from sdcard? 12.52.31 # <[Saint]> There's options man. Options! :P 12.53.00 # OF means 20 min database update. Never lol 12.53.55 # when I last used the OF it didnt update when you boot with the cable inserted and you could hard-reset it between unmounting/safe removal and unplugging the cable 12.55.04 # the clipzip is as3525 like older clips right? 12.57.30 # kugel: amsv2 like clipv2 and clip+ 12.57.44 # so as3525 + tiny changes 12.57.52 # ah yea, I remember 12.58.12 # it's a long time ago since I was into that :) 12.58.21 # biggest change is as3543 PMU + different USB and SD controllers 12.58.29 # me too but it's printed deep in my mind :P 13.00.25 # different USB controller? 13.00.34 # amsv2 controller is the same than nano2g 13.01.02 # kugel: next time I don't listen to you :P "Refreshing your media" and it takes forever with 8 + 32GB 13.01.15 # funman: aren't there problems with that controller (or the driver)? 13.01.29 # lebellium: up on boot? 13.01.34 # yes... 13.01.44 Quit polemon (Ping timeout: 256 seconds) 13.02.20 # hm, don't know. all samsa OFs I've used skipped that when the cable was inserted at boot 13.02.22 # kugel: yes it crashes sometimes but works most of the time 13.02.58 # perhaps the connect problems lebellium reports are caused by that rather than buffer/buflib/skin engine issues? 13.03.24 # also [Saint] said the nano2g has similar issues? 13.04.02 # <[Saint]> don't they share the same USB controller? 13.04.27 # <[Saint]> Its shared with at least one other target, iirc. 13.04.40 # <[Saint]> N2G USB being broken has been a known issue for some time, though. 13.10.23 Quit kevku (Ping timeout: 245 seconds) 13.12.30 # lebellium: still refreshing? ::( 13.12.48 # updated RB build and now "refreshing media" while disconnecting. Arghhhh I'll kill Sansa people 13.14.01 # saratoga: can you please refer to the original task when you close ones as duplicate? 13.14.57 # lebellium: the rolo-from-sd idea would have been quicker 13.15.13 # probably. If I new what that means :D 13.15.28 # knew* 13.15.43 # put the new rockbox.sansa on the sd and "play it" from the old rockbox installation 13.15.59 # or copy it over to the .rockbox folder and reboot 13.17.19 # ah! 13.17.21 # ok good to know 13.19.10 # (you could also have removed the sd while booting the OF so the refresh doesnt last as long) 13.24.17 # 1st try: worked. 2nd try: doesn't mount, and PANIC playlist_resume while disconnecting 13.24.43 # okay 13.25.08 Join kevku [0] (~kevku@2001:0:c38c:c38c:2445:cf4b:3d69:be3e) 13.25.20 # lebellium: can you retry with that line changed to "sleep(HZ*10);"? 13.26.57 # that's a 10s sleep so don't be surprised if the UI doesnt do anything for that long after disconnect 13.28.16 # ok 13.43.47 Quit olspookishmagus (Quit: All for nothing) 13.47.43 # kugel; 1st try: 10 seconds then OK, 2nd try: 10 seconds then Panic playlist_resume 13.47.47 # while disconnecting 13.48.02 # did it connect? 13.48.10 # yes both times 13.48.27 # gevaerts: ping 13.49.06 # and now 3rd time: won't connect "undefined instruction". I take a break, these USB issues make me crazy 13.49.17 # hm, I'm surprised it connected in the 2nd case 13.49.38 # I can see how it panics when it didnt properly connect, but if it connected it shouldnt panic 13.50.11 # undefined instruction? Now that's really weird 13.50.41 # and sometimes it replaces my status bar with the failsafe status bar to connect 13.50.57 # it's another behaviour every time I connect it 13.51.25 *** Saving seen data "./dancer.seen" 13.53.35 # I confirm it may mount properly but when disconnecting, it displays panic playlist_resume after 10s 13.53.39 # I got it a 2nd time 14.03.55 # lebellium: alright, I need the help of gevaerts now, thanks for your testing 14.06.19 # you're welcome. But given the fact it's a highly random issue, I don't think it's possible to fix it, unless a dev has a Clip Zip and faces the same issue. 14.08.29 # Only [Saint] talked about that until now. All other reports are from normal users like me, not devs. 14.09.06 # <[Saint]> Of course its possible to fix. 14.09.10 # there aren't so many devs anymore :( 14.09.36 # <[Saint]> It never used to happen, which means we were either A: getting it right, or B: not pissing it off as much as we are now. 14.09.46 # <[Saint]> the trick is getting it back to one of those states :) 14.10.12 # bisecting over a year's worth of commits? 14.10.13 # <[Saint]> Also, sadly, yes. 14.10.15 # should be fun! 14.10.29 # <[Saint]> In terms of active committers, this project is in reasonably bad shape. 14.10.39 # bisecting random behavior isnt useful 14.10.58 # right 14.11.04 # <[Saint]> We need new blood. But DAPs are no longer fun. 14.11.16 # they're not? 14.11.31 # [Saint]: Rockbox has been ported to Clip Zip since late 2011 now, almost 2 years. I've been reported the theme issues since then. Nothing new on themes breaking USB for 2 years. I really think that if a dev faced the issue, that would be easier to fix. 14.11.39 # <[Saint]> Seeing as how a phone can do everything, and more, no..not really. 14.12.20 # many smartphones are still low capacity, and many have bad output 14.12.31 # low capacity without sdcard expansion* 14.12.48 # <[Saint]> data plans+cloud storage 14.13.09 # streaming is impractical in many situations 14.13.10 # copper: most phones are good enough 14.13.26 # (if not most situations) 14.13.58 # I mean there are many reasons people still buy DAPs 14.14.13 # even though that includes Android and iOS DAPs 14.14.23 # <[Saint]> Right. But those people are A: aging, and/or B: enthusiasts. 14.14.32 # <[Saint]> look around your various hifi communities. 14.14.41 # <[Saint]> Those that frequent them are aging. 14.16.16 # lebellium: I think it's expected that the default statusbar is shown 14.16.50 # kugel: AFAIK, no. A 14.16.58 # iirc skins are disabled during usb because they require access to the storage (those with custom fonts at least) which cannot be done 14.17.10 # skins are not disabled during USB 14.17.59 # [Saint]: indeed, I guess that younger people also have lower storage needs 14.18.00 # <[Saint]> it _should_ dump what it needs into the buffer when the screen changes. 14.18.12 # <[Saint]> No need to access the disc for the theme during connection. 14.18.14 # lebellium: okay, but the fonts are unloaded 14.18.23 # no idea how that works if the skin uses that font 14.18.34 # <[Saint]> It seems to "Just Work" 14.18.43 # <[Saint]> My themes maintain userfont during USB. 14.18.59 # I don't know how it works but with any of my theme, only the menu list is replaced by the rockbox connection logo. The background and my status bar (with fonts) is still there 14.19.08 # [Saint]: the code clearly unloads all fonts 14.19.22 # <[Saint]> Yay for bugs, then. 14.19.45 # and it calls skin_unload_all(), guess what that does 14.20.04 # <[Saint]> well it certainly doesn't clear the .sbs...I know that much :) 14.20.10 # <[Saint]> perhaps it _should_. 14.20.14 # <[Saint]> ...it doesn't, though. 14.20.21 # that's at least the intention of the code 14.21.18 Quit AlexP (Remote host closed the connection) 14.21.28 # <[Saint]> Why does it need to dump the font? We know *exactly* what needs to be displayed, couldn't it just keen N many glyphs in the buffer? 14.21.33 # <[Saint]> Or, all of them, for that matter? 14.21.44 # <[Saint]> I don't understand why it would need to access the disc. 14.22.13 # you can't determine if the glyhps are in cache 14.22.19 # <[Saint]> Aha. 14.22.24 # yeah the number of active devs has decreased recently, mostly because we have no new devs. I guess people just stopped using mp3 players 14.22.36 # the skin can display arbitrary strings, you cannot know if the glyphs needed for that will be accessible 14.22.38 # <[Saint]> git hurt us a lot, too. 14.22.39 Join AlexP [0] (~alex@rockbox/staff/AlexP) 14.22.43 # <[Saint]> which is *fucking* sad. 14.22.47 # <[Saint]> ...pardon my French. 14.23.03 # git has nothing to do with it 14.23.19 # <[Saint]> I argue otherwise. 14.23.39 # <[Saint]> Several very active commiters fell right off the map, as soon as we switched. 14.23.47 Quit sakax (Quit: Leaving) 14.24.07 Join sakax [0] (~sakax@d8D862C77.access.telenet.be) 14.24.12 # hum, who did ? 14.24.12 # lebellium: I loaded samsung like onto my fuzev2 14.24.30 # <[Saint]> kugel: skins in general can, but the USB screen can't. We know exactly what will be displayed there. 14.24.33 # there is some full screen image that overlays the menu 14.25.01 # [Saint]: if the sbs is visible during the usb screen it it can display what it wants 14.25.19 # <[Saint]> and if it is supposed to disallow the .sbs, it makes it even easier to predict what is required. 14.25.26 # <[Saint]> heh, timing. 14.26.32 # kugel: http://imageshack.us/a/img826/2456/qggh.jpg and http://imageshack.us/a/img542/9601/blj6.jpg. That's how it connects randomly 14.27.02 # <[Saint]> you can clearly see userfont there. 14.27.12 # yes, I can see that on my fuzev2 as well 14.27.16 # <[Saint]> and (duh...no need to say this) the .sbs 14.27.26 # <[Saint]> So, something is awry. 14.27.36 # <[Saint]> I had no idea it was supposed to dump userfont. 14.29.09 # lebellium: what's this full screen image is flashing over the menu? 14.29.34 # ? 14.29.40 # <[Saint]> smells like improperly layered viewports fighting with screen updates. 14.30.29 # isn't it just the display's low refresh rate? 14.30.56 # like when you photograph a 60Hz CRT display 14.31.04 # The main difference between my themes and almost any other is that I use %?mp<%VI(Z)|%VI(X)> and a "mini-player" 14.31.48 # my fuzev2 has frozen upon screendump :\ 14.32.00 # <[Saint]> copper: kugel is talking about on-device, not the visible tearing in the images supplied. 14.32.53 # lebellium: is the fuzev2 version out-of-date or something? 14.33.06 # no, it works perfectly but look at the description 14.33.10 # you need a recent build 14.33.14 # due to the high amount of fonts loaded 14.33.21 # gavaerts changed the limit for me 14.33.22 # :D 14.33.24 # gevaerts* 14.33.28 # oh a reboot helped against the flashing 14.33.45 # <[Saint]> Odd. 14.34.22 # <[Saint]> lebellium: ...how many did you need? 0_o 14.35.00 # [Saint]: it's because of the iRiver remote! H320 and Fuze share the same themes 14.35.12 # well, I cannot reproduce the connect-failure or panic on disconnect on this device 14.35.34 # <[Saint]> if you're just using it to display numerics and the occasional symbol, it may have a much smaller footprint if you used bitmaps. 14.36.17 Quit AlexP (Remote host closed the connection) 14.36.20 # <[Saint]> by "how many did you need" I meant "how many fonts, per theme, do you require in the worst case?" 14.36.21 # well I don't remember exactly but feel free to look at my code and see how crazy it is :D 14.37.06 # <[Saint]> I remember doing an audit of your theme(s) many, many moons ago. But a lot has changed since then. 14.37.17 # <[Saint]> And I would wager it has been re-written a few times since. 14.38.00 # I guess I have about 10 fonts loaded for the Fuze theme 14.38.19 # yowza 14.38.23 # <[Saint]> That's...a....lot. 14.38.51 Join AlexP [0] (~alex@rockbox/staff/AlexP) 14.39.14 # two fonts are loaded 14.39.15 # It's like 2 themes 14.39.27 # Remote theme = CLip Zip them 14.39.28 # e 14.39.33 # + the main theme 14.39.41 # Clip+ * 14.40.05 # <[Saint]> So...10 fonts per screen, or, in total? 14.40.11 # in total! 14.40.13 # not per screen 14.40.15 # <[Saint]> the latter makes it a lot easier to imagine. 14.40.43 # * kugel still counts 2 14.40.50 # kugel: heh? 14.41.03 # <[Saint]> the worst case look to be the .fms, which is using 3, unless I'm mistaken. That's not so bad. 14.41.24 # FMS uses big %Fl(8,34 Ubuntu [Bold].fnt) 14.41.26 # that doesn't help 14.41.28 # <[Saint]> are you limiting the glyphs loaded? 14.41.32 # 4 after entering the fms 14.41.41 # <[Saint]> Ah, I missed one. 14.42.44 # But indeed USB connection works better with my theme for fuze than Clip Zip. So I don't think it's related to all fonts loaded 14.43.36 # <[Saint]> are you using the 'glyphs' tuple for the %Fl command? 14.43.45 # seems like I need a clipzip to reproduce it 14.43.54 # I don't know what it is [Saint] 14.43.54 # <[Saint]> "%Fl(ident,filename,glyphs)" 14.44.45 # <[Saint]> That prevents the theme from trying to load *every* glyph the font has. It keeps only N amount of glyphs cached. 14.45.14 # * lebellium googling "glyph" 14.45.15 # every glyph is never loaded 14.45.24 # glyph = character 14.45.26 # sign 14.45.30 # by defaults it's capped to whatever fits into 10k or so 14.45.38 # <[Saint]> So, if you were only displaying the chars Aa-Zz, you could safely limit it to 56 glyphs 14.45.48 # <[Saint]> its 200 or so by default, iirc. 14.45.58 # <[Saint]> or some size limit. 14.46.02 # <[Saint]> whatever comes first. 14.47.28 Quit jhMikeS (Ping timeout: 264 seconds) 14.47.33 # <[Saint]> With large fonts, this can reduce the memory usage by a reasonably amount. Not terribly important for some targets, crucial for others. 14.48.00 # I'll have a look when I have some time 14.48.45 # <[Saint]> If you know, for example, that you will only be displaying the numbers 0-9 and the symbols : and %, you could cap it at 12. 14.49.14 # my Fuze+ skin uses 309KiB 14.49.16 # for battery percentage I could do that indeed 14.49.39 # <[Saint]> Otherwise it may waste memory better used for the audio buffer caching glyphs that will never be displayed. 14.50.39 # <[Saint]> On the Classic, ...meh. On some targets, with 2MB of RAM total, every bit counts. :) 14.51.10 # <[Saint]> (there's other targets to add to the "don't care about RAM" list...but, ...anyway) 14.51.40 # the Fuze+ seems to have about 60MB like the Classic 14.53.15 # not sure if those are MiBs 14.59.34 Join dfkt [0] (dfkt@unaffiliated/dfkt) 15.01.21 # the fuze+ has 64MiB of ram 15.02.34 # kugel: pong 15.09.02 # gevaerts: there seems to be some usb problems on the clipzip 15.09.38 # it struggles with connecting, and it appears that usb_storage_disconnect() isn't always called 15.10.54 # how can it happen that this isnt always called (but usb_storage_init_connection() is) 15.10.57 # ? 15.12.39 Quit Rower (Quit: Hmmm...) 15.13.01 Join kaputnik_ [0] (~kaputnik@port-92-206-28-8.dynamic.qsc.de) 15.14.20 Quit kaputnik__ (Ping timeout: 256 seconds) 15.15.21 # kugel: the only way I see is that usb_thread() never sees USB_EXTRACTED 15.16.31 Join dan991199 [0] (dan991199@d216-121-238-253.home3.cgocable.net) 15.16.33 # or it sees it but usb_state != USB_INSERTED 15.17.20 Part dan991199 15.18.18 # Hm, yes 15.18.27 Join Rower [0] (husvagn@v-413-alfarv-177.bitnet.nu) 15.18.58 # I don't see how that could happen though 15.19.02 # but that doesnt look possible 15.20.08 # lebellium reported that even when usb storage connects fine then he can see the panicf() I inserted into playlist.c (it triggeres when it cannot get the audio buffer which is last-owned by usb_storage.c) 15.21.18 # hum, there is something fishy on the Zen X-Fi2: it has the same Mobile DDR chip as the Zen X-Fi3 but it fails when the ram is run at 133MHz whereas it works on the Zen X-Fi3 :-/ 15.21.38 # lebellium: can you apply that patch as well (on top of the others): http://pastie.org/8118125 ? 15.22.19 # pamaury: different modules 15.22.19 # ? 15.24.19 Quit Rower (Quit: Hmmm...) 15.26.08 Join Rower [0] (husvagn@v-413-alfarv-177.bitnet.nu) 15.26.14 Join prof_wolfff [0] (~prof_wolf@62.83.50.196.dyn.user.ono.com) 15.27.20 # no :( same parameters, everything is the same 15.27.42 # gevaerts: if it doesnt see USB_EXTRACTED how can the usb screen see SYS_USB_DISCONNECTED? 15.28.51 # Hmmm 15.29.40 # because that's what happens, the usb screen thinks disconnected and calls playlist_resume() where the panic occurs 15.30.17 # Did you push those changes not to call audio_get_buffer() yet? 15.30.40 # not to master, but lebellium runs that (from gerrit) 15.31.23 # with that a call to usb_storage_disconnect() is required to release the audio buffer 15.32.10 # Is usb_core_exit() called? 15.32.23 # I can't tell from here :p 15.32.42 # * gevaerts asks lebellium instead :) 15.33.02 # * kugel doesnt think he can easily tell that either 15.34.49 # kugel: I can apply that patch but later this afternoon or evening. I need a break for now USB makes me crazy :) 15.35.08 # The thing is, the old usb_storage_disconnect() doesn't do anything, so we don't really reliably know that it ever got called properly 15.35.20 # yeah 15.35.49 # however it seems to be the case on my fuzev2 15.36.20 # ok 15.36.35 # So it's likely not to be an obvious bug in usb_core.c 15.36.39 # BTW kugel: I also have issues with USB connection and my theme on Fuzev1 (tried today) while I thought USB was more reliable on V1 than V2 15.36.46 Quit Rower (Quit: Hmmm...) 15.38.55 Join Rower [0] (husvagn@v-413-alfarv-177.bitnet.nu) 15.46.26 # gevaerts: the implementation of usb_enable() is the same 15.49.36 # [Saint]: have you tried lebellium's theme on one of your nano2g? 15.51.29 *** Saving seen data "./dancer.seen" 16.01.46 Quit Rower (Quit: Hmmm...) 16.07.32 Quit akaWolf (Ping timeout: 248 seconds) 16.10.40 Join Rower [0] (husvagn@v-413-alfarv-177.bitnet.nu) 16.17.43 Quit Rower (Quit: Hmmm...) 16.19.59 Join Rower [0] (husvagn@v-413-alfarv-177.bitnet.nu) 16.21.28 Join lorenzo92 [0] (~chatzilla@host70-107-dynamic.40-79-r.retail.telecomitalia.it) 16.27.59 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) 16.33.32 Quit n1s (Ping timeout: 276 seconds) 16.43.51 Quit Rower (Quit: Hmmm...) 16.47.37 Join Rower [0] (husvagn@v-413-alfarv-177.bitnet.nu) 16.47.51 Nick dv__ is now known as dv_ (~quassel@chello080108009040.14.11.vie.surfer.at) 16.51.38 Quit melmothX (Quit: #) 16.55.45 Join ender` [0] (krneki@foo.eternallybored.org) 17.05.58 Quit lorenzo92 (Ping timeout: 256 seconds) 17.14.52 Quit Rower (Quit: Hmmm...) 17.17.43 Join Rower [0] (husvagn@v-413-alfarv-177.bitnet.nu) 17.21.43 Quit Rower (Client Quit) 17.23.01 Join Rower [0] (husvagn@v-413-alfarv-177.bitnet.nu) 17.27.01 Quit Rower (Client Quit) 17.28.22 Join Rower [0] (husvagn@v-413-alfarv-177.bitnet.nu) 17.31.21 Quit Rower (Client Quit) 17.32.39 Join Rower [0] (husvagn@v-413-alfarv-177.bitnet.nu) 17.51.31 *** Saving seen data "./dancer.seen" 17.51.46 # To all fuze+ users: could you try the latest build and tell me if you still have the freeze after usb bootloader mode ? 17.52.18 Quit Rower (Quit: Hmmm...) 17.53.20 # pamaury: what's that? Plugging it while powered off, then powering it on? 17.54.06 # yes, power off, plug usb then unplug, it should boot and most probably freeze. I just committed a potential fix 17.54.19 Join Rower [0] (husvagn@v-413-alfarv-177.bitnet.nu) 17.59.21 # it turns on while plugged, displays "bootloader usb mode" 17.59.30 # when plugged in* 17.59.57 # it stays on that screen while plugged in 18.00.22 # yeah, then unplug it 18.00.32 # now it boots 18.00.38 # and seems to be working fine 18.00.56 # now redo the same except that you should only let it plugged a few seconds 18.01.16 # turn off, plug in, wait 3 seconds, unplug? 18.01.48 # yes 18.02.11 # works fine 18.02.51 # are you using the latest build ? 18.02.53 # yes 18.03.00 # good 18.03.02 # built myself 18.03.15 # now can you retry with an older one ? 18.03.16 # I ran git pull --rebase 18.03.22 # ok 18.03.35 # say 10 commits before head 18.04.44 # 130605 good enough? 18.05.38 # yes 18.06.00 # yup, freezes on the boot screen with the logo at the top and the build version at the bottom 18.06.33 # good, so that's indeed a fix, thanks 18.06.38 # np 18.07.42 # this has a been a long running issue, it's good that I finally fixed it 18.08.44 # good job :) 18.26.26 Join lorenzo92 [0] (~chatzilla@host70-107-dynamic.40-79-r.retail.telecomitalia.it) 18.26.32 Quit lorenzo92 (Client Quit) 18.29.23 Quit liar (Ping timeout: 248 seconds) 18.30.29 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 18.36.43 Quit liar (Ping timeout: 264 seconds) 18.44.16 Join lorenzo92 [0] (~chatzilla@host70-107-dynamic.40-79-r.retail.telecomitalia.it) 18.44.45 # I'm rewriting the packer for YP-R0 (R1 too) to be fully open (and much more fast too ^^) 18.45.10 # once I figure out how to mess with a cramfs on windows, i will be able to insert the player into rbutil :) 18.47.02 # why do you need to mess with cramfs ? 18.47.50 Quit Scall (Read error: Connection reset by peer) 18.48.19 Join Scall [0] (~chat@unaffiliated/scall) 18.48.37 # because I need to modify some data in the cramfs of the player in order to boot rockbox 18.49.15 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 18.49.25 # i found an interesting option for cramfs tools but I don't understand what's its porpouse, it correctly appends a previous image but i don't know if it's intended to *not* doing any merge... 18.49.33 # in fact, it doesn't 18.50.43 # I guess a cramfs image is compressed ? 18.51.34 # hum yeah 18.51.37 # it should be 18.52.12 # the problem are permissions on windows. alternatively, if possible, a small ram disk would be the solution ^^ 18.54.07 Quit liar (Ping timeout: 264 seconds) 18.56.18 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 19.22.53 Quit kevku (Ping timeout: 245 seconds) 19.25.29 Quit Rower (Quit: Hmmm...) 19.27.16 Join Rower [0] (husvagn@v-413-alfarv-177.bitnet.nu) 19.28.11 Quit Scall (Read error: Connection reset by peer) 19.30.43 Quit pamaury (Ping timeout: 248 seconds) 19.31.13 Quit Rower (Client Quit) 19.31.18 Join Scall [0] (~chat@unaffiliated/scall) 19.36.08 Quit onder` (Ping timeout: 256 seconds) 19.36.22 Join kevku [0] (~kevku@2001:0:c38c:c38c:3d:4be4:3d69:beaa) 19.41.16 Join joshumax [0] (~joshumax@c-76-121-250-99.hsd1.wa.comcast.net) 19.41.20 # hello 19.41.25 Join Rower [0] (~husvagn@v-413-alfarv-177.bitnet.nu) 19.42.17 Join onder` [0] (~onder@24.244.89.228) 19.47.19 # hello 19.48.43 # oh hi 19.49.09 # Just a quick question, does anyone remember the old "zvue" media player? 19.50.00 # kugel: I just tried your latest patch. I can't reproduce the Panic resume_playlist issue when disconnecting, but I don't know if it's just a coincidence or if it fixed something :) 19.50.58 # But now I have more often "*Panic* stkov usb" when connecting. Maybe just a coincidence too 19.51.35 *** Saving seen data "./dancer.seen" 19.52.21 # hm interesting 19.54.16 # I guess that also explains the undefined instruction error you saw earlier 19.56.11 # lebellium: please add this patch http://pastie.org/8118689 and see if it does anything 19.57.14 # ok. I'll do it in about 40min, brb 19.57.54 # stkov is evil 20.13.14 Quit Scall (Ping timeout: 276 seconds) 20.14.47 Join Scall [0] (~chat@unaffiliated/scall) 20.31.06 Quit kevku (Ping timeout: 260 seconds) 20.42.13 Quit Rower (Read error: Connection reset by peer) 20.43.01 Join Rower [0] (husvagn@v-413-alfarv-177.bitnet.nu) 20.43.53 Join kevku [0] (~kevku@2001:0:c38c:c38c:1cea:1955:3d69:beaa) 20.59.43 Join krabador [0] (~krabador@unaffiliated/krabador) 21.05.04 # kugel: I just got a "undefined instruction" while connecting but no more stkov usb so far 21.09.34 Nick DormantBrain is now known as SuperBrainAK (~andy@shared02.balt01.cd.2g2u.net) 21.19.19 Quit Guinness` (Ping timeout: 264 seconds) 21.33.15 Quit Rower (Quit: Hmmm...) 21.34.41 Join Rower [0] (husvagn@v-413-alfarv-177.bitnet.nu) 21.35.41 Quit lorenzo92 (Ping timeout: 256 seconds) 21.40.16 Quit kiwicam (Remote host closed the connection) 21.44.45 Join z180 [0] (~chatzilla@ip-109-45-62-26.web.vodafone.de) 21.45.06 Join einhirn [0] (Miranda@bsod.vpn.tu-clausthal.de) 21.47.21 # lebellium: really strange 21.47.31 # lebellium: does the panic still happen on disconnect? 21.48.36 # I haven't seen it for some time now. 21.49.10 # does it still freeze? 21.50.02 # on disconnect 21.50.10 # sometimes but becoming rare. Disconnecting works better overall. But connecting is still quite unstable 21.50.44 # but it's not fixed yet? 21.50.56 # i.e. the freeze is still there in some cases 21.51.00 Quit liar (Read error: No route to host) 21.51.37 *** Saving seen data "./dancer.seen" 21.52.16 # After applying your last 2 patches, I guess it still froze 2/xx times when disconnecting. I don't know if I can say it's fixed yet. But looks better to me overall 21.52.56 # meh 21.53.22 # and IIRC the 2 times it still froze, it did not mount well before 21.54.00 # at least the panic is gone 21.54.11 # seems to be the case indeed 21.54.12 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 21.58.37 Quit Scall (Read error: Connection reset by peer) 21.59.29 Quit kaputnik_ (Ping timeout: 256 seconds) 21.59.48 Join Scall [0] (~chat@unaffiliated/scall) 22.10.41 Join Guest11127 [0] (~Slayer@c-69-143-178-62.hsd1.va.comcast.net) 22.13.55 Join kaputnik_ [0] (~kaputnik@port-92-206-28-8.dynamic.qsc.de) 22.22.58 # hm, who's the clipzip maintainer (if any)? 22.23.19 # bertrik 22.23.25 # and/or funman 22.24.21 # funman: ping 22.29.11 Quit y4n (Quit: Today is the perfect day for a perfect day.) 22.30.19 Join jhMikeS [0] (~jethead71@d192-24-174-117.try.wideopenwest.com) 22.30.19 Quit jhMikeS (Changing host) 22.30.19 Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) 22.51.32 Join lorenzo92 [0] (~chatzilla@host201-108-dynamic.44-79-r.retail.telecomitalia.it) 23.12.32 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 23.26.06 Quit mrtux (Quit: gtg) 23.26.38 Join mrtux [0] (~mrtux@unaffiliated/mrtux) 23.27.00 Quit einhirn (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) 23.30.57 Quit Rower (Quit: Hmmm...) 23.31.03 Join musiklover [0] (58d7727e@gateway/web/freenode/ip.88.215.114.126) 23.31.06 # hi 23.34.28 # i would like to get a music-player that can connected via USB to the pc where is acts as a connected mass storage device, that i can mounted it's FS, copy/delete music. When playingin music i would like to browse on a folder baysis. The player should ignore id-tags. is there such a player (like meizu m6 was one) that can run rockbox and does rockbox offer the mentioned features? 23.39.43 Quit Zarggg (Ping timeout: 264 seconds) 23.44.42 # are there chances that craetive zen player will get rockbox? 23.47.16 Quit bertrik (Ping timeout: 246 seconds) 23.51.40 *** Saving seen data "./dancer.seen" 23.53.26 # pamaury: the xor key is a little different with respect to the z5 one, now I understand why it wasn't working ^^ 23.57.02 Quit kevku (Ping timeout: 245 seconds) 23.57.58 # Is there a rockbox compatible device in a formfactor like this: http://skattertech.com/2007/12/creative-introduces-32gb-zen/ or this https://en.wikipedia.org/wiki/Meizu_M6_miniPlayer