[1.3.0.0] YT Videos frequently don't start on first attempt (1 Viewer)

[tourettes]

Bad news. I tried many YT videos and several from other sites, but nothing Each video starts playing without any problem.

*Damn*
Anything I can do here to help gather more data? Debugversion/logging of the filters maybe? @tourettes ?

Additional logging would help, but there is just too many places (MPAR + source filter) that could go wrong so it is really hit and miss to try to find it. Current MPAR log looks ok, does the OV source filter log anything? Is there any differences in the log when the playback fails?

 

[tourettes]

@georgius @tourettes
Anyone of you had time to take a look? Would highly appreciate it!

Currently always switching back to the default audio renderer when watching YT-videos in OnlineVideos and playback works flawlessly that way.
I am a bit confused that I seem to be the first person to report this issues of OV in combination with MPAR.

You are not alone. I have posted this before here : https://forum.team-mediaportal.com/...ixes-for-1-3-0-beta.109738/page-3#post-921809

The issue is probably not bad as I didn't receive any logs when requested Althou based on iloop's logs there is no clues in the logs.

 

[Jelmo]

@georgius @tourettes
Anyone of you had time to take a look? Would highly appreciate it!

Currently always switching back to the default audio renderer when watching YT-videos in OnlineVideos and playback works flawlessly that way.
I am a bit confused that I seem to be the first person to report this issues of OV in combination with MPAR.

You are not alone. I have posted this before here : https://forum.team-mediaportal.com/...ixes-for-1-3-0-beta.109738/page-3#post-921809

The issue is probably not bad as I didn't receive any logs when requested Althou based on iloop's logs there is no clues in the logs.

You are right. Was bussy to check this issue. Hopefully i will have time on Thuesday to provide the files.

 

[georgius]

Bad news. I tried many YT videos and several from other sites, but nothing Each video starts playing without any problem.

*Damn*
Anything I can do here to help gather more data? Debugversion/logging of the filters maybe? @tourettes ?

Additional logging would help, but there is just too many places (MPAR + source filter) that could go wrong so it is really hit and miss to try to find it. Current MPAR log looks ok, does the OV source filter log anything? Is there any differences in the log when the playback fails?

There is no additional logging (except MPUrlSourceSplitter.log file) from source filter. I analysed again logs from @infinite.loop and found interesting sequence:

