From 216e50b3b66b8c8f15f4e06a6c9e535cb4b216c6 Mon Sep 17 00:00:00 2001 From: Robert Hak Date: Fri, 14 Jun 2002 09:07:19 +0000 Subject: updating irc logs git-svn-id: svn://svn.rockbox.org/rockbox/trunk@996 a1c6a512-1295-4272-9138-f99709370657 --- www/irc/rockbox-20020605.log | 421 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 421 insertions(+) create mode 100644 www/irc/rockbox-20020605.log (limited to 'www/irc/rockbox-20020605.log') diff --git a/www/irc/rockbox-20020605.log b/www/irc/rockbox-20020605.log new file mode 100644 index 0000000000..c28cd86bf6 --- /dev/null +++ b/www/irc/rockbox-20020605.log @@ -0,0 +1,421 @@ +**** BEGIN LOGGING AT Tue Jun 4 23:37:03 2002 + +--> adiamas (~adiamas@216.194.26.223) has joined #rockbox +--- Topic for #rockbox is Version 1.0 released! http://bjorn.haxx.se/rockbox/ +--- Topic for #rockbox set by adi|home at Tue Jun 4 04:41:56 + hm + the archos is a bit heavy + i need to find a light hd + bb tom +<-- xtac[z] has quit ("i focus on the pain the only thing that's real") +--- You are now known as adi|home +--- dw|gone is now known as dwihno +--> Bagder (~daniel@as3-3-2.ras.s.bonet.se) has joined #rockbox + morning fellas + Good morning! + And it's a wonderful morning indeed. + oh sure + Although my headphones haven't been fixed yet + morning + hellö hellö + Bagder.. my email is shot right now.. can't see commits... did you work on the m3u reader? + yes + it might even work a bit now + :O + I'm more or less waiting for Zagor/Linus to try this and/or comment it + or anyone else of course + hmm.. ill take a look + the read function should take larger peaces each time it does a read() of course... + pieces + not peaces + :) + oops + :-) + peace to everyone ;-) + except Al-Queda + they can burn... + hehe + them and their virgins +* adi|home gets down off his soapbox + can i access the m3u reader from the uisim? + yes + home + name the file .m3u + browse to it and press play on it + k + I mean, it should have a .m3u extension + i get We instruct the MPEG thread to play Ani Difranco - Back Back Back.mp3 for us + correct? + yes + I haven't made the playlist do any shuffle or anything yet + k + it plays it from start to end + and then restarts again + k + however, not all that is possible to see in the simulator + heheh you and i have such diff code styles :) + fd = open() + if (-1 != fd) + hehe + id do: if ((fd = open()) < 0) + I never do the assignment inside the condition if I can move it outside without penalty + any particular reason? + for readability + ahh.. + i wold agree with that.. + the generated code will be exactly the same anyway + but in the same vein.. comparing against -1 specifically is a bad habit to me :) + perhaps + != 0 is failure in unix + not if open() is documented to return -1 on error ;-) + never know what functions return... + heheh true.. + but what if it was to return -2 as well? + ;) + then it would be a silly check ;-) + hehehe + neither way is better.. just diff like i said ;) + yeah + besides.. i know when i become supreme overlord you will have to do it my way ... + im patient.. i can wait ;) + haha, you just let me know when you get your super powers and I'll fix my code then before you turn me into something unpleasant :-P + no worries.. id never turn you into a canadian ;) + the read/open/lseek +* Bagder sighs ffom relief + are they the ones we implimented + or part of the newlib? + yes + newlib is not needed anymore + not used + well if this would be posix stuff - I'd definitely advice to test explictly against -1 and then do errno stuff after that + okay... that case, can read fail? + yes, read can fail + so yes, I should check for that + nods +* Bagder hides + we in fact set errno too, posix-fake-mode enabled ;-) + lol + would use of registers be of any use on the Archos? + just wondering if there is a faster way to run throught that while loop of yours.. + modern gcc versions more or less ignore the register keyword + k + I/ew should read() larger chunks instead + premature optimization is the root of all beer + I/we + reading single-bytes like that is plain silly + there is nothing wrong with premature optimization.. so long as you odn't go overboard + can you give me a rough idea of how we are managing the playlists? + i missed that convo + pretty simple: + we have the playlist on disk as a m3u file + we store only indexes to the file names in memory + that is, to the entry names within the m3u + The m3u is in the memory? + no + never + can i assume the index is the seek used by lseek + then you read in the filename? + exactly + i guess that makes sense.. you ahve to spin the drive up to read in the mp3 anyway. + yes + so doing it to get each index is no big deal. + we can even cache a few indexes before and after if we think that'll improve things + nods + so when we run "random" + we shuffle the arrat with all the seek-positions + array + makes sense + okay.. so we run from start to finish on the indices right? + yes + then having an int index that reps the "index of *NEXT* track to play' makes no sense + you only want to know the current file being played + don't you? + it doesn't really matter + i guess + I chose "next" just so that zero would make sense already when initing the struct + nod + the mpeg thread will id3-read the file and allow others to get that info + ? + thing is + we deliver the track to the mpeg thread long before we hear it + so we need the mpeg thread to tell the world which song that is actually playing right now + nod +--> Linus (~linus@labb.contactor.se) has joined #rockbox + morning Linus + morning! + hen you init the structure.. would you want to reset the seed for rand? + yes + oh btw - random and shuffle play in my mind are different things - and both are nice, depending on situation + are you editing that file at all? if not ill fix this stuff as i go + adi|home: I'm not, feel free to improve + ki + Linus: spotted my id3-fix? + Hadaka: you want "true" random in some cases? That is, same song may be played twice? + okay... what happens if we barf on playlist processing? + ie: file read fails + open fails + Bagder: havent't come to the Rockbox-CVS folder yet... :-) + adi|home: just return, do nothing + k + Linus: hehe :-) + i think we eventually want a message to the user no + ? + Linus: yes - or at times ofcourse a simple limit of not ever picking the next song to be the same song as the one exactly before would be sufficient + Linus: but for example when using mpg123 - I do use true random play for some stuff + what is mp123? + mpg123? + you don't know what it is? :) + alnmighty mp3 thingy + an mp3 player? + Mpg123 is a fast and portable MPEG audio player for Unix. + Ah. + very, very common + That must mean that I'm ver very unaware of things. :-) + Bagder: its your code.. so let me ask.. on checking the open... is if(fd >= 0) acceptable to you? + or rather i leave it -l != fd? +--> nayr (~ryan@ip68-2-171-8.ph.ph.cox.net) has joined #rockbox + hi nayr! + most jukebox softwares on unix use that as a backend - also there's a free replacement for it, mpg321, which is compatible + Hello! + hey nayr + do we have stat in our api now? + or maybe it just makes more sense to lseek to a files end to get its size? + The ID3 code seeks to the end + heheh okay "static unsigned int playlist_seed = 0xdeadcafe" + is just wrong + why do you need the file length? + right now we are reading in the m3u file a byte at a time + that makes no sense. + no it doesn't + ...and... + so get the file size + define a static buffer of say 100 bytes + and read in at a better increment. + so you kno when you hit the file end + your still not mallocing.. + so life is okay + why do you need the file size for that? + i guess i could just keep lseeking? + you could just read until end-of-file + are we gaurenteed to have an end-of-file? + of course + otherwise you wouldn't be able to lseek(9 to find out the end-of-file... + right, thats what im saying... +* adi|home now that i have my head outta my ass + lets say char buf[100] + then we do successive lseeks of 100 till we fail + then we just grab the rest of the file when we fail + you don't need a buffer to do lseek() + i know that + but where are you putting the data from the m3u file? + Maybe I'm not understanding what you want to accomplish + read/parse an m3u file + to store in our playlist structure + So get the data, one row at a time (it's a text file, right?) + right + why seek()? + how do you know when a line ense? + ends? + you search for CRLF + CR/LF or just LF? + whatever + im just going by what we have right now + nods + so to do that you need to read from the file into a buffer + so read into a 100 byte buffer, and look for EOL's + thats what im saying :) + thus the char buf[100] + but I still don't understand the seek() part + are just going to read until read fails? + exactly + so how do you tell the dif between "we reached the end of file: failed" and "archos is fucked: failed"/ + ? +<-- trillback has quit (zahn.openprojects.net irc.openprojects.net) +<-- adi|work has quit (zahn.openprojects.net irc.openprojects.net) +<-- webmind has quit (zahn.openprojects.net irc.openprojects.net) +<-- datazone has quit (zahn.openprojects.net irc.openprojects.net) +<-- gd has quit (zahn.openprojects.net irc.openprojects.net) +<-- PiotR has quit (zahn.openprojects.net irc.openprojects.net) +<-- PsycoXul has quit (zahn.openprojects.net irc.openprojects.net) + -1 means failure, 0 means end-of-file + still there? +<-- Linus (~linus@labb.contactor.se) has left #rockbox +--> Linus (~linus@labb.contactor.se) has joined #rockbox + yeah.. just giant brain fart... + i see what your getting at + great + im not changing this now.. im bound to fsck it up.. to tired.. i ll hit it in the morning + night all + thanks for helping me pull my head from my ass Linus ;) +--> gd (~chatzilla@dns.agssmf.com) has joined #rockbox +--> PiotR (~piotr@212-170-21-172.uc.nombres.ttd.es) has joined #rockbox +--> PsycoXul (psyco@adsl-63-205-43-243.dsl.lsan03.pacbell.net) has joined #rockbox + hmm, one should make a feature checklist of what the archos (recorder) can do - and what is implemented in rockbox + night, adi|home! + how does the resume work on the original archos btw? does it save the current song/directory somewhere when it starts playing it or? + The Player saves that info on the hard drive + when it starts playing a song + ?? I could never get resume to work anyway. + but not when the battery is too low + I guess it's a safety feature not to write on the hard disk when low on batteries + nayr: how come? + ookkay + Well, maybe I'm not understanding what it's supposed to do. I was thinking it would resume a song where it left off between power cycles (ala iPod) + The recorder, OTOH saves that data in internal RAM + nayr: it only remembers which song it played + nayr: we will try to implement mid-song resume in Rockbox + Hmmm... OK. Well, I became overly excited when I heard about this project on /. + I figure there's a much better chance of getting the features I want by working with you folks than working with archos. :-) + nayr: nice. i hope you still feel that way. + nayr: are you a programmer? + yeah, mid-song resume (and keeping of the current playlist) would be just dandy + I used to pretend to be. But if I can code at all, it's high-level stuff (RAD/UI, 4GL, etc.) C/ASM really isn't my forte. I can read it, but I can't code it :( + ok. you can still be very useful + But I kick ass at QA, especially when I've got a personal stake in the project. =) + may god help us :-) + the QA department! + Programmers tend to hate me pretty quickly. =) + :-) + bedtime now. I'm sure I'll be bouncing back in here again soon. Thanks for all the work you folks have done so far, and I look forward to good things in the future! +<-- nayr (~ryan@ip68-2-171-8.ph.ph.cox.net) has left #rockbox +<-- Hadaka has quit (zahn.openprojects.net irc.openprojects.net) +--> Hadaka (naked@graywolf.onnanifujiyuu.org) has joined #rockbox +--> trillback (~trillian@sdn-ar-001ncraleP254.dialsprint.net) has joined #rockbox +--> adi|work (~adiamas@pool-151-204-140-140.ny325.east.verizon.net) has joined #rockbox +--> webmind (webmind@seal.student.utwente.nl) has joined #rockbox +--> datazone ([sm5Ow6WK8@207.136.36.203) has joined #rockbox + Linus: anyway, the id3 code should be reentrant now + Bagder: great + and if you get time, I'd appreciate if you tried the playlist code on target + I realize time is a shortage here ;-) + So the MP3 thread should use the ID3 code to dig some info from the file it plays + yes + and pass it to the GUI somehow + and "export" that info + right + I'll try to find out a good way to report the current playing pos as well + I'll look into Lion's suggestion and see what I can do. + about using a timer? + I didn't follow the playlist discussion. Do we have a working version? + we do + Bagder: timer? + somewhat "naive" and simple still thugh + Linus: forget it, I didn't follow that talk so closely ;-) + AFAICS, there is no good way to determine the song length + does the ID3 tag contain such info? + no, not without scanning the whole file + VBR is hell +--- Linus is now known as Linus|meeting + :/ + VBR is evil stuff + I can't believe I work in a project without gdb on target, when even rockbox has it :-/ + gdb? + <-- sucks, tell me what gdb is good for + debugger + you've not developed seriously when you say that + ah + I used the visual c debugger + right + How hard is gdb to learn? + gdb is much more powerful, if somewhat more crude interface + the basics are simple + using it from within emacs makes it even easier + You got some basic introduction stuff? + 'b [symbol]' for breakpoints + 'c' for continue + 'run' to start + 'n' for next + 's' for step-in + that's it ;-) + 'p [variable]' display variable contents + 'info locals' display all local variables + does it require some extra stuff compiled into the binary? + yes, it requires that it was compiled with -g for maximum use + mkay +--> Zagor (~bjst@labb.contactor.se) has joined #rockbox + hey Z + hi + Zagor: I added some playlist code yday + not very fancy or anything, but it could work + ok, nice + it's still basic and slightly "naive" + but a start + Zagor: I made 'playing' hold a play "mode" instead of just a boolean + so that play-all-dir should still work too + in tree.c you mean? + yes + ok + they're just digits now, but we should remake it into some enum or somthing + yup + 152 subscribers today + wow +<-- Smari has quit (Read error: 110 (Connection timed out)) +* ironi has returned, [gone/11h 49m 47s] + hello ppl + hi ironi + hey ho + just came home + I'm thinking on working on my persolan homepage + It needs a facelift + time to go and get a visa ;-) +--- Bagder is now known as Bagder|away + hehe + apt-get dist-upgrade is my favourite command ever + yeah, debian rocks + it does. + hehe, nice peak yesterday. + 3rd june: 4700 accesses + 4th june: 60196 accesses + pages, not accesses + 04:00-05:00 on the 4th: 25 pages + 05:00-06:00 on the 4th: 3279 pages :) + has there been a post on slashdot? + =) + quite so + Is there some way to make directories invisible using the archos firmware? I'd like to have a folder to store documents and stuff and I don't want it being displayed :) + not that I know of + dwihno: well maybe hidden directories could be excluded in the archos + that is perhaps an easy solution + yeah + I'll test that later + I sold my last computer last night + So now I have ZERO computers + Zero, zip, nada! + heh + INGA! + when is the dell coming? + No jävla datorer! :) + I haven't ordered it yet + oh ok + I'm awaiting a faktura to be betalad by the evil customer + it doesn't take long for themto ship it though, i thiok. + you din't take cash, thats bad. + =) + Nah, it will probably take less than 1 week + Are there any good ways to install some really kickass boot loader? + I want to have Win98, Win2k and linux on the same box :) + i'm sure the guys in #linuxhelp knows all about that. :) + dwihno: grub is nice + ironi: never tried it... :) +* dwihno goes on a google streak + if you want windows gui easy-to-install-bla-bla-mumbo-jumbo there is powerquest bootmagic + Eww + grub is cool though because you can edit the options in the boot loader + at boot + That's what I like! + I like configurability + i tried when using gentoo + i really find it better than lilo for me + Hmm, how come? + i just like it more + Is it cute? :) + you dont edit a config file, you instead enter a grub console where you supply commands + you can enter this console at boot too + if you want + ah + Damn DNS server! + GIVE ME THE LOOKUP YOU EVIL DNS STUFF! :) + ah, now it works +--- Disconnected (Connection timed out). +**** ENDING LOGGING AT Wed Jun 5 06:14:13 2002 + -- cgit v1.2.3