STB Firewire (IEEE-1394) Support

[DFA]

Spaceghost:

This all began when I started experimenting with the STB FW as presented in the AVSForum thread. While a good starting point, I found actual usage to be a bit primitive; like rubbing sticks together to get fire (the last time I checked that thread, the sticks are still rubbing). This does not mean I am putting CapDVHS down or belittling those efforts. Just way too inconvenient and not even on the WAF radar screen. The need for it to go to a higher level to be useful was apparent.

When I started this thread, the UNE did not yet even exist, it was just a gleam in my eye. I had been experimenting with graphs and the STB FW capture device and Sage playback capabilities and knew it could be done. Originally, I gave thought to a network encoder "applet" that would use Graphedit itself as the "recorder". I also thought that what Anders had developed for the DVB card was adaptable. It was indeed close to what was needed and did not take him long to "Universalize" it and add Girder support. Praise to Anders and many thanks. I did the beta testing and advised him of bugs and needed changes to make it work since he had no way to actually test it with a US Cable STB. (I have maintained a log of our transactions and is also quite lengthy). Finally, with the addition of the "TuningDelay" feature which put an end to the "Audio Rendering Error" problem, the UNE was a working reality and released. A rewrite, by yours truly, of the INF file for the STB capture driver rounded things out.

Hence, much of the beginning of this thread deals with ideas, concepts and developement (BS&T) and some tangent chatter rather than implementation. In order to spare people some tedium reading (360 total posts as of this one!), I will reference your posted instructions and Olyar15's summary for those wanting to go straight to the well. I will edit my first post to link to these summaries and instructions. I will get around to that Monday or so.

I am sure many will appreciate the shortcut and the concise instructions you have kindly taken the time to compile along with your own in depth knowledge of UNE functionality.

What would be really cool is to roll up a package with Anders's UNE with the "SGraphRecorder.ini" parameters set to better nominal default values and handles matching the GML file ("Number" instead of "Channel", etc.); the STB FW driver / INF files; a cut-and-paste text file containing the parameter block that needs to be added to "sage.properties" file; Graphedit w/ "proppage.dll"; the Girder GML file; the Cyberlink filters; a batch file(s) to install the filters and "proppage.dll"; and your instructions. Even a partial roll up would be great if having to stay away from the filters and/or Graphedit.

Dane

[spaceghost]

Dane,
A great thanks goes out to you and Anders. For without you, this awesome feature would not be possible!

[AndersNolberger]

What is key to this is that when creating the graph, the path used for the dump filter is the SAME as configured in Sage for location of video files.

Is it really nesessary that the path used in the dump filter is correct? When Sage sends a command to record it includes the full path to the file and I send that to the dump filter.

[AndersNolberger]

From the setup instructions:
Sage uses the Dump.mpg for buffering only. You will see a separate file under your recordings directory (as usual but it will be much bigger!).

The file dump.mpg is never used. The name is changed by SGR before the graph is started. The reason to put a name there is just to be able to test the graph in Graphedit. With most dump filters it is possible to press cancel on the file selection dialog and it will work anyway.

[turak]

Originally Posted by AndersNolberger

Is it really nesessary that the path used in the dump filter is correct? When Sage sends a command to record it includes the full path to the file and I send that to the dump filter.

I've been trying to get this working on one of my client boxes. I've tried setting the dump to one of the recording directories on the server (\\sage\tv2\null.mpg) and I've tried setting it to the local SGR directory. Either way, the recorded show ends up in one of my recording directories on the server.

[DFA]

Anders:

Thanks for the clarification. I stand corrected. Based on early correspondence and reading, I was under the impression that Sage only advised the file name and not entire drive and path.

Anyway, this is good news for "abasu2003" since this means he should be able to take advantage of multiple drives and paths as Sage would do normally.

Also explains for turak why recording always goes back to the server drive and path as configured in Sage.

DFA

[eobiont]

Re: Support for PVR150 blaster.

