| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Use new send_packet/receive_frame API.
Bumps libav and ffmpeg version requirements. Revert this commit if you
need an older version.
|
|
|
|
See #577.
|
|
If player is running one SIGINT restarts current track request, two
SIGINT (or more) quit pianobar. Idle main loop (i.e. no player or
submenu) quits on SIGINT. Fixes issue #564.
|
|
^C now works as expected: It interrupts API requests, input prompts and
audio streaming. Timeouts have been removed.
|
|
On one of my machines the first song plays fine, but every track
thereafter fails playing with the following error message:
[volume @ 0x7f6b1c0a1200] [Eval @ 0x7f6b21ab6b60] Invalid chars '.0' at the end of expression '1.0'
[volume @ 0x7f6b1c0a1200] Error when evaluating the volume expression '1.0'
/!\ create_filter volume (Das Argument ist ungültig)
I’m not sure why this fixes the issue, but it might be a bug in ffmpeg.
|
|
A few changes were made to AVFrame and the buffersink. Should be
compatible with ffmpeg >= 2.1 and libav >= 10. Version 1.2/9 do not work
at this point.
|
|
I removed most of the *BSD-related stuff, because I can’t test these. If
this breaks your build, send me a patch please.
|
|
The initial volume setup was ignored as well. Introduced by previous
commit 310900e4be52d11388792d776d9f6b89380bbecd. See
https://github.com/PromyLOPh/pianobar/commit/310900e4be52d11388792d776d9f6b89380bbecd
|
|
Fixes issue #508.
|
|
libav 11 reports an invalid channel layout for mp3 files. This is a
work-around. The problem is fixed with libav 11.1.
|
|
Skipping/quitting while pausing does not play the current packet any
more. Avoid unneccessary calls to av_read_(play|pause).
|
|
If retry is triggered once and openStream fails after that retry is
never set to false, resulting in an infinite loop that cannot be
interrupted by the user.
|
|
Fixes #442.
|
|
Drop minor version check, assuming this workaround is required for all
future versions. See 0a64272db65201fc2ecb3406b89d895966933b99. Fixes
issue #456.
|
|
I’ll give it another shot. ffmpeg’s doc/developer.texi states their
micro version always starts at 100 for this very reason. Use that to
detect ffmpeg and guess its version by looking at major and minor
version numbers. Let’s hope this works.
|
|
Closes #441.
|
|
Song timer was shown without song playing.
|
|
Commit 8012d6cb4bb65a858105ef878c5b98d91b24e1cd was broken in several
ways. Since auto-detection did not work correctly it was replaced by a
user-editable variable. See #439.
|
|
Adds support for ffmpeg 2.2 and 1.2. Right now the maintenance overhead
of supporting both libav implementations is not that big.
Fixes #437 and #435.
|
|
Shouldn’t make a difference right now. Just in case…
|
|
libav 9.12 and ffmpeg 2.2 have been tested.
Here’s why: My mp4 “parser” *cough* never was a mp4 parser in the sense
that it actually understood the file format. Instead it grepped the
input stream for “magic” strings (section identifiers). That alone
should be sufficient to throw away the code and rewrite it. Additionally
libfaad2 has not been updated for ages. I guess it was abandoned in
favor of libav/ffmpeg.
With libav/ffmpeg, which we support both as long as the API’s don’t
diverge too much, pianobar gains fast and reliable AAC and MP3 decoding
without bothering too much about the details. Most users will have it
installed already. On my own machine libav consumes about 2/3 CPU time
compared to the previous solution when playing AAC. Unfortunately memory
usage doubled and my attempts to disable unused protocols/formats/codec
failed due to libav’s API limitations.
While cleaning up a small detail regarding the eventcmd API has changed
too: Song duration and position are measured in seconds instead of
milliseconds now. Since libav/ffmpeg keeps track of accurate timing the
precision pianobar keeps track of can be reduced, while still being
sufficient for most users.
|
|
|
|
1) Make sure that multiple bad playlists in a row don’t result in a
temporary ban
2) Ignore songs skipped because the playlist timed out after pausing for
too long
|
|
Player thread now sets its status correctly. Closes #360.
|
|
Workaround for #355, fixes commit
2c516503d2cb81dd156afc24677ac4bf3caefceb.
|
|
See #352.
|
|
Add commands that always play and always pause, in addition to the
current toggle pause command.
Closes #342.
|
|
|
|
Decoding errors are usually not fatal, so we can recover by skipping the
broken frame. This also fixes invalid memory reads caused by
sampleSizeCurr >= sampleSizeN. See issue #304.
|
|
Pandora limited the audio formats we can request explicitly. Don’t rely
on this and use the formats available with the given partner
credentials. Closes #271.
|
|
Closes #250.
|
|
This reverts commit 7df9371491e96a99c1e463f7787aede352ac5a37.
|
|
This reverts commit f6dffd1822404522b8354ac453a911a0d98bfc61.
|
|
1) Realtime signals don’t exist in OS X
2) libao apparently locks a mutex in ao_play, which is locked again in
ao_close and causes a deadlock
Closes #256, although I’m considering the option of partially reverting
7df9371491e96a99c1e463f7787aede352ac5a37, as this introduces more nasty
behavior than it solves.
|
|
No more mutex locking/checking for quit condition. Should (slightly)
increase responsiveness of the player thread. Closes #250.
|
|
32kbit/s. Closes #233.
|
|
Move player buffer to heap, a few const’s here and there, increase
header buffer size, fix comments.
|
|
as requested by rfc 2616
|
|
Closes #88
|
|
Again. And hopefully the last time.
|
|
|
|
Fixes issue #66 (audio playback on big-endian machines).
|
|
A few byteswaps replaced by conditional byteswaps. Thanks to Andrew Peng
for providing access to a powerpc machine.
|
|
Fixes bug #16.
ao_sample_format structure has been updated, matrix must be NULL.
|
|
|
|
|
|
|
|
|
|
Under certain circumstances (fast station switching e.g.) a new playlist
was not fetched, because the player thread returned 0x1 (== libao error)
and the main thread NULLed curStation.
|
