Project

General

Profile

Bug #4298

Recordings do not appear until restart

Added by Evren Yurtesen over 2 years ago. Updated about 2 months ago.

Status:
New
Priority:
Normal
Assignee:
Category:
PVR / DVR
Target version:
Start date:
2017-03-28
Due date:
% Done:

0%

Estimated time:
Found in version:
4.1-2405~geb495a0
Affected Versions:

Description

I am using 4.1-2405~geb495a0~xenial and I realized that the recordings finished from autorec have log entries at /home/hts/.hts/tvheadend/dvr/log but they do not appear in the finished recordings list until I restart tvheadend service.

I don't see anything strange in the logs

Mar 18 19:39:37 ubuntu tvheadend[763]: dvr: "Midsomerin murhat (12)" on "Yle TV1" recorder starting
Mar 18 19:39:37 ubuntu tvheadend[763]: subscription: 0118: "DVR: Midsomerin murhat (12)" subscribing on channel "Yle TV1", weight: 300, adapter: "Realtek RTL2832 (DVB-T) : DVB-T #0", network: "Turku", mux: "538MHz", provider: "YLE", service: "Yle TV1", profile="pass" 
Mar 18 19:40:07 ubuntu tvheadend[763]: dvr: /export/WD-WCATR1665370/Tvheadend/Yle TV1/Midsomerin murhat (12)/Midsomerin murhat (12).2017-03-18.19-40.ts from adapter: "Realtek RTL2832 (DVB-T) : DVB-T #0", network: "Turku", mux: "538MHz", provider: "YLE", service: "Yle TV1" 
Mar 18 20:26:54 ubuntu tvheadend[763]: subscription: 0118: "DVR: Midsomerin murhat (12)" unsubscribing from "Yle TV1" 
Mar 18 20:26:54 ubuntu tvheadend[763]: dvr: "Midsomerin murhat (12)" on "Yle TV1": End of program: Completed OK

Yet this specific recording was not listed in finished recordings until I restarted tvheadend service.

I did not have this problem with pre 4.1 versions. Any ideas?

Note: I have a post recording script which re-encodes files with x265 and overwrites them. I had no problems with it in the past versions of tvheadend but just thought I would mention in case it may be related?

History

#1

Updated by Jaroslav Kysela over 2 years ago

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

#2

Updated by Evren Yurtesen over 2 years ago

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

#3

Updated by Joe User over 2 years ago

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.

#4

Updated by Jaroslav Kysela over 2 years ago

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\
...
#5

Updated by Joe User over 2 years ago

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?

#6

Updated by Evren Yurtesen over 2 years ago

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.

#7

Updated by Jaroslav Kysela over 2 years ago

  • Target version set to 4.4

Note to me: document the possibility to change the file path throught the http request. Perhaps, think about a simpler way for scripts (like unix named pipe?).

#8

Updated by Joe User about 2 months ago

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.

Also available in: Atom PDF