I totally understand why the UNE only supports tuning via Girder as that is a standard that is easy to implement. What I would like to see added to Sage is a line in the Sage properties that is something in the capture device definition something like Always_Tune=True or something like that. Since SageTV already knows how to send the commands to USB UIRT and my Sage supported blaster, it seems like it would be an easy thing to make a variable in Sage that would tell Sage to handle the channel changes and the UNE to handle the recording.

With the release of the source for DCTRecord, I would guess that this function could be incorporated into Sage so that TS over firewire is a supported capture device, and we won;t need to mess with the hack of treating the FW capture device as a network recorder.

[travisbell]

I am just wondering now that we have all been using this for a little while, what have we decided is the best MPEG demultiplexer, multiplexer and dump filter.

I am still using the MS demultiplexer along with Cyberlink's multiplexer and dump filter.

Cheers,

[DFA]

eobiont:

I follow what you are saying. Before Anders had implemented UNE channel change control by Girder, I asked Jeff this very thing. I suggested that if Sage found the variable name "localhost" for a network encoder address, Sage would not defeat use of direct local channel control such as by "uu_irsage.dll" plugin for example. Jeff was not keen on the idea because it was a change to the core code.

Furthermore, Sage does recognize the STB FW Cap device but excludes it (blacklists) it because it fails the "Crossbar test". I also asked Jeff about this if there was some way to overide the xbar test such that the STB FW Cap device might be used directly. Core code alterations would be involved here as well so was not met with favor as was the channel change idea.

DFA

[eobiont]

OK. I found this on the web. It is an exe a guy called Richard Gate
wrote that is an EXE that you can call to change channels using the PVR150.

You just call C:\<path>\IRBControl 23 and it changes the channel to 23 using the PVR150 as configured by the hauppauge utility.

With this in mind, would it be possible to add to or make a custom UNE so that instead of calling Girder, you could call IRBControl with the channel number for channel changes?

I know there probably aren't a ton of people with the PVR150 AND want to record via FireWire, but maybe there are.

Here is a link to the EXE's web site.

http://www.disco-nt.co.uk/download/

Also, I am sorry if my questioning is getting tedious. I just don't want to shell out $50 for an extra peice of hardware to do something I already have the hardware for. (This alone was the reason I bought the PVR150 ($80) over any other capture device - it included the potentially $50 blaster piece)

[olyar15]

eobiont, you could probably use Girder as a workaround to call that program instead of using the USBUIRT. You still need Girder, but it would save you from having to buy another piece of hardware.

[DFA]

eobiont:

For myself, from a philosophical perspective, I've never considered the HTPC thing to be an economical endeavor and pretty much consider it to be a money pit! Just me.

I agree with Olyar15: I see no reason Girder can not command IRBControl as you want. I have Girder doing many things besides just IR control. Girder is only limited by the imagination in my opinion.

However, if I understand what you are saying, IRBControl is for changing channels on the PVR-150 tuner so don't know what good that would do you but I probably am missing something?

Anders provides the source code for SGraphRecorder so that others can improve or customize it for specific and special needs. You could customize it to suit your needs if having the expertise or access to someone who does.

DFA

[eobiont]

Thanks for the replies both of you.

I draw a distinction between spending money on HTPC and wasting money on HTPC, although I agree that the line can be blurry.

I didn't realize that the source code was available for UNE. I can do a bit of programming, so perhaps I will be able to configure support for the PVR150 blaster. If it gets difficult, I will look into the Girder route. I haven't used Girder so I wasn't aware that it could be made to send out commands to other programs. That will probably work too. In either case I will report back for those interested.

The program I mentioned takes an agument of a channel number and sends the channel change out the blaster. The way the blaster works, you run a configuration program to let the blaster know what device you have, then third party programs just need to tell the interface "Change to channel 201" and the interface sends the proper command dependant on your device. The thirdy party doesn't need to know what device you have or how to change channels on it.

At any rate, thanks for the tips. I am anxious to try the two options out.
There aren't any channels on my cable (other than VOD and PPV) that are 5C encrypted so this will be like getting a whole second capture device + HDTV.

[DFA]

ebiont:

Start of plug for Girder:

