Sage file access details?

[lovingHDTV]

I'm trying to determine how sage accesses/store video files with respect to network bandwidth.

Here is my setup. On the Server and client I have drives v: mapped to \\client\d, now if the encoder is installed in client, and I record a show with it, will it get stored directly to drive d: via the mapped drive v:, or travel over the network to server to be stored on drive v: which will cause it to travel over the network again to client to be stored on drive d:.

I guess this goes for playing shows stored on the client to be played on the client.

I hope this makes sense.

thanks,

[Kanati]

since you can't map a mapped drive you aren't going to get any of that infinite loop type thing you are asking about. If I understand correctly you have:

Server
C:
D:
V: \\client\d

Client
C:
D:
V: \\localhost\d

The server would save the file across the network to \\client\d if you have it set to use V: ... If you have it set to use V: and D: it will (I think it balances use between drives) save to both D: locally and V: (\\client\d).

Now if I am mistaken, and you have V: mapped to \\server\d on the client machine you will get exactly the same result. The only difference is that on the client machine you will be pulling from the D: drive on the server.

Maybe it would be best if you describe what you are wanting instead of what you THINK might be happening.

[ToxMox]

I'm pretty sure it travels from the encoder on the client to the server and back to the client. Same goes for playback. I've never tested this so I don't know for sure.

[Opus4]

Networked encoders write directly to the storage location w/o touching SageTV server. So, I guess your question boils down to: how does the client system handle a file saved to \\client\d mapped as drive v: compared to how it would save something directly to d:. I would hope the system knows it is a local drive and uses no network resources, but someone with more knowledge of how networks work would have to confirm that.

For playback, however, streaming for most media goes through SageTV server & then out to the client playing that media, i.e.: the client won't play a local file w/o network usage.

- Andy

[lovingHDTV]

It makes sense that for recording it go directly to the drive, whether local or remote. It is kind of disappointing to hear that client playback requires everything to go through the server. To bad the server could not just server up the location of the file to the client. Then when done viewing the client send back any info to the server, like mark watched, like, etc.

thanks

[Kanati]

That would be an extremely poor way to do it and I'd be pretty surprised if that was the case. I don't use client, but for frey to program it to use double bandwidth by sending to the server before going back to the client would be extremely negligent on their part. Someone that uses client please check this as I'm betting it's not the case. The client should check in with the server and ask "is it ok to play this?" and do it.

[mlbdude]

That is how it works. Fortunately the server streams it out to the client rather than just send the file as fast as the network can handle it. I doubt it was designed with the limitation that the client would even have a encoder card in it. It is generic so any computer can have an encoder and any computer can have a client.

[salsbst]

That would be an extremely poor way to do it and I'd be pretty surprised if that was the case. I don't use client, but for frey to program it to use double bandwidth by sending to the server before going back to the client would be extremely negligent on their part. Someone that uses client please check this as I'm betting it's not the case. The client should check in with the server and ask "is it ok to play this?" and do it.

And what if the client and the file server don't share the same operating system and file system? Still a bad idea? Your statement sounds quite brash.

[Kanati]

And what if the client and the file server don't share the same operating system and file system?

So? The file is stored on the client machine and the client wants to play it... It should, at most, have to check in with the server and then play it. So what if the OS/file system isn't the same? In this case and apparently from what mlbdude says, the file gets streamed to the server which then streams it back to the client. Poor choice however brash you think it may be to say so.

[Opus4]

Originally Posted by Kanati

Someone that uses client please check this...

I wish I had thought of actually trying to use the client one day instead of just making stuff up & posting it.

Originally Posted by Kanati

... as I'm betting it's not the case.

So... how much do we win in that bet?

The client doesn't even have to have access to the location where the media is stored. In fact, direct access to the recording dirs for the client only came into play when people started needing the client to be able to use something like ComSkip data files that are stored in the same place as the associated recordings... leading to a sudden desire by people to change their recording dir locations to use mapped drives or UNC paths so the client could see those locations. I don't know if the client will gain direct access in the future, but that is the way it currently is.

