Bug - FATAL_ERROR: Can't receive value from the server!

Submitted by 1984 on Fri, 2012-12-07 12:42

Forums:

Hi,

What I use:
===========
* Music On Console (version 2.5.0-beta1, revision 2506).
* Arch Linux fully updated.

The Error:
==========
The error "FATAL_ERROR: Can't receive value from the server!" occurs, when I _open a directory_ with .mp3 files and moc crashes. It also happens with all the other formats I normally use except .ogg. I can even play .ogg files.

The History:
============
It started when I installed the sourceforge code which I modified a little. There I got the problem that I couldn't play these (.mp3 etc.) files and got an error message that moc can't find the audio stream (or something like that). So I searched in the internet and deleted my ~/.moc directory and then the above mentioned error ("Can't receive value...") occured. After later using my old backup of the .moc directory (where the audio stream error occured again) I deleted the .moc/cache file and then I again got the "FATAL_ERROR: Can't receive value from the server!" error. And now I'm stuck there.

What I tried:
=============
* Installing the sourceforge code. (unmodified)
* Installing the arch linux package.
* Removing the ~/.moc directory.
* Removing only ~/moc/cache from my old config dir.
* Running mocp -SF and start the client to get a better error message. These are the last three lines:

Dez 7 13:32:55.706626: ffmpeg.c:142 ffmpeg_log_repeats(): FFmpeg said: max_analyze_duration 5000000 reached at 5015510
Dez 7 13:32:55.706672: ffmpeg.c:142 ffmpeg_log_repeats(): FFmpeg said: Estimating duration from bitrate, this may be inaccurate
Speicherzugriffsfehler (Speicherabzug geschrieben)

The last line is german for Seg Fault.

What I assume:
==============
It seems to be somehow related to the cache as it got worse when I deleted my old cache file. It also seems to be related to codecs as it doesn't happen with the .ogg files. The strange thing is, that I used the same version now for a month or so and everything worked. Now the same version doesn't work anymore. There was no update between this behaviour change. Right now my system is completely up to date.

Thx for your help.

Regards,
1984

jcf

Fri, 2012-12-07 18:04

First, thank you for taking the time to provide enough clues for me to get a handle on your problem.

From the information you've given this sounds like another case of FFmpeg's application trashing codec misidentifications.
[br]

  • Does "no update between this behaviour change" also apply to the FFmpeg libraries?
  • If you build with '--without-ffmpeg' does the problem go away?
  • Have you made any changes to the audio files themselves (e.g., retagging)?
  • What happens if use use this option on mocp: -O "PreferredDecoders+=mp3(mp3)"?

1984

Fri, 2012-12-07 19:21

Providing enough information is the least I can do if I get this great open source player and if I want help :)

Before I answer your questions I got some new information which at least explains the weird part of this bug. The arch linux package works! I just didn't uninstall the manual installation correctly and so the new installation of the arch package used some of the binaries, config files etc. that have the bug it seems. So this is an answer to your first question.

1. There is no correlation between the bug and an update.

2. I built it with "./configure --without-ffmpeg; make; sudo make install;" and there was no change in the behaviour.
This is what I got after configuring:

MOC will be compiled with:
Decoder plugins: aac flac modplug mp3 musepack sndfile speex vorbis
wavpack
Sound Drivers: OSS ALSA JACK
DEBUG: yes
RCC: no
Network streams: yes
Resampling: yes
MIME magic: yes

When using an moc installation can I check if it has been compiled with ffmpeg? Just to be shure.

3. I changed two options in my ~/.moc/config a few days ago but I don't think that they change anything in my audio files. At least I hope they don't :D Here are the options:
ShowTime = IfAvailable -> yes
TagsCacheSize = 256 -> 65536
I didn't change anything else with respect to my audio files.

4. If I use this option _everything works_! I've got sound when playing mp3 files and then obviously it doesn't crash anymore when entering a directory with them in it. I also didn't find any problems with other formats. So it seems to be a decoder but not ffmpeg?!

So that's all for now. Did this get you any further? If you need more information, please ask. Thanks for helping!

Regards.

EDIT: From now on (and already in this post) when I talk about an moc installation I'm refering to the installation from the current sourceforge code with a clean .moc dir and not the arch package and any specific config file.

jcf

Fri, 2012-12-07 20:04

You may be running into a bug I recently detected in the ModPlug decoder, although it should only occur with WAV files and manifest as memory exhaustion rather than a segfault. Try building '--without-modplug'.

1984

Fri, 2012-12-07 20:15

Building without modplug didn't change anything. Still the same behaviour and the same error. Can you explain why the package works but the manually compiled code not? It's the same version.

Here's what configure gave me:

MOC will be compiled with:
Decoder plugins: aac ffmpeg/libav flac mp3 musepack sndfile speex
vorbis wavpack
Sound Drivers: OSS ALSA JACK
DEBUG: yes
RCC: no
Network streams: yes
Resampling: yes
MIME magic: yes

