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 2021-02-18

00:02:42 Nick _builtin is now known as __builtin (~quassel@rockbox/developer/builtin)
00:13:03 Quit koniu (Remote host closed the connection)
00:13:31 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
01:00
01:24:21 Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de)
01:28:33 Quit ZincAlloy (Ping timeout: 246 seconds)
01:35:07 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:3:680b:f5ae:b56f)
01:40:01 Quit ZincAlloy (Ping timeout: 272 seconds)
01:57:01***Saving seen data "./dancer.seen"
02:00
02:03:38 Quit PicklesTheFrog (Ping timeout: 264 seconds)
02:03:45 Join MulX [0] (~mulx@2a03:7220:8081:2900::1)
02:06:04 Quit APLU (Ping timeout: 240 seconds)
02:06:04 Nick MulX is now known as APLU (~mulx@2a03:7220:8081:2900::1)
03:00
03:23:47 Quit ps-auxw (Ping timeout: 265 seconds)
03:24:01 Join ps-auxw [0] (~arneb@p548d56ce.dip0.t-ipconnect.de)
03:57:04***Saving seen data "./dancer.seen"
04:00
04:04:53 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
04:21:52 Quit asaba (Quit: Relay server offline)
04:58:12 Join asaba [0] (~asaba@103.113.159.184)
05:00
05:20:43 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
05:21:48 Quit Stanley00_ (Ping timeout: 256 seconds)
05:57:07***Saving seen data "./dancer.seen"
06:00
06:45:46 Quit Stanley00 (Remote host closed the connection)
06:46:24 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
06:51:06 Quit Stanley00 (Ping timeout: 272 seconds)
07:00
07:16:58 Join kugel_ [0] (~kugel@rockbox/developer/kugel)
07:18:25 Quit kugel (Ping timeout: 240 seconds)
07:26:43 Join PimpiN8 [0] (~PimpiN8@82-75-30-111.cable.dynamic.v4.ziggo.nl)
07:26:50 Quit PimpiN8 (Client Quit)
07:57:10***Saving seen data "./dancer.seen"
08:00
08:03:05 Quit J_Darnley (Ping timeout: 240 seconds)
08:03:06 Join jdarnley [0] (~J_Darnley@d51a44418.access.telenet.be)
08:38:42 Quit Barlow (Ping timeout: 246 seconds)
08:40:05 Join Barlow [0] (~barlow@unaffiliated/barlow)
08:58:22 Join massiveH [0] (~massiveH@ool-18e4e82f.dyn.optonline.net)
09:00
09:32:50 Quit bluebrother (Ping timeout: 256 seconds)
09:36:10 Quit pamaury (Quit: Konversation terminated!)
09:41:04 Join bluebrother [0] (~dom@rockbox/developer/bluebrother)
09:44:34 Join MrZeus_ [0] (~MrZeus@194.37.96.119)
09:57:13***Saving seen data "./dancer.seen"
10:00
10:18:15 Join alexweissman [0] (~alexweiss@c-73-102-58-200.hsd1.in.comcast.net)
10:24:33 Quit speachy (Ping timeout: 264 seconds)
10:24:50 Join speachy [0] (~speachy@209.2.65.77)
10:32:21 Join remihacker5 [0] (~remihacke@pax.irondistrict.org)
10:47:40 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
11:00
11:01:00 Quit remihacker5 (Quit: my battery probably died :()
11:01:19 Join remihacker5 [0] (~remihacke@vpn.irondistrict.org)
11:08:42 Join remihacker5_ [0] (~remihacke@vpn.irondistrict.org)
11:11:21 Quit remihacker5 (Ping timeout: 264 seconds)
11:11:24 Quit pamaury (Ping timeout: 272 seconds)
11:12:44 Quit remihacker5_ (Read error: Connection reset by peer)
11:15:45 Join remihacker5 [0] (~remihacke@vpn.irondistrict.org)
11:56:26 Join chris_s [0] (5fdf48e9@ip-95-223-72-233.hsi16.unitymediagroup.de)
11:57:17***Saving seen data "./dancer.seen"
11:58:27chris_sIs it just me, or is the explanation for the “Insert Shuffled” behavior in the manual (Subsection 4.4.3) either misleading, or the code needs to be adjusted so that it behaves in the way it is described there:
11:58:27chris_s“Add track(s) to the playlist in a random order.”
11:58:28chris_sI expected the tracks to be added as contiguous entries, i.e. to have "Insert Shuffled" behave like "Insert", only that the order of the inserted tracks would be random. The actual behavior as it is described in apps/playlist.c (see comment on line 695) though is as follows:
11:58:28DBUGEnqueued KICK chris_s
11:58:28chris_s"Add [each] track at some random point between the current playing track and end of playlist"
12:00
12:07:09speachyI'd agree with you
12:07:54speachyie "shuffle the selection and insert that into the playlist"
12:08:33speachyhowever the existing behavior is sort of "insert the selection into the playlist then shuffle everything"
12:11:00 Join remihacker5_ [0] (~remihacke@pax.irondistrict.org)
12:13:11 Quit remihacker5 (Quit: my battery probably died :()
12:13:11 Quit remihacker5_ (Client Quit)
12:45:58 Quit koniu (Remote host closed the connection)
12:47:21 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
12:54:37 Quit chris_s (Quit: Connection closed)
13:00
13:08:48 Join lebellium [0] (~lebellium@89-92-69-66.hfc.dyn.abo.bbox.fr)
13:09:58 Join ZincAlloy [0] (~Adium@ip5f5acf9f.dynamic.kabel-deutschland.de)
13:14:28 Quit ZincAlloy (Ping timeout: 260 seconds)
13:17:18 Join ZincAlloy [0] (~Adium@2a02:8108:943f:d824:7cbd:be25:de73:81db)
13:20:58 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
13:35:46 Quit michaelni (Quit: Leaving)
13:36:18 Join michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at)
13:37:09 Quit pamaury (Ping timeout: 264 seconds)
13:42:23 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
13:44:21_bilgus_I imagine the code acts the way it does because jhmikeS found it more efficient that way I'd adjust the manual to explain it better not the code to match the manual..
13:57:21***Saving seen data "./dancer.seen"
14:00
14:09:33 Quit pamaury (Ping timeout: 264 seconds)
14:19:16 Join PicklesTheFrog [0] (~PicklesTh@2601:640:8780:a820:a077:31a6:590b:4458)
14:21:42speachyalong those sane notes, we might want to revert g69746d8
14:22:40speachysince elsewhere we don't automatically start/resume playback if we select a new track when we're paused.
14:39:57 Join pamaury [0] (~pamaury@rockbox/developer/pamaury)
14:49:08 Join PicklesTheFrog1 [0] (~PicklesTh@2601:640:8780:a820:a077:31a6:590b:4458)
14:52:29 Quit PicklesTheFrog (Ping timeout: 268 seconds)
15:00
15:05:44 Quit MrZeus_ (Ping timeout: 272 seconds)
15:10:00 Quit alexweissman ()
15:13:27 Join J_Darnley [0] (~J_Darnley@d51A44418.access.telenet.be)
15:14:24 Quit jdarnley (Ping timeout: 260 seconds)
15:17:40 Quit pamaury (Ping timeout: 260 seconds)
15:19:26 Quit Acou_Bass (Quit: ZNC 1.8.2 - https://znc.in)
15:24:30 Join Acou_Bass [0] (~Acou_Bass@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net)
15:25:52 Nick bleb_ is now known as bleb (~cm@unaffiliated/bleb)
15:53:44 Join PimpiN8 [0] (~PimpiN8@178.239.173.176)
15:57:24***Saving seen data "./dancer.seen"
16:00
16:11:26 Join bonfire [0] (~bonfire@c-24-2-109-9.hsd1.ut.comcast.net)
16:34:15 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
17:00
17:02:24 Quit beencubed (Quit: Leaving)
17:09:38 Join beencubed [0] (~beencubed@209.131.238.248)
17:27:08 Quit PimpiN8 (Ping timeout: 256 seconds)
17:48:17 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach)
17:57:25***Saving seen data "./dancer.seen"
17:57:38 Quit Acou_Bass (Quit: ZNC 1.8.2 - https://znc.in)
18:00
18:02:03 Join Acou_Bass [0] (~Acou_Bass@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net)
18:12:16 Quit ZincAlloy (Quit: Leaving.)
18:21:41 Quit lebellium (Quit: Leaving)
18:34:58 Quit Acou_Bass (Read error: Connection reset by peer)
18:36:34 Join Acou_Bass [0] (~Acou_Bass@cpc96070-bolt17-2-0-cust175.10-3.cable.virginm.net)
19:00
19:25:54 Join chris_s [0] (5fdf48e9@ip-95-223-72-233.hsi16.unitymediagroup.de)
19:34:51 Quit chris_s (Quit: Ping timeout (120 seconds))
19:57:28***Saving seen data "./dancer.seen"
20:00
20:00:51 Quit ac_laptop (Ping timeout: 246 seconds)
20:01:38 Quit PicklesTheFrog1 (Read error: Connection reset by peer)
20:09:20 Join ac_laptop [0] (~ac_laptop@186.2.247.129)
20:33:39 Quit koniu (Ping timeout: 268 seconds)
20:34:56 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
20:43:16 Join chris_s [0] (5fdf48e9@ip-95-223-72-233.hsi16.unitymediagroup.de)
20:46:24chris_sI wonder if abebc6b should also be reverted. While I personally much prefer (and will continue using) the new behavior for the reasons explained in the commit message, I've now realized that the old behavior was (for whatever reason) quite intentional. I had missed the fact that it's mentioned multiple times in the manual and in the FAQ.
20:46:25chris_sAlternatively, I would offer to update the manual to reflect the changed behavior.
20:46:25chris_sFrom Subsection 4.4.2:
20:46:26DBUGEnqueued KICK chris_s
20:46:26chris_s"If playback is stopped, the Insert and Queue functions can be used as described in 4.4.3 to create a new playlist instead of adding to an existing one. This will erase any dynamic playlist."
20:46:26chris_s4.4.3:
20:46:27***Alert Mode level 1
20:46:27chris_s"Insert.
20:46:27***Alert Mode level 2
20:46:27chris_sAdd track(s) immediately after any tracks added via the most recent Insert operation. If no tracks have yet been added via an Insert, new tracks will be added immediately after the current playing track. If playback is stopped a new dynamic playlist will get created with the selected tracks."
20:46:28***Alert Mode level 3
20:46:28chris_sand, finally, from the FAQ:
20:46:28***Alert Mode level 4
20:46:28chris_s"How do I put a single song into a playlist, rather than an entire directory?
20:46:29***Alert Mode level 5
20:46:29chris_sRockbox creates a playlist any time you play a song. When you play a song normally, Rockbox will create a playlist of all of the songs in the folder with the song you select. If you want to play only a single song, or start a new playlist with a single song rather than the entire folder, do this:
20:46:29***Alert Mode level 6
20:46:29chris_sStop playback.
20:46:30***Alert Mode level 7
20:46:30chris_sEnter the file menu.
20:46:30***Alert Mode level 8
20:46:30chris_sSelect the song you want to add.
20:46:31***Alert Mode level 9
20:46:31chris_sEnter the context menu.
20:46:31***Alert Mode level 10
20:46:31chris_sSelect "Insert.""
20:51:05 Quit chris_s (Quit: Connection closed)
20:52:37 Join chris_s [0] (5fdf48e9@ip-95-223-72-233.hsi16.unitymediagroup.de)
20:54:26 Quit chris_s (Client Quit)
20:55:14 Join FroggestSpirit [0] (18c0819f@d192-24-159-129.try.wideopenwest.com)
20:55:52FroggestSpiritOk, so it wasn't the floating point thing that stopped my codec from working. Where is the memory allocation for codecs defined? I have a feeling it uses too much ram
20:56:03 Join chris_s [0] (5fdf48e9@ip-95-223-72-233.hsi16.unitymediagroup.de)
20:56:32***Alert Mode OFF
20:59:07 Quit ac_laptop (Ping timeout: 272 seconds)
21:00
21:03:00 Quit chris_s (Quit: Ping timeout (120 seconds))
21:05:32 Join chris_s [0] (5fdf48e9@ip-95-223-72-233.hsi16.unitymediagroup.de)
21:06:28 Quit chris_s (Client Quit)
21:06:53 Join chris_s [0] (5fdf48e9@ip-95-223-72-233.hsi16.unitymediagroup.de)
21:09:37chris_sImo, the situation described in the FAQ could be better handled by putting the "Play Next" command (which would be more appropriately named "Clear List & Play Next") in the context menu when playback was stopped.
21:09:38chris_sThe naming of the insert operations frankly confused me to no end even after using Rockbox for a while and I never used queuing at all  (whose behavior isn't particularly obvious from the name), which is why in my personal build I've actually whittled the options down to:
21:09:38chris_s"Play Next"
21:09:39DBUGEnqueued KICK chris_s
21:09:39chris_s"Add"
21:09:39chris_s"Play Last"
21:09:40***Alert Mode level 1
21:09:40chris_s"Clear List & Play Next"
21:09:40***Alert Mode level 2
21:09:40chris_sfor what is currently named (in identical order):
21:09:41***Alert Mode level 3
21:09:41chris_s"Insert Next"
21:09:41***Alert Mode level 4
21:09:41chris_s"Insert"
21:09:42***Alert Mode level 5
21:09:42chris_s"Insert Last"
21:09:42***Alert Mode level 6
21:09:42chris_s"Play Next"
21:12:02 Quit chris_s (Quit: Connection closed)
21:19:43***Alert Mode OFF
21:25:27 Join chris_s [0] (5fdf48e9@ip-95-223-72-233.hsi16.unitymediagroup.de)
21:28:02chris_sLastly, I've never quite understood why the dynamic playlist becomes inaccessible when it has finished playing? Seems like at least some users may decide to listen to it again or want to save it after it's finished. That's an easy one-line fix to reset the resume index to 0 instead of -1 after playback without obvious drawbacks (to me). But the
21:28:02chris_scurrent behavior here, too, is probably purposeful?
21:28:25 Quit chris_s (Client Quit)
21:34:28 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
21:37:01 Quit Stanley00 (Client Quit)
21:41:13 Join remihacker5 [0] (~remihacke@209.33.244.211)
21:45:30 Quit remihacker5 (Client Quit)
21:45:50 Join remihacker5 [0] (~remihacke@209.33.244.211)
21:52:21 Quit remihacker5 (Quit: my battery probably died :()
21:53:49 Join remihacker5 [0] (~remihacke@209.33.244.211)
21:56:43 Quit remihacker5 (Client Quit)
21:57:29***Saving seen data "./dancer.seen"
21:59:57FroggestSpiritalright, got it working!
22:00
22:02:58 Quit FroggestSpirit (Quit: Connection closed)
22:17:27 Quit cockroach (Quit: leaving)
22:55:35 Join Stanley00 [0] (~stanley00@unaffiliated/stanley00)
23:00
23:38:10 Quit koniu (Remote host closed the connection)
23:38:40 Join koniu [0] (~koniu@gateway/tor-sasl/koniu)
23:57:31***Saving seen data "./dancer.seen"

Previous day | Next day