General discussion

hi,

when displaying long id3-tags, MOC cuts the tag at a certain lenght.

for example:

Nine Inch Nails - Another Version of the Truth (Kronos Quartet and Enrique Gonzalez Muller) [Y34RZ3R0R3M1X3D]

results in

Nine Inch Nails - Another Version of the Truth (Kronos Quartet and Enrique Gonzalez Muller) [Y34R]

in my ~/.moc/config i've played around with the "TagsCacheSize" option, from 254 to 512 KB, doesnt seem to help.
the "FormatString" is set to "%(a:%a - :)%(t:%t:) [%(A:%A:)]".

is there some way to display those long id3-tags? i hope this last little annoying problem is solvable somehow.. if so, i would mark MOC as nearly perfect! :)

thank you in advance,

ryz

I'd like to see moc talking my native language. Therefore I've internationalised the source code using GNU gettext.

Patch can be found on http://xpisar.wz.cz/moc-i18n/.

Patch introduces gettext infrastructure, configure --enable-nls flag, sample i18n of "mocp --help" output and Czech translation as a demo.

Because I don't know much about autotools, the patch contains some needless files. I think maintainer can filter the files.

Don't forget to run autoreconf after applying the patch.

If you like it, incorporate it into mainline code. If you dislike something, tell it me, I will try to fix it. I would like to get some feed back before i18ning the whole application.

Which arguments can I use with -Q (--format) ?

I was wondering why moc(2.5.0-a3) would only compile with faad2-2.0* but not with 2.6.

The configure script checks for the presence of the faacDecInit-Function - this function has been renamed in 2.6 to NeACCDecInit.

However, 2.6 is backwards compatible by providing access to the re-named function via #define-directives. These are not used in the test (as the header is not included).

I think there can be an easy solution to this and I'll try to create a patch - but maybe this is already known ?

I would really like to keep using MOC as my main player, however I need to get my music processed by brutefir which applies DRC (room corrections).

This seems to be very "fishy" from the configuration point of view. As far as I know, not many players support further processing by brutefir (mplayer via jack e.g.)

I would like to stay with OSS as my soundcard (lynx l22) is not supported by ALSA yet.

It's easy to use brutefir when the player has ability to play music on stdout, in this case just adding pipe to brutefir is sufficient, but this is not the case of MOC.

I wish I had this functionality: MOC(playing flac) -> brutefir -> OSS (dig. out device) -> external DAC - etc etc

Do you think this could be achieved?

Any help/suggestions highly appreciated.

Hi,

I got a German keyboard layout (qwertz) and am using dwm. In dwm I am assigning tags to different windows with M-[0-9]. This is why i wanted to change the volume_[0-9]0 options to ^[0-9], but then I get following response from mocp:

FATAL_ERROR: Key ^r is defined for refresh and volume_20

i haven't changed anything else at this state, and file says:

.moc/richi.keymap: ASCII English text

Anyone got a solution for this?

If I start with a copied keymap.example again, and want to set the go_to_fast_dir[0-9] option to my uppercase 1-0 letters (on my German keyboard), this would result in !"§$%&/()=, but then mocp will complain about the §:

FATAL_ERROR: Parse error in the keymap file line 100: bad key sequence

I think this is because § is not an ascii char, and vim converts the keymap file to:

.moc/richi.keymap: UTF-8 Unicode English text

Anyone knows how to work around this?

bye
richi

I only want to say thanks for new alpha :) It`s great that project still alive :)

Some time ago I contributed the MIDI-decoder-plugin to MOC. After using it for a while I experienced that playing or just extracting the time-information from some MIDI-files would cause segmentation faults.

Today I was able to track down the problem and it lies within the libtimidity-library. If you are experiencing segfaults with MIDI-playback you should visit the libtimidity project page (http://sourceforce.net/projects/libtimidity) and use the patch I contributed there (there is only one patch).

I hope package maintainers decide to incorporate the patch as there has been no development to the library for about four years...

This post has not much to do with MOC but the chances are good that MOC is the only active player using libtimidity... :-)