STB Firewire (IEEE-1394) Support

[DFA]

Travisbell:

"There was a Playback Error in payback. Details:
sage.PlaybackException: ERROR (05,0x80004005):
There was a problem rendering the audio portion of
the content for playback."

Welcome to my world!

I know this one very well. When we have an update to SGR, I hope for it to go away or to drill down to the source of it. I have not yet determined if it is the SGR graph, audio codec or a Sage filter (Sage problem). I have tried enough audio codecs to all but eliminate that as a source. I have been using a different fllter combo and have started but not quite eliminated that; pending the SGR update. I also plan on replacing some of Sage's own filters with earlier filters from 2.0 era to see if that is the source.

It occurs for me after first going to the SGR encoder (OK on first use and continued use even with mixed SD and HD channel changing) then going to PVR-250 then back to SGR encoder. This is when it happens; on the second visit to the UNE. I know the graph itself is not hung because if you check the video directory, you will see the right file name and growing in size (recording) all the while Sage is displaying the error. It can be remedied by shutting and restarting SGR. The restarting of the SGR resets the dump filter file name to the "dummy" startup name which I have decided is a clue to the source of the problem. I'm fairly certain that it is NOT an SGR problem. I have talked to Anders about it at length and he has pretty well eliminated it as an SGR issue. However, we have discussed what might be done with the SGR to work around the problem even though SGR seeming not to be the source of the problem. One work around was for SGR to "reset" the graph so the dump filter file name goes back to the "dummy" since this seems to make Sage happy. It may yet come to that.

Your help will be appreciated on this. Right now, I think "guys" is you and me. I was not sure if it was going to be with just my system or more pervasive. When I was analizing the STB TS streams with TSReader, I noted that in general, the HD streams are AC3-5chan and the SD streams are AC3-2chan. It may have something to do with filters changing gears for the two audio types. Just yet don't have this pinned down. With a different graph combo I have been experimenting with, it will never happen if I stay on SD channels and can switch back and forth with encoders w/o issue. As soon as an HD channel is put in the mix, cycling encoders causes the error. Different behavior of the problem with diffierent graph.

Note that Sage has had very little HD usage to date so not much user experience on this. We may well have a few things to solve that are Sage issues and will take some looking at by Frey. If a Sage problem, we will have to pin it down to report to Frey.

The forth coming SGR update that will allow us to side step recording (mask) the STB channel change stream transition discontinuity I hope will help to clear this up or at least help identify the source by eliminating a possible source.

Thanks for Moto vendor ID. What is full Moto model number, unabridged?

Dane

[DFA]

Driver/INF STB capture package now updated to include section for Moto DCT-6200. See Post #74.

DFA

[DFA]

Travisbell:

Try the Sage dump in place of the CL dump and see if you still get the Sage audio renderer error.

Also, try setting this "sage.properties" parameter to this value:

videoframe/network_encoding_to_playback_delay=4000

Might try it at much more or much less to see if any impact.

Might also try this:

seeker/fast_mux_switch=false
(or vise-versa)

Let me know.

Dane

[travisbell]

Just played around with it for a few more hours. Tried every single combination I could come up with. Sage does seem to want to play again, but it's after a significant period of time (5 to 15 mins..). When it does come back in though, it starts playing where the live recording left off, so for example I was 15 mins out of sync with the live feed.

I tried the two mods you put up, it didn't seem to change the behavior. I am going to keep digging with this one.

Let me know if you discover anything to help

[DFA]

Travisbell:

I have found this as well: Sage seems locked up at 100% CPU but as long as 15 minutes later, it takes off like everything was just fine.

The symptom is that as long as the encoder (graph) is running, a file is being written and when you are viewing live TV, going to different channels, a new file is always being opened for each channel even when returning to a previously viewed channel, a new file is opened. When the graph is stopped, like when putting Sage in sleep and no scheduled recordings are going on, the dump filter retains the name of the last file it was recording. When the encoder is again called upon and the graph started, it is then when the dump filter opens against the file name it previously used that there is trouble. The dump filter may not like this because the filter is in "New" mode.

