The 2 channels you mention have the same channel ID in the broadcast data so will end up with the same EPG data. You can see the channel ID in the log.
Many other channels are the same where there is a non HD and an HD channel. They have the same ID that points to the same EPG data for both channels.
Do you have other examples where it is wrong?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have check for other channels but right now those channels are the ones that I know are wrong, if you check in EIT, you will see that those channels have different programming, some times they seem to have the same programming but just for a few hours but if you check the whole day, their programming is different.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you look at the log you can see that the same channel ID is normally used for SD and HD channels. Why they are doing it for the channels that are different I don't know.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With SD and HD makes sense because are the same channel, but for this peculiar case, maybe they are using something else to identify the channel, maybe the channel ID needs something extra, for example in ATSC the subchannel number or something like that, or maybe channel order not just channel id.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You have to take one of those only two programmings from EIT, then compare the datetime + title with its equivalent in MHW2 and you will see that the channel ID doesn't match.
Last edit: Sed Wer 2022-11-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't know why the EIT now/next doesn't match the MHW data but after looking at the data at the protocol level there is no separate data for the 2 channels you have found. They share the same data.
And I've checked to see if there is any EPG related to the 2 channels that might be being ignored and there isn't.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've looked at this problem from time to time and discovered at the weekend
that around one third of programme descriptionS broadcast are never used. It
may be that they are the programmes that are incorrect but I need to check
with recent data.
Then I just need to find the title data that goes with the description.
From: discussion@epgcollector.p.re.sourceforge.net [mailto:discussion@epgcollector.p.re.sourceforge.net] On Behalf Of Sed Wer
Sent: Monday, 21 November 2022 6:58 p.m.
To: stevebickell@xtra.co.nz
Subject: [epgcollector:discussion] MHW2 still gets programming from another
channel
There will probably be gaps around the clock change. If the broadcasters keep the duration of programmes that span the clock change to the actual programme length there will be a gap. If they increased the duration by an hour to account for the clock change that might screw up any software that records those programmes. I guess they leave the programme duration at the actual length.
Similarly when clocks go back there will be many overlaps.
I've attached a log file. There are many programme summaries (ie descriptions) broadcast that are not used by any epg entry. Can you look in the log at the unused summaries and if possible identify which channel the first few might be associated with.
I'm trying to find out what programming ID's belong to those out of phase channels, right now I just can see that most of those orphan programming IDs belong to other channels, I'll try to do a more detail investigation about what programming belong to those incorrect channels.
Meanwhile I have narrowed some channels with wrong programming:
This is one example
[29810 NAT GEO WILD] should be [30605 NAT GEOGRAPH]
and [30605 NAT GEOGRAPH] should be [29810 NAT GEO WILD]
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've attached 3 text files with the channel information that is received.
The channel data is all on pid 0xc8 in tables 0, 2 and 3. Table 1 is used for the category information.
As you can see from the first 2 files the channel tables are the same until you get to channel 41 when there is no LSMARTBANK2 in table 2. Table 2 then has an extra channel at the end, ALQUILER HD. Table 3 is different again.
The channel ID listed is just the position in the table, it is not part of the broadcast data. The only part of the channel data that has not been decoded is listed as unknown in the attached text files. It is listed as both hex and as a number and the number appears to indicate it represents some pointer into another table as it increases for each channel. However I don't know where this might point to.
The epg data is linked to the channel via the channel ID which is in the title data that is transmitted. The channel ID in the title data never exceeds 112, ie the highest channel ID. There doesn't seem to be any information in the title data that says it is for channel table 0, 2 or 3.
So you can see why the epg data is not matching because the 3 channel tables don't match.
You can get all this information out of EPGC by putting the word PROTOCOL in the Trace ID's box on the Diagnostics tab. You will also then get a low level listing of all the titles and summaries. The titles have quite a lot of unknown data fields but I've spent a lot of time trying to decode them with no success. Maybe you can shed some light on them
I need more time to analyze those files, but in a quick check, I've found that the file 0.txt is pretty much the one to look at.
2.txt has some channels as HD, according to my findings, the channels that are failing are not HD, some channels that seem to appear twice without showing its HD counterpart:
Hi Steve, after testing your new version, I still got some channels that doesn't gets the correct programming
Some examples are channels 29857 and 29863, EPG Collector seems to think that those two channels are the same but they aren't.
Here's the dump link
https://easyupload.io/p4bumv
Finally got round to looking at this.
The 2 channels you mention have the same channel ID in the broadcast data so will end up with the same EPG data. You can see the channel ID in the log.
Many other channels are the same where there is a non HD and an HD channel. They have the same ID that points to the same EPG data for both channels.
Do you have other examples where it is wrong?
I have check for other channels but right now those channels are the ones that I know are wrong, if you check in EIT, you will see that those channels have different programming, some times they seem to have the same programming but just for a few hours but if you check the whole day, their programming is different.
EPGC can only go by the channel ID and if they are the same for 2 or more channels they will get the same data.
So that means the Channel ID is not getting right, there's a way to get the Channel ID from EIT instead?
No sorry. It's not present for EIT.
If you look at the log you can see that the same channel ID is normally used for SD and HD channels. Why they are doing it for the channels that are different I don't know.
With SD and HD makes sense because are the same channel, but for this peculiar case, maybe they are using something else to identify the channel, maybe the channel ID needs something extra, for example in ATSC the subchannel number or something like that, or maybe channel order not just channel id.
How do you know the EIT data is different for the 2 channels? When I try collecting EIT all I get is now and next EPG entries.
You have to take one of those only two programmings from EIT, then compare the datetime + title with its equivalent in MHW2 and you will see that the channel ID doesn't match.
Last edit: Sed Wer 2022-11-19
I don't know why the EIT now/next doesn't match the MHW data but after looking at the data at the protocol level there is no separate data for the 2 channels you have found. They share the same data.
And I've checked to see if there is any EPG related to the 2 channels that might be being ignored and there isn't.
Weird, maybe they use EIT for channel ID and HMW for programming.
Can you find any other examples?
This is a new dump
https://easyupload.io/jwi6fj
In this image you can se some channels that have different programming, some are HD so those doesn't count bot the rest do count.
Here's the image
Hi Sed,
Could you give me another TS dump of 10847.
I've looked at this problem from time to time and discovered at the weekend
that around one third of programme descriptionS broadcast are never used. It
may be that they are the programmes that are incorrect but I need to check
with recent data.
Then I just need to find the title data that goes with the description.
From: discussion@epgcollector.p.re.sourceforge.net
[mailto:discussion@epgcollector.p.re.sourceforge.net] On Behalf Of Sed Wer
Sent: Monday, 21 November 2022 6:58 p.m.
To: stevebickell@xtra.co.nz
Subject: [epgcollector:discussion] MHW2 still gets programming from another
channel
Here's the image
Attachments:
https://sourceforge.net/p/epgcollector/discussion/1125945/thread/15d62b9a17 /ad65/attachment/Example_04.png (45.2 kB; image/png)
MHW2 still gets programming from another channel
https://sourceforge.net/p/epgcollector/discussion/1125945/thread/15d62b9a17 /?limit=25#ad65
Sent from sourceforge.net because stevebickell@xtra.co.nz is subscribed to
https://sourceforge.net/p/epgcollector/discussion/1125945/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/epgcollector/admin/discussion/forums. Or, if this
is a mailing list, you can unsubscribe from the mailing list.
Hi, here's the dump
By the way when the summer / winter clock switches, there's a lot of gap in programming.
https://easyupload.io/ym7t8b
There will probably be gaps around the clock change. If the broadcasters keep the duration of programmes that span the clock change to the actual programme length there will be a gap. If they increased the duration by an hour to account for the clock change that might screw up any software that records those programmes. I guess they leave the programme duration at the actual length.
Similarly when clocks go back there will be many overlaps.
I've attached a log file. There are many programme summaries (ie descriptions) broadcast that are not used by any epg entry. Can you look in the log at the unused summaries and if possible identify which channel the first few might be associated with.
Hi Steve,
I'm trying to find out what programming ID's belong to those out of phase channels, right now I just can see that most of those orphan programming IDs belong to other channels, I'll try to do a more detail investigation about what programming belong to those incorrect channels.
Meanwhile I have narrowed some channels with wrong programming:
This is one example
[29810 NAT GEO WILD] should be [30605 NAT GEOGRAPH]
and
[30605 NAT GEOGRAPH] should be [29810 NAT GEO WILD]
On Friday / Saturday (I don't remember exactly what day), this were the wrong channels:
[29857 EUROSPORT 1] <-> [30506 DAZN 2]
[30372 DAZN 1] <-> [29860 DAZN F1]
[30403 DISNEY CH.] <-> [30663 DREAMWORKS]
[30506 DAZN 2] <-> [30372 DAZN 1]
On Sunday, this where the Wrong channels:
[29800 M+ Ellas #V] <-> [30516 M+ #VAMOS]
[29810 NAT GEO WILD] <-> [30605 NAT GEOGRAPH]
[29857 EUROSPORT 1] <-> [30506 DAZN 2]
[29860 DAZN F1] <-> [30601 M+ GOLF]
[30372 DAZN 1] <-> [29860 DAZN F1]
[30403 DISNEY CH.] <-> [30663 DREAMWORKS]
[30506 DAZN 2] <-> [30372 DAZN 1]
[30601 M+ GOLF] <-> [30607 M+ DEPORTES]
[30607 M+ DEPORTES] <-> [29800 M+ELLAS#V]
[30663 DreamWorks] <-> [30510 NICKELODEON]
I've attached 3 text files with the channel information that is received.
The channel data is all on pid 0xc8 in tables 0, 2 and 3. Table 1 is used for the category information.
As you can see from the first 2 files the channel tables are the same until you get to channel 41 when there is no LSMARTBANK2 in table 2. Table 2 then has an extra channel at the end, ALQUILER HD. Table 3 is different again.
The channel ID listed is just the position in the table, it is not part of the broadcast data. The only part of the channel data that has not been decoded is listed as unknown in the attached text files. It is listed as both hex and as a number and the number appears to indicate it represents some pointer into another table as it increases for each channel. However I don't know where this might point to.
The epg data is linked to the channel via the channel ID which is in the title data that is transmitted. The channel ID in the title data never exceeds 112, ie the highest channel ID. There doesn't seem to be any information in the title data that says it is for channel table 0, 2 or 3.
So you can see why the epg data is not matching because the 3 channel tables don't match.
You can get all this information out of EPGC by putting the word PROTOCOL in the Trace ID's box on the Diagnostics tab. You will also then get a low level listing of all the titles and summaries. The titles have quite a lot of unknown data fields but I've spent a lot of time trying to decode them with no success. Maybe you can shed some light on them
I need more time to analyze those files, but in a quick check, I've found that the file 0.txt is pretty much the one to look at.
2.txt has some channels as HD, according to my findings, the channels that are failing are not HD, some channels that seem to appear twice without showing its HD counterpart:
(30901) M+ ELLAS #V | (29800) M+ELLAS#V
(29962) M+ #VAMOS | (30516) M+ #VAMOS
(29965) DREAMWORKS | (30663) DREAMWORKS
Both tables might need to be used because some channels with the same name have different NID/TID/SID.
What do you think table 3 is for?
Wow, apparently, there are some "hidden" channels, that are not available in the other tables, for example:
ONID: 8916 TSID: 14 SID: 277 Name: DISCOVERY M. Unknown: 0x18f3
ONID: 8916 TSID: 14 SID: 202 Name: PARAMOUNT C. Unknown: 0x19c3
ONID: 8916 TSID: 40000 SID: 40003 Name: TDP HD Unknown: 0x20f3
Those 3 channels doesn't appear in EPG when you execute EPG Collector.
Table 3 might be ignored in your version.