Bug #4298
Recordings do not appear until restart
0%
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
Updated by Jaroslav Kysela over 7 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.
Updated by Evren Yurtesen over 7 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
Updated by Joe User over 7 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.
Updated by Jaroslav Kysela over 7 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\ ...
Updated by Joe User over 7 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?
Updated by Evren Yurtesen over 7 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.
Updated by Jaroslav Kysela over 7 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?).
Updated by Joe User about 5 years 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.