Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#11287 closed Bug Report - General (fixed)

mythtv-setup can not add video sources when a large lineup exists in Schedules Direct

Reported by: skd5aner <skd5aner@…> Owned by: danielk
Priority: minor Milestone: 0.26.1
Component: MythTV - Mythtv-setup Version: 0.26-fixes
Severity: medium Keywords:
Cc: Ticket locked: no

Description

My cable company got the wise idea of completely switching their lineups today. I followed the age old advice of simply deleting the existing video sources, and trying to re-add them. However, the Data Direct lineup box never populates. I'm leveraging schedules direct.

Here are the only relevant lines from the log with -v most:

2012-12-11 18:58:37.460719 I  Fetching lineups from Schedules Direct...
2012-12-11 18:58:37.746113 I  DataDirect: Grabbing channel data
2012-12-11 18:58:37.746193 I  Downloading DataDirect feed
2012-12-11 18:58:49.756527 E  DataDirect: Failed to get data: Download error
2012-12-11 18:58:49.756547 E  DDLS: fillSelections did not successfully load selections
2012-12-11 18:58:49.756949 I  DataDirect: Deleting temporary files

Searching the mailing list, I can across this email thread, and it appears to be a bug associated with the switch from leveraging wget to MDM and it timing out too early. http://www.gossamer-threads.com/lists/mythtv/users/530565#530565

I would submit a patch to increase the time out, but I'm not sure what the most reasonable setting should be. I can see this is impacting other users as well, and hadn't noticed a bug report for it yet.

Change History (5)

comment:1 Changed 11 years ago by skd5aner <skd5aner@…>

Per the email thread, I applied the following patch:

diff --git a/mythtv/libs/libmythbase/mythdownloadmanager.cpp b/mythtv/libs/libmy
index cc1721b..2bbdc20 100644
--- a/mythtv/libs/libmythbase/mythdownloadmanager.cpp
+++ b/mythtv/libs/libmythbase/mythdownloadmanager.cpp
@@ -813,7 +813,7 @@ bool MythDownloadManager::downloadNow(MythDownloadInfo *dlIn
     while ((!dlInfo->IsDone()) &&
            (dlInfo->m_errorCode == QNetworkReply::NoError) &&
            (((!dlInfo->m_url.startsWith("myth://")) &&
-             (dlInfo->m_lastStat.secsTo(MythDate::current()) < 10)) ||
+             (dlInfo->m_lastStat.secsTo(MythDate::current()) < 45)) ||
             ((dlInfo->m_url.startsWith("myth://")) &&
              (startedAt.secsTo(MythDate::current()) < 20))))
     {

That said, 45 might have been too long. I think upping it from 10 to ~15-20 might have been sufficient in my case, based on me counting out loud while watching the console scroll to where it was successful.

comment:2 Changed 11 years ago by skd5aner <skd5aner@…>

Sorry, hit submit too soon - Applying that change did "fix" the problem for me.

comment:3 Changed 11 years ago by Chris Pinkham <cpinkham@…>

Resolution: fixed
Status: newclosed

In afa03f27a2fb442800f148fb28da1f7585a2f02f/mythtv:

Bump MDM::downloadNow() timeout up to 60 seconds.

The previous 10-second timeout was causing issues when trying to
download large lineups from Schedules Direct. This commit bumps
the downloadNow() timeout to 60 seconds. This is a blocking call,
so if the caller doesn't want to potentially block for that long,
they should be use one of the non-blocking methods.

Fixes #11287.

comment:4 Changed 11 years ago by Chris Pinkham <cpinkham@…>

In bcc459fa2893f65c1debe9a7f976d3c23e865531/mythtv:

Bump MDM::downloadNow() timeout up to 60 seconds.

The previous 10-second timeout was causing issues when trying to
download large lineups from Schedules Direct. This commit bumps
the downloadNow() timeout to 60 seconds. This is a blocking call,
so if the caller doesn't want to potentially block for that long,
they should be use one of the non-blocking methods.

References #11287.

(cherry picked from commit afa03f27a2fb442800f148fb28da1f7585a2f02f)

comment:5 Changed 11 years ago by Raymond Wagner

Milestone: unknown0.26.1
Note: See TracTickets for help on using tickets.