Would like to put in two feature requests;
Being able to specify specific folders/drives for dedicated caching only. This way I can keep caching local while storage could be in the network — probably making it less likely to experience streaming hiccups.
Being able to limit a drive’s storage space for recordings. This way We could keep other information on a drive instead of filling it up and spilling over.
Your wish has been granted (changed post category to Channels DVR/Feature Requests).
Although you could have done that when you posted.
Depending upon how you set up your server, all of this is possible. If you run your server in a container (or a Linux environment where you have control over your volumes and mounts), then you simply mount your network volume into the expected locations, and then "override" the cache locations with a local bind mount.
Of course, while it seems great in theory, network storage for primary DVR recording is a bad idea, especially with MPEG2 OTA content. And while your Cat8 2.5GbE is awesome on paper, your constant posts about issues seem to indicate otherwise.
In any case, what you are asking for is already available if you are willing to put forth the effort with no need for the developers to do anything; all you need to do is embrace the features already available to you.
(And you may want to look at quotas at the OS-level to ensure that your recording drive only uses the data you allow it.)
Thanks for moving it to the feature request section. Duly noted.
A bit harsh but true. Funny thing is, my xfinity connection works 100% on the initial setup. It was only the iptv connection which was dropping. How that differs (why one is finicky and the other is not), I’m not quite sure but perhaps it’s completely different mechanics when it comes to caching MPEG2 content. Either way, you’re correct about stability issues and some of it was definitely cabling-related. Also I’m thinking there may be additional stuff going on with Jumbo Frames on the NAS NIC set too high.
I’m concerned about recording space eventually filling up and the cache spilling over onto a new drive then eventually to the NAS where suddenly the m3u channels start hiccuping again. I’d imagine that it isn’t an isolated incident here and preventable.
As for specific cache locations, almost all of my graphics 2D/3D applications have specific directories set aside for caching, and I routinely work off of the network storage for large datasets and processing (network rendering over multiple computers) rarely experiencing any network issues or dropped packets. So its a bit weird to have seen the cache lumped together.
You’re also correct in limiting space that you could set aside a drive partition, although for a typical user that’s getting away from simplicity.
Another solution for myself would be to pick up a gpu for my NAS (transcoding) and install CDVR in Container Station/Docker there and probably be done with all this “local vs. non-local.” I’m leaning towards this but I’m trying to cut down on personal spending for now.
While I realize the devs don’t want to be really distracted dealing with iptv content (understandably so), I’ll admit that two of my major incentives for trying Channels DVR was connecting to xfinity (transitioning my wife and eventually ditching Comcast tv/TiVo) and secondly the bonus of importing m3u content. Third I’ll have a hdhomerun arriving tomorrow. The aggregation of most everything - having it all in one place is my end goal. With Plex, they unfortunately nuked 3rd party plugins and iptv, and running xTeve is a total pain. Afaik there’s also no xfinity connection. Their live recording capabilities (as well as tivimate’ s) are wonky by comparison.
Why does the NAS need a graphics card to run CDVR?
Transcoding. I’m running other things on the NAS which can be offloaded (surveillance station, AI, plex, etc.) freeing up resources.
This could be a good idea on a local-level, too, though. Cache to SSD, DVR to HDD, for example. I 1000% agree on your skepticism with network-based storage, however.
I avoid all these problems simply by recording to an SSD and moving the recordings to mass storage when the DVR is not in use automatically using a cron job. It simply checks if the DVR is busy recording viewing or running commercial detection ... if any of this is active it will not move anything.
All Caches recordings etc ... a SSD drive can easily handle.
What do you put in crontab to do this? I use cron to rsync overnight, but would be nice to have this type of check in there.
This is how I check ... after the && you can add your command ... also change to your IP.
curl http://10.0.0.2:8089/dvr | grep "busy\":false," && your command
Thanks! I'll give it a try.
Question when you use rsync how you remove the empty directory? left behind.
I don't. I use it for backup. I run my DVR on my internal 2TB SSD and keep my other recordings on a 5TB external HDD. I have a second external 5TB that is just for backing up. So I run 1 rsync to copy the DVR directory from the SSD to the HDD, then a second to copy the main external to the backup external. Plus I'm running Time Machine of the full SSD to a separate volume on each of the externals. Can't have enough backups!
(added your code)
0 1 * * * curl http://127.0.0.1:8089:/dvr | grep "busy\":false," && rsync -av --exclude=".*" --exclude "Streaming*" --exclude "Logs*" --exclude "Images*" /Users/scott/DVR/ /Volumes/OneTouch/DVR/ --delete
0 2 * * * curl http://127.0.0.1:8089:/dvr | grep "busy\":false," && rsync -av --exclude=".*" /Volumes/OneTouch/ /Volumes/BackupPlus/ --delete
Thanks going to steal your rsync backup.
Go for it. The exclude ".*" were added when I switch from RPi to Mac because MacOS would lock certain hidden files and kill the process. So if you're not on mac, might not need those.
Don't copy paste my lines. They have an extra : after the 8089.