Native HDHomeRun Prime Support

[KryptoNyte]

I think there is a creative way to solve the issue. I just don't have the programming background to apply the logic.

Oh, and I don't have the logic either.

[Monedeath]

Originally Posted by Fuzzy

Understand, though, that sage will have no idea how long a given tuner is 'lost', so it is still going to rehash it's entire schedule. There is no way for Sage to reschedule a small portion of it's schedule, or even a single item on it's schedule, without running through all it's multiple iterations from the beginning. Doens't matter if the tuner is gone for a minute, or 3 days. Sage's behavior when said tuner is unavailable has to be the same.

The issue there is a possible 13 minute cycle for Carny to figure out it should switch to tuner 2 is a problem when it discovers the tuner it wanted to use is unavailable seconds before recording starts. That probably should be targeted for further examination as to how Sage might be better able to handle that situation in the future.

With networked tuners, like the Homeruns, it has become unreasonable for Sage to assume it is the only potential user of a given specific tuner. Likewise, this behavior also plays into people who watch live TV who get pestered by Sage about a scheduled recording wanting to use a given tuner(the one they're using), even though there are several other tuners with the same tuner merit sitting idle at the time.

[Monedeath]

Originally Posted by Taddeusz

This is a future thing but maybe the scheduler should be modified to have tuner pools. The scheduler can be set to record something from the pool. It will then try each tuner in the pool until it finds one not locked. This to me would be more logical than having each tuner stand on its own but associated with a particular channel lineup. It makes more sense in my mind to have a pool associated with a lineup and have tuners assigned to the pool that are able to receive the lineup.

Not that I'd be the one to implement, but I am suspecting the pooled tuner suggestion above is probably the core idea for a revised recording scheduler. Where the "pool" can be either a single device, group of devices, or other such combination. Ie, Sage knows there are 4 Tuners in the ATSC tuner pool with the same tuner merit, so when recording scheduling occurs it reserves a time, not a specific lane(knowing there is a limit of 4 lanes).

Then once time to record nears, based on priority for the recordings start checking tuner availability and slot in accordingly. If someone wanted to be fancy there could be a secondary process that was run previously(before a tuner failure event) to indicate if alternative airing times or pool selections are possible for a given program to possibly help in reshuffling in the interest of trying to record everything possible as I recall that is what the scheduler does currently when scheduling in the first place.

The challenge is dealing with concurrent alternatives spanning multiple pools, such as ATSC/QAM/Cable Card tuner record options for same channel for example, where all tuners are either scheduled to be busy, or are already busy once Sage tries to use them, but some programs aren't due to rebroadcast during the look ahead window.

[Narflex]

Originally Posted by Monedeath

Likewise, this behavior also plays into people who watch live TV who get pestered by Sage about a scheduled recording wanting to use a given tuner(the one they're using), even though there are several other tuners with the same tuner merit sitting idle at the time.

FYI, this logic was improved while at Google, and that code was integrated into the open source version...so hopefully you'll get less prompts that are unnecessary now.

[jpwegas]

Originally Posted by Narflex

Regarding stream repair...SageTV has extensive code for doing this already. It's what's been always used with any of the Digital TV systems we support. It actually remuxes the transport stream into a program stream and then writes that out. There is a facility in sage.media.format.MPEGParser for doing the remuxing from a Java level...but I don't know if that specific path of code still works because we stopped using that awhile ago. At the native layer though, it definitely works.

Are network encoder streams pushed to the server with UploadID passed through this stream repair code? I'm wondering if I can take ffmpeg out of the loop if I add upload support.

--John

[Fuzzy]

As far as I can tell, the UploadID streamed files are written directly to disk. It is a general purpose system that is used by more than just the network encoders for transferring files between client and server. It is not something that is specific to recording.

[Narflex]

Originally Posted by jpwegas

Are network encoder streams pushed to the server with UploadID passed through this stream repair code? I'm wondering if I can take ffmpeg out of the loop if I add upload support.

--John

You could add support into the MediaServer.java class to enable this...I think it's a great feature to add.

[jvl711]

Originally Posted by Narflex

You could add support into the MediaServer.java class to enable this...I think it's a great feature to add.

I am planning on doing this. I just released a new beta of PrimeNetEncoder, so I think I might shift focus towards working on this.

[jvl711]

Originally Posted by Narflex

You could add support into the MediaServer.java class to enable this...I think it's a great feature to add.

Hi Jeff,

I ran the test scenario to make sure the library was loading properly in Windows, and I was able to convert a file using the remuxFile option.

I was thinking of adding a new WRITEOPENR ("R" for remux I guess). I would Add an additional parameter to the command for output type (REMUX_TS/REMUX_PS). Should I also send a parameter to tell it how many bytes it should send to the init method? The remuxFile is currently sending 8192. How about a channel parameter in case there are multiple streams in the future?

Then I would also add a WRITER command to handle remuxing the stream.

Josh

[Narflex]

Since you're asking for suggestions...I'll tell you how I'd do it.

1) Add a new command called "REMUX FORMAT CHANNEL INITSIZE" where FORMAT is TS or PS and CHANNEL is a number for which program in the stream to remux (-1 meaning use the default program). INITSIZE is the number of bytes to init, if its zero then default to 8192. This then configures that connection for doing remuxing.
2) In the WRITE handler; if its in remuxing mode...then do that. And automatically handle doing the init part in here as well and then just hold onto that data for when the init is complete so you can write it to the file.
3) Be sure to close the remuxer when the connection is terminated as well.