- Andy

[stanger89]

Originally Posted by Kanati

In this case and apparently from what mlbdude says, the file gets streamed to the server which then streams it back to the client. Poor choice however brash you think it may be to say so.

But you're only looking at one possible configuration. If that were the only one, then yes it would be a poor choice, but it's not, eg:

File is stored on the server with SageTV.
File is stored on a separate machine from SageTV but which the client doesn't have access/permission to use.

The whole point of the server streaming to the client is that the client doesn't need access to the filesystem where the file is stored, for most situations, having the server read the file, and stream it to the client is probably the best compromise.

Further, it's not necessarilly easy to make an exception for your circumstance. In that situation, you'd have to be recording to either a UNC path or mapped drive, both of which may or may not be on the client system. And while possible to determine if it's local, it's a good bit of excess complexity for essentially no benefit.

And finally, it's not like bandwidth costs anything, assuming a full-duplex 100 Mbps connection, you'll be using AT MOST 1/8 of the connection for streaming, realistically more like 1/16-1/12. And with 1000Mbps you multiply those by 1/10 so it's even less. Heck I record/playback digital cable from a network file system over 100Mbps, and those files are 36Mbps (about 5-6x a Sage recording) and it doesn't cause any issues.

While it may not be optimal in that specific case, doesn't mean it's a poor choice, it's probably the best solution for the most possible cases total.

[Kanati]

File is stored on the server with SageTV.
File is stored on a separate machine from SageTV but which the client doesn't have access/permission to use.

I agree totally that in those cases it is indeed the best solution. In THIS case, however, the server doesn't need to know it's local, only that the client is requesting to play a file... The CLIENT knows it's local, so it's just waiting on response from the server saying that it's ok to play. It determines whether the file is ok to play, and says "go for it." The client then plays the file without any network traffic other than the initial query/response to the server.

My background is as a programmer. Specifically, I write networking code for connection to and from the IRS currently, and have a good background in network programming... I am also a network administrator for a national level ISP... Networking "is my thing" so to speak. So I think we'll have to agree to disagree on how difficult it would be to have the client determine that it's on a local drive... After all I don't have the code base for sage to determine what it would take to change. But in the short term I still believe it was a bit short sighted to create it the way it is...

(what happens when we get true HDTV support? Low bandwidth now, but HD is a bit heftier... So toss a few more of those clients on the network and it'll be more of a burden...)

No skin off of anyone's back right now... Like you say, internal bandwidth don't cost a dime. Currently you are right... It's "probably the best compromise".

[nielm]

The general idea behind sage is that the file server *is* the media server which *is* the Sage server...

Setting up separate systems (with correct mapped drives/paths/privilages) for people who are techies who understand Windows networking, but Sage is intended for the 'average' home user, who may not want to lean all that stuff.

As the server does not know whether the client has access to the files, the 'safest' solution for ease of configuration is for the server to serve the files directly.

This also allows a generic client / server architecture to be developed which can run cross-platform, and serve files to media extender devices such as the MediaMVP..

[lovingHDTV]

Sage operates like I thought it did. But there is a pretty easy solution, I'll buy a gigabit hub, put a gigabit card in the server. With that setup I should be able to record, and stream HDTV for serveral client simultaneously without any issues. At the price of gigabit hardware now this will be cheaper upgrading my PC133 memory

[ToxMox]

Just be careful when buying a gigabit switch/hub. Many that are listed as being gigabit only have one gigabit port and the rest are 10/100.

[mlbdude]

Just for frame of reference, at one point I had the SageTV server with two encoders, two network encoders in another box, and three clients (one on the network encoder) and never had any bandwidth issues or issues with other network apps when everything was in use.

[lovingHDTV]

mlbdude,
was that 100MB full duplex I assume?

[mlbdude]

Originally Posted by lovingHDTV

mlbdude,
was that 100MB full duplex I assume?

Sorry, yes 100MB full duplex.