00:00:11 | MO-Pantsu | I tried your line on it's own. no difference |
00:00:19 | HCl | amiconn: it should probably be possible to uncomment part of the unused tagdatabase support functions |
00:00:33 | amiconn | Bagder: 3.3.1 -> 3.3.5 saves almost 1 KB ... |
00:00:35 | | Join ze [0] (ze@ca-dstreet-cuda2-c9a-73.snbrca.adelphia.net) |
00:00:39 | HCl | i'm planning to use them later in order to be able to add fileentries to the tagdatabase on the fly |
00:00:43 | | Join p3druskus [0] (~petru@37.Red-80-37-10.pooles.rima-tde.net) |
00:00:59 | amiconn | HCl: That might be helpful |
00:01:07 | MO-Pantsu | does your next track scroll too with 'artist - title'? |
00:01:10 | Coldtoast | with my line, it displays "unknown artist -" on teh first track til it gets past the frst 2MB barrier. Then it loads the correct info and fills it in. When the track changes, it changes to the new info |
00:01:13 | Coldtoast | and all scrolls |
00:01:47 | HCl | gah. too many interesting programs on discovery channel |
00:01:50 | Coldtoast | you know that lines like this: |
00:01:53 | * | HCl just turns it off before he starts to watch it |
00:01:54 | amiconn | I hope that [IDC]Dragon finishes bootbox testing some day. Then rombox shouldn't be a problem anymore on all archoses |
00:01:56 | Coldtoast | Artist. %s%?ia<%ia|%?d2<%d2|[\root]>> %?ig<(%ig)|%t0> |
00:02:03 | Coldtoast | scrolsl teh WHOLE line? |
00:02:07 | HCl | whats bootbox? |
00:02:18 | Coldtoast | you don't get static "Artist" with scrolling artist name |
00:02:30 | Coldtoast | the whole line including "Arttist" scrolls |
00:02:48 | amiconn | On archos, we have a dual-boot bootloader also developed by [IDC]Dragon which allows to boot 2 different firmwares from flash |
00:03:25 | amiconn | Any of the 2 can be either compressed (then it needs to be uncompressed into ram before execution) or uncompressed and executed directly from rom |
00:03:51 | Coldtoast | btw MO-Pantsu |
00:04:00 | amiconn | The first image serves as a backup and is only started if you hold a button while booting |
00:04:01 | Coldtoast | you can actually alter a few of your conditionals |
00:04:18 | amiconn | In our current flash packages this first image is the archos firmware, compressed |
00:04:26 | Coldtoast | you don't need things like ?%Ia<%a|> |
00:04:34 | MO-Pantsu | I just need a line that works....sigh |
00:04:38 | amiconn | The second image, which is started normally, is usually rockbox |
00:04:46 | Coldtoast | oops |
00:04:57 | Coldtoast | I mean ?Ia<%Ia|> |
00:05:11 | Coldtoast | just use ?Ia<%Ia> |
00:05:12 | amiconn | 'rombox' means uncompressed rockbox, executed directly from rom and hence leaving some more free ram for buffering etc |
00:05:33 | Coldtoast | "The else part is optional, so the "|" does not have to be |
00:05:33 | Coldtoast | specified if no else part is desired. |
00:05:36 | Coldtoast | " |
00:05:39 | Coldtoast | that's from teh docs |
00:05:40 | amiconn | The problem is that this isn't possible on all units due to space constraints |
00:05:44 | MO-Pantsu | I have aq headache now |
00:05:47 | amiconn | (the rom is only 256KB) |
00:05:59 | MO-Pantsu | can't be bothered anymore |
00:06:06 | MO-Pantsu | if it's some weird bug it's evading me |
00:06:37 | Coldtoast | here |
00:06:54 | Coldtoast | accept the dcc |
00:07:06 | MO-Pantsu | it's not downloading for some reason hold on |
00:07:08 | amiconn | So [IDC]Dragon works on replacing the alternate firmware image (the archos one) with a stripped-down rockbox which is only able to charge (for archoses which have software controlled charging), allow USB access, and boot from HD |
00:07:09 | | Quit MO-Pantsu () |
00:07:11 | Coldtoast | this works on mine |
00:07:16 | amiconn | *This* is bootbox |
00:07:22 | | Join Rori [0] (MO-Pantsu@deadman3000.plus.com) |
00:07:34 | Rori | try again |
00:07:53 | Coldtoast | nup |
00:07:58 | Rori | ah just paste the damned thing |
00:08:10 | Coldtoast | heh |
00:08:30 | Coldtoast | there you go |
00:10:46 | amiconn | HCl: Could you please disable the unused parts for now? |
00:11:15 | HCl | kay. |
00:11:29 | amiconn | Hmm. |
00:11:37 | | Join Stryke` [0] (~Chairman8@cpe-24-168-110-99.si.res.rr.com) |
00:12:57 | amiconn | The unused functions are only for updating the tagdb on the target, or is there more? |
00:13:22 | HCl | committed |
00:13:27 | HCl | nope, thats it |
00:13:36 | amiconn | tnx :) |
00:13:48 | amiconn | Let's see if that brings back my rombox.... |
00:13:57 | * | HCl goes to shower |
00:14:02 | amiconn | ...at least temporrily |
00:17:39 | Coldtoast | can you add a parameter to .wps so you can display %ff in KHz as well? |
00:18:24 | Bagder | yes you can |
00:18:59 | amiconn | Rombox isn't back :( |
00:19:11 | amiconn | Output is 524 bytes larger than max (192496) |
00:19:33 | Bagder | then hardeep's next-dir thing is probably those ~500 bytes |
00:19:57 | amiconn | Must be more |
00:20:37 | HCl | runtime database is still a fair amount of extra code.. |
00:20:56 | amiconn | I guess your gcc 3.3.1 will give ~1500 bytes too much, but rombox was possible before even with that gcc |
00:21:20 | Bagder | Output is 644 bytes larger than max (192496) |
00:21:35 | amiconn | Uh? Interesting... |
00:21:41 | Bagder | very! |
00:21:46 | amiconn | Why is that? |
00:22:13 | amiconn | I would expect a roughly proportional decrease |
00:23:21 | amiconn | I know that it would bring rombox back if I compile with -Os (and I know the fix to make it run with that -O option) |
00:23:45 | amiconn | ...but I don't think that we want -Os |
00:24:15 | Coldtoast | Bagder: did you say you CAN get %ff to display as KHz? |
00:24:26 | Bagder | sure, just write the code |
00:24:50 | Coldtoast | heh. if I were conversant in C, I'd love to |
00:25:39 | | Quit Stryke` ("Friends don't let friends listen to Anti-Flag") |
00:26:02 | HCl | gnight |
00:27:06 | Bagder | good idea |
00:33:19 | | Quit spiralout (Read error: 131 (Connection reset by peer)) |
00:43:52 | | Join TCK [0] (TCK@81-86-98-63.dsl.pipex.com) |
00:45:45 | | Join bug_ol_paul32432 [0] (~d1ced0bc@labb.contactor.se) |
00:46:48 | bug_ol_paul32432 | what is the easiest way to reset ur iriver?? |
00:48:54 | | Quit bug_ol_paul32432 (Client Quit) |
00:49:08 | Rori | OK guys. Me and Coldtoast have been testing the next track thing and I have a weird problem |
00:51:11 | Rori | for some reason I can't get next track artist to display when playing the first track. Ever. Not even if I wait until the end of the track. Yes the condition is in there as advised by the wps docs |
00:51:38 | Rori | yes there is an id3 tag and tried swapping id3v1 to v2 and back |
00:52:06 | Rori | ONLY if I FF a little on the first track played does it then display the artist for the next track |
00:52:33 | Rori | It always shows the title when it buffers part way through the first track but never the artist for the next track unless I FF |
00:53:12 | Coldtoast | yeah. on my player I get the info right near the end but when he does exactly the same thing I do, his doesn't do it |
00:54:23 | Rori | using his wps btw |
00:54:28 | Rori | just to make sure |
00:54:33 | Rori | tried various tracks |
00:54:59 | Rori | they have correct ID3 tag info. using clean latest build of rockbox. Odd eh? |
00:55:30 | Rori | the fact it reads the tag for artist after I FF makes it even odder |
00:55:53 | amiconn | The tag is read always |
00:56:06 | Rori | it's just not displaying if I let it play |
00:56:17 | amiconn | I think there is a bug in wps code that it doesn't detect the info changed and the display should be updated |
00:56:18 | Rori | only when it gets to track 2 it then shows artist correctly for track 3 |
00:56:33 | Rori | yep methinks so too |
00:56:51 | Rori | that bug has been driving me crazy for 2 days |
00:57:13 | Rori | wondering why I could not get next track info to display correctly |
00:57:29 | Coldtoast | I better head to be. it's 9am |
00:57:46 | | Quit Coldtoast ("Peace and Protection 4.22") |
00:57:50 | Rori | thanks for the help |
00:58:04 | Rori | at least I know it's not me being dumb |
01:00 |
01:09:01 | | Join webguest72 [0] (~d49f4cf2@labb.contactor.se) |
01:09:07 | | Join n0bby [0] (~fake@40-218.207-68.tampabay.res.rr.com) |
01:17:15 | | Quit Rick (Read error: 104 (Connection reset by peer)) |
01:17:29 | | Quit Ancelot () |
01:18:11 | | Join Rick [0] (~rick@pool-71-108-23-179.lsanca.dsl-w.verizon.net) |
01:18:49 | | Quit Harpy (Read error: 145 (Connection timed out)) |
01:22:40 | | Quit webguest72 ("CGI:IRC") |
01:25:24 | | Join wlad [0] (wlad@200.139.133.172) |
01:30:22 | Rori | is the top line always off limits for wps? |
01:46:55 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
01:46:56 | | Quit n0bby (Read error: 104 (Connection reset by peer)) |
01:47:32 | *** | Saving seen data "./dancer.seen" |
01:55:09 | | Quit p3druskus ("leaving") |
01:55:46 | | Part Moos |
01:58:19 | | Quit hicks (Remote closed the connection) |
02:00 |
02:01:05 | amiconn | Argh! The runtimedb handling is bad bad bad! :( |
02:01:21 | amiconn | It causes a spinup for *every* track change! |
02:17:56 | | Join PaulJ_ [0] (~PaulJ@vpn-3005.gwdg.de) |
02:19:03 | | Quit PaulJ_ (Remote closed the connection) |
02:19:09 | | Join amiconn_ [0] (~jens@p54BD515E.dip.t-dialin.net) |
02:22:01 | thegeek | shame on you HCl |
02:22:04 | thegeek | ;p |
02:23:15 | | Quit amiconn (Nick collision from services.) |
02:23:15 | | Nick amiconn_ is now known as amiconn (~jens@p54BD515E.dip.t-dialin.net) |
02:26:35 | * | amiconn is severely annoyed by the runtimedb code |
02:26:52 | * | amiconn goes to sleep |
02:29:21 | | Join n0bby [0] (~fake@36-219.207-68.tampabay.res.rr.com) |
02:34:24 | | Quit courtc (Read error: 110 (Connection timed out)) |
02:35:03 | | Quit PaulJ (Read error: 113 (No route to host)) |
02:36:07 | wlad | anyone here know where does the damm ATJ2085 MCU boots on? (rom address) |
02:48:26 | n0bby | nope |
02:48:28 | n0bby | i wouldnt anywat |
02:48:33 | n0bby | -t +y |
02:50:20 | wlad | =( |
02:50:35 | wlad | there is absolutely no info on that chip ... |
02:50:50 | wlad | just a very imcomplete datasheet ..... |
02:52:58 | | Join kenshin_ [0] (~dave@c-24-17-8-193.hsd1.wa.comcast.net) |
02:54:59 | | Nick wlad is now known as wladston (wlad@200.139.133.172) |
02:57:28 | | Quit wladston () |
03:00 |
03:04:24 | | Join wacky_ [0] (~wacky@modemcable011.4-37-24.mc.videotron.ca) |
03:04:39 | wacky_ | hey guys, do you know a way to have warnings and errors highlighted in a bash shell, while running gcc ? |
03:05:00 | kenshin_ | nope. never seen a way to do that. |
03:05:48 | kenshin_ | but usually gcc just bombs on errors (making them obvious) and warnings are usually okay to skip |
03:05:50 | wacky_ | I've seen that on a friend's computer, it was all highlighted.. and he didn't do anything really weird, it was by default on a Mandriva distro... |
03:08:58 | wacky_ | there must be a package that tweaked /etc/profile.d in some way ?! |
03:09:47 | kenshin_ | i've only seen highlighting on the bash prompt and ls |
03:12:18 | kenshin_ | Mandriva may have customized bash to recognize gcc errors and warnings |
03:13:10 | | Quit skel_ (Remote closed the connection) |
03:13:34 | kenshin_ | and i don't see any gcc options to do this |
03:15:50 | wacky_ | oh :) just installed gcc-colorgcc :) |
03:15:55 | wacky_ | it's a perl wrapper that colorizes the output :) |
03:15:55 | wacky_ | nice |
03:19:04 | | Quit n0bby (Read error: 110 (Connection timed out)) |
03:24:30 | | Part wacky_ |
03:37:49 | | Join tvelocity [0] (~tony@ipa201.6.tellas.gr) |
03:47:34 | *** | Saving seen data "./dancer.seen" |
04:00 |
04:00:18 | | Quit Rick ("I… don't need to be here.") |
04:00:31 | | Join Rick [0] (rick@pool-71-108-23-179.lsanca.dsl-w.verizon.net) |
04:01:11 | | Quit Rick (Client Quit) |
04:01:22 | | Join Rick [0] (rick@pool-71-108-23-179.lsanca.dsl-w.verizon.net) |
04:06:08 | | Join QT_ [0] (as@area51.users.madwifi) |
04:09:01 | | Quit ShockerEngr (Read error: 145 (Connection timed out)) |
04:17:34 | | Quit QT (Read error: 113 (No route to host)) |
04:17:38 | | Quit kenshin_ (Read error: 110 (Connection timed out)) |
04:17:43 | | Quit xen` (Read error: 110 (Connection timed out)) |
04:20:10 | Rori | anyone fancy tackling that wps updating display bug? :) |
04:59:07 | | Join Leperkawn [0] (~chatzilla@68-188-193-92.dhcp.mrqt.mi.charter.com) |
05:00 |
05:02:42 | | Join n0bby [0] (~fake@40-218.207-68.tampabay.res.rr.com) |
05:15:59 | | Join kenshin_ [0] (~dave@c-24-17-8-193.hsd1.wa.comcast.net) |
05:17:08 | Leperkawn | So, what are your opinions on me getting a h3x0 through those free dealies and sending it to the rockbox devs? |
05:24:26 | kenshin_ | the devs who need the 3x0 (for writing the bootloader) already have them |
05:26:33 | Leperkawn | Ah. |
05:26:39 | Leperkawn | Well, then. |
05:26:45 | Leperkawn | I will just have to sit by and wait. |
05:32:00 | kenshin_ | have no fear, development is in progress |
05:34:29 | | Quit n0bby (Read error: 110 (Connection timed out)) |
05:47:35 | *** | Saving seen data "./dancer.seen" |
05:56:29 | | Join bagawk [0] (1000@bagawk.user) |
05:59:08 | | Quit Leperkawn ("Chatzilla 0.9.68.5 [Firefox 1.0.4/20050511]") |
06:00 |
06:13:50 | | Quit kenshin_ (Read error: 110 (Connection timed out)) |
06:29:45 | | Quit bagawk ("Leaving") |
06:43:13 | | Join cYmen_ [0] (~cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
06:44:05 | | Quit cYmen (Read error: 104 (Connection reset by peer)) |
06:53:03 | | Join ashridah [0] (ashridah@220-253-123-32.VIC.netspace.net.au) |
07:00 |
07:03:01 | | Join ehntoo [0] (~noclue2@24-177-147-34.dhcp.mrqt.mi.charter.com) |
07:39:12 | | Join gshgs [0] (patriarch@g228051.upc-g.chello.nl) |
07:47:38 | *** | Saving seen data "./dancer.seen" |
07:54:58 | | Quit Seed (Read error: 104 (Connection reset by peer)) |
07:56:49 | | Join Harpy [0] (slkDk7tNlI@dsl-hkigw7wbb.dial.inet.fi) |
07:59:14 | | Join Seed [0] (ben@l192-117-115-168.broadband.actcom.net.il) |
08:00 |
08:02:09 | | Quit Seed (Read error: 104 (Connection reset by peer)) |
08:06:09 | | Join Seed [0] (ben@l192-117-115-168.broadband.actcom.net.il) |
08:06:34 | | Join tiegs [0] (~18e15776@labb.contactor.se) |
08:07:10 | | Quit tiegs (Client Quit) |
08:13:51 | | Join AEnertia [0] (~aenertia@210.54.152.120) |
08:27:06 | | Join StrathAFK [0] (~mike@dgvlwinas01pool0-a204.wi.tds.net) |
08:34:50 | | Quit Seed (Read error: 104 (Connection reset by peer)) |
08:41:44 | | Join Seed [0] (ben@l192-117-115-168.broadband.actcom.net.il) |
08:45:08 | | Quit Thasp_ (Read error: 101 (Network is unreachable)) |
08:51:24 | | Quit Strath (Read error: 110 (Connection timed out)) |
08:56:29 | | Quit Harpy (Read error: 145 (Connection timed out)) |
08:58:57 | | Quit gshgs (Read error: 110 (Connection timed out)) |
09:00 |
09:03:31 | | Nick QT_ is now known as QT (as@area51.users.madwifi) |
09:09:40 | | Nick StrathAFK is now known as Strath (~mike@dgvlwinas01pool0-a204.wi.tds.net) |
09:26:54 | | Quit ehntoo ("Leaving") |
09:32:39 | | Quit pabs (Read error: 60 (Operation timed out)) |
09:47:40 | *** | Saving seen data "./dancer.seen" |
10:00 |
10:08:56 | | Join einhirn [0] (Miranda@carlsberg.heim2.tu-clausthal.de) |
10:13:55 | | Join Thasp [0] (Thasp@151.205.127.205) |
10:21:40 | | Quit TCK (Read error: 104 (Connection reset by peer)) |
10:30:34 | | Join webguest57 [0] (~d1ced0f8@labb.contactor.se) |
10:31:16 | webguest57 | hello |
10:32:42 | webguest57 | i have a question or rahter want your opinion |
10:34:47 | webguest57 | what bmp wps do you think is the best\ |
10:50:06 | HCl | amiconn: ofcourse it causes a spinup for every track, it needs a binary search to locate the runtime record for the track, and people didn't want the database in ram, also, it needs to save the runtime database whenever it changes, cause it has to happen before the unit will be powered off |
10:51:16 | amiconn | I know *why* it happens with the current design, however, you should try to find a way to do without it |
10:51:33 | HCl | how? O.o. |
10:51:34 | amiconn | ...and *not* holding the whole db in RAM |
10:51:53 | amiconn | The current behaviour is inacceptable imho |
10:52:21 | amiconn | Rockbox tries to save as much battery as possible by prebuffering, and the runtime database destroys this concept |
10:52:24 | HCl | well it could probably cache runtime data in the same way it buffers the audio |
10:52:43 | amiconn | ...and it is not even deactivatable if a valid tag database is found :( |
10:53:22 | amiconn | That's why I didn't further research the integration on archos although it seems that should be easy |
10:53:28 | HCl | i have no idea how we would go around to caching the runtime info though |
10:53:37 | HCl | maybe the runtime info can be added to the id3 info? |
10:53:53 | amiconn | Hmm, that sounds like a possible way |
10:54:07 | HCl | iirc, on archos, it will still require it to save every time the data changes, cause it can shut down too fast? |
10:54:35 | amiconn | The playback code (playback.c on iriver, mpeg.c on archos) stores id3 info and associated data for a number of tracks |
10:54:47 | HCl | mhm |
10:55:00 | HCl | well, you'd just have to move the loading to that, i guess |
10:55:27 | amiconn | ...so the runtimedb code could put the runtime info into that (or even better imho, the playback code itself could update the runtime info field) |
10:55:27 | HCl | but it would still need to write to the rundatabase every time so that data isn't lost before shutting dwon |
10:55:31 | HCl | down |
10:56:01 | amiconn | ...and then call the function to update the runtime database (mutliple entries) when it is rebuffering |
10:56:14 | amiconn | ...or stopping |
10:56:35 | HCl | wasn't there something with archos having a hardware turnoff thing? |
10:56:48 | HCl | and rockbox not having time to do things before shutting down? |
10:56:51 | HCl | or am i mistaken |
10:56:51 | amiconn | Yes, but you should ignore that |
10:56:56 | HCl | why? |
10:57:24 | amiconn | There are 2 targets (archos player and recorder v1) which have a fast hardware shutdown (~ 1 sec) |
10:57:33 | HCl | mk |
10:57:45 | amiconn | All others have a much longer delay, so we do software shutdown as on the iriver |
10:57:55 | amiconn | (rec fm, rec v2, ondiops) |
10:57:59 | amiconn | *ondios |
10:58:20 | amiconn | They still have a hardware shutdown, but that requires to hold the button > 10 seconds |
10:58:24 | HCl | well, my suggestion is then to add all the info the runtime database needs about a file to the id3 tag thing |
10:58:35 | amiconn | Think of it as the archos equivalent of the iriver reset button |
10:58:55 | HCl | like file entry info, current file entry offset, runtime info, current runtime entry offset.. |
10:59:27 | amiconn | The units with fast hardware shutdown also have a safe shutdown feature in rockbox, which takes care of flushing all info to disk |
10:59:39 | HCl | k |
10:59:49 | Slasheri | Hmm, on certain situations id3 structs might get cleared before actual buffer refilling |
11:00 |
11:00:00 | HCl | ick |
11:00:03 | HCl | why? |
11:00:03 | amiconn | We can't prevent the user from doing a hw shutdown, but if he does this, it is his own fault if some runtime info gets lost |
11:00:51 | amiconn | HCl: Also keep in mind that the hd spins up more often on archos due to the small RAM, so the potential loss isn't so big |
11:00:58 | Slasheri | HCl: for example with dynamic playlists a flush event causes that behaviour (buffering code clears everything but the current track_info struct) and disk spinup will follow later |
11:01:23 | amiconn | ...and even on iriver there is a potential danger to loose some runtime data - when the battery gets too low |
11:01:31 | * | HCl is a bit confused, but isn't quite awake yet.. |
11:01:35 | amiconn | ...even with your current design |
11:02:25 | HCl | then we could probably just have an array of structures containing that info for each song next to the track info thing? |
11:03:06 | amiconn | Slasheri: The important point would be to call the runtimedb callback *before* any such event processing, be it a normal buffer refill or a flush due to skip, new track selected etc |
11:03:21 | Slasheri | amiconn: Hmm, that is possible |
11:03:38 | amiconn | Of course this menas the runtimedb code shouldn't take too long |
11:03:40 | Slasheri | But i think the database should not flush to disk before the actual spin up is necessary |
11:03:48 | HCl | it doesn't take long at the moment... |
11:04:04 | HCl | the binary search is pretty fast, much faster than i had expected |
11:04:11 | amiconn | That's nice |
11:04:46 | amiconn | I tried to build a tagdb with your java songdb, however it seems this doesn't work with the runtimedb here (??) |
11:05:02 | HCl | it should as long as the generated paths are okay |
11:05:15 | HCl | they should start with a / and follow with the absolute path to a file |
11:05:16 | | Quit webguest57 ("CGI:IRC (EOF)") |
11:05:28 | HCl | you might need to grab the new songdb.jar from the wiki |
11:05:29 | amiconn | May that be caused by the fact that I ran it under windows? The paths are displayed with backslashes.... |
11:05:40 | HCl | nah, i fixed that.. |
11:05:45 | HCl | you probably have an oldish version |
11:05:46 | amiconn | I grabbed the latest one as of today ~1 am |
11:05:49 | HCl | hrm |
11:05:50 | HCl | odd |
11:06:04 | amiconn | Maybe I used −−strip the wrong way? |
11:06:08 | HCl | the slashes should be / and i *know* i fixed that o.o. |
11:06:18 | HCl | i dunno |
11:06:20 | HCl | i run it with.. |
11:06:21 | amiconn | Do I need to strip the drive letter? |
11:06:38 | HCl | well, it does that for you, but if you have −−strip, it should be added there |
11:07:00 | amiconn | Okay, perhaps I should try again... |
11:07:12 | HCl | java -jar SongDB.jar C:\windows\profiles\hcl\desktop\music −−strip c:\windows\profiles\hcl\desktop\music |
11:07:15 | HCl | that worked fine here |
11:07:29 | amiconn | I prefer to run it directly on the unit |
11:07:35 | HCl | yea, same |
11:07:35 | amiconn | I used |
11:07:38 | HCl | that was just a test example |
11:07:51 | amiconn | java -jar L:\ −−strip L:\ |
11:07:51 | HCl | for my unit i use java -jar −−dirisalbum / |
11:08:00 | HCl | you can leave out the strip entirely |
11:08:03 | amiconn | Okay |
11:08:07 | HCl | it will strip the drive letter by default |
11:08:23 | amiconn | The paths are printed with \ on the screen |
11:08:33 | HCl | yea, thats okay |
11:08:36 | HCl | as long as the final path |
11:08:40 | HCl | in the end with longest filename |
11:08:43 | HCl | is having / slashes |
11:09:04 | HCl | its most probably the \ at the end of your strip |
11:09:09 | HCl | removing the first / slash |
11:09:20 | HCl | i haven't added code to force paths starting with / yet |
11:09:21 | amiconn | I think it would be better to print the mangled paths instead of the source paths, at least for tracking down problems |
11:09:48 | amiconn | (taking into account −−strip, −−add and \ ==> / replacement |
11:09:48 | HCl | well.. the paths it shows are merely for showing, it doesn't process those since they are directories.. |
11:09:53 | HCl | but okay |
11:09:58 | amiconn | Ah, yes |
11:10:39 | amiconn | I think it would still be better to show them processed as well. I might not be the only one who gets confused... |
11:10:53 | HCl | yea, i'll change that and also force a / at the beginning.. |
11:11:00 | amiconn | I don't remember how the perl version does it |
11:11:26 | | Join [IDC]Dragon [0] (~5483912e@labb.contactor.se) |
11:11:57 | amiconn | It *seemed* to me that the java version is slower, but I'm rather unsure about this |
11:12:10 | amiconn | (not the disk scanning step, but the sorting & output step) |
11:12:17 | [IDC]Dragon | hi there |
11:12:32 | amiconn | hi |
11:12:36 | [IDC]Dragon | before i gotta run off again: |
11:12:52 | [IDC]Dragon | i just made a BootBox wiki article |
11:13:00 | [IDC]Dragon | with .ucl files |
11:13:08 | amiconn | For testing? |
11:13:13 | [IDC]Dragon | yes |
11:13:15 | amiconn | I.e. flash as secondary? |
11:13:21 | [IDC]Dragon | yes again |
11:13:23 | amiconn | (with rockbox_flash) |
11:13:39 | amiconn | Ah |
11:13:59 | amiconn | Anything special to observe? |
11:14:08 | [IDC]Dragon | see the text |
11:14:54 | amiconn | You have tested on Ondio SP??? |
11:15:17 | [IDC]Dragon | FM, sorry |
11:16:46 | HCl | uploading fixed version |
11:16:55 | HCl | done |
11:16:59 | [IDC]Dragon | is there a way to delete a wrong attachment? so far I've hidden it. |
11:17:16 | HCl | amiconn: try the new songdb.jar.. |
11:18:37 | [IDC]Dragon | btw, what is this dynamic db? |
11:18:48 | amiconn | [IDC]Dragon: Should I do that (I guess it's th eplayer .ajz)? |
11:19:04 | HCl | proof-of-concept quality, at the moment, but it will keep track of playcount and other things |
11:19:18 | HCl | in order to be able to do some nice searches on music |
11:19:30 | [IDC]Dragon | amiconn: or educate me how to delete |
11:19:38 | amiconn | There is no special delete action, to delete an attachment, you have to move it to the Trash web, topic TrashAttachment |
11:20:18 | [IDC]Dragon | how can I move it? |
11:20:44 | amiconn | Attach -> (attachment to delete) -> action -> move attachment -> To: Trash topic: TrashAttachment |
11:20:46 | [IDC]Dragon | ah, found it |
11:22:08 | [IDC]Dragon | thx |
11:22:21 | amiconn | HCl: Thanks. |
11:22:27 | HCl | np |
11:23:18 | amiconn | HCl: Perhaps the runtime db should be switchable for now? |
11:23:24 | [IDC]Dragon | are all Rombox builds too big now (except Player)? |
11:23:38 | amiconn | (To avoid the spinup for those who want the tagdb, but not the runtimedb) |
11:23:39 | HCl | amiconn: i would, but i'm not sure how to add a config option o.o |
11:23:58 | amiconn | [IDC]Dragon: Player and Ondio SP are still romboxable |
11:23:59 | HCl | it shouldn't be hard to add, just a return -1 in the rundb_init depending on a variable |
11:24:09 | amiconn | HCl: I can do that |
11:24:13 | HCl | please |
11:24:34 | HCl | i could also use quite some help on moving the runtime data so that its pre-cached, since i have 0 experience with that |
11:24:46 | [IDC]Dragon | I've read about 2.5, is that prepared already? |
11:24:56 | | Join hicks [0] (~hicks@zeus.mups.co.uk) |
11:25:41 | amiconn | HCl: Unfortunately I can't do that now, as I'm still busy with graphics... That requires much more work than a config option |
11:25:43 | [IDC]Dragon | sorry for my noob kindof questions these days |
11:25:47 | HCl | thats okay |
11:26:08 | HCl | the code isn't meant to be production quality yet, we needn't be in a hurry, the option to turn it off is a good idea though. |
11:26:10 | amiconn | [IDC]Dragon: The 2.5 snapshot is already taken (a week ago or two) |
11:26:30 | HCl | i'm probably gonna look at getting the rating in the wps menu (?) that i haven't even discovered yet |
11:26:32 | | Quit gromit` (Read error: 104 (Connection reset by peer)) |
11:26:36 | [IDC]Dragon | so I should check out that label for BootBox |
11:26:37 | HCl | after i wake up |
11:26:44 | HCl | and eat breakfast |
11:27:19 | [IDC]Dragon | must have happend secretly |
11:27:35 | | Join Chamois [0] (~Chamois@i01v-62-35-66-23.d4.club-internet.fr) |
11:27:39 | | Join gromit` [0] (~gromit`@ras75-5-82-234-244-69.fbx.proxad.net) |
11:27:46 | [IDC]Dragon | so your latest gfx stuff is not in |
11:29:29 | | Join PaulJ [0] (~PaulJ@vpn-3092.gwdg.de) |
11:29:39 | [IDC]Dragon | ok, I'm off and stop asking questions |
11:29:54 | [IDC]Dragon | ...will stop |
11:29:58 | [IDC]Dragon | cu |
11:30:35 | | Quit [IDC]Dragon ("CGI:IRC") |
11:31:06 | amiconn | HCl: In 'General settings'->'Playback': 'Gather runtime data' yes/no |
11:31:11 | amiconn | Would that be acceptable |
11:31:13 | amiconn | ? |
11:31:57 | HCl | sure |
11:32:01 | HCl | sounds fine |
11:32:02 | HCl | :) |
11:32:25 | HCl | might want to add (experimental) to it for now |
11:33:12 | amiconn | Okay, will do that |
11:33:27 | amiconn | This is only the language string which is easily changed later |
11:33:41 | * | HCl goes to buy breakfast and stuff.. |
11:33:44 | HCl | afk |
11:47:43 | *** | Saving seen data "./dancer.seen" |
11:52:01 | | Join preglow [0] (thomj@s183a.studby.ntnu.no) |
11:52:45 | preglow | wassup |
12:00 |
12:00:26 | | Quit PaulJ (Read error: 145 (Connection timed out)) |
12:17:39 | amiconn | HCl: When I'm thinking about it, caching the playtime info shouldn't need changes to the runtime db code, only to the playback code |
12:17:56 | amiconn | Well, almost |
12:18:16 | | Join ep0ch [0] (~ep0ch@84.12.182.81) |
12:18:33 | amiconn | The playback code would the simply call the callback not after each track, but only when it is rebufferung, and then it would call it for all 'passed' tracks |
12:18:56 | amiconn | The id3 structure would then contain the actual playtime, which is a good thing imho |
12:19:06 | amiconn | No need to keep track of it in the database code |
12:19:18 | | Join [-AIR-] [0] (air@host86-130-27-166.range86-130.btcentralplus.com) |
12:19:23 | | Nick [-AIR-] is now known as west-acre (air@host86-130-27-166.range86-130.btcentralplus.com) |
12:19:25 | HCl | mhm, you just have to move the data it requires to the id3 structure |
12:19:42 | amiconn | The data should already be there |
12:19:47 | amiconn | (I think) |
12:20:00 | Slasheri | Hmm, that is a good idea |
12:20:01 | amiconn | There should be an additional parameter which would tell the runtimedb whether it should fsync() or not |
12:20:13 | amiconn | (To avoid fsyncing everytime) |
12:20:18 | HCl | what do you mean the data should already be there? |
12:20:21 | Slasheri | Before every flush that data from played tracks can be passed to the database |
12:20:26 | amiconn | This would then be true for the last call in each batch |
12:20:28 | HCl | the runtime database requires quite a bit of knowledge |
12:20:58 | amiconn | The id3 structure contains path, length, and already played time |
12:21:02 | HCl | it needs the offset of the fileentry of the file, the data that was in the file entry |
12:21:11 | HCl | the offset of the runtime entry of the file |
12:21:21 | | Join Moos [0] (MoosCamaro@m214.net81-66-158.noos.fr) |
12:21:23 | HCl | the rating, playcount, and all the other runtime data |
12:21:34 | HCl | and ofcourse the hashes of the runtime entry and the file entry |
12:21:42 | amiconn | Hmm, but this is handled by the runtimedb itself??? |
12:22:00 | HCl | at the moment, yes, but there's only a single location where it stores this info |
12:22:09 | HCl | so it would have to be moved to the id3 structure |
12:22:15 | amiconn | No, why? |
12:22:49 | amiconn | The way the runtimedb works won't change, the only thing that changes is the point in time when it is called |
12:22:52 | HCl | because it would still require a harddisk spin up otherwise? |
12:23:00 | amiconn | No |
12:23:05 | HCl | i'm confused. |
12:23:12 | HCl | :/ |
12:23:16 | amiconn | Currently it is called after each track that finished playing |
12:23:20 | HCl | yes. |
12:23:45 | amiconn | With the new concept it would be called by the playback code *when the playback code needs to rebuffer* |
12:23:49 | HCl | you're wanting to keep track of the playcount, and look the file up when you're planning to write to it? |
12:23:52 | amiconn | ...which needs a spinup anyway |
12:24:05 | Slasheri | in future it can be called n times for each track info in buffer while we have to rebuffer / erase the track structure |
12:24:15 | amiconn | ...and then it would be called *for all passed tracks* *in succession* |
12:24:31 | HCl | you can't do that, since it loads runtime db info |
12:24:35 | HCl | when needed |
12:24:40 | amiconn | Yes, and? |
12:24:52 | HCl | you can't call it in succession cause the data wouldn't change |
12:25:06 | * | HCl is confused x.x |
12:25:29 | HCl | the current code insists on getting called when a new song gets loaded |
12:25:29 | amiconn | Hmm? |
12:25:33 | HCl | you can't call it at other locations |
12:25:47 | HCl | prior to a song getting loaded it needs to load the runtime info of that song |
12:25:52 | amiconn | That would not happen |
12:25:55 | amiconn | Yes |
12:26:08 | HCl | and at the end of it it needs to write the runtime info back after it has been altered |
12:26:16 | amiconn | Hmm, why would it need the runtime info prior to loading? |
12:26:28 | HCl | because it contains stuff like rating, previous playcount, volume adjustment |
12:26:37 | amiconn | Imho it should be sufficient to do it all at the end (or even delayed further) |
12:26:54 | HCl | no, we want playcount to be increased after 50% of the file has been played or so |
12:26:59 | HCl | and volume adjustment to work, obviously |
12:27:25 | amiconn | Why would you require to increase playcount at the extact time 50% have passed? |
12:27:37 | HCl | not exact, but 50% or 75% |
12:27:41 | HCl | because at the moment its horrible |
12:27:43 | HCl | even when you skip tracks |
12:27:44 | amiconn | It should be sufficient to bump playcount when we know that 50% have been played |
12:27:46 | HCl | it still counts them as played |
12:27:55 | HCl | yes |
12:28:00 | amiconn | ...no matter when that info is passed to the db |
12:28:05 | HCl | but still. you NEED the info from the runtime database |
12:28:18 | amiconn | Okay, then this needs to be split in 2 |
12:28:19 | HCl | in order to be able to show playcount, change the rating properly and show the rating of the file |
12:28:27 | HCl | and volume adjustment as well |
12:28:33 | amiconn | One callback would update all data for the passed tracks |
12:28:48 | amiconn | ...which would be called before rebuffering |
12:28:59 | amiconn | ...and another callback for upcoming tracks |
12:29:10 | amiconn | ...which would be called when buffering these tracks |
12:29:23 | HCl | it would still be tricky, since you'd have to know which track is actually the current one |
12:29:30 | HCl | and you'd have to store all the info in an array |
12:29:42 | amiconn | ...and the relevant playback info (which would be volume adjustment only) would then be stored in the id3 struct |
12:29:54 | HCl | i prefer rating and playcount as well |
12:29:56 | amiconn | ...which already is in an array |
12:29:58 | HCl | so you can actually show that on wps |
12:30:05 | amiconn | Yes, okay |
12:30:25 | HCl | but yea, that would work |
12:30:31 | HCl | as long as i can load the data into the id3 struct |
12:30:37 | HCl | and fetch the data from the id3 struct to write it back |
12:30:59 | amiconn | Yes |
12:31:22 | HCl | preferably by just calling a event_fetch_runtime_info(blah *id3) |
12:31:23 | amiconn | Imagine a rebuffer event: 3 tracks have passed, and 2 new one get buffered |
12:31:32 | amiconn | The following would happen: |
12:31:34 | HCl | and an event_write_runtime_info(blah *id3) |
12:31:50 | HCl | and just call that many times |
12:32:09 | amiconn | (spinup) -> call to runtimedb for passed track (3x) -> rebuffer -> call to runtimedb for upcoming track (2x) -> (spindown) |
12:32:32 | HCl | sure |
12:32:46 | HCl | as long as you use the two events i just described and i'm able to store the runtime data in the id3 tag |
12:33:04 | amiconn | yes, exactly |
12:33:16 | HCl | preferably, i'd like to store the fileentry and rundbentry in the id3 as well |
12:33:26 | amiconn | I think this would work pretty well; the wps already accesses the info in the id3 struct |
12:33:33 | HCl | it would prevent doing 2 binary searches when 1 will do |
12:33:41 | amiconn | How large are these? Just pointers? |
12:33:45 | HCl | just ints |
12:33:50 | amiconn | Okay |
12:33:52 | HCl | offsets into the databases |
12:34:04 | amiconn | Change that to explicit longs if possible |
12:34:12 | HCl | yea, i think they are.. |
12:34:16 | amiconn | Fine |
12:34:37 | HCl | hmm, or not *changes* |
12:36:00 | amiconn | We don't want to limit the databases to 64 KB on gmini, if that port will be finished some time, i think? ;) |
12:36:18 | HCl | hm? are they limited to 64kb? |
12:37:12 | amiconn | If you use ints, then yes |
12:37:16 | HCl | ah :P |
12:37:18 | amiconn | Gmini has a 16 bit cpu |
12:37:23 | HCl | :P |
12:37:35 | HCl | well, changed it, i'll go over the code later to see if i missed some |
12:37:53 | amiconn | Hmm. I do have that option prepared here, currently testing... |
12:38:14 | amiconn | Is there a method to display the runtimedb contents? |
12:38:30 | HCl | a crude one... testdbv2.c in tools/ |
12:38:41 | HCl | it requires you to set all the defines in the source to the values it spits out |
12:38:46 | HCl | and recompile |
12:38:49 | HCl | before it will work |
12:38:51 | amiconn | Hmm, my rockbox.rundb is still 8 bytes :( |
12:39:05 | HCl | well, not much contents to display, then |
12:39:07 | HCl | :x |
12:39:16 | amiconn | I did play a number of tracks... |
12:39:20 | HCl | RRD1,0 is what it should contain |
12:39:26 | HCl | did you turn the option thing on? |
12:39:47 | HCl | the remote should print out some rundb info |
12:40:03 | HCl | at the moment it ignores files with a hash of 0 |
12:40:22 | amiconn | Yes I turned it on |
12:40:30 | HCl | and it ignores files on which it fails to find a fileentry in the tagdatabase |
12:40:52 | amiconn | I have a database generated with your latest java songdb, which contains all files on my iriver |
12:40:57 | HCl | k |
12:41:13 | HCl | well, i guess you can toss me your database and i can check it briefly with testdbv2 |
12:41:27 | HCl | pretty much the thing you need to look for is whether the fileentries seem to have the correct path |
12:41:43 | HCl | you could also add a logf to print out the results of the binary search |
12:41:48 | amiconn | I'll check whether the option is working |
12:41:58 | amiconn | (that's possible even without getting entries) |
12:42:02 | amiconn | Then commit it |
12:42:46 | amiconn | If I delete the rundb, the reboot, the file should be recreated when the option is on |
12:42:53 | amiconn | ...otherwise not |
12:42:56 | HCl | mhm |
12:44:10 | amiconn | I also added proper handling for the usb case (like with the tagdb) |
12:44:20 | HCl | thanks |
12:45:59 | amiconn | The volume adjustment has to be done by the playback code anyway, so the id3 struct should be the best place to keep it |
12:46:12 | HCl | *nods* |
12:47:25 | preglow | about time to start renaming the id3 struct, perhaps? :) |
12:47:42 | amiconn | It's called mp3entry now |
12:47:49 | preglow | not much better |
12:48:10 | preglow | doesn't matter much, but is misleading now that we support a bunch of codecs |
12:49:26 | amiconn | HCl: Committed. |
12:49:27 | | Join Coldtoast [0] (edan@ppp110-115.lns1.hba1.internode.on.net) |
12:49:32 | amiconn | ...almost |
12:50:57 | amiconn | there. |
12:53:01 | HCl | k :) |
12:53:12 | * | HCl needs more sleep :/ |
12:53:32 | HCl | should i work on implementing those two event things when i'm awake? |
12:53:44 | HCl | i just need someone to make the event interface much like the old one |
12:54:13 | amiconn | I think this would be cool |
12:54:49 | HCl | mm? |
12:55:17 | amiconn | I mean, that it would not need to spinup after each track anymore |
12:55:23 | HCl | *nods* |
12:55:25 | amiconn | I just have to find out why my database refuses to work, then I could add the event handling for archos |
12:55:33 | HCl | k :) |
12:55:47 | * | HCl prods Slasheri a bi |
12:55:48 | HCl | t |
12:55:51 | amiconn | I already tried, but I thought something was wrong because my runtimedb didn't get populated |
12:56:19 | HCl | as long as the option is enabled and the tagdatabase is loaded, there are two options left to why it could go wrong |
12:56:21 | amiconn | Could be that just my tagdb was wrong... |
12:56:24 | HCl | 1) the hash of the file is 0 |
12:56:28 | HCl | 2) the binary search failed |
12:56:47 | HCl | the binary search fails if the tagdatabase has wrong filename entries |
12:56:47 | | Join Christi-S [0] (~Christi@82-70-230-150.dsl.in-addr.zen.co.uk) |
12:56:59 | amiconn | Hmm. |
12:57:06 | amiconn | hi Christi |
12:57:11 | Christi-S | Heya. |
12:57:16 | * | HCl goes to nap a bit :/ |
12:57:21 | Slasheri | HCl: Hmm :) |
12:57:30 | amiconn | HCl: The has shouldn't be 0 with the java version, right? |
12:57:31 | | Quit ep0ch ("goto") |
12:57:41 | HCl | Slasheri: do you think you could implement the two events that were proposed? |
12:57:51 | HCl | amiconn: nope, java version should be hashing |
12:57:56 | HCl | you can try the testdbv2 tool |
12:58:03 | HCl | it allows raw dumps of the database |
12:58:09 | Slasheri | HCl: that doesn't sound a good thing. If you mean the start-of-track and end-of-track events? |
12:58:19 | amiconn | Perhaps I will... I have to decide between 4-grey coding and database adaption... |
12:58:22 | amiconn | :/ |
12:58:28 | HCl | mmm, ask amiconn for details :/ |
12:58:51 | amiconn | Slasheri: No start-of-track and end-of-track when they actually happen |
12:58:55 | HCl | i'm not 100% sure what i should call the events, but pretty much, there's one that gets called repeatedly for every id3 entry that needs to be saved |
12:59:08 | HCl | and one that gets called repeatedly for every id3 entry that needs runtime info added to it |
12:59:24 | * | HCl goes for a nap now :/ |
12:59:31 | Slasheri | amiconn: Hmm, only start-of-track and end-of-track when codec starts / ends? |
12:59:33 | amiconn | ...but 'upcoming track' for each track that gets buffered, and 'passed track' for each track that has passed, *at the time the rebuffering takes place* |
12:59:57 | Slasheri | Ah |
13:00 |
13:00:00 | amiconn | ...to completey avoid additional spinups |
13:00:14 | Slasheri | that might work |
13:00:32 | amiconn | I didn't look at how playback.c handles it, but I know a bit how mpeg.c handles it |
13:00:40 | amiconn | It should be quite simple |
13:01:00 | Slasheri | so when we are buffering new tracks, generate an event when we start buffering a new track? |
13:01:07 | amiconn | mpeg.c has an array (16 entries) to keep info about all loaded tracks |
13:01:32 | amiconn | It has a read pointer and a write pointer and is used as a ring buffer |
13:01:43 | Slasheri | currently playback.c generates the event at exact time (with audio buffer latency taken in account) when track change |
13:01:46 | Slasheri | s |
13:02:07 | amiconn | The read pointer advances at each track change, and the write pointer advances advances for each newly buffered track |
13:02:19 | Slasheri | yep, playback.c has that ring structure also |
13:02:30 | amiconn | For my proposal to work, we would need a third pointer, 'trailing read' |
13:03:14 | amiconn | The buffering code would call the 'new track' callback each time it advances the write pointer, which happens while buffering |
13:03:44 | Slasheri | that sounds possible |
13:03:53 | amiconn | Immediately before buffering new tracks, it would count the 'trailing read' pointer up to the read pointer, and call the 'passed track' callback for each of these |
13:04:34 | amiconn | So n times callback for passed tracks, then rebuffer and call new track callback m times |
13:04:36 | Slasheri | Hmm, is there a need for trailing read? I guess no because we know the buffered track count |
13:04:46 | Slasheri | yes |
13:05:07 | amiconn | I don't know how playback.c does that, but the read pointer in mpeg.c advances at the time of a track change |
13:05:18 | amiconn | ..to keep track of current info for wps |
13:05:38 | amiconn | ...but we need to tell the runtimedb about all tracks that have passed |
13:06:11 | Slasheri | yep, that is possible with the current implementation without any new pointers |
13:06:24 | amiconn | Okay, so you have 3 pointers? |
13:06:57 | amiconn | Or you keep track about the write position with th buffered tracks count? |
13:06:58 | Slasheri | read_index, write_index and track_count. These are enough to find the passed tracks |
13:07:08 | amiconn | Ah, yes |
13:07:44 | | Join Hansmaulwurf [0] (~maerlyn@p54AAE4CE.dip.t-dialin.net) |
13:08:24 | Slasheri | i can implement that event :) |
13:08:40 | amiconn | mpeg.c does that a little different afair, but that shouldn't be a problem |
13:09:02 | amiconn | mpeg.c doesn't keep the track_count separately iirc |
13:11:05 | | Quit ashridah (Read error: 110 (Connection timed out)) |
13:11:21 | amiconn | I think these 2 new event could be added while the current one should stay as well |
13:11:35 | amiconn | Then HCl could hook the runtimedb to these 2 new callbacks |
13:11:40 | Slasheri | of course, i think it that way too :) |
13:11:53 | amiconn | ...and finally the current trackchange callback can go away |
13:12:26 | amiconn | The 'new track' callback should have an additional parameter |
13:12:40 | amiconn | ...telling the runtimedb whether this is the last call in the batch |
13:12:54 | | Join ashridah [0] (ashridah@220-253-120-108.VIC.netspace.net.au) |
13:12:56 | Slasheri | ah, ok |
13:13:01 | amiconn | This way it only needs to fsync() at the last call |
13:13:40 | amiconn | ...and the ata_sleep() in the playback code should go after these calls |
13:13:42 | | Quit edx (Read error: 110 (Connection timed out)) |
13:15:15 | HCl | sounds good :) |
13:15:56 | | Join PaulJ [0] (~PaulJ@vpn-3061.gwdg.de) |
13:18:14 | | Quit Christi-S ("If I were actually witty, this quitline would be funny.") |
13:21:27 | amiconn | Slasheri: Just a detail: It is perfectly possible that there are no callbacks at all when rebuffering, in case we're playing a very long track that was already running at the last rebuffer event, and will still play at the next rebuffer event |
13:22:01 | amiconn | Much less likely on iriver than on archos, but still possible even with mp3 |
13:22:11 | Slasheri | amiconn: yes, of course :) |
13:22:19 | amiconn | I had some 100 MB mp3 track.... |
13:22:46 | Slasheri | callbacks will be called only when track really begins/ends |
13:23:04 | amiconn | And also, the 'new track' callback must be called at the initial buffer filling, and the 'passed track' callbacks at stop |
13:23:27 | amiconn | ...but I think you got the point :) |
13:23:32 | Slasheri | yep :) |
13:23:49 | Slasheri | i will try to test that these special cases works also |
13:26:08 | amiconn | How large is your track info array? |
13:26:51 | amiconn | On archos we use 16 even with the small RAM. Some users managed to exceed that, playing tiny snippets from a language learning CD... |
13:27:29 | Slasheri | Hmm, i haven't measured it but it might be several thousands bytes long because we cache 10 id3 and mp3data structures. However, it should be enough to pass the mp3entry structure only to the database |
13:27:32 | | Quit tvelocity ("Leaving") |
13:27:52 | amiconn | Yes, I mean the number of entries |
13:27:55 | amiconn | ...only 10 :/ |
13:28:00 | Slasheri | Ah, yes 10 |
13:28:09 | Slasheri | That can be changed with the MAX_TRACK define |
13:28:23 | amiconn | easy... |
13:28:32 | Slasheri | however, i have never had a situation that even 10 tracks in buffer at a time ;) |
13:28:54 | amiconn | I can imagine that happen with some albums I have |
13:29:22 | Slasheri | ok, that number should be increased if necessary |
13:30:53 | amiconn | yup |
13:31:23 | amiconn | I just checked. D.Trance Gold CD1, encoded with lame @192 kbps |
13:31:31 | amiconn | The first 12 tracks are ~27 MB |
13:33:55 | amiconn | I noticed some strange effect with the backlight fading. It still flickers if there's a lot of bitmap drawing, but I don't understand why. |
13:34:09 | amiconn | Try snow.rock and logo.rock, you'll see what I mean... |
13:35:14 | Slasheri | yes, i know that.. I think some interrupts might override the timer2 interrupt |
13:36:36 | Slasheri | or maybe the interrupts are disabled while updating display |
13:36:38 | amiconn | Hmm, now I can't make it happen |
13:36:57 | Slasheri | just try to write bunch of text to the remote lcd with logf |
13:37:06 | Slasheri | that will cause that undesired effect always |
13:37:35 | amiconn | Ah, now I understand... |
13:37:59 | amiconn | It does happen with snow.rock and logo.rock, because these draw on the remote as well |
13:38:07 | amiconn | ...but only if the remote is plugged! |
13:38:22 | Slasheri | :D so the problem is with the remote display code |
13:38:35 | amiconn | Rather, with the remote lcd data transfer |
13:38:41 | Slasheri | yep |
13:39:33 | amiconn | Ahahhhh!!! |
13:39:40 | amiconn | I know why |
13:39:48 | Slasheri | that's great :) |
13:40:08 | amiconn | The port handling of the remote lcd transfer interferes with the port handling in the backlight dimming interrupt |
13:40:18 | Slasheri | oh |
13:40:23 | amiconn | That's tricky... |
13:41:12 | amiconn | That's because the port set/reset is non-atomic... |
13:41:39 | * | amiconn checks the coldfire manual |
13:42:05 | amiconn | We might need an equivalent to the SH1 read-modify-write AND and OR |
13:43:36 | amiconn | ..and it seems it is possible :) |
13:43:51 | Slasheri | =) |
13:44:16 | | Join Febs [0] (~chatzilla@207-172-122-81.c3-0.rdl-ubr4.trpr-rdl.pa.cable.rcn.com) |
13:45:06 | amiconn | That would be an equivalent to the and_b / or_b / xor_b macros for SH1 |
13:47:09 | amiconn | The problem is that statements like GPIO1_OUT &= ~0x00000004; are non-atomic |
13:47:46 | *** | Saving seen data "./dancer.seen" |
13:48:13 | Slasheri | Hmm, yes. So it should be possible to make it atomic with some assembly code? |
13:48:28 | amiconn | so on archos, we have and_b(~0x04, &PADRL); as an equivalent (obviously for byte witdh only) |
13:48:40 | amiconn | This is actually a small assembly macro |
13:48:50 | amiconn | ...and that should be possible on coldfire as well |
13:48:56 | Slasheri | good :) |
13:49:32 | amiconn | ...with something like and.l %dn,(%am) |
13:50:31 | amiconn | This has to be used for all port operations on ports that could be potentially changed in an interrupt as well |
13:50:43 | amiconn | ...which are practically all on iriver :/ |
13:50:59 | amiconn | Not too bad, but quite a number of changes |
13:51:37 | Slasheri | That's true.. but if it's possible to do it with some nice macro it shouldn't be so bad |
13:52:37 | amiconn | Yeps. Look at firmware/export/system.h lines 82 ff how this is done for SH1 |
13:53:20 | amiconn | We would then have and_l(), or_l() and xor_l() |
13:53:22 | Slasheri | ah, that seems good :) |
13:53:46 | amiconn | ..even a bit more flexible since both the address and the data can be variables on coldfire |
13:56:21 | | Join bipak [0] (~bip@p508848B1.dip.t-dialin.net) |
14:00 |
14:00:50 | west-acre | l |
14:04:48 | amiconn | w00t, that actually works :)) |
14:05:04 | Slasheri | cool =) |
14:05:39 | amiconn | ..and it decreases code size a bit |
14:05:49 | Slasheri | nice :D |
14:13:23 | amiconn | I converted the whole remote lcd driver and backlight.c for now. All other places doing port manipulation should probably be changed as well |
14:14:24 | | Quit bipak_ (Read error: 110 (Connection timed out)) |
14:19:02 | amiconn | The flickering fade is no more :) |
14:45:29 | HCl | any progress on the events thing or should i just go and look at implementing rating? |
14:45:34 | HCl | how do i access the wps context menu? |
14:47:24 | Slasheri | HCl: I will implement it soon (now working with mono playback) |
14:47:34 | HCl | k :) |
14:52:13 | | Quit Chamois ("Leaving") |
14:55:02 | | Join edx [0] (edx@p54A8DAD5.dip.t-dialin.net) |
14:58:49 | HCl | who can tell me about the wps menu? |
15:00 |
15:00:29 | * | HCl thinks he got it |
15:04:13 | | Quit ze (Read error: 104 (Connection reset by peer)) |
15:04:17 | | Join ze [0] (ze@ca-dstreet-cuda2-c9a-73.snbrca.adelphia.net) |
15:14:41 | HCl | i'm bored :/ |
15:15:00 | preglow | and i'm out |
15:15:08 | preglow | see you guys some day in the not too distant future, i hope |
15:15:14 | | Join tvelocity [0] (~tony@ipa201.6.tellas.gr) |
15:15:21 | preglow | if i can stand 28k8 it might even be pretty soon! |
15:15:22 | preglow | later! |
15:15:26 | | Quit preglow ("leaving") |
15:16:09 | HCl | cya.. |
15:17:30 | * | HCl prods amiconn |
15:17:33 | HCl | any luck? |
15:34:29 | amiconn | Sorry, no. Didn't investigate further for now |
15:34:34 | amiconn | Gotta go, bbl |
15:34:39 | | Part amiconn |
15:36:22 | | Join xen` [0] (nop@stg25-1-82-238-117-1.fbx.proxad.net) |
15:36:40 | xen` | Is there anyone on the .mod playing ? |
15:36:54 | | Quit tvelocity ("Leaving") |
15:36:55 | xen` | I'll probably take a look about if it's possible |
15:37:16 | xen` | (if nobody on it) |
15:47:49 | *** | Saving seen data "./dancer.seen" |
15:58:59 | | Join tvelocity [0] (~tony@ipa201.6.tellas.gr) |
15:59:10 | tvelocity | a ETA i antigrafi! |
15:59:14 | tvelocity | :P |
15:59:17 | tvelocity | mia wra* |
15:59:19 | tvelocity | oops wrong channel |
15:59:30 | tvelocity | damn xchat focus |
15:59:33 | | Quit AEnertia (Client Quit) |
16:00 |
16:07:49 | | Quit xen` (Read error: 145 (Connection timed out)) |
16:14:29 | | Join kenshin [0] (~dave@c-24-17-8-193.hsd1.wa.comcast.net) |
16:19:10 | kenshin | anyone know when t0mas will be back? |
17:00 |
17:22:13 | | Join Godeater [0] (~c2cbc979@labb.contactor.se) |
17:23:33 | | Quit Godeater (Client Quit) |
17:29:15 | | Quit tvelocity ("Leaving") |
17:37:27 | | Join DangerousDan [0] (~Miranda@194.22.60.59) |
17:39:42 | | Quit kenshin (Read error: 110 (Connection timed out)) |
17:47:53 | *** | Saving seen data "./dancer.seen" |
17:48:03 | HCl | mrf |
17:48:06 | * | HCl prods around |
17:48:14 | HCl | Slasheri / amiconn? |
17:49:10 | Slasheri | HCl: you will get it soon :) |
17:50:49 | | Join bagawk [0] (1000@bagawk.user) |
17:51:35 | | Join pabs [0] (~pabs@xor.pablotron.org) |
17:52:21 | HCl | k :) |
17:52:26 | * | HCl is falling asleep here |
18:00 |
18:04:36 | | Join muesli- [0] (muesli_tv@Bbc99.b.pppool.de) |
18:09:56 | | Join courtc [0] (~courtc@adsl-154-38-44.asm.bellsouth.net) |
18:13:19 | | Quit edx () |
18:18:21 | | Quit einhirn ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
18:19:12 | | Join kenshin [0] (~dave@c-24-17-8-193.hsd1.wa.comcast.net) |
18:19:43 | | Join Lost-ash [0] (ashridah@220-253-122-74.VIC.netspace.net.au) |
18:22:42 | | Quit ashridah (Read error: 110 (Connection timed out)) |
18:23:44 | | Quit hicks (Remote closed the connection) |
18:24:07 | | Quit muesli- ("ich will Kühe!!!") |
18:26:25 | | Join hicks [0] (~hicks@zeus.mups.co.uk) |
18:34:19 | Slasheri | HCl: Done, now testing |
18:36:20 | | Nick Lost-ash is now known as ashridah (ashridah@220-253-122-74.VIC.netspace.net.au) |
18:36:34 | | Quit ashridah ("Leaving") |
18:39:21 | | Join webguest91 [0] (~d49f4cf2@labb.contactor.se) |
18:41:41 | | Join XavierGr [0] (~test@ppp13-adsl-95.ath.forthnet.gr) |
18:49:48 | Slasheri | HCl: it should work now, i will commit |
18:51:45 | XavierGr | does anyone know what HAVE_LCD_CHARCELLS define means? |
18:53:36 | | Quit bagawk ("Leaving") |
18:55:06 | | Join amiconn [0] (jens@pD9F4C491.dip.t-dialin.net) |
18:57:24 | XavierGr | hi amiconn |
18:57:41 | amiconn | hi |
18:58:48 | XavierGr | amiconn: I see that while there are scroll configuration variables in lcd-h100-remote.c there are not present to configure in settings.c and settings-menu.c |
18:58:58 | amiconn | Yes |
18:59:30 | XavierGr | I tried to add them but I got lost... |
18:59:31 | amiconn | Nobody did this so far because the remote isn't really used with scrolling yet |
19:00 |
19:00:34 | XavierGr | does anyone know what HAVE_LCD_CHARCELLS define means? |
19:00:37 | amiconn | There is some oddity too which I don't understand why Rick did it |
19:00:58 | amiconn | The remote scrolling thread isn't created for the simulator. Imho it should |
19:01:31 | amiconn | Yes, that's simple, and should be obvious. It means the target has a character cell based display, as opposed to bitmap based |
19:01:31 | XavierGr | yeah all my attempts to test code is making a normal build to test in my player it is very tiresome |
19:01:58 | XavierGr | like seven segment displays? |
19:02:16 | amiconn | The only device that has this is the archos player/studio |
19:02:23 | XavierGr | oh I got it |
19:02:33 | amiconn | It has a 2 line x 11 character, 5x7 point dot matrix display |
19:02:55 | amiconn | However, you can't freely access the single dots |
19:03:32 | amiconn | The display ram contains character values, and the 5x7 dot matrices are taken from a character generator, which is mostly in ROM |
19:03:42 | XavierGr | so player/studio is very limited in text output I guess... |
19:03:46 | amiconn | Yup |
19:04:08 | amiconn | It's still possible to support many rockbox features on that limited display |
19:04:38 | amiconn | Depending on the exact lcd type (there are old and new players), 4 or 8 characters are user definable |
19:05:25 | amiconn | This is what the playergfx library exploits - it allows (tiny) bitmap grahpics on this display! |
19:07:26 | XavierGr | so what about the remote thread you proposed. Do you think that it will have files like remote-wps.c and remote-tree.c e.t.c |
19:07:38 | XavierGr | or it will be implemented in current code? |
19:11:01 | XavierGr | any plans for the remote uisimulator on win32 yet? |
19:11:55 | | Quit DangerousDan (Read error: 131 (Connection reset by peer)) |
19:12:41 | | Join Ancelot [0] (Ancelot@42-138-126-200.fibertel.com.ar) |
19:12:59 | Ancelot | Bagder |
19:13:15 | Ancelot | BADGER BADGER BADGER BADGER BADGER BADGER BADGER BADGER BADGER BADGER BADGER (mushrooom mushrooom!) |
19:16:09 | | Join Stryke` [0] (~Chairman8@cpe-24-168-110-99.si.res.rr.com) |
19:16:45 | | Quit Ancelot (Client Quit) |
19:27:41 | | Quit amiconn (Read error: 110 (Connection timed out)) |
19:32:17 | | Join amiconn [0] (jens@pD9F4C759.dip.t-dialin.net) |
19:35:20 | | Join road_runner [0] (~5540763e@labb.contactor.se) |
19:36:37 | road_runner | Question: I found something very useful at sourceforge and there's no apperent reason why RockBox wouldn't include that patch on their build. where's the place to suggest to use it? |
19:37:21 | Nibbler | well, there is some patch-area at rockbox.org i think |
19:38:36 | road_runner | thanks i'll check it out. |
19:38:37 | XavierGr | link? |
19:40:48 | | Quit Stryke` ("Friends don't let friends listen to Anti-Flag") |
19:40:55 | | Join Stryke` [0] (~Chairman8@cpe-24-168-110-99.si.res.rr.com) |
19:47:39 | | Quit courtc (Read error: 110 (Connection timed out)) |
19:47:57 | *** | Saving seen data "./dancer.seen" |
19:48:27 | | Join courtc [0] (~courtc@adsl-158-49-201.asm.bellsouth.net) |
19:48:59 | | Part amiconn |
19:56:02 | | Quit Stryke` (Read error: 145 (Connection timed out)) |
20:00 |
20:08:35 | | Quit XavierGr () |
20:13:49 | | Join Bger_cgiirc [0] (~d5f0dcba@labb.contactor.se) |
20:14:24 | Bger_cgiirc | Bagder / B4gder : about Li-Ion batteries... it seems you |
20:14:29 | Bger_cgiirc | are right |
20:14:48 | Bger_cgiirc | http://www.computerhope.com/battery.htm#02 |
20:14:57 | Bger_cgiirc | http://www.batterieswholesale.com/damaging_batteries.htm |
20:15:04 | Bger_cgiirc | http://wirelessreview.com/mag/wireless_power_liion/ |
20:15:47 | Bger_cgiirc | some quotes |
20:15:50 | Bger_cgiirc | "Another easy way to destroy an Li-Ion battery is by discharging it too far." |
20:16:06 | Bger_cgiirc | "The Li-Ion cell should never be allowed to drop below about 2.4V, or an internal chemical reaction will occur where one of the battery electrodes can oxidize (corrode) through a process which can not be reversed by recharging." |
20:16:43 | Bger_cgiirc | "The Li-Ion typically is discharged to 3V/cell. The lowest low-voltage power cutoff is 2.5V/cell." |
20:17:05 | Bger_cgiirc | "During prolonged storage, however, a discharge below this voltage level is possible. Manufacturers recommend a trickle charge to raise such a battery gradually back up into the acceptable voltage window. Not all chargers are designed to apply a charge once a Li-Ion battery has dipped below 2.5V/cell." |
20:17:11 | | Quit Hansmaulwurf ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") |
20:18:11 | Bger_cgiirc | sorry for the flood... |
20:26:09 | | Join CheeseBurgerMan [0] (~Dan@63.150.80.210) |
20:30:58 | Bger_cgiirc | http://www.national.com/appinfo/power/files/f19.pdf |
20:38:01 | | Join Yokaloshi [0] (~Yokalosh@cpc1-cbly2-4-0-cust103.glfd.cable.ntl.com) |
20:38:51 | | Join PaulJ_ [0] (~PaulJ@vpn-3048.gwdg.de) |
20:39:01 | Yokaloshi | guys, since #linux + #debian are totally useless i have come seeking someones advice cos u ppl are in the know..... |
20:39:15 | Yokaloshi | which version of debian should be used with an amd-k6?: [alpha] [arm] [hppa] [i386] [ia64] [m68k] [mips] [mipsel] [powerpc] [sparc] |
20:40:17 | Yokaloshi | or am i wrong and none of you have the slightest idea? |
20:41:59 | | Quit CheeseBurgerMan (Client Quit) |
20:42:56 | Yokaloshi | anyone? |
20:42:59 | Yokaloshi | no-one? |
20:47:45 | | Join CheeseBurgerMan [0] (~Dan@63.150.80.210) |
20:47:58 | Bger_cgiirc | yokaloshi: i386 |
20:49:55 | | Quit hicks (Remote closed the connection) |
20:51:23 | Yokaloshi | thanks |
20:51:26 | Yokaloshi | what kernal? |
20:51:43 | Slasheri | just use the latest unstable or stable version |
20:51:49 | Yokaloshi | oki doki |
20:51:51 | Slasheri | And always newest kernel, 2.6.xx should be ok |
20:52:14 | Yokaloshi | 2.6 on the debian disk didnt work |
20:52:19 | Yokaloshi | i'll try something older |
20:52:22 | | Join hicks [0] (~hicks@zeus.mups.co.uk) |
20:52:35 | | Quit west-acre ("—I-n-v-i-s-i-o-n— 2.0 Build 3515") |
20:54:11 | | Quit Yokaloshi () |
20:55:17 | | Quit PaulJ (Read error: 113 (No route to host)) |
20:59:41 | Slasheri | Hmm, the voice ui seems quite easy to port |
21:00 |
21:01:57 | Moos | Hi Slasheri, not needed a new codec like speex? |
21:13:44 | Slasheri | Moos: We can implement the new codec later. If i understood correctly we should modify the codec loader to support two codecs loaded at a time |
21:14:05 | Slasheri | So we could have the voice codec always loaded & ready |
21:16:09 | Moos | a ok, goody :) |
21:17:19 | Bger_cgiirc | hm, what do you think about the idea to put rockbox.iriver in .rockbox folder ? |
21:17:33 | Bger_cgiirc | in *the* rockbox folder... |
21:18:02 | Bger_cgiirc | i know that it's a must for the archos devices to be in the root folder |
21:19:07 | Bger_cgiirc | but this comes from being compatible with original archos firmware |
21:20:02 | Bger_cgiirc | however, iriver's firmware never had posibility to load the firmware from the disk |
21:22:23 | Bger_cgiirc | yes, i know that for making such change it's needed to change the bootloader |
21:31:16 | | Quit Thasp () |
21:48:00 | *** | Saving seen data "./dancer.seen" |
21:48:46 | road_runner | Imho, would clean up some mess, not having files running around at your Root folder. specially when it's out in the public. |
21:50:30 | Bger_cgiirc | yes, that's my reason to offer this |
21:55:33 | ghode|afk | um its only one file... |
21:57:06 | | Quit kenshin (Read error: 145 (Connection timed out)) |
21:57:42 | Bger_cgiirc | but don't you think that all rockbox specific stuff is good to be in the .rockbox directory ? |
21:59:13 | hicks | Either that or modify the rockbox file list to hide rockbox.iriver when normally viewing |
22:00 |
22:01:15 | Bger_cgiirc | hicks, when you hide it, it's still there |
22:02:36 | hicks | yes, but is there a major problem with it been there if you can't see it? kinda like the .rockbox folder is there but not visible? |
22:04:13 | road_runner | That's just a part of the problem. the other is you don't want no one to exidently delete the file. if it's inside a directory it's less likely to happend. |
22:04:13 | Bger_cgiirc | not the same when you attach the unit to a PC |
22:04:29 | hicks | yeah thats true |
22:04:39 | road_runner | (accidently) |
22:04:56 | Bger_cgiirc | this too |
22:07:00 | | Quit road_runner ("CGI:IRC (EOF)") |
22:23:55 | Bger_cgiirc | nite |
22:23:58 | | Quit Bger_cgiirc ("CGI:IRC 0.5.4 (2004/01/29)") |
23:00 |
23:02:12 | | Quit Febs ("Chatzilla 0.9.68.5 [Firefox 1.0.4/20050511]") |
23:02:34 | | Join stoffel [0] (~sfr@dsl-084-057-136-155.arcor-ip.net) |
23:07:02 | | Join Musicmad [0] (~Musicmad@port547.ds1-oebr.adsl.cybercity.dk) |
23:07:02 | | Join PaulJ [0] (~PaulJ@vpn-3048.gwdg.de) |
23:09:31 | Rori | I found a workaround for that 'Next track' not displaying bug |
23:10:03 | Rori | Someone suggested using t0; in front which forces a refresh to display after buffering |
23:10:08 | | Join noel_sad_sogn [0] (~c87ec44a@labb.contactor.se) |
23:11:10 | noel_sad_sogn | Hey.... anybody there? |
23:11:11 | Rori | I don't see why wps can't pull the ID3 tag info without having to buffer the next track first |
23:11:24 | Bagder | Rori: then write a patch |
23:11:30 | Rori | :) |
23:11:37 | Rori | Show me how ;) |
23:11:46 | Coldtoast | that's your fave response Bagder :_ |
23:11:47 | Bagder | questioning functions when you don't know how things work is odd |
23:11:54 | Rori | I'm not complaining just pointing it out heh |
23:12:04 | Bagder | Coldtoast: yes it is! ;-) |
23:12:13 | Coldtoast | hehe |
23:12:21 | Bagder | Rori: of course we would've done that if it was that simple |
23:12:42 | Rori | I look from laymans point of view. If there is a technical reason not much else I can do or say as long as someone tells me that is the reason |
23:12:58 | Bagder | well _everything_ more or less is possible |
23:13:05 | Bagder | given enough time and sweat |
23:13:09 | Rori | of course |
23:13:21 | Coldtoast | where's the ID3 info stored in an MP3? |
23:13:23 | Rori | but some things have limitations due to hardware |
23:13:33 | Bagder | Coldtoast: in the begining or the end of the file |
23:13:51 | Coldtoast | beginning OR end? how odd |
23:13:59 | Bagder | v1 vs v2 id3 |
23:14:02 | Rori | so you have to read the entire file to read the tags? |
23:14:07 | Coldtoast | beginning or end depending on what version of ID3 it is I assume? |
23:14:07 | Bagder | no |
23:14:07 | | Join kenshin [0] (~dave@c-24-17-8-193.hsd1.wa.comcast.net) |
23:14:11 | Bagder | you can seek to the end |
23:14:17 | Bagder | Coldtoast: yes |
23:14:25 | Coldtoast | ok |
23:15:49 | Rori | Does it seem like every time I type something here it's a whinge? If so I apologise. I'm just speaking my mind without knowing much really. |
23:16:15 | Rori | Take it with a pinch of salt ;) |
23:16:18 | Bagder | you say things "I don't see why..." |
23:16:28 | Bagder | which sounds as if you question things |
23:16:59 | Bagder | at least in my ears |
23:17:00 | Rori | Well I don't because I don't know much so I say it without actually asking directly. Maybe I should just ask instead of putting it in such a way as it seems like a whinge :) |
23:17:36 | Coldtoast | think I'll go watch War of the Worlds when I wake up |
23:17:45 | Rori | Nothing wrong with questioning things. But I guess it is how it comes across that counts. |
23:17:50 | Rori | I saw it |
23:17:54 | Rori | well half of it |
23:18:04 | Rori | I was in the loo puking up a lot whilst at the cinema |
23:18:13 | Coldtoast | is it THAT bad?!? |
23:18:17 | Rori | something I ate did not agree with me |
23:18:19 | Rori | lol |
23:18:24 | Coldtoast | :) |
23:18:25 | Rori | yeah it was THAT bad ;) |
23:18:38 | Rori | I saw Tom Cruise' acting and it made me vomit |
23:18:46 | Coldtoast | I actually like Tom now |
23:18:56 | Rori | It was an OK movie from what I saw of it |
23:19:17 | Coldtoast | never really used to but he's done some films I LOVE in recent years; Minority Report, Vanilla Sky, Last Samurai |
23:19:26 | Rori | was lacking a little from a modern day spin on the story I thought. It stuck too close to the book which is a bit out of date now. |
23:19:41 | Rori | But the fighting machines were awesome! |
23:19:46 | Coldtoast | then I saw the full vid of the guy squirting him and how he reacted and I now really like him |
23:20:09 | Rori | and the sound they make will make you shat your pants |
23:20:19 | Coldtoast | nuff said |
23:20:24 | Rori | enjoy |
23:20:29 | Coldtoast | hope so |
23:20:43 | Coldtoast | not expecting it to be as enjoyable as Batman Begins but I hope I like it |
23:20:52 | Rori | it's enjoyable |
23:20:55 | Coldtoast | Batman Begins is absolutely AWESOME |
23:21:06 | Rori | don't try to look too close at the plotholes |
23:21:28 | Rori | Batman Begins had some plotholes but I looked past them |
23:21:41 | Rori | Because the acting and ideas in it were great |
23:22:17 | Coldtoast | tiem to get my player and update it |
23:22:22 | Rori | I want to see wotw again to catch the bits I missed while in the toilet chucking my guts up |
23:22:34 | Rori | downloading a cam |
23:22:43 | Rori | I think I have that right since I paid to see it anyhow ;) |
23:22:58 | Rori | and it will get deleted afterwards since the quality sucks |
23:23:18 | Rori | I will just flick to the bits I missed |
23:23:54 | Coldtoast | eh... no comment |
23:25:21 | | Quit PaulJ_ (Read error: 110 (Connection timed out)) |
23:28:47 | Coldtoast | there's still a prob with mono MP3s |
23:29:12 | Coldtoast | I get L+R fine, which is gret, but I also get a constant ticking thru them |
23:29:43 | Coldtoast | Bagder: if you play that MP3 I found from the other day, you should hear it |
23:30:38 | Coldtoast | aaah |
23:30:40 | Coldtoast | hold on |
23:30:55 | Coldtoast | it's the resampling I guess. the ones that tick are 22KHz |
23:31:24 | Coldtoast | the 64kbit, 44.1KHz ones are clean |
23:39:01 | | Quit Bagder ("Off to search for that connect-resetting peer guy!") |
23:40:02 | | Join Bagder [0] (~daniel@1-1-5-26a.hud.sth.bostream.se) |
23:42:52 | dionoea | hmmm ... the simulators seem to mess up the gnome control panel ... thats weird :) |
23:43:03 | Bagder | ? |
23:43:08 | Bagder | not for me |
23:43:19 | dionoea | it doesn't do it every time |
23:43:26 | | Join ghostiger [0] (~ghostiger@fdf84575d351d3c3.session.tor) |
23:43:26 | Bagder | it never did it for me |
23:43:34 | dionoea | it just happened twice since i've used it... really weird |
23:43:37 | Bagder | and I've used the sim on x11 since day 1 |
23:43:47 | dionoea | the panel vibrates and cpu usage sky rockets |
23:43:47 | Bagder | (day 1 the sim existed that is) |
23:43:55 | dionoea | killall gnome-panel fixes it ... |
23:44:13 | Bagder | I say that is a bug in gnome then |
23:44:19 | dionoea | possible :p |
23:44:36 | Bagder | the sim uses only plain x11 functions |
23:47:04 | | Quit noel_sad_sogn ("CGI:IRC (EOF)") |
23:48:01 | *** | Saving seen data "./dancer.seen" |
23:48:36 | * | Bagder just made a little alsa app that says "glitch" |
23:49:52 | Coldtoast | hey Bagder: how do you disable a soundcard in Linux? |
23:50:06 | Coldtoast | I have 2 in this machine and need to disable one cos PCM gets sent to the wrong one |
23:50:20 | ze | unload its module? |
23:50:20 | Bagder | unload the driver for it |
23:50:21 | ansivirus | Coldtoast: you can try rmmod |
23:50:44 | Coldtoast | I did try using the hotplug blacklist but it stopped working] |
23:50:48 | Coldtoast | ok |
23:51:12 | | Quit PaulJ (Remote closed the connection) |
23:51:18 | Coldtoast | by "stopped working" I mean it stopped beign disabled. Something must have been calling the driver |
23:51:22 | Bagder | also, the card is often identified by an alias in /etc/modules.conf that could be changed |
23:51:39 | Coldtoast | ok |
23:51:59 | Coldtoast | I have a good reason for hacing 2 cards, btw |
23:52:00 | Bagder | but I'm not really skilled in linux sound |
23:52:16 | Coldtoast | one's my pro card which I need for ASIO. the other's an Audigy 2 |
23:52:23 | dionoea | Coldtoast: you blacklisted it in /etc/hotplug/blacklist.d/<some filename> ? (works fine here) |
23:52:32 | Coldtoast | I use the pro card for recording guitar and the Audigy 2 for gaming |
23:53:08 | Coldtoast | is there another blacklist file in that die dionoea? |
23:53:27 | dionoea | "in that die" ? |
23:53:37 | Coldtoast | err. die=dir |
23:53:53 | dionoea | well ... you can put as many files as you wish |
23:54:06 | dionoea | they all get parsed when hotplug is launched |
23:54:17 | Coldtoast | in /etc/hotplug/ is there a file called "blacklist"? |
23:54:31 | dionoea | that was the old way of doing it i think |
23:54:43 | dionoea | but its there all right |
23:54:44 | Coldtoast | aah. then I was doing it the old way |
23:54:53 | Coldtoast | yeah. that may be why it doesn;t work too well |
23:54:55 | | Join muffti [0] (~5495d9b8@labb.contactor.se) |
23:54:55 | dionoea | what distro are you using ? |
23:55:00 | Coldtoast | Mandriva |
23:55:01 | muffti | hi |
23:55:46 | Bagder | hey |
23:56:06 | muffti | i need some help installing rockbox |
23:58:08 | Coldtoast | muffti: http://www.rockbox.org/twiki/bin/view/Main/IriverBoot |
23:58:49 | muffti | i've got a archos jukebox studio 10 |
23:58:55 | Coldtoast | OH |