Can't find MP2 client settings? (1 Viewer)

[morpheus_xx]

[edit: By the way, in what context would such a modification actually be useful? I've never come across any XMLTV file which contains programme elements with identical start and stop time attributes.]

My commit note contains the reference to one possible source: the grabber for tvtv.de produced such results. IIRC the main issue were "overlapping programs": there was on big program over 8 hours, and then multiple small ones in the same range. The first of this smaller programs had the same start time as the "surrounding" program.

While this could be said to be issues of the grabber or the online site providing program information, in result it lead to programs persisted that had the same start and end time. My filter exaclty prevented this case.

What I didn't know was the fact that there are xmltv sources that obmit the endtime and that other logic deals with it. As the original coded didn't solve my problem, and the new code doesn't support the other way, both should be changed to a common way.

If I move the check into the correction functions, the result should be the expected one. Or a simple check constraint on the Programs table that avoids "start = end" would be another possibility (effective but not elegant).

 

[mm1352000]

IIRC the main issue were "overlapping programs": there was on big program over 8 hours, and then multiple small ones in the same range. The first of this smaller programs had the same start time as the "surrounding" program.

Did the grabber use the clumpidx attribute?
http://xmltv.cvs.sourceforge.net/viewvc/xmltv/xmltv/xmltv.dtd

TV listings sometimes have the problem of listing two or more programmes in the same timeslot, such as 'News; Weather'. We call this a 'clump' of programmes, and the 'clumpidx' attribute differentiates between two programmes sharing the same timeslot and channel. In this case News would have clumpidx="0/2" and Weather would have clumpidx="1/2". If you don't have this problem, be thankful!

While this could be said to be issues of the grabber or the online site providing program information...

Bingo. IMHO the problem should be fixed at the source. Trying to hack in checks and workarounds elsewhere is messy and error prone. I strongly dislike such approaches.

...both should be changed to a common way.

As above: I disagree.

If I move the check into the correction functions, the result should be the expected one. Or a simple check constraint on the Programs table that avoids "start = end" would be another possibility (effective but not elegant).

What about fixing the grabber?

 

[morpheus_xx]

I think the main issue is the problem with multiple programs that have the same start time in common: in fixup there is first a sorting, then the endtimes will be corrected. This correction actually sets the end times of former programs to the same start time.

So if we in principle agree that it is not wanted to have such entries, we can make sure they won't get persisted. But after the other fixes have been applied. If all sources would be free of errors, we probably would not even need the "FixEndTimes" and "RemoveOverlappingPrograms" methods.

 

[mm1352000]

So if we in principle agree that it is not wanted to have such entries, we can make sure they won't get persisted.

No, we don't agree. Probably one or even both/all of the entries represent valid programs. The problem is that the encoder has failed to encode the start and stop times correctly. Such input is non-compliant. I insist that the XMLTV plugin shouldn't even attempt to deal with the situation. If there are multiple programmes with the same start time, obviously at least one should be kept. However the XMLTV plugin has no idea what to do. That's why I say this problem should be fixed at the source and the XMLTV plugin code should be completely left alone. If there are multiple sources for this problem, all of them should be fixed.

If all sources would be free of errors, we probably would not even need the "FixEndTimes" and "RemoveOverlappingPrograms" methods.

No, I disagree again. FixEndTimes (and various other processing) is responsible for determining the stop time when it's not provided (remember that providing the stop time is optional). Therefore such methods will always be needed.

 

[Lehmden]

If there are multiple sources for this problem, all of them should be fixed.

In a perfect world, absolutely... But this is not in our hands as we don't provide those sources. They are external programs developed by others. We can ask them to fix those, but most likely this won't happen. So any way to make the code more robust on external errors is a good attempt.

 

[mm1352000]

@Lehmden
Hypothetically you are right. My point is that modifying the XMLTV plugin should be the last resort.

In practice for this specific problem: so far the WebGrab++ grabber for tvtv.de is/was the only known source. That grabber (.ini file) can be modified by anybody. Further, some sort of fix seems to have been provided when the problem was reported. So, why all the fuss? morpheus_xx's change clearly broke the XMLTV plugin and seems to be no longer required. Why can't it simply be reverted?

 

[morpheus_xx]

To be correct, this was another kind of fix.

 

[mm1352000]

I give up. Clearly we have different opinions once again. I regret replying to this thread.

 

[HTPCSourcer]

Hi @mm1352000 ,

Can you PM morpheus and me please?

 

[LaoChe]

I just went through the whole process again and immediately ran the log collector so these logs should have everything. I am also including the xml files in case those help.