There is a bug when using ast_seekstream/ast_tellstream with format_mp3 in that
the file read position is not reset before attempting to read samples. So when
we seek to determine the maximum size of the file (as in res_agi's STREAM FILE)
we weren't then resetting the file pointer so that we could properly read
samples. This patch addresses that (in a similar manner to format_wav.c).
(closes issue #15224)
Reported by: rbd
Patches:
20091230_addons_1.4_issue15224.diff uploaded by seanbright (license 71)
Tested by: rbd, seanbright
Review: https://reviewboard.asterisk.org/r/453
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@238014 f38db490-d61c-443f-a65b-d21fe96a405b
This problem was introduced when the AST_FRIENDLY_OFFSET patch was merged.
I'm surprised that nobody noticed any trouble when testing that patch, but this
fixes the code that fills in the buffer to start filling in after the offset
portion of the buffer.
(closes issue #15850)
Reported by: 99gixxer
Patches:
issue15850.diff1.txt uploaded by russell (license 2)
Tested by: 99gixxer
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@217113 f38db490-d61c-443f-a65b-d21fe96a405b
format_mp3 claimed that it provided AST_FRIENDLY_OFFSET in frames returned by
read(). However, it lied. This means that other parts of the code that
attempted to make use of the offset buffer would end up corrupting the fields
in the ast_filestream structure. This resulted in quite a few crashes due to
unexpected values for fields in ast_filestream.
This patch closes out quite a few bugs. However, some of these bugs have been
open for a while and have been an area where more than one bug has been
discussed. So with that said, anyone that is following one of the issues
closed here, if you still have a problem, please open a new bug report for the
specific problem you are still having. If you do, please ensure that the bug
report is based on the newest version of Asterisk, and that this patch is
applied if format_mp3 is in use. Thanks!
(closes issue #15109)
Reported by: jvandal
Tested by: aragon, russell, zerohalo, marhbere, rgj
(closes issue #14958)
Reported by: aragon
(closes issue #15123)
Reported by: axisinternet
(closes issue #15041)
Reported by: maxnuv
(closes issue #15396)
Reported by: aragon
(closes issue #15195)
Reported by: amorsen
Tested by: amorsen
(closes issue #15781)
Reported by: jensvb
(closes issue #15735)
Reported by: thom4fun
(closes issue #15460)
Reported by: marhbere
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@215212 f38db490-d61c-443f-a65b-d21fe96a405b
Someone asked yesterday, "is there a good reason why we can't just put these
modules in Asterisk?". After a brief discussion, as long as the modules are
clearly set aside in their own directory and not enabled by default, it is
perfectly fine.
For more information about why a module goes in addons, see README-addons.txt.
chan_ooh323 does not currently compile as it is behind some trunk API updates.
However, it will not build by default, so it should be okay for now.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@204413 f38db490-d61c-443f-a65b-d21fe96a405b
seanbright