Re: Recursive download with episode name filter?

[iz]

> On 24 Apr 2024, at 13:11, Nick Payne  wrote:
> 
> Interestingly, if I run
> 
> get_iplayer "Snooker*
> 
> all that finds are the various Day 1, Day 2 etc videos. None of the A vs B 
> match videos are found.

The docs explicitly state that web-only items are not searchable.

As to the original question: You can't do it directly, but you should be able 
to strain the output from --pid-recursive-list into a list of PID values for 
the individual matches, then feed that to GiP.
___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Seeking Help with Downloading AD Films

[iz]

> On 9 Mar 2024, at 12:21, Darran Ross  wrote:
> 
> What I'd like to know is, would it be possible to ask GiP to search all 
> available films and then download only those with audio description?

The short answer is no. GiP cannot search by category or version, nor can it 
search the entire iPlayer catalog. If, for example, you came up with a way to 
scrape the Films category on the iPlayer site you could probably assemble a 
list of PIDs to feed to GiP. You could also simply work your through the Films 
category and copy/paste URLs of the films you want to the command line or to a 
batch script of some sort. Tedious, but might be doable for the roughly 250 
films available. Use of --versions=audiodescribed wold prevent the download of 
any films without audio description, at the expense of some error messages.
___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Searching failing

[iz]

> On 9 Mar 2024, at 14:46, Charles Johnson  wrote:
> 
> On 06/03/2024 20:56, iz wrote:
>> "firstbcastdate" is not a search field. Use --fields=available
> Thank you. So I therefore must take it that all tokens that match the pattern 
> ^\w+: in a listing (such as firstbcastyear:, firstbcastrel:, etc.) are NOT 
> the names of fields? If so, that's a PITA. How do I know which fields ARE 
> available for use?
> 

Only a few fields in --info output are derived from the cache data used for 
searches. You would be waiting until (relative) doomsday to index all metadata 
for all available programmes. The only really useful search fields are the ones 
shown in the doc examples. The use of "available" is a bit of a fluke that only 
works because it is stored as a formatted date/time. As was mentioned by Chris 
Walker, you also have --available-since and --available-before to bracket 
searches by availability time. Otherwise, crack open one of your cache files - 
fields names at at the top. They are the same field names shown in docs for use 
with --listformat.


___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: releaseyear metadata get_iplayer extracts for Films

[iz]

> On 6 Mar 2024, at 18:49, David  wrote:
> 
> Unfortunately neither of my examples is currently listed in the iPlayer 
> schedules on so I am unable to confirm via the website if the Beach does not 
> the original release year (so its extracting ), but all my 
> spot checks of current films on the iPlayer website have the orginal release 
> date shown, so it would be surprising if the Beach did not have it, which 
> makes me wonder if there is some other reason why get_iplayer cannot return 
> it?

If the film is no longer available on iPlayer, there is no release year listed, 
so nothing for get_iplayer to grab.


___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Searching failing

[iz]

> On 23 Feb 2024, at 11:00, Charles Johnson  wrote:
> 
> I don't really do much searching so I might be doing something wrong, but the 
> following search fails to produce any results for me:
> 
> get_iplayer --type=radio --fields=firstbcastdate "2024-02-22"
> 
> I know for a fact that certain programmes are new every day. Can anyone tell 
> me what's (not) happening here?

"firstbcastdate" is not a search field. Use --fields=available
___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: m001vkll puzzle

[iz]

> On 20 Jan 2024, at 11:16, Jim web  wrote:
>
> This *also* was ended part-way though the sitting. So I checked the webpage
> and that states the duration is over 3 hours. Yet what I got was 1h 33m
> long.

Use --versions=editorial

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: PVR process stops working

[iz]

> On 13 Dec 2023, at 11:16, MrBrunes  wrote:
>
> I've tried removing "--quiet 2" and then adding --verbose and

Remove --quiet but not "2"


___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: PVR process stops working

[iz]

