General discussion

Here you can discuss everything related to MOC which doesn't fit other subforum.

Cant open more than one display

Submitted by GenghisKhan on Sat, 2012-10-20 23:01

Forums:

This is what I get when attempting to open one more console with mocp http://dpaste.de/WHhsO/ (this text will be erased in a month. Please copy this text somehow to fit in this thread or add or tags)

Regressions in mocp layout

Submitted by timthelion on Wed, 2012-10-17 13:50

Forums:

It seems to me, that since the last update on arch linux(we're currently at:

$ mocp -V

This is : Music On Console
Version : 2.5.0-alpha4
Built : Oct 1 2012 18:41:48
Compiled with : OSS ALSA JACK internet streams resample
Author : Damian Pietras
Homepage : http://moc.daper.net/
E-Mail : mocmaint@daper.net
Copyright : (C) 2003-2011 Damian Pietras and others
License : GNU General Public License, version 2 or later

there has been a regression in the way mocp handles small screen sizes. Now it seems to require a larger terminal than before, and when the screen size decreases it often crashes with:

FATAL_ERROR: Layout1 is malformed!

Not sure what has changed.

Timothy

Client Freeze / Corrupt Tags Cache / 'rm -rf ~/.moc/cache'

Submitted by jcf on Thu, 2012-09-27 05:38

Forums:

User tomaszg and I have put some time into investigating the supposed tags cache corruption problem for which the accepted wisdom has been to delete the MOC tags cache. It has actually turned out to be a problem with stale database locks left over after a previous server crash, and I have today committed a patch (r2492) which I believe fixes it.

The Symptoms

  • The client freezes.
  • The server continues playing but does not respond to commands.
  • Neither the server nor the client can be shut down gracefully.

Verification

  • The client's status message indicates a server communication is in progress, usually relating to tags or playlist.
  • The command db_stat -h ~/.moc/cache shows the same WRITE lock being HELD and WAITed for on the same audio file.
  • This does not change significantly after the server is terminated.
  • When the server is terminated the client also terminates with a fatal error about being unable to receive a value from the server.
  • Setting the 'TagsCacheSize' option very low significantly increases the frequency of the problem appearing.

The Cause

  • At some point the server has died while holding a database lock.
  • Eventually the server attempts to acquire the lock and waits forever.
  • Because it's blocked on the lock it cannot service new requests.
  • The client sends a request and waits forever for the response.

Recovery Action

  • kill -9 $(cat ~/.moc/pid)
  • db_recover -h ~/.moc/cache
  • rm -f ~/.moc/cache/log.*
  • mocp

(Note that step 2 will create a 10MB log file. Step 3 deletes it, but you will still need to have sufficient space in your filesystem.)

The Solution

MOC no longer uses files (~/.moc/cache/__db.*) to back the memory in which locks are held. So when the MOC server crashes, any locks it is holding disappear along with the process's memory. This works because MOC uses single-process (though multi-threaded) access to the database holding the tags cache and it appears that losing the file-backed memory does not endanger the database's structural integrity.

Also See

node/825 (this is a textbook example of this problem)
node/599 (here the segfault is the triggering event)

Playlist errors

Submitted by leolfm on Fri, 2012-09-07 18:00

Forums:

Well, this thing http://s17.postimage.org/uw6osl37h/2012_09_07_14_31_53.jpg is really pissing me off.

Some files, when I add to the playlist, is normal, others come with your directory+name
The only difference I found between them was :

directory+name = Stereo
name = JntStereo

Has anyone had this problem, or has, or knows how to solve? thank you :p

mocp segfault with cwd=null when parsing files

Submitted by dflogeras on Mon, 2012-08-13 19:36

Forums:

I have a folder containing a bunch of mp3's, and a .m3u file with the playlist in it, then there seems to be a random (empty) .txt file in the folder.

If I invoke moc with 'mocp *' (I know this is probably bad to do, but I was lazy), it segfaults, with the following backtrace. You can see that cwd is 0x0, and that is what is being passed to strcpy. If I remove the .txt file and invoke 'mocp *' again it does not segfault, interestingly enough. Let me know if I can get more context via the debugger for you. I realize I am being a 'dumb user' by doing 'mocp *', but the app probably shouldn't crash.

I am using Gentoo's version of mocp, compiled from 2.5.0_alpha4_p20120501-r1, which I assume is a checkout of the alpha4 from the date specified (I'm not the maintainer). There are other 2.5.0_alpha4 packages available but I figured I'd use the latest one available to me in case the bug had been fixed.

Program received signal SIGSEGV, Segmentation fault.
(gdb) bt
#0 0x00007ffff697eeb6 in __strcpy_ssse3 () from /lib64/libc.so.6
#1 0x00000000004367ef in make_path (buf=0x7fffffff8710 "", buf_size=8192, cwd=0
x0, path=0x75d020 "01_born_under_punches_(the_heat_goes_on).mp3") at playlis
t_file.c:54
#2 0x0000000000436b71 in plist_load_m3u (plist=0x6ff600, fname=0x7fffffffa7f0 "
/home/dave/Talking Heads - Remain In Light/album.m3u", cwd=0x0, load_serial=0) at pl
aylist_file.c:154
#3 0x0000000000437502 in plist_load (plist=0x6ff600, fname=0x7fffffffa7f0 "/hom
e/dave/Talking Heads - Remain In Light/album.m3u", cwd=0x0, load_serial=0) at playli
st_file.c:408
#4 0x000000000041f23c in process_args (args=0x6fe140) at interface.c:1546
#5 0x00000000004229dc in init_interface (sock=12, logging=0, args=0x6fe140) at
interface.c:3444
#6 0x0000000000413864 in start_moc (params=0x7fffffffd900, args=0x6fe140) at ma
in.c:205
#7 0x0000000000414bbf in main (argc=3, argv=0x7fffffffda98) at main.c:842

Compiling MOC mp3 decoder plugins on CentOS 6

Submitted by kotzenhuber on Mon, 2012-08-06 18:17

Forums:

Hi,

i couldn't find any solution yet.
I'm compiling MOC under CentOS 6. I did install the gstreamer-plugin-ugly package and I do have mp3 running with other applications (mpd/sonata and vlc).
So I am pretty sure that the libs are there. My guess is, that moc looks for the mp3 libs in places that they actually aren't.
Would anyone know just which libs exactly moc will search for and how i can find out whether they're installed on my system and how i might point moc's "configure"script to the right places?

Cheers

svn 2454 search for .a .la files

Submitted by symbianflo on Wed, 2012-07-25 10:51

Forums:

Hi folx , my builds fail with this error, .a .la files are no longer shiped in rpm packages ( I'm talking about mandriva, rosa ,unity a.s.o)

libtool: link: cannot find the library `/usr/lib/libstdc++.la' or unhandled argument `/usr/lib/libstdc++.la'
make[3]: *** [libmodplug_decoder.la] Error 1
make[3]: Leaving directory `/home/build/rpmbuild/BUILD/trunk/decoder_plugins/modplug'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/build/rpmbuild/BUILD/trunk/decoder_plugins'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/build/rpmbuild/BUILD/trunk'
make: *** [all] Error 2

any help would be very useful
Thx

Trouble with Japanese text

Submitted by himoto on Sat, 2012-07-21 08:57

Forums:

Some Japanese text seems to be fine on mocp, which I think is the UTF-8 encoded
But other Japanese text is not displayed properly.

Is there a way to fix this?

Pages

Subscribe to RSS - General discussion