Girder is VERY powerful but is considered to have a steep learning curve (depends a lot on each individuals current state of knowledge and experience). Many avoid it because of the steep learning curve. Now having learned most of Girder, it also needs to be said that the rewards are enormous.

As an example of more extreme usage of Girder, I found a LUA script which Girder runs and calculates the sun-up and sun-down each day for the latitude I am at and controls my lighting for the front of the house via X-10. Others have done such things as display caller ID on their TV when the phone rings. I have Girder also doing things like stopping my LCDC application on suspend and restarting it on resume and disabling my XCard driver (which is not ACPI compliant) on suspend and re-enabling on resume. I have Girder doing many other house keeping and automating chores as well. Phenomenal application IMHO and easily worth twice the price.

End of plug for Girder.

I would expect Girder to be the path of least resistance and is a great addition to any HTPC (not a waste of money). In the past, I have made costly mistakes and bad purchases requiring corrective expenditures; Girder was not one of them.

DFA

[Wheemer]

3.2.9 version of girder was free, it can be found pretty easily on the net.

[AndersNolberger]

eobiont:
Youve got a pm.

[eobiont]

I have Girder installed, but I think it is going to be a little tough.

Is SGR sending girder the action "Channel" with payload of the channel number or is it simply sending Channel880 with no payload?

I switched the INI to GirderIndividualNumbers=0

This is beacuse it get's me closer to what I need, which is to send an Execute to a program with a register set as the Channel Number (or payload)

I need something like on event Channel, set [reg1] to payload. Then Execute an external program with [reg1] as the argument.

Maybe I need to do this...

Set the Individual numbers back to GirderIndividualNumbers=1
Then for each Number, Concatenate the number to the varable [reg1].
When Girder then receives the NumberEnter command, it would Execute my external app with the [reg1] register


***Time Passes****

I have it kind of working.
I have attached a GML that I made that will tune to two of my channels, and this works. On receiving action "CHANNEL880" Girder Executes "IRBControl.exe 880" and my STB changes to 880 and the HD program is recorded. Making an action for each of the possible channels is going to be very tedious. Is there a better way than this brute forse method? When looking at the variables in Girder as commands are sent, nothing ever gets loaded into pld1 so I think that SGR is sending the channel number as part of the action text and not as payload, which is a bummer for me. Maybe each night I can do 10 more channels and be done in a week or so .

Do you think the Number1 Number2 etc concatenating onto a string and then Number(enter) sending the concatenated string has merrit? If I should go to a different thread for help, just let me know.

[DFA]

eobiont:

What you need to do is much simpler than that; or maybe not. Do you have to send the whole channel number as an arguement to IRBControl or can you go single digits? Single digits would be easier but scripts can be written to do just about anything.

Give me some info about where you have stored your IRBControl executable and I will attempt to put together a GML file for you. PM with your email address also for something to send.

DFA

[AndersNolberger]

New version of UNE is available. See http://forums.sage.tv/forums/showthr...7&page=1&pp=20 for more information.

[DFA]

eobiont:

Yes there is a better way (tedious is an under statement for 999 commands). I have a GML just about done for you; just have to look up how to use a variable name for an arguement in a command line.

But it looks likes Anders has beat me to it! Let me know if you still want to proceed with a Girder solution.

Edit: Try the attached. Download and install WinLUAEx plugin for Girder. Configure "SGraphRecorder.ini" Girder section as follows:

[Girder]
UseGirder=1
GirderHost=127.0.0.1
GirderPort=1024
GirderPassword=HTPC
GirderPrefix=Number
GirderIndividualNumbers=1
GirderInterNumberTimeSpacing=0

I probably did not get the syntax on "ShellExecute" cmd right and needs fiddling with but you can see what and how things are handled in the scripts. If it does not fly the first time, edit the "Enter Group" \ "Send Channel" comand LUA script to change syntax to:
ShellExecute("C:\\Program Files\\Girder32\\IBRControl.exe",channel,nil,nil,nil)

PS: The single commands under the multi-groups are because I edited this from some stuff I created that does "Auto-Enter" and does have multiple commands. There is no problem with single commands under multi-groups but you can pull them out and delete the muti-groups if you like. I was just too lazy.

DFA