FATAL_ERROR: Can't send() int to the server. / FATAL_ERROR: Can't receive value from the server.

Submitted by Jangari on Mon, 2010-04-12 03:47

Forums:

I get these two errors whenever trying to cd into a directory that contains sound files with moc. The first error (Can't send() int to the server) I get when the directory contains .wav files, and the other I get when the directory contains .mp3 files.

This is a recently installed system, Ubuntu 9.10 on a very recent HP Pavilion DM1. Moc did work, I recall, at one point. I'm not sure what I did to break it, but I did copy over my entire ~/.moc directory from my old machine. I've tried removing and reinstalling moc entirely but it hasn't had any effect.

Any ideas?

Jangari

Mon, 2010-04-12 03:50

Probably should have tried this before posting, but moving the config directory fixed the issue, so it's somewhere there.

I'll put shit back into the .moc folder progressively until I find the problem.

lenoch

Mon, 2010-04-12 09:55

Hi,

you can try to run only the server with logging: mocp -SF and then run the client in another terminal. You'll sure get better messages that the generic "can't send int ..." one (it only means that the server has died and therefore the client can't connect to it).
Anyway, the problem has something to deal with your configuration, or maybe missing plugins/libraries? Let's see... :-)

thehijacker

Sat, 2010-07-24 20:46

Here is last few lines in the messages before the crash:

Jul 24 21:55:19.970930: audio_conversion.c:616 audio_conv(): Fast conversion!
Jul 24 21:55:19.972495: player.c:451 decode_loop(): loop...
Jul 24 21:55:19.973818: io.c:568 io_prebuffer(): prebuffering to 65536 bytes...
mocp: out_buf.c:347: out_buf_time_get: Assertion `time >= 0' failed.
/home/epkg/bin/moc: line 27: 14768 Aborted (core dumped) mocp $PAR

This always happens when he tries to play next mp3 file from the loaded playlist.

I am using latest SVN sources from today.

No idea how to fix this error. Anyone can help me please?

lenoch

Sun, 2010-08-08 13:03

Hi,

I was dealing with this assertion when working on my MPRIS patch (http://moc.daper.net/node/496) some time ago (might get back to finishing it, too).
I lowered the AUDIO_MAX_PLAY constant to be able to read current track time with higher precision (actually, the precision being equal to the constant). This made the assertion trigger more often. By the way, the variable "time" is float, so a relational operator should be avoided, or the type changed (which I did in my patch). What is important, I read a topic about ALSA/PulseAudio issue _somewhere_ that dealt with audio buffers. It made me realize that the requirement of the time value being non-negative could sometimes be _inappropriate_, so I simply replaced the assertion:
-assert(time >= 0);
+if (time < 0) time = 0;
Note that I also changed the variable type to long to work around the questionable operator.

jcf

Wed, 2014-08-13 01:54

I have today committed to SVN r2656 which fixes this bug.

It turns out the assertion being triggered is not valid as a negative time value may arise legitimately if the hardware buffer still contains more samples from the previous file than have been decoded from the next file. This situation is now handled appropriately.

Viorel

Fri, 2010-04-16 00:04

Try:

$ rm -rf ~/.moc/cache

http://www.esdebian.org/wiki/moc-music-on-console#5

lenoch

Fri, 2010-04-16 13:06

I can't say this solution is systematic, we better look for the cause :-)

Kiike

Wed, 2010-10-20 14:53

I am getting the same errors (can't receive value from server and can't send() int to server) when adding M4A files to the playlist. I am using --with-ffmpeg and --without-aac, and it went fine somem time ago. FFmpeg can indeed decode those files so I guess this is a MOC bug. It would be nice if it played the AACs natively, I guess...
I'll try running a gdb session, but don't think it'll help much.
I am using SVN r2251, and ffmpeg-25448 on an iBook G4 with Arch Linux PPC. I have also tried deleting .cache and using a .moc directory from scratch.
Any help would be greatly appreciated,