similar to: metadata cache corruption: cleared -> fixing in progress

On 29.07.2015 21:34, Nux! wrote: > Yes, you can. > In fact you can use the binaries from the ovirt repo itself, no need to rebuild. Thank you! In fact - I can't use raw binaries from the ovirt repo itself, because these qemu-kvm binaries contains one bug, which is already fixed in Debian: If you want to migrate Windows from hardware node to VM using CentOS 7.1 on hardware node and

Rename the cache files like ‘qemu.stat’ etc so they include the qemu binary "key" (ie. size and mtime) in the name. This allows a single user to use multiple qemu binaries in parallel without conflicts. --- lib/qemu.c | 29 ++++++++++++++++++++++++----- 1 file changed, 24 insertions(+), 5 deletions(-) diff --git a/lib/qemu.c b/lib/qemu.c index 097d56929..1549bb33a 100644 ---

The previous code duplicated a lot of common code for reading and writing the cache file per data field. This change simply factors out that common code. This makes it simpler to add new tests in future. This is just refactoring, it should have no effect. --- lib/qemu.c | 375 +++++++++++++++++++++++++++++++++++++++---------------------- 1 file changed, 238 insertions(+), 137 deletions(-)

Hi, yum-2.4 and required dependancies for CentOS-3 are now available for i386 and x86_64 in the centosplus repository. The default version still is 2.0, nothing changes for those who don't want/need the new features (for example: fastestmirror, priorities and protectbase). For those who don't want to update to yum-2.4 but still use the centosplus repository, add to your /etc/yum.conf

Monty Montgomery wrote, on 6/25/2009 2:16 PM: >> Is there any way to understand exactly how it is invalid? I can replicate >> this corruption simply by adding large album art to any ogg file with the >> latest release of MediaMonkey. > The second page is corrupt. The basic structure looks correct, first > guess would be bad checksum. I'll look more closely in just a

2009/7/9 Adam Rosi-Kessel <adam at rosi-kessel.org>: > Adam Rosi-Kessel wrote, on 6/30/2009 11:14 AM: >> >> Conrad Parker wrote, on 6/30/2009 11:05 AM: >>>> >>>> http://adam.rosi-kessel.org/bugs/liboggz/484/other_corruption.ogg >>>> Yet also won't play or process properly with oggz or hogg tools. Any >>>> ideas whether this

Adam Rosi-Kessel <adam at rosi-kessel.org> wrote: > I finally got something like an explanation from the Mediamonkey > developers. Here is their explanation as to why MM corrupted my files: > > > the problem was caused by the fact that Vorbis library uses alloca() > > function on several places, which allocates memory on stack. We > > changed it to alloc() and

Conrad Parker wrote, on 7/8/2009 8:20 PM: >> Anything I can do to keep this on radar? I'm not sure if it is really a bug >> -- perhaps at least a wishlist request. Will putting it in a tracker >> somewhere help? > yes, a tracker would help. I'm somewhat confused about the right place to file this--can you suggest? There seem to be few separate projects it might

Monty Montgomery wrote, on 6/25/2009 1:10 PM: > Vorbose -v reports the following for the beginning of the file: > > INFO page: Capture pattern OggS, format version 0 > Flags: first page of logical stream > > Granule position: 0x0000000000000000 > Stream serialno : 0x490f5cff > Sequence number : 0 >

Conrad Parker wrote, on 6/30/2009 11:05 AM: >> http://adam.rosi-kessel.org/bugs/liboggz/484/other_corruption.ogg >> Yet also won't play or process properly with oggz or hogg tools. Any >> ideas whether this is the same or different root cause? (In all of these >> cases, I'm reasonably certain that disk corruption is not an issue). > that one is entirely missing

Ivo Emanuel Gon?alves wrote, on 6/18/2009 6:14 AM: > On 6/18/09, Conrad Parker<conrad at metadecks.org> wrote: >> This sounds like it needs a new tool specifically for fixing broken >> Ogg files. > > I see two solutions: > > 1) the new vcut which I reckon will fix the problem since it has to > split and rebuild the audio in a new Ogg vcut built today from svn

Conrad Parker wrote, on 6/18/2009 3:15 PM: > Hopefully at some point the vorbis data in the file becomes valid. > Perhaps we just need to know the original encoding settings to create > a new file with valid codebooks and splice them together: oggz-dump -r > should be ok for that, just take the first 3 packets of the new file, > and packets 17 onwards (or 100 onwards) of the

Adam Rosi-Kessel wrote, on 6/21/2009 9:29 AM: > Conrad Parker wrote, on 6/20/2009 10:24 PM: >>> How about another approach -- is there a tool that will verify the page >>> checksums? oggz-validate doesn't seem to do this. If the page checksums >>> are okay, then doesn't that suggest the streams are also recoverable? >> If the page checksums are bad then

> So if I understand correctly -- the first packet is just OggS, so that's No. The first packet is the ID header, containing information such as bitrate, sample rate, number of channels, etc. OggS is the ogg level page capture pattern. Pages encapsulate packets. > easy to replace. The second packet is the metadata, which we can lose. > It's just the third packet that needs to be

Martin Leese wrote, on 7/15/2009 3:29 PM: > Adam Rosi-Kessel<adam at rosi-kessel.org> wrote: > >> So I've written a script to do the following: > ... > > I have got lost. Did you manage to identify the > rogue software that corrupted the files in the > first place? In the greater scheme of things, > fixing this (prevention) is more important than >

Adam Rosi-Kessel wrote: > I finally got something like an explanation from the Mediamonkey > developers. Here is their explanation as to why MM corrupted my files: > > > the problem was caused by the fact that Vorbis library uses alloca() > > function on several places, which allocates memory on stack. We > > changed it to alloc() and free() functions pair instead,

On Wed, Jul 22, 2009 at 7:24 PM, Martin Leese<martin.leese at stanfordalumni.org> wrote: > Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > >> Martin Leese wrote: >>> Anyway, calling alloc()s with no corresponding >>> free()s is a memory leak. Not good code. >> >> The alloca() function allocates space on the stack and >> that

> However, there is a general point. ?Xiph policy > now encourages cover art in VorbisComments > using the METADATA_BLOCK_PICTURE tag, > visit: > http://wiki.xiph.org/VorbisComment#Cover_art > > This means that VorbisComments can be > huge, and so memory for them now needs to > be allocated from the heap, not the stack. Huge is relative. Are people really sticking

Vorbose -v reports the following for the beginning of the file: INFO page: Capture pattern OggS, format version 0 Flags: first page of logical stream Granule position: 0x0000000000000000 Stream serialno : 0x490f5cff Sequence number : 0 Checksum : 0xee9c02b9 Total segments : 1 Total packets : 1

Adam Rosi-Kessel wrote, on 6/19/2009 3:56 PM: > Conrad Parker wrote, on 6/18/2009 3:15 PM: >> Hopefully at some point the vorbis data in the file becomes valid. >> Perhaps we just need to know the original encoding settings to create >> a new file with valid codebooks and splice them together: oggz-dump -r >> should be ok for that, just take the first 3 packets of the