user-1479
05-05-2017, 05:47 AM
I've experienced a strange problem in v3.00. It appeared to be caused by a combination of 1) episodes not appearing in cache AND 2) the use of --pid-recursive. I've resolved my own problem and I'm not sure anything is to be done but thought I'd describe the issue here in case it's deemed a bug or in case anyone else runs into similar.
Firstly I only have 2 out of 4 available episodes of "Rhod Gilbert's Work Experience" appearing in my listings cache. All four are available on iplayer website and all four are able to be downloaded via direct URL/PID using older v2.97. (Note I've clean installed v3.00 under a separate user account for testing so that my preferences/cache between versions are kept separated.)
http://www.bbc.co.uk/iplayer/episodes/b00zf3m1
I'm not normally bothered about the cache as I always just use URLS or PIDS after browsing the iplayer website. But in v3.00 I could only download the two episodes that already appeared in the listings cache. Attempts to download the other two episodes (not in the cache) via URL/PID method threw up a "Failed to fetch episode PID" error. I did try adding the --future option per 'known problems' but no difference.
My two cached entries:
The two missing episodes are :
I don't know why the cache problem but eventually I tracked the downloading problem down to my having --pid-recursive in my preferences file.
I know --pid-recursive doesn't make sense when you want to manually download a non-series PID but I've always had it in my preferences file as previously (at least in v2.97) it always appeared to be ignored for non-series PIDs and was safe to leave there for some lazy occasions when I did want to use a series-based PID. (Mainly because I also used --pid-recursive-noclips as well and together they were quite long to have to remember).
Once removed from my preferences file, the missing non-cached 2 episodes downloaded successfully via URL/PID method in v3.00. Of course they still don't appear in my listings cache for whatever reason.
Purely for testing purposes, if I manually added --pid-recursive back to the CLI command for downloading the correctly cached pids, then the download is successful. But when the same is used for the 2 non-cached pids, the download isn't attempted.
Failure scenario: NON-CACHED episode AND --pid-recursive option used
(Doesn't make sense to do this but it might occur if --pid-recursive is in your preferences file)
The URL in the error message at the bottom gives a good clue I think. I guess this behaviour must have had to change due to the re-implementation and the way web-scraping works?
The solution is obviously just not to use it in my saved preferences.
If the maintainer wants to see more I will gather some logs etc. I'm not sure it's worth worrying about though - just to be aware of.
Firstly I only have 2 out of 4 available episodes of "Rhod Gilbert's Work Experience" appearing in my listings cache. All four are available on iplayer website and all four are able to be downloaded via direct URL/PID using older v2.97. (Note I've clean installed v3.00 under a separate user account for testing so that my preferences/cache between versions are kept separated.)
http://www.bbc.co.uk/iplayer/episodes/b00zf3m1
I'm not normally bothered about the cache as I always just use URLS or PIDS after browsing the iplayer website. But in v3.00 I could only download the two episodes that already appeared in the listings cache. Attempts to download the other two episodes (not in the cache) via URL/PID method threw up a "Failed to fetch episode PID" error. I did try adding the --future option per 'known problems' but no difference.
My two cached entries:
Code:
gi3@tiger:~$ ./get_iplayer-3.00 "work experience"
get_iplayer v3.00, Copyright (C) 2008-2010 Phil Lewis
This program comes with ABSOLUTELY NO WARRANTY; for details use --warranty.
This is free software, and you are welcome to redistribute it under certain
conditions; use --conditions for details.
NOTE: A UK TV licence is required to legally access BBC iPlayer TV content
Matches:
3875: Rhod Gilbert's Work Experience: Series 6 - Journalist, BBC Two, b070wftv
3876: Rhod Gilbert's Work Experience: Series 7 - Florist, BBC Two, b08jqg5h
INFO: 2 Matching Programmes
gi3@tiger:~$The two missing episodes are :
Code:
Series 7 Episode 1 - Estate Agent - b08htmdj
Series 7 Episode 2 - Builder - b08hzzbhI don't know why the cache problem but eventually I tracked the downloading problem down to my having --pid-recursive in my preferences file.
I know --pid-recursive doesn't make sense when you want to manually download a non-series PID but I've always had it in my preferences file as previously (at least in v2.97) it always appeared to be ignored for non-series PIDs and was safe to leave there for some lazy occasions when I did want to use a series-based PID. (Mainly because I also used --pid-recursive-noclips as well and together they were quite long to have to remember).
Once removed from my preferences file, the missing non-cached 2 episodes downloaded successfully via URL/PID method in v3.00. Of course they still don't appear in my listings cache for whatever reason.
Purely for testing purposes, if I manually added --pid-recursive back to the CLI command for downloading the correctly cached pids, then the download is successful. But when the same is used for the 2 non-cached pids, the download isn't attempted.
Failure scenario: NON-CACHED episode AND --pid-recursive option used
(Doesn't make sense to do this but it might occur if --pid-recursive is in your preferences file)
Code:
gi3@tiger:~$ ./get_iplayer-3.00 --pid=b08htmdj --tvmode=hvf --stop=20 --force --overwrite --pid-recursive
get_iplayer v3.00, Copyright (C) 2008-2010 Phil Lewis
This program comes with ABSOLUTELY NO WARRANTY; for details use --warranty.
This is free software, and you are welcome to redistribute it under certain
conditions; use --conditions for details.
NOTE: A UK TV licence is required to legally access BBC iPlayer TV content
WARNING: Failed to fetch episode PIDs from http://www.bbc.co.uk/programmes/b08htmdj/episodes/player?page=1
gi3@tiger:~$The URL in the error message at the bottom gives a good clue I think. I guess this behaviour must have had to change due to the re-implementation and the way web-scraping works?
The solution is obviously just not to use it in my saved preferences.
If the maintainer wants to see more I will gather some logs etc. I'm not sure it's worth worrying about though - just to be aware of.