Fri 29 Dec 2006 07:42:43 AM UTC, original submission:
Currently, backend player failure is handled in roughly the same way as backend player success. This is a problem, because it makes problems invisible to the user and therefore difficult to identify and understand. It makes Bongo behave very confusingly when a backend player cannot play a track.
Specifically, when a backend cannot play a track, attempting to play the track will cause the playback indicators (header line, fringe icon, and mode line indicator) to appear briefly and then disappear almost immediately. Then the next track is played, and — given the previous failure —, it is likely that this track will also fail to play. The result is a rapid run-down through the entire playlist — the playback indicators flashing hysterically — until finally the last track is reached and all playback stops.
This is not good for experienced users, and it is especially not good for inexperienced users. Therefore, all player failures should be reported to the user, with error messages from the backend players. When a player fails, playback should stop, to prevent the hysterical playlist run-through. If we don’t stop at the first error, we should at least stop after, say, three consecutive errors.
There is one major problem with this, namely that there appears to be no reasonably easy way to detect when mplayer fails. It doesn’t return an error code, and I don’t think it prints out any message that always means ‘failure to play anything at all’. It does print out error messages — tons of them in fact, even for files it can play — but there is no apparent pattern or regularity in them.
What we could do is treat it as a failure whenever an mplayer process terminates within, say, a second. Is this good enough? Can anyone think of a better solution? Does anyone want to file a bug report on mplayer? :-)
I do think, however, that most players other than mplayer return error codes on failure. Bongo even knows about this and runs a special failure hook, ‘bongo-player-failed-functions’. So if we just did something useful whenever this happened, this bug would be fixed (were it not for mplayer).
Having analyzed the problem in more detail, it doesn’t seem very hard to fix. What’s more, it’s rather important that we do fix it, because it is a serious bug. (I would say ‘I will fix this in X days’, but all such promises I have made in the past have turned out to be lies.)
I will add the development mailing list to CC — I hope noone minds. That will also serve the purpose of announcing the existence of this Savannah project page. (Don’t use it if you don’t want to — the mailing list is still perfectly good for everything it used to be good for. Probably better than this website, in fact, for most purposes.)
|