Event codes

[mvallevand]

I've been having trouble with WebRadio dieing on certain streams on the PC that work fine on the PCH. The PC log events seem to follow the same

2011-04-05 19:35:32.807 [DEBUG][1] GetEventCode() returned: 0x000d
2011-04-05 19:35:32.807 [DEBUG][1] GetEventCode() returned: 0x000e
2011-04-05 19:35:46.678 [DEBUG][1] GetEventCode() returned: 0x0003
2011-04-05 19:36:03.478 [DEBUG][1] GetEventCode() returned: 0x0001
2011-04-05 19:36:03.479 [DEBUG][1] TrackEnded()

What does this sequence mean anything?

Martin

[sub]

These are directshow event codes, like EC_COMPLETE (0x0001). If you look in Windows SDK's evcode.h, it has a description of the various codes.


#define EC_COMPLETE 0x01
// ( HRESULT, void ) : defaulted (special)
// Signals the completed playback of a stream within the graph. This message
// is sent by renderers when they receive end-of-stream. The default handling
// of this message results in a _SINGLE_ EC_COMPLETE being sent to the
// application when ALL of the individual renderers have signaled EC_COMPLETE
// to the filter graph. If the default handing is canceled, the application
// will see all of the individual EC_COMPLETEs.


#define EC_CLOCK_CHANGED 0x0D
// ( void, void ) : application
// Notify application that the clock has changed.
// (i.e. SetSyncSource has been called on the filter graph and has been
// distributed successfully to the filters in the graph.)


#define EC_PAUSED 0x0E
// ( HRESULT, void ) : application
// Notify application the previous pause request has completed

#define EC_ERRORABORT 0x03
// ( HRESULT, void ) : application
// Operation aborted because of error

[mvallevand]

These are directshow event codes, like EC_COMPLETE (0x0001). If you look in Windows SDK's evcode.h, it has a description of the various codes.

Ok that's good to know. The pause is especially odd since I don't issue one. Is that part of live mp3 streaming at your end?

Martin

[sub]

The pause will have been generated by one of the directshow filters in the graph, when failed to get any data or something like that, so the source filter issued a pause to try waiting for data.

[mvallevand]

Ok thanks, I don't know enough about direct show to understand what it does. I was able to get several streams to play through by prebuffering 160k instead of 128k, it seems like a lot for 48 kbs streams.

Martin

[sub]

Its next to impossible to tell why these directshow send these particular messages unless you can find documentation describing their behaviour error conditions. It would obviously be easier for me to tell you the reason if they were directshow filters I'd written, but thats not the case for net radio streams.

[mvallevand]

Ok, sorry, I thought you did something extra in NPVRMP3Reader.ax for these growing mp3 files saved to the hard disk (with tag and metadata removed for the mpeg splitter). I remember you having to make some changes to get this to work.

Martin

[sub]

What exactly is the situation here? Is some web radio stream you're asking the API to play via URL, or you're downloading it yourself and saving it to disk as an .mp3 file, then playing it?

[mvallevand]

For WebRadio I download the file and stream it from a file called Gbnetradio-#.mp3 from the logs

Code:

2011-04-05 23:58:53.625    [DEBUG][1]    PlayMusicFiles() queueing:
2011-04-05 23:58:53.625    [DEBUG][1]     - C:\temp\WebRadio\Gbnetradio-3.mp3
2011-04-05 23:58:53.625    [DEBUG][1]    Starting first track: C:\temp\WebRadio\Gbnetradio-3.mp3
2011-04-05 23:58:55.150    [DEBUG][1]    Graph filter list:
2011-04-05 23:58:55.151    [DEBUG][1]     - Default DirectSound Device
2011-04-05 23:58:55.151    [DEBUG][1]     - ffdshow Audio Decoder
2011-04-05 23:58:55.151    [DEBUG][1]     - MPEG-I Stream Splitter
2011-04-05 23:58:55.151    [DEBUG][1]     - NPVR MP3 Reader

Martin

[sub]

The 'NPVR MP3 Reader' is a fairly simple filter that doesnt do much. It basically represents a file, that misreports its size as being very big, and if the controlling filter ('MPEG-I Stream Splitter' in this graph) askes for a chunk of data that isnt yet in the file, it'll wait up to 5 seconds for data to arrive, before returning the whatever was available.

I dont know how much data the 'MPEG-I Stream Splitter' filter is asking for, but maybe it isnt there within 5 seconds? I could try giving you a version that waits longer?