Random skipping in recordings

Channels DVR Server
#1

not sure if this is new or remote only, but since we've been away from home the past few days and watching a lot of recordings from our home channels server i've been occasionally seeing recordings randomly skip ahead by what seems like 15-20 minutes with no interaction from me. the recordings themselves are not compromised, as i can restart the recording and go back to the point where it skipped and everything plays fine...

has anyone else seen anything like this? i'm seeing this on the fire stick app...

edit: just happened again. watched the first few minutes of an episode, skipped ahead 15 min or so. restarted, went back to the original skip point...made it a few mins further before skipping ahead again.

#2

What is the source of the recording?

Timestamp issues can cause problems, especially with internet-based streams (Locast/TVE), and are only enhanced/exacerbated by transcoding for remote access.

#3

both cases where i've seen it were locast, but i had never seen it before yesterday. i use channels exclusively for locast/TVE and had never seen this before.

#4

I have had issues with Locast in the past. It will be fine and then I would get partial recordings. From what I have been able to tell, the problem is on the Locast side. My Locast recordings were never quite as clear as watching live - which was OK.

#5

that's not what this is, at all. the recordings themselves are obviously fine, as evidenced by the fact that i can go back and restart them at the point where it skipped and be able to view it (sometimes for just a few minutes til it skips again, but sometimes all the way to the end).

this isn't an issue of the recordings being corrupted, this is just the playback skipping randomly for some reason.

#6

I have had one instance of something similar to this happening. If I recall correctly it started right after I skipped ahead numerous times. This was on an iPad. It jumped quite a bit into the future. I dragged back to where I thought I should be on the timeline and started playback again. It worked but when I skipped ahead again it jumped forward again. I think I backed out of the recording and went back in and resumed and things were fine. Not 100% sure this is what you are seeing but sounds very similar.

#7

not quite...it's just happening randomly while watching. not necessarily after skipping ahead.

#8

based on what i saw tonight, it seems this was only happening in recordings that were in progress. i started watching the weakest link just before it finished recording and had it skip twice, but after the recording finished it hasn't skipped at all...

#9

Sounds like you have a bandwidth issue, either network or hard drive/storage. Since it ends after the writes finish, it's probably an issue with the storage side.

Moving your DVR recording drive to a faster bus might help your situation.

#10

hmm...i'm not sure how to accomplish that. i have channels running via docker inside a proxmox VM on my T30, and it's writing to an internal drive. it's not like i have it running on a rpi writing to an external drive or something like that. there should be plenty of bandwidth available for it.

#11

So it's running in a container in a VM on the NAS? I can see a few layers there, so that might have something to do with it.

For the NAS: what FS are you using, and what's your storage layout? ZFS? Ext4 on RAID via mdadm? Btrfs? XFS on LVM?

For the VM: How is storage accomplished? Direct block access, or disk image? What format is the image: qcow2, raw, or something else? What disk driver are you using, VirtIO, SATA, something else? What FS is being used? Is the FS performing COW?

For the container: Which storage/FS driver is it using? Overlay2, or something else?

For each layer there are multiple places where the storage performance can be impacted, and certain settings can be tweaked to address some of the limitations. However, there is always going to be additional overhead when you introduce additional layers.

1 Like
#12

So it's running in a container in a VM on the NAS? I can see a few layers there, so that might have something to do with it.

yeah, that's unfortunately the easiest way for me to accomplish it. i have several other services running this way though without any issues (although plex does occasionally stop to buffer, which i've never quite understood because the server and network should be plenty powerful enough...i wonder if this is similar).

For the NAS: what FS are you using, and what's your storage layout? ZFS? Ext4 on RAID via mdadm? Btrfs? XFS on LVM?

i'm not sure how to answer this so i'll just describe how it's set up: proxmox creates a virtual disk for the VM and attaches it to the VM as storage. the server isn't really a NAS per se, it's a server that does have a VM running openmediavault acting as a NAS, but the storage for channels isn't using OMV - it has its own virtual disk.

For the VM: How is storage accomplished? Direct block access, or disk image? What format is the image: qcow2, raw, or something else? What disk driver are you using, VirtIO, SATA, something else? What FS is being used? Is the FS performing COW?

