bugBongo - Bugs: bug #18627, Player failures should be reported...


bug #18627: Player failures should be reported to the user

Submitter:  Daniel Brockman <dbrock>
Submitted:  Fri 29 Dec 2006 07:42:43 AM UTC
Category:  None Severity:  4 - Important
Item Group:  None Status:  Confirmed
Privacy:  Public Assigned to:  None
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup

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.)

Daniel Brockman <dbrock>
Group administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by dbrock (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2006-12-29 dbrock Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-04b1.
    Corresponding source code