R5000-HD capture via USB2 & SageTV

[Kirby]

Originally Posted by jlindborg

Cool - let me know what live TV is like streaming to a client if you can. I don't have HD coming off the dish yet so it's not a switching between SD/HD issue. I've tried two clients across my gigabit hard wired network and both have the same exactly problems - I suppose I can try playback on the server itself, although it's tucked in a closet with no monitor on it and you can't see video via VNC so that'll be a bit of a PITA.

Clearly bandwidth is not the issue since full OTA HD stuff plays flawlessly on both clients either live or recorded. Also my analog 250s are making 2.4 gig/hour files compared with the 1.2 gig/hour the r5000s are so I wouldn't think that's the issue. Can't think for the life of me what the problem would be with live TV - even shifted (I let the Mariners game record for 30 minutes before playback and it's _still_ jacked up - but if you wait for the recording to end it plays just fine). Very annoying...

Either way - I'll keep reporting the issue to both parties involved and hopefully some resolution will be found.

EDIT: Oh, and if you get a chance, try whipping back and forth to the "edge" of the recording program with the remote while it's recording - one of my clients _really_ doesn't like this and takes a bit of a nap while you watch the Sage logo spin...

I'll let you know what I find out. Question, on your server, you have 1GB of ram. R5000's are memory hungry, requiring 512MB by itself. Have you looked at ram usage when you are trying to play time shifted or live tv? And also, can you play a file once it is recorded, but the r5000 is recording another show?

Just wondering out loud if its a memory issue. I suppose there is also one other thing that could be of issue. You guys are all actually running a version later of the r5000 DVR than I am. I will upgrade mine tomorrow and see if it changes anything.

My brother's setup is playback via a client, over 1gbit ether. So that will be a good test. I've also used my client over 1gbit ether without issues, but just to a PC monitor. The only issues I have still are playing back MPEG4 streams from Dish, but thats a whole other ball of wax..

I'll keep you posted with what I find out.

[GKusnick]

Originally Posted by Kirby

Furthermore, I wouldnt suggest that bad mouthing Nextcom is appropriate.

Depends on what you mean by "bad mouthing". I agree that trash-talking is not called for. But I hope that jlindborg will continue to report honestly on his experiences, negative or positive, with Nextcom tech support. As a prospective buyer, I want to hear all the viewpoints, not just the favorable ones.

[jlindborg]

Hmmm... no, I haven't checked memory usage - I'll stick a memory monitor on there and chart it and try some scenarios. I can't say for sure if I've played a complted recording while another r5000 session is recording - when I get back home I'll run through some scenarios and see what it does. If it's just am atter of adding more RAM, I'm all over that...

[stanger89]

Kirby, checking on Dish Network won't really answer the question, they use standard DVB (and DVB-S2 for the new MPEG-4/HD stuff). DirecTV uses their own protocol all around. That's why the the 169time product can't do SD on DTV and I believe also why Nextcomm didn't/couldn't do it on DTV for a long time as well.

[Kimper]

I am holding off on buying because somewhere along the way it dawned on me that the only HD stuff I would really sit down and watch is from the big 3 broadcasters (abc,cbs,nbc) that I get OTA anyway.

No matter how awesome it looks, I just can't imagine sitting down and watching a show about Desert Lizards...

So, holding off a while. Now if I could get fresh Battlestar Galactica in HD I might convert to dish just for that. But I have yet to figure out who has the Sci-fi channel broadcast in HD?

[BobPhoenix]

Originally Posted by Kimper

Now if I could get fresh Battlestar Galactica in HD I might convert to dish just for that. But I have yet to figure out who has the Sci-fi channel broadcast in HD?

UHD broadcasts them in HD but they are about a year old so not new.

BobP.

[Kirby]

Originally Posted by stanger89

Kirby, checking on Dish Network won't really answer the question, they use standard DVB (and DVB-S2 for the new MPEG-4/HD stuff). DirecTV uses their own protocol all around. That's why the the 169time product can't do SD on DTV and I believe also why Nextcomm didn't/couldn't do it on DTV for a long time as well.

