R5000-HD capture via USB2 & SageTV

[dbfresh23]

Originally Posted by zoop

anyone using the r5000 with sagetv linux oem?

thx

/jer

Since it still uses the windows app from Nextcom to do the recording it's not going to be possible, at least not w/o also having a windows system running that.

[NEOSG]

What about a VMWare Windows Session on the linux host, soley for the nexcom portion ;-)

[Kirby]

Heck, try it with Wine

[gregkovacs]

I'm getting ready to build a system, and for the longest time, I thought I was going to use BeyondTV, BUT... this thread describes what I've been searching/waiting for forever!!!

What are the latest/most severe problems you guys have run into?

What about H264? Does 5.1 support it, sucessfully?

I could go with D* or E*, it seems like people here are leaning toward E*, is that still the consensus? Pro's con's? E* converting to H264?

[dbfresh23]

Originally Posted by gregkovacs

I'm getting ready to build a system, and for the longest time, I thought I was going to use BeyondTV, BUT... this thread describes what I've been searching/waiting for forever!!!

What are the latest/most severe problems you guys have run into?

What about H264? Does 5.1 support it, sucessfully?

I could go with D* or E*, it seems like people here are leaning toward E*, is that still the consensus? Pro's con's? E* converting to H264?

You should read through this thread as I believe all of you questions are answered in it.

[NEOSG]

Anyone using UNC paths for the recording path for an R5000? When I did it, it worked AOK as far as the acutal recording. But if I tried to watch a currently recording stream, the R5000hd.exe app started using up a rising amount of CPU resources until eventually I hade to force it to stop. I mentioned this to nextcom support and I got the impression that they felt it was a non-issue.

[Kirby]

Are your UNC paths to local drives (local to the R5000 and server) or going out over the LAN? I couldnt get reliable recordings going over the LAN to a file server with UNC paths, but my local drives are setup as UNC paths and work fine.

[NEOSG]

Thanks Kirby. They are local to the sdage server that the R5000 is installed on. I haven't tested it again since build c, but since your reporting things working AOK, I will try them again. It is entirely possible it is just something quirly with my setup.

[Kirby]

I just checked my setup (new server) and I didnt set them up as UNC's this time for whatever reason. I know I was running them before as UNC, so I can try switching them back to UNC and re-verify it, but I really am quite sure I didnt have any issues before so long as the directory was actually a local directory.

[Jesse]

Hi,

Am I correct in assuming that the SD recordings with the R5000 would be better than the standard STB-->Tuner Card setup? I am guessing (hoping) that eliminating the whole encoding thing will result in a better picture.

TIA

[Kirby]

Originally Posted by Jesse

Hi,

Am I correct in assuming that the SD recordings with the R5000 would be better than the standard STB-->Tuner Card setup? I am guessing (hoping) that eliminating the whole encoding thing will result in a better picture.

TIA

Yes thats correct. If you set the R5000 DVR app to compress mode, no null packets are recorded, and you will capture true MPEG2 files in their smallest form. You are recording the stream as sent from E* or D* or whatever provider. You will get a better picture, in fact its the best possible picture you can hope to achieve, much like firewire recording of HD from cable boxes, or OTA HD captures.

[Ralphjb]

Originally Posted by Jesse

Hi,

Am I correct in assuming that the SD recordings with the R5000 would be better than the standard STB-->Tuner Card setup? I am guessing (hoping) that eliminating the whole encoding thing will result in a better picture.

TIA

I read the previous post. I have no doubt that theoretically this is true. But really, I can detect no improvement in picture quality on SD material. I think this falls under the garbage in, garbage out category.

Don't get me wrong. I love the integration of the r5000 with SageTV. Love it! Huge fan. When I bought the R5000 all those years ago, I was hoping for this integration.

But I would not do this for SD stuff. HD, yes. SD no.

Just want to clarify. I do now use the R5000 tuner to record SD stuff. It is very convenient, and there is no reason not too. I am just saying, buy the R5000 mod for its ability to record HD, not because of any meaningful improvement in SD.

[Kirby]

I know of nothing on the consumer level that can real-time encode to the same picture quality as the native stream. I use my R5000's for both HD and SD, and on my HDTV and setup, if you compare the native SD streams to those captured via a PVR card and re-encoded, its quite obvious which is which.

I guess do whatever you want to do in terms of capturing. But the re-encoding process done with a PVR card and standard outputs of a receiver is always going to introduce a PQ degredation of some sort, more obvious on some channels than others.

[Jesse]

Hi Guys,

Thanks to both of you for your input.

Ralphjb said:
I am just saying, buy the R5000 mod for its ability to record HD, not because of any meaningful improvement in SD.

