get_iplayer forums

Full Version: MP4 conversions skipped in PVR (ffmpeg version detection problem)
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

Just upgraded to the latest version, and seeing this:

WARNING: ffmpeg 2.5 or higher is required to convert hvf downloads to MP4
WARNING: Use --raw to bypass MP4 conversion and retain .ts file
WARNING: Use --ffmpeg-force to override checks and force MP4 conversion attempt

andy@xcp-dl:~$ get_iplayer -V
get_iplayer v3.03, 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.

I've put the following in my options file:

ffmpeg /home/andy/ffmpeg-3.3.4-64bit-static/ffmpeg
ffmpegforce 1

As far as I can tell, I'm using a recent ffmpeg:

andy@xcp-dl:~$ /home/andy/ffmpeg-3.3.4-64bit-static/ffmpeg -V
ffmpeg version 3.3.4-static  Copyright (c) 2000-2017 the FFmpeg developers

Any suggestions?


A bit more info, while looking in the code I realised there's another line of debug that would be useful.

Before the messages I posted above, I get:

WARNING: Your version of ffmpeg () does not support conversion of hvf downloads to MP4 - not converting .ts file

Looks like it's not correctly determining the version of ffmpeg. However, given that I've specified a specific path to ffmpeg in the settings file, should it even be doing this step?


A bit more info.

The 'system' ffmpeg is reporting its version as '3.2.7-1~deb9u1'. I wonder is this confusing it?

If so, why isn't it using the 'static' version I've pointed it to in the config file?

andy@xcp-dl:~$ get_iplayer --prefs-show
Options in '/home/andy/.get_iplayer/options'
refreshexcludegroupsradio = local
type = all
radiomode = best
fps50 = 1
ffmpeg = /home/andy/ffmpeg-3.3.4-64bit-static/ffmpeg
tvmode = best
ffmpegforce = 1
nopurge = 1

Thanks again

Follow our instructions to provide a full report so we can see what is happening on your system.
Trying to do that, but now finding that sometimes it's downloading episodes and converting them, when previously it's failed.

I'll keep digging to see if I can cause it to happen consistently. Sadly, the main time it fails is when running --pvr, which sadly doesn't give the same results each time you run it.


BTW, you don't need that alternate version of ffmpeg. The version in Stretch works fine.

I thought that would be the case, but figured it was worth trying the static version.

I'm a little confused that it seems to sometimes work and sometimes not. Not sure if there's something funky going on with the VM that it's running on!

Will let you know if I get further information.


Ok, log files attached, using both the 'Debian' ffmpeg, and the static one. Apologies they're long, but the only way I could get the issue to happen repeatably was to run the full --pvr scan from cron.

Interestingly, when trying to download "Saving Lives at Sea", it doesn't display a valid ffmpeg version string, so downloads a .ts file. However, later when it tries to download "The Next Step", it does display the ffmpeg version string (and then goes on to complain that the .mp4 file already exists).

Any help?


I can see that the internal variables containing ffmpeg version info appear to get overwritten or undefined somewhere along the way, but I can't reproduce that behaviour. A few random thoughts (not much hope for any of them, though):
  • Somehow you have a file without a corresponding history entry. Fix the problem with "The Next Step" by moving /var/spool/xbmc/iPlayer-Download/The_Next_Step_Series_5_-_8._12_Hour_Party_People_b097rtf9_original.mp4 somewhere else and allowing it to re-download before the later attempt at "Saving Lives at Sea".
  • Perhaps try get_iplayer --pvr-single saving_lives to see if there is something peculiar to that pvr search.
  • Back up and empty $HOME/.get_iplayer/pvr, then start adding those pvr searches back into that folder in small batches. Start with those that are current and may actually locate programmes. There may be a bad apple that can be isolated.
I'll give those a try.

Just to clarify something, I've been manually editing the download history to remove these files and force them to be downloaded again (for test purposes). It's not something I do on a regular basis, but it could be related.

I'll try doing the pvr-single operations you suggest.


Ok, some more information.

If I remove the latest episodes of Saving Lives at Sea and Next Step from both the directory and history, I can download them both as MP4 if I use pvr-single.

If I remove them again from directory and history file, then run a full --pvr, Next Step downloads as MP4, and Saving Lives downloads as .ts.

So it looks like something in the script is resetting (clearing?) the ffmpeg version when a full PVR scan is run.

For now, I might just write a shell script that goes over all of the individual PVR files, running get_iplayer with pvr-single for each one. That's a nasty workaround, but might get me back up and running for now.

Happy to run any test versions if you think it might help.

Thanks for the assistance.

Rename "saving_lives" to "a_saving_lives" so that it will be executed first. If only the first download works regardless of content, then that would at least establish a pattern of sorts, though it would explain nothing. And try more than two searches that produce downloads to see if it really is only the first that works.
You can stop thrashing your machine. I found the problem, and it is a bug in v3.03. I'll get v3.04 tonight or tomorrow, but in the meantime roll back to v3.02, or just wait for v3.04.
That's good news.

Will look out for a new version. Thanks for looking into it.

Fixed in v3.04

Updated and ran a full pvr scan from cron. For some reason it didn't email me the log (will look into that) but it has downloaded everything as mp4, so looks like that did the trick.

Thanks for all your assistance.

Good news. Thanks for the bug report.