Previous day | Jump to hour: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | Next day

Seconds: Show Hide | Joins: Show Hide | View raw
Font: Serif Sans-Serif Monospace | Size: Small Medium Large

Click in the nick column to highlight everything a person has said.
The Logo icon identifies that the person is a core developer (has commit access).

#rockbox log for 2013-06-16

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] (
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:05vsync_does rockbox support any other fs than fat32?
02:07:34saratogawell fat16 :)
02:08:04vsync_okay :(
02:17:46fs-bluebotBuild Server message: New build round started. Revision d561017, 217 builds, 21 clients.
02:20:43 Join Epicanis [0] (~yaaic@
02:24:33fs-bluebotBuild Server message: Build round completed after 408 seconds.
02:24:34fs-bluebotBuild Server message: Revision 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: <apo_> 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:56saratogahow do i try a patch from gerrit?
02:31:01saratogacherry pick or one of the other options?
02:31:22 Join b1101 [0] (~b@
02:35:59gevaertscherry 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 -
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] (
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] (
06:31:02 Nick shai_ is now known as shai (
06:32:51 Quit shai (Quit: Leaving)
06:43:49 Quit Raptors (Read error: Connection reset by peer)
06:55:01 Join Raptors [0] (
07:33:11 Join liar [0] (
07:40:05***Saving seen data "./dancer.seen"
08:06:17 Quit kevku (Quit: KVIrc 4.3.1 Aria
08:29:24 Join akaWolf [0] (~akaWolf@unaffiliated/akawolf)
09:12:58 Join advcomp2019_ [0] (
09:12:58 Quit advcomp2019_ (Changing host)
09:12:58 Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019)
09:15:17 Join dokan_ [0] (
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] (
09:16:25 Join mystica555 [0] (
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@
09:28:39 Nick mt is now known as Guest95238 (~quassel@
09:40:09***Saving seen data "./dancer.seen"
09:46:55 Join pretty_function [0] (~sigBART@
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] (
10:32:37 Join bertrik [0] (~quassel@rockbox/developer/bertrik)
10:33:32bertrikgevaerts: awake yet?
10:34:13bertrikI think I found a bug in the usb stack
10:35:07[Saint]He didn't say he'd fix it... ;)
10:35:21bertrikprobably not a big deal
10:36:09copperany USB bug is a big deal!
10:36:11bertrikbut the fix is simple
10:41:36 Quit tchan (Quit: WeeChat 0.4.1)
10:41:50bertrikthe bug probably affects the way LUNs are recognised on rockbox storage
10:51:23 Join lorenzo92 [0] (
10:51:30 Quit kevku (Ping timeout: 260 seconds)
10:52:29 Join mt [0] (~quassel@
10:52:54 Nick mt is now known as Guest73236 (~quassel@
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] (
11:04:05 Join mt` [0] (~quassel@
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] (
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] (
12:06:29 Join y4n [0] (~y4n@unaffiliated/y4ndexx)
12:23:49 Quit Gallomimia (Ping timeout: 252 seconds)
12:26:37 Join Gallomimia [0] (
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] (
12:47:45 Join fs-bluebot [0] (
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:25:34 Join y4n [0] (~y4n@unaffiliated/y4ndexx)
13:29:53 Nick mt` is now known as mt (~quassel@
13:30:00 Quit mt (Changing host)
13:30:00 Join mt [0] (~quassel@rockbox/developer/mt)
13:39:54 Quit copper (Quit: ZNC -
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: - Chat comfortably. Anywhere.)
13:47:36 Join mt [0] (~quassel@
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] (
14:06:00 Quit TheLemonMan (Changing host)
14:06:00 Join TheLemonMan [0] (~LemonBoy@unaffiliated/thelemonman)
14:06:37pamaurybertrik: can you elaborate on this usb bug ?
14:35:26bertrikpamaury: variable allocation_length is not used when handling SCSI_REPORT_LUNS, I posted a patch at
14:35:38bertrikUnlikely that this is an actual problem though
14:36:54bertrikThere 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:17pamauryindeed, I don't think that actually happen but it's always better to handle it the right way
14:37:18bertrikas far as I understand, we should send back data with a length of the minimum of those three
14:37:43pamauryI would need to rerereread the spec to check
14:38:24bertrikI'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:07pamauryI'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] (
15:21:14 Join stoffel [0] (
15:30:12 Join darkham_ [0] (
15:31:58 Quit krabador (Ping timeout: 260 seconds)
15:33:22 Quit kevku (Ping timeout: 260 seconds)
15:38:49copperIs there any chance that I/O activity inside the Fuze+ could affect the display?
15:39:01copperI'm seing some kind of refresh rate issue
15:39:26coppersome light flickering of sorts
15:39:37lebelliumI also noticed that some time ago copper
15:40:14***Saving seen data "./dancer.seen"
15:40:37copperSanDisk really dropped the ball with the Fuze+
15:41:00copperI'm suspecting bad management
15:41:05copperpoor decision making
15:41:19 Join mt` [0] (~quassel@rockbox/developer/mt)
15:41:55copperI still love it though!
15:42:15pamauryI 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:22lebelliumI 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:42copperpamaury: well I was wondering if it was a hardware issue
15:43:17copperthere is no doubt that the screen that they put in there is of bad quality
15:43:34pamauryI 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:08lebelliumthe 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:17copperI'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:44copperright now it's very constant
15:45:09pamauryAt 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:11copperah screw it, it's taking too long
15:46:37copperpamaury: ok, yup, it's definitely activated by I/O on the sdxc card
15:46:45copperI can reproduce it at will
15:47:18copperlemme try with the internal flash memory now
15:47:19lebelliumI get the issue without microsd card
15:48:46coppersame thing
15:50:18pamauryah indeed, there is a slight flicker on I/O, but that's really light compared to the hard flicker that sometimes happen
15:52:51pamauryto be honested, I had never noticed this before !
15:53:26 Join tchan [0] (~tchan@lunar-linux/developer/tchan)
15:53:50copperI'm gonna try again with the OF
15:54:38pamauryyeah that would help
15:55:58copperas soon as I plugged it in, running the OF, it rebooted under Rockbox
15:56:07 Quit darkham_ (Quit: Bah...)
15:56:46copperdid it again
15:56:59lebelliumit doesn't happen with OF, no flickering
15:57:58copperI 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 -
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:38gevaertsbertrik: I'm fairly sure you're correct
16:48:18 Join SeaWeed [0] (
16:48:31 Part SeaWeed
16:50:59bertrikunlikely 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] (
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:21:37 Join melmothX [0] (~melmoth@unaffiliated/melmothx)
18:22:11fs-bluebotBuild Server message: New build round started. Revision 8390eb9, 217 builds, 20 clients.
18:23:26pamauryfinally, after 20 commits, I've moved imx233 to new registers !
18:26:45gevaertsRight. Two warnings should be gone
18:26:55gevaertsThe third one shows a real issue though
18:29:38fs-bluebotBuild Server message: Build round completed after 447 seconds.
18:29:39fs-bluebotBuild Server message: Revision 8390eb9 result: All green
18:29:40fs-bluebotBuild Server message: New build round started. Revision d4061a4, 217 builds, 20 clients.
18:30:41gevaertsah, a pattern!
18:36:03fs-bluebotBuild Server message: Build round completed after 384 seconds.
18:36:04fs-bluebotBuild Server message: Revision d4061a4 result: All green
18:36:35fs-bluebotBuild Server message: New build round started. Revision abb7d1d, 217 builds, 20 clients.
18:36:54gevaertsSilly old bug :)
18:38:39gevaertsSlightly more than eight years
18:40:10n1sgevaerts: will you fix the other bugs in the midi plugin now? :)
18:40:34gevaertsn1s: this one caused bad memory accesses, so I'm claiming this could explain every other one :)
18:40:43gevaertsWell, not *extremely* bad
18:41:16gevaertsAlso, you were the last one to touch this particular code, so it's your fault anyway :)
18:41:29n1sbut not anymore!
18:41:50n1stag, you're it!
18:41:52*n1s runs
18:43:58fs-bluebotBuild Server message: Build round completed after 444 seconds.
18:43:59fs-bluebotBuild Server message: Revision abb7d1d result: All green
18:44:43n1sseriously though, it's nice that they add useful warnings
18:46:17gevaertsYes. The "unused typedef" one may be a bit silly, but warning about bad array accesses definitely makes up for that
18:51:25gevaertsHmmm, that table is slightly wrong in many places!
18:51:50gevaertsIt 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] (
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] (
19:07:53 Join TheSphinX^ [0] (
19:10:02 Join DexterLB [0] (
19:11:20 Join kaputnik [0] (
19:15:48gevaertsThere, people can now state their opinions on g#489 :)
19:15:50fs-bluebotGerrit review #489 at : midi: 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:33bertrikhm, we keep a table of frequencies at milliHertz resolution, then immediately truncate it to 1/10 Hz resolution upon use :)
19:18:48gevaertsNot entirely
19:18:54gevaertssequencer.c also uses that table
19:19:24bertrikoh, ok, so we actually save a table now
19:19:38gevaertsYes, that's n1s' doing :)
19:21:03gevaertsHmm, near the end of the table the differences are larger, with one outlier of 0.064Hz
19:21:13gevaertsI claim the original table was wrong there though
19:21:52bertrikmaybe it wasn't an even tempered scale
19:22:29bertrikmore probably just dodgy rounding
19:23:40gevaertsThe 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:25:13gevaertsY axis is in millihertz
19:35:03 Quit shamus (Read error: Connection reset by peer)
19:35:57 Join shamus [0] (
19:40:20***Saving seen data "./dancer.seen"
19:59:31 Join stoffel [0] (
20:14:46 Quit stoffel (Ping timeout: 260 seconds)
20:31:36n1sgevaerts: is there an audible difference?
20:35:20gevaertsn1s: that would require me to find a midi file and set stuff up :)
20:35:38gevaertsI doubt it though
20:35:47 Quit mt` (Ping timeout: 252 seconds)
20:36:31gevaertsI mainly see this as replacing a set of magic numbers with a set of logical easy to understand numbers
20:37:28gevaertsAlso, 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:38gevaertsIt'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:42:12gevaertsBy "*no* difference", I mean "exactly the same bits go to the audio chip"
20:43:07 Join kaputnik_ [0] (
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:01gevaertsYou shouldn't be listening to midi anyway then
20:44:24[Saint]ir reencode it to flac, so its OK.
20:44:37gevaertsvinyl 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.
22:12:14saratoga_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:38bertriksaratoga_: ok
22:28:47 Join pamaury [0] (~quassel@rockbox/developer/pamaury)
22:28:58saratoga_sorry i mispoke aboave
22:29:04saratoga_I mean TAK
22:29:19 Quit melmothX (Quit: #)
22:29:21saratoga_stupid similar three letter acronyms :)
22:33:11bertriksaratoga_: no one is stopping you from doing it :)
22:33:21bertrikdo you want / need help with that?
22:33:30saratoga_yeah i want to once i get some free time
22:40:48 Quit pamaury (Ping timeout: 246 seconds)
22:41:46bertriksaratoga_: does ffmpeg already have a fixed point decoder?
22:42:06bertrikhm, or are lossless decoders generally always fixed point?
22:46:59n1si think so
22:47:22saratoga_generally they're fixed point
22:47:44saratoga_since rounding errors in floating point are very difficult to predict
22:48:21saratoga_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:01saratoga_they also have a wma lossless decoder now, but its probably not all that interesting given how poorly that format performs
22:49:22saratoga_TAK is interesting because its compression is better than flac but its decode speed is still quite good
22:50:27n1syeah, there's no portable encoder though
22:56:24n1sfrom 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:43saratoga_thats large for a lossless decoder
22:57:50saratoga_TTA is < 500 lines for the whole thing
22:58:01saratoga_well not the bitstream stuff
22:58:13n1sthat's format parser and things, the actual decoder is < 1000
23:03:48 Join TheLemonMan [0] (~LemonBoy@unaffiliated/thelemonman)
23:04:38 Quit kevku (Ping timeout: 260 seconds)
23:13:57saratoga_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:15bluebrother^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:27bluebrother^that way we could show if the embedded AA is incompatible (for whatever reason)
23:40:51bluebrother^right now we don't support some formats but don't have a way for the user to find out :)
23:41:05pamaurysaratoga: the zen xfi3 is unstable actually
23:41:29saratoga_bluebrother^: at very least i should probably add this kind of information tot he log system
23:41:39saratoga_pamaury: can rbutil install it?
23:41:56pamauryI have a patch for it in gerrit, it needs some cleanup
23:42:16saratoga_once thats committed, we should update the front page
23:42:27bluebrother^reminds me that I wanted to give that file attributes patch in gerrit a look :o
23:42:32pamaurybasically the only issue is that rbutil needs to be able to unpack cab files, I'll try to cleanup the patch soon
23:42:51saratoga_the xfi wasn't the most popular player but i bet theres users who would be very interested in trying it
23:42:54pamaurythen the zen mozaic (when committed) will be unstable soon too
23:43:08pamauryonly install is problematic because it needs MTP
23:43:17pamaurywe have a tool for it but it's not in rbutil
23:43:27pamaurysame for x-fi
23:43:44pamaurythe zen should follow as soon as I figure out the screen issue
23:43:49pamauryzen v is in good shape too
23:43:59saratoga_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:00bluebrother^integrating MTP in Rockbox Utility is kinda problematic, since it assumes a drive letter / mountpoint being present at all time
23:45:18bluebrother^(one of the reasons why beast isn't integrated yet)
23:46:06pamauryyeah, 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:18saratoga_isn't there some way to enumerate MTP devices?
23:46:42pamauryyes there is
23:47:22pamauryon 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:53saratoga_so you'd have to quit rbutil to refresh it?
23:53:05pamauryas far as know yes, except if they fixed that but I'm not so sure
23:54:32saratoga_i guess that wouldn't be terrible
23:57:23 Quit saratoga_ (Quit: Page closed)
23:57:43pamauryone needs to check though, it's quite possible that libmpt implemented it's own mechanism to update the list
23:57:55pamaurybut yeah, that's THE major issue of libusb in my opinion

Previous day | Next day