On 5 Dec 2023, at 16:41,   wrote:
> 
> On Windows I can confirm it does not always clear the lock file when 
> starting. Very occasionally on a freshly booted machine pvr will fail to run 
> due to an old lock file. Delete and try again and all is good. It doesn't 
> happen ofyen (every 3 - 4 montgs or so) but it does happen. 

A corrupt/invalid/unreadable lock file could also prevent the PVR scheduler 
from starting, with different error messages. If that isn't the case and it's 
actually reporting that a non-existent process is running, I guess you can add 
that to the list of Perl+Windows peculiarities.


___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: PVR process stops working

[iz]

On 5 Dec 2023, at 13:13, Don Grunbaum  wrote:
> 
> The pvr creates a small file called pvrlock in the get_iplayer folder. Try 
> deleting that.

Not such a good idea since in this case since the previous PVR invocation is 
still running, or at least its Perl interpreter is still alive. Even if GiP 
dies and leaves the lock file behind, the next PVR invocation will clean it up, 
assuming the Perl process that created it is really dead.


___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: PVR process stops working

[iz]

On 4 Dec 2023, at 19:02, MrBrunes  wrote:
> 
> The PID never shows up in Task Manager or Process Explorer so it's reboot 
> time.

At most, you should only need to kill the Perl interpreter (perl.exe) process.

> 
> How can I diagnose this?
> Failing that, is there any way to make the PVR process more resilient,
> or failing that is there an easier method to detect that it's stopped
> downloading?

Run PVR scheduler from a command prompt instead of from start menu or desktop. 
The output should remain on-screen if it dies, or you could redirect it to a 
file.

> 
> The docs mention the possibility of using the Windows scheduler for
> the PVR at 
> https://github.com/get-iplayer/get_iplayer/wiki/documentation/09a72bf76c131c8932bbf0aef1eeb95ec85049b9#scheduling-the-pvr
> but the external link is invalid.

You are linking to a very obsolete version of the docs. The current version has 
what you're after.


___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: '5 Live Science' not being found to download

[iz]

> On 18 Apr 2022, at 15:17, MacFH - C E Macfarlane - News  
> wrote:
> 
>   --type radio --pid p02pc9ny --pid-recursive
> ... it finds all the previous versions before April this year that I've 
> already downloaded, listened to, and then deleted, and I don't want to waste 
> my bandwith downloading 550 or so programmes that I've already heard.

You can use --pid p02pc9ny --pid-recursive --hide --mark-downloaded to add to 
download history all previous podcast episodes not already downloaded. Use 
--pid p02pc9ny --pid-recursive --hide on subsequent runs to pick up new 
episodes.


___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Experimental HD and audio only downloads

[iz]

> On 7 Apr 2022, at 22:00, fred.d  wrote:
> 
> I've found that a lot of content seems to be available in the new Full HD 
> format. However every so often I come across one that downloads only the 
> audio.

It’s a get_iplayer bug that crops up when no 1080p stream is available. Work 
around it with —exclude-format=hls

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Audio portion of dash downloads slow

[iz]

> On 14 Mar 2022, at 03:02, Nick Payne  wrote:
> 
> No, here's an example of the quite different speeds for the audio and video 
> portions of a dash download - the 158Mb of audio took 31 

This has always been the case, though it is more visible now with 1080p since 
DASH is its default format, unlike 720p and others. There is no reason to 
expect that audio and video would download at the same speed. Video may be 
throttled as well, and there can be cases where the video stream is slower than 
the audio. Those media streams are intended for real-time playback, and even 
the low-ish speeds you get are adequate for that purpose. Audio is only a few 
percent of the total payload, so it only needs a few percent of the total 
throughput to keep up with the video. In your example, the audio actually 
downloaded at 5x real-time, which was about twice that of the video. Anyway, 
that has nothing to do with GiP.

> A second, and quite unrelated problem is that the estimated file sizes for 
> fhd 1080p downloads are always too high by a factor or three or

Read the release notes


___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Permission denied at /usr/local/get_iplayer line 2153

[iz]

