New NAS, new protocol, same observation

Channels DVR Server
#1

Reference Traffic when recording - #5 by JefferMC

Earlier in the year, I made the observation that as a recording was being made, the amount of data being written per interval increases as the recording is made. The last suggestion was that it had something to do with the fact I was using iSCSI as the protocol to access the storage and that the increased writes were an artifact of that.

I have since installed a new NAS and am accessing it from the ChannelsDVR server using NFS. However, the graph looks much the same. A single recording of a football game in MPEG2 on the Fox affiliate starts off writing 6-7 Mbps at the beginning of the recording, but by the end, it's writing over 25 Mbps. Here's the graph (note direction is as viewed by the switch port, so in is from the NAS, out is to the NAS)..

image

Lest you somehow think the broadcast itself is getting up to 25 Mbps, here's the machine that's hosting the Channels DVR container, so the data out (from the switch) is the data from the HDHR and data in is on its way to the NAS. By the way, I don't think it's just long programs, I think it happens with shorter programs too, but its more obvious when there is only one program recording for several hours.

image

I'm sure there's some sort of reasonable explanation for it, I'd just like to understand what that reason is.

#2

I'm assuming those are views from some kind of managed switch?

Have you compared that with a view from your NAS showing its network activity.

#3

It's hard following your descriptions without seeing the network topology, the connections and the switch ports involved and knowing what switch you're talking about.

1 Like
#4

There's an Ethernet switch to which the HDHR, the Linux machine hosting the Channels container and the NAS are all hooked. The monitoring is on the ports of that switch, meaning that all the "IN" and "OUT" labels are from the perspective of the Ethernet switch, not the device.

So a steady stream of about 6 Mbps is incoming from the HDHR into the Linux machine for 3.5 hours. An ever-increasing stream is going from the Linux machine to the NAS host over that same period.

The Network Graph for the NAS:

image

Netdata network traffic on the Linux host:

image
image963×757 43.9 KB

#5

Is that taken from the NAS, or the switch?

And what else would contribute to traffic to/from the NAS, besides Channels DVR recordings?

#6

Could be a lot of things accessing the NAS, but at this time, nothing was That graph is from the NAS itself, so for the time of the other graph, it shows the same thing.

For the original NAS, nothing else could.

#7

And are all your recordings good?

#8

As far as i can tell, yes. And the file size reflects the 6 Mbps, not the increased one. The concern is excessive writes and uneeded network traffic.

But, primarily, i want to know why?

#9

Does your switch show any errors on the associated ports?

#10

The switch shows no errors on either port.

#11

I'm out of ideas.
Have you tried using Channels DVR Server as a Linux install, instead of in a container?
Are you using an NFS mount to your NAS on the linux server hosting Channels DVR?

#12
  1. No, I haven't tried that. Containers are the way.
  2. Yes, the NFS share is mounted on the Linux server and tied to a Docker volume for the container
#13

What does your docker run or compose look like?
What directory are you picking for Channels DVR to record to?
Screenshot 2026-08-16 at 14-35-12 Channels Settings

#14 
Binds:[
"/opt/channels-dvr:/channels-dvr",
"/mnt/dvr/recordings:/shares/DVR",
"/mnt/media/plex:/plexmedia:ro"
],

image

#15

I suspect your graph is total bits out rather than bits per second.

#16

You suspect incorrectly. The same metric formula is being used throughout these switch traffic displays. And it returns to zero at the end. Also notice that it wanders up and down as it ascends, were it total bits it would never do that.

#17

On your NAS, look at the following:
Network activity
Disk writes

What do you see there?

#18

Here are 3 of the 4 active disks in the RAIDZ2 set for the period (I avoided the end where it does post processing because it makes this part of the graph smooshed):

image
image1143×706 162 KB

A minor increasing trend is visible here, but not nearly as pronounced. Anyway, here's the network from the NAS (a better snapshot of just the 3.5 hours as opposed to the 24 hour above... still learning the NAS software):

image
image1185×293 42.5 KB

I'm inclined to go with the theory from @eric that this is showing the streaming index being rewritten. The ZFS software is only writing the actual changes to disk, which keeps the network trend from fully reaching the disk.

I do wonder if it is really necessary to write the entire streaming index from scratch every second.

#19

This is very strange and I never saw anything like this when I had my channels storage on a NAS. I also used ZFS for the pool. The ZFS ARC will be purged to disk periodically and as more data is written per unit time, the number of IOs go down as block rewrites are not necessary.

#20

It's the only way to do atomic writes that change files. It's the only way to keep it up-to-date so you can have the best remote streaming experience while recording. Optimizing for the least possible disk IO is not a priority we have in our DVR. We optimize for over-all efficiency and user experience.