Tvheadend

Could you describe, what your post-script does with the file? TVH marks the entry as 'missing file' when you remove the original file.

Jaroslav Kysela wrote:

Could you describe, what your post-script does with the file? TVH marks the entry as 'missing file' when you remove the original file.

It simply re-encodes the file to /tmp/FILE and then uses 'mv' to move it over original file. The original file is never deleted, it is simply overwritten. Below is the script....

#!/bin/bash

# Post Processor Command : /usr/local/bin/re-encode.sh "%b" "%f" 

if [ $# -ne 2 ]; then
        /bin/echo "You need to supply the base name and full path to file to be converted." 
        /bin/echo "re-encode video.mkv /opt/data/video.mkv" 
        exit
fi

# Do not start another ffmpeg while another is running!
while pgrep -x ffmpeg > /dev/null; do
        sleep 60
done

/usr/bin/nice -n 19 /usr/bin/ffmpeg -loglevel quiet -y -i "$2" -c:v libx265 -crf 24 -preset medium -c:a aac -c:s copy -ss 0 -vf yadif=deint=interlaced:mode=send_field "/tmp/$1"  > /dev/null 2>&1

if [ $? -eq 0 ] && [ -f "$2" ];
then
   /bin/mv -f "/tmp/$1" "$2" 
else
   /bin/rm -f "/tmp/$1" 
fi

If you use "cp" instead of "mv", (then rm /tmp/$1) it will preserve the inode of the original file and will not cause it to go "missing". Of course this creates a lot more disk activity...

Best solution would be for tvheadend to check for the existence of a new file with the same name as the old file when an "IN_DELETE" is received through inotify.

Then problem is that mv operation is not atomic across different filesystems, so it is possible that the path might not exist for a little time:

$ strace mv 2 /tmp/1
...
access("/tmp/1", W_OK)                  = 0
rename("2", "/tmp/1")                   = -1 EXDEV (Invalid cross-device link)
unlink("/tmp/1")                        = 0
open("/tmp/1", O_WRONLY|O_CREAT|O_EXCL, 0600) = 4\
...

Related to this post: [[https://tvheadend.org/boards/5/topics/20340]]

Yes, timing would be an issue, but maybe as the other post suggest, a periodic re-scan would be helpful. Or maybe a web link which could be selected or even called with curl/wget which would trigger a re-scan and could be put at the end of transcoding post scripts?

Sorry for the silence. I had food poisoning :(
Anyway, I changed script to use `cp` instead and it seems to work now. I am not sure if the issue is the timing. It worked fine for previous tvheadend versions. Maybe how tvheadend cached the file locations changed?

In either case, thanks for the responses.

This is similar to the closed bug #3818 (https://tvheadend.org/issues/3818)

Any script which changes the recording file should use the filemoved api to notify tvheadend.

This should be changed to a feature request, which can be closed if using the filemoved api is a satisfactory solution, or it can be open of Jaroslav is still thinking of an automated way to deal with the post processing of record files.

Also, if wanted, I could add a simple check to the inotify delete (file removed) function to check if a new file (inode) has been created with the same name as original and, if so, do not set as removed in dvr db.