R5000-HD capture via USB2 & SageTV

[dbfresh23]

Originally Posted by NEOSG

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.

Are you using comskip or showanalyzer/dirmon? If you are using dirmon try checking the box that indicates not to start on a file until recording has completed.

[NEOSG]

Originally Posted by dbfresh23

Are you using comskip or showanalyzer/dirmon? If you are using dirmon try checking the box that indicates not to start on a file until recording has completed.

Been there done that I actually only recently turned comskip processing via DirMon2 monitorring back on. I wanted to let things run "stable" for awhile, without comskip running all the time.

The current watching while recrding via R500HD app to UNC path, pegging the cpu issue was happening without comskip processing of files evening turned on.

but, good thinking

Tis next

p.s I certainly appreciate the fellow brainstorming

[Ron]

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).

I tried the same, i.e., recorded a show to a networked drive. Then opened up client and started playback after about 10 minutes of the show was recorded. CPU usage shot up to about 43% and after about 5 minutes of viewing, it began to stutter.

[NEOSG]

Originally Posted by Ron

I tried the same, i.e., recorded a show to a networked drive. Then opened up client and started playback after about 10 minutes of the show was recorded. CPU usage shot up to about 43% and after about 5 minutes of viewing, it began to stutter.

Thanks for testing. I am going to do another round of the "I'm not cookoo" dance

[NEOSG]

Here was my email back and forth with David at Nextcom.

-------------

I am using the lates multi-instance sage support build of 24c

If I am recording to a local machine but referencing the save to path in UNC format (\\<machine name of or IP address>\<share and path> AND trying to access the currently recording file (say watching live or slightly delayed TV), the R5000HD.exe process starts using more and more CPU and heavy studdering begins. it basically becomes unwatchable as the cpu usgae approchaes 100%. if referencing the save to path using a local drive letter, this NEVER happens

I have been able to reproduce this over and over again, regardless of the drive type (SATA, PATA, USB, FIREWIRE) that the UNC save to path is located on.

I was wondering if you could

a. try and replicate it and let me know if you experience the same thing
b. If you can, please add it to the list of bugs to be squashed.

if you would rather I post this to the avs forum thread or sagetv threads, just let me know.
thanks,

Scott

--



r5000support@nextcomwireless.com
to me
More options Jun 2
Scott,
You need to have a system with quite a bit of horsepower to accomplish stutter-free simultaneous playback of HD streams using software. Typically you would expect to see the CPU maxing out, most of it from the DirectShow components. We can't duplicate what you're describing (no difference in performance between UNC format specifier). I would recommend breaking the processes apart, e.g. measuring your CPU usage while only playing back an HD stream and while only making a recording (specifying both UNC and local drive formats). You can then also try simultaneous recording and playback but of 2 different files.

The only thing I can think of is that by specifying a network path or IP address you're somehow reading and writing via the TCP/IP stack which is adding unnecessary overhead. If that can be confirmed, then you just have to avoid doing it, the behavior is by design, not due to a bug. Thanks,

David

------

Sage gang,

Any thoughts or opions on David's response

[camTexas]

Sounds like a punt to me... I can record two HD programs and play back another all day long with my 2-R5000 units and I only have an Athlon64 2800 (using 7600GS) with 1G memory and no stuttering. I'm rebuilding my system right now so don't want to potentially break it switching to UNC paths but I will check this out after I get all configured and backed up correctly. I'd like to go UNC in the future as well so we need to figure this out.

[Kirby]

Of course the easy answer is to not record to UNC paths... And my new server is going to do just that. I have 320GB for live recording, and about 3TB for offline storage. Its pretty easy to unload the 320GB every few days if need be. So with that said, I am going to keep trying to figure out what the issue here is, but at some point I am going to stop worrying about it and do what works.

[stanger89]

Sounds like he doesn't get that you're doing playback on a remote PC.

[Kirby]

David has a full report from me in his hands as of this afternoon. So we'll see what he comes up with, but I still think this is possibly a network encoder (general) issue, possibly JAVA related, or Sage related. A network encoder is just supposed to send bits to Sage to write to disc right? Why should it care if Sage decides to write those locally or to a remote UNC path? Short answer, it shouldnt. Its going to be a real PITA for me to setup my cable box firewire network encoder again, as I was getting ready to return the box to Charter, but I guess I will have to do so.

And the comments from David in the above email about loading up the TCP stack seem to make some sense, as it seems that there is un-needed TCP usage when playback happens. With my one client, and the library being on the sage switch, when the client plays a file on the library computer, all the data is streamed down to my Sage server, and then back up to the client. I dont know if thats because Sage needs to keep control to know whats happening on that file in case multiple clients start to access it? I really dont know. But it seems like the server could initiate the playback and then let the client and library computer play on their own. Maybe file locking wont allow that?

[Kirby]

I just tested it again. Started watching a live recording, and after about 20 minutes I finally got stuttering. However, and this is the key, 15 minutes into playback, the r5000 app was at or above 40% cpu usage, and the sagetvservice.exe was running 0-4%. Then the service app started to creep up in percentage, and finally at the stutter point, was over 25% cpu usage. Something is definitely up, could it be the network encoder protocols passing between the encoder and the service app causing the issue? Java related? It does not appear that high cpu usage alone by the r5000 app is causing this, as I just determined on my system here.

[stanger89]

Might want to run that past Sage, somethings not right if the Sage CPU usage is rising too.

[NEOSG]

New test. haven't done this yet but will asap

In my sage.properties I reference the R5000 encoders using the loopback address 127.0.0.1 . But, when I tried UNC paths for storing the recordings, I used the regular NIC IP of in my case 10.250.10.100 \\10.250.10.100\sharename

i wonder if there would be any difference if I used 10.250.10.100 (the local sage server where the r500 is installed) in the sage.properites file rather than 127.0.0.1 \\10.250.10.100ortnumber


I will test this as soon as I can later today

[NEOSG]

This last test did not change anything. R5000hd process still shoots upwards north of 75% cpu usage and casues stuttering

[Kirby]

But what happened to your sage .EXE usage at the same time stutter started? was it high as well, or down near 0?

Another useful test maybe, start recording to a UNC path, and then open up the recording file in another media player, such as WMP? Does that cause the R5000 app to spike?

[NEOSG]

i'll check it out again later tonight when I am at home. I already flipped things back to not using UNC for the R5000 encoders. Things get so slow remotely that it is a pian sometimes. I'll also add the client into the test mix tonight. So, I'll try the UNC paths with recordings and monitor sage.exe on the client, sagetvservice.exe on the server, and r5000hd.exe on the same server.

Along with trying to access the file via another media player while it is recording via r5000hd.

I'll let you know how things go later.

[Kirby]

I found another thing that can make the cpu usage of the sagetvservice.exe file spike. Open up an explorer window to the UNC path while its recording, and watch it go boooooooooooooom!

I'm going to try some other tests on this, including:

1) setup a UNC path to a drive on linux/samba to see if the remote location OS has any bearing on this
2) try to access the recording from WMP, MPC, etc
3) setup my DCT-6200 firewire setup again (ugh!) to test its behavior to a remote UNC path
4) put the r5000 on a different computer than the server, and see its results.
5) get a big club and start swinging at various objects in my line of sight, just for the pure pleasure of it!

