WMC multi-purposes "in-use" TV tuner if appropriate, bypassing "new tuning" need

[DSperber]

SERENDIPITOUS EPIPHANY:

My problem tuning to USA (101) on Spectrum SoCal with BOTH my M910t (Ceton6 PCIe) and Z170 (Ceton6 ETH) machines persists. No explanation yet why that particular channel (including its below-100 duplicate 40) presents a tuning challenge for the Ceton cards. For some reason when a new scheduled recording (series or one-off) on that channel initiates the associated "background" process of getting a tuner assigned runs into a "no signal for tuner 1/2/3/4/5/6" situation, with a fail-over to try the next tuner. Most times some other tuner can eventually be found that successfully tunes to 101 and the recording is off and running (though perhaps several minutes after scheduled recording was originally supposed to start). But also, some times all six tuners are exhausted and NONE was found that magically could conenct, and I've not completely lost that scheduled recording.

In contrast, remarkably, the FOREGROUND tuner selection process (i.e. for "live TV" or when picking a program to watch "live" from the GUIDE) must somehow be different. It seems to work 100% successfully, or at least it never seems to fail even though multiple tuners may have been examined in the background before one was found to work properly and then be selected for allocation to the foreground "live" need. There is a varying non-instant amount of time required by the Ceton/driver tuner-allocation process (which can last seemingly 4-10 seconds), so clearly something is happening under the covers.

Now here is the serendipitous epiphany about how WMC allocates tuners: if a single already-tuned/allocated tuner can be SHARED for a second or third etc. need, IT WILL BE SHARED IMMEDIATELY!

In other words, depending on the specific new situation and its needs, just because a tuner is newly required to provide live/recording capability to a "user task" (either (a) foreground WMC window on a local monitor for a specific channel, (b) background WMC recording task for that same specific channel, or (c) RDP task to support an extender for "live" view of that same specific channel), WMC may actually choose to SHARE THE ONE PRE-TUNED TUNER which is already tuned to the required channel!! If you look at the web browser GUI to see what's going on with the six tuners, turns out there will only be ONE which is "playing" and tuned to the target channel. It is obviously "simultaneously feeding" all of the other foreground/background/RDP tasks the exact same "live data" for that channel.

Now most importantly, once the first task completes its tuner-search/allocation process and is now "in-use" for the selected channel (a process which may take 3-10 seconds, depending on whether the channel might be non-SDV or SDV so that a tuning adapter is involved, or if encrypted/non-encrypted so that a cablecard might be involved, etc.) any subsequent user task "live need" for the same channel WILL INITIATE A NEAR-INSTANT SHARED USE OF THE PRE-TUNED ALREADY ALLOCATED TUNER TO DELIVER THAT SAME CHANNEL to the subsequent user task.

NOTE: this notion also impacts when multiple "overlapping" scheduled recordings FOR THE SAME CHANNEL start, depending on when the already-active recording for that channel is scheduled to end. For example, if one recording is set for 6:00 - 9:03 for channel 101, and a second recording is set for 9:00 - 12:03 for channel 101, WMC will recognize this overlap (apparently considering it to be "extraneous" and unnecessary) and will actually DELAY THE START of the second recording to not start until 9:03, in order to be able to continue to immediately use "live" the very same tuner which had been allocated/used for the first recording, continuing its allocation/use for the second recording WITHOUT NEEDING A SECOND COMPLETELY INDEPENDENT FROM-SCRATCH TUNER SEARCH/ALLOCATION for a tuner suitable for use by the second recording. The fact that both recordings are for the same channel is handled in an "intelligent way", even though it does seem to override the user's request to start that second recording at 9:00, and not 9:03 as actually happens.

So, how is this relevant for me TODAY, and how has it actually "saved me" and solved (or at least provided a 100% guaranteed successful workaround for) a desperate current problem I'm having??

I'm having inexplicable trouble tuning to channel 101, whenever a new scheduled recording has to begin for channel 101. So what I've done and which seems to have totally overcome my problem is to first open a foreground local WMC window (to tune to and watch channel 101 "live") on a local monitor. And I'm now just leaving this foreground window open forever (though with volume tuned down to 1 and window minimized to the taskbar). That's the trick! Whatever tuner is now tuned/allocated for channel 101, that's going to be the one-and-only "universal feeder for channel 101" for any other subsequent user task also requiring channel 101 "live".

And now, whenever a subsequent new background scheduled recording for channel 101 must be started, it discovers that tuner which is currently foreground allocated/in-use for channel 101 (for my always-running WMC window task that is "watching channel 101 live"), AND WILL SHARE IT!!! There is ZERO tuner search/allocation needed in the background, so the subsequent recording task STARTS NEAR-INSTANTLY, and with ZERO POSSIBILITY OF A "NO SIGNAL FOR TUNER" FAILURE. Or, if I start an extender and want to watch channel 101 live, it too produces NEAR-INSTANT activation of picture on the associated TV, once again SHARING that original underlying tuned/allocated tuner for channel 101.