1984

Fri, 2012-12-07 20:47

Again new behaviour:

I started moc with "mocp -O "PreferredDecoders+=mp3(mp3)"" after a new installation (without modplug). Then I entered a directory with mp3 files and it crashed.

When I now start it again with "-O "PreferredDecoders+=mp3(mp3)"" it doesn't crash anymore no matter what I do.

When I now start it without "-O "PreferredDecoders+=mp3(mp3)"" it only crashes when I go to directories I haven't visited before (in the same installation) with moc with the option "-O "PreferredDecoders+=mp3(mp3)"" activated.

Started with the option I can play mp3 files. Without I can't.

I know this behaviour is kind of logical but I still wanted to post it.

1984

Sun, 2013-01-13 13:23

* So here's the conclusion after e-mailing a lot:

The problem isn't solved and we couldn't find the bug. It doesn't seem to be strictly moc's fault but still it seems to crash on unexpected behaviour of ffmpeg. So we could assure that ffmpeg triggers the crash.

* The facts:

We could fix the issue by compiling moc with the '--without-ffmpeg' option.

Version of ffmpeg where the bug exists:
|ffmpeg version 0.10||
||built on Feb 15 2012 12:57:58 with gcc 4.6.2 20120120 (prerelease)||
||configuration: ||
||libavutil 51. 34.101 / 51. 34.101||
||libavcodec 53. 60.100 / 53. 60.100||
||libavformat 53. 31.100 / 53. 31.100||
||libavdevice 53. 4.100 / 53. 4.100||
||libavfilter 2. 60.100 / 2. 60.100||
||libswscale 2. 1.100 / 2. 1.100||
||libswresample 0. 6.100 / 0. 6.100|

I couldn't reproduce the error with a self compiled version of libavutil. Even if it was exactly the same version number.

The end of the stacktrace of the crash is:

#0 0xb713402c in av_dict_get () from /usr/lib/libavutil.so.51
No symbol table info available.
#1 0xb717bb0f in ffmpeg_info (file_name=0x81c0698 "/home/user/test.mp3", info=0xaff00468, tags_sel=3) at ffmpeg.c:383
err = 0
ic = 0xaff00500
__FUNCTION__ = "ffmpeg_info"
md = 0xaff013e0
entry = 0x4db0a4e8
#2 0x08078a50 in read_file_tags (file=0x81c0698 "/home/user/test.mp3", tags=0xaff00468, tags_sel=3) at files.c:365
df = 0xb717f800
needed_tags = 3
__PRETTY_FUNCTION__ = "read_file_tags"
__FUNCTION__ = "read_file_tags"

I couldn't get the #1 debug symbols because, as said before, I couldn't reproduce the problem with a self compiled version and so I couldn't get a broken version with debug symbols.

These are the last two lines before the crash of the client log:
Dez 10 11:03:29.368103: protocol.c:92 get_int_noblock(): recv() failed when getting int (res 0): Erfolg
Dez 10 11:03:29.368284: interface.c:190 get_int_from_srv_noblock(): FATAL ERROR: Can't receive value from the server!

There were no exciting lines at the end of the server log.

l0vot

Wed, 2013-02-13 15:31

When attempting to play mp3 files I get this error: Unsupported sample size!. The first time a mp3 is opened after the server starts there seems to be a 50% chance that the server will simply crash, if the server does not crash the first time it does not crash when attempting to play mp3s, it just throws the error.

It seems that the most recent update of ffmpeg is causing my problem, it started after a ffmpeg update, not a moc update, (according to my other machine anyways). Executing # pacman -Syu on the other arch install (which has a working moc) attempts to upgrade ffmpeg, but not moc.

This is on a fully updated arch system BTW

EDIT: #mocp -O "PreferredDecoders+=mp3(mp3)"# appears to fix the problem, does moc have an autodetect problem or something?

jcf

Wed, 2013-02-13 18:14

Yes, we know about this problem and have a patch in testing already (which makes a nice change).

It is caused by the move to "planar" audio types in FFmpeg 1.1. You should find that the problem files have a 'p' appended to the audio format in ffprobe output.

jcf

Tue, 2013-02-19 03:17

I have today committed to SVN r2524 which fixes this problem.

If you wish to cherrypick this patch then you should get the whole patchset r2523:2526 which will fix a couple of related problems.

l0vot

Sun, 2013-02-24 20:05

I am unfamiliar with svn, does the developmental version of moc have the patches?

tomaszg

Sun, 2013-02-24 20:14

No, but next beta will have them.

If you want to try svn, you can download current source by using

svn co svn://daper.net/moc/trunk

in command line. Then you should run "autoreconf", "./configure" and "make install" in the "trunk" directory.