[NEOSG]

Originally Posted by Kirby

I found another thing that can make the cpu usage of the sagetvservice.exe file spike. Open up an explorer window to the UNC path while its recording, and watch it go boooooooooooooom!

I'm going to try some other tests on this, including:

1) setup a UNC path to a drive on linux/samba to see if the remote location OS has any bearing on this
2) try to access the recording from WMP, MPC, etc
3) setup my DCT-6200 firewire setup again (ugh!) to test its behavior to a remote UNC path
4) put the r5000 on a different computer than the server, and see its results.
5) get a big club and start swinging at various objects in my line of sight, just for the pure pleasure of it!

Try the cookoo dance. It really helps

[NEOSG]

i will say, all in all, you gotta love what the R5000 paired with Sage give us.

I am anxiously awaiting sage H264 support for the r5000HD H264 files.

Also, I would like to figure this UNC issue out, just to cross it off the list.

[Kirby]

Ran an interesting test last night. Had a live show recording, and started up the web interface plugin by nielm, and started the file streaming back to the PC via VLC, and cpu usage never went above 8%, and r5000.exe never above 4%. So, does that mean anything?

*edit* I forgot to mention I was also able to play the current recording from a client machine via WMP, Nero Showtime, Media Player Classic, all without any surge in cpu usage on the server. So what does the Sage Client do when its viewing a file? Is there some sort of call from the client checking for file size that could be causing this issue, bundled with some sort of TCP/IP stack bug from MS? Maybe the network encoder is getting flooded with file size requests to the point that it cant cope?

[GKusnick]

Can someone who owns an R5000 clarify something for me? If my DirecTV receiver has an OTA tuner built in, will the R5000 capture those OTA channels, or just the satellite channels? Or am I better off with a separate OTA tuner card anyway?

Also, does anyone have recommendations for specific DirecTV receiver models to use for this purpose? I've seen the compatibility list on the Nextcom site; I'm just wondering if there's any reason to prefer one model over another on that list.

Thanks.