search for: last_offset

...tive to >the start of the file even if you have an id3v2 tag in front. Yeah, I was trying to avoid doing that. This is meant for some fast (as opposed to the current pure perl version) header parsing only code, not doing a decoder in this piece as well. It looks like FLAC__Metadata_Chain has a last_offset - but it's not exposed. That should theoretically give me the position after the last metadata block? -D -- Be who you are and say what you feel, because those who mind don't matter and those who matter don't mind. -- Dr. Seuss

I hacked some command line options into imaptest. I dont think I broke it.. Place into dovecot-source root as usual and compile with: gcc imaptest.c -o imaptest -Wall -W -I. -Isrc/lib -DHAVE_CONFIG_H src/lib/liblib.a As per Timo's instructions. # imaptest -h imaptest [USER at IP:PORTNO] [pass=PASSWORD] [mbox=MBOX] [clients=CC] [msgs=NMSG] [use_authenticate] [PORTNO] USER = template for

...f you have an id3v2 tag in front. > > Yeah, I was trying to avoid doing that. This is meant for some fast > (as > opposed to the current pure perl version) header parsing only code, > not doing > a decoder in this piece as well. > > It looks like FLAC__Metadata_Chain has a last_offset - but it's not > exposed. > That should theoretically give me the position after the last > metadata block? yep, that will work too. but just writing skipping code is pretty simple: is_last=0 read 'fLaC' string while (!is_last) { read 1 byte metadata block type read 3...

...will work too. but just writing skipping code is >pretty simple: > >is_last=0 >read 'fLaC' string >while (!is_last) { > read 1 byte metadata block type > read 3 byte metadata block length > is_last = type & 0x80 > fseek(file,length,SEEK_CUR) >} >last_offset=ftell(file) > >see also: > http://flac.sourceforge.net/format.html#metadata_block_header >'length' is big-endian Should type be of FLAC__byte, and length of FLAC__uint32? I'm not having much luck here.. (not a C programmer by nature). -D -- This movie has warped my frag...

I'm attempting to use the metadata level 2 interface to get at the various interesting bits, which is working fine. But I also need a relevant piece of data, the offset of where the metadata ends, and the audio blocks begin. I'm not finding a clear way to reach that number. Is this exposed anywhere? Thanks. -D -- The revolution will be documented.

Hi all - The following 9 patches add more error handling to the btrfs code: - Add btrfs_panic - Catch locking failures in {set,clear}_extent_bit - Push up set_extent_bit errors to callers - Push up lock_extent errors to callers - Push up clear_extent_bit errors to callers - Push up unlock_extent errors to callers - Make pin_down_extent return void - Push up btrfs_pin_extent errors to

...g cpu_khz) -{ - cyc2ns_scale = (1000000 << CYC2NS_SCALE_FACTOR)/cpu_khz; -} - -static inline unsigned long long cycles_2_ns(unsigned long long cyc) -{ - return (cyc * cyc2ns_scale) >> CYC2NS_SCALE_FACTOR; -} - static unsigned long long monotonic_clock_hpet(void) { unsigned long long last_offset, this_offset, base; @@ -155,6 +122,7 @@ static int __init init_hpet(char* overri return -ENODEV; printk("Using HPET for gettimeofday\n"); + init_xtime_from_cmos(); if (cpu_has_tsc) { unsigned long tsc_quotient = calibrate_tsc_hpet(&tsc_hpet_quotient); if (tsc_quotient)...

...g cpu_khz) -{ - cyc2ns_scale = (1000000 << CYC2NS_SCALE_FACTOR)/cpu_khz; -} - -static inline unsigned long long cycles_2_ns(unsigned long long cyc) -{ - return (cyc * cyc2ns_scale) >> CYC2NS_SCALE_FACTOR; -} - static unsigned long long monotonic_clock_hpet(void) { unsigned long long last_offset, this_offset, base; @@ -155,6 +122,7 @@ static int __init init_hpet(char* overri return -ENODEV; printk("Using HPET for gettimeofday\n"); + init_xtime_from_cmos(); if (cpu_has_tsc) { unsigned long tsc_quotient = calibrate_tsc_hpet(&tsc_hpet_quotient); if (tsc_quotient)...

Hi, I have rewritten the patches I submitted earlier today for the CVS HEAD. Some of the changes were already committed months ago. On 2007/03/15 12:30, Timo Sirainen <tss at iki.fi> wrote: > That's ok, but I'm not sure about bsearch_insert_pos(). It's the way it > is mostly because I wanted to keep bsearch() API. If it can't return > void * then maybe it could be

Hi all - Here''s my current error handling patchset, against 3.1-rc8. Almost all of this patchset is preparing for actual error handling. Before we start in on that work, I''m trying to reduce the surface we need to worry about. It turns out that there is a ton of code that returns an error code but never actually reports an error. The patchset has grown to 65 patches. 46 of them

...atic noinline int add_ra_bio_pages(struct inode *inode, tree = &BTRFS_I(inode)->io_tree; if (isize == 0) - return 0; + return; end_index = (i_size_read(inode) - 1) >> PAGE_CACHE_SHIFT; @@ -542,7 +541,6 @@ static noinline int add_ra_bio_pages(struct inode *inode, next: last_offset += PAGE_CACHE_SIZE; } - return 0; } /* diff --git a/fs/btrfs/delayed-ref.c b/fs/btrfs/delayed-ref.c index 125cf76..0aae23c 100644 --- a/fs/btrfs/delayed-ref.c +++ b/fs/btrfs/delayed-ref.c @@ -390,10 +390,10 @@ update_existing_head_ref(struct btrfs_delayed_ref_node *existing, * this does all...

After running ceph on XFS for some time, I decided to try btrfs again. Performance with the current "for-linux-min" branch and big metadata is much better. The only problem (?) I''m still seeing is a warning that seems to occur from time to time: [87703.784552] ------------[ cut here ]------------ [87703.789759] WARNING: at fs/btrfs/inode.c:2103