In recent months I have found that I have very poor performance with TV Headend on my Vero when trying to watch a programme that has not yet finished recording. Playback starts but after a variable amount of time, it crashes (I’m usually watching a recording of a BBC One HD program at the time, via terrestial digital aerial adapter, a Silicon Labs Si2168).
My Vero’s have a wired connection to the switch that my Synology NAS is connected to, the NAS is NFS-mounted via fstab to the Vero hosting the TV Headend server for the PVR directory.
Here is a log from the latest playback crash. I wonder if anyone can advise if the log offers any pointers as to where the problem might be?
https://paste.osmc.tv/jujacuyefo
P.S. my NAS video share is NFS mounted via Kodi in terms of general use. I just thought I’d initiate playback of a recording file from the video file browser rather than via the PVR manager, and playback is rock-solid.
I don’t really know anything about the PVR stuff but to switch to the fstab put this in your advancedsettings.xml…
<pathsubstitution>
<substitute>
<from>nfs://192.168.1.216/volume1/video/PVR/</from>
<to>/home/osmc/PVR/</to>
</substitute>
</pathsubstitution>
If you tweaked your fstab back to just nfs…vol1/ and then path subbed nfs…vol1 to home…vol1 then you would make all of your media be accessed with a system mount instead of just your PVR share. FYI although you can certainly mount to your home directory it is much more common to use /media or /mnt
thanks @darwindesign. I have always found Kodi-mounted NFS to be rock-solid with my NAS, on this occasion it’s playback of the OS-mounted in-progress recording that’s stalling. I will monitor whether initiating playback of in-progress recordings from the Kodi files browser (i.e. the Kodi-mounted path) consistently works, or whether the success I had with this last night turns out to be a one-off fluke.
Since everything else is working very well with my Kodi-mounted paths I am loathe to change at this piont, as I’d have multiple substituions to sort out across several clients whilst ensuring nothing gets messed up with the central DB on the NAS.
As someone who uses MySQL with quite a few different clients I can appreciate the concern you have about what I suggested. However the path substitution I outlined does not impact your database or any other clients. If you changed what was in your sources.xml then you would change the paths that get stored in the db. When you do what I suggested above it only redirects on the fly when the listed path string is encountered. This is how I understood it to work but I tested it this morning just to make completely sure and checked what was being stored in the db itself. I added a new movie with a smb:// path as the source and a path sub to a system mount. The db only stored the smb:// path. If the system mount fixes your issue I don’t see where there could be any downside to redirecting the PVR, or all sources on that machine, to a system mount.
I might be being dense here, as my PVR directory is already OS mounted so I can point to it in the Tv Headend configuration, it is already the record/playback path for anything I do in the PVR manager - yet I am having issues with playback while recording - it starts ok, then after a while grinds to a halt.
Based on just n=1, starting playback via a Kodi-mounted path of the in-progress recording works.
At some point I’m hoping someone can advise if the log I posted is pointing to a particular issue.
Couple of updates.
Initiating playback of an in-progress recording via the video files browser instead of via the PVR manager can lead to a playback crash as well, the first time I tried that seemed to be a lucky fluke.
This evening I thought I should try deleting the Kodi-mounted link to the NFS share entirely, and run only with the fstab version of the PVR mount. However, I still find that after a few minutes of successful playback of an in-progress recording, playback will just stall at some point and I am dumped out to the Kodi menu browser (ie playback crashes, but Kodi does not).
Would like to give this one a nudge as it would be great if someone could look at the log I posted in case this points to what the root cause might be of the unreliable playback of in-progress recordings. The flaky behaviour of TVheadend on my Vero when playing back such files is causing some irritation around the household.
I dusted off my LE Pi with a clean install of TVheadend and it was fine, so I’m considering pulling TVheadend server off the Vero and just runing it on the LE Pi as a workaround, but ideally it would be good to figure out where the problem is.
Are the TVH versions the same?
The current TVH version shipping from LE is 4.2.8-36. OSMC is 4.2.8, but I believe it is an older build, I have not found the last level of the minor version number but the date is several months older.
I had thought I might have fixed TVH on my Vero by changing the TVH setting for the DVR Cache scheme - I changed it from “System” to “Sync + don’t keep” in case this might help, and at first I had some very encouraging tests over sustained periods, but after a few hours of up-time, playback of an in-progress recording ground to a halt and crashed out to the Kodi GUI.
It is possible the LE TVH could also fail if I run it long enough, it has not yet had as much up time for me to observe, but so far no issues. My recording directory on the NAS is NFS kernel-mounted just as it is on the Vero, except with LE I use one of the supplied storage-mount template files that are provided.
I came across this recently posted guide on how to set up TVH on an OSMC Pi and towards the end of the guide, there is some commentary on a memory leak issue, with instructions on how to create a swap area to manage that. Should try this on a Vero?
http://unixetc.co.uk/2019/11/22/how-to-watch-and-record-live-tv-with-a-raspberry-pi/
I’m running TVH regularly and I’m not getting any memory leaks. Are there steps to reproduce? I only record a few programmes a month, mind.
I have not been able to pin it down exactly to reproduce. I record from BBC One and Two HD over Freeview, several times a week. Typical situation where playback fails will be if I start watching Match of the Day shortly after the program has started. Typically playback is fine for a few minutes, and then grinds to a halt. I had wondered if the log I posted at the start of this thread has any pointers?
The log doesn’t give any clues. I’ve checked and the latest stable TVH is still 4.28, so there’s not a new version to bump to unfortunately
Thanks for checking. For now I will run TVH server on my LE Pi and use my Vero’s for playback duties, and see how things go. Based on yesterday’s performance this setup was solid, but I’ll need to run this configuration for longer to be sure.
I thought I’d give the Vero another chance with TVH and several things went wrong this evening. I had set two programs to record that were back to back on the same channel. I started watching the first program some minutes after the recording started. All was fine until the broadcast finished, and then playback became very stuttery and eventually died. I noticed that the recording of the first program had aborted giving me an incomplete recording, and also the subsequent scheduled recording failed to start so that recording was a total loss.
I guess I can’t rule out a server-side issue but it’s a big coincidence that everything went wrong at the transition point on the broadcasts.
Can you try the staging repo?
Sure, I have installed that and will see how it goes with TVH. I’ve already noticed a very clean initialisation of .ts playback with the new repo, I was not having major issues in that regard but it could be a little bumpy, that’s gone now, thanks.
Hopefully not tempting fate, but since installing the staging repo, my issues with playback stalling while recording seem to have gone. TVH has felt very solid since the update.
1 Like
There are some improvements for playback in the staging repository
Sam