you are way over my head on a lot of these questions, unfortunately. i'm not a hardware expert, i'm just getting started with the whole homelab thing. proxmox was the easiest way for me to get up and running quickly.

according to the proxmox console, it's SCSI. SCSI controller is listed as VirtIO SCSI. the virtual disk itself is a 1GB lvm-thin volume. the underlying drives are all western digital white label 10 TB drives that were shucked from easystore externals. no RAID.

For the container: Which storage/FS driver is it using? Overlay2, or something else?

overlay2

if you need any more definitive answers i'm happy to run any commands on the server that will get you the answers you need.

#13

My knee-jerk response with the limited information given is that indeed the two situations are related. It also seems to me that the layering of storage being so far removed from operating on bare metal is probably the biggest bottleneck.

You may find more detailed and helpful responses from the Proxmox folks. They would be much better situated on how to tweak or arrange your system to get the best performance, and avoid file r/w slowdowns.

(Of course, this is just my WAG based upon limited information. However, I think it might give you a few pointers on where to start looking.)

1 Like
#14

ok, definitely not that. just skipped WAY ahead in the middle of us watching SNL recording from last night...like 30 minutes ahead. again, able to restart the recording and put it back at the skip point...so the actual recording is fine.

#15

so, because i'm an idiot and didn't check the logs last week when this was happening and it still is happening regularly, i decided to check the logs last night as it skipped merrily through big brother over and over and over again. low and behold, there are some items there...

2020/10/07 20:42:02.060454 [ENC] Starting encoder for Big Brother S22E27 2020-10-07-1957.mpg in /shares/DVR/Streaming/file3045-345f1a54986e-330607883/encoder-0-656556917 at 0 (0.000000) (encoder=libx264, resolution=480, deinterlacer=blend, bitrate=1000 segment_size=0.01)
2020/10/07 20:42:15.012493 [ENC] Segment 29 has unexpected duration: inputs=38-39 expected=2 actual=2.1 expected_pts=58.000000-60.000000 actual_pts=57.974667-60.041333
2020/10/07 20:42:24.813779 [ENC] Segment 52 has unexpected duration: inputs=66-68 expected=2 actual=2.066667 expected_pts=104.000000-106.000000 actual_pts=104.008000-106.041333
2020/10/07 20:42:26.913734 [ENC] Segment 57 has unexpected duration: inputs=76-78 expected=2 actual=2.066667 expected_pts=114.000000-116.000000 actual_pts=114.008000-116.041333
2020/10/07 20:42:45.599327 [ENC] Request for 107 is more than 10 from the last encoded segment of 96
2020/10/07 20:42:45.639007 [ENC] Stopped encoder for Big Brother S22E27 2020-10-07-1957.mpg in /shares/DVR/Streaming/file3045-345f1a54986e-330607883/encoder-0-656556917 after encoding 0 to 96

similar lines are in the log each time the recording skips.

#16

That looks to be a problem with the source feed from Locast then.

#17

that doesn't make sense, there's nothing wrong with the recording. if i re-start it and go back to the spot where it skipped, it plays through it fine (until the next time it decides to skip). lather, rinse, repeat.

#18

Solely based upon the information you've provided, it does appear to be the case:

Your local transcoder is having issues because the stream it is ingesting differs from what the container said it contained.

Also, why are you transcoding? Is this for remote viewing? I don't recall that transcoding was mentioned previously, so this is new information. Does the problem occur when quality is set to Original? Does it occur with hardware transcoding?

#19

yes it's for remote viewing, that was mentioned earlier. the internet connection isn't strong enough to support original, so i have no choice.

and again, i don't understand how it can be an issue with the feed from locast when i can go back and play it from exactly the same point (even a little before) and it will play perfectly right through the spot where it just skipped without so much as a single hiccup (no pixelation, no audio glitch, nothing). the recording is flawless, it just randomly skips ahead at times for seemingly no reason.

if it were an issue with the locast feed, would i not be having issues when watching live? there are no issues if i watch anything live...

edit: this isn't only for locast streams, my wife tried to watch drag race the other day and said the same thing was happening to her.

#20

update: skipping also on original quality (no transcoding). nothing in logs when playing @ original.