I’m probably not the first guy to write a media player, for my own use and my own reasons (the main one being the bad randomizers found on almost all the existing players I tried), and while I got it working mostly to my satisfaction, there’s one thing that still annoys me a lot.
It’s bad mp3 files. I have some which are still around from Napster era, and among them there were many aborted downloads, which I never replaced, they were just long enough, and all the other players I had (from Winamp, Foobar on windowses, to Qmmp and Strawberry on linux, and Cog on mac) which would mostly eat any errors, or crash.
The purpose of this player is to be my radio without commercials, so it’s supposed to play indefinitely, and to simply ignore and log such errors and move to next song. Initially there’d be three (!) dialogs, and I wrapped the .Load() and .Play() calls in try-except, which removed the dialogs coming from wx. However, the innermost dialog comes form gStreamer, and I haven’t so far managed to catch that. It just stops playing and waits for someone to come and click OK.
What I’d like to have is for it to work as if on a computer, automatically, no worker tending to it. I know that gStreamer is a couple of levels deeper, wx’s media player is a wrapper around it, but still - if there’s a way to catch that error without any dialog, I’d like to know about it.
well, I haven’t done anything with the MediaCtrl but as I understand you right the events one never puts them into a try: if the wrapper is written properly you will receive them if you bind them
on the other hand your tracks stop on a fault which the wrapper doesn’t catch and thus can’t hand over to you
the try-except can only react on faults in the Python part, i.e. outside the MediaCtrl
I think I have reproduced your error by creating a truncated mp3 from a good mp3 file and then trying to load it into the Media Ctrl example from the wxPython demo.
I noticed the “Media_ctrl_demo Error” dialog contained the phrase “Media playback error”.
I searched for that phrase in the wxWidgets 3.2.6 source code and found it in src/unix/mediactrl.cpp
//-----------------------------------------------------------------------------
// wxGStreamerMediaBackend::CheckForErrors
//
// Reports any errors received from gstreamer. Should be called after any
// failure.
//-----------------------------------------------------------------------------
bool wxGStreamerMediaBackend::CheckForErrors()
{
wxMutexLocker lock(m_mutexErr);
if ( m_errors.empty() )
return false;
for ( unsigned n = 0; n < m_errors.size(); n++ )
{
const Error& err = m_errors[n];
wxLogTrace(wxTRACE_GStreamer,
"gst_error_callback: %s", err.m_debug);
wxLogError(_("Media playback error: %s"), err.m_message);
}
m_errors.clear();
return true;
}
I think it’s the call to wxLogError() that is displaying the dialog i.e. the dialog is created by wxWidgets and not gstreamer.
See Log Classes Overview — wxPython Phoenix 4.2.2 documentation for the equivalent wxPython functions. That page contains some information about customising the handling of the log functions. I haven’t read it in detail, but perhaps there is a way to stop wx.LogError() calls from displaying a dialog in an application?
I added a call to wx.Log.SetLogLevel(wx.LOG_FatalError) in the demo example and the dialog no longer appeared when I tried to load the truncated mp3 file.
I don’t know whether this will have any unwanted side effects in the rest of the application.