Again, no matter how many simultaneously active foreground/background/RDP tasks might present for some "live" use, as long as they all need the same channel as is currently tuned/allocated for the foreground task, they will all SHARE THAT SAME TUNER to feed that channel to all of them simultaneously!!

And there will never need to be a new tuner search/tune/allocate which is potentially subject to the 'no signal for tuner" failure. It's impossible to fail!! It's already been tuned and allocated to that channel successfully and is currently active, and now serves as the "channel 101 server" for all subsequent background/RDP needs, no matter what those needs are, avoiding having to find/tune/allocate again which risks "no signal for tuner" failures.

==>> NO MORE "NO SIGNAL FOR TUNER" FAILURES, although there is now the theoretically unwanted but unavoidable loss of duplication of the overlapping few minutes of end/start content in two "adjacent" recordings. Now the two recordings will simply provide a chronologically contiguous stream for that common channel, with no duplication of several minutes at the conceptual chronological "join time point". Just to keep things simple and consistent, I've changed my "overlapping recordings" (which initially were set up to try and avoid loss of any recorded minutes!) to now simply end and start "on the hour". The presence of the magical "always-running foreground task" which produced the "channel server" tuned/allocated channel 101 instant delivery system seems to have eliminated all risk of any lost recorded minutes.

[Space]

Note that the feature of not causing a conflict if there is a small (5 minutes or less) overlap is called "Enhanced Conflict Resolution" and was first introduced with the Vista version of WMC. It will occur even if the overlapping programs are on different channels. It's intent was to pacify users with only a single tuner (common at the time) when two shows they wanted to record were only overlapping by a small amount, as the cable networks had started to do to frustrate people who wanted to record competitors shows. I believe adding "10 minutes after" "Stop" padding to the earlier recording is the only way to disable this feature.

Also note that when you tune in to a channel "live" it chooses tuners in the reverse order that is used for a background recording. This may be a clue as to why you are having issues with one but not the other.

Settings->TV->Guide->Edit Channels will allow you to look at the channel and see all the tuners that are assigned to that channel.

Select the channel and then select "Edit sources".

