| 00:04:41 | | Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) |
| 00:10:17 | | Quit DerPapst (Quit: Leaving.) |
| 00:15:59 | | Quit Keripo (Quit: Leaving.) |
| 00:16:25 | | Quit sideral (Quit: Leaving.) |
| 00:16:47 | | Quit froggyman (Quit: Ex-Chat) |
| 00:16:57 | | Join froggyman [0] (~seth@98.115.0.7) |
| 00:16:58 | | Quit froggyman (Changing host) |
| 00:16:58 | | Join froggyman [0] (~seth@unaffiliated/froggyman) |
| 00:18:30 | | Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) |
| 00:20:00 | | Join JesusFreak316 [0] (~JesusFrea@pool-173-65-59-203.tampfl.fios.verizon.net) |
| 00:28:57 | | Quit L-Strife89 (Quit: Vamoose!) |
| 00:41:01 | | Quit rasher (Ping timeout: 240 seconds) |
| 00:42:11 | | Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) |
| 00:42:39 | | Quit Judas_PhD (Quit: This is a quitting message) |
| 00:42:50 | | Quit Leif (Quit: Leaving) |
| 00:43:16 | | Quit Zambezi (Quit: 2weeks idletime.) |
| 00:43:28 | | Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) |
| 00:45:22 | | Quit ender` (Quit: Smoking is one of the leading causes of statistics.) |
| 00:46:45 | | Join rasher [0] (~rasher@rockbox/developer/rasher) |
| 00:46:53 | | Quit rasher (Client Quit) |
| 00:47:03 | | Join rasher_ [0] (~rasher@rockbox/developer/rasher) |
| 00:47:10 | | Nick rasher_ is now known as rasher (~rasher@rockbox/developer/rasher) |
| 00:54:41 | *** | Saving seen data "./dancer.seen" |
| 01:00 |
| 01:16:01 | | Quit bluebrother (Disconnected by services) |
| 01:16:03 | | Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) |
| 01:23:15 | | Quit wodz (Quit: Leaving) |
| 01:28:42 | | Quit Judas_PhD (Quit: This is a quitting message) |
| 01:32:36 | | Join GeekShad0w [0] (~Antoine@93.21.168.181) |
| 01:34:18 | | Join GeekSh4dow [0] (~Antoine@93.21.168.181) |
| 01:35:46 | | Quit dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) |
| 01:36:06 | | Quit GeekShadow (Ping timeout: 260 seconds) |
| 01:38:22 | | Quit GeekShad0w (Ping timeout: 264 seconds) |
| 01:40:59 | | Quit mudd1 (Read error: Operation timed out) |
| 01:43:21 | | Quit LambdaCalculus37 (Quit: This computer has gone to sleep) |
| 02:00 |
| 02:06:12 | | Quit pamaury (Remote host closed the connection) |
| 02:06:56 | | Quit efyx (Remote host closed the connection) |
| 02:10:24 | | Quit factor (Read error: Connection reset by peer) |
| 02:25:16 | | Quit saratoga (Quit: Page closed) |
| 02:26:55 | | Join factor [0] (~factor@75.108.68.114) |
| 02:27:03 | | Quit JesusFreak316 (Ping timeout: 246 seconds) |
| 02:30:12 | | Quit timccc (Quit: Leaving.) |
| 02:38:57 | | Quit robin0800 (Ping timeout: 246 seconds) |
| 02:39:10 | | Join Keripo [0] (~Keripo@eng125.wireless-resnet.upenn.edu) |
| 02:39:48 | | Join komputes [0] (~komputes@ubuntu/member/komputes) |
| 02:41:00 | | Quit GeekSh4dow (Quit: The cake is a lie !) |
| 02:44:35 | | Quit komputes (Read error: Connection reset by peer) |
| 02:45:35 | | Join timccc [0] (~timccc@112.166.15.141) |
| 02:53:44 | | Quit antil33t () |
| 02:54:44 | *** | Saving seen data "./dancer.seen" |
| 03:00 |
| 03:15:23 | | Quit silbo (Remote host closed the connection) |
| 03:26:52 | | Join Leif [0] (~LeifAnder@c-98-202-6-36.hsd1.ut.comcast.net) |
| 03:51:02 | | Quit Keripo (Ping timeout: 248 seconds) |
| 03:53:33 | | Join Keripo1 [0] (~Keripo@eng125.wireless-resnet.upenn.edu) |
| 03:57:13 | | Quit markun (Ping timeout: 240 seconds) |
| 04:00 |
| 04:00:50 | | Join T44 [0] (~Topy44@f048136241.adsl.alicedsl.de) |
| 04:01:31 | | Join markun [0] (~markun@ip503cd9a5.speed.planet.nl) |
| 04:01:32 | | Quit markun (Changing host) |
| 04:01:32 | | Join markun [0] (~markun@rockbox/developer/markun) |
| 04:03:26 | | Join JesusFreak316 [0] (~JesusFrea@pool-173-65-59-203.tampfl.fios.verizon.net) |
| 04:04:24 | | Quit Topy (Ping timeout: 246 seconds) |
| 04:05:50 | | Quit ChickeNES (Quit: Computer has gone to sleep.) |
| 04:07:38 | | Quit Keripo1 (Read error: Connection reset by peer) |
| 04:19:43 | | Join Barahir_ [0] (~jonathan@77.0.133.202) |
| 04:20:13 | | Join kugel [0] (~kugel@e178059120.adsl.alicedsl.de) |
| 04:20:13 | | Quit kugel (Changing host) |
| 04:20:13 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 04:21:04 | | Quit kugelp (Read error: Operation timed out) |
| 04:23:36 | | Quit Barahir (Ping timeout: 276 seconds) |
| 04:44:21 | | Quit amiconn (Disconnected by services) |
| 04:44:21 | | Join amiconn_ [0] (quassel@rockbox/developer/amiconn) |
| 04:44:34 | | Quit pixelma (Disconnected by services) |
| 04:44:36 | | Join pixelma_ [0] (quassel@rockbox/staff/pixelma) |
| 04:44:36 | | Nick amiconn_ is now known as amiconn (quassel@rockbox/developer/amiconn) |
| 04:44:39 | | Nick pixelma_ is now known as pixelma (quassel@rockbox/staff/pixelma) |
| 04:54:48 | *** | Saving seen data "./dancer.seen" |
| 04:55:06 | | Quit TheSeven (Ping timeout: 248 seconds) |
| 04:59:05 | | Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) |
| 05:00 |
| 05:22:57 | | Join Rob2223 [0] (~Miranda@p4FFF2EE4.dip.t-dialin.net) |
| 05:26:16 | | Quit Rob2222 (Ping timeout: 240 seconds) |
| 05:48:17 | | Quit mystica555 (Quit: Ekkusu Chatto) |
| 05:48:55 | | Join mystica555 [0] (~Mike@71-208-217-27.hlrn.qwest.net) |
| 05:54:21 | | Quit sinthetek (Read error: Operation timed out) |
| 05:54:28 | | Join sinthetek [0] (~sinthetek@unaffiliated/sinthetek) |
| 06:00 |
| 06:04:07 | | Quit JesusChrysler (Quit: JesusChrysler) |
| 06:12:21 | [Saint] | Is there any way I can browse *all* the patches on flyspray? |
| 06:12:52 | [Saint] | I mean, I know they're all still there, as I can view them by entering the task number...but, what if I don't *know* the task number? |
| 06:13:22 | [Saint] | the only solution I have found is hoping Google has some snippet about what I'm looking for that mentions a task number. |
| 06:13:56 | | Quit Leif (Quit: Leaving) |
| 06:21:56 | mc2739 | [Saint]: if you click the "+" to show advanced options, you have more search options |
| 06:24:05 | mc2739 | I don't think you can specify strictly patches, but you can filter on tasks with attachments |
| 06:24:50 | [Saint] | yes, but that only shows bug/patches that haven't been closed no? |
| 06:25:00 | [Saint] | I want to view ones that have been closed also. |
| 06:25:14 | mc2739 | you can select to show closed tasks also |
| 06:25:51 | [Saint] | Hmmm...I must be missing that, I'll take another look soon. Thanks. |
| 06:34:02 | | Join Horschti [0] (~Horscht@xbmc/user/horscht) |
| 06:37:44 | | Quit Horscht (Ping timeout: 258 seconds) |
| 06:42:35 | | Join BHSPitMonkey [0] (~stephen@unaffiliated/bhspitmonkey) |
| 06:54:43 | | Join Keripo [0] (~Keripo@eng125.wireless-resnet.upenn.edu) |
| 06:54:52 | *** | Saving seen data "./dancer.seen" |
| 07:00 |
| 07:04:34 | | Join byteframe [0] (~byteframe@unaffiliated/byteframe) |
| 07:04:58 | byteframe | arg I fuscking love my clip+ rockbox. |
| 07:06:02 | | Quit JesusFreak316 (Ping timeout: 246 seconds) |
| 07:06:09 | | Part byteframe ("Leaving.") |
| 07:22:09 | * | [Saint] wonders how hard it would be to use haptic feedback as opposed to an audible "click" for keyclick on devices that support it. |
| 07:24:53 | | Join Raptors [0] (~Raptors@dsl-69-171-129-91.acanac.net) |
| 07:25:06 | Raptors | is there a way to remove the list of recent bookmarks |
| 07:25:16 | Raptors | or a way to skip it? |
| 07:25:27 | Raptors | its soooo annoying |
| 07:26:53 | Raptors | I just want it to resume from the bookmark if I open a file with a bookmark, don't need to see a list of bookmarks (with not way around other then opening one of the bookmarks and choosing something else from playlist) everytime I open a podcast folder |
| 07:30:04 | [Saint] | settings - general settings - bookmarking - maintain a list of recent bookmarks - no |
| 07:30:10 | [Saint] | or, RTFM ;) |
| 07:30:14 | Raptors | I did tha |
| 07:30:15 | Raptors | t |
| 07:30:20 | Raptors | but it still pops up |
| 07:31:06 | [Saint] | then I suspect you're talking about automatic resume instead? |
| 07:31:26 | Raptors | no |
| 07:31:30 | Raptors | the list of bookmarks |
| 07:31:41 | Raptors | do I have to manually remove it or something? |
| 07:32:05 | [Saint] | No. If you've turned off "maintain a list of recent bookmarks" it shouldn't be there. |
| 07:32:18 | [Saint] | Or, you're not talking about what you think you are, or what I think you are. |
| 07:33:37 | Raptors | I think it might be because they are old bookmarks without files?! |
| 07:34:14 | Raptors | it doesn't do it on new bookmarks but in some of the podcast folders it does do it |
| 07:34:15 | Raptors | :/ |
| 07:35:14 | [Saint] | Have you by any chance set "Load last bookmark" to "ask"? |
| 07:35:22 | Raptors | No |
| 07:35:59 | Raptors | it must be a bug |
| 07:36:22 | Raptors | once I remove the bookmarks for files that doent exist the list doesn't popup |
| 07:36:40 | [Saint] | If it's only doing it for specific directories...I suspect you might be confusing bookmarking and automatic resume. |
| 07:37:08 | | Quit BHSPitMonkey (Quit: Ex-Chat) |
| 07:37:39 | [Saint] | If not, I have no idea what's going on. |
| 07:40:13 | Raptors | ugh there is an even more annoying bug now. I can't start any other podcast in that folder. It always opens up the very last bookmark in the last file |
| 07:40:38 | Raptors | even if I choose some other file from the list |
| 07:40:52 | * | Raptors is uber confused |
| 07:40:55 | [Saint] | That has me pretty much convinced that you're messing up bookmarking and automatic resume features. |
| 07:41:09 | [Saint] | Have a read of the manual regarding these areas. |
| 07:41:28 | Raptors | No that is bookmarking |
| 07:42:03 | Raptors | Even if I choose another file from the folder it always opens the last file |
| 07:42:14 | Raptors | the only other way to get past it is to use next |
| 07:42:19 | [Saint] | Turn off "load last bookmark" then. |
| 07:42:23 | [Saint] | and, read the manual. |
| 07:42:32 | Raptors | and the file one was about bookmarking list |
| 07:43:23 | Raptors | [Saint], load last bookmark opens up the last file too? |
| 07:43:35 | Raptors | I thought it just opened up the last bookmark in the file chosen |
| 07:43:42 | Raptors | that is a stupid feature |
| 07:45:30 | * | Raptors goes to find manual |
| 07:46:27 | Raptors | Load Last Bookmark. |
| 07:46:27 | Raptors | This option controls if Rockbox should automatically load a bookmark for a file, when that file is played. |
| 07:46:36 | Raptors | That is not what I'm saying |
| 07:46:42 | Raptors | it opens up the last file too |
| 07:46:47 | Raptors | I can't play anything else |
| 07:46:54 | Raptors | it has to be a bug |
| 07:47:54 | | Join OsxFailer [0] (~cdc84e8a@giant.haxx.se) |
| 07:48:01 | [Saint] | Update to a current build, see if you can reproduce it, and if you can, put the "recipie" on the tracker. |
| 07:48:30 | Raptors | wouldn't that erase everything on it? |
| 07:48:36 | [Saint] | No. |
| 07:48:50 | Raptors | how do I update to the latest build? |
| 07:48:53 | [Saint] | backup your config.cfg if you're worried. |
| 07:49:40 | Raptors | I made the lastest build like couple months ago so I forgot :/ |
| 07:50:34 | Raptors | nvm |
| 07:50:36 | Raptors | I found the page |
| 07:50:39 | OsxFailer | Hey everyone |
| 07:51:21 | [Saint] | Raptors: http://www.rockbox.org/wiki/RockboxUtility |
| 07:51:34 | [Saint] | sorry, just had a big-ass earthquake here :| |
| 07:51:48 | Raptors | o you don't mean the latest from svn/ |
| 07:51:50 | Raptors | ? |
| 07:52:58 | [Saint] | Yes, I do. |
| 07:53:24 | | Join sideral [0] (~sideral@213.165.85.248) |
| 07:53:24 | | Quit sideral (Changing host) |
| 07:53:24 | | Join sideral [0] (~sideral@rockbox/developer/sideral) |
| 07:53:30 | Raptors | then why did you point me to rockboxutility? |
| 07:53:36 | Raptors | it can install svn version? |
| 07:53:40 | [Saint] | To install the latest build? |
| 07:53:44 | Raptors | it can install svn version? |
| 07:53:47 | [Saint] | yes. |
| 07:53:52 | | Quit OsxFailer (Quit: CGI:IRC) |
| 07:59:49 | Raptors | [Saint], same thing happens |
| 08:00 |
| 08:01:06 | [Saint] | Raptors: You can make a bug report regarding the issue here: http://www.rockbox.org/tracker/ |
| 08:01:37 | [Saint] | Include as much detail as you think is relevant, but pay particular attention to replicating the issue. |
| 08:01:48 | [Saint] | and, thankyou. |
| 08:04:34 | | Join stoffel [0] (~quassel@p57B4BFD9.dip.t-dialin.net) |
| 08:38:04 | | Quit wtachi (Quit: WeeChat 0.3.4) |
| 08:44:23 | | Join slooopy [0] (~sloo@95-90-30-123-dynip.superkabel.de) |
| 08:54:53 | *** | Saving seen data "./dancer.seen" |
| 08:57:50 | | Quit stoffel (Remote host closed the connection) |
| 08:58:07 | | Quit JackWinter (Ping timeout: 252 seconds) |
| 08:59:39 | | Join stoffel [0] (~quassel@p57B4BFD9.dip.t-dialin.net) |
| 09:00 |
| 09:05:20 | | Join JackWinter [0] (~jack@vodsl-9173.vo.lu) |
| 09:21:54 | | Join n1s [0] (~quassel@rockbox/developer/n1s) |
| 09:29:04 | | Quit sideral (Ping timeout: 240 seconds) |
| 09:29:26 | | Join utanapischti [0] (~username@p4FF2DBDB.dip.t-dialin.net) |
| 09:32:39 | | Quit sasquatch (Ping timeout: 240 seconds) |
| 09:43:48 | | Join Zambezi [0] (Zulu@80.67.9.2) |
| 09:47:16 | | Part DrDnar1 |
| 09:56:32 | | Join Stummi [0] (~Stummi@rockbox/developer/Stummi) |
| 10:00 |
| 10:01:45 | pixelma | Raptors: maybe save your current settings and paste the content of config.cfg in the .rockbox folder (or the file itself) to a pastebin site. Also - which target do you have? |
| 10:02:27 | Raptors | kk |
| 10:06:04 | Raptors | pixelma, http://pastebin.com/q71BKCQC |
| 10:06:37 | | Join Jerom [0] (~jerome@koe67-6-78-244-229-246.fbx.proxad.net) |
| 10:06:51 | | Quit Jerom (Client Quit) |
| 10:07:12 | Raptors | http://pastebin.com/JcftWy1J |
| 10:08:30 | n1s | TheSeven: does a classic charge in the emcore menu? |
| 10:09:56 | jhMikeS | bam! http://www.rockbox.org/tracker/task/12069 |
| 10:10:30 | Raptors | ????? |
| 10:10:40 | n1s | jhMikeS: whoa! |
| 10:10:45 | [Saint] | good work. |
| 10:10:49 | Raptors | what is it? |
| 10:10:50 | [Saint] | you kept that quiet. |
| 10:10:57 | [Saint] | Raptors: nevermind. |
| 10:11:03 | [Saint] | A new playback engine. |
| 10:11:17 | jhMikeS | [Saint]: I just shut up around here and codec, as I'm apt to do with large projects |
| 10:11:22 | Raptors | How could someone keep that quiet :/ |
| 10:11:25 | jhMikeS | *coded even |
| 10:11:54 | jhMikeS | [Saint]: First stages of radical surgery anyway |
| 10:11:56 | Raptors | Is it more efficient? |
| 10:12:09 | [Saint] | jhMikeS: Less "Oh, really?...you did it like *that?!?*" ;) |
| 10:12:15 | n1s | jhMikeS: so a big wound to suture up now? ;) |
| 10:12:37 | jhMikeS | Raptors: I don't know. It's certainly more through about things :) |
| 10:12:58 | Raptors | Does it add anything new? |
| 10:13:00 | jhMikeS | n1s: hopefully it can be outpatient :) |
| 10:13:16 | * | Raptors reads detail |
| 10:13:34 | jhMikeS | Raptors: addresses long standing bugs about seeking and anything else i could find in the immediate area but tries not to add features |
| 10:13:57 | Raptors | o... |
| 10:14:00 | Raptors | good work |
| 10:14:24 | Raptors | must of took you a long time to make that patch |
| 10:14:36 | [Saint] | jhMikeS: is "AUDIO_FAST_SKIP_PREVIEW" a type of scrubing? or am I being too literal? |
| 10:14:46 | jhMikeS | when did I last speak much around here? when I went most silent is when I got started. |
| 10:15:05 | jhMikeS | [Saint]: Metadata scrubbing? |
| 10:15:43 | jhMikeS | It lets the WPS keep up with each click, the way it should work, not how it is, and not with clobbering the playback engine's bookkeeping. |
| 10:15:46 | [Saint] | Oh, obviously not. I looked at the function name and assumed it was something to allow audio playback whilst seeking. |
| 10:15:53 | [Saint] | (which would be very, very cool) |
| 10:16:18 | jhMikeS | Better chance of that now since the codec can be controlled like that |
| 10:16:34 | jhMikeS | one thing at a time though :) |
| 10:16:41 | * | [Saint] nods. |
| 10:17:07 | | Join ender` [0] (krneki@84.255.206.8) |
| 10:18:03 | n1s | jhMikeS: so doe sthis adress the weirdness caused by track changes not happening at the same time in wps and playback? |
| 10:18:15 | [Saint] | RB is one of the very few DAP OSes (that's worth mentioning) that doesn't do scrubbing/seek-preview iiuc. It's nice to have. |
| 10:18:17 | jhMikeS | n1s: yes |
| 10:18:21 | n1s | cool |
| 10:19:12 | | Join Luca_S [0] (~5d925151@giant.haxx.se) |
| 10:19:13 | [Saint] | Wooo! %Pe/s tags will work correctly now! ;) |
| 10:19:16 | jhMikeS | one place it cannot avoid a pre-increment is at playlist boundaries (directory change) because playlists just can't peek into the next one |
| 10:20:30 | * | jhMikeS quite throughly lacks WPS tag knowledge |
| 10:20:44 | pixelma | I don't think that keeping quiet about such a work is a good idea |
| 10:20:44 | [Saint] | Playback starts.ends |
| 10:20:46 | Raptors | out of curiosity why didn't you just release small patches instead of one mega patch? |
| 10:20:52 | [Saint] | s/./// |
| 10:21:08 | Luca_S | screw testing, commit it :D |
| 10:21:15 | Luca_S | congratulations jhMikeS! |
| 10:21:16 | jhMikeS | Raptors: codec API redesign |
| 10:21:17 | [Saint] | errr...no. |
| 10:21:22 | Raptors | o... |
| 10:21:55 | jhMikeS | [Saint]: report! |
| 10:22:29 | [Saint] | Presently the %Pe/s tags are quite a ways out from their timeout, compared to the time that they fire. |
| 10:22:32 | pixelma | Raptors: this setting looks like it needs changing (but I don't use bookmarking myself so am not sure): use most-recent-bookmarks: on |
| 10:22:38 | Luca_S | re: my uSD problems on fuzev2 have been solved by switching to a different uSD. the problematic uSD works fine in my phone, i'm back to 100% satisfaction :) thanks to everybody that helped. I'll report on FS too |
| 10:22:43 | [Saint] | I expect this related to the timing issues you're talking about. |
| 10:23:36 | [Saint] | %Pe(10) is supposed to go true 10 seconds before the current track ends. |
| 10:23:47 | [Saint] | realistically it's closer to ~7 seconds or so. |
| 10:23:55 | Luca_S | jhMikeS: on which player did you test your patch? is it player-independant? |
| 10:24:27 | jhMikeS | Luca_S: x5, beast and clip so far, a bit on e200 |
| 10:24:53 | jhMikeS | [Saint]: Normally the pcm delay is 3 seconds |
| 10:25:15 | [Saint] | jhMikeS: Aha...well, that makes perfect sense then ;) |
| 10:25:51 | jhMikeS | but the remaining times should be latency adjust or the WPS would be wrong |
| 10:25:58 | [Saint] | I was looking for the problem in the skin code solely, and, that is *not* my domain. Turns out even if it was I'd never have found it. |
| 10:26:00 | [Saint] | heh. |
| 10:27:21 | jhMikeS | pixelma: sorry, I become a cave dweller with big works or I get too distracted |
| 10:27:56 | | Quit n1s (Remote host closed the connection) |
| 10:28:11 | jhMikeS | at least I didn't come back with 10 commandments or something, but more bearded, indeed :) |
| 10:28:56 | Raptors | pixelma, that just turns off load last bookmark |
| 10:29:16 | [Saint] | Hell, at least you came in and said "Hey, looky what I got!" instead of just dumping it in svn. |
| 10:32:52 | jhMikeS | [Saint]: :P Oh, I was tempted...and it wouldn't have been the first time if I did. |
| 10:33:08 | [Saint] | but, you *didn't* ;) |
| 10:33:15 | Raptors | dumping on SVN FTW |
| 10:33:19 | jhMikeS | Is that a dare? |
| 10:33:29 | [Saint] | People only complain about ninja commits like that if it's a contentious feature though really. |
| 10:33:59 | jhMikeS | If it deals with features, it only tries to make them work more how one would expect. |
| 10:34:10 | jhMikeS | Things like autoresume |
| 10:34:17 | [Saint] | Or, if it's horribly untested and breaks stuff...even if it isn't even remotely contentious. |
| 10:34:43 | Raptors | jhMikeS, add load last bookmark to that list |
| 10:34:44 | jhMikeS | it shouldn't, I've been checking that along the way |
| 10:34:59 | Raptors | it literally loads the last bookmark regardless of what file you chose |
| 10:35:04 | Raptors | in that folder :/ |
| 10:35:26 | pixelma | [Saint]: I'd also complain about such a "ninja commit" if it changes things fundamentally and hasn't been tested enough |
| 10:35:32 | [Saint] | I think that's you more having a predetermined view (which is apparently incorrect) of how something should work. |
| 10:35:40 | [Saint] | wanting something to work differently != bug. |
| 10:35:49 | jhMikeS | Raptors: a bug in bookmarking? the playback code really doesn't deal with those. |
| 10:35:50 | pixelma | and the playback engine needs thoroughly testing |
| 10:35:52 | [Saint] | Raptors: : ^ |
| 10:36:11 | Raptors | heh |
| 10:36:16 | Raptors | Who deals with bookmarking? |
| 10:37:06 | jhMikeS | pixelma: changes nothing as far as features, fundamentally speaking, except to correct what makes them work in a half-baked way |
| 10:37:39 | jhMikeS | cuesheets now don't need reboot to enable or disable |
| 10:38:20 | | Join leavittx [0] (~leavittx@89.221.199.187) |
| 10:38:37 | jhMikeS | autoresume on already buffered tracks didn't always autoresume per the settings but now they should |
| 10:39:24 | [Saint] | I'll give it a whirl on RaaA shortly. I don't suppose you checked there? |
| 10:39:28 | Raptors | isn't there a way to tell it to autoresume? |
| 10:39:33 | jhMikeS | rewind at track changes or end of plalist: works |
| 10:39:34 | Raptors | I swear I saw a setting for it |
| 10:39:54 | [Saint] | Raptors: Yes, there is. Check the manual. |
| 10:40:11 | Raptors | Then what does jhMikeS want to change? :/ |
| 10:40:16 | jhMikeS | Raptors: in general settings (where you not expect it to be) and you must have the database enabled |
| 10:40:25 | | Quit factor (Ping timeout: 252 seconds) |
| 10:40:27 | Raptors | o... |
| 10:41:00 | jhMikeS | Raptors: bugs and fragility due to races |
| 10:41:58 | pixelma | jhMikeS: like always wasting RAM? ;) But a "rewrite" doesn't sound as if it doesn't change something fundamentally, I just think that if lots of code has changed there will be new bugs, something "coming back" that had been fixed before even if it was in a hackish way. Playback engine is a major part and everyone uses different features and ways of listening. There are so many places for bugs, one dev can never think of all :| |
| 10:42:35 | Raptors | well if someone knows who deals with bookmarking that I can talk to leave me a PM. (I already filed a bug report) |
| 10:42:39 | * | Raptors goes to sleep |
| 10:42:44 | pixelma | I'm not against your work and maybe it really helps but it is such a fragile thing in my eyes |
| 10:42:58 | [Saint] | Raptors: There's not really "developers that deal with X" |
| 10:43:03 | jhMikeS | pixelma: that's why there a FS task, to check that stuff out |
| 10:43:07 | [Saint] | People work on what they want to work on. |
| 10:44:17 | Raptors | I know that but I though there would be at least 1 person who usually works on bookmarking... |
| 10:44:41 | jhMikeS | pixelma: there are reasons it's fragile, at least inside the playback code |
| 10:45:05 | | Join factor [0] (~factor@75.108.68.114) |
| 10:45:15 | pixelma | I don't mean the current playback engine, it is more about the importance of it |
| 10:46:33 | pixelma | and the power (and curse) of it |
| 10:46:33 | * | jhMikeS never hesitated to majorly revamp the kernel either |
| 10:46:33 | * | jhMikeS is crazy like that though |
| 10:51:12 | DEBUG | EOF from server (Connection reset by peer) (snapshot: netstuff.c line 545) |
| 10:51:12 | *** | Cleanup |
| 10:51:12 | *** | Cleanup |
| 10:51:12 | *** | Saving seen data "./dancer.seen" |
| 10:51:12 | *** | Exit |
| 10:51:14 | *** | Started Dancer V4.16 |
| 10:51:14 | *** | Connected to irc.freenode.net on port 6667 |
| 10:51:14 | *** | Logfile for #rockbox started |
| 10:51:15 | Mode | "logbot :+i" by logbot |
| 10:51:18 | *** | Server message 501: 'logbot :Unknown MODE flag' |
| 10:51:19 | | Join logbot [0] (~rockbox@giant.haxx.se) |
| 10:51:19 | | Join factor [0] (~factor@75.108.68.114) |
| 10:51:19 | | Join leavittx [0] (~leavittx@89.221.199.187) |
| 10:51:19 | | Join Luca_S [0] (~5d925151@giant.haxx.se) |
| 10:51:19 | | Join ender` [0] (krneki@84.255.206.8) |
| 10:51:19 | | Join Stummi [0] (~Stummi@rockbox/developer/Stummi) |
| 10:51:19 | | Join Zambezi [0] (Zulu@80.67.9.2) |
| 10:51:19 | | Join utanapischti [0] (~username@p4FF2DBDB.dip.t-dialin.net) |
| 10:51:19 | | Join JackWinter [0] (~jack@vodsl-9173.vo.lu) |
| 10:51:19 | | Join stoffel [0] (~quassel@p57B4BFD9.dip.t-dialin.net) |
| 10:51:19 | | Join slooopy [0] (~sloo@95-90-30-123-dynip.superkabel.de) |
| 10:51:19 | | Join Raptors [0] (~Raptors@dsl-69-171-129-91.acanac.net) |
| 10:51:19 | | Join Keripo [0] (~Keripo@eng125.wireless-resnet.upenn.edu) |
| 10:51:19 | | Join Horschti [0] (~Horscht@xbmc/user/horscht) |
| 10:51:19 | | Join sinthetek [0] (~sinthetek@unaffiliated/sinthetek) |
| 10:51:19 | | Join mystica555 [0] (~Mike@71-208-217-27.hlrn.qwest.net) |
| 10:51:19 | | Join Rob2223 [0] (~Miranda@p4FFF2EE4.dip.t-dialin.net) |
| 10:51:19 | | Join TheSeven [0] (~TheSeven@rockbox/developer/TheSeven) |
| 10:51:19 | | Join pixelma [0] (quassel@rockbox/staff/pixelma) |
| 10:51:19 | | Join amiconn [0] (quassel@rockbox/developer/amiconn) |
| 10:51:19 | | Join kugel [0] (~kugel@rockbox/developer/kugel) |
| 10:51:19 | | Join Barahir_ [0] (~jonathan@77.0.133.202) |
| 10:51:19 | | Join markun [0] (~markun@rockbox/developer/markun) |
| 10:51:19 | | Join T44 [0] (~Topy44@f048136241.adsl.alicedsl.de) |
| 10:51:19 | | Join timccc [0] (~timccc@112.166.15.141) |
| 10:51:19 | | Join bluebroth3r [0] (~dom@rockbox/developer/bluebrother) |
| 10:51:19 | | Join rasher [0] (~rasher@rockbox/developer/rasher) |
| 10:51:19 | | Join froggyman [0] (~seth@unaffiliated/froggyman) |
| 10:51:19 | | Join avacore [0] (~avacore@1008ds1-rdo.0.fullrate.dk) |
| 10:51:19 | | Join jhMikeS [0] (~jethead71@rockbox/developer/jhMikeS) |
| 10:51:19 | | Join krazykit [0] (~krazykit@99-126-205-52.lightspeed.cicril.sbcglobal.net) |
| 10:51:19 | | Join pepsi [0] (~pepsi@unaffiliated/jbutera) |
| 10:51:19 | | Join bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com) |
| 10:51:19 | | Join jae [0] (~jae@dedicated.jaerhard.com) |
| 10:51:19 | | Join mt [0] (~mtee@rockbox/developer/mt) |
| 10:51:19 | | Join fyrestorm [0] (~nnscript@cpe-68-173-236-235.nyc.res.rr.com) |
| 10:51:19 | | Join Guinness [0] (Slayer@c-68-55-111-159.hsd1.va.comcast.net) |
| 10:51:19 | | Join maraz [0] (maraz@kapsi.fi) |
| 10:51:19 | | Join Torne [0] (~torne@rockbox/developer/Torne) |
| 10:51:19 | | Join [Saint] [0] (~St.]@124-197-14-130.callplus.net.nz) |
| 10:51:19 | | Join jordan` [0] (gromit@2a01:e34:eebf:c890:21a:4dff:fe63:6966) |
| 10:51:19 | | Join mc2739 [0] (~mc2739@rockbox/developer/mc2739) |
| 10:51:19 | | Join swilde [0] (~wilde@aktaia.intevation.org) |
| 10:51:19 | | Join user890104 [0] (~Venci@6bez10.info) |
| 10:51:19 | | Join balintx [0] (~quassel@szerver1.gulyasp-koll.sulinet.hu) |
| 10:51:19 | | Join bluefoxx [0] (fuzzylomba@S0106485b3917092d.vs.shawcable.net) |
| 10:51:19 | | Join amee2k [0] (~thomas@ve504.cugnet.net) |
| 10:51:19 | | Join jfc [0] (~john@72.73.80.12) |
| 10:51:19 | | Join z35 [0] (~z35@ool-18bdad71.dyn.optonline.net) |
| 10:51:19 | | Join martii [0] (martii@sokrates.mimuw.edu.pl) |
| 10:51:19 | | Join Zarggg [0] (~zarggg@24.229.139.169.res-cmts.sm.ptd.net) |
| 10:51:19 | | Join Buganini [0] (~buganini@security-hole.info) |
| 10:51:19 | | Join JdGordon [0] (~jonno@rockbox/developer/JdGordon) |
| 10:51:19 | | Join pikytcus [0] (~bigd@failbox.co.cc) |
| 10:51:19 | | Join boghog [0] (~aphax@2001:980:34c7:0:1e6f:65ff:fe86:1e03) |
| 10:51:19 | | Join bluefoxx_ [0] (~bluefoxx_@S010600216b36c2a8.vs.shawcable.net) |
| 10:51:19 | | Join evilnick_B [0] (0c140464@rockbox/staff/evilnick) |
| 10:51:19 | | Join Xerion [0] (~xerion@5419A4D7.cm-5-2c.dynamic.ziggo.nl) |
| 10:51:19 | | Join simonlnu [0] (simon@unaffiliated/simonrvn) |
| 10:51:19 | | Join Strife89 [0] (~Strife89@168.16.226.152) |
| 10:51:19 | | Join FoolOnHill [0] (~foh@adsl-71-68-84.bhm.bellsouth.net) |
| 10:51:19 | | Join Llorean [0] (~DarkkOne@rockbox/user/Llorean) |
| 10:51:19 | | Join Elfish [0] (amba@2a01:4f8:100:90a1:abc:abc:abc:abc) |
| 10:51:19 | | Join ender| [0] (krneki@foo.eternallybored.org) |
| 10:51:19 | | Join yosafbridge [0] (~yosafbrid@li125-242.members.linode.com) |
| 10:51:19 | | Join logvelc [0] (~erik@elbereth.midgard.liu.se) |
| 10:51:19 | | Join scorche|sh [0] (~scorche@rockbox/administrator/scorche) |
| 10:51:19 | | Join advcomp2019_ [0] (~advcomp20@unaffiliated/advcomp2019) |
| 10:51:19 | | Join linuxstb [0] (~linuxstb@rockbox/developer/linuxstb) |
| 10:51:19 | | Join DX3 [0] (~Dre@92.18.105.207) |
| 10:51:19 | | Join dionoea [0] (~dionoea@videolan/developer/dionoea) |
| 10:51:19 | | Join linuxguy3 [0] (~timj@adsl-76-202-250-104.dsl.emhril.sbcglobal.net) |
| 10:51:19 | | Join ps-auxw [0] (~arneb@2001:470:c807:0:1532:4e5f:2ad3:4123) |
| 10:51:19 | | Join Rondom [0] (~rondom@nonmodosedetiam.net) |
| 10:51:19 | | Join Galois [0] (djao@efnet-math.org) |
| 10:51:19 | | Join soap_ [0] (~soap@rockbox/staff/soap) |
| 10:51:19 | | Join Bagder [0] (~daniel@rockbox/developer/bagder) |
| 10:51:19 | | Join AlexP [0] (~alex@rockbox/staff/AlexP) |
| 10:51:19 | | Join n17ikh [0] (~n17ikh@c-68-59-25-51.hsd1.sc.comcast.net) |
| 10:51:19 | | Join scorche [0] (~scorche@rockbox/administrator/scorche) |
| 10:51:19 | | Join simabeis_ [0] (~simabeis@lobmenschen.de) |
| 10:51:19 | | Join jepler [0] (~jepler@emc/developer/pdpc.professional.jepler) |
| 10:51:19 | | Join YPSY [0] (~ypsy@geekpadawan.de) |
| 10:51:19 | | Join alexbobp [0] (~alex@ppp-70-253-78-241.dsl.austtx.swbell.net) |
| 10:51:19 | | Join Unhelpful [0] (~quassel@rockbox/developer/Unhelpful) |
| 10:51:19 | | Join kkit|sh [0] (~kkit@li135-248.members.linode.com) |
| 10:51:19 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
| 10:51:19 | | Join bthomson [0] (~bthomson@pool-71-114-64-197.washdc.dsl-w.verizon.net) |
| 10:51:19 | | Join pjm0616 [0] (~user@110.9.28.45) |
| 10:51:19 | | Join mikroflops_ [0] (~yogurt@h-34-156.A238.priv.bahnhof.se) |
| 10:51:19 | | Join cjcopi [0] (~craig@adsl-76-241-118-43.dsl.bcvloh.sbcglobal.net) |
| 10:51:19 | | Join niekie [0] (~niek@CAcert/Assurer/niekie) |
| 10:51:19 | | Join feisar-_ [0] (jljhook@ihq.in) |
| 10:51:19 | | Join aevin [0] (eivindsy@unaffiliated/aevin) |
| 10:51:19 | | Join gevaerts [0] (~fg@rockbox/developer/gevaerts) |
| 10:51:19 | | Join knittl [0] (~knittl@unaffiliated/knittl) |
| 10:51:19 | | Join guymann [0] (~charles@adsl-69-177-39-115.adsl.snet.net) |
| 10:51:19 | | Join [fred] [0] (fred@ircop.efnet.at) |
| 10:51:19 | | Join Battousai [0] (~bryan@gentoo/developer/battousai) |
| 10:51:19 | | Join tguinot [0] (~tguinot@ks22840.kimsufi.com) |
| 10:51:19 | | Join bzed [0] (~bzed@2001:6f8:118a::100) |
| 10:51:19 | | Join ack` [0] (~ack@mingbai.org) |
| 10:51:19 | | Join elcan [0] (user36@pr0.us) |
| 10:51:19 | | Join preglow [0] (thomj@rockbox/developer/preglow) |
| 10:51:19 | | Join kisak [0] (~kisak@pool-72-70-187-188.hrbgpa.fios.verizon.net) |
| 10:51:19 | | Join crwl [0] (~crwlll@dsl-jklbrasgw1-fe8edf00-29.dhcp.inet.fi) |
| 10:51:19 | | Join parafin [0] (parafin@paraf.in) |
| 10:51:19 | | Join b42 [0] (~b42@178.72.210.42) |
| 10:51:19 | | Join TBFOOL [0] (~tb@c-3c3671d5.09-42-73746f22.cust.bredbandsbolaget.se) |
| 10:51:19 | | Join @ChanServ [0] (ChanServ@services.) |
| 10:51:19 | | Join ranmachan [0] (ranma@yumi.tdiedrich.de) |
| 10:51:19 | | Join olejorgenb [0] (bronner@caracal.stud.ntnu.no) |
| 10:51:19 | | Join ThomasAH [0] (~thomas@aktaia.intevation.org) |
| 10:51:19 | | Join Hadaka [0] (~naked@naked.iki.fi) |
| 10:51:19 | | Join jvoisin [0] (~jvoisin@ks22840.kimsufi.com) |
| 10:51:19 | | Join FOAD [0] (~dok@83.161.135.61) |
| 10:51:19 | | Join zu [0] (~zu@ks355000.kimsufi.com) |
| 10:51:19 | | Join Utchy [0] (~Utchy@rps6752.ovh.net) |
| 10:51:19 | | Join ved [0] (ved@ddsbox.co.cc) |
| 10:51:19 | | Join merbanan [0] (~banan@c-83-233-242-230.cust.bredband2.com) |
| 10:51:19 | | Join Farthen [0] (~Farthen@static.225.178.40.188.clients.your-server.de) |
| 10:51:19 | | Join CIA-87 [0] (~CIA@208.69.182.149) |
| 10:51:19 | | Join literal [0] (hinrik@w.nix.is) |
| 10:51:59 | [Saint] | I thought (or was under the impression) that *everything* revolved around the hideous bitch-goddess that is the playback engine...? |
| 10:52:29 | jhMikeS | I do know of some tiny glitches, but it's too far to go addressing that since the features still operate |
| 10:52:57 | jhMikeS | [Saint]: but I now know goddess pretty well :P |
| 10:53:48 | jhMikeS | there is no goddess but goddess, hail eris! |
| 10:59:42 | [Saint] | While I do agree that more communication would have been nice, I must say that I do admire jhMikeS for wanting to, let alone actually achieving, wiping two of the biggest asses in Rockbox presently. |
| 10:59:48 | [Saint] | (buffering and playback) |
| 10:59:54 | jhMikeS | lol |
| 11:00 |
| 11:00:28 | jhMikeS | rockbox is muticheeked |
| 11:03:22 | pixelma | well, how do you know it's really better and if you don't buy an improvement in one area with the opposite in to others? I don't. Sorry to sound so negative but I think a bit of doubts are allowed. It needed years to factor out q huge number of bugs with the current engine and to even find those bugs as (like I said people are using playback in such various ways I could never imagined) |
| 11:03:42 | pixelma | *in two others |
| 11:05:38 | jhMikeS | to really wipe the bugs, things need a solid foundation. best thing to do is just run the patch using it your own way and see. |
| 11:05:38 | [Saint] | well, no one will ever know if it could be better without rebuilding the current system and getting it tested. |
| 11:05:38 | [Saint] | So, I still say "good on him". |
| 11:05:42 | [Saint] | It's not committed, so it's not breaking anything presently. |
| 11:06:28 | pixelma | communication helps |
| 11:07:19 | [Saint] | It does, yes, and although communication during the process of writing it would have been beneficial perhaps...it can't happen *now*. |
| 11:07:20 | jhMikeS | certain bugs won't ever get fixed unless someone dives in and corrects things and some of that isn't minor tweaking, it's acutally _designing_ it this time around. |
| 11:08:03 | [Saint] | I don't necessarily agree with jhMikeS shutting himself in a hole to write this, but in some ways, I can see why he chose to do so. |
| 11:08:37 | jhMikeS | things like handling broken playlists have been worked on, in as much as playlists don't try to be smart and take too much control |
| 11:08:37 | | Join pamaury [0] (~quassel@vit94-1-82-67-248-70.fbx.proxad.net) |
| 11:08:37 | | Quit pamaury (Changing host) |
| 11:08:37 | | Join pamaury [0] (~quassel@rockbox/developer/pamaury) |
| 11:09:10 | | Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) |
| 11:09:42 | jhMikeS | it's not at the mercy of the presence of codecs to drive all track changes either |
| 11:10:46 | jhMikeS | [Saint]: why not? that's the approved occultist method :) |
| 11:11:06 | jhMikeS | of course, I might be the only one here that approves of such things |
| 11:11:42 | [Saint] | Well, for the same reason as pixelma said, communication is good...but for the same reason I said, I can also see why you may not have wanted to do so. |
| 11:11:57 | [Saint] | Communication can also be very enfuriating and oppressive at times ;) |
| 11:12:06 | jhMikeS | I can't think clearly like that...that's all :) |
| 11:14:05 | | Quit JackWinter (Remote host closed the connection) |
| 11:20:01 | pixelma | I really don't want to dismiss the work being done here, I just don't like the way it was done behind the scenes. It doesn't help with our bus factor problem and e.g. we also want our GSoC students to communicate |
| 11:21:00 | jhMikeS | if you don't want, I'll just keep it as a personal patch :) |
| 11:22:29 | pixelma | that's not what I said |
| 11:25:06 | jhMikeS | yes, I sort of have my skunkworks, I did mention that what I was working on however, mostly to Buschel |
| 11:25:14 | jhMikeS | his playlist workarounds aren't necessary with this |
| 11:31:54 | | Join MethoS- [0] (~clemens@134.102.106.250) |
| 11:33:44 | | Quit Luca_S (Quit: CGI:IRC (Ping timeout)) |
| 11:36:47 | * | jhMikeS will run through fs and check any bug report that could be connected to the engine itself |
| 11:48:02 | | Join Luca_S [0] (~5d925151@giant.haxx.se) |
| 12:00 |
| 12:16:37 | | Quit Luca_S (Quit: CGI:IRC (EOF)) |
| 12:19:21 | | Quit Judas_PhD (Quit: This is a quitting message) |
| 12:22:32 | | Join TheLemonMan [0] (~lem0n@ppp-206-131.98-62.inwind.it) |
| 12:23:13 | pamaury | anyone know how "time_t time(time_t *timer)" is implemented in modern glibc ? It does not call __SYS_time and I can't find it in the glibc source code :-/ |
| 12:24:05 | * | [Saint] wonders what his RaaA build is complaining about: http://pastebin.com/gCTQLC1i |
| 12:24:37 | | Join leavittx_ [0] (~leavittx@89.221.199.187) |
| 12:30:57 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
| 12:32:11 | | Quit TheLemonMan (Ping timeout: 276 seconds) |
| 12:34:08 | | Join TheLemonMan [0] (~lem0n@ppp-206-131.98-62.inwind.it) |
| 12:35:58 | jhMikeS | [Saint]: endian.h conflicts with system.h for some byteswap macros (thought I recall macros that look out for that) :\ |
| 12:36:09 | AlexP | jhMikeS: So should this work as a drop in patch at present? As in apply and just see if things still work (for testing)? |
| 12:37:56 | jhMikeS | AlexP: yes |
| 12:38:03 | AlexP | jhMikeS: OK, I'll have a play :) |
| 12:38:22 | AlexP | jhMikeS: Oh, and does it affect things like potential GSoC bufflib projects? |
| 12:39:11 | jhMikeS | I need to look at those. It might even facilitate them in a small if I caught on to what that's about. |
| 12:40:17 | AlexP | OK - we are in the process of interviewing for them so it would be good to know - it seems unfair to pull the rug out from under students' feet at this point |
| 12:40:49 | jhMikeS | wasn't there an issue about memory compaction? I remember kugel saying something. |
| 12:41:41 | AlexP | Ideas are here: http://www.rockbox.org/wiki/SummerOfCode2011#Port_buflib_from_the_pluginlib_over_to_the_core_and_use_it_to_allocate_big_buffers_in_a_more_dynamic_way. |
| 12:41:52 | AlexP | Also the nect one on standalone playback library |
| 12:42:02 | AlexP | I can send you the proposals as well |
| 12:42:04 | jhMikeS | looks like we just sneak in malloc around the back door :) |
| 12:42:52 | AlexP | jhMikeS: PM? |
| 12:42:52 | [Saint] | jhMikeS: basically, what I was asking is...do those warnings point to anything I should be looking at in particular, or is it nothing to bother about? |
| 12:43:07 | | Join skapazzo [0] (~skapazzo@195.81.67.123) |
| 12:44:12 | jhMikeS | [Saint]: might not be a problem |
| 12:45:55 | [Saint] | I'll revert everything in my tree and see if it still complains about svn head, if it's something I've introduced I won't bother too hard looking for it ;) |
| 12:46:22 | [Saint] | I only have some very trivial patches in my tree though :/ |
| 12:46:47 | jhMikeS | heh, not testing mine out? :( |
| 12:47:16 | jhMikeS | oh, right, that one's pretty trivial :p |
| 12:48:16 | [Saint] | Heh, no I haven't added that in yet. These warnings caught my eye. |
| 12:48:52 | [Saint] | It's nice that your patch doesn't mess up anything in my tree, that's a rare treat ;) |
| 12:51:15 | *** | Saving seen data "./dancer.seen" |
| 12:52:48 | | Join DerPapst [0] (~Alexander@p57954722.dip.t-dialin.net) |
| 12:54:30 | jhMikeS | surely I would have made a malpatch :) |
| 12:55:45 | skapazzo | hy, good day to everyone |
| 13:00 |
| 13:01:19 | | Join Judas_PhD [0] (~kevin@misterfluffy.dsl.xmission.com) |
| 13:02:44 | | Join herefornow [0] (~joe@99.32.61.4) |
| 13:05:19 | | Part herefornow |
| 13:15:03 | | Join LambdaCalculus37 [0] (~rmenes@rockbox/staff/LambdaCalculus37) |
| 13:15:58 | | Quit LambdaCalculus37 (Client Quit) |
| 13:16:59 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 13:20:28 | jhMikeS | [Saint]: did your phone melt yet or do anything normally unphonelike? |
| 13:29:32 | * | jhMikeS has been getting odd FS errors where he later finds audio files that have minor corruption, usually on e200 but once on gigabeat S |
| 13:31:31 | | Quit stoffel (Ping timeout: 276 seconds) |
| 13:33:36 | [Saint] | well...it hasn't melted yet ;) |
| 13:33:53 | [Saint] | Doesn't *appear* to be doing anything unphonelike... |
| 13:34:01 | jhMikeS | sounds like a good start :) |
| 13:34:35 | | Quit mt (Ping timeout: 252 seconds) |
| 13:36:18 | kugel | jhMikeS: Can you document the new/changed playback stack somewhere? |
| 13:36:45 | [Saint] | jhMikeS: perhaps it's worthwhile for you to look at/try FS #11883 ? |
| 13:37:20 | jhMikeS | kugel: in what aspect? |
| 13:37:47 | kugel | all aspects :) |
| 13:39:00 | jhMikeS | lol...it's really not _that_ different, just mostly filling in holes, and it's not even committed yet |
| 13:39:58 | | Quit bieber (Ping timeout: 276 seconds) |
| 13:40:54 | jhMikeS | [Saint]: It seems related to using the on-player file managment stuff (move, delete, rename) but I discover it so late I can't be sure, but with the beast, I never used that stuff there and shortly after I did discover there were crosslinked files when before I never had an issue on a disk check |
| 13:41:31 | kugel | well, it always lacked documentation, and a rewrite is a good opportunity to fix that |
| 13:42:02 | kugel | and people try to avoid this area for a reason :) |
| 13:42:04 | jhMikeS | kugel: probably not worth my time if pixelma won't let it in SVN :p |
| 13:42:53 | kugel | why should she? |
| 13:45:48 | | Join sideral [0] (~sideral@rockbox/developer/sideral) |
| 13:46:31 | | Join stoffel [0] (~quassel@p57B4BFD9.dip.t-dialin.net) |
| 13:49:56 | | Join Keripo1 [0] (~Keripo@fkb054.wireless-pennnet.upenn.edu) |
| 13:50:13 | jhMikeS | well, I just blew a couple month of work if it doesn't go...I guess we're happy with the same old bugs then :) You mean you don't want fresh ones? |
| 13:50:16 | | Nick kugel is now known as kugelp (~kugel@rockbox/developer/kugel) |
| 13:52:16 | AlexP | jhMikeS: I think he means why should she not let it in |
| 13:53:10 | jhMikeS | she was objecting earlier quite voceriferously, more so than usual |
| 13:53:26 | | Quit Keripo (Ping timeout: 276 seconds) |
| 13:58:01 | gevaerts | Well, against the development style more than against the patch I'd say |
| 14:00 |
| 14:00:56 | sideral | jhMikeS: I think it's just a question of how to build confidence in the redesigned playback engine. Big changes are much harder to review and build confidence in. Hence I think kugel's idea to document this thoroughly could help demonstrating it's better and building confidence. |
| 14:01:09 | sideral | jhMikeS: My take: keep it up |
| 14:01:37 | sideral | And thanks for caring about the mess that is playback today at all! |
| 14:02:34 | sideral | I even think a few new bugs are tolerable if the thing turns out easier to maintain than the present one |
| 14:02:45 | jhMikeS | thanks...it's fun because it's somewhat difficult |
| 14:03:51 | gevaerts | sideral: if new bugs *aren't* tolerable, we need to shut down svn right now! |
| 14:03:52 | sideral | (catching up with the log) jhMikeS: Re the autoresume problem you mentioned earlier: Do you mean a problem with the autoresume system I contributed? |
| 14:04:38 | jhMikeS | sideral: it would only do resumes at first buffering, not a skipping back to an already buffered track at least not if you skipped more than two |
| 14:06:02 | sideral | jhMikeS: Never had that problem... Can can I reproduce it? |
| 14:06:08 | jhMikeS | now it does it at each codec start according to the settings, which is what I'd expect |
| 14:06:26 | sideral | s/Can can/How can/ |
| 14:06:32 | jhMikeS | easy, just skip a couple tracks away and resume point will get stale |
| 14:07:14 | jhMikeS | if the track remained on the buffer, the original load resume point was used, not what you exited last time (I think that's how it went) |
| 14:08:36 | jhMikeS | it couldn't do it right all the time since the resume point was _only_ obtained once per load from disk and never thereafter |
| 14:08:58 | sideral | should this be easier to reproduce with short tracks? |
| 14:09:11 | jhMikeS | but codec starting wasn't a well-defined operation as it is with the patch |
| 14:09:27 | jhMikeS | length won't matter |
| 14:10:25 | jhMikeS | of course use tracks long enough so that tagree accepts the resume point |
| 14:11:37 | sideral | so there's no buffer event generated? but the id3 info including the resume point should still be buffered as well? |
| 14:11:44 | sideral | (trying to reproduce it) |
| 14:12:20 | jhMikeS | that's the original resume point at load though |
| 14:12:42 | sideral | no luck reproducing it. Anyway, I'm glad your patch fixes it :) |
| 14:13:34 | jhMikeS | make sure to skip ahead enough but yes, use tracks that fit fully inside the buffer. if it's a clip, it probably won't be easily reproducible |
| 14:14:14 | jhMikeS | on a player that can buffer a dozen tracks, it's a different story since they tend to stay there |
| 14:14:58 | sideral | the original resume point is constantly updated by the codec AFAIU, and then written out by tagtree_track_finish_event, and then either it stays with the updated offset in memory or its reloaded at the next tagtree_buffer_event |
| 14:15:19 | sideral | that's my understanding. I don't see where the hole in that would be? |
| 14:15:41 | sideral | I have a Clip+ at hand right now, and can't seem to reproduce it with this player |
| 14:15:41 | | Quit factor (Read error: Connection reset by peer) |
| 14:19:21 | sideral | jhMikeS: If you have a set of files and a player I can reproduce it with (Clip+ or ClipV2 or any simulator), could you please open a separate FS tracker item with this info? |
| 14:19:28 | jhMikeS | it's not updated into the buffered mp3entry, just the current one |
| 14:20:35 | sideral | aha, OK, that's probably a bug then. Still no luck reproducing it right now |
| 14:20:35 | jhMikeS | what the WPS and codec use are separate data from what's in the file buffer |
| 14:21:17 | | Quit bluefoxx (Quit: Can we, should we, will we?) |
| 14:22:15 | sideral | jhMikeS: BTW, have you seen that I reopened FS #11877? |
| 14:22:26 | jhMikeS | I doubt I could reproduce easily on a small memory device since it rebuffers so often and rarely has more than a single track on the buffer, but a something with 64MB, it wasn't a problem |
| 14:23:12 | jhMikeS | sideral: it disppeared then reappeared at some point? |
| 14:24:33 | sideral | jhMikeS: (autoresume) The ClipV2/Clip+ have plenty of memory, don't they? I think the problem is alleviated by the buffer thread trying to buffer ahead, so old stuff tends to flush out pretty quickly if there's enough data left to play |
| 14:25:50 | sideral | jhMikeS: (USB corruption) The problem remains fixed on my ClipV2 (only one observation since your fixes went in), but now I can reproduce it on my new Clip+ |
| 14:25:53 | jhMikeS | I don't know what they have for ram. old stuff gets flushed when the watermark is hit |
| 14:26:11 | jhMikeS | ...or the needed data isn't avaible, like a rebuffer or skip |
| 14:27:28 | jhMikeS | I was lurking all this time peeking at my IRC client from time to time. I recall you mentioning ruled out 29492? |
| 14:28:06 | sideral | Right. Backing that out didn't fix the problem. |
| 14:28:49 | sideral | (If I've done it correctly, it wasn't a clean revert. But I think I did it right.) |
| 14:32:56 | jhMikeS | I'd expect an issue with that to affect all, since that code is only different based on core count. |
| 14:33:05 | | Join factor [0] (~factor@75.108.68.114) |
| 14:35:12 | sideral | Yeah. So I think r29129 & r29130 somehow were not complete |
| 14:35:57 | sideral | Or it's something entirely different that's sufficiently worked around by these revisions for my ClipV2 to work |
| 14:36:47 | jhMikeS | there are some strange hardware dependencies on those...if I plug usb on my fuzev2, I can watch the tuner registers go nuts :) |
| 14:38:24 | sideral | scary |
| 14:39:03 | jhMikeS | if usb is plugged at boot, it hangs in the tuner code in fmradio_init |
| 14:42:31 | jhMikeS | maybe try plugging different players while watching the fm radio debug |
| 14:45:15 | * | jhMikeS wonders now if even though Rockbox isn't Linux, if it will slowly become Linux |
| 14:46:40 | * | jhMikeS wonders if everything just eventually becomes Linux |
| 14:46:51 | * | gevaerts starts working on x.rock :) |
| 14:47:19 | jhMikeS | up, up and away! :) |
| 14:47:33 | bluebroth3r | not xorg.rock? |
| 14:47:42 | * | [Saint] starts working on a Gnome3 theme ;) |
| 14:47:56 | gevaerts | bluebroth3r: not decided yet :) |
| 14:48:00 | * | bluebroth3r waits for someone to start working on KDE4.rock :P |
| 14:48:12 | jhMikeS | if you wait long enough, everything looks like a penguin |
| 14:48:31 | bluebroth3r | penguin.rock? |
| 14:49:11 | gevaerts | jhMikeS: your experience with the playback engine makes me want to talk to you in #rockbox-gsoc :) |
| 14:49:19 | jhMikeS | rrrr |
| 14:49:47 | [Saint] | haha! you proved you're smart. |
| 14:49:53 | [Saint] | you're done for now... :P |
| 14:50:15 | jhMikeS | lol...on one side, now I'm getting flipped over |
| 14:50:44 | * | bluebroth3r is annoyed by this "fonts are bitmaps" "bug" guy |
| 14:51:19 | *** | Saving seen data "./dancer.seen" |
| 14:51:19 | * | kugelp wonders about the implications of jhMikeS' patch for several gsoc proposals |
| 14:51:54 | | Quit Keripo1 (Quit: Leaving.) |
| 14:52:10 | * | jhMikeS say "vector fonts" |
| 14:53:03 | sideral | gevaerts: What's so secret about GSOC that it requires a separate secret channel? |
| 14:53:16 | TheSeven | [10:08] <n1s> TheSeven: does a classic charge in the emcore menu? << yep |
| 14:53:20 | gevaerts | sideral: the channel isn't secret! |
| 14:55:53 | sideral | gevaerts: What's so special about GSOC that it requires a separate special channel? |
| 15:00 |
| 15:01:55 | | Quit stoffel (Remote host closed the connection) |
| 15:05:36 | sideral | gevaerts: or in other words, why can't that conversation (with jhMikeS or the candidates) happen here? |
| 15:05:58 | | Join rdd [0] (~rdd@c83-250-52-16.bredband.comhem.se) |
| 15:06:24 | CIA-87 | New commit by sideral (r29717): Fix regression in r29715: files listed multiple times in uisimulator ... |
| 15:10:00 | CIA-87 | r29717 build result: 50 errors, 0 warnings (sideral committed) |
| 15:11:55 | sideral | ??? Interesting: "configure didn't find sdl-config, which indicates that you don't have SDL (properly) installed. Please correct and re-run configure!" |
| 15:12:16 | sideral | What should I make of this? |
| 15:14:33 | | Join bluefoxx [0] (fuzzylomba@S0106485b3917092d.vs.shawcable.net) |
| 15:15:31 | gevaerts | sideral: suppose you were interviewing at a company, would you expect both your interview and the following discussion about it to be public? |
| 15:16:50 | sideral | gevaerts: Didn't realize it was used for interviews. Did you imply you'd like to interview jhMikeS as a GSOC candidate? |
| 15:17:11 | gevaerts | no, but that I wanted to talk to him about a specific candidate |
| 15:17:54 | sideral | OK, sorry for the bother then |
| 15:18:07 | sideral | any advice re the build problem?? |
| 15:18:20 | CIA-87 | New commit by gevaerts (r29718): Add mobanda-Rondom to blacklist |
| 15:18:22 | gevaerts | Yes, that :) |
| 15:18:32 | sideral | aha :) |
| 15:19:05 | | Join kroon [0] (c351437b@gateway/web/freenode/ip.195.81.67.123) |
| 15:19:22 | gevaerts | sideral: by the way, you're welcome to join that channel too, it's accessible for all rockbox committers (but we ask those who apply as a student to keep out) |
| 15:19:49 | | Quit kroon (Client Quit) |
| 15:21:24 | sideral | gevaerts: I'd like to, but unfortunately the amount of spare time I have doesn't allow any investment into helping steer or police Rockbox right now :( |
| 15:21:29 | sideral | I'd rather like to get some contentious new features done ;) |
| 15:22:13 | gevaerts | :) |
| 15:22:34 | * | pamaury tries to motivate himself to have a look at the clip+ usb problem...again |
| 15:23:34 | | Quit b42 (Read error: Operation timed out) |
| 15:23:45 | sideral | pamaury: Here's some motivation for you: We'll be able to enable Rockbox USB for AMSv2 when you're done; at least I am not aware of any other major issue with it. And you'll be my hero :) |
| 15:24:54 | pamaury | hehe, let's go then |
| 15:25:23 | jhMikeS | gogogo |
| 15:25:30 | TheLemonMan | pamaury: i have something that will make you happy :D |
| 15:25:47 | Rondom | hm |
| 15:25:49 | Rondom | ok |
| 15:26:06 | Rondom | what's wrong? |
| 15:26:13 | | Join evilnick [0] (18bcf602@rockbox/staff/evilnick) |
| 15:26:24 | pamaury | TheLemonMan: video is working? |
| 15:26:26 | gevaerts | sideral: I don't want to imply that you *should* be there. I mainly wanted to make sure you didn't get the impression that the "gsoc people" want to keep this a closed group |
| 15:26:34 | TheLemonMan | http://foss.doredevelopment.dk/mirrors/imx/ |
| 15:26:49 | Rondom | gevaerts: hi, what's wrong with my client? |
| 15:26:51 | TheLemonMan | elftosb code and some example code for imx23 boards |
| 15:27:06 | gevaerts | Rondom: http://build.rockbox.org/shownewlog.cgi?rev=29717;type=ipodcolorsim |
| 15:27:19 | pamaury | wow, is this open source ? |
| 15:27:37 | Rondom | ah I see |
| 15:27:40 | Rondom | will fix asap |
| 15:28:01 | gevaerts | OK. Let me know when it's fixed, and I'll drop you from the blacklist :) |
| 15:28:19 | TheLemonMan | dunno |
| 15:28:20 | [Saint] | ??? Interesting: "configure didn't find sdl-config, which indicates that you don't have SDL (properly) installed. Please correct and re-run configure!" |
| 15:28:20 | [Saint] | <sideral> What should I make of this? |
| 15:28:31 | [Saint] | sideral: I'm getting that too. |
| 15:28:49 | [Saint] | I *definitely* have SDL installed...what else would I possibly need to do? |
| 15:29:13 | [Saint] | (I discovered this while attempting an SDL application build) |
| 15:29:37 | pamaury | TheLemonMan: that's nice :) Just a shame we discover it after after finding out muc of the format :) |
| 15:30:25 | Rondom | gevaerts: its fixed, now. i accidentally removed sdl... :-/ |
| 15:30:33 | pamaury | the code is incredibly complicated for nothing it seems, I haven't any of thos esb file using such complicated construct |
| 15:31:09 | CIA-87 | New commit by gevaerts (r29719): Re-allow mobanda-Rondom (problem should now be fixed) |
| 15:31:45 | TheLemonMan | its because they used overcomplicated lexical parsers |
| 15:32:19 | pamaury | they also use a bunch of C++ classes |
| 15:32:23 | pamaury | ridiculous... |
| 15:32:30 | | Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) |
| 15:32:45 | TheLemonMan | the power of sepples heh |
| 15:33:26 | pamaury | any thanks for this, I don't know how you find it but that's awesome |
| 15:33:31 | pamaury | *anyway |
| 15:34:14 | TheLemonMan | it's of no use to me tho |
| 15:34:49 | pamaury | not much to me either :) |
| 15:35:02 | pamaury | I still plan to rewrite elftosb |
| 15:35:29 | | Quit advcomp2019_ (Ping timeout: 276 seconds) |
| 15:41:40 | pamaury | wow, I had nearly everything right when reverse engineering the format |
| 15:44:12 | TheLemonMan | when rewriting sbinfo make sure the output fits in a 80x24 terminal ;) |
| 15:44:44 | pamaury | doesn't it ? |
| 15:45:08 | pamaury | I will only tweak a few things in sbinfo, the elftosb program won't output much things |
| 15:45:28 | pamaury | it's a shame we still don't have the code for the hid loader |
| 15:46:15 | | Join tmzt [0] (~tmzt@76.211.0.191) |
| 15:46:56 | TheLemonMan | some output lines get cut |
| 15:47:45 | pamaury | hum, I'll have a look in a minute |
| 15:48:00 | pamaury | I always use a huge terminal so I don't pay attention |
| 15:48:30 | TheLemonMan | what if we send the mfgtool included sb ? |
| 15:49:39 | pamaury | not sure, apparently then you can send some commands in another (documented) format, but it's quite possible it makes assumption on the hardware available |
| 15:52:22 | TheLemonMan | mmh, my tool isnt working anymore |
| 15:52:54 | | Join Buschel [0] (~chatzilla@p54B67972.dip.t-dialin.net) |
| 15:54:12 | pamaury | indeed, sbinfo output doesn't fit 80 columns display |
| 15:57:05 | | Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com) |
| 16:00 |
| 16:02:26 | | Quit liar (Read error: Connection reset by peer) |
| 16:02:58 | JdGordon | *ooof* |
| 16:03:06 | * | JdGordon lands with a thud |
| 16:03:29 | jhMikeS | pcm latency |
| 16:03:39 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 16:03:56 | TheLemonMan | i got the player to boot from the usb! yay |
| 16:04:21 | * | Buschel makes good progress with memory reduction for m4a playback :) |
| 16:04:24 | JdGordon | jhMikeS: surely plaback doesnt care what the playlist actually is? doesnt it just continually ask playlist for filenames? |
| 16:04:41 | Buschel | seems like we could reach better playability for long m4a tracks :) |
| 16:05:28 | jhMikeS | JdGordon: it does, but it must decode ahead of what is heard. the patch fixes the advance of the playlist before the track is over, except where directories are concerned, because right now it can't fix that |
| 16:06:05 | CIA-87 | New commit by pamaury (r29720): sbinfo: fix section flags, don't output more than 80 characters per line, fix colours |
| 16:06:26 | pamaury | TheLemonMan: done :) |
| 16:06:48 | TheLemonMan | thanks :D |
| 16:07:27 | JdGordon | jhMikeS: right, so im saying that shouldnt be worked around by playback.. playlist should be fixed to auto rebuild the playlist when playback seeks past the end - if its a dirplay ofcourse- |
| 16:07:55 | jhMikeS | playlists don't know the next song for a new directory until the playlist is actually advanced, at which point it's created, then playback know the next song to do |
| 16:09:29 | jhMikeS | not sure what you're saying. it does rebuild when calling playlist_next |
| 16:10:21 | CIA-87 | r29720 build result: All green |
| 16:10:26 | jhMikeS | but normally, playlist_peek is used, but that can't see past the end of the current directory into at least one song |
| 16:11:15 | TheLemonMan | fixed this off by one error :D |
| 16:12:19 | jhMikeS | playback can always see the entire playlist that is _current_ to get whatever filenames |
| 16:12:40 | JdGordon | jhMikeS: right, iirc there isnt really any reason playlist_peek() cant be fixed to make it load the next directory if we are in dirplay mde |
| 16:13:13 | jhMikeS | it must not destroy the old one though |
| 16:13:22 | JdGordon | it shouldnt need to |
| 16:13:36 | | Join mint [0] (~mint@116.72.193.20) |
| 16:13:54 | JdGordon | it could do a similar thing to the "play next" item, so it queues all the existing tracks and adds the next dir |
| 16:14:11 | JdGordon | or we just keep a list of directories to play outside/next to of the filename buffer |
| 16:14:19 | | Part mint |
| 16:14:33 | JdGordon | working around playlist brokeness in playback seems bad |
| 16:14:49 | JdGordon | of course this is without looking at your patch or understanding the existing code at all :p |
| 16:14:53 | jhMikeS | it's not very extreme in the workaround but it has to just to work for now |
| 16:14:59 | | Join smk [0] (~smk@116.72.193.20) |
| 16:16:46 | jhMikeS | if it could see into future directories, all gapless skips could be treated like normal delayed advances the same way |
| 16:17:22 | jhMikeS | or...we just let pcm run out then go to the next directory and don't worry about the delays between different playlists |
| 16:18:06 | jhMikeS | the 3s pcm buffer seems geared just to absorb spinup time between them |
| 16:20:31 | | Quit smk (Quit: Leaving) |
| 16:21:10 | JdGordon | I dont think inter-playlist gaps is a big deal |
| 16:22:15 | | Quit jae (Ping timeout: 260 seconds) |
| 16:25:24 | jhMikeS | it's only with auto directory changes, dirs don't matter when playing from the database |
| 16:25:33 | | Quit [Saint] (Quit: I'm only going to heaven, if it feels like Hell. I'm only going to heaven, if it tastes like caramel...) |
| 16:25:54 | | Join [Saint] [0] (~St.]@124-197-14-130.callplus.net.nz) |
| 16:26:04 | * | jhMikeS never tried playing a list of playlists, if that's even doable |
| 16:29:51 | JdGordon | well, it doesnt matter for the db because the db sucks ass also |
| 16:30:07 | JdGordon | the db inserts each track into the playlist instead of doing a dirplay-type-thing |
| 16:31:14 | JdGordon | having the playlist on repeat-shuffle probably would have the same effect right? |
| 16:32:44 | jhMikeS | it would treat it like a dirchange since it has to generate it anew at each completion |
| 16:36:19 | jhMikeS | looks like playing more playlists without stopping just adds those tracks to the current one |
| 16:38:47 | | Join jae [0] (~jae@dedicated.jaerhard.com) |
| 16:41:29 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 16:41:54 | | Quit Buschel (Ping timeout: 240 seconds) |
| 16:44:51 | | Quit Judas_PhD (Quit: This is a quitting message) |
| 16:45:14 | | Join tchan1 [0] (~tchan@c-69-243-144-187.hsd1.il.comcast.net) |
| 16:45:48 | | Quit timccc (Read error: No route to host) |
| 16:45:56 | | Join timccc [0] (~timccc@112.166.15.141) |
| 16:47:37 | | Quit tchan (Ping timeout: 276 seconds) |
| 16:50:51 | | Join JesusFreak316 [0] (~JesusFrea@pool-173-65-59-203.tampfl.fios.verizon.net) |
| 16:51:20 | *** | Saving seen data "./dancer.seen" |
| 16:51:38 | | Join piotrekm [0] (~piotrek@unaffiliated/piotrekm) |
| 16:53:05 | | Join aramir [0] (~Miranda@92.61.135.251) |
| 16:54:48 | | Quit Barahir_ (Quit: leaving) |
| 16:55:24 | | Join Barahir [0] (~jonathan@fb08schindler24.anorg.chemie.uni-giessen.de) |
| 16:56:05 | | Quit bluefoxx (Ping timeout: 260 seconds) |
| 16:58:16 | | Quit factor (Remote host closed the connection) |
| 17:00 |
| 17:04:18 | | Quit sideral (Quit: Leaving.) |
| 17:22:31 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 17:24:32 | | Join factor [0] (~factor@75.108.68.114) |
| 17:25:37 | | Quit aramir (Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org) |
| 17:27:50 | | Quit petur (Ping timeout: 258 seconds) |
| 17:32:06 | | Join skfunnyboy [0] (~skfunnybo@modemcable024.96-202-24.mc.videotron.ca) |
| 17:33:51 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 17:36:21 | | Quit skfunnyboy (Ping timeout: 246 seconds) |
| 17:39:03 | | Quit liar (Read error: Connection reset by peer) |
| 17:39:29 | | Join u42p [0] (~v35b@d157074.adsl.hansenet.de) |
| 17:39:31 | | Join Leif [0] (~LeifAnder@c-98-202-6-36.hsd1.ut.comcast.net) |
| 17:39:37 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 17:40:35 | [Saint] | Hmmmm...ok, those warnings I pointed to earlier are present in "vanilla" SVN head |
| 17:41:06 | [Saint] | http://pastebin.com/gCTQLC1i for the interested |
| 17:41:12 | [Saint] | kugelp: ^ |
| 17:41:29 | kugelp | i know these |
| 17:41:43 | kugelp | some change by TheSeven introduced it, but it doesnt harm |
| 17:41:56 | [Saint] | Aha, well...as long as you're aware of them and they're harmless, all is well. |
| 17:42:40 | * | bertrik plans to document the IAP autobaud mechanism a bit more |
| 17:43:53 | | Quit [Saint] (Quit: I'm only going to heaven, if it feels like Hell. I'm only going to heaven, if it tastes like caramel...) |
| 17:44:12 | | Join [Saint] [0] (~St.]@124-197-14-130.callplus.net.nz) |
| 17:45:47 | | Quit [Saint] (Client Quit) |
| 17:46:01 | | Join [Saint] [0] (~St.]@124-197-14-130.callplus.net.nz) |
| 17:46:19 | | Quit [Saint] (Read error: Connection reset by peer) |
| 17:46:52 | | Join [Saint] [0] (~St.]@124-197-14-130.callplus.net.nz) |
| 17:48:11 | | Join smk [0] (~smk@116.72.193.20) |
| 17:48:37 | | Quit [Saint] (Client Quit) |
| 17:48:50 | | Join [Saint] [0] (~St.]@124-197-14-130.callplus.net.nz) |
| 17:48:54 | | Quit petur (Ping timeout: 258 seconds) |
| 17:50:23 | | Join petur [0] (~petur@rockbox/developer/petur) |
| 17:51:17 | smk | hi.a general design question. goto statements are generally avoided to help track code flow better (so it is taught in colleges :P ). i find rockbox code using goto very frequently on the other hand. hmm..any reasons? |
| 17:51:36 | gevaerts | Yes, religion and code don't mix :) |
| 17:51:42 | tguinot | huhu |
| 17:51:51 | gevaerts | "gotos are bad" is religion |
| 17:51:52 | smk | :D |
| 17:52:36 | smk | haha. the college prof wasn't very clear on why not to use goto. |
| 17:52:41 | tguinot | I would not say that they are bad but you need to know how to use it and when |
| 17:52:42 | * | jhMikeS gets annoyed at syntactic puritanicalism |
| 17:53:03 | gevaerts | Well, if you look closely, you should (I hope!) find that goto use falls into a few patterns. They shouldn't be used randomly |
| 17:53:31 | gevaerts | Never use a goto for looping :) |
| 17:53:33 | jhMikeS | if they were, you'd have a prefetch abort without much delay |
| 17:54:20 | jhMikeS | ooh...destroy mpegplayer then since it does in one spot |
| 17:54:22 | smk | gevaerts: at some parts goto has been used for looping in rockbox code. |
| 17:54:57 | gevaerts | smk: example? |
| 17:54:59 | jhMikeS | sometimes it's the cleanest way to handle an exceptional case of "redo this" |
| 17:54:59 | bluebroth3r | there aren't that much gotos in the application code. grepping for it reveals gotos in drivers and codecs mostly |
| 17:55:05 | smk | yeah. goto has been used for repeated pinging |
| 17:55:21 | | Quit leavittx_ (Remote host closed the connection) |
| 17:56:24 | smk | gevaerts: in buflib.c , it's been used for repeatedly trying for allocation |
| 17:56:36 | bertrik | we *do* have some horrible loops in some places indeed ... |
| 17:57:55 | gevaerts | smk: right. I don't think those are *bad*, but I admit that I wouldn't write it that way |
| 17:58:11 | jhMikeS | goto is fine if otherwise you'd be doing strange contortions to remain "pure" |
| 17:59:09 | jhMikeS | what about switch fall-through? is that evil? personally, I like it alot. |
| 17:59:28 | gevaerts | jhMikeS: objecting to switch fall-through is definitely evil :) |
| 18:00 |
| 18:00:00 | * | jhMikeS likes default: not being the last case too >:] |
| 18:00:20 | bertrik | switch fall-through is OK with me, but I'd like a comment with that to tell it's intentional |
| 18:00:32 | jhMikeS | and strings as arrays of course "string"[x] |
| 18:02:30 | * | bluebroth3r agrees with bertrik on the fall-through |
| 18:03:02 | jhMikeS | most often I comment it unless it's blatantly obvious it's intentional |
| 18:03:42 | bluebroth3r | /* fall-through: this is obvious! */ |
| 18:03:45 | bluebroth3r | :) |
| 18:03:48 | gevaerts | case a:\ncase b: <do something>; break; case c:\ncase d: <do something else>; break; doesn't need a comment IMO |
| 18:04:37 | | Quit petur (Ping timeout: 258 seconds) |
| 18:10:06 | bertrik | I agree on that |
| 18:18:27 | | Quit smk (Quit: Leaving) |
| 18:30:11 | | Quit JesusFreak316 (Ping timeout: 250 seconds) |
| 18:34:00 | | Join mt [0] (~mtee@41.239.50.34) |
| 18:34:00 | | Quit mt (Changing host) |
| 18:34:00 | | Join mt [0] (~mtee@rockbox/developer/mt) |
| 18:36:00 | | Join thomasjfox [0] (~thomasjfo@rockbox/developer/thomasjfox) |
| 18:39:48 | thomasjfox | Question about idle shutdown: When I configure idle shutdown to 15 minutes and listen to an album that last 90 minutes, is rockbox supposed to shut down immediately after finishing the last track? |
| 18:40:15 | gevaerts | no, after 15 minutes idle time |
| 18:40:22 | u42p | no, idle means no music playing |
| 18:40:33 | thomasjfox | hmm. Then it's a bug :) |
| 18:40:41 | AlexP | when music is playing you may be idle but the player isn't :) |
| 18:41:17 | thomasjfox | It also felt very strange that rockbox just shuts down after the last track... |
| 18:41:29 | AlexP | yeah, that shouldn't happen |
| 18:41:46 | thomasjfox | So the "last track finished" event should reset the idle timer somehow |
| 18:42:10 | thomasjfox | (-> it should already) |
| 18:47:18 | | Join smk [0] (~smk@116.72.193.20) |
| 18:50:26 | TheSeven | kugelp: that's actually a bug in some android include file |
| 18:50:47 | TheSeven | i just triggered it by causing things to be included in a different order in some place |
| 18:51:07 | TheSeven | bertrik: sounds like a good idea |
| 18:51:10 | kugelp | they tend to be buggy yes |
| 18:51:21 | *** | Saving seen data "./dancer.seen" |
| 18:51:28 | TheSeven | that's basically what's holding me back from implementing iap for the s5l870x |
| 18:51:28 | kugelp | we don't use -Wundef because of those |
| 18:53:51 | smk | AlexP : hi |
| 18:54:17 | AlexP | smk: Hi, standby please :) |
| 18:54:36 | smk | yeah. sure |
| 18:55:46 | bertrik | TheSeven, the basic idea is that the baudrate can be inferred from the data received when trying to read the 0xFF byte at a high bitrate. If we sample too high, the start bit will spill into the data bits, with a specific value for each lower bitrate. |
| 18:56:18 | TheSeven | heh, funny |
| 18:56:22 | | Quit liar (Ping timeout: 258 seconds) |
| 18:56:27 | TheSeven | requires the uart to ignore framing errors though? |
| 18:57:17 | bertrik | I think so |
| 18:57:41 | CIA-87 | New commit by thomasjfox (r29721): Fix premature idle shutdown on RaaA after last track finished playing |
| 18:58:07 | bertrik | also there seem to be two 'hierarchies' of bitrates, 1200/2400/4800/9600/19200/38400 and 14400/28800/57600/115200 |
| 19:00 |
| 19:00:52 | | Quit piotrekm (Quit: piotrekm) |
| 19:01:34 | CIA-87 | r29721 build result: All green |
| 19:01:42 | | Quit leavittx (Ping timeout: 276 seconds) |
| 19:03:27 | bertrik | TheSeven, and I think there's a little complication that a 1200 bps signal samples at 38400 will spill the start bit over too many bits at 38400 |
| 19:04:05 | TheSeven | what's the valid baud range for that thing anyway? |
| 19:04:12 | TheSeven | and how does initial handshaking work? |
| 19:04:25 | TheSeven | are the accessories repeatedly transmitting 0xff bytes all the time? |
| 19:04:40 | bertrik | TheSeven, not sure actually about the baud rates in use |
| 19:06:23 | preglow | anyone know why rockbox sometimes spins up the disk during navigation even though dircache is on? |
| 19:07:14 | | Quit niekie (Read error: Operation timed out) |
| 19:10:56 | | Quit bertrik (Ping timeout: 258 seconds) |
| 19:11:27 | | Join mt_ [0] (~mtee@41.239.50.34) |
| 19:14:26 | | Join saratoga2 [0] (600afc5f@rockbox/developer/saratoga) |
| 19:15:42 | | Join piotrekm [0] (~piotrek@unaffiliated/piotrekm) |
| 19:15:49 | | Quit mt (Ping timeout: 276 seconds) |
| 19:15:53 | | Nick mt_ is now known as mt (~mtee@41.239.50.34) |
| 19:16:14 | | Quit mt (Changing host) |
| 19:16:14 | | Join mt [0] (~mtee@rockbox/developer/mt) |
| 19:17:08 | | Join bertrik [0] (~bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 19:17:08 | | Quit bertrik (Changing host) |
| 19:17:08 | | Join bertrik [0] (~bertrik@rockbox/developer/bertrik) |
| 19:19:05 | | Join t0rc [0] (~t0rc@unaffiliated/t0rc/x-5233201) |
| 19:19:42 | | Join leavittx [0] (~leavittx@89.221.199.187) |
| 19:19:43 | | Part piotrekm |
| 19:20:22 | | Join ptrm [0] (~piotrek@unaffiliated/piotrekm) |
| 19:20:57 | | Nick ptrm is now known as piotrekm (~piotrek@unaffiliated/piotrekm) |
| 19:22:55 | | Join pastr_ [0] (4db95260@gateway/web/freenode/ip.77.185.82.96) |
| 19:24:11 | pastr_ | does rockbox offer the feature to adjust the playback speeds of podcast on sansa clips? |
| 19:24:30 | | Quit leavittx (Ping timeout: 246 seconds) |
| 19:24:59 | saratoga2 | yes |
| 19:25:32 | pastr_ | sweet thanks |
| 19:26:08 | pastr_ | i am looking in the doc right now , but can't find it |
| 19:27:32 | saratoga2 | manual page 31 |
| 19:27:47 | AlexP | pastr_: http://download.rockbox.org/daily/manual/rockbox-sansaclip/rockbox-buildch6.html#x9-1130006.10 |
| 19:27:52 | | Quit piotrekm (Quit: piotrekm) |
| 19:28:23 | pastr_ | AlexP: thanks |
| 19:28:54 | bertrik | TheSeven, it should not be too hard to make the iap autobaud generic. It's now poking directly into the uart, but we could replace that by a call to serial_bitrate (and rework the hack for bitrate=0) |
| 19:33:12 | | Join leavittx [0] (~leavittx@89.221.199.187) |
| 19:34:04 | | Join mshathlonxp [0] (~msh@5acba0d5.bb.sky.com) |
| 19:42:16 | | Quit leavittx (Ping timeout: 246 seconds) |
| 19:47:32 | | Join bieber [0] (~quassel@162-78.97-97.tampabay.res.rr.com) |
| 19:49:59 | | Join Buschel [0] (~chatzilla@p54A3AA53.dip.t-dialin.net) |
| 19:50:42 | | Join piotrekm [0] (~piotrek@addr16.neoplus.adsl.tpnet.pl) |
| 19:50:42 | | Quit piotrekm (Changing host) |
| 19:50:42 | | Join piotrekm [0] (~piotrek@unaffiliated/piotrekm) |
| 19:51:13 | | Join Buschel_ [0] (~chatzilla@p54A3AA53.dip.t-dialin.net) |
| 19:53:12 | | Quit smk (Quit: Leaving) |
| 19:53:42 | | Quit pastr_ (Quit: Page closed) |
| 19:54:08 | | Join {phoenix} [0] (~dirk@p5DF2DFFE.dip.t-dialin.net) |
| 19:54:38 | | Quit Buschel (Ping timeout: 240 seconds) |
| 19:54:40 | | Nick Buschel_ is now known as Buschel (~chatzilla@p54A3AA53.dip.t-dialin.net) |
| 19:54:42 | | Join smk [0] (~smk@116.72.193.20) |
| 19:54:56 | | Join sideral [0] (~sideral@rockbox/developer/sideral) |
| 19:55:32 | | Join niekie [0] (~niek@CAcert/Assurer/niekie) |
| 19:55:42 | thomasjfox | Is there a configuration setting for the height of the menu cursor? I recently had the chance to use the android port and it's very touch friendly thanks to the huge cursor |
| 19:56:11 | bluebroth3r | menu cursor? |
| 19:56:29 | thomasjfox | menu bar? |
| 19:56:43 | thomasjfox | the one that highlights the current selected item in a menu |
| 19:57:00 | kugelp | thomasjfox: I have a preliminary patch on my git repo for that |
| 19:57:01 | AlexP | It just goes with font size |
| 19:57:06 | kugelp | it's not android specific |
| 19:57:11 | AlexP | kugelp has a spacing patch |
| 19:57:15 | AlexP | er, yeah :) |
| 19:57:25 | thomasjfox | That was really nice to use! |
| 19:57:30 | AlexP | Which I use on Android and is great |
| 19:57:44 | * | thomasjfox will steal it for maemo, too |
| 19:58:04 | kugelp | AlexP: yea it is, unless you try a non-gradient line selector :P |
| 19:58:13 | AlexP | Not tried that :) |
| 19:59:20 | | Join JesusFreak316 [0] (~JesusFrea@pool-173-65-59-203.tampfl.fios.verizon.net) |
| 20:00 |
| 20:01:49 | | Join stoffel [0] (~quassel@p57B4BFD9.dip.t-dialin.net) |
| 20:04:11 | martii | hey |
| 20:04:16 | martii | any devs here? |
| 20:04:55 | | Quit dfkt (Quit: -= SysReset 2.55=- Sic gorgiamus allos subjectatos nunc.) |
| 20:04:58 | AlexP | Yes, plenty - ask away |
| 20:05:48 | thomasjfox | argh, updated my tree to SVN head and now something seems wrong with backdrop handling |
| 20:06:02 | martii | AlexP: I'm getting Data abort error on startup of my iPod 4th gen |
| 20:06:14 | thomasjfox | The menu backdrop just appears if I "reselect" the cabbiev2 theme |
| 20:06:15 | martii | looks like I have no idea what to do |
| 20:06:17 | AlexP | martii: What version? |
| 20:06:25 | martii | AlexP: I can't check at the moment |
| 20:06:42 | AlexP | Do you remember what version you installed? |
| 20:06:43 | martii | AlexP: :( as I get only error while refreshing library |
| 20:06:48 | AlexP | Or roughly when? |
| 20:06:59 | AlexP | You can connect it to USB and look at rockbox-info.txt |
| 20:07:17 | martii | AlexP: it's dying before USB kicks in |
| 20:07:28 | AlexP | Use the OF |
| 20:07:32 | martii | AlexP: OF? |
| 20:07:32 | AlexP | or emergency disk mode |
| 20:07:36 | gevaerts | thomasjfox: if r29700 causes it, I'm *not* to blame! |
| 20:07:36 | AlexP | Original firmware |
| 20:07:52 | AlexP | i.e. boot the ipod software |
| 20:07:52 | martii | AlexP: OK - what is the emergency disc mode? |
| 20:08:05 | martii | AlexP: sure I would have to install itunes first :( |
| 20:08:11 | AlexP | No you don't |
| 20:08:13 | martii | AlexP: I'm on linux |
| 20:08:17 | AlexP | It is mass storage |
| 20:08:27 | AlexP | It appears just as a USB drive |
| 20:08:34 | AlexP | Turn on hold and boot |
| 20:08:42 | martii | AlexP: any key pressed during startup? |
| 20:08:44 | martii | ok |
| 20:08:47 | AlexP | It will start the apple firmware |
| 20:08:50 | thomasjfox | gevaerts: I'll try a "git revert" |
| 20:08:54 | AlexP | I think it is hold anyway, check the manual |
| 20:08:55 | martii | AlexP: OK will try |
| 20:09:15 | | Quit piotrekm (Quit: piotrekm) |
| 20:09:24 | martii | AlexP: I'll tell you when I put the rockbox in as I have also teste iTrip and confirmed it worked |
| 20:09:34 | martii | AlexP: I should have an e-mail somewhere |
| 20:09:37 | AlexP | martii: great |
| 20:09:39 | thomasjfox | gevaerts: The backdrop disappear after upgrading and also disappears when I remove/reset the .config/rockbox.org directory |
| 20:09:50 | AlexP | martii: Was it a release you installed or a current build? |
| 20:10:27 | | Join piotrekm [0] (~piotrek@unaffiliated/piotrekm) |
| 20:10:28 | thomasjfox | gevaerts: Let's see what strace has to say about it |
| 20:11:10 | * | jhMikeS had the backdrop disappear but just reloaded the theme |
| 20:11:12 | martii | AlexP: I'm not sure wait - battery is drained, I can't check it right now) |
| 20:11:31 | AlexP | martii: Anyway, if it is 3.8 (or something around there), it had problems |
| 20:11:46 | | Join dfkt [0] (dfkt@unaffiliated/dfkt) |
| 20:11:51 | AlexP | Check the disk (fsck.vfat on linux, chkdsk on Windows) then install 3.8.1 |
| 20:12:10 | gevaerts | Well, or a current build from around that time |
| 20:12:34 | thomasjfox | jhMikeS: Did that happen on RaaA or on a "real" target? |
| 20:12:40 | | Quit fyrestorm (Read error: Connection reset by peer) |
| 20:12:57 | AlexP | gevaerts: That's what I said :) |
| 20:12:58 | jhMikeS | real target, right after the "put backdrop anywhere" commit |
| 20:13:06 | martii | AlexP: I'll let you know as soon as it boots up :) |
| 20:13:09 | thomasjfox | Reverting the commit "fixes" the issue. I'll strace it |
| 20:13:15 | gevaerts | AlexP: yes, but I forgot to read :) |
| 20:13:35 | martii | AlexP: it was workign just fine - but one day I decided to put like 8G of podcasts on it (mp3( |
| 20:13:37 | jhMikeS | I haven't had further issues though once reloading the theme |
| 20:13:37 | | Quit Leif (Quit: Leaving) |
| 20:13:44 | martii | AlexP: and that's where the problem started |
| 20:14:11 | | Quit stoffel (Read error: Operation timed out) |
| 20:14:27 | martii | AlexP: so I installed it at the beggining os 11/2010 |
| 20:14:32 | martii | AlexP: so I installed it at the beggining of 11/2010 |
| 20:15:04 | thomasjfox | jhMikeS: It also breaks fresh installs |
| 20:15:29 | | Join leavittx [0] (~leavittx@89.221.199.187) |
| 20:15:50 | jhMikeS | thomasjfox: I must admit I didn't check that :) |
| 20:16:31 | thomasjfox | jhMikeS: Just noticed it as one of my tests is to clear the config directory and rebuild the database from scratch when I do a new maemo build |
| 20:16:49 | martii | AlexP: is there any way I can restore factory defaults or just delete library db? |
| 20:17:05 | AlexP | martii: delete *.tcd in the .rockbox folder |
| 20:17:23 | gevaerts | martii: check the filesystem too while you're at it |
| 20:17:33 | AlexP | I'd then check the filesystem, and install 3.8.1 |
| 20:17:37 | AlexP | Then we will see |
| 20:18:43 | martii | gevaerts: battery is weak so far - it shows apple logo and dies after few minutes does the same :) |
| 20:18:53 | martii | gevaerts: I'll do the check |
| 20:18:56 | gevaerts | Well yes, maybe wait a bit first :) |
| 20:19:48 | martii | I also think i have f*** up the battery - I have left iPod for a ew days in my car when it was pretty cold in winter (-15) |
| 20:20:14 | martii | seems battery never fully charges since |
| 20:20:34 | martii | and after all night charging lasts for 10-15 min |
| 20:20:47 | martii | so seems I need to replace battery (again) |
| 20:20:56 | thomasjfox | I'm off to dinner, the strace results are here: http://pastebin.com/ur0aRBni |
| 20:21:12 | | Quit leavittx (Ping timeout: 252 seconds) |
| 20:21:14 | martii | ok I got the error |
| 20:21:20 | thomasjfox | Looks like it stopped searching other folders if not found in the first one or something |
| 20:21:31 | martii | Data abort at 0004CC48 (0) |
| 20:21:45 | | Part u42p ("Leaving") |
| 20:21:47 | martii | and it's frozen now |
| 20:21:58 | martii | how can I force reboot? |
| 20:22:43 | AlexP | hold menu+select |
| 20:22:47 | CIA-87 | New commit by pamaury (r29722): sbinfo: move sb specific bits of its own header |
| 20:22:49 | CIA-87 | New commit by pamaury (r29723): sbinfo: move more things to sb.h, rewrite code to use structures instead of hardcoded offsets |
| 20:22:57 | AlexP | Is the data abort after having checked the disk and with 3.8.1? |
| 20:23:09 | martii | AlexP: doesn;t help |
| 20:23:16 | martii | AlexP: seems like CPU froze |
| 20:23:33 | AlexP | menu+select is hardware, it always works |
| 20:23:41 | gevaerts | Maybe toggle hold on and off first |
| 20:23:43 | AlexP | turn hold on then off, then hold menu+select |
| 20:23:48 | AlexP | for a long time maybe |
| 20:23:51 | AlexP | up to a minute |
| 20:25:02 | gevaerts | Putting the ipod down on a flat surface helps |
| 20:26:16 | martii | looks like nono of this works :( |
| 20:26:46 | AlexP | Unless there is a hardware problem, it will eventually |
| 20:26:51 | CIA-87 | r29722 build result: All green |
| 20:27:18 | martii | hmmm hold off and menu + select for 20 sec seems to do the trick (or battery just died again) |
| 20:29:06 | martii | AlexP: when I have hold on during the startup it doesn't turn into usb drive |
| 20:29:23 | AlexP | Does it go into the apple firmware? |
| 20:29:52 | martii | AlexP: I can see apple icon and thats all |
| 20:29:53 | CIA-87 | r29723 build result: All green |
| 20:30:00 | AlexP | martii: Wait for it to boot |
| 20:30:16 | martii | AlexP: nothing shows up in my logs as an device |
| 20:30:26 | AlexP | Wait until it has booted |
| 20:30:30 | martii | AlexP: OK |
| 20:31:47 | AlexP | If it doesn't, then that suggests another problem |
| 20:31:56 | martii | AlexP: all I see is an big apple icon and that's all |
| 20:32:07 | AlexP | Sounds like other problems then |
| 20:32:44 | martii | ok |
| 20:32:51 | AlexP | Try emergency disk mode - menu+select to reboot, then as soon as it does menu+play. Although if this isn't working and the Apple firmware won't boot then it sounds like hardware issues |
| 20:32:54 | martii | I had to remove cable |
| 20:32:59 | martii | and just put it back |
| 20:33:28 | martii | AlexP: so I'll do fsck first :) |
| 20:33:36 | AlexP | OK, great :) |
| 20:34:58 | martii | so it's RB v 3.7 |
| 20:35:04 | AlexP | Right |
| 20:35:16 | AlexP | So, still - check the disk, then install 3.8.1 |
| 20:35:22 | | Join GodEater [0] (~bibble@5ad8c3a6.bb.sky.com) |
| 20:35:22 | | Quit GodEater (Changing host) |
| 20:35:22 | | Join GodEater [0] (~bibble@rockbox/staff/GodEater) |
| 20:36:16 | martii | AlexP: did the vfat fsck |
| 20:37:35 | martii | AlexP: so can I put new rockbox now in this recovery mode? |
| 20:37:44 | martii | AlexP: or should I boot into rockbox |
| 20:38:11 | | Quit Stummi (Quit: Bye!) |
| 20:38:21 | AlexP | You can install rockbox like this |
| 20:38:35 | | Join bluefoxx [0] (fuzzylomba@S0106485b3917092d.vs.shawcable.net) |
| 20:40:11 | | Quit evilnick (Ping timeout: 252 seconds) |
| 20:47:20 | | Quit saratoga2 (Quit: Page closed) |
| 20:48:13 | | Quit avacore (Ping timeout: 240 seconds) |
| 20:49:41 | | Join avacore [0] (~avacore@1008ds1-rdo.0.fullrate.dk) |
| 20:50:22 | martii | AlexP: ok I got 3.8.1 on board :) |
| 20:50:48 | AlexP | cool, any better? |
| 20:51:08 | martii | AlexP: I'm doing library refresh :) |
| 20:51:23 | *** | Saving seen data "./dancer.seen" |
| 20:51:24 | AlexP | fingers crossed :) |
| 20:54:27 | martii | AlexP: seems fine :) |
| 20:54:52 | AlexP | good news :) |
| 20:55:10 | martii | AlexP: thanks for help |
| 20:55:20 | AlexP | you're welcome :) |
| 20:55:34 | martii | AlexP: just one more thing - when I long press Play it doesn't shut donw |
| 20:55:36 | martii | down |
| 20:55:41 | AlexP | hmmm, odd |
| 20:55:46 | AlexP | does it do anything? |
| 20:56:08 | martii | I can surf menu and play music |
| 20:56:32 | martii | I have hold menu select for restart |
| 20:57:35 | AlexP | I mean does anything happen when you hold play? |
| 20:57:55 | martii | yep now it turned off |
| 20:58:05 | martii | I was at the main menu |
| 20:58:08 | martii | maybe that was w problem |
| 20:58:09 | * | jhMikeS should maybe just add an impressive-sounding list of fixed playback bugs for his task...later though |
| 20:58:24 | martii | when I did it during the playback it did shutd down |
| 20:59:21 | martii | AlexP: thanks anyway |
| 21:00 |
| 21:01:14 | | Join benedikt93 [0] (~benedikt9@unaffiliated/benedikt93) |
| 21:01:27 | | Quit TheLemonMan (Quit: Destructor called) |
| 21:08:53 | CIA-87 | New commit by Buschel (r29724): Refactor alac decoder as preparation for upcoming m4a changes. The alac decoder does not need to use get_sample_info() to gather frame size or the ... |
| 21:12:33 | CIA-87 | r29724 build result: 0 errors, 62 warnings (Buschel committed) |
| 21:16:19 | | Join liar [0] (~liar@clnet-p09-185.ikbnet.co.at) |
| 21:17:19 | | Nick tchan1 is now known as tchan (~tchan@c-69-243-144-187.hsd1.il.comcast.net) |
| 21:17:25 | Buschel | hmm, I don't get those warnings... what is the right way to cast those? |
| 21:17:30 | | Quit tchan (Changing host) |
| 21:17:30 | | Join tchan [0] (~tchan@lunar-linux/developer/tchan) |
| 21:19:07 | thomasjfox | gevaerts: I think I found the issue |
| 21:19:26 | thomasjfox | gevaerts: Upon first initialization, global_settings.backdrop_file contains "cabbiev2" |
| 21:19:42 | thomasjfox | gevaerts: If I re-set the theme, it changes to /.rockbox/backdrops/cabbiev2.bmp |
| 21:19:48 | gevaerts | ah |
| 21:20:05 | thomasjfox | gevaerts: Does that make any sense to you? |
| 21:20:34 | gevaerts | a bit, yes |
| 21:21:15 | gevaerts | The setting used to store just the basename of the file, while now it stores the full path |
| 21:21:25 | gevaerts | That means the default is now wrong |
| 21:21:49 | thomasjfox | That and we should implement some kind of upgrade path |
| 21:22:43 | gevaerts | Buschel: I'm getting those too. Are you on a 32 bit system> |
| 21:22:44 | gevaerts | ? |
| 21:23:11 | Buschel | cygwin, win xp |
| 21:23:31 | gevaerts | I'm on 64 bit linux |
| 21:23:55 | gevaerts | thomasjfox: can you try http://pastebin.com/gya7C3me |
| 21:23:56 | gevaerts | ? |
| 21:24:56 | Buschel | gevaerts: can you check if http://pastie.org/1801493 helps? |
| 21:25:28 | | Quit MethoS- (Read error: Connection reset by peer) |
| 21:25:39 | thomasjfox | gevaerts: works! |
| 21:25:42 | gevaerts | Buschel: that helps |
| 21:25:49 | Buschel | thanks :) |
| 21:26:14 | CIA-87 | New commit by Buschel (r29725): Fix yellow. |
| 21:26:25 | CIA-87 | New commit by gevaerts (r29726): Since r29700 changed the way the backdrop setting works, the default needs to be updated too |
| 21:26:51 | thomasjfox | gevaerts: Is there some kind of system/API to perform config file upgrades? |
| 21:26:57 | gevaerts | no |
| 21:27:25 | gevaerts | But in this case I'd say "You may have to re-choose the theme" in the release notes should be fine |
| 21:27:37 | thomasjfox | Then we'll need another way to prevent everyone from re-setting their backdrop in 3.9 |
| 21:29:39 | thomasjfox | gevaerts: what about testing if global_settings.backdrop_file contains a "/" and convert it otherwise? |
| 21:30:16 | CIA-87 | r29725 build result: All green |
| 21:30:54 | gevaerts | thomasjfox: we haven't traditionally done that sort of thing I think |
| 21:31:08 | | Quit [Saint] (Read error: Connection reset by peer) |
| 21:32:15 | AlexP | No, we've just said you need to reselect or whatever |
| 21:32:15 | thomasjfox | gevaerts: It's the golden rule at $dayjob: An update is not allowed to break existing setups if achievable |
| 21:32:29 | AlexP | Depends what is needed |
| 21:32:47 | AlexP | That is better of course, but not if it involves lots of complications |
| 21:32:55 | AlexP | We aren't a commercial vendor after all :) |
| 21:33:05 | | Join [Saint] [0] (~st.lasciv@124-197-14-130.callplus.net.nz) |
| 21:33:10 | | Join saratoga [0] (9803c6dd@rockbox/developer/saratoga) |
| 21:33:13 | gevaerts | thomasjfox: "if achievable", or "if achievable at reasonable cost"? |
| 21:33:36 | CIA-87 | r29726 build result: All green |
| 21:33:54 | AlexP | We broke the entire skin system before between releases, this is nothing :) |
| 21:33:58 | thomasjfox | gevaerts: all commercial vendors have that hidden "at reasonable cost" thing attached to every sentence they say |
| 21:34:05 | gevaerts | thomasjfox: we do too :) |
| 21:34:21 | gevaerts | A few hundred bytes per setting adds up... |
| 21:35:21 | thomasjfox | if config.cfg would contain "version: 3.8.1"+ in the future, we could perform little adjustments on the first start |
| 21:35:41 | thomasjfox | in fact, that should be very easy to do, just tap into the main startup sequence |
| 21:35:55 | thomasjfox | if the version field is not present, just assume it's pre 3.9 |
| 21:35:57 | gevaerts | Is that *really* worth the code? |
| 21:36:23 | gevaerts | I mean, even assuming most or all changes are automatically doable |
| 21:36:59 | thomasjfox | Well, I normally install updates unattended on my main linux workstation. It would suck to adjust config files after every upgrade |
| 21:37:17 | AlexP | A slightly different scenario |
| 21:37:26 | thomasjfox | Not on RaaA ;) |
| 21:37:32 | gevaerts | You're free to provide update scripts in your .deb :) |
| 21:37:34 | AlexP | yes |
| 21:38:14 | | Join L-Strife89 [0] (~Strife89@168.16.226.187) |
| 21:38:58 | thomasjfox | gevaerts: That would be an option. A generic solution for all targets would be better. At least it broke for jhMikeS on a real target... |
| 21:39:21 | CIA-87 | New commit by Buschel (r29727): Refactor aac decoder as preparation for upcoming m4a changes. The aac decoder does not need to use get_sample_info() to gather frame size or the ... |
| 21:39:28 | gevaerts | A generic solution for all targets would have a quite high cost |
| 21:40:01 | thomasjfox | Simple version check of the config file on startup? It's retrieving one setting |
| 21:40:13 | | Quit piotrekm (Quit: piotrekm) |
| 21:40:20 | gevaerts | A check is easy |
| 21:40:27 | AlexP | And then dealing with how all the settings are now and how they should be |
| 21:40:33 | AlexP | And the conversion of each one |
| 21:40:38 | gevaerts | s/are now/have ever been/ |
| 21:40:42 | AlexP | yep |
| 21:41:08 | thomasjfox | That should be hidden in "update steps" |
| 21:41:11 | | Quit smk (Quit: Leaving) |
| 21:41:23 | thomasjfox | Perform update for 3.8.x -> 3.9 -> 3.9.1 -> 3.10 |
| 21:41:31 | gevaerts | *where*? |
| 21:41:35 | thomasjfox | Every steps just knows which small amount of variables to adjust |
| 21:41:39 | AlexP | Which needs lots of code, no? |
| 21:42:05 | thomasjfox | Just tiny bits if we change config existing config settings at all |
| 21:42:13 | CIA-87 | r29727 build result: All green |
| 21:42:43 | thomasjfox | That code only gets triggered if the "version" in the config mismatches |
| 21:42:53 | gevaerts | But where does that code live? |
| 21:43:02 | thomasjfox | apps/update_config.c? |
| 21:43:05 | gevaerts | There's more to cost than runtime |
| 21:43:44 | gevaerts | Quick quiz: how much RAM do rockbox targets have? |
| 21:43:46 | thomasjfox | Are we running tight on space on some real targets? |
| 21:43:55 | AlexP | We are always tight |
| 21:44:08 | thomasjfox | gevaerts: Some contain just 2MB? |
| 21:44:09 | AlexP | Battery life is king |
| 21:44:11 | gevaerts | yes |
| 21:44:11 | Torne | you could put it in init and discard it |
| 21:44:22 | Torne | not saying i think it's a good idea but something that only runs at boot doesn't need to take up ram |
| 21:44:36 | gevaerts | true |
| 21:46:05 | gevaerts | But there's of course also the work of writing all conversions |
| 21:46:37 | thomasjfox | gevaerts: That can be outsourced to the person changing the config setting :o) |
| 21:47:08 | gevaerts | Sure, it will be done at the same time as the manual changes |
| 21:47:33 | AlexP | And at least those can be done by other people :) |
| 21:48:48 | thomasjfox | That leaves the question if there is an easy way to do this at boot time and then release the occupied memory |
| 21:49:23 | gevaerts | AlexP: but is someone (apart from thomasjfox of course :) going to be motivated to do this? |
| 21:51:05 | AlexP | gevaerts: I have my doubts |
| 21:51:30 | AlexP | And I'd say the only really acceptable way is the non-RAM wasting way |
| 21:51:38 | AlexP | But I'm willing to be proved wrong :) |
| 21:51:41 | thomasjfox | non-RAM wasting is a must |
| 21:52:05 | AlexP | So, yes - the on start and discard way |
| 21:52:44 | thomasjfox | is that related to #ifdef BOOTLOADER or is that something different? |
| 21:53:10 | gevaerts | that's not related |
| 21:53:32 | | Join fyrestorm [0] (~nnscript@68.173.236.93) |
| 21:56:03 | kugelp | re backdrop: are existing themes handled? |
| 21:56:12 | thomasjfox | Is there any easy way to implement the code discard without fiddling with dlopen()/other kinds of "buffering" stuff? |
| 21:56:15 | thomasjfox | kugelp: no |
| 21:56:19 | kugelp | oh wait, nevermind, the .cfg always had the full path |
| 21:56:29 | gevaerts | Ah, right |
| 21:56:37 | gevaerts | So it's really only manually set backdrops |
| 21:56:39 | kugelp | just not the in-memory representaton |
| 21:57:15 | thomasjfox | kugelp: The full path is only present if you selected the theme manually once |
| 21:57:26 | Torne | didn't we submit the patch that discards .init after boot? |
| 21:58:08 | kugelp | thomasjfox: well, you need to reboot to upgrade rockbox. and the .cfg is parsed on reboot :) |
| 21:58:57 | | Join BHSPitMini [0] (~BHSPitMon@74.5.104.71) |
| 21:59:12 | thomasjfox | kugelp: -Parsing- a config file still doesn't put a full path in it :o) |
| 21:59:36 | | Quit jhMikeS (Ping timeout: 258 seconds) |
| 21:59:48 | kugelp | thomasjfox: As I just said, the .cfg always had the full path |
| 22:00 |
| 22:00:04 | thomasjfox | kugelp: Let me try again |
| 22:01:31 | | Join mudd1 [0] (~cmertes@ip-78-94-202-227.unitymediagroup.de) |
| 22:01:41 | * | thomasjfox fires up his backup disc to look at his previous backup of the n900 |
| 22:02:00 | gevaerts | kugelp: the theme .cfg |
| 22:02:08 | gevaerts | Oh, wait |
| 22:02:09 | gevaerts | right |
| 22:02:16 | * | gevaerts shuts up |
| 22:03:11 | thomasjfox | ok, my config.cfg doesn't have any backdrop setting at all |
| 22:03:25 | thomasjfox | So this should be fixed since we fixed the cabbiev2 default value, right? |
| 22:03:38 | thomasjfox | I'll retry by removing the backdrop setting from my current config |
| 22:03:38 | gevaerts | Yes, that was really the only problem I think |
| 22:03:45 | | Join TheLemonMan [0] (~lem0n@ppp-206-131.98-62.inwind.it) |
| 22:03:51 | thomasjfox | If so, it will save lots of work ;) |
| 22:04:05 | kugelp | thomasjfox: yes |
| 22:04:33 | | Quit robin0800 (Quit: Leaving) |
| 22:04:55 | thomasjfox | Yep, issue solved :) |
| 22:05:01 | | Quit skapazzo (Ping timeout: 240 seconds) |
| 22:06:14 | | Quit slooopy (Quit: Verlassend) |
| 22:07:06 | | Join skapazzo [0] (~skapazzo@195.81.67.123) |
| 22:08:55 | TheLemonMan | pamaury: how do you build the code ? |
| 22:09:00 | Buschel | lear: you there? |
| 22:10:12 | Buschel | sideral: you there? |
| 22:10:17 | | Join leavittx [0] (~leavittx@89.221.199.187) |
| 22:10:47 | pamaury | TheLemonMan: which code ? |
| 22:11:06 | TheLemonMan | your code that is executed after the OF bootloader |
| 22:12:39 | | Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com) |
| 22:12:55 | pamaury | with the arm gcc that we use for all other arm targets |
| 22:13:04 | pamaury | (not sure if it's your question) |
| 22:13:23 | pamaury | But if you want I can put my code on my github repo |
| 22:13:34 | TheLemonMan | with no particular cflags/asflags/ldflags ? |
| 22:14:04 | pamaury | yes of course, lots of them |
| 22:14:06 | pamaury | :) |
| 22:15:31 | TheLemonMan | i reversed the video init sequence but have no information about the lcd controller nor an example of how to blit |
| 22:16:44 | TheLemonMan | btw, here it is, in case anyone spots a command pattern of a known controller |
| 22:16:45 | TheLemonMan | https://gist.github.com/73c1b1d05fcacb3f1ccc |
| 22:17:14 | | Quit AlexP (Ping timeout: 258 seconds) |
| 22:17:42 | | Join AlexP [0] (~alex@rockbox/staff/AlexP) |
| 22:19:11 | pamaury | TheLemonMan: if it's using the lcdif block of the SoC, the block manages the transfer to the lcd and there is a register that hold the base address of the framebuffer |
| 22:20:00 | pamaury | I haven't got any information on the lcd controller of the fuze+ either |
| 22:20:10 | TheLemonMan | i fear it needs dma tranfers to access that memory |
| 22:20:41 | pamaury | I think the lcdif blocks handles everything |
| 22:21:42 | | Quit skapazzo (Ping timeout: 276 seconds) |
| 22:26:11 | | Join skapazzo [0] (~skapazzo@195.81.67.123) |
| 22:27:24 | TheLemonMan | mind sharing your makefile ? |
| 22:27:54 | CIA-87 | New commit by thomasjfox (r29728): Define LCD dpi for n900, n8xx and the pandora |
| 22:28:52 | pamaury | http://pastebin.com/6GHqQdaa |
| 22:30:18 | | Quit advcomp2019 (Read error: Connection reset by peer) |
| 22:30:44 | CIA-87 | r29728 build result: All green |
| 22:30:45 | | Join advcomp2019 [0] (~advcomp20@97-114-224-157.sxcy.qwest.net) |
| 22:30:45 | | Quit advcomp2019 (Changing host) |
| 22:30:45 | | Join advcomp2019 [0] (~advcomp20@unaffiliated/advcomp2019) |
| 22:31:06 | TheLemonMan | mind sharing the linkerscript too ? |
| 22:32:23 | pamaury | http://pastebin.com/2JWA6ZXN |
| 22:35:19 | | Quit robin0800 (Remote host closed the connection) |
| 22:39:09 | | Join robin0800 [0] (~robin0800@cpc3-brig8-0-0-cust703.3-3.cable.virginmedia.com) |
| 22:39:22 | | Quit skapazzo (Read error: Connection reset by peer) |
| 22:47:48 | TheSeven | bertrik: how much IRAM does the clip+ actually have? |
| 22:48:16 | TheSeven | the datasheet says 320KB, but the code tells me that it's at least 1M |
| 22:49:42 | saratoga | 1MB for the clip |
| 22:49:44 | saratoga | + |
| 22:49:51 | saratoga | the clipv1 has 320KB |
| 22:50:05 | saratoga | AMSv2 updated the iram to 1MB |
| 22:50:12 | saratoga | and also made it a lot faster |
| 22:50:41 | sideral | Hi Buschel |
| 22:51:03 | | Join skapazzo [0] (~skapazzo@195.81.67.123) |
| 22:51:17 | Buschel | sideral: hi! can you test a thing for me? :) |
| 22:51:25 | *** | Saving seen data "./dancer.seen" |
| 22:51:57 | * | skapazzo sure is happy his router waited until now to get all warm and crashy |
| 22:52:11 | sideral | Buschel: sure! but unfortunately not tonight |
| 22:52:24 | sideral | you mean the m4a patch? |
| 22:52:28 | Buschel | sideral: will you have some tomorrow? |
| 22:52:30 | Buschel | yes |
| 22:53:12 | sideral | I think I can manage tomorrow, possibly late at night. which one should I test? |
| 22:53:23 | Buschel | I will update a next patch tonight (speed up of the table build-up) |
| 22:53:29 | Buschel | just the latest |
| 22:53:46 | sideral | alright |
| 22:54:54 | sideral | thanks a lot for your work on this! looking forward to listening my long m4a podcasts on my mp3 player again :) |
| 22:58:02 | | Quit benedikt93 (Quit: Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.) |
| 23:00 |
| 23:00:12 | sideral | AlexP, saratoga: I now have a working prototype of dynamic DB update for new tracks. Did you guys have any interest in this that's more than purely academic? |
| 23:00:53 | AlexP | sideral: I wanted to use the resume system without a full blown database |
| 23:00:56 | saratoga | i'm curious how it works, but i don't know that code well enough to give useful feedback |
| 23:01:14 | sideral | (dynamic update = add as they are played) |
| 23:01:23 | | Quit Bagder (Quit: connection reset by beer) |
| 23:01:36 | TheLemonMan | pamaury: can i haz your crt0 too ? mine refuses to pass trough gcc |
| 23:01:40 | AlexP | sideral: Does it respect database.ignore? |
| 23:02:10 | sideral | AlexP, saratoga: OK, I'll post it to FS tomorrow or the day after. Right now it's still woefully inefficient as it does a full commit for each new track |
| 23:02:15 | sideral | AlexP: Not yet |
| 23:02:21 | AlexP | OK :) |
| 23:02:46 | sideral | Would that be important? Do you ever play tracks out of an db.ignore'd directory? |
| 23:02:52 | CIA-87 | New commit by thomasjfox (r29729): Update maemo build changelog |
| 23:03:53 | gevaerts | sideral: the question is really "Why does AlexP have a database.ignore in the first place?" :) |
| 23:04:06 | AlexP | I don't |
| 23:04:12 | AlexP | As I don't use the database |
| 23:04:31 | AlexP | But when this is in I would have it ignore all my music and just add spoken word when needed |
| 23:04:43 | AlexP | So that I get resume on those |
| 23:04:59 | * | gevaerts nods |
| 23:04:59 | saratoga | it seems like that might be more confusing then helpful (since it would mean that music in some folders might not be resumable for reasons not immediately clear to the user) |
| 23:05:02 | sideral | I see |
| 23:05:14 | AlexP | saratoga: That's down to the user though surely |
| 23:05:34 | AlexP | By default it would work on anything the database does like now |
| 23:05:51 | saratoga | wouldn't it make more sense to add the files regardless and just have a flag that makes them not sure up in the database view? |
| 23:06:03 | AlexP | I don't use the db at all |
| 23:06:05 | CIA-87 | r29729 build result: All green |
| 23:06:21 | | Quit BHSPitMini (Ping timeout: 260 seconds) |
| 23:06:25 | AlexP | But seeing as I'm forced to with the resume system, I'd rather it be as small as possible |
| 23:06:26 | saratoga | or even just have a regular full database update set the flag, so that if a user isn't using the database view, but wants things like resume info, they don't have to care |
| 23:06:28 | | Join Bagder [0] (~daniel@rockbox/developer/bagder) |
| 23:07:16 | | Join silbo [0] (~quassel@81-21-243-46.televork.ee) |
| 23:07:29 | sideral | I think it's important to really not include db.ignore'd files in the DB, as that may be the majority of files on the device (think RaaA) |
| 23:07:39 | AlexP | yep |
| 23:08:04 | sideral | at least for the regular DB init. I don't care as much for files the user actually plays |
| 23:08:04 | AlexP | This is all I'm saying - I put database.ignore in my music folder and they don't get added |
| 23:08:19 | pamaury | TheLemonMan: sorry for the delay, crt0.S comes :) |
| 23:08:21 | AlexP | I don't have it in spken word and they do get added |
| 23:08:33 | AlexP | Exactly like now for db init |
| 23:08:45 | sideral | I'll think about it. |
| 23:09:01 | saratoga | probably the best way is to just add everything thats played, and have a db scan flag anything thats near an ignore file as invisible |
| 23:09:17 | AlexP | It'd also be confusing the other way - I set database.ignore, why has it shown up? |
| 23:09:22 | pamaury | TheLemonMan: http://pastebin.com/cMT07JQ8 |
| 23:11:30 | TheLemonMan | no luck :| |
| 23:11:47 | pamaury | with video ? |
| 23:16:21 | sideral | AlexP, saratoga: thanks for your input for now. Need to leave now unfortunately. Your homework: put a comment into FS #12054 (Highlight each album's last-played track in database views - great for audiobooks and podcasts) |
| 23:16:27 | sideral | ;) |
| 23:16:48 | AlexP | hehe :) |
| 23:17:23 | TheLemonMan | the player rebooted at some point |
| 23:18:07 | | Quit mshathlonxp (Quit: poweroff) |
| 23:18:10 | pamaury | you need to init the sdram before |
| 23:18:15 | pamaury | (probably) |
| 23:21:11 | | Quit avacore (Ping timeout: 248 seconds) |
| 23:22:08 | | Quit sideral (Quit: Leaving.) |
| 23:23:09 | | Join avacore [0] (~avacore@1008ds1-rdo.0.fullrate.dk) |
| 23:23:39 | | Join smk [0] (~smk@116.72.193.20) |
| 23:26:32 | smk | hi. i want to be able to know which function is being run while i am using my simulator.to understand the code.so i have put debug info in the threads to print stuff when they are running.is there anything else i need to be tracking?other than the threads? |
| 23:27:51 | smk | and i identified the threads by calls made to create_thread(). if i am not wrong. |
| 23:31:00 | | Quit smk (Quit: Leaving) |
| 23:33:41 | | Quit JesusFreak316 (Ping timeout: 246 seconds) |
| 23:35:19 | | Quit {phoenix} (Remote host closed the connection) |
| 23:43:00 | CIA-87 | New commit by thomasjfox (r29730): Increase pandora build version |
| 23:46:08 | CIA-87 | r29730 build result: All green |
| 23:46:40 | | Quit factor (Read error: Connection reset by peer) |
| 23:52:03 | | Join GeekShadow [0] (~Antoine@reactos/tester/GeekShadow) |
| 23:52:51 | | Quit [Saint] (Quit: I'm only going to Heaven if it feels like Hell, I'm only going to Heaven if it tastes like caramel...) |
| 23:56:50 | | Join factor [0] (~factor@75.108.68.114) |
| 23:57:07 | | Join [Saint] [0] (~st.lasciv@124-197-14-130.callplus.net.nz) |
icon identifies that the person is a core developer (has commit access).