Scheduler schedules recordings on channels it doesn't receive

[anonymous]

I've found a little problem with the way mythtv schedules programs.

If more than one capturecard is connected to a single inputsource, mythtv assumes that it can receive every channel associated with the inputsource on either capturecard. Normally this is probably true, but I've found at least one case where it isn't.

I've got a cable box connected by firewire (dct-6200) and a DVB card (pchdtv-5500) both connected to the same feed. The cable box can get any channel, but the DVB card can only get a subset of the channels. I can't set up two different input sources because mythfilldatabase changes the datadirect lineups, and I end up with no data for a bunch of channels. The result is that mythtv schedules recordings on channels it doesn't know how to tune, and these recordings fail, so I miss a bunch of shows.

I thought about a few ways to address this, and this seemed to be the simplest. This patch changes the SQL query in AddNewRecords? so that programs that can't be tuned are omitted.

It's written as a case structure so that others that have different hardware might add additional when clauses that describe when a particular device might be used.

Anyway, I hope this is helpful. Please let me know if I didn't do this correctly, as this is the first time I've submitted a ticket for mythtv. Here's the patch:

$ svn diff programs/mythbackend/scheduler.cpp Index: programs/mythbackend/scheduler.cpp =================================================================== --- programs/mythbackend/scheduler.cpp (revision 13212) +++ programs/mythbackend/scheduler.cpp (working copy) @@ -2319,6 +2319,10 @@

" LEFT JOIN oldfind ON " " (oldfind.recordid = recordmatch.recordid AND " " oldfind.findid = ") + progfindid + QString(") "

+" WHERE (CASE capturecard.cardtype " +" WHEN 'FIREWIRE' THEN channel.channum = channel.channum+0 " +" WHEN 'DVB' THEN (channel.mplexid && channel.mplexid != 32767) " +" ELSE 1 END)"

" ORDER BY RECTABLE.recordid DESC " );

[adambrewster@…]

Patch

[adambrewster@…]

Sorry, putting the patch inline didn't seem to work very well.

The attachment is the same as the patch in the description.

Adam

Here it is again in code tags.

Index: programs/mythbackend/scheduler.cpp
===================================================================
--- programs/mythbackend/scheduler.cpp  (revision 13212)
+++ programs/mythbackend/scheduler.cpp  (working copy)
@@ -2319,6 +2319,10 @@
 " LEFT JOIN oldfind ON "
 "  (oldfind.recordid = recordmatch.recordid AND "
 "   oldfind.findid = ") + progfindid + QString(") "
+" WHERE (CASE capturecard.cardtype "
+"  WHEN 'FIREWIRE' THEN channel.channum = channel.channum+0 "
+"  WHEN 'DVB' THEN (channel.mplexid && channel.mplexid != 32767) "
+"  ELSE 1 END)"
 " ORDER BY RECTABLE.recordid DESC "
 );

[Janne Grunau]

Please don't put nasty hacks into the scheduler.

The correct solution is to create two videosources and use two different data direct line-ups.

Closing this as invalid.

[anonymous]

Thank you for your response, but I disagree with your assessment.

First, I consider searching for nearby zip codes with similar channel lineups to be more of a hack than my solution. What happens if the lineup in one area changes? Also in my area, all the zip codes I know of seem to have identical lineups, so I get the message "This provider has already been selected." even when selecting a different zip code.

Second, a well designed system should work in the broadest possible range of cases. If a user mis-configures his input sources and channel lineups in mythtv (as you say I've done), but the system has enough information to schedule the recordings correctly anyway, then I believe it should do so.

Finally, I don't think that sanity checking qualifies as a "nasty hack" in any computer programming context. It may slow the scheduler down by a couple of milliseconds, but trying to tune a channel where mplexid = 32767 using a dvb card is going to fail every time (unless the system has run out of mplexids, and that's a bigger problem).

From your response, I gather that you're not interested in seeing this problem fixed, so I'm not going to reopen the ticket. If I'm mistaken, please let me know. Otherwise, I'll just apply the patch to my own builds.

Thank you,
Adam

[sphery <mtdean@…>]

Trac is not a discussion forum. Please continue discussion in the thread at ​http://www.gossamer-threads.com/lists/mythtv/users/263214#263214 (from only hours after you created this ticket and I didn't BCC you because of) or create a new one if you can't find the original and I'll explain to you why Janne is correct.