Debian Stretch crashes while running get_iplayer with NFS
Hi all,

Since upgrading my machine to Debian Stretch, whenever I try to use get_iplayer to download anything, it completely crashes the machine. A message is emitted on the console saying that perl has been blocked for more than 2 minutes.

It's storing the downloaded files on an NFS filesystem, but I've just done an rsync between 2 NFS mounted filesystems on the same machine, and that's working Ok. I don't think it's an issue there.

Has anyone else seen anything similar?


Follow our instructions to provide a full report so that - as much as possible - we can see what what get_iplayer is doing before the crash.
Apologies for not providing sufficient information.

The odd thing is, I've just tried to gather the logging requested, and it's run a successful pvr session for the first time since the upgrade.

One thing I had done was remove the config setting to use the static version of ffmpeg. I thought I'd run another pvr session and had it crash, which was the reason I'd made the above post. Perhaps the reboot after that failed attempt was necessary to complete the transition back to the system ffmpeg?

I'll try again a few times in the next few days and see if the problem recurs.


Typical. I thought I'd give it another go, and it's failed this time.

Log file is attached.

It looks like it failed mid-download of that Horrible Histories episode. It got this far:

-rw-r--r-- 1 andy andy 465891328 Aug  6 15:05 /var/spool/media/videos/iPlayer-Download/
-rw-r--r-- 1 andy andy      3634 Aug  6 15:05 /var/spool/media/videos/iPlayer-Download/

Hope this helps, appreciate any advice.


Attached Files
.txt   get_iplayer.txt (Size: 119.77 KB / Downloads: 12)
It's not clear from that log whether the download actually starts. Do this instead, and post the log file:
get_iplayer --pid=b0909jrk --fps50 --log-progress > log.txt 2>&1
Here you go. Seems to get part way through the download then just stop. Completely kills the machine when it does this.

Thanks for the help so far.


Attached Files
.txt   log.txt (Size: 3.17 KB / Downloads: 10)
Looks like my assertion that NFS isn't a factor might have been wrong. I've just had the machine do exactly the same thing when carrying out a mv between two NFS mounts.

Unless the logs I've provided point to some issue in get_iplayer, I suspect the issue might actually lie elsewhere.

Once I get to the bottom of it I'll report back.

Your last log confirms that the problem isn't related to ffmpeg or get_iplayer. The last test was writing to your home directory (unlike the earlier test), so just to be sure: are you mounting your home directory via NFS as well? If so, then try one more test with --output configured to a location on an internal disk. I can see from the last log that get_iplayer is able to open, truncate, read, and write an output file. For it to hang and crash mid-download would lead me to suspect NFS as the culprit. The only thing get_iplayer is doing at that point is downloading chunks of the programme to the output file. It seems less likely the crashing problem would be in the network stack. In general, it isn't a great idea to have your output directory on a network drive because get_iplayer sends the entire file over the wire 5 times for each download, but everyone's setup will perform differently.
No, the home directory isn't an NFS mount.

However, there are other processes running on the machine that will be accessing NFS all the time, so it's possible it's general NFS access that is the issue.

Will do some more digging and see what I can find.