These were all deprecated between releases 0.6 and 0.10 of ffmpeg,
except for one change (renaming of CodecID to AVCodecID) which we can
work around with a typedef. The deprecated functions were still
available in 0.11, but were removed later on after several years of
deprecation.
This makes it possible to build our plugin with any ffmpeg version
between 0.10 and 2.7, so we can now experiment with updating to 2.7 at
least for the gcc4 builds.
* ffmpeg can handle these through ModPlug
* By default, ffmpoeg will not try these formats because the way to
detect them are a bit unsafe (4 bytes at a particular offset in the file
serve as an identifier). So, hint the sniffing by giving it a filename
of ".mod" to get modplug to be used. This does not affect sniffing in
the regular way for other formats.
* Add some common tracked music formats to the muxer table.
* Fix some tracing to use current (as of ffmpeg 0.10) function names and
because some variables were renamed.
It's a 32 bit register which needs properly aligned 32 bit writes. Using
a bit field does not guarantee that, so replace it with shifts and
masks. Should fix#12338.
Replace avcodec_encode_audio with avcodec_encode_audio2. The latter
provides us with more information on the encoded data, so we can avoid
guessing things on our own. It also handles memory allocations on its
own, which fix some cases where we would provide a too small buffer.
* TRANSITION_... was incorrectly changed from the original patch.
* Divided it into two constants, and also prefixed the new constants with
the register fields they are valid for.
* Fixed incorrect usage of |= and removed the corresponding TODO comments.
* Moved some reoccurring code into their own methods.
* Added check for the ST bit in the command register for the interrupt
hard reset, too.
* This closes ticket #12295, thanks Anarchos!
It provides a way for filesystems to cache a lookup failure and
therefore prevents repeated lookups of missing entries. This is a
common scenario for example in command lookup and compiling, where
each directory in PATH or each include directory is searched for the
given entry.
TCPEndpoint::Free() uses _EnterTimeWait() to start the time-wait timer
for later cleanup. The latter did call _CancelConnectionTimers()
unconditionally however, also cancelling a retransmit timer that was
possibly still needed for the retransmission of the FIN packet. If the
FIN packet got lost, the connection would be left open on the other end.
The APICall trace entry just records the function name but this is
enough to deduce where some of the state changes come from.
Also move the TRACE macros past the MutexLockers to ensure that their
output happens at the time when the methods actually run.
The retransmit timer was only stopped when all in flight data was
acknowledged and never updated on individual acknowledgements. This
caused a lot of erroneous retransmits whenever the buffer was filled
fast enough so that the acknowledgements never caught up, i.e. whenever
uploading or streaming data.
Move setting of the initial retransmit timer inside the send loop so it
is closer to the actual time the segment is sent out and simplify the
logic a bit.
Limit the minimal retransmit timeout to 200 msecs to avoid spurious
retransmit in the face of delayed acknowledgements. This is lower than
the 1 second minimum the RFCs suggest. Other stacks use various other
sub-second timeouts, the 200 msecs follows what Linux does.
Also add the exponential back off of the retransmit timeout when
retransmits are triggered. This is bounded by a 60 seconds maximum
according to RFC6298.
The WaitList implementation had a race condition between checking for
the condition and acquiering the semaphore. If a thread was rescheduled
at that point, the signal could be missed due to the use of
release_sem_etc() with the B_RELEASE_ALL flag while the thread was not
yet waiting for the semaphore. The transfer would subsequently stall.
* While it should not be a big problem the
bebook specify to do it after custom operations,
most nodes also follow this way, this commit restore
consistency.
__res_state can't be used with pthreads involved, instead use
__res_get_state and __res_put_state which maintain a pool of res_state
instances.
Fixes#12195.
* Make the title the default font and bold like other screen savers
* Don't center the copyright text, left align
* Put spacing strut between title/copyright and the rest
* Put the pop-up menus in a grid, make them variable width
* Add some more glue so items grow apart more nicely
The assembly I converted this from didn't look hand-generated, which
probably explains why it was so convoluted.
No functional change intended (the generated code will change, though.)
I don't know why this was in there -- possibly for older machines
that couldn't do their fullscreen resolution at 60fps? Which doesn't
make a lot of sense, since there's a frame-limiting option too.
The removal of the vnode happens later than the actual unlink. As part
of the unlink, the vnode cache is already updated to mark the unlinked
directory invalid. This means its entry in the directory list needs to
be removed as well. Otherwise, if a directory list entry is looked up
in the time between unlink and remove_vnode, the assertion which checks
the validity of the directory list entries would fail.
Directory entries are cached using the block cache, so the cached
blocks need to be discarded when directories are removed/shrunk.
Otherwise freed directory blocks that were reused for file data would
later be clobbered when the block cache was flushed.
The forced cache sync for removable media hid the problem for these
devices. It was easily triggered on non-removable media however.
There's no real need to distinguish between first/middle/last parts of
the file and much of the initialization can be done simpler.
This also checks for overflows when truncating the requested length. On
64 bit platforms this would always happen due to the kernel file map
code requesting (size_t)-1 (i.e. unlimited) extents. This lead to the
file end being reached when building the map from a position unequal 0,
which would happen for files fragmented enough to need more than the
default of 8 supplied vectors. An IO error was returned in that case,
rendering the file partially unreadable.
* The decorator now draws the titlebar.
* The titlebar is font sensitive.
* The minimize button is usable.
* The buttons are pressable.
* Fix a redraw issue.
At least right now, the constructor of ServerInfoSender can only fail
because of OOM.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
Fixes#11716. One minor tweak by me from the original patch
(change "!sender" to "sender == NULL").
CID 991278, but that also causes CID 991176, so both of those
are fixed. Does *not* fix#12156. Might fix some of the outstanding
NFSv4 issues but I didn't look too hard.
This reverts commit ae495ca8fe.
My system volume was mysteriously corrupted while booting or shutting down today,
enough to make it unbootable and KDL on attempt to mount it. I'm assuming our gcc2
still isn't safe with regard to -O2 optimization of filesystems, and revert this,
until proven wrong (eg. by running test suites and FS stress tests and finding no
issues.
Axel comented on the commit saying it probably was not a good idea, but no action was
taken. Should we setup a better commit review system?
Revert the Tracker portions of hrev48858, they were not needed and were not
right either... sorry guys
OpenTargetFolder add-on modified slightly to use the passed in symlink(s) only,
the parent directory ref is unused, it appears to be unneeded here also.
With this and the reverted commits Zip-O-Matic and other add-ons should
work again.
Fixes#12105
* Try to standardize between the names
to make them easier to understand
* Avoid terms like "File system" as it can
confuse users (these are just partitions)
* We don't want to list *every* GUID here,
just the ones most desktop users *might* see
(we skip things like cepf)
* The alternate / backup block wasn't defined
leading to an invalid configuration.
* This was compounded with another issue that
was resolved a while back with GPT
* gdisk now identifies GPT systems created with
Haiku as valid
This was fixed in 2008 in the ide_pci driver, but has never been merged
in ide_isa. It probably won't matter as machine with IDE on the ISA bus
are unlikely to run Haiku.
Thanks to philcostin for finding the problem using cppcheck.
* This would be a GPT partition pointing to itself, leading to infinite
recursion in the GPT parser calling itself and Haiku would reset
(probably triple fault?).
* Thanks to Puck for discovering this!
* Remove the BBox.
* Don't resize buttons when horizontally resizing the window.
* Compute the server address field width correctly by taking the label into
account.
* There is no need for the Intel partitioning system to write MBR
bootcode on non-x86 systems
* The MBR_HEADER define is used to prevent Jam from making MBR.h
a dependency; the dependency is then specified explicitly when
building for x86/x86_64 platforms
* This should support both GPT and MBR formatted partitions.
* To boot Haiku from a GPT partition, it must have the correct
BFS UUID for the partition.
* Tools such as gdisk/gptfdisk can create partitions with
the correct BFS UUID.
On 64 bit platforms a 64 bit size_t was written at the (incorrect)
uint32 on the stack, causing the adjacent bytes variable to be
clobbered. Because of this, the vectors wouldn't actually be filled
with any file data, making the content of files inacessible.
* Incorrect handling of realloc() failure (if reallocation fails,
original buffer is still allocated and must be freed),
* Use of bit shift on signed integer (undefined behavior in C and C++).
Since zip has been outsourced, it's possible to loose it when
upgrading, in which case ZOM went busylooping without noticing the
thread actually never started.
At least now it says "failed to create the archive".
Maybe it should try to install zip?
