[mythtv-users] Storing recordings on network share
travis at tabbal.net
Thu Sep 22 21:41:51 UTC 2011
On Thu, Sep 22, 2011 at 12:17 PM, Simon Hobson <linux at thehobsons.co.uk>wrote:
> >But who uses 2mbps these days?
> Lots of people ! Over here in the UK, DVB-T
> (which we generally call Freeview) varies but
> isn't a particularly high bit rate. Some of the
> commercial channels can be less than 1GByte/hr or
> about 2Mbits/s, while the BBC channels can be
> more than 3 times that. That's all for SD though
> - I'll need a DVB-T2 tuner to get HD.
Interesting. I'm US based as you probably figured out with the ATSC comment,
so I'm not very familiar with DVB as we needed to make up our own version of
digital TV for no reason I have understood yet. :) My recordings are also
HD, so the required bandwidth goes up a lot. I generally see about 6GB/hr
That is useful to know.
> How is the size of that buffer determined ? Can
> it be controlled by the admin ? Other than taking
> memory away from other areas, is there any
> penalty for using a larger buffer ?
It was hardcoded last time I looked in the source. ThreadedFileWriter.cpp
IIRC. I doubled it and solved a lot of problems, but the syncs were still
killing performance on the array. They don't seem to cause a problem on
single disks or the RAID1 it uses now. Removing the sync calls caused other
issues, so I just switched away from storing recordings on the RAID6. If I
had found a complete solution, I would have sent a patch in, but the things
I did never did fix it entirely. Generally speaking, I agree, larger buffers
are probably called for on HD material, but even if you buffer a few gig, at
some point the HDD has to catch up, or you lose data. Increasing the buffer
didn't seem to cause any issues in my testing, but I hardly have a large
Myth system compared to others here. The array in question is also rather
busy with lots of other tasks, not an ideal place for recordings to go
directly to in any case, for the same reason recordings+database on the same
spindle isn't the best idea.
However, it isn't all that long since bus
> throughput was an issue - especially on (for
> example) a SCSI bus with multiple high
> performance drives. Yes, in the past I'm been
> down the road of carefully arranging my server
> drives equally across all the available busses -
> but I think then the PCI-something slot was
> probably the streaming throughput bottleneck.
Ah yes, been a while since I had to mess with anything like that. SATA/SAS
has made life easy in a number of ways. :)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mythtv-users