MythTV and NFS for Recordings

04Nov18

MythTV error message: Error opening jump program file buffer

I’m posting this hoping it will help others who run into the same issue noted above. For the longest time, I’ve used local disk for TV recordings with MythTV on my media center builds (Typically on Ubuntu, but my last build was on Korora) and never had any issues. But recently I lost a 1TB drive and decided that as a band-aid, I’d just an NFS volume on my central NFS backup server for the house. With 5 TB to spare, why not right? To set this up, I simply renamed the original /var/lib/mythtv/recordings directory as /var/lib/mythtv/recordings.old and created a new directory with the original name, set the correct owner:group and mode and then mounted the remotely exported volume.

On the remote side, I made sure that the right user and group IDs were assigned to the exported /capstore/mythtv directory, defined the export for read/write in /etc/exports and ran ‘exportfs -av’/ So far so good. I then mounted the new NFS volume on the media center, verified that owner:group and mode looked correct and then ran the MythTV frontend (note that the backend is also on the media center system). Watch TV worked, but as soon as I tried to change the channel, I got the dreaded “Error opening jump program file buffer” error. Assuming that others have encountered this before, I searched the web which pointed me to some forums where people were asking the same question but getting various, unhelpful answers. Some of them complaining about how the community isn’t that helpful. Not a good sign for my search!

I went to the MythTV wiki and located the NFS section. Beside the things I’d already set up, I tried the other recommendations, like setting the actimeo=0 mount option on the client to turn off NFS attribute caching, and using ‘soft’ and ‘async’ to prevent issues with uninterruptible sleep states should the NFS server go offline or otherwise be unavailable. I tried switching between UDP and TCP protocols. I set the rsize and wsize to 32k. None of these things seemed to be working. I also found that I could forego actimeo altogether and just use ‘noac’ to disable attribute caching which improves response time for media purposes like MythTV. I double checked the ACL on the dir as well to no avail. It looked like everything was set right but as soon as I tried to change the channel, I’d get that annoying error and the forums had no answer.

At one point I switched back to my local disk to make sure there was no issue there, and it definitely had no problem working from local disk. The NFS was the issue, but how? Why? Log files were vastly unhelpful other than confirming that the file didn’t exist. Looking in the directory, the file was definitely being created and was there. Each one even had a few kB or Megs in it. Then I noticed something funny. I knew when I’d been working on this issue last night and today. And the time stamps on those files did not look correct at all. Nearly -12 hours off! I checked the system time on the media center and it was correct. I went to the NFS server and checked and… it was nearly -12 hours off. The server is quite old (I won’t say how old as it’s nearly embarrassing šŸ™‚ ). The issue appears that the Linux distribution I used for it has time servers in /etc/ntp.conf that are no longer valid so it’s drifted out of time sync for quite a while.

I corrected the defunct time server pools, stopped ntpd, synced with ntpdate and restarted ntpd, then verified that the time was correct as viewed from both sides. It was. I tried running MythTV again and changing channels. It finally worked. So what I learned is that EVERYTHING matters with NFS for MythTV (and other applications) including the server’s time. My guess is that MythFrontend created the file it needed but probably has some aspect of it’s functionality where it stats some portion of the time stamp and if it doesn’t jibe with local time on the client, it treats the file as non-existent, hence the “File not found” errors. The other thing that it reinforced in my mind… I have some updates to take care of. But that’s a task for when I actually have time back in my personal life.

Some of the useful links I found that got me partway there:

Most helpful for the MythTV specifics around NFS set up: https://www.mythtv.org/wiki/Optimizing_Performance#Network_File_Systems

Where to check backend logging: https://www.mythtv.org/wiki/Troubleshooting:Filesystem_Permissions

Useful tip for CIFS and NFS (note there is no ‘forcedirectio’ mount option in LInux, that is where ‘noac’ comes in): http://wildebeestplain.blogspot.com/2011/01/mythtv-and-network-mounts.html

I hope this saves someone else time, because although it might be obvious to some, not everyone would think to check time skew on the backend file server as part of troubleshooting NFS issues. I know I will from now on.

 

Advertisements


No Responses Yet to “MythTV and NFS for Recordings”

  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.


%d bloggers like this: