Tvheadend

May I suggest a couple of simple modifications?

At the end of the "ffmpeg" if you add "&&" then the next line (mv) would only be run if the ffmpeg is successful (in case you run out of disk space or ffmpeg fails half-way through). Since it would leave the tmp file in that case, maybe force remove it at the end for simplicity.

If you add double quotation marks around $TSVIDEO then it will also handle filenames with spaces.

So something like this:

/usr/bin/ffmpeg -i "$TSVIDEO" -c copy -f mpegts "$TSVIDEO.tmp" &&
mv -f "$TSVIDEO.tmp" "$TSVIDEO" 
rm -f "$TSVIDEO.tmp" 

Good points, @Em!

I've made the changes accordingly, thanks for mentioning!

Couple of other minor points that caused me some problems today.

If the filename starts with "Live:" then ffmpeg treats it as a protocol (like http: ) and aborts. So it needs "file:" in front of the filename to force it to always read the file.

The other minor change I made was to ensure the written file has the same timestamp as the original file (since I don't run it as post-proc, only when needed).

So:

ffmpeg -i file:"$TSVIDEO" ... && touch -r "$TSVIDEO" "$TSVIDEO.tmp" && mv ...

You may be able to stop these bad recordings from occurring in the first place. See this article:

Getting bad satellite recordings in TVHeadEnd? Here’s a possible fix - https://freetoairamerica.wordpress.com/2015/08/01/getting-bad-satellite-recordings-in-tvheadend-heres-a-possible-fix/

Hi,

it does not seem that's the root cause of the issue, but it seems I've fixed that last weekend ;-)

I did a "netstat -us" on my TVH VM and saw a lot of missed UDP packets due to receiver buffer overflows. It seems that the UDP input buffers are not sufficient in Ubuntu 16.04, so I've added this to my /etc/sysctl.conf:

# Increase size of file handles and inode cache
fs.file-max = 2097152

# Do less swapping
vm.swappiness = 10
vm.dirty_ratio = 60
vm.dirty_background_ratio = 2

# Sets the time before the kernel considers migrating a proccess to another core
kernel.sched_migration_cost_ns = 5000000

# Group tasks by TTY
#kernel.sched_autogroup_enabled = 0

### GENERAL NETWORK SECURITY OPTIONS ###

# Number of times SYNACKs for passive TCP connection.
net.ipv4.tcp_synack_retries = 2

# Allowed local port range
net.ipv4.ip_local_port_range = 2000 65535

# Protect Against TCP Time-Wait
net.ipv4.tcp_rfc1337 = 1

# Control Syncookies
net.ipv4.tcp_syncookies = 1

# Decrease the time default value for tcp_fin_timeout connection
net.ipv4.tcp_fin_timeout = 15

# Decrease the time default value for connections to keep alive
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_keepalive_intvl = 15

### TUNING NETWORK PERFORMANCE ###

# Default Socket Receive Buffer
net.core.rmem_default = 31457280

# Maximum Socket Receive Buffer
net.core.rmem_max = 33554432

# Default Socket Send Buffer
net.core.wmem_default = 31457280

# Maximum Socket Send Buffer
net.core.wmem_max = 33554432

# Increase number of incoming connections
net.core.somaxconn = 65535

# Increase number of incoming connections backlog
net.core.netdev_max_backlog = 65536

# Increase the maximum amount of option memory buffers
net.core.optmem_max = 25165824

# Increase the maximum total buffer-space allocatable
# This is measured in units of pages (4096 bytes)
net.ipv4.tcp_mem = 786432 1048576 26777216
net.ipv4.udp_mem = 65536 131072 262144

# Increase the read-buffer space allocatable
net.ipv4.tcp_rmem = 8192 87380 33554432
net.ipv4.udp_rmem_min = 16384

# Increase the write-buffer-space allocatable
net.ipv4.tcp_wmem = 8192 65536 33554432
net.ipv4.udp_wmem_min = 16384

# Increase the tcp-time-wait buckets pool size to prevent simple DOS attacks
net.ipv4.tcp_max_tw_buckets = 1440000
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1

Then reboot the TVH server. From that point on my UDP RX errors are stable at 0 and I don't see any recording issues.

Thanks, I'll give those a try.

Recordings were working fine 99% of the time until my machine had major problems recently, now I have a number of files that don't fast forward correctly.

I'll keep an eye on the stats and see if they are increasing before I make the change, but it looks like it could be the network since I reset the tvh stats and my tvh is already saying 4000 continuity errors but my sat>ip server is saying (I believe) 8 errors.

It was a bad network. My sat>ip machine had (suddenly/unexpectedly) decided wi-fi should have a higher priority for sending data instead of the Ethernet cable. Since the cable data light was still flashing, I thought it was all working fine and I hadn't realized there was a problem with that machine.

The "rfkill" command can be used to permanently disable wifi.