Confirm tuner priority

[HomeyFour]

Wondering if anyone can confirm / deny this is they BTV normally works.

7pm: Recording 1st episode of WKRP in Cincinatti. global 2 minutes padding
7:30: Recording 2nd episode of WKRP in Cincinatti. global 2 minutes padding, same channel as 1st episode

On my box, BTV starts recording the 2nd episode using another tuner (2 minutes early due to padding) while the first one is still recording the last few minutes. What I would love in this case is for the same tuner to record contiously from 6:58pm to 8:02pm and just make a file break at 7:30.

I get into a bit of a jam because this ties up my two PVR-150s at 7:30 on the dot, so my HD-PVR has to record an SD program that starts at 7:30 instead of using one of the PVR-150s. Normally its not a problem, except for one of my Link boxes is too weak to playback h.264 so I try to avoid recording SD programming on the HD-PVR unless absolutely necessary.

[fmharr]

That is how it works.

Do you no longer have the PVR-500 listed in your sig?

You could not use padding for these shows. It might work or might not.

You could force it to use the 150 tuner card. It might work or might not.

This might help or it might not

Mike

[HomeyFour]

Originally Posted by fmharr

That is how it works.

Do you no longer have the PVR-500 listed in your sig?

You could not use padding for these shows. It might work or might not.

You could force it to use the 150 tuner card. It might work or might not.

This might help or it might not

Mike

LOL! Actually I need to update the sig. I had to remove the PVR-500 - A few months ago I started getting all kinds of timestamp issues out of that card only. Don't know if its a chipset problem or if something went south on it or what, but it was useless unfortunately.

I think I will desable the padding on these records - excellent suggestion!

[ZetaVu]

You can tell that recording job to only use one of the tuners, then it will record them back to back. Be warned, every once in a while BTV screws up their intelligent recording, and something else may be using that tuner when your recording is about to start (usually scheduled recordings will account for this)

[noodleNT]

Athough this is by design, I don't think it is the most efficient use of the tuners. For instance, I have the hdhome run do most of my records. However, I may be watching live HD on another channel. If I have back to back a on a HD channels, one will be in HD and the second will be standard def. Kinds of a pain.

[fmharr]

Originally Posted by noodleNT

Athough this is by design, I don't think it is the most efficient use of the tuners. For instance, I have the hdhome run do most of my records. However, I may be watching live HD on another channel. If I have back to back a on a HD channels, one will be in HD and the second will be standard def. Kinds of a pain.

That's why I added extra HD tuners. You can never have to many.

Mike

[Fonceur]

Originally Posted by noodleNT

Athough this is by design, I don't think it is the most efficient use of the tuners.

Indeed, back to back on the same channel should be handled better. How hard can it be to write to two files at the same time during those overlaps?

[damonbrodie]

Originally Posted by Fonceur

Indeed, back to back on the same channel should be handled better. How hard can it be to write to two files at the same time during those overlaps?

I second the motion!

[koan00]

I found out a long time ago its easier to just throw more hardware at the problem than wait for SS to fix something.

[PaulF]

When using DriectX to capture to a file, you have to shut down and restart the filter graph to change files. In my opinion it is a Microsoft problem, not a SS problem.

[koan00]

Originally Posted by PaulF

When using DriectX to capture to a file, you have to shut down and restart the filter graph to change files. In my opinion it is a Microsoft problem, not a SS problem.

Be that as it may, it should still be trivial to fix for back to back. Simply cut up the one file after the recording (or copy out the part for the first recording while still recording to the file). The middle 4 minutes are in both files.

[PaulF]

Originally Posted by koan00

Be that as it may, it should still be trivial to fix for back to back. Simply cut up the one file after the recording (or copy out the part for the first recording while still recording to the file). The middle 4 minutes are in both files.

Cutting video files is trivial? Surely you jest. You know the files are highly compressed, right?

[koan00]

Originally Posted by PaulF

Cutting video files is trivial? Surely you jest. You know the files are highly compressed, right?

Yes I am aware. Compression has nothing to do with it. The stream does not need to be decompressed or recompressed. There are tons of free or pay tools that do it already.

[PaulF]

Originally Posted by koan00

Yes I am aware. Compression has nothing to do with it. The stream does not need to be decompressed or recompressed. There are tons of free or pay tools that do it already.

All I am saying is that if you need a tool to do it, it is not trivial(especially pay tools). Why do video editors un-compress the file before you can edit a file? Why would SS want hire someone that knows all the video file format internals. That is the point of DirectX. DirectX filter coders know the file formats. You sound like some of my old managers. Are you a manager?

You have a point about the new digital TV transport streams, though. That would be trivial because there no file headers to worry about and eack packet stands alone.

[koan00]

Originally Posted by PaulF

All I am saying is that if you need a tool to do it, it is not trivial(especially pay tools).

And I would disagree. Just because someone made an application, that doesn't make it hard. By your logic all programming is non-trivial.

Originally Posted by PaulF

Why do video editors un-compress the file before you can edit a file?

Because you are actually editing the contents of what the video is displaying. Splitting a transport stream is not 'editing' the file in a traditional sense. Read the descriptions of the applications that do only splitting. They mention things like "fast" and "no quality loss" - that would be impossible if they were decompressing/recompressing after the split.

Originally Posted by PaulF

Why would SS want hire someone that knows all the video file format internals.

Because their application works with video files as its primary function, and having someone who knows about video file internals would be a great asset to the team? I'd be surprised if they didn't have anyone already with some of this background knowledge.