27-11-2012 21:21:13.665 [ a64] [{80E9C286-2E1D-4D57-81B5-3C53D7BF8095}] [Info]    LAVSplitter: Pause(): Start
27-11-2012 21:21:13.667 [ a64] [{80E9C286-2E1D-4D57-81B5-3C53D7BF8095}] [Info]    LAVSplitter: Pause(): End
27-11-2012 21:21:13.669 [13a8] [{80E9C286-2E1D-4D57-81B5-3C53D7BF8095}] [Info]    LAVSplitter: ThreadProc(): no command
27-11-2012 21:21:13.754 [ cb4] [{80E9C286-2E1D-4D57-81B5-3C53D7BF8095}] [Info]    LAVSplitter: Run(): Start
27-11-2012 21:21:13.773 [13a8] [{80E9C286-2E1D-4D57-81B5-3C53D7BF8095}] [Info]    LAVSplitter: ThreadProc(): CMD_PLAY
27-11-2012 21:21:13.774 [ cb4] [{80E9C286-2E1D-4D57-81B5-3C53D7BF8095}] [Info]    LAVSplitter: Run(): End
27-11-2012 21:21:13.774 [ cb4] [{80E9C286-2E1D-4D57-81B5-3C53D7BF8095}] [Info]    LAVSplitter: Pause(): Start
27-11-2012 21:21:13.776 [13a8] [{80E9C286-2E1D-4D57-81B5-3C53D7BF8095}] [Info]    LAVSplitter: ThreadProc(): CMD_PAUSE
27-11-2012 21:21:13.776 [ cb4] [{80E9C286-2E1D-4D57-81B5-3C53D7BF8095}] [Info]    LAVSplitter: Pause(): End
27-11-2012 21:21:13.826 [ cb4] [{80E9C286-2E1D-4D57-81B5-3C53D7BF8095}] [Info]    LAVSplitter: Run(): Start
27-11-2012 21:21:13.828 [13a8] [{80E9C286-2E1D-4D57-81B5-3C53D7BF8095}] [Info]    LAVSplitter: ThreadProc(): CMD_PLAY
27-11-2012 21:21:13.841 [ cb4] [{80E9C286-2E1D-4D57-81B5-3C53D7BF8095}] [Info]    LAVSplitter: Run(): End
27-11-2012 21:21:13.845 [ cb4] [{80E9C286-2E1D-4D57-81B5-3C53D7BF8095}] [Info]    LAVSplitter: Pause(): Start
27-11-2012 21:21:13.847 [13a8] [{80E9C286-2E1D-4D57-81B5-3C53D7BF8095}] [Info]    LAVSplitter: ThreadProc(): CMD_PAUSE
27-11-2012 21:21:13.847 [ cb4] [{80E9C286-2E1D-4D57-81B5-3C53D7BF8095}] [Info]    LAVSplitter: Pause(): End
27-11-2012 21:21:13.848 [ cb4] [{80E9C286-2E1D-4D57-81B5-3C53D7BF8095}] [Info]    LAVSplitter: Run(): Start
27-11-2012 21:21:13.849 [13a8] [{80E9C286-2E1D-4D57-81B5-3C53D7BF8095}] [Info]    LAVSplitter: ThreadProc(): CMD_PLAY
27-11-2012 21:21:13.849 [ cb4] [{80E9C286-2E1D-4D57-81B5-3C53D7BF8095}] [Info]    LAVSplitter: Run(): End
27-11-2012 21:21:13.850 [ cb4] [{80E9C286-2E1D-4D57-81B5-3C53D7BF8095}] [Info]    LAVSplitter: Pause(): Start
27-11-2012 21:21:13.852 [13a8] [{80E9C286-2E1D-4D57-81B5-3C53D7BF8095}] [Info]    LAVSplitter: ThreadProc(): CMD_PAUSE
27-11-2012 21:21:13.852 [ cb4] [{80E9C286-2E1D-4D57-81B5-3C53D7BF8095}] [Info]    LAVSplitter: Pause(): End

The most interesting are times between CMD_PLAY and CMD_PAUSE:

1. 27-11-2012 21:21:13.773 - 27-11-2012 21:21:13.776 - 3 ms
2. 27-11-2012 21:21:13.828 - 27-11-2012 21:21:13.847 - 19 ms
3. 27-11-2012 21:21:13.849 - 27-11-2012 21:21:13.852 - 3 ms

The commands for CMD_PLAY and CMD_PAUSE come from graph. When source filter receive CMD_PAUSE it doesn't demux stream and doesn't send any data to connected filters! It starts demuxing when receive CMD_PLAY or CMD_SEEK. But as you can see from times, source filter doesn't have time to demux some packets.

 

[georgius]

@infinite.loop can you test attached source filter version, if problem with MPAR still persists?

 

[infinite.loop]

will do!
Does it require (re)registering?

 

[georgius]

will do!
Does it require (re)registering?

No registering is needed, just replace current files.

 

[infinite.loop]

No registering is needed, just replace current files.

Works perfectly! Played more than 50 files, all worked!

 

[tourettes]

No registering is needed, just replace current files.

Works perfectly! Played more than 50 files, all worked!

@georgius, what was the fix? Out of curiosity - I want to be sure that source filter doesn't have some workaround for some MPAR issue

 

[georgius]

Just overriden GetState() method and returning VFW_S_CANT_CUE when in paused state (like written on msdn page):

STDMETHODIMP CLAVSplitter::GetState(DWORD dwMSecs, __out FILTER_STATE *State)
{
  CheckPointer (State, E_POINTER);
 
  HRESULT result = __super::GetState(dwMSecs, State);
  result = (SUCCEEDED(result) && (m_State == State_Paused)) ? VFW_S_CANT_CUE : result;
 
  return result;
}