This is similar to how the transcoding feature in the media server works.

Originally Posted by jvl711

Hi Jeff,

I ran the test scenario to make sure the library was loading properly in Windows, and I was able to convert a file using the remuxFile option.

I was thinking of adding a new WRITEOPENR ("R" for remux I guess). I would Add an additional parameter to the command for output type (REMUX_TS/REMUX_PS). Should I also send a parameter to tell it how many bytes it should send to the init method? The remuxFile is currently sending 8192. How about a channel parameter in case there are multiple streams in the future?

Then I would also add a WRITER command to handle remuxing the stream.

Josh

[jvl711]

Originally Posted by Narflex

Since you're asking for suggestions...I'll tell you how I'd do it.

1) Add a new command called "REMUX FORMAT CHANNEL INITSIZE" where FORMAT is TS or PS and CHANNEL is a number for which program in the stream to remux (-1 meaning use the default program). INITSIZE is the number of bytes to init, if its zero then default to 8192. This then configures that connection for doing remuxing.
2) In the WRITE handler; if its in remuxing mode...then do that. And automatically handle doing the init part in here as well and then just hold onto that data for when the init is complete so you can write it to the file.
3) Be sure to close the remuxer when the connection is terminated as well.

This is similar to how the transcoding feature in the media server works.

Perfect! Very similar to what I was planning on doing.

So would the protocol look like this from the clients perspective

WRITEOPEN FileName UploadID (Verifies the file and preps the streams)
REMUX Format Channel InitiSize (Creates the Remuxer and sets upload mode to remux)
WRITE Size \r\n Data (Handles all remuxing duties including the pushing the initData)
CLOSE (Closes all streams and the remuxer)

Sorry for all of the questions. I would just prefer to do it the way that made the most sense to you so that it works with the architecture.

Josh

[mhassman]

Hey, not sure if this will help anyone, but I wrote an equivalent to SageDCT a number of years ago.. have been running on it since then as my primary tuner source for SageTV v7.

It's modeled after http://babgvant.com/files/folders/sa...ntry20796.aspx.. I tried to get SageDCT working, but never succeeded. So, wrote my own.

I never got back to polishing it (channel preview missing, source encoders are manually defined as opposed to auto-detected, and few other minor issues), but it's been stable for years. Might be a useful guide for interacting with the HD Prime.. I remember there was a tuner locking function in the api.

Happy to provide source (.net) if that helps anyone.
Drop me a private message if interested.
:-)

[Narflex]

Originally Posted by jvl711

Perfect! Very similar to what I was planning on doing.

So would the protocol look like this from the clients perspective

WRITEOPEN FileName UploadID (Verifies the file and preps the streams)
REMUX Format Channel InitiSize (Creates the Remuxer and sets upload mode to remux)
WRITE Size \r\n Data (Handles all remuxing duties including the pushing the initData)
CLOSE (Closes all streams and the remuxer)

Sorry for all of the questions. I would just prefer to do it the way that made the most sense to you so that it works with the architecture.

Josh

Pretty close....couple things:

1) Call it REMUX_SETUP for consistency with XCODE_SETUP
2) WRITE has 2 arguments, offset and size
3) Be sure to cleanup the remuxer in the finally {} block as well (if it wasn't already yet) in case the client never called CLOSE

[jvl711]

Originally Posted by Narflex

Pretty close....couple things:

1) Call it REMUX_SETUP for consistency with XCODE_SETUP
2) WRITE has 2 arguments, offset and size
3) Be sure to cleanup the remuxer in the finally {} block as well (if it wasn't already yet) in case the client never called CLOSE

FYI...

I have it working in a proof of concept. I implemented exactly as we discussed. I have a few issues that I am looking into. Mainly MediaServer does not appear to be closing the file properly. When I stop the recording the file just hangs out. I have to shutdown Sage and manually delete them. I will double check the close and finally blocks to make sure everything is being properly disposed of.

The remuxer also appears to be causing Sage to crash with a java core dump occasionally. I need to determine if these are issues that I introduced, or if there is other issues down stream from the code I wrote.

Josh

[Narflex]

Originally Posted by jvl711

The remuxer also appears to be causing Sage to crash with a java core dump occasionally. I need to determine if these are issues that I introduced, or if there is other issues down stream from the code I wrote.

Josh

I would not be surprised if there are bugs that will cause it to crash since we never really used this path very often. But the core functionality it's utilizing should be very stable...so the bugs should be at a higher level in the remuxer and hopefully not that hard to fix.