Dash mode does not seem to respect excludesupplier option

[Vangelis forthnet]

On Sun Jan 10 07:11:01 GMT 2016, Timothy wrote:

> Log sample below:
> (snip)
> INFO: Found mode dashhigh1: (gip_dash_iplayer_320) dash aac 320kbps stream 
> (CDN: af_limelight_uk_dash/2)
> INFO: Found mode dashhigh2: (gip_dash_iplayer_320) dash aac 320kbps stream 
> (CDN: af_akamai_uk_dash/1)

 Many thanks for your verbose log, Timothy :-)
The above pretty much confirms what I stated in
http://lists.infradead.org/pipermail/get_iplayer/2016-January/008554.html

>> If you just use dashhigh, you let GiP itself decide;
>> it does this by checking the highest priority value,
>> 2 >1 => so a safe bet would be:
>> dashhigh1 = Limelight
>> dashhigh2 = Akamai

> it appears that the --exclude-supplier option
> does not seem to work for DASH streams.

It appears you are right; I conducted some tests
from my original IP, first issued:

perl get_iplayer-295latest.pl -v -t --pid 
b00c84nd --modes=flash --exclude-supplier=akamai

and GiP only attempted mode flashlow1:

INFO: flashlow1 modes will be tried for version original
where:
INFO: Found mode flashlow1: (stream-nonuk-audio_streaming_aac_vlow) rtmp aac 
48kbps stream (CDN: limelight/20)

Then issued:

perl get_iplayer-295latest.pl -v -t --pid 
b00c84nd --modes=hls --exclude-supplier=akamai

and no modes were found:
INFO: No specified modes (hlshd,hlssd,hlsvhigh,hlshigh,hlsstd,hlsmed,hlslow) 
available for this programme with version 'original'
INFO: Try using --modes=flashlow,dashmed,dashlow

simply because the only one available hls radiomode
is being served from Ak:

INFO: Found mode hlslow1: (gip_hls_iplayer_45) hls aac 45kbps stream (CDN: 
akamai_hls_open/10)

So, "--exclude-supplier=akamai" is being honoured in 2.95dev for RTMP/HLS.

Whereas, issuing:

perl get_iplayer-295latest.pl -v -t --pid 
b00c84nd --modes=dash --exclude-supplier=akamai

produces:
INFO: dashmed1,dashmed2,dashlow1,dashlow2 modes will be tried for version 
original
where the "2" modes belong to akamai:
INFO: Found mode dashmed2: (gip_dash_iplayer_96) dash aac 96kbps stream 
(CDN: af_akamai_nonuk_dash/1)
INFO: Found mode dashlow2: (gip_dash_iplayer_48) dash aac 48kbps stream 
(CDN: af_akamai_nonuk_dash/1)

I can't say whether this behaviour is by design or a bug,
but to debug this further I examined the "excludesupplier"
line within the 2.95dev main script's code:

excludesupplier => [ 1, "excludesupplier|exclude-supplier=s", 'Recording', 
'--exclude-supplier <suppliers>', "Comma-delimited list of media stream 
suppliers to skip.  Possible values: 
level3,akamai,limelight,bidi,mf_akamai,mf_limelight,mf_bidi"],

Since "mf_akamai" appears as a valid entry but
the dash akamai CDN is being reported by GiP 2.95
as  "af_akamai_[non]uk_dash", I did some extrapolation
and issued:

perl get_iplayer-295latest.pl -v -t --pid 
b00c84nd --modes=dash --exclude-supplier=af_akamai

This appears to have worked as intended:
INFO: dashmed1,dashlow1 modes will be tried for version original

INFO: Found mode dashmed1: (gip_dash_iplayer_96) dash aac 96kbps stream 
(CDN: af_limelight_nonuk_dash/2)
INFO: Found mode dashlow1: (gip_dash_iplayer_48) dash aac 48kbps stream 
(CDN: af_limelight_nonuk_dash/2)

and, likewise:

perl get_iplayer-295latest.pl -v -t --pid 
b00c84nd --modes=dash --exclude-supplier=af_limelight

yields:
INFO: dashmed1,dashlow1 modes will be tried for version original
but now:
INFO: Found mode dashmed1: (gip_dash_iplayer_96) dash aac 96kbps stream 
(CDN: af_akamai_nonuk_dash/1)
INFO: Found mode dashlow1: (gip_dash_iplayer_48) dash aac 48kbps stream 
(CDN: af_akamai_nonuk_dash/1)

To sum up:

Fetch (audio) DASH from Akamai: "--exclude-supplier=af_limelight" (or choose 
dash...2 mode of the two)
Fetch (audio) DASH from Limelight: "--exclude-supplier=af_akamai" (or choose 
dash...1 mode of the two, or let GiP choose it by default)

(As stated multiple times, I can't write perl code myself,
but is it not possible with some RegEx to amend
current behaviour so that value "akamai" for
option "--exclude-supplier" comprises "mf_akamai",
"af_akamai" and other possible "akamai" variants?)

Regards,
Vangelis.