--- Log for 07.09.104  Server: leguin.freenode.net  Channel: #rockbox
--- Nick: logbot  Version: Dancer V4.16  Started: 11 days and 13 hours ago

00.00.40 #       <amiconn> LinusN: Perhaps the tag handling in mpeg.c should be rewritten, because of several reasons:
00.01.06 #       <LinusN> amiconn: yes
00.01.09 #       <amiconn> (1) It has a static limit of 16 tracks
00.01.31 #       <amiconn> (2) If this limit is exceeded, it seems to cause problems
00.01.56 #       <LinusN> 1) we want static limits
00.02.03 #       <LinusN> 2) that's the bug
00.02.25 #       <amiconn> (3) It uses both an array of structs and a pointer array to these. Why it's designed that way is beyond me
00.03.02 #       <amiconn> (4) There are frequent NULL pointer accesses while playback
00.03.20 #       <LinusN> 3) that's an old relic from the days the structs were allocated from the pool of 16 structs
00.03.34 #       <LinusN> 4) yes, that's another bug
00.03.47 #       <amiconn> (5) the struct array for 16 tags consumes a whopping 24 K of ram (bss)
00.04.20 #       <LinusN> "whopping" :-)
00.04.48 #       <amiconn> For what it does, I consider this "whopping"
00.05.09 #       <amiconn> I wonder why it is necessary to convert & buffer the tags of all loaded tracks at load time.
00.05.39 #       <LinusN> because we don't want to spin up again just to read the tags?
00.06.22 #       <amiconn> Aren't the tags loaded interspersed with the mp3 data, so that they are in ram already, between the tracks?
00.06.48 #       <LinusN> they aren't loaded into the mp3 buffer
00.07.01 #       <LinusN> only mp3 data is in the buffer
00.07.20 #       <LinusN> and we need a copy of the tags, since the tag data will be gone when the buffer fills up the next time
00.07.36 #       <LinusN> (if they were loaded into the mp3 buffer, that is)
00.07.51 #       <amiconn> I'd rather suggest to only store the track start index at load time (this table could have many more entries, since these are simple pointers)
00.08.33 #       <amiconn> The tags could then be decoded when needed (e.g. when the previous track starts)
00.08.42 #       <LinusN> "track start index"?
00.09.20 #       <amiconn> Yes, the buffer index where the track starts
00.09.37 #       <LinusN> you mean load the tags into the mp3 buffer?
00.10.07 #       <amiconn> Yes, although this is slightly more work for v1
00.10.27 #       <LinusN> yes it is, and the swapping will be trickier
00.11.09 #       <LinusN> since you mustn't swap the tag data
00.11.20 #       <amiconn> Of course
00.12.10 #       <amiconn> My first though was to place the already decoded tags into the buffer, but this won't work when the buffer wraps in the middle of the struct
00.12.24 #       <LinusN> we have discussed this approach several times, and found it pretty complicated
00.14.08 #       <amiconn> If we stay with the current approach (an array of structs) I still don't get why there are 16 pointers, allocating from a pool of 16 structs. This is complicated too, for no reason. We could use the struct array directly as a ring buffer
00.14.26 Quit    edx ()
00.15.23 #       <amiconn> On the contrary, if we would buffer the tags within the mp3 buffer, the ram allocation for tags would be dynamic.
00.15.48 #       <LinusN> amiconn: did you read my answer for your question 3)?
00.17.04 #       <amiconn> Yes, I read that, but I still don't get why this was done. Did the usused struct got used for something else?
00.17.54 #       <LinusN> i don't remember why it was designed like that back then
00.18.21 #       <LinusN> i think it might come from the days when we had a malloc
00.18.22 #       <amiconn> For the typical use as a music player, there are mostly 1..2 tracks in memory, so having 16 slots is wasting ram. On the other hand, if you have short clips, 16 slots might even be too few :(
00.19.46 #       <LinusN> yes, i agree that we need a better way of handling this
00.20.20 #       <LinusN> but i think loading the tags into the mp3 buffer will lead to complicated code
00.20.21 #       <lImbus> where's the problem to make this variable ?
00.20.37 #       <LinusN> we don't have dynamic memory
00.20.54 #       <lImbus> uhh. that's some argument.
00.21.31 #       <lImbus> how are the limits for "max files in dir browser" and playlist handled ?
00.21.52 #       <amiconn> These pointers are btw the reason for the NULL pointer accesses.
00.23.24 #       <LinusN> lImbus: they are taken from the mp3 buffer at boot time
00.23.30 #       <LinusN> amiconn: ah
00.25.50 #       <amiconn> LinusN: You said that buffering the tags within the mp3 buffer complicates the bitswapping. This is only true if the tracks are swapped at load time. We could swap before playback instead (the next dma chunk)
00.26.33 #       <amiconn> This could in fact help portability - chances are that another architecture doesn't need bitswapping
00.27.38 #       <amiconn> I consider bitswapping to be a part of the "mp3 driver", while handling the tags, track changes, reloads etc. is part of the playback engine
00.27.49 #       <LinusN> finding the next dma chunk will still be more complicated
00.28.18 #       <LinusN> today, everything in the mp3 buffer is mp3 data, so we can just grab the next 64k
00.28.33 #       <amiconn> We don't...
00.28.43 #       <lImbus> ok, that's what I meant. isn't the case of having 16 tracks beeing smaller than 2 MB (or even 8MB) small enough to make that configurable like max dirbrowser ?
00.29.03 #       <lImbus> Frihet must have chunks smaller than 128 kB
00.29.22 #       <Frihet> I can look
00.31.32 #       <Frihet> The MP3 files average about 60KB
00.32.37 #       <Frihet> They are short phrases like "Hvordan har du de"
00.33.21 #       <LinusN> amiconn: yes, there is the special cases when the end of the buffer is reached, and at track boundaries
00.33.55 #       <LinusN> but the tags-in-buffer approach complicates it even more
00.34.13 #       <amiconn> LinusN: Yes, exactly. We already check for track boundaries, so having the tag data at the beginning of the next tracks shouldn't add much complexity
00.34.18 #       <LinusN> i'm not saying that it is hard, i just mean that the code will get harder to understand
00.35.03 #       <LinusN> and when the tags are big, we will waste buffer space, like when some silly person sticks album covers in the tag
00.35.35 #       <amiconn> If we pre-decode the tags and put the struct at the beginning of the track, the size will be constant.
00.36.04 #       <amiconn> This has to be copied when starting playback of that track, since otherwise it is gone at the next reload
00.36.37 #       <amiconn> The only special case would be when the buffer would wrap within the tag data, but that can be avoided by wrapping prematurely
00.36.39 #       <LinusN> yup
00.39.00 #       <amiconn> Btw: my interpretation of the posix rules for O_TRUNC is correct :)
00.39.07 #       <LinusN> good
00.40.03 #       <amiconn> So I'll try what you suggested, and hope it doesn't ruin my box' file system (of course I have a backup)
00.41.24 #       * amiconn digs for the correct irc backlog
00.43.16 #       <Frihet> I will leave bug 949268 with the experts and check in later in the week.  If it's too big a deal, just let me know.
00.43.48 ***     Saving seen data "./dancer.seen"
00.44.07 Quit    Frihet ("ChatZilla 0.9.52B [Mozilla rv:1.6/20040114]")
00.44.43 #       <amiconn> LinusN: As you probably found, I implemented the new screen_dump() without using assembler ;)
00.46.27 Join    SmoothOperator [0] (~c35d2208@labb.contactor.se)
00.46.36 Quit    SmoothOperator (Client Quit)
00.56.12 #       <LinusN> amiconn: saw that, and was pleased :-)
00.56.17 #       <LinusN> sleep time
00.56.18 #       <LinusN> nite all
00.56.24 Part    LinusN
01.10.38 Join    Frihet [0] (~chatzilla@38.119.217.96)
01.13.07 Quit    Frihet (Client Quit)
01.26.34 Join    SmoothOperator [0] (~acbeb032@labb.contactor.se)
01.42.05 Quit    SmoothOperator ("CGI:IRC (Ping timeout)")
02.23.05 Part    amiconn
02.43.50 ***     Saving seen data "./dancer.seen"
02.49.22 Join    NegativeK [0] (~negk@68.114.40.130)
03.01.30 Quit    elinenbe (" HydraIRC -> http://www.hydrairc.com <- irc client ownage!")
04.01.30 Quit    lImbus (Remote closed the connection)
04.23.29 Quit    NegativeK ("Leaving")
04.23.30 Join    NegativeK [0] (~negk@68.114.40.130)
04.43.54 ***     Saving seen data "./dancer.seen"
05.21.29 Join    grogro [0] (~gromit@ALagny-151-1-23-64.w83-114.abo.wanadoo.fr)
05.39.50 Quit    maikeul (Read error: 110 (Connection timed out))
06.27.50 Join    midk [0] (~midk@c-24-18-39-204.client.comcast.net)
06.35.46 Join    scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com)
06.35.51 Part    scott666_
06.43.55 ***     Saving seen data "./dancer.seen"
07.32.33 Join    LinusN [0] (~linus@labb.contactor.se)
08.09.05 Nick    midk is now known as midk|sleep (~midk@c-24-18-39-204.client.comcast.net)
08.20.21 Join    hardeep [0] (1098@208.247.65.237)
08.20.48 #       <hardeep> hey, does anyone know where I can download some sample rvf files?
08.23.28 #       <hardeep> aha, found some: http://rockbox.haxx.se/newvid/
08.25.15 Join    Zagor [242] (~bjst@labb.contactor.se)
08.26.28 #       <LinusN> Zagor: today is payday for you, you owe me a lunch :-)
08.26.39 #       <Zagor> sure
08.27.36 #       <dwihno> :-)
08.36.28 Part    LinusN
08.36.38 Join    LinusN [0] (~linus@labb.contactor.se)
08.37.41 #       <dwihno> ConTraktor
08.43.56 ***     Saving seen data "./dancer.seen"
08.45.55 #       <Zagor> whoa, what happened to todays daily build?
08.47.24 #       <dwihno> ?!
08.47.48 #       <Zagor> hmm, bug and patch lists are empty too. network blackout?
08.47.50 #       <dwihno> Perhaps somebody tried integrating the rombox build (Badger?)
08.48.23 Join    [IDC]Dragon [0] (~d9ff8454@labb.contactor.se)
08.48.40 #       <[IDC]Dragon> 'morning from me logpeeker
08.48.46 #       <Zagor> :)
08.49.09 #       <[IDC]Dragon> hardeep: here are some really nice videos: http://rockboxvideo.redbreva.co.uk/
08.49.45 #       <[IDC]Dragon> and a few links to mediocre ones: http://rockbox.haxx.se/mail/archive/rockbox-archive-2004-02/0189.shtml
08.52.08 #       <[IDC]Dragon> hardeep: got enough bandwidth?
08.53.32 #       <[IDC]Dragon> did anybody check if the daily ROMbox build works?
08.56.05 Join    Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se)
08.56.42 #       <Bagder> Zagor: you checked why the daily builds failed?
08.56.46 #       <dwihno> When you talk of the trolls ;)
08.56.58 #       <Zagor> looking at it now. the bug and patch lists are empty too.
08.57.10 #       <Zagor> Bagder: you check the builds, i'll check the lists ok?
08.59.27 #       <Bagder> something truly weird happened
08.59.44 #       <Bagder> the size of the tarball package is a lot smaller today
09.00.03 #       <[IDC]Dragon> (my question somehow got answered)
09.01.37 #       <Bagder> I can't see how the problems can be related
09.01.51 #       <Bagder> Zagor: didn't you get some clues in a crontab mail?
09.02.02 #       <Bagder> or is it dev/nulled?
09.02.44 #       <Zagor> i think i deleted it :(
09.03.40 #       <[IDC]Dragon> bbl
09.03.58 #       <[IDC]Dragon> (learned that acronym yesterday)
09.04.01 Part    [IDC]Dragon
09.06.36 #       <Bagder> hm
09.07.45 #       <LinusN> Bagder: bleeding edge and daily builds are done by differents scripts, right?
09.08.16 Quit    Bagder ("Leaving")
09.17.51 #       <LinusN> Zagor: u there?
09.24.47 #       <Zagor> rerunning daily builds...
09.26.20 #       <webmind> morning
09.26.31 #       <Zagor> hi
09.29.07 Join    amiconn [0] (~jens@pD9E7DE1A.dip.t-dialin.net)
09.29.25 #       <amiconn> morning
09.32.14 #       <LinusN> hi
09.32.37 #       <LinusN> amiconn: regarding the tag discussion
09.33.30 #       <LinusN> we need to keep the current and the upcoming tag in memory, otherwise the next-track wps info won't work
09.33.37 #       <amiconn> Of course
09.34.08 #       <Zagor> daily builds now work. the problem was "configure update" mangled the Makefile for some of the targets.
09.35.03 Join    amiconn_ [0] (~jens@pD9E7F378.dip.t-dialin.net)
09.35.43 Join    amiconn__ [0] (~d9092244@labb.contactor.se)
09.36.41 Quit    amiconn (Nick collision from services.)
09.36.41 Nick    amiconn_ is now known as amiconn (~jens@pD9E7F378.dip.t-dialin.net)
09.37.11 Join    Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se)
09.38.52 #       <amiconn__> Zagor: The tarball is now much larger than the last few days...
09.39.04 #       <Bagder> looks wrong
09.40.42 #       <Bagder> and so it is
09.40.56 #       <Bagder> it contains a rockbox-daily-20040907 dir
09.41.00 #       <Bagder> with contents
09.41.24 #       <Bagder> like rockbox-daily-20040907/rockbox-daily-20040907/apps/
09.41.41 #       <LinusN> i guess someone has unpacked it in the build dir when we examined the build errors
09.42.03 #       <Bagder> yes "somone" must have ;-)
09.42.10 #       * Bagder can't type
09.42.27 #       <LinusN> but he can unpack a tar file :-)
09.42.38 #       <Bagder> *I* didn't do that
09.42.46 #       <LinusN> sorry :-)
09.42.53 #       <Bagder> since I can't type, I can't unpack either ;-)
09.42.59 #       <amiconn__> LinusN: To flash that into the box?
09.43.03 #       * LinusN points to Zagor
09.43.16 #       * Bagder joins LinusN in the pointing
09.43.23 #       <amiconn__> Ooops, I read "uclpack" instead of "unpack"
09.43.53 Mode    "#rockbox +o LinusN " by ChanServ (ChanServ@services.)
09.44.05 #       <LinusN> amiconn__: want to kick amiconn?
09.44.14 #       <amiconn__> LinusN: No.
09.44.18 #       <LinusN> ok
09.44.32 #       <amiconn__> This is my home box, I just have to wait 15 min to re-connect to it
09.44.37 #       <Zagor> well i didn't unpack anything anywhere
09.45.11 #       <LinusN> weird
09.45.31 #       <Bagder> it might be because it was re-run on the same date
09.45.34 #       <Bagder> somehow
09.45.41 #       <Bagder> let's ignore it and hope it works better tomorrow
09.45.44 Join    kurzhaarrocker [0] (~knoppix@p50877DD2.dip0.t-ipconnect.de)
09.45.45 #       <LinusN> or we ran the update.sh script in the wrong dir
09.46.13 #       <Bagder> Zagor: did you update the uclpack tool?
09.46.44 #       <Zagor> nope, didn't find the source then got busy with other stuff
09.47.00 #       <Bagder> the source is in the RomBox wiki page
09.47.14 #       <Zagor> no, that's just one file. more is needed.
09.47.26 #       <Bagder> aha
09.47.32 #       <Bagder> yes, ucl-1.01
09.47.43 #       <Bagder> I'll fix it
09.47.46 #       <Zagor> thanks
09.48.49 #       <Bagder> it uses the /usr/local/bin one, right?
09.50.25 #       <Bagder> it is updated now anyway
09.50.26 #       <Zagor> i think so yes
09.51.02 #       <Bagder> gcc 3.0.4 makes a 5K larger ucl file than 3.3.1
09.51.32 #       <Bagder> we should upgrade the cross-compiler stuff on labb as well
09.51.54 #       <Zagor> yeah
09.53.02 #       <Bagder> "Output is 216 bytes larger than max (188400)"
09.53.11 #       <Bagder> 3.0.4 can't make a rombox for the v2
09.53.21 #       <Zagor> boo
09.55.25 #       <Bagder> annoying
09.55.32 Quit    amiconn__ ("CGI:IRC 0.5.4 (2004/01/29)")
09.58.46 #       <amiconn> Back for real :)
10.03.01 Join    [IDC]Dragon [0] (~d90a3255@labb.contactor.se)
10.03.12 #       <[IDC]Dragon> back again
10.03.28 #       <amiconn> hi Jörg
10.03.49 #       <[IDC]Dragon> no Ondio luck yesterday? (saw your bid)
10.04.04 #       <amiconn> Was too expensive imho
10.04.16 #       <amiconn> Today another Ondio is due (in the evening)
10.04.18 #       <[IDC]Dragon> cheapskin!
10.07.48 #       <[IDC]Dragon> amiconn: on a different one: nice screendump function
10.08.29 #       <[IDC]Dragon> or, bad one before, 1.8K buried, ts, ts
10.09.00 #       <[IDC]Dragon> do we have more like that?
10.09.28 #       <LinusN> very likely
10.09.39 #       <[IDC]Dragon> where?
10.10.10 #       <LinusN> there is a possibility that we have more debug functions that have ended up in the official build
10.10.39 #       <LinusN> and those are probably not very optimized
10.11.10 #       <[IDC]Dragon> scary...
10.11.30 #       <LinusN> not at all, that's how things work
10.11.54 #       <LinusN> there is a first version of everything, then you improve it
10.12.05 #       <amiconn> LinusN: I'd suggest eliminating most of the debug menu for the upcoming 2.3 release, leaving only stuff that could really help to spot problems
10.12.17 #       <LinusN> amiconn: absolutely
10.12.22 #       <[IDC]Dragon> I was joking, don't take it too serious
10.12.33 #       <LinusN> [IDC]Dragon: no offense taken
10.13.03 #       <LinusN> we can at least put the debug functions on a diet
10.13.17 #       * [IDC]Dragon has a deja-vu: "upcoming 2.3 release"
10.13.43 #       <LinusN> we need to find the nasty recording bug that Paul experiences
10.13.55 #       <amiconn> Candidates would be the mas register & codec debug...
10.13.56 #       <[IDC]Dragon> 3KB to go for "native FM" rombox
10.13.59 #       <LinusN> with lots of corrupt frames
10.14.39 #       <[IDC]Dragon> LinusN: can we reproduce that?
10.14.56 #       <LinusN> amiconn: do you get corrupt frames?
10.15.16 #       * [IDC]Dragon shoul try recording
10.17.08 #       <amiconn> LinusN: Usually I almost use recording. I plan to do even more extensive recording tests, though
10.17.29 #       <amiconn> I would need a reliable tool to spot corrupt frames for that
10.18.03 #       <[IDC]Dragon> amiconn: have you looked at my frame parser in rvf_mux?
10.18.17 #       <amiconn> mp3utility is a bit questionable, and mp3fixer is definitely buggy, at least the windows binary
10.18.28 #       <amiconn> [IDC]Dragon: No, not yet
10.18.38 #       <[IDC]Dragon> should be easy to make a tool from it
10.19.15 #       <[IDC]Dragon> it walks the headers, inspects them all
10.19.31 #       <[IDC]Dragon> and recognises lost/regained sync
10.19.38 #       <amiconn> Does it check the frame checksum (if there is one)?
10.19.50 #       <[IDC]Dragon> no
10.20.08 #       <[IDC]Dragon> feel free to add that ;-)
10.20.54 #       <LinusN> the code in mp3data.c and the vbrfix code should be a good base to build upon
10.21.14 #       <[IDC]Dragon> so we got choices
10.28.28 #       <amiconn> [IDC]Dragon: As you asked whether we have more functions that use a lot of ram: look at the ro(ck|m)box.map, especially the bss space each module takes
10.30.13 #       <[IDC]Dragon> "ro(ck|m)box", hehe
10.30.58 #       <[IDC]Dragon> yes, that's a start. but I don't know how much is "justified", and no names for static stuff
10.32.58 #       <amiconn> One of those little ram suckers is mpeg.o, because of the tag handling...
10.33.22 #       <[IDC]Dragon> putting salt on LinusN's wounds?
10.33.42 #       <[IDC]Dragon> (if that german saying translates correct)
10.43.14 #       * [IDC]Dragon still thinks malloc would be nice
10.44.00 ***     Saving seen data "./dancer.seen"
10.44.00 #       <Bagder> malloc for what?
10.44.27 #       <Zagor> malloc is a waste of ram
10.44.28 #       <[IDC]Dragon> for not having worst-case static allocation all the time
10.44.52 #       <Zagor> the only result will be lovely out-of-memory handling code all over the place
10.44.58 #       <[IDC]Dragon> it's a tradeof, not a waste
10.45.44 #       <[IDC]Dragon> out of memory is an assert within malloc
10.45.45 #       <Zagor> ok i won't dismiss it right off like that. where do you suggest we'd benefit from it?
10.46.14 #       <[IDC]Dragon> the tag handling, for example
10.46.16 #       <amiconn> I'm tempted to rewrite the tag handling (dynamically within the mp3 buffer, as I discussed with LinusN). I wouldn't need malloc for that
10.46.30 #       <Zagor> but with an assert we'd crash whenever we run out of memory!?
10.47.23 #       <[IDC]Dragon> we have the mp3 buffer to munch from, we won't run out of mem for the other stuff
10.47.53 #       <Zagor> it's pretty icky munching from the mp3 buffer while music is playing
10.48.19 #       * [IDC]Dragon thinks vaguely about a way to have the unallocated as a linked buffer list
10.48.35 #       <Bagder> it is possible
10.48.44 #       <Bagder> but icky
10.48.49 #       <[IDC]Dragon> whenever mem is needed, it should be taken from the played end
10.49.00 #       <Bagder> but...
10.49.03 #       <[IDC]Dragon> if not possible, from the newes unplayed
10.49.20 #       <Bagder> so it would need to reread data?
10.49.28 #       <[IDC]Dragon> yes, something like that
10.50.14 #       <amiconn> An ugly thing with malloc is memory fragmentation (without having an mmu of course). How would you handle that?
10.50.34 #       <dwihno> MMU?
10.50.49 #       <Bagder> it fragments even with MMU
10.50.59 #       <[IDC]Dragon> as we wade through, it will defragment again
10.51.13 #       <amiconn> Bagder: Yes, but you can remap the unused pieces into one region
10.51.45 #       <LinusN> we have had this discussion countless times
10.51.55 #       <[IDC]Dragon> there's different algorithms for reducing fragmentation
10.52.01 #       <[IDC]Dragon> LinusN: sorry
10.52.23 #       <LinusN> don't worry, this time we might come to a different conclusion
10.52.31 #       <Bagder> reducing is the word, it can't be avoided
10.52.36 #       <[IDC]Dragon> sounds optimistic
10.53.15 #       <Bagder> I still haven't read a good argument why it is good in current rockbox
10.53.28 #       <LinusN> Bagder: agreed
10.53.32 #       <[IDC]Dragon> well, by profession I'm working on an embedded system for mobile phones
10.53.53 #       <[IDC]Dragon> and we malloc like crazy
10.54.01 #       <[IDC]Dragon> no problems yet
10.54.14 #       <Bagder> I'm sorry, but that doesn't really answer my question
10.54.28 #       <Bagder> I too usually use malloc a lot
10.54.53 #       <[IDC]Dragon> we're probably not even aware any more in how many places we put memory aside
10.55.45 #       <[IDC]Dragon> like, to communicate the recording pathname to the mpeg task, there are 2 static buffers
10.56.33 #       <[IDC]Dragon> really needed only until the taskswitch
10.57.18 #       <Bagder> I believe the cost of adding code for handling segmented mpeg playback, malloc and everything is much greater than the amount of memory currently "wasted" due to our lack of malloc - but this is only my suspicion
10.57.35 #       <[IDC]Dragon> a valid one
10.59.13 #       <Bagder> btw
10.59.18 #       <[IDC]Dragon> certainly I also don't know, it's just by gut feeling I woudn't build an embedded system of this size without malloc
10.59.24 #       <Bagder> I think we should release 2.3 soon
10.59.30 #       <[IDC]Dragon> ;-)
11.01.38 #       <LinusN> also consider the amount of debugging time we have gained by not having to hunt memory leaks
11.02.08 #       <Zagor> or oom crashes
11.02.17 #       <LinusN> or defragmentation problems
11.02.51 #       <LinusN> dynamic memory is a two-edged sword imho
11.02.57 Join    lImbus [0] (~manuel@kernel.cycos.net)
11.03.05 #       <LinusN> i avoid it if i can
11.03.12 #       * [IDC]Dragon shuts up on the subject
11.03.16 #       <LinusN> :-)
11.04.41 #       <[IDC]Dragon> how about a call for 2.3 feature freeze?
11.04.54 #       <[IDC]Dragon> or are we not freezing any more?
11.04.58 #       <Bagder> good idea
11.05.10 #       <[IDC]Dragon> we appear frozen already
11.06.16 #       <[IDC]Dragon> I'll probably folk (temporarily) for Ondio, but that's a different story
11.06.31 #       <Bagder> we should fix the gcc on the build box before release so that we can offer rombox on as many configs as possible
11.07.08 #       <[IDC]Dragon> s/folk/fork
11.09.39 #       <[IDC]Dragon> do we need some more field testing with gcc3.3.1?
11.10.32 #       <Bagder> we need to upgrade the rockbox.haxx.se's gcc installation to 3.3.1 from 3.0.4 to make smaller files
11.10.42 #       <[IDC]Dragon> yes
11.11.20 #       <[IDC]Dragon> and perhaps the build results could use some more testing, because of the compiler change?
11.11.27 #       <Bagder> true
11.11.41 #       <Bagder> just in case
11.14.32 #       <[IDC]Dragon> btw, gcc3.3.1 now works on my box, too
11.14.45 #       <[IDC]Dragon> thanks to BC's devkit
11.15.07 #       <Bagder> bbl
11.15.09 Quit    Bagder ("Leaving")
11.31.11 Quit    NegativeK (Read error: 113 (No route to host))
11.59.08 Join    dwihno_ [0] (~dw@81.8.224.89)
12.07.40 Quit    dwihno (Read error: 60 (Operation timed out))
12.10.27 Join    dwihno [0] (~dw@81.8.224.89)
12.17.21 Join    Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se)
12.24.39 Quit    dwihno_ (Read error: 110 (Connection timed out))
12.32.05 #       <lImbus> Bagder: can you tell me more about the rockbox-funds ?
12.32.31 #       <Bagder> it is the donated money via the "donate" paypal button on the site
12.34.07 #       <lImbus> mhmm. would like to donate a small bit too, but mind to open a paypal stuff for only that.
12.34.30 #       <Bagder> I don't think you need to do that
12.34.42 #       <Bagder> you can pay with a credit card if you wish
12.36.04 #       <lImbus> mhmm. don't have one. that's the main issue I think.
12.36.32 #       <lImbus> doesn't it have a SWIFT and BIC like european international transfers now ?
12.36.46 #       <Bagder> I don't know, it might
12.41.28 Quit    dwihno (Read error: 110 (Connection timed out))
12.44.01 ***     Saving seen data "./dancer.seen"
12.44.31 #       <lImbus> can't find anything concerning that.
12.47.27 #       <Bagder> me neither
12.53.17 #       <Lynx_> |Imbus: are you german?
12.56.04 #       <Lynx_> https://www.paypal.com/de/
12.59.18 #       <lImbus> not really. but that seems to be solution, as soon as I am willing to create another account for that. I simply don't want to have a special account on nearly every internet page
13.17.21 Quit    Bagder ("Leaving")
13.42.10 Join    dwihno [0] (~dw@81.8.224.89)
13.45.18 Join    yousan [0] (~yousan@peta5.u-aizu.ac.jp)
13.45.47 Quit    yousan (Client Quit)
13.53.41 #       <Zagor> whee, the iriver uses the isd-300 usb/ata bridge
13.54.01 #       <Zagor> it's only renamed "cypress cy7c68310" since cypress bought isd
13.54.44 #       <kurzhaarrocker> How much is in the rockbox fund? Can we buy one too? :)
13.54.57 #       <Zagor> we will
13.55.17 #       * kurzhaarrocker was thinking about buying cypress
13.55.25 #       <Zagor> haha ok 
13.57.08 Join    Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se)
13.58.32 #       <dwihno> Cypress hill! \o/
13.59.23 #       <kurzhaarrocker> One Cypress should do. Or do we need a whole forest?
14.01.31 #       <LinusN> we just need some seeds
14.01.50 #       <LinusN> and then we just wait a few generations :-)
14.02.28 #       <[IDC]Dragon> if only buying a box would be enough...
14.02.46 #       <Zagor> [IDC]Dragon: have you got the ondio yet?
14.02.59 #       <[IDC]Dragon> Zagor bought an AV3x0 long time ago, still no Rockbox on it
14.03.14 #       <[IDC]Dragon> Zagor: not yet :-(
14.03.29 #       <[IDC]Dragon> looks like it won't reach here today
14.04.33 #       <LinusN> it took 2 days for my fm recorder to go from USA to Sweden, but it took almost a week to get it through customs...
14.05.00 #       <[IDC]Dragon> no customs this time, it's from germany
14.05.18 #       <kurzhaarrocker> You should ship those things without good music on int, LinusN
14.05.27 #       <kurzhaarrocker> -t
14.05.57 #       <LinusN> it was new, with only those default french crap songs on it
14.06.15 #       <[IDC]Dragon> repairing mp3 players must be a good source of music
14.06.21 #       <LinusN> indeed
14.06.30 #       <[IDC]Dragon> maybe I should open up my shop
14.06.42 #       <LinusN> the "send me your songs for analysis" scheme works good for me :-)
14.06.55 #       <[IDC]Dragon> :-/
14.07.42 #       <kurzhaarrocker> With french songs its different. Quarantine. They must be relabledt to "Freedom Songs".
14.11.16 #       <Zagor> [IDC]Dragon: i admit i bought the av a bit early :)
14.13.04 #       <Zagor> [IDC]Dragon: if you like, the rockbox fund can sponsor the ondio
14.14.18 #       <[IDC]Dragon> whoa, what a nice fund
14.14.43 #       <[IDC]Dragon> to be fair, let's wait awhile if this proves fruitful
14.14.55 #       <Zagor> ok
14.15.14 #       <[IDC]Dragon> (before my wishes soar too high)
14.16.08 #       <[IDC]Dragon> in case of success, we can direct new Ondio Rockbox user to the donate button
14.16.21 #       <[IDC]Dragon> s/user/users
14.16.31 #       <Zagor> there's more than one? ;)
14.16.41 #       <[IDC]Dragon> not yet ;-)
14.16.59 #       <[IDC]Dragon> read: "Ondio Rockbox users"
14.21.24 #       <kurzhaarrocker> I hope you are talking about the ondio recorder?
14.22.14 #       <[IDC]Dragon> I ordered a recorder, yes
14.22.45 #       <kurzhaarrocker> good.
14.23.56 #       <[IDC]Dragon> that can be a nice thing about a flash recorder: no moving parts, no noise in the internal mic
14.24.41 #       <[IDC]Dragon> 1 GB MMC cards are less than 100 Euro nowadays, I was surprised
14.25.16 #       <[IDC]Dragon> (don't tell me I can get a 40 GB disk for that)
14.25.30 #       <kurzhaarrocker> well Archos proved that it is possible to have unbearable noise even without moving parts. I hope they improved.
14.25.55 #       <[IDC]Dragon> is it so bad?
14.26.30 #       <kurzhaarrocker> Rockbox improved it a lot.
14.26.42 #       <kurzhaarrocker> It was because of the crappy lcd programming.
14.26.48 #       <[IDC]Dragon> when? with what hardware?
14.26.57 #       <kurzhaarrocker> The normal Recorder 6
14.27.32 #       <kurzhaarrocker> With the original archos hardware you'd hear and record every lcd refresh. With rockbox it was ok.
14.27.47 #       <kurzhaarrocker> (still not the best recording device I ever had...)
14.28.00 #       <[IDC]Dragon> always, or gradually improving?
14.28.21 #       <kurzhaarrocker> I don't remember any of that trouble with rockbox anywhen.
14.28.33 #       <dwihno> crappy lcd programming?
14.28.42 #       <[IDC]Dragon> I'm asking because our LCD access is a lot faster since video
14.28.54 #       <kurzhaarrocker> dwihno not in rockbox of course :)
14.29.03 #       <[IDC]Dragon> about factor of 4
14.29.51 Join    wildstoo [0] (~d512f815@labb.contactor.se)
14.29.53 #       <dwihno> kurzhaarrocker: nah, rockbox lcd code is da shiznat! :)
14.29.55 #       <kurzhaarrocker> I must admit that I probably haven't used recording with Rockbox after January 2004 because I use a special build with trigger included.
14.30.15 #       <LinusN> [IDC]Dragon: that was one of the first things we noticed when we developed rockbox, that the noise was gone
14.30.53 #       <[IDC]Dragon> nice. Have you ever held a scope to the LCD clock with Archos s/w?
14.31.00 #       <LinusN> nope
14.31.02 #       <wildstoo> hi. i recently acquired an Archos Studio 20 with an 80GB HD upgrade.. problem is, WinXP will not format drives that are greater than 32GB as FAT32.
14.31.12 #       <LinusN> wildstoo: tough luck :-)
14.31.29 #       <[IDC]Dragon> use Paragon or other tools to format
14.31.34 #       <Bagder> windows is a fine OS *really*
14.31.37 #       <LinusN> i think some of the partitioning tools out there can help you with that
14.31.39 #       <Bagder> ;-)
14.31.40 #       <wildstoo> anyone know of any (free) tools that will allow me to format a partition on a USB drive as FAT32 under WinXP?
14.31.49 #       <dwihno> wildstoo: get that software
14.31.54 #       <[IDC]Dragon> Paragon did it for me
14.32.07 #       <LinusN> i use paragon as well
14.32.10 #       <[IDC]Dragon> the free demo version was sufficient
14.32.33 #       <wildstoo> ok i'll look at Paragon, thanks
14.33.04 #       <dwihno> what was it 
14.33.04 #       <dwihno> paragon partition something
14.33.04 #       <dwihno> it is neat
14.33.04 DBUG    Enqueued KICK dwihno
14.33.04 #       <dwihno> and you can do it with the demo ver
14.33.55 #       <wildstoo> $50 :(
14.34.14 #       <[IDC]Dragon> http://kb.paragon.ag/paragon/templ/169.jsp?catId=3283
14.34.15 #       <wildstoo> uh.. site says that demo version doesn't let you do any actual operations
14.34.29 #       <wildstoo> just play with the UI and see how things MIGHT work if you registered
14.34.45 Quit    wildstoo (Client Quit)
14.34.52 Join    wildstoo [0] (~d512f815@labb.contactor.se)
14.35.04 #       <wildstoo> lol clicked a link and got navigated away
14.35.10 #       <wildstoo> should have seen that coming really
14.35.10 #       <kurzhaarrocker> Do you have knoppix?
14.35.27 #       <wildstoo> (on CGI IRC, firewalled here)
14.35.38 #       <Zagor> try ranish partition manager: http://www.ranish.com/part/  it's definitely free
14.35.45 #       <wildstoo> nope
14.35.49 #       <wildstoo> but i could get it
14.41.20 #       <Bagder> syncing 20GB music takes a while
14.41.42 #       <kurzhaarrocker> Just imagine you had to do it in real-time, Bagder
14.41.50 #       <Bagder> hehe
14.42.03 #       <Lynx_> wildstoo: are you sure windos xp can't do that?
14.42.16 #       <Bagder> Lynx_: yes, many people have claimed this
14.43.11 #       <LinusN> XP can do it, but it won't let you
14.43.17 #       <kurzhaarrocker> Lynx_ only Win95 / Win98 can do it. Upgrading sometimes is not an improvement.
14.44.02 #       <LinusN> microsoft want to promote NTFS, so they limit the usage of FAT32
14.44.04 ***     Saving seen data "./dancer.seen"
14.45.13 #       <Bagder> rockbox is so lame that hasn't switched to ntfs yet
14.45.18 #       <wildstoo> well, FAT32 is a bit crap in many ways
14.45.26 Part    Zagor
14.45.44 #       <wildstoo> roll on WinFS ;)
14.46.18 #       <Bagder> I read they won't include that
14.46.31 Ctcp    Ignored 1 channel CTCP requests in 0 seconds at the last flood
14.46.31 #       * kurzhaarrocker wants a portable mp3 player with 5 1/4" floppy.
14.47.04 #       <[IDC]Dragon> maybe you find an ATA floppy, just connect it then
14.47.42 Join    dwihno_ [0] (~dw@81.8.224.89)
14.47.47 Quit    dwihno (Read error: 60 (Operation timed out))
14.49.40 #       <wildstoo> it doesn't matter what drive label you give the drive, does it?
14.49.53 #       <wildstoo> doesn't have to be called JUKEBOX or ARCHOS or something, does it?
14.49.54 #       <Bagder> nope
14.49.55 #       <LinusN> no
14.50.35 #       <[IDC]Dragon> just reading the Ondio manual, the firmware doesn't look bad
14.50.38 #       <[IDC]Dragon> http://www.minidisc.org/manuals/archos/archos_ondio.pdf
14.50.51 #       <[IDC]Dragon> maybe it doesn't need Rockbox?
14.51.02 #       <wildstoo> *sigh* 80GB HD over a USB connection = about 24 hours to format it
14.51.07 #       <Lynx_> wait a minute, i just remember if formated my box from xp home two weeks ago...
14.51.27 #       <[IDC]Dragon> do a quick format
14.51.39 #       <Lynx_> sure does work for me, xp offers ntfs and fat32
14.51.49 #       <[IDC]Dragon> else this is no-go, tha batteries won't last 24 hours
14.51.54 #       <Lynx_> maybe the drive has to be fat32 to begin with, though
14.52.05 #       <wildstoo> i have it connected to mains
14.52.23 #       <wildstoo> XP offers FAT32 if the drive is less than 32GB in size
14.52.25 #       <[IDC]Dragon> still, this supplies less power than the disk needs
14.52.29 #       <wildstoo> mine is 80GB
14.52.37 #       <Lynx_> wildstoo: ah, that's it...
14.52.38 #       <[IDC]Dragon> so you will drain the batteries
14.53.21 #       <wildstoo> well i copied stuff off it for about 12 hours yesterday and it didn't die
14.53.24 #       <wildstoo> and it's still alive now
14.53.39 #       <[IDC]Dragon> very surprising...
14.54.01 #       <[IDC]Dragon> what model?
14.54.08 #       * kurzhaarrocker is glad that he has a 2 1/2" -> 3 1/2" adapter...
14.54.45 #       <wildstoo> um.. Archos Studio 20
14.55.12 #       <[IDC]Dragon> do the studios have a stonger charger?
14.55.19 #       <wildstoo> if you mean the HD itself i have no idea of the model :)
14.55.22 #       <[IDC]Dragon> stronger
14.55.51 #       <wildstoo> no idea.. it doesn't even show a battery symbol when it's connected to USB anyway
14.55.54 #       <wildstoo> so there's no way to tell
14.58.57 #       <wildstoo> gets pretty toasty when it's running all night connected to mains
14.59.07 #       <wildstoo> :)
15.11.08 Quit    Bagder ("Leaving")
15.11.32 Quit    wildstoo ("CGI:IRC (EOF)")
15.13.34 Join    paultje3181 [0] (~83d3e218@labb.contactor.se)
15.14.01 #       <paultje3181> hi, how can I view JPG's using rockbox?
15.14.15 #       <paultje3181> player version, today's build
15.14.48 #       <kurzhaarrocker> The player doesn't have a graphical lcd and can not display jpg's :(
15.14.55 #       <paultje3181> pity
15.15.04 #       <paultje3181> no bmp's as well?
15.15.17 #       <kurzhaarrocker> No graphix at all, only text.
15.15.21 #       <paultje3181> damn
15.15.36 #       <paultje3181> I should've bought the recorder :P
15.15.43 #       <kurzhaarrocker> :)
15.16.15 #       <paultje3181> I'll try to get text working then
15.16.33 #       <paultje3181> haven't tested it yet, but rockbox sure is great
15.23.43 #       <paultje3181> a smaller font isn't possible as well I guess?
15.24.20 #       <kurzhaarrocker> You guessed right
15.24.43 #       <[IDC]Dragon> you can move the box further away
15.24.48 #       <paultje3181> :P
15.25.12 #       <paultje3181> I meant to get more text on the display :D
15.25.52 #       <paultje3181> what I pity, now I can get RSI from reading Harry Potter on my jukebox :p
15.26.30 #       <kurzhaarrocker> lol! 
15.26.48 #       <paultje3181> well, I'm off reading :P
15.26.57 #       <paultje3181> thnx for the info!
15.27.01 #       <lImbus> lol @ [IDC]Dragon
15.27.02 #       <kurzhaarrocker> no problem
15.27.38 Quit    paultje3181 ("CGI:IRC (EOF)")
15.27.46 #       <[IDC]Dragon> funny guy
15.27.46 Nick    dwihno_ is now known as dwihno (~dw@81.8.224.89)
15.28.04 #       <[IDC]Dragon> jpeg on a player, rotfl
15.28.20 #       <kurzhaarrocker> Maybe we should have advised him to read the faq instead of harry potter on the player...
15.28.55 #       <kurzhaarrocker> Well with those user definable characters there in fact could be a way to visualize jpgs...
15.29.09 #       <[IDC]Dragon> certainly, and video
15.29.48 #       <[IDC]Dragon> if you redefine them at exacly the time they are displayed
15.30.34 #       <kurzhaarrocker> ... and by synchronizes shaking you might even increase the display area...
15.30.46 #       <[IDC]Dragon> ah, yes
15.31.23 #       <[IDC]Dragon> and by syncing to external RGB light pulsed you'll get color
15.31.34 #       <kurzhaarrocker> yay! :D
15.31.58 #       <[IDC]Dragon> maybe 3D if you move it back and forth, too
15.32.27 #       <kurzhaarrocker> Now let's find a hard drive that survives that treatment.
15.33.57 #       <kurzhaarrocker> After watching "lord of the rings" with that method you don't need a fitness center any more.
15.35.18 #       <[IDC]Dragon> i'm off
15.35.23 Part    [IDC]Dragon
15.56.14 Part    LinusN
15.56.24 Part    kurzhaarrocker
16.14.33 Join    edx [0] (edx@p548792DE.dip.t-dialin.net)
16.18.25 Join    dwihno_ [0] (~dw@81.8.224.89)
16.30.57 Quit    dwihno (Read error: 110 (Connection timed out))
16.44.06 ***     Saving seen data "./dancer.seen"
16.54.24 Join    methangas [0] (methangas@0x50a476c8.virnxx10.adsl-dhcp.tele.dk)
16.54.24 Quit    lImbus (Read error: 54 (Connection reset by peer))
17.06.59 Nick    dwihno_ is now known as dwihno (~dw@81.8.224.89)
17.16.35 Join    dwihno_ [0] (~dw@81.8.224.89)
17.24.32 Join    lImbus [0] (~manuel@kernel.cycos.net)
17.34.39 Quit    dwihno (Read error: 110 (Connection timed out))
17.39.08 Join    midk [0] (~midk@c-24-18-39-204.client.comcast.net)
17.40.30 Quit    midk|sleep (Read error: 104 (Connection reset by peer))
17.42.44 Join    dwihno__ [0] (~dw@81.8.224.89)
17.51.51 Join    epictetus [0] (uifils@otto.microway.com)
17.54.15 Join    dwihno [0] (~dw@81.8.224.89)
17.59.27 Quit    hardeep ("[BX] Connection reset by panasync?")
18.04.38 Quit    dwihno_ (Read error: 110 (Connection timed out))
18.10.43 Quit    dwihno__ (Read error: 110 (Connection timed out))
18.12.17 Join    mecraw [0] (~lmarlow@69.2.235.2)
18.32.22 Join    bagawk [0] (Lee@ACC0E21B.ipt.aol.com)
18.35.23 #       <Lynx_> i just notices something weird: I had the flashed box charging while off. then I turned it on without unplugging it. now if i press off again it displays "battery charging", but that does not go away, and if i do something like move the cursor it smears through the message.
18.35.37 #       <Lynx_> like only the parts the cursor changes are refreshed.
18.35.56 #       <midk> Lynx_, this was recently fixed
18.36.03 #       <midk> upgrade to the latest daily build
18.36.03 #       <Lynx_> ok
18.36.15 #       <Lynx_> thx
18.36.33 #       <midk> np
18.39.44 #       <Lynx_> hehe, the installer says "..while installing rockbox on your computer"
18.41.03 #       <bagawk> :P
18.41.15 #       <bagawk> the installer is a little wierd
18.41.28 #       <midk> :)
18.41.33 #       <bagawk> it also adds an item to your add/remove programs list
18.41.34 #       <Lynx_> didn't after upgrading, the box ask if it should rolo the new firmware?
18.41.47 #       <bagawk> yes    do that :)
18.41.54 #       <Lynx_> hehe, didn't even see that. and, does removing work? ;-)
18.41.59 #       <Lynx_> well, it's not asking
18.42.02 #       <bagawk> i have no idea
18.42.34 #       <midk> ?
18.42.47 #       <bagawk> i think i just did it, without my archos connected, and it just said it was removed, with absolutly nothing done
18.42.54 #       <midk> just rolo into the ajbrec.ajz
18.44.10 ***     Saving seen data "./dancer.seen"
18.46.33 #       <Lynx_> hmm, same with just unzipping it. maybe that feature was changed..
18.47.03 #       <midk> it sometimes doesn't work
18.47.06 #       <midk> just do it manually
18.47.35 #       <Lynx_> i did...
18.48.04 #       <midk> now reflash.....
18.50.28 Join    bagawk_ [0] (Lee@ACC06A2A.ipt.aol.com)
18.50.45 #       <Lynx_> thx, but I know that much ;-)
18.51.13 #       <Lynx_> with the video plugin, is there still some value one can adjust to remove flickering?
18.51.44 #       <midk> nope
18.51.57 #       <midk> let it warm up and it doesn't flicker though
18.52.07 #       <midk> just a little band runs across the screen..
18.52.19 Quit    bagawk (Read error: 104 (Connection reset by peer))
18.53.05 Nick    bagawk_ is now known as bagawk (Lee@ACC06A2A.ipt.aol.com)
18.55.18 #       <bagawk> midk: not always for me
18.55.29 #       <bagawk> most of the time i see nothing
18.55.44 #       <bagawk> :)
18.56.04 #       <Lynx_> is there some site where a rvf stuff is collected?
18.56.15 #       <Lynx_> like futurama and such...
18.56.17 #       <bagawk> there are a few on the rocbkx site
18.56.31 #       <bagawk> http://rockbox.haxx.se/newvid
18.56.41 #       <bagawk> there are only a few good ones
18.56.41 #       <midk> not really
18.56.57 #       <midk> http://rockbox.haxx.se/newvid  has a few things
18.57.06 #       <bagawk> doom is ok, futruama is great, baby, and a warm reception in LA suck
18.57.17 #       <bagawk> and grantz graf is kinda cool sometimes
18.58.05 #       <Lynx_> grantz graf?
18.58.21 #       <Lynx_> ah...
18.58.43 #       <Lynx_> and there is a wiki entry on the conversion tools
18.59.08 Join    pike [0] (amiga@h234n1fls22o1064.bredband.comhem.se)
19.02.39 #       <Lynx_> cu all
19.02.45 Quit    Lynx_ (" Like VS.net's GUI?  Then try HydraIRC -> http://www.hydrairc.com <-")
19.02.45 #       <pike> Hello Felix, Markus, Lee and anyone else I couldn't find the real name for :)
19.08.52 #       <bagawk> ?
19.09.09 #       <bagawk> do i know you?
19.09.11 #       <bagawk> lol
19.09.47 #       <pike> nah, I came here from your website
19.09.57 #       <pike> did a little reading before
19.10.00 #       <pike> :p
19.10.28 #       <pike> so you guys involved in anyway with this? http://rockbox.haxx.se/twiki/bin/view/Main/IriverInfo
19.16.00 #       <pike> just found this... shame I dont speak japanese http://www.susono.com/~hiroya_d/iRiverJ/Font/
19.18.07 #       <methangas> use babelfish
19.18.19 #       <methangas> if you wanna find out what it can do
19.18.33 #       <methangas> allthough i don't really have a solution to the firmware :P
19.19.10 #       <pike> solution to what?
19.20.00 #       <methangas> getting it translated
19.21.01 #       <pike> aha.. I was just curious what it did. so anyone in here involved in getting rockbox onto ihpX series ? or it's still in the "need more info" stage ?
19.21.58 #       <lImbus> i think they planned to buy a device
19.22.26 #       <lImbus> 'they' found out it's the same usb-bridge
19.22.27 #       <pike> most people in here swedes, or only the founders?
19.23.00 #       <pike> they just cut the price further on ihp120 afaik.
19.23.07 #       <pike> they = irivernordic
19.24.42 #       <lImbus> a few of the founders/core developers are swedish. then there are germans, and a few from everywhere
19.24.42 #       <lImbus> err. I actually think all of the founders are swedish
19.25.12 #       <pike> so am I
19.25.37 #       <pike> H120: förr 3795kr - nu 3499kr and thats directly from them, I think it can probably be found for as little as 3000 sek
19.26.37 #       <pike> thats the unit I have myself, but I'm no viz with electronics, just know how to handle a primitive soldering iron :p
19.28.55 #       <lImbus> tell it Zagor or Bagder. I dunno what they planned
19.29.11 Quit    pike (Read error: 104 (Connection reset by peer))
19.29.58 Join    pike [0] (~amiga@h234n1fls22o1064.bredband.comhem.se)
19.30.05 #       <lImbus> welcome back
19.30.14 #       <pike> xchat crashed.. :p
19.30.53 Join    radu [0] (~radu@face-00000002.user)
19.32.55 #       <pike> so when I read the documentation, the mp3 decoding hardware in the archos only supports mp3, this will probably not be an issue on iriver?
19.40.43 #       <lImbus> yeah, you may be right. I know iriver can do other formats. so either the dsp does or they do in hardware (must have > 100 mHz)
19.40.54 #       <lImbus> err, in software, of course
19.41.13 #       <pike> cpu/dsp faster than 100mhz?
19.42.06 #       <lImbus> cpu
19.42.07 #       <pike> iriver ihpX handles wma, wav and mp3 afaik. no drm though
19.42.39 #       <pike> dream would be lossless and aac support, hehe. but I'll say no more. too early to make wishes
19.42.57 #       <lImbus> isn't wav lossless ?
19.43.20 #       <bagawk> lImbus: yes but not compressed
19.43.24 #       <pike> yeah, but I mean lossless compression, like flac, ape, you know
19.43.35 #       <lImbus> ah, of course
19.43.55 #       <lImbus> if they already to decoding in cpu, then we could give it a try. as well as ogg
19.44.09 #       <lImbus> ogg depending on memory
19.44.32 #       <pike> og yeah, firgot vorbis
19.44.35 #       <pike> forgot*
19.44.44 #       <pike> it's already supported
19.44.51 #       <pike> but a real battery drainer
19.46.19 #       <bagawk> bye
19.46.22 #       <bagawk> : )
19.47.10 Quit    bagawk ("umount /dev/brain")
19.47.14 #       <pike> crappy decoder for vorbis methinks
19.47.35 #       <pike> does rockbox support cuesheets handling now?
19.53.03 Join    hdn [0] (~TapeTape@dyn-83-157-167-218.ppp.tiscali.fr)
19.53.06 #       <hdn> lut
19.54.07 #       <lImbus> pike: what's a cuesheet ?
19.54.32 #       <pike> it's an invetion that CDRWIN makers created
19.55.05 #       <pike> it's a textfile basically desrcibing the layout for a cd, an instruction how it should be burned, with track separations etc
19.55.37 #       <pike> past years have been used for "mixed" audiocd's, to provide "seamless" playback
19.55.50 #       <pike> winamp supports it via a plugin
19.55.54 #       <pike> foobar has the support builtin
19.55.55 #       <midk> if you rip a cd as one huge mp3 file a cuesheet specifies times for each track, and names i believe etc
19.56.04 #       <pike> ^yep
19.56.13 #       <midk> at 3:17 it's track 2, 7:53 track 3 etc
19.57.04 #       <pike> http://pike2k.mine.nu:8010/201-va_-_dont_look_now_mixed_by_way_out_west-boss.cue
19.57.36 Part    hdn
19.57.48 #       <pike> that cuesheet is faulty
19.57.54 #       <pike> ... the ending shouldnt be there.
19.58.14 #       <pike> mp3 scene has issues with them, or better yet, the tools they use
20.00.57 #       <lImbus> ok, I see. it takes consideration of pre and postroll
20.02.06 #       <pike> "gaps" yeah
20.02.20 #       <pike> now most cuesheets dont include this info, but some do
20.09.50 Join    webguest35 [0] (~0c01350a@labb.contactor.se)
20.10.00 Quit    webguest35 (Client Quit)
20.10.20 Join    webguest83 [0] (~0c01350a@labb.contactor.se)
20.10.38 #       <webguest83> hello
20.11.54 Quit    webguest83 (Client Quit)
20.44.13 ***     Saving seen data "./dancer.seen"
21.03.44 Join    Elemeno [0] (~4givn@dpc691997050.direcpc.com)
21.04.05 #       <Elemeno> hey, has anyone ever replaced the LCD screen on the FM recorder?
21.04.34 #       <midk> yes.
21.04.57 #       <midk> oh, right, you were trying to replace yours.
21.04.58 #       <midk> :)
21.05.19 #       <Elemeno> :-) Yep
21.05.29 #       <midk> having trouble?
21.05.39 #       <Elemeno> I received the new one today, put it in, and it works!
21.05.39 #       <Elemeno> But... I have a question
21.06.20 #       <Elemeno> When I took the original one out, it seemed like it was glued or it somehow stuck to the MP3 player.  so I'm wondering how I should reattach it
21.06.48 #       <midk> your new one is loose?
21.06.52 #       <midk> did you check the page then?
21.07.43 #       <Elemeno> what I mean is the original screen, it seemed like the entire back was somehow glued or something to the white square
21.08.00 Join    _aLF [0] (Alexandre@mutualite-3-82-67-66-128.fbx.proxad.net)
21.08.01 #       <_aLF> hi
21.08.07 #       <Elemeno> and it's just a practical question, I guess, of how to keep the new screen in place.  does that make any sense?
21.08.11 #       <Elemeno> hi
21.10.47 #       <Elemeno> midk:  Basically, I'm trying to figure out how to physically reattach the screen to the Archos once it's plugged in and working
21.11.25 #       <midk> i know what you mean
21.11.30 #       <midk> did you check the doc i gave you?
21.12.31 #       <Elemeno> I think so.  I know there was one page I visited that talked about replacing the LCD screen, but it was for a different model
21.13.58 #       <midk> should be the same method, as it's the same screen
21.14.11 #       <midk> you could just roll up a piece of tape and stick it back there :)
21.14.33 #       <Elemeno> yup.  I'm sure I could get creative.  I was just wondering if there was "a way"
21.14.48 #       <Elemeno> I'm pretty happy to just have my screen working again:-)
21.16.55 #       <Elemeno> now I just have to fix the mic, but I wouldn't think that would be too bad
21.17.22 #       <midk> not really a way :)
21.21.27 Quit    Elemeno ()
21.52.14 Join    scott666_ [0] (~scott666@c-24-245-58-48.mn.client2.attbi.com)
21.52.25 Part    scott666_
21.57.51 Quit    midk (Remote closed the connection)
22.31.52 Quit    methangas (" The IRC Client of the Gods! -> http://www.hydrairc.com <- HydraIRC")
22.44.16 ***     Saving seen data "./dancer.seen"
23.31.52 Quit    lImbus (Remote closed the connection)
23.47.56 Quit    Hadaka (Read error: 238 (Connection timed out))