Bug reports

Hi everyone,
today I update the packages in debian testing (amd64) and MOC updated to 2.5.0~beta2-1 version.

Now when I try to start the MOC session it fails with a segfault error without more info (--debug yields same result):
$ mocp
Fallo de segmento # segment fault, in english
$ echo $?
139


In the syslog appears:
mocp[11405]: segfault at 0 ip 00007f2eeff3f0b6 sp 00007fff74b11be8 error 4 in libc-2.18.so[7f2eefebf000+1a0000]

And with gdb:
(gdb) run
Starting program: /usr/bin/mocp
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff5a090b6 in ?? () from /lib/x86_64-linux-gnu/libc.so.6

Didn't try to compile it because I think this is the last stable version but if it's necessary I'll probe.

I hope this would be valuable info to fix it. Thanks for your time and for this awesome player :-)

hello everyone, i'm new at this forum!
I don't know if this is a but that's my problem: I was learning changing the moc themes, but I don't find a way to make it permanent. When I close it and re-open, the changes don't have effect. Does anyone know how to fix it?

thanks for this useful program, it is what i was looking for!

mocp crashed when quitting and having opened a directory, which partition was at that time in errorneous state. I don't konw if this can be reproduced and I don't know what exactly caused this, so I'll try to just describe what happened.

I left moc daemon and mocp (in a console window) running over weekend having opened a media folder on a NTFS partition on a USB-connected drive. Earlier today I just closed the console player and did not care about the daemon.

Now I was trying to save something on the partition and found out that there was something wrong: ls -l on a symlink leading to folder on the partition wared about "I/O Error" and shown one of sub-folders with "?????" instead of some details. So I went to re-mount the drive. Obviously moc demon was preventing that so I opened mocp again and hit S-Q.

That's when mocp crashed.

This happened on Fedora 20. The crash was caught by ABRT (Automatic Bug Reporting Tool) and stack trace was generated. So what I have is the "problem data", a tarball of a /var/tmp/abrt/ccpp* subdir, where abrt keeps information related to crash

The download link for moc-2.5.0-beta2 points to the beta1 release:
http://ftp.daper.net/pub/soft/moc/unstable/moc-2.5.0-beta1.tar.bz2

I'm also getting a '403: Forbidden' error when trying to download the signature file: http://ftp.daper.net/pub/soft/moc/unstable/moc-2.5.0-beta2.tar.bz2.sig

Thanks

If somebody opens a URL with the button 'o' for something like "http://moc.daper.net/node/add/forum/19", it will cause an error "Stream error: HTTP response code said error", but it will also continue to try to open it after that error.
> (46!) Stream error: HTTP response code said error
> (120!) Stream error: HTTP response code said error

etc. etc.

Because of this, it takes up a lot of resources on not only the client, but also where it is going (It's literally the equivelant of doing while [1]; do curl www.google.com ; done )

And because "queued_message_errors" is defined as a 32bit int, if we were somehow able to make that number go past 2147483648, it would cause a int overflow (just under extreme circumstances, lol.) -- It would take 9.72159 years, but it would work!!

I've got a folder called 'Music', which contains all .WAV files.
All of those .WAV files contain no 'data' chunk marker on them.
So, when I play one of the songs, it givs this error: "Can't open file: Error in WAV file. No 'data' chunk marker", and skips onto the next song. Because the next song doesn't have it either, it gives the error again and skips onto the next. And again, and again.

It makes mocp unusable, and you can't even quit mocp. The only way to exit is to pkill mocp.. It also uses 150% CPU.

It just keeps flashing the error, and you can't do a single thing.

Hi,

when trying to play a corrupted mp3 file moc seems to crash, freezing the whole raspberry pi. Unfortunately no log files are saved. Everything just stops working so it's kind of hard to trace the problem. Since it only happens when I play this specific file until the corrupted part I assume it's a bug in moc.

All I can say is: The audio is played, some strange noise appears and then everything crashes. :o)

So, I've encountered a strange bug..
Currently, when I adjust the volume within mocp, it is only audible from 90%-100%.

When opening 'alsamixer' on the same computer, it seems that..
[MOCP - AlsaMixer(real)]

89% - 2%
90% - 11%
91% - 21%
92% - 30%

etc..

So I can only change volume for per 10% within mocp..

As you can imagine, it's pretty frustrating!!

It didn't happen yesterday, and I don't think I did anything over-night.. I just listened to the radio(That being said, I'd never used the radio on mocp before)..

Here's my config file for mocp..

Theme = /usr/local/share/moc/themes/green_theme

## Show file titles (title, author, album) instead of file names.
ReadTags = yes

MusicDir = "/home/user/Music"

ShowStreamErrors = yes

Repeat = yes

AutoNext = yes

FormatString = "%(n:%n %t:%t)"
#%(a:%a - :) %(t:%t:)%(A: (%A):)"

HideFileExtension = yes

I'm using external Bose speakers, and in AlsaMixer the only 'playback' device is a single 'PCM'. (In MOCP, the volume thing is Master 90% -- Could this be the reason?)

I'm using PulseAudio and ALSA.

Thanks