Universal Network Encoder (1.0.10 - Mars 20)

[foolio]

stealth:

is you BDA app a generic app to address the MS ATSC network provider filter to change the channel or is specific to the ATI? would it be very difficult to port it to support the fusion?

[Stealth1971]

foolio -

EDIT: [I read your question too fast. I don't think I answered the first part - could it change the channels for Fusion. Yes - as long as they conformed to the DBA architecture, channel changing shoud work without any code changes to what I have now.]

I am going out on a limb here to say "yes" (for porting). The roots of the app started from sample BDA code from MS. However, it took some discovery to find that Microsoft's sample app had used 1 extra filter from what the ATI HD Wonder needed... (its been awhile since I got passed that so I don't remember the issue exactly) But the filter graph should be 99% the same. In most cases I could see it being just specifying the right BDA driver. Right now I am using a hard coded reference to the ATI driver (the filter GUID) but that could be selectable in the future by listing the the BDA drivers.

One last gotcha - I could see some vendor locking their filter to only connect their apps... that would suck

When I get this solid with the HD Wonder - I would have no issues porting to other boards...

(I should have been working on stuff that makes $$$ today, but this was more fun )

[foolio]

that's great to hear, Stealth1971.

looking forward to testing it with the fusion. Let me know if I can help beta test.

[dvsing]

Anders--

Picking up an issue from a few weeks ago, I got a reply from Jeff at Frey Tech. regarding how to keep Sage & the Network Encoder using the same socket for network communication (instead of opening and closing a new socket for every single command). This is what Jeff said:

Have the network encoder return "2\r\n" in response to the VERSION command.
That'll cause SageTV to keep the socket connection open instead of closing
it after each request. But the connection can still close due to a timeout,
and then SageTV will reopen it when needed (like it used to every time).

FYI, that's the only feature of the VERSION command.

Thanks,
Jeff

If the UNE code is modified to report version 2, and the socket server code is modified to NOT disconnect the socket and instead continue to listen for more commands after each command is issued & dispatched, then we will be halfway to solving the problem I'm seeing when Sage is watching the same file it's recording to (rapid-fire GET_FILE_SIZE messages from Sage).

I still haven't heard from Sage as to why it's issuing so many GET_FILE_SIZE messages, and what drives/limits the rate of these messages. I hope to hear back from them soon on this.

Regardless, getting UNE/Sage to use the same network socket for all communication will keep it from overrunning the network stack.

-Dan

[dvsing]

Breakthrough!

So, someone suggested that I try running SageTV in stand-alone (no SageTV service) mode. When running in this mode, I can watch the same file as the UNE is recording to and there is no flood of GET_FILE_SIZE messages!

Although this means I have to not use service mode until it gets fixed, at least there is a work-around. I've sent the details to Frey so hopefully they'll track this one down. I also seem to notice less (no?) stuttering when running in stand-alone mode vs. service... I wonder if the flood of GET_FILE_SIZE messages is related to stuttering in playback..

-Dan

[turak]

Originally Posted by dvsing

Breakthrough!

So, someone suggested that I try running SageTV in stand-alone (no SageTV service) mode. When running in this mode, I can watch the same file as the UNE is recording to and there is no flood of GET_FILE_SIZE messages!

Although this means I have to not use service mode until it gets fixed, at least there is a work-around. I've sent the details to Frey so hopefully they'll track this one down. I also seem to notice less (no?) stuttering when running in stand-alone mode vs. service... I wonder if the flood of GET_FILE_SIZE messages is related to stuttering in playback..

-Dan

I'm getting the GET_FILE_SIZE for both service and stand alone mode

[spaceghost]

I get the GET_FILE_SIZE only in service mode.

turak-
did you disable and STOP sage and the service? just disabling the service itself while it's still running isn't enough. I made that mistake and noticed I had to stop the service.

[dvsing]

I agree with spaceghost-- stopping the service doesn't prevent it from being loaded on-demand when you launch sage. If you want to run sage in non-service mode, you need to DISABLE the service through the sage service control manager, not just stop it.

-Dan

[turak]

I did disable it through the sage service control manager. I'll have to try again to make sure that the service is stopped. Although I'm pretty sure that it was stopped because SageTV reverted back to the default STV and I had to reset my UI preferences. I still have yet to get SageTV or SageClient to play back a HD recording. I keep getting the audio render exception error. The recordings play back fine in windows media player.

[sundansx]

DFA,
I am trying to setup a graph via 1394 from my Motorola HD Cable box to write directly to a .TS file. It sounds like you already did this. Could you briefly describe this graph? I already have recording from my box working via CapDVHS and am playing back the .ts streams via Zoomplayer+HDTVpump+NvidiaAV (which I prefer).

