Bug reports

Hi,

=== System ===

* Arch Linux fully updated
* Music On Console (version 2.5.0-beta1, revision 2506) from the Arch Repos

=== Bug ===

When playing an mp3 file with only one channel while using JACK as the soundserver (with ALSA everything works) I get a very loud noise on the second channel. With stereo files everything is fine.

=== My analysis so far ===

Playing the same file with mplayer and ffmpeg or mpg123 the problem doesn't occur. So I think it's not related to the codecs.

Mplayer opens only one channel in the 'Jack Audio Connection Kit' while moc opens two. One of the moc channels is the noise while the other one normally plays the file. As the two channels of MOC in JACK are permanent I think the signal should be splitted.

The Mono option of moc doesn't change anything.

Interestingly ogg files work. It seems that the decoder automatically splits the one-channeled signal and maps it on two channels. The output also runs over two channels and not one as with mp3 files.

=== Any questions? ===

Ask. :)

Best,
1984

I am trying to circumnavigate the crappy re-sampling done by dmix by making sure the stream does not need to be re-sampled in. Moc has ForceSampleRate as an option in it's config file, so I used ForceSampleRate = 48000 in the moc config file. This appeared to work, until one of my 24bit 44100hz files began to play. There were random little pops for the duration of any of the 24 bit files. disabling re-sampling by commenting out the ForceSampleRate option immediately got rid of the pops. the rest of my config file is (or at least the possibly relevant parts):
[code
]ReadTags = yes
Sort = FileName
ShowStreamErrors = no
Mp3IgnoreCRCErrors = yes
OutputBuffer = 1024
InputBuffer = 1024
Prebuffering = 128
SoundDriver = ALSA
JackOutLeft = "alsa_pcm:playback_1"
JackOutRight = "alsa_pcm:playback_2"
OSSDevice = /dev/dsp
OSSMixerDevice = /dev/mixer
OSSMixerChannel1 = pcm
OSSMixerChannel2 = master
AlsaMixer1 = PCM
AlsaMixer2 = Master
AlsaDevice = default
UseMmap = no
ResampleMethod = SincBestQuality
ForceSampleRate = 48000
Allow24bitOutput = yes
UseRealtimePriority = yes
ModPlug_Oversampling = yes

Am I just doing it wrong, or is this a bug.

PS. I already tried to increase the buffer sizes, it didn't help.

Segfault if using mocp --format '%t' (or any other non empty format string, for that matter) against a server instance that is running but not playing a song.

I've added comments here: http://paste.posativ.org/i1u The second comment is not really related to the issue, just a remark.

This is more a suggestion than a bug report :)
When searching for tracks using the / command, the shortcuts 'a' and 'shift+a' to enqueue to playlist cannot work (obviously, because the keystrokes are used to populate the search field).
But it still could be interesting to add items to the playlist while searching, for instance through the use of some other keyboard modifier ?

Thanks in adv. ;)
(using trunk:2522)

Linux Mint 13
MOC was installed with "sudo apt-get...."
so, if I press ctrl+alt+backspace and mocp is running, that when I login, mocp don't run and if I write "top" in terminal, mocp "eaten" 100% CPU.
Sorry for my ruby language and sorry that I can't give log files, but I believe that you understand me =)

Operating system: Arch Linux (with testing repository enabled)
MOC version: 2.5.0-beta1 r2522 (but also happens with the older version in the official repositories)
Where did I get MOC from: Source code (but also happens with the older version in the official repositories)

Logs:

This is the relevant part of the server log:

Feb 15 17:07:28.211640: audio.c:421 play_thread(): Entering playing thread
Feb 15 17:07:28.211665: audio.c:439 play_thread(): Playing item 0: XXX.mp3
Feb 15 17:07:28.211699: server.c:257 wake_up_server(): Waking up the server
Feb 15 17:07:28.211726: server.c:1724 server_loop(): Got 'wake up'
Feb 15 17:07:28.211748: server.c:646 send_events(): Flushing events for client 0
Feb 15 17:07:28.211776: out_buf.c:345 out_buf_reset(): resetting the buffer
Feb 15 17:07:28.211796: player.c:357 precache_wait(): Precache thread is not running
Feb 15 17:07:28.211814: server.c:257 wake_up_server(): Waking up the server
Feb 15 17:07:28.211970: server.c:1724 server_loop(): Got 'wake up'
Feb 15 17:07:28.212053: server.c:646 send_events(): Flushing events for client 0
Feb 15 17:07:28.255901: ffmpeg.c:143 ffmpeg_log_repeats(): FFmpeg said: max_analyze_duration 5000000 reached at 5015510
Feb 15 17:07:28.256147: ffmpeg.c:143 ffmpeg_log_repeats(): FFmpeg said: Estimating duration from bitrate, this may be inaccurate
Feb 15 17:07:28.256225: ffmpeg.c:712 ffmpeg_open(): FFmpeg thinks 'XXX.mp3' is format(codec) 'mp3(mp3)'
Feb 15 17:07:28.256706: server.c:257 wake_up_server(): Waking up the server
Feb 15 17:07:28.256769: server.c:1724 server_loop(): Got 'wake up'
Feb 15 17:07:28.256794: server.c:646 send_events(): Flushing events for client 0
Feb 15 17:07:28.257324: server.c:776 server_error(): ERROR: Unsupported sample size!

This is a variable dump before the error in ffmpeg_init():

fmt_from_codec returns 0
fmt_from_sample_fmt returns 0
codec->id is 86017 = AV_CODEC_ID_MP3
data->enc->sample_fmt is 6 = AV_SAMPLE_FMT_S16P, ///< signed 16 bits, planar

Problem description:

Previously MP3 (and MP4) files worked. I had ffmpeg 1.0.1 installed, and MOC didn't load the ffmpeg plugin (I think it's because it requires version >=1?), so the other MP3 plugin was used and everything worked.

Recently ffmpeg 1.1.2 has became available in the Arch Linux testing repository. After I did the upgrade, MOC loads the ffmpeg plugin correctly and attempts to load MP3 files through ffmpeg, which doesn't work with the error "Unsupported sample size!".

MP3 files play correctly in the command line ffplay tool.

Problem analysis:

As I posted above, ffmpeg is returning a planar sample format (AV_SAMPLE_FMT_S16P) which isn't included in the enumeration on fmt_from_sample_fmt, so the sample format isn't recognized. If the sample format is added to the enumeration, then the audio plays, but it's glitchy.

This is because decode_packet has an if statement to handle planar formats, but it doesn't seem to work correctly (it doesn't seem do the interleaving well). I hacked a workaround to interleave the data in the planes and the MP3s play correctly thereafter.

This occurs using version 2.5.0-beta1 and 2.5.0_alpha4_p20111211 on gentoo (these are the only 2 versions available in portage).

The interface frequently draws glitches as if something is failing to be refreshed when switching between panes. My terminal is rxvt-unicode v9.15. I've attached a picture demonstrating glitches in the bottom left pane.

Hi,
I've been using moc for a while now (at least a year) and I like it.

However I noticed the client takes a lot longer to start if the files in the playlist are on a remote file system. During this startup time moc is unresponsive.

Stracing a starting client shows that it stat()s every file in the playlist 4 times. Why? (ReadTags was set to no, command line was ./mocp -D, build from current svn)

With ReadTags set to yes loading a playlist (obviously) slows down more. Is it possible to expand the ReadTags option to include additional values like "visible or "played" which only request tags for files currently visible on the screen or currently playing?