Greetings

My specs:

OS: WinVista SP2 x86
JRE 7u65
FRD 0.9u4
bbc.frp 1.1.14
plugin settings:
480p
1935 (default)
Limelight
"Enable Tor" unticked
UK http proxy configured in FRD
"Download subtitles" ticked

Sample TV file:

T in The Park 2014: Arctic Monkeys and Example
(NB: Expires on 23:30 BST 20 July 2014 !)

It looks as if the bug I had originally reported here, which afflicted v1.1.11 of
the bbc plugin but was fixed by tong2shot in v1.1.12, has reared its ugly head again in v1.1.14
Sample link produces .flv video file named:

T in the Park - 2014 - Arctic Monkeys & Example

and .srt subs file named:

T in the Park - 2014 - Arctic Monkeys &_amp; Example

(I have included an underscore between "&" and "amp;", else the forum software 
wouldn't show it correctly...)

The same thing happened with another "T in the Park 2014" TV show
I downloaded earlier in the day,
T in the Park - 2014 - Ed Sheeran & Imagine Dragons
but is due to expire imminently, for which I have attached a "Tile View" snapshot of the downloads folder,
to better illustrate the issue (attachment TileView.jpg).
Would you be so kind as to kill this bug once and for all, because it is kind of annoying?

And a personal note on v1.1.14 of the bbc plugin:
I did NOT like it that the downloading of the subtitles file was made a SILENT one;
At first, immediately after updating from v1.1.13 (of which I made prior a backup),
I initially thought that a) subs downloading was broken or b) the video file did not come
with a corresponding subs file - it can happen sometimes when the beeb omits to provide one,
only to find the subtitles file inside the downloads folder when I went there to retrieve the video file...
On another scenario, for some TV shows I first download the 480p video file in order to view it
on my (old-ish) laptop, and then I download the 720p HD version for viewing it on a friend's
50" LED hi-tech TV - plugin 1.1.14 re-downloads the subs for a second time, which is not really
needed, since it is the same for all quality variants of the TV programme... In v1.1.13, user can
decline the re-download (if subs file already present within the DLs folder...).
I have, for now, reverted to bbc.frp 1.1.13, which is still functional and more to my liking...
And while at it, I noticed another small detail:
Since not physically in the UK, I use HTTP proxies with the bbc plugin; the rtmp downloading
(Limelight/Level 3 CDNs) is done via my original connection with very high speeds (~ 1.8 MBps),
but the subs file downloading is realised via the proxy connection - this is not really needed,
since the subs URL (for Sample TV file mentioned in the start of this post this is:
Raw subs URL)
is not geo-blocked; I have in the past come across some half-dead UK proxies that had
sufficient bandwidth to initiate the rtmp download but would time-out in the subs fetching...

I hope the devs do not mind my detailed remarks, this is done
with the intention to make FRD an even more superb tool than it already is!

Many regards from Greece (where living is hard currently, but the weather is still an ally )

TVjunkie Wrote:
-------------------------------------------------------
> Would you be so kind as to kill this bug once and
> for all, because it is kind of annoying?

Ha! forgot about that. Fixed in plugin v1.1.15.


> And a personal note on v1.1.14 of the bbc plugin:
> I did NOT like it that the downloading of the
> subtitles file was made a SILENT one;

Prior to v1.1.14, BBC plugin used an ugly hack to queue subtitle. We had to add 'fname' parameter to original subtitle URL to match video/audio's file name.


> On another scenario, for some TV shows I first
> download the 480p video file in order to view it
> on my (old-ish) laptop, and then I download the
> 720p HD version for viewing it on a friend's
> 50" LED hi-tech TV - plugin 1.1.14 re-downloads
> the subs for a second time, which is not really
> needed, since it is the same for all quality
> variants of the TV programme... In v1.1.13, user
> can
> decline the re-download (if subs file already
> present within the DLs folder...).

I'll say that's a corner case. You can easily delete the subtitle.

The advantage of silent subtitle download is that you don't have to wait for the queue, it's downloaded instantly. Imagine that you have 15 URLs in the queue in active state (non-paused) and BBC URL at the top. Prior to v1.1.14, when the BBC URL is downloaded, the subtitle is queued at the bottom. You either have to move the subtitle to the top, or wait until all items are downloaded. Which in my opinion is annoying.


> And while at it, I noticed another small detail:
> Since not physically in the UK, I use HTTP proxies
> with the bbc plugin; the rtmp downloading
> (Limelight/Level 3 CDNs) is done via my original
> connection with very high speeds (~ 1.8 MBps),
> but the subs file downloading is realised via the
> proxy connection - this is not really needed,
> since the subs URL (for Sample TV file mentioned
> in the start of this post this is:
> Raw subs URL)
> is not geo-blocked; I have in the past come across
> some half-dead UK proxies that had
> sufficient bandwidth to initiate the rtmp download
> but would time-out in the subs fetching...

Okay plugin v1.1.15 uses direct connection to download subtitle.


> I hope the devs do not mind my detailed remarks,
> this is done
> with the intention to make FRD an even more superb
> tool than it already is!
>
> Many regards from Greece (where living is hard
> currently, but the weather is still an ally )

Thanks for the detailed report.

tong2shot wrote:
-------------------------------------------------------
> Ha! forgot about that. Fixed in plugin v1.1.15.

Yes, much obliged

> Prior to v1.1.14, BBC plugin used an ugly hack to queue subtitle.
> We had to add 'fname' parameter to original subtitle URL
> to match video/audio's file name.

Thanks for the technical explanation

> The advantage of silent subtitle download is that you don't have to wait for the queue,
> it's downloaded instantly.
> Imagine that you have 15 URLs in the queue in active state (non-paused) and BBC URL at the top.
> Prior to v1.1.14, when the BBC URL is downloaded, the subtitle is queued at the bottom.
> You either have to move the subtitle to the top, or wait until all items are downloaded.
> Which in my opinion is annoying.

While I totally understand what you just described, the above scenario was not one
I would encounter on my usage of FRD.
Whenever I download iplayer files, I make sure to have no other pending (active/paused/queued) downloads;
and in practice, I do not download at the same time more than four (4) bbc files.
My available download bandwidth is divided by the number of parallel bbc downloads (I think this is controlled
by the CDN server), if I download more than 4 it takes quite a while for all of them to complete;
and there is an elevated chance of connection dropouts. If one or two files lose connection,
then FRD has to start downloading them from scratch, so I don't want to risk that...
And by setting
Options -> Preferences -> Connections -> Max concurrent downloads at a time -> 8 ,
once the 4 iplayer URLs are loaded, all 4 subs files are, in essence, downloaded instantly.
But I respect your choice of plugin functionality

> Okay, plugin v1.1.15 uses direct connection to download subtitle.

Many thanks for this improvement, too!