Bug#348740: moc: looks bad with utf8 locale
On Wed, Jan 18, 2006 at 08:24:36PM +0200, Eugeniy Meshcheryakov wrote: > Package: moc > Version: 2.3.3-1 > Severity: important > Tags: patch l10n > > When run with UTF-8 locale moc does not display non-latin characters > well, as shown on (locale uk_UA.UTF-8): > http://www.cluster.kiev.ua/eugen/moc-bug/bad.png > > Attached patch fixes this problem, result is shown in > http://www.cluster.kiev.ua/eugen/moc-bug/good.png > > Patch changes one m4 file, so you will need to regenerate auto* files > after applying the patch. The patch works nice as I can see on the screenshot, but as Elimar already said UTF-8 support is in 2.4. I'm not going to include it into MOC, because it's not so easy :). For example: with this patch it is possible to run MOC only with ncursesw (which not everybody has) and probably only in UTF-8 terminal. -- Damian Pietras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#348740: moc: looks bad with utf8 locale
On Thu, Jan 19, 2006 at 01:46:37AM +0200, Eugeniy Meshcheryakov wrote: > 18 січня 2006 о 20:42 +0100 Elimar Riesebieter написав(-ла): > > severity 348740 minor > Well, it is not really minor, it is comletely unusable when playlist > contains songs with titles written with Cyrillic letters (in UTF8)... > > Please have a look at http://moc.daper.net. Damian has introduced > > UTF-8 support in version 2.4.0-alpha2-1. 2.4.0-alpha2-2 can be > > tested from > > > > deb http://www.lxtec.de/debarchiv binary-powerpc/ > > deb http://www.lxtec.de/debarchiv binary-i386/ > > deb-src http://www.lxtec.de/debarchiv sources/ > > > Well, I tested it and I saw the following picture: > http://www.cluster.kiev.ua/eugen/moc-bug/new.png > > And language in playlist does not look like Ukrainian to me :(. Encoding > probably can be fixed, but note the length of bar over selected song - > it is too short (see my patch for posible solution of this). But at > least this version is linked with libncursesw5... Another problem with your patch I didn't mention is that the interface code has changed much in 2.4, so I can't use it in the new version. If you want help (and help is needed, because I can test it for polish and can't do it well for other) use the current SVN version and fix it for your language. -- Damian Pietras
Bug#307651: mocp crashes on "back"
On Wed, May 04, 2005 at 04:27:06PM +0300, Oleg Grenrus wrote:
> Package: moc
> Version: 2.2.1-1
>
> When in playlist is just one file, repeat is on and i press 'b' - back,
> mocp crashes, with error message:
Thanks for the report. THe patch is included (for 2.2.1 and
2.3.0-alpha1).
--
Damian Pietras
Index: playlist.c
===
--- playlist.c (revision 1231)
+++ playlist.c (revision 1232)
@@ -780,7 +780,7 @@
{
int i;
- i = plist->num;
+ i = plist->num - 1;
while (i > 0 && plist_deleted(plist, i))
i--;
pgpY0jUOiAVqa.pgp
Description: PGP signature
Bug#331328: moc: random crashes
On Thu, Sep 22, 2005 at 12:46:46AM +0200, Knoppix User wrote: > Well on x86 random crashes on serval situations appear > like: > -) selecting a song, and it segfaults, new startup usually works > -) static crashes on startup, after processing the file list is > segfaults/exits > -) exceptional crashes -somewhen-anytime- > > i cannot track it with gdb, just tried once in which case a gui appears > , tries to read the playlist, i control-c that and continue gdb, no gui > appearing anymore Sorry, it is not enough to fix it. Please try to use gdb with the core file: 'gdb mocp core', there should be a core file after crash, if not, check your confguration: ulimit -c should have non-zero value (like 1024). Does it really crach in the same directories, with the same playlists where sometimes it doesn't? I know there is probably a bug in libid3tag in Debian causing a segfalut on some mp3 files, I haven't track it down, but I have an mp3 that crashes MOC and madplay -v file.mp3. Maybe there is a file that shows this bug? Try setting ReadTags to no in the configuration file. -- Damian Pietras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#331521: moc: Assertion fault in UI
On Mon, Oct 03, 2005 at 10:24:40PM +0200, Christian Häggström wrote: > In my filewindow I had searched for a string which limited the files > listed to two entries. When moc had played the current song and was > about to switch to the next, the user interface crashed. The daemon > continued to play in the background. > > mocp: menu.c:489: menu_item_set_time_plist: Assertion `i != -1' failed. > Aborted (core dumped) Thanks, included patch should fix the problem. -- Damian Pietras Index: menu.c === --- menu.c (revision 1680) +++ menu.c (working copy) @@ -486,9 +486,8 @@ assert (menu != NULL); i = find_item_plist (menu, plist_num); - assert (i != -1); - - menu_item_set_time (menu, i, time); + if (i != -1) + menu_item_set_time (menu, i, time); } void menu_item_set_format (struct menu *menu, const int num,
Bug#326168: moving a file crashes mocp
On Fri, Sep 02, 2005 at 04:57:38PM +1000, Nathan Hurst wrote: > Package: mocp > Version: moc > Severity: normal > > 1. find a file in the moc browser > 2. mv the file to a new name in shell > 3. hit play on the old file name in moc > 4. moc goes into an infinite loop, and displays some random chars on the > file type widget Thanks for the report. This is already fixed in my development branch for 2.3 and will be fixed in 2.3.2. -- Damian Pietras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#369075: moc: doesn't work after sending it strange options
On Sat, May 27, 2006 at 12:12:40PM +0200, Bartosz Fenski aka fEnIo wrote: > I wanted to skip currently played song and I didn't remember exact option > to do so and I wrote: > > mocp -nexr > > Yes, that was typo by the way. Music stopped playing. It stopped, bacause you used -x which means exit. Typing -nexr is valid: you enabled 4 options: -n - next -e - recursively -x - exit (stop the server) -r - previous > and when I tried to > launch moc again I got: > > ([EMAIL PROTECTED])~$mocp > Running the server... > Trying JACK... > Trying ALSA... > mocp: relocation error: mocp: symbol snd_pcm_hw_params_get_channels_min, > version ALSA_0.9.0rc4 not defined in file libasound.so.2 with link time > reference Sounds like linking issue - you probably have libasound.so.2 older than MOC was compiled with or something like that. It appeard after you used -x because only the server uses libasound.so.2, so after -x another mocp command tried to run the servcer again. -- Damian Pietras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413586: moc: use 'a' to add a directory as well
On Tue, Mar 06, 2007 at 09:21:52PM +0100, Elimar Riesebieter wrote: > forwarded 413586 Damian Pietras <[EMAIL PROTECTED]> > > thanks > > Hi Damian, > > what do you think of that idea? Should it go into 2.5.0? Seems to be a good change, I think I'll merge it. -- Damian Pietras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#416102: moc: pressing 'A' in a directory without subdirectories seems to add all files a level or two above
On Sat, Mar 24, 2007 at 05:17:56PM -0500, Good Times wrote:
> I was in a directory without subdirs and when I pressed A, there was a
> long pause and then lots and lots of files added to my playlist
Thanks. The attached patch fixes the problem and will be included in
futer releases.
--
Damian Pietras
Index: interface.c
===
--- interface.c (revision 1986)
+++ interface.c (revision 1987)
@@ -1663,7 +1663,7 @@
}
- if (!strcmp(file, "../")) {
+ if (!strcmp(file, "..")) {
error ("Can't add '..'.");
free (file);
return;
Bug#392106: mocp consumes too much memory if playing many hours
On Tue, Oct 10, 2006 at 10:47:35AM +0200, DaVinci wrote: > Package: moc > Version: 2.4.0-2+b1 > Severity: normal > > I don't understand why, but if mocp is much time playing music, it > consumes a great account of memory. With other players like cmus, that > account is constant along time. In mocp, it increments progresively. First, how do you mesure it and what are the numbers? People sometimes tell me that MOC uses much memory seeing the VSZ column in ps output or the VIRT column in top. This memory is not physically allocated, but MOC uses mmap() to map whole files to memory. The real memory used is in the RSS colums. -- Damian Pietras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392106: mocp consumes too much memory if playing many hours
On Wed, Oct 11, 2006 at 01:08:44PM +0200, DaVinci wrote: > El miércoles 11 de octubre, Elimar Riesebieter escribió: > > On Wed, 11 Oct 2006 the mental interface of > > DaVinci told: > > > > [...] > > > I have not tryed. I'll see it playing a gigantic list. But I want to > > > know: do you all experience a constant used memory increment when > > > running moc? > > > > Running mocp for more than 1 hour with a playlist of about 400 titles: > > > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > > 7127 riesebie 15 0 75560 7936 3144 S 2.0 1.0 1:21.74 mocp > > Great test. Now I have found something new. If I use moc with mp3 or > wav files, memory use is stable, like yours, but when I play flac files > the problem with raising memory use appears. > > Perhaps a question of interfacing with flac library? I've discovered a memory leak in the code that read tags for FLAC files. I don't really belive that this could cause such big memory consumption, but you can try the attached patch. -- Damian Pietras Index: decoder_plugins/flac/flac.c === --- decoder_plugins/flac/flac.c (revision 1931) +++ decoder_plugins/flac/flac.c (working copy) @@ -356,6 +356,8 @@ } else free (value); + + free (name); } static void get_vorbiscomments (const char *filename, struct file_tags *tags)
Bug#392106: mocp consumes too much memory if playing many hours
On Wed, Oct 11, 2006 at 01:08:44PM +0200, DaVinci wrote: > El miércoles 11 de octubre, Elimar Riesebieter escribió: > > On Wed, 11 Oct 2006 the mental interface of > > DaVinci told: > > > > [...] > > > I have not tryed. I'll see it playing a gigantic list. But I want to > > > know: do you all experience a constant used memory increment when > > > running moc? > > > > Running mocp for more than 1 hour with a playlist of about 400 titles: > > > > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > > 7127 riesebie 15 0 75560 7936 3144 S 2.0 1.0 1:21.74 mocp > > Great test. Now I have found something new. If I use moc with mp3 or > wav files, memory use is stable, like yours, but when I play flac files > the problem with raising memory use appears. > > Perhaps a question of interfacing with flac library? Yes, this could be a problem in the FLAC plugin. Talking about mmap(), you can disable using it by putting: UseMmap = no in your ~/.moc/config -- Damian Pietras
Bug#392106: mocp consumes too much memory if playing many hours
On Thu, Oct 12, 2006 at 12:09:41AM +0200, Elimar Riesebieter wrote: > On Wed, 11 Oct 2006 the mental interface of > Damian Pietras told: > > [...] > > I've discovered a memory leak in the code that read tags for FLAC files. > > I don't really belive that this could cause such big memory consumption, > > but you can try the attached patch. > > Running mocp patched shows increasing the mem usage from start playing > a flac at 2.6% to 7% till the end of a 5:30 song. Thats not the > resolution then :( This was done on PPC. Did you try setting UseMmap to no? -- Damian Pietras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#419047: moc: quitting the user interface with a large playlist takes several minutes
On Fri, Apr 13, 2007 at 04:17:56PM +0300, Leo Moisio wrote: > Package: moc > Version: 2.4.1-1 > Severity: important > > > With a large playlist of about 2000 songs, quitting the user interface > by pressing q takes several minutes, while it is almost instant with a > small playlist. It's a feature, not a bug :) > > The status bar of the ui shows that moc is "Reading tags...". MOC by default saves the playlist at exit, so it must read tags for all files. You can turn this off by setting SavePlaylist to "no" in the config file. Alternatively you can set TagsCache to some bigger value to have tags for all your files always in the cache (in memory if the server is running). Try sizes like 2048 and more (it's in KB). After the first read MOC should exit faster. > Toggling read tags with f key before quitting takes just a couple > seconds, but does not make quitting faster. That's because tags for the whole playlist are already queued for read. -- Damian Pietras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#432673: moc: Line editing in "i" and "o" commands gets corrupted
On Wed, Jul 11, 2007 at 07:02:04PM +0200, Elimar Riesebieter wrote: > On Wed, 11 Jul 2007 the mental interface of > Martín Ferrari told: > > > Package: moc > > Version: 1:2.5.0~alpha2-1+b1 > > Severity: normal > > > > When using the go to directory (i) or open url (o) commands, and you use > > the delete/backspace to edit the line, the text after the cursor gets > > corrupted. > > > > Example: > > > > ???URL: http://gaogle.com/_ > > > > I go to the 'a' and press delete: > > > > ???URL: http://goglle.com > > > > And after a few more deletes in the same position: > > > > ???URL: http://gle > > > > So, you get the idea... > > No, I don't. It seems to be either a locale problem or a problem > with yout terminal. I can reproduce this on my Ubuntu system, no solution for now, but I'll take care of it. -- Damian Pietras
Bug#432673: moc: Line editing in "i" and "o" commands gets corrupted
On Wed, Jul 11, 2007 at 11:35:06AM +0100, Martín Ferrari wrote: > Package: moc > Version: 1:2.5.0~alpha2-1+b1 > Severity: normal > > When using the go to directory (i) or open url (o) commands, and you use > the delete/backspace to edit the line, the text after the cursor gets > corrupted. Attached patch should fix the problem. -- Damian Pietras Index: interface_elements.c === --- interface_elements.c (revision 2033) +++ interface_elements.c (working copy) @@ -426,7 +426,7 @@ memmove (e->text_ucs + e->cur_pos - 1, e->text_ucs + e->cur_pos, -width - e->cur_pos); +(width - e->cur_pos) * sizeof(e->text_ucs[0])); e->text_ucs[--width] = L'\0'; e->cur_pos--; @@ -453,7 +453,7 @@ len--; memmove (e->text_ucs + e->cur_pos, e->text_ucs + e->cur_pos + 1, -len - e->cur_pos); +(len - e->cur_pos) * sizeof(e->text_ucs[0])); e->text_ucs[len] = L'\0'; /* Can we show more after deleting the char? */
Bug#364524: mocp crashes w/ assertion failure (iface_set_mixer_value)
On Sun, Apr 23, 2006 at 08:46:35PM -0400, Ryan Richter wrote:
> When I start mocp, it crashes saying:
>
> mocp: interface_elements.c:3267: iface_set_mixer_value: Assertion `value >= 0
> && value <= 100' failed.
The attached patch should prevent the crash but you will be probably not
able to use one or both mixer channels from moc.
--
Damian Pietras
Index: interface.c
===
--- interface.c (revision 1899)
+++ interface.c (working copy)
@@ -424,7 +424,9 @@
static void update_mixer_value ()
{
- iface_set_mixer_value (get_mixer_value());
+ int val = get_mixer_value ();
+
+ iface_set_mixer_value (val >= 0 ? val : 0);
}
static void update_mixer_name ()
signature.asc
Description: Digital signature
Bug#392106: mocp consumes too much memory if playing many hours
On Mon, Oct 23, 2006 at 10:19:17PM +0200, DaVinci wrote: > Hi again. > > I have probed option "UseMmap = no" and problem dissapear. Now memory > use of moc server is not greater than 0.4% in my machine. > > Is there any bad effect in not using Mmap? No, mmap was supposed to improve performance, but with current versions of MOC it's not true. I'll made this option off by default in the next releases. -- Damian Pietras -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392106: mocp consumes too much memory if playing many hours
On Tue, Oct 24, 2006 at 09:13:56PM +0200, Elimar Riesebieter wrote:
> On Tue, 24 Oct 2006 the mental interface of
> Damian Pietras told:
>
> > On Mon, Oct 23, 2006 at 10:19:17PM +0200, DaVinci wrote:
> > > Hi again.
> > >
> > > I have probed option "UseMmap = no" and problem dissapear. Now memory
> > > use of moc server is not greater than 0.4% in my machine.
> > >
> > > Is there any bad effect in not using Mmap?
> >
> > No, mmap was supposed to improve performance, but with current versions
> > of MOC it's not true. I'll made this option off by default in the next
> > releases.
>
> So do you agree to close this bug then?
I don't know if we can even say it's a bug in MOC, but it's definitelly
resolved :)
If you want to have MOC with this option turned off by default, you gan
change the line in options.c:
option_add_int ("UseMmap", 1);
to:
option_add_int ("UseMmap", 0);
--
Damian Pietras
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
