00:00:28 | saratoga | linuxstb: I see what you mean about other flac decoders being slow, take a look at the Clip battery life for FLAC vs. MP3 in the retail firmware: http://forums.sandisk.com/sansa/board/message?board.id=clip&thread.id=14326 |
00:00:47 | saratoga | they must be clocking that thing at 100+ MHz for flac playback |
00:01:05 | linuxstb | wow... |
00:01:07 | pixelma | on the wiki page there is a note that it says it is on OSX. What OS are you running ferric84? |
00:01:25 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
00:01:34 | ferric84 | i'm on ubuntu 8.10 |
00:01:45 | pixelma | hmm, don't know then |
00:04:10 | ferric84 | yeah. who knows |
00:04:44 | linuxstb | saratoga: I can't see any recent flac benchmarks on the SansaRuntime wiki page, but there is one from Jan 2008 (with patches) that gives > 20 hrs. So I'm guessing mp3/flac are similar in Rockbox now? |
00:05:19 | saratoga | linuxstb: I think flac is actually a lot faster then MP3 |
00:06:02 | kugel | FlynDice: I found something interesting. Have a look how GPIOB differs depending on the background color |
00:06:20 | saratoga | linuxstb: wiki says 13MHz for flac playback |
00:07:15 | saratoga | the best part is thats an ARMv5E CPU with 512KB of IRAM in the second bench, so they've got single cycle MAC and memory access |
00:07:32 | | Quit Llorean ("Leaving.") |
00:07:51 | | Join flx_ [0] (i=flux@jolt.modeemi.cs.tut.fi) |
00:08:04 | | Part piotrek2234 |
00:08:08 | | Join pixelma_ [50] (n=pixelma@rockbox/staff/pixelma) |
00:08:08 | | Quit pixelma (Nick collision from services.) |
00:08:11 | | Quit flux (Read error: 104 (Connection reset by peer)) |
00:08:23 | | Nick pixelma_ is now known as pixelma (n=pixelma@rockbox/staff/pixelma) |
00:08:30 | kugel | linuxstb: I've posted results to the CodecPerformanceComparision page some month ago |
00:08:33 | | Quit itcheg ("http://www.mibbit.com ajax IRC Client") |
00:08:35 | | Quit mipfi ("Get MacIrssi - http://www.sysctl.co.uk/projects/macirssi/") |
00:08:39 | kugel | that was after the mp3-on-cop commit |
00:09:03 | | Quit amiconn (Nick collision from services.) |
00:09:04 | | Join amiconn_ [50] (n=jens@rockbox/developer/amiconn) |
00:09:10 | ferric84 | how do you exit an application? |
00:09:13 | saratoga | speaking of which, I should update those with WMA results |
00:09:15 | ferric84 | like metronome for example.. |
00:09:24 | | Nick amiconn_ is now known as amiconn (n=jens@rockbox/developer/amiconn) |
00:09:29 | linuxstb | kugel: Yes, but how does that translate into battery life differences? |
00:09:56 | kugel | linuxstb: well, the initial question was whether flac and mp3 are comparable now |
00:10:00 | linuxstb | ferric84: Mostly MENU+SELECT. The Rockbox manual should describe it. |
00:10:07 | saratoga | linuxstb: on flash targets, it probably won't since we clock the CPU at 30MHz |
00:10:11 | ferric84 | gotcha. thanks |
00:10:13 | linuxstb | kugel: Yes, _runtime comparable_ |
00:10:23 | saratoga | at best you'll get a tiny savings from sleeping the core |
00:10:28 | saratoga | but thats extremely small |
00:10:44 | | Join Llorean [0] (n=DarkkOne@ppp-70-243-32-116.dsl.hstntx.swbell.net) |
00:11:01 | kugel | linuxstb: well, flac perfoms very faster, but both don't boost, so they are comparable |
00:11:16 | kugel | you can get above 20h with both |
00:11:52 | saratoga | i think we're somewhere around 25 hours now for a brand new battery based on the current draw measurements |
00:12:28 | saratoga | once all the current improvements go in, and the core clock is lowered, and wps updates on screen off are disabled, we'll probably be just short of 30 hours |
00:12:34 | kugel | that's a wild assumption :) |
00:12:55 | saratoga | well thats assuming the OF actually gets 20 too |
00:13:02 | kugel | I'd say it's nearer to 25h than to 20h, but I doubt it's above 23.xh |
00:13:14 | saratoga | lets say on a battery that gives the OF 20 hours, I think we'd be around 25 |
00:13:52 | kugel | the OF isn't so bad |
00:13:54 | saratoga | i'll do another round of measurements once all the work in progress power savings stuff goes through |
00:14:05 | kugel | I don't think we can get 30h |
00:15:34 | | Quit matsl (Remote closed the connection) |
00:15:35 | | Join moos [0] (i=Mustapha@rockbox/staff/moos) |
00:15:42 | saratoga | 30 hours means 25mA draw, Toni claimed he got 28mA at 24MHz core clock |
00:16:00 | | Join rakslice [0] (n=rak@S010602055dee5503.ok.shawcable.net) |
00:16:00 | saratoga | so we'd have to find another 3 mA somewhere else |
00:16:27 | saratoga | the playback DMA stuff gives us 300uA, so we're 10% there |
00:16:47 | saratoga | disabling updates when the screen is off is probably another 1-1.5mA |
00:17:02 | kugel | it's a bit less than 1h |
00:17:38 | | Quit ferric84 ("Leaving") |
00:17:53 | saratoga | thats about 1.5mA then |
00:18:42 | saratoga | i guess someone using FLAC with the unboosted clock at 16MHz would save another 2.5mA, so they'd probably break 30 hours, but that'd be a trick with MP3 |
00:19:30 | saratoga | though maybe we'll get lucky and someone will show up with another hard ware device we don't properly power down like Toni did this fall |
00:19:52 | kugel | saratoga: http://www.rockbox.org/mail/archive/rockbox-dev-archive-2008-12/0127.shtml |
00:21:22 | kugel | saratoga: UI will be a pain though @16MHz ;) |
00:21:58 | kugel | I'm still unsure why the zero boost wait is rotting. The UI wasn't that bad, and it would allow shrinking the pcmbuf a bit |
00:22:53 | saratoga | kugel: from what i understand, it could be commited with the UI left at 30MHz |
00:23:16 | saratoga | but if we want to lower the clock to 24, it'd still need more boost calls added to the actual UI code so that it doesn't lag |
00:23:30 | saratoga | I've actually been meaning to ask Zagor about that |
00:23:51 | saratoga | i'm unsure if he still has other plans before its committed |
00:24:05 | kugel | we could just boost lcd_update for the beginning, until some proper ui boost is worked out |
00:24:09 | kugel | that would help alot already |
00:24:15 | amiconn | Didn't someone test zero-boost wait and found that it uses a bit more battery than classic boosting? |
00:24:21 | | Quit flydutch ("/* empty */") |
00:24:42 | amiconn | Also, zerowait boost isn't possible on coldfire, so we'd have to maintain two different methods |
00:25:42 | stripwax | amiconn - seems to help on pp if these results (at end) are to be believed http://www.rockbox.org/tracker/task/9800?project=1&type=4&order=dateopened&sort=desc&pagenum=2 |
00:26:11 | kugel | amiconn: http://www.rockbox.org/tracker/task/9797 |
00:26:21 | saratoga | amiconn: the benches are exactly the same, which is as expected since the average clock is also unchanged aside from the tiny speed up from not taking so long to boost |
00:26:38 | saratoga | theres only a speedup once the core clock is lowered |
00:26:46 | kugel | it *is* possible |
00:26:52 | kugel | and we concluded that a dozen times now |
00:28:40 | kugel | "22:28 without this patch, 23:21 with this patch." −− looks noticeable to me |
00:29:01 | *** | Saving seen data "./dancer.seen" |
00:29:16 | * | amiconn is very sceptical about this zero-wait boost |
00:30:00 | saratoga | kugel: thats from adjusting the core clock though, you can get that right now just by lowering it without zero wait boosting |
00:30:04 | amiconn | Sure lowering the unboosted clock will increase runtime, but at the price of laggy ui. And if you do ui boost, it can quite easily reduce runtime below what we started |
00:30:28 | saratoga | amiconn: the idea of zero wait boost is to avoid that problem |
00:30:40 | saratoga | you simply boost in the required UI code, and then unboost when done |
00:30:50 | kugel | amiconn: I don't think so |
00:30:52 | amiconn | UI boost would not only need to kick in when the user is actively doing something, but also e.g. for scrolling |
00:31:19 | saratoga | amiconn: of course, but it doesn't have to stay boosted, even when scrolling the GUI only uses a fraction of the CPU's time |
00:31:41 | saratoga | so scrolling would probably still result in a boost ratio only somewhat higher then normal |
00:31:55 | kugel | once the user is doing UI stuff, the power consumption is higher anyway (backlight, lcd updates, additiona calculations), the boost won't be that noticeable in the end |
00:32:10 | amiconn | I know. I still think it's not worth the hassle, and will make things worse |
00:32:11 | kugel | but the lowered clock will give better runtime when you don't use the player |
00:32:40 | pixelma | yes, runtime is best when I don't use my player ;P |
00:32:41 | saratoga | amiconn: I don't understand your reluctance here |
00:33:06 | saratoga | i assume improved battery life is worth any increase in complexity so long as someone is willing to work on it |
00:33:08 | kugel | pixelma: particulary with lowered clock (e.g. 22MHz instead of 45MHz), which is the point |
00:33:19 | kugel | at least for high-effecient codesc |
00:33:45 | saratoga | and frankly, the increase here some quite small |
00:34:02 | saratoga | we'll need to add a couple calls to boost, and fix up the PP clocking, which probably should be done regardless |
00:34:19 | saratoga | on Coldfire, I suppose it depends on if we can really get away zero wait or not |
00:34:39 | amiconn | saratoga: The improved runtime part is what I don't believe until proven. And I mean not as an experiment, but with proper gui speed |
00:35:01 | | Quit bmbl ("Woah!") |
00:35:03 | saratoga | amiconn: I don't see why GUI speed should have any impact on battery life |
00:35:03 | amiconn | We can not get zero-wait boost on coldfire without risking freezes. Period. |
00:35:16 | amiconn | saratoga: I mentioned it. Scrolling. |
00:35:24 | saratoga | we're literally adding a couple mA of current load while the backlight uses 100mA |
00:35:29 | saratoga | its literally irrelevent |
00:35:51 | saratoga | hmm i used literally twice |
00:36:07 | amiconn | What does the backlight have to do with boost & scrolling?? And if it's irrelevant compared to backlight, you can stop anyway... |
00:36:09 | | Nick JdGordon|zzz is now known as JdGordon (n=jonno@rockbox/developer/JdGordon) |
00:36:23 | JdGordon | amiconn: why cant a track change event based follow playlist work? |
00:36:41 | JdGordon | bareing in mind i just woke up |
00:37:03 | amiconn | JdGordon: "Follow Playlist" is supposed to put you on the currently playing track whenever you leave the wps. So it's a status based operation, not a transition based one |
00:37:30 | | Quit stripwax (Read error: 104 (Connection reset by peer)) |
00:38:07 | kugel | uhm, but the directory changes only at track change |
00:38:32 | kugel | so, the patch only needs to be updated during track change |
00:38:49 | amiconn | Try the follwoing in current rockbox. Start playing a track ('Folow Playlist' enabled of course). Navigate to the browser, move the cursor to a different track. Go back to the wps, and the again go to the browser. The track must not have changed yet. Note at which track you end up.... the one you browsed last. |
00:39:00 | kugel | path* |
00:39:07 | amiconn | You *should* end up on the currently playing track though.... |
00:39:47 | amiconn | kugel: Yeah, but why copy the path on track change to yet another buffer? The wps knows the path anyway... |
00:40:01 | | Join iamben_ [0] (n=ben@ppp-70-250-213-149.dsl.spfdmo.swbell.net) |
00:40:16 | saratoga | amiconn: the only way a properly implemented zero wait boost system can decrease battery life is if it increases average clock [we know this from measurements in fs9800] |
00:40:20 | saratoga | the only way the average clock can increase is if the system decides that a higher clock is needed for smooth UI updates |
00:40:32 | amiconn | It's easier to just set the browser path whenever you leave the wps (if follow playlist is enabled) |
00:40:42 | kugel | "is supposed to put you on the currently playing track " −− I thought just to the folder where the track is (which I'd like more too) |
00:41:00 | saratoga | from my point of view, if the system is properly designed and decides that a higher clock is needed for what the user wants, then I think giving up some battery life is the right thing to do rather then lagging the UI |
00:41:06 | amiconn | saratoga: Of course - and I think that it most probably will |
00:41:10 | kugel | but your example breaks that too, I think |
00:41:18 | saratoga | however I think in practice it will probably be impossible to do that |
00:41:27 | saratoga | scrolling uses very little extra CPU time |
00:41:27 | pixelma | I believe it's been this way (putting you into the directory you browsed last unless track changed in the meantime) for quite a while... |
00:41:38 | amiconn | kugel: What's worst is that all this used to work nicely not too long ago :\ |
00:41:58 | saratoga | its on the order of 10MHz in my testing, which is comparable to what is saved by lowering the CPU clock |
00:41:59 | JdGordon | workking, and working nicely are not the same |
00:42:18 | saratoga | realistically you'd have to scroll for hours and hours to cancel out the savings from the lowered clock when you weren't scrolling |
00:42:29 | saratoga | the battery would die first from the back light |
00:42:36 | amiconn | huh? |
00:42:39 | kugel | saratoga: I think he means scrollin lines, but I'm not sure |
00:42:46 | | Quit gregzx ("ChatZilla 0.9.84 [Firefox 3.0.6/2009011913]") |
00:42:48 | amiconn | What does the backlight have to do with scrolling? |
00:42:58 | amiconn | Yes I mean scrolling lines of course |
00:43:06 | saratoga | aside from ipod users, most people use both at the same time |
00:43:12 | saratoga | and even then, most ipod users use both |
00:43:30 | rakslice | perhaps scrolling turns the backlight on? |
00:43:30 | pixelma | Ipod users? |
00:43:43 | saratoga | indeed it does, at least by default |
00:44:11 | kugel | scrolling lines don't turn the backlight on |
00:44:16 | pixelma | scrolling lines in e.g. the WPS don't turn the backlight on, otherwise it would almost constantly be on |
00:44:24 | saratoga | i mean scrolling lines in lists |
00:44:45 | saratoga | scrolling lines in WPSes isn't all that CPU intensive |
00:44:48 | kugel | You're obviously not talking about the same scrolling here ;) |
00:45:02 | pixelma | they don't either if you just stay in the list or menu without moving up or down... |
00:45:19 | amiconn | I mean scrolling text in the wps of course, which can (depending on display and font size) scroll for hours and hours without any backlight involved (on transflective displays) |
00:45:20 | kugel | saratoga: it's more cpu intensive as you think |
00:45:34 | saratoga | your benchs put it at 1.5mA |
00:46:04 | saratoga | small compared to scrolling in lists anyway |
00:46:18 | saratoga | the ipod video probably needs 5+ mA to do that |
00:47:18 | amiconn | And scrolling text already looks odd at 30MHz on G5 iirc. If you want to lower unboosted clock (which would be the only reason to introduce zero-wait boost), you need gui boost, including for whenever the scroll thread kicks in. And then I doubt that any savings remain, unless your wps never scrolls |
00:48:07 | | Quit domonoky (Read error: 104 (Connection reset by peer)) |
00:48:28 | amiconn | Also, you then have to maintain two strategies, zero-wait boost and classic boost. It *may* become necessary to have different strategies anyway though (thinking i.MX31 here, with its dynamic voltage adjustment) |
00:49:01 | JdGordon | amiconn: your recipe 5min ago works fine on h300... the problem is not in that diff... its in hwcodec doing something differently |
00:49:19 | * | JdGordon disagrees that using the track change event for follow playlist is bad |
00:49:26 | | Join SoapWork [0] (n=42c07542@gateway/web/cgi-irc/labb.contactor.se/x-5f09861aed6e246d) |
00:49:49 | kugel | is it better? |
00:51:16 | amiconn | JdGordon: The wps already knows the current track's path? So why copy it somewhere else, using an event? Sounds unnecessarily complex to me |
00:51:26 | amiconn | s/\?/./ |
00:52:00 | JdGordon | amiconn: either way it gets copied, at the end of the playlist the id3 pointer is invalid so the wps loses the position |
00:53:14 | JdGordon | the change is when its saved, previously it wasted the MAX_PATH in the wps struct which needed the cleanup and so moved the buffer to where its actually used (i.e root menu) |
00:53:16 | amiconn | I don't understand.... |
00:53:49 | kugel | how's the id3 struct of the current track invalid? |
00:54:02 | JdGordon | at the end of the playlist |
00:54:08 | amiconn | Without events, the wps would copy the path to the browser when leaving the wps. With events, the event will cause copying the path to an extra buffer. When leaving the wps, it needs to be copied again - to the browser |
00:54:39 | kugel | JdGordon: how? |
00:54:40 | JdGordon | that second copy doesnt happen |
00:54:54 | | Quit SoapWork ("CGI:IRC (Ping timeout)") |
00:55:06 | JdGordon | kugel: at playlist_stop() (or maybe audio_stop()) the current track info is \0'ed |
00:55:15 | amiconn | Hmm? So how is the scenario I described earlier supposed to work? |
00:55:31 | amiconn | Iiuc, you mean that tthe track change event copies the path directly to the browser? |
00:55:38 | JdGordon | yes |
00:55:48 | amiconn | So the screnario I described *cannot* work |
00:56:06 | JdGordon | well, not entirely... its copied to the root menu which checks if it should use it based on which screen was the previous one |
00:56:09 | amiconn | ...because if you go to the browser and browse somewhere else, the current path will be changed |
00:56:35 | amiconn | I don't go to the root menu - I use ON to go directly from WPS to browsxer |
00:56:46 | amiconn | And then the scenario I described breaks here |
00:56:49 | kugel | JdGordon: why is it \0'd? is there any advantage to not keep the id3 pointer after stopping playback? |
00:56:56 | amiconn | (would be SELECT on irivers) |
00:57:32 | JdGordon | kugel: I dont know and it caught me out elsewhere... it just does |
00:57:41 | * | amiconn tests on iriver |
00:57:48 | | Quit ender` (" We're not lost. We're locationally challenged. -- John M. Ford") |
00:58:18 | kugel | I'd just stop the \0'ing, it sounds unnecessary to me anyway. the event stuff sounds more complex than needed to me too |
00:58:41 | | Quit tessarakt ("Client exiting") |
00:58:44 | amiconn | Hmm, it does indeed work on iriver. So why does it? |
00:58:53 | JdGordon | amiconn: just tried again... the only time it might not work is if you press navi before the event gets fired (so while its buffering very quickly after pressing on) |
00:59:17 | JdGordon | because there is a difference in the way swcodec and hwcodec handles end of playlist... |
00:59:24 | amiconn | The first-time "follow playlist" *does* work on hwcodec, but neither does it work at end-of-playlist nor when trying the described scenario |
00:59:51 | amiconn | The scenario has nothing to do with end-of-playlist |
01:00 |
01:00:03 | | Part iamben_ |
01:00:08 | JdGordon | no, im surprised that doesnt work on hwocdec |
01:01:45 | amiconn | Hmm, why does it work now????? |
01:02:00 | amiconn | I tried a few hours ago, over and over. It never worked.... |
01:02:33 | amiconn | Meh, I hate bugs that change behaviour when trying to hunt them down :\ |
01:03:15 | JdGordon | haha |
01:03:48 | amiconn | Really. I tried dozens of builds (past-r19747), and none of them worked in the described scenario |
01:04:22 | JdGordon | if you go wps->browser->menu->browser then what you said should happen (i.e look broken) but if you always go wps->broswer then it shold work fine |
01:04:58 | JdGordon | end of playlist *is* definetly broken though yeah? |
01:05:00 | amiconn | Browser-menu-browser shouldn't put you on the currently playing track. Just leaving the wps should |
01:05:02 | amiconn | yes |
01:05:18 | amiconn | It even causes a null-pointer access in r19747 and later |
01:06:50 | JdGordon | a quick fix for that could be just check id3 (root_menu.c:82) is not null? |
01:07:36 | amiconn | That wouldn't fix the problem though - only the null pointer access |
01:09:22 | JdGordon | I think it actually will... |
01:09:26 | kugel | I'm still not convinced of the event thing, I agree that the wps should handle that |
01:09:51 | JdGordon | the previous track path will stay untouched so you'll end up at the last track of the laylist |
01:09:57 | kugel | since it's only supposed to happen upon leaving the wps anyway, so it's more a wps feature |
01:11:27 | amiconn | JdGordon: If it does, the underlying problem is probably that hwcodec also sends a track chnage event at the end of playlist, while swcodec doesn't |
01:11:34 | amiconn | Now which is the correct behaviour? |
01:11:43 | JdGordon | swcodec is correct in that case |
01:11:55 | JdGordon | track change is for when the new track actually starts playing |
01:12:22 | amiconn | Hmm |
01:12:35 | amiconn | Now I only need to understand why the mpeg thread doe sthat |
01:15:03 | kugel | when the event won't be sent, you can safe the check for NULL, not? |
01:15:15 | kugel | s/safe/avoid |
01:16:42 | amiconn | yes |
01:17:00 | amiconn | Not sending the event would be correct iiuc |
01:21:39 | | Quit BHSPitLappy (Remote closed the connection) |
01:26:11 | | Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") |
01:29:48 | amiconn | JdGordon: r20014 :) |
01:30:10 | JdGordon | nice work :) |
01:30:21 | * | JdGordon heard the disks churning and wondered who commited something |
01:31:03 | JdGordon | hopefully that doesnt break anyting :D |
01:31:10 | | Join SoapWork [0] (n=42c07542@gateway/web/cgi-irc/labb.contactor.se/x-9bcf573b974cf401) |
01:32:01 | | Join topbloke [0] (i=top_blok@adsl-75-56-63-135.dsl.emhril.sbcglobal.net) |
01:32:26 | | Quit SoapWork (Client Quit) |
01:33:24 | kugel | JdGordon: I think the actual bug is line 843 |
01:33:46 | JdGordon | of which file? there are quite a few in the repo :p |
01:33:51 | kugel | mpeg.c |
01:34:27 | kugel | queue_post(&mpeg_queue, MPEG_TRACK_CHANGE, 0);playing = false; |
01:34:52 | kugel | that's on stopping, this post should be removed, not check for playing in the queue |
01:34:53 | amiconn | MPEG_TRACK_CHANGE != PLAYBACK_EVENT_TRACK_CHANGE |
01:35:31 | kugel | amiconn: queue_post(&mpeg_queue, MPEG_TRACK_CHANGE, 0); will cause track_change() to be called |
01:35:42 | kugel | I noticed the difference... |
01:36:13 | kugel | amiconn: and track_change is sending the event |
01:36:30 | JdGordon | its probably also doing important stuff like cleanups |
01:36:55 | amiconn | Yes, but not only. It's also doing some other important things |
01:38:23 | * | kugel wonders if stop works |
01:38:37 | kugel | nevermind |
01:39:26 | amiconn | That said, mpeg.c is kind of a mess. The question is whether it should be cleaned up, or hwcodec should be made to use playback.c, or yet a third solution (e.g. write a new, lightweight playback engine based on finding from both mpeg.c and playback.c) |
01:39:35 | | Join nuonguy [0] (n=john@c-24-6-174-132.hsd1.ca.comcast.net) |
01:39:46 | amiconn | *findings |
01:40:09 | amiconn | But first of all, mpeg.c needs to be split into the recording and playback parts |
01:41:24 | kugel | sounds wrong to me that track_change() is called on playlist _end_, but yea, it's a mess ;) |
01:43:14 | amiconn | track_change() *is* what detects end-of-playlist (by calling update_playlist()) - transfer_end() merely indicates that it is out of mpeg data due to a track end (with potentially more tracks to follow) |
01:44:25 | | Join cool_walking_ [0] (i=cb3b81c3@gateway/web/ajax/mibbit.com/x-a1dd26fcc5e26781) |
01:46:36 | | Join jordoex [0] (n=quassel@d154-20-53-81.bchsia.telus.net) |
01:49:29 | kugel | amiconn: why is num_tracks_in_memory() even returnin > 0? |
01:49:50 | amiconn | Because there is a track in memory? |
01:50:04 | kugel | the one that just ended, you mean? |
01:50:19 | kugel | how's that one interesting when the playlist ends? |
01:50:56 | amiconn | remove_current_tag() is what removes the current one from the list, so num_tracks_in_memory() yields 1 before |
01:51:15 | kugel | ah ok |
01:52:06 | kugel | shouldn't it remove the track before? |
01:52:39 | amiconn | What I don't understand is why the test is even there. It should always be true, otherwise something's seriously broken, and playback would never stop |
01:53:01 | kugel | yep, that's what I'm thinking too |
01:53:38 | JdGordon | amiconn: I thought ou were against major work in mpeg.c because it has been pretty stable? |
01:54:00 | amiconn | It is pretty stable in general, but it's also quite messy |
01:54:30 | amiconn | I always said that I would like to see the playback engines unified, but then playback.c used to be far less stable than mpeg.c |
01:55:04 | * | amiconn btw thinks that playback.c isn't really clear either, although it became a lot better already |
01:55:58 | amiconn | It's also quite long - almost as long as mpeg.c even though the latter contains both playback and recording |
01:56:51 | JdGordon | part of that is the codec stuff which isnt in mpeg.c isnt it? |
01:58:26 | JdGordon | not completly relevant, but we havnt decided what so of api playlist<->playback should use... once thats set there is a chance playback can be cleaned up more |
01:58:38 | | Quit Thundercloud (Remote closed the connection) |
01:59:09 | amiconn | It might be a good idea to split the codec handling stuff from playback.c |
01:59:11 | | Quit topbloke ("bye") |
01:59:56 | | Join Nico_P [50] (n=nicolas@rockbox/developer/NicoP) |
02:00 |
02:01:47 | JdGordon | could the MAS be thought of as just a hardware codec? so if things were usnified we could use the same api for it and the sw codecs? |
02:03:01 | kugel | why is the SIM #ifndef'd so hard in mpeg.c? |
02:04:50 | JdGordon | because its not closyly simulated like swcodec |
02:04:57 | kugel | it doesn't even have the thread |
02:05:07 | amiconn | Same api will be very difficult, as it really has different constraints (e.g. no overlapping), but the api should become similar |
02:05:14 | | Join shadearg [0] (i=shadearg@ipv4.panoptix.net) |
02:05:18 | JdGordon | actually... it is simulated alot, whereas swcodec runs the same code |
02:10:50 | | Quit shadearg ("goodbye.") |
02:11:16 | amiconn | Btw, playback.c and mpeg.c are not the only playback engines in rockbox. There are at least 3 more: one in mpegplayer, one in video.rock, and another (simple) one in wavplay |
02:11:55 | | Join shadearg [0] (i=arg@ipv4.panoptix.net) |
02:11:59 | amiconn | These are a lot simpler as they don't have to handle track changes though |
02:18:18 | | Quit kugel ("ChatZilla 0.9.84 [Firefox 3.1b2/20081201080242]") |
02:20:21 | JdGordon | sure, but is there any point trying to merge them in also? |
02:27:30 | amiconn | No, but they can be used for comparison |
02:29:05 | *** | Saving seen data "./dancer.seen" |
02:57:11 | | Quit mirak (Remote closed the connection) |
03:00 |
03:07:26 | | Quit Nico_P (Remote closed the connection) |
03:17:45 | | Join SoapWork [0] (n=42c07542@gateway/web/cgi-irc/labb.contactor.se/x-ef27589f236791cf) |
03:19:35 | | Quit SoapWork (Client Quit) |
03:27:34 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
03:35:06 | | Quit moos ("Rockbox rules the DAP world") |
04:00 |
04:07:05 | | Join blkhawk- [0] (n=blkhawk@g230129074.adsl.alicedsl.de) |
04:13:07 | | Join AndyIL [0] (i=AndyI@212.14.205.32) |
04:23:12 | | Quit blkhawk (Read error: 110 (Connection timed out)) |
04:24:03 | | Nick blkhawk- is now known as blkhawk (n=blkhawk@g230129074.adsl.alicedsl.de) |
04:24:40 | | Join SoapWork [0] (n=42c07542@gateway/web/cgi-irc/labb.contactor.se/x-4e7f95d2ab30f794) |
04:26:47 | | Quit AndyI (Read error: 110 (Connection timed out)) |
04:27:15 | | Quit SoapWork (Client Quit) |
04:29:08 | *** | Saving seen data "./dancer.seen" |
04:39:20 | | Quit miepchen^schlaf (Connection timed out) |
04:44:27 | | Join BHSPitMonkey [0] (n=stephen@unaffiliated/bhspitmonkey) |
04:44:36 | * | JdGordon so loves bugs which dont effect the sim :( |
04:45:09 | | Join Barahir_ [0] (n=jonathan@Ya417.y.pppool.de) |
04:45:44 | | Quit Barahir (Read error: 60 (Operation timed out)) |
04:58:49 | | Join likemindead [0] (n=mccracke@96-25-231-104.ama.clearwire-dns.net) |
05:00 |
05:02:23 | | Part likemindead ("I'm out--like a boner in sweat pants... 0_o") |
05:09:16 | | Quit Llorean ("Leaving.") |
05:12:58 | | Join Llorean [0] (n=DarkkOne@ppp-70-243-32-116.dsl.hstntx.swbell.net) |
05:15:40 | | Quit daurnimator (Read error: 60 (Operation timed out)) |
05:15:54 | | Join daurnimator [0] (n=quae@ppp118-208-190-24.lns10.mel4.internode.on.net) |
05:28:21 | | Part Aurix_Lexico |
05:28:21 | | Join `Assassin [0] (n=blank@71-8-56-51.dhcp.leds.al.charter.com) |
05:37:28 | | Join webguest09 [0] (n=ad167099@gateway/web/cgi-irc/labb.contactor.se/x-124f00fe0a820953) |
05:38:57 | | Quit webguest09 (Client Quit) |
05:39:10 | | Join webguest49 [0] (n=ad167099@gateway/web/cgi-irc/labb.contactor.se/x-e87f1072fd0426b6) |
05:40:10 | | Quit webguest49 (Client Quit) |
05:40:33 | | Quit Horscht ("Verlassend") |
05:46:27 | | Join SoapWork [0] (n=hall@66-192-117-66.static.twtelecom.net) |
05:53:41 | | Join Acky [0] (n=omgwtfbb@cpc1-stok5-0-0-cust655.bagu.cable.ntl.com) |
05:53:47 | | Quit rocko ("Leaving") |
05:56:10 | | Join rocko [0] (n=rocko@c-67-167-117-152.hsd1.il.comcast.net) |
06:00 |
06:01:01 | | Quit rocko (Client Quit) |
06:04:56 | | Quit CaptainKewl (Read error: 60 (Operation timed out)) |
06:08:09 | | Quit Acksaw (Connection timed out) |
06:17:59 | Unhelpful | here's my bufalloc-like allocator so far, with some very simplistic tests. i'll try to tackle compaction in the next few days, it should be pretty simple, just walk the list of blocks from first_free_block up, accumulating the value of each free block, shift used blocks down by that ammount, and update their handle table entries. https://looking-glass.us/~chshrcat/rockbox/allocator_test.zip |
06:20:59 | | Join perrikwp [0] (i=18ac0c41@gateway/web/ajax/mibbit.com/x-02228aba1b5b5539) |
06:24:54 | | Join Tuplanolla [0] (n=jani@unaffiliated/tuplanolla) |
06:25:31 | | Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
06:27:25 | | Join _Auron_ [0] (n=DarkAuro@ppp-70-249-146-14.dsl.rcsntx.swbell.net) |
06:28:40 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
06:29:11 | *** | Saving seen data "./dancer.seen" |
06:33:14 | | Join RoC_MasterMind [0] (n=Free@c-76-122-43-188.hsd1.fl.comcast.net) |
06:33:32 | | Quit RoC_MasterMind (Client Quit) |
06:55:19 | JdGordon | oh bugger.... I've got a bug which freezes up my DAP's and with a bit of adding and removing nothing but some spalsh()'s its gone... :p |
06:57:13 | | Quit GodEater_ ("http://www.mibbit.com ajax IRC Client") |
07:00 |
07:01:05 | | Quit gevaerts (Remote closed the connection) |
07:10:14 | | Quit saratoga ("CGI:IRC (EOF)") |
07:14:36 | | Quit daurnimator (Read error: 60 (Operation timed out)) |
07:14:49 | | Join daurnimator [0] (n=quae@ppp118-208-190-24.lns10.mel4.internode.on.net) |
07:22:11 | | Join rocko [0] (n=rocko@c-67-167-117-152.hsd1.il.comcast.net) |
07:22:21 | | Join einhirn [0] (i=Miranda@bsod.rz.tu-clausthal.de) |
07:27:13 | | Quit _Auron_ ("Infinity repeatedly denies rumours of plotting with zero to bring down the Universe.") |
07:29:48 | | Join _Auron_ [0] (n=DarkAuro@ppp-70-249-146-14.dsl.rcsntx.swbell.net) |
07:41:50 | | Join blkhawk- [0] (n=blkhawk@g229220020.adsl.alicedsl.de) |
07:44:59 | | Nick flx_ is now known as flux (i=flux@jolt.modeemi.cs.tut.fi) |
07:52:48 | | Quit Llorean (Read error: 104 (Connection reset by peer)) |
07:53:30 | | Join Llorean [0] (n=DarkkOne@ppp-70-243-32-116.dsl.hstntx.swbell.net) |
07:54:38 | | Quit blkhawk (Read error: 110 (Connection timed out)) |
07:54:48 | | Nick blkhawk- is now known as blkhawk (n=blkhawk@g229220020.adsl.alicedsl.de) |
07:59:34 | | Quit rocko ("Leaving") |
08:00 |
08:09:06 | | Nick Beaver`away is now known as Beaver`univ (i=balvito@dsl540010D7.pool.t-online.hu) |
08:09:58 | | Join GodEater_ [0] (i=c2cbc962@rockbox/staff/GodEater) |
08:10:51 | | Quit GodEater_ (Client Quit) |
08:11:07 | | Join GodEater_ [0] (i=c2cbc962@rockbox/staff/GodEater) |
08:12:09 | | Join perrikwp [0] (i=18ac0c41@gateway/web/ajax/mibbit.com/x-2abe68b31810b153) |
08:19:57 | | Join Buschel [0] (n=abc@p54A3E6DA.dip.t-dialin.net) |
08:22:40 | | Quit perrikwp ("http://www.mibbit.com ajax IRC Client") |
08:22:40 | | Quit Buschel (Client Quit) |
08:25:03 | | Join ender` [0] (i=krneki@foo.eternallybored.org) |
08:27:13 | | Join perrikwp [0] (i=18ac0c41@gateway/web/ajax/mibbit.com/x-1103324100fdc585) |
08:29:13 | *** | Saving seen data "./dancer.seen" |
08:32:36 | | Join lymeca [0] (n=lymeca@student167-120.hampshire.edu) |
08:40:37 | | Join Rob2223 [0] (n=Miranda@p4FDCD677.dip.t-dialin.net) |
08:43:58 | | Join timc [0] (n=aoeu@124.93.243.83) |
08:54:20 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
08:54:35 | kugel | JdGordon: data abort? |
08:55:02 | kugel | (re: I've got a bug which freezes up my DAP's and with a bit of adding and removing nothing but some spalsh()'s its gone..) |
08:55:21 | | Quit cool_walking_ ("http://www.mibbit.com ajax IRC Client") |
08:58:59 | | Quit Rob2222 (Read error: 110 (Connection timed out)) |
08:59:12 | | Quit gromit` (Read error: 110 (Connection timed out)) |
09:00 |
09:04:12 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
09:04:33 | * | pixelma also guesses that it happens with the e200 |
09:06:08 | | Join miepchen^schlaf [0] (n=miepel@p579ECB8C.dip.t-dialin.net) |
09:06:11 | | Join Zagor [242] (n=bjorn@rockbox/developer/Zagor) |
09:11:32 | | Join petur [50] (n=petur@rockbox/developer/petur) |
09:24:21 | | Quit robin0800 (Read error: 104 (Connection reset by peer)) |
09:25:33 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
09:29:50 | | Quit robin0800 (Client Quit) |
09:30:37 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
09:36:52 | | Quit jordoex (Read error: 110 (Connection timed out)) |
09:38:06 | | Join {-phoenix-} [0] (n=dirk@p54B47B90.dip.t-dialin.net) |
09:42:46 | | Join LinusN [0] (n=linus@rockbox/developer/LinusN) |
09:47:49 | | Quit BHSPitMonkey (Remote closed the connection) |
09:55:22 | | Join Thundercloud [0] (n=thunderc@cpc3-hem18-0-0-cust53.lutn.cable.ntl.com) |
09:55:24 | | Quit kugel ("ChatZilla 0.9.84-rdmsoft [XULRunner 1.9.0.6/2009020911]") |
10:00 |
10:02:03 | | Quit miepchen^schlaf () |
10:02:19 | | Quit kachna|lappy (Read error: 113 (No route to host)) |
10:05:20 | | Join ap0 [0] (i=51fc5204@gateway/web/ajax/mibbit.com/x-51d89b342170ccf4) |
10:05:58 | `Assassin | What possible reasons might there be for song files not showing up in the database but showing up in the file list fine? I have to go out of the normal way of finding these files in the database by going to the <Untagged> section. The files in question have all the ID3 info filled in, but all the database will show is a partial title track name when playing. |
10:06:22 | `Assassin | I reinitialized the whole database to see if this might fix the problem but nothing changed. |
10:12:48 | Zagor | `Assassin: try playing it, then go to "view id3 tags" in the context meny and see how the tags look |
10:15:11 | `Assassin | I don't know where to go to view all the ID3 tags without connecting my iPod to my computer. >_< |
10:16:01 | Zagor | it's in the the wps context menu. I don't remember the key for ipod, try holding select for a few seconds when in the wps. |
10:16:02 | `Assassin | I know at the very least the track title ID3 tag is messed up in almost all these files. |
10:16:45 | Zagor | `Assassin: well then it's not surprising that the database gets confused |
10:16:45 | `Assassin | But it's of course not messed up when I right click the file to go to properties while it's connected to my computer. |
10:17:31 | | Quit kadoban (Remote closed the connection) |
10:18:12 | `Assassin | That makes the problem mysterious to me. It's like the database just decided it didn't want to bother with these particular songs for no reason. |
10:18:28 | | Join msou| [0] (i=msoul@meridian.sosdg.org) |
10:18:55 | Zagor | not "no reason". you said yourself the tags are not read correctly. that is the reason. |
10:19:38 | `Assassin | Well yeah. So any idea why they aren't being read correctly? |
10:21:25 | BigBambi | What format are the tags, and what format are the music files? |
10:21:45 | BigBambi | Some encoders put the wrong format tags on for the type of music file |
10:21:59 | BigBambi | e.g. ape tags on MP3 |
10:22:45 | `Assassin | I probably tagged them with iTunes. I'll check on the format... |
10:23:06 | BigBambi | iTunes doesn't always change the actual tags as well, it uses its own database |
10:23:32 | BigBambi | So you really need to check with a different program that reads only the actual tags, and not a database |
10:24:03 | | Join NanoBoy [0] (n=55e65f04@gateway/web/cgi-irc/labb.contactor.se/x-a6daf5f5856abc3c) |
10:25:51 | | Quit NanoBoy (Client Quit) |
10:27:31 | `Assassin | Okay, one of the files in question was encoded with LAME3.90. It's an mp3 and it's ID3 tag version is 2.3. |
10:29:17 | *** | Saving seen data "./dancer.seen" |
10:35:25 | | Quit Thundercloud (Remote closed the connection) |
10:35:44 | | Join pyro_maniac [0] (i=foobar@p57BBB1F5.dip0.t-ipconnect.de) |
10:37:15 | | Quit ap0 ("http://www.mibbit.com ajax IRC Client") |
10:46:39 | | Join kadoban [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) |
10:47:38 | | Join kachna|lappy [0] (n=kachna@r3g248.net.upc.cz) |
10:54:20 | | Join miepchen^schlaf [0] (n=miepel@p579ECB8C.dip.t-dialin.net) |
10:56:56 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
10:58:37 | | Quit {-phoenix-} (Remote closed the connection) |
10:59:18 | JdGordon | kugel: if it was a data abort at leats i would know where to start debugging :/ |
10:59:29 | JdGordon | i tihnk its a freeze/infinite loop more than a crash |
11:00 |
11:01:28 | | Join blkhawk- [0] (n=blkhawk@g228017022.adsl.alicedsl.de) |
11:09:26 | | Quit einhirn (Read error: 54 (Connection reset by peer)) |
11:11:39 | | Quit nuonguy ("This computer has gone to sleep") |
11:14:36 | | Join CaptainSquid [0] (n=Miranda@dslb-084-056-035-074.pools.arcor-ip.net) |
11:15:26 | | Quit blkhawk (Read error: 110 (Connection timed out)) |
11:16:26 | | Nick blkhawk- is now known as blkhawk (n=blkhawk@g228017022.adsl.alicedsl.de) |
11:17:30 | | Join ap0 [0] (i=51fc5204@gateway/web/ajax/mibbit.com/x-c8de81792613bfe3) |
11:24:49 | | Quit robin0800 (Read error: 104 (Connection reset by peer)) |
11:29:28 | | Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) |
11:31:58 | | Join gromit` [0] (n=gromit@ALagny-154-1-44-70.w83-200.abo.wanadoo.fr) |
11:32:01 | | Quit blkhawk (Remote closed the connection) |
11:32:04 | | Quit rakslice (Read error: 104 (Connection reset by peer)) |
11:32:13 | | Quit Rob2223 (Read error: 104 (Connection reset by peer)) |
11:32:17 | | Join rakslice [0] (n=rak@S010602055dee5503.ok.shawcable.net) |
11:32:17 | | Join Rob2222 [0] (n=Miranda@p4FDCD677.dip.t-dialin.net) |
11:32:22 | | Join blkhawk [0] (n=blkhawk@g228017022.adsl.alicedsl.de) |
11:43:11 | pixelma | JdGordon: reproducable by playing a certain directory? And does it happen with backlight off so you can't watch a possible error displayed on the screen and which DAP? |
11:43:19 | | Quit z35 ("Leaving") |
11:43:47 | pixelma | reproducible even |
11:44:01 | JdGordon | i dont know about it being only certain directories, and its with the backlight on |
11:44:13 | * | JdGordon assumed it was his patch... |
11:44:26 | JdGordon | I havnt reviously had problems with the folder im using to test |
11:44:29 | pixelma | ok, probably something else than what I suspected |
11:44:41 | pixelma | (guess kugel too) |
11:45:22 | kugel | yep ;) |
11:45:30 | | Quit kugel (Remote closed the connection) |
11:46:03 | JdGordon | yeah, na its definetly my patch which is causing it... not your bug |
11:46:23 | | Quit `Assassin (Read error: 54 (Connection reset by peer)) |
11:51:07 | | Join blkhawk- [0] (n=blkhawk@e179089217.adsl.alicedsl.de) |
11:51:23 | | Quit msou| ("Bbl.") |
12:00 |
12:05:00 | | Quit blkhawk (Read error: 113 (No route to host)) |
12:05:05 | | Nick blkhawk- is now known as blkhawk (n=blkhawk@e179089217.adsl.alicedsl.de) |
12:07:27 | | Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) |
12:14:13 | | Join blkhawk- [0] (n=blkhawk@f051117143.adsl.alicedsl.de) |
12:14:35 | | Join webguest74 [0] (n=1813fbae@gateway/web/cgi-irc/labb.contactor.se/x-8f7b5570e3f49de6) |
12:21:34 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
12:24:39 | | Quit webguest74 ("CGI:IRC (EOF)") |
12:24:48 | | Join ThoDin [0] (n=1813fbae@gateway/web/cgi-irc/labb.contactor.se/x-55f4bbccb7bfe9f3) |
12:27:08 | | Join __lifeless [0] (n=lifeless@90.151.213.220) |
12:27:42 | | Quit blkhawk (Read error: 110 (Connection timed out)) |
12:28:11 | | Nick blkhawk- is now known as blkhawk (n=blkhawk@f051117143.adsl.alicedsl.de) |
12:28:39 | | Quit kugel (Remote closed the connection) |
12:28:54 | | Join moos [0] (i=Mustapha@rockbox/staff/moos) |
12:29:19 | *** | Saving seen data "./dancer.seen" |
12:29:38 | ThoDin | Got a "vid pid" issue with a 4th gen color ipod, ipodpatch looking for 0x05ac 0x1203 but have 0x05ac 0x1263 in XP home. the question is would I be beter off at my debian box(not convinient) or is there a workaround for the vid-pid's in XP home sp3? |
12:30:21 | ThoDin | thodyn@gmail.com |
12:30:34 | | Quit linuxstb (Remote closed the connection) |
12:30:59 | gevaerts | ThoDin: that may be a bug in ipodpatcher I guess. Can you submit a bug report? |
12:32:01 | ThoDin | probably should, just registered with th wiki page that lists th id's so cant author yet |
12:32:50 | ThoDin | i mis mt *nix (sob) |
12:33:17 | scorche | ...huh? |
12:33:53 | ThoDin | i miss my unix (cant type, 3 am) |
12:35:13 | domonoky | ipodpatcher doesnt look for vid/pid. |
12:35:25 | domonoky | it detectes the drive by the content. |
12:35:40 | ThoDin | really? |
12:36:52 | domonoky | yes. rbutil might uses the vid/pids, but not ipodpatcher itself. |
12:38:03 | ThoDin | maybe i Have over looked somethin then, but i read this url and thought different ; http://www.rockbox.org/twiki/bin/view/Main/DeviceDetection#Finding_USB_IDs |
12:38:04 | domonoky | and a pid of 1263 sounds very new, ipod classic has 1261, and nano 3th gen has 1262, is it really a ipod color ? |
12:38:25 | ThoDin | i'll keep reading, thanks |
12:39:36 | domonoky | this wiki page, doesnt say what method ipodpatcher uses, we collect those ids, to help rbutil detect the device. |
12:39:58 | | Join gnuppla [0] (i=Citizen@p508D7FD4.dip.t-dialin.net) |
12:39:58 | | Quit ThoDin ("CGI:IRC (EOF)") |
12:40:41 | | Join ThoDin [0] (n=1813fbae@gateway/web/cgi-irc/labb.contactor.se/x-9708eefeea2e5998) |
12:40:56 | | Nick ThoDin is now known as thodyn (n=1813fbae@gateway/web/cgi-irc/labb.contactor.se/x-9708eefeea2e5998) |
12:41:45 | thodyn | sorry, got kicked by cheap hardware |
12:42:43 | domonoky | thodyn: so what is the real issue ? does ipodpatcher detect your ipod ? |
12:42:49 | | Quit _lifeless (Read error: 110 (Connection timed out)) |
12:42:55 | thodyn | yes, it's shaped like an aeroplane wing looking at either end and it's fusia in color ( i think ) |
12:43:08 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
12:43:30 | thodyn | no ipod detected by ipodpatcher or rbutil |
12:44:02 | thodyn | itunes got it of course, although i have disabled it now |
12:44:44 | thodyn | got it in emergency mode just fine |
12:44:50 | advcomp2019 | that is the 4th gen nano for what you said |
12:45:00 | domonoky | maybe take a look here http://support.apple.com/kb/HT1353 to see if you really have a ipod color |
12:45:22 | | Quit ap0 ("http://www.mibbit.com ajax IRC Client") |
12:45:54 | thodyn | for sure, 8 gig version |
12:46:33 | BigBambi | There is no 8GB ipod color |
12:46:45 | domonoky | if it is a new nano, its not supported. |
12:46:51 | BigBambi | That is some form of ipod nano, I'd guess 4th gen |
12:46:52 | thodyn | identical to the pink one |
12:47:07 | BigBambi | It is not an ipod color, and it is not supported |
12:47:24 | domonoky | and 4th gen nano, would make sense with this usb pid. (one higher the 3th gen Nano) |
12:47:48 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
12:48:12 | thodyn | sorry did I say it was a color, my bad, it's a 4gen |
12:48:28 | BigBambi | thodyn: Have a look at www.rockbox.org |
12:48:55 | thodyn | got it on my sansa e250 |
12:48:59 | BigBambi | thodyn: It is a 4th gen *nano* - the nano bit is important - and as www.rockbox.org states is not supported |
12:49:07 | thodyn | works great! |
12:50:06 | BigBambi | yes, my point in saying look at www.rockbox.org was that the front page of www.rockbox.org very clearly states that the 4th gen Nano does not work |
12:50:20 | thodyn | you know I read that too, but they seem to go on as if it works, and Im a bleeding edge kinda guy |
12:50:36 | BigBambi | Where does it suggest it works? |
12:51:22 | thodyn | thats good to know, feel like a shot glass of a mind just read a beer mug of info (spilled some) |
12:51:37 | BigBambi | "It runs on a wide range of players: (...) not the 2nd/3rd/4th gen Nano" seems pretty unambiguous to me |
12:51:54 | thodyn | thanks alot guys, apreciate your patience |
12:52:48 | thodyn | maybe i was confusing the issue some how, no woories i'll read for a while more\ |
12:52:49 | BigBambi | no problem |
12:53:14 | BigBambi | If you can find anywhere that suggests the 4th gen nano works please tell us and we will change it |
12:53:21 | BigBambi | But I don't think there is anywhere |
12:53:34 | thodyn | u got it :) |
12:55:27 | thodyn | later (tommorow maybe) Ive got an interstingly "refurbished" third gen I'd like an opinion on. Take it easy . |
12:55:34 | | Quit thodyn ("CGI:IRC") |
12:58:34 | BigBambi | If he means third gen nano I'm going to smack him with the frontpage :) |
12:59:11 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
13:00 |
13:00:11 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
13:01:32 | | Quit gnuppla ("...dignity and pain for all your beloved...") |
13:11:40 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
13:14:40 | | Join linuxstb [0] (n=linuxstb@rockbox/developer/linuxstb) |
13:16:49 | | Quit bmbl (Read error: 110 (Connection timed out)) |
13:19:17 | | Quit kugel (Remote closed the connection) |
13:27:05 | | Quit Seed (Read error: 110 (Connection timed out)) |
13:31:58 | | Join kugel [0] (n=kugel@141.45.204.109) |
13:34:06 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
13:38:22 | | Join {-phoenix-} [0] (n=dirk@p54B47B90.dip.t-dialin.net) |
13:39:15 | | Quit faemir (Connection timed out) |
13:47:21 | | Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) |
13:52:58 | | Quit kugel (Remote closed the connection) |
13:53:14 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
13:57:14 | | Quit robin0800 (Read error: 104 (Connection reset by peer)) |
13:57:17 | | Join robin0800_ [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
14:00 |
14:00:06 | | Quit FOAD (Read error: 110 (Connection timed out)) |
14:01:14 | | Part LinusN |
14:06:06 | | Quit kugel (Remote closed the connection) |
14:06:33 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
14:07:07 | | Quit kugel (Remote closed the connection) |
14:07:56 | | Join piotrek2234 [0] (n=piotrek2@chello084010133138.chello.pl) |
14:08:49 | | Quit robin0800_ (Remote closed the connection) |
14:11:29 | | Quit Seed (Nick collision from services.) |
14:11:34 | | Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) |
14:16:21 | | Quit daurnimator (Read error: 60 (Operation timed out)) |
14:17:58 | | Part piotrek2234 |
14:18:10 | | Quit Seed (Nick collision from services.) |
14:18:15 | | Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) |
14:20:11 | | Join piotrek2234 [0] (n=piotrek2@chello084010133138.chello.pl) |
14:24:25 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
14:28:12 | | Join daurnimator [0] (n=quae@ppp121-44-216-55.lns10.mel4.internode.on.net) |
14:29:21 | *** | Saving seen data "./dancer.seen" |
14:30:34 | | Quit Seed (Nick collision from services.) |
14:30:38 | | Join Seedy [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) |
14:35:51 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
14:35:54 | | Join Sedgewick [0] (n=Sedgewic@81.200.132.126) |
14:37:25 | | Quit Seedy (Read error: 104 (Connection reset by peer)) |
14:44:28 | | Join Seed [0] (n=ben@bzq-84-108-232-45.cablep.bezeqint.net) |
14:45:52 | | Nick JdGordon is now known as JdGordon|zzz (n=jonno@rockbox/developer/JdGordon) |
14:46:29 | | Quit robin0800 (Read error: 104 (Connection reset by peer)) |
14:47:38 | | Quit kugel (Remote closed the connection) |
14:47:51 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
14:48:49 | | Quit robin0800 (Read error: 104 (Connection reset by peer)) |
14:49:44 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
15:00 |
15:05:37 | | Quit bmbl ("Woah!") |
15:13:25 | | Join xxYO [0] (n=d4f4ad7d@gateway/web/cgi-irc/labb.contactor.se/x-ab996dee85046910) |
15:14:19 | | Quit xxYO (Client Quit) |
15:14:37 | | Join mrkiko [0] (n=mrkiko@host49-50-dynamic.0-87-r.retail.telecomitalia.it) |
15:15:37 | | Part piotrek2234 |
15:15:42 | | Join gregzx [0] (n=chatzill@dtm206.neoplus.adsl.tpnet.pl) |
15:29:01 | | Join Rob2223 [0] (n=Miranda@p4FDCCC10.dip.t-dialin.net) |
15:29:35 | | Join Acksaw [0] (n=omgwtfbb@cpc1-stok5-0-0-cust655.bagu.cable.ntl.com) |
15:32:43 | | Quit Acky (Read error: 60 (Operation timed out)) |
15:47:15 | | Quit Rob2222 (Read error: 110 (Connection timed out)) |
15:47:38 | | Quit kachna|lappy (Read error: 110 (Connection timed out)) |
15:55:00 | | Join jaykay [0] (n=chatzill@p579E6C9A.dip.t-dialin.net) |
15:56:22 | | Join CaptainKewl [0] (i=jds@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) |
15:57:48 | | Nick Barahir_ is now known as Barahir (n=jonathan@Ya417.y.pppool.de) |
15:59:51 | | Join midijunkie [0] (n=Miranda@pD9547A7B.dip0.t-ipconnect.de) |
16:00 |
16:01:52 | | Join Zoxc [0] (i=Zoxc@ti0128a340-dhcp0017.bb.online.no) |
16:04:42 | | Join Aurix_Lexico [0] (n=comrade@c-68-56-205-239.hsd1.fl.comcast.net) |
16:07:36 | | Join LambdaCalculus37 [0] (n=rmenes@c-68-83-177-181.hsd1.nj.comcast.net) |
16:09:54 | | Join Chris_Black [0] (n=Sedgewic@81.200.132.126) |
16:25:36 | | Quit Sedgewick (Read error: 110 (Connection timed out)) |
16:26:21 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
16:28:59 | | Quit jaykay (Read error: 110 (Connection timed out)) |
16:29:25 | *** | Saving seen data "./dancer.seen" |
16:32:35 | | Join gartral1 [0] (n=Gartral@75.33.69.103) |
16:33:04 | gartral1 | the Ipod FAQ page has some horribly outdated information |
16:34:31 | LambdaCalculus37 | gatrall: What needs to be fixed up? |
16:36:36 | kadoban | it says the Rockbox Utility is experimental... |
16:36:50 | kadoban | there was a broken link i just fixed up a few minutes ago |
16:37:38 | gartral1 | at the bottom of functionality questions, it sais that rockbox does not support any accessory... |
16:38:13 | gartral1 | for Ipods, obviously |
16:38:43 | LambdaCalculus37 | I'll fix that up, since we have accessory support, but not every accessory has been tested. |
16:40:07 | gartral1 | yea, but i figured saying "some work" is better than the misleading "none work" |
16:44:22 | LambdaCalculus37 | Fixed. |
16:44:55 | gartral1 | and this isnt really a bug, as it is just plain funny, if you go into the plugins>applications menu and select lamp with long press and go too its properties, rb reports it has a play length of 8:32 |
16:45:49 | * | linuxstb wonders about the answer to "My iPod doesn't show up as a USB drive in Windows Explorer, why not?" |
16:46:23 | gartral1 | i was wondering about that too, but its kinda funny |
16:47:40 | kadoban | it's pretty unprofessional, and probably pretty confusing or anyone who would actually be asking that question... |
16:48:12 | kadoban | i thought i remember reading a section like that somewhere else that was nice..i wonder if it's in the manual |
16:49:09 | | Join fyrestorm [0] (n=fyre@cpe-24-90-81-53.nyc.res.rr.com) |
16:49:45 | gartral1 | is there way to "force" i file too be played in rockbox as a different file type? |
16:49:52 | gartral1 | a file* |
16:50:01 | | Join Nico_P [50] (n=nicolas@rockbox/developer/NicoP) |
16:50:13 | kadoban | gartral1: in the context menu with 'Open With...'? |
16:52:12 | gartral1 | kadoban: i said play, as in take an MP3 and play it as another type of file, say, a WMA or WAV |
16:53:12 | | Join toffe82 [0] (n=chatzill@h-74-0-180-178.snvacaid.covad.net) |
16:53:32 | | Quit miepchen^schlaf () |
16:54:49 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
16:57:44 | | Join nuonguy [0] (n=john@c-24-6-174-132.hsd1.ca.comcast.net) |
16:59:09 | | Join webguest67 [0] (n=ad167099@gateway/web/cgi-irc/labb.contactor.se/x-67677cf420a0e9a3) |
17:00 |
17:00:29 | webguest67 | Hey I really want to upload a theme I made for the sansa c200 as there are not very many of them but I need write permission. Any help there? |
17:01:03 | domonoky | webguest67: what is your wikiname ? |
17:02:17 | | Quit obo (Remote closed the connection) |
17:04:07 | | Join CaptainKwel [0] (n=jds@207-237-172-77.c3-0.nyr-ubr4.nyr.ny.cable.rcn.com) |
17:05:16 | | Quit Zagor ("Client exiting") |
17:09:36 | | Join obo [0] (n=obo@77-99-230-49.cable.ubr04.trow.blueyonder.co.uk) |
17:11:51 | | Quit lymeca (Connection timed out) |
17:14:35 | | Quit webguest67 ("CGI:IRC (Ping timeout)") |
17:15:03 | | Quit CaptainKewl (Read error: 110 (Connection timed out)) |
17:16:03 | | Join saratoga [0] (n=9803c6dd@gateway/web/cgi-irc/labb.contactor.se/x-0c6cc9cf54074bf7) |
17:16:05 | | Quit Chris_Black ("off") |
17:17:06 | saratoga | does anyone know Aoyumi's [the vorbis developer] full name? |
17:17:14 | saratoga | i want to commit his patches |
17:19:22 | moos | ask him in a patch comment? |
17:21:18 | kugel | saratoga: I can only find Aoyumi using google, seems he hides his last name |
17:23:39 | | Join avis [0] (n=ident@pdpc/supporter/student/avis) |
17:24:15 | avis | can anyone recommend a nice rockbox compatible player, that has a very good long battery life ? (and hopefully doesn't cost an arm and leg) |
17:25:10 | rob_ | no |
17:25:12 | moos | avis: check this out first: http://www.rockbox.org/twiki/bin/view/Main/BuyersGuide |
17:25:16 | SoapWork | what do you consider long life? |
17:25:29 | avis | i consider 24 hours long life |
17:26:20 | * | domonoky is playing again with the e200v2 button driver, and its really funny that a red backdrop makes the scrollwheel work :-) |
17:26:37 | kugel | domonoky: not funny at all, imo |
17:26:50 | SoapWork | Ipod Video 60/80GB with MP3/MPC _should_ be able to acheive that if/when the BCM disable code becomes part of SVN. |
17:27:03 | moos | domonoky: hehe :) |
17:27:44 | rob_ | SoapWork: whats BCM disable code? |
17:27:45 | SoapWork | and they are cheap on Craigslist / eBay. Else you're looking towards a more expensive option - Like an Iriver Hxxx or Iaudio X/M |
17:27:47 | rob_ | backlight? |
17:27:59 | SoapWork | not just the backlight, the entire LCD controller. |
17:28:10 | SoapWork | massive power consumption decrease. |
17:28:15 | rob_ | hmm :> |
17:28:31 | kugel | and massive is not even exaggerated |
17:28:58 | avis | ooh ok |
17:29:08 | kugel | though you can go 22+h with the sansa e200 too, and we also have found some ways to increase that |
17:29:09 | rob_ | i bought a second hand ipod video the other day for 75GBP |
17:29:11 | avis | i'll look for something cheap :) |
17:29:19 | rob_ | 60gb model |
17:29:33 | gartral1 | as of right now, the e200s have about 20-25 hours |
17:29:35 | SoapWork | Of course there is nothing on the screen when the backlight is off, and this is different than stock behavior (for iPods) but not different than many other players with their not transflective screens. |
17:29:37 | rob_ | though oddly on the BuyersGuide page theres no mention of it... |
17:29:44 | moos | avis: sansas seems to are the way to go for you |
17:30:28 | * | gartral1 loves his e200 |
17:30:29 | avis | i can live with 14-17 hours |
17:30:33 | SoapWork | yes, the 60/80GB models have more RAM and larger batteries than their 30GB counterparts, as well as dual-platter HDDs. |
17:31:00 | rob_ | SoapWork: so the 60gb is effectively the same as the 80gb (rather than 30gb)? |
17:31:08 | SoapWork | If you can live with 14-17, then a sansa E2x0 is a very inexpensive option. |
17:31:24 | rob_ | do sansa do any high-capacity models? |
17:31:32 | SoapWork | rob_, for sake of this discussion, yes. |
17:31:52 | rob_ | i mean in general, such as 30gb+ |
17:31:55 | gartral1 | SoapWork: i get 20+ on my sansa, what are you trying to play? |
17:32:07 | rob_ | i saw a sansa the other day and it looked really nice (i like that it has external memory slot too) |
17:32:25 | gartral1 | rob_: unfortuently, no, but they do have micro SD ports |
17:32:32 | SoapWork | gartral1, I do not follow your question. |
17:33:12 | gartral1 | SoapWork: i get 20 + hours playtime on my sansa, why is your batt life so much shorter? |
17:34:13 | gartral1 | rob_: the highes internal storage sansa is the e280 (8 gb internal) but good luck finding a V1... |
17:34:31 | rob_ | whats a V1? |
17:34:44 | SoapWork | I don't recall saying it was - I directly responded to his (avis') mentioning of 14-17. |
17:34:59 | avis | what model number is the sansa e2x0 ? |
17:35:08 | SoapWork | rob_, there are two totally different sets of hardware both having been sold as Sandisk Sansa E2x0s |
17:35:12 | kadoban | rob_: there are two versions of the e200 series, versions 1 and 2. only version 1 is currently supported |
17:35:33 | avis | so its a hit or miss thing ? no guarantees unless stated what revision ? |
17:35:34 | rob_ | ah |
17:35:37 | gartral1 | the V1 sansas are older, and have different hardware than their v2 counterparts, currently, rockbox only works on the V1s |
17:35:49 | LambdaCalculus37 | You can tell one from another by the firmware revision. |
17:35:56 | SoapWork | The first version of the hardware (V1) uses hardware very much like iPods and is fully supported by Rockbox. The second revision of the hardware (the AMS versions) is in developement. |
17:36:04 | LambdaCalculus37 | 01.XX.XX means it's a v1, and 03.XX.XX means it's a v2. |
17:36:19 | gartral1 | avis: E2x0 is a placeholder for e250 e260 e270 e280 |
17:36:23 | avis | ooh thank you LambdaCalculus37 thats wonderful information |
17:36:47 | gartral1 | avis: all of which are the same DAP with different sized drives |
17:36:54 | avis | ooh ok. |
17:37:59 | LambdaCalculus37 | There are also some e200 models that are known as "Rhapsody" models. They're largely the same, but have a slightly different original firmware, and thus a slightly different install method for Rockbox. |
17:38:06 | LambdaCalculus37 | Those would have an "R" in their model name. |
17:38:17 | LambdaCalculus37 | e.g. 250R, etc. |
17:38:25 | gartral1 | there also somewhat rare outside of the US |
17:38:42 | gartral1 | from what i hear >.> |
17:38:55 | LambdaCalculus37 | Yeah, it was mostly sold in Best Buy stores to be used as part of their Rhapsody music service. |
17:39:10 | | Quit thegeek (Read error: 104 (Connection reset by peer)) |
17:39:12 | gartral1 | which was bought by Real Inc |
17:39:16 | LambdaCalculus37 | But I digress... |
17:39:27 | | Join Rich^ [0] (n=rich@81.94.235.186) |
17:40:29 | | Join thegeek [0] (n=nnscript@s243b.studby.ntnu.no) |
17:40:58 | avis | the e270 looks alright to me. if i heard you correct LambdaCalculus37, the 1.xxx series original firmware is what i need in that model ? |
17:41:26 | LambdaCalculus37 | You need a 01.XX.XX firmware, yes. |
17:41:42 | avis | thank you :) save me alot of heartache knowing that info |
17:41:58 | gartral1 | so whats the extra letter by the processor name in hardware info for? |
17:42:06 | | Quit Richlv (No route to host) |
17:42:37 | domonoky | hm, e200v2 button driver also works fine if i just write out one red pixel before reading the dbop. maybe we can place this pixel out of the visible range ? |
17:42:40 | gartral1 | avis: yea, but its still somewhat hit/miss with buying used/refurbished ones, and dont buy a new one |
17:42:56 | avis | even with 01.xx.xx firmware gartral1 ? |
17:43:28 | gartral1 | no, but you have too be holding the DAP in your hands to figure out which firmware version it is |
17:43:29 | | Quit chrippa (Read error: 110 (Connection timed out)) |
17:43:30 | kadoban | avis: if you can get the answer to that question it's always correct i believe, but often it's not a choice |
17:43:43 | LambdaCalculus37 | If you buy on eBay, you can always ask the seller to check for you. |
17:44:04 | avis | thats what i'm doing |
17:44:19 | * | gartral1 got his refurbished, thankfuly it was a v1 |
17:44:47 | avis | i had a cowon iaudio 7 16gb, but it stopped working on me, and i can't find my paypal receipt. there is no way to search transactions by string i dont think either :( for warranty |
17:45:38 | | Join webguest06 [0] (n=ad167099@gateway/web/cgi-irc/labb.contactor.se/x-c4b90581c8e46f60) |
17:45:45 | gartral1 | avis: bummer, but also off topic, take that kinda stuff too #rockbox-community |
17:45:53 | avis | sorry |
17:46:46 | domonoky | ha, e200v2 button driver works fine, if i write the red pixel to LCD_WIDTH/HEIGHT+1 (out of the visible area) so thats a solution to our button problem :-) |
17:46:49 | gartral1 | np, its just this is a technical channel, and we dont like the logs "cluttered" so to speak |
17:47:44 | kugel | domonoky: I already tried that ;) |
17:48:03 | kugel | oh, not that. how did you do? |
17:48:07 | moos | domonoky: wee \o/ |
17:48:35 | | Quit krazykit (Read error: 104 (Connection reset by peer)) |
17:49:05 | kugel | I was having problems with lcd_window_x/y (in order to tell the driver where to draw), changing that messes normal usage up (at least what I tried) |
17:49:20 | | Quit webguest06 (Client Quit) |
17:49:28 | | Join krazykit [0] (n=kkit@adsl-76-251-249-28.dsl.ipltin.sbcglobal.net) |
17:49:29 | gartral1 | so wait, e200 v2 buttons work? |
17:49:32 | | Join webguest78 [0] (n=ad167099@gateway/web/cgi-irc/labb.contactor.se/x-f4b9373dda93f286) |
17:50:09 | domonoky | kugel: dbop reading function: http://pastebin.com/m42c84812 and dummy lcd_update function: http://pastebin.com/m1236f9bf |
17:50:20 | domonoky | gartral1: we are working on it.. |
17:51:14 | kugel | domonoky: and that doesn't cause problems? |
17:52:03 | | Quit webguest78 (Client Quit) |
17:52:09 | | Join webguest95 [0] (n=ad167099@gateway/web/cgi-irc/labb.contactor.se/x-9f9c9307a64b4008) |
17:52:09 | | Quit webguest95 (Client Quit) |
17:52:09 | kugel | the dbop reading is in an interrupt, and may be during an lcd update (and you're changing the addresses), that's surely problematic isn't it? It was here |
17:52:14 | | Quit petur ("*plop*") |
17:52:14 | kugel | since I was trying similar things |
17:52:22 | domonoky | seems to work fine |
17:53:22 | | Join webguest64 [0] (n=ad167099@gateway/web/cgi-irc/labb.contactor.se/x-a2dd54907b8e3cda) |
17:53:24 | | Quit webguest64 (Client Quit) |
17:53:33 | | Join webguest36 [0] (n=ad167099@gateway/web/cgi-irc/labb.contactor.se/x-046f7dace784b8a5) |
17:53:41 | kugel | well, I need to try that then :> |
17:53:52 | domonoky | i also print out the dbop values in the button ticktask, and it doesnt cause any problems. |
17:54:25 | kugel | which dbop values? |
17:55:05 | kugel | and where do you print? |
17:55:37 | domonoky | just dbop_din, so i know it works. and i do it just after i called read_dbop() |
17:56:50 | | Quit webguest36 (Client Quit) |
17:56:54 | | Join webguest36 [0] (n=ad167099@gateway/web/cgi-irc/labb.contactor.se/x-05e2d1fa9cf478ab) |
17:57:01 | webguest36 | Sorry if I already said something like this but I got diconnected and can't find where I was before. I am trying to upload my own theme for the sansa c200 since there are so little but I need write permission. My rockbox name is creativesansa333. I am Quinlan Moll on twiki. |
17:58:49 | kugel | domonoky: well, it might work, but it may not be correct |
17:58:55 | domonoky | webguest36: done, promise not to spam ! |
17:59:14 | kugel | it's rather "undefined" what DBOP_DIN is without the read data valid bit set |
17:59:32 | kugel | you should rather print the return value |
17:59:34 | domonoky | kugel: ? |
17:59:48 | kugel | according to the datasheet |
17:59:49 | domonoky | of course i do print the return value |
17:59:58 | * | SoapWork didn't get his check yet. |
18:00 |
18:00:03 | kugel | and why should that cause problems?? |
18:00:03 | | Quit Rich^ (No route to host) |
18:00:07 | domonoky | but it contains the dbop_din value, as i have just read it.. |
18:00:15 | kugel | I thought you were saying you print dbop_din |
18:00:22 | domonoky | as i do a lcd_update in the ticktask ? |
18:00:25 | kugel | as in DBOP_DIN |
18:00:46 | domonoky | which is the same "problem" as doing a one pixel write before the read.. |
18:00:50 | kugel | I'm still unsure how this would cause problems |
18:01:38 | kugel | you just copied DBOP_DIN, it's not the same space. and DBOP_DIN is valid when you copy it to ret |
18:02:03 | kugel | ret and DBOP_DON are not in the same space in the memory, I mean |
18:02:06 | kugel | DIN* |
18:02:56 | kugel | domonoky: btw, you could also use the debug menu.. |
18:03:00 | domonoky | kugel: stop it, i know how to code, and i am reading and printing the value correctly. (ie not just DBOP_DIN, but the return value i get from my function,) |
18:03:07 | | Join flydutch [0] (n=flydutch@host210-153-dynamic.15-87-r.retail.telecomitalia.it) |
18:03:35 | domonoky | the only "problem" could be if the ticktask interrupts a lcd_transfer and we change the update window |
18:04:28 | kugel | domonoky: yes, and that's just fine. So why should it cause problems to print that (maybe I just got "i also print out the dbop values in the button ticktask, and it doesnt cause any problems." wrong) |
18:04:57 | webguest36 | Thanks |
18:04:58 | kugel | yes, that's the problem I am expecting (as I already said) |
18:05:02 | domonoky | kugel: its one more lcd_update in the ticktask, which also changes the update window |
18:05:43 | kugel | ah ok, sorry for the missunderstanding then |
18:06:02 | kugel | and, I know, that you know how to code :) |
18:09:04 | | Join dan_ [0] (n=dan@dynamic-oit-lifenet-a-1.Princeton.EDU) |
18:10:50 | | Quit webguest36 ("CGI:IRC (EOF)") |
18:12:30 | dan_ | Selecting a .m3u text file causes rockbox to play the music files listed there. So they're a bit like a symlink. How hard would it be to add the ability to list either (a) directories or (b) other .m3u files in an m3u file? In the case of (a) rockbox would visit the directory and (b) would start playing the m3u file. |
18:13:25 | | Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) |
18:13:48 | linuxstb | dan_: Why are you asking "how hard"? That's something you want to work on? |
18:15:59 | dan_ | Potentially, unless rockbox developers advise that it would be very difficult. |
18:16:34 | | Join chrippa [0] (n=chrippa@evangelion.se) |
18:19:10 | | Part toffe82 |
18:19:37 | | Join lymeca [0] (n=lymeca@student164-74.hampshire.edu) |
18:19:55 | | Join jaykay [0] (n=chatzill@p579E6C9A.dip.t-dialin.net) |
18:20:30 | linuxstb | dan_: I don't know that code at all, but if I was you I would just download the source, look at it, and ask questions here. |
18:20:47 | | Join toffe82 [0] (n=chatzill@h-74-0-180-178.snvacaid.covad.net) |
18:23:29 | dan_ | OK will do. I just wanted to check that there wasn't something obviously stupid about the idea. |
18:26:52 | SoapWork | I think maintaining compatibility with other users of .m3u files would be quite important. Perhaps there is already an extension in the standard to do this, or at worst drop the other features into comment fields? |
18:27:20 | | Join hillshum [0] (n=hillshum@75-165-240-206.slkc.qwest.net) |
18:28:45 | | Join wemdowemd [0] (n=chatzill@cpc3-brig10-0-0-cust234.brig.cable.ntl.com) |
18:29:24 | wemdowemd | In Vista, when plugging in & switching on my 'boxed H10, I get "Windows needs to install drivers for |
18:29:26 | *** | Saving seen data "./dancer.seen" |
18:29:43 | wemdowemd | "Windows needs to install driver software for your rockbox media player" |
18:30:03 | wemdowemd | Where can I find these drivers? |
18:30:17 | hillshum | the Rockbox USB stack is incomplete |
18:30:25 | SoapWork | Dismiss the message. |
18:31:28 | hillshum | It will only charge |
18:31:50 | hillshum | Use the OF to sync |
18:32:52 | wemdowemd | By OF you mean 'UMD mode', as in mount it like a normal HDD? |
18:33:21 | hillshum | Original Firmware |
18:33:49 | wemdowemd | Oh I see. Well it is easier just to mount it in hard drive mode anyway |
18:33:50 | wemdowemd | Thanks |
18:33:50 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
18:35:09 | wemdowemd | Out of interest, are there any intentions to get Rockbox to work like that, mounting like an MTP device? |
18:35:20 | | Join FOAD [0] (n=dok@dinah.blub.net) |
18:35:29 | BigBambi | yes |
18:35:49 | wemdowemd | Huh. Well I'll look forward to it |
18:35:56 | | Quit wemdowemd ("ChatZilla 0.9.84 [Firefox 3.0.6/2009011913]") |
18:36:03 | BigBambi | Rockbox has a USB stack, it just isn't enabled by default because there are some remaining issues |
18:36:32 | BigBambi | er sorry, not MTP |
18:36:41 | BigBambi | MSC/UMS |
18:36:45 | bertrik | ...gone already |
18:37:44 | hillshum | how do I undo rockboxdev.sh? |
18:42:05 | | Join idshark [0] (i=chainsaw@i.will.tell.u.some.hotstories.de) |
18:42:24 | bertrik | is anyone currently working on the ams sansa storage >1 GB problem? |
18:44:31 | | Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) |
18:44:36 | | Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
18:45:04 | | Join mrkiko_ [0] (n=mrkiko@host149-43-dynamic.56-82-r.retail.telecomitalia.it) |
18:45:33 | kugel | domonoky: doesn't work for me |
18:46:16 | domonoky | kugel: if you disable interrupts while doing the lcd_updates, it works fine. |
18:47:00 | kugel | the normal ones? Will try |
18:48:00 | domonoky | lcd_update and lcd_update_rect needs to be protected, so we dont mess up the lcd-configuration.. we need a better solution for this. |
18:50:08 | domonoky | maybe we should get the ticktask out of interrupt context for ams-sansas. How is the ticktask implemented on other targets ? |
18:50:27 | | Part pyro_maniac ("Leaving.") |
18:51:14 | | Join jordoex [0] (n=quassel@d154-20-53-81.bchsia.telus.net) |
18:53:33 | kugel | domonoky: as interrupt.. |
18:55:19 | | Quit Llorean (Read error: 104 (Connection reset by peer)) |
18:55:42 | | Join Llorean [0] (n=DarkkOne@ppp-70-243-32-116.dsl.hstntx.swbell.net) |
18:56:38 | | Quit mrkiko (Read error: 110 (Connection timed out)) |
18:56:49 | hillshum | how do I get rid of the crosscompiler? |
18:59:42 | kugel | hillshum: delete what it installed |
19:00 |
19:00:01 | hillshum | from where? |
19:00:04 | kugel | domonoky: got it working now |
19:00:11 | kugel | hillshum: look in your path |
19:01:44 | kugel | domonoky: I think this will do for now. I have no idea how to do it else |
19:01:49 | | Join robin0800_ [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
19:01:49 | | Quit robin0800_ (Connection reset by peer) |
19:01:53 | bluebrother | LambdaCalculus37: are you still using a mac? |
19:02:40 | | Join Thundercloud [0] (n=thunderc@cpc3-hem18-0-0-cust53.lutn.cable.ntl.com) |
19:02:45 | kugel | domonoky: we should look into unifying the button driver now, imo |
19:03:29 | LambdaCalculus37 | bluebrother: Yep. |
19:03:50 | bluebrother | nice. Then you might be able answering a few questions regarding OS X :) |
19:04:00 | domonoky | kugel: jup, it also needs a massive clean-up. (many static vars are not needed) |
19:04:09 | LambdaCalculus37 | bluebrother: I'll try my best to. :) |
19:04:34 | bluebrother | how long does it take to remount the player (after ipodpatchers unmounting)? |
19:04:54 | LambdaCalculus37 | bluebrother: I haven't timed it. Want me to? |
19:05:09 | * | LambdaCalculus37 runs to get an iPod |
19:05:31 | bluebrother | and are you able building rbutil on mac? I made up a patch to wait until the system remounts the player after running ipodpatcher / sansapatcher, but have no way to test it |
19:05:54 | LambdaCalculus37 | bluebrother: I've never tried building rbutil on OS X. I can do so right now, though. |
19:06:43 | bluebrother | would be cool if you could try the patch then :) |
19:06:54 | jaykay | jdgordon|zzz: should i report a statusbar bug in the plugins or do you know that it sometimes doesnt get redrawn in the plugins? |
19:06:58 | LambdaCalculus37 | bluebrother: FS#? |
19:07:09 | bluebrother | current version is here: http://www.alice-dsl.net/dominik.riebeling/rockbox/0001-OS-X-after-installing-the-bootloader-for-Ipod-San.patch |
19:07:34 | hillshum | kugel, thats only some of it |
19:07:48 | kugel | domonoky: which one you mean? |
19:07:49 | hillshum | still more somewhere |
19:07:57 | bluebrother | currently the delay until the remount wait times out is 15 seconds, but that might need adjustment |
19:08:01 | kugel | I thought I cleaned up the fuze's one |
19:08:30 | LambdaCalculus37 | bluebrother: I guess I have to apply with patch -p1 then. |
19:08:50 | bluebrother | yep, I'm using git-svn quite a bit these times |
19:08:52 | domonoky | kugel: int_btn and alike are not needed, could be easily done via return values. |
19:10:02 | kugel | domonoky: maybe, but only until we found a way to use an ISR for the wheel |
19:10:11 | | Join xSlack [0] (n=brett@173-17-70-78.client.mchsi.com) |
19:10:57 | LambdaCalculus37 | bluebrother: Okay, first I'm going to time ipodpatcher and see how long it takes to remount the player. |
19:11:10 | * | LambdaCalculus37 takes his watch up and hits enter on the terminal |
19:12:20 | domonoky | ISR for wheel is not possible, there is no interrupt support for dbop reads. but only the wheel, (and maybe hold) needs to store the old value. All other buttons could be done via return values. which would make the code much clearer and more similar to other button-drivers. |
19:14:09 | LambdaCalculus37 | 2m30s.... |
19:14:21 | LambdaCalculus37 | Still ticking... |
19:14:25 | BigBambi | wow |
19:14:42 | LambdaCalculus37 | bluebrother: 2 minutes 43 seconds to unmount, write the bootloader, and remount. |
19:14:48 | LambdaCalculus37 | On my iPod color. |
19:15:33 | bluebrother | urgh. That's kinda ages. |
19:15:51 | | Quit saratoga ("CGI:IRC (Ping timeout)") |
19:16:02 | kugel | domonoky: are you sure it's not *possible*? I still hope we just didn't find a way yet |
19:16:12 | LambdaCalculus37 | However, it appears that it hasn't remounted, but instead is still attempting to. |
19:16:16 | domonoky | kugel: datasheet says so. |
19:16:28 | LambdaCalculus37 | No wait, just showed up in my Finder. |
19:16:45 | kugel | domonoky: dbop has several interrupt masks, nothing of use for us though |
19:17:19 | domonoky | page 85, says no interrupt support for reads. |
19:17:55 | | Join piotrek2234 [0] (n=piotrek2@chello084010133138.chello.pl) |
19:17:56 | kugel | hm, sad |
19:17:58 | LambdaCalculus37 | bluebrother: Okay, how to compile rbutil? Just run qmake? |
19:18:10 | bluebrother | run qmake, then make |
19:18:20 | LambdaCalculus37 | Okay. |
19:18:29 | bluebrother | at least that's the way on windows and linux, I assume it's the same on os x |
19:19:49 | bluebrother | you should increase the value of m_remountTries (currently 30) a bit −− from your timing I guess 600 should be a good value. |
19:20:10 | bluebrother | that's in bootloaderinstallbase:201 after patching |
19:20:14 | LambdaCalculus37 | "qmake: Command not found"!? What the!? |
19:20:53 | * | LambdaCalculus37 knows he installed the Qt libraries |
19:21:25 | bluebrother | either its not in the path or it has a different name −− on my linux box it's qmake-qt4 (to distinguish to qt3) |
19:26:19 | LambdaCalculus37 | I found it. |
19:26:28 | bluebrother | nice :) |
19:26:51 | LambdaCalculus37 | It was installed to /usr/local/Trolltech/Qt-4.4.0/bin here. |
19:26:57 | * | LambdaCalculus37 adds that to his $PATH |
19:29:04 | LambdaCalculus37 | Now we're in business. :) |
19:29:52 | LambdaCalculus37 | Oops... got this message: http://pastebin.com/m1324802f |
19:30:13 | bluebrother | you can safely ignore that. |
19:30:38 | xSlack | What do you use to manage audio on a rockbox ipod |
19:30:38 | LambdaCalculus37 | Okay. |
19:30:40 | * | LambdaCalculus37 makes |
19:30:51 | bluebrother | building for release tries to add the translations to the resources, but those are created later. Worst case would be missing translations |
19:31:26 | LambdaCalculus37 | bluebrother: Meh... since we're just testing some stuff anyway, it's not really the end of the world to not have the translations. |
19:31:49 | bluebrother | LambdaCalculus37: indeed ... I guess you're speaking at least some english ;-) |
19:32:01 | hillshum | xSlack, ?? |
19:32:17 | | Join roman_ [0] (n=roman@89-178-208-216.broadband.corbina.ru) |
19:33:38 | LambdaCalculus37 | bluebrother: :) |
19:34:13 | | Quit kadoban (Remote closed the connection) |
19:34:55 | * | LambdaCalculus37 goes to make a pot of tea while he waits for rbutil to compile |
19:35:12 | kugel | domonoky: that would at least explain that the wheel doesn't feel too good in the OF either |
19:35:23 | kugel | but they probably poll more often |
19:36:09 | hillshum | xSlack, do you mean what desktop software? |
19:37:12 | xSlack | yes |
19:37:29 | xSlack | hillshum: i just plugged my rockbox ipod in and nothing poped up |
19:37:31 | bertrik | xSlack, you can simply put the music anywhere on a rockboxed player and browse to it using the "files" menu, or use the database and select songs based on tags |
19:38:23 | xSlack | I understand that, but i was wondering how i work with the files on the ipod though my desktop |
19:38:27 | xSlack | as far as adding removing |
19:38:42 | xSlack | Normally i just access it like a mounted drive right? |
19:38:47 | hillshum | Are you using iTunes? |
19:39:22 | xSlack | im not using anything right now |
19:39:45 | | Quit bertrik ("yay new kernel") |
19:39:50 | xSlack | But doesnt a ipod usually show up like a usb drive |
19:39:56 | kugel | domonoky: if it's really impossible to read without polling we should find a way to poll the wheel more often, to get at least a reasonable and reliable feeling |
19:40:02 | xSlack | and work the same way, as long as it has rockbox on it |
19:40:57 | hillshum | yeah, just drag and drop or sync with what ever will work |
19:41:08 | hillshum | what OS? |
19:41:34 | domonoky | kugel: we need to somehow determine how fast we need to poll, to not miss a wheel-change. (current tick task runs every 10ms). |
19:42:07 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
19:42:39 | kugel | I think the timer can be programmed faster, if not, we IIRC also have a second timer (I think that's unused) |
19:43:18 | | Join n1s [0] (n=nils@rockbox/developer/n1s) |
19:44:27 | LambdaCalculus37 | bluebrother: Another error: http://pastebin.com/m1b25b738 |
19:45:05 | bluebrother | hmm −− you need libusb and the development headers. |
19:46:53 | | Join kadoban [0] (n=mud@cpe-24-93-17-195.rochester.res.rr.com) |
19:47:17 | bluebrother | you can put libusb.a in the rbutil base folder (if you built libusb statically). At least on linux you can do that ... |
19:48:48 | LambdaCalculus37 | I have libusb and libusb-shlibs installed. |
19:49:05 | Unhelpful | erm, is there a libusb-dev that you need, perhaps? |
19:49:39 | * | LambdaCalculus37 looks in fink |
19:50:17 | LambdaCalculus37 | Nope. |
19:50:17 | LambdaCalculus37 | Nope. |
19:50:23 | * | LambdaCalculus37 kicks X-Chat |
19:53:36 | LambdaCalculus37 | There's a libusb.a file located in /sw/lib; I'll copy it into /rockbox/rbutil then. |
19:53:58 | | Quit kugel (Remote closed the connection) |
19:54:23 | | Quit n1s () |
19:54:43 | | Join n1s [0] (n=nils@rockbox/developer/n1s) |
19:55:32 | LambdaCalculus37 | bluebrother: Should libusb.a be in rockbox/rbutil, or in rockbox/rbutil/rbutilqt? |
19:55:56 | bluebrother | the latter, though if the file is in a standard linker path you don't need to copy at all |
19:56:10 | bluebrother | currently you're missing usb.h ;-) |
19:59:12 | | Join fml [0] (n=4fd3cad8@gateway/web/cgi-irc/labb.contactor.se/x-f6bfa4f90f118586) |
19:59:27 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
19:59:38 | xSlack | How come when i copy my music off of my ipod to my hard drive all of the audio files come up named with four capitol letters like AHJF.mp3 |
19:59:49 | LambdaCalculus37 | bluebrother: And there are a whole bunch of files named usb.h all around my mac. |
20:00 |
20:00:00 | bluebrother | :/ |
20:00:03 | n1s | xSlack: you have itunes to thank for that |
20:00:07 | kadoban | xSlack: that's how iTunes stores it |
20:00:08 | kugel | domonoky: http://pastie.org/390960 |
20:00:27 | kugel | This contains the lcd function and the cleaned up fuze button driver |
20:00:54 | bluebrother | well, you alternatively could download libusb 0.1, extract that in the rbutilqt folder, build it and then add -Llibusb-0.1.12 to LIBS in rbutilqt.pro |
20:01:00 | kugel | I'll commit that later, I need to go now. I'll read the logs in case you have objections or ideas. The Home button works with that now |
20:01:22 | xSlack | wow, so theirs no way i can pull the actual mp3 of the ipod? |
20:01:28 | xSlack | and keep the name |
20:01:41 | bluebrother | maybe that's the easier route ... or check to get the right usb.h and as easy fix maybe copy it to the rbutilqt folder if it's not in the include path |
20:01:56 | rasher | xSlack: That *is* the name the mp3 has. |
20:02:04 | n1s | xSlack: itunes renames then when they are copied *to* the ipod |
20:02:12 | linuxstb | xSlack: There are many third-party apps to copy files of an ipod and rename it something recognisable. But that's off-topic here (ask google). |
20:02:19 | domonoky | kugel: looks fine. |
20:02:21 | hillshum | mp3tag and other software can read the tag and change the filename |
20:02:30 | SoapWork | xSlack, IF your music is properly tagged any one of the numerous full-featured tagging programs out there can rename and organize your mp3s based on interior tags. |
20:02:45 | xSlack | know any? |
20:02:50 | | Quit kugel (Client Quit) |
20:02:54 | hillshum | mp3tag |
20:03:00 | hillshum | this is getting offtopic |
20:03:01 | * | linuxstb thought this was off-topic... |
20:03:22 | * | xSlack sincerely appolagizes |
20:04:18 | | Nick mrkiko_ is now known as mrkiko (n=mrkiko@host149-43-dynamic.56-82-r.retail.telecomitalia.it) |
20:04:40 | * | bluebrother spots that libusb-1.0 is out |
20:04:51 | * | Bagder welcomes committer #70, BigBambi |
20:04:55 | LambdaCalculus37 | \o/ |
20:05:03 | * | LambdaCalculus37 hands BigBambi a beer |
20:05:04 | BigBambi | Many thanks all :) |
20:05:13 | bluebrother | welcome! |
20:05:16 | gevaerts | \☺/ |
20:05:23 | LambdaCalculus37 | BigBambi: Welcome to the Committers Club! :) |
20:05:27 | moos | domonoky: please don't let your findings rot on one of your tree, please commit after :) |
20:06:00 | moos | Bienvenue BigBambi !!! |
20:06:19 | * | n1s gets the cake out |
20:06:21 | BigBambi | cheers :) |
20:06:21 | jaykay | bigbambi: congratulation :) |
20:07:09 | * | moos hightlight the half? of the channel: BEER BEER BEER |
20:07:18 | LambdaCalculus37 | BEER BEER BEER! :D |
20:08:08 | * | BigBambi has no beer :( |
20:08:18 | * | LambdaCalculus37 hands BigBambi a case of beer |
20:09:56 | LambdaCalculus37 | BigBambi: Now time for you to make your initiation commit. :) |
20:10:17 | BigBambi | yeah, I will do shortly - just have to work out how to spell my name... |
20:11:42 | pixelma | you don't know that and want to contribute to the manual? ;) Congrats though :) |
20:11:57 | | Join Horscht [0] (n=Horscht@xbmc/user/horscht) |
20:12:06 | BigBambi | pixelma: hehe, cheers :) |
20:13:34 | | Quit {-phoenix-} (Remote closed the connection) |
20:13:44 | | Join perrikwp|class [0] (i=9821476f@gateway/web/ajax/mibbit.com/x-61d750ef1cee8ab2) |
20:14:12 | * | moos is waiting for the new modified trunk/docs/COMMITTERS file from BigBambi :) |
20:14:25 | BigBambi | moos: I'm getting there :) |
20:16:03 | | Quit bmbl ("Woah!") |
20:17:03 | | Join fdinel [0] (n=Miranda@modemcable204.232-203-24.mc.videotron.ca) |
20:21:41 | gartral1 | shouldnt the bubbles game have a playback context? or is there simply not enough room? |
20:23:49 | n1s | BigBambi: you should get a dev cloak and a forum badge too :) |
20:24:19 | domonoky | gartral1: its probably just because no-one added it :-) |
20:25:30 | kadoban | probably quite a few of the plugins could use playback context... |
20:26:00 | * | gartral1 wonders how hard it is to port... |
20:26:24 | linuxstb | "playback context" ? |
20:26:26 | * | domonoky would think it wouldnt be too hard, plenty of examples around. |
20:26:28 | kadoban | to port playback context? it's like 3 lines of boilerplate if they use the normal menu |
20:29:28 | *** | Saving seen data "./dancer.seen" |
20:29:37 | fml | kugel: hello. I've seen your patch. Well done! The comment in gwps.h is not quite accurate though. It should read "non-negative if set explicitely" (not just "positive") |
20:32:39 | Unhelpful | kadoban: "normal" menu? does that mean not oldmenuapi, or just not custom-drawn menu? |
20:33:20 | kadoban | Unhelpful: i think as long as they don't use a custom-drawn menu it should be easy, but then i haven't looked extensively |
20:35:14 | | Join rakslice_work [0] (n=Vineyard@S01060016b68ef62b.ok.shawcable.net) |
20:35:33 | | Join pyro_maniac [0] (n=jens@77-21-68-46-dynip.superkabel.de) |
20:35:39 | | Quit dan_ ("Leaving") |
20:41:42 | LambdaCalculus37 | bluebrother: I'm still at a loss as to which usb.h file I need to use to get rbutilqt to build properly. |
20:41:44 | hillshum | should the e200v2 build fine? |
20:42:08 | bluebrother | LambdaCalculus37: I guess you have libusb-0.1.12? |
20:42:40 | LambdaCalculus37 | I do. |
20:43:21 | | Quit Llorean ("Leaving.") |
20:44:22 | kadoban | hillshum: seems to build for me |
20:44:34 | bluebrother | well, you could try using the one I have on my box and check if it's the same as one of yours. File is here: http://www.alice-dsl.net/dominik.riebeling/rockbox/usb.h |
20:44:50 | hillshum | must me on my end then |
20:45:54 | | Quit lymeca (Connection timed out) |
20:46:27 | | Join miepchen^schlaf [0] (n=miepel@p579ECB8C.dip.t-dialin.net) |
20:47:08 | | Join dandin1 [0] (n=dandin1-@69-196-152-18.dsl.teksavvy.com) |
20:47:31 | | Join MethoS [0] (n=lem@host-091-097-240-090.ewe-ip-backbone.de) |
20:49:24 | LambdaCalculus37 | bluebrother: Third time's the charm. :) |
20:49:41 | * | LambdaCalculus37 tries once again |
20:53:52 | * | domonoky just commited the e200v2 button fix. Its still ugly because of the interrupt disable while lcd transfers. But i can finally hear music on my e200v2 :-) |
20:56:28 | LambdaCalculus37 | \o/ |
20:56:54 | hillshum | w00t! |
21:00 |
21:02:07 | gartral1 | WOOOT |
21:02:10 | jaykay | what is missing at the e200v2s to be called supported? or is there any (not outdated) wiki page for that? |
21:02:48 | gevaerts | jaykay: stable playback and support for >1GB storage |
21:02:54 | hillshum | The page is SansaV2 and a manual |
21:03:13 | domonoky | jaykay: status on SansaV2 wiki page is still pretty much current. |
21:03:51 | domonoky | also recording is still missing for all ams-sansas. but thats not strictly needed for a release. |
21:04:34 | jaykay | domonoky: may i remove "cannot read scroll wheel" in SansaV2? |
21:05:17 | domonoky | jaykay: yes, while the button driver is still not ready, it works now fine. |
21:07:33 | * | domonoky just updated it :-) |
21:07:42 | pyro_maniac | hi there, I#ve got |
21:08:00 | linuxstb | jaykay: The TargetStatus wiki page says (generally) what's needed for a device to be called "supported" - http://www.rockbox.org/twiki/bin/view/Main/TargetStatus#Current_status_of_supported_targ |
21:08:11 | pyro_maniac | I have got a question again. what happens on "make zip" |
21:08:30 | bluebrother | pyro_maniac: the resulting files of a build get zipped up :) |
21:08:57 | pyro_maniac | bluebrother: where can I find the commands for that? |
21:09:30 | linuxstb | pyro_maniac: The "Makefile" calls buildzip.pl |
21:10:04 | | Quit bluebrother (Read error: 104 (Connection reset by peer)) |
21:10:07 | pyro_maniac | ok, because I got problems with unpacking with tar |
21:11:10 | linuxstb | pyro_maniac: ? "make zip" makes a zip... |
21:12:22 | pyro_maniac | linuxstb: I thought tar can unpack even zip files. oh and ark got problems either |
21:13:11 | | Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) |
21:14:08 | bluebrother | stupid network dropout |
21:14:19 | bluebrother | pyro_maniac: tar can handle tar. Nothing more, nothing less. |
21:14:29 | | Join Taylor [0] (n=Taylor@c-24-91-82-205.hsd1.ma.comcast.net) |
21:14:33 | jaykay | can someone look whether my edit in SansaV2 is ok? |
21:14:54 | pyro_maniac | bluebrother: ok sorry for that and thanks for help |
21:15:05 | bluebrother | LambdaCalculus37: any news? I'm going to be afk for a couple of minutes now |
21:15:37 | LambdaCalculus37 | bluebrother: Still building. |
21:16:04 | LambdaCalculus37 | Oops... http://pastebin.com/m7db38075 |
21:16:12 | Taylor | we've made some progress with the "vulnerability" in the new encrypted ipods - Linux4nano is looking for help from 5/5.5g firmware and RE experts- if you are interested head over #linux4nano-dev |
21:16:39 | bluebrother | ok, so there's some error in my patch. Well. |
21:17:46 | bertrik | yuk, do we really need a dummy read/write to the display to make the buttons work? |
21:18:09 | bertrik | feels like a very hacky workaround to me |
21:21:07 | bluebrother | LambdaCalculus37: updated patch: http://www.alice-dsl.net/dominik.riebeling/rockbox/rbutil-remount.patch |
21:21:50 | LambdaCalculus37 | Got. |
21:22:04 | LambdaCalculus37 | I need to clean up the rbutilqt folder a little bit first. |
21:22:41 | * | bluebrother should've updated the timeout value the same time |
21:22:55 | n1s | Taylor: what progress have you made? |
21:24:26 | | Quit Anges (Remote closed the connection) |
21:24:42 | | Quit Nico_P (Remote closed the connection) |
21:25:13 | | Join z35 [0] (n=z35@h213.100.91.75.dynamic.ip.windstream.net) |
21:26:27 | | Quit perrikwp|class ("http://www.mibbit.com ajax IRC Client") |
21:27:15 | | Quit robin0800 (Read error: 104 (Connection reset by peer)) |
21:27:15 | LambdaCalculus37 | bluebrother: Building once again. |
21:27:46 | | Join Anges [0] (n=agnes@lns-bzn-49f-62-147-173-3.adsl.proxad.net) |
21:28:07 | bluebrother | LambdaCalculus37: updated patch once more −− overlooked another thing (sic): http://www.alice-dsl.net/dominik.riebeling/rockbox/rbutil-remount2.patch |
21:28:30 | bluebrother | I also increased the timeout time this time (wow, what an amount of time ;-) |
21:29:08 | | Quit fml ("CGI:IRC") |
21:29:20 | Unhelpful | bufalloc-like allocator is at FS #9916, if anybody wants to take a look. i'll work on integrating it into pictureflow as a bufalloc replacement next. |
21:29:56 | * | LambdaCalculus37 stops his build, removes the older patch, and adds bluebrother's new patch in instead, and starts up once again with building |
21:32:33 | | Join robin0800 [0] (n=robin080@cpc3-brig8-0-0-cust436.brig.cable.ntl.com) |
21:35:27 | | Join {-phoenix-} [0] (n=dirk@p54B47B90.dip.t-dialin.net) |
21:42:20 | pyro_maniac | can anybody help me with logf() ? |
21:45:19 | | Join MethoS- [0] (n=lem@host-091-096-209-040.ewe-ip-backbone.de) |
21:51:21 | | Quit MethoS (Read error: 60 (Operation timed out)) |
21:53:39 | | Join Chesteta [0] (n=Chesteta@dyn53-149.res-hall.ndsu.NoDak.edu) |
21:54:19 | gevaerts | pyro_maniac: what sort of help? |
21:56:35 | | Quit robin0800 (Read error: 104 (Connection reset by peer)) |
21:56:51 | Chesteta | hello; I just updated to the latest svn and I have a feeling something is wrong... note: i just ran through a svn co svn://svn.rockbox.org/rockbox/trunk rockbox command (checked out a totally new clean svn) see −−> http://rafb.net/p/vKapAB80.html |
21:57:04 | Chesteta | if anyone could help me I would appreciate it |
21:57:26 | pyro_maniac | gevaerts: I've put the "usb_serial_send("test\n",5);" into the usb_serial.c as you said. but after connecting with see you nothing happens |
21:57:50 | n1s | Chesteta: "arm-elf-gcc: command not found" is a pretty strong clue... |
21:58:14 | Chesteta | yeah; but since its a totally new svn checkout... should i reinstall cygwin? |
21:58:52 | gevaerts | pyro_maniac: hm. That seems to mean that usb serial broke since I last checked. I'll look into it soon (probably not today though) |
21:59:06 | n1s | the compiler has nothing to do with your checkout, make sure that you follower all the instructions for installing the cygwin environment |
21:59:15 | n1s | followed* |
21:59:42 | Chesteta | ok; things had been compiling properly before... I will just reinstall cygwin :) |
21:59:48 | gevaerts | Don't |
22:00 |
22:00:07 | gevaerts | You just need to set your $PATH correctly... |
22:00:16 | | Quit CaptainSquid ("Miranda IM!") |
22:00:42 | Chesteta | gevaerts; was that to me or to pyro_maniac? |
22:00:53 | gevaerts | Chesteta: to you |
22:01:27 | Chesteta | ok; how can I set my $path correctly? I am not very familiar with cygwin, all I know is patches and compiling rockbox... |
22:01:32 | pyro_maniac | gevaerts: could I test anything on the connection? debugmode said: cu: fconn_open: Opening port /dev/ttyUSB0 (default speed) cu: fsserial_open: Baud rate is 9600 cu: fconn_set: Changing setting to 0, 0, 2 Connected. |
22:01:35 | | Join casainho [0] (n=chatzill@87.196.187.199) |
22:02:07 | LambdaCalculus37 | bluebrother: http://pastebin.com/m51d621f1 |
22:02:10 | gevaerts | pyro_maniac: there's something wrong on the player side I think. |
22:02:29 | gevaerts | Chesteta: http://www.rockbox.org/twiki/bin/view/Main/CygwinDevelopment#Step_4_Add_the_cross_compiler_di |
22:02:42 | Chesteta | ok; thank you :) |
22:02:52 | | Join mcuelenaere [0] (n=mcuelena@rockbox/developer/mcuelenaere) |
22:03:05 | pyro_maniac | gevaerts: can you tell me more? |
22:04:05 | casainho | hello :-) −− I am working ion drivers for buttons, and I would like to know what values should be returned on "int button_read_device(void)"... like if I want to return a value for my target button_up, what value should I return? |
22:04:22 | bluebrother | LambdaCalculus37: argh. You need a universal libusb. Now how to get that ... |
22:04:25 | gevaerts | pyro_maniac: I'm trying to reproduce it now |
22:04:55 | | Nick hillshum is now known as Hillshum (n=hillshum@unaffiliated/hillshum) |
22:05:12 | bluebrother | LambdaCalculus37: can you try commenting out line 225 in rbutilqt.pro? That might make it only produce a binary for your cpu type |
22:05:58 | | Join akur [0] (n=akur@bl6-157-246.dsl.telepac.pt) |
22:07:41 | | Part akur |
22:12:33 | mcuelenaere | how do I make the bitmaps compile first before any C files get compiled (in a bootloader build)? |
22:12:41 | | Join LinusN [0] (n=linus@rockbox/developer/LinusN) |
22:15:05 | | Quit midijunkie ("?(???~•~)?") |
22:15:06 | | Quit Horscht ("Verlassend") |
22:15:15 | | Quit bertrik ("Leaving") |
22:18:07 | | Quit miepchen^schlaf () |
22:18:23 | | Join miepchen^schlaf [0] (n=miepel@p579ECB8C.dip.t-dialin.net) |
22:19:19 | | Quit LambdaCalculus37 (Read error: 104 (Connection reset by peer)) |
22:22:22 | | Join LambdaCalculus37 [0] (n=rmenes@rockbox/staff/LambdaCalculus37) |
22:24:24 | | Quit fdinel (Read error: 104 (Connection reset by peer)) |
22:24:49 | pyro_maniac | gevaerts: can I help or should I wait? |
22:25:57 | | Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) |
22:26:11 | gevaerts | pyro_maniac: unless you feel like diving head first into the USB code, I don't think you can help much |
22:27:25 | * | gevaerts has an idea... |
22:27:46 | * | Hillshum listens up |
22:29:30 | *** | Saving seen data "./dancer.seen" |
22:30:30 | | Join jaykay_ [0] (n=chatzill@p579E6C9A.dip.t-dialin.net) |
22:35:23 | | Quit jaykay_ (Client Quit) |
22:36:21 | | Join bs66_ [0] (n=sysuser@79.138.192.183.bredband.tre.se) |
22:36:49 | | Part LinusN |
22:40:12 | gevaerts | pyro_maniac: nearly there... |
22:42:27 | pyro_maniac | gevaerts: I got some time to wait |
22:42:32 | | Quit jaykay (Read error: 110 (Connection timed out)) |
22:43:42 | | Quit bs66_1 (Read error: 60 (Operation timed out)) |
22:43:48 | | Quit gregzx ("ChatZilla 0.9.84 [Firefox 3.0.6/2009011913]") |
22:44:08 | | Join Horscht [0] (n=Horscht@xbmc/user/horscht) |
22:47:03 | gevaerts | pyro_maniac: r20023 should fix it. If you enable logf in firmware/usbstack/usb_serial.c, it has a logf() call that tells you the input it received back over the serial line. |
22:47:06 | | Join kachna|lappy [0] (n=kachna@r4ax178.net.upc.cz) |
22:49:08 | | Quit roman_ (Read error: 110 (Connection timed out)) |
22:49:56 | pyro_maniac | gevaerts: I will test |
22:53:58 | | Quit Chesteta () |
22:56:27 | | Quit Beta2K (No route to host) |
22:56:46 | | Join gregzx [0] (n=chatzill@dtm206.neoplus.adsl.tpnet.pl) |
23:00 |
23:02:13 | | Join advcomp2019_ [0] (n=advcomp2@unaffiliated/advcomp2019) |
23:02:39 | CaptainKwel | Hi. ipod video 30gb. Is it normal for disk access to completely clobber the battery? |
23:02:53 | CaptainKwel | Like a single database init will drain the power all at once. |
23:03:12 | LambdaCalculus37 | That doesn't seem normal. |
23:03:14 | CaptainKwel | Or switching songs maybe 5-6 times in succession. |
23:03:22 | | Quit advcomp2019 (Nick collision from services.) |
23:03:23 | | Nick advcomp2019_ is now known as advcomp2019 (n=advcomp2@unaffiliated/advcomp2019) |
23:04:50 | | Join matsl_ [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) |
23:05:15 | | Quit matsl (Read error: 110 (Connection timed out)) |
23:05:29 | | Join Barahir_ [0] (n=jonathan@X9e6c.x.pppool.de) |
23:05:54 | SoapWork | CaptainKwel, was it your battery bench which appeared to elbow at 65%? |
23:06:07 | SoapWork | s/elbow/knee/ |
23:06:55 | CaptainKwel | It would just die altogether. |
23:07:09 | pyro_maniac | gevaerts: now I got feedback |
23:07:38 | SoapWork | are we talking the same thing? FS #9890? logiccircut? |
23:07:53 | SoapWork | Trevor beckerson? |
23:08:09 | | Quit Horscht ("Verlassend") |
23:08:44 | gevaerts | pyro_maniac: great! So now you can start actually using this :) |
23:08:53 | CaptainKwel | no and no. Just using any given svn build. |
23:09:55 | CaptainKwel | It's been happening for as long as i've been running rockbox. Thought it was normal. |
23:10:16 | pyro_maniac | gevaerts: thanks for help |
23:11:10 | CaptainKwel | Trying to figure out which part needs replacing, the disk or the battery. |
23:12:07 | SoapWork | CaptainKwel, as a battery ages the internal resistance of the cells increase. This can lead to a (relatively) healthy looking discharge curve during periods of low power consumption (because voltage drop is a factor of resistance and amperage), but a severe, sudden, drop in measured battery voltage during periods of high current draw. |
23:12:21 | bluebrother | LambdaCalculus37: any more progress on your build attempts? |
23:12:44 | | Join PaulJam [0] (i=PaulJam_@vpn-3012.gwdg.de) |
23:13:00 | LambdaCalculus37 | bluebrother: Nah, keeps crapping out. |
23:13:06 | bluebrother | damn. |
23:13:23 | SoapWork | Since there is no way to look inside a battery and say "hmm, 75% capacity left", capacity is infered by looking up voltage against a standard discharge curve. |
23:13:30 | LambdaCalculus37 | http://pastebin.com/m660849ab |
23:14:07 | SoapWork | IF your battery is failing, your battery voltage will dip during periods of high current consumption so low that it may trigger the low-battery shutdown. |
23:14:11 | bluebrother | that's with the line in rbutilqt.pro removed? |
23:15:02 | CaptainKwel | I have noticed that happening too.. it would dive and sometimes shut down during periods of long disk access, but then still appear to have a healthy percentage left after rebooting. |
23:15:03 | domonoky | LambdaCalculus37: add a -L. to the LIBS in rbutilqt.pro line 226 |
23:15:32 | LambdaCalculus37 | domonoky: Thanks. |
23:15:56 | SoapWork | there are other possibilities, CaptainKwel, but I think the one I outlined is the most likely. |
23:16:23 | CaptainKwel | I picked it up as a refurb so it's probably got more years on it than it looks like it does. |
23:16:47 | SoapWork | Perhaps your HDD is pulling too much juice for some reason. Perhaps your hardware is incorrectly reporting voltage. Perhaps the imps in your iPod are just mucking with you. |
23:16:54 | LambdaCalculus37 | domonoky: My current line 226 in rbutilqt.pro is this: LIBS += -L/usr/local/lib -framework IOKit |
23:17:01 | CaptainKwel | ipod gremlins. |
23:17:51 | | Quit Barahir (Read error: 110 (Connection timed out)) |
23:17:55 | CaptainKwel | hmm. What is the BCM? |
23:18:07 | domonoky | LambdaCalculus37: yes, because i think libusb is normally at usr/local/lib in macosx, just add a -L. if you have the lib in rbutils directory |
23:19:28 | | Join Horscht [0] (n=Horscht@xbmc/user/horscht) |
23:19:42 | | Part Anges |
23:21:49 | | Quit domonoky (Read error: 104 (Connection reset by peer)) |
23:23:07 | n1s | CaptainKwel: a video decoding coprocessor thing |
23:24:39 | | Quit Zoxc () |
23:26:36 | | Quit mrkiko ("leaving") |
23:33:08 | | Quit jhMikeS (Nick collision from services.) |
23:33:14 | | Join jhMikeS [50] (n=jethead7@rockbox/developer/jhMikeS) |
23:39:56 | LambdaCalculus37 | I was wondering... shouldn't the images in manual/appendix/images be updated? They're still the old Archos/Rockbox default icons, and that's already very out of date considering that we have the Tango icons by default now. |
23:41:17 | BigBambi | The file format icons? |
23:42:11 | | Quit ender` (" Life is what happens to you when you had other plans. -- John Lennon") |
23:42:44 | LambdaCalculus37 | Yes. |
23:43:02 | BigBambi | Yeah |
23:45:38 | LambdaCalculus37 | We can keep the old icons for the Archos manuals, but we really should use the new Tango icons for newer targets. |
23:46:20 | BigBambi | yep |
23:48:17 | n1s | BigBambi: for future commits it's customary to reference the FS# of a patch/bug in the commit message, and great work on the manual! :) |
23:48:51 | | Join matsl__ [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) |
23:49:25 | BigBambi | n1s: I know in general, but as I wrote the patch and the task didn't have any discussion, I didn't think it was necessary - however I'll put it in next time :) and thanks :) |
23:50:38 | | Quit matsl_ (Read error: 110 (Connection timed out)) |
23:50:57 | pyro_maniac | gevaerts: after the connection is established the buffer should be red out right? I am asking because I only see the test I have written into the transfer_complete |
23:52:10 | gevaerts | It doesn't write out the entire logf buffer |
23:53:15 | pyro_maniac | I have to force it by myself? |
23:53:38 | | Quit matsl__ (Client Quit) |
23:53:51 | | Join matsl__ [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) |
23:55:30 | pyro_maniac | I have written some logf into the init functions of the hardware and I want to read that after I have made the connection |
23:55:45 | bluebrother | LambdaCalculus37: if you still can't get the libusb thing to work there's always the option to simply remove all libusb related stuff. I've put up a patch at http://www.alice-dsl.net/dominik.riebeling/rockbox/rbutil-removelibusb.diff |
23:55:48 | | Quit matsl__ (Client Quit) |
23:56:40 | gevaerts | pyro_maniac: you'd have to dump the logf buffer exsplicitely I think |
23:56:45 | LambdaCalculus37 | bluebrother: I'll try it in a minute. I'm doing some manual work. |
23:56:55 | bluebrother | noticed that :) |
23:57:34 | LambdaCalculus37 | On the Rockboy manual page, shouldn't the Screen Rotate option be described as "Rotate the screen by 90 degrees" instead of "Rotate the screen by 90 percent"? |
23:57:45 | pyro_maniac | gevaerts: can you say where? |
23:57:47 | bluebrother | won't be around for too long anymore (getting late here) but I'll be around tomorrow. Would be nice if you could confirm my code to work correctly ;-) so we can have that in the next rbutil release |
23:57:54 | n1s | LambdaCalculus37: probably :) |
23:58:08 | bluebrother | LambdaCalculus37: definitely degrees. Percent is ... off |
23:58:09 | LambdaCalculus37 | bluebrother: I'll try it and I'll announce it on the logs. |
23:58:14 | gevaerts | pyro_maniac: not really |
23:58:15 | LambdaCalculus37 | Very off. |
23:58:36 | bluebrother | ok, great. Thanks a bunch for your work (and sorry for the trouble with it ...) |