Here is a test you can run. If you put Sage in sleep and no recordings are going on, kill SGraphRecorder and restart. This will put the "dummy" startup file name back in the dump filter. Then wake Sage and I'll bet everything is OK. That might be because the "dummy" file does not exist on the HDD nor is the Sage playback graph trying to access the "dummy" file.

It could be because the Sage playback graph and the dump filter when restarting with the file name it last recorded are competing for the file or a timing issue in terms of access.

Also, for the CL dump, you'll find that for the properties, it can be configured for "New" or "Append". I have tried to put it in Append but have found that when I save and close Graphedit and then restart Graphedit and recheck the graph, the dump filter resorts back to "New". The setting will not stick.

That's the "what" of it. I do not yet know the "why" of it. These are symptoms but not necessarily the root cause.

Jeff did offer some assistance and I have not yet called on any. Perhaps this is where he might be able to help by providing a "why" so that it can be addressed. It might be as simple as a "sage.properties" parameter.

It will be resolved. I've done this rodeo before. If all else fails, we can ask Anders if he can write a "Null.mpg" file name to the dump every time the graph is stopped. That will fix it but leaves the question unanswered.

I will try to drop a note to Jeff and see if I can get his attention.

Dane

[travisbell]

That sounds great Dane. I certainly appreciate all your hard work.

if there is anything I can do aside from the obvious "second user testing" let me know.

Cheers,

[sleonard]

DFA, it's been a while but I've been waiting for Cox to update my SA3250. I think the update has been d/l to the box (I watched it do an update and the OS was upped to 1.2 from 1.0) but the PC doesn't see anything attached. No "New Hardware Found" message. Do you know if I can tell from any of the STB's info screens so I know for sure? I've looked at all 18 screens and nothing obviously concerns IEEE 1394. The only change I have been able to notice was the OS change on page 3.
If I can confirm that the box has the FW update then I need to be troubleshooting the PC and cable. Otherwise I need to call Cox again.

BTW, great job to both you and Anders. This has really moved forward and I'm going nuts not being able to play with this and help out. I also hope Jeff jumps on this and makes both F/W capture and channel changing native although I also like the idea of using the UNE to connect webcams, giving them a channel in the EPG.

[DFA]

Sleonard:

They may have updated the OS but they did not install IEEE-1394. If they did, you would have 19 diag pages and on the 19th page (titled "1394 Information") you would clearly see the details about Firewire. On page 17 (titled "Component Information"), you should see a summary of installed software totaling about 9 modules with "firebus" clearly being one of them. The fact that the PC finds no new hardware further confirms that the STB has no Firebus software yet installed.

Go back to provider and put on your "nasty" face. You've waited long enough and been patient enough. I usually go ballistic early on.

DFA

[AndersNolberger]

Version 1.0.5 is available on my web page as of yesterday. It supports a configurable delay before start of graph.

I dont think the fact that the old filename is left in the dump filter should do anything since the graph is stopped. I change the name before the graph is started again. But I could try to set it to something else to try.

[LaVike]

DFA, Anders, Travis,
Sorry I haven't been able to help at all on this. I'm still waiting for parts for my Shuttle. I will hopefully be trying this over the weekend provided my parts come in. I'd like to thank you all for your Herculean efforts.

The purpose of the email is that being an engineer (systems not software), it sounds like you all are at a point where Frey has to step up to the plate and get involved. Heck, they are getting Firewire HDTV and more capabilities that they can market. Setting filenames to various names and other such stuff to "fake" SageTV into working correctly is great, innovative, and smart. However, Frey should step up and help out. Its not really a consumer solution to the problem. It definately helps them identify where they need focus their efforts, but they need a solution for folks who aren't as smart as you all.

Just my $.02. and I wanted to say thanks for all the effort.

[DFA]

Travisbell:

Holy Cow!

Anders released an update yesterday that includes "Start" delay feature to accomodate the large FW channel latency. It is in the new "SGraphRecorder.ini" file with variable name "TuningDelay". Download now!

Not only does it do as intended, avoid having the graph run while the TS stream is in transition, it appears to have rectified the other issue with Sage giving an Audio rendering error when the graph (encoder) is stopped and restarted. This is preliminary, but I have made at least 6 consecutive encoder switches and no Sage hang!!!

