Custom Query (13436 matches)


Show under each result:

Results (25 - 27 of 13436)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Ticket Resolution Summary Owner Reporter
#13625 fixed Insure mythfilldatabase issues reschedule even if --no-mark-repeats is given gigem Gary Buhrmaster

Insure mythfilldatabase issues reschedule even if --no-mark-repeats is given

Ticket created by request of dev from oob discussion.

Mythfilldatabase currently skips the reschedule if the --no-mark-repeats command line option is given, even if other changes to the program database have occurred (which is likely for any real run with real data).

Mitigation: Don't use --no-mark-repeats (which is likely a very rare use case), or run a separate request (mythutil --resched) to force a reschedule after running mythfilldatabase with --no-mark-repeats.

Lightly tested proposed patch follows:

diff --git a/mythtv/programs/mythfilldatabase/main.cpp b/mythtv/programs/mythfilldatabase/main.cpp
index aa6c33ace2..dba30522f8 100644
--- a/mythtv/programs/mythfilldatabase/main.cpp
+++ b/mythtv/programs/mythfilldatabase/main.cpp
@@ -660,9 +660,8 @@ int main(int argc, char *argv[])
             "| the master backend is restarted.                            |\n"

-    if (mark_repeats)
-        ScheduledRecording::RescheduleMatch(0, 0, 0, QDateTime(),
-                                            "MythFillDatabase");
+    ScheduledRecording::RescheduleMatch(0, 0, 0, QDateTime(),
+                                        "MythFillDatabase");


#13624 Duplicate liveTV resolution not detect correctly Mark Kendall veehexx

i'm using a self-compiled fixes/31 build (currently on commit a2b8c26; 1st May 2020), using rpi4 as FE with current latest mythtv-light from PBennetts repo.

I use 2 playback profiles using resolution to define which one to use - one for SD (<1920 <1080) and one for HD (1920 1080). signal is from DVB-S2, and is bra

When watching BBC1HD via LiveTV i've noticed that OSD initally shows a SD tag and OSD_Debug shows a deinterlacer from my SD profile. If i now bring up the program info ('i' on keyboard) once playback has started it correctly reports a 1080HD icon however still remains attached to the SD playback profile untill one of the following is done, which will then correctly bind to the HD profile:

1) pause & unpause playback 2) skip back (skip forward has no effect) 3) switch to another channel (even another HD channel, eg BBC2HD) and switch back to original BBC1HD

my playback profiles define which deinterlacer to use for each resolution, with my SD profile set to high deint. the rpi4 doesnt have the grunt to handle HD content with High deint so results in poor performance. on the flip side, UK SD is also progressive scan so if i set no deinterlacer in my SD proile, then 1080i would result in no deinterlacing.

Recordings do not exhibit this issue and soly related to livetv.

#13623 fixed mythfilldatabase may not process valid XMLTV files if program starttime order is not increasing Bill Meek Gary Buhrmaster

mythfilldatabase (with a9aa006139) may no longer process valid XMLTV files if the program starttime order is not increasing.

Originally reported to the XMLTV project, where it was pointed out that the issue is actually due to a MythTV issue. As the original reporter chose not to create a MythTV ticket (s/he found their own workaround), here is what seems to be the essential part of the original issue so that it can be addressed here:

In a9aa006139 a new (to mythfilldatabase) test was added to check that the starttime was increasing with each new program element on the same channel, and reject the input file if it was not.

While many (most?) XMLTV grabbers appear to return the data in starttime order (and for that matter, channel and starttime order), any such order requirement is not part of the specification, and the original reporter ran into this issue with their chosen grabber for a particular day.

The order check should be removed to support compliant source files.

FWIW, as I recall (it has been a long time since I last looked at the code in question), MythTV itself does its own internal sorting of the program data that it processes for its own purposes.

The mitigation until this issue is resolved is to run the output of a grabber through TV_SORT (but note that if there is a lot of source data TV_SORT can be very resource intensive (lots of memory and cpu)).

COMPLETELY untested patch (not compiled, let alone tested, just sort of looks right):

diff --git a/mythtv/programs/mythfilldatabase/xmltvparser.cpp b/mythtv/programs/mythfilldatabase/xmltvparser.cpp
index 78f22170cd..bbce136c9d 100644
--- a/mythtv/programs/mythfilldatabase/xmltvparser.cpp
+++ b/mythtv/programs/mythfilldatabase/xmltvparser.cpp
@@ -205,8 +205,6 @@ bool XMLTVParser::parseFile(
     QString aggregatedTitle;
     QString aggregatedDesc;
     bool haveReadTV = false;
-    QString last_channel = ""; //xmltvId of the last program element we read
-    QDateTime last_starttime; //starttime of the last program element we read
     while (!xml.atEnd() && !xml.hasError() && (! (xml.isEndElement() && == "tv")))
         if (xml.readNextStartElement())
@@ -709,23 +707,6 @@ bool XMLTVParser::parseFile(
                     // so we have a (relatively) clean program element now, which is good enough to process or to store
-                    if (pginfo->m_channel != last_channel) {
-                        //we have a channel change here
-                        last_channel = pginfo->m_channel;
-                        last_starttime = QDateTime(QDate(1970, 1, 1), QTime(0, 0, 0)); //initialize it to a time far, far away ...
-                    }
-                    else {
-                        //we are still on the same channel
-                        if (pginfo->m_starttime >= last_starttime) {
-                            last_starttime = pginfo->m_starttime;
-                        }
-                        else {
-                            LOG(VB_GENERAL, LOG_ERR, QString("Malformed XML file, program out of order at line %1, %2").arg(xml.lineNumber()).arg(xml.errorString()));
-                            delete pginfo;
-                            return false;
-                        }
-                    }
                     if (pginfo->m_clumpidx.isEmpty())
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Note: See TracQuery for help on using queries.