| 00:03:15 | zeekoe | yep, i know, i saw it at the television once |
| 00:03:43 | | Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) |
| 00:03:51 | | Join webguest45 [0] (n=d55efcba@labb.contactor.se) |
| 00:04:01 | webguest45 | hi |
| 00:04:37 | | Quit webguest45 (Client Quit) |
| 00:08:55 | | Join Link9064 [0] (n=18ecb4e1@labb.contactor.se) |
| 00:09:27 | *** | Saving seen data "./dancer.seen" |
| 00:09:49 | Link9064 | whats the difference between the fmrecorder and fmrecorder8mb firmware? |
| 00:15:02 | zeekoe | the fmrecorder8mb is for 8mb fm recorders :-) |
| 00:15:21 | zeekoe | you can mod the recorder with an 8 mb chip if you want, see the wiki how to do it |
| 00:15:32 | zeekoe | you'll need some soldering skills though... |
| 00:15:54 | Link9064 | and what benefits are there in doing that? |
| 00:17:16 | zeekoe | extended battery life |
| 00:17:27 | zeekoe | more buffer space = less hard drive spinups |
| 00:21:57 | Link9064 | k, thx |
| 00:23:45 | | Quit matsl (Read error: 60 (Operation timed out)) |
| 00:24:30 | zeekoe | np |
| 00:35:54 | | Quit zeekoe ("Leaving") |
| 00:35:54 | pill | hi |
| 00:37:09 | | Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) |
| 00:41:55 | | Quit Link9064 ("CGI:IRC (EOF)") |
| 00:45:38 | Moos | good night @ all |
| 00:45:49 | | Quit Moos ("Parti") |
| 00:45:59 | | Quit markun () |
| 01:00 |
| 01:01:08 | | Join thegeek_ [0] (n=thegeek@s057b.studby.ntnu.no) |
| 01:01:08 | | Quit thegeek (Read error: 104 (Connection reset by peer)) |
| 01:06:59 | | Quit ender` (Connection timed out) |
| 01:09:27 | | Quit thegeek_ (Read error: 104 (Connection reset by peer)) |
| 01:11:26 | | Join thegeek [0] (n=thegeek@s057b.studby.ntnu.no) |
| 01:11:53 | | Quit Mojito () |
| 01:19:17 | | Quit cv_ ("changing servers") |
| 01:19:20 | | Join cv_ [0] (n=verm@neko.mahou.org) |
| 01:23:13 | | Join Yono [0] (n=Yono@69-169-174-248.bflony.adelphia.net) |
| 01:34:28 | | Quit preglow ("leaving") |
| 01:40:45 | | Quit cYmen ("zZz") |
| 01:40:45 | | Quit Yono (Read error: 104 (Connection reset by peer)) |
| 01:41:40 | | Quit rasher (Remote closed the connection) |
| 01:43:26 | | Quit _aLF ("Leaving") |
| 01:51:37 | | Quit matsl (Remote closed the connection) |
| 02:00 |
| 02:01:14 | | Quit linuxstb ("CGI:IRC") |
| 02:09:28 | *** | Saving seen data "./dancer.seen" |
| 02:24:06 | | Quit DangerousDan ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 02:30:27 | | Join hicks [0] (n=hicks@zeus.mups.co.uk) |
| 02:52:46 | | Join bagawk [0] (i=1000@unaffiliated/bagawk) |
| 03:00 |
| 03:03:24 | | Quit hicks (Remote closed the connection) |
| 03:05:47 | | Quit bagawk ("Leaving") |
| 03:49:26 | | Quit ansivirus ("Leaving") |
| 04:00 |
| 04:05:32 | | Join QT [0] (i=as@madwifi/users/area51) |
| 04:09:30 | *** | Saving seen data "./dancer.seen" |
| 04:17:25 | | Quit QT_ (Connection timed out) |
| 04:18:48 | | Quit HCl (Remote closed the connection) |
| 04:18:49 | | Join HCl [0] (i=hcl@titania.student.utwente.nl) |
| 04:20:28 | | Join ansivirus [0] (n=ansiviru@ppp-69-148-93-202.dsl.rcsntx.swbell.net) |
| 04:54:03 | | Join DarkShadow [0] (n=4360fb7f@labb.contactor.se) |
| 04:57:45 | | Quit DarkShadow (Client Quit) |
| 06:00 |
| 06:09:34 | *** | Saving seen data "./dancer.seen" |
| 06:43:59 | | Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) |
| 06:50:01 | | Nick Maxime is now known as Maxime` (n=flemmard@fbx.flemmard.net) |
| 06:57:42 | | Quit matsl (Remote closed the connection) |
| 07:00 |
| 07:26:22 | | Join LinusN [0] (n=linus@labb.contactor.se) |
| 07:29:31 | amiconn | morning |
| 07:30:16 | LinusN | morning |
| 07:30:19 | * | amiconn just committed the xing header fixes |
| 07:30:25 | LinusN | wonderful |
| 07:30:40 | amiconn | I've done some research regarding the bitshifted recordings. |
| 07:30:52 | amiconn | Really interesting... |
| 07:31:21 | amiconn | (1) This is most likely *not* the s/pdif malfunction, but something else |
| 07:31:59 | amiconn | It does also happen with analog recording, and it did not happen with a >8 hour s/pdif recording.... |
| 07:32:08 | amiconn | ...all with q=7 |
| 07:33:10 | amiconn | It seems that it might happen anytime, but the probability is very very low unless a high quality setting is used *and* the recording level is high |
| 07:33:55 | amiconn | My error-free s/pdif recording was made from a "quiet" CD |
| 07:34:57 | amiconn | (2) I wrote a little tool to bitshift blocks in a file. With this tool, I was able to completely repair yesterday's test recording.... |
| 07:35:51 | amiconn | ....after analysing (with a hex editor) at which point the recording was shifted by which amount |
| 07:36:28 | LinusN | wow |
| 07:36:50 | amiconn | (3) The MAS shifts both up and down. Yesterday's recording had +1 and -1 bit, but iirc I also observed +2 bits in another test |
| 07:37:39 | amiconn | See http://www.rockbox.org/irc/rockbox-20050914.txt starting 22:44:35 |
| 07:41:53 | LinusN | so we should release a tool to repair recordings... |
| 07:42:00 | LinusN | silly mas! |
| 07:42:18 | | Join B4gder [0] (n=daniel@static-213-115-255-230.sme.bredbandsbolaget.se) |
| 07:43:06 | amiconn | The hardest part is the shift amount analysis |
| 07:43:17 | LinusN | indeed |
| 07:43:43 | amiconn | I just started a test recording with archos firmware, just to see whether it has the same problem |
| 07:44:04 | amiconn | (q=7 and a sufficient recording level) |
| 07:53:02 | LinusN | i sincerely hope that it happens with the original firmware too :-) |
| 08:00 |
| 08:09:36 | *** | Saving seen data "./dancer.seen" |
| 08:25:00 | | Join ender` [0] (i=ychat@84.52.165.220) |
| 08:51:41 | | Quit Lynx_awy (Read error: 104 (Connection reset by peer)) |
| 08:52:03 | | Join Lynx_awy [0] (n=lynx@tina-10-4.genetik.uni-koeln.de) |
| 10:00 |
| 10:02:09 | | Join linuxstb [0] (n=5343d4aa@labb.contactor.se) |
| 10:06:01 | | Join Dan [0] (i=Bollocks@tredwell.plus.com) |
| 10:06:11 | Dan | :) |
| 10:09:39 | *** | Saving seen data "./dancer.seen" |
| 10:14:16 | linuxstb | Does anyone have any opinions on how the iPod Photo compares with the iRiver H340 - in terms of hardware and audio quality? Does anyone know of any reviews comparing them? |
| 10:15:58 | Zagor | reviews mentioning audio quality mostly seem to compare the headphones. I doubt you'd hear much difference between various players using the same headphones. |
| 10:17:05 | linuxstb | I've been browsing the ipodlinux project and looking at some of the code, and I think an ipod port of Rockbox is very do-able. But I'm having trouble thinking of a reason to buy an ipod... |
| 10:17:24 | Zagor | :-) |
| 10:18:00 | linuxstb | ipodlinux's problems seem to be: lack of a good application, and struggling with writing Linux drivers to fully support the hardware. |
| 10:18:10 | linuxstb | i.e. they understand the hardware, but Linux is getting in the way. |
| 10:19:42 | LinusN | that is why porting linux to an audio player is a bad idea in general |
| 10:19:57 | LinusN | especially if you plan on using it as a portable audio player |
| 10:20:29 | linuxstb | I don't think anyone involved with Rockbox would disagree with that. |
| 10:20:59 | B4gder | having written a few linux drivers lately, I would say it isn't that hard really... |
| 10:21:15 | B4gder | I think they just lack developers |
| 10:21:17 | LinusN | still, porting linux for the fun of it is of course a completely different thing |
| 10:22:36 | B4gder | I wonder if their bootloader could more or less start rockbox instead of linux |
| 10:22:52 | linuxstb | B4gder: Absolutely. |
| 10:23:11 | B4gder | I guess it should be just about the same |
| 10:23:19 | linuxstb | My understanding is that the iPod boots by reading the firmware from a boot partition. |
| 10:24:02 | linuxstb | So iPodLinux simply "dd"s a new image to the boot partition, which includes the bootloader, Linux and the original f/w |
| 10:24:15 | B4gder | aha |
| 10:24:40 | linuxstb | The bootloader itself copies itself to the SRAM, copies the appropriate image to the required address in RAM, and then jumps to it. |
| 10:25:17 | linuxstb | The bootloader contains a simple keyboard and LCD driver - but no IDE driver. |
| 10:26:56 | linuxstb | The code is here: http://cvs.sourceforge.net/viewcvs.py/ipodlinux/tools/ipodloader/ |
| 10:27:22 | LinusN | some guys are just lunatics: http://ipodlinux.org/stories/piezo/index.html |
| 10:27:28 | B4gder | so how does the bootloader get the image into ram? |
| 10:27:42 | B4gder | if it can't read from disk |
| 10:28:38 | linuxstb | I think the ipod itself loads it. i.e. it convinces the ipod that the firmware is double the normal size. |
| 10:28:49 | B4gder | ok, sounds clever enough |
| 10:29:59 | B4gder | and it also means they never flash the ipod |
| 10:30:11 | linuxstb | Nope. |
| 10:30:21 | Zagor | archos dejavu |
| 10:30:24 | B4gder | what a cosy archos-feeling ;-) |
| 10:31:28 | B4gder | so getting Rockbox instead of linux would be rather easy |
| 10:31:37 | B4gder | once the initial things are ported |
| 10:31:48 | linuxstb | That's my thought. |
| 10:32:19 | linuxstb | The main problem would be using the co-processor - otherwise we would struggle badly with real-time playback. |
| 10:32:31 | B4gder | why? |
| 10:32:35 | linuxstb | But that would be much easier with Rockbox than Linux I expect. |
| 10:32:37 | B4gder | 80Mhz arm should be enough |
| 10:32:44 | B4gder | even single-core |
| 10:32:51 | linuxstb | Maybe - but not for all the codecs. |
| 10:33:10 | B4gder | no, possibly not |
| 10:33:29 | linuxstb | I'm not saying it's a problem - just something new to Rockbox that would need to be done. |
| 10:33:35 | B4gder | yes |
| 10:34:27 | linuxstb | I'm also not sure how "usb mode" works. That may not work with ipodlinux. |
| 10:34:48 | B4gder | right, and what fs do the ipods use? |
| 10:35:00 | linuxstb | FAT32 or HFS |
| 10:35:23 | B4gder | ok, so working on fat32 only would be a start |
| 10:37:40 | linuxstb | Yes. But Mac's can use FAT32 ipods, so I don't think it's a show-stopper for Mac users. |
| 10:37:44 | linuxstb | (I think) |
| 10:38:42 | | Join amiconn_ [0] (n=jens@p54BD7C6E.dip.t-dialin.net) |
| 10:41:58 | linuxstb | So, is anyone tempted to buy an ipod? |
| 10:42:37 | B4gder | I'm quite tempted to see a serious Rockbox attempt on ipod at least |
| 10:46:40 | | Join cYmen [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
| 10:48:40 | linuxstb | Does amiconn's last commit mean there's nothing left to do before 2.5? |
| 10:52:31 | pill | hi |
| 10:53:09 | pill | does anyone know if rockbox could read .cue files, providing the appropriate patch? |
| 10:53:50 | CoCoLUS | a cue file is just another version of a playlist |
| 10:53:57 | pill | yeah |
| 10:54:15 | CoCoLUS | but with a little catch :) |
| 10:54:21 | pill | indeed :) |
| 10:54:51 | LinusN | cue files don't really fit into the rockbox architecture |
| 10:54:51 | CoCoLUS | rockbox supports bookmarks... maybe a plugin which reads the cue points and converts it into bookmarks |
| 10:55:31 | LinusN | so there are numerous special cases that need to be taken care of |
| 10:56:01 | LinusN | like resuming, bookmarks, queueing, playlist editige etc |
| 10:56:05 | LinusN | editing |
| 10:56:09 | | Quit amiconn (Read error: 110 (Connection timed out)) |
| 10:56:09 | | Nick amiconn_ is now known as amiconn (n=jens@p54BD7C6E.dip.t-dialin.net) |
| 10:56:34 | linuxstb | Changing that's been on my to-do list for years. But it's a low priority. |
| 10:56:42 | | Join markun [0] (n=markun@bastards.student.ipv6.utwente.nl) |
| 10:57:05 | CoCoLUS | and, the cue file can contain additional artist/title info... |
| 10:57:10 | LinusN | there is a very old patch for this, but it was kind of half hearted |
| 10:57:25 | linuxstb | Yes - I wrote that :) |
| 10:57:30 | LinusN | :-) |
| 10:57:45 | linuxstb | The criticisms were right, but I never found the time to resolve them. |
| 10:58:03 | linuxstb | I can't even find a copy of it now. |
| 10:58:07 | LinusN | and it is even harder now, with the dynamic playlists and all |
| 10:58:25 | LinusN | linuxstb: you can find it in the mailing list archives |
| 10:58:37 | CoCoLUS | but why even use cue files? |
| 10:58:45 | CoCoLUS | if there's gapless playback anyway? |
| 10:59:17 | linuxstb | My reason is that I have long radio recordings, and I want to be able to jump to specific points without having to split the file. |
| 10:59:36 | linuxstb | I would also like to be able to create the cuefiles during playback on Rockbox. |
| 10:59:50 | linuxstb | Sort of like the splitedit plugin. |
| 10:59:57 | linuxstb | But without the splitting. |
| 11:00 |
| 11:00:42 | LinusN | the question is how rockbox should treat cue files |
| 11:01:02 | | Join ep0ch [0] (n=ep0ch@84.12.153.190) |
| 11:01:09 | LinusN | it could treat them as X individual tracks |
| 11:01:17 | LinusN | or as a playlist |
| 11:01:33 | linuxstb | I think treating it like a playlist would fit into Rockbox best. |
| 11:01:40 | ep0ch | can anyone else confirm on ihp that for some mp3s the codec bitrate is no longer displayed in wps? |
| 11:01:50 | linuxstb | So each item in the playlist would need extending to include the start and end time in the file. |
| 11:02:00 | LinusN | ep0ch: show me one of those mp3's |
| 11:02:06 | ep0ch | i will upload |
| 11:02:07 | ep0ch | hangon |
| 11:02:57 | CoCoLUS | linuxstb: why? end time of track x is start time of track x + 1? |
| 11:03:20 | LinusN | linuxstb: ok, so all playlist entries have a track name plus start/endpoints? |
| 11:03:21 | linuxstb | What if you only insert one track from the cuefile into the playlist. |
| 11:03:35 | linuxstb | LinusN: Yes. |
| 11:03:40 | LinusN | sounds reasonable |
| 11:04:17 | LinusN | ok, and the browser will treat a cue file like a subdirectory? |
| 11:04:19 | CoCoLUS | ah |
| 11:04:22 | CoCoLUS | now i get it... |
| 11:05:05 | LinusN | in fact, extending the playlist with start/endpoints opens up the door to beat-matched mixes... |
| 11:05:12 | linuxstb | LinusN: What does the browser do now with a playlist? (I don't use them). |
| 11:05:24 | linuxstb | Is that treated like a subdir? |
| 11:05:38 | LinusN | it stores the file position for each line in the list |
| 11:05:48 | LinusN | the browser plays the list |
| 11:06:08 | LinusN | unless you open it in the playlist editor |
| 11:09:21 | linuxstb | I can't think of an easy way to create cuefiles though. I would like to do that from the normal WPS whilst listening - not with a plugin. |
| 11:09:46 | linuxstb | i.e. when listening to a long recording, I want to index it there and then. |
| 11:10:53 | | Join preglow [0] (n=thomjoha@hekta.edt.aft.hist.no) |
| 11:12:43 | ep0ch | linusN: While the mp3s are uploading the line in my wps that i've always had is: %ac%s%t2%ac%fc %?fv<%fbkbps VBR|%fbkbps CBR|> %ffHz |
| 11:12:47 | CoCoLUS | i'm sorry if thats a dumb question... but... can the decoders even jump to such a specific timestamp in the file? the cue files specifiy the stamp up to 1/100 seconds |
| 11:13:13 | ep0ch | linusN: so it might be the WPS that is broken not the mp3 |
| 11:13:30 | Zagor | linuxstb: perhaps an extension of the bookmarking system |
| 11:14:05 | preglow | Zagor: going for a release now? |
| 11:14:30 | LinusN | ep0ch: the last "|" in the vbr conditional shouldn't be there |
| 11:14:43 | LinusN | after "CBR" |
| 11:14:46 | ep0ch | linusN: ok |
| 11:15:05 | LinusN | that would have worked before the enum conditionals, but not anymore |
| 11:15:13 | ep0ch | LinusN: ahh ty |
| 11:15:33 | linuxstb | CoCoLUS: The codecs don't seek very accurately at the moment - that's something else I would like to change. |
| 11:15:39 | Zagor | preglow: yes, but I'm a bit disconnected at the moment. I'll just press the button the told to. :-) |
| 11:15:43 | | Join tvelocity [0] (n=tony@ipa251.6.tellas.gr) |
| 11:15:53 | Zagor | s/the/when/ |
| 11:16:04 | linuxstb | They should seek to the closest frame before the seek point, and then discard the necessary number of decoded samples - to give sample-accurate seeking. |
| 11:16:35 | linuxstb | This obviously isn't possible on the Archos. |
| 11:16:49 | LinusN | linuxstb: accurate seeking will still be nearly impossible with MP3 VBR files |
| 11:17:11 | linuxstb | Yes. But easy with everything else. |
| 11:17:19 | ep0ch | linusN: yeah that was it, fixed now, thankyou |
| 11:17:51 | LinusN | you're welcome |
| 11:22:19 | preglow | i don't see the point with sample-accurate seeking, apart from .cue support |
| 11:22:30 | preglow | sample accurate seeking is a pain with vbr files |
| 11:22:31 | linuxstb | Is anyone going to tell Zagor to press the release button? Or are there things left to do? |
| 11:23:11 | ep0ch | testing? |
| 11:27:38 | B4gder | I guess we neeed amiconn's and LinusN's blessing |
| 11:27:56 | LinusN | yes you do |
| 11:28:03 | linuxstb | :) |
| 11:28:31 | B4gder | I gave it thumbs up several days ago ;-) |
| 11:47:21 | linuxstb | preglow: sample accurate seeking is only a paid with MP3 files. I don't think there's any problem with the other formats. |
| 11:47:26 | linuxstb | s/paid/pain/ |
| 11:47:52 | linuxstb | So I see no reason not do it where it is easy. |
| 11:49:02 | preglow | linuxstb: might not be, mp3 is the only format i'm pretty familiar with the internals of |
| 11:49:26 | preglow | then again, mp3s is pretty much the only format used with cue files |
| 11:49:56 | linuxstb | FLAC CUE is a common backup format for CDs. |
| 11:50:23 | linuxstb | I would use it for CBR MP2 files. |
| 11:50:33 | | Join ashridah [0] (i=ashridah@220-253-121-1.VIC.netspace.net.au) |
| 11:50:39 | pill | i have another question |
| 11:50:57 | pill | can i make terminalx9 the default font for .nfo files? |
| 11:51:04 | pill | somehow |
| 11:51:34 | pill | since more ascii art is really jaw-dropping |
| 11:51:44 | pill | most* |
| 11:51:46 | pill | i mean |
| 11:51:57 | preglow | not yet, i believe |
| 11:52:06 | pill | okay |
| 11:52:49 | linuxstb | A problem would be that if we added cue-support without accurate seeking in VBR MP3, users would complain. |
| 11:53:03 | pill | users always complain :) |
| 11:53:08 | pill | anyway |
| 11:53:14 | linuxstb | I think there would be a demand for a slow-seeking mode which scanned the file. |
| 11:53:42 | pill | i wish to tell you guys that i use rockbox 100% of the time since initial iriver build, and i REALLY appreciate your work. |
| 11:53:49 | pill | i'm willing to donate |
| 11:54:01 | | Quit tvelocity ("Leaving") |
| 11:55:20 | preglow | linuxstb: could just as well scan the mp3 on first access and create bookmarks for all tracks, then, so it's saved for later use |
| 12:00 |
| 12:01:29 | linuxstb | Does the Xing VBR header contain seek points? |
| 12:02:19 | preglow | yes |
| 12:02:24 | preglow | about a 100, or so |
| 12:02:36 | linuxstb | So they could be the cue points? |
| 12:02:46 | preglow | perhaps |
| 12:03:45 | preglow | you're talking about modifying the file to contain the seek points we want? |
| 12:04:07 | LinusN | the seek points are not exact |
| 12:04:27 | preglow | i'd expect not, since they're bytes... |
| 12:04:57 | preglow | what data does a bookmark contain? |
| 12:05:13 | preglow | exact file offset, i take it? |
| 12:05:58 | linuxstb | So what exactly is in the Xing header? I assumed a seek point would contain the byte offset in the file of a frame, and the position in the audio (in ms or samples) of that frame. |
| 12:06:10 | preglow | oh no |
| 12:06:13 | preglow | it's just a byte |
| 12:06:24 | preglow | kind of a file offset percentage, i guess |
| 12:06:47 | LinusN | yes 1/256 of the file size |
| 12:06:49 | preglow | seek to x/255*filesize |
| 12:06:52 | preglow | then search from there |
| 12:09:13 | pill | the difficulty with cue files would be to read track info, artist and album and all, too.. |
| 12:09:24 | pill | so it's a whole different way of thinking |
| 12:09:43 | *** | Saving seen data "./dancer.seen" |
| 12:09:49 | * | pill shrugs |
| 12:10:23 | preglow | not much of a problem, if you ask me |
| 12:10:44 | preglow | the cue reader will most certainly have to be in the rockbox core anyway, it's just a pretty weird playlist format |
| 12:10:51 | pill | yes |
| 12:10:59 | pill | well yes |
| 12:11:14 | pill | but it's not using id3 at all, then |
| 12:11:19 | preglow | no |
| 12:11:22 | pill | of just for the genre |
| 12:11:25 | pill | and the year |
| 12:11:38 | | Quit preglow ("woops, reboot") |
| 12:11:59 | linuxstb | You would need some kind of priority setting - ID3, then cuefile "album" info and then cuefile "track info". |
| 12:12:34 | linuxstb | e.g. the Artist could be in the ID3, or at the start of the cuefile, or as part of the track info in the cuefile. |
| 12:13:18 | linuxstb | So you would want to check all three, and use the last one. |
| 12:13:32 | | Join preglow [0] (n=50cb263c@labb.contactor.se) |
| 12:13:41 | preglow | bloody amateur server admins rebooting all the time |
| 12:13:49 | preglow | but yes |
| 12:13:53 | pill | :) |
| 12:14:12 | preglow | a problem might be loading all the track info from the cue file at once, rockbox is used to loading track info as it needs it |
| 12:14:26 | linuxstb | But satisfactory seeking is probably the hardest part. |
| 12:14:31 | preglow | but that's not much of a problem, i guess, just look into the cue file instead, when you used to read metadata from the files |
| 12:14:48 | preglow | linuxstb: well, there is just one way of doing it: walking the bitstream |
| 12:15:04 | preglow | which is pretty slow, i'm afraid |
| 12:15:14 | linuxstb | I think foobar does that. |
| 12:15:23 | preglow | we could spawn a thread doing this when a user plays the cue the first time |
| 12:15:28 | preglow | and the results must be saved |
| 12:15:37 | preglow | linuxstb: that's exactly what i does, and slowly too |
| 12:16:15 | linuxstb | As it's only needed for VBR MP3, a plugin like VBRfix would probably be cleaner. |
| 12:17:16 | preglow | well |
| 12:17:29 | linuxstb | Why hasn't anyone solved this problem before with a file header? i.e. like the Xing header but better. |
| 12:17:33 | preglow | as long as it's done transparently, for example if the cue loader can't find a suitable set of bookmarks/seek points |
| 12:17:47 | preglow | linuxstb: well, there's vbri, but it's not very widely spread |
| 12:18:02 | linuxstb | Let's help spread it. |
| 12:19:35 | preglow | the vbri header lets you define full precision seek points, and an arbitrary number of them too |
| 12:19:49 | preglow | at least i _think_ it is full precision, can't exactly remember the spec |
| 12:19:53 | * | linuxstb searches for vbri and finds Variable Bore Rams Inc. |
| 12:20:07 | preglow | http://www.codeproject.com/audio/MPEGAudioInfo.asp |
| 12:20:12 | preglow | there's a header description there |
| 12:21:19 | preglow | don't know how well it coexists with the other headers, and that might be a problem |
| 12:21:31 | preglow | i'm also not sure i want rockbox to modify any files |
| 12:22:30 | linuxstb | 'm just talking about a VBRI-fix plugin, and Rockbox supporting it on playback. |
| 12:22:54 | preglow | hmm |
| 12:23:05 | preglow | well, that plugin would also have to read cue files, then |
| 12:23:17 | linuxstb | Of course. Not a problem. |
| 12:23:19 | preglow | still not sure i'm thrilled about it |
| 12:23:45 | preglow | granted my files are correctly made, i'd like them to be playable without having to modify them |
| 12:24:01 | preglow | but it's not the worst compromise i've ever heard of |
| 12:24:03 | linuxstb | IMO, they are not correctly made - they don't have a seek table. |
| 12:24:20 | preglow | oh, they do, but not one suitable for cue files |
| 12:24:40 | preglow | you can seek perfectly well with xing seek points, but not exactly |
| 12:24:58 | preglow | but of course, not having to depend on external files for seek points would be nice |
| 12:25:14 | preglow | so if vbri headers will coexist nicely with others, it's a decent idea, i suppose |
| 12:25:56 | pill | oh, you're talking about modifying files? |
| 12:26:02 | pill | like with adding geplaygain? |
| 12:26:08 | pill | replaygain* |
| 12:26:09 | linuxstb | It just seems to make sense to fix the limitations of the MP3 format, rather than compromise when playing back. |
| 12:26:55 | pill | imho, having to modify files that are properly tagged is not satisfying. |
| 12:27:06 | pill | especially if you have sfv files that come with them |
| 12:27:30 | pill | that's why i didn't add replaygain to my files |
| 12:27:56 | preglow | linuxstb: the fix will only apply to us |
| 12:28:12 | preglow | linuxstb: and if we ever dump across a file WITH a vbri header, how do we know it's not one we made? |
| 12:28:37 | preglow | i suppose the vbri header we make will have to have seek points defined according to cue track boundaries |
| 12:28:59 | preglow | s/suppose/assume/ |
| 12:29:12 | linuxstb | Of course. |
| 12:29:42 | linuxstb | But I don't use VBR MP3, so my opinion shouldn't count for much. |
| 12:30:01 | preglow | well, no, but you are suggesting how to better use them ;) |
| 12:30:07 | preglow | i don't use them much myself |
| 12:30:16 | preglow | but i've got a couple of cue/mp3 albums i'd like to be supported |
| 12:30:41 | pill | i have cue for some dnb albums |
| 12:30:46 | preglow | still, finding out if a vbri header is generated by us, and hence has got suitable seek points or not, will be tricky |
| 12:30:51 | preglow | pill: yeah, me too |
| 12:30:54 | pill | :) |
| 12:31:11 | linuxstb | I guess there's three options - store seek points in a VBRI header (or similar), store them in the cuefile, or store them in an external file. |
| 12:31:30 | pill | ext file is the best |
| 12:31:32 | pill | to me |
| 12:31:39 | preglow | well, in principle, but they'd be easy to loose |
| 12:32:24 | preglow | but it wouldn't modify any files |
| 12:32:28 | linuxstb | pill: Why don't you want to modify your MP3 files and then generate new sfv files? What do you need the sfv files for? |
| 12:32:29 | preglow | which i consider good |
| 12:33:00 | linuxstb | I'm assuming that adding a VBRI header wouldn't affect playback in other players. |
| 12:33:11 | preglow | 'course |
| 12:33:14 | preglow | and i know nothing about that |
| 12:33:28 | preglow | afaik, vbri headers are few and far between |
| 12:33:50 | preglow | my guess is also that you'd see either a xing OR a vbri file |
| 12:33:52 | preglow | ehh, hedaer |
| 12:33:54 | preglow | not both |
| 12:34:19 | pill | linuxstb: i have 250GB of mp3s, all properly tagged, and when someone gets these off me, he checks with the sfv |
| 12:34:44 | linuxstb | How many of those have a cuefile? |
| 12:34:52 | pill | that is the good question |
| 12:34:52 | pill | :) |
| 12:34:57 | pill | i knew it would arise |
| 12:35:01 | pill | hmm |
| 12:35:08 | pill | i'd say 20/30 albums |
| 12:35:19 | Dan | what do you use to tag them? |
| 12:35:27 | pill | i dont tag them |
| 12:35:31 | pill | they're already tagged |
| 12:35:36 | Dan | o |
| 12:35:41 | pill | the cue comes from EAC |
| 12:36:14 | pill | but it's the same with replaygain |
| 12:36:21 | linuxstb | So it wouldn't be a big job to create a second VBRI-enabled copy of your 30-albums. |
| 12:36:26 | pill | bah |
| 12:36:37 | pill | well, technically yes |
| 12:36:58 | pill | but it's not the most versatile way to go |
| 12:37:05 | pill | (just my 2 cents) |
| 12:37:24 | preglow | not much, no, but the problem remains, you might have to strip away some headers that were there before, vbri headers might not be widely supported |
| 12:37:33 | preglow | all of which can be researched, so someone go ahead ;) |
| 12:37:53 | preglow | i need to eat |
| 12:39:07 | linuxstb | All I'm really suggesting is that Rockbox could support the VBRI tag. If there was a demand for alternative methods of accurate seeking in a VBR MP3 file, we could add those as well. |
| 12:39:55 | linuxstb | But if VBRI tags worked, I personally would be happy with that solution. |
| 12:41:28 | preglow | we'll probably supports vbri, yes |
| 12:41:34 | preglow | only problem is the variable size seek table |
| 12:41:38 | pill | it's be better than no support at all, that's for sure. |
| 12:42:47 | linuxstb | All the codecs (FLAC, Ogg etc) have variable sized seek tables. |
| 12:43:56 | preglow | yeah, sure, but nothing rockbox has parsed from mp3s thus far |
| 12:44:01 | preglow | how do you deal with the variable sizes, then? |
| 12:44:03 | preglow | malloc? :-) |
| 12:44:23 | linuxstb | Yep. |
| 12:51:32 | preglow | well, well |
| 12:51:38 | preglow | i don't expect we'll ever be rid of malloc anyway |
| 12:51:46 | preglow | not in something as diverse as rockbox is becoming |
| 13:00 |
| 13:05:31 | | Join Moos [0] (i=DrMoos@m113.net81-66-159.noos.fr) |
| 13:05:46 | Moos | Hi guys ! |
| 13:09:35 | Moos | still freeze here? :) |
| 13:09:51 | | Quit linuxstb ("CGI:IRC (Ping timeout)") |
| 13:14:25 | | Quit markun () |
| 13:20:31 | | Join rasher [0] (n=jonas@62.79.64.148.adsl.hs.tiscali.dk) |
| 13:20:58 | | Quit edx (Read error: 110 (Connection timed out)) |
| 13:23:16 | rasher | Is iriver the only player without a hardware poweroff? |
| 13:23:28 | rasher | (currently supported) |
| 13:23:55 | flurble | ? |
| 13:24:08 | rasher | I'll try again.. |
| 13:24:30 | rasher | Do all the Archos devices have a hardware-controlled poweroff? |
| 13:26:25 | LinusN | yes |
| 13:26:35 | LinusN | (i don't really know about the ondio though) |
| 13:27:07 | LinusN | but all the other models have a hardware poweroff mechanism |
| 13:27:58 | amiconn | Ondio is same as fm/v2 recorder |
| 13:28:11 | amiconn | Hardware poweroff by pressing OnOff >= 10 seconds |
| 13:28:31 | flurble | does the iriver not have a hardware poweroff, then? |
| 13:28:40 | flurble | what's it mean by hardware poweroff? |
| 13:29:09 | rasher | That the software doesn't have to react |
| 13:29:19 | * | HCl prods Moos |
| 13:29:29 | rasher | Rockbox could chose to ignore the press on STOP and not shut down the player. |
| 13:29:39 | flurble | ah |
| 13:29:48 | rasher | Not so if it's done in hardware |
| 13:37:06 | | Join edx [0] (i=edx@p54A87B96.dip.t-dialin.net) |
| 13:48:42 | | Quit ender` (Read error: 110 (Connection timed out)) |
| 13:50:07 | rasher | Does volume-triggered recording work on Ondiofm? |
| 13:55:40 | amiconn | I didn't test it, but it should work |
| 13:57:21 | rasher | Good, wasn't entirely clear from the commit message |
| 13:57:31 | rasher | I'm fixing up the changelog |
| 14:00 |
| 14:03:36 | | Quit Febs (Read error: 110 (Connection timed out)) |
| 14:09:30 | | Nick preglow is now known as prelol (n=50cb263c@labb.contactor.se) |
| 14:09:45 | *** | Saving seen data "./dancer.seen" |
| 14:09:50 | | Join preglow [0] (n=thomjoha@hekta.edt.aft.hist.no) |
| 14:10:13 | | Quit prelol ("out") |
| 14:10:57 | rasher | How does http://www.rockbox.org/twiki/pub/Main/ReleaseNotes/ReleaseNotes-25.txt look? |
| 14:11:07 | CoCoLUS | texty :) |
| 14:11:51 | rasher | Well yes. I was aiming for "what could be sent to the mailinglist" |
| 14:12:54 | rasher | http://www.rockbox.org/twiki/bin/view/Main/ReleaseNotes is the wiki version |
| 14:13:00 | rasher | (will be moved to ReleaseNotes25 |
| 14:14:17 | CoCoLUS | i like it, but i thinkt he iriver part should be a bit more elaborate |
| 14:14:39 | CoCoLUS | there'll be a -lot- of iriver users reading this |
| 14:15:29 | rasher | I think I'll just put a link to each ports main page |
| 14:16:04 | CoCoLUS | a big fat notice on the first page... "this release concers archos products only - it's not an iriver-release" |
| 14:16:06 | Moos | http://www.rockbox.org/twiki/bin/view/Main/IriverStatus |
| 14:16:59 | rasher | CoCoLUS: The Rockbox project is pleased to announce the immediate availability of Rockbox 2.5 for Archos Jukebox 5000, 6000 and Studio, Archos Jukebox Recorder 6, 10, 15 and 20, Archos Jukebox Recorder v2, Archos Jukebox FM Recorder, Archos Ondio FM and Archos Ondio SP. |
| 14:17:02 | rasher | I think that covers it. |
| 14:18:14 | rasher | and if it doesn't, there'll be public ridicule. |
| 14:18:52 | CoCoLUS | that sentence is waaaay to large. mistic-users won't eben read it halfway through. |
| 14:18:57 | CoCoLUS | even, even |
| 14:19:26 | rasher | Hence, public ridicule. |
| 14:19:43 | rasher | I really don't want to litter this text with handholding for people without reading comprehension |
| 14:20:14 | CoCoLUS | really, i personally think that the readme is fine, just imaging the ruckus in this channel the day someone from the board notices the 2.5 release... |
| 14:21:29 | rasher | The readme? |
| 14:22:20 | CoCoLUS | the release notes. |
| 14:22:22 | rasher | Updated the wiki page with links to the ports pages |
| 14:23:03 | rasher | Ah. Well, I'm sure you're right, but I don't think there should be huge notices about it not being for iriver |
| 14:23:16 | CoCoLUS | one last thing, you should really add a remark at 4.2 about the remote not working |
| 14:23:21 | CoCoLUS | thats a major for most users |
| 14:24:22 | rasher | Hm. I don't want to be too specific, because the entire section 4 is mostly a "oh, by the way" |
| 14:24:33 | rasher | Think I'll hint at "missing features" |
| 14:24:49 | rasher | Or something like that |
| 14:26:21 | CoCoLUS | "major missing features: full remote support, ..." |
| 14:26:25 | CoCoLUS | is enough, imho |
| 14:26:28 | CoCoLUS | but you're the writer :) |
| 14:26:38 | CoCoLUS | do something poetic... |
| 14:30:14 | | Join hshah [0] (n=c2c92012@labb.contactor.se) |
| 14:31:23 | rasher | http://www.rockbox.org/twiki/bin/rdiff/Main/ReleaseNotes you won |
| 14:34:06 | CoCoLUS | yeah :) |
| 14:35:02 | | Quit B4gder ("Lämnar") |
| 14:35:53 | | Join zhilik [0] (n=zhilik@ppp83-237-231-206.pppoe.mtu-net.ru) |
| 14:45:47 | CoCoLUS | just tried to apply an image-using wps the first time |
| 14:45:56 | CoCoLUS | do i need to enable the images somewhere? :) |
| 14:46:22 | rasher | Nope |
| 14:46:28 | rasher | Perhaps you got an "old" wps? |
| 14:46:34 | rasher | The image format changed a few weeks ago |
| 14:46:45 | rasher | I suspect a lot of wps havent been updated |
| 14:48:27 | CoCoLUS | most likely. |
| 14:53:20 | CoCoLUS | found a new one. :) |
| 14:53:47 | CoCoLUS | hm... large font... lots of text scrolling... does that cost batter? :) |
| 14:53:57 | rasher | Doubt it |
| 14:55:08 | CoCoLUS | well i'll know if it stops playing during the ride home... which starts now. bye |
| 15:00 |
| 15:05:59 | preglow | an mp3 player that runs on batter, now that sounds good for the environment |
| 15:06:37 | rasher | Better than running it on dead kittens (http://slashdot.org/article.pl?sid=05/09/14/2355223&tid=133&tid=126) |
| 15:07:18 | preglow | haha, yeah, saw it |
| 15:07:30 | preglow | better make it run on dogs |
| 15:07:33 | preglow | i like kittens :P |
| 15:10:33 | | Join linuxstb [0] (n=linuxstb@host213-123-154-169.in-addr.btopenworld.com) |
| 15:10:56 | rasher | Of course it was just BILD misquoting the guy. Still amusing though. |
| 15:14:21 | | Join t0mas [0] (n=Tomas@unaffiliated/t0mas) |
| 15:15:15 | Moos | Linus,amiconn: What remains it to do before the release ? bugfixes for all bugs listed in Release to do? |
| 15:15:52 | Moos | hi t0mas :) |
| 15:16:31 | rasher | I don't think the remaining bugs are going to be fixed |
| 15:16:40 | rasher | If I understand what I read earlier correctlly |
| 15:17:07 | Moos | I think so it's why I'am wondering why not release ;) |
| 15:18:05 | rasher | I think the relevant people are just buy |
| 15:18:06 | rasher | busy |
| 15:18:21 | Moos | maybe |
| 15:19:39 | Moos | rasher: a propos, congratulations for languages |
| 15:20:05 | rasher | Yeah, people have been quite good at providing translations |
| 15:20:40 | | Join ]RowaN[ [0] (n=5688bf02@labb.contactor.se) |
| 15:20:44 | Moos | lot of fully translations |
| 15:20:48 | ]RowaN[ | u guys seen this? www.dapreview.net/content.php?review.221 |
| 15:21:28 | rasher | ]RowaN[: Yup. Pretty good review although he misses a few things. Good overall though |
| 15:21:43 | rasher | Moos: Indeed. I'm quite satisfied with it |
| 15:22:04 | Moos | :) |
| 15:22:24 | ]RowaN[ | my god that entire article doesnt even mention replaygain does it |
| 15:22:30 | Moos | Rowan already see here |
| 15:23:09 | Moos | probably article made before the RG support ;) |
| 15:25:19 | ]RowaN[ | no, article is from 8th sept (8 days ago) |
| 15:25:47 | rasher | Well, does the Karma have that? It seems like he's halfway comparing it to that. |
| 15:26:14 | ]RowaN[ | i just added a comment to the article about RG =] |
| 15:26:20 | Moos | Rowan : published 8th :] |
| 15:27:47 | ]RowaN[ | yes, thats what i said |
| 15:29:08 | Moos | maybe the reserches about Rockbox few weeks ago, or they don't see this marvellous feature support |
| 15:29:21 | ]RowaN[ | it cant have taken him more than 20 minutes to write that little article, surely |
| 15:29:33 | Moos | :) |
| 15:36:17 | | Quit ashridah ("sleep") |
| 15:57:58 | | Part LinusN |
| 16:00 |
| 16:04:15 | linuxstb | Well, I've given myself a challenge and ordered an ipod... |
| 16:04:34 | Moos | boo |
| 16:04:44 | Moos | :-) |
| 16:06:10 | ]RowaN[ | soon ipods will be so small you will be able to use them as a suppository |
| 16:09:47 | *** | Saving seen data "./dancer.seen" |
| 16:11:16 | rasher | linuxstb: which model? |
| 16:22:03 | linuxstb | 60GB Photo |
| 16:22:45 | linuxstb | It (I hope!) uses a PP5020 - the same as the iRiver H10s |
| 16:25:36 | rasher | how much help is that? |
| 16:25:36 | | Join Sucka [0] (n=NNSCRIPT@host81-156-159-120.range81-156.btcentralplus.com) |
| 16:25:45 | rasher | In terms of a possible h10 port |
| 16:26:11 | rasher | How large a part of the player is the PP5020, I guess is more precise |
| 16:30:03 | Dan | rasher |
| 16:30:11 | Dan | its arriving tomorrow morning :D |
| 16:30:23 | rasher | That was quick |
| 16:30:30 | Dan | ya |
| 16:31:01 | Dan | ill probably end up coding some apps to go with it haha |
| 16:31:29 | Dan | once i find out how everythings works |
| 16:32:59 | ]RowaN[ | i need a rockbox sticker for the back of my iriver |
| 16:33:27 | rasher | There should be a cafepress store |
| 16:33:40 | rasher | With any earnings going into the rockbox fund |
| 16:34:41 | ]RowaN[ | i was just thinking that |
| 16:34:46 | linuxstb | The PP5020 is a "system on a chip" - so I would expect there to be a lot of similarities between the H10 and the iPods. |
| 16:35:01 | linuxstb | LCD is one obvious differnece. |
| 16:35:11 | ]RowaN[ | i'll set one up if #rockbox trusts me not to run off with the millions of pounds of profits =p |
| 16:35:34 | rasher | Hm, I think zagor/bagder/linus should set it up |
| 16:35:45 | rasher | to avoid transfering back and forth |
| 16:37:10 | rasher | linuxstb: Yeah, just wondering how much system is on the chip |
| 16:39:14 | linuxstb | We'll find out... |
| 16:39:31 | rasher | Yup. |
| 16:39:33 | Zagor | i'll look into the cafepress thing. we've discussed it long ago (anyone remember the tshirt contest?) but since we're lazy nother ever materialized |
| 16:39:57 | rasher | I'd almost be tempted to trade in my iriver for an ipod |
| 16:42:09 | | Join Hansmaulwurf [0] (n=maerlyn@p5081F107.dip.t-dialin.net) |
| 16:42:29 | rasher | (assuming a working Rockbox port) |
| 16:43:22 | | Quit hshah ("CGI:IRC") |
| 16:43:26 | preglow | i'd just get an ipod as well, heh |
| 16:43:43 | Hansmaulwurf | iPoo |
| 16:43:56 | preglow | you aren't from misticriver, are you? |
| 16:44:48 | Hansmaulwurf | "from"? |
| 16:44:50 | * | amiconn doesn't want an ipod for sure |
| 16:44:57 | Hansmaulwurf | well i am registered there yes |
| 16:45:06 | Hansmaulwurf | why? |
| 16:48:19 | rasher | It shows. |
| 16:50:23 | ep0ch | if iPods did Vorbis, gapless and drag and drop usb storage, i would get one too. |
| 16:50:24 | linuxstb | One thing that worries me a little is that the ARM requires aligned memory read/writes. I'm guessing Rockbox isn't safe in this respect. |
| 16:50:47 | amiconn | linuxstb: SH1 requires aligned memory writes as well |
| 16:51:00 | amiconn | *reads/writes |
| 16:51:13 | linuxstb | The arm's requirements are detailed here: |
| 16:51:14 | linuxstb | http://ipodlinux.org/IPod_Programming |
| 16:51:25 | amiconn | At least the all-platform code should be safe in that respect |
| 16:51:58 | Hansmaulwurf | (ep0ch) if iPods did Vorbis, gapless and drag and drop usb storage, i would get one too. <−−- and a remote LCD and of coz rockbox ;) |
| 16:52:22 | rasher | No lcd remote for ipod :-\ |
| 16:52:32 | rasher | I'm beginning to think I can live without it though |
| 16:52:36 | ep0ch | well, i dont use remote at all on the ihp |
| 16:52:39 | linuxstb | My understanding was that iPods did support usb storage - it's just that the iTunes database needs updating. So it's a software problem fixable by Rockbox. |
| 16:53:00 | amiconn | linuxstb: Yes, that's what SH1 reqires too. Otherwise you'll get an address error exception |
| 16:53:13 | ep0ch | linuxstb: yeah something along the lines of music filenames being stored as a hash on the drive, not quite what i would like. |
| 16:53:15 | ]RowaN[ | i never use my iriver's remote.. all the extra wires and bulkyness of it (compared to the size of the player) kind of outweighs its purpose |
| 16:53:25 | | Quit cYmen ("fu!") |
| 16:53:41 | Hansmaulwurf | huh? the remote has maybe 10g |
| 16:53:48 | ]RowaN[ | its not like my iriver takes up the boot of my car |
| 16:54:05 | amiconn | linuxstb: Even the coldfire requires it in some cases, though not for ordinary data accesses |
| 16:54:27 | ep0ch | Hansmaulwurf: 10g? grams? gig? |
| 16:54:29 | linuxstb | amiconn: Thanks. I'm glad it's not a new issue. |
| 16:54:35 | Hansmaulwurf | and for using it while byciclgin its very useful |
| 16:54:37 | Hansmaulwurf | gram |
| 16:55:42 | rasher | Hansmaulwurf: most of the times I don't need the lcd though |
| 16:55:47 | rasher | Just a skip-button |
| 16:55:50 | ep0ch | Hansmaulwurf: not weight, but too many wires to get tangled up in |
| 16:56:03 | ]RowaN[ | that reminds me ive got a rio pmp300 (iirc) that i need to bin/ebay up... it works but the battery connection is loose |
| 16:56:11 | Hansmaulwurf | u can store the wires in your bags |
| 16:56:13 | ]RowaN[ | 32mb onboard, whoa! =] |
| 16:56:16 | amiconn | ]RowaN[: I agree here. It's not a problem of how much it weighs, but it adds another item and cable hanging around... |
| 16:56:40 | ]RowaN[ | when i said outweigh... i didnt mean physically =] |
| 16:56:41 | | Join ender` [0] (i=ychat@84.52.165.220) |
| 16:56:44 | Hansmaulwurf | at home the remote is mostly useless i agree |
| 16:56:58 | Hansmaulwurf | but for any kind of outdoor activity its very usefull |
| 16:57:11 | rasher | amiconn: Depends on how you arrange it.. I have my player in my pocket, and the remote cable curled up there. Remote clipped unto the pocket-top and the headphone cable from there to my ears |
| 16:57:27 | Hansmaulwurf | same here rasher |
| 16:57:39 | amiconn | For use while walking etc., the iriver is too bulky anyway |
| 16:57:45 | amiconn | I use my Ondio for that |
| 16:57:52 | ]RowaN[ | its another item that will get caugt in the handbag clasp of some tragic commuter who rushes past you, then pulls you to the floor / launches your iriver onto the train track / strangles you with the pulled wire |
| 16:58:19 | Dan | put the cable up through your jacket |
| 16:58:20 | ep0ch | i always found the remote on the ihp a pain in the arse to use, too many buttons, and it operated completely differently to the main unit |
| 16:58:43 | ]RowaN[ | iriver does seem somewhat bulky these days, but it fits snugly into my inside jacket pocket.. i need all 30gigs of music all day coz i do a 4 hour commute |
| 16:58:50 | Hansmaulwurf | can we agree that it was a great gift from iriver to give a lcd remote for free on the h1** series? :) |
| 16:59:07 | ep0ch | huh? i paid for it |
| 16:59:12 | Hansmaulwurf | ? |
| 16:59:12 | rasher | pwned. |
| 16:59:15 | ep0ch | was included in the price |
| 16:59:18 | | Quit Moos ("Parti") |
| 16:59:23 | rasher | Heh, of course |
| 16:59:27 | amiconn | I only keep my remote for rockbox development. Otherwise I would give it away. |
| 16:59:33 | | Join Moos [0] (i=DrMoos@m113.net81-66-159.noos.fr) |
| 16:59:54 | | Join tucoz [0] (n=50ca630c@labb.contactor.se) |
| 17:00 |
| 17:00:29 | Hansmaulwurf | will we see a lcd remote support in the near future? |
| 17:00:48 | tucoz | amiconn: you here? I read in the logs a while back that you found irivers fm-radio having worse reception than the archoses. Did you try with the remote? |
| 17:00:49 | Hansmaulwurf | or are all Rockbox developer busy with an iPoo port? |
| 17:00:50 | ep0ch | yeah amiconn just volunteed to do all the code ;) |
| 17:01:06 | amiconn | tucoz: No, without the remote |
| 17:01:31 | tucoz | i.e using the remote as antenna. For me, I get a lot better reception with that. (iirc) ;) |
| 17:01:35 | amiconn | ...but with the exact same earphone (==antenna) as on the Ondio |
| 17:02:15 | Hansmaulwurf | the reception on the iriver is very poor |
| 17:02:17 | tucoz | ok, I am not sure of this. not often that I use the remote. But, I think reception is improved by using the remote. |
| 17:02:23 | ]RowaN[ | do radio stations still broadcast? |
| 17:02:23 | Hansmaulwurf | one reason why i dont use it |
| 17:02:38 | Hansmaulwurf | ]RowaN[: in germany they do |
| 17:02:45 | Hansmaulwurf | i heared |
| 17:02:46 | amiconn | And btw, this is only valid for the newer Ondios with Philips tuner. The old Ondios and the FM recorder have a samsung fm tuner, which is rather poor |
| 17:03:06 | rasher | Hansmaulwurf: Noone's working on an iPod port now. And please refrain from making such comments. |
| 17:03:21 | ep0ch | tucoz: yeah using the remote will add extra length to the antenna, so makes sense :) |
| 17:03:21 | Hansmaulwurf | sorry |
| 17:03:43 | ]RowaN[ | you should see the size of my antenna, its huge |
| 17:03:57 | ep0ch | hhe |
| 17:04:19 | amiconn | ep0ch: Extra length doesn't always yield better reception. It's also a question whether the antenna is properly tuned/ adapted |
| 17:04:21 | tucoz | ep0ch. Yes, that is true, but I thought that the wireing was using some other pins than the audio pins. But, then again, what do I know. |
| 17:05:04 | ep0ch | hmm, i suppose adding extra length increases the chances of the wire being in the right direction then |
| 17:05:20 | | Join ripnetuk [0] (n=george@82-70-100-230.dsl.in-addr.zen.co.uk) |
| 17:05:33 | ep0ch | i.e horizontally rather than vertical |
| 17:05:39 | ripnetuk | Hi guys. Has anyone contributed code to make the LCD remote on iRiver work yet? |
| 17:05:45 | amiconn | tucoz: No, it doesn't. The antenna function of the headphone cable is done by decoupling the wires from ground for high frequencies (with coils), and coupling it to the fm tuner with a small capacitor |
| 17:06:02 | ep0ch | you know too much :D |
| 17:06:07 | rasher | ripnetuk: No. Not outside a half-hearted attempt by XavierGr which went about it the wrong way |
| 17:06:13 | Hansmaulwurf | ripnetuk: try xavierGs build |
| 17:06:23 | ripnetuk | was that the one that used the remote LCD instead of the main one? |
| 17:06:30 | rasher | No, not quite |
| 17:06:43 | ripnetuk | ? |
| 17:06:43 | rasher | It simply mirrored every lcd call with a remote_lcd one |
| 17:06:53 | rasher | Which is not quite right |
| 17:06:55 | ripnetuk | why is that the wrong (short term) approach? |
| 17:07:07 | ripnetuk | surely if we display the middle XxY pixels on the remote |
| 17:07:23 | Hansmaulwurf | on the player u could only see as much as on the remote |
| 17:07:24 | ripnetuk | its much better than nothing? (obviously replace with real seperate screen buffer when the code exists) |
| 17:07:26 | Hansmaulwurf | for example |
| 17:08:21 | ripnetuk | ? you saying he reduced the screen size defines to be small enough for the remote (leaving a border on the main LCD)? |
| 17:08:28 | tucoz | amiconn: ok. thanks. |
| 17:08:34 | rasher | ripnetuk: it's not really useful for menus and filebrowser |
| 17:08:44 | amiconn | ripnetuk: The remote lcd drive is there, and there is a separate screen buffer |
| 17:08:58 | amiconn | What is missing is the UI code handling it |
| 17:09:06 | ripnetuk | so we need to (eventually) change all lcd_write functions to take a screen ID as well then? |
| 17:09:13 | amiconn | Nope |
| 17:09:36 | amiconn | There is a second set of functions. It's already in place |
| 17:10:03 | amiconn | I repeat: What is missing is the UI code handling it. There are two possible approaches |
| 17:10:04 | ripnetuk | so do we plan to alter each place in code to call both sets when needed (ie, menus know how to draw to either device) |
| 17:10:14 | ripnetuk | what 2 approaches are u thinking of? |
| 17:10:28 | rasher | There was a little discussion on the mailinglist |
| 17:10:35 | amiconn | (1) Mirror all output of a certain part (file browser, menu, wps etc) on the second display |
| 17:11:09 | * | ripnetuk rejoins mailing list (left when sold Archos, forgot to re-join when iRiver port became viable) |
| 17:11:11 | amiconn | This is the approach XavierGr took (but without adjusting for the different sizes, so all screens are clipped on the remote) |
| 17:11:32 | rasher | http://www.rockbox.org/mail/archive/rockbox-archive-2005-08/0114.shtml |
| 17:11:40 | amiconn | (2) Have a secondary GUI thread, as independent as possible from the main GUI thread |
| 17:11:43 | | Quit rasher (Remote closed the connection) |
| 17:11:45 | ripnetuk | thanks :) |
| 17:12:03 | amiconn | Imho (2) is the way to go, because it's way more flexible |
| 17:12:23 | amiconn | Of course there must be some communication between both GUI threads |
| 17:12:35 | ripnetuk | yes, (2) sounds like the way to go... |
| 17:12:47 | ripnetuk | potentially you could play Tetris on the remote, and wps on main :) |
| 17:13:36 | | Part tucoz |
| 17:14:27 | | Join dpassen1 [0] (n=dpassen1@resnet-233-61.resnet.UMBC.EDU) |
| 17:14:51 | ripnetuk | thanks for info people - i might have a play with the remote API to see what I can do |
| 17:25:03 | ]RowaN[ | colour laser printer labels sheet rockbox.jpg... just made a little banner for the back of my iriver =] |
| 17:26:22 | ]RowaN[ | the area around the screen of my h120 seems glassy.. as if it could be lifted off, and the plate under it replaced? anyone know? |
| 17:26:44 | | Join markun [0] (n=markun@bastards.student.ipv6.utwente.nl) |
| 17:27:46 | | Quit ripnetuk ("arrrrgggh") |
| 17:41:16 | Dan | thats what i was thinking rowan |
| 17:50:24 | zhilik | So... Anybody have an idea, where I can find a dead MPIO HD200? I asked on some forums and no results yet (and I rather doubt ther will be). |
| 18:00 |
| 18:00:07 | Dan | ebay? |
| 18:00:08 | Dan | lol |
| 18:00:46 | zhilik | No. Looked there... |
| 18:00:57 | Dan | what country? |
| 18:01:04 | zhilik | Russia, Moscow. |
| 18:01:13 | Dan | hmm |
| 18:01:25 | Dan | why do you need it to be dead? |
| 18:01:27 | Dan | parts? |
| 18:01:48 | zhilik | No, so I can look at the PCB and start porting RockBox to it. |
| 18:01:56 | Dan | oh |
| 18:02:06 | zhilik | http://www.rockbox.org/twiki/bin/view/Main/InsideMPIOHD200 |
| 18:02:31 | zhilik | It has BGA packaged chips. |
| 18:03:01 | Dan | hmm |
| 18:03:13 | Dan | without going to forums / auction sites etc |
| 18:03:33 | Dan | the only way i can see is cutting a deal with a shop |
| 18:03:41 | Dan | for a returned one |
| 18:08:57 | | Quit Sucka (Read error: 110 (Connection timed out)) |
| 18:09:49 | *** | Saving seen data "./dancer.seen" |
| 18:10:22 | | Quit ]RowaN[ ("CGI:IRC") |
| 18:13:58 | | Quit linuxstb ("Client Exiting") |
| 18:14:35 | preglow | amiconn: any showstoppers for a release? |
| 18:34:09 | | Join Sucka [0] (n=NNSCRIPT@host81-156-159-120.range81-156.btcentralplus.com) |
| 18:49:37 | | Quit Dan () |
| 19:00 |
| 19:04:14 | | Join Hans|Kaufrausch [0] (n=maerlyn@p5081D67F.dip.t-dialin.net) |
| 19:05:21 | | Quit dpassen1 () |
| 19:05:32 | | Join cYmen [0] (n=cymen@nat-ph3-wh.rz.uni-karlsruhe.de) |
| 19:22:31 | | Quit Hansmaulwurf (Read error: 110 (Connection timed out)) |
| 19:59:45 | | Join Lear [0] (n=chatzill@h36n10c1o285.bredband.skanova.com) |
| 20:00 |
| 20:00:42 | ep0ch | Oh i'm tempted to get the MPIO HD200 now, any downfalls with it? |
| 20:02:15 | Bagder | yes, there's no rockbox for it |
| 20:02:20 | Bagder | (yet) |
| 20:02:23 | ep0ch | heh, are there any funds in the kitty to buy Zhilik another HD200? |
| 20:02:32 | Bagder | yes |
| 20:02:46 | Bagder | we're ready to sponsor him a broken one |
| 20:02:47 | ep0ch | i'm not donating any more until .mod and .sid is done :p |
| 20:03:07 | ep0ch | what if a broken one isnt available? |
| 20:03:23 | Bagder | then we'll see |
| 20:03:26 | ep0ch | i could be tempted to donate money for that |
| 20:05:17 | ep0ch | any other bad things about the HD200 except lack of rockbox? |
| 20:05:26 | Bagder | no idea |
| 20:05:32 | Bagder | it seems similar to h1x0 spec wise |
| 20:05:43 | zhilik | It's got bad firmware :-) |
| 20:05:51 | zhilik | Sound's good. |
| 20:05:54 | zhilik | Loud. |
| 20:05:56 | ep0ch | are the controls any good? |
| 20:06:04 | zhilik | The battery lasts for a few hours. |
| 20:06:19 | zhilik | The controls are OK if you get used to them. |
| 20:06:49 | ep0ch | does it come with a remote or not? i read it does, but couldnt see a picture |
| 20:06:58 | zhilik | But one of the reasons why I wanted to port RockBox to it is that i want to get the control from my dead iMP-550. |
| 20:07:09 | zhilik | The remote has 4/5 buttons. |
| 20:07:16 | zhilik | No LCD. |
| 20:07:45 | zhilik | 6 buttons and a hold switch. |
| 20:07:54 | ep0ch | zhilik: "i want to get the control from my dead iMP-550.", what do you mean by that? |
| 20:08:17 | ep0ch | you want the HD200 to be like the imp-550 navigation wise? |
| 20:08:21 | zhilik | I've got a dead iRiver SlimX iMP-550. |
| 20:08:39 | zhilik | Which was the player I used before the MPIO. |
| 20:08:52 | zhilik | And I want to connect its remote to the MPIO. |
| 20:08:57 | ep0ch | ohh ok |
| 20:09:53 | *** | Saving seen data "./dancer.seen" |
| 20:10:08 | zhilik | iRiver's devides are easy to use. A pity the 550 turned out to be such crap - died after a year and a bit (just after the guarantee). Even the radio is dead. I can use it as a device for displaying "No Disk". |
| 20:10:09 | ep0ch | i'm stuck in the mode of thought that if i were to wait, something better would come out, but then i'll never buy anything :( |
| 20:10:38 | ep0ch | heh |
| 20:11:03 | zhilik | The MPIO's not that bad. |
| 20:11:46 | ep0ch | i want a small Vorbis player that might one day have rockbox on... |
| 20:11:56 | zhilik | In fact appart from the rather small battery life, buggy firmware (hope that'll get fixed ;-) everything's fine. |
| 20:12:04 | zhilik | It plays Vorbis. |
| 20:12:09 | ep0ch | yup |
| 20:12:22 | ep0ch | that's why i'm interested in it :) |
| 20:13:13 | zhilik | Oh, another thing - the remote connector is bad - it easilly disconnects. |
| 20:13:30 | ep0ch | wasnt actually planning on using the remote anyway :D |
| 20:13:35 | zhilik | But I don't use it. |
| 20:13:48 | | Quit Lear ("Chatzilla 0.9.68.5.1 [Firefox 1.4/undefined]") |
| 20:13:57 | ep0ch | headphone socket is on the side, is that a pain or not? |
| 20:14:40 | zhilik | Not really. At least if you don't have a straight connector. (My KOSS Porta Pro doesn't). |
| 20:14:55 | zhilik | The sound is good. |
| 20:15:03 | zhilik | I was rather amazed by it. |
| 20:15:29 | zhilik | It has Line-In, Microphone. Doesn't need any stupid software (I HATE iTunes). |
| 20:15:51 | zhilik | Can directly encode to upto 192b/s MP3. |
| 20:16:09 | zhilik | A radio (it work well). |
| 20:16:22 | zhilik | And you can record the radio. |
| 20:16:54 | zhilik | Standard miniUSB connector (if you lose the cable, it wont be a problem to buy a new one). |
| 20:17:20 | ep0ch | i think i read somewhere, that to use the radio you have to install some software first? that right? |
| 20:17:43 | ep0ch | maybe it means firmware |
| 20:17:46 | zhilik | I don't know. The first thing I did with it is went and got new firmware. |
| 20:18:21 | zhilik | And I don't use any softwarre. |
| 20:18:51 | zhilik | To update it you DON'T nedd the MPIO utility - simply copy the files into the SYSTEM directory. |
| 20:19:06 | ep0ch | so all in all what's the real likely hood of rockbox being ported to this thing? |
| 20:19:20 | ep0ch | i wonder what the user base is for it.. |
| 20:19:28 | zhilik | Yes. And that's a BIG problem. |
| 20:19:33 | zhilik | :-) |
| 20:20:08 | amiconn | Wtf.... |
| 20:20:25 | zhilik | It's very cheap. But build quality isn't high - I have a fealing that if I dropped it on a hard floor it would break. |
| 20:20:54 | ep0ch | really? the pictures i've seen look like its good quality |
| 20:21:08 | ep0ch | amiconn: sup, you broken something again? |
| 20:21:10 | ep0ch | ;) |
| 20:21:36 | amiconn | Several strange, good & bad news about my archos firmware test recording.... |
| 20:21:37 | zhilik | The plastic's rather thin. The 2 parts are held together with 4 small screws. |
| 20:22:22 | zhilik | I suggest you get the white version - the others have paint which will slowly get scratched and the player won't be a good sight. |
| 20:22:31 | ep0ch | oh noooo so 2.5 is going to be a long wait then? |
| 20:22:31 | amiconn | (1) The recording stopped after ~5 hours 18 min for whatever reason. Player did shut down |
| 20:22:49 | amiconn | (2) There are _no_ frame errors in the recording. |
| 20:22:57 | ep0ch | all good so far |
| 20:23:29 | amiconn | (3) Archos somehow manages to get the _correct_ framecount even when it's not possible to read that from the MAS |
| 20:23:49 | amiconn | (it's greater than 0x7ffff) |
| 20:24:13 | amiconn | They also manage to avoid a partial last frame |
| 20:24:39 | | Join DangerousDan [0] (n=Miranda@newtpulsifer.campus.luth.se) |
| 20:24:43 | zhilik | If you have alook at my scans, you'll see that C616 is blown. And it wasn't me that broke it... So the build quality IS low. |
| 20:25:04 | zhilik | C616 is on the back next to the CF slot. |
| 20:25:07 | amiconn | (4) It seems they use a funny trick for their Xing header. They don't reserve the space beforehand, but write the Xing data _into_ the first frame |
| 20:26:26 | amiconn | ...and leave no space for id3v2 (no wonder, since they don't support it for reading either). MP3 data starts at file position 0 |
| 20:26:47 | ep0ch | so to summarise how does that compare with rockbox? |
| 20:28:32 | amiconn | (1): Rockbox is better. No shutdown for obscure reasons (2) Rockbox doesn't manage that with high-q recordings (3) Rockbox doesn't manage that (but gets close) (4) I think the rockbox method is better |
| 20:35:14 | | Join solex_ [0] (n=jrschulz@d027183.adsl.hansenet.de) |
| 20:37:35 | zhilik | ep0ch: So are you plannig to buy the MPIO or not? [Simply intersted.] |
| 20:47:15 | | Quit Seed (Read error: 104 (Connection reset by peer)) |
| 20:47:22 | | Join Seed [0] (i=ben@192.117.115.168) |
| 20:47:46 | | Quit solex (Read error: 110 (Connection timed out)) |
| 20:58:56 | ep0ch | zhilik: not 100% sure :) |
| 20:59:32 | zhilik | What are the other variants? [Again, simply interested.] |
| 20:59:39 | ep0ch | i have come close to pressing the buy button |
| 21:00 |
| 21:00:24 | ep0ch | none really, maybe iriver will come out with a new HD based played with Vorbis support... |
| 21:00:37 | ep0ch | i'm playing the waiting game |
| 21:01:10 | | Quit Sucka ("a bird in the bush is worth two in your house") |
| 21:06:27 | zhilik | ep0ch: I got tired of doing that. It took me about a month to decide what I wanted. Or to be more exact, to see that such a thing simply doesn't exist. |
| 21:07:34 | | Join matsl [0] (n=matsl@1-1-4-2a.mal.sth.bostream.se) |
| 21:27:07 | | Quit Bagder (Read error: 104 (Connection reset by peer)) |
| 21:41:06 | | Join paugh [0] (n=kickback@dsl-62-3-104-34.zen.co.uk) |
| 21:43:15 | | Nick paugh is now known as AliasAle (n=kickback@dsl-62-3-104-34.zen.co.uk) |
| 21:57:36 | | Join Kuolar [0] (n=Mirico@cust-65-110-26-169.sfu-reznet.connectwest.net) |
| 22:00 |
| 22:01:12 | | Join Sucka [0] (n=NNSCRIPT@host81-156-208-141.range81-156.btcentralplus.com) |
| 22:03:27 | | Quit zhilik ("http://www.zhukovsky.net") |
| 22:05:08 | | Join Bagder [0] (n=daniel@1-1-5-26a.hud.sth.bostream.se) |
| 22:09:57 | *** | Saving seen data "./dancer.seen" |
| 22:10:04 | | Quit Kuolar () |
| 22:40:51 | | Quit Sucka ("a bird in the bush is worth two in your house") |
| 22:41:39 | | Join lImbus [0] (n=MDJ@port-212-202-8-79.dynamic.qsc.de) |
| 22:55:46 | | Join webguest84 [0] (n=d49f4cf2@labb.contactor.se) |
| 22:56:22 | | Quit ansivirus (Read error: 110 (Connection timed out)) |
| 22:56:54 | | Join webguest41 [0] (n=d49f4cf2@labb.contactor.se) |
| 22:57:03 | | Quit webguest41 (Client Quit) |
| 22:58:58 | | Join Maxime [0] (n=flemmard@fbx.flemmard.net) |
| 22:58:58 | | Quit t0mas (Read error: 104 (Connection reset by peer)) |
| 22:58:58 | | Quit Maxime` (Read error: 104 (Connection reset by peer)) |
| 22:59:38 | | Join t0mas [0] (n=Tomas@unaffiliated/t0mas) |
| 23:00 |
| 23:04:01 | | Quit atubbs ("fdsnet self-destruct sequence activated") |
| 23:07:59 | | Join webguest58 [0] (n=50c3c8ed@labb.contactor.se) |
| 23:08:32 | | Quit webguest58 (Client Quit) |
| 23:10:56 | | Nick AliasAle is now known as AliasCoffee (n=kickback@dsl-62-3-104-34.zen.co.uk) |
| 23:18:10 | | Join Sandking [0] (n=jacek@ogorek.akron.wroc.pl) |
| 23:18:24 | Sandking | hi there |
| 23:18:25 | Sandking | :] |
| 23:18:38 | Bagder | good evening |
| 23:18:46 | Sandking | I got my first day of using rockbox is done :D |
| 23:19:05 | Sandking | [ahh... it's too late to write correct english :) ] |
| 23:19:11 | Bagder | congratulations! :-) |
| 23:19:27 | Sandking | it feels ok aside from hanging in some situations |
| 23:19:33 | Sandking | [like messin with wps] |
| 23:20:01 | Sandking | but I got two questions - how to queue and what is databox? |
| 23:20:04 | Bagder | ah, a few bugs keep you alert |
| 23:20:19 | Sandking | [h120] |
| 23:20:25 | Bagder | databox is one of the plugins for doing searches in the runtimedb |
| 23:21:23 | Sandking | yesterday rasher [?] wrote how to use databox to play best rated songs - any tip? |
| 23:21:27 | Bagder | about queue, I think you use the context-menu (long press on navi) |
| 23:21:41 | Sandking | [it was something like - rating > x ] |
| 23:21:50 | Bagder | yes, that should be possible |
| 23:22:03 | Bagder | but those plugins are rather user hostile if you ask me |
| 23:22:14 | Sandking | I noticed that :] |
| 23:22:16 | Bagder | I've never used them (partly because of that) |
| 23:22:50 | Sandking | but options like playing best songs and all that what db gives will be included in future? |
| 23:23:21 | Bagder | hopefully, yes |
| 23:23:42 | Sandking | how fast does new versions appear? |
| 23:23:57 | Bagder | it depends what a new version is to you |
| 23:24:22 | Bagder | we offer daily builds every day |
| 23:24:54 | amiconn | Databox is quite logical imho. |
| 23:24:55 | Bagder | we don't do formal releases very often |
| 23:25:02 | Bagder | logical yes |
| 23:25:04 | Bagder | easy no |
| 23:25:13 | Sandking | so all the small things can go in daily builds? |
| 23:25:27 | Bagder | Sandking: all changes that are done are available in those |
| 23:25:32 | amiconn | The only user-unfriendlyness is when you are clicking together a query which is longer than the available screen space |
| 23:25:49 | amiconn | (very unlikely on H1x0, but very likely on the player) |
| 23:26:21 | Sandking | amiconn - so how to type command to play songs starting from some rating |
| 23:26:39 | Sandking | or songs that has been played / not been played certain amount of times? |
| 23:27:27 | amiconn | I never used rating, but I'll have a quick look at databox... |
| 23:28:17 | | Join rasher [0] (n=jonas@62.79.64.148.adsl.hs.tiscali.dk) |
| 23:28:25 | Moos | amiconn/Bagder: what is the freeze statement please? |
| 23:29:55 | amiconn | Sandking: Start databox, enter the filename under which you want to save your query (extension is appended automatically is omitted), then click together a query string like rating > 6 <END> |
| 23:30:58 | amiconn | The query will be saved under the name (and in the path) you specified. If you want to execute the query, just run the file. You'll get a playlist in the root, search.m3u, containing the result |
| 23:32:07 | amiconn | I admit that entering the filename everytime is somewhat user-unfriendly, but solving that needs a way to have dual-mode plugins |
| 23:32:21 | amiconn | (usable both as viewer and as standalone plugin) |
| 23:35:12 | Sandking | i love option to display battery charge with number |
| 23:35:42 | rasher | Having the two tasks (search creating and executing) seperated is confusing to most users I think |
| 23:35:58 | rasher | Seperated in two files, that is |
| 23:36:07 | rasher | two plugins. |
| 23:36:12 | Bagder | I agree |
| 23:36:53 | amiconn | It's debatable. The advantage is that you can store you queries and execute them multiple times |
| 23:37:09 | rasher | My suggestion still allows that |
| 23:37:30 | amiconn | Unifying the plugins is possible, if we have that method for dual-mode plugins |
| 23:37:40 | rasher | Indeed. |
| 23:37:41 | Bagder | we do |
| 23:37:47 | rasher | We do? |
| 23:37:48 | Bagder | its just a matter of path |
| 23:38:05 | Bagder | a viewer is just a normal plugin that gets a file name |
| 23:38:22 | rasher | Yeah, the plugins don't need changing |
| 23:38:25 | amiconn | Bagder: I know that you can run (some of) the viewer plugins directly, but they don't appear in the plugin menu |
| 23:38:37 | Bagder | right, due to the path |
| 23:38:41 | Bagder | being different |
| 23:39:15 | Sandking | strange - i did the right query and it added some files that I haven't really rated |
| 23:39:26 | amiconn | Perhaps it would be a better idea to have all plugins in one path, and a plugin.config (like the current viewers.config) defining flags |
| 23:39:39 | Bagder | amiconn: yes |
| 23:39:51 | Bagder | the current approach is a little naive |
| 23:39:57 | amiconn | One flag for "viewer", another flag for "plugin menu" |
| 23:40:12 | amiconn | The new search plugin would get both flags set |
| 23:40:31 | Sandking | ok guys - thanks for help today, I need some sleep - see you tomorrow |
| 23:40:37 | amiconn | This method would also allow to completely hide some plugins, by setting neither flag |
| 23:40:43 | amiconn | (e.g. credits.rock) |
| 23:40:52 | | Quit Sandking () |
| 23:41:33 | | Quit Hans|Kaufrausch ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )") |
| 23:41:56 | amiconn | Or do it the other way round for viewability, and define that a plugin not listed at all has no flag set |
| 23:42:15 | amiconn | I.e. one flag for "viewer", one flag for "hide from plugin menu" |
| 23:42:57 | amiconn | Pure viewers would have both flags set, the new search plugin would only have the viewer flag set, and ordinary plugins aren't listed at all |
| 23:43:16 | amiconn | credits.c could then have the "hide" flag set |
| 23:44:28 | amiconn | Even simpler: Keep viewers.config as-is for viewers, but all plugins in /.rockbox/rocks, and hide the plugins not wanted in the menu with the "hidden" flag |
| 23:44:40 | amiconn | (FAT32 file system flag this time) |
| 23:45:01 | | Join tucoz [0] (n=50ca630c@labb.contactor.se) |
| 23:47:15 | tucoz | Hi, are there any special plans for radio on iriver? I mean with the preset. anyway, I'll just write the obvious. Add || IRIVER_H100_PAD to line 974 for presets to work in the menu. Really nice :) |
| 23:47:40 | | Join Mojito [0] (i=Mojito@p548FEC5C.dip.t-dialin.net) |
| 23:47:42 | Mojito | hi! |
| 23:48:07 | tucoz | hi |
| 23:48:11 | | Join ashridah [0] (i=ashridah@220-253-122-108.VIC.netspace.net.au) |
| 23:48:37 | tucoz | that would be in apps/recorder/radio.c |
| 23:48:44 | rasher | tucoz: linuxstb suggested this a few days ago |
| 23:48:49 | rasher | There are some problems apparently |
| 23:49:00 | tucoz | rasher: hehe, didn't know |
| 23:50:27 | Mojito | konw some one here something about iriverter? |
| 23:50:45 | tucoz | rasher: I've noticed that radio is in a, well, early state. |
| 23:51:16 | Mojito | i converted a avi file there its a dvdrip in xvid and ac3 sound |
| 23:51:17 | amiconn | I can't imagine what problems should arise from enabling fm presets on iriver this way |
| 23:51:30 | Mojito | but when i converted it with iriverter and put it on my h340.. i cant play the file |
| 23:51:31 | amiconn | It might not be the optimal solution, but it should work ok |
| 23:52:04 | rasher | If it works, good idea. |
| 23:52:06 | tucoz | me neither. I just thought that it was a simple enhancement, not introducing new code. which is nice imho. |
| 23:52:26 | tucoz | rasher. yes it works. Hmm, let me reboot and check |
| 23:52:42 | rasher | Confused linuxstb didn't add it |
| 23:52:58 | tucoz | hmm, it works. |
| 23:55:54 | tucoz | rasher: do you remember what the problems were? I've noticed that the volume needs attention. |
| 23:56:02 | rasher | I'll see |
| 23:56:03 | tucoz | but that is regardless of this :) |
| 23:56:50 | tucoz | goodnight |
| 23:56:59 | | Quit tucoz ("CGI:IRC 0.5.4 (2004/01/29)") |
icon identifies that the person is a core developer (has commit access).