--- Log for 16.06.113 Server: leguin.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 6 days and 14 hours ago 00.05.49 Quit melmothX (Quit: #) 00.05.56 Quit dewlap (Read error: Connection reset by peer) 00.06.20 Join dewlap [0] (~dewlap@2001:5c0:1000:a::88f) 00.09.04 Quit bertrik_ (Read error: Connection reset by peer) 00.09.20 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 00.20.44 Quit shamus (Read error: Connection reset by peer) 00.21.18 Join shamus [0] (~shmaus@ip-206-192-195-49.marylandheights.ip.cablemo.net) 00.27.48 Quit dewlap (Read error: Connection reset by peer) 00.28.13 Join dewlap [0] (~dewlap@2001:5c0:1000:a::88f) 00.30.19 Quit joshin (Quit: Gotta stop the kids from rioting) 00.38.43 Part zaphee 01.11.04 Quit n1s (Quit: Ex-Chat) 01.40.01 *** Saving seen data "./dancer.seen" 02.07.05 # does rockbox support any other fs than fat32? 02.07.14 # no 02.07.34 # well fat16 :) 02.08.04 # okay :( 02.17.46 # Build Server message: 3New build round started. Revision d561017, 217 builds, 21 clients. 02.20.43 Join Epicanis [0] (~yaaic@67.231.69.99) 02.24.33 # Build Server message: 3Build round completed after 408 seconds. 02.24.34 # Build Server message: 3Revision d561017 result: All green 02.27.45 Join Strife89 [0] (~Strife89@2602:306:250e:8d79:9de1:baa6:9227:7232) 02.28.01 Quit ender` (Quit: I just built a crontab that builds crontabs on another box, so it can wake up the first box in time for it to run its crontabs :D) 02.29.09 Quit pamaury (Ping timeout: 256 seconds) 02.30.56 # how do i try a patch from gerrit? 02.31.01 # cherry pick or one of the other options? 02.31.22 Join b1101 [0] (~b@108.61.47.139) 02.35.59 # cherry pick is usually the best 02.44.14 Quit Strife89 (Quit: Reboot.) 03.20.22 Quit bertrik (Remote host closed the connection) 03.32.43 Quit Epicanis (Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org) 03.40.02 *** Saving seen data "./dancer.seen" 04.02.25 Join kilroy [0] (~dewlap@2001:5c0:1400:a::2eb) 04.03.20 Quit krabador (Quit: Bah...) 04.07.01 Quit dewlap (Ping timeout: 245 seconds) 04.38.16 Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) 04.42.59 Quit amiconn (Disconnected by services) 04.42.59 Join amiconn_ [0] (quassel@rockbox/developer/amiconn) 04.42.59 Quit pixelma (Disconnected by services) 04.43.00 Join pixelma_ [0] (pixelma@rockbox/staff/pixelma) 04.43.02 Nick pixelma_ is now known as pixelma (pixelma@rockbox/staff/pixelma) 04.43.03 Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) 05.28.37 Quit mrtux (Quit: rebooting) 05.30.41 Join mrtux [0] (~mrtux@unaffiliated/mrtux) 05.32.01 Quit [7] (Disconnected by services) 05.32.10 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven) 05.40.04 *** Saving seen data "./dancer.seen" 05.45.10 Join TheSphinX_ [0] (~briehl@pD9FBBB20.dip0.t-ipconnect.de) 05.48.39 Quit TheSphinX^ (Ping timeout: 252 seconds) 06.10.15 Quit froggyman (Ping timeout: 276 seconds) 06.15.41 Join froggyman [0] (~froggyman@unaffiliated/froggyman) 06.26.24 Join shai_ [0] (~Shai@l192-117-110-233.cable.actcom.net.il) 06.31.02 Nick shai_ is now known as shai (~Shai@l192-117-110-233.cable.actcom.net.il) 06.32.51 Quit shai (Quit: Leaving) 06.43.49 Quit Raptors (Read error: Connection reset by peer) 06.55.01 Join Raptors [0] (~whoneedsa@216-58-33-203.cpe.distributel.net) 07.33.11 Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) 07.40.05 *** Saving seen data "./dancer.seen" 08.06.17 Quit kevku (Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/) 08.29.24 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf) 09.12.58 Join advcomp2019_ [0] (~advcomp20@65-131-177-93.sxct.qwest.net) 09.12.58 Quit advcomp2019_ (Changing host) 09.12.58 Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) 09.15.17 Join dokan_ [0] (~minatani@ac250006.ppp.asahi-net.or.jp) 09.16.08 Quit dokan (Ping timeout: 264 seconds) 09.16.09 Quit mystica555 (Ping timeout: 264 seconds) 09.16.09 Quit preglow (Ping timeout: 264 seconds) 09.16.14 Join preglow_ [0] (thomj@skrotnisse.pvv.ntnu.no) 09.16.25 Join mystica555 [0] (~mystica55@71-218-206-169.hlrn.qwest.net) 09.16.42 Quit advcomp2019 (Ping timeout: 264 seconds) 09.25.13 Join melmothX [0] (~melmoth@unaffiliated/melmothx) 09.28.16 Join mt [0] (~quassel@197.35.178.147) 09.28.39 Nick mt is now known as Guest95238 (~quassel@197.35.178.147) 09.40.09 *** Saving seen data "./dancer.seen" 09.46.55 Join pretty_function [0] (~sigBART@123.252.212.101) 09.49.18 Join n1s [0] (~n1s@rockbox/developer/n1s) 09.53.27 Quit Guest95238 (Ping timeout: 256 seconds) 09.55.53 Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) 10.20.05 Quit mc2739 (Read error: Connection reset by peer) 10.20.11 Join mc2739_ [0] (~mc2739@rockbox/developer/mc2739) 10.28.53 Join stoffel [0] (~quassel@pD9E40DD8.dip0.t-ipconnect.de) 10.32.37 Join bertrik [0] (~quassel@rockbox/developer/bertrik) 10.33.05 # morning 10.33.10 # indeed 10.33.32 # gevaerts: awake yet? 10.34.13 # I think I found a bug in the usb stack 10.34.31 # \o/ 10.35.07 # <[Saint]> He didn't say he'd fix it... ;) 10.35.21 # probably not a big deal 10.36.09 # any USB bug is a big deal! 10.36.11 # but the fix is simple 10.41.36 Quit tchan (Quit: WeeChat 0.4.1) 10.41.50 # the bug probably affects the way LUNs are recognised on rockbox storage 10.51.23 Join lorenzo92 [0] (~chatzilla@host109-106-dynamic.20-79-r.retail.telecomitalia.it) 10.51.30 Quit kevku (Ping timeout: 260 seconds) 10.52.29 Join mt [0] (~quassel@196.218.41.112) 10.52.54 Nick mt is now known as Guest73236 (~quassel@196.218.41.112) 10.56.10 Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) 10.57.12 Quit Guest73236 (Ping timeout: 245 seconds) 11.01.08 Join ender` [0] (krneki@foo.eternallybored.org) 11.04.05 Join mt` [0] (~quassel@196.218.41.112) 11.20.21 Quit kevku (Ping timeout: 245 seconds) 11.30.45 Quit lorenzo92 (Ping timeout: 252 seconds) 11.34.36 Quit Gallomimia (Ping timeout: 276 seconds) 11.35.55 Join Gallomimia [0] (~gallo@key.cha0sgaming.net) 11.39.33 Quit stoffel (Ping timeout: 252 seconds) 11.40.10 *** Saving seen data "./dancer.seen" 11.41.11 Quit Gallomimia (Ping timeout: 245 seconds) 11.43.26 Join Gallomimia [0] (~gallo@key.cha0sgaming.net) 12.06.29 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 12.23.49 Quit Gallomimia (Ping timeout: 252 seconds) 12.26.37 Join Gallomimia [0] (~gallo@key.cha0sgaming.net) 12.39.12 Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) 12.42.48 Quit pretty_function (Remote host closed the connection) 12.43.04 Quit bluebrother (Disconnected by services) 12.43.09 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother) 12.44.47 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 12.46.17 Quit fs-bluebot (Ping timeout: 264 seconds) 12.46.47 Join kaputnik [0] (~kaputnik@port-92-206-120-112.dynamic.qsc.de) 12.47.45 Join fs-bluebot [0] (~fs-bluebo@g227184105.adsl.alicedsl.de) 13.07.25 Quit kevku (Ping timeout: 245 seconds) 13.10.58 Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) 13.19.22 Quit n1s (Quit: Ex-Chat) 13.21.33 Quit y4n (Quit: HOLY SHIT! WE'RE ALL JUST LIVING ON A GINORMOUS FUCKING SPINNING ROCK FLOATING THROUGH SPACE CIRCLING A BIG FUCKING BALL OF FIRE!!!) 13.25.34 Join y4n [0] (~y4n@unaffiliated/y4ndexx) 13.29.53 Nick mt` is now known as mt (~quassel@196.218.41.112) 13.30.00 Quit mt (Changing host) 13.30.00 Join mt [0] (~quassel@rockbox/developer/mt) 13.39.54 Quit copper (Quit: ZNC - http://znc.in) 13.39.58 Quit kevku (Ping timeout: 260 seconds) 13.40.12 *** Saving seen data "./dancer.seen" 13.40.55 Join copper [0] (~copper@unaffiliated/copper) 13.46.04 Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) 13.47.15 Quit mt (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 13.47.36 Join mt [0] (~quassel@196.218.41.112) 13.47.50 Quit mt (Changing host) 13.47.50 Join mt [0] (~quassel@rockbox/developer/mt) 13.51.37 Part mt 13.55.11 Join mt [0] (~quassel@rockbox/developer/mt) 14.06.00 Join TheLemonMan [0] (~LemonBoy@ppp-4-51.26-151.libero.it) 14.06.00 Quit TheLemonMan (Changing host) 14.06.00 Join TheLemonMan [0] (~LemonBoy@unaffiliated/thelemonman) 14.06.37 # bertrik: can you elaborate on this usb bug ? 14.35.26 # pamaury: variable allocation_length is not used when handling SCSI_REPORT_LUNS, I posted a patch at http://gerrit.rockbox.org/r/#/c/488/ 14.35.38 # Unlikely that this is an actual problem though 14.36.54 # There are three packet lengths involved: the length in the CBW, the length in field allocation length of the SCSI request, and the actual length of the SCSI_REPORT_LUNS response 14.37.17 # indeed, I don't think that actually happen but it's always better to handle it the right way 14.37.18 # as far as I understand, we should send back data with a length of the minimum of those three 14.37.43 # I would need to rerereread the spec to check 14.38.24 # I'm not completely sure anymore what the 'length' field in the CBW means when asking for data, if it's a maximum length or the actual expected length 14.39.07 # I'll run my scsi analyser on it to check what are the values on a real life transfer 14.41.30 Join mt` [0] (~quassel@rockbox/developer/mt) 14.44.50 Quit mt (Ping timeout: 260 seconds) 14.50.49 Join krabador [0] (~krabador@unaffiliated/krabador) 14.58.13 Nick mt` is now known as mt (~quassel@rockbox/developer/mt) 15.10.03 Join lebellium [0] (~chatzilla@lns-c10k-ld-02-m-212-194-176-149.dsl.sta.abo.bbox.fr) 15.21.14 Join stoffel [0] (~quassel@pD9E40DD8.dip0.t-ipconnect.de) 15.30.12 Join darkham_ [0] (~krabador@host172-183-dynamic.19-79-r.retail.telecomitalia.it) 15.31.58 Quit krabador (Ping timeout: 260 seconds) 15.33.22 Quit kevku (Ping timeout: 260 seconds) 15.38.49 # Is there any chance that I/O activity inside the Fuze+ could affect the display? 15.39.01 # I'm seing some kind of refresh rate issue 15.39.26 # some light flickering of sorts 15.39.37 # I also noticed that some time ago copper 15.40.14 *** Saving seen data "./dancer.seen" 15.40.37 # SanDisk really dropped the ball with the Fuze+ 15.41.00 # I'm suspecting bad management 15.41.05 # poor decision making 15.41.19 Join mt` [0] (~quassel@rockbox/developer/mt) 15.41.55 # I still love it though! 15.42.15 # I really don't know how to solve the screen flicker issue, I don't think it's I/O related. At best it could be related to the touchpad but it seems to happen only rarely 15.42.22 # I don't, that's why I did not report the light flickering issue, I don't use it enough to bother me :D 15.42.42 # pamaury: well I was wondering if it was a hardware issue 15.43.17 # there is no doubt that the screen that they put in there is of bad quality 15.43.34 # I don't know, i've never seen this issue in the OF (although I never really used it so maybe I missed it). So it seems to be rockbox related but that doesn't help 15.43.40 Quit mt (Ping timeout: 245 seconds) 15.44.08 # the Fuze+ has the best color screen of any Sansa released. I don't tell you how bad is the C200 or Clip Zip screen compared to Fuze+ 15.44.17 # I'm doing some heavy reading on the Fuze's microsdxc card, I'll check if the flickering stops (or slows down) when my I/O operation is completed 15.44.44 # right now it's very constant 15.45.09 # At some point I thought this issue could be related to the DC-DC not being able to sustain the 3.3V IO rail but I'm not so sure now 15.46.07 Join Horscht [0] (~Horscht@xbmc/user/horscht) 15.46.11 # ah screw it, it's taking too long 15.46.37 # pamaury: ok, yup, it's definitely activated by I/O on the sdxc card 15.46.45 # I can reproduce it at will 15.47.18 # lemme try with the internal flash memory now 15.47.19 # I get the issue without microsd card 15.48.46 # same thing 15.50.18 # ah indeed, there is a slight flicker on I/O, but that's really light compared to the hard flicker that sometimes happen 15.52.51 # to be honested, I had never noticed this before ! 15.52.54 # *honest 15.53.26 Join tchan [0] (~tchan@lunar-linux/developer/tchan) 15.53.50 # I'm gonna try again with the OF 15.54.38 # yeah that would help 15.55.41 # wtf 15.55.58 # as soon as I plugged it in, running the OF, it rebooted under Rockbox 15.56.07 Quit darkham_ (Quit: Bah...) 15.56.46 # did it again 15.56.59 # it doesn't happen with OF, no flickering 15.57.58 # I can't manage to test it with the OF 16.06.21 Quit pamaury (Read error: No route to host) 16.07.32 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 16.10.06 Join krabador [0] (~krabador@unaffiliated/krabador) 16.21.39 Join mrtux_ [0] (~colin@unaffiliated/mrtux) 16.24.28 Quit mrtux (Quit: WeeChat 0.4.1) 16.24.29 Nick mrtux_ is now known as mrtux (~colin@unaffiliated/mrtux) 16.26.35 Join mrtux_ [0] (~mrtux@unaffiliated/mrtux) 16.32.48 Quit mrtux (Quit: ZNC - http://znc.in) 16.32.52 Nick mrtux_ is now known as mrtux (~mrtux@unaffiliated/mrtux) 16.36.08 Quit mrtux (Quit: WeeChat 0.4.1) 16.36.37 Join mrtux [0] (~mrtux@unaffiliated/mrtux) 16.47.38 # bertrik: I'm fairly sure you're correct 16.48.18 Join SeaWeed [0] (~SeaWeed@c-107-4-148-121.hsd1.va.comcast.net) 16.48.31 Part SeaWeed 16.49.45 # thanks 16.50.59 # unlikely to cause a problem, just a little more safe. cppcheck complained about a variable being set but unused 16.51.09 # * gevaerts nods 16.58.37 Quit Horscht (Quit: quit) 17.01.53 Quit stoffel (Remote host closed the connection) 17.13.04 Join n1s [0] (~n1s@nl118-168-30.student.uu.se) 17.13.04 Quit n1s (Changing host) 17.13.04 Join n1s [0] (~n1s@rockbox/developer/n1s) 17.25.46 Quit krabador (Quit: Bah...) 17.27.21 Join krabador [0] (~krabador@unaffiliated/krabador) 17.40.16 *** Saving seen data "./dancer.seen" 17.48.06 Quit kaputnik (Ping timeout: 268 seconds) 18.16.07 Nick mc2739_ is now known as mc3739 (~mc2739@rockbox/developer/mc2739) 18.19.58 Quit melmothX (Ping timeout: 260 seconds) 18.20.46 # hmmm 18.21.37 Join melmothX [0] (~melmoth@unaffiliated/melmothx) 18.22.11 # Build Server message: 3New build round started. Revision 8390eb9, 217 builds, 20 clients. 18.23.26 # finally, after 20 commits, I've moved imx233 to new registers ! 18.26.45 # Right. Two warnings should be gone 18.26.55 # The third one shows a real issue though 18.29.38 # Build Server message: 3Build round completed after 447 seconds. 18.29.39 # Build Server message: 3Revision 8390eb9 result: All green 18.29.40 # Build Server message: 3New build round started. Revision d4061a4, 217 builds, 20 clients. 18.30.41 # ah, a pattern! 18.36.03 # Build Server message: 3Build round completed after 384 seconds. 18.36.04 # Build Server message: 3Revision d4061a4 result: All green 18.36.35 # Build Server message: 3New build round started. Revision abb7d1d, 217 builds, 20 clients. 18.36.37 # There 18.36.54 # Silly old bug :) 18.38.39 # Slightly more than eight years 18.40.10 # gevaerts: will you fix the other bugs in the midi plugin now? :) 18.40.34 # n1s: this one caused bad memory accesses, so I'm claiming this could explain every other one :) 18.40.43 # Well, not *extremely* bad 18.41.16 # Also, you were the last one to touch this particular code, so it's your fault anyway :) 18.41.29 # but not anymore! 18.41.50 # tag, you're it! 18.41.52 # * n1s runs 18.43.03 # :) 18.43.58 # Build Server message: 3Build round completed after 444 seconds. 18.43.59 # Build Server message: 3Revision abb7d1d result: All green 18.44.43 # seriously though, it's nice that they add useful warnings 18.46.17 # Yes. The "unused typedef" one may be a bit silly, but warning about bad array accesses definitely makes up for that 18.51.25 # Hmmm, that table is slightly wrong in many places! 18.51.50 # It has the base A at 440.000 HZ, but the one below that is 219.999? 18.54.52 Quit TheSphinX_ (Ping timeout: 240 seconds) 18.59.55 Join TheSphinX^ [0] (~briehl@p57A392C3.dip0.t-ipconnect.de) 19.03.26 Quit mc3739 (Quit: leaving) 19.04.42 Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) 19.04.53 Quit DexterLB (Read error: Connection reset by peer) 19.05.40 Quit TheSphinX^ (Ping timeout: 248 seconds) 19.06.24 Join lorenzo92 [0] (~chatzilla@host58-107-dynamic.20-79-r.retail.telecomitalia.it) 19.07.53 Join TheSphinX^ [0] (~briehl@p57A38BB5.dip0.t-ipconnect.de) 19.10.02 Join DexterLB [0] (~dex@77-85-7-183.btc-net.bg) 19.11.20 Join kaputnik [0] (~kaputnik@port-92-206-120-112.dynamic.qsc.de) 19.15.48 # There, people can now state their opinions on g#489 :) 19.15.50 # 3Gerrit review #489 at http://gerrit.rockbox.org/r/489 : 3midi: Recalculate (and rename) the note frequency table. by Frank Gevaerts (changes/89/489/1) 19.16.28 Join kevku [0] (~kevku@2001:470:27:773:0:feed:c0f:fee) 19.18.33 # hm, we keep a table of frequencies at milliHertz resolution, then immediately truncate it to 1/10 Hz resolution upon use :) 19.18.48 # Not entirely 19.18.54 # sequencer.c also uses that table 19.19.24 # oh, ok, so we actually save a table now 19.19.38 # Yes, that's n1s' doing :) 19.21.03 # Hmm, near the end of the table the differences are larger, with one outlier of 0.064Hz 19.21.13 # I claim the original table was wrong there though 19.21.52 # maybe it wasn't an even tempered scale 19.22.29 # more probably just dodgy rounding 19.23.40 # The differences between my calculations and the original table are 0.001Hz or zero up to entry 94, and then they start to go up 19.24.51 # http://hostname.be/diff.png 19.25.13 # Y axis is in millihertz 19.35.03 Quit shamus (Read error: Connection reset by peer) 19.35.57 Join shamus [0] (~shmaus@ip-206-192-195-49.marylandheights.ip.cablemo.net) 19.40.20 *** Saving seen data "./dancer.seen" 19.59.31 Join stoffel [0] (~quassel@pD9E40DD8.dip0.t-ipconnect.de) 20.14.46 Quit stoffel (Ping timeout: 260 seconds) 20.31.36 # gevaerts: is there an audible difference? 20.35.20 # n1s: that would require me to find a midi file and set stuff up :) 20.35.38 # I doubt it though 20.35.47 Quit mt` (Ping timeout: 252 seconds) 20.36.31 # I mainly see this as replacing a set of magic numbers with a set of logical easy to understand numbers 20.37.28 # Also, it's only going to make a difference in high notes anyway, so definitely not all files will have a difference 20.37.54 # * gevaerts assumes that a 0.001 Hz difference is absolutely inaudible 20.38.38 # It's also entirely possible even that there is *no* difference due to rounding in various places 20.40.10 # <[Saint]> ...go over to headfi and say that. :P 20.40.53 # <[Saint]> Buy some $8K cables, then you'll hear the difference. 20.41.55 # Bah 20.42.12 # By "*no* difference", I mean "exactly the same bits go to the audio chip" 20.43.07 Join kaputnik_ [0] (~kaputnik@port-92-206-81-126.dynamic.qsc.de) 20.43.11 # <[Saint]> But they may not be as crisp, or fragrant, or have the subtle, honey tones the originals had. 20.43.35 # <[Saint]> But I have some cables that'll fix that. 20.44.01 # You shouldn't be listening to midi anyway then 20.44.24 # <[Saint]> ir reencode it to flac, so its OK. 20.44.37 # vinyl or nothing! 20.46.58 Quit kaputnik (Ping timeout: 260 seconds) 20.49.12 Quit TheLemonMan (Read error: Operation timed out) 21.05.45 Quit akaWolf (Ping timeout: 245 seconds) 21.36.58 Quit AndyP_ (Quit: ChatZilla 0.9.90 [Firefox 21.0/20130511120803]) 21.40.22 *** Saving seen data "./dancer.seen" 21.47.46 Quit Scromple (Ping timeout: 252 seconds) 21.50.54 Quit krabador (Ping timeout: 260 seconds) 21.55.05 Join Horschti [0] (~Horscht@xbmc/user/horscht) 21.58.14 Join krabador [0] (~krabador@unaffiliated/krabador) 22.11.28 Join saratoga_ [0] (123e0c38@gateway/web/freenode/ip.18.62.12.56) 22.12.14 # TTA is such a dead-simple but also really efficient lossless format we should think about porting the ffmpeg decoder 22.23.46 Quit lorenzo92 (Quit: ChatZilla 0.9.90 [Firefox 21.0/20130517204131]) 22.25.58 Quit pamaury (Ping timeout: 256 seconds) 22.26.05 Quit y4n (Quit: 6,000,000 ways to die — choose one.) 22.27.38 # saratoga_: ok 22.28.47 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 22.28.55 # oh 22.28.58 # sorry i mispoke aboave 22.28.59 # above 22.29.04 # I mean TAK 22.29.19 Quit melmothX (Quit: #) 22.29.21 # stupid similar three letter acronyms :) 22.33.11 # saratoga_: no one is stopping you from doing it :) 22.33.21 # do you want / need help with that? 22.33.25 # haha 22.33.30 # yeah i want to once i get some free time 22.40.48 Quit pamaury (Ping timeout: 246 seconds) 22.41.46 # saratoga_: does ffmpeg already have a fixed point decoder? 22.42.06 # hm, or are lossless decoders generally always fixed point? 22.46.59 # i think so 22.47.22 # generally they're fixed point 22.47.44 # since rounding errors in floating point are very difficult to predict 22.48.21 # ffmpeg does like to do huge mallocs and such though, so just because its fixed point doesn't mean its trivial to port 22.49.01 # they also have a wma lossless decoder now, but its probably not all that interesting given how poorly that format performs 22.49.22 # TAK is interesting because its compression is better than flac but its decode speed is still quite good 22.50.27 # yeah, there's no portable encoder though 22.56.24 # from a very quick glance at the ffmpeg code it seems very similar to flac, stereo correlation, lpc and residues. the initial patch for ffmpeg adds less than 2000 loc 22.57.43 # thats large for a lossless decoder 22.57.50 # TTA is < 500 lines for the whole thing 22.58.01 # well not the bitstream stuff 22.58.13 # that's format parser and things, the actual decoder is < 1000 22.58.19 # ah 23.03.48 Join TheLemonMan [0] (~LemonBoy@unaffiliated/thelemonman) 23.04.38 Quit kevku (Ping timeout: 260 seconds) 23.13.57 # how soon until we can have an unstable version released for any of the creative players? 23.14.07 Quit Horschti (Quit: quit) 23.16.36 Quit n1s (Ping timeout: 240 seconds) 23.31.28 Nick soap_ is now known as soap (~soap@rockbox/staff/soap) 23.39.14 Join pamaury [0] (~quassel@rockbox/developer/pamaury) 23.39.15 # saratoga_: I'm wondering if it would be a good idea to add an entry to the properties showing the album art type 23.40.26 *** Saving seen data "./dancer.seen" 23.40.27 # that way we could show if the embedded AA is incompatible (for whatever reason) 23.40.51 # right now we don't support some formats but don't have a way for the user to find out :) 23.41.05 # saratoga: the zen xfi3 is unstable actually 23.41.29 # bluebrother^: at very least i should probably add this kind of information tot he log system 23.41.39 # pamaury: can rbutil install it? 23.41.56 # I have a patch for it in gerrit, it needs some cleanup 23.42.16 # once thats committed, we should update the front page 23.42.27 # reminds me that I wanted to give that file attributes patch in gerrit a look :o 23.42.32 # basically the only issue is that rbutil needs to be able to unpack cab files, I'll try to cleanup the patch soon 23.42.37 # cool 23.42.51 # the xfi wasn't the most popular player but i bet theres users who would be very interested in trying it 23.42.54 # then the zen mozaic (when committed) will be unstable soon too 23.43.08 # only install is problematic because it needs MTP 23.43.17 # we have a tool for it but it's not in rbutil 23.43.27 # same for x-fi 23.43.44 # the zen should follow as soon as I figure out the screen issue 23.43.49 # zen v is in good shape too 23.43.59 # lack of rbutil isn't fatal, but we'd need to release a binary for the tool for windows/linux and put good instructions (like for the e200r) 23.45.00 # integrating MTP in Rockbox Utility is kinda problematic, since it assumes a drive letter / mountpoint being present at all time 23.45.18 # (one of the reasons why beast isn't integrated yet) 23.46.06 # yeah, and MTP under linux is sometimes problematic, sendfirm only works half of the time on my linux because of the poor kde support for mtp (it messes with the devices but as ptp) 23.46.18 # isn't there some way to enumerate MTP devices? 23.46.42 # yes there is 23.47.22 # on Windows of course there the API and on Linux libmtp does it too but suffers from the same problem as libusb: you cannot refresh the list dynamically 23.51.53 # so you'd have to quit rbutil to refresh it? 23.53.05 # as far as know yes, except if they fixed that but I'm not so sure 23.54.28 # ok 23.54.32 # i guess that wouldn't be terrible 23.57.23 Quit saratoga_ (Quit: Page closed) 23.57.43 # one needs to check though, it's quite possible that libmpt implemented it's own mechanism to update the list 23.57.55 # but yeah, that's THE major issue of libusb in my opinion