I will list all the tuners (showing 3, but be sure to scroll down as there may be many more than that) in the order they will be used (forwards for scheduled recordings and backwards for live viewing, or maybe the opposite, I don't remember).

You can test each tuner by toggling "Show Preview" and then selecting each of the tuners. If any tuner is not working, you can just remove the check mark (in the box) for that tuner and it will not be used when tuning to that channel. If you make any changes, be sure to select "Save" to confirm your changes.

[unclebun]

See if you can figure this one out. I watch Formula 1. I have the prerace show and the races set to series record. They do, and you always lose a small portion of whatever aired between the recordings, i.e. it does not apply the 10 minutes before and after to the joint between the two recordings. It is therefore using the same tuner to record both programs. However, at tracks where the race is more likely to run long, or if there is bad weather, or if I remember to think about it, I will sometimes go into the schedule the day before the race and add the Sportscenter show that comes after the race as a one-time recording. When it does that recording, it will do the 10 minute pads so the race recording goes 10 minutes beyond the scheduled time, and Sportscenter has a 10 minute pad before the show. It has used a different tuner to record Sportscenter.

[Space]

Why would it be applying "10 minutes before and after", what settings do you have for your Series?

[DSperber]

Just to elaborate a bit more on the "epiphany" (i.e. the accidental discovery that one single tuner was in fact supplying content to both the foreground "live" user task as well as to the background "recording " user task when both required tuning to the same channel), and how I came to stumble on to it...

Thankfully, in light of my current ongoing "waiting for channel map" situation (only on Ceton6 ETH, perhaps due to some type of hardware failure going on) which prevents using my tuning adapter which therefore prevents tuning to any SDV-provided channels here on Spectrum SoCal, USA channel 101 is a non-SDV channel. So at least I can theoretically tune to it even with the tuning adapter not just inaccessible and unusable by the Ceton ETH but even completely disconnected and removed (e.g. pulling out the USB cable). So I've been fighting for over a week now trying to babysit the Z170 in order not to lose recordings on USA, which unfortunately has been assigned 24/7 duty by NBC making the situation really critical.

I've been trying to kick-start each of the six tuners using the web GUI, theoretically tuning manually to channel 101, hoping that this pre-use of that tuner might make it somehow more accessible when a background recording need kicks in. Now because the tuning adapter is not usable (even though channel 101 is not an SDV-delivered channel) the "tuning resolver" functionality doesn't work either. so even though the channel might actually be tuned to 101 by that tuner, there is no "tuning resolved successfully" message shown at the bottom of the web GUI page for that tuner as appears there when "TR Status: READY" and manual tuning is actually successful.

And I've been kind of testing things out after working manually with the web GUI to tune channel 101, by then going to the foreground "live" WMC to try and see if I can now get to channel 101 and other channels to actually watch what's being broadcast at that time. Probably because the tuning adapter is not active and the official channel map required for SDV functionality is not loaded, foreground tuning to any arbitrary [non-SDV] "live" channel takes much longer than it should, like 5-15 seconds, although it's always eventually successful.

But I noticed that curiously if I happened to actually be recording channel 101 in the background, when I tried to tune to 101 using Guide or "live" that picture and sound for the program appears near instantly, instead of the 5-15 seconds I had to wait for channels other than 101. While both of these activities were still active (i.e. both foreground "live" on 101 as well as background "recording" on 101) I went to the web GUI to see what tuners were in use for channel 101, fully expecting that TWO would be "playing". Astonishingly, only ONE WAS "PLAYING" to channel 101! This prompted the epiphany, that in fact the one single tuner was providing content simultaneously to both the background and foreground tasks, since they both required tuning to the same channel 101.

So, I reasoned, if that tuner is tuned to 101 and active (for recording) when I need to also tune to 101 for foreground live viewing, and if that situation causes a complete skipping of allocating a second tuner independently also tuned to 101 but instead instantly provides the same first tuner already in-use and active for 101 to the background task instantly and simultaneously to the second foreground task (explaining why picture/sound appeared near instantly when I went "live" to 101 while a background recording for 101 was proceeding), would not the exact same story apply in reverse?

In other words, if I was "live" viewing 101 so that a tuner was allocated and tuned to 101 when a background recording need for channel 101 kicked off, would not the same tuner that was already in use for the foreground live function simply instantly be assigned for simultaneous duty to feed signal to the background recording task again without needing to go through a new second tuner allocation/tuning process? And the answer is YES, it does work exactly that way.

So I am thrilled to report that this trick technique of keeping an ongoing foreground "live" task so-called "watching channel 101" (but minimized to the taskbar and with sound turned down) has in fact worked perfectly to allow every new 3-hour recording block for USA 101 to start "instantly on the hour", exactly as set up in the manually added "series recording" (by channel and time for "everyday"), something which had never happened before. Previously it might take up to 6 minutes for the "no signal found for tuner" fail-over process to finally get a tuner working and assigned for use in a new rercording, and now it takes ZERO TIME. Each recording for 101 since yesterday had been 100% successful in starting on the hour, and ZERO tuner signal failures have occurred (obviously, because no new tuner is ever needed now!).


My new Ceton ETH arrives this afternoon, but I won't attempt to install it until after the Olympics are over and I have all the time in the world to do whatever might be necessary. Hopefully there is some hardware issue that's only developed fairly recently in my current Ceton ETH (which used to work perfectly) and which will finally disappear with the new one, and which will result in the curing of TR Status of "waiting for channel map" and a return to "ready".

I still can't imagine why I'm having trouble tuning to channel 101 and no other channel, on BOTH of my machines (one with Ceton ETH but no operational tuning adapter at the moment, and the other with Ceton PCIe and a perfectly normal working tuning adapter). I can't imagine how something Spectrum is doing could cause one specific channel present a tuning challenge to a Ceton tuner, but how else can one explain the identical only-on-101 tuning problems on two separate machines?

This story will have its next chapter next week, when I can finally get the new Ceton ETH installed.

[unclebun]

Why would it be applying "10 minutes before and after", what settings do you have for your Series?

My series setting is to add the pad before and after a scheduled recording, which adds up to 10 minutes.

[Space]

If you have all three of your recording requests (two Series and one one-off) set to "Stop: 10 minutes after" (hard post-padding) then I would expect that all three would add the additional 10 minutes to the end, and would record any conflicting recordings on a separate tuner.

If you also have a 10 minute soft pre-padding on all of them (there is no hard pre-padding in WMC), then I would also expect them to add 10 minutes to the start of each recording (assuming there was no conflict with that extra 10 minutes) since they would be recording on different tuners. This would mean each recording would have 20 minutes extra added to them (10 minutes pre-padding and 10 minutes post-padding).

Since you are not seeing this behavior, I would have to assume you do not have the proper post-padding setting on all of your recording requests. Perhaps you have the "Stop: 10 minutes, if possible" (soft post-padding) setting on them instead?

If you do have "Stop: 10 minutes after" set on all of them, then I can't explain why you are seeing what you say.