Comment 12 for bug 118700

> You can download recordings from the backend using an URL like
> http://host:6544/Myth/GetRecording?ChanId=12345&StartTime=2008-07-15T00:00:00.
This would be a good solution. However the best it would be for the frontend using the _ftp_ transfer protocol, because this really is the fastest way to get big files over the network without causing additionally traffic/loss/... . But you have to deal with what we have ;)

Just a few comments because I see you are going deeper into the problem: There are two possible scenarios:
 1. Download to mytharchive frontend -> Process** locally
 2. Process** on (fast) NFS mount

** mythreplex, ffmpeg, dvdauthor & Co. ...

(1.) If I understand this right, you first download the mpg file from the backend to e.g. the temporary mytharchive dir on the frontend and then process it? This would use all resources at best and avoid problems mentioned in (2.). Probably you could force mytharchive to use a "Storage Group" that points to this directory after copying. I don't know if mytharchive already distinguishes between local/distant file systems and can handle the existence of two identical recording files in different locations?

(2.) Due to the fact, that even on fast gigabit networks with fast backend servers (and this is not the fact here, since people like to use their faster frontend due to a weak backend server) the throughput would reach at best (!) approximately 20-30MByte/s on a mounted NFS directory. To avoid any flame wars here: I am talking about real life speeds, not theoretical speed. Compare that to possible disk speeds of around 80-100 MByte/s with direct disk access. Additionally using a NFS mount on the backend server that way will cause heave CPU usage on this machine! On the other hand this would lead into less disk usage on the frontend machine (however heavily using the PCI bus for the network connection).

So laga I wish you good inspirations getting this (1.) to work ;) ... Someday ;)