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).

Notice: Only Gecko based browsers prior to FF4 support the multipart/mixed "server push" method used by this log reader to auto-update. Since you do not appear to use such a browser, this page will simply show the current log, and not automatically update.

#rockbox log for 2018-05-02

00:07:57***Saving seen data "./dancer.seen"
00:24:56 Quit petur (Quit: Leaving)
00:47:00 Quit ZincAlloy (Quit: Leaving.)
01:00
01:25:38 Quit alce (Read error: No route to host)
01:57:31 Quit this_is_a_nick (Remote host closed the connection)
02:00
02:08:01***Saving seen data "./dancer.seen"
02:12:42 Quit ender` (Quit: Is there like a way to put a compiler in "Just trust me on that one" mode?)
02:17:54 Quit Rower (Ping timeout: 276 seconds)
02:18:35 Join Rower [0] (husvagn@m83-182-173-65.cust.tele2.se)
02:40:45bray90820So I am here with rockbox on a DX90 and and every time I try to play a song the system reboots I tried it on stock firmware and everything works correctly
02:43:24 Quit Rower (Ping timeout: 268 seconds)
02:43:57 Join Rower [0] (husvagn@m176-64-208-187.cust.tele2.se)
02:51:00 Join this_is_a_nick [0] (~amofiuhr_@ip187-132-50-179.ct.co.cr)
02:54:58pR0PsI'm having an issue with data corruption when copying files running RockBox. iPod Video, latest dev build of RockBox, 2*128GB SanDisk SD cards in a iFlash dual. When I copy files over running RockBox almost every file is corrupt. It still plays so it's mostly fine, but theres a ton of skipping, making it unlistenable. I know it's not hardware-related because I put it in disk mode, let iTunes totally restore it, and used iTunes to copy files over and they're
02:54:59pR0Ps all fine. Is this a known issue?
02:55:10 Quit jhMikeS (Ping timeout: 260 seconds)
03:00
03:00:56__builtinpR0Ps: yes, it's a known issue
03:01:06__builtiniflash adapters are known not to work well
03:01:32__builtinwe get a question about those roughly once a week
03:04:13pR0Pshuh, good to know.
03:04:38pR0PsAre there any workarounds or patches? (or an open bug I could look into?)
03:05:34__builtinI don't think so
03:05:52__builtinthe obvious workaround is "use the OF"
03:06:10__builtinsomething about the OF's ATA driver works better with the adapter
03:06:58pR0PsJust while transferring data? Or no Rockbox entirely?
03:08:30__builtinyou could see if using the OF to transfer data and then rockbox to using access it works any better, but I doubt it
03:09:24pR0PsAww, that sucks, I hate iTunes
03:11:25pR0PsSo that would mean that if the data goes from USB -> Rockbox USB driver -> Rockbox ATA driver -> iFlash (does it?) then the problem would be the ATA driver?
03:12:40pR0PsIf it was in the USB driver I would expect transferring data with the Of and playing it with RB would work, but if it's in how RB communicates with the disk then yeah, no difference.
03:13:27pR0Ps(well, the files would be fine, but anything else RB wrote to the disk like the DB would be corrupt)
03:20:17pR0PsAre there any other options for flash cards that *do* work well with RB?
03:35:57pR0PsI came across a few posts in the forums from people that said transferring via OF and playing in RB worked fine so I'll give that a shot
03:36:35__builtinit could be a bug with writing only, but I'm not sure
03:58:21 Quit amiconn (Quit: No Ping reply in 64 seconds.)
03:59:12 Quit pixelma (Quit: No Ping reply in 120 seconds.)
03:59:29 Join amiconn [0] (~amiconn@rockbox/developer/amiconn)
04:00
04:00:22 Join pixelma [0] (~pixelma@rockbox/staff/pixelma)
04:08:02***Saving seen data "./dancer.seen"
04:19:08pR0PsAnecdote incoming: I formatted via iTunes on Windows, installed RB, rebooted into disk mode, transferred music, and rebooted back into RB. Everything is playing perfectly.
04:19:47pR0PsAlso, after I transferred the files I did a hash check on them and they all match (previously the hashes were different after copying)
05:00
05:00:02 Quit CommunistWitchDr (Quit: Fuck this, I'm out)
05:00:12 Join SovietShaman [0] (quasselcor@24-217-39-226.dhcp.stls.mo.charter.com)
05:02:10 Quit SovietShaman (Client Quit)
05:03:24 Join SovietShaman [0] (quasselcor@24-217-39-226.dhcp.stls.mo.charter.com)
05:04:59 Nick SovietShaman is now known as CommunistWitchDr (quasselcor@24-217-39-226.dhcp.stls.mo.charter.com)
05:14:10 Join jhMikeS [0] (~jethead71@24.192.177.173)
05:31:03 Quit jhMikeS (Ping timeout: 265 seconds)
05:48:26 Join alce [0] (~taz@83-245-228-117-nat-p.elisa-mobile.fi)
06:00
06:06:50 Quit [7] (Ping timeout: 265 seconds)
06:08:05***Saving seen data "./dancer.seen"
06:10:27 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)
06:12:58 Quit Soap (Read error: Connection reset by peer)
06:13:25 Join Soap [0] (~Soap@rockbox/staff/soap)
06:17:08 Join Bilgus [0] (~Bilgus@unaffiliated/bilgus)
07:00
07:10:44 Join lebellium [0] (~hexchat@89-93-177-206.hfc.dyn.abo.bbox.fr)
07:11:56 Quit lebellium (Client Quit)
07:27:29 Quit michaelni (Ping timeout: 255 seconds)
07:40:26 Join michaelni [0] (~michael@213-47-41-20.cable.dynamic.surfer.at)
08:00
08:08:06***Saving seen data "./dancer.seen"
08:09:46 Quit SammysHP (Ping timeout: 245 seconds)
08:10:00 Join SammysHP [0] (~SammysHP@faol.sammyshp.de)
08:16:50 Quit dys (Ping timeout: 240 seconds)
08:25:28 Quit Rower (Ping timeout: 260 seconds)
08:26:21 Join Rower [0] (husvagn@m176-64-208-187.cust.tele2.se)
08:30:11 Join petur [0] (~petur@rockbox/developer/petur)
08:37:23alceDigital[m]: i do not know if you are familiar with linux but https://github.com/mikebrady/shairport-sync/issues/200
08:39:04alcei am not sure if i have any bluetooth audio receivers so a bit hard to test
08:52:36 Quit TheSeven (Ping timeout: 265 seconds)
08:52:58 Join TheSeven [0] (~quassel@rockbox/developer/TheSeven)
08:55:15alcei think from audio quality point of view it would be difficult for any bluetooth receiver to match the 3.5mm jack because the dac and these receivers is most likely of lower quality
09:00
09:19:40 Join ender` [0] (krneki@foo.eternallybored.org)
10:00
10:08:10***Saving seen data "./dancer.seen"
10:51:24Digital[m]alce: thanks, I'll look into it
10:54:53 Quit Rower (Ping timeout: 265 seconds)
10:55:48 Join Rower [0] (husvagn@m176-64-208-187.cust.tele2.se)
11:00
11:00:31 Quit evilnick_ (Ping timeout: 260 seconds)
11:00:44 Join evilnick_ [0] (~evilnick@d54c3417e.access.telenet.be)
11:10:16 Quit APLU (Ping timeout: 276 seconds)
11:13:36 Join APLU [0] (~mulx@eva.aplu.fr)
11:13:37 Quit alce (Read error: Connection reset by peer)
11:19:02 Join alce [0] (~taz@83-245-228-117-nat-p.elisa-mobile.fi)
11:51:32 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
12:00
12:08:11***Saving seen data "./dancer.seen"
12:34:26 Quit evilnick_ (Ping timeout: 240 seconds)
12:35:34 Join evilnick_ [0] (~evilnick@d54C3417E.access.telenet.be)
12:38:24 Quit pamaury (Ping timeout: 248 seconds)
12:40:04 Quit evilnick_ (Ping timeout: 240 seconds)
12:40:42 Join evilnick_ [0] (~evilnick@d54C3417E.access.telenet.be)
13:00
13:08:04 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
13:25:42 Join massiveH [0] (~massiveH@ool-18e4e27c.dyn.optonline.net)
13:45:09 Quit alce (Read error: No route to host)
14:00
14:08:14***Saving seen data "./dancer.seen"
14:25:33 Join amayer [0] (~amayer@107-1-97-172-ip-static.hfc.comcastbusiness.net)
14:37:53 Quit massiveH (Quit: Leaving)
15:00
15:55:50 Join paulk-gagarine-s [0] (~paulk-gag@220.107.128.77.rev.sfr.net)
15:58:54 Quit paulk-gagarine (Ping timeout: 268 seconds)
15:59:13 Quit paulk-gagarine-s (Remote host closed the connection)
15:59:31 Join paulk-gagarine [0] (~paulk-gag@220.107.128.77.rev.sfr.net)
16:00
16:08:15***Saving seen data "./dancer.seen"
16:22:03 Join jhMikeS [0] (~jethead71@24.192.177.173)
16:40:27__builtinpR0Ps: looks like a write issue then
16:53:28 Quit petur (Quit: Connection reset by beer)
18:00
18:08:18***Saving seen data "./dancer.seen"
18:12:38 Join amofiuhr_ [0] (~amofiuhr_@ip187-132-50-179.ct.co.cr)
18:13:21 Quit this_is_a_nick (Ping timeout: 276 seconds)
18:15:54 Join zu [0] (~zu@ks387228.kimsufi.com)
18:16:09 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:3848:e51b:92b9:7f9)
18:47:44 Quit ZincAlloy (Ping timeout: 256 seconds)
19:00
19:45:07 Join Strife1989 [0] (~quassel@adsl-98-80-193-204.mcn.bellsouth.net)
19:45:10 Join dys [0] (~dys@tmo-113-86.customers.d1-online.com)
19:47:58 Quit Strife89 (Ping timeout: 260 seconds)
19:51:04 Quit bluebrother (Disconnected by services)
19:51:09 Join bluebrother^ [0] (~dom@rockbox/developer/bluebrother)
19:51:20 Join fs-bluebot_ [0] (~fs-bluebo@port-92-202-250-141.dynamic.qsc.de)
19:52:02 Join alce [0] (~taz@83-245-228-117-nat-p.elisa-mobile.fi)
19:54:04 Quit fs-bluebot (Ping timeout: 276 seconds)
19:56:47 Join lebellium [0] (~hexchat@89-93-177-206.hfc.dyn.abo.bbox.fr)
19:59:38 Quit alce (Ping timeout: 260 seconds)
20:00
20:06:25 Join alce [0] (~taz@83-245-228-117-nat-p.elisa-mobile.fi)
20:08:22***Saving seen data "./dancer.seen"
20:14:53 Quit amofiuhr_ (Remote host closed the connection)
20:19:12 Quit dys (Ping timeout: 248 seconds)
20:20:19 Join dys [0] (~dys@tmo-080-193.customers.d1-online.com)
20:37:01 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:3848:e51b:92b9:7f9)
20:41:46 Join this_is_a_nick [0] (~amofiuhr_@201.199.104.92)
20:42:45 Join xorly [0] (~xorly@ip-86-49-24-93.net.upcbroadband.cz)
20:46:07 Join smoke_fumus [0] (~smoke_fum@188.35.176.90)
20:55:36 Quit GeekShadow (Ping timeout: 256 seconds)
20:57:34 Join GeekShadow [0] (~antoine@reactos/tester/GeekShadow)
21:00
21:06:15 Quit ZincAlloy (Ping timeout: 256 seconds)
21:16:25 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:3848:e51b:92b9:7f9)
21:41:08 Quit GeekShadow (Ping timeout: 264 seconds)
21:45:36 Quit alce (Read error: Connection reset by peer)
21:48:14 Join GeekShadow [0] (~antoine@reactos/tester/GeekShadow)
21:51:23 Join alce [0] (~taz@83-245-228-117-nat-p.elisa-mobile.fi)
22:00
22:02:04 Quit GeekShadow (Ping timeout: 240 seconds)
22:02:04 Quit ZincAlloy (Ping timeout: 255 seconds)
22:08:24***Saving seen data "./dancer.seen"
22:14:45 Join GeekShadow [0] (~antoine@reactos/tester/GeekShadow)
22:14:48 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:3848:e51b:92b9:7f9)
22:26:02 Quit ZincAlloy (Quit: Leaving.)
22:29:27 Quit amayer (Quit: Leaving)
22:29:47 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:3848:e51b:92b9:7f9)
22:43:56 Quit Rower (Ping timeout: 240 seconds)
22:44:31 Join Rower [0] (husvagn@m176-64-208-187.cust.tele2.se)
22:46:58 Quit alce (Ping timeout: 276 seconds)
22:53:42 Join alce [0] (~taz@83-245-228-117-nat-p.elisa-mobile.fi)
23:00
23:09:28 Quit lebellium (Quit: Leaving)
23:13:34 Quit pamaury (Ping timeout: 240 seconds)
23:13:35 Quit alce (Read error: Connection reset by peer)
23:19:18 Join alce [0] (~taz@83-245-228-117-nat-p.elisa-mobile.fi)
23:30:13pR0Ps__builtin: Seems like it. Even when I was using RB to transfer files and getting corruption, the hashes I was reading back from the device were always the same. I'm just worried that if the problem is between the RB and the disk instead of USB and RB then all the writes that RB does over the course of normal use (database, etc) will eventually succumb to the same same corruption. It seems to be working so far though.
23:31:49 Quit ZincAlloy (Ping timeout: 255 seconds)
23:33:59pR0PsI am seeing occasional longer-than-normal delays when hitting next to skip songs repeatedly. Seems to be happening when I hit next while it's still caching the currently-playing song. Known issue again? Or maybe it's something in how the driver and iFlash interact?
23:36:03 Join ZincAlloy [0] (~Adium@2a02:8108:8b80:1700:3848:e51b:92b9:7f9)
23:55:27 Join krabador [0] (~krabador@unaffiliated/krabador)
23:56:16 Quit krabador (Remote host closed the connection)
23:56:35 Join krabador [0] (~krabador@unaffiliated/krabador)
23:58:02 Quit krabador (Client Quit)

Previous day | Next day