Right on. No way would I spend the cash on this just to do SD. I am just hoping that improved SD will be icing on the cake. HD is my main interest here.

I have noticed that captures with a pvr card are somewhat inferior to the picture strait out of one of my DTV STB's. My wife still uses her Sony/M$ UTV for quite a bit of stuff. On our SDTV it is very dificult to tell the difference between her STB and Sage. On our HD plasma the difference is quite noticeable.

Improved SD is just further justification for what is otherwise an obscene expenditure.

Thanks again.

[Kirby]

Ok, I have my server really messed up in its configuration right now as I am moving files around between lots of recordings directories, had a show fire up to record on a networked UNC drive. I tried to play the file 10 minutes delayed, and got stutter after 3-4 minutes.

So I started monitoring the server via VNC, and started up a local recording, non UNC drive, and cpu stayed at 8-10% usage, and playback was fine for live tv. Switched to a networked UNC path, and after three minutes, the cpu usage had shot up to 50% and stuttering started. See attached JPEG.

If I play a recorded show from a UNC path, no issue, 1% usage. So something is definitely screwy with viewing live files from a network UNC path. What could it be? Its definitely not my network (gigabit ethernet).

[NEOSG]

Originally Posted by Kirby

Ok, I have my server really messed up in its configuration right now as I am moving files around between lots of recordings directories, had a show fire up to record on a networked UNC drive. I tried to play the file 10 minutes delayed, and got stutter after 3-4 minutes.

So I started monitoring the server via VNC, and started up a local recording, non UNC drive, and cpu stayed at 8-10% usage, and playback was fine for live tv. Switched to a networked UNC path, and after three minutes, the cpu usage had shot up to 50% and stuttering started. See attached JPEG.

If I play a recorded show from a UNC path, no issue, 1% usage. So something is definitely screwy with viewing live files from a network UNC path. What could it be? Its definitely not my network (gigabit ethernet).

Praised the lord, I'm not crazy ;-) Remember me mentioning this. Not that i wish any hassles on you kirby I tested it again with build 24c, and it is still happening. The gang at nextcom thought that this was a non-issue. perhaps if you mention it also they will realize it is AN issue.

[Kirby]

The problem is that I dont know if its for sure an R5000 issue, and not a Sage network encoder issue. The reason I say that is because the R5000 app didnt change, it wasnt the application causing the CPU to shoot up from what I could tell.

[dbfresh23]

Just an idea, but why not try copying some random large file to that UNC path while also watching a recorded file. This should at least tell you if it's an R5000 issue. If it stutters then it's safe to say that it's not an R5000 issue.

Another thing you can try is to add an entry to your Windows hosts file and specify the IP of the UNC host - this should make finding it a bit faster when your server is writing to / reading from it.

[NEOSG]

Originally Posted by dbfresh23

Just an idea, but why not try copying some random large file to that UNC path while also watching a recorded file. This should at least tell you if it's an R5000 issue. If it stutters then it's safe to say that it's not an R5000 issue.

Another thing you can try is to add an entry to your Windows hosts file and specify the IP of the UNC host - this should make finding it a bit faster when your server is writing to / reading from it.

Thank you for the ideas. The UNC paths I use are pointing right at the local server itself using it's IP rather than hostname. For example, \\serverIP\share So, that rules out DNS. Also, the sage server is also the storage server used in the UNC path. So, essentially, it is pointing to itself. Also, writing to those same drives using the drive letter works AOK. Writing to those same drives using UNC and a different encoder/tuner works AOK. It is only with the R5000HD app writing to a local UNC path and trying to watch a file that is currently recording, that the R5000HD app cpu usage gets so high that the stuttering starts to happen. If I write to the same drive via the R5000 app using the drive letter everything is AOK. So, that should rule out the drive itself, right?

It is so wierd. It only happens if writing to the UNC path AND trying to wath while it is recording, that the R5000 app cpu usage creeps up and up untilt he show becomes unwatchable.

keep those ideas coming. one of them will point us to the cause
FYI, the reason why I want this to work is so that I can use comskip files and such and not have to map drives on the clients.

[Kirby]

I noticed another odd thing the other night. I have a storage server, sage/r5000 server, and a few clients. If I watch a show, already recorded, from the storage server (import directory) from my client on my desktop pc, both of which are connected to the same ethernet switch (sage/r5000 server is on another switch, connected via gigabit ether), why does the program stream down to the sage server, and then back up to my client? That seems counter-productive, not to mention using up bandwidth when its not needed.

Can the client itself not view the file directly, after getting its location info from the server?

I'm going to try setting up another network encoder (cable box) and see if it does the same thing going to a network UNC recording directory. I seem to recall it does from my past setup.