ref post:Post #29 of the Universial Network Encoder (1.0.7 - Mars 01).

[AndersNolberger]

A new version is now available on my homepage.

[flashbacck]

Originally Posted by Stealth1971

foolio -

EDIT: [I read your question too fast. I don't think I answered the first part - could it change the channels for Fusion. Yes - as long as they conformed to the DBA architecture, channel changing shoud work without any code changes to what I have now.]

I am going out on a limb here to say "yes" (for porting). The roots of the app started from sample BDA code from MS. However, it took some discovery to find that Microsoft's sample app had used 1 extra filter from what the ATI HD Wonder needed... (its been awhile since I got passed that so I don't remember the issue exactly) But the filter graph should be 99% the same. In most cases I could see it being just specifying the right BDA driver. Right now I am using a hard coded reference to the ATI driver (the filter GUID) but that could be selectable in the future by listing the the BDA drivers.

One last gotcha - I could see some vendor locking their filter to only connect their apps... that would suck

When I get this solid with the HD Wonder - I would have no issues porting to other boards...

(I should have been working on stuff that makes $$$ today, but this was more fun )

Hey stealth, I hate to be a pest, but is there an update on this project?

[Stealth1971]

Flashbacck -

Work decided that they needed me 24/7 lately - So I have been beat down by "the man" and not able to work on this... However, here is the status where I left it a 2 weeks ago:

- BDA driver control is fine (start/stop the graph, name target file, change channels...)
edit: '- I have the skeleton done for the network encoder done '---Cancel that - Asking Anders for UNE integration so we can get this done faster...

My problem lies in getting Sage to playback my remuxed MPEG file from the transport stream... The video/audio sync seems wacked (technical term) I am currently using Cyberlink's mux filter...

Any thoughts on this from anyone? I think they are experience similar issues for the Comcast firewire capture in another thread...

I am planning on trying to get an alpha version soon - if I can get some time this week!

[Stealth1971]

update:

I noticed the other Filter Graphs actually use the NVidia TS Info Parser inserted before the Demuxer - hmmm - its probably mentioned somewhere - but what is that accomplishing? If this fixes my problem that would be great! - I am currently connecting the BDA capture device directly to the MS MPEG demuxer... I am not an MPEG guru by any stretch However, if can get the final muxed files to play nice with Sage - We have BDA capture solution that can tune channels directly for the ATI HD Wonder (and other BDA tunable devices)

[dvsing]

A quick update on the GET_FILE_SIZE "bug".

I had some dialog with Frey Tech. recently and started asking questions as to what was governing the rate of GET_FILE_SIZE messages.

Eventually, the answer I got was "that's proprietary - let's just say that it needs to happen". And that is that.

So, on one hand, I am slightly dissapointed about this... because it seems like this truly WAS a problem-- I have yet to actually install the 2.2 RELEASE of sage.. I'm still running on the last RC, so I will have to install the release and check to see if perhaps the absence of debug loggin perhaps causes this problem to go away, or at least not cause playback oddness.

The oddness that I was seeing even after Anders fixed the protocol issue with SGraphRecorder is that the UI was very sluggish to repond to remote commands when watching an mpeg file that was still being actively recorded to ("live" or "near-live" HDTV). I had connected this UI behavior to the appearance of a seemingly unnecessary number of GET_FILE_SIZE messages in the SGraphRecorder debug window-- but perhaps it's time to go back and search for other causes of UI oddness.

Is anyone still noticing UI sluggishness in the 2.2 RELEASE version, when running in service mode, and watching the same mpeg file that is currently being written/recorded to by SGraphRecorder?

-Dan

[Stealth1971]

Moved this to:

HDNE Thread

[spaceghost]

Stealth1971-
From what I understand, the Nvidia TS Info Parser scans the incoming transport stream and sets the PID's for the demuxer. Without this, and if the PID's change, the demux will be trying to "tune" into the wrong PID (or a PID that no longer exists).

Dan-
That is indeed bad news. Sounds almost like they do NOT want to look at/fix it. I am still running 2.2.6, sluggish response. Didn't want to upgrade and lose the import folders capability.

[spaceghost]

Stealth-
Any luck with putting the TS INFO Parser in line?

[Stealth1971]

spaceghost -

Thanks for the info!

I have tried it out - it added 2 more pins to my demux - named "Video" & "Audio" So I attached those to the Cyberlink Mux. I don't remember much of a difference, compared to just connecting my TS stream pin to the MS demux directly. (I did it a couple of nights ago - thats what I seem to remember right now) I will add it back again to check.

[Stealth1971]

Ahhhh ha! The PID changing would explain some capture anamolies that I have seen / been reported to me for the BDA capture app. I think I will be putting 'TS Info Parser' back in to the graph.

Thanx spaceghost...