Recording Failed To Start (1 Viewer)

[CyberSimian]

I was using MP earlier this morning when I noticed that a scheduled recording had not started (no red dot visible). And this was after I had rebooted about 90 minutes earlier!

I have looked at the TV Server log, and at the time of the recording (10:04:00 today), the Scheduler recognises that a recording is due to start (on channel "movies4men"), examines the tuners to find which are free, finds that 8 tuners are free, but then never actually starts the recording; it seems to repeat this in some sort of loop. The recording was scheduled before the clock change, but that seems an unlikely cause.

I rebooted again, and scheduled a short programme to record in the near future, and that did start recording on time. Any advice? I have attached the logs. Thanks.

-- from CyberSimian in the UK

 

[mm1352000]

Hello

The cause is a tuner driver deadlock, which in turn is triggered by the EPG grabber repeatedly tuning to the same transmitter. I've seen this before with TBS tuners (for example, -->here<-- [follow mcraenz's posts and my responses to him]) so I suspect a TBS driver bug.

The fix?
None. TBS would have to fix whatever the problem is in their drivers.

The workaround?
Fix your EPG configuration. Minimise the number of channels you tick for grabbing. Especially: do not tick channels that can't be tuned and timeshifted/recorded successfully 24/7. When configured properly you almost certainly only need to tick one channel from each transmitter/frequency (and untick "store data only for selected channels"). At minimum you could possibly even just tick one (yes, that's right - one) channel (and untick both "store data only for selected channels" and "grab EPG only for channels on same transponder").

For the record, here are the channels that are currently causing the problem:

• QUEST+1 [TV]
  
• Kiss [radio]
• Kerrang! [radio]
• Magic [radio]
• KISSTORY [radio]
• KISS FRESH [radio]
  
• Show TV [TV]

But do not make the mistake of only unticking these. The problem is almost certain to happen again unless you amend your configuration properly as described above.

Regards,
mm

 

[CyberSimian]

The cause is a tuner driver deadlock, which in turn is triggered by the EPG grabber repeatedly tuning to the same transmitter. I've seen this before with TBS tuners... Workaround:

Do not tick channels that can't be tuned and timeshifted/recorded successfully 24/7.
Tick only one channel from each transmitter/frequency.
Untick "store data only for selected channels").

Thank you, thank you, thank you! The consequences of picking certain combinations of settings were not obvious to me, so I am not surprised that I ended up with a less-than-optimal result.

At minimum you could possibly even just tick one channel (and untick both "store data only for selected channels" and "grab EPG only for channels on same transponder").

This is an interesting possibility. I am no expert in this area, but my understanding of the UK DVB-T system (other countries may be different) is that each MUX transmits the EPG for all MUXes, but with a preference for the channels in its own MUX. So the EPG for the channels in its own MUX will be populated fairly quickly, but the EPG for the other MUXes will take much longer.

The DVB-T2 MUXes are different again, in that they transmit the EPG in an encoded form (fortunately one that MP understands), but the EPG for the HD channels are not included in the DVT-T MUXes (which are not encoded). I think that this was so that the BBC could impose the requirement on equipment makers that they honour the DRM requirements for the HD channels. Certainly, my Humax HDR-FOX-T2 can export SD and HD recordings to other devices, but only the SD recordings will play on other devices -- the HD recordings remain encrypted, and will playback only on the original device.

The upshot of this is that if a single channel were to be used for EPG grabbing, it would have to be an HD channel; if an SD channel were chosen, the EPG for the HD channels would be missing. So I am going to look at the MUXes and select one 24-hour channel from each MUX for EPG grabbing. Thank you!

-- from CyberSimian in the UK

 

[CyberSimian]

When configured properly you almost certainly only need to tick one channel from each transmitter/frequency (and untick "store data only for selected channels").

May I ask one more question? I used "ScanChannelsBDA_UK.exe" to find which channels resided in each MUX. The version of "ScanChannels" that I have recognises DVB-T2 MUXes, but does not understand them (so it does not list the channels in the DVB-T2 MUXes). The scan revealed that:

(1) There are currently 8 MUXes at my location, two of which are DVB-T2.
(2) All 8 MUXes contain TV channels.
(3) 4 DVB-T MUXes also contain radio channels. (I don't know whether the DVB-T2 MUXes contain radio channels.)

So this is the question: if I select one TV channel from each of the 8 MUXes (to be used for EPG grabbing), and deselect "store data only for selected channels" (as you specified), will that also grab the EPG for the radio channels in the MUXes, or do I also need to select one radio channel from each of the MUXes that contains radio channels?

I initially selected one TV and one radio channel from each MUX, but some of the radio channels now show "No data available" (for "KissFresh", "Kiss", "Kisstory", "Magic", "Kerrang"). I had selected "Magic" as the grabber channel for its MUX, and even though "Magic" has no EPG, both "Talksport" and "Insight" do have an EPG (they reside in the same MUX as "Magic"). After re-reading your post, I changed the grabber channel from "Magic" to "Insight", so perhaps that will fix the EPG gaps the next time that EPG grabbing occurs.

-- from CyberSimian in the UK

 

[CyberSimian]

For the record, here are the channels that are currently causing the problem:

• QUEST+1 [TV]
  
• Kiss [radio]
• Kerrang! [radio]
• Magic [radio]
• KISSTORY [radio]
• KISS FRESH [radio]
  
• Show TV [TV]

I have looked at this some more, and have come to the conclusion that the problem with these channels may have been caused by a "retune event" that occurred in the UK several weeks ago. As mentioned previously, I have a Humax HDR-FOX-T2 PVR which I keep as an "emergency standby", in case my HTPC suffers a catastrophic failure. As such, I do not normally use the Humax for recording, so I was happy to retune it as soon as the UK retune-event was completed. I checked today, and most of the channels that you mention above broadcast for 24 hours per day, have full details in the EPG, and can be selected successfully for viewing or listening.

Now my understanding of the retune event was that it changed only logical channel numbers (LCNs), and that there is enough indirection in the channel definitions for the renumbered channels still to be found. And indeed, MP can still find the news channels, which moved from LCNs in the 80s to the 130s, and I still have a fully-populated EPG for them. However, I suspect that the channels listed above experienced more significant changes, possibly moving from one MUX to another, such that MP can no longer find them.

So, why haven't I retuned my HTPC? I have so far refrained from doing this because of the (to me) unknown impact that it will have on the recording schedule.

The reason why I am wary is that with Windows Media Center, retuning has a catastrophic effect on the recording schedule. Windows has a penchant for using GUIDs to reference things, and this includes the channels in WMC, and the recording requests. Each recording request contains the GUID of the channel that it is to tune. When the channels are rescanned, WMC allocates a new set of (unique) GUIDs for the channels, with the result that the recording requests now refer to channels that no longer exist in the channel database. An incremental scan probably does not do this, but then you end up with a lot of dead channel definitions (because they moved somewhere else, but WMC cannot delete them because they might be part-time channels which were not broadcasting when the scan was performed).

So, may I ask a supplementary question? If I perform a tuner rescan, what effect does that have on the recording schedule? Is the schedule preserved without error, or is it completely destroyed? Thank you.

-- from CyberSimian in the UK

 

[mm1352000]

Hello again

So this is the question: if I select one TV channel from each of the 8 MUXes (to be used for EPG grabbing), and deselect "store data only for selected channels" (as you specified), will that also grab the EPG for the radio channels in the MUXes, or do I also need to select one radio channel from each of the MUXes that contains radio channels?

I'm pretty sure that when you deselect "store data..." the EPG grabber will store for both radio and TV channels. In other words: no need to configure separate radio grabbing.

I initially selected one TV and one radio channel from each MUX, but some of the radio channels now show "No data available" (for "KissFresh", "Kiss", "Kisstory", "Magic", "Kerrang"). I had selected "Magic" as the grabber channel for its MUX, and even though "Magic" has no EPG, both "Talksport" and "Insight" do have an EPG (they reside in the same MUX as "Magic"). After re-reading your post, I changed the grabber channel from "Magic" to "Insight", so perhaps that will fix the EPG gaps the next time that EPG grabbing occurs.

This all makes sense.
The channels that have no data are the ones that aren't tunable. Like you say, those channels probably experienced more significant changes as part of the "retune event". Maybe they were moved to a different mux, and maybe their identifiers (service ID etc.) were changed. If they were moved to a different mux then I'd expect tuning would fail but EPG might continue to be shown. If their identifiers were changed then tuning will fail and EPG won't be picked up even though it is available in the broadcast. The EPG grabber would see the data but wouldn't know which channels to link it to.

The only way to fix the "tunability" and EPG for these channels is to fix their tuning details - frequency etc. as well as identifiers. It is easiest to do this by scanning, but it can also be done manually if you can get access to the correct details from another source (such as your Humax STB).

So, why haven't I retuned my HTPC? I have so far refrained from doing this because of the (to me) unknown impact that it will have on the recording schedule.
...
If I perform a tuner rescan, what effect does that have on the recording schedule? Is the schedule preserved without error, or is it completely destroyed?

Assuming the channel identifiers have changed for the broken channels and not changed for the working channels, the effect would be:

1. Scanning does not directly touch schedules. Any effects on schedules described below are the result of effects on channels.
   
2. The existing channels that work should effectively be completely unchanged. Unchanged in that they should continue to be tunable, and the associated schedules should continue to record. Unchanged even to the degree that the saved name and logical channel number won't be touched even if the broadcast name and/or LCN have changed. TV Server does not update names or LCNs as it currently can't tell the difference between standard and user-modified names/LCNs.
   
3. The effect for existing channels that don't work depends on the scan settings and the reason the channels don't work.
   1. Channels that have changed identifiers would continue to exist in their current untunable state with no EPG data. Any schedules associated with these channels would continue to fail to record. TV Server never automatically deletes channels.
      
   2. For channels that have moved to a different mux but kept the same identifiers:
      • If you scan with "channel movement" detection enabled then the rescan should fix such channels. Fix in that they should become tunable again and the EPG show show again. Associated schedules should start working again given that the channels are tunable.
      • If you scan with "channel movement" detection disabled then the outcome is expected to be the same as if the identifiers changed. In other words: channels remain in the database along with schedules in broken state, and no EPG data.
4. Replacements for channels whose identifiers have changed should be created along with any genuinely new channels that have been added to the broadcast platform. If the EPG grabber is configured appropriately, all of these channels - replacement and new - should get EPG data automatically. The existing "record on any channel" schedules will apply to the new channels automatically. The other existing schedules that are associated with specific channels will not be automatically transferred to replacement channels. There is no association between a replacement and its previous incarnation to enable this. From TV Server's perspective replacement channels look just like any other new channel.

In short, the intention is that a rescan should do as much good as possible with zero harm.

Beyond rescanning you can do in-place fixing of broken channels:

1. Combine the existing channels with their replacements.
2. Edit the combined channels and delete the non-working tuning details.

...OR...

1. Manually copy the working tuning details from the replacement channels back to the existing channels.

Both of these would avoid having to recreate schedules, reorganise groups, and re-map tuners.

Regards,
mm

 

[CyberSimian]

In short, the intention is that a rescan should do as much good as possible with zero harm.

Thank you very much for a detailed explanation. Now the test to see if I have understood it correctly!

Recommended practice is:

(1) Don't begin by deleting channels.

(2) Rescan, enabling channel-movement detection.

(3) Channels that are not changed by the scan do not result in the creation of duplicate channels. Recordings for these channels will continue to work without problem.

(4) Channels that are different after the scan will be usable, but may leave as an orphan the equivalent channel that existed before the scan (depending on whether ids changed). These orphans are unusable and should be deleted. Scheduled recordings for programmes on orphan channels will not work, and so need to be deleted and recreated.

(5) New channels will be added and be usable.

Well, I hope that I have got that right!

-- from CyberSimian in the UK

 

[mm1352000]

(1) Don't begin by deleting channels.

Correct.

(2) Rescan, enabling channel-movement detection.

Correct.

(3) Channels that are not changed by the scan do not result in the creation of duplicate channels. Recordings for these channels will continue to work without problem.

Correct.

(4) Channels that are different after the scan will be usable, but may leave as an orphan the equivalent channel that existed before the scan (depending on whether ids changed).

Correct.

These orphans are unusable and should be deleted. Scheduled recordings for programmes on orphan channels will not work, and so need to be deleted and recreated.

Yes and no.
The "should be deleted" and "need to be deleted and recreated" parts depend entirely on personal choice. It is not the only choice/option.

As I tried to explain, you do have options for fixing schedules associated with orphaned channels which don't involve deleting and recreating the schedules. You can attempt to fix the orphaned channels, either by manually editing tuning details (eg. copying the working tuning detail parameters from the new channel to the orphaned channel) or by following the combine process I mentioned.

[edit: Don't forget the other potential consequences of deleting orphaned channels, which are that you'd [possibly] have to rename and/or renumber the replacements to match your preference, add the replacements to the groups the orphans were in, fix the channel order within the groups...]

(5) New channels will be added and be usable.

Correct.

Well, I hope that I have got that right!

Pretty much.

 

[CyberSimian]

The "should be deleted" and "need to be deleted and recreated" parts depend entirely on personal choice. It is not the only choice/option...

Don't forget the other potential consequences of deleting orphaned channels, which are that you'd [possibly] have to rename and/or renumber the replacements to match your preference, add the replacements to the groups the orphans were in, fix the channel order within the groups.

Thank you for re-iterating this, as it had not quite percolated through into my conciousness!

I do not currently use channel groups (but may do so in the future). However, I have modified a couple of channel names, and was contemplating modifying quite a few more (mostly to make them shorter). So it is a good idea to understand the implications of the alternative ways of fixing the channel problems.

When analogue switch-off was completed in the UK, I think that most people assumed that the DVB-T system would then be mostly unchanging. But it does not seem to have turned out that way, with a continuing need for rescans every few months. (The next big change will be migration to DVB-T2, and the eventual switch off of the DVB-T1 transmissions, but probably not for a few years!)

-- from CyberSimian in the UK