The switch shows no errors on either port.
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?
- No, I haven't tried that. Containers are the way.
- Yes, the NFS share is mounted on the Linux server and tied to a Docker volume for the container
What does your docker run or compose look like?
What directory are you picking for Channels DVR to record to?
Binds:[
"/opt/channels-dvr:/channels-dvr",
"/mnt/dvr/recordings:/shares/DVR",
"/mnt/media/plex:/plexmedia:ro"
],
I suspect your graph is total bits out rather than bits per second.
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.
On your NAS, look at the following:
Network activity
Disk writes
What do you see there?
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):
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):
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.
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.
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.
I really don't think the streaming index accounts for that much increased traffic. Could it?
I don't have deep video processing enabled and the couple video index files (iframes.m3u8 & stream.m3u8) created for each recording are relatively small in size.
Not sure how large the files are when deep video processing is enabled.
Being able to watch while recording is important, so I'll take whatever tradeoff that entails, but it looks rather strange, and would appear to place some upper limit on program length.
I have run into some issues with longer recordings as I approach the end (less responsive to FF, etc.) and wondered if it were due to re-reading an index from the beginning.
@eric would know better than I. I don't know exactly what is in the streaming index, what the data structure looks like, etc. I think the deep video processing is done after the fact, and I don't think I have that enabled, either.
Look in your DVR's Metadata directory
There's one folder per recording, with the name of the folder equal to the file ID of the recording.
Check Settings > General > Library Database > Deep Video Processing
This might be helpful to monitor the situation
To test, you could redirect the streaming index directory in your docker volume mapping to be written to your linux machine running Channels DVR Server.
If the excess network traffic is due to the streaming index being written, this will prove it.
Simply add a volume bind for the Metadata directory to a local path on the linux machine running CDVR
/linux_dvr_server_path:/shares/DVR/Metadata
I did some math on it. The stream pointer files are a total of 2.6 MB. So by the end of the recording, it was writing more than an additional 20 megabits per second for a stream that was only 6 Mbps.
Guess if it's rewriting the complete streaming index files every second that makes sense.