I suspected this might be remedied along with the need to mask the TS transition. I believe that the SGR was simply too fast for Sage and causing some sort of timing problem. In the case of HW encoders that actually stop and start encoding, there is an inherent delay (latency) from when they get the "start" command and when a file is opened and a delivery of stream begins. This may only be a fraction of second I imagine but is enough for Sage to get its house in order. In the case of the SGR and STB Firewire, the stream is always available ("On") and without any controllable delay, when receiving the "start" command, the response is virtually instantaneous. I think this may have been somehow causing Sage to choke. I had noticed with all the testing, that I did not always get the "audio" error and that sometimes it would actually "go" and other times choppy video and hissy audio or Sage hanging suggesting a timing problem and something being on the "edge". Just a theory. Whatever the case, seems resolved! Time will tell for sure.

I am using 3000 msec for SGR "TuningDelay" and set the following "sage.properties" parameter to this value:

videoframe/network_encoding_to_playback_delay=4000

These values may not be optimal and perhaps can be pared down but the absolute minimum may vary STB to STB make and model.

Travis, give this a try as soon as you can and see if you are equally successful. This may now finalize the SGR.

THANKS ANDERS!!!!


PS: In this release, Anders has also added an "Enter" event which follows the channel digits being sent to Girder. This will help for faster channel changes for single and double digit channels. The "Enter" event is simply the "prefix text" without any number appended. For example: "Channel6" --> "Channel1" --> "Channel". "Channel" is the "Enter" event. Works good.
Dane

[travisbell]

I grabbed the new 1.0.5 and changed my SGraphRecorder.ini to look like the following;

FileName=TStoPS.GRF
TuningDelay=3000

This did not fix my problem. Damn!

I have been able to re-produce the problem by doing this (let me know what your results are);

- Start SGR
- Start Sage
- Tune into an HD channel, let it play for 30 secs
- Go "back" and put Sage to sleep
- After 30 secs, resume Sage
- Go back into Live TV and choose a different channel than you tuned into the first time
- Watch the error pop up

This will happen to me EVERY time. Definitely a dependable problem.

Thanks!

[DFA]

Travis:

Try this for "sage.properities":;

mmc/always_tune_channel=true
seeker/fast_mux_switch=true

Along with above, try reducing "TunerDelay" in "SGraphRecorder.ini" to 2500. I do not know your Moto latency, however.

Possible need to maintain this relationship for the Sage "videoframe/network_encoding_to_playback_delay" parameter:

videoframe/network_encoding_to_playback_delay => SGRTunerDelay + 1500

Understand I am not dealing in certainties. I have since got a few audio errors but am doing things I have not been able to get away with at all before. Still adjusting and checking and still very up beat.

EDIT:
Currently running like this:
SGR "TunerDelay=2750"
SAGE "videoframe/network_encoding_to_playback_delay=4500"

Working OK so far. Will sit back with this for a bit and absorb. My test is the successful switch back and forth between PVR-250 encoder and SGR encoder in conjunction with SD <--> HD switching.

DFA

[travisbell]

I modified my settings to yours, plus going up and down and if you do the steps I wrote down above, I still get the audio rendering error.

Do you get the audio error if you do those steps?

[DFA]

Travis:

I replicated your steps several times and could not reproduce what you are getting.

Have you set up an EPG and making channel changes thru Sage? If not, all bets are off. The SGR "TuningDelay" feature will only be of value when Sage receives the channel change command and SGR stops / starts the graph and delivers that change to the STB via Girder and to some Girder-compatable IR emitter (USB-UIRT in my case). If still making channel changes direct to STB, you'll definitly be getting the error due to the discontinuity not being masked. For that matter, for Sage itself to be of any value either, it has to get channel change info.

I would like to compare notes on STB perfomance. My provider is Brighthouse Networks. The STB make and model is Scientific-Atlanta 3250HD. The Firebus software revs. are as follows:

firebus = 2.5.7.1
fbdtcp = 2.5.3.1

VividLogic is the supplier of the Firebus SW for SA.

