Krister Lagerstrom wrote:
> Aubin Paul wrote:
>> On Mon, Oct 27, 2003 at 06:39:38PM +0100, Dirk Meyer wrote:
>
> ...
>
>>>Sorry for the long mail, but it may help you to understand the stuff
>>>and find bugs in the future (not that there are bugs).
>>>
>>>
>>>Please test it!
>> Thanks for finding t
I've run into the same problem; it's not consistent, but about a third
of the time, there is a delay when quitting mplayer, and it ends up
having to kill it with a -9.
I tried to send a double quit, which worked for the most part, but if
the first quit went through, it would cause problems since t
Aubin Paul wrote:
On Mon, Oct 27, 2003 at 06:39:38PM +0100, Dirk Meyer wrote:
...
Sorry for the long mail, but it may help you to understand the stuff
and find bugs in the future (not that there are bugs).
Please test it!
Thanks for finding this; I remember fixing a bug like this awhile back
wit
On Mon, Oct 27, 2003 at 06:39:38PM +0100, Dirk Meyer wrote:
> NO
:)
>
> directory.py eventhandler:
>
> Playlist.eventhandler(self, event, menuw)
>
> changing it to
>
> return Playlist.eventhandler(self, event, menuw)
>
> and the
Aubin Paul wrote:
> On Mon, Oct 27, 2003 at 04:43:21PM +0100, Dirk Meyer wrote:
>> It's only needed if you skip to the playlist too fast.
>
> That's not when this is happening. The problem arises for basic
> playback. I play a folder full of music (it plays a track, and then
> when the first finis
On Mon, Oct 27, 2003 at 04:43:21PM +0100, Dirk Meyer wrote:
> It's only needed if you skip to the playlist too fast.
That's not when this is happening. The problem arises for basic
playback. I play a folder full of music (it plays a track, and then
when the first finishes, just before the second
Aubin Paul wrote:
> This is with the latest snapshot. I commented out the 'raise OSError'
> because it's not being trapped anywhere.
It's only needed if you skip to the playlist too fast.
> At this point, nothing crashes, but the music player "stops" and it
> returns to the song list, with mplay