Right, my brothers setup thought is DirecTV. And it works. Just got back from there. And I agree, DirecTV will always have that issue, unless they ever change to standard DVB, which they couldnt afford to do. 18+ million box swaps at minimum to get DVB compliant.

[techtom]

Originally Posted by jlindborg

First and foremost is that you cannot get [Directv SD] recordings done with the r5000 encoder to play via the MVP - the sound plays (badly) but no video. If you process it with VideoRedo and clean it up, it does play then. I have a background process bascially cleaning up all my r5000 recordings for this reason which is a tad annoying. Also annoying is the lack of response from Sage (two reports, no reply) and the constant refrain of "it works in all our viewers here" from the NextComm guys..."

The problem is with MVP (and directv). To get the lowest bit rate, Directv use variable GOP structures (vs. Fixed IBBPBBP...)which is confusing to some players. Variable GOP is why the resulting quality is better than "DVD long play" recordings yet only half the bit rate. Video redo probably changes the structure to a DVD compatible GOP structure which will play on anything. The R5000-HD does not touch the video at all, it just packages it in an Mpeg-2 transport stream. The video in the transport stream and the transport stream itself is ISO 13818 spec compliant.

-Techtom

[techtom]

Originally Posted by dbfresh23

OK, I now have basically every H.264 file I've thrown at SageTV playing perfectly fine EXCEPT for the R5000-HD sample. I even have Nero H.264 HD and SD AVC & ASP files playing fine (The sample/trailers I downloaded from their website). This is after emailing SageTV support and getting some extra info for DeMuxing.

Sage TV has a problem with H.264 in a mpeg-2 transport streams. Your samples are either h.264 elementary streams (Annex-B, NAL format wo/audio) or ASP (AKA mpeg-4 part 1 systems, .mov, quicktime format).

I created the following test case (for kirby). I downloaded the nasa 720p h.264 clip from the Apple HD web site. The clip plays in any h.264 capable player. I demuxed the clip into h.264 video and AAC audio, converted the audio into mp3 and remuxed the video and audio into an mpeg-2 transport stream. The resulting clip is spec compliant, but not all players would play it. CoreAVC didn't work at all, Videolan's VLC had audio problems, SageTV couldn't play it either. Windows media player and Graphedit (if I renamed it from .ts to .mpg) played it perfectly. Elecard w/AVC plugin played it perfectly, regardless of the extension. BTW I've installed the Cyberlink AVC codec support for hardware assisted H.264 playback w/ATI Radeon X1600.

The problem is with the selection of the demuxer. The microsoft directx mpeg-2 demuxer does not handle h.264 video streams correctly. If I rename the remuxed clip to .ts, graphedit will render the graph using the microsoft mpeg-2 demuxer and the resulting graph will not play. If the remuxed clip is renamed to .mpg, graphedit will render the graph using the elecard mepg-2 demuxer, which does understand h.264 video and the playback is perfect. The resulting graph uses either the elecard avc decoder or the cyberlink AVC decoder. Both work, but the cyberlink uses the avi hardware and can playback 1080i clips.

If sageTV is using the directx mpeg-2 demuxer to build its playback graphs, the demuxer will flag the video incorrecly and the resulting graph has no hope of working...

-Techtom

[techtom]

Originally Posted by dbfresh23

Yeah, tried that. It [r5000-hd h.264 SD sample clip] actually makes TSReader crash.

Turn off the "thumbnail" preview window and it won't crash.

From Rod Hewitt (the creator of TSR), "I am looking at a new decoder BTW – the current one is the reference decoder and it’s slow and crashy!"

I'm sure Rod will have it fixed soon. He's very responsive.

-Techtom

[jlindborg]

Just a follow up with some more testing. The memory thing wasn't it - as a test I got three recordings going at the same time (one HT OTA, one on the 250 and one with the r5000) and the played back a pre canned r5000 recording and it played back dandy - I watched it for about half an hour with no burps. The memory still showed something like 200 meg not in use - no page swapping in sight.

Watching the Mariners game yesterday it was better than usual (and not just because we managed to squeak out a win with highly questionable pitching) - I let it start recording and about an hour into it started playback. Over the course of the 3+ hour game I only noticed two stutters - but these are hard to miss. It doesn't just drop a frame, it stutters and then seems to play in "slow motion" of sorts for a bit and then smooths back out on its own. But this is better than I've seen it before. It's important to note this is _not_ in the recorded file - if you go back and view that section again it's smooth. I never notice such behavior playing finished recordings.

I also installed a client on my big game box (2 gig of ram, ATI X850, 3800+) and played with some live recording scenarios yesterday - I was able to make it a bit happier selecting a live playback option by putting a big delay in the properties ini file for the network encoder - 8 to 10 seconds seemed to be necessary. It never just locks playback like this. However I was still seeing very noticible stuttering for a while and then it smoothed out a bit later. I didn't watch any one show for more than about 10 minutes so I can't say if it sutters now and again later.

However, it did occur to me that perhaps the background processing with VideoRedo is having an effect - although it's copying the file and processing it on another server and then copying it back - and it's _supposed_ to only try and process the file if the recording is done - however I did catch it launching a process on a currently recording r5000 file yesterday. It fails, of course, and shouldn't affect anything but you never know about these things. So for today's game (recording as I type) I've shut down that 2nd server with my comskip and VideoRedo cleanup jobs on it and have checked to see that no other recordings for the other two devices are going to kick in till after the game. I'm heading up stairs to watch what I hope will be a 2nd series win in a row...

[jlindborg]

OK – good game (any win is a good win, after all) and the viewing on the r5000 was just about flawless with no other hard drive activity going on. I’m only noticing a couple of consistent issues.

1. If you crank it out to “live” with the remote, it does still pause and occasioncally stutter while it catches up. Reminds me of the old MVP integration days before it was native in 4.1 – you have to let it get a few seconds ahead. But it always smooths out. I saw no spontaneous sputters during the entire main 3 hour broadcast.

2. Several times I noticed that if I did skip forward 1 (10 seconds) it actually moved _Backwards_ in the show. I thought I was just having heart palpatations after my boys left men on the bags yet again but I noticed it 7 or 8 times during the playback - it only happens the first time you hit it after it's been playing a while and subsequent hits all work correctly - and large forwards never do it (or perhaps they move forward less than they should but you don't notice it - I can't tell). Something seems a pinch funky about the file position changes here.

3. As the show transitioned to the after game recording (I always make sure to record the show following the game in case it goes over) there was about an 8 second “no signal” notice (which is expected – there’s a wind up period for the r5000 which will always be there) and the playback following that did stutter several times and play “Slow motion” again and then smoothed out after a minute. Again, the recording itself is fine if you go back and look at it. Not the end of the world but the “no signal” came right after our struggling closer gave up a lead off double in the 9th! Not ideal… man alive - my kingdom for a decent closer again...

So assuming the live playback performance was better because there was no other activity on the HD (remember, comskip and Video Redo are running off box – the CPU on the main server rarely bounces up over %20), I guess the question is why the r5000 recordings are so much more sensitive to playback bobbles like that – I’ve been running 3 recording sources in that same rig (3 250s and then 2 250s and an HD OTA receiver and now 1 250, 1 r5000 and 1 OTA HD) for about 18 months no and never had a single playback issue till now – live or otherwise. I still don’t with either of the other sources. I even had the HD card in another box for a while - there was a pinch of a delay at startup but never a problem during playback.

I’m not willing to just shrug my shoulders and let the dodgy live playback at the edges go… I’m still leaving the 250 as my lead off hitter for live recordings – it’s much snappier and never has an issue. Ever. Not at the edges and not during recording transitions (just a quick 2 second flip at most), it’s very reliable. I’m also turning off processing with VideoRedo but I have comskip back up and running. I’ll just not watch on the MVP for now – I don’t use that viewer much these days anyway. I'll continue to report the MVP playback stuff to Sage - if the clients can play it and the server can play it, seems to me something can be done to deal with it on the MVP client. They may not think it's high enough priority to deal with but hey... I'll keep asking. I think the r5000 notes should explicitly mention the fact that this is a problem, however, since the MVP client was a big part of the recent 4.x Sage development push.

Someone asked me in PM if I’d buy the r5000 again – yeah, I would. It’s not ideal but the picture quality is great and the file size is very nice and I _do_ plan on getting HD going with the dish this summer – mostly for HD HBO as I get local fine OTA (besides, I don’t think I can get MPEG 2 HD locals here in Seattle – it requires new receiver equipment). If you’re going to jump on it, though, just make sure you understand it doesn’t play on the MVP without jumping through some hoops and you may experience somewhat more laggy live viewing responsiveness at the start of shows and on transitions – maybe not – maybe it’s just me and my bad karma but I doubt it very much.

[Kirby]

Originally Posted by jlindborg

1. If you crank it out to “live” with the remote, it does still pause and occasioncally stutter while it catches up. Reminds me of the old MVP integration days before it was native in 4.1 – you have to let it get a few seconds ahead. But it always smooths out. I saw no spontaneous sputters during the entire main 3 hour broadcast.

I get that sometimes too, however its not just the R5000 that it happens on. I have a DCT-6200 cable STB with firewire port, and that setup does the same thing at the leading edge of the program stream. Not always, but sometimes.

2. Several times I noticed that if I did skip forward 1 (10 seconds) it actually moved _Backwards_ in the show. I thought I was just having heart palpatations after my boys left men on the bags yet again but I noticed it 7 or 8 times during the playback - it only happens the first time you hit it after it's been playing a while and subsequent hits all work correctly - and large forwards never do it (or perhaps they move forward less than they should but you don't notice it - I can't tell). Something seems a pinch funky about the file position changes here.

Any idea how far back? I wonder if it is something with this line:

videoframe/time_behind_live_to_disable_skip_forward=4000

If you were say 5 or 6 seconds behind, and you hit 10sec forward, could that cause a jump back?

3. As the show transitioned to the after game recording (I always make sure to record the show following the game in case it goes over) there was about an 8 second “no signal” notice (which is expected – there’s a wind up period for the r5000 which will always be there) and the playback following that did stutter several times and play “Slow motion” again and then smoothed out after a minute. Again, the recording itself is fine if you go back and look at it. Not the end of the world but the “no signal” came right after our struggling closer gave up a lead off double in the 9th! Not ideal… man alive - my kingdom for a decent closer again...

The "no signal" is because it was tuning into the next show. I have mine set to always tune channels (due to changing issues on my firewire setup) I wonder if it would tune at the change-over or not, if that setting wasnt set. Probably a better option is to just extend the recording length by 30mins or 1hr or something. My average change time on Dish is about 10 seconds, and on cable its about 12 (because we had to slow down the channel changing on my cable box, and bypass its power-sense setting).

So assuming the live playback performance was better because there was no other activity on the HD (remember, comskip and Video Redo are running off box – the CPU on the main server rarely bounces up over %20), I guess the question is why the r5000 recordings are so much more sensitive to playback bobbles like that – I’ve been running 3 recording sources in that same rig (3 250s and then 2 250s and an HD OTA receiver and now 1 250, 1 r5000 and 1 OTA HD) for about 18 months no and never had a single playback issue till now – live or otherwise. I still don’t with either of the other sources. I even had the HD card in another box for a while - there was a pinch of a delay at startup but never a problem during playback.

I've had 2 r5000 HD streams writing to the same drive, and playing back another from same drive, all over a 1gbit ether connection without issue. However I have been having network issues the past week or so (sage server seems to fall off the network for no reason, no errors, and then comes back after a minute) so I have put 2 drives into my server for recording to.

I'm glad you are making some progress on getting things working better. As for the stuttering audio at the edge of a live playback, I had dismissed this as a Sage issue, since it happens on using Anders' UNE for firewire boxes, but maybe I just have something set wrong on both systems?

[jlindborg]

Yeah, I thought about the skip forward thing being related to being near the end of the file but most of the instances I saw that with I was a good 30 minutes back or more so that's not it. At least not all the time anyway.

It'd be nice if the skip ahead had a setting that would always leave X seconds in the buffer no matter what - that particular setting is fine if you're right close to the end but if you're, say, 20 seconds back and hit skip ahead 3 minutes then it rams it right to the end of sputters - if you could tell sage to never get closer than, say, 4 seconds from the end I'm betting that would help with some of the "edge case" problems.

So you never see any stuttering after a live show starts playing (after the "no signal" and/or the spinning Sage icon)? It's pretty consistent for me on all my clients. I'm tempted to haul an LCD screen into the wiring-closet-of-pain and verify if it happens directly on the server as well just to rule out anything goofy with remote clients being involved...

[jlindborg]

Also interesting and possibly related - I've been comparing how the comskip files for the r5000 are to those with the 250s and I've noticed some discrepencies - I thought maybe comskip was having problems with the files since its debug mode chokes on the r5000 files now and again, but I don't think that's the case. If I open the file created by comskip for Video Redo the commercials are mostly spot on - however in sage they tend to "drift" by a few seconds - especially for long shows near the end. Not by huge amounts but you can notice it.

Gotta go thatch the lawn, I'll check more into this later tonight but I'm thinking this may be related to some sort of timeline issue Sage might be having with the files...

[Kirby]

Originally Posted by jlindborg

So you never see any stuttering after a live show starts playing (after the "no signal" and/or the spinning Sage icon)? It's pretty consistent for me on all my clients. I'm tempted to haul an LCD screen into the wiring-closet-of-pain and verify if it happens directly on the server as well just to rule out anything goofy with remote clients being involved...

No I didnt say that. I do sometimes get stuttering at the live edge when a recording starts. But its not consistent. Its not on any particular channel, or time of day, and doesnt seem to matter if the sun is shining in Berlin at that time or not either! My main playback is done from the sage server. If I pause the playback for a second, then start it again, it goes on its merry way.

[stanger89]

Originally Posted by techtom

I demuxed the clip into h.264 video and AAC audio, converted the audio into mp3 and remuxed the video and audio into an mpeg-2 transport stream.

Can I ask what tool(s) you used to do the H.264 into mpg muxing?

[Kirby]

jlindborg,

Can you tell me if you are using Overlay or VMR9? FSE enabled?

[jlindborg]

Yes, I'm using VMR9 and FSE on my main client hooked to the plasma - I've tried Overlay as well without FSE. Doesn't seem to make all that much difference. And fiddling with my over-powered game box those settings didn't do much of anything with respect to the stuttering and "slow-mo" effect when starting a live viewing.

[Kirby]

Well I was using VMR9 + FSE on my Nvidia 7800GT card on my sage server (also main playback machine) and if I tried to start on channel 6300 on dish (first of 20+HD channels in a row) and just did channel up, let it settle in for 30 seconds, and channel up again, over and over, I couldnt get through all the channels before things would screw up.

I changed out my video card this morning to do some H264 testing, to a ATI x1600Pro, and I just turned off FSE and went to Overlay, and I can change channels up and down randomly without issues.

I never usually watch programming in this fashion, usually I just find it in the guide and select it. But something definitely happened on my system to make this work in this fashion better.

When scrolling through the 28 or so channels, I would say that 1/3 would stutter briefly (5 seconds or less) then play fine. a couple channels would require a pause/play to get good sound. and the rest would sync right up or take less than a second to sync audio and not stutter.