My take on VividLogic's product, as an analogy, is "Win 3.1" in a "Win XP" world. The channel change latency is problem enough but has been effectively dealt with. Beyond that, there is an additional 5 - 10 sec. period after the initial channel change stream transition for the stream to stabilize. During that period, the picture speeds up and slows down; rocks back and forth for 5 - 10 secs. until it stabilizes. Almost all of the time, the SGR graph and Sage playback graph deal with it. Once in a while, this period of instability causes the Sage error to occur for me. I have confirmed, to the best of my ability, that this instability, beyond the actual channel-change-stream-break, originates with the STB.

In short, any residual problems I am having are with the STB. I have been "nudging" my provider for a Firebus SW update if I am not running the latest. I have not had much luck in even figuring out what is the latest. Sleonard, who has been patiently waiting for his provider to DL the Firebus SW to his box, I hope and assume will get the latest. I am interested to see what version his provider installs when finally doing so.

UPDATE: It seems that setting the "clock" active in the MS DeMux helps a great deal with post channel change instability and "rocking". Needs to be added as a footnote to building the graph.

DFA

[DFA]

CALLING ALL MUX's

I have now begun to focus on "fine tuning" the graph a bit. I think the graph is good up to and including the MS DeMUx. I'm not so sure about the CL Mux. I would like to try others. Does MS include a Mux in MCE 2005? If so, I would VERY much like to try it; any other candidates as well. PM me if you have something for me to try.


Everything is working reasonably well for me at this point. I have had to abaondon VPP and drop the use of VMR (now using Overlay). While my 9600XT was a good balance between heat and performance for VMR in SD, it seems a bit anemic for VMR in HD. That puts me in the market for a video card update. I have followed some of the comments about the latest crop of nVidia cards but remain confused as to the bottom line. Graphic card recommends also gratefully accepted. Heat and fan noise is a consideration and refuse to give up an adjacent PCI slot.

Dane

[Naylia]

Dane,

You may want to check out the 6600GTs with native component out if you're looking to upgrade your card. They're in the low $200s. I'd check out HTPCnews.com for advice on brands and more specifics.

On a more relevant note, I went out and got a new moto box and will be downloading Sage this weekend due largely to yours and the others in this threads effort. Hopefully we can get some more people working this and get it sorted out, but I agree with LaVike that Frey should step up because they could probably take this and run with it and have a patch out in a couple weeks along with instructions on how to build your own graph. I'll try to document the process I follow from start to finish to create a mini howto summarizing your instructions.

[DFA]

Thanks Naylia.

It seems to now be worked out fairly well thanks to Anders last update. Just the possibility that a different combination of filters might be discovered that better suit the STB FW application. As is now, doable and acceptable. I particulary enjoy the "inHD" channels. The DTCP issue takes some of the enjoyment out such that constancy is not guaranteed. Till something better comes along, better than nothing I feel.

It might be advisable to get the box, install the capture driver posted earlier in this thread (Post #74 I think) then build a graph which renders to screen (no mux or dump; I had posted a JPEG of one somewhere but can post again if requested). That way you can evaluate what you have available and signal is OK, etc., etc. before putting out any money.

Dane

[travisbell]

Ah yes, I have not got Girder (or any other blaster) working yet. I have been having a tough time finding out more info for the MCE remote. It seems like no one has developed any 3rd party add-ons for it. FYI -- MS has posted a great deal of info on it here, http://msdn.microsoft.com/library/de...te_control.asp

Question: How bad is the lag when you change channels? On my regular STB I can flip through pretty quickly, maybe 750 msec's between my command and STB reacting. In Sage, when I "pretend" to change channels (just hit the ch + button) it takes a good 4 seconds to respond.

I think I have other questions, but they seem to have left me for now...

Thanks Dane,

[DFA]

Travis:

It is not very quick. About 4 seconds. There may be room for improvement, particulary if it can be indentified what Sage is having trouble with. It can not be reduced beyond a cetain amount of inherent latency that is built in.

FW channel surfing will not be a lot of fun but no issue for recordings. Small price to pay for HD recording in my opinion.

DFA