> Sent: Wednesday, December 22, 2021 at 10:05 PM
> My options file has
> ffmpeg /usr/local/bin

You need the full path to ffmpeg, not just the directory.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Red Rock TV programme missing from schedule

[iz]

On Wed, 10 Jul 2019 at 10:40, RS  wrote:
> seem to have been made available initially in a format version 3.20 of
> get_iplayer cannot handle (but youtube-dl can), and then have gradually
> been converted.

Not the case. That programme was always available to get_iplayer. You
just used the wrong PID before.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Exclude/Include patterns

[iz]

Going by your initial post, you only want Radio 3, 4 and 4 extra to be
cached.  In that case, all you need is --type=radio --refresh
--refresh-include="BBC Radio 4,BBC Radio 3". Run with --cache-rebuild
instead of --refresh the first time to reset your radio cache with
only those stations. You don't need --refresh-exclude in any form.

On 8 August 2018 at 20:53, Az  wrote:
> On Fri, July 13, 2018 1:24 pm, RS wrote:
>
>> get_iplayer --refresh-exclude-groups-radio national,regional,local
>> --refresh-include "BBC Radio 4,BBC Radio 3" -f --type radio
>>
>>
>> adds 2211 programmes to a newly created radio.cache
>>
>> I'll leave you to check whether they are what you want.
>>
>>
>> Best wishes
>> Richard
>
> Thanks
>
> Sorry for the delay in answering.
>
> What I've settled on for now is --refresh-exclude-groups-radio regional,local
>
> That way I can still see some other national which may be interesting.
> I'll go through the list at some time and trim it by an include like
> yours, or exclude those I don't want. Whichever works out easier.
>
>
> ___
> get_iplayer mailing list
> get_iplayer@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/get_iplayer

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: no more hslv format ?

[iz]

On 2 May 2018 at 16:49, Jim web  wrote:
>
> As things are, I could then have gip+ffmpeg generate the 50 fps mp4 files
> (i.e. in the current form) onto hd. This saves some hd wear but means I now
> have those (big) files on hd before I then run a 50 -> 25 fps process to
> create smaller ones (which will be akin in size to what I got from the
> 25fps fetching). The result using this approach means I've still done the
> fetching as quickly as possible, but have about three times as much data
> written to hd at some point.

You may be able to limit the whole process to only two file writes
with a little scripting and XML parsing. Use --raw with GiP  to save
the .ts file directly to drive or to drive via ram disk. The ram disk
probably wouldn't be of much use since I doubt your downloads are
limited by disk write speed. Also use --metadata to save programme
metadata in an XML file and --thumbnail to save the cover art in a JPG
file. Write a script to re-encode the file to 25fps MP4 and at the
same time add metadata tags with ffmpeg, using the XML file and JPG
file as input to construction of the ffmpeg command string. You'll
need ffmpeg 4.0 or higher to add cover art to MP4.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: no more hslv format ?

[iz]

On 30 April 2018 at 15:22, Jim web  wrote:
> conversion as things stand? IIRC it has to recontain the content and tweak
> the aac format in some way. So I'd need to be able to replilicate what is

GiP uses ffmpeg's aac_adtstoasc bitstream filter to remove ADTS
framing when copying the audio stream from .ts files, but more recent
versions of ffmpeg do that automatically for MP4 output format. If you
re-encode the audio as well as the video (probably not necessary),
that won't matter.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: no more hslv format ?

[iz]

On 30 April 2018 at 13:56, Jim web  wrote:
>
> 1) Use gip to get a 50fps file saved to ram.

You'll want to use the --raw flag with GiP to avoid remuxing to MP4
and tagging, both of which create a file copy, which would halve the
max size of programmes you could download to ram disk.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Cannot play downloads from get_iplayer!

[iz]

On 18 April 2018 at 10:52, RS  wrote:
> Are you counting HVF as HLS streams?

Of course. For anyone confused, you have to distinguish "hls" the
prefix from HLS the format.  The "hvf" prefix also denotes HLS format
streams.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Cannot play downloads from get_iplayer!

[iz]

On 18 April 2018 at 08:53, Alan Milewczyk  wrote:
> HLS streams are being phased out.

No they’re not. Only the 1280x720 and 832x468 25fps HLS streams are gone

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Cannot play downloads from get_iplayer!

[iz]

On 18 April 2018 at 07:28, Paul Thornett  wrote:
> OK, but, previously, the tvmode=best has produced an .mp4 file that my
> PVR is quite happy with. This is no longer the case. Does that not
> suggest something has changed?

Only that you're now being denied access to the HLS streams GiP uses as default.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Cannot play downloads from get_iplayer!

[iz]

On Wednesday, 18 April 2018, Paul Thornett  wrote:
>
>
> So the question is: what is QuickStream Fix doing that Handbrake can't?


It is doing what I told you to do, remux your .mp4 to .ts. You can do
it with ffmpeg, and no doubt with other tools. Transcoding with
Handbrake will not help if you still produce a file incompatible with
your hardware. Since you don’t have access to HLS streams, you have to
fix up the video from DASH streams to be compatible with your player.
Nothing has changed with the stream formats. You’re just not getting
all the streams you did before. I’m guessing you’re not in the UK.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Cannot play downloads from get_iplayer!

[iz]

On 17 April 2018 at 16:24, Paul Thornett  wrote:
>   --tvmode = best (results in dvfxsd1)

It seems hvf streams are not available to you for some reason. They
would spare you this headache. Otherwise, just re-mux your .mp4 to .ts
(mpeg-ts). You can then re-mux back to .mp4 if necessary. Worked for
me with QuickTime and Apple TV, which have the same limitation.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Unable to play with VLC

[iz]

This is a known limitation of VLC, and it is unrelated to colour
subtitles. Any external subtitles file can cause the problem. If you
are wedded to .ts files for some reason, try another media player.

On 3 April 2018 at 04:15, Paul Thornett  wrote:
> Problem solved! VLC can't cope with subtitle files containing colour
> directives. I've only recently started requesting subtitles (in fact,
> when v3.13 came out).
> Regards,
>
> Paul Thornett
>
>
> On 3 April 2018 at 11:44, Paul Thornett  wrote:
>> Running on Windows 7, I use these options when using get_iplayer:
>>tvmode=hlshd
>>raw=1
>>subtitles=1
>>
>> With GIP 3.13 I am unable to use VLC to play any downloaded .ts file!
>> They all load and play fine using VideoRedo TVSuite 5.3.83.763. But
>> attempting to play them with VLC results in the progress bar at the
>> bottom of the screen flashing yellow while sweeping back and forth
>> across the entire progress bar, with CPU usage ranging from 1% to 25%.
>>
>> Regards,
>>
>> Paul Thornett
>
> ___
> get_iplayer mailing list
> get_iplayer@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/get_iplayer

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: v3.13 released

[iz]

On 28 March 2018 at 11:33, RS  wrote:
> That suggests that with the new algorithm it is going to be necessary to
> refresh more than once a week to maintain a complete cache.

There is no "new algorithm", and you don't have to refresh more often
than you did before. If you can't live with a hole in your cache, just
rebuild it.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: v3.13 released

[iz]

Once get_iplayer updates the cache in any given week, it doesn't go
back to the previous week. Ordinarily that would be unnecessary, but
you can force it with the use of --refresh-limit or --cache-rebuild,
as has already been suggested. It's likely that people did their first
update this week with the old broken get_iplayer, and thus subsequent
updates with the new get_iplayer didn't go back to last week.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Format of options file

[iz]

> > binmode does still work AFAIK, but a more modern and flexible method
> > is to use the crlf I/O layer, which is documented here:
> >   https://perldoc.perl.org/PerlIO.html
> >
> > Note however that an awful lot of perl code just doesn't bother.
> 
> Windows stacks the `:crlf' layer by default.  I *think* Richard's trying
> to avoid that because he wants his get_iplayer to use POSIX text files
> on Linux, as normal, and Windows.

PerlIO enables you to go either way, and no code changes are necessary. The 
simplest solution is to run the equivalent of 'PERLIO=crlf get_iplayer [...]' 
on Linux, perhaps via an alias in your shell. Probably best not to set 
PERLIO=crlf permanently if you run other Perl programs. You may not like having 
files with CRLF line endings, but they will still work on both platforms if you 
screw up editing and get mixed line endings. If you really can't abide CRLF, 
use PERLIO=perlio on Windows instead to produce LF line endings. Probably 
simplest to set it locally in the get_iplayer batch file. You just have to be 
careful not to inject CRLF line endings if you edit any files directly, though 
I would expect any decent text editor on both platforms can avoid that.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Downloading Podcast?

[iz]

> Why cannot GiP get a podcast for which I have the pid and can play on my pc?

Your clip is only available in Flash format, which GiP doesn't support. This is 
unrelated to podcasts. Your clip was a promo item, not a podcast episode. GiP 
can download the actual podcast episodes.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Modes and best quality

[iz]

> Sent: Wednesday, December 13, 2017 at 11:15 PM
>
> The cmp_modes() function scores a mode and compares two modes

cmp_modes() is unrelated to which modes are available for download. If you want 
to see where --tvmode=best is expanded, look at modelist(). If you want to see 
where unavailable streams are filtered out of that expanded list, look at 
download_retry_loop(). If you want to know why streams were unavailable to 
Nick, see my last post.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Modes and best quality

[iz]

> Sent: Wednesday, December 13, 2017 at 10:40 AM
> From: "Nick Payne" 
>
> This behaviour does not accord with the documentation at
> https://github.com/get-iplayer/get_iplayer/wiki/modes

It does. Look at all those "403 No Protocol" errors. If you can't download the 
stream information, GiP won't be able to access them. You got the best 25fps 
stream available in both cases. As to why you get those errors, I haven't a 
clue. The URLs clearly have protocols included, and you would see a different 
error if they didn't, so the errors must refer to problems on the BBC side or 
somewhere in between. Even in your example, some errors aren't repeated, so 
might be difficult to diagnose.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Generate .cue from timestamp for long program

[iz]

> Sent: Tuesday, August 08, 2017 at 10:40 AM
> From: iz
>
> You probably want http://www.bbc.co.uk/programmes/b08y04ks/playlist.json, 
> which contains start times in seconds (used for markers in web player).

Upon further investigation, it looks like 
http://www.bbc.co.uk/programmes/b08y04kj/segments.json would be more useful in 
your example. Use the above file to get the vpid value (b08y04kj) used to find 
the segments file. It also looks like the vpid could be scraped from the HTML 
of the programme page (http://www.bbc.co.uk/programmes/b08y04ks)

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Generate .cue from timestamp for long program

[iz]

> Sent: Tuesday, August 08, 2017 at 9:42 AM
> From: "Live Musicfs" 
> 
> Here are example of lyric information which I extract from Foobar2000.  
> However, the time information is NOT the real time playback time from the web 
> audio player:
> 
> http://www.bbc.co.uk/programmes/b08y04ks

You probably want http://www.bbc.co.uk/programmes/b08y04ks/playlist.json, which 
contains start times in seconds (used for markers in web player).

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: GIP 2.99 on openSUSE 42.2

[iz]

> Sent: Tuesday, March 21, 2017 at 1:35 PM
> From: RS 
>
> For HLS you need v2.5 or above so v3.2 ought to be alright.  However I have 
> a feeling there was a problem with v3.2 and you need to upgrade to v3.2.2. 

You don't. I found the solution for particular issue covered here:

https://squarepenguin.co.uk/forums/thread-1144.html

and it no longer affects GiP, nor would it affect your example. And as you know 
from other posts, ffmpeg 3.2 will work OK.


___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: GIP 2.99 on openSUSE 42.2

[iz]

> Sent: Tuesday, March 21, 2017 at 1:18 PM
> From: "michael norman"
>
> Whether I know how ffmpeg works is neither here nor there.

Oh yes it is. If ffmpeg is broken, incorrectly installed, inaccessible, or 
misconfigured, GiP won't be able to launch it. As someone suggested earlier in 
the thread, take the failed ffmpeg command from the GiP error message and try 
to run it at the command line. If it still begins with /usr/share/ffmpeg, 
change it to /usr/bin/ffmpeg.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: GIP 2.99 on openSUSE 42.2

[iz]

> Sent: Tuesday, March 21, 2017 at 12:51 PM
> From: "michael norman"
>
> I last tried --prefs-add ffmpeg  "/usr/bin/ffmpeg" but that doesn't work.

Wrong syntax (compare to below), and not necessary since you have established 
that /usr/bin/ffmpeg is in $PATH.

> I ran get_iplayer --prefs-del --ffmpeg="/usr/share/ffmpeg"

I suggest you back up and delete $HOME/.get_iplayer/options since it may have 
junk in it now. Run with only default settings until you know ffmpeg works.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: GIP 2.99 on openSUSE 42.2

[iz]

> Sent: Tuesday, March 21, 2017 at 11:52 AM
> From: "michael norman" 
>
> Quite so.  What I can't work out is how to change that.

get_iplayer --prefs-del --ffmpeg="/usr/share/ffmpeg"

Run "which ffmpeg" at a prompt. If that returns "/usr/share/ffmpeg", something 
is dreadfully wrong that is unrelated to GiP.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: GIP 2.99 on openSUSE 42.2

[iz]

> Sent: Friday, March 17, 2017 at 2:23 PM
> From: "michael norman"
>
> /home/michael1/imagine_Summer_2010_-_3._Growing_Old_Disgracefully_b00sz455_original.hls.ts
> open3: exec of /usr/share/ffmpeg -loglevel error -stats -y -i 
> /home/michael1/imagine_Summer_2010_-_3._Growing_Old_Disgracefully_b00sz455_original.hls.ts
>  
> -c:v copy -c:a copy -bsf:a aac_adtstoasc 
> /home/michael1/imagine_Summer_2010_-_3._Growing_Old_Disgracefully_b00sz455_original.partial.mp4
>  
> failed at /usr/bin/get_iplayer line 2075.

You have misconfigured GiP somehow. /usr/share/ffmpeg will never be the 
location of your ffmpeg binary. It is a folder that contains shared data for 
ffmpeg, such as preset files. No surprise that GiP can't launch a folder. Use 
/usr/bin/ffmpeg, though that should already in in $PATH and thus no need to 
configure GiP explicitly.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Re "Issues with Large Files" and "Recent Radio Downloads Not Playing".

[iz]

> Sent: Thursday, January 26, 2017 at 4:36 PM
> From: Budge
>
> profile"  error with this file.  I am using ffmpeg v3.2-6.5 but I do not 
> think it is an ffmpeg fault.  There was an update on my system on 17 

ffmpeg 3.2 may be the culprit. That particular version caused a problem with 
remuxing DASH radio downloads that would lead to atomicparsley showing "unknown 
profile":

https://squarepenguin.co.uk/forums/thread-1095.html

If that is the case, you would need to remux with newer ffmpeg to another .m4a 
file.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Re "Issues with Large Files" and "Recent Radio Downloads Not Playing".

[iz]

> Sent: Wednesday, January 25, 2017 at 11:46 AM
> From: RS
> 
> It seems that DASH is not simply AAC.  The adaptive bit rate may be what is 
> causing Linn to complain about the size of the stsz table.

"Adaptive bit rate" isn't an inherent property of a stream or the resulting 
file. That phrase just means that a player can choose among different bit rate 
streams in a single playlist based on characteristics of the playback 
environment. get_iplayer isn't an adaptive "player", so it's a moot issue in 
this case. Also, the raw DASH files for radio programmes don't use stsz and 
related tables. The files are fragmented MP4, so the sample information is 
spread over multiple track fragments. The st* tables are created during 
re-muxing, and only describe the audio content of the final file.

> The next question is how to convert AVC3  to AVC1  or AAC.  I have already 

AVC3 is only related to video, so has no bearing here. ffmpeg version 3 and 
above will do AVC3->AV1 during re-muxing, though.

> tried using ffmpeg and its aac codec.  It was very slow and I still couldn't 
> play the file.  I have also tried the Nero encoder, but my player did not 
> like the MP42 Major Brand or the .mp4 extension.

One other long shot to try is to remove the MP4 container by remuxing to plain 
old ADTS AAC. However, I'm guessing that even if that file played you may not 
be able to seek/ff/rw, so of limited use. You could also feed the raw 
fragmented MP4 DASH file to your player, but I suspect that is even less likely 
to be supported.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Issues with Large Files

[iz]

> Sent: Saturday, January 14, 2017 at 12:05 PM
> From: RS
> 
> always suspicious of people who refer to "chunks" when there is a recognised 

I suspect they are using "chunk" from MP4 parlance, though a chunk contains 
multiple audio blocks ("samples" in MP4).

> Does the Linn play all the files in a directory in turn?  It it does, would 
> it help to split the file into separate files for each act of the opera?

The issue could be that Linn's player doesn't have enough memory to read the 
sample tables from the file's MP4 container, so it refuses to play the file. If 
so, splitting the file or transcoding to FLAC are probably the best options.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Issues with Large Files

[iz]

> Sent: Thursday, January 12, 2017 at 3:30 PM
> 
> My question is with what does one look at a file to find out this info. 
> I tried mediainfo and am none the wiser.  What tool gives me the detail 
> to which Linn referred?

In this case, you only need arithmetic. AAC uses a fixed number of samples per 
frame (the "1024 spf" you see in the frame rate in MediaInfo output), so the 
total number of frames is basically a function of sample rate and programme 
duration. 400k+ would be expected for a 48kHz 9200 sec AAC LC file.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Audio/Video Out of Sync

[iz]

> Sent: Tuesday, August 16, 2016 at 4:39 PM
> From: RS 
>
> >From: David Cantrell
> >Sent: Tuesday, August 16, 2016 14:42
> 
> >> >I'd like to rate-limit get_iplayer so that other things on the same
> >> >machine that are also talking to the internet don't run like stunned 
> 
> If you are using OS/X I can't comment because I have never used it.  A quick 

If you are using OS X, this approach worked for me:

https://dreness.com/blog/archives/843

Just change "dummynet out" to "dummynet in" and change the bandwidth limit to 
desired value.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Simultaneous D/L warnings in 2.95.1

[iz]

> Sent: Tuesday, July 19, 2016 at 12:31 AM
> From: "Nick Payne" 
> 
> WARNING: Segment not found (13) 

That is due to a server error. It means that piece of the programme is missing 
or unavailable on the server. It isn't related to your network connectivity or 
anything in GiP. The fact that you see that message means the server has 
delivered a complete response, albeit a 404 "not found" response. I've seen 
these problems fixed after a while, but not always.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: xinetd and get_iplayer.cgi

[iz]

> Sent: Wednesday, September 09, 2015 at 1:16 PM
> From: "Sam Lewis" 
> ...
> I get the following output on my web browser: "CMD STEDRR: mkdir /plugins: 
> Permissions denied at /home/me/opt/get_iplayer/get_iplayer line 2200."

I haven't tried exactly the same thing, but I think the issues are the same as 
I found with CGI deployment.  There are a couple of things to do:

1. Log in as "me" and run get_iplayer once (with no arguments) to create and 
seed its config directory, incl. downloading plugin files.

2. Set HOME for the spawned server environment in xinetd.conf. get_iplayer 
wants to access its config directory at $HOME/.get_iplayer.

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: Transcoding live streams question

[iz]

On Thu Jun 4 11:02:28 BST 2015, John Warburton wrote:
 
 (1) am I neglecting a command-line option to do this,

I found that I could use --hls-livetv-opts=-acodec copy -vcodec copy